From: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: Shuangpeng Bai <shuangpeng.kernel@gmail.com>,
David Lechner <dlechner@baylibre.com>,
Nuno Sa <nuno.sa@analog.com>, Andy Shevchenko <andy@kernel.org>,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 3/3] iio: adc: ti-ads112c14: add continuous mode support
Date: Sun, 13 Sep 2026 23:44:23 -0400 [thread overview]
Message-ID: <20260914034428.2165528-1-shuangpeng.kernel@gmail.com> (raw)
In-Reply-To: <20260901025147.583b3f61@jic23-huawei>
Hi Jonathan,
I took another look at current_trigger_store() following your comment
about the possible TOCTOU there. There may also be a trigger lifetime
issue in the attach path.
I checked mainline commit
fd73f4a6659897191fa0d40695fe370925dd3780 (Linux 7.3-rc3).
The reference acquired by current_trigger_store() becomes the reference
held by indio_dev->trig, while iio_trigger_attach_poll_func() does not
take an additional device reference to the trigger.
For example, hi8435 uses INDIO_EVENT_TRIGGERED and allows changing its
trigger, so these stores reach attach/detach. Assume the consumer stays
registered, initially has no trigger, and T is a sysfs trigger with no
other users. No one writes trigger_now.
With two independently opened current_trigger files, the stores can run
concurrently because kernfs only serializes each open file:
A: select T via current_trigger_store()
acquire reference; indio_dev->trig = T
iio_trigger_attach_poll_func(T, pollfunc_event)
allocate pf->irq; request_threaded_irq() succeeds and returns
<preempt before reading trig->ops>
B: remove T via iio-trig-sysfs's remove_trigger
iio_trigger_unregister(T)
irq_work_sync(&t->work)
iio_trigger_free(T)
clear current_trigger with "\n"
oldtrig = T; indio_dev->trig = NULL
iio_trigger_detach_poll_func(T, pollfunc_event)
iio_trigger_put(T) -> iio_trig_release() -> kfree(T)
A: resume in iio_trigger_attach_poll_func()
if (trig->ops && trig->ops->set_trigger_state && notinuse)
^ possible UAF
The consumer reference keeps T alive after removal, but B's clearing
store can drop the last reference while A is still in attach.
At the pause point the IRQ is installed, so B can detach it. T->ops is
NULL, and free_irq() does not wait for the enclosing attach call.
I have only checked this by source review and do not have a reproducer
or KASAN trace.
Does this race look possible to you?
Best,
Shuangpeng
prev parent reply other threads:[~2026-09-14 3:45 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-27 22:22 [PATCH v4 0/3] iio: adc: ti-ads112c14: " David Lechner (TI)
2026-08-27 22:22 ` [PATCH v4 1/3] iio: adc: ti-ads112c14: add DRDY interrupt support David Lechner (TI)
2026-08-30 21:00 ` Jonathan Cameron
2026-08-27 22:22 ` [PATCH v4 2/3] iio: adc: ti-ads112c14: create data read helper functions David Lechner (TI)
2026-08-27 22:22 ` [PATCH v4 3/3] iio: adc: ti-ads112c14: add continuous mode support David Lechner (TI)
2026-08-30 21:00 ` Jonathan Cameron
2026-08-30 22:24 ` Jonathan Cameron
2026-08-31 21:39 ` David Lechner
2026-08-31 21:31 ` David Lechner
2026-09-01 1:51 ` Jonathan Cameron
2026-09-14 3:44 ` Shuangpeng Bai [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=20260914034428.2165528-1-shuangpeng.kernel@gmail.com \
--to=shuangpeng.kernel@gmail.com \
--cc=andy@kernel.org \
--cc=dlechner@baylibre.com \
--cc=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nuno.sa@analog.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
all inboxes | Powered by JetHome®