* [PATCH net] net: clear transport header during tunnel decapsulation
@ 2026-06-24 7:32 Eric Dumazet
2026-06-24 10:41 ` Jiayuan Chen
` (3 more replies)
0 siblings, 4 replies; 6+ messages in thread
From: Eric Dumazet @ 2026-06-24 7:32 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, Ido Schimmel, David Ahern, netdev, eric.dumazet,
Eric Dumazet, syzbot+d5d0d598a4cfdfafdc3b
Syzbot triggered a DEBUG_NET_WARN_ON_ONCE(len > INT_MAX) assertion in
pskb_may_pull_reason() called from qdisc_pkt_len_segs_init().
The root cause is a stale, negative transport header offset carried over
during tunnel decapsulation. When a tunnel receiver (e.g., VXLAN or Geneve)
decapsulates a packet, it pulls the outer headers but leaves the transport
header pointing to the outer UDP header. This offset becomes negative
relative to the new skb->data (inner IP header).
If the packet bypasses GRO (e.g., an untrusted GSO packet flagged as
"unexpected GSO" by udp_unexpected_gso() due to missing tunnel GSO bits),
it is flushed directly to the stack as GRO_NORMAL. On ingress, Layer 2 Qdisc
processing (sch_handle_ingress) happens before Layer 3 IP reception
(ip_rcv_core) can run and reset the transport header. Consequently,
qdisc_pkt_len_segs_init() attempts to validate the transport header using
pskb_may_pull(skb, hdr_len + sizeof(tcphdr)). The negative hdr_len overflows
the unsigned cast in pskb_may_pull(), triggering the assertion.
Fix this by clearing the transport header to the ~0U sentinel value during
decapsulation. This ensures that:
1) The ingress Qdisc safely skips validation via !skb_transport_header_was_set()
and returns early without warning.
2) The IP layer (ip_rcv_core) later correctly resets the transport header
to the inner L4 header offset.
Introduce skb_unset_transport_header() helper and apply it in the main
decapsulation paths:
1) __iptunnel_pull_header() (covering Geneve, GRE, IPIP, SIT, etc.)
2) vxlan_rcv() (covering VXLAN)
This restores skb invariants at the decapsulation boundary without adding
overhead to the Qdisc fast path.
Fixes: 7fb4c1967011 ("net: pull headers in qdisc_pkt_len_segs_init()")
Reported-by: syzbot+d5d0d598a4cfdfafdc3b@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/6a3b853b.52ae72c2.136ac7.000c.GAE@google.com/T/#u
Signed-off-by: Eric Dumazet <edumazet@google.com>
Assisted-by: Gemini:gemini-3.1-pro
---
drivers/net/vxlan/vxlan_core.c | 1 +
include/linux/skbuff.h | 5 +++++
net/ipv4/ip_tunnel_core.c | 1 +
3 files changed, 7 insertions(+)
diff --git a/drivers/net/vxlan/vxlan_core.c b/drivers/net/vxlan/vxlan_core.c
index 67c367cc566233e809b0f70e0d939dd1c1ac0d9f..49318ad8164a2f2572fc58c0ed449b68922ae71e 100644
--- a/drivers/net/vxlan/vxlan_core.c
+++ b/drivers/net/vxlan/vxlan_core.c
@@ -1799,6 +1799,7 @@ static int vxlan_rcv(struct sock *sk, struct sk_buff *skb)
dev_dstats_rx_add(vxlan->dev, skb->len);
vxlan_vnifilter_count(vxlan, vni, vninode, VXLAN_VNI_STATS_RX, skb->len);
+ skb_unset_transport_header(skb);
gro_cells_receive(&vxlan->gro_cells, skb);
rcu_read_unlock();
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 115db8c44db21383632dd150a17c9ddcc03508e4..e8305a0fd3857ab85da4c2e8322989ed93e88d87 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -3084,6 +3084,11 @@ static inline bool skb_transport_header_was_set(const struct sk_buff *skb)
return skb->transport_header != (typeof(skb->transport_header))~0U;
}
+static inline void skb_unset_transport_header(struct sk_buff *skb)
+{
+ skb->transport_header = (typeof(skb->transport_header))~0U;
+}
+
static inline unsigned char *skb_transport_header(const struct sk_buff *skb)
{
DEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb));
diff --git a/net/ipv4/ip_tunnel_core.c b/net/ipv4/ip_tunnel_core.c
index d3c677e9bff2080e4760347a3d873da4e83ac3ca..59192f58da2e3aae19d00505cc3bb04b083b77c5 100644
--- a/net/ipv4/ip_tunnel_core.c
+++ b/net/ipv4/ip_tunnel_core.c
@@ -134,6 +134,7 @@ int __iptunnel_pull_header(struct sk_buff *skb, int hdr_len,
__vlan_hwaccel_clear_tag(skb);
skb_set_queue_mapping(skb, 0);
skb_scrub_packet(skb, xnet);
+ skb_unset_transport_header(skb);
return iptunnel_pull_offloads(skb);
}
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH net] net: clear transport header during tunnel decapsulation
2026-06-24 7:32 [PATCH net] net: clear transport header during tunnel decapsulation Eric Dumazet
@ 2026-06-24 10:41 ` Jiayuan Chen
2026-06-24 11:44 ` Eric Dumazet
2026-06-24 12:14 ` [syzbot ci] " syzbot ci
` (2 subsequent siblings)
3 siblings, 1 reply; 6+ messages in thread
From: Jiayuan Chen @ 2026-06-24 10:41 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, Ido Schimmel, David Ahern, netdev, eric.dumazet,
syzbot+d5d0d598a4cfdfafdc3b
On 6/24/26 3:32 PM, Eric Dumazet wrote:
> Syzbot triggered a DEBUG_NET_WARN_ON_ONCE(len > INT_MAX) assertion in
> pskb_may_pull_reason() called from qdisc_pkt_len_segs_init().
>
> The root cause is a stale, negative transport header offset carried over
> during tunnel decapsulation. When a tunnel receiver (e.g., VXLAN or Geneve)
> decapsulates a packet, it pulls the outer headers but leaves the transport
> header pointing to the outer UDP header. This offset becomes negative
> relative to the new skb->data (inner IP header).
>
> If the packet bypasses GRO (e.g., an untrusted GSO packet flagged as
> "unexpected GSO" by udp_unexpected_gso() due to missing tunnel GSO bits),
> it is flushed directly to the stack as GRO_NORMAL. On ingress, Layer 2 Qdisc
> processing (sch_handle_ingress) happens before Layer 3 IP reception
> (ip_rcv_core) can run and reset the transport header. Consequently,
> qdisc_pkt_len_segs_init() attempts to validate the transport header using
> pskb_may_pull(skb, hdr_len + sizeof(tcphdr)). The negative hdr_len overflows
> the unsigned cast in pskb_may_pull(), triggering the assertion.
>
> Fix this by clearing the transport header to the ~0U sentinel value during
> decapsulation. This ensures that:
> 1) The ingress Qdisc safely skips validation via !skb_transport_header_was_set()
> and returns early without warning.
> 2) The IP layer (ip_rcv_core) later correctly resets the transport header
> to the inner L4 header offset.
>
> Introduce skb_unset_transport_header() helper and apply it in the main
> decapsulation paths:
> 1) __iptunnel_pull_header() (covering Geneve, GRE, IPIP, SIT, etc.)
> 2) vxlan_rcv() (covering VXLAN)
>
> This restores skb invariants at the decapsulation boundary without adding
> overhead to the Qdisc fast path.
>
> Fixes: 7fb4c1967011 ("net: pull headers in qdisc_pkt_len_segs_init()")
> Reported-by: syzbot+d5d0d598a4cfdfafdc3b@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/netdev/6a3b853b.52ae72c2.136ac7.000c.GAE@google.com/T/#u
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Assisted-by: Gemini:gemini-3.1-pro
I think a negative skb_transport_offset() should break something else too,
so the Fixes tag looks wrong, but I couldn't find any actual breakage
(luck, or I'm missing it).
Hope sashiko read this reply and confirm it....
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH net] net: clear transport header during tunnel decapsulation
2026-06-24 10:41 ` Jiayuan Chen
@ 2026-06-24 11:44 ` Eric Dumazet
0 siblings, 0 replies; 6+ messages in thread
From: Eric Dumazet @ 2026-06-24 11:44 UTC (permalink / raw)
To: Jiayuan Chen
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
Ido Schimmel, David Ahern, netdev, eric.dumazet,
syzbot+d5d0d598a4cfdfafdc3b
On Wed, Jun 24, 2026 at 3:41 AM Jiayuan Chen <jiayuan.chen@linux.dev> wrote:
>
>
> On 6/24/26 3:32 PM, Eric Dumazet wrote:
> > Syzbot triggered a DEBUG_NET_WARN_ON_ONCE(len > INT_MAX) assertion in
> > pskb_may_pull_reason() called from qdisc_pkt_len_segs_init().
> >
> > The root cause is a stale, negative transport header offset carried over
> > during tunnel decapsulation. When a tunnel receiver (e.g., VXLAN or Geneve)
> > decapsulates a packet, it pulls the outer headers but leaves the transport
> > header pointing to the outer UDP header. This offset becomes negative
> > relative to the new skb->data (inner IP header).
> >
> > If the packet bypasses GRO (e.g., an untrusted GSO packet flagged as
> > "unexpected GSO" by udp_unexpected_gso() due to missing tunnel GSO bits),
> > it is flushed directly to the stack as GRO_NORMAL. On ingress, Layer 2 Qdisc
> > processing (sch_handle_ingress) happens before Layer 3 IP reception
> > (ip_rcv_core) can run and reset the transport header. Consequently,
> > qdisc_pkt_len_segs_init() attempts to validate the transport header using
> > pskb_may_pull(skb, hdr_len + sizeof(tcphdr)). The negative hdr_len overflows
> > the unsigned cast in pskb_may_pull(), triggering the assertion.
> >
> > Fix this by clearing the transport header to the ~0U sentinel value during
> > decapsulation. This ensures that:
> > 1) The ingress Qdisc safely skips validation via !skb_transport_header_was_set()
> > and returns early without warning.
> > 2) The IP layer (ip_rcv_core) later correctly resets the transport header
> > to the inner L4 header offset.
> >
> > Introduce skb_unset_transport_header() helper and apply it in the main
> > decapsulation paths:
> > 1) __iptunnel_pull_header() (covering Geneve, GRE, IPIP, SIT, etc.)
> > 2) vxlan_rcv() (covering VXLAN)
> >
> > This restores skb invariants at the decapsulation boundary without adding
> > overhead to the Qdisc fast path.
> >
> > Fixes: 7fb4c1967011 ("net: pull headers in qdisc_pkt_len_segs_init()")
> > Reported-by: syzbot+d5d0d598a4cfdfafdc3b@syzkaller.appspotmail.com
> > Closes: https://lore.kernel.org/netdev/6a3b853b.52ae72c2.136ac7.000c.GAE@google.com/T/#u
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > Assisted-by: Gemini:gemini-3.1-pro
>
>
> I think a negative skb_transport_offset() should break something else too,
> so the Fixes tag looks wrong, but I couldn't find any actual breakage
> (luck, or I'm missing it).
Read again the changelog: transport header is set (in ingress) a bit
later in the stack.
Nothing needs it before, but qdisc_pkt_len_segs_init() if/when it is
called in ingress.
>
> Hope sashiko read this reply and confirm it....
On older kernels (before 7fb4c1967011 ("net: pull headers in
qdisc_pkt_len_segs_init()"),
the bug is completely latent and harmless.
This prevents unnecessary backporting churn and potential merge conflicts on
very old kernels where skb_unset_transport_header() doesn't exist.
The Historical Option (a6d5bbf34efa / d342894c5d28):
If we point to the original commits that introduced the tunnels,
we are historically accurate, but we risk stable scripts trying to
backport this fix all the way back to 2012/2016
(e.g. kernel 3.7 or 4.6), which is unnecessary and highly likely to
fail to apply.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [syzbot ci] Re: net: clear transport header during tunnel decapsulation
2026-06-24 7:32 [PATCH net] net: clear transport header during tunnel decapsulation Eric Dumazet
2026-06-24 10:41 ` Jiayuan Chen
@ 2026-06-24 12:14 ` syzbot ci
2026-06-29 10:53 ` [PATCH net] " Paolo Abeni
2026-07-09 5:00 ` kernel test robot
3 siblings, 0 replies; 6+ messages in thread
From: syzbot ci @ 2026-06-24 12:14 UTC (permalink / raw)
To: davem, dsahern, edumazet, eric.dumazet, horms, idosch, kuba,
netdev, pabeni, syzbot
Cc: syzbot, syzkaller-bugs
syzbot ci has tested the following series
[v1] net: clear transport header during tunnel decapsulation
https://lore.kernel.org/all/20260624073209.3703492-1-edumazet@google.com
* [PATCH net] net: clear transport header during tunnel decapsulation
and found the following issue:
WARNING in geneve_udp_encap_recv
Full report is available here:
https://ci.syzbot.org/series/1f6dc47e-354f-4904-bc18-c2b7ea4d79b2
***
WARNING in geneve_udp_encap_recv
tree: net
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/netdev/net.git
base: d87363b0edfc7504ff2b144fe4cdd8154f90f42e
arch: amd64
compiler: Debian clang version 22.1.6 (++20260514074242+fc4aad7b5db3-1~exp1~20260514074407.73), Debian LLD 22.1.6
config: https://ci.syzbot.org/builds/7bb83c16-d55d-4d99-8c2b-6050e0022ef6/config
------------[ cut here ]------------
!skb_transport_header_was_set(skb)
WARNING: ./include/linux/skbuff.h:3094 at geneve_udp_encap_recv+0x26ed/0x4130, CPU#1: kworker/1:3/5072
Modules linked in:
CPU: 1 UID: 0 PID: 5072 Comm: kworker/1:3 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Workqueue: mld mld_ifc_work
RIP: 0010:geneve_udp_encap_recv+0x26ed/0x4130
Code: c8 00 00 00 0f b6 04 01 84 c0 0f 85 f2 18 00 00 48 8b 7c 24 78 66 44 89 6f 0a e8 7e 9b 7a 03 e9 8c 00 00 00 e8 f4 fc 33 fb 90 <0f> 0b 90 e9 2e e3 ff ff 49 83 c6 06 4c 89 f0 48 c1 e8 03 48 b9 00
RSP: 0018:ffffc90000a08620 EFLAGS: 00010246
RAX: ffffffff8691f92c RBX: ffff8881bcc8b5d0 RCX: ffff88816a7abb80
RDX: 0000000000000100 RSI: 000000000000ffff RDI: 000000000000ffff
RBP: ffffc90000a08790 R08: ffffffff903114f7 R09: 1ffffffff206229e
R10: dffffc0000000000 R11: fffffbfff206229f R12: ffff888109f6a108
R13: 1ffff110213ed5df R14: 0000000000000010 R15: dffffc0000000000
FS: 0000000000000000(0000) GS:ffff8882a927b000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f6956ea5440 CR3: 000000016f55c000 CR4: 00000000000006f0
Call Trace:
<IRQ>
udp_queue_rcv_one_skb+0xfc5/0x10e0
udp_unicast_rcv_skb+0x21a/0x3a0
udp_rcv+0xecb/0x1db0
ip_protocol_deliver_rcu+0x27e/0x440
ip_local_deliver_finish+0x3bb/0x6f0
NF_HOOK+0x336/0x3c0
NF_HOOK+0x336/0x3c0
process_backlog+0xa34/0x1860
__napi_poll+0xaa/0x330
net_rx_action+0x61d/0xf50
handle_softirqs+0x225/0x840
do_softirq+0x76/0xd0
</IRQ>
<TASK>
__local_bh_enable_ip+0xf8/0x130
__dev_queue_xmit+0x1ed7/0x37f0
ip6_output+0x337/0x540
NF_HOOK+0x177/0x4f0
mld_sendpack+0x890/0xe10
mld_ifc_work+0x839/0xe70
process_scheduled_works+0xa8e/0x14e0
worker_thread+0xa47/0xfb0
kthread+0x388/0x470
ret_from_fork+0x514/0xb70
ret_from_fork_asm+0x1a/0x30
</TASK>
***
If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
Tested-by: syzbot@syzkaller.appspotmail.com
---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.
To test a patch for this bug, please reply with `#syz test`
(should be on a separate line).
The patch should be attached to the email.
Note: arguments like custom git repos and branches are not supported.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH net] net: clear transport header during tunnel decapsulation
2026-06-24 7:32 [PATCH net] net: clear transport header during tunnel decapsulation Eric Dumazet
2026-06-24 10:41 ` Jiayuan Chen
2026-06-24 12:14 ` [syzbot ci] " syzbot ci
@ 2026-06-29 10:53 ` Paolo Abeni
2026-07-09 5:00 ` kernel test robot
3 siblings, 0 replies; 6+ messages in thread
From: Paolo Abeni @ 2026-06-29 10:53 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller, Jakub Kicinski
Cc: Simon Horman, Ido Schimmel, David Ahern, netdev, eric.dumazet,
syzbot+d5d0d598a4cfdfafdc3b
On 6/24/26 9:32 AM, Eric Dumazet wrote:
> diff --git a/net/ipv4/ip_tunnel_core.c b/net/ipv4/ip_tunnel_core.c
> index d3c677e9bff2080e4760347a3d873da4e83ac3ca..59192f58da2e3aae19d00505cc3bb04b083b77c5 100644
> --- a/net/ipv4/ip_tunnel_core.c
> +++ b/net/ipv4/ip_tunnel_core.c
> @@ -134,6 +134,7 @@ int __iptunnel_pull_header(struct sk_buff *skb, int hdr_len,
> __vlan_hwaccel_clear_tag(skb);
> skb_set_queue_mapping(skb, 0);
> skb_scrub_packet(skb, xnet);
> + skb_unset_transport_header(skb);
In geneve_udp_encap_recv() the above is called a few lines before:
geneveh = geneve_hdr(skb);
which in turn accesses indirectly the transport header via udp_hdr().
Also AFAICS even vxlan uses __iptunnel_pull_header() in the receive
path, possibly no additional unset needed in such driver.
Side note: it would be helpful if the syzbot CI reports could include
the fully decoded stack trace.
/P
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH net] net: clear transport header during tunnel decapsulation
2026-06-24 7:32 [PATCH net] net: clear transport header during tunnel decapsulation Eric Dumazet
` (2 preceding siblings ...)
2026-06-29 10:53 ` [PATCH net] " Paolo Abeni
@ 2026-07-09 5:00 ` kernel test robot
3 siblings, 0 replies; 6+ messages in thread
From: kernel test robot @ 2026-07-09 5:00 UTC (permalink / raw)
To: Eric Dumazet
Cc: oe-lkp, lkp, netdev, ltp, David S . Miller, Jakub Kicinski,
Paolo Abeni, Simon Horman, Ido Schimmel, David Ahern,
eric.dumazet, Eric Dumazet, syzbot+d5d0d598a4cfdfafdc3b,
oliver.sang
Hello,
kernel test robot noticed "KASAN:slab-use-after-free_in_vxlan_rcv[vxlan]" on:
commit: 35913c60d9c1072bf8c8d4e626bde513eeffcc45 ("[PATCH net] net: clear transport header during tunnel decapsulation")
url: https://github.com/intel-lab-lkp/linux/commits/Eric-Dumazet/net-clear-transport-header-during-tunnel-decapsulation/20260624-153313
base: https://git.kernel.org/cgit/linux/kernel/git/davem/net.git d87363b0edfc7504ff2b144fe4cdd8154f90f42e
patch link: https://lore.kernel.org/all/20260624073209.3703492-1-edumazet@google.com/
patch subject: [PATCH net] net: clear transport header during tunnel decapsulation
in testcase: ltp
version:
with following parameters:
test: net.features
config: x86_64-rhel-9.4-ltp
compiler: gcc-14
test machine: 8 threads 1 sockets Intel(R) Core(TM) i7-4790T CPU @ 2.70GHz (Haswell) with 16G memory
(please refer to attached dmesg/kmsg for entire log/backtrace)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202607091154.8fb0e88c-lkp@intel.com
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20260709/202607091154.8fb0e88c-lkp@intel.com
below decoded stack trace FYI:
kern :err : [ 836.649020] [ C2] ==================================================================
kern :err : [ 836.657473] [ C2] BUG: KASAN: slab-use-after-free in vxlan_rcv (kbuild/src/drivers/net/vxlan/vxlan_core.c:1567 kbuild/src/drivers/net/vxlan/vxlan_core.c:1745) vxlan
kern :err : [ 836.665872] [ C2] Read of size 4 at addr ffff888414b94787 by task kworker/u32:14/3114
kern :err : [ 836.677034] [ C2] CPU: 2 UID: 0 PID: 3114 Comm: kworker/u32:14 Tainted: G S 7.1.0+ #1 PREEMPT(lazy)
kern :err : [ 836.677039] [ C2] Tainted: [S]=CPU_OUT_OF_SPEC
kern :err : [ 836.677041] [ C2] Hardware name: Gigabyte Technology Co., Ltd. Z97X-UD5H/Z97X-UD5H, BIOS F9 04/21/2015
kern :err : [ 836.677043] [ C2] Workqueue: ipv6_addrconf addrconf_dad_work
kern :err : [ 836.677051] [ C2] Call Trace:
kern :err : [ 836.677053] [ C2] <IRQ>
kern :err : [ 836.677055] [ C2] dump_stack_lvl (kbuild/src/lib/dump_stack.c:94 kbuild/src/lib/dump_stack.c:120)
kern :err : [ 836.677060] [ C2] print_address_description+0x70/0x300
kern :err : [ 836.677066] [ C2] ? vxlan_rcv (kbuild/src/drivers/net/vxlan/vxlan_core.c:1567 kbuild/src/drivers/net/vxlan/vxlan_core.c:1745) vxlan
kern :err : [ 836.677074] [ C2] print_report (kbuild/src/mm/kasan/report.c:482)
kern :err : [ 836.677078] [ C2] ? __virt_addr_valid (kbuild/src/include/linux/mmzone.h:2198 (discriminator 1) kbuild/src/include/linux/mmzone.h:2280 (discriminator 1) kbuild/src/arch/x86/mm/physaddr.c:54 (discriminator 1))
kern :err : [ 836.677093] [ C2] ? vxlan_rcv (kbuild/src/drivers/net/vxlan/vxlan_core.c:1567 kbuild/src/drivers/net/vxlan/vxlan_core.c:1745) vxlan
kern :err : [ 836.677102] [ C2] kasan_report (kbuild/src/mm/kasan/report.c:595)
kern :err : [ 836.677105] [ C2] ? vxlan_rcv (kbuild/src/drivers/net/vxlan/vxlan_core.c:1567 kbuild/src/drivers/net/vxlan/vxlan_core.c:1745) vxlan
kern :err : [ 836.677115] [ C2] vxlan_rcv (kbuild/src/drivers/net/vxlan/vxlan_core.c:1567 kbuild/src/drivers/net/vxlan/vxlan_core.c:1745) vxlan
kern :err : [ 836.677146] [ C2] ? __pfx_vxlan_rcv (kbuild/src/drivers/net/vxlan/vxlan_core.c:2327) vxlan
kern :err : [ 836.677153] [ C2] ? ip6_list_rcv_finish+0x8d2/0xc30
kern :err : [ 836.677156] [ C2] ? __pfx_ip6_list_rcv_finish+0x10/0x10
kern :err : [ 836.677158] [ C2] ? ip6_parse_tlv (kbuild/src/net/ipv6/exthdrs.c:175)
kern :err : [ 836.677162] [ C2] ? __pfx_vxlan_rcv (kbuild/src/drivers/net/vxlan/vxlan_core.c:2327) vxlan
kern :err : [ 836.677169] [ C2] udp_queue_rcv_one_skb (kbuild/src/net/ipv4/udp.c:2388)
kern :err : [ 836.677174] [ C2] ? ipv6_parse_hopopts (kbuild/src/net/ipv6/exthdrs.c:1081)
kern :err : [ 836.677177] [ C2] udp_unicast_rcv_skb (kbuild/src/net/ipv4/udp.c:2574)
kern :err : [ 836.677180] [ C2] udp_rcv (kbuild/src/net/ipv4/udp.c:2640)
kern :err : [ 836.677184] [ C2] ? __pfx_udp_rcv (kbuild/src/net/ipv4/udp.c:2451 (discriminator 1))
kern :err : [ 836.677187] [ C2] ? ip_mc_validate_source (kbuild/src/include/net/ip_fib.h:460 kbuild/src/net/ipv4/route.c:1729 kbuild/src/net/ipv4/route.c:1705)
kern :err : [ 836.677193] [ C2] ip_protocol_deliver_rcu (kbuild/src/net/ipv4/ip_input.c:207 (discriminator 4))
kern :err : [ 836.677196] [ C2] ip_local_deliver_finish (kbuild/src/net/ipv4/ip_input.c:241 (discriminator 1))
kern :err : [ 836.677199] [ C2] ip_local_deliver (kbuild/src/include/linux/netfilter.h:318 kbuild/src/include/linux/netfilter.h:312 kbuild/src/net/ipv4/ip_input.c:262)
kern :err : [ 836.677201] [ C2] ? __pfx_ip_local_deliver (kbuild/src/include/linux/skbuff.h:4508 (discriminator 1))
kern :err : [ 836.677204] [ C2] ? ip_rcv_finish_core (kbuild/src/net/ipv4/ip_input.c:391)
kern :err : [ 836.677206] [ C2] ? netif_receive_skb_list_internal (kbuild/src/include/linux/rcupdate.h:873 kbuild/src/net/core/dev.c:6440)
kern :err : [ 836.677210] [ C2] ip_rcv (kbuild/src/include/net/dst.h:480 (discriminator 6) kbuild/src/net/ipv4/ip_input.c:492 (discriminator 6) kbuild/src/include/linux/netfilter.h:318 (discriminator 6) kbuild/src/include/linux/netfilter.h:312 (discriminator 6) kbuild/src/net/ipv4/ip_input.c:612 (discriminator 6))
kern :err : [ 836.677212] [ C2] ? __pfx_netif_receive_skb_list_internal (kbuild/src/net/core/dev.c:6662 (discriminator 2))
kern :err : [ 836.677215] [ C2] ? __pfx_ip_rcv (kbuild/src/include/net/dst.h:480 (discriminator 1))
kern :err : [ 836.677218] [ C2] ? __pfx_ip_rcv (kbuild/src/include/net/dst.h:480 (discriminator 1))
kern :err : [ 836.677221] [ C2] __netif_receive_skb_one_core (kbuild/src/net/core/dev.c:6206 (discriminator 4))
kern :err : [ 836.677223] [ C2] ? napi_complete_done (kbuild/src/include/linux/instrumented.h:55 kbuild/src/net/core/dev.c:6831)
kern :err : [ 836.677226] [ C2] ? __pfx___netif_receive_skb_one_core (kbuild/src/net/core/dev.c:6248)
kern :err : [ 836.677229] [ C2] ? _raw_spin_lock_irq (kbuild/src/include/linux/instrumented.h:55 kbuild/src/include/linux/atomic/atomic-instrumented.h:1301 kbuild/src/include/asm-generic/qspinlock.h:111 kbuild/src/include/linux/spinlock.h:187 kbuild/src/include/linux/spinlock_api_smp.h:143 kbuild/src/kernel/locking/spinlock.c:174)
kern :err : [ 836.677235] [ C2] process_backlog (kbuild/src/net/core/dev.c:6670)
kern :err : [ 836.677238] [ C2] __napi_poll (kbuild/src/net/core/dev.c:7729)
kern :err : [ 836.677241] [ C2] net_rx_action (kbuild/src/net/core/dev.c:7792 kbuild/src/net/core/dev.c:7949)
kern :err : [ 836.677245] [ C2] ? __pfx_net_rx_action (kbuild/src/include/net/gro.h:525)
kern :err : [ 836.677248] [ C2] ? __pfx_hrtimer_update_next_event (kbuild/src/kernel/time/hrtimer.c:195)
kern :err : [ 836.677253] [ C2] ? __pfx_sched_clock_cpu (kbuild/src/include/linux/list.h:226)
kern :err : [ 836.677257] [ C2] ? sched_clock (kbuild/src/arch/x86/kernel/tsc.c:297)
kern :err : [ 836.677261] [ C2] ? sched_clock_cpu (kbuild/src/kernel/sched/clock.c:400)
kern :err : [ 836.677265] [ C2] handle_softirqs (kbuild/src/kernel/softirq.c:622)
kern :err : [ 836.677269] [ C2] do_softirq (kbuild/src/kernel/softirq.c:523 (discriminator 20) kbuild/src/kernel/softirq.c:510 (discriminator 20))
kern :err : [ 836.677272] [ C2] </IRQ>
kern :err : [ 836.677273] [ C2] <TASK>
kern :err : [ 836.677274] [ C2] __local_bh_enable_ip (kbuild/src/kernel/softirq.c:450)
kern :err : [ 836.677276] [ C2] __dev_queue_xmit (kbuild/src/include/linux/bottom_half.h:33 kbuild/src/include/linux/rcupdate.h:914 kbuild/src/net/core/dev.c:4907)
kern :err : [ 836.677280] [ C2] ? unwind_next_frame (kbuild/src/include/linux/rcupdate.h:873 kbuild/src/include/linux/rcupdate.h:1183 kbuild/src/arch/x86/kernel/unwind_orc.c:495)
kern :err : [ 836.677284] [ C2] ? arch_stack_walk (kbuild/src/arch/x86/include/asm/unwind.h:64 kbuild/src/arch/x86/kernel/stacktrace.c:24)
kern :err : [ 836.677287] [ C2] ? kasan_save_track (kbuild/src/mm/kasan/common.c:78)
kern :err : [ 836.677293] [ C2] ? __pfx___dev_queue_xmit (kbuild/src/net/core/dev.c:4735)
kern :err : [ 836.677296] [ C2] ? __pfx__raw_spin_lock_bh (kbuild/src/kernel/locking/spinlock.c:159)
kern :err : [ 836.677299] [ C2] ? _raw_write_lock_bh (kbuild/src/include/linux/instrumented.h:55 kbuild/src/include/linux/atomic/atomic-instrumented.h:1301 kbuild/src/include/asm-generic/qrwlock.h:98 kbuild/src/include/linux/rwlock_api_smp.h:222 kbuild/src/kernel/locking/spinlock.c:338)
kern :err : [ 836.677302] [ C2] ? __asan_memcpy (kbuild/src/mm/kasan/shadow.c:106 (discriminator 1))
kern :err : [ 836.677306] [ C2] ? eth_header (kbuild/src/net/ethernet/eth.c:99 (discriminator 6))
kern :err : [ 836.677311] [ C2] ? neigh_resolve_output (kbuild/src/include/linux/netdevice.h:3493 kbuild/src/net/core/neighbour.c:1611 kbuild/src/net/core/neighbour.c:1596)
kern :err : [ 836.677316] [ C2] ip6_finish_output2 (kbuild/src/include/net/neighbour.h:560 (discriminator 2) kbuild/src/net/ipv6/ip6_output.c:136 (discriminator 2))
kern :err : [ 836.677320] [ C2] ? __pfx_ip6_finish_output2 (kbuild/src/include/net/xfrm.h:1303)
kern :err : [ 836.677324] [ C2] ? kasan_save_track (kbuild/src/mm/kasan/common.c:78)
kern :err : [ 836.677327] [ C2] ? __kasan_kmalloc (kbuild/src/mm/kasan/common.c:398 kbuild/src/mm/kasan/common.c:415)
kern :err : [ 836.677330] [ C2] ? dst_cow_metrics_generic (kbuild/src/include/linux/slab.h:969 kbuild/src/net/core/dst.c:194)
kern :err : [ 836.677333] [ C2] ? icmp6_dst_alloc (kbuild/src/include/net/dst.h:136 kbuild/src/include/net/dst.h:197 kbuild/src/net/ipv6/route.c:3359)
kern :err : [ 836.677336] [ C2] ? ndisc_send_skb (kbuild/src/net/ipv6/ndisc.c:491)
kern :err : [ 836.677339] [ C2] ? addrconf_dad_completed (kbuild/src/net/ipv6/addrconf.c:4395)
kern :err : [ 836.677342] [ C2] ? addrconf_dad_begin (kbuild/src/net/ipv6/addrconf.c:4157)
kern :err : [ 836.677345] [ C2] ? addrconf_dad_work (kbuild/src/net/ipv6/addrconf.c:4262)
kern :err : [ 836.677348] [ C2] ? process_one_work (kbuild/src/kernel/workqueue.c:3314)
kern :err : [ 836.677350] [ C2] ? worker_thread (kbuild/src/kernel/workqueue.c:3397 kbuild/src/kernel/workqueue.c:3478)
kern :err : [ 836.677352] [ C2] ? kthread (kbuild/src/kernel/kthread.c:436)
kern :err : [ 836.677356] [ C2] ? ret_from_fork (kbuild/src/arch/x86/kernel/process.c:158)
kern :err : [ 836.677358] [ C2] ? ret_from_fork_asm (kbuild/src/arch/x86/entry/entry_64.S:245)
kern :err : [ 836.677361] [ C2] ? addrconf_dad_work (kbuild/src/net/ipv6/addrconf.c:4262)
kern :err : [ 836.677364] [ C2] ? process_one_work (kbuild/src/kernel/workqueue.c:3314)
kern :err : [ 836.677366] [ C2] ? worker_thread (kbuild/src/kernel/workqueue.c:3397 kbuild/src/kernel/workqueue.c:3478)
kern :err : [ 836.677369] [ C2] ip6_finish_output (kbuild/src/net/ipv6/ip6_output.c:208 kbuild/src/net/ipv6/ip6_output.c:219)
kern :err : [ 836.677372] [ C2] ip6_output (kbuild/src/include/linux/netfilter.h:307 kbuild/src/net/ipv6/ip6_output.c:246)
kern :err : [ 836.677375] [ C2] ? __pfx_ip6_output (kbuild/src/net/ipv6/ip6_output.c:169)
kern :err : [ 836.677379] [ C2] ? _raw_spin_lock_irqsave (kbuild/src/include/linux/instrumented.h:55 kbuild/src/include/linux/atomic/atomic-instrumented.h:1301 kbuild/src/include/asm-generic/qspinlock.h:111 kbuild/src/include/linux/spinlock.h:187 kbuild/src/include/linux/spinlock_api_smp.h:133 kbuild/src/kernel/locking/spinlock.c:166)
kern :err : [ 836.677382] [ C2] ? __pfx__raw_spin_lock_irqsave (kbuild/src/kernel/locking/spinlock.c:273)
kern :err : [ 836.677385] [ C2] NF_HOOK+0xda/0x1f0
kern :err : [ 836.677388] [ C2] ? __pfx_NF_HOOK+0x10/0x10
kern :err : [ 836.677391] [ C2] ? rt6_uncached_list_add (kbuild/src/include/linux/list.h:96 kbuild/src/include/linux/list.h:158 kbuild/src/include/linux/list.h:191 kbuild/src/net/ipv6/route.c:145)
kern :err : [ 836.677394] [ C2] ndisc_send_skb (kbuild/src/net/ipv6/ndisc.c:512)
kern :err : [ 836.677396] [ C2] ? __pfx_ndisc_send_skb (kbuild/src/include/net/dst.h:470 (discriminator 1))
kern :err : [ 836.677400] [ C2] ? ndisc_send_rs (kbuild/src/net/ipv6/ndisc.c:171 (discriminator 1) kbuild/src/net/ipv6/ndisc.c:719 (discriminator 1))
kern :err : [ 836.677402] [ C2] addrconf_dad_completed (kbuild/src/net/ipv6/addrconf.c:4395)
kern :err : [ 836.677406] [ C2] ? __pfx_addrconf_dad_completed (kbuild/src/net/ipv6/addrconf.c:4091 (discriminator 10))
kern :err : [ 836.677409] [ C2] ? _raw_spin_lock (kbuild/src/include/linux/instrumented.h:55 kbuild/src/include/linux/atomic/atomic-instrumented.h:1301 kbuild/src/include/asm-generic/qspinlock.h:111 kbuild/src/include/linux/spinlock.h:187 kbuild/src/include/linux/spinlock_api_smp.h:159 kbuild/src/kernel/locking/spinlock.c:158)
kern :err : [ 836.677412] [ C2] ? __pfx__raw_spin_lock (kbuild/src/kernel/locking/spinlock.c:331)
kern :err : [ 836.677416] [ C2] ? addrconf_dad_begin (kbuild/src/net/ipv6/addrconf.c:4157)
kern :err : [ 836.677419] [ C2] addrconf_dad_begin (kbuild/src/net/ipv6/addrconf.c:4157)
kern :err : [ 836.677422] [ C2] ? __pfx_sched_balance_newidle (kbuild/src/kernel/sched/fair.c:13237 (discriminator 1))
kern :err : [ 836.677425] [ C2] ? __pfx_addrconf_dad_begin (kbuild/src/include/net/ipv6.h:459 (discriminator 2))
kern :err : [ 836.677428] [ C2] ? __pfx__raw_spin_lock_bh (kbuild/src/kernel/locking/spinlock.c:159)
kern :err : [ 836.677432] [ C2] addrconf_dad_work (kbuild/src/net/ipv6/addrconf.c:4262)
kern :err : [ 836.677435] [ C2] ? __pfx_addrconf_dad_work (kbuild/src/net/ipv6/addrconf.c:1568 (discriminator 2))
kern :err : [ 836.677438] [ C2] ? __schedule (kbuild/src/kernel/sched/core.c:5507 kbuild/src/kernel/sched/core.c:7228)
kern :err : [ 836.677443] [ C2] process_one_work (kbuild/src/kernel/workqueue.c:3314)
kern :err : [ 836.677446] [ C2] ? assign_work (kbuild/src/kernel/workqueue.c:1233)
kern :err : [ 836.677451] [ C2] worker_thread (kbuild/src/kernel/workqueue.c:3397 kbuild/src/kernel/workqueue.c:3478)
kern :err : [ 836.677454] [ C2] ? __pfx_worker_thread (kbuild/src/kernel/workqueue.c:3405 (discriminator 1))
kern :err : [ 836.677456] [ C2] kthread (kbuild/src/kernel/kthread.c:436)
kern :err : [ 836.677459] [ C2] ? recalc_sigpending (kbuild/src/include/linux/instrumented.h:97 kbuild/src/include/asm-generic/bitops/instrumented-atomic.h:41 kbuild/src/include/linux/thread_info.h:109 kbuild/src/kernel/signal.c:181)
kern :err : [ 836.677463] [ C2] ? __pfx_kthread (kbuild/src/include/linux/list.h:404 (discriminator 2))
kern :err : [ 836.677466] [ C2] ret_from_fork (kbuild/src/arch/x86/kernel/process.c:158)
kern :err : [ 836.677468] [ C2] ? __pfx_ret_from_fork (kbuild/src/arch/x86/include/asm/entry-common.h:54)
kern :err : [ 836.677470] [ C2] ? switch_fpu (kbuild/src/include/linux/instrumented.h:82 kbuild/src/include/asm-generic/bitops/instrumented-non-atomic.h:141 kbuild/src/include/linux/thread_info.h:133 kbuild/src/include/linux/sched.h:2084 kbuild/src/arch/x86/include/asm/fpu/sched.h:34)
kern :err : [ 836.677475] [ C2] ? __switch_to (kbuild/src/arch/x86/kernel/process_64.c:403 kbuild/src/arch/x86/kernel/process_64.c:663)
kern :err : [ 836.677478] [ C2] ? __switch_to_asm (kbuild/src/arch/x86/entry/entry_64.S:206)
kern :err : [ 836.677481] [ C2] ? __pfx_kthread (kbuild/src/include/linux/list.h:404 (discriminator 2))
kern :err : [ 836.677484] [ C2] ret_from_fork_asm (kbuild/src/arch/x86/entry/entry_64.S:245)
kern :err : [ 836.677488] [ C2] </TASK>
kern :err : [ 837.303842] [ C2] Allocated by task 121763:
kern :warn : [ 837.308450] [ C2] kasan_save_stack (kbuild/src/mm/kasan/common.c:57)
kern :warn : [ 837.313267] [ C2] kasan_save_track (kbuild/src/mm/kasan/common.c:78)
kern :warn : [ 837.318040] [ C2] __kasan_slab_alloc (kbuild/src/mm/kasan/common.c:340 kbuild/src/mm/kasan/common.c:366)
kern :warn : [ 837.322991] [ C2] kmem_cache_alloc_node_noprof (kbuild/src/include/linux/kasan.h:253 kbuild/src/mm/slub.c:4610 kbuild/src/mm/slub.c:4939 kbuild/src/mm/slub.c:4991)
kern :warn : [ 837.328984] [ C2] __alloc_skb (kbuild/src/net/core/skbuff.c:704 (discriminator 2))
kern :warn : [ 837.333421] [ C2] __tcp_send_ack (kbuild/src/net/ipv4/tcp_output.c:4467)
kern :warn : [ 837.338725] [ C2] tcp_rcv_established (kbuild/src/net/ipv4/tcp_input.c:6168 kbuild/src/net/ipv4/tcp_input.c:6162 kbuild/src/net/ipv4/tcp_input.c:6662)
kern :warn : [ 837.344030] [ C2] tcp_v6_do_rcv (kbuild/src/net/ipv6/tcp_ipv6.c:1625)
kern :warn : [ 837.348812] [ C2] tcp_v6_rcv (kbuild/src/net/ipv6/tcp_ipv6.c:1902)
kern :warn : [ 837.353415] [ C2] ip6_protocol_deliver_rcu (kbuild/src/net/ipv6/ip6_input.c:479 (discriminator 1))
kern :warn : [ 837.359180] [ C2] ip6_input_finish (kbuild/src/net/ipv6/ip6_input.c:534)
kern :warn : [ 837.364172] [ C2] ip6_input (kbuild/src/include/linux/netfilter.h:318 kbuild/src/include/linux/netfilter.h:312 kbuild/src/net/ipv6/ip6_input.c:545)
kern :warn : [ 837.368432] [ C2] ip6_list_rcv_finish+0x80c/0xc30
kern :warn : [ 837.374685] [ C2] ip6_sublist_rcv (kbuild/src/net/ipv6/ip6_input.c:361)
kern :warn : [ 837.379465] [ C2] ipv6_list_rcv (kbuild/src/net/ipv6/ip6_input.c:395)
kern :warn : [ 837.384188] [ C2] __netif_receive_skb_list_core (kbuild/src/net/core/dev.c:6249 (discriminator 1) kbuild/src/net/core/dev.c:6296 (discriminator 1))
kern :warn : [ 837.390302] [ C2] netif_receive_skb_list_internal (kbuild/src/net/core/dev.c:6348 kbuild/src/net/core/dev.c:6439)
kern :warn : [ 837.396561] [ C2] napi_complete_done (kbuild/src/include/net/gro.h:523 kbuild/src/include/net/gro.h:519 kbuild/src/include/net/gro.h:531 kbuild/src/net/core/dev.c:6807)
kern :warn : [ 837.401691] [ C2] gro_cell_poll (kbuild/src/net/core/gro_cells.c:74)
kern :warn : [ 837.406397] [ C2] __napi_poll (kbuild/src/net/core/dev.c:7729)
kern :warn : [ 837.410830] [ C2] net_rx_action (kbuild/src/net/core/dev.c:7792 kbuild/src/net/core/dev.c:7949)
kern :warn : [ 837.415519] [ C2] handle_softirqs (kbuild/src/kernel/softirq.c:622)
kern :warn : [ 837.420390] [ C2] do_softirq (kbuild/src/kernel/softirq.c:523 (discriminator 20) kbuild/src/kernel/softirq.c:510 (discriminator 20))
kern :warn : [ 837.424643] [ C2] __local_bh_enable_ip (kbuild/src/kernel/softirq.c:450)
kern :warn : [ 837.429767] [ C2] __dev_queue_xmit (kbuild/src/include/linux/bottom_half.h:33 kbuild/src/include/linux/rcupdate.h:914 kbuild/src/net/core/dev.c:4907)
kern :warn : [ 837.434801] [ C2] ip6_finish_output2 (kbuild/src/include/net/neighbour.h:558 kbuild/src/net/ipv6/ip6_output.c:136)
kern :warn : [ 837.440010] [ C2] ip6_finish_output (kbuild/src/net/ipv6/ip6_output.c:208 kbuild/src/net/ipv6/ip6_output.c:219)
kern :warn : [ 837.445045] [ C2] ip6_output (kbuild/src/include/linux/netfilter.h:307 kbuild/src/net/ipv6/ip6_output.c:246)
kern :warn : [ 837.449472] [ C2] ip6_xmit (kbuild/src/include/net/dst.h:470 (discriminator 3) kbuild/src/include/linux/netfilter.h:318 (discriminator 3) kbuild/src/include/linux/netfilter.h:312 (discriminator 3) kbuild/src/net/ipv6/ip6_output.c:379 (discriminator 3))
kern :warn : [ 837.453809] [ C2] inet6_csk_xmit (kbuild/src/net/ipv6/inet6_connection_sock.c:121 (discriminator 2))
kern :warn : [ 837.458578] [ C2] __tcp_transmit_skb (kbuild/src/net/ipv4/tcp_output.c:1716 (discriminator 1))
kern :warn : [ 837.463872] [ C2] tcp_write_xmit (kbuild/src/net/ipv4/tcp_output.c:1734 kbuild/src/net/ipv4/tcp_output.c:3062)
kern :warn : [ 837.468814] [ C2] __tcp_push_pending_frames (kbuild/src/net/ipv4/tcp_output.c:3245 (discriminator 1))
kern :warn : [ 837.474459] [ C2] tcp_sendmsg_locked (kbuild/src/net/ipv4/tcp.c:1414)
kern :warn : [ 837.479755] [ C2] tcp_sendmsg (kbuild/src/net/ipv4/tcp.c:1451)
kern :warn : [ 837.484124] [ C2] __sys_sendto (kbuild/src/net/socket.c:775 (discriminator 1) kbuild/src/net/socket.c:790 (discriminator 1) kbuild/src/net/socket.c:2252 (discriminator 1))
kern :warn : [ 837.488724] [ C2] __x64_sys_sendto (kbuild/src/net/socket.c:2259 kbuild/src/net/socket.c:2255 kbuild/src/net/socket.c:2255)
kern :warn : [ 837.493587] [ C2] do_syscall_64 (kbuild/src/arch/x86/entry/syscall_64.c:63 kbuild/src/arch/x86/entry/syscall_64.c:94)
kern :warn : [ 837.498221] [ C2] entry_SYSCALL_64_after_hwframe (kbuild/src/arch/x86/entry/entry_64.S:121)
kern :err : [ 837.506678] [ C2] Freed by task 121763:
kern :warn : [ 837.510939] [ C2] kasan_save_stack (kbuild/src/mm/kasan/common.c:57)
kern :warn : [ 837.515714] [ C2] kasan_save_track (kbuild/src/mm/kasan/common.c:78)
kern :warn : [ 837.520491] [ C2] kasan_save_free_info (kbuild/src/mm/kasan/generic.c:584)
kern :warn : [ 837.525618] [ C2] __kasan_slab_free (kbuild/src/mm/kasan/common.c:253 kbuild/src/mm/kasan/common.c:285)
kern :warn : [ 837.530482] [ C2] kmem_cache_free (kbuild/src/include/linux/kasan.h:235 kbuild/src/mm/slub.c:2700 kbuild/src/mm/slub.c:6310 kbuild/src/mm/slub.c:6437)
kern :warn : [ 837.535295] [ C2] tcp_rcv_established (kbuild/src/net/ipv4/tcp_input.c:6560)
kern :warn : [ 837.540686] [ C2] tcp_v6_do_rcv (kbuild/src/net/ipv6/tcp_ipv6.c:1625)
kern :warn : [ 837.545468] [ C2] __release_sock (kbuild/src/include/net/sock.h:1190 (discriminator 1) kbuild/src/net/core/sock.c:3258 (discriminator 1))
kern :warn : [ 837.550288] [ C2] release_sock (kbuild/src/net/core/sock.c:3857)
kern :warn : [ 837.554899] [ C2] tcp_sendmsg (kbuild/src/net/ipv4/tcp.c:1452)
kern :warn : [ 837.559281] [ C2] __sys_sendto (kbuild/src/net/socket.c:775 (discriminator 1) kbuild/src/net/socket.c:790 (discriminator 1) kbuild/src/net/socket.c:2252 (discriminator 1))
kern :warn : [ 837.563883] [ C2] __x64_sys_sendto (kbuild/src/net/socket.c:2259 kbuild/src/net/socket.c:2255 kbuild/src/net/socket.c:2255)
kern :warn : [ 837.568744] [ C2] do_syscall_64 (kbuild/src/arch/x86/entry/syscall_64.c:63 kbuild/src/arch/x86/entry/syscall_64.c:94)
kern :warn : [ 837.573365] [ C2] entry_SYSCALL_64_after_hwframe (kbuild/src/arch/x86/entry/entry_64.S:121)
kern :err : [ 837.581815] [ C2] The buggy address belongs to the object at ffff888414b94780
which belongs to the cache skbuff_head_cache of size 232
kern :err : [ 837.596736] [ C2] The buggy address is located 7 bytes inside of
freed 232-byte region [ffff888414b94780, ffff888414b94868)
kern :err : [ 837.613201] [ C2] The buggy address belongs to the physical page:
kern :warn : [ 837.619738] [ C2] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x414b94
kern :warn : [ 837.628704] [ C2] head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
kern :warn : [ 837.637367] [ C2] flags: 0x17ffffc0000040(head|node=0|zone=2|lastcpupid=0x1fffff)
kern :warn : [ 837.645332] [ C2] page_type: f5(slab)
kern :warn : [ 837.649452] [ C2] raw: 0017ffffc0000040 ffff8881003a2000 dead000000000100 dead000000000122
kern :warn : [ 837.658208] [ C2] raw: 0000000000000000 0000000800190019 00000000f5000000 0000000000000000
kern :warn : [ 837.666938] [ C2] head: 0017ffffc0000040 ffff8881003a2000 dead000000000100 dead000000000122
kern :warn : [ 837.675756] [ C2] head: 0000000000000000 0000000800190019 00000000f5000000 0000000000000000
kern :warn : [ 837.684572] [ C2] head: 0017ffffc0000001 ffffffffffffff81 00000000ffffffff 00000000ffffffff
kern :warn : [ 837.693424] [ C2] head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000002
kern :warn : [ 837.702280] [ C2] page dumped because: kasan: bad access detected
kern :err : [ 837.711381] [ C2] Memory state around the buggy address:
kern :err : [ 837.717212] [ C2] ffff888414b94680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
kern :err : [ 837.725465] [ C2] ffff888414b94700: fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc
kern :err : [ 837.733699] [ C2] >ffff888414b94780: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
kern :err : [ 837.741937] [ C2] ^
kern :err : [ 837.746228] [ C2] ffff888414b94800: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc
kern :err : [ 837.754492] [ C2] ffff888414b94880: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
kern :err : [ 837.762743] [ C2] ==================================================================
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-07-09 5:01 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-24 7:32 [PATCH net] net: clear transport header during tunnel decapsulation Eric Dumazet
2026-06-24 10:41 ` Jiayuan Chen
2026-06-24 11:44 ` Eric Dumazet
2026-06-24 12:14 ` [syzbot ci] " syzbot ci
2026-06-29 10:53 ` [PATCH net] " Paolo Abeni
2026-07-09 5:00 ` kernel test robot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox