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

ksmbd: fix type confusion via race condition when using ipc_msg_send_request

req->handle is allocated using ksmbd_acquire_id(&ipc_ida), based on
ida_alloc. req->handle from ksmbd_ipc_login_request and
FSCTL_PIPE_TRANSCEIVE ioctl can be same and it could lead to type confusion
between messages, resulting in access to unexpected parts of memory after
an incorrect delivery. ksmbd check type of ipc response but missing add
continue to check next ipc reponse.
CVSS Score: 8.1 (HIGH)
CWE: CWE-362, CWE-362
References: https://git.kernel.org/stable/c/1e8833c03a38e1d5d5df6484e3f670a2fd38fb76; https://git.kernel.org/stable/c/3cb2b2e41541fe6f9cc55ca22d4c0bd260498aea; https://git.kernel.org/stable/c/6321bbda4244b93802d61cfe0887883aae322f4b
CVE: CVE-2025-21949
Published: 2025-04-01
Description: In the Linux kernel, the following vulnerability has been resolved:

LoongArch: Set hugetlb mmap base address aligned with pmd size

With ltp test case "testcases/bin/hugefork02", there is a dmesg error
report message such as:

 kernel BUG at mm/hugetlb.c:5550!
 Oops - BUG[#1]:
 CPU: 0 UID: 0 PID: 1517 Comm: hugefork02 Not tainted 6.14.0-rc2+ #241
 Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022
 pc[PII_REDACTED]4eaf1c ra [PII_REDACTED] tp 900000010edbc000 sp 900000010edbf940
 a0 900000010edbfb00 a[PII_REDACTED]d20280 a2 00007fffe9474000 a3 00007ffff3474000
 a4 [PII_REDACTED] a5 [PII_REDACTED] a6[PII_REDACTED]3cadd3 a7 [PII_REDACTED]
 t0[PII_REDACTED]ffffff t1 [PII_REDACTED] t2 900000010ecd7900 t3 00007fffe9474000
 t4 00007fffe9474000 t5 [PII_REDACTED] t6 900000010edbfb00 t7 [PII_REDACTED]
 t8 [PII_REDACTED] u0[PII_REDACTED]4849d0 s9 900000010edbfa00 s0[PII_REDACTED]d20280
 s1 00007fffe9474000 s2 [PII_REDACTED] s3[PII_REDACTED]d20280 s4[PII_REDACTED]b38b10
 s5 900000010edbfb00 s6 00007ffff3474000 s7 [PII_REDACTED] s8 900000010edbfa08
    ra: [PII_REDACTED] unmap_vmas+0x130/0x218
   ERA:[PII_REDACTED]4eaf1c __unmap_hugepage_range+0x6f4/0x7d0
  PRMD: 00000004 (PPLV0 +PIE -PWE)
  EUEN: 00000007 (+FPE +SXE +ASXE -BTE)
  ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
 ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0)
 PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)
 Process hugefork02 (pid: 1517, threadinfo=00000000a670eaf4, task=000000007a95fc64)
 Call Trace:
 [<[PII_REDACTED]4eaf1c>] __unmap_hugepage_range+0x6f4/0x7d0
 [<[PII_REDACTED]>] unmap_vmas+0x12c/0x218
 [<[PII_REDACTED]>] exit_mmap+0xe0/0x308
 [<[PII_REDACTED]25fdc4>] mmput+0x74/0x180
 [<[PII_REDACTED]26a284>] do_exit+0x294/0x898
 [<[PII_REDACTED]26aa30>] do_group_exit+0x30/0x98
 [<[PII_REDACTED]27bed4>] get_signal+0x83c/0x868
 [<[PII_REDACTED]2457b4>] arch_do_signal_or_restart+0x54/0xfa0
 [<[PII_REDACTED]5795e8>] irqentry_exit_to_user_mode+0xb8/0x138
 [<[PII_REDACTED]2572d0>] tlb_do_page_fault_1+0x114/0x1b4

