From: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
To: dmitry.torokhov@gmail.com
Cc: floe@butterbrot.org, linux-input@vger.kernel.org,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
Subject: [PATCH v1 0/2] Input: sur40 - fix UAF/hang on closing the video node after unplug
Date: Sun, 20 Sep 2026 18:39:47 +0700 [thread overview]
Message-ID: <20260920113949.12726-1-ngocthang2710.1999@gmail.com> (raw)
Hi,
syzbot reported a slab-use-after-free in vb2_core_queue_release() [1]:
closing /dev/v4l-touch* after the SUR40 was unplugged reads freed memory.
Cause: sur40_disconnect() kfree()s struct sur40_state, which embeds the
video_device, v4l2_device and vb2_queue, even though a video node can
still be open. v4l2_release() and vb2_fop_release() then dereference
freed memory. Patch 2 fixes this by giving the v4l2_device a release()
callback that frees the state, and dropping the disconnect path's
reference with v4l2_device_put(), so the last close does the freeing.
The probe error paths never expose the node and still free directly.
Patch 1 is needed first: once the state outlives disconnect, closing a
node that is still streaming hangs forever, because
sur40_stop_streaming() waits (vb2_wait_for_all_buffers) for buffers
that only the input poll callback completes, and that is gone after
unplug. Returning the queued buffers before the wait fixes it. This was
masked by the UAF above.
Testing: no hardware, so I emulated a SUR40 (045e:0775) with raw-gadget
on dummy_hcd in QEMU with KASAN. The reproducer enumerates the device,
starts a non-blocking read() on the video node (making the fd the queue
owner), disconnects the gadget, then close()s the fd.
- before: KASAN: slab-use-after-free in v4l2_release(), allocated in
sur40_probe(), freed in sur40_disconnect() (same alloc/free stacks
as the syzbot report)
- patch 1 only: no KASAN, but close() blocks in
vb2_wait_for_all_buffers() [only meaningful with patch 2 applied]
- both patches: 5 consecutive enumerate/disconnect/close cycles, no
KASAN, no hang.
(The dma_map_sg WARNING during read() in the log comes from dummy_hcd
having no DMA mask; it is unrelated.)
Nguyen Ngoc Thang (2):
Input: sur40 - don't wait for buffers nothing will complete
Input: sur40 - keep device state alive until the video node is
released
drivers/input/touchscreen/sur40.c | 21 +++++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
--
2.43.0
next reply other threads:[~2026-09-20 11:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-20 11:39 Nguyen Ngoc Thang [this message]
2026-09-20 11:39 ` [PATCH v1 1/2] Input: sur40 - don't wait for buffers nothing will complete Nguyen Ngoc Thang
2026-09-30 8:04 ` Hans Verkuil
2026-09-20 11:39 ` [PATCH v1 2/2] Input: sur40 - keep device state alive until the video node is released Nguyen Ngoc Thang
2026-09-30 8:05 ` Hans Verkuil
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=20260920113949.12726-1-ngocthang2710.1999@gmail.com \
--to=ngocthang2710.1999@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=floe@butterbrot.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.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 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®