From: Simon Horman <horms@kernel.org>
To: Qingfang Deng <qingfang.deng@linux.dev>
Cc: linux-ppp@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
Guillaume Nault <gnault@redhat.com>,
Wojciech Drewek <wojciech.drewek@intel.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Paul Mackerras <paulus@ozlabs.org>, Jaco Kroon <jaco@uls.co.za>,
James Carlson <carlsonj@workingcode.com>,
Marcin Szycik <marcin.szycik@linux.intel.com>
Subject: Re: [PATCH net v5 1/2] flow_dissector: do not dissect PPPoE PFC frames
Date: Tue, 14 Apr 2026 18:08:32 +0100 [thread overview]
Message-ID: <20260414170745.GA772482@horms.kernel.org> (raw)
In-Reply-To: <20260414021353.23471-1-qingfang.deng@linux.dev>
On Tue, Apr 14, 2026 at 10:13:48AM +0800, Qingfang Deng wrote:
> RFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT
> RECOMMENDED for PPPoE. In practice, pppd does not support negotiating
> PFC for PPPoE sessions, and the flow dissector driver has assumed an
> uncompressed frame until the blamed commit.
>
> During the review process of that commit [1], support for PFC is
> suggested. However, having a compressed (1-byte) protocol field means
> the subsequent PPP payload is shifted by one byte, causing 4-byte
> misalignment for the network header and an unaligned access exception
> on some architectures.
>
> The exception can be reproduced by sending a PPPoE PFC frame to an
> ethernet interface of a MIPS board, with RPS enabled, even if no PPPoE
> session is active on that interface:
>
> $ 0 : 00000000 80c40000 00000000 85144817
> $ 4 : 00000008 00000100 80a75758 81dc9bb8
> $ 8 : 00000010 8087ae2c 0000003d 00000000
> $12 : 000000e0 00000039 00000000 00000000
> $16 : 85043240 80a75758 81dc9bb8 00006488
> $20 : 0000002f 00000007 85144810 80a70000
> $24 : 81d1bda0 00000000
> $28 : 81dc8000 81dc9aa8 00000000 805ead08
> Hi : 00009d51
> Lo : 2163358a
> epc : 805e91f0 __skb_flow_dissect+0x1b0/0x1b50
> ra : 805ead08 __skb_get_hash_net+0x74/0x12c
> Status: 11000403 KERNEL EXL IE
> Cause : 40800010 (ExcCode 04)
> BadVA : 85144817
> PrId : 0001992f (MIPS 1004Kc)
> Call Trace:
> [<805e91f0>] __skb_flow_dissect+0x1b0/0x1b50
> [<805ead08>] __skb_get_hash_net+0x74/0x12c
> [<805ef330>] get_rps_cpu+0x1b8/0x3fc
> [<805fca70>] netif_receive_skb_list_internal+0x324/0x364
> [<805fd120>] napi_complete_done+0x68/0x2a4
> [<8058de5c>] mtk_napi_rx+0x228/0xfec
> [<805fd398>] __napi_poll+0x3c/0x1c4
> [<805fd754>] napi_threaded_poll_loop+0x234/0x29c
> [<805fd848>] napi_threaded_poll+0x8c/0xb0
> [<80053544>] kthread+0x104/0x12c
> [<80002bd8>] ret_from_kernel_thread+0x14/0x1c
>
> Code: 02d51821 1060045b 00000000 <8c640000> 3084000f 2c820005 144001a2 00042080 8e220000
>
> To reduce the attack surface and maintain performance, do not process
> PPPoE PFC frames.
>
> [1] https://patch.msgid.link/20220630231016.GA392@debian.home
> Fixes: 46126db9c861 ("flow_dissector: Add PPPoE dissectors")
> Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev>
> ---
> Changes in v5: drop byte-swap change
> Link to v4: https://lore.kernel.org/netdev/20260410033627.93786-1-qingfang.deng@linux.dev/
>
> net/core/flow_dissector.c | 10 +---------
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
> index 1b61bb25ba0e..f9aaba554128 100644
> --- a/net/core/flow_dissector.c
> +++ b/net/core/flow_dissector.c
> @@ -1374,16 +1374,8 @@ bool __skb_flow_dissect(const struct net *net,
> break;
> }
>
> - /* least significant bit of the most significant octet
> - * indicates if protocol field was compressed
> - */
> ppp_proto = ntohs(hdr->proto);
> - if (ppp_proto & 0x0100) {
> - ppp_proto = ppp_proto >> 8;
> - nhoff += PPPOE_SES_HLEN - 1;
> - } else {
> - nhoff += PPPOE_SES_HLEN;
> - }
I think it would be good to add a comment around here
describing how PFC is safely handled in this function.
> + nhoff += PPPOE_SES_HLEN;
>
> if (ppp_proto == PPP_IP) {
> proto = htons(ETH_P_IP);
> --
> 2.43.0
>
prev parent reply other threads:[~2026-04-14 17:08 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-14 2:13 [PATCH net v5 1/2] flow_dissector: do not dissect PPPoE PFC frames Qingfang Deng
2026-04-14 2:13 ` [PATCH net v5 2/2] pppoe: drop " Qingfang Deng
2026-04-14 17:08 ` Simon Horman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260414170745.GA772482@horms.kernel.org \
--to=horms@kernel.org \
--cc=anthony.l.nguyen@intel.com \
--cc=carlsonj@workingcode.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gnault@redhat.com \
--cc=jaco@uls.co.za \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-ppp@vger.kernel.org \
--cc=marcin.szycik@linux.intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=paulus@ozlabs.org \
--cc=qingfang.deng@linux.dev \
--cc=wojciech.drewek@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox