deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-38034
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: correct the order of prelim_ref arguments in btrfs__prelim_ref

btrfs_prelim_ref() calls the old and new reference variables in the
incorrect order. This causes a NULL pointer dereference because oldref
is passed as NULL to trace_btrfs_prelim_ref_insert().

Note, trace_btrfs_prelim_ref_insert() is being called with newref as
oldref (and oldref as NULL) on purpose in order to print out
the values of newref.

To reproduce:
echo 1 > /sys/kernel/debug/tracing/events/btrfs/btrfs_prelim_ref_insert/enable

Perform some writeback operations.

Backtrace:
BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 115949067 P4D 115949067 PUD 11594a067 PMD 0
 Oops: Oops: 0000 [#1] SMP NOPTI
 CPU: 1 UID: 0 PID: 1188 Comm: fsstress Not tainted 6.15.0-rc2-tester+ #47 PREEMPT(voluntary)  7ca2cef72d5e9c600f0c7718adb6462de8149622
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014
 RIP: 0010:trace_event_raw_event_btrfs__prelim_ref+0x72/0x130
 Code: e8 43 81 9f ff 48 85 c0 74 78 4d 85 e4 0f 84 8f 00 00 00 49 8b 94 24 c0 06 00 00 48 8b 0a 48 89 48 08 48 8b 52 08 48 89 50 10 <49> 8b 55 18 48 89 50 18 49 8b 55 20 48 89 50 20 41 0f b6 55 28 88
 RSP: 0018:ffffce44820077a0 EFLAGS: 00010286
 RAX: ffff8c6b403f9014 RBX: ffff8c6b55825730 RCX: 304994edf9cf506b
 RDX: d8b11eb7f0fdb699 RSI: ffff8c6b403f9010 RDI: ffff8c6b403f9010
 RBP: [PII_REDACTED] R08: [PII_REDACTED] R09: [PII_REDACTED]
 R10: 00000000ffffffff R11: [PII_REDACTED] R12: ffff8c6b4e8fb000
 R13: [PII_REDACTED] R14: ffffce44820077a8 R15: ffff8c6b4abd1540
 FS:  00007f4dc6813740(0000) GS:ffff8c6c1d378000(0000) knlGS:[PII_REDACTED]
 CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
 CR2: [PII_REDACTED] CR3: 000000010eb42000 CR4:[PII_REDACTED]750ef0
 PKRU: 55555554
 Call Trace:
  <TASK>
  prelim_ref_insert+0x1c1/0x270
  find_parent_nodes+0x12a6/0x1ee0
  ? __entry_text_end+0x101f06/0x101f09
  ? srso_alias_return_thunk+0x5/0xfbef5
  ? srso_alias_return_thunk+0x5/0xfbef5
  ? srso_alias_return_thunk+0x5/0xfbef5
  ? srso_alias_return_thunk+0x5/0xfbef5
  btrfs_is_data_extent_shared+0x167/0x640
  ? fiemap_process_hole+0xd0/0x2c0
  extent_fiemap+0xa5c/0xbc0
  ? __entry_text_end+0x101f05/0x101f09
  btrfs_fiemap+0x7e/0xd0
  do_vfs_ioctl+0x425/0x9d0
  __x64_sys_ioctl+0x75/0xc0
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0528bba48dce7820d2da72e1a114e1c4552367eb; https://git.kernel.org/stable/c/137bfa08c6441f324d00692d1e9d22cfd773329b; https://git.kernel.org/stable/c/5755b6731655e248c4f1d52a2e1b18795b4a2a3a
CVE: CVE-2025-38036
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/xe/vf: Perform early GT MMIO initialization to read GMDID

VFs need to communicate with the GuC to obtain the GMDID value
and existing GuC functions used for that assume that the GT has
it's MMIO members already setup. However, due to recent refactoring
the gt->mmio is initialized later, and any attempt by the VF to use
xe_mmio_read|write() from GuC functions will lead to NPD crash due
to unset MMIO register address:

[] xe 0000:00:02.1: [drm] Running in SR-IOV VF mode
[] xe 0000:00:02.1: [drm] GT0: sending H2G MMIO 0x5507
[] BUG: unable to handle page fault for address: [PII_REDACTED]

Since we are already tweaking the id and type of the primary GT to
mimic it's a Media GT before initializing the GuC communication,
we can also call xe_gt_mmio_init() to perform early setup of the
gt->mmio which will make those GuC functions work again.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/13265fe7426ec9ba5aa86baab913417ca361e8a4; https://git.kernel.org/stable/c/ef6e950aea76a5009ccc79ebfa955ecc66cd85a2
CVE: CVE-2025-38037
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

vxlan: Annotate FDB data races

The 'used' and 'updated' fields in the FDB entry structure can be
accessed concurrently by multiple threads, leading to reports such as
[1]. Can be reproduced using [2].

Suppress these reports by annotating these accesses using
READ_ONCE() / WRITE_ONCE().

[1]
BUG: KCSAN: data-race in vxlan_xmit / vxlan_xmit

write to 0xffff942604d263a8 of 8 bytes by task 286 on cpu 0:
 vxlan_xmit+0xb29/0x2380
 dev_hard_start_xmit+0x84/0x2f0
 __dev_queue_xmit+0x45a/0x1650
 packet_xmit+0x100/0x150
 packet_sendmsg+0x2114/0x2ac0
 __sys_sendto+0x318/0x330
 __x64_sys_sendto+0x76/0x90
 x64_sys_call+0x14e8/0x1c00
 do_syscall_64+0x9e/0x1a0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

read to 0xffff942604d263a8 of 8 bytes by task 287 on cpu 2:
 vxlan_xmit+0xadf/0x2380
 dev_hard_start_xmit+0x84/0x2f0
 __dev_queue_xmit+0x45a/0x1650
 packet_xmit+0x100/0x150
 packet_sendmsg+0x2114/0x2ac0
 __sys_sendto+0x318/0x330
 __x64_sys_sendto+0x76/0x90
 x64_sys_call+0x14e8/0x1c00
 do_syscall_64+0x9e/0x1a0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

value changed: 0x00000000fffbac6e -> 0x00000000fffbac6f

Reported by Kernel Concurrency Sanitizer on:
CPU: 2 UID: 0 PID: 287 Comm: mausezahn Not tainted 6.13.0-rc7-01544-gb4b270f11a02 #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014

[2]
 #!/bin/bash

 set +H
 echo whitelist > /sys/kernel/debug/kcsan
 echo !vxlan_xmit > /sys/kernel/debug/kcsan

 ip link add name vx0 up type vxlan id 10010 dstport 4789 local 192.0.2.1
 bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 198.51.100.1
 taskset -c 0 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q &
 taskset -c 2 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q &
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/02a33b1035a307453a1da6ce0a1bf3676be287d7; https://git.kernel.org/stable/c/13cba3f837903f7184d6e9b6137d5165ffe82a8f; https://git.kernel.org/stable/c/4eceb7eae6ea7c950384c34e6dbbe872c981935f
CVE: CVE-2025-38038
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

cpufreq: amd-pstate: Remove unnecessary driver_lock in set_boost

set_boost is a per-policy function call, hence a driver wide lock is
unnecessary. Also this mutex_acquire can collide with the mutex_acquire
from the mode-switch path in status_store(), which can lead to a
deadlock. So, remove it.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/61e931ee145eeab8196e585ff4334870b130b744; https://git.kernel.org/stable/c/cd347d[PII_REDACTED]86762d79c5a691785e9be418; https://git.kernel.org/stable/c/db1cafc77aaaf871509da06f4a864e9af6d6791f
CVE: CVE-2025-38039
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Avoid WARN_ON when configuring MQPRIO with HTB offload enabled

When attempting to enable MQPRIO while HTB offload is already
configured, the driver currently returns `-EINVAL` and triggers a
`WARN_ON`, leading to an unnecessary call trace.

Update the code to handle this case more gracefully by returning
`-EOPNOTSUPP` instead, while also providing a helpful user message.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/090c0ba179eaf7b670e720aa054533756a43d565; https://git.kernel.org/stable/c/689805dcc474c2accb5cffbbcea1c06ee4a54570; https://git.kernel.org/stable/c/9e2bac6835f73895598df5a3a125a19497fad46b
CVE: CVE-2025-38040
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

serial: mctrl_gpio: split disable_ms into sync and no_sync APIs

The following splat has been observed on a SAMA5D27 platform using
atmel_serial:

BUG: sleeping function called from invalid context at kernel/irq/manage.c:738
in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 27, name: kworker/u5:0
preempt_count: 1, expected: 0
INFO: lockdep is turned off.
irq event stamp: 0
hardirqs last  enabled at (0): [<00000000>] 0x0
hardirqs last disabled at (0): [<c01588f0>] copy_process+0x1c4c/0x7bec
softirqs last  enabled at (0): [<c0158944>] copy_process+0x1ca0/0x7bec
softirqs last disabled at (0): [<00000000>] 0x0
CPU: 0 UID: 0 PID: 27 Comm: kworker/u5:0 Not tainted 6.13.0-rc7+ #74
Hardware name: Atmel SAMA5
Workqueue: hci0 hci_power_on [bluetooth]
Call trace:
  unwind_backtrace from show_stack+0x18/0x1c
  show_stack from dump_stack_lvl+0x44/0x70
  dump_stack_lvl from __might_resched+0x38c/0x598
  __might_resched from disable_irq+0x1c/0x48
  disable_irq from mctrl_gpio_disable_ms+0x74/0xc0
  mctrl_gpio_disable_ms from atmel_disable_ms.part.0+0x80/0x1f4
  atmel_disable_ms.part.0 from atmel_set_termios+0x764/0x11e8
  atmel_set_termios from uart_change_line_settings+0x15c/0x994
  uart_change_line_settings from uart_set_termios+0x2b0/0x668
  uart_set_termios from tty_set_termios+0x600/0x8ec
  tty_set_termios from ttyport_set_flow_control+0x188/0x1e0
  ttyport_set_flow_control from wilc_setup+0xd0/0x524 [hci_wilc]
  wilc_setup [hci_wilc] from hci_dev_open_sync+0x330/0x203c [bluetooth]
  hci_dev_open_sync [bluetooth] from hci_dev_do_open+0x40/0xb0 [bluetooth]
  hci_dev_do_open [bluetooth] from hci_power_on+0x12c/0x664 [bluetooth]
  hci_power_on [bluetooth] from process_one_work+0x998/0x1a38
  process_one_work from worker_thread+0x6e0/0xfb4
  worker_thread from kthread+0x3d4/0x484
  kthread from ret_from_fork+0x14/0x28

This warning is emitted when trying to toggle, at the highest level,
some flow control (with serdev_device_set_flow_control) in a device
driver. At the lowest level, the atmel_serial driver is using
serial_mctrl_gpio lib to enable/disable the corresponding IRQs
accordingly.  The warning emitted by CONFIG_DEBUG_ATOMIC_SLEEP is due to
disable_irq (called in mctrl_gpio_disable_ms) being possibly called in
some atomic context (some tty drivers perform modem lines configuration
in regions protected by port lock).

Split mctrl_gpio_disable_ms into two differents APIs, a non-blocking one
and a blocking one. Replace mctrl_gpio_disable_ms calls with the
relevant version depending on whether the call is protected by some port
lock.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1bd2aad57da95f7f2d2bb52f7ad15c0f4993a685; https://git.kernel.org/stable/c/68435c1fa3db696db4f480385db9e50e26691d0d; https://git.kernel.org/stable/c/7187ec6b0b9ff22ebac2c3bb4178b7dbbdc0a55a
CVE: CVE-2025-38041
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: sunxi-ng: h616: Reparent GPU clock during frequency changes

The H616 manual does not state that the GPU PLL supports
dynamic frequency configuration, so we must take extra care when changing
the frequency. Currently any attempt to do device DVFS on the GPU lead
to panfrost various ooops, and GPU hangs.

The manual describes the algorithm for changing the PLL
frequency, which the CPU PLL notifier code already support, so we reuse
that to reparent the GPU clock to GPU1 clock during frequency
changes.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1439673b78185eaaa5fae444b3a9d58c434ee78e; https://git.kernel.org/stable/c/eb963d7948ce6571939c6875424b557b25f16610
CVE: CVE-2025-38043
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

firmware: arm_ffa: Set dma_mask for ffa devices

Set dma_mask for FFA devices, otherwise DMA allocation using the device pointer
lead to following warning:

WARNING: CPU: 1 PID: 1 at kernel/dma/mapping.c:597 dma_alloc_attrs+0xe0/0x124
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2e62c803feec1ef5847d8fa47dd0de039abfa378; https://git.kernel.org/stable/c/3a3efeef64364c2a028cf0d03d68c831813a97fd; https://git.kernel.org/stable/c/97bab02f0b64ba6bcdf6a8fae561db07f509aee9
CVE: CVE-2025-38044
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

media: cx231xx: set device_caps for 417

The video_device for the MPEG encoder did not set device_caps.

Add this, otherwise the video device can't be registered (you get a
WARN_ON instead).

