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/userspace-api/media/intro.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/userspace-api/media/intro.rst')
| -rw-r--r-- | Documentation/userspace-api/media/intro.rst | 46 |
1 files changed, 46 insertions, 0 deletions
diff --git a/Documentation/userspace-api/media/intro.rst b/Documentation/userspace-api/media/intro.rst new file mode 100644 index 000000000..4a6bd665b --- /dev/null +++ b/Documentation/userspace-api/media/intro.rst @@ -0,0 +1,46 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============ +Introduction +============ + +This document covers the Linux Kernel to Userspace API's used by video +and radio streaming devices, including video cameras, analog and digital +TV receiver cards, AM/FM receiver cards, Software Defined Radio (SDR), +streaming capture and output devices, codec devices and remote controllers. + +A typical media device hardware is shown at :ref:`typical_media_device`. + +.. _typical_media_device: + +.. kernel-figure:: typical_media_device.svg + :alt: typical_media_device.svg + :align: center + + Typical Media Device + +The media infrastructure API was designed to control such devices. It is +divided into five parts. + +1. The :ref:`first part <v4l2spec>` covers radio, video capture and output, + cameras, analog TV devices and codecs. + +2. The :ref:`second part <dvbapi>` covers the API used for digital TV and + Internet reception via one of the several digital tv standards. While it is + called as DVB API, in fact it covers several different video standards + including DVB-T/T2, DVB-S/S2, DVB-C, ATSC, ISDB-T, ISDB-S, DTMB, etc. The + complete list of supported standards can be found at + :c:type:`fe_delivery_system`. + +3. The :ref:`third part <remote_controllers>` covers the Remote Controller API. + +4. The :ref:`fourth part <media_controller>` covers the Media Controller API. + +5. The :ref:`fifth part <cec>` covers the CEC (Consumer Electronics Control) API. + +It should also be noted that a media device may also have audio components, like +mixers, PCM capture, PCM playback, etc, which are controlled via ALSA API. For +additional information and for the latest development code, see: +`https://linuxtv.org <https://linuxtv.org>`__. For discussing improvements, +reporting troubles, sending new drivers, etc, please mail to: `Linux Media +Mailing List (LMML) <http://vger.kernel.org/vger-lists.html#linux-media>`__. |
