From: sashiko-bot@kernel.org
To: "Sean Young" <sean@mess.org>
Cc: bpf@vger.kernel.org, media-ci@linuxtv.org
Subject: Re: [PATCH v3 12/13] media: rc: Fix use after free in bpf progs
Date: Wed, 22 Jul 2026 10:49:06 +0000 [thread overview]
Message-ID: <20260722104907.27C131F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <ef00c264d0ead1324c4d61bbb3b1a4b2dc5bd4f6.1784715737.git.sean@mess.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] NULL pointer dereference in BPF LIRC operations due to missing `!raw` check on device registration error path.
--
--- Patch [12]: [PATCH v3 12/13] media: rc: Fix use after free in bpf progs ---
commit 7dc21e94d34583cca33adec11dc3c1b8af880d26
Author: Sean Young <sean@mess.org>
media: rc: Fix use after free in bpf progs
Since commit dccc0c3ddf8f ("media: rc: fix race between unregister and
urb/irq callbacks"), rcdev->raw is no longer set to NULL after device
unregister. raw->progs could point to stale data.
> diff --git a/drivers/media/rc/bpf-lirc.c b/drivers/media/rc/bpf-lirc.c
> index 2f7564f26445c..14ab611e74457 100644
> --- a/drivers/media/rc/bpf-lirc.c
> +++ b/drivers/media/rc/bpf-lirc.c
> @@ -148,12 +148,13 @@ static int lirc_bpf_attach(struct rc_dev *rcdev, struct bpf_prog *prog)
> if (ret)
> return ret;
>
> - raw = rcdev->raw;
> - if (!raw) {
> + if (!rcdev->registered) {
> ret = -ENODEV;
> goto unlock;
> }
>
> + raw = rcdev->raw;
> +
> old_array = lirc_rcu_dereference(raw->progs);
[Severity: High]
Can this lead to a NULL pointer dereference if rc_register_device() fails?
In rc_register_device(), dev->registered is set to true before lirc_register()
makes the device visible to userspace. If a subsequent initialization step fails
(such as input_register_device() or ir_raw_event_register()), the error path
calls ir_raw_event_free(dev), which frees dev->raw and sets it to NULL.
However, dev->registered is never reverted to false. If a concurrent userspace
process opens /dev/lircX and calls bpf(BPF_PROG_ATTACH) while the fd is kept
open, the !rcdev->registered check here would pass. The raw pointer would
then be NULL, causing lirc_rcu_dereference(raw->progs) to crash.
[ ... ]
> @@ -186,12 +187,13 @@ static int lirc_bpf_detach(struct rc_dev *rcdev, struct bpf_prog *prog)
> if (ret)
> return ret;
>
> - raw = rcdev->raw;
> - if (!raw) {
> + if (!rcdev->registered) {
> ret = -ENODEV;
> goto unlock;
> }
>
> + raw = rcdev->raw;
> +
> old_array = lirc_rcu_dereference(raw->progs);
[Severity: High]
Could the same NULL pointer dereference occur here in lirc_bpf_detach() if
userspace races with device registration failure?
[ ... ]
> @@ -316,6 +319,11 @@ int lirc_prog_query(const union bpf_attr *attr, union bpf_attr __user *uattr)
> if (ret)
> goto put;
>
> + if (!rcdev->registered) {
> + ret = -ENODEV;
> + goto unlock;
> + }
> +
> progs = lirc_rcu_dereference(rcdev->raw->progs);
[Severity: High]
Does this code also suffer from the same NULL pointer dereference risk on
rcdev->raw when rc_register_device() hits an error path?
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1784715737.git.sean@mess.org?part=12
next prev parent reply other threads:[~2026-07-22 10:49 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-22 10:23 [PATCH v3 00/13] Fix leaks in rc core Sean Young
2026-07-22 10:23 ` [PATCH v3 01/13] media: streamzap: Add missing rc_unregister_device() Sean Young
2026-07-22 10:23 ` [PATCH v3 02/13] media: redrat3: Ensure rc device is freed if enable_detector() fails Sean Young
2026-07-22 10:23 ` [PATCH v3 03/13] media: redrat3: Ensure we don't read beyond the end of the packet Sean Young
2026-07-22 10:23 ` [PATCH v3 04/13] media: redrat3: Ensure all urbs are suspended Sean Young
2026-07-22 10:23 ` [PATCH v3 05/13] media: redrat3: Error path leaves device in transmitting state Sean Young
2026-07-22 10:23 ` [PATCH v3 06/13] media: sunxi-cir: Ensure no more interrupts can occur before free Sean Young
2026-07-22 10:36 ` sashiko-bot
2026-07-22 10:23 ` [PATCH v3 07/13] media: meson-ir-tx: Ensure clock is disabled on unbind Sean Young
2026-07-22 10:23 ` Sean Young
2026-07-22 10:34 ` sashiko-bot
2026-07-22 10:23 ` [PATCH v3 08/13] media: meson-ir-tx: Ensure rc_free_device() is called " Sean Young
2026-07-22 10:23 ` Sean Young
2026-07-22 10:23 ` [PATCH v3 09/13] media: meson-ir-tx: Ensure probe error is propagated Sean Young
2026-07-22 10:23 ` Sean Young
2026-07-22 10:23 ` [PATCH v3 10/13] media: ir-hix5hd2: Ensure rdev is setup before interrupts are enabled Sean Young
2026-07-22 10:23 ` [PATCH v3 11/13] media: rc: Use after free in ir_raw_event_handle() Sean Young
2026-07-22 10:23 ` [PATCH v3 12/13] media: rc: Fix use after free in bpf progs Sean Young
2026-07-22 10:49 ` sashiko-bot [this message]
2026-07-22 10:23 ` [PATCH v3 13/13] media: rc: Fix race condition during rc_register_device() Sean Young
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=20260722104907.27C131F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=media-ci@linuxtv.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sean@mess.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.