deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-38193
Published: 2025-07-04
Description: In the Linux kernel, the following vulnerability has been resolved:

net_sched: sch_sfq: reject invalid perturb period

Gerrard Tai reported that SFQ perturb_period has no range check yet,
and this can be used to trigger a race condition fixed in a separate patch.

We want to make sure ctl->perturb_period * HZ will not overflow
and is positive.


tc qd add dev lo root sfq perturb -10   # negative value : error
Error: sch_sfq: invalid perturb period.

tc qd add dev lo root sfq perturb[PII_REDACTED] # too big : error
Error: sch_sfq: invalid perturb period.

tc qd add dev lo root sfq perturb 2000000 # acceptable value
tc -s -d qd sh dev lo
qdisc sfq 8005: root refcnt 2 limit 127p quantum 64Kb depth 127 flows 128 divisor 1024 perturb 2000000sec
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190
References: https://git.kernel.org/stable/c/0357da9149eac621f39e235a135ebf155f01f7c3; https://git.kernel.org/stable/c/2254d038dab9c194fe6a4b1ce31034f42e91a6e5; https://git.kernel.org/stable/c/590b2d7d0beadba2aa576708a05a05f0aae39295
CVE: CVE-2025-38194
Published: 2025-07-04
Description: In the Linux kernel, the following vulnerability has been resolved:

jffs2: check that raw node were preallocated before writing summary

Syzkaller detected a kernel bug in jffs2_link_node_ref, caused by fault
injection in jffs2_prealloc_raw_node_refs. jffs2_sum_write_sumnode doesn't
check return value of jffs2_prealloc_raw_node_refs and simply lets any
error propagate into jffs2_sum_write_data, which eventually calls
jffs2_link_node_ref in order to link the summary to an expectedly allocated
node.

kernel BUG at fs/jffs2/nodelist.c:592!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI
CPU: 1 PID: 31277 Comm: syz-executor.7 Not tainted 6.1.128-syzkaller-00139-ge10f83ca10a1 #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
RIP: 0010:jffs2_link_node_ref+0x570/0x690 fs/jffs2/nodelist.c:592
Call Trace:
 <TASK>
 jffs2_sum_write_data fs/jffs2/summary.c:841 [inline]
 jffs2_sum_write_sumnode+0xd1a/0x1da0 fs/jffs2/summary.c:874
 jffs2_do_reserve_space+0xa18/0xd60 fs/jffs2/nodemgmt.c:388
 jffs2_reserve_space+0x55f/0xaa0 fs/jffs2/nodemgmt.c:197
 jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362
 jffs2_write_end+0x726/0x15d0 fs/jffs2/file.c:301
 generic_perform_write+0x314/0x5d0 mm/filemap.c:3856
 __generic_file_write_iter+0x2ae/0x4d0 mm/filemap.c:3973
 generic_file_write_iter+0xe3/0x350 mm/filemap.c:4005
 call_write_iter include/linux/fs.h:2265 [inline]
 do_iter_readv_writev+0x20f/0x3c0 fs/read_write.c:735
 do_iter_write+0x186/0x710 fs/read_write.c:861
 vfs_iter_write+0x70/0xa0 fs/read_write.c:902
 iter_file_splice_write+0x73b/0xc90 fs/splice.c:685
 do_splice_from fs/splice.c:763 [inline]
 direct_splice_actor+0x10c/0x170 fs/splice.c:950
 splice_direct_to_actor+0x337/0xa10 fs/splice.c:896
 do_splice_direct+0x1a9/0x280 fs/splice.c:1002
 do_sendfile+0xb13/0x12c0 fs/read_write.c:1255
 __do_sys_sendfile64 fs/read_write.c:1323 [inline]
 __se_sys_sendfile64 fs/read_write.c:1309 [inline]
 __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81
 entry_SYSCALL_64_after_hwframe+0x6e/0xd8

