From: Qingfang Deng <qingfang.deng@linux.dev>
To: netdev-bot+sashiko@kernel.org
Cc: andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@kernel.org,
kuba@kernel.org, pabeni@redhat.com, leitao@debian.org,
norbert@doyensec.com, hataegu0826@gmail.com, paulus@ozlabs.org,
Brice.Goglin@ens-lyon.org, akpm@osdl.org, Matt_Domsch@dell.com,
linux-ppp@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] ppp: remove SC_MUST_COMP
Date: Sat, 31 Oct 2026 09:28:10 +0800 [thread overview]
Message-ID: <84396bab-166b-435f-9663-0aa2939de3fc@linux.dev> (raw)
In-Reply-To: <179339596607.3131.10030375792154782283@kernel.org>
On 10/31/2026 5:32 AM, netdev-bot+sashiko@kernel.org wrote:
> [Severity: Medium]
> Does the fix need the define to be removed from the UAPI header?
>
> PPPIOCSFLAGS already masks the user value with the kernel-internal
> SC_FLAG_BITS:
>
> drivers/net/ppp/ppp_generic.c:ppp_ioctl() {
> ...
> ppp->flags = val & SC_FLAG_BITS;
> ...
> }
>
> Removing the bit from SC_FLAG_BITS (and SC_MASK), together with the two
> checks, looks like enough to stop SC_DC_ERROR from being stored as a
> config flag.
>
> Deleting the define is a separate change at the source level. Userspace
> that includes <linux/ppp-ioctl.h>, directly or through <linux/if_ppp.h>,
> and refers to SC_MUST_COMP would no longer build.
>
> The commit message calls the flag unused, but the evidence is that one
> pppd integration from 2005 never landed upstream. That does not rule out
> out-of-tree pppd MPPE forks or other daemons that use the name.
>
> With the Fixes: tag pointing at a 2005 commit, this header change will
> likely be backported to the stable kernel-headers as well.
>
> Would it work to keep the define, with a comment that the kernel ignores
> it and that it aliases SC_DC_ERROR, while still dropping it from
> SC_FLAG_BITS and SC_MASK and removing the checks?
I found no trace of existing users (searched GitHub). Even _if_ there
are any, _and_ SC_MUST_COMP does not alias SC_DC_ERROR, the logic is
still flawed - received packets are silently dropped without noticing
the userspace.
If the goal is to prevent the removal from backports, I may split out
the removal part into a net-next patch.
prev parent reply other threads:[~2026-10-31 1:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 7:49 [PATCH net] ppp: remove SC_MUST_COMP Qingfang Deng
2026-10-30 21:32 ` netdev-bot+sashiko
2026-10-31 1:28 ` Qingfang Deng [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=84396bab-166b-435f-9663-0aa2939de3fc@linux.dev \
--to=qingfang.deng@linux.dev \
--cc=Brice.Goglin@ens-lyon.org \
--cc=Matt_Domsch@dell.com \
--cc=akpm@osdl.org \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=hataegu0826@gmail.com \
--cc=kuba@kernel.org \
--cc=leitao@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-ppp@vger.kernel.org \
--cc=netdev-bot+sashiko@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=norbert@doyensec.com \
--cc=pabeni@redhat.com \
--cc=paulus@ozlabs.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.