| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
of/address: Fix NULL bus dereference in of_pci_range_parser_one()
The bus matching rework made of_match_bus() return NULL for nodes with
ranges/dma-ranges but no local #address-cells. parser_init() stored that
NULL bus, and the range iterator later dereferenced it.
Reject such nodes in parser_init(), leaving an explicit empty
iterator for callers that ignore the init return, and make
of_dma_get_max_cpu_address() honour the init failure so a rejected node
cannot clamp the DMA limit. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: reject DX_BIND_QUERY without a DX context
vmw_cmd_dx_bind_query() unconditionally dereferences
sw_context->dx_ctx_node->ctx. Userspace can trigger a NULL pointer
dereference from any render-node fd by submitting an execbuf with
dx_context_handle == SVGA3D_INVALID_ID and a SVGA_3D_CMD_DX_BIND_QUERY
opcode in the command stream: dx_ctx_node is left NULL and the kernel
oopses on the assignment. The same NULL is then re-read in
vmw_resources_reserve() via vmw_context_get_dx_query_mob().
All sibling DX handlers fail-close on a missing dx_ctx_node using
VMW_GET_CTX_NODE(). Use the same pattern here, returning -EINVAL up
front before any relocation state is published. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: avoid destroy_workqueue(NULL) on vkms init failure
Two paths through vmw_vkms_init() can leave vmw->crc_workq NULL while
still leaving the rest of the driver in a state that calls
vmw_vkms_cleanup() at module unload:
1. vmw_host_get_guestinfo(GUESTINFO_VBLANK, ...) failing or
returning an oversized buffer -- the common case on hosts
without a VBLANK guestinfo entry -- early-returned before the
workqueue allocation.
2. alloc_ordered_workqueue() returning NULL on memory pressure.
vmw_vkms_cleanup() then calls destroy_workqueue(NULL), which
dereferences wq->name and panics.
Fix the first case by removing the early return: vmw->vkms_enabled
is already false on the rpci-failure path so no work will ever be
queued, and allocating the workqueue unconditionally keeps the
control flow simple. Fix the second case by guarding the cleanup
with a NULL check, since alloc_ordered_workqueue() can still fail
under low memory. |
| In the Linux kernel, the following vulnerability has been resolved:
media: uvcvideo: Fix deadlock if uvc_status_stop is called from async_ctrl.work
If a UVC camera has an asynchronous control, uvc_status_stop may be
called from async_ctrl.work:
uvc_ctrl_status_event_work()
uvc_ctrl_status_event()
uvc_ctrl_clear_handle()
uvc_pm_put()
uvc_status_put()
uvc_status_stop()
cancel_work_sync()
This will cause a deadlock, since cancel_work_sync will wait for
uvc_ctrl_status_event_work to complete before returning.
Fix this by returning early from uvc_status_stop if we are currently in
the work function. flush_status now remains false until uvc_status_start
is called again, ensuring that uvc_ctrl_status_event_work won't resubmit
the URB. |
| In the Linux kernel, the following vulnerability has been resolved:
afs: fix NULL pointer dereference in afs_get_tree()
afs_alloc_sbi() uses kzalloc for memory allocation. And, if
ctx->dyn_root is not null, as->cell and as->volume are null.
In trace_afs_get_tree() they are dereferenced.
KASAN error message:
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 2 PID: 18478 Comm: syz-executor.7 Not tainted 5.10.246-syzkaller #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1
04/01/2014
RIP: 0010:perf_trace_afs_get_tree+0x1d9/0x550
include/trace/events/afs.h:1365
Call Trace:
trace_afs_get_tree include/trace/events/afs.h:1365 [inline]
afs_get_tree+0x922/0x1350 fs/afs/super.c:599
vfs_get_tree+0x8e/0x300 fs/super.c:1572
do_new_mount fs/namespace.c:3011 [inline]
path_mount+0x14a5/0x2220 fs/namespace.c:3341
do_mount fs/namespace.c:3354 [inline]
__do_sys_mount fs/namespace.c:3562 [inline]
__se_sys_mount fs/namespace.c:3539 [inline]
__x64_sys_mount+0x283/0x300 fs/namespace.c:3539
do_syscall_64+0x33/0x50 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x67/0xd1
Found by Linux Verification Center (linuxtesting.org) with Syzkaller. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/gpusvm: Reject VMAs with VM_IO or VM_PFNMAP when creating SVM ranges
VMAs marked with VM_IO or VM_PFNMAP are not backed by struct page
objects, which GPUSVM requires in order to operate correctly. In
particular, get_pages() relies on hmm_range_fault() to resolve struct
pages for the target range.
Attempting to create an SVM range on such VMAs results in repeated
get_pages() failures and can lead to an infinite loop inside a driver’s
page‑fault handler. Prevent this by rejecting ranges on VM_IO or
VM_PFNMAP VMAs and returning -EIO. |
| In the Linux kernel, the following vulnerability has been resolved:
hfsplus: Remove the duplicate attr inode dirty marking action
Syzbot reported a null-ptr-deref in [1].
If the attributes file is not loaded during system mount, a trigger
occurs [1] when setxattr is executed in userspace.
Remove the first mark attr inode dirty operation.
[1]
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
Call Trace:
hfsplus_setxattr+0x124/0x340 fs/hfsplus/xattr.c:555
hfsplus_trusted_setxattr+0x40/0x60 fs/hfsplus/xattr_trusted.c:30
__vfs_setxattr+0x43c/0x480 fs/xattr.c:218
__vfs_setxattr_noperm+0x12d/0x660 fs/xattr.c:252
vfs_setxattr+0x163/0x360 fs/xattr.c:339
do_setxattr fs/xattr.c:654 [inline] |
| In the Linux kernel, the following vulnerability has been resolved:
evm: terminate and bound the evm_xattrs read buffer
evm_read_xattrs() allocates size + 1 bytes, fills them from the list of
enabled xattrs, and then passes strlen(temp) to
simple_read_from_buffer(). When no configured xattrs are enabled, the
fill loop stores nothing and temp[0] remains uninitialized, so strlen()
reads beyond initialized memory.
Explicitly terminate the buffer after allocation, use snprintf() for
each formatted line, and pass the accumulated length, without risk of
truncation, to simple_read_from_buffer(). |
| In the Linux kernel, the following vulnerability has been resolved:
net/sched: cls_bpf: prevent unbounded recursion in offload rollback
Quan Sun reported [1] a stack overflow in cls_bpf_offload_cmd().
Reproducer on netdevsim: add a skip_sw cls_bpf filter, set the
bpf_tc_accept debugfs knob to 0, then `tc filter replace`. The replace
calls tc_setup_cb_replace() which fails. cls_bpf_offload_cmd() then
swaps prog/oldprog and recursively calls itself to roll back. But
bpf_tc_accept=0 makes the rollback fail too, which triggers yet another
rollback frame with the same arguments, and so on until the stack is
exhausted.
bpf_tc_accept is just a convenient knob for the reproducer. Any driver
whose tc_setup_cb_replace() fails twice in a row can hit the same loop,
so this is not a netdevsim-only issue.
Two ways to fix it:
1) Have the rollback call tc_setup_cb_add() on oldprog instead of
re-entering cls_bpf_offload_cmd().
2) Mark the rollback frame with a flag and skip a second-level
rollback from inside it.
Go with (2). It is the smaller change and keeps the original behaviour:
the rollback still goes through tc_setup_cb_replace(), so the driver
gets one real chance to restore its state. If that attempt also fails,
we just return the original error instead of recursing.
[1]: https://lore.kernel.org/bpf/ce5a6005-3c5e-4696-9e05-eba9461dc860@std.uestc.edu.cn/T/#u |
| In the Linux kernel, the following vulnerability has been resolved:
md/raid1,raid10: fix deadlock in read error recovery path
raid1d and raid10d may resubmit a split md cloned bio while handling
a read error. In this case, resubmitting the bio can lead to a deadlock
if the array is suspended before md_handle_request() acquires an
active_io reference via percpu_ref_tryget_live().
Since the cloned bio already holds an active_io reference,
trying to acquire another reference via percpu_ref_tryget_live()
can lead to a deadlock while the array is suspended.
Fix this by using percpu_ref_get() for md cloned bios. |
| In the Linux kernel, the following vulnerability has been resolved:
md/raid1,raid10: fix bio accounting for split md cloned bios
Use md_cloned_bio() to control bio accounting instead of relying
on r1bio_existed in raid1 or the io_accounting flag in raid10.
The previous logic does not reliably reflect whether a bio is an
md cloned bio. When a failed bio is split and resubmitted via
bio_submit_split_bioset() on the error path, this can lead to either
double accounting for md cloned bios, or missing accounting for bios
returned from bio_submit_split_bioset()
Fix this by using md_cloned_bio() to detect md cloned bios and
skip accounting accordingly. |
| In the Linux kernel, the following vulnerability has been resolved:
raid1: fix nr_pending leak in REQ_ATOMIC bad-block error path
In raid1_write_request(), each per-mirror loop iteration begins by
incrementing rdev->nr_pending. If a REQ_ATOMIC write encounters a
badblock within the requested range, the code jumps to err_handle
without dropping the reference taken for the current mirror.
err_handle's cleanup loop will only decrements for k < i and
r1_bio->bios[k] is non-NULL. The current slot is therefore skipped,
leaving its nr_pending reference leaked permanently. The reference
prevents the rdev from ever being removed, since raid1_remove_conf()
refuses to remove an rdev with nr_pending > 0.
Fix this by calling rdev_dec_pending() before jumping to err_handle. |
| In the Linux kernel, the following vulnerability has been resolved:
liveupdate: fix u-a-f in luo_file_unpreserve_files() and luo_file_finish()
In luo_file_unpreserve_files() and luo_file_finish(), reorder
module_put() and xa_erase() to ensure the file handler module remains
pinned while its operations are being accessed.
Specifically, luo_get_id() dereferences fh->ops->get_id, so the module
reference must be held until after xa_erase() (which calls luo_get_id)
completes.
For luo_file_finish(), this requires moving the module_put() call out of
the luo_file_finish_one() helper and into the main loop of
luo_file_finish() itself. |
| In the Linux kernel, the following vulnerability has been resolved:
ext2: fix ignored return value of generic_write_sync()
Fix ext2_dio_write_iter() to propagate the error returned by
generic_write_sync() instead of silently discarding it, which could
cause write(2) to return success to userspace on O_SYNC/O_DSYNC files
even when the sync failed.
The correct pattern, already used in ext2_dax_write_iter() in the same
file and in ext4, xfs, f2fs among others, is:
if (ret > 0)
ret = generic_write_sync(iocb, ret);
Found by Linux Verification Center (linuxtesting.org) with SVACE.
[JK: Reflect also filemap_write_and_wait() return value] |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: fix fast commit wait/wake bit mapping on 64-bit
On 64-bit, ext4 dynamic inode states live in the upper half of i_flags,
and ext4_test_inode_state() applies the corresponding +32 offset.
The fast-commit wait and wake paths open-coded the wait key with the raw
EXT4_STATE_* value. Add small helpers for the state wait word and bit,
and use them for the FC_COMMITTING and FC_FLUSHING_DATA waits so the wait
key follows the same mapping as the state helpers. |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: sm501fb: Fix buffer errors in OF binding code
The code that gets the frame buffer mode from OF has 'use after free',
'buffer overrun' and memory leaks.
info->edid_data isn't free if the probe functions fail or if
pd->def_mode is set.
If both the CRT and PANEL are enabled info->edid_data is used after
being freed and is freed twice.
The string returned by of_get_property(np, "mode", &len) is just
written over either the static "640x480-16@60" or the module parameter
string without any regard for the length (which is most likely longer).
Use kstrump() for the OF mode and free everything before freeing 'info. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: zoned: fix deadlock waiting for ticket during data relocation
When performing data relocation on a zoned filesystem, BTRFS can deadlock
in handle_reserve_tickets(). The relocation process is waiting on a space
reservation ticket that can never be fulfilled, because the relocation
itself is the operation responsible for freeing up that space.
Fix this by introducing a new flush state,
BTRFS_RESERVE_FLUSH_ZONED_RELOCATION, specifically for data chunk
allocation during zoned relocation. Like
BTRFS_RESERVE_FLUSH_FREE_SPACE_INODE, this state uses
priority_reclaim_data_space() instead of the normal flushing path, which
avoids re-entering the relocation code and breaking the deadlock cycle.
In btrfs_alloc_data_chunk_ondemand(), select this new flush state when the
inode belongs to a data relocation root on a zoned filesystem. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix deadlock cloning inline extent when using flushoncommit
In commit b48c980b6a7e ("btrfs: fix deadlock between reflink and
transaction commit when using flushoncommit") a deadlock was fixed
between reflinks and transaction commits when the fs is mounted with the
flushoncommit option. This happened when we had to copy an inline extent's
data to the destination file. However the issue was fixed only for the
case where the destination offset is 0, it missed the case when the offset
is greater than zero.
Fix this by ensuring we get i_size update whenever we copied an inline
extent's data into the destination file.
Syzbot reported this with the following trace:
INFO: task kworker/u8:3:57 blocked for more than 143 seconds.
Not tainted syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/u8:3 state:D stack:21600 pid:57 tgid:57 ppid:2 task_flags:0x4208160 flags:0x00080000
Workqueue: writeback wb_workfn (flush-btrfs-129)
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5402 [inline]
__schedule+0x16f9/0x5500 kernel/sched/core.c:7204
__schedule_loop kernel/sched/core.c:7283 [inline]
schedule+0x164/0x360 kernel/sched/core.c:7298
wait_extent_bit fs/btrfs/extent-io-tree.c:905 [inline]
btrfs_lock_extent_bits+0x59c/0x700 fs/btrfs/extent-io-tree.c:2008
btrfs_lock_extent fs/btrfs/extent-io-tree.h:152 [inline]
btrfs_invalidate_folio+0x440/0xc00 fs/btrfs/inode.c:7718
extent_writepage fs/btrfs/extent_io.c:1848 [inline]
extent_write_cache_pages fs/btrfs/extent_io.c:2552 [inline]
btrfs_writepages+0x12f3/0x2410 fs/btrfs/extent_io.c:2684
do_writepages+0x32e/0x550 mm/page-writeback.c:2571
__writeback_single_inode+0x133/0x10e0 fs/fs-writeback.c:1764
writeback_sb_inodes+0x97f/0x1980 fs/fs-writeback.c:2056
wb_writeback+0x445/0xb00 fs/fs-writeback.c:2241
wb_do_writeback fs/fs-writeback.c:2388 [inline]
wb_workfn+0x3fd/0xf20 fs/fs-writeback.c:2428
process_one_work+0x98b/0x1630 kernel/workqueue.c:3318
process_scheduled_works kernel/workqueue.c:3401 [inline]
worker_thread+0xb49/0x1140 kernel/workqueue.c:3482
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
INFO: task syz.0.145:8523 blocked for more than 143 seconds.
Not tainted syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz.0.145 state:D stack:22752 pid:8523 tgid:8522 ppid:5850 task_flags:0x400140 flags:0x00080002
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5402 [inline]
__schedule+0x16f9/0x5500 kernel/sched/core.c:7204
__schedule_loop kernel/sched/core.c:7283 [inline]
schedule+0x164/0x360 kernel/sched/core.c:7298
wb_wait_for_completion+0x3e8/0x790 fs/fs-writeback.c:227
__writeback_inodes_sb_nr+0x24c/0x2d0 fs/fs-writeback.c:2847
try_to_writeback_inodes_sb+0x9a/0xc0 fs/fs-writeback.c:2895
btrfs_start_delalloc_flush fs/btrfs/transaction.c:2182 [inline]
btrfs_commit_transaction+0x813/0x2fc0 fs/btrfs/transaction.c:2371
btrfs_sync_file+0xdf4/0x1230 fs/btrfs/file.c:1822
generic_write_sync include/linux/fs.h:2663 [inline]
btrfs_do_write_iter+0x6a9/0x840 fs/btrfs/file.c:1473
new_sync_write fs/read_write.c:595 [inline]
vfs_write+0x629/0xba0 fs/read_write.c:688
ksys_write+0x156/0x270 fs/read_write.c:740
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x15f/0x560 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f5a0bdece59
RSP: 002b:00007f5a0b446028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007f5a0c065fa0 RCX: 00007f5a0bdece59
RDX: 000000000000029f RSI: 0000200000
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btmtk: fix URB leak in alloc_mtk_intr_urb error path
When btmtk_isopkt_pad() fails, the previously allocated URB is not freed,
leaking the urb structure. Add usb_free_urb() before returning the error. |
| In the Linux kernel, the following vulnerability has been resolved:
spi: xilinx: use FIFO occupancy register to determine buffer size
The method the driver uses to determine the size of the FIFO has a
problem. What it currently does is this:
It stops the SPI hardware and writes to the TX FIFO register until TX
FIFO FULL asserts in the status register. But the hardware does not only
have the FIFO, it also has a shift register which can hold a byte. This
can be seen, when writing a byte to the FIFO (while the SPI hardware is
stopped,) the TX FIFO EMPTY is still empty. So, if we have a FIFO size
of 16 for example, the current method returns a 17.
This is a problem, at least when using the driver in irq mode. The same
size determined for the TX FIFO is also assumed for the RX FIFO. When a
SPI transaction wants to write the amount of the FIFO size or more
bytes, the following happens, for example with 16 bytes FIFO size:
The driver stops the SPI hardware and writes 17 bytes to the TX FIFO and
starts the SPI hardware and goes sleep.
The hardware then shifts out 17 bytes (FIFO + shift register) and
simultaneously reads bytes into the RX FIFO, but it only has 16 places,
so it looses one byte. Then TX FIFO empty asserts, wakes the driver
again, which has a fast path and reads 16 bytes from the RX FIFO, but
before reading the last 17th byte (which is lost) it does this:
sr = xspi->read_fn(xspi->regs + XSPI_SR_OFFSET);
if (!(sr & XSPI_SR_RX_EMPTY_MASK)) {
xilinx_spi_rx(xspi);
rx_words--;
}
It reads the status register and checks if the RX FIFO is not empty.
But it is empty in our case. So this check spins in a while loop
forever locking the driver.
This patch fixes the logic to determine the FIFO size. |
