linux-kernel - Re: Re: [PATCH] dev/parport: fix the array out-of-bounds risk

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: <2024070503-concert-mummify-dcbf@gregkh>
Date: Fri, 5 Jul 2024 08:45:45 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: tuhaowen <tuhaowen@...ontech.com>
Cc: alexander.deucher@....com, huangbibo@...ontech.com,
	linux-kernel@...r.kernel.org, sudipm.mukherjee@...il.com,
	wangyuli@...ontech.com
Subject: Re: Re: [PATCH] dev/parport: fix the array out-of-bounds risk

On Fri, Jul 05, 2024 at 02:36:58PM +0800, tuhaowen wrote:
> On Thu, Jul 04, 2024 at 06:07:47PM +0800, Greg Kroah-Hartman wrote:
> 
> > Usually because no one actually has this hardware anymore :)
> > 
> > Can you also properly test the buffer size when writing into it so that
> > even if the math is incorrect, it will not overflow?
> 
> 
> As of now, I have encountered these three devices: BUNET BU1L02,
> EB-LINK EB-2C1B01, and SYBA FG-EMT03A-N. When these PCIe to parallel
> port cards are installed, the system experiences abnormal reboots.
> I am not sure if there are other devices with these issues.
> 
> Below is the stack trace I encountered during the actual issue:
> 
> [ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:
> Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport]
> [ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:
> QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2
> [ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp
> [ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun
> PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024
> [ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:
> [ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0
> [ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20
> [ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c
> [ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc
> [ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38
> [ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport]
> 
> 
> The array buffer size is 20 bytes.
> When executing code in a 64-bit CPU environment,
> up to 44 bytes of data will be written into this array
> (the size of "%lu\t%lu\n" is 21 + 1 + 21 + 1).
> 
> This modification will resolve the current issue without introducing new problems.

I'm not disputing that this change looks correct, I'm asking that you
redo it and properly check the array size when writing to it so as to
ensure that it really is correct in case our math is incorrect
somewhere.

thanks,

greg k-h