summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2 daystcp: fix request_sock use-after-free during Fast Open accept()Hyunwoo Kim
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 fastopenq->rskq_rst_tail->dl_next = req: BUG: KASAN: slab-use-after-free in reqsk_fastopen_remove+0x142/0x210 Write of size 8 at addr ffff888108230688 by task swapper/5/0 ... Call Trace: <IRQ> ... reqsk_fastopen_remove+0x142/0x210 tcp_check_req+0x96f/0xdd0 ... tcp_rcv_state_process+0x19c/0x26b0 ... tcp_v4_do_rcv+0x16e/0x490 tcp_v4_rcv+0x14a0/0x1af0 ... ip_protocol_deliver_rcu+0x39/0x1e0 ip_local_deliver_finish+0x124/0x1e0 ip_local_deliver+0xfb/0x1e0 ... </IRQ> To widen the race windows, mdelay(5) was added after newsk = req->sk, mdelay(20) after the if (req) reqsk_put(req) block, and mdelay(100) after tcp_rsk(req)->tfo_listener = false. The KASAN report above was reproduced with this kernel. For the lockless check, use tcp_sk(newsk)->syn_fastopen_child instead of tfo_listener, which reqsk_fastopen_remove() clears. syn_fastopen_child is a field of the Fast Open child TCP socket referenced by newsk, not of the request_sock. It is set before the child socket is added to the accept queue. The paths that call reqsk_fastopen_remove() in response to a remote ACK or RST do not clear this field. inet_csk_accept() uses this field to take fastopenq.lock only for Fast Open child sockets and rechecks tfo_listener while holding the lock. Connections that did not use Fast Open continue to avoid the lock. Fixes: e3d95ad7da4f ("inet: avoid fastopen lock for regular accept()") Cc: stable@vger.kernel.org Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/avQKA_YTAThtbsYU@v4bel Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 daysnet: usb: cdc_ncm: don't underflow the NDP room checkJiahao Xu
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 Here tx_curr_size is 0x140 = 320, skb->len is already 256 and the skb_put_zero() wants another 172 bytes. Two device controlled settings make this reachable: - dwNtbOutMaxSize = 320 caps tx_max at 320. The lower bound computed in cdc_ncm_check_tx_max() is max_datagram_size + max_ndp_size + the NTH header, but cdc_ncm_setup() clamps tx_max before cdc_ncm_set_dgram_size() runs, so max_datagram_size is still 0 and the bound is only max_ndp_size + the NTH header. It does not reserve room for one datagram plus one NDP. - wNdpOutAlignment = 256 is accepted by cdc_ncm_fix_modulus() as long as it is smaller than tx_max, and cdc_ncm_align_tail() then pads the 12 byte NTH header up to 256 bytes right before this check. An NDP can also be added to an NTB that already holds datagrams through cdc_mbim_tx_fixup(), which uses a different signature per MBIM session. On plain cdc_ncm the chain lookup in cdc_ncm_ndp16() returns the existing NDP for the single signature, so there the create path is normally reached for the first datagram of each NTB. Rewrite the test as an addition, which cannot underflow and gives the same answer whenever the original subtraction did not wrap. Fixes: c78b7c586657 ("net: cdc_ncm: refactoring for tx multiplexing") Fixes: 0fa81b304a79 ("cdc_ncm: Implement the 32-bit version of NCM Transfer Block") Reported-by: syzbot+1994e2ecf323ed90f255@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1994e2ecf323ed90f255 Signed-off-by: Jiahao Xu <xujiahao@cmss.chinamobile.com> Link: https://patch.msgid.link/20261111124156.637661-1-xujiahao@cmss.chinamobile.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 daysnet: netns: fix INT_MAX nsid cleanupZhao Gongyi
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@vger.kernel.org Signed-off-by: Zhao Gongyi <zhaogongyi@bytedance.com> Link: https://patch.msgid.link/20261111033525.65828-1-zhaogongyi@bytedance.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 daysamt: use ipv6_hdr() in amt_mldv1_leave_handler()Wenbo Sun
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 reproducing the stale group forwarding in a User-Mode Linux (ARCH=um) environment, and verified in UML by testing that AMT relay multicast forwarding stops immediately after receiving an MLDv1 Done message. Fixes: b75f7095d4d4 ("amt: add mld report message handler") Signed-off-by: Wenbo Sun <sunwenbo@cmss.chinamobile.com> Link: https://patch.msgid.link/20261111031147.105834-1-sunwenbo@cmss.chinamobile.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 daysaf_unix: Inherit SO_INQ in unix_stream_connect()Wenbo Sun
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 returned no SCM_INQ control message. Tested on UML (x86_64) against the reproducer, verifying that recvmsg() on the accepted socket now returns the expected SCM_INQ control message, and ran the tools/testing/selftests/net/af_unix/scm_inq selftest (all 6 test cases passed). Fixes: df30285b3670 ("af_unix: Introduce SO_INQ.") Signed-off-by: Wenbo Sun <sunwenbo@cmss.chinamobile.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20261111023222.77227-1-sunwenbo@cmss.chinamobile.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 daystcp: Pass req->rsk_listener to inet_csk_reqsk_queue_drop() in tcp_check_req().Kuniyuki Iwashima
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. Without the patch, this script times out while waiting for SYN+ACK since the new listener drops SYN, but with the patch, 3WHS completes. 0 `sysctl -q net.ipv4.tcp_migrate_req=1` +0 `sysctl -q net.ipv4.tcp_syncookies=0` +0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 4 +0 setsockopt(4, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0 +0 bind(4, ..., ...) = 0 +0 listen(4, 128) = 0 +0 < S 0:0(0) win 32792 <mss 1000> +0 > S. 0:0(0) ack 1 <...> +0 listen(3, 128) = 0 +0 close(4) = 0 +.01 < R 1:1(0) win 0 +0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 5 +0 listen(5, 1) = 0 +.01 < S 0:0(0) win 32792 <mss 1000> +0 > S. 0:0(0) ack 1 <...> +0 < . 1:1(0) ack 1 win 32792 +0 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 +0 accept(3, ..., ...) = 6 Let's pass req->rsk_listener instead. Fixes: d4f2c86b2b7e ("tcp: Migrate TCP_NEW_SYN_RECV requests at receiving the final ACK.") Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20261111020304.1532064-2-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 daysmailmap: add entries for Hangbin LiuHangbin 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@kylinos.cn> Link: https://patch.msgid.link/20261111-mailmap-v1-1-8ab349555808@kylinos.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 daysALSA: usb-audio: Add native DSD support for NiceHCK OctaveShengyu Qu
NiceHCK Octave is an OEM of TTGK TT39039F01-PROMAX[1] and supports DSD64/ DSD128/DSD256/DSD512[2]. It advertises the UAC2 RAW_DATA format on altsetting 4 of its playback interface, but without the DSD_RAW quirk flag the driver exposes it only as a SPECIAL format that cannot be used. Add QUIRK_FLAG_DSD_RAW for the device (USB ID 3302:39c3), so the altsetting is exposed as DSD_U32_BE, enabling native DSD playback. [1] https://www.audiosciencereview.com/forum/index.php?threads/nicehck-octave-dongle-dac.65535/post-2390027 [2] https://szttgk.com/product/HIFIAUDIOMODULE/846.html Signed-off-by: Shengyu Qu <wiagn@4d2.org> Link: https://patch.msgid.link/20261112173131.86655-1-wiagn@4d2.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
2 daysMerge branch 'net-virtio-validate-outer-protocol-of-udp-tunnel-gso-packets'Jakub Kicinski
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 when the tag is in the packet data, so an outer IPv6 header was reported as IPv4. Without it, patch 3 would drop such packets. Kernels without this fix still send such headers, so it should go to stable along with patch 3. Patch 2 clears a stale skb->protocol left on recycled NAPI frags skbs, which could make the checks of patch 3 reject valid frames. Patch 3 validates the outer headers, using the parsing helpers from Michael's series "net: resolve uncommon partial checksums at ingress", as Willem suggested. The callers tell whether frames start with an Ethernet header, as the device type of a tun device can be changed with TUNSETLINK. The rest of Michael's series (checksum validation and completion) is left to him. The selftests of v3 will follow in a separate series, with the fixes Sashiko found in them. ==================== Link: https://patch.msgid.link/20261110213628.3476051-1-edumazet@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 daysnet: virtio: validate outer protocol of UDP tunnel GSO packetsEric Dumazet
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 gre_tap_xmit ... tun_get_user Validate the outer headers with the parsing helpers from Michael's series "net: resolve uncommon partial checksums at ingress": - locate the L3 header: Ethernet with optional VLAN tags, or the network header set by the caller. skb->protocol is not trusted when it disagrees with the frame. - require the outer L3 protocol to match the declared tunnel type. - require the outer UDP header exactly at outer_th_offset, after IPv4 options or IPv6 extension headers, and reject fragments. Unlike the original helpers: - the callers tell whether the frame starts with an Ethernet header, with a new has_eth argument of virtio_net_hdr_tnl_to_skb(), instead of using the device type. tun frames packets from its IFF_TAP and IFF_TUN flags, and TUNSETLINK can set the device type to any value. virtio_net and tun_xdp_one() always pass true, tun_get_user() passes whether the device is IFF_TAP. - ipv6_find_hdr() stops at an AH header, as Willem suggested in the review of that series. Fixes: a2fb4bc4e2a6 ("net: implement virtio helpers to handle UDP GSO tunneling.") Reported-by: Hassan Sultan <hassansultan@google.com> Suggested-by: Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/netdev/93d0e37c99711bebdf60c120af03010455c2f2e2.1793276116.git.mst@redhat.com/ Co-developed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Eric Dumazet <edumazet@kernel.org> Link: https://patch.msgid.link/20261110213628.3476051-4-edumazet@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 daystun: clear stale skb->protocol of NAPI frags skbsEric Dumazet
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. Fixes: 90e33d459407 ("tun: enable napi_gro_frags() for TUN/TAP driver") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/netdev/179386753589.488856.11455181721004759454@kernel.org/ Suggested-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Eric Dumazet <edumazet@kernel.org> Link: https://patch.msgid.link/20261110213628.3476051-3-edumazet@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 daysnet: virtio: fix UDP tunnel GSO header of VLAN tagged packetsEric Dumazet
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 with an outer IPv6 header is reported as VIRTIO_NET_HDR_GSO_UDP_TUNNEL_IPV4. This happens when __vlan_hwaccel_push_inside() inserted the tag because the device does not offload it: virtio_net never offloads VLAN insertion but keeps UDP tunnel GSO in its vlan_features, and tun does the same with VLAN TX offload disabled, or with QinQ (outer tag offloaded, inner tag in the data). The receiver sets inner_network_header and transport_header from these offsets, and checks them with the wrong outer family. A forwarded packet that gets segmented again uses the wrong inner headers, and a receiver checking the outer headers against the virtio header drops the packet. Add vlan_hlen to both offsets like csum_start, and take the outer family from vlan_get_protocol(), which skips VLAN tags in the data. Fixes: a2fb4bc4e2a6 ("net: implement virtio helpers to handle UDP GSO tunneling.") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/netdev/179421814766.994134.3669228181251158303@kernel.org/ Closes: https://lore.kernel.org/netdev/179433950084.994134.15100186606737698605@kernel.org/ Signed-off-by: Eric Dumazet <edumazet@kernel.org> Link: https://patch.msgid.link/20261110213628.3476051-2-edumazet@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 daysarm64/gcs: Ignore attempts to change GCS mode during signal returnMark Brown
If userspace tries to update the GCS mode as part of signal return then we update the thread state but don't update GCSCRE0_EL1, meaning the change does not take effect. We may also get issues for other tasks on context switch since we suppress writes of the register if the two tasks have the same mode. Since no currently known userspace tries to use this functionality close this by ignoring any attempt to change the mode through signal return. The GCS mode for the current thread can be changed using the prctl() interface and will be preserved on signal return, allowing updates to the mode from the signal handler. Reported-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/as-8IqsbMbOBo5Oq@arm.com Suggested-by: Catalin Marinas <catalin.marinas@arm.com> Fixes: 16f47bb9ac8a ("arm64/signal: Expose GCS state in signal frames") Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2 daysbnxt_en: Take RTNL before netif_close() when aborting FW resetBryan Cochrane
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: netif_close_many+0xb5/0x190 netif_close+0xa2/0xd0 bnxt_fw_reset_task.cold+0x8d/0x213 [bnxt_en] process_one_work+0x19d/0x3a0 worker_thread+0x1af/0x320 kthread+0xe3/0x120 followed by the same assertion from call_netdevice_notifiers_info(), fib_rules_event(), inetdev_event(), rtnl_fill_ifinfo(), devlink_compat_phys_port_name_get() and ip_mc_down(). This was observed on a machine in real use with a BCM57504 (4 PFs, FW 236.1.153.0) running v7.1.6: the firmware crashed, announced a "Fatal firmware reset event" and then failed to come back within the advertised max wait, so bnxt_fw_reset_task() aborted the reset on all ports: bnxt_en 0000:c1:00.1 eno16905np1: Firmware reset aborted bnxt_en 0000:c1:00.1 eno16905np1: fw_health_status 0x448100 Take RTNL (before the netdev instance lock, matching the OPENING state which already uses rtnl_trylock()) in the fw_reset_abort path of bnxt_fw_reset_task() and route the POLL_VF abort through that same path. In bnxt_fw_reset(), only a PF can reach the bnxt_get_registered_vfs() error path that calls netif_close(), so take RTNL up front via bnxt_rtnl_lock_sp() when BNXT_PF(bp) is true and keep bnxt_lock_sp() on VFs. That avoids dropping the instance lock mid-reset (which would expose a transient BNXT_STATE_IN_FW_RESET and let a concurrent devlink health recover set BNXT_STATE_IN_SP_TASK), avoids racing with bnxt_sriov_configure() updating active_vfs outside RTNL, and keeps VFs from contending on RTNL during recovery while PFs already run on the single-threaded bnxt_pf_wq. The bug was found by inspecting the kernel log of the affected machine and the driver source; the fix was prepared with the help of an AI coding assistant (Gemini based) and reviewed by the submitter. It is build tested (allmodconfig with W=1, plus the same change on top of v7.1.6 built as a module for the affected BCM57504 host). The aborted reset path itself only runs when the firmware fails to return from a reset, which could not be reproduced on demand. Fixes: 004b5008016a ("eth: bnxt: remove most dependencies on RTNL") Cc: stable@vger.kernel.org Signed-off-by: Bryan Cochrane <bcochrane@google.com> Link: https://patch.msgid.link/20261110044235.204386-1-bcochrane@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 daysMerge tag 'pwrseq-fixes-for-v7.4-rc3' of ↵Linus Torvalds
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
2 daysnet/mlx5: Lag, Return error when enabling MPESW without LAG supportUri Dar
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@nvidia.com> Reviewed-by: Shay Drori <shayd@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20261110114350.2639891-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 daysudp_tunnel: don't treat IPv4 sockets bound to an address as wildcardAntonio Quartulli
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@mandelbit.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20261110113306.3698438-1-antonio@mandelbit.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 daysMerge branch 'net-dsa-motorcomm-acl-fixup'Jakub Kicinski
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@kernel.org>
2 daysnet: dsa: motorcomm: Delete the ACL rule of the port being unboundDavid Yang
A flower filter on a block shared across ports is offloaded as one hardware rule per port, all carrying the same classifier cookie. Deletion looked a rule up by cookie alone and could take another port's copy: with skip_sw, a filter silently stopped being enforced on a still-bound port, while the detached port kept enforcing it. Delete the rule matching the port being unbound instead. Fixes: 8eb9e7520b17 ("net: dsa: yt921x: Add ACL support") Signed-off-by: David Yang <mmyangfl@gmail.com> Link: https://patch.msgid.link/20261110104930.223598-4-mmyangfl@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 daysnet: dsa: motorcomm: Resolve the flower action list to one ACL verdictDavid Yang
The hardware resolves one forward decision per ACL rule, but the translation accumulated every action, so a later action silently changed the verdict of the ones before it: an `action drop action trap` filter with skip_sw trapped packets to the CPU instead of dropping them. Resolve the list against its first terminal action, and ask for software assistance if any action follows the redirect action. Fixes: 8eb9e7520b17 ("net: dsa: yt921x: Add ACL support") Signed-off-by: David Yang <mmyangfl@gmail.com> Link: https://patch.msgid.link/20261110104930.223598-3-mmyangfl@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 daysnet: dsa: motorcomm: Fix extack message on unsupported TC actionsDavid Yang
No extack reasons were given to unsupported TC actions. Set a reason on the default path before falling back, and drop the now-redundant initializer of `reason`, so the compiler warns on any future path that uses it without assigning one. Fixes: 8eb9e7520b17 ("net: dsa: yt921x: Add ACL support") Signed-off-by: David Yang <mmyangfl@gmail.com> Link: https://patch.msgid.link/20261110104930.223598-2-mmyangfl@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 daysnet/mlx5e: kTLS, Fix missing error unwind when enabling RX offloadXuanqiang Luo
Since commit abed42f9cd80 ("net/mlx5e: Conditionally create async ICOSQ"), the async ICOSQ is only created when an XDP program is attached or priv->ktls_rx_was_enabled is set. When TLS RX offload is enabled for the first time, mlx5e_ktls_set_feature_rx() sets the flag and reopens the channels so that they get the queue, but it ignores the return value of mlx5e_safe_reopen_channels(). If the reopen fails, mlx5e_safe_switch_params() keeps the old channels, which have no async ICOSQ, while NETIF_F_HW_TLS_RX is still reported as enabled. The next offloaded RX connection then dereferences the NULL c->async_icosq in post_rx_param_wqes(). Enabling the feature again does not help, as the flag is already set and the reopen is skipped. Propagate the error, clear the flag and destroy the accel TCP flow tables again, so that the feature stays disabled and the next attempt retries the reopen. Fixes: abed42f9cd80 ("net/mlx5e: Conditionally create async ICOSQ") Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20261110101709.2589088-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 daysMerge tag 'gpio-fixes-for-v7.4-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio fixes from Bartosz Golaszewski: "To no surprise, this batch was mostly driven by issues found by LLMs (notably: sashiko) during reviews of other changes. This is why it's bigger than what I normally send at this stage. Fixes in GPIO core: - fix a race in shared GPIO descriptor release path - fix several issues in gpio-shared-proxy: race between concurrent initial users, dropping votes in error paths and driving the default value with no votes cast - fix stack out-of-bounds access bugs in GPIO hog handling - fix a race in GPIO descriptor consumer label update - reset lookup flags on each hogged line - fix GPIO descriptor leak and fast-path cancellation in gpiod_get_array() - fix return value in of_gpiochip_instance_match() stub for !CONFIG_OF - fix potential misconfiguration of flags for hogged lines on OF systems - fix a reference leak in deferred GPIO controller setup error path Fixes in GPIO drivers: - fix interrupt handling bugs in gpio-aspeed - fix an interrupt leak and two UAF bugs in gpio-virtuser - fix a UAF bugs in gpio-sodaville, gpio-mpc8xxx and gpio-brcmstb - fix a sleeping-while-atomic bug in gpio-mvebu - reject unsupported interrupt types in gpio-mpfs - fix an irqchip leak in gpio-regmap helper - fix debounce arithmetic in gpio-rockchip - propagate runtime PM failures in gpio-omap - defer GPIO chip registration to postcore_initcall() in gpio-sa1100" * tag 'gpio-fixes-for-v7.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: (26 commits) gpiolib: fix stack out-of-bounds access in gpiochip_add_hog() gpio: shared: fix a race in shared desc release path gpio: sodaville: fix use-after-free bug when registering the irqchip gpio: virtuser: fix interrupt leak and UAF gpio: mvebu: fix sleeping-while-atomic in mvebu_gpio_level_irq_mask() gpiolib: synchronize updates of descriptor labels gpiolib: of: return -ENOENT from of_gpio_count() stub gpiolib: fix fast-path cancellation in gpiod_get_array() gpiolib: fix GPIO descriptor leak in gpiod_get_array() gpio: of: fix potential misconfiguration of hogged lines gpio: mpfs: reject unsupported interrupt types gpio: keep the chip reference when deferred setup fails gpio: regmap: free the irqchip if adding the irq domain fails gpio: aspeed: Preserve the pending G7 interrupt status on control writes gpio: aspeed: Clear only the acked line's G4 interrupt status gpiolib: reset lookup flags for each hogged line gpio: virtuser: remove the debugfs files before freeing the line data gpio: mpc8xxx: Fix potential use-after-free of IRQ domain gpio: shared-proxy: Drop the vote when switching to input gpio: shared-proxy: Drive the default value when no votes are cast ...
2 daysgtp: free the skb after handling an echo responseJoas Antonio dos Santos
gtp0_handle_echo_resp() and gtp1u_handle_echo_resp() return the result of genlmsg_multicast_netns() to gtp_encap_recv(). When the netlink notification is delivered that result is 0, and gtp_encap_recv() treats 0 as "the skb has been consumed": switch (ret) { case 1: netdev_dbg(gtp->dev, "pass up to the process\n"); break; case 0: break; case -1: netdev_dbg(gtp->dev, "GTP packet has been dropped\n"); kfree_skb(skb); ret = 0; break; } The echo response handlers only read from the skb and never free it or pass it on, so every echo response that is reported to a listener on the gtp multicast group leaks the skb. Echo responses are handled for any peer when the UDP sockets were created by the kernel, so a remote host can leak memory on the receiver by sending GTP echo responses while a process with CAP_NET_ADMIN is subscribed to the gtp multicast group, for example a daemon that monitors echo responses. The error paths do not leak but have a related problem. -ENOMEM and the error from genlmsg_multicast_netns() (-ESRCH when nobody listens) are not -1, so they are returned unchanged to the UDP stack, which takes a negative value from encap_rcv() as a request to resubmit the packet to the protocol with that number. Return -1 when the notification cannot be built, so that gtp_encap_recv() drops the skb, and consume the skb once the notification has been handed to netlink, whether or not anybody is listening. Found by LLM-assisted source review, untested. Fixes: d33bd757d362 ("gtp: Implement GTP echo request") Cc: stable@vger.kernel.org Signed-off-by: Joas Antonio dos Santos <joasantonio108@gmail.com> Link: https://patch.msgid.link/20261110-gtp-echo-rsp-leak-v1-1-192c032f3dfa@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 daysMerge branch 'ice-dpll-fix-updates-of-the-synce-cgu-registers-on-e825'Jakub Kicinski
Ivan Vecera says: ==================== ice: dpll: fix updates of the SyncE CGU registers on E825 All E825C PFs share the CGU registers R10 and R11, which hold the mux and the divider of the two recovered clock outputs. Both patches fix how a link change updates them, both found in review: - Patch 1 adds a lock shared by all PFs around the read-modify-write sequences of these registers. A link change on one PF could undo an RCLK pin change made by another PF. - Patch 2 lets a link change set the divider of an output only when its port drives that output. Every port set it from its own link speed, which is wrong when ports run at different speeds. Both were tested on GNR-D with dual complex E825, details are in the commit messages. Patch 1 was also patch 2 of the net-next series "dpll: do not serialize driver callbacks under global dpll_lock" [1], which needs it. v2 of that series will drop it. [1] https://lore.kernel.org/netdev/20261106121005.1327603-1-ivecera@redhat.com/ ==================== Link: https://patch.msgid.link/20261110094350.184185-1-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 daysice: dpll: set the SyncE divider only for the port driving the outputIvan Vecera
R10 holds one divider for each recovered clock output, shared by all ports. ice_ptp_link_change() sets it from the link speed of its own port even when another port drives the output, and checks the mux only to decide whether an error is worth reporting. With ports running at different speeds, a link change on one port leaves the output of another port with a wrong divider. Skip the outputs that the port does not drive, and check the mux under cgu_synce_lock, so that another PF cannot select its port in between. The check computes the mux value as port % ports_per_phy + 3, while ice_tspll_cfg_bypass_mux_e825c() and ice_dpll_rclk_update_e825c() use port + 3. With the skip, a port from ports_per_phy up would never update the divider, so use port + 3 as they do. Tested on GNR-D with dual complex E825. With the RCLK pin of one port connected, five down and up cycles of another port of the same complex called ice_tspll_cfg_synce_ethdiv_e825c() 20 times without this patch and never with it. Five cycles of the port driving the output still called it 10 times. Both ports ran at 25 Gb/s, so the divider value did not change on this setup. Fixes: ad1df4f2d591 ("ice: dpll: Support E825-C SyncE and dynamic pin discovery") Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Petr Oros <poros@redhat.com> Link: https://patch.msgid.link/20261110094350.184185-3-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 daysice: dpll: serialize changes of the SyncE CGU registersIvan Vecera
All E825C PFs share the CGU registers R10 and R11. On dual complex E825 the second complex reaches the CGU of complex 0 through cgu_peer. RCLK pin callbacks read, modify and write these registers under dpll_lock and the pf->dplls.lock of their PF. ice_ptp_link_change() rewrites R10 under the pf->dplls.lock of its PF only, so a link change on one PF can write back a stale R10 and undo an RCLK pin change made by another PF. Add a mutex to struct ice_adapter, which all E825C PFs share, and hold it around these sequences. Tested on GNR-D with dual complex E825, with a 2 to 4 ms delay after the read of R10 in the link change path to widen the window. Toggling the RCLK pin of one port while another port of the same complex went down and up 143 times lost 120 of 86814 updates of the mux in R10 without this patch, and none of 76992 with it. Fixes: ad1df4f2d591 ("ice: dpll: Support E825-C SyncE and dynamic pin discovery") Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Petr Oros <poros@redhat.com> Link: https://patch.msgid.link/20261110094350.184185-2-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 daysMerge tag 'acpi-7.4-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fixes from Rafael Wysocki: "These fix a mistake in the ACPI APEI GHES code causing recoverable CPU, memory, CXL and vendor-specific errors reported through GHES to never show up in a vmcore, address a potential deadlock related to ACPI device hotplug that causes lockdep to complain and give up, and fix up the recently added support for _Ixx GPEs: - Make recoverable CPU, memory, CXL and vendor-specific errors reported through GHES show up in vmcores by fixing a broken error severity check in ghes_log_hwerr() (Breno Leitao) - Avoid printing diagnostic messages for ACPI device objects after dropping reference to them (Sasha Levin) - Avoid holding the physical_node_lock for ACPI device objects across device_offline() and device_online() due to a potential deadlock that causes lockdep to complain and turn itself off (Sasha Levin) - Avoid spurious system wakeups from suspend-to-idle on platforms where an _Ixx GPE is shared by user-wakeup and background events (Saranya Gopal)" * tag 'acpi-7.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: s2idle: Handle shared _Ixx GPEs without an EC ACPI: APEI: GHES: Fix severity check in ghes_log_hwerr() ACPI: scan: Do not hold physical_node_lock across device_offline() and device_online() ACPI: scan: Print the offline failure message in acpi_bus_offline()
2 daysMerge tag 'pm-7.4-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fixes from Rafael Wysocki: "These address a few issues in the cpufreq core and drivers, including issues actually seen in the field, a few issues related to runtime PM, including a false-positive warning introduced relatively recently and a long-standing defect in the runtime PM core code related to autosuspend, and revert a problematic recent update of the intel_rapl power capping driver. Specifics: - Revert a recent update of the intel_rapl power capping driver that caused perf to return bogus values (Dennis Chen) - Fix the synchronization of boost state updates in cpufreq (Christian Loehle) - Fix issues related to system suspend-resume synchronization in the cpufreq core and intel_pstate driver (Rafael Wysocki) - Fix P-state index mismatch in extract_io() in the ACPI cpufreq driver on systems with defective _PSS (Li RongQing) - Fix issues related to target frequency caching in cpufreq (Rafael Wysocki) - Prevent a false-positive warning in pm_runtime_remove() introduced by a previous fix during the 7.0 development cycle (Zhou Minqiang) - Extend a recent improvement related to the handling of suppliers during device runtime-suspend to some previously missed cases in which it is relevant for consistency (Brian Norris) - Update runtime PM documentation to reflect new behavior after recent changes (Stanley Jhu) - Add last_busy timestamp updates for devices requested to resume from runtime suspend that are missing if those devices are not actually suspended (Rafael Wysocki)" * tag 'pm-7.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: Revert "powercap: intel_rapl: Expose all package CPUs in PMU cpumask" PM: runtime: Update last_busy in rpm_resume() for active devices cpufreq: Fix updates of cached resolved frequency and index cpufreq: Cache post-resolution target frequency in __resolve_freq() cpufreq: acpi-cpufreq: fix P-state index mismatch in extract_io() cpufreq: Serialize global boost updates cpufreq: Preserve global boost state on failed updates PM: runtime: Update runtime_pm.rst for non-fatal resume errors PM: runtime: Only queue an idle check for RPM-linked suppliers (part 2) PM: runtime: Fix check_flush_dependency warning from pm_runtime_remove cpufreq: intel_pstate: Use rdmsrq_safe() to read MSR_MISC_PWR_MGMT cpufreq: intel_pstate: Clear last written P-state value on suspend cpufreq: Force passing target frequency to driver during resume cpufreq: Improve suspend-resume synchronization cpufreq: Hold the policy write lock when changing boost state
2 daysMerge tag 'rust-fixes-7.4-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux Pull Rust fix from Miguel Ojeda: - Fix build error in the upcoming Rust 1.100 when using an AutoFDO profile by supporting the stabilized name for 'profile-sample-use' * tag 'rust-fixes-7.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: kbuild: rust: support stabilized flag `-Cprofile-sample-use` for Rust >= 1.100
2 daysMerge tag 'tpm-v7.4-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd Pull TPM fixes from Jarkko Sakkinen: - Add the missing check of the return value of crypto_kpp_set_secret() when creating an authenticated HMAC session - Check the payload size of EVENT_TAG entries before reading them, in order to avoid out-of-bounds reads with a truncated TPM 1.x event log - Flush the timeout work outside buffer_mutex in tpm_common_read(), as the work itself takes the same mutex, which can lead to a deadlock - Fix a memory leak of the event log buffer in the error path of tpm_read_log_acpi() * tag 'tpm-v7.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd: tpm: acpi: Fix memory leak at tpm_read_log_acpi() error path tpm: flush timeout work outside buffer_mutex to avoid deadlock tpm: eventlog: check the payload size before reading tag events tpm: Check return value of crypto_kpp_set_secret()
3 daysvsock/virtio: clear vqs[] to avoid a UAF on a failed PM restoreJerome Mohm
virtio_vsock_vqs_del() frees the virtqueues but leaves vsock->vqs[] pointing at them. If virtio_vsock_restore() then fails, the driver stays bound with a dangling vqs[], and the next freeze or unbind passes a freed virtqueue to virtqueue_detach_unused_buf(): BUG: KASAN: slab-use-after-free in virtqueue_detach_unused_buf virtio_vsock_vqs_del (net/vmw_vsock/virtio_transport.c:785) virtio_vsock_remove Freed by task ...: vp_del_vqs virtio_vsock_freeze Clear vqs[] after del_vqs() and when virtio_find_vqs() fails. Return early from virtio_vsock_vqs_del() when vqs[] is empty: the detach loops would pass NULL to virtqueue_detach_unused_buf(), and a second del_vqs() would free virtio-mmio's IRQ again, which only WARNs in free_irq() ("Trying to free already-free IRQ"). Found with the help of Anthropic's Claude and reproduced on virtio-pci and virtio-mmio by failing the restore with failslab, without other kernel changes; the virtio-mmio WARN was found by the netdev Sashiko review and reproduced with v1 of this patch. With this patch neither report appears on virtio-pci or virtio-mmio guests, and the vsock vmtest.sh single-VM tests pass. A find_vqs() failure after some virtqueues were set up was not exercised. Fixes: bd50c5dc182b ("vsock/virtio: add support for device suspend/resume") Cc: stable@vger.kernel.org Signed-off-by: Jerome Mohm <jrmmhm.kernel@eldare.de> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Link: https://patch.msgid.link/20261109-vsock-restore-uaf-send-v4-1-1df8dfb5d5de@eldare.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 daysnet: mana: report RX checksum offload for IPv6Hamza Mahfooz
The hardware validates TCP and UDP checksums for both IPv4 and IPv6 and reports the result in rx_tcp_csum_succeed and rx_udp_csum_succeed. However, mana_rx_skb() also requires rx_iphdr_csum_succeed before it sets CHECKSUM_UNNECESSARY. That bit is only set for IPv4 (since IPv6 has no header checksum), so IPv6 TCP and UDP traffic is always checksummed again in software. So, only look at the L4 result. For IPv4 this makes no material difference since CHECKSUM_UNNECESSARY only covers the L4 checksum, and ip_rcv_core() always verifies the IPv4 header checksum in software. Between two Azure Standard_E16s_v6 VMs (VF enabled), IPv6 TCP and UDP packets (including VXLAN over IPv6), now arrive with CHECKSUM_UNNECESSARY instead of CHECKSUM_NONE, so GRO no longer checksums them in software. Calls to __skb_gro_checksum_complete() on the receiver during an 8 second iperf3 run: before after TCP/IPv4, 12.2 Gbps 23 28 TCP/IPv6, 12.1 Gbps 8728419 25 UDP/IPv6, 1.5 Gbps 1071380 20 TCP/VXLAN/IPv6, 10.9 Gbps 7934373 18 Cc: stable@vger.kernel.org Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> Link: https://patch.msgid.link/20261109142856.779955-1-hamzamahfooz@linux.microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 daysselftests: net: exercise SO_MARK on connected socketsXia Yan
cmsg_so_mark.sh sends to explicit destinations, so it does not test the route cached by connect(). Add -k to cmsg_sender to connect first and send without msg_name. Check connected IPv4 and IPv6 UDP, ping and raw sockets with equal, prohibited and zero per-message marks. Add an exact mark 0 prohibit rule before the connected cases. Connect with an allowed socket mark, then require rejection of a mark 0 cmsg. The same test fails four IPv6 cases before the kernel fix and passes all 54 with it. Signed-off-by: Xia Yan <yanxia@cmss.chinamobile.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20261109014400.9025-2-yanxia@cmss.chinamobile.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 daysipv6: fix cached route reuse for control messagesXia Yan
A connected IPv6 UDP or ping socket can reuse its cached route when an SO_MARK cmsg requests another mark. A packet can then bypass a prohibit rule instead of failing with EACCES. ip6_sk_dst_lookup_flow() reads the cache even when connected is false. UDP clears connected after parsing IP or socket control messages. Ping always passes false. Only read the cache when connected is true. Ordinary connected UDP sends keep using the cache. Ping sends do a fresh lookup. Found during code review of IPv6 UDP route caching. On UML, the same connected-socket selftest fails four IPv6 cases before the fix and passes all 54 with it. Fixes: c6af0c227a22 ("ip: support SO_MARK cmsg") Suggested-by: Willem de Bruijn <willemdebruijn.kernel@gmail.com> Link: https://lore.kernel.org/netdev/willemdebruijn.kernel.1e0038bcc3ef8@gmail.com/ Cc: stable@vger.kernel.org Signed-off-by: Xia Yan <yanxia@cmss.chinamobile.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20261109014400.9025-1-yanxia@cmss.chinamobile.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 dayss390/dasd: Don't trust userspace-supplied result field in format checkStefan Haberland
BIODASDCHECKFMT used to copy the entire format_check_t struct from userspace, including the result/unit/rec/num_records/blksize/ key_length fields that are output fields only. dasd_eckd_format_evaluate_tracks() relies on cdata->result being zero to decide whether to apply an index correction (i--/pos--) after a successful check. A caller that pre-sets result to a non-zero value can suppress that correction, leaving pos advanced past the last valid entry; the (partially out-of-bounds) fmt_buffer[pos] fields are then copied back to userspace, leaking heap contents. Only expect is an Input field; copy just that member in and zero the rest of cdata. Fixes: 8fd575200db5 ("s390/dasd: Add new ioctl BIODASDCHECKFMT") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260722103704.1709668-1-sth@linux.ibm.com Cc: stable@vger.kernel.org #4.7 Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com> Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Link: https://patch.msgid.link/20261112102608.1057852-5-sth@linux.ibm.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
3 dayss390/dasd: Fix wrong free and refcount leak in build_check_tcw error pathStefan Haberland
dasd_eckd_build_check_tcw() allocates its request with dasd_fmalloc_request(), but its out_err path frees it with dasd_sfree_request(). The latter uses a different pool and therefor, leading to invalid pointer arithmetic and a crash. Use the matching dasd_ffree_request() instead. The same error path also leaves start_priv->count incremented without ever decrementing it again. This leaks a permanent reference on every build failure. Decrement it before freeing the request. Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260722103704.1709668-1-sth@linux.ibm.com Fixes: 8fd575200db5 ("s390/dasd: Add new ioctl BIODASDCHECKFMT") Cc: stable@vger.kernel.org #4.7 Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com> Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Fixes: 5e2b17e712cf ("s390/dasd: Add dynamic formatting support for ESE volumes") Link: https://patch.msgid.link/20261112102608.1057852-4-sth@linux.ibm.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
3 dayss390/dasd: Re-initialize RCD buffer with "V1.0" before every startStefan Haberland
Under z/VM the Read Configuration Data (RCD) buffer has to start with EBCDIC "V1.0" to request the virtual device SNEQ that carries the minidisk UIT. The request and the response share the same buffer: CP evaluates the magic on the way out and the RCD data is written into the same buffer on the way back. The magic is only written when the request is built and again in read_conf_cb() when the original request fails. Several restart paths do not run that callback: - ERP use the same buffer and if the same error occurs again, the ERP restarts the existing ERP request; if a different error occurs, it adds another ERP request. Neither re-initializes the magic. - Terminated (timed out) ERP requests, killed requests and requests requeued after the last path was gone are restarted without it. - dasd_sleep_on_immediately() overwrites cqr->callback, so read_conf_cb() never ran for dasd_eckd_read_conf_immediately(), and its fastpath retries in dasd_int_handler() do not call a callback either. If such a restart succeeds, z/VM omits the virtual device SNEQ, the UID of that path is built without the UIT and the paths are reported as "Not all channel paths lead to the same device" although they lead to the same minidisk. Every start of a request, whatever path led to it, goes through dasd_start_IO(). Add an optional prepare_io function to the request that dasd_start_IO() calls before every start of the request and of its ERP requests, and use it to write the magic for RCD requests. The ERP handling stays unchanged. read_conf_cb() is no longer needed and is removed, which also gets rid of its memset() that only cleared a single byte. Fixes: 5915a873fcb1 ("[S390] dasd: re-initialize read_conf buffer for retries") Cc: stable@vger.kernel.org Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com> Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Link: https://patch.msgid.link/20261112102608.1057852-3-sth@linux.ibm.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
3 dayss390/dasd: Fix typo 'immediatly' -> 'immediately'Stefan Haberland
Fix typo in function name dasd_sleep_on_immediatly(). Suggested-by: Heiko Carstens <hca@linux.ibm.com> Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com> Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Link: https://patch.msgid.link/20261112102608.1057852-2-sth@linux.ibm.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
3 daysMerge branch 'net-psp-preserve-skb_ext_psp-across-packet-scrubbing'Jakub Kicinski
Wei Wang says: ==================== net: psp: preserve SKB_EXT_PSP across packet scrubbing When a virtual interface such as netkit is associated with a PSP device in another network namespace via PSP_CMD_DEV_ASSOC, incoming PSP packets decapsulated on the physical device lose their SKB_EXT_PSP extension when scrubbed during redirection (e.g. skb_do_redirect() or netkit_xmit() calling skb_scrub_packet()). As a result, __psp_sk_rx_policy_check() rejects incoming PSP-encrypted TCP data segments at the socket layer. This gap slipped through the existing psp.py selftests because both _data_basic_send() and _data_basic_send_netkit_psp_assoc() only sent a unidirectional data stream from the test socket to psp_responder; the returning pure TCP ACKs had SKB_EXT_PSP stripped by skb_scrub_packet(), but were still accepted by __psp_sk_rx_policy_check() while peer_tx was unset. Patch 1 (originally from Jakub Sitnicki's BPF skb extension series [1]) introduces skb_ext_scrub() to selectively preserve SKB_EXT_PSP during skb_scrub_packet(). Patch 2 updates the psp.py selftests to exercise bidirectional PSP data transfer using psp_responder's "data echo" command in both direct and netkit dev-assoc test cases. Link: https://lore.kernel.org/netdev/20260910-bpf-meta-inside-skb-ext-v2-3-0b21e42180b0@cloudflare.com/ [1] ==================== Link: https://patch.msgid.link/20261106182007.374660-1-weiwan@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 daysselftests/net: psp: test bidirectional data transferWei Wang
_data_basic_send() and _data_basic_send_netkit_psp_assoc() currently only verify unidirectional data transmission from the test socket to psp_responder. As a result, they do not exercise the receive path for PSP-encrypted TCP data segments arriving at the test socket (such as packets redirected across a netkit interface associated via dev-assoc, which relies on SKB_EXT_PSP surviving packet scrubbing). Use the existing "data echo" command in psp_responder to verify that the test socket can also receive PSP-encrypted data from the peer in both _data_basic_send() and _data_basic_send_netkit_psp_assoc(). Signed-off-by: Wei Wang <weiwan@google.com> Reviewed-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20261106182007.374660-3-weiwan@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 daysnet: Make PSP skb extension survive packet scrubbingWei Wang
skb_scrub_packet() drops all skb extensions unconditionally via skb_ext_reset(). It runs on tunnel encap/decap (ip_tunnel_rcv, vxlan_rcv, etc.) and virtual device forwarding/redirection (dev_forward_skb, netkit_xmit, skb_do_redirect). When a virtual device such as netkit is associated with a PSP device in another network namespace via PSP_CMD_DEV_ASSOC, incoming PSP packets decapsulated by psp_dev_rcv() lose their SKB_EXT_PSP extension when scrubbed during redirection into the peer netns. Without SKB_EXT_PSP, __psp_sk_rx_policy_check() rejects incoming TCP data segments at the socket layer with SKB_DROP_REASON_PSP_INPUT. Introduce a static skb_ext_scrub() helper in net/core/skbuff.c to preserve SKB_EXT_PSP across skb_scrub_packet() while dropping all other extensions. If SKB_EXT_PSP is not active, skb_ext_scrub() simply calls skb_ext_reset(). If SKB_EXT_PSP is the only extension in the skb_ext buffer, nothing needs to be scrubbed. Otherwise, save the PSP metadata, reset the extension block, and re-add a fresh SKB_EXT_PSP extension. Fixes: 06c2dce2d0f6 ("psp: add new netlink cmd for dev-assoc and dev-disassoc") Link: https://lore.kernel.org/r/20260910-bpf-meta-inside-skb-ext-v2-3-0b21e42180b0@cloudflare.com Reported-by: Daniel Zahka <daniel.zahka@gmail.com> Closes: https://lore.kernel.org/netdev/DLODSKPY6ON6.1G6SP3CFFLCPJ@gmail.com/ Co-developed-by: Jakub Sitnicki <jakub@cloudflare.com> Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com> Signed-off-by: Wei Wang <weiwan@google.com> Reviewed-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20261106182007.374660-2-weiwan@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 daysnet/smc: fix link group ownership in handshake abortMahanta Jambigi
An aborted first-contact handshake can hang the handshake worker on the socket lock it already holds, reset the clcsock of a socket that has fallen back to TCP, or corrupt the alert-node lookup when the handshake retries with the same connection. The abort leaves a connection registered in a link group that another context has already unlinked for termination: smc_conn_free() skips the unregister when lgr->list is empty, so the alert token and alert node stay in lgr->conns_all. If the handshake retries another device or SMC version, smc_conn_create() creates a second link group and smc_lgr_register_conn() inserts the same alert node into it: the token loop is skipped, rb_link_node() links a node that is still in the old tree into the new one, and a second sock_hold() is taken where only one sock_put() will follow. The old group's terminator then keeps returning that node from rb_first() and can kill a connection that now belongs to the new group. smc_lgr_cleanup_early() also starts a second termination of the link group that is already being terminated, which takes lock_sock() on the socket the handshake worker holds; if the termination work wins the race instead, it later kills the freed connection and aborts the clcsock of a socket that has fallen back to TCP. Making the unregister unconditional also lets smc_conn_free() reach the delayed free work on a claimed link group, where the lockless freeing check can arm it after the owner has cancelled it. Always unregister the connection, claim a link group for termination once under lgr_lock, keep the link group alive across the abort, and arm the delayed free work only under the same lock and cancel it synchronously before the teardown. Drop an already freed connection in smc_conn_kill() without running the connection and socket teardown. Fixes: 2a0674fffb6b ("net/smc: improve abnormal termination of link groups") Fixes: f9aab6f2ce57 ("net/smc: immediate freeing in smc_lgr_cleanup_early()") Cc: stable@vger.kernel.org Signed-off-by: Mahanta Jambigi <mjambigi@linux.ibm.com> Link: https://patch.msgid.link/20261106130457.1092203-1-mjambigi@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
3 dayspower: sequencing: pcie-m2: fix serdev controller reference leakBartosz Golaszewski
In pwrseq_pcie_m2_create_serdev_one(), if serdev_ctrl->serdev is NULL but pdev is already tracked in ctx->pci_devices, we return early from the loop and skip the serdev_controller_put(), leaking the reference. Initialize ret to 0 and jump directly to the label that ensures the reference is released. Cc: stable@vger.kernel.org Closes: https://sashiko.dev/#/bug/linux-07754192-a8ad-42d6-ab1b-cd6f16bec846 Fixes: c4be520907a4 ("power: sequencing: pcie-m2: Create serdev for PCI devices present before probe") Link: https://patch.msgid.link/20261105-pwrseq-pcie-m2-serdev-ref-leak-v1-1-e2e022ca17ec@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
3 daysarm64: hugetlb: Prevent write fault livelocks on stale TLB entriesChris Down
In Meta production, we have had tasks get stuck in a fault loop while using hugetlb on arm64. During my investigations I found that affected tasks share a private hugetlb page. Looking at the stuck task states, I found the following ordering: CPU0 CPU1 ---- ---- read page [read only entry cached in TLB] write page hugetlb_fault() hugetlb_wp() [reuse folio] set_huge_ptep_maybe_writable() set_huge_ptep_writable() [flush local TLB only] write page using stale entry hugetlb_fault() huge_ptep_set_access_flags() [entry already writable, no flush] retry write using stale entry [fault indefinitely. well, that's not ideal!] The reason is that when a write fault makes a non-contiguous hugetlb entry writable, it only invalidates the local TLB. However, another CPU can keep the old read-only entry, so its write will fault even though the page table already permits it. hugetlb_fault() then finds nothing to change and leaves the stale entry in place, so the same write keeps going round in circles. This is particularly bad because, if the kernel is copying to user memory, the retry stays inside the kernel and the task can't act on the pending signal. It can even remain unkillable while holding locks across the copy, resulting in further failures. For example, a read into a hugetlb buffer can hold the pipe mutex and block other users of the pipe until the loop ends, causing cascading lockups across the machine. To fix this, when a write fault finds nothing to change in a non-contiguous hugetlb entry, let's invalidate the local entry. Fixes: cb1fa2e99955 ("arm64, tlbflush: don't TLBI broadcast if page reused in write fault") Cc: stable@vger.kernel.org Signed-off-by: Chris Down <chris@chrisdown.name> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
3 daysigmp: use the joined device when leaving a multicast groupJunyoung Jang
When a socket joins a multicast group, the ifindex of the device is stored in the socket's membership entry. When leaving, ip_mc_leave_group() resolves the device again from the request. If the request only specifies an interface address and that address is not assigned to any device, no device is found. The membership is still matched by address and removed from the socket, but the group is not released on the device it was joined on. The group is then leaked on the device until the device is unregistered. An unprivileged user can trigger this by joining with an ifindex and a non-local address and leaving with the address only. It can also happen when a socket joins and leaves with the address only and the address is removed in between. Fix by resolving the device from the ifindex stored in the membership, like ip_mc_drop_socket() does. Fixes: 4eba7bb1d72d ("ipv4: igmp: Allow removing groups from a removed interface") Signed-off-by: Junyoung Jang <graypanda.inzag@gmail.com> Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20261109125312.2208874-1-graypanda.inzag@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
3 daysRevert "ALSA: hda/cs420x: Add CS4208 fixup for MacBookAir 7,2"Takashi Iwai
This reverts commit 82cfab6a52621febf36752bd5ed5184f82c96e07. The quirk entry seems matching with other multiple irrelevant models that lead to a regression on those. Maybe we should use HDA_CODEC_QUIRK() entry for the corresponding codec SSID, instead. But let's revert for addressing the regression at first. Fixes: 82cfab6a5262 ("ALSA: hda/cs420x: Add CS4208 fixup for MacBookAir 7,2") Closes: https://lore.kernel.org/71fb1e29-60e1-4522-a071-c53557cea39b@icloud.com Closes: https://lore.kernel.org/CABWzDrqrskmtb7MVFgJ54k4WNSqby7Qo3R1XeoVBaJ+djaO1ew@mail.gmail.com Cc: <stable@vger.kernel.org> Link: https://patch.msgid.link/20261112124844.694544-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
3 daysALSA: hda/realtek: Update quirk for Acer Predator PHN16-72Fa-Iz Faadhillah Ibrahim
The Acer Predator PHN16-72 (1025:1731) uses the ALC245 codec, but its mic-mute LED is not enabled by default. Replace the existing quirk with ALC245_FIXUP_ACER_MICMUTE_LED quirk to enable the mic-mute LED chain the existing ALC2XX_FIXUP_HEADSET_MIC quirk. Fixes: 34e08ad3a8da ("ALSA: hda/realtek: Add quirk for Acer Predator PHN16-72") Signed-off-by: Fa-Iz Faadhillah Ibrahim <faiz.faadhillah@gmail.com> Link: https://patch.msgid.link/20261111172108.30011-1-faiz.faadhillah@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
3 daysselftests: overlayfs: reject different lower idmaps on same fsJérémy Jean
Add an idmapped overlay test for two lower layers that share a backing superblock but use different idmaps. Check that mount creation with index=on fails with EINVAL. Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
3 daysALSA: hda/realtek - remove headphone MIC support for Dell Pro QC1255Kailang Yang
This unit don't support headphone MIC. The popping sound will disappear when you remove it. Fixes: 97272a5704bf ("ALSA: hda/realtek - Fixed Headphone noise issue for Dell QCM1255") Signed-off-by: Kailang Yang <kailang@realtek.com> Link: https://lore.kernel.org/3c8129fbfa6d4ee2b464735f2f31dffa@realtek.com Signed-off-by: Takashi Iwai <tiwai@suse.de>