Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
00080050033 [ 42.212704][ T164] CR2: 00007f0dc8e9fe10 CR3: 000000000b56d003 CR4: 0000000000772ef0 [ 42.213227][ T164] PKRU: 55555554 [ 42.213366][ T164] Call Trace: [ 42.213483][ T164] <TASK> [ 42.213565][ T164] __fbnic_pm_attach.isra.0+0x8e/0xa0 [ 42.213725][ T164] pci_reset_function+0x116/0x1d0 [ 42.213895][ T164] reset_store+0xa0/0x100 [ 42.214025][ T164] ? pci_dev_reset_attr_is_visible+0x50/0x50 [ 42.214221][ T164] ? sysfs_file_kobj+0xc1/0x1e0 [ 42.214374][ T164] ? sysfs_kf_write+0x65/0x160 [ 42.214526][ T164] kernfs_fop_write_iter+0x2f8/0x4c0 [ 42.214677][ T164] ? kernfs_vma_page_mkwrite+0x1f0/0x1f0 [ 42.214836][ T164] new_sync_write+0x308/0x6f0 [ 42.214987][ T164] ? __lock_acquire+0x34
fs_vma_page_mkwrite+0x1f0/0x1f0 [ 42.214836][ T164] new_sync_write+0x308/0x6f0 [ 42.214987][ T164] ? __lock_acquire+0x34c/0x740 [ 42.215135][ T164] ? new_sync_read+0x6f0/0x6f0 [ 42.215288][ T164] ? lock_acquire.part.0+0xbc/0x260 [ 42.215440][ T164] ? ksys_write+0xff/0x200 [ 42.215590][ T164] ? perf_trace_sched_switch+0x6d0/0x6d0 [ 42.215742][ T164] vfs_write+0x65e/0xbb0 [ 42.215876][ T164] ksys_write+0xff/0x200 [ 42.215994][ T164] ? __ia32_sys_read+0xc0/0xc0 [ 42.216141][ T164] ? do_user_addr_fault+0x269/0x9f0 [ 42.216292][ T164] ? rcu_is_watching+0x15/0xd0 [ 42.216442][ T164] do_syscall_64+0xbb/0x360 [ 42.216591][ T164] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 42.216784][ T164] RIP: 0033:
64] do_syscall_64+0xbb/0x360 [ 42.216591][ T164] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 42.216784][ T164] RIP: 0033:0x7f0dc8ea9986 A bit of digging showed that we were invoking the phylink_resume as a part of the fbnic_up path when we were enabling the service task while not holding the RTNL lock. We should be enabling this sooner as a part of the ndo_open path and then just letting the service task come online later. This will help to enforce the correct locking and brings the phylink interface online at the same time as the network interface, instead of at a later time. I tested this on QEMU to verify this was working by putting the system to sleep using "echo mem > /sys/power/state" t
e. I tested this on QEMU to verify this was working by putting the system to sleep using "echo mem > /sys/power/state" to put the system to sleep in the guest and then using the command "system_wakeup" in the QEMU monitor. References: - https://git.kernel.org/stable/c/7aab65c62a8a8b48c02e600fe9367b2af662fcb6 - https://git.kernel.org/stable/c/3ac5f54e47eb348a4bc26e600c63b4d778a22e23 - https://git.kernel.org/stable/c/6ede14a2c6365e7e5d855643c7c8390b5268c467
CVE ID: CVE-2025-39832 State: PUBLISHED Published: 2025-09-16T13:08:49.513Z Last Updated: 2025-09-29T06:00:35.700Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix lockdep assertion on sync reset unload event Fix lockdep assertion triggered during sync reset unload event. When the sync reset flow is initiated using the devlink reload fw_activate option, the PF already holds the devlink lock while handling unload event. In this case, delegate sync reset unload event handling back to the devlink callback process to avoid double-locking and resolve the lockdep warning. Kernel log: WARNING: CPU: 9 PID: 1578 at devl_asse
back process to avoid double-locking and resolve the lockdep warning. Kernel log: WARNING: CPU: 9 PID: 1578 at devl_assert_locked+0x31/0x40 [...] Call Trace: <TASK> mlx5_unload_one_devl_locked+0x2c/0xc0 [mlx5_core] mlx5_sync_reset_unload_event+0xaf/0x2f0 [mlx5_core] process_one_work+0x222/0x640 worker_thread+0x199/0x350 kthread+0x10b/0x230 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x8e/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> References: - https://git.kernel.org/stable/c/ddac9d0fe2493dd550cbfc75eeaf31e9b6dac959 - https://git.kernel.org/stable/c/0c87dba9ccd3801d3b503f0b4fd41be343af4f06 - https://git.kernel.org/stable/c/06d897148e7963865
s://git.kernel.org/stable/c/0c87dba9ccd3801d3b503f0b4fd41be343af4f06 - https://git.kernel.org/stable/c/06d897148e79638651800d851a69547b56b4be2e - https://git.kernel.org/stable/c/902a8bc23a24882200f57cadc270e15a2cfaf2bb
CVE ID: CVE-2025-39833 State: PUBLISHED Published: 2025-09-16T13:08:50.192Z Last Updated: 2025-09-29T06:00:36.938Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mISDN: hfcpci: Fix warning when deleting uninitialized timer With CONFIG_DEBUG_OBJECTS_TIMERS unloading hfcpci module leads to the following splat: [ 250.215892] ODEBUG: assert_init not available (active state 0) object: ffffffffc01a3dc0 object type: timer_list hint: 0x0 [ 250.217520] WARNING: CPU: 0 PID: 233 at lib/debugobjects.c:612 debug_print_object+0x1b6/0x2c0 [ 250.218775] Modules linked in: hfcpci(-) mISDN_core [ 250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod No
ct+0x1b6/0x2c0 [ 250.218775] Modules linked in: hfcpci(-) mISDN_core [ 250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod Not tainted 6.17.0-rc2-g6f713187ac98 #2 PREEMPT(voluntary) [ 250.220940] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 250.222377] RIP: 0010:debug_print_object+0x1b6/0x2c0 [ 250.223131] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 41 56 48 8b 14 dd a0 4e 01 9f 48 89 ee 48 c7 c7 20 46 01 9f e8 cb 84d [ 250.225805] RSP: 0018:ffff888015ea7c08 EFLAGS: 00010286 [ 250.226608] RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff9be93a95 [ 250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0
0000000000000005 RCX: ffffffff9be93a95 [ 250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0 [ 250.228993] RBP: ffffffff9f014a00 R08: 0000000000000001 R09: ffffed1002bd4f39 [ 250.230043] R10: ffff888015ea79cf R11: 0000000000000001 R12: 0000000000000001 [ 250.231185] R13: ffffffff9eea0520 R14: 0000000000000000 R15: ffff888015ea7cc8 [ 250.232454] FS: 00007f3208f01540(0000) GS:ffff8880caf5a000(0000) knlGS:0000000000000000 [ 250.233851] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 250.234856] CR2: 00007f32090a7421 CR3: 0000000004d63000 CR4: 00000000000006f0 [ 250.236117] Call Trace: [ 250.236599] <TASK> [ 250.236967] ? trace_irq_enable.constprop.0+0xd4/0x130 [ 25
0000000006f0 [ 250.236117] Call Trace: [ 250.236599] <TASK> [ 250.236967] ? trace_irq_enable.constprop.0+0xd4/0x130 [ 250.237920] debug_object_assert_init+0x1f6/0x310 [ 250.238762] ? __pfx_debug_object_assert_init+0x10/0x10 [ 250.239658] ? __lock_acquire+0xdea/0x1c70 [ 250.240369] __try_to_del_timer_sync+0x69/0x140 [ 250.241172] ? __pfx___try_to_del_timer_sync+0x10/0x10 [ 250.242058] ? __timer_delete_sync+0xc6/0x120 [ 250.242842] ? lock_acquire+0x30/0x80 [ 250.243474] ? __timer_delete_sync+0xc6/0x120 [ 250.244262] __timer_delete_sync+0x98/0x120 [ 250.245015] HFC_cleanup+0x10/0x20 [hfcpci] [ 250.245704] __do_sys_delete_module+0x348/0x510 [ 250.246461] ? __pfx___do_sys_delete_module+0x10/0x10
0/0x20 [hfcpci] [ 250.245704] __do_sys_delete_module+0x348/0x510 [ 250.246461] ? __pfx___do_sys_delete_module+0x10/0x10 [ 250.247338] do_syscall_64+0xc1/0x360 [ 250.247924] entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by initializing hfc_tl timer with DEFINE_TIMER macro. Also, use mod_timer instead of manual timeout update. References: - https://git.kernel.org/stable/c/43fc5da8133badf17f5df250ba03b9d882254845 - https://git.kernel.org/stable/c/97766512a9951b9fd6fc97f1b93211642bb0b220
CVE ID: CVE-2025-39834 State: PUBLISHED Published: 2025-09-16T13:08:50.896Z Last Updated: 2025-09-29T06:00:38.178Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/mlx5: HWS, Fix memory leak in hws_action_get_shared_stc_nic error flow When an invalid stc_type is provided, the function allocates memory for shared_stc but jumps to unlock_and_out without freeing it, causing a memory leak. Fix by jumping to free_shared_stc label instead to ensure proper cleanup. References: - https://git.kernel.org/stable/c/051fd8576a2e4e95d5870c5c9f8679c5b16882e4 - https://git.kernel.org/stable/c/a630f83592cdad1253523a1b760cfe78fef6cd9c
CVE ID: CVE-2025-39835 State: PUBLISHED Published: 2025-09-16T13:08:51.599Z Last Updated: 2025-11-03T17:43:51.920Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: xfs: do not propagate ENODATA disk errors into xattr code ENODATA (aka ENOATTR) has a very specific meaning in the xfs xattr code; namely, that the requested attribute name could not be found. However, a medium error from disk may also return ENODATA. At best, this medium error may escape to userspace as "attribute not found" when in fact it's an IO (disk) error. At worst, we may oops in xfs_attr_leaf_get() when we do: error = xfs_attr_leaf_hasname(args, &bp); if (erro
disk) error. At worst, we may oops in xfs_attr_leaf_get() when we do: error = xfs_attr_leaf_hasname(args, &bp); if (error == -ENOATTR) { xfs_trans_brelse(args->trans, bp); return error; } because an ENODATA/ENOATTR error from disk leaves us with a null bp, and the xfs_trans_brelse will then null-deref it. As discussed on the list, we really need to modify the lower level IO functions to trap all disk errors and ensure that we don't let unique errors like this leak up into higher xfs functions - many like this should be remapped to EIO. However, this patch directly addresses a reported bug in the xattr code, and should be safe to backport to stable kernels. A larger-scope patch to handle more
a reported bug in the xattr code, and should be safe to backport to stable kernels. A larger-scope patch to handle more unique errors at lower levels can follow later. (Note, prior to 07120f1abdff we did not oops, but we did return the wrong error code to userspace.) Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/157ddfb05961c68ab7d457a462822a698e4e4bf4 - https://git.kernel.org/stable/c/90bae69c2959c39912f0c2f07a9a7894f3fc49f5 - https://git.kernel.org/stable/c/e358d4b6225e4c1eb208686a05e360ef8df59e07 - https://git.kernel.org/stable/c/d3cc7476b89fb45b7e00874f4f56f6b928467c60 - https://git.kernel.org/stable/c/dcdf36f1b67884c722abce9b8946e34ffb
g/stable/c/d3cc7476b89fb45b7e00874f4f56f6b928467c60 - https://git.kernel.org/stable/c/dcdf36f1b67884c722abce9b8946e34ffb9f67c8 - https://git.kernel.org/stable/c/39fc2742ca14f7fbc621ce9b43bcbd00248cb9a8 - https://git.kernel.org/stable/c/ae668cd567a6a7622bc813ee0bb61c42bed61ba7
CVE ID: CVE-2025-39836 State: PUBLISHED Published: 2025-09-16T13:08:52.326Z Last Updated: 2025-09-29T06:00:40.674Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: efi: stmm: Fix incorrect buffer allocation method The communication buffer allocated by setup_mm_hdr() is later on passed to tee_shm_register_kernel_buf(). The latter expects those buffers to be contiguous pages, but setup_mm_hdr() just uses kmalloc(). That can cause various corruptions or BUGs, specifically since commit 9aec2fb0fd5e ("slab: allocate frozen pages"), though it was broken before as well. Fix this by using alloc_pages_exact() instead of kmalloc(). Referen
frozen pages"), though it was broken before as well. Fix this by using alloc_pages_exact() instead of kmalloc(). References: - https://git.kernel.org/stable/c/77ff27ff0e4529a003c8a1c2492c111968c378d3 - https://git.kernel.org/stable/c/630c0e6064daf84f17aad1a7d9ca76b562e3fe47 - https://git.kernel.org/stable/c/c5e81e672699e0c5557b2b755cc8f7a69aa92bff
CVE ID: CVE-2025-39837 State: PUBLISHED Published: 2025-09-19T15:26:12.152Z Last Updated: 2025-09-29T06:00:41.813Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: platform/x86: asus-wmi: Fix racy registrations asus_wmi_register_driver() may be called from multiple drivers concurrently, which can lead to the racy list operations, eventually corrupting the memory and hitting Oops on some ASUS machines. Also, the error handling is missing, and it forgot to unregister ACPI lps0 dev ops in the error case. This patch covers those issues by introducing a simple mutex at acpi_wmi_register_driver() & *_unregister_driver, and adding the p
covers those issues by introducing a simple mutex at acpi_wmi_register_driver() & *_unregister_driver, and adding the proper call of asus_s2idle_check_unregister() in the error path. References: - https://git.kernel.org/stable/c/e7a70326fb26b905cfc8fe2366113aa4394733ef - https://git.kernel.org/stable/c/5549202b9c02c2ecbc8634768a3da8d9e82d548d
CVE ID: CVE-2025-39838 State: PUBLISHED Published: 2025-09-19T15:26:13.506Z Last Updated: 2025-11-03T17:43:52.863Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cifs: prevent NULL pointer dereference in UTF16 conversion There can be a NULL pointer dereference bug here. NULL is passed to __cifs_sfu_make_node without checks, which passes it unchecked to cifs_strndup_to_utf16, which in turn passes it to cifs_local_to_utf16_bytes where '*from' is dereferenced, causing a crash. This patch adds a check for NULL 'src' in cifs_strndup_to_utf16 and returns NULL early to prevent dereferencing NULL pointer. Found by Linux Verification Ce
c' in cifs_strndup_to_utf16 and returns NULL early to prevent dereferencing NULL pointer. Found by Linux Verification Center (linuxtesting.org) with SVACE Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/65b98a7e65e7a8f3894d8760cd194eaf20504c99 - https://git.kernel.org/stable/c/1cfa5dd05847137f0fb3ce74ced80c0b4858d716 - https://git.kernel.org/stable/c/1f797f062b5cf13a1c2bcc23285361baaa7c9260 - https://git.kernel.org/stable/c/3c26a8d30ed6b53a52a023ec537dc50a6d34a67a - https://git.kernel.org/stable/c/70bccd9855dae56942f2b18a08ba137bb54093a0
CVE ID: CVE-2025-39839 State: PUBLISHED Published: 2025-09-19T15:26:14.688Z Last Updated: 2025-11-03T17:43:54.812Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix OOB read/write in network-coding decode batadv_nc_skb_decode_packet() trusts coded_len and checks only against skb->len. XOR starts at sizeof(struct batadv_unicast_packet), reducing payload headroom, and the source skb length is not verified, allowing an out-of-bounds read and a small out-of-bounds write. Validate that coded_len fits within the payload area of both destination and source sk_buffs before XORing. Additional Analyst Notes: - CVE Program Co
ithin the payload area of both destination and source sk_buffs before XORing. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/30fc47248f02b8a14a61df469e1da4704be1a19f - https://git.kernel.org/stable/c/1e36c6c8dc8023b4bbe9a16e819f9998b9b6a183 - https://git.kernel.org/stable/c/5d334bce9fad58cf328d8fa14ea1fff855819863 - https://git.kernel.org/stable/c/dce6c2aa70e94c04c523b375dfcc664d7a0a560a - https://git.kernel.org/stable/c/bb37252c9af1cb250f34735ee98f80b46be3cef1 - https://git.kernel.org/stable/c/20080709457bc1e920eb002483d7d981d9b2ac1c - https://git.kernel.org/stable/c/a67c6397fcb7e842d3c595243049940970541c48 - https://git.kernel.org/stable/c/
81d9b2ac1c - https://git.kernel.org/stable/c/a67c6397fcb7e842d3c595243049940970541c48 - https://git.kernel.org/stable/c/d77b6ff0ce35a6d0b0b7b9581bc3f76d041d4087
CVE ID: CVE-2025-39840 State: PUBLISHED Published: 2025-09-19T15:26:15.596Z Last Updated: 2025-09-29T06:00:45.574Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: audit: fix out-of-bounds read in audit_compare_dname_path() When a watch on dir=/ is combined with an fsnotify event for a single-character name directly under / (e.g., creating /a), an out-of-bounds read can occur in audit_compare_dname_path(). The helper parent_len() returns 1 for "/". In audit_compare_dname_path(), when parentlen equals the full path length (1), the code sets p = path + 1 and pathlen = 1 - 1 = 0. The subsequent loop then dereferences p[pathlen - 1]
th length (1), the code sets p = path + 1 and pathlen = 1 - 1 = 0. The subsequent loop then dereferences p[pathlen - 1] (i.e., p[-1]), causing an out-of-bounds read. Fix this by adding a pathlen > 0 check to the while loop condition to prevent the out-of-bounds access. [PM: subject tweak, sign-off email fixes] References: - https://git.kernel.org/stable/c/9735a9dcc307427e7d6336c54171682f1bac9789 - https://git.kernel.org/stable/c/4540f1d23e7f387880ce46d11b5cd3f27248bf8d
CVE ID: CVE-2025-39841 State: PUBLISHED Published: 2025-09-19T15:26:16.349Z Last Updated: 2025-11-03T17:43:56.756Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix buffer free/clear order in deferred receive path Fix a use-after-free window by correcting the buffer release sequence in the deferred receive path. The code freed the RQ buffer first and only then cleared the context pointer under the lock. Concurrent paths (e.g., ABTS and the repost path) also inspect and release the same pointer under the lock, so the old order could lead to double-free/UAF. Note that the repost path already uses the correct pattern:
er the lock, so the old order could lead to double-free/UAF. Note that the repost path already uses the correct pattern: detach the pointer under the lock, then free it after dropping the lock. The deferred path should do the same. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/ab34084f42ee06a9028d67c78feafb911d33d111 - https://git.kernel.org/stable/c/baa39f6ad79d372a6ce0aa639fbb2f1578479f57 - https://git.kernel.org/stable/c/95b63d15fce5c54a73bbf195e1aacb5a75b128e2 - https://git.kernel.org/stable/c/55658c7501467ca9ef3bd4453dd920010db8bc13 - https://git.kernel.org/stable/c/d96cc9a1b57725930c60b607423759d563b4d900 - https://git.kernel.org/stabl
d920010db8bc13 - https://git.kernel.org/stable/c/d96cc9a1b57725930c60b607423759d563b4d900 - https://git.kernel.org/stable/c/367cb5ffd8a8a4c85dc89f55e7fa7cc191425b11 - https://git.kernel.org/stable/c/897f64b01c1249ac730329b83f4f40bab71e86c7 - https://git.kernel.org/stable/c/9dba9a45c348e8460da97c450cddf70b2056deb3
CVE ID: CVE-2025-39842 State: PUBLISHED Published: 2025-09-19T15:26:17.075Z Last Updated: 2025-11-03T17:43:57.858Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ocfs2: prevent release journal inode after journal shutdown Before calling ocfs2_delete_osb(), ocfs2_journal_shutdown() has already been executed in ocfs2_dismount_volume(), so osb->journal must be NULL. Therefore, the following calltrace will inevitably fail when it reaches jbd2_journal_release_jbd_inode(). ocfs2_dismount_volume()-> ocfs2_delete_osb()-> ocfs2_free_slot_info()-> __ocfs2_free_slot_info()-> evict()-> ocfs2_evict_inode()-> ocfs2_clear_inode()-> jbd2_journ
)-> ocfs2_free_slot_info()-> __ocfs2_free_slot_info()-> evict()-> ocfs2_evict_inode()-> ocfs2_clear_inode()-> jbd2_journal_release_jbd_inode(osb->journal->j_journal, Adding osb->journal checks will prevent null-ptr-deref during the above execution path. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/42c415c53ad2065088cc411d08925effa5b3d255 - https://git.kernel.org/stable/c/e9188f66e94955431ddbe2cd1cdf8ff2bb486abf - https://git.kernel.org/stable/c/f4a917e6cd6c798f7adf39907f117fc754db1283 - https://git.kernel.org/stable/c/85e66331b60601d903cceaf8c10a234db863cd78 - https://git.kernel.org/stable/c/f46e8ef8bb7b452584f2e75337b619ac51a7cadf
CVE ID: CVE-2025-39843 State: PUBLISHED Published: 2025-09-19T15:26:17.758Z Last Updated: 2025-11-03T17:43:58.958Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm: slub: avoid wake up kswapd in set_track_prepare set_track_prepare() can incur lock recursion. The issue is that it is called from hrtimer_start_range_ns holding the per_cpu(hrtimer_bases)[n].lock, but when enabled CONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare, and try to hold the per_cpu(hrtimer_bases)[n].lock. Avoid deadlock caused by implicitly waking up kswapd by passing in allocation flags, which do not contain __GFP_KSWAPD_RECLAIM in the
k caused by implicitly waking up kswapd by passing in allocation flags, which do not contain __GFP_KSWAPD_RECLAIM in the debug_objects_fill_pool() case. Inside stack depot they are processed by gfp_nested_mask(). Since ___slab_alloc() has preemption disabled, we mask out __GFP_DIRECT_RECLAIM from the flags there. The oops looks something like: BUG: spinlock recursion on CPU#3, swapper/3/0 lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3 Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT) Call trace: spin_bug+0x0 _raw_spin_lock_irqsave+0x80 hrtimer_try_to_cancel+0x94 task_contending+0x10c enqueue_dl_entity+0x2a4 dl_server_start+0x74 enqueue_t
ock_irqsave+0x80 hrtimer_try_to_cancel+0x94 task_contending+0x10c enqueue_dl_entity+0x2a4 dl_server_start+0x74 enqueue_task_fair+0x568 enqueue_task+0xac do_activate_task+0x14c ttwu_do_activate+0xcc try_to_wake_up+0x6c8 default_wake_function+0x20 autoremove_wake_function+0x1c __wake_up+0xac wakeup_kswapd+0x19c wake_all_kswapds+0x78 __alloc_pages_slowpath+0x1ac __alloc_pages_noprof+0x298 stack_depot_save_flags+0x6b0 stack_depot_save+0x14 set_track_prepare+0x5c ___slab_alloc+0xccc __kmalloc_cache_noprof+0x470 __set_page_owner+0x2bc post_alloc_hook[jt]+0x1b8 prep_new_page+0x28 get_page_from_freelist+0x1edc __alloc_pages_noprof+0x13c alloc_slab_page+0x244 allocate_slab+0x7c ___slab_alloc+0x8e8 km
get_page_from_freelist+0x1edc __alloc_pages_noprof+0x13c alloc_slab_page+0x244 allocate_slab+0x7c ___slab_alloc+0x8e8 kmem_cache_alloc_noprof+0x450 debug_objects_fill_pool+0x22c debug_object_activate+0x40 enqueue_hrtimer[jt]+0xdc hrtimer_start_range_ns+0x5f8 ... Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/994b03b9605d36d814c611385fbf90ca6db20aa8 - https://git.kernel.org/stable/c/522ffe298627cfe72539d72167c2e20e72b5e856 - https://git.kernel.org/stable/c/243b705a90ed8449f561a271cf251fd2e939f3db - https://git.kernel.org/stable/c/eb3240ffd243bfb8b1e9dc568d484ecf9fd660ab - https://git.kernel.org/stable/c/850470a8413a8a78e772c4f6bd9fe81ec6bd5b0f
CVE ID: CVE-2025-39844 State: PUBLISHED Published: 2025-09-19T15:26:18.471Z Last Updated: 2025-11-03T17:43:59.901Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm: move page table sync declarations to linux/pgtable.h During our internal testing, we started observing intermittent boot failures when the machine uses 4-level paging and has a large amount of persistent memory: BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: <TASK> __init_zone_
present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: <TASK> __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] </TASK> It turns out that the kernel panics while initializing vmemmap (struct page array) when the vmemmap region spans two PGD entries, because the new PGD entry is only installed in init_mm.pgd, but not in the page tables of other tasks. And looking at __populate_section_memmap(): if (vmemmap_can_optimize(altmap, pgmap)) // does not sync top level page tabl