mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2026-09-22 09:34:56 +02:00
ad9a7da3fa39c2d616ec0dd3cf6e30531d032fe7
1480992
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Daehyeon Ko
|
ad9a7da3fa |
vsock/vmci: validate packet source for connected sockets
vmci_transport_recv_stream_cb() looks up sockets first by the full source
and destination tuple, then by destination only in the bound table. The
fallback can select a non-listening socket without checking whether the
packet came from its stored peer.
This was reproduced with two VMCI contexts. A RST from the context not
stored in a TCP_SYN_SENT socket reset that socket after it was selected by
the destination-only lookup.
VMCI can process notification packets in bottom-half context when the
socket is not owned by user context, or defer packets to a workqueue. Use
vsock_check_source() after taking the socket lock in the bottom-half path,
and recheck after lock_sock() in the workqueue path. Listening sockets
continue to accept packets from any source.
Reply with a RST addressed from the received packet before dropping a
source that fails validation. This preserves the existing reset behavior
for bound non-listening and concurrently closed sockets without directing
the reset to a connected socket's stored peer.
Fixes:
|
||
|
Daehyeon Ko
|
dee44f41f2 |
vsock/virtio: validate packet source for connected sockets
virtio_transport_recv_pkt() looks up sockets first by the full source and
destination tuple, then by destination only in the bound table. The
fallback is needed for listening and connecting sockets, but sockets remain
in the bound table after connect(), so it can also return a non-listening
socket.
The fallback does not validate the source address. In TCP_SYN_SENT, a
RESPONSE from an unrelated source can transition the victim socket to
TCP_ESTABLISHED while its stored remote address remains unchanged.
Subsequent RW packets from that source are delivered through the same
destination-only fallback.
This was reproduced with capability-empty processes under different UIDs.
The attacker discovered the target tuple through unprivileged AF_VSOCK
sock_diag and caused the victim socket to read 16 attacker-chosen bytes;
the intended peer-side socket read 0 of those 16 bytes.
Add vsock_check_source() to validate the transport, source port and source
CID against the peer stored in a non-listening socket. The local transport
is the CID exception because its packets are generated internally with
VMADDR_CID_LOCAL as their source, including connections using CID aliases.
Use the helper after lock_sock() in the virtio receive path.
Fixes:
|
||
 Florian Schauer
|
dc0df5a0c6 |
page_pool: keep frag_offset aligned for odd-sized requests
page_pool_alloc_frag_netmem() rounds the requested fragment size with
size = ALIGN(size, dma_get_cache_alignment());
dma_get_cache_alignment() returns 1 unless the architecture defines
ARCH_DMA_MINALIGN, which DMA-coherent architectures such as x86 do not.
There the ALIGN() is a no-op and pool->frag_offset advances by the raw,
unrounded size.
A single caller asking for an odd size then leaves frag_offset misaligned
for every fragment carved out of that page afterwards. The pool is shared,
so the damage is not confined to the caller that caused it.
The per-cpu system_page_pool used by generic XDP hits this.
skb_pp_cow_data() allocates its fragments with the raw packet length:
size = min_t(u32, len, PAGE_SIZE);
truesize = size;
page = page_pool_dev_alloc(pool, &page_off, &truesize);
leaving frag_offset odd for whatever is carved out of that page next. Its
own head allocation is already aligned -- SKB_HEAD_ALIGN(size) plus the
XDP_PACKET_HEADROOM its callers pass -- so it is a later user of the shared
pool that pays: page_pool_dev_alloc_va() returns a misaligned buffer,
napi_build_skb() installs it as skb->head, and skb_shinfo(skb) ==
skb->head + skb->end is misaligned with it.
skb_shinfo()->dataref is a 4-byte atomic_t at offset 0x20, so the
atomic_inc() in __skb_clone() straddles a cache line. On x86 with split
lock detection -- fatal for kernel split locks by default -- this panics
the machine:
Oops: Split lock detected
RIP: 0010:skb_clone+0x154/0x1e0
Call Trace:
<IRQ>
raw_local_deliver+0x1ed/0x2c0
ip_protocol_deliver_rcu+0x54/0x1c0
ip_local_deliver_finish+0x85/0x100
ip_local_deliver+0x67/0x100
__netif_receive_skb_one_core+0x85/0xa0
process_backlog+0x87/0x130
Reproduced by attaching any generic-mode XDP program to loopback and
opening a RAW IPPROTO_UDP socket, which makes raw_local_deliver() clone
every locally delivered UDP packet; ordinary DNS traffic then triggers it,
roughly once per 2500 clones. Observed on 6.12.101 and 7.1.8.
Tracing page_pool_alloc_frag_netmem() over one such run shows the
amplification -- two odd-sized requests, nine misaligned offsets:
requested size & 7: 0: 17035 5: 1 7: 1
frag_offset & 7: 0: 17028 3: 1 4: 1 5: 1 6: 1 7: 5
and skb_pp_cow_data() returning heads that were aligned on entry:
head 0xffff8f4c86aeac00 -> 0xffff8f4c53a9a9c4 (&7=4)
head 0xffff8f4d6a8a42c0 -> 0xffff8f4c4f7b7a45 (&7=5)
Round the fragment size up to at least the alignment struct skb_shared_info
requires, so fragments are always suitably aligned for the objects callers
build on them. Architectures needing a larger DMA alignment keep it.
This also makes the remainder computed in page_pool_alloc_netmem(),
*size = max_size - *offset;
aligned, since max_size is a power of two -- which fixes the matching
misalignment of skb->end.
Verified with a controlled A/B under QEMU/KVM: same tree, same config,
same compiler, same rootfs and identical traffic, differing only by this
patch. A SEC("xdp.frags") XDP_PASS program on lo plus UDP datagrams
larger than max_head_size drives skb_pp_cow_data()'s fragment loop, which
passes raw packet lengths to the pool. Measured at the return of
skb_pp_cow_data():
unpatched patched
skb_pp_cow_data calls 40800 40800
misaligned skb->head 1120 0
dataref at line offset >60 80 0
The last row counts the accesses that actually fault:
skb_shinfo()->dataref sits at head+end+0x20 and is a 4-byte atomic, so
`lock incl` splits a 64-byte cache line only when that address lands at
offset 61..63. All 80 occurrences were at offset 61; the panic reported
above was at offset 62. Eliminating the misalignment removes every one
of them.
Same class of bug as commit
|
||
 Jamal Hadi Salim