Not seen before since currently 417 support is disabled, but I found
this while experimenting with it.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0884dd3abbe80307a2d4cbdbe5e312be164f8adb; https://git.kernel.org/stable/c/2ad41beb7df3bd63b209842d16765ec59dafe6e4; https://git.kernel.org/stable/c/4731d5328f507ae8fd8a57abbca9119ec7a8d665
CVE: CVE-2025-38045
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: fix debug actions order

The order of actions taken for debug was implemented incorrectly.
Now we implemented the dump split and do the FW reset only in the
middle of the dump (rather than the FW killing itself on error.)
As a result, some of the actions taken when applying the config
will now crash the device, so we need to fix the order.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/181e8b56b74ad3920456dcdc8a361520d9007956; https://git.kernel.org/stable/c/2b790fe67ed483d86c1aeb8be6735bf792caa7e5; https://git.kernel.org/stable/c/328fbc96ecbee16c5fcbfcb3ac57b476f94da2f0
CVE: CVE-2025-38046
Published: 2025-06-18
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2025-38047
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/fred: Fix system hang during S4 resume with FRED enabled

Upon a wakeup from S4, the restore kernel starts and initializes the
FRED MSRs as needed from its perspective.  It then loads a hibernation
image, including the image kernel, and attempts to load image pages
directly into their original page frames used before hibernation unless
those frames are currently in use.  Once all pages are moved to their
original locations, it jumps to a "trampoline" page in the image kernel.

