Re: [PATCH net v6 2/2] pppoe: drop PFC frames

Qingfang Deng
2026-04-19T07:54:00Z

Hi,

On 4/19/2026 3:11 AM, Jakub Kicinski wrote:
> [ ... ]
>> @@ -434,6 +434,12 @@ static int pppoe_rcv(struct sk_buff *skb, struct net_device *dev,
>> if (skb->len < len)
>> goto drop;
>>
>> + /* skb->data points to the PPP protocol header after skb_pull_rcsum.
>> + * Drop PFC frames.
>> + */
>> + if (ppp_skb_is_compressed_proto(skb))
>
> Does this code safely access the PPP protocol byte?
>
> After pulling the PPPoE header, skb->data points to the inner payload.
> However, the new ppp_skb_is_compressed_proto() helper unconditionally
> dereferences skb->data[0].
>
> If a crafted PPPoE packet is received with an inner length of 0 and no
> Ethernet padding, the linear buffer might end exactly after the PPPoE header.
> In that scenario, this would read past the allocated linear buffer.
>
> Even if the inner length is greater than 0, could the payload reside entirely
> in non-linear paged fragments, causing an out-of-bounds read?
>
> Would it be safer to verify the packet has at least 1 byte and use
> pskb_may_pull() to ensure the protocol byte is in the linear region before
> inspecting it, perhaps after the pskb_trim_rcsum() call?
I already updated the pskb_may_pull() above, from struct pppoe_hdr (6)
to PPPOE_SES_HLEN (8), to ensure that.

Regards,
Qingfang