linux-kernel - Re: [PATCH] fbmem: Fix fb_read, fb

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] [day] [month] [year] [list]

Date:	Wed, 22 Sep 2010 01:00:19 +0100
From:	James Hogan <james@...anarts.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	sparclinux@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-fbdev@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>,
	Dave Airlie <airlied@...hat.com>,
	Marcin Slusarz <marcin.slusarz@...il.com>,
	Florian Tobias Schandinat <FlorianSchandinat@....de>,
	Denys Vlasenko <vda.linux@...glemail.com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	James Simmons <jsimmons@...radead.org>
Subject: Re: [PATCH] fbmem: Fix fb_read, fb_write unaligned accesses.

On Wednesday 22 September 2010 00:19:50 Andrew Morton wrote:
> On Sat, 18 Sep 2010 01:23:47 +0100
> 
> James Hogan <james@...anarts.com> wrote:
> > Apologies for corrupted patch. I'll try again.
> > Comments? I'd also appreciate if somebody familiar with sbus on sparc
> > could check this patch is sane since I know virtually nothing about sbus
> > and am not in a position to compile for sparc, let alone test on it:
> > 
> > fb_{read,write} access the framebuffer using lots of fb_{read,write}l's
> > but don't check that the file position is aligned which can cause
> > problems on some architectures which do not support unaligned accesses.
> 
> What are these "problems"?

On the arch I hit this on (which isn't in tree) I experienced a fault at the 
point of the unaligned write in kernel code, but this is only because 
unaligned access checking is switched on which isn't always possible 
(otherwise the write would have just silently failed/done something else). It 
terminated the program, but didn't cause any other problems.
Documentation/unaligned-memory-access.txt also mentions that some 
architectures raise exceptions that can't be worked around, or fail silently 
and may actually perform different writes to the one requested.

> I'd have thought they would be fairly fatal, in which case this is a
> high-priority patch.  But I'd also have thought that the problems would
> have been noted before now.

The common way to access the framebuffer is by mmapping it into userland, so I 
don't think the read/write syscalls are commonly used on it, and in any case 
colour data tends to be naturally aligned so unaligned writes would be 
uncommon.

> 
> So I assume that you're doing something which nobody has done before.
> 
> Confused.  Help?

The actualy case that hit this is admitedly rather silly. I did a quick test 
of the framebuffer by typing this at a shell:
yes > /dev/fb0
I'd have to check it again to see exactly how lots of 2 byte writes ("y\n") 
ended up unaligned, but at the point of the crash the dest pointer was 
definitely unaligned (the hex address ended in a 5) and the patch fixed it for 
me.

Hope that helps.

Cheers
James

Download attachment "signature.asc " of type "application/pgp-signature" (199 bytes)