Linux/linux ddd664bnet/bluetooth iso.c, net/bluetooth/rfcomm core.c

Merge tag 'net-7.1-rc7' 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.

  Current release - fix to a fix:

   - Bluetooth: MGMT: fix backward compatibility with bluetoothd
     which adds stray bytes to MGMT_OP_ADD_EXT_ADV_DATA

  Previous releases - regressions:

   - af_unix: fix inq_len update inaccuracy on partial read

   - eth: fec: fix pinctrl default state restore order on resume

   - wifi: iwlwifi:
       - mvm: don't support the reset handshake for old firmwares
       - pcie: simplify the resume flow if fast resume is not used,

    [45 lines not shown]
DeltaFile
+184-0tools/testing/selftests/net/test_vxlan_vnifilter_notify.sh
+55-37net/l2tp/l2tp_ppp.c
+37-42net/mptcp/options.c
+41-36net/sched/act_pedit.c
+50-19net/bluetooth/rfcomm/core.c
+46-17net/bluetooth/iso.c
+413-15183 files not shown
+1,027-43389 files

Linux/linux 44ed32dinclude/linux tracepoint.h

Merge tag 'trace-v7.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace

Pull tracing fix from Steven Rostedt:

 - Fix CFI violation in probestub function

   The probestub is a function to allow tprobes to hook to a tracepoint
   to gain access to its parameters.

   The function itself is only referenced by the tracepoint structure
   which lives in the __tracepoint section. objtool explicitly ignores
   that section and when processing functions in the kernel, if it
   detects one that has no references it will seal it to have its ENDBR
   stripped on boot up.

   This means the probstub function will have its ENDBR stripped and if
   a tprobe is attached to it with IBT enabled, it will go *boom*.

* tag 'trace-v7.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
  tracing: Fix CFI violation in probestub being called by tprobes
DeltaFile
+8-0include/linux/tracepoint.h
+8-01 files

Linux/linux 6a08076arch/s390/configs debug_defconfig defconfig, arch/s390/include/asm bug.h linkage.h

Merge tag 's390-7.1-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux

Pull s390 fixes from Alexander Gordeev:

 - Enable IOMMUFD and VFIO cdev such that PCI pass-through to
   QEMU/KVM can optionally utilize native IOMMUFD

 - With HAVE_ARCH_BUG_FORMAT enabled the BUG infrastructure might
   misinterpret flags or fault. Fix this by moving the "format"
   field emission into __BUG_ENTRY()

 - The generic version of _THIS_IP_ is known to be brittle and may
   break with current and future GCC and Clang optimizations.  Fix
   it by overriding _THIS_IP_

* tag 's390-7.1-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390: Implement _THIS_IP_ using inline asm
  s390/bug: Always emit format word in __BUG_ENTRY
  s390/configs: Enable IOMMUFD and VFIO cdev in defconfigs
DeltaFile
+6-6arch/s390/include/asm/bug.h
+4-0arch/s390/configs/debug_defconfig
+4-0arch/s390/configs/defconfig
+2-0arch/s390/include/asm/linkage.h
+16-64 files

Linux/linux b6197b3drivers/net/ethernet/broadcom/bnxt bnxt.c

Reapply "bnxt_en: bring back rtnl_lock() in the bnxt_open() path"