Fix this issue by checking return value of jffs2_prealloc_raw_node_refs
before calling jffs2_sum_write_data.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/337f80f3d546e131c7aa90b61d8cde051ae858c7; https://git.kernel.org/stable/c/346cfb9d19ea7feb6fb57917b21c4797fb444dab; https://git.kernel.org/stable/c/3f46644a5131a4793fc95c32a7d0a769745b06e7
CVE: CVE-2025-38195
Published: 2025-07-04
Description: In the Linux kernel, the following vulnerability has been resolved:

LoongArch: Fix panic caused by NULL-PMD in huge_pte_offset()

ERROR INFO:

CPU 25 Unable to handle kernel paging request at virtual address 0x0
         ...
 Call Trace:
 [<[PII_REDACTED]23c30c>] huge_pte_offset+0x3c/0x58
 [<[PII_REDACTED]57fd4c>] hugetlb_follow_page_mask+0x74/0x438
 [<[PII_REDACTED]51fee8>] __get_user_pages+0xe0/0x4c8
 [<[PII_REDACTED]>] faultin_page_range+0x84/0x380
 [<[PII_REDACTED]564e8c>] madvise_vma_behavior+0x534/0xa48
 [<[PII_REDACTED]56689c>] do_madvise+0x1bc/0x3e8
 [<[PII_REDACTED]566df4>] sys_madvise+0x24/0x38
 [<[PII_REDACTED]5b9e88>] do_syscall+0x78/0x98
 [<[PII_REDACTED]221f18>] handle_syscall+0xb8/0x158

In some cases, pmd may be NULL and rely on NULL as the return value for
processing, so it is necessary to determine this situation here.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/985f086f281b7bbb6644851e63af1a17ffff9277; https://git.kernel.org/stable/c/b427d98d55217b53c88643579fbbd8a4c351a105; https://git.kernel.org/stable/c/b5c7397b7fd125203c60b59860c168ee92291272
CVE: CVE-2025-38196
Published: 2025-07-04
Description: In the Linux kernel, the following vulnerability has been resolved:

io_uring/rsrc: validate buffer count with offset for cloning

syzbot reports that it can trigger a WARN_ON() for kmalloc() attempt
that's too big:

WARNING: CPU: 0 PID: 6488 at mm/slub.c:5024 __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024
Modules linked in:
CPU: 0 UID: 0 PID: 6488 Comm: syz-executor312 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024
lr : __do_kmalloc_node mm/slub.c:-1 [inline]
lr : __kvmalloc_node_noprof+0x3b4/0x640 mm/slub.c:5012
sp : ffff80009cfd7a90
x29: ffff80009cfd7ac0 x28: ffff0000dd52a120 x27:[PII_REDACTED]412dc0
x26: [PII_REDACTED] x25: ffff7000139faf70 x24: [PII_REDACTED]
x23: ffff800082f4cea8 x22: 00000000ffffffff x21: 000000010cd004a8
x20: ffff0000d75816c0 x19: ffff0000dd52a000 x18: 00000000ffffffff
x17: ffff800092f39000 x16: ffff80008adbe9e4 x15: [PII_REDACTED]
x14: 1ffff000139faf1c x13: [PII_REDACTED] x12: [PII_REDACTED]
x11: ffff7000139faf21 x10: [PII_REDACTED] x9 : ffff80008f27b938
x8 : [PII_REDACTED] x7 : [PII_REDACTED] x6 : [PII_REDACTED]
x5 : 00000000ffffffff x4 :[PII_REDACTED]400dc0 x3 : [PII_REDACTED]
x2 : 000000010cd004a8 x1 : ffff80008b3ebc40 x0 : [PII_REDACTED]
Call trace:
 __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024 (P)
 kvmalloc_array_node_noprof include/linux/slab.h:1065 [inline]
 io_rsrc_data_alloc io_uring/rsrc.c:206 [inline]
 io_clone_buffers io_uring/rsrc.c:1178 [inline]
 io_register_clone_buffers+0x484/0xa14 io_uring/rsrc.c:1287
 __io_uring_register io_uring/register.c:815 [inline]
 __do_sys_io_uring_register io_uring/register.c:926 [inline]
 __se_sys_io_uring_register io_uring/register.c:903 [inline]
 __arm64_sys_io_uring_register+0x42c/0xea8 io_uring/register.c:903
 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
 invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49
 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132
 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151
 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767
 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786
 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600

