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
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:
nfsd: fix use-after-free due to delegation race A delegation break could
arrive as soon as we've called vfs_setlease. A delegation break runs a
callback which immediately (in nfsd4_cb_recall_prepare) adds the
delegation to del_recall_lru. If we then exit nfs4_set_delegation
without hashing the delegation, it will be freed as soon as the callback
is done with it, without ever being removed from del_recall_lru.
Symptoms show up later as use-after-free or list corruption warnings,
usually in the laundromat thread. I suspect aba2072f4523 "nfsd: grant
read delegations to clients holding writes" made this bug easier to hit,
but I looked as far back as v3.0 and it looks to me it already had the
same problem. So I'm not sure where the bug was introduced; it may have
been there from the beginning. (CVE-2021-47506)
Jann Horn discovered that the watch_queue event notification subsystem
in the Linux kernel contained an out-of-bounds write vulnerability. A
local attacker could use this to cause a denial of service (system
crash) or escalate their privileges. (CVE-2022-0995)
In the Linux kernel, the following vulnerability has been resolved: net:
atlantic: eliminate double free in error handling logic Driver has a
logic leak in ring data allocation/free, where aq_ring_free could be
called multiple times on same ring, if system is under stress and got
memory allocation error. Ring pointer was used as an indicator of
failure, but this is not correct since only ring data is
allocated/deallocated. Ring itself is an array member. Changing ring
allocation functions to return error code directly. This simplifies
error handling and eliminates aq_ring_free on higher layer.
(CVE-2023-52664)
In the Linux kernel, the following vulnerability has been resolved:
ceph: prevent use-after-free in encode_cap_msg() In fs/ceph/caps.c, in
encode_cap_msg(), "use after free" error was caught by KASAN at this
line - 'ceph_buffer_get(arg->xattr_buf);'. This implies before the
refcount could be increment here, it was freed. In same file, in
"handle_cap_grant()" refcount is decremented by this line -
'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a race occurred
and resource was freed by the latter line before the former line could
increment it. encode_cap_msg() is called by __send_cap() and
__send_cap() is called by ceph_check_caps() after calling __prep_cap().
__prep_cap() is where arg->xattr_buf is assigned to ci->i_xattrs.blob.
This is the spot where the refcount must be increased to prevent "use
after free" error. (CVE-2024-26689)
In the Linux kernel, the following vulnerability has been resolved: smb:
client: fix potential UAF in smb2_is_valid_lease_break() Skip sessions
that are being teared down (status == SES_EXITING) to avoid UAF.
(CVE-2024-35864)
In the Linux kernel, the following vulnerability has been resolved: HID:
core: zero-initialize the report buffer Since the report buffer is used
by all kinds of drivers in various ways, let's zero- initialize it
during allocation to make sure that it can't be ever used to leak kernel
memory via specially-crafted report. (CVE-2024-50302)
In the Linux kernel, the following vulnerability has been resolved:
media: dvbdev: prevent the risk of out of memory access The dvbdev
contains a static variable used to store dvb minors. The behavior of it
depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set,
dvb_register_device() won't check for boundaries, as it will rely that a
previous call to dvb_register_adapter() would already be enforcing it.
On a similar way, dvb_device_open() uses the assumption that the
register functions already did the needed checks. This can be fragile if
some device ends using different calls. This also generate warnings on
static check analysers like Coverity. So, add explicit guards to prevent
potential risk of OOM issues. (CVE-2024-53063)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Fix out of bounds reads when finding clock sources The
current USB-audio driver code doesn't check bLength of each descriptor
at traversing for clock descriptors. That is, when a device provides a
bogus descriptor with a shorter bLength, the driver might hit
out-of-bounds reads. For addressing it, this patch adds sanity checks to
the validator functions for the clock descriptor traversal. When the
descriptor length is shorter than expected, it's skipped in the loop.
For the clock source and clock multiplier descriptors, we can just check
bLength against the sizeof() of each descriptor type. OTOH, the clock
selector descriptor of UAC2 and UAC3 has an array of bNrInPins elements
and two more fields at its tail, hence those have to be checked in
addition to the sizeof() check. (CVE-2024-53150)
In the Linux kernel, the following vulnerability has been resolved:
sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket BUG: KASAN:
slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0
(CVE-2024-53168)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox
devices A bogus device can provide a bNumConfigurations value that
exceeds the initial value used in usb_get_configuration for allocating
dev->config. This can lead to out-of-bounds accesses later, e.g. in
usb_destroy_configuration. (CVE-2024-53197)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix usage slab after free [ +0.000021] BUG: KASAN:
slab-use-after-free in drm_sched_entity_flush+0x6cb/0x7a0 (CVE-2024-56551)
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: Fix oops due to NULL pointer dereference in
brcmf_sdiod_sglist_rw() This patch fixes a NULL pointer dereference bug
in brcmfmac that occurs when a high 'sd_sgentry_align' value applies
(e.g. 512) and a lot of queued SKBs are sent from the pkt queue. The
problem is the number of entries in the pre-allocated sgtable, it is
nents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) >>
4 + 1. Given the default [rt]xglom_size=32 it's actually 35 which is too
small. Worst case, the pkt queue can end up with 64 SKBs. This occurs
when a new SKB is added for each original SKB if tailroom isn't enough
to hold tail_pad. At least one sg entry is needed for each SKB. So,
eventually the "skb_queue_walk loop" in brcmf_sdiod_sglist_rw may run
out of sg entries. This makes sg_next return NULL and this causes the
oops. The patch sets nents to max(rxglom_size, txglom_size) * 2 to be
able handle the worst- case. Btw. this requires only 64-35=29 * 16 (or
20 if CONFIG_NEED_SG_DMA_LENGTH) = 464 additional bytes of memory.
(CVE-2024-56593)
In the Linux kernel, the following vulnerability has been resolved: jfs:
add a check to prevent array-index-out-of-bounds in dbAdjTree When the
value of lp is 0 at the beginning of the for loop, it will become
negative in the next assignment and we should bail out. (CVE-2024-56595)
In the Linux kernel, the following vulnerability has been resolved: jfs:
array-index-out-of-bounds fix in dtReadFirst The value of stbl can be
sometimes out of bounds due to a bad filesystem. Added a check with
appopriate return of error code in that case. (CVE-2024-56598)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btmtk: avoid UAF in btmtk_process_coredump hci_devcd_append
may lead to the release of the skb, so it cannot be accessed once it is
called. (CVE-2024-56653)
In the Linux kernel, the following vulnerability has been resolved:
drm/dp_mst: Ensure mst_primary pointer is valid in
drm_dp_mst_handle_up_req() While receiving an MST up request message
from one thread in drm_dp_mst_handle_up_req(), the MST topology could be
removed from another thread via drm_dp_mst_topology_mgr_set_mst(false),
freeing mst_primary and setting drm_dp_mst_topology_mgr::mst_primary to
NULL. This could lead to a NULL deref/use-after-free of mst_primary in
drm_dp_mst_handle_up_req(). Avoid the above by holding a reference for
mst_primary in drm_dp_mst_handle_up_req() while it's used. v2: Fix
kfreeing the request if getting an mst_primary reference fails.
(CVE-2024-57798)
Update instructions
The problem can be corrected by updating your kernel livepatch to the
following versions:
Ubuntu 20.04 LTS
aws - 112.1
aws - 112.2
azure - 112.1
azure - 112.2
gcp - 112.1
gcp - 112.2
generic - 112.1
generic - 112.2
gkeop - 112.1
ibm - 112.1
lowlatency - 112.1
lowlatency - 112.2
oracle - 112.1
Ubuntu 18.04 LTS
aws - 112.1
azure - 112.1
gcp - 112.1
generic - 112.1
lowlatency - 112.1
oracle - 112.1
Ubuntu 16.04 LTS
aws - 112.1
azure - 112.1
gcp - 112.1
generic - 112.1
lowlatency - 112.1
Ubuntu 22.04 LTS
aws - 112.1
aws - 112.2
azure - 112.1
azure - 112.2
gcp - 112.1
generic - 112.1
gke - 112.1
ibm - 112.1
oracle - 112.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-2021-47506
- CVE-2022-0995
- CVE-2023-52664
- CVE-2024-26689
- CVE-2024-35864
- CVE-2024-50302
- CVE-2024-53063
- CVE-2024-53150
- CVE-2024-53168
- CVE-2024-53197
- CVE-2024-56551
- CVE-2024-56593
- CVE-2024-56595
- CVE-2024-56598
- CVE-2024-56653
- CVE-2024-57798
No comments:
Post a Comment