Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-39962 State: PUBLISHED Published: 2025-10-09T12:13:22.684Z Last Updated: 2025-10-09T12:13:22.684Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix untrusted unsigned subtract Fix the following Smatch static checker warning: net/rxrpc/rxgk_app.c:65 rxgk_yfs_decode_ticket() warn: untrusted unsigned subtract. 'ticket_len - 10 * 4' by prechecking the length of what we're trying to extract in two places in the token and decoding for a response packet. Also use sizeof() on the struct we're extracting rather specifying the size numerically to be consistent with the other related statements. References: - http
extracting rather specifying the size numerically to be consistent with the other related statements. References: - https://git.kernel.org/stable/c/71571e187106631a8127f2dde780f35caa358d33 - https://git.kernel.org/stable/c/2429a197648178cd4dc930a9d87c13c547460564
CVE ID: CVE-2025-39963 State: PUBLISHED Published: 2025-10-09T12:13:23.345Z Last Updated: 2025-10-09T12:13:23.345Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: io_uring: fix incorrect io_kiocb reference in io_link_skb In io_link_skb function, there is a bug where prev_notif is incorrectly assigned using 'nd' instead of 'prev_nd'. This causes the context validation check to compare the current notification with itself instead of comparing it with the previous notification. Fix by using the correct prev_nd parameter when obtaining prev_notif. References: - https://git.kernel.org/stable/c/a89c34babc2e5834aa0905278f26f4dbe4b26b76
ameter when obtaining prev_notif. References: - https://git.kernel.org/stable/c/a89c34babc2e5834aa0905278f26f4dbe4b26b76 - https://git.kernel.org/stable/c/50a98ce1ea694f1ff8e87bc2f8f84096d1736f6a - https://git.kernel.org/stable/c/2c139a47eff8de24e3350dadb4c9d5e3426db826
CVE ID: CVE-2025-39964 State: PUBLISHED Published: 2025-10-13T13:48:30.334Z Last Updated: 2025-10-13T13:48:30.334Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg Issuing two writes to the same af_alg socket is bogus as the data will be interleaved in an unpredictable fashion. Furthermore, concurrent writes may create inconsistencies in the internal socket state. Disallow this by adding a new ctx->write field that indiciates exclusive ownership for writing. References: - https://git.kernel.org/stable/c/0f28c4adbc4a97437874c9b669fd7958a8c6d6ce - https://git.kernel.org/
riting. References: - https://git.kernel.org/stable/c/0f28c4adbc4a97437874c9b669fd7958a8c6d6ce - https://git.kernel.org/stable/c/e4c1ec11132ec466f7362a95f36a506ce4dc08c9 - https://git.kernel.org/stable/c/1f323a48e9b5ebfe6dc7d130fdf5c3c0e92a07c8 - https://git.kernel.org/stable/c/7c4491b5644e3a3708f3dbd7591be0a570135b84 - https://git.kernel.org/stable/c/9aee87da5572b3a14075f501752e209801160d3d - https://git.kernel.org/stable/c/45bcf60fe49b37daab1acee57b27211ad1574042 - https://git.kernel.org/stable/c/1b34cbbf4f011a121ef7b2d7d6e6920a036d5285
CVE ID: CVE-2025-39965 State: PUBLISHED Published: 2025-10-13T13:48:31.033Z Last Updated: 2025-10-13T13:48:31.033Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: xfrm: xfrm_alloc_spi shouldn't use 0 as SPI x->id.spi == 0 means "no SPI assigned", but since commit 94f39804d891 ("xfrm: Duplicate SPI Handling"), we now create states and add them to the byspi list with this value. __xfrm_state_delete doesn't remove those states from the byspi list, since they shouldn't be there, and this shows up as a UAF the next time we go through the byspi list. References: - https://git.kernel.org/stable/c/0baf92d0b1590b903c1f4ead75e61715e50e814
time we go through the byspi list. References: - https://git.kernel.org/stable/c/0baf92d0b1590b903c1f4ead75e61715e50e8146 - https://git.kernel.org/stable/c/9fcedabaae0096f712bbb4ccca6a8538af1cd1c8 - https://git.kernel.org/stable/c/a78e55776522373c446f18d5002a8de4b09e6bf7 - https://git.kernel.org/stable/c/cd8ae32e4e4652db55bce6b9c79267d8946765a9
CVE ID: CVE-2025-39966 State: PUBLISHED Published: 2025-10-15T07:55:50.843Z Last Updated: 2025-10-15T07:55:50.843Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iommufd: Fix race during abort for file descriptors fput() doesn't actually call file_operations release() synchronously, it puts the file on a work queue and it will be released eventually. This is normally fine, except for iommufd the file and the iommufd_object are tied to gether. The file has the object as it's private_data and holds a users refcount, while the object is expected to remain alive as long as the file is. When the allocation of a new object aborts bef
unt, while the object is expected to remain alive as long as the file is. When the allocation of a new object aborts before installing the file it will fput() the file and then go on to immediately kfree() the obj. This causes a UAF once the workqueue completes the fput() and tries to decrement the users refcount. Fix this by putting the core code in charge of the file lifetime, and call __fput_sync() during abort to ensure that release() is called before kfree. __fput_sync() is a bit too tricky to open code in all the object implementations. Instead the objects tell the core code where the file pointer is and the core will take care of the life cycle. If the object is successfully allocated
re code where the file pointer is and the core will take care of the life cycle. If the object is successfully allocated then the file will hold a users refcount and the iommufd_object cannot be destroyed. It is worth noting that close(); ioctl(IOMMU_DESTROY); doesn't have an issue because close() is already using a synchronous version of fput(). The UAF looks like this: BUG: KASAN: slab-use-after-free in iommufd_eventq_fops_release+0x45/0xc0 drivers/iommu/iommufd/eventq.c:376 Write of size 4 at addr ffff888059c97804 by task syz.0.46/6164 CPU: 0 UID: 0 PID: 6164 Comm: syz.0.46 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Googl
.46 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcd/0x630 mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0x100/0x1b0 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:400 [inline] __refcount_dec include/linux/refcount.h:455 [inline]
ub_release include/linux/atomic/atomic-instrumented.h:400 [inline] __refcount_dec include/linux/refcount.h:455 [inline] refcount_dec include/linux/refcount.h:476 [inline] iommufd_eventq_fops_release+0x45/0xc0 drivers/iommu/iommufd/eventq.c:376 __fput+0x402/0xb70 fs/file_table.c:468 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x41c/0x4c0 arc
-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x41c/0x4c0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f References: - https://git.kernel.org/stable/c/17195a7d754a5c6a31888702ca93f6f08f3383ad - https://git.kernel.org/stable/c/e4825368285e33d6360c6c6a6a10d2d83da06e55 - https://git.kernel.org/stable/c/4e034bf045b12852a24d5d33f2451850818ba0c1
CVE ID: CVE-2025-39967 State: PUBLISHED Published: 2025-10-15T07:55:51.554Z Last Updated: 2025-10-15T07:55:51.554Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fbcon: fix integer overflow in fbcon_do_set_font Fix integer overflow vulnerabilities in fbcon_do_set_font() where font size calculations could overflow when handling user-controlled font parameters. The vulnerabilities occur when: 1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount multiplication with user-controlled values that can overflow. 2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow 3. This results in smaller allocations than e
rflow. 2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow 3. This results in smaller allocations than expected, leading to buffer overflows during font data copying. Add explicit overflow checking using check_mul_overflow() and check_add_overflow() kernel helpers to safety validate all size calculations before allocation. References: - https://git.kernel.org/stable/c/994bdc2d23c79087fbf7dcd9544454e8ebcef877 - https://git.kernel.org/stable/c/9c8ec14075c5317edd6b242f1be8167aa1e4e333 - https://git.kernel.org/stable/c/b8a6e85328aeb9881531dbe89bcd2637a06c3c95 - https://git.kernel.org/stable/c/a6eb9f423b3db000aaedf83367b8539f6b72dcfc - https://git.kernel.org/stable/c/adac90bb1aaf4
https://git.kernel.org/stable/c/a6eb9f423b3db000aaedf83367b8539f6b72dcfc - https://git.kernel.org/stable/c/adac90bb1aaf45ca66f9db8ac100be16750ace78 - https://git.kernel.org/stable/c/4a4bac869560f943edbe3c2b032062f6673b13d3 - https://git.kernel.org/stable/c/c0c01f9aa08c8e10e10e8c9ebb5be01a4eff6eb7 - https://git.kernel.org/stable/c/1a194e6c8e1ee745e914b0b7f50fa86c89ed13fe
CVE ID: CVE-2025-39968 State: PUBLISHED Published: 2025-10-15T07:55:52.272Z Last Updated: 2025-10-15T07:55:52.272Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: i40e: add max boundary check for VF filters There is no check for max filters that VF can request. Add it. References: - https://git.kernel.org/stable/c/9176e18681cb0d34c5acc87bda224f5652af2ab8 - https://git.kernel.org/stable/c/e490d8c5a54e0dd1ab22417d72c3a7319cf0f030 - https://git.kernel.org/stable/c/77a35be582dff4c80442ebcdce24d45eed8a6ce4 - https://git.kernel.org/stable/c/02aae5fcdd34c3a55a243d80a1b328a35852a35c - https://git.kernel.org/stable/c/edecce7abd7152b48e27
/git.kernel.org/stable/c/02aae5fcdd34c3a55a243d80a1b328a35852a35c - https://git.kernel.org/stable/c/edecce7abd7152b48e279b4fa0a883d1839bb577 - https://git.kernel.org/stable/c/d33e5d6631ac4fddda235a7815babc9d3f124299 - https://git.kernel.org/stable/c/8b13df5aa877b9e4541e301a58a84c42d84d2d9a - https://git.kernel.org/stable/c/cb79fa7118c150c3c76a327894bb2eb878c02619
CVE ID: CVE-2025-39969 State: PUBLISHED Published: 2025-10-15T07:55:52.948Z Last Updated: 2025-10-15T07:55:52.948Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: i40e: fix validation of VF state in get resources VF state I40E_VF_STATE_ACTIVE is not the only state in which VF is actually active so it should not be used to determine if a VF is allowed to obtain resources. Use I40E_VF_STATE_RESOURCES_LOADED that is set only in i40e_vc_get_vf_resources_msg() and cleared during reset. References: - https://git.kernel.org/stable/c/185745d56ec958bf8aa773828213237dfcc32f5a - https://git.kernel.org/stable/c/f47876788a23de296c42ef9d505b5
el.org/stable/c/185745d56ec958bf8aa773828213237dfcc32f5a - https://git.kernel.org/stable/c/f47876788a23de296c42ef9d505b5c1630f0b4b8 - https://git.kernel.org/stable/c/8e35c80f8570426fe0f0cc92b151ebd835975f22 - https://git.kernel.org/stable/c/6c3981fd59ef11a75005ac9978f034da5a168b6a - https://git.kernel.org/stable/c/e748f1ee493f88e38b77363a60499f979d42c58a - https://git.kernel.org/stable/c/6128bbc7adc25c87c2f64b5eb66a280b78ef7ab7 - https://git.kernel.org/stable/c/a991dc56d3e9a2c3db87d0c3f03c24f6595400f1 - https://git.kernel.org/stable/c/877b7e6ffc23766448236e8732254534c518ba42
CVE ID: CVE-2025-39970 State: PUBLISHED Published: 2025-10-15T07:55:53.610Z Last Updated: 2025-10-15T07:55:53.610Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: i40e: fix input validation logic for action_meta Fix condition to check 'greater or equal' to prevent OOB dereference. References: - https://git.kernel.org/stable/c/a88c1b2746eccf00e2094b187945f0f1e990b400 - https://git.kernel.org/stable/c/28465770ca3b694286ff9ed6dfd558413f57d98f - https://git.kernel.org/stable/c/f8c8e11825b24661596fa8db2f0981ba17ed0817 - https://git.kernel.org/stable/c/461e0917eedcd159d87f3ea846754a1e07d7e78a - https://git.kernel.org/stable/c/3883e970
17 - https://git.kernel.org/stable/c/461e0917eedcd159d87f3ea846754a1e07d7e78a - https://git.kernel.org/stable/c/3883e9702b6a4945e93b16c070f338a9f5b496f9 - https://git.kernel.org/stable/c/3118f41d8fa57b005f53ec3db2ba5eab1d7ba12b - https://git.kernel.org/stable/c/560e1683410585fbd5df847f43433c4296f0d222 - https://git.kernel.org/stable/c/9739d5830497812b0bdeaee356ddefbe60830b88
CVE ID: CVE-2025-39971 State: PUBLISHED Published: 2025-10-15T07:55:54.270Z Last Updated: 2025-10-15T07:55:54.270Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in config queues msg Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40e_vc_config_queues_msg(). References: - https://git.kernel.org/stable/c/a6ff2af78343eceb0f77ab1a2fe802183bc21648 - https://git.kernel.org/stable/c/f5f91d164af22e7147130ef8bebbdb28d8ecc6e2 - https://git.kernel.org/stable/c/1fa0aadade34481c567cdf4a897c0d4e4d548bd1 - https://git.kernel.org/stable/c/8b9c7719b0987b1c6c5fc910599f3618a558dbd
ble/c/1fa0aadade34481c567cdf4a897c0d4e4d548bd1 - https://git.kernel.org/stable/c/8b9c7719b0987b1c6c5fc910599f3618a558dbde - https://git.kernel.org/stable/c/2cc26dac0518d2fa9b67ec813ee60e183480f98a - https://git.kernel.org/stable/c/bfcc1dff429d4b99ba03e40ddacc68ea4be2b32b - https://git.kernel.org/stable/c/5c1f96123113e0bdc6d8dc2b0830184c93da9f65 - https://git.kernel.org/stable/c/f1ad24c5abe1eaef69158bac1405a74b3c365115
CVE ID: CVE-2025-39972 State: PUBLISHED Published: 2025-10-15T07:55:54.929Z Last Updated: 2025-10-15T07:55:54.929Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in i40e_validate_queue_map Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40e_validate_queue_map(). References: - https://git.kernel.org/stable/c/b6cb93a7ff208f324c7ec581d72995f80e115e0e - https://git.kernel.org/stable/c/6f15a7b34fae75e745bdc2ec05e06ddfd0dd2f3c - https://git.kernel.org/stable/c/34dfac0c904829967d500c51f216916ce1452957 - https://git.kernel.org/stable/c/4d5e804a9e19b639b18fd13664dbad3c03c
/stable/c/34dfac0c904829967d500c51f216916ce1452957 - https://git.kernel.org/stable/c/4d5e804a9e19b639b18fd13664dbad3c03c79e61 - https://git.kernel.org/stable/c/50a1e2f50f6c22b93b94eb8d168a1be3c05bf5cd - https://git.kernel.org/stable/c/cc4191e8ef40d2249c1b9a8617d22ec8a976b574 - https://git.kernel.org/stable/c/d4e3eaaa3cb3af77836d806c89cd6ebf533a7320 - https://git.kernel.org/stable/c/aa68d3c3ac8d1dcec40d52ae27e39f6d32207009
CVE ID: CVE-2025-39973 State: PUBLISHED Published: 2025-10-15T07:55:55.590Z Last Updated: 2025-10-15T07:55:55.590Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: i40e: add validation for ring_len param The `ring_len` parameter provided by the virtual function (VF) is assigned directly to the hardware memory context (HMC) without any validation. To address this, introduce an upper boundary check for both Tx and Rx queue lengths. The maximum number of descriptors supported by the hardware is 8k-32. Additionally, enforce alignment constraints: Tx rings must be a multiple of 8, and Rx rings must be a multiple of 32. References: - h
enforce alignment constraints: Tx rings must be a multiple of 8, and Rx rings must be a multiple of 32. References: - https://git.kernel.org/stable/c/0543d40d6513cdf1c7882811086e59a6455dfe97 - https://git.kernel.org/stable/c/7d749e38dd2b7e8a80da2ca30c93e09de95bfcf9 - https://git.kernel.org/stable/c/45a7527cd7da4cdcf3b06b5c0cb1cae30b5a5985 - https://git.kernel.org/stable/c/d3b0d3f8d11fa957171fbb186e53998361a88d4e - https://git.kernel.org/stable/c/c0c83f4cd074b75cecef107bfc349be7d516c9c4 - https://git.kernel.org/stable/c/05fe81fb9db20464fa532a3835dc8300d68a2f84 - https://git.kernel.org/stable/c/afec12adab55d10708179a64d95d650741e60fe0 - https://git.kernel.org/stable/c/55d225670def06b01af2e7a5
.kernel.org/stable/c/afec12adab55d10708179a64d95d650741e60fe0 - https://git.kernel.org/stable/c/55d225670def06b01af2e7a5e0446fbe946289e8
CVE ID: CVE-2025-39974 State: PUBLISHED Published: 2025-10-15T07:55:56.275Z Last Updated: 2025-10-15T07:55:56.275Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing/osnoise: Fix slab-out-of-bounds in _parse_integer_limit() When config osnoise cpus by write() syscall, the following KASAN splat may be observed: BUG: KASAN: slab-out-of-bounds in _parse_integer_limit+0x103/0x130 Read of size 1 at addr ffff88810121e3a1 by task test/447 CPU: 1 UID: 0 PID: 447 Comm: test Not tainted 6.17.0-rc6-dirty #288 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dump_stac
(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x55/0x70 print_report+0xcb/0x610 kasan_report+0xb8/0xf0 _parse_integer_limit+0x103/0x130 bitmap_parselist+0x16d/0x6f0 osnoise_cpus_write+0x116/0x2d0 vfs_write+0x21e/0xcc0 ksys_write+0xee/0x1c0 do_syscall_64+0xa8/0x2a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> This issue can be reproduced by below code: const char *cpulist = "1"; int fd=open("/sys/kernel/debug/tracing/osnoise/cpus", O_WRONLY); write(fd, cpulist, strlen(cpulist)); Function bitmap_parselist() was called to parse cpulist, it require that the parameter 'buf' must be terminated with a '\0' or '\n'.
ap_parselist() was called to parse cpulist, it require that the parameter 'buf' must be terminated with a '\0' or '\n'. Fix this issue by adding a '\0' to 'buf' in osnoise_cpus_write(). References: - https://git.kernel.org/stable/c/930cb05a9e107777316b3ccf37f9556366669065 - https://git.kernel.org/stable/c/a2501032de0d1bc7971b2e43c03da534ac10ee9b
CVE ID: CVE-2025-39975 State: PUBLISHED Published: 2025-10-15T07:55:56.951Z Last Updated: 2025-10-15T07:55:56.951Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: smb: client: fix wrong index reference in smb2_compound_op() In smb2_compound_op(), the loop that processes each command's response uses wrong indices when accessing response bufferes. This incorrect indexing leads to improper handling of command results. Also, if incorrectly computed index is greather than or equal to MAX_COMPOUND, it can cause out-of-bounds accesses. References: - https://git.kernel.org/stable/c/ba7bcfd52c66dd1c2dfa5142aca7e4a70b62dfa5 - https://git.
f-bounds accesses. References: - https://git.kernel.org/stable/c/ba7bcfd52c66dd1c2dfa5142aca7e4a70b62dfa5 - https://git.kernel.org/stable/c/bfb1e2aad1fecef8320fd71332acde0d53a8d699 - https://git.kernel.org/stable/c/093615fc76063ea08d454ba86677ce64c736e806 - https://git.kernel.org/stable/c/fbe2dc6a9c7318f7263f5e4d50f6272b931c5756
CVE ID: CVE-2025-39976 State: PUBLISHED Published: 2025-10-15T07:55:57.608Z Last Updated: 2025-10-15T07:55:57.608Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: futex: Use correct exit on failure from futex_hash_allocate_default() copy_process() uses the wrong error exit path from futex_hash_allocate_default(). After exiting from futex_hash_allocate_default(), neither tasklist_lock nor siglock has been acquired. The exit label bad_fork_core_free unlocks both of these locks which is wrong. The next exit label, bad_fork_cancel_cgroup, is the correct exit. sched_cgroup_fork() did not allocate any resources that need to freed. Use
bad_fork_cancel_cgroup, is the correct exit. sched_cgroup_fork() did not allocate any resources that need to freed. Use bad_fork_cancel_cgroup on error exit from futex_hash_allocate_default(). References: - https://git.kernel.org/stable/c/f1635765cd0fdbf27b04d9a50be91a01b5adda13 - https://git.kernel.org/stable/c/4ec3c15462b9f44562f45723a92e2807746ba7d1
CVE ID: CVE-2025-39977 State: PUBLISHED Published: 2025-10-15T07:55:58.283Z Last Updated: 2025-10-15T07:55:58.283Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: futex: Prevent use-after-free during requeue-PI syzbot managed to trigger the following race: T1 T2 futex_wait_requeue_pi() futex_do_wait() schedule() futex_requeue() futex_proxy_trylock_atomic() futex_requeue_pi_prepare() requeue_pi_wake_futex() futex_requeue_pi_complete() /* preempt */ * timeout/ signal wakes T1 * futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED futex_hash_put() // back to userland, on stack futex_q is garbage /* back */ wake_up_state(q->task, T
_REQUEUE_PI_LOCKED futex_hash_put() // back to userland, on stack futex_q is garbage /* back */ wake_up_state(q->task, TASK_NORMAL); In this scenario futex_wait_requeue_pi() is able to leave without using futex_q::lock_ptr for synchronization. This can be prevented by reading futex_q::task before updating the futex_q::requeue_state. A reference on the task_struct is not needed because requeue_pi_wake_futex() is invoked with a spinlock_t held which implies a RCU read section. Even if T1 terminates immediately after, the task_struct will remain valid during T2's wake_up_state(). A READ_ONCE on futex_q::task before futex_requeue_pi_complete() is enough because it ensures that the variable is re
(). A READ_ONCE on futex_q::task before futex_requeue_pi_complete() is enough because it ensures that the variable is read before the state is updated. Read futex_q::task before updating the requeue state, use it for the following wakeup. References: - https://git.kernel.org/stable/c/cb5d19a61274b51b49601214a87af573b43d60fa - https://git.kernel.org/stable/c/348736955ed6ca6e99ca24b93b1d3fbfe352c181 - https://git.kernel.org/stable/c/a170b9c0dde83312b8b58ccc91509c7c15711641 - https://git.kernel.org/stable/c/d824b2dbdcfe3c390278dd9652ea526168ef6850 - https://git.kernel.org/stable/c/b549113738e8c751b613118032a724b772aa83f2
CVE ID: CVE-2025-39978 State: PUBLISHED Published: 2025-10-15T07:55:58.949Z Last Updated: 2025-10-15T07:55:58.949Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix potential use after free in otx2_tc_add_flow() This code calls kfree_rcu(new_node, rcu) and then dereferences "new_node" and then dereferences it on the next line. Two lines later, we take a mutex so I don't think this is an RCU safe region. Re-order it to do the dereferences before queuing up the free. References: - https://git.kernel.org/stable/c/5723120423a753a220b8b2954b273838b9d7e74a - https://git.kernel.org/stable/c/df2c071061ed52d2225d97b212d27
el.org/stable/c/5723120423a753a220b8b2954b273838b9d7e74a - https://git.kernel.org/stable/c/df2c071061ed52d2225d97b212d27ecedf456b8a - https://git.kernel.org/stable/c/c41b2941a024d4ec7c768e16ffb10a74b188fced - https://git.kernel.org/stable/c/a8a63f27c3a8a3714210d32b12fd0f16d0337414 - https://git.kernel.org/stable/c/d9c70e93ec5988ab07ad2a92d9f9d12867f02c56