| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAA3_GnpijQeBNVOqy6QtUMDjhy_ku_b54uf30zfEq=etMTqKrA@mail.gmail.com>
Date: Mon, 19 Jan 2026 14:36:04 +0900
From: 戸田晃太 <kota.toda@...-cybersecurity.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: pabeni@...hat.com, netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
小池悠生 <yuki.koike@...-cybersecurity.com>,
戸田晃太 <kota.toda@...-cybersecurity.com>
Subject: Re: [PATCH net] bonding: Fix header_ops type confusion
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
```
2026年1月15日(木) 20:07 Eric Dumazet <edumazet@...gle.com>:
>
> On Thu, Jan 15, 2026 at 11:33 AM 戸田晃太 <kota.toda@...-cybersecurity.com> wrote:
> >
> > Hello, Eric and other maintainers,
> >
> > I hope you’re doing well. I’m following up on our email, sent during
> > the holiday season, in case it got buried.
> >
> > When you have a moment, could you please let us know if you had a
> > chance to review it?
> >
> > Thank you in advance, and I look forward to your response.
> >
>
> I think it would be nice to provide an actual stack trace of the bug,
> on a recent kernel tree.
>
> We had recent patches dealing with dev->hard_header_len changes.
Powered by blists - more mailing lists