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

rcu/nocb: Fix possible invalid rdp's->nocb_cb_kthread pointer access

In the preparation stage of CPU online, if the corresponding
the rdp's->nocb_cb_kthread does not exist, will be created,
there is a situation where the rdp's rcuop kthreads creation fails,
and then de-offload this CPU's rdp, does not assign this CPU's
rdp->nocb_cb_kthread pointer, but this rdp's->nocb_gp_rdp and
rdp's->rdp_gp->nocb_gp_kthread is still valid.

This will cause the subsequent re-offload operation of this offline
CPU, which will pass the conditional check and the kthread_unpark()
will access invalid rdp's->nocb_cb_kthread pointer.

This commit therefore use rdp's->nocb_gp_kthread instead of
rdp_gp's->nocb_gp_kthread for safety check.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/1bba3900ca18bdae28d1b9fa10f16a8f8cb2ada1; https://git.kernel.org/stable/c/1c951683a720b17c9ecaad1932bc95b29044611f; https://git.kernel.org/stable/c/3da45ec1e485a1a5ad31fe9ddd467c7ee5ae4ef9
CVE: CVE-2025-38705
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/pm: fix null pointer access

Writing a string without delimiters (' ', '\n', '\0') to the under
gpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profile
will result in a null pointer dereference.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/5d8cc029e5595760c7d18c64632e8e40a86a9b2e; https://git.kernel.org/stable/c/a83ffafd02a7af59848755c109d544e3894af737; https://git.kernel.org/stable/c/cef79c18538e9ce2ca6e5b3fa95c38ec41dcd07a
CVE: CVE-2025-38706
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime()

snd_soc_remove_pcm_runtime() might be called with rtd == NULL which will
leads to null pointer dereference.
This was reproduced with topology loading and marking a link as ignore
due to missing hardware component on the system.
On module removal the soc_tplg_remove_link() would call
snd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored,
no runtime was created.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2d91cb261cac6d885954b8f5da28b5c176c18131; https://git.kernel.org/stable/c/2fce20decc6a83f16dd73744150c4e7ea6c97c21; https://git.kernel.org/stable/c/41f53afe53a57a7c50323f99424b598190acf192
CVE: CVE-2025-38707
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Add sanity check for file name

The length of the file name should be smaller than the directory entry size.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/27ee9a42b245efe6529e28b03453291a775cb3e4; https://git.kernel.org/stable/c/2ac47f738ddfc1957a33be163bc97ee8f78e85a6; https://git.kernel.org/stable/c/3572737a768dadea904ebc4eb34b6ed575bb72d9
CVE: CVE-2025-38708
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

drbd: add missing kref_get in handle_write_conflicts

With `two-primaries` enabled, DRBD tries to detect "concurrent" writes
and handle write conflicts, so that even if you write to the same sector
simultaneously on both nodes, they end up with the identical data once
the writes are completed.

In handling "superseeded" writes, we forgot a kref_get,
resulting in a premature drbd_destroy_device and use after free,
and further to kernel crashes with symptoms.

Relevance: No one should use DRBD as a random data generator, and apparently
all users of "two-primaries" handle concurrent writes correctly on layer up.
That is cluster file systems use some distributed lock manager,
and live migration in virtualization environments stops writes on one node
before starting writes on the other node.

Which means that other than for "test cases",
this code path is never taken in real life.

FYI, in DRBD 9, things are handled differently nowadays.  We still detect
"write conflicts", but no longer try to be smart about them.
We decided to disconnect hard instead: upper layers must not submit concurrent
writes. If they do, that's their fault.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/00c9c9628b49e368d140cfa61d7df9b8922ec2a8; https://git.kernel.org/stable/c/0336bfe9c237476bd7c45605a36ca79c2bca62e5; https://git.kernel.org/stable/c/3a896498f6f577e57bf26aaa93b48c22b6d20c20
CVE: CVE-2025-38709
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

loop: Avoid updating block size under exclusive owner