At this point, the image kernel takes control, but the FRED MSRs still
contain values set by the restore kernel, which may differ from those
set by the image kernel before hibernation.  Therefore, the image kernel
must ensure the FRED MSRs have the same values as before hibernation.
Since these values depend only on the location of the kernel text and
data, they can be recomputed from scratch.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/c42f740a07eea4807e98d2d8febc549c957a7b49; https://git.kernel.org/stable/c/e5f1e8af9c9e151ecd665f6d2e36fb25fec3b110; https://git.kernel.org/stable/c/e7090fe75a2826363c71ad1fb4e95e58141478df
CVE: CVE-2025-38048
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

virtio_ring: Fix data race by tagging event_triggered as racy for KCSAN

syzbot reports a data-race when accessing the event_triggered, here is the
simplified stack when the issue occurred:

==================================================================
BUG: KCSAN: data-race in virtqueue_disable_cb / virtqueue_enable_cb_delayed

write to 0xffff8881025bc452 of 1 bytes by task 3288 on cpu 0:
 virtqueue_enable_cb_delayed+0x42/0x3c0 drivers/virtio/virtio_ring.c:2653
 start_xmit+0x230/0x1310 drivers/net/virtio_net.c:3264
 __netdev_start_xmit include/linux/netdevice.h:5151 [inline]
 netdev_start_xmit include/linux/netdevice.h:5160 [inline]
 xmit_one net/core/dev.c:3800 [inline]