|
7b120a7719 |
selftests: tc-testing: add u32 node ID pool exhaustion test
Add a tdc test case that fills the u32 node ID space with 4095 auto-generated handles, then attempts to add a 4096th. On the fixed kernel the 4096th filter is rejected with ENOSPC (exit 2). On the unfixed kernel it silently succeeds with a duplicate handle. The setup pipes the 4095 add commands directly into `tc -b -` inside a single bash -c (matching the existing test id 1234 pattern), avoiding any temp file. Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com> Link: https://patch.msgid.link/20260825081052.133898-2-jhs@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Jamal Hadi Salim
|
d7e7e98d23 |
net/sched: cls_u32: fix duplicate handle when node ID pool is exhausted
gen_new_kid() falls back to returning max (htid | 0xFFF) when both
idr_alloc_u32() ranges are full, instead of reporting an error.
u32_change() trusts that value and inserts a new knode with a handle
that is already live in the hash table, breaking handle uniqueness
within the table's node ID space.
The handle was never reserved in ht->handle_idr, so every later error
path that does idr_remove(&ht->handle_idr, handle) removes the
reservation of a different, live knode, which is then reused — one
failed add compounds into further duplicates.
The 4095 limit is per (table, bucket) — ht->handle_idr is per hash
table and the range is derived from htid (bucketid), so a table with
divisor 256 can legitimately hold 256*4095 knodes.
The sibling helper gen_new_htid() has the same silent in-band failure:
it returns 0 when the tp_c handle pool (1..0x7FF) is full, and
u32_init() publishes the root hash table with handle 0 without
checking. Two root tables with handle 0 alias in u32_lookup_ht(),
allowing cross-tcf_proto knode add/lookup/delete. Add the same
exhaustion check that the divisor path already has.
Return an error so u32_change() fails with ENOSPC/ENOMEM when the
node ID space is exhausted, and so u32_init() fails with -ENOMEM
when the hash table ID space is exhausted. The extack message
distinguishes pool exhaustion (-ENOSPC) from a transient allocation
failure (-ENOMEM).
Conditions to recreate the bug:
- CONFIG_NET_SCHED=y, CONFIG_CLS_U32=y (or =m with module loaded)
- Create a clsact qdisc on a device, then add 4095 u32 filters with
auto-generated handles to fill the node ID space for the root hash
table (single bucket). The 4096th auto-handle filter add triggers
the duplicate handle (fh 800::fff reused). Reachable at Level 2
(unshare -Urn, namespace-local CAP_NET_ADMIN).
- For gen_new_htid: create 2047 u32 proto entries on the same block
to fill the tp_c handle pool, then create one more. The root table
gets handle 0 and aliases with other handle-0 root tables.
Fixes:
|
||
 Jakub Kicinski
|
f05f0d85cd |
Merge branch 'fix-to-possible-skb-leak-due-to-race-condtion-in-tx-path'
Selvamani Rajagopal says: ==================== Fix to possible skb leak due to race condtion in tx path Now the traffic is handled in threaded IRQ, and the disable_traffic flag is checked before handling the data, new race condition is exposed, in which buffer may leak, if threaded IRQ interrupts the trasmit path midway. With this change, disable_traffic and waiting_tx_skb pointer are protected by spin lock/unlock pair. This is highlighted in Sashiko review https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260611-level-trigger-v5-0-4533a9e85ce2%40onsemi.com Also on buffer overrun condition, probably due to loss of SPI data chunks, receive path doesn't see the expected data chunk with end_valid bit set. As a result, driver keeps adding data chunks to the skb before running out of space and kernel panic is seen. With this change, before adding data to the skb, if there is no space, skb is freed and driver starts looking for new frame by looking for a data chunk with start_valid bit set. [ 705.405490] skbuff: skb_over_panic: text:ffffffd2eb72a264 len:1600 put:64 head:ffffff804e5cdc40 data:ffffff804e5cdc80 tail:0x680 end:0x640 dev:eth1 [ 705.405569] ------------[ cut here ]------------ [ 705.405575] kernel BUG at net/core/skbuff.c:214! [ 705.405589] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 6703.427690] Call trace: [ 705.925157] skb_panic+0x58/0x68 (P) [ 705.928726] skb_put+0x74/0x80 [ 705.931772] oa_tc6_update_rx_skb+0x44/0x98 [oa_tc6_mod] [ 705.937084] oa_tc6_macphy_threaded_irq+0x3f4/0x900 [oa_tc6_mod] [ 705.943084] irq_thread_fn+0x34/0xb8 [ 705.946654] irq_thread+0x1a0/0x300 [ 705.950134] kthread+0x138/0x150 [ 705.953356] ret_from_fork+0x10/0x20 ==================== Link: https://patch.msgid.link/20260824-fix-race-condition-and-crash-v7-0-4323279b18f2@onsemi.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
 Selvamani Rajagopal
|
3cc2aa96b9 |
net: ethernet: oa_tc6: Fix for the wrong data type
Inadvertently bool data type is used where int is supposed to
be used. This might turn a negative error code into true or
false and sign of the return code would be lost.
Fixes:
|
||
|
Selvamani Rajagopal
|
349c366365 |
net: ethernet: oa_tc6: Disable tx queues on fatal error
Previously, TX queue interface was stopped when
disable_traffic flag was set, which would indicate fatal
error. It is more appropriate to disable the queue as,
unless driver is unloaded and reloaded, there is no recovery
after disable_traffic is set.
Queues may be re-enabled inadvertently by other layers.
Intention of disable_traffic is only to stop the traffic
from flowing on fatal error.
Fixes:
|
||
|
Selvamani Rajagopal
|
172c974113 |
net: ethernet: oa_tc6: Improve the error recovery
When oversubscribed traffic causes lot of buffer overflow errors,
probably due to loss of data chunks, driver fails to find a
data chunk with end_valid bit set, before it runs out of sk buffer
space. As a result, assert is seen during skb_put.
Now, check is made if skb buffer has enough tailroom for the
incoming data before accepting. If there is no room, current
frame is abandoned and it will start looking for a data chunk
with start_valid bit, that is a new frame.
SK buffer allocation error is considered as recoverable error.
rx_buf_overflow flag is too specific and no longer the only
condition this flag is used for. Therefore it is renamed as
wait_until_start_valid. This is more appropriate as this flag
is used to look for the next data chunk with SV bit set, after
failures like buffer overflow, buffer allocation failure, skb pointer
validity besides buffer overflow error.
Not writing to status0 if it reads 0.
Fixes:
|
||
|
Selvamani Rajagopal
|
5443d9c4f5 |
net: ethernet: oa_tc6: Protect skb pointer used by two different kernel instances
Threaded IRQ uses waiting_tx_skb. Transmit path also uses this pointer
without any mutual exclusion protection. As a result, it might leak skb
buffer, particularly if threaded IRQ sets disable_traffic true after
start_xmit already checked and found that disable_traffic being false,
if they happen to run on different cores.
On fatal error, where disable_traffic is set, transmit function drops the
packet and return NETDEV_TX_OK. Due to this change, skb_linearize call
is moved up to the beginning of the transmit function.
Since skb buffer may be freed from different contexts, dev_kfree_skb_any
is used to free skb buffer now, replacing one of the kfree_skb call.
oa_tc6_exit disables the irq before setting disable_traffic true.
Fixes:
|
||
 Bryam Vargas
|
fa5acd038e |
net/iucv: fix the recvmsg window update
iucv_sock_recvmsg() sends the HiperSockets-only AF_IUCV_FLAG_WIN without testing the transport, so on a classic z/VM socket iucv_send_ctrl() sizes the skb through a NULL iucv->hs_dev. SO_MSGLIMIT accepts 1, so msglimit / 2 is zero and one recvmsg() on its own socket is enough for an unprivileged process to take a spurious disconnect. It also calls iucv_send_ctrl() under spin_lock_bh(&message_q.lock), which allocates GFP_KERNEL inside a section the code treats as atomic. Sending outside that lock lets two recvmsg() reach afiucv_hs_send() at once, where msg_recv is sampled for the advertised window and subtracted after dev_queue_xmit() -- and sendmsg reaches that counter under lock_sock() while recvmsg holds no socket lock, so both can subtract the same value, the counter goes negative and the credit reaches the peer twice. Test the transport, claim the credit with atomic_xchg() after the last error exit and hand it back if the transmit fails, and send once the lock is dropped. Fixes: |
||
 Kiran Kumar K
