| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
Input: synaptics-rmi4 - block s_input when F54 queue is busy
Changing the input (diagnostic report type) mid-stream changes the
report size. Since V4L2 buffers are allocated based on the size at
stream start, changing the input while streaming could lead to a
heap buffer overflow if the new size is larger than the allocated
buffers.
Prevent this by blocking VIDIOC_S_INPUT with -EBUSY if the V4L2 queue
is busy (streaming). |
| In the Linux kernel, the following vulnerability has been resolved:
libceph: fix multiple unsafe decodes in decode_locker()
decode_locker() in cls_lock_client.c contains three unsafe decode
operations that allow a malicious or compromised OSD to trigger
slab-out-of-bounds reads:
1. ceph_decode_copy() at the locker_id_t name field has no preceding
bounds check. With p == end after ceph_start_decoding() accepts
struct_len=0, this reads sizeof(ceph_entity_name) = 9 bytes past
the validated buffer boundary.
2. *p += sizeof(struct ceph_timespec) after the locker_info_t header
is an unchecked pointer advance. A malicious OSD can position p
past end, causing all subsequent _safe checks to pass against a
bogus boundary.
3. len = ceph_decode_32(p) has no preceding bounds check, and the
immediately following *p += len is uncapped. A malicious OSD can
send len=0xffffffff, advancing p gigabytes past end and escaping
the decode window entirely.
Fix all three by replacing bare operations with their safe variants:
ceph_decode_copy -> ceph_decode_copy_safe
*p += sizeof(...) -> ceph_decode_skip_n
ceph_decode_32(p) -> ceph_decode_32_safe
*p += len -> ceph_decode_skip_n
A new label is added to return -EINVAL on any bounds violation.
-EINVAL is appropriate here: the data received from the OSD
is structurally malformed, which is an invalid argument to the decode
contract regardless of whether the caller or the wire is at fault.
Attacker model: a malicious or compromised OSD in a multi-tenant Ceph
deployment can trigger this against any kernel client that issues the
lock.get_info class method (e.g. during RBD exclusive lock acquisition)
without any further privileges beyond OSD session establishment.
[ idryomov: use ceph_decode_skip_string() to skip description, trim
changelog ] |
| In the Linux kernel, the following vulnerability has been resolved:
openrisc: signal: do not restore privileged SR bits on sigreturn
restore_sigcontext() copies the whole supervision register (SR) from the
signal frame and only clears SPR_SR_SM before the value is reloaded into
the hardware SR (through ESR and l.rfe) on the return to user space. All
other SR bits are left under user control.
An unprivileged task can thus return from a signal handler through a
crafted sigframe that clears SPR_SR_DME. With the data MMU disabled the
CPU performs no translation or protection on data accesses, so the task
gains read and write access to arbitrary physical memory, a local
privilege escalation. SPR_SR_IME, SPR_SR_SUMRA, SPR_SR_LEE, SPR_SR_EPH
and the cache-enable bits are exposed the same way. The ptrace GPR regset
already refuses any change to SR for exactly this reason.
Restore only the arithmetic flag bits (F, CY, OV) from the signal frame
and take every privileged control bit from the SR the kernel saved on
signal entry.
Verified with qemu-system-or1k -M or1k-sim: before this change an
unprivileged PoC clears SPR_SR_DME in rt_sigreturn and writes a marker to
physical address 0x03000000 (beyond the kernel's mem=32M); afterwards the
same PoC receives SIGSEGV and physical memory is unchanged. |
| In the Linux kernel, the following vulnerability has been resolved:
libceph: Avoid using invalid osd indices from primary_temp
A corrupted osdmap received from a Ceph monitor or OSD may contain osd
indices in its pg_temp, primary_temp, pg_upmap, and pg_upmap_items parts
that don't exist, i.e., that are greater than max_osd or smaller than
CEPH_HOMELESS_OSD (-1). These indices are used to create the up and
acting set in ceph_pg_to_up_acting_osds(), called from calc_target().
While most of these osd indices are checked, the one from primary_temp
is not. Subsequently, this may lead to calc_target() returning this
(potentially invalid) index as target osd for a (linger) request.
Because the osd_state, osd_weight, and osd_addr arrays only contain
max_osd entries (with indices 0 to max_osd -1), this leads to
out-of-bounds accesses when trying to read values from these arrays.
This patch fixes the issue by adding a check to get_temp_osds(), so that
only valid osd indices from primary_temp are used, and it falls back to
using the primary from pg_temp or the up set if it is invalid.
[ idryomov: changelog ] |
| In the Linux kernel, the following vulnerability has been resolved:
s390/vfio_ccw: Fix out of bounds check on CCW array
The routine ccwchain_calc_length() counts the number of channel
command words (CCWs) that are chained together in a single channel
program, and rejects anything larger than CCWCHAIN_LEN_MAX (256) CCWs.
The loop itself is "do..while (count < 257)", and while the logic in
is_cpa_within_range() correctly adjusts between the 0-index array of
CCWs and the count of CCWs starting at 1, this means it would look
at a possible 257th CCW before ending the loop and (correctly)
returning an error.
Fix this by restructuring the loop to break as soon as 256 CCWs
(thus indexes 0-255) are examined, without looking at memory
outside the range. |
| In the Linux kernel, the following vulnerability has been resolved:
xfs: propagate errors from xfs_rtginode_load
xfs_rtginode_ensure() treats every xfs_rtginode_load() error other than
-ENOENT as success. This can leave the realtime group inode unset after an
I/O, allocation, or corruption error. Growfs then continues as though the
inode had been loaded.
Only -ENOENT means that the inode needs to be created. Return all other
errors to the growfs caller. |
| In the Linux kernel, the following vulnerability has been resolved:
xfs: fix off-by-one in rtrefcount btree root level validation
xfs_rtrefcountbt_compute_maxlevels() sets
mp->m_rtrefc_maxlevels = min(d_maxlevels, r_maxlevels) + 1;
where the trailing "+ 1" already accounts for the inode-root level, so the
deepest valid on-disk root level is m_rtrefc_maxlevels - 1 and a cursor must
satisfy bc_nlevels <= bc_maxlevels (= m_rtrefc_maxlevels).
The two on-disk validation paths, xfs_rtrefcountbt_verify() and
xfs_iformat_rtrefcount(), check the root level with ">" instead of ">=", so a
crafted rtreflink (metadir + realtime + reflink) image whose
/rtgroups/N.refcount inode has bb_level == m_rtrefc_maxlevels is accepted on
mount. xfs_rtrefcountbt_init_cursor() then sets bc_nlevels = bb_level + 1,
exceeding bc_maxlevels by one. Since the xfs_rtrefcountbt_cur slab object is
sized for exactly bc_maxlevels entries, the first btree op on such a cursor
indexes bc_levels[m_rtrefc_maxlevels] past the end of the object. This is
reached by the first rtrefcount cursor built after mount, via log/CoW
recovery (xfs_reflink_recover_cow() during xfs_mountfs()) or an
FS_IOC_GETFSMAP over the realtime device.
Reject a root level equal to m_rtrefc_maxlevels, matching the ">=" form
already used by the sibling data-device refcount/rmap verifiers and the
in-memory rtrmap verifier.
BUG: KASAN: slab-out-of-bounds in xfs_btree_lookup (fs/xfs/libxfs/xfs_btree.c:2101)
Write of size 2 at addr ffff888018391658 by task exploit/144
xfs_btree_lookup (fs/xfs/libxfs/xfs_btree.c:2101)
xfs_btree_query_range (fs/xfs/libxfs/xfs_btree.c:5308)
xfs_refcount_recover_cow_leftovers (fs/xfs/libxfs/xfs_refcount.c:2113)
xfs_reflink_recover_cow (fs/xfs/xfs_reflink.c:1085)
xlog_recover_finish (fs/xfs/xfs_log_recover.c:3551)
xfs_mountfs (fs/xfs/xfs_mount.c:1158)
xfs_fs_fill_super (fs/xfs/xfs_super.c:1940)
get_tree_bdev_flags (fs/super.c:1634)
vfs_get_tree (fs/super.c:1694)
path_mount (fs/namespace.c:4161)
__x64_sys_mount (fs/namespace.c:4367)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
The buggy address belongs to the cache xfs_rtrefcountbt_cur of size 216
The buggy address is located 8 bytes to the right of
allocated 216-byte region [ffff888018391578, ffff888018391650)
Kernel panic - not syncing: Fatal exception |
| In the Linux kernel, the following vulnerability has been resolved:
xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN
When exchanging two full-file ranges, xmi_can_exchange_reflink_flags()
can move the reflink inode flag from the file that currently has it to
the other file, as long as exactly one side is marked. This assumes
that the file contents, and therefore all shared extents, are exchanged.
That assumption is not true when XFS_EXCHMAPS_INO1_WRITTEN is set.
xfs_exchmaps_can_skip_mapping() can skip hole and unwritten mappings
from file1, so an exchange can complete without moving every mapping
that the earlier flag-swap decision accounted for. In that case the
post-operation cleanup can clear the reflink flag from an inode that
still owns shared written extents. Later writes then take the
non-reflink write path and may update blocks that should still have
been protected by CoW, which shows up as data corruption between
reflink-related files.
Fix this by disabling the reflink flag exchange whenever
XFS_EXCHMAPS_INO1_WRITTEN is requested. The contents exchange can still
proceed; the conservative outcome is that both inodes keep the reflink
flag. The regular reflink flag cleanup path can drop the extra flag
later once the inode no longer has shared extents. |
| In the Linux kernel, the following vulnerability has been resolved:
ceph: fix hanging __ceph_get_caps() with stale mds_wanted
A reader can hang forever in __ceph_get_caps() when the client no
longer holds `FILE_RD`, but local cap state still says that the
capability is already wanted (via `mds_wanted`).
One way to trigger this is through MDS cap revocation. If another
client performs a conflicting operation, the MDS can revoke `FILE_RD`
from the reader; the next read then has to reacquire `FILE_RD`. If
the cap update that should request `FILE_RD` never reaches the MDS
after `cap->mds_wanted` was raised, the reader is left holding only
non-file caps while local `mds_wanted` still includes the file read
caps.
In that state, try_get_cap_refs() sees `need <= mds_wanted` and
returns 0, so __ceph_get_caps() just waits on `i_cap_wq`. If the cap
update that was supposed to request `FILE_RD never reaches the MDS
after `cap->mds_wanted was` raised, no further request is sent and the
waiter can sleep indefinitely until unrelated cap traffic happens to
wake it up.
The ordering issue is that `cap->mds_wanted` is updated in
__prep_cap() before the `CEPH_MSG_CLIENT_CAPS message` is actually
queued for send. That makes one field serve two different meanings at
once: what this client wants, and what the client believes the MDS
already knows it wants.
A proper fix would be to split those states and track whether a cap
update is actually in flight or has been observed by the MDS.
However, simply moving the `cap->mds_wanted assignment` later would
not be sufficient: queueing the message in the messenger does not
guarantee that the MDS processed that specific wanted set, and
reconnect or message loss can still invalidate that assumption.
Fixing that properly would require a larger rework of the cap state
machine.
To allow simpler backports to stable kernels, this patch implements a
simpler workaround:
- stop waiting forever in __ceph_get_caps(); after a bounded wait,
fall back to the renew path
- make ceph_renew_caps() issue a synchronous `OPEN` request whenever
the inode still does not actually hold the wanted caps, instead of
only calling ceph_check_caps()
The extra issued-vs-wanted check in ceph_renew_caps() is necessary
because the previous test only checked whether the inode still had any
real caps at all. That is not enough after revocation: the client can
still hold something like `pLs` and yet be missing `FILE_RD`
completely. In that case, falling back to ceph_check_caps() is not
sufficient, because it still trusts `cap->mds_wanted` and may resend
nothing. By requiring `(issued & wanted) == wanted` before taking the
asynchronous path, the code only uses ceph_check_caps() when the
`wanted caps` are already actually issued. Otherwise, it sends the
synchronous `OPEN` renew.
This preserves the existing asynchronous fast path when the wanted
caps are already issued, avoids changing cap-state semantics, and
fixes the hang by guaranteeing that a stalled waiter eventually
retries through a path that does not rely on the stale `mds_wanted`
state.
[ idryomov: move CEPH_GET_CAPS_WAIT_TIMEOUT from libceph.h to
mds_client.h, formatting ] |
| In the Linux kernel, the following vulnerability has been resolved:
clk: spacemit: k3: set hdma clock as critical
HDMA clock is responsible for the internal TCM access path of X100 RISC-V
core, so set the clock flag as critical to prevent it from being shut off,
otherwise the Linux system will hang, for example in the case of a vector
instruction access generates a page fault. |
| In the Linux kernel, the following vulnerability has been resolved:
riscv: lib: Fix ZBB strnlen reading past count boundary
The ZBB-optimized strnlen loop loads one word ahead before checking the
aligned boundary:
REG_L t1, SZREG(t0) // load next word
addi t0, t0, SZREG // advance
orc.b t1, t1
bgeu t0, t4, 4f // boundary check AFTER load
where t4 = (s + count) & -SZREG. When s is aligned and count is a
multiple of SZREG, t4 equals s + count and the loop loads a full word
starting at exactly s + count. If s + count falls on a page boundary
with the next page unmapped, this faults.
Fix by computing the aligned boundary from the last valid byte
(s + count - 1) instead of s + count. This makes the loop stop at the
word containing the last valid byte rather than potentially loading the
word after it. The count == 0 case is already handled by the beqz
early exit.
Also add a pre-loop guard (bgeu t0, t4) for the case where all valid
bytes fit within the first word. With the adjusted boundary, t4 can
equal t0, and entering the loop with stale register state from the
first-word processing would produce incorrect results.
The final minu clamp ensures the result is still correct when the last
loaded word extends past s + count - 1 within the same aligned word. |
| In the Linux kernel, the following vulnerability has been resolved:
ovpn: defer key slot crypto freeing to workqueue
Key slots are released through a kref and the existing release path
frees the AEAD transforms from an RCU callback. That is not safe for all
crypto implementations: crypto_free_aead can sleep, for example when an
async or hardware implementation has teardown work to complete.
Use queue_rcu_work for key-slot release. This keeps the RCU grace period
needed by lockless key-slot readers, but runs the actual crypto teardown
from workqueue context where sleeping is allowed. Once the rcu_work
callback runs, pre-existing RCU readers are gone, and the final kref put
already proves that no transform user remains, so the worker can release
the AEAD transforms and free the slot directly.
The previous patch drains ovpn_wq during module exit, so queued key-slot
teardown work cannot outlive module text. |
| In the Linux kernel, the following vulnerability has been resolved:
veth: fix queue index used to wake the peer txq in veth_poll
veth_poll() derives the index of the peer TX queue to wake from
rq->xdp_rxq.queue_index. That field is only initialized by
xdp_rxq_info_reg() in veth_enable_xdp_range(), which runs only when an
XDP program is attached. On the plain GRO/NAPI path
(veth_napi_enable_range()) xdp_rxq_info_reg() is never called, so
queue_index stays 0 for every queue, as priv->rq is zero-allocated.
So in a multi-queue setup with GRO enabled and no XDP program attached,
every NAPI instance looks at the peer's TX queue 0. If veth_xmit() stops
peer TX queue 1 because the ptr_ring is full (NETDEV_TX_BUSY), nothing
ever wakes it again: the poller draining queue 1 wakes queue 0 instead.
veth implements no ndo_tx_timeout, so the netdev watchdog does not kick
in either, and the queue stays stopped indefinitely.
Derive the index from the position of the rq within priv->rq instead,
which is correct regardless of whether XDP was ever enabled.
Scripts to reproduce the stall are available at
https://github.com/netoptimizer/veth-backpressure-performance-testing |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused |
