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

[Yizhou Zhao]

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.

> 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.  That exercises the BR2684 receive and IP filter path,
but not a hardware SAR implementation. However, this is a real logical bug
existing in the kernel, but it is not verified that if it will be triggered
by a real hardware.

Yours Sincerely,
Yizhou