Re: [PATCH net] atm: br2684: validate IP header length before filtering

[Andrew Lunn]

On Mon, Jun 15, 2026 at 02:10:55PM +0800, Yizhou Zhao wrote:
> Hi Andrew,
> 
> On Sun, Jun 14, 2026 at 08:36:57PM +0800, Andrew Lunn wrote:
> > So did all these people find the problem at the same time in parallel?
> > Can you point to their reports?
> 
> No, they were not independent reports found in parallel. This came from
> one internal analysis/reproducer effort, and I do not have separate
> public reports to point to. Sorry for the confusion.

Please take a read of:

https://docs.kernel.org/process/submitting-patches.html

There is a section about Reported-by, and what it means.

>  > It is a long time since i worked with ATM. From what i remember,
> ATM > cells are 48 bytes in size. So can the packet actually be
> smaller than > 48? Would a 48 byte packet trigger this? Or is AAL5
> involved here? Can > AAL5 carry a frame smaller than 48 bytes?  On
> the cell-size question: yes, ATM cells carry 48 bytes of payload,
> but br2684_push() does not receive raw ATM cells.  It receives the
> reassembled AAL5 CPCS-SDU/PDU from the ATM layer.  AAL5 can carry a
> shorter user payload in one cell by padding the final cell, with the
> AAL5 trailer carrying the real payload length.  So an 8-byte
> LLC/SNAP BR2684 PDU can be carried in a single ATM cell with
> padding, while br2684 still sees skb->len == 8 after AAL5
> reassembly.  A reassembled 48-byte BR2684 PDU would not trigger the
> issue in the LLC case: after pulling the 8-byte LLC/SNAP header, 40
> bytes remain, so the IPv4 daddr access is in bounds. The problematic
> case is a reassembled AAL5 PDU shorter than the encapsulation header
> plus a minimum IPv4 header, for example an 8-byte LLC/SNAP IPv4 PDU
> with no IP payload. The VC-routed case is similar: the current code
> reads iph->version before checking that the reassembled PDU contains
> an IPv4 header.  > What hardware was used when finding this problem?
> I know DSL often > used ATM underneath, so was it a DSL modem?  I'm
> sorry that no physical ATM/DSL hardware was used. I verified this in
> QEMU/KVM with a small dummy ATM device that registers an atm_dev and
> injects reassembled AAL5 PDUs through the real VCC receive callback
> after BR2684 is attached.

So this is hypothetical and in real life not a real issue. Please drop
the Fixes tag, and submit to net next.

ATM is pretty much dead. If you do any further work, could you please
look at currently used hardware, and try to avoid wasting our time
with hypothetical problems.

    Andrew

---
pw-bot: cr