Message-ID: <CANn89iK-Ojmi4kCZwXhFq-pG5PacLs=m71Jtw4zRpxaPEbJdhg@mail.gmail.com>
Date: Mon, 19 Jan 2026 10:30:09 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: 戸田晃太 <kota.toda@...-cybersecurity.com>
Cc: pabeni@...hat.com, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, 
	小池悠生 <yuki.koike@...-cybersecurity.com>
Subject: Re: [PATCH net] bonding: Fix header_ops type confusion

On Mon, Jan 19, 2026 at 6:36 AM 戸田晃太 <kota.toda@...-cybersecurity.com> wrote:
>
> Thanks for your quick response.
>
> The following information is based on Linux kernel version 6.12.65,
> the latest release in the 6.12 tree.
> The kernel config is identical to that of the kernelCTF instance
> (available at: https://storage.googleapis.com/kernelctf-build/releases/lts-6.12.65/.config)
>
>
> This type confusion occurs in several locations, including,
> for example, `ipgre_header` (`header_ops->create`),
> where the private data of the network device is incorrectly cast as
> `struct ip_tunnel *`.
>
> ```
> static int ipgre_header(struct sk_buff *skb, struct net_device *dev,
>       unsigned short type,
>       const void *daddr, const void *saddr, unsigned int len)
> {
>   struct ip_tunnel *t = netdev_priv(dev);
>   struct iphdr *iph;
>   struct gre_base_hdr *greh;
> ...
> ```
>
> When a bond interface is given to this function,
> it should not reference the private data as `struct ip_tunnel *`,
> because the bond interface uses the private data as `struct bonding *`.
> (quickly confirmed by seeing drivers/net/bonding/bond_netlink.c:909)
>
> ```
> struct rtnl_link_ops bond_link_ops __read_mostly = {
>     .kind            = "bond",
>     .priv_size        = sizeof(struct bonding),
> ...
> ```
>
> The stack trace below is the backtrace of all stack frame during a
> call to `ipgre_header`.
>
> ```
> ipgre_header at net/ipv4/ip_gre.c:890
> dev_hard_header at ./include/linux/netdevice.h:3156
> packet_snd at net/packet/af_packet.c:3082
> packet_sendmsg at net/packet/af_packet.c:3162
> sock_sendmsg_nosec at net/socket.c:729
> __sock_sendmsg at net/socket.c:744
> __sys_sendto at net/socket.c:2213
> __do_sys_sendto at net/socket.c:2225
> __se_sys_sendto at net/socket.c:2221
> __x64_sys_sendto at net/socket.c:2221
> do_syscall_x64 at arch/x86/entry/common.c:47
> do_syscall_64 at arch/x86/entry/common.c:78
> entry_SYSCALL_64 at arch/x86/entry/entry_64.S:121
> ```
>
> This causes memory corruption during subsequent operations.
>
> The following stack trace shows a General Protection Fault triggered
> when sending a packet
> to a bonding interface that has an IPv4 GRE interface as a slave.
>
> ```
> [    1.712329] Oops: general protection fault, probably for
> non-canonical address 0xdead0000cafebabe: 0000 [#1] SMP NOPTI
> [    1.712972] CPU: 0 UID: 1000 PID: 205 Comm: exp Not tainted 6.12.65 #1
> [    1.713344] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS Arch Linux 1.17.0-2-2 04/01/2014
> [    1.713890] RIP: 0010:skb_release_data+0x8a/0x1c0
> [    1.714162] Code: c0 00 00 00 49 03 86 c8 00 00 00 0f b6 10 f6 c2
> 01 74 48 48 8b 70 28 48 85 f6 74 3f 41 0f b6 5d 00 83 e3 10 40 f6 c6
> 01 75 24 <48> 8b 06 ba 01 00 00 00 4c 89 f7 48 8b 00 ff d0 0f 1f 00 41
> 8b6
> [    1.715276] RSP: 0018:ffffc900007cfcc0 EFLAGS: 00010246
> [    1.715583] RAX: ffff888106fe12c0 RBX: 0000000000000010 RCX: 0000000000000000
> [    1.716036] RDX: 0000000000000017 RSI: dead0000cafebabe RDI: ffff8881059c4a00
> [    1.716504] RBP: ffffc900007cfe10 R08: 0000000000000010 R09: 0000000000000000
> [    1.716955] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002
> [    1.717429] R13: ffff888106fe12c0 R14: ffff8881059c4a00 R15: ffff888106e57000
> [    1.717866] FS:  0000000038e54380(0000) GS:ffff88813bc00000(0000)
> knlGS:0000000000000000
> [    1.718350] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    1.718703] CR2: 00000000004bf480 CR3: 00000001009ec001 CR4: 0000000000772ef0
> [    1.719109] PKRU: 55555554
> [    1.719297] Call Trace:
> [    1.719461]  <TASK>
> [    1.719611]  sk_skb_reason_drop+0x58/0x120
> [    1.719891]  packet_sendmsg+0xbcb/0x18f0
> [    1.720166]  ? pcpu_alloc_area+0x186/0x260
> [    1.720421]  __sys_sendto+0x1e2/0x1f0
> [    1.720691]  __x64_sys_sendto+0x24/0x30
> [    1.720948]  do_syscall_64+0x58/0x120
> [    1.721174]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [    1.721509] RIP: 0033:0x42860d
> [    1.721713] Code: c3 ff ff ff ff 64 89 02 eb b9 0f 1f 00 f3 0f 1e
> fa 80 3d 5d 4a 09 00 00 41 89 ca 74 20 45 31 c9 45 31 c0 b8 2c 00 00
> 00 0f 05 <48> 3d 00 f0 ff ff 77 6b c3 66 2e 0f 1f 84 00 00 00 00 00 55
> 489
> [    1.722837] RSP: 002b:00007fff597e95e8 EFLAGS: 00000246 ORIG_RAX:
> 000000000000002c
> [    1.723315] RAX: ffffffffffffffda RBX: 00000000000003e8 RCX: 000000000042860d
> [    1.723721] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000310
> [    1.724103] RBP: 00007fff597e9880 R08: 0000000000000000 R09: 0000000000000000
> [    1.724565] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff597e99f8
> [    1.725010] R13: 00007fff597e9a08 R14: 00000000004b7828 R15: 0000000000000001
> [    1.725441]  </TASK>
> [    1.725594] Modules linked in:
> [    1.725790] ---[ end trace 0000000000000000 ]---
> [    1.726057] RIP: 0010:skb_release_data+0x8a/0x1c0
> [    1.726339] Code: c0 00 00 00 49 03 86 c8 00 00 00 0f b6 10 f6 c2
> 01 74 48 48 8b 70 28 48 85 f6 74 3f 41 0f b6 5d 00 83 e3 10 40 f6 c6
> 01 75 24 <48> 8b 06 ba 01 00 00 00 4c 89 f7 48 8b 00 ff d0 0f 1f 00 41
> 8b6
> [    1.727285] RSP: 0018:ffffc900007cfcc0 EFLAGS: 00010246
> [    1.727623] RAX: ffff888106fe12c0 RBX: 0000000000000010 RCX: 0000000000000000
> [    1.728052] RDX: 0000000000000017 RSI: dead0000cafebabe RDI: ffff8881059c4a00
> [    1.728467] RBP: ffffc900007cfe10 R08: 0000000000000010 R09: 0000000000000000
> [    1.728908] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002
> [    1.729323] R13: ffff888106fe12c0 R14: ffff8881059c4a00 R15: ffff888106e57000
> [    1.729744] FS:  0000000038e54380(0000) GS:ffff88813bc00000(0000)
> knlGS:0000000000000000
> [    1.730236] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    1.730597] CR2: 00000000004bf480 CR3: 00000001009ec001 CR4: 0000000000772ef0
> [    1.730988] PKRU: 55555554
> ```
>

OK thanks.

I will repeat my original feedback : I do not see any barriers in the
patch you sent.

Assuming bond_setup_by_slave() can be called multiple times during one
master lifetime, I do not think your patch is enough.

Also, please clarify what happens with stacks of two or more bonding devices ?

Powered by blists - more mailing lists