| Age | Commit message (Collapse) | Author |
|---|
|
Egor Poderiagin reported runtime resume failures caused by rejected
writes during regcache_sync().
Remove the PDE23 REQ_POWER_STATE default and the defaults for the
volatile MBQ registers 0x2000046 and 0x6100006. Also remove 0x2000046
from the MBQ readable and volatile register lists.
This allows cache sync to complete without suppressing sync errors.
Thanks to Egor Poderiagin for the detailed report and testing of the
default removals.
Closes:
https://lore.kernel.org/linux-sound/8a12a2d9-1b56-4e00-8ccc-cf31325f8366@crazyrussian.pro/
Fixes: 7a0886826308 ("ASoC: codecs: rt721-sdca-sdw: Propagate regcache_sync() errors")
Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Link: https://patch.msgid.link/20261027-rt721fix-v1-1-42cd4b1711d2@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Peter Ujfalusi <peter.ujfalusi@linux.intel.com> says:
While looking at the reconfig lockup reported in
https://bugzilla.kernel.org/show_bug.cgi?id=222182
I checked whether the same can be done by unbinding and binding the HDA
codec driver via sysfs:
echo -n ehdaudio0D0 > /sys/bus/hdaudio/drivers/snd_hda_codec_alc882/unbind
echo -n ehdaudio0D0 > /sys/bus/hdaudio/drivers/snd_hda_codec_alc882/bind
The unbind works and the SOF card is removed, but the codec cannot be
bound again. This has been broken for a long time with hdac_hda; the
reconfig lockup itself is addressed by a separate patch.
Patch 1 and 2 fix the bind: the codec private data was lost on unbind
and the codec device type was left as HDA_DEV_ASOC, so no HDA codec
driver could match it anymore. Patch 2 depends on patch 1, otherwise
the bind would dereference NULL drvdata instead of failing.
Patch 3 fixes an unbalanced runtime PM disable in the component remove,
which leaves the codec with runtime PM disabled after the card is
re-created. This is also visible with machine driver unbind/bind.
Tested on PTL (ALC888 + iDisp): repeated codec and machine driver
unbind/bind, playback/capture, runtime suspend and module reload.
Link: https://patch.msgid.link/20261027083840.28813-1-peter.ujfalusi@linux.intel.com
|
|
hdac_hda_codec_remove() disables runtime PM of the codec device before
releasing the HDA link and calling the codec driver's remove callback,
so that no runtime resume can race with the teardown and access the
link or the already freed codec driver data.
snd_hda_codec_cleanup_for_unbind() then disables runtime PM again.
On the next probe snd_hda_codec_register() enables runtime PM only once,
leaving it disabled after the ASoC card or the codec driver has been
unbound and bound again: the codec stays powered and runtime_status
reads 'unsupported'.
Re-enable runtime PM at the end of hdac_hda_codec_remove() to balance
its own disable. The codec remains disabled until it is registered again.
Fixes: c3ec8ac82105 ("ASoC: hdac_hda: fix memleak on module unload")
Cc: stable@vger.kernel.org
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20261027083840.28813-4-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
hdac_hda_codec_probe() changes the type of the codec device to
HDA_DEV_ASOC to prevent snd_hda_codec_unregister() from unregistering
the device when the card is freed.
The type is never restored, and hda_bus_match() requires the device and
driver types to be equal. After unbinding the codec driver via sysfs the
HDA_DEV_LEGACY codec drivers no longer match the device and bind fails
with -ENODEV.
Restore HDA_DEV_LEGACY with a device managed action registered before
the component, so it runs after the component and the card are gone.
Fixes: b60ee2e281b6 ("ASoC: hdac_hda: overwrite hdev type to HDA_DEV_ASOC")
Cc: stable@vger.kernel.org
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20261027083840.28813-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The SOF HDA code allocates struct hdac_hda_priv and stores it as drvdata
of the codec device before the codec driver is bound. The driver core
clears drvdata on unbind, so after unbinding the codec driver via sysfs
a subsequent bind dereferences a NULL pointer in hdac_hda_dev_probe().
All information in the private data can be derived from the codec
device itself, so allocate and set it up in hdac_hda_dev_probe() as a
device managed resource, which is released on unbind.
Remove the allocation from SOF, keeping the check for iDisp codecs
without display audio component.
Fixes: 3fd63658caed ("ASoC: Intel: Drop hdac_ext usage for codec device creation")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20261027083840.28813-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The RX macro interpolator gains ("RX_RXn Digital Volume") run from
-84 dB to +40 dB. PipeWire and PulseAudio map full volume to the top of
a hardware control's range, so a UCM device that uses one of them as
its volume control plays 40 dB hot at 100% and clips.
Set a platform limit of 84 (0 dB) on the RX0, RX1 and RX2 interpolator
gains when the RX codec DMA link is initialised, the way the sc8280xp
and x1e80100 machine drivers limit their WSA gains. 0 dB is the default
of these controls and the value alsa-ucm-conf's rx-macro init sets, so
existing configurations are unaffected. A control that does not exist
on a board is skipped.
Signed-off-by: Filippo Falezza <effeffe99@gmail.com>
Reviewed-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20261027-sm8250-rx-gain-v1-1-386ee6d971db@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
ixgbe_xmit_frame_ring() takes an extra skb reference with skb_get()
for the pending TX timestamp before preparing the skb for transmit.
Several of the following steps may need to reallocate the skb head:
- ixgbe_tso() calls skb_cow_head(), which reaches pskb_expand_head()
when the header is cloned (e.g. a packet tap holds a clone).
- ixgbe_tx_csum() falls back to skb_checksum_help() for unsupported
checksum offsets, which can call pskb_expand_head() through
skb_ensure_writable().
- With DCB and a software VLAN tag, skb_cow_head() is called to
rewrite the VLAN priority.
pskb_expand_head() used to BUG() on shared skbs. Since commit
c7d8bc3dd511 ("net: skbuff: don't BUG() on bad arguments to
pskb_expand_head()") it returns -EINVAL instead, so these packets
are dropped (TSO, DCB) or sent with an unfinished checksum
(skb_checksum_help() errors are ignored by ixgbe_tx_csum()).
Reserve the TX timestamp right before ixgbe_tx_map(), after all skb
preparation, as i40e and ice already do. The timestamp request
remains covered on the FCoE path, and the cleanup on ixgbe_tx_map()
failure is unchanged.
Fixes: 891dc0821d20 ("ixgbe: Add ptp work item to poll for the Tx timestamp")
Cc: stable@vger.kernel.org
Signed-off-by: Eric Dumazet <edumazet@kernel.org>
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Link: https://patch.msgid.link/20261026082035.335770-1-edumazet@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
__netif_set_xps_queue() walks the OLD dev_maps to free its entries. The
per-row trip count uses the NEW num_tc while the row stride uses the OLD
dev_maps->num_tc, so when dev->num_tc was raised without rebuilding the
XPS map the last row indexes attr_map[] past the allocation:
BUG: KASAN: slab-out-of-bounds in __netif_set_xps_queue+0x1458/0x1ee8
Read of size 8 at addr ffff000014f69458 by task insmod/112
The loop frees entries in dev_maps, so both the trip count and the stride
must come from dev_maps->num_tc. The map is sized
XPS_CPU_DEV_MAPS_SIZE(old num_tc)/XPS_RXQ_DEV_MAPS_SIZE(old num_tc, ...),
so iterating the new (larger) num_tc reads past the end.
Fixes: 255c04a87f43 ("net: embed num_tc in the xps maps")
Signed-off-by: Dudu Lu <phx0fer@gmail.com>
Reviewed-by: Antoine Tenart <atenart@kernel.org>
Link: https://patch.msgid.link/20261021155538.67867-1-phx0fer@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
When pppoe_connect() disconnects or reuses a socket, it removes the old
session from the hash table and resets the socket's fields. An RCU
reader that reached the entry before it was unlinked can still be using
its address, ifindex or next pointer.
If sockets A and B share a hash bucket with A preceding B, a concurrent
__get_item() looking for B can be traversing A when it is removed.
Clearing A->next then makes the lookup miss B and drop the packet.
Reinserting A can similarly redirect the reader into another hash chain.
Call synchronize_net() after unlinking the old session and before
clearing its fields. This allows existing receive-path and
/proc/net/pppoe readers to finish before the socket is cleared or reused.
This was found by Sashiko's static analysis, and reproduced on a VM
stress test with KCSAN.
BUG: KCSAN: data-race in hash_item+0x1c/0x60
race at unknown origin, with read to 0xffff888000a1c566 of 2 bytes by task 147 on cpu 2:
hash_item+0x1c/0x60
pppoe_seq_next+0x112/0x1b0
seq_read_iter+0x595/0x700
seq_read+0xb0/0xe0
proc_reg_read+0xd0/0xf0
vfs_read+0xbd/0x220
ksys_read+0xa9/0x100
__x64_sys_read+0x47/0x60
x64_sys_call+0x98/0x1fd0
do_syscall_64+0x5b/0x260
entry_SYSCALL_64_after_hwframe+0x4b/0x53
value changed: 0x0002 -> 0x0000
Fixes: 72cdc67e7fa7 ("pppoe: remove rwlock usage")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261020092118.47416-1-qingfang.deng@linux.dev
Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev>
Reviewed-by: Eric Dumazet <edumazet@kernel.org>
Link: https://patch.msgid.link/20261026061300.256009-1-qingfang.deng@linux.dev
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
When RTAX_CWND is locked, user is able to pass 0 into it.
This could lead to writing 0 to tp->snd_cwnd, leading to a
division by zero error.
Oops: divide error: 0000 [#1] SMP KASAN NOPTI
Call Trace:
<IRQ>
tcp_reno_cong_avoid (net/ipv4/tcp_cong.c:510 (discriminator 1))
tcp_ack (net/ipv4/tcp_input.c:3517 net/ipv4/tcp_input.c:3873 net/ipv4/tcp_input.c:4440)
tcp_rcv_established (net/ipv4/tcp_input.c:6685)
tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1854)
tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2248)
ip_protocol_deliver_rcu (net/ipv4/ip_input.c:207 (discriminator 1))
ip_local_deliver_finish (net/ipv4/ip_input.c:241 (discriminator 1))
ip_local_deliver (./include/linux/netfilter.h:325 ./include/linux/netfilter.h:319 net/ipv4/ip_input.c:262)
ip_rcv (./include/net/dst.h:481 (discriminator 6) net/ipv4/ip_input.c:492 (discriminator 6) ./include/linux/netfilter.h:325 (discriminator 6) ./include/li)
__netif_receive_skb_one_core (net/core/dev.c:6297 (discriminator 4))
__netif_receive_skb (net/core/dev.c:6410)
process_backlog (net/core/dev.c:6761)
__napi_poll.constprop.0 (net/core/dev.c:7830)
net_rx_action (net/core/dev.c:7893 net/core/dev.c:8050)
handle_softirqs (kernel/softirq.c:645)
__irq_exit_rcu (kernel/softirq.c:679 kernel/softirq.c:519 kernel/softirq.c:758)
irq_exit_rcu (kernel/softirq.c:775)
sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1062 (discriminator 35) arch/x86/kernel/apic/apic.c:1062 (discriminator 35))
RIP: 0010:tcp_cong_avoid_ai (net/ipv4/tcp_cong.c:482)
Fix by checking if user pass in zero as parameter and if lock is present.
Fixes: 814d488c6126 ("tcp: fix the timid additive increase on stretch ACKs")
Cc: stable@vger.kernel.org
Suggested-by: Eric Dumazet <edumazet@kernel.org>
Reported-by: co+71b6509cb791e531@bugs.sh
Signed-off-by: Kaho Jiang <kj2864@nyu.edu>
Reviewed-by: Eric Dumazet <edumazet@kernel.org>
Link: https://patch.msgid.link/20261021235732.1313305-2-kj2864@nyu.edu
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Hannes Laimer says:
====================
vxlan: keep reserved_bits on changelink
Currently reserved_bits are reset on every changelink. This leads to
packets using extensions that were enabled on creation being dropped
after a changelink. The first commit describes the problem and
solution in more detail and the second just adds a selftest for this.
Signed-off-by: Hannes Laimer <h.laimer@proxmox.com>
====================
Link: https://patch.msgid.link/20261023-b4-vxlan-changelink-gbp-v1-0-f0d13951c09b@proxmox.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
On a device created with gbp, run the reserved bit probes before and
after an unrelated changelink. Check that what the device accepts has
not changed.
Signed-off-by: Hannes Laimer <h.laimer@proxmox.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Link: https://patch.msgid.link/20261023-b4-vxlan-changelink-gbp-v1-2-f0d13951c09b@proxmox.com
Tested-by: Gabriel Goller <g.goller@proxmox.com>
Reviewed-by: Gabriel Goller <g.goller@proxmox.com>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
vxlan_nl2conf() derives reserved_bits from the extension attributes
set in the netlink message if IFLA_VXLAN_RESERVED_BITS is absent. A
changelink having it set is rejected, so this means that every
changelink will reset all extension bits and reserve them again.
vxlan_nl2flag() rejects setting a flag on an attribute that is
create-only on changelink. So also setting an extension attribute will
fail before it can un-reserve its fields.
The extension's header bits being reserved again then makes
vxlan_rcv() drop frames that have them set in their header as invalid.
The device still reports the extension as enabled, because only the
reserved_bits are rebuilt and the flags are just copied.
A simple reproducer is
ip link add vxgbp type vxlan id 1 dstport 4789 local 10.0.0.1 gbp
ip link set dev vxgbp type vxlan ageing 300
After setting the unrelated ageing, incoming packets with the GBP bit
set in the header start getting dropped.
Keeping the reserved_bits on changelink is safe because anything a
changelink accepts leaves the header bits enabled extensions use
unchanged.
Ran into this when adding support for the GBP flag in ifupdown2, see
link below. The device kept dropping packets after some time, it
turned out it always started after a changelink.
Tested this by changing ageing by hand on a vxlan device that was
created by ifupdown2 with the gbp flag, and checking the reserved bits
using
ip -d link show vxgbp | grep -o 'reserved_bits 0x[0-9a-f]*'
Without the fix I got 0xf7ffffff000000ff after the changelink, and
with the fix it stayed 0x77000000000000ff. The following patch
contains a selftest that fails without the fix and passes with it.
Fixes: e4f8647767cf ("vxlan: Track reserved bits explicitly as part of the configuration")
Link: https://lore.proxmox.com/pve-devel/20260828134708.692354-1-h.laimer@proxmox.com/
Signed-off-by: Hannes Laimer <h.laimer@proxmox.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Link: https://patch.msgid.link/20261023-b4-vxlan-changelink-gbp-v1-1-f0d13951c09b@proxmox.com
Tested-by: Gabriel Goller <g.goller@proxmox.com>
Reviewed-by: Gabriel Goller <g.goller@proxmox.com>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
'net-rds-fix-init-failures-leaving-built-in-transports-on-a-dead-core'
Allison Henderson says:
====================
net/rds: fix init failures leaving built-in transports on a dead core
The kernel test robot hit a slab-use-after-free on rds_wq at boot with
CONFIG_SYSCTL=n and RDS, RDS_RDMA and RDS_TCP built in [1]. Two
separate bugs are involved.
With CONFIG_SYSCTL=n, register_net_sysctl() is a stub that returns
NULL, and RDS treats that as -ENOMEM, so rds_init() fails even though
every tunable has a usable default. Patch 1 only treats NULL as a
failure when sysctl support is built in.
Second, when RDS is built in, a failed rds_init() does not stop the
rds_rdma and rds_tcp initcalls. They run against a core that has
already been torn down and queue onto or flush the freed rds_wq. The
error path of rds_ib_init() did this in the robot's report. The
rds_tcp listen socket can also do it when an incoming connection
arrives. Patch 2 makes both transports bail out with -ENODEV unless
rds_init() succeeded. Modular builds can't hit this, because the
transports need symbols from rds.ko.
Thanks to Oleg Nesterov and Joel Granados for the analysis in [2].
Testing: x86_64 under virtme-ng, built in RDS/RDS_RDMA/RDS_TCP,
CONFIG_SYSCTL=n, KASAN, booted with initcall_debug:
- net/main: rds_init() returns -ENOMEM, then rds_rdma_init() hits
KASAN slab-use-after-free in __flush_workqueue() from rds_ib_init(),
reproducing [1].
- patch 2 only: rds_init() still returns -ENOMEM; rds_rdma_init() and
rds_tcp_init() return -ENODEV and the boot completes cleanly.
- both patches: rds_init(), rds_rdma_init() and rds_tcp_init() all
return 0, no KASAN reports.
[1] https://lore.kernel.org/oe-lkp/202610190310.9737b2e3-lkp@intel.com
[2] https://lore.kernel.org/all/atdoGiW_sHlWgOwt@redhat.com/
====================
Link: https://patch.msgid.link/20261021195837.142802-1-achender@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
rds, rds_rdma and rds_tcp each have their own module_init(). When they
are built in, those run in link order, so rds_init() goes first, but
do_initcalls() does not stop when it fails. The transports then
initialize against a core that has already been torn down: rds_wq has
been destroyed, yet rds_ib_dev_put(), rds_ib_unregister_client() and
rds_tcp_accept_work() still queue onto or flush it, and
rds_trans_register() hands the transports to a core whose socket
family may never have been registered.
This was seen with CONFIG_SYSCTL=n, where rds_sysctl_init() failed and
rds_ib_init()'s error path then flushed the freed rds_wq [1], but any
rds_init() failure after rds_threads_init() has the same effect.
Record whether rds_init() succeeded and have rds_rdma_init() and
rds_tcp_init() bail out with -ENODEV otherwise. Modular builds are
unaffected: the transports need symbols exported by rds.ko, so they
cannot be loaded unless rds_init() succeeded.
[1] https://lore.kernel.org/oe-lkp/202610190310.9737b2e3-lkp@intel.com
Fixes: 55b7ed0b582f ("RDS: Common RDMA transport code")
Fixes: 70041088e3b9 ("RDS: Add TCP transport to RDS")
Suggested-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Allison Henderson <achender@kernel.org>
Link: https://patch.msgid.link/20261021195837.142802-3-achender@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
With CONFIG_SYSCTL=n, register_net_sysctl() and register_net_sysctl_sz()
are inline stubs that return NULL. rds_sysctl_init(),
rds_ib_sysctl_init() and rds_tcp_init_net() all treat that NULL as
-ENOMEM, so RDS refuses to initialize at all even though every tunable
has a sane compiled-in default.
When RDS is built in, that is worse than a missing feature: the failed
rds_init() destroys rds_wq, but the rds_rdma initcall still runs, and
when rds_ib_sysctl_init() fails the same way, the error path in
rds_ib_init() flushes the already freed workqueue:
BUG: KASAN: slab-use-after-free in touch_wq_lockdep_map
...
__flush_workqueue
rds_ib_init
rds_rdma_init
...
Allocated by task 1:
alloc_workqueue_noprof
rds_threads_init
rds_init
...
Freed by task 0:
kfree
rcu_do_batch
Only treat the NULL return as a failure when sysctl support is actually
compiled in. The exit paths need no change: unregister_net_sysctl_table()
is an empty stub with CONFIG_SYSCTL=n and already tolerates a NULL header
otherwise.
The underlying problem of built-in transports initializing after
rds_init() has failed is independent of sysctl and is addressed
separately.
Reported-by: kernel test robot <yi1.lai@intel.com>
Closes: https://lore.kernel.org/oe-lkp/202610190310.9737b2e3-lkp@intel.com
Fixes: 3e5048495c85 ("RDS: sysctls")
Fixes: e6babe4cc4ce ("RDS/IB: Stats and sysctls")
Fixes: c6a58ffed536 ("RDS: TCP: Add sysctl tunables for sndbuf/rcvbuf on rds-tcp socket")
Suggested-by: Joel Granados <joel.granados@kernel.org>
Signed-off-by: Allison Henderson <achender@kernel.org>
Reviewed-by: Joel Granados <joel.granados@kernel.org>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Link: https://patch.msgid.link/20261021195837.142802-2-achender@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
On EN7581, STP BPDUs received on switch user ports never reach the CPU.
Like MT7531 and MT7988, EN7581 and AN7583 only set the CPU port bitmap
in MT7531_CFC and are skipped by mt753x_conduit_state_change(). On
EN7581 this is not enough: trapped BPDUs reach the CPU only when
MT7530_CPU_EN and MT7530_CPU_PORT are also set in MT753X_MFC. Add
EN7581 and AN7583 to mt753x_conduit_state_change().
Tested on an AN7581 board (Gemtek W1700K, airoha,en7581-switch), where
only lan3 and lan4 are switch user ports. With RSTP BPDUs arriving on
lan4:
- without this patch, none reached the CPU;
- setting CPU_EN and CPU_PORT by hand delivered them, and clearing them
stopped them;
- with this patch, they are received from boot.
Only BPDUs were tested. AN7583 is untested and is included because the
driver sets it up like EN7581.
Fixes: 2b0229f67932 ("net: dsa: mt7530: Add EN7581 support")
Fixes: d76556db10bf ("net: dsa: mt7530: Add AN7583 support")
Acked-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
Signed-off-by: Tao Gong <gongtao0607@gmail.com>
Link: https://patch.msgid.link/20261022205649.2351696-1-gongtao0607@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Compound response handling pads the last response of a compound to an
8-byte boundary by growing the final iov and the RFC1002 length.
smb2_allocate_rsp_buf() allocates exactly response_sz. A command can
fill the response buffer to within 7 bytes of its end, for example a
QUERY_INFO whose output is bounded only by the space left. The padding
can then run past the allocation, and ksmbd_tcp_writev() reads those
bytes when it sends the response.
BUG: KASAN: slab-out-of-bounds in _copy_from_iter+0x744/0x10e0
Call Trace:
_copy_from_iter+0x744/0x10e0
tcp_sendmsg_locked+0x2290/0x3f80
ksmbd_tcp_writev+0x10c7/0x1ab0 [ksmbd]
Allocate room for the padding when the request is a compound, as
smb2_read() and smb2_read_pipe() do for their payloads. response_sz is
unchanged, so commands still fill only up to it, and kvzalloc() zeroes
the padding.
Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3")
Cc: stable@vger.kernel.org
Signed-off-by: Ian Bridges <icb@fastmail.org>
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
|
|
A CREATE response that carries an AAPL create context can reach
create_rsp_size (572 bytes for SMB 3.1.1). Commit 713c31a3a225
("ksmbd: fix SMB2 CREATE response buffer overflow") makes
smb2_allocate_rsp_buf() reserve that much, but only for the first
command of a compound. A CREATE later in the compound is guarded by
is_chained_smb2_message() instead, which reserves only
MAX_CIFS_SMALL_BUFFER_SIZE (448 bytes) for the next response. smb2_open()
then appends the create contexts without checking the space left.
That check also uses the unpadded length of the response so far.
init_chained_smb2_rsp() pads the previous response to 8 bytes before the
next command runs, so the next response can start up to 7 bytes later
than the check assumes.
When a CREATE follows a command that fills the response buffer, such as
QUERY_DIRECTORY, it writes its create contexts past the end of the
buffer. The AAPL context is written last.
BUG: KASAN: slab-out-of-bounds in create_aapl_rsp_buf+0x31/0x6e0 [ksmbd]
Call Trace:
create_aapl_rsp_buf+0x31/0x6e0 [ksmbd]
smb2_open+0x4fa8/0xd900 [ksmbd]
handle_ksmbd_work+0x88c/0x1cb0 [ksmbd]
When the next command is a CREATE, reserve create_rsp_size, as
smb2_allocate_rsp_buf() does for a single CREATE, and check the reserve
against the 8-byte aligned offset where the next response starts.
Fixes: 8f1b796ff113 ("ksmbd: add AAPL kAAPL_SERVER_QUERY create context support")
Signed-off-by: Ian Bridges <icb@fastmail.org>
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
|
|
Writing to the reconfig or clear sysfs nodes of a codec handled by ASoC
(SOF via hdac_hda, AVS via codecs/hda) hangs the writer.
snd_hda_codec_reset() sets card->shutdown and calls
device_release_driver(). With ext_ops the driver unbind unregisters the
ASoC component, which unbinds and frees the whole ASoC card:
- snd_card_disconnect() returns early as card->shutdown is already set,
so the card's child devices are not removed and snd_card_free() waits
for the card release forever.
- Even without that, freeing the card removes the codec's hwdep device,
which owns the sysfs node the reset was issued from, deadlocking in
kernfs while waiting for the active write to finish.
The legacy HDA driver keeps the card across a driver rebind, ASoC does
not, so the reset cannot be supported there. Return -EOPNOTSUPP and skip
the misleading "codec is being used" messages in the callers.
Fixes: 6bae5ea94989 ("ASoC: hdac_hda: add asoc extension for legacy HDA codec drivers")
Cc: stable@vger.kernel.org
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=222182
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20261027072835.4796-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
With IFF_NAPI_FRAGS, tun_get_user() takes tfile->napi_mutex, gets the
skb from napi_get_frags() and copies the user data into it before it
enters the RCU read-side section around napi_gro_frags().
tun_detach_all() waits with synchronize_net() and then calls
tun_napi_del() without napi_mutex. netif_napi_del() frees napi->skb
through napi_free_frags(). A writer that is still copying has not yet
entered its RCU section, so synchronize_net() does not wait for it, and
deleting the device frees the skb while the writer is using it:
BUG: KASAN: slab-use-after-free in skb_copy_datagram_from_iter+0x175/0x720
Read of size 8 at addr ffff888077def990 by task br029-poc/9406
Call Trace:
skb_copy_datagram_from_iter+0x175/0x720
tun_get_user+0xb42/0x3d00
tun_chr_write_iter+0x113/0x200
...
Freed by task 9405:
kmem_cache_free+0x184/0x670
__netif_napi_del_locked+0x2bb/0x3c0
tun_net_uninit+0x566/0xa70
unregister_netdevice_many_notify+0x1a26/0x2090
rtnl_dellink+0x514/0x710
__tun_detach() also calls tun_napi_del() without the mutex, but only
from tun_chr_close(), when no write on that file can be in flight.
Take napi_mutex around tun_napi_del() in tun_detach_all() for both
attached and disabled queues.
Fixes: 90e33d459407 ("tun: enable napi_gro_frags() for TUN/TAP driver")
Signed-off-by: Cheng Yongkang <teel4res@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/179268538303.70821.16548460883330758972@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
If the share path is a mount point and crossmnt is not set (crossmnt = no,
or ksmbd-tools that predate the option), the share root looks empty to
clients: QUERY_DIRECTORY on it returns only "." and "..". Files created
in the root go to the mounted filesystem, but a directory query cannot
find them afterwards, so e.g. "rm" of a file that was just uploaded
fails with STATUS_NO_SUCH_FILE.
An empty name refers to the share root. For it, ksmbd_vfs_path_lookup()
looks up share_conf->path again starting from its parent, and the mount
on the last component is not followed, which gives the directory covered
by the mount. All other names are looked up relative to
share_conf->vfs_path, which was resolved through the mount when the
share was set up.
share_conf->vfs_path already refers to the share root, so return a
reference to it instead of looking the path up again.
Fixes: 74d7970febf7 ("ksmbd: fix racy issue from using ->d_parent and ->d_name")
Signed-off-by: Denis Kulikov <dar1knessx@gmail.com>
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
|
|
Since currently dedicated EROFS-owned meta inodes are used for
file-backed mounts, .read_folio() checks are now redundant.
As a result, EROFS file-back mounts can now apply to tmpfs too.
Fixes: e587a984d332 ("erofs: use dedicated meta inodes for file-backed mounts")
Signed-off-by: Gao Xiang (Docker) <xiang@kernel.org>
|
|
The device reports vendor-specific class on all interfaces, so the
standard parser rejects it and no card is created. Add a composite
quirk with fixed audio and raw-MIDI layouts. The id table entry
matches interface 0 only so that the vendor control interfaces (2/3)
are left unbound for userspace access.
The endpoints advertise no synchronization and the device provides no
feedback; both streams are locked to the USB SOF. The playback entry
is marked USB_ENDPOINT_SYNC_SYNC so that generic sync-EP detection
does not pair the capture data endpoint (0x82) as implicit feedback
for the output stream; the capture entry needs no override, as its
.ep_idx = 1 already keeps it out of sync-EP detection.
Verified on hardware: audio duplex at both supported rates, raw MIDI
in/out, and complete patch dumps as SysEx on the MIDI endpoints.
Signed-off-by: Shawn Rainey <rainey.shawn+kaudio@gmail.com>
Link: https://patch.msgid.link/20261023122513.1025684-1-rainey.shawn+kaudio@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
This patch fixes playback issues on the Microbook II.
The correct value was in the older driver for this device
(https://github.com/manuel-rhdt/snd-microbookii/blob/dd304c097bb6a9d52276ac29c6969fa02bc7674a/audio.c#L914).
Datainterval needs to be set explicitly.
Fixes: a634090a0f24 ("ALSA: usb-audio: Add quirk for MOTU MicroBook II")
Signed-off-by: Sally Marcher <me@gry.sh>
Link: https://lore.kernel.org/d5dfd044-69f6-4fc3-9884-6599d88afb55@student.tugraz.at
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The Realtek ALC4080 USB audio on the MSI MAG X570S Tomahawk Max WiFi
(USB ID 0db0:a073, the same ID as the MAG X570S Torpedo Max mixer map)
has six streaming interfaces with 68 altsettings in total. For each of
them, __snd_usb_parse_audio_interface() switches the interface to alt 0,
initialises pitch and the sample rate and switches back, which costs
about 64 ms per altsetting here, mostly spent inside usb_set_interface().
Probing the card therefore takes about 6.4 seconds, on every boot.
That setup is redundant with snd_usb_endpoint_prepare() at stream-open
time, so set QUIRK_FLAG_SKIP_IFACE_SETUP for this device.
Tested on 7.2.11 with the equivalent quirk_flags=0db0:a073:skip_iface_setup
module option, re-probing the device via its sysfs "authorized"
attribute: probe time went from 6.45 s to 0.57 s, all 68 altsettings
are still listed in /proc/asound/cardX/stream*, and playback and
capture work.
Assisted-by: LLM
Signed-off-by: Zak Brighton Knight <zakbrightonknight@gmail.com>
Link: https://patch.msgid.link/20261026140934.3575940-1-zakbrightonknight@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
bypass
While a sched is bypassing, its tasks are run by its host, the nearest
ancestor that isn't bypassing. check_rq_for_timeouts() tests a runnable task
against its owner's timeout. Since 2c91169377f4 ("sched_ext: Blame the DSQ's
owning scheduler for a runnable stall"), it ejects the sched owning the DSQ
the task waits on. The sched tested, the sched ejected and the sched running
the task can all differ.
- Timeouts are per sched. A bypassing sub-scheduler with a 2s timeout under
a root with the default 30s has its tasks on the root's bypass DSQ. The
root, not bypassing itself, consumes that DSQ before calling
ops.dispatch() only on every other pass, and on the others only after
ops.dispatch() yields nothing. A task that waits 2s there ejects the root,
disabling all of sched_ext.
- A bypassing owner's task on the local DSQ is blamed on the owner, which
places nothing while bypassing. If the owner is already exiting, e.g.
during its own disable, the exit is a no-op and nothing is ejected. If the
host isn't running the task, the owner's disable, which waits on it, may
never finish.
- The wait isn't restarted when bypass moves a task. The time it waited
under its owner counts against the host once it is on the host's bypass
DSQ, and its time there against the owner once bypass lifts.
The sched running a task is its owner, or the host while the owner is
bypassing. Test the task against that sched's timeout and blame it. A bypass
requeue can change the sched running a task, so restart the wait of every
task scx_bypass() requeues except the root's own, which the root runs
bypassing or not. Single-scheduler behavior is unchanged.
A task that migrates while scx_bypass() works through the cpus, leaving one
before its requeue and arriving on another after it, is requeued by neither
and keeps its wait, which then counts against the sched now running it. That
is what happened to every task before this patch. This might be worth
addressing in the future, but the race is rare and the real-world
implications should be limited.
Fixes: 2c91169377f4 ("sched_ext: Blame the DSQ's owning scheduler for a runnable stall")
Cc: stable@vger.kernel.org # v7.3+: 30fb2b1e4d41: sched_ext: Fix the running task keeping its protection into bypass
Cc: stable@vger.kernel.org # v7.3+: 5809f749fbdb: sched_ext: Fix a bypassed task stalling on a cpu its scheduler has no caps on
Cc: stable@vger.kernel.org # v7.3+
Reported-by: Andrea Righi <arighi@nvidia.com>
Link: https://lore.kernel.org/all/at4l0yXTk7T_ouk0@gpd4/
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Andrea Righi <arighi@nvidia.com>
|
|
A quirk was added in commit 704de5697008 ("ALSA: hda/realtek: Add quirk
for HP Pavilion All-in-One 27-ca1xxx")
Also enable the quirk for the actual 89e9 model named there.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216139
Signed-off-by: Ernst Persson <ernstp@gmail.com>
Link: https://patch.msgid.link/20261027-realtek-alc274-v1-1-c0eae15d0c55@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The enable module parameter is declared and documented as "Enable
pcmtest soundcard.", but nothing reads it. Loading the module with
enable=0 still creates the card.
Return -ENODEV from mod_init() when enable is false, as the pcsp driver
does.
Fixes: 315a3d57c64c ("ALSA: Implement the new Virtual PCM Test Driver")
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Link: https://patch.msgid.link/20261027012228.3797565-1-sammiee5311@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
copy_capture_data() and copy_playback_data() wrap the ring buffer
position once and split the memcpy() in two at the buffer end, which is
only correct when one packet holds at most buffer_size frames. The
capture packet size is the device's (actual_length up to wMaxPacketSize,
divided by 3 * bNrChannels from its own descriptor), the playback packet
size is taken from the capture packets, and set_stream_hw() lets the
PCM client pick period_bytes_min 1, periods_min 2 and a period time of
1.5 packet intervals: 9 frames at 44.1 kHz high speed, an 18-frame
buffer. A device sending 672-byte mono 24-bit packets delivers 224
frames per packet.
After the first packet buffer_pos is 206 and stays beyond buffer_size.
On the next packet frames1 = buffer_size - buffer_pos wraps and memcpy()
runs away:
snd-ua101 2-1:1.0: invalid position: , pos = 206, buffer size = 18,
period size = 9
BUG: KASAN: slab-out-of-bounds in capture_urb_complete+0x9eb/0xcb0
Read of size 4294966732 at addr ffff88800d73e7e0 by task vhci_rx/81
and for playback:
BUG: KASAN: vmalloc-out-of-bounds in playback_work+0x789/0xac0
Read of size 4294966732 at addr ffffc9000002626a by task kworker/0:1H/80
Clamp the capture copy to buffer_size. On playback, copy at most one
buffer and fill the rest of the packet with silence, so the URB length,
the delay accounting and the data sent stay consistent. With that bound
the single wrap and both memcpy() halves stay inside the buffer. A
device whose packets do not fit the buffer never played correctly
anyway.
Reproduced on 7.3-rc7 with a USB/IP device presenting the UA-101
interface layout and a 672-byte isochronous endpoint.
Fixes: 63978ab3e3e9 ("sound: add Edirol UA-101 support")
Cc: stable@vger.kernel.org
Signed-off-by: Sinan Turunc <enscrpt@pm.me>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20261026223543.620-3-enscrpt@pm.me
|
|
retire_capture_urb() and prepare_playback_urb() assume that one USB
packet never carries more data than the whole ALSA ring buffer. Nothing
enforces that: the packet size comes from the device (wMaxPacketSize,
and curpacksize == maxpacksize when the class-specific endpoint
descriptor sets MaxPacketsOnly), while the PCM hardware constraints only
require 64-byte periods, two periods and a period time of one data
interval. An 8 kHz mono U8 stream on a 128-byte buffer is legal, and a
full-speed device can send 1023-byte packets into it.
On the first oversized packet hwptr_done is wrapped once and stays
beyond buffer_bytes (895 for 1023 bytes into 128). On the next packet
the wrap arithmetic in the copy path computes
bytes1 = subs->buffer_bytes - oldptr
with oldptr > buffer_bytes, so bytes1 wraps to about 4 GB and memcpy()
runs off the end of the URB buffer and of the vmalloc'd DMA buffer:
BUG: KASAN: slab-out-of-bounds in retire_capture_urb+0x251/0x870
Read of size 4294966529 at addr ffff88800c1e2800 by task vhci_rx/82
and for playback, where copy_to_urb() has the same shape:
BUG: KASAN: vmalloc-out-of-bounds in copy_to_urb.isra.0+0x188/0x430
Read of size 4294966529 at addr ffffc9000004537f by task vhci_rx/79
prepare_playback_urb+0x98a/0x1fc0
Truncate an oversized capture packet to the buffer size, and stop
filling a playback URB once it holds a whole buffer. With bytes <=
buffer_bytes the single wrap of hwptr_done and the two-part memcpy()
in both copy paths stay inside the buffer. A device whose packets do
not fit the buffer at all was never going to play correctly anyway.
Reproduced on 7.3-rc7 with a USB/IP device (dummy_hcd cannot carry
isochronous data) advertising a UAC1 endpoint with MaxPacketsOnly and
wMaxPacketSize 1023, and a PCM client using period_size 64, periods 2.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Sinan Turunc <enscrpt@pm.me>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20261026223543.620-2-enscrpt@pm.me
|
|
lo_ioctl() checks for (mode & BLK_OPEN_WRITE) || capable(CAP_SYS_ADMIN)
before allowing LOOP_SET_STATUS or LOOP_SET_STATUS64, but not
lo_compat_ioctl(), the handler used by 32-bit user space on 64-bit
kernels.
As a result, on 64-bit kernels with CONFIG_COMPAT=y, a 32-bit
unprivileged user-space process holding a read-only (O_RDONLY) file
descriptor to an active /dev/loopN device can issue a compat
LOOP_SET_STATUS ioctl to modify lo_offset, clear lo_sizelimit to 0
(exposing backing-file data past the configured limit), or alter
lo_flags.
Enforce the same (mode & BLK_OPEN_WRITE) || capable(CAP_SYS_ADMIN) check
on LOOP_SET_STATUS in lo_compat_ioctl().
Cc: stable@vger.kernel.org
Assisted-by: ARTIST LLM
Signed-off-by: Dominik Maier <dmnk@google.com>
Reviewed-by: Bart Van Assche bvanassche@acm.org
Link: https://patch.msgid.link/20261025200740.2064379-1-dmnk@google.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
The comment "not really needed" has been there since the inception
of git history. I have done build testing of all files that use
<linux/cdrom.h> with no problems found.
<linux/libata.h> includes <linux/cdrom.h>. I have also build tested
99% of the files that use <linux/libata.h> with no build issues found.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Phillip Potter <phil@philpotter.co.uk>
Link: https://patch.msgid.link/20261026220823.1162-2-phil@philpotter.co.uk
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Nicolai Buchwitz says:
====================
net: usb: cdc_ncm/cdc_mbim: fix netpoll lockup in tx_fixup
Mikkel reported lockups with netconsole on a cdc_ncm device. Further
analysis showed that netpoll calls ndo_start_xmit() with IRQs off but
BHs on while holding the txq lock, and the spin_unlock_bh() in the
tx_fixup paths runs pending softirqs. A transmit from one of them then
spins on that txq lock.
Patch 1 fixes cdc_ncm. Mikkel tested the v2 version of it. Patch 2
fixes the same code in cdc_mbim and is untested.
====================
Link: https://patch.msgid.link/20261024-cdc-ncm-netpoll-v3-0-6284ca03f967@tipi-net.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
cdc_mbim_tx_fixup() has the same spin_unlock_bh() as cdc_ncm_tx_fixup().
Under netpoll it runs pending softirqs while the txq lock is held, and
a transmit from one of them spins on that lock.
Use plain spin_lock() as in cdc_ncm.
Fixes: 9bf211a30b3f ("net: cdc_mbim: adding MBIM driver")
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20261024-cdc-ncm-netpoll-v3-2-6284ca03f967@tipi-net.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
netpoll holds the txq lock and calls ndo_start_xmit() with IRQs off but
BHs on. The spin_unlock_bh() in cdc_ncm_tx_fixup() then runs pending
softirqs. If one of them transmits, it spins on the txq lock that
netpoll holds. With netconsole on a cdc_ncm device this ends in a soft
or hard lockup.
Every caller of cdc_ncm_tx_fixup() holds the txq lock with BHs or IRQs
off, so the softirq user of ctx->mtx cannot interrupt it. Use plain
spin_lock().
Fixes: c84ff1d6dff3 ("cdc_ncm: reduce driver latency in the data path")
Reported-by: Mikkel Eskildsen <mke@visotia.com>
Closes: https://lore.kernel.org/netdev/PRAP189MB185019A5A8D411482BB6E0CDA9982@PRAP189MB1850.EURP189.PROD.OUTLOOK.COM/
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20261024-cdc-ncm-netpoll-v3-1-6284ca03f967@tipi-net.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
interval to vary by HZ
The mcast_startup_query_interval default value is calculated as
125 * HZ / 4. With CONFIG_HZ=250, this results in 3124 instead of
3125 due to integer truncation. The test currently hardcodes 3125,
which fails on kernels built with CONFIG_HZ=250.
Allow a +/- 1 tolerance for the default value check to account for
this rounding, while still catching genuine regressions in the
default value.
Signed-off-by: Jin Li <jinli@lanxincomputing.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20261022103023.834927-1-jinli@lanxincomputing.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
xp_assign_dev() sets XDP_UMEM_SG_FLAG before checking whether the
device supports multibuffer zero-copy. If assignment fails, xsk_bind()
destroys the pool but retains the registered UMEM. A subsequent bind
without XDP_USE_SG inherits the stale flag.
The flag also changes RX buffer sizing after DMA mapping. On igc, a
failed SG bind followed by a non-SG retry with 4096-byte chunks and
1792 bytes of headroom passes admission with 2048 bytes, but programs
a 1024-byte RX buffer. On I225-V hardware, an ordinary 1514-byte frame
is truncated to 1024 bytes or 1008 with RX timestamps enabled.
Restoring the original flags eliminates the truncation in both cases.
Save the UMEM flags before assignment and restore them on failure.
Discovered during development of AF_XDP changes for igc.
Fixes: d609f3d228a8 ("xsk: add multi-buffer support for sockets sharing umem")
Cc: stable@vger.kernel.org
Signed-off-by: Paul Moses <p@1g4.org>
Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Link: https://patch.msgid.link/20261021224705.2078753-1-p@1g4.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
aq_pci_remove() clears the driver's RXNFC rule list before unregistering
the netdevice. Until unregister_netdev() returns, ethtool operations can
still call aq_get_rxnfc_rule(), aq_get_rxnfc_all_rules(),
aq_add_rxnfc_rule(), or aq_del_rxnfc_rule(). Those paths traverse the
same unlocked hlist that aq_clear_rxnfc_all_rules() is mutating and
freeing.
The race is reachable by issuing RXNFC ethtool commands concurrently with
PCI device removal or driver unbind. A reader can dereference a node that
has just been freed, and two writers can corrupt the list or free the same
rule more than once, causing KASAN reports, list corruption, or a kernel
panic.
Reverse the removal order: unregister the netdevice first, then clear the
RXNFC rules. After unregister_netdev() returns, ethtool can no longer
enter the driver, while the PCI device is still available for the
rule-clearing routine to issue hardware commands.
Found during a static-analysis-assisted audit: candidate sites were
surfaced by a Coccinelle rule, and the reader/writer paths were
confirmed by LLM-assisted (GLM-5.3) code inspection. The issue was
not observed at runtime; it is identified by code inspection only.
Fixes: 8d0bcb012f57 ("net: aquantia: add infrastructure for ntuple rules")
Signed-off-by: Binbin Deng <18983559317@163.com>
Link: https://patch.msgid.link/20261020022630.515209-1-18983559317@163.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Such function is invoked in process context, performs an RCU device
lookup and dereference the found device with no additional protection.
=============================
WARNING: suspicious RCU usage
7.3.0-virtme #7 Not tainted
-----------------------------
net/core/dev.c:1047 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
locks held by python3/233: 2, last CPU#5:
#0: ffffffffbab93268 (cb_lock){++++}-{4:4}, at: genl_rcv+0x19/0x40
#1: ffffffffbab93320 (genl_mutex){+.+.}-{4:4}, at:
genl_rcv_msg+0x12c/0x160
stack backtrace:
CPU: 5 UID: 0 PID: 233 Comm: python3 Not tainted 7.3.0#7 PREEMPT(full)
Hardware name: Bochs, BIOS Bochs 01/01/2011
Call Trace:
<TASK>
dump_stack_lvl+0x6f/0xb0
lockdep_rcu_suspicious.cold+0x37/0x8e
dev_get_by_index_rcu+0x135/0x180
gtp_find_dev+0xe7/0x360 [gtp]
gtp_genl_send_echo_req+0x298/0xb30 [gtp]
genl_family_rcv_msg_doit+0x20f/0x310
genl_family_rcv_msg+0x3a8/0x640
genl_rcv_msg+0xbb/0x160
netlink_rcv_skb+0x154/0x3a0
genl_rcv+0x28/0x40
netlink_unicast+0x54b/0x860
netlink_sendmsg+0x7fb/0xf60
__sys_sendto+0x3d6/0x450
__x64_sys_sendto+0xe4/0x1f0
do_syscall_64+0xff/0x530
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7ffa43b0256e
Code: 4d 89 d8 e8 d4 bd 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83
f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 <c9> c3 83 e2 39
83 fa 08 75 e7 e8 03 ff ff ff 0f 1f 00 f3 0f 1e fa
RSP: 002b:00007ffd3b8828d0 EFLAGS: 00000202 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00007ffd3b8829e0 RCX: 00007ffa43b0256e
RDX: 0000000000000034 RSI: 00007ffa3519d0d0 RDI: 0000000000000006
RBP: 00007ffd3b8828e0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffa351cc0c0
R13: 00007ffd3b8829e0 R14: 00007ffa354ca130 R15: 00007ffa4433d498
</TASK>
Add the missing RCU guards and keep it for the whole function body,
while the RCU-protected device is used.
Found by code inspection, validated explicitly testing the relevant
code path.
Fixes: d33bd757d362 ("gtp: Implement GTP echo request")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Link: https://patch.msgid.link/ed27d133fe73afd377d3fa4e553c34e7987b6dd9.1792744478.git.pabeni@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Commit 8540827ebac6 ("pppoe: fix reception of frames with no mac
header") drops PPPoE session frames with no MAC header to avoid reading
uninitialized memory.
Apply the same to PPPoE discovery frames, as both functions read
eth_hdr(skb)->h_source.
Found by LLM static analysis, and reproduced using the same TUN
injection as described in the mentioned commit.
Fixes: 8540827ebac6 ("pppoe: fix reception of frames with no mac header")
Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20261023080002.221332-1-qingfang.deng@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
tcp_tso_autosize() right-shifts the u32 returned by tcp_min_rtt() by
sysctl_tcp_tso_rtt_log. The sysctl uses proc_dou8vec_minmax() without
an upper bound, so it accepts values through 255. Values above 31 make
the shift undefined.
A process with CAP_NET_ADMIN in the target network namespace can set the
per-netns sysctl. With CONFIG_UBSAN_SHIFT=y, setting it to 32 and sending
TCP data over loopback triggers:
UBSAN: shift-out-of-bounds in net/ipv4/tcp_output.c:2264:30
shift exponent 32 is too large for 32-bit type 'unsigned int'
Call Trace:
__ubsan_handle_shift_out_of_bounds
tcp_tso_segs
tcp_write_xmit
__tcp_push_pending_frames
tcp_push
tcp_sendmsg_locked
Limit the sysctl to 31, the largest valid shift count for a u32, and
document the accepted range. Writes of larger values now fail with
-EINVAL.
On a UBSAN/KASAN build of the net tree, values 0 and 31 remained
accepted, values 32 and 255 returned -EINVAL, and TCP traffic with the
valid boundary values produced no sanitizer diagnostics.
Fixes: 65466904b015 ("tcp: adjust TSO packet sizes based on min_rtt")
Cc: stable@vger.kernel.org
Signed-off-by: Yingjie Wang <1075151112@qq.com>
Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Reviewed-by: Neal Cardwell <ncardwell@google.com>
Reviewed-by: Eric Dumazet <edumazet@kernel.org>
Link: https://patch.msgid.link/tencent_31D2FFCCE76C50A695A1270151F825E90906@qq.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
TIPC assumes that the received skb is not shared with other users.
However, syzbot reports a bug triggered by receiving a shared skb:
...
RIP: 0010:pskb_expand_head+0x135a/0x13a0 net/core/skbuff.c:2308
__pskb_pull_tail+0x111/0x1870 net/core/skbuff.c:2890
skb_cow_data+0x2ed/0xc50 net/core/skbuff.c:5398
tipc_aead_decrypt net/tipc/crypto.c:892 [inline]
tipc_crypto_rcv+0x346/0x23d0 net/tipc/crypto.c:1843
tipc_rcv+0x4b7/0x1040 net/tipc/node.c:2119
tipc_l2_rcv_msg+0x2d9/0x470 net/tipc/bearer.c:669
deliver_ptype_list_skb net/core/dev.c:2533 [inline]
...
The root cause is that local delivery hooks in the kernel (e.g.,
deliver_skb()) may increment the skb's reference count (`users`) before
TIPC processes it on ingress.
Fix this by calling skb_share_check() to ensure exclusive ownership
before passing the skb to tipc_rcv(). As TIPC needs to modify the skb's
data, the cloned skb needs to be uncloned when needed. This can be
addressed in separate patch.
Reported-by: syzbot+0017742620a9d06f06ef@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=0017742620a9d06f06ef
Closes: https://lore.kernel.org/all/20261018145928.58317-1-ngocthang2710.1999@gmail.com/T/
Fixes: b97bf3fd8f6a ("[TIPC] Initial merge")
Co-developed-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
Signed-off-by: Tung Nguyen <tung.quang.nguyen@est.tech>
Link: https://patch.msgid.link/20261023052921.54220-1-tung.quang.nguyen@est.tech
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
'clk-tenstorrent' and 'clk-pile' into clk-next
* clk-renesas: (25 commits)
clk: renesas: r8a78000: Add SGASYNCD8_PERW_BUS
clk: renesas: rzg2l: Fix internal clock names
clk: renesas: r9a08g046: Add TSU and ADC1 clocks and resets
clk: renesas: Add support for RZ/G2M v3.0
clk: renesas: r9a08g046: Add CANFD clocks and resets
clk: renesas: r9a08g046: Propagate clk rate for ETH TX mux clocks
dt-bindings: clock: Add r8a774a3 CPG Core Clock definitions
clk: renesas: r8a779g0: Add ZG clocks
clk: renesas: rcar-gen4: Tidy up DEF_GEN4_Z()
clk: renesas: r9a09g077: Register SYSC regmap
clk: renesas: rcar-gen3: Use FIELD_GET()
clk: renesas: rzv2h: Convert to clk_hw based provider API
clk: renesas: rzv2h: Drop duplicated parent lookup in fixed_mod_status_clk_register()
clk: renesas: r9a08g046: Add PCIe clocks and reset
clk: renesas: Make sure clk_init_data is fully initialized
clk: renesas: r9a08g046: Add clock and reset entries for LVDS
clk: renesas: r9a08g046: Add MIPI DSI and LCDC clock/reset entries
clk: renesas: r9a08g046: Sort macro definitions alphabetically
clk: renesas: rzg2l: Add support for RZ/G3L DSI mux
clk: renesas: rzg2l: Add support for LVDS fixed-factor divider with 4:7 duty cycle
...
* clk-samsung:
clk: samsung: acpm: add Exynos850 support
clk: samsung: acpm: introduce driver data for SoC-specific clocks
clk: samsung: Introduce Exynos5515 clock driver
clk: samsung: clk-pll: Add support for pll_309
dt-bindings: clock: Add Exynos5515 SoC
* clk-starfive:
dt-bindings: soc: starfive: Add StarFive JHB100 syscon modules
dt-bindings: clock: Add StarFive JHB100 Peripheral-3 clock and reset generator
dt-bindings: clock: Add StarFive JHB100 Peripheral-2 clock and reset generator
dt-bindings: clock: Add StarFive JHB100 Peripheral-1 clock and reset generator
dt-bindings: clock: Add StarFive JHB100 Peripheral-0 clock and reset generator
dt-bindings: clock: Add StarFive JHB100 System-2 clock and reset generator
dt-bindings: clock: Add StarFive JHB100 System-1 clock and reset generator
dt-bindings: clock: Add StarFive JHB100 System-0 clock and reset generator
* clk-tenstorrent:
MAINTAINERS: Update RISC-V Tenstorrent SoC entry
clk: tenstorrent: use regmap_assign_bits() for conditional set/clear
clk: tenstorrent: Fix refcount leak on shared gate clk enable failure
clk: tenstorrent: Assign .num before accessing .hws
* clk-pile: (126 commits)
clk: imx: pll14xx: support spread spectrum clock generation
clk: cdce925: Size the PLL child name buffer for any int
clk: stm32: fix clock array size for STM32MP21
dt-bindings: clock: Convert HiSilicon clocks to DT schema
clk: lmk04832: Handle reset GPIO lookup errors
dt-bindings: clock: anlogic,dr1v90-cru: make external clocks optional
clk: tegra: bpmp: remove kcalloc
clk: mmp2-audio: add missing PM_CLK dependency
clk: zte: Introduce a driver for zx297520v3 LSP clocks
clk: zte: Introduce a driver for zx297520v3 matrix clocks
clk: zte: Introduce a driver for zx297520v3 top clocks
clk: zte: Add zx PLL support infrastructure
clk: zte: Add regmap-based clocks
clk: zte: Add Clock registration infrastructure
dt-bindings: clk: zte: Add zx297520v3 LSP clock and reset controller
dt-bindings: clk: zte: Add zx297520v3 matrix clock and reset controller
dt-bindings: clk: zte: Add zx297520v3 top clock and reset controller
clk: nuvoton: ma35d1: Add missing WDT/WWDT parent clocks
dt-bindings: clock: ma35d1: Add missing WDT/WWDT parent clocks
dt-bindings: clock: ma35d1: Drop CLK_MAX_IDX define
...
|
|
and 'clk-qcom' into clk-next
* clk-allwinner:
clk: sunxi-ng: ccu_common: Use readl_relaxed_poll_timeout_atomic for PLL lock
clk: sunxi-ng: sun55i-a523-r-ccu: Use P-only clocks for timers
clk: sunxi-ng: sun55i-a523-ccu: Use P-only clocks for high-speed timers
clk: sunxi-ng: sun55i-a523-ccu: Use M-only clocks for MBUS, IOMMU and DRAM
clk: sunxi-ng: div: Add feature support to M clock macro
* clk-amlogic:
clk: meson: t7: don't mark sys_ampipe_nand as critical
dt-bindings: clock: Add Amlogic A9 SCMI clock controller
clk: meson: t7: keep the memory fabric clocks running
* clk-imx:
clk: imx: Fix clock reference leak in imx_obtain_fixed_clock_hw()
clk: imx: Fix clock reference leak in imx_get_clk_hw_by_name()
clk: imx: fracn-gppll: Add 350 MHz support
clk: imx: composite-93: return timeout from gate enable
* clk-microchip:
clk: at91: main: Drop unneeded cast in at91_clk_register_main_osc()
* clk-qcom: (156 commits)
clk: qcom: Add support for camera clock controller on Maili
clk: qcom: ipq9650: Use icc-clk for enabling NoC related clocks
clk: qcom: ipq5210: add 24MHz rate for USB UTMI clock
clk: qcom: ipq5332: add 24MHz rate for USB UTMI clock
clk: qcom: ipq5018: add 24MHz rate for USB UTMI clock
clk: qcom: Fix camera rivian PLL configuration settings
clk: qcom: videocc-sm8350: Use common probe handling for always-on clocks
clk: qcom: videocc-sm8250: Use common probe handling for always-on clocks
clk: qcom: videocc-sm7150: Use common probe handling for always-on clocks
clk: qcom: videocc-sm6350: Use common probe handling for always-on clocks
clk: qcom: videocc-sa8775p: Use common probe handling for always-on clocks
clk: qcom: lpasscorecc-sc7180: Use common probe handling for always-on clocks
clk: qcom: gpucc-x1p42100: Use common probe handling for always-on clocks
clk: qcom: gpucc-x1e80100: Use common probe handling for always-on clocks
clk: qcom: gpucc-sm8550: Use common probe handling for always-on clocks
clk: qcom: gpucc-sm4450: Use common probe handling for always-on clocks
clk: qcom: gpucc-sc8280xp: Use common probe handling for always-on clocks
clk: qcom: gpucc-sc7280: Use common probe handling for always-on clocks
clk: qcom: gpucc-sar2130p: Use common probe handling for always-on clocks
clk: qcom: gcc-x1e80100: Use common clock controller probe data
...
|
|
Add support for spread spectrum clock (SSC) generation to the pll14xx
driver.
Tested on the video PLL of i.MX8MN and i.MX8MP based boards.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Acked-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Link: https://patch.msgid.link/20260904101243.412006-5-dario.binacchi@amarulasolutions.com
Signed-off-by: Brian Masney <bmasney@redhat.com>
|
|
The PLL child node name is built from "PLL%d" in a 6 byte stack buffer.
The PLL index is bounded by the chip's num_plls, at most 4, but GCC
cannot see that bound and, with W=1, warns that the formatted string
may not fit.
Make the buffer large enough to hold any int and use snprintf() with
sizeof() so the size stays tied to the declaration.
Fixes: 19fbbbbcd3a3 ("Add TI CDCE925 I2C controlled clock synthesizer driver")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://patch.msgid.link/20261014-cdce925-truncate-child-name-v1-1-00136be00c49@baylibre.com
Signed-off-by: Brian Masney <bmasney@redhat.com>
|
|
STM32MP21_LAST_CLK is used as the number of entries of the onecell
clk_hw array allocated in stm32_rcc_clock_init(), and as the bound of
the clock IDs it can hold. It was wrongly set to CK_SCMI_KER_ETR (112),
which belongs to the SCMI clock ID range, whereas the RCC clock IDs
go up to CK_KER_STM (289).
As a result the array is too small, and registering a clock whose ID
is greater than 111 writes past the end of the allocated clk_hw array
(hws[cfg_clock->id] = hw), and consumers requesting such a clock
get rejected or read out of bounds.
Define STM32MP21_LAST_CLK as CK_KER_STM + 1 so that the array covers
all the RCC clock IDs.
No device tree node uses the STM32MP21 RCC driver yet, so there is no
need to backport this patch to stable kernels.
Fixes: 37ae8501cdb0 ("clk: stm32: introduce clocks for STM32MP21 platform")
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@foss.st.com>
Link: https://patch.msgid.link/20261012131859.215240-1-gabriel.fernandez@foss.st.com
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Brian Masney <bmasney@redhat.com>
|
|
Convert the HiSilicon Hi6220/Hi3660/Hi3670 clock bindings to DT schema
format. Rearrange the binding documents splitting out the stub clock
binding from everything else.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Wei Xu <xuwei5@hisilicon.com>
Link: https://patch.msgid.link/20261001212051.2227941-1-robh@kernel.org
Signed-off-by: Brian Masney <bmasney@redhat.com>
|
|
devm_gpiod_get_optional() may return -EPROBE_DEFER or other errors,
but lmk04832_probe() currently ignores them.
Check the return value and propagate errors from the reset GPIO lookup.
Fixes: 3bc61cfd6f4a ("clk: add support for the lmk04832")
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Link: https://patch.msgid.link/20261006110501.57051-1-phucduc.bui@gmail.com
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Brian Masney <bmasney@redhat.com>
|
