## https://sploitus.com/exploit?id=PACKETSTORM:190076
Linux kernel vulnerabilities
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 20.04 LTS
- Ubuntu 18.04 LTS
- Ubuntu 16.04 LTS
- Ubuntu 22.04 LTS
- Ubuntu 14.04 LTS
Summary
Several security issues were fixed in the kernel.
Software Description
- linux - Linux kernel
- linux-aws - Linux kernel for Amazon Web Services (AWS) systems
- linux-azure - Linux kernel for Microsoft Azure Cloud systems
- linux-gcp - Linux kernel for Google Cloud Platform (GCP) systems
- linux-gke - Linux kernel for Google Container Engine (GKE) systems
- linux-gkeop - Linux kernel for Google Container Engine (GKE) systems
- linux-ibm - Linux kernel for IBM cloud systems
- linux-oracle - Linux kernel for Oracle Cloud systems
Details
In the Linux kernel, the following vulnerability has been resolved: tty:
n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc Any unprivileged
user can attach N_GSM0710 ldisc, but it requires CAP_NET_ADMIN to create
a GSM network anyway. Require initial namespace CAP_NET_ADMIN to do
that. (CVE-2023-52880)
In the Linux kernel, the following vulnerability has been resolved: net:
openvswitch: fix overwriting ct original tuple for ICMPv6
OVS_PACKET_CMD_EXECUTE has 3 main attributes: - OVS_PACKET_ATTR_KEY -
Packet metadata in a netlink format. - OVS_PACKET_ATTR_PACKET - Binary
packet content. - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the
packet. OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key
structure with the metadata like conntrack state, input port,
recirculation id, etc. Then the packet itself gets parsed to populate
the rest of the keys from the packet headers. Whenever the packet
parsing code starts parsing the ICMPv6 header, it first zeroes out
fields in the key corresponding to Neighbor Discovery information even
if it is not an ND packet. It is an ‘ipv6.nd’ field. However, the ‘ipv6’
is a union that shares the space between ‘nd’ and ‘ct_orig’ that holds
the original tuple conntrack metadata parsed from the
OVS_PACKET_ATTR_KEY. ND packets should not normally have conntrack
state, so it’s fine to share the space, but normal ICMPv6 Echo packets
or maybe other types of ICMPv6 can have the state attached and it should
not be overwritten. The issue results in all but the last 4 bytes of the
destination address being wiped from the original conntrack tuple
leading to incorrect packet matching and potentially executing wrong
actions in case this packet recirculates within the datapath or goes
back to userspace. ND fields should not be accessed in non-ND packets,
so not clearing them should be fine. Executing memset() only for actual
ND packets to avoid the issue. Initializing the whole thing before
parsing is needed because ND packet may not contain all the options. The
issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn’t affect
packets entering OVS datapath from network interfaces, because in this
case CT metadata is populated from skb after the packet is already
parsed. (CVE-2024-38558)
In the Linux kernel, the following vulnerability has been resolved:
media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in
uvc_parse_format This can lead to out of bounds writes since frames of
this type were not taken into account when calculating the size of the
frames buffer in uvc_parse_streaming. (CVE-2024-53104)
In the Linux kernel, the following vulnerability has been resolved:
netlink: terminate outstanding dump on socket close Netlink supports
iterative dumping of data. It provides the families the following ops: -
start - (optional) kicks off the dumping process - dump - actual dump
helper, keeps getting called until it returns 0 - done - (optional)
pairs with .start, can be used for cleanup The whole process is
asynchronous and the repeated calls to .dump don’t actually happen in a
tight loop, but rather are triggered in response to recvmsg() on the
socket. This gives the user full control over the dump, but also means
that the user can close the socket without getting to the end of the
dump. To make sure .start is always paired with .done we check if there
is an ongoing dump before freeing the socket, and if so call .done. The
complication is that sockets can get freed from BH and .done is allowed
to sleep. So we use a workqueue to defer the call, when needed.
Unfortunately this does not work correctly. What we defer is not the
cleanup but rather releasing a reference on the socket. We have no
guarantee that we own the last reference, if someone else holds the
socket they may release it in BH and we’re back to square one. The whole
dance, however, appears to be unnecessary. Only the user can interact
with dumps, so we can clean up when socket is closed. And close always
happens in process context. Some async code may still access the socket
after close, queue notification skbs to it etc. but no dumps can start,
end or otherwise make progress. Delete the workqueue and flush the dump
state directly from the release handler. Note that further cleanup is
possible in -next, for instance we now always call .done before
releasing the main module reference, so dump doesn’t have to take a
reference of its own. (CVE-2024-53140)
In the Linux kernel, the following vulnerability has been resolved:
blk-cgroup: Fix UAF in blkcg_unpin_online() blkcg_unpin_online() walks
up the blkcg hierarchy putting the online pin. To walk up, it uses
blkcg_parent(blkcg) but it was calling that after
blkcg_destroy_blkgs(blkcg) which could free the blkcg, leading to the
following UAF:
================================================================== BUG:
KASAN: slab-use-after-free in blkcg_unpin_online+0x15a/0x270 Read of
size 8 at addr ffff8881057678c0 by task kworker/9:1/117 CPU: 9 UID: 0
PID: 117 Comm: kworker/9:1 Not tainted
6.13.0-rc1-work-00182-gb8f52214c61a-dirty #48 Hardware name: QEMU
Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022 Workqueue:
cgwb_release cgwb_release_workfn Call Trace:
dump_stack_lvl+0x27/0x80 print_report+0x151/0x710
kasan_report+0xc0/0x100 blkcg_unpin_online+0x15a/0x270
cgwb_release_workfn+0x194/0x480 process_scheduled_works+0x71b/0xe20
worker_thread+0x82a/0xbd0 kthread+0x242/0x2c0 ret_from_fork+0x33/0x70
ret_from_fork_asm+0x1a/0x30
… Freed by task 1944: kasan_save_track+0x2b/0x70
kasan_save_free_info+0x3c/0x50 __kasan_slab_free+0x33/0x50
kfree+0x10c/0x330 css_free_rwork_fn+0xe6/0xb30
process_scheduled_works+0x71b/0xe20 worker_thread+0x82a/0xbd0
kthread+0x242/0x2c0 ret_from_fork+0x33/0x70 ret_from_fork_asm+0x1a/0x30
Note that the UAF is not easy to trigger as the free path is indirected
behind a couple RCU grace periods and a work item execution. I could
only trigger it with artifical msleep() injected in
blkcg_unpin_online(). Fix it by reading the parent pointer before
destroying the blkcg’s blkg’s. (CVE-2024-56672)
Attila Szász discovered that the HFS+ file system implementation in the
Linux Kernel contained a heap overflow vulnerability. An attacker could
use a specially crafted file system image that, when mounted, could
cause a denial of service (system crash) or possibly execute arbitrary
code. (CVE-2025-0927)
Update instructions
The problem can be corrected by updating your kernel livepatch to the
following versions:
Ubuntu 20.04 LTS
aws - 110.1
aws - 110.3
azure - 110.1
azure - 110.3
azure - 110.4
gcp - 110.1
gcp - 110.3
generic - 110.1
generic - 110.3
gkeop - 110.1
ibm - 110.1
ibm - 110.3
lowlatency - 110.1
lowlatency - 110.3
oracle - 110.1
oracle - 110.3
Ubuntu 18.04 LTS
aws - 110.1
azure - 110.1
gcp - 110.1
generic - 110.1
lowlatency - 110.1
oracle - 110.1
Ubuntu 16.04 LTS
aws - 110.1
azure - 110.1
gcp - 110.1
generic - 110.1
lowlatency - 110.1
Ubuntu 22.04 LTS
aws - 110.3
aws - 110.4
azure - 110.3
azure - 110.4
gcp - 110.3
gcp - 110.4
generic - 110.3
generic - 110.4
gke - 110.3
gke - 110.4
ibm - 110.2
ibm - 110.3
ibm - 110.4
oracle - 110.3
oracle - 110.4
Ubuntu 14.04 LTS
generic - 110.1
lowlatency - 110.1
Support Information
Livepatches for supported LTS kernels will receive upgrades for a period
of up to 13 months after the build date of the kernel.
Livepatches for supported HWE kernels which are not based on an LTS
kernel version will receive upgrades for a period of up to 9 months
after the build date of the kernel, or until the end of support for that
kernel’s non-LTS distro release version, whichever is sooner.
References
- CVE-2023-52880
- CVE-2024-38558
- CVE-2024-53104
- CVE-2024-53140
- CVE-2024-56672
- CVE-2025-0927