Commit graph

1,482,218 commits

Author SHA1 Message Date
Kuniyuki Iwashima
73e594c19b af_packet: Don't cast tpacket_hdr.tp_len to int in tpacket_parse_header().
syzbot reported BUG() in sock_sendmsg_nosec(). [0]

The problem is that tpacket_parse_header() casts user-provided
tpacket_hdr.tp_len, which is u32, to int.

If the length is larger than INT_MAX, the following condition
in tpacket_parse_header() passes,

  if (unlikely(tp_len > size_max))

and any negative value can be returned to the caller, up to
sock_sendmsg_nosec().

The repro set tpacket_hdr.tp_len to 0xfffffdef, which is cast
to -EIOCBQUEUED (-529), triggering BUG() in sock_sendmsg_nosec().

  *(uint64_t*)0x200000000008 = 0xfffffdef;
  ...
  syscall(__NR_write, /*fd=*/r[0], /*buf=*/0x200000000000ul, /*count=*/1ul);

Let's define the local tp_len as u32 in tpacket_parse_header().

[0]:
kernel BUG at net/socket.c:803!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 0 UID: 0 PID: 5628 Comm: syz-executor176 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026
RIP: 0010:sock_sendmsg_nosec+0x145/0x180 net/socket.c:803
Code: 06 67 48 0f b9 3a eb 95 e8 e8 3a 22 f8 48 89 df 4c 89 f6 4c 89 e2 4d 89 fb 2e e8 32 a5 5c 16 e9 51 ff ff ff e8 cc 3a 22 f8 90 <0f> 0b e8 c4 3a 22 f8 48 83 c3 18 48 89 d8 48 c1 e8 03 42 80 3c 28
RSP: 0018:ffffc90003aefb48 EFLAGS: 00010293
RAX: ffffffff89a578d4 RBX: ffff8880764c67c0 RCX: ffff88807fb23e80
RDX: 0000000000000000 RSI: 00000000fffffdef RDI: 00000000fffffdef
RBP: 00000000fffffdef R08: ffffc90003aef747 R09: 1ffff9200075dee8
R10: dffffc0000000000 R11: fffff5200075dee9 R12: 0000000000000001
R13: dffffc0000000000 R14: ffffc90003aefbc0 R15: ffffffff8aac4310
FS:  000055559101b400(0000) GS:ffff888124ce0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000200000000210 CR3: 0000000073dca000 CR4: 00000000003526f0
Call Trace:
 <TASK>
 __sock_sendmsg net/socket.c:815 [inline]
 sock_write_iter+0x2de/0x3e0 net/socket.c:1266
 new_sync_write fs/read_write.c:595 [inline]
 vfs_write+0x612/0xba0 fs/read_write.c:687
 ksys_write+0x150/0x270 fs/read_write.c:739
 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
 do_syscall_64+0x166/0x520 arch/x86/entry/syscall_64.c:84
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f173130ecb9
Code: c0 79 93 eb d5 48 8d 7c 1d 00 eb 99 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 d8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffd67e44248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f173130ecb9
RDX: 0000000000000001 RSI: 0000200000000000 RDI: 0000000000000003
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd67e44388
R13: 0000000000000002 R14: 00002000000000c0 R15: 0000000000000002
 </TASK>

Fixes: 69e3c75f4d ("net: TX_RING and packet mmap")
Reported-by: syzbot+73df3f89e1e13089e466@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/6a946ffa.1d9ded08.62e62.0123.GAE@google.com/
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260830180915.260225-1-kuniyu@google.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-09-01 10:42:56 +02:00
Zhenhao Wan
38a62306c4 drm/nouveau/uvmm: clear the dirty flag when unwinding an OP_UNMAP_SPARSE
A successful OP_UNMAP_SPARSE marks its region dirty with
nouveau_uvma_region_dirty() and defers the teardown to
nouveau_uvmm_bind_job_cleanup(); it does not remove the region from
uvmm->region_mt.

If a later op in the job fails, the unwind path never clears reg->dirty
(set in one place, cleared nowhere) and sets op->reg = NULL, so cleanup
skips the teardown. The region is left in the tree with dirty set and its
completion never signalled. Later binds over that range then fail
permanently -- -ENOENT or -EINVAL from the dirty checks, or an unkillable
wait_for_completion() in bind_validate_region() -- for the lifetime of
the uvmm.

Clear reg->dirty when the unwind reverts the sparse unmap, restoring the
region to the state it was found in.

Fixes: b88baab828 ("drm/nouveau: implement new VM_BIND uAPI")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Assisted-by: Claude:claude-opus-5
Cc: stable@vger.kernel.org
Signed-off-by: Zhenhao Wan <whi4ed0g@gmail.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260811-nouveau-uvmm-vmbind-fixes-v2-3-aaee4b395d04@gmail.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-09-01 10:18:00 +02:00
Zhenhao Wan
ccf930812f drm/nouveau/uvmm: fix premature region free on failed OP_UNMAP_SPARSE
In nouveau_uvmm_bind_job_submit()'s OP_UNMAP_SPARSE arm, op->reg is set
from nouveau_uvma_region_find(), which only looks the region up and takes
no reference; a region's sole reference is its membership in
uvmm->region_mt. Two failure paths leave op->reg set: the -ENOENT check
when the region is busy, and the drm_gpuvm_sm_unmap_ops_create() failure.
The sibling nouveau_uvmm_sm_unmap_prepare() failure just below clears
op->reg; these two do not.

unwind_continue steps back one op, so the failing op is skipped by the
unwind loop and its op->reg stays set. nouveau_uvmm_bind_job_cleanup()
then enters its if (op->reg) branch and calls nouveau_uvma_region_remove()
and nouveau_uvma_region_put() on it, dropping the tree's sole reference
and freeing a region this job never created. The comment above the
cleanup loop documents the broken invariant: op->reg must be NULL on
submit failure.

This frees a live region on an unrelated failure, reachable single-job
when drm_gpuvm_sm_unmap_ops_create() returns -ENOMEM; if another job owns
the same region, its cleanup then removes and puts the freed region, a
use-after-free. Clear op->reg on both failure paths.

Fixes: b88baab828 ("drm/nouveau: implement new VM_BIND uAPI")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Assisted-by: Claude:claude-opus-5
Cc: stable@vger.kernel.org
Signed-off-by: Zhenhao Wan <whi4ed0g@gmail.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260811-nouveau-uvmm-vmbind-fixes-v2-2-aaee4b395d04@gmail.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-09-01 10:18:00 +02:00
Zhenhao Wan
412a6ceb56 drm/nouveau/uvmm: fix NULL deref unwinding an OP_MAP_SPARSE op
Each bind_job_op is zeroed by kzalloc_obj() in bind_job_op_from_uop(),
and the OP_MAP_SPARSE case in nouveau_uvmm_bind_job_submit() only creates
a region, so op->ops stays NULL for a successfully processed sparse map.

If a later op in the same job fails, the reverse unwind loop revisits that
op and calls drm_gpuva_ops_free(&uvmm->base, op->ops) unconditionally.
drm_gpuva_ops_free() dereferences its argument right away
(list_for_each_entry_safe on &ops->list), so a NULL op->ops oopses. The
path is reachable by any render-node fd holder, since NOUVEAU_VM_BIND is
DRM_RENDER_ALLOW.

Guard the free with IS_ERR_OR_NULL(), as nouveau_uvmm_bind_job_cleanup()
already does for the identical free.

Fixes: b88baab828 ("drm/nouveau: implement new VM_BIND uAPI")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Assisted-by: Claude:claude-opus-5
Cc: stable@vger.kernel.org
Signed-off-by: Zhenhao Wan <whi4ed0g@gmail.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260811-nouveau-uvmm-vmbind-fixes-v2-1-aaee4b395d04@gmail.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-09-01 10:18:00 +02:00
Maxime Ripard
67f8bc848e
Merge drm/drm-fixes into drm-misc-fixes
Let's start the 7.3 drm-misc-fixes cycle.

Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-09-01 09:38:51 +02:00
Damien Le Moal
3f9c7a108c block: flag zoned disks with GENHD_FL_NO_PART
Zoned block devices do not support partitions. However, the partition
table is nevertheless still inspected, and any partition found ignored
with a warning in add_partition(). While this is generally not a problem,
and in fact beneficial to the user as it indicates an invalid use of a
zoned block device, scanning for a partition table on the device may
result in issuing read operations to offline zones (e.g. after a disk head
is depopulated for disks that support head management operations).

Since partitions are ignored anyway, completely disable partition scanning
for zoned gendisks by setting the flag GENHD_FL_NO_PART in __add_disk().
The existing check in add_partition() is left as-is to ensure that we
still get a warning if for whatever reason, despite GENHD_FL_NO_PART, we
still endup trying to add partitions.

Flagging zoned disks with GENHD_FL_NO_PART also has the benefit to expose
through sysfs the ext_range attribute with the value of 1 instead of the
default DISK_MAX_PARTS, thus correctly advertizing the fact that zoned
disks do not support partitions.

Fixes: 5eac3eb30c ("block: Remove partition support for zoned block devices")
Cc: stable@vger.kernel.org
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Hannes Reinecke <hare@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Link: https://patch.msgid.link/20260831025050.667758-1-dlemoal@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-08-31 22:42:09 -06:00
Linus Torvalds
786262be60 - Mark the mpc85xx and ThunderX EDAC drivers as orphaned due to lack of
access to hardware
 
 - Remove the unused fake error injection interface from the EDAC debugfs
   code due to potential races between logging a fake and a real hw error
 
 - edac_mc_sysfs: Use sysfs_emit_at() for proper bounds checking
 
 - Remove Mark Gross from maintainer entries and move him to CREDITS
 
 - Load the AMD address translation library only on systems which can
   actually make use of it (have ECC memory) instead of on every AMD Zen
   system out there
 
 - In edac_altera, detect the SoC variant using the ECC manager's
   compatible string instead of the build architecture to select the
   correct interrupt layout, and remove leftover architecture-specific
   ifdeffery from the double-bit error handling path
 
 - Add a new reviewer for the Xilinx EDAC drivers
 
 - Unify address translation logic in Intel client EDAC drivers igen6 and
   ie31200 along with detecting memory controller counts at boot time
   instead of relying on hardcoded, platform specific numbers. Also, fix
   a bunch of issues in them; work by Qiuxu Zhuo
 
 - Add support for a new Intel processor platform Starfire which is
   a derivative of Panther Lake SoCs
 
 - The usual cleanups and fixlets all over
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEzv7L6UO9uDPlPSfHEsHwGGHeVUoFAmqWQWEACgkQEsHwGGHe
 VUr1kg/7BvyA9UYGN3qjkq6M+U+OsnulLsqAXztu2LcvbXGrZE9z5hto12L8lmEh
 Wh/gpzSIT+108j5L2vFr61Y4w42+uB6u9+SuIKFwXK4NgtMqIBLE2kf3M0k7rKtv
 UldNVw48Z18jJdghySEIAWXhF4PyT77RlEVqqVCyTpKOC/9gQh+UPDINUn5VW3yq
 gg9xTNh+PqoV0UsCfL9Y6OgsgaaaodzHtCWurQalsgLXlzoa0Ycsk9wiT+QtDlaO
 EqoceYInyMO/6b0GIw+7za7eHVJ1kuUvkrZVGB5bXLbz8VCUI/hWl4ru4YYGHX1m
 eCUJfRdZSoSv8ySYjz3Gh3hqO3S5JpNu/Epg3hq19Y51XnoWPj3RQNfkjsULSG4s
 IyTtIUHmX1SZM8w0yNBlJiz3xkovd5OFA+kDwY8qqnkysZvXqsbS1XDOerez6ahP
 Ciw/adq0iPau2bp2w3MSM40Qe0oJbvExh7+TX+0epOpZDvl096OW4OG3G4I3wt8n
 JzBzwRhGuBvK2iz8sN4iZ9Oo+rhE22+1ulr7Ns4oW7jR35g3gaWZI/gzWhBBD3fQ
 rcpHpm+OY23qnG5Y+jlwH6gEKNzK0H6wp8tCBIgIdpBUT4A08BUm2Nogqfn0VFqa
 NW/EHHuk0wgL7dQIWXqm8lBjQHmWQHXAbRz+W9CideCGBwSBgIk=
 =t886
 -----END PGP SIGNATURE-----

