linux-kernel - Re: [BUG] Drivers/8255: Page fault in comedi

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: <22bbe97e-db08-481b-96d0-eb1d12227083@mev.co.uk>
Date: Wed, 3 Dec 2025 13:08:06 +0000
From: Ian Abbott <abbotti@....co.uk>
To: 李天宇 <2200013188@....pku.edu.cn>,
 linux-kernel <linux-kernel@...r.kernel.org>
Cc: hsweeten <hsweeten@...ionengravers.com>,
 xujiakai2025 <xujiakai2025@...as.ac.cn>,
 "zhaoruilin22@...ls.ucas.ac.cn" <zhaoruilin22@...ls.ucas.ac.cn>
Subject: Re: [BUG] Drivers/8255: Page fault in comedi_8255.c

On 29/11/2025 13:19, 李天宇 wrote:
> Hi,
> 
> There’s a bug in the comedi_8255.c file, specifically related to a page fault. This issue occurs when an illegal address is passed as a parameter to outb() function at line 47. This illegal address is subsequently used in asm code, leading to a page fault when trying to write to -0x70(%rsi).
> 
> The bug was initially discovered via a fuzzing framework on Linux kernel version 6.18-rc6, and it was later found reproducible on Linux kernel version 6.18-rc7.
> 
> After analyzing the calling stack, I suspect that the root cause may lie in the dev_8255_attach function. Specifically, at 8255.c:70, when reading iobase from it-&gt;options[i], there seems to be no validation for the conversion from int to unsigned long. If a negative value is encountered, it is cast to an illegally large number (e.g., 0xffff…), which may be causing the issue.

There is validation by request_region(), which is the reason for the 
reported I/O port conflicts.

Admittedly, the 8255 driver should probably reject any specified I/O 
port addresses that are not aligned on 4 byte boundaries to match the 
register decoding of the 8255 chip, but I don't think that's the problem 
here.

> 
> I’m not entirely confident in this analysis, but fortunately, there’s enough information provided for your reference:
> 
> 	Kernel Source: https://git.kernel.org/torvalds/t/linux-6.18-rc7.tar.gz
> 	Configuration: https://github.com/j1akai/KConfigFuzz_bug/raw/refs/heads/main/x86/mainline-config
> 	Reproducible Code: https://github.com/Wxm-233/KConfigFuzz_crashes/raw/refs/heads/main/405536bde2d1b503f3903a2a3de2d6dd94cef0a3/repro.cprog
>          GCC Info: https://github.com/Wxm-233/KConfigFuzz_crashes/raw/refs/heads/main/405536bde2d1b503f3903a2a3de2d6dd94cef0a3/gccinfo
> 	Kernel Log(First found): https://github.com/Wxm-233/KConfigFuzz_crashes/raw/refs/heads/main/405536bde2d1b503f3903a2a3de2d6dd94cef0a3/report0
> 	Kernel Log(Later Repro): https://github.com/Wxm-233/KConfigFuzz_crashes/raw/refs/heads/main/405536bde2d1b503f3903a2a3de2d6dd94cef0a3/report
> 
> I hope this information is helpful in identifying and resolving the issue. Thanks for your time and attention.
> 

Looking at the list of I/O base addresses that "repro.c" is using and 
the I/O port conflict messages in the "Later Repro" report, it seems 
happy enough until it tries to set up an 8255 subdevice at I/O port base 
address 0x100.  I don't know if there is any actual (or virtual) 
hardware at that base address that may be causing problems. 
Historically, IBM PS/2 systems had a set of Programmable Option Select 
registers at that address.

-- 
-=( Ian Abbott <abbotti@....co.uk> || MEV Ltd. is a company  )=-
-=( registered in England & Wales.  Regd. number: 02862268.  )=-
-=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=-
-=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-