linux-kernel - Re: [v2] serial_core:recognize invalid pointer from userspace

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]

Date:	Thu, 10 Mar 2016 13:46:47 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	"Lu.Jiang" <lu.jiang@...driver.com>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	<linux-kernel@...r.kernel.org>, <linux-serial@...r.kernel.org>
Subject: Re: [v2] serial_core:recognize invalid pointer from userspace

> When userspace get setting with TIOCGSERIAL,
> 
> 1.On 64bit kernel + 32bit rootfs, compat ioctl code use 0xffffffff to 
> mark invalid conversion.

Start at the beginning. What is being passed back and forth that causes
the problem. What memory address does your uart have ?

> 2.On 32bit kernel with 64bit physical address, uart_get_info() in 
> serial_core will truncate a 64bit address into 32bit pointer with 
> following code:
>      retinfo->iomem_base      = (void *)(unsigned long)uport->mapbase;
> 
> Then when setting with TIOCSSERIAL ioctl, application can not provide 
> original value for iomem_base, it leads setserial can not work on such 
> boards.

Yes - it's a legacy feature that isn't really needed on 64bit systems.

> I don't know why kernel should expose this value to userspace, and seems 
> no need for userspace application to update an physical address for driver.
> Can we consider drop this member in handle for TIOCSSERIAL ioctl. Please 
> see a rough patch in attachment.

There are old PC and embedded cases from the time before devicetree and
ACPI were the default. It's now an API people rely upon.

It would make sense I think to return 0 for the base address if it
exceeds 32bits, and also to ignore a TIOCSSERIAL that passes 0 as the
address back. Would that fix your use case ?

Alan