read to 0xffff8881025bc452 of 1 bytes by interrupt on cpu 1:
 virtqueue_disable_cb_split drivers/virtio/virtio_ring.c:880 [inline]
 virtqueue_disable_cb+0x92/0x180 drivers/virtio/virtio_ring.c:2566
 skb_xmit_done+0x5f/0x140 drivers/net/virtio_net.c:777
 vring_interrupt+0x161/0x190 drivers/virtio/virtio_ring.c:2715
 __handle_irq_event_percpu+0x95/0x490 kernel/irq/handle.c:158
 handle_irq_event_percpu kernel/irq/handle.c:193 [inline]

value changed: 0x01 -> 0x00
==================================================================

When the data race occurs, the function virtqueue_enable_cb_delayed() sets
event_triggered to false, and virtqueue_disable_cb_split/packed() reads it
as false due to the race condition. Since event_triggered is an unreliable
hint used for optimization, this should only cause the driver temporarily
suggest that the device not send an interrupt notification when the event
index is used.

Fix this KCSAN reported data-race issue by explicitly tagging the access as
data_racy.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/02d2d6caee3abc9335cfca35f8eb4492173ae6f2; https://git.kernel.org/stable/c/2e2f925fe737576df2373931c95e1a2b66efdfef; https://git.kernel.org/stable/c/4ed8f0e808b3fcc71c5b8be7902d8738ed595b17
CVE: CVE-2025-38050
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/hugetlb: fix kernel NULL pointer dereference when replacing free hugetlb folios