which is due to offset + buffer_count being too large. The registration
code checks only the total count of buffers, but given that the indexing
is an array, it should also check offset + count. That can't exceed
IORING_MAX_REG_BUFFERS either, as there's no way to reach buffers beyond
that limit.

There's no issue with registrering a table this large, outside of the
fact that it's pointless to register buffers that cannot be reached, and
that it can trigger this kmalloc() warning for attempting an allocation
that is too large.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0e23ac818f3afb16660b0ba384875d56a7013879; https://git.kernel.org/stable/c/1d27f11bf02b38c431e49a17dee5c10a2b4c2e28
CVE: CVE-2025-38197
Published: 2025-07-04
Description: In the Linux kernel, the following vulnerability has been resolved:

platform/x86: dell_rbu: Fix list usage

Pass the correct list head to list_for_each_entry*() when looping through
the packet list.

Without this patch, reading the packet data via sysfs will show the data
incorrectly (because it starts at the wrong packet), and clearing the
packet list will result in a NULL pointer dereference.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/07d7b8e7ef7d1f812a6211ed531947c56d09e95e; https://git.kernel.org/stable/c/32d05e6cc3a7bf6c8f16f7b7ef8fe80eca0c233e; https://git.kernel.org/stable/c/4d71f2c1e5263a9f042faa71d[PII_REDACTED]9dc79
CVE: CVE-2025-38198
Published: 2025-07-04
Description: In the Linux kernel, the following vulnerability has been resolved:

fbcon: Make sure modelist not set on unregistered console

It looks like attempting to write to the "store_modes" sysfs node will
run afoul of unregistered consoles:

UBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28
index -1 is out of range for type 'fb_info *[32]'
...
 fbcon_info_from_console+0x192/0x1a0 drivers/video/fbdev/core/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.
