CVE-2022-48848: tracing/osnoise: Do not unregister events twice
In the Linux kernel, the following vulnerability has been resolved:
tracing/osnoise: Do not unregister events twice
Nicolas reported that using:
# trace-cmd record -e all -M 10 -p osnoise --poll
Resulted in the following kernel warning:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1217 at kernel/tracepoint.c:404 tracepoint_probe_unregister+0x280/0x370
[...]
CPU: 0 PID: 1217 Comm: trace-cmd Not tainted 5.17.0-rc6-next-20220307-nico+ #19
RIP: 0010:tracepoint_probe_unregister+0x280/0x370
[...]
CR2: 00007ff919b29497 CR3: 0000000109da4005 CR4: 0000000000170ef0
Call Trace:
<TASK>
osnoise_workload_stop+0x36/0x90
tracing_set_tracer+0x108/0x260
tracing_set_trace_write+0x94/0xd0
? __check_object_size.part.0+0x10a/0x150
? selinux_file_permission+0x104/0x150
vfs_write+0xb5/0x290
ksys_write+0x5f/0xe0
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7ff919a18127
[...]
---[ end trace 0000000000000000 ]---
The warning complains about an attempt to unregister an
unregistered tracepoint.
This happens on trace-cmd because it first stops tracing, and
then switches the tracer to nop. Which is equivalent to:
# cd /sys/kernel/tracing/
# echo osnoise > current_tracer
# echo 0 > tracing_on
# echo nop > current_tracer
The osnoise tracer stops the workload when no trace instance
is actually collecting data. This can be caused both by
disabling tracing or disabling the tracer itself.
To avoid unregistering events twice, use the existing
trace_osnoise_callback_enabled variable to check if the events
(and the workload) are actually active before trying to
deactivate them.
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue affects the osnoise tracing feature. Under specific tracing state changes, the kernel can try to unregister the same tracepoint twice, producing a kernel warning. The provided sources show an operational reliability bug, not evidence of remote compromise, privilege escalation, or active exploitation.
Executive priority
Treat this as routine kernel maintenance unless affected systems depend heavily on osnoise tracing. Prioritize patching through standard kernel update cycles, especially on observability, performance testing, and real-time diagnostics hosts.
Technical view
The osnoise tracer could call event/workload deactivation after tracing was already stopped, causing tracepoint_probe_unregister to warn about unregistering an unregistered tracepoint. The fix uses trace_osnoise_callback_enabled to confirm callbacks are active before deactivation.
Likely exposure
Exposure appears limited to Linux systems running affected 5.16-era kernels where osnoise tracing is available and used. General application servers are less likely exposed unless kernel tracing workflows or diagnostics rely on osnoise.
Exploitation context
The source bundle describes a local tracing workflow that triggers a kernel warning. KEV is false, and no cited source states active exploitation or a practical security impact beyond the warning.
Researcher notes
Affected versions are incompletely expressed in the source bundle, but Linux 5.16 through fixed stable releases are indicated. The evidence supports a double-unregister bug in tracing/osnoise with fixes in stable kernel commits. No CVSS, CWE, or KEV signal is provided.
Mitigation direction
Upgrade to a kernel containing the referenced stable fixes.
Check distribution advisories for backported CVE-2022-48848 fixes.
Limit osnoise tracing access to trusted administrators.
Avoid unsupported affected kernels in production observability workflows.
Validation and detection
Inventory Linux kernel versions across affected fleets.
Confirm vendor changelogs include CVE-2022-48848 or the referenced commits.
Review kernel logs for osnoise or tracepoint unregister warnings.
Confirm only trusted users can access kernel tracing interfaces.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2022-48848 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.