Merge tag 'net-7.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Pull networking fixes from Jakub Kicinski:
"Including fixes from netfilter, wireless and bluetooth.
Previous releases - regressions:
- tcp: rate limit receive queue collapsing
- raw: fix ICMP unreachable sent when receive queue is full
- eth: bnxt_en: take RTNL before netif_close() when aborting FW reset
Previous releases - always broken:
- tcp:
- bound snd_cwnd_clamp to TCP_MAX_SND_CWND
- number of fixes for TCP Fast Open
[41 lines not shown]
Merge branch 'nsh-limit-recursion-in-nsh_gso_segment'
Eric Dumazet says:
====================
nsh: limit recursion in nsh_gso_segment()
Sashiko found that nsh_gso_segment() can call itself, through
skb_mac_gso_segment(), once per stacked NSH header. Nothing limits the
depth, and a 64KB GSO packet made of 8-byte NSH headers overflows the
kernel stack. It was reported while reviewing an unrelated virtio
series [1].
Such a packet can be sent with a packet socket using PACKET_VNET_HDR,
when the nsh module is loaded.
Patch 1 uses the recursion counter added in commit 006c8b834aed ("net:
gso: limit recursive IP-in-IP segmentation"), with the same limit as
IPv4 and IPv6.
[7 lines not shown]
selftests: net: add a test for NSH GSO
Send TCPv4 GSO packets encapsulated in a stack of NSH headers to a
dummy device which has TSO disabled, using a packet socket with
PACKET_VNET_HDR, and count the packets the device transmits.
Packets with one or four NSH headers must be segmented. Packets with
5, 64 or 8000 NSH headers must be dropped: they exceed the recursion
limit of the GSO handlers. Without the limit in nsh_gso_segment(),
the last one overflows the kernel stack.
# ./nsh_gso.sh
PASS: 1 NSH headers: 4 packets sent
PASS: 4 NSH headers: 4 packets sent
PASS: 5 NSH headers: 0 packets sent
PASS: 64 NSH headers: 0 packets sent
PASS: 8000 NSH headers: 0 packets sent
Signed-off-by: Eric Dumazet <edumazet at kernel.org>
[2 lines not shown]
nsh: limit recursion in nsh_gso_segment()
nsh_gso_segment() calls skb_mac_gso_segment() for the inner packet,
which calls nsh_gso_segment() again when the next protocol is NSH,
either directly or behind an inner Ethernet header (ETH_P_TEB).
Nothing limits the depth: a GSO packet made of stacked 8-byte NSH
headers recurses once per header, and a 64KB packet can hold about
8000 of them, overflowing the kernel stack.
Such a packet can be injected with a packet socket using
PACKET_VNET_HDR, or with tun/tap or virtio_net, as nothing checks
that a GSO packet with VIRTIO_NET_HDR_F_NEEDS_CSUM carries the
protocol it claims. It is then segmented in software if the output
device does not support the GSO type:
BUG: TASK stack guard page was hit at ffffcad5c0ab3ff8 (stack is ffffcad5c0ab4000..ffffcad5c0ab8000)
Oops: stack guard page: 0000 [#1] SMP NOPTI
CPU: 3 UID: 0 PID: 337 Comm: nsh_gso Tainted: G E 7.4.0-rc1+ #118 PREEMPT(lazy)
[35 lines not shown]
Merge branch 'net-tls-break-the-connection-after-a-burst-of-empty-data-records'
Jakub Kicinski says:
====================
net: tls: break the connection after a burst of empty data records
Deal with overload of zero-length TLS records. This is the next iteration
of Chuck's series. I tried to make it as simple as possible - break the
connection if sender floods us with zero-length records. Consume / discard
those records even on PEEK to avoid infinite rx_list growth.
https://lore.kernel.org/20261019-tls-follow-on-v6-0-ab01c4ecca0c@kernel.org
====================
Link: https://patch.msgid.link/20261111185522.2859004-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
tls: Consume empty data records in tls_sw_splice_read()
A zero-length application_data record decrypts to full_len == 0,
so tls_sw_splice_read() splices zero bytes and returns zero. A zero
return from a splice read means EOF, and the caller tears down a
connection that is still live.
Consume the record and fetch the next one, as tls_sw_read_sock()
does. The cap on consecutive empty records bounds the loop.
When an empty record precedes a close_notify, splice(2) now returns
-EINVAL from the control-record test instead of a false EOF. A
splice that reaches an alert record already reports -EINVAL.
Fixes: c46234ebb4d1 ("tls: RX path for ktls")
Reported-by: Sabrina Dubroca <sd at queasysnail.net>
Closes: https://lore.kernel.org/netdev/akaoXcfamBp8_mYe@krikkit/
Signed-off-by: Chuck Lever <cel at kernel.org>
Link: https://patch.msgid.link/20261111185522.2859004-3-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
selftests: tls: Skip the zero_len tests when TLS is unavailable
FIXTURE_SETUP(zero_len) returns early when ulp_sock_pair() reports
that the TCP_ULP setsockopt failed, so on a kernel built without
CONFIG_TLS the TLS_RX setsockopt never runs. TEST_F(zero_len, test)
then sends its raw records over a plain TCP socket, which returns
the ciphertext verbatim. All eight variants FAIL on a machine that
lacks TLS, and those failures mask any real regression in the same
run.
Skip the test when the fixture recorded notls, as the other
fixtures in this file do.
Fixes: a61a3e961baf ("selftests: tls: add tests for zero-length records")
Signed-off-by: Chuck Lever <cel at kernel.org>
Link: https://patch.msgid.link/20261111185522.2859004-4-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
selftests: tls: Cover the cap on consecutive empty records
Check through both recv() and splice() that a run of 128 empty data
records is consumed and the data record behind it is delivered, and
that a run of 129 breaks the connection with EBADMSG before the data
record can be read. Two runs of 128 with a read returning EAGAIN in
between must not break the connection, the cap applies to a burst the
reader cannot keep up with, not to the connection as a whole.
kTLS cannot send an empty record. A TLS 1.3 record of type 0 whose
only byte is the data content type decrypts to one, since the receiver
strips the 0 as padding.
Reviewed-by: Chuck Lever <cel at kernel.org>
Link: https://patch.msgid.link/20261111185522.2859004-6-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
selftests: tls: Extend coverage for zero-length records
The zero_len fixture injects raw pre-encrypted records over a
socket carrying a TLS_RX key only, and some of those records are
zero-length application_data records. Every variant reads the
records back with recvmsg() without MSG_PEEK, so neither splice nor
MSG_PEEK is tested against an empty record.
Add zero_len_splice and zero_len_peek. A zero return from splice()
means EOF, so zero_len_splice checks that a run of empty data
records does not end a live connection. zero_len_peek checks that a
peek reaches the payload behind a run of empty records and leaves
the payload in place for the read that follows. When a payload does
not follow the run, the peek must leave the socket unreadable. An
unfixed kernel returns 0 from splice(), and after the peek poll()
reports the socket readable.
Signed-off-by: Chuck Lever <cel at kernel.org>
Link: https://patch.msgid.link/20261111185522.2859004-5-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
tls: Break the connection after a burst of empty data records
TLS permits zero-length application_data records, and RFC 8446
suggests them for generating cover traffic. Nothing bounds how many of
them a reader processes back to back, though. They advance neither
loop bound in tls_sw_recvmsg() and tls_sw_read_sock(), so a peer
streaming them faster than the reader decrypts them keeps it in the
kernel for as long as they arrive. recvmsg() does not check for signals
while records are ready, and its peek and async paths queue every empty
record on rx_list. read_sock consumers like nvme-tcp hold the socket
lock throughout and never get control back.
Break the connection once a reader decrypts more than 128 consecutive
empty data records without sleeping or returning to its caller in
between, treating the burst as a protocol violation like a malformed
record header. A stream of empty records which the reader keeps up with
costs no more than any other traffic, so the count starts over on every
read and whenever the reader waits for the next record. The strparser
is stopped before it parses the next record, so the reader gets the
[22 lines not shown]
Merge tag 'for-7.4-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux
Pull btrfs fixes from David Sterba:
- zoned mode fixes
- fix counting active zones after activation
- redo zone reset after error
- update device lock range during mount and zone loading
to avoid lockdep warnings with device drivers (virtio)
- space accounting and extent buffer handling fixes
- fix keeping zstd workspace for the last level
- handle a real case of a subvolume with 0 refs in the SUBVOL_SYNC
ioctl
- properly handle case of zero num_stripes when reading chunk items
- exclude reloc tree from xarray as it is special and its key does
[20 lines not shown]
net: phy: c45: select BASE-T1 type for the forced speed
Commit 25108a834e14 ("net: phy: c45: add support for 1000BASE-T1 forced
setup") made genphy_c45_pma_setup_forced() write the type selection
field (bits 3:0) of the BASE-T1 PMA/PMD control register (1.2100) on
every forced setup: 1000BASE-T1 for SPEED_1000, and 0 for everything
else. 0 selects 100BASE-T1, so forcing a 10BASE-T1L PHY to 10 Mbit/s
now also switches its PMA to 100BASE-T1, a mode it does not implement.
Seen on an ADIN1110 (internal ADIN1100 PHY): after
ethtool -s ethX autoneg off speed 10 master-slave forced-master
1.2100 reads 0xc000 instead of the 0xc002. Since the field is not
restored by re-enabling autoneg, the PHY keeps the wrong type until
the next forced setup or reset.
Add a helper that returns the type selection value for the forced speed
and the supported link modes: 100BASE-T1, 1000BASE-T1, and 10BASE-T1L or
[16 lines not shown]
net/mlx5e: Fix false WARN_ON_ONCE in flow steering cleanup on RX init failure
mlx5e_attach_netdev() sets rx_mode_active before calling init_rx(), so
any init_rx() failure after mlx5e_create_flow_steering() has succeeded
makes mlx5e_destroy_flow_steering() trip
WARN_ON_ONCE(fs->rx_mode_active) in mlx5e_del_vlan_rules().
Hit in internal regression testing, so kthread creation failed
with -EINTR:
WARNING: CPU: 3 PID: 170 at drivers/net/ethernet/mellanox/mlx5/core/en_fs.c:564 mlx5e_del_vlan_rules+0x295/0x2b0 [mlx5_core]
mlx5e_destroy_flow_steering+0x34/0xc0 [mlx5_core]
mlx5e_init_nic_rx+0x137/0x200 [mlx5_core]
mlx5e_attach_netdev+0x105/0x360 [mlx5_core]
Fix it by creating NIC flow steering with rx_mode_active cleared and
setting it only after profile->init_rx() succeeds. This also lets the
internal error paths of mlx5e_create_flow_steering() destroy partially
created steering without warning. The flag is set in
[11 lines not shown]
net/mlx5e: IPsec, don't match upper proto selectors in crypto offload TX
The mentioned commit introduced support for upper protocol selectors
(protocol & ports) to mlx5 IPsec offload. In crypto offload mode this
causes offloaded TX SAs to stop matching traffic.
In tx_add_rule(), setup_fte_upper_proto_match() is called for all
offload types and programs a match on the upper protocol (TCP/UDP) and
ports. For crypto offload, setup_fte_esp() is then called and sets
ip_protocol to ESP. The resulting rule requires both ESP as the IP
protocol and TCP/UDP ports, which no packet can satisfy, so TX crypto
offload silently stops working for such SAs.
In crypto offload mode the stack builds the ESP packet and the HW only
encrypts it, so the SA rule should only match on the SPI. Move the
setup_fte_upper_proto_match() call under the XFRM_DEV_OFFLOAD_PACKET
case, where the rule matches the plaintext packet and upper protocol
selectors apply.
[11 lines not shown]
tcp: fix request_sock use-after-free during Fast Open accept()
Commit e3d95ad7da4f ("inet: avoid fastopen lock for regular accept()")
made inet_csk_accept() check tfo_listener before taking fastopenq.lock
to avoid taking the lock for connections that did not use Fast Open.
reqsk_fastopen_remove() clears tfo_listener while holding fastopenq.lock,
then reads req->sk. If inet_csk_accept() concurrently observes
tfo_listener after it has been cleared, it skips fastopenq.lock and
drops the last reference to the request_sock. This can free the
request_sock while reqsk_fastopen_remove() is still using it.
If the freed memory is reused for a new request_sock with req->sk ==
NULL, the reset path in reqsk_fastopen_remove() can append the new
request_sock to the original listener's list of requests that caused an
RST. After the new request_sock is freed, the next append writes through
the stale rskq_rst_tail into freed memory.
KASAN reported the following use-after-free when writing
[46 lines not shown]
net: usb: cdc_ncm: don't underflow the NDP room check
cdc_ncm_ndp16() and cdc_ncm_ndp32() verify that the new NDP and the
datagram fit into the NTB with an unsigned subtraction:
if ((ctx->tx_curr_size - skb->len - reserve) < ctx->max_ndp_size)
return NULL;
Nothing guarantees that skb->len plus the reserve stays below
tx_curr_size, and when it does not the subtraction wraps around to a
huge value, the check passes, and the skb_put_zero() of max_ndp_size
bytes that follows overruns the NTB:
skbuff: skb_over_panic: text:ffff80000db33558 len:428 put:172
head:ffff0000c2c66100 tail:0x1ac end:0x140
kernel BUG at net/core/skbuff.c:200
skb_put_zero include/linux/skbuff.h:2595 [inline]
cdc_ncm_ndp16 drivers/net/usb/cdc_ncm.c:1132 [inline]
cdc_ncm_fill_tx_frame+0xdf0/0x30e0 drivers/net/usb/cdc_ncm.c:1309
[33 lines not shown]
net: netns: fix INT_MAX nsid cleanup
A syzkaller reproducer assigning INT_MAX as a peer nsid triggers an
idr_get_next() warning during netns cleanup. With panic_on_warn, this
panics the kernel.
alloc_netid() also overflows reqid + 1 for this nsid. Use
idr_alloc_u32() for requested IDs and idr_get_next_ul() for cleanup so
the cursor can advance past INT_MAX.
QEMU/KVM reproduced the warning without kernel changes or fault
injection. The same reproducer ran without warnings after this change.
Kernel selftests were not run.
Fixes: 7acee67a6bce ("netns: optimize netns cleaning by batching unhash_nsid calls")
Cc: stable at vger.kernel.org
Signed-off-by: Zhao Gongyi <zhaogongyi at bytedance.com>
Link: https://patch.msgid.link/20261111033525.65828-1-zhaogongyi@bytedance.com
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
amt: use ipv6_hdr() in amt_mldv1_leave_handler()
In amt_mldv1_leave_handler(), which handles IPv6 MLDv1 Done
(ICMPV6_MGM_REDUCTION) messages, the source address is mistakenly
extracted via ip_hdr(skb)->saddr into host.ip4 instead of copying the
IPv6 source address from ipv6_hdr(skb)->saddr into host.ip6 as
amt_mldv1_report_handler() does.
Because amt_lookup_group() compares the full union amt_addr for v6
groups, looking up the group with a 32-bit IPv4 header slice fails to
match the group entry created by amt_mldv1_report_handler(). As a
result, amt_del_group() is not called when an MLDv1 listener leaves,
and the AMT relay continues forwarding multicast traffic until the
group timer expires.
Use ipv6_hdr(skb) and copy ip6h->saddr into host.ip6 so that MLDv1
Done messages properly match and delete the corresponding IPv6 group.
This issue was found via LLM-assisted code review, confirmed by
[8 lines not shown]
af_unix: Inherit SO_INQ in unix_stream_connect()
When SO_INQ is enabled on a listening AF_UNIX SOCK_STREAM socket,
accepted sockets created by unix_stream_connect() do not inherit
u->recvmsg_inq from the listener, unlike TCP_INQ, AF_VSOCK SO_INQ,
and AF_UNIX SO_RIGHTS_NOTRUNC. As a result, recvmsg() on the
accepted socket never puts an SCM_INQ control message unless SO_INQ
is set again after accept().
Copy otheru->recvmsg_inq to newu->recvmsg_inq in
unix_stream_connect() using READ_ONCE() to pair with the lockless
WRITE_ONCE() in unix_setsockopt().
Found during LLM-assisted code review of unix_stream_connect() while
comparing option inheritance between SO_INQ and SO_RIGHTS_NOTRUNC.
Confirmed on UML (x86_64) by enabling SO_INQ on a listening AF_UNIX
SOCK_STREAM socket before listen() and accept(), sending data from a
connected client, and observing that recvmsg() on the accepted socket
[12 lines not shown]
tcp: Pass req->rsk_listener to inet_csk_reqsk_queue_drop() in tcp_check_req().
When connection migration happens in tcp_v[46]_rcv(), a new
listener is passed to tcp_check_req().
When either of the following is true,
* the new listener queue is full and
net.ipv4.tcp_abort_on_overflow is set
* the packet has RST or (not stripped) SYN
tcp_check_req() sends RST and calls inet_csk_reqsk_queue_drop().
Here, the new listener is passed, and its qlen is decremented
wrongly while reqsk is tied to the old listener.
Once qlen underflows, inet_csk_reqsk_queue_is_full() always
return true, and the new listener stops serving.
[32 lines not shown]
mailmap: add entries for Hangbin Liu
Add the active email address for Hangbin Liu and map the old or rarely-used
addresses to it. This prevents get_maintainer.pl from listing not actively
used addresses as patch recipients.
Signed-off-by: Hangbin Liu <liuhangbin at kylinos.cn>
Link: https://patch.msgid.link/20261111-mailmap-v1-1-8ab349555808@kylinos.cn
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
Merge branch 'net-virtio-validate-outer-protocol-of-udp-tunnel-gso-packets'
Eric Dumazet says:
====================
net: virtio: validate outer protocol of UDP tunnel GSO packets
virtio_net_hdr_tnl_to_skb() does not check that a UDP tunnel GSO
packet really has outer IPv4/IPv6 and UDP headers matching the
declared tunnel type. A guest, or any tap writer, can send a frame
with another outer ethertype (NSH in the report), and the GSO stack
then builds segments with skb->data before skb->head. The host
crashes in skb_under_panic() as soon as a header is pushed.
Patch 1 fixes the producer side, virtio_net_hdr_tnl_from_skb(), for
VLAN tagged packets:
- the tunnel offsets did not account for the VLAN tag tun inserts in
the frame, and were 4 bytes short.
- the outer family came from skb->protocol, which is the VLAN protocol
[21 lines not shown]
net: virtio: validate outer protocol of UDP tunnel GSO packets
virtio_net_hdr_tnl_to_skb() trusts the virtio header to describe a
UDP tunnel over IPv4 or IPv6, but never checks that the frame actually
carries such outer headers. Because VIRTIO_NET_HDR_F_NEEDS_CSUM is
mandatory for tunnel GSO, __virtio_net_hdr_to_skb() skips the flow
dissector, so virtio_net_hdr_match_proto() is never applied either.
A guest (or a tap writer) can then inject a frame with an arbitrary
outer ethertype, for example ETH_P_NSH, with SKB_GSO_UDP_TUNNEL set.
The GSO stack then runs nsh_gso_segment() on top of the UDP tunnel
segmentation, which assumes a different header layout. The result is
segments with skb->data before skb->head, and a host crash in
skb_under_panic() as soon as a later layer pushes a header:
skbuff: skb_under_panic: ... put:4 ... dev:gretap1
kernel BUG at net/core/skbuff.c:215!
skb_push
__gre_xmit
[36 lines not shown]
tun: clear stale skb->protocol of NAPI frags skbs
With IFF_NAPI_FRAGS, tun_napi_alloc_frags() gets its skb from
napi_get_frags(). If GRO merged the previous frame with
GRO_MERGED_FREE, that skb was recycled by napi_reuse_skb(), which does
not reset skb->protocol set by napi_frags_skb() for the previous frame.
tun_get_user() calls tun_vnet_hdr_tnl_to_skb() before eth_type_trans(),
so the virtio header checks see the protocol of the previous frame:
GSO packets without VIRTIO_NET_HDR_F_NEEDS_CSUM are dissected with the
wrong protocol. A following change checks the outer protocol of UDP
tunnel GSO packets, which would then reject a valid frame when the two
ethertypes differ.
This needs GRO to hold packets across writes, and IFF_NAPI_FRAGS needs
CAP_NET_ADMIN.
Clear skb->protocol in tun_napi_alloc_frags(), like skbs allocated
by tun_alloc_skb() or build_skb(). eth_type_trans() sets it later.
[9 lines not shown]
net: virtio: fix UDP tunnel GSO header of VLAN tagged packets
virtio_net_hdr_tnl_from_skb() builds a wrong header for VLAN tagged UDP
tunnel GSO packets.
1) When the skb carries a hwaccel VLAN tag, tun_put_user() inserts the
802.1Q header in the frame it copies to user space or vhost-net, and
passes vlan_hlen = VLAN_HLEN. virtio_net_hdr_from_skb() adds
vlan_hlen to csum_start, but inner_nh_offset and outer_th_offset do
not account for it, and are 4 bytes short of the real inner L3 and
outer UDP headers in the emitted frame.
tun advertises NETIF_F_HW_VLAN_CTAG_TX and NETIF_F_HW_VLAN_STAG_TX
in hw_enc_features, and its vlan_features keep the UDP tunnel GSO
features, so this happens for example with a VLAN filtering bridge
with a tagged port, or with a vlan device on top of a tap.
2) The outer family comes from skb->protocol, which is ETH_P_8021Q or
ETH_P_8021AD when the VLAN tag is in the packet data, so a packet
[24 lines not shown]
bnxt_en: Take RTNL before netif_close() when aborting FW reset
netif_close() must be called with RTNL held in addition to the netdev
instance lock: __dev_close_many() asserts it, and the NETDEV_GOING_DOWN
and NETDEV_DOWN notifier chains it runs rely on it for serialization.
Commit 004b5008016a ("eth: bnxt: remove most dependencies on RTNL")
replaced rtnl_lock() with netdev_lock() in bnxt_fw_reset_task() and
bnxt_fw_reset(). That is sufficient for the paths that only tear the
NIC down internally with __bnxt_close_nic(), but the abort paths close
the netdev via bnxt_fw_reset_abort() -> netif_close(), and the error
path in bnxt_fw_reset() calls netif_close() directly. Those now run
without RTNL and trigger a WARN_ONCE() cascade when a firmware reset is
aborted:
RTNL: assertion failed at net/core/dev.c (1740)
WARNING: net/core/dev.c:1740 at __dev_close_many+0x1be/0x1f0
Workqueue: bnxt_pf_wq bnxt_fw_reset_task [bnxt_en]
Call Trace:
[48 lines not shown]
Merge tag 'pwrseq-fixes-for-v7.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull power sequencing fixes from Bartosz Golaszewski:
- fix a use-after-free bug and a serdev reference leak in pwrseq-pcie-m2
- increase WCN7850 power-up delay in pwrseq-qcom-wcn
- make the API contract for pwrseq descriptor serialization clearer
* tag 'pwrseq-fixes-for-v7.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
power: sequencing: pcie-m2: fix serdev controller reference leak
power: sequencing: pcie-m2: use devm_mutex_init()
power: sequencing: pcie-m2: fix use-after-free in pwrseq_pcie_m2_vregs_enable()
power: sequencing: core: add a note on descriptor serialization
power: sequencing: qcom-wcn: increase WCN7850 power-up delay
net/mlx5: Lag, Return error when enabling MPESW without LAG support
When firmware reports a function as not LAG capable (lag_master=0 or
num_lag_ports < 2), mlx5_lag_add_mdev() creates no LAG object for it.
Enabling multiport E-Switch on such a device returns 0 from
mlx5_lag_mpesw_queue_work(), so
"devlink dev param set ... esw_multiport value true" reports success
although nothing was enabled, and a following "devlink dev param show"
still reports false.
Return -EOPNOTSUPP instead. mlx5_lag_mpesw_disable() ignores the return
value, so disabling keeps its current behavior.
Fixes: a32327a3a02c ("net/mlx5: Lag, Control MultiPort E-Switch single FDB mode")
Signed-off-by: Uri Dar <udar at nvidia.com>
Reviewed-by: Shay Drori <shayd at nvidia.com>
Signed-off-by: Tariq Toukan <tariqt at nvidia.com>
Reviewed-by: Daniel Machon <daniel.machon at microchip.com>
Link: https://patch.msgid.link/20261110114350.2639891-1-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
udp_tunnel: don't treat IPv4 sockets bound to an address as wildcard
With IPv6 enabled, sk_saddr_any() checks sk_v6_rcv_saddr also for
AF_INET sockets, where it is always zero. An IPv4 tunnel socket bound to
a specific address (e.g. fou or geneve with "local") ends up in the GRO
lookup fast path, although another socket may bind the same port on a
different address: GRO then hands that socket's packets to the tunnel's
gro_receive.
Check the IPv6 address only for AF_INET6 sockets.
Fixes: a36283e2b683 ("udp_tunnel: create a fastpath GRO lookup.")
Signed-off-by: Antonio Quartulli <antonio at mandelbit.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu at google.com>
Link: https://patch.msgid.link/20261110113306.3698438-1-antonio@mandelbit.com
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
Merge branch 'net-dsa-motorcomm-acl-fixup'
David Yang says:
====================
net: dsa: motorcomm: ACL fixup
Various ACL defects. Found by LLM and manually verified (on YT9215).
====================
Link: https://patch.msgid.link/20261110104930.223598-1-mmyangfl@gmail.com
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
