linux-kernel - linux framebuffer ioctls

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

Message-ID: <71a0d6ff0608240548l4a6a3352r6428cf6672a81b64@mail.gmail.com>
Date:	Thu, 24 Aug 2006 16:48:39 +0400
From:	"Alexander Shishkin" <alexander.shishckin@...il.com>
To:	LKML <linux-kernel@...r.kernel.org>
Subject: linux framebuffer ioctls

Hi,

I've just stumbled upon a funny issue regarding FBIOGET_FSCREENINFO
ioctl command. What it does is filling in a structure called
fb_fix_screeninfo (fb.h) and passes it to userspace. Now the problem
is that if you run 32-bit userspace with a 64-bit kernel, you have
problems because of 2 unsigned long fields in the abovementioned
structure:

 unsigned long smem_start; /* Start of frame buffer mem */
 ...
 unsigned long mmio_start; /* Start of Memory Mapped I/O */

Most of the structure fields that follow smem_start get screwed from
32-bit userspace point.
I take it that applications somehow make use of these fields (at least
kdrive's fbdev does, from what I see).
Now the question is, how do we get around this situation?

-- 
I am free of all prejudices. I hate every one equally.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/