Linux Kernel up to 5.17.12/5.18.1 jit_subprogs memory corruption

Summaryinfo

A vulnerability has been found in Linux Kernel up to 5.17.12/5.18.1 and classified as critical. Affected is the function jit_subprogs. Performing a manipulation results in memory corruption. This vulnerability was named CVE-2022-49552. There is no available exploit. The affected component should be upgraded.

Detailsinfo

A vulnerability classified as critical has been found in Linux Kernel up to 5.17.12/5.18.1. This affects the function jit_subprogs. The manipulation with an unknown input leads to a memory corruption vulnerability. CWE is classifying the issue as CWE-119. The product performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer. This is going to have an impact on confidentiality, integrity, and availability. The summary by CVE is:

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix combination of jit blinding and pointers to bpf subprogs. The combination of jit blinding and pointers to bpf subprogs causes: [ 36.989548] BUG: unable to handle page fault for address: 0000000100000001 [ 36.990342] #PF: supervisor instruction fetch in kernel mode [ 36.990968] #PF: error_code(0x0010) - not-present page [ 36.994859] RIP: 0010:0x100000001 [ 36.995209] Code: Unable to access opcode bytes at RIP 0xffffffd7. [ 37.004091] Call Trace: [ 37.004351] [ 37.004576] ? bpf_loop+0x4d/0x70 [ 37.004932] ? bpf_prog_3899083f75e4c5de_F+0xe3/0x13b The jit blinding logic didn't recognize that ld_imm64 with an address of bpf subprogram is a special instruction and proceeded to randomize it. By itself it wouldn't have been an issue, but jit_subprogs() logic relies on two step process to JIT all subprogs and then JIT them again when addresses of all subprogs are known. Blinding process in the first JIT phase caused second JIT to miss adjustment of special ld_imm64. Fix this issue by ignoring special ld_imm64 instructions that don't have user controlled constants and shouldn't be blinded.

The advisory is shared at git.kernel.org. This vulnerability is uniquely identified as CVE-2022-49552 since 02/26/2025. The exploitability is told to be easy. Technical details are known, but no exploit is available. The price for an exploit might be around USD $0-$5k at the moment (estimation calculated on 10/23/2025).

Upgrading to version 5.17.13 or 5.18.2 eliminates this vulnerability. Applying the patch a029b02b47dd5bb87a21550d9d9a80cb4dd3f714/d106a3e96fca30e44081eae9c27aab28fc132a46/4b6313cf99b0d51b49aeaea98ec76ca8161ecb80 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.

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

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 5.17.0
• 5.17.1
• 5.17.2
• 5.17.3
• 5.17.4
• 5.17.5
• 5.17.6
• 5.17.7
• 5.17.8
• 5.17.9
• 5.17.10
• 5.17.11
• 5.17.12
• 5.18.0
• 5.18.1

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