Echo: linux: security update to 6.9.10-1

medium Tenable Cloud Security Plugin ID 457117

Description

There are packages installed that are affected by a vulnerability referenced in the following CVE:

- In the Linux kernel, the following vulnerability has been resolved: bpf: Fail bpf_timer_cancel when
callback is being cancelled Given a schedule: timer1 cb timer2 cb bpf_timer_cancel(timer2);
bpf_timer_cancel(timer1); Both bpf_timer_cancel calls would wait for the other callback to finish
executing, introducing a lockup. Add an atomic_t count named 'cancelling' in bpf_hrtimer. This keeps track
of all in-flight cancellation requests for a given BPF timer. Whenever cancelling a BPF timer, we must
check if we have outstanding cancellation requests, and if so, we must fail the operation with an error
(-EDEADLK) since cancellation is synchronous and waits for the callback to finish executing. This implies
that we can enter a deadlock situation involving two or more timer callbacks executing in parallel and
attempting to cancel one another. Note that we avoid incrementing the cancelling counter for the target
timer (the one being cancelled) if bpf_timer_cancel is not invoked from a callback, to avoid spurious
errors. The whole point of detecting cur->cancelling and returning -EDEADLK is to not enter a busy wait
loop (which may or may not lead to a lockup). This does not apply in case the caller is in a non-callback
context, the other side can continue to cancel as it sees fit without running into errors. Background on
prior attempts: Earlier versions of this patch used a bool 'cancelling' bit and used the following pattern
under timer->lock to publish cancellation status. lock(t->lock); t->cancelling = true; mb(); if
(cur->cancelling) return -EDEADLK; unlock(t->lock); hrtimer_cancel(t->timer); t->cancelling = false; The
store outside the critical section could overwrite a parallel requests t->cancelling assignment to true,
to ensure the parallely executing callback observes its cancellation status. It would be necessary to
clear this cancelling bit once hrtimer_cancel is done, but lack of serialization introduced races. Another
option was explored where bpf_timer_start would clear the bit when (re)starting the timer under
timer->lock. This would ensure serialized access to the cancelling bit, but may allow it to be cleared
before in-flight hrtimer_cancel has finished executing, such that lockups can occur again. Thus, we choose
an atomic counter to keep track of all outstanding cancellation requests and use it to prevent lockups in
case callbacks attempt to cancel each other while executing in parallel. (CVE-2024-42239)

Solution

Update the linux library and its related packages to version 6.9.10-1 or later.

See Also

https://advisory.echohq.com/cve/CVE-2024-42239

Plugin Details

Severity: Medium

ID: 457117

Version: Revision 1.1

Type: Local

Published: 10/2/2026

Updated: 10/2/2026

Risk Information

VPR

Risk Factor: Low

Score: 3

Percentile: 23.18

CVSS v2

Risk Factor: Medium

Base Score: 4.6

Temporal Score: 3.4

Vector: CVSS2#AV:L/AC:L/Au:S/C:N/I:N/A:C

CVSS Score Source: CVE-2024-42239

CVSS v3

Risk Factor: Medium

Base Score: 5.5

Temporal Score: 4.8

Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Temporal Vector: CVSS:3.0/E:U/RL:O/RC:C

Vulnerability Information

Exploit Ease: No known exploits are available

Patch Publication Date: 9/15/2025

Vulnerability Publication Date: 8/7/2024

Reference Information

CVE: CVE-2024-42239