In the Linux kernel, the following vulnerability has been resolved:
vsock: Do not allow binding to VMADDR_PORT_ANY
It is possible for a vsock to autobind to VMADDR_PORT_ANY. This can
cause a use-after-free when a connection is made to the bound socket.
The socket returned by accept() also has port VMADDR_PORT_ANY but is not
on the list of unbound sockets. Binding it will result in an extra
refcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keep
the binding until socket destruction).
Modify the check in __vsock_bind_connectible() to also prevent binding
to VMADDR_PORT_ANY.
In the Linux kernel, the following vulnerability has been resolved:
eventpoll: Fix semi-unbounded recursion
Ensure that epoll instances can never form a graph deeper than
EP_MAX_NESTS+1 links.
Currently, ep_loop_check_proc() ensures that the graph is loop-free and
does some recursion depth checks, but those recursion depth checks don't
limit the depth of the resulting tree for two reasons:
- They don't look upwards in the tree.
- If there are multiple downwards paths of different lengths, only one of
the paths is actually considered for the depth check since commit
28d82dc1c4ed ("epoll: limit paths").
Essentially, the current recursion depth check in ep_loop_check_proc() just
serves to prevent it from recursing too deeply while checking for loops.
A more thorough check is done in reverse_path_check() after the new graph
edge has already been created; this checks, among other things, that no
paths going upwards from any non-epoll file with a length of more than 5
edges exist. However, this check does not apply to non-epoll files.
As a result, it is possible to recurse to a depth of at least roughly 500,
tested on v6.15. (I am unsure if deeper recursion is possible; and this may
have changed with commit 8c44dac8add7 ("eventpoll: Fix priority inversion
problem").)
To fix it:
1. In ep_loop_check_proc(), note the subtree depth of each visited node,
and use subtree depths for the total depth calculation even when a subtree
has already been visited.
2. Add ep_get_upwards_depth_proc() for similarly determining the maximum
depth of an upwards walk.
3. In ep_loop_check(), use these values to limit the total path length
between epoll nodes to EP_MAX_NESTS edges.
In the Linux kernel, the following vulnerability has been resolved:
bpf, ktls: Fix data corruption when using bpf_msg_pop_data() in ktls
When sending plaintext data, we initially calculated the corresponding
ciphertext length. However, if we later reduced the plaintext data length
via socket policy, we failed to recalculate the ciphertext length.
This results in transmitting buffers containing uninitialized data during
ciphertext transmission.
This causes uninitialized bytes to be appended after a complete
"Application Data" packet, leading to errors on the receiving end when
parsing TLS record.
In the Linux kernel, the following vulnerability has been resolved:
staging: fbtft: fix potential memory leak in fbtft_framebuffer_alloc()
In the error paths after fb_info structure is successfully allocated,
the memory allocated in fb_deferred_io_init() for info->pagerefs is not
freed. Fix that by adding the cleanup function on the error path.
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: clear initialized flag for deinit-ed srng lists
In a number of cases we see kernel panics on resume due
to ath11k kernel page fault, which happens under the
following circumstances:
1) First ath11k_hal_dump_srng_stats() call
Last interrupt received for each group:
ath11k_pci 0000:01:00.0: group_id 0 22511ms before
ath11k_pci 0000:01:00.0: group_id 1 14440788ms before
[..]
ath11k_pci 0000:01:00.0: failed to receive control response completion, polling..
ath11k_pci 0000:01:00.0: Service connect timeout
ath11k_pci 0000:01:00.0: failed to connect to HTT: -110
ath11k_pci 0000:01:00.0: failed to start core: -110
ath11k_pci 0000:01:00.0: firmware crashed: MHI_CB_EE_RDDM
ath11k_pci 0000:01:00.0: already resetting count 2
ath11k_pci 0000:01:00.0: failed to wait wlan mode request (mode 4): -110
ath11k_pci 0000:01:00.0: qmi failed to send wlan mode off: -110
ath11k_pci 0000:01:00.0: failed to reconfigure driver on crash recovery
[..]
2) At this point reconfiguration fails (we have 2 resets) and
ath11k_core_reconfigure_on_crash() calls ath11k_hal_srng_deinit()
which destroys srng lists. However, it does not reset per-list
->initialized flag.
3) Second ath11k_hal_dump_srng_stats() call sees stale ->initialized
flag and attempts to dump srng stats:
Last interrupt received for each group:
ath11k_pci 0000:01:00.0: group_id 0 66785ms before
ath11k_pci 0000:01:00.0: group_id 1 14485062ms before
ath11k_pci 0000:01:00.0: group_id 2 14485062ms before
ath11k_pci 0000:01:00.0: group_id 3 14485062ms before
ath11k_pci 0000:01:00.0: group_id 4 14780845ms before
ath11k_pci 0000:01:00.0: group_id 5 14780845ms before
ath11k_pci 0000:01:00.0: group_id 6 14485062ms before
ath11k_pci 0000:01:00.0: group_id 7 66814ms before
ath11k_pci 0000:01:00.0: group_id 8 68997ms before
ath11k_pci 0000:01:00.0: group_id 9 67588ms before
ath11k_pci 0000:01:00.0: group_id 10 69511ms before
BUG: unable to handle page fault for address: ffffa007404eb010
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 100000067 P4D 100000067 PUD 10022d067 PMD 100b01067 PTE 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k]
Call Trace:
<TASK>
? __die_body+0xae/0xb0
? page_fault_oops+0x381/0x3e0
? exc_page_fault+0x69/0xa0
? asm_exc_page_fault+0x22/0x30
? ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k (HASH:6cea 4)]
ath11k_qmi_driver_event_work+0xbd/0x1050 [ath11k (HASH:6cea 4)]
worker_thread+0x389/0x930
kthread+0x149/0x170
Clear per-list ->initialized flag in ath11k_hal_srng_deinit().
In the Linux kernel, the following vulnerability has been resolved:
iwlwifi: Add missing check for alloc_ordered_workqueue
Add check for the return value of alloc_ordered_workqueue since it may
return NULL pointer.
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtl818x: Kill URBs before clearing tx status queue
In rtl8187_stop() move the call of usb_kill_anchored_urbs() before clearing
b_tx_status.queue. This change prevents callbacks from using already freed
skb due to anchor was not killed before freeing such skb.
BUG: kernel NULL pointer dereference, address: 0000000000000080
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Not tainted 6.15.0 #8 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
RIP: 0010:ieee80211_tx_status_irqsafe+0x21/0xc0 [mac80211]
Call Trace:
<IRQ>
rtl8187_tx_cb+0x116/0x150 [rtl8187]
__usb_hcd_giveback_urb+0x9d/0x120
usb_giveback_urb_bh+0xbb/0x140
process_one_work+0x19b/0x3c0
bh_worker+0x1a7/0x210
tasklet_action+0x10/0x30
handle_softirqs+0xf0/0x340
__irq_exit_rcu+0xcd/0xf0
common_interrupt+0x85/0xa0
</IRQ>
Tested on RTL8187BvE device.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
In the Linux kernel, the following vulnerability has been resolved:
xen: fix UAF in dmabuf_exp_from_pages()
[dma_buf_fd() fixes; no preferences regarding the tree it goes through -
up to xen folks]
As soon as we'd inserted a file reference into descriptor table, another
thread could close it. That's fine for the case when all we are doing is
returning that descriptor to userland (it's a race, but it's a userland
race and there's nothing the kernel can do about it). However, if we
follow fd_install() with any kind of access to objects that would be
destroyed on close (be it the struct file itself or anything destroyed
by its ->release()), we have a UAF.
dma_buf_fd() is a combination of reserving a descriptor and fd_install().
gntdev dmabuf_exp_from_pages() calls it and then proceeds to access the
objects destroyed on close - starting with gntdev_dmabuf itself.
Fix that by doing reserving descriptor before anything else and do
fd_install() only when everything had been set up.
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Remove skb secpath if xfrm state is not found
Hardware returns a unique identifier for a decrypted packet's xfrm
state, this state is looked up in an xarray. However, the state might
have been freed by the time of this lookup.
Currently, if the state is not found, only a counter is incremented.
The secpath (sp) extension on the skb is not removed, resulting in
sp->len becoming 0.
Subsequently, functions like __xfrm_policy_check() attempt to access
fields such as xfrm_input_state(skb)->xso.type (which dereferences
sp->xvec[sp->len - 1]) without first validating sp->len. This leads to
a crash when dereferencing an invalid state pointer.
This patch prevents the crash by explicitly removing the secpath
extension from the skb if the xfrm state is not found after hardware
decryption. This ensures downstream functions do not operate on a
zero-length secpath.
BUG: unable to handle page fault for address: ffffffff000002c8
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 282e067 P4D 282e067 PUD 0
Oops: Oops: 0000 [#1] SMP
CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NONE
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:__xfrm_policy_check+0x61a/0xa30
Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 <0f> b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa
RSP: 0018:ffff88885fb04918 EFLAGS: 00010297
RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000
RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000
RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353
R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8
R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00
FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<IRQ>
? try_to_wake_up+0x108/0x4c0
? udp4_lib_lookup2+0xbe/0x150
? udp_lib_lport_inuse+0x100/0x100
? __udp4_lib_lookup+0x2b0/0x410
__xfrm_policy_check2.constprop.0+0x11e/0x130
udp_queue_rcv_one_skb+0x1d/0x530
udp_unicast_rcv_skb+0x76/0x90
__udp4_lib_rcv+0xa64/0xe90
ip_protocol_deliver_rcu+0x20/0x130
ip_local_deliver_finish+0x75/0xa0
ip_local_deliver+0xc1/0xd0
? ip_protocol_deliver_rcu+0x130/0x130
ip_sublist_rcv+0x1f9/0x240
? ip_rcv_finish_core+0x430/0x430
ip_list_rcv+0xfc/0x130
__netif_receive_skb_list_core+0x181/0x1e0
netif_receive_skb_list_internal+0x200/0x360
? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core]
gro_receive_skb+0xfd/0x210
mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core]
mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core]
? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core]
mlx5e_napi_poll+0x114/0xab0 [mlx5_core]
__napi_poll+0x25/0x170
net_rx_action+0x32d/0x3a0
? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core]
? notifier_call_chain+0x33/0xa0
handle_softirqs+0xda/0x250
irq_exit_rcu+0x6d/0xc0
common_interrupt+0x81/0xa0
</IRQ>
In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject narrower access to pointer ctx fields
The following BPF program, simplified from a syzkaller repro, causes a
kernel warning:
r0 = *(u8 *)(r1 + 169);
exit;
With pointer field sk being at offset 168 in __sk_buff. This access is
detected as a narrower read in bpf_skb_is_valid_access because it
doesn't match offsetof(struct __sk_buff, sk). It is therefore allowed
and later proceeds to bpf_convert_ctx_access. Note that for the
"is_narrower_load" case in the convert_ctx_accesses(), the insn->off
is aligned, so the cnt may not be 0 because it matches the
offsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However,
the target_size stays 0 and the verifier errors with a kernel warning:
verifier bug: error during ctx access conversion(1)
This patch fixes that to return a proper "invalid bpf_context access
off=X size=Y" error on the load instruction.
The same issue affects multiple other fields in context structures that
allow narrow access. Some other non-affected fields (for sk_msg,
sk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr for
consistency.
Note this syzkaller crash was reported in the "Closes" link below, which
used to be about a different bug, fixed in
commit fce7bd8e385a ("bpf/verifier: Handle BPF_LOAD_ACQ instructions
in insn_def_regno()"). Because syzbot somehow confused the two bugs,
the new crash and repro didn't get reported to the mailing list.