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

RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow

When cur_qp isn't NULL, in order to avoid fetching the QP from
the radix tree again we check if the next cqe QP is identical to
the one we already have.

The bug however is that we are checking if the QP is identical by
checking the QP number inside the CQE against the QP number inside the
mlx5_ib_qp, but that's wrong since the QP number from the CQE is from
FW so it should be matched against mlx5_core_qp which is our FW QP
number.

Otherwise we could use the wrong QP when handling a CQE which could
cause the kernel trace below.

This issue is mainly noticeable over QPs 0 & 1, since for now they are
the only QPs in our driver whereas the QP number inside mlx5_ib_qp
doesn't match the QP number inside mlx5_core_qp.

BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: Oops: 0000 [#1] SMP
 CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]
 RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib]
 Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21
 RSP: 0018:ffff88810511bd60 EFLAGS: 00010046
 RAX: [PII_REDACTED] RBX: [PII_REDACTED] RCX: [PII_REDACTED]
 RDX: [PII_REDACTED] RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a
 RBP:[PII_REDACTED]0000b0 R08: [PII_REDACTED] R09: ffff88810511bc10
 R10: [PII_REDACTED] R11: [PII_REDACTED] R12: ffff88810d593000
 R13: ffff88810e579108 R14: ffff[PII_REDACTED]00 R15:[PII_REDACTED]0000b0
 FS:  [PII_REDACTED](0000) GS:ffff88885fa00000(0000) knlGS:[PII_REDACTED]
 CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
 CR2: [PII_REDACTED] CR3:[PII_REDACTED]7e6001 CR4:[PII_REDACTED]370eb0
 Call Trace:
  <TASK>
  ? __die+0x20/0x60
  ? page_fault_oops+0x150/0x3e0
  ? exc_page_fault+0x74/0x130
  ? asm_exc_page_fault+0x22/0x30
  ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib]
  __ib_process_cq+0x5a/0x150 [ib_core]
  ib_cq_poll_work+0x31/0x90 [ib_core]
  process_one_work+0x169/0x320
  worker_thread+0x288/0x3a0
  ? work_busy+0xb0/0xb0
  kthread+0xd7/0x1f0
  ? kthreads_online_cpu+0x130/0x130
  ? kthreads_online_cpu+0x130/0x130
  ret_from_fork+0x2d/0x50
  ? kthreads_online_cpu+0x130/0x130
  ret_from_fork_asm+0x11/0x20
  </TASK>
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/3b97d[PII_REDACTED]5ac5ce8ffbc6e716928310f7f; https://git.kernel.org/stable/c/55c65a64aefa6267b964d90e9a4039cb68ec73a5; https://git.kernel.org/stable/c/5ed3b0cb3f827072e93b4c5b6e2b8106fd7cccbd
CVE: CVE-2025-22087
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix array bounds error with may_goto

may_goto uses an additional 8 bytes on the stack, which causes the
interpreters[] array to go out of bounds when calculating index by
stack_size.

1. If a BPF program is rewritten, re-evaluate the stack size. For non-JIT
cases, reject loading directly.

2. For non-JIT cases, calculating interpreters[idx] may still cause
out-of-bounds array access, and just warn about it.

3. For jit_requested cases, the execution of bpf_func also needs to be
warned. So move the definition of function __bpf_prog_ret0_warn out of
the macro definition CONFIG_BPF_JIT_ALWAYS_ON.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/19e6817f84000d0b06f09fd69ebd56217842c122; https://git.kernel.org/stable/c/1a86ae57b2600e5749f5f674e9d4296ac00c69a8; https://git.kernel.org/stable/c/4524b7febdd55fb99ae2e1f48db64019fa69e643
CVE: CVE-2025-22088
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/erdma: Prevent use-after-free in erdma_accept_newconn()

After the erdma_cep_put(new_cep) being called, new_cep will be freed,
and the following dereference will cause a UAF problem. Fix this issue.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/667a628ab67d359166799fad89b3c[PII_REDACTED]a; https://git.kernel.org/stable/c/78411a133312ce7d8a3239c76a8fd85bca1cc10f; https://git.kernel.org/stable/c/7aa6bb5276d9fec98deb05615a086eeb893854ad
CVE: CVE-2025-22090
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range()

If track_pfn_copy() fails, we already added the dst VMA to the maple
tree. As fork() fails, we'll cleanup the maple tree, and stumble over
the dst VMA for which we neither performed any reservation nor copied
any page tables.

Consequently untrack_pfn() will see VM_PAT and try obtaining the
PAT information from the page table -- which fails because the page
table was not copied.