The problem is that base address allocated from hugetlbfs is not aligned
with pmd size. Here add a checking for hugetlbfs and align base address
with pmd size. After this patch the test case "testcases/bin/hugefork02"
passes to run.

This is similar to the commit 7f24cbc9c4d42db8a3c8484d1 ("mm/mmap: teach
generic_get_unmapped_area{_topdown} to handle hugetlb mappings").
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/242b34f48a377afe4b285b472bd0f17744fca8e8; https://git.kernel.org/stable/c/3109d5ff484b7bc7b955f166974c6776d91f247b
CVE: CVE-2025-21950
Published: 2025-04-01
Description: In the Linux kernel, the following vulnerability has been resolved:

drivers: virt: acrn: hsm: Use kzalloc to avoid info leak in pmcmd_ioctl

In the "pmcmd_ioctl" function, three memory objects allocated by
kmalloc are initialized by "hcall_get_cpu_state", which are then
copied to user space. The initializer is indeed implemented in
"acrn_hypercall2" (arch/x86/include/asm/acrn.h). There is a risk of
information leakage due to uninitialized bytes.
CVSS Score: 7.1 (HIGH)
References: https://git.kernel.org/stable/c/1b8f7a2caa7f9cdfd135e3f78eb9d7e36fb95083; https://git.kernel.org/stable/c/4e15cf870d2c748e45d45ffc4d5b1dc1b7d50120; https://git.kernel.org/stable/c/524f29d78c9bdeb49f31f5b0376a07d2fc5cf563
CVE: CVE-2025-21951
Published: 2025-04-01
Description: In the Linux kernel, the following vulnerability has been resolved:

bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlock

There are multiple places from where the recovery work gets scheduled
asynchronously. Also, there are multiple places where the caller waits
synchronously for the recovery to be completed. One such place is during
the PM shutdown() callback.

If the device is not alive during recovery_work, it will try to reset the
device using pci_reset_function(). This function internally will take the
device_lock() first before resetting the device. By this time, if the lock
has already been acquired, then recovery_work will get stalled while
waiting for the lock. And if the lock was already acquired by the caller
which waits for the recovery_work to be completed, it will lead to
deadlock.

This is what happened on the X1E80100 CRD device when the device died
before shutdown() callback. Driver core calls the driver's shutdown()
callback while holding the device_lock() leading to deadlock.

And this deadlock scenario can occur on other paths as well, like during
the PM suspend() callback, where the driver core would hold the
device_lock() before calling driver's suspend() callback. And if the
recovery_work was already started, it could lead to deadlock. This is also
observed on the X1E80100 CRD.

So to fix both issues, use pci_try_reset_function() in recovery_work. This
function first checks for the availability of the device_lock() before
trying to reset the device. If the lock is available, it will acquire it
and reset the device. Otherwise, it will return -EAGAIN. If that happens,
recovery_work will fail with the error message "Recovery failed" as not
much could be done.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667, CWE-667
References: https://git.kernel.org/stable/c/1f9eb7078bc6b5fb5cbfbcb37c4bc01685332b95; https://git.kernel.org/stable/c/[PII_REDACTED]5c245c9cd46e42ac01026d1e61f027; https://git.kernel.org/stable/c/7746f3bb8917fccb4571a576f3837d80fc513054
CVE: CVE-2025-21952
Published: 2025-04-01
Description: In the Linux kernel, the following vulnerability has been resolved:

HID: corsair-void: Update power supply values with a unified work handler

corsair_void_process_receiver can be called from an interrupt context,
locking battery_mutex in it was causing a kernel panic.
Fix it by moving the critical section into its own work, sharing this
work with battery_add_work and battery_remove_work to remove the need
for any locking
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0c28e4d1e10d2aae608094620bb386e6fd73d55e; https://git.kernel.org/stable/c/de19c9dfb68f7c5791accc89047f92e952f57996
CVE: CVE-2025-21954
Published: 2025-04-01
Description: In the Linux kernel, the following vulnerability has been resolved:

netmem: prevent TX of unreadable skbs

Currently on stable trees we have support for netmem/devmem RX but not
TX. It is not safe to forward/redirect an RX unreadable netmem packet
into the device's TX path, as the device may call dma-mapping APIs on
dma addrs that should not be passed to it.

Fix this by preventing the xmit of unreadable skbs.

Tested by configuring tc redirect:

sudo tc qdisc add dev eth1 ingress
sudo tc filter add dev eth1 ingress protocol ip prio 1 flower ip_proto \
	tcp src_ip 192.168.1.12 action mirred egress redirect dev eth1

Before, I see unreadable skbs in the driver's TX path passed to dma
mapping APIs.

After, I don't see unreadable skbs in the driver's TX path passed to dma
mapping APIs.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/1c17c8ced25c5fbe424c7ad7ea11d33014a986b1; https://git.kernel.org/stable/c/454825019d2f0c59e5174ece9e713f45ad80beff; https://git.kernel.org/stable/c/f3600c867c99a2cc8038680ecf211089c50e7971
CVE: CVE-2025-21955
Published: 2025-04-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: prevent connection release during oplock break notification

ksmbd_work could be freed when after connection release.
Increment r_count of ksmbd_conn to indicate that requests
are not finished yet and to not release the connection.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/09aeab68033161cb54f194da93e51a11aee6144b; https://git.kernel.org/stable/c/3aa660c059240e0c795217182cf7df32909dd917; https://git.kernel.org/stable/c/a4261bbc33fbf99b99c80aa3a2c[PII_REDACTED]980
CVE: CVE-2025-21956
Published: 2025-04-01
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Assign normalized_pix_clk when color depth = 14

[WHY & HOW]
A warning message "WARNING: CPU: 4 PID: 459 at ... /dc_resource.c:3397
calculate_phy_pix_clks+0xef/0x100 [amdgpu]" occurs because the
display_color_depth == COLOR_DEPTH_141414 is not handled. This is
observed in Radeon RX 6600 XT.

It is fixed by assigning pix_clk * (14 * 3) / 24 - same as the rests.

Also fixes the indentation in get_norm_pix_clk.

(cherry picked from commit 274a87eb389f58eddcbc5659ab0b180b37e92775)
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0174a2e5770efee9dbd4b58963ed4d939298ff5e; https://git.kernel.org/stable/c/04f90b505ad3a6eed474bbaa03167095fef5203a; https://git.kernel.org/stable/c/0c0016712e5dc23ce4a7e673cbebc24a535d8c8a
CVE: CVE-2025-21957
Published: 2025-04-01
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: qla1280: Fix kernel oops when debug level > 2

A null dereference or oops exception will eventually occur when qla1280.c
driver is compiled with DEBUG_QLA1280 enabled and ql_debug_level > 2.  I
think its clear from the code that the intention here is sg_dma_len(s) not
length of sg_next(s) when printing the debug info.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/11a8dac1177a596648a020a7f3708257a2f95fee; https://git.kernel.org/stable/c/24602e2664c515a4f2950d7b52c3d[PII_REDACTED]c; https://git.kernel.org/stable/c/5233e3235dec3065ccc[PII_REDACTED]75dbe3c6b8a
CVE: CVE-2025-21958
Published: 2025-04-01
Description: In the Linux kernel, the following vulnerability has been resolved:

Revert "openvswitch: switch to per-action label counting in conntrack"

Currently, ovs_ct_set_labels() is only called for confirmed conntrack
entries (ct) within ovs_ct_commit(). However, if the conntrack entry
does not have the labels_ext extension, attempting to allocate it in
ovs_ct_get_conn_labels() for a confirmed entry triggers a warning in
nf_ct_ext_add():

  WARN_ON(nf_ct_is_confirmed(ct));

This happens when the conntrack entry is created externally before OVS
increments net->ct.labels_used. The issue has become more likely since
commit fcb1aa5163b1 ("openvswitch: switch to per-action label counting
in conntrack"), which changed to use per-action label counting and
increment net->ct.labels_used when a flow with ct action is added.

Since there’s no straightforward way to fully resolve this issue at the
moment, this reverts the commit to avoid breaking existing use cases.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-367
References: https://git.kernel.org/stable/c/1063ae07383c0ddc5bcce170260c143825846b03; https://git.kernel.org/stable/c/9e79fdabd52cfce1a021640a81256878a2c516a2; https://git.kernel.org/stable/c/d91bfc64a[PII_REDACTED]e74d2c6f3a61e9a77fd7d
CVE: CVE-2025-21960
Published: 2025-04-01
Description: In the Linux kernel, the following vulnerability has been resolved:

eth: bnxt: do not update checksum in bnxt_xdp_build_skb()

The bnxt_rx_pkt() updates ip_summed value at the end if checksum offload
is enabled.
When the XDP-MB program is attached and it returns XDP_PASS, the
bnxt_xdp_build_skb() is called to update skb_shared_info.
The main purpose of bnxt_xdp_build_skb() is to update skb_shared_info,
but it updates ip_summed value too if checksum offload is enabled.
This is actually duplicate work.

When the bnxt_rx_pkt() updates ip_summed value, it checks if ip_summed
is CHECKSUM_NONE or not.
It means that ip_summed should be CHECKSUM_NONE at this moment.
But ip_summed may already be updated to CHECKSUM_UNNECESSARY in the
XDP-MB-PASS path.
So the by skb_checksum_none_assert() WARNS about it.

This is duplicate work and updating ip_summed in the
bnxt_xdp_build_skb() is not needed.

Splat looks like:
WARNING: CPU: 3 PID: 5782 at ./include/linux/skbuff.h:5155 bnxt_rx_pkt+0x479b/0x7610 [bnxt_en]
Modules linked in: bnxt_re bnxt_en rdma_ucm rdma_cm iw_cm ib_cm ib_uverbs veth xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_]
CPU: 3 UID: 0 PID: 5782 Comm: socat Tainted: G        W          6.14.0-rc4+ #27
Tainted: [W]=WARN
Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021
RIP: 0010:bnxt_rx_pkt+0x479b/0x7610 [bnxt_en]
Code: 54 24 0c 4c 89 f1 4c 89 ff c1 ea 1f ff d3 0f 1f 00 49 89 c6 48 85 c0 0f 84 4c e5 ff ff 48 89 c7 e8 ca 3d a0 c8 e9 8f f4 ff ff <0f> 0b f
RSP: 0018:ffff88881ba09928 EFLAGS: 00010202
RAX: [PII_REDACTED] RBX: 00000000c7590303 RCX: [PII_REDACTED]
RDX: 1ffff1104e7d1610 RSI: [PII_REDACTED] RDI: ffff8881c91300b8
RBP: ffff88881ba09b28 R08: ffff888273e8b0d0 R09: ffff888273e8b070
R10: ffff888273e8b010 R11: ffff888278b0f000 R12: ffff888273e8b080
R13: ffff8881c9130e00 R14: ffff8881505d3800 R15: ffff888273e8b000
FS:  00007f5a2e7be080(0000) GS:ffff88881ba00000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 00007fff2e708ff8 CR3: 000000013e3b0000 CR4:[PII_REDACTED]7506f0
PKRU: 55555554
Call Trace:
 <IRQ>
 ? __warn+0xcd/0x2f0
 ? bnxt_rx_pkt+0x479b/0x7610
 ? report_bug+0x326/0x3c0
 ? handle_bug+0x53/0xa0
 ? exc_invalid_op+0x14/0x50
 ? asm_exc_invalid_op+0x16/0x20
 ? bnxt_rx_pkt+0x479b/0x7610
 ? bnxt_rx_pkt+0x3e41/0x7610
 ? __pfx_bnxt_rx_pkt+0x10/0x10
 ? napi_complete_done+0x2cf/0x7d0
 __bnxt_poll_work+0x4e8/0x1220
 ? __pfx___bnxt_poll_work+0x10/0x10
 ? __pfx_mark_lock.part.0+0x10/0x10
 bnxt_poll_p5+0x36a/0xfa0
 ? __pfx_bnxt_poll_p5+0x10/0x10
 __napi_poll.constprop.0+0xa0/0x440
 net_rx_action+0x899/0xd00
...

Following ping.py patch adds xdp-mb-pass case. so ping.py is going
to be able to reproduce this issue.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/44578bc6460b8fca530fc7bd5897c115d9bd27e2; https://git.kernel.org/stable/c/5b57ed14a1b85e7ab0074d9668a0baa6c94826c7; https://git.kernel.org/stable/c/c03e7d05aa0e2f7e9a9ce5ad8a12471a53f941dc
CVE: CVE-2025-21961
Published: 2025-04-01
Description: In the Linux kernel, the following vulnerability has been resolved:

eth: bnxt: fix truesize for mb-xdp-pass case

When mb-xdp is set and return is XDP_PASS, packet is converted from
xdp_buff to sk_buff with xdp_update_skb_shared_info() in
bnxt_xdp_build_skb().
bnxt_xdp_build_skb() passes incorrect truesize argument to
xdp_update_skb_shared_info().
The truesize is calculated as BNXT_RX_PAGE_SIZE * sinfo->nr_frags but
the skb_shared_info was wiped by napi_build_skb() before.
So it stores sinfo->nr_frags before bnxt_xdp_build_skb() and use it
instead of getting skb_shared_info from xdp_get_shared_info_from_buff().

Splat looks like:
 ------------[ cut here ]------------
 WARNING: CPU: 2 PID: 0 at net/core/skbuff.c:6072 skb_try_coalesce+0x504/0x590
 Modules linked in: xt_nat xt_tcpudp veth af_packet xt_conntrack nft_chain_nat xt_MASQUERADE nf_conntrack_netlink xfrm_user xt_addrtype nft_coms
 CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.14.0-rc2+ #3
 RIP: 0010:skb_try_coalesce+0x504/0x590
 Code: 4b fd ff ff 49 8b 34 24 40 80 e6 40 0f 84 3d fd ff ff 49 8b 74 24 48 40 f6 c6 01 0f 84 2e fd ff ff 48 8d 4e ff e9 25 fd ff ff <0f> 0b e99
 RSP: 0018:ffffb62c4120caa8 EFLAGS: 00010287
 RAX: [PII_REDACTED] RBX: ffffb62c4120cb14 RCX:[PII_REDACTED]000ec0
 RDX: [PII_REDACTED] RSI: ffffa06e5d7dc000 RDI: [PII_REDACTED]
 RBP: ffffa06e5d7ddec0 R08: ffffa06e6120a800 R09: ffffa06e7a119900
 R10: [PII_REDACTED] R11: ffffa06e5d7dcec0 R12: ffffe4360575f740
 R13: ffffe[PII_REDACTED]0 R14: [PII_REDACTED] R15: [PII_REDACTED]
 FS:  [PII_REDACTED](0000) GS:ffffa0755f700000(0000) knlGS:[PII_REDACTED]
 CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
 CR2: 00007f147b76b0f8 CR3:[PII_REDACTED]5d4000 CR4:[PII_REDACTED]7506f0
 PKRU: 55555554
 Call Trace:
  <IRQ>
  ? __warn+0x84/0x130
  ? skb_try_coalesce+0x504/0x590
  ? report_bug+0x18a/0x1a0
  ? handle_bug+0x53/0x90
  ? exc_invalid_op+0x14/0x70
  ? asm_exc_invalid_op+0x16/0x20
  ? skb_try_coalesce+0x504/0x590
  inet_frag_reasm_finish+0x11f/0x2e0
  ip_defrag+0x37a/0x900
  ip_local_deliver+0x51/0x120
  ip_sublist_rcv_finish+0x64/0x70
  ip_sublist_rcv+0x179/0x210
  ip_list_rcv+0xf9/0x130

How to reproduce:
<Node A>
ip link set $interface1 xdp obj xdp_pass.o
ip link set $interface1 mtu 9000 up
ip a a 10.0.0.1/24 dev $interface1
<Node B>
ip link set $interfac2 mtu 9000 up
ip a a 10.0.0.2/24 dev $interface2
ping 10.0.0.1 -s 65000

Following ping.py patch adds xdp-mb-pass case. so ping.py is going to be
able to reproduce this issue.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/19107e71be330dbccb9f8f9f4cf0a9abeadad802; https://git.kernel.org/stable/c/9f7b2aa5034e24d3c49db73d5f760c0435fe31c2; https://git.kernel.org/stable/c/b4679807c6083ade4d47f03f80da891afcb6ef62
CVE: CVE-2025-21962
Published: 2025-04-01
Description: In the Linux kernel, the following vulnerability has been resolved:

cifs: Fix integer overflow while processing closetimeo mount option

User-provided mount parameter closetimeo of type u32 is intended to have
an upper limit, but before it is validated, the value is converted from
seconds to jiffies which can lead to an integer overflow.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190, CWE-190
References: https://git.kernel.org/stable/c/1c46673be93dd2954f44fe370fb4f2b8e6214224; https://git.kernel.org/stable/c/513f6cf2e906a504b7ab0b62b2eea993a6f64558; https://git.kernel.org/stable/c/6c13fcb7cf59ae65940da1dfea80144e42921e53
CVE: CVE-2025-21963
Published: 2025-04-01
Description: In the Linux kernel, the following vulnerability has been resolved:

cifs: Fix integer overflow while processing acdirmax mount option

User-provided mount parameter acdirmax of type u32 is intended to have
an upper limit, but before it is validated, the value is converted from
seconds to jiffies which can lead to an integer overflow.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190, CWE-190
References: https://git.kernel.org/stable/c/0c26edf477e093cefc41637f5bccc102e1a77399; https://git.kernel.org/stable/c/2809a79bc64964ce02e0c5f2d6bd39b9d09bdb3c; https://git.kernel.org/stable/c/39d086bb3558da9640ef335f97453e01d32578a1
CVE: CVE-2025-21964
Published: 2025-04-01
Description: In the Linux kernel, the following vulnerability has been resolved:

cifs: Fix integer overflow while processing acregmax mount option

User-provided mount parameter acregmax of type u32 is intended to have
an upper limit, but before it is validated, the value is converted from
seconds to jiffies which can lead to an integer overflow.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190, CWE-190
References: https://git.kernel.org/stable/c/0252c33cc943e9e48ddfafaa6b1eb72adb68a099; https://git.kernel.org/stable/c/5f500874ab9b3cc8c169c2ab49f00b838520b9c5; https://git.kernel.org/stable/c/7489161b1852390b4413d57f2457cd40b34da6cc
CVE: CVE-2025-21965
Published: 2025-04-01
Description: In the Linux kernel, the following vulnerability has been resolved:

sched_ext: Validate prev_cpu in scx_bpf_select_cpu_dfl()

If a BPF scheduler provides an invalid CPU (outside the nr_cpu_ids
range) as prev_cpu to scx_bpf_select_cpu_dfl() it can cause a kernel
crash.

To prevent this, validate prev_cpu in scx_bpf_select_cpu_dfl() and
trigger an scx error if an invalid CPU is specified.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/515680e76c536dd4aa8e2b5d674b0d441baddf5b; https://git.kernel.org/stable/c/752b56bb76e2471197d25d6948d85753043b10da; https://git.kernel.org/stable/c/9360dfe4cbd62ff1eb8217b[PII_REDACTED]23b75b3
CVE: CVE-2025-21966
Published: 2025-04-01
Description: In the Linux kernel, the following vulnerability has been resolved:

dm-flakey: Fix memory corruption in optional corrupt_bio_byte feature

Fix memory corruption due to incorrect parameter being passed to bio_init
CVSS Score: 7.8 (HIGH)
CWE: CWE-787, CWE-787
References: https://git.kernel.org/stable/c/57e9417f69839cb10f7ffca684c38acd28ceb57b; https://git.kernel.org/stable/c/5a87e46da2418c57b445371f5ca0958d5779ba5f; https://git.kernel.org/stable/c/818330f756f3800c37d738bd36bce60eac949938
CVE: CVE-2025-21967
Published: 2025-04-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix use-after-free in ksmbd_free_work_struct

->interim_entry of ksmbd_work could be deleted after oplock is freed.
We don't need to manage it with linked list. The interim request could be
immediately sent whenever a oplock break wait is needed.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-416
References: https://git.kernel.org/stable/c/62746ae3f5414244a96293e3b017be637b641280; https://git.kernel.org/stable/c/bb39ed[PII_REDACTED][PII_REDACTED]d[PII_REDACTED]d31; https://git.kernel.org/stable/c/eb51f6f59d19b92f6fe84d3873f958495ab32f0a
CVE: CVE-2025-21968
Published: 2025-04-01
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix slab-use-after-free on hdcp_work

[Why]
A slab-use-after-free is reported when HDCP is destroyed but the
property_validate_dwork queue is still running.

[How]
Cancel the delayed work when destroying workqueue.

(cherry picked from commit 725a04ba5a95e89c89633d4322430cfbca7ce128)
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-416
References: https://git.kernel.org/stable/c/06acfdef370ae018dad9592369e2d2fd9a40c09e; https://git.kernel.org/stable/c/1397715b011bcdc6ad91b17df7acaee301e89db5; https://git.kernel.org/stable/c/378b361e2e30e9729f9a7676f7926868d14f4326
CVE: CVE-2025-21971
Published: 2025-04-01
Description: In the Linux kernel, the following vulnerability has been resolved:

net_sched: Prevent creation of classes with TC_H_ROOT

The function qdisc_tree_reduce_backlog() uses TC_H_ROOT as a termination
condition when traversing up the qdisc tree to update parent backlog
counters. However, if a class is created with classid TC_H_ROOT, the
traversal terminates prematurely at this class instead of reaching the
actual root qdisc, causing parent statistics to be incorrectly maintained.
In case of DRR, this could lead to a crash as reported by Mingi Cho.

Prevent the creation of any Qdisc class with classid TC_H_ROOT
(0xFFFFFFFF) across all qdisc types, as suggested by Jamal.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-835
References: https://git.kernel.org/stable/c/003d92c91cdb5a64b25a9a74cb8543aac9a8bb48; https://git.kernel.org/stable/c/0c3057a5a04d07120b3d0ec9c79568fceb9c921e; https://git.kernel.org/stable/c/5c3ca9cb48b51bd72bf76b8b05e24f3cd53db5e7
CVE: CVE-2025-21972
Published: 2025-04-01
Description: In the Linux kernel, the following vulnerability has been resolved:

net: mctp: unshare packets when reassembling

Ensure that the frag_list used for reassembly isn't shared with other
packets. This avoids incorrect reassembly when packets are cloned, and
prevents a memory leak due to circular references between fragments and
their skb_shared_info.

The upcoming MCTP-over-USB driver uses skb_clone which can trigger the
problem - other MCTP drivers don't share SKBs.

A kunit test is added to reproduce the issue.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/5c47d5bfa7b096cf8890afac32141c578583f8e0; https://git.kernel.org/stable/c/f44fff3d3c6cd67b6f348b821d73c4d6888c7a6e; https://git.kernel.org/stable/c/f5d83cf0eeb90fade4d5c4d17d24b8bee9ceeecc