Merge tag 'sound-7.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"A collection of small fixes as usual. A couple of regression fixes are
included in addition to the various quirks and device-specific fixes.
ALSA Core:
- PCM: Fix potential inconsistent PCM state reporting after XRUN
HD-audio:
- Fix sysfs hint parser
- Revert CS4208 fixup for MacBookAir 7,2 due to regressions
- ACPI _DSD fixes for CS35L41 side-codec on various HP laptops
- Device quirks for Acer (Predator, TravelLite) and Dell (Pro QC1255,
XPS 8940)
USB-audio:
- Fix for USB controller bugs reporting oversized packets
- Fix UAF on disconnect in caiaq
[40 lines not shown]
Merge tag 'block-7.4-20261112' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
Pull block fixes from Jens Axboe:
- ublk fixes: don't publish a new device in the idr until it's fully
set up, and don't hold ublk_ctl_mutex across device removal, as a
stuck filesystem on one device otherwise blocked ADD_DEV and DEL_DEV
for every other ublk device.
- s390/dasd fixes: re-initialize the RCD buffer magic before every
request start, fix a wrong free and refcount leak in the check_tcw
error path, don't trust the userspace-supplied result field in the
format check, and a typo fix.
* tag 'block-7.4-20261112' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
s390/dasd: Don't trust userspace-supplied result field in format check
s390/dasd: Fix wrong free and refcount leak in build_check_tcw error path
s390/dasd: Re-initialize RCD buffer with "V1.0" before every start
s390/dasd: Fix typo 'immediatly' -> 'immediately'
[2 lines not shown]
Merge tag 'io_uring-7.4-20261112' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
Pull io_uring fix from Jens Axboe:
- Don't end the NAPI busy poll early on need_resched() when a single
NAPI is registered, as that left the rest of the wait timeout
sleeping in schedule_hrtimeout() rather than busy polling.
* tag 'io_uring-7.4-20261112' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
io_uring/napi: don't end the single NAPI busy poll early on need_resched()
Merge tag 'cifs-fixes-7.4-rc3' of https://git.manguebit.org/linux
Pull smb client fixes from Paulo Alcantara:
- Fix silent data loss in writeback
Since the move to netfslib a transient failure (a reconnect, a lost
handle, an interrupted wait, -ENOMEM, or a task killed while close()
flushes its dirty pages) ended writeback with the folios clean and
no error, dropping the write.
Retry it instead, bounded by the hard and retrans mount options, and
have umount -f abort the retries and the reconnect and credit waits
so the unmount's own sync can't hang
- Prefer a non-O_DIRECT handle for writeback, as Windows rejects
unaligned I/O on O_DIRECT handles and silently dropped about 1% of
the writes in generic/051
[50 lines not shown]
Merge tag 'erofs-for-7.4-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs
Pull erofs fixes from Gao Xiang:
- Fix stacked fs check for file-backed mounts with extra devices
- Disallow file-backed mounts on shared backing inodes
- Reset metadata offsets when fsoffset= is used to fix xattr reads
inside and outside the metabox in ont shot
- Refine on-disk format summary
* tag 'erofs-for-7.4-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs:
docs: erofs: refine the on-disk overview
erofs: reset buf->off in erofs_init_metabuf()
erofs: treat files shared by inode_share as stacked
erofs: apply the stacked fs check to extra file-backed devices
ALSA: aw2-alsa: select SND_PCM
Several stanzas in sound/pci/Kconfig select SND_PCM.
SND_AW2 selects nothing at all.
aw2-alsa calls snd_pcm_new, which sound/core/pcm.c provides under SND_PCM.
aw2-alsa.c:(.text+0x554): undefined reference to `snd_pcm_new'
4 symbols are undefined in all.
The driver can be built into vmlinux while SND_PCM is a module, in which
case the symbols are not there at link time.
Select rather than depend on: SND_PCM has no prompt of its own and is only
ever enabled by a select, so a depends on would leave SND_AW2
unselectable.
Reproduced on v7.3, arm64, with CONFIG_SND_AW2=y and CONFIG_SND_PCM=m.
[8 lines not shown]
Merge tag 'asoc-fix-v7.4-rc2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v7.4
Another week, another pile of driver specific fixes and quirks. We do
have one major fix which addresses a bug introduced by confusion with
the counted_by interfaces that was causing major disruption for a number
of platforms.
Merge tag 'net-7.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Pull networking fixes from Jakub Kicinski:
"Including fixes from netfilter, wireless and bluetooth.
Previous releases - regressions:
- tcp: rate limit receive queue collapsing
- raw: fix ICMP unreachable sent when receive queue is full
- eth: bnxt_en: take RTNL before netif_close() when aborting FW reset
Previous releases - always broken:
- tcp:
- bound snd_cwnd_clamp to TCP_MAX_SND_CWND
- number of fixes for TCP Fast Open
[41 lines not shown]
Merge branch 'nsh-limit-recursion-in-nsh_gso_segment'
Eric Dumazet says:
====================
nsh: limit recursion in nsh_gso_segment()
Sashiko found that nsh_gso_segment() can call itself, through
skb_mac_gso_segment(), once per stacked NSH header. Nothing limits the
depth, and a 64KB GSO packet made of 8-byte NSH headers overflows the
kernel stack. It was reported while reviewing an unrelated virtio
series [1].
Such a packet can be sent with a packet socket using PACKET_VNET_HDR,
when the nsh module is loaded.
Patch 1 uses the recursion counter added in commit 006c8b834aed ("net:
gso: limit recursive IP-in-IP segmentation"), with the same limit as
IPv4 and IPv6.
[7 lines not shown]
selftests: net: add a test for NSH GSO
Send TCPv4 GSO packets encapsulated in a stack of NSH headers to a
dummy device which has TSO disabled, using a packet socket with
PACKET_VNET_HDR, and count the packets the device transmits.
Packets with one or four NSH headers must be segmented. Packets with
5, 64 or 8000 NSH headers must be dropped: they exceed the recursion
limit of the GSO handlers. Without the limit in nsh_gso_segment(),
the last one overflows the kernel stack.
# ./nsh_gso.sh
PASS: 1 NSH headers: 4 packets sent
PASS: 4 NSH headers: 4 packets sent
PASS: 5 NSH headers: 0 packets sent
PASS: 64 NSH headers: 0 packets sent
PASS: 8000 NSH headers: 0 packets sent
Signed-off-by: Eric Dumazet <edumazet at kernel.org>
[2 lines not shown]
nsh: limit recursion in nsh_gso_segment()
nsh_gso_segment() calls skb_mac_gso_segment() for the inner packet,
which calls nsh_gso_segment() again when the next protocol is NSH,
either directly or behind an inner Ethernet header (ETH_P_TEB).
Nothing limits the depth: a GSO packet made of stacked 8-byte NSH
headers recurses once per header, and a 64KB packet can hold about
8000 of them, overflowing the kernel stack.
Such a packet can be injected with a packet socket using
PACKET_VNET_HDR, or with tun/tap or virtio_net, as nothing checks
that a GSO packet with VIRTIO_NET_HDR_F_NEEDS_CSUM carries the
protocol it claims. It is then segmented in software if the output
device does not support the GSO type:
BUG: TASK stack guard page was hit at ffffcad5c0ab3ff8 (stack is ffffcad5c0ab4000..ffffcad5c0ab8000)
Oops: stack guard page: 0000 [#1] SMP NOPTI
CPU: 3 UID: 0 PID: 337 Comm: nsh_gso Tainted: G E 7.4.0-rc1+ #118 PREEMPT(lazy)
[35 lines not shown]
Merge branch 'net-tls-break-the-connection-after-a-burst-of-empty-data-records'
Jakub Kicinski says:
====================
net: tls: break the connection after a burst of empty data records
Deal with overload of zero-length TLS records. This is the next iteration
of Chuck's series. I tried to make it as simple as possible - break the
connection if sender floods us with zero-length records. Consume / discard
those records even on PEEK to avoid infinite rx_list growth.
https://lore.kernel.org/20261019-tls-follow-on-v6-0-ab01c4ecca0c@kernel.org
====================
Link: https://patch.msgid.link/20261111185522.2859004-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
tls: Consume empty data records in tls_sw_splice_read()
A zero-length application_data record decrypts to full_len == 0,
so tls_sw_splice_read() splices zero bytes and returns zero. A zero
return from a splice read means EOF, and the caller tears down a
connection that is still live.
Consume the record and fetch the next one, as tls_sw_read_sock()
does. The cap on consecutive empty records bounds the loop.
When an empty record precedes a close_notify, splice(2) now returns
-EINVAL from the control-record test instead of a false EOF. A
splice that reaches an alert record already reports -EINVAL.
Fixes: c46234ebb4d1 ("tls: RX path for ktls")
Reported-by: Sabrina Dubroca <sd at queasysnail.net>
Closes: https://lore.kernel.org/netdev/akaoXcfamBp8_mYe@krikkit/
Signed-off-by: Chuck Lever <cel at kernel.org>
Link: https://patch.msgid.link/20261111185522.2859004-3-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
selftests: tls: Skip the zero_len tests when TLS is unavailable
FIXTURE_SETUP(zero_len) returns early when ulp_sock_pair() reports
that the TCP_ULP setsockopt failed, so on a kernel built without
CONFIG_TLS the TLS_RX setsockopt never runs. TEST_F(zero_len, test)
then sends its raw records over a plain TCP socket, which returns
the ciphertext verbatim. All eight variants FAIL on a machine that
lacks TLS, and those failures mask any real regression in the same
run.
Skip the test when the fixture recorded notls, as the other
fixtures in this file do.
Fixes: a61a3e961baf ("selftests: tls: add tests for zero-length records")
Signed-off-by: Chuck Lever <cel at kernel.org>
Link: https://patch.msgid.link/20261111185522.2859004-4-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
selftests: tls: Cover the cap on consecutive empty records
Check through both recv() and splice() that a run of 128 empty data
records is consumed and the data record behind it is delivered, and
that a run of 129 breaks the connection with EBADMSG before the data
record can be read. Two runs of 128 with a read returning EAGAIN in
between must not break the connection, the cap applies to a burst the
reader cannot keep up with, not to the connection as a whole.
kTLS cannot send an empty record. A TLS 1.3 record of type 0 whose
only byte is the data content type decrypts to one, since the receiver
strips the 0 as padding.
Reviewed-by: Chuck Lever <cel at kernel.org>
Link: https://patch.msgid.link/20261111185522.2859004-6-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
selftests: tls: Extend coverage for zero-length records
The zero_len fixture injects raw pre-encrypted records over a
socket carrying a TLS_RX key only, and some of those records are
zero-length application_data records. Every variant reads the
records back with recvmsg() without MSG_PEEK, so neither splice nor
MSG_PEEK is tested against an empty record.
Add zero_len_splice and zero_len_peek. A zero return from splice()
means EOF, so zero_len_splice checks that a run of empty data
records does not end a live connection. zero_len_peek checks that a
peek reaches the payload behind a run of empty records and leaves
the payload in place for the read that follows. When a payload does
not follow the run, the peek must leave the socket unreadable. An
unfixed kernel returns 0 from splice(), and after the peek poll()
reports the socket readable.
Signed-off-by: Chuck Lever <cel at kernel.org>
Link: https://patch.msgid.link/20261111185522.2859004-5-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
tls: Break the connection after a burst of empty data records
TLS permits zero-length application_data records, and RFC 8446
suggests them for generating cover traffic. Nothing bounds how many of
them a reader processes back to back, though. They advance neither
loop bound in tls_sw_recvmsg() and tls_sw_read_sock(), so a peer
streaming them faster than the reader decrypts them keeps it in the
kernel for as long as they arrive. recvmsg() does not check for signals
while records are ready, and its peek and async paths queue every empty
record on rx_list. read_sock consumers like nvme-tcp hold the socket
lock throughout and never get control back.
Break the connection once a reader decrypts more than 128 consecutive
empty data records without sleeping or returning to its caller in
between, treating the burst as a protocol violation like a malformed
record header. A stream of empty records which the reader keeps up with
costs no more than any other traffic, so the count starts over on every
read and whenever the reader waits for the next record. The strparser
is stopped before it parses the next record, so the reader gets the
[22 lines not shown]
Merge tag 'for-7.4-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux
Pull btrfs fixes from David Sterba:
- zoned mode fixes
- fix counting active zones after activation
- redo zone reset after error
- update device lock range during mount and zone loading
to avoid lockdep warnings with device drivers (virtio)
- space accounting and extent buffer handling fixes
- fix keeping zstd workspace for the last level
- handle a real case of a subvolume with 0 refs in the SUBVOL_SYNC
ioctl
- properly handle case of zero num_stripes when reading chunk items
- exclude reloc tree from xarray as it is special and its key does
[20 lines not shown]
net: phy: c45: select BASE-T1 type for the forced speed
Commit 25108a834e14 ("net: phy: c45: add support for 1000BASE-T1 forced
setup") made genphy_c45_pma_setup_forced() write the type selection
field (bits 3:0) of the BASE-T1 PMA/PMD control register (1.2100) on
every forced setup: 1000BASE-T1 for SPEED_1000, and 0 for everything
else. 0 selects 100BASE-T1, so forcing a 10BASE-T1L PHY to 10 Mbit/s
now also switches its PMA to 100BASE-T1, a mode it does not implement.
Seen on an ADIN1110 (internal ADIN1100 PHY): after
ethtool -s ethX autoneg off speed 10 master-slave forced-master
1.2100 reads 0xc000 instead of the 0xc002. Since the field is not
restored by re-enabling autoneg, the PHY keeps the wrong type until
the next forced setup or reset.
Add a helper that returns the type selection value for the forced speed
and the supported link modes: 100BASE-T1, 1000BASE-T1, and 10BASE-T1L or
[16 lines not shown]
net/mlx5e: Fix false WARN_ON_ONCE in flow steering cleanup on RX init failure
mlx5e_attach_netdev() sets rx_mode_active before calling init_rx(), so
any init_rx() failure after mlx5e_create_flow_steering() has succeeded
makes mlx5e_destroy_flow_steering() trip
WARN_ON_ONCE(fs->rx_mode_active) in mlx5e_del_vlan_rules().
Hit in internal regression testing, so kthread creation failed
with -EINTR:
WARNING: CPU: 3 PID: 170 at drivers/net/ethernet/mellanox/mlx5/core/en_fs.c:564 mlx5e_del_vlan_rules+0x295/0x2b0 [mlx5_core]
mlx5e_destroy_flow_steering+0x34/0xc0 [mlx5_core]
mlx5e_init_nic_rx+0x137/0x200 [mlx5_core]
mlx5e_attach_netdev+0x105/0x360 [mlx5_core]
Fix it by creating NIC flow steering with rx_mode_active cleared and
setting it only after profile->init_rx() succeeds. This also lets the
internal error paths of mlx5e_create_flow_steering() destroy partially
created steering without warning. The flag is set in
[11 lines not shown]
net/mlx5e: IPsec, don't match upper proto selectors in crypto offload TX
The mentioned commit introduced support for upper protocol selectors
(protocol & ports) to mlx5 IPsec offload. In crypto offload mode this
causes offloaded TX SAs to stop matching traffic.
In tx_add_rule(), setup_fte_upper_proto_match() is called for all
offload types and programs a match on the upper protocol (TCP/UDP) and
ports. For crypto offload, setup_fte_esp() is then called and sets
ip_protocol to ESP. The resulting rule requires both ESP as the IP
protocol and TCP/UDP ports, which no packet can satisfy, so TX crypto
offload silently stops working for such SAs.
In crypto offload mode the stack builds the ESP packet and the HW only
encrypts it, so the SA rule should only match on the SPI. Move the
setup_fte_upper_proto_match() call under the XFRM_DEV_OFFLOAD_PACKET
case, where the rule matches the plaintext packet and upper protocol
selectors apply.
[11 lines not shown]
tcp: fix request_sock use-after-free during Fast Open accept()
Commit e3d95ad7da4f ("inet: avoid fastopen lock for regular accept()")
made inet_csk_accept() check tfo_listener before taking fastopenq.lock
to avoid taking the lock for connections that did not use Fast Open.
reqsk_fastopen_remove() clears tfo_listener while holding fastopenq.lock,
then reads req->sk. If inet_csk_accept() concurrently observes
tfo_listener after it has been cleared, it skips fastopenq.lock and
drops the last reference to the request_sock. This can free the
request_sock while reqsk_fastopen_remove() is still using it.
If the freed memory is reused for a new request_sock with req->sk ==
NULL, the reset path in reqsk_fastopen_remove() can append the new
request_sock to the original listener's list of requests that caused an
RST. After the new request_sock is freed, the next append writes through
the stale rskq_rst_tail into freed memory.
KASAN reported the following use-after-free when writing
[46 lines not shown]
net: usb: cdc_ncm: don't underflow the NDP room check
cdc_ncm_ndp16() and cdc_ncm_ndp32() verify that the new NDP and the
datagram fit into the NTB with an unsigned subtraction:
if ((ctx->tx_curr_size - skb->len - reserve) < ctx->max_ndp_size)
return NULL;
Nothing guarantees that skb->len plus the reserve stays below
tx_curr_size, and when it does not the subtraction wraps around to a
huge value, the check passes, and the skb_put_zero() of max_ndp_size
bytes that follows overruns the NTB:
skbuff: skb_over_panic: text:ffff80000db33558 len:428 put:172
head:ffff0000c2c66100 tail:0x1ac end:0x140
kernel BUG at net/core/skbuff.c:200
skb_put_zero include/linux/skbuff.h:2595 [inline]
cdc_ncm_ndp16 drivers/net/usb/cdc_ncm.c:1132 [inline]
cdc_ncm_fill_tx_frame+0xdf0/0x30e0 drivers/net/usb/cdc_ncm.c:1309
[33 lines not shown]
net: netns: fix INT_MAX nsid cleanup
A syzkaller reproducer assigning INT_MAX as a peer nsid triggers an
idr_get_next() warning during netns cleanup. With panic_on_warn, this
panics the kernel.
alloc_netid() also overflows reqid + 1 for this nsid. Use
idr_alloc_u32() for requested IDs and idr_get_next_ul() for cleanup so
the cursor can advance past INT_MAX.
QEMU/KVM reproduced the warning without kernel changes or fault
injection. The same reproducer ran without warnings after this change.
Kernel selftests were not run.
Fixes: 7acee67a6bce ("netns: optimize netns cleaning by batching unhash_nsid calls")
Cc: stable at vger.kernel.org
Signed-off-by: Zhao Gongyi <zhaogongyi at bytedance.com>
Link: https://patch.msgid.link/20261111033525.65828-1-zhaogongyi@bytedance.com
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
amt: use ipv6_hdr() in amt_mldv1_leave_handler()
In amt_mldv1_leave_handler(), which handles IPv6 MLDv1 Done
(ICMPV6_MGM_REDUCTION) messages, the source address is mistakenly
extracted via ip_hdr(skb)->saddr into host.ip4 instead of copying the
IPv6 source address from ipv6_hdr(skb)->saddr into host.ip6 as
amt_mldv1_report_handler() does.
Because amt_lookup_group() compares the full union amt_addr for v6
groups, looking up the group with a 32-bit IPv4 header slice fails to
match the group entry created by amt_mldv1_report_handler(). As a
result, amt_del_group() is not called when an MLDv1 listener leaves,
and the AMT relay continues forwarding multicast traffic until the
group timer expires.
Use ipv6_hdr(skb) and copy ip6h->saddr into host.ip6 so that MLDv1
Done messages properly match and delete the corresponding IPv6 group.
This issue was found via LLM-assisted code review, confirmed by
[8 lines not shown]
af_unix: Inherit SO_INQ in unix_stream_connect()
When SO_INQ is enabled on a listening AF_UNIX SOCK_STREAM socket,
accepted sockets created by unix_stream_connect() do not inherit
u->recvmsg_inq from the listener, unlike TCP_INQ, AF_VSOCK SO_INQ,
and AF_UNIX SO_RIGHTS_NOTRUNC. As a result, recvmsg() on the
accepted socket never puts an SCM_INQ control message unless SO_INQ
is set again after accept().
Copy otheru->recvmsg_inq to newu->recvmsg_inq in
unix_stream_connect() using READ_ONCE() to pair with the lockless
WRITE_ONCE() in unix_setsockopt().
Found during LLM-assisted code review of unix_stream_connect() while
comparing option inheritance between SO_INQ and SO_RIGHTS_NOTRUNC.
Confirmed on UML (x86_64) by enabling SO_INQ on a listening AF_UNIX
SOCK_STREAM socket before listen() and accept(), sending data from a
connected client, and observing that recvmsg() on the accepted socket
[12 lines not shown]
tcp: Pass req->rsk_listener to inet_csk_reqsk_queue_drop() in tcp_check_req().
When connection migration happens in tcp_v[46]_rcv(), a new
listener is passed to tcp_check_req().
When either of the following is true,
* the new listener queue is full and
net.ipv4.tcp_abort_on_overflow is set
* the packet has RST or (not stripped) SYN
tcp_check_req() sends RST and calls inet_csk_reqsk_queue_drop().
Here, the new listener is passed, and its qlen is decremented
wrongly while reqsk is tied to the old listener.
Once qlen underflows, inet_csk_reqsk_queue_is_full() always
return true, and the new listener stops serving.
[32 lines not shown]
mailmap: add entries for Hangbin Liu
Add the active email address for Hangbin Liu and map the old or rarely-used
addresses to it. This prevents get_maintainer.pl from listing not actively
used addresses as patch recipients.
Signed-off-by: Hangbin Liu <liuhangbin at kylinos.cn>
Link: https://patch.msgid.link/20261111-mailmap-v1-1-8ab349555808@kylinos.cn
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
Merge branch 'net-virtio-validate-outer-protocol-of-udp-tunnel-gso-packets'
Eric Dumazet says:
====================
net: virtio: validate outer protocol of UDP tunnel GSO packets
virtio_net_hdr_tnl_to_skb() does not check that a UDP tunnel GSO
packet really has outer IPv4/IPv6 and UDP headers matching the
declared tunnel type. A guest, or any tap writer, can send a frame
with another outer ethertype (NSH in the report), and the GSO stack
then builds segments with skb->data before skb->head. The host
crashes in skb_under_panic() as soon as a header is pushed.
Patch 1 fixes the producer side, virtio_net_hdr_tnl_from_skb(), for
VLAN tagged packets:
- the tunnel offsets did not account for the VLAN tag tun inserts in
the frame, and were 4 bytes short.
- the outer family came from skb->protocol, which is the VLAN protocol
[21 lines not shown]
