linux-stable.git/drivers, branch v7.2.6

dm-integrity: fix buffer overflow with keyed discard

2026-09-14T11:41:11+00:00

commit 59e6f919d77d72ec79cbf171256f2f7819737580 upstream.

Since commit 68c5c42567bc ("dm-integrity: replace forgeable discard
filler with a keyed sector marker"), integrity_metadata computes a
checksum for every discarded block into the "checksums" buffer.
integrity_sector_checksum always writes the whole digest. So if the tag
size is smaller than the digest size, the checksum of the last block
that fits into the buffer is written past the end of it. For example,
with hmac(sha256) and tag size 16, a 4MiB discard writes 16 bytes past
the kmalloc'ed page.

Fix this by subtracting extra_space from the buffer size when computing
max_blocks, like we do for writes.

Fixes: 68c5c42567bc ("dm-integrity: replace forgeable discard filler with a keyed sector marker")
Reviewed-by: Jose Fernandez (Anthropic) 
Signed-off-by: Ben Cressey 
Assisted-by: Claude:unspecified
Signed-off-by: Mikulas Patocka 
Signed-off-by: Greg Kroah-Hartman

usb: atm: usbatm: fix invalid ci_range initialization

2026-09-14T11:41:11+00:00

[ Upstream commit a60fd8c6dbaa76da4163cf225ed2b9e982540f39 ]

syzbot reported a shift-out-of-bounds in __vcc_connect():

  UBSAN: shift-out-of-bounds in net/atm/common.c:382:32
  shift exponent -1 is negative
  CPU: 0 UID: 0 PID: 5987 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full)
  Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/05/2026
  Call Trace:
   
   dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
   ubsan_epilogue+0xa/0x30 lib/ubsan.c:233
   __ubsan_handle_shift_out_of_bounds+0x36d/0x400 lib/ubsan.c:494
   __vcc_connect+0x14b4/0x19c0 net/atm/common.c:382
   vcc_connect+0x328/0x8f0 net/atm/common.c:498
   pvc_bind+0x272/0x380 net/atm/pvc.c:52
   __sys_bind+0x2e3/0x410 net/socket.c:1976
   __x64_sys_bind+0x7a/0x90 net/socket.c:1979
   ...

ATM device ci_range fields (vpi_bits and vci_bits) represent the
number of bits supported for VPI and VCI addressing on the device.
net/atm/common.c directly uses these fields as bit shift counts:
  vpi >> dev->ci_range.vpi_bits
  vci >> dev->ci_range.vci_bits
  1 << vcc->dev->ci_range.vpi_bits
  1 << vcc->dev->ci_range.vci_bits

usbatm_atm_init() sets ci_range.vpi_bits and ci_range.vci_bits to
ATM_CI_MAX (-1), which is defined in  as a
sentinel value for userspace ATM_SETCIRANGE requests, not a valid bit
count. Shifting by -1 is undefined behavior and triggers UBSAN
warnings.

ATM UNI cell headers allow up to 8 bits for VPI (0..255) and 16 bits
for VCI (0..65535). Initialize vpi_bits to 8 and vci_bits to 16, as
done by solos-pci.

Fixes: c59bba75fa50 ("[PATCH] USB ATM: new usbatm core")
Reported-by: syzbot+6665d3db5fef15914802@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=6665d3db5fef15914802
Suggested-by: Eric Dumazet 
Link: https://lore.kernel.org/all/20260824024620.23485-1-kartikey406@gmail.com/T/ [v1]
Signed-off-by: Deepanshu Kartikey 
Link: https://patch.msgid.link/20260826133258.8306-1-kartikey406@gmail.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

net: fec: only stop PTP if it was initialized

2026-09-14T11:41:10+00:00

[ Upstream commit dd890ae29299636fb037276fc1b5238698d08b03 ]

fec_ptp_init() is only called when fep->bufdesc_ex is available.
However, fec_probe() unconditionally calls fec_ptp_stop() on the
failed_init path, and fec_drv_remove() unconditionally calls
fec_ptp_stop() during device removal.

Check fep->bufdesc_ex before calling fec_ptp_stop() in both paths
to avoid stopping PTP when it was not initialized.

Fixes: 32cba57ba74b ("net: fec: introduce fec_ptp_stop and use in probe fail path")
Reviewed-by: Wei Fang 
Reviewed-by: Frank Li 
Signed-off-by: bui duc phuc 
Link: https://patch.msgid.link/20260826103428.32807-1-phucduc.bui@gmail.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

slip: remove slip_hangup() to fix use-after-free in slip_receive_buf()

2026-09-14T11:41:10+00:00

[ Upstream commit 23c53269f2baaedf2d92784290cb9ef6db2a3bce ]

Jaeyoung Chung and Eulgyu Kim reported a slab-use-after-free read
in slip_receive_buf() when racing against tty hangup.

tty_ldisc_hangup() calls ld->ops->hangup() while holding only
a read lock on tty->ldisc_sem (via tty_ldisc_ref()).
Because slip_hangup() simply called slip_close(), it ran concurrently
with reader functions such as slip_receive_buf().

