In the Linux kernel, the following vulnerability has been resolved: riscv: fix oops caused by irqsoff latency tracer 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.

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2025-988860 advisory.

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

    riscv: fix oops caused by irqsoff latency tracer

    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.

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2025-987237 advisory.

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

    riscv: fix oops caused by irqsoff latency tracer

    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.

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - In the Linux kernel, the following vulnerability has been resolved: riscv: fix oops caused by irqsoff     latency tracer 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.
    (CVE-2022-48922)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Severity
273824	Unity Linux 20.1070a Security Update: kernel (UTSA-2025-988860)	Nessus	Unity Linux Local Security Checks	medium
268408	Unity Linux 20.1070e Security Update: kernel (UTSA-2025-987237)	Nessus	Unity Linux Local Security Checks	medium
243884	Linux Distros Unpatched Vulnerability : CVE-2022-48922	Nessus	Misc.	medium

Detections

Analytics

CVE-2022-48922

medium

Tenable Plugins

medium

medium

medium