Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
re/fbcon.c:122 fbcon_new_modelist+0xbf/0x2d0 drivers/video/fbdev/core/fbcon.c:3048 fb_new_modelist+0x328/0x440 drivers/video/fbdev/core/fbmem.c:673 store_modes+0x1c9/0x3e0 drivers/video/fbdev/core/fbsysfs.c:113 dev_attr_store+0x55/0x80 drivers/base/core.c:2439 static struct fb_info *fbcon_registered_fb[FB_MAX]; ... static signed char con2fb_map[MAX_NR_CONSOLES]; ... static struct fb_info *fbcon_info_from_console(int console) ... return fbcon_registered_fb[con2fb_map[console]]; If con2fb_map contains a -1 things go wrong here. Instead, return NULL, as callers of fbcon_info_from_console() are trying to compare against existing "info" pointers, so error handling should kick in correctly. Additi
rom_console() are trying to compare against existing "info" pointers, so error handling should kick in correctly. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/b3237d451bf3a4490cb1a76f3b7c91d9888f1c4b - https://git.kernel.org/stable/c/519ba75728ee8cd561dce25fc52a2ec5c47171dc - https://git.kernel.org/stable/c/f28f1f578cd810779d01999c60618cda14c281dd - https://git.kernel.org/stable/c/54b28f7c567dd659e5f9562f518e4d7f3f6a367b - https://git.kernel.org/stable/c/cedc1b63394a866bf8663a3e40f4546f1d28c8d8
CVE ID: CVE-2025-38199 State: PUBLISHED Published: 2025-07-04T13:37:21.227Z Last Updated: 2025-07-28T04:14:53.974Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix memory leak due to multiple rx_stats allocation rx_stats for each arsta is allocated when adding a station. arsta->rx_stats will be freed when a station is removed. Redundant allocations are occurring when the same station is added multiple times. This causes ath12k_mac_station_add() to be called multiple times, and rx_stats is allocated each time. As a result there is memory leaks. Prevent multiple allocations of rx_stats when ath12k_mac_station_add(
ated each time. As a result there is memory leaks. Prevent multiple allocations of rx_stats when ath12k_mac_station_add() is called repeatedly by checking if rx_stats is already allocated before allocating again. Allocate arsta->rx_stats if arsta->rx_stats is NULL respectively. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 References: - https://git.kernel.org/stable/c/232f962ae5fca98912a719e64b4964a5aec7c99b - https://git.kernel.org/stable/c/c426497fa2055c8005196922e7d29c41d7e0948a
CVE ID: CVE-2025-38200 State: PUBLISHED Published: 2025-07-04T13:37:22.076Z Last Updated: 2025-11-03T17:35:23.815Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: i40e: fix MMIO write access to an invalid page in i40e_clear_hw When the device sends a specific input, an integer underflow can occur, leading to MMIO write access to an invalid page. Prevent the integer underflow by changing the type of related variables. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/872607632c658d3739e4e7889e4f3c419ae2c193 - https://git.kernel.org/stable/c/5e75c9082987479e647c75ec8fdf18fa68263c42 -
c/872607632c658d3739e4e7889e4f3c419ae2c193 - https://git.kernel.org/stable/c/5e75c9082987479e647c75ec8fdf18fa68263c42 - https://git.kernel.org/stable/c/fecb2fc3fc10c95724407cc45ea35af4a65cdde2 - https://git.kernel.org/stable/c/d88a1e8f024ba26e19350958fecbf771a9960352 - https://git.kernel.org/stable/c/8cde755f56163281ec2c46b4ae8b61f532758a6f - https://git.kernel.org/stable/c/3502dd42f178dae9d54696013386bb52b4f2e655 - https://git.kernel.org/stable/c/2a1f4f2e36442a9bdf771acf6ee86f3cf876e5ca - https://git.kernel.org/stable/c/015bac5daca978448f2671478c553ce1f300c21e
CVE ID: CVE-2025-38201 State: PUBLISHED Published: 2025-07-04T13:37:22.732Z Last Updated: 2025-07-28T04:14:56.757Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when resizing hashtable because __GFP_NOWARN is unset. Similar to: b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX") References: - https://git.kernel.org/stable/c/0ab3de047808f375a36cd345225572eb3366f3c6 - https://git.kernel.org/stable/c/d2768016f091f8a5264076b433fd7c3fabb6eb97 - https://git.kernel.or
cd345225572eb3366f3c6 - https://git.kernel.org/stable/c/d2768016f091f8a5264076b433fd7c3fabb6eb97 - https://git.kernel.org/stable/c/b85e3367a5716ed3662a4fe266525190d2af76df
CVE ID: CVE-2025-38202 State: PUBLISHED Published: 2025-07-04T13:37:23.347Z Last Updated: 2025-11-03T17:35:24.781Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Check rcu_read_lock_trace_held() in bpf_map_lookup_percpu_elem() bpf_map_lookup_percpu_elem() helper is also available for sleepable bpf program. When BPF JIT is disabled or under 32-bit host, bpf_map_lookup_percpu_elem() will not be inlined. Using it in a sleepable bpf program will trigger the warning in bpf_map_lookup_percpu_elem(), because the bpf program only holds rcu_read_lock_trace lock. Therefore, add the missed check. Additional Analyst Notes: - CVE Progr
bpf program only holds rcu_read_lock_trace lock. Therefore, add the missed check. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/2f8c69a72e8ad87b36b8052f789da3cc2b2e186c - https://git.kernel.org/stable/c/7bf4461f1c97207fda757014690d55a447ce859f - https://git.kernel.org/stable/c/2d834477bbc1e8b8a59ff8b0c081529d6bed7b22 - https://git.kernel.org/stable/c/b522d4d334f206284b1a44b0b0b2f99fd443b39b - https://git.kernel.org/stable/c/d4965578267e2e81f67c86e2608481e77e9c8569
CVE ID: CVE-2025-38203 State: PUBLISHED Published: 2025-07-04T13:37:23.975Z Last Updated: 2025-11-03T17:35:25.733Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: jfs: Fix null-ptr-deref in jfs_ioc_trim [ Syzkaller Report ] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000087: 0000 [#1 KASAN: null-ptr-deref in range [0x0000000000000438-0x000000000000043f] CPU: 2 UID: 0 PID: 10614 Comm: syz-executor.0 Not tainted 6.13.0-rc6-gfbfd64d25c7a-dirty #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Sched_ext: serialise (enabled+all), task: runnable_at=-30ms RIP: 0010:jfs
i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Sched_ext: serialise (enabled+all), task: runnable_at=-30ms RIP: 0010:jfs_ioc_trim+0x34b/0x8f0 Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 93 90 82 fe ff 4c 89 ff 31 f6 RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206 RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000a RDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001 RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000 R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438 FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000 CS: 0010 DS:
000000001 R15: 0000000000000438 FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __die_body+0x61/0xb0 ? die_addr+0xb1/0xe0 ? exc_general_protection+0x333/0x510 ? asm_exc_general_protection+0x26/0x30 ? jfs_ioc_trim+0x34b/0x8f0 jfs_ioctl+0x3c8/0x4f0 ? __pfx_jfs_ioctl+0x10/0x10 ? __pfx_jfs_ioctl+0x10/0x10 __se_sys_ioctl+0x269/0x350 ? __pfx___se_sys_ioctl+0x10/0x10 ? do_syscall_64+0xfb/0x210 do_syscall_64+
fs_ioctl+0x10/0x10 __se_sys_ioctl+0x269/0x350 ? __pfx___se_sys_ioctl+0x10/0x10 ? do_syscall_64+0xfb/0x210 do_syscall_64+0xee/0x210 ? syscall_exit_to_user_mode+0x1e0/0x330 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe51f4903ad Code: c3 e8 a7 2b 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d RSP: 002b:00007fe5202250c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fe51f5cbf80 RCX: 00007fe51f4903ad RDX: 0000000020000680 RSI: 00000000c0185879 RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe520225640 R13: 000000000000000e R14: 00007
R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe520225640 R13: 000000000000000e R14: 00007fe51f44fca0 R15: 00007fe52021d000 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:jfs_ioc_trim+0x34b/0x8f0 Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 93 90 82 fe ff 4c 89 ff 31 f6 RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206 RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000a RDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001 RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000 R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001
100f830000 R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438 FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Kernel panic - not syncing: Fatal exception [ Analysis ] We believe that we have found a concurrency bug in the `fs/jfs` module that results in a null pointer dereference. There is a closely related issue which has been fixed: https:/
s/jfs` module that results in a null pointer dereference. There is a closely related issue which has been fixed: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6c1b3599b2feb5c7291f5ac3a36e5fa7cedb234 ... but, unfortunately, the accepted patch appears to still be susceptible to a null pointer dereference under some interleavings. To trigger the bug, we think that `JFS_SBI(ipbmap->i_sb)->bmap` is set to NULL in `dbFreeBits` and then dereferenced in `jfs_ioc_trim`. This bug manifests quite rarely under normal circumstances, but is triggereable from a syz-program. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/0d50
rom a syz-program. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/0d50231d473f89024158dc62624930de45d13718 - https://git.kernel.org/stable/c/a9d41c925069c950e18160e12a7e10e0f58c56fb - https://git.kernel.org/stable/c/4a8cb9908b51500a76f5156423bd295df53bff89 - https://git.kernel.org/stable/c/9806ae34d7d661c372247cd36f83bfa0523d60ed - https://git.kernel.org/stable/c/a4685408ff6c3e2af366ad9a7274f45ff3f394ee
CVE ID: CVE-2025-38204 State: PUBLISHED Published: 2025-07-04T13:37:24.606Z Last Updated: 2025-11-03T17:35:26.756Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: jfs: fix array-index-out-of-bounds read in add_missing_indices stbl is s8 but it must contain offsets into slot which can go from 0 to 127. Added a bound check for that error and return -EIO if the check fails. Also make jfs_readdir return with error if add_missing_indices returns with an error. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/81af4b34fd72d390d7f237c6a545cc6d09707956 - https://git.kernel.org/stable/c/bfa4
ences: - https://git.kernel.org/stable/c/81af4b34fd72d390d7f237c6a545cc6d09707956 - https://git.kernel.org/stable/c/bfa4655d28f338e68d345aed80d19be7999bbce2 - https://git.kernel.org/stable/c/44618bee303bed151ef3a525ff79fbd7689593b5 - https://git.kernel.org/stable/c/c8399564a58fb6ea2ff21a6fd278417943cb51a5 - https://git.kernel.org/stable/c/5dff41a86377563f7a2b968aae00d25b4ceb37c9
CVE ID: CVE-2025-38205 State: PUBLISHED Published: 2025-07-04T13:37:25.242Z Last Updated: 2025-07-28T04:15:02.988Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid divide by zero by initializing dummy pitch to 1 [Why] If the dummy values in `populate_dummy_dml_surface_cfg()` aren't updated then they can lead to a divide by zero in downstream callers like CalculateVMAndRowBytes() [How] Initialize dummy value to a value to avoid divide by zero. References: - https://git.kernel.org/stable/c/8044f981b2cf8c32fe1bd5d1fc991552cdf7ffe0 - https://git.kernel.org/stable/c/7e40f64896e8e3dca471e287672db5ace12ea0be
CVE ID: CVE-2025-38206 State: PUBLISHED Published: 2025-07-04T13:37:25.966Z Last Updated: 2025-11-03T17:35:27.691Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: exfat: fix double free in delayed_free The double free could happen in the following path. exfat_create_upcase_table() exfat_create_upcase_table() : return error exfat_free_upcase_table() : free ->vol_utbl exfat_load_default_upcase_table : return error exfat_kill_sb() delayed_free() exfat_free_upcase_table() <--------- double free This patch set ->vol_util as NULL after freeing it. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/
_util as NULL after freeing it. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/13d8de1b6568dcc31a95534ced16bc0c9a67bc15 - https://git.kernel.org/stable/c/66e84439ec2af776ce749e8540f8fdd257774152 - https://git.kernel.org/stable/c/d3cef0e7a5c1aa6217c51faa9ce8ecac35d6e1fd - https://git.kernel.org/stable/c/1f3d9724e16d62c7d42c67d6613b8512f2887c22
CVE ID: CVE-2025-38207 State: PUBLISHED Published: 2025-07-04T13:37:27.508Z Last Updated: 2025-07-28T04:15:06.073Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm: fix uprobe pte be overwritten when expanding vma Patch series "Fix uprobe pte be overwritten when expanding vma". This patch (of 4): We encountered a BUG alert triggered by Syzkaller as follows: BUG: Bad rss-counter state mm:00000000b4a60fca type:MM_ANONPAGES val:1 And we can reproduce it with the following steps: 1. register uprobe on file at zero offset 2. mmap the file at zero offset: addr1 = mmap(NULL, 2 * 4096, PROT_NONE, MAP_PRIVATE, fd, 0); 3. mremap part of
o offset 2. mmap the file at zero offset: addr1 = mmap(NULL, 2 * 4096, PROT_NONE, MAP_PRIVATE, fd, 0); 3. mremap part of vma1 to new vma2: addr2 = mremap(addr1, 4096, 2 * 4096, MREMAP_MAYMOVE); 4. mremap back to orig addr1: mremap(addr2, 4096, 4096, MREMAP_MAYMOVE | MREMAP_FIXED, addr1); In step 3, the vma1 range [addr1, addr1 + 4096] will be remap to new vma2 with range [addr2, addr2 + 8192], and remap uprobe anon page from the vma1 to vma2, then unmap the vma1 range [addr1, addr1 + 4096]. In step 4, the vma2 range [addr2, addr2 + 4096] will be remap back to the addr range [addr1, addr1 + 4096]. Since the addr range [addr1 + 4096, addr1 + 8192] still maps the file, it will take vma_merge_ne
[addr1, addr1 + 4096]. Since the addr range [addr1 + 4096, addr1 + 8192] still maps the file, it will take vma_merge_new_range to expand the range, and then do uprobe_mmap in vma_complete. Since the merged vma pgoff is also zero offset, it will install uprobe anon page to the merged vma. However, the upcomming move_page_tables step, which use set_pte_at to remap the vma2 uprobe pte to the merged vma, will overwrite the newly uprobe pte in the merged vma, and lead that pte to be orphan. Since the uprobe pte will be remapped to the merged vma, we can remove the unnecessary uprobe_mmap upon merged vma. This problem was first found in linux-6.6.y and also exists in the community syzkaller: http
probe_mmap upon merged vma. This problem was first found in linux-6.6.y and also exists in the community syzkaller: https://lore.kernel.org/all/000000000000ada39605a5e71711@google.com/T/ References: - https://git.kernel.org/stable/c/58b83b9a9a929611a2a2e7d88f45cb0d786b7ee0 - https://git.kernel.org/stable/c/2b12d06c37fd3a394376f42f026a7478d826ed63
CVE ID: CVE-2025-38208 State: PUBLISHED Published: 2025-07-04T13:37:28.226Z Last Updated: 2025-07-28T04:15:12.787Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: smb: client: add NULL check in automount_fullpath page is checked for null in __build_path_from_dentry_optional_prefix when tcon->origin_fullpath is not set. However, the check is missing when it is set. Add a check to prevent a potential NULL pointer dereference. References: - https://git.kernel.org/stable/c/37166d63e42c34846a16001950ecec96229a8d17 - https://git.kernel.org/stable/c/a9e916fa5c7d0ec2256aa44aa24ddd92f529ce35 - https://git.kernel.org/stable/c/cce8e71ca1f7
https://git.kernel.org/stable/c/a9e916fa5c7d0ec2256aa44aa24ddd92f529ce35 - https://git.kernel.org/stable/c/cce8e71ca1f7ad9045707f0d22490c1e9ed1df6c - https://git.kernel.org/stable/c/f1e7a277a1736e12cc4bd6d93b8a5c439b8ca20c
CVE ID: CVE-2025-38209 State: PUBLISHED Published: 2025-07-04T13:37:28.853Z Last Updated: 2025-07-28T04:15:14.351Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: remove tag set when second admin queue config fails Commit 104d0e2f6222 ("nvme-fabrics: reset admin connection for secure concatenation") modified nvme_tcp_setup_ctrl() to call nvme_tcp_configure_admin_queue() twice. The first call prepares for DH-CHAP negotitation, and the second call is required for secure concatenation. However, this change triggered BUG KASAN slab-use-after- free in blk_mq_queue_tag_busy_iter(). This BUG can be recreated by repeating the
ge triggered BUG KASAN slab-use-after- free in blk_mq_queue_tag_busy_iter(). This BUG can be recreated by repeating the blktests test case nvme/063 a few times [1]. When the BUG happens, nvme_tcp_create_ctrl() fails in the call chain below: nvme_tcp_create_ctrl() nvme_tcp_alloc_ctrl() new=true ... Alloc nvme_tcp_ctrl and admin_tag_set nvme_tcp_setup_ctrl() new=true nvme_tcp_configure_admin_queue() new=true ... Succeed nvme_alloc_admin_tag_set() ... Alloc the tag set for admin_tag_set nvme_stop_keep_alive() nvme_tcp_teardown_admin_queue() remove=false nvme_tcp_configure_admin_queue() new=false nvme_tcp_alloc_admin_queue() ... Fail, but do not call nvme_remove_admin_tag_set() nvme_uninit_ctrl(
n_queue() new=false nvme_tcp_alloc_admin_queue() ... Fail, but do not call nvme_remove_admin_tag_set() nvme_uninit_ctrl() nvme_put_ctrl() ... Free up the nvme_tcp_ctrl and admin_tag_set The first call of nvme_tcp_configure_admin_queue() succeeds with new=true argument. The second call fails with new=false argument. This second call does not call nvme_remove_admin_tag_set() on failure, due to the new=false argument. Then the admin tag set is not removed. However, nvme_tcp_create_ctrl() assumes that nvme_tcp_setup_ctrl() would call nvme_remove_admin_tag_set(). Then it frees up struct nvme_tcp_ctrl which has admin_tag_set field. Later on, the timeout handler accesses the admin_tag_set field and
p struct nvme_tcp_ctrl which has admin_tag_set field. Later on, the timeout handler accesses the admin_tag_set field and causes the BUG KASAN slab-use-after-free. To not leave the admin tag set, call nvme_remove_admin_tag_set() when the second nvme_tcp_configure_admin_queue() call fails. Do not return from nvme_tcp_setup_ctrl() on failure. Instead, jump to "destroy_admin" go-to label to call nvme_tcp_teardown_admin_queue() which calls nvme_remove_admin_tag_set(). References: - https://git.kernel.org/stable/c/db1da838b6012e4570c6f81e28ffe1d0ff595948 - https://git.kernel.org/stable/c/e7143706702a209c814ed2c3fc6486c2a7decf6c
CVE ID: CVE-2025-38210 State: PUBLISHED Published: 2025-07-04T13:37:29.663Z Last Updated: 2025-07-28T04:15:15.899Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: configfs-tsm-report: Fix NULL dereference of tsm_ops Unlike sysfs, the lifetime of configfs objects is controlled by userspace. There is no mechanism for the kernel to find and delete all created config-items. Instead, the configfs-tsm-report mechanism has an expectation that tsm_unregister() can happen at any time and cause established config-item access to start failing. That expectation is not fully satisfied. While tsm_report_read(), tsm_report_{is,is_bin}_visible(
cess to start failing. That expectation is not fully satisfied. While tsm_report_read(), tsm_report_{is,is_bin}_visible(), and tsm_report_make_item() safely fail if tsm_ops have been unregistered, tsm_report_privlevel_store() tsm_report_provider_show() fail to check for ops registration. Add the missing checks for tsm_ops having been removed. Now, in supporting the ability for tsm_unregister() to always succeed, it leaves the problem of what to do with lingering config-items. The expectation is that the admin that arranges for the ->remove() (unbind) of the ${tsm_arch}-guest driver is also responsible for deletion of all open config-items. Until that deletion happens, ->probe() (reload / bin
t driver is also responsible for deletion of all open config-items. Until that deletion happens, ->probe() (reload / bind) of the ${tsm_arch}-guest driver fails. This allows for emergency shutdown / revocation of attestation interfaces, and requires coordinated restart. References: - https://git.kernel.org/stable/c/015f04ac884a454d4d8aaa7b67758f047742b1cf - https://git.kernel.org/stable/c/cefbafcbdef011d6ef9414902311afdfba3c33eb - https://git.kernel.org/stable/c/fba4ceaa242d2bdf4c04b77bda41d32d02d3925d
CVE ID: CVE-2025-38211 State: PUBLISHED Published: 2025-07-04T13:37:30.307Z Last Updated: 2025-11-03T17:35:29.579Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix use-after-free of work objects after cm_id destruction The commit 59c68ac31e15 ("iw_cm: free cm_id resources on the last deref") simplified cm_id resource management by freeing cm_id once all references to the cm_id were removed. The references are removed either upon completion of iw_cm event handlers or when the application destroys the cm_id. This commit introduced the use-after-free condition where cm_id_private object could still be in use by event
he cm_id. This commit introduced the use-after-free condition where cm_id_private object could still be in use by event handler works during the destruction of cm_id. The commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to destroying CM IDs") addressed this use-after- free by flushing all pending works at the cm_id destruction. However, still another use-after-free possibility remained. It happens with the work objects allocated for each cm_id_priv within alloc_work_entries() during cm_id creation, and subsequently freed in dealloc_work_entries() once all references to the cm_id are removed. If the cm_id's last reference is decremented in the event handler work, the work object
ences to the cm_id are removed. If the cm_id's last reference is decremented in the event handler work, the work object for the work itself gets removed, and causes the use- after-free BUG below: BUG: KASAN: slab-use-after-free in __pwq_activate_work+0x1ff/0x250 Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091 CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 Workqueue: 0x0 (iw_cm_wq) Call Trace: <TASK> dump_stack_lvl+0x6a/0x90 print_report+0x174/0x554 ? __virt_addr_valid+0x208/0x430 ? __pwq_activate_work+0x1ff/0x250 kasan_report+0xae/0x170 ? __p