Linux Kernel up to 5.10.72/5.14.11 riscv denial of service

Summaryinfo

A vulnerability classified as critical has been found in Linux Kernel up to 5.10.72/5.14.11. The affected element is an unknown function of the component riscv. Performing a manipulation results in denial of service. This vulnerability is known as CVE-2021-47414. No exploit is available. It is recommended to upgrade the affected component.

Detailsinfo

A vulnerability was found in Linux Kernel up to 5.10.72/5.14.11. It has been classified as critical. This affects some unknown processing of the component riscv. The manipulation with an unknown input leads to a denial of service vulnerability. CWE is classifying the issue as CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use. This is going to have an impact on availability. The summary by CVE is:

In the Linux kernel, the following vulnerability has been resolved: riscv: Flush current cpu icache before other cpus On SiFive Unmatched, I recently fell onto the following BUG when booting: [ 0.000000] ftrace: allocating 36610 entries in 144 pages [ 0.000000] Oops - illegal instruction [#1] [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.13.1+ #5 [ 0.000000] Hardware name: SiFive HiFive Unmatched A00 (DT) [ 0.000000] epc : riscv_cpuid_to_hartid_mask+0x6/0xae [ 0.000000] ra : __sbi_rfence_v02+0xc8/0x10a [ 0.000000] epc : ffffffff80007240 ra : ffffffff80009964 sp : ffffffff81803e10 [ 0.000000] gp : ffffffff81a1ea70 tp : ffffffff8180f500 t0 : ffffffe07fe30000 [ 0.000000] t1 : 0000000000000004 t2 : 0000000000000000 s0 : ffffffff81803e60 [ 0.000000] s1 : 0000000000000000 a0 : ffffffff81a22238 a1 : ffffffff81803e10 [ 0.000000] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000 [ 0.000000] a5 : 0000000000000000 a6 : ffffffff8000989c a7 : 0000000052464e43 [ 0.000000] s2 : ffffffff81a220c8 s3 : 0000000000000000 s4 : 0000000000000000 [ 0.000000] s5 : 0000000000000000 s6 : 0000000200000100 s7 : 0000000000000001 [ 0.000000] s8 : ffffffe07fe04040 s9 : ffffffff81a22c80 s10: 0000000000001000 [ 0.000000] s11: 0000000000000004 t3 : 0000000000000001 t4 : 0000000000000008 [ 0.000000] t5 : ffffffcf04000808 t6 : ffffffe3ffddf188 [ 0.000000] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000002 [ 0.000000] [] riscv_cpuid_to_hartid_mask+0x6/0xae [ 0.000000] [] sbi_remote_fence_i+0x1e/0x26 [ 0.000000] [] flush_icache_all+0x12/0x1a [ 0.000000] [] patch_text_nosync+0x26/0x32 [ 0.000000] [] ftrace_init_nop+0x52/0x8c [ 0.000000] [] ftrace_process_locs.isra.0+0x29c/0x360 [ 0.000000] [] ftrace_init+0x80/0x130 [ 0.000000] [] start_kernel+0x5c4/0x8f6 [ 0.000000] ---[ end trace f67eb9af4d8d492b ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- While ftrace is looping over a list of addresses to patch, it always failed when patching the same function: riscv_cpuid_to_hartid_mask. Looking at the backtrace, the illegal instruction is encountered in this same function. However, patch_text_nosync, after patching the instructions, calls flush_icache_range. But looking at what happens in this function: flush_icache_range -> flush_icache_all -> sbi_remote_fence_i -> __sbi_rfence_v02 -> riscv_cpuid_to_hartid_mask The icache and dcache of the current cpu are never synchronized between the patching of riscv_cpuid_to_hartid_mask and calling this same function. So fix this by flushing the current cpu's icache before asking for the other cpus to do the same.

The advisory is shared at git.kernel.org. This vulnerability is uniquely identified as CVE-2021-47414. The exploitability is told to be difficult. Neither technical details nor an exploit are publicly available.

Upgrading to version 5.10.73 or 5.14.12 eliminates this vulnerability. Applying the patch 427faa29e06f/f1c7aa87c423/bb8958d5dc79 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the vulnerability database at CERT Bund (WID-SEC-2024-1197). Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Affected

• Debian Linux
• Amazon Linux 2
• Red Hat Enterprise Linux
• Ubuntu Linux
• SUSE Linux
• IBM InfoSphere Guardium
• Oracle Linux
• EMC Avamar
• Dell NetWorker
• IBM Security Guardium
• RESF Rocky Linux
• Broadcom Brocade SANnav
• Open Source Linux Kernel
• IBM Business Automation Workflow
• IBM Spectrum Protect Plus
• IBM QRadar SIEM
• Dell Avamar
• Juniper Junos Space
• IBM DB2
• IBM Storage Scale System
• SolarWinds Security Event Manager
• Dell PowerProtect Data Domain
• Dell PowerProtect Data Domain Management Center
• Dell PowerProtect Data Domain OS

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 5.10.0
• 5.10.1
• 5.10.2
• 5.10.3
• 5.10.4
• 5.10.5
• 5.10.6
• 5.10.7
• 5.10.8
• 5.10.9
• 5.10.10
• 5.10.11
• 5.10.12
• 5.10.13
• 5.10.14
• 5.10.15
• 5.10.16
• 5.10.17
• 5.10.18
• 5.10.19
• 5.10.20
• 5.10.21
• 5.10.22
• 5.10.23
• 5.10.24
• 5.10.25
• 5.10.26
• 5.10.27
• 5.10.28
• 5.10.29
• 5.10.30
• 5.10.31
• 5.10.32
• 5.10.33
• 5.10.34
• 5.10.35
• 5.10.36
• 5.10.37
• 5.10.38
• 5.10.39
• 5.10.40
• 5.10.41
• 5.10.42
• 5.10.43
• 5.10.44
• 5.10.45
• 5.10.46
• 5.10.47
• 5.10.48
• 5.10.49
• 5.10.50
• 5.10.51
• 5.10.52
• 5.10.53
• 5.10.54
• 5.10.55
• 5.10.56
• 5.10.57
• 5.10.58
• 5.10.59
• 5.10.60
• 5.10.61
• 5.10.62
• 5.10.63
• 5.10.64
• 5.10.65
• 5.10.66
• 5.10.67
• 5.10.68
• 5.10.69
• 5.10.70
• 5.10.71
• 5.10.72
• 5.14.0
• 5.14.1
• 5.14.2
• 5.14.3
• 5.14.4
• 5.14.5
• 5.14.6
• 5.14.7
• 5.14.8
• 5.14.9
• 5.14.10
• 5.14.11

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔍
• 🔍
• 🔍

CPE 2.2info

• 🔍
• 🔍
• 🔍

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion