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: <AMgA9QAeJpb138vn*G9h8qoW.3.1764849805322.Hmail.2200013188@stu.pku.edu.cn>
Date: Thu, 4 Dec 2025 20:03:25 +0800 (GMT+08:00)
From: 李天宇 <2200013188@....pku.edu.cn>
To: Ian Abbott <abbotti@....co.uk>, 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

Hi Ian,

Thank you very much for the analysis and your helpful suggestions.

Following your hint, I performed additional experiments by modifying the I/O base address passed through COMEDI_DEVCONFIG. The results are quite interesting:

	- Using 0x100, 0x200, or 0x300 as the base address consistently triggers a kernel panic (page fault in subdev_8255_io).
	- Removing the value entirely from the options array avoids the crash (I/O port conflict remains).
	- Using 0x400 also does *not* trigger the issue.

This seems to support your point that certain I/O port ranges may be problematic, and the fault is not solely caused by the conversion from negative values to an unsigned address. Instead, it may indeed be related to specific port regions conflicting or being unmapped during device initialization.

At this point, I am not sufficiently familiar with the driver internals to confidently determine whether this behavior is expected or if it should be considered a bug. Given the reproducibility and the fact that unvalidated base addresses can lead to a direct page fault, I would like to ask:

Do you think this should be treated as a bug in the 8255 driver, possibly requiring additional validation or rejection of unsupported I/O port ranges? If so, I would be happy to continue testing or assist in any way, but further guidance from someone experienced with this driver would be greatly appreciated.

Thanks again for your time and insights.

Best regards.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