[<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