CVE-2022-50553
BaseFortify
Publication date: 2025-10-07
Last updated on: 2026-02-04
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | From 5.11 (inc) to 5.15.87 (inc) |
| linux | linux_kernel | 6.1.0-rc8 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-787 | The product writes data past the end, or before the beginning, of the intended buffer. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability is an out-of-bound write in the Linux kernel's tracing subsystem. Specifically, when creating a synthetic event with many parameters (more than 16), the kernel writes beyond the bounds of an array called 'var_ref_idx' which only supports up to 16 entries, while the number of parameters can be up to 64. This causes memory corruption that overwrites other data structures, eventually leading to a kernel panic (system crash). The issue was fixed by increasing the array size and adding checks to prevent out-of-bound writes.
How can this vulnerability impact me? :
This vulnerability can cause a kernel panic, which means the affected Linux system can crash unexpectedly. This can lead to denial of service, loss of availability, and potential data loss or corruption if the system is unstable or crashes during critical operations.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by attempting to create a synthetic event with more than 16 parameters in the Linux kernel tracing subsystem, which triggers the out-of-bound write and kernel panic. The following commands can be used to test for the vulnerability by creating such an event and trace action: # cd /sys/kernel/tracing/ # echo "my_synth_event int v1; int v2; int v3; int v4; int v5; int v6; int v7; int v8; int v9; int v10; int v11; int v12; int v13; int v14; int v15; int v16; int v17; int v18; int v19; int v20; int v21; int v22; int v23; int v24; int v25; int v26; int v27; int v28; int v29; int v30; int v31; int v32; int v33; int v34; int v35; int v36; int v37; int v38; int v39; int v40; int v41; int v42; int v43; int v44; int v45; int v46; int v47; int v48; int v49; int v50; int v51; int v52; int v53; int v54; int v55; int v56; int v57; int v58; int v59; int v60; int v61; int v62; int v63" >> synthetic_events # echo 'hist:keys=pid:ts0=common_timestamp.usecs if comm=="bash"' >> events/sched/sched_waking/trigger # echo "hist:keys=next_pid:onmatch(sched.sched_waking).my_synth_event(pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid)" >> events/sched/sched_switch/trigger If these commands cause a kernel panic or similar crash, the system is vulnerable.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include updating the Linux kernel to a version where this vulnerability is fixed. The fix involves adjusting the length of the 'data->var_ref_idx' array to match SYNTH_FIELDS_MAX and adding sanity checks to prevent out-of-bound writes. Until the kernel is updated, avoid creating synthetic events with more than 16 parameters in the tracing subsystem to prevent triggering the vulnerability.