netdev - Re: [PATCH] net, hsr: reject HSR frame if skb can't hold tag

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANn89i+pRcoUO5_VeS9evwPJrNaa=8H2=p7=Fo3oJCENV0019g@mail.gmail.com>
Date: Wed, 20 Aug 2025 11:21:39 -0700
From: Eric Dumazet <edumazet@...gle.com>
To: Jakub Acs <acsjakub@...zon.de>
Cc: netdev@...r.kernel.org, aws-security@...zon.com, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, security@...nel.org, 
	stable@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net, hsr: reject HSR frame if skb can't hold tag

On Tue, Aug 19, 2025 at 1:28 AM Jakub Acs <acsjakub@...zon.de> wrote:
>
> Receiving HSR frame with insufficient space to hold HSR tag in the skb
> can result in a crash (kernel BUG):
>
> [   45.390915] skbuff: skb_under_panic: text:ffffffff86f32cac len:26 put:14 head:ffff888042418000 data:ffff888042417ff4 tail:0xe end:0x180 dev:bridge_slave_1
> [   45.392559] ------------[ cut here ]------------
> [   45.392912] kernel BUG at net/core/skbuff.c:211!
> [   45.393276] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI
> [   45.393809] CPU: 1 UID: 0 PID: 2496 Comm: reproducer Not tainted 6.15.0 #12 PREEMPT(undef)
> [   45.394433] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
> [   45.395273] RIP: 0010:skb_panic+0x15b/0x1d0
>
> <snip registers, remove unreliable trace>
>
>
> This issue was found by syzkaller.
>
> The panic happens in br_dev_queue_push_xmit() once it receives a
> corrupted skb with ETH header already pushed in linear data. When it
> attempts the skb_push() call, there's not enough headroom and
> skb_push() panics.
>
> The corrupted skb is put on the queue by HSR layer, which makes a
> sequence of unintended transformations when it receives a specific
> corrupted HSR frame (with incomplete TAG).
>
> Fix it by dropping and consuming frames that are not long enough to
> contain both ethernet and hsr headers.
>
> Alternative fix would be to check for enough headroom before skb_push()
> in br_dev_queue_push_xmit().
>
> In the reproducer, this is injected via AF_PACKET, but I don't easily
> see why it couldn't be sent over the wire from adjacent network.
>
> Further Details:
>
> In the reproducer, the following network interface chain is set up:
>
> ┌────────────────┐   ┌────────────────┐
> │ veth0_to_hsr   ├───┤  hsr_slave0    ┼───┐
> └────────────────┘   └────────────────┘   │
>                                           │ ┌──────┐
>                                           ├─┤ hsr0 ├───┐
>                                           │ └──────┘   │
> ┌────────────────┐   ┌────────────────┐   │            │┌────────┐
> │ veth1_to_hsr   ┼───┤  hsr_slave1    ├───┘            └┤        │
> └────────────────┘   └────────────────┘                ┌┼ bridge │
>                                                        ││        │
>                                                        │└────────┘
>                                                        │
>                                         ┌───────┐      │
>                                         │  ...  ├──────┘
>                                         └───────┘
>
> To trigger the events leading up to crash, reproducer sends a corrupted
> HSR frame with incomplete TAG, via AF_PACKET socket on 'veth0_to_hsr'.
>

> Signed-off-by: Jakub Acs <acsjakub@...zon.de>
> Cc: Eric Dumazet <edumazet@...gle.com>
> Cc: Jakub Kicinski <kuba@...nel.org>
> Cc: Paolo Abeni <pabeni@...hat.com>
> Cc: security@...nel.org
> Cc: stable@...nel.org
> Cc: netdev@...r.kernel.org
> Cc: linux-kernel@...r.kernel.org
> ---

Reviewed-by: Eric Dumazet <edumazet@...gle.com>