Syzbot came up with a reproducer where a loop device block size is
changed underneath a mounted filesystem. This causes a mismatch between
the block device block size and the block size stored in the superblock
causing confusion in various places such as fs/buffer.c. The particular
issue triggered by syzbot was a warning in __getblk_slow() due to
requested buffer size not matching block device block size.

Fix the problem by getting exclusive hold of the loop device to change
its block size. This fails if somebody (such as filesystem) has already
an exclusive ownership of the block device and thus prevents modifying
the loop device under some exclusive owner which doesn't expect it.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/139a000d20f2f38ce34296feddd641d730fe1c08; https://git.kernel.org/stable/c/457d2c5e112fd08dc1039b1ae39a83ec1782360d; https://git.kernel.org/stable/c/5d67b30aefeb7a949040bbb1b4e3b84c5d29a624
CVE: CVE-2025-38710
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

gfs2: Validate i_depth for exhash directories

A fuzzer test introduced corruption that ends up with a depth of 0 in
dir_e_read(), causing an undefined shift by 32 at:

  index = hash >> (32 - dip->i_depth);

As calculated in an open-coded way in dir_make_exhash(), the minimum
depth for an exhash directory is ilog2(sdp->sd_hash_ptrs) and 0 is
invalid as sdp->sd_hash_ptrs is fixed as sdp->bsize / 16 at mount time.

So we can avoid the undefined behaviour by checking for depth values
lower than the minimum in gfs2_dinode_in(). Values greater than the
maximum are already being checked for there.

Also switch the calculation in dir_make_exhash() to use ilog2() to
clarify how the depth is calculated.

Tested with the syzkaller repro.c and xfstests '-g quick'.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/53a0249d68a210c16e961b83adfa82f94ee0a53d; https://git.kernel.org/stable/c/557c024ca7250bb65ae60f16c02074106c2f197b; https://git.kernel.org/stable/c/9680c58675b82348ab84d387e4fa727f7587e1a0
CVE: CVE-2025-38711
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

smb/server: avoid deadlock when linking with ReplaceIfExists

If smb2_create_link() is called with ReplaceIfExists set and the name
does exist then a deadlock will happen.

ksmbd_vfs_kern_path_locked() will return with success and the parent
directory will be locked.  ksmbd_vfs_remove_file() will then remove the
file.  ksmbd_vfs_link() will then be called while the parent is still
locked.  It will try to lock the same parent and will deadlock.

This patch moves the ksmbd_vfs_kern_path_unlock() call to *before*
ksmbd_vfs_link() and then simplifies the code, removing the file_present
flag variable.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/1e858a7a51c7b8b009d8f246de7ceb7743b44a71; https://git.kernel.org/stable/c/814cfdb6358d9b84fcbec9918c8f938cc096a43a; https://git.kernel.org/stable/c/9d5012ffe14120f978ee34aef4df3d6cb026b7c4
CVE: CVE-2025-38712
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

hfsplus: don't use BUG_ON() in hfsplus_create_attributes_file()

When the volume header contains erroneous values that do not reflect
the actual state of the filesystem, hfsplus_fill_super() assumes that
the attributes file is not yet created, which later results in hitting
BUG_ON() when hfsplus_create_attributes_file() is called. Replace this
BUG_ON() with -EIO error with a message to suggest running fsck tool.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-617
References: https://git.kernel.org/stable/c/03cd1db1494cf930e2fa042c9c13e32bffdb4eba; https://git.kernel.org/stable/c/1bb8da27ff15e346d4bc9e248e819c9a88ebf9d6; https://git.kernel.org/stable/c/9046566fa692f88954dac8c510f37ee17a15fdb7
CVE: CVE-2025-38715
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

hfs: fix slab-out-of-bounds in hfs_bnode_read()

This patch introduces is_bnode_offset_valid() method that checks
the requested offset value. Also, it introduces
check_and_correct_requested_length() method that checks and
correct the requested length (if it is necessary). These methods
are used in hfs_bnode_read(), hfs_bnode_write(), hfs_bnode_clear(),
hfs_bnode_copy(), and hfs_bnode_move() with the goal to prevent
the access out of allocated memory and triggering the crash.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/384a66b89f9540a9a8cb0f48807697dfabaece4c; https://git.kernel.org/stable/c/67ecc81f6492275c9c54280532f558483c99c90e; https://git.kernel.org/stable/c/a1a60e79502279f996e55052f50cc[PII_REDACTED]
CVE: CVE-2025-38717
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