|
1376afc766 |
octeontx2-af: fix CN20K default MCAM rule removal on port cleanup
npc_mcam_free_all_entries() disables every MCAM entry mapped to a
port before freeing it. On CN20K, that also disables the default
broadcast, multicast, promiscuous, and unicast rules, which causes
packet drops when all rules are removed per port.
Only disable and free non-default entries. Leave CN20K default rules
enabled when freeing the remaining port entries.
Fixes:
|
||
 Maciej Fijalkowski
|
a8455260b2 |
ipvlan: unregister upper devices outside pnodes_lock
syzbot reported the following circular locking dependency:
xs->mutex -> netdev lock -> pnodes_lock -> net->xdp.lock -> xs->mutex
The pnodes_lock -> net->xdp.lock edge is recorded when
ipvlan_device_event(NETDEV_UNREGISTER) calls unregister_netdevice_many()
while holding pnodes_lock. A nested NETDEV_UNREGISTER notification for
an IPvlan device enters xsk_notifier(), which acquires net->xdp.lock.
Keep pnodes_lock only while marking the upper devices as dying, removing
them from port->ipvlans, and queueing them for unregistration. Once the
devices have been detached from the protected list, release pnodes_lock
before unregister_netdevice_many() invokes notifier callbacks.
The port remains alive across unregistration because
ipvlan_device_event() holds the reference acquired by ipvlan_port_get().
The dying flag prevents a concurrent ->dellink() callback from deleting a
queued device again.
Fixes:
|
||
 Baul Lee
|
4aa61c88b4 |
vxlan: mdb: Fix use-after-free in vxlan_mdb_remote_src_del()
vxlan_mdb_is_valid_source(), which validates MDBE_ATTR_SOURCE and every
MDBE_ATTR_SRC_LIST member, accepts the all-zeros address.
A source list is only accepted on a (*, G) entry, whose source is the
all-zeros address, and for each member of the list an (S, G) entry is
derived from it by substituting the source. Entries are keyed by a plain
memcmp() of struct vxlan_mdb_entry_key, so if MDBE_ATTR_SOURCE is present
and holds the all-zeros address and the source list holds it as well, the
derived (S, G) key is byte-identical to the (*, G) key and resolves to the
same entry. Omitting MDBE_ATTR_SOURCE is not equivalent, as the key is
then left with a zero address family.
vxlan_mdb_remote_src_del() removes the forwarding entry of a source before
freeing the source entry:
vxlan_mdb_remote_src_fwd_del(vxlan, group, remote, &ent->addr);
vxlan_mdb_remote_src_entry_del(ent);
With the keys aliased, the first call deletes the remote of the entry that
owns 'ent' instead of a separate (S, G) entry, and frees 'ent'. The second
call then runs on the freed entry, and its hlist_del() reads ->pprev and
->next out of it and writes through them.
Adding the (*, G) entry with NLM_F_REPLACE and no source list marks the
all-zeros source for deletion and reaches this from the sweep at the end
of vxlan_mdb_remote_srcs_replace().
BUG: KASAN: slab-use-after-free in __vxlan_mdb_add+0x1cd/0xd70
Read of size 8 at addr ffff888102852500 by task poc/84
__vxlan_mdb_add+0x1cd/0xd70
vxlan_mdb_add+0xc0/0x140
rtnl_mdb_add+0x157/0x2a0
rtnetlink_rcv_msg+0x207/0x5a0
Allocated by task 84:
__kmalloc_cache_noprof+0x153/0x360
vxlan_mdb_remote_srcs_add+0x2eb/0x440
__vxlan_mdb_add+0x803/0xd70
Freed by task 84:
kfree+0x14c/0x3b0
vxlan_mdb_remote_del+0x129/0x1a0
__vxlan_mdb_del+0x4f/0xe0
vxlan_mdb_remote_src_fwd_del.isra.0+0x162/0x1b0
__vxlan_mdb_add+0x1c5/0xd70
The MDB operations are netns-scoped, so an unprivileged user can perform
them in a new user and network namespace.
Reject the all-zeros address in vxlan_mdb_is_valid_source(), which covers
both call sites. A (*, G) entry is expressed by omitting the source, so
nothing legitimate is refused.
Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
Fixes:
|
||
 Charles Vosburgh
|
6cfc1b90cb |
sctp: validate chunk length in the inqueue parser
SCTP chunks always include a four-byte generic header, but sctp_inq_pop() currently accepts shorter declared lengths. A zero-length chunk leaves chunk_end at the current header. When ASCONF is covered by the association's SCTP-AUTH policy, sctp_assoc_bh_rcv() can continue before the state machine performs its normal chunk-length check. sctp_inq_pop() then returns the same malformed chunk repeatedly and the receive softirq can lock up. A remote SCTP peer can trigger this after establishing an association on a kernel built with CONFIG_IP_SCTP and configured with net.sctp.addip_enable=1 and net.sctp.auth_enable=1. The reproducer did not require application credentials, a shared SCTP AUTH key, or net.sctp.addip_noauth_enable=1. On commit |
||
 James Nugraha
|
ac8d6b28d4 |
net: amd-xgbe: discard rx packets with bad FCS
amd-xgbe driver currently sets the MAC_RCR.DCRCC bit whenever
RX is enabled. This disables hardware FCS validation, causing packets
with bad FCS to be accepted unconditionally.
This change unsets DCRCC so that packets with bad FCS will be dropped,
in-line with typical behaviours of many other network controllers.
Tests:
- Verified that packets with bad FCS are now dropped.
- Verified that receiving packets with bad FCS will increment the
`rx_crc_errors` counter.
Fixes:
|
||
 Xuanqiang Luo
|
ac08d183da |
raw: annotate disconnect-side IPv4 match writers
raw_v4_match() reads inet_daddr, inet_rcv_saddr and sk_bound_dev_if locklessly under RCU. Bind and connect writers are annotated, but __udp_disconnect() still clears the same fields using plain stores. Commit |
||
 Henry Martin
|
2cb0b0b1ed |
sctp: fix soft lockup from unpadded ASCONF-ACK parameter iteration
sctp_verify_asconf() walks ASCONF-ACK parameters with
sctp_walk_params(), which advances by SCTP_PAD4(length), while the
consumer sctp_get_asconf_response() iterates the same parameters
advancing by the raw length, without padding. A single odd-length
parameter desynchronises the two walks and makes the consumer
interpret attacker-controlled bytes at a misaligned offset.
When those bytes yield a length of zero, the while loop over
asconf_ack_len makes no progress, spinning forever in softirq
context, and the watchdog reports a soft lockup. All reads stay
within the received skb, so the lockup is a pure remote denial of
service. A remote peer can trigger it with a crafted ASCONF-ACK on
an ADD-IP enabled association with an outstanding ASCONF (RFC 5061
section 4.1.2 requires the chunk to be authenticated, but the
predefined empty key id 0 allows the peer to compute the same
association HMAC from publicly exchanged parameters, so the gate
does not help).
The SCTP_PARAM_ERR_CAUSE case of sctp_verify_asconf() also performs
no length check, letting a parameter without a complete error
header reach the consumer, which reads errhdr.cause past the end of
the parameter, an out-of-bounds read.
Reject SCTP_PARAM_ERR_CAUSE parameters shorter than
sizeof(struct sctp_addip_param) + sizeof(struct sctp_errhdr) at the
verifier, and advance the consumer iterator with the same padding
rule as the verifier to keep the two walks in lockstep. The verifier
change guarantees a complete error header in every ERR_CAUSE
parameter the consumer can see, so the consumer's asconf_ack_len
check is dropped and it returns err_param->cause directly. The
consumer padding fix is still required because odd lengths remain
valid for SCTP_PARAM_ERR_CAUSE per RFC 5061.
The issue was found by ZeroHive, a vulnerability hunting agent at
Tencent Yunding Lab.
Fixes:
|
||
 Xin Long
