CVE-2022-48865: tipc: fix kernel panic when enabling bearer
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix kernel panic when enabling bearer
When enabling a bearer on a node, a kernel panic is observed:
[ 4.498085] RIP: 0010:tipc_mon_prep+0x4e/0x130 [tipc]
...
[ 4.520030] Call Trace:
[ 4.520689] <IRQ>
[ 4.521236] tipc_link_build_proto_msg+0x375/0x750 [tipc]
[ 4.522654] tipc_link_build_state_msg+0x48/0xc0 [tipc]
[ 4.524034] __tipc_node_link_up+0xd7/0x290 [tipc]
[ 4.525292] tipc_rcv+0x5da/0x730 [tipc]
[ 4.526346] ? __netif_receive_skb_core+0xb7/0xfc0
[ 4.527601] tipc_l2_rcv_msg+0x5e/0x90 [tipc]
[ 4.528737] __netif_receive_skb_list_core+0x20b/0x260
[ 4.530068] netif_receive_skb_list_internal+0x1bf/0x2e0
[ 4.531450] ? dev_gro_receive+0x4c2/0x680
[ 4.532512] napi_complete_done+0x6f/0x180
[ 4.533570] virtnet_poll+0x29c/0x42e [virtio_net]
...
The node in question is receiving activate messages in another
thread after changing bearer status to allow message sending/
receiving in current thread:
thread 1 | thread 2
-------- | --------
|
tipc_enable_bearer() |
test_and_set_bit_lock() |
tipc_bearer_xmit_skb() |
| tipc_l2_rcv_msg()
| tipc_rcv()
| __tipc_node_link_up()
| tipc_link_build_state_msg()
| tipc_link_build_proto_msg()
| tipc_mon_prep()
| {
| ...
| // null-pointer dereference
| u16 gen = mon->dom_gen;
| ...
| }
// Not being executed yet |
tipc_mon_create() |
{ |
... |
// allocate |
mon = kzalloc(); |
... |
} |
Monitoring pointer in thread 2 is dereferenced before monitoring data
is allocated in thread 1. This causes kernel panic.
This commit fixes it by allocating the monitoring data before enabling
the bearer to receive messages.
Security readout for executives and security teams
Plain-English summary
CVE-2022-48865 is a Linux kernel stability flaw in TIPC. Under a timing race while enabling a TIPC bearer, the kernel can dereference monitoring data before it exists, causing a panic. The business impact is denial of service on affected systems that use TIPC, not confirmed data theft or privilege escalation.
Executive priority
Treat as maintenance priority for general fleets, and higher priority for production systems using TIPC. The main business risk is unexpected outage from kernel panic. There is no evidence in the provided sources of active exploitation or data compromise.
Technical view
The flaw is a race in Linux TIPC bearer enablement. Message receive handling can call tipc_mon_prep() before tipc_mon_create() allocates monitoring state, leading to a null-pointer dereference and kernel panic. The upstream fix changes initialization order so monitoring data is allocated before bearer traffic can be received.
Likely exposure
Exposure appears limited to Linux systems with affected kernels where TIPC is enabled or bearers are configured. Systems not using TIPC are less likely to be practically exposed based on the provided description. Distribution-specific backport status is not included in the source bundle.
Exploitation context
The source bundle does not show active exploitation, public weaponization, KEV listing, CVSS, or a remote exploit claim. The described failure requires TIPC bearer enablement and a race with incoming activation messages, producing kernel panic denial of service.
Researcher notes
The affected-version data in the bundle is incomplete and should be reconciled with distro advisories. The core bug is initialization ordering: bearer receive path becomes active before monitoring state exists. Validate fixes by code lineage or vendor backport notes, not only upstream version numbers.
Mitigation direction
Apply Linux kernel updates containing the referenced stable fixes.
Follow your Linux distribution advisory for backported fixed packages.
Disable or avoid TIPC bearer configuration where TIPC is not required.
Prioritize remediation on clustered or availability-sensitive Linux hosts using TIPC.
Validation and detection
Inventory Linux hosts where TIPC is enabled or configured.
Compare deployed kernel builds against vendor fixed package advisories.
Check whether the referenced upstream stable fixes are included in your kernel source package.
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-48865 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.