bpf: Support dual-stack sockets in bpf_tcp_check_syncookie #218
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Author
|
Master branch: ccaff3d |
Author
|
Master branch: 77c9387 |
kernel-patches-bot
force-pushed
the
series/627220=>bpf
branch
from
fd1087b to
9f9919c
Compare
Author
|
Master branch: 2609f63 |
kernel-patches-bot
force-pushed
the
series/627220=>bpf
branch
from
9f9919c to
dc648e5
Compare
Author
|
Master branch: a2fb498 |
kernel-patches-bot
force-pushed
the
series/627220=>bpf
branch
from
dc648e5 to
fbe8a89
Compare
Author
|
Master branch: 0a210af |
kernel-patches-bot
force-pushed
the
series/627220=>bpf
branch
from
fbe8a89 to
771a951
Compare
Author
|
Master branch: 0a210af |
kernel-patches-bot
force-pushed
the
series/627220=>bpf
branch
from
771a951 to
bec21ca
Compare
Author
|
Master branch: 0a210af |
kernel-patches-bot
force-pushed
the
series/627220=>bpf
branch
from
bec21ca to
ead5043
Compare
Author
|
Master branch: 0a210af |
kernel-patches-bot
force-pushed
the
series/627220=>bpf
branch
from
ead5043 to
ffbcd12
Compare
Author
|
Master branch: 0a210af |
kernel-patches-bot
force-pushed
the
series/627220=>bpf
branch
from
ffbcd12 to
a8e2364
Compare
Author
|
Master branch: 0a210af |
kernel-patches-bot
force-pushed
the
series/627220=>bpf
branch
from
a8e2364 to
ac705f1
Compare
Author
|
At least one diff in series https://patchwork.kernel.org/project/netdevbpf/list/?series=627220 expired. Closing PR. |
bpf_tcp_gen_syncookie looks at the IP version in the IP header and validates the address family of the socket. It supports IPv4 packets in AF_INET6 dual-stack sockets. On the other hand, bpf_tcp_check_syncookie looks only at the address family of the socket, ignoring the real IP version in headers, and validates only the packet size. This implementation has some drawbacks: 1. Packets are not validated properly, allowing a BPF program to trick bpf_tcp_check_syncookie into handling an IPv6 packet on an IPv4 socket. 2. Dual-stack sockets fail the checks on IPv4 packets. IPv4 clients end up receiving a SYNACK with the cookie, but the following ACK gets dropped. This patch fixes these issues by changing the checks in bpf_tcp_check_syncookie to match the ones in bpf_tcp_gen_syncookie. IP version from the header is taken into account, and it is validated properly with address family. Fixes: 3990408 ("bpf: add helper to check for a valid SYN cookie") Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Acked-by: Arthur Fabre <afabre@cloudflare.com>
The previous commit fixed support for dual-stack sockets in bpf_tcp_check_syncookie. This commit adjusts the selftest to verify the fixed functionality. Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com> Acked-by: Arthur Fabre <afabre@cloudflare.com>
Author
|
Master branch: 0a210af |
kernel-patches-bot
force-pushed
the
series/627220=>bpf
branch
from
ac705f1 to
dc9dd18
Compare
Author
|
At least one diff in series https://patchwork.kernel.org/project/netdevbpf/list/?series=629579 irrelevant now. Closing PR. |
kernel-patches-daemon-bpf-rc bot
pushed a commit
that referenced
this pull request
Mar 3, 2024
Distinguish between xe_pt and the xe_pt_dir subclass when allocating and freeing. Also use a fixed-size array for the xe_pt_dir page entries to make life easier for dynamic range- checkers. Finally rename the page-directory child pointer array to "children". While no functional change, this fixes ubsan splats similar to: [ 51.463021] ------------[ cut here ]------------ [ 51.463022] UBSAN: array-index-out-of-bounds in drivers/gpu/drm/xe/xe_pt.c:47:9 [ 51.463023] index 0 is out of range for type 'xe_ptw *[*]' [ 51.463024] CPU: 5 PID: 2778 Comm: xe_vm Tainted: G U 6.8.0-rc1+ #218 [ 51.463026] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 2001 02/01/2023 [ 51.463027] Call Trace: [ 51.463028] <TASK> [ 51.463029] dump_stack_lvl+0x47/0x60 [ 51.463030] __ubsan_handle_out_of_bounds+0x95/0xd0 [ 51.463032] xe_pt_destroy+0xa5/0x150 [xe] [ 51.463088] __xe_pt_unbind_vma+0x36c/0x9b0 [xe] [ 51.463144] xe_vm_unbind+0xd8/0x580 [xe] [ 51.463204] ? drm_exec_prepare_obj+0x3f/0x60 [drm_exec] [ 51.463208] __xe_vma_op_execute+0x5da/0x910 [xe] [ 51.463268] ? __drm_gpuvm_sm_unmap+0x1cb/0x220 [drm_gpuvm] [ 51.463272] ? radix_tree_node_alloc.constprop.0+0x89/0xc0 [ 51.463275] ? drm_gpuva_it_remove+0x1f3/0x2a0 [drm_gpuvm] [ 51.463279] ? drm_gpuva_remove+0x2f/0xc0 [drm_gpuvm] [ 51.463283] xe_vm_bind_ioctl+0x1a55/0x20b0 [xe] [ 51.463344] ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe] [ 51.463414] drm_ioctl_kernel+0xb6/0x120 [ 51.463416] drm_ioctl+0x287/0x4e0 [ 51.463418] ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe] [ 51.463481] __x64_sys_ioctl+0x94/0xd0 [ 51.463484] do_syscall_64+0x86/0x170 [ 51.463486] ? syscall_exit_to_user_mode+0x7d/0x200 [ 51.463488] ? do_syscall_64+0x96/0x170 [ 51.463490] ? do_syscall_64+0x96/0x170 [ 51.463492] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 51.463494] RIP: 0033:0x7f246bfe817d [ 51.463498] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00 [ 51.463501] RSP: 002b:00007ffc1bd19ad0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 51.463502] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f246bfe817d [ 51.463504] RDX: 00007ffc1bd19b60 RSI: 0000000040886445 RDI: 0000000000000003 [ 51.463505] RBP: 00007ffc1bd19b20 R08: 0000000000000000 R09: 0000000000000000 [ 51.463506] R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffc1bd19b60 [ 51.463508] R13: 0000000040886445 R14: 0000000000000003 R15: 0000000000010000 [ 51.463510] </TASK> [ 51.463517] ---[ end trace ]--- v2 - Fix kerneldoc warning (Matthew Brost) Fixes: dd08ebf ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240209112655.4872-1-thomas.hellstrom@linux.intel.com (cherry picked from commit 157261c) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
kernel-patches-daemon-bpf-rc bot
pushed a commit
that referenced
this pull request
Oct 22, 2025
When conditional jumps are performed on the same register (e.g., r0 <= r0, r0 > r0, r0 < r0) where the register holds a scalar with range, the verifier incorrectly attempts to adjust the register's min/max bounds. This leads to invalid range bounds and triggers a BUG warning: verifier bug: REG INVARIANTS VIOLATION (true_reg1): range bounds violation u64=[0x1, 0x0] s64=[0x1, 0x0] u32=[0x1, 0x0] s32=[0x1, 0x0] var_off=(0x0, 0x0) WARNING: CPU: 0 PID: 93 at kernel/bpf/verifier.c:2731 reg_bounds_sanity_check+0x163/0x220 Modules linked in: CPU: 0 UID: 0 PID: 93 Comm: repro-x-3 Tainted: G W 6.18.0-rc1-ge7586577b75f-dirty #218 PREEMPT(full) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:reg_bounds_sanity_check+0x163/0x220 Call Trace: <TASK> reg_set_min_max.part.0+0x1b1/0x360 check_cond_jmp_op+0x1195/0x1a60 do_check_common+0x33ac/0x33c0 ... The issue occurs in reg_set_min_max() function where bounds adjustment logic is applied even when both registers being compared are the same. Comparing a register with itself should not change its bounds since the comparison result is always known (e.g., r0 == r0 is always true, r0 < r0 is always false). Fix this by adding an early return in reg_set_min_max() when false_reg1 and false_reg2 point to the same register, skipping the unnecessary bounds adjustment that leads to the verifier bug. Reported-by: Kaiyan Mei <M202472210@hust.edu.cn> Reported-by: Yinhao Hu <dddddd@hust.edu.cn> Closes: https://lore.kernel.org/all/1881f0f5.300df.199f2576a01.Coremail.kaiyanm@hust.edu.cn/ Fixes: 0df1a55 ("bpf: Warn on internal verifier errors") Signed-off-by: KaFai Wan <kafai.wan@linux.dev>
kernel-patches-daemon-bpf-rc bot
pushed a commit
that referenced
this pull request
Oct 22, 2025
When conditional jumps are performed on the same register (e.g., r0 <= r0, r0 > r0, r0 < r0) where the register holds a scalar with range, the verifier incorrectly attempts to adjust the register's min/max bounds. This leads to invalid range bounds and triggers a BUG warning: verifier bug: REG INVARIANTS VIOLATION (true_reg1): range bounds violation u64=[0x1, 0x0] s64=[0x1, 0x0] u32=[0x1, 0x0] s32=[0x1, 0x0] var_off=(0x0, 0x0) WARNING: CPU: 0 PID: 93 at kernel/bpf/verifier.c:2731 reg_bounds_sanity_check+0x163/0x220 Modules linked in: CPU: 0 UID: 0 PID: 93 Comm: repro-x-3 Tainted: G W 6.18.0-rc1-ge7586577b75f-dirty #218 PREEMPT(full) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:reg_bounds_sanity_check+0x163/0x220 Call Trace: <TASK> reg_set_min_max.part.0+0x1b1/0x360 check_cond_jmp_op+0x1195/0x1a60 do_check_common+0x33ac/0x33c0 ... The issue occurs in reg_set_min_max() function where bounds adjustment logic is applied even when both registers being compared are the same. Comparing a register with itself should not change its bounds since the comparison result is always known (e.g., r0 == r0 is always true, r0 < r0 is always false). Fix this by adding an early return in reg_set_min_max() when false_reg1 and false_reg2 point to the same register, skipping the unnecessary bounds adjustment that leads to the verifier bug. Reported-by: Kaiyan Mei <M202472210@hust.edu.cn> Reported-by: Yinhao Hu <dddddd@hust.edu.cn> Closes: https://lore.kernel.org/all/1881f0f5.300df.199f2576a01.Coremail.kaiyanm@hust.edu.cn/ Fixes: 0df1a55 ("bpf: Warn on internal verifier errors") Signed-off-by: KaFai Wan <kafai.wan@linux.dev>
kernel-patches-daemon-bpf-rc bot
pushed a commit
that referenced
this pull request
Oct 22, 2025
When conditional jumps are performed on the same register (e.g., r0 <= r0, r0 > r0, r0 < r0) where the register holds a scalar with range, the verifier incorrectly attempts to adjust the register's min/max bounds. This leads to invalid range bounds and triggers a BUG warning: verifier bug: REG INVARIANTS VIOLATION (true_reg1): range bounds violation u64=[0x1, 0x0] s64=[0x1, 0x0] u32=[0x1, 0x0] s32=[0x1, 0x0] var_off=(0x0, 0x0) WARNING: CPU: 0 PID: 93 at kernel/bpf/verifier.c:2731 reg_bounds_sanity_check+0x163/0x220 Modules linked in: CPU: 0 UID: 0 PID: 93 Comm: repro-x-3 Tainted: G W 6.18.0-rc1-ge7586577b75f-dirty #218 PREEMPT(full) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:reg_bounds_sanity_check+0x163/0x220 Call Trace: <TASK> reg_set_min_max.part.0+0x1b1/0x360 check_cond_jmp_op+0x1195/0x1a60 do_check_common+0x33ac/0x33c0 ... The issue occurs in reg_set_min_max() function where bounds adjustment logic is applied even when both registers being compared are the same. Comparing a register with itself should not change its bounds since the comparison result is always known (e.g., r0 == r0 is always true, r0 < r0 is always false). Fix this by adding an early return in reg_set_min_max() when false_reg1 and false_reg2 point to the same register, skipping the unnecessary bounds adjustment that leads to the verifier bug. Reported-by: Kaiyan Mei <M202472210@hust.edu.cn> Reported-by: Yinhao Hu <dddddd@hust.edu.cn> Closes: https://lore.kernel.org/all/1881f0f5.300df.199f2576a01.Coremail.kaiyanm@hust.edu.cn/ Fixes: 0df1a55 ("bpf: Warn on internal verifier errors") Signed-off-by: KaFai Wan <kafai.wan@linux.dev>
kernel-patches-daemon-bpf-rc bot
pushed a commit
that referenced
this pull request
Oct 23, 2025
When conditional jumps are performed on the same register (e.g., r0 <= r0, r0 > r0, r0 < r0) where the register holds a scalar with range, the verifier incorrectly attempts to adjust the register's min/max bounds. This leads to invalid range bounds and triggers a BUG warning: verifier bug: REG INVARIANTS VIOLATION (true_reg1): range bounds violation u64=[0x1, 0x0] s64=[0x1, 0x0] u32=[0x1, 0x0] s32=[0x1, 0x0] var_off=(0x0, 0x0) WARNING: CPU: 0 PID: 93 at kernel/bpf/verifier.c:2731 reg_bounds_sanity_check+0x163/0x220 Modules linked in: CPU: 0 UID: 0 PID: 93 Comm: repro-x-3 Tainted: G W 6.18.0-rc1-ge7586577b75f-dirty #218 PREEMPT(full) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:reg_bounds_sanity_check+0x163/0x220 Call Trace: <TASK> reg_set_min_max.part.0+0x1b1/0x360 check_cond_jmp_op+0x1195/0x1a60 do_check_common+0x33ac/0x33c0 ... The issue occurs in reg_set_min_max() function where bounds adjustment logic is applied even when both registers being compared are the same. Comparing a register with itself should not change its bounds since the comparison result is always known (e.g., r0 == r0 is always true, r0 < r0 is always false). Fix this by adding an early return in reg_set_min_max() when false_reg1 and false_reg2 point to the same register, skipping the unnecessary bounds adjustment that leads to the verifier bug. Reported-by: Kaiyan Mei <M202472210@hust.edu.cn> Reported-by: Yinhao Hu <dddddd@hust.edu.cn> Closes: https://lore.kernel.org/all/1881f0f5.300df.199f2576a01.Coremail.kaiyanm@hust.edu.cn/ Fixes: 0df1a55 ("bpf: Warn on internal verifier errors") Signed-off-by: KaFai Wan <kafai.wan@linux.dev>
kernel-patches-daemon-bpf-rc bot
pushed a commit
that referenced
this pull request
Oct 23, 2025
When conditional jumps are performed on the same register (e.g., r0 <= r0, r0 > r0, r0 < r0) where the register holds a scalar with range, the verifier incorrectly attempts to adjust the register's min/max bounds. This leads to invalid range bounds and triggers a BUG warning: verifier bug: REG INVARIANTS VIOLATION (true_reg1): range bounds violation u64=[0x1, 0x0] s64=[0x1, 0x0] u32=[0x1, 0x0] s32=[0x1, 0x0] var_off=(0x0, 0x0) WARNING: CPU: 0 PID: 93 at kernel/bpf/verifier.c:2731 reg_bounds_sanity_check+0x163/0x220 Modules linked in: CPU: 0 UID: 0 PID: 93 Comm: repro-x-3 Tainted: G W 6.18.0-rc1-ge7586577b75f-dirty #218 PREEMPT(full) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:reg_bounds_sanity_check+0x163/0x220 Call Trace: <TASK> reg_set_min_max.part.0+0x1b1/0x360 check_cond_jmp_op+0x1195/0x1a60 do_check_common+0x33ac/0x33c0 ... The issue occurs in reg_set_min_max() function where bounds adjustment logic is applied even when both registers being compared are the same. Comparing a register with itself should not change its bounds since the comparison result is always known (e.g., r0 == r0 is always true, r0 < r0 is always false). Fix this by adding an early return in reg_set_min_max() when false_reg1 and false_reg2 point to the same register, skipping the unnecessary bounds adjustment that leads to the verifier bug. Reported-by: Kaiyan Mei <M202472210@hust.edu.cn> Reported-by: Yinhao Hu <dddddd@hust.edu.cn> Closes: https://lore.kernel.org/all/1881f0f5.300df.199f2576a01.Coremail.kaiyanm@hust.edu.cn/ Fixes: 0df1a55 ("bpf: Warn on internal verifier errors") Signed-off-by: KaFai Wan <kafai.wan@linux.dev>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull request for series with
subject: bpf: Support dual-stack sockets in bpf_tcp_check_syncookie
version: 4
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=627220