From: Hongyan Xu <getshell@seu.edu.cn>
To: qemu-devel@nongnu.org
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
qemu-stable@nongnu.org, Hongyan Xu <getshell@seu.edu.cn>
Subject: [PATCH] chardev/baum: unregister the brlapi fd handler on finalize
Date: Fri, 4 Sep 2026 11:30:55 +0800 [thread overview]
Message-ID: <20260904033055.413-1-getshell@seu.edu.cn> (raw)
baum_chr_open() registers baum->brlapi_fd with the main loop through a
raw qemu_set_fd_handler() call. The chardev base class does not know
about this handler, and char_braille_finalize() only closes the brlapi
connection and frees the handle; it never removes the fd handler.
When the chardev is removed at runtime (QMP chardev-remove /
object_unparent), BaumChardev is finalized and freed while the main loop
still holds an fd handler whose opaque points to the freed object. The
next time brlapi_fd becomes readable (or the connection drops) the loop
calls baum_chr_read() with a dangling opaque, dereferencing freed
memory -> host use-after-free.
Unregister the handler in char_braille_finalize() before tearing the
connection down, using the same descriptor that baum_chr_open()
registered, and NULL the handle afterwards as a belt-and-braces guard.
Only do so while baum->brlapi is valid: baum_chr_open() sets
baum->brlapi_fd from brlapi__openConnection(), which is
BRLAPI_INVALID_FILE_DESCRIPTOR on failure, and that error path already
g_free()s the handle and returns before any handler is installed.
Signed-off-by: Hongyan Xu <getshell@seu.edu.cn>
---
chardev/baum.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/chardev/baum.c b/chardev/baum.c
index ac1e535ba8..6d9df70c7e 100644
--- a/chardev/baum.c
+++ b/chardev/baum.c
@@ -671,8 +671,16 @@ static void char_braille_finalize(Object *obj)
timer_free(baum->cellCount_timer);
if (baum->brlapi) {
+ /*
+ * baum_chr_open() registered brlapi_fd with the main loop via
+ * qemu_set_fd_handler(); unregister it before tearing the
+ * connection down so a later chardev-remove cannot dispatch
+ * baum_chr_read() with a dangling opaque.
+ */
+ qemu_set_fd_handler(baum->brlapi_fd, NULL, NULL, NULL);
brlapi__closeConnection(baum->brlapi);
g_free(baum->brlapi);
+ baum->brlapi = NULL;
}
}
--
2.50.1.windows.1
next reply other threads:[~2026-09-04 4:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 3:30 Hongyan Xu [this message]
2026-09-04 6:36 ` [PATCH] chardev/baum: unregister the brlapi fd handler on finalize Samuel Thibault
-- strict thread matches above, loose matches on Subject: below --
2026-09-08 21:11 Samuel Thibault
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=20260904033055.413-1-getshell@seu.edu.cn \
--to=getshell@seu.edu.cn \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
--cc=samuel.thibault@ens-lyon.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.