LSN-0109-1: Kernel Live Patch Security Notice
20 February 2025
Several security issues were fixed in the kernel.
Releases
Software Description
- aws - Linux kernel for Amazon Web Services (AWS) systems - (>= 4.15.0-1159, >= 5.4.0-1009, >= 5.4.0-1061, >= 5.15.0-1000, >= 6.8.0-1008, >= 4.4.0-1159)
- aws-5.15 - Linux kernel for Amazon Web Services (AWS) systems - (>= 5.15.0-1000)
- aws-hwe - Linux kernel for Amazon Web Services (AWS-HWE) systems - (>= 4.15.0-1126)
- azure - Linux kernel for Microsoft Azure Cloud systems - (>= 5.4.0-1010, >= 5.15.0-1000, >= 6.8.0-1007, >= 4.15.0-1114)
- azure-4.15 - Linux kernel for Microsoft Azure Cloud systems - (>= 4.15.0-1168)
- azure-5.15 - Linux kernel for Microsoft Azure cloud systems - (>= 5.15.0-1069)
- gcp - Linux kernel for Google Cloud Platform (GCP) systems - (>= 5.4.0-1009, >= 5.15.0-1000, >= 6.8.0-1007, >= 4.15.0-1118)
- gcp-4.15 - Linux kernel for Google Cloud Platform (GCP) systems - (>= 4.15.0-1154)
- gcp-5.15 - Linux kernel for Google Cloud Platform (GCP) systems - (>= 5.15.0-1000)
- generic-4.15 - Linux hardware enablement (HWE) kernel - (>= 4.15.0-214, >= 4.15.0-143)
- generic-4.4 - Linux kernel - (>= 4.4.0-243)
- generic-5.15 - Linux hardware enablement (HWE) kernel - (>= 5.15.0-0)
- generic-5.4 - Linux kernel - (>= 5.4.0-150, >= 5.4.0-26)
- gke - Linux kernel for Google Container Engine (GKE) systems - (>= 5.15.0-1000)
- gkeop - Linux kernel for Google Container Engine (GKE) systems - (>= 5.4.0-1009)
- ibm - Linux kernel for IBM cloud systems - (>= 5.4.0-1009, >= 5.15.0-1000, >= 6.8.0-1005)
- ibm-5.15 - Linux kernel for IBM cloud systems - (>= 5.15.0-1000)
- linux - Linux kernel - (>= 5.15.0-71, >= 5.15.0-24, >= 6.8.0-1)
- lowlatency-4.15 - Linux hardware enablement (HWE) kernel - (>= 4.15.0-214, >= 4.15.0-143)
- lowlatency-4.4 - Linux kernel - (>= 4.4.0-243)
- lowlatency-5.15 - Linux hardware enablement (HWE) kernel - (>= 5.15.0-0)
- lowlatency-5.4 - Linux kernel - (>= 5.4.0-150, >= 5.4.0-26)
- oracle - Linux kernel for Oracle Cloud systems - (>= 4.15.0-1129, >= 5.4.0-1121, >= 5.15.0-1055)
- oracle-5.15 - Linux kernel for Oracle Cloud systems - (>= 5.15.0-1055)
Details
In the Linux kernel, the following vulnerability has been
resolved: tls: fix use-after-free on failed backlog decryption When the
decrypt request goes to the backlog and crypto_aead_decrypt returns -EBUSY,
tls_do_decryption will wait until all async decryptions have completed. If
one of them fails, tls_do_decryption will return -EBADMSG and
tls_decrypt_sg jumps to the error path, releasing all the pages. But the
pages have been passed to the async callback, and have already been
released by tls_decrypt_done. The only true async case is when
crypto_aead_decrypt returns -EINPROGRESS. With -EBUSY, we already waited so
we can tell tls_sw_recvmsg that the data is available for immediate copy,
but we need to notify tls_decrypt_sg (via the new ->async_done flag) that
the memory has already been released.)(CVE-2024-26800)
In the Linux kernel, the following vulnerability has been
resolved: inet: inet_defrag: prevent sk release while still in use
ip_local_out() and other functions can pass skb->sk as function argument.
If the skb is a fragment and reassembly happens before such function call
returns, the sk must not be released. This affects skb fragments
reassembled via netfilter or similar modules, e.g. openvswitch or ct_act.c,
when run as part of tx pipeline. Eric Dumazet made an initial analysis of
this bug. Quoting Eric: Calling ip_defrag() in output path is also implying
skb_orphan(), which is buggy because output path relies on sk not
disappearing. A relevant old patch about the issue was : 8282f27449bf
('inet: frag: Always orphan skbs inside ip_defrag()') [..
net/ipv4/ip_output.c depends on skb->sk being set, and probably to an inet
socket, not an arbitrary one. If we orphan the packet in ipvlan, then
downstream things like FQ packet scheduler will not work properly. We need
to change ip_defrag() to only use skb_orphan() when really needed, ie
whenever frag_list is going to be used. Eric suggested to stash sk in
fragment queue and made an initial patch. However there is a problem with
this: If skb is refragmented again right after, ip_do_fragment() will copy
head->sk to the new fragments, and sets up destructor to sock_wfree. IOW,
we have no choice but to fix up sk_wmem accouting to reflect the fully
reassembled skb, else wmem will underflow. This change moves the orphan
down into the core, to last possible moment. As ip_defrag_offset is aliased
with sk_buff->sk member, we must move the offset into the FRAG_CB, else
skb->sk gets clobbered. This allows to delay the orphaning long enough to
learn if the skb has to be queued or if the skb is completing the reasm
queue. In the former case, things work as before, skb is orphaned. This is
safe because skb gets queued/stolen and won't continue past reasm engine.
In the latter case, we will steal the skb->sk reference, reattach it to the
head skb, and fix up wmem accouting when inet_frag inflates truesize.)(CVE-2024-26921)
In the Linux kernel, the following vulnerability has been
resolved: watchdog: cpu5wdt.c: Fix use-after-free bug caused by
cpu5wdt_trigger When the cpu5wdt module is removing, the origin code uses
del_timer() to de-activate the timer. If the timer handler is running,
del_timer() could not stop it and will return directly. If the port region
is released by release_region() and then the timer handler
cpu5wdt_trigger() calls outb() to write into the region that is released,
the use-after-free bug will happen. Change del_timer() to
timer_shutdown_sync() in order that the timer handler could be finished
before the port region is released.)(CVE-2024-38630)
In the Linux kernel, the following vulnerability has been
resolved: exec: Fix ToCToU between perm check and set-uid/gid usage When
opening a file for exec via do_filp_open(), permission checking is done
against the file's metadata at that moment, and on success, a file pointer
is passed back. Much later in the execve() code path, the file metadata
(specifically mode, uid, and gid) is used to determine if/how to set the
uid and gid. However, those values may have changed since the permissions
check, meaning the execution may gain unintended privileges. For example,
if a file could change permissions from executable and not set-id:
---------x 1 root root 16048 Aug 7 13:16 target to set-id and non-
executable: ---S------ 1 root root 16048 Aug 7 13:16 target it is possible
to gain root privileges when execution should have been disallowed. While
this race condition is rare in real-world scenarios, it has been observed
(and proven exploitable) when package managers are updating the setuid bits
of installed programs. Such files start with being world-executable but
then are adjusted to be group-exec with a set-uid bit. For example, 'chmod
o-x,u+s target' makes 'target' executable only by uid 'root' and gid
'cdrom', while also becoming setuid-root: -rwxr-xr-x 1 root cdrom 16048 Aug
7 13:16 target becomes: -rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target
But racing the chmod means users without group 'cdrom' membership can get
the permission to execute 'target' just before the chmod, and when the
chmod finishes, the exec reaches brpm_fill_uid(), and performs the setuid
to root, violating the expressed authorization of 'only cdrom group members
can setuid to root'. Re-check that we still have execute permissions in
case the metadata has changed. It would be better to keep a copy from the
perm-check time, but until we can do that refactoring, the least-bad option
is to do a full inode_permission() call (under inode lock). It is
understood that this is safe against dead-locks, but hardly optimal.)(CVE-2024-43882)
In the Linux kernel, the following vulnerability has been
resolved: vsock/virtio: Initialization of the dangling pointer occurring in
vsk->trans During loopback communication, a dangling pointer can be created
in vsk->trans, potentially leading to a Use-After-Free condition. This
issue is resolved by initializing vsk->trans to NULL.)(CVE-2024-50264)
In the Linux kernel, the following vulnerability has been
resolved: hv_sock: Initializing vsk->trans to NULL to prevent a dangling
pointer When hvs is released, there is a possibility that vsk->trans may
not be initialized to NULL, which could lead to a dangling pointer. This
issue is resolved by initializing vsk->trans to NULL.)(CVE-2024-53103)
Checking update status
The problem can be corrected in these Livepatch versions:
| Kernel type | 24.04 | 22.04 | 20.04 | 18.04 | 16.04 |
|---|---|---|---|---|---|
| aws | 109.2 | 109.2 | 109.2 | 109.2 | 109.2 |
| aws-5.15 | — | — | 109.2 | — | — |
| aws-hwe | — | — | — | — | 109.2 |
| azure | 109.2 | 109.2 | 109.2 | — | 109.2 |
| azure-4.15 | — | — | — | 109.2 | — |
| azure-5.15 | — | — | 109.2 | — | — |
| gcp | 109.2 | 109.2 | 109.2 | — | 109.2 |
| gcp-4.15 | — | — | — | 109.2 | — |
| gcp-5.15 | — | — | 109.2 | — | — |
| generic-4.15 | — | — | — | 109.2 | 109.2 |
| generic-4.4 | — | — | — | — | 109.2 |
| generic-5.15 | — | — | 109.2 | — | — |
| generic-5.4 | — | — | 109.2 | 109.2 | — |
| gke | — | 109.2 | — | — | — |
| gkeop | — | — | 109.2 | — | — |
| ibm | 109.2 | 109.2 | 109.2 | — | — |
| ibm-5.15 | — | — | 109.2 | — | — |
| linux | 109.2 | 109.2 | — | — | — |
| lowlatency-4.15 | — | — | — | 109.2 | 109.2 |
| lowlatency-4.4 | — | — | — | — | 109.2 |
| lowlatency-5.15 | — | — | 109.2 | — | — |
| lowlatency-5.4 | — | — | 109.2 | 109.2 | — |
| oracle | — | 109.2 | 109.2 | 109.2 | — |
| oracle-5.15 | — | — | 109.2 | — | — |
To check your kernel type and Livepatch version, enter this command:
canonical-livepatch status