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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-10-06T09:18:11.803Z",
  "pubdate": "2026-10-06T09:18:11.803Z",
  "executiveSummary": "A use-after-free vulnerability exists in the Linux kernel's lan743x network driver, specifically within the RX packet processing logic.\nThe issue stems from an incorrect pointer reference during checksum processing when handling multi-buffer packets.\nThe vulnerability occurs when a packet spans multiple receive buffers, causing the driver to write to freed memory metadata after the head skb is linearized.\nThis flaw allows for a potential memory corruption scenario, which could lead to kernel instability, denial of service, or potentially arbitrary code execution if an attacker can manipulate the heap state.\nThe vulnerability impacts systems utilizing the lan743x driver. It is triggered during the RX process when packets exceed single-buffer capacity, such as during live MTU increases.\nThere are no specific authentication or privilege requirements to trigger this vulnerability, as it is reached via normal network traffic processing, making it potentially exploitable by a remote attacker capable of sending fragmented or large packets to the target interface.",
  "technicalDetails": "The root cause of this vulnerability is an improper reference in the lan743x_rx_process_buffer() function within the lan743x driver. When the driver processes packets that span multiple receive buffers, it appends subsequent fragments to the frag_list of the head skb.\nUpon reaching the final descriptor, the driver invokes lan743x_rx_trim_skb(), which linearizes the head skb and subsequently frees the metadata associated with the fragment skbs.\nThe vulnerability is triggered because the checksum-success path continues to utilize a local skb pointer that still references the now-freed final fragment skb. When the driver attempts to update the ip_summed field for the packet, it performs a write operation against this stale, freed memory location, resulting in a KASAN-detected use-after-free (UAF) condition.\nThe multi-buffer receive scenario is frequently encountered following a live MTU increase, as existing ring entries retain their previous buffer size until they are actively replenished. Consequently, an attacker can intentionally cause the driver to enter this multi-buffer path by sending packets that exceed the current buffer size, forcing the driver to concatenate fragments and trigger the faulty code path.\nStep-by-step exploitation flow: 1. The attacker transmits a network frame that is larger than the individual RX buffer size, necessitating multiple descriptors. 2. The lan743x driver populates the head skb with fragments. 3. lan743x_rx_trim_skb() is called, linearizing the packet and releasing the memory associated with the fragment skbs. 4. The driver logic proceeds to the checksum calculation phase, where it incorrectly writes the checksum status to the ip_summed field using a pointer to the already-freed fragment skb. 5. This results in a memory write into an invalid/reallocated heap region.\nThe impact of this UAF is significant, as it permits an attacker to perform a write operation to kernel memory. Depending on the kernel heap layout at the time of the UAF, this could lead to the corruption of adjacent kernel objects, potentially allowing an attacker to overwrite sensitive kernel structures or pointers, thereby escalating privileges or executing arbitrary code."
}