| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: guard dc_sink dereferences in MST mode validation
dm_dp_mst_is_port_support_mode() reads
aconnector->dc_sink->dsc_caps... for the DSC branch-throughput check,
and get_conv_frl_bw()'s HDMI-PCON FRL-bandwidth path reads
aconnector->dc_sink->edid_caps.max_frl_rate, both without a NULL
check. dc_sink is cleared asynchronously on MST unplug, and both
functions run from paths that the driver's own comments document as
racing that teardown: the connector probe worker's ->mode_valid
callback and a compositor's atomic check, neither of which holds the
MST manager lock that the teardown path uses. The former does have an
existing dsc_aux NULL check, but dsc_aux isn't reliably cleared in
every path that clears dc_sink, so it doesn't cover this.
Fail the port-support check and skip the FRL conversion path when the
sink is already gone.
(cherry picked from commit 7c3db8da4e039698ae198c870712428644e965c7) |
| In the Linux kernel, the following vulnerability has been resolved:
pfcp: fix socket lifetime on netdevice registration failure
pfcp_newlink() creates the UDP socket before register_netdevice().
If registration fails after pfcp_dev_init() succeeds, the core calls
pfcp_dev_uninit(), which releases the socket and clears pfcp->sk.
The newlink error path then releases it again, causing a NULL pointer
dereference. This was observed with failslab fault injection:
FAULT_INJECTION: forcing a failure.
kobject: kobject_add_internal failed for pfcp0 (error: -12 parent: net)
BUG: KASAN: null-ptr-deref in udp_tunnel_sock_release+0x1c/0x50
Read of size 8 at addr 0000000000000120 by task ip/1037
Call trace:
show_stack+0x18/0x24 (C)
dump_stack_lvl+0x78/0x90
print_report+0x468/0x5cc
kasan_report+0xa4/0xf0
__asan_load8+0x7c/0xd0
udp_tunnel_sock_release+0x1c/0x50
pfcp_newlink+0x128/0x184
rtnl_newlink+0x848/0xe44
rtnetlink_rcv_msg+0x468/0x514
netlink_rcv_skb+0xc0/0x1f0
rtnetlink_rcv+0x18/0x24
netlink_unicast+0x4b8/0x558
netlink_sendmsg+0x2b8/0x584
...
Return from pfcp_del_sock() if pfcp->sk is NULL. |
| In the Linux kernel, the following vulnerability has been resolved:
media: qcom: iris: fix runtime PM reference leaks
Use pm_runtime_resume_and_get() in iris_enable_power_domains()
to avoid leaking a runtime PM usage count on failure.
Also ensure pm_runtime_put_sync() is always called in
iris_disable_power_domains(), even when iris_opp_set_rate()
fails, so runtime PM references remain balanced. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: validate TX status rate metadata
minstrel_ht_tx_status() converts the HT/VHT rate reported in a TX status
into a group and rate index and uses those to index the minstrel_ht rate
tables. The existing validation only checked that an entry was present
and had tries recorded; it did not check that the reported MCS, spatial
stream count and bandwidth are representable by the tables, so malformed
metadata passed to minstrel_ht_get_stats() or
minstrel_ht_ri_get_stats() could be used as an out-of-bounds index.
Validate the rate metadata in the common TX status path instead of only
in minstrel_ht, since the values are used by more than rate control.
The legacy ieee80211_tx_rate array and the rate_info based entries are
sanitized in ieee80211_tx_status_ext() and ieee80211_tx_rate_update()
before any consumer runs: an entry that does not describe a valid rate
for its encoding is dropped. minstrel_ht keeps the checks that depend
on its own tables, i.e. the supported number of spatial streams, the MCS
group size and the supported bandwidths.
This does not take away the driver's responsibility to report sane
values, it only prevents a single bad report from corrupting mac80211
state. No WARN_ON() is added: with panic_on_warn a driver bug would
otherwise turn into a denial of service. |
| In the Linux kernel, the following vulnerability has been resolved:
virt: vmgenid: set driver_data before registering notification handlers
Both probe paths register their notification handler before assigning
driver_data, which the handler dereferences.
In the devicetree path, the notification IRQ can fire as soon as
devm_request_irq() registers the handler: the interrupt may already be
pending at probe time, for example when a VMM injects the
generation-changed notification while restoring a guest from a snapshot
that was taken before the driver had probed (Firecracker does exactly
this on snapshot restore). The IRQ is also requested with IRQF_SHARED,
so another device sharing the line can trigger the handler just as
early. The handler then calls vmgenid_notify(), which dereferences the
still-NULL driver_data and panics:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.38+ #1 PREEMPT(none)
Hardware name: linux,dummy-virt (DT)
pc : vmgenid_notify.isra.0+0x24/0x8c
lr : vmgenid_of_irq_handler+0x14/0x34
Call trace:
vmgenid_notify.isra.0+0x24/0x8c (P)
vmgenid_of_irq_handler+0x14/0x34
__handle_irq_event_percpu+0x44/0x1bc
handle_irq_event+0x4c/0xb4
handle_fasteoi_irq+0xf8/0x1f8
The ACPI path has the same ordering problem: the handler is installed
with acpi_install_notify_handler() before driver_data is assigned.
ACPI notifications are dispatched asynchronously from a workqueue, so
the window is narrow, but a notification arriving between the two calls
hits the same NULL dereference.
Assign driver_data before registering the handlers. The state is fully
initialized at that point, so the handlers are safe to run. Should
registration fail, the probe error path leaves no dangling pointer
behind: the driver core clears driver_data in device_unbind_cleanup(). |
| In the Linux kernel, the following vulnerability has been resolved:
sysctl: Check range in proc_dointvec_ms_jiffies_minmax
Add the range check to do_proc_int_conv_ms_jiffies_minmax that commit
d174174c6776 ("sysctl: replace SYSCTL_INT_CONV_CUSTOM macro with
functions") incorrectly removed. |
| In the Linux kernel, the following vulnerability has been resolved:
EDAC/altera: Use parent device for devres in altr_portb_setup()
Anchor the devres group and the devm-managed IRQ requests in altr_portb_setup()
to the actual parent device (device->edac->dev) instead of the embedded struct
device inside the copied per-port altr_edac_device_dev.
This keeps devres_open_group(), devm_request_irq(), devres_remove_group() and
devres_release_group() all referring to the same long-lived device so the
group and the resources allocated inside it are torn down together. |
| In the Linux kernel, the following vulnerability has been resolved:
binderfs: fix UAF write in binder_add_device
binderfs_binder_device_create() publishes the new dentry with
d_make_persistent() and then calls simple_done_creating(), which drops
the parent directory lock and the creator's dentry reference. It then
calls binder_add_device() to register the device in the global
binder_devices list.
After simple_done_creating() releases the parent directory lock, a
concurrent unlinkat() can remove the new device entry. Dropping the
creator's dentry reference can then trigger binderfs_evict_inode(),
freeing the device. binder_add_device() later accesses the freed
object, causing UAF write.
Found by a modified Syzkaller:
BUG: KASAN: slab-use-after-free in hlist_add_head include/linux/list.h:1073 [inline]
BUG: KASAN: slab-use-after-free in binder_add_device+0xa9/0xc0 drivers/android/binder.c:7068
Write of size 8 at addr ffff88805b340c00 by task syz.1.532/11389
CPU: 0 UID: 0 PID: 11389 Comm: syz.1.532 Not tainted 7.2.0 #4 PREEMPT(full)
Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x10e/0x1f0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xf7/0x600 mm/kasan/report.c:482
kasan_report+0xe4/0x120 mm/kasan/report.c:595
hlist_add_head include/linux/list.h:1073 [inline]
binder_add_device+0xa9/0xc0 drivers/android/binder.c:7068
binderfs_binder_device_create.isra.0+0x724/0x990 drivers/android/binderfs.c:196
binder_ctl_ioctl+0x186/0x1b0 drivers/android/binderfs.c:241
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7ff9027a833d
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ff903674018 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007ff902a35fa0 RCX: 00007ff9027a833d
RDX: 0000200000000500 RSI: 00000000c1086201 RDI: 0000000000000004
RBP: 00007ff902850733 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ff902a36038 R14: 00007ff902a35fa0 R15: 00007ffd7166bfa0
</TASK>
Allocated by task 11389:
kasan_save_stack+0x33/0x60 mm/kasan/common.c:57
kasan_save_track+0x14/0x30 mm/kasan/common.c:78
poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:415
kasan_kmalloc include/linux/kasan.h:263 [inline]
__kmalloc_cache_noprof+0x2e4/0x6f0 mm/slub.c:5489
_kmalloc_noprof include/linux/slab.h:988 [inline]
_kzalloc_noprof include/linux/slab.h:1309 [inline]
binderfs_binder_device_create.isra.0+0x17a/0x990 drivers/android/binderfs.c:148
binder_ctl_ioctl+0x186/0x1b0 drivers/android/binderfs.c:241
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 11389:
kasan_save_stack+0x33/0x60 mm/kasan/common.c:57
kasan_save_track+0x14/0x30 mm/kasan/common.c:78
kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5f/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2677 [inline]
slab_free mm/slub.c:6377 [inline]
kfree+0x2fc/0x6e0 mm/slub.c:6692
binderf
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
net: sparx5: skip ptp deinit if init was skipped
sparx5_ptp_init() returns early on the base lan969x variants
because they do not have the SPX5_FEATURE_PTP flag. It also returns early
when no "ptp" interrupt is described. Unbinding the driver then causes a
NULL pointer dereference when cleaning up uninitialized tx_skbs queues:
Unable to handle kernel NULL pointer dereference at virtual address
0000000000000008
Call trace:
skb_queue_purge_reason+0x68/0x120 (P)
sparx5_ptp_deinit+0x64/0xc0
mchp_sparx5_remove+0x38/0x70
platform_remove+0x20/0x30
device_remove+0x4c/0x80
Before per-port tx_skbs were added, a NULL dereference would have happened
when calling ptp_clock_unregister() on the never-registered PTP clocks.
Fix by returning early in sparx5_ptp_deinit() if PTP is not used. |
| In the Linux kernel, the following vulnerability has been resolved:
rtc: ac100: Fix clock provider use-after-free on probe failure
ac100_rtc_register_clks() registers the RTC-32k clock with
clk_hw_register_fixed_rate() and the clock provider with
of_clk_add_hw_provider(). Neither is device managed, and both are
released only from ac100_rtc_remove(). The driver core does not call
remove() when probe() fails: really_probe() reaches probe_failed below
the device_remove() call and goes straight to releasing the device's
managed resources.
ac100_rtc_probe() ends with
return devm_rtc_register_device(chip->rtc);
so if that fails after the clocks have been registered, the provider is
left on the global of_clk_providers list holding chip->clk_data, which
was allocated with devm_kzalloc() and is freed while probe() unwinds. A
later lookup on this device tree node then reads freed memory in
of_clk_hw_onecell_get(). Consumers that do exactly that exist in tree:
the wifi power sequence nodes on sun8i-a83t-bananapi-m3 and
sun8i-a83t-cubietruck-plus take <&ac100_rtc 1>, and the sun9i-a80 boards
route osc32k through <&ac100_rtc 0>. The window is narrow, as
devm_rtc_register_device() can only fail with -ENOMEM here, but the
provider is left dangling whenever it does.
The RTC-32k clock is leaked on the same path. Since clk_core_lookup()
searches a global list that is not scoped per device, __clk_register()
rejects the duplicate name with -EEXIST, so the leak also makes a later
probe of the same device fail.
The error path that returns -EINVAL when the ADDA 4M parent clock cannot
be found leaks the RTC-32k clock in the same way. No provider has been
registered at that point, so that one is a leak rather than a
use-after-free.
Register both with devm_clk_hw_register_fixed_rate() and
devm_of_clk_add_hw_provider() so that they are released whenever the
device goes away, on a failed probe as well as on unbind. Devres
releases in reverse order of acquisition, so the provider is removed
before chip->clk_data is freed, and the clkout children are now
unregistered before their parent rather than after it.
ac100_rtc_unregister_clks() and the remove callback then have nothing
left to do and are removed. |
| In the Linux kernel, the following vulnerability has been resolved:
netfs: zero gaps in read-gaps folio to avoid writing back stale data
netfs_read_gaps() leaves gaps around a streaming write's dirty region
unread on the server side, so a short/EOF response there left stale
folio content that later got written back.
Zero it after the read completes, not before: netfs_wait_for_read()
returns rreq->transferred once ret >= 0, so build an iterator over the
same bvec array the read used, advance past ret, and zero the rest.
The dirty region already maps to sink pages in that array rather than
the real folio, so this can't touch it, and only the actual shortfall
gets zeroed instead of the whole gap upfront. |
| In the Linux kernel, the following vulnerability has been resolved:
mptcp: options: fix uninit-value in mptcp_write_data_fin
When sending a DATA_FIN without data, and because the DATA_FIN occupies
1 octet of the connection-level sequence space [1], it is then required
to add a DSS mapping with specific values.
If the checksum has been negotiated, it also needs to be computed, and
included in the outgoing packet, and thus the initial csum data needs to
be reset to 0 as well. This is no longer the case since commit
cfcceb7a39fc ("tcp: shrink per-packet memset in __tcp_transmit_skb()"),
because the whole ext_copy structure is no longer zeroed by default.
This seems to be the only case where use_map is changed and set
afterwards, so initialising the csum field only in this case, along with
other fields for this specific case. |
| In the Linux kernel, the following vulnerability has been resolved:
nvme: fix command effects log lifetime for multipath heads
KASAN reported a use-after-free when an I/O passthrough command was sent
through a multipath namespace head after the controller path that first
created the head had been removed:
BUG: KASAN: slab-use-after-free in nvme_command_effects+0x192/0x200 [nvme_core]
Read of size 4 at addr ffff888141b14400 by task nvme/19811
nvme_command_effects+0x192/0x200 [nvme_core]
nvme_cmd_allowed+0x7e/0x1b0 [nvme_core]
nvme_user_cmd.constprop.0+0x1b5/0x450 [nvme_core]
nvme_ns_head_chr_ioctl+0xf4/0x2a0 [nvme_core]
Move the log cache to the subsystem, with one entry per command set. Both
controllers and namespace heads hold subsystem references, keeping their
log pointers valid until subsystem release. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k: reject short WMI command responses
ath9k_wmi_rsp_callback() removes the validated WMI header and copies
the number of bytes expected by the waiting command into its response
buffer. A device response shorter than that expectation can therefore
be read beyond the skb payload.
Record -EMSGSIZE for a short response, complete the waiter, and return
the stored status from the command path. This also prevents callers from
consuming stale response bytes as a successful reply. |
| In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: fix rx Scatter-Gather support
When a received frame is larger than dma_buf_sz, the DMA scatters it
across multiple RX descriptors (rx Scatter-Gather). The secondary RX
buffer (sec_page) was only allocated and programmed when split-header
(SPH) was active, so for regular frames buffer2 was neither allocated
nor backed by a valid mapping. As soon as an incoming frame overflowed
buffer1, the DMA wrote the overflow into the unmapped secondary-buffer
address, triggering an SMMU translation fault on IOMMU-based platforms:
arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x00000000, fsynr=0x7f0011, cbfrsynra=0x1c90, cb=11
arm-smmu 15000000.iommu: FSR = 00000402 [Format=2 TF], SID=0x1c90
arm-smmu 15000000.iommu: FSYNR0 = 007f0011 [S1CBNDX=127 WNR PLVL=1]
Enable scatter-gather for non-SPH frames on cores that can program an
independent secondary RX buffer (GMAC4/XGMAC): allocate and mark buffer2
as valid in stmmac_init_rx_buffers() and stmmac_rx_refill(), and account
for it in the buffer length computation. Legacy cores have no set_sec_addr
op, so they keep buffer2 disabled.
Since buffer2 is handed to the DMA at page offset 0, the page pool sync
window is widened to cover both buffers in every mode: offset is set to 0
and max_len to dma_buf_sz + stmmac_rx_offset().
The FCS can straddle the buffer1/buffer2 boundary and a descriptor
boundary, so it is now stripped from the tail of the assembled frame with
pskb_trim() instead of from a single buffer, avoiding an unsigned underflow
for frames that overflow a buffer by 1..3 bytes. For single-buffer frames
the XDP program must not see the FCS, so it is removed from the XDP buffer
before the program runs.
Native XDP currently only supports single-buffer (linear) frames. An
oversized frame accepted by the MAC (jumbo enabled) is received via
buffer2; the XDP program only sees buffer1, so on a TX/REDIRECT verdict
the frame is forwarded truncated. XDP multi-buffer support to handle
this case is planned as a follow-up.
AF_XDP zero-copy RX is not covered by this change: a ZC queue still
programs buffer2 at DMA address 0 (and XGMAC has no buffer2-valid bit),
so an oversized frame overflowing buffer1 can still trigger the same
SMMU translation fault. Handling is planned as a follow-up. |
| In the Linux kernel, the following vulnerability has been resolved:
block: reject polled dio with user integrity metadata
IOCB_HAS_METADATA leaves iocb->private as a uio_meta, while
iocb_bio_iopoll() expects a bio. Since 2729a60bbfb9, metadata I/O
always uses __blkdev_direct_IO(), which never publishes the bio for
polling, so IOPOLL calls bio_poll() on the uio_meta.
Reproducer: io_uring IOPOLL plus a PI attribute on an integrity device
(scsi_debug dif=1 dix=1). KASAN reports:
Oops: general protection fault, probably for non-canonical
address 0xdffffc0000000004
KASAN: null-ptr-deref in range
[0x0000000000000020-0x0000000000000027]
RIP: 0010:bio_poll+0x9d/0x4b0
Call Trace:
iocb_bio_iopoll+0x5b/0x80
io_uring_classic_poll+0xf3/0x140
io_do_iopoll+0x4e3/0xc00
io_iopoll_check+0x275/0x560
__do_sys_io_uring_enter+0x2e5/0x720
Return -EOPNOTSUPP when HIPRI is combined with user metadata. |
| In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix AF_XDP TX timestamp teardown NULL dereference
During XSK TX queue teardown, outstanding descriptors are completed
without a CQE. If one requested a TX timestamp, the completion path
passes that NULL CQE to mlx5e_xsk_fill_timestamp(), which dereferences
it.
Return zero when no CQE is available, indicating that teardown did not
produce a TX timestamp. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfnetlink_queue: hold nfnl mutex in event notifier
We must serialize the release notifier and the config netlink function.
A concurrent thread can issue close() which can call the release function
while unrelated socket processes UNBIND request for same portid:
Oops: general protection fault, [..]
RIP: 0010:__instance_destroy+0x60/0x210 [nfnetlink_queue]
Call Trace:
nfqnl_recv_config+0x9b0/0xdc0 [nfnetlink_queue]
nfnetlink_rcv_msg+0x7c2/0xeb0
? __pfx_nfnetlink_rcv_msg+0x10/0x10
After this, parallel UNBIND and URELEASE events are impossible.
This change isn't nice, but its the shortest fix given instances
are not refcounted and the nfnetlink config callback drops the
rcu read lock early due to need for sleeping allocations. |
| In the Linux kernel, the following vulnerability has been resolved:
octeontx2-pf: Fix aura BPID assignment when CONFIG_DCB is enabled
Previously, BPID assignment under CONFIG_DCB assumed
`queue_to_pfc_map` was always initialized. For SDP VFs this leads to
invalid memory access as it was not initialized.
This patch adds a NULL check for `queue_to_pfc_map` before
dereferencing it. Also, simplifies the logic by always assigning a
default BPID first, then conditionally overriding it if CONFIG_DCB is
enabled and the map exists. |
