deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-38154
Published: 2025-07-03
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf, sockmap: Avoid using sk_socket after free when sending

The sk->sk_socket is not locked or referenced in backlog thread, and
during the call to skb_send_sock(), there is a race condition with
the release of sk_socket. All types of sockets(tcp/udp/unix/vsock)
will be affected.

Race conditions:
'''
CPU0                               CPU1

backlog::skb_send_sock
  sendmsg_unlocked
    sock_sendmsg
      sock_sendmsg_nosec
                                   close(fd):
                                     ...
                                     ops->release() -> sock_map_close()
                                     sk_socket->ops = NULL
                                     free(socket)
      sock->ops->sendmsg
            ^
            panic here
'''

The ref of psock become 0 after sock_map_close() executed.
'''
void sock_map_close()
{
    ...
    if (likely(psock)) {
    ...
    // !! here we remove psock and the ref of psock become 0
    sock_map_remove_links(sk, psock)
    psock = sk_psock_get(sk);
    if (unlikely(!psock))
        goto no_psock; <=== Control jumps here via goto
        ...
        cancel_delayed_work_sync(&psock->work); <=== not executed
        sk_psock_put(sk, psock);
        ...
}
'''

Based on the fact that we already wait for the workqueue to finish in
sock_map_close() if psock is held, we simply increase the psock
reference count to avoid race conditions.

With this patch, if the backlog thread is running, sock_map_close() will
wait for the backlog thread to complete and cancel all pending work.

If no backlog running, any pending work that hasn't started by then will
fail when invoked by sk_psock_get(), as the psock reference count have
been zeroed, and sk_psock_drop() will cancel all jobs via
cancel_delayed_work_sync().

In summary, we require synchronization to coordinate the backlog thread
and close() thread.

The panic I catched:
'''
Workqueue: events sk_psock_backlog
RIP: 0010:sock_sendmsg+0x21d/0x440
RAX: [PII_REDACTED] RBX: ffffc9000521fad8 RCX: [PII_REDACTED]
...
Call Trace:
 <TASK>
 ? die_addr+0x40/0xa0
 ? exc_general_protection+0x14c/0x230
 ? asm_exc_general_protection+0x26/0x30
 ? sock_sendmsg+0x21d/0x440
 ? sock_sendmsg+0x3e0/0x440
 ? __pfx_sock_sendmsg+0x10/0x10
 __skb_send_sock+0x543/0xb70
 sk_psock_backlog+0x247/0xb80
...
'''
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/15c0250dae3b48a398447d2b364603821ed4ed90; https://git.kernel.org/stable/c/4c6fa65ab2aec7df94809478c8d28ef38676a1b7; https://git.kernel.org/stable/c/4edb40b05cb6a261775abfd8046804ca139a5546
CVE: CVE-2025-38155
Published: 2025-07-03
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7915: Fix null-ptr-deref in mt7915_mmio_wed_init()

devm_ioremap() returns NULL on error. Currently, mt7915_mmio_wed_init()
does not check for this case, which results in a NULL pointer
dereference.

Prevent null pointer dereference in mt7915_mmio_wed_init().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/790d05cde359356feea8915094a51166af1629f5; https://git.kernel.org/stable/c/d825ed9fd768be10d52beba6f57a4b50c0c154aa; https://git.kernel.org/stable/c/e9f9cef1877ac32285dbc1f31b86c8955b712fc2
CVE: CVE-2025-38156
Published: 2025-07-03
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7996: Fix null-ptr-deref in mt7996_mmio_wed_init()

devm_ioremap() returns NULL on error. Currently, mt7996_mmio_wed_init()
does not check for this case, which results in a NULL pointer
dereference.

Prevent null pointer dereference in mt7996_mmio_wed_init()
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1072fc0ca1f8d0d5397d[PII_REDACTED]6f937b8e63; https://git.kernel.org/stable/c/8f30e2b059757d8711a823e4c9c023db62a1d171; https://git.kernel.org/stable/c/af861c6dea2ef06845a5c7672999a06c06099735
CVE: CVE-2025-38157
Published: 2025-07-03
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath9k_htc: Abort software beacon handling if disabled

A malicious USB device can send a WMI_SWBA_EVENTID event from an
ath9k_htc-managed device before beaconing has been enabled. This causes
a device-by-zero error in the driver, leading to either a crash or an
out of bounds read.

