Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-37991 State: PUBLISHED Published: 2025-05-20T17:18:45.988Z Last Updated: 2025-11-03T19:58:05.217Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: parisc: Fix double SIGFPE crash Camm noticed that on parisc a SIGFPE exception will crash an application with a second SIGFPE in the signal handler. Dave analyzed it, and it happens because glibc uses a double-word floating-point store to atomically update function descriptors. As a result of lazy binding, we hit a floating-point store in fpe_func almost immediately. When the T bit is set, an assist exception trap occurs when when the co-processor encounters *any* floa
ost immediately. When the T bit is set, an assist exception trap occurs when when the co-processor encounters *any* floating-point instruction except for a double store of register %fr0. The latter cancels all pending traps. Let's fix this by clearing the Trap (T) bit in the FP status register before returning to the signal handler in userspace. The issue can be reproduced with this test program: root@parisc:~# cat fpe.c static void fpe_func(int sig, siginfo_t *i, void *v) { sigset_t set; sigemptyset(&set); sigaddset(&set, SIGFPE); sigprocmask(SIG_UNBLOCK, &set, NULL); printf("GOT signal %d with si_code %ld\n", sig, i->si_code); } int main() { struct sigaction action = { .sa_sigaction = fpe_
tf("GOT signal %d with si_code %ld\n", sig, i->si_code); } int main() { struct sigaction action = { .sa_sigaction = fpe_func, .sa_flags = SA_RESTART|SA_SIGINFO }; sigaction(SIGFPE, &action, 0); feenableexcept(FE_OVERFLOW); return printf("%lf\n",1.7976931348623158E308*1.7976931348623158E308); } root@parisc:~# gcc fpe.c -lm root@parisc:~# ./a.out Floating point exception root@parisc:~# strace -f ./a.out execve("./a.out", ["./a.out"], 0xf9ac7034 /* 20 vars */) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 ... rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr
110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} --- --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} --- +++ killed by SIGFPE +++ Floating point exception Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/2a1aff3616b3b57aa4a5f8a7762cce1e82493fe6 - https://git.kernel.org/stable/c/757ba4d17b868482837c566cfefca59e2296c608 - https://git.kernel.org/stable/c/ec4584495868bd465fe60a3f771915c0e7ce7951 - https://git.kernel.org/stable/c/6c639af49e9e5615a8395981eaf5943fb40acd6f - https://git.kernel.org/stable/c/6a098c51d18ec99485668da44294565c43dbc106 - htt
c639af49e9e5615a8395981eaf5943fb40acd6f - https://git.kernel.org/stable/c/6a098c51d18ec99485668da44294565c43dbc106 - https://git.kernel.org/stable/c/cf21e890f56b7d0038ddaf25224e4f4c69ecd143 - https://git.kernel.org/stable/c/df3592e493d7f29bae4ffde9a9325de50ddf962e - https://git.kernel.org/stable/c/de3629baf5a33af1919dec7136d643b0662e85ef
CVE ID: CVE-2025-37992 State: PUBLISHED Published: 2025-05-26T14:54:15.796Z Last Updated: 2025-11-03T19:58:06.592Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net_sched: Flush gso_skb list too during ->change() Previously, when reducing a qdisc's limit via the ->change() operation, only the main skb queue was trimmed, potentially leaving packets in the gso_skb list. This could result in NULL pointer dereference when we only check sch->limit against sch->q.qlen. This patch introduces a new helper, qdisc_dequeue_internal(), which ensures both the gso_skb list and the main queue are properly flushed when trimming excess packets
eue_internal(), which ensures both the gso_skb list and the main queue are properly flushed when trimming excess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie) are updated to use this helper in their ->change() routines. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/ea1132ccb112f51ba749c56a912f67970c2cd542 - https://git.kernel.org/stable/c/d3336f746f196c6a53e0480923ae93939f047b6c - https://git.kernel.org/stable/c/d38939ebe0d992d581acb6885c1723fa83c1fb2c - https://git.kernel.org/stable/c/a7d6e0ac0a8861f6b1027488062251a8e28150fd - https://git.kernel.org/stable/c/d1365ca80b012d8a7863e45949e413fb61fa4861 - https://git.kerne
6b1027488062251a8e28150fd - https://git.kernel.org/stable/c/d1365ca80b012d8a7863e45949e413fb61fa4861 - https://git.kernel.org/stable/c/fe88c7e4fc2c1cd75a278a15ffbf1689efad4e76 - https://git.kernel.org/stable/c/2d3cbfd6d54a2c39ce3244f33f85c595844bd7b8
CVE ID: CVE-2025-37993 State: PUBLISHED Published: 2025-05-29T13:15:52.811Z Last Updated: 2025-05-29T13:15:52.811Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: can: m_can: m_can_class_allocate_dev(): initialize spin lock on device probe The spin lock tx_handling_spinlock in struct m_can_classdev is not being initialized. This leads the following spinlock bad magic complaint from the kernel, eg. when trying to send CAN frames with cansend from can-utils: | BUG: spinlock bad magic on CPU#0, cansend/95 | lock: 0xff60000002ec1010, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 | CPU: 0 UID: 0 PID: 95 Comm: cansend Not tainted
0xff60000002ec1010, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 | CPU: 0 UID: 0 PID: 95 Comm: cansend Not tainted 6.15.0-rc3-00032-ga79be02bba5c #5 NONE | Hardware name: MachineWare SIM-V (DT) | Call Trace: | [<ffffffff800133e0>] dump_backtrace+0x1c/0x24 | [<ffffffff800022f2>] show_stack+0x28/0x34 | [<ffffffff8000de3e>] dump_stack_lvl+0x4a/0x68 | [<ffffffff8000de70>] dump_stack+0x14/0x1c | [<ffffffff80003134>] spin_dump+0x62/0x6e | [<ffffffff800883ba>] do_raw_spin_lock+0xd0/0x142 | [<ffffffff807a6fcc>] _raw_spin_lock_irqsave+0x20/0x2c | [<ffffffff80536dba>] m_can_start_xmit+0x90/0x34a | [<ffffffff806148b0>] dev_hard_start_xmit+0xa6/0xee | [<ffffffff8065b730>] sch_direct_xmit+0x114/0x2
rt_xmit+0x90/0x34a | [<ffffffff806148b0>] dev_hard_start_xmit+0xa6/0xee | [<ffffffff8065b730>] sch_direct_xmit+0x114/0x292 | [<ffffffff80614e2a>] __dev_queue_xmit+0x3b0/0xaa8 | [<ffffffff8073b8fa>] can_send+0xc6/0x242 | [<ffffffff8073d1c0>] raw_sendmsg+0x1a8/0x36c | [<ffffffff805ebf06>] sock_write_iter+0x9a/0xee | [<ffffffff801d06ea>] vfs_write+0x184/0x3a6 | [<ffffffff801d0a88>] ksys_write+0xa0/0xc0 | [<ffffffff801d0abc>] __riscv_sys_write+0x14/0x1c | [<ffffffff8079ebf8>] do_trap_ecall_u+0x168/0x212 | [<ffffffff807a830a>] handle_exception+0x146/0x152 Initializing the spin lock in m_can_class_allocate_dev solves that problem. References: - https://git.kernel.org/stable/c/2ecce25ea296f328d7907
ock in m_can_class_allocate_dev solves that problem. References: - https://git.kernel.org/stable/c/2ecce25ea296f328d79070ee36229a15aeeb7aca - https://git.kernel.org/stable/c/7d5379cfecfdd665e4206bc4f19824656388779f - https://git.kernel.org/stable/c/dcaeeb8ae84c5506ebc574732838264f3887738c
CVE ID: CVE-2025-37994 State: PUBLISHED Published: 2025-05-29T13:15:53.481Z Last Updated: 2025-11-03T19:58:07.987Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: displayport: Fix NULL pointer access This patch ensures that the UCSI driver waits for all pending tasks in the ucsi_displayport_work workqueue to finish executing before proceeding with the partner removal. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/9dda1e2a666a8a32ce0f153b5dee05c7351f1020 - https://git.kernel.org/stable/c/a9931f1b52b2d0bf3952e003fd5901ea7eb851ed - https://git.kernel.org/stable/c/
c7351f1020 - https://git.kernel.org/stable/c/a9931f1b52b2d0bf3952e003fd5901ea7eb851ed - https://git.kernel.org/stable/c/7804c4d63edfdd5105926cc291e806e8f4ce01b5 - https://git.kernel.org/stable/c/076ab0631ed4928905736f1701e25f1e722bc086 - https://git.kernel.org/stable/c/14f298c52188c34acde9760bf5abc669c5c36fdb - https://git.kernel.org/stable/c/5ad298d6d4aebe1229adba6427e417e89a5208d8 - https://git.kernel.org/stable/c/e9b63faf5c97deb43fc39a52edbc39d626cc14bf - https://git.kernel.org/stable/c/312d79669e71283d05c05cc49a1a31e59e3d9e0e
CVE ID: CVE-2025-37995 State: PUBLISHED Published: 2025-05-29T13:15:54.095Z Last Updated: 2025-11-03T19:58:09.408Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: module: ensure that kobject_put() is safe for module type kobjects In 'lookup_or_create_module_kobject()', an internal kobject is created using 'module_ktype'. So call to 'kobject_put()' on error handling path causes an attempt to use an uninitialized completion pointer in 'module_kobject_release()'. In this scenario, we just want to release kobject without an extra synchronization required for a regular module unloading process, so adding an extra check whether 'compl
ithout an extra synchronization required for a regular module unloading process, so adding an extra check whether 'complete()' is actually required makes 'kobject_put()' safe. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/93799fb988757cdacf19acba57807746c00378e6 - https://git.kernel.org/stable/c/a63d99873547d8b39eb2f6db79dd235761e7098a - https://git.kernel.org/stable/c/f1c71b4bd721a4ea21da408806964b10468623f2 - https://git.kernel.org/stable/c/9e7b49ce4f9d0cb5b6e87db9e07a2fb9e754b0dd - https://git.kernel.org/stable/c/faa9059631d3491d699c69ecf512de9e1a3d6649 - https://git.kernel.org/stable/c/d63851049f412cdfadaeef7a7eaef5031d11c1e9 - https://g
631d3491d699c69ecf512de9e1a3d6649 - https://git.kernel.org/stable/c/d63851049f412cdfadaeef7a7eaef5031d11c1e9 - https://git.kernel.org/stable/c/31d8df3f303c3ae9115230820977ef8c35c88808 - https://git.kernel.org/stable/c/a6aeb739974ec73e5217c75a7c008a688d3d5cf1
CVE ID: CVE-2025-37996 State: PUBLISHED Published: 2025-05-29T13:15:54.956Z Last Updated: 2025-05-29T13:15:54.956Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Fix uninitialized memcache pointer in user_mem_abort() Commit fce886a60207 ("KVM: arm64: Plumb the pKVM MMU in KVM") made the initialization of the local memcache variable in user_mem_abort() conditional, leaving a codepath where it is used uninitialized via kvm_pgtable_stage2_map(). This can fail on any path that requires a stage-2 allocation without transition via a permission fault or dirty logging. Fix this by making sure that memcache is always valid.
tion without transition via a permission fault or dirty logging. Fix this by making sure that memcache is always valid. References: - https://git.kernel.org/stable/c/a26d50f8a4a5049e956984797b5d0dedea4bbb18 - https://git.kernel.org/stable/c/157dbc4a321f5bb6f8b6c724d12ba720a90f1a7c
CVE ID: CVE-2025-37997 State: PUBLISHED Published: 2025-05-29T13:15:55.580Z Last Updated: 2025-11-03T19:58:10.817Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix region locking in hash types Region locking introduced in v5.6-rc4 contained three macros to handle the region locks: ahash_bucket_start(), ahash_bucket_end() which gave back the start and end hash bucket values belonging to a given region lock and ahash_region() which should give back the region lock belonging to a given hash bucket. The latter was incorrect which can lead to a race condition between the garbage collector and adding new elements
cket. The latter was incorrect which can lead to a race condition between the garbage collector and adding new elements when a hash type of set is defined with timeouts. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/00cfc5fad1491796942a948808afb968a0a3f35b - https://git.kernel.org/stable/c/226ce0ec38316d9e3739e73a64b6b8304646c658 - https://git.kernel.org/stable/c/82c1eb32693bc48251d92532975e19160987e5b9 - https://git.kernel.org/stable/c/aa77294b0f73bb8265987591460cd25b8722c3df - https://git.kernel.org/stable/c/a3dfec485401943e315c394c29afe2db8f9481d6 - https://git.kernel.org/stable/c/e2ab67672b2288521a6146034a971f9a82ffc5c5 - https://git.ker
43e315c394c29afe2db8f9481d6 - https://git.kernel.org/stable/c/e2ab67672b2288521a6146034a971f9a82ffc5c5 - https://git.kernel.org/stable/c/6e002ecc1c8cfdfc866b9104ab7888da54613e59 - https://git.kernel.org/stable/c/8478a729c0462273188263136880480729e9efca
CVE ID: CVE-2025-37998 State: PUBLISHED Published: 2025-05-29T13:15:56.197Z Last Updated: 2025-11-03T19:58:12.202Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: openvswitch: Fix unsafe attribute parsing in output_userspace() This patch replaces the manual Netlink attribute iteration in output_userspace() with nla_for_each_nested(), which ensures that only well-formed attributes are processed. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/6712dc21506738f5f22b4f68b7c0d9e0df819dbd - https://git.kernel.org/stable/c/06b4f110c79716c181a8c5da007c259807840232 - https://git.kernel.org/
f68b7c0d9e0df819dbd - https://git.kernel.org/stable/c/06b4f110c79716c181a8c5da007c259807840232 - https://git.kernel.org/stable/c/47f7f00cf2fa3137d5c0416ef1a71bdf77901395 - https://git.kernel.org/stable/c/bca8df998cce1fead8cbc69144862eadc2e34c87 - https://git.kernel.org/stable/c/0236742bd959332181c1fcc41a05b7b709180501 - https://git.kernel.org/stable/c/ec334aaab74705cc515205e1da3cb369fdfd93cd - https://git.kernel.org/stable/c/4fa672cbce9c86c3efb8621df1ae580d47813430 - https://git.kernel.org/stable/c/6beb6835c1fbb3f676aebb51a5fee6b77fed9308 - https://www.zerodayinitiative.com/advisories/ZDI-25-307/
CVE ID: CVE-2025-37999 State: PUBLISHED Published: 2025-05-29T13:15:56.825Z Last Updated: 2025-05-29T13:15:56.825Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fs/erofs/fileio: call erofs_onlinefolio_split() after bio_add_folio() If bio_add_folio() fails (because it is full), erofs_fileio_scan_folio() needs to submit the I/O request via erofs_fileio_rq_submit() and allocate a new I/O request with an empty `struct bio`. Then it retries the bio_add_folio() call. However, at this point, erofs_onlinefolio_split() has already been called which increments `folio->private`; the retry will call erofs_onlinefolio_split() again, but th
) has already been called which increments `folio->private`; the retry will call erofs_onlinefolio_split() again, but there will never be a matching erofs_onlinefolio_end() call. This leaves the folio locked forever and all waiters will be stuck in folio_wait_bit_common(). This bug has been added by commit ce63cb62d794 ("erofs: support unencoded inodes for fileio"), but was practically unreachable because there was room for 256 folios in the `struct bio` - until commit 9f74ae8c9ac9 ("erofs: shorten bvecs[] for file-backed mounts") which reduced the array capacity to 16 folios. It was now trivial to trigger the bug by manually invoking readahead from userspace, e.g.: posix_fadvise(fd, 0, st.s
os. It was now trivial to trigger the bug by manually invoking readahead from userspace, e.g.: posix_fadvise(fd, 0, st.st_size, POSIX_FADV_WILLNEED); This should be fixed by invoking erofs_onlinefolio_split() only after bio_add_folio() has succeeded. This is safe: asynchronous completions invoking erofs_onlinefolio_end() will not unlock the folio because erofs_fileio_scan_folio() is still holding a reference to be released by erofs_onlinefolio_end() at the end. References: - https://git.kernel.org/stable/c/61e0fc3312309867e5a3495329dad0286d2a5703 - https://git.kernel.org/stable/c/c26076197df348c84cc23e5962d61902e072a0f5 - https://git.kernel.org/stable/c/bbfe756dc3062c1e934f06e5ba39c239aa953b
able/c/c26076197df348c84cc23e5962d61902e072a0f5 - https://git.kernel.org/stable/c/bbfe756dc3062c1e934f06e5ba39c239aa953b92
CVE ID: CVE-2025-38000 State: PUBLISHED Published: 2025-06-06T13:03:35.405Z Last Updated: 2025-11-03T17:32:58.709Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sch_hfsc: Fix qlen accounting bug when using peek in hfsc_enqueue() When enqueuing the first packet to an HFSC class, hfsc_enqueue() calls the child qdisc's peek() operation before incrementing sch->q.qlen and sch->qstats.backlog. If the child qdisc uses qdisc_peek_dequeued(), this may trigger an immediate dequeue and potential packet drop. In such cases, qdisc_tree_reduce_backlog() is called, but the HFSC qdisc's qlen and backlog have not yet been updated, leading to
ses, qdisc_tree_reduce_backlog() is called, but the HFSC qdisc's qlen and backlog have not yet been updated, leading to inconsistent queue accounting. This can leave an empty HFSC class in the active list, causing further consequences like use-after-free. This patch fixes the bug by moving the increment of sch->q.qlen and sch->qstats.backlog before the call to the child qdisc's peek() operation. This ensures that queue length and backlog are always accurate when packet drops or dequeues are triggered during the peek. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/1034e3310752e8675e313f7271b348914008719a - https://git.kernel.org/stable/c/f9f59
nces: - https://git.kernel.org/stable/c/1034e3310752e8675e313f7271b348914008719a - https://git.kernel.org/stable/c/f9f593e34d2fb67644372c8f7b033bdc622ad228 - https://git.kernel.org/stable/c/89c301e929a0db14ebd94b4d97764ce1d6981653 - https://git.kernel.org/stable/c/f1dde3eb17dc1b8bd07aed00004b1e05fc87a3d4 - https://git.kernel.org/stable/c/93c276942e75de0e5bc91576300d292e968f5a02 - https://git.kernel.org/stable/c/49b21795b8e5654a7df3d910a12e1060da4c04cf - https://git.kernel.org/stable/c/3f3a22eebbc32b4fa8ce9c1d5f9db214b45b9335 - https://git.kernel.org/stable/c/3f981138109f63232a5fb7165938d4c945cc1b9d
CVE ID: CVE-2025-38001 State: PUBLISHED Published: 2025-06-06T13:41:45.462Z Last Updated: 2025-11-03T17:33:00.634Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net_sched: hfsc: Address reentrant enqueue adding class to eltree twice Savino says: "We are writing to report that this recent patch (141d34391abbb315d68556b7c67ad97885407547) [1] can be bypassed, and a UAF can still occur when HFSC is utilized with NETEM. The patch only checks the cl->cl_nactive field to determine whether it is the first insertion or not [2], but this field is only incremented by init_vf [3]. By using HFSC_RSC (which uses init_ed) [4], it is possible
r not [2], but this field is only incremented by init_vf [3]. By using HFSC_RSC (which uses init_ed) [4], it is possible to bypass the check and insert the class twice in the eltree. Under normal conditions, this would lead to an infinite loop in hfsc_dequeue for the reasons we already explained in this report [5]. However, if TBF is added as root qdisc and it is configured with a very low rate, it can be utilized to prevent packets from being dequeued. This behavior can be exploited to perform subsequent insertions in the HFSC eltree and cause a UAF." To fix both the UAF and the infinite loop, with netem as an hfsc child, check explicitly in hfsc_enqueue whether the class is already in the
nd the infinite loop, with netem as an hfsc child, check explicitly in hfsc_enqueue whether the class is already in the eltree whenever the HFSC_RSC flag is set. [1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547 [2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1572 [3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677 [4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574 [5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u Additio
mBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/e5bee633cc276410337d54b99f77fbc1ad8801e5 - https://git.kernel.org/stable/c/6672e6c00810056acaac019fe26cdc26fee8a66c - https://git.kernel.org/stable/c/2c928b3a0b04a431ffcd6c8b7d88a267124a3a28 - https://git.kernel.org/stable/c/a0ec22fa20b252edbe070a9de8501eef63c17ef5 - https://git.kernel.org/stable/c/295f7c579b07b5b7cf2dffe485f71cc2f27647cb - https://git.kernel.org/stable/c/2f2190ce4ca972051cac6a8d7937448f8cb9673c - https://git.kernel.org/stable/c/4e38eaaabfb7fffbb371a51150203e19eee5d70e
le/c/2f2190ce4ca972051cac6a8d7937448f8cb9673c - https://git.kernel.org/stable/c/4e38eaaabfb7fffbb371a51150203e19eee5d70e - https://git.kernel.org/stable/c/39ed887b1dd2d6b720f87e86692ac3006cc111c8 - https://git.kernel.org/stable/c/ac9fe7dd8e730a103ae4481147395cc73492d786
CVE ID: CVE-2025-38002 State: PUBLISHED Published: 2025-06-06T13:43:41.137Z Last Updated: 2025-06-26T14:59:26.666Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: io_uring/fdinfo: grab ctx->uring_lock around io_uring_show_fdinfo() Not everything requires locking in there, which is why the 'has_lock' variable exists. But enough does that it's a bit unwieldy to manage. Wrap the whole thing in a ->uring_lock trylock, and just return with no output if we fail to grab it. The existing trylock() will already have greatly diminished utility/output for the failure case. This fixes an issue with reading the SQE fields, if the ring is bei
atly diminished utility/output for the failure case. This fixes an issue with reading the SQE fields, if the ring is being actively resized at the same time. References: - https://git.kernel.org/stable/c/bdb7d2ec2e31c46c45d1f32667dfa8216a72705e - https://git.kernel.org/stable/c/d871198ee431d90f5308d53998c1ba1d5db5619a - https://project-zero.issues.chromium.org/issues/417522668
CVE ID: CVE-2025-38003 State: PUBLISHED Published: 2025-06-08T10:34:55.808Z Last Updated: 2025-11-03T17:33:02.902Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing rcu read protection for procfs content When the procfs content is generated for a bcm_op which is in the process to be removed the procfs output might show unreliable data (UAF). As the removal of bcm_op's is already implemented with rcu handling this patch adds the missing rcu_read_lock() and makes sure the list entries are properly removed under rcu protection. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.o
erly removed under rcu protection. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/19f553a1ddf260da6570ed8f8d91a8c87f49b63a - https://git.kernel.org/stable/c/659701c0b954ccdb4a916a4ad59bbc16e726d42c - https://git.kernel.org/stable/c/0622846db728a5332b917c797c733e202c4620ae - https://git.kernel.org/stable/c/6d7d458c41b98a5c1670cbd36f2923c37de51cf5 - https://git.kernel.org/stable/c/1f912f8484e9c4396378c39460bbea0af681f319 - https://git.kernel.org/stable/c/63567ecd99a24495208dc860d50fb17440043006 - https://git.kernel.org/stable/c/7c9db92d5f0eadca30884af75c53d601edc512ee - https://git.kernel.org/stable/c/dac5e6249159ac255dad9781793dbe5908ac9ddb