|
2188569e7e |
sctp: fix a TOCTOU race in SCTP_CMD_TIMER_START
The SCTP_CMD_TIMER_START handler checks timer_pending() before calling
timer_reduce(). The timer can expire and detach between these operations,
causing timer_reduce() to rearm the timer without taking the association
reference required for the newly armed timer.
The timer callback later unconditionally drops its association reference,
which can leave the association reference count unbalanced and result in
use-after-free during association teardown.
Use the return value of timer_reduce() to determine whether the timer was
actually armed. Take the association reference only when timer_reduce()
successfully starts a new timer, closing the race between checking the
timer state and rearming it.
This issue was reported by Nico Yip (@_cyeaa_) working with TrendAI Zero
Day Initiative.
Fixes:
|
||
|
Jakub Kicinski
|
b84cc38f3f |
Merge branch 'tcp-fix-use-after-free-in-do_tcp_getsockopt'
Cen Zhang says: ==================== tcp: fix use-after-free in do_tcp_getsockopt() do_tcp_getsockopt() has two lockless reads of icsk_ca_ops. Since BPF struct_ops congestion control made icsk_ca_ops point to dynamically allocated memory, a concurrent setsockopt(TCP_CONGESTION) can replace the pointer and free the old object while either reader is using it. Patch 1 fixes the TCP_CONGESTION path by copying ca_ops->name to a stack buffer while holding rcu_read_lock(). It also uses READ_ONCE() for the lockless load and annotates the relevant icsk_ca_ops stores with WRITE_ONCE(). Patch 2 fixes the TCP_CC_INFO path by keeping the READ_ONCE() load, ca_ops->get_info lookup, and call inside an RCU read-side critical section. ==================== Link: https://patch.msgid.link/cover.1787870710.git.blbllhy@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
 Cen Zhang (Microsoft Security FORGE Labs)
|
385e474086 |
tcp: fix use-after-free in do_tcp_getsockopt(TCP_CC_INFO)
do_tcp_getsockopt() reads icsk->icsk_ca_ops and dereferences the
get_info function pointer without rcu_read_lock(). With BPF struct_ops
congestion control, ca_ops can point to dynamically allocated memory
that is freed concurrently, resulting in a use-after-free when the
kernel dereferences or calls through the stale pointer.
BUG: KASAN: slab-use-after-free in do_tcp_getsockopt+0x2037/0x23e0
Read of size 8 at addr ffff888013701258 by task exploit/149
do_tcp_getsockopt+0x2037/0x23e0 (net/ipv4/tcp.c:4564)
tcp_getsockopt+0x91/0xf0
__sys_getsockopt+0xf7/0x170
Fix this by wrapping the ca_ops load and get_info call within
rcu_read_lock()/rcu_read_unlock(), and using READ_ONCE() to load
the icsk_ca_ops pointer.
Fixes:
|
||
|
Cen Zhang (Microsoft Security FORGE Labs)
|
5271b79b7a |
tcp: fix use-after-free in do_tcp_getsockopt(TCP_CONGESTION)
do_tcp_getsockopt() reads icsk->icsk_ca_ops->name without holding rcu_read_lock(). Since commit |
||
|
Jakub Kicinski
|
7e1d6caa9c |
Merge branch 'net-sched-fix-remaining-actions-notification-accounting-issues'
Victor Nogueira says:
====================
net/sched: Fix remaining actions notification accounting issues
Commit
|
||
 Victor Nogueira
|
251367a0a3 |
net/sched: act_api: fix skb sizing and action leak on reoffload delete
tcf_reoffload_del_notify_msg() sizes the RTM_DELACTION skb with tcf_action_fill_size(action) alone. Unlike every other notification path it never wraps that in tcf_action_full_attrs_size(), so the nlmsg_put() header, struct tcamsg and the TCA_ACT_TAB nest that tca_get_fill() emits - 24 bytes on x86_64 - are not budgeted. As long as the single action stays well under NLMSG_GOODSIZE the floor in alloc_skb() hides this, but once its fill size crosses NLMSG_GOODSIZE the allocation is exactly 24 bytes short and tca_get_fill() runs out of tailroom. That is now easy to reach for an offloadable act_pedit with a large tcfp_nkeys, which commit |
||
|
Victor Nogueira
|
e9ca46ebc3 |
net/sched: act_api: size the RTM_GETACTION reply from the actions
tca_action_gd() already walks every requested action and accumulates
attr_size += tcf_action_fill_size(act), then wraps the result in
tcf_action_full_attrs_size(). For RTM_DELACTION that value is handed to
tcf_del_notify_msg(), which allocates max(attr_size, NLMSG_GOODSIZE). For
RTM_GETACTION it is silently discarded and tcf_get_notify() allocates a
fixed NLMSG_GOODSIZE skb instead.
Any action whose dump exceeds that fixed budget therefore cannot be read
back. For example, act_pedit overruns the budget with 32 actions of four
munge keys each, act_police with 32 policers once the optional
rate/peakrate/result/avrate attributes are present
Fix this by passing attr_size through and allocate the reply the way the
add and delete paths do.
Note on exposure: RTM_GETACTION is the only one of the three action
commands that is not capability checked - tc_ctl_action() requires
CAP_NET_ADMIN for RTM_NEWACTION and RTM_DELACTION only - so this turns a
fixed NLMSG_GOODSIZE reply into a user sized allocation on an
unprivileged path. It is bounded by TCA_ACT_MAX_PRIO actions per
request, and tca_action_gd() does not reject duplicate indices, so a
single large action can be requested 32 times; an act_bpf program near
BPF_MAXINSNS is about 32KB of dump, or roughly 1MB for one request.
Creating such an action still requires CAP_NET_ADMIN, and the add and
delete paths have sized their skbs this way since the Fixes commit.
Should this ever need bounding, GFP_KERNEL_ACCOUNT would charge the
reply to the caller's memcg.
Fixes:
|
||
|
Victor Nogueira
|
13eb543ceb |
net/sched: act_api: budget all shared attributes in notify skbs
tcf_action_shared_attrs_size() is supposed to return an upper bound on the
netlink attributes every action dump emits outside of TCA_ACT_OPTIONS, so
that tcf_add_notify_msg(), tcf_del_notify_msg() and friends can allocate
an skb large enough for the reply. It has fallen behind the dump path and
is now an underestimate for every single action.
Attributes, such as, TCA_ACT_IN_HW_COUNT and TCA_STATS_BASIC_HW are
emitted unconditionally and never accounted for. TCA_STATS_PKT64,
TCA_ACT_USED_HW_STATS, TCA_STATS_RATE_EST, TCA_STATS_RATE_EST64 require
specific conditions, but are also not accounted for.
Fix the issue by budgeting all of them so that we have a legitimate
upper bound. Even tough for of them require specific conditions, they
are cheap so, to avoid overcomplicating, we opted to account for them
unconditionally as well to account for a real worst case scenario.
Fixes:
|
||
 Dong Chenchen