Prevent this by aborting the handling in ath9k_htc_swba() if beacons are
not enabled.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/0281c19074976ec48f0078d50530b406ddae75bc; https://git.kernel.org/stable/c/40471b23147c86ea3ed97faee79937c618250bd0; https://git.kernel.org/stable/c/5482ef9875eaa43f0435e14570e1193823de857e
CVE: CVE-2025-38158
Published: 2025-07-03
Description: In the Linux kernel, the following vulnerability has been resolved:

hisi_acc_vfio_pci: fix XQE dma address error

The dma addresses of EQE and AEQE are wrong after migration and
results in guest kernel-mode encryption services  failure.
Comparing the definition of hardware registers, we found that
there was an error when the data read from the register was
combined into an address. Therefore, the address combination
sequence needs to be corrected.

Even after fixing the above problem, we still have an issue
where the Guest from an old kernel can get migrated to
new kernel and may result in wrong data.

In order to ensure that the address is correct after migration,
if an old magic number is detected, the dma address needs to be
updated.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/7710c883eb8cb5cf510ca47ec0e26c6cb7e94a4f; https://git.kernel.org/stable/c/809a9c10274e1bcf6d05f1c0341459a425a4f05f; https://git.kernel.org/stable/c/884a76e813178778d271fea59783763d32bb7e72
CVE: CVE-2025-38159
Published: 2025-07-03
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: rtw88: fix the 'para' buffer size to avoid reading out of bounds

Set the size to 6 instead of 2, since 'para' array is passed to
'rtw_fw_bt_wifi_control(rtwdev, para[0], &para[1])', which reads
5 bytes:

void rtw_fw_bt_wifi_control(struct rtw_dev *rtwdev, u8 op_code, u8 *data)
{
    ...
    SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, *data);
    SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, *(data + 1));
    ...
    SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4));

Detected using the static analysis tool - Svace.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/1ee8ea6937d13b20f90ff35d71ccc03ba448182d; https://git.kernel.org/stable/c/4c2c372de2e[PII_REDACTED]3cce6de44d70ae15cd; https://git.kernel.org/stable/c/68a1037f0bac4de9a585aa9c879ef886109f3647
CVE: CVE-2025-38160
Published: 2025-07-03
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: bcm: rpi: Add NULL check in raspberrypi_clk_register()

devm_kasprintf() returns NULL when memory allocation fails. Currently,
raspberrypi_clk_register() does not check for this case, which results
in a NULL pointer dereference.

Add NULL check after devm_kasprintf() to prevent this issue.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0a2712cd24ecfeb520af60f6f859b442c7ab01ff; https://git.kernel.org/stable/c/1b69a5299f28ce8e6afa37c3690dbc14c3a1f53f; https://git.kernel.org/stable/c/3c1adc2f8c732ea09e8c4bce5941fec019c6205d
CVE: CVE-2025-38162
Published: 2025-07-03
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nft_set_pipapo: prevent overflow in lookup table allocation

When calculating the lookup table size, ensure the following
multiplication does not overflow:

- desc->field_len[] maximum value is U8_MAX multiplied by
  NFT_PIPAPO_GROUPS_PER_BYTE(f) that can be 2, worst case.
- NFT_PIPAPO_BUCKETS(f->bb) is 2^8, worst case.
- sizeof(unsigned long), from sizeof(*f->lt), lt in
  struct nft_pipapo_field.

Then, use check_mul_overflow() to multiply by bucket size and then use
check_add_overflow() to the alignment for avx2 (if needed). Finally, add
lt_size_check_overflow() helper and use it to consolidate this.

While at it, replace leftover allocation using the GFP_KERNEL to
GFP_KERNEL_ACCOUNT for consistency, in pipapo_resize().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/43fe1181f[PII_REDACTED]96ae9ff611790edb65b5e; https://git.kernel.org/stable/c/4c5c6aa9967dbe55bd017bb509885928d0f31206; https://git.kernel.org/stable/c/91edc076439c9e2f34b176149f1c84a47a8ec32f
CVE: CVE-2025-38163
Published: 2025-07-03
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to do sanity check on sbi->total_valid_block_count

syzbot reported a f2fs bug as below:

