linux-kernel - Re: reproducible GPF error in native_tss_update_io

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: <57af7a02-c765-409d-a04c-bf74e747f8b6@intel.com>
Date: Tue, 7 Jan 2025 13:28:12 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: reveliofuzzing <reveliofuzzing@...il.com>, tglx@...utronix.de,
 mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com,
 kirill.shutemov@...ux.intel.com
Cc: x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: reproducible GPF error in native_tss_update_io_bitmap

On 1/6/25 18:32, reveliofuzzing wrote:
> Hello,
> 
> We found the following general protection fault bug in Linux kernel 6.12, and
> it can be reproduced stably in a QEMU VM. To our knowledge, this problem has not
> been observed by SyzBot so we would like to report it for your reference.
> 
> - dmesg
> syzkaller login: [   90.849309] Oops: general protection fault,
> probably for non-canonical address 0xdffffc0000000000: 0000 [#1]
> PREEMPTI
> [   90.853735] KASAN: null-ptr-deref in range
> [0x0000000000000000-0x0000000000000007]
> [   90.856772] CPU: 0 PID: 3265 Comm: iou-sqp-3264 Not tainted 6.10.0 #2
> [   90.859386] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.13.0-1ubuntu1.1 04/01/2014
> [   90.862774] RIP: 0010:native_tss_update_io_bitmap+0x143/0x510

The whole thing looks like an issue in the failure path when trying to
create an io_uring io worker thread. It's probably some confusion in
treating the worker thread like a userspace thread with an io bitmap
when the worker thread doesn't have one.

It's _probably_ only reproducible with io_uring. It's arguable whether
it's likely an x86 issue or an io_uring issue.

In any case, running:

	scripts/decode_stacktrace.sh

and providing a full vmlinux might be helpful if folks want to dig into
this more.