| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
staging: vme_user: fix location monitor leak in tsi148 bridge
tsi148_probe() allocates a location monitor resource and links it into
tsi148_bridge->lm_resources. The probe error path frees this list, but
tsi148_remove() only frees the dma, slave and master resource lists, so
the location monitor resource is leaked on device unbind or module
unload.
Free the lm_resources list in tsi148_remove() as well, before
tsi148_bridge is freed. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/vcn4: avoid rereading IB param length
Reuse the parameter length returned by
vcn_v4_0_enc_find_ib_param() instead of rereading it from
the IB.
This avoids a potential TOCTOU issue if the IB contents
change between reads.
(cherry picked from commit dbb02b4755f8c1f3773263f2d779872c1c0c073a) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON()
There's no need to crash the kernel for these cases.
(cherry picked from commit fa4f86a148271e325e95287630a3a15a9cd35fdc) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON()
There's no need to crash the kernel for these cases.
(cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c) |
| In the Linux kernel, the following vulnerability has been resolved:
tcp: challenge ACK for non-exact RST in SYN-RECEIVED
The SYN-RECEIVED request-socket path in tcp_check_req() accepts an
in-window RST without requiring SEG.SEQ to exactly match RCV.NXT. A
non-exact RST therefore removes the request instead of eliciting a
challenge ACK.
RFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in
SYN-RECEIVED: an exact RST resets the connection, while a non-exact
in-window RST must trigger a challenge ACK and be dropped.
Apply that check before the ACK-field validation, following the RFC
sequence-number, RST, then ACK processing order. Factor the per-netns
challenge ACK quota out of tcp_send_challenge_ack() so request sockets
can share it. Use the request socket's send_ack() callback and its own
out-of-window ACK timestamp to send and rate-limit the response. |
| In the Linux kernel, the following vulnerability has been resolved:
tcp: initialize standalone TCP-AO response padding
tcp_v4_send_ack() and tcp_v6_send_response() construct standalone TCP
responses with TCP-AO options. The option length carries the actual MAC
length, but the TCP header length includes the option rounded up to a
four-byte boundary.
tcp_ao_hash_hdr() writes the MAC only. Thus, when the MAC length is not
four-byte aligned, the one to three bytes after the MAC are left
uninitialized and may be transmitted. For the normal TCP-AO hashing
mode, those bytes also have to be initialized before computing the MAC.
Initialize only the alignment padding in the TCP-AO branches, before
hashing the header. Use TCPOPT_NOP, as in the normal TCP-AO output path.
This avoids adding work to non-AO TCP responses while preserving a valid
authenticated header. |
| In the Linux kernel, the following vulnerability has been resolved:
ila: reload IPv6 header after pskb_may_pull in checksum adjust
ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling
pskb_may_pull(). On a non-linear skb whose transport header sits in a page
fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head()
and free the old skb head, leaving ip6h dangling; the following
get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator()
uses ip6h (and the iaddr derived from it) again after the csum-adjust
call and additionally writes the new locator through that pointer.
Impact: a remote IPv6 packet routed through a configured ILA
csum-adjust-transport route or receive-side mapping triggers a
slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or
mapping requires CAP_NET_ADMIN to configure, but trigger packets are
unauthenticated once it exists.
Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport()
before the csum-diff read. In ila_update_ipv6_locator() only the
ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in
that case alone before the destination-address write; the neutral-map
modes never pull and keep their cached pointers. |
| In the Linux kernel, the following vulnerability has been resolved:
ptp: ptp_s390: Add missing facility check
Only register the physical clock when facility 28 is installed
and PTFF QAF returns that PTFF QPT is available. |
| CWE-200: Exposure of Sensitive
Information to an Unauthorized Actor |
| Incorrect conversion between numeric types in VC1 codec in libsavsvc.so prior to SMR Aug-2026 Release 1 allows local attackers to write out-of-bounds memory. |
| In the Linux kernel, the following vulnerability has been resolved:
mm/khugepaged: write all dirty file folios when collapsing
[There is no upstream commit, as this code was removed by upstream
commit 044925f9b565 ("mm: fs: remove filemap_nr_thps*() functions and their users")]
As-is, khugepaged and writable-file opening exclude each other. A file
cannot be open writeable and have THPs (because the filesystem is not aware
of them). khugepaged will never collapse file pages for files that are
opened writeable. On an open(O_RDWR/O_WRONLY), the page cache for that
particular file is dropped. This is fine because nothing could've been
dirtied.
However, there is an edge-case: collapse_file() might not be able to
coexist with concurrent writers, but it can coexist with dirty folios
(from previous writers). Therefore, the following can happen:
open(file, O_RDWR)
write(file)
close(file)
madvise(file_mapping, MADV_COLLAPSE, some non-dirty range)
open(file, O_RDWR)
nr_thps > 0
truncate_inode_pages()
/* THPs are cleared out, but so are the dirty folios */
When this edge-case happens, there is data loss, as the dirty folios are
fully discarded.
Fix it by fully writing back the page cache (and waiting) when collapsing
file THPs. Doing so provides the guarantee that no dirty folio will be
observed while there are active THPs. To fully ensure this is safe, the
invalidate_lock needs to be held while doing the writeout, so that
do_dentry_open()'s page cache truncation excludes this write-and-wait.
As a side effect, move the nr_thps counter bumping outside the i_pages
lock. This is correct since the counter itself is an atomic_t and the
producer <-> consumer correctness is provided by a full memory barrier:
smp_mb() in collapse_file()/memory barrier implied by full ordering in
get_write_access() -> atomic_inc_unless_negative(). |
| In the Linux kernel, the following vulnerability has been resolved:
HID: wacom: use GFP_ATOMIC in wacom_wac_queue_flush()
wacom_wac_queue_flush() is called via the .raw_event callback
(wacom_raw_event → wacom_wac_pen_serial_enforce → wacom_wac_queue_flush).
For USB HID devices, this callback is invoked from hid_irq_in(), which
is a URB completion handler running in atomic context. Using GFP_KERNEL
in this path can sleep, leading to a "scheduling while atomic" bug.
Use GFP_ATOMIC instead. The existing code already handles allocation
failure by skipping the fifo entry and continuing. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: core: fix uninitialized data in debugfs
If *ppos is non-zero then simple_write_to_buffer() will not initialize
the start of buf[]. Non zero values for *ppos aren't going to work
anyway. Test for them at the start of the function and return -EINVAL. |
| In the Linux kernel, the following vulnerability has been resolved:
debugobjects: Plug race against a concurrent OOM disable
syzbot reported a puzzling splat:
WARNING: kernel/time/hrtimer.c:443 at stub_timer+0xa/0x20
stub_timer() is installed as timer callback function in
hrtimer_fixup_assert_init(), which is invoked when
debug_object_assert_init() can't find a shadow object. In that case debug
objects emits a warning about it before invoking the fixup.
Though the provided console log lacks this warning and instead has the
following a few seconds before the splat:
ODEBUG: Out of memory. ODEBUG disabled
So the object was looked up in debug_object_assert_init() and the lookup
failed due a concurrent out of memory situation which disabled debug
objects and freed the shadow objects:
debug_object_assert_init()
if (!debug_objects_enabled)
return; obj = alloc();
if (!obj) {
// Out of memory
debug_objects_enabled = false;
free_objects();
obj = lookup_or_alloc();
// The lookup failed because the other side
// removed the objects, so this returns
// an error code as the object in question
// is not statically initialized
if (!IS_ERR_OR_NULL(obj))
return;
if (!obj) {
debug_oom();
return;
}
print(...)
if (!debug_objects_enabled)
return;
fixup(...)
The debug object splat is skipped because debug_objects_enabled is false,
but the fixup callback is invoked unconditionally, which makes the timer
disfunctional.
This is only a problem in debug_object_assert_init() and
debug_object_activate() as both have to handle statically initialized
objects and therefore must handle the error pointer return case
gracefully. All other places only handle the found/not found case and the
NULL pointer return is a signal for OOM. Otherwise they get a valid shadow
object.
Plug the hole by checking whether debug objects are still enabled before
invoking the print and fixup function in those two places. |
| In the Linux kernel, the following vulnerability has been resolved:
time/jiffies: Register jiffies clocksource before usage
Teddy reported that a XEN HVM has a long boot delay, which was bisected to
the recent enhancements to the negative motion detection. It turned out
that the jiffies clocksource is used in early boot before it is registered,
which leaves the max_delta_raw field at zero. That causes the read out to
be clamped to the max delta of 0, which means time is not making progress.
Cure it by ensuring that it is initialized before its first usage in
timekeeping_init(). |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: reject mapping a reserved doorbell to a new queue
When creating an user-queue, the user space
provides a doorbell BO handle and an offset within
the bo to obtain a doorbell.
However current implementation using xa_store_irq()
to store a doorbell, which allows a later queue created
with the same BO and offset parameters to overwrite an
existing queue and doorbell mapping.
This can cause problems like misrouting fence IRQ
processing to a wrong queue, and mislead the cleanup
process of one queue erasing the mapping of another queue.
This commit fixes this issue by replacing xa_store_irq with
xa_insert_irq, which rejects mapping a reserved
doorbell to a newly created queue
(cherry picked from commit 6244eae22966350db52faf9c1369d3b2ffc5de4e) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: invoke pm_genpd_remove() before freeing genpd
Call pm_genpd_remove() to unregister from global list prior to releasing
acp_genpd memory, and clear the pointer after free.
(cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix division by zero with invalid uvd dimensions
When width or height is less than 16, width_in_mb or height_in_mb
becomes 0, leading to fs_in_mb being 0. This causes a division by
zero when calculating num_dpb_buffer in H264 and H264 Perf decode
paths.
Add validation to reject frames with width < 16 or height < 16
before performing any calculations that depend on these values.
V2: Format change - move up all vaiable definitions.
V3: Use warn_once to avoid spam.
(cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON()
There's no need to crash the kernel for these cases.
(cherry picked from commit f952076f76d62f783e8ba4995a7c400d39354ccf) |
| In the Linux kernel, the following vulnerability has been resolved:
tipc: clear sock->sk on the failed-insert path in tipc_sk_create()
When tipc_sk_create() fails to insert the new socket (tipc_sk_insert()
returns non-zero), its error path frees the sk with sk_free() but leaves
sock->sk pointing at the freed object:
if (tipc_sk_insert(tsk)) {
sk_free(sk);
pr_warn("Socket create failed; port number exhausted\n");
return -EINVAL;
}
This is harmless for plain socket(): the syscall layer clears sock->ops
before releasing, so tipc_release() is never called. It is not harmless
on the accept() path. tipc_accept() creates the pre-allocated child
socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves
new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then
fput()s the new file, so __sock_release() -> tipc_release() runs
lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the
sk_lock spinlock.
tipc_release() already guards this exact "failed accept() releases a
pre-allocated child" case with "if (sk == NULL) return 0;", but the
guard is bypassed because tipc_sk_create() left sock->sk non-NULL
(dangling) rather than NULL.
Clear sock->sk on the failed-insert path so the existing tipc_release()
NULL check fires and the use-after-free is avoided.
The tipc_sk_insert() failure is reached when the per-netns socket
rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M
elements) -- i.e. once a netns holds ~2M TIPC sockets every insert
returns -E2BIG.
BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839)
Write of size 8 at addr ffff8880047cdc38 by task init/1
lock_sock_nested (net/core/sock.c:3839)
tipc_release (net/tipc/socket.c:638)
__sock_release (net/socket.c:710)
sock_close (net/socket.c:1501)
__fput (fs/file_table.c:512)
Allocated by task 1:
sk_alloc (net/core/sock.c:2308)
tipc_sk_create (net/tipc/socket.c:487)
tipc_accept (net/tipc/socket.c:2744)
do_accept (net/socket.c:2034)
Freed by task 1:
__sk_destruct (net/core/sock.c:2391)
tipc_sk_create (net/tipc/socket.c:504)
tipc_accept (net/tipc/socket.c:2744)
do_accept (net/socket.c:2034) |