net: kcm: Fix race condition in kcm_unattach()

syzbot found a race condition when kcm_unattach(psock)
and kcm_release(kcm) are executed at the same time.

kcm_unattach() is missing a check of the flag
kcm->tx_stopped before calling queue_work().

If the kcm has a reserved psock, kcm_unattach() might get executed
between cancel_work_sync() and unreserve_psock() in kcm_release(),
requeuing kcm->tx_work right before kcm gets freed in kcm_done().

Remove kcm->tx_stopped and replace it by the less
error-prone disable_work_sync().
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/52565a935213cd6a8662ddb8efe5b4219343a25d; https://git.kernel.org/stable/c/7275dc3bb8f91b23125ff3f47b6529935cf46152; https://git.kernel.org/stable/c/798733ee5d5788b12e8a52db1519abc17e826f69
CVE: CVE-2025-38718
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

sctp: linearize cloned gso packets in sctp_rcv

A cloned head skb still shares these frag skbs in fraglist with the
original head skb. It's not safe to access these frag skbs.

syzbot reported two use-of-uninitialized-memory bugs caused by this:

  BUG: KMSAN: uninit-value in sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211
   sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211
   sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:998
   sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88
   sctp_backlog_rcv+0x397/0xdb0 net/sctp/input.c:331
   sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1122
   __release_sock+0x1da/0x330 net/core/sock.c:3106
   release_sock+0x6b/0x250 net/core/sock.c:3660
   sctp_wait_for_connect+0x487/0x820 net/sctp/socket.c:9360
   sctp_sendmsg_to_asoc+0x1ec1/0x1f00 net/sctp/socket.c:1885
   sctp_sendmsg+0x32b9/0x4a80 net/sctp/socket.c:2031
   inet_sendmsg+0x25a/0x280 net/ipv4/af_inet.c:851
   sock_sendmsg_nosec net/socket.c:718 [inline]

and

  BUG: KMSAN: uninit-value in sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987
   sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987
   sctp_inq_push+0x2a3/0x350 net/sctp/inqueue.c:88
   sctp_backlog_rcv+0x3c7/0xda0 net/sctp/input.c:331
   sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148
   __release_sock+0x1d3/0x330 net/core/sock.c:3213
   release_sock+0x6b/0x270 net/core/sock.c:3767
   sctp_wait_for_connect+0x458/0x820 net/sctp/socket.c:9367
   sctp_sendmsg_to_asoc+0x223a/0x2260 net/sctp/socket.c:1886
   sctp_sendmsg+0x3910/0x49f0 net/sctp/socket.c:2032
   inet_sendmsg+0x269/0x2a0 net/ipv4/af_inet.c:851
   sock_sendmsg_nosec net/socket.c:712 [inline]

This patch fixes it by linearizing cloned gso packets in sctp_rcv().
CVSS Score: 7.8 (HIGH)
CWE: CWE-908
References: https://git.kernel.org/stable/c/03d0cc6889e[PII_REDACTED]0b5444b570f4bbf53d5; https://git.kernel.org/stable/c/1bd5214ea681584c5886fea3ba03e49f93a43c0e; https://git.kernel.org/stable/c/4506bcaabe004d07be8ff09116a3024fbd6aa965
CVE: CVE-2025-38719
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

net: hibmcge: fix the division by zero issue

When the network port is down, the queue is released, and ring->len is 0.
In debugfs, hbg_get_queue_used_num() will be called,
which may lead to a division by zero issue.

This patch adds a check, if ring->len is 0,
hbg_get_queue_used_num() directly returns 0.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-369
References: https://git.kernel.org/stable/c/475e06113c615dafd44262d6d6bd37786f7f4206; https://git.kernel.org/stable/c/7004b26f0b64331143eb0b312e77a357a11427ce; https://git.kernel.org/stable/c/c945e1ad4f3b77166a3215dabc0c6c980d4a9c73
CVE: CVE-2025-38720
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

