deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-68351
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

exfat: fix refcount leak in exfat_find

Fix refcount leaks in `exfat_find` related to `exfat_get_dentry_set`.

Function `exfat_get_dentry_set` would increase the reference counter of
`es->bh` on success. Therefore, `exfat_put_dentry_set` must be called
after `exfat_get_dentry_set` to ensure refcount consistency. This patch
relocate two checks to avoid possible leaks.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/9aee8de970f18c2aaaa348e3de86c38e2d956c1d; https://git.kernel.org/stable/c/d009ff8959d28d2a33aeb96a5f7e7161c421d78f; https://git.kernel.org/stable/c/fc9ce762525e73438d31b613f18bca92a4d3d578
CVE: CVE-2025-68352
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

spi: ch341: fix out-of-bounds memory access in ch341_transfer_one

Discovered by Atuin - Automated Vulnerability Discovery Engine.

The 'len' variable is calculated as 'min(32, trans->len + 1)',
which includes the 1-byte command header.

When copying data from 'trans->tx_buf' to 'ch341->tx_buf + 1', using 'len'
as the length is incorrect because:

1. It causes an out-of-bounds read from 'trans->tx_buf' (which has size
   'trans->len', i.e., 'len - 1' in this context).
2. It can cause an out-of-bounds write to 'ch341->tx_buf' if 'len' is
   CH341_PACKET_LENGTH (32). Writing 32 bytes to ch341->tx_buf + 1
   overflows the buffer.

Fix this by copying 'len - 1' bytes.
References: https://git.kernel.org/stable/c/545d1287e40a55242f6ab68bcc1ba3b74088b1bc; https://git.kernel.org/stable/c/81841da1f30f66a850cc8796d99ba330aad9d696; https://git.kernel.org/stable/c/cad6c0fd6f3c0e76a1f75df4bce3b08a13f08974
CVE: CVE-2025-68353
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

net: vxlan: prevent NULL deref in vxlan_xmit_one