------------[ cut here ]------------
kernel BUG at fs/f2fs/f2fs.h:2521!
RIP: 0010:dec_valid_block_count+0x3b2/0x3c0 fs/f2fs/f2fs.h:2521
Call Trace:
 f2fs_truncate_data_blocks_range+0xc8c/0x11a0 fs/f2fs/file.c:695
 truncate_dnode+0x417/0x740 fs/f2fs/node.c:973
 truncate_nodes+0x3ec/0xf50 fs/f2fs/node.c:1014
 f2fs_truncate_inode_blocks+0x8e3/0x1370 fs/f2fs/node.c:1197
 f2fs_do_truncate_blocks+0x840/0x12b0 fs/f2fs/file.c:810
 f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:838
 f2fs_truncate+0x417/0x720 fs/f2fs/file.c:888
 f2fs_setattr+0xc4f/0x12f0 fs/f2fs/file.c:1112
 notify_change+0xbca/0xe90 fs/attr.c:552
 do_truncate+0x222/0x310 fs/open.c:65
 handle_truncate fs/namei.c:3466 [inline]
 do_open fs/namei.c:3849 [inline]
 path_openat+0x2e4f/0x35d0 fs/namei.c:4004
 do_filp_open+0x284/0x4e0 fs/namei.c:4031
 do_sys_openat2+0x12b/0x1d0 fs/open.c:1429
 do_sys_open fs/open.c:1444 [inline]
 __do_sys_creat fs/open.c:1522 [inline]
 __se_sys_creat fs/open.c:1516 [inline]
 __x64_sys_creat+0x124/0x170 fs/open.c:1516
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/syscall_64.c:94

The reason is: in fuzzed image, sbi->total_valid_block_count is
inconsistent w/ mapped blocks indexed by inode, so, we should
not trigger panic for such case, instead, let's print log and
set fsck flag.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/05872a167c2cab80ef186ef23cc34a6776a1a30c; https://git.kernel.org/stable/c/25f3776b58c1c45ad2e50ab4b263505b4d2378ca; https://git.kernel.org/stable/c/49bc7bf38e42cfa642787e947f5721696ea73ac3
CVE: CVE-2025-38164
Published: 2025-07-03
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: zone: fix to avoid inconsistence in between SIT and SSA

w/ below testcase, it will cause inconsistence in between SIT and SSA.

create_null_blk 512 2 1024 1024
mkfs.f2fs -m /dev/nullb0
mount /dev/nullb0 /mnt/f2fs/
touch /mnt/f2fs/file
f2fs_io pinfile set /mnt/f2fs/file
fallocate -l 4GiB /mnt/f2fs/file

F2FS-fs (nullb0): Inconsistent segment (0) type [1, 0] in SSA and SIT
CPU: 5 UID: 0 PID: 2398 Comm: fallocate Tainted: G           O       6.13.0-rc1 #84
Tainted: [O]=OOT_MODULE
Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
Call Trace:
 <TASK>
 dump_stack_lvl+0xb3/0xd0
 dump_stack+0x14/0x20
 f2fs_handle_critical_error+0x18c/0x220 [f2fs]
 f2fs_stop_checkpoint+0x38/0x50 [f2fs]
 do_garbage_collect+0x674/0x6e0 [f2fs]
 f2fs_gc_range+0x12b/0x230 [f2fs]
 f2fs_allocate_pinning_section+0x5c/0x150 [f2fs]
 f2fs_expand_inode_data+0x1cc/0x3c0 [f2fs]
 f2fs_fallocate+0x3c3/0x410 [f2fs]
 vfs_fallocate+0x15f/0x4b0
 __x64_sys_fallocate+0x4a/0x80
 x64_sys_call+0x15e8/0x1b80
 do_syscall_64+0x68/0x130
 entry_SYSCALL_64_after_hwframe+0x67/0x6f
RIP: 0033:0x7f9dba5197ca
F2FS-fs (nullb0): Stopped filesystem due to reason: 4

The reason is f2fs_gc_range() may try to migrate block in curseg, however,
its SSA block is not uptodate due to the last summary block data is still
in cache of curseg.

