Track vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
Azure kernel could misjudge keepalive timing
published 8 months ago
Summary
The Azure Linux kernel versions before 6.6.130.1-3 may incorrectly handle timing information for network keepalive messages. This could cause the system to miss or send unnecessary keepalive packets, potentially affecting network reliability. Updating to the latest kernel version resolves the problem.
What to do
- Update azure kernel to version 6.6.130.1-3.
Affected software
| Ecosystem | Vendor | Product | Affected versions |
|---|---|---|---|
| Azure Linux:3 | azure | kernel |
< 6.6.130.1-3 Fix: upgrade to 6.6.130.1-3
|
Original advisory text
CVE-2026-23118 affecting package kernel for versions less than 6.6.130.1-3
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix data-race warning and potential load/store tearing
Fix the following:
BUG: KCSAN: data-race in rxrpc_peer_keepalive_worker / rxrpc_send_data_packet
which is reporting an issue with the reads and writes to ->last_tx_at in:
conn->peer->last_tx_at = ktime_get_seconds();
and:
keepalive_at = peer->last_tx_at + RXRPC_KEEPALIVE_TIME;
The lockless accesses to these to values aren't actually a problem as the
read only needs an approximate time of last transmission for the purposes
of deciding whether or not the transmission of a keepalive packet is
warranted yet.
Also, as ->last_tx_at is a 64-bit value, tearing can occur on a 32-bit
arch.
Fix both of these by switching to an unsigned int for ->last_tx_at and only
storing the LSW of the time64_t. It can then be reconstructed at need
provided no more than 68 years has elapsed since the last transmission.
rxrpc: Fix data-race warning and potential load/store tearing
Fix the following:
BUG: KCSAN: data-race in rxrpc_peer_keepalive_worker / rxrpc_send_data_packet
which is reporting an issue with the reads and writes to ->last_tx_at in:
conn->peer->last_tx_at = ktime_get_seconds();
and:
keepalive_at = peer->last_tx_at + RXRPC_KEEPALIVE_TIME;
The lockless accesses to these to values aren't actually a problem as the
read only needs an approximate time of last transmission for the purposes
of deciding whether or not the transmission of a keepalive packet is
warranted yet.
Also, as ->last_tx_at is a 64-bit value, tearing can occur on a 32-bit
arch.
Fix both of these by switching to an unsigned int for ->last_tx_at and only
storing the LSW of the time64_t. It can then be reconstructed at need
provided no more than 68 years has elapsed since the last transmission.
References
Timeline
Published14 Feb 2026
Updated23 Sep 2026
First seen23 Sep 2026
Sources
AZL-77691 · OSV
Track software like this
Free during beta