qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: =?gb18030?B?qWdseW0=?= <707242047@qq.com>
To: =?gb18030?B?TWFyYy1BbmRyqKYgTHVyZWF1?= <marcandre.lureau@redhat.com>
Cc: =?gb18030?B?cWVtdS1kZXZlbA==?= <qemu-devel@nongnu.org>,
	=?gb18030?B?a3JheGVs?= <kraxel@redhat.com>
Subject: =?gb18030?B?u9i4tKO6IFtQQVRDSCBSRkMgdjFdZGlzcGxheTogZml4IGhlYXAgdXNlIGFmdGVyIGZyZWUgaW4gY3Vyc29yX3B1dA==?=
Date: Thu, 11 Apr 2024 09:55:41 +0800	[thread overview]
Message-ID: <tencent_EC82468ED075970213367AE7801FBA4C0405@qq.com> (raw)
In-Reply-To: <CAMxuvazoMKnhU8bcSnON2daO7Am4h4oTYrvPjgRhKL8uUCzTFA@mail.gmail.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 3075 bytes --]

Hi


During the test with logging, I found that there may be a conflict between the logic of updating the refcount in vnc_dpy_cursor_define() and QXL_CURSOR_SET&nbsp;action,&nbsp; same as dpy_cursor_define() after commit&nbsp;385ac97f,&nbsp;&nbsp;and the atomic operation needs to be ensured;


The first thoughts are as follows£¬only lock cursor_unref/cursor_ref with ssd.lock£¬But&nbsp;it seems we can't get ssd.lock within dpy_cursor_define£¬so if we can't lock The top-level function&nbsp;qemu_spice_cursor_refresh_bh()£¿


--- a/hw/display/qxl-render.c
+++ b/hw/display/qxl-render.c
@@ -336,6 +336,7 @@ int qxl_render_cursor(PCIQXLDevice *qxl, QXLCommandExt *ext)
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;qemu_mutex_lock(&amp;qxl-&gt;ssd.lock);
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;if (qxl-&gt;ssd.cursor) {
+&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; // other thread
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;cursor_unref(qxl-&gt;ssd.cursor);
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;}
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;qxl-&gt;ssd.cursor = c;
diff --git a/ui/console.c b/ui/console.c
index 43226c5c14..31dbd8fc6f 100644
--- a/ui/console.c
+++ b/ui/console.c
@@ -985,8 +985,10 @@ void dpy_cursor_define(QemuConsole *c, QEMUCursor *cursor)
&nbsp; &nbsp; &nbsp;DisplayState *s = c-&gt;ds;
&nbsp; &nbsp; &nbsp;DisplayChangeListener *dcl;
&nbsp;
+&nbsp; &nbsp; //lock, main thread
&nbsp; &nbsp; &nbsp;cursor_unref(con-&gt;cursor);
&nbsp; &nbsp; &nbsp;con-&gt;cursor = cursor_ref(cursor);
+&nbsp; &nbsp; //unlock
&nbsp; &nbsp; &nbsp;if (!qemu_console_is_visible(c)) {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;return;
&nbsp; &nbsp; &nbsp;}





------------------&nbsp;ԭʼÓʼþ&nbsp;------------------
·¢¼þÈË:                                                                                                                        "Marc-Andr¨¦ Lureau"                                                                                    <marcandre.lureau@redhat.com&gt;;
·¢ËÍʱ¼ä:&nbsp;2024Äê4ÔÂ10ÈÕ(ÐÇÆÚÈý) ÍíÉÏ9:24
ÊÕ¼þÈË:&nbsp;"©glym"<707242047@qq.com&gt;;
³­ËÍ:&nbsp;"qemu-devel"<qemu-devel@nongnu.org&gt;;"kraxel"<kraxel@redhat.com&gt;;
Ö÷Ìâ:&nbsp;Re: [PATCH RFC v1]display: fix heap use after free in cursor_put



Hi

On Wed, Apr 10, 2024 at 2:066§2PM ©glym <707242047@qq.com&gt; wrote:
&gt;
&gt;

Please send the patch as inline:
https://www.qemu.org/docs/master/devel/submitting-a-patch.html#do-not-send-as-an-attachment

The patch is doing too much changes to the ssd.lock usage without
explaining in detail which race and how it solved it.

In particular, ui/spice-display.c usage seems safer before your
change, since it takes the lock on display_refresh and
display_mouse_define. It properly temporarily releases the lock before
calling the dpy_mouse_set() and dpy_cursor_define() as well.

To me, it looks like the only offender is qxl_spice_reset_cursor(),
which lacks locking before unrefing.

Could you confirm this hypothesis if you are able to reproduce the issue?

thanks

[-- Attachment #2: Type: text/html, Size: 4285 bytes --]

      reply	other threads:[~2024-04-11  1:57 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <tencent_BE1012EC266132443B1FA040EF8A60D1EC0A@qq.com>
2024-04-10 13:24 ` [PATCH RFC v1]display: fix heap use after free in cursor_put Marc-André Lureau
2024-04-11  1:55   ` =?gb18030?B?qWdseW0=?= [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=tencent_EC82468ED075970213367AE7801FBA4C0405@qq.com \
    --to=707242047@qq.com \
    --cc=kraxel@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=qemu-devel@nongnu.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;
as well as URLs for NNTP newsgroup(s).