summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-07-27bpf: Simplify bounds refinement from s32Paul Chaignon
During the bounds refinement, we improve the precision of various ranges by looking at other ranges. Among others, we improve the following in this order (other things happen between 1 and 2): 1. Improve u32 from s32 in __reg32_deduce_bounds. 2. Improve s/u64 from u32 in __reg_deduce_mixed_bounds. 3. Improve s/u64 from s32 in __reg_deduce_mixed_bounds. In particular, if the s32 range forms a valid u32 range, we will use it to improve the u32 range in __reg32_deduce_bounds. In __reg_deduce_mixed_bounds, under the same condition, we will use the s32 range to improve the s/u64 ranges. If at (1) we were able to learn from s32 to improve u32, we'll then be able to use that in (2) to improve s/u64. Hence, as (3) happens under the same precondition as (1), it won't improve s/u64 ranges further than (1)+(2) did. Thus, we can get rid of (3). In addition to the extensive suite of selftests for bounds refinement, this patch was also tested with the Agni formal verification tool [1]. Additionally, Eduard mentioned: The argument appears to be as follows: Under precondition `(u32)reg->s32_min <= (u32)reg->s32_max` __reg32_deduce_bounds produces: reg->u32_min = max_t(u32, reg->s32_min, reg->u32_min); reg->u32_max = min_t(u32, reg->s32_max, reg->u32_max); And then first part of __reg_deduce_mixed_bounds assigns: a. reg->umin umax= (reg->umin & ~0xffffffffULL) | max_t(u32, reg->s32_min, reg->u32_min); b. reg->umax umin= (reg->umax & ~0xffffffffULL) | min_t(u32, reg->s32_max, reg->u32_max); And then second part of __reg_deduce_mixed_bounds assigns: c. reg->umin umax= (reg->umin & ~0xffffffffULL) | (u32)reg->s32_min; d. reg->umax umin= (reg->umax & ~0xffffffffULL) | (u32)reg->s32_max; But assignment (c) is a noop because: max_t(u32, reg->s32_min, reg->u32_min) >= (u32)reg->s32_min Hence RHS(a) >= RHS(c) and umin= does nothing. Also assignment (d) is a noop because: min_t(u32, reg->s32_max, reg->u32_max) <= (u32)reg->s32_max Hence RHS(b) <= RHS(d) and umin= does nothing. Plus the same reasoning for the part dealing with reg->s{min,max}_value: e. reg->smin_value smax= (reg->smin_value & ~0xffffffffULL) | max_t(u32, reg->s32_min_value, reg->u32_min_value); f. reg->smax_value smin= (reg->smax_value & ~0xffffffffULL) | min_t(u32, reg->s32_max_value, reg->u32_max_value); vs g. reg->smin_value smax= (reg->smin_value & ~0xffffffffULL) | (u32)reg->s32_min_value; h. reg->smax_value smin= (reg->smax_value & ~0xffffffffULL) | (u32)reg->s32_max_value; RHS(e) >= RHS(g) and RHS(f) <= RHS(h), hence smax=,smin= do nothing. This appears to be correct. Also, Shung-Hsi: Beside going through the reasoning, I also played with CBMC a bit to double check that as far as a single run of __reg_deduce_bounds() is concerned (and that the register state matches certain handwavy expectations), the change indeed still preserve the original behavior. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Shung-Hsi Yu <shung-hsi.yu@suse.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://github.com/bpfverif/agni [1] Link: https://lore.kernel.org/bpf/aIJwnFnFyUjNsCNa@mail.gmail.com
2025-07-27Merge tag 'timers-urgent-2025-07-27' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer fix from Thomas Gleixner: "A single fix for the PTP systemcounter mechanism: The rework of this mechanism added a 'use_nsec' member to struct system_counterval. get_device_system_crosststamp() instantiates that struct on the stack and hands a pointer to the driver callback. Only the drivers which set use_nsec to true, initialize that field, but all others ignore it. As get_device_system_crosststamp() does not initialize the struct, the use_nsec field contains random stack content in those cases. That causes a miscalulation usually resulting in a failing range check in the best case. Initialize the structure before handing it to the drivers to cure that" * tag 'timers-urgent-2025-07-27' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: timekeeping: Zero initialize system_counterval when querying time from phc drivers
2025-07-27gpiolib: enable CONFIG_GPIOLIB_LEGACY even for !GPIOLIBArnd Bergmann
A few drivers that use the legacy GPIOLIB interfaces can be enabled even when GPIOLIB is disabled entirely. With my previous patch this now causes build failures like: drivers/nfc/s3fwrn5/uart.c: In function 's3fwrn82_uart_parse_dt': drivers/nfc/s3fwrn5/uart.c:100:14: error: implicit declaration of function 'gpio_is_valid'; did you mean 'uuid_is_valid'? [-Werror=implicit-function-declaration] These did not show up in my randconfig tests because randconfig almost always has GPIOLIB selected by some other driver, and I did most of the testing with follow-up patches that address the failures properly. Move the symbol outside of the 'if CONFIG_GPIOLIB' block for the moment to avoid the build failures. It can be moved back and turned off by default once all the driver specific changes are merged. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202507261934.yIHeUuEQ-lkp@intel.com/ Fixes: 678bae2eaa81 ("gpiolib: make legacy interfaces optional") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20250726211053.2226857-1-arnd@kernel.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-26Merge tag 'spi-fix-v6.16-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fix from Mark Brown: "One last fix for v6.16, removing some hard coding to avoid data corruption on some NAND devices in the QPIC driver" * tag 'spi-fix-v6.16-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: spi-qpic-snand: don't hardcode ECC steps
2025-07-26sched/task_stack: Add missing const qualifier to end_of_stack()Kees Cook
Add missing const qualifier to the non-CONFIG_THREAD_INFO_IN_TASK version of end_of_stack() to match the CONFIG_THREAD_INFO_IN_TASK version. Fixes a warning with CONFIG_KSTACK_ERASE=y on archs that don't select THREAD_INFO_IN_TASK (such as LoongArch): error: passing 'const struct task_struct *' to parameter of type 'struct task_struct *' discards qualifiers The stackleak_task_low_bound() function correctly uses a const task parameter, but the legacy end_of_stack() prototype didn't like that. Build tested on loongarch (with CONFIG_KSTACK_ERASE=y) and m68k (with CONFIG_DEBUG_STACK_USAGE=y). Fixes: a45728fd4120 ("LoongArch: Enable HAVE_ARCH_STACKLEAK") Reported-by: Nathan Chancellor <nathan@kernel.org> Closes: https://lore.kernel.org/all/20250726004313.GA3650901@ax162 Cc: Youling Tang <tangyouling@kylinos.cn> Cc: Huacai Chen <chenhuacai@loongson.cn> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Kees Cook <kees@kernel.org>
2025-07-26kstack_erase: Support Clang stack depth trackingKees Cook
Wire up CONFIG_KSTACK_ERASE to Clang 21's new stack depth tracking callback[1] option. Link: https://clang.llvm.org/docs/SanitizerCoverage.html#tracing-stack-depth [1] Acked-by: Nicolas Schier <n.schier@avm.de> Link: https://lore.kernel.org/r/20250724055029.3623499-4-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
2025-07-26kstack_erase: Add -mgeneral-regs-only to silence Clang warningsKees Cook
Once CONFIG_KSTACK_ERASE is enabled with Clang on i386, the build warns: kernel/kstack_erase.c:168:2: warning: function with attribute 'no_caller_saved_registers' should only call a function with attribute 'no_caller_saved_registers' or be compiled with '-mgeneral-regs-only' [-Wexcessive-regsave] Add -mgeneral-regs-only for the kstack_erase handler, to make Clang feel better (it is effectively a no-op flag for the kernel). No binary changes encountered. Build & boot tested with Clang 21 on x86_64, and i386. Build tested with GCC 14.2.0 on x86_64, i386, arm64, and arm. Reported-by: Nathan Chancellor <nathan@kernel.org> Closes: https://lore.kernel.org/all/20250726004313.GA3650901@ax162 Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Kees Cook <kees@kernel.org>
2025-07-26init.h: Disable sanitizer coverage for __init and __headKees Cook
While __noinstr already contained __no_sanitize_coverage, it needs to be added to __init and __head section markings to support the Clang implementation of CONFIG_KSTACK_ERASE. This is to make sure the stack depth tracking callback is not executed in unsupported contexts. The other sanitizer coverage options (trace-pc and trace-cmp) aren't needed in __head nor __init either ("We are interested in code coverage as a function of a syscall inputs"[1]), so this is fine to disable for them as well. Link: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/kcov.c?h=v6.14#n179 [1] Acked-by: Marco Elver <elver@google.com> Link: https://lore.kernel.org/r/20250724055029.3623499-3-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
2025-07-26kstack_erase: Disable kstack_erase for all of arm compressed boot codeKees Cook
When building with CONFIG_KSTACK_ERASE=y and CONFIG_ARM_ATAG_DTB_COMPAT=y, the compressed boot environment encounters an undefined symbol error: ld.lld: error: undefined symbol: __sanitizer_cov_stack_depth >>> referenced by atags_to_fdt.c:135 This occurs because the compiler instruments the atags_to_fdt() function with sanitizer coverage calls, but the minimal compressed boot environment lacks access to sanitizer runtime support. The compressed boot environment already disables stack protector with -fno-stack-protector. Similarly disable sanitizer coverage by adding $(DISABLE_KSTACK_ERASE) to the general compiler flags (and remove it from the one place it was noticed before), which contains the appropriate flags to prevent sanitizer instrumentation. This follows the same pattern used in other early boot contexts where sanitizer runtime support is unavailable. Reported-by: Linux Kernel Functional Testing <lkft@linaro.org> Closes: https://lore.kernel.org/all/CA+G9fYtBk8qnpWvoaFwymCx5s5i-5KXtPGpmf=_+UKJddCOnLA@mail.gmail.com Reported-by: Nathan Chancellor <nathan@kernel.org> Closes: https://lore.kernel.org/all/20250726004313.GA3650901@ax162 Suggested-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Kees Cook <kees@kernel.org>
2025-07-26Merge tag 'i2c-for-6.16-rc8' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: - qup: avoid potential hang when waiting for bus idle - tegra: improve ACPI reset error handling - virtio: use interruptible wait to prevent hang during transfer * tag 'i2c-for-6.16-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: qup: jump out of the loop in case of timeout i2c: virtio: Avoid hang by using interruptible completion wait i2c: tegra: Fix reset error handling with ACPI
2025-07-26Merge tag 'clk-fixes-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk fixes from Stephen Boyd: "A few Allwinner clk driver fixes: - Mark Allwinner A523 MBUS clock as critical to avoid system stalls - Fix names of CSI related clocks on Allwinner V3s. This includes changes to the driver, DT bindings and DT files. - Fix parents of TCON clock on Allwinner V3s" * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: clk: sunxi-ng: v3s: Fix TCON clock parents clk: sunxi-ng: v3s: Fix CSI1 MCLK clock name clk: sunxi-ng: v3s: Fix CSI SCLK clock name clk: sunxi-ng: a523: Mark MBUS clock as critical
2025-07-26selftests/bpf: Enable private stack tests for arm64Puranjay Mohan
As arm64 JIT now supports private stack, make sure all relevant tests run on arm64 architecture. Relevant tests: #415/1 struct_ops_private_stack/private_stack:OK #415/2 struct_ops_private_stack/private_stack_fail:OK #415/3 struct_ops_private_stack/private_stack_recur:OK #415 struct_ops_private_stack:OK #549/1 verifier_private_stack/Private stack, single prog:OK #549/2 verifier_private_stack/Private stack, subtree > MAX_BPF_STACK:OK #549/3 verifier_private_stack/No private stack:OK #549/4 verifier_private_stack/Private stack, callback:OK #549/5 verifier_private_stack/Private stack, exception in mainprog:OK #549/6 verifier_private_stack/Private stack, exception in subprog:OK #549/7 verifier_private_stack/Private stack, async callback, not nested:OK #549/8 verifier_private_stack/Private stack, async callback, potential nesting:OK #549 verifier_private_stack:OK Summary: 2/11 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/bpf/20250724120257.7299-4-puranjay@kernel.org
2025-07-26bpf, arm64: JIT support for private stackPuranjay Mohan
The private stack is allocated in bpf_int_jit_compile() with 16-byte alignment. It includes additional guard regions to detect stack overflows and underflows at runtime. Memory layout: +------------------------------------------------------+ | | | 16 bytes padding (overflow guard - stack top) | | [ detects writes beyond top of stack ] | BPF FP ->+------------------------------------------------------+ | | | BPF private stack (sized by verifier) | | [ 16-byte aligned ] | | | BPF PRIV SP ->+------------------------------------------------------+ | | | 16 bytes padding (underflow guard - stack bottom) | | [ detects accesses before start of stack ] | | | +------------------------------------------------------+ On detection of an overflow or underflow, the kernel emits messages like: BPF private stack overflow/underflow detected for prog <prog_name> After commit bd737fcb6485 ("bpf, arm64: Get rid of fpb"), Jited BPF programs use the stack in two ways: 1. Via the BPF frame pointer (top of stack), using negative offsets. 2. Via the stack pointer (bottom of stack), using positive offsets in LDR/STR instructions. When a private stack is used, ARM64 callee-saved register x27 replaces the stack pointer. The BPF frame pointer usage remains unchanged; but it now points to the top of the private stack. Relevant tests (Enabled in following patch): #415/1 struct_ops_private_stack/private_stack:OK #415/2 struct_ops_private_stack/private_stack_fail:OK #415/3 struct_ops_private_stack/private_stack_recur:OK #415 struct_ops_private_stack:OK #549/1 verifier_private_stack/Private stack, single prog:OK #549/2 verifier_private_stack/Private stack, subtree > MAX_BPF_STACK:OK #549/3 verifier_private_stack/No private stack:OK #549/4 verifier_private_stack/Private stack, callback:OK #549/5 verifier_private_stack/Private stack, exception in main prog:OK #549/6 verifier_private_stack/Private stack, exception in subprog:OK #549/7 verifier_private_stack/Private stack, async callback, not nested:OK #549/8 verifier_private_stack/Private stack, async callback, potential nesting:OK #549 verifier_private_stack:OK Summary: 2/11 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/bpf/20250724120257.7299-3-puranjay@kernel.org
2025-07-26bpf: Move bpf_jit_get_prog_name() to core.cPuranjay Mohan
bpf_jit_get_prog_name() will be used by all JITs when enabling support for private stack. This function is currently implemented in the x86 JIT. Move the function to core.c so that other JITs can easily use it in their implementation of private stack. Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/bpf/20250724120257.7299-2-puranjay@kernel.org
2025-07-26bpf, arm64: Fix fp initialization for exception boundaryPuranjay Mohan
In the ARM64 BPF JIT when prog->aux->exception_boundary is set for a BPF program, find_used_callee_regs() is not called because for a program acting as exception boundary, all callee saved registers are saved. find_used_callee_regs() sets `ctx->fp_used = true;` when it sees FP being used in any of the instructions. For programs acting as exception boundary, ctx->fp_used remains false even if frame pointer is used by the program and therefore, FP is not set-up for such programs in the prologue. This can cause the kernel to crash due to a pagefault. Fix it by setting ctx->fp_used = true for exception boundary programs as fp is always saved in such programs. Fixes: 5d4fa9ec5643 ("bpf, arm64: Avoid blindly saving/restoring all callee-saved registers") Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Xu Kuohai <xukuohai@huawei.com> Link: https://lore.kernel.org/bpf/20250722133410.54161-2-puranjay@kernel.org
2025-07-26dpll: zl3073x: Fix build failureIvan Vecera
If CONFIG_ZL3073X is enabled but both CONFIG_ZL3073X_I2C and CONFIG_ZL3073X_SPI are disabled, the compilation may fail because CONFIG_REGMAP is not enabled. Fix the issue by selecting CONFIG_REGMAP when CONFIG_ZL3073X is enabled. Fixes: 2df8e64e01c10 ("dpll: Add basic Microchip ZL3073x support") Signed-off-by: Ivan Vecera <ivecera@redhat.com> Link: https://patch.msgid.link/20250726184145.25769-1-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-26selftests: bpf: fix legacy netfilter optionsJakub Kicinski
Recent commit to add NETFILTER_XTABLES_LEGACY missed setting a couple of configs to y. They are still enabled but as modules which appears to have upset BPF CI, e.g.: test_bpf_nf_ct:FAIL:iptables-legacy -t raw -A PREROUTING -j CONNMARK --set-mark 42/0 unexpected error: 768 (errno 0) Fixes: 3c3ab65f00eb ("selftests: net: Enable legacy netfilter legacy options.") Link: https://patch.msgid.link/20250726155349.1161845-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-26umd: Remove usermode driver frameworkThomas Weißschuh
The code is unused since 98e20e5e13d2 ("bpfilter: remove bpfilter"), therefore remove it. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Christian Brauner <brauner@kernel.org> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com> Link: https://lore.kernel.org/bpf/20250721-remove-usermode-driver-v1-2-0d0083334382@linutronix.de
2025-07-26bpf/preload: Don't select USERMODE_DRIVERThomas Weißschuh
The usermode driver framework is not used anymore by the BPF preload code. Fixes: cb80ddc67152 ("bpf: Convert bpf_preload.ko to use light skeleton.") Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/bpf/20250721-remove-usermode-driver-v1-1-0d0083334382@linutronix.de
2025-07-26Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Merge in late fixes to prepare for the 6.17 net-next PR. Conflicts: net/core/neighbour.c 1bbb76a89948 ("neighbour: Fix null-ptr-deref in neigh_flush_dev().") 13a936bb99fb ("neighbour: Protect tbl->phash_buckets[] with a dedicated mutex.") 03dc03fa0432 ("neighbor: Add NTF_EXT_VALIDATED flag for externally validated entries") Adjacent changes: drivers/net/usb/usbnet.c 0d9cfc9b8cb1 ("net: usbnet: Avoid potential RCU stall on LINK_CHANGE event") 2c04d279e857 ("net: usb: Convert tasklet API to new bottom half workqueue mechanism") net/ipv6/route.c 31d7d67ba127 ("ipv6: annotate data-races around rt->fib6_nsiblings") 1caf27297215 ("ipv6: adopt dst_dev() helper") 3b3ccf9ed05e ("net: Remove unnecessary NULL check for lwtunnel_fill_encap()") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-26Merge branch 'ipv6-f6i-fib6_siblings-and-rt-fib6_nsiblings-fixes'Jakub Kicinski
Eric Dumazet says: ==================== ipv6: f6i->fib6_siblings and rt->fib6_nsiblings fixes Series based on an internal syzbot report with a repro. After fixing (in the first patch) the original minor issue, I found that syzbot repro was able to trigger a second more serious bug in rt6_nlmsg_size(). Code review then led to the two final patches. I have not released the syzbot bug, because other issues still need investigations. ==================== Link: https://patch.msgid.link/20250725140725.3626540-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-26ipv6: annotate data-races around rt->fib6_nsiblingsEric Dumazet
rt->fib6_nsiblings can be read locklessly, add corresponding READ_ONCE() and WRITE_ONCE() annotations. Fixes: 66f5d6ce53e6 ("ipv6: replace rwlock with rcu and spinlock in fib6_table") Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20250725140725.3626540-5-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-26ipv6: fix possible infinite loop in fib6_info_uses_dev()Eric Dumazet
fib6_info_uses_dev() seems to rely on RCU without an explicit protection. Like the prior fix in rt6_nlmsg_size(), we need to make sure fib6_del_route() or fib6_add_rt2node() have not removed the anchor from the list, or we risk an infinite loop. Fixes: d9ccb18f83ea ("ipv6: Fix soft lockups in fib6_select_path under high next hop churn") Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20250725140725.3626540-4-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-26ipv6: prevent infinite loop in rt6_nlmsg_size()Eric Dumazet
While testing prior patch, I was able to trigger an infinite loop in rt6_nlmsg_size() in the following place: list_for_each_entry_rcu(sibling, &f6i->fib6_siblings, fib6_siblings) { rt6_nh_nlmsg_size(sibling->fib6_nh, &nexthop_len); } This is because fib6_del_route() and fib6_add_rt2node() uses list_del_rcu(), which can confuse rcu readers, because they might no longer see the head of the list. Restart the loop if f6i->fib6_nsiblings is zero. Fixes: d9ccb18f83ea ("ipv6: Fix soft lockups in fib6_select_path under high next hop churn") Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20250725140725.3626540-3-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-26ipv6: add a retry logic in net6_rt_notify()Eric Dumazet
inet6_rt_notify() can be called under RCU protection only. This means the route could be changed concurrently and rt6_fill_node() could return -EMSGSIZE. Re-size the skb when this happens and retry, removing one WARN_ON() that syzbot was able to trigger: WARNING: CPU: 3 PID: 6291 at net/ipv6/route.c:6342 inet6_rt_notify+0x475/0x4b0 net/ipv6/route.c:6342 Modules linked in: CPU: 3 UID: 0 PID: 6291 Comm: syz.0.77 Not tainted 6.16.0-rc7-syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:inet6_rt_notify+0x475/0x4b0 net/ipv6/route.c:6342 Code: fc ff ff e8 6d 52 ea f7 e9 47 fc ff ff 48 8b 7c 24 08 4c 89 04 24 e8 5a 52 ea f7 4c 8b 04 24 e9 94 fd ff ff e8 9c fe 84 f7 90 <0f> 0b 90 e9 bd fd ff ff e8 6e 52 ea f7 e9 bb fb ff ff 48 89 df e8 RSP: 0018:ffffc900035cf1d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffc900035cf540 RCX: ffffffff8a36e790 RDX: ffff88802f7e8000 RSI: ffffffff8a36e9d4 RDI: 0000000000000005 RBP: ffff88803c230f00 R08: 0000000000000005 R09: 00000000ffffffa6 R10: 00000000ffffffa6 R11: 0000000000000001 R12: 00000000ffffffa6 R13: 0000000000000900 R14: ffff888032ea4100 R15: 0000000000000000 FS: 00007fac7b89a6c0(0000) GS:ffff8880d6a20000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fac7b899f98 CR3: 0000000034b3f000 CR4: 0000000000352ef0 Call Trace: <TASK> ip6_route_mpath_notify+0xde/0x280 net/ipv6/route.c:5356 ip6_route_multipath_add+0x1181/0x1bd0 net/ipv6/route.c:5536 inet6_rtm_newroute+0xe4/0x1a0 net/ipv6/route.c:5647 rtnetlink_rcv_msg+0x95e/0xe90 net/core/rtnetlink.c:6944 netlink_rcv_skb+0x155/0x420 net/netlink/af_netlink.c:2552 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x58d/0x850 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 Fixes: 169fd62799e8 ("ipv6: Get rid of RTNL for SIOCADDRT and RTM_NEWROUTE.") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: syzbot <syzkaller@googlegroups.com> Link: https://patch.msgid.link/20250725140725.3626540-2-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-26vrf: Drop existing dst reference in vrf_ip6_input_dstStanislav Fomichev
Commit ff3fbcdd4724 ("selftests: tc: Add generic erspan_opts matching support for tc-flower") started triggering the following kmemleak warning: unreferenced object 0xffff888015fb0e00 (size 512): comm "softirq", pid 0, jiffies 4294679065 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 40 d2 85 9e ff ff ff ff ........@....... 41 69 59 9d ff ff ff ff 00 00 00 00 00 00 00 00 AiY............. backtrace (crc 30b71e8b): __kmalloc_noprof+0x359/0x460 metadata_dst_alloc+0x28/0x490 erspan_rcv+0x4f1/0x1160 [ip_gre] gre_rcv+0x217/0x240 [ip_gre] gre_rcv+0x1b8/0x400 [gre] ip_protocol_deliver_rcu+0x31d/0x3a0 ip_local_deliver_finish+0x37d/0x620 ip_local_deliver+0x174/0x460 ip_rcv+0x52b/0x6b0 __netif_receive_skb_one_core+0x149/0x1a0 process_backlog+0x3c8/0x1390 __napi_poll.constprop.0+0xa1/0x390 net_rx_action+0x59b/0xe00 handle_softirqs+0x22b/0x630 do_softirq+0xb1/0xf0 __local_bh_enable_ip+0x115/0x150 vrf_ip6_input_dst unconditionally sets skb dst entry, add a call to skb_dst_drop to drop any existing entry. Cc: David Ahern <dsahern@kernel.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Fixes: 9ff74384600a ("net: vrf: Handle ipv6 multicast and link-local addresses") Signed-off-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20250725160043.350725-1-sdf@fomichev.me Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-26net/sched: taprio: align entry index attr validation with mqprioSimon Horman
Both taprio and mqprio have code to validate respective entry index attributes. The validation is indented to ensure that the attribute is present, and that it's value is in range, and that each value is only used once. The purpose of this patch is to align the implementation of taprio with that of mqprio as there seems to be no good reason for them to differ. For one thing, this way, bugs will be present in both or neither. As a follow-up some consideration could be given to a common function used by both sch. No functional change intended. Except of tdc run: the results of the taprio tests # ok 81 ba39 - Add taprio Qdisc to multi-queue device (8 queues) # ok 82 9462 - Add taprio Qdisc with multiple sched-entry # ok 83 8d92 - Add taprio Qdisc with txtime-delay # ok 84 d092 - Delete taprio Qdisc with valid handle # ok 85 8471 - Show taprio class # ok 86 0a85 - Add taprio Qdisc to single-queue device # ok 87 6f62 - Add taprio Qdisc with too short interval # ok 88 831f - Add taprio Qdisc with too short cycle-time # ok 89 3e1e - Add taprio Qdisc with an invalid cycle-time # ok 90 39b4 - Reject grafting taprio as child qdisc of software taprio # ok 91 e8a1 - Reject grafting taprio as child qdisc of offloaded taprio # ok 92 a7bf - Graft cbs as child of software taprio # ok 93 6a83 - Graft cbs as child of offloaded taprio Cc: Vladimir Oltean <vladimir.oltean@nxp.com> Cc: Maher Azzouzi <maherazz04@gmail.com> Link: https://lore.kernel.org/netdev/20250723125521.GA2459@horms.kernel.org/ Signed-off-by: Simon Horman <horms@kernel.org> Reviewed-by: Cong Wang <xiyou.wangcong@gmail.com> Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Link: https://patch.msgid.link/20250725-taprio-idx-parse-v1-1-b582fffcde37@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-26net: fsl_pq_mdio: use dev_err_probeAlexander Stein
Silence deferred probes using dev_err_probe(). This can happen when the ethernet PHY uses an IRQ line attached to a i2c GPIO expander. If the i2c bus is not yet ready, a probe deferral can occur. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250725055615.259945-1-alexander.stein@ew.tq-group.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-26selftests: rtnetlink.sh: remove esp4_offload after testXiumei Mu
The esp4_offload module, loaded during IPsec offload tests, should be reset to its default settings after testing. Otherwise, leaving it enabled could unintentionally affect subsequence test cases by keeping offload active. Without this fix: $ lsmod | grep offload; ./rtnetlink.sh -t kci_test_ipsec_offload ; lsmod | grep offload; PASS: ipsec_offload esp4_offload 12288 0 esp4 32768 1 esp4_offload With this fix: $ lsmod | grep offload; ./rtnetlink.sh -t kci_test_ipsec_offload ; lsmod | grep offload; PASS: ipsec_offload Fixes: 2766a11161cc ("selftests: rtnetlink: add ipsec offload API test") Signed-off-by: Xiumei Mu <xmu@redhat.com> Reviewed-by: Shannon Nelson <sln@onemain.com> Reviewed-by: Hangbin Liu <liuhangbin@gmail.com> Link: https://patch.msgid.link/6d3a1d777c4de4eb0ca94ced9e77be8d48c5b12f.1753415428.git.xmu@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-26vsock: remove unnecessary null check in vsock_getname()Wang Liang
The local variable 'vm_addr' is always not NULL, no need to check it. Signed-off-by: Wang Liang <wangliang74@huawei.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Link: https://patch.msgid.link/20250725013808.337924-1-wangliang74@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-26Merge branch 'xsk-fix-negative-overflow-issues-in-zerocopy-xmit'Jakub Kicinski
Jason Xing says: ==================== xsk: fix negative overflow issues in zerocopy xmit Fix two negative overflow issues around {stmmac_xdp|igb}_xmit_zc(). ==================== Link: https://patch.msgid.link/20250723142327.85187-1-kerneljasonxing@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-26igb: xsk: solve negative overflow of nb_pkts in zerocopy modeJason Xing
There is no break time in the while() loop, so every time at the end of igb_xmit_zc(), negative overflow of nb_pkts will occur, which renders the return value always false. But theoretically, the result should be set after calling xsk_tx_peek_release_desc_batch(). We can take i40e_xmit_zc() as a good example. Returning false means we're not done with transmission and we need one more poll, which is exactly what igb_xmit_zc() always did before this patch. After this patch, the return value depends on the nb_pkts value. Two cases might happen then: 1. if (nb_pkts < budget), it means we process all the possible data, so return true and no more necessary poll will be triggered because of this. 2. if (nb_pkts == budget), it means we might have more data, so return false to let another poll run again. Fixes: f8e284a02afc ("igb: Add AF_XDP zero-copy Tx support") Signed-off-by: Jason Xing <kernelxing@tencent.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Link: https://patch.msgid.link/20250723142327.85187-3-kerneljasonxing@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-26stmmac: xsk: fix negative overflow of budget in zerocopy modeJason Xing
A negative overflow can happen when the budget number of descs are consumed. as long as the budget is decreased to zero, it will again go into while (budget-- > 0) statement and get decreased by one, so the overflow issue can happen. It will lead to returning true whereas the expected value should be false. In this case where all the budget is used up, it means zc function should return false to let the poll run again because normally we might have more data to process. Without this patch, zc function would return true instead. Fixes: 132c32ee5bc0 ("net: stmmac: Add TX via XDP zero-copy socket") Signed-off-by: Jason Xing <kernelxing@tencent.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Link: https://patch.msgid.link/20250723142327.85187-2-kerneljasonxing@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-26dt-bindings: ieee802154: Convert at86rf230.txt yaml formatFrank Li
Convert at86rf230.txt yaml format. Additional changes: - Add ref to spi-peripheral-props.yaml. - Add parent spi node in examples. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20250724230129.1480174-1-Frank.Li@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-26Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rmk/linuxLinus Torvalds
Pull ARM fixes from Russell King: - use an absolute path for asm/unified.h in KBUILD_AFLAGS to solve a regression caused by commit d5c8d6e0fa61 ("kbuild: Update assembler calls to use proper flags and language target") - fix dead code elimination binutils version check again * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rmk/linux: ARM: 9450/1: Fix allowing linker DCE with binutils < 2.36 ARM: 9448/1: Use an absolute path to unified.h in KBUILD_AFLAGS
2025-07-26Merge tag 'soc-fixes-6.16-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC fixes from Arnd Bergmann: "These are two fixes that came in late, one addresses a regression on a rockchips based board, the other is for ensuring a consistent dt binding for a device added in 6.16 before the incorrect one makes it into a release" * tag 'soc-fixes-6.16-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: arm64: dts: rockchip: Drop netdev led-triggers on NanoPi R5S arm64: dts: allwinner: a523: Rename emac0 to gmac0
2025-07-26Merge tag 'sunxi-fixes-for-6.16' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into soc/dt Allwinner fixes for 6.16 Only one fix: Correct the name of the A523's EMAC0 to GMAC0, as seen in the SoC's datasheets. The matching DT binding change is in the net tree. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-07-25Merge branch 'selftests-bpf-fix-a-few-dynptr-test-failures-with-64k-page-size'Martin KaFai Lau
Yonghong Song says: ==================== selftests/bpf: Fix a few dynptr test failures with 64K page size There are a few dynptr test failures with arm64 64K page size. They are fixed in this patch set and please see individual patches for details. ==================== Link: https://patch.msgid.link/20250725043425.208128-1-yonghong.song@linux.dev Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
2025-07-25selftests/bpf: Fix test dynptr/test_dynptr_memset_xdp_chunks failureYonghong Song
For arm64 64K page size, the xdp data size was set to be more than 64K in one of previous patches. This will cause failure for bpf_dynptr_memset(). Since the failure of bpf_dynptr_memset() is expected with 64K page size, return success. Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Link: https://patch.msgid.link/20250725043440.209266-1-yonghong.song@linux.dev
2025-07-25selftests/bpf: Fix test dynptr/test_dynptr_copy_xdp failureYonghong Song
For arm64 64K page size, the bpf_dynptr_copy() in test dynptr/test_dynptr_copy_xdp will succeed, but the test will failure with 4K page size. This patch made a change so the test will fail expectedly for both 4K and 64K page sizes. Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Acked-by: Mykyta Yatsenko <yatsenko@meta.com> Link: https://patch.msgid.link/20250725043435.208974-1-yonghong.song@linux.dev
2025-07-25selftests/bpf: Increase xdp data size for arm64 64K page sizeYonghong Song
With arm64 64K page size, the following 4 subtests failed: #97/25 dynptr/test_probe_read_user_dynptr:FAIL #97/26 dynptr/test_probe_read_kernel_dynptr:FAIL #97/27 dynptr/test_probe_read_user_str_dynptr:FAIL #97/28 dynptr/test_probe_read_kernel_str_dynptr:FAIL These failures are due to function bpf_dynptr_check_off_len() in include/linux/bpf.h where there is a test if (len > size || offset > size - len) return -E2BIG; With 64K page size, the 'offset' is greater than 'size - len', which caused the test failure. For 64KB page size, this patch increased the xdp buffer size from 5000 to 90000. The above 4 test failures are fixed as 'size' value is increased. But it introduced two new failures: #97/4 dynptr/test_dynptr_copy_xdp:FAIL #97/12 dynptr/test_dynptr_memset_xdp_chunks:FAIL These two failures will be addressed in subsequent patches. Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Acked-by: Mykyta Yatsenko <yatsenko@meta.com> Link: https://patch.msgid.link/20250725043430.208469-1-yonghong.song@linux.dev
2025-07-25Merge branch 'net-dsa-microchip-add-ksz8463-switch-support'Jakub Kicinski
Tristram Ha says: ==================== net: dsa: microchip: Add KSZ8463 switch support This series of patches is to add KSZ8463 switch support to the KSZ DSA driver. ==================== Link: https://patch.msgid.link/20250725001753.6330-1-Tristram.Ha@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25net: dsa: microchip: Disable PTP function of KSZ8463Tristram Ha
The PTP function of KSZ8463 is on by default. However, its proprietary way of storing timestamp directly in a reserved field inside the PTP message header is not suitable for use with the current Linux PTP stack implementation. It is necessary to disable the PTP function to not interfere the normal operation of the MAC. Note the PTP driver for KSZ switches does not work for KSZ8463 and is not activated for it. Signed-off-by: Tristram Ha <tristram.ha@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250725001753.6330-7-Tristram.Ha@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25net: dsa: microchip: Setup fiber ports for KSZ8463Tristram Ha
The fiber ports in KSZ8463 cannot be detected internally, so it requires specifying that condition in the device tree. Like the one used in Micrel PHY the port link can only be read and there is no write to the PHY. The driver programs registers to operate fiber ports correctly. Signed-off-by: Tristram Ha <tristram.ha@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250725001753.6330-6-Tristram.Ha@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25net: dsa: microchip: Write switch MAC address differently for KSZ8463Tristram Ha
KSZ8463 uses 16-bit register definitions so it writes differently for 8-bit switch MAC address. Signed-off-by: Tristram Ha <tristram.ha@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250725001753.6330-5-Tristram.Ha@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25net: dsa: microchip: Use different registers for KSZ8463Tristram Ha
KSZ8463 does not use same set of registers as KSZ8863 so it is necessary to change some registers when using KSZ8463. Signed-off-by: Tristram Ha <tristram.ha@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250725001753.6330-4-Tristram.Ha@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25net: dsa: microchip: Add KSZ8463 switch support to KSZ DSA driverTristram Ha
KSZ8463 switch is a 3-port switch based from KSZ8863. Its major difference from other KSZ SPI switches is its register access is not a simple continual 8-bit transfer with automatic address increase but uses a byte-enable mechanism specifying 8-bit, 16-bit, or 32-bit access. Its registers are also defined in 16-bit format because it shares a design with a MAC controller using 16-bit access. As a result some common register accesses need to be re-arranged. This patch adds the basic structure for using KSZ8463. It cannot use the same regmap table for other KSZ switches as it interprets the 16-bit value as little-endian and its SPI commands are different. KSZ8463 uses a byte-enable mechanism to specify 8-bit, 16-bit, and 32-bit access. The register is first shifted right by 2 then left by 4. Extra 4 bits are added. If the access is 8-bit one of the 4 bits is set. If the access is 16-bit two of the 4 bits are set. If the access is 32-bit all 4 bits are set. The SPI command for read or write is then added. Because of this register transformation separate SPI read and write functions are provided for KSZ8463. KSZ8463's internal PHYs use standard PHY register definitions so there is no need to remap things. However, the hardware has a bug that the high word and low word of the PHY id are swapped. In addition the port registers are arranged differently so KSZ8463 has its own mapping for port registers and PHY registers. Therefore the PORT_CTRL_ADDR macro is replaced with the get_port_addr helper function. Signed-off-by: Tristram Ha <tristram.ha@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250725001753.6330-3-Tristram.Ha@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25dt-bindings: net: dsa: microchip: Add KSZ8463 switch supportTristram Ha
KSZ8463 switch is a 3-port switch based from KSZ8863. Its register access is significantly different from the other KSZ SPI switches. Signed-off-by: Tristram Ha <tristram.ha@microchip.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250725001753.6330-2-Tristram.Ha@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25selftests: drv-net: Wait for bkg socat to startMohsin Bashir
Currently, UDP exchange is prone to failure when cmd attempt to send data while socat in bkg is not ready. Since, the behavior is probabilistic, this can result in flakiness for XDP tests. While testing test_xdp_native_tx_mb() on netdevsim, a failure rate of around 1% in 500 500 iterations was observed. Use wait_port_listen() to ensure that the bkg socat is started and ready to receive before cmd start sending. With proposed changes, a re-run of the same test passed 100% of time. Signed-off-by: Mohsin Bashir <mohsin.bashr@gmail.com> Link: https://patch.msgid.link/20250724235140.2645885-1-mohsin.bashr@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-25Merge branch 'arm64-dts-socfpga-enable-ethernet-support-for-agilex5'Jakub Kicinski
Matthew Gerlach says: ==================== arm64: dts: socfpga: enable ethernet support for Agilex5 This patch set enables ethernet support for the Agilex5 family of SOCFPGAs, and specifically enables gmac2 on the Agilex5 SOCFPGA Premium Development Kit. Patch 1 defines Agilex5 compatibility string in the device tree bindings. Patch 2 add the new compatibility string to dwmac-socfpga.c. ==================== Link: https://patch.msgid.link/20250724154052.205706-1-matthew.gerlach@altera.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>