A kernel crash was observed when replacing free hugetlb folios:

BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 28 UID: 0 PID: 29639 Comm: test_cma.sh Tainted 6.15.0-rc6-zp #41 PREEMPT(voluntary)
RIP: 0010:alloc_and_dissolve_hugetlb_folio+0x1d/0x1f0
RSP: 0018:ffffc9000b30fa90 EFLAGS: 00010286
RAX: [PII_REDACTED] RBX:[PII_REDACTED]342cca RCX: ffffea[PII_REDACTED]
RDX: ffffc9000b30fb08 RSI: ffffea[PII_REDACTED] RDI: [PII_REDACTED]
RBP: ffffc9000b30fb20 R08: [PII_REDACTED] R09: [PII_REDACTED]
R10: ffff88886f92eb00 R11: [PII_REDACTED] R12: ffffea[PII_REDACTED]
R13: [PII_REDACTED] R14:[PII_REDACTED]0c0200 R15: [PII_REDACTED]
FS:  00007fcda5f14740(0000) GS:ffff8888ec1d8000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: [PII_REDACTED] CR3: [PII_REDACTED] CR4:[PII_REDACTED]350ef0
Call Trace:
<TASK>
 replace_free_hugepage_folios+0xb6/0x100
 alloc_contig_range_noprof+0x18a/0x590
 ? srso_return_thunk+0x5/0x5f
 ? down_read+0x12/0xa0
 ? srso_return_thunk+0x5/0x5f
 cma_range_alloc.constprop.0+0x131/0x290
 __cma_alloc+0xcf/0x2c0
 cma_alloc_write+0x43/0xb0
 simple_attr_write_xsigned.constprop.0.isra.0+0xb2/0x110
 debugfs_attr_write+0x46/0x70
 full_proxy_write+0x62/0xa0
 vfs_write+0xf8/0x420
 ? srso_return_thunk+0x5/0x5f
 ? filp_flush+0x86/0xa0
 ? srso_return_thunk+0x5/0x5f
 ? filp_close+0x1f/0x30
 ? srso_return_thunk+0x5/0x5f
 ? do_dup2+0xaf/0x160
 ? srso_return_thunk+0x5/0x5f
 ksys_write+0x65/0xe0
 do_syscall_64+0x64/0x170
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

There is a potential race between __update_and_free_hugetlb_folio() and
replace_free_hugepage_folios():

CPU1                              CPU2
__update_and_free_hugetlb_folio   replace_free_hugepage_folios
                                    folio_test_hugetlb(folio)
                                    -- It's still hugetlb folio.

  __folio_clear_hugetlb(folio)
  hugetlb_free_folio(folio)
                                    h = folio_hstate(folio)
                                    -- Here, h is NULL pointer

When the above race condition occurs, folio_hstate(folio) returns NULL,
and subsequent access to this NULL pointer will cause the system to crash.
To resolve this issue, execute folio_hstate(folio) under the protection
of the hugetlb_lock lock, ensuring that folio_hstate(folio) does not
return NULL.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/113ed54ad276c352ee5ce109bdcf0df118a43bda; https://git.kernel.org/stable/c/e97283978a9848190d451f7038ac399613445f79
CVE: CVE-2025-38053
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