In this patch, we add a condition in f2fs_gc_range() to check whether
section is opened or not, and skip block migration for opened section.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/44a51592ac657d8e422585414d7ec17a5b50fb0e; https://git.kernel.org/stable/c/773704c1ef96a8b70d0d186ab725f50548de82c4; https://git.kernel.org/stable/c/8d9431b0d11a5030aa1ce477defee455b3821701
CVE: CVE-2025-38165
Published: 2025-07-03
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf, sockmap: Fix panic when calling skb_linearize

The panic can be reproduced by executing the command:
./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress --rx-strp 100000

Then a kernel panic was captured:
'''
[  657.460555] kernel BUG at net/core/skbuff.c:2178!
[  657.462680] Tainted: [W]=WARN
[  657.463287] Workqueue: events sk_psock_backlog
...
[  657.469610]  <TASK>
[  657.469738]  ? die+0x36/0x90
[  657.469916]  ? do_trap+0x1d0/0x270
[  657.470118]  ? pskb_expand_head+0x612/0xf40
[  657.470376]  ? pskb_expand_head+0x612/0xf40
[  657.470620]  ? do_error_trap+0xa3/0x170
[  657.470846]  ? pskb_expand_head+0x612/0xf40
[  657.471092]  ? handle_invalid_op+0x2c/0x40
[  657.471335]  ? pskb_expand_head+0x612/0xf40
[  657.471579]  ? exc_invalid_op+0x2d/0x40
[  657.471805]  ? asm_exc_invalid_op+0x1a/0x20
[  657.472052]  ? pskb_expand_head+0xd1/0xf40
[  657.472292]  ? pskb_expand_head+0x612/0xf40
[  657.472540]  ? lock_acquire+0x18f/0x4e0
[  657.472766]  ? find_held_lock+0x2d/0x110
[  657.472999]  ? __pfx_pskb_expand_head+0x10/0x10
[  657.473263]  ? __kmalloc_cache_noprof+0x5b/0x470
[  657.473537]  ? __pfx___lock_release.isra.0+0x10/0x10
[  657.473826]  __pskb_pull_tail+0xfd/0x1d20
[  657.474062]  ? __kasan_slab_alloc+0x4e/0x90
[  657.474707]  sk_psock_skb_ingress_enqueue+0x3bf/0x510
[  657.475392]  ? __kasan_kmalloc+0xaa/0xb0
[  657.476010]  sk_psock_backlog+0x5cf/0xd70
[  657.476637]  process_one_work+0x858/0x1a20
'''

The panic originates from the assertion BUG_ON(skb_shared(skb)) in
skb_linearize(). A previous commit(see Fixes tag) introduced skb_get()
to avoid race conditions between skb operations in the backlog and skb
release in the recvmsg path. However, this caused the panic to always
occur when skb_linearize is executed.

The "--rx-strp 100000" parameter forces the RX path to use the strparser
module which aggregates data until it reaches 100KB before calling sockmap
logic. The 100KB payload exceeds MAX_MSG_FRAGS, triggering skb_linearize.

To fix this issue, just move skb_get into sk_psock_skb_ingress_enqueue.

'''
sk_psock_backlog:
    sk_psock_handle_skb
       skb_get(skb) <== we move it into 'sk_psock_skb_ingress_enqueue'
       sk_psock_skb_ingress____________
                                       ↓
                                       |
                                       | → sk_psock_skb_ingress_self
                                       |      sk_psock_skb_ingress_enqueue
sk_psock_verdict_apply_________________↑          skb_linearize
'''

Note that for verdict_apply path, the skb_get operation is unnecessary so
we add 'take_ref' param to control it's behavior.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/3d25fa2d7f127348c818e1dab9e58534f7ac56cc; https://git.kernel.org/stable/c/4dba44333a11522df54b49aa1f2edfaf6ce35fc7; https://git.kernel.org/stable/c/5ca2e29f6834c64c0e5a9ccf1278c21fb49b827e
CVE: CVE-2025-38167
Published: 2025-07-03
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: handle hdr_first_de() return value

The hdr_first_de() function returns a pointer to a struct NTFS_DE. This
pointer may be NULL. To handle the NULL error effectively, it is important
to implement an error handler. This will help manage potential errors
consistently.