Merge tag 'edac_updates_for_v7.3_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras

Pull forgotten EDAC updates from Borislav Petkov:
 "Somewhat belated (and forgotten :-\) EDAC updates lineup for v7.3:

   - Mark the mpc85xx and ThunderX EDAC drivers as orphaned due to lack
     of access to hardware

   - Remove the unused fake error injection interface from the EDAC
     debugfs code due to potential races between logging a fake and a
     real hw error

   - edac_mc_sysfs: Use sysfs_emit_at() for proper bounds checking

   - Remove Mark Gross from maintainer entries and move him to CREDITS

   - Load the AMD address translation library only on systems which can
     actually make use of it (have ECC memory) instead of on every AMD
     Zen system out there

   - In edac_altera, detect the SoC variant using the ECC manager's
     compatible string instead of the build architecture to select the
     correct interrupt layout, and remove leftover architecture-specific
     ifdeffery from the double-bit error handling path

   - Add a new reviewer for the Xilinx EDAC drivers

   - Unify address translation logic in Intel client EDAC drivers igen6
     and ie31200 along with detecting memory controller counts at boot
     time instead of relying on hardcoded, platform specific numbers.
     Also, fix a bunch of issues in them; work by Qiuxu Zhuo

   - Add support for a new Intel processor platform Starfire which is a
     derivative of Panther Lake SoCs

   - The usual cleanups and fixlets all over"

* tag 'edac_updates_for_v7.3_rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras: (24 commits)
  EDAC/thunderx: Orphan it
  EDAC/device_sysfs: Cleanup around edac_device_ctl_poll_msec_store()
  EDAC/device_sysfs: Use kstrtouint() for poll_msec to prevent truncation
  EDAC/igen6: Add Intel Starfire SoCs support
  EDAC/igen6: Refactor address translation logic
  EDAC/igen6: Remove redundant resource configuration tables
  EDAC/igen6: Detect present memory controllers at runtime
  EDAC/igen6: Simplify compute die ID comments
  EDAC/igen6: Remove unnecessary XOR on the zero-valued interleave bit
  EDAC/igen6: Fix Raptor Lake-P logged error address
  EDAC/igen6: Fix channel address decode for non-hash mode
  EDAC/igen6: Fix channel selection hash
  EDAC/igen6: Fix interleave boundary condition
  EDAC/ie31200: Decouple DIMM width decoding from enum order
  RAS/AMD/ATL: Remove conditional return with no effect
  EDAC: Remove redundant dev_err()
  MAINTAINERS: Add Radhey Shyam Pandey as Xilinx EDAC reviewer
  EDAC/altera: Remove remaining CONFIG_64BIT ifdefs in the DB-error path
  EDAC/altera: Use ECC manager compatible to select A10/S10 IRQ layout
  RAS/AMD/ATL, EDAC/amd64: Only load ATL when needed
  ...
2026-08-31 20:10:39 -07:00
Koichiro Den
545b63503c net: ntb_netdev: Fix statistics races
ntb_netdev updates shared net_device stats from per-QP RX and TX
callbacks. Once multiple queues are enabled, concurrent updates can be
lost.

Use per-CPU tstats for packet and byte counters and DEV_STATS_INC() for
less frequent drop and error counters. Callbacks can run synchronously
in the xmit path or asynchronously from a tasklet or the memcpy kthread.
Pin TX updates against migration in the kthread path. Use the IRQ-safe
u64_stats helpers because netpoll can invoke the synchronous path with
IRQs disabled.

Let the core manage tstats while keeping transport teardown after
unregister_netdev(), outside RTNL. RCU lets unregister wait for TX
completions already updating stats, while later completions only consume
the skb and skip accounting and queue wake.

Fixes: 24d9e73c7e ("net: ntb_netdev: Support ethtool channels for multi-queue")
Cc: stable@vger.kernel.org
Suggested-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260830151617.3546585-1-den@valinux.co.jp
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 20:09:35 -07:00
Eric Dumazet
975b5b067f ipv6: sr: restore network header before routing and forwarding
ipv6_srh_rcv() runs with skb->data at the Segment Routing Header (SRH)
while skb_network_header() points at the IPv6 header.

When segments_left > 0, ipv6_srh_rcv() previously restored the skb->data
position by pushing sizeof(struct ipv6hdr), assuming the SRH immediately
followed the fixed IPv6 header. If another extension header (such as a
Hop-by-Hop options header) precedes the SRH, skb_network_offset()
remained negative.

This led to two problems:
1. During ip6_route_input(), fib6_rules_early_flow_dissect() invokes
   __skb_flow_dissect() which passes the negative skb_network_offset()
   to flow dissection, breaking BPF and C flow dissector logic.
2. If forwarded via ip6_forward() or redirected via act_mirred, downstream
   handlers (like sch_fragment() or neighbour output) pass the negative
   offset as an unsigned length, triggering OOB memcpy or buffer overflows.

Fix this by pushing -skb_network_offset(skb) before routing, ensuring
skb_network_offset(skb) is 0 for route lookup / flow dissection as well as
downstream forwarding. On the loopback path, pull skb_transport_offset(skb)
to restore skb->data to the SRH before looping back.

Fixes: 1ababeba4a ("ipv6: implement dataplane support for rthdr type 4 (Segment Routing Header)")
Reported-by: TencentOS Corvus AI <corvus@tencent.com>
Reported-by: Jun Yang <junvyyang@tencent.com>
Reported-by: Fourie Zhang <fouriezhang@tencent.com>
Closes: https://lore.kernel.org/netdev/20260817104128.22681-1-juny24602@gmail.com/
Closes: https://lore.kernel.org/netdev/20260827092345.2301937-1-fouriezhang@tencent.com/
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260828141727.2372570-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 20:04:37 -07:00
David Laight
81c600c263 tipc: Dont send random pad bytes in RESET/ACTIVATE messages
The interface name is passed in a fixed length (TIPC_MAX_IF_NAME) buffer.
Replace the strcpy(data, l->if_name) with memcpy() so that the
pad bytes are actually written (l->if_name[] is zero padded)
rather than sending random bytes from the skb to the remote system.

Replace two other strcpy() with strscpy().

Fixes: e74a386d70 ("tipc: remove pre-allocated message header in link struct")
Signed-off-by: David Laight <david.laight.linux@gmail.com>
Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech>
Link: https://patch.msgid.link/20260829115813.188600-1-david.laight.linux@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 20:02:36 -07:00
Tung Nguyen
b3b76e9f4f tipc: fix NULL deref in tipc_named_node_up() on empty publication list
User-space applications can bind a large number of service addresses to
one or more sockets. Each binding of a local-scope service address inserts
one entry (publication) into the TIPC name table. If the number of these
publications exceeds TIPC_MAX_PUBL (65535), protocol service types
(such as node state and link state) are no longer inserted into the name
table. This causes two issues:

1. User-space applications subscribing to node or link up/down events
   stop receiving notifications.

2. A NULL pointer dereference can occur:

   BUG: kernel NULL pointer dereference, address: 00000000000000d0
   ...
   CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc4-default+ #5 PREEMPT(full)
   ...
   RIP: 0010:tipc_named_node_up (./include/linux/skbuff.h:2251 net/tipc/name_distr.c:195 net/tipc/name_distr.c:221)
   ...
   Call Trace:
   <IRQ>
   tipc_node_write_unlock (net/tipc/node.c:428)
   tipc_rcv (net/tipc/node.c:934 net/tipc/node.c:2189)
   tipc_udp_recv (net/tipc/udp_media.c:389)

   Thread 1 (tipc_net_finalize) | Thread 2 (named_distribute)
   -----------------------------|-----------------------------
                                | ...
                                | list_for_each_entry(publ, pls, binding_node) {
                                | ...
                                | __skb_queue_tail(list, skb);
                                | ...
                                | }
                                | ...
                                | hdr = buf_msg(skb_peek_tail(list));
   ...                          |
   tipc_nametbl_publish();      |

   If 'tipc_nametbl_publish()' (Thread 1) fails because the number of
   local publications reaches TIPC_MAX_PUBL, list (Thread 2) will be empty. As a
   result, NULL is passed to 'buf_msg()', leading to a NULL pointer dereference.

Fix these issues by allowing protocol service types (node state, link state,
and topology server) to be inserted into the name table unconditionally.
This ensures that users subscribing to these types always receive
notifications. In addition, the maximum number of local user publications is
reduced to (TIPC_MAX_PUBL - 1). This ensures that the maximum bulk size
calculated in tipc_link_set_queue_limits() remains valid.

Fixes: a5e7ac5ce1 ("tipc: fix regression bug where node events are not being generated")
Reported-by: Xiang Mei <xmei5@asu.edu>
Tested-by: Weiming Shi <bestswngs@gmail.com>
Signed-off-by: Tung Nguyen <tung.quang.nguyen@est.tech>
Link: https://patch.msgid.link/20260827111418.164957-1-tung.quang.nguyen@est.tech
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 20:01:49 -07:00
Jakub Kicinski
f88bbbbe96 Merge branch 'mitigate-a-side-channel-in-routing-exception-caches'
Ido Schimmel says:

====================
Mitigate a side channel in routing exception caches

When an ICMP error that quotes a UDP packet is locally delivered, the
kernel only creates a routing exception if the quoted packet matches
a socket. This allows an off-path attacker to conduct a side-channel
attack on the routing exception caches in order to discover the
ephemeral ports used by connected UDP sockets.

Previous mitigations tried to make it harder for attackers to find hash
collisions in these caches and make the eviction of exceptions less
predictable. Amit Klein and Noam Caspi demonstrated that both of these
mitigations can be bypassed.

This patchset tries to mitigate such attacks by always creating an
exception, even before trying to find a matching socket. The exception
is created by the same helpers that are used when the quoted packet did
not originate from a socket, so that guesses (right or wrong) from an
off-path attacker always result in an exception being created or updated
in the cache that the attacker can observe.

Note that this mitigation does not make it easier for attackers to fill
these caches, since they can already create exceptions with little to no
validation. For example, by sending an ICMP error that quotes an ICMP
Echo Reply or one that quotes a UDP source port that matches a wildcard
socket.

In the good case (matched socket) this comes at the cost of an extra
route lookup, as the exception is created before the one performed by
the socket path. When the two lookups resolve to different nexthops,
an exception is created in the cache of each.