This reverts commit 850d9248d2eac662f869c766a598c877690c74e5.
This reapplies commit 325eb217e41f ("bnxt_en: bring back rtnl_lock()
in the bnxt_open() path").

Breno reports a lockdep warning in bnxt. During FW reset the driver
may end up calling netif_set_real_num_tx_queues() (if queue count
changes), so calls to bnxt_open() still require rtnl_lock.

  net/sched/sch_generic.c:1416 suspicious rcu_dereference_protected() usage!

   dev_qdisc_change_real_num_tx+0x54/0xe0
   netif_set_real_num_tx_queues+0x4ed/0xa80
   __bnxt_open_nic+0x9cb/0x3490
   bnxt_open+0x1cb/0x370
   bnxt_fw_reset_task+0x80d/0x1e80
   process_scheduled_works+0x9c1/0x13b0


    [11 lines not shown]
DeltaFile
+29-7drivers/net/ethernet/broadcom/bnxt/bnxt.c
+29-71 files

Linux/linux 3c94f24net/ipv4 udp.c

udp: clear skb->dev before running a sockmap verdict

On the UDP receive path skb->dev is repurposed as dev_scratch (the
truesize/state cache set by udp_set_dev_scratch()), through the
union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff.

When a UDP socket is in a sockmap, sk_data_ready is
sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor()
(sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq.
If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp,
bpf_skc_lookup_tcp), bpf_skc_lookup() does:

        if (skb->dev)
                caller_net = dev_net(skb->dev);

skb->dev still holds the dev_scratch value (a non-NULL integer), so dev_net()
dereferences it as a struct net_device * and the kernel takes a general
protection fault on a non-canonical address in softirq:


    [39 lines not shown]
DeltaFile
+8-0net/ipv4/udp.c
+8-01 files

Linux/linux e374b22net/sctp sm_statefuns.c

sctp: purge outqueue on stale COOKIE-ECHO handling

sctp_stream_update() is only invoked when the association is moved into
COOKIE_WAIT during association setup/reconfiguration. In this path, the
outbound stream scheduler state (stream->out_curr) is expected to be
clean, since no user data should have been transmitted yet unless the
state machine has already partially progressed.

However, a corner case exists in sctp_sf_do_5_2_6_stale(): when a
Stale Cookie ERROR is received, the association is rolled back from
COOKIE_ECHOED to COOKIE_WAIT. In this scenario, user data may already
have been queued and even bundled with the COOKIE-ECHO chunk.

During the rollback, sctp_stream_update() frees the old stream table
and installs a new one, but it does not invalidate stream->out_curr.
As a result, out_curr may still point to a freed sctp_stream_out
entry from the previous stream state.

Later, SCTP scheduler dequeue paths (FCFS, RR, PRIO, etc.) rely on

    [36 lines not shown]
DeltaFile
+1-5net/sctp/sm_statefuns.c
+1-51 files

Linux/linux b47ff80drivers/net/bonding bond_3ad.c bond_procfs.c

bonding: annotate data-races arcound churn variables

These fields are updated asynchronously by the bonding state machine
in ad_churn_machine() while holding bond->mode_lock.

bond_info_show_slave() and bond_fill_slave_info() read them without
bond->mode_lock being held, we need to add READ_ONCE() and
WRITE_ONCE() annotations.

Note that AD_CHURN_MONITOR, AD_CHURN, and AD_NO_CHURN are defined
exclusively in (kernel private) include/net/bond_3ad.h header.

They should be moved to include/uapi/linux/if_bonding.h or userspace
tools will have to hardcode their values.

Fixes: 4916f2e2f3fc ("bonding: print churn state via netlink")
Fixes: 14c9551a32eb ("bonding: Implement port churn-machine (AD standard 43.4.17).")
Signed-off-by: Eric Dumazet <edumazet at google.com>
Link: https://patch.msgid.link/20260603123514.388226-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
DeltaFile
+10-8drivers/net/bonding/bond_3ad.c
+4-4drivers/net/bonding/bond_procfs.c
+2-2drivers/net/bonding/bond_netlink.c
+16-143 files

Linux/linux 7561c7fnet/802 mrp.c

net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr

In mrp_pdu_parse_vecattr(), vector attribute events are encoded three
per byte and valen tracks the number of events left to process.

The parser decrements valen after processing the first and second events
from each event byte, but not after processing the third one. When valen
is exactly a multiple of three, the loop continues after the last valid
event and consumes the next byte as a new event byte, applying a
spurious event to the MRP applicant state.

Additionally, when valen is zero the parser unconditionally consumes
attrlen bytes as FirstValue and advances the offset, even though per
IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of
zero and no FirstValue or Vector fields. This corrupts the offset for
subsequent PDU parsing.

Also, when valen exceeds three the loop crosses byte boundaries but
the attribute value is not incremented between the last event of one

    [18 lines not shown]
DeltaFile
+9-0net/802/mrp.c
+9-01 files

Linux/linux 9fc237fdrivers/net/ethernet/realtek/rtase rtase_main.c

rtase: Avoid sleeping in get_stats64()

The .ndo_get_stats64 callback must not sleep because it can be
called when reading /proc/net/dev.

rtase_get_stats64() calls rtase_dump_tally_counter(), which polls
the tally counter dump bit with read_poll_timeout(). This may
sleep while waiting for the hardware counter dump to complete.

Use read_poll_timeout_atomic() instead to avoid sleeping in the
get_stats64() path.

Fixes: 079600489960 ("rtase: Implement net_device_ops")
Cc: stable at vger.kernel.org
Signed-off-by: Justin Lai <justinlai0215 at realtek.com>
Link: https://patch.msgid.link/20260603061816.31356-1-justinlai0215@realtek.com
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
DeltaFile
+3-2drivers/net/ethernet/realtek/rtase/rtase_main.c
+3-21 files

Linux/linux 3a5f3f7net/ieee802154/6lowpan tx.c

ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit()

The aoe driver (or similar) generates a non-IPv6 packet
(e.g., ETH_P_AOE) and queues it for transmission via dev_queue_xmit()
on a 6LoWPAN interface (configured by the user or test case).

Since the packet is not IPv6, the 6LoWPAN header_ops->create function
(lowpan_header_create or header_create) returns early without initializing
the lowpan_addr_info structure in the skb headroom.

In the transmit function (lowpan_xmit), the driver calls lowpan_header
(or setup_header) which unconditionally copies and uses the lowpan_addr_info
from the headroom, which contains uninitialized data.

Fix this by dropping non IPv6 packets.

A similar fix is needed in net/bluetooth/6lowpan.c bt_xmit().

Fixes: 4dc315e267fe ("ieee802154: 6lowpan: move transmit functionality")

    [6 lines not shown]
DeltaFile
+5-0net/ieee802154/6lowpan/tx.c
+5-01 files

Linux/linux 791c91dnet/ipv6 mcast.c

ipv6: mcast: Fix use-after-free when processing MLD queries

When processing an MLD query, a pointer to the multicast group address
is retrieved when initially parsing the packet. This pointer is later
dereferenced without being reloaded despite the fact that the skb header
might have been reallocated following the pskb_may_pull() calls, leading
to a use-after-free [1].

Fix by copying the multicast group address when the packet is initially
parsed.

[1]
BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512)
Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118

