| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered
sata_dwc_enable_interrupts() is called before platform_get_irq() and
ata_host_activate(), leaving the SATA controller's interrupt mask
enabled without a registered handler. If a later step fails (irq
request, phy init, etc.) or if the controller asserts an interrupt
during probe, the irq line may fire with no handler, causing a
spurious interrupt storm.
Move sata_dwc_enable_interrupts() after ata_host_activate() so that
interrupts are only unmasked once the handler is registered and the
core is fully initialized. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: revalidate LOAD_CONN_PARAM queued update
MGMT_OP_LOAD_CONN_PARAM queues conn_update_sync() when a single parameter
update changes an existing LE central connection. The queued work currently
stores a borrowed hci_conn_params entry from hdev->le_conn_params. A later
LOAD_CONN_PARAM request can clear disabled parameters and free that entry
before hci_cmd_sync_work() runs the queued callback.
Do not keep the borrowed hci_conn_params pointer in queued work. Queue the
hci_conn instead and hold a reference until the queued callback completes.
When the work runs, revalidate that the connection is still present, look
up the current hci_conn_params entry, and cancel the update if userspace
removed that entry while the work was pending.
Copy the interval values from the current params entry under hdev->lock,
then drop the lock and keep using hci_le_conn_update_sync() to issue the
update.
Validation reproduced this kernel report:
BUG: KASAN: slab-use-after-free in conn_update_sync+0x2a/0xf0 [bluetooth]
Read of size 1 at addr ffff88810c697126 by task kworker/u17:0/377
Workqueue: hci0 hci_cmd_sync_work [bluetooth]
Call Trace:
<TASK>
dump_stack_lvl+0x66/0xa0
print_report+0xce/0x5f0
kasan_report+0xe0/0x110
conn_update_sync+0x2a/0xf0 [bluetooth]
hci_cmd_sync_work+0x187/0x210 [bluetooth]
process_one_work+0x4fd/0xbc0
worker_thread+0x2d8/0x570
kthread+0x1ad/0x1f0
ret_from_fork+0x3c9/0x540
ret_from_fork_asm+0x1a/0x30
Allocated by task 466:
hci_conn_params_add+0xa6/0x240 [bluetooth]
load_conn_param+0x4e1/0x850 [bluetooth]
hci_sock_sendmsg+0x96b/0xf80 [bluetooth]
Freed by task 474:
kfree+0x313/0x590
hci_conn_params_clear_disabled+0x9b/0xc0 [bluetooth]
load_conn_param+0x4bf/0x850 [bluetooth]
hci_sock_sendmsg+0x96b/0xf80 [bluetooth] |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: extend conn_hash lookup critical sections
Using RCU-protected pointers outside the critical sections without
refcount is incorrect and may result to UAF.
Extend critical section to cover both hci_conn_hash lookup and use of
the returned conn.
Add surrounding rcu_read_lock() also when return value is not used, in
preparation for RCU lockdep requirement to hci_lookup_le_connect().
This avoids concurrent deletion of the conn before we are done
dereferencing it.
Also, make sure to hold hdev->lock when accessing hdev->accept_list. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync
Dereferencing RCU-protected pointers outside critical sections is
invalid and may lead to UAF.
Take hdev->lock for hci_conn lookup and hci_abort_conn(). Don't use RCU
to ensure the conn is fully initialized at this point. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds
Dereferencing RCU-protected pointers outside critical sections is
invalid and may lead to UAF. Use of hci_conn in hci_sync callbacks also
needs to hold refcount to avoid UAF.
Take appropriate locks for hci_conn lookups, and take refcount for
hci_conn pointers stored in mgmt_pending_cmd so that the pointer stays
valid.
When accessing conn->state, ensure hdev->lock is held to avoid data
race. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: hold hdev->lock for hci_conn_params lookups
hci_conn_params_lookup requires hdev->lock be held, otherwise the list
iteration or param access is not safe.
Hold hdev->lock for params lookups in hci_sync. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_qca: Clear memdump state on invalid dump size
qca_controller_memdump() allocates qca->qca_memdump before processing
the first dump packet. For a sequence-zero packet it then disables IBS,
marks memdump collection active, and reads the advertised dump size.
If the controller reports a zero dump size, the error path frees the
local qca_memdump object and returns without clearing qca->qca_memdump
or undoing the collection state. A later memdump work item initializes
its local pointer from qca->qca_memdump and skips allocation when that
pointer is non-NULL, so it can operate on freed memory. The stale
collection and IBS-disabled flags can also leave waiters or later
transmit handling blocked behind an aborted dump.
Clear the saved pointer and memdump state before returning from the
invalid-size path, matching the cleanup used when hci_devcd_init() fails.
A static analysis checker reported the stale memdump state, and manual
source review confirmed the invalid-size failure path. |
| In the Linux kernel, the following vulnerability has been resolved:
smb/client: handle overlapping allocated ranges in fallocate
smb3_simple_fallocate_range() can skip holes when an allocated range
returned by the server starts before the current fallocate offset. The
skipped hole is not zero-filled, but fallocate still returns success. A
later write to that hole may therefore fail with ENOSPC.
The function queries allocated ranges so that it can preserve existing
contents and write zeroes only into holes. However, the server may return
a range that starts before the current fallocate offset.
For example, assume the fallocate request is [100, 400) and the only
allocated range returned by the server is [0, 200):
Request: [100, 400)
Server range: [ 0, 200) allocated
Correct:
[100, 200) allocated data, skip
[200, 400) hole, zero-fill
Current:
[100, 300) skipped
[300, 400) zero-filled afterwards
The current code adds the full server range length, 200, to the current
offset 100 and moves to 300. As a result, the hole in [200, 300) is
skipped without being zero-filled.
Fix this by advancing only over the part of the allocated range that
overlaps the current fallocate offset. Ignore ranges that end before the
current offset and reject ranges whose end offset overflows.
This also prevents a malformed range length from causing an out-of-bounds
zero-buffer read. |
| In the Linux kernel, the following vulnerability has been resolved:
can: raw: add locking for raw flags bitfield
With commit 890e5198a6e5 ("can: raw: use bitfields to store flags in
struct raw_sock") the formerly separate integer values have been integrated
into a single bitfield. This led to a read-modify-write operation when
changing a flag in raw_setsockopt() which now needs a locking to prevent
concurrent access.
Instead of adding a lock/unlock hell in each of the flag manipulations this
patch introduces a wrapper for a new raw_setsockopt_locked() function
analogue to the isotp_setsockopt[_locked]() approach in net/can/isotp.c
[mkl: use Closes tag instead of Link] |
| In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Reject unhashed UDP sockets on sockmap update
UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means
sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false.
Because sockmap accepts unbound UDP sockets, a BPF program can increment a
socket's refcount via lookup. If the socket is subsequently bound, the
transition from unbound to bound causes bpf_sk_release() to skip the
decrement of the refcount, causing a memory leak.
unreferenced object 0xffff88810bc2eb40 (size 1984):
comm "test_progs", pid 2451, jiffies 4295320596
hex dump (first 32 bytes):
7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................
02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............
backtrace (crc bdee079d):
kmem_cache_alloc_noprof+0x557/0x660
sk_prot_alloc+0x69/0x240
sk_alloc+0x30/0x460
inet_create+0x2ce/0xf80
__sock_create+0x25b/0x5c0
__sys_socket+0x119/0x1d0
__x64_sys_socket+0x72/0xd0
do_syscall_64+0xa1/0x5f0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Instead of special-casing for refcounted sockets, reject unhashed UDP
sockets during sockmap updates, as there is no benefit to supporting those.
This effectively reverts the commit under Fixes, with two exceptions:
1. sock_map_sk_state_allowed() maintains a fall-through `return true`.
2. In the spirit of commit b8b8315e39ff ("bpf, sockmap: Remove unhash
handler for BPF sockmap usage"), the proto::unhash BPF handler is not
reintroduced.
Historical note: this issue is related to commit 67312adc96b5 ("bpf: reject
unhashed sockets in bpf_sk_assign"). |
| In the Linux kernel, the following vulnerability has been resolved:
s390/checksum: Fix csum_partial() without vector facility
Currently csum_partial() calls csum_copy() with copy=false and dst=NULL.
On machines without the vector facility, csum_copy() falls back to
cksm(dst, ...), causing the checksum to be calculated from address zero
instead of the source buffer.
The VX implementation already checksums data loaded from src. Make the
fallback do the same by passing src to cksm(). |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe/vf: Fix VF CCS attach/detach race with in-flight BO moves
xe_bo_move() attaches VF CCS read/write batch buffers (BBs) to a BO
after it transitions NULL/SYSTEM -> TT, and detaches them after it
transitions TT -> SYSTEM. Both operations were done synchronously on
the CPU immediately after building the move's copy/clear fence,
without waiting for that fence to signal. This creates two races with
VF migration:
- Attach happens too late relative to the copy job it is meant to
protect. If the copy job is submitted before the CCS BBs are
attached, a VF migration event that pauses execution mid-copy can
observe partially copied CCS metadata without the attach state
needed to correctly save/restore it.
- Detach happens too early relative to the copy job that moves data
out of TT. The CCS BBs are torn down right after the copy fence is
obtained, while the actual blit may still be in flight. A VF
migration event that pauses execution mid-copy can then race the
save/restore path against the still-running blit, and the CCS BBs
it would need to make sense of the paused state have already been
removed.
Fix both races:
- Move the attach call to before the copy/clear job is submitted, so
the CCS BBs are already registered by the time the copy runs. On
attach failure, unwind and bail out of the move. xe_migrate_ccs_rw_copy()
now takes the destination resource explicitly, since bo->ttm.resource
is not updated to the new resource until after the move commits.
- Detach only after explicitly waiting for the copy fence to signal,
instead of tearing down the CCS BBs immediately after obtaining it.
While here, also fix xe_sriov_vf_ccs_attach_bo() to properly unwind and
propagate errors: the per-context loop previously never broke out on
error, silently discarding earlier failures. Unwind by clearing each
attached context directly via xe_migrate_ccs_rw_copy_clear() instead of
reusing xe_sriov_vf_ccs_detach_bo(), which requires both contexts to be
attached before it will clean up either one.
(cherry picked from commit d45ad0aa7a1eb5d7288b5ed948b05695611dc39e) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe/guc: Keep scheduler timeline name alive
The scheduler keeps a pointer to the timeline name, but q->name
is freed with the exec queue while scheduler fences can still
reference it.
Store the name in struct xe_guc_exec_queue so it shares
the scheduler's RCU-deferred lifetime.
(cherry picked from commit 41075f0eb5dcbd3b065d15f15ef7bbe9315188e8) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe/guc: Hold device ref until queue teardown completes
GuC exec queue destruction can run asynchronously. If the final device
put happens from a destroy worker, drmm cleanup can end up draining
the same workqueue and deadlock.
Hold a drm_device reference for the queue lifetime and drop it after
queue teardown completes. This keeps drmm cleanup from running while
async destroy work is still pending.
Move GuC destroy work to a module-lifetime Xe workqueue and flush it
on PCI remove so hot-unbind/rebind still waits for pending destroy work.
With queue-held device refs, guc_submit_sw_fini() cannot run with live
GuC IDs. Replace the fini wait with an assertion and remove the unused
fini_wq.
v2:
- Rebase
v3:
- Switch to queue-lifetime drm_dev_get()/drm_dev_put() model. (Matt)
- Queue async teardown on system_dfl_wq instead of xe->destroy_wq. (Matt)
- Drop separate deferred drm_dev_put worker.
- Remove stale drain_workqueue(xe->destroy_wq) from guc_submit_sw_fini().
v4:
- Replace the guc_submit_sw_fini() wait with an assertion and remove
the now-unused fini_wq. (sashiko)
v5:
- Move destroy work to a module-lifetime Xe workqueue instead of
system_dfl_wq. (Matt)
- Flush the module-lifetime destroy workqueue during PCI remove to
preserve the old device-remove wait semantics.
v6:
- Keep SVM pagemap destroy work on the per-device destroy_wq to avoid
letting it outlive the xe_device/drm_device. (Sashiko)
- Use WQ_MEM_RECLAIM for xe->destroy_wq because SVM pagemap destroy work
can be queued from the reclaim path.
v7:
- Drop the per-device xe->destroy_wq and use the module-level destroy WQ
for SVM pagemap destroy as well. (Matt)
- Rename xe_exec_queue_destroy_wq_*() helpers to xe_destroy_wq_*()
helpers because the WQ is no longer exec-queue specific. (Matt)
v8:
- Rebase.
v9:
- Keep SVM pagemap destroy work on the per-device WQ_MEM_RECLAIM
destroy_wq because it can be queued from reclaim and embeds
the dev_pagemap used by devres teardown. (Sashiko)
- Keep the module-level destroy WQ GuC-only and drop WQ_MEM_RECLAIM
from it.
- Update the module-WQ kdoc to document the GuC/SVM split.
v10:
- Keep xe->destroy_wq per-cpu while adding WQ_MEM_RECLAIM to fix the
workqueue allocation warning.
v11:
- Drop the SVM pagemap destroy comment as it was revision-specific.
(Thomas)
v12:
- Rebase.
(cherry picked from commit da1124abac689cc2b1d8995e5f0a816f8a122edb) |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: pin conn during async oplock break notification
smb2_oplock_break_noti() and smb2_lease_break_noti() store a ksmbd_conn
pointer in an async ksmbd_work and then queue that work on ksmbd-io. The
work only increments conn->r_count, which prevents teardown from passing
the pending-request wait after the increment, but it does not pin the
struct ksmbd_conn object.
If connection teardown races with an oplock break notification, the last
conn reference can be dropped before the queued worker finishes. The
worker then uses the freed conn in ksmbd_conn_write() and
ksmbd_conn_r_count_dec().
Take a real conn reference when publishing the conn pointer to the async
work item, and drop it after the notification work has decremented
r_count. Apply the same lifetime rule to lease break notification, which
uses the same work->conn pattern. |
| In the Linux kernel, the following vulnerability has been resolved:
accel/amdxdna: Fix use-after-free of mm_struct in job scheduler
amdxdna_cmd_submit() stores current->mm in job->mm without holding any
reference. aie2_sched_job_run() later access job->mm from the DRM
scheduler worker thread. With only a raw pointer and no structural
reference, the mm_struct can be freed before the scheduler runs the job.
Fix this by calling mmgrab() to hold a structural mm_count reference for
the lifetime of the job, paired with mmdrop() in every cleanup path. |
| In the Linux kernel, the following vulnerability has been resolved:
tcp: fix TIME_WAIT socket reference leak on PSP policy failure
Release the TIME_WAIT socket reference and jump to discard_it
upon PSP policy failure in both IPv4 and IPv6 receive paths.
This prevents a memory leak of tcp_tw_bucket structures. |
| In the Linux kernel, the following vulnerability has been resolved:
dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()
When a dpll_pin is shared across multiple dpll_device instances and
those devices are being unregistered (e.g. during driver module removal),
a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync().
This happens under the following conditions:
- A pin is registered with two or more dpll devices (dpll_A, dpll_B)
- The pin has ref_sync pairs with other pins
- During unregistration of dpll_A's pins, a ref_sync partner pin is
unregistered first, removing it from dpll_A->pin_refs
- But since the partner pin is still registered with dpll_B, its
dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT
run and the partner stays in the pin's ref_sync_pins xarray
- When the pin itself is then unregistered from dpll_A, the delete
notification calls dpll_msg_add_pin_ref_sync() which finds the
partner in ref_sync_pins, passes dpll_pin_available() (partner is
still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A,
partner) returns NULL because partner was already removed from
dpll_A->pin_refs
- The NULL priv pointer is passed to the driver's ref_sync_get
callback, which dereferences it
BUG: kernel NULL pointer dereference, address: 0000000000000034
Oops: Oops: 0000 [#1] SMP NOPTI
RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x]
Call Trace:
dpll_msg_add_pin_ref_sync+0xb8/0x200
dpll_cmd_pin_get_one+0x3b6/0x4b0
dpll_pin_event_send+0x72/0x140
__dpll_pin_unregister+0x5a/0x2b0
dpll_pin_unregister+0x49/0x70
Fix this by skipping ref_sync pins whose priv pointer cannot be resolved
for the current dpll device. |
| In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_tunnel_key: Defer dst_release to RCU callback
Fix a race-condition use-after-free in tunnel_key_release_params().
The function releases the metadata_dst of the old params synchronously
via dst_release() while deferring the params struct free with
kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may
still hold the old params pointer (under rcu_read_lock_bh) and proceed
to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's
dst_release has already pushed the dst's rcuref to RCUREF_DEAD.
[email protected] produced a poc which i (and Victor) verified
that KASAN reports:
==================================================================
BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112
BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326
BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109
BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173
BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168
Write of size 4 at addr ffff88806158de40 by task poc/9388
CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy)
Tainted: [W]=WARN
Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94
dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378
print_report+0x139/0x4ad mm/kasan/report.c:482
kasan_report+0xe4/0x1d0 mm/kasan/report.c:595
check_region_inline mm/kasan/generic.c:186
kasan_check_range+0x125/0x200 mm/kasan/generic.c:200
instrument_atomic_read_write include/linux/instrumented.h:112
atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326
__rcuref_put include/linux/rcuref.h:109
rcuref_put include/linux/rcuref.h:173
dst_release+0x5b/0x370 net/core/dst.c:168
refdst_drop include/net/dst.h:272
skb_dst_drop include/net/dst.h:284
skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163
skb_release_all net/core/skbuff.c:1187
[..]
Allocated by task 9391:
kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
kasan_save_track+0x14/0x30 mm/kasan/common.c:78
poison_kmalloc_redzone mm/kasan/common.c:398
__kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415
kasan_kmalloc include/linux/kasan.h:263
__do_kmalloc_node mm/slub.c:5296
__kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308
kmalloc_noprof include/linux/slab.h:954
kzalloc_noprof include/linux/slab.h:1188
offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35
tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258
tcf_action_offload_add net/sched/act_api.c:293
tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547
tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101
[..]
Freed by task 9391:
kasan_save_stack+0x30/0x50 mm/kasan/common.c:57
kasan_save_track+0x14/0x30 mm/kasan/common.c:78
kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253
__kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235
slab_free_hook mm/slub.c:2689
slab_free mm/slub.c:6251
kfree+0x21f/0x6b0 mm/slub.c:6566
tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284
tcf_action_offload_add net/sched/act_api.c:293
tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547
tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101
The buggy address belongs to the object at ffff88806158de00
which belongs to the cache kmalloc-256 of size 256
The buggy address is located 64 bytes inside of
freed 256-byte region [ffff88806158de00, ffff88806158df00)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c
head: order:1 mapcount:0 entire_map
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
sctp: fix auth_hmacs array size in struct sctp_cookie
The auth_hmacs array in struct sctp_cookie is supposed to store a complete
SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr
followed by N HMAC identifiers.
However, the array size was calculated using an extra 2 bytes instead of
sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers
are configured, the HMAC-ALGO parameter stored in the endpoint is larger
than the auth_hmacs buffer in the cookie.
As a result, sctp_association_init() copies beyond the end of auth_hmacs
when initializing the association, corrupting the adjacent auth_chunks
field. This can lead to an invalid HMAC identifier being accepted and later
cause an out-of-bounds read in sctp_auth_get_hmac().
Fix the array size calculation by including the full SCTP parameter header
size. |
