linux-kernel - Re: [PATCH] x86: Fix off-by-one error in __access

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4d5abd25-57c1-4233-a34a-3167a114dcc8@maowtm.org>
Date: Tue, 26 Nov 2024 01:09:15 +0000
From: Tingmao Wang <m@...wtm.org>
To: Mikel Rychliski <mikel@...elr.com>, Thomas Gleixner <tglx@...utronix.de>,
 Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
 Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
 "H. Peter Anvin" <hpa@...or.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: Fix off-by-one error in __access_ok

Hi,

I hit an issue with using gdb (and eventually more) on a system with 9p 
as rootfs which I eventually root-caused to this, so I'm just posting 
here for reference / another testing datapoint, since I couldn't find 
any other mentions of this error elsewhere and this is in the latest 
stable kernel (6.12 / 6.12.1). Apologies in advance that I might not be 
offering much else useful, but I can confirm that applying this patch 
fixes it.

I'm running a development VM where the rootfs is a 9p mount, and from 
6.12 I get this if I try to debug anything with gdb:

[    6.258525][   T88] netfs: Couldn't get user pages (rc=-14)
[    6.259414][   T88] netfs: Zero-sized read [R=1ff3]
/bin/sh: error while loading shared libraries: 
/lib/x86_64-linux-gnu/libc.so.6: cannot read file data: Input/output error
During startup program exited with code 127.

After some further testing I realized that basically *everything* was 
broken (e.g. /bin/sh) if I disable ASLR (via 
/proc/sys/kernel/randomize_va_space), with the same messages printed. 
The user-space is a Debian distribution.

Basically I think the user-space initialisation tries to call read with 
(for example) buf=0x7fffffffdfc8 and count=832, so it spans the last two 
valid user-space pages, and the access_ok in gup_fast_fallback 
eventually fails (because somewhere above it rounds to whole pages).

I think this doesn't happen with a "normal" ext4 root (otherwise I would 
be surprised if nobody else has reported it yet) - it might just have 
been surfaced by recent v9fs changes.