Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
own in the trace below. Fix by managing the irq_work state correctly. irq_exit() __irq_exit_rcu() /* in_hardirq() returns false after this */ preempt_count_sub(HARDIRQ_OFFSET) tick_irq_exit() tick_nohz_irq_exit() tick_nohz_stop_sched_tick() trace_tick_stop() /* a bpf prog is hooked on this trace point */ __bpf_trace_tick_stop() bpf_trace_run2() rcu_read_unlock_special() /* will send a IPI to itself */ irq_work_queue_on(&rdp->defer_qs_iw, rdp->cpu); A simple reproducer can also be obtained by doing the following in tick_irq_exit(). It will hang on boot without the patch: static inline void tick_irq_exit(void) { + rcu_read_lock(); + WRITE_ONCE(current->rcu_read_unlock_special.b.need_qs, true);
tic inline void tick_irq_exit(void) { + rcu_read_lock(); + WRITE_ONCE(current->rcu_read_unlock_special.b.need_qs, true); + rcu_read_unlock(); + [neeraj: Apply Frederic's suggested fix for PREEMPT_RT] References: - https://git.kernel.org/stable/c/e7a375453cca2b8a0d2fa1b82b913f3fed7c0507 - https://git.kernel.org/stable/c/1cfa244f7198d325594e627574930b7b91df5bfe - https://git.kernel.org/stable/c/ddebb2a7677673cf4438a04e1a48b8ed6b0c8e9a - https://git.kernel.org/stable/c/56c5ef194f4509df63fc0f7a91ea5973ce479b1e - https://git.kernel.org/stable/c/b41642c87716bbd09797b1e4ea7d904f06c39b7b
CVE ID: CVE-2025-39745 State: PUBLISHED Published: 2025-09-11T16:52:18.423Z Last Updated: 2025-09-29T05:58:33.407Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rcutorture: Fix rcutorture_one_extend_check() splat in RT kernels For built with CONFIG_PREEMPT_RT=y kernels, running rcutorture tests resulted in the following splat: [ 68.797425] rcutorture_one_extend_check during change: Current 0x1 To add 0x1 To remove 0x0 preempt_count() 0x0 [ 68.797533] WARNING: CPU: 2 PID: 512 at kernel/rcu/rcutorture.c:1993 rcutorture_one_extend_check+0x419/0x560 [rcutorture] [ 68.797601] Call Trace: [ 68.797602] <TASK> [ 68.797619] ? lockdep_s
utorture_one_extend_check+0x419/0x560 [rcutorture] [ 68.797601] Call Trace: [ 68.797602] <TASK> [ 68.797619] ? lockdep_softirqs_off+0xa5/0x160 [ 68.797631] rcutorture_one_extend+0x18e/0xcc0 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c] [ 68.797646] ? local_clock+0x19/0x40 [ 68.797659] rcu_torture_one_read+0xf0/0x280 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c] [ 68.797678] ? __pfx_rcu_torture_one_read+0x10/0x10 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c] [ 68.797804] ? __pfx_rcu_torture_timer+0x10/0x10 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c] [ 68.797815] rcu-torture: rcu_torture_reader task started [ 68.797824] rcu-torture: Creating rcu_torture_reader
6ac997c] [ 68.797815] rcu-torture: rcu_torture_reader task started [ 68.797824] rcu-torture: Creating rcu_torture_reader task [ 68.797824] rcu_torture_reader+0x238/0x580 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c] [ 68.797836] ? kvm_sched_clock_read+0x15/0x30 Disable BH does not change the SOFTIRQ corresponding bits in preempt_count() for RT kernels, this commit therefore use softirq_count() to check the if BH is disabled. References: - https://git.kernel.org/stable/c/a85550267247cdf5e7499be00ea8e388ab014e50 - https://git.kernel.org/stable/c/69c5ae0f441c2d72e8f48dc1e08464c172360c4c - https://git.kernel.org/stable/c/8d71351d88e478d3c4e945e3218e97ec677fd807
CVE ID: CVE-2025-39746 State: PUBLISHED Published: 2025-09-11T16:52:19.112Z Last Updated: 2025-09-29T05:58:34.660Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: shutdown driver when hardware is unreliable In rare cases, ath10k may lose connection with the PCIe bus due to some unknown reasons, which could further lead to system crashes during resuming due to watchdog timeout: ath10k_pci 0000:01:00.0: wmi command 20486 timeout, restarting hardware ath10k_pci 0000:01:00.0: already restarting ath10k_pci 0000:01:00.0: failed to stop WMI vdev 0: -11 ath10k_pci 0000:01:00.0: failed to stop vdev 0: -11 ieee80211 phy0: PM
_pci 0000:01:00.0: failed to stop WMI vdev 0: -11 ath10k_pci 0000:01:00.0: failed to stop vdev 0: -11 ieee80211 phy0: PM: **** DPM device timeout **** Call Trace: panic+0x125/0x315 dpm_watchdog_set+0x54/0x54 dpm_watchdog_handler+0x57/0x57 call_timer_fn+0x31/0x13c At this point, all WMI commands will timeout and attempt to restart device. So set a threshold for consecutive restart failures. If the threshold is exceeded, consider the hardware is unreliable and all ath10k operations should be skipped to avoid system crash. fail_cont_count and pending_recovery are atomic variables, and do not involve complex conditional logic. Therefore, even if recovery check and reconfig complete are executed
les, and do not involve complex conditional logic. Therefore, even if recovery check and reconfig complete are executed concurrently, the recovery mechanism will not be broken. Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1 References: - https://git.kernel.org/stable/c/201c9b4485edc618863a60f97a2d88bddd139467 - https://git.kernel.org/stable/c/e36991bddf8be63e79659f654cdb1722db4e8132 - https://git.kernel.org/stable/c/84ca5632b8d05d1c2e25604d1d63434b2fb61c85 - https://git.kernel.org/stable/c/c256a94d1b1b15109740306f7f2a7c2173e12072
CVE ID: CVE-2025-39747 State: PUBLISHED Published: 2025-09-11T16:52:19.816Z Last Updated: 2025-09-29T05:58:35.905Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/msm: Add error handling for krealloc in metadata setup Function msm_ioctl_gem_info_set_metadata() now checks for krealloc failure and returns -ENOMEM, avoiding potential NULL pointer dereference. Explicitly avoids __GFP_NOFAIL due to deadlock risks and allocation constraints. Patchwork: https://patchwork.freedesktop.org/patch/661235/ References: - https://git.kernel.org/stable/c/53dc780c1e94ea782d8936b41bfaa83c663702eb - https://git.kernel.org/stable/c/01e3eda8edc3
https://git.kernel.org/stable/c/53dc780c1e94ea782d8936b41bfaa83c663702eb - https://git.kernel.org/stable/c/01e3eda8edc3c4caaa49261d1a56c799b0bd6268 - https://git.kernel.org/stable/c/d5386bcede7b57b193c658dcbb9d22004cde7580 - https://git.kernel.org/stable/c/1c8c354098ea9d4376a58c96ae6b65288a6f15d8
CVE ID: CVE-2025-39748 State: PUBLISHED Published: 2025-09-11T16:52:20.534Z Last Updated: 2025-09-29T05:58:37.148Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Forget ranges when refining tnum after JSET Syzbot reported a kernel warning due to a range invariant violation on the following BPF program. 0: call bpf_get_netns_cookie 1: if r0 == 0 goto <exit> 2: if r0 & Oxffffffff goto <exit> The issue is on the path where we fall through both jumps. That path is unreachable at runtime: after insn 1, we know r0 != 0, but with the sign extension on the jset, we would only fallthrough insn 2 if r0 == 0. Unfortunately, is_branch
r0 != 0, but with the sign extension on the jset, we would only fallthrough insn 2 if r0 == 0. Unfortunately, is_branch_taken() isn't currently able to figure this out, so the verifier walks all branches. The verifier then refines the register bounds using the second condition and we end up with inconsistent bounds on this unreachable path: 1: if r0 == 0 goto <exit> r0: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0xffffffffffffffff) 2: if r0 & 0xffffffff goto <exit> r0 before reg_bounds_sync: u64=[0x1, 0xffffffffffffffff] var_off=(0, 0) r0 after reg_bounds_sync: u64=[0x1, 0] var_off=(0, 0) Improving the range refinement for JSET to cover all cases is tricky. We also don't expect many users to
var_off=(0, 0) Improving the range refinement for JSET to cover all cases is tricky. We also don't expect many users to rely on JSET given LLVM doesn't generate those instructions. So instead of improving the range refinement for JSETs, Eduard suggested we forget the ranges whenever we're narrowing tnums after a JSET. This patch implements that approach. References: - https://git.kernel.org/stable/c/f01e06930444cab289a8783017af9b64255bd103 - https://git.kernel.org/stable/c/2fd0c26bacd90ef26522bd3169000a4715bf151f - https://git.kernel.org/stable/c/80a6b11862a7cfdf691e8f9faee89cfea219f098 - https://git.kernel.org/stable/c/6279846b9b2532e1b04559ef8bd0dec049f29383
CVE ID: CVE-2025-39749 State: PUBLISHED Published: 2025-09-11T16:52:21.228Z Last Updated: 2025-11-03T17:43:01.289Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rcu: Protect ->defer_qs_iw_pending from data race On kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is invoked within an interrupts-disabled region of code [1], it will invoke rcu_read_unlock_special(), which uses an irq-work handler to force the system to notice when the RCU read-side critical section actually ends. That end won't happen until interrupts are enabled at the soonest. In some kernels, such as those booted with rcutree.use_softirq=y, the irq
n until interrupts are enabled at the soonest. In some kernels, such as those booted with rcutree.use_softirq=y, the irq-work handler is used unconditionally. The per-CPU rcu_data structure's ->defer_qs_iw_pending field is updated by the irq-work handler and is both read and updated by rcu_read_unlock_special(). This resulted in the following KCSAN splat: ------------------------------------------------------------------------ BUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special read to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8: rcu_read_unlock_special+0x175/0x260 __rcu_read_unlock+0x92/0xa0 rt_spin_unlock+0x9b/0xc0 __local_bh_enable+0x10d/0x170 __local_
d_unlock_special+0x175/0x260 __rcu_read_unlock+0x92/0xa0 rt_spin_unlock+0x9b/0xc0 __local_bh_enable+0x10d/0x170 __local_bh_enable_ip+0xfb/0x150 rcu_do_batch+0x595/0xc40 rcu_cpu_kthread+0x4e9/0x830 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30 write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8: rcu_preempt_deferred_qs_handler+0x1e/0x30 irq_work_single+0xaf/0x160 run_irq_workd+0x91/0xc0 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30 no locks held by irq_work/8/88. irq event stamp: 200272 hardirqs last enabled at (200272): [<ffffffffb0f56121>] finish_task_switch+0x131/0x320 har
8/88. irq event stamp: 200272 hardirqs last enabled at (200272): [<ffffffffb0f56121>] finish_task_switch+0x131/0x320 hardirqs last disabled at (200271): [<ffffffffb25c7859>] __schedule+0x129/0xd70 softirqs last enabled at (0): [<ffffffffb0ee093f>] copy_process+0x4df/0x1cc0 softirqs last disabled at (0): [<0000000000000000>] 0x0 ------------------------------------------------------------------------ The problem is that irq-work handlers run with interrupts enabled, which means that rcu_preempt_deferred_qs_handler() could be interrupted, and that interrupt handler might contain an RCU read-side critical section, which might invoke rcu_read_unlock_special(). In the strict KCSAN mode of operati
ain an RCU read-side critical section, which might invoke rcu_read_unlock_special(). In the strict KCSAN mode of operation used by RCU, this constitutes a data race on the ->defer_qs_iw_pending field. This commit therefore disables interrupts across the portion of the rcu_preempt_deferred_qs_handler() that updates the ->defer_qs_iw_pending field. This suffices because this handler is not a fast path. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/74f58f382a7c8333f8d09701aefaa25913bdbe0e - https://git.kernel.org/stable/c/f937759c7432d6151b73e1393b6517661813d506 - https://git.kernel.org/stable/c/0ad84d62217488e679ecc90e8628980dcc003de3 - https:
759c7432d6151b73e1393b6517661813d506 - https://git.kernel.org/stable/c/0ad84d62217488e679ecc90e8628980dcc003de3 - https://git.kernel.org/stable/c/b5de8d80b5d049f051b95d9b1ee50ae4ab656124 - https://git.kernel.org/stable/c/b55947b725f190396f475d5d0c59aa855a4d8895 - https://git.kernel.org/stable/c/e35e711c78c8a4c43330c0dcb1c4d507a19c20f4 - https://git.kernel.org/stable/c/90de9c94ea72327cfa9c2c9f6113c23a513af60b - https://git.kernel.org/stable/c/55e11f6776798b27cf09a7aa0d718415d4fc9cf5 - https://git.kernel.org/stable/c/90c09d57caeca94e6f3f87c49e96a91edd40cbfd
CVE ID: CVE-2025-39750 State: PUBLISHED Published: 2025-09-11T16:52:21.917Z Last Updated: 2025-09-29T05:58:39.644Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Correct tid cleanup when tid setup fails Currently, if any error occurs during ath12k_dp_rx_peer_tid_setup(), the tid value is already incremented, even though the corresponding TID is not actually allocated. Proceed to ath12k_dp_rx_peer_tid_delete() starting from unallocated tid, which might leads to freeing unallocated TID and cause potential crash or out-of-bounds access. Hence, fix by correctly decrementing tid before cleanup to match only the success
tential crash or out-of-bounds access. Hence, fix by correctly decrementing tid before cleanup to match only the successfully allocated TIDs. Also, remove tid-- from failure case of ath12k_dp_rx_peer_frag_setup(), as decrementing the tid before cleanup in loop will take care of this. Compile tested only. References: - https://git.kernel.org/stable/c/30cad87978057516c93467516bc481a3eacfd66a - https://git.kernel.org/stable/c/2ef17d1476ab26bce89764e2f16833d7f52acc38 - https://git.kernel.org/stable/c/907c630e58af9e86e215f3951c7b287bd86d0f15 - https://git.kernel.org/stable/c/6301fe4f209165334d251a1c6da8ae47f93cb32c - https://git.kernel.org/stable/c/4a2bf707270f897ab8077baee8ed5842a5321686
CVE ID: CVE-2025-39751 State: REJECTED Published: 2025-09-11T16:52:22.651Z Last Updated: 2025-10-06T09:54:34.568Z Description: No description available.
CVE ID: CVE-2025-39752 State: PUBLISHED Published: 2025-09-11T16:52:23.372Z Last Updated: 2025-11-03T17:43:03.272Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ARM: rockchip: fix kernel hang during smp initialization In order to bring up secondary CPUs main CPU write trampoline code to SRAM. The trampoline code is written while secondary CPUs are powered on (at least that true for RK3188 CPU). Sometimes that leads to kernel hang. Probably because secondary CPU execute trampoline code while kernel doesn't expect. The patch moves SRAM initialization step to the point where all secondary CPUs are powered down. That fixes rarely
ect. The patch moves SRAM initialization step to the point where all secondary CPUs are powered down. That fixes rarely hangs on RK3188: [ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.091996] rockchip_smp_prepare_cpus: ncores 4 Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/3c6bf7a324b8995b9c7d790c8d2abf0668f51551 - https://git.kernel.org/stable/c/888a453c2a239765a7ab4de8a3cedae2e3802528 - https://git.kernel.org/stable/c/c0726d1e466e2d0da620836e293a59e6427ccdff - https://git.kernel.org/stable/c/265583266d93db4ff83d088819b1f63fdf0131db - https://git.kernel.org/stable/c/d7d6d076ee9532c4668f14696a35688d35dd16f4 - https://git.ke
db4ff83d088819b1f63fdf0131db - https://git.kernel.org/stable/c/d7d6d076ee9532c4668f14696a35688d35dd16f4 - https://git.kernel.org/stable/c/0223a3683d502b7e5eb2eb4ad7e97363fa88d531 - https://git.kernel.org/stable/c/47769dab9073a73e127aa0bfd0ba4c51eaccdc33 - https://git.kernel.org/stable/c/1eb67589a7e091b1e5108aab72fddbf4dc69af2c - https://git.kernel.org/stable/c/7cdb433bb44cdc87dc5260cdf15bf03cc1cd1814
CVE ID: CVE-2025-39753 State: PUBLISHED Published: 2025-09-11T16:52:24.082Z Last Updated: 2025-09-29T05:58:43.421Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: gfs2: Set .migrate_folio in gfs2_{rgrp,meta}_aops Clears up the warning added in 7ee3647243e5 ("migrate: Remove call to ->writepage") that occurs in various xfstests, causing "something found in dmesg" failures. [ 341.136573] gfs2_meta_aops does not implement migrate_folio [ 341.136953] WARNING: CPU: 1 PID: 36 at mm/migrate.c:944 move_to_new_folio+0x2f8/0x300 References: - https://git.kernel.org/stable/c/3d2c05cbc6a3725d832b912b637971f37301c7e5 - https://git.kernel.org
f8/0x300 References: - https://git.kernel.org/stable/c/3d2c05cbc6a3725d832b912b637971f37301c7e5 - https://git.kernel.org/stable/c/9d9b053f7f9c5a35049abe56af9e6ac70b6b0e4b - https://git.kernel.org/stable/c/9f745095c382b76e68407fd6f15ef27baf2a013f - https://git.kernel.org/stable/c/e89cab180eb22950b6eb7b3462623c2aa81e5835 - https://git.kernel.org/stable/c/5c8f12cf1e64e0e8e6cb80b0c935389973e8be8d
CVE ID: CVE-2025-39754 State: PUBLISHED Published: 2025-09-11T16:52:24.763Z Last Updated: 2025-09-29T05:58:44.690Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/smaps: fix race between smaps_hugetlb_range and migration smaps_hugetlb_range() handles the pte without holdling ptl, and may be concurrenct with migration, leaing to BUG_ON in pfn_swap_entry_to_page(). The race is as follows. smaps_hugetlb_range migrate_pages huge_ptep_get remove_migration_ptes folio_unlock pfn_swap_entry_folio BUG_ON To fix it, hold ptl lock in smaps_hugetlb_range(). References: - https://git.kernel.org/stable/c/2a1f3663974162b8f1e098196f557cfc1d1
old ptl lock in smaps_hugetlb_range(). References: - https://git.kernel.org/stable/c/2a1f3663974162b8f1e098196f557cfc1d160138 - https://git.kernel.org/stable/c/09fc018f48871123ad5dbd7b03c956580232ed76 - https://git.kernel.org/stable/c/b625883ccbcc2b57808db51d1375b1d7b9bcb3e5 - https://git.kernel.org/stable/c/45d19b4b6c2d422771c29b83462d84afcbb33f01
CVE ID: CVE-2025-39755 State: PUBLISHED Published: 2025-04-18T07:01:37.105Z Last Updated: 2025-10-01T16:13:19.532Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: staging: gpib: Fix cb7210 pcmcia Oops The pcmcia_driver struct was still only using the old .name initialization in the drv field. This led to a NULL pointer deref Oops in strcmp called from pcmcia_register_driver. Initialize the pcmcia_driver struct name field. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/7ec50077d7f6647cb6ba3a2a20a6c26f51259c7d - https://git.kernel.org/stable/c/c82ae06f49e70d1c14ee9c76c392345856d050
able/c/7ec50077d7f6647cb6ba3a2a20a6c26f51259c7d - https://git.kernel.org/stable/c/c82ae06f49e70d1c14ee9c76c392345856d050c9 - https://git.kernel.org/stable/c/c1baf6528bcfd6a86842093ff3f8ff8caf309c12
CVE ID: CVE-2025-39756 State: PUBLISHED Published: 2025-09-11T16:52:26.136Z Last Updated: 2025-11-03T17:43:05.180Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fs: Prevent file descriptor table allocations exceeding INT_MAX When sysctl_nr_open is set to a very high value (for example, 1073741816 as set by systemd), processes attempting to use file descriptors near the limit can trigger massive memory allocation attempts that exceed INT_MAX, resulting in a WARNING in mm/slub.c: WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288 This happens because kvmalloc_array() and kvmalloc() check if the requeste
lub.c:5027 __kvmalloc_node_noprof+0x21a/0x288 This happens because kvmalloc_array() and kvmalloc() check if the requested size exceeds INT_MAX and emit a warning when the allocation is not flagged with __GFP_NOWARN. Specifically, when nr_open is set to 1073741816 (0x3ffffff8) and a process calls dup2(oldfd, 1073741880), the kernel attempts to allocate: - File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes - Multiple bitmaps: ~400MB - Total allocation size: > 8GB (exceeding INT_MAX = 2,147,483,647) Reproducer: 1. Set /proc/sys/fs/nr_open to 1073741816: # echo 1073741816 > /proc/sys/fs/nr_open 2. Run a program that uses a high file descriptor: #include <unistd.h> #include <sys/re
073741816 > /proc/sys/fs/nr_open 2. Run a program that uses a high file descriptor: #include <unistd.h> #include <sys/resource.h> int main() { struct rlimit rlim = {1073741824, 1073741824}; setrlimit(RLIMIT_NOFILE, &rlim); dup2(2, 1073741880); // Triggers the warning return 0; } 3. Observe WARNING in dmesg at mm/slub.c:5027 systemd commit a8b627a introduced automatic bumping of fs.nr_open to the maximum possible value. The rationale was that systems with memory control groups (memcg) no longer need separate file descriptor limits since memory is properly accounted. However, this change overlooked that: 1. The kernel's allocation functions still enforce INT_MAX as a maximum size regardless of
this change overlooked that: 1. The kernel's allocation functions still enforce INT_MAX as a maximum size regardless of memcg accounting 2. Programs and tests that legitimately test file descriptor limits can inadvertently trigger massive allocations 3. The resulting allocations (>8GB) are impractical and will always fail systemd's algorithm starts with INT_MAX and keeps halving the value until the kernel accepts it. On most systems, this results in nr_open being set to 1073741816 (0x3ffffff8), which is just under 1GB of file descriptors. While processes rarely use file descriptors near this limit in normal operation, certain selftests (like tools/testing/selftests/core/unshare_test.c) and
scriptors near this limit in normal operation, certain selftests (like tools/testing/selftests/core/unshare_test.c) and programs that test file descriptor limits can trigger this issue. Fix this by adding a check in alloc_fdtable() to ensure the requested allocation size does not exceed INT_MAX. This causes the operation to fail with -EMFILE instead of triggering a kernel warning and avoids the impractical >8GB memory allocation request. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/b4159c5a90c03f8acd3de345a7f5fc63b0909818 - https://git.kernel.org/stable/c/f95638a8f22eba307dceddf5aef9ae2326bbcf98 - https://git.kernel.org/stable/c/74952808662
- https://git.kernel.org/stable/c/f95638a8f22eba307dceddf5aef9ae2326bbcf98 - https://git.kernel.org/stable/c/749528086620f8012b83ae032a80f6ffa80c45cd - https://git.kernel.org/stable/c/628fc28f42d979f36dbf75a6129ac7730e30c04e - https://git.kernel.org/stable/c/237e416eb62101f21b28c9e6e564d10efe1ecc6f - https://git.kernel.org/stable/c/d4f9351243c17865a8cdbe6b3ccd09d0b13a7bcc - https://git.kernel.org/stable/c/9f61fa6a2a89a610120bc4e5d24379c667314b5c - https://git.kernel.org/stable/c/dfd1f4ea98c3bd3a03d12169b5b2daa1f0a3e4ae - https://git.kernel.org/stable/c/04a2c4b4511d186b0fce685da21085a5d4acd370
CVE ID: CVE-2025-39757 State: PUBLISHED Published: 2025-09-11T16:52:26.900Z Last Updated: 2025-11-03T17:43:07.057Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Validate UAC3 cluster segment descriptors UAC3 class segment descriptors need to be verified whether their sizes match with the declared lengths and whether they fit with the allocated buffer sizes, too. Otherwise malicious firmware may lead to the unexpected OOB accesses. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/799c06ad4c9c790c265e8b6b94947213f1fb389c - https://git.kernel.org/stable/c/786571b10b
- https://git.kernel.org/stable/c/799c06ad4c9c790c265e8b6b94947213f1fb389c - https://git.kernel.org/stable/c/786571b10b1ae6d90e1242848ce78ee7e1d493c4 - https://git.kernel.org/stable/c/275e37532e8ebe25e8a4069b2d9f955bfd202a46 - https://git.kernel.org/stable/c/47ab3d820cb0a502bd0074f83bb3cf7ab5d79902 - https://git.kernel.org/stable/c/1034719fdefd26caeec0a44a868bb5a412c2c1a5 - https://git.kernel.org/stable/c/ae17b3b5e753efc239421d186cd1ff06e5ac296e - https://git.kernel.org/stable/c/dfdcbcde5c20df878178245d4449feada7d5b201 - https://git.kernel.org/stable/c/7ef3fd250f84494fb2f7871f357808edaa1fc6ce - https://git.kernel.org/stable/c/ecfd41166b72b67d3bdeb88d224ff445f6163869