mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: hyunjungg <hj351016@gmail.com>
To: MyungJoo Ham <myungjoo.ham@samsung.com>,
	Chanwoo Choi <cw00.choi@samsung.com>
Cc: linux-kernel@vger.kernel.org,
	Krzysztof Kozlowski <krzk@kernel.org>,
	linux-samsung-soc@vger.kernel.org,
	Hans de Goede <hansg@kernel.org>,
	Hyunjung Ko <hj351016@gmail.com>
Subject: [PATCH 0/5] extcon: fix work-vs-devres teardown use-after-free in MUIC/connector drivers
Date: Fri,  6 Nov 2026 22:17:25 +0900	[thread overview]
Message-ID: <20261106131730.2633139-1-hj351016@gmail.com> (raw)

From: Hyunjung Ko <hj351016@gmail.com>

Five extcon drivers register a detect/IRQ work for device-managed
cancellation (devm_work_autocancel() / devm_delayed_work_autocancel())
in their probe function *before* they acquire the resources that the
work handler dereferences -- most importantly the extcon device from
devm_extcon_dev_allocate() / devm_extcon_dev_register(), and for
intel-int3496 also several GPIO descriptors.

devres unwinds in reverse registration order, so on unbind the extcon
device (and the GPIOs) are released first and the work is cancelled
last:

	/* free_irq() */
	devm_extcon_dev_unregister() / extcon freed
	...
	cancel_[delayed_]work_sync(&work);	/* too late */

The work is armed from the IRQ handler (schedule_work() in the MUIC
drivers; queue_delayed_work()/mod_delayed_work() in palmas/int3496), so
an instance can still be pending or running at unbind. When it runs in
the window after the extcon device has been freed but before the work is
cancelled, the handler dereferences freed memory via
extcon_set_state_sync() -> use-after-free. The MUIC drivers' early
"if (!info->edev) return;" guard does not help: info is itself devm
memory freed last, so info->edev is a dangling, non-NULL pointer in that
window rather than NULL.

Each patch fixes one driver by moving the devm work-cancel registration
to *after* the extcon device (and, for int3496, the GPIOs) are acquired
and registered, and still *before* the IRQ that arms the work. Teardown
then runs in the correct order: free IRQ -> drain/cancel work -> free
extcon device. The relocated devm_[delayed_]work_autocancel() still
performs the INIT before the work's first queuing site (the IRQ handler,
requested afterwards), so no queue-before-INIT window is introduced. No
functional change otherwise.

Found by static analysis / code review. None of the five is reproduced
on hardware: each needs its MUIC/PMIC/USB-ID-mux chip and is not
QEMU-reproducible. Treat accordingly.

Hyunjung Ko (5):
  extcon: intel-int3496: drain ID work before its GPIOs and extcon device are freed
  extcon: palmas: drain ID-detect work before the extcon device is freed
  extcon: max8997: drain MUIC IRQ work before extcon device is freed
  extcon: max14577: drain MUIC IRQ work before extcon device is freed
  extcon: max77693: drain MUIC IRQ work before extcon device is freed

 drivers/extcon/extcon-intel-int3496.c |  7 ++++---
 drivers/extcon/extcon-palmas.c        | 12 ++++++------
 drivers/extcon/extcon-max8997.c       | 26 +++++++++++++-------------
 drivers/extcon/extcon-max14577.c      | 28 ++++++++++++++--------------
 drivers/extcon/extcon-max77693.c      | 28 ++++++++++++++--------------
 5 files changed, 51 insertions(+), 50 deletions(-)

--
2.43.0


             reply	other threads:[~2026-11-06 13:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-06 13:17 hyunjungg [this message]
2026-11-06 13:17 ` [PATCH 1/5] extcon: intel-int3496: drain ID work before its GPIOs and extcon device are freed hyunjungg
2026-11-06 15:46   ` Hans de Goede
2026-11-06 13:17 ` [PATCH 2/5] extcon: palmas: drain ID-detect work before the extcon device is freed hyunjungg
2026-11-06 13:17 ` [PATCH 3/5] extcon: max8997: drain MUIC IRQ work before " hyunjungg
2026-11-06 13:17 ` [PATCH 4/5] extcon: max14577: " hyunjungg
2026-11-06 13:17 ` [PATCH 5/5] extcon: max77693: " hyunjungg

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=20261106131730.2633139-1-hj351016@gmail.com \
    --to=hj351016@gmail.com \
    --cc=cw00.choi@samsung.com \
    --cc=hansg@kernel.org \
    --cc=krzk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=myungjoo.ham@samsung.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®