diff options
| author | Ali Ahmet Memis <ali@iusegentoo.com> | 2026-08-21 01:45:27 +0000 |
|---|---|---|
| committer | Stafford Horne <shorne@gmail.com> | 2026-08-29 07:32:26 +0100 |
| commit | 78004e9a87f240df03e2f73120d291763c32e0a7 (patch) | |
| tree | 137c22dd795222931b9d2bf2501d37cd766741aa /Documentation/fb/pvr2fb.rst | |
| download | linux-stable-78004e9a87f240df03e2f73120d291763c32e0a7.tar.gz linux-stable-78004e9a87f240df03e2f73120d291763c32e0a7.zip | |
openrisc: fix arbitrary kernel memory access via or1k_atomic syscallgrafted
sys_or1k_atomic() (syscall 244 in the "or1k" ABI) takes two user
pointers, v1 and v2, and swaps the words they point to in hand-written
assembly.
l.lwz r29,0(r4)
l.lwz r27,0(r5)
l.sw 0(r4),r27
l.sw 0(r5),r29
The pointers are not checked with access_ok(). The four memory
accesses also have no exception table entries.
A caller passes a kernel address as either pointer, and the syscall
reads from and writes to it directly.
This gives an unprivileged process a kernel read/write primitive. It
overwrites kernel data such as the sys_call_table, gaining code
execution in kernel context.
Check both pointers before entering the critical section. Add fixups
for the four memory accesses so faults on valid but unmapped user
addresses return -EFAULT.
[shorne@gmail.com: fix comment style]
Fixes: 9d02a4283e9c ("OpenRISC: Boot code")
Cc: stable@vger.kernel.org
Signed-off-by: Ali Ahmet Memis <ali@iusegentoo.com>
Signed-off-by: Stafford Horne <shorne@gmail.com>
Diffstat (limited to 'Documentation/fb/pvr2fb.rst')
| -rw-r--r-- | Documentation/fb/pvr2fb.rst | 66 |
1 files changed, 66 insertions, 0 deletions
diff --git a/Documentation/fb/pvr2fb.rst b/Documentation/fb/pvr2fb.rst new file mode 100644 index 000000000..315ce085a --- /dev/null +++ b/Documentation/fb/pvr2fb.rst @@ -0,0 +1,66 @@ +=============================================== +pvr2fb - PowerVR 2 graphics frame buffer driver +=============================================== + +This is a driver for PowerVR 2 based graphics frame buffers, such as the +one found in the Dreamcast. + +Advantages: + + * It provides a nice large console (128 cols + 48 lines with 1024x768) + without using tiny, unreadable fonts (NOT on the Dreamcast) + * You can run XF86_FBDev on top of /dev/fb0 + * Most important: boot logo :-) + +Disadvantages: + + * Driver is largely untested on non-Dreamcast systems. + +Configuration +============= + +You can pass kernel command line options to pvr2fb with +`video=pvr2fb:option1,option2:value2,option3` (multiple options should be +separated by comma, values are separated from options by `:`). + +Accepted options: + +========== ================================================================== +font:X default font to use. All fonts are supported, including the + SUN12x22 font which is very nice at high resolutions. + + +mode:X default video mode with format [xres]x[yres]-<bpp>@<refresh rate> + The following video modes are supported: + 640x640-16@60, 640x480-24@60, 640x480-32@60. The Dreamcast + defaults to 640x480-16@60. At the time of writing the + 24bpp and 32bpp modes function poorly. Work to fix that is + ongoing + + Note: the 640x240 mode is currently broken, and should not be + used for any reason. It is only mentioned here as a reference. + +inverse invert colors on screen (for LCD displays) + +nomtrr disables write combining on frame buffer. This slows down driver + but there is reported minor incompatibility between GUS DMA and + XFree under high loads if write combining is enabled (sound + dropouts). MTRR is enabled by default on systems that have it + configured and that support it. + +cable:X cable type. This can be any of the following: vga, rgb, and + composite. If none is specified, we guess. + +output:X output type. This can be any of the following: pal, ntsc, and + vga. If none is specified, we guess. +========== ================================================================== + +X11 +=== + +XF86_FBDev has been shown to work on the Dreamcast in the past - though not yet +on any 2.6 series kernel. + +Paul Mundt <lethal@linuxdc.org> + +Updated by Adrian McMenamin <adrian@mcmen.demon.co.uk> |
