SUSE-IU-2025:381-1
SUSE Image
security@suse.de
SUSE Security Team
SUSE Image SUSE-IU-2025:381-1
Interim
1
1
2025-10-07T15:00:36Z
current
2025-01-30T01:00:00Z
2025-01-30T01:00:00Z
cve-database/bin/generate-cvrf-publiccloud.pl
2021-02-18T01:00:00Z
Image update for SUSE-IU-2025:381-1 / google/sle-micro-5-2-byos-v20250130-x86-64
This image update for google/sle-micro-5-2-byos-v20250130-x86-64 contains the following changes:
Package 000release-packages:SUSE-MicroOS-release was updated:
Package aaa_base was updated:
- Add patch git-50-845b509c9a005340a0455cb8a7fe084d1b8f1946.patch * Add mc helpers for both tcsh and bash resources (boo#1203617)
Package containerd was updated:
- Update to containerd v1.7.23. Upstream release notes: <https://github.com/containerd/containerd/releases/tag/v1.7.23>
- Rebase patches:
* 0001-BUILD-SLE12-revert-btrfs-depend-on-kernel-UAPI-inste.patch
- Update to containerd v1.7.22. Upstream release notes:
<https://github.com/containerd/containerd/releases/tag/v1.7.22>
- Bump minimum Go version to 1.22.
- Rebase patches:
* 0001-BUILD-SLE12-revert-btrfs-depend-on-kernel-UAPI-inste.patch
Package docker was updated:
- Update docker-buildx to v0.19.2. See upstream changelog online at <https://github.com/docker/buildx/releases/tag/v0.19.2>.
Some notable changelogs from the last update:
* <https://github.com/docker/buildx/releases/tag/v0.19.0>
* <https://github.com/docker/buildx/releases/tag/v0.18.0>
- Update to Go 1.22.
- Add a new toggle file /etc/docker/suse-secrets-enable which allows users to
disable the SUSEConnect integration with Docker (which creates special mounts
in /run/secrets to allow container-suseconnect to authenticate containers
with registries on registered hosts). bsc#1231348 bsc#1232999
In order to disable these mounts, just do
echo 0 > /etc/docker/suse-secrets-enable
and restart Docker. In order to re-enable them, just do
echo 1 > /etc/docker/suse-secrets-enable
and restart Docker. Docker will output information on startup to tell you
whether the SUSE secrets feature is enabled or not.
* 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch
- Disable docker-buildx builds for SLES. It turns out that build containers
with docker-buildx don't currently get the SUSE secrets mounts applied,
meaning that container-suseconnect doesn't work when building images.
bsc#1233819
- Add docker-integration-tests-devel subpackage for building and running the
upstream Docker integration tests on machines to test that Docker works
properly. Users should not install this package.
- docker-rpmlintrc updated to include allow-list for all of the integration
tests package, since it contains a bunch of stuff that wouldn't normally be
allowed.
- Remove DOCKER_NETWORK_OPTS from docker.service. This was removed from
sysconfig a long time ago, and apparently this causes issues with systemd in
some cases.
- Further merge docker and docker-stable specfiles to minimise the differences.
The main thing is that we now include both halves of the
Conflicts/Provides/Obsoletes dance in both specfiles.
- Update to docker-buildx v0.17.1 to match standalone docker-buildx package we
are replacing. See upstream changelog online at
<https://github.com/docker/buildx/releases/tag/v0.17.1>
- Allow users to disable SUSE secrets support by setting
DOCKER_SUSE_SECRETS_ENABLE=0 in /etc/sysconfig/docker. bsc#1231348
bsc#1232999
- Add %{_sysconfdir}/audit/rules.d to filelist.
- Mark docker-buildx as required since classic "docker build" has been
deprecated since Docker 23.0. bsc#1230331
- Import docker-buildx v0.16.2 as a subpackage. Previously this was a separate
package, but with docker-stable it will be necessary to maintain the packages
together and it makes more sense to have them live in the same OBS package.
bsc#1230333
- Make some minor name macro updates to help with the docker-stable package
fork.
- Update to Docker 26.1.5-ce. See upstream changelog online at
<https://docs.docker.com/engine/release-notes/26.1/#2615>
bsc#1230294
- This update includes fixes for:
* CVE-2024-41110. bsc#1228324
* CVE-2023-47108. bsc#1217070
* CVE-2023-45142. bsc#1228553
- Rebase patches:
* 0001-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
* 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch
* 0003-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
* 0004-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
* 0005-SLE12-revert-apparmor-remove-version-conditionals-fr.patch
* 0006-bsc1221916-update-to-patched-buildkit-version-to-fix.patch
* 0007-bsc1214855-volume-use-AtomicWriteFile-to-save-volume.patch
* cli-0001-docs-include-required-tools-in-source-tree.patch
Package kernel-default was updated:
- smb: client: fix use-after-free of signing key (bsc#1234921, CVE-2024-53179).
- commit 3b35702
- smb: client: fix use-after-free of signing key (bsc#1234921,
CVE-2024-53179).
- commit c3470ed
- scsi: sg: Fix slab-use-after-free read in sg_release()
(CVE-2024-56631 bsc#1235480).
- commit 39e048d
- 9p/xen: fix release of IRQ (CVE-2024-56704 bsc#1235584).
- commit 19bad6c
- NFSv4.0: Fix a use-after-free problem in the asynchronous open()
(CVE-2024-53173 bsc#1234891).
- commit a94e553
- Bluetooth: L2CAP: do not leave dangling sk pointer on error
in l2cap_sock_create() (CVE-2024-56605 bsc#1235061).
- commit 20f98a1
- media: s5p_cec: limit msg.len to CEC_MAX_MSG_SIZE
(CVE-2022-49035 bsc#1215304).
- commit da4fde6
- net: mana: Increase the DEF_RX_BUFFERS_PER_QUEUE to 1024
(bsc#1235246).
- commit 4fbdfe2
- wifi: mwifiex: Fix memcpy() field-spanning write warning in
mwifiex_config_scan() (CVE-2024-56539 bsc#1234963).
- commit ee60ab9
- vfio/pci: Properly hide first-in-list PCIe extended capability
(bsc#1235004 CVE-2024-53214).
- commit bf247b6
- Bluetooth: RFCOMM: avoid leaving dangling sk pointer in
rfcomm_sock_alloc() (bsc#1235056 CVE-2024-56604).
- commit 59e9445
- Bluetooth: Consolidate code around sk_alloc into a helper
function (bsc#1235056 CVE-2024-56604).
Refresh
patches.suse/Bluetooth-SCO-Fix-UAF-on-sco_sock_timeout.patch.
- commit 8ac1fe3
- Bluetooth: hci_sock: purge socket queues in the destruct()
callback (bsc#1235056 CVE-2024-56604).
- commit 5fdf3eb
- hfsplus: don't query the device logical block size multiple
times (bsc#1235073 CVE-2024-56548).
- commit 14dfa57
- wifi: ath9k: add range check for conn_rsp_epid in
htc_connect_service() (CVE-2024-53156 bsc#1234846).
- commit 4be0730
- ALSA: 6fire: Release resources at card release (CVE-2024-53239
bsc#1235054).
- commit 21c90ac
- NFSD: Prevent a potential integer overflow (CVE-2024-53146
bsc#1234853).
- commit eb512aa
- Update
patches.suse/Bluetooth-hci_event-Align-BR-EDR-JUST_WORKS-paring-w.patch
(git-fixes bsc#1230697 CVE-2024-8805 CVE-2024-53144
bsc#1234690).
- commit 192af19
- Update
patches.suse/net-nfc-llcp-Add-lock-when-modifying-device-list.patch
(CVE-2023-52524 bsc#1220937 bsc#1220927).
- commit 6f47795
- xen/netfront: fix crash when removing device (XSA-465
CVE-2024-53240 bsc#1234281).
- commit b0ad117
- Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE
(git-fixes, bsc#1230697, CVE-2024-8805).
- commit da492aa
- Update
patches.suse/initramfs-avoid-filename-buffer-overrun.patch
(CVE-2024-53142 bsc#1232436).
- commit 160662b
Package cryptsetup was updated:
- luksFormat succeeds despite creating corrupt device [bsc#1234273] * Add a better warning if luksFormat ends with image without any space for data.
* Print warning early if LUKS container is too small for activation.
* Add patches:
- cryptsetup-Add-a-better-warning-if-luksFormat-no-space-for-data.patch
- cryptsetup-Print-warning-early-if-LUKS-container-is-too-small-for-activation.patch
Package libzypp was updated:
- Url: queryparams without value should not have a trailing "=".- version 17.35.16 (35)
- Url query part: `=` is a safe char in value (bsc#1234304)
- RpmDb: Recognize rpmdb.sqlite as database file (#593)
- Fix typo (fixes #592)
- cmake: check location of fcgi header and adjust include
accordingly. On Debian and derivatives the fcgi headers
are not stored in a fastcgi/ subdirectory.(#590)
- version 17.35.15 (35)
Package python-Jinja2 was updated:
Package rsync was updated:
- Fix FLAG_GOT_DIR_FLIST collission with FLAG_HLINKED * Added rsync-fix-FLAG_GOT_DIR_FLIST.patch
- Security update,CVE-2024-12747, bsc#1235475 race condition in handling symbolic links
* Added rsync-CVE-2024-12747.patch
- Security update, fix multiple vulnerabilities:
* CVE-2024-12085, bsc#1234101 - Info Leak via uninitialized Stack contents defeats ASLR
* CVE-2024-12086, bsc#1234102 - Server leaks arbitrary client files
* CVE-2024-12087, bsc#1234103 - Server can make client write files outside of destination directory
using symbolic links
* CVE-2024-12088, bsc#1234104 - --safe-links Bypass
* Added rsync-CVE-2024-12085.patch
* Added rsync-CVE-2024-12086_01.patch
* Added rsync-CVE-2024-12086_02.patch
* Added rsync-CVE-2024-12086_03.patch
* Added rsync-CVE-2024-12086_04.patch
* Added rsync-CVE-2024-12087_01.patch
* Added rsync-CVE-2024-12087_02.patch
* Added rsync-CVE-2024-12088.patch
* Added rsync-fix-compile-missing-my_alloc_ref.patch
Package zypper was updated:
- info: Allow to query a specific version (jsc#PED-11268) To query for a specific version simply append "-<version>" or
"-<version>-<release>" to the "<name>" pattern. Note that the
edition part must always match exactly.
- version 1.14.79
The CVRF data is provided by SUSE under the Creative Commons License 4.0 with Attribution (CC-BY-4.0).
https://publiccloudimagechangeinfo.suse.com/google/sle-micro-5-2-byos-v20250130-x86-64/
Public Cloud Image Info
https://www.suse.com/support/security/rating/
SUSE Security Ratings
Public Cloud Image google/sle-micro-5-2-byos-v20250130-x86-64
aaa_base-84.87+git20180409.04c9dae-150300.10.23.1
containerd-1.7.23-150000.120.1
docker-26.1.5_ce-150000.212.1
kernel-default-5.3.18-150300.59.188.1
libcryptsetup12-2.3.7-150300.3.11.2
libzypp-17.35.16-150200.141.1
python3-Jinja2-2.10.1-150000.3.18.1
rsync-3.2.3-150000.4.33.1
zypper-1.14.79-150200.99.1
zypper-needs-restarting-1.14.79-150200.99.1
aaa_base-84.87+git20180409.04c9dae-150300.10.23.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250130-x86-64
containerd-1.7.23-150000.120.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250130-x86-64
docker-26.1.5_ce-150000.212.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250130-x86-64
kernel-default-5.3.18-150300.59.188.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250130-x86-64
libcryptsetup12-2.3.7-150300.3.11.2 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250130-x86-64
libzypp-17.35.16-150200.141.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250130-x86-64
python3-Jinja2-2.10.1-150000.3.18.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250130-x86-64
rsync-3.2.3-150000.4.33.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250130-x86-64
zypper-1.14.79-150200.99.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250130-x86-64
zypper-needs-restarting-1.14.79-150200.99.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250130-x86-64
In the Linux kernel, the following vulnerability has been resolved:
media: s5p_cec: limit msg.len to CEC_MAX_MSG_SIZE
I expect that the hardware will have limited this to 16, but just in
case it hasn't, check for this corner case.
CVE-2022-49035
important
OpenTelemetry-Go Contrib is a collection of third-party packages for OpenTelemetry-Go. A handler wrapper out of the box adds labels `http.user_agent` and `http.method` that have unbound cardinality. It leads to the server's potential memory exhaustion when many malicious requests are sent to it. HTTP header User-Agent or HTTP method for requests can be easily set by an attacker to be random and long. The library internally uses `httpconv.ServerRequest` that records every value for HTTP `method` and `User-Agent`. In order to be affected, a program has to use the `otelhttp.NewHandler` wrapper and not filter any unknown HTTP methods or User agents on the level of CDN, LB, previous middleware, etc. Version 0.44.0 fixed this issue when the values collected for attribute `http.request.method` were changed to be restricted to a set of well-known values and other high cardinality attributes were removed. As a workaround to stop being affected, `otelhttp.WithFilter()` can be used, but it requires manual careful configuration to not log certain requests entirely. For convenience and safe usage of this library, it should by default mark with the label `unknown` non-standard HTTP methods and User agents to show that such requests were made but do not increase cardinality. In case someone wants to stay with the current behavior, library API should allow to enable it.
CVE-2023-45142
important
OpenTelemetry-Go Contrib is a collection of third-party packages for OpenTelemetry-Go. Prior to version 0.46.0, the grpc Unary Server Interceptor out of the box adds labels `net.peer.sock.addr` and `net.peer.sock.port` that have unbound cardinality. It leads to the server's potential memory exhaustion when many malicious requests are sent. An attacker can easily flood the peer address and port for requests. Version 0.46.0 contains a fix for this issue. As a workaround to stop being affected, a view removing the attributes can be used. The other possibility is to disable grpc metrics instrumentation by passing `otelgrpc.WithMeterProvider` option with `noop.NewMeterProvider`.
CVE-2023-47108
important
In the Linux kernel, the following vulnerability has been resolved:
net: nfc: llcp: Add lock when modifying device list
The device list needs its associated lock held when modifying it, or the
list could become corrupted, as syzbot discovered.
CVE-2023-52524
moderate
A flaw was found in rsync which could be triggered when rsync compares file checksums. This flaw allows an attacker to manipulate the checksum length (s2length) to cause a comparison between a checksum and uninitialized memory and leak one byte of uninitialized stack data at a time.
CVE-2024-12085
moderate
A flaw was found in rsync. It could allow a server to enumerate the contents of an arbitrary file from the client's machine. This issue occurs when files are being copied from a client to a server. During this process, the rsync server will send checksums of local data to the client to compare with in order to determine what data needs to be sent to the server. By sending specially constructed checksum values for arbitrary files, an attacker may be able to reconstruct the data of those files byte-by-byte based on the responses from the client.
CVE-2024-12086
moderate
A path traversal vulnerability exists in rsync. It stems from behavior enabled by the `--inc-recursive` option, a default-enabled option for many client options and can be enabled by the server even if not explicitly enabled by the client. When using the `--inc-recursive` option, a lack of proper symlink verification coupled with deduplication checks occurring on a per-file-list basis could allow a server to write files outside of the client's intended destination directory. A malicious server could write malicious files to arbitrary locations named after valid directories/paths on the client.
CVE-2024-12087
important
A flaw was found in rsync. When using the `--safe-links` option, the rsync client fails to properly verify if a symbolic link destination sent from the server contains another symbolic link within it. This results in a path traversal vulnerability, which may lead to arbitrary file write outside the desired directory.
CVE-2024-12088
moderate
A flaw was found in rsync. This vulnerability arises from a race condition during rsync's handling of symbolic links. Rsync's default behavior when encountering symbolic links is to skip them. If an attacker replaced a regular file with a symbolic link at the right time, it was possible to bypass the default behavior and traverse symbolic links. Depending on the privileges of the rsync process, an attacker could leak sensitive information, potentially leading to privilege escalation.
CVE-2024-12747
moderate
Moby is an open-source project created by Docker for software containerization. A security vulnerability has been detected in certain versions of Docker Engine, which could allow an attacker to bypass authorization plugins (AuthZ) under specific circumstances. The base likelihood of this being exploited is low.
Using a specially-crafted API request, an Engine API client could make the daemon forward the request or response to an authorization plugin without the body. In certain circumstances, the authorization plugin may allow a request which it would have otherwise denied if the body had been forwarded to it.
A security issue was discovered In 2018, where an attacker could bypass AuthZ plugins using a specially crafted API request. This could lead to unauthorized actions, including privilege escalation. Although this issue was fixed in Docker Engine v18.09.1 in January 2019, the fix was not carried forward to later major versions, resulting in a regression. Anyone who depends on authorization plugins that introspect the request and/or response body to make access control decisions is potentially impacted.
Docker EE v19.03.x and all versions of Mirantis Container Runtime are not vulnerable.
docker-ce v27.1.1 containes patches to fix the vulnerability. Patches have also been merged into the master, 19.03, 20.0, 23.0, 24.0, 25.0, 26.0, and 26.1 release branches. If one is unable to upgrade immediately, avoid using AuthZ plugins and/or restrict access to the Docker API to trusted parties, following the principle of least privilege.
CVE-2024-41110
critical
In the Linux kernel, the following vulnerability has been resolved:
initramfs: avoid filename buffer overrun
The initramfs filename field is defined in
Documentation/driver-api/early-userspace/buffer-format.rst as:
37 cpio_file := ALGN(4) + cpio_header + filename + "\0" + ALGN(4) + data
...
55 ============= ================== =========================
56 Field name Field size Meaning
57 ============= ================== =========================
...
70 c_namesize 8 bytes Length of filename, including final \0
When extracting an initramfs cpio archive, the kernel's do_name() path
handler assumes a zero-terminated path at @collected, passing it
directly to filp_open() / init_mkdir() / init_mknod().
If a specially crafted cpio entry carries a non-zero-terminated filename
and is followed by uninitialized memory, then a file may be created with
trailing characters that represent the uninitialized memory. The ability
to create an initramfs entry would imply already having full control of
the system, so the buffer overrun shouldn't be considered a security
vulnerability.
Append the output of the following bash script to an existing initramfs
and observe any created /initramfs_test_fname_overrunAA* path. E.g.
./reproducer.sh | gzip >> /myinitramfs
It's easiest to observe non-zero uninitialized memory when the output is
gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(),
rather than the initrd_start+initrd_size block.
---- reproducer.sh ----
nilchar="A" # change to "\0" to properly zero terminate / pad
magic="070701"
ino=1
mode=$(( 0100777 ))
uid=0
gid=0
nlink=1
mtime=1
filesize=0
devmajor=0
devminor=1
rdevmajor=0
rdevminor=0
csum=0
fname="initramfs_test_fname_overrun"
namelen=$(( ${#fname} + 1 )) # plus one to account for terminator
printf "%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s" \
$magic $ino $mode $uid $gid $nlink $mtime $filesize \
$devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname
termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) ))
printf "%.s${nilchar}" $(seq 1 $termpadlen)
---- reproducer.sh ----
Symlink filename fields handled in do_symlink() won't overrun past the
data segment, due to the explicit zero-termination of the symlink
target.
Fix filename buffer overrun by aborting the initramfs FSM if any cpio
entry doesn't carry a zero-terminator at the expected (name_len - 1)
offset.
CVE-2024-53142
moderate
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Prevent a potential integer overflow
If the tag length is >= U32_MAX - 3 then the "length + 4" addition
can result in an integer overflow. Address this by splitting the
decoding into several steps so that decode_cb_compound4res() does
not have to perform arithmetic on the unsafe length value.
CVE-2024-53146
important
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()
I found the following bug in my fuzzer:
UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51
index 255 is out of range for type 'htc_endpoint [22]'
CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Workqueue: events request_firmware_work_func
Call Trace:
<TASK>
dump_stack_lvl+0x180/0x1b0
__ubsan_handle_out_of_bounds+0xd4/0x130
htc_issue_send.constprop.0+0x20c/0x230
? _raw_spin_unlock_irqrestore+0x3c/0x70
ath9k_wmi_cmd+0x41d/0x610
? mark_held_locks+0x9f/0xe0
...
Since this bug has been confirmed to be caused by insufficient verification
of conn_rsp_epid, I think it would be appropriate to add a range check for
conn_rsp_epid to htc_connect_service() to prevent the bug from occurring.
CVE-2024-53156
important
In the Linux kernel, the following vulnerability has been resolved:
NFSv4.0: Fix a use-after-free problem in the asynchronous open()
Yang Erkun reports that when two threads are opening files at the same
time, and are forced to abort before a reply is seen, then the call to
nfs_release_seqid() in nfs4_opendata_free() can result in a
use-after-free of the pointer to the defunct rpc task of the other
thread.
The fix is to ensure that if the RPC call is aborted before the call to
nfs_wait_on_sequence() is complete, then we must call nfs_release_seqid()
in nfs4_open_release() before the rpc_task is freed.
CVE-2024-53173
important
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free of signing key
Customers have reported use-after-free in @ses->auth_key.response with
SMB2.1 + sign mounts which occurs due to following race:
task A task B
cifs_mount()
dfs_mount_share()
get_session()
cifs_mount_get_session() cifs_send_recv()
cifs_get_smb_ses() compound_send_recv()
cifs_setup_session() smb2_setup_request()
kfree_sensitive() smb2_calc_signature()
crypto_shash_setkey() *UAF*
Fix this by ensuring that we have a valid @ses->auth_key.response by
checking whether @ses->ses_status is SES_GOOD or SES_EXITING with
@ses->ses_lock held. After commit 24a9799aa8ef ("smb: client: fix UAF
in smb2_reconnect_server()"), we made sure to call ->logoff() only
when @ses was known to be good (e.g. valid ->auth_key.response), so
it's safe to access signing key when @ses->ses_status == SES_EXITING.
CVE-2024-53179
important
In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: Properly hide first-in-list PCIe extended capability
There are cases where a PCIe extended capability should be hidden from
the user. For example, an unknown capability (i.e., capability with ID
greater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionally
chosen to be hidden from the user.
Hiding a capability is done by virtualizing and modifying the 'Next
Capability Offset' field of the previous capability so it points to the
capability after the one that should be hidden.
The special case where the first capability in the list should be hidden
is handled differently because there is no previous capability that can
be modified. In this case, the capability ID and version are zeroed
while leaving the next pointer intact. This hides the capability and
leaves an anchor for the rest of the capability list.
However, today, hiding the first capability in the list is not done
properly if the capability is unknown, as struct
vfio_pci_core_device->pci_config_map is set to the capability ID during
initialization but the capability ID is not properly checked later when
used in vfio_config_do_rw(). This leads to the following warning [1] and
to an out-of-bounds access to ecap_perms array.
Fix it by checking cap_id in vfio_config_do_rw(), and if it is greater
than PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for direct
read only access instead of the ecap_perms array.
Note that this is safe since the above is the only case where cap_id can
exceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, which
are already checked before).
[1]
WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]
CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1
(snip)
Call Trace:
<TASK>
? show_regs+0x69/0x80
? __warn+0x8d/0x140
? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]
? report_bug+0x18f/0x1a0
? handle_bug+0x63/0xa0
? exc_invalid_op+0x19/0x70
? asm_exc_invalid_op+0x1b/0x20
? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]
? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core]
vfio_pci_rw+0x101/0x1b0 [vfio_pci_core]
vfio_pci_core_read+0x1d/0x30 [vfio_pci_core]
vfio_device_fops_read+0x27/0x40 [vfio]
vfs_read+0xbd/0x340
? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio]
? __rseq_handle_notify_resume+0xa4/0x4b0
__x64_sys_pread64+0x96/0xc0
x64_sys_call+0x1c3d/0x20d0
do_syscall_64+0x4d/0x120
entry_SYSCALL_64_after_hwframe+0x76/0x7e
CVE-2024-53214
important
In the Linux kernel, the following vulnerability has been resolved:
ALSA: 6fire: Release resources at card release
The current 6fire code tries to release the resources right after the
call of usb6fire_chip_abort(). But at this moment, the card object
might be still in use (as we're calling snd_card_free_when_closed()).
For avoid potential UAFs, move the release of resources to the card's
private_free instead of the manual call of usb6fire_chip_destroy() at
the USB disconnect callback.
CVE-2024-53239
important
In the Linux kernel, the following vulnerability has been resolved:
xen/netfront: fix crash when removing device
When removing a netfront device directly after a suspend/resume cycle
it might happen that the queues have not been setup again, causing a
crash during the attempt to stop the queues another time.
Fix that by checking the queues are existing before trying to stop
them.
This is XSA-465 / CVE-2024-53240.
CVE-2024-53240
moderate
Jinja is an extensible templating engine. Prior to 3.1.5, An oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to store a reference to a malicious string's format method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox. This vulnerability is fixed in 3.1.5.
CVE-2024-56326
important
In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()
Replace one-element array with a flexible-array member in `struct
mwifiex_ie_types_wildcard_ssid_params` to fix the following warning
on a MT8173 Chromebook (mt8173-elm-hana):
[ 356.775250] ------------[ cut here ]------------
[ 356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcard_ssid_tlv->ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1)
[ 356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]
The "(size 6)" above is exactly the length of the SSID of the network
this device was connected to. The source of the warning looks like:
ssid_len = user_scan_in->ssid_list[i].ssid_len;
[...]
memcpy(wildcard_ssid_tlv->ssid,
user_scan_in->ssid_list[i].ssid, ssid_len);
There is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this
struct, but it already didn't account for the size of the one-element
array, so it doesn't need to be changed.
CVE-2024-56539
important
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: don't query the device logical block size multiple times
Devices block sizes may change. One of these cases is a loop device by
using ioctl LOOP_SET_BLOCK_SIZE.
While this may cause other issues like IO being rejected, in the case of
hfsplus, it will allocate a block by using that size and potentially write
out-of-bounds when hfsplus_read_wrapper calls hfsplus_submit_bio and the
latter function reads a different io_size.
Using a new min_io_size initally set to sb_min_blocksize works for the
purposes of the original fix, since it will be set to the max between
HFSPLUS_SECTOR_SIZE and the first seen logical block size. We still use the
max between HFSPLUS_SECTOR_SIZE and min_io_size in case the latter is not
initialized.
Tested by mounting an hfsplus filesystem with loop block sizes 512, 1024
and 4096.
The produced KASAN report before the fix looks like this:
[ 419.944641] ==================================================================
[ 419.945655] BUG: KASAN: slab-use-after-free in hfsplus_read_wrapper+0x659/0xa0a
[ 419.946703] Read of size 2 at addr ffff88800721fc00 by task repro/10678
[ 419.947612]
[ 419.947846] CPU: 0 UID: 0 PID: 10678 Comm: repro Not tainted 6.12.0-rc5-00008-gdf56e0f2f3ca #84
[ 419.949007] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
[ 419.950035] Call Trace:
[ 419.950384] <TASK>
[ 419.950676] dump_stack_lvl+0x57/0x78
[ 419.951212] ? hfsplus_read_wrapper+0x659/0xa0a
[ 419.951830] print_report+0x14c/0x49e
[ 419.952361] ? __virt_addr_valid+0x267/0x278
[ 419.952979] ? kmem_cache_debug_flags+0xc/0x1d
[ 419.953561] ? hfsplus_read_wrapper+0x659/0xa0a
[ 419.954231] kasan_report+0x89/0xb0
[ 419.954748] ? hfsplus_read_wrapper+0x659/0xa0a
[ 419.955367] hfsplus_read_wrapper+0x659/0xa0a
[ 419.955948] ? __pfx_hfsplus_read_wrapper+0x10/0x10
[ 419.956618] ? do_raw_spin_unlock+0x59/0x1a9
[ 419.957214] ? _raw_spin_unlock+0x1a/0x2e
[ 419.957772] hfsplus_fill_super+0x348/0x1590
[ 419.958355] ? hlock_class+0x4c/0x109
[ 419.958867] ? __pfx_hfsplus_fill_super+0x10/0x10
[ 419.959499] ? __pfx_string+0x10/0x10
[ 419.960006] ? lock_acquire+0x3e2/0x454
[ 419.960532] ? bdev_name.constprop.0+0xce/0x243
[ 419.961129] ? __pfx_bdev_name.constprop.0+0x10/0x10
[ 419.961799] ? pointer+0x3f0/0x62f
[ 419.962277] ? __pfx_pointer+0x10/0x10
[ 419.962761] ? vsnprintf+0x6c4/0xfba
[ 419.963178] ? __pfx_vsnprintf+0x10/0x10
[ 419.963621] ? setup_bdev_super+0x376/0x3b3
[ 419.964029] ? snprintf+0x9d/0xd2
[ 419.964344] ? __pfx_snprintf+0x10/0x10
[ 419.964675] ? lock_acquired+0x45c/0x5e9
[ 419.965016] ? set_blocksize+0x139/0x1c1
[ 419.965381] ? sb_set_blocksize+0x6d/0xae
[ 419.965742] ? __pfx_hfsplus_fill_super+0x10/0x10
[ 419.966179] mount_bdev+0x12f/0x1bf
[ 419.966512] ? __pfx_mount_bdev+0x10/0x10
[ 419.966886] ? vfs_parse_fs_string+0xce/0x111
[ 419.967293] ? __pfx_vfs_parse_fs_string+0x10/0x10
[ 419.967702] ? __pfx_hfsplus_mount+0x10/0x10
[ 419.968073] legacy_get_tree+0x104/0x178
[ 419.968414] vfs_get_tree+0x86/0x296
[ 419.968751] path_mount+0xba3/0xd0b
[ 419.969157] ? __pfx_path_mount+0x10/0x10
[ 419.969594] ? kmem_cache_free+0x1e2/0x260
[ 419.970311] do_mount+0x99/0xe0
[ 419.970630] ? __pfx_do_mount+0x10/0x10
[ 419.971008] __do_sys_mount+0x199/0x1c9
[ 419.971397] do_syscall_64+0xd0/0x135
[ 419.971761] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 419.972233] RIP: 0033:0x7c3cb812972e
[ 419.972564] Code: 48 8b 0d f5 46 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c2 46 0d 00 f7 d8 64 89 01 48
[ 419.974371] RSP: 002b:00007ffe30632548 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5
[ 419.975048] RAX: ffffffffffffffda RBX: 00007ffe306328d8 RCX: 00007c3cb812972e
[ 419.975701] RDX: 0000000020000000 RSI: 0000000020000c80 RDI:
---truncated---
CVE-2024-56548
important
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc()
bt_sock_alloc() attaches allocated sk object to the provided sock object.
If rfcomm_dlc_alloc() fails, we release the sk object, but leave the
dangling pointer in the sock object, which may cause use-after-free.
Fix this by swapping calls to bt_sock_alloc() and rfcomm_dlc_alloc().
CVE-2024-56604
important
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()
bt_sock_alloc() allocates the sk object and attaches it to the provided
sock object. On error l2cap_sock_alloc() frees the sk object, but the
dangling pointer is still attached to the sock object, which may create
use-after-free in other code.
CVE-2024-56605
important
In the Linux kernel, the following vulnerability has been resolved:
scsi: sg: Fix slab-use-after-free read in sg_release()
Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN:
BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30
kernel/locking/lockdep.c:5838
__mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912
sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407
In sg_release(), the function kref_put(&sfp->f_ref, sg_remove_sfp) is
called before releasing the open_rel_lock mutex. The kref_put() call may
decrement the reference count of sfp to zero, triggering its cleanup
through sg_remove_sfp(). This cleanup includes scheduling deferred work
via sg_remove_sfp_usercontext(), which ultimately frees sfp.
After kref_put(), sg_release() continues to unlock open_rel_lock and may
reference sfp or sdp. If sfp has already been freed, this results in a
slab-use-after-free error.
Move the kref_put(&sfp->f_ref, sg_remove_sfp) call after unlocking the
open_rel_lock mutex. This ensures:
- No references to sfp or sdp occur after the reference count is
decremented.
- Cleanup functions such as sg_remove_sfp() and
sg_remove_sfp_usercontext() can safely execute without impacting the
mutex handling in sg_release().
The fix has been tested and validated by syzbot. This patch closes the
bug reported at the following syzkaller link and ensures proper
sequencing of resource cleanup and mutex operations, eliminating the
risk of use-after-free errors in sg_release().
CVE-2024-56631
important
In the Linux kernel, the following vulnerability has been resolved:
9p/xen: fix release of IRQ
Kernel logs indicate an IRQ was double-freed.
Pass correct device ID during IRQ release.
[Dominique: remove confusing variable reset to 0]
CVE-2024-56704
moderate
BlueZ HID over GATT Profile Improper Access Control Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of BlueZ. Authentication is not required to exploit this vulnerability.
The specific flaw exists within the implementation of the HID over GATT Profile. The issue results from the lack of authorization prior to allowing access to functionality. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-25177.
CVE-2024-8805
important