Jakub Kicinski [Wed, 24 Jun 2026 18:20:18 +0000 (11:20 -0700)]
selftests: bonding: add a test for VLAN propagation over a bonded real device
Add a regression test for the VLAN notifier handling that the netdev_work
deferral fixed.
A VLAN's real device propagates its UP/DOWN, MTU and feature changes onto
the VLANs stacked on top of it. This used to be done synchronously from the
real device's notifier and deadlocked when the real device was brought up
while enslaved to a bond (instance lock held across NETDEV_UP) and the VLAN
on top was itself a bond member: the synchronous propagation re-entered the
stack and took the same instance lock again.
The test covers both halves:
- that the deferred UP/DOWN, MTU and feature propagation actually lands on
the VLAN (link state and MTU use an ops-locked dummy, i.e. the deferral
path; features use veth, which exports vlan_features to inherit), and
- that the deadlock-prone topology - a VLAN on a dummy, with the VLAN and
the dummy each enslaved to a different bond - can be built without
hanging.
Jakub Kicinski [Wed, 24 Jun 2026 18:20:17 +0000 (11:20 -0700)]
vlan: defer real device state propagation to netdev_work
vlan_device_event() generates nested UP/DOWN, MTU and feature
change events. It executes an event for the VLAN device directly
from the notifier - while the locks of the lower device are held.
This causes deadlocks, for example:
bond (3) bond_update_speed_duplex(vlan)
| ^ v
vlan (2) UP(vlan) (4) vlan_ethtool_get_link_ksettings()
| ^ v
dummy (1) UP(dummy) (5) __ethtool_get_link_ksettings()
The dummy device is ops locked, vlan creates a nested event (2),
then bond wants to ask vlan for link state (3). bond uses the
"I'm already holding the instance lock" flavor of API. But in
this case the lock held refers to vlan itself. We hit vlan's
link settings trampoline (4) and call __ethtool_get_link_ksettings()
which tries to lock dummy. Deadlock. There's no clean way for us
to tell the vlan_ethtool_get_link_ksettings() that the caller
is already in lower device's critical section.
Defer the propagation to the per-netdev work facility instead:
the notifier only schedules netdev_work_sched(vlandev, VLAN_WORK_*),
and ndo_work (vlan_dev_work) applies the change later. Hopefully
nobody expects the VLAN state changes to be instantaneous.
If someone does expect the changes to be instantaneous we will
have to do the same thing Stan did for rx_mode and "strategically"
place sync calls, to make sure such delayed works are executed
after we drop the ops lock but before we drop rtnl_lock.
Stan suggests that if we need that down the line we may
consider reshaping the mechanism into "async notifications".
AFAICT only vlan does this sort of netdev open chaining,
so as a first try I think that sticking the complexity into
the vlan code makes sense.
One corner case is that we need to cancel the event if user
explicitly changes the state before work could run. Consider
the following operations with vlan0 on top of dummy0:
ip link set dev dummy0 up # queues work to up vlan0
ip link set dev vlan0 down # user explicitly downs the vlan
ndo_work # acts on the stale event
Reported-by: syzbot+09da62a8b78959ceb8bb@syzkaller.appspotmail.com Reported-by: syzbot+cb67c392b0b8f0fd0fc1@syzkaller.appspotmail.com Reported-by: syzbot+9bb8bd77f3966641f298@syzkaller.appspotmail.com Fixes: 9f275c2e9020 ("net: ethtool: make sure __ethtool_get_link_ksettings() is ops-locked") Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20260624182018.2445732-4-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Wed, 24 Jun 2026 18:20:16 +0000 (11:20 -0700)]
net: add the driver-facing netdev_work scheduling API
With an extra event mask we can easily extend the netdev work
to also service driver-defined events. For advanced drivers
this is probably not a perfect match, but it makes running
deferred work easier in simple cases.
Expose the netdev_work facility to drivers. Add helpers
to schedule work and a dedicated ndo to perform the driver-
-scheduled actions.
Jakub Kicinski [Wed, 24 Jun 2026 18:20:15 +0000 (11:20 -0700)]
net: turn the rx_mode work into a generic netdev_work facility
The rx_mode update runs from a workqueue: drivers have their
ndo_set_rx_mode_async() callback executed by a single global
work item under RTNL and ops lock. This is a useful pattern.
Support multiple "events" that need to be serviced and make RX_MODE
sync the first one. Call the events "core" because later on
we will let drivers define and schedule their own.
Looks like I missed ethtool_op_get_link() trying to sync linkwatch,
which needs rtnl_lock. Not all drivers do this - bnxt doesn't,
it just returns the link state, so add an opt-in bit.
Reported-by: Breno Leitao <leitao@debian.org> Fixes: 45079e00133e ("net: ethtool: optionally skip rtnl_lock on Netlink path for GET ops") Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Breno Leitao <leitao@debian.org> Acked-by: Harshitha Ramamurthy <hramamurthy@google.com> Link: https://patch.msgid.link/20260624190439.2521219-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Thu, 25 Jun 2026 17:07:35 +0000 (10:07 -0700)]
Merge branch 'rxrpc-miscellaneous-fixes'
David Howells says:
====================
rxrpc: Miscellaneous fixes
Here are some miscellaneous AF_RXRPC fixes for more stuff found by Sashiko[1][2]:
(1) Fix ACKALL handling by adding two more call states to simplify when
ACKs are valid.
(2) Fix connection leak from AF_RXRPC recvmsg userspace OOB handling.
(3) Fix double unlock in AF_RXRPC recvmsg userspace OOB handling.
(4) Fix AFS preallocate charge to flush the waitqueue after unlistening
the socket so that any charging thread that does manage to get started
will be waited for before socket destruction.
(5) Fix AFS OOB notify handling to cancel in-progress OOB notification
handling and then to flush the workqueue it's on.
(6) Fix handling of apparent reply reception before initial transmission
starts in client call.
(7) Fix OOB challenge leak in cleanup on notification failure.
(8) Fix infinite loop in recvmsg if OOB packet available, but no calls.
(9) Fix notify vs recvmsg race where notify thinks the call is already
queued.
(10) Fix MSG_PEEK call leak for calls with no content.
(11) Fix rxrpc_rotate_tx_window() to check that there's something in the Tx
buffer before attempting to rotate it.
====================
David Howells [Wed, 24 Jun 2026 16:38:17 +0000 (17:38 +0100)]
rxrpc: Fix leak of released call in recvmsg(MSG_PEEK)
Fix rxrpc_recvmsg() to also drop the ref it holds on an already-released
call if MSG_PEEK is in force (the function holds a ref on the call
irrespective of whether MSG_PEEK is specified or not).
David Howells [Wed, 24 Jun 2026 16:38:16 +0000 (17:38 +0100)]
rxrpc: Fix socket notification race
There's a race between rxrpc_recvmsg() and rxrpc_notify_socket(), whereby
the latter's attempt to avoid disabling interrupts and taking the socket's
recvmsg_lock if the call is already queued may happen simultaneously with
the former's discarding of a call that has nothing queued.
Fix this by removing the shortcut. Note that this only affects userspace's
use of AF_RXRPC; the AFS filesystem driver doesn't use the socket queue.
David Howells [Wed, 24 Jun 2026 16:38:14 +0000 (17:38 +0100)]
rxrpc: Fix oob challenge leak in cleanup after notification failure
Fix rxrpc_notify_socket_oob() to return an indication of failure in the
event that it failed to queue a packet and fix rxrpc_post_challenge() to
clean up the connection ref in such an event.
David Howells [Wed, 24 Jun 2026 16:38:13 +0000 (17:38 +0100)]
rxrpc: Fix the reception of a reply packet before data transmission
Fix rxrpc_receiving_reply() to handle the reception of an apparent reply
DATA packet before rxrpc has had a chance to send any request DATA packets
on a client call by checking to see if the call has been exposed yet by
sending the first packet.
Without this, rxrpc_rotate_tx_window() might oops.
Also fix rxrpc_rotate_tx_window() to handle the Tx queue being empty by
changing the do...while loop into a while loop, just in case a call is
abnormally terminated by an early reply before the last request packet is
transmitted.
David Howells [Wed, 24 Jun 2026 16:38:12 +0000 (17:38 +0100)]
afs: Fix uncancelled rxrpc OOB message handler
Fix AFS to cancel its OOB message processing (typically to respond to
security challenges). Also move OOB message processing to afs_wq so that
it's also waited for and make the OOB handler just return if the net
namespace is no longer live.
Fixes: 5800b1cf3fd8 ("rxrpc: Allow CHALLENGEs to the passed to the app for a RESPONSE") Link: https://sashiko.dev/#/patchset/20260609140911.838677-1-dhowells%40redhat.com Signed-off-by: David Howells <dhowells@redhat.com>
cc: Li Daming <d4n.for.sec@gmail.com>
cc: Ren Wei <n05ec@lzu.edu.cn>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Jeffrey Altman <jaltman@auristor.com>
cc: Simon Horman <horms@kernel.org>
cc: linux-afs@lists.infradead.org
cc: stable@kernel.org Link: https://patch.msgid.link/20260624163819.3017002-6-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
David Howells [Wed, 24 Jun 2026 16:38:11 +0000 (17:38 +0100)]
afs: Fix further netns teardown to cancel the preallocation charger
When an afs network namespace is torn down, it cancels and waits for the
work item that keeps the preallocated rxrpc call/conn/peer queue charged
before disabling incoming (i.e. listen 0), but there's a small window in
which it can be requeued by an incoming call wending through the I/O
thread.
Fix this by cancelling the charger work item again after reducing the
listen backlog to zero.
Fixes: 47694fbc9d24 ("afs: Fix netns teardown to cancel the preallocation charger") Reported-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David Howells <dhowells@redhat.com> Link: https://sashiko.dev/#/patchset/20260609140911.838677-1-dhowells%40redhat.com
cc: Li Daming <d4n.for.sec@gmail.com>
cc: Ren Wei <n05ec@lzu.edu.cn>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Jeffrey Altman <jaltman@auristor.com>
cc: Simon Horman <horms@kernel.org>
cc: linux-afs@lists.infradead.org
cc: stable@kernel.org Link: https://patch.msgid.link/20260624163819.3017002-5-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Wyatt Feng [Wed, 24 Jun 2026 16:38:08 +0000 (17:38 +0100)]
rxrpc: Fix ACKALL packet handling
rxrpc_input_ackall() accepts ACKALL packets without checking whether the
call is in a state that can legitimately have outstanding transmit buffers.
A forged ACKALL can therefore reach a new service call in
RXRPC_CALL_SERVER_RECV_REQUEST before any reply packets have been queued.
In that state call->tx_top is zero and call->tx_queue is NULL, so
rxrpc_rotate_tx_window() dereferences a NULL txqueue and triggers a
null-pointer dereference.
Fix the handling of ACKALL packets by the following means:
(1) Add two new call states: RXRPC_CALL_CLIENT_PRE_SEND which indicates
that the client call is connected, but nothing has been transmitted as
yet; and RXRPC_CALL_CLIENT_AWAIT_ACK, which indicates that everything
has been transmitted at least once, but we're now waiting for the
stuff remaining in the Tx buffer to be ACK'd (retransmissions may
still happen).
The RXRPC_CALL_CLIENT_PRE_SEND state is set when the call is assigned
a channel and transitions to RXRPC_CALL_CLIENT_SEND_REQUEST when the
first packet is transmitted.
RXRPC_CALL_CLIENT_AWAIT_REPLY is then narrowed in scope to indicate
that all Tx packets have been ACK'd and we're now waiting for the
reply to be received.
(2) As per Wyatt Feng's original patch[1], the ACKALL handler then checks
that the call state is one in which there might be stuff in the Tx
buffer to ACK, but now this includes AWAIT_ACK rather than
AWAIT_REPLY. ACKALL packets are ignored if received in the wrong
state.
Note that unlike Wyatt Feng's patch, it's no longer necessary to check
to see if the Tx buffer exists as this the state set now covers this.
(3) Make the ACKALL handler use call->tx_transmitted rather than
call->tx_top as the former is explicitly the highest packet seq number
transmitted, whereas the latter has a looser definition.
Thanks to Jeffrey Altman for a description of the history of the ACKALL
packet[1].
Fixes: b341a0263b1b ("rxrpc: Implement progressive transmission queue struct") Reported-by: Yuan Tan <yuantan098@gmail.com> Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Reported-by: Zhengchuan Liang <zcliangcn@gmail.com> Reported-by: Xin Liu <bird@lzu.edu.cn> Signed-off-by: Wyatt Feng <bronzed_45_vested@icloud.com> Co-developed-by: David Howells <dhowells@redhat.com> Signed-off-by: David Howells <dhowells@redhat.com>
cc: Ren Wei <n05ec@lzu.edu.cn>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: linux-afs@lists.infradead.org Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20260616155749.2125907-2-dhowells@redhat.com/ Link: https://lore.kernel.org/r/c0fd4fec-1576-4070-b31e-a37d5506f5ed@auristor.com/ Reviewed-by: Jeffrey Altman <jaltman@auristor.com> Link: https://patch.msgid.link/20260624163819.3017002-2-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Linus Torvalds [Thu, 25 Jun 2026 16:56:47 +0000 (09:56 -0700)]
Merge tag 'block-7.2-20260625' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
Pull block fixes from Jens Axboe:
- blk-cgroup locking rework and fixes:
- fix a use-after-free in __blkcg_rstat_flush()
- defer freeing policy data until after an RCU grace period
- defer the blkcg css_put until the blkg is unlinked from
the queue
- unwind the queue_lock nesting under RCU / blkcg->lock
across the lookup, create, associate and destroy paths
- NVMe fixes via Keith:
- Fix a crash and memory leak during invalid cdev teardown,
and related cdev cleanups (Maurizio, John)
- nvmet fixes: handle TCP_CLOSING in the tcp state_change
handler, reject short AUTH_RECEIVE buffers, handle inline
data with a nonzero offset in rdma, fix an sq refcount leak,
and allocate ana_state with the port (Maurizio, Michael,
Bryam, Wentao, Rosen)
- nvme-fc fix to not cancel requests on an IO target before it
is initialized (Mohamed)
- nvme-apple fix to prevent shared tags across queues on Apple
A11 (Nick)
- Various smaller fixes and cleanups (John)
- MD fixes via Yu Kuai:
- raid1/raid10 fixes for writes_pending and barrier reference
leaks on write and discard failures, plus REQ_NOWAIT handling
fixes (Abd-Alrhman)
- raid5 discard accounting and validation, and a batch of fixes
for stripe batch races (Yu Kuai, Chen)
- Protect raid1 head_position during read balancing (Chen)
- block bio-integrity fixes: correct an error injection static key
decrement, fix GFP flag confusion in bio_integrity_alloc_buf(), and
handle REQ_OP_ZONE_APPEND in __bio_integrity_action() (Christoph)
- Fixes for bio_iov_iter_bounce_write(): revert the iov_iter after a
short copy, and respect the iov_iter nofault flag (Qu)
- Invalidate the cached plug timestamp after a task switch, and clear
PF_BLOCK_TS in copy_process() (Usama)
- Fix the IORING_URING_CMD_REISSUE flags check in blkdev_uring_cmd()
(Yitang)
- Remove a redundant plug in __submit_bio() (Wen)
- Don't warn when reclassifying a busy socket lock in nbd (Deepanshu)
* tag 'block-7.2-20260625' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: (45 commits)
block: handle REQ_OP_ZONE_APPEND in __bio_integrity_action
block: fix GFP_ flags confusion in bio_integrity_alloc_buf
block, bfq: don't grab queue_lock to initialize bfq
mm/page_io: don't nest queue_lock under rcu in bio_associate_blkg_from_page()
blk-cgroup: don't nest queue_lock under blkcg->lock in blkcg_destroy_blkgs()
blk-cgroup: don't nest queue_lock under rcu in bio_associate_blkg()
blk-cgroup: don't nest queue_lock under rcu in blkg_lookup_create()
blk-cgroup: don't nest queue_lock under rcu in blkcg_print_blkgs()
blk-cgroup: delay freeing policy data after rcu grace period
blk-cgroup: protect iterating blkgs with blkcg->lock in blkcg_print_stat()
md/raid5: avoid R5_Overlap races while breaking stripe batches
md/raid5: use stripe state snapshot in break_stripe_batch_list()
blk-cgroup: defer blkcg css_put until blkg is unlinked from queue
blk-cgroup: fix UAF in __blkcg_rstat_flush()
block, bfq: protect async queue reset with blkcg locks
nbd: don't warn when reclassifying a busy socket lock
block: fix incorrect error injection static key decrement
md/raid5: let stripe batch bm_seq comparison wrap-safe
md/raid1: protect head_position for read balance
md/raid1: free r1_bio when REQ_NOWAIT is set and read would block on retry
...
Linus Torvalds [Thu, 25 Jun 2026 16:53:31 +0000 (09:53 -0700)]
Merge tag 'io_uring-7.2-20260625' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
Pull io_uring fixes from Jens Axboe:
- Fix a file reference leak in the nop opcode when used with
IOSQE_FIXED_FILE
- Preserve the SQ array entries when resizing the ring via the register
path
- Preserve the partial result for an iopoll request rather than
overwriting it
- Don't audit log IORING_OP_RECV_ZC
- Bound io_pin_pages() by the page array byte size in the memmap path
- Follow-up cleanup to the task_work mpscq conversion, getting rid of
the now-unnecessary tw_pending tracking for the !DEFER_TASKRUN path
- Switch a system_unbound_wq user over to system_dfl_wq
* tag 'io_uring-7.2-20260625' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
io_uring/memmap: bound io_pin_pages() by page array byte size
io_uring: Use system_dfl_wq instead of system_unbound_wq
io_uring/register: preserve SQ array entries on resize
io_uring, audit: don't log IORING_OP_RECV_ZC
io_uring: get rid of tw_pending for !DEFER task work
io_uring/rw: preserve partial result for iopoll
io_uring/nop: fix file reference leak with IOSQE_FIXED_FILE
Praveen Talari [Thu, 25 Jun 2026 15:56:02 +0000 (21:26 +0530)]
spi: core: Abort active target transfer on controller suspend
When an SPI controller operating in target mode has a transfer in
progress at the time of system suspend, the suspend path proceeds
without aborting the ongoing transfer. This can leave the hardware in
an inconsistent state, potentially causing the system to hang or fail
to resume cleanly.
Fix this by invoking the controller's target_abort callback from
spi_controller_suspend() when the controller is in target mode and the
callback is registered. This ensures any active target transfer is
cleanly terminated before the controller is suspended.
Pengpeng Hou [Wed, 24 Jun 2026 14:43:13 +0000 (22:43 +0800)]
fbdev: viafb: return an error when DMA copy times out
viafb_dma_copy_out_sg() logs a VIA DMA timeout when the DONE bit is not
set after the completion wait and grace delay, but still returns success
to the caller.
Preserve the existing cleanup sequence and return -ETIMEDOUT when the DMA
engine did not report completion.
Linus Torvalds [Thu, 25 Jun 2026 16:33:23 +0000 (09:33 -0700)]
Merge tag 'gpio-fixes-for-v7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio fixes from Bartosz Golaszewski:
- fix locking context with shared GPIOs in gpio-tegra
- fix IRQ domain leak in error path in gpio-davinci
- fix returning a potentially uninitialized integer in
gpiochip_set_multiple()
- use raw spinlock in gpio-eic-sprd and gpio-sch to address locking
context issues
- bail out of probe() if registering the GPIO chip fails in gpio-mlxbf3
- fix varible type for storing the "ngpios" property in gpio-pisosr
- fix out-of-bounds pin access in GPIO ACPI
- make GPIO ACPI core only trigger interrupts on boot that are marked
as ActiveBoth
- fix kerneldoc in gpio-tb10x
- reference the real software node of the cs5535 GPIO controller in
Geode board file
* tag 'gpio-fixes-for-v7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
gpio: davinci: fix IRQ domain leak on devm_kzalloc failure
gpio: tegra: do not call pinctrl for GPIO direction
gpio: tb10x: fix struct tb10x_gpio kernel-doc
gpiolib: initialize return value in gpiochip_set_multiple()
x86/platform/geode: reference the real node of the cs5535 GPIO controller
gpio: eic-sprd: use raw_spinlock_t in the irq startup path
gpio: sch: use raw_spinlock_t in the irq startup path
gpiolib: acpi: Prevent out-of-bounds pin access in OperationRegion handler
gpiolib: acpi: Add robust bounds-checking for GPIO pin resources
gpio: mlxbf3: fail probe if gpiochip registration fails
gpio: pisosr: Read "ngpios" as u32
gpiolib: acpi: Only trigger ActiveBoth interrupts on boot
Pengpeng Hou [Thu, 25 Jun 2026 03:01:02 +0000 (11:01 +0800)]
fbdev: goldfishfb: fail pan display on base-update timeout
goldfish_fb_pan_display() waits for the device to acknowledge the new
framebuffer base, but it only logs a timeout and still reports success.
The probe path also ignores the initial pan-display result before
registering the framebuffer.
Return -ETIMEDOUT when the base-update acknowledgment does not arrive,
and propagate that error from the initial probe-time base update before
the framebuffer is published.
Linus Torvalds [Thu, 25 Jun 2026 16:20:26 +0000 (09:20 -0700)]
Merge tag 'pwrseq-fixes-for-v7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull power sequencing fixes from Bartosz Golaszewski:
- fix an ABBA deadlock in pwrseq unregister path
- fix a use-after-free bug in pwrseq core
- sort PCI device IDs in ascending order in pwrseq-pcie-m2
* tag 'pwrseq-fixes-for-v7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
power: sequencing: fix ABBA deadlock in pwrseq_device_unregister()
power: sequencing: pcie-m2: Sort PCI device IDs in ascending order
pwrseq: core: fix use-after-free in pwrseq_debugfs_seq_next()
Mingyu Wang [Thu, 25 Jun 2026 16:03:06 +0000 (00:03 +0800)]
fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font()
When fbcon_do_set_font() fails (e.g., due to a memory allocation failure
inside vc_resize() under heavy memory pressure), it jumps to the `err_out`
label to roll back the console state. However, the current rollback logic
forgets to restore the `hi_font` state, leading to a severe state machine
corruption.
Earlier in the function, `set_vc_hi_font()` might be called to change
`vc->vc_hi_font_mask` and mutate the screen buffer. If `vc_resize()`
subsequently fails, the `err_out` path restores `vc_font.charcount`
but entirely skips rolling back the `vc_hi_font_mask` and the screen
buffer.
This mismatch leaves the terminal in a desynchronized state. Because
`vc_hi_font_mask` remains set, the VT subsystem will still accept
character indices greater than 255 from userspace and write them to the
screen buffer. Subsequent rendering calls (e.g., `fbcon_putcs()`) will
then use these inflated indices to access the reverted, 256-character
font array, leading to a deterministic out-of-bounds read and potential
kernel memory disclosure.
Fix this by adding the missing rollback logic for the `hi_font` mask
and screen buffer in the error path.
Fixes: a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize() failed") Cc: stable@vger.kernel.org Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Helge Deller <deller@gmx.de>
====================
net: hns3: fix configuration deadlocks and refactor link setup
This patch series addresses a sequence of link configuration deadlocks
and parameter contamination issues in the hns3 network driver, which
typically occur during hardware resets or driver initialization under
specific user-configured scenarios.
The bugs root from asynchronous discrepancies between the MAC state
machine and cached user requests during sudden hardware resets, leading
to invalid parameter combos or frozen registers.
====================
Shuaisong Yang [Wed, 24 Jun 2026 14:13:19 +0000 (22:13 +0800)]
net: hns3: differentiate autoneg default values between copper and fiber
Fix a link loss issue during driver initialization on optical ports
connected to forced-mode (non-autoneg) remote switches.
Previously, during driver probe or initialization, hclge_configure()
blindly hardcoded hdev->hw.mac.req_autoneg to AUTONEG_ENABLE for all
media types. While this is necessary for copper (BASE-T) ports to
establish a link, many high-speed optical (fiber) ports in data
centers are connected to switches running in forced mode (fixed speed,
autoneg disabled). Forcing autoneg on these optical ports during
initialization causes a permanent link failure since the remote end
refuses to respond to autoneg pulses.
Fix this by implementing media-type differentiated initialization in
hclge_init_ae_dev(). Copper ports continue to default to
AUTONEG_ENABLE, while optical ports strictly inherit the preset
autoneg status pre-configured by the firmware (hdev->hw.mac.autoneg),
preserving native compatibility with forced-mode network environments.
Fixes: 05eb60e9648c ("net: hns3: using user configure after hardware reset") Signed-off-by: Shuaisong Yang <yangshuaisong@h-partners.com> Signed-off-by: Jijie Shao <shaojijie@huawei.com> Link: https://patch.msgid.link/20260624141319.271439-5-shaojijie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Shuaisong Yang [Wed, 24 Jun 2026 14:13:18 +0000 (22:13 +0800)]
net: hns3: fix permanent link down deadlock after reset
Fix a critical race condition deadlock where the network interface
remains permanently Link Down after a hardware reset under specific
ethtool sequences.
This issue exclusively manifests in firmware-controlled PHY topologies
where the driver relies on the IMP firmware to arbitrate link parameters.
Standard devices driven by the kernel's native PHY_LIB are unaffected.
The deadlock occurs via the following path:
1. User disables autoneg and forces an unmatched speed, forcing link
down: `ethtool -s ethx autoneg off speed 10 duplex full`
2. User re-enables autoneg: `ethtool -s ethx autoneg on`. The netdev
stack passes cmd->base.speed as SPEED_UNKNOWN (0xffffffff).
3. Driver saves req_autoneg=1, but before the interface can link up,
a hardware reset is triggered.
4. During reset recovery, MAC init reads the un-synchronized runtime
state mac.autoneg (which is still 0/OFF), misinterprets it as
forced mode, and pushes the cached SPEED_UNKNOWN into the hardware
registers, causing the MAC firmware state machine to freeze.
Meanwhile, PHY init reads req_autoneg=1 and enables PHY autoneg.
Since the MAC is frozen with 0xffffffff and PHY is running autoneg,
they mismatch permanently.
Fix this by:
1. Intercepting SPEED_UNKNOWN/DUPLEX_UNKNOWN in
hclge_set_phy_link_ksettings() and hclge_cfg_mac_speed_dup_h() to
prevent it from corrupting the driver's cached valid configuration.
2. Save req_autoneg in hclge_set_autoneg().
3. Aligning the state judgment in hclge_set_autoneg_speed_dup() to use
req_autoneg instead of the un-synchronized runtime mac.autoneg,
ensuring both MAC and PHY consistently enter the autoneg branch to
eliminate configuration discrepancies during reset recovery.
Fixes: 05eb60e9648c ("net: hns3: using user configure after hardware reset") Signed-off-by: Shuaisong Yang <yangshuaisong@h-partners.com> Signed-off-by: Jijie Shao <shaojijie@huawei.com> Link: https://patch.msgid.link/20260624141319.271439-4-shaojijie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Shuaisong Yang [Wed, 24 Jun 2026 14:13:17 +0000 (22:13 +0800)]
net: hns3: refactor MAC autoneg and speed configuration
Extract the MAC autoneg and speed/duplex/lane configuration logic out
of hclge_mac_init() and encapsulate it into a new dedicated helper
function hclge_set_autoneg_speed_dup().
In the init path (hclge_init_ae_dev), this helper is now called after
hclge_update_port_info() so that firmware-reported autoneg values are
already populated before applying the link configuration.
Introduce a separate req_lane_num field in struct hclge_mac to isolate
the user-requested lane count from mac.lane_num, which firmware may
overwrite via hclge_get_sfp_info() with stale values from a prior link
lifecycle (e.g., lane_num=4 from 100G). During probe, req_lane_num is
initialized to 0, which instructs firmware to auto-select the correct
lane count for the current speed, rather than reusing the firmware-
reported mac.lane_num that may be inconsistent with the target speed.
This prevents probe failures from mismatched (speed, lane_num) pairs.
In the reset path (hclge_reset_ae_dev), it runs immediately after
hclge_mac_init(), using the previously cached req_* values to restore
the link without re-querying firmware.
Shuaisong Yang [Wed, 24 Jun 2026 14:13:16 +0000 (22:13 +0800)]
net: hns3: unify copper port ksettings configuration path
Refactor hns3_set_link_ksettings() and hclge_set_phy_link_ksettings()
to unify the configuration path for copper ports.
Previously, netdevs with a native kernel phy attached bypassed the main
MAC parameter caching logic and returned early via
phy_ethtool_ksettings_set(). This prevented the driver from updating
hdev->hw.mac.req_xxx variables for kernel PHY setups, leaving them
out-of-sync during reset recovery.
Clean this up by routing all copper port configurations through
ops->set_phy_link_ksettings(), and perform driver-level or kernel-level
PHY arbitration inside hclge_set_phy_link_ksettings() via
hnae3_dev_phy_imp_supported(). This ensures that the user's intended link
profiles (req_speed, req_duplex, req_autoneg) are uniformly recorded
across all copper and fiber deployment topologies, laying the groundwork
for stable reset recovery.
For copper ports where neither IMP firmware nor a kernel PHY is available
(e.g. PHY_INEXISTENT), hclge_set_phy_link_ksettings() returns -ENODEV.
In hns3_set_link_ksettings(), this is caught so the configuration falls
through to the existing MAC-level path (check_ksettings_param ->
cfg_mac_speed_dup_h), preserving compatibility with PHY-less copper
deployments.
Shradha Gupta [Wed, 24 Jun 2026 07:21:35 +0000 (00:21 -0700)]
net: mana: Optimize irq affinity for low vcpu configs
Before the commit 755391121038 ("net: mana: Allocate MSI-X vectors
dynamically"), all the MANA IRQs were assigned statically and together
during early driver load.
After this commit, the IRQ allocation for MANA was done in two phases.
HWC IRQ allocated earlier and then, queue IRQs dynamically added at a
later point. By this time, the IRQ weights on vCPUs can become imbalanced
and if IRQ count is greater than the vCPU count the topology aware IRQ
distribution logic in MANA can cause multiple MANA IRQs to land on the
same vCPUs, while other sibling vCPUs have none (case 1).
On SMP enabled, low-vCPU systems, this becomes a bigger problem as the
softIRQ handling overhead of two IRQs on the same vCPUs becomes much more
than their overheads if they were spread across sibling vCPUs.
In such cases when many parallel TCP connections are tested, the
throughput drops significantly.
Fix the affinity assignment logic, in cases where the IRQ count is greater
than the vCPU count and when IRQs are added dynamically, by utilizing all
the vCPUs irrespective of their NUMA/core bindings (case 2).
The results of setting the affinity and hint to NULL were also studied,
and we observed that, with this logic if there are pre-existing IRQs
allocated on the VM (apart from MANA), during MANA IRQs allocation, it
leads to clustering of the MANA queue IRQs again (case 3).
=======================================================
Case 1: without this patch
=======================================================
4 vcpu(2 cores), 5 MANA IRQs (1 HWC + 4 Queue)
%soft on each vCPU(mpstat -P ALL 1) on receiver
vCPU 0 1 2 3
=======================================================
pass 1: 38.85 0.03 24.89 24.65
pass 2: 39.15 0.03 24.57 25.28
pass 3: 40.36 0.03 23.20 23.17
=======================================================
Case 2: with this patch
=======================================================
4 vcpu(2 cores), 5 MANA IRQs (1 HWC + 4 Queue)
%soft on each vCPU(mpstat -P ALL 1) on receiver
vCPU 0 1 2 3
=======================================================
pass 1: 15.42 15.85 14.99 14.51
pass 2: 15.53 15.94 15.81 15.93
pass 3: 16.41 16.35 16.40 16.36
=======================================================
Case 3: with affinity set to NULL
=======================================================
4 vCPU(2 cores), 5 MANA IRQs (1 HWC + 4 Queue)
Linus Torvalds [Thu, 25 Jun 2026 16:09:38 +0000 (09:09 -0700)]
Merge tag 'docs-7.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/docs/linux
Pull more documentation updates from Jonathan Corbet:
"A handful of late-arriving docs fixes, along with one document update
that fell through the cracks before"
* tag 'docs-7.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/docs/linux:
docs: tools: Fix typo 'ackward' to 'awkward' in unittest.rst
kdoc: xforms: ignore special static/inline macros
kdoc: xforms_lists: handle DECLARE_PER_CPU() in kernel-doc
MAINTAINERS: Fix regex for kdoc
docs: kgdb: Fix path of driver options
Documentation: tracing: fix typo in events documentation
Docs/driver-api/uio-howto: document mmap_prepare callback
docs/mm: clarify that we are not looking for LLM generated content
kernel-doc: xforms: support __SYSFS_FUNCTION_ALTERNATIVE()
Linus Torvalds [Thu, 25 Jun 2026 16:06:12 +0000 (09:06 -0700)]
Merge tag 'kbuild-7.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux
Pull more Kbuild updates from Nathan Chancellor:
- Link host programs with ld.lld when $(LLVM) is set to match user's
expectations that LLVM will be used exclusively during the build
process
- Fix modpost warnings from static variable name promotion that can
happen more aggressively with the recently merged distributed ThinLTO
support
- Add an optional warning for user-supplied Kconfig values that changed
after processing, such as out of range values or options that have
incorrect / missing dependencies
* tag 'kbuild-7.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux:
kconfig: add optional warnings for changed input values
modpost: Ignore Clang LTO suffixes in symbol matching
kbuild: Use ld.lld for linking host programs when LLVM is set
Nirmoy Das [Wed, 24 Jun 2026 13:44:16 +0000 (06:44 -0700)]
selftests: tls: size splice_short pipe by page size
splice_short grows its pipe with (MAX_FRAGS + 1) * 0x1000 so it can
queue one short vmsplice() buffer for each fragment before draining the
pipe. That assumes 4K pipe buffers.
On 64K-page kernels the request is rounded to 262144 bytes, which
provides only four pipe buffers. The fifth one-byte vmsplice() blocks in
pipe_wait_writable and the test times out before it reaches the TLS path.
Request enough bytes for the same number of pipe buffers using the
runtime page size, and assert that the kernel granted at least that much.
If an unprivileged run cannot raise the pipe above the system
pipe-max-size limit, skip the test because it cannot exercise the
intended path.
Fixes: 3667e9b442b9 ("selftests: tls: add test for short splice due to full skmsg") Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260624134416.3235403-1-nirmoyd@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Linus Torvalds [Thu, 25 Jun 2026 16:00:53 +0000 (09:00 -0700)]
Merge tag 'for-linus-7.2-1' of https://github.com/cminyard/linux-ipmi
Pull ipmi updates from Corey Minyard:
"Lots of little tweaks.
Nothing huge, the biggest issue was a possible refcount underflow that
could cause a memory leak in some situations. Otherwise, fixing
formatting and style things and some docs typos"
* tag 'for-linus-7.2-1' of https://github.com/cminyard/linux-ipmi:
docs: ipmi: Fix path of the "hotmod" module parameter
ipmi: Drop unused assignment of platform_device_id driver data
ipmi: si: Use platform_get_irq_optional() to retrieve interrupt
ipmi: fix refcount leak in i_ipmi_request()
ipmi:ssif: Drop unused assignment of platform_device_id driver data
ipmi: Fix user refcount underflow in event delivery
ipmi: Use named initializers for struct i2c_device_id
ipmi: Use LIST_HEAD() to initialize on stack list head
ipmi:kcs: Reduce the number of retries
Haoxiang Li [Tue, 23 Jun 2026 11:57:14 +0000 (19:57 +0800)]
net: sparx5: unregister blocking notifier on init failure
sparx5_register_notifier_blocks() registers the switchdev blocking
notifier before allocating the ordered workqueue. If the workqueue
allocation fails, the error path unregisters the switchdev and netdevice
notifiers, but leaves the blocking notifier registered.
Add a separate error label for the workqueue allocation failure path and
unregister the switchdev blocking notifier there.
Fixes: d6fce5141929 ("net: sparx5: add switching support") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260623115714.2192074-1-haoxiang_li2024@163.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Eric Dumazet [Tue, 23 Jun 2026 17:30:30 +0000 (17:30 +0000)]
tipc: avoid busy looping in tipc_exit_net()
Blamed commit introduced a busy-wait loop in tipc_exit_net()
to wait for pending UDP bearer cleanup works to complete:
while (atomic_read(&tn->wq_count))
cond_resched();
This loop can busy-wait for a long time if cond_resched() is a NOP. This
typically happens if the netns exit is executed by a high priority task,
or under kernels configured without preemption (CONFIG_PREEMPT_NONE). In
such cases, it wastes CPU cycles and can lead to soft lockups.
Fix this by replacing the busy loop with wait_var_event(), allowing the
thread to sleep properly until the work queue count reaches zero.
Accordingly, update cleanup_bearer() to use atomic_dec_and_test() and
wake_up_var() to wake up the waiter when the count drops to zero.
This uses the global wait queue hash table, avoiding the need to bloat
struct tipc_net with a wait_queue_head_t. The atomic_dec_and_test()
provides the necessary memory barrier to ensure the wakeup is not missed.
Fixes: 04c26faa51d1 ("tipc: wait and exit until all work queues are done") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Jon Maloy <jmaloy@redhat.com> Cc: tipc-discussion@lists.sourceforge.net Reviewed-by: Xin Long <lucien.xin@gmail.com> Link: https://patch.msgid.link/20260623173030.2925059-3-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Eric Dumazet [Tue, 23 Jun 2026 17:30:29 +0000 (17:30 +0000)]
tipc: fix UAF in cleanup_bearer() due to premature dst_cache_destroy()
TIPC UDP media bearer teardown calls dst_cache_destroy() on its
replicast caches before calling synchronize_net() to wait for
concurrent RCU readers (transmitters) to finish:
This is highly buggy because dst_cache_destroy() immediately frees the
per-CPU cache memory (free_percpu()) and releases the cached dst
entries without any synchronization.
If a concurrent transmitter (e.g., tipc_udp_xmit()) is running on another
CPU under RCU protection, it can call dst_cache_get() concurrently,
leading to:
1. Use-After-Free on the per-CPU cache pointer itself (crash).
2. "rcuref - imbalanced put()" warning if it attempts to release a
dst that was concurrently released by dst_cache_destroy().
Furthermore, calling kfree(ub) immediately after synchronize_net() without
closing the socket first (or waiting after closing it) leaves a window
where a concurrent receiver (tipc_udp_recv()) could start after
synchronize_net(), access ub, and suffer a UAF when kfree(ub) runs.
To fix this, we must defer dst_cache_destroy() and kfree(ub) until after
we have ensured that no more readers can see the bearer/socket and all
existing readers have finished:
1. Defer rcast entry destruction (both dst_cache_destroy() and kfree())
to an RCU callback using call_rcu_hurry().
Using call_rcu_hurry() ensures the dst entries are released quickly.
2. Release the bearer socket using udp_tunnel_sock_release() (stops
new receive readers).
3. Call synchronize_net() to wait for all outstanding RCU readers
(both transmit and receive) to finish.
4. Now that it is safe, call dst_cache_destroy() on the main bearer
cache, and free ub.
Note: 3) and 4) can be changed later in net-next to also use
call_rcu_hurry() and get rid of the synchronize_net() latency.
Fixes: e9c1a793210f ("tipc: add dst_cache support for udp media") Reported-by: syzbot+e14bc5d4942756023b77@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a396a66.52ae72c2.136ac7.0003.GAE@google.com/T/#u Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Jon Maloy <jmaloy@redhat.com> Cc: tipc-discussion@lists.sourceforge.net Reviewed-by: Xin Long <lucien.xin@gmail.com> Link: https://patch.msgid.link/20260623173030.2925059-2-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Haoxiang Li [Tue, 23 Jun 2026 11:43:16 +0000 (19:43 +0800)]
octeontx2-af: Free BPID bitmap on setup failure
nix_setup_bpids() allocates bp->bpids with rvu_alloc_bitmap(), which uses
a plain kcalloc(). If any of the following devm_kcalloc() allocations for
the BPID mapping arrays fails, the function returns without freeing the
bitmap. Free the BPID bitmap before returning from those error paths.
Fixes: d6212d2e41a0 ("octeontx2-af: Create BPIDs free pool") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260623114316.2182271-1-haoxiang_li2024@163.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: ethernet: qualcomm: ppe: Demote from supported and fix maintainer addresses
Emails to the maintainer of Qualcomm PPE Ethernet driver (Luo Jie
<quic_luoj@quicinc.com>) bounce permanently (full mailbox), because the
"quicinc.com" addresses were deprecated for public work. All Qualcomm
contributors are aware of that and were asked to fix their addresses.
Driver is not supported - in terms of how netdev understands supported
commitment - if maintainer does not care to receive the patches for its
code, so demote it to "maintained" to reflect true status.
Fix all occurences of Luo Jie email address to preferred and working
domain.
Wei Fang [Wed, 24 Jun 2026 07:27:26 +0000 (15:27 +0800)]
net: enetc: fix potential divide-by-zero when num_vsi is zero
For i.MX94 series, all the standalone ENETCs do not support SR-IOV, so
pf->caps.num_vsi is zero. This leads to a divide-by-zero in
enetc4_default_rings_allocation() when distributing rings among PF and
VFs.
Division by zero is undefined behavior in C. On ARM64, the UDIV/SDIV
instructions silently return zero rather than raising an exception, so
the issue does not cause a visible crash. However, relying on this
behavior is incorrect and poses a cross-platform compatibility risk.
Add an explicit check for num_vsi == 0 and return early after the PF's
rings have been configured.
Fixes: 2d673b0e2f8d ("net: enetc: add standalone ENETC support for i.MX94") Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20260624072726.1238903-1-wei.fang@oss.nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
dt-bindings: net: renesas,ether: Drop example "ethernet-phy-ieee802.3-c22" fallback
Fix the Micrel PHY in the example which shouldn't have the
fallback "ethernet-phy-ieee802.3-c22" compatible:
Documentation/devicetree/bindings/net/renesas,ether.example.dtb: ethernet-phy@1 \
(ethernet-phy-id0022.1537): compatible: ['ethernet-phy-id0022.1537', 'ethernet-phy-ieee802.3-c22'] is too long
from schema $id: http://devicetree.org/schemas/net/micrel.yaml
Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Conor Dooley <conor.dooley@microchip.com> Acked-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Fixes: 37a2fce09001 ("dt-bindings: sh_eth convert bindings to json-schema") Link: https://patch.msgid.link/20260624150250.131966-2-robh@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ct_limit_set() is documented as being called with ovs_mutex held. It
walks the ct limit hlist with hlist_for_each_entry_rcu(), but the
iterator does not currently pass the OVS lockdep condition used
elsewhere for RCU-protected OVS objects.
Pass lockdep_ovsl_is_held() to the iterator. This matches the function's
existing caller contract and lets CONFIG_PROVE_RCU_LIST distinguish the
ovs_mutex-protected update path from the RCU read-side ct_limit_get()
path.
This was found by our static analysis tool and then manually reviewed
against the current tree. In the reviewed CONFIG_PROVE_RCU_LIST triage
run, the writer-side ct limit update produced the expected "RCU-list
traversed in non-reader section!!" warning while ovs_mutex was held,
with the stack matching ct_limit_set() and ovs_ct_limit_set_zone_limit().
The change is limited to documenting the existing protection contract.
This is a lockdep annotation cleanup. It does not change the conntrack
limit list update or release behavior.
Eric Dumazet [Thu, 25 Jun 2026 06:59:36 +0000 (06:59 +0000)]
net: udp_tunnel: prevent double queueing in udp_tunnel_nic_device_sync
Yue Sun reported a use-after-free and debugobjects warning in
udp_tunnel_nic_device_sync_work() during concurrent device operations.
The workqueue core clears the internal pending bit before invoking the
worker. At that point, a concurrent thread can queue the work again.
When the already running worker eventually clears the work_pending flag
to 0, it mistakenly clears the flag for the newly queued instance.
udp_tunnel_nic_unregister() then observes work_pending as 0 and frees
the structure while the second work item is still active in the queue,
leading to UAF.
Fix this by returning early in udp_tunnel_nic_device_sync() if
work_pending is already set, preventing redundant work queueing.
Fixes: cc4e3835eff4 ("udp_tunnel: add central NIC RX port offload infrastructure") Reported-by: Yue Sun <samsun1006219@gmail.com> Suggested-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260625065938.654652-2-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
HE WEI (ギカク) [Wed, 24 Jun 2026 09:09:52 +0000 (18:09 +0900)]
usb: misc: usbio: bound bulk IN response length to the received transfer
usbio_bulk_msg() copies bpkt_len = le16_to_cpu(bpkt->len) bytes out of
the bulk IN buffer (usbio->rxbuf, allocated with size usbio->rxbuf_len)
into the caller's buffer. bpkt_len is fully controlled by the device
and is only checked against ibuf_len; ibuf_len in turn is checked
against usbio->txbuf_len, not against rxbuf_len:
txbuf_len and rxbuf_len are taken independently from the bulk OUT and
bulk IN endpoint wMaxPacketSize in usbio_probe(). A malicious or
malfunctioning device that advertises a large bulk OUT endpoint and a
small bulk IN endpoint (e.g. by claiming one of the quirk-free IDs such
as the Lattice NX33U, 0x2ac1:0x20cb) therefore makes ibuf_len, and
hence the device-supplied bpkt_len, exceed rxbuf_len. memcpy() then
reads up to txbuf_len - rxbuf_len bytes past the end of the rxbuf slab
object. The over-read bytes are handed back to the i2c layer and on to
user space through i2c-dev, disclosing adjacent slab memory; with KASAN
this is reported as a slab-out-of-bounds read.
The number of bytes actually received is already known: act equals the
URB actual_length and is bounded by rxbuf_len. Reject any response
that claims more payload than was received, mirroring the existing
"act < sizeof(*bpkt)" check just above.
The control path (usbio_ctrl_msg()) is not affected: it uses a single
buffer (ctrlbuf) for both directions, so its analogous copy can never
leave the allocation.
Found by code review. The out-of-bounds read was confirmed under
AddressSanitizer with a faithful userspace model of usbio_bulk_msg()'s
receive path (an rxbuf_len-sized buffer, the same act/ibuf_len/bpkt_len
checks and the memcpy). A USB raw-gadget + dummy_hcd reproducer is
also available.
Haoxiang Li [Tue, 23 Jun 2026 09:33:25 +0000 (17:33 +0800)]
usb: mtu3: unmap request DMA on queue failure
mtu3_gadget_queue() maps the request before checking whether
the QMU GPD ring can accept another transfer. the request is
returned with -EAGAIN before it is linked on the endpoint
request list if mtu3_prepare_transfer() fails.
Normal completion and dequeue paths unmap requests from
mtu3_req_complete(), but this error path never reaches that
helper, so the DMA mapping is left active. Unmap the request
before returning from the failed queue path.
WenTao Liang [Thu, 11 Jun 2026 13:11:21 +0000 (21:11 +0800)]
usb: dwc3: meson-g12a: fix refcount leak in dwc3_meson_g12a_resume()
If dwc3_meson_g12a_resume() succeeds in calling
reset_control_reset(), an internal triggered_count reference is
acquired. If any later step fails (usb_init, phy_init,
phy_power_on, regulator_enable, or usb_post_init), the function
returns the error without rearming the reset control. This leaks
the reference and leaves the reset control in a triggered state,
causing future reset_control_reset() calls to incorrectly return
early as if already reset.
Add an error path that calls reset_control_rearm() to balance
the reference before returning the error.
Maoyi Xie [Wed, 27 May 2026 15:08:32 +0000 (23:08 +0800)]
usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler
The OTG branch of composite_setup() falls back to the first
configuration when none is selected:
if (cdev->config)
config = cdev->config;
else
config = list_first_entry(&cdev->configs,
struct usb_configuration, list);
if (!config)
goto done;
...
memcpy(req->buf, config->descriptors[0], value);
list_first_entry() never returns NULL. On an empty list it returns
container_of() of the list head. So the "if (!config)" check is dead.
When cdev->configs is empty, config points at the head inside struct
usb_composite_dev. config->descriptors[0] reads whatever sits at that
offset. The memcpy copies up to w_length bytes of it into the response
buffer.
cdev->configs can be empty in two cases. One is a teardown race on
gadget unbind with a control transfer in flight. The other is a driver
that sets is_otg before it adds a config. A reproducer that holds
cdev->configs empty triggers a KASAN fault in this branch.
Use list_first_entry_or_null() so the existing check does its job.
usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect()
ueagle-atm uses the asynchronous request_firmware_nowait() in .probe(),
but does not wait for its completion, not even in .disconnect(); so, if the
device is unplugged meanwhile, its teardown runs concurrently with that.
Even though this inconsistency is worth addressing on its own, it has also
triggered several bug reports in syzbot over the years (some auto-closed)
where the firmware sysfs fallback mechanism (CONFIG_FW_LOADER_USER_HELPER)
creates a firmware subdirectory in the device directory during its removal,
which might hit unexpected conditions in kernfs, apparently, depending at
which point the add and remove operations raced. (See links.)
The pattern is:
usb ?-?: Direct firmware load for ueagle-atm/eagle?.fw failed with error -2
usb ?-?: Falling back to sysfs fallback for: ueagle-atm/eagle?.fw
<ERROR>
Call trace:
...
kernfs_create_dir_ns
sysfs_create_dir_ns
create_dir
kobject_add_internal
kobject_add_varg
kobject_add
class_dir_create_and_add
get_device_parent
device_add
fw_load_sysfs_fallback
fw_load_from_user_helper
firmware_fallback_sysfs
_request_firmware
request_firmware_work_func
...
(Some variations are observed, after fw_load_sysfs_fallback(), e.g., [1].)
While the kernfs side is being looked at, the ueagle-atm side can be fixed
by waiting for the pre-firmware load in the .disconnect() handler.
This change has a similar approach to previous work by Andrey Tsygunka [2]
(wait_for_completion() in .disconnect()), but it is relatively different in
design/implementation; using the Originally-by tag for credit assignment.
This has been tested with:
- synthetic reproducer to check the error path;
- USB gadget (virtual device) to check the firmware upload path;
- QEMU device emulator to check the device ID re-enumeration path;
(The latter two were written by Claude; no other code/text in this commit.)
Stephen Boyd [Thu, 25 Jun 2026 14:55:47 +0000 (07:55 -0700)]
Merge branches 'clk-microchip' and 'clk-qcom' into clk-next
* clk-microchip:
clk: at91: keep securam node alive while mapping it
clk: at91: sama7d65: add peripheral clock for I3C
clk: microchip: mpfs-ccc: fix peripheral driver registration failures after oob fix
clk: at91: sam9x7: Fix gmac_gclk clock definition
clk: at91: sam9x7: Rename macb0_clk to gmac_clk
clk: at91: sam9x7: Remove gmac peripheral clock with ID 67
clk: microchip: rename clk-core to clk-pic32
* clk-qcom: (32 commits)
clk: qcom: regmap-phy-mux: Rework the implementation
clk: qcom: a53: Corrected frequency multiplier for 1152MHz
clk: qcom: camcc-milos: Declare icc path dependency for CAMSS_TOP_GDSC
clk: qcom: gdsc: Support enabling interconnect path for power domain
dt-bindings: clock: qcom,milos-camcc: Document interconnect path
interconnect: Add devm_of_icc_get_by_index() as exported API for users
clk: qcom: camcc-x1p42100: Add support for camera clock controller
clk: qcom: camcc-x1e80100: Add support for camera QDSS debug clocks
clk: qcom: videocc-x1p42100: Add support for video clock controller
dt-bindings: clock: qcom: Add X1P42100 camera clock controller
dt-bindings: clock: qcom: Add X1P42100 video clock controller
clk: qcom: nord: negcc: add support for the USB2 PHY reset
dt-bindings: clock: qcom: add the definition for the USB2 PHY reset
clk: qcom: clk-rpmh: Make all VRMs optional
clk: qcom: Add support for global clock controller on Hawi
clk: qcom: clk-alpha-pll: Add support for Taycan EHA_T PLL
clk: qcom: Add Hawi TCSR clock controller driver
clk: qcom: rpmh: Add support for Hawi RPMH clocks
dt-bindings: clock: qcom: Add Hawi global clock controller
dt-bindings: clock: qcom: Add Hawi TCSR clock controller
...
Neill Kapron [Fri, 19 Jun 2026 04:06:04 +0000 (04:06 +0000)]
usb: gadget: f_fs: Tie read_buffer lifetime to ffs_epfile
Currently, ffs_epfile_release unconditionally frees the endpoint's
read_buffer when a file descriptor is closed. If userspace explicitly
opens the endpoint multiple times and closes one, the read_buffer is
destroyed. This can lead to silent data loss if other file descriptors
are still actively reading from the endpoint.
By tying the lifetime of the read_buffer to the ffs_epfile structure itself
(which is destroyed when the functionfs instance is torn down in
ffs_epfiles_destroy), we eliminate the brittle dependency on open/release
calls while correctly matching the conceptual lifetime of unread data on
the hardware endpoint.
Fixes: 9353afbbfa7b ("usb: gadget: f_fs: buffer data from ‘oversized’ OUT requests") Cc: stable <stable@kernel.org> Assisted-by: Antigravity:gemini-3.1-pro Signed-off-by: Neill Kapron <nkapron@google.com> Link: https://patch.msgid.link/20260619040609.4010746-3-nkapron@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Neill Kapron [Fri, 19 Jun 2026 04:06:03 +0000 (04:06 +0000)]
usb: gadget: f_fs: Initialize epfile->in early to fix endpoint direction checks
When parsing endpoint descriptors, ffs_data_got_descs() generates the
eps_addrmap which contains the endpoint direction. However, epfile->in
was previously only populated in ffs_func_eps_enable() which executes
upon USB host connection. As a result, early userspace ioctls like
FUNCTIONFS_DMABUF_ATTACH that run before the host connects would see
epfile->in as 0, leading to incorrect DMA directions.
By moving the initialization to ffs_epfiles_create(), epfile->in is
accurate before userspace opens the endpoint files.
Fan Wu [Tue, 16 Jun 2026 13:20:11 +0000 (13:20 +0000)]
usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove
The threaded IRQ handler ccg_irq_handler() calls ucsi_notify_common(),
which on a connector-change event calls ucsi_connector_change() and
schedules connector work. In ucsi_ccg_remove(), ucsi_destroy() frees
uc->ucsi (kfree) before free_irq() is called, so a handler invocation
already in flight may access the freed object after ucsi_destroy().
CPU 0 (remove) | CPU 1 (threaded IRQ)
ucsi_destroy(uc->ucsi) | ccg_irq_handler()
kfree(ucsi) // FREE | ucsi_notify_common(uc->ucsi) // USE
Move free_irq() before ucsi_destroy() in the remove path. It is kept
after ucsi_unregister(): ucsi_unregister() cancels connector work whose
handler issues GET_CONNECTOR_STATUS through ucsi_send_command_common(),
which waits for a completion that is signalled from the IRQ handler, so
the IRQ must stay active until that work has been cancelled.
The probe error path already orders free_irq() before ucsi_destroy().
This bug was found by static analysis.
Fixes: e32fd989ac1c ("usb: typec: ucsi: ccg: Move to the new API") Cc: stable <stable@kernel.org> Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://patch.msgid.link/20260616132011.103279-1-fanwu01@zju.edu.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If pmdata->svid_index is driven beyond SVID_DISCOVERY_MAX (16), it results
in an out-of-bounds read of the pmdata->svids array. Because pd_mode_data
is embedded inside struct tcpm_port, indexing past svids reads into
adjacent fields. In particular:
- At index 16, it reads the altmodes count.
- At index 18 and beyond, it reads into altmode_desc[], which contains
partner-supplied SVDM Discovery Modes VDOs.
By injecting a chosen SVID into altmode_desc[0].vdo and driving svid_index
to 20, the partner can force paltmode->svid to be loaded with an arbitrary,
partner- chosen SVID, which is then registered via
typec_partner_register_altmode().
Fix this by validating that pmdata->svid_index is non-negative and strictly
less than pmdata->nsvids before accessing the pmdata->svids array inside
svdm_consume_modes().
Assisted-by: Antigravity:gemini-3.5-flash Fixes: 4ab8c18d4d67 ("usb: typec: Register a device for every mode") Cc: stable <stable@kernel.org> Signed-off-by: Badhri Jagan Sridharan <badhri@google.com> Reviewed-by: RD Babiera <rdbabiera@google.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://patch.msgid.link/20260622220803.305750-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Mon, 22 Jun 2026 15:26:12 +0000 (17:26 +0200)]
USB: legousbtower: fix use-after-free on disconnect race
mutex_unlock() may access the mutex structure after releasing the lock
and therefore cannot be used to manage lifetime of objects directly
(unlike spinlocks and refcounts). [1][2]
Use a kref to release the driver data to avoid use-after-free in
mutex_unlock() when release() races with disconnect().
[1] a51749ab34d9 ("locking/mutex: Document that mutex_unlock() is
non-atomic")
[2] 2b9d9e0a9ba0 ("locking/mutex: Clarify that mutex_unlock(), and most
other sleeping locks, can still use the lock object
after it's unlocked")
Fixes: 18bcbcfe9ca2 ("USB: misc: legousbtower: semaphore to mutex") Cc: stable <stable@kernel.org> Cc: Daniel Walker <dwalker@mvista.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260622152612.116422-5-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Mon, 22 Jun 2026 15:26:11 +0000 (17:26 +0200)]
USB: ldusb: fix use-after-free on disconnect race
mutex_unlock() may access the mutex structure after releasing the lock
and therefore cannot be used to manage lifetime of objects directly
(unlike spinlocks and refcounts). [1][2]
Use a kref to release the driver data to avoid use-after-free in
mutex_unlock() when release() races with disconnect().
[1] a51749ab34d9 ("locking/mutex: Document that mutex_unlock() is
non-atomic")
[2] 2b9d9e0a9ba0 ("locking/mutex: Clarify that mutex_unlock(), and most
other sleeping locks, can still use the lock object
after it's unlocked")
Fixes: ce0d7d3f575f ("usb: ldusb: ld_usb semaphore to mutex") Cc: stable <stable@kernel.org> Cc: Daniel Walker <dwalker@mvista.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260622152612.116422-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Mon, 22 Jun 2026 15:26:10 +0000 (17:26 +0200)]
USB: idmouse: fix use-after-free on disconnect race
mutex_unlock() may access the mutex structure after releasing the lock
and therefore cannot be used to manage lifetime of objects directly
(unlike spinlocks and refcounts). [1][2]
Use a kref to release the driver data to avoid use-after-free in
mutex_unlock() when release() races with disconnect().
[1] a51749ab34d9 ("locking/mutex: Document that mutex_unlock() is
non-atomic")
[2] 2b9d9e0a9ba0 ("locking/mutex: Clarify that mutex_unlock(), and most
other sleeping locks, can still use the lock object
after it's unlocked")
Fixes: 54d2bc068fd2 ("USB: fix locking in idmouse") Cc: stable@vger.kernel.org # 2.6.24 Cc: Oliver Neukum <oliver@neukum.org> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260622152612.116422-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Mon, 22 Jun 2026 15:26:09 +0000 (17:26 +0200)]
USB: iowarrior: fix use-after-free on disconnect race
mutex_unlock() may access the mutex structure after releasing the lock
and therefore cannot be used to manage lifetime of objects directly
(unlike spinlocks and refcounts). [1][2]
Use a kref to release the driver data to avoid use-after-free in
mutex_unlock() when release() races with disconnect().
[1] a51749ab34d9 ("locking/mutex: Document that mutex_unlock() is non-atomic")
[2] 2b9d9e0a9ba0 ("locking/mutex: Clarify that mutex_unlock(), and most
other sleeping locks, can still use the lock object
after it's unlocked")
Johan Hovold [Sat, 23 May 2026 17:05:23 +0000 (19:05 +0200)]
USB: iowarrior: fix use-after-free on disconnect
Submitted write URBs are not stopped on close() and therefore need to be
stopped unconditionally on disconnect() to avoid use-after-free in the
completion handler.
However ffs->reset_work is only ever initialized via INIT_WORK() in
ffs_func_set_alt() and ffs_func_disable(), and only on the
FFS_DEACTIVATED path. That state is reached solely by ffs_data_closed()
when the instance is mounted with the "no_disconnect" option, so for the
common case (no "no_disconnect", or mounted and unmounted without ever
being deactivated) reset_work is never initialized.
ffs_data_new() allocates the ffs_data with kzalloc_obj() and does not
initialize reset_work, and ffs_data_reset()/ffs_data_clear() do not touch
it either, so reset_work.func is left NULL. cancel_work_sync() on such a
work then trips the WARN_ON(!work->func) guard in __flush_work():
On older kernels cancel_work_sync() on a zero-initialized work struct was
a silent no-op, which hid the missing initialization.
Initialize reset_work once in ffs_data_new() so it is always valid for
the lifetime of the ffs_data, and drop the now-redundant INIT_WORK()
calls from the two deactivation paths.
Haoxiang Li [Mon, 22 Jun 2026 05:26:27 +0000 (13:26 +0800)]
usb: cdnsp: fix stream context array leak in cdnsp_alloc_stream_info()
cdnsp_alloc_stream_info() allocates stream_info->stream_ctx_array with
cdnsp_alloc_stream_ctx(). If a later stream ring allocation or stream
mapping update fails, the error path frees the allocated stream rings
and stream_rings array, but leaves stream_ctx_array allocated.
Free the stream context array before falling through to the stream_rings
cleanup path.
Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") Cc: stable <stable@kernel.org> Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com> Acked-by: Peter Chen <peter.chen@kernel.org> Link: https://patch.msgid.link/20260622052627.696373-1-haoxiang_li2024@163.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cen Zhang [Thu, 25 Jun 2026 04:45:47 +0000 (12:45 +0800)]
ntfs: avoid stale runlist element dereference in MFT writeback
ntfs_write_mft_block() maps each $MFT record through the $MFT data
runlist. For sub-folio clusters it looks up a struct runlist_element under
ni->runlist.lock, drops the lock, and later uses rl->length and rl->vcn
when choosing folio_sz.
That pointer is only borrowed from ni->runlist.rl. Concurrent $MFT
allocation extension can merge a replacement runlist under the same lock,
and ntfs_rl_realloc() can free the old backing array. If that happens
between the lookup and the later folio_sz decision, writeback can
dereference freed runlist storage.
The buggy scenario involves two paths, with each column showing the order
within that path:
MFT writeback path: $MFT allocation extension:
1. Look up rl under 1. Extend the $MFT data allocation.
ni->runlist.lock. 2. Publish a replacement runlist.
2. Drop ni->runlist.lock. 3. Free the old runlist array.
3. Read rl->length and rl->vcn
to choose folio_sz.
Compute the remaining run length while ni->runlist.lock is still held, and
use that scalar after unlock. This preserves the existing folio sizing
decision without carrying a borrowed runlist_element across the lock
boundary.
Validation reproduced this kernel report:
BUG: KASAN: slab-use-after-free in ntfs_mft_writepages+0x1c8d/0x1fb0
Paul Cercueil [Tue, 9 Jun 2026 15:29:05 +0000 (17:29 +0200)]
usb: gadget: f_fs: Fix DMA fence leak
In ffs_dmabuf_transfer(), a ffs_dma_fence object is kmalloc'd, with the
underlying dma_fence later initialized by dma_fence_init(), which sets
its kref counter to 1. Then, dma_resv_add_fence() gets a second
reference, and a pointer to the ffs_dma_fence is passed as the
usb_request's "context" field.
The dma-resv mechanism will manage the second reference, but the first
reference is never properly released; the ffs_dmabuf_cleanup() function
decreases the reference count, but only to balance with the reference
grab in ffs_dmabuf_signal_done().
The code will then slowly leak memory as more ffs_dma_fence objects are
created without being ever freed.
Address this issue by transferring ownership of the fence to the DMA
reservation object, by calling dma_fence_put() right after
dma_resv_add_fence(). The ffs_dma_fence then gets properly discarded
after being signalled.
Fixes: 7b07a2a7ca02 ("usb: gadget: functionfs: Add DMABUF import interface") Cc: stable <stable@kernel.org> Signed-off-by: Paul Cercueil <paul@crapouillou.net> Tested-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://patch.msgid.link/20260609152905.729328-1-paul@crapouillou.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: typec: ucsi: Invert DisplayPort role assignment
The existing implementation assigned these flags backwards, configuring
the partner's DisplayPort role to match the port's role instead of
complementing it.
This prevents proper configuration during DP altmode activation, often
causing `pin_assignment` to remain 0 in `dp_altmode_configure()` and
resulting in VDM negotiation failures:
Johan Hovold [Mon, 8 Jun 2026 14:58:03 +0000 (16:58 +0200)]
USB: ulpi: fix memory leak on registration failure
The allocated device name is never freed on early ULPI device
registration failures.
Fix this by initialising the device structure earlier and releasing the
initial reference whenever registration fails.
Fixes: 289fcff4bcdb ("usb: add bus type for USB ULPI") Cc: stable <stable@kernel.org> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260608145803.69360-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xu Rao [Tue, 2 Jun 2026 05:38:42 +0000 (13:38 +0800)]
USB: storage: include US_FL_NO_SAME in quirks mask
usb_stor_adjust_quirks() parses the usb-storage.quirks module
parameter into a new flag set and then applies it with the quirk
mask to override built-in flags.
The mask is meant to cover the flags that can be overridden by
the module parameter. The 'k' quirk character sets US_FL_NO_SAME,
but US_FL_NO_SAME is not included in the mask.
As a result, the module parameter can set US_FL_NO_SAME, but it
cannot clear a built-in US_FL_NO_SAME flag by providing an override
entry that omits 'k'.
Add US_FL_NO_SAME to the mask so that the module parameter can
override it in the same way as the other supported flags.
Fixes: 8010622c86ca ("USB: UAS: introduce a quirk to set no_write_same") Cc: stable <stable@kernel.org> Signed-off-by: Xu Rao <raoxu@uniontech.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://patch.msgid.link/3BCE5880F9A45C2E+20260602053842.2920137-1-raoxu@uniontech.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: core: add USB_QUIRK_NO_LPM for VIA Labs USB 2.0 hub
The VIA Labs, Inc. USB 2.0 hub controller (2109:2817),
found in a KVM switch, fails to enumerate high-power devices during
cold boot and system restart.
Applying the kernel parameter
usbcore.quirks=2109:2817:k
resolves the issue.
Enumeration failure log:
usb 1-1.2.3: device descriptor read/64, error -32
usb 1-1.2.3: Device not responding to setup address.
usb 1-1.2.3: device not accepting address 11, error -71
usb 1-1.2-port3: unable to enumerate USB device
Erich E. Hoover [Tue, 2 Jun 2026 20:45:08 +0000 (14:45 -0600)]
USB: quirks: add NO_LPM for the Samsung T5 EVO Portable SSD
The Samsung T5 EVO Portable SSD (04e8:6200) exhibit two forms of
link instability when USB Link Power Management is enabled:
1. The units fail to initialize properly on first detection,
resulting in a lockup in the drive where it must be power cycled
or the kernel will not recognize the presence of the device.
2. If used for sustained operations (small amounts of continuous
data are transferred to the unit) then the unit will "hiccup"
after roughly 8 hours of use and will disconnect and reconnect.
This has a certain probability of triggering the first issue,
but also causes mount points to become invalid since the device
gets issued a new letter.
Jared Baldridge [Sat, 30 May 2026 22:19:48 +0000 (18:19 -0400)]
usb: cdc_acm: Add quirk for Uniden BC125AT scanner
Uniden BC125AT radio scanner has a USB interface which fails to work
with the cdc_acm driver:
usb 1-1: new full-speed USB device number 2 using uhci_hcd
cdc_acm 1-1:1.0: Zero length descriptor references
cdc_acm 1-1:1.0: probe with driver cdc_acm failed with error -22
usbcore: registered new interface driver cdc_acm
Adding the NO_UNION_NORMAL quirk for the device fixes the issue:
usb 1-1: new full-speed USB device number 2 using uhci_hcd
cdc_acm 1-1:1.0: ttyACM0: USB ACM device
usbcore: registered new interface driver cdc_acm
`lsusb -v` of the device:
Bus 001 Device 002: ID 1965:0017 Uniden Corporation BC125AT
Negotiated speed: Full Speed (12Mbps)
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0 [unknown]
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1965 Uniden Corporation
idProduct 0x0017 BC125AT
bcdDevice 0.01
iManufacturer 1 Uniden America Corp.
iProduct 2 BC125AT
iSerial 3 0001
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0030
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 [unknown]
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)
Mathias Nyman [Tue, 16 Jun 2026 10:09:16 +0000 (13:09 +0300)]
xhci: dbc: support runtime suspend while DbC is in enabled state
Allow xHC to runtime suspend if DbC is in 'enabled' state for over
15 seconds without a connect.
Idea is that every time we go to 'enabled' state we make sure DbC runtime
pm usage is '1' and save a timestamp. if the event loop still finds DbC in
enabled state 15 seconds later then it decrease DbC runtime pm usage by
calling pm_runtime_put().
Enabled state is reached either when DbC is enabled by userspace or a
connected/configured DbC is disconnected.
When a connect is detected we make sure DbC usage count is 1.
If DbC has been in 'enabled' state for 15 seconds and DbC usage is
decreased to 0 by pm_runtime_put, then the whole xHC controller may
runtime suspends to PCI D3 state if no other devices are using it
DbC sysfs file will show 'suspended' when xHC is suspended and will wake up
and enable DbC at cable connect, or when user writes 'enable' to the file.
This patch was originally part of a larger DbC series, but dropped before
the series was submitted to 7.2-rc1. The series has a locking issue in
commit 520058b73ba3 ("xhci: dbc: serialize enabling and disabling dbc")
which is also resolved by this patch
Shengjiu Wang [Thu, 25 Jun 2026 10:24:16 +0000 (18:24 +0800)]
ASoC: fsl_asrc_dma: fix eDMA maxburst misalignment with channel count
The back-end consumes data in units of the number of channels. When the
maxburst value is not evenly divisible by the channel count, the DMA
transfer length does not align with the FIFO frame boundary, causing
wrong data to be copied and audible noise at the end of the stream.
This is specific to eDMA: eDMA only responds to DMA requests from the
back-end, whereas SDMA handles requests from both the front-end and the
back-end and is not affected.
For eDMA, when the back-end maxburst is not evenly divisible by the
channel count, align it to the nearest valid boundary:
- If maxburst >= channel count, override to the channel count so each
transfer corresponds to exactly one audio frame.
- If maxburst < channel count, override to 1 to avoid partial-frame
transfers.
Retain the original maxburst for SDMA or when it already aligns with
the channel count.
Xu Rao [Thu, 25 Jun 2026 13:29:03 +0000 (21:29 +0800)]
ACPI: TAD: Check AC wake capability before enabling wakeup
ACPI_TAD_AC_WAKE is a non-zero bit definition, so testing the macro
itself is always true. As a result, every TAD device is initialized as
a system wakeup device, including RTC-only devices and devices whose
wake capability bits were cleared because _PRW is absent.
Test the capability value returned by _GCP instead. This keeps
RTC-only TAD devices usable without advertising a wakeup capability
that the firmware does not provide.
Christian Hewitt [Thu, 25 Jun 2026 12:28:11 +0000 (12:28 +0000)]
ASoC: codecs: pcm512x: only print info once on no sclk
If sclk is not provided the driver falls back to using bclk and prints
an info message in the system log. Under normal operations the message
is repeated many times:
[ 17.929576] pcm512x 0-004c: No SCLK, using BCLK: -2
[ 17.949172] pcm512x 0-004c: No SCLK, using BCLK: -2
[ 17.953029] pcm512x 0-004c: No SCLK, using BCLK: -2
[ 17.965059] pcm512x 0-004c: No SCLK, using BCLK: -2
[ 82.592980] pcm512x 0-004c: No SCLK, using BCLK: -2
[ 82.866293] pcm512x 0-004c: No SCLK, using BCLK: -2
Switch from dev_info to dev_info_once to reduce log noise.
Pengpeng Hou [Tue, 23 Jun 2026 13:58:34 +0000 (21:58 +0800)]
spi: sh-msiof: abort transfers when reset times out
sh_msiof_spi_reset_regs() asserts TX/RX reset and polls until the reset
bits clear, but the poll result is ignored. sh_msiof_transfer_one() can
therefore continue programming a transfer after the controller did not
leave reset.
Return the reset poll result from the helper and abort the transfer on
timeout, matching the existing transfer path's error-return style.
rtc: ds1307: update reference to removed CONFIG_RTC_DRV_DS1307_HWMON
The CONFIG_RTC_DRV_DS1307_HWMON macro was removed in favor of
CONFIG_HWMON in commit 6b583a64fd1e ("rtc: ds1307: simplify hwmon
config"), but a reference to it remained in a comment. Correct this
reference.
Discovered while searching for CONFIG_* symbols referenced in code but
not defined in any Kconfig file.
platform/x86: amd-pmc: Fix S0i3 wakeup with alarmtimer
It was reported that suspend-then-hibernate stopped working with modern
systemd versions on AMD Cezanne systems. The reason for this breakage
was because systemd switched to using alarmtimer instead of the wakealarm
sysfs file.
On AMD Cezanne systems, amd_pmc_verify_czn_rtc() programs a secondary
timer with the alarm time. This was introduced by
commit 59348401ebed ("platform/x86: amd-pmc: Add special handling for
timer based S0i3 wakeup"). However, this function uses rtc_read_alarm(),
which only reads the aie_timer, not the next expiring timer from the
timerqueue.
When both alarmtimer and wakealarm are active, the first expiring timer
might be the alarmtimer, but amd_pmc_verify_czn_rtc() would only see
the aie_timer, potentially missing the earlier alarm.
Switch to rtc_read_next_alarm() to read whichever timer will fire next.
Also handle -ENOENT (no alarm pending) explicitly as a non-error case.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3591 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://patch.msgid.link/20260521043714.1022930-3-mario.limonciello@amd.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
length is the iso header data_length. It can be up to 0xffff. So the
gate allows a count up to about 16379. isight_samples() then copies
count frames out of payload->samples into the PCM DMA buffer.
payload->samples holds only 2 * MAX_FRAMES_PER_PACKET values. The
device multiplexes two samples per frame. A count past
MAX_FRAMES_PER_PACKET reads past the payload. A count past the buffer
size writes past runtime->dma_area. The smallest PCM buffer is larger
than MAX_FRAMES_PER_PACKET. Bounding the count to MAX_FRAMES_PER_PACKET
keeps both the read and the write in range.
A malicious or faulty Apple iSight on the FireWire bus reaches this
during a normal capture.
Xu Rao [Tue, 23 Jun 2026 07:13:08 +0000 (15:13 +0800)]
ALSA: usb-audio: qcom: Free QMI handle
qc_usb_audio_probe() allocates svc->uaudio_svc_hdl separately from the
uaudio_qmi_svc object.
qmi_handle_release() releases the resources owned by an initialized QMI
handle, but does not free the memory containing the struct qmi_handle
itself. The probe error path and the remove path currently release the
handle and then free svc, losing the last pointer to the separately
allocated handle.
This leaks one struct qmi_handle on each affected probe unwind and on
each successful probe/remove cycle.
Free the handle after qmi_handle_release() in both paths.
Lenovo Legion 7i 16IAX7 systems with Realtek ALC287 codec SSID
17aa:3874 and CSC3551/CS35L41 speaker amps do not provide the
required CS35L41 _DSD properties in ACPI.
Without a quirk, cs35l41-hda fails probing the amps with missing
cirrus,dev-index / Platform not supported errors, leaving the built-in
speakers silent.
This model is similar to the already-supported 17AA386F Legion 7i
16IAX7 variant. Add the Realtek ALC287 quirk to select
ALC287_FIXUP_CS35L41_I2C_2 and add 17AA3874 to the CS35L41 property
table using the same two-amp external-boost configuration.
Tested on a Lenovo Legion 7 16IAX7 with Ubuntu 7.0.0-22-generic. Both
CSC3551 CS35L41 amps probe and bind, firmware loads, calibration
applies, built-in speaker playback works, and the cirrus,dev-index
failure is gone.
Darvell Long [Wed, 24 Jun 2026 14:37:23 +0000 (07:37 -0700)]
ALSA: usb-audio: avoid kobject path lookup in DualSense match
The DualSense jack-detection input handler verifies that a matching input
device belongs to the same physical controller by building kobject path
strings for both the input device and the USB audio device, then comparing
the path prefix.
This was observed when a weak physical connection caused the controller
to rapidly disconnect and reconnect. During that repeated hotplug,
snd_dualsense_ih_match() can run while the controller's USB device is
being disconnected. kobject_get_path() walks ancestor kobjects and
dereferences their names; if the USB device kobject name is no longer
valid, this can fault in strlen():
The same ownership check can be done without building kobject path
strings. The input device is parented below the HID device, USB interface
and USB device, so walking the input device parent chain and comparing
against the mixer USB device preserves the check without dereferencing
kobject names during disconnect.
Fixes: 79d561c4ec04 ("ALSA: usb-audio: Add mixer quirk for Sony DualSense PS5") Cc: <stable@vger.kernel.org> Assisted-by: Cute:gpt-5.5 Signed-off-by: Darvell Long <contact@darvell.me> Link: https://patch.msgid.link/20260624143723.2986353-1-contact@darvell.me Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: hda/realtek: Add quirk for Acer Nitro ANV15-41
The Acer Nitro ANV15-41 laptop with ALC245 codec does not
detect the headset microphone in the combo jack by default.
Apply the ALC2XX_FIXUP_HEADSET_MIC quirk to fix it.
Tiezhu Yang [Thu, 25 Jun 2026 05:08:57 +0000 (13:08 +0800)]
selftests/bpf: Add __arch_loongarch to limit test cases for LoongArch
Make it possible to limit certain tests to LoongArch, just like it is
already done for x86_64, arm64, riscv64, and s390x.
This is a follow up patch of:
commit ee7fe84468b1 ("selftests/bpf: __arch_* macro to limit test cases to specific archs")
commit 1e4e6b9e260d ("selftests/bpf: Add __arch_s390x macro")
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Tiezhu Yang [Thu, 25 Jun 2026 05:08:57 +0000 (13:08 +0800)]
selftests/bpf: Add get_preempt_count() support for LoongArch
There is no LoongArch support for get_preempt_count() currently and its
fallback path always returns 0, just add it so that bpf_in_interrupt(),
bpf_in_nmi(), bpf_in_hardirq(), bpf_in_serving_softirq(), bpf_in_task()
work for LoongArch as well.
The latest kernels select CONFIG_THREAD_INFO_IN_TASK, it can just read
preempt_count from the thread_info which is embedded within task_struct.
With this patch, "./test_progs -t exe_ctx" passes on LoongArch.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
The pointer to thread_info is always available in the $tp register, so
the call to bpf_get_smp_processor_id() can be inlined into a single load
instruction.
The pointer to task_struct is always available in the $tp register, so
the calls to bpf_get_current_task() and bpf_get_current_task_btf() can
be inlined into a single move instruction.
Tiezhu Yang [Thu, 25 Jun 2026 05:03:53 +0000 (13:03 +0800)]
LoongArch: BPF: Fix off-by-one error in tail call
The current code updates the tail call counter (TCC) using a pre-increment
approach, it stores the incremented value back to memory before performing
any boundary or target validation checks.
This causes two major issues:
1. When a tail call fails because the target program is NULL, the TCC is
incorrectly incremented and saved in memory anyway.
2. This dummy increment implicitly consumes one slot of the allowed tail
call budget. As a result, the subsequent loop reaches the maximum limit
prematurely, leading to a test failure where the actual loop count is
32 instead of the expected 33.
Fix this by deferring the counter update. Change the branch condition to
BPF_JSGE (greater or equal) so that we check the boundary first. The TCC
is only incremented and stored back to memory after the boundary check
and the NULL-target check both pass.
projects / thirdparty / kernel / linux.git / log
