From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-181.mta0.migadu.com (out-181.mta0.migadu.com [91.218.175.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7B6152DCF61 for ; Sun, 19 Apr 2026 07:54:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776585241; cv=none; b=gefGnWTX+MeT6QhA+5QIGggOj3PeDEY3DNxSKLKGWRy65HpqkPA8nnXTuZOANguqYGqC1OF/LwVDtpq3vItoa1nVix3fWmkUk7VA8HNhM/ymAi0SKqyyjD8kmF+uuKcfi7myKMJEc0gS3kg+6iPUyyDdAWjzeoB2pEgY8eT/ge0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776585241; c=relaxed/simple; bh=E51XdivgXYIY5zPsosfCq0DsVtrQFYIvPrKAyxTDIaM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Zi2QgS29okDeaIIpgS6zRXZzIeXZNaDW67eYjFUjRRoScLBIyN589zczPbWp3621RwdRnhSJxUArXquu6oDpLJ/6yAZnyrwsdxp4q/b+MPTs0wouV7DlWZwDDGd0C1dkwPQTE/qOuGoXpOqn5XSv9X5sdmfAZZ9Fd8iZFOkYDWk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=Hdm/DIl0; arc=none smtp.client-ip=91.218.175.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="Hdm/DIl0" Message-ID: <50806e49-c3a1-4188-bd73-85e0ad688ebf@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1776585228; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+NhmQ0fyExbe9oLesQZIQSK20oXCEDZCPnnUDMZ+R6I=; b=Hdm/DIl0gB9Oer2IyAnav8h+Vby2J4nL5q9duVVTyEkdn3H5bQKJauSZx8H3LP+MZamlaP CKz3uNB41o5rzASzHusSe7xMxBFr8FVJmFTQHL7QNRZ4BJReHFl8iF57eRa9p9nIGblJ+r D3HfeQqFGqYR6hgHrehJ+r903uwHw6o= Date: Sun, 19 Apr 2026 15:53:36 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH net v6 2/2] pppoe: drop PFC frames To: Jakub Kicinski Cc: linux-ppp@vger.kernel.org, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, pabeni@redhat.com, hataegu0826@gmail.com, horms@kernel.org, kees@kernel.org, kuniyu@google.com, bigeasy@linutronix.de, gnault@redhat.com, ericwouds@gmail.com, semen.protsenko@linaro.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, paulus@ozlabs.org, jaco@uls.co.za, carlsonj@workingcode.com, wojciech.drewek@intel.com, marcin.szycik@linux.intel.com References: <20260415022456.141758-2-qingfang.deng@linux.dev> <20260418191145.213625-1-kuba@kernel.org> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Qingfang Deng In-Reply-To: <20260418191145.213625-1-kuba@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT 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