|
28a57fb2c5 |
net: iptunnel: fix stale transport header during tunnel decapsulation
Syzbot reported a crash in qdisc_pkt_len_segs_init() caused by a stale transport_header offset after tunnel decapsulation. BUG: unable to handle page fault for address: ffffed102091a42e Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 340 Comm: qdisc_uaf_repro Not tainted 7.2.0-rc4-00061-g248951ddc14d #256 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:__asan_load2 <IRQ> qdisc_pkt_len_segs_init (net/core/dev.c:4145) __dev_queue_xmit (net/core/dev.c:4787) br_dev_queue_push_xmit (net/bridge/br_forward.c:53) br_handle_frame_finish (net/bridge/br_input.c:229) br_handle_frame (net/bridge/br_input.c:315) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6099) __netif_receive_skb_list_core (net/core/dev.c:6287) netif_receive_skb_list_internal (net/core/dev.c:6445) napi_complete_done (net/core/dev.c:6813) gro_cell_poll (net/core/gro_cells.c:74) __napi_poll (net/core/dev.c:7735) net_rx_action (net/core/dev.c:7798 net/core/dev.c:7955) handle_softirqs (kernel/softirq.c:622) do_softirq (kernel/softirq.c:523 kernel/softirq.c:510 ) __local_bh_enable_ip (kernel/softirq.c:450) tun_get_user (drivers/net/tun.c:1986 (discriminator 1)) tun_chr_write_iter (drivers/net/tun.c:2032) The issue is completely latent until qdisc read transport header in commit |
||
|
Jakub Kicinski
|
b873bf8141 |
Merge branch 'net-mlx5e-prevent-stale-xsk-buffer-release-on-refill-retries'
Jerome Tollet says: ==================== net/mlx5e: Prevent stale XSK buffer release on refill retries Prevent duplicate XSK buffer release when a deferred RX refill fails and the same WQE is retried. Patch 1 fixes legacy cyclic RQ. It is unchanged from v3 and retains Dragos' Reviewed-by tag. Patch 2 fixes the analogous striding-RQ MPWQE path. Following Dragos' review, it now fills skip_release_bitmap in the common error path of mlx5e_xsk_alloc_rx_mpwqe(), consistently with mlx5e_alloc_rx_mpwqe(). Targeted fault injection covered both an early allocation failure and a partial 8-of-16-buffer unwind. With three consecutive failures for one MPWQE, the original 16 XSK buffers were released only once, retries saw a full bitmap, and a later successful allocation cleared it. A clean 20-second AF_XDP zero-copy pressure run exercised 1,575,262 buffer allocation failures without invalid descriptors, WQE errors, or kernel warnings. ==================== Link: https://patch.msgid.link/20260824141645.23700-1-jtollet@cisco.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
 Jerome Tollet
|
63811edf51 |
net/mlx5e: Prevent stale XSK buffer release on MPWQE refill retry
With AF_XDP on a striding RQ, mlx5e defers releasing XSK buffers until
an MPWQE is refilled. If XSK allocation then returns -ENOMEM,
actual_wq_head is not advanced and a later NAPI poll retries the same
WQE.
mlx5e_free_rx_mpwqe() leaves each released slot marked as releasable. On
retry it can therefore call xsk_buff_free() again through stale pointers
after the frames have returned to the XSK pool and been reallocated.
Set all skip_release_bitmap bits in the common error path of
mlx5e_xsk_alloc_rx_mpwqe(). This matches mlx5e_alloc_rx_mpwqe(). A
successful allocation already clears the bitmap after replacing every
buffer, so retries become idempotent without changing the success path.
Fault injection forced three consecutive failures for one selected MPWQE.
Both an early allocation failure and a partial 8-of-16-buffer unwind
released the original 16 XSK buffers only once. Each error left a full
bitmap, the following NAPI retry skipped the release, and a later
successful allocation cleared it. A 20-second AF_XDP zero-copy pressure
run exercised 1,575,262 buffer allocation failures without invalid
descriptors, WQE errors, or kernel warnings.
Fixes:
|
||
|
Jerome Tollet
|
e01620844c |
net/mlx5e: Prevent stale XSK buffer release on refill retry
When an XDP redirect to an AF_XDP socket fails because its RX ring is
full, the XSK core frees the buffer. During the subsequent batched refill
of a legacy cyclic RQ, mlx5e also releases the WQE's XSK buffer before
allocating a replacement. If that refill succeeds only partially, a WQE
left without a replacement retains its old buffer pointer.
The buffer can meanwhile be allocated to another WQE. A later refill
retry can then free the live buffer through the stale pointer and publish
the same UMEM frame twice.
Mark the WQE as released immediately after the driver-side free. The flag
is already cleared when a replacement buffer is assigned, so refill
retries no longer release stale pointers.
The failure is silent and produces no kernel warning or splat. A
standalone legacy cyclic-RQ zero-copy libxsk reproducer, using 64-byte UDP
traffic offered at 12 Mpps, detected it: stock stopped after 2,854,914
packets in 4.094 seconds, with 4,542 xdp_rx_ring_full events and 64
ownership/double-publication errors. With this change it processed
356,904,225 packets in 30 seconds despite 571,405 xdp_rx_ring_full events,
with no ownership or data errors.
Fixes:
|
||
 Lorenzo Bianconi
|
a5d946466a |
net: stmmac: fix dma mapping leak in stmmac_tso_xmit()
In stmmac_tso_xmit(), if the DMA mapping of an skb fragment fails, the
frame is dropped but the DMA mappings already created for the linear
part and for the fragments mapped before the failure are never
unmapped, leaking DMA mappings.
Fix the leak by walking back over the descriptors used by the frame and
releasing each of them with stmmac_free_tx_buffer(). Moreover, release
the descriptors with stmmac_release_tx_desc() unmapping the DMA buffers.
Fixes:
|
||
 Eric Dumazet
|
18666c73af |
tcp: use GFP_ATOMIC in tcp_send_active_reset()
tcp_send_active_reset() can be called from contexts where gfp_any()
(in tcp_disconnect()) or sk->sk_allocation (in __tcp_close() and
mptcp_do_fastclose()) evaluates to GFP_KERNEL, which includes
__GFP_FS and __GFP_DIRECT_RECLAIM.
Allocating with GFP_KERNEL while holding the socket lock (sk_lock) creates
a lockdep dependency:
sk_lock -> fs_reclaim
This causes false-positive lockdep circular locking warnings with storage
subsystems (such as nvme-tcp) that acquire socket locks in block I/O paths
and invoke tcp_disconnect() or close sockets upon teardown:
set->srcu -> sk_lock -> fs_reclaim -> elevator_lock -> set->srcu
Active resets are small RST packet headers that should never
enter direct reclaim or block while holding socket locks.
Use sk_gfp_mask(sk, GFP_ATOMIC | __GFP_NOWARN) inside tcp_send_active_reset()
and remove its priority argument. This preserves __GFP_MEMALLOC access
for SOCK_MEMALLOC sockets, suppresses allocation failure warnings,
and aligns with other control packet allocations (e.g. tcp_send_fin(),
__tcp_send_ack(), tcp_xmit_probe_skb()).
Fixes:
|
||
|
Jakub Kicinski
|
c185c78e2a |
Merge branch 'netlink-specs-fixes-for-conntrack-dump-filtering'
Ilya Maximets says: ==================== netlink: specs: fixes for conntrack dump filtering ==================== Link: https://patch.msgid.link/20260826220444.4054714-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
 Ilya Maximets