The easiest fix would be to simply clear the VM_PAT flag of the dst VMA
if track_pfn_copy() fails. However, the whole thing is about "simply"
clearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy()
and performed a reservation, but copying the page tables fails, we'll
simply clear the VM_PAT flag, not properly undoing the reservation ...
which is also wrong.

So let's fix it properly: set the VM_PAT flag only if the reservation
succeeded (leaving it clear initially), and undo the reservation if
anything goes wrong while copying the page tables: clearing the VM_PAT
flag after undoing the reservation.

Note that any copied page table entries will get zapped when the VMA will
get removed later, after copy_page_range() succeeded; as VM_PAT is not set
then, we won't try cleaning VM_PAT up once more and untrack_pfn() will be
happy. Note that leaving these page tables in place without a reservation
is not a problem, as we are aborting fork(); this process will never run.

A reproducer can trigger this usually at the first try:

  https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c

  WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110
  Modules linked in: ...
  CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ #92
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014
  RIP: 0010:get_pat_info+0xf6/0x110
  ...
  Call Trace:
   <TASK>
   ...
   untrack_pfn+0x52/0x110
   unmap_single_vma+0xa6/0xe0
   unmap_vmas+0x105/0x1f0
   exit_mmap+0xf6/0x460
   __mmput+0x4b/0x120
   copy_process+0x1bf6/0x2aa0
   kernel_clone+0xab/0x440
   __do_sys_clone+0x66/0x90
   do_syscall_64+0x95/0x180

Likely this case was missed in:

  d155df53f310 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed")

... and instead of undoing the reservation we simply cleared the VM_PAT flag.

Keep the documentation of these functions in include/linux/pgtable.h,
one place is more than sufficient -- we should clean that up for the other
functions like track_pfn_remap/untrack_pfn separately.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/8d6373f83f367dbed316ddeb178130a3a64b5b67; https://git.kernel.org/stable/c/a6623712ba8449876f0b3de[PII_REDACTED]fb851e4; https://git.kernel.org/stable/c/b07398e8a5da517083f5c3f2daa8f6681b48ab28
CVE: CVE-2025-22092
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

PCI: Fix NULL dereference in SR-IOV VF creation error path

Clean up when virtfn setup fails to prevent NULL pointer dereference
during device removal. The kernel oops below occurred due to incorrect
error handling flow when pci_setup_device() fails.

Add pci_iov_scan_device(), which handles virtfn allocation and setup and
cleans up if pci_setup_device() fails, so pci_iov_add_virtfn() doesn't need
to call pci_stop_and_remove_bus_device().  This prevents accessing
partially initialized virtfn devices during removal.

  BUG: kernel NULL pointer dereference, address:[PII_REDACTED]0000d0
  RIP: 0010:device_del+0x3d/0x3d0
  Call Trace:
   pci_remove_bus_device+0x7c/0x100
   pci_iov_add_virtfn+0xfa/0x200
   sriov_enable+0x208/0x420
   mlx5_core_sriov_configure+0x6a/0x160 [mlx5_core]
   sriov_numvfs_store+0xae/0x1a0

[bhelgaas: commit log, return ERR_PTR(-ENOMEM) directly]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/04d50d953ab46d96b0b32d5ad955fceaa28622db; https://git.kernel.org/stable/c/c67a233834b778b8c78f8b62c072ccf87a9eb6d0; https://git.kernel.org/stable/c/ef421b4d206f0d3681804b8f94f06a8458a53aaf
CVE: CVE-2025-22094
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

powerpc/perf: Fix ref-counting on the PMU 'vpa_pmu'

