riscv: fix oops caused by irqsoff latency tracer
Published Aug 22, 2024
5.5
MEDIUMCVSS 3.1
EPSS 0.21%
Description
The trace_hardirqs_{on,off}() require the caller to setup frame pointer properly. This because these two functions use macro 'CALLER_ADDR1' (aka. __builtin_return_address(1)) to acquire caller info. If the $fp is used for other purpose, the code generated this macro (as below) could trigger memory access fault.
0xffffffff8011510e <+80>: ld a1,-16(s0) 0xffffffff80115112 <+84>: ld s2,-8(a1) # <-- paging fault here
The oops message during booting if compiled with 'irqoff' tracer enabled: [ 0.039615][ T0] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8 [ 0.041925][ T0] Oops [#1] [ 0.042063][ T0] Modules linked in: [ 0.042864][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.17.0-rc1-00233-g9a20c48d1ed2 #29 [ 0.043568][ T0] Hardware name: riscv-virtio,qemu (DT) [ 0.044343][ T0] epc : trace_hardirqs_on+0x56/0xe2 [ 0.044601][ T0] ra : restore_all+0x12/0x6e [ 0.044721][ T0] epc : ffffffff80126a5c ra : ffffffff80003b94 sp : ffffffff81403db0 [ 0.044801][ T0] gp : ffffffff8163acd8 tp : ffffffff81414880 t0 : 0000000000000020 [ 0.044882][ T0] t1 : 0098968000000000 t2 : 0000000000000000 s0 : ffffffff81403de0 [ 0.044967][ T0] s1 : 0000000000000000 a0 : 0000000000000001 a1 : 0000000000000100 [ 0.045046][ T0] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000 [ 0.045124][ T0] a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000054494d45 [ 0.045210][ T0] s2 : ffffffff80003b94 s3 : ffffffff81a8f1b0 s4 : ffffffff80e27b50 [ 0.045289][ T0] s5 : ffffffff81414880 s6 : ffffffff8160fa00 s7 : 00000000800120e8 [ 0.045389][ T0] s8 : 0000000080013100 s9 : 000000000000007f s10: 0000000000000000 [ 0.045474][ T0] s11: 0000000000000000 t3 : 7fffffffffffffff t4 : 0000000000000000 [ 0.045548][ T0] t5 : 0000000000000000 t6 : ffffffff814aa368 [ 0.045620][ T0] status: 0000000200000100 badaddr: 00000000000000f8 cause: 000000000000000d [ 0.046402][ T0] [<ffffffff80003b94>] restore_all+0x12/0x6e
This because the $fp(aka. $s0) register is not used as frame pointer in the assembly entry code.
resume_kernel: REG_L s0, TASK_TI_PREEMPT_COUNT(tp) bnez s0, restore_all REG_L s0, TASK_TI_FLAGS(tp) andi s0, s0, _TIF_NEED_RESCHED beqz s0, restore_all call preempt_schedule_irq j restore_all
To fix above issue, here we add one extra level wrapper for function trace_hardirqs_{on,off}() so they can be safely called by low level entry code.
Affected products
-
- Version 3c4697982982StatusaffectedConstraints<1851b9a46706
- Version 3c4697982982StatusaffectedConstraints<22e2100b1b07
- Version 3c4697982982StatusaffectedConstraints<9e2dbc31e367
- Version 3c4697982982StatusaffectedConstraints<b5e180490db4
- Version
-
- Version 5.9StatusaffectedConstraints-
- Version 0StatusunaffectedConstraints<5.9
- Version 5.10.103StatusunaffectedConstraints<=5.10.*
- Version 5.15.26StatusunaffectedConstraints<=5.15.*
- Version 5.16.12StatusunaffectedConstraints<=5.16.*
- Version 5.17StatusunaffectedConstraints<=*
- Version
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | |||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Linux | Linux | unaffected |
| |||||||||||||||||||||
| Linux | Linux | affected |
|
- ≥ 5.9 · < 5.10.103
- ≥ 5.11 · < 5.15.26
- ≥ 5.16 · < 5.16.12
- 5.17
- 5.17
- 5.17
- 5.17
- 5.17
No data.
Red Hat Enterprise Linux 6
kernel
Not affected
Red Hat Enterprise Linux 7
kernel
Not affected
Red Hat Enterprise Linux 7
kernel-rt
Not affected
Red Hat Enterprise Linux 8
kernel
Not affected
Red Hat Enterprise Linux 8
kernel-rt
Not affected
Red Hat Enterprise Linux 9
kernel
Not affected
Red Hat Enterprise Linux 9
kernel-rt
Not affected
| Product | Package | State | Advisory |
|---|---|---|---|
| Red Hat Enterprise Linux 6 | kernel | Not affected | n/a |
| Red Hat Enterprise Linux 7 | kernel | Not affected | n/a |
| Red Hat Enterprise Linux 7 | kernel-rt | Not affected | n/a |
| Red Hat Enterprise Linux 8 | kernel | Not affected | n/a |
| Red Hat Enterprise Linux 8 | kernel-rt | Not affected | n/a |
| Red Hat Enterprise Linux 9 | kernel | Not affected | n/a |
| Red Hat Enterprise Linux 9 | kernel-rt | Not affected | n/a |
No package ranges for this CVE.
Remediation
Red Hat statement
Red Hat Enterprise Linux is not vulnerable to this CVE, as it does not affect the versions or configurations of the Linux Kernel used in its distributions.
Red Hat mitigation
Mitigation for this issue is ei ther not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
References (9)
- https://access.redhat.com/security/cve/CVE-2022-48922 Vendor Advisory
- https://bugzilla.redhat.com/show_bug.cgi?id=2307175 Issue Tracking
- https://git.kernel.org/stable/c/1851b9a467065b18ec2cba156eea345206df1c8f Patch
- https://git.kernel.org/stable/c/22e2100b1b07d6f5acc71cc1acb53f680c677d77 Patch
- https://git.kernel.org/stable/c/9e2dbc31e367d08ee299a0d8aeb498cb2e12a1c3 Patch
- https://git.kernel.org/stable/c/b5e180490db4af8c0f80c4b65ee482d333d0e8ee Patch
- https://lore.kernel.org/linux-cve-announce/2024082219-CVE-2022-48922-be4d@gregkh/T
- https://nvd.nist.gov/vuln/detail/CVE-2022-48922
- https://www.cve.org/CVERecord?id=CVE-2022-48922
Change history (0)
No recorded changes yet.