Workqueue: mld mld_query_work
Call Trace:
<TASK>
dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)

    [38 lines not shown]
DeltaFile
+4-4net/ipv6/mcast.c
+4-41 files

Linux/linux 05ef0afdrivers/net/vxlan vxlan_vnifilter.c, tools/testing/selftests/net test_vxlan_vnifilter_notify.sh Makefile

Merge branch 'vxlan-vnifilter-fix-vni-add-update-notifications'

Andy Roulin says:

====================
vxlan: vnifilter: fix VNI add/update notifications

When a vxlan device has vnifilter enabled, userspace observers
(e.g., bridge monitor vni) miss VNI add events and see spurious
notifications on no-op VNI re-adds.

Patch 1 fixes the missing notification on VNI add: vxlan_vni_add()
guarded the notification on a 'changed' flag that vxlan_vni_update_group()
only sets when a multicast group or remote is supplied, so VNIs added
without a group (e.g., L3 VXLAN) were silently created.

Patch 2 fixes the spurious notification on VNI update: vxlan_vni_update()
tested 'if (changed)' against a bool pointer instead of dereferencing it,
so every re-add produced a notification regardless of whether anything

    [8 lines not shown]
DeltaFile
+184-0tools/testing/selftests/net/test_vxlan_vnifilter_notify.sh
+2-3drivers/net/vxlan/vxlan_vnifilter.c
+1-0tools/testing/selftests/net/Makefile
+187-33 files

