mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
synced 2026-11-10 20:48:12 +00:00
1,483,903 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Jakub Kicinski
|
be35a3e003 |
Still more fixes coming in, notably:
- ath11k: avoid running out of stations on HW restart
- mac80211:
- drop too large fragmented MPDUs
- mesh path handling fixes
- validation improvements
- reject CSA with bad 320 MHz bandwidth
- cfg80211: fix RTS for single radio devices
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEpeA8sTs3M8SN2hR410qiO8sPaAAFAmq9AkAACgkQ10qiO8sP
aAD8mBAAhYUPz08049fTa9JV2yYjuSpeQPk6G0GgEWCxCeAFN/2MvYYB+/dP1lST
4hNUMq3b8JWh3n7jJopkpmFsiMRP2yslXq7osTrDuliuv2cTgRJiUaEF+jVplANQ
kMPvOgeGhks9MAZSD5tLf2wBHNJ3hk7OR8YniUxymvSxh51yg4j4eFvklVgd1m5S
5TJAQeT8iUkDjo08SHkhEab8D4tkkapdXJA4itnKD9kvT/jM/HPc7FjRdDE23zmD
2jbF+oiUDfcUqQ81sBhCTUfU+MdeWLiNvMz6kvMOl9jhH2tBoVSaDgiL20vU9a4N
1rdbHowwb6bGdl857q2ET+X5UhR3ygpF8wsUlAykJmKpCSk9KRfHSCOhd28CikIm
sDJO9+gU3tqiGPjYH344XM5NGXs18QM/v6SVnsKxyEtDVK9sXc09JKcAMF1rM+0u
YRIF7+Rl4cbfmO0ys7wKG7gJV48iZPFJbtFwU80aDizpfGk/eGkCLpEc3z4UROHL
YfRpziOD2QNbj8MuGbRYUMQYudYcV7FCaBmbzRYrbtuyC0SYJwBquXOcG+GTJy6d
tZ6ZahMc3o8oHjIxf9lfJ594DAw42ClL4PT/yhuP72TQR1oIoFq+pKYhLK5oc/Qt
mIDjZ6LMzGd3Ob0pk0kVHvpjKq509sLUAXoW6k2pHSne5EU3YRs=
=2Up4
-----END PGP SIGNATURE-----
Merge tag 'wireless-2026-09-30' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless
Johannes Berg says:
====================
Still more fixes coming in, notably:
- ath11k: avoid running out of stations on HW restart
- mac80211:
- drop too large fragmented MPDUs
- mesh path handling fixes
- validation improvements
- reject CSA with bad 320 MHz bandwidth
- cfg80211: fix RTS for single radio devices
* tag 'wireless-2026-09-30' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: (27 commits)
wifi: mac80211: fix slab-out-of-bounds read in ieee80211_monitor_select_queue()
wifi: mac80211: reject invalid 320 MHz CSA bandwidth
wifi: mac80211: set info->band for 802.3 encap offload frames
wifi: mac80211: prevent AP VLAN tx from other interfaces
wifi: cfg80211: preserve hidden-group beacon IE ownership
wifi: mac80211: keep fallback association elements alive
wifi: mac80211: shut down RX BA session timer on teardown
wifi: mac80211: validate TX status rate metadata
wifi: ath9k_htc: bound TX aggregation to MAX_TX_BUF_SIZE
wifi: ath9k: reject short WMI command responses
wifi: ath9k: Clean up device initialisation guards
wifi: ath11k: reset ar->num_stations on hardware start
wifi: cfg80211: fix RTS threshold setting for single-radio PHY
wifi: mac80211: handle empty FILS association request payload
wifi: mac80211: minstrel_ht: validate fixed rate index
wifi: p54: validate firmware record lengths
wifi: mac80211: fix mesh fast xmit path deletion UAF
wifi: mac80211: drop oversized fragments to avoid extra_len overflow
wifi: wlcore: Fix runtime PM leak in wlcore_remove()
wifi: mac80211: drain PS delivery work during station teardown
...
====================
Link: https://patch.msgid.link/20260930124440.224799-3-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
||
Harshit Mogalapalli
|
99b43ede9e |
net: microchip: vcap: stop scanning after deleting key field
The only call outside the KUnit tests is in
sparx5_tc_add_rule_copy(), which passes a fixed key list with no
duplicate entries. Therefore, the potential double-free is not
currently reachable in tree.
However, vcap_filter_rule_keys() is exported and does not require its
key list entries to be unique. If a future or external caller supplies
the same key at another position that the inner loop visits, it calls
list_del() and kfree() a second time on the freed field, leading to a
potential double-free.
Break the inner loop after removing a matching field. The outer safe
list traversal continues to process the remaining rule fields.
Fixes:
|
||
David S. Miller
|
2e7ea988a0 |
Merge branch 'tcp-old-acks'
tcp: correct timestamp echo for accepted old ACKs Linux can acknowledge newly received data while echoing an outdated TCP timestamp. This happens when a reordered packet fills a receive gap but carries an older acknowledgment for traffic in the other direction. If the sender uses this echo to measure round-trip time after a long idle period, the stale timestamp can inflate its estimate and slow its sending. Changes in v2, following Eric Dumazet's review: - Remove the redundant SYN_RECV condition and unused flag accumulation. - Replace the log-parsing wrapper with a plain packetdrill test that checks the timestamp echo directly, using the existing selftest runner. - Rebase on net |
||
Jeff Jo
|
81fe707ae5 |
selftests: net: check timestamp echo after an old ACK
Add a regression test for a gap-filling packet whose acknowledgment has
become old. Linux first sends data to the peer. Deliver two peer data
packets out of order: the later packet acknowledges Linux's data, while
the delayed packet still carries the earlier acknowledgment.
Require the ACK that closes the receive gap to echo the delayed packet's
timestamp, 301000. Without the fix, Linux accepts the data but still echoes
the previously saved timestamp, 1000. Also check that the application can
read all 34 bytes.
Use a large jump in peer timestamps to represent the idle interval, with
no real wait, loss or retransmission. The test directly checks the outgoing
timestamp echo. It requires packetdrill's merged TSecr verification fix
(linked below); older tools incorrectly pass on an unfixed kernel.
Use the existing packetdrill selftest runner for IPv4, IPv6 and
IPv4-mapped IPv6.
Link:
|
||
|
Jeff Jo
|
1b92780ae4 |
tcp: refresh TS.Recent for accepted old ACKs
A TCP packet can carry new data while acknowledging traffic in the
opposite direction. With overlapping traffic in both directions, a
delayed packet's acknowledgment can be older than one Linux has already
accepted, even when that packet fills a gap in the received data.
Linux accepts the data, but tcp_ack() takes the old_ack path and skips
updating TS.Recent, the timestamp saved for outgoing acknowledgments.
The reply therefore echoes an older timestamp. If the sender uses this
echo to measure round-trip time after a long idle period, its estimate
includes the idle time and can reduce its sending rate.
Update TS.Recent in old_ack using tcp_replace_ts_recent(), before SACK
processing can trigger a transmission. This reuses the existing timestamp
and sequence checks, including PAWS protection against old duplicate
packets. ACK validation already rejects old ACKs in SYN_RECV before this
path, so no additional state check is needed.
Echoing the timestamp of the packet that fills the receive gap follows
RFC 7323 section 4.3. In a socket reproduction with 300 seconds idle,
controlled reordering and retransmission to exercise timestamp-based RTT
sampling, the sender's smoothed round-trip time was 37.5 seconds without
the fix and 15.5 ms with it.
Fixes:
|
||
Quentin Freimanis
|
0d2c49915b |
net: sparx5: skip ptp deinit if init was skipped
sparx5_ptp_init() returns early on the base lan969x variants
because they do not have the SPX5_FEATURE_PTP flag. It also returns early
when no "ptp" interrupt is described. Unbinding the driver then causes a
NULL pointer dereference when cleaning up uninitialized tx_skbs queues:
Unable to handle kernel NULL pointer dereference at virtual address
0000000000000008
Call trace:
skb_queue_purge_reason+0x68/0x120 (P)
sparx5_ptp_deinit+0x64/0xc0
mchp_sparx5_remove+0x38/0x70
platform_remove+0x20/0x30
device_remove+0x4c/0x80
Before per-port tx_skbs were added, a NULL dereference would have happened
when calling ptp_clock_unregister() on the never-registered PTP clocks.
Fix by returning early in sparx5_ptp_deinit() if PTP is not used.
Fixes:
|
||
Yongzhao Chen
|
20f3599d85 |
net: phy: qcom: at803x: Fix IPQ5018 short-cable DAC values
When "qcom,dac-preset-short-cable" is set, ipq5018_config_init()
programs the MDAC (MMD1 0x8100) and EDAC (debug 0x4380) fields. Both
fields occupy bits 15:8 (IPQ5018_PHY_DAC_MASK), but the value 0x10 is
passed unshifted as the set argument of phy_modify_mmd() and
at803x_debug_reg_mask(). Neither helper shifts or masks that argument,
so both fields are cleared to 0x00 instead of being set to 0x10, and
bit 4 of the low byte, which is outside the field, is set.
Use FIELD_PREP() to place the value in the field. This matches the
vendor SDK, which clears bits 15:8 and ORs in the value shifted left
by 8.
On a Redmi AX5400 board, where the IPQ5018 internal PHY connects to a
QCA8337 switch PHY without a cable, MDAC and EDAC read 0x6868 and
0x7800 before the write. With this change they read back 0x1068 and
0x1000, with the low byte preserved. Without it, the same writes would
leave 0x0078 and 0x0010.
No in-tree DTS sets this property yet, but it is documented in
qca,ar803x.yaml and used by several IPQ5018 boards in OpenWrt.
Fixes:
|
||
Sandeep Haemoon
|
6f0c2c4f5e |
net: ethernet: mtk_eth_soc: allocate dummy netdev sooner
The RX rings and the shared NAPI are carried by an internal "dummy" netdev
(eth->dummy_dev). mtk_probe() creates that dummy device, and adds the
shared tx/rx NAPI to it, only after the MAC netdevs have been registered.
That order has been there since the MT7623 support was added and leaves a
window in which the netdevs are visible to the network core before the
shared NAPI and the dummy device exist.
If anything brings the first netdev up during that window (e.g. netifd
opening the WAN link the instant the interface is registered), the
first-open path runs without them. On NETSYS v2 and later SoCs
mtk_rx_alloc() -> __xdp_rxq_info_reg() then dereferences eth->dummy_dev ==
NULL:
WARNING: CPU: ... Missing net_device from driver
in net/core/xdp.c and mtk_open() fails with -ENODEV. On NETSYS v1 SoCs
(MT7621/MT7622/MT7623/MT7629) there is no page pool, so the same open
instead calls napi_enable() on a napi_struct that netif_napi_add() has not
initialised yet and dereferences a NULL napi->dev.
Allocate the dummy netdev and add the shared tx/rx NAPI to it before the
register_netdev() loop. Both the dummy-allocation failure and a
register_netdev() failure now unwind through mtk_unreg_dev(), which
unregisters the net_device notifiers and the netdevs registered so far,
stopping a concurrently-opened netdev (ndo_stop) and its NAPI before the
dummy carrier is freed.
A netdev that opened during the window can also have queued the
frame-engine reset worker (via the tx watchdog or phylink), so the probe
error path now cancels eth->pending_work before freeing the shared state,
as mtk_cleanup() already does on remove.
Fixes:
|
||
Willem de Bruijn
|
5f0764cb1c |
net: extend IPv6 exthdr detection of tunneled packets
Commit |
||
Jamal Hadi Salim
|
ea4d4b5ddd |
net: cap skb->queue_mapping when the tx queue is picked
skbedit can set skb->queue_mapping and raise the per-CPU skip_txqueue flag so __dev_queue_xmit() honours the mapping. __dev_queue_xmit() cleared the flag before sch_handle_egress() and only read it afterwards, so the flag was not confined to the xmit that set it: a nested xmit (mirred redirect or mirror, or a drop after skbedit) could set the flag and the outer xmit would consume it for an skb that never went through skbedit. A forwarded packet still carries the ingress NIC's rx_queue + 1 in skb->queue_mapping, so the outer device then indexes its tx queue state with that stale value. Taprio's child array q->qdiscs[] is sized to the device's queue count, so taprio_enqueue() indexes past its allocation and dereferences the result as a struct Qdisc *. We (ab)use the skb->nf_skip_egress which means "skip netfilter egress for this packet" to tag to "am I in tc egress?". Despite the overload I dont see it as a conflict since the marker is set only around the single sch_handle_egress() call and ingress path is guarded by tc_at_ingress. I will send a followup(net-next) patch once this hits net-next to rename the skb->nf_skip_egress bit/flag to skb->skip_egress Arm the flag only from the egress classifier that can use it: raise skip_txqueue from tcf_skbedit_act() only when it runs inside sch_handle_egress(), thanks to skb->nf_skip_egress. An egress qdisc classifier runs in q->enqueue(), after the tx queue has been picked, so a mapping it sets cannot affect the current packet; arming the flag there only pollutes it for a later xmit. Then own the flag for the xmit frame the egress hook runs in: save the incoming value and clear it just before sch_handle_egress(), and restore it after the hook - on the consumed (drop) path, or, in the same call that reads it, on the surviving path. The save and the restores stay inside the egress_needed_key static branch, so a packet pays for them only when egress hooks are active ( |
||
Nicolai Buchwitz
|
19419faf58 |
net: bcmgenet: fix NULL dereference in set_coalesce before first open
The Rx ring priv and index are only set in bcmgenet_init_rx_ring(),
which runs at open. Setting the Rx coalescing parameters on an interface
that was never opened, e.g. "ethtool -C eth0 rx-usecs 50", dereferences
a NULL ring->priv. The oops happens with RTNL held, so networking
stays stuck until a reboot:
Unable to handle kernel paging request at virtual address 0000000000002788
pc : bcmgenet_set_rx_coalesce.isra.0+0x10/0x88
lr : bcmgenet_set_coalesce+0xe8/0x180
Call trace:
bcmgenet_set_rx_coalesce.isra.0+0x10/0x88 (P)
__ethnl_set_coalesce.isra.0+0x490/0x570
ethnl_set_coalesce+0x48/0xc0
ethnl_default_set_doit+0xf4/0x230
genl_family_rcv_msg_doit+0xe8/0x160
genl_rcv_msg+0x220/0x2a0
netlink_rcv_skb+0x68/0x140
genl_rcv+0x40/0x60
netlink_unicast+0x338/0x3c0
netlink_sendmsg+0x19c/0x3f8
__sock_sendmsg+0x64/0xc0
__sys_sendto+0x124/0x198
__arm64_sys_sendto+0x30/0x48
Set priv and index at probe. Writing the registers while the interface
is down is harmless because open resets the MAC and
bcmgenet_init_rx_coalesce() reapplies the stored values.
It was observed on a Raspberry Pi CM4, but should apply to all other
genet devices.
Fixes:
|
||
Yoshihisa Yamamoto
|
8b99934374 |
net: pcs: rzn1-miic: Clear MIIC protection state before unprotect sequence
On RZ/T2H and RZ/N1D MIIC, writing 0x0000 to the MIIC protection
register clears the protection state machine.
The initial protection state cannot be assumed to be constant,
as it may be influenced by previous activity before the driver
takes ownership of the hardware.
Clear the protection state before issuing the unprotect sequence
so that register access always starts from a known state, regardless
of any previous activity.
Fixes:
|
||
|
Jakub Kicinski
|
38b7c47069 |
Merge branch 'fix-udp-splice-checksum-alignment-across-fragments'
Alireza Asgari via says: ==================== Fix UDP splice checksum alignment across fragments When skb_splice_from_iter() appends several pipe fragments, it updates skb->len only after the loop. The software-checksum helper nevertheless uses that unchanged length as the checksum position for each fragment. An odd number of bytes already appended during the call therefore gives later fragments the wrong checksum alignment. A standalone reproducer primes a UDP socket with sendto(MSG_MORE), splices distinct pipe buffers, then uncorks the datagram. The send succeeds, but the receiver drops the packet and increments its checksum-error counter. Patch 1 passes the actual cumulative offset to the checksum helper without changing the final length update or partial-progress handling. Patch 2 adds a loopback selftest covering IPv4, IPv6, IPv4-mapped destinations, connected and unconnected sockets, prefixes and fragment boundaries. ==================== Link: https://patch.msgid.link/20260924-fix-udp-splice-checksum-v1-0-fe61d65447a8@asgari.net Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
Alireza Asgari
|
1221246d3b |
selftests: net: cover UDP splice checksum fragment alignment
Exercise software UDP checksums when splice() transfers multiple pipe fragments into a corked datagram. Use separate source pipes so short writes cannot merge, and use odd fragment lengths to expose checksum-position errors between fragments. Cover IPv4, IPv6 and IPv4-mapped destinations, connected and unconnected sockets, resident prefixes, even and odd fragment lengths, and a fragment starting near a page boundary. Ordinary sends provide a control. Check the complete payload and reject extra datagrams after a successful send. Keep receive waits bounded and skip unavailable address families or pipe capacities. The test uses only loopback sockets with ephemeral ports and has no dependency on the application that exposed the regression. Signed-off-by: Alireza Asgari <alireza@asgari.net> Link: https://patch.msgid.link/20260924-fix-udp-splice-checksum-v1-2-fe61d65447a8@asgari.net Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Alireza Asgari
|
febec6a707 |
net: fix checksum offsets in skb_splice_from_iter()
skb_splice_from_iter() appends multiple page fragments before updating
skb->len. However, skb_splice_csum_page() uses that unchanged length as the
offset for every fragment checksum. If bytes already appended during the
call have an odd total length, a later fragment's checksum is combined
with the wrong parity.
For example, prime a UDP socket with sendto(MSG_MORE) and splice two
distinct pipe buffers containing "abc" and "DEFGH". Uncorking reports
success, but the receiver discards the packet for a bad checksum.
This also affects IPv6 and fragments beginning near a page boundary.
Pass the initial skb length plus the bytes already spliced to the checksum
helper. Keep the existing final length update and partial-progress error
handling unchanged. CHECKSUM_PARTIAL does not use this helper and remains
unaffected.
Fixes:
|
||
Ilkka Lappeteläinen
|
2cf81fc950 |
net/packet: prevent TX_RING byte count overflow
tpacket_snd() drains every SEND_REQUEST frame in a TX ring and adds
each valid packet length to the signed int len_sum. Userspace can
recycle completed frames concurrently, so a single blocking send call
is not bounded by the ring size.
After enough successful transmissions len_sum wraps into the negative
range. In particular, 65536 65535-byte frames followed by a 65007-byte
frame produce 0xfffffdef, or -EIOCBQUEUED. sock_sendmsg_nosec() treats
that as an impossible return and triggers a BUG. On systems configured
to panic on oops, a CAP_NET_RAW holder can panic the host kernel.
Stop before the next frame would make the byte count exceed INT_MAX.
The positive short count leaves that frame pending for a later send
call.
A two-thread TPACKET_V2 reproducer triggered the BUG on an arm64 build
of Linux 7.3-rc4. With this change, the same reproducer returned the
expected positive short count without an oops.
Fixes:
|
||
|
Jamal Hadi Salim
|
54518e0e82 |
net/sched: sch_codel: match the no-drop threshold to the packet size
commit |
||
|
Jamal Hadi Salim
|
d031465acc |
net/sched: fq_codel: match the no-drop threshold to the packet size
commit |
||
Sagar Taunk
|
0923198be4 |
rust: net: netlink: validate attribute length before casting to c_int
`put()` trusted an unchecked `as` cast from `usize` to `c_int`.
When the length exceeds `i32::MAX` that cast wraps around to a
negative value.
This ultimately resulted in a kernel panic when the reinterpreted
value via `__nla_reserve()` and `skb_put()` became enormous.
Validate payload and header both fit together in a `u16`, rejecting
any payload that wouldn't leave room for `NLA_HDRLEN`.
Fixes:
|
||
Hannu Varjoranta
|
f8932b2c0c |
gve: DQO: accept TSO packets with non-protocol gso_type bits
Since commit |
||
Zihan Xi
|
006c8b834a |
net: gso: limit recursive IP-in-IP segmentation
IP-in-IP GSO can re-enter inet_gso_segment() or ipv6_gso_segment()
for each nested IP header. encap_level tracks header bytes, not callback
depth, so a deep chain can exhaust the kernel stack. Making
inet_gso_segment() stackable introduced unbounded IPv4 nesting; IPIP
GSO/TSO later made the path reachable. The IPv6 stackable path was
introduced separately and uses the same guard.
Count IPv4 and IPv6 GSO handler entries in skb_gso_cb, initialized once
per top-level GSO operation and preserved across GRE/UDP context changes.
Use the existing IP_TUNNEL_RECURSION_LIMIT for both handlers. The first
five entries pass, and the sixth returns -EINVAL before dispatching
another GSO callback.
Fixes:
|
||
Xuanqiang Luo
|
0f17d2e3dd |
pfcp: fix socket lifetime on netdevice registration failure
pfcp_newlink() creates the UDP socket before register_netdevice().
If registration fails after pfcp_dev_init() succeeds, the core calls
pfcp_dev_uninit(), which releases the socket and clears pfcp->sk.
The newlink error path then releases it again, causing a NULL pointer
dereference. This was observed with failslab fault injection:
FAULT_INJECTION: forcing a failure.
kobject: kobject_add_internal failed for pfcp0 (error: -12 parent: net)
BUG: KASAN: null-ptr-deref in udp_tunnel_sock_release+0x1c/0x50
Read of size 8 at addr 0000000000000120 by task ip/1037
Call trace:
show_stack+0x18/0x24 (C)
dump_stack_lvl+0x78/0x90
print_report+0x468/0x5cc
kasan_report+0xa4/0xf0
__asan_load8+0x7c/0xd0
udp_tunnel_sock_release+0x1c/0x50
pfcp_newlink+0x128/0x184
rtnl_newlink+0x848/0xe44
rtnetlink_rcv_msg+0x468/0x514
netlink_rcv_skb+0xc0/0x1f0
rtnetlink_rcv+0x18/0x24
netlink_unicast+0x4b8/0x558
netlink_sendmsg+0x2b8/0x584
...
Return from pfcp_del_sock() if pfcp->sk is NULL.
Fixes:
|
||
Eric Dumazet
|
37e02c42a0 |
net: restrict SO_RESERVE_MEM to TCP sockets and cap max value
Commit |
||
|
Nicolai Buchwitz
|
036778a4fa |
net: ethtool: let tsconfig reach a PHY-only timestamp provider
TSCONFIG_GET and TSCONFIG_SET reject a device that implements neither
hwtstamp NDO, even when its PHY can serve the request. The ioctls they
meant to replace handle it, so the two interfaces disagree on the same
hardware and user space has to pick one.
Accept the default timestamping PHY and an already installed provider on
both sides. On the set side the test moves into ethnl_set_tsconfig() as
the validate callback runs without rtnl. On the get side it stays ahead
of ethnl_ops_begin(), so a device that can serve nothing keeps failing
with EOPNOTSUPP and a dump still skips it rather than stopping there.
A netdev provider needs ndo_hwtstamp_set to be programmed at all, so
don't pick that source without it, and test for ndo_hwtstamp_get before
calling it.
Fixes:
|
||
Andrea Mayer
|
8ae3f4067b |
seg6: ensure packet data is writable before modifying SRH and IPv6 DA
advance_nextseg() modifies the SRH Segments Left field and the IPv6
destination address without ensuring the packet data is writable.
seg6_next_csid_advance_arg() has the same problem when it advances the
NEXT-C-SID argument in the destination address.
The skb may be cloned, for example by an AF_PACKET socket receiving on
the ingress device. advance_nextseg() and seg6_next_csid_advance_arg()
then write into the packet data shared with the clone. A read from that
socket can return the modified packet instead of the received one. The
simplified path below shows this for advance_nextseg():
__netif_receive_skb_one_core
__netif_receive_skb_core
deliver_skb [orig: users=2, cloned=0]
packet_rcv
skb_clone clone queued to the AF_PACKET socket
consume_skb(orig) [orig: users=1, cloned=1]
ipv6_rcv
ip6_rcv_core skb_share_check: no-op [orig: users=1]
[...]
input_action_end_core
advance_nextseg writes into the data shared with the clone
Call skb_ensure_writable() in advance_nextseg() and in
seg6_next_csid_advance_arg() before they modify the packet data.
skb_ensure_writable() may reallocate skb->head, which invalidates the
pointers into the packet data taken before the call.
advance_nextseg() now returns a valid SRH pointer, or NULL if
skb_ensure_writable() fails.
seg6_next_csid_advance_arg() takes the pointer to the destination
address from the skb after skb_ensure_writable().
On failure, the callers drop the packet with SKB_DROP_REASON_NOMEM.
Fixes:
|
||
Lorenzo Bianconi
|
8809572851 |
net: stmmac: fix rx Scatter-Gather support
When a received frame is larger than dma_buf_sz, the DMA scatters it
across multiple RX descriptors (rx Scatter-Gather). The secondary RX
buffer (sec_page) was only allocated and programmed when split-header
(SPH) was active, so for regular frames buffer2 was neither allocated
nor backed by a valid mapping. As soon as an incoming frame overflowed
buffer1, the DMA wrote the overflow into the unmapped secondary-buffer
address, triggering an SMMU translation fault on IOMMU-based platforms:
arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x00000000, fsynr=0x7f0011, cbfrsynra=0x1c90, cb=11
arm-smmu 15000000.iommu: FSR = 00000402 [Format=2 TF], SID=0x1c90
arm-smmu 15000000.iommu: FSYNR0 = 007f0011 [S1CBNDX=127 WNR PLVL=1]
Enable scatter-gather for non-SPH frames on cores that can program an
independent secondary RX buffer (GMAC4/XGMAC): allocate and mark buffer2
as valid in stmmac_init_rx_buffers() and stmmac_rx_refill(), and account
for it in the buffer length computation. Legacy cores have no set_sec_addr
op, so they keep buffer2 disabled.
Since buffer2 is handed to the DMA at page offset 0, the page pool sync
window is widened to cover both buffers in every mode: offset is set to 0
and max_len to dma_buf_sz + stmmac_rx_offset().
The FCS can straddle the buffer1/buffer2 boundary and a descriptor
boundary, so it is now stripped from the tail of the assembled frame with
pskb_trim() instead of from a single buffer, avoiding an unsigned underflow
for frames that overflow a buffer by 1..3 bytes. For single-buffer frames
the XDP program must not see the FCS, so it is removed from the XDP buffer
before the program runs.
Native XDP currently only supports single-buffer (linear) frames. An
oversized frame accepted by the MAC (jumbo enabled) is received via
buffer2; the XDP program only sees buffer1, so on a TX/REDIRECT verdict
the frame is forwarded truncated. XDP multi-buffer support to handle
this case is planned as a follow-up.
AF_XDP zero-copy RX is not covered by this change: a ZC queue still
programs buffer2 at DMA address 0 (and XGMAC has no buffer2-valid bit),
so an oversized frame overflowing buffer1 can still trigger the same
SMMU translation fault. Handling is planned as a follow-up.
Fixes:
|
||
Mina Almasry
|
bdea498018 |
net: page_pool: fix use-after-free in page_pool_recycle_ring_bulk()
With CONFIG_PAGE_POOL_STATS=y, page_pool_recycle_ring_bulk() updates the recycle stats after dropping the producer lock. If it just recycled the last inflight netmems of a pool being destroyed, page_pool_release() can pass its producer-lock barrier and free the pool before recycle_stat_add() runs. Commit |
||
Jérémy Jean
|
512ccd3d0e |
tipc: prevent GCM nonce reuse on peer key changes
TIPC can encrypt traffic between nodes using a different transmit key
for each node. In this mode, the AES-GCM nonce for a packet sent to a
known peer consists of a 32-bit prefix (a per-key salt XOR the peer's
address) followed by a 64-bit counter. That counter is stored in the
peer's RX crypto object. When the peer reports a change in which key
it uses to receive packets, TIPC resets this counter. The sender can
still be using the same TX key and salt, so subsequent packets reuse
earlier nonces. This nonce reuse breaks confidentiality and exposes
GCM's authentication key. This makes forgeries trivial: an attacker
can exploit CTR malleability to alter captured ciphertexts and use the
recovered authentication key to compute a valid tag for the modified
ciphertext, under the same key and nonce.
Use the TX key's existing aead->seqno counter instead. All encryptions
using that key object share the same atomic counter, so concurrent
encryptions get distinct nonce counter values. The counter survives
key activation and peer reconnection, and peer key-status reports
cannot reset it. This prevents those transitions from causing nonce
reuse while the same TX key remains installed.
The nonce format is unchanged, and receivers do not require consecutive
counter values, so sharing the counter across peers remains compatible
with existing receivers. A pre-existing check still invokes key
revocation in the unlikely event that the counter wraps to zero.
Fixes:
|
||
|
Jakub Kicinski
|
fb9b529be0 |
Merge branch 'octeontx2-misc-fixes-for-rvu-drivers'
Subrat Pandey says: ==================== octeontx2: Misc fixes for RVU drivers A few independent fixes for the Marvell OcteonTX2 (RVU AF/PF) drivers: - Fix aura/CQ BPID assignment under CONFIG_DCB, which assumed queue_to_pfc_map was always allocated (not true for SDP VFs). - Fix the SC resource cleanup loop that iterated over secy.max instead of sc.max. ==================== Link: https://patch.msgid.link/20260922102149.2078168-1-subratp@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
Baha Mesleh
|
cdef07f300 |
octeontx2-af: mcs: Fix SC resource cleanup loop
The SC resource cleanup and statistics loops were incorrectly
iterating over secy.max instead of sc.max, so the highest SC id
could be left allocated across teardown or FLR. Use sc.max as
the loop bound.
Fixes:
|
||
Geetha sowjanya
|
0569945639 |
octeontx2-pf: Fix aura BPID assignment when CONFIG_DCB is enabled
Previously, BPID assignment under CONFIG_DCB assumed
`queue_to_pfc_map` was always initialized. For SDP VFs this leads to
invalid memory access as it was not initialized.
This patch adds a NULL check for `queue_to_pfc_map` before
dereferencing it. Also, simplifies the logic by always assigning a
default BPID first, then conditionally overriding it if CONFIG_DCB is
enabled and the map exists.
Fixes:
|
||
|
Jakub Kicinski
|
382cf97689 |
bluetooth pull request for net:
Core: - hci_core: Serialize ACL scheduling with channel deletion - hci_core: Serialize SCO and ISO scheduling with teardown - hci_core: Serialize fragmented ISO packet queueing - hci_core: Fix inquiry cache timestamps on 64-bit systems - hci_core: free the HCI ID if naming fails - hci_conn: Lock parent access during enhanced SCO setup - hci_sync: Fix inquiry cache use-after-free - hci_sync: don't drain cmd_sync backlog on unregister - RFCOMM: Fix initial port reference race - SMP: Serialize SMP remote OOB data access Drivers: - btintel: fix buffer over-read in btintel_hw_error() - btintel: validate DDC record lengths - btintel_pcie: fix plen overflow in btintel_pcie_recv_frame() - btintel_pcie: reject oversized TX packets in send_frame() -----BEGIN PGP SIGNATURE----- iQJNBAABCgA3FiEE7E6oRXp8w05ovYr/9JCA4xAyCykFAmq6h1YZHGx1aXoudm9u LmRlbnR6QGludGVsLmNvbQAKCRD0kIDjEDILKZEND/42wPb5lDOUU7VgMG6THiU/ G6r4LMsjHkpGfkZox4OIAzXEbWvby9hZgilO2M8uXvHUqHrZ9IcfsA8rXgK+Bort EcoQGzq0X6RSysoJ3XOXj1QW6jXR8XqN9SongdaCR6I6xlGtXkMkbD8+APSII3oI xo5oU3MrsDPqIL+ow6GmYtAA1aGoD95QZL5S1tBaYwUB8mThDJQchE0DTzNk2jZ0 gjgvfNBXkFjeIzrlVw/zhs7hJVebCgAZvrSlriCK1rvgU/3D2UKYYQPOu8ztjM18 ITtKniIddPmALaXmJHiR/zt6nruw3/CUEkIdjd3a/XiP1n6xGCsGd9tte98Qr/8X Mr9ID7i7Old2WZc5nx+pOf+Bliy2omluzIsiqGO3KaoSCht2wZOwjKMEaIS1cS/m YdMTZ+nQshHRpO0w8nVObIC1lGLYBPjnwVv5IFXWiepT90vBij7pgDZHUgx2HO2n a7ejJcgDyHkGWI7loXAs1qZPNjcTRFO9IQ84wpARe94Hc7NaRcGBUCz3b3HH/5+H TuihQbVGVkV96jzeF7cIDifcZRky8yoUW/AoEfAuZzkQjonn9NBZ063ulUdZhEFc W8Psa1e/zrYqKgH7U9l4gfDn5yu1mEIFBKgAqZ2e0CbsJAklt3yY08xj0KI1kgaB FMRl+SFuGtDThQUk1ifFng== =ToWl -----END PGP SIGNATURE----- Merge tag 'for-net-2026-09-28' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: Core: - hci_core: Serialize ACL scheduling with channel deletion - hci_core: Serialize SCO and ISO scheduling with teardown - hci_core: Serialize fragmented ISO packet queueing - hci_core: Fix inquiry cache timestamps on 64-bit systems - hci_core: free the HCI ID if naming fails - hci_conn: Lock parent access during enhanced SCO setup - hci_sync: Fix inquiry cache use-after-free - hci_sync: don't drain cmd_sync backlog on unregister - RFCOMM: Fix initial port reference race - SMP: Serialize SMP remote OOB data access Drivers: - btintel: fix buffer over-read in btintel_hw_error() - btintel: validate DDC record lengths - btintel_pcie: fix plen overflow in btintel_pcie_recv_frame() - btintel_pcie: reject oversized TX packets in send_frame() * tag 'for-net-2026-09-28' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: hci_core: Serialize SCO and ISO scheduling with teardown Bluetooth: hci_core: Serialize ACL scheduling with channel deletion Bluetooth: Serialize SMP remote OOB data access Bluetooth: RFCOMM: Fix initial port reference race Bluetooth: hci_sync: Fix inquiry cache use-after-free Bluetooth: hci_sync: don't drain cmd_sync backlog on unregister Bluetooth: hci_core: Serialize fragmented ISO packet queueing Bluetooth: hci_conn: Lock parent access during enhanced SCO setup Bluetooth: btintel: validate DDC record lengths Bluetooth: hci_core: free the HCI ID if naming fails Bluetooth: hci_core: Fix inquiry cache timestamps on 64-bit systems Bluetooth: btintel_pcie: reject oversized TX packets in send_frame() Bluetooth: btintel_pcie: fix plen overflow in btintel_pcie_recv_frame() Bluetooth: btintel: fix buffer over-read in btintel_hw_error() ==================== Link: https://patch.msgid.link/20260928152919.942973-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
Anirudh Virdi
|
04c824940d |
net/mlx5: Fix slab-out-of-bounds when handling team device events
The mlx5_handle_changeupper_event() and mlx5_handle_changeinfodata_event()
functions check for LAG masters (which includes both bonding and team
devices) but only call bonding-specific APIs. When processing team device
events, calling bond_slave_get_rcu() and bond_is_slave_inactive() on
team_port structures causes KASAN to detect an out-of-bounds memory access
since team_port is smaller than bond slave.
Fix this by wrapping the bond-specific API calls with a check for bonding
devices. This allows the function to still process LAG events for both
bonding and teams but only calls bond-specific functions when dealing with
actual bonding devices.
For mlx5_handle_changeinfodata_event(), keep the explicit bond check as
mlx5 doesn't handle state information for team ports anyway.
Tested with Mellanox ConnectX-5 on Linux 7.2.0-rc6:
- Bonding: PASS (no regressions)
- Team device: PASS (no KASAN errors)
Fixes:
|
||
|
Jakub Kicinski
|
0456d187c0 |
Merge branch 'net-systemport-collection-of-fixes'
Florian Fainelli says: ==================== net: systemport: Collection of fixes ==================== Link: https://patch.msgid.link/20260922232440.598918-1-florian.fainelli@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
Florian Fainelli
|
242935adfe |
net: systemport: Fix RUNT MIB counter register offset calculation
In UniMAC hardware, there is a 0xC byte gap between the RX MIB counters
and the TX MIB counters, and a second 0xC byte gap between the TX MIB
counters and the RX RUNT MIB counters.
In bcm_sysport_update_mib_counters(), 'offset' was only set to
UMAC_MIB_STAT_OFFSET (0xC) for all non-RX counters, omitting the second
0xC gap for BCM_SYSPORT_STAT_RUNT counters. As a result, all 4 RUNT MIB
counters were read from unmapped gap register space.
Fix this by setting offset to 2 * UMAC_MIB_STAT_OFFSET (0x18) when
reading BCM_SYSPORT_STAT_RUNT counters.
Fixes:
|
||
|
Florian Fainelli
|
eb7b84af0e |
net: systemport: Fix buffer overflow in bcm_sysport_get_stats()
When running on SYSTEMPORT Lite, certain statistics are unsupported and
skipped during bcm_sysport_get_stats(). The variable 'j' tracks the
compacted index into the destination data buffer, whereas 'i' iterates
over all elements in bcm_sysport_gstrings_stats.
Because the buffer allocated by ethtool is sized only according to
bcm_sysport_get_sset_count(), storing values at data[i] instead of
data[j] writes past the allocated array bounds, leading to memory
corruption.
Fix this by writing to data[j] instead of data[i].
Fixes:
|
||
Christian Melendez
|
6b2462f07c |
MAINTAINERS: add missing entry for b53.rst
Documentation/networking/dsa/b53.rst is not covered by the BROADCOM B53/SF2 ETHERNET SWITCH DRIVER entry. Signed-off-by: Christian Melendez <chrismelnu@gmail.com> Link: https://patch.msgid.link/20260922211439.369917-2-chrismelnu@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
Chengfeng Ye
|
848a7a91c7 |
Bluetooth: hci_core: Serialize SCO and ISO scheduling with teardown
hci_low_sent() selects a connection under RCU but drops the read lock
before calculating its quota and returning it to the scheduler. The
connection is then used without lifetime protection by hci_sched_iso()
and hci_sched_sco().
After the TX worker drops the RCU read lock, hci_abort_conn_sync() on
hdev->req_workqueue can remove the connection from the hash, complete
synchronize_rcu(), purge its queues and release it. The TX worker on
hdev->workqueue can then access the freed connection in hci_quote_sent()
or while dequeuing packets and updating conn->sent.
KASAN reported:
BUG: KASAN: slab-use-after-free in hci_low_sent+0x730/0x840
Workqueue: hci0 hci_tx_work
Call Trace:
hci_low_sent+0x730/0x840
hci_sched_iso+0x25e/0x4d0
hci_tx_work+0x239/0xcb0
Allocated by task 93:
__hci_conn_add+0x16f/0x1b40
hci_bind_bis+0x782/0x17b0
hci_connect_bis+0xa0/0x510
iso_sock_connect+0x589/0x1050
Freed by task 88:
kfree+0x131/0x3c0
device_release+0xc8/0x240
kobject_put+0x14d/0x280
hci_conn_del+0x55a/0xe80
hci_disconnect_sync+0x156/0x180
hci_abort_conn_sync+0x3e7/0x940
hci_cmd_sync_work+0x13c/0x290
Hold hci_dev_lock() across connection selection and transmission in both
SCO and ISO scheduling, serializing them with connection teardown. This
also prevents queuing completion timestamps after the connection queues
have been purged. Extending RCU across transmission would be unsafe
because the transmit path can sleep. Keep the ISO timeout check outside
the mutex since hci_link_tx_to() takes it itself.
The preceding channel fix already holds this mutex in the ACL and LE
schedulers, which call the SCO scheduler between packets. Move the SCO
body to __hci_sched_sco(), assert that its caller holds the mutex, and
use it directly from these locked paths. Keep a locking hci_sched_sco()
wrapper for the direct calls from hci_tx_work(). This avoids recursively
acquiring the device mutex while preserving the scheduling order.
Remove the obsolete claim that connection removal disables TX.
Fixes:
|
||
|
Chengfeng Ye
|
f4845ab191 |
Bluetooth: hci_core: Serialize ACL scheduling with channel deletion
hci_chan_sent() selects a channel under RCU but drops the read lock before
accessing chan->conn and returning the channel. The ACL and LE schedulers
then use its packet queue and update its transmit counters without any
protection against channel deletion.
After TX selects a channel and releases RCU, a disconnect command timeout
on the separate request workqueue can run hci_conn_failed() and
l2cap_conn_del(). hci_chan_del() can then unlink the channel, complete
synchronize_rcu(), purge its queue and free it before TX resumes. This
causes use-after-free both in hci_chan_sent() and in its callers.
KASAN reported:
BUG: KASAN: slab-use-after-free in hci_chan_sent+0x892/0x9b0
Workqueue: hci0 hci_tx_work
Call Trace:
hci_chan_sent+0x892/0x9b0
hci_tx_work+0x5e6/0xb70
Allocated by task 91:
hci_chan_create+0xe3/0x350
l2cap_conn_add.part.0+0x12/0xa30
l2cap_chan_connect+0x110d/0x1b60
l2cap_sock_connect+0x310/0x530
Freed by task 99:
hci_chan_del+0x11f/0x170
l2cap_conn_del+0x4f1/0x800
l2cap_connect_cfm+0x88c/0xd30
hci_conn_failed+0x150/0x250
hci_abort_conn_sync+0x3e3/0x800
hci_cmd_sync_run+0x7e/0xc0
hci_abort_conn+0x105/0x1f0
disconnect_sync+0x157/0x290
hci_cmd_sync_work+0x13c/0x290
Hold the existing device mutex across channel selection and transmission
in both schedulers to serialize them with channel teardown. Keep timeout
handling outside the critical sections because hci_link_tx_to() acquires
the same mutex. This also permits the transmit path to sleep, unlike
extending the RCU read-side critical section across packet submission.
Fixes:
|
||
|
Chengfeng Ye
|
81a2345f19 |
Bluetooth: Serialize SMP remote OOB data access
build_pairing_cmd() looks up remote OOB data and copies its contents
without holding hdev->lock, which serializes the list's writers. After
SMP finds an entry, a concurrent management Remove Remote OOB Data
command can unlink and free it before SMP reads its present flag or
copies its random and confirmation values. Removal can also invalidate
an entry while the lookup is still traversing the list.
KASAN reported:
BUG: KASAN: slab-use-after-free in build_pairing_cmd+0x948/0x9b0
Call Trace:
build_pairing_cmd+0x948/0x9b0
smp_recv_cb+0x459f/0x8110
l2cap_recv_frame+0xf14/0x9190
l2cap_recv_acldata+0xa64/0xd40
hci_rx_work+0x4ca/0x730
Allocated by task 87:
hci_add_remote_oob_data+0x11d/0x530
add_remote_oob_data+0x282/0x400
hci_sock_sendmsg+0x1033/0x1ea0
Freed by task 93:
hci_remote_oob_data_clear+0x108/0x1c0
remove_remote_oob_data+0x198/0x220
hci_sock_sendmsg+0x1033/0x1ea0
Taking hdev->lock in build_pairing_cmd() would recurse for callers that
already hold it and invert the device-to-L2CAP lock order on the receive
path. Add a per-device remote_oob_lock instead, held across the SMP
lookup and copies and by the add, remove and clear helpers. Cover
initialization and in-place updates as well, so SMP cannot read partially
initialized or updated OOB values. Release the mutex on allocation
failure, preserving the existing error return.
The new critical sections acquire no device, connection or channel locks.
Writers retain their existing hdev->lock protection, which continues to
serialize the other readers without changing their locking or behavior.
Link: https://lore.kernel.org/r/00660cd3-7d71-13a4-f617-229e6defb701@gmail.com
Fixes:
|
||
|
Chengfeng Ye
|
2d696c1ed3 |
Bluetooth: RFCOMM: Fix initial port reference race
For RFCOMM_RELEASE_ONHUP devices, rfcomm_tty_install() and
__rfcomm_release_dev() both use RFCOMM_TTY_OWNED to decide who drops the
initial tty_port reference. The release path tests the bit separately
from the install path setting it, so both can drop that reference.
The synchronous hangup does not prevent this race: port->tty is not
assigned until tty_port_open(), after installation. The following
interleaving is possible:
1. Install and release each obtain a reference with rfcomm_dev_get().
2. Release observes RFCOMM_TTY_OWNED clear.
3. Install sets RFCOMM_TTY_OWNED and drops the initial reference.
4. Release drops the same initial reference again.
5. TTY cleanup drops its reference and frees the device.
6. Release performs its final tty_port_put() on the freed port.
KASAN reported:
BUG: KASAN: slab-use-after-free in tty_port_put+0x22/0x190
Write of size 4 at addr ffff8881001d3d5c by task poc/92
Call Trace:
tty_port_put+0x22/0x190
rfcomm_dev_ioctl+0x1d4/0x1930
sock_do_ioctl+0x110/0x260
sock_ioctl+0x380/0x590
__x64_sys_ioctl+0x134/0x1c0
Allocated by task 88:
rfcomm_dev_ioctl+0x8f6/0x1930
sock_do_ioctl+0x110/0x260
sock_ioctl+0x380/0x590
__x64_sys_ioctl+0x134/0x1c0
Freed by task 65:
kfree+0x131/0x3c0
rfcomm_dev_destruct+0x23b/0x2f0
release_one_tty+0xc1/0x370
process_one_work+0x661/0x1090
Use test_and_set_bit() in both paths so that only the caller that changes
RFCOMM_TTY_OWNED from clear to set drops the initial reference. Each path
keeps its own lookup reference until release or TTY cleanup, preserving
the existing callback ordering and error handling.
Fixes:
|
||
|
Chengfeng Ye
|
8ed67535fd |
Bluetooth: hci_sync: Fix inquiry cache use-after-free
The sync command worker holds hdev->req_lock, but inquiry-cache updates and flushes use hdev->lock. Both hci_acl_create_conn_sync() and hci_stop_discovery_sync() look up entries and read their fields without taking hdev->lock. After either lookup returns, a concurrent HCIINQUIRY ioctl can acquire hdev->lock and flush the cache, freeing the entry. The worker then reads the freed entry while preparing a create-connection or remote-name-cancel command. The list traversal also races with cache updates and removal. KASAN reported these accesses: BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5f1/0x650 Workqueue: hci0 hci_cmd_sync_work Call Trace: hci_acl_create_conn_sync+0x5f1/0x650 hci_cmd_sync_work+0x13c/0x290 Allocated by task 90: hci_inquiry_cache_update+0x3e6/0x7d0 hci_inquiry_result_evt+0x3cb/0x560 Freed by task 93: hci_inquiry_cache_flush+0x111/0x2b0 hci_inquiry+0x2f2/0x780 hci_sock_ioctl+0x269/0x5f0 BUG: KASAN: slab-use-after-free in hci_stop_discovery_sync+0x3b1/0x3c0 Workqueue: hci0 hci_cmd_sync_work Call Trace: hci_stop_discovery_sync+0x3b1/0x3c0 hci_cmd_sync_work+0x173/0x300 Allocated by task 86: hci_inquiry_cache_update+0x483/0x940 hci_inquiry_result_evt+0x3cb/0x560 Freed by task 91: hci_inquiry_cache_flush+0x13e/0x2f0 hci_inquiry+0x2f2/0x780 hci_sock_ioctl+0x269/0x5f0 Hold hdev->lock across each lookup and all reads from its result. Copy the remote address before unlocking so discovery cancellation does not retain a cache entry pointer. Release the lock before sending synchronous HCI commands, since their completion handlers may need the same lock. Fixes: |
||
Nguyen Ngoc Thang
|
b1f24c1ab5 |
Bluetooth: hci_sync: don't drain cmd_sync backlog on unregister
hci_unregister_dev() disables cmd_work and cmd_timer, then calls
hci_cmd_sync_clear(), whose cancel_work_sync() waits for
hci_cmd_sync_work() to return. That worker dequeues and runs every
entry on cmd_sync_work_list. With cmd_work disabled nothing reaches
the controller, so each queued HCI command waits the full
HCI_CMD_TIMEOUT (2s).
The backlog has no bound. Userspace can keep queuing MGMT commands
such as MGMT_OP_GET_CLOCK_INFO against a controller that doesn't
answer. Closing /dev/vhci then blocks in vhci_release() for
backlog * 2s:
INFO: task syz-executor:5749 blocked for more than 143 seconds.
cancel_work_sync
hci_cmd_sync_clear
hci_unregister_dev
vhci_release
In a local reproduction the backlog held more than 5000 entries,
which comes to hours of hang.
Stop the worker from taking new entries once HCI_UNREGISTER is set,
and wake any request still waiting with -ENODEV before cancelling
the work. The entries left over are destroyed with -ECANCELED by the
existing sweep in hci_cmd_sync_clear(). They stay on the list until
the work has stopped, so hci_cmd_sync_dequeue() and friends still see
them. A callback already running may still issue another command,
which delays unregister by at most one timeout per remaining command,
not by the whole backlog.
Fixes:
|
||
|
Chengfeng Ye
|
1a572db43c |
Bluetooth: hci_core: Serialize fragmented ISO packet queueing
The fragmented path in hci_queue_iso() calls __skb_queue_tail() without
holding conn->data_q.lock. The socket lock serializes senders, but the
transmit worker can concurrently remove packets from this queue using
skb_dequeue().
After an insertion saves the old tail pointer, hci_sched_iso() can dequeue
that packet and pass it to the driver. The driver can free the packet
before the insertion resumes and writes to the old tail's next pointer,
causing a use-after-free. Concurrent updates can also corrupt the queue.
KASAN reported:
BUG: KASAN: slab-use-after-free in hci_send_iso+0xc7d/0xe10
Call Trace:
hci_send_iso+0xc7d/0xe10
iso_sock_sendmsg+0x710/0x900
__sys_sendto+0x34a/0x3a0
Allocated by task 86:
__alloc_skb+0xdd/0x820
alloc_skb_with_frags+0x7e/0x770
sock_alloc_send_pskb+0x67a/0x820
bt_skb_sendmsg.constprop.0+0xc0/0x6c0
iso_sock_sendmsg+0x44e/0x900
Freed by task 90:
kmem_cache_free+0xcb/0x3d0
vhci_read+0x33f/0x4d0
vfs_read+0x177/0xa20
Hold the queue lock across the entire fragment batch, as hci_queue_acl()
does, to serialize insertion against dequeue while preserving fragment
ordering.
Fixes:
|
||
|
Chengfeng Ye
|
024e05f73a |
Bluetooth: hci_conn: Lock parent access during enhanced SCO setup
Bluetooth: hci_conn: Lock parent access during enhanced SCO setup
hci_enhanced_setup_sync() runs on the request workqueue without the
hci_dev_lock held by its caller when setup was queued. Its CVSD
capability check and find_next_esco_param() dereference conn->parent
while the receive workqueue can unlink and release that parent.
The following interleaving can cause a use-after-free:
hci_enhanced_setup_sync() hci_disconn_complete_evt()
load conn->parent
hci_dev_lock()
hci_conn_del(ACL parent)
unlink SCO child
drop link's parent reference
clear child->parent
release ACL parent
bt_link_release()
kfree(parent)
hci_dev_unlock()
read parent->features[0][3]
The reference held for the queued SCO child does not keep its ACL parent
alive after unlinking. Commit
|
||
Cen Zhang (Microsoft)
|
6f63e919fe |
wifi: mac80211: fix slab-out-of-bounds read in ieee80211_monitor_select_queue()
ieee80211_monitor_select_queue() validates the skb length using skb->len before dereferencing pointers into skb->data to access the 802.11 header. However, skb->len includes data in both the linear head buffer and non-linear fragments/pages. When AF_PACKET sends a packet large enough to become non-linear, the 802.11 header at skb->data + len_rthdr may extend past the linear head buffer even though skb->len appears sufficient. This leads to a slab-out-of-bounds read when accessing hdr->frame_control, as the kernel reads beyond the allocated skb head buffer: BUG: KASAN: slab-out-of-bounds in ieee80211_monitor_select_queue+0x1ed/0x220 syzbot has hit the same issues. Fix this by checking skb_headlen(skb) (which gives the length of the linear data region) instead of skb->len before dereferencing skb->data pointers. This ensures the required bytes are actually present in the linear portion of the skb. Apply the same fix to ieee80211_validate_radiotap_len() which has the same class of bug: it uses skb->len to validate accesses to skb->data, and to the corresponding checks in ieee80211_monitor_start_xmit(): for drivers advertising NETIF_F_SG the skb is not linearized before ndo_start_xmit, so the 802.11 header can be read past the linear buffer there as well. Fixes: |
||
Ruide Cao
|
56e236759f |
wifi: mac80211: reject invalid 320 MHz CSA bandwidth
The HT/VHT channel definition validator can receive a 320 MHz
bandwidth indication from a received CSA frame on a non-6 GHz link.
It warns for this unsupported width but continues with an uninitialized
vht_operation.chan_width, which is then read by
ieee80211_chandef_vht_oper(). With panic_on_warn enabled, this lets a
received frame panic the kernel.
Reject the channel definition before entering the VHT operation
conversion. This preserves the existing CSA fallback while avoiding
both the warning and the uninitialized read.
Fixes:
|
||
Felix Fietkau
|
4febc02cd0 |
wifi: mac80211: set info->band for 802.3 encap offload frames
Unlike the 802.11 TX paths, ieee80211_8023_xmit() does not set
info->band from the channel context on non-MLD interfaces. It stays at
0, so ieee80211_get_tx_rates() uses the wrong band for these frames.
Set it the same way as ieee80211_build_hdr(): drop the frame if there is
no channel context, and leave the band at 0 on MLD interfaces.
Reported-by: Andrea Pesaresi <andreapesaresi82@gmail.com>
Fixes:
|
||
Qishuai Liu
|
a7bfaba482 |
ipv6: fix prefix route expiry in modify_prefix_route()
modify_prefix_route() is given the lifetime in clock_t relative to now,
but fib6_set_expires() wants an absolute jiffies value. So when a
permanent address is changed to a finite valid_lft, the prefix route
ends up already expired and GC removes it.
Steps to reproduce:
ip link add dummy9 type dummy
ip link set dummy9 up
ip -6 addr add 2001:db8:9::1/64 dev dummy9
ip -6 addr change 2001:db8:9::1/64 dev dummy9 valid_lft 3600 preferred_lft 3600
ip -6 route show dev dummy9 # expires is negative
Fixes:
|
||
|
Nicolai Buchwitz
|
0e7fe2b0ca |
net: bcmgenet: allocate RX buffers as page fragments
Since the page_pool conversion every RX buffer is a whole page and the
skb truesize is the page, although the hardware writes at most 2 KiB of
it. On 64 KiB pages a packet therefore counts 65792 bytes against the
socket buffer where it used to count 2752. As a result a UDP socket
with the default buffer starts to drop after three packets, and the RX
rings pin 16 MiB for 512 KiB of buffers.
Fix this and allocate the buffers as page fragments, so the truesize is
what a packet occupies. 4 KiB pages stay one buffer per page.
Sync each buffer in the refill path, as page_pool can only sync a whole
page on recycle. On 4 KiB pages that is twice what the hardware wrote.
Fixes:
|