Aggregator

LSN-0107-1: Kernel Live Patch Security Notice

Ubuntu Security Advisories
2 weeks 3 days ago
In the Linux kernel, the following vulnerability has been resolved: inet: inet_defrag: prevent sk release while still in use ip_local_out() and other functions can pass skb->sk as function argument. If the skb is a fragment and reassembly happens before such function call returns, the sk must not be released. This affects skb fragments reassembled via netfilter or similar modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline. Eric Dumazet made an initial analysis of this bug. Quoting Eric: Calling ip_defrag() in output path is also implying skb_orphan(), which is buggy because output path relies on sk not disappearing. A relevant old patch about the issue was : 8282f27449bf ('inet: frag: Always orphan skbs inside ip_defrag()') [.. net/ipv4/ip_output.c depends on skb->sk being set, and probably to an inet socket, not an arbitrary one. If we orphan the packet in ipvlan, then downstream things like FQ packet scheduler will not work properly. We need to change ip_defrag() to only use skb_orphan() when really needed, ie whenever frag_list is going to be used. Eric suggested to stash sk in fragment queue and made an initial patch. However there is a problem with this: If skb is refragmented again right after, ip_do_fragment() will copy head->sk to the new fragments, and sets up destructor to sock_wfree. IOW, we have no choice but to fix up sk_wmem accouting to reflect the fully reassembled skb, else wmem will underflow. This change moves the orphan down into the core, to last possible moment. As ip_defrag_offset is aliased with sk_buff->sk member, we must move the offset into the FRAG_CB, else skb->sk gets clobbered. This allows to delay the orphaning long enough to learn if the skb has to be queued or if the skb is completing the reasm queue. In the former case, things work as before, skb is orphaned. This is safe because skb gets queued/stolen and won't continue past reasm engine. In the latter case, we will steal the skb->sk reference, reattach it to the head skb, and fix up wmem accouting when inet_frag inflates truesize.)(CVE-2024-26921) In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix garbage collector racing against connect() Garbage collector does not take into account the risk of embryo getting enqueued during the garbage collection. If such embryo has a peer that carries SCM_RIGHTS, two consecutive passes of scan_children() may see a different set of children. Leading to an incorrectly elevated inflight count, and then a dangling pointer within the gc_inflight_list. sockets are AF_UNIX/SOCK_STREAM S is an unconnected socket L is a listening in-flight socket bound to addr, not in fdtable V's fd will be passed via sendmsg(), gets inflight count bumped connect(S, addr) sendmsg(S, [V]); close(V) __unix_gc() ---------------- ------------------------- ----------- NS = unix_create1() skb1 = sock_wmalloc(NS) L = unix_find_other(addr) unix_state_lock(L) unix_peer(S) = NS // V count=1 inflight=0 NS = unix_peer(S) skb2 = sock_alloc() skb_queue_tail(NS, skb2[V]) // V became in-flight // V count=2 inflight=1 close(V) // V count=1 inflight=1 // GC candidate condition met for u in gc_inflight_list: if (total_refs == inflight_refs) add u to gc_candidates // gc_candidates={L, V} for u in gc_candidates: scan_children(u, dec_inflight) // embryo (skb1) was not // reachable from L yet, so V's // inflight remains unchanged __skb_queue_tail(L, skb1) unix_state_unlock(L) for u in gc_candidates: if (u.inflight) scan_children(u, inc_inflight_move_tail) // V count=1 inflight=2 (!) If there is a GC-candidate listening socket, lock/unlock its state. This makes GC wait until the end of any ongoing connect() to that socket. After flipping the lock, a possibly SCM-laden embryo is already enqueued. And if there is another embryo coming, it can not possibly carry SCM_RIGHTS. At this point, unix_inflight() can not happen because unix_gc_lock is already taken. Inflight graph remains unaffected.)(CVE-2024-26923) In the Linux kernel, the following vulnerability has been resolved: mm: swap: fix race between free_swap_and_cache() and swapoff() There was previously a theoretical window where swapoff() could run and teardown a swap_info_struct while a call to free_swap_and_cache() was running in another thread. This could cause, amongst other bad possibilities, swap_page_trans_huge_swapped() (called by free_swap_and_cache()) to access the freed memory for swap_map. This is a theoretical problem and I haven't been able to provoke it from a test case. But there has been agreement based on code review that this is possible (see link below). Fix it by using get_swap_device()/put_swap_device(), which will stall swapoff(). There was an extra check in _swap_info_get() to confirm that the swap entry was not free. This isn't present in get_swap_device() because it doesn't make sense in general due to the race between getting the reference and swapoff. So I've added an equivalent check directly in free_swap_and_cache(). Details of how to provoke one possible issue (thanks to David Hildenbrand for deriving this): --8<----- __swap_entry_free() might be the last user and result in 'count == SWAP_HAS_CACHE'. swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0. So the question is: could someone reclaim the folio and turn si->inuse_pages==0, before we completed swap_page_trans_huge_swapped(). Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are still references by swap entries. Process 1 still references subpage 0 via swap entry. Process 2 still references subpage 1 via swap entry. Process 1 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE [then, preempted in the hypervisor etc.] Process 2 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls __try_to_reclaim_swap(). __try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()-> put_swap_folio()->free_swap_slot()->swapcache_free_entries()-> swap_entry_free()->swap_range_free()-> ... WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries); What stops swapoff to succeed after process 2 reclaimed the swap cache but before process1 finished its call to swap_page_trans_huge_swapped()? --8<-----)(CVE-2024-26960) In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix use-after-free bugs caused by sco_sock_timeout When the sco connection is established and then, the sco socket is releasing, timeout_work will be scheduled to judge whether the sco disconnection is timeout. The sock will be deallocated later, but it is dereferenced again in sco_sock_timeout. As a result, the use-after-free bugs will happen. The root cause is shown below: Cleanup Thread Worker Thread sco_sock_release sco_sock_close __sco_sock_close sco_sock_set_timer schedule_delayed_work sco_sock_kill (wait a time) sock_put(sk) //FREE sco_sock_timeout sock_hold(sk) //USE The KASAN report triggered by POC is shown below: [ 95.890016 ================================================================== [ 95.890496] BUG: KASAN: slab-use-after-free in sco_sock_timeout+0x5e/0x1c0 [ 95.890755] Write of size 4 at addr ffff88800c388080 by task kworker/0:0/7 ... [ 95.890755] Workqueue: events sco_sock_timeout [ 95.890755] Call Trace: [ 95.890755] [ 95.890755] dump_stack_lvl+0x45/0x110 [ 95.890755] print_address_description+0x78/0x390 [ 95.890755 print_report+0x11b/0x250 [ 95.890755] ? __virt_addr_valid+0xbe/0xf0 [ 95.890755] ? sco_sock_timeout+0x5e/0x1c0 [ 95.890755 kasan_report+0x139/0x170 [ 95.890755] ? update_load_avg+0xe5/0x9f0 [ 95.890755] ? sco_sock_timeout+0x5e/0x1c0 [ 95.890755 kasan_check_range+0x2c3/0x2e0 [ 95.890755] sco_sock_timeout+0x5e/0x1c0 [ 95.890755] process_one_work+0x561/0xc50 [ 95.890755 worker_thread+0xab2/0x13c0 [ 95.890755] ? pr_cont_work+0x490/0x490 [ 95.890755] kthread+0x279/0x300 [ 95.890755] ? pr_cont_work+0x490/0x490 [ 95.890755] ? kthread_blkcg+0xa0/0xa0 [ 95.890755] ret_from_fork+0x34/0x60 [ 95.890755] ? kthread_blkcg+0xa0/0xa0 [ 95.890755 ret_from_fork_asm+0x11/0x20 [ 95.890755] [ 95.890755] [ 95.890755 Allocated by task 506: [ 95.890755] kasan_save_track+0x3f/0x70 [ 95.890755 __kasan_kmalloc+0x86/0x90 [ 95.890755] __kmalloc+0x17f/0x360 [ 95.890755 sk_prot_alloc+0xe1/0x1a0 [ 95.890755] sk_alloc+0x31/0x4e0 [ 95.890755 bt_sock_alloc+0x2b/0x2a0 [ 95.890755] sco_sock_create+0xad/0x320 [ 95.890755] bt_sock_create+0x145/0x320 [ 95.890755 __sock_create+0x2e1/0x650 [ 95.890755] __sys_socket+0xd0/0x280 [ 95.890755 __x64_sys_socket+0x75/0x80 [ 95.890755] do_syscall_64+0xc4/0x1b0 [ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f [ 95.890755] [ 95.890755] Freed by task 506: [ 95.890755] kasan_save_track+0x3f/0x70 [ 95.890755] kasan_save_free_info+0x40/0x50 [ 95.890755 poison_slab_object+0x118/0x180 [ 95.890755] __kasan_slab_free+0x12/0x30 [ 95.890755] kfree+0xb2/0x240 [ 95.890755] __sk_destruct+0x317/0x410 [ 95.890755] sco_sock_release+0x232/0x280 [ 95.890755] sock_close+0xb2/0x210 [ 95.890755] __fput+0x37f/0x770 [ 95.890755] task_work_run+0x1ae/0x210 [ 95.890755] get_signal+0xe17/0xf70 [ 95.890755 arch_do_signal_or_restart+0x3f/0x520 [ 95.890755 syscall_exit_to_user_mode+0x55/0x120 [ 95.890755] do_syscall_64+0xd1/0x1b0 [ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f [ 95.890755] [ 95.890755] The buggy address belongs to the object at ffff88800c388000 [ 95.890755] which belongs to the cache kmalloc-1k of size 1024 [ 95.890755 The buggy address is located 128 bytes inside of [ 95.890755] freed 1024-byte region [ffff88800c388000, ffff88800c388400) [ 95.890755] [ 95.890755] The buggy address belongs to the physical page: [ 95.890755 page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88800c38a800 pfn:0xc388 [ 95.890755] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 95.890755] ano ---truncated---)(CVE-2024-27398) In the Linux kernel, the following vulnerability has been resolved: watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger When the cpu5wdt module is removing, the origin code uses del_timer() to de-activate the timer. If the timer handler is running, del_timer() could not stop it and will return directly. If the port region is released by release_region() and then the timer handler cpu5wdt_trigger() calls outb() to write into the region that is released, the use-after-free bug will happen. Change del_timer() to timer_shutdown_sync() in order that the timer handler could be finished before the port region is released.)(CVE-2024-38630)

USN-7091-1: Ruby vulnerabilities

Ubuntu Security Advisories
2 weeks 3 days ago
It was discovered that Ruby incorrectly handled parsing of an XML document that has specific XML characters in an attribute value using REXML gem. An attacker could use this issue to cause Ruby to crash, resulting in a denial of service. This issue only affected in Ubuntu 22.04 LTS and Ubuntu 24.04 LTS. (CVE-2024-35176, CVE-2024-39908, CVE-2024-41123) It was discovered that Ruby incorrectly handled parsing of an XML document that has many entity expansions with SAX2 or pull parser API. An attacker could use this issue to cause Ruby to crash, resulting in a denial of service. (CVE-2024-41946) It was discovered that Ruby incorrectly handled parsing of an XML document that has many digits in a hex numeric character reference. An attacker could use this issue to cause Ruby to crash, resulting in a denial of service. (CVE-2024-49761)

USN-7083-1: OpenJPEG vulnerabilities

Ubuntu Security Advisories
2 weeks 3 days ago
It was discovered that OpenJPEG incorrectly handled certain memory operations when using the command line "-ImgDir" in a directory with a large number of files, leading to an integer overflow vulnerability. An attacker could potentially use this issue to cause a denial of service. This issue only affected Ubuntu 16.04 LTS, Ubuntu 18.04 LTS, Ubuntu 20.04 LTS and Ubuntu 22.04 LTS. (CVE-2021-29338) It was discovered that OpenJPEG incorrectly handled decompressing certain .j2k files in sycc420_to_rgb, leading to a heap-based buffer overflow vulnerability. If a user or automated system were tricked into opening a specially crafted file, an attacker could possibly use this issue to execute arbitrary code. (CVE-2021-3575) It was discovered that OpenJPEG incorrectly handled certain memory operations in the opj2_decompress program. An attacker could potentially use this issue to cause a denial of service. This issue only affected Ubuntu 16.04 LTS, Ubuntu 18.04 LTS, Ubuntu 20.04 LTS and Ubuntu 22.04 LTS. (CVE-2022-1122)

USN-7089-2: Linux kernel vulnerabilities

Ubuntu Security Advisories
2 weeks 4 days ago
Chenyuan Yang discovered that the USB Gadget subsystem in the Linux kernel did not properly check for the device to be enabled before writing. A local attacker could possibly use this to cause a denial of service. (CVE-2024-25741) Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems: - ARM32 architecture; - MIPS architecture; - PA-RISC architecture; - PowerPC architecture; - RISC-V architecture; - S390 architecture; - x86 architecture; - Cryptographic API; - Serial ATA and Parallel ATA drivers; - Null block device driver; - Bluetooth drivers; - Cdrom driver; - Clock framework and drivers; - Hardware crypto device drivers; - CXL (Compute Express Link) drivers; - Cirrus firmware drivers; - GPIO subsystem; - GPU drivers; - I2C subsystem; - IIO subsystem; - InfiniBand drivers; - ISDN/mISDN subsystem; - LED subsystem; - Multiple devices driver; - Media drivers; - Fastrpc Driver; - Network drivers; - Microsoft Azure Network Adapter (MANA) driver; - Near Field Communication (NFC) drivers; - NVME drivers; - NVMEM (Non Volatile Memory) drivers; - PCI subsystem; - Pin controllers subsystem; - x86 platform drivers; - S/390 drivers; - SCSI drivers; - Thermal drivers; - TTY drivers; - UFS subsystem; - USB DSL drivers; - USB core drivers; - DesignWare USB3 driver; - USB Gadget drivers; - USB Serial drivers; - VFIO drivers; - VHOST drivers; - File systems infrastructure; - BTRFS file system; - GFS2 file system; - JFFS2 file system; - JFS file system; - Network file systems library; - Network file system client; - NILFS2 file system; - NTFS3 file system; - SMB network file system; - Memory management; - Netfilter; - Tracing infrastructure; - io_uring subsystem; - BPF subsystem; - Core kernel; - Bluetooth subsystem; - CAN network layer; - Ceph Core library; - Networking core; - IPv4 networking; - IPv6 networking; - IUCV driver; - MAC80211 subsystem; - Network traffic control; - Sun RPC protocol; - Wireless networking; - AMD SoC Alsa drivers; - SoC Audio for Freescale CPUs drivers; - MediaTek ASoC drivers; - SoC audio core drivers; - SOF drivers; - Sound sequencer drivers; (CVE-2024-42104, CVE-2024-42101, CVE-2024-41052, CVE-2024-42157, CVE-2024-41020, CVE-2024-41055, CVE-2024-42124, CVE-2023-52888, CVE-2024-42079, CVE-2024-43858, CVE-2024-41075, CVE-2024-42073, CVE-2024-42113, CVE-2024-42110, CVE-2024-41080, CVE-2024-42097, CVE-2024-41046, CVE-2024-42076, CVE-2024-41010, CVE-2024-41018, CVE-2024-42115, CVE-2024-41048, CVE-2024-42231, CVE-2024-42241, CVE-2024-41034, CVE-2024-42065, CVE-2024-42140, CVE-2024-42094, CVE-2024-41029, CVE-2024-42225, CVE-2024-41096, CVE-2024-42088, CVE-2024-41087, CVE-2023-52887, CVE-2024-42141, CVE-2024-42135, CVE-2024-42247, CVE-2024-39487, CVE-2024-42229, CVE-2024-42147, CVE-2024-42252, CVE-2024-41038, CVE-2024-41083, CVE-2024-42091, CVE-2024-42156, CVE-2024-42149, CVE-2024-41015, CVE-2024-41047, CVE-2024-42129, CVE-2024-42120, CVE-2024-41097, CVE-2024-42243, CVE-2024-42084, CVE-2024-42250, CVE-2024-41023, CVE-2024-41028, CVE-2024-42108, CVE-2024-41045, CVE-2024-42098, CVE-2024-41064, CVE-2024-42087, CVE-2024-42080, CVE-2024-41049, CVE-2024-42271, CVE-2024-41037, CVE-2024-42114, CVE-2024-41044, CVE-2024-42126, CVE-2024-42119, CVE-2024-42223, CVE-2024-42280, CVE-2024-42112, CVE-2024-41019, CVE-2024-42133, CVE-2024-42152, CVE-2024-41074, CVE-2024-41042, CVE-2024-41093, CVE-2024-41025, CVE-2024-42253, CVE-2024-42136, CVE-2024-42127, CVE-2024-41036, CVE-2024-42237, CVE-2024-42111, CVE-2024-41031, CVE-2024-41069, CVE-2024-41084, CVE-2024-41076, CVE-2024-41090, CVE-2024-41088, CVE-2024-41070, CVE-2024-42118, CVE-2024-42238, CVE-2024-42234, CVE-2024-41089, CVE-2024-41095, CVE-2024-41085, CVE-2024-42106, CVE-2024-42155, CVE-2024-42146, CVE-2024-42130, CVE-2024-42089, CVE-2024-42132, CVE-2024-41091, CVE-2024-42153, CVE-2024-42236, CVE-2024-42085, CVE-2024-41065, CVE-2024-41032, CVE-2024-42090, CVE-2024-41030, CVE-2024-41017, CVE-2024-42230, CVE-2024-42144, CVE-2024-42137, CVE-2024-41082, CVE-2024-41056, CVE-2024-42145, CVE-2024-41041, CVE-2024-42240, CVE-2024-41081, CVE-2024-42103, CVE-2024-41053, CVE-2024-42070, CVE-2024-42121, CVE-2024-42105, CVE-2024-41022, CVE-2024-42151, CVE-2024-42142, CVE-2024-41035, CVE-2024-42232, CVE-2024-41058, CVE-2024-42109, CVE-2024-41077, CVE-2024-42095, CVE-2024-39486, CVE-2024-42131, CVE-2024-42068, CVE-2024-41073, CVE-2024-41079, CVE-2024-42082, CVE-2024-41071, CVE-2024-41066, CVE-2024-42102, CVE-2024-43855, CVE-2024-41061, CVE-2024-41072, CVE-2024-41059, CVE-2024-41094, CVE-2024-41021, CVE-2024-41098, CVE-2024-42158, CVE-2024-41033, CVE-2024-42096, CVE-2024-42251, CVE-2024-42077, CVE-2024-42063, CVE-2024-42227, CVE-2024-41007, CVE-2024-41057, CVE-2024-41063, CVE-2024-41039, CVE-2024-41067, CVE-2024-41062, CVE-2024-42100, CVE-2024-42074, CVE-2024-42064, CVE-2024-41092, CVE-2024-42128, CVE-2024-41086, CVE-2024-41054, CVE-2024-42239, CVE-2024-41027, CVE-2024-42093, CVE-2024-42244, CVE-2024-41050, CVE-2024-41012, CVE-2024-42246, CVE-2024-42117, CVE-2024-42069, CVE-2024-42067, CVE-2024-42086, CVE-2024-42066, CVE-2024-41060, CVE-2024-42248, CVE-2024-41068, CVE-2024-42161, CVE-2024-42092, CVE-2024-42245, CVE-2024-41078, CVE-2024-42235, CVE-2024-42150, CVE-2024-41051, CVE-2024-42138)

USN-7088-2: Linux kernel vulnerabilities

Ubuntu Security Advisories
2 weeks 4 days ago
Ziming Zhang discovered that the VMware Virtual GPU DRM driver in the Linux kernel contained an integer overflow vulnerability. A local attacker could use this to cause a denial of service (system crash). (CVE-2022-36402) Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems: - ARM64 architecture; - PowerPC architecture; - User-Mode Linux (UML); - x86 architecture; - Block layer subsystem; - Cryptographic API; - Android drivers; - Serial ATA and Parallel ATA drivers; - ATM drivers; - Drivers core; - CPU frequency scaling framework; - Device frequency scaling framework; - GPU drivers; - HID subsystem; - Hardware monitoring drivers; - InfiniBand drivers; - Input Device core drivers; - Input Device (Miscellaneous) drivers; - IOMMU subsystem; - IRQ chip drivers; - ISDN/mISDN subsystem; - LED subsystem; - Multiple devices driver; - Media drivers; - EEPROM drivers; - VMware VMCI Driver; - MMC subsystem; - Network drivers; - Near Field Communication (NFC) drivers; - NVME drivers; - Device tree and open firmware driver; - Parport drivers; - PCI subsystem; - Pin controllers subsystem; - Remote Processor subsystem; - S/390 drivers; - SCSI drivers; - QCOM SoC drivers; - Direct Digital Synthesis drivers; - TTY drivers; - Userspace I/O drivers; - DesignWare USB3 driver; - USB Gadget drivers; - USB Serial drivers; - BTRFS file system; - File systems infrastructure; - Ext4 file system; - F2FS file system; - JFS file system; - NILFS2 file system; - BPF subsystem; - Core kernel; - DMA mapping infrastructure; - Tracing infrastructure; - Radix Tree data structure library; - Kernel userspace event delivery library; - Objagg library; - Memory management; - Amateur Radio drivers; - Bluetooth subsystem; - CAN network layer; - Networking core; - Ethtool driver; - IPv4 networking; - IPv6 networking; - IUCV driver; - KCM (Kernel Connection Multiplexor) sockets driver; - MAC80211 subsystem; - Netfilter; - Network traffic control; - SCTP protocol; - Sun RPC protocol; - TIPC protocol; - TLS protocol; - Wireless networking; - AppArmor security module; - Simplified Mandatory Access Control Kernel framework; - SoC audio core drivers; - USB sound devices; (CVE-2024-46714, CVE-2024-42288, CVE-2024-42290, CVE-2024-44987, CVE-2024-41090, CVE-2024-42313, CVE-2024-46689, CVE-2024-46737, CVE-2024-44946, CVE-2024-44999, CVE-2024-44935, CVE-2024-38602, CVE-2024-43883, CVE-2024-26607, CVE-2024-41091, CVE-2024-45025, CVE-2024-42305, CVE-2024-26891, CVE-2024-41073, CVE-2024-44969, CVE-2024-26641, CVE-2024-46719, CVE-2024-40929, CVE-2024-46721, CVE-2024-46740, CVE-2024-41012, CVE-2024-42280, CVE-2024-46738, CVE-2024-46722, CVE-2024-42246, CVE-2024-41063, CVE-2024-41072, CVE-2024-41068, CVE-2024-43884, CVE-2024-46758, CVE-2024-43861, CVE-2024-42306, CVE-2024-42285, CVE-2024-41065, CVE-2024-46818, CVE-2024-43894, CVE-2024-44954, CVE-2024-42310, CVE-2024-46829, CVE-2023-52614, CVE-2024-47663, CVE-2024-42281, CVE-2024-42297, CVE-2024-46800, CVE-2024-44960, CVE-2024-44952, CVE-2024-46747, CVE-2024-42286, CVE-2024-41071, CVE-2024-43893, CVE-2023-52531, CVE-2024-43860, CVE-2024-46840, CVE-2024-41011, CVE-2024-43890, CVE-2024-45026, CVE-2024-42292, CVE-2024-27051, CVE-2024-41015, CVE-2024-47668, CVE-2024-46817, CVE-2024-43846, CVE-2024-44988, CVE-2024-44944, CVE-2024-43829, CVE-2024-45021, CVE-2024-43914, CVE-2024-43856, CVE-2024-46673, CVE-2024-46771, CVE-2024-41081, CVE-2024-43830, CVE-2024-43839, CVE-2024-43853, CVE-2024-47669, CVE-2024-42244, CVE-2021-47212, CVE-2024-46844, CVE-2024-44965, CVE-2024-41059, CVE-2024-46783, CVE-2024-42295, CVE-2024-35848, CVE-2024-41017, CVE-2024-47659, CVE-2024-42309, CVE-2024-26800, CVE-2024-41064, CVE-2024-43879, CVE-2024-46679, CVE-2024-43854, CVE-2024-41022, CVE-2024-43858, CVE-2024-46739, CVE-2024-46685, CVE-2024-42289, CVE-2024-44998, CVE-2024-46761, CVE-2024-46677, CVE-2024-42131, CVE-2024-46815, CVE-2024-46777, CVE-2024-43880, CVE-2024-42276, CVE-2024-42265, CVE-2024-46723, CVE-2024-42259, CVE-2024-45028, CVE-2024-42229, CVE-2024-42283, CVE-2024-44948, CVE-2024-44995, CVE-2024-46757, CVE-2024-46822, CVE-2024-45006, CVE-2024-46780, CVE-2024-26668, CVE-2024-42284, CVE-2024-46782, CVE-2024-46781, CVE-2024-43871, CVE-2024-42304, CVE-2024-42311, CVE-2024-45003, CVE-2024-46745, CVE-2024-41098, CVE-2024-46750, CVE-2024-47667, CVE-2024-41020, CVE-2024-26640, CVE-2024-41070, CVE-2024-42301, CVE-2024-43882, CVE-2024-45008, CVE-2024-26885, CVE-2024-42287, CVE-2024-46744, CVE-2024-43908, CVE-2024-46798, CVE-2023-52918, CVE-2024-36484, CVE-2024-43841, CVE-2024-41042, CVE-2024-38611, CVE-2024-43867, CVE-2024-26669, CVE-2024-42271, CVE-2024-46756, CVE-2024-44947, CVE-2024-43835, CVE-2024-46676, CVE-2024-46743, CVE-2024-46759, CVE-2024-46675, CVE-2024-46828, CVE-2024-46755)