All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-93098: rpmsg: glink: fix deadlock in endpoint destroy during driver detach
Date: Thu, 17 Sep 2026 17:16:15 +0100	[thread overview]
Message-ID: <2026091744-CVE-2026-93098-7ef4@gregkh> (raw)

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

rpmsg: glink: fix deadlock in endpoint destroy during driver detach

During driver detach, the device core holds the device mutex throughout
the driver's remove callback chain.  When the rpmsg endpoint is
destroyed as part of that teardown, the GLINK endpoint destroy
implementation attempts to unregister the underlying rpmsg device.
That unregistration calls device_del(), which tries to re-acquire the
same device mutex already held higher up the stack, causing rmmod to
hang indefinitely.

The deadlock manifests with the following call chain:

[<0>] device_del+0x44/0x414  <- tries to acquire same mutex
[<0>] device_unregister+0x18/0x34
[<0>] rpmsg_unregister_device+0x28/0x4c
[<0>] qcom_glink_remove_rpmsg_device+0x70/0xc0
[<0>] qcom_glink_destroy_ept+0x58/0xbc
[<0>] rpmsg_dev_remove+0x50/0x60
[<0>] device_remove+0x4c/0x80
[<0>] device_release_driver_internal+0x1cc/0x228  <- acquires device mutex
[<0>] driver_detach+0x4c/0x98
[<0>] bus_remove_driver+0x6c/0xbc
[<0>] driver_unregister+0x30/0x60
[<0>] unregister_rpmsg_driver+0x10/0x1c
[<0>] fastrpc_exit+0x28/0x38 [fastrpc]
[<0>] __arm64_sys_delete_module+0x1b8/0x294
[<0>] invoke_syscall+0x48/0x10c
[<0>] el0_svc_common.constprop.0+0xc0/0xe0
[<0>] do_el0_svc+0x1c/0x28
[<0>] el0_svc+0x34/0x108
[<0>] el0t_64_sync_handler+0xa0/0xe4
[<0>] el0t_64_sync+0x198/0x19c

The rpmsg device unregistration inside endpoint destroy is redundant.
In both contexts where endpoint destruction is triggered:

- Driver detach path: the driver core already tears down the rpmsg
  device.

- Channel close path: the rpmsg device is already unregistered before
  endpoint destruction is reached.

Remove the redundant unregistration to fix the deadlock.

The Linux kernel CVE team has assigned CVE-2026-93098 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 5.10.248 with commit 93b6b9e4acff4794e7426d3ad64ef14e3b3e8919 and fixed in 5.10.270 with commit 73092c2292aa65515671e54abbcda2166d3827ed
	Issue introduced in 5.15.198 with commit 24fd02c3a4798de7dc94b55d36a1685fe6cdaf69 and fixed in 5.15.221 with commit bbc236357876d35a624030e5c50eedbc380be98e
	Issue introduced in 6.1.160 with commit 32fe8cdf541863239b81c80b8b04112d6e8792cf and fixed in 6.1.188 with commit 8597f669a5268e0dcf243e2b2d6ca00370117057
	Issue introduced in 6.6.120 with commit c6210714347f72bae8e7142dc0a7f99923c466e7 and fixed in 6.6.157 with commit 48f55b90f0d713e477e26b85d7327d9592d016f9
	Issue introduced in 6.12.64 with commit fcab5c2672f8dac3d77013dbe047b2441f4141f5 and fixed in 6.12.110 with commit cbcdf96e1c87bc07055d04264018ded1f3bafffb
	Issue introduced in 6.18.3 with commit f80e4e91b010ee7d6c52f24d069975ac955ac6b2 and fixed in 6.18.52 with commit ecad679e2b92c419cc22cc8f257cd457d5192647
	Issue introduced in 6.19 with commit a53e356df548f6b0e82529ef3cc6070f42622189 and fixed in 7.2.6 with commit e559626bee8a6632aafc08eedcdb4bf26ca245c5
	Issue introduced in 6.19 with commit a53e356df548f6b0e82529ef3cc6070f42622189 and fixed in 7.3-rc1 with commit 5a5a48e788e02fd8a8eb7188ce440572d6c12418

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-93098
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	drivers/rpmsg/qcom_glink_native.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/73092c2292aa65515671e54abbcda2166d3827ed
	https://git.kernel.org/stable/c/bbc236357876d35a624030e5c50eedbc380be98e
	https://git.kernel.org/stable/c/8597f669a5268e0dcf243e2b2d6ca00370117057
	https://git.kernel.org/stable/c/48f55b90f0d713e477e26b85d7327d9592d016f9
	https://git.kernel.org/stable/c/cbcdf96e1c87bc07055d04264018ded1f3bafffb
	https://git.kernel.org/stable/c/ecad679e2b92c419cc22cc8f257cd457d5192647
	https://git.kernel.org/stable/c/e559626bee8a6632aafc08eedcdb4bf26ca245c5
	https://git.kernel.org/stable/c/5a5a48e788e02fd8a8eb7188ce440572d6c12418

                 reply	other threads:[~2026-09-17 16:36 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=2026091744-CVE-2026-93098-7ef4@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=cve@kernel.org \
    --cc=gregkh@kernel.org \
    --cc=linux-cve-announce@vger.kernel.org \
    --cc=linux-kernel@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 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.