Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
k_bg_unused(), or a different future user of bg_list, better to be safe than sorry. Otherwise we risk the following interleaving (bg_list refcount in parens) T1 (some random op) T2 (btrfs_mark_bg_unused) !list_empty(&bg->bg_list); (1) list_del_init(&bg->bg_list); (1) list_move_tail (1) btrfs_put_block_group (0) btrfs_delete_unused_bgs bg = list_first_entry list_del_init(&bg->bg_list); btrfs_put_block_group(bg); (-1) Ultimately, this results in a broken ref count that hits zero one deref early and the real final deref underflows the refcount, resulting in a WARNING. References: - https://git.kernel.org/stable/c/bf089c4d1141b27332c092b1dcca5022c415a3b6 - https://git.kernel.org/stable/c/909e60f
es: - https://git.kernel.org/stable/c/bf089c4d1141b27332c092b1dcca5022c415a3b6 - https://git.kernel.org/stable/c/909e60fb469d4101c6b08cf6e622efb062bb24a1 - https://git.kernel.org/stable/c/185fd73e5ac06027c4be9a129e59193f6a3ef202 - https://git.kernel.org/stable/c/7511e29cf1355b2c47d0effb39e463119913e2f6
CVE ID: CVE-2025-37857 State: PUBLISHED Published: 2025-05-09T06:42:05.258Z Last Updated: 2025-11-03T19:56:33.197Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: st: Fix array overflow in st_setup() Change the array size to follow parms size instead of a fixed value. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/736ae988bfb5932c05625baff70fba224d547c08 - https://git.kernel.org/stable/c/574b399a7fb6ae71c97e26d122205c4a720c0e43 - https://git.kernel.org/stable/c/c6015d0f7a2236ddb3928b2dfcb1c556a1368b55 - https://git.kernel.org/stable/c/f746fe0c51e044d1248dc67918328bfb3d86b63
ble/c/c6015d0f7a2236ddb3928b2dfcb1c556a1368b55 - https://git.kernel.org/stable/c/f746fe0c51e044d1248dc67918328bfb3d86b639 - https://git.kernel.org/stable/c/e4d1ca0a84a6650d3172eb8c07ef2fbc585b0d96 - https://git.kernel.org/stable/c/7fe3b4deed8b93609058c37c9a11df1d2b2c0423 - https://git.kernel.org/stable/c/e6b585d016c47ca8a37b92ea8a3fe35c0b585256 - https://git.kernel.org/stable/c/ad4c3037dc77739a625246a2a0fb23b8f3402c06 - https://git.kernel.org/stable/c/a018d1cf990d0c339fe0e29b762ea5dc10567d67
CVE ID: CVE-2025-37858 State: PUBLISHED Published: 2025-05-09T06:42:05.940Z Last Updated: 2025-11-03T19:56:35.947Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fs/jfs: Prevent integer overflow in AG size calculation The JFS filesystem calculates allocation group (AG) size using 1 << l2agsize in dbExtendFS(). When l2agsize exceeds 31 (possible with >2TB aggregates on 32-bit systems), this 32-bit shift operation causes undefined behavior and improper AG sizing. On 32-bit architectures: - Left-shifting 1 by 32+ bits results in 0 due to integer overflow - This creates invalid AG sizes (0 or garbage values) in sbi->bmap->db_agsize
bits results in 0 due to integer overflow - This creates invalid AG sizes (0 or garbage values) in sbi->bmap->db_agsize - Subsequent block allocations would reference invalid AG structures - Could lead to: - Filesystem corruption during extend operations - Kernel crashes due to invalid memory accesses - Security vulnerabilities via malformed on-disk structures Fix by casting to s64 before shifting: bmp->db_agsize = (s64)1 << l2agsize; This ensures 64-bit arithmetic even on 32-bit architectures. The cast matches the data type of db_agsize (s64) and follows similar patterns in JFS block calculation code. Found by Linux Verification Center (linuxtesting.org) with SVACE. Additional Analyst Note
in JFS block calculation code. Found by Linux Verification Center (linuxtesting.org) with SVACE. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/dd07a985e2ded47b6c7d69fc93c1fe02977c8454 - https://git.kernel.org/stable/c/8bb29629a5e4090e1ef7199cb42db04a52802239 - https://git.kernel.org/stable/c/3d8a45f87010a802aa214bf39702ca9d99cbf3ba - https://git.kernel.org/stable/c/55edbf5dbf60a8195c21e92124c4028939ae16b2 - https://git.kernel.org/stable/c/7ccf3b35274512b60ecb614e0637e76bd6f2d829 - https://git.kernel.org/stable/c/c802a6a4009f585111f903e810b3be9c6d0da329 - https://git.kernel.org/stable/c/211ed8f5e39e61f9e4d18edd64ce8005a67a1b2a - https://git.k
f585111f903e810b3be9c6d0da329 - https://git.kernel.org/stable/c/211ed8f5e39e61f9e4d18edd64ce8005a67a1b2a - https://git.kernel.org/stable/c/ec34cdf4f917cc6abd306cf091f8b8361fedac88 - https://git.kernel.org/stable/c/7fcbf789629cdb9fbf4e2172ce31136cfed11e5e
CVE ID: CVE-2025-37859 State: PUBLISHED Published: 2025-05-09T06:42:06.596Z Last Updated: 2025-11-03T19:56:38.707Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: page_pool: avoid infinite loop to schedule delayed worker We noticed the kworker in page_pool_release_retry() was waken up repeatedly and infinitely in production because of the buggy driver causing the inflight less than 0 and warning us in page_pool_inflight()[1]. Since the inflight value goes negative, it means we should not expect the whole page_pool to get back to work normally. This patch mitigates the adverse effect by not rescheduling the kworker when detecting
ool to get back to work normally. This patch mitigates the adverse effect by not rescheduling the kworker when detecting the inflight negative in page_pool_release_retry(). [1] [Mon Feb 10 20:36:11 2025] ------------[ cut here ]------------ [Mon Feb 10 20:36:11 2025] Negative(-51446) inflight packet-pages ... [Mon Feb 10 20:36:11 2025] Call Trace: [Mon Feb 10 20:36:11 2025] page_pool_release_retry+0x23/0x70 [Mon Feb 10 20:36:11 2025] process_one_work+0x1b1/0x370 [Mon Feb 10 20:36:11 2025] worker_thread+0x37/0x3a0 [Mon Feb 10 20:36:11 2025] kthread+0x11a/0x140 [Mon Feb 10 20:36:11 2025] ? process_one_work+0x370/0x370 [Mon Feb 10 20:36:11 2025] ? __kthread_cancel_work+0x40/0x40 [Mon Feb 10 20:
:36:11 2025] ? process_one_work+0x370/0x370 [Mon Feb 10 20:36:11 2025] ? __kthread_cancel_work+0x40/0x40 [Mon Feb 10 20:36:11 2025] ret_from_fork+0x35/0x40 [Mon Feb 10 20:36:11 2025] ---[ end trace ebffe800f33e7e34 ]--- Note: before this patch, the above calltrace would flood the dmesg due to repeated reschedule of release_dw kworker. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/c3c7c57017ce1d4b2d3788c1fc59e7e39026e158 - https://git.kernel.org/stable/c/9f71db4fb82deb889e0bac4a51b34daea7d506a3 - https://git.kernel.org/stable/c/91522aba56e9fcdf64da25ffef9b27f8fad48e0f - https://git.kernel.org/stable/c/90e089a64504982f8d62f223027cb9f903781f78
e/c/91522aba56e9fcdf64da25ffef9b27f8fad48e0f - https://git.kernel.org/stable/c/90e089a64504982f8d62f223027cb9f903781f78 - https://git.kernel.org/stable/c/95f17738b86fd198924d874a5639bcdc49c7e5b8 - https://git.kernel.org/stable/c/7204335d1991c23fc615ab76f31f175748a578e1 - https://git.kernel.org/stable/c/e74e5aa33228c5e2cb4fc80ad103541a7b7805ec - https://git.kernel.org/stable/c/738d1812ec2e395e953258aea912ddd867d11a13 - https://git.kernel.org/stable/c/43130d02baa137033c25297aaae95fd0edc41654
CVE ID: CVE-2025-37860 State: PUBLISHED Published: 2025-04-18T07:01:28.132Z Last Updated: 2025-11-02T13:30:36.755Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sfc: fix NULL dereferences in ef100_process_design_param() Since cited commit, ef100_probe_main() and hence also ef100_check_design_params() run before efx->net_dev is created; consequently, we cannot netif_set_tso_max_size() or _segs() at this point. Move those netif calls to ef100_probe_netdev(), and also replace netif_err within the design params code with pci_err. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/f2162
ode with pci_err. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/f21623b8446735b5e2ac5f8ee69b8743177d7b19 - https://git.kernel.org/stable/c/e56391011381d6d029da377a65ac314cb3d5def2 - https://git.kernel.org/stable/c/8241ecec1cdc6699ae197d52d58e76bddd995fa5
CVE ID: CVE-2025-37861 State: PUBLISHED Published: 2025-05-09T06:42:07.245Z Last Updated: 2025-05-26T05:22:30.734Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue When the task management thread processes reply queues while the reset thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset thread, which points to unallocated memory, causing a crash. Add flag 'io_admin_reset_sync' to synchronize access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to block I/O and adm
access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as unrecoverable. References: - https://git.kernel.org/stable/c/65ba18c84dbd03afe9b38c06c151239d97a09834 - https://git.kernel.org/stable/c/8d310d66e2b0f5f9f709764641647e8a3a4924fa - https://git.kernel.org/stable/c/75b67dca4195e11ccf966a704787b2aa2754a457 - https://git.kernel.org/stable/c/f195fc060c738d303a21fae146dbf85e1595fb4c
CVE ID: CVE-2025-37862 State: PUBLISHED Published: 2025-05-09T06:42:07.941Z Last Updated: 2025-11-03T19:56:41.456Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: HID: pidff: Fix null pointer dereference in pidff_find_fields This function triggered a null pointer dereference if used to search for a report that isn't implemented on the device. This happened both for optional and required reports alike. The same logic was applied to pidff_find_special_field and although pidff_init_fields should return an error earlier if one of the required reports is missing, future modifications could change this logic and resurface this possibl
rlier if one of the required reports is missing, future modifications could change this logic and resurface this possible null pointer dereference again. LKML bug report: https://lore.kernel.org/all/CAL-gK7f5=R0nrrQdPtaZZr1fd-cdAMbDMuZ_NLA8vM0SX+nGSw@mail.gmail.com Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/44a1b8b2027afbb37e418993fb23561bdb9efb38 - https://git.kernel.org/stable/c/d230becb9d38b7325c5c38d051693e4c26b1829b - https://git.kernel.org/stable/c/6b4449e4f03326fbd2136e67bfcc1e6ffe61541d - https://git.kernel.org/stable/c/ddb147885225d768025f6818df533d30edf3e102 - https://git.kernel.org/stable/c/be706a48bb7896d4130edc82811233d1d6215
table/c/ddb147885225d768025f6818df533d30edf3e102 - https://git.kernel.org/stable/c/be706a48bb7896d4130edc82811233d1d62158e7 - https://git.kernel.org/stable/c/f8f4d77710e1c38f4a2bd26c88c4878b5b5e817a - https://git.kernel.org/stable/c/3a507184f9307e19cb441b897c49e7843c94e56b - https://git.kernel.org/stable/c/e368698da79af821f18c099520deab1219c2044b - https://git.kernel.org/stable/c/22a05462c3d0eee15154faf8d13c49e6295270a5
CVE ID: CVE-2025-37863 State: PUBLISHED Published: 2025-05-09T06:43:54.250Z Last Updated: 2025-05-26T05:22:33.385Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ovl: don't allow datadir only In theory overlayfs could support upper layer directly referring to a data layer, but there's no current use case for this. Originally, when data-only layers were introduced, this wasn't allowed, only introduced by the "datadir+" feature, but without actually handling this case, resulting in an Oops. Fix by disallowing datadir without lowerdir. References: - https://git.kernel.org/stable/c/0874b629f65320778e7e3e206177770666d9db18 - https:/
tadir without lowerdir. References: - https://git.kernel.org/stable/c/0874b629f65320778e7e3e206177770666d9db18 - https://git.kernel.org/stable/c/b9e3579213ba648fa23f780e8d53e99011c62331 - https://git.kernel.org/stable/c/21d2ffb0e9838a175064c22f3a9de97d1f56f27d - https://git.kernel.org/stable/c/eb3a04a8516ee9b5174379306f94279fc90424c4
CVE ID: CVE-2025-37864 State: PUBLISHED Published: 2025-05-09T06:43:54.873Z Last Updated: 2025-05-26T05:22:34.722Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: dsa: clean up FDB, MDB, VLAN entries on unbind As explained in many places such as commit b117e1e8a86d ("net: dsa: delete dsa_legacy_fdb_add and dsa_legacy_fdb_del"), DSA is written given the assumption that higher layers have balanced additions/deletions. As such, it only makes sense to be extremely vocal when those assumptions are violated and the driver unbinds with entries still present. But Ido Schimmel points out a very simple situation where that is wrong:
the driver unbinds with entries still present. But Ido Schimmel points out a very simple situation where that is wrong: https://lore.kernel.org/netdev/ZDazSM5UsPPjQuKr@shredder/ (also briefly discussed by me in the aforementioned commit). Basically, while the bridge bypass operations are not something that DSA explicitly documents, and for the majority of DSA drivers this API simply causes them to go to promiscuous mode, that isn't the case for all drivers. Some have the necessary requirements for bridge bypass operations to do something useful - see dsa_switch_supports_uc_filtering(). Although in tools/testing/selftests/net/forwarding/local_termination.sh, we made an effort to popularize be
filtering(). Although in tools/testing/selftests/net/forwarding/local_termination.sh, we made an effort to popularize better mechanisms to manage address filters on DSA interfaces from user space - namely macvlan for unicast, and setsockopt(IP_ADD_MEMBERSHIP) - through mtools - for multicast, the fact is that 'bridge fdb add ... self static local' also exists as kernel UAPI, and might be useful to someone, even if only for a quick hack. It seems counter-productive to block that path by implementing shim .ndo_fdb_add and .ndo_fdb_del operations which just return -EOPNOTSUPP in order to prevent the ndo_dflt_fdb_add() and ndo_dflt_fdb_del() from running, although we could do that. Accepting tha
in order to prevent the ndo_dflt_fdb_add() and ndo_dflt_fdb_del() from running, although we could do that. Accepting that cleanup is necessary seems to be the only option. Especially since we appear to be coming back at this from a different angle as well. Russell King is noticing that the WARN_ON() triggers even for VLANs: https://lore.kernel.org/netdev/Z_li8Bj8bD4-BYKQ@shell.armlinux.org.uk/ What happens in the bug report above is that dsa_port_do_vlan_del() fails, then the VLAN entry lingers on, and then we warn on unbind and leak it. This is not a straight revert of the blamed commit, but we now add an informational print to the kernel log (to still have a way to see that bugs exist), an
blamed commit, but we now add an informational print to the kernel log (to still have a way to see that bugs exist), and some extra comments gathered from past years' experience, to justify the logic. References: - https://git.kernel.org/stable/c/86c6613a69bca815f1865ed8cedfd4b9142621ab - https://git.kernel.org/stable/c/8fcc1e6f808912977caf17366c625b95dc29ba4f - https://git.kernel.org/stable/c/99c50c98803425378e08a7394dc885506dc85f06 - https://git.kernel.org/stable/c/7afb5fb42d4950f33af2732b8147c552659f79b7
CVE ID: CVE-2025-37865 State: PUBLISHED Published: 2025-05-09T06:43:55.486Z Last Updated: 2025-11-03T19:56:42.851Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: fix -ENOENT when deleting VLANs and MST is unsupported Russell King reports that on the ZII dev rev B, deleting a bridge VLAN from a user port fails with -ENOENT: https://lore.kernel.org/netdev/Z_lQXNP0s5-IiJzd@shell.armlinux.org.uk/ This comes from mv88e6xxx_port_vlan_leave() -> mv88e6xxx_mst_put(), which tries to find an MST entry in &chip->msts associated with the SID, but fails and returns -ENOENT as such. But we know that this chip does not su
ry in &chip->msts associated with the SID, but fails and returns -ENOENT as such. But we know that this chip does not support MST at all, so that is not surprising. The question is why does the guard in mv88e6xxx_mst_put() not exit early: if (!sid) return 0; And the answer seems to be simple: the sid comes from vlan.sid which supposedly was previously populated by mv88e6xxx_vtu_get(). But some chip->info->ops->vtu_getnext() implementations do not populate vlan.sid, for example see mv88e6185_g1_vtu_getnext(). In that case, later in mv88e6xxx_port_vlan_leave() we are using a garbage sid which is just residual stack memory. Testing for sid == 0 covers all cases of a non-bridge VLAN or a bridge
garbage sid which is just residual stack memory. Testing for sid == 0 covers all cases of a non-bridge VLAN or a bridge VLAN mapped to the default MSTI. For some chips, SID 0 is valid and installed by mv88e6xxx_stu_setup(). A chip which does not support the STU would implicitly only support mapping all VLANs to the default MSTI, so although SID 0 is not valid, it would be sufficient, if we were to zero-initialize the vlan structure, to fix the bug, due to the coincidence that a test for vlan.sid == 0 already exists and leads to the same (correct) behavior. Another option which would be sufficient would be to add a test for mv88e6xxx_has_stu() inside mv88e6xxx_mst_put(), symmetric to the one
ich would be sufficient would be to add a test for mv88e6xxx_has_stu() inside mv88e6xxx_mst_put(), symmetric to the one which already exists in mv88e6xxx_mst_get(). But that placement means the caller will have to dereference vlan.sid, which means it will access uninitialized memory, which is not nice even if it ignores it later. So we end up making both modifications, in order to not rely just on the sid == 0 coincidence, but also to avoid having uninitialized structure fields which might get temporarily accessed. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/35cde75c08a1fa1a5ac0467afe2709caceeef002 - https://git.kernel.org/stable/c/afae908
es: - https://git.kernel.org/stable/c/35cde75c08a1fa1a5ac0467afe2709caceeef002 - https://git.kernel.org/stable/c/afae9087301471970254a9180e5a26d3d8e8af09 - https://git.kernel.org/stable/c/9ee6d3a368ed34f2457863da3085c676e9e37a3d - https://git.kernel.org/stable/c/9da4acbd60664271d34a627f7f63cd5bad8eba74 - https://git.kernel.org/stable/c/ea08dfc35f83cfc73493c52f63ae4f2e29edfe8d
CVE ID: CVE-2025-37866 State: PUBLISHED Published: 2025-05-09T06:43:56.128Z Last Updated: 2025-05-26T05:22:37.272Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mlxbf-bootctl: use sysfs_emit_at() in secure_boot_fuse_state_show() A warning is seen when running the latest kernel on a BlueField SOC: [251.512704] ------------[ cut here ]------------ [251.512711] invalid sysfs_emit: buf:0000000003aa32ae [251.512720] WARNING: CPU: 1 PID: 705264 at fs/sysfs/file.c:767 sysfs_emit+0xac/0xc8 The warning is triggered because the mlxbf-bootctl driver invokes "sysfs_emit()" with a buffer pointer that is not aligned to the start of the page
cause the mlxbf-bootctl driver invokes "sysfs_emit()" with a buffer pointer that is not aligned to the start of the page. The driver should instead use "sysfs_emit_at()" to support non-zero offsets into the destination buffer. References: - https://git.kernel.org/stable/c/5e1dcc5bfd7a2896178c604bc69d6ab9650967da - https://git.kernel.org/stable/c/b129005ddfc0e6daf04a6d3b928a9e474f9b3918
CVE ID: CVE-2025-37867 State: PUBLISHED Published: 2025-05-09T06:43:56.749Z Last Updated: 2025-11-03T19:56:45.599Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Silence oversized kvmalloc() warning syzkaller triggered an oversized kvmalloc() warning. Silence it by adding __GFP_NOWARN. syzkaller log: WARNING: CPU: 7 PID: 518 at mm/util.c:665 __kvmalloc_node_noprof+0x175/0x180 CPU: 7 UID: 0 PID: 518 Comm: c_repro Not tainted 6.11.0-rc6+ #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__kvmalloc_node_noprof+0x175/0x180 RSP: 0018:ffffc90001
el-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__kvmalloc_node_noprof+0x175/0x180 RSP: 0018:ffffc90001e67c10 EFLAGS: 00010246 RAX: 0000000000000100 RBX: 0000000000000400 RCX: ffffffff8149d46b RDX: 0000000000000000 RSI: ffff8881030fae80 RDI: 0000000000000002 RBP: 000000712c800000 R08: 0000000000000100 R09: 0000000000000000 R10: ffffc90001e67c10 R11: 0030ae0601000000 R12: 0000000000000000 R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000 FS: 00007fde79159740(0000) GS:ffff88813bdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000180 CR3: 0000000105eb4005 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 00000000
: 0000000080050033 CR2: 0000000020000180 CR3: 0000000105eb4005 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ib_umem_odp_get+0x1f6/0x390 mlx5_ib_reg_user_mr+0x1e8/0x450 ib_uverbs_reg_mr+0x28b/0x440 ib_uverbs_write+0x7d3/0xa30 vfs_write+0x1ac/0x6c0 ksys_write+0x134/0x170 ? __sanitizer_cov_trace_pc+0x1c/0x50 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/f94ac90ce7bd6f9266ad0d99044ed86e8d1416c1 - https://git.kernel.org/stable/c/791daf8240cedf27af8794038ae
rnel.org/stable/c/f94ac90ce7bd6f9266ad0d99044ed86e8d1416c1 - https://git.kernel.org/stable/c/791daf8240cedf27af8794038ae1d32ef643bce6 - https://git.kernel.org/stable/c/6c588e9afbab240c921f936cb676dac72e2e2b66 - https://git.kernel.org/stable/c/ae470d06320dea4002d441784d691f0a26b4322d - https://git.kernel.org/stable/c/0d81bb58a203ad5f4044dc18cfbc230c194f650a - https://git.kernel.org/stable/c/f476eba25fdf70faa7b19a3e0fb00e65c5b53106 - https://git.kernel.org/stable/c/9a0e6f15029e1a8a21e40f06fd05aa52b7f063de
CVE ID: CVE-2025-37868 State: PUBLISHED Published: 2025-05-09T06:43:57.383Z Last Updated: 2025-05-26T05:22:39.786Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/xe/userptr: fix notifier vs folio deadlock User is reporting what smells like notifier vs folio deadlock, where migrate_pages_batch() on core kernel side is holding folio lock(s) and then interacting with the mappings of it, however those mappings are tied to some userptr, which means calling into the notifier callback and grabbing the notifier lock. With perfect timing it looks possible that the pages we pulled from the hmm fault can get sniped by migrate_pages_ba
ck. With perfect timing it looks possible that the pages we pulled from the hmm fault can get sniped by migrate_pages_batch() at the same time that we are holding the notifier lock to mark the pages as accessed/dirty, but at this point we also want to grab the folio locks(s) to mark them as dirty, but if they are contended from notifier/migrate_pages_batch side then we deadlock since folio lock won't be dropped until we drop the notifier lock. Fortunately the mark_page_accessed/dirty is not really needed in the first place it seems and should have already been done by hmm fault, so just remove it. (cherry picked from commit bd7c0cb695e87c0e43247be8196b4919edbe0e85) References: - https://git.
ault, so just remove it. (cherry picked from commit bd7c0cb695e87c0e43247be8196b4919edbe0e85) References: - https://git.kernel.org/stable/c/65dc4e3d5b01db0179fc95c1f0bdb87194c28ab5 - https://git.kernel.org/stable/c/90574ecf6052be83971d91d16600c5cf07003bbb - https://git.kernel.org/stable/c/2577b202458cddff85cc154b1fe7f313e0d1f418