slip_close() unregisters and frees the net device and its private
struct slip, causing concurrent reader threads in slip_receive_buf()
to dereference freed memory.

Line discipline close() is already guaranteed to be called under
the write lock of tty->ldisc_sem during hangup processing
(in tty_ldisc_reinit() or tty_ldisc_kill()).

Remove slip_hangup() so teardown is serialized cleanly by slip_close().

Fixes: 5342b77c4123 ("slip: Clean up create and destroy")
Reported-by: Jaeyoung Chung 
Reported-by: Eulgyu Kim 
Closes: https://lore.kernel.org/netdev/20260825150655.1450271-1-jjy600901@snu.ac.kr/
Cc: Qingfang Deng 
Signed-off-by: Eric Dumazet 
Link: https://patch.msgid.link/20260826105238.3323436-1-edumazet@google.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

net: dsa: mxl862xx: enable assisted learning on CPU port

2026-09-14T11:41:10+00:00

[ Upstream commit 88c71cc0ad9800d8814bd3627b21a0da9028e057 ]

The MxL862xx driver enables FDB isolation but does not enable assisted
learning on the CPU port. Consequently, MAC addresses learned through a
physical switch port are not updated in hardware when the corresponding
station moves to a foreign bridge port, such as a Wi-Fi interface.

The stale hardware FDB entry continues directing return traffic toward
the original physical port. Traffic entering that same port is then
filtered instead of being forwarded to the CPU and software bridge. This
causes downstream unicast traffic, including DHCP OFFER and ACK packets,
to disappear after a client roams to a local wireless interface. The
client eventually considers the connection unusable and disconnects.

Enable assisted CPU-port learning so DSA installs foreign bridge FDB
entries on the CPU port. This keeps the hardware FDB synchronized with
the software bridge and allows return traffic to reach locally attached
Wi-Fi clients after roaming.

Tested on a BPI R4 PRO with a MxL862xx switch and a BE14000 WiFi interface.
- Without patch, wired uplink on lan6 port (mxl path)
  Wifi clients connect but roam away not getting DHCP offers
- Without patch, wired uplink on wan port (no mxl path)
  Wifi clients connect and roam successfully
- With this patch, uplink on lan6 (mxl path)
  Wifi clients connect and roam successfully

Fixes: 340bdf984613 ("net: dsa: mxl862xx: implement bridge offloading")
Signed-off-by: Edoardo Pinci 
Link: https://patch.msgid.link/DU0P251MB069949C6DEB4D1D51F31FE87C4A02@DU0P251MB0699.EURP251.PROD.OUTLOOK.COM
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

net: stmmac: restore NET_IP_ALIGN in the RX DMA offset

2026-09-14T11:41:10+00:00

[ Upstream commit 23680bf5f8c69c923546b84a8e6c401bef8b88fe ]

Since the RX path was converted to zero-copy, the page pool page is handed
to the stack directly as the skb head, and the offset the DMA engine writes
at is what determines the alignment of the packet headers.

Before the conversion the payload was copied into an skb obtained from
napi_alloc_skb(), which reserves NET_SKB_PAD + NET_IP_ALIGN. The
conversion moved the headroom into stmmac_rx_offset() but did not carry
over NET_IP_ALIGN, so on architectures where NET_IP_ALIGN is 2 the IP
header now lands misaligned:

  64 (NET_SKB_PAD) + 14 (ethernet) + 20 (IP) = 98

Same for the XDP branch:

  256 (XDP_PACKET_HEADROOM) + 14 (ethernet) + 20 (IP) = 290

On ARM32 this is fatal, because ldm and ldrd trap on unaligned addresses
even when CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set.