|
8b348496cb |
netlink: specs: add missing mask attributes for conntrack dump
'mark-mask' and 'status-mask' are defined and supported by the
conntrack dump, but missing from the list of arguments.
While at it, the order of the arguments should follow the order of
their definition in the enum ctattr_type. That appears to be a common
convention for other spec files.
Fixes:
|
||
|
Ilya Maximets
|
2a004bfb62 |
netlink: specs: fix the conntrack filter type
The CTA_FILTER doesn't contain nested tuple attributes, instead it
contains bit masks that specify which tuple attributes to filter on.
The values for filtering are taken from the top-level CTA_TUPLE_ORIG
and CTA_TUPLE_REPLY, which are also missing in the attribute list
for the dump request.
The bits themselves somehow are not in the public headers, so not
defining them in the spec either for now. Once they are public in
uAPI, they can be added here with enum-as-flags.
Fixes:
|
||
|
Eric Dumazet
|
7fcc2fe39f |
net: icmp: avoid invalid transport header access in icmp_send tracepoint
syzbot reported a WARNING triggered by DEBUG_NET_WARN_ON_ONCE():
WARNING: at skb_transport_header include/linux/skbuff.h:3087 [inline]
WARNING: at udp_hdr include/linux/udp.h:23 [inline]
WARNING: at do_trace_event_raw_event_icmp_send include/trace/events/icmp.h:30 [inline]
WARNING: at trace_event_raw_event_icmp_send+0x48c/0x6ec include/trace/events/icmp.h:11
Call trace:
skb_transport_header include/linux/skbuff.h:3087 [inline]
udp_hdr include/linux/udp.h:23 [inline]
do_trace_event_raw_event_icmp_send include/trace/events/icmp.h:30 [inline]
trace_event_raw_event_icmp_send+0x48c/0x6ec include/trace/events/icmp.h:11
__traceiter_icmp_send include/trace/events/icmp.h:11 [inline]
__do_trace_icmp_send include/trace/events/icmp.h:11 [inline]
trace_icmp_send+0x320/0x49c include/trace/events/icmp.h:11
__icmp_send+0xcfc/0x11d8 net/ipv4/icmp.c:1013
ipv4_send_dest_unreach net/ipv4/route.c:1280 [inline]
ipv4_link_failure+0x57c/0x8dc net/ipv4/route.c:1287
dst_link_failure include/net/dst.h:438 [inline]
vti_tunnel_xmit+0xe40/0x17a4 net/ipv4/ip_vti.c:307
TP_fast_assign() unconditionally calls udp_hdr(skb) before checking
whether the packet is UDP. Furthermore, __icmp_send() can be invoked
from paths (e.g., link failures, ARP errors, forwarding, AF_PACKET)
where skb->transport_header was never initialized (~0U).
Under CONFIG_DEBUG_NET=y, calling skb_transport_header(skb) triggers
DEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb)).
Fix this by:
1. Only parsing transport info when iph->protocol == IPPROTO_UDP.
2. Using skb_header_pointer() at skb_network_offset(skb) + (iph->ihl << 2)
to safely fetch the UDP header without assuming transport_header is set.
Fixes:
|
||
 Chengfeng Ye
|
dddf197f29 |
tipc: protect node reset trace dump with node lock
The tipc_node_reset_links trace event asks tipc_node_dump() to walk the
node's link entries. Unlike the other node events that request link data,
this event runs without the node lock.
This permits bearer teardown to free a link while the trace callback is
dumping it:
CPU 0 CPU 1
trace_tipc_node_reset_links()
tipc_node_dump()
l = n->links[0].link
tipc_node_write_lock()
kfree(l)
n->links[0].link = NULL
tipc_node_write_unlock()
tipc_link_dump(l)
tipc_link_dump() then dereferences the stale pointer. KASAN reported:
BUG: KASAN: slab-use-after-free in tipc_link_dump
Read of size 4 by task poc/115
Call Trace:
tipc_link_dump+0x10cb/0x16b0
tipc_node_dump+0x4bb/0x740
trace_event_raw_event_tipc_node_class+0x258/0x360
tipc_node_reset_links+0x14d/0x1a0
tipc_rcv+0x13f5/0x3030
tipc_udp_recv+0x4e3/0x670
Allocated by task 0:
tipc_link_create+0x1e1/0x1020
tipc_node_check_dest+0x7d2/0x11a0
tipc_disc_rcv+0xdbf/0x1430
Freed by task 89:
kfree+0x131/0x3c0
tipc_node_link_down+0x267/0x4b0
tipc_node_delete_links+0xec/0x160
bearer_disable+0x107/0x260
Take the node write lock around the trace event. This serializes the
dump against tipc_node_link_down(delete=true), which frees the link
under the same write lock.
Fixes:
|
||
 Zihan Xi
|
5046d2880f |
ipv4: avoid divide by zero in fib_rebalance
fib_rebalance() computes the total eligible nexthop weight in one pass and programs upper bounds in a second pass. A concurrent change to ignore_routes_with_linkdown can make the first pass return zero while the second pass sees an eligible nexthop, resulting in division by zero. If the first pass reports a zero total, set each nexthop upper bound to -1 and skip the division. This matches the IPv6 fix in commit |
||
 Linus Torvalds
