Re: [PATCH net v6 2/2] pppoe: drop PFC frames
From: Qingfang Deng
Date: Sun Apr 19 2026 - 03:54:13 EST
Hi,
On 4/19/2026 3:11 AM, Jakub Kicinski wrote:
[ ... ]I already updated the pskb_may_pull() above, from struct pppoe_hdr (6) to PPPOE_SES_HLEN (8), to ensure that.
@@ -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?
Regards,
Qingfang