Linux: >> Linux Kernel >> 6.18.11 Security Vulnerabilities
In the Linux kernel, the following vulnerability has been resolved:
crypto: atmel-tdes - fix DMA sync direction
Before DMA output is consumed by the CPU, ->dma_addr_out must be synced
with dma_sync_single_for_cpu() instead of dma_sync_single_for_device().
Using the wrong direction can return stale cache data on non-coherent
platforms.
CVSS Score
5.5
EPSS Score
0.001
Published
2026-05-27
In the Linux kernel, the following vulnerability has been resolved:
erofs: fix the out-of-bounds nameoff handling for trailing dirents
Currently we already have boundary-checks for nameoffs, but the trailing
dirents are special since the namelens are calculated with strnlen()
with unchecked nameoffs.
If a crafted EROFS has a trailing dirent with nameoff >= maxsize,
maxsize - nameoff can underflow, causing strnlen() to read past the
directory block.
nameoff0 should also be verified to be a multiple of
`sizeof(struct erofs_dirent)` as well [1].
[1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com
CVSS Score
7.1
EPSS Score
0.001
Published
2026-05-27
In the Linux kernel, the following vulnerability has been resolved:
rbd: fix null-ptr-deref when device_add_disk() fails
do_rbd_add() publishes the device with device_add() before calling
device_add_disk(). If device_add_disk() fails after device_add()
succeeds, the error path calls rbd_free_disk() directly and then later
falls through to rbd_dev_device_release(), which calls rbd_free_disk()
again. This double teardown can leave blk-mq cleanup operating on
invalid state and trigger a null-ptr-deref in
__blk_mq_free_map_and_rqs(), reached from blk_mq_free_tag_set().
Fix this by following the normal remove ordering: call device_del()
before rbd_dev_device_release() when device_add_disk() fails after
device_add(). That keeps the teardown sequence consistent and avoids
re-entering disk cleanup through the wrong path.
The bug was first flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while analyzing
v6.13-rc1. The tool is still under development and is not yet publicly
available.
We reproduced the bug on v7.0 with a real Ceph backend and a QEMU x86_64
guest booted with KASAN and CONFIG_FAILSLAB enabled. The reproducer
confines failslab injections to the __add_disk() range and injects
fail-nth while mapping an RBD image through
/sys/bus/rbd/add_single_major.
On the unpatched kernel, fail-nth=4 reliably triggered the fault:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 0 UID: 0 PID: 273 Comm: bash Not tainted 7.0.0-01247-gd60bc1401583 #6 PREEMPT(lazy)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
RIP: 0010:__blk_mq_free_map_and_rqs+0x8c/0x240
Code: 00 00 48 8b 6b 60 41 89 f4 49 c1 e4 03 4c 01 e5 45 85 ed 0f 85 0a 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 e9 48 c1 e9 03 <80> 3c 01 00 0f 85 31 01 00 00 4c 8b 6d 00 4d 85 ed 0f 84 e2 00 00
RSP: 0018:ff1100000ab0fac8 EFLAGS: 00000246
RAX: dffffc0000000000 RBX: ff1100000c4806a0 RCX: 0000000000000000
RDX: 0000000000000002 RSI: 0000000000000000 RDI: ff1100000c4806f4
RBP: 0000000000000000 R08: 0000000000000001 R09: ffe21c000189001b
R10: ff1100000c4800df R11: ff1100006cf37be0 R12: 0000000000000000
R13: 0000000000000000 R14: ff1100000c480700 R15: ff1100000c480004
FS: 00007f0fbe8fe740(0000) GS:ff110000e5851000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe53473b2e0 CR3: 0000000012eef000 CR4: 00000000007516f0
PKRU: 55555554
Call Trace:
<TASK>
blk_mq_free_tag_set+0x77/0x460
do_rbd_add+0x1446/0x2b80
? __pfx_do_rbd_add+0x10/0x10
? lock_acquire+0x18c/0x300
? find_held_lock+0x2b/0x80
? sysfs_file_kobj+0xb6/0x1b0
? __pfx_sysfs_kf_write+0x10/0x10
kernfs_fop_write_iter+0x2f4/0x4a0
vfs_write+0x98e/0x1000
? expand_files+0x51f/0x850
? __pfx_vfs_write+0x10/0x10
ksys_write+0xf2/0x1d0
? __pfx_ksys_write+0x10/0x10
do_syscall_64+0x115/0x690
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f0fbea15907
Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
RSP: 002b:00007ffe22346ea8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000058 RCX: 00007f0fbea15907
RDX: 0000000000000058 RSI: 0000563ace6c0ef0 RDI: 0000000000000001
RBP: 0000563ace6c0ef0 R08: 0000563ace6c0ef0 R09: 6b6435726d694141
R10: 5250337279762f78 R11: 0000000000000246 R12: 0000000000000058
R13: 00007f0fbeb1c780 R14: ff1100000c480700 R15: ff1100000c480004
</TASK>
With this fix applied, rerunning the reproducer over fail-nth=1..256
yields no KASAN reports.
[ idryomov: rename err_out_device_del -> err_out_device ]
CVSS Score
5.5
EPSS Score
0.001
Published
2026-05-27
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: split transactions in dio completion to avoid credit exhaustion
During ocfs2 dio operations, JBD2 may report warnings via following
call trace:
ocfs2_dio_end_io_write
ocfs2_mark_extent_written
ocfs2_change_extent_flag
ocfs2_split_extent
ocfs2_try_to_merge_extent
ocfs2_extend_rotate_transaction
ocfs2_extend_trans
jbd2__journal_restart
start_this_handle
output: JBD2: kworker/6:2 wants too many credits credits:5450 rsv_credits:0 max:5449
To prevent exceeding the credits limit, modify ocfs2_dio_end_io_write() to
handle extents in a batch of transaction.
Additionally, relocate ocfs2_del_inode_from_orphan(). The orphan inode
should only be removed from the orphan list after the extent tree update
is complete. This ensures that if a crash occurs in the middle of extent
tree updates, we won't leave stale blocks beyond EOF.
This patch also changes the logic for updating the inode size and removing
orphan, making it similar to ext4_dio_write_end_io(). Both operations are
performed only when everything looks good.
Finally, thanks to Jans and Joseph for providing the bug fix prototype and
suggestions.
CVSS Score
5.5
EPSS Score
0.001
Published
2026-05-27
In the Linux kernel, the following vulnerability has been resolved:
crypto: acomp - fix wrong pointer stored by acomp_save_req()
acomp_save_req() stores &req->chain in req->base.data. When
acomp_reqchain_done() is invoked on asynchronous completion, it receives
&req->chain as the data argument but casts it directly to struct
acomp_req. Since data points to the chain member, all subsequent field
accesses are at a wrong offset, resulting in memory corruption.
The issue occurs when an asynchronous hardware implementation, such as
the QAT driver, completes a request that uses the DMA virtual address
interface (e.g. acomp_request_set_src_dma()). This combination causes
crypto_acomp_compress() to enter the acomp_do_req_chain() path, which
sets acomp_reqchain_done() as the completion callback via
acomp_save_req().
With KASAN enabled, this manifests as a general protection fault in
acomp_reqchain_done():
general protection fault, probably for non-canonical address 0xe000040000000000
KASAN: probably user-memory-access in range [0x0000400000000000-0x0000400000000007]
RIP: 0010:acomp_reqchain_done+0x15b/0x4e0
Call Trace:
<IRQ>
qat_comp_alg_callback+0x5d/0xa0 [intel_qat]
adf_ring_response_handler+0x376/0x8b0 [intel_qat]
adf_response_handler+0x60/0x170 [intel_qat]
tasklet_action_common+0x223/0x820
handle_softirqs+0x1ab/0x640
</IRQ>
Fix this by storing the request itself in req->base.data instead of
&req->chain, so that acomp_reqchain_done() receives the correct pointer.
Simplify acomp_restore_req() accordingly to access req->chain directly.
CVSS Score
7.8
EPSS Score
0.002
Published
2026-05-27
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0
INVLPGA should cause a #UD when EFER.SVME is not set. Add a check to
properly inject #UD when EFER.SVME=0.
[sean: tag for stable@]
CVSS Score
5.5
EPSS Score
0.001
Published
2026-05-27
In the Linux kernel, the following vulnerability has been resolved:
spi: fix resource leaks on device setup failure
Make sure to call controller cleanup() if spi_setup() fails while
registering a device to avoid leaking any resources allocated by
setup().
CVSS Score
5.5
EPSS Score
0.001
Published
2026-05-27
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mana_ib: Disable RX steering on RSS QP destroy
When an RSS QP is destroyed (e.g. DPDK exit), mana_ib_destroy_qp_rss()
destroys the RX WQ objects but does not disable vPort RX steering in
firmware. This leaves stale steering configuration that still points to
the destroyed RX objects.
If traffic continues to arrive (e.g. peer VM is still transmitting) and
the VF interface is subsequently brought up (mana_open), the firmware
may deliver completions using stale CQ IDs from the old RX objects.
These CQ IDs can be reused by the ethernet driver for new TX CQs,
causing RX completions to land on TX CQs:
WARNING: mana_poll_tx_cq+0x1b8/0x220 [mana] (is_sq == false)
WARNING: mana_gd_process_eq_events+0x209/0x290 (cq_table lookup fails)
Fix this by disabling vPort RX steering before destroying RX WQ objects.
Note that mana_fence_rqs() cannot be used here because the fence
completion is delivered on the CQ, which is polled by user-mode (e.g.
DPDK) and not visible to the kernel driver.
Refactor the disable logic into a shared mana_disable_vport_rx() in
mana_en, exported for use by mana_ib, replacing the duplicate code.
The ethernet driver's mana_dealloc_queues() is also updated to call
this common function.
CVSS Score
7.8
EPSS Score
0.001
Published
2026-05-27
In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: fix use-after-free in mwifiex_adapter_cleanup()
The mwifiex_adapter_cleanup() function uses timer_delete()
(non-synchronous) for the wakeup_timer before the adapter structure is
freed. This is incorrect because timer_delete() does not wait for any
running timer callback to complete.
If the wakeup_timer callback (wakeup_timer_fn) is executing when
mwifiex_adapter_cleanup() is called, the callback will continue to
access adapter fields (adapter->hw_status, adapter->if_ops.card_reset,
etc.) which may be freed by mwifiex_free_adapter() called later in the
mwifiex_remove_card() path.
Use timer_delete_sync() instead to ensure any running timer callback has
completed before returning.
CVSS Score
7.8
EPSS Score
0.001
Published
2026-05-27
In the Linux kernel, the following vulnerability has been resolved:
md/raid5: validate payload size before accessing journal metadata
r5c_recovery_analyze_meta_block() and
r5l_recovery_verify_data_checksum_for_mb() iterate over payloads in a
journal metadata block using on-disk payload size fields without
validating them against the remaining space in the metadata block.
A corrupted journal contains payload sizes extending beyond the PAGE_SIZE
boundary can cause out-of-bounds reads when accessing payload fields or
computing offsets.
Add bounds validation for each payload type to ensure the full payload
fits within meta_size before processing.
CVSS Score
7.1
EPSS Score
0.001
Published
2026-05-27