Patch #1 fixes a pre-existing bug in the handling of ICMPv6 Redirect
Message packets. Discovered while writing the selftest.

Patch #2 creates an exception from the IPv4 UDP code even before socket
matching. Other socket types do not need this: raw sockets have no
ports, and for TCP the ICMP error is discarded unless the quoted
sequence number is in window.

Patch #3 does the same for IPv6.

Patch #4 adds a selftest.

v1: https://lore.kernel.org/netdev/20260826143735.1819315-1-idosch@nvidia.com/
====================

Link: https://patch.msgid.link/20260828192344.2596928-1-idosch@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 19:56:33 -07:00
Ido Schimmel
c923c14942 selftests: net: Add exception cache tests
Add a test for the IPv4 and IPv6 exception caches, covering the
exceptions that are created in response to ICMP errors quoting a UDP
packet.

The topology consists of a host (h1) that reaches a remote host (h2)
via a router (r1), with a second router (r2) attached to the segment
shared by h1 and r1. UDP packets are injected using a packet socket, so
that an ICMP error quoting them is only matched to a socket when one was
opened separately with the same source port. PMTU errors are provoked by
lowering the MTU of the far end of the path and redirects by pointing
r1's route towards h2 back over the segment it received the packet from.

The following is tested for both address families and for both PMTU and
redirect exceptions:

* An error that is not matched to a socket creates an exception that
  carries the new MTU or gateway.
* An error that is matched to a socket creates the same exception.

The PMTU tests further verify that a lower PMTU replaces the one stored
in the exception whereas a higher one does not, and that a socket which
disabled PMTU discovery using IP{,V6}_PMTUDISC_OMIT gets the same
exception as the other cases.

Without "ipv4: udp: Create exceptions before socket matching" and "ipv6:
udp: Create exceptions before socket matching", the tests that do not
open a socket fail:

 # ./exception_cache.sh
 TEST: IPv4: PMTU: exception without a matching socket               [FAIL]
         No socket: exception does not carry an MTU of 1400
 TEST: IPv6: PMTU: exception without a matching socket               [FAIL]
         No socket: exception does not carry an MTU of 1400
 TEST: IPv4: PMTU: exception with a matching socket                  [ OK ]
 TEST: IPv6: PMTU: exception with a matching socket                  [ OK ]
 TEST: IPv4: PMTU: exception with a socket ignoring it               [FAIL]
         PMTU discovery disabled: exception does not carry an MTU of 1400
 TEST: IPv6: PMTU: exception with a socket ignoring it               [FAIL]
         PMTU discovery disabled: exception does not carry an MTU of 1400
 TEST: IPv4: Redirect: exception without a matching socket           [FAIL]
         No socket: exception does not carry the new gateway
 TEST: IPv6: Redirect: exception without a matching socket           [FAIL]
         No socket: exception does not carry the new gateway
 TEST: IPv4: Redirect: exception with a matching socket              [ OK ]
 TEST: IPv6: Redirect: exception with a matching socket              [ OK ]

Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260828192344.2596928-5-idosch@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 19:56:31 -07:00
Ido Schimmel
ac76cab50e ipv6: udp: Create exceptions before socket matching
Currently, when ICMPv6 Packet Too Big and Redirect Message packets are
locally delivered and quote a UDP packet, an exception is only created
in the IPv6 exception cache if the kernel can match the UDP packet to an
existing socket.

This behavior allows off-path attackers to conduct a side-channel attack
on the exception cache in order to discover the ephemeral port used by a
connected UDP socket.

Commit 4785305c05 ("ipv6: use siphash in rt6_exception_hash()") and
commit a00df2caff ("ipv6: make exception cache less predictible") tried
to mitigate such attacks by making it harder for attackers to discover
hash collisions in the exception cache and by randomizing the number of
exceptions a hash bucket can hold, respectively. Unfortunately, both of
the mitigations can be bypassed.

Instead, mitigate such attacks by always creating an exception, even
before trying to find a matching socket. Do that by calling
ip6_update_pmtu() and ip6_redirect(), the helpers used when the quoted
packet did not originate from a socket.

This means that guesses (right or wrong) from an off-path attacker will
always result in an exception being created or updated in the cache that
the attacker can observe.

Pass the ifindex of the ingress device and the default uid, in a similar
fashion to icmpv6_err(). Unlike IPv4, an oif of 0 would not match any
nexthop in ip6_redirect_nh_match() and no exception would be created in
response to a Redirect Message.

Note that this does not allow attackers to create exceptions that they
could not create before, as both helpers can already be reached with
little to no validation. For example, by sending an ICMPv6 error that
quotes an ICMPv6 Echo Reply or one that quotes a UDP source port that
matches a wildcard socket.

Also note that in the good case (matched socket) the above scheme comes
at the cost of an extra route lookup, as the no socket helpers perform
their own lookup before the one performed by ip6_sk_update_pmtu() /
ip6_sk_redirect(). When the two resolve to different nexthops, it also
results in two exceptions being created for the same destination IP. One
in the exception cache of the nexthop resolved by the no socket helpers
and another in the exception cache of the nexthop used by the socket.

Fixes: 2b760fcf5c ("ipv6: hook up exception table to store dst cache")
Cc: stable@vger.kernel.org
Reported-by: Amit Klein <aksecurity@gmail.com>
Reported-by: Noam Caspi <noam.caspi@mail.huji.ac.il>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://patch.msgid.link/20260828192344.2596928-4-idosch@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 19:56:30 -07:00
Ido Schimmel
4c3499f79f ipv4: udp: Create exceptions before socket matching
Currently, when ICMP Fragmentation Needed and Redirect Message packets
are locally delivered and quote a UDP packet, a FIB nexthop exception
(FNHE) is only created if the kernel can match the UDP packet to an
existing socket.

This behavior allows off-path attackers to conduct a side-channel attack
on the FNHE cache in order to discover the ephemeral port used by a
connected UDP socket.