Any received echo request panics the machine, e.g:

  Unhandled fault: alignment exception (0x001) at 0x81873062
  Internal error: : 1 [#1] SMP ARM
  Hardware name: Altera SOCFPGA Arria10
  PC is at icmp_echo+0x38/0xa8
  LR is at icmp_rcv+0x22c/0x370
  Call trace:
   icmp_echo from icmp_rcv+0x22c/0x370
   icmp_rcv from ip_protocol_deliver_rcu+0x2c/0x224
   ip_protocol_deliver_rcu from ip_local_deliver+0xc8/0x1a0
   ip_local_deliver from ip_sublist_rcv_finish+0x3c/0x50
   ip_sublist_rcv_finish from ip_list_rcv_finish+0x110/0x118
   ip_list_rcv_finish from ip_list_rcv+0xc8/0xdc
   ip_list_rcv from __netif_receive_skb_list_core+0x170/0x1c0
   ...
   napi_complete_done from stmmac_napi_poll_rx+0xcb0/0x1030
  Code: e24dd068 e59020a0 e28dc010 e0822001 (e8920003)
  Kernel panic - not syncing: Fatal exception in interrupt

The faulting instruction is the ldm of *icmp_hdr(skb) in icmp_echo().

Fix by adding NET_IP_ALIGN back to the RX offset, which restores the
alignment the stack used to get.

Note that commit a955318fe67e ("stmmac: align RX buffers") made a similar
change in 2021 and was reverted by commit 12d125b4574b ("stmmac: Revert
"stmmac: align RX buffers"") because it caused packet corruption. That
patch raised the offset from 0 without adjusting the buffer size
accounting, so the DMA engine could arguably write past the end of the RX
buffers, though this was never root caused.
Commit df542f669307 ("net: stmmac: Switch to zero-copy in non-XDP RX
path") since derives the page pool allocation from stmmac_rx_offset(), so
the extra bytes are accounted for.

Fixes: df542f669307 ("net: stmmac: Switch to zero-copy in non-XDP RX path")
Cc: Daniel Baldin 
Signed-off-by: Pascal Kneuper 
Link: https://patch.msgid.link/20260824125014.47862-1-PKneuper@dspace.de
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

net: stmmac: drop gso_enabled_types and rely on netdev features

2026-09-14T11:41:10+00:00

[ Upstream commit 9c24a504a3af1acb96da8d6a45a373fda8a9c687 ]

The gso_enabled_types field is used by stmmac_xmit() to decide whether a
GSO skb should be passed to stmmac_tso_xmit(). It is updated in
stmmac_set_features() based solely on NETIF_F_TSO, so disabling IPv4
TSO while keeping IPv6 TSO (NETIF_F_TSO6) enabled zeroes the mask. As a
result IPv6 GSO frames, which the networking stack still generates since
NETIF_F_TSO6 is enabled, fall through to the non-TSO xmit path where
they are not handled.

The networking stack already manages the GSO logic: a GSO skb is only
delivered to the driver when the matching offload feature (NETIF_F_TSO,
NETIF_F_TSO6 or NETIF_F_GSO_UDP_L4) is enabled, otherwise the frame is
segmented in software before reaching ndo_start_xmit().
stmmac_features_check() also validates each GSO frame against the TSO
hardware constraints and falls back to software GSO when they are not met.

Drop the gso_enabled_types field and rely on skb_is_gso() in
stmmac_xmit() instead, which correctly routes IPv6 GSO frames to the TSO
path when NETIF_F_TSO is disabled. This also removes the data race
between stmmac_set_gso_types(), called from the feature-set path, and
the lockless read of gso_enabled_types in stmmac_xmit().

Fixes: 2e4082e4b739 ("net: stmmac: simplify GSO/TSO test in stmmac_xmit()")
Signed-off-by: Lorenzo Bianconi 
Link: https://patch.msgid.link/20260824-stmmac-fix-tso6-features-v3-1-c73a7a4a0ec7@oss.qualcomm.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

net: stmmac: selftests: Don't test flow control for small rx fifos

2026-09-14T11:41:10+00:00

[ Upstream commit 96e8cb5527ce50c024a8e2d22d2bfedeccaf97d0 ]

On dwmac1000, dwmac4 and dwxgmac, we only emit pause frames if there's
at least 4096 bytes in each queue's fifo.

The phylink mac capabilities are still MAC_ASYM_PAUSE | MAC_SYM_PAUSE as
otherwise we won't be able to negotiate 'rx on' pause. ASYM only will
prevent negotiating 'rx off tx on', while SYM only doesn't really
matche the reality (not symmetric if we can only do RX pause).

Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support")
Signed-off-by: Maxime Chevallier 
Reviewed-by: Andrew Lunn 
Link: https://patch.msgid.link/20260826140500.616466-7-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

net: stmmac: selftests: Account for the UC filter list for filtering tests

2026-09-14T11:41:10+00:00

[ Upstream commit cd8c3b2752c684141eab2282e294cae2971a9759 ]

On dwmac, one of the Unicast filter entries is used to store the local
HW addr. This means that we have to use promisc mode for any kind of
unicast filtering if we only have one slot in our unicast filter.

The number of slots available depends on how the IP is integrated, and
we can't autodiscover how many of these slots we have available, so
the DT property snps,perfect-filter-entries can be used to specify how
many are available.

Most IP variants default to 1 if this isn't specified, which is the case
for the amlogic variants (in this case, S905X3).

The stmmac selftests for UC filtering look if we have enough slots in
the filter to store the dev->uc list, but doesn't account for the
device's own MAC address. The dev->uc list's size we get with
netdev_uc_count() also doesn't account for the HW addr.

As the selftest only requires one available slot, in the case of
single-slot platforms, that means we erroneously consider we have enough
room for the test, when we actually don't, and the filtering test fails.

Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support")
Signed-off-by: Maxime Chevallier 
Reviewed-by: Andrew Lunn 
Link: https://patch.msgid.link/20260826140500.616466-6-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

net: stmmac: dwxgmac: Account for the primary MAC address for UC filtering

2026-09-14T11:41:10+00:00

[ Upstream commit 2739d6f9a2b8729b0d85cbe0dc93e1d68670b6f2 ]

The same filter slots are used to store the main MAC address as well as
the address for the unicast filter. Let's account for that when deciding
whether or not to use promisc when programming the UC list in hardware.

Fixes: 0efedbf11f07 ("net: stmmac: xgmac: Fix XGMAC selftests")
Signed-off-by: Maxime Chevallier 
Reviewed-by: Andrew Lunn 
Link: https://patch.msgid.link/20260826140500.616466-5-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin