linux-kernel - Re: CVE-2023-53283: xen/virtio: Fix NULL deref when a bridge of PCI root bus has no parent

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <af378199-d525-4358-a2b5-0e5393756ff1@suse.com>
Date: Tue, 16 Sep 2025 10:51:51 +0200
From: Jürgen Groß <jgross@...e.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: cve@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: CVE-2023-53283: xen/virtio: Fix NULL deref when a bridge of PCI
 root bus has no parent

On 16.09.25 10:36, Greg KH wrote:
> On Tue, Sep 16, 2025 at 10:29:26AM +0200, Juergen Gross wrote:
>> On 16.09.25 10:11, Greg Kroah-Hartman wrote:
>>> From: Greg Kroah-Hartman <gregkh@...nel.org>
>>>
>>> Description
>>> ===========
>>>
>>> In the Linux kernel, the following vulnerability has been resolved:
>>>
>>> xen/virtio: Fix NULL deref when a bridge of PCI root bus has no parent
>>>
>>> When attempting to run Xen on a QEMU/KVM virtual machine with virtio
>>> devices (all x86_64), function xen_dt_get_node() crashes on accessing
>>> bus->bridge->parent->of_node because a bridge of the PCI root bus has no
>>> parent set:
>>>
>>> [    1.694192][    T1] BUG: kernel NULL pointer dereference, address: 0000000000000288
>>> [    1.695688][    T1] #PF: supervisor read access in kernel mode
>>> [    1.696297][    T1] #PF: error_code(0x0000) - not-present page
>>> [    1.696297][    T1] PGD 0 P4D 0
>>> [    1.696297][    T1] Oops: 0000 [#1] PREEMPT SMP NOPTI
>>> [    1.696297][    T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.3.7-1-default #1 openSUSE Tumbleweed a577eae57964bb7e83477b5a5645a1781df990f0
>>> [    1.696297][    T1] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014
>>> [    1.696297][    T1] RIP: e030:xen_virtio_restricted_mem_acc+0xd9/0x1c0
>>> [    1.696297][    T1] Code: 45 0c 83 e8 c9 a3 ea ff 31 c0 eb d7 48 8b 87 40 ff ff ff 48 89 c2 48 8b 40 10 48 85 c0 75 f4 48 8b 82 10 01 00 00 48 8b 40 40 <48> 83 b8 88 02 00 00 00 0f 84 45 ff ff ff 66 90 31 c0 eb a5 48 89
>>> [    1.696297][    T1] RSP: e02b:ffffc90040013cc8 EFLAGS: 00010246
>>> [    1.696297][    T1] RAX: 0000000000000000 RBX: ffff888006c75000 RCX: 0000000000000029
>>> [    1.696297][    T1] RDX: ffff888005ed1000 RSI: ffffc900400f100c RDI: ffff888005ee30d0
>>> [    1.696297][    T1] RBP: ffff888006c75010 R08: 0000000000000001 R09: 0000000330000006
>>> [    1.696297][    T1] R10: ffff888005850028 R11: 0000000000000002 R12: ffffffff830439a0
>>> [    1.696297][    T1] R13: 0000000000000000 R14: ffff888005657900 R15: ffff888006e3e1e8
>>> [    1.696297][    T1] FS:  0000000000000000(0000) GS:ffff88804a000000(0000) knlGS:0000000000000000
>>> [    1.696297][    T1] CS:  e030 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> [    1.696297][    T1] CR2: 0000000000000288 CR3: 0000000002e36000 CR4: 0000000000050660
>>> [    1.696297][    T1] Call Trace:
>>> [    1.696297][    T1]  <TASK>
>>> [    1.696297][    T1]  virtio_features_ok+0x1b/0xd0
>>> [    1.696297][    T1]  virtio_dev_probe+0x19c/0x270
>>> [    1.696297][    T1]  really_probe+0x19b/0x3e0
>>> [    1.696297][    T1]  __driver_probe_device+0x78/0x160
>>> [    1.696297][    T1]  driver_probe_device+0x1f/0x90
>>> [    1.696297][    T1]  __driver_attach+0xd2/0x1c0
>>> [    1.696297][    T1]  bus_for_each_dev+0x74/0xc0
>>> [    1.696297][    T1]  bus_add_driver+0x116/0x220
>>> [    1.696297][    T1]  driver_register+0x59/0x100
>>> [    1.696297][    T1]  virtio_console_init+0x7f/0x110
>>> [    1.696297][    T1]  do_one_initcall+0x47/0x220
>>> [    1.696297][    T1]  kernel_init_freeable+0x328/0x480
>>> [    1.696297][    T1]  kernel_init+0x1a/0x1c0
>>> [    1.696297][    T1]  ret_from_fork+0x29/0x50
>>> [    1.696297][    T1]  </TASK>
>>> [    1.696297][    T1] Modules linked in:
>>> [    1.696297][    T1] CR2: 0000000000000288
>>> [    1.696297][    T1] ---[ end trace 0000000000000000 ]---
>>>
>>> The PCI root bus is in this case created from ACPI description via
>>> acpi_pci_root_add() -> pci_acpi_scan_root() -> acpi_pci_root_create() ->
>>> pci_create_root_bus() where the last function is called with
>>> parent=NULL. It indicates that no parent is present and then
>>> bus->bridge->parent is NULL too.
>>>
>>> Fix the problem by checking bus->bridge->parent in xen_dt_get_node() for
>>> NULL first.
>>>
>>> The Linux kernel CVE team has assigned CVE-2023-53283 to this issue.
>>
>> Please revoke this CVE. There is no way an unprivileged user could trigger
>> this issue.
> 
> Normal users can't spin up qemu instances?  How does someone "start Xen"
> like this?  I thought any user could do that, or is this restricted to
> only root users somehow?  And if "somehow", what is that?

This crash has been observed when running Xen inside a KVM guest. The crash
happened in the dom0 of that Xen instance. So anyone being capable to start
this KVM guest is able to cause this crash, but the same person can just
terminate the KVM guest causing the same "damage". I don't think someone
controlling the KVM guest can be called "unprivileged" regarding the guest.


Juergen

Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3684 bytes)

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (496 bytes)