[PATCH net] atm: br2684: reject short VC-MUX bridged frames

[PATCH net] atm: br2684: reject short VC-MUX bridged frames

[Yizhou Zhao]

br2684_push() validates the two-byte pad at the start of received
VC-MUX bridged frames with memcmp(), but does not first make sure that
those two bytes are present in the skb.

A short AAL5 PDU can reach this path after a BR2684 VCC is attached with
BR2684_ENCAPS_VC and bridged payload.  If skb->len is 0 or 1, the pad
comparison reads beyond the valid skb data.  When the bytes beyond
skb->len compare as zero, the code then continues toward eth_type_trans()
with the malformed frame.

Reject frames shorter than BR2684_PAD_LEN before checking the pad.  This
keeps the existing validation for valid VC-MUX bridged frames, which must
carry the two-byte pad before the Ethernet header.

Fixes: 7e903c2ae36e ("atm: [br2864] fix routed vcmux support")
Cc: stable@vger.kernel.org
Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>
Reported-by: Ao Wang <wangao@seu.edu.cn>
Reported-by: Xuewei Feng <fengxw06@126.com>
Reported-by: Qi Li <qli01@tsinghua.edu.cn>
Reported-by: Ke Xu <xuke@tsinghua.edu.cn>
Assisted-by: GLM:GLM-5.1
Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
---
 net/atm/br2684.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/atm/br2684.c b/net/atm/br2684.c
index 6580d67c3456..07283c475a40 100644
--- a/net/atm/br2684.c
+++ b/net/atm/br2684.c
@@ -491,6 +491,8 @@ static void br2684_push(struct atm_vcc *atmvcc, struct sk_buff *skb)
 			skb->pkt_type = PACKET_HOST;
 		} else { /* p_bridged */
 			/* first 2 chars should be 0 */
+			if (skb->len < BR2684_PAD_LEN)
+				goto error;
 			if (memcmp(skb->data, pad, BR2684_PAD_LEN) != 0)
 				goto error;
 			skb_pull(skb, BR2684_PAD_LEN);

-- 
2.43.0

Re: [PATCH net] atm: br2684: reject short VC-MUX bridged frames

[Andrew Lunn]

On Sun, Jun 14, 2026 at 11:27:45PM +0800, Yizhou Zhao wrote:
> br2684_push() validates the two-byte pad at the start of received
> VC-MUX bridged frames with memcmp(), but does not first make sure that
> those two bytes are present in the skb.
> 
> A short AAL5 PDU can reach this path after a BR2684 VCC is attached with
> BR2684_ENCAPS_VC and bridged payload.  If skb->len is 0 or 1, the pad
> comparison reads beyond the valid skb data.  When the bytes beyond
> skb->len compare as zero, the code then continues toward eth_type_trans()
> with the malformed frame.
> 
> Reject frames shorter than BR2684_PAD_LEN before checking the pad.  This
> keeps the existing validation for valid VC-MUX bridged frames, which must
> carry the two-byte pad before the Ethernet header.
> 
> Fixes: 7e903c2ae36e ("atm: [br2864] fix routed vcmux support")
> Cc: stable@vger.kernel.org
> Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
> Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>
> Reported-by: Ao Wang <wangao@seu.edu.cn>
> Reported-by: Xuewei Feng <fengxw06@126.com>
> Reported-by: Qi Li <qli01@tsinghua.edu.cn>
> Reported-by: Ke Xu <xuke@tsinghua.edu.cn>
> Assisted-by: GLM:GLM-5.1

Same questions as for the previous patch. Lots of parallel
discoveries? What hardware was used, etc.

	     Andrew

Re: [PATCH net] atm: br2684: reject short VC-MUX bridged frames

[Yizhou Zhao]

Hi Andrew,

On Sun, Jun 14, 2026 at 08:39:12PM +0800, Andrew Lunn wrote:

> Same questions as for the previous patch. Lots of parallel
> discoveries? What hardware was used, etc.

I'm sorry that in this case no physical ATM/DSL hardware was 
used either. I verified this in QEMU/KVM with a small dummy 
ATM device as in the previous patch. I think that this is a
real logical bug, but whether it can be triggered by a real
Device was not verified.

Yours Sincerely,
Yizhou

Re: [PATCH net] atm: br2684: reject short VC-MUX bridged frames

[Andrew Lunn]

On Mon, Jun 15, 2026 at 02:27:56PM +0800, Yizhou Zhao wrote:
> Hi Andrew,
> 
> On Sun, Jun 14, 2026 at 08:39:12PM +0800, Andrew Lunn wrote:
> 
> > Same questions as for the previous patch. Lots of parallel
> > discoveries? What hardware was used, etc.
> 
> I'm sorry that in this case no physical ATM/DSL hardware was 
> used either. I verified this in QEMU/KVM with a small dummy 
> ATM device as in the previous patch. I think that this is a
> real logical bug, but whether it can be triggered by a real
> Device was not verified.

Please also submit this one to net next.

       Andrew