Linux/linux 8df1c84tools/testing/selftests/net test_vxlan_vnifilter_notify.sh Makefile

selftests: net: add vxlan vnifilter notification test

Add a selftest for VXLAN vnifilter netlink notifications that verifies
RTM_NEWTUNNEL and RTM_DELTUNNEL are sent correctly when VNIs are added,
deleted, or updated, and that no spurious notifications are sent when
a VNI is re-added with the same attributes.

Signed-off-by: Andy Roulin <aroulin at nvidia.com>
Acked-by: Petr Machata <petrm at nvidia.com>
Link: https://patch.msgid.link/20260602185138.253265-4-aroulin@nvidia.com
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
DeltaFile
+184-0tools/testing/selftests/net/test_vxlan_vnifilter_notify.sh
+1-0tools/testing/selftests/net/Makefile
+185-02 files

Linux/linux aa6ca1cdrivers/net/vxlan vxlan_vnifilter.c

vxlan: vnifilter: send notification on VNI add

When a new VNI is added to a vxlan device with vnifilter enabled,
no RTM_NEWTUNNEL notification is sent to userspace. This means
'bridge monitor vni' never shows VNI add events, even though
VNI delete events are reported correctly.

The bug is in vxlan_vni_add(), where the notification is guarded by
'if (changed)'. The 'changed' flag is set by vxlan_vni_update_group()
only when the multicast group or remote IP is modified, but for a
new VNI added without a group (e.g. in L3 VxLAN interface scenarios),
the function returns early without setting changed=true. Since this
is a new VNI, the notification should be sent unconditionally.

The notification is not guarded by the return value of
vxlan_vni_update_group() because, at this point, the VNI has already
been inserted into the hash table and list with no rollback on error.
The VNI will be visible in 'bridge vni show' regardless, so userspace
should be informed. This is consistent with vxlan_vni_del() which also

    [21 lines not shown]
DeltaFile
+1-2drivers/net/vxlan/vxlan_vnifilter.c
+1-21 files

Linux/linux 84683b5drivers/net/vxlan vxlan_vnifilter.c

vxlan: vnifilter: fix spurious notification on VNI update

When a VNI is re-added with the same attributes (e.g. same group or no
group), vxlan_vni_update() sends a spurious RTM_NEWTUNNEL notification
even though nothing changed.

The bug is that 'if (changed)' tests whether the pointer is non-NULL,
not the bool value it points to. Since every caller passes a valid
pointer, the condition is always true and the notification fires
unconditionally.

Fix by dereferencing the pointer: 'if (*changed)'.

Reproducer:

 # ip link add vxlan100 type vxlan dstport 4789 local 10.0.0.1 \
      nolearning external vnifilter
 # ip link set vxlan100 up
 # bridge monitor vni &

    [8 lines not shown]
DeltaFile
+1-1drivers/net/vxlan/vxlan_vnifilter.c
+1-11 files

Linux/linux ab1ecaadrivers/net/ethernet/realtek/rtase rtase_main.c

rtase: Reset TX subqueue when clearing TX ring

rtase_tx_clear() clears the TX ring and resets the ring indexes.
However, the TX queue state and BQL accounting are not reset at
the same time.

This may leave __QUEUE_STATE_STACK_XOFF asserted after
rtase_sw_reset(), preventing new TX packets from being scheduled.

Reset the TX subqueue when clearing the TX ring so the TX queue
state and BQL accounting are restored together.

Fixes: 5a2a2f15244c ("rtase: Implement the rtase_down function")
Cc: stable at vger.kernel.org
Signed-off-by: Justin Lai <justinlai0215 at realtek.com>
Reviewed-by: Alexander Lobakin <aleksander.lobakin at intel.com>
Link: https://patch.msgid.link/20260602114659.12335-1-justinlai0215@realtek.com
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
DeltaFile
+2-0drivers/net/ethernet/realtek/rtase/rtase_main.c
+2-01 files