Neither sock4 nor sock6 pointers are guaranteed to be non-NULL in
vxlan_xmit_one, e.g. if the iface is brought down. This can lead to the
following NULL dereference:

  BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
  Oops: Oops: 0000 [#1] SMP NOPTI
  RIP: 0010:vxlan_xmit_one+0xbb3/0x1580
  Call Trace:
   vxlan_xmit+0x429/0x610
   dev_hard_start_xmit+0x55/0xa0
   __dev_queue_xmit+0x6d0/0x7f0
   ip_finish_output2+0x24b/0x590
   ip_output+0x63/0x110

Mentioned commits changed the code path in vxlan_xmit_one and as a side
effect the sock4/6 pointer validity checks in vxlan(6)_get_route were
lost. Fix this by adding back checks.

Since both commits being fixed were released in the same version (v6.7)
and are strongly related, bundle the fixes in a single commit.
References: https://git.kernel.org/stable/c/1f73a56f986005f0bc64ed23873930e2ee4f5911; https://git.kernel.org/stable/c/4ac26aafdc8c7271414e2e7c0b2cb266a26591bc
CVE: CVE-2025-68354
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex

regulator_supply_alias_list was accessed without any locking in
regulator_supply_alias(), regulator_register_supply_alias(), and
regulator_unregister_supply_alias(). Concurrent registration,
unregistration and lookups can race, leading to:

1 use-after-free if an alias entry is removed while being read,
2 duplicate entries when two threads register the same alias,
3 inconsistent alias mappings observed by consumers.

Protect all traversals, insertions and deletions on
regulator_supply_alias_list with the existing regulator_list_mutex.
References: https://git.kernel.org/stable/c/09811a83b214cc15521e0d818e43ae9043e9a28d; https://git.kernel.org/stable/c/0cc15a10c3b4ab14cd71b779fd5c9ca0cb2bc30d; https://git.kernel.org/stable/c/431a1d44ad4866362cc28fc1cc4ca93d84989239
CVE: CVE-2025-68355
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix exclusive map memory leak

When excl_prog_hash is 0 and excl_prog_hash_size is non-zero, the map also
needs to be freed. Otherwise, the map memory will not be reclaimed, just
like the memory leak problem reported by syzbot [1].

syzbot reported:
BUG: memory leak
  backtrace (crc 7b9fb9b4):
    map_create+0x322/0x11e0 kernel/bpf/syscall.c:1512
    __sys_bpf+0x3556/0x3610 kernel/bpf/syscall.c:6131
References: https://git.kernel.org/stable/c/688b745401ab16e2e1a3b504863f0a45fd345638; https://git.kernel.org/stable/c/f[PII_REDACTED]d72fc0e7bc8601234d690dee2178d
CVE: CVE-2025-68356
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

gfs2: Prevent recursive memory reclaim

Function new_inode() returns a new inode with inode->i_mapping->gfp_mask
set to GFP_HIGHUSER_MOVABLE.  This value includes the __GFP_FS flag, so
allocations in that address space can recurse into filesystem memory
reclaim.  We don't want that to happen because it can consume a
significant amount of stack memory.

Worse than that is that it can also deadlock: for example, in several
places, gfs2_unstuff_dinode() is called inside filesystem transactions.
This calls filemap_grab_folio(), which can allocate a new folio, which
can trigger memory reclaim.  If memory reclaim recurses into the
filesystem and starts another transaction, a deadlock will ensue.

To fix these kinds of problems, prevent memory reclaim from recursing
into filesystem code by making sure that the gfp_mask of inode address
spaces doesn't include __GFP_FS.

The "meta" and resource group address spaces were already using GFP_NOFS
as their gfp_mask (which doesn't include __GFP_FS).  The default value
of GFP_HIGHUSER_MOVABLE is less restrictive than GFP_NOFS, though.  To
avoid being overly limiting, use the default value and only knock off
the __GFP_FS flag.  I'm not sure if this will actually make a
difference, but it also shouldn't hurt.

This patch is loosely based on commit ad22c7a043c2 ("xfs: prevent stack
overflows from page cache allocation").

Fixes xfstest generic/273.
References: https://git.kernel.org/stable/c/2c5f4a53476e3cab70adc77b38942c066bd2c17c; https://git.kernel.org/stable/c/49e7347f4644d031306d56cb4d51e467cbdcbc69; https://git.kernel.org/stable/c/9c0960ed112398bdb6c60ccf6e6b583bc59acede
CVE: CVE-2025-68357
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

iomap: allocate s_dio_done_wq for async reads as well

Since commit 222f2c7c6d14 ("iomap: always run error completions in user
context"), read error completions are deferred to s_dio_done_wq.  This
means the workqueue also needs to be allocated for async reads.
References: https://git.kernel.org/stable/c/51297686e00f4d5d941b0f20f12b2f12879d753c; https://git.kernel.org/stable/c/7fd8720dff2d9c70cf5a1a13b7513af01952ec02; https://git.kernel.org/stable/c/bfc717be833fd9ee41443fde2dea0352a7fca333
CVE: CVE-2025-68359
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix double free of qgroup record after failure to add delayed ref head

In the previous code it was possible to incur into a double kfree()
scenario when calling add_delayed_ref_head(). This could happen if the
record was reported to already exist in the
btrfs_qgroup_trace_extent_nolock() call, but then there was an error
later on add_delayed_ref_head(). In this case, since
add_delayed_ref_head() returned an error, the caller went to free the
record. Since add_delayed_ref_head() couldn't set this kfree'd pointer
to NULL, then kfree() would have acted on a non-NULL 'record' object
which was pointing to memory already freed by the callee.

The problem comes from the fact that the responsibility to kfree the
object is on both the caller and the callee at the same time. Hence, the
fix for this is to shift the ownership of the 'qrecord' object out of
the add_delayed_ref_head(). That is, we will never attempt to kfree()
the given object inside of this function, and will expect the caller to
act on the 'qrecord' object on its own. The only exception where the
'qrecord' object cannot be kfree'd is if it was inserted into the
tracing logic, for which we already have the 'qrecord_inserted_ret'
boolean to account for this. Hence, the caller has to kfree the object
only if add_delayed_ref_head() reports not to have inserted it on the
tracing logic.

As a side-effect of the above, we must guarantee that
'qrecord_inserted_ret' is properly initialized at the start of the
function, not at the end, and then set when an actual insert
happens. This way we avoid 'qrecord_inserted_ret' having an invalid
value on an early exit.

The documentation from the add_delayed_ref_head() has also been updated
to reflect on the exact ownership of the 'qrecord' object.
References: https://git.kernel.org/stable/c/364685c4c2d9c9f4408d95451bcf42fdeebc3ebb; https://git.kernel.org/stable/c/725e46298876a2cc1f1c3fb22ba69d29102c3ddf; https://git.kernel.org/stable/c/[PII_REDACTED]e3119dfb3b43a2b7c287ce2242211c
CVE: CVE-2025-68361
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

erofs: limit the level of fs stacking for file-backed mounts

Otherwise, it could cause potential kernel stack overflow (e.g., EROFS
mounting itself).
References: https://git.kernel.org/stable/c/34447aeedbaea8f9aad3da5b07030a1c0e124639; https://git.kernel.org/stable/c/620472e6b303c4dbcc7ecf1aba1cda4f3523e4a4; https://git.kernel.org/stable/c/b[PII_REDACTED]a494e894e6ccfcf88d99e9425f129
CVE: CVE-2025-68362
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb()

The rtl8187_rx_cb() calculates the rx descriptor header address
by subtracting its size from the skb tail pointer.
However, it does not validate if the received packet
(skb->len from urb->actual_length) is large enough to contain this
header.

If a truncated packet is received, this will lead to a buffer
underflow, reading memory before the start of the skb data area,
and causing a kernel panic.

Add length checks for both rtl8187 and rtl8187b descriptor headers
before attempting to access them, dropping the packet cleanly if the
check fails.
References: https://git.kernel.org/stable/c/118e12bf3e4288cf845cd3759bd9d4c99f91aab5; https://git.kernel.org/stable/c/4758770a673c60d8f615809304d72e1432fa6355; https://git.kernel.org/stable/c/5ebf0fe7eaef9f6173a4c6ea77c5353e21645d15
CVE: CVE-2025-68363
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Check skb->transport_header is set in bpf_skb_check_mtu

The bpf_skb_check_mtu helper needs to use skb->transport_header when
the BPF_MTU_CHK_SEGS flag is used:

	bpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS)

The transport_header is not always set. There is a WARN_ON_ONCE
report when CONFIG_DEBUG_NET is enabled + skb->gso_size is set +
bpf_prog_test_run is used:

WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071
 skb_gso_validate_network_len
 bpf_skb_check_mtu
 bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch
 bpf_test_run
 bpf_prog_test_run_skb

For a normal ingress skb (not test_run), skb_reset_transport_header
is performed but there is plan to avoid setting it as described in
commit 2170a1f09148 ("net: no longer reset transport_header in __netif_receive_skb_core()").

This patch fixes the bpf helper by checking
skb_transport_header_was_set(). The check is done just before
skb->transport_header is used, to avoid breaking the existing bpf prog.
The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.
References: https://git.kernel.org/stable/c/1c30e4afc5507f0069cc09bd561e510e4d97fbf7; https://git.kernel.org/stable/c/30ce906557a21adef4cba5901c8e995dc18263a9; https://git.kernel.org/stable/c/942268e2726ac7f16e3ec49dbfbbbe7cf5af9da5
CVE: CVE-2025-68364
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()

In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' just
to avoid crashing the whole kernel due to a filesystem corruption.
References: https://git.kernel.org/stable/c/08b93c1c12c[PII_REDACTED]3d733475c64d14de5d2; https://git.kernel.org/stable/c/1ad2f81a099b8df5f72bce0a3e9f531263a846b8; https://git.kernel.org/stable/c/7abbe41d22a06aae00fd46d29f59dd40a01e988f
CVE: CVE-2025-68365
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Initialize allocated memory before use

KMSAN reports: Multiple uninitialized values detected:

- KMSAN: uninit-value in ntfs_read_hdr (3)
- KMSAN: uninit-value in bcmp (3)

Memory is allocated by __getname(), which is a wrapper for
kmem_cache_alloc(). This memory is used before being properly
cleared. Change kmem_cache_alloc() to kmem_cache_zalloc() to
properly allocate and clear memory before use.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/192e8ce302f14ac66259231dd10cede19858d742; https://git.kernel.org/stable/c/7d52c592cf53f5bb7163967edc01d2d7d80de44a; https://git.kernel.org/stable/c/a58e29849aef8d26554a982989a2190b49aaf8ed
CVE: CVE-2025-68366
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

nbd: defer config unlock in nbd_genl_connect

There is one use-after-free warning when running NBD_CMD_CONNECT and
NBD_CLEAR_SOCK:

nbd_genl_connect
  nbd_alloc_and_init_config // config_refs=1
  nbd_start_device // config_refs=2
  set NBD_RT_HAS_CONFIG_REF			open nbd // config_refs=3
  recv_work done // config_refs=2
						NBD_CLEAR_SOCK // config_refs=1
						close nbd // config_refs=0
  refcount_inc -> uaf

------------[ cut here ]------------
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290
 nbd_genl_connect+0x16d0/0x1ab0
 genl_family_rcv_msg_doit+0x1f3/0x310
 genl_rcv_msg+0x44a/0x790

The issue can be easily reproduced by adding a small delay before
refcount_inc(&nbd->config_refs) in nbd_genl_connect():

        mutex_unlock(&nbd->config_lock);
        if (!ret) {
                set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags);
+               printk("before sleep\n");
+               mdelay(5 * 1000);
+               printk("after sleep\n");
                refcount_inc(&nbd->config_refs);
                nbd_connect_reply(info, nbd->index);
        }
References: https://git.kernel.org/stable/c/1649714b930f9ea6233ce0810ba885999da3b5d4; https://git.kernel.org/stable/c/2e5e0665a594f076ef2b9439447bae8be293d09d; https://git.kernel.org/stable/c/330d688a5ca[PII_REDACTED]1a3cf31b92ad1b0b3ed
CVE: CVE-2025-68368
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

md: init bioset in mddev_init

IO operations may be needed before md_run(), such as updating metadata
after writing sysfs. Without bioset, this triggers a NULL pointer
dereference as below:

 BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
 Call Trace:
  md_update_sb+0x658/0xe00
  new_level_store+0xc5/0x120
  md_attr_store+0xc9/0x1e0
  sysfs_kf_write+0x6f/0xa0
  kernfs_fop_write_iter+0x141/0x2a0
  vfs_write+0x1fc/0x5a0
  ksys_write+0x79/0x180
  __x64_sys_write+0x1d/0x30
  x64_sys_call+0x2818/0x2880
  do_syscall_64+0xa9/0x580
  entry_SYSCALL_64_after_hwframe+0x4b/0x53

Reproducer
```
  mdadm -CR /dev/md0 -l1 -n2 /dev/sd[cd]
  echo inactive > /sys/block/md0/md/array_state
  echo 10 > /sys/block/md0/md/new_level
```

mddev_init() can only be called once per mddev, no need to test if bioset
has been initialized anymore.
References: https://git.kernel.org/stable/c/381a3ce1c0ffed647c9b913e142b099c7e9d5afc; https://git.kernel.org/stable/c/9d37fe37dfa0833a8768740f0575e0ffd793cb4a
CVE: CVE-2025-68369
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ntfs3: init run lock for extend inode

After setting the inode mode of $Extend to a regular file, executing the
truncate system call will enter the do_truncate() routine, causing the
run_lock uninitialized error reported by syzbot.

Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to
a regular file, the do_truncate() routine would not be entered.

Add the run_lock initialization when loading $Extend.

syzbot reported:
INFO: trying to register non-static key.
Call Trace:
 dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
 assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984
 register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299
 __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112
 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868
 down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590
 ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860
 ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387
 ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808
References: https://git.kernel.org/stable/c/19164d8228317f3f1fe2662a9ba587cfe3b2d29e; https://git.kernel.org/stable/c/433d1f7c628c3cbdd7efce064d6c7acd072cf6c4; https://git.kernel.org/stable/c/6e17555728bc469d484c59db4a0abc65c19bc315
CVE: CVE-2025-68370
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

coresight: tmc: add the handle of the event to the path

The handle is essential for retrieving the AUX_EVENT of each CPU and is
required in perf mode. It has been added to the coresight_path so that
dependent devices can access it from the path when needed.

The existing bug can be reproduced with:
perf record -e cs_etm//k -C 0-9 dd if=/dev/zero of=/dev/null

Showing an oops as follows:
Unable to handle kernel paging request at virtual address 000f6e84934ed19e

Call trace:
 tmc_etr_get_buffer+0x30/0x80 [coresight_tmc] (P)
 catu_enable_hw+0xbc/0x3d0 [coresight_catu]
 catu_enable+0x70/0xe0 [coresight_catu]
 coresight_enable_path+0xb0/0x258 [coresight]
References: https://git.kernel.org/stable/c/aaa5abcc9d44d2c8484f779ab46d242d774cabcb; https://git.kernel.org/stable/c/d0c9effd82f2c19b92acd07d357fac5f392d549a; https://git.kernel.org/stable/c/faa8f38f7ccb344ace2c1f364efc70e3a12d32f3
CVE: CVE-2025-68371
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: smartpqi: Fix device resources accessed after device removal

Correct possible race conditions during device removal.

Previously, a scheduled work item to reset a LUN could still execute
after the device was removed, leading to use-after-free and other
resource access issues.

This race condition occurs because the abort handler may schedule a LUN
reset concurrently with device removal via sdev_destroy(), leading to
use-after-free and improper access to freed resources.

  - Check in the device reset handler if the device is still present in
    the controller's SCSI device list before running; if not, the reset
    is skipped.

  - Cancel any pending TMF work that has not started in sdev_destroy().

  - Ensure device freeing in sdev_destroy() is done while holding the
    LUN reset mutex to avoid races with ongoing resets.
References: https://git.kernel.org/stable/c/1a5c5a2f88e839af5320216a02ffb075b668596a; https://git.kernel.org/stable/c/4e1acf1b6dd6dd0495bda139daafd7a403ae2dc1; https://git.kernel.org/stable/c/6d2390653d82cad0e1ba2676e536dd99678f6ef1
CVE: CVE-2025-68372
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

nbd: defer config put in recv_work

There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and
NBD_CMD_RECONFIGURE:
  nbd_genl_connect     // conf_ref=2 (connect and recv_work A)
  nbd_open	       // conf_ref=3
  recv_work A done     // conf_ref=2
  NBD_CLEAR_SOCK       // conf_ref=1
  nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B)
  close nbd	       // conf_ref=1
  recv_work B
    config_put         // conf_ref=0
    atomic_dec(&config->recv_threads); -> UAF

Or only running NBD_CLEAR_SOCK:
  nbd_genl_connect   // conf_ref=2
  nbd_open 	     // conf_ref=3
  NBD_CLEAR_SOCK     // conf_ref=2
  close nbd
    nbd_release
      config_put     // conf_ref=1
  recv_work
    config_put 	     // conf_ref=0
    atomic_dec(&config->recv_threads); -> UAF

Commit 87aac3a80af5 ("nbd: call nbd_config_put() before notifying the
waiter") moved nbd_config_put() to run before waking up the waiter in
recv_work, in order to ensure that nbd_start_device_ioctl() would not
be woken up while nbd->task_recv was still uncleared.

However, in nbd_start_device_ioctl(), after being woken up it explicitly
calls flush_workqueue() to make sure all current works are finished.
Therefore, there is no need to move the config put ahead of the wakeup.

Move nbd_config_put() to the end of recv_work, so that the reference is
held for the whole lifetime of the worker thread. This makes sure the
config cannot be freed while recv_work is still running, even if clear
+ reconfigure interleave.

In addition, we don't need to worry about recv_work dropping the last
nbd_put (which causes deadlock):

path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT):
  connect  // nbd_refs=1 (trigger recv_work)
  open nbd // nbd_refs=2
  NBD_CLEAR_SOCK
  close nbd
    nbd_release
      nbd_disconnect_and_put
        flush_workqueue // recv_work done
      nbd_config_put
        nbd_put // nbd_refs=1
      nbd_put // nbd_refs=0
        queue_work

path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT):
  connect  // nbd_refs=2 (trigger recv_work)
  open nbd // nbd_refs=3
  NBD_CLEAR_SOCK // conf_refs=2
  close nbd
    nbd_release
      nbd_config_put // conf_refs=1
      nbd_put // nbd_refs=2
  recv_work done // conf_refs=0, nbd_refs=1
  rmmod // nbd_refs=0

