CVE-2022-50553
published 2025-10-07CVE-2022-50553: In the Linux kernel, the following vulnerability has been resolved: tracing/hist: Fix out-of-bound write on 'action_data.var_ref_idx' When generate a synthetic…
PriorityP422medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.19%
9.1th percentile
In the Linux kernel, the following vulnerability has been resolved:
tracing/hist: Fix out-of-bound write on 'action_data.var_ref_idx'
When generate a synthetic event with many params and then create a trace
action for it [1], kernel panic happened [2].
It is because that in trace_action_create() 'data->n_params' is up to
SYNTH_FIELDS_MAX (current value is 64), and array 'data->var_ref_idx'
keeps indices into array 'hist_data->var_refs' for each synthetic event
param, but the length of 'data->var_ref_idx' is TRACING_MAP_VARS_MAX
(current value is 16), so out-of-bound write happened when 'data->n_params'
more than 16. In this case, 'data->match_data.event' is overwritten and
eventually cause the panic.
To solve the issue, adjust the length of 'data->var_ref_idx' to be
SYNTH_FIELDS_MAX and add sanity checks to avoid out-of-bound write.
[1]
# 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,pid)" >> events/sched/sched_switch/trigger
[2]
BUG: unable to handle page fault
Affected
20 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.4-1 (bookworm) | linux 6.1.4-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | — | — |
| linux | linux | >= 38b67e60b6b582e81f9db1b2e7176cbbfbd3e574 < cf79d5410a569dad1d4112b5c3c02383cca8213a | cf79d5410a569dad1d4112b5c3c02383cca8213a |
| linux | linux | >= 5.4.19 < 5.4.229 | 5.4.229 |
| linux | linux | >= 5.5.6 < 5.6 | 5.6 |
| linux | linux | >= d380dcde9a07ca5de4805dee11f58a98ec0ad6ff < 0cb31bd88361edb96cfc622648717ba348f0f4dc | 0cb31bd88361edb96cfc622648717ba348f0f4dc |
| linux | linux | >= d380dcde9a07ca5de4805dee11f58a98ec0ad6ff < 15697f653399253f9be4ed2a1e03d795f3cfee94 | 15697f653399253f9be4ed2a1e03d795f3cfee94 |
| linux | linux | >= d380dcde9a07ca5de4805dee11f58a98ec0ad6ff < b4efdc219fb8cfa066c7042e636ab8ad6d7e7494 | b4efdc219fb8cfa066c7042e636ab8ad6d7e7494 |
| linux | linux | >= d380dcde9a07ca5de4805dee11f58a98ec0ad6ff < 04241956ce8825ff06e06e4083e7b692e9d5f712 | 04241956ce8825ff06e06e4083e7b692e9d5f712 |
| linux | linux | >= d380dcde9a07ca5de4805dee11f58a98ec0ad6ff < 82470f7d9044842618c847a7166de2b7458157a7 | 82470f7d9044842618c847a7166de2b7458157a7 |
| linux | linux_kernel | >= 0 < 5.10.178-1 | 5.10.178-1 |
| linux | linux_kernel | >= 0 < 6.1.4-1 | 6.1.4-1 |
| linux | linux_kernel | >= 0 < 6.1.4-1 | 6.1.4-1 |
| linux | linux_kernel | >= 0 < 6.1.4-1 | 6.1.4-1 |
| linux | linux_kernel | >= 5.11 < 5.15.87 | 5.15.87 |
| linux | linux_kernel | >= 5.16 < 6.0.18 | 6.0.18 |
| linux | linux_kernel | >= 5.4.19 < 5.4.229 | 5.4.229 |
| linux | linux_kernel | >= 5.5.6 < 5.10.163 | 5.10.163 |
| linux | linux_kernel | >= 6.1 < 6.1.4 | 6.1.4 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: tracing/hist: Fix out-of-bound write on 'action_data.var_ref_idx'
vendor_redhat·2025-10-07·CVSS 5.5
CVE-2022-50553 [MEDIUM] CWE-787 kernel: tracing/hist: Fix out-of-bound write on 'action_data.var_ref_idx'
kernel: tracing/hist: Fix out-of-bound write on 'action_data.var_ref_idx'
In the Linux kernel, the following vulnerability has been resolved:
tracing/hist: Fix out-of-bound write on 'action_data.var_ref_idx'
When generate a synthetic event with many params and then create a trace
action for it [1], kernel panic happened [2].
It is because that in trace_action_create() 'data->n_params' is up to
SYNTH_FIELDS_MAX (current value is 64), and array 'data->var_ref_idx'
keeps indices into array 'hist_data->var_refs' for each synthetic event
param, but the length of 'data->var_ref_idx' is TRACING_MAP_VARS_MAX
(current value is 16), so out-of-bound write happened when 'data->n_params'
more than 16. In this case, 'data->match_data.event' is overwritten and
eventually cause the panic.
To solve the is
Debian
CVE-2022-50553: linux - In the Linux kernel, the following vulnerability has been resolved: tracing/his...
vendor_debian·2022·CVSS 5.5
CVE-2022-50553 [MEDIUM] CVE-2022-50553: linux - In the Linux kernel, the following vulnerability has been resolved: tracing/his...
In the Linux kernel, the following vulnerability has been resolved: tracing/hist: Fix out-of-bound write on 'action_data.var_ref_idx' When generate a synthetic event with many params and then create a trace action for it [1], kernel panic happened [2]. It is because that in trace_action_create() 'data->n_params' is up to SYNTH_FIELDS_MAX (current value is 64), and array 'data->var_ref_idx' keeps indices into array 'hist_data->var_refs' for each synthetic event param, but the length of 'data->var_ref_idx' is TRACING_MAP_VARS_MAX (current value is 16), so out-of-bound write happened when 'data->n_params' more than 16. In this case, 'data->match_data.event' is overwritten and eventually cause the panic. To solve the issue, adjust the length of 'data->var_ref_idx' to be SYNTH_FIELDS_MAX and ad
VulDB
Linux Kernel up to 6.1.3 trace_action_create denial of service (EUVD-2025-31984 / Nessus ID 278484)
vuldb·2026-04-20·CVSS 5.5
CVE-2022-50553 [MEDIUM] Linux Kernel up to 6.1.3 trace_action_create denial of service (EUVD-2025-31984 / Nessus ID 278484)
A vulnerability has been found in Linux Kernel up to 5.4.228/5.10.162/5.15.86/6.0.17/6.1.3 and classified as critical. This issue affects the function trace_action_create. This manipulation causes denial of service.
This vulnerability appears as CVE-2022-50553. The attacker needs to be present on the local network. There is no available exploit.
The affected component should be upgraded.
GHSA
GHSA-rvj3-h2c8-jjxg: In the Linux kernel, the following vulnerability has been resolved:
tracing/hist: Fix out-of-bound write on 'action_data
ghsa_unreviewed·2025-10-07
CVE-2022-50553 [MEDIUM] CWE-787 GHSA-rvj3-h2c8-jjxg: In the Linux kernel, the following vulnerability has been resolved:
tracing/hist: Fix out-of-bound write on 'action_data
In the Linux kernel, the following vulnerability has been resolved:
tracing/hist: Fix out-of-bound write on 'action_data.var_ref_idx'
When generate a synthetic event with many params and then create a trace
action for it [1], kernel panic happened [2].
It is because that in trace_action_create() 'data->n_params' is up to
SYNTH_FIELDS_MAX (current value is 64), and array 'data->var_ref_idx'
keeps indices into array 'hist_data->var_refs' for each synthetic event
param, but the length of 'data->var_ref_idx' is TRACING_MAP_VARS_MAX
(current value is 16), so out-of-bound write happened when 'data->n_params'
more than 16. In this case, 'data->match_data.event' is overwritten and
eventually cause the panic.
To solve the issue, adjust the length of 'data->var_ref_idx' to be
SYNTH_FIELDS_MAX an
OSV
CVE-2022-50553: In the Linux kernel, the following vulnerability has been resolved: tracing/hist: Fix out-of-bound write on 'action_data
osv·2025-10-07·CVSS 5.5
CVE-2022-50553 [MEDIUM] CVE-2022-50553: In the Linux kernel, the following vulnerability has been resolved: tracing/hist: Fix out-of-bound write on 'action_data
In the Linux kernel, the following vulnerability has been resolved: tracing/hist: Fix out-of-bound write on 'action_data.var_ref_idx' When generate a synthetic event with many params and then create a trace action for it [1], kernel panic happened [2]. It is because that in trace_action_create() 'data->n_params' is up to SYNTH_FIELDS_MAX (current value is 64), and array 'data->var_ref_idx' keeps indices into array 'hist_data->var_refs' for each synthetic event param, but the length of 'data->var_ref_idx' is TRACING_MAP_VARS_MAX (current value is 16), so out-of-bound write happened when 'data->n_params' more than 16. In this case, 'data->match_data.event' is overwritten and eventually cause the panic. To solve the issue, adjust the length of 'data->var_ref_idx' to be SYNTH_FIELDS_MAX and ad
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/04241956ce8825ff06e06e4083e7b692e9d5f712https://git.kernel.org/stable/c/0cb31bd88361edb96cfc622648717ba348f0f4dchttps://git.kernel.org/stable/c/15697f653399253f9be4ed2a1e03d795f3cfee94https://git.kernel.org/stable/c/82470f7d9044842618c847a7166de2b7458157a7https://git.kernel.org/stable/c/b4efdc219fb8cfa066c7042e636ab8ad6d7e7494https://git.kernel.org/stable/c/cf79d5410a569dad1d4112b5c3c02383cca8213a
2025-10-07
Published