CVE-2025-39703

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net, hsr: reject HSR frame if skb can&amp;#39;t hold tag<br /> <br /> Receiving HSR frame with insufficient space to hold HSR tag in the skb<br /> can result in a crash (kernel BUG):<br /> <br /> [ 45.390915] skbuff: skb_under_panic: text:ffffffff86f32cac len:26 put:14 head:ffff888042418000 data:ffff888042417ff4 tail:0xe end:0x180 dev:bridge_slave_1<br /> [ 45.392559] ------------[ cut here ]------------<br /> [ 45.392912] kernel BUG at net/core/skbuff.c:211!<br /> [ 45.393276] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI<br /> [ 45.393809] CPU: 1 UID: 0 PID: 2496 Comm: reproducer Not tainted 6.15.0 #12 PREEMPT(undef)<br /> [ 45.394433] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> [ 45.395273] RIP: 0010:skb_panic+0x15b/0x1d0<br /> <br /> <br /> <br /> [ 45.402911] Call Trace:<br /> [ 45.403105] <br /> [ 45.404470] skb_push+0xcd/0xf0<br /> [ 45.404726] br_dev_queue_push_xmit+0x7c/0x6c0<br /> [ 45.406513] br_forward_finish+0x128/0x260<br /> [ 45.408483] __br_forward+0x42d/0x590<br /> [ 45.409464] maybe_deliver+0x2eb/0x420<br /> [ 45.409763] br_flood+0x174/0x4a0<br /> [ 45.410030] br_handle_frame_finish+0xc7c/0x1bc0<br /> [ 45.411618] br_handle_frame+0xac3/0x1230<br /> [ 45.413674] __netif_receive_skb_core.constprop.0+0x808/0x3df0<br /> [ 45.422966] __netif_receive_skb_one_core+0xb4/0x1f0<br /> [ 45.424478] __netif_receive_skb+0x22/0x170<br /> [ 45.424806] process_backlog+0x242/0x6d0<br /> [ 45.425116] __napi_poll+0xbb/0x630<br /> [ 45.425394] net_rx_action+0x4d1/0xcc0<br /> [ 45.427613] handle_softirqs+0x1a4/0x580<br /> [ 45.427926] do_softirq+0x74/0x90<br /> [ 45.428196] <br /> <br /> This issue was found by syzkaller.<br /> <br /> The panic happens in br_dev_queue_push_xmit() once it receives a<br /> corrupted skb with ETH header already pushed in linear data. When it<br /> attempts the skb_push() call, there&amp;#39;s not enough headroom and<br /> skb_push() panics.<br /> <br /> The corrupted skb is put on the queue by HSR layer, which makes a<br /> sequence of unintended transformations when it receives a specific<br /> corrupted HSR frame (with incomplete TAG).<br /> <br /> Fix it by dropping and consuming frames that are not long enough to<br /> contain both ethernet and hsr headers.<br /> <br /> Alternative fix would be to check for enough headroom before skb_push()<br /> in br_dev_queue_push_xmit().<br /> <br /> In the reproducer, this is injected via AF_PACKET, but I don&amp;#39;t easily<br /> see why it couldn&amp;#39;t be sent over the wire from adjacent network.<br /> <br /> Further Details:<br /> <br /> In the reproducer, the following network interface chain is set up:<br /> <br /> ┌────────────────┐ ┌────────────────┐<br /> │ veth0_to_hsr ├───┤ hsr_slave0 ┼───┐<br /> └────────────────┘ └────────────────┘ │<br /> │ ┌──────┐<br /> ├─┤ hsr0 ├───┐<br /> │ └──────┘ │<br /> ┌────────────────┐ ┌────────────────┐ │ │┌────────┐<br /> │ veth1_to_hsr ┼───┤ hsr_slave1 ├───┘ └┤ │<br /> └────────────────┘ └────────────────┘ ┌┼ bridge │<br /> ││ │<br /> │└────────┘<br /> │<br /> ┌───────┐ │<br /> │ ... ├──────┘<br /> └───────┘<br /> <br /> To trigger the events leading up to crash, reproducer sends a corrupted<br /> HSR fr<br /> ---truncated---