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

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