| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
ntfs: bound the look-ahead attribute-list entry in ntfs_external_attr_find()
When resolving an attribute lookup with a non-zero @lowest_vcn,
ntfs_external_attr_find() peeks at the next $ATTRIBUTE_LIST entry to
decide whether to keep searching, but bounds that not-yet-validated
entry only with "(u8 *)next_al_entry + 6 < al_end" (which proves just
bytes 0..6 are in range) and "(u8 *)next_al_entry + length <= al_end"
with an attacker-controlled, non-8-aligned length. It then reads
next_al_entry->lowest_vcn (an __le64 at offset 8) and the name at
next_al_entry->name_offset, both of which can lie past al_end -- the
exact end of the kvmalloc'd attribute-list buffer (allocated at the
on-disk attr_list_size, no rounding). A crafted on-disk $ATTRIBUTE_LIST
whose last entry sits a few bytes before al_end therefore yields a slab
out-of-bounds read when the inode is read.
Validate the look-ahead entry with ntfs_attr_list_entry_is_valid() (added
in patch 1/3) before dereferencing lowest_vcn and the name, so the same
fixed-header, length and name bounds the main attribute-list walk uses now
guard this read too. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Disable xfrm_decode_session hook attachment
BPF LSM programs can currently attach to xfrm_decode_session(). That
hook may return an error, but security_skb_classify_flow() calls it
from a void path and triggers BUG_ON() if an error is returned.
Disable BPF attachment to the hook to prevent a BPF LSM program from
turning packet classification into a full panic. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_expect: use conntrack GC to reap expectations
This patch replaces the timer API by GC worker approach for
expectations, as it already happened in many other subsystems.
Use the existing conntrack GC worker to iterate over the local list of
expectations in the master conntrack to reap expired expectations.
Check IPS_HELPER_BIT to run GC for expectations, set it on for nft_ct
expectation which nevers sets it. Hold the expectation spinlock while
iterating over the master conntrack expectation list to synchronize with
nf_ct_remove_expectations(). This also performs runtime packet path
garbage collection through the expectation insertion and lookup
functions while walking over one of the chains of the global expectation
hashtables. Unconfirmed conntrack entries are skipped since ct->ext can
be reallocated and dying are skipped since those will be gone soon.
Set on IPS_HELPER_BIT if the helper ct extension is added, then the new
GC worker does not need to bump the ct refcount to check if the ct->ext
helper is available.
This removes the extra bump on the refcount for expectation timers, this
allows to remove several nf_ct_expect_put() calls after the unlink,
after this update only refcount remains at 1 while on the expectation
hashes.
This patch implicitly addresses a race with the existing timer API
allowing an expectation to access a stale exp->master pointer which has
been already released when expectation removal loses races with an
expiring timer, ie. timer_del() reporting false.
Add a new NF_CT_EXPECT_DEAD flag to reap this expectation via GC. This
is needed by nf_conntrack_unexpect_related() which is called in error
paths to invalidate newly created expectations that has been added into
the hashes. These expectactions cannot be inmediately released as GC or
nf_ct_remove_expectations() could race to make it. On expectation
insert, the runtime GC reaps stale expectations before checking the
expectation limit set by policy.
Set current timestamp in nf_ct_expect_alloc(), then add the expectation
policy timeout (or custom timeout specified added on top of this) to
specify the expectation lifetime. |
| In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: LAG, MPESW, Fix missing complete() on devcom error
mlx5_mpesw_work() returned without calling complete() when
mlx5_lag_get_devcom_comp() returned NULL. A caller that queued the
work and waited on mpesww->comp would block indefinitely.
Funnel the early-return path through a new "complete" label so the
waiter is always woken. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: sco: Fix a race condition in sco_sock_timeout()
sco_sock_timeout() runs asynchronously and lock_sock(sk). If the socket
is closing while the timer is running, it holds the same lock
(lock_sock(sk)) twice, leading to a deadlock.
CPU 0 CPU 1
==================== ======================
sco_sock_close()
sco_sock_timeout()
lock_sock(sk) // <-- LOCK
__sco_sock_close()
sco_chan_del()
sco_conn_put()
sco_conn_free()
disable_delayed_work_sync()
lock(sk) // <-- SAME LOCK
Fix this by moving disable_delayed_work_sync() outside of lock_sock(sk),
ensuring that no lock_sock(sk) is held before sco_sock_timeout().
Lockdep splat:
WARNING: possible circular locking dependency detected
6.13.0-rc4 #7 Not tainted
syz-executor292/9514 is trying to acquire lock:
ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_lock_acquire sect/v6.13-rc4/./include/linux/rcupdate.h:337 [inline]
ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: rcu_read_lock sect/v6.13-rc4/./include/linux/rcupdate.h:849 [inline]
ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4137 [inline]
ffff8881115d5070 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}, at: __flush_work+0xd1/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195
but task is already holding lock:
ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline]
ffff88807db3a258 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: sco_sock_close+0x25/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:524
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}:
lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849
lock_sock_nested+0x48/0x130 sect/v6.13-rc4/net/core/sock.c:3622
lock_sock sect/v6.13-rc4/./include/net/sock.h:1623 [inline]
sco_sock_timeout+0xbe/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:158
process_one_work sect/v6.13-rc4/kernel/workqueue.c:3229 [inline]
process_scheduled_works+0xa99/0x18f0 sect/v6.13-rc4/kernel/workqueue.c:3310
worker_thread+0x8a9/0xd80 sect/v6.13-rc4/kernel/workqueue.c:3391
kthread+0x2c6/0x360 sect/v6.13-rc4/kernel/kthread.c:389
ret_from_fork+0x4e/0x80 sect/v6.13-rc4/arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 sect/v6.13-rc4/arch/x86/entry/entry_64.S:244
-> #0 ((work_completion)(&(&conn->timeout_work)->work)){+.+.}-{0:0}:
check_prev_add sect/v6.13-rc4/kernel/locking/lockdep.c:3161 [inline]
check_prevs_add sect/v6.13-rc4/kernel/locking/lockdep.c:3280 [inline]
validate_chain+0x1888/0x5760 sect/v6.13-rc4/kernel/locking/lockdep.c:3904
__lock_acquire+0x13b4/0x2120 sect/v6.13-rc4/kernel/locking/lockdep.c:5226
lock_acquire+0x1c4/0x520 sect/v6.13-rc4/kernel/locking/lockdep.c:5849
touch_work_lockdep_map sect/v6.13-rc4/kernel/workqueue.c:3909 [inline]
start_flush_work sect/v6.13-rc4/kernel/workqueue.c:4163 [inline]
__flush_work+0x70f/0xc40 sect/v6.13-rc4/kernel/workqueue.c:4195
__cancel_work_sync sect/v6.13-rc4/kernel/workqueue.c:4351 [inline]
disable_delayed_work_sync+0xbb/0xf0 sect/v6.13-rc4/kernel/workqueue.c:4514
sco_conn_free sect/v6.13-rc4/net/bluetooth/sco.c:95 [inline]
kref_put sect/v6.13-rc4/./include/linux/kref.h:65 [inline]
sco_conn_put+0x18f/0x270 sect/v6.13-rc4/net/bluetooth/sco.c:107
sco_chan_del+0xe2/0x210 sect/v6.13-rc4/net/bluetooth/sco.c:236
sco_sock_close+0x8f/0x100 sect/v6.13-rc4/net/bluetooth/sco.c:526
sco_sock_release+0x62/0x2d0 sect/v6.13-rc4/net/blueto
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: nv: Inject SEA if kvm_translate_vncr() can't resolve PFN
kvm_handle_vncr_abort() assumes that s1_walk_result conveys an abort
when kvm_translate_vncr() returns -EFAULT. This is not always the case
as it's possible to encounter 'late' failures on the output of S1
translation, e.g. a GFN outside of the memslots.
Fix it by preparing an external abort before returning from
kvm_translate_vncr(). Get rid of the BUG_ON() in the fault injection
path while at it. |
| In the Linux kernel, the following vulnerability has been resolved:
tools/power/x86/intel-speed-select: Harden daemon pidfile open
Avoid symlink-based pidfile clobbering by opening the pidfile with
O_NOFOLLOW and validating it with fstat() before locking/writing.
The daemon currently uses a fixed pidfile path under /tmp. A local
unprivileged user can pre-create a symlink at that path and cause a
root-run daemon instance to write into an attacker-chosen file. |
| In the Linux kernel, the following vulnerability has been resolved:
cxl: Fix CXL_HEADERLOG_SIZE to match RAS Capability size
The CXL r4.0 8.2.4.17.7 RAS Capability Structure has total length 0x58
bytes (CXL_RAS_CAPABILITY_LENGTH); the Header Log occupies the trailing
64 bytes at offset 0x18. CXL_HEADERLOG_SIZE was defined as SZ_512,
eight times the actual on-device size.
header_log_copy() reads CXL_HEADERLOG_SIZE_U32 (128) dwords from the
RAS capability iomap, overrunning the 88-byte mapping by 448 bytes.
The cxl_aer_uncorrectable_error trace event memcpy()s CXL_HEADERLOG_SIZE
(512) bytes from its source. For the CPER caller the source is
struct cxl_ras_capability_regs::header_log[16] (64 bytes) embedded in a
stack-local cxl_cper_prot_err_work_data, so the memcpy reads 448 bytes
of kernel stack into the trace event ring buffer where userspace can
read it via tracefs.
Set CXL_HEADERLOG_SIZE to 64 and derive CXL_HEADERLOG_SIZE_U32 from it,
bringing all iomap readers into agreement on 16 dwords. Userspace tools
such as rasdaemon have grown a dependency on the buggy 512-byte (128 u32)
header_log layout in the cxl_aer_uncorrectable_error trace event. Add
CXL_HEADERLOG_TRACE_SIZE_U32 = 128 and use it for the trace event
__array and its memcpy to preserve that ABI. Both callers now pass a
zero-filled u32[CXL_HEADERLOG_TRACE_SIZE_U32] staging buffer with only
the first CXL_HEADERLOG_SIZE_U32 (16) entries populated from hardware;
the remaining 112 u32s are zero-padded, keeping the 512-byte trace ring
buffer layout intact.
[ dj: Replaced 64 with SZ_64 per RichardC ] |
| In the Linux kernel, the following vulnerability has been resolved:
ufs: core: tracing: Do not dereference pointers in TP_printk()
The trace events in drivers/ufs/core/ufs_trace.h were converted to take a
pointer to the hba structure as an argument for the tracepoint and then in
TP_printk() the printing of the dev_name from the ring buffer was
converted to using the dev dereferenced pointer from the hba saved
pointer.
This is not allowed as the TP_printk() is executed at the time the trace
event is read from /sys/kernel/tracing/trace file. That can happen
literally, seconds, minutes, hours, weeks, days, or even months later!
There is no guarantee that the hba pointer will still exist by the time it
is dereferenced when the "trace" file is read.
Instead, save the device name from the hba pointer at the time the
tracepoint is called and place it into the ring buffer event. Then the
TP_printk() can read the name directly from the ring buffer and remove the
possibility that it will read a freed pointer and crash the kernel.
This was detected when testing the trace event code that looks for
TP_printk() parameters doing illegal derferences[1]
[1] https://lore.kernel.org/all/20260630184836.74d477b6@gandalf.local.home/ |
| In the Linux kernel, the following vulnerability has been resolved:
hwmon: (occ) unregister sysfs devices outside occ lock
occ_active(false) and occ_shutdown() unregister sysfs-backed devices while
occ->lock is held. hwmon_device_unregister() and sysfs_remove_group() can
wait for active sysfs callbacks to drain, and those callbacks can enter the
OCC update path and try to take occ->lock again. That gives the unregister
paths the lock ordering occ->lock -> sysfs callback drain, while a callback
has the opposite edge sysfs callback -> occ->lock.
This issue was found by our static analysis tool and then manually
reviewed against the current tree.
The grounded PoC kept the real unregister and callback carrier:
occ_shutdown()
hwmon_device_unregister()
occ_show_temp_1()
occ_update_response()
Lockdep reported the circular dependency with occ_shutdown() already
holding the OCC mutex and hwmon_device_unregister() waiting on the sysfs
side:
WARNING: possible circular locking dependency detected
... (sysfs_lock) ... at: hwmon_device_unregister+0x12/0x30 [vuln_msv]
... (&test_occ.lock) ... at: occ_shutdown.constprop.0+0xe/0x40 [vuln_msv]
occ_update_response.isra.0+0xb/0x20 [vuln_msv]
occ_show_temp_1.constprop.0.isra.0+0x23/0x40 [vuln_msv]
*** DEADLOCK ***
Serialize hwmon registration and removal with a separate hwmon_lock.
Under that lock, detach occ->hwmon and update occ->active while occ->lock
is held so concurrent OCC state changes still see a stable state, then
drop occ->lock before calling hwmon_device_unregister(). Remove the
driver sysfs group before taking occ->lock in occ_shutdown(), so draining
the driver attributes cannot wait while the OCC mutex is held. Also make
OCC update callbacks return -ENODEV after deactivation, so callbacks that
already passed sysfs active protection do not poll the hardware after
teardown has detached the hwmon device. |
| In the Linux kernel, the following vulnerability has been resolved:
mmc: vub300: defer reset until cmd_mutex is unlocked
vub300_cmndwork_thread() holds cmd_mutex while it sends a command and
waits for the command response. If the response wait times out,
__vub300_command_response() kills the command URBs and then synchronously
resets the USB device through usb_reset_device().
That reset path re-enters the driver through vub300_pre_reset(), which
also takes cmd_mutex. The worker therefore tries to acquire the same
mutex recursively while it is still holding it from the command path.
This issue was found by our static analysis tool and then manually
reviewed against the current tree.
The grounded PoC kept the real worker and timeout/reset carrier:
vub300_cmndwork_thread()
__vub300_command_response()
usb_lock_device_for_reset()
usb_reset_device()
vub300_pre_reset()
Lockdep reported the same-task recursive acquisition on cmd_mutex:
WARNING: possible recursive locking detected
... (&test_vub300.cmd_mutex) ... at: usb_reset_device... [vuln_msv]
... (&test_vub300.cmd_mutex) ... at: vub300_cmndwork_thread+0x12/0x20 [vuln_msv]
Workqueue: vub300_cmd_wq vub300_cmndwork_thread [vuln_msv]
*** DEADLOCK ***
Return a flag from __vub300_command_response() when the timeout path needs
a device reset, then perform the reset after vub300_cmndwork_thread() has
cleared the in-flight command state and dropped cmd_mutex. The reset is
still attempted before mmc_request_done(), preserving the existing request
completion ordering while avoiding the recursive lock. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/rockchip: dw_dp: Fix null-ptr-deref in dw_dp_remove()
Attempting to access driver data in the platform driver ->remove()
callback may lead to a null pointer dereference since there is no
guaranty that the component ->bind() callback invoking
platform_set_drvdata() was executed.
A common scenario is when Rockchip DRM driver didn't manage to run
component_bind_all() because of an (unrelated) error causing early
return from rockchip_drm_bind().
Drop the unnecessary call to platform_get_drvdata() and, instead,
reference the target device structure via platform_device. |
| In the Linux kernel, the following vulnerability has been resolved:
accel/amdxdna: Guard management mailbox channel cleanup against NULL pointer
The management mailbox channel cleanup helpers can be called from
error handling paths when mgmt_chann has already been destroyed.
Add NULL checks to xdna_mailbox_free_channel() and
xdna_mailbox_stop_channel() so the cleanup path safely returns instead
of dereferencing a NULL mailbox channel pointer. |
| In the Linux kernel, the following vulnerability has been resolved:
hfsplus: Add a sanity check for btree node size
Syzbot reported an uninit-value bug in [1] with a corrupted HFS+ image,
during the file system mounting process, specifically while loading the
catalog, a corrupted node_size value of 1 caused the rec_off argument
passed to hfs_bnode_read_u16() (within hfs_bnode_find()) to be excessively
large. Consequently, the function failed to return a valid value to
initialize the off variable, triggering the bug [1].
Every node starts from BTree node descriptor: struct hfs_bnode_desc.
So, the size of node cannot be lesser than that. However, technical
specification declares that: "The node size (which is expressed in bytes)
must be power of two, from 512 through 32,768, inclusive." Add a check
for btree node size base on technical specification.
[1]
BUG: KMSAN: uninit-value in hfsplus_bnode_find+0x141c/0x1600 fs/hfsplus/bnode.c:584
hfsplus_bnode_find+0x141c/0x1600 fs/hfsplus/bnode.c:584
hfsplus_btree_open+0x169a/0x1e40 fs/hfsplus/btree.c:382
hfsplus_fill_super+0x111f/0x2770 fs/hfsplus/super.c:553
get_tree_bdev_flags+0x6e6/0x920 fs/super.c:1694
get_tree_bdev+0x38/0x50 fs/super.c:1717
hfsplus_get_tree+0x35/0x40 fs/hfsplus/super.c:709
vfs_get_tree+0xb3/0x5d0 fs/super.c:1754
fc_mount fs/namespace.c:1193 [inline] |
| In the Linux kernel, the following vulnerability has been resolved:
soc: xilinx: Fix race condition in event registration
The zynqmp_power driver registers handlers for suspend and subsystem
restart events using register_event(). However, the work structures
(zynqmp_pm_init_suspend_work and zynqmp_pm_init_restart_work) used by
these handlers were allocated and initialized after the registration
call.
This created a race window where, if the firmware triggered an event
immediately after registration but before allocation, the callback
(suspend_event_callback or subsystem_restart_event_callback) would
dereference a NULL pointer in work_pending(), leading to a crash.
Fix this by allocating and initializing the work structures before
registering the events. |
| In the Linux kernel, the following vulnerability has been resolved:
soc: xilinx: Shutdown and free rx mailbox channel
A mbox rx channel is requested using mbox_request_channel_byname() in
probe. In remove callback, the rx mailbox channel is cleaned up when the
rx_chan is NULL due to incorrect condition check. The mailbox channel is
not shutdown and it can receive messages even after the device removal.
This leads to use after free. Also the channel resources are not freed.
Fix this by checking the rx_chan correctly. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: hisi_sas: Add slave_destroy interface for v3 hw
WARNING is triggered when executing link reset of remote PHY and rmmod
SAS driver simultaneously. Following is the WARNING log:
WARNING: CPU: 61 PID: 21818 at drivers/base/core.c:1347 __device_links_no_driver+0xb4/0xc0
Call trace:
__device_links_no_driver+0xb4/0xc0
device_links_driver_cleanup+0xb0/0xfc
__device_release_driver+0x198/0x23c
device_release_driver+0x38/0x50
bus_remove_device+0x130/0x140
device_del+0x184/0x434
__scsi_remove_device+0x118/0x150
scsi_remove_target+0x1bc/0x240
sas_rphy_remove+0x90/0x94
sas_rphy_delete+0x24/0x3c
sas_destruct_devices+0x64/0xa0 [libsas]
sas_revalidate_domain+0xe4/0x150 [libsas]
process_one_work+0x1e0/0x46c
worker_thread+0x15c/0x464
kthread+0x160/0x170
ret_from_fork+0x10/0x20
---[ end trace 71e059eb58f85d4a ]---
During SAS phy up, link->status is set to DL_STATE_AVAILABLE in
device_links_driver_bound, then this setting influences
__device_links_no_driver() before driver rmmod and caused WARNING.
Add the slave_destroy interface to make sure link is removed after flush
workque. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: ccp/sev-dev-tsm - bail out early when pdev->bus is NULL
dsm_create() initially checks pdev->bus when computing segment_id:
u8 segment_id = pdev->bus ? pci_domain_nr(pdev->bus) : 0;
But the next two lines unconditionally dereference pdev->bus via
pcie_find_root_port() and especially pci_dev_id(pdev), which expands
to PCI_DEVID(dev->bus->number, dev->devfn). If pdev->bus is in fact
NULL, segment_id is initialised to 0 but the very next statement
crashes the kernel.
smatch flags this:
drivers/crypto/ccp/sev-dev-tsm.c:253 dsm_create() error: we
previously assumed 'pdev->bus' could be null (see line 251)
Make the NULL handling consistent: if pdev->bus is NULL the device
has no PCI context to work with and SEV TIO setup cannot proceed,
so return -ENODEV before any of the bus-dependent lookups. The
remaining initialisation now runs only on the path where pdev->bus
is known to be valid.
No change for callers where pdev->bus is non-NULL, which is the
only case where dsm_create() did meaningful work before this change. |
| In the Linux kernel, the following vulnerability has been resolved:
media: atomisp: gc2235: fix UAF and memory leak
gc2235_probe() handles its error paths incorrectly.
If media_entity_pads_init() fails, gc2235_remove() is called, which
tears down the subdev and frees dev, but then still falls through to
atomisp_register_i2c_module(). This results in use-after-free.
If atomisp_register_i2c_module() fails, the media entity and control
handler are left initialized and dev is leaked.
gc2235_remove() unconditionally calls media_entity_cleanup() and
v4l2_ctrl_handler_free(), but these are not initialized at every
error path in gc2235_probe().
Replace gc2235_remove() calls in the probe error paths with explicit
unwind labels that free only the resources initialized at each point
of failure, in reverse order of initialization. |
| In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Fix OOB in scmi_power_name_get()
scmi_power_name_get() does not validate the domain number passed by the
external caller, which may lead to an out-of-bounds access.
Fix this by returning "unknown" for invalid domains, like
scmi_reset_name_get() does. |
