CVE-2022-49149

rxrpc: Fix call timer start racing with call destruction

Published Feb 26, 2025 CVSS 3.1 · 9.8 Critical EPSS < 1% KEV · Not listed
Description
In the Linux kernel, the following vulnerability has been resolved:

rxrpc: Fix call timer start racing with call destruction

The rxrpc_call struct has a timer used to handle various timed events
relating to a call. This timer can get started from the packet input
routines that are run in softirq mode with just the RCU read lock held.
Unfortunately, because only the RCU read lock is held - and neither ref or
other lock is taken - the call can start getting destroyed at the same time
a packet comes in addressed to that call. This causes the timer - which
was already stopped - to get restarted. Later, the timer dispatch code may
then oops if the timer got deallocated first.

Fix this by trying to take a ref on the rxrpc_call struct and, if
successful, passing that ref along to the timer. If the timer was already
running, the ref is discarded.

The timer completion routine can then pass the ref along to the call's work
item when it queues it. If the timer or work item where already
queued/running, the extra ref is discarded.

Remediation

No solution or workaround provided in the CVE record

Tracking

Sign in to view the affected projects.

Advisories

Source ID Title
EUVD EUVD EUVD-2022-55076 In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix call timer start racing with call destruction The rxrpc_call struct has a timer used to handle various timed events relating to a call. This timer can get started from the packet input routines that are run in softirq mode with just the RCU read lock held. Unfortunately, because only the RCU read lock is held - and neither ref or other lock is taken - the call can start getting destroyed at the same time a packet comes in addressed to that call. This causes the timer - which was already stopped - to get restarted. Later, the timer dispatch code may then oops if the timer got deallocated first. Fix this by trying to take a ref on the rxrpc_call struct and, if successful, passing that ref along to the timer. If the timer was already running, the ref is discarded. The timer completion routine can then pass the ref along to the call's work item when it queues it. If the timer or work item where already queued/running, the extra ref is discarded.
Ubuntu USN Ubuntu USN USN-8919-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8920-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-9032-1 Linux kernel vulnerabilities
History
Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'yes', 'Exploitation': 'none', 'Technical Impact': 'total'}, 'version': '2.0.3'}

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 4.7, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H'}

cvssV3_1

{'score': 9.8, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'}

Type Values Removed Values Added
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:4.15:-:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:4.15:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:4.15:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:4.15:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:4.15:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:4.15:rc6:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:4.15:rc7:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:4.15:rc8:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:4.15:rc9:*:*:*:*:*:*
Type Values Removed Values Added
Weaknesses CWE-362
Metrics cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

cvssV3_1

{'score': 4.7, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H'}

Type Values Removed Values Added
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix call timer start racing with call destruction The rxrpc_call struct has a timer used to handle various timed events relating to a call. This timer can get started from the packet input routines that are run in softirq mode with just the RCU read lock held. Unfortunately, because only the RCU read lock is held - and neither ref or other lock is taken - the call can start getting destroyed at the same time a packet comes in addressed to that call. This causes the timer - which was already stopped - to get restarted. Later, the timer dispatch code may then oops if the timer got deallocated first. Fix this by trying to take a ref on the rxrpc_call struct and, if successful, passing that ref along to the timer. If the timer was already running, the ref is discarded. The timer completion routine can then pass the ref along to the call's work item when it queues it. If the timer or work item where already queued/running, the extra ref is discarded.
Title rxrpc: Fix call timer start racing with call destruction
References
Weaknesses

Sources

Status
PUBLISHED
Assigner
Linux
Published
Updated
Oct 15, 2026, 9:21 PM
Reserved
Feb 26, 2025, 1:49 AM
Status
Modified
Published
Feb 26, 2025, 7:00 AM
Modified
Oct 15, 2026, 10:17 PM
Severity
Moderate
Public date
Feb 26, 2025, 12:00 AM