idpf: fix null-ptr-deref in idpf_features_check

idpf_features_check is used to validate the TX packet. skb header
length is compared with the hardware supported value received from
the device control plane. The value is stored in the adapter structure
and to access it, vport pointer is used. During reset all the vports
are released and the vport pointer that the netdev private structure
points to is NULL.

To avoid null-ptr-deref, store the max header length value in netdev
private structure. This also helps to cache the value and avoid
accessing adapter pointer in hot path.

BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
...
RIP: 0010:idpf_features_check+0x6d/0xe0 [idpf]
Call Trace:
 <TASK>
 ? __die+0x23/0x70
 ? page_fault_oops+0x154/0x520
 ? exc_page_fault+0x76/0x190
 ? asm_exc_page_fault+0x26/0x30
 ? idpf_features_check+0x6d/0xe0 [idpf]
 netif_skb_features+0x88/0x310
 validate_xmit_skb+0x2a/0x2b0
 validate_xmit_skb_list+0x4c/0x70
 sch_direct_xmit+0x19d/0x3a0
 __dev_queue_xmit+0xb74/0xe70
 ...
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2dabe349f7882ff1407a784d54d[PII_REDACTED]088; https://git.kernel.org/stable/c/bf1e751c5a5611aa037ab44cca955c141eb68dcc; https://git.kernel.org/stable/c/f6f5e9c8cb680c3cb9771fd9fa114319cbc4f514
CVE: CVE-2025-38054
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

ptp: ocp: Limit signal/freq counts in summary output functions

The debugfs summary output could access uninitialized elements in
the freq_in[] and signal_out[] arrays, causing NULL pointer
dereferences and triggering a kernel Oops (page_fault_oops).
This patch adds u8 fields (nr_freq_in, nr_signal_out) to track the
number of initialized elements, with a maximum of 4 per array.
The summary output functions are updated to respect these limits,
preventing out-of-bounds access and ensuring safe array handling.

Widen the label variables because the change confuses GCC about
max length of the strings.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/0b7d3e782027ac3b6fec56159e8e348042000aef; https://git.kernel.org/stable/c/c9e455581e2ba87ee38c126e8dc49a424b9df0cf; https://git.kernel.org/stable/c/fcad74f894ac89790084cc2e1ec61b08220941d1
CVE: CVE-2025-38055
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

perf/x86/intel: Fix segfault with PEBS-via-PT with sample_freq

Currently, using PEBS-via-PT with a sample frequency instead of a sample
period, causes a segfault.  For example:

    BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
    <NMI>
    ? __die_body.cold+0x19/0x27
    ? page_fault_oops+0xca/0x290
    ? exc_page_fault+0x7e/0x1b0
    ? asm_exc_page_fault+0x26/0x30
    ? intel_pmu_pebs_event_update_no_drain+0x40/0x60
    ? intel_pmu_pebs_event_update_no_drain+0x32/0x60
    intel_pmu_drain_pebs_icl+0x333/0x350
    handle_pmi_common+0x272/0x3c0
    intel_pmu_handle_irq+0x10a/0x2e0
    perf_event_nmi_handler+0x2a/0x50

That happens because intel_pmu_pebs_event_update_no_drain() assumes all the
pebs_enabled bits represent counter indexes, which is not always the case.
In this particular case, bits 60 and 61 are set for PEBS-via-PT purposes.

The behaviour of PEBS-via-PT with sample frequency is questionable because
although a PMI is generated (PEBS_PMI_AFTER_EACH_RECORD), the period is not
adjusted anyway.

Putting that aside, fix intel_pmu_pebs_event_update_no_drain() by passing
the mask of counter bits instead of 'size'.  Note, prior to the Fixes
commit, 'size' would be limited to the maximum counter index, so the issue
was not hit.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0b1874a5b1173fbcb2185ab828f4c33d067e551e; https://git.kernel.org/stable/c/99bcd91fabada0dbb1d5f0de44532d8008db93c6; https://git.kernel.org/stable/c/ca51db23166767a8445deb8331c9b8d5205d9287