CVSS Score: 7.8 (HIGH)
CWE: CWE-129
References: https://git.kernel.org/stable/c/519ba75728ee8cd561dce25fc52a2ec5c47171dc; https://git.kernel.org/stable/c/54b28f7c567dd659e5f9562f518e4d7f3f6a367b; https://git.kernel.org/stable/c/b3237d451bf3a4490cb1a76f3b7c91d9888f1c4b
CVE: CVE-2025-38199
Published: 2025-07-04
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()
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
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/232f962ae5fca98912a719e64b4964a5aec7c99b; https://git.kernel.org/stable/c/c426497fa2055c[PII_REDACTED]e7d29c41d7e0948a
CVE: CVE-2025-38200
Published: 2025-07-04
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.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-191
References: https://git.kernel.org/stable/c/015bac5daca978448f2671478c553ce1f300c21e; https://git.kernel.org/stable/c/2a1f4f2e36442a9bdf771acf6ee86f3cf876e5ca; https://git.kernel.org/stable/c/3502dd42f178dae9d[PII_REDACTED]6bb52b4f2e655
CVE: CVE-2025-38201
Published: 2025-07-04
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")
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/0ab3de047808f375a36cd345225572eb3366f3c6; https://git.kernel.org/stable/c/1fe27f97944017a9d3c5af4d6d95282bff0f1147; https://git.kernel.org/stable/c/4abccfb61f422300be014b8e734c63344306f009
CVE: CVE-2025-38202
Published: 2025-07-04
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.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2d834477bbc1e8b8a59ff8b0c081529d6bed7b22; https://git.kernel.org/stable/c/2f8c69a72e8ad87b36b8052f789da3cc2b2e186c; https://git.kernel.org/stable/c/7bf4461f1c97207fda757014690d55a447ce859f
CVE: CVE-2025-38204
Published: 2025-07-04
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.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/44618bee303bed151ef3a525ff79fbd7689593b5; https://git.kernel.org/stable/c/5dff41a86377563f7a2b968aae00d25b4ceb37c9; https://git.kernel.org/stable/c/81af4b34fd72d390d7f237c6a545cc6d09707956
CVE: CVE-2025-38205
Published: 2025-07-04
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.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-369
References: https://git.kernel.org/stable/c/7e40f64896e8e3dca471e287672db5ace12ea0be; https://git.kernel.org/stable/c/8044f981b2cf8c32fe1bd5d1fc991552cdf7ffe0
CVE: CVE-2025-38206
Published: 2025-07-04
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.
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/13d8de1b6568dcc31a95534ced16bc0c9a67bc15; https://git.kernel.org/stable/c/1f3d9724e16d62c7d42c67d6613b8512f2887c22; https://git.kernel.org/stable/c/66e84439ec2af776ce749e8540f8fdd257774152
CVE: CVE-2025-38207
Published: 2025-07-04
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 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_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:
https://lore.kernel.org/all/[PII_REDACTED]00ada39605a5e71711@google.com/T/
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2b12d06c37fd3a394376f42f026a7478d826ed63; https://git.kernel.org/stable/c/58b83b9a9a929611a2a2e7d88f45cb0d786b7ee0
CVE: CVE-2025-38208
Published: 2025-07-04
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.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/37166d63e42c34846a16001950ecec96229a8d17; https://git.kernel.org/stable/c/a9e916fa5c7d0ec2256aa44aa24ddd92f529ce35; https://git.kernel.org/stable/c/cce8e71ca1f7ad9045707f0d22490c1e9ed1df6c
CVE: CVE-2025-38209
Published: 2025-07-04
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 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()
 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 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().
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/db1da838b6012e4570c6f81e28ffe1d0ff595948; https://git.kernel.org/stable/c/e[PII_REDACTED]a209c814ed2c3fc6486c2a7decf6c
CVE: CVE-2025-38210
Published: 2025-07-04
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(), 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 /
bind) of the ${tsm_arch}-guest driver fails.

This allows for emergency shutdown / revocation of attestation
interfaces, and requires coordinated restart.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/015f04ac884a454d4d8aaa7b67758f047742b1cf; https://git.kernel.org/stable/c/cefbafcbdef011d6ef[PII_REDACTED]afdfba3c33eb; https://git.kernel.org/stable/c/fba4ceaa242d2bdf4c04b77bda41d32d02d3925d
CVE: CVE-2025-38212
Published: 2025-07-04
Description: In the Linux kernel, the following vulnerability has been resolved:

ipc: fix to protect IPCS lookups using RCU

syzbot reported that it discovered a use-after-free vulnerability, [0]

[0]: https://lore.kernel.org/all/67af13f8.050a0220.21dd3.0038.GAE@google.com/

idr_for_each() is protected by rwsem, but this is not enough.  If it is
not protected by RCU read-critical region, when idr_for_each() calls
radix_tree_node_free() through call_rcu() to free the radix_tree_node
structure, the node will be freed immediately, and when reading the next
node in radix_tree_for_each_slot(), the already freed memory may be read.

Therefore, we need to add code to make sure that idr_for_each() is
protected within the RCU read-critical region when we call it in
shm_destroy_orphaned().
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/5180561afff8e0f029073c8c8117c95c6512d1f9; https://git.kernel.org/stable/c/5f1e1573bf103303944fd7225559de5d8297539c; https://git.kernel.org/stable/c/68c173ea138b66d7dd1fd980c9bc578a18e11884
CVE: CVE-2025-38213
Published: 2025-07-04
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.