In the Linux kernel, the following vulnerability has been resolved:
nvme-apple: Destroy the admin queue on removal
The admin queue is allocated with blk_mq_alloc_queue() but never
destroyed. nvme_free_ctrl() only drops the last reference and
blk_mq_exit_queue() and blk_sync_queue() never run: the hctx is never
moved to q->unused_hctx_list and the timeout timer and work stay armed on
a queue that is about to be freed which will eventually oops inside
blk_mq_timeout_work().
This can only be triggered when the controller fails to come up and is
then immediately torn down again which is why no one ever ran into this
before.
Let's just copy wh
nvmet: fix NULL pointer dereference in nvmet_execute_identify_ns_zns()
In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix NULL pointer dereference in nvmet_execute_identify_ns_zns()
When a host issues an Identify command with CNS 05h (I/O Command Set
specific Identify Namespace) and CSI 02h (ZNS) targeting a file-backed
namespace, nvmet_execute_identify_ns_zns() calls bdev_is_zoned() on
req->ns->bdev. A file-backed namespace has no block device, so
req->ns->bdev is NULL and bdev_is_zoned() dereferences it, oopsing.
The I/O command set is selected by the host-supplied CSI field and the
command is routed here whenever CONFIG_BLK_DEV_ZONED is enabled,
independent of the namespace back
nvme/ioctl: check SUBMIT_IO with nvme_cmd_allowed()
In the Linux kernel, the following vulnerability has been resolved:
nvme/ioctl: check SUBMIT_IO with nvme_cmd_allowed()
Unlike IO_CMD / IO64_CMD, NVME_IOCTL_SUBMIT_IO never calls
nvme_cmd_allowed(). Unprivileged callers can thus issue I/O on a
partition device or write through a read-only file descriptor.
Pass flags and open_for_write through and reject disallowed commands
with -EACCES.
nfc: llcp: avoid userspace overflow on invalid optlen
In the Linux kernel, the following vulnerability has been resolved:
nfc: llcp: avoid userspace overflow on invalid optlen
nfc_llcp_getsockopt() casts optval to (u32 __user *) for put_user(), so
the kernel always stores 4 bytes regardless of the caller-supplied
optlen. The existing min_t(u32, len, sizeof(u32)) only clamps the length
reported back to userspace; it does not constrain the store. A call with
optlen < 4 therefore writes past the user buffer, violating the
getsockopt(2) contract for all five supported optnames.
Reject any call with optlen < sizeof(u32) up front. 'len' is int, so a
plain size comparison would promote a negative op
nfc: llcp: read llcp_sock->local under the socket lock in getsockopt
In the Linux kernel, the following vulnerability has been resolved:
nfc: llcp: read llcp_sock->local under the socket lock in getsockopt
nfc_llcp_getsockopt() read llcp_sock->local before lock_sock(sk) and
then dereferenced the cached pointer inside the locked region.
llcp_sock_bind() assigns and clears llcp_sock->local under the same
socket lock, dropping the last reference on its error path. A
getsockopt() racing an in-flight bind() can observe the pointer, block
on lock_sock(), and then dereference a freed nfc_llcp_local once bind()
has unwound.
Move the llcp_sock->local read and the NULL check inside the
lock_sock(sk) region so bind()
nfc: nci: fix double completion race in nci_data_exchange_complete
In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: fix double completion race in nci_data_exchange_complete
nci_close_device() and nci_rx_work can both call
nci_data_exchange_complete() concurrently. After commit 4527025d440ce8
("nfc: nci: fix circular locking dependency in nci_close_device") moved
flush_workqueue(ndev->rx_wq) after mutex_unlock(&ndev->req_lock),
rx_work is no longer serialized with the explicit completion call in the
close path. Both callers read the non-NULL callback pointer and invoke
rawsock_data_exchange_complete(), which calls sock_put() -- but only one
sock_hold() was taken, so the second
nfc: llcp: bound SNL TLV parsing to the skb and add length checks
In the Linux kernel, the following vulnerability has been resolved:
nfc: llcp: bound SNL TLV parsing to the skb and add length checks
nfc_llcp_recv_snl() walked the SNL TLV list using a u16 offset/length
pair derived from skb->len, without bounding reads to the actual skb
data. Three problems followed:
- For a short frame (skb->len < LLCP_HEADER_SIZE), tlv_len underflowed.
- The per-TLV header (type, length) was read without checking that two
bytes remained.
- A declared TLV length could run past the end of the buffer, and an
SDREQ with length == 0 made "service_name_len = length - 1" underflow
(size_t), driving an out-of
nfc: pn533: hold a reference to the request skb during send_frame
In the Linux kernel, the following vulnerability has been resolved:
nfc: pn533: hold a reference to the request skb during send_frame
__pn533_send_async() publishes the command and then calls
dev->phy_ops->send_frame(). Once dev->cmd is set, an incoming frame
can be matched to this command: the I2C threaded IRQ runs
pn533_recv_frame(), which queues cmd_complete_work, and
pn533_send_async_complete() frees cmd->req with consume_skb().
On the I2C transport, pn533_i2c_send_frame() still dereferences the same
skb after i2c_master_send() returns, so a completion that races the
send can free the skb while the transport is still using it.
The req
nfc: nci: fix use of uninitialized memory in CORE_INIT_RSP parsing
In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: fix use of uninitialized memory in CORE_INIT_RSP parsing
nci_core_init_rsp_packet_v1() and nci_core_init_rsp_packet_v2() parse
the CORE_INIT_RSP packet without validating that the skb contains
enough data. A malformed response (e.g. injected via virtual_ncidev)
can declare a large num_supported_rf_interfaces while providing
insufficient data, causing reads of uninitialized slab memory. This
is later used in nci_init_complete_req(), triggering a KMSAN
uninit-value warning.
Add skb length checks before accessing packet fields:
- Validate the skb has at least 1 byte
ALSA: seq: Don't leak the extension cell pointer in the bounce payload
In the Linux kernel, the following vulnerability has been resolved:
ALSA: seq: Don't leak the extension cell pointer in the bounce payload
The bounce_error_event() embeds the failed event in the bounce payload
by pointing data.ext.ptr at it. When that event is a queued
variable-length event, its own data.ext.ptr holds the address of its
first extension cell, put there by snd_seq_event_dup(). The payload
goes out verbatim through snd_seq_expand_var_event(), so the address
reaches userspace.
That is the same address commit 705dd6dcbc0e ("ALSA: seq: Clear
variable event pointer on read") removed from the event header. The
read path still c
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cxgb4: Free debugfs on registration failure
c4iw_alloc() creates the per-device debugfs tree (dev->debugfs_root via
setup_debugfs()), but it is removed only in c4iw_remove(), not in
c4iw_dealloc(). When RDMA device registration fails, the registration
worker's err_dealloc_ctx path calls c4iw_dealloc() directly, bypassing
c4iw_remove(), so the debugfs dentries leak and outlive the freed
c4iw_dev.
Move debugfs_remove_recursive() into c4iw_dealloc() so every path that
frees ctx->dev also removes its debugfs tree.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cma: Fix WARNING in res_to_rt
syzbot reported a WARN_ON(!res->dev) in res_to_rt() triggered via
addr_handler() during asynchronous address resolution:
"
WARNING: drivers/infiniband/core/restrack.c:138 at res_to_rt+0x1c4/0x230
CPU#1: kworker/u8:4/59
Modules linked in:
CPU: 1 UID: 0 PID: 59 Comm: kworker/u8:4 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Compute Engine, BIOS Google 07/24/2026
Workqueue: ib_addr process_one_req
RIP: 0010:res_to_rt+0x1c4/0x230 drivers/infiniband/core/restrack.c:138
RSP: 0018:ffffc9000201f850 EFLAGS: 00010293
RAX: ffffffff88
In the Linux kernel, the following vulnerability has been resolved:
bpf: Compare iterator types during state pruning
An iterator stack slot can be MEM_RCU or PTR_UNTRUSTED. These states
must not be equal, or the verifier can prune an unsafe path.
Compare the pointer type for STACK_ITER slots.
In the Linux kernel, the following vulnerability has been resolved:
ubi: Fix rollback for explicit UBI device numbers
ubi_init_attach() rolls back module initialization failures by scanning
ubi_devices[0..i-1], where i is the mtd= parameter index. That assumes
the parameter index matches the UBI device number.
That assumption is not true when mtd= specifies an explicit ubi_num. A
successfully attached device can be stored at a higher ubi_devices[]
slot, and a later failure can miss it during rollback.
Scan the full ubi_devices[] array and detach by the actual array index,
matching the way UBI devices are stored.
In the Linux kernel, the following vulnerability has been resolved:
mtd: ubi: Release device reference on busy detach
ubi_detach_mtd_dev() obtains a device reference through ubi_get_device()
before checking whether the UBI device is busy. The busy return path drops
ubi->ref_count but leaves the device reference held, so the device object
cannot be released after a later detach.
Drop the device reference before returning -EBUSY.
ASoC: xilinx: formatter_pcm: fix stream_data leak on open error
In the Linux kernel, the following vulnerability has been resolved:
ASoC: xilinx: formatter_pcm: fix stream_data leak on open error
In xlnx_formatter_pcm_open(), stream_data is allocated and
adata->play_stream or adata->capture_stream is assigned early. If a
later step, such as snd_pcm_hw_constraint_step() or
snd_pcm_hw_constraint_integer(), fails, the function returns the error
immediately. ALSA does not call the close callback when open fails, so
stream_data is leaked and the stream pointer is left dangling, pointing
to a substream that ALSA frees. A later interrupt would then call
snd_pcm_period_elapsed() on the freed substream.
Free
firewire: core: fix memory leak in error path of build_tree()
In the Linux kernel, the following vulnerability has been resolved:
firewire: core: fix memory leak in error path of build_tree()
In the error path of build_tree(), node instances can remain in the local
linked list when the function returns.
Whenever an invalid value is detected in the self ID sequence, each
allocated node instance is either an entry in the linked list or an
entry in the ports array of its parent node. Therefore, the allocate
node instances can be safely released by traversing the linked list from
its head.
Release the remaining node instances with for_each_fw_node() before
returning to the caller.
arm64/efi: Avoid voluntary preemption with efi_mm installed
In the Linux kernel, the following vulnerability has been resolved:
arm64/efi: Avoid voluntary preemption with efi_mm installed
Gus reports a bad kernel memory access when using software PAN
(CONFIG_ARM64_SW_TTBR0_PAN=y) on a machine with support for EFI runtime
services:
Unable to handle kernel access to user memory outside uaccess routines
at virtual address 00000000f322ff30
Mem abort info:
ESR = 0x0000000096000004
FSC = 0x04: level 0 translation fault
Internal error: Oops: 0000000096000004 [#1] SMP
Workqueue: efi_rts_wq efi_call_rts
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : efi_call_rt
bpf, s390: Clear fetch destination on faulting arena atomic
In the Linux kernel, the following vulnerability has been resolved:
bpf, s390: Clear fetch destination on faulting arena atomic
Same missing register clear as on riscv64. A RMW atomic on an arena pointer
is converted to BPF_PROBE_ATOMIC and gets an exception table entry, but
bpf_jit_probe_atomic_pre() only fills in the arena base and the probe
offset, leaving probe->reg at the -1 that bpf_jit_probe_init() set, which
bpf_jit_probe_post() writes into the entry and ex_handler_bpf() then reads
back as "there is nothing to clear".
That is right for a plain BPF_{ADD,AND,OR,XOR}, which only writes memory,
but an RMW carrying BPF_FETCH also reads
In the Linux kernel, the following vulnerability has been resolved:
s390/debug: Fix deadlock during unregister
Unregistering an s390dbf debug area while one of the associated debugfs
files is being written to can cause a deadlock:
$ echo >.../vmur/level $ rmmod vmur
===================================================
debugfs write
debugfs_file_get()
debug_unregister()
mutex_lock(debug_mutex)
debugfs_remove()
wait for debugfs_file_put()
debug_file_ops.write()
debug_input()
mutex_lock(debug_mutex) ==> DEADLOCK
Fix this by splitting deb