Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
_exec_queue_destroy+0xb3/0xf0 [xe] <4> [953.587515] xe_oa_release+0x9c/0xc0 [xe] (cherry picked from commit b107c63d2953907908fd0cafb0e543b3c3167b75) Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/ed7cd3510d8da6e3578d9125a9ea4440f8adeeaa - https://git.kernel.org/stable/c/c0403e4ceecaefbeaf78263dffcd3e3f06a19f6b
CVE ID: CVE-2024-53133 State: PUBLISHED Published: 2024-12-04T14:20:39.077Z Last Updated: 2025-10-01T20:17:09.922Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle dml allocation failure to avoid crash [Why] In the case where a dml allocation fails for any reason, the current state's dml contexts would no longer be valid. Then subsequent calls dc_state_copy_internal would shallow copy invalid memory and if the new state was released, a double free would occur. [How] Reset dml pointers in new_state to NULL and avoid invalid pointer (cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c) Additio
new_state to NULL and avoid invalid pointer (cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c) Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/874ff59cde8fc525112dda26b501a1bac17dde9f - https://git.kernel.org/stable/c/6825cb07b79ffeb1d90ffaa7a1227462cdca34ae
CVE ID: CVE-2024-53134 State: PUBLISHED Published: 2024-12-04T14:20:40.002Z Last Updated: 2025-10-01T20:17:09.789Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx93-blk-ctrl: correct remove path The check condition should be 'i < bc->onecell_data.num_domains', not 'bc->onecell_data.num_domains' which will make the look never finish and cause kernel panic. Also disable runtime to address "imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!" Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/8fc228ab5d38a026eae7183a5f74a4fac43d9b6a - https://git.kerne
Vulnrichment: References: - https://git.kernel.org/stable/c/8fc228ab5d38a026eae7183a5f74a4fac43d9b6a - https://git.kernel.org/stable/c/201fb9e164a1e4c5937de2cf58bcb0327c08664f - https://git.kernel.org/stable/c/f7c7c5aa556378a2c8da72c1f7f238b6648f95fb
CVE ID: CVE-2024-53135 State: PUBLISHED Published: 2024-12-04T14:20:40.815Z Last Updated: 2025-11-03T22:29:37.797Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN Hide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable support for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are myriad bugs in the implementation, some of which are fatal to the guest, and others which put the stability and health of the host at risk. For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and *stays* d
ost at risk. For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and *stays* disabled prior to VM-Enter, which is necessary as hardware disallows loading (the guest's) RTIT_CTL if tracing is enabled (enforced via a VMX consistency check). Per the SDM: If the logical processor is operating with Intel PT enabled (if IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the "load IA32_RTIT_CTL" VM-entry control must be 0. On the host side, KVM doesn't validate the guest CPUID configuration provided by userspace, and even worse, uses the guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring guest CPUID to enumerate
guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring guest CPUID to enumerate more address ranges than are supported in hardware will result in KVM trying to passthrough, save, and load non-existent MSRs, which generates a variety of WARNs, ToPA ERRORs in the host, a potential deadlock, etc. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/c3742319d021f5aa3a0a8c828485fee14753f6de - https://git.kernel.org/stable/c/d4b42f926adcce4e5ec193c714afd9d37bba8e5b - https://git.kernel.org/stable/c/b8a1d572478b6f239061ee9578b2451bf2f021c2 - https://git.kernel.org/stable/c/e6716f4230a8784957273ddd27326264b27b9313 -
c/b8a1d572478b6f239061ee9578b2451bf2f021c2 - https://git.kernel.org/stable/c/e6716f4230a8784957273ddd27326264b27b9313 - https://git.kernel.org/stable/c/d28b059ee4779b5102c5da6e929762520510e406 - https://git.kernel.org/stable/c/b91bb0ce5cd7005b376eac690ec664c1b56372ec - https://git.kernel.org/stable/c/aa0d42cacf093a6fcca872edc954f6f812926a17
CVE ID: CVE-2024-53136 State: PUBLISHED Published: 2024-12-04T14:20:41.634Z Last Updated: 2025-11-03T22:29:39.267Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm: revert "mm: shmem: fix data-race in shmem_getattr()" Revert d949d1d14fa2 ("mm: shmem: fix data-race in shmem_getattr()") as suggested by Chuck [1]. It is causing deadlocks when accessing tmpfs over NFS. As Hugh commented, "added just to silence a syzbot sanitizer splat: added where there has never been any practical problem". Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/36b537e8f302f670c7cf35d88a3a294443e32d52 - h
tes: - CVE Program Container: References: - https://git.kernel.org/stable/c/36b537e8f302f670c7cf35d88a3a294443e32d52 - https://git.kernel.org/stable/c/a3c65022d89d5baa2cea8e87a6de983ea305f14c - https://git.kernel.org/stable/c/57cc8d253099d1b8627f0fb487ee011d9158ccc9 - https://git.kernel.org/stable/c/d3f9d88c2c03b2646ace336236adca19f7697bd3 - https://git.kernel.org/stable/c/5874c1150e77296565ad6e495ef41fbf87570d14 - https://git.kernel.org/stable/c/64e67e8694252c1bf01b802ee911be3fee62c36b - https://git.kernel.org/stable/c/901dc2ad7c3789fa87dc3956f6697c5d62d5cf7e - https://git.kernel.org/stable/c/d1aa0c04294e29883d65eac6c2f72fe95cc7c049
CVE ID: CVE-2024-53137 State: PUBLISHED Published: 2024-12-04T14:20:42.510Z Last Updated: 2025-10-01T20:17:09.655Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ARM: fix cacheflush with PAN It seems that the cacheflush syscall got broken when PAN for LPAE was implemented. User access was not enabled around the cache maintenance instructions, causing them to fault. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/e6960a2ed49c9a25357817535f7cc50594a58604 - https://git.kernel.org/stable/c/ca29cfcc4a21083d671522ad384532e28a43f033
CVE ID: CVE-2024-53138 State: PUBLISHED Published: 2024-12-04T14:20:43.395Z Last Updated: 2025-11-03T22:29:40.765Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: kTLS, Fix incorrect page refcounting The kTLS tx handling code is using a mix of get_page() and page_ref_inc() APIs to increment the page reference. But on the release path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used. This is an issue when using pages from large folios: the get_page() references are stored on the folio page while the page_ref_inc() references are stored directly in the given page. On release the folio page will be dere
o page while the page_ref_inc() references are stored directly in the given page. On release the folio page will be dereferenced too many times. This was found while doing kTLS testing with sendfile() + ZC when the served file was read from NFS on a kernel with NFS large folios support (commit 49b29a573da8 ("nfs: add support for large folios")). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/a0ddb20a748b122ea86003485f7992fa5e84cc95 - https://git.kernel.org/stable/c/ffad2ac8c859c1c1a981fe9c4f7ff925db684a43 - https://git.kernel.org/stable/c/c7b97f9e794d8e2bbaa50e1d6c230196fd214b5e - https://git.kernel.org/stable/c/69fbd07f17b0fdaf8970bc705f5bf1
l.org/stable/c/c7b97f9e794d8e2bbaa50e1d6c230196fd214b5e - https://git.kernel.org/stable/c/69fbd07f17b0fdaf8970bc705f5bf115c297839d - https://git.kernel.org/stable/c/93a14620b97c911489a5b008782f3d9b0c4aeff4 - https://git.kernel.org/stable/c/2723e8b2cbd486cb96e5a61b22473f7fd62e18df - https://git.kernel.org/stable/c/dd6e972cc5890d91d6749bb48e3912721c4e4b25
CVE ID: CVE-2024-53139 State: PUBLISHED Published: 2024-12-04T14:20:44.169Z Last Updated: 2025-05-04T09:54:01.311Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sctp: fix possible UAF in sctp_v6_available() A lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints that sctp_v6_available() is calling dev_get_by_index_rcu() and ipv6_chk_addr() without holding rcu. [1] ============================= WARNING: suspicious RCU usage 6.12.0-rc5-virtme #1216 Tainted: G W ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_lock
CU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by sctp_hello/31495: #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp stack backtrace: CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G W 6.12.0-rc5-virtme #1216 Tainted: [W]=WARN Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7)) sctp_v6_available (net/sct
s (kernel/locking/lockdep.c:6822) dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7)) sctp_v6_available (net/sctp/ipv6.c:701) sctp sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp sctp_bind (net/sctp/socket.c:320) sctp inet6_bind_sk (net/ipv6/af_inet6.c:465) ? security_socket_bind (security/security.c:4581 (discriminator 1)) __sys_bind (net/socket.c:1848 net/socket.c:1869) ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340) ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminato
pt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13)) __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1)) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f59b934a1e7 Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b
9 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48 All code ======== 0: 44 00 00 add %r8b,(%rax) 3: 48 8b 15 39 8c 0c 00 mov 0xc8c39(%rip),%rdx # 0xc8c43 a: f7 d8 neg %eax c: 64 89 02 mov %eax,%fs:(%rdx) f: b8 ff ff ff ff mov $0xffffffff,%eax 14: eb bd jmp 0xffffffffffffffd3 16: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1) 1d: 00 00 00 20: 0f 1f 00 nopl (%rax) 23: b8 31 00 00 00 mov $0x31,%eax 28: 0f 05 syscall 2a:* 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax <-- trapping instruction 30: 73 01 jae 0x33 32: c3 ret 33: 48 8b 0d 09 8c 0c 00 mov 0xc8c09(%rip),%rcx # 0xc8c43 3a: f7 d8 neg %e
ing instruction 30: 73 01 jae 0x33 32: c3 ret 33: 48 8b 0d 09 8c 0c 00 mov 0xc8c09(%rip),%rcx # 0xc8c43 3a: f7 d8 neg %eax 3c: 64 89 01 mov %eax,%fs:(%rcx) 3f: 48 rex.W Code starting with the faulting instruction =========================================== 0: 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax 6: 73 01 jae 0x9 8: c3 ret 9: 48 8b 0d 09 8c 0c 00 mov 0xc8c09(%rip),%rcx # 0xc8c19 10: f7 d8 neg %eax 12: 64 89 01 mov %eax,%fs:(%rcx) 15: 48 rex.W RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7 RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 19999999999999
7f59b934a1e7 RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000 R10: 00007f59b9253298 R11: 000000000000 ---truncated--- Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/ad975697211f4f2c4ce61c3ba524fd14d88ceab8 - https://git.kernel.org/stable/c/05656a66592759242c74063616291b7274d11b2f - https://git.kernel.org/stable/c/eb72e7fcc83987d5d5595b43222f23b295d5de7f
CVE ID: CVE-2024-53140 State: PUBLISHED Published: 2024-12-04T14:20:44.914Z Last Updated: 2025-11-03T22:29:42.217Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvm
ous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee th
work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. Some async code may still access the socket after close, queue notification skbs to it etc. but no dumps can start, end or otherwise make progress. Delete the workqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for i
kqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for instance we now always call .done before releasing the main module reference, so dump doesn't have to take a reference of its own. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/114a61d8d94ae3a43b82446cf737fd757021b834 - https://git.kernel.org/stable/c/598c956b62699c3753929602560d8df322e60559 - https://git.kernel.org/stable/c/6e3f2c512d2b7dbd247485b1dd9e43e4210a18f4 - https://git.kernel.org/stable/c/d2fab3d66cc16cfb9e3ea1772abe6b79b71fa603 - https://git.kernel.org/stable/c/4e87a52133284afbd40fb522dbf96e258af52a98 - https://gi
6cc16cfb9e3ea1772abe6b79b71fa603 - https://git.kernel.org/stable/c/4e87a52133284afbd40fb522dbf96e258af52a98 - https://git.kernel.org/stable/c/bbc769d2fa1b8b368c5fbe013b5b096afa3c05ca - https://git.kernel.org/stable/c/176c41b3ca9281a9736b67c6121b03dbf0c8c08f - https://git.kernel.org/stable/c/1904fb9ebf911441f90a68e96b22aa73e4410505
CVE ID: CVE-2024-53141 State: PUBLISHED Published: 2024-12-06T09:37:02.009Z Last Updated: 2025-11-03T20:46:21.162Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add missing range check in bitmap_ip_uadt When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists, the values of ip and ip_to are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs. So we should add missing range checks and remove unnecessary range checks. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/sta
ve unnecessary range checks. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/3c20b5948f119ae61ee35ad8584d666020c91581 - https://git.kernel.org/stable/c/78b0f2028f1043227a8eb0c41944027fc6a04596 - https://git.kernel.org/stable/c/2e151b8ca31607d14fddc4ad0f14da0893e1a7c7 - https://git.kernel.org/stable/c/e67471437ae9083fa73fa67eee1573fec1b7c8cf - https://git.kernel.org/stable/c/7ffef5e5d5eeecd9687204a5ec2d863752aafb7e - https://git.kernel.org/stable/c/856023ef032d824309abd5c747241dffa33aae8c - https://git.kernel.org/stable/c/591efa494a1cf649f50a35def649c43ae984cd03 - https://git.kernel.org/stable/c/15794835378ed56fb9bacc6a5dd3b9f33520604e - https:
fa494a1cf649f50a35def649c43ae984cd03 - https://git.kernel.org/stable/c/15794835378ed56fb9bacc6a5dd3b9f33520604e - https://git.kernel.org/stable/c/35f56c554eb1b56b77b3cf197a6b00922d49033d
CVE ID: CVE-2024-53142 State: PUBLISHED Published: 2024-12-06T09:37:03.035Z Last Updated: 2025-11-03T20:46:24.014Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as: 37 cpio_file := ALGN(4) + cpio_header + filename + "\0" + ALGN(4) + data ... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== ========================= ... 70 c_namesize 8 bytes Length of filename, including final \0 When extracting an initramf
= ========================= ... 70 c_namesize 8 bytes Length of filename, including final \0 When extracting an initramfs cpio archive, the kernel's do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash s
ystem, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block. ---- reproducer.sh ---- nilchar="A" # change to "\0" to properly zero terminate / pad magic="070701" ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname="initramfs_test_fname_over
0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname="initramfs_test_fname_overrun" namelen=$(( ${#fname} + 1 )) # plus one to account for terminator printf "%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s" \ $magic $ino $mode $uid $gid $nlink $mtime $filesize \ $devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) )) printf "%.s${nilchar}" $(seq 1 $termpadlen) ---- reproducer.sh ---- Symlink filename fields handled in do_symlink() won't overrun past the data segment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs
gment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn't carry a zero-terminator at the expected (name_len - 1) offset. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/bb7ac96670ab1d8d681015f9d66e45dad579af4d - https://git.kernel.org/stable/c/c509b1acbd867d9e09580fe059a924cb5825afb1 - https://git.kernel.org/stable/c/d3df9f26cff97beaa5643e551031795d5d5cddbe - https://git.kernel.org/stable/c/6983b8ac787b3add5571cda563574932a59a99bb - https://git.kernel.org/stable/c/f892ddcf9f645380c358e73653cb0900f6bc9eb8 - https://git.kernel.org/stable/c/1a423bbbeaf9e3
ttps://git.kernel.org/stable/c/f892ddcf9f645380c358e73653cb0900f6bc9eb8 - https://git.kernel.org/stable/c/1a423bbbeaf9e3e20c4686501efd9b661fe834db - https://git.kernel.org/stable/c/49d01e736c3045319e030d1e75fb983011abaca7 - https://git.kernel.org/stable/c/fb83b093f75806333b6f4ae29b158d2e0e3ec971 - https://git.kernel.org/stable/c/e017671f534dd3f568db9e47b0583e853d2da9b5
CVE ID: CVE-2024-53143 State: PUBLISHED Published: 2024-12-07T06:40:43.522Z Last Updated: 2025-05-04T09:54:07.791Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix ordering of iput() and watched_objects decrement Ensure the superblock is kept alive until we're done with iput(). Holding a reference to an inode is not allowed unless we ensure the superblock stays alive, which fsnotify does by keeping the watched_objects count elevated, so iput() must happen before the watched_objects decrement. This can lead to a UAF of something like sb->s_fs_info in tmpfs, but the UAF is hard to hit because race orderings that oops
can lead to a UAF of something like sb->s_fs_info in tmpfs, but the UAF is hard to hit because race orderings that oops are more likely, thanks to the CHECK_DATA_CORRUPTION() block in generic_shutdown_super(). Also, ensure that fsnotify_put_sb_watched_objects() doesn't call fsnotify_sb_watched_objects() on a superblock that may have already been freed, which would cause a UAF read of sb->s_fsnotify_info. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/45a8f8232a495221ed058191629f5c628f21601a - https://git.kernel.org/stable/c/83af1cfa10d9aafdabd06b3655e07727f373b434 - https://git.kernel.org/stable/c/21d1b618b6b9da46c5116c640ac4b1cc8d40d63a - ht
83af1cfa10d9aafdabd06b3655e07727f373b434 - https://git.kernel.org/stable/c/21d1b618b6b9da46c5116c640ac4b1cc8d40d63a - https://project-zero.issues.chromium.org/issues/379667898
CVE ID: CVE-2024-53144 State: PUBLISHED Published: 2024-12-17T15:55:03.394Z Last Updated: 2025-11-03T22:29:43.667Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE This aligned BR/EDR JUST_WORKS method with LE which since 92516cd97fd4 ("Bluetooth: Always request for user confirmation for Just Works") always request user confirmation with confirm_hint set since the likes of bluetoothd have dedicated policy around JUST_WORKS method (e.g. main.conf:JustWorksRepairing). CVE: CVE-2024-8805 Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.or