Depends-on: e2daec488c57 ("nbd: Fix hungtask when nbd_config_put")
References: https://git.kernel.org/stable/c/198aa230a6f8c1f6af7ed26b29180749c3e79e4d; https://git.kernel.org/stable/c/1ba2ced2bbdf7e64a30c3e88c70ea8bc208d1509; https://git.kernel.org/stable/c/3692884bd6187d89d41eef81e5a9724519fd01c1
CVE: CVE-2025-68373
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

md: avoid repeated calls to del_gendisk

There is a uaf problem which is found by case 23rdev-lifetime:

Oops: general protection fault, probably for non-canonical address 0xdead[PII_REDACTED]22
RIP: 0010:bdi_unregister+0x4b/0x170
Call Trace:
 <TASK>
 __del_gendisk+0x356/0x3e0
 mddev_unlock+0x351/0x360
 rdev_attr_store+0x217/0x280
 kernfs_fop_write_iter+0x14a/0x210
 vfs_write+0x29e/0x550
 ksys_write+0x74/0xf0
 do_syscall_64+0xbb/0x380
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7ff5250a177e

The sequence is:
1. rdev remove path gets reconfig_mutex
2. rdev remove path release reconfig_mutex in mddev_unlock
3. md stop calls do_md_stop and sets MD_DELETED
4. rdev remove path calls del_gendisk because MD_DELETED is set
5. md stop path release reconfig_mutex and calls del_gendisk again

So there is a race condition we should resolve. This patch adds a
flag MD_DO_DELETE to avoid the race condition.
References: https://git.kernel.org/stable/c/90e3bb44c0a86e245d8e5c6520206fa113acb1ee; https://git.kernel.org/stable/c/b4c5cf406062ad44cd[PII_REDACTED]0c6435b2f3b; https://git.kernel.org/stable/c/f0fae1debeb9102398ddf2ef69b4f5d395afafed
CVE: CVE-2025-68374
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

md: fix rcu protection in md_wakeup_thread

We attempted to use RCU to protect the pointer 'thread', but directly
passed the value when calling md_wakeup_thread(). This means that the
RCU pointer has been acquired before rcu_read_lock(), which renders
rcu_read_lock() ineffective and could lead to a use-after-free.
References: https://git.kernel.org/stable/c/0dc76205549b4c25705e54345f211b9f66e018a0; https://git.kernel.org/stable/c/21989cb5034c835b212385a2afadf279d8069da0; https://git.kernel.org/stable/c/a4bd1caf591faeae44cb10b6517e7dacb5139bda