In the Linux kernel, the following vulnerability has been resolved: net: lan743x: fix RX checksum…

Why it is Amber

• CVSS 8.1 high
• Remotely exploitable without logging in
• On your watchlist: linux kernel

References

• https://git.kernel.org/stable/c/0e52886c4324c9897c2c62f92be3dc8316cee67e
• https://git.kernel.org/stable/c/161a403c8625e152de03d1da22bbf9cda6dc9f9f
• https://git.kernel.org/stable/c/5c216bfa9fb7b36804485e67975e9c98055b31ef
• https://git.kernel.org/stable/c/6fe5c3a2503983abb431d93faeadfc7f5e6a7e33
• https://git.kernel.org/stable/c/a58024835c704419bb46d2a34e5223f65605f958
• https://git.kernel.org/stable/c/a9ce4053dc945c5372dedba5017ee675b30dc0c5

Original description

In the Linux kernel, the following vulnerability has been resolved: net: lan743x: fix RX checksum use-after-free lan743x_rx_process_buffer() adds each non-first receive buffer to the head skb's frag_list. On the last descriptor, lan743x_rx_trim_skb() linearizes the head and frees the fragment skb metadata. The checksum-success path then writes ip_summed through the local skb pointer, which still points to the final fragment. This causes a use-after-free write when a packet spans more than one receive buffer. Set ip_summed on the surviving head skb instead. Multi-buffer receive can occur after a live MTU increase because existing ring entries keep their old buffer size until they are replenished. A KUnit test invoking lan743x_rx_process_buffer() with a two-buffer packet produced a one-byte KASAN use-after-free write before this change. The same test passed after the change. The driver object also builds with W=1. This was not tested on physical LAN743x hardware.