From: Simon Horman <horms@kernel.org>
To: Dudu Lu <phx0fer@gmail.com>
Cc: vinicius.gomes@intel.com, jhs@mojatatu.com, jiri@resnulli.us,
netdev@vger.kernel.org
Subject: Re: [PATCH net] net/sched: taprio: unwind the netdevice notifier if register_qdisc() fails
Date: Fri, 23 Oct 2026 11:59:53 +0100 [thread overview]
Message-ID: <20261023105953.GK708417@horms.kernel.org> (raw)
In-Reply-To: <20261021155417.66254-1-phx0fer@gmail.com>
On Wed, Oct 21, 2026 at 11:54:17PM +0800, Dudu Lu wrote:
> taprio_module_init() registers taprio_device_notifier and then returns
> register_qdisc()'s error directly. When register_qdisc() fails the
> notifier stays registered, but the loader's failure path frees the module
> image without ever calling the __exit function, so netdev_chain is left
> pointing at taprio_device_notifier.notifier_call -- a function pointer
> that lives in text that has just been freed.
>
> register_qdisc() has two failure returns: -EEXIST (duplicate .id) and
> -EINVAL (malformed cl_ops). taprio_class_ops satisfies every checked
> implication, so -EINVAL is unreachable and -EEXIST is the only reachable
> failure; it needs a pre-existing "taprio" entry in qdisc_base. In-tree
> that is reachable only through bpf_qdisc_reg() (CONFIG_NET_SCH_BPF); a
> module calling the exported register_qdisc() reaches it as well.
>
> Once the notifier is left dangling, the next netdevice event that walks
> netdev_chain calls through the stale pointer:
>
> BUG: KASAN: vmalloc-out-of-bounds in notifier_call_chain+0x650/0xb5c
> Read of size 8 at addr ffff80001fc5ab08 by task ip/110
> notifier_call_chain+0x650/0xb5c
> raw_notifier_call_chain+0x34/0x64
> call_netdevice_notifiers_info+0xa8/0x198
> __dev_close_many+0xe0/0x800
> ...
> >ffff80001fc5ab00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>
> The shadow row is all f8 (KASAN_VMALLOC_INVALID): the read lands in
> vmalloc memory that was poisoned when the module image was freed, and the
> indirect call is unguarded because the only check, func_ptr_is_kernel_text(),
> is compiled out unless CONFIG_DEBUG_NOTIFIERS.
>
> Mirror the sibling sch_cbs.c and act_mirred.c, which unwind the notifier
> on this failure path.
>
> Fixes: 7b9eba7ba0c1 ("net/sched: taprio: fix picos_per_byte miscalculation")
> Assisted-by: LLM
> Signed-off-by: Dudu Lu <phx0fer@gmail.com>
> ---
> Tested base
> -----------
> Detected on Linux 7.3-rc4 (commit 93f51579e7df), arm64 QEMU guest.
> Re-checked against mainline f47d223627f8 (v7.3-341): the affected code
> is unchanged between the two, so the bug is still present there.
> Checked against linux-next next-20261021 (commit 9a482184d910): the
> affected code is unchanged there as well, so the bug is still present in
> linux-next too.
>
> Reproducer status
> -----------------
> A reproducer was written and executed on an arm64 QEMU guest with
> CONFIG_NET_SCH_TAPRIO=m, KASAN_VMALLOC=y, CONFIG_MODULE_UNLOAD=y; it fires at the
> claimed sink. The reproducer source is not posted here per
> Documentation/process/security-bugs.rst; it is available on request.
>
> Triggering conditions
> ---------------------
> A pre-existing "taprio" entry in qdisc_base, so register_qdisc() returns
> -EEXIST (the only reachable failure). In-tree this is reachable via
> bpf_qdisc_reg() (CONFIG_NET_SCH_BPF); the reproducer reaches it through the
> exported register_qdisc(). Then a NETDEV_UP event.
>
> Notes
> -----
> Built and checkpatch-clean: this patch was applied on top of 7.3-rc4
> (commit 93f51579e7df) and a full arm64 kernel (defconfig) was built with
> it -- no new warnings or errors. scripts/checkpatch.pl reports 0 errors,
> 0 warnings.
Reviewed-by: Simon Horman <horms@kernel.org>
next prev parent reply other threads:[~2026-10-23 10:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 15:54 [PATCH net] net/sched: taprio: unwind the netdevice notifier if register_qdisc() fails Dudu Lu
2026-10-21 15:58 ` netdev-bot+sinfo
2026-10-22 4:59 ` phx
2026-10-23 10:59 ` Simon Horman [this message]
2026-10-26 23:30 ` patchwork-bot+netdevbpf
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=20261023105953.GK708417@horms.kernel.org \
--to=horms@kernel.org \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=phx0fer@gmail.com \
--cc=vinicius.gomes@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