- Linux-stable-mirror - lists.linaro.org

Optimiza tu reclutamiento con PsicoSmart

by Valeria Pérez

Mejora tus contrataciones con PsicoSmart body { margin: 0; padding: 0; font-family: Arial, Helvetica, sans-serif; font-size: 14px; color: #333; background-color: #ffffff; } table { border-spacing: 0; width: 100%; max-width: 600px; margin: auto; } td { padding: 12px 20px; } a { color: #1a73e8; text-decoration: none; } .footer { font-size: 12px; color: #888888; text-align: center; } Evalúa talento de forma objetiva y mejora tus contrataciones con PsicoSmart. Hola, , ¿Te ha pasado que un candidato luce perfecto en entrevista, pero en el trabajo no encaja como esperabas? En selección, confiar solo en la percepción puede llevar a decisiones costosas. Por eso quiero presentarte PsicoSmart, una herramienta creada para que los equipos de Recursos Humanos tomen decisiones más objetivas y acertadas. Con PsicoSmart puedes: Aplicar 31 pruebas psicométricas que evalúan liderazgo, honestidad, comunicación e inteligencia. Validar conocimientos técnicos con más de 2,500 exámenes especializados. Supervisar la identidad de quien responde mediante captura fotográfica automática durante la evaluación. Gestionar todo desde una sola plataforma, accesible desde cualquier dispositivo. Si estás buscando mejorar tus contrataciones, podría ser una muy buena opción. Si quieres conocer más puedes responder este correo o simplemente contactarme, mis datos están abajo. Saludos, -------------- Atte.: Valeria Pérez Ciudad de México: (55) 5018 0565 WhatsApp: +52 33 1607 2089 Si no deseas recibir más correos, haz clic aquí para darte de baja. Para remover su dirección de esta lista haga <a href="https://s1.arrobamail.com/unsuscribe.php?id=yiwtsrewiswqqtseup">click aquí</a>

3 weeks, 2 days

1
0
0 0

[PATCH 1/2] rust: kbuild: treat `build_error` and `rustdoc` as kernel objects

by Miguel Ojeda

Even if normally `build_error` isn't a kernel object, it should still be treated as such so that we pass the same flags. Similarly, `rustdoc` targets are never kernel objects, but we need to treat them as such. Otherwise, starting with Rust 1.91.0 (released 2025-10-30), `rustc` will complain about missing sanitizer flags since `-Zsanitizer` is a target modifier too [1]: error: mixing `-Zsanitizer` will cause an ABI mismatch in crate `build_error` --> rust/build_error.rs:3:1 | 3 | //! Build-time error. | ^ | = help: the `-Zsanitizer` flag modifies the ABI so Rust crates compiled with different values of this flag cannot be used together safely = note: unset `-Zsanitizer` in this crate is incompatible with `-Zsanitizer=kernel-address` in dependency `core` = help: set `-Zsanitizer=kernel-address` in this crate or unset `-Zsanitizer` in `core` = help: if you are sure this will not cause problems, you may use `-Cunsafe-allow-abi-mismatch=sanitizer` to silence this error Thus explicitly mark them as kernel objects. Cc: stable(a)vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/138736 [1] Signed-off-by: Miguel Ojeda <ojeda(a)kernel.org> --- rust/Makefile | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/rust/Makefile b/rust/Makefile index 23c7ae905bd2..5de103e20841 100644 --- a/rust/Makefile +++ b/rust/Makefile @@ -127,9 +127,14 @@ rustdoc-core: private rustc_target_flags = --edition=$(core-edition) $(core-cfgs rustdoc-core: $(RUST_LIB_SRC)/core/src/lib.rs rustdoc-clean FORCE +$(call if_changed,rustdoc) +# Even if `rustdoc` targets are not kernel objects, they should still be +# treated as such so that we pass the same flags. Otherwise, for instance, +# `rustc` will complain about missing sanitizer flags causing an ABI mismatch. +rustdoc-compiler_builtins: private is-kernel-object := y rustdoc-compiler_builtins: $(src)/compiler_builtins.rs rustdoc-core FORCE +$(call if_changed,rustdoc) +rustdoc-ffi: private is-kernel-object := y rustdoc-ffi: $(src)/ffi.rs rustdoc-core FORCE +$(call if_changed,rustdoc) @@ -147,6 +152,7 @@ rustdoc-pin_init: $(src)/pin-init/src/lib.rs rustdoc-pin_init_internal \ rustdoc-macros FORCE +$(call if_changed,rustdoc) +rustdoc-kernel: private is-kernel-object := y rustdoc-kernel: private rustc_target_flags = --extern ffi --extern pin_init \ --extern build_error --extern macros \ --extern bindings --extern uapi @@ -522,6 +528,10 @@ $(obj)/pin_init.o: $(src)/pin-init/src/lib.rs $(obj)/compiler_builtins.o \ $(obj)/$(libpin_init_internal_name) $(obj)/$(libmacros_name) FORCE +$(call if_changed_rule,rustc_library) +# Even if normally `build_error` is not a kernel object, it should still be +# treated as such so that we pass the same flags. Otherwise, for instance, +# `rustc` will complain about missing sanitizer flags causing an ABI mismatch. +$(obj)/build_error.o: private is-kernel-object := y $(obj)/build_error.o: private skip_gendwarfksyms = 1 $(obj)/build_error.o: $(src)/build_error.rs $(obj)/compiler_builtins.o FORCE +$(call if_changed_rule,rustc_library) -- 2.51.2

3 weeks, 2 days

4
6
0 0

For stable: [PATCH v2] mfd: kempld: Switch back to earlier ->init() behavior

by Michael Brunner

Mainline patch information (included in 6.18-rc): mfd: kempld: Switch back to earlier ->init() behavior Commit 309e65d151ab9be1e7b01d822880cd8c4e611dff Please consider this patch for all supported stable and longterm versions that include the faulty commit 9e36775c22c7 mentioned in the patch description. This includes all Kernel versions starting with v6.10. Newer Kontron/JUMPtec products are not listed in the kempld drivers DMI table, as they are supposed to be identified using ACPI. Without this patch there is no way to get the driver working with those boards on the affected kernel versions. Thanks in advance, Michael Brunner

3 weeks, 2 days

2
1
0 0

[PATCH] drm/amd/display: Fix NULL deref in debugfs odm_combine_segments

by Rong Zhang

When a connector is connected but inactive (e.g., disabled by desktop environments), pipe_ctx->stream_res.tg will be destroyed. Then, reading odm_combine_segments causes kernel NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 16 UID: 0 PID: 26474 Comm: cat Not tainted 6.17.0+ #2 PREEMPT(lazy) e6a17af9ee6db7c63e9d90dbe5b28ccab67520c6 Hardware name: LENOVO 21Q4/LNVNB161216, BIOS PXCN25WW 03/27/2025 RIP: 0010:odm_combine_segments_show+0x93/0xf0 [amdgpu] Code: 41 83 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 85 c9 74 2d 48 8b bc 07 f0 08 00 00 <48> 8b 07 48 8b 80 08 02 00> RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286 RAX: 0000000000005000 RBX: ffff8e35976b02d0 RCX: ffff8e3aeed052d8 RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0 R10: ffffd1bf4b953c78 R11: 0000000000000000 R12: ffffd1bf4b953d08 R13: 0000000000040000 R14: 0000000000000001 R15: 0000000000000001 FS: 00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: <TASK> seq_read_iter+0x125/0x490 ? __alloc_frozen_pages_noprof+0x18f/0x350 seq_read+0x12c/0x170 full_proxy_read+0x51/0x80 vfs_read+0xbc/0x390 ? __handle_mm_fault+0xa46/0xef0 ? do_syscall_64+0x71/0x900 ksys_read+0x73/0xf0 do_syscall_64+0x71/0x900 ? count_memcg_events+0xc2/0x190 ? handle_mm_fault+0x1d7/0x2d0 ? do_user_addr_fault+0x21a/0x690 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x6c/0x74 RIP: 0033:0x7f44d4031687 Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00> RSP: 002b:00007ffdb4b5f0b0 EFLAGS: 00000202 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 00007f44d3f9f740 RCX: 00007f44d4031687 RDX: 0000000000040000 RSI: 00007f44d3f5e000 RDI: 0000000000000003 RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007f44d3f5e000 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000040000 </TASK> Modules linked in: tls tcp_diag inet_diag xt_mark ccm snd_hrtimer snd_seq_dummy snd_seq_midi snd_seq_oss snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device x> snd_hda_codec_atihdmi snd_hda_codec_realtek_lib lenovo_wmi_helpers think_lmi snd_hda_codec_generic snd_hda_codec_hdmi snd_soc_core kvm snd_compress uvcvideo sn> platform_profile joydev amd_pmc mousedev mac_hid sch_fq_codel uinput i2c_dev parport_pc ppdev lp parport nvme_fabrics loop nfnetlink ip_tables x_tables dm_cryp> CR2: 0000000000000000 ---[ end trace 0000000000000000 ]--- RIP: 0010:odm_combine_segments_show+0x93/0xf0 [amdgpu] Code: 41 83 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 85 c9 74 2d 48 8b bc 07 f0 08 00 00 <48> 8b 07 48 8b 80 08 02 00> RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286 RAX: 0000000000005000 RBX: ffff8e35976b02d0 RCX: ffff8e3aeed052d8 RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0 R10: ffffd1bf4b953c78 R11: 0000000000000000 R12: ffffd1bf4b953d08 R13: 0000000000040000 R14: 0000000000000001 R15: 0000000000000001 FS: 00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0 PKRU: 55555554 Fix this by checking pipe_ctx->stream_res.tg before dereferencing. Fixes: 07926ba8a44f ("drm/amd/display: Add debugfs interface for ODM combine info") Cc: stable(a)vger.kernel.org Signed-off-by: Rong Zhang <i(a)rong.moe> --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c index f263e1a4537e1..00dac862b665a 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c @@ -1302,7 +1302,8 @@ static int odm_combine_segments_show(struct seq_file *m, void *unused) if (connector->status != connector_status_connected) return -ENODEV; - if (pipe_ctx != NULL && pipe_ctx->stream_res.tg->funcs->get_odm_combine_segments) + if (pipe_ctx && pipe_ctx->stream_res.tg && + pipe_ctx->stream_res.tg->funcs->get_odm_combine_segments) pipe_ctx->stream_res.tg->funcs->get_odm_combine_segments(pipe_ctx->stream_res.tg, &segments); seq_printf(m, "%d\n", segments); base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787 -- 2.51.0

3 weeks, 2 days

2
2
0 0

[PATCH] lib/crypto: curve25519-hacl64: Fix older clang KASAN workaround for GCC

by Nathan Chancellor

Commit 2f13daee2a72 ("lib/crypto/curve25519-hacl64: Disable KASAN with clang-17 and older") inadvertently disabled KASAN in curve25519-hacl64.o for GCC unconditionally because clang-min-version will always evaluate to nothing for GCC. Add a check for CONFIG_CC_IS_GCC to avoid the workaround, which is only needed for clang-17 and older. Additionally, invert the 'ifeq (...,)' into 'ifneq (...,y)', as it is a little easier to read and understand the intention ("if not GCC or at least clang-18, disable KASAN"). Cc: stable(a)vger.kernel.org Fixes: 2f13daee2a72 ("lib/crypto/curve25519-hacl64: Disable KASAN with clang-17 and older") Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> --- lib/crypto/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/crypto/Makefile b/lib/crypto/Makefile index bded351aeace..372b7a12b371 100644 --- a/lib/crypto/Makefile +++ b/lib/crypto/Makefile @@ -90,7 +90,7 @@ else libcurve25519-$(CONFIG_CRYPTO_LIB_CURVE25519_GENERIC) += curve25519-fiat32.o endif # clang versions prior to 18 may blow out the stack with KASAN -ifeq ($(call clang-min-version, 180000),) +ifneq ($(CONFIG_CC_IS_GCC)$(call clang-min-version, 180000),y) KASAN_SANITIZE_curve25519-hacl64.o := n endif --- base-commit: 6146a0f1dfae5d37442a9ddcba012add260bceb0 change-id: 20251102-curve25519-hacl64-fix-kasan-workaround-75fdb8c098fd Best regards, -- Nathan Chancellor <nathan(a)kernel.org>

3 weeks, 2 days

2
3
0 0

[PATCH AUTOSEL 6.17-5.10] net: tls: Cancel RX async resync request on rcd_delta overflow

by Sasha Levin

From: Shahar Shitrit <shshitrit(a)nvidia.com> [ Upstream commit c15d5c62ab313c19121f10e25d4fec852bd1c40c ] When a netdev issues a RX async resync request for a TLS connection, the TLS module handles it by logging record headers and attempting to match them to the tcp_sn provided by the device. If a match is found, the TLS module approves the tcp_sn for resynchronization. While waiting for a device response, the TLS module also increments rcd_delta each time a new TLS record is received, tracking the distance from the original resync request. However, if the device response is delayed or fails (e.g due to unstable connection and device getting out of tracking, hardware errors, resource exhaustion etc.), the TLS module keeps logging and incrementing, which can lead to a WARN() when rcd_delta exceeds the threshold. To address this, introduce tls_offload_rx_resync_async_request_cancel() to explicitly cancel resync requests when a device response failure is detected. Call this helper also as a final safeguard when rcd_delta crosses its threshold, as reaching this point implies that earlier cancellation did not occur. Signed-off-by: Shahar Shitrit <shshitrit(a)nvidia.com> Reviewed-by: Sabrina Dubroca <sd(a)queasysnail.net> Signed-off-by: Tariq Toukan <tariqt(a)nvidia.com> Link: https://patch.msgid.link/1761508983-937977-3-git-send-email-tariqt@nvidia.c… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: Based on my semantic analysis of the kernel repository, here is my comprehensive assessment: ## **VERDICT: YES** This commit should be backported to stable kernel trees. ## **Detailed Analysis** ### **1. Semantic Code Analysis Tools Used** I used the following semantic analysis tools to examine this commit: - **mcp__semcode__find_function**: Located `tls_device_rx_resync_async`, `tls_device_rx_resync_new_rec`, and `tls_offload_rx_resync_async_request_start` - **mcp__semcode__find_type**: Examined `struct tls_offload_resync_async` structure - **mcp__semcode__find_callers**: Traced the call graph upward from affected functions - **mcp__semcode__find_callchain**: Built complete call chain from user space to the bug location - **Git tools**: Analyzed commit history, dependencies, and related fixes ### **2. Impact Analysis Results** **Call Chain Discovery** (from user-space to bug): ``` User recvmsg() syscall → tls_sw_recvmsg (net/tls/tls_sw.c:2031) → tls_strp_read_sock (net/tls/tls_strp.c:514) → tls_rx_msg_size (net/tls/tls_sw.c:2441) → tls_device_rx_resync_new_rec (net/tls/tls_device.c:767) → tls_device_rx_resync_async (net/tls/tls_device.c:712) ← **BUG HERE** ``` **User-Space Exposure**: This is **100% user-space triggerable**. Any application receiving TLS data with hardware offload enabled can hit this code path. **Affected Hardware**: Only Mellanox/NVIDIA mlx5 NICs currently use async TLS resync (found via semantic search: `drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c`) ### **3. Bug Description** **Current behavior (without patch)**: At line net/tls/tls_device.c:726-727: ```c if (WARN_ON_ONCE(resync_async->rcd_delta == USHRT_MAX)) return false; ``` When `rcd_delta` reaches 65535 (USHRT_MAX): - WARN() fires, polluting kernel logs - Function returns false, BUT doesn't cancel the resync request - `resync_async->req` remains set (still "active") - Every subsequent TLS record continues processing in async mode - Results in continuous WARN() spam and wasted CPU cycles **Fixed behavior (with patch)**: ```c if (WARN_ON_ONCE(resync_async->rcd_delta == USHRT_MAX)) { tls_offload_rx_resync_async_request_cancel(resync_async); // ← NEW return false; } ``` The new helper properly cancels the resync by setting `atomic64_set(&resync_async->req, 0)`, preventing further async processing. ### **4. Triggering Conditions** The bug triggers in real-world scenarios: - Packet drops/reordering in the network - Device hardware errors - Device resource exhaustion - Unstable network connections - Device losing track of TLS record state After device fails to respond, the kernel continues logging every TLS record header and incrementing `rcd_delta` until overflow occurs (65,535 TLS records ≈ realistic in high-throughput scenarios). ### **5. Code Change Scope** **Minimal and contained**: - Adds 6-line helper function `tls_offload_rx_resync_async_request_cancel()` - Modifies 2 lines at overflow check (adds braces + function call) - Total: +9 lines, -1 line - Files: `include/net/tls.h`, `net/tls/tls_device.c` ### **6. Dependency Analysis** **Critical**: This commit is a **stable dependency** for commit 426e9da3b284 ("net/mlx5e: kTLS, Cancel RX async resync request in error flows"), which: - Has explicit `Fixes: 0419d8c9d8f8` tag (kTLS RX resync support from ~2019) - Uses the new `tls_offload_rx_resync_async_request_cancel()` helper - Addresses the root cause in the mlx5 driver Without this commit, the mlx5 fix cannot be applied. ### **7. Backport Status** Already being backported: - cd4ff87174242: Backport with "Stable-dep-of: 426e9da3b284" tag - 689074947f008: Another stable backport - Shows active stable tree maintenance ### **8. Stable Tree Compliance** ✅ **Fixes important bug**: Prevents kernel log spam and CPU waste ✅ **No new features**: Pure bug fix ✅ **No architectural changes**: Adds one helper function ✅ **Minimal regression risk**: Only 10 lines, affects rare code path ✅ **Confined to subsystem**: TLS offload only ✅ **Dependency for other fixes**: Required by mlx5 driver fix ✅ **Well-reviewed**: Reviewed-by Sabrina Dubroca (TLS subsystem expert) ✅ **Hardware vendor submission**: NVIDIA engineers with hardware knowledge ### **9. Risk Assessment** **Very low risk**: - Change only affects TLS hardware offload users (small subset) - Only triggers at overflow condition (previously broken anyway) - No modification to hot path - only error handling - Well-tested by NVIDIA (hardware vendor) - Already merged in mainline v6.18-rc4 - Being actively backported to other stable trees ### **Conclusion** This is a textbook example of an ideal stable backport candidate: small, focused, fixes real user-visible issues, has dependencies, low risk, and already has stable tree activity. The semantic analysis confirms user- space can trigger this bug through normal TLS operations with hardware offload enabled. include/net/tls.h | 6 ++++++ net/tls/tls_device.c | 4 +++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/include/net/tls.h b/include/net/tls.h index b90f3b675c3c4..c7bcdb3afad75 100644 --- a/include/net/tls.h +++ b/include/net/tls.h @@ -467,6 +467,12 @@ tls_offload_rx_resync_async_request_end(struct tls_offload_resync_async *resync_ atomic64_set(&resync_async->req, ((u64)ntohl(seq) << 32) | RESYNC_REQ); } +static inline void +tls_offload_rx_resync_async_request_cancel(struct tls_offload_resync_async *resync_async) +{ + atomic64_set(&resync_async->req, 0); +} + static inline void tls_offload_rx_resync_set_type(struct sock *sk, enum tls_offload_sync_type type) { diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c index a82fdcf199690..bb14d9b467f28 100644 --- a/net/tls/tls_device.c +++ b/net/tls/tls_device.c @@ -723,8 +723,10 @@ tls_device_rx_resync_async(struct tls_offload_resync_async *resync_async, /* shouldn't get to wraparound: * too long in async stage, something bad happened */ - if (WARN_ON_ONCE(resync_async->rcd_delta == USHRT_MAX)) + if (WARN_ON_ONCE(resync_async->rcd_delta == USHRT_MAX)) { + tls_offload_rx_resync_async_request_cancel(resync_async); return false; + } /* asynchronous stage: log all headers seq such that * req_seq <= seq <= end_seq, and wait for real resync request -- 2.51.0

3 weeks, 2 days

1
19
0 0

[PATCH 6.17 00/35] 6.17.7-rc1 review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.17.7 release. There are 35 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun, 02 Nov 2025 14:00:34 +0000. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.17.7-rc1… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.17.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 6.17.7-rc1 Menglong Dong <menglong8.dong(a)gmail.com> arch: Add the macro COMPILE_OFFSETS to all the asm-offsets.c Tejun Heo <tj(a)kernel.org> sched_ext: Make qmap dump operation non-destructive Filipe Manana <fdmanana(a)suse.com> btrfs: use smp_mb__after_atomic() when forcing COW in create_pending_snapshot() Qu Wenruo <wqu(a)suse.com> btrfs: tree-checker: add inode extref checks Filipe Manana <fdmanana(a)suse.com> btrfs: abort transaction if we fail to update inode in log replay dir fixup Filipe Manana <fdmanana(a)suse.com> btrfs: use level argument in log tree walk callback replay_one_buffer() Filipe Manana <fdmanana(a)suse.com> btrfs: always drop log root tree reference in btrfs_replay_log() Thorsten Blum <thorsten.blum(a)linux.dev> btrfs: scrub: replace max_t()/min_t() with clamp() in scrub_throttle_dev_io() Naohiro Aota <naohiro.aota(a)wdc.com> btrfs: zoned: refine extent allocator hint selection Johannes Thumshirn <johannes.thumshirn(a)wdc.com> btrfs: zoned: return error from btrfs_zone_finish_endio() Filipe Manana <fdmanana(a)suse.com> btrfs: abort transaction in the process_one_buffer() log tree walk callback Filipe Manana <fdmanana(a)suse.com> btrfs: abort transaction on specific error places when walking log tree Chen Ridong <chenridong(a)huawei.com> cpuset: Use new excpus for nocpu error check when enabling root partition Avadhut Naik <avadhut.naik(a)amd.com> EDAC/mc_sysfs: Increase legacy channel support to 16 David Kaplan <david.kaplan(a)amd.com> x86/bugs: Fix reporting of LFENCE retpoline Aaron Lu <ziqianlu(a)bytedance.com> sched/fair: update_cfs_group() for throttled cfs_rqs David Kaplan <david.kaplan(a)amd.com> x86/bugs: Add attack vector controls for VMSCAPE Tejun Heo <tj(a)kernel.org> sched_ext: Keep bypass on between enable failure and scx_disable_workfn() Jiri Olsa <jolsa(a)kernel.org> seccomp: passthrough uprobe systemcall without filtering Kuan-Wei Chiu <visitorckw(a)gmail.com> EDAC: Fix wrong executable file modes for C source files Josh Poimboeuf <jpoimboe(a)kernel.org> perf: Skip user unwind if the task is a kernel thread Josh Poimboeuf <jpoimboe(a)kernel.org> perf: Have get_perf_callchain() return NULL if crosstask and user are set Steven Rostedt <rostedt(a)goodmis.org> perf: Use current->flags & PF_KTHREAD|PF_USER_WORKER instead of current->mm == NULL Dapeng Mi <dapeng1.mi(a)linux.intel.com> perf/x86/intel: Add ICL_FIXED_0_ADAPTIVE bit into INTEL_FIXED_BITS_MASK Kyle Manna <kyle(a)kylemanna.com> EDAC/ie31200: Add two more Intel Alder Lake-S SoCs for EDAC support Richard Guy Briggs <rgb(a)redhat.com> audit: record fanotify event regardless of presence of rules Charles Keepax <ckeepax(a)opensource.cirrus.com> genirq/manage: Add buslock back in to enable_irq() Charles Keepax <ckeepax(a)opensource.cirrus.com> genirq/manage: Add buslock back in to __disable_irq_nosync() Charles Keepax <ckeepax(a)opensource.cirrus.com> genirq/chip: Add buslock back in to irq_set_handler() David Kaplan <david.kaplan(a)amd.com> x86/bugs: Qualify RETBLEED_INTEL_MSG David Kaplan <david.kaplan(a)amd.com> x86/bugs: Report correct retbleed mitigation status Haofeng Li <lihaofeng(a)kylinos.cn> timekeeping: Fix aux clocks sysfs initialization loop bound Tejun Heo <tj(a)kernel.org> sched_ext: Sync error_irq_work before freeing scx_sched Tejun Heo <tj(a)kernel.org> sched_ext: Put event_stats_cpu in struct scx_sched_pcpu Tejun Heo <tj(a)kernel.org> sched_ext: Move internal type and accessor definitions to ext_internal.h ------------- Diffstat: .../admin-guide/hw-vuln/attack_vector_controls.rst | 1 + Makefile | 4 +- arch/alpha/kernel/asm-offsets.c | 1 + arch/arc/kernel/asm-offsets.c | 1 + arch/arm/kernel/asm-offsets.c | 2 + arch/arm64/kernel/asm-offsets.c | 1 + arch/csky/kernel/asm-offsets.c | 1 + arch/hexagon/kernel/asm-offsets.c | 1 + arch/loongarch/kernel/asm-offsets.c | 2 + arch/m68k/kernel/asm-offsets.c | 1 + arch/microblaze/kernel/asm-offsets.c | 1 + arch/mips/kernel/asm-offsets.c | 2 + arch/nios2/kernel/asm-offsets.c | 1 + arch/openrisc/kernel/asm-offsets.c | 1 + arch/parisc/kernel/asm-offsets.c | 1 + arch/powerpc/kernel/asm-offsets.c | 1 + arch/riscv/kernel/asm-offsets.c | 1 + arch/s390/kernel/asm-offsets.c | 1 + arch/sh/kernel/asm-offsets.c | 1 + arch/sparc/kernel/asm-offsets.c | 1 + arch/um/kernel/asm-offsets.c | 2 + arch/x86/events/intel/core.c | 10 +- arch/x86/include/asm/perf_event.h | 6 +- arch/x86/kernel/cpu/bugs.c | 27 +- arch/x86/kvm/pmu.h | 2 +- arch/xtensa/kernel/asm-offsets.c | 1 + drivers/edac/ecs.c | 0 drivers/edac/edac_mc_sysfs.c | 24 + drivers/edac/ie31200_edac.c | 4 + drivers/edac/mem_repair.c | 0 drivers/edac/scrub.c | 0 fs/btrfs/disk-io.c | 2 +- fs/btrfs/extent-tree.c | 6 +- fs/btrfs/inode.c | 7 +- fs/btrfs/scrub.c | 3 +- fs/btrfs/transaction.c | 2 +- fs/btrfs/tree-checker.c | 37 + fs/btrfs/tree-log.c | 64 +- fs/btrfs/zoned.c | 8 +- fs/btrfs/zoned.h | 9 +- include/linux/audit.h | 2 +- kernel/cgroup/cpuset.c | 6 +- kernel/events/callchain.c | 16 +- kernel/events/core.c | 7 +- kernel/irq/chip.c | 2 +- kernel/irq/manage.c | 4 +- kernel/sched/build_policy.c | 1 + kernel/sched/ext.c | 1056 +------------------ kernel/sched/ext.h | 23 - kernel/sched/ext_internal.h | 1064 ++++++++++++++++++++ kernel/sched/fair.c | 3 - kernel/seccomp.c | 32 +- kernel/time/timekeeping.c | 2 +- tools/sched_ext/scx_qmap.bpf.c | 18 +- 54 files changed, 1326 insertions(+), 1150 deletions(-)

3 weeks, 2 days

17
52
0 0

[PATCH v3] fix missing sb_min_blocksize() return value checks in some filesystems

by Yongpeng Yang

From: Yongpeng Yang <yangyongpeng(a)xiaomi.com> When emulating an nvme device on qemu with both logical_block_size and physical_block_size set to 8 KiB, but without format, a kernel panic was triggered during the early boot stage while attempting to mount a vfat filesystem. [95553.682035] EXT4-fs (nvme0n1): unable to set blocksize [95553.684326] EXT4-fs (nvme0n1): unable to set blocksize [95553.686501] EXT4-fs (nvme0n1): unable to set blocksize [95553.696448] ISOFS: unsupported/invalid hardware sector size 8192 [95553.697117] ------------[ cut here ]------------ [95553.697567] kernel BUG at fs/buffer.c:1582! [95553.697984] Oops: invalid opcode: 0000 [#1] SMP NOPTI [95553.698602] CPU: 0 UID: 0 PID: 7212 Comm: mount Kdump: loaded Not tainted 6.18.0-rc2+ #38 PREEMPT(voluntary) [95553.699511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [95553.700534] RIP: 0010:folio_alloc_buffers+0x1bb/0x1c0 [95553.701018] Code: 48 8b 15 e8 93 18 02 65 48 89 35 e0 93 18 02 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b 90 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f [95553.702648] RSP: 0018:ffffd1b0c676f990 EFLAGS: 00010246 [95553.703132] RAX: ffff8cfc4176d820 RBX: 0000000000508c48 RCX: 0000000000000001 [95553.703805] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000000 [95553.704481] RBP: ffffd1b0c676f9c8 R08: 0000000000000000 R09: 0000000000000000 [95553.705148] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [95553.705816] R13: 0000000000002000 R14: fffff8bc8257e800 R15: 0000000000000000 [95553.706483] FS: 000072ee77315840(0000) GS:ffff8cfdd2c8d000(0000) knlGS:0000000000000000 [95553.707248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95553.707782] CR2: 00007d8f2a9e5a20 CR3: 0000000039d0c006 CR4: 0000000000772ef0 [95553.708439] PKRU: 55555554 [95553.708734] Call Trace: [95553.709015] <TASK> [95553.709266] __getblk_slow+0xd2/0x230 [95553.709641] ? find_get_block_common+0x8b/0x530 [95553.710084] bdev_getblk+0x77/0xa0 [95553.710449] __bread_gfp+0x22/0x140 [95553.710810] fat_fill_super+0x23a/0xfc0 [95553.711216] ? __pfx_setup+0x10/0x10 [95553.711580] ? __pfx_vfat_fill_super+0x10/0x10 [95553.712014] vfat_fill_super+0x15/0x30 [95553.712401] get_tree_bdev_flags+0x141/0x1e0 [95553.712817] get_tree_bdev+0x10/0x20 [95553.713177] vfat_get_tree+0x15/0x20 [95553.713550] vfs_get_tree+0x2a/0x100 [95553.713910] vfs_cmd_create+0x62/0xf0 [95553.714273] __do_sys_fsconfig+0x4e7/0x660 [95553.714669] __x64_sys_fsconfig+0x20/0x40 [95553.715062] x64_sys_call+0x21ee/0x26a0 [95553.715453] do_syscall_64+0x80/0x670 [95553.715816] ? __fs_parse+0x65/0x1e0 [95553.716172] ? fat_parse_param+0x103/0x4b0 [95553.716587] ? vfs_parse_fs_param_source+0x21/0xa0 [95553.717034] ? __do_sys_fsconfig+0x3d9/0x660 [95553.717548] ? __x64_sys_fsconfig+0x20/0x40 [95553.717957] ? x64_sys_call+0x21ee/0x26a0 [95553.718360] ? do_syscall_64+0xb8/0x670 [95553.718734] ? __x64_sys_fsconfig+0x20/0x40 [95553.719141] ? x64_sys_call+0x21ee/0x26a0 [95553.719545] ? do_syscall_64+0xb8/0x670 [95553.719922] ? x64_sys_call+0x1405/0x26a0 [95553.720317] ? do_syscall_64+0xb8/0x670 [95553.720702] ? __x64_sys_close+0x3e/0x90 [95553.721080] ? x64_sys_call+0x1b5e/0x26a0 [95553.721478] ? do_syscall_64+0xb8/0x670 [95553.721841] ? irqentry_exit+0x43/0x50 [95553.722211] ? exc_page_fault+0x90/0x1b0 [95553.722681] entry_SYSCALL_64_after_hwframe+0x76/0x7e [95553.723166] RIP: 0033:0x72ee774f3afe [95553.723562] Code: 73 01 c3 48 8b 0d 0a 33 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d da 32 0f 00 f7 d8 64 89 01 48 [95553.725188] RSP: 002b:00007ffe97148978 EFLAGS: 00000246 ORIG_RAX: 00000000000001af [95553.725892] RAX: ffffffffffffffda RBX: 00005dcfe53d0080 RCX: 000072ee774f3afe [95553.726526] RDX: 0000000000000000 RSI: 0000000000000006 RDI: 0000000000000003 [95553.727176] RBP: 00007ffe97148ac0 R08: 0000000000000000 R09: 000072ee775e7ac0 [95553.727818] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [95553.728459] R13: 00005dcfe53d04b0 R14: 000072ee77670b00 R15: 00005dcfe53d1a28 [95553.729086] </TASK> The panic occurs as follows: 1. logical_block_size is 8KiB, causing {struct super_block *sb}->s_blocksize is initialized to 0. vfat_fill_super - fat_fill_super - sb_min_blocksize - sb_set_blocksize //return 0 when size is 8KiB. 2. __bread_gfp is called with size == 0, causing folio_alloc_buffers() to compute an offset equal to folio_size(folio), which triggers a BUG_ON. fat_fill_super - sb_bread - __bread_gfp // size == {struct super_block *sb}->s_blocksize == 0 - bdev_getblk - __getblk_slow - grow_buffers - grow_dev_folio - folio_alloc_buffers // size == 0 - folio_set_bh //offset == folio_size(folio) and panic To fix this issue, add proper return value checks for sb_min_blocksize() in vfat, exfat, isofs, and xfs. Add the __must_check mark to sb_min_blocksize(). Cc: <stable(a)vger.kernel.org> # v6.15 Fixes: a64e5a596067bd ("bdev: add back PAGE_SIZE block size validation for sb_set_blocksize()") Signed-off-by: Yongpeng Yang <yangyongpeng(a)xiaomi.com> Reviewed-by: Matthew Wilcox <willy(a)infradead.org> Reviewed-by: Darrick J. Wong <djwong(a)kernel.org> Reviewed-by: Jan Kara <jack(a)suse.cz> Reviewed-by: OGAWA Hirofumi <hirofumi(a)mail.parknet.co.jp> --- v3: - remove the unnecessary blocksize variable definition v2: - add the __must_check mark to sb_min_blocksize() and include the Fixes tag --- block/bdev.c | 2 +- fs/exfat/super.c | 5 ++++- fs/fat/inode.c | 6 +++++- fs/isofs/inode.c | 5 +++++ fs/xfs/xfs_super.c | 5 ++++- include/linux/fs.h | 2 +- 6 files changed, 20 insertions(+), 5 deletions(-) diff --git a/block/bdev.c b/block/bdev.c index 810707cca970..638f0cd458ae 100644 --- a/block/bdev.c +++ b/block/bdev.c @@ -231,7 +231,7 @@ int sb_set_blocksize(struct super_block *sb, int size) EXPORT_SYMBOL(sb_set_blocksize); -int sb_min_blocksize(struct super_block *sb, int size) +int __must_check sb_min_blocksize(struct super_block *sb, int size) { int minsize = bdev_logical_block_size(sb->s_bdev); if (size < minsize) diff --git a/fs/exfat/super.c b/fs/exfat/super.c index 7f9592856bf7..74d451f732c7 100644 --- a/fs/exfat/super.c +++ b/fs/exfat/super.c @@ -433,7 +433,10 @@ static int exfat_read_boot_sector(struct super_block *sb) struct exfat_sb_info *sbi = EXFAT_SB(sb); /* set block size to read super block */ - sb_min_blocksize(sb, 512); + if (!sb_min_blocksize(sb, 512)) { + exfat_err(sb, "unable to set blocksize"); + return -EINVAL; + } /* read boot sector */ sbi->boot_bh = sb_bread(sb, 0); diff --git a/fs/fat/inode.c b/fs/fat/inode.c index 9648ed097816..9cfe20a3daaf 100644 --- a/fs/fat/inode.c +++ b/fs/fat/inode.c @@ -1595,8 +1595,12 @@ int fat_fill_super(struct super_block *sb, struct fs_context *fc, setup(sb); /* flavour-specific stuff that needs options */ + error = -EINVAL; + if (!sb_min_blocksize(sb, 512)) { + fat_msg(sb, KERN_ERR, "unable to set blocksize"); + goto out_fail; + } error = -EIO; - sb_min_blocksize(sb, 512); bh = sb_bread(sb, 0); if (bh == NULL) { fat_msg(sb, KERN_ERR, "unable to read boot sector"); diff --git a/fs/isofs/inode.c b/fs/isofs/inode.c index 6f0e6b19383c..ad3143d4066b 100644 --- a/fs/isofs/inode.c +++ b/fs/isofs/inode.c @@ -610,6 +610,11 @@ static int isofs_fill_super(struct super_block *s, struct fs_context *fc) goto out_freesbi; } opt->blocksize = sb_min_blocksize(s, opt->blocksize); + if (!opt->blocksize) { + printk(KERN_ERR + "ISOFS: unable to set blocksize\n"); + goto out_freesbi; + } sbi->s_high_sierra = 0; /* default is iso9660 */ sbi->s_session = opt->session; diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 1067ebb3b001..bc71aa9dcee8 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -1693,7 +1693,10 @@ xfs_fs_fill_super( if (error) return error; - sb_min_blocksize(sb, BBSIZE); + if (!sb_min_blocksize(sb, BBSIZE)) { + xfs_err(mp, "unable to set blocksize"); + return -EINVAL; + } sb->s_xattr = xfs_xattr_handlers; sb->s_export_op = &xfs_export_operations; #ifdef CONFIG_XFS_QUOTA diff --git a/include/linux/fs.h b/include/linux/fs.h index c895146c1444..26d4ca0f859a 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -3424,7 +3424,7 @@ extern void inode_sb_list_add(struct inode *inode); extern void inode_add_lru(struct inode *inode); extern int sb_set_blocksize(struct super_block *, int); -extern int sb_min_blocksize(struct super_block *, int); +extern int __must_check sb_min_blocksize(struct super_block *, int); int generic_file_mmap(struct file *, struct vm_area_struct *); int generic_file_mmap_prepare(struct vm_area_desc *desc); -- 2.43.0

3 weeks, 2 days

2
2
0 0

[PATCH 5.10/5.15] vxlan: Fix NPD when refreshing an FDB entry with a nexthop object

by Vasiliy Kovalev

From: Ido Schimmel <idosch(a)nvidia.com> commit 6ead38147ebb813f08be6ea8ef547a0e4c09559a upstream. VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled. However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2]. Fix by dropping such packets earlier. Remove the misleading comment from first_remote_rcu(). [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_snoop+0x98/0x1e0 [...] Call Trace: <TASK> vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] #!/bin/bash ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10 mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q Fixes: 1274e1cc4226 ("vxlan: ecmp support for mac fdb entries") Reported-by: Marlin Cremers <mcremers(a)cloudbear.nl> Reviewed-by: Petr Machata <petrm(a)nvidia.com> Signed-off-by: Ido Schimmel <idosch(a)nvidia.com> Reviewed-by: Nikolay Aleksandrov <razor(a)blackwall.org> Link: https://patch.msgid.link/20250901065035.159644-2-idosch@nvidia.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> [ kovalev: bp to fix CVE-2025-39851 ] Signed-off-by: Vasiliy Kovalev <kovalev(a)altlinux.org> --- drivers/net/vxlan/vxlan_core.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/net/vxlan/vxlan_core.c b/drivers/net/vxlan/vxlan_core.c index 5a7008136100..8872cb7a2dbb 100644 --- a/drivers/net/vxlan/vxlan_core.c +++ b/drivers/net/vxlan/vxlan_core.c @@ -174,9 +174,7 @@ static inline struct hlist_head *vs_head(struct net *net, __be16 port) return &vn->sock_list[hash_32(ntohs(port), PORT_HASH_BITS)]; } -/* First remote destination for a forwarding entry. - * Guaranteed to be non-NULL because remotes are never deleted. - */ +/* First remote destination for a forwarding entry. */ static inline struct vxlan_rdst *first_remote_rcu(struct vxlan_fdb *fdb) { if (rcu_access_pointer(fdb->nh)) @@ -1507,6 +1505,10 @@ static bool vxlan_snoop(struct net_device *dev, if (likely(f)) { struct vxlan_rdst *rdst = first_remote_rcu(f); + /* Don't override an fdb with nexthop with a learnt entry */ + if (rcu_access_pointer(f->nh)) + return true; + if (likely(vxlan_addr_equal(&rdst->remote_ip, src_ip) && rdst->remote_ifindex == ifindex)) return false; @@ -1515,10 +1517,6 @@ static bool vxlan_snoop(struct net_device *dev, if (f->state & (NUD_PERMANENT | NUD_NOARP)) return true; - /* Don't override an fdb with nexthop with a learnt entry */ - if (rcu_access_pointer(f->nh)) - return true; - if (net_ratelimit()) netdev_info(dev, "%pM migrated from %pIS to %pIS\n", -- 2.50.1

3 weeks, 2 days

1
0
0 0

[PATCH 6.1/6.6] vxlan: Fix NPD when refreshing an FDB entry with a nexthop object

by Vasiliy Kovalev

From: Ido Schimmel <idosch(a)nvidia.com> commit 6ead38147ebb813f08be6ea8ef547a0e4c09559a upstream. VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled. However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2]. Fix by dropping such packets earlier. Remove the misleading comment from first_remote_rcu(). [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_snoop+0x98/0x1e0 [...] Call Trace: <TASK> vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [2] #!/bin/bash ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10 mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q Fixes: 1274e1cc4226 ("vxlan: ecmp support for mac fdb entries") Reported-by: Marlin Cremers <mcremers(a)cloudbear.nl> Reviewed-by: Petr Machata <petrm(a)nvidia.com> Signed-off-by: Ido Schimmel <idosch(a)nvidia.com> Reviewed-by: Nikolay Aleksandrov <razor(a)blackwall.org> Link: https://patch.msgid.link/20250901065035.159644-2-idosch@nvidia.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> [ kovalev: bp to fix CVE-2025-39851 ] Signed-off-by: Vasiliy Kovalev <kovalev(a)altlinux.org> --- drivers/net/vxlan/vxlan_core.c | 8 ++++---- drivers/net/vxlan/vxlan_private.h | 4 +--- 2 files changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/net/vxlan/vxlan_core.c b/drivers/net/vxlan/vxlan_core.c index 57606891e413..9555887646e5 100644 --- a/drivers/net/vxlan/vxlan_core.c +++ b/drivers/net/vxlan/vxlan_core.c @@ -1460,6 +1460,10 @@ static bool vxlan_snoop(struct net_device *dev, if (likely(f)) { struct vxlan_rdst *rdst = first_remote_rcu(f); + /* Don't override an fdb with nexthop with a learnt entry */ + if (rcu_access_pointer(f->nh)) + return true; + if (likely(vxlan_addr_equal(&rdst->remote_ip, src_ip) && rdst->remote_ifindex == ifindex)) return false; @@ -1468,10 +1472,6 @@ static bool vxlan_snoop(struct net_device *dev, if (f->state & (NUD_PERMANENT | NUD_NOARP)) return true; - /* Don't override an fdb with nexthop with a learnt entry */ - if (rcu_access_pointer(f->nh)) - return true; - if (net_ratelimit()) netdev_info(dev, "%pM migrated from %pIS to %pIS\n", diff --git a/drivers/net/vxlan/vxlan_private.h b/drivers/net/vxlan/vxlan_private.h index 85b6d0c347e3..8444b5d1ca60 100644 --- a/drivers/net/vxlan/vxlan_private.h +++ b/drivers/net/vxlan/vxlan_private.h @@ -56,9 +56,7 @@ static inline struct hlist_head *vs_head(struct net *net, __be16 port) return &vn->sock_list[hash_32(ntohs(port), PORT_HASH_BITS)]; } -/* First remote destination for a forwarding entry. - * Guaranteed to be non-NULL because remotes are never deleted. - */ +/* First remote destination for a forwarding entry. */ static inline struct vxlan_rdst *first_remote_rcu(struct vxlan_fdb *fdb) { if (rcu_access_pointer(fdb->nh)) -- 2.50.1

3 weeks, 2 days

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror