mirror of
https://github.com/torvalds/linux.git
synced 2026-10-23 23:51:02 +02:00
f99005fbed
1484983 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Linus Torvalds
|
f99005fbed |
vfs-7.3-rc7.fixes
Please consider pulling these changes from the signed vfs-7.3-rc7.fixes tag.
Thanks!
Christian
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRAhzRXHqcMeLMyaSiRxhvAZXjcogUCasilxwAKCRCRxhvAZXjc
ooQTAQD6awSrQcUIG0ca5hbowpn7sLi8kWGnmzf2yydKSyp3bwEAnpSQEw3BXUKH
0O7JEyZFL0VcMTTceSPKkKCqGg5nugI=
=Wc48
-----END PGP SIGNATURE-----
Merge tag 'vfs-7.3-rc7.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs
Pull vfs fixes from Christian Brauner:
"This contains fixes for the current development cycle.
All of them came out of a review of the mount code that started with a
bug report. The review modeled the corner cases of mount propagation,
unmounting and mount reference counting and turned up a lot of bugs.
Most of them years old. Most fixes come with a selftest.
- Rework connected mounts.
A mount that is unmounted together with its parent can stay
attached to the parent to keep its mountpoint covered. That happens
when the mountpoint is removed with rmdir(), unlink() or rename(),
when a detached tree is dissolved, and for locked mounts in any
umount that isn't synchronous, including the teardown of their
mount namespace. The parent then owns the child and drops it on its
own final mntput(). So any reference from the child's superblock
back to one of its ancestors becomes a cycle that is never freed.
A loop device backed by an image on a tmpfs and mounted on that
same tmpfs is enough. Remove the directory the tmpfs is mounted on
from the host, let the container's mount namespace exit, and the
loop device, the tmpfs and the filesystem on the loop device are
leaked for good. The same works with autofs, zram, ecryptfs,
binfmt_misc, fuse passthrough, zloop, a mass storage gadget and md,
and the selftests have reproducers for them. This has been possible
since v4.1. It is also why "put_mnt_ns(): leave mounts connected"
was reverted in -rc5. Keeping every mount of a dying mount
namespace connected made these cycles trivial to create.
Every unmounted mount is now detached from its parent. Where the
mountpoint has to stay covered the mount leaves a cover on the
parent instead, allocated together with the mount. A lookup on the
unmounted parent that hits a cover finds an empty immutable
directory or file on the private nullfs instance. Nothing leads
from a cover to another mount, so no unmounted mount owns another
one and no cycle can form.
This is visible to userspace. A formerly connected mount can no
longer be reached through its unmounted parent and ".." inside it
leads nowhere, as for every other lazily unmounted mount.
With that the private nullfs instance becomes reachable from
userspace, so it now refuses mounts on top, is mounted read-only,
and refuses fsnotify marks and file locks. Its inodes are shared by
every holder and a watch or a lock would otherwise reach across
users. may_decode_fh() now also decides its subtree check under a
single mount_lock hold, as a racing umount could otherwise let it
decode into what a locked child covered.
- umount:
* Don't silently unmount busy mounts.
Since v4.13 propagate_umount() takes down propagated copies of
the victim with children as long as each child is an overmount or
another copy of the victim, but propagate_mount_busy() only ever
checked copies without children or with just an overmount. A
container that moved a tree beneath its copy of a host mount lost
that tree from under its open file descriptor to a plain umount()
on the host. propagate_mount_busy() now applies the same rules,
walking each chain of copies once.
* Don't let a migrating task hide its reference from umount().
mnt_get_count() sums the per-cpu counters under mount_lock but
the mntget() and mntput() fast paths don't take it. A task that
takes a reference on a cpu the sum has already passed and drops
it after migrating to one the sum hasn't reached yet hides the
reference it held to begin with, and umount() succeeds with the
file still open. Gets and puts now live in separate per-cpu
counters and all puts are summed before all gets with a full
barrier in between, the way srcu_readers_active_idx_check() does
it. mntget() is unchanged and mntput() gains an smp_wmb().
* Check each submount for references right before unmounting it.
shrink_submounts() and mark_mounts_for_expiry() checked all their
victims up front. Unmounting the first could move a busy
overmount to where the next victim's propagated copy is looked up
and it was then unmounted without a check.
* Never expire a locked mount.
A shrinkable mount moved beneath a locked mount with
MOVE_MOUNT_BENEATH takes over the lock, and umount() of an
unlocked ancestor expired it and revealed what it covered. That
umount() now fails with EBUSY as it does for any other locked
child. A lazy umount still takes the whole tree.
- Overmounts and locked mounts:
* Unhash a dentry before detaching the mounts on it.
unlink(), rmdir() and rename() detach the mounts on the victim
but only d_delete() it once its inode is unlocked, a window that
includes an expedited RCU grace period. In between, a lookup from
a mount namespace in which the dentry is a mountpoint found it
hashed, positive and uncovered. Drop the dentry first, as
d_invalidate() already does.
* Don't reveal overmounted entries in refwalk.
A refwalk that had grabbed the dentry before the unlink never
rechecked it the way rcuwalk does with d_seq and mount_lock.
Without any artificial widening three walkers read the covered
file 27 times in a minute. step_into() now fails an unhashed
dentry marked DCACHE_CANT_MOUNT with -ESTALE and the walk is
retried.
* Keep covered mounts covered in OPEN_TREE_NAMESPACE.
Creating such a mount namespace only takes a user namespace and
the copy followed bind mount rules: no children without
AT_RECURSIVE and no unbindable mounts with it. An unprivileged
user could see what mounts covered in the source, such as the
parts of /proc and /sys that container runtimes mask. If the
caller doesn't own the source mount namespace a non-recursive
copy of a mount with something mounted below the requested
directory is now refused and a recursive copy includes unbindable
mounts, the way unshare() copies.
* Keep the lock on a mount that a propagated copy is moved beneath.
MNT_LOCKED moved to any mount that ended up beneath a locked
mount, propagated copies included. A host mount and umount on a
directory covered by a locked mount in a less privileged mount
namespace left that cover unlocked for the namespace's owner to
remove. Only mounts the caller places beneath take over the lock
now.
* Handle mount locking for automounts correctly. Which copies to
lock was decided by the mount namespace of the task that
triggered the automount. A task in a user namespace that
triggered one on a host mount through a file descriptor got the
host's own automount locked while its own copy stayed unlocked
and could have nosuid, nodev and noexec cleared. Use the owner of
the mount namespace the mount lands in.
- Use-after-free and crashes:
* Refuse an automount below a mount that is in no namespace.
The private clones overlayfs uses for its layers have the
MNT_NS_INTERNAL error pointer as their namespace, which
finish_automount() let through and count_mounts() dereferenced. A
fanotify filesystem mark on an overlayfs lower layer hands out
file descriptors on such a clone. With debugfs as the lower layer
opening "tracing" oopses with namespace_sem held for writing and
every mount operation on the system blocks from then on.
* Reset the old parent's ->overmount in mnt_change_mountpoint().
When propagate_umount() moved an overmount off a mount that a
file descriptor kept alive, MOVE_MOUNT_BENEATH through that
descriptor later followed the stale pointer into the freed
overmount.
* statmount() with STATMOUNT_BY_FD and pivot_root() read the parent
of a mount that may be unmounted and only held by a file
descriptor, while the parent's final mntput() can free it.
statmount() now reads it under mount_lock and pivot_root() first
checks that both mounts are in the caller's mount namespace.
* Queue a mount only once for mount notifications. A mount
reparented by one umount_tree() and taken down by the next under
the same namespace_sem hold, as in shrink_submounts(), was queued
twice. That cut the mounts queued in between out of notify_list
while it still pointed at them, and once they were freed every
later mount operation walked freed memory.
* Don't let a pseudo dentry become the root of a mount. A bind
mount of a bpf token file did that with a DCACHE_NORCU dentry,
which is freed without an RCU grace period while lockless path
walks may still look at it. Refuse to clone such a mount.
* Don't inherit MNT_UMOUNT in clone_mnt(). A bind mount of a lazily
unmounted nsfs or pidfs mount through its file descriptor started
out flagged as unmounted. Among other things __detach_mounts()
then dropped the namespace's reference on it, the mount outlived
its namespace and mount_setattr() through the descriptor read the
freed namespace. A recursive bind mount of such a mount also
copied the unmounted stack still attached to it. That now fails
with EINVAL, copying the mount itself still works.
* Remove the fsnotify marks of a mount namespace in free_mnt_ns()
instead of the RCU callback that frees the namespace, where
taking the group mutexes meant sleeping in softirq context.
- Propagation and copies:
* Keep a copied mount unbindable. Since v6.17 clone_mnt() didn't
copy the unbindable flag, so every mount namespace created with
CLONE_NEWNS had bindable copies of all unbindable mounts. This
had been fixed once before.
* Refuse MOVE_MOUNT_SET_GROUP on an unbindable mount. It made the
mount an unbindable slave, a state nothing else can produce, or
silently dropped the unbindable flag. CRIU applies MS_UNBINDABLE
after restoring sharing and isn't affected.
* Check a recursive bind mount for mount namespace loops.
Recursively bind mounting a tree from another mount namespace
could put a mount of a namespace's file inside that same
namespace, which then pins itself and all its mounts. Repeating
it leaks without limit, the reproducer took Shmem from 380 kB to
65916 kB. The copy is now checked with check_for_nsfs_mounts()
before it is grafted, as move_mount() does.
* Look at the topmost mount for a mount namespace file.
attach_recursive_mnt() never looked at the topmost mount of the
source's chain of overmounts. If that was the chain's only mount
namespace file an existing mount at a propagated destination got
buried below the root of the nsfs file where no path walk reaches
it.
* Don't put a mountpoint on a dentry that's being removed.
attach_recursive_mnt() makes a mountpoint of the source's root
without its inode lock, so a racing rmdir() of that directory
could leave a mount on it that nothing ever detaches.
d_set_mounted() now checks cant_mount() as well.
- nullfs:
* Take no inode lock for readdir of an immutable directory.
The root of every empty mount namespace is the same nullfs
directory and iterate_dir() held its i_rwsem across
->iterate_shared(). A reader whose buffer faults on a FUSE mount
of its own holds it for as long as its server wants, and with an
exclusive locker queued behind it every lookup that misses the
dcache, every create and every mount in that directory waits. One
user of an empty mount namespace stalls all others. Directories
with the new FOP_IMMUTABLE flag skip the lock.
* Refuse to reconfigure internal superblocks through fspick(),
MS_REMOUNT or the read-only remount that a synchronous umount()
of the root does. For nullfs only root in the initial user
namespace could do it, but the superblock is shared by every
mount namespace and the flags showed up in statfs() for all of
them.
* Don't update the access time on nullfs and refuse F_SET_RW_HINT
on an immutable inode.
- unshare: Free an nsproxy that was never installed with
nsproxy_free() when set_cred_ucounts() fails. put_nsproxy() dropped
active references that were never taken, which triggered a warning
and hid the caller's own namespaces from listns().
- Smaller changes: mount_setattr() checks the target before it walks
the tree to allocate peer group ids, unshare() puts the old
fs_struct before the old namespaces, dissolve_on_fput() drops the
file's reference to the tree itself, disconnect_mount() is
simplified and the documentation of the propagated unmount rule is
brought up to date"
* tag 'vfs-7.3-rc7.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: (58 commits)
namespace: simplify disconnect_mount()
selftests/filesystems: test covered mounts
namespace: rework connected mounts
nullfs: add an empty immutable regular file
selftests/filesystems: check that reading the root of an empty mount namespace stalls nobody
selftests/filesystems: add a helper that holds a readdir in a page fault
readdir: take no inode lock on an immutable directory
nullfs: refuse file locks
fsnotify: let a filesystem refuse marks on its objects
namespace: nothing is mounted on or written through knullfs
namespace: keep the private nullfs instance in knullfs
fhandle: decide the subtree check under mount_lock
selftests/filesystems: check that an automount below an overlay layer is refused
selftests/filesystems: check the atime of the empty mount namespace root
selftests/filesystems: check that a lock lands on the right mount and stays
namespace: keep the lock on a mount that a propagated copy is moved beneath
namespace: never expire a locked mount
nullfs: don't update the access time
namespace: handle mount locking for automounts correctly
namespace: refuse an automount below a mount that is in no namespace
...
|
||
|
Linus Torvalds
|
9515f634db |
arm64 fixes for -rc7
- Fix PMU EL2 trap configuration for CPUs with an IMPDEF PMU.
- Fix kcov boot selftest failure by excluding our early IRQ entry code.
-----BEGIN PGP SIGNATURE-----
iQFEBAABCgAuFiEEPxTL6PPUbjXGY88ct6xw3ITBYzQFAmrH1N8QHHdpbGxAa2Vy
bmVsLm9yZwAKCRC3rHDchMFjNHG0CACV2EKHHOdY/g1+PA6NmNeWzVlFT0nczOSh
m/iF+SHdZ+ZcFdipKFQd5cMVpDyVubOvJjuvlFQYreM1AkNrbTqavYfHwbF8mmdF
iqSZIjimjPUBmAJtxlobgP1UPUypI6Chnu0GTnLohufaznEhVqBj97aaE3xyMe3F
muX6d5yybK+wUi/iNt+gnsDNnGS9nDv0/Az7lUeqE1kSFWISz0UQa/pyEDtm4XT9
kzaWsRuRiRNb86nxalA5lvGaZd+RRXtMkUGp0OB3TCgN5WyfgFf3QiSufcYS3RlN
aozeM3nZFaSU4XMH8Ce1XbUkfr1HNA18MgwMSzorjLMBs56PAvax
=Xwu1
-----END PGP SIGNATURE-----
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Will Deacon:
"It finally seems to have calmed down on the arm64 fixes front, so
please pull these two straightforward fixes for -rc7. One fixes the
EL2 trap configuration for implementation-defined CPU PMU hardware
during boot and the other fixes a kcov selftest failure by excluding
our softirq early entry code:
- Fix PMU EL2 trap configuration for CPUs with an IMPDEF PMU
- Fix kcov boot selftest failure by excluding our early IRQ entry
code"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: irq: exclude the softirq stack switch from KCOV
arm64/boot: Don't set PMUv3p9 FGT2 bits without PMUv3
|
||
|
Linus Torvalds
|
af32da41b0 |
Including fixes from wireless, wireguard, CAN and Bluetooth.
We have one known regression to wrap up in VLAN handling.
Current release - regressions:
- Bluetooth: RFCOMM: fix deadlock on rfcomm_mutex
Previous releases - regressions:
- can: fix regression in handling RPS after migrating metadata to skb_ext
- eth: iavf: fix regressions in reconfig impacting bonding
- eth: mana: fix packet forwarding performance regression
- eth: stmmac: remove buggy VLAN acceleration support
Previous releases - always broken:
- a few high prio fixes for tun, and af_packet
- amt: fix a UaF on tunnel teardown
- eth: bnxt: fix PCIe AER recovery and FLR handling issues
- eth: macb: don't modify Tx skbs before taking ownership
- eth: axienet: don't leak Tx skbs on interface stop
- wifi: nxpwifi: number of LLM-ish fixes
- wifi: assorted mt76 fixes
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE6jPA+I1ugmIBA4hXMUZtbf5SIrsFAmrH6sMACgkQMUZtbf5S
IrtsDg//UvqATFotE+zcXa9yD3Pdg35wSH3uGZJYWIr+ZzEFW3hQdbh9rZy5ulX3
XUhFKlFSeEIarV4UstlvEbkLXSEqbaaFMfYBw03L6os3mGVQqMwi+C+7gn3aoqd4
NE1ct2NChnryr8ORCRjZW3OXjAguGuQBXZ4BFRnDWatbY0Cfuf35ap/RdNKztcEd
hct5rsd3LCNgGspjKq19LvD3npEcURebD9Do7mpwoIlw/AECLdCqUW0QkIJW/F6L
qZic95CyZXy39guuhI88cmfnSiZfz2grm8az4nlF9cDoJS1CW7peor6KzzisbT6m
Iltkwwj6v0NcVKE3f86oSSE5RS8kOJx+YcftNe0S+flZmCLpxopbF6VGfTJUmlyJ
CsQ6+n7iQd+1MoZZDGaJjgx14se5pqnnkJ38dVVi1OhomS/jpFYuw2U1dw1GzrJN
hLjPxmeF+HIFIKEbVjMyMbTCQGb8CfCQnH0qQ7XJnezImln+oA9ub66b/Zgwbubl
k8elLxkiFKgjT9bnwm4/+ZtI5VW8QRgV6sxPxpxD4tyVIaKrs2b9sqv9do3YPjPa
HGzMcRL9YMtGcv87gS8gjJRlAdkOWWzVDzw3nf3gMvAiedHIqvtUBcjB22+ueXqg
mJ0dT46BBTNbzrl8gljVTU5zm6ZYHxKm2vTTgbMdGJTzASNKfmE=
=+sxU
-----END PGP SIGNATURE-----
Merge tag 'net-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Pull networking fixes from Jakub Kicinski:
"Including fixes from wireless, wireguard, CAN and Bluetooth.
We have one known regression to wrap up in VLAN handling.
Current release - regressions:
- Bluetooth: RFCOMM: fix deadlock on rfcomm_mutex
Previous releases - regressions:
- can: fix regression in handling RPS after migrating metadata to skb_ext
- eth:
- iavf: fix regressions in reconfig impacting bonding
- mana: fix packet forwarding performance regression
- stmmac: remove buggy VLAN acceleration support
Previous releases - always broken:
- a few high prio fixes for tun, and af_packet
- amt: fix a UaF on tunnel teardown
- eth:
- bnxt: fix PCIe AER recovery and FLR handling issues
- macb: don't modify Tx skbs before taking ownership
- axienet: don't leak Tx skbs on interface stop
- wifi:
- nxpwifi: number of LLM-ish fixes
- assorted mt76 fixes"
* tag 'net-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (128 commits)
net: macb: copy shared skbs before appending the FCS
net: macb: check TX ring before modifying skb
vsock: Fix memory leak in vmci_transport_recv_dgram_cb()
wireguard: noise: reject response consumption after intermediate initiation
wireguard: queueing: preserve tstamp_type when encapsulating packet
net: openvswitch: validate transport header presence in set_ipv6_addr
net/smc: protect clcsock lifetime in smc_getname
ipv6: do not warn on route notification size race
ipv4: do not warn on route notification size race
ipv4: validate checksum_start before completing checksum
ptp: ocp: fix PCIe delay estimation calculation
xen/netfront: don't leak the skb when xennet_fill_frags() fails
net/packet: call packet_parse_headers after virtio_net_hdr_to_skb
xen/netfront: drop RX packets with a short Ethernet header
net: skbuff: don't leave stale bytes in skb_copy_and_csum_bits()
net: sparx5: free the matchall entry on destroy
selftests: mlxsw: Test port range occupancy on template create
mlxsw: spectrum_flower: Fix port range register leak in tmplt_create()
net: dsa: microchip: fix KSZ8765 fiber detection
net/mlx5e: Order ICOSQ cc update after CQ doorbell
...
|
||
|
Jakub Kicinski
|
37f12441f5 |
Merge branch 'net-macb-fix-software-fcs-handling-of-shared-and-requeued-skbs'
Nicolai Buchwitz says: ==================== net: macb: fix software FCS handling of shared and requeued skbs While testing the genet MTU series I used a Raspberry Pi CM5 (RP1 GEM) as pktgen source for the CM4. With clone_skb the CM5 rebooted after a few seconds. Further investigation showed that macb_pad_and_fcs() appends the FCS in place, so the shared skb grows with every transmit until BQL completes more than was queued and dql_completed() hits its BUG_ON. The same code also modifies the skb before the TX ring check, so a NETDEV_TX_BUSY retry gets an skb that was already replaced or grown. Patch 1 checks the ring first, patch 2 copies shared skbs. Tested on Raspberry CM5 with pktgen at 60/20000 bytes, clone_skb 0/ 1000, burst 1/32. ==================== Link: https://patch.msgid.link/20261006-nb-macb-shared-skb-net-v1-0-a80641479041@tipi-net.de Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Nicolai Buchwitz
|
9151d6c427 |
net: macb: copy shared skbs before appending the FCS
macb_pad_and_fcs() appends the FCS in place when the skb has tailroom.
A shared skb, as pktgen sends in clone_skb mode, grows by one FCS per
transmit. BQL then completes more bytes than were queued and
dql_completed() hits its BUG_ON.
On a Raspberry Pi CM5 (RP1 GEM) pktgen with clone_skb 1000 burst 32 at
60 bytes kills the box within seconds.
Copy shared skbs before appending the FCS. Clearing IFF_TX_SKB_SHARING
would also fix it but makes pktgen refuse clone_skb on macb.
Fixes:
|
||
|
Nicolai Buchwitz
|
6b48ed85ae |
net: macb: check TX ring before modifying skb
macb_pad_and_fcs() replaces or extends the skb before the ring space
check. On NETDEV_TX_BUSY the stack requeues an skb that is already freed
or grown.
Check the ring first, using the padded length for the descriptor count.
Nonlinear skbs always take the copy path so the count can assume a
linear skb.
Fixes:
|
||
|
Ilia Gavrilov
|
7c24a4e87e |
vsock: Fix memory leak in vmci_transport_recv_dgram_cb()
During the closure of a datagram socket, the vmci_transport_recv_dgram_cb()
function may be called, which will add the packets
to the socket's backlog; then, after the receive queue is cleared,
the __release_sock() function will move the packet back from the socket's
backlog to the receive queue, which will lead to a memory leak.
sock_close
__sock_release
__vsock_release
// take ownership by user-space
lock_sock_nested
sock_set_flag(sk, SOCK_DEAD)
vmci_transport_release
vmci_dispatch_dgs
vmci_datagram_invoke_guest_handler
vmci_transport_recv_dgram_cb
sk_receive_skb
if (!sock_owned_by_user(sk))
[...]
(!) else if sk_add_backlog()
[...]
(!) skb_queue_purge(&sk->sk_receive_queue)
release_sock
__release_sock
// move all packets from the backlog
// to the receive queue
(!) sk_backlog_rcv
vsock_queue_rcv_skb
[...]
__sock_queue_rcv_skb
if (!sock_flag(sk, SOCK_DEAD))
// Since the socket is "dead", the function will not
// be called
sk->sk_data_ready(sk)
sock_release_ownership(sk);
sock_put
Add a receive queue cleanup in the socket destructor to fix this.
syzkaller report:
unreferenced object 0xffff8880117bfb80 (size 240):
comm "irq/56-vmw_vmci", pid 205, jiffies 4295064448 (age 73.992s)
hex dump (first 32 bytes):
78 dc 26 1e 80 88 ff ff 78 dc 26 1e 80 88 ff ff x.&.....x.&.....
00 00 00 00 00 00 00 00 c0 da 26 1e 80 88 ff ff ..........&.....
backtrace:
[<ffffffff82be8d97>] __alloc_skb+0x287/0x330 net/core/skbuff.c:505
[<ffffffffa114bcbd>] vmci_transport_recv_dgram_cb+0xbd/0x210 [vmw_vsock_vmci_transport]
[<ffffffffa05072c6>] vmci_datagram_invoke_guest_handler+0x366/0x450 [vmw_vmci]
[<ffffffffa050ad75>] vmci_dispatch_dgs+0x235/0x490 [vmw_vmci]
[<ffffffffa050b025>] vmci_interrupt+0x55/0x290 [vmw_vmci]
[<ffffffff8137ad2b>] irq_thread_fn+0x8b/0x1a0 kernel/irq/manage.c:1205
[<ffffffff8137c7ae>] irq_thread+0x28e/0x530 kernel/irq/manage.c:1314
[<ffffffff81253dd6>] kthread+0x2e6/0x3a0 kernel/kthread.c:376
[<ffffffff81004392>] ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:295
Found by InfoTeCS on behalf of Linux Verification Center
(linuxtesting.org) with Syzkaller.
Fixes:
|
||
|
Jakub Kicinski
|
fe4167bf53 |
Merge branch 'wireguard-fixes-for-7-3-rc7'
Jason A. Donenfeld says: ==================== WireGuard fixes for 7.3-rc7 This series contains two important WireGuard fixes 1) Stop zeroing out skb->tstamp_type when encapsulating packets, so that fq behaves correctly, from Ramses de Norre. 2) Make sure handshake state isn't swapped out while locks are released, reported by Jérémy Jean. ==================== Link: https://patch.msgid.link/20261008130124.724119-1-Jason@zx2c4.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Jason A. Donenfeld
|
d0305f8d90 |
wireguard: noise: reject response consumption after intermediate initiation
Two threads begin processing the identical response message, received
twice. The first thread, A, runs. While it's running, the second one,
B, gets partway through, and during that slow calculation, or even while
blocking on down_write(), A completes and then also a handshake
initiation that's already been queued up runs in thread C, which itself
takes that same down_write(). The handshake initiation creation
succeeds, and sets the state back to waiting-for-response, and calls
up_write(), at which point thread B resumes, because either its finished
its calculations or was finally allowed to acquire down_write(). Thread
B then copies the state back to the peer, and begins a new session,
using that state, which is the same session as the one made in thread A.
Thread A Thread B Thread C
down_read()
sA = handshake->state
memcpy(cA, handshake->crypto)
up_read()
if (sA != 1)
goto fail
slow_crypto(cA)
down_read()
sB = handshake->state
memcpy(cB, handshake->crypto)
up_read()
if (sB != 1)
goto fail
slow_crypto(cB)
down_write()
if (sA != handshake->state)
goto fail
memcpy(handshake->crypto, cA)
handshake->state = 2
up_write()
down_write()
if (handshake->state != 2)
goto fail
derive_session(handshake->crypto)
up_write()
down_write()
slow_crypto(handshake->crypto)
handshake->state = 1
up_write()
down_write()
if (sB != handshake->state)
goto fail
memcpy(handshake->crypto, cB)
handshake->state = 2
up_write()
down_write()
if (handshake->state != 2)
goto fail
derive_session(handshake->crypto)
up_write()
This seems basically impossible to hit in a meaningful way in practice,
but ensure that it absolutely cannot happen by comparing the ephemeral
private key that's on the stack with the latest one that the peer's
handshake state has.
Cc: stable@vger.kernel.org
Fixes:
|
||
|
Ramses de Norre
|
65ab9de4bd |
wireguard: queueing: preserve tstamp_type when encapsulating packet
Sending traffic through a wireguard tunnel on a host using the fq qdisc fills the log with: fq: likely mono tstamp with tstamp_type 0 An skb carries a timestamp in skb->tstamp and, separately, a skb->tstamp_type field recording which clock that timestamp came from. The two have to agree. When wireguard encapsulates a packet it calls wg_reset_packet(), which clears the fields that must not leak from the inner packet into the tunnel packet. It does so in two steps: skb_scrub_packet(skb, true); memset(&skb->headers, 0, sizeof(skb->headers)); skb_scrub_packet() deliberately keeps skb->tstamp when it holds a monotonic timestamp: that value is the time the packet is scheduled to be sent, and the qdisc still needs it. The memset then zeroes skb->tstamp_type, because that field sits inside the headers group while skb->tstamp does not. The packet therefore leaves wireguard carrying a monotonic timestamp labelled as a realtime one. Nothing noticed until commit |
||
|
Fernando Fernandez Mancera
|
3c6a4b1133 |
net: openvswitch: validate transport header presence in set_ipv6_addr
When executing IPv6 address rewrite actions on IPv6 fragments,
set_ipv6_addr() calls update_ipv6_checksum(). If parse_ipv6hdr()
processes a non-first IPv6 fragment, it sets key->ip.proto to
NEXTHDR_FRAGMENT and returns early without calling
skb_set_transport_header().
update_ipv6_checksum() unconditionally evaluates skb_transport_offset()
on entry before checking l4_proto. Because skb->transport_header is
uninitialized, this triggers a warning under CONFIG_DEBUG_NET=y although
it is completely harmless.
Fix this by returning early in update_ipv6_checksum() if l4_proto is
NEXTHDR_FRAGMENT. This avoids reading the uninitialized transport offset
for fragments while preserving the debug warning for any other protocol
where the transport header is unexpectedly missing.
See the syzbot trace:
!skb_transport_header_was_set(skb)
WARNING: ./include/linux/skbuff.h:3075 at skb_transport_header include/linux/skbuff.h:3075 [inline], CPU#1: syz-executor463/5635
WARNING: ./include/linux/skbuff.h:3075 at skb_transport_offset include/linux/skbuff.h:3250 [inline], CPU#1: syz-executor463/5635
WARNING: ./include/linux/skbuff.h:3075 at update_ipv6_checksum net/openvswitch/actions.c:361 [inline], CPU#1: syz-executor463/5635
WARNING: ./include/linux/skbuff.h:3075 at set_ipv6_addr+0x462/0x660 net/openvswitch/actions.c:399, CPU#1: syz-executor463/5635
[...]
RIP: 0010:skb_transport_header include/linux/skbuff.h:3075 [inline]
RIP: 0010:skb_transport_offset include/linux/skbuff.h:3250 [inline]
RIP: 0010:update_ipv6_checksum net/openvswitch/actions.c:361 [inline]
RIP: 0010:set_ipv6_addr+0x462/0x660 net/openvswitch/actions.c:399
[...]
Call Trace:
<TASK>
set_ipv6 net/openvswitch/actions.c:531 [inline]
do_execute_actions+0x557e/0x8600 net/openvswitch/actions.c:1366
ovs_execute_actions+0xde/0x520 net/openvswitch/actions.c:1592
ovs_packet_cmd_execute+0xb4f/0xf10 net/openvswitch/datapath.c:705
genl_family_rcv_msg_doit+0x233/0x340 net/netlink/genetlink.c:1114
genl_rcv_msg+0x614/0x7a0 net/netlink/genetlink.c:1209
netlink_rcv_skb+0x226/0x4a0 net/netlink/af_netlink.c:2572
genl_rcv+0x28/0x40 net/netlink/genetlink.c:1218
netlink_unicast+0x7bd/0x940 net/netlink/af_netlink.c:1361
netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1916
sock_sendmsg_nosec+0x14e/0x190 net/socket.c:800
Reported-by: syzbot+4cc63fcfb3845e149969@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=4cc63fcfb3845e149969
Fixes:
|
||
|
Chengfeng Ye
|
64a6b36b0e |
net/smc: protect clcsock lifetime in smc_getname
smc_getname() dereferences smc->clcsock without holding
clcsock_release_lock. Link-group termination can release the CLC socket
through smc_close_active_abort() while the SMC socket is still open,
for example after shutdown(SHUT_WR).
A getsockname() caller can load smc->clcsock, then the termination worker
can clear the pointer and call sock_release() before the caller accesses
clcsock->ops or invokes getname(). This causes a use-after-free; if the
worker clears the pointer before the load, it causes a NULL dereference.
The syscall's file reference keeps the SMC socket alive but does not
prevent asynchronous release of its CLC socket.
KASAN reported the following with test-only timing instrumentation:
BUG: KASAN: slab-use-after-free in smc_getname+0x19e/0x1b0
Read of size 8 at addr ffff888109abb4e0 by task poc/103
Call Trace:
smc_getname+0x19e/0x1b0
do_getsockname+0xe5/0x170
__sys_getsockname+0x8c/0x100
Allocated by task 95:
sock_alloc_inode+0x1e/0x280
sock_alloc+0x3d/0x240
__sock_create+0x7e/0x430
smc_create+0x121/0x240
Freed by task 0:
kmem_cache_free+0xcc/0x340
rcu_core+0x50a/0x1850
Last potentially related work creation:
evict+0x446/0x6c0
smc_clcsock_release+0xa8/0xd0
smc_close_active_abort+0x26a/0x3a0
__smc_lgr_terminate.part.0+0x137/0x2e0
Hold clcsock_release_lock across the pointer check and the getname()
callback to serialize with smc_clcsock_release(). Return -EBADF if the
CLC socket has already been released, preserving the existing peer
state check and the callback's return value otherwise.
Fixes:
|
||
|
Jakub Kicinski
|
d5788029c3 |
Merge branch 'ipv4-ipv6-do-not-warn-on-route-notification-size-races'
Daehyeon Ko says: ==================== ipv4/ipv6: do not warn on route notification size races A nexthop group can grow between route notification sizing and filling. Both IPv4 and IPv6 can then legitimately return -EMSGSIZE, so remove the stale warnings while preserving their existing error paths. Patch 1 is unchanged from v1. Patch 2 adds the IPv6 counterpart requested by Ido. No new build or runtime test was run; both changes only delete the stale comment and WARN_ON(). ==================== Link: https://patch.msgid.link/cover.1791423190.git.4ncienth@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Daehyeon Ko
|
c97426ec64 |
ipv6: do not warn on route notification size race
fib6_info_hw_flags_set() sizes the skb with rt6_nlmsg_size() and later
fills it with rt6_fill_node(). With nexthop compatibility mode enabled,
a concurrent replacement can grow the group between these independent
snapshots. rt6_fill_node() can then legitimately return -EMSGSIZE, so
the warning does not prove a sizing bug.
Remove the warning. The existing error path still frees the skb and
reports the error to listeners.
Fixes:
|
||
|
Daehyeon Ko
|
e02a5b6588 |
ipv4: do not warn on route notification size race
Commit |
||
|
Michael S. Tsirkin
|
6785011f8b |
ipv4: validate checksum_start before completing checksum
If a packet with bad checksum metadata gets into the ipv4 stack, skb_checksum_help can corrupt the network header and cause a bunch of mischief. This was discovered and reported by Paulos, and has been reporoduced by others independently since. We really shouldn't allow such packets in, but as a defence in depth measure, let's also check before we complete the checksum. A more complete validation at input is forthcoming, but needs more work. Cc: stable@vger.kernel.org Fixes: |
||
|
Vadim Fedorenko
|
f8c8bd159a |
ptp: ocp: fix PCIe delay estimation calculation
The commit in fixes introduced a high cap for delayas U64_MAX value
while ktime_t is actually s64. This is wrong cap as it becomes negative
value and any comparison to a real delay will fail to update delay
value. Use KTIME_MAX constant as correct max cap for PCIe delay.
The issue was hit in production (a negative value is observed):
# cat /sys/class/timecard/ocp0/ts_window_adjust
-3
Fixes:
|
||
|
Josef Bacik
|
93ccaf1c26 |
xen/netfront: don't leak the skb when xennet_fill_frags() fails
When a response chain has more slots than fit in the skb's frags,
xennet_fill_frags() returns an error and xennet_poll() jumps to its
error path. That path moves what's left on tmpq to errq to be freed,
but the skb being filled was already dequeued from tmpq, so it's never
freed. Each chain that overflows leaks the skb and the pages attached
to it as frags, and the backend decides how many slots it sends.
Put the skb back on tmpq before taking the error path, like the
xennet_set_skb_gso() failure just above it does.
Fixes:
|
||
|
Willem de Bruijn
|
513e23857a |
net/packet: call packet_parse_headers after virtio_net_hdr_to_skb
SOCK_RAW packet sockets incorrectly drop VLAN-tagged GSO packets without VIRTIO_NET_HDR_F_NEEDS_CSUM. packet_parse_headers() sets skb->protocol to VLAN but advances skb->network_header past the VLAN tags. virtio_net_hdr_to_skb() then flow dissects these packets, which parses the network header as a VLAN tag, and fails. Call packet_parse_headers() after virtio_net_hdr_to_skb() instead. This matches tun_get_user() and tap_get_user() and thus simplifies overall complexity. Commit |
||
|
Josef Bacik
|
089e58805c |
xen/netfront: drop RX packets with a short Ethernet header
handle_incoming_queue() pulls pull_to bytes into the head before
calling eth_type_trans(). pull_to is the length of the first RX slot,
capped at RX_COPY_THRESHOLD, and that length comes from the backend.
Nothing checks it against ETH_HLEN.
If the first slot is shorter than ETH_HLEN and more slots follow, the
head ends up shorter than an Ethernet header while skb->len is longer,
and eth_type_trans() BUG()s in __skb_pull(). If the whole packet is
shorter than ETH_HLEN, eth_type_trans() reads the header past the end
of the data instead.
Pull at least ETH_HLEN, and drop the packet if that fails, which also
drops packets too short to hold an Ethernet header. This also checks
the return value of the pull, which was ignored.
Fixes:
|
||
|
Josef Bacik
|
ab9414ed70 |
net: skbuff: don't leave stale bytes in skb_copy_and_csum_bits()
When skb_copy_and_csum_bits() reaches unreadable frags it returns 0
after copying only the linear part, and the rest of the caller's buffer
is left as it was. The callers copy into a buffer that is about to go
out on the wire: an ICMP error quoting the offending packet, or a
driver's TX bounce buffer in skb_copy_and_csum_dev(). Neither buffer
is zeroed beforehand, so whatever was in memory there gets sent.
Zero the part of the buffer we didn't fill. The checksum usually
won't match the data any more, so the receiver will usually drop the
packet, but either way it no longer carries anything it shouldn't.
Only zero for a positive @len, a negative one from a broken caller must
not turn into a huge memset().
Fixes:
|
||
|
Daniel Machon
|
2b82e16d60 |
net: sparx5: free the matchall entry on destroy
sparx5_tc_matchall_replace() allocates a struct sparx5_mall_entry for
every offloaded matchall filter and adds it to sparx5->mall_entries.
sparx5_tc_matchall_destroy() removes the entry from the list, but never
frees it, so the entry of every deleted mirror and goto matchall filter
is leaked.
Free the entry after unlinking it.
The leak was discovered by an AI code review agent, and reproduced with
kmemleak on a lan969x EV board (EV23X71A) by repeatedly adding and
deleting matchall mirror and goto filters. With the fix, kmemleak no
longer reports the leak.
Cc: stable@vger.kernel.org
Fixes:
|
||
|
Jakub Kicinski
|
ff6f5157e0 |
Merge branch 'mlxsw-fix-port-range-register-leak'
Petr Machata says: ==================== mlxsw: Fix port range register leak When the mlxsw driver parses a port range template rule, it acquires the actual port range registers. The parsing is only done to determine the element usage, so the registers can be deallocated right away, but this is never done, and the registers are leaked. Plug this leak and add a selftest that would have caught it. ==================== Link: https://patch.msgid.link/cover.1791294384.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Petr Machata
|
71198b59df |
selftests: mlxsw: Test port range occupancy on template create
Add a test that creates a tc chain template matching on both source and destination port ranges and verifies via devlink-resource occupancy that this does not leak port range registers, neither while the template exists nor after it is deleted. Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/e7b37b80adb7ac8b0ef20a22d7654a6656c1c545.1791294384.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Petr Machata
|
7ea07afb23 |
mlxsw: spectrum_flower: Fix port range register leak in tmplt_create()
mlxsw_sp_flower_tmplt_create() parses a flow_cls_offload template
into a stack-local struct mlxsw_sp_acl_rule_info purely to compute
rulei.values.elusage. Parsing can acquire port range registers via
mlxsw_sp_flower_parse_ports_range(), but since this rulei never goes
through mlxsw_sp_acl_rulei_destroy(), those registers were never
released, including through chain template deletion.
Factor out of mlxsw_sp_acl_rulei_destroy() the code to actually
release the necessary resources and call from
mlxsw_sp_flower_tmplt_create() to plug the leak.
The issue was found during a review of Wentao Liang's patch referenced
below.
Fixes:
|
||
|
Sebastien Royen
|
fc13ba44da |
net: dsa: microchip: fix KSZ8765 fiber detection
The KSZ8765 is similar to the KSZ8795 but has two fiber ports.
KSZ8_PORT_STATUS_0 is used to detect fiber mode. It is currently
defined as 0x08, which is the Global Control 6 MIB Control register
and has bit 7 defined as Flush Counter.
Set KSZ8_PORT_STATUS_0 to 0x18, which is the Port 1 Status 0 register
where bit 7 is the Fiber Mode bit.
This issue was discovered when upgrading an embedded device from kernel
5.10 to 6.16. The device was using a KSZ8765 device tree configuration
and the corresponding hardware, but during boot the kernel incorrectly
detected it as a KSZ8795. The relevant boot messages were:
ksz-switch spi0.0: found switch: KSZ8795, rev 0
ksz-switch spi0.0: Device tree specifies chip KSZ8765 but found KSZ8795, please fix it!
Cc: stable@vger.kernel.org
Fixes:
|
||
|
Li RongQing
|
b056ca4d37 |
net/mlx5e: Order ICOSQ cc update after CQ doorbell
mlx5e_poll_ico_cq() requires sq->cc to be updated only after
mlx5_cqwq_update_db_record(), otherwise a CQ overrun may occur.
The current implementation updates sq->cc before the CQ doorbell
record, violating this ordering requirement.
Update the CQ doorbell record first and use dma_wmb() before updating
sq->cc. This ensures that the CQ space is released to the device
before the corresponding ICOSQ consumer index is updated by software.
Fixes:
|
||
|
Jakub Kicinski
|
726be6a0e8 |
Merge branch 'veth-fix-peer-netdev_xdp_act_ndo_xmit-after-gro-is-toggled-while-down'
Tianyi Gao says: ==================== veth: fix peer NETDEV_XDP_ACT_NDO_XMIT after GRO is toggled while down Toggling GRO on a veth device while it is down leaves its peer's NETDEV_XDP_ACT_NDO_XMIT flag stale once the device comes up. XDP redirects into the peer are then rejected with -EOPNOTSUPP, or, if GRO was turned off, accepted and then dropped with -ENXIO. Patch 1 refreshes the peer's flags in veth_open(). Patch 2 extends veth.sh to check the peer's flag after GRO is toggled while the device is down, in both directions. ==================== Link: https://patch.msgid.link/20261006173241.65945-1-tianyi@cloudflare.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Tianyi Gao
|
c017800af5 |
selftests: net: veth: test peer ndo-xmit after GRO toggle while down
Test that toggling GRO on a veth device while it is down updates the peer's ndo-xmit XDP feature once the device comes up, for both GRO on and GRO off. xdp-features is only visible through netlink, so read it with the ynl CLI, as double_udp_encap.sh does. Skip the checks if the CLI is not found, as in an installed kselftest tree. Signed-off-by: Tianyi Gao <tianyi@cloudflare.com> Link: https://patch.msgid.link/20261006173241.65945-3-tianyi@cloudflare.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Tianyi Gao
|
3f09003999 |
veth: fix peer NETDEV_XDP_ACT_NDO_XMIT after GRO is toggled while down
A veth device advertises NETDEV_XDP_ACT_NDO_XMIT only if its peer has an XDP program attached or GRO enabled, that is, only if the peer will have NAPI to receive the frames. veth_set_features() updates the peer's flag when GRO is toggled, but returns early if the device is down, and veth_open() only refreshes the flags of the device being opened. Toggling GRO while the device is down therefore leaves the peer's flag stale after the device comes up. If GRO was enabled while down, the device comes up with NAPI but the peer does not advertise NDO_XMIT, and devmap rejects redirects to the peer with -EOPNOTSUPP. If GRO was disabled while down, the device comes up without NAPI but the peer still advertises NDO_XMIT, so redirects are accepted and then dropped in veth_xdp_xmit() with -ENXIO. Commit |
||
|
Hamza Mahfooz
|
259c4a5191 |
net: mana: reserve RX buffer headroom to fix forwarding performance
Commit |
||
|
Linus Torvalds
|
6c377d19d4 |
Mark the ext4 data=journal feature as being deprecated and will be
removed in 2028. Also designate the primary branch that Sashiko and other tools use to find the primary development branch in the ext4 tree. -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEK2m5VNv+CHkogTfJ8vlZVpUNgaMFAmrHtq4ACgkQ8vlZVpUN gaMFZAf/eACeBhy6Tm9s6MDAewS84BDeNd/WuUrIn+Jpt1jwpL83sNPY3rgleR7s spPpg7fJQJfFbRiyOj4YUNbwShCOJ61cOw/BrLBYD5HlkCNuexBNWEOEVB7HWAVv f+J7FLF8k/6lgzuXI4CNzC4NIpKiWLUi3zbGbjxZgtdsr1j7zThVn83WwuHqnJic dLlW5Twcwox0j2UDKRmERL1x8QBeghJPSX9u1xNEtx8/gEkAKGJ601MrbVmZPDDy FuXZUdOuyctLuiFMjvB20jVXMVCO0SMj5DiJ8vwGYV/OHVYcLxx7WP7KxJ/IKmK8 lk748C174vVDTLTSzBDIAnqctfkUxQ== =zILx -----END PGP SIGNATURE----- Merge tag 'ext4_for_linus-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 Pull ext4 fixes from Ted Ts'o: "Mark the ext4 data=journal feature as being deprecated and will be removed in 2028. Also designate the primary branch that Sashiko and other tools use to find the primary development branch in the ext4 tree" * tag 'ext4_for_linus-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: ext4: mark data=journal as deprecated and will be removed in January 2028. MAINTAINERS: name the ext4 dev branch |
||
|
Theodore Ts'o
|
3e78d7b063 |
ext4: mark data=journal as deprecated and will be removed in January 2028.
Signed-off-by: Theodore Ts'o <tytso@mit.edu> |
||
|
Matthias Goergens
|
4b1d04693e |
MAINTAINERS: name the ext4 dev branch
The ext4 T: entry names the repository without a branch, so tools that
default to the repository's HEAD select master, which still points at a
merge from October 2020 (
|
||
|
Linus Torvalds
|
47324d3a5b |
power sequencing fixes for v7.3-rc7
- add missing PCI device IDs for Thinkpad T14s gen6 which should have been part of commit |
||
|
Linus Torvalds
|
156c9ca041 |
gpio fixes for v7.3-rc7
- fix runtime PM leak in error path in gpio-xilinx - fix race when arming the IRQ poll worker in gpio-mpsse - fix devres cleanup path on probe error in gpio-exar -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEkeUTLeW1Rh17omX8BZ0uy/82hMMFAmrHWhAACgkQBZ0uy/82 hMOkgg/+LFRYaG+Y+ql27JO4LUuzqIdLyqhlGVCcXt74p21kxGTbohF9LgeqcmTi 1vV6CztX2puAnsZYwC9m8bHZrn5mJVu1on1u3gIsKQyooeTSoucZLWTCLl28SjNu HAH5DRUZe2ma/eMEfZaydANziJHjaniblq+E+wq7tS4F4djDJsgNzb34k2r4vldS VsxYo3KOcbXU0efGB4x002u0SQgYjcHEgRVg3Qi9lXDtMdUNYLMCAaOAlBNWvD/K CaQrUIM3XvOoVfnpg2JKd/IKg4d0ouUqQkmagTnS+Zbsj5G5vWYt6sL+PcME8cI0 jSGMH7NZhFHk7veChCLJA3jkvF2UKaroQKegs5KI239kG55eYrwhm0lSkkZIeaHC qLBEsrchAHjii1Mn27O9hK5oNpc/g2HRPEaoSvZGp4V7Q8UD37KsLgjr6jB/3Uy3 yCpREip+uTEZS/wcIRiR2HP03KIfJi9a0y8Ur8uDo/4WcQo5M5GGm+t3zQn4r74t bxrtYOqWEeZ/xXutTS34DqADaZpdGCAGRDjGBJhRNsO2RMrU2uoGCGPd5H/LLN6y Ss7/QWcm9EJuXp3waMdr25V49NUWZNo6zg0ywmGrxK7AZMyyD4sFI1btWOf1Z771 q7sAQuPoZ93pWpcKrSFxjGl2YHTS7x+yCEbO4fVOdmDupBW5xMw= =qEj0 -----END PGP SIGNATURE----- Merge tag 'gpio-fixes-for-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio fixes from Bartosz Golaszewski: - fix runtime PM leak in error path in gpio-xilinx - fix race when arming the IRQ poll worker in gpio-mpsse - fix devres cleanup path on probe error in gpio-exar * tag 'gpio-fixes-for-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: gpio: mpsse: fix race when arming the IRQ poll worker gpio: exar: initialize the ID before registering its cleanup gpio: xilinx: fix runtime PM leak on request error path |
||
|
Linus Torvalds
|
b732c98215 |
7 hotfixes. 4 are cc:stable.
- Update .mailmap entries for Andy Yan and John Garry. - Fix read-only MAP_SHARED /dev/zero mappings so they retain shared-file semantics instead of being treated as anonymous memory, also avoiding a CONFIG_DEBUG_VM assertion. - Fix 32-bit build warnings in the hugetlb-mmap selftest caused by using the wrong printf format for size_t values. - Fix a boot-time crash when early function tracing causes CPA to free kernel page tables before the workqueues used for deferred freeing are available. - Fix two MREMAP_DONTUNMAP locked_vm accounting leaks: one caused by an mlock-on-fault VMA self-merging, and one caused by partially remapping a locked VMA. -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQTTMBEPP41GrTpTJgfdBJ7gKXxAjgUCascg4wAKCRDdBJ7gKXxA jjLCAP4ygLUaOZmgJVAmD8loFAa/AB0CE1V+LZwBUyzqCogY6wD/Sp+JbhE+mZDS vjp7soYnDoqv7Gi872WTUx2rnjaLxAg= =qjI7 -----END PGP SIGNATURE----- Merge tag 'mm-hotfixes-stable-2026-10-07-21-48' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull MM fixes from Andrew Morton: - Update .mailmap entries for Andy Yan and John Garry - Fix read-only MAP_SHARED /dev/zero mappings so they retain shared-file semantics instead of being treated as anonymous memory, also avoiding a CONFIG_DEBUG_VM assertion - Fix 32-bit build warnings in the hugetlb-mmap selftest caused by using the wrong printf format for size_t values - Fix a boot-time crash when early function tracing causes CPA to free kernel page tables before the workqueues used for deferred freeing are available - Fix two MREMAP_DONTUNMAP locked_vm accounting leaks: one caused by an mlock-on-fault VMA self-merging, and one caused by partially remapping a locked VMA * tag 'mm-hotfixes-stable-2026-10-07-21-48' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mailmap: update entry for Andy Yan drivers/char/mem: mmap readonly MAP_SHARED-/dev/zero correctly selftests/mm: cleanup -Wformat issues in hugetlb-mmap mm: don't schedule deferred kernel page table freeing while booting mailmap: update addresses for John Garry mm/mremap: fix locked_vm leak by splitting VMA for MREMAP_DONTUNMAP mm/mremap: fix locked_vm leak from MREMAP_DONTUNMAP self-merge |
||
|
Linus Torvalds
|
0c2669a9f4 |
soc: fixes for 7.3, part 2
There are fixes in three ares this time:
- Four distinct issues in TEE firmware, all fairly minor
- Five devicetree mistakes on NXP i.MX8, lx2160a and Qualcomm
based machines, one of these may cause file system corruption
from an incorrect SD card supply voltage
- Five fixes for clk drivers on new Qualcomm platforms,
addressing issues with incorrect enable states
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmrBd1cACgkQmmx57+YA
GNlYxBAAhJs6mulHyhGSKOHYbvPHHHsCPFcWT6gLZRRy4lA50GwzptT8SAk6TmlS
C6wm81nVG27hdju5TMiExDUfjiTFd3sxpT8xDP1DVNAgZD6+s2LyFrFbAqRs0zxS
SoaZgzsu7q2pD4wBQpQgOM38YODl05CdzwY4YZqiFoomYHSQzI4xlTVGY6/fcJcm
79fRV63LUznRVtsy+ETMg9TdBcJjPY6huuH/C8JifXvl4Q6P99FGXvZp2rpiFqU0
Y3GXA58XtDqUyrwjbUXFrosmqAqsEU5x+iCA1EV2Y1P460rG4jyhXFAYHimJl9UH
Pnfq5Sb2r+JeK1li4HgHX8g3wDr6KUO/biuInNCUAUEFxQ6W7l+NRZTgjisB9m2W
O6Ju0WMXLMvDsm4OMxYyepxcV3fmxzYMvzs36EmJo67OAhETrTCRmU1M8l5N2s50
84wlGoGdLXYoYCKOzLKZBj77Y1zjoYcxBEDx5PLZR2kMWjxtW+zLkKK1NME39691
nDU+NfMAxbMl+28NCtP91ceaVvb+8Zf9vGDcf7RBz6fTZpwUtW9Z9L7x8MVl873a
88oZNHQrGXO+J6VcwskOIhlR5bDCPfpRQm2y2Y+wY6iz/Ie4Jh5n7J8prpzabs43
AuoGpNqHAVrkfklsr66cDzT43XX1KK59+QQwJiOXe5sDetk5m64=
=Mq24
-----END PGP SIGNATURE-----
Merge tag 'soc-fixes-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull SoC fixes from Arnd Bergmann:
- Four distinct issues in TEE firmware, all fairly minor
- Five devicetree mistakes on NXP i.MX8, lx2160a and Qualcomm
based machines, one of these may cause file system corruption
from an incorrect SD card supply voltage
- Five fixes for clk drivers on new Qualcomm platforms,
addressing issues with incorrect enable states
* tag 'soc-fixes-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
MAINTAINERS: update my email address
tee: optee: ffa: support shared memory offsets on large-page kernels
optee: register TEE devices only once fully initialized
tee: shm: reject zero-sized allocations in tee_dyn_shm_alloc_helper()
arm64: dts: imx8mp-var-dart-sonata: Fix Sonata SD I/O supply
arm64: dts: lx2160a: fix the iic5 spi3 pinmux offset and value
arm64: dts: lx2160a: fix IIC1 pinmux submask rejected by pinctrl-single
arm64: dts: lx2160a: fix incorrect pinmux
clk: qcom: gpucc-kaanapali: Mark the GPU CX GDSC as votable
clk: qcom: gpucc-glymur: Mark the GPU CX GDSC as votable
clk: qcom: gcc-kaanapali: Fix always-enabling PCIE_RSCC clocks
clk: qcom: gcc-hawi: Fix always-enabling PCIE_RSCC clocks
clk: qcom: gcc-eliza: Fix always-enabling PCIE_RSCC clocks
arm64: dts: qcom: x1-denali: Fix microphone distortion
tee: qcomtee: fix kernel-doc warnings
|
||
|
Linus Torvalds
|
8fc6e59488 |
usb: mtu3: Fix a double-dereference splat in TP_printk
This splat is reporting a double-dereference that can result in garbage traces being dumped due to the possibility of the TP_printk() being executed without the benefit of main memory being present. The fix is to move the extra dereference from TP_printk() time to TP_fast_assign() time. -----BEGIN PGP SIGNATURE----- iQJHBAABCgAxFiEEbK7UrM+RBIrCoViJnr8S83LZ+4wFAmrFPjETHHBhdWxtY2tA a2VybmVsLm9yZwAKCRCevxLzctn7jFa3D/4yDuCA4eVlyw8Ldqh0bCjbZCPAz421 TUXA+KU7jQaUy3mVWNyLDpFdOe6cChXskdxnEpzwXeze+05bK1nbu0jEXACU2edO xhbbS20KirhgZcZvS4XdgF2d7RFiHG79ajbsLwy2e1JlO3EtCklVfISLcjB4Xi9S wASHI6loJ4ev6YD6InFsPQVgN19m9SuuVGQRPgtHnzuPrlWxv6KuQg2DMwiJyLI1 13/bOSiLNwVlHynMvtmv/o7Qi1XszhIjG7qotdc8TJPjcjL0grP6qSOr7/QrZxfQ nUsdyVJ+WDarAArQ/Femk4IDRiqYMnLFxN65Ol1CGUlpTkQluU8deqgj5qvEQFVX SopYFDqj4fL7prdfhtOML3DCXtJZ6BAWAA24HUCL7zJ2+pYT57USk6OiSNsIUS8Y khCsW+1pzEInb8PRI7h9dvUu6jRn407PTytKZ4GNt6PnLzDWb8wvRpy+Jjzsr6LS NLyjkNlAVYMBItsfg+Y/9Lt6uqhpioz42+/3J5bsxTqksM4BNSRSZ+paJs/fNgFk drMxMuo5gsI8zQsKaVL6QlIKEChJPKzRzEIOJYKUDx3uhpwbtHO2551KGlQZIRNL ZbXZEDfgAHfGJ3ho3QZ/AyLzFiB+WUbT5+gw6mYNzjiUFObMlgU6p6Z/rS/eMNPi 1qR4UHl0fRvu1Q== =MAuw -----END PGP SIGNATURE----- Merge tag 'usb-mtu3.2026.10.06a' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu Pull tracing fix from Paul McKenney: "Fix a double-dereference splat in TP_printk in usb mtu3. This was a pre-existing bug that can corrupt tracing output, but which was exposed this cycle by additional checking that was added to the tracing subsystem. This splat is reporting a double-dereference that can result in garbage traces being dumped due to the possibility of the TP_printk() being executed without the benefit of main memory being present. The fix is to move the extra dereference from TP_printk() time to TP_fast_assign() time" * tag 'usb-mtu3.2026.10.06a' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu: usb: mtu3: Fix double dereference in TP_printk |
||
|
Linus Torvalds
|
4cc6bbaeb3 |
srcu: Fix spurious WARN_ON() for rcu_segcblist_n_cbs() in cleanup_srcu_struct()
This issue was introduced during the recent merge window: |
||
|
Daehyeon Ko
|
6d25ffca05 |
cipso: adjust cached option offsets when removing CIPSO
cipso_v4_skbuff_delattr() removes the CIPSO bytes but does not adjust
cached offsets for options that follow them.
For example, with a valid 10-byte CIPSO option followed by a seven-byte
RR option, parsing records rr at offset 30. Removing CIPSO moves RR to
offset 20, while the cached offset remains 30. Consumers such as
ip_forward_options() and __ip_options_echo() then access the wrong bytes;
the latter may interpret packet data as the option length and copy it into
fixed-size option storage.
Mirror cipso_v4_delopt() and subtract cipso_len from the srr, rr, ts and
router_alert offsets when they follow CIPSO. cipso_len is the distance
the first memmove() shifts those options. The later header move and
network-header reset relocate the bytes and their offset base together.
Fixes:
|
||
|
Haishuang Yan
|
c57b2e60d4 |
bareudp: set the inner protocol to the protocol of the packet
bareudp_xmit_skb() sets the inner protocol of the skb to the configured ethertype, and bareudp6_xmit_skb() does not set it at all. The inner protocol is used by skb_udp_tunnel_segment() to segment the inner packet when GSO has to be done in software, for instance when the lower device does not offload the checksum. With multiproto, an IPv4 device also carries IPv6, so the IPv6 header is parsed as an IPv4 one. With IPv6 underlay, the inner protocol is whatever the skb had before. In both cases segmentation fails and the packets are dropped. With veth tx checksum offload disabled, iperf3 TCP over bareudp gets about 10 Mbit/s with thousands of retransmits instead of about 700 Mbit/s for IPv6 over IPv4 and for both families over IPv6, while IPv4 over IPv4 works. At this point skb->protocol is the protocol of the inner packet, which bareudp_xmit() has already checked against the configuration, so use it on both paths. Fixes: |
||
|
Tony Nguyen
|
1d6500523b |
e1000e: add system to disable K1 list
Javier reports seeing packet loss issues related to the re-enablement
of K1; disabling it makes the issues go away. Add the reported system
to have K1 disabled by default.
Reproduction steps (from the Link):
Plug the cable and ping the default gateway on the LAN. No suspend/resume
involved, machine freshly booted and on AC power. Nothing e1000e-related in
dmesg apart from the link up/down messages; no "Hardware Unit Hang".
Default (K1 enabled):
$ ping -c 30 192.168.10.1
--- 192.168.10.1 ping statistics ---
30 packets transmitted, 18 received, 40% packet loss, time 29734ms
rtt min/avg/max/mdev = 0.211/0.315/0.384/0.046 ms
The lost packets are spread over the run (seq 6, 8, 9, 11, 13, 14, 16, 19,
20, 24, 25, 30), not a single burst. DHCP on this link also takes 1-2
minutes to get a lease, consistent with incoming packets being dropped.
With K1 disabled at runtime:
# ethtool --set-priv-flags enp0s31f6 disable-k1 on
$ ethtool --show-priv-flags enp0s31f6
Private flags for enp0s31f6:
s0ix-enabled: on
disable-k1 : on
$ ping -c 30 192.168.10.1
--- 192.168.10.1 ping statistics ---
30 packets transmitted, 30 received, 0% packet loss, time 29713ms
rtt min/avg/max/mdev = 0.169/0.251/0.468/0.054 ms
$ ping -c 30 192.168.10.1
--- 192.168.10.1 ping statistics ---
30 packets transmitted, 30 received, 0% packet loss, time 29677ms
rtt min/avg/max/mdev = 0.101/0.222/0.360/0.064 ms
I have only compile tested this, but Javier has tested that disabling K1
on his system (Lenovo ThinkPad P14s Gen 5 (Intel), I219-LM [8086:550a])
resolves his issues.
Cc: stable@vger.kernel.org
Fixes:
|
||
|
Eric Dumazet
|
f202578efc |
flow_dissector: avoid u16 truncation of hlen in bpf_flow_dissect()
bpf_flow_dissect() sanitizes the offsets returned by the BPF program with clamp_t(u16, ..., hlen). If hlen is bigger than 65535, the upper bound is truncated before the comparison. For instance, with hlen == 65536, both nhoff and thoff are forced to zero, even if the program returned sane values. This is the same class of bug as the one fixed in commit |
||
|
Eric Dumazet
|
a51d233ccd |
bnxt_en: fix DMA mapping length for padded small packets
Stefan Fleischmann reported Intel IOMMU DMA Read faults on BCM57412
NetXtreme-E NICs when transmitting packets on VLAN/macvlan interfaces:
DMAR: [DMA Read NO_PASID] Request device [18:00.0] fault addr 0xfc499000
[fault reason 0x06] PTE Read access is not set
bnxt_en 0000:18:00.0 eno1np0: Abandoning msg {0xb4 0x41a} len: 0 due to firmware status: 0x2000001
...
NETDEV WATCHDOG: eno1np0 (bnxt_en): transmit queue 0 timed out
The fault address (0xfc499000) is on an exact 4KB page boundary,
pointing to a DMA read buffer overrun.
In bnxt_start_xmit(), packets smaller than BNXT_MIN_PKT_SIZE (52 bytes),
such as 42-byte untagged ARP frames, are padded:
if (length < BNXT_MIN_PKT_SIZE) {
pad = BNXT_MIN_PKT_SIZE - length;
if (skb_pad(skb, pad))
goto tx_kick_pending;
length = BNXT_MIN_PKT_SIZE;
}
mapping = dma_map_single(&pdev->dev, skb->data, len, DMA_TO_DEVICE);
...
dma_unmap_len_set(tx_buf, len, len);
However, 'len' was initialized earlier to skb_headlen(skb) (e.g. 42 bytes)
and is left unadjusted after padding. Consequently, dma_map_single() and
dma_unmap_len_set() map and track only 42 bytes.
Later, the hardware TX buffer descriptor is programmed with the padded length:
txbd->tx_bd_len_flags_type =
cpu_to_le32(((len + pad) << TX_BD_LEN_SHIFT) | flags |
TX_BD_FLAGS_PACKET_END);
The NIC DMA engine is thus instructed to read 52 bytes from a region where
only 42 bytes were DMA-mapped. If skb->data ends near the boundary of a 4KB
page (within 'pad' bytes of the next page), the hardware DMA read overruns
into the unmapped adjacent page, triggering an IOMMU fault.
This issue was exposed after commit
|
||
|
Jakub Kicinski
|
7fadfc8dc6 |
Merge branch 'bnxt_en-pcie-flr-aer-fixes'
Michael Chan says: ==================== bnxt_en: PCIe FLR/AER fixes This patchset is split from the earlier 9-patch series to limit the fixes to the PCIe FLR/AER issues only (patches 7 to 9). The other fixes (patches 1 to 6) will be sent to net-next separately. The 1st patch is unchanged since v1. It refactors a bnxt_clear_bars() helper needed by patch 2 and 3. Patch 2 fixes an issue during driver init. in the kdump kernel on a Dell system with a smart PCIe switch upstream from the NIC. Patch 3 fixes an issue in the AER code path for non-fatal errors found by a partner. These patches have been regression tested on Broadcom 5750X and 5760X NICs running 237.x.x.x production FW. ==================== Link: https://patch.msgid.link/20261005204246.3822563-1-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Pavan Chebbi
|
2e52da2709 |
bnxt_en: Re-write the BARs following any type of PCIe errors
Currently the driver zeroes the BARs only when fatal PCIe errors
are reported so that pci_restore_state() restores it. However
firmware handles both fatal and non-fatal errors the same way when
it sees the slot reset resulting from the PCI_ERS_RESULT_NEED_RESET
return code from the driver. This means that we must re-write the
BARs post recovery even during non-fatal errors. Otherwise we will
see that every MMIO access returns all-ones and the firmware appears
dead.
Zero-out the BARs during PCIe error recovery regardless of type of
PCIe error, and make the wait after the hot reset unconditional.
Disable memory decode and bus mastering before rewriting the BARs so
the device doesn't decode a half-updated address, bailing out if
config space is still inaccessible. Defer pci_enable_device() until
after the BAR rewrite and restore, so the device isn't re-enabled
while its BARs are still being rewritten, then re-enable the device
and re-assert bus mastering. Guard the same Command register cleanup
on the re-enable failure path against an inaccessible device.
Skip re-enabling the device in bnxt_io_slot_reset() if it is already
enabled, so enable_cnt does not go unbalanced. A concurrent
bnxt_fw_reset_task() can also be re-enabling the same device in its
ENABLE_DEV state, so guard that call the same way.
Fixes:
|
||
|
Michael Chan
|
386f887c82 |
bnxt_en: Fix driver init in kdump kernel
Fix and strengthen the FLR sequence when initializing in the kdump
kernel. If the NIC is behind a PCIe switch in synthetic (smart)
mode, the switch may need to see that the BARs have been initialized
before it will pass mem read/write TLPs to the NIC.
On a Dell system with a PEX89144 PCIe switch, echo c > /proc/sysrq-trigger
will trigger fatal AER without this patch:
bnxt_en 0000:67:00.0: enabling device (0000 -> 0002)
[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 5
[Hardware Error]: event severity: recoverable
[Hardware Error]: Error 0, type: fatal
[Hardware Error]: section_type: PCIe error
[Hardware Error]: port_type: 5, upstream switch port
...
Add a new bnxt_kdump_reset() to do the expanded FLR sequence in the
kdump kernel. We now disable bus master and memory, save the PCI
state, do the FLR, clear the BARs, and restore the PCI state. The
BARs have to be cleared to ensure that they get re-initialized and
visible to the PCIe switch.
Since it is the kdump kernel, we make every effort to continue in
the best possible way even if pci_save_state() or pcie_flr() returns
error. After FLR, we poll for an additional 5 seconds before
aborting in case the device is not properly returning CRS. This is
similar to the 5-second wait in bnxt_io_slot_reset().
Fixes:
|
||
|
Michael Chan
|
8f5d59b9cf |
bnxt_en: Add bnxt_clear_bars() helper
In bnxt_io_slot_reset(), we clear the 6 BAR registers. Add a helper function to do that. The helper will be used again in the next patch. Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com> Reviewed-by: Joe Damato <joe@dama.to> Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20261005204246.3822563-2-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Fredrik Nyberg
|
9b6c20f788 |
net: usb: ax88179_178a: fix rx frame length for non-last packets
Commit |