Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
anged to enable userspace control the interrupt mask by writing 0/1 to /dev/uioX. References: - https://git.kernel.org/stable/c/540aac117eaea5723cef5e4cbf3035c4ac654d92 - https://git.kernel.org/stable/c/65d40acd911c7011745cbbd2aaac34eb5266d11e - https://git.kernel.org/stable/c/a44f61f878f32071d6378e8dd7c2d47f9490c8f7 - https://git.kernel.org/stable/c/01ce972e6f9974a7c76943bcb7e93746917db83a - https://git.kernel.org/stable/c/2af39ab5e6dc46b835a52e80a22d0cad430985e3 - https://git.kernel.org/stable/c/37bd91f22794dc05436130d6983302cb90ecfe7e - https://git.kernel.org/stable/c/e29587c07537929684faa365027f4b0d87521e1b - https://git.kernel.org/stable/c/b15b7d2a1b09ef5428a8db260251897405a19496
CVE ID: CVE-2025-40049 State: PUBLISHED Published: 2025-10-28T11:48:25.862Z Last Updated: 2025-10-29T13:19:50.179Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Squashfs: fix uninit-value in squashfs_get_parent Syzkaller reports a "KMSAN: uninit-value in squashfs_get_parent" bug. This is caused by open_by_handle_at() being called with a file handle containing an invalid parent inode number. In particular the inode number is that of a symbolic link, rather than a directory. Squashfs_get_parent() gets called with that symbolic link inode, and accesses the parent member field. unsigned int parent_ino = squashfs_i(inode)->parent;
th that symbolic link inode, and accesses the parent member field. unsigned int parent_ino = squashfs_i(inode)->parent; Because non-directory inodes in Squashfs do not have a parent value, this is uninitialised, and this causes an uninitialised value access. The fix is to initialise parent with the invalid inode 0, which will cause an EINVAL error to be returned. Regular inodes used to share the parent field with the block_list_start field. This is removed in this commit to enable the parent field to contain the invalid inode number 0. References: - https://git.kernel.org/stable/c/f81a5bc9e924ee1950e0dd82bd10749048390f6e - https://git.kernel.org/stable/c/382a47fae449e554ef1e8c198667fd2f3270b
table/c/f81a5bc9e924ee1950e0dd82bd10749048390f6e - https://git.kernel.org/stable/c/382a47fae449e554ef1e8c198667fd2f3270b945 - https://git.kernel.org/stable/c/61d38b5ce2782bff3cacaacbb8164087a73ed1a5 - https://git.kernel.org/stable/c/81a2bca52d43fc9d9abf07408b91255131c5dc53 - https://git.kernel.org/stable/c/c28b0ca029edf5d0558abcd76cb8c732706cd339 - https://git.kernel.org/stable/c/1b3ccd0019132880c94bb00ca7088c1749308f82 - https://git.kernel.org/stable/c/91b99db7a92e57ff48a96a1b10fddfd2547e7f53 - https://git.kernel.org/stable/c/74058c0a9fc8b2b4d5f4a0ef7ee2cfa66a9e49cf
CVE ID: CVE-2025-40050 State: PUBLISHED Published: 2025-10-28T11:48:26.654Z Last Updated: 2025-10-28T11:48:26.654Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Skip scalar adjustment for BPF_NEG if dst is a pointer In check_alu_op(), the verifier currently calls check_reg_arg() and adjust_scalar_min_max_vals() unconditionally for BPF_NEG operations. However, if the destination register holds a pointer, these scalar adjustments are unnecessary and potentially incorrect. This patch adds a check to skip the adjustment logic when the destination register contains a pointer. References: - https://git.kernel.org/stable/c/b9ef4
e adjustment logic when the destination register contains a pointer. References: - https://git.kernel.org/stable/c/b9ef4963227246b9222e1559ddeec8e7af63e6c6 - https://git.kernel.org/stable/c/34904582b502a86fdb4d7984b12cacd2faabbe0d
CVE ID: CVE-2025-40051 State: PUBLISHED Published: 2025-10-28T11:48:27.279Z Last Updated: 2025-10-28T11:48:27.279Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vhost: vringh: Modify the return value check The return value of copy_from_iter and copy_to_iter can't be negative, check whether the copied lengths are equal. References: - https://git.kernel.org/stable/c/db042925a5ab7a550b710addeadbf6f72e3a8a4b - https://git.kernel.org/stable/c/78dc7362662fedaa1928fb8e4f27401c8322905d - https://git.kernel.org/stable/c/baa37b1c7e29546f79c39bef0d18c4edc9f39bb1 - https://git.kernel.org/stable/c/cfa0654402c06d086201a9ff167eb95da5844fc3 -
/c/baa37b1c7e29546f79c39bef0d18c4edc9f39bb1 - https://git.kernel.org/stable/c/cfa0654402c06d086201a9ff167eb95da5844fc3 - https://git.kernel.org/stable/c/82a8d0fda55b35361ee7f35b54fa2b66d7847d2b
CVE ID: CVE-2025-40052 State: PUBLISHED Published: 2025-10-28T11:48:27.854Z Last Updated: 2025-10-28T11:48:27.854Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: smb: client: fix crypto buffers in non-linear memory The crypto API, through the scatterlist API, expects input buffers to be in linear memory. We handle this with the cifs_sg_set_buf() helper that converts vmalloc'd memory to their corresponding pages. However, when we allocate our aead_request buffer (@creq in smb2ops.c::crypt_message()), we do so with kvzalloc(), which possibly puts aead_request->__ctx in vmalloc area. AEAD algorithm then uses ->__ctx for its privat
ith kvzalloc(), which possibly puts aead_request->__ctx in vmalloc area. AEAD algorithm then uses ->__ctx for its private/internal data and operations, and uses sg_set_buf() for such data on a few places. This works fine as long as @creq falls into kmalloc zone (small requests) or vmalloc'd memory is still within linear range. Tasks' stacks are vmalloc'd by default (CONFIG_VMAP_STACK=y), so too many tasks will increment the base stacks' addresses to a point where virt_addr_valid(buf) will fail (BUG() in sg_set_buf()) when that happens. In practice: too many parallel reads and writes on an encrypted mount will trigger this bug. To fix this, always alloc @creq with kmalloc() instead. Also drop
nd writes on an encrypted mount will trigger this bug. To fix this, always alloc @creq with kmalloc() instead. Also drop the @sensitive_size variable/arguments since kfree_sensitive() doesn't need it. Backtrace: [ 945.272081] ------------[ cut here ]------------ [ 945.272774] kernel BUG at include/linux/scatterlist.h:209! [ 945.273520] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI [ 945.274412] CPU: 7 UID: 0 PID: 56 Comm: kworker/u33:0 Kdump: loaded Not tainted 6.15.0-lku-11779-g8e9d6efccdd7-dirty #1 PREEMPT(voluntary) [ 945.275736] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014 [ 945.276877] Workqueue: writeback wb_wo
PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014 [ 945.276877] Workqueue: writeback wb_workfn (flush-cifs-2) [ 945.277457] RIP: 0010:crypto_gcm_init_common+0x1f9/0x220 [ 945.278018] Code: b0 00 00 00 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 c7 c0 00 00 00 80 48 2b 05 5c 58 e5 00 e9 58 ff ff ff <0f> 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 48 c7 04 24 01 00 00 00 48 8b [ 945.279992] RSP: 0018:ffffc90000a27360 EFLAGS: 00010246 [ 945.280578] RAX: 0000000000000000 RBX: ffffc90001d85060 RCX: 0000000000000030 [ 945.281376] RDX: 0000000000080000 RSI: 0000000000000000 RDI: ffffc90081d85070 [ 945.282145] RBP: ffffc90001d85010 R08: ffffc90001d85000 R09: 000000
080000 RSI: 0000000000000000 RDI: ffffc90081d85070 [ 945.282145] RBP: ffffc90001d85010 R08: ffffc90001d85000 R09: 0000000000000000 [ 945.282898] R10: ffffc90001d85090 R11: 0000000000001000 R12: ffffc90001d85070 [ 945.283656] R13: ffff888113522948 R14: ffffc90001d85060 R15: ffffc90001d85010 [ 945.284407] FS: 0000000000000000(0000) GS:ffff8882e66cf000(0000) knlGS:0000000000000000 [ 945.285262] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 945.285884] CR2: 00007fa7ffdd31f4 CR3: 000000010540d000 CR4: 0000000000350ef0 [ 945.286683] Call Trace: [ 945.286952] <TASK> [ 945.287184] ? crypt_message+0x33f/0xad0 [cifs] [ 945.287719] crypto_gcm_encrypt+0x36/0xe0 [ 945.288152] crypt_message+0x54a/0xa
184] ? crypt_message+0x33f/0xad0 [cifs] [ 945.287719] crypto_gcm_encrypt+0x36/0xe0 [ 945.288152] crypt_message+0x54a/0xad0 [cifs] [ 945.288724] smb3_init_transform_rq+0x277/0x300 [cifs] [ 945.289300] smb_send_rqst+0xa3/0x160 [cifs] [ 945.289944] cifs_call_async+0x178/0x340 [cifs] [ 945.290514] ? __pfx_smb2_writev_callback+0x10/0x10 [cifs] [ 945.291177] smb2_async_writev+0x3e3/0x670 [cifs] [ 945.291759] ? find_held_lock+0x32/0x90 [ 945.292212] ? netfs_advance_write+0xf2/0x310 [ 945.292723] netfs_advance_write+0xf2/0x310 [ 945.293210] netfs_write_folio+0x346/0xcc0 [ 945.293689] ? __pfx__raw_spin_unlock_irq+0x10/0x10 [ 945.294250] netfs_writepages+0x117/0x460 [ 945.294724] do_writepages+0xbe/0x
9] ? __pfx__raw_spin_unlock_irq+0x10/0x10 [ 945.294250] netfs_writepages+0x117/0x460 [ 945.294724] do_writepages+0xbe/0x170 [ 945.295152] ? find_held_lock+0x32/0x90 [ 945.295600] ? kvm_sched_clock_read+0x11/0x20 [ 945.296103] __writeback_single_inode+0x56/0x4b0 [ 945.296643] writeback_sb_inodes+0x229/0x550 [ 945.297140] __writeback_inodes_wb+0x4c/0xe0 [ 945.297642] wb_writeback+0x2f1/0x3f0 [ 945.298069] wb_workfn+0x300/0x490 [ 945.298472] process_one_work+0x1fe/0x590 [ 945.298949] worker_thread+0x1ce/0x3c0 [ 945.299397] ? __pfx_worker_thread+0x10/0x10 [ 945.299900] kthr ---truncated--- References: - https://git.kernel.org/stable/c/ba905a567105dde21cdb8e6d3a87110fa434b393 - https://git.kernel
truncated--- References: - https://git.kernel.org/stable/c/ba905a567105dde21cdb8e6d3a87110fa434b393 - https://git.kernel.org/stable/c/7a8a8c15468f0c99685e9964451feffd1a3cc859 - https://git.kernel.org/stable/c/4a61b68abd2788db0364c9a0b6a39f1699fea440 - https://git.kernel.org/stable/c/998a67b954680f26f3734040aeeed08642d49721
CVE ID: CVE-2025-40053 State: PUBLISHED Published: 2025-10-28T11:48:28.444Z Last Updated: 2025-10-29T13:19:52.908Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: dlink: handle copy_thresh allocation failure The driver did not handle failure of `netdev_alloc_skb_ip_align()`. If the allocation failed, dereferencing `skb->protocol` could lead to a NULL pointer dereference. This patch tries to allocate `skb`. If the allocation fails, it falls back to the normal path. Tested-on: D-Link DGE-550T Rev-A3 References: - https://git.kernel.org/stable/c/84fd710a704f3d53d4120e452e86cea558cf73a8 - https://git.kernel.org/stable/c/5aa9b88
es: - https://git.kernel.org/stable/c/84fd710a704f3d53d4120e452e86cea558cf73a8 - https://git.kernel.org/stable/c/5aa9b885602811a026a3f45c92ea2b4b04c54f09 - https://git.kernel.org/stable/c/9d49e4b14609e1a20d931e718962c4b6b5485174 - https://git.kernel.org/stable/c/ea87151df398d407a632c7bf63013290f01c5009 - https://git.kernel.org/stable/c/7ed5010fef0930f4322d620052edc854ef3ec41f - https://git.kernel.org/stable/c/fd7b6b2c920d7fd370a612be416a904d6e1ebe55 - https://git.kernel.org/stable/c/8169a6011c5fecc6cb1c3654c541c567d3318de8
CVE ID: CVE-2025-40054 State: PUBLISHED Published: 2025-10-28T11:48:29.073Z Last Updated: 2025-10-28T11:48:29.073Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: fix UAF issue in f2fs_merge_page_bio() As JY reported in bugzilla [1], Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 pc : [0xffffffe51d249484] f2fs_is_cp_guaranteed+0x70/0x98 lr : [0xffffffe51d24adbc] f2fs_merge_page_bio+0x520/0x6d4 CPU: 3 UID: 0 PID: 6790 Comm: kworker/u16:3 Tainted: P B W OE 6.12.30-android16-5-maybe-dirty-4k #1 5f7701c9cbf727d1eebe77c89bbbeb3371e895e5 Tainted: [P]=PROPRIETARY_MODULE, [B]=BAD_PAGE, [W]=WAR
id16-5-maybe-dirty-4k #1 5f7701c9cbf727d1eebe77c89bbbeb3371e895e5 Tainted: [P]=PROPRIETARY_MODULE, [B]=BAD_PAGE, [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Workqueue: writeback wb_workfn (flush-254:49) Call trace: f2fs_is_cp_guaranteed+0x70/0x98 f2fs_inplace_write_data+0x174/0x2f4 f2fs_do_write_data_page+0x214/0x81c f2fs_write_single_data_page+0x28c/0x764 f2fs_write_data_pages+0x78c/0xce4 do_writepages+0xe8/0x2fc __writeback_single_inode+0x4c/0x4b4 writeback_sb_inodes+0x314/0x540 __writeback_inodes_wb+0xa4/0xf4 wb_writeback+0x160/0x448 wb_workfn+0x2f0/0x5dc process_scheduled_works+0x1c8/0x458 worker_thread+0x334/0x3f0 kthread+0x118/0x1ac ret_from_fork+0x10/0x20 [1] https://bugzilla.kernel
uled_works+0x1c8/0x458 worker_thread+0x334/0x3f0 kthread+0x118/0x1ac ret_from_fork+0x10/0x20 [1] https://bugzilla.kernel.org/show_bug.cgi?id=220575 The panic was caused by UAF issue w/ below race condition: kworker - writepages - f2fs_write_cache_pages - f2fs_write_single_data_page - f2fs_do_write_data_page - f2fs_inplace_write_data - f2fs_merge_page_bio - add_inu_page : cache page #1 into bio & cache bio in io->bio_list - f2fs_write_single_data_page - f2fs_do_write_data_page - f2fs_inplace_write_data - f2fs_merge_page_bio - add_inu_page : cache page #2 into bio which is linked in io->bio_list write - f2fs_write_begin : write page #1 - f2fs_folio_wait_writeback - f2fs_submit_merged_ipu_write
nked in io->bio_list write - f2fs_write_begin : write page #1 - f2fs_folio_wait_writeback - f2fs_submit_merged_ipu_write - f2fs_submit_write_bio : submit bio which inclues page #1 and #2 software IRQ - f2fs_write_end_io - fscrypt_free_bounce_page : freed bounced page which belongs to page #2 - inc_page_count( , WB_DATA_TYPE(data_folio), false) : data_folio points to fio->encrypted_page the bounced page can be freed before accessing it in f2fs_is_cp_guarantee() It can reproduce w/ below testcase: Run below script in shell #1: for ((i=1;i>0;i++)) do xfs_io -f /mnt/f2fs/enc/file \ -c "pwrite 0 32k" -c "fdatasync" Run below script in shell #2: for ((i=1;i>0;i++)) do xfs_io -f /mnt/f2fs/enc/file
le \ -c "pwrite 0 32k" -c "fdatasync" Run below script in shell #2: for ((i=1;i>0;i++)) do xfs_io -f /mnt/f2fs/enc/file \ -c "pwrite 0 32k" -c "fdatasync" So, in f2fs_merge_page_bio(), let's avoid using fio->encrypted_page after commit page into internal ipu cache. References: - https://git.kernel.org/stable/c/01118321e0c8a5f3ece57d0d377bfc92d83cd210 - https://git.kernel.org/stable/c/edf7e9040fc52c922db947f9c6c36f07377c52ea
CVE ID: CVE-2025-40055 State: PUBLISHED Published: 2025-10-28T11:48:29.665Z Last Updated: 2025-10-29T13:19:55.237Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix double free in user_cluster_connect() user_cluster_disconnect() frees "conn->cc_private" which is "lc" but then the error handling frees "lc" a second time. Set "lc" to NULL on this path to avoid a double free. References: - https://git.kernel.org/stable/c/283333079d96c84baa91f0c62b5e0cbec246b7a2 - https://git.kernel.org/stable/c/f992bc72f681c32a682d474a29c2135a64d4f4e5 - https://git.kernel.org/stable/c/827c8efa0d1afe817b90f3618afff552e88348d2 - https://git.
81c32a682d474a29c2135a64d4f4e5 - https://git.kernel.org/stable/c/827c8efa0d1afe817b90f3618afff552e88348d2 - https://git.kernel.org/stable/c/bfe011297ddd2d0cd64752978baaa0c04cd20573 - https://git.kernel.org/stable/c/7e76fe9dfadbc00364d7523d5a109e9d3e4a7db2 - https://git.kernel.org/stable/c/694d5b401036a614f8080085a9de6f86ff0742dc - https://git.kernel.org/stable/c/892f41e12c8689130d552a9eb2b77bafd26484ab - https://git.kernel.org/stable/c/8f45f089337d924db24397f55697cda0e6960516
CVE ID: CVE-2025-40056 State: PUBLISHED Published: 2025-10-28T11:48:30.249Z Last Updated: 2025-10-28T11:48:30.249Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vhost: vringh: Fix copy_to_iter return value check The return value of copy_to_iter can't be negative, check whether the copied length is equal to the requested length instead of checking for negative values. References: - https://git.kernel.org/stable/c/bd71e7e0a612740e4de5524880c7cd40293af5f7 - https://git.kernel.org/stable/c/781226e11d5bdea0d69c7b5aa3cda874093c73b8 - https://git.kernel.org/stable/c/b3a950d236e98440c07405ba597b11bce56a8050 - https://git.kernel.org/st
aa3cda874093c73b8 - https://git.kernel.org/stable/c/b3a950d236e98440c07405ba597b11bce56a8050 - https://git.kernel.org/stable/c/68aac2b335d474b938d154b9c95cbc58838cb2ce - https://git.kernel.org/stable/c/439263376c2c4e126cac0d07e4987568de4eaba5
CVE ID: CVE-2025-40057 State: PUBLISHED Published: 2025-10-28T11:48:30.947Z Last Updated: 2025-10-28T11:48:30.947Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ptp: Add a upper bound on max_vclocks syzbot reported WARNING in max_vclocks_store. This occurs when the argument max is too large for kcalloc to handle. Extend the guard to guard against values that are too large for kcalloc References: - https://git.kernel.org/stable/c/8dd446056336faa2283d62cefc2f576536845edc - https://git.kernel.org/stable/c/35ce5f163889dbce88eda1df661b357a09bbed87 - https://git.kernel.org/stable/c/e9f35294e18da82162004a2f35976e7031aaf7f9
CVE ID: CVE-2025-40058 State: PUBLISHED Published: 2025-10-28T11:48:31.567Z Last Updated: 2025-10-28T11:48:31.567Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Disallow dirty tracking if incoherent page walk Dirty page tracking relies on the IOMMU atomically updating the dirty bit in the paging-structure entry. For this operation to succeed, the paging- structure memory must be coherent between the IOMMU and the CPU. In another word, if the iommu page walk is incoherent, dirty page tracking doesn't work. The Intel VT-d specification, Section 3.10 "Snoop Behavior" states: "Remapping hardware encountering the need t
't work. The Intel VT-d specification, Section 3.10 "Snoop Behavior" states: "Remapping hardware encountering the need to atomically update A/EA/D bits in a paging-structure entry that is not snooped will result in a non- recoverable fault." To prevent an IOMMU from being incorrectly configured for dirty page tracking when it is operating in an incoherent mode, mark SSADS as supported only when both ecap_slads and ecap_smpwc are supported. References: - https://git.kernel.org/stable/c/ebe16d245a00626bb87163862a1b07daf5475a3e - https://git.kernel.org/stable/c/8d096ce0e87bdc361f0b25d7943543bc53aa0b9e - https://git.kernel.org/stable/c/57f55048e564dedd8a4546d018e29d6bbfff0a7e
CVE ID: CVE-2025-40059 State: PUBLISHED Published: 2025-10-28T11:48:32.186Z Last Updated: 2025-10-28T11:48:32.186Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: coresight: Fix incorrect handling for return value of devm_kzalloc The return value of devm_kzalloc could be an null pointer, use "!desc.pdata" to fix incorrect handling return value of devm_kzalloc. References: - https://git.kernel.org/stable/c/8c4e7e646d5d9050b374baf5c6bb3a00fb79e206 - https://git.kernel.org/stable/c/9688b66d0a5e0eecf44f6286b8d9f7a161264035 - https://git.kernel.org/stable/c/70714eb7243eaf333d23501d4c7bdd9daf011c01
CVE ID: CVE-2025-40060 State: PUBLISHED Published: 2025-10-28T11:48:32.775Z Last Updated: 2025-10-28T11:48:32.775Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: coresight: trbe: Return NULL pointer for allocation failures When the TRBE driver fails to allocate a buffer, it currently returns the error code "-ENOMEM". However, the caller etm_setup_aux() only checks for a NULL pointer, so it misses the error. As a result, the driver continues and eventually causes a kernel panic. Fix this by returning a NULL pointer from arm_trbe_alloc_buffer() on allocation failures. This allows that the callers can properly handle the failure.
nter from arm_trbe_alloc_buffer() on allocation failures. This allows that the callers can properly handle the failure. References: - https://git.kernel.org/stable/c/cef047e0a55cb07906fcaae99170f19a9c0bb6c2 - https://git.kernel.org/stable/c/fe53a726d5edf864e80b490780cc135fc1adece9 - https://git.kernel.org/stable/c/9768536f82600a05ce901e31ccfabd92c027ff71 - https://git.kernel.org/stable/c/296da78494633e1ab5e2e74173a9c8683b04aa6b - https://git.kernel.org/stable/c/f505a165f1c7cd37b4cb6952042a5984693a4067 - https://git.kernel.org/stable/c/8a55c161f7f9c1aa1c70611b39830d51c83ef36d
CVE ID: CVE-2025-40061 State: PUBLISHED Published: 2025-10-28T11:48:33.361Z Last Updated: 2025-10-28T11:48:33.361Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix race in do_task() when draining When do_task() exhausts its iteration budget (!ret), it sets the state to TASK_STATE_IDLE to reschedule, without a secondary check on the current task->state. This can overwrite the TASK_STATE_DRAINING state set by a concurrent call to rxe_cleanup_task() or rxe_disable_task(). While state changes are protected by a spinlock, both rxe_cleanup_task() and rxe_disable_task() release the lock while waiting for the task to finish
cted by a spinlock, both rxe_cleanup_task() and rxe_disable_task() release the lock while waiting for the task to finish draining in the while(!is_done(task)) loop. The race occurs if do_task() hits its iteration limit and acquires the lock in this window. The cleanup logic may then proceed while the task incorrectly reschedules itself, leading to a potential use-after-free. This bug was introduced during the migration from tasklets to workqueues, where the special handling for the draining case was lost. Fix this by restoring the original pre-migration behavior. If the state is TASK_STATE_DRAINING when iterations are exhausted, set cont to 1 to force a new loop iteration. This allows the ta
te is TASK_STATE_DRAINING when iterations are exhausted, set cont to 1 to force a new loop iteration. This allows the task to finish its work, so that a subsequent iteration can reach the switch statement and correctly transition the state to TASK_STATE_DRAINED, stopping the task as intended. References: - https://git.kernel.org/stable/c/85288bcf7ffe11e7b036edf91937bc62fd384076 - https://git.kernel.org/stable/c/52edccfb555142678c836c285bf5b4ec760bd043 - https://git.kernel.org/stable/c/660b6959c4170637f5db2279d1f71af33a49e49b - https://git.kernel.org/stable/c/8ca7eada62fcfabf6ec1dc7468941e791c1d8729
CVE ID: CVE-2025-40062 State: PUBLISHED Published: 2025-10-28T11:48:33.961Z Last Updated: 2025-10-28T11:48:33.961Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm - set NULL to qm->debug.qm_diff_regs When the initialization of qm->debug.acc_diff_reg fails, the probe process does not exit. However, after qm->debug.qm_diff_regs is freed, it is not set to NULL. This can lead to a double free when the remove process attempts to free it again. Therefore, qm->debug.qm_diff_regs should be set to NULL after it is freed. References: - https://git.kernel.org/stable/c/a7836260d5121949ba734e840d42a86ab4a32fcc - https://
ULL after it is freed. References: - https://git.kernel.org/stable/c/a7836260d5121949ba734e840d42a86ab4a32fcc - https://git.kernel.org/stable/c/1750f1ec143ebabdbdfa013668665c9d5042c430 - https://git.kernel.org/stable/c/a87a21a56244b8f4eb357f6bad879247005bbe38 - https://git.kernel.org/stable/c/7226a0650ad5705bd8d39a11be270fa21ed1e6a5 - https://git.kernel.org/stable/c/f0cafb02de883b3b413d34eb079c9680782a9cc1
CVE ID: CVE-2025-40063 State: PUBLISHED Published: 2025-10-28T11:48:34.549Z Last Updated: 2025-10-28T11:48:34.549Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: comp - Use same definition of context alloc and free ops In commit 42d9f6c77479 ("crypto: acomp - Move scomp stream allocation code into acomp"), the crypto_acomp_streams struct was made to rely on having the alloc_ctx and free_ctx operations defined in the same order as the scomp_alg struct. But in that same commit, the alloc_ctx and free_ctx members of scomp_alg may be randomized by structure layout randomization, since they are contained in a pure ops struct