linux-cve-announce - CVE-2022-50647: RISC-V: Make port I/O string accessors actually work

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>] [day] [month] [year] [list]
Message-ID: <2025120937-CVE-2022-50647-cb33@gregkh>
Date: Tue,  9 Dec 2025 09:01:48 +0900
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2022-50647: RISC-V: Make port I/O string accessors actually work

From: Greg Kroah-Hartman <gregkh@...nel.org>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

RISC-V: Make port I/O string accessors actually work

Fix port I/O string accessors such as `insb', `outsb', etc. which use
the physical PCI port I/O address rather than the corresponding memory
mapping to get at the requested location, which in turn breaks at least
accesses made by our parport driver to a PCIe parallel port such as:

PCI parallel port detected: 1415:c118, I/O at 0x1000(0x1008), IRQ 20
parport0: PC-style at 0x1000 (0x1008), irq 20, using FIFO [PCSPP,TRISTATE,COMPAT,EPP,ECP]

causing a memory access fault:

Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000001008
Oops [#1]
Modules linked in:
CPU: 1 PID: 350 Comm: cat Not tainted 6.0.0-rc2-00283-g10d4879f9ef0-dirty #23
Hardware name: SiFive HiFive Unmatched A00 (DT)
epc : parport_pc_fifo_write_block_pio+0x266/0x416
 ra : parport_pc_fifo_write_block_pio+0xb4/0x416
epc : ffffffff80542c3e ra : ffffffff80542a8c sp : ffffffd88899fc60
 gp : ffffffff80fa2700 tp : ffffffd882b1e900 t0 : ffffffd883d0b000
 t1 : ffffffffff000002 t2 : 4646393043330a38 s0 : ffffffd88899fcf0
 s1 : 0000000000001000 a0 : 0000000000000010 a1 : 0000000000000000
 a2 : ffffffd883d0a010 a3 : 0000000000000023 a4 : 00000000ffff8fbb
 a5 : ffffffd883d0a001 a6 : 0000000100000000 a7 : ffffffc800000000
 s2 : ffffffffff000002 s3 : ffffffff80d28880 s4 : ffffffff80fa1f50
 s5 : 0000000000001008 s6 : 0000000000000008 s7 : ffffffd883d0a000
 s8 : 0004000000000000 s9 : ffffffff80dc1d80 s10: ffffffd8807e4000
 s11: 0000000000000000 t3 : 00000000000000ff t4 : 393044410a303930
 t5 : 0000000000001000 t6 : 0000000000040000
status: 0000000200000120 badaddr: 0000000000001008 cause: 000000000000000f
[<ffffffff80543212>] parport_pc_compat_write_block_pio+0xfe/0x200
[<ffffffff8053bbc0>] parport_write+0x46/0xf8
[<ffffffff8050530e>] lp_write+0x158/0x2d2
[<ffffffff80185716>] vfs_write+0x8e/0x2c2
[<ffffffff80185a74>] ksys_write+0x52/0xc2
[<ffffffff80185af2>] sys_write+0xe/0x16
[<ffffffff80003770>] ret_from_syscall+0x0/0x2
---[ end trace 0000000000000000 ]---

For simplicity address the problem by adding PCI_IOBASE to the physical
address requested in the respective wrapper macros only, observing that
the raw accessors such as `__insb', `__outsb', etc. are not supposed to
be used other than by said macros.  Remove the cast to `long' that is no
longer needed on `addr' now that it is used as an offset from PCI_IOBASE
and add parentheses around `addr' needed for predictable evaluation in
macro expansion.  No need to make said adjustments in separate changes
given that current code is gravely broken and does not ever work.

The Linux kernel CVE team has assigned CVE-2022-50647 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 4.15 with commit fab957c11efe2f405e08b9f0d080524bc2631428 and fixed in 5.4.220 with commit 2c60db6869fe5213471fcf4fe5704dc29da8b5ee
	Issue introduced in 4.15 with commit fab957c11efe2f405e08b9f0d080524bc2631428 and fixed in 5.10.150 with commit 2ce9fab94b8db61f014e43ddf80dd1524ae6dff4
	Issue introduced in 4.15 with commit fab957c11efe2f405e08b9f0d080524bc2631428 and fixed in 5.15.75 with commit dc235db7b79a352d07d62e8757ad856dbf1564c1
	Issue introduced in 4.15 with commit fab957c11efe2f405e08b9f0d080524bc2631428 and fixed in 5.19.17 with commit 140b2b92dbefffa7f4f7211a1fd399a6e79e71c4
	Issue introduced in 4.15 with commit fab957c11efe2f405e08b9f0d080524bc2631428 and fixed in 6.0.3 with commit 1acee4616930fc07265cb8e539753a8062daa8e0
	Issue introduced in 4.15 with commit fab957c11efe2f405e08b9f0d080524bc2631428 and fixed in 6.1 with commit 9cc205e3c17d5716da7ebb7fa0c985555e95d009

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2022-50647
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	arch/riscv/include/asm/io.h


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/2c60db6869fe5213471fcf4fe5704dc29da8b5ee
	https://git.kernel.org/stable/c/2ce9fab94b8db61f014e43ddf80dd1524ae6dff4
	https://git.kernel.org/stable/c/dc235db7b79a352d07d62e8757ad856dbf1564c1
	https://git.kernel.org/stable/c/140b2b92dbefffa7f4f7211a1fd399a6e79e71c4
	https://git.kernel.org/stable/c/1acee4616930fc07265cb8e539753a8062daa8e0
	https://git.kernel.org/stable/c/9cc205e3c17d5716da7ebb7fa0c985555e95d009