Additionally, error handling for the return value already exists at other
points where this function is called.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2d5879f64554181b89f44d4817b9ea86e8e913e1; https://git.kernel.org/stable/c/4ecd0cde89feee26525ccdf1af0c1ae156ca010b; https://git.kernel.org/stable/c/5390b3d4c6d41d05bb9149d094d504cbc9ea85bf
CVE: CVE-2025-38168
Published: 2025-07-03
Description: In the Linux kernel, the following vulnerability has been resolved:

perf: arm-ni: Unregister PMUs on probe failure

When a resource allocation fails in one clock domain of an NI device,
we need to properly roll back all previously registered perf PMUs in
other clock domains of the same device.

Otherwise, it can lead to kernel panics.

Calling arm_ni_init+0x0/0xff8 [arm_ni] @ 2374
arm-ni ARMHCB70:00: Failed to request PMU region 0x1f3c13000
arm-ni ARMHCB70:00: probe with driver arm-ni failed with error -16
list_add corruption: next->prev should be prev (fffffd01e9698a18),
but was [PII_REDACTED]. (next=ffff10001a0decc8).
pstate: 6340009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
pc : list_add_valid_or_report+0x7c/0xb8
lr : list_add_valid_or_report+0x7c/0xb8
Call trace:
 __list_add_valid_or_report+0x7c/0xb8
 perf_pmu_register+0x22c/0x3a0
 arm_ni_probe+0x554/0x70c [arm_ni]
 platform_probe+0x70/0xe8
 really_probe+0xc6/0x4d8
 driver_probe_device+0x48/0x170
 __driver_attach+0x8e/0x1c0
 bus_for_each_dev+0x64/0xf0
 driver_add+0x138/0x260
 bus_add_driver+0x68/0x138
 __platform_driver_register+0x2c/0x40
 arm_ni_init+0x14/0x2a [arm_ni]
 do_init_module+0x36/0x298
---[ end trace [PII_REDACTED] ]---
Kernel panic - not syncing: Oops - BUG: Fatal exception
SMP: stopping secondary CPUs
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/72caf9886e9c1731cf7bfe3eabc308b9268b21d6; https://git.kernel.org/stable/c/7e958e116e3be05a1f869b5a885fc5d674c7725f; https://git.kernel.org/stable/c/7f57afde6a44d9e044885e1125034edd4fda02e8
CVE: CVE-2025-38169
Published: 2025-07-03
Description: In the Linux kernel, the following vulnerability has been resolved:

arm64/fpsimd: Avoid clobbering kernel FPSIMD state with SMSTOP

On system with SME, a thread's kernel FPSIMD state may be erroneously
clobbered during a context switch immediately after that state is
restored. Systems without SME are unaffected.

If the CPU happens to be in streaming SVE mode before a context switch
to a thread with kernel FPSIMD state, fpsimd_thread_switch() will
restore the kernel FPSIMD state using fpsimd_load_kernel_state() while
the CPU is still in streaming SVE mode. When fpsimd_thread_switch()
subsequently calls fpsimd_flush_cpu_state(), this will execute an
SMSTOP, causing an exit from streaming SVE mode. The exit from
streaming SVE mode will cause the hardware to reset a number of
FPSIMD/SVE/SME registers, clobbering the FPSIMD state.

Fix this by calling fpsimd_flush_cpu_state() before restoring the kernel
FPSIMD state.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/01098d893fa8a6edb2b56e178b798e3e6b674f02; https://git.kernel.org/stable/c/55d52af498daea75aa03ba9b7e444c8ae495ac20; https://git.kernel.org/stable/c/a305821f597ec943849d3e53924adb88c61ed682
CVE: CVE-2025-38170
Published: 2025-07-03
Description: In the Linux kernel, the following vulnerability has been resolved:

arm64/fpsimd: Discard stale CPU state when handling SME traps

The logic for handling SME traps manipulates saved FPSIMD/SVE/SME state
incorrectly, and a race with preemption can result in a task having
TIF_SME set and TIF_FOREIGN_FPSTATE clear even though the live CPU state
is stale (e.g. with SME traps enabled). This can result in warnings from
do_sme_acc() where SME traps are not expected while TIF_SME is set:

|        /* With TIF_SME userspace shouldn't generate any traps */
|        if (test_and_set_thread_flag(TIF_SME))
|                WARN_ON(1);

This is very similar to the SVE issue we fixed in commit:

  751ecf6afd6568ad ("arm64/sve: Discard stale CPU state when handling SVE traps")