net: hibmcge: fix rtnl deadlock issue

Currently, the hibmcge netdev acquires the rtnl_lock in
pci_error_handlers.reset_prepare() and releases it in
pci_error_handlers.reset_done().

However, in the PCI framework:
pci_reset_bus - __pci_reset_slot - pci_slot_save_and_disable_locked -
 pci_dev_save_and_disable - err_handler->reset_prepare(dev);

In pci_slot_save_and_disable_locked():
	list_for_each_entry(dev, &slot->bus->devices, bus_list) {
		if (!dev->slot || dev->slot!= slot)
			continue;
		pci_dev_save_and_disable(dev);
		if (dev->subordinate)
			pci_bus_save_and_disable_locked(dev->subordinate);
	}

This will iterate through all devices under the current bus and execute
err_handler->reset_prepare(), causing two devices of the hibmcge driver
to sequentially request the rtnl_lock, leading to a deadlock.

Since the driver now executes netif_device_detach()
before the reset process, it will not concurrently with
other netdev APIs, so there is no need to hold the rtnl_lock now.

Therefore, this patch removes the rtnl_lock during the reset process and
adjusts the position of HBG_NIC_STATE_RESETTING to ensure
that multiple resets are not executed concurrently.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/1343a8994ca7dba78f5dd818e89d68331c21c35d; https://git.kernel.org/stable/c/c875503a9b9082928d7d3fc60b5400d16fbfae4e; https://git.kernel.org/stable/c/d85a6346fd6f595c[PII_REDACTED]d0cdf35c004a5e
CVE: CVE-2025-38721
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: ctnetlink: fix refcount leak on table dump

