CVE-2026-64113

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ixgbevf: fix use-after-free in VEPA multicast source pruning<br /> <br /> ixgbevf_clean_rx_irq() prunes frames whose source MAC matches the VF&amp;#39;s<br /> own address (VEPA multicast workaround) by freeing the skb and<br /> continuing to the next descriptor:<br /> <br /> dev_kfree_skb_irq(skb);<br /> continue;<br /> <br /> The skb pointer is declared outside the while loop and persists across<br /> iterations. Because the continue skips the "skb = NULL" reset at the<br /> bottom of the loop, the next iteration enters the "else if (skb)" path<br /> and calls ixgbevf_add_rx_frag() on the freed skb, dereferencing<br /> skb_shinfo(skb)-&gt;nr_frags - a use-after-free in NAPI softirq context.<br /> <br /> The sibling driver iavf already handles this correctly by nulling the<br /> pointer before continuing. Apply the same pattern here.<br /> <br /> I do not have ixgbevf hardware; the bug was found by static analysis<br /> (scan_drop_continue_loops.py + semgrep drop_continue_in_loop, multi-tool<br /> corroboration with the highest score in the scan). The UAF was confirmed<br /> under KASAN by loading a test module that reproduces the exact code<br /> pattern (alloc skb, kfree_skb, then read skb_shinfo(skb)-&gt;nr_frags):<br /> <br /> BUG: KASAN: slab-use-after-free in ixgbevf_uaf_test_init+0x100/0x1000<br /> Read of size 8 at addr 000000006163ae78 by task insmod/30<br /> freed 208-byte region [000000006163adc0, 000000006163ae90)<br /> <br /> QEMU emulates igb (82576) but not ixgbe (82599), and the igbvf VF<br /> driver does not include the VEPA source pruning path, so a full<br /> end-to-end reproduction with emulated hardware was not possible.