Commit 6457378fe7 ("ipv4: use siphash instead of Jenkins in
fnhe_hashfun()") and commit 67d6d681e1 ("ipv4: make exception cache
less predictible") tried to mitigate such attacks by making it harder
for attackers to discover hash collisions in the FNHE cache and by
randomizing the number of exceptions a hash bucket can hold,
respectively. Unfortunately, both of the mitigations can be bypassed.

Instead, mitigate such attacks by always creating a FNHE, even before
trying to find a matching socket. Do that by calling ipv4_update_pmtu()
and ipv4_redirect(), the helpers used when the quoted packet did not
originate from a socket.

This means that guesses (right or wrong) from an off-path attacker will
always result in a FNHE being created or updated in the cache that the
attacker can observe.

Pass an oif of 0, in a similar fashion to icmp_err(). This is also the
oif used by the socket path for sockets that are not bound to a device.

Note that this does not allow attackers to create FNHEs that they could
not create before, as both helpers can already be reached with little to
no validation. For example, by sending an ICMP error that quotes an ICMP
Echo Reply or one that quotes a UDP source port that matches a wildcard
socket.

Also note that in the good case (matched socket) the above scheme comes
at the cost of an extra route lookup, as the no socket helpers perform
their own lookup before the one performed by ipv4_sk_update_pmtu() /
ipv4_sk_redirect(). When the two resolve to different nexthops, it also
results in two exceptions being created for the same destination IP. One
in the FNHE cache of the nexthop resolved by the no socket helpers and
another in the FNHE cache of the nexthop used by the socket.

Fixes: 4895c771c7 ("ipv4: Add FIB nexthop exceptions.")
Cc: stable@vger.kernel.org
Reported-by: Amit Klein <aksecurity@gmail.com>
Reported-by: Noam Caspi <noam.caspi@mail.huji.ac.il>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://patch.msgid.link/20260828192344.2596928-3-idosch@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 19:56:30 -07:00
Ido Schimmel
cd51b74bdd ipv6: Fix redirect exception creation for UDP/RAW sockets
When an ICMP Redirect Message is matched to a socket, both IPv4 and IPv6
verify that the source IP of the ICMP packet is the current gateway for
the quoted packet. Both also pass the socket's bound device as the
expected nexthop device.

The difference is that IPv4 treats "oif=0" as "any", whereas IPv6 always
requires an exact match (see ip6_redirect_nh_match()), since the gateway
address is usually a link-local address.

Therefore, when an IPv6 UDP/RAW socket is not bound to a device, the
above verification fails and an exception is not created. This also
happens when the socket is bound to a VRF, as l3mdev_update_flow()
resets the oif to 0.

Fix this by passing the ifindex of the ingress device as the expected
nexthop device. This is consistent with the existing callers of
ip6_redirect(). Note that for ICMPv6 Redirect Message packets the VRF
driver does not reset skb->dev to the VRF device, so skb->dev is
correct, even when it is a VRF port.

Fixes: b55b76b221 ("ipv6:introduce function to find route for redirect")
Cc: stable@vger.kernel.org
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260828192344.2596928-2-idosch@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 19:56:30 -07:00
Borislav Petkov (AMD)
68c90773f4 Merge remote-tracking branches 'ras/edac-misc', 'ras/edac-drivers' and 'ras/edac-amd-atl' into edac-updates
* ras/edac-misc:
  EDAC/thunderx: Orphan it
  EDAC/device_sysfs: Cleanup around edac_device_ctl_poll_msec_store()
  EDAC/device_sysfs: Use kstrtouint() for poll_msec to prevent truncation
  MAINTAINERS: Add Radhey Shyam Pandey as Xilinx EDAC reviewer
  MAINTAINERS: Remove Mark Gross from relevant entries
  EDAC/sysfs: Use sysfs_emit_at() in dimmdev_location_show()
  EDAC/mpc85xx: Orphan it

* ras/edac-drivers:
  EDAC/igen6: Add Intel Starfire SoCs support
  EDAC/igen6: Refactor address translation logic
  EDAC/igen6: Remove redundant resource configuration tables
  EDAC/igen6: Detect present memory controllers at runtime
  EDAC/igen6: Simplify compute die ID comments
  EDAC/igen6: Remove unnecessary XOR on the zero-valued interleave bit
  EDAC/igen6: Fix Raptor Lake-P logged error address
  EDAC/igen6: Fix channel address decode for non-hash mode
  EDAC/igen6: Fix channel selection hash
  EDAC/igen6: Fix interleave boundary condition
  EDAC/ie31200: Decouple DIMM width decoding from enum order
  EDAC: Remove redundant dev_err()
  EDAC/altera: Remove remaining CONFIG_64BIT ifdefs in the DB-error path
  EDAC/altera: Use ECC manager compatible to select A10/S10 IRQ layout

* ras/edac-amd-atl:
  RAS/AMD/ATL: Remove conditional return with no effect
  RAS/AMD/ATL, EDAC/amd64: Only load ATL when needed
  EDAC/debugfs: Remove the fake_inject debugfs interface

Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
2026-08-31 19:29:47 -07:00
Eric Dumazet
97cc84dad1 ip6_gre: check tunnel info before xmit in ip6gre_tunnel_xmit
Shuangpeng Bai reported a KASAN slab-use-after-free in
ip6gre_tunnel_xmit().

The precise KASAN bug was caused by ip6_tnl_xmit() consuming the
skb during headroom expansion and returning an error, while
ip6gre_tunnel_xmit() still held the stale pointer and called
skb_tunnel_info_txcheck(skb) at tx_err. That specific bug was fixed by
commit 87f21b59dd ("ip6_tunnel: use skb_cow_head() in ip6_tnl_xmit()").

However, calling skb_tunnel_info_txcheck(skb) at the tx_err label
after the transmission attempt remains problematic:

Downstream helpers like ip6_tnl_xmit() call skb_scrub_packet(),
which drops the skb's metadata_dst before transmission. If an error
occurs later during transmit, inspecting skb at tx_err sees a scrubbed
dst and misclassifies tx_errors vs tx_dropped.

Commit e5f7e211b6 ("ip6gre: avoid tx_error when sending MLD/DAD on
external tunnels") already handled this correctly in
ip6erspan_tunnel_xmit() by checking and caching tun_info before
transmit.

Align ip6gre_tunnel_xmit() with ip6erspan_tunnel_xmit() by caching
tun_info before xmit and checking it at tx_err.

Fixes: e5f7e211b6 ("ip6gre: avoid tx_error when sending MLD/DAD on external tunnels")
Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
Closes: https://lore.kernel.org/netdev/20260819062224.3197349-1-shuangpeng.kernel@gmail.com/
Cc: Davide Caratti <dcaratti@redhat.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260828103731.1951815-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 17:56:52 -07:00
Jakub Kicinski
ec12bdd568 Merge branch 'ipv6-mcast-rcu-and-timer-fixes'
Eric Dumazet says:

====================
ipv6: mcast: RCU and timer fixes

This series addresses several RCU synchronization and timer calculation
issues identified in IPv6 multicast (MLD) handling within net/ipv6/mcast.c
while I was working on fixing a syzbot report in net/ipv4/icmp.c.

Patch 1 fixes an RCU reader diversion in ip6_mc_del1_src() where mutating
psf->sf_next to insert an unlinked source node into the tombstone list
diverted concurrent lockless readers (e.g. ipv6_chk_mcast_addr()) into
pmc->mca_tomb, causing them to miss remaining active sources.

Patch 2 converts ip6_mc_source() to use copy-on-write RCU updates.
Previously, source additions and deletions modified the socket's
psl->sl_addr array in-place, causing concurrent lockless readers in
inet6_mc_check() (UDP/RAW receive path) to observe torn 16-byte IPv6
addresses or duplicated/missed sources.

Patch 3 fixes delay calculation in igmp6_join_group() when canceling an
existing delayed work, preventing unsigned jiffies underflows when the
timer has already expired and clamping the delay to the unsolicited report
interval.

Patch 4 ensures rcu_assign_pointer() is consistently used for __rcu list
updates in __ipv6_dev_mc_dec(), ipv6_sock_mc_drop(), __ipv6_sock_mc_close(),
and related helpers.

Patch 5 switches igmp6_mc_seq_show() to use jiffies_delta_to_clock_t()
with a signed long delta, preventing underflows in /proc/net/igmp6 timer
duration reporting.
====================

Link: https://patch.msgid.link/20260828084531.1826790-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 17:54:48 -07:00
Eric Dumazet
b4cf4a092a ipv6: mcast: use jiffies_delta_to_clock_t() in igmp6_mc_seq_show()
If a multicast group timer has expired but the delayed work has
not yet run to clear MAF_TIMER_RUNNING, expires - jiffies produces
a negative value.

Because unsigned arithmetic was used with jiffies_to_clock_t(),
expires - jiffies underflows to a huge value and reports invalid
timer durations in /proc/net/igmp6.

Use jiffies_delta_to_clock_t() with a signed long delta to properly
cap expired deltas to 0, matching IPv4 igmp_mc_seq_show() and commit
a399a80531 ("time: jiffies_delta_to_clock_t() helper to the rescue").

Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260828084531.1826790-6-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 17:54:46 -07:00
Eric Dumazet
0c8f56c583 ipv6: mcast: use rcu_assign_pointer() for __rcu list updates
Several places in net/ipv6/mcast.c update RCU-protected lists
(np->ipv6_mc_list, idev->mc_list, idev->mc_tomb) using direct pointer
assignments instead of rcu_assign_pointer():

1. In __ipv6_dev_mc_dec(), unlinking a group from idev->mc_list did:
       *map = ma->next;
   without rcu_assign_pointer() while concurrent readers traverse
   idev->mc_list locklessly under rcu_read_lock().
2. In ipv6_sock_mc_drop() and __ipv6_sock_mc_close(), unlinking a group
   from np->ipv6_mc_list directly assigned *lnk = mc_lst->next and
   np->ipv6_mc_list = mc_lst->next without rcu_assign_pointer(), racing
   with lockless readers in inet6_mc_check().
3. In __ipv6_sock_mc_join(), mc_lst->next was initialized to
   np->ipv6_mc_list via raw assignment before publishing mc_lst.
4. In mld_del_delrec() and __ipv6_dev_mc_inc(), __rcu source pointers
   passed into rcu_assign_pointer() lacked explicit dereference helpers.

Fix these by consistently using rcu_assign_pointer() along with
mc_dereference() / sock_dereference().

Fixes: 456b61bca8 ("ipv6: mcast: RCU conversion")
Fixes: 88e2ca3080 ("mld: convert ifmcaddr6 to RCU")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Taehee Yoo <ap420073@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260828084531.1826790-5-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 17:54:46 -07:00
Eric Dumazet
75fa9caeb8 ipv6: mcast: fix delay calculation in igmp6_join_group()
When joining a multicast group, if a report work is already pending
(e.g. scheduled by a query or a previous join), igmp6_join_group()
cancels the delayed work and recalculates the delay:

	if (cancel_delayed_work(&ma->mca_work)) {
		refcount_dec(&ma->mca_refcnt);
		delay = ma->mca_work.timer.expires - jiffies;
	}

Unlike igmp6_group_queried(), igmp6_join_group() did not check
if delay >= interval. This leads to two issues:

1. If the timer has already expired (timer.expires <= jiffies), the
   stale expiry is reused by mod_delayed_work(), causing the second
   unsolicited report to fire on the very next tick without a
   randomized delay.
2. If the timer was originally armed by a query with a large
   maximum response delay, delay could exceed
   unsolicited_report_interval(ma->idev).

Fix this by initializing delay to unsolicited_report_interval(ma->idev)
and re-randomizing it with get_random_u32_below(interval) when
delay >= interval, mirroring the logic in igmp6_group_queried().

Fixes: 2d9a93b490 ("mld: convert from timer to delayed work")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Taehee Yoo <ap420073@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Link: https://patch.msgid.link/20260828084531.1826790-4-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 17:54:46 -07:00
Eric Dumazet
c073d1b070 ipv6: mcast: use copy-on-write RCU updates in ip6_mc_source()
pmc->sflist is read locklessly under rcu_read_lock() by
inet6_mc_check() during packet reception in the UDP and RAW
multicast receive paths.

ip6_mc_source() mutated psl->sl_addr and psl->sl_count in-place
when adding or removing a source filter. Additionally, when expanding
the filter buffer, newpsl was published via rcu_assign_pointer()
before writing the new source into the array.

Because 16-byte struct in6_addr writes are not atomic and array
shifting is not synchronized with RCU readers, concurrent readers in
inet6_mc_check() could read torn IPv6 addresses or observe
duplicated/missed source entries.

Fix this by switching ip6_mc_source() to copy-on-write RCU updates:
allocate and fully populate newpsl before publishing it via
rcu_assign_pointer(), and reclaim the old filter via kfree_rcu(),
matching ip6_mc_msfilter().

Also remove the now unused IP6_SFBLOCK macro.

Fixes: 882ba1f73c ("mld: convert ipv6_mc_socklist->sflist to RCU")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Taehee Yoo <ap420073@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260828084531.1826790-3-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 17:54:45 -07:00
Eric Dumazet
93b4923984 ipv6: mcast: fix RCU list diversion in ip6_mc_del1_src()
When removing a source filter whose count reaches zero, ip6_mc_del1_src()
unlinks psf from pmc->mca_sources. If the filter was previously active,
the code moved psf directly into pmc->mca_tomb by updating psf->sf_next.

Because pmc->mca_sources is traversed locklessly under RCU (e.g. by
ipv6_chk_mcast_addr()), mutating psf->sf_next before a grace period
elapses diverts concurrent readers to the tombstone list. Consequently,
readers miss remaining active sources in pmc->mca_sources and improperly
examine deleted tombstone entries.

Fix this by allocating a new tombstone node for pmc->mca_tomb (as done
in sf_setstate()) and retiring the original psf via kfree_rcu().

Fixes: 4b200e3989 ("mld: convert ip6_sf_list to RCU")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Taehee Yoo <ap420073@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260828084531.1826790-2-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 17:54:45 -07:00
Andi Kleen
738ef4cd82 uprobes: guard trace cleanup against error pointers
Sashiko pointed out the some of the scope cleanups for free_uprobe
could get an error pointer. Handle this case in free_uprobe
to prevent a crash.

On the other hand the macro doesn't need the guard because
free_uprobe itself already does the check.

Link: https://lore.kernel.org/all/20260831150651.1134594-2-ak@kernel.org/

Assisted-by: omp:gpt-5.6-luna sashiko
Signed-off-by: Andi Kleen <ak@kernel.org>
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2026-09-01 09:50:11 +09:00
Qingfang Deng
d8d4d1cf40 ppp: ppp_synctty: simplify tty disc_data access
Apply the same simplification as the preceding ppp_async change.

Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Reported-by: syzbot+b503105c2410c3433459@syzkaller.appspotmail.com
Closes: https://syzbot.org/bug?extid=b503105c2410c3433459
Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260828073245.126804-2-qingfang.deng@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 17:36:56 -07:00
Qingfang Deng
9feb069e5e ppp: ppp_async: simplify tty disc_data access
tty_ldisc_hangup() invokes the hangup callback while holding only a read
lock on tty->ldisc_sem, so it can run concurrently with other line
discipline callbacks. This currently forces async PPP to maintain
separate lifetime protection around tty->disc_data.

Line discipline close is called under the write lock during hangup
processing. Remove the hangup callback and rely on close for teardown,
as done for SLIP by commit 23c53269f2 ("slip: remove slip_hangup() to
fix use-after-free in slip_receive_buf()"). This serializes teardown
with all other line discipline operations.

disc_data_lock, refcount and completion are redundant with that
serialization. Remove them and access tty->disc_data directly.

This also eliminates a lockdep warning reported by syzbot. The warning
does not indicate a real deadlock because the write side runs only in
process context with hardirqs disabled.

Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Reported-by: syzbot+8e808eb853386f575d86@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/0000000000002fbad30611e25849@google.com/
Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260828073245.126804-1-qingfang.deng@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 17:36:56 -07:00
Eric Dumazet
2987ee196c igmp: convert struct ip_sf_list to RCU
Commit 23d2b94043 ("igmp: Add ip_mc_list lock in ip_check_mc_rcu")
added spin_lock_bh(&im->lock) to ip_check_mc_rcu() to prevent a
use-after-free while iterating im->sources during concurrent deletions.

However, ip_check_mc_rcu() is called from RCU read-side critical
sections in packet receive and route lookup fast paths (e.g.
__mkroute_output(), ip_route_input_rcu(), and __udp4_lib_rcv()).

When igmpv3_send_cr() or igmpv3_send_report() holds &pmc->lock and
calls add_grec() -> igmpv3_newpack() -> ip_route_output_ports(),
an XFRM policy matching a multicast destination triggers
xfrm_tmpl_resolve_one() -> xfrm4_get_saddr() -> __mkroute_output() ->
ip_check_mc_rcu(). This attempts to acquire &im->lock while &pmc->lock
is already held on the same CPU, triggering a lockdep recursive locking
warning / deadlock.

Fix this by converting IPv4 struct ip_sf_list to RCU, mirroring the
IPv6 implementation in net/ipv6/mcast.c:

1. Add struct rcu_head to struct ip_sf_list and annotate sf_next,
   sources, and tomb as __rcu pointers.
2. Use rcu_assign_pointer() and kfree_rcu() for list updates and
   deletions.
3. Remove spin_lock_bh(&im->lock) from ip_check_mc_rcu() and traverse
   im->sources locklessly with for_each_psf_rcu(), reading and writing
   counter fields with READ_ONCE() and WRITE_ONCE().

Note: RCU conversion of /proc/net/mcfilter will be done in a
separate patch.

Fixes: 23d2b94043 ("igmp: Add ip_mc_list lock in ip_check_mc_rcu")
Reported-by: syzbot+3d99fb01bcd740f2fc1e@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=3d99fb01bcd740f2fc1e
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260827160656.903003-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 17:22:03 -07:00
Jakub Kicinski
1ea9fff22b bluetooth pull request for net:
Core:
 
  - hci_core: Fix race condition during device registration
  - L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan
  - L2CAP: fix out-of-bounds write in l2cap_ecred_connect
  - L2CAP: clear FLAG_DEFER_SETUP only for same PID/PSM
 
 Drivers:
 
  - hci_mrvl: Fix wrong return value check of wait_on_bit_timeout()
  - btintel_pcie: Clear automask on spurious interrupts
  - btintel: validate version TLV value lengths
  - btintel: bound firmware ID by TLV length
  - btintel: propagate version TLV parsing errors
 -----BEGIN PGP SIGNATURE-----
 
 iQJNBAABCgA3FiEE7E6oRXp8w05ovYr/9JCA4xAyCykFAmqVxRsZHGx1aXoudm9u
 LmRlbnR6QGludGVsLmNvbQAKCRD0kIDjEDILKe10EAChWhEsuut57nFkj7hEej8Z
 0YQhCbKNRz9Iw7/3m4PMb20sHMOptTdkb5yanDMHLpXSOTN15GR/iyWzNBPafzf0
 yNeOJaB6ePb3yKTRRIfde0s6H2TMcFJpSTF1ARtvyssDDwnVezIuQQr2/VMZY9Rf
 GNGji7lMJpc1gjn2VIixukPK2CAeZ1I9+b3tl2P6KaHXU5jZEoLGczmMy8i4UBQS
 xD3dWtg/w9+tBVeLH6MIzcHM3xEOPB2Sn3DNT6nHmyeCz9Yq4ZkJjcUhH70LIl2t
 46fUTHq+2lnqLfk8Hx/gv5OW/mwO5jzvXZx1o+Jd3kia88E5YQ6sw7ZxDjv9YO9S
 +KmjqulbF2OsZEgcqZwuny36muLbgM5Z4MNnrieNNd/F17QiUJmztUDKB/hcUaZk
 ASztjPNNWev4W8M7HkZFfHjbX2hrCN0jXDEExNHubfiWgP0P9w9/VFlI0MSsrRUE
 ksTJCMVfy5jMWQ8pVqiBLE0BmC10yY1karUtsVpN4rmwWXzLGu4yFZikBUNpyY5c
 uVbMFdFleCdilu0nSGLfr3kVXSVn5QI8q7tkQjm6mmQbtQE1T6B5ozhNsU5XK+3r
 2GTLCFgOX2TN1WtbKzHXw1uj681WWUJb82Xug/HuxZ4quYN+FkT0MJCiKCWyoEgI
 RDX2npvAHbz0d0N7YCV6cQ==
 =Lygn
 -----END PGP SIGNATURE-----

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

Luiz Augusto von Dentz says:

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

Core:

 - hci_core: Fix race condition during device registration
 - L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan
 - L2CAP: fix out-of-bounds write in l2cap_ecred_connect
 - L2CAP: clear FLAG_DEFER_SETUP only for same PID/PSM

Drivers:

 - hci_mrvl: Fix wrong return value check of wait_on_bit_timeout()
 - btintel_pcie: Clear automask on spurious interrupts
 - btintel: validate version TLV value lengths
 - btintel: bound firmware ID by TLV length
 - btintel: propagate version TLV parsing errors

* tag 'for-net-2026-08-31' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth:
  Bluetooth: hci_mrvl: Fix wrong return value check of wait_on_bit_timeout()
  Bluetooth: L2CAP: clear FLAG_DEFER_SETUP only for same PID/PSM
  Bluetooth: L2CAP: fix out-of-bounds write in l2cap_ecred_connect
  Bluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan
  Bluetooth: hci_core: Fix race condition during device registration
  Bluetooth: btintel: propagate version TLV parsing errors
  Bluetooth: btintel: bound firmware ID by TLV length
  Bluetooth: btintel: validate version TLV value lengths
  Bluetooth: btintel_pcie: Clear automask on spurious interrupts
====================

Link: https://patch.msgid.link/20260831181837.946230-1-luiz.dentz@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 17:12:03 -07:00
Aohan Mei
fee1065570 net/sched: cls_flower: validate mask pointer after nla_next()
fl_set_enc_opt() iterates the key's nested tunnel-option attributes
with nla_for_each_attr() while advancing a single mask pointer via
nla_next() at the bottom of each loop, so the mask cursor is driven
by the number of key attributes rather than by the mask's own
attributes.  The nla_ok() added by commit c96adff956 ("cls_flower:
call nla_ok() before nla_next()") only validates the mask pointer
that was just consumed; the pointer produced by nla_next() is used by
the next iteration (fl_set_geneve_opt() and siblings) without any
validation.

The mask's nested attributes are validated with NL_VALIDATE_LIBERAL,
which merely warns on trailing bytes that do not form a complete
attribute.  A mask carrying one valid attribute plus 1-3 residue
bytes (or a non-aligned attribute length making msk_depth negative)
therefore reaches the next iteration with msk_depth != 0, so neither
the !msk_depth check in fl_set_enc_opt() nor the !depth check in the
per-type helpers fires.  nla_type() then reads past the mask payload
and nla_parse_nested_deprecated() iterates with an nla_len taken
from those bytes, reading well beyond the mask attribute (KASAN:
slab-out-of-bounds read in __nla_validate_parse from fl_change()).

Validate the advanced mask pointer as well: when the mask is not
legitimately exhausted (msk_depth != 0) and the new pointer fails
nla_ok(), reject the filter with -EINVAL.  An exactly exhausted mask
still skips the check, preserving exact-match behaviour for the
remaining key attributes.

Fixes: c96adff956 ("cls_flower: call nla_ok() before nla_next()")
Reported-by: TencentOS Corvus AI <corvus@tencent.com>
Cc: stable@vger.kernel.org
Signed-off-by: Aohan Mei <henrymei@tencent.com>
Link: https://patch.msgid.link/20260826025123.62758-1-ljp1205831794@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 17:02:56 -07:00
Jakub Kicinski
9d0f206eb3 Merge branch 'vsock-validate-packet-sources-after-bound-lookup-fallback'
Daehyeon Ko says:

====================
vsock: validate packet sources after bound lookup fallback

Both virtio and VMCI look up connected sockets by the full tuple before
falling back to a destination-only bound lookup. The fallback can select a
non-listening socket without validating the packet source.

V2 covered only the virtio path. Following Stefano's review, this series
moves the source and transport validation into a documented AF_VSOCK helper
and uses it for both virtio and VMCI. The VMCI patch checks both its
bottom-half and deferred workqueue receive paths.

V4 preserves VMCI's existing RST behavior when source validation fails.
The reset is addressed from the received packet so that a bound but
non-listening or concurrently closed socket still notifies the sender,
without directing the reset to a connected socket's stored peer.

The v3 regression was reproduced in three x86_64 KASAN boots: a REQUEST to
a bound but non-listening socket returned VMCI_ERROR_NO_ACCESS but no RST
arrived within one second. With v4, the sending context received the
expected RST in all three boots. The original VMCI source-validation oracle
also passed in three v4 boots: a matched RST reset the pending socket while
a mismatched-context RST left it pending. No KASAN report occurred.

Patch 1 is unchanged from v3 (identical stable patch-id) and carries
Bobby's Reviewed-by for that revision. Its v3 validation covered the
cross-UID injection oracle, local CID aliases, selected VSOCK selftests,
and W=1 changed-object builds under allmodconfig and allyesconfig.

The current-tree guest-CID vhost probe could not be rerun because the test
user lacks access to /dev/vhost-vsock.
====================

Link: https://patch.msgid.link/20260826003929.966160-1-4ncienth@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 16:50:58 -07:00
Daehyeon Ko
ad9a7da3fa vsock/vmci: validate packet source for connected sockets
vmci_transport_recv_stream_cb() looks up sockets first by the full source
and destination tuple, then by destination only in the bound table. The
fallback can select a non-listening socket without checking whether the
packet came from its stored peer.

This was reproduced with two VMCI contexts. A RST from the context not
stored in a TCP_SYN_SENT socket reset that socket after it was selected by
the destination-only lookup.

VMCI can process notification packets in bottom-half context when the
socket is not owned by user context, or defer packets to a workqueue. Use
vsock_check_source() after taking the socket lock in the bottom-half path,
and recheck after lock_sock() in the workqueue path. Listening sockets
continue to accept packets from any source.

Reply with a RST addressed from the received packet before dropping a
source that fails validation. This preserves the existing reset behavior
for bound non-listening and concurrently closed sockets without directing
the reset to a connected socket's stored peer.

Fixes: d021c34405 ("VSOCK: Introduce VM Sockets")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/netdev/20260814121255.6B5001F000E9@smtp.kernel.org/
Cc: stable@vger.kernel.org
Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
Suggested-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Daehyeon Ko <4ncienth@gmail.com>
Reviewed-by: Vishnu Dasa <vishnu.dasa@broadcom.com>
Link: https://patch.msgid.link/20260826003929.966160-3-4ncienth@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 16:50:54 -07:00
Daehyeon Ko
dee44f41f2 vsock/virtio: validate packet source for connected sockets
virtio_transport_recv_pkt() looks up sockets first by the full source and
destination tuple, then by destination only in the bound table. The
fallback is needed for listening and connecting sockets, but sockets remain
in the bound table after connect(), so it can also return a non-listening
socket.

The fallback does not validate the source address. In TCP_SYN_SENT, a
RESPONSE from an unrelated source can transition the victim socket to
TCP_ESTABLISHED while its stored remote address remains unchanged.
Subsequent RW packets from that source are delivered through the same
destination-only fallback.

This was reproduced with capability-empty processes under different UIDs.
The attacker discovered the target tuple through unprivileged AF_VSOCK
sock_diag and caused the victim socket to read 16 attacker-chosen bytes;
the intended peer-side socket read 0 of those 16 bytes.

Add vsock_check_source() to validate the transport, source port and source
CID against the peer stored in a non-listening socket. The local transport
is the CID exception because its packets are generated internally with
VMADDR_CID_LOCAL as their source, including connections using CID aliases.

Use the helper after lock_sock() in the virtio receive path.

Fixes: 06a8fc7836 ("VSOCK: Introduce virtio_vsock_common.ko")
Closes: https://lore.kernel.org/netdev/20260813121236.2328599-1-4ncienth@gmail.com/
Cc: stable@vger.kernel.org
Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com>
Signed-off-by: Daehyeon Ko <4ncienth@gmail.com>
Link: https://patch.msgid.link/20260826003929.966160-2-4ncienth@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 16:50:54 -07:00
Florian Schauer
dc0df5a0c6 page_pool: keep frag_offset aligned for odd-sized requests
page_pool_alloc_frag_netmem() rounds the requested fragment size with

	size = ALIGN(size, dma_get_cache_alignment());

dma_get_cache_alignment() returns 1 unless the architecture defines
ARCH_DMA_MINALIGN, which DMA-coherent architectures such as x86 do not.
There the ALIGN() is a no-op and pool->frag_offset advances by the raw,
unrounded size.

A single caller asking for an odd size then leaves frag_offset misaligned
for every fragment carved out of that page afterwards.  The pool is shared,
so the damage is not confined to the caller that caused it.

The per-cpu system_page_pool used by generic XDP hits this.
skb_pp_cow_data() allocates its fragments with the raw packet length:

	size = min_t(u32, len, PAGE_SIZE);
	truesize = size;
	page = page_pool_dev_alloc(pool, &page_off, &truesize);

leaving frag_offset odd for whatever is carved out of that page next.  Its
own head allocation is already aligned -- SKB_HEAD_ALIGN(size) plus the
XDP_PACKET_HEADROOM its callers pass -- so it is a later user of the shared
pool that pays: page_pool_dev_alloc_va() returns a misaligned buffer,
napi_build_skb() installs it as skb->head, and skb_shinfo(skb) ==
skb->head + skb->end is misaligned with it.

skb_shinfo()->dataref is a 4-byte atomic_t at offset 0x20, so the
atomic_inc() in __skb_clone() straddles a cache line.  On x86 with split
lock detection -- fatal for kernel split locks by default -- this panics
the machine:

  Oops: Split lock detected
  RIP: 0010:skb_clone+0x154/0x1e0
  Call Trace:
   <IRQ>
   raw_local_deliver+0x1ed/0x2c0
   ip_protocol_deliver_rcu+0x54/0x1c0
   ip_local_deliver_finish+0x85/0x100
   ip_local_deliver+0x67/0x100
   __netif_receive_skb_one_core+0x85/0xa0
   process_backlog+0x87/0x130

Reproduced by attaching any generic-mode XDP program to loopback and
opening a RAW IPPROTO_UDP socket, which makes raw_local_deliver() clone
every locally delivered UDP packet; ordinary DNS traffic then triggers it,
roughly once per 2500 clones.  Observed on 6.12.101 and 7.1.8.

Tracing page_pool_alloc_frag_netmem() over one such run shows the
amplification -- two odd-sized requests, nine misaligned offsets:

  requested size & 7:   0: 17035    5: 1    7: 1
  frag_offset & 7:      0: 17028    3: 1    4: 1    5: 1    6: 1    7: 5

and skb_pp_cow_data() returning heads that were aligned on entry:

  head 0xffff8f4c86aeac00 -> 0xffff8f4c53a9a9c4 (&7=4)
  head 0xffff8f4d6a8a42c0 -> 0xffff8f4c4f7b7a45 (&7=5)

Round the fragment size up to at least the alignment struct skb_shared_info
requires, so fragments are always suitably aligned for the objects callers
build on them.  Architectures needing a larger DMA alignment keep it.

This also makes the remainder computed in page_pool_alloc_netmem(),

	*size = max_size - *offset;

aligned, since max_size is a power of two -- which fixes the matching
misalignment of skb->end.

Verified with a controlled A/B under QEMU/KVM: same tree, same config,
same compiler, same rootfs and identical traffic, differing only by this
patch.  A SEC("xdp.frags") XDP_PASS program on lo plus UDP datagrams
larger than max_head_size drives skb_pp_cow_data()'s fragment loop, which
passes raw packet lengths to the pool.  Measured at the return of
skb_pp_cow_data():

                          unpatched   patched
  skb_pp_cow_data calls       40800     40800
  misaligned skb->head         1120         0
  dataref at line offset >60     80         0

The last row counts the accesses that actually fault:
skb_shinfo()->dataref sits at head+end+0x20 and is a 4-byte atomic, so
`lock incl` splits a 64-byte cache line only when that address lands at
offset 61..63.  All 80 occurrences were at offset 61; the panic reported
above was at offset 62.  Eliminating the misalignment removes every one
of them.

Same class of bug as commit 3bed3cc415 ("net: Do not allocate page
fragments that are not skb aligned"), which fixed the older
netdev_alloc_frag()/napi_alloc_frag() allocators.

Fixes: 53e0961da1 ("page_pool: add frag page recycling support in page pool")
Cc: stable@vger.kernel.org
Signed-off-by: Florian Schauer <florian@schauer.to>
Acked-by: Jesper Dangaard Brouer <hawk@kernel.org>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260828060822.2628276-1-florian@schauer.to
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 16:24:51 -07:00
Jamal Hadi Salim
7b120a7719 selftests: tc-testing: add u32 node ID pool exhaustion test
Add a tdc test case that fills the u32 node ID space with 4095
auto-generated handles, then attempts to add a 4096th. On the fixed
kernel the 4096th filter is rejected with ENOSPC (exit 2). On the
unfixed kernel it silently succeeds with a duplicate handle.

The setup pipes the 4095 add commands directly into `tc -b -` inside a
single bash -c (matching the existing test id 1234 pattern), avoiding
any temp file.

Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Link: https://patch.msgid.link/20260825081052.133898-2-jhs@mojatatu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 16:07:33 -07:00
Jamal Hadi Salim
d7e7e98d23 net/sched: cls_u32: fix duplicate handle when node ID pool is exhausted
gen_new_kid() falls back to returning max (htid | 0xFFF) when both
idr_alloc_u32() ranges are full, instead of reporting an error.
u32_change() trusts that value and inserts a new knode with a handle
that is already live in the hash table, breaking handle uniqueness
within the table's node ID space.

The handle was never reserved in ht->handle_idr, so every later error
path that does idr_remove(&ht->handle_idr, handle) removes the
reservation of a different, live knode, which is then reused — one
failed add compounds into further duplicates.

The 4095 limit is per (table, bucket) — ht->handle_idr is per hash
table and the range is derived from htid (bucketid), so a table with
divisor 256 can legitimately hold 256*4095 knodes.

The sibling helper gen_new_htid() has the same silent in-band failure:
it returns 0 when the tp_c handle pool (1..0x7FF) is full, and
u32_init() publishes the root hash table with handle 0 without
checking.  Two root tables with handle 0 alias in u32_lookup_ht(),
allowing cross-tcf_proto knode add/lookup/delete.  Add the same
exhaustion check that the divisor path already has.

Return an error so u32_change() fails with ENOSPC/ENOMEM when the
node ID space is exhausted, and so u32_init() fails with -ENOMEM
when the hash table ID space is exhausted.  The extack message
distinguishes pool exhaustion (-ENOSPC) from a transient allocation
failure (-ENOMEM).

Conditions to recreate the bug:
- CONFIG_NET_SCHED=y, CONFIG_CLS_U32=y (or =m with module loaded)
- Create a clsact qdisc on a device, then add 4095 u32 filters with
  auto-generated handles to fill the node ID space for the root hash
  table (single bucket). The 4096th auto-handle filter add triggers
  the duplicate handle (fh 800::fff reused). Reachable at Level 2
  (unshare -Urn, namespace-local CAP_NET_ADMIN).
- For gen_new_htid: create 2047 u32 proto entries on the same block
  to fill the tp_c handle pool, then create one more. The root table
  gets handle 0 and aliases with other handle-0 root tables.

Fixes: 7801db8aec ("net_sched: avoid generating same handle for u32 filters")
Reported-by: vega@nebusec.ai
Tested-by: Victor Nogueira <victor@mojatatu.com>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Link: https://patch.msgid.link/20260825081052.133898-1-jhs@mojatatu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 16:07:33 -07:00
Jakub Kicinski
f05f0d85cd Merge branch 'fix-to-possible-skb-leak-due-to-race-condtion-in-tx-path'
Selvamani Rajagopal says:

====================
Fix to possible skb leak due to race condtion in tx path

Now the traffic is handled in threaded IRQ, and the
disable_traffic flag is checked before handling the
data, new race condition is exposed, in which
buffer may leak, if threaded IRQ interrupts the
trasmit path midway.

With this change, disable_traffic and waiting_tx_skb
pointer are protected by spin lock/unlock pair.

This is highlighted in Sashiko review
https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260611-level-trigger-v5-0-4533a9e85ce2%40onsemi.com

Also on buffer overrun condition, probably due to loss of
SPI data chunks, receive path doesn't see the expected
data chunk with end_valid bit set. As a result, driver
keeps adding data chunks to the skb before running out
of space and kernel panic is seen.

With this change, before adding data to the skb, if there
is no space, skb is freed and driver starts looking for
new frame by looking for a data chunk with start_valid
bit set.

[  705.405490] skbuff: skb_over_panic: text:ffffffd2eb72a264 len:1600 put:64 head:ffffff804e5cdc40 data:ffffff804e5cdc80 tail:0x680 end:0x640 dev:eth1
[  705.405569] ------------[ cut here ]------------
[  705.405575] kernel BUG at net/core/skbuff.c:214!
[  705.405589] Internal error: Oops - BUG: 00000000f2000800 [#1]  SMP

[ 6703.427690] Call trace:
[  705.925157]  skb_panic+0x58/0x68 (P)
[  705.928726]  skb_put+0x74/0x80
[  705.931772]  oa_tc6_update_rx_skb+0x44/0x98 [oa_tc6_mod]
[  705.937084]  oa_tc6_macphy_threaded_irq+0x3f4/0x900 [oa_tc6_mod]
[  705.943084]  irq_thread_fn+0x34/0xb8
[  705.946654]  irq_thread+0x1a0/0x300
[  705.950134]  kthread+0x138/0x150
[  705.953356]  ret_from_fork+0x10/0x20
====================

Link: https://patch.msgid.link/20260824-fix-race-condition-and-crash-v7-0-4323279b18f2@onsemi.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 16:03:22 -07:00
Selvamani Rajagopal
3cc2aa96b9 net: ethernet: oa_tc6: Fix for the wrong data type
Inadvertently bool data type is used where int is supposed to
be used. This might turn a negative error code into true or
false and sign of the return code would be lost.

Fixes: 8f9bf857e4 ("net: ethernet: oa_tc6: implement internal PHY initialization")
Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
Link: https://patch.msgid.link/20260824-fix-race-condition-and-crash-v7-4-4323279b18f2@onsemi.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 16:03:21 -07:00
Selvamani Rajagopal
349c366365 net: ethernet: oa_tc6: Disable tx queues on fatal error
Previously, TX queue interface was stopped when
disable_traffic flag was set, which would indicate fatal
error. It is more appropriate to disable the queue as,
unless driver is unloaded and reloaded, there is no recovery
after disable_traffic is set.

Queues may be re-enabled inadvertently by other layers.
Intention of disable_traffic is only to stop the traffic
from flowing on fatal error.

Fixes: b542d13fab ("net: ethernet: oa_tc6: Interrupt is active low, level triggered.")
Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
Link: https://patch.msgid.link/20260824-fix-race-condition-and-crash-v7-3-4323279b18f2@onsemi.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 16:03:21 -07:00
Selvamani Rajagopal
172c974113 net: ethernet: oa_tc6: Improve the error recovery
When oversubscribed traffic causes lot of buffer overflow errors,
probably due to loss of data chunks, driver fails to find a
data chunk with end_valid bit set, before it runs out of sk buffer
space. As a result, assert is seen during skb_put.

Now, check is made if skb buffer has enough tailroom for the
incoming data before accepting. If there is no room, current
frame is abandoned and it will start looking for a data chunk
with start_valid bit, that is a new frame.

SK buffer allocation error is considered as recoverable error.

rx_buf_overflow flag is too specific and no longer the only
condition this flag is used for. Therefore it is renamed as
wait_until_start_valid. This is more appropriate as this flag
is used to look for the next data chunk with SV bit set, after
failures like buffer overflow, buffer allocation failure, skb pointer
validity besides buffer overflow error.

Not writing to status0 if it reads 0.

Fixes: d70a0d8f2f ("net: ethernet: oa_tc6: implement receive path to receive rx ethernet frames")
Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
Link: https://patch.msgid.link/20260824-fix-race-condition-and-crash-v7-2-4323279b18f2@onsemi.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 16:03:20 -07:00
Selvamani Rajagopal
5443d9c4f5 net: ethernet: oa_tc6: Protect skb pointer used by two different kernel instances
Threaded IRQ uses waiting_tx_skb. Transmit path also uses this pointer
without any mutual exclusion protection. As a result, it might leak skb
buffer, particularly if threaded IRQ sets disable_traffic true after
start_xmit already checked and found that disable_traffic being false,
if they happen to run on different cores.

On fatal error, where disable_traffic is set, transmit function drops the
packet and return NETDEV_TX_OK. Due to this change, skb_linearize call
is moved up to the beginning of the transmit function.

Since skb buffer may be freed from different contexts, dev_kfree_skb_any
is used to free skb buffer now, replacing one of the kfree_skb call.

oa_tc6_exit disables the irq before setting disable_traffic true.

Fixes: b542d13fab ("net: ethernet: oa_tc6: Interrupt is active low, level triggered.")
Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
Link: https://patch.msgid.link/20260824-fix-race-condition-and-crash-v7-1-4323279b18f2@onsemi.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 16:03:20 -07:00
Bryam Vargas
fa5acd038e net/iucv: fix the recvmsg window update
iucv_sock_recvmsg() sends the HiperSockets-only AF_IUCV_FLAG_WIN without
testing the transport, so on a classic z/VM socket iucv_send_ctrl() sizes
the skb through a NULL iucv->hs_dev. SO_MSGLIMIT accepts 1, so msglimit / 2
is zero and one recvmsg() on its own socket is enough for an unprivileged
process to take a spurious disconnect.

It also calls iucv_send_ctrl() under spin_lock_bh(&message_q.lock), which
allocates GFP_KERNEL inside a section the code treats as atomic. Sending
outside that lock lets two recvmsg() reach afiucv_hs_send() at once, where
msg_recv is sampled for the advertised window and subtracted after
dev_queue_xmit() -- and sendmsg reaches that counter under lock_sock()
while recvmsg holds no socket lock, so both can subtract the same value,
the counter goes negative and the credit reaches the peer twice.

Test the transport, claim the credit with atomic_xchg() after the last
error exit and hand it back if the transmit fails, and send once the lock
is dropped.

Fixes: 3881ac441f ("af_iucv: add HiperSockets transport")
Fixes: 238965b71b ("net/af_iucv: build proper skbs for HiperTransport")
Cc: stable@vger.kernel.org
Tested-by: Aswin Karuvally <aswin@linux.ibm.com>
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
Link: https://patch.msgid.link/20260828-b4-disp-33fac0ed-v3-1-e6d061880ee0@proton.me
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-08-31 15:51:22 -07:00
Arvind Yadav
8eae39cd0a drm/pagemap: Reset migration page count on eviction retry
drm_pagemap_evict_to_ram() may retry eviction, but mpages retains
the count from the previous attempt. A retry can therefore continue
to the copy path even when no RAM pages were populated.

Reset mpages at the retry label so it reflects only the current
attempt.

Fixes: 99624bdff8 ("drm/gpusvm: Add support for GPU Shared Virtual Memory")
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260728090304.1264759-1-arvind.yadav@intel.com
2026-08-31 14:56:05 -07:00
Arvind Yadav
c4126f1db3 drm/pagemap: Prevent double migration of device pages
A device-private folio migrated to system memory by a CPU fault can
remain reachable through the raw-PFN eviction path until migration
finalization drops the source reference.

If eviction selects the same device-private folio during this window,
it can attempt to migrate the folio again. The second migration can leave
an uncharged folio on an LRU list, causing folio_lruvec_lock_irqsave() to
retry indefinitely and resulting in a soft lockup and RCU stall.

Mark successfully migrated device-private folios using a low bit of
their zone_device_data before migration finalization. Make both CPU-fault
and raw-PFN migration paths skip device-private folios carrying this
flag.

Mask the flag when retrieving the drm_pagemap_zdd pointer and preserve
it when a device-private folio is split. Keeping the state on the physical
folio also avoids depending on a virtual address that may change before a
fault occurs.

v2:
- Replace the retired-PFN XArray with an embedded bitmap. (Matthew Brost)
- Mark every base page covered by a migrated folio so retirement remains
  valid if the folio is later split.

v3:
- Store the migrated state in a low bit of zone_device_data instead of
  adding virtual-range and bitmap tracking to the ZDD. (Matthew Brost)
- Mask the flag when retrieving the ZDD and preserve it when splitting
  a folio.
- Drop the pre-existing fixes already covered by Matthew Brost's series:
  https://patchwork.freedesktop.org/series/171651/

v4:
- Advance by the folio size only for migration entries marked with
  MIGRATE_PFN_COMPOUND. (Sashiko)

v5:
- Simplify ZDD flag updates and folio iteration. (Matthew Brost)
- Skip retired device-private folios in the CPU-fault path. (Matthew Brost)
- Preserve flag bits while taking a new ZDD reference for split folios.

v6:
- Restore MIGRATE_PFN_COMPOUND-aware stepping so non-compound migration
  entries are processed one at a time. (Sashiko)
- Drop the pre-existing fixes already covered by Matthew Brost's series:
  https://patchwork.freedesktop.org/series/171651/

The lockup was observed as:
[10109.860465] watchdog: BUG: soft lockup - CPU#9 stuck for 26s! [kworker/u65:5:6557]
[10109.860524] Tainted: [S]=CPU_OUT_OF_SPEC, [O]=OOT_MODULE
[10109.860524] Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 0812 02/24/2023
[10109.860525] Workqueue: xe_page_fault_work_queue xe_pagefault_queue_work [xe]
[10109.860644] RIP: 0010:_raw_spin_unlock_irqrestore+0x57/0x80
[10109.860655] Call Trace:
[10109.860655]  <TASK>
[10109.860657]  folio_lruvec_lock_irqsave+0x216/0x220
[10109.860661]  ? __pfx_lru_add+0x10/0x10
[10109.860665]  folio_batch_move_lru+0xc8/0x450
[10109.860670]  ? lock_acquire+0xc4/0x2d0
[10109.860674]  ? __folio_batch_add_and_move+0x60/0x2e0
[10109.860677]  ? folio_migrate_mapping+0xa6/0x110
[10109.860679]  ? folio_migrate_flags+0x13b/0x1b0
[10109.860681]  ? __pfx_lru_add+0x10/0x10
[10109.860683]  __folio_batch_add_and_move+0xe7/0x2e0
[10109.860685]  ? dma_iova_try_alloc+0xb0/0x140
[10109.860689]  folio_add_lru+0x64/0x80
[10109.860691]  __migrate_device_finalize+0x12c/0x270
[10109.860695]  migrate_device_finalize+0x10/0x20
[10109.860698]  drm_pagemap_evict_to_ram+0x185/0x370 [drm_gpusvm_helper]
[10109.860704]  ? drm_pagemap_evict_to_ram+0x96/0x370 [drm_gpusvm_helper]
[10109.860709]  xe_svm_bo_evict+0x15/0x20 [xe]
[10109.860819]  ? xe_svm_bo_evict+0x15/0x20 [xe]
[10109.860921]  xe_bo_move+0x107e/0x1570 [xe]
[10109.860992]  ? xe_ttm_tt_create+0x168/0x340 [xe]
[10109.861059]  ? __up_read+0x98/0x2b0
[10109.861061]  ? lock_is_held_type+0xa3/0x130
[10109.861067]  ttm_bo_handle_move_mem+0xe8/0x1e0 [ttm]
[10109.861075]  ttm_bo_evict+0x141/0x1c0 [ttm]
[10109.861081]  ttm_bo_evict_cb+0x9f/0x100 [ttm]
[10109.861086]  ttm_lru_walk_for_evict+0x84/0x190 [ttm]
[10109.861091]  ? xe_ttm_vram_mgr_new+0x258/0x3a0 [xe]
[10109.861198]  ttm_bo_alloc_resource+0x219/0x750 [ttm]
[10109.861203]  ? ttm_bo_alloc_resource+0xa9/0x750 [ttm]
[10109.861208]  ? lock_acquire+0xc4/0x2d0
[10109.861214]  ttm_bo_validate+0x94/0x1c0 [ttm]
[10109.861218]  ? ww_mutex_trylock+0x19d/0x3d0
[10109.861219]  ? _raw_write_unlock+0x22/0x50
[10109.861223]  ttm_bo_init_reserved+0x17d/0x1f0 [ttm]
[10109.861228]  xe_bo_init_locked+0x20a/0x620 [xe]
[10109.861294]  ? __pfx_xe_ttm_bo_destroy+0x10/0x10 [xe]
[10109.861359]  ? mark_held_locks+0x46/0x90
[10109.861361]  ? __create_object+0x68/0xc0
[10109.861366]  __xe_bo_create_locked+0x384/0xa20 [xe]
[10109.861432]  ? lock_acquire+0xc4/0x2d0
[10109.861434]  ? xe_drm_pagemap_populate_mm+0xd3/0x340 [xe]
[10109.861542]  xe_bo_create_locked+0x23/0x40 [xe]
[10109.861609]  xe_drm_pagemap_populate_mm+0x12e/0x340 [xe]
[10109.861707]  ? __lock_acquire+0x43e/0x2930
[10109.861716]  drm_pagemap_populate_mm+0x74/0xe0 [drm_gpusvm_helper]
[10109.861720]  xe_svm_alloc_vram+0xb5/0x2c0 [xe]
[10109.861817]  ? seqcount_lockdep_reader_access.constprop.0+0x9f/0xc0
[10109.861819]  ? ktime_get+0x23/0x130
[10109.861821]  ? trace_hardirqs_on+0x22/0xe0
[10109.861823]  ? seqcount_lockdep_reader_access.constprop.0+0x9f/0xc0
[10109.861826]  __xe_svm_handle_pagefault+0x77d/0xbf0 [xe]
[10109.861924]  ? rwsem_down_write_slowpath+0x43a/0x9a0
[10109.861926]  ? _raw_spin_unlock_irq+0x27/0x70
[10109.861928]  ? rwsem_down_write_slowpath+0x43a/0x9a0
[10109.861929]  ? trace_hardirqs_on+0x22/0xe0
[10109.861931]  ? _raw_spin_unlock_irq+0x27/0x70
[10109.861933]  ? rwsem_down_write_slowpath+0x459/0x9a0
[10109.861937]  xe_svm_handle_pagefault+0x3d/0xb0 [xe]
[10109.862030]  xe_pagefault_queue_work+0x1a9/0x520 [xe]
[10109.862122]  process_one_work+0x239/0x730
[10109.862127]  worker_thread+0x200/0x3f0
[10109.862130]  ? __pfx_worker_thread+0x10/0x10
[10109.862132]  kthread+0x10d/0x150
[10109.862133]  ? __pfx_kthread+0x10/0x10
[10109.862135]  ret_from_fork+0x3bd/0x470
[10109.862138]  ? __pfx_kthread+0x10/0x10
[10109.862140]  ret_from_fork_asm+0x1a/0x30
[10109.862146]  </TASK>

Fixes: 99624bdff8 ("drm/gpusvm: Add support for GPU Shared Virtual Memory")
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Assisted-by: Claude:claude-opus-4-8
Suggested-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260810092845.2776097-1-arvind.yadav@intel.com
2026-08-31 14:56:03 -07:00
Linus Torvalds
abdf623ddb workqueue: Fixes for v7.3-rc1
- An unbound worker pool could be freed while still reachable through the
   pending-activation list, leading to a use-after-free. Unlink before
   dropping the reference.
 
 - On PREEMPT_RT, the BH workqueue kick raised softirqs from preemptible
   context, tripping a lockdep assertion and possibly losing concurrently
   raised softirq bits.
 
 - Draining BH work off a dead CPU nests two pools' callback locks, which
   lockdep misreported as recursive locking. The nesting cannot deadlock.
   Annotate it.
 
 - Reject watchdog thresholds that overflow the conversion to jiffies.
 
 - Make the drgn workqueue dump script work again on kernels and vmcores
   from before the workqueue attrs field rename.
 -----BEGIN PGP SIGNATURE-----
 
 iIQEABYKACwWIQTfIjM1kS57o3GsC/uxYfJx3gVYGQUCapXs/Q4cdGpAa2VybmVs
 Lm9yZwAKCRCxYfJx3gVYGd75AP9VTI8d7dor4mn82j7J6l8Xcy8U1ePM/K5v1PqU
 n9lfUwD/aopS+dp/uCuqR6pLBxineFAPxNoEgxxO2bDv9OqhoAY=
 =fj3U
 -----END PGP SIGNATURE-----

Merge tag 'wq-for-7.3-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq

Pull workqueue fixes from Tejun Heo:

 - An unbound worker pool could be freed while still reachable through
   the pending-activation list, leading to a use-after-free. Unlink
   before dropping the reference

 - On PREEMPT_RT, the BH workqueue kick raised softirqs from preemptible
   context, tripping a lockdep assertion and possibly losing
   concurrently raised softirq bits

 - Draining BH work off a dead CPU nests two pools' callback locks,
   which lockdep misreported as recursive locking. The nesting cannot
   deadlock. Annotate it

 - Reject watchdog thresholds that overflow the conversion to jiffies

 - Make the drgn workqueue dump script work again on kernels and vmcores
   from before the workqueue attrs field rename

* tag 'wq-for-7.3-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
  tools/workqueue/wq_dump.py: Support backward compatibility for wq->attrs rename
  workqueue: reject watchdog thresholds that overflow jiffies
  workqueue: Fix unbound pool lifetime for pending pwqs
  workqueue: Use raise_softirq() to trigger softirq in irq_work handler
  workqueue: Annotate cb_lock nesting when draining a dead BH pool
2026-08-31 14:38:40 -07:00
Linus Torvalds
c3b510de42 cgroup: Fixes for v7.3-rc1
- After cgroup.kill was written to a cgroup, every child cloned into it
   with CLONE_INTO_CGROUP was spuriously killed because the fork path
   snapshotted the kill counter before resolving the target cgroup.
 
 - Releasing an isolated cpuset partition dropped the isolation of CPUs
   isolated on the kernel command line.
 
 - Selftest and documentation fixes.
 -----BEGIN PGP SIGNATURE-----
 
 iIQEABYKACwWIQTfIjM1kS57o3GsC/uxYfJx3gVYGQUCapXm8w4cdGpAa2VybmVs
 Lm9yZwAKCRCxYfJx3gVYGbhtAQCfUc4oanF94uiAGzH2UAA2HIorLT4TDjuDj/oM
 qrqeLQEA1p2XQz56SYXhK8fG+fy+Ep3xxqS2gStmtYL20ie4lQc=
 =i4QU
 -----END PGP SIGNATURE-----

Merge tag 'cgroup-for-7.3-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup

Pull cgroup fixes from Tejun Heo:

 - After cgroup.kill was written to a cgroup, every child cloned into it
   with CLONE_INTO_CGROUP was spuriously killed because the fork path
   snapshotted the kill counter before resolving the target cgroup

 - Releasing an isolated cpuset partition dropped the isolation of CPUs
   isolated on the kernel command line

 - Selftest and documentation fixes

* tag 'cgroup-for-7.3-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
  selftests/cgroup: test clone3() into a previously killed cgroup
  cgroup: fix spurious SIGKILL of CLONE_INTO_CGROUP children
  selftests/cgroup: Add test for preserving boot-isolated CPUs
  cgroup/cpuset: Preserve boot-isolated CPUs on partition release
  selftests/cgroup: Drop invalid boot isolation comparison
  docs: cgroup-v2: fix misc.events key format description
  selftests/cgroup: Fix cg_run_in_subcgroups ignoring arg parameter
  selftests/cgroup: set the test plan after the setup checks
2026-08-31 14:20:32 -07:00
Aaron Tomlin
93e257938a tools/workqueue/wq_dump.py: Support backward compatibility for wq->attrs rename
Commit 464e454e1c ("workqueue: rename wq->unbound_attrs to wq->attrs")
renamed wq->unbound_attrs to wq->attrs. When running wq_dump.py against
older running kernels or vmcores where struct workqueue_struct still
contains unbound_attrs, drgn raises an AttributeError.

Add a wq_attrs() helper to allow wq_dump.py to inspect both older and newer
kernel versions seamlessly.

Fixes: 464e454e1c ("workqueue: rename wq->unbound_attrs to wq->attrs")
Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-31 10:17:08 -10:00
Linus Torvalds
bf1079577a sched_ext: Fixes for v7.3-rc1
- The task ownership check in the dispatch queue move operation raced
   against the task exiting or moving to a different sub-scheduler,
   spuriously triggering scheduler aborts. Fix by moving the check under
   the queue lock.
 
 - The cgroup bandwidth change callback runs in a sleepable context but
   sleepable implementations were rejected at load time. Allow them and add
   a marker so userspace can detect the capability.
 
 - Sync tooling headers with the scx repo for accumulated compatibility
   improvements.
 
 - Example scheduler fixes: ignored timer re-arm failures and vtime credit
   loss on cgroup migration.
 
 - Documentation and comment fixes.
 -----BEGIN PGP SIGNATURE-----
 
 iIQEABYKACwWIQTfIjM1kS57o3GsC/uxYfJx3gVYGQUCapXcug4cdGpAa2VybmVs
 Lm9yZwAKCRCxYfJx3gVYGZFfAQCMdpcFMqLdaHkRMiWK+SopQ703AnnpoX9xC81t
 vy81mQD/QlIEZimidIS2xju3/HkHfVXX6hHxAbMy8hdclhYHlgM=
 =256l
 -----END PGP SIGNATURE-----

Merge tag 'sched_ext-for-7.3-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext

Pull sched_ext fixes from Tejun Heo:

 - The task ownership check in the dispatch queue move operation raced
   against the task exiting or moving to a different sub-scheduler,
   spuriously triggering scheduler aborts. Fix by moving the check under
   the queue lock

 - The cgroup bandwidth change callback runs in a sleepable context but
   sleepable implementations were rejected at load time. Allow them and
   add a marker so userspace can detect the capability

 - Sync tooling headers with the scx repo for accumulated compatibility
   improvements

 - Example scheduler fixes: ignored timer re-arm failures and vtime
   credit loss on cgroup migration

 - Documentation and comment fixes

* tag 'sched_ext-for-7.3-rc1-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext:
  sched_ext: Fix missing @slice and @vtime descriptions in finish_dispatch() kernel-doc
  sched_ext: Fix several comment issues
  sched_ext: Check bpf_timer_start return values in scx_qmap
  sched_ext: Fix vtime delta loss in scx_flatcg cgroup migration
  sched_ext: Fix timer pinning and return value in scx_central
  docs/sched_ext: document that cgroup CPU knobs are scheduler-dependent
  sched_ext: Fix spurious aborts in scx_bpf_dsq_move() on ownership change races
  sched_ext: Sync common and compat headers from the scx repo
  sched_ext: Sync tools autogen enum headers from the scx repo
  Docs/admin-guide/cgroup-v2: document BPF scheduler callbacks for cpu.max and cpu.idle
  sched_ext: Fix nonexistent field in sched-ext.rst example
  sched_ext: Allow ops.cgroup_set_bandwidth() to be sleepable
2026-08-31 13:13:35 -07:00
Paul Moore
77d499e61d selinux: fix BPF token permission checks
Avoid multiple lookups of the bpffs creator SID using the token's file
descriptor when the same information can be found via the resolved
path/dentry (in selinux_bpf_token_create()) or the token itself (in
selinux_bpf_map_create() and selinux_bpf_prog_load()).  Not only does
this simplify the code, it avoids potential TOCTOU issues if the user
changes the token file descriptor passed into the kernel.

Cc: stable@vger.kernel.org
Fixes: 5473a722f7 ("selinux: add support for BPF token access control")
Reviewed-by: Stephen Smalley <stephen.smalley.work@gmail.com>
Tested-by: Stephen Smalley <stephen.smalley.work@gmail.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
2026-08-31 14:09:27 -04:00
Gongwei Li
2deb76c21b Bluetooth: hci_mrvl: Fix wrong return value check of wait_on_bit_timeout()
wait_on_bit_timeout() returns 0 if the bit was cleared, -EINTR if the
process received a signal and the mode permitted wake up on that signal,
or -EAGAIN if the timeout elapsed.  It never returns 1.

Hence the check "err == 1" in mrvl_load_firmware() is dead code: when
the waiting task is interrupted by a signal (-EINTR), the code falls
into the "else if (err)" branch and misreports it as "Firmware request
timeout" with -ETIMEDOUT instead of propagating -EINTR.

Fix this by testing for -EINTR so that an interrupted firmware load is
properly detected and reported.

Fixes: 162f812f23 ("Bluetooth: hci_uart: Add Marvell support")
Signed-off-by: Gongwei Li <ligongwei@kylinos.cn>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-31 14:05:27 -04:00