|
1b78070aae |
Merge tag 'net-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Pull networking fixes from Jakub Kicinski:
"Including fixes from Bluetooth, IPSec and Netfilter.
Current release - fix to a fix:
- netfilter: ipset: remove need to allocate memory on delete operations
Current release - regressions:
- macb: drop CONFIG_OF #if block, fix build
Previous releases - always broken:
- stream of fixes for SCTP continues
- inet: frags: strip GSO state from fragments before reassembly
- virtio-net: ensure that TCP packets don't overflow gso_segs
- tcp-ao: fix use-after-free of current_key on reconnect to another
peer
- page_pool: remove zone/policy GFP flags when allocating XArray
entries
- Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN
- tls: device: fix out-of-bounds write in tls_append_frag()
- eth: bnxt:
- ring the doorbell when SW USO exits early, avoid packets stuck
in Tx
- gate TPH enablement behind BNXT_SUPPORTS_QUEUE_API check, avoid
users of older NICs seeing non-actionable warning messages
- eth: qede: fix NULL pointer dereference in TPA fragment processing"
* tag 'net-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (216 commits)
inet: frags: strip GSO state from fragments before reassembly
net/sched: sch_htb: limit htb_classify inner-class filter hops
selftests/net: packetdrill: add tcp_urg_ptr_retransmit
tcp: fix corruption of urgent data on multi-segment retransmit
usb: atm: usbatm: fix invalid ci_range initialization
net: fec: only stop PTP if it was initialized
slip: remove slip_hangup() to fix use-after-free in slip_receive_buf()
net: bridge: mcast: fix use-after-free of a master VLAN's multicast context
net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup
net: dsa: mxl862xx: enable assisted learning on CPU port
net: stmmac: restore NET_IP_ALIGN in the RX DMA offset
net: stmmac: drop gso_enabled_types and rely on netdev features
net: stmmac: selftests: Don't test flow control for small rx fifos
net: stmmac: selftests: Account for the UC filter list for filtering tests
net: stmmac: dwxgmac: Account for the primary MAC address for UC filtering
net: stmmac: dwmac4: Account for the primary MAC address for UC filtering
net: stmmac: dwmac1000: Account for the primary MAC address for UC filtering
net: stmmac: selftests: Check multiple MMC counters
selftests: net: Fix slow configurations in big_tcp_tunnels.sh
selftests: net: Lower threshold with csum offload off in big_tcp_tunnels.sh
...
|
||
|
Jakub Kicinski
|
4a9d62a877 |
Merge tag 'nf-26-08-27' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf
Pablo Neira Ayuso says:
====================
Netfilter fixes for net
The following patchset contains Netfilter fixes for net:
1) Use DEBUG_NET_WARN_ON_ONCE() instead of WARN_ON() from the tproxy
datapath, a recent bug found a way to reach WARN_ON from datapath
due to insufficient validation of xt_TPROTO checkentry.
From Fernando F. Mancera.
2) Similar to previous patch to replace WARN_ON_ONCE by
DEBUG_NET_WARN_ON_ONCE() for connlimit. Not known issue, but
since this patch has been around for a while, let's merge it.
Also from Fernando.
3) Move nf_tables harware offload commit path after chain blob
and audit to reduce chances of leaving the hardware in
inconsistent state.
4) Add missing vzeroupper to nf_tables pipapo AVX2 to address
performace degradation to later user of SSE code,
from Eric Biggers.
5) Remove pr_debug() in x_tables extensions, a recent bogus found a
way to print a unsanitized string in xt_IDLETIMER, many of these
pr_debug() calls are there for historical reasons.
6) Use pr_info_ratelimited() in x_tables .checkentry.
7) Fix an imbalance in module refcount due to incorrect override
expression logic with sets. Remove unnecessary clone in control
plane, use the existing expressions provided by set or dynset
expression. Release override expressions only.
8) Tigthen nf_tables device name removal, it is possible to remove
prefix strings with exact device name. From Fernando F. Mancera.
9) Set on the set dead bit earlier, otherwise it is possible to
call .commit on deleted sets. This also addresses the
re-introduction of a bug.
* tag 'nf-26-08-27' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf:
netfilter: nf_tables: remove leftover set_update_list
netfilter: nf_tables: set on dead bit when performing early element removal
netfilter: nf_tables: skip double clone set expressions on element insert
netfilter: x_tables: replace pr_{info,err}() by pr_info_ratelimited()
netfilter: x_tables: remove pr_debug
netfilter: nft_set_pipapo_avx2: add missing vzeroupper
netfilter: nf_tables: move hardware offload step after building the chain blob
netfilter: conncount: use DEBUG_NET_WARN_ON_ONCE on reaching count limit
netfilter: tproxy: use DEBUG_NET_WARN_ON_ONCE for protocol fallbacks
====================
Link: https://patch.msgid.link/20260827141733.423453-1-pablo@netfilter.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
||
|
Linus Torvalds
|
3ba13f5e71 |
Merge tag 'devicetree-fixes-for-7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
Pull devicetree fixes from Rob Herring: - Fix possible out-of-bounds access in of_alias_scan() - Fix refcount leak in of_irq_get_affinity() - Add Qualcomm SPMI PMIC haptics input which is already referenced * tag 'devicetree-fixes-for-7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: of: fix out-of-bounds read in of_alias_scan() stem parser of/irq: Fix device node refcount leak in of_irq_get_affinity() dt-bindings: input: Add Qualcomm SPMI PMIC haptics |
||
 Xinyang Ge
|
d5dc1e69fd |
inet: frags: strip GSO state from fragments before reassembly
A virtio_net_hdr (tun/tap, or AF_PACKET with PACKET_VNET_HDR) can mark an IPv4 or IPv6 fragment as GSO; nothing relates gso_type to frag_off. inet_frag_reasm_prepare()/inet_frag_reasm_finish() keep the first fragment's skb as the head of the reassembled datagram, including its shinfo->gso_size/gso_type/gso_segs, and chain the remaining fragments on frag_list with whatever linear/paged layout they arrived with. After ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...) the reassembled skb therefore still claims to be GSO (SKB_GSO_DODGY), and the next software segmentation point - udp_rcv_segment() on local delivery, validate_xmit_skb(), or the ip_finish_output_gso() slow path - hands it to skb_segment(). skb_segment()'s frag_list walk assumes GRO-shaped input and hits one of its BUG_ON()s. Two writes to a tap by an unprivileged user in its own userns are enough: kernel BUG at net/core/skbuff.c:4899! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ #2 RIP: 0010:skb_segment+0x20ca/0x48b0 Call Trace: <TASK> __udp_gso_segment+0x29a/0x27d0 udp4_ufo_fragment+0x458/0x6c0 inet_gso_segment+0x429/0x1340 skb_mac_gso_segment+0x233/0x4f0 __skb_gso_segment+0x308/0x660 udp_queue_rcv_skb+0x440/0xad0 udp_unicast_rcv_skb+0xc7/0x2c0 udp_rcv+0x16ce/0x2260 ip_protocol_deliver_rcu+0x197/0x2d0 ip_local_deliver+0x430/0x690 ip_rcv+0x16f/0x1f0 __netif_receive_skb_one_core+0x15e/0x1c0 __netif_receive_skb+0x1e/0x110 netif_receive_skb+0xf6/0x5c0 tun_rx_batched.isra.0+0x3ab/0x790 tun_get_user+0x17c3/0x3550 tun_chr_write_iter+0xba/0x1b0 vfs_write+0x646/0x1130 </TASK> Kernel panic - not syncing: Fatal exception in interrupt This runs with BH disabled, so it is a panic rather than an oops. The same is reachable with CAP_NET_RAW in a netns where a defrag point precedes a GSO point, and from a guest whose VMM forwards virtio_net_hdr to a tap. The SKB_GSO_DODGY frag_list checks added by commit |
||
|
Jamal Hadi Salim
|
729c4896ab |
net/sched: sch_htb: limit htb_classify inner-class filter hops
htb_classify() follows each filter-selected inner class by switching
to cl->filter_list, but never bounds the number of hops. A filter on
an inner class can point back to itself or to another inner class that
points back, creating an infinite loop in the packet classification
path with the qdisc lock held and BH disabled — a soft lockup / panic
from a single packet.
Bound the traversal with a hop counter and drop the packet with a
rate-limited warning once the bound is exceeded. The counter is
incremented at the point the inner filter chain is picked up, after the
TC_ACT_* switch has consumed the classifier verdict, so a terminal
TC_ACT_QUEUED/STOLEN/TRAP on the last permitted chain still sets *qerr
to __NET_XMIT_STOLEN and the packet is not charged as a drop by this
qdisc or its parent.
The bound is TC_HTB_MAXDEPTH, taken from HTB's own parameters rather than
from the qdisc hierarchy depth limit. Class levels run from 0 to
TC_HTB_MAXDEPTH - 1, so a traversal that strictly descends in level can
take at most TC_HTB_MAXDEPTH hops. That descent is what a sane
configuration does, but it is assumed here rather than enforced:
htb_find() resolves a classid against every class in the qdisc, so a
filter may equally select a sibling or an ancestor. The normal
root -> inner -> leaf path takes a single hop, so the bound does not
affect legitimate classification.
htb_classify() can now return NULL irrespective of CONFIG_NET_CLS_ACT,
whereas previously every NULL return sat inside that ifdef. The NULL
handler in htb_enqueue() therefore cannot stay conditional either, so
drop the ifdef around it. This matches hfsc_enqueue(), which has always
handled a NULL class unconditionally. Without it, a kernel built
without actions would dereference a NULL class instead of dropping.
Conditions to recreate the bug:
- CONFIG_NET_SCHED, CONFIG_NET_SCH_HTB, CONFIG_NET_CLS_U32,
CONFIG_LOCKUP_DETECTOR.
- Create an HTB qdisc on a device (e.g. lo), add an inner class
1:1 with a leaf child 1:10, install a root u32 filter selecting
1:1, and an inner-class u32 filter on 1:1 also selecting 1:1.
- Send one packet (ping). On the unfixed kernel the classify loop
spins with the qdisc lock held; with softlockup_panic=1 it panics.
- Reachable from unprivileged user via unshare -Urn (CAP_NET_ADMIN).
Fixes:
|
||
 Jiayuan Chen