Linux/linux 1d31eb2drivers/net/ethernet/marvell/octeontx2/af rvu_npc.c rvu_npc_fs.c

octeontx2-af: npc: Fix CPT channel mask in npc_install_flow

Use the CPT-aware NIX channel mask in the npc_install_flow path so that
when the host PF installs steering rules in kernel for a VF used from
userspace (e.g. DPDK), MCAM entries see the same channel mask semantics as
other RX paths.

Fixes: 56bcef528bd8 ("octeontx2-af: Use npc_install_flow API for promisc and broadcast entries")
Cc: Naveen Mamindlapalli <naveenm at marvell.com>
Signed-off-by: Nithin Dabilpuram <ndabilpuram at marvell.com>
Signed-off-by: Ratheesh Kannoth <rkannoth at marvell.com>
Link: https://patch.msgid.link/20260602045853.1558530-1-rkannoth@marvell.com
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
DeltaFile
+16-16drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c
+1-1drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c
+1-0drivers/net/ethernet/marvell/octeontx2/af/rvu.h
+18-173 files

Linux/linux 1232b31Documentation/devicetree/bindings/net eswin,eic7700-eth.yaml

dt-bindings: ethernet: eswin: fix hsp-sp-csr backward compatibility

Commit c36069c6f46c ("dt-bindings: ethernet: eswin: add optional TXD and
RXD delay register offsets") added two optional cells to eswin,hsp-sp-csr
but omitted minItems: 4.

As a result, dt-schema implicitly required all 6 cells, which broke
backward compatibility with existing 4-cell device trees.

Add minItems: 4 to preserve backward compatibility.

Fixes: c36069c6f46c ("dt-bindings: ethernet: eswin: add optional TXD and RXD delay register offsets")
Reported-by: Sashiko AI <sashiko-bot at kernel.org>
Closes: https://lore.kernel.org/all/20260519022334.35742C2BCB7@smtp.kernel.org/
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski at oss.qualcomm.com>
Signed-off-by: Zhi Li <lizhi2 at eswincomputing.com>
Link: https://patch.msgid.link/20260602014528.2076-1-lizhi2@eswincomputing.com
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
DeltaFile
+2-1Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml
+2-11 files

Linux/linux 0861615net/sctp sm_make_chunk.c

sctp: validate cached peer INIT chunk length in COOKIE_ECHO processing

When a listening SCTP server processes a COOKIE_ECHO chunk, the cached
peer INIT chunk embedded after the cookie is parsed and its parameters
are later walked by sctp_process_init() using sctp_walk_params().

However, the chunk header length of this cached INIT chunk was not
validated against the remaining buffer in the COOKIE_ECHO payload. If
the length field is inflated, the parameter walk can run beyond the
actual received data, leading to out-of-bounds reads and potential
memory corruption during later parameter handling (e.g. STATE_COOKIE
processing and kmemdup() copies).

Add a bounds check in sctp_unpack_cookie() to ensure the cached INIT
chunk length does not exceed the available data in the COOKIE_ECHO
buffer before it is used.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: Brian Geffon <bgeffon at google.com>

    [3 lines not shown]
DeltaFile
+5-0net/sctp/sm_make_chunk.c
+5-01 files

Linux/linux 899ee91include/net/tc_act tc_pedit.h, net/sched act_pedit.c

net/sched: fix pedit partial COW leading to page cache corruption

tcf_pedit_act() computes the COW range for skb_ensure_writable()
once before the key loop using tcfp_off_max_hint, but the hint does
not account for the runtime header offset added by typed keys. This
can leave part of the write region un-COW'd.

Fix by moving skb_ensure_writable() inside the per-key loop where
the actual write offset is known, and add overflow checking on the
offset arithmetic. For negative offsets (e.g. Ethernet header edits
at ingress), use skb_cow() to COW the headroom instead. Guard
offset_valid() against INT_MIN, where negation is undefined.

Fixes: 8b796475fd78 ("net/sched: act_pedit: really ensure the skb is writable")
Reported-by: Yiming Qian <yimingqian591 at gmail.com>
Reported-by: Keenan Dong <keenanat2000 at gmail.com>
Reported-by: Han Guidong <2045gemini at gmail.com>
Reported-by: Zhang Cen <rollkingzzc at gmail.com>
Reviewed-by: Han Guidong <2045gemini at gmail.com>

    [11 lines not shown]
DeltaFile
+41-36net/sched/act_pedit.c
+0-1include/net/tc_act/tc_pedit.h
+41-372 files

Linux/linux c05fa14net/vmw_vsock vmci_transport.c

vsock/vmci: fix sk_ack_backlog leak on failed handshake

When vmci_transport_recv_connecting_server() returns an error,
vmci_transport_recv_listen() calls vsock_remove_pending() but never
calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented
permanently.

Repeated handshake failures (malformed packets, queue pair alloc
failure, event subscribe failure) cause sk_ack_backlog to climb
toward sk_max_ack_backlog. Once it reaches the limit the listener
permanently refuses all new connections with -ECONNREFUSED, a
silent denial of service requiring a process restart to recover.

The two existing sk_acceptq_removed() calls in af_vsock.c do not
cover this path: line 764 checks vsock_is_pending() which returns
false after vsock_remove_pending(), and line 1889 is only reached
on successful accept().

Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on

    [8 lines not shown]
DeltaFile
+3-1net/vmw_vsock/vmci_transport.c
+3-11 files

Linux/linux a764b0edrivers/net/bonding bond_main.c

net: bonding: fix NULL pointer dereference in bond_do_ioctl()

In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which
can return NULL if the requested interface name does not exist. However,
the subsequent slave_dbg() call is placed before the NULL check:

    slave_dev = __dev_get_by_name(net, ifr->ifr_slave);
    slave_dbg(bond_dev, slave_dev, "slave_dev=%p:\n", slave_dev); //here
    if (!slave_dev)
        return -ENODEV;

The slave_dbg() macro expands to netdev_dbg(bond_dev, "(slave %s): " fmt,
(slave_dev)->name, ...) which unconditionally dereferences slave_dev->name
before the NULL check is performed. This results in a NULL pointer
dereference kernel oops when a user calls bonding ioctl (e.g.
SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave
interface name.

This is reachable from userspace via the bonding ioctl interface with

    [10 lines not shown]
DeltaFile
+2-2drivers/net/bonding/bond_main.c
+2-21 files

Linux/linux 0652a3dinclude/linux tracepoint.h

tracing: Fix CFI violation in probestub being called by tprobes

The probestub is a function to allow tprobes to hook to a tracepoint to
gain access to its parameters. The function itself is only referenced by
the tracepoint structure which lives in the __tracepoint section. objtool
explicitly ignores that section and when processing functions in the
kernel, if it detects one that has no references it will seal it to have
its ENDBR stripped on boot up.

This means when a tprobe is attached to the sched_wakeup tracepoint, when it
is triggered it will call __probestub_sched_wakeup and due to the missing
ENDBR on a CFI-enabled machine it will take a #CP exception.

Fix this by adding CFI_NOSEAL annotation to probestub declaration.

Cc: stable at vger.kernel.org
Acked-by: Masami Hiramatsu (Google) <mhiramat at kernel.org>
Link: https://patch.msgid.link/20260603153147.573589-1-eva.kurchatova@virtuozzo.com
Fixes: d5173f753750 ("objtool: Exclude __tracepoints data from ENDBR checks")

    [3 lines not shown]
DeltaFile
+8-0include/linux/tracepoint.h
+8-01 files

Linux/linux 1231623drivers/net geneve.c

geneve: fix length used in GRO hint UDP checksum adjustment

In geneve_post_decap_hint the length used for adjusting the UDP checksum
should be 'skb->len - gro_hint->nested_tp_offset' (UDP length) instead
of 'skb->len - gro_hint->nested_nh_offset' (IP length).

Fixes: fd0dd796576e ("geneve: use GRO hint option in the RX path")
Cc: Paolo Abeni <pabeni at redhat.com>
Reported-by: Sashiko <sashiko-bot at kernel.org>
Closes: https://sashiko.dev/#/patchset/20260521131436.748832-1-jhs%40mojatatu.com
Signed-off-by: Antoine Tenart <atenart at kernel.org>
Reviewed-by: Simon Horman <horms at kernel.org>
Link: https://patch.msgid.link/20260529144713.780938-1-atenart@kernel.org
Signed-off-by: Paolo Abeni <pabeni at redhat.com>
DeltaFile
+1-1drivers/net/geneve.c
+1-11 files

Linux/linux 060c1dadrivers/net/ethernet/airoha airoha_eth.c, drivers/net/ethernet/mediatek mtk_eth_soc.c

Merge branch 'fix-use-after-free-in-metadata-dst-teardown-in-airoha_eth-and-mtk_eth_soc-drivers'

Lorenzo Bianconi says:

====================
Fix use-after-free in metadata dst teardown in airoha_eth and mtk_eth_soc drivers

airoha_metadata_dst_free() and mtk_free_dev() call metadata_dst_free()
which frees the metadata_dst with kfree() immediately, bypassing the RCU
grace period.
Replace metadata_dst_free() with dst_release() which properly goes
through the refcount path and runs call_rcu_hurry() if refcount goes to
zero.
====================

Link: https://patch.msgid.link/20260602-airoha-mtk-metadata-uaf-fix-v1-0-3aaa99d83351@kernel.org
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
DeltaFile
+1-1drivers/net/ethernet/airoha/airoha_eth.c
+1-1drivers/net/ethernet/mediatek/mtk_eth_soc.c
+2-22 files

Linux/linux b38cae8drivers/net/ethernet/airoha airoha_eth.c

net: airoha: Fix use-after-free in metadata dst teardown

airoha_metadata_dst_free() runs metadata_dst_free() which frees the
metadata_dst with kfree() immediately, bypassing the RCU grace period.
In the RX path, skb_dst_set_noref() sets a non-refcounted pointer from
the skb to the metadata_dst. This function requires RCU read-side
protection and the dst must remain valid until all RCU readers complete.
Since metadata_dst_free() calls kfree() directly, an use-after-free can
occur if any skb still holds a noref pointer to the dst when the driver
tears it down.
Replace metadata_dst_free() with dst_release() which properly goes
through the refcount path: when the refcount drops to zero, it schedules
the actual free via call_rcu_hurry(), ensuring all RCU readers have
completed before the memory is freed.

Fixes: af3cf757d5c9 ("net: airoha: Move DSA tag in DMA descriptor")
Signed-off-by: Lorenzo Bianconi <lorenzo at kernel.org>
Link: https://patch.msgid.link/20260602-airoha-mtk-metadata-uaf-fix-v1-1-3aaa99d83351@kernel.org
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
DeltaFile
+1-1drivers/net/ethernet/airoha/airoha_eth.c
+1-11 files

Linux/linux 80df409drivers/net/ethernet/mediatek mtk_eth_soc.c

net: ethernet: mtk_eth_soc: Fix use-after-free in metadata dst teardown

mtk_free_dev() calls metadata_dst_free() which frees the metadata_dst
with kfree() immediately, bypassing the RCU grace period.
In the RX path, skb_dst_set_noref() sets a non-refcounted pointer from
the skb to the metadata_dst. This function requires RCU read-side
protection and the dst must remain valid until all RCU readers complete.
Since metadata_dst_free() calls kfree() directly, a use-after-free can
occur if any skb still holds a noref pointer to the dst when the driver
tears it down.
Replace metadata_dst_free() with dst_release() which properly goes
through the refcount path: when the refcount drops to zero, it schedules
the actual free via call_rcu_hurry(), ensuring all RCU readers have
completed before the memory is freed.

Fixes: 2d7605a72906 ("net: ethernet: mtk_eth_soc: enable hardware DSA untagging")
Signed-off-by: Lorenzo Bianconi <lorenzo at kernel.org>
Link: https://patch.msgid.link/20260602-airoha-mtk-metadata-uaf-fix-v1-2-3aaa99d83351@kernel.org
Signed-off-by: Jakub Kicinski <kuba at kernel.org>
DeltaFile
+1-1drivers/net/ethernet/mediatek/mtk_eth_soc.c
+1-11 files

Linux/linux d20da91net/bluetooth iso.c l2cap_core.c, net/bluetooth/bnep core.c

Merge tag 'for-net-2026-06-03' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth

Luiz Augusto von Dentz says:

====================
bluetooth pull request for net:

 - hci_core: fix memory leak in error path of hci_alloc_dev()
 - hci_sync: reject oversized Broadcast Announcement prepend
 - MGMT: Fix backward compatibility with userspace
 - MGMT: validate advertising TLV before type checks
 - L2CAP: reject BR/EDR signaling packets over MTUsig
 - RFCOMM: validate skb length in MCC handlers
 - RFCOMM: hold listener socket in rfcomm_connect_ind()
 - ISO: Fix not releasing hdev reference on iso_conn_big_sync
 - ISO: Fix a use-after-free of the hci_conn pointer
 - ISO: Fix data-race on iso_pi fields in hci_get_route calls
 - SCO: Fix data-race on sco_pi fields in sco_connect
 - BNEP: reject short frames before parsing

    [18 lines not shown]
DeltaFile
+50-19net/bluetooth/rfcomm/core.c
+46-17net/bluetooth/iso.c
+37-22net/bluetooth/bnep/core.c
+46-0net/bluetooth/l2cap_core.c
+22-4net/bluetooth/rfcomm/sock.c
+15-5net/bluetooth/sco.c
+216-674 files not shown
+235-7710 files

Linux/linux ac05609drivers/net/wireless/intel/iwlwifi/mld mac80211.c, drivers/net/wireless/intel/iwlwifi/mvm fw.c ops.c

Merge tag 'wireless-2026-06-03' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless

Johannes Berg says:

====================
Things are finally quieting down:
 - iwlwifi:
   - FW reset handshake removal for older devices
   - NIC access fix in fast resume
   - avoid too large command for some BIOSes
   - fix TX power constraints in AP mode
 - cfg80211:
   - fix netlink parse overflow
   - fix potential 6 GHz scan memory leak
   - enforce HE/EHT consistency to avoid mac80211 crash
 - mac80211: guard radiotap antenna parsing

* tag 'wireless-2026-06-03' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless:
  wifi: cfg80211: enforce HE/EHT cap/oper consistency

    [11 lines not shown]
DeltaFile
+32-24drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+22-6drivers/net/wireless/intel/iwlwifi/mvm/fw.c
+9-0net/wireless/nl80211.c
+8-1net/wireless/scan.c
+7-0drivers/net/wireless/intel/iwlwifi/mld/mac80211.c
+6-0drivers/net/wireless/intel/iwlwifi/mvm/ops.c
+84-313 files not shown
+88-379 files

Linux/linux 11c31f8net/mptcp options.c pm.c

Merge branch 'mptcp-misc-fixes-for-v7-1-rc7'

Matthieu Baerts says:

====================
mptcp: misc fixes for v7.1-rc7

Here are various unrelated fixes:

- Patch 1: fix missing wakeups when multiple threads are reading from
  the same fd. A fix for v5.7.

- Patch 2: fix retransmission loop when MPTCP checksum is enabled. A fix
  for v5.14.

- Patch 3: fix a TOCTOU race while computing rcv_wnd. A fix for v5.11.

- Patch 4: allow subflows receive window to shrink if needed. A fix for
  v5.19.

    [23 lines not shown]
DeltaFile
+37-42net/mptcp/options.c
+4-11net/mptcp/pm.c
+10-5net/mptcp/sockopt.c
+8-6net/mptcp/pm_userspace.c
+10-0net/mptcp/protocol.c
+3-4net/mptcp/protocol.h
+72-682 files not shown
+81-708 files