gpio: mt7621: be sure IRQ domain is created before exposing GPIO chips
Function 'mediatek_gpio_bank_probe()' registers three GPIO chips using
'devm_gpiochip_add_data()'. At this point, the chips become live and visible
to consumers. However, the IRQ domain isn't allocated and set up until
'mt7621_gpio_irq_setup()' is called after the GPIO chips setup finishes.
If a consumer requests a GPIO IRQ concurrently 'mt7621_gpio_to_irq()' can
be called and pass a NULL irq domain pointer irq_create_mapping(), that can
corrupt the mappings or cause a crash. Fix this possible problem seting up
irq domain before GPIO chips setup is performed.
gpio: mt7621: more robust management of IRQ domain teardown
The driver uses devm_gpiochip_add_data() to register the GPIO chips which
means the devres subsystem will unregister them only after the function
'mt7621_gpio_remove()' returns. During the window between domain destruction
and devres unregistering the GPIO chips, the chips are still fully active.
If a consumer or userspace invokes gpiod_to_irq() during this window,
'mt7621_gpio_to_irq()' can dereference the already-freed irq domain pointer.
Thus, manage the IRQ domain teardown using 'devm_add_action_or_reset()' to
guarantee it is destroyed strictly after the GPIO chips are removed.
gpio: mt7621: avoid corruption of shared interrupt trigger state
The bank-shared fields like 'rising' and 'falling' are modified using
non-atomic read-modify-write operations. Since every gpio chip instance
represents an entire bank of 32 pins, if 'mediatek_gpio_irq_type()' is
called concurrently for different IRQs on the same bank a possible overwrite
of each other's configuration is possible. Thus, protect this state with
'gpio_generic_lock_irqsave' lock in the same way it is handled in irp_chip
'mediatek_gpio_irq_mask()' and 'mediatek_gpio_irq_unmask()' callbacks.
Matt Bobrowski [Sun, 28 Jun 2026 20:11:03 +0000 (20:11 +0000)]
bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is uninitialized
When CONFIG_BPF_LSM=y is set, BPF inode storage maps
(BPF_MAP_TYPE_INODE_STORAGE) are compiled into the kernel. However,
if the BPF LSM is not explicitly enabled at boot time (e.g. omitted
from the "lsm=" boot parameter), lsm_prepare() is never executed for
the BPF LSM.
Consequently, the BPF inode security blob offset
(bpf_lsm_blob_sizes.lbs_inode) is never initialized and remains at
its default compiled size of 8 bytes instead of being updated to a
valid offset past the reserved struct rcu_head (typically 16 bytes
or more).
When a privileged user creates and updates a BPF_MAP_TYPE_INODE_STORAGE
map, bpf_inode() evaluates inode->i_security + 8. This erroneously
aliases the struct rcu_head.func callback pointer at the beginning
of the inode->i_security blob. During subsequent map element cleanup
or inode destruction, writing NULL to owner_storage clears the queued
RCU callback pointer. When rcu_do_batch() later executes the queued
callback, it attempts an instruction fetch at address 0x0, triggering
an immediate kernel panic.
Fix this by introducing a global bpf_lsm_initialized boolean flag
marked with __ro_after_init. Set this flag to true inside bpf_lsm_init()
when the LSM framework successfully registers the BPF LSM. Gate map
allocation in inode_storage_map_alloc() on this flag, returning
-EOPNOTSUPP if the BPF LSM is in turn uninitialized.
This fail-fast approach prevents userspace from allocating inode
storage maps when the supporting BPF LSM infrastructure is absent,
avoiding zombie map states.
Fixes: 8ea636848aca ("bpf: Implement bpf_local_storage for inodes") Reported-by: oxsignal <awo@kakao.com> Signed-off-by: Matt Bobrowski <mattbobrowski@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Reviewed-by: Amery Hung <ameryhung@gmail.com> Link: https://lore.kernel.org/bpf/20260628201103.3624525-1-mattbobrowski@google.com
Boris Brezillon [Thu, 25 Jun 2026 12:40:37 +0000 (14:40 +0200)]
drm/panthor: Keep interrupts masked until they are needed
The autogenerated panthor_request_xx_irq() helpers unmask Mali
interrupts before we're sure we'll have a handler registered. For
non-shared IRQ lines, that's fine, but for shared ones, it might cause
an interrupt flood if the HW block raises an interrupt for any reason.
We could reworking the calls in panthor_request_xx_irq(), but it's just
simpler to let the caller decide when they are ready to handle interrupts
and call panthor_pwr_irq_resume() themselves. While at it, rework the
prototype to let users call panthor_pwr_irq_enable_events() explicitly
instead of passing an initial mask to panthor_request_pwr_irq().
Boris Brezillon [Thu, 25 Jun 2026 12:40:36 +0000 (14:40 +0200)]
drm/panthor: Interrupt group start/resumption if group_bind_locked() fails
group_bind_locked() can fail if the MMU block is stuck. This is normally
a reset situation, but by the time we reset the GPU, we might have
tried to resume a group that's not resident, which will probably trip
out the FW. So let's avoid that by bailing out when group_bind_locked()
returns an error. We don't even try to start more groups because the
GPU will be reset anyway.
Boris Brezillon [Thu, 25 Jun 2026 12:40:33 +0000 (14:40 +0200)]
drm/panthor: Fix panthor_pwr_unplug()
We can't call panthor_pwr_irq_suspend() if the device is suspended,
or this leads to a hang when the IOMEM region is accessed while the
clks are disabled. Do what other sub-components do and conditionally
call panthor_pwr_irq_suspend() if we know the PWR regbank block is
accessible.
Fixes: c27787f2b77f ("drm/panthor: Introduce panthor_pwr API and power control framework") Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-7-b67ed973fea6@collabora.com
Boris Brezillon [Thu, 25 Jun 2026 12:40:32 +0000 (14:40 +0200)]
drm/panthor: Don't overrule pending immediate ticks in sched_resume_tick()
We schedule immediate ticks when we need to process events on CSGs,
but those immediate ticks don't change the resched_target because we
want the other groups to stay scheduled for the remaining of the GPU
timeslot they were given. Make sure these immediate ticks don't get
overruled by a sched_queue_delayed_work() that would delay the tick
execution.
Fixes: 99820b4b7e50 ("drm/panthor: Make sure we resume the tick when new jobs are submitted") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260625-panthor-signal-from-irq-v4-0-3d2908912afa@collabora.com?part=9 Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Karunika Choo <karunika.choo@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-6-b67ed973fea6@collabora.com
Boris Brezillon [Thu, 25 Jun 2026 12:40:31 +0000 (14:40 +0200)]
drm/panthor: Fix theoretical IOMEM access in suspended state
In theory, our hardirq handler can be called while the device (and
thus the panthor_irq) is suspended, because the IRQ line is shared.
In practice though, in all the designs we've seen, the line is only
shared within the GPU, and because sub-component suspend state is
consistent (all-suspended or all-resumed), we shouldn't end up with
an interrupt triggered while we're suspended.
Fix the problem anyway, if nothing else, for our sanity.
Boris Brezillon [Thu, 25 Jun 2026 12:40:28 +0000 (14:40 +0200)]
drm/panthor: Keep the reset work disabled until everything is initialized
The reset work will sub-component reset helpers, which might not be
ready if the reset happens during initialization, leading to NULL
pointer dereferences or worse.
Avoid that by keeping the reset work disabled while we're initializing
those sub-components.
Boris Brezillon [Thu, 25 Jun 2026 12:40:27 +0000 (14:40 +0200)]
drm/panthor: Always use the IRQ-safe variant when acquiring the fence lock
Since dma_fence objects can be shared with other subsystems, they may be
accessed from hardirq context in those drivers, and we have to take
that into account by also using the IRQ-safe variant when acquiring
the lock.
drm/arm/komeda: fix error handling for clk_prepare_enable() and callers
komeda_dev_resume() calls clk_prepare_enable() without checking the
return value. If the clock fails to enable, the function returns 0
(success) while IRQs are enabled and IOMMU is connected on potentially
unclocked hardware, causing undefined behavior on resume.
Propagate the error from clk_prepare_enable() and fix all call sites
in komeda_drv.c that previously ignored the return value of
komeda_dev_resume():
- komeda_platform_probe(): if resume fails, jump to err_destroy_mdev
(skipping the suspend call, since the clock was never enabled)
- komeda_pm_resume(): propagate the error and skip
drm_mode_config_helper_resume() on failure
This issue was found by code review without access to Komeda hardware.
drm/arm/malidp: use clk_bulk API in runtime PM resume and suspend
malidp_runtime_pm_resume() calls clk_prepare_enable() three times
without checking the return value. If any clock fails to enable, the
driver silently proceeds with unclocked hardware, leading to undefined
behavior.
Convert both the resume and suspend paths to use the clk_bulk API:
clk_bulk_prepare_enable() in resume checks the return value and rolls
back any successfully enabled clocks on failure;
clk_bulk_disable_unprepare() in suspend keeps the two paths symmetric.
This issue was found by code review without access to Mali DP hardware.
Peiyang He [Tue, 30 Jun 2026 03:08:56 +0000 (11:08 +0800)]
ntfs: fix mrec_lock ABBA deadlock in rename
ntfs_file_fsync(), ntfs_dir_fsync() and __ntfs_write_inode() lock an
inode's mrec_lock before taking the mrec_lock of its parent directory.
ntfs_rename() takes old_ni->mrec_lock and old_dir_ni->mrec_lock
before taking new_ni->mrec_lock for an existing target, or
new_dir_ni->mrec_lock for a cross-directory rename.
This can deadlock when ntfs_file_fsync() or __ntfs_write_inode() holds
the target inode, or when ntfs_dir_fsync() holds a child target
directory, while rename() holds the parent directory and waits for the
target.
Fix this by locking the existing target inode before taking any parent
directory mrec_lock. For cross-directory renames where the target parent
is a descendant of the source parent, lock the target parent before the
source parent so the directory order matches the child-to-parent order used
by ntfs_file_fsync(), ntfs_dir_fsync(), and __ntfs_write_inode().
Cen Zhang [Sat, 27 Jun 2026 04:27:58 +0000 (12:27 +0800)]
ntfs: avoid stale runlist element dereference in fallocate
ntfs_attr_fallocate() allocates holes and delayed allocations inside
initialized size by looking up the current runlist element under
ni->runlist.lock. The returned struct runlist_element is only a borrowed
pointer into ni->runlist.rl. A writer can replace and free that array
after the read lock is dropped, so later reads of rl->lcn, rl->length and
rl->vcn can touch freed memory.
The buggy scenario involves two paths, with each column showing the order
within that path:
ntfs_attr_fallocate():
1. Take ni->runlist.lock for read.
2. Get rl from ntfs_attr_find_vcn_nolock().
3. Drop ni->runlist.lock.
4. Read rl->lcn, rl->length and rl->vcn.
mmap page_mkwrite:
1. Enter ntfs_filemap_page_mkwrite().
2. Reach __ntfs_write_iomap_begin() and ntfs_attr_map_cluster().
3. Merge allocation state with ntfs_runlists_merge().
4. Reallocate ni->runlist.rl in ntfs_rl_realloc(), freeing the old array.
Validation reproduced this kernel report:
BUG: KASAN: slab-use-after-free in ntfs_attr_fallocate+0xbb8/0xd00
Fix this by copying the needed runlist fields while the read lock is still
held and using only those scalar snapshots after unlocking.
After the snapshot, ntfs_attr_map_cluster() can also find that the range
is already mapped and return balloc=false. Only call ntfs_dio_zero_range()
when new clusters were allocated, matching the write iomap path and
preserving the zero-newly-allocated-holes behavior.
gpio: shared-proxy: always serialize with a sleeping mutex
The shared GPIO descriptor used either a mutex or a spinlock, chosen at
runtime from the underlying chip's can_sleep:
shared_desc->can_sleep = gpiod_cansleep(shared_desc->desc);
... if (can_sleep) mutex_lock(); else spin_lock_irqsave();
can_sleep describes only the value path (->get/->set). Under the same
lock, however, the proxy may call gpiod_set_config() and
gpiod_direction_*(), which can reach pinctrl paths that take a mutex
(e.g. gpiod_set_config() -> gpiochip_generic_config() ->
pinctrl_gpio_set_config()), independent of can_sleep. On a controller
with non-sleeping MMIO value ops the descriptor lock was a spinlock, so
the sleeping pinctrl call ran from atomic context. Reproduced on an
Amlogic A113X board with the workaround from commit 28f240683871
("pinctrl: meson: mark the GPIO controller as sleeping") reverted; the
original Khadas VIM3 report hit the same path:
BUG: sleeping function called from invalid context
__mutex_lock
pinctrl_get_device_gpio_range
pinctrl_gpio_set_config
gpiochip_generic_config
gpiod_set_config
gpio_shared_proxy_set_config <- voting spinlock held
...
mmc_pwrseq_simple_probe
The spinlock existed to take the value vote from atomic context, but the
vote and the (possibly sleeping) control operations share the same state
and lock, so this scheme cannot serialize config under a mutex and still
offer atomic value access. Always serialize the shared descriptor with a
mutex instead and mark the proxy a sleeping gpiochip, driving the
underlying GPIO through the cansleep value accessors: those are valid
for both sleeping and non-sleeping chips, so value access keeps working
on fast controllers, at the cost of no longer being atomic.
With every vote edge now driven through the cansleep value setter,
gpio_shared_proxy_set_unlocked() no longer needs a per-call setter: drop
its set_func callback and call gpiod_set_value_cansleep() directly. The
shared direction_output path reaches it only once the line is already an
output, so driving the value there is equivalent to re-issuing
gpiod_direction_output(), without the redundant per-edge re-assertion of
drive config and bias.
This is observable: consumers gating on gpiod_cansleep() take their
sleeping branch on a proxied GPIO (mmc-pwrseq-emmc skips its
emergency-restart reset handler; its normal reset is unaffected), and
consumers that reject sleeping GPIOs (pwm-gpio, ps2-gpio, ...) would
fail to probe. Such atomic users do not share a pin through the proxy,
whose purpose is voting on shared reset/enable lines. The same narrowing
already applies on Amlogic since that workaround, and rockchip
addressed the identical splat per-driver in commit 7ca497be0016 ("gpio:
rockchip: Stop calling pinctrl for set_direction"); fixing the proxy
addresses the locking error once, for every controller.
The lock type was added by commit a060b8c511ab ("gpiolib: implement
low-level, shared GPIO support"); the sleeping call under it arrived with
the proxy driver.
Ido Schimmel [Mon, 29 Jun 2026 07:21:17 +0000 (10:21 +0300)]
bridge: stp: Fix a potential use-after-free when deleting a bridge
The three STP timers are not supposed to be armed while the bridge is
administratively down. They are synchronously deactivated when the
bridge is put administratively down and the various call sites check for
'IFF_UP' before arming them.
This check is missing from br_topology_change_detection() and it is
possible to engineer a situation in which the topology change timer is
armed while the bridge is administratively down, resulting in a
use-after-free [1] when the bridge is deleted.
Fix by adding the missing check and for good measures synchronously
shutdown the three timers when the bridge is deleted.
[1]
ODEBUG: free active (active state 0) object: ffff88811662b9b0 object type: timer_list hint: br_topology_change_timer_expired (net/bridge/br_stp_timer.c:120)
WARNING: lib/debugobjects.c:629 at debug_print_object+0x1bc/0x450, CPU#9: ip/359
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Noam Rathaus <noamr@ssd-disclosure.com> Reported-by: Neil Young <contact@ssd-disclosure.com> Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260629072117.497959-1-idosch@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Bryam Vargas [Sun, 21 Jun 2026 02:43:34 +0000 (21:43 -0500)]
drm/virtio: bound EDID block reads to the response buffer
virtio_get_edid_block() validates the read offset only against the
device-supplied resp->size field, never against the fixed-size resp->edid
array. The EDID block index is driven by the device-supplied extension
count, so a malicious virtio-gpu backend can advertise a large size
together with a high block count and read far past the array into adjacent
kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds
read / info leak).
Also reject any read whose end exceeds the size of the edid array.
Conforming EDID responses stay within the array and are unaffected.
Jamal Hadi Salim [Sun, 28 Jun 2026 11:12:29 +0000 (07:12 -0400)]
net/sched: sch_teql: Introduce slaves_lock to avoid race condition and UAF
The teql master->slaves singly linked list is not protected against
multiple writes. It can be mod'ed concurently from teql_master_xmit(),
teql_dequeue(), teql_init() and teql_destroy() without holding any list
lock or RCU protection.
zdi-disclosures@trendmicro.com has demonstrated that the qdisc is freed
after an RCU grace period, but teql_master_xmit() running on another
CPU can still hold a stale pointer into the list, resulting in a
slab-use-after-free:
BUG: KASAN: slab-use-after-free in teql_master_xmit+0xf0f/0x16b0
Read of size 8 at addr ffff888013fb0440 by task poc/332
Freed 512-byte region [ffff888013fb0400, ffff888013fb0600) (kmalloc-512)
The fix?
Add a per-master slaves_lock spinlock that serializes all mutations of
master->slaves and the NEXT_SLAVE() links in teql_destroy() and
teql_qdisc_init(). teql_master_xmit() also takes the same slaves_lock
around those updates.
Annotate master->slaves and the per-slave ->next pointer with __rcu and
use the appropriate RCU accessors everywhere they are touched:
rcu_assign_pointer() on the writer side (under slaves_lock),
rcu_dereference_protected() for the writer-side loads (also under
slaves_lock), rcu_dereference_bh() for the loads in teql_master_xmit() and
rtnl_dereference() for the loads in teql_master_open()/teql_master_mtu(),
which run under RTNL.
Pair this with rcu_read_lock_bh()/rcu_read_unlock_bh() around the list
traversal in teql_master_xmit(), so that readers either observe a fully
linked list or are deferred until the in-flight mutation completes. The two
early-return paths in teql_master_xmit() are updated to release the RCU-bh
read-side critical section before returning, since leaving it held would
disable BH on that CPU for good.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: zdi-disclosures@trendmicro.com Tested-by: Victor Nogueira <victor@mojatatu.com> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com> Link: https://patch.msgid.link/20260628111229.669751-1-jhs@mojatatu.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Rosen Penev [Fri, 26 Jun 2026 22:52:28 +0000 (15:52 -0700)]
net: gianfar: dispose irq mappings on probe failure and device removal
irq_of_parse_and_map() creates irqdomain mappings that should be
balanced with irq_dispose_mapping(). The driver never called
irq_dispose_mapping(), leaking mappings on probe failure and
device removal.
Fix by adding irq_dispose_mapping() in free_gfar_dev() and
expanding its loop from priv->num_grps to MAXGROUPS so the
error path also catches partially-initialized groups. All
irqinfo pointers are pre-initialized to NULL in gfar_of_init(),
making the NULL-guarded walk in free_gfar_dev() safe for every
scenario.
gfar_parse_group() itself is left as a simple parse function
with no resource management; cleanup is centralized in the
caller's error path.
Assisted-by: opencode:big-pickle Fixes: b31a1d8b4151 ("gianfar: Convert gianfar to an of_platform_driver") Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20260626225228.427392-1-rosenp@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Andrea Righi [Fri, 26 Jun 2026 16:32:18 +0000 (18:32 +0200)]
net: lan743x: Initialize eth_syslock spinlock before use
lan743x_hardware_init() calls pci11x1x_strap_get_status() during the
PCI11x1x probe sequence. That helper acquires the Ethernet subsystem
hardware lock via lan743x_hs_syslock_acquire(), which relies on
adapter->eth_syslock_spinlock to serialize access.
The spinlock is currently initialized only after the strap status is
read. With CONFIG_DEBUG_SPINLOCK enabled, taking the zeroed initialized
spinlock can trip the spinlock debug check.
Fix by initializing adapter->eth_syslock_spinlock before reading the
strap status so the probe path never attempts to lock an uninitialized
spinlock.
Fixes: 46b777ad9a8c ("net: lan743x: Add support to SGMII 1G and 2.5G") Cc: stable@vger.kernel.org # v6.0+ Signed-off-by: Andrea Righi <arighi@nvidia.com> Reviewed-by: David Thompson <davthompson@nvidia.com> Reviewed-by: Thangaraj Samynathan<Thangaraj.s@microchip.com> Link: https://patch.msgid.link/20260626163218.3591486-1-arighi@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Shubham Nayak [Mon, 29 Jun 2026 13:34:55 +0000 (19:04 +0530)]
ALSA: hda/realtek: Add quirk for HP Victus 16-e0xxx (88EE) to enable mute LED
The mute LED on the HP Victus 16-e0xxx (board ID 88EE, ALC245 codec)
does not function by default. Add the ALC245_FIXUP_HP_MUTE_LED_COEFBIT
quirk to enable it. Tested on my HP Victus 16-e0xxx with kernel 7.1.2.
Jiawen Wu [Fri, 26 Jun 2026 09:25:30 +0000 (17:25 +0800)]
net: libwx: fix VMDQ mask for 1-queue mode
In wx_set_vmdq_queues(), the VMDQ mask was not set for the devices not
supporting WX_FLAG_MULTI_64_FUNC, i.e., NGBE devices. A mask of 0 causes
__ALIGN_MASK(1, ~vmdq->mask) to return 0, which incorrectly sets
q_per_pool to 0 in wx_write_qde().
Fix the VMDQ 1-queue mask to 0x7F then ensures that __ALIGN_MASK(1,
~0x7F) correctly evaluates to 1.
Lorenzo Bianconi [Thu, 25 Jun 2026 06:49:23 +0000 (08:49 +0200)]
net: airoha: fix max receive size configuration
Set the GDM maximum receive size to AIROHA_MAX_RX_SIZE unconditionally
during hardware initialization instead of updating it according to the
configured MTU. This avoids dropping incoming frames that exceed the
current MTU but could still be processed by the networking stack, which
is able to fragment the reply on the TX side (e.g. ICMP echo requests).
Move the per-port MTU configuration to the PPE egress path where it
belongs, and set the tx frame size running airoha_ppe_set_xmit_frame_size()
to dynamically track the maximum MTU across running interfaces sharing
the same PPE instance.
Fix the PPE MTU register addressing to pack two port entries per
register word and add WAN_MTU0 configuration for non-LAN GDM devices.
Fixes: 54d989d58d2a ("net: airoha: Move min/max packet len configuration in airoha_dev_open()") Tested-by: Madhur Agrawal <madhur.agrawal@airoha.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260625-airoha-fix-rx-max-len-v1-1-45b9b827358d@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Haoxiang Li [Thu, 25 Jun 2026 00:48:34 +0000 (08:48 +0800)]
fsl/fman: Free init resources on KeyGen failure in fman_init()
fman_muram_alloc() allocates initialization resources before
initializing the KeyGen block. If keygen_init() fails, the
function returns -EINVAL directly and leaves those resources
allocated. Free the initialization resources before returning
from the KeyGen failure path.
Johan Hovold [Mon, 29 Jun 2026 12:45:26 +0000 (14:45 +0200)]
USB: serial: keyspan_pda: fix information leak
The write() callback is supposed to return the number of characters
accepted or a negative errno. Since the addition of write fifo support
the keyspan_pda implementation will however return the number characters
submitted to the device if the write urb is not already in use. If this
number is larger than the number of characters passed to write(), the
line discipline continues writing data from beyond the tty write buffer.
Fix the information leak by making sure that keyspan_pda_write_start()
returns zero on success as intended.
Paul Louvel [Mon, 29 Jun 2026 14:07:02 +0000 (16:07 +0200)]
gpio-f7188x: Add support for NCT6126D version B
The Nuvoton NCT6126D Super-I/O is available in two hardware revisions.
According to the manufacturer datasheet revision 2.4, version A reports
chip ID 0xD283, while version B reports chip ID 0xD284.
The driver currently only recognizes only the version A ID. Version B
only contains hardware fixes unrelated to the GPIO functionality, so it
can be supported by simply adding its chip ID without any other driver
changes.
The HDCP 2.2 specification requires the seq_num_v to be monotonically
increasing, and repeated seq_num_v needs to be treated as an integrity
failure. Make it so.
For the first message, seq_num_v must be zero, and is already
checked. We can only check for less-than-or-equal for the subsequent
messages, where hdcp2_encrypted is true.
Discovered using AI-assisted static analysis confirmed by Intel Product
Security.
Florian Fuchs [Tue, 30 Jun 2026 01:33:42 +0000 (18:33 -0700)]
Input: maplemouse - fix NULL pointer dereference in open()
Commit 555c765b0cc2 ("Input: mouse - drop unnecessary calls to
input_set_drvdata") dropped the input_set_drvdata() call in probe
because the data appeared to be unused. However, dc_mouse_open() and
dc_mouse_close() were using maple_get_drvdata(to_maple_dev(&dev->dev)).
This appears to be accessing the data attached to an instance of
maple_device structure, while in reality this actually retrieves driver
data from the input device's embedded struct device (doing invalid
conversion of input device structure to maple device). After
input_set_drvdata() was removed, that lookup started returning NULL and
opening the input device dereferences mse->mdev.
Restore input_set_drvdata() and convert open() and close() to use
input_get_drvdata() so the dependency is no longer hidden.
Fixes: 6b3480855aad ("maple: input: fix up maple mouse driver") Fixes: 555c765b0cc2 ("Input: mouse - drop unnecessary calls to input_set_drvdata") Signed-off-by: Florian Fuchs <fuchsfl@gmail.com> Link: https://patch.msgid.link/20260628230715.2982552-1-fuchsfl@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
After previous patch, writes to network header are restricted.
However, there is another way to manipulate the l3 header: The
checksum update function.
Restrict this for network header writes, only the ipv4 header is
allowed. This needs run-time checks because BRIDGE, INET, NETDEV
families can carry l3 headers other than IP.
checksum updates to the udp/tcp (l4) headers are not restricted.
netfilter: nftables: restrict linklayer and network header writes
Don't permit arbitrary writes to linklayer and network header data.
Several spots in network stack trust header validation performed in
ipv4/ipv6 before PRE_ROUTING hook.
For linklayer, allow writes for netdev ingress. For other hooks, only
allow link layer writes that do not spill into network header.
For network header, check the offset/length combinations:
- changing dscp requires store at offset 0 for checsum fixups, so
make sure ip version + length field isn't altered.
- ip6 dscp starts directly after the version field, so make sure it
remains 6.
Several of these checks could already be done at rule insertion time.
Risk is that this might cause ruleset load failures for existing
rulesets. With this change such writes are silently skipped and packet
passes unchanged.
Transport and inner header bases are not checked / restricted.
netfilter: nfnetlink_queue: restrict writes to network header
nfnetlink_queue doesn't allow selective replacements of some part of the
payload, only complete replacement.
If the new data is shorter, skb is trimmed, otherwise expanded.
Add minimal validation of the new ip/ipv6 header. Check total len
matches skb length. Disallow ip option modifications.
IPv6 extension headers are also disabled.
IP options and exthdrs could be allowed later after validation pass or
ip option recompile.
Transport header is not checked.
Bridge modifications are rejected. Given userspace doesn't even receive
L2 headers, use is limited and I don't think there are any users of
bridge nfnetlink_queue, let alone users that modifiy payload.
netfilter: nft_fib: reject fib expression on the netdev egress hook
A fib expression in a netdev egress base chain dereferences nft_in(pkt),
NULL on the transmit path, causing a NULL pointer dereference at eval.
nft_fib_validate() masks the hook with NF_INET_* values, but netdev hook
numbers are a separate enum that aliases them (NF_NETDEV_EGRESS ==
NF_INET_LOCAL_IN), so an egress chain passes validation and then faults.
Add nft_fib_netdev_validate() that limits each result/flag to the netdev
hook where the device it reads exists: the input-device cases (OIF,
OIFNAME, ADDRTYPE with F_IIF) to ingress, the output-device case (ADDRTYPE
with F_OIF) to egress, ADDRTYPE with no device flag to both. Also restrict
nft_fib_validate() to NFPROTO_IPV4/IPV6/INET so its NF_INET_* masks are
not applied to another family's hooks.
netfilter: nfnetlink_cthelper: cap to maximum number of expectation per master
If userspace helper policy updates sets maximum number of expectation to
zero, cap it to NF_CT_EXPECT_MAX_CNT (255) on updates too.
Fixes: 397c8300972f ("netfilter: nf_conntrack_helper: cap maximum number of expectation at helper registration") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Florian Westphal <fw@strlen.de>
netfilter: nf_conntrack_sip: validate skb_dst() before accessing it
tc ingress and openvswitch do not guarantee routing information to be
available. These subsystems use the conntrack helper infrastructure, and
the SIP helper relies on the skb_dst() to be present if
sip_external_media is set to 1 (which is disabled by default as a module
parameter).
This effectively disables the sip_external_media toggle for these
subsystems without resulting in a crash.
Xiang Mei [Thu, 25 Jun 2026 01:00:06 +0000 (18:00 -0700)]
netfilter: ipset: fix race between dump and ip_set_list resize
The release path of ip_set_dump_do() and ip_set_dump_done() read
inst->ip_set_list via ip_set_ref_netlink(), a plain rcu_dereference_raw()
of the array pointer. These run from netlink_recvmsg() without the nfnl
mutex and without an RCU read-side critical section.
A concurrent ip_set_create() can grow the array: it publishes the new
array, calls synchronize_net() and then kvfree()s the old one. Since the
dump paths read the array outside any RCU reader, synchronize_net() does
not wait for them and the old array can be freed while they still index
into it, causing a use-after-free.
The dumped set itself stays pinned via set->ref_netlink, so only the
array load needs protecting. Take rcu_read_lock() around it, matching
ip_set_get_byname() and __ip_set_put_byindex().
BUG: KASAN: slab-use-after-free in ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697)
Read of size 8 at addr ffff88800b5c4018 by task exploit/150
Call Trace:
...
kasan_report (mm/kasan/report.c:595)
ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697)
netlink_dump (net/netlink/af_netlink.c:2325)
netlink_recvmsg (net/netlink/af_netlink.c:1976)
sock_recvmsg (net/socket.c:1159)
__sys_recvfrom (net/socket.c:2315)
...
Oops: general protection fault, probably for non-canonical address ... KASAN NOPTI
KASAN: maybe wild-memory-access in range [0x02d6...d0-0x02d6...d7]
RIP: 0010:ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1698)
Kernel panic - not syncing: Fatal exception
Fixes: 8a02bdd50b2e ("netfilter: ipset: Fix calling ip_set() macro at dumping") Cc: stable@vger.kernel.org Reported-by: Weiming Shi <bestswngs@gmail.com> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei <xmei5@asu.edu> Acked-by: Jozsef Kadlecsik <kadlec@netfilter.org> Signed-off-by: Florian Westphal <fw@strlen.de>
Florian Westphal [Tue, 16 Jun 2026 11:26:26 +0000 (13:26 +0200)]
netfilter: nft_set_pipapo: don't leak bad clone into future transaction
On memory allocation failure the cloned nft_pipapo_match can enter a bad
state:
- some fields can have their lookup tables resized while others did
not
- bits might have been toggled
- scratch map can be undersized which also means m->bsize_max can be
lower than what is required
This means that the next insertion in the same batch can trigger
out-of-bounds writes.
Furthermore, a failure in the first can result in the bad clone to
leak into the next transaction because the abort callback is never
executed in this case (the upper layer saw an error and no attempt to
allocate a transactional request was made).
Record a state for the nft_pipapo_match structure:
- NEW (pristine clone)
- MOD (modified clone with good state)
- ERR (potentially bogus content)
Then make it so that deletes and insertions fail when the clone
entered ERR state.
In case the very first insert attempt results in an error, free the
clone right away.
Fixes: 3c4287f62044 ("nf_tables: Add set type for arbitrary concatenation of ranges") Cc: stable@vger.kernel.org Reported-and-tested-by: Seesee <cjc000013@gmail.com> Reviewed-by: Stefano Brivio <sbrivio@redhat.com> Signed-off-by: Florian Westphal <fw@strlen.de>
Florian Westphal [Wed, 24 Jun 2026 21:06:43 +0000 (23:06 +0200)]
netfilter: nf_conntrack_expect: zero at allocation time
There are occasional LLM hints wrt. leaking uninitialized data to
userspace via ctnetlink. Just zero at allocation time,
expectations are not frequently used these days.
Intentionally keeps _init as-is because we could theoretically
support re-init, so add the missing exp->dir there.
v4 tried to fix the RollBall regression from 8fe125892f40 by deferring the
bridge probe to PHY discovery time. Maxime Chevallier and Aleksander
Bajkowski both tested that on genuine RollBall hardware and confirmed it
does not restore PHY detection (the module still is not ready when the
probe runs), and the Sashiko static review flagged the same path.
So this version drops the deferred-probe patch and instead reverts 8fe125892f40, restoring the pre-regression behaviour for genuine RollBall
modules. A proper fix for slow-initializing modules needs per-module init
timing (a longer module_t_wait / a per-module quirk) and genuine RollBall
hardware to validate; that is better owned as a follow-up by someone with
such a module.
====================
Petr Wozniak [Sat, 27 Jun 2026 17:32:42 +0000 (19:32 +0200)]
Revert "net: phy: sfp: probe for RollBall I2C-to-MDIO bridge in mdio-i2c"
This reverts commit 8fe125892f40 ("net: phy: sfp: probe for RollBall
I2C-to-MDIO bridge in mdio-i2c").
That commit added a RollBall bridge probe at MDIO bus creation time, in
i2c_mii_init_rollball(), to avoid a multi-minute PHY probe retry loop on
modules without a bridge (e.g. RTL8261BE). The probe runs in SFP_S_INIT,
before genuine RollBall modules have finished their firmware/bridge
initialization, so the bridge does not yet answer CMD_READ/CMD_DONE. The
probe times out, mdio_protocol is set to MDIO_I2C_NONE, and PHY detection
is then skipped for genuine RollBall modules that worked before the commit.
This was confirmed on hardware by Maxime Chevallier and Aleksander
Bajkowski: their RollBall modules no longer detect a PHY, and work again
on v7.0 (before the bridge probing was introduced). The Sashiko static
review flagged the same path.
Deferring the probe to PHY discovery time does not fix it either: at that
point a slow module may still be initializing, so the probe still returns
-ENODEV. A proper fix needs per-module init timing (a longer module_t_wait
or a per-module quirk, per SFF-8472 the host must also wait at least 300 ms
after insertion), which requires genuine RollBall hardware to develop and
validate. Revert to restore the previous, working behaviour in the meantime.
The RTL8261BE retry-loop latency that the reverted commit addressed is
handled in our downstream tree, so reverting upstream is safe on our side.
Petr Wozniak [Sat, 27 Jun 2026 17:32:41 +0000 (19:32 +0200)]
net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy
sfp_i2c_mdiobus_create() allocates the I2C MDIO bus with mdio_i2c_alloc(),
a plain (non-devm) allocation, and registers it. sfp_i2c_mdiobus_destroy()
only unregisters the bus and clears sfp->i2c_mii without calling
mdiobus_free(). As the only reference to the bus is then cleared, the
struct mii_bus is leaked.
This is hit whenever a copper/RollBall SFP module that instantiated an MDIO
bus is removed: sfp_sm_main() takes the global teardown path and calls
sfp_i2c_mdiobus_destroy(). sfp_cleanup(), on driver unbind, frees
sfp->i2c_mii directly, which is why the leak only triggered on module
hot-removal and not on unbind.
Free the bus in sfp_i2c_mdiobus_destroy() to match the allocation done in
sfp_i2c_mdiobus_create().
Fixes: e85b1347ace6 ("net: sfp: create/destroy I2C mdiobus before PHY probe/after PHY release") Signed-off-by: Petr Wozniak <petr.wozniak@gmail.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Larysa Zaremba <larysa.zaremba@intel.com> Link: https://patch.msgid.link/312bde8176fc429aa89524e3be250137f034ba84.1782581445.git.petr.wozniak@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Xiang Mei [Sat, 27 Jun 2026 20:53:53 +0000 (13:53 -0700)]
usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()
genelink_rx_fixup() splits an aggregated RX frame into its individual
packets, using a per-packet length taken from device-supplied data. That
length is only bounded by GL_MAX_PACKET_LEN (1514); it is never compared
against how many bytes were actually received.
A malicious GeneLink (GL620A) device can therefore send a short URB whose
header claims packet_count > 1 and a first packet of up to 1514 bytes.
skb_put_data(gl_skb, packet->packet_data, size);
then copies past the end of the receive buffer and hands the adjacent slab
contents up the network stack, an out-of-bounds read that leaks kernel heap.
No privilege is required: the path runs in the usbnet RX softirq as soon as
the interface is up.
BUG: KASAN: slab-out-of-bounds in genelink_rx_fixup (drivers/net/usb/gl620a.c:112)
Read of size 1514 at addr ffff888011309708 by task ksoftirqd/0/14
Call Trace:
...
__asan_memcpy (mm/kasan/shadow.c:105)
genelink_rx_fixup (include/linux/skbuff.h:2814 drivers/net/usb/gl620a.c:112)
usbnet_bh (drivers/net/usb/usbnet.c:572 drivers/net/usb/usbnet.c:1589)
process_one_work (kernel/workqueue.c:3322)
bh_worker (kernel/workqueue.c:3405)
tasklet_action (kernel/softirq.c:965)
handle_softirqs (kernel/softirq.c:622)
run_ksoftirqd (kernel/softirq.c:1076)
...
skb_pull() already verifies that the requested length fits the buffer and
returns NULL otherwise. Move it ahead of the copy and check its result, so
a packet that overruns the received data is rejected before it is read.
Well-formed frames, whose packets are fully present, are unaffected.
Fixes: 47ee3051c856 ("[PATCH] USB: usbnet (5/9) module for genesys gl620a cables") Reported-by: Weiming Shi <bestswngs@gmail.com> Signed-off-by: Xiang Mei <xmei5@asu.edu> Link: https://patch.msgid.link/20260627205353.4000788-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Doruk Tan Ozturk [Sat, 27 Jun 2026 22:30:59 +0000 (00:30 +0200)]
net/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete
When an offloaded MACsec RX SC is deleted, macsec_del_rxsc_ctx() freed
the per-SC metadata_dst with metadata_dst_free(), which kfree()s the
object unconditionally and ignores the dst reference count. The RX
datapath in mlx5e_macsec_offload_handle_rx_skb() looks up the SC under
rcu_read_lock() via xa_load(), takes a reference with dst_hold() and
attaches the dst to the skb with skb_dst_set(). A reader that already
obtained the rx_sc pointer can race with the delete path and operate on
freed memory.
Fix the owner side by dropping the reference with dst_release() instead
of freeing unconditionally, and convert the RX datapath to
dst_hold_safe() so a reader racing the SC delete cannot attach a dst
whose last reference was just dropped; only attach it when a reference
was actually taken.
mlx5e_macsec_add_rxsc() also published sc_xarray_element via xa_alloc()
before rx_sc->md_dst was allocated and initialised, so a datapath reader
that looked the SC up by fs_id could observe rx_sc with md_dst still
NULL or, on weakly-ordered architectures, a non-NULL md_dst pointer
whose contents were not yet visible. NULL-check the xa_load() result and
md_dst on the datapath, and reorder add_rxsc() so the xa_alloc() publish
happens only after md_dst is fully initialised; the xarray RCU publish
then pairs with the rcu_read_lock()/xa_load() in the datapath.
Note: macsec_del_rxsc_ctx() also kfree()s rx_sc->sc_xarray_element
without an RCU grace period while the same datapath reads it under
rcu_read_lock(); that is a separate pre-existing issue left to a
follow-up patch.
Found by 0sec automated security-research tooling (https://0sec.ai).
Fixes: b7c9400cbc48 ("net/mlx5e: Implement MACsec Rx data path using MACsec skb_metadata_dst") Cc: stable@vger.kernel.org Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260627223059.29917-1-doruk@0sec.ai Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Yousef Alhouseen [Sun, 28 Jun 2026 00:28:04 +0000 (02:28 +0200)]
netdevsim: remove ethtool debugfs files before freeing netdev
The ethtool debugfs files point directly into struct netdevsim, which is
allocated as net_device private data. Their containing port directory is
removed only after nsim_destroy() calls free_netdev().
An open simple-attribute file can consequently dereference the freed
private data before the directory is removed. KASAN observed this in
debugfs_u32_get() during network namespace teardown.
Track and remove the ethtool subtree before free_netdev() on both the
normal and registration-failure paths. debugfs removal drains active
file users before returning.
Fixes: ff1f7c17fb20 ("netdevsim: add pause frame stats") Reported-by: syzbot+6c25f4750230faf70be9@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6c25f4750230faf70be9 Cc: <stable+noautosel@kernel.org> # netdevsim is a test harness, it's never loaded on production systems Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com> Link: https://patch.msgid.link/20260628002804.24214-1-alhouseenyousef@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Pengfei Zhang [Thu, 25 Jun 2026 07:05:17 +0000 (15:05 +0800)]
ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump
inet6_dump_fib() saves its progress in cb->args[1] as a positional
index within the current hash chain. Between batches, a concurrent
fib6_new_table() can insert a new table at the chain head, shifting
all existing entries. The saved index then lands on a different
table, causing fib6_dump_table() to set w->root to the wrong table
while w->node still points into the previous one.
fib6_walk_continue() dereferences w->node->parent (NULL) and panics:
Fix by storing tb->tb6_id in cb->args[1] instead of a positional
index. On resume, skip entries until the id matches; a concurrent
head-insert can never match the saved id, so the walker always
resumes on the correct table.
Fixes: 1b43af5480c3 ("[IPV6]: Increase number of possible routing tables to 2^32") Signed-off-by: Pengfei Zhang <zhangfeionline@gmail.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260625070517.965597-1-zhangfeionline@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Dmitry Safonov [Thu, 25 Jun 2026 18:21:41 +0000 (19:21 +0100)]
tcp: Decrement tcp_md5_needed static branch
In case of early freeing an unwanted TCP-MD5 key on TCP-AO connect(),
md5sig_info is freed right away (and set to NULL). Later, at
the moment of socket destruction, the static branch counter
is not getting decremented.
Add a missing decrement for TCP-MD5 static branch.
Reported-by: Qihang <q.h.hack.winter@gmail.com> Fixes: 0aadc73995d0 ("net/tcp: Prevent TCP-MD5 with TCP-AO being set") Cc: stable@vger.kernel.org Signed-off-by: Dmitry Safonov <0x7f454c46@gmail.com> Link: https://patch.msgid.link/20260625-tcp-md5-connect-v3-3-1fd313d6c1e0@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
tcp: defer md5sig_info kfree past RCU grace period in tcp_connect
The md5+ao reconciliation in tcp_connect() (net/ipv4/tcp_output.c)
has two symmetric branches:
if (needs_md5) {
tcp_ao_destroy_sock(sk, false);
} else if (needs_ao) {
tcp_clear_md5_list(sk);
kfree(rcu_replace_pointer(tp->md5sig_info, NULL, ...));
}
Both branches free a per-socket auth-info object while the socket is
in TCP_SYN_SENT and is already on the inet ehash (inserted by
inet_hash_connect() in tcp_v4_connect()). Both branches are reachable
by softirq RX-path readers that load the corresponding info pointer
via implicit RCU before bh_lock_sock_nested() is taken.
The needs_md5 branch is fixed in the prior patch by re-introducing
the call_rcu() free in tcp_ao_destroy_sock(): the equivalent per-key
loop runs inside tcp_ao_info_free_rcu(), the RCU callback, so by the
time it frees each tcp_ao_key all softirq readers that captured the
container have already completed rcu_read_unlock().
The needs_ao branch is not symmetric in the same way. The container
free can be deferred via kfree_rcu(md5sig, rcu) -- struct
tcp_md5sig_info already has the required rcu member
(include/net/tcp.h:1999-2002), and the rest of the tree already does
this in the tcp_md5sig_info_add() rollback paths
(net/ipv4/tcp_ipv4.c:1410, 1436). But the per-key teardown is done
by tcp_clear_md5_list() in process context BEFORE the container's
RCU grace period: it walks &md5sig->head and frees each
tcp_md5sig_key with bare hlist_del + kfree. A concurrent softirq
reader in __tcp_md5_do_lookup() / __tcp_md5_do_lookup_exact()
(tcp_ipv4.c:1253, 1298) walks the same list via
hlist_for_each_entry_rcu() and races with that bare kfree on the
keys themselves -- a per-key slab use-after-free of the same class
as the TCP-AO bug, on the same race window.
Fix this in two halves:
1. Convert the bare kfree() in tcp_connect() to kfree_rcu() so the
md5sig_info container joins the rest of the md5sig lifecycle.
The local-variable lift is mechanical and required because
kfree_rcu() is a macro that expects an lvalue.
2. Make tcp_clear_md5_list() RCU-safe by replacing hlist_del +
kfree(key) with hlist_del_rcu + kfree_rcu(key, rcu). struct
tcp_md5sig_key already carries the rcu member
(include/net/tcp.h:1995) and tcp_md5_do_del()
(net/ipv4/tcp_ipv4.c:1456) already uses kfree_rcu, so this
restores the lifecycle invariant the rest of the file follows
rather than introducing a one-off.
The other caller of tcp_clear_md5_list() is tcp_md5_destruct_sock()
(net/ipv4/tcp.c:412), which runs from the sock destructor when the
socket is already unhashed and unreachable; the extra grace period
there is unnecessary but harmless. Making the helper unconditionally
RCU-safe is the cleaner contract.
The needs_ao branch is not reachable by the userns reproducer used
to demonstrate the AO-side splat (the repro installs both keys but
ends up in the needs_md5 branch because the connect peer matches
the MD5 key, not the AO key); however the symmetric race exists
and a maintainer touching this code should not have to think about
which branch escapes RCU and which one does not.
Fixes: 51e547e8c89c ("tcp: Free TCP-AO/TCP-MD5 info/keys without RCU") Cc: stable@vger.kernel.org # v6.18+ Suggested-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Reviewed-by: Dmitry Safonov <dima@arista.com> Reviewed-by: Eric Dumazet <edumazet@google.com>
[also credits to Qihang, who found that this races with tcp-diag] Reported-by: Qihang <q.h.hack.winter@gmail.com> Signed-off-by: Dmitry Safonov <0x7f454c46@gmail.com> Link: https://patch.msgid.link/20260625-tcp-md5-connect-v3-2-1fd313d6c1e0@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
tcp: restore RCU grace period in tcp_ao_destroy_sock
Commit 51e547e8c89c ("tcp: Free TCP-AO/TCP-MD5 info/keys without RCU")
removed the call_rcu() callback from tcp_ao_destroy_sock(), arguing that
"the destruction of info/keys is delayed until the socket destructor"
and therefore "no one can discover it anymore".
That argument does not hold for the call site in tcp_connect()
(net/ipv4/tcp_output.c:4327-4332). At that point the socket is in
TCP_SYN_SENT, has already been inserted into the inet ehash by
inet_hash_connect() in tcp_v4_connect(), and is therefore very much
discoverable: any softirq running tcp_v4_rcv() on another CPU can take
the socket out of the ehash, walk into tcp_inbound_hash(), and load
tp->ao_info via implicit RCU before bh_lock_sock_nested() is taken on
the destroying CPU.
The reader path then enters __tcp_ao_do_lookup() (net/ipv4/tcp_ao.c:208)
which re-loads tp->ao_info via rcu_dereference_check(); the re-load can
still observe the (about-to-be-freed) pointer because there is no
synchronize_rcu() between rcu_assign_pointer(tp->ao_info, NULL) and
tcp_ao_info_free() in tcp_ao_destroy_sock(). The captured pointer is
then walked at line 223:
The writer's synchronous kfree() is free to complete between the line
218 re-fetch and the line 223 hlist iteration. The slab is reused
(or simply LIST_POISON1-stamped if not yet reused) and the iteration
walks attacker-controlled or poison memory in softirq context.
Reproducer (no debug shim, stock x86_64 v7.1-rc2 SMP+KASAN, QEMU+KVM):
an unprivileged uid=1000 process inside CLONE_NEWUSER|CLONE_NEWNET
installs TCP_MD5SIG + TCP_AO_ADD_KEY on a TCP socket, sprays forged
TCP-AO segments toward its eventual 4-tuple via raw sockets, then
calls connect(). The md5-wins reconciliation in tcp_connect() fires
tcp_ao_destroy_sock(); the softirq backlog reader on the loopback
NAPI path crashes on the freed ao->head.first walk:
Oops: general protection fault, probably for non-canonical
address 0xfbd59c000000002f
KASAN: maybe wild-memory-access in range
[0xdead000000000178-0xdead00000000017f]
CPU: 0 UID: 1000 PID: 100 Comm: repro_userns
RIP: 0010:__tcp_ao_do_lookup+0x107/0x1c0
Call Trace: <IRQ>
__tcp_ao_do_lookup+0x107/0x1c0
tcp_ao_inbound_lookup.constprop.0+0x12a/0x200
tcp_inbound_ao_hash+0x5ea/0x1520
tcp_inbound_hash+0x7ce/0x1240
tcp_v4_rcv+0x1e7a/0x3e10
...
Restore the RCU grace period: re-add struct rcu_head to tcp_ao_info
and replace the synchronous tcp_ao_info_free() with a call_rcu()
callback. Readers that captured tp->ao_info before rcu_assign_pointer
NULLed it now see the object remain valid until rcu_read_unlock().
With the patch applied the reproducer runs cleanly for 2000 iterations
on the same kernel build.
Fixes: 51e547e8c89c ("tcp: Free TCP-AO/TCP-MD5 info/keys without RCU") Cc: stable@vger.kernel.org # v6.18+ Reviewed-by: Dmitry Safonov <dima@arista.com> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Dmitry Safonov <0x7f454c46@gmail.com> Link: https://patch.msgid.link/20260625-tcp-md5-connect-v3-1-1fd313d6c1e0@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Maoyi Xie [Thu, 25 Jun 2026 06:17:28 +0000 (14:17 +0800)]
net: wwan: iosm: bound device offsets in the MUX downlink decoder
mux_dl_adb_decode() walks a chain of aggregated datagram tables using
offsets and lengths taken from the modem. first_table_index,
next_table_index, table_length, datagram_index and datagram_length are
all device supplied le values. Only first_table_index was checked, and
only for being non zero. The decoder then formed adth = block +
adth_index and read the table header and the datagram entries with no
bound against the received skb. A modem that reports an index or a
length past the downlink buffer makes the decoder read out of bounds.
The buffer is IPC_MEM_MAX_DL_MUX_LITE_BUF_SIZE and skb->len is at most
that, so skb->len is the real limit, but none of these in band offsets
were checked against it.
The table chain is also followed with no forward progress check. The loop
takes the next table from adth->next_table_index and stops only when that
reaches zero. A modem can stage two tables that point at each other, so
the loop never ends. It runs in softirq and clones the skb on every pass.
Validate every device offset and length against skb->len before use.
The block header must fit. Each table header, on entry and after every
next_table_index, must lie inside the skb. The datagram table must fit.
Each datagram index and length must stay inside the skb. The header
padding must not exceed the datagram length so the receive length does
not wrap. Require each next_table_index to move forward so the chain
cannot cycle.
This was reproduced under KASAN as a slab out of bounds read on a normal
downlink receive once the iosm net device is up.
Samuel Page [Thu, 25 Jun 2026 14:38:15 +0000 (15:38 +0100)]
tipc: fix out-of-bounds read in broadcast Gap ACK blocks
A broadcast PROTOCOL/STATE_MSG can carry a Gap ACK blocks record in its
data area. tipc_get_gap_ack_blks() only verifies that the record's len
field is self-consistent with its ugack_cnt/bgack_cnt counts
(sz == struct_size(p, gacks, ugack_cnt + bgack_cnt)); it does not check
that the record actually fits in the message data area, msg_data_sz().
The unicast caller tipc_link_proto_rcv() bounds it ("if (glen > dlen)
break;"), but the broadcast caller tipc_bcast_sync_rcv() discards the
returned size, so tipc_link_advance_transmq() copies the record off the
receive skb with an attacker-controlled count:
A TIPC neighbour that negotiated TIPC_GAP_ACK_BLOCK triggers it with one
ordinary broadcast STATE_MSG (msg_bc_ack_invalid() clear), sized so its
data area is short, carrying a Gap ACK record with len = 0x400,
bgack_cnt = 0xff and ugack_cnt = 0. len then equals
struct_size(p, gacks, 255), so the consistency check passes and ga is
non-NULL; kmemdup() reads struct_size(ga, gacks, 255) = 1024 bytes out
of the much smaller skb:
BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x48/0x60
Read of size 1024 at addr ffff0000c7030d38 by task poc864/69
Call trace:
kmemdup_noprof+0x48/0x60
tipc_link_advance_transmq+0x86c/0xb80
tipc_link_bc_ack_rcv+0x19c/0x1e0
tipc_bcast_sync_rcv+0x1c4/0x2c4
tipc_rcv+0x85c/0x1340
tipc_l2_rcv_msg+0xac/0x104
The buggy address belongs to the object at ffff0000c7030d00
which belongs to the cache skbuff_small_head of size 704
The buggy address is located 56 bytes inside of
allocated 704-byte region [ffff0000c7030d00, ffff0000c7030fc0)
The copied-out bytes are subsequently consumed as gap/ack values, but
the read is already out of bounds at the kmemdup() regardless of how
they are used.
The unicast STATE path drops such a message: "if (glen > dlen) break;"
skips the rest of STATE_MSG handling and the skb is freed. Make the
broadcast path drop it too. tipc_bcast_sync_rcv() now bounds the record
against msg_data_sz() and, when it does not fit, reports it back through
tipc_node_bc_sync_rcv() to tipc_rcv() so the skb is discarded rather than
processed. ga is not cleared on this path: ga == NULL already means
"legacy peer without Selective ACK", a distinct legitimate state.
Fixes: d7626b5acff9 ("tipc: introduce Gap ACK blocks for broadcast link") Cc: stable@vger.kernel.org Signed-off-by: Samuel Page <sam@bynar.io> Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech> Link: https://patch.msgid.link/20260625143815.1525412-1-sam@bynar.io Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Thu, 25 Jun 2026 16:05:08 +0000 (09:05 -0700)]
eth: fbnic: don't cache shinfo across skb realloc
fbnic_tx_lso() calls skb_cow_head() which may reallocate the skb
including the shared info. We can't use the pointer calculated
before the call.
BUG: KASAN: slab-use-after-free in fbnic_tx_lso.isra.0+0x668/0x8e0
Read of size 4 at addr ff110000262edd98 by task swapper/5/0
Call Trace:
fbnic_tx_lso.isra.0+0x668/0x8e0
fbnic_xmit_frame+0x622/0xba0
dev_hard_start_xmit+0xf4/0x620
Allocated by task 8653:
__alloc_skb+0x11e/0x5f0
alloc_skb_with_frags+0xcc/0x6c0
sock_alloc_send_pskb+0x327/0x3f0
__ip_append_data+0x188b/0x47a0
ip_make_skb+0x24a/0x300
udp_sendmsg+0x14d2/0x21e0
Freed by task 0:
kfree+0x123/0x5a0
pskb_expand_head+0x36c/0xfa0
fbnic_tx_lso.isra.0+0x500/0x8e0
fbnic_xmit_frame+0x622/0xba0
dev_hard_start_xmit+0xf4/0x620
sch_direct_xmit+0x25b/0x1100
The buggy address belongs to the object at ff110000262edc40
which belongs to the cache skbuff_small_head of size 640
The buggy address is located 344 bytes inside of
freed 640-byte region [ff110000262edc40, ff110000262ede
Guenter Roeck [Mon, 29 Jun 2026 23:18:18 +0000 (16:18 -0700)]
hwmon: (aspeed-g6-pwm-tach) Guard fan RPM calculation against divide-by-zero
Sashiko reports:
In the aspeed-g6-pwm-tacho driver, the aspeed_tach_val_to_rpm() function
calculates the fan RPM using the tachometer value. However, it does not
check if the tachometer value is zero before performing the division.
If the hardware reports a tachometer value of 0 (which can happen due to
an extremely fast pulse, a stuck edge, or a hardware glitch), the
calculated tach_div evaluates to 0. The subsequent call to do_div() with
tach_div as the divisor triggers a divide-by-zero exception, leading to
a kernel panic.
Check the divisor against zero to fix the problem.
Fixes: 7e1449cd15d1 ("hwmon: (aspeed-g6-pwm-tacho): Support for ASPEED g6 PWM/Fan tach") Cc: Billy Tsai <billy_tsai@aspeedtech.com> Reported-by: Sashiko <sashiko-bot@kernel.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Guenter Roeck [Mon, 29 Jun 2026 23:08:00 +0000 (16:08 -0700)]
hwmon: (pmbus) Fix passing events to regulator core
Sashiko reports:
Commit 754bd2b4a084 ("hwmon: (pmbus/core) Protect regulator operations with
mutex") introduced a worker to batch regulator events over time using
atomic_or(). The delayed worker then passes the combined bitmask unmodified
to regulator_notifier_call_chain().
The core regulator subsystem's regulator_handle_critical() function
evaluates the event parameter using a strict switch statement. If
multiple distinct faults occur before the worker runs (e.g.,
REGULATOR_EVENT_UNDER_VOLTAGE | REGULATOR_EVENT_OVER_CURRENT), the combined
bitmask fails to match any case. This leaves the reason as NULL and
completely bypasses the critical hw_protection_trigger().
Fix the problem by passing events bit by bit to the regulator event
handler.
iio: common: st_sensors: honour channel endianness in read_axis_data
st_sensors_read_axis_data() unconditionally decoded multi-byte
results with get_unaligned_le16() / get_unaligned_le24() regardless
of the channel's declared scan_type.endianness.
For every ST sensor that has used this helper since it was introduced
this happened to be fine because the ST IMU/accel/gyro/pressure
families publish their data registers as little-endian and the
channel specs in those drivers declare IIO_LE accordingly.
The LSM303DLH magnetometer however publishes its X/Y/Z output as a
pair of big-endian bytes (the H register sits at the lower address,
0x03/0x05/0x07, and the L register immediately after), and its
channel specs in st_magn_core.c correctly declare IIO_BE -- but
read_axis_data() ignored that and decoded as little-endian, swapping
the high and low bytes of every magnetometer sample. The LSM303DLHC
and LSM303DLM share the same st_magn_16bit_channels (IIO_BE) and
were therefore byte-swapped by the same bug; users of those parts
will see different in_magn_*_raw values after this fix lands.
The bug is most visible on a stationary chip: in earth's field the
true X reading is small and the high byte sits at 0x00, so swapping
the bytes pins sysfs X at exactly the low byte's pattern (e.g. 0x00F0
= 240). Y and Z still appear "to vary" because their magnitudes are
larger and the noise in the low byte produces big swings in the
swapped high byte:
before (LSM303DLH flat, sysfs in_magn_*_raw):
X=240 (stuck), Y= 12032..23296, Z=-16128..-9728
after (direct i2c-dev big-endian decode, same chip same orientation):
X≈-4096, Y≈210, Z≈80 (sensible values reflecting earth's
ambient field at low gauss range)
Fix read_axis_data() to dispatch on ch->scan_type.endianness and
call get_unaligned_be16() / get_unaligned_be24() when the channel
declares IIO_BE. Existing IIO_LE consumers (st_accel, st_gyro,
st_pressure, st_lsm6dsx and others) are unaffected because their
channel specs already declare IIO_LE and the LE path is unchanged.
While restructuring the branches, replace the previously implicit
silent-success-with-uninitialised-*data fall-through for
byte_for_channel outside 1..3 with an explicit return -EINVAL. No
in-tree ST sensor publishes such a channel, but the new behaviour
is strictly safer than handing userspace garbage.
Fixes: 23491b513bcd ("iio:common: Add STMicroelectronics common library") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 sparse smatch clang-analyzer coccinelle checkpatch Assisted-by: Sashiko:claude-opus-4-7 Signed-off-by: Herman van Hazendonk <github.com@herrie.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Runyu Xiao [Thu, 4 Jun 2026 01:42:47 +0000 (09:42 +0800)]
iio: imu: bmi160: add IRQF_NO_THREAD to data-ready trigger IRQ
bmi160_probe_trigger() registers iio_trigger_generic_data_rdy_poll()
through devm_request_irq(), but it passes only irq_type and does not add
IRQF_NO_THREAD.
When the kernel is booted with forced IRQ threading, the parent IRQ can
otherwise be threaded by the IRQ core and the subsequent IIO trigger
child IRQ is dispatched from irq/... thread context instead of hardirq
context. Because the handler immediately pushes the event into
iio_trigger_poll(), this violates the hardirq-only IIO trigger helper
contract and can drive downstream trigger consumers through the wrong
execution context.
Add IRQF_NO_THREAD on top of irq_type when registering the BMI160 data-
ready trigger handler.
Runyu Xiao [Thu, 4 Jun 2026 01:42:46 +0000 (09:42 +0800)]
iio: imu: adis: add IRQF_NO_THREAD to non-FIFO trigger IRQ
devm_adis_probe_trigger() registers iio_trigger_generic_data_rdy_poll()
through devm_request_irq() on the non-FIFO path, but it does not add
IRQF_NO_THREAD to the IRQ flags.
When the kernel is booted with forced IRQ threading, the parent IRQ can
otherwise be threaded by the IRQ core and the subsequent IIO trigger
child IRQ is then dispatched from irq/... thread context instead of
hardirq context. Because iio_trigger_generic_data_rdy_poll()
immediately drives iio_trigger_poll(), this violates the hardirq-only
IIO trigger helper contract and can push downstream trigger consumers
through the wrong execution context.
Add IRQF_NO_THREAD on top of the existing adis->irq_flag value for the
non-FIFO request_irq() path, while preserving the current trigger
polarity and IRQF_NO_AUTOEN behavior.
Zhang Lixu [Wed, 10 Jun 2026 08:29:10 +0000 (16:29 +0800)]
iio: hid-sensor-rotation: Fix stale or zero output when reading raw values
When reading the raw quaternion attribute (in_rot_quaternion_raw), the
driver currently returns either all zeros (if the sensor was never enabled)
or stale data (if the sensor was previously enabled) because it reads from
the internal buffer without explicitly requesting a new sample from the
sensor.
To fix this, power up the sensor, call sensor_hub_input_attr_read_values()
to issue a synchronous GET_REPORT and receive the full quaternion data
directly into a local buffer, then decode the four components.
HID: sensor-hub: Add sensor_hub_input_attr_read_values() for multi-byte reads
sensor_hub_input_attr_get_raw_value() is limited to returning a single
32-bit value, which is insufficient for sensors that report data larger
than 32 bits, such as a quaternion with four s16 elements.
Add sensor_hub_input_attr_read_values() that accepts a caller-provided
buffer and accumulates incoming data until the buffer is full. The two
paths are distinguished in sensor_hub_raw_event() by pending.max_raw_size
being non-zero, preserving backward compatibility.
Maxwell Doose [Sat, 13 Jun 2026 00:58:11 +0000 (19:58 -0500)]
iio: adc: spear: Initialize completion before requesting IRQ
In the report from Jaeyoung Chung:
"spear_adc_probe() in drivers/iio/adc/spear_adc.c registers its
interrupt handler with devm_request_irq() before it initializes
st->completion with init_completion(). If an interrupt arrives after
devm_request_irq() and before init_completion(), the handler calls
complete() on an uninitialized completion, causing a kernel panic.
If the device raises an interrupt before init_completion() runs,
complete() acquires the uninitialized wait.lock and walks the zeroed
task_list in swake_up_locked(). The zeroed task_list makes list_empty()
return false, so swake_up_locked() dereferences a NULL list entry,
triggering a KASAN wild-memory-access."
Fix the chance of a spurious IRQ causing an uninitialized pointer
dereference by moving init_completion() above devm_request_irq().
Fixes: b586e5d9eee0 ("staging:iio:adc:spear rename device specific state structure to _state") Reported-by: Sangyun Kim <sangyun.kim@snu.ac.kr> Reported-by: Kyungwook Boo <bookyungwook@gmail.com> Reported-by: Jaeyoung Chung <jjy600901@snu.ac.kr> Closes: https://lore.kernel.org/linux-iio/20260610115700.774689-1-jjy600901@snu.ac.kr/ Signed-off-by: Maxwell Doose <m32285159@gmail.com> Reviewed-by: Vladimir Zapolskiy <vz@kernel.org> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Maxwell Doose [Sat, 13 Jun 2026 00:58:10 +0000 (19:58 -0500)]
iio: adc: lpc32xx: Initialize completion before requesting IRQ
In the report from Jaeyoung Chung:
"lpc32xx_adc_probe() in drivers/iio/adc/lpc32xx_adc.c registers its
interrupt handler with devm_request_irq() before it initializes
st->completion with init_completion(). If an interrupt arrives after
devm_request_irq() and before init_completion(), the handler calls
complete() on an uninitialized completion, causing a kernel panic.
If the device raises an interrupt before init_completion() runs,
complete() acquires the uninitialized wait.lock and walks the zeroed
task_list in swake_up_locked(). The zeroed task_list makes list_empty()
return false, so swake_up_locked() dereferences a NULL list entry,
triggering a KASAN wild-memory-access."
Fix the chance of a spurious IRQ causing an uninitialized pointer
dereference by moving init_completion() above devm_request_irq().
Fixes: 7901b2a1453e ("staging:iio:adc:lpc32xx rename local state structure to _state") Reported-by: Sangyun Kim <sangyun.kim@snu.ac.kr> Reported-by: Kyungwook Boo <bookyungwook@gmail.com> Reported-by: Jaeyoung Chung <jjy600901@snu.ac.kr> Closes: https://lore.kernel.org/linux-iio/20260610115700.774689-1-jjy600901@snu.ac.kr/ Signed-off-by: Maxwell Doose <m32285159@gmail.com> Reviewed-by: Vladimir Zapolskiy <vz@kernel.org> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Biren Pandya [Sun, 14 Jun 2026 07:15:49 +0000 (12:45 +0530)]
iio: light: gp2ap002: fix runtime PM leak on read error
gp2ap002_read_raw() calls pm_runtime_get_sync() before reading the
lux value, but if gp2ap002_get_lux() fails, it returns directly. This
skips the pm_runtime_put_autosuspend() call at the "out" label,
permanently leaking a runtime PM reference and preventing the device
from autosuspending.
Replace the direct return with a "goto out" to ensure the reference
is properly dropped on the error path.
Fixes: f6dbf83c17cb ("iio: light: gp2ap002: Take runtime PM reference on light read") Signed-off-by: Biren Pandya <birenpandya@gmail.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Biren Pandya [Sun, 14 Jun 2026 07:15:48 +0000 (12:45 +0530)]
iio: pressure: mpl115: fix runtime PM leak on read error
mpl115_read_raw() takes a runtime PM reference with pm_runtime_get_sync()
before reading the processed pressure or raw temperature, but on the read
error path it returns without calling pm_runtime_put_autosuspend(). Each
failed read therefore leaks a runtime PM reference and prevents the device
from autosuspending.
Drop the reference before checking the return value so both the success
and error paths are balanced.
Fixes: 0c3a333524a3 ("iio: pressure: mpl115: Implementing low power mode by shutdown gpio") Signed-off-by: Biren Pandya <birenpandya@gmail.com> Assisted-by: Claude:claude-opus-4-8 coccinelle Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Biren Pandya [Sun, 14 Jun 2026 07:15:46 +0000 (12:45 +0530)]
iio: accel: kxsd9: fix runtime PM imbalance on write_raw() error
kxsd9_write_raw() takes a runtime PM reference with pm_runtime_get_sync()
but returns -EINVAL directly when a scale with a non-zero integer part is
requested, skipping the matching pm_runtime_put_autosuspend(). This leaks
a runtime PM usage-counter reference on every such write, after which the
device can no longer autosuspend.
Set the error code and fall through to the existing put instead of
returning early.
Fixes: 9a9a369d6178 ("iio: accel: kxsd9: Deploy system and runtime PM") Signed-off-by: Biren Pandya <birenpandya@gmail.com> Assisted-by: Claude:claude-opus-4-8 coccinelle Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Bryam Vargas [Sat, 13 Jun 2026 07:18:39 +0000 (02:18 -0500)]
iio: accel: bmc150: clamp the device-reported FIFO frame count
__bmc150_accel_fifo_flush() copies the number of samples the device
reports in its hardware FIFO into an on-stack buffer
u16 buffer[BMC150_ACCEL_FIFO_LENGTH * 3];
which is sized for at most BMC150_ACCEL_FIFO_LENGTH (32) samples. The
frame count is read from the FIFO_STATUS register and only masked to its
7 valid bits:
count = val & 0x7F;
so it can be 0..127. The only other limit applied to it is the optional
caller-supplied sample budget:
if (samples && count > samples)
count = samples;
which does not constrain count on the flush-all path (samples == 0), and
leaves it well above 32 whenever samples is larger. count samples are
then transferred into buffer[]:
bmc150_accel_fifo_transfer() reads count * 6 bytes through regmap, so a
malfunctioning, malicious or counterfeit accelerometer (or an attacker
tampering with the I2C/SPI bus) that reports up to 127 frames writes up
to 762 bytes into the 192-byte buffer: a stack out-of-bounds write of up
to 570 bytes that clobbers the stack canary, saved registers and the
return address.
Clamp count to BMC150_ACCEL_FIFO_LENGTH, the number of samples buffer[]
is sized for, before the transfer, mirroring the watermark clamp already
done in bmc150_accel_set_watermark(). A well-formed flush reports at most
BMC150_ACCEL_FIFO_LENGTH frames, so legitimate devices are unaffected.
Fixes: 3bbec9773389 ("iio: bmc150_accel: add support for hardware fifo") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Ariana Lazar [Thu, 4 Jun 2026 13:46:47 +0000 (16:46 +0300)]
iio: dac: mcp47feb02: Fix passing uninitialized vref1_uV for no Vref1 case
Ensure that if a device has Vref1 but reading the regulator returns an
error, mcp47feb02_init_ctrl_regs() is not called with an uninitialized
vref1_uV value. Also add a device_property_present() check for the Vref1
supply before reading the regulator.
Fixes: dd154646d292 ("iio: dac: mcp47feb02: Fix Vref validation [1-999] case") Reported-by: Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/all/adiPnla0M5EzvgD-@stanley.mountain/ Signed-off-by: Ariana Lazar <ariana.lazar@microchip.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Guangshuo Li [Wed, 3 Jun 2026 12:16:40 +0000 (20:16 +0800)]
iio: adc: ti-ads1119: fix PM reference leak in buffer preenable
ads1119_triggered_buffer_preenable() resumes the device with
pm_runtime_resume_and_get() before starting a conversion.
If i2c_smbus_write_byte() fails, the function returns the error directly
and leaves the runtime PM usage counter elevated. The matching
postdisable callback is not called when preenable fails, so the reference
is leaked and the device may remain runtime-active indefinitely.
Store the I2C transfer result in ret and drop the runtime PM reference on
failure before returning the error.
Fixes: a9306887eba41 ("iio: adc: ti-ads1119: Add driver") Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Samuel Moelius [Tue, 2 Jun 2026 16:45:39 +0000 (16:45 +0000)]
iio: adc: ad7380: select REGMAP
The AD7380 driver uses generic regmap types and APIs. However, its
Kconfig entry does not select REGMAP.
As a result, AD7380 can be enabled from an allnoconfig-derived config
with SPI_MASTER=y while REGMAP remains unset, causing ad7380.o to fail
to build.
Fixes: b095217c104b ("iio: adc: ad7380: new driver for AD7380 ADCs") Signed-off-by: Samuel Moelius <samuel.moelius@trailofbits.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Jann Horn [Fri, 26 Jun 2026 15:52:52 +0000 (17:52 +0200)]
bpf,fork: wipe ->bpf_storage before bailouts that access it
Currently, copy_process() can bail out to free_task() before p->bpf_storage
has been initialized, with this call graph (shown here for the
!CONFIG_MEMCG case):
copy_process
dup_task_struct
arch_dup_task_struct
[copies the entire task_struct, including ->bpf_storage member]
[RLIMIT_NPROC check fails]
delayed_free_task
free_task
bpf_task_storage_free
rcu_dereference(task->bpf_storage)
bpf_local_storage_destroy
In this case, the nascent task's ->bpf_storage member that
bpf_local_storage_destroy() operates on is a plain copy of the parent's
->bpf_storage pointer, not a real initialized pointer.
This leads to badness (kernel hangs, UAF).
This is reachable as long as the process calling fork() has been inserted
into a task storage map.
Cc: stable@kernel.org Fixes: a10787e6d58c ("bpf: Enable task local storage for tracing programs") Signed-off-by: Jann Horn <jannh@google.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Matti Vaittinen [Fri, 26 Jun 2026 07:23:58 +0000 (10:23 +0300)]
hwmon: adm1275: Detect coefficient overflow
Sashiko detected potential coefficient overflow if large shunt resistor
is used. When going unnoticed it can cause "drastically incorrect
telemetry scaling factors" as Sashiko put it.
I am not convinced such "drastically incorrect telemetry scaling
factors" could have gone unnoticed, so I suspect such large shunt
resistors aren't really used. Well, it shouldn't hurt to detect the
error and abort the probe before Really Wrong current / power -values
are reported to user by the hwmon.
While adding support for the ROHM BD127X0 hot-swap controllers, sashiko
reported an error in device-name comparison, which can lead to reading
uninitialized stack memory.
Quoting Sashiko:
This is a pre-existing issue, but I noticed that just before this block in
adm1275_probe(), there might be an out-of-bounds stack read:
ret = i2c_smbus_read_block_data(client, PMBUS_MFR_MODEL, block_buffer);
if (ret < 0) { ... }
for (mid = adm1275_id; mid->name[0]; mid++) {
if (!strncasecmp(mid->name, block_buffer, strlen(mid->name)))
break;
}
Since i2c_smbus_read_block_data() reads up to 32 bytes into the
uninitialized stack array block_buffer without appending a null
terminator, strncasecmp() could read past the valid bytes returned in ret.
For example, if the device returns a shorter string like "adm12", checking
it against "adm1275" up to the length of "adm1275" will continue reading
into uninitialized stack bounds.
Prevent reading uninitialized memory by zeroing the stack array.
Joshua Crofts [Mon, 29 Jun 2026 19:17:41 +0000 (21:17 +0200)]
hwmon: (max6697) add missing 'select REGMAP_I2C' to Kconfig
The Kconfig entry for the MAX6697 sensor doesn't contain a
`select REGMAP_I2C` parameter, causing build failures if regmap
isn't selected previously during the build process.
Joshua Crofts [Mon, 29 Jun 2026 19:17:40 +0000 (21:17 +0200)]
hwmon: (ltc2992) add missing 'select REGMAP_I2C' to Kconfig
The Kconfig entry for the LTC2992 sensor doesn't contain a
`select REGMAP_I2C` parameter, causing build failures if regmap
isn't selected previously during the build process.
Joshua Crofts [Mon, 29 Jun 2026 19:17:39 +0000 (21:17 +0200)]
hwmon: (max1619) add missing 'select REGMAP' to Kconfig
The Kconfig entry for the MAX1619 sensor doesn't contain a
`select REGMAP` parameter, causing build failures if regmap
isn't selected previously during the build process.
Pengpeng Hou [Mon, 15 Jun 2026 06:47:31 +0000 (14:47 +0800)]
hwmon: (w83627hf) remove VID sysfs files on error and remove
w83627hf_probe() creates cpu0_vid and vrm with device_create_file() when
VID information is available.
The error path and remove callback only remove the common and optional
attribute groups. Those groups do not contain cpu0_vid or vrm, so the
files can remain after a later probe failure or after device removal
while their callbacks still expect live driver data.
Remove the standalone VID sysfs files from both the probe error path and
the remove callback.
Pengpeng Hou [Mon, 15 Jun 2026 06:48:06 +0000 (14:48 +0800)]
hwmon: (w83793) remove vrm sysfs file on probe failure
w83793_probe() creates the vrm sysfs file after creating the VID files
when VID support is present.
The normal remove path deletes vrm, but the probe error path only
removes the sensor, SDA, VID, fan, PWM and temperature files. A later
probe failure can therefore leave vrm behind after the driver data has
been freed.
Remove vrm in the probe error path next to the VID files, matching the
normal remove path.
Alex Williamson [Mon, 15 Jun 2026 19:12:34 +0000 (13:12 -0600)]
vfio/pci: Expose latched module parameter policy in debugfs
The nointxmask and disable_idle_d3 module parameters remain writable,
but vfio-pci now latches their values into each device at init. Once a
device is registered, changing the module parameter only affects future
devices, leaving no direct way to confirm the effective policy for an
existing device.
Add a pci debugfs directory under the VFIO device debugfs root and
report the per-device nointxmask and disable_idle_d3 values. These are
read-only debugfs views and use the same Y/N bool output convention as
the module parameters.
Read-only vfio-pci parameters, such as disable_vga, are not exposed here
because they cannot drift from the latched device value, therefore the
existing module parameter exposure via sysfs is sufficient.
Note that while only vfio-pci currently provides these options, the
implementation is in vfio-pci-core and therefore properly reflects the
device policy in the core, regardless of driver.
Assisted-by: OpenAI Codex:gpt-5 Cc: Guixin Liu <kanie@linux.alibaba.com> Signed-off-by: Alex Williamson <alex.williamson@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20260615191241.688297-7-alex.williamson@nvidia.com Signed-off-by: Alex Williamson <alex@shazbot.org>
Alex Williamson [Mon, 15 Jun 2026 20:47:00 +0000 (14:47 -0600)]
vfio: Remove device debugfs before releasing devres
VFIO device debugfs files created with debugfs_create_devm_seqfile()
store a devres allocated debugfs_devm_entry as inode private data.
vfio_unregister_group_dev() currently calls vfio_device_del() before
vfio_device_debugfs_exit(), but device_del() releases devres. This can
leave debugfs entries visible with stale inode private data while
unregister waits for userspace references to drain.
Remove the per-device debugfs tree before vfio_device_del(). The debugfs
view is diagnostic only, so losing it at the start of unregister is
preferable to preserving entries whose backing storage may already have
been released.
Complete the teardown by clearing the per-device debugfs root after
removal. This matches the global debugfs root cleanup and prevents
future users from mistaking a removed dentry for a live debugfs tree
during the remainder of unregister.
Alex Williamson [Mon, 15 Jun 2026 19:12:33 +0000 (13:12 -0600)]
vfio/pci: Latch all module parameters per device
The vfio-pci module parameters of disable_idle_d3, nointxmask, and
disable_vga latch vfio-pci policy into vfio-pci-core globals each time
the vfio-pci module is initialized. The disable_idle_d3 parameter has
already migrated to a per-device flag in order to provide consistency
for refcounted PM operations for the lifetime of the device
registration.
Pull the remaining vfio-pci module-parameter policy out of vfio-pci-core
into per-device flags set at device initialization.
This also restores the mutable aspect of the disable_idle_d3 and
nointxmask module parameters for vfio-pci, with the caveat that the
parameters are latched into the device at probe.
A notable change for variant drivers is that their devices are no longer
affected by vfio-pci module parameters and those drivers may need to
adopt similar module parameters if any devices have a hidden dependency
on vfio-pci setting non-default policy.
Assisted-by: Claude:claude-opus-4-8 Acked-by: Chengwen Feng <fengchengwen@huawei.com> Signed-off-by: Alex Williamson <alex.williamson@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20260615191241.688297-6-alex.williamson@nvidia.com Signed-off-by: Alex Williamson <alex@shazbot.org>
Alex Williamson [Mon, 15 Jun 2026 19:12:32 +0000 (13:12 -0600)]
vfio/mlx5: Fix racy bitfields and tighten struct layout
Bitfield operations are not atomic, they use a read-modify-write
pattern, therefore we should be careful not to pack bitfields that
can be concurrently updated into the same storage unit.
This split takes a binary approach: flags that are only modified
pre/post open/close remain bitfields, flags modified from user
action, including actions that reach across to another device (ex.
reset) use dedicated storage units.
Note mlx5_vhca_page_tracker.status is relocated to fill the alignment
hole this split exposes.
Bitfield justifications:
migrate_cap: written only in mlx5vf_cmd_set_migratable() at probe
chunk_mode: written only in mlx5vf_cmd_set_migratable() at probe
mig_state_cap: written only in mlx5vf_cmd_set_migratable() at probe
Dedicated storage units:
mdev_detach: written in the VF attach/detach event notifier
mlx5fv_vf_event() at runtime
log_active: written in mlx5vf_start_page_tracker()/
mlx5vf_stop_page_tracker() during runtime dirty tracking
deferred_reset: written in mlx5vf_state_mutex_unlock()/
mlx5vf_pci_aer_reset_done() during runtime reset handling
is_err: set by tracker error handling and dirty-log polling at runtime
object_changed: set by tracker event handling and cleared by dirty-log
polling at runtime
Fixes: 61a2f1460fd0 ("vfio/mlx5: Manage the VF attach/detach callback from the PF") Fixes: 79c3cf279926 ("vfio/mlx5: Init QP based resources for dirty tracking") Fixes: f886473071d6 ("vfio/mlx5: Add support for tracker object change event") Cc: Yishai Hadas <yishaih@nvidia.com> Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Alex Williamson <alex.williamson@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20260615191241.688297-5-alex.williamson@nvidia.com Signed-off-by: Alex Williamson <alex@shazbot.org>
Alex Williamson [Mon, 15 Jun 2026 19:12:31 +0000 (13:12 -0600)]
vfio/pci: Fix racy bitfields and tighten struct layout
Bitfield operations are not atomic, they use a read-modify-write
pattern, therefore we should be careful not to pack bitfields that
can be concurrently updated into the same storage unit.
This split takes a binary approach: flags that are only modified
pre/post open/close remain bitfields, flags modified from user
action, including actions that reach across to another device (ex.
reset) use dedicated storage units.
Note that the virq_disabled and bardirty flags are relocated to fill
an existing hole in the structure.
Bitfield justifications:
has_dyn_msix: written only in vfio_pci_core_enable()
pci_2_3: written only in vfio_pci_core_enable()
reset_works: written only in vfio_pci_core_enable()
extended_caps: written only in vfio_cap_len() under vfio_config_init()
has_vga: written only in vfio_pci_core_enable()
nointx: written only in vfio_pci_core_enable()
needs_pm_restore: written only in vfio_pci_probe_power_state()
disable_idle_d3: written only at .init in vfio_pci_core_init_dev()
Dedicated storage units:
virq_disabled: written by guest INTx command writes in
vfio_basic_config_write() while the device is open
bardirty: written by guest BAR writes in vfio_basic_config_write()
while the device is open
pm_intx_masked: written in the runtime-PM suspend path.
pm_runtime_engaged: written by low-power feature entry/exit paths
needs_reset: set in vfio_pci_core_disable() and cleared for devices in
the set by vfio_pci_dev_set_try_reset()
sriov_active: written by vfio_pci_core_sriov_configure() via sysfs
sriov_numvfs while bound.
Fixes: 9cd0f6d5cbb6 ("vfio/pci: Use bitfield for struct vfio_pci_core_device flags") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Alex Williamson <alex.williamson@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20260615191241.688297-4-alex.williamson@nvidia.com Signed-off-by: Alex Williamson <alex@shazbot.org>
Alex Williamson [Mon, 15 Jun 2026 19:12:30 +0000 (13:12 -0600)]
vfio/pci: Release the VGA arbiter client on register_device() failure
The re-order in the Fixes commit below displaced vfio_pci_vga_init() as
the last failure point of what is now vfio_pci_core_register_device()
without introducing an unwind for the VGA arbiter registration.
In current kernels this is mostly benign because vfio_pci_set_decode()
only uses pci_dev state, but the original failure path could leave a
callback with a freed vdev cookie. The stale registration also becomes
unsafe again once the callback follows drvdata to the vfio device.
Add the required VGA unwind callout.
Fixes: 4aeec3984ddc ("vfio/pci: Re-order vfio_pci_probe()") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Alex Williamson <alex.williamson@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20260615191241.688297-3-alex.williamson@nvidia.com Signed-off-by: Alex Williamson <alex@shazbot.org>
Alex Williamson [Mon, 15 Jun 2026 19:12:29 +0000 (13:12 -0600)]
vfio/pci: Latch disable_idle_d3 per device
When disable_idle_d3 was introduced in vfio-pci, it directly manipulated
the device power state with pci_set_power_state(). There were no
refcounts to maintain or balanced operations, we could unconditionally
bring the device to D0 and conditionally move it to D3hot. Therefore
the module parameter was made writable.
Later, in commit c61302aa48f7 ("vfio/pci: Move module parameters to
vfio_pci.c"), as part of the vfio-pci-core split, the writable aspect
of the module parameter was nullified. The parameter value could still
be changed through sysfs, but the vfio-pci driver latched the values
into vfio-pci-core globals at module init. Loading the vfio-pci module,
or unloading and reloading, with non-default or different values could
change the globals relative to existing devices bound to vfio-pci
variant drivers.
Runtime PM was introduced in commit 7ab5e10eda02 ("vfio/pci: Move the
unused device into low power state with runtime PM"), which marks the
point where power states became refcounted. PM get and put operations
need to be balanced, but the same module operations noted above can
change the global variables relative to those devices already bound to
vfio-pci variant drivers. This introduces a window where PM operations
can now become unbalanced.
To resolve this with a narrow footprint for stable backports, the
disable_idle_d3 flag is latched into the vfio_pci_core_device at the
time of initialization, such that the device always operates with a
consistent value.
NB. vfio_pci_dev_set_try_reset() now unconditionally raises the
runtime PM usage count around bus reset to account for disable_idle_d3
becoming a per-device rather than global flag. When this flag is set,
the additional get/put pair is harmless and allows continued use of the
shared vfio_pci_dev_set_pm_runtime_get() helper.
Fixes: 7ab5e10eda02 ("vfio/pci: Move the unused device into low power state with runtime PM") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Alex Williamson <alex.williamson@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20260615191241.688297-2-alex.williamson@nvidia.com Signed-off-by: Alex Williamson <alex@shazbot.org>
Vijendar Mukunda [Mon, 29 Jun 2026 02:57:22 +0000 (10:57 +0800)]
MAINTAINERS: ASoC: SOF: add AMD reviewer for Sound Open Firmware
SOF spans multiple vendors and hardware paths. AMD ships ACP-based
platforms and contributes to the shared SOF tree, so list an AMD
reviewer (R:) on the SOF MAINTAINERS entry for balanced review and
correct get_maintainer coverage when shared SOF code changes.
Add:
R: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Lizhi Hou [Thu, 11 Jun 2026 05:51:50 +0000 (22:51 -0700)]
accel/amdxdna: Fix iommu domain lifetime race during device removal
When force_iova mode is enabled, amdxdna_remove() frees xdna->domain. If
amdxdna_gem_obj_free() is called after device removal, it may attempt to
access xdna->domain, resulting in a use-after-free.
Fix the race by adding freeing xdna->domain as a managed release action,
so its lifetime is managed by DRM and remains valid until all managed
resources are released.
Lizhi Hou [Thu, 11 Jun 2026 05:51:49 +0000 (22:51 -0700)]
accel/amdxdna: Fix notifier_wq lifetime race during device removal
amdxdna_remove() destroys notifier_wq. If amdxdna_gem_obj_free() is
called after device removal, it may attempt to flush notifier_wq,
resulting in a use-after-free.
Fix the race by allocating notifier_wq with
drmm_alloc_ordered_workqueue(), so its lifetime is managed by DRM and
remains valid until all managed resources are released.
Lizhi Hou [Thu, 11 Jun 2026 05:51:48 +0000 (22:51 -0700)]
accel/amdxdna: Fix amdxdna_client lifetime race during device removal
In amdxdna_remove(), all amdxdna_client structures are freed after
calling drm_dev_unplug(). However, drm_dev_unplug() does not force
existing file descriptors to be closed, so amdxdna_drm_close() may be
called after amdxdna_remove() has completed.
As a result, accessing client->pid for debug output in
amdxdna_drm_close() can lead to a use-after-free, since the access is
not protected by drm_dev_enter().
Fix this by decoupling hardware teardown from client cleanup.
amdxdna_remove() only performs hardware-related cleanup, while
per-client resources are released from amdxdna_drm_close() when the
corresponding file is closed.
Jisheng Zhang [Mon, 15 Jun 2026 04:40:35 +0000 (12:40 +0800)]
spi: dw: fix first spi transfer with dma always fallback to PIO
Even with proper dma engine support, the first spi transfer always
fallback to PIO, the reason is the dws->n_bytes is 0 after
initialization, so the dw_spi_can_dma() calling from __spi_map_msg()
return false, thus both tx_sg_mapped and rx_sg_mapped are false, so
for the first spi transfer, the spi_xfer_is_dma_mapped() reports false
thus fallback to PIO.
Although this brings no harm, we can simply fix this issue by
calcuating the "n_bytes" from xfer->bits_per_word.
projects / thirdparty / kernel / linux.git / log