|
6a7e91f890 |
selftests/net: packetdrill: add tcp_urg_ptr_retransmit
Drive a connection into urgent mode and force a multi-segment retransmit, checking that each retransmitted segment keeps its own urg_ptr. The test asserts the fixed behaviour: the hole is retransmitted as two independent skbs, each with its own urg_ptr (5001 and 4001) and no PSH. An unpatched kernel instead sends one super-skb whose GSO split copies urg_ptr onto the second segment and also sets PSH there, so on an unpatched kernel the mismatch shows up on the PSH bit (actual P.U ... urg 5001) before the urg_ptr: tcp_urg_ptr_retransmit.pkt:63: live packet field tcp_psh: expected: 0 (0x0) vs actual: 1 (0x1) script packet: .U 1001:2001(1000) ack 1 actual packet: P.U 1001:2001(1000) ack 1 win 1050 After the fix the retransmit carries a per-segment urg_ptr and the test passes. Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260826141145.67823-2-jiayuan.chen@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Jiayuan Chen
|
ce2b807f42 |
tcp: fix corruption of urgent data on multi-segment retransmit
On the normal xmit path, while in urgent mode we refuse to build a
multi-segment TSO packet, so every segment gets its own urg_ptr:
/* tcp_write_xmit() */
limit = mss_now;
if (tso_segs > 1 && !tcp_urg_mode(tp))
limit = tcp_mss_split_point(...);
The retransmit path has no such guard. __tcp_retransmit_skb() builds a
segs > 1 skb and hands it to the GSO layer, which only advances th->seq
per segment and copies urg_ptr verbatim:
/* __tcp_retransmit_skb() */
len = cur_mss * segs; /* segs > 1, no urg_mode check */
...
/* tcp_gso_segment(): bumps seq only, urg_ptr is copied */
urg_ptr is an offset from the segment's own seq, so a copied value points
at a different place on each segment. The receiver rebuilds the absolute
urgent seq as seg.seq + urg_ptr, so it walks a moving urgent point instead
of the one OOB byte:
seg1 seq 1 urg_ptr 5001 -> urgent @ 5001 (ok)
seg2 seq 1001 urg_ptr 5001 -> urgent @ 6001 (wrong, +MSS)
seg3 seq 2001 urg_ptr 5001 -> urgent @ 7001 (wrong, +2*MSS)
The real OOB byte is never pointed at, so the receiver stops splicing it
out and delivers it as normal in-band data, corrupting the stream.
Guard the retransmit length like the xmit path: keep segs = 1 while in
urgent mode.
Fixes:
|
||
 Deepanshu Kartikey
|
a60fd8c6db |
usb: atm: usbatm: fix invalid ci_range initialization
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:
<TASK>
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 <uapi/linux/atmdev.h> 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:
|
||
 bui duc phuc
|
dd890ae292 |
net: fec: only stop PTP if it was initialized
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:
|
||
|
Eric Dumazet
|
23c53269f2 |
slip: remove slip_hangup() to fix use-after-free in slip_receive_buf()
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:
|
||
|
Linus Torvalds
|
9bb34313d9 |
Merge tag 'spi-fix-v7.3-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown: "A couple of fixes that came in during the merge window: Geert fixed an uninitialised data bug in the amlogic-spisg driver which could crash and in the Loongson driver Li Jun hooked up the existing suspend operations more fully to fix hibernation" * tag 'spi-fix-v7.3-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: loongson: pm: add .freeze .poweroff .thaw .restore spi: amlogic-spisg: Make sure clk_init_data is fully initialized |
||
 Norbert Szetei
|
50e5c6605c |
net: bridge: mcast: fix use-after-free of a master VLAN's multicast context
br_multicast_toggle_one_vlan() clears BR_VLFLAG_MCAST_ENABLED under
br->multicast_lock before stopping a VLAN's multicast context. That is
the teardown handshake: lockless readers gate on the flag through
br_multicast_ctx_should_use() -> br_multicast_ctx_vlan_disabled(), so
once it is cleared under the lock no reader can arm the context again.
For a master VLAN the handshake never runs. __vlan_del() clears
BRIDGE_VLAN_INFO_BRENTRY before calling br_vlan_put_master(), so
br_multicast_toggle_one_vlan(masterv, false) returns early on
!br_vlan_is_brentry(vlan): the flag stays set and br->multicast_lock is
never taken. br_vlan_put_master() then drains the context in
br_multicast_ctx_deinit() and frees the VLAN through call_rcu(), while a
reader still inside rcu_read_lock() sees the context as enabled and
re-arms it. The port and port-VLAN branch of the function has no
br_vlan_is_brentry() test and flips the flag under br->multicast_lock,
so it is not affected.
The reader is the bridge transmit path. For a master VLAN
br_multicast_rcv() selects brmctx = &vlan->br_mcast_ctx with
pmctx = NULL, so IGMP sent to the bridge device re-arms the context's
timers after br_multicast_ctx_deinit() has already stopped them.
BUG: KASAN: slab-use-after-free in detach_if_pending+0x412/0x4a0
Write of size 8 at addr ffff88810ac39918 by task brmc/601
__mod_timer+0x51a/0xc50
br_multicast_host_join+0x25b/0x390
__br_multicast_add_group+0x468/0x530
br_ip4_multicast_add_group+0x1a0/0x260
br_multicast_rcv+0x2cda/0x61e0
br_dev_xmit+0x6c4/0x1540
Allocated by task 610:
br_vlan_add+0x111/0xb40
br_vlan_info+0x370/0x3e0
Freed by task 0:
kfree+0x1a7/0x4f0
rcu_core+0x7dc/0x10a0
Only test br_vlan_is_brentry() when enabling, like the
br_multicast_ctx_vlan_global_disabled() test next to it. Disabling then
always clears BR_VLFLAG_MCAST_ENABLED under br->multicast_lock before
br_multicast_ctx_deinit() drains the context.
Fixes:
|