Commit 176cda0619b6 ("powerpc/perf: Add perf interface to expose vpa
counters") introduced 'vpa_pmu' to expose Book3s-HV nested APIv2 provided
L1<->L2 context switch latency counters to L1 user-space via
perf-events. However the newly introduced PMU named 'vpa_pmu' doesn't
assign ownership of the PMU to the module 'vpa_pmu'. Consequently the
module 'vpa_pmu' can be unloaded while one of the perf-events are still
active, which can lead to kernel oops and panic of the form below on a
Pseries-LPAR:

BUG: Kernel NULL pointer dereference on read at 0x00000058
<snip>
 NIP [c[PII_REDACTED]06cb8] event_sched_out+0x40/0x258
 LR [c[PII_REDACTED]0e8a4] __perf_remove_from_context+0x7c/0x2b0
 Call Trace:
 [c00000025fc3fc30] [c00000025f8457a8] 0xc00000025f8457a8 (unreliable)
 [c00000025fc3fc80] [fffffffffffffee0] 0xfffffffffffffee0
 [c00000025fc3fcd0] [c[PII_REDACTED]01e70] event_function+0xa8/0x120
<snip>
 Kernel panic - not syncing: Aiee, killing interrupt handler!

Fix this by adding the module ownership to 'vpa_pmu' so that the module
'vpa_pmu' is ref-counted and prevented from being unloaded when perf-events
are initialized.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/6cf045b51e2c5721db7e55305f09ee32741e00f9; https://git.kernel.org/stable/c/70ea7c5189197c6f5acdcfd8a2651be2c41e2faa; https://git.kernel.org/stable/c/ff99d5b6a246715f2257123cdf6c4a29cb33aa78
CVE: CVE-2025-22095
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

PCI: brcmstb: Fix error path after a call to regulator_bulk_get()

If the regulator_bulk_get() returns an error and no regulators
are created, we need to set their number to zero.

If we don't do this and the PCIe link up fails, a call to the
regulator_bulk_free() will result in a kernel panic.

While at it, print the error value, as we cannot return an error
upwards as the kernel will WARN() on an error from add_bus().

[kwilczynski: commit log, use comma in the message to match style with
other similar messages]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3651ad5249c51cf7eee078e[PII_REDACTED]a6bdb4; https://git.kernel.org/stable/c/6f44e1fdb006db61394aa4d4c25728ada00842e7; https://git.kernel.org/stable/c/7842e842a9bf6bd5866c84f588353711d131ab1a
CVE: CVE-2025-22096
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm/gem: Fix error code msm_parse_deps()

The SUBMIT_ERROR() macro turns the error code negative.  This extra '-'
operation turns it back to positive EINVAL again.  The error code is
passed to ERR_PTR() and since positive values are not an IS_ERR() it
eventually will lead to an oops.  Delete the '-'.

Patchwork: https://patchwork.freedesktop.org/patch/637625/
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0b305b7cadce835505bd93183a599acb1f800a05; https://git.kernel.org/stable/c/efe759dcf3352d8379a1adad7b4d14044a4c41a7
CVE: CVE-2025-22097
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/vkms: Fix use after free and double free on init error

If the driver initialization fails, the vkms_exit() function might
access an uninitialized or freed default_config pointer and it might
double free it.

Fix both possible errors by initializing default_config only when the
driver initialization succeeded.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/1f68f1cf09d06061eb549726ff8339e064eddebd; https://git.kernel.org/stable/c/49a69f67f53518bdd9b7eeebf019a2da6cc0e954; https://git.kernel.org/stable/c/561fc0c5cf41f646f3e9e61784cbc0fc832fb936
CVE: CVE-2025-22098
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm: zynqmp_dp: Fix a deadlock in zynqmp_dp_ignore_hpd_set()

Instead of attempting the same mutex twice, lock and unlock it.

This bug has been detected by the Clang thread-safety analyzer.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/3f988cd2f65175e79349961a43a9deb115174784; https://git.kernel.org/stable/c/7a8d53aa5b7d2a89cda598239d08423bd66920f1; https://git.kernel.org/stable/c/f887685ee0eb4ef[PII_REDACTED][PII_REDACTED]8f6eb
CVE: CVE-2025-22099
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm: xlnx: zynqmp_dpsub: Add NULL check in zynqmp_audio_init

devm_kasprintf() calls can return null pointers on failure.
But some return values were not checked in zynqmp_audio_init().

Add NULL check in zynqmp_audio_init(), avoid referencing null
pointers in the subsequent code.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/066d6f22e7d84953db6bbf2dae[PII_REDACTED]60c6; https://git.kernel.org/stable/c/d0660f9c588a1246a1a543c91a1e3cad910237da
CVE: CVE-2025-22100
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/panthor: Fix race condition when gathering fdinfo group samples

Commit e16635d88fa0 ("drm/panthor: add DRM fdinfo support") failed to
protect access to groups with an xarray lock, which could lead to
use-after-free errors.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/0590c94c3596d6c1a3d549ae611366f2ad4e1d8d; https://git.kernel.org/stable/c/6d98c83ad67e7bd86a47494fd6c3863e7bb26db9; https://git.kernel.org/stable/c/e9d45f42a64a400adba59ee83d03e6db662530b4
CVE: CVE-2025-22101
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: libwx: fix Tx L4 checksum

The hardware only supports L4 checksum offload for TCP/UDP/SCTP protocol.
There was a bug to set Tx checksum flag for the other protocol that results
in Tx ring hang. Fix to compute software checksum for these packets.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/5f583e059eced1857f41e221ef5951e029e632bd; https://git.kernel.org/stable/c/6d56ea133adf0389b216ba6e47f7f35e95776713; https://git.kernel.org/stable/c/c7d82913d5f9e97860772ee4051eaa66b56a6273
CVE: CVE-2025-22103
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: fix NULL pointer dereference in l3mdev_l3_rcv

When delete l3s ipvlan:

    ip link del link eth0 ipvlan1 type ipvlan mode l3s

This may cause a null pointer dereference:

    Call trace:
     ip_rcv_finish+0x48/0xd0
     ip_rcv+0x5c/0x100
     __netif_receive_skb_one_core+0x64/0xb0
     __netif_receive_skb+0x20/0x80
     process_backlog+0xb4/0x204
     napi_poll+0xe8/0x294
     net_rx_action+0xd8/0x22c
     __do_softirq+0x12c/0x354

This is because l3mdev_l3_rcv() visit dev->l3mdev_ops after
ipvlan_l3s_unregister() assign the dev->l3mdev_ops to NULL. The process
like this:

    (CPU1)                     | (CPU2)
    l3mdev_l3_rcv()            |
      check dev->priv_flags:   |
        master = skb->dev;     |
                               |
                               | ipvlan_l3s_unregister()
                               |   set dev->priv_flags
                               |   dev->l3mdev_ops = NULL;
                               |
      visit master->l3mdev_ops |

To avoid this by do not set dev->l3mdev_ops when unregister l3s ipvlan.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0032c99e83b9ce6d5995d65900aa4b6ffb501cce; https://git.kernel.org/stable/c/52b44d8c653459c658b733d13658afdde45f6836; https://git.kernel.org/stable/c/59599bce44af3df7a215ebc81cb166426e1c9204
CVE: CVE-2025-22104
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

ibmvnic: Use kernel helpers for hex dumps

Previously, when the driver was printing hex dumps, the buffer was cast
to an 8 byte long and printed using string formatters. If the buffer
size was not a multiple of 8 then a read buffer overflow was possible.

Therefore, create a new ibmvnic function that loops over a buffer and
calls hex_dump_to_buffer instead.

This patch address KASAN reports like the one below:
  ibmvnic 30000003 env3: Login Buffer:
  ibmvnic 30000003 env3: 01000000af000000
  <...>
  ibmvnic 30000003 env3: 2e6d62692e736261
  ibmvnic 30000003 env3:[PII_REDACTED]6d6f63
  ==================================================================
  BUG: KASAN: slab-out-of-bounds in ibmvnic_login+0xacc/0xffc [ibmvnic]
  Read of size 8 at addr c[PII_REDACTED]a9aa8 by task ip/17681
  <...>
  Allocated by task 17681:
  <...>
  ibmvnic_login+0x2f0/0xffc [ibmvnic]
  ibmvnic_open+0x148/0x308 [ibmvnic]
  __dev_open+0x1ac/0x304
  <...>
  The buggy address is located 168 bytes inside of
                allocated 175-byte region [c[PII_REDACTED]a9a00, c[PII_REDACTED]a9aaf)
  <...>
  =================================================================
  ibmvnic 30000003 env3:[PII_REDACTED]33766e
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/ae6b1d6c1acee3a2000394d83ec9f1028321e207; https://git.kernel.org/stable/c/d93a6caab5d7d9b5ce034d75b1e1e993338e3852
CVE: CVE-2025-22105
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

bonding: check xdp prog when set bond mode

Following operations can trigger a warning[1]:

    ip netns add ns1
    ip netns exec ns1 ip link add bond0 type bond mode balance-rr
    ip netns exec ns1 ip link set dev bond0 xdp obj af_xdp_kern.o sec xdp
    ip netns exec ns1 ip link set bond0 type bond mode broadcast
    ip netns del ns1

When delete the namespace, dev_xdp_uninstall() is called to remove xdp
program on bond dev, and bond_xdp_set() will check the bond mode. If bond
mode is changed after attaching xdp program, the warning may occur.

Some bond modes (broadcast, etc.) do not support native xdp. Set bond mode
with xdp program attached is not good. Add check for xdp program when set
bond mode.

    [1]
    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 11 at net/core/dev.c:9912 unregister_netdevice_many_notify+0x8d9/0x930
    Modules linked in:
    CPU: 0 UID: 0 PID: 11 Comm: kworker/u4:0 Not tainted 6.14.0-rc4 #107
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
    Workqueue: netns cleanup_net
    RIP: 0010:unregister_netdevice_many_notify+0x8d9/0x930
    Code: 00 00 48 c7 c6 6f e3 a2 82 48 c7 c7 d0 b3 96 82 e8 9c 10 3e ...
    RSP: 0018:ffffc90000063d80 EFLAGS: 00000282
    RAX: 00000000ffffffa1 RBX: ffff[PII_REDACTED]00 RCX: 00000000ffffdfff
    RDX: [PII_REDACTED] RSI: 00000000ffffffea RDI: ffffc90000063b48
    RBP: ffffc90000063e28 R08: ffffffff82d39b28 R09:[PII_REDACTED]009ffb
    R10: [PII_REDACTED] R11: ffffffff82d09b40 R12: ffff[PII_REDACTED]e8
    R13: [PII_REDACTED] R14: dead[PII_REDACTED]00 R15: ffffc[PII_REDACTED]0
    FS:  [PII_REDACTED](0000) GS:ffff888007a00000(0000) knlGS:[PII_REDACTED]
    CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
    CR2: 000000000d406b60 CR3:[PII_REDACTED]83e000 CR4:[PII_REDACTED]0006f0
    Call Trace:
     <TASK>
     ? __warn+0x83/0x130
     ? unregister_netdevice_many_notify+0x8d9/0x930
     ? report_bug+0x18e/0x1a0
     ? handle_bug+0x54/0x90
     ? exc_invalid_op+0x18/0x70
     ? asm_exc_invalid_op+0x1a/0x20
     ? unregister_netdevice_many_notify+0x8d9/0x930
     ? bond_net_exit_batch_rtnl+0x5c/0x90
     cleanup_net+0x237/0x3d0
     process_one_work+0x163/0x390
     worker_thread+0x293/0x3b0
     ? __pfx_worker_thread+0x10/0x10
     kthread+0xec/0x1e0
     ? __pfx_kthread+0x10/0x10
     ? __pfx_kthread+0x10/0x10
     ret_from_fork+0x2f/0x50
     ? __pfx_kthread+0x10/0x10
     ret_from_fork_asm+0x1a/0x30
     </TASK>
    ---[ end trace [PII_REDACTED] ]---
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/094ee6017ea09c11d6af187935a949df32803ce0; https://git.kernel.org/stable/c/0dd4fac43bdea23cfe4bb2a3eabb76d752ac32fb; https://git.kernel.org/stable/c/5106da73b01668a1aa5d0f352b95d2b832b5caa7
CVE: CVE-2025-22106
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

vmxnet3: unregister xdp rxq info in the reset path

vmxnet3 does not unregister xdp rxq info in the
vmxnet3_reset_work() code path as vmxnet3_rq_destroy()
is not invoked in this code path. So, we get below message with a
backtrace.

Missing unregister, handled but fix driver
WARNING: CPU:48 PID: 500 at net/core/xdp.c:182
__xdp_rxq_info_reg+0x93/0xf0

This patch fixes the problem by moving the unregister
code of XDP from vmxnet3_rq_destroy() to vmxnet3_rq_cleanup().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0dd765fae295832934bf28e45dd5a355e0891ed4; https://git.kernel.org/stable/c/23da4e0bb2a38966d29db0ff90a8fe68fdfa1744; https://git.kernel.org/stable/c/9908541a9e235b7c5e2fbdd59910eaf9c32c3075
CVE: CVE-2025-22107
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry()

There are actually 2 problems:
- deleting the last element doesn't require the memmove of elements
  [i + 1, end) over it. Actually, element i+1 is out of bounds.
- The memmove itself should move size - i - 1 elements, because the last
  element is out of bounds.

The out-of-bounds element still remains out of bounds after being
accessed, so the problem is only that we touch it, not that it becomes
in active use. But I suppose it can lead to issues if the out-of-bounds
element is part of an unmapped page.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/031e00249e9e6bee72ba66701c8f83b45fc4b8a2; https://git.kernel.org/stable/c/4584486cfcca24b7b586da3377eb3cffd48669ec; https://git.kernel.org/stable/c/59b97641de03c081f26b3a8876628c765b5faa25
CVE: CVE-2025-22108
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

bnxt_en: Mask the bd_cnt field in the TX BD properly

The bd_cnt field in the TX BD specifies the total number of BDs for
the TX packet.  The bd_cnt field has 5 bits and the maximum number
supported is 32 with the value 0.

CONFIG_MAX_SKB_FRAGS can be modified and the total number of SKB
fragments can approach or exceed the maximum supported by the chip.
Add a macro to properly mask the bd_cnt field so that the value 32
will be properly masked and set to 0 in the bd_cnd field.

Without this patch, the out-of-range bd_cnt value will corrupt the
TX BD and may cause TX timeout.

The next patch will check for values exceeding 32.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/107b25db61122d8f990987895c2912927b8b6e3f; https://git.kernel.org/stable/c/f60b41b815826f15c4d0323f923f398c423178d0