The race can occur when the SME trap handler is preempted before and
after manipulating the saved FPSIMD/SVE/SME state, starting and ending on
the same CPU, e.g.

| void do_sme_acc(unsigned long esr, struct pt_regs *regs)
| {
|         // Trap on CPU 0 with TIF_SME clear, SME traps enabled
|         // task->fpsimd_cpu is 0.
|         // per_cpu_ptr(&fpsimd_last_state, 0) is task.
|
|         ...
|
|         // Preempted; migrated from CPU 0 to CPU 1.
|         // TIF_FOREIGN_FPSTATE is set.
|
|         get_cpu_fpsimd_context();
|
|         /* With TIF_SME userspace shouldn't generate any traps */
|         if (test_and_set_thread_flag(TIF_SME))
|                 WARN_ON(1);
|
|         if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {
|                 unsigned long vq_minus_one =
|                         sve_vq_from_vl(task_get_sme_vl(current)) - 1;
|                 sme_set_vq(vq_minus_one);
|
|                 fpsimd_bind_task_to_cpu();
|         }
|
|         put_cpu_fpsimd_context();
|
|         // Preempted; migrated from CPU 1 to CPU 0.
|         // task->fpsimd_cpu is still 0
|         // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then:
|         // - Stale HW state is reused (with SME traps enabled)
|         // - TIF_FOREIGN_FPSTATE is cleared
|         // - A return to userspace skips HW state restore
| }

Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set
by calling fpsimd_flush_task_state() to detach from the saved CPU
state. This ensures that a subsequent context switch will not reuse the
stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the
new state to be reloaded from memory prior to a return to userspace.

Note: this was originallly posted as [1].

[ Rutland: rewrite commit message ]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/43be952e885476dafb74aa832c0847b2f4f650c6; https://git.kernel.org/stable/c/6103f9ba51a59afb5a0f32299c837377c5a5a693; https://git.kernel.org/stable/c/c4a4786d93e99517d6f10ed56b9ffba4ce88d3b3
CVE: CVE-2025-38171
Published: 2025-07-03
Description: In the Linux kernel, the following vulnerability has been resolved:

power: supply: max77705: Fix workqueue error handling in probe

The create_singlethread_workqueue() doesn't return error pointers, it
returns NULL.  Also cleanup the workqueue on the error paths.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/11741b8e382d34b13277497ab91123d8b0b5c2db; https://git.kernel.org/stable/c/7f16be2b2927fdcfe40b596b7411c46d23a82034
CVE: CVE-2025-38172
Published: 2025-07-03
Description: In the Linux kernel, the following vulnerability has been resolved:

erofs: avoid using multiple devices with different type

For multiple devices, both primary and extra devices should be the
same type. `erofs_init_device` has already guaranteed that if the
primary is a file-backed device, extra devices should also be
regular files.

However, if the primary is a block device while the extra device
is a file-backed device, `erofs_init_device` will get an ENOTBLK,
which is not treated as an error in `erofs_fc_get_tree`, and that
leads to an UAF:

  erofs_fc_get_tree
    get_tree_bdev_flags(erofs_fc_fill_super)
      erofs_read_superblock
        erofs_init_device  // sbi->dif0 is not inited yet,
                           // return -ENOTBLK
      deactivate_locked_super
        free(sbi)
    if (err is -ENOTBLK)
      sbi->dif0.file = filp_open()  // sbi UAF

So if -ENOTBLK is hitted in `erofs_init_device`, it means the
primary device must be a block device, and the extra device
is not a block device. The error can be converted to -EINVAL.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/65115472f741ca000d7ea4a5922214f93cd1516e; https://git.kernel.org/stable/c/9748f2f54f66743ac77275c34886a9f890e18409; https://git.kernel.org/stable/c/cd04beb9ce2773a16057248bb4fa424068ae3807
CVE: CVE-2025-38173
Published: 2025-07-03
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: marvell/cesa - Handle zero-length skcipher requests

Do not access random memory for zero-length skcipher requests.
Just return 0.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/32d3e8049a8b60f18c5c39f5931bfb1130ac11c9; https://git.kernel.org/stable/c/5e9666ac8b94c978690f937d59170c5237bd2c45; https://git.kernel.org/stable/c/7894694b5d5b2ecfd7fb081d6f60b9e169ab4d13