There is a reference count leak in ctnetlink_dump_table():
      if (res < 0) {
                nf_conntrack_get(&ct->ct_general); // HERE
                cb->args[1] = (unsigned long)ct;
                ...

While its very unlikely, its possible that ct == last.
If this happens, then the refcount of ct was already incremented.
This 2nd increment is never undone.

This prevents the conntrack object from being released, which in turn
keeps prevents cnet->count from dropping back to 0.

This will then block the netns dismantle (or conntrack rmmod) as
nf_conntrack_cleanup_net_list() will wait forever.

This can be reproduced by running conntrack_resize.sh selftest in a loop.
It takes ~20 minutes for me on a preemptible kernel on average before
I see a runaway kworker spinning in nf_conntrack_cleanup_net_list.

One fix would to change this to:
        if (res < 0) {
		if (ct != last)
	                nf_conntrack_get(&ct->ct_general);

But this reference counting isn't needed in the first place.
We can just store a cookie value instead.

A followup patch will do the same for ctnetlink_exp_dump_table,
it looks to me as if this has the same problem and like
ctnetlink_dump_table, we only need a 'skip hint', not the actual
object so we can apply the same cookie strategy there as well.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/19b909a4b1452fb97e477d2f08b97f8d04095619; https://git.kernel.org/stable/c/30cf811058552b8cd0e98dff677ef3f89d6d34ce; https://git.kernel.org/stable/c/41462f4cfc583513833f87f9ee55d12da651a7e3
CVE: CVE-2025-38722
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

habanalabs: fix UAF in export_dmabuf()

As soon as we'd inserted a file reference into descriptor table, another
thread could close it.  That's fine for the case when all we are doing is
returning that descriptor to userland (it's a race, but it's a userland
race and there's nothing the kernel can do about it).  However, if we
follow fd_install() with any kind of access to objects that would be
destroyed on close (be it the struct file itself or anything destroyed
by its ->release()), we have a UAF.

dma_buf_fd() is a combination of reserving a descriptor and fd_install().
habanalabs export_dmabuf() calls it and then proceeds to access the
objects destroyed on close.  In particular, it grabs an extra reference to
another struct file that will be dropped as part of ->release() for ours;
that "will be" is actually "might have already been".

Fix that by reserving descriptor before anything else and do fd_install()
only when everything had been set up.  As a side benefit, we no longer
have the failure exit with file already created, but reference to
underlying file (as well as ->dmabuf_export_cnt, etc.) not grabbed yet;
unlike dma_buf_fd(), fd_install() can't fail.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/33927f3d0ecdcff06326d6e4edb6166aed42811c; https://git.kernel.org/stable/c/40deceb38f9db759772d1c289c28fd2a543f57fc; https://git.kernel.org/stable/c/55c232d7e0241f1d5120b595e7a9de24c75ed3d8
CVE: CVE-2025-38723
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

LoongArch: BPF: Fix jump offset calculation in tailcall

The extra pass of bpf_int_jit_compile() skips JIT context initialization
which essentially skips offset calculation leaving out_offset = -1, so
the jmp_offset in emit_bpf_tail_call is calculated by

"#define jmp_offset (out_offset - (cur_offset))"

is a negative number, which is wrong. The final generated assembly are
as follow.

54:	bgeu        	$a2, $t1, -8	    # 0x0000004c
58:	addi.d      	$a6, $s5, -1
5c:	bltz        	$a6, -16	    # 0x0000004c
60:	alsl.d      	$t2, $a2, $a1, 0x3
64:	ld.d        	$t2, $t2, 264
68:	beq         	$t2, $zero, -28	    # 0x0000004c

Before apply this patch, the follow test case will reveal soft lock issues.

cd tools/testing/selftests/bpf/
./test_progs --allow=tailcalls/tailcall_bpf2bpf_1

dmesg:
watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [test_progs:25056]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/17c010fe45def335fe03a[PII_REDACTED]b04c7f349; https://git.kernel.org/stable/c/1a782fa32e644aa9fbae6c8488f3e61221ac96e1; https://git.kernel.org/stable/c/9262e3e04621558e875eb5afb5e726b648cd5949
CVE: CVE-2025-38724
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

nfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm()

Lei Lu recently reported that nfsd4_setclientid_confirm() did not check
the return value from get_client_locked(). a SETCLIENTID_CONFIRM could
race with a confirmed client expiring and fail to get a reference. That
could later lead to a UAF.

Fix this by getting a reference early in the case where there is an
extant confirmed client. If that fails then treat it as if there were no
confirmed client found at all.

In the case where the unconfirmed client is expiring, just fail and
return the result from get_client_locked().
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/22f45cedf281e6171817c8a3432c44d788c550e1; https://git.kernel.org/stable/c/36e83eda90e0e4ac52f259f775b40b2841f8a0a3; https://git.kernel.org/stable/c/3f252a73e81aa01660cb426735eab932e6182e8d
CVE: CVE-2025-38725
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

net: usb: asix_devices: add phy_mask for ax88772 mdio bus

Without setting phy_mask for ax88772 mdio bus, current driver may create
at most 32 mdio phy devices with phy address range from 0x00 ~ 0x1f.
DLink DUB-E100 H/W Ver B1 is such a device. However, only one main phy
device will bind to net phy driver. This is creating issue during system
suspend/resume since phy_polling_mode() in phy_state_machine() will
directly deference member of phydev->drv for non-main phy devices. Then
NULL pointer dereference issue will occur. Due to only external phy or
internal phy is necessary, add phy_mask for ax88772 mdio bus to workarnoud
the issue.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/4faff70959d51078f9ee8372f8cff0d7045e4114; https://git.kernel.org/stable/c/59ed6fbdb1bc03316e09493ffde7066f031c7524; https://git.kernel.org/stable/c/75947d3200de98a9ded9ad8972e02f1a177097fe
CVE: CVE-2025-38726
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ftgmac100: fix potential NULL pointer access in ftgmac100_phy_disconnect

After the call to phy_disconnect() netdev->phydev is reset to NULL.
So fixed_phy_unregister() would be called with a NULL pointer as argument.
Therefore cache the phy_device before this call.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/44bcd397ad9cd1a6b25fabb7f5edbee4fb0cfc2e; https://git.kernel.org/stable/c/9ad90dd34b4e8e5be1e45a4559f4de0f14e53af2; https://git.kernel.org/stable/c/ae59ec969c07c73f0610f8bd7e648f01e798d222