SUSE-IU-2025:2021-1 SUSE Image security@suse.de SUSE Security Team SUSE Image SUSE-IU-2025:2021-1 Interim 1 1 2026-03-19T08:55:24Z current 2025-07-21T01:00:00Z 2025-07-21T01:00:00Z cve-database/bin/generate-cvrf-publiccloud.pl 2021-02-18T01:00:00Z Image update for SUSE-IU-2025:2021-1 / google/sles-15-sp4-chost-byos-v20250721-x86-64 This image update for google/sles-15-sp4-chost-byos-v20250721-x86-64 contains the following changes: Package aaa_base was updated: - Add patch git-51-fbf7ee9dc9cd970532a54eed6472d7f3b0e7f431.patch * If a user switches the login shell respect the already set PATH environment (bsc#1235481) - add patch aaa_base-rc.status.patch (bsc#1236033) (no git, file is gone in factory/tumbleweed) update detection for systemd in rc.status, mountpoint for cgroup changed with cgroup2, so just check if pid 1 is systemd - Add patch git-50-845b509c9a005340a0455cb8a7fe084d1b8f1946.patch * Add mc helpers for both tcsh and bash resources (boo#1203617) Package apparmor was updated: - Add dac_read_search capability for unix_chkpwd to allow it to read the shadow file even if it has 000 permissions. This is needed after the CVE-2024-10041 fix in PAM. * unix-chkpwd-add-read-capability.path, bsc#1241678 - Allow pam_unix to execute unix_chkpwd with abi/3.0 - remove dovecot-unix_chkpwd.diff - Add allow-pam_unix-to-execute-unix_chkpwd.patch - Add revert-abi-change-for-unix_chkpwd.patch (bsc#1234452, bsc#1232234) - Add dovecot-unix_chkpwd.diff to allow dovecot-auth to execute unix_chkpwd, and add a profile for unix_chkpwd. This is needed for PAM with CVE-2024-10041 (bsc#1234452) Package bash was updated: - Add patch boo1227807.patch * Load completion file eveh if a brace expansion is in the command line included (boo#1227807) Package bind was updated: - Limit additional section processing for large RDATA sets. When answering queries, don’t add data to the additional section if the answer has more than 13 names in the RDATA. This limits the number of lookups into the database(s) during a single client query, reducing the query-processing load. (CVE-2024-11187) [bsc#1236596, bind-9.16-CVE-2024-11187.patch] Package ca-certificates-mozilla was updated: - revert the distrusted certs for now. originally these only distrust &quot;new issued&quot; certs starting after a certain date, while old certs should still work. (bsc#1240343) - remove-distrusted.patch: removed - explit remove distruted certs, as the distrust does not get exported correctly and the SSL certs are still trusted. (bsc#1240343) - Entrust.net Premium 2048 Secure Server CA - Entrust Root Certification Authority - AffirmTrust Commercial - AffirmTrust Networking - AffirmTrust Premium - AffirmTrust Premium ECC - Entrust Root Certification Authority - G2 - Entrust Root Certification Authority - EC1 - GlobalSign Root E46 - GLOBALTRUST 2020 - remove-distrusted.patch: apply to certdata.txt - Fix awk to compare (missing a =) and give the following output: [#] NSS_BUILTINS_LIBRARY_VERSION &quot;2.74&quot; - pass file argument to awk (bsc#1240009) - update to 2.74 state of Mozilla SSL root CAs: Removed: * SwissSign Silver CA - G2 Added: * D-TRUST BR Root CA 2 2023 * D-TRUST EV Root CA 2 2023 - remove extensive signature printing in comments of the cert bundle - Define two macros to break a build cycle with p11-kit. - Updated to 2.72 state of Mozilla SSL root CAs (bsc#1234798) Removed: - SecureSign RootCA11 - Security Communication RootCA3 Added: - TWCA CYBER Root CA - TWCA Global Root CA G2 - SecureSign Root CA12 - SecureSign Root CA14 - SecureSign Root CA15 Package cifs-utils was updated: - Add patches: * 0001-cifs.upcall-correctly-treat-UPTARGET_UNSPECIFIED-as-.patch (bsc#1243488) * 0001-mount.cifs-retry-mount-on-EINPROGRESS.patch - CVE-2025-2312: cifs-utils: cifs.upcall makes an upcall to the wrong namespace in containerized environments while trying to get Kerberos credentials (bsc#1239680) * add New-mount-option-for-cifs.upcall-namespace-reso.patch Package containerd was updated: - Update to containerd v1.7.27. Upstream release notes: &lt;https://github.com/containerd/containerd/releases/tag/v1.7.27&gt; bsc#1239749 CVE-2024-40635 - Rebase patches: * 0001-BUILD-SLE12-revert-btrfs-depend-on-kernel-UAPI-inste.patch - Update to containerd v1.7.26. Upstream release notes: &lt;https://github.com/containerd/containerd/releases/tag/v1.7.26&gt; - Rebase patches: * 0001-BUILD-SLE12-revert-btrfs-depend-on-kernel-UAPI-inste.patch - Update to containerd v1.7.25. Upstream release notes: &lt;https://github.com/containerd/containerd/releases/tag/v1.7.25&gt; &lt;https://github.com/containerd/containerd/releases/tag/v1.7.24&gt; - Rebase patches: * 0001-BUILD-SLE12-revert-btrfs-depend-on-kernel-UAPI-inste.patch - Update to containerd v1.7.23. Upstream release notes: &lt;https://github.com/containerd/containerd/releases/tag/v1.7.23&gt; - Rebase patches: * 0001-BUILD-SLE12-revert-btrfs-depend-on-kernel-UAPI-inste.patch - Update to containerd v1.7.22. Upstream release notes: &lt;https://github.com/containerd/containerd/releases/tag/v1.7.22&gt; - Bump minimum Go version to 1.22. - Rebase patches: * 0001-BUILD-SLE12-revert-btrfs-depend-on-kernel-UAPI-inste.patch Package coreutils was updated: - coreutils-9.7-sort-CVE-2025-5278.patch: Add upstream patch: sort with key character offsets of SIZE_MAX, could induce a read of 1 byte before an allocated heap buffer. (CVE-2025-5278, bsc#1243767) Package curl was updated: - Security fix: [bsc#1236590, CVE-2025-0725] * content_encoding: drop support for zlib before 1.2.0.4 * content_encoding: put the decomp buffers into the writer structs * Add curl-CVE-2025-0725.patch - Security fix: [bsc#1236588, CVE-2025-0167] * netrc: 'default' with no credentials is not a match * Add curl-CVE-2025-0167.patch - Security fix: [bsc#1234068, CVE-2024-11053] * curl could leak the password used for the first host to the followed-to host under certain circumstances. * netrc: address several netrc parser flaws * Add curl-CVE-2024-11053.patch - Security fix: [bsc#1232528, CVE-2024-9681] * HSTS subdomain overwrites parent cache entry * Add curl-CVE-2024-9681.patch - Make special characters in URL work with aws-sigv4 [bsc#1230516] * http_aws_sigv4: canonicalize the query [fc76a24c] * test439: verify query canonization for aws-sigv4 [65661016] * http_aws_sigv4: skip the op if the query pair is zero bytes [16bdc09e] * aws_sigv4: the query canon code miscounted URL encoded input [a1532a33] * http_aws_sigv4: canonicalise valueless query params [bbba69da] * aws-sigv4: url encode the canonical path [768909d8] * Add upstream patches: - curl-aws_sigv4-canonicalize-the-query.patch - curl-aws_sigv4-verify-query-canonization.patch - curl-aws_sigv4-skip-the-op-if-the-query-pair-is-zero-bytes.patch - curl-aws_sigv4-the-query-canon-code-miscounted-url-encoded-input.patch - curl-aws_sigv4-canonicalise-valueless-query-params.patch - curl-aws_sigv4-url-encode-the-canonical-path.patch Package docker was updated: [ This update is a no-op, only needed to work around unfortunate automated packaging script behaviour on SLES. ] - The following patches were removed in openSUSE in the Docker 28.1.1-ce update, but the patch names were later renamed in a SLES-only update before Docker 28.1.1-ce was submitted to SLES. This causes the SLES build scripts to refuse the update because the patches are not referenced in the changelog. There is no obvious place to put the patch removals (the 28.1.1-ce update removing the patches chronologically predates their renaming in SLES), so they are included here a dummy changelog entry to work around the issue. - 0007-CVE-2025-22868-vendor-jws-split-token-into-fixed-num.patch - 0008-CVE-2025-22869-vendor-ssh-limit-the-size-of-the-inte.patch - Update to docker-buildx v0.25.0. Upstream changelog: &lt;https://github.com/docker/buildx/releases/tag/v0.25.0&gt; - Do not try to inject SUSEConnect secrets when in Rootless Docker mode, as Docker does not have permission to access the host zypper credentials in this mode (and unprivileged users cannot disable the feature using /etc/docker/suse-secrets-enable.) bsc#1240150 * 0003-SECRETS-SUSE-implement-SUSE-container-secrets.patch - Rebase patches: * 0001-SECRETS-SUSE-always-clear-our-internal-secrets.patch * 0002-SECRETS-daemon-allow-directory-creation-in-run-secre.patch * 0004-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch * 0005-bsc1073877-apparmor-clobber-docker-default-profile-o.patch * 0006-SLE12-revert-apparmor-remove-version-conditionals-fr.patch - Always clear SUSEConnect suse_* secrets when starting containers regardless of whether the daemon was built with SUSEConnect support. Not doing this causes containers from SUSEConnect-enabled daemons to fail to start when running with SUSEConnect-disabled (i.e. upstream) daemons. This was a long-standing issue with our secrets support but until recently this would've required migrating from SLE packages to openSUSE packages (which wasn't supported). However, as SLE Micro 6.x and SLES 16 will move away from in-built SUSEConnect support, this is now a practical issue users will run into. bsc#1244035 + 0001-SECRETS-SUSE-always-clear-our-internal-secrets.patch - Rearrange patches: - 0001-SECRETS-daemon-allow-directory-creation-in-run-secre.patch + 0002-SECRETS-daemon-allow-directory-creation-in-run-secre.patch - 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch + 0003-SECRETS-SUSE-implement-SUSE-container-secrets.patch - 0003-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch + 0004-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch - 0004-bsc1073877-apparmor-clobber-docker-default-profile-o.patch + 0005-bsc1073877-apparmor-clobber-docker-default-profile-o.patch - 0005-SLE12-revert-apparmor-remove-version-conditionals-fr.patch + 0006-SLE12-revert-apparmor-remove-version-conditionals-fr.patch [NOTE: This update was only ever released in SLES and Leap.] - Always clear SUSEConnect suse_* secrets when starting containers regardless of whether the daemon was built with SUSEConnect support. Not doing this causes containers from SUSEConnect-enabled daemons to fail to start when running with SUSEConnect-disabled (i.e. upstream) daemons. This was a long-standing issue with our secrets support but until recently this would've required migrating from SLE packages to openSUSE packages (which wasn't supported). However, as SLE Micro 6.x and SLES 16 will move away from in-built SUSEConnect support, this is now a practical issue users will run into. bsc#1244035 + 0001-SECRETS-SUSE-always-clear-our-internal-secrets.patch - Rearrange patches: - 0001-SECRETS-daemon-allow-directory-creation-in-run-secre.patch + 0002-SECRETS-daemon-allow-directory-creation-in-run-secre.patch - 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch + 0003-SECRETS-SUSE-implement-SUSE-container-secrets.patch - 0003-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch + 0004-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch - 0004-bsc1073877-apparmor-clobber-docker-default-profile-o.patch + 0005-bsc1073877-apparmor-clobber-docker-default-profile-o.patch - 0005-SLE12-revert-apparmor-remove-version-conditionals-fr.patch + 0006-SLE12-revert-apparmor-remove-version-conditionals-fr.patch - 0006-CVE-2025-22868-vendor-jws-split-token-into-fixed-num.patch + 0007-CVE-2025-22868-vendor-jws-split-token-into-fixed-num.patch - 0007-CVE-2025-22869-vendor-ssh-limit-the-size-of-the-inte.patch + 0008-CVE-2025-22869-vendor-ssh-limit-the-size-of-the-inte.patch - Update to Docker 28.2.2-ce. See upstream changelog online at &lt;https://github.com/moby/moby/releases/tag/v28.2.2&gt; - 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 - Update to Docker 28.2.1-ce. See upstream changelog online at &lt;https://docs.docker.com/engine/release-notes/28/#2820&gt; bsc#1243833 &lt;https://github.com/moby/moby/releases/tag/v28.2.1&gt; - 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 - Update to docker-buildx v0.24.0. Upstream changelog: &lt;https://github.com/docker/buildx/releases/tag/v0.24.0&gt; - Update to Docker 28.1.1-ce. See upstream changelog online at &lt;https://docs.docker.com/engine/release-notes/28/#2811&gt; bsc#1242114 Includes upstream fixes: - CVE-2025-22872 bsc#1241830 - Remove long-outdated build handling for deprecated and unsupported devicemapper and AUFS storage drivers. AUFS was removed in v24, and devicemapper was removed in v25. &lt;https://docs.docker.com/engine/deprecated/#aufs-storage-driver&gt; - 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 - Remove upstreamed patches: - 0006-CVE-2025-22868-vendor-jws-split-token-into-fixed-num.patch - 0007-CVE-2025-22869-vendor-ssh-limit-the-size-of-the-inte.patch - cli-0001-docs-include-required-tools-in-source-tree.patch - Update to docker-buildx v0.23.0. Upstream changelog: &lt;https://github.com/docker/buildx/releases/tag/v0.23.0&gt; - Update to docker-buildx v0.22.0. Upstream changelog: &lt;https://github.com/docker/buildx/releases/tag/v0.22.0&gt; * Includes fixes for CVE-2025-0495. bsc#1239765 - Disable transparent SUSEConnect support for SLE-16. PED-12534 When this patchset was first added in 2013 (and rewritten over the years), there was no upstream way to easily provide SLE customers with a way to build container images based on SLE using the host subscription. However, with docker-buildx you can now define secrets for builds (this is not entirely transparent, but we can easily document this new requirement for SLE-16). Users should use RUN --mount=type=secret,id=SCCcredentials zypper -n ... in their Dockerfiles, and docker buildx build --secret id=SCCcredentials,src=/etc/zypp/credentials.d/SCCcredentials,type=file . when doing their builds. - Now that the only blocker for docker-buildx support was removed for SLE-16, enable docker-buildx for SLE-16 as well. PED-8905 - Don't use the new container-selinux conditional requires on SLE-12, as the RPM version there doesn't support it. Arguably the change itself is a bit suspect but we can fix that later. bsc#1237367 - Add backport for golang.org/x/oauth2 CVE-2025-22868 fix. bsc#1239185 + 0006-CVE-2025-22868-vendor-jws-split-token-into-fixed-num.patch - Add backport for golang.org/x/crypto CVE-2025-22869 fix. bsc#1239322 + 0007-CVE-2025-22869-vendor-ssh-limit-the-size-of-the-inte.patch - Refresh 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 - Make container-selinux requirement conditional on selinux-policy (bsc#1237367) - Update to Docker 27.5.1-ce. See upstream changelog online at &lt;https://docs.docker.com/engine/release-notes/27/#2741&gt; bsc#1237335 - 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 * cli-0001-docs-include-required-tools-in-source-tree.patch - Update to docker-buildx 0.20.1. See upstream changelog online at &lt;https://github.com/docker/buildx/releases/tag/v0.20.1&gt; - Update to Docker 27.4.1-ce. See upstream changelog online at &lt;https://docs.docker.com/engine/release-notes/27/#2741&gt; - 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 * cli-0001-docs-include-required-tools-in-source-tree.patch - Update to docker-buildx 0.19.3. See upstream changelog online at &lt;https://github.com/docker/buildx/releases/tag/v0.19.3&gt; - Update to Docker 27.4.0-ce. See upstream changelog online at &lt;https://docs.docker.com/engine/release-notes/27/#274&gt; - 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 * cli-0001-docs-include-required-tools-in-source-tree.patch - Remove upstreamed patches: - 0006-bsc1221916-update-to-patched-buildkit-version-to-fix.patch - 0007-bsc1214855-volume-use-AtomicWriteFile-to-save-volume.patch - Update docker-buildx to v0.19.2. See upstream changelog online at &lt;https://github.com/docker/buildx/releases/tag/v0.19.2&gt;. Some notable changelogs from the last update: * &lt;https://github.com/docker/buildx/releases/tag/v0.19.0&gt; * &lt;https://github.com/docker/buildx/releases/tag/v0.18.0&gt; - 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 &gt; /etc/docker/suse-secrets-enable and restart Docker. In order to re-enable them, just do echo 1 &gt; /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 &lt;https://github.com/docker/buildx/releases/tag/v0.17.1&gt; - Add %{_sysconfdir}/audit/rules.d to filelist. - Mark docker-buildx as required since classic &quot;docker build&quot; 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 &lt;https://docs.docker.com/engine/release-notes/26.1/#2615&gt; 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 findutils was updated: - do not crash when file system loop was encountered [bsc#1231472]- added patches fix https://git.savannah.gnu.org/cgit/findutils.git/commit/?id=e5d6eb919b9 + findutils-avoid-crash-system-loop.patch - modified patches % findutils-xautofs.patch (p1) Package glibc was updated: - static-setuid-ld-library-path.patch: elf: Ignore LD_LIBRARY_PATH and debug env var for setuid for static (CVE-2025-4802, bsc#1243317) - pthread-wakeup.patch: pthreads NPTL: lost wakeup fix 2 (bsc#1234128, BZ [#25847]) - assert-message-allocation.patch: Fix underallocation of abort_msg_s struct (CVE-2025-0395, bsc#1236282, BZ #32582)) - tcache-thread-shutdown.patch: malloc: Initiate tcache shutdown even without allocations (bsc#1228661, BZ #28028) Package google-guest-agent was updated: - Update to version 20250506.01 (bsc#1243254, bsc#1243505) * Make sure agent added connections are activated by NM (#534) - from version 20250506.00 * wrap NSS cache refresh in a goroutine (#533) - from version 20250502.01 * Wicked: Only reload interfaces for which configurations are written or changed. (#524) - from version 20250502.00 * Add AuthorizedKeysCompat to windows packaging (#530) * Remove error messages from gce_workload_cert_refresh and metadata script runner (#527) * Update guest-logging-go dependency (#526) * Add 'created-by' metadata, and pass it as option to logging library (#508) * Revert &quot;oslogin: Correctly handle newlines at the end of modified files (#520)&quot; (#523) * Re-enable disabled services if the core plugin was enabled (#522) * Enable guest services on package upgrade (#519) * oslogin: Correctly handle newlines at the end of modified files (#520) * Fix core plugin path (#518) * Fix package build issues (#517) * Fix dependencies ran go mod tidy -v (#515) * Fix debian build path (#514) * Bundle compat metadata script runner binary in package (#513) * Bump golang.org/x/net from 0.27.0 to 0.36.0 (#512) * Update startup/shutdown services to launch compat manager (#503) * Bundle new gce metadata script runner binary in agent package (#502) * Revert &quot;Revert bundling new binaries in the package (#509)&quot; (#511) - from version 20250418.00 * Re-enable disabled services if the core plugin was enabled (#521) - from version 20250414.00 * Add AuthorizedKeysCompat to windows packaging (#530) * Remove error messages from gce_workload_cert_refresh and metadata script runner (#527) * Update guest-logging-go dependency (#526) * Add 'created-by' metadata, and pass it as option to logging library (#508) * Revert &quot;oslogin: Correctly handle newlines at the end of modified files (#520)&quot; (#523) * Re-enable disabled services if the core plugin was enabled (#522) * Enable guest services on package upgrade (#519) * oslogin: Correctly handle newlines at the end of modified files (#520) * Fix core plugin path (#518) * Fix package build issues (#517) * Fix dependencies ran go mod tidy -v (#515) * Fix debian build path (#514) * Bundle compat metadata script runner binary in package (#513) * Bump golang.org/x/net from 0.27.0 to 0.36.0 (#512) * Update startup/shutdown services to launch compat manager (#503) * Bundle new gce metadata script runner binary in agent package (#502) * Revert &quot;Revert bundling new binaries in the package (#509)&quot; (#511) - Update to version 20250327.01 (bsc#1239763, bsc#1239866) * Remove error messages from gce_workload_cert_refresh and metadata script runner (#527) - from version 20250327.00 * Update guest-logging-go dependency (#526) * Add 'created-by' metadata, and pass it as option to logging library (#508) * Revert &quot;oslogin: Correctly handle newlines at the end of modified files (#520)&quot; (#523) * Re-enable disabled services if the core plugin was enabled (#522) * Enable guest services on package upgrade (#519) * oslogin: Correctly handle newlines at the end of modified files (#520) * Fix core plugin path (#518) * Fix package build issues (#517) * Fix dependencies ran go mod tidy -v (#515) * Fix debian build path (#514) * Bundle compat metadata script runner binary in package (#513) * Bump golang.org/x/net from 0.27.0 to 0.36.0 (#512) * Update startup/shutdown services to launch compat manager (#503) * Bundle new gce metadata script runner binary in agent package (#502) * Revert &quot;Revert bundling new binaries in the package (#509)&quot; (#511) - from version 20250326.00 * Re-enable disabled services if the core plugin was enabled (#521) - from version 20250324.00 * Enable guest services on package upgrade (#519) * oslogin: Correctly handle newlines at the end of modified files (#520) * Fix core plugin path (#518) * Fix package build issues (#517) * Fix dependencies ran go mod tidy -v (#515) * Fix debian build path (#514) * Bundle compat metadata script runner binary in package (#513) * Bump golang.org/x/net from 0.27.0 to 0.36.0 (#512) * Update startup/shutdown services to launch compat manager (#503) * Bundle new gce metadata script runner binary in agent package (#502) * Revert &quot;Revert bundling new binaries in the package (#509)&quot; (#511) * Revert bundling new binaries in the package (#509) * Fix typo in windows build script (#501) * Include core plugin binary for all packages (#500) * Update crypto library to fix CVE-2024-45337 (#499) * Start packaging compat manager (#498) * Start bundling ggactl_plugin_cleanup binary in all agent packages (#492) * scripts: introduce a wrapper to locally build deb package (#490) * Introduce compat-manager systemd unit (#497) - from version 20250317.00 * Revert &quot;Revert bundling new binaries in the package (#509)&quot; (#511) * Revert bundling new binaries in the package (#509) * Fix typo in windows build script (#501) * Include core plugin binary for all packages (#500) * Update crypto library to fix CVE-2024-45337 (#499) * Start packaging compat manager (#498) * Start bundling ggactl_plugin_cleanup binary in all agent packages (#492) * scripts: introduce a wrapper to locally build deb package (#490) * Introduce compat-manager systemd unit (#497) - from version 20250312.00 * Revert bundling new binaries in the package (#509) * Fix typo in windows build script (#501) * Include core plugin binary for all packages (#500) * Update crypto library to fix CVE-2024-45337 (#499) * Start packaging compat manager (#498) * Start bundling ggactl_plugin_cleanup binary in all agent packages (#492) * scripts: introduce a wrapper to locally build deb package (#490) * Introduce compat-manager systemd unit (#497) - from version 20250305.00 * Revert bundling new binaries in the package (#509) * Fix typo in windows build script (#501) * Include core plugin binary for all packages (#500) * Update crypto library to fix CVE-2024-45337 (#499) * Start packaging compat manager (#498) * Start bundling ggactl_plugin_cleanup binary in all agent packages (#492) * scripts: introduce a wrapper to locally build deb package (#490) * Introduce compat-manager systemd unit (#497) - from version 20250304.01 * Fix typo in windows build script (#501) - from version 20250214.01 * Include core plugin binary for all packages (#500) - from version 20250214.00 * Update crypto library to fix CVE-2024-45337 (#499) - from version 20250212.00 * Start packaging compat manager (#498) * Start bundling ggactl_plugin_cleanup binary in all agent packages (#492) - from version 20250211.00 * scripts: introduce a wrapper to locally build deb package (#490) * Introduce compat-manager systemd unit (#497) - from version 20250207.00 * vlan: toggle vlan configuration in debian packaging (#495) * vlan: move config out of unstable section (#494) * Add clarification to comments regarding invalid NICs and the `invalid` tag. (#493) * Include interfaces in lists even if it has an invalid MAC. (#489) * Fix windows package build failures (#491) * vlan: don't index based on the vlan ID (#486) * Revert PR #482 (#488) * Remove Amy and Zach from OWNERS (#487) * Skip interfaces in interfaceNames() instead of erroring if there is an (#482) * Fix Debian packaging if guest agent manager is not checked out (#485) - from version 20250204.02 * force concourse to move version forward. - from version 20250204.01 * vlan: toggle vlan configuration in debian packaging (#495) - from version 20250204.00 * vlan: move config out of unstable section (#494) * Add clarification to comments regarding invalid NICs and the `invalid` tag. (#493) - from version 20250203.01 * Include interfaces in lists even if it has an invalid MAC. (#489) - from version 20250203.00 * Fix windows package build failures (#491) * vlan: don't index based on the vlan ID (#486) * Revert PR #482 (#488) * Remove Amy and Zach from OWNERS (#487) * Skip interfaces in interfaceNames() instead of erroring if there is an (#482) * Fix Debian packaging if guest agent manager is not checked out (#485) - from version 20250122.00 * networkd(vlan): remove the interface in addition to config (#468) * Implement support for vlan dynamic removal, update dhclient to remove only if configured (#465) * Update logging library (#479) * Remove Pat from owners file. (#478) - Add patch to fix unexpected memory consumption during token parsing in golang.org/x/oauth2 (bsc#1239197, CVE-2025-22868) * CVE-2025-22868.patch - Update to version 20250116.00: (bsc#1236403) * networkd(vlan): remove the interface in addition to config (#468) * Implement support for vlan dynamic removal, update dhclient to remove only if configured (#465) * Update logging library (#479) * Remove Pat from owners file. (#478) - Update to version 20241209.01: (bsc#1235664) * readme: add notes about plugin manager (#476) * Update metadata script runner to honor cloud logging config flag (#475) * Fixing fallback from systemd-networkd to dhclient (#471) * network: fix nmcli check pattern (#472) * Update readme with guest agent manager (#469) * Add missing packaging spec (#466) * Bring back side-by-side packaging (#464) * Avoid changing permissions of directory if parent is / (#463) * network: force NetworkManager to connect to primary nic (#461) * Revert plugin manager packaging (#460) * Add GOPATH to PATH in debian build (#459) * Add plugin manager to debian build (#457) * rpm packaging: fix plugin manager assumptions (#458) * packaging: add plugin manager to rhel packaging (#454) - Update to version 20241018.01 (bsc#1231775, bsc#1231776) * Add support for including agent manager in guest-agent package (#456) * plugin manager: Introduce the systemd service file (#455) * documentation: Update metadata script runner details (#453) - from version 20241013.00 * Update OWNERS (#452) - from version 20241011.01 * SUSE no overwrite bug fix, Ubuntu 18.04 exception (#451) - from version 20241011.00 * Skip MDS setup by default for this release (#450) - from version 20241010.01 * Revert &quot;network/netplan: Adjust link-local accordingly (#443)&quot; (#448) * Set enable regardless of previous check failed or not (#447) - from version 20241009.03 * Avoid unnecessary reloads, check before overwriting configs (#446) - from version 20241009.02 * network/netplan: Do generate instead of apply (#445) - from version 20241009.01 * Skip SetupInterfaces if configs are already applied (#444) * network/netplan: Adjust link-local accordingly (#443) * Repeated logging could be mistaken for a recurring issue, log mds mtls endpoint error only once (#439) * Retry MDS PUT operation, reload netplan/networkctl only if configs are changed (#438) * Log interface state after setting up network (#437) * network: Debian 12 rollback only if default netplan is ok (#436) - from version 20240930.01 * Change mtls mds defaults, update log message to assure error is harmless (#434) - from version 20240930.00 * network: Restore Debian 12 netplan configuration. (#433) * network: Remove primary NIC left over configs. (#432) * Update VLAN interfaces format to match with MDS (#431) * Fix panics in agent when setting up VLAN with netplan (#430) * Add VLAN NIC support for NetworkManager (#429) * Fix debian12 netplan config issue, use ptr receiver (#428) * Update README to reflect new network manager changes (#427) * Introduce a configuration toggle for enabling/disabling cloud logging (#413) * Adapt and update config key to be consistent with MDS (#426) * Allow users to enable/disable the mds mtls via metadata key (#423) * Make primary nic management config consistent across all network managers (#422) * Document disabling account manager on AD (#421) * Update README with MDS MTLS docs (#418) * Avoid writing configuration files when they already exist on wicked and (#410) * Update golang.org/x/net dependencies to catch up on CVEs (#412) * Get rid of deperecated dependencies in snapshot service generate code (#411) * Fix where agent panics on nil event (#409) * Configure primary nic if only set in cfg file (#408) * Update NIC management strategy (#402) * Only release dhclient leases for an interface if the respective dhclient is still running (#407) * Disable OS Login without pruning off any extra suffix. (#400) * Skip root cert rotation if installed once (#405) * Add ipv6 support to guest agent (#404) * Update Accounts documentation (#403) * Update google-startup-scripts.service to enable logging (#399) * Network subsystem remove os rules (#396) * oslogin: Don't remove sshca watcher when oslogin is disabled (#398) * Update dependencies to catch up on CVE fixes (#397) * Network manager netplan implementation (#386) * Update dependencies to catch up on CVE fixes (#391) * Log current available routes on error (#388) * Fix command monitor bugs (#389) * windows account: Ignore &quot;user already belogs to group&quot; error (#387) * Add more error logging in snapshot handling requests, use common retry util (#384) * All non-200 status code from MDS should raise error (#383) * Change metadata key to enable-oslogin-certificates (#382) * Update dhclient pid/lease file directory to abide apparmor rules (#381) * Add COS homedir-gid patch to upstream. (#365) * Add require-oslogin-certificates logic to disable keys (#368) * systemd-networkd: Support Debian 12's version (#372) * Minor update typo in comment (#380) * NetworkManager: Only set secondary interfaces as up (#378) * address manager: Make sure we check for oldMetadata (#375) * network: Early setup network (#374) * NetworkManager: Fix ipv6 and ipv4 mode attribute (#373) * Network Manager: Make sure we clean up ifcfg files (#371) * metadata script runner: Fix script download (#370) * oslogin: Avoid adding extra empty line at the end of /etc/security/group.conf (#369) * Dynamic vlan (#361) * Check for nil response (#366) * Create NetworkManager implementation (#362) * Skip interface manager on Windows (#363) * network: Remove ignore setup (#360) * Create wicked network service implementation and its respective unit (#356) * Update metadata script runner, add tests (#357) * Refactor guest-agent to use common retry util (#355) * Flush logs before exiting #358 (#359) * Create systemd-networkd unit tests. (#354) * Update network manager unit tests (#351) * Implement retry util (#350) * Refactor utils package to not dump everything unrelated into one file (#352) * Set version on metadata script runner (#353) * Implement cleanup of deprecated configuration directives (#348) * Ignore DHCP offered routes only for secondary nics (#347) * Deprecate DHClient in favor of systemd-networkd (#342) * Generate windows and linux licenses (#346) * Remove quintonamore from OWNERS (#345) * Delete integration tests (#343) - Update to version 20240816.00 * Add configuration toggle to enable/disable use of OS native certificate stores (#419) * Fix dependencies in stable branch #412 (#415) * Update dep: golang.org/x/crypto to v0.17.0 * Update dep: google.golang.org/protobuf to 1.33.0 * Update dep: golang.org/x/net to 0.17.0 * Update dep: google.golang.org/grpc to v1.57.1 - from version 20240813.00 * Update README with MDS MTLS docs (#418) - from version 20240808.01 * Avoid writing configuration files when they already exist on wicked and NetworkManager (#410) - from version 20240808.00 * Update golang.org/x/net dependencies to catch up on CVEs (#412) - from version 20240805.00 * Get rid of deperecated dependencies in snapshot service generate code (#411) - Drop dont_overwrite_ifcfg.patch, fixed upstream - Update to version 20240802.00 * Fix where agent panics on nil event (#409) - from version 20240801.00 * Configure primary nic if only set in cfg file (#408) * Update NIC management strategy (#402) * Only release dhclient leases for an interface if the respective dhclient is still running (#407) * Disable OS Login without pruning off any extra suffix. (#400) * Skip root cert rotation if installed once (#405) * Add ipv6 support to guest agent (#404) * Update Accounts documentation (#403) * Update google-startup-scripts.service to enable logging (#399) * Network subsystem remove os rules (#396) * oslogin: don't remove sshca watcher when oslogin is disabled (#398) * Update dependencies to catch up on CVE fixes (#397) * Network manager netplan implementation (#386) * Update dependencies to catch up on CVE fixes (#391) * Log current available routes on error (#388) * Fix command monitor bugs (#389) * Windows account: ignore &quot;user already belogs to group&quot; error (#387) * Add more error logging in snapshot handling requests, use common retry util (#384) * All non-200 status code from MDS should raise error (#383) * Change metadata key to enable-oslogin-certificates (#382) * Update dhclient pid/lease file directory to abide apparmor rules (#381) * Add COS homedir-gid patch to upstream. (#365) * Add require-oslogin-certificates logic to disable keys (#368) * systemd-networkd: support debian 12's version (#372) * Minor update typo in comment (#380) * NetworkManager: only set secondary interfaces as up (#378) * address manager: make sure we check for oldMetadata (#375) * network: early setup network (#374) * NetworkManager: fix ipv6 and ipv4 mode attribute (#373) * Network Manager: make sure we clean up ifcfg files (#371) * metadata script runner: fix script download (#370) * oslogin: avoid adding extra empty line at the end of /etc/security/group.conf (#369) * Dynamic vlan (#361) * Check for nil response (#366) * Create NetworkManager implementation (#362) * Skip interface manager on Windows (#363) * network: remove ignore setup (#360) * Create wicked network service implementation and its respective unit (#356) * Update metadata script runner, add tests (#357) * Refactor guest-agent to use common retry util (#355) * Flush logs before exiting #358 (#359) * Create systemd-networkd unit tests. (#354) * Update network manager unit tests (#351) * Implement retry util (#350) * Refactor utils package to not dump everything unrelated into one file (#352) * Set version on metadata script runner (#353) * Implement cleanup of deprecated configuration directives (#348) * Ignore DHCP offered routes only for secondary nics (#347) * Deprecate DHClient in favor of systemd-networkd (#342) * Generate windows and linux licenses (#346) * Remove quintonamore from OWNERS (#345) * Delete integration tests (#343) - from version 20240716.00 * Update dep: golang.org/x/crypto to v0.17.0 * Update dep: google.golang.org/protobuf to 1.33.0 * Update dep: golang.org/x/net to 0.17.0 * Update dep: google.golang.org/grpc to v1.57.1 - Update to version 20240701.00 * Update google-startup-scripts.service to enable logging (#399) - Update to version 20240611.01 * Network subsystem remove os rules (#396) * oslogin: don't remove sshca watcher when oslogin is disabled (#398) * update dependencies to catch up on CVE fixes (#397) * Network manager netplan implementation (#386) * update dependencies to catch up on CVE fixes (#391) * Log current available routes on error (#388) * Fix command monitor bugs (#389) * windows account: ignore &quot;user already belogs to group&quot; error (#387) * Add more error logging in snapshot handling requests, use common retry util (#384) * All non-200 status code from MDS should raise error (#383) * change metadata key to enable-oslogin-certificates (#382) * Update dhclient pid/lease file directory to abide apparmor rules (#381) * Add COS homedir-gid patch to upstream. (#365) * Add require-oslogin-certificates logic to disable keys (#368) * systemd-networkd: support debian 12's version (#372) * Minor update typo in comment (#380) * NetworkManager: only set secondary interfaces as up (#378) * address manager: make sure we check for oldMetadata (#375) * network: early setup network (#374) * NetworkManager: fix ipv6 and ipv4 mode attribute (#373) * Network Manager: make sure we clean up ifcfg files (#371) * metadata script runner: fix script download (#370) * oslogin: avoid adding extra empty line at the end of /etc/security/group.conf (#369) * Dynamic vlan (#361) * Check for nil response (#366) * Create NetworkManager implementation (#362) * Skip interface manager on Windows (#363) * network: remove ignore setup (#360) * Create wicked network service implementation and its respective unit (#356) * Update metadata script runner, add tests (#357) * Refactor guest-agent to use common retry util (#355) * Flush logs before exiting #358 (#359) * Create systemd-networkd unit tests. (#354) * Update network manager unit tests (#351) * Implement retry util (#350) * Refactor utils package to not dump everything unrelated into one file (#352) * Set version on metadata script runner (#353) * Implement cleanup of deprecated configuration directives (#348) * ignore DHCP offered routes only for secondary nics (#347) * Deprecate DHClient in favor of systemd-networkd (#342) * Generate windows and linux licenses (#346) * Remove quintonamore from OWNERS (#345) * Delete integration tests (#343) - from version 20240528.00 * update dep: golang.org/x/crypto to v0.17.0 * update dep: google.golang.org/protobuf to 1.33.0 * update dep: golang.org/x/net to 0.17.0 * update dep: google.golang.org/grpc to v1.57.1 Package google-guest-configs was updated: - Check that %{_sysconfdir}/sysconfig/network/ifcfg-eth0 actually exists before making any modifications to it (bsc#1241112) - Add ggc-no-dup-metasrv-entry.patch + Follow up to (bsc#1234289, bsc#1234293). Avoid duplicate entries for the metadata server in /etc/hosts - Update to version 20241205.00 (bsc#1234254, bsc#1234255) * Update google_set_multiqueue to configure vCPU ranges based on VM platform (#90) - from version 20241204.00 * Restore google_set_multiqueue changes for A3Ultra (#93) * Depend on networkd-dispatcher in Ubuntu (#94) - Include components to set hostname and /etc/hosts entries (bsc#1234289, bsc#1234293) * Add sysconfig and sysconfig-network to BuildRequires * Install google_set_hostname into %{_bindir} * Install google_up.sh into %{_sysconfdir}/sysconfig/network/scripts/ * Add code to add and remove POST_UP_SCRIPT=&quot;compat:suse:google_up.sh&quot; to /etc/sysconfig/network/ifcfg-eth0 in %post and %postun sections - Update to version 20241121.00 (bsc#1233625, bsc#1233626) * Temporarily revert google_set_multiqueue changes for release (#92) - from version 20241115.00 * Remove IDPF devices from renaming rules (#91) - from version 20241112.00 * Revert &quot;Revert 3 commits:&quot; (#89) - from version 20241108.00 * Revert 3 commits: (#87) - from version 20241107.00 * gce-nic-naming: Exit 1 so that udev ignores the rule on error (#86) - from version 20241106.00 * Remove Apt IPv4 only config for Debian and Ubuntu (#85) - from version 20241031.00 * Add GCE intent based NIC naming tools (#84) - from version 20241025.00 * Update google_set_multiqueue to skip set_irq if NIC is not a gvnic device (#83) - Add new binary gce-nic-naming to %{_bindir} in %files section - Update to version 20241021.00 (bsc#1231775, bsc#1231776) * Add GCE-specific config for systemd-resolved (#82) - from version 20241015.00 * Update google_set_multiqueue to enable on A3Ultra family (#79) - from version 20241013.00 * Update OWNERS (#81) - from version 20241010.00 * Depend on jq in enterprise linux (#80) - from version 20241008.00 * Always use IP from primary NIC in the networkd-dispatcher routable hook (#78) - Update to version 20240925.00 * Call google_set_hostname on openSUSE and when the agent is configured to manage hostname and FQDN, let it (#75) - from version 20240924.00 * Include systemd-networkd hook in Ubuntu packaging (#77) - from version 20240905.00 * Update packaging as of Ubuntu devel packaging (#65) - from version 20240830.00 * Fix the name for A3 Edge VMs (#76) - Update to version 20240725.00 * Fix: hostnamectl command (#74) - Update to version 20240607.00 * Update is_a3_platform to include A3-edge shape (#73) - Update to version 20240514.00 * Add systemd-networkd hostname hook (#71) - from version 20240501.00 * Add hostname hook for NetworkManager without dhclient compat script (#70) Package google-guest-oslogin was updated: - Override upstream version to address upgrade problems (bsc#1243997) - Rework SELinux support (bsc#1232553) * Add pkgconfig(systemd) to BuildRequires for SELinux builds * Add policycoreutils to BuildRequires * Build and install SELinux module on older distributions as well to allow users to use the module with their own SELinux policies * Make checkpolicy build dependency unconditional * Move oslogin.pp SELinux module into %{selinuxtype} subdirectory * Own %{_datadir}/selinux{,/packages} on older distributions * Split SELinux support into separate -selinux package * Use SELinux RPM macros to install and uninstall SELinux module * Use RPM conditional builds to enable SELinux on newer distributions - Build and install SELinux module (bsc#1232553) Package google-osconfig-agent was updated: - Update to version 20250416.02 (bsc#1244304, bsc#1244503) * defaultSleeper: tolerate 10% difference to reduce test flakiness (#810) * Add output of some packagemanagers to the testdata (#808) - from version 20250416.01 * Refactor OS Info package (#809) - from version 20250416.00 * Report RPM inventory as YUM instead of empty SoftwarePackage when neither Zypper nor YUM are installed. (#805) - from version 20250414.00 * Update hash computation algorithm (#799) - Update to version 20250320.00 * Bump github.com/envoyproxy/protoc-gen-validate from 1.1.0 to 1.2.1 (#797) - from version 20250318.00 * Bump go.opentelemetry.io/otel/sdk/metric from 1.32.0 to 1.35.0 (#793) - from version 20250317.02 * Bump cel.dev/expr from 0.18.0 to 0.22.0 (#792) * Bump github.com/golang/glog from 1.2.3 to 1.2.4 in the go_modules group (#785) - from version 20250317.01 * Bump cloud.google.com/go/logging from 1.12.0 to 1.13.0 (#774) - from version 20250317.00 * Add tests for retryutil package. (#795) - from version 20250306.00 * Update OWNERS (#794) - from version 20250206.01 * Use separate counters for pre- and post-patch reboots. (#788) - from version 20250206.00 * Update owners (#789) - from version 20250203.00 * Fix the vet errors for contants in logging (#786) - from version 20250122.00 * change available package check (#783) - from version 20250121.00 * Fix Inventory reporting e2e tests. (#782) - from version 20250120.00 * fix e2e tests (#781) - Add -buildmode=pie to go build command line (bsc#1239948) - Drop CVE-2024-45339.patch, merged upstream - Renumber patches - Add patch to fix unexpected memory consumption during token parsing in golang.org/x/oauth2 (bsc#1239197, CVE-2025-22868) * CVE-2025-22868.patch - Add patch to fix vulnerability when creating log files * CVE-2024-45339.patch (bsc#1236560, CVE-2024-45339) - Update to version 20250115.01 (bsc#1236406, bsc#1236407) * Bump cloud.google.com/go/osconfig from 1.14.2 to 1.14.3 (#772) - from version 20250115.00 * Bump cloud.google.com/go/auth from 0.10.2 to 0.14.0 (#767) * Bump go.opentelemetry.io/otel from 1.32.0 to 1.33.0 (#771) * Bump google.golang.org/protobuf from 1.35.1 to 1.36.2 (#763) - from version 20250114.00 * Bump golang.org/x/time from 0.8.0 to 0.9.0 (#770) - from version 20250113.01 * Bump cloud.google.com/go/auth/oauth2adapt from 0.2.5 to 0.2.7 (#766) - from version 20250113.00 * Bump golang.org/x/net from 0.31.0 to 0.34.0 (#769) - from version 20250110.00 * Bump golang.org/x/crypto from 0.29.0 to 0.31.0 in the go_modules group (#760) * Bump cloud.google.com/go/longrunning from 0.6.2 to 0.6.3 (#744) - from version 20241218.00 * Scanners fixes (#720) * Bump cloud.google.com/go/storage from 1.46.0 to 1.47.0 (#736) * Bump go.opentelemetry.io/contrib/detectors/gcp from 1.29.0 to 1.32.0 (#730) * Bump go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp (#738) * Bump golang.org/x/net from 0.30.0 to 0.31.0 (#731) - from version 20241118.01 * Bump github.com/googleapis/gax-go/v2 from 2.13.0 to 2.14.0 (#737) - from version 20241118.00 * move example to appropriate directory (#740) - from version 20241115.00 * Replace sles-15-sp3-sap old deprecated image in e2e tests (#739) * Bump golang.org/x/time from 0.7.0 to 0.8.0 (#734) - from version 20241114.03 * Bump github.com/GoogleCloudPlatform/opentelemetry-operations-go/detectors/gcp (#735) - from version 20241114.02 * Bump go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc (#729) - from version 20241114.01 * Remove SLES-15-SP2-SAP from e2e tests and add the new SLES-15-SP6 (#733) * Bump golang.org/x/crypto from 0.28.0 to 0.29.0 (#728) * Bump go.opentelemetry.io/otel/sdk/metric from 1.30.0 to 1.32.0 (#727) - from version 20241114.00 * Add example to run exec script from the gcs bucket (#732) * Bump cel.dev/expr from 0.16.1 to 0.18.0 (#723) - from version 20241112.00 * Bump golang.org/x/oauth2 from 0.23.0 to 0.24.0 (#722) * Bump github.com/GoogleCloudPlatform/opentelemetry-operations-go/exporter/metric (#721) * Bump google.golang.org/grpc from 1.67.1 to 1.68.0 (#725) * Bump github.com/golang/glog from 1.2.2 to 1.2.3 (#715) * Bump google.golang.org/api from 0.203.0 to 0.205.0 (#716) - from version 20241107.01 * Bump github.com/envoyproxy/go-control-plane from 0.13.0 to 0.13.1 (#717) * Bump github.com/GoogleCloudPlatform/opentelemetry-operations-go/internal/resourcemapping (#718) * Bump cloud.google.com/go/auth from 0.10.0 to 0.10.1 (#719) - from version 20241107.00 * Bump cloud.google.com/go/logging from 1.11.0 to 1.12.0 (#709) * Bump cloud.google.com/go/iam from 1.2.1 to 1.2.2 (#710) * Bump cloud.google.com/go/storage from 1.43.0 to 1.46.0 (#713) * Bump cloud.google.com/go/osconfig from 1.14.1 to 1.14.2 (#708) * Bump cloud.google.com/go/auth/oauth2adapt from 0.2.4 to 0.2.5 (#712) - from version 20241106.00 * Update OWNERS (#714) - from version 20241029.01 * remove toolchain override (#706) * Bump go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp (#701) - from version 20241029.00 * Bump go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc (#702) - from version 20241028.00 * Bump cloud.google.com/go/longrunning from 0.6.0 to 0.6.2 (#705) - from version 20241017.00 * Add a new CloudBuild trigger config-file for auto updating the presubmit test container image on every new commit (#704) - from version 20241004.00 * Add new packagebuild presubmit that will use cloud-build (#694) - from version 20240927.00 * Third batch of dependencies upgrade (#690) - Bump the golang compiler version to 1.22.4 (bsc#1225974, CVE-2024-24790) - Update to version 20240926.03 (bsc#1231775, bsc#1231776) * Revert &quot;Bump go.opentelemetry.io/otel from 1.24.0 to 1.30.0 (#679)&quot; (#684) - from version 20240926.02 * Bump go.opentelemetry.io/otel from 1.24.0 to 1.30.0 (#679) * another batch of depencies upgrade (#683) - from version 20240926.01 * aggregate dependabot changes to go.mod (#677) * Revert back Source package info delivery to control-plane (#673) - from version 20240926.00 * Update OWNERS (#676) - from version 20240924.02 * Upgrade grpc and it's dependencies to latest version (#672) - from version 20240924.01 * Implement keepalive config (#671) - from version 20240924.00 * Set new version of gRPC for test (#669) - from version 20240920.00 * Revert &quot;bump version of the gRPC&quot; (#667) - from version 20240919.00 * bump version of the gRPC (#666) - from version 20240917.00 * Merge pull request #665 from GoogleCloudPlatform/revert-664-update_grpc_dependency * Revert &quot;Update grpc library and other dependencies. (#664)&quot; - from version 20240916.00 * Update grpc library and other dependencies. (#664) - from version 20240913.00 * Move packagebuild presubmit to osconfig (#662) - from version 20240912.00 * Revert &quot;update osconfig api to v1.13.0 &amp; indirect dependency update&quot; (#659) - from version 20240822.00 * Revert &quot;Source package info delivery to control-plane (#639)&quot; (#656) - from version 20240821.00 * Fix golang version format to fix builds. (#655) - from version 20240814.01 * Use gcsfuse pkg in guest-policies e2e in pkg update tests instead of old pkgs (#653) * Replace osconfig-agent-test pkg by gcsfuse in ospolicies tests and inventory-report tests (#652) - from version 20240806.00 * Disable Repository Resource test for SLES-12 (#650) - Update to version 20240801.00 * Fix Debian-12 failing test by using gcsfuse pkg * Fix fetching gpg key unit tests (#649) - from version 20240729.00 * Fix for old state file on Windows (#648) - from version 20240723.00 * Add debugging logs for repository resource config (#646) - from version 20240718.00 * Fix SLES-12 SP5 RPM package-resource e2e test (#645) - from version 20240715.01 * Fix OSPolicies e2e tests for SLES-15 SP5 by removing zypper update from VMs startup script (#644) - from version 20240715.00 * Fix GuestPolicies e2e tests for SLES-15 SP5 by removing zypper update from VMs startup script (#643) - from version 20240709.01 * Source package info delivery to control-plane (#639) - from version 20240709.00 * Enable gpgcheck flag for RPM e2e tests (#638) - from version 20240708.00 * Update osconfig api to v1.13.0 * Indirect dependency update (#637) - from version 20240705.01 * Updating Windows &amp; Linux Chrome packages to fix failing e2e tests (#636) - from version 20240705.00 * Merge pull request #635 from Gulio/patch-1 * Update OWNERS - from version 20240702.02 * Remove RHEL-7 and CentOS-7 images from e2e tests (#634) - Update to version 20240702.01 * Use Debian-11 img in googet pkg build workflow (#632) - from version 20240702.00 * Pipeline testing 00 (#631) - from version 20240701.00 * update readme file (#628) - from version 20240625.01 * Updating yum install to support multi architecture based packages * Revert &quot;Adding Architecture to the packages being installed/updated in yum repo&quot; - from version 20240625.00 * Update old SLES images urls (#627) - from version 20240620.00 * Merge pull request #626 from GoogleCloudPlatform/yum-multiarch-fix * Adding Architecture to the packages being installed/updated in yum repo - from version 20240618.01 * Extract source_name(source_rpm) for rpm packages (#624) - from version 20240618.00 * update README.md file (#625) - from version 20240615.00 * Fix(dpkg) return onlt installed items as inventory (#623) * Extract source name and version for dpkg packages. (#622) - Update to version 20240607.00 * Update e2e tests to use VMM team's GCP project for pkgs testing version (#621) - from version 20240606.00 * Disable SUSE tests to run with testing agent repo (#619) - from version 20240604.00 * Fix the logic of pick region for Artifact Registry function (#618) - from version 20240603.00 * Disable centos-stream-8 tests as it reached EOL in May 31 (#617) - from version 20240529.00 * Merge pull request #610 from savijatv/patch-3 * Update cis-level1-once-a-day-policy.yaml - from version 20240528.00 * Merge pull request #616 from MahmoudOuka/allow-windows-e2e-tests-to-\ install-testing-version-of-agent-from-private-artifact-registry-repos * Allow Windows e2e tests to pull osconfig-agent pkg from testing (private) repos from Artifact registry - from version 20240527.01 * Merge pull request #615 from MahmoudOuka/fix-SUSE-e2e-tests * fix SUSE e2e tests - from version 20240527.00 * Merge pull request #614 from MahmoudOuka/allow-apt-and-yum-\ e2e-tests-to-pull-osconfig-agent-pkg-from-testing-repos * fix golint comments * Allow Apt &amp; Yum e2e tests to pull osconfig-agent pkg from testing repos - from version 20240524.03 * Merge pull request #611 from savijatv/patch-ospolicy-samples * Update to the CIS OS policy samples - from version 20240524.00 * Merge pull request #612 from MahmoudOuka/update-apt-e2e-tests-\ to-pull-osconfig-agent-pkg-from-new-ar-repos * fix golint comment * Update Apt e2e tests to pull osconfig-agent pkg from new AR repos instead of rapture - from version 20240523.02 * bump golang.org/x/crypto version (#613) - from version 20240523.00 * update go-cmp dependency (#604) - from version 20240522.00 * rollback masive dependency update (#603) * Bump google.golang.org/api from 0.180.0 to 0.181.0 (#596) - Update to version 20240517.00 * Bump cloud.google.com/go/auth from 0.4.1 to 0.4.2 (#597) - from version 20240516.01 * Bump cloud.google.com/go/logging from 1.9.0 to 1.10.0 (#595) * Bump cloud.google.com/go/storage from 1.40.0 to 1.41.0 (#594) - from version 20240516.00 * Bump google.golang.org/grpc from 1.63.2 to 1.64.0 (#593) - Update to version 20240513.02 * E2e tests: allow passing spesific EL version number to InstallOSConfigEL func (#592) - from version 20240513.01 * Bump google.golang.org/api from 0.179.0 to 0.180.0 (#591) - from version 20240513.00 * E2e tests: Fix EL version detection logic in E2E tests (#590) * Bump google.golang.org/api from 0.178.0 to 0.179.0 (#589) - from version 20240510.02 * Bump cloud.google.com/go/auth from 0.4.0 to 0.4.1 (#588) - from version 20240510.01 * E2e tests: use family url format instead of specific version URL for head test images (#587) - from version 20240510.00 * Fix for lock location (#586) - from version 20240509.03 * Bump cloud.google.com/go from 0.112.2 to 0.113.0 (#584) - from version 20240509.02 * Remove dependabot not needed label (#576) - from version 20240509.01 * Write inventory to attributes only if enabled (#486) - from version 20240509.00 * E2e tests: install gnupg2 and run apt update in VMs startup-scripts (#583) * Add a temporary e2e test image for Ubuntu to test the latest osconfig-agent stable version (#582) * Bump google.golang.org/api from 0.177.0 to 0.178.0 (#578) * Bump github.com/googleapis/gax-go/v2 from 2.12.3 to 2.12.4 (#579) * Bump cloud.google.com/go/iam from 1.1.7 to 1.1.8 (#577) * Bump cloud.google.com/go/auth from 0.3.0 to 0.4.0 (#580) * Bump go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc (#581) * Bump golang.org/x/net from 0.24.0 to 0.25.0 (#575) * Bump cloud.google.com/go/osconfig from 1.12.6 to 1.12.7 (#573) * Bump go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp (#574) * Bump cloud.google.com/go/longrunning from 0.5.6 to 0.5.7 (#571) - from version 20240508.08 * Bump github.com/golang/glog from 1.2.0 to 1.2.1 (#572) - from version 20240508.07 * Bump golang.org/x/text from 0.14.0 to 0.15.0 (#565) - from version 20240508.06 * Bump golang.org/x/oauth2 from 0.19.0 to 0.20.0 (#566) * Bump golang.org/x/sys from 0.19.0 to 0.20.0 (#564) - from version 20240508.05 * Bump go.opentelemetry.io/otel/trace from 1.24.0 to 1.26.0 (#563) - from version 20240508.04 * Bump google.golang.org/protobuf from 1.34.0 to 1.34.1 (#567) * Using the default reviewer set for PR approvals (#570) - from version 20240508.03 * Adding advanced CodeQL settings to scan on PRs (#569) - from version 20240508.02 * Update Debian-12 package build workflow to use debian-cloud project (#568) - from version 20240508.01 * Dependabot dependency updates (#562) - from version 20240508.00 * Revert &quot;Initial configuration of the dependabot for the direct and indirect d…&quot; (#561) * Initial configuration of the dependabot for the direct and indirect dependency scanning (#560) - from version 20240507.00 * Fix Debian-12 package build workflow typo (#559) - from version 20240506.00 * Use signed-by keyring approach for apt repos in Debian 12+ and Ubuntu 24+ (#558) - from version 20240501.03 * Logrus dependency update (#557) - from version 20240501.02 * Updating dependencies and respective checksums (#556) - from version 20240501.01 * Update go.mod (#554) - from version 20240501.00 * Bump golang.org/x/net from 0.17.0 to 0.23.0 (#542) - from version 20240430.01 * Remove SBOM generation logic from package build workflows (#553) - from version 20240425.00 * Fix e2e tests for exec-output size limit (#552) - from version 20240424.00 * Disabled some images which are either past EoL or broken (#549) - from version 20240423.01 * Copy packagebuild folder from guest-test-infra repo to osconfig repo (#545) * OS Config windows state file location changed (#544) - from version 20240423.00 * Removed debian-10 from e2e tests (#548) - from version 20240422.00 * Merge pull request #541 from GoogleCloudPlatform/michaljankowiak-patch-1 * Update OWNERS - from version 20240409.00 * Bump output size limit to 500KB (#538) Package grub2 was updated: - Fix zfs.mo not found message when booting on legacy BIOS (bsc#1237865) * 0001-autofs-Ignore-zfs-not-found.patch - Security fixes for 2024 * 0001-misc-Implement-grub_strlcpy.patch - Fix CVE-2024-45781 (bsc#1233617) * 0002-fs-ufs-Fix-a-heap-OOB-write.patch - Fix CVE-2024-56737 (bsc#1234958) - Fix CVE-2024-45782 (bsc#1233615) * 0003-fs-hfs-Fix-stack-OOB-write-with-grub_strcpy.patch - Fix CVE-2024-45780 (bsc#1233614) * 0004-fs-tar-Integer-overflow-leads-to-heap-OOB-write.patch - Fix CVE-2024-45783 (bsc#1233616) * 0005-fs-hfsplus-Set-a-grub_errno-if-mount-fails.patch * 0006-kern-file-Ensure-file-data-is-set.patch * 0007-kern-file-Implement-filesystem-reference-counting.patch - Fix CVE-2025-0624 (bsc#1236316) * 0008-net-Fix-OOB-write-in-grub_net_search_config_file.patch - Fix CVE-2024-45774 (bsc#1233609) * 0009-video-readers-jpeg-Do-not-permit-duplicate-SOF0-mark.patch - Fix CVE-2024-45775 (bsc#1233610) * 0010-commands-extcmd-Missing-check-for-failed-allocation.patch - Fix CVE-2025-0622 (bsc#1236317) * 0011-commands-pgp-Unregister-the-check_signatures-hooks-o.patch - Fix CVE-2025-0622 (bsc#1236317) * 0012-normal-Remove-variables-hooks-on-module-unload.patch - Fix CVE-2025-0622 (bsc#1236317) * 0013-gettext-Remove-variables-hooks-on-module-unload.patch - Fix CVE-2024-45776 (bsc#1233612) * 0014-gettext-Integer-overflow-leads-to-heap-OOB-write-or-.patch - Fix CVE-2024-45777 (bsc#1233613) * 0015-gettext-Integer-overflow-leads-to-heap-OOB-write.patch - Fix CVE-2025-0690 (bsc#1237012) * 0016-commands-read-Fix-an-integer-overflow-when-supplying.patch - Fix CVE-2025-1118 (bsc#1237013) * 0017-commands-minicmd-Block-the-dump-command-in-lockdown-.patch - Fix CVE-2024-45778 (bsc#1233606) - Fix CVE-2024-45779 (bsc#1233608) * 0018-fs-bfs-Disable-under-lockdown.patch - Fix CVE-2025-0677 (bsc#1237002) - Fix CVE-2025-0684 (bsc#1237008) - Fix CVE-2025-0685 (bsc#1237009) - Fix CVE-2025-0686 (bsc#1237010) - Fix CVE-2025-0689 (bsc#1237011) * 0019-fs-Disable-many-filesystems-under-lockdown.patch - Fix CVE-2025-1125 (bsc#1237014) - Fix CVE-2025-0678 (bsc#1237006) * 0020-fs-Prevent-overflows-when-allocating-memory-for-arra.patch - Bump upstream SBAT generation to 5 - grub2.spec: Add ofnet to signed grub.elf to support powerpc net boot installation when secure boot is enabled (bsc#1217761) (bsc#1228866) - Improved check for disk device when looking for PReP partition * 0004-Introduce-prep_load_env-command.patch Package haveged was updated: - Fix for bsc#1222296 and bsc#1165294.- Remove haveged-switch-root.service. - Add haveged-once.service. - Add patch files introducing the '--once' flag. * introduce-once-1.patch * introduce-once-2.patch Package hwdata was updated: - Update to version 0.394: * Update pci and vendor ids - Update to version 0.393: * Update pci, usb and vendor ids * Fix usb.ids encoding and a couple of typos * Fix configure to honor --prefix - Update to version 0.392: * Update pci and vendor ids - Update to version 0.391: * Update pci and vendor ids - update to 0.390: * Update pci and vendor ids update to 0.389: * Update pci and vendor ids - update to 0.385: * Update pci and vendor ids - update to 0.383: * Update pci and vendor ids - update to 0.382: * Update pci, usb and vendor ids Package hwinfo was updated: - merge gh#openSUSE/hwinfo#156- fix network card detection on aarch64 (bsc#1240648) - 21.88 - merge gh#openSUSE/hwinfo#152 - avoid reporting of spurious usb storage devices (bsc#1223330) - 21.87 - merge gh#openSUSE/hwinfo#151 - do not overdo usb device de-duplication (bsc#1239663) - 21.86 Package iproute2 was updated: - avoid spurious cgroup warning (bsc#1234383): - ss-Tone-down-cgroup-path-resolution.patch Package iputils was updated: - Security fix [bsc#1243772, CVE-2025-48964] * Fix integer overflow in ping statistics via zero timestamp * Add iputils-CVE-2025-48964_01.patch * Add iputils-CVE-2025-48964_02.patch * Add iputils-CVE-2025-48964_03.patch * Add iputils-CVE-2025-48964_regression.patch - Fix bsc#1243284 - ping on s390x prints invalid ttl * Add iputils-invalid-ttl-s390x.patch * Fix ipv4 ttl value when using SOCK_DGRAM on big endian systems - Security fix [bsc#1242300, CVE-2025-47268] * integer overflow in RTT calculation can lead to undefined behavior * Add iputils-CVE-2025-47268.patch Package jq was updated: Package kbd was updated: - Don't search for resources in the current directory. It can cause unwanted side effects or even infinite loop (bsc#1237230, kbd-ignore-working-directory-1.patch, kbd-ignore-working-directory-2.patch, kbd-ignore-working-directory-3.patch). Package kernel-default was updated: - ext4: fix OOB read when checking dotdot dir (bsc#1241640 CVE-2025-37785). - commit a1f98cf - Update patches.suse/arm64-bpf-Add-BHB-mitigation-to-the-epilogue-for-cBP.patch (bsc#1242778 CVE-2025-37948 bsc#1243649). - Update patches.suse/arm64-bpf-Only-mitigate-cBPF-programs-loaded-by-unpr.patch (bsc#1242778 CVE-2025-37963 bsc#1243660). - Update patches.suse/dm-stats-check-for-and-propagate-alloc_percpu-failur-d3aa.patch (git-fixes CVE-2023-53044 bsc#1242759). - commit 70937e2 - Update patches.suse/0001-netfs-Fix-missing-xas_retry-calls-in-xarray-iteratio.patch (bsc#1213946 CVE-2022-49810 bsc#1242489). - Update patches.suse/0037-dm-ioctl-fix-misbehavior-if-list_versions-races-with-module-loading.patch (git-fixes CVE-2022-49771 bsc#1242686). - Update patches.suse/ACPI-APEI-Fix-integer-overflow-in-ghes_estatus_pool_.patch (git-fixes CVE-2022-49885 bsc#1242735). - Update patches.suse/ALSA-hda-fix-potential-memleak-in-add_widget_node.patch (git-fixes CVE-2022-49835 bsc#1242385). - Update patches.suse/ALSA-usb-audio-Drop-snd_BUG_ON-from-snd_usbmidi_outp.patch (git-fixes CVE-2022-49772 bsc#1242147). - Update patches.suse/ASoC-core-Fix-use-after-free-in-snd_soc_exit.patch (git-fixes CVE-2022-49842 bsc#1242484). - Update patches.suse/Bluetooth-L2CAP-Fix-memory-leak-in-vhci_write.patch (CVE-2022-3619 bsc#1204569 CVE-2022-49908 bsc#1242157). - Update patches.suse/Bluetooth-L2CAP-Fix-use-after-free-caused-by-l2cap_r.patch (CVE-2022-3564 bsc#1206073 CVE-2022-49910 bsc#1242452). - Update patches.suse/Bluetooth-L2CAP-fix-use-after-free-in-l2cap_conn_del.patch (CVE-2022-3640 bsc#1204619 CVE-2022-49909 bsc#1242453). - Update patches.suse/Bluetooth-btsdio-fix-use-after-free-bug-in-btsdio_re-73f7b171b7c0.patch (git-fixes CVE-2023-53145 bsc#1243047). - Update patches.suse/HID-intel-ish-hid-ipc-Fix-potential-use-after-free-i.patch (git-fixes CVE-2023-53039 bsc#1242745). - Update patches.suse/IB-hfi1-Correctly-move-list-in-sc_disable.patch (git-fixes CVE-2022-49931 bsc#1242382). - Update patches.suse/Input-i8042-fix-leaking-of-platform-device-on-module.patch (git-fixes CVE-2022-49777 bsc#1242232). - Update patches.suse/Input-iforce-invert-valid-length-check-when-fetching.patch (git-fixes CVE-2022-49790 bsc#1242387). - Update patches.suse/PCI-s390-Fix-use-after-free-of-PCI-resources-with-pe.patch (git-fixes CVE-2023-53123 bsc#1242403). - Update patches.suse/RDMA-core-Fix-null-ptr-deref-in-ib_core_cleanup.patch (git-fixes CVE-2022-49925 bsc#1242371). - Update patches.suse/SUNRPC-Fix-a-server-shutdown-leak.patch (git-fixes CVE-2023-53131 bsc#1242377). - Update patches.suse/SUNRPC-Fix-null-ptr-deref-when-xps-sysfs-alloc-faile.patch (git-fixes CVE-2022-49928 bsc#1242369). - Update patches.suse/arm64-entry-avoid-kprobe-recursion.patch (git-fixes CVE-2022-49888 bsc#1242458). - Update patches.suse/ata-libata-transport-fix-double-ata_host_put-in-ata_.patch (git-fixes CVE-2022-49826 bsc#1242549). - Update patches.suse/ata-libata-transport-fix-error-handling-in-ata_tdev_.patch (git-fixes CVE-2022-49823 bsc#1242545). - Update patches.suse/ata-libata-transport-fix-error-handling-in-ata_tlink.patch (git-fixes CVE-2022-49824 bsc#1242547). - Update patches.suse/ata-libata-transport-fix-error-handling-in-ata_tport.patch (git-fixes CVE-2022-49825 bsc#1242548). - Update patches.suse/bnxt_en-Avoid-order-5-memory-allocation-for-TPA-data.patch (jsc#SLE-18978 CVE-2023-53134 bsc#1242380). - Update patches.suse/bnxt_en-Fix-possible-crash-in-bnxt_hwrm_set_coal.patch (git-fixes CVE-2022-49869 bsc#1242158). - Update patches.suse/bridge-switchdev-Fix-memory-leaks-when-changing-VLAN.patch (git-fixes CVE-2022-49812 bsc#1242151). - Update patches.suse/ca8210-fix-mac_len-negative-array-access.patch (git-fixes CVE-2023-53040 bsc#1242746). - Update patches.suse/can-af_can-fix-NULL-pointer-dereference-in-can_rx_re.patch (git-fixes CVE-2022-49863 bsc#1242169). - Update patches.suse/can-j1939-j1939_send_one-fix-missing-CAN-header-init.patch (git-fixes CVE-2022-49845 bsc#1243133). - Update patches.suse/capabilities-fix-potential-memleak-on-error-path-fro.patch (git-fixes CVE-2022-49890 bsc#1242469). - Update patches.suse/capabilities-fix-undefined-behavior-in-bit-shift-for.patch (git-fixes CVE-2022-49870 bsc#1242551). - Update patches.suse/ceph-avoid-putting-the-realm-twice-when-decoding-snaps-fails.patch (bsc#1206051 CVE-2022-49770 bsc#1242597). - Update patches.suse/cifs-Fix-connections-leak-when-tlink-setup-failed.patch (git-fixes CVE-2022-49822 bsc#1242544). - Update patches.suse/cifs-fix-use-after-free-bug-in-refresh_cache_worker-.patch (bsc#1193629 CVE-2023-53052 bsc#1242749). - Update patches.suse/dmaengine-mv_xor_v2-Fix-a-resource-leak-in-mv_xor_v2.patch (git-fixes CVE-2022-49861 bsc#1242580). - Update patches.suse/dmaengine-ti-k3-udma-glue-fix-memory-leak-when-regis.patch (git-fixes CVE-2022-49860 bsc#1242586). - Update patches.suse/drm-Fix-potential-null-ptr-deref-in-drm_vblank_destr.patch (git-fixes CVE-2022-49827 bsc#1242689). - Update patches.suse/drm-amd-display-fix-shift-out-of-bounds-in-Calculate.patch (git-fixes CVE-2023-53077 bsc#1242752). - Update patches.suse/drm-amdkfd-Fix-NULL-pointer-dereference-in-svm_migra.patch (git-fixes CVE-2022-49864 bsc#1242685). - Update patches.suse/drm-amdkfd-Fix-an-illegal-memory-access.patch (git-fixes CVE-2023-53090 bsc#1242753). - Update patches.suse/drm-drv-Fix-potential-memory-leak-in-drm_dev_init.patch (git-fixes CVE-2022-49830 bsc#1242150). - Update patches.suse/drm-i915-active-Fix-misuse-of-non-idle-barriers-as-f.patch (git-fixes CVE-2023-53087 bsc#1242280). - Update patches.suse/drm-shmem-helper-Remove-another-errant-put-in-error-.patch (git-fixes CVE-2023-53084 bsc#1242294). - Update patches.suse/ext4-Fix-possible-corruption-when-moving-a-directory.patch (bsc#1210763 CVE-2023-53137 bsc#1242358). - Update patches.suse/ext4-fix-BUG_ON-when-directory-entry-has-invalid-rec.patch (bsc#1206886 CVE-2022-49879 bsc#1242733). - Update patches.suse/ext4-fix-WARNING-in-ext4_update_inline_data.patch (bsc#1213012 CVE-2023-53100 bsc#1242790). - Update patches.suse/ext4-fix-another-off-by-one-fsmap-error-on-1k-block-.patch (bsc#1210767 CVE-2023-53143 bsc#1242276). - Update patches.suse/ext4-fix-task-hung-in-ext4_xattr_delete_inode.patch (bsc#1213096 CVE-2023-53089 bsc#1242744). - Update patches.suse/ext4-fix-warning-in-ext4_da_release_space.patch (bsc#1206887 CVE-2022-49880 bsc#1242734). - Update patches.suse/ext4-update-s_journal_inum-if-it-changes-after-journ.patch (bsc#1213094 CVE-2023-53091 bsc#1242767). - Update patches.suse/ext4-zero-i_disksize-when-initializing-the-bootloade.patch (bsc#1213013 CVE-2023-53101 bsc#1242791). - Update patches.suse/firmware-xilinx-don-t-make-a-sleepable-memory-alloca.patch (git-fixes CVE-2023-53099 bsc#1242399). - Update patches.suse/ftrace-Fix-invalid-address-access-in-lookup_rec-when-index-is-0.patch (git-fixes CVE-2023-53075 bsc#1242218). - Update patches.suse/ftrace-Fix-null-pointer-dereference-in-ftrace_add_mod.patch (git-fixes CVE-2022-49802 bsc#1242270). - Update patches.suse/ftrace-Fix-use-after-free-for-dynamic-ftrace_ops.patch (git-fixes CVE-2022-49892 bsc#1242449). - Update patches.suse/gfs2-Check-sb_bsize_shift-after-reading-superblock.patch (git-fixes CVE-2022-49769 bsc#1242440). - Update patches.suse/i2c-piix4-Fix-adapter-not-be-removed-in-piix4_remove.patch (git-fixes CVE-2022-49900 bsc#1242454). - Update patches.suse/i40e-Fix-kernel-crash-during-reboot-when-adapter-is-.patch (jsc#SLE-18378 CVE-2023-53114 bsc#1242398). - Update patches.suse/iavf-fix-hang-on-reboot-with-ice.patch (jsc#SLE-18385 CVE-2023-53064 bsc#1242222). - Update patches.suse/ibmvnic-Free-rwi-on-reset-success.patch (bsc#1184350 ltc#191533 git-fixes CVE-2022-49906 bsc#1242464). - Update patches.suse/ice-copy-last-block-omitted-in-ice_get_module_eeprom.patch (git-fixes CVE-2023-53142 bsc#1242282). - Update patches.suse/igb-revert-rtnl_lock-that-causes-deadlock.patch (jsc#SLE-18379 CVE-2023-53060 bsc#1242241). - Update patches.suse/iio-adc-at91_adc-fix-possible-memory-leak-in-at91_ad.patch (git-fixes CVE-2022-49794 bsc#1242392). - Update patches.suse/iio-adc-mp2629-fix-potential-array-out-of-bound-acce.patch (git-fixes CVE-2022-49792 bsc#1242389). - Update patches.suse/iio-trigger-sysfs-fix-possible-memory-leak-in-iio_sy.patch (git-fixes CVE-2022-49793 bsc#1242391). - Update patches.suse/interconnect-exynos-fix-node-leak-in-probe-PM-QoS-er.patch (git-fixes CVE-2023-53092 bsc#1242415). - Update patches.suse/interconnect-fix-mem-leak-when-freeing-nodes.patch (git-fixes CVE-2023-53096 bsc#1242289). - Update patches.suse/ipv6-addrlabel-fix-infoleak-when-sending-struct-ifad.patch (git-fixes CVE-2022-49865 bsc#1242570). - Update patches.suse/kprobes-Skip-clearing-aggrprobe-s-post_handler-in-kprobe-on-ftrace-case.patch (git-fixes CVE-2022-49779 bsc#1242261). - Update patches.suse/loop-Fix-use-after-free-issues.patch (bsc#1214991 CVE-2023-53111 bsc#1242428). - Update patches.suse/mISDN-fix-misuse-of-put_device-in-mISDN_register_dev.patch (git-fixes CVE-2022-49818 bsc#1242527). - Update patches.suse/mISDN-fix-possible-memory-leak-in-mISDN_dsp_element_.patch (git-fixes CVE-2022-49821 bsc#1242542). - Update patches.suse/mISDN-fix-possible-memory-leak-in-mISDN_register_dev.patch (git-fixes CVE-2022-49915 bsc#1242409). - Update patches.suse/macvlan-enforce-a-consistent-minimal-mtu.patch (git-fixes CVE-2022-49776 bsc#1242248). - Update patches.suse/media-meson-vdec-fix-possible-refcount-leak-in-vdec_.patch (git-fixes CVE-2022-49887 bsc#1242736). - Update patches.suse/media-rc-gpio-ir-recv-add-remove-function.patch (git-fixes CVE-2023-53098 bsc#1242779). - Update patches.suse/misc-vmw_vmci-fix-an-infoleak-in-vmci_host_do_receiv.patch (git-fixes CVE-2022-49788 bsc#1242353). - Update patches.suse/mmc-sdhci-pci-Fix-possible-memory-leak-caused-by-mis.patch (git-fixes CVE-2022-49787 bsc#1242352). - Update patches.suse/msft-hv-2675-HID-hyperv-fix-possible-memory-leak-in-mousevsc_prob.patch (git-fixes CVE-2022-49874 bsc#1242478). - Update patches.suse/net-ena-Fix-error-handling-in-ena_init.patch (git-fixes CVE-2022-49813 bsc#1242497). - Update patches.suse/net-iucv-Fix-size-of-interrupt-data.patch (bsc#1211465 git-fixes CVE-2023-53108 bsc#1242422). - Update patches.suse/net-macvlan-fix-memory-leaks-of-macvlan_common_newli.patch (git-fixes CVE-2022-49853 bsc#1242688). - Update patches.suse/net-mlx5-E-Switch-Fix-an-Oops-in-error-handling-code.patch (jsc#SLE-19253 CVE-2023-53058 bsc#1242237). - Update patches.suse/net-mlx5-Fix-steering-rules-cleanup.patch (jsc#SLE-19253 CVE-2023-53079 bsc#1242765). - Update patches.suse/net-smc-Fix-possible-leaked-pernet-namespace-in-smc_init (git-fixes CVE-2022-49905 bsc#1242467). - Update patches.suse/net-tun-Fix-memory-leaks-of-napi_get_frags.patch (git-fixes CVE-2022-49871 bsc#1242558). - Update patches.suse/net-usb-lan78xx-Limit-packet-length-to-skb-len.patch (git-fixes CVE-2023-53068 bsc#1242239). - Update patches.suse/net-usb-smsc75xx-Limit-packet-length-to-skb-len.patch (git-fixes CVE-2023-53125 bsc#1242285). - Update patches.suse/net-usb-smsc95xx-Limit-packet-length-to-skb-len.patch (git-fixes CVE-2023-53062 bsc#1242228). - Update patches.suse/net-x25-Fix-skb-leak-in-x25_lapb_receive_frame.patch (git-fixes CVE-2022-49809 bsc#1242402). - Update patches.suse/nfc-fdp-Fix-potential-memory-leak-in-fdp_nci_send.patch (git-fixes CVE-2022-49924 bsc#1242426). - Update patches.suse/nfc-fdp-add-null-check-of-devm_kmalloc_array-in-fdp_.patch (git-fixes CVE-2023-53139 bsc#1242361). - Update patches.suse/nfc-nfcmrvl-Fix-potential-memory-leak-in-nfcmrvl_i2c.patch (git-fixes CVE-2022-49922 bsc#1242378). - Update patches.suse/nfc-nxp-nci-Fix-potential-memory-leak-in-nxp_nci_sen.patch (git-fixes CVE-2022-49923 bsc#1242394). - Update patches.suse/nfc-pn533-initialize-struct-pn533_out_arg-properly.patch (git-fixes CVE-2023-53119 bsc#1242370). - Update patches.suse/nfc-st-nci-Fix-use-after-free-bug-in-ndlc_remove-due.patch (git-fixes bsc#1210337 CVE-2023-1990 CVE-2023-53106 bsc#1242215). - Update patches.suse/nfs4-Fix-kmemleak-when-allocate-slot-failed.patch (git-fixes CVE-2022-49927 bsc#1242416). - Update patches.suse/nilfs2-fix-deadlock-in-nilfs_count_free_blocks.patch (git-fixes CVE-2022-49850 bsc#1242164). - Update patches.suse/nilfs2-fix-kernel-infoleak-in-nilfs_ioctl_wrap_copy.patch (git-fixes CVE-2023-53035 bsc#1242739). - Update patches.suse/nilfs2-fix-use-after-free-bug-of-ns_writer-on-remoun.patch (git-fixes CVE-2022-49834 bsc#1242695). - Update patches.suse/nvmet-avoid-potential-UAF-in-nvmet_req_complete.patch (git-fixes CVE-2023-53116 bsc#1242411). - Update patches.suse/nvmet-fix-a-memory-leak-in-nvmet_auth_set_key.patch (git-fixes CVE-2022-49807 bsc#1242357). - Update patches.suse/ocfs2-fix-data-corruption-after-failed-write.patch (bsc#1208542 CVE-2023-53081 bsc#1242281). - Update patches.suse/octeontx2-pf-Fix-SQE-threshold-checking.patch (jsc#SLE-24682 CVE-2022-49858 bsc#1242589). - Update patches.suse/perf-core-Fix-perf_output_begin-parameter-is-incorrectly-invoked-in-perf_event_bpf_output.patch (git fixes CVE-2023-53065 bsc#1242229). - Update patches.suse/phy-ralink-mt7621-pci-add-sentinel-to-quirks-table.patch (git-fixes CVE-2022-49868 bsc#1242550). - Update patches.suse/pinctrl-devicetree-fix-null-pointer-dereferencing-in.patch (git-fixes CVE-2022-49832 bsc#1242154). - Update patches.suse/platform-chrome-cros_ec_chardev-fix-kernel-data-leak.patch (git-fixes CVE-2023-53059 bsc#1242230). - Update patches.suse/qed-qed_sriov-guard-against-NULL-derefs-from-qed_iov.patch (jsc#SLE-19001 CVE-2023-53066 bsc#1242227). - Update patches.suse/ring-buffer-Check-for-NULL-cpu_buffer-in-ring_buffer.patch (bsc#1204705 CVE-2022-49889 bsc#1242455). - Update patches.suse/rose-Fix-NULL-pointer-dereference-in-rose_send_frame.patch (git-fixes CVE-2022-49916 bsc#1242421). - Update patches.suse/scsi-core-Remove-the-proc-scsi-proc_name-directory-earlier.patch (git-fixes CVE-2023-53140 bsc#1242372). - Update patches.suse/scsi-lpfc-Check-kzalloc-in-lpfc_sli4_cgn_params_read.patch (git-fixes CVE-2023-53038 bsc#1242743). - Update patches.suse/scsi-mpt3sas-Fix-NULL-pointer-access-in-mpt3sas_transport_port_add.patch (git-fixes CVE-2023-53124 bsc#1242165). - Update patches.suse/scsi-qla2xxx-Perform-lockless-command-completion-in-abort-path.patch (git-fixes CVE-2023-53041 bsc#1242747). - Update patches.suse/scsi-qla2xxx-Synchronize-the-IOCB-count-to-be-in-ord.patch (bsc#1209292 bsc#1209684 bsc#1209556 CVE-2023-53056 bsc#1242219). - Update patches.suse/scsi-scsi_dh_alua-Fix-memleak-for-qdata-in-alua_activate.patch (git-fixes CVE-2023-53078 bsc#1242231). - Update patches.suse/scsi-scsi_transport_sas-Fix-error-handling-in-sas_phy_add.patch (git-fixes CVE-2022-49839 bsc#1242443). - Update patches.suse/scsi-zfcp-Fix-double-free-of-FSF-request-when-qdio-send-fails (git-fixes CVE-2022-49789 bsc#1242366). - Update patches.suse/serial-imx-Add-missing-.thaw_noirq-hook.patch (git-fixes CVE-2022-49841 bsc#1242473). - Update patches.suse/siox-fix-possible-memory-leak-in-siox_device_add.patch (git-fixes CVE-2022-49836 bsc#1242355). - Update patches.suse/tracing-Do-not-let-histogram-values-have-some-modifiers.patch (git-fixes CVE-2023-53093 bsc#1242279). - Update patches.suse/tracing-Fix-memory-leak-in-test_gen_synth_cmd-and-test_empty_synth_event.patch (git-fixes CVE-2022-49800 bsc#1242265). - Update patches.suse/tracing-Fix-memory-leak-in-tracing_read_pipe.patch (git-fixes CVE-2022-49801 bsc#1242338). - Update patches.suse/tracing-Fix-wild-memory-access-in-register_synth_event.patch (git-fixes CVE-2022-49799 bsc#1242264). - Update patches.suse/tracing-kprobe-Fix-memory-leak-in-test_gen_kprobe-kretprobe_cmd.patch (git-fixes CVE-2022-49891 bsc#1242456). - Update patches.suse/tracing-kprobe-Fix-potential-null-ptr-deref-on-trace_array-in-kprobe_event_gen_test_exit.patch (git-fixes CVE-2022-49796 bsc#1242305). - Update patches.suse/tracing-kprobe-Fix-potential-null-ptr-deref-on-trace_event_file-in-kprobe_event_gen_test_exit.patch (git-fixes CVE-2022-49797 bsc#1242320). - Update patches.suse/udf-Fix-a-slab-out-of-bounds-write-bug-in-udf_find_e.patch (bsc#1206649 CVE-2022-49846 bsc#1242716). - Update patches.suse/usb-dwc2-fix-a-devres-leak-in-hw_enable-upon-suspend.patch (git-fixes CVE-2023-53054 bsc#1242226). - Update patches.suse/usb-gadget-u_audio-don-t-let-userspace-block-driver-.patch (git-fixes CVE-2023-53045 bsc#1242756). - Update patches.suse/usb-ucsi-Fix-NULL-pointer-deref-in-ucsi_connector_ch.patch (git-fixes CVE-2023-53049 bsc#1242244). - Update patches.suse/wifi-cfg80211-fix-memory-leak-in-query_regdb_file.patch (git-fixes CVE-2022-49881 bsc#1242481). - Update patches.suse/x86-fpu-Drop-fpregs-lock-before-inheriting-FPU-permissions.patch (bnc#1205282 CVE-2022-49783 bsc#1242312). - commit b466a4e - arm64: proton-pack: Add new CPUs 'k' values for branch mitigation (bsc#1242778). - commit 9eea847 - arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users (bsc#1242778). - commit 8fea3ff - arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs (bsc#1242778). - commit 40fcf50 - arm64: proton-pack: Expose whether the branchy loop k value (bsc#1242778). - commit ec2de57 - arm64: proton-pack: Expose whether the platform is mitigated by firmware (bsc#1242778). - arm64: insn: Add support for encoding DSB (bsc#1242778). - commit ae7bc9f - Refresh patches.kabi/kabi-allow-extra-bugints.patch. - commit 335bd7e - hv_netvsc: Remove rmsg_pgcnt (bsc#1243737). - hv_netvsc: Preserve contiguous PFN grouping in the page buffer array (bsc#1243737). - hv_netvsc: Use vmbus_sendpacket_mpb_desc() to send VMBus messages (bsc#1243737). - Drivers: hv: Allow vmbus_sendpacket_mpb_desc() to create multiple ranges (bsc#1243737). - scsi: storvsc: Set correct data length for sending SCSI command without payload (git-fixes). - commit 19dfad0 - Remove debug flavor (bsc#1243919). This is only released in Leap, and we don't have Leap 15.4 anymore. - commit 30c990a - Refresh fixes for cBPF issue (bsc#1242778) - Update metadata and put them into the sorted part of the series - Refresh patches.suse/x86-bhi-do-not-set-BHI_DIS_S-in-32-bit-mode.patch. - Refresh patches.suse/x86-bpf-add-IBHF-call-at-end-of-classic-BPF.patch. - Refresh patches.suse/x86-bpf-call-branch-history-clearing-sequence-on-exit.patch. - commit 46d2b60 - mptcp: fix NULL pointer in can_accept_new_subflow (CVE-2025-23145 bsc#1242596). - mptcp: relax check on MPC passive fallback (CVE-2025-23145 bsc#1242596). - mptcp: refine opt_mp_capable determination (CVE-2025-23145 bsc#1242596). - mptcp: use OPTION_MPTCP_MPJ_SYN in subflow_check_req() (CVE-2025-23145 bsc#1242596). - mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect() (CVE-2025-23145 bsc#1242596). - mptcp: strict validation before using mp_opt-&gt;hmac (CVE-2025-23145 bsc#1242596). - mptcp: mptcp_parse_option() fix for MPTCPOPT_MP_JOIN (CVE-2025-23145 bsc#1242596). - mptcp: Fix duplicated argument in protocol.h (CVE-2025-23145 bsc#1242596). - mptcp: consolidate in_opt sub-options fields in a bitmask (CVE-2025-23145 bsc#1242596). - mptcp: better binary layout for mptcp_options_received (CVE-2025-23145 bsc#1242596). - mptcp: do not set unconditionally csum_reqd on incoming opt (CVE-2025-23145 bsc#1242596). - commit 3eef261 - RDMA/mlx5: Fix a WARN during dereg_mr for DM type (CVE-2025-21888 bsc#1240177) - commit a053ba8 - net: make sock_inuse_add() available (CVE-2024-53168 bsc#1234887). - commit a64cc81 - sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket (CVE-2024-53168 bsc#1234887). - commit 2087675 - Refresh patches.kabi/kabi-allow-extra-bugints.patch. - commit ba9a618 - mtd: phram: Add the kernel lock down check (bsc#1232649). - commit af6a7f8 - Refresh patches.suse/ACPI-processor-idle-return-an-error-if-both-P_LVL-2-.patch. The patch has meanwhile been merged upstream. Add it to the sorted section. - commit 2243312 - nfsd: make sure exp active before svc_export_show (CVE-2024-56558 bsc#1235100). - commit 3fbc559 - netfilter: nft_tunnel: fix geneve_opt type confusion addition (CVE-2025-22056 bsc#1241525). - commit ead34ea - net: mvpp2: Prevent parser TCAM memory corruption (CVE-2025-22060 bsc#1241526). - net: mvpp2: parser fix QinQ (CVE-2025-22060 bsc#1241526). - commit d211f59 - scsi: core: Fix unremoved procfs host directory regression (git-fixes). - commit fcdce73 - tcp: cdg: allow tcp_cdg_release() to be called multiple times (CVE-2022-49775 bsc#1242245) - commit 1480658 - ocfs2: fix the issue with discontiguous allocation in the global_bitmap (git-fixes). - commit 1773903 - Update patches.suse/scsi-core-Fix-a-procfs-host-directory-removal-regression.patch (git-fixes CVE-2023-53118 bsc#1242365). updated meta-data, adding new CVE and bug references - commit 87fcd7f - proc: fix UAF in proc_get_inode() (bsc#1240802 CVE-2025-21999). - commit 8fb7944 - net: openvswitch: fix nested key length validation in the set() action (CVE-2025-37789 bsc#1242762). - commit 52f7543 - netfilter: conntrack: revisit the gc initial rescheduling bias (CVE-2022-49110 bsc#1237981). - commit 7e1d902 - netfilter: conntrack: fix the gc rescheduling delay (CVE-2022-49110 bsc#1237981). - commit 9cc8bdd - netfilter: conntrack: revisit gc autotuning (CVE-2022-49110 bsc#1237981). - commit da48bfa - Bluetooth: fix null ptr deref on hci_sync_conn_complete_evt (bsc#1238032 CVE-2022-49139). - commit 2031355 - watch_queue: fix pipe accounting mismatch (CVE-2025-23138 bsc#1241648). - commit 789ef85 - 9p/trans_fd: always use O_NONBLOCK read/write (CVE-2022-49767 bsc#1242493). - commit 9dce75d - Update patches.suse/dm-crypt-add-cond_resched-to-dmcrypt_write-fb29.patch (git-fixes CVE-2023-53051 bsc#1242284). - commit 33b6152 - x86/bhi: Do not set BHI_DIS_S in 32-bit mode (bsc#1242778). - x86/bpf: Add IBHF call at end of classic BPF (bsc#1242778). - x86/bpf: Call branch history clearing sequence on exit (bsc#1242778). - commit bcd2c85 - Update patches.suse/can-etas_es58x-es58x_rx_err_msg-fix-memory-leak-in-e.patch (git-fixes stable-5.14.19 CVE-2021-47671 bsc#1241421). - commit 855e2af - Update patches.suse/net-mana-Fix-error-handling-in-mana_create_txq-rxq-s.patch (bsc#1240195 CVE-2024-46784 bsc#1230771). - commit b86bfe4 - Revert &quot;exec: fix the racy usage of fs_struct-&gt;in_exec (CVE-2025-22029&quot; This reverts commit b68bd5953c15c3c2b21e60fbd6d8a52b0bbb030c. This turned out to be not an issue. See https://bugzilla.suse.com/show_bug.cgi?id=1241378#c4 - commit d9d19c1 - exec: fix the racy usage of fs_struct-&gt;in_exec (CVE-2025-22029 bsc#1241378). - commit b68bd59 - x86/mm: Fix flush_tlb_range() when used for zapping normal PMDs (CVE-2025-22045 bsc#1241433). - commit c4ca325 - memstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove (bsc#1241280 CVE-2025-22020). - commit 0f74fae - drm/vkms: Fix use after free and double free on init error (CVE-2025-22097 bsc#1241541). - commit 02fe040 - net: fix geneve_opt length integer overflow (CVE-2025-22055 bsc#1241371). - commit 15ff527 - net: atm: fix use after free in lec_send() (CVE-2025-22004 bsc#1240835). - commit 889e26f - kABI workaround struct rcu_head and ax25_ptr (CVE-2025-21812 bsc#1238471). - commit 1d6ea68 - ax25: rcu protect dev-&gt;ax25_ptr (CVE-2025-21812 bsc#1238471). - Refresh patches.kabi/net-ax25_dev-kabi-workaround.patch. - commit 88b5c8e - Update patches.suse/fbdev-smscufx-fix-error-handling-code-in-ufx_usb_pro.patch (git-fixes CVE-2022-49741 bsc#1240747). - commit 0c9a431 - Update patches.suse/RDMA-mlx5-Fix-implicit-ODP-hang-on-parent-deregistra.patch (git-fixes CVE-2025-21886 bsc#1240188). - commit 6a0c1b0 - arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array (CVE-2025-21785 bsc#1238747) - commit 2c96a9a - vrf: use RCU protection in l3mdev_l3_out() (CVE-2025-21791 bsc#1238512). - commit 50bbf71 - Delete patches.suse/btrfs-defrag-don-t-use-merged-extent-map-for-their-generat.patch. - Delete patches.suse/btrfs-fix-defrag-not-merging-contiguous-extents-due-to-mer.patch. - Delete patches.suse/btrfs-fix-extent-map-merging-not-happening-for-adjacent-ex.patch. Reverting ineffective changes for bsc#1239968 and closing it as WONTFIX. - commit a1bc1ab - padata: avoid UAF for reorder_work (CVE-2025-21726 bsc#1238865). - commit bfab8c2 - kABI: Fix kABI after backport od CVE-2025-21839 (bsc#1239061 CVE-2025-21839). - commit 38fa6d3 - KVM: x86: Load DR6 with guest value only before entering .vcpu_run() loop (bsc#1239061 CVE-2025-21839). - commit 325b428 - KVM: X86: Set host DR6 only on VMX and for KVM_DEBUGREG_WONT_EXIT (bsc#1239061 CVE-2025-21839). - commit 8727046 - KVM: X86: Remove unneeded KVM_DEBUGREG_RELOAD (bsc#1239061 CVE-2025-21839). - commit bbb1715 - gfs2: Fix inode height consistency check (git-fixes). - gfs2: Always check inode size of inline inodes (bsc#1240207 CVE-2022-49739). - gfs2: Cosmetic gfs2_dinode_{in,out} cleanup (bsc#1240207 CVE-2022-49739). - commit a949c3f - Revert &quot;gfs2: Fix inode height consistency check (git-fixes).&quot; This reverts commit 935054ab3fe2351d6b7c7a49e49bc57d5ae66ce2. The revert commit will re-add by bsc#1240207 bug fix - commit f6fc2e8 - Refresh patches.suse/blk-throttle-Set-BIO_THROTTLED-when-bio-has-been-throttled.patch. The original version had a back-port mistake that cause aregression. - commit fb94b71 - mm/khugepaged: fix -&gt;anon_vma race (CVE-2023-52935 bsc#1240276). - commit 6257477 - net: mana: Fix error handling in mana_create_txq/rxq's NAPI cleanup (bsc#1240195). - Refresh patches.suse/net-mana-Enable-debugfs-files-for-MANA-device.patch. - commit 15a2f6b - net: mana: Support holes in device list reply msg (bsc#1240133). - commit 1dee3f4 - Update patches.suse/media-cx24116-prevent-overflows-on-SNR-calculus.patch (CVE-2024-50290 bsc#1233479 bsc#1225742). - Update patches.suse/media-dvbdev-prevent-the-risk-of-out-of-memory-acces.patch (CVE-2024-53063 bsc#1233557 bsc#1225742). - commit 4c491c6 - Update patches.suse/ALSA-hda-via-Avoid-potential-array-out-of-bound-in-a.patch (git-fixes CVE-2023-52988 bsc#1240293). - Update patches.suse/Bluetooth-Fix-possible-deadlock-in-rfcomm_sk_state_c.patch (git-fixes CVE-2023-53016 bsc#1240281). - Update patches.suse/HID-betop-check-shape-of-output-reports.patch (git-fixes bsc#1207186 CVE-2023-53015 bsc#1240288). - Update patches.suse/NFSD-fix-use-after-free-in-nfsd4_ssc_setup_dul.patch (git-fixes bsc#1209788 CVE-2023-1652 CVE-2023-53025 bsc#1240264). - Update patches.suse/RDMA-core-Fix-ib-block-iterator-counter-overflow.patch (bsc#1207878 CVE-2023-53026 bsc#1240308). - Update patches.suse/Revert-wifi-mac80211-fix-memory-leak-in-ieee80211_if.patch (git-fixes CVE-2023-53028 bsc#1240212). - Update patches.suse/Squashfs-fix-handling-and-sanity-checking-of-xattr_i.patch (git-fixes CVE-2023-52933 bsc#1240275). - Update patches.suse/block-bfq-fix-uaf-for-bfqq-in-bic_set_bfqq-b600.patch (git-fixes CVE-2023-52983 bsc#1240284). - Update patches.suse/bnxt-Do-not-read-past-the-end-of-test-names.patch (jsc#SLE-18978 CVE-2023-53010 bsc#1240290). - Update patches.suse/bpf-Fix-pointer-leak-due-to-insufficient-speculative.patch (bsc#1231375 CVE-2023-53024 bsc#1240272). - Update patches.suse/bpf-Skip-task-with-pid-1-in-send_signal_common.patch (git-fixes CVE-2023-52992 bsc#1240317). - Update patches.suse/can-isotp-split-tx-timer-into-transmission-and-timeo.patch (git-fixes CVE-2023-52941 bsc#1240280). - Update patches.suse/cifs-Fix-oops-due-to-uncleared-server-smbd_conn-in-reconnect.patch (git-fixes CVE-2023-53006 bsc#1240208). - Update patches.suse/cifs-fix-potential-memory-leaks-in-session-setup.patch (bsc#1193629 CVE-2023-53008 bsc#1240318). - Update patches.suse/drm-i915-Fix-potential-bit_17-double-free.patch (git-fixes CVE-2023-52930 bsc#1240304). - Update patches.suse/efi-fix-potential-NULL-deref-in-efi_mem_reserve_pers.patch (git-fixes CVE-2023-52976 bsc#1240283). - Update patches.suse/firewire-fix-memory-leak-for-payload-of-request-suba.patch (git-fixes CVE-2023-52989 bsc#1240266). - Update patches.suse/mm-memcg-fix-NULL-pointer-in-mem_cgroup_track_foreign_dirty_slowpath.patch (bsc#1209262 CVE-2023-52939 bsc#1240231). - Update patches.suse/net-mdio-validate-parameter-addr-in-mdiobus_get_phy.patch (git-fixes CVE-2023-53019 bsc#1240286). - Update patches.suse/net-nfc-Fix-use-after-free-in-local_cleanup.patch (git-fixes CVE-2023-53023 bsc#1240309). - Update patches.suse/net-phy-dp83822-Fix-null-pointer-access-on-DP83825-D.patch (git-fixes CVE-2023-52984 bsc#1240279). - Update patches.suse/netfilter-nft_payload-incorrect-arithmetics-when-fet.patch (CVE-2023-0179 bsc#1207034 CVE-2023-53033 bsc#1240210). - Update patches.suse/netlink-prevent-potential-spectre-v1-gadgets.patch (bsc#1209547 CVE-2017-5753 CVE-2023-53000 bsc#1240227). - Update patches.suse/octeontx2-pf-Avoid-use-of-GFP_KERNEL-in-atomic-conte.patch (git-fixes CVE-2023-53030 bsc#1240292). - Update patches.suse/octeontx2-pf-Fix-the-use-of-GFP_KERNEL-in-atomic-con.patch (git-fixes CVE-2023-53029 bsc#1240220). - Update patches.suse/scsi-iscsi_tcp-Fix-UAF-during-login-when-accessing-the-shost-ipaddress.patch (git-fixes CVE-2023-2162 bsc#1210647 CVE-2023-52974 bsc#1240213). - Update patches.suse/scsi-iscsi_tcp-Fix-UAF-during-logout-when-accessing-the-shost-ipaddress.patch (git-fixes CVE-2023-52975 bsc#1240322). - Update patches.suse/squashfs-harden-sanity-check-in-squashfs_read_xattr_.patch (git-fixes CVE-2023-52979 bsc#1240282). - Update patches.suse/trace_events_hist-add-check-for-return-value-of-create_hist_field.patch (git-fixes CVE-2023-53005 bsc#1240278). - Update patches.suse/tracing-Make-sure-trace_printk-can-output-as-soon-as-it-can-be-used.patch (git-fixes CVE-2023-53007 bsc#1240229). - Update patches.suse/vc_screen-move-load-of-struct-vc_data-pointer-in-vcs.patch (git-fixes bsc#1213167 CVE-2023-3567 CVE-2023-52973 bsc#1240218). - Update patches.suse/x86-i8259-Mark-legacy-PIC-interrupts-with-IRQ_LEVEL.patch (git-fixes CVE-2023-52993 bsc#1240297). - commit f69d55e - Update patches.suse/VMCI-Use-threaded-irqs-instead-of-tasklets.patch (git-fixes CVE-2022-49759 bsc#1240245). - Update patches.suse/dmaengine-Fix-double-increment-of-client_count-in-dm.patch (git-fixes CVE-2022-49753 bsc#1240250). - Update patches.suse/dmaengine-imx-sdma-Fix-a-possible-memory-leak-in-sdm.patch (git-fixes CVE-2022-49746 bsc#1240242). - Update patches.suse/perf-x86-amd-fix-potential-integer-overflow-on-shift-of-a-int.patch (git fixes CVE-2022-49748 bsc#1240256). - Update patches.suse/usb-gadget-f_fs-Prevent-race-during-ffs_ep0_queue_wa.patch (git-fixes CVE-2022-49755 bsc#1240247). - Update patches.suse/w1-fix-WARNING-after-calling-w1_process.patch (git-fixes CVE-2022-49751 bsc#1240254). - commit 67615b0 - Update patches.suse/can-j1939-fix-errant-WARN_ON_ONCE-in-j1939_session_d.patch (git-fixes CVE-2021-4454 bsc#1240205). - commit 3ad7432 - RDMA/mlx5: Fix implicit ODP hang on parent deregistration (git-fixes) - commit fb96cb5 - RDMA/mlx5: Fix a race for an ODP MR which leads to CQE with error (CVE-2025-21732 bsc#1237877) - commit 4fd8031 - RDMA/mlx5: Fix implicit ODP use after free (CVE-2025-21714 bsc#1237890) - commit b066549 - can: hi311x: hi3110_can_ist(): fix potential use-after-free (CVE-2024-56651 bsc#1235528). - commit c9a4975 - btrfs: fix use-after-free when attempting to join an aborted transaction (CVE-2025-21753 bsc#1237875) - commit 4b7aa14 - idpf: fix idpf_vc_core_init error path (CVE-2024-53064 bsc#1233558). - commit f7c6f3c - btrfs: send: fix invalid clone operation for file that got its size decreased (bsc#1239969). - btrfs: send: allow cloning non-aligned extent if it ends at i_size (bsc#1239969). - commit 6046fcc - net: mana: Allow variable size indirection table (bsc#1239016). - Refresh patches.suse/net-mana-Enable-debugfs-files-for-MANA-device.patch. - commit ab31abc - net: mana: Avoid open coded arithmetic (bsc#1239016). - RDMA/mana_ib: Prefer struct_size over open coded arithmetic (bsc#1239016). - net: mana: Add flex array to struct mana_cfg_rx_steer_req_v2 (bsc#1239016). - RDMA/mana_ib: Use v2 version of cfg_rx_steer_req to enable RX coalescing (bsc#1239016). - commit 3e2838d - btrfs: fix defrag not merging contiguous extents due to merged extent maps (bsc#1239968). - btrfs: fix extent map merging not happening for adjacent extents (bsc#1239968). - btrfs: defrag: don't use merged extent map for their generation check (bsc#1239968). - commit 7ca0c8b - scsi: target: tcmu: Fix possible page UAF (CVE-2022-49053 bsc#1237918). - commit 31de519 - KVM: Explicitly verify target vCPU is online in kvm_get_vcpu() (CVE-2024-58083 bsc#1239036). - commit c06a95f - ACPI: processor: idle: Return an error if both P_LVL{2,3} idle states are invalid (bsc#1237530). - commit bc72fe5 - mm/mmu_notifier.c: fix race in mmu_interval_notifier_remove() (bsc#1239126). - commit 9ba4a9a - mm: zswap: move allocations during CPU init outside the lock (git-fixes). - commit 2ba6fb9 - mm: zswap: properly synchronize freeing resources during CPU hotunplug (bsc#1237029 CVE-2025-21693). - commit a35b49f - mm/zswap: change per-cpu mutex and buffer to per-acomp_ctx (bsc#1237029 CVE-2025-21693). - commit 2a858ad - partitions: mac: fix handling of bogus partition table (CVE-2025-21772 bsc#1238911). - blk-throttle: Set BIO_THROTTLED when bio has been throttled (CVE-2022-49465 bsc#1238919). - commit 0fbb2d1 - crypto: ecdh - explicitly zeroize private_key (CVE-2024-42098 bsc#1228779). - commit b69238c - crypto: aead,cipher - zeroize key buffer after use (CVE-2024-42229 bsc#1228708). - commit 15d760d - Update patches.suse/dmaengine-qcom-bam_dma-fix-runtime-PM-underflow.patch (git-fixes CVE-2022-49650 bsc#1239452). - Update patches.suse/netfilter-nf_tables-initialize-registers-in-nft_do_c.patch (CVE-2022-1016 bsc#1197227 CVE-2022-49293 bsc#1239454). - commit 320b3f1 - Update patches.suse/x86-bhi-Avoid-warning-in-DB-handler-due-to-BHI-mitigation.patch (git-fixes CVE-2024-42240 bsc#1228966). - commit b914598 - drm/i915/gt: Fix potential UAF by revoke of fence registers (git-fixes CVE-2024-41092 bsc#1228483). - commit 8041e33 - Update patches.suse/net-usb-aqc111-Fix-out-of-bounds-accesses-in-RX-fixu.patch (bsc#1237903 CVE-2022-49051). Added CVE reference - commit 3c47ace - drm/amdgpu: avoid buffer overflow attach in smu_sys_set_pp_table() (bsc#1239115 CVE-2025-21780) - commit 698625c - Update patches.suse/0001-be2net-Fix-buffer-overflow-in-be_get_module_eeprom.patch (bsc#1201323 CVE-2022-49581 bsc#1238540). - Update patches.suse/0004-dm-fix-use-after-free-in-dm_cleanup_zoned_dev.patch (git-fixes CVE-2022-49270 bsc#1238459). - Update patches.suse/0005-drm-mediatek-Add-vblank-register-unregister-callback.patch (bsc#1190768 CVE-2022-49506 bsc#1238804). - Update patches.suse/0006-dm-integrity-fix-memory-corruption-when-tag_size-is-.patch (git-fixes CVE-2022-49044 bsc#1237840). - Update patches.suse/0009-block-bfq-don-t-move-oom_bfqq.patch (git-fixes CVE-2022-49179 bsc#1238092). - Update patches.suse/0010-bfq-fix-use-after-free-in-bfq_dispatch_request.patch (git-fixes CVE-2022-49176 bsc#1238097). - Update patches.suse/0011-dm-raid-fix-accesses-beyond-end-of-raid-member-array.patch (git-fixes CVE-2022-49674 bsc#1239041). - Update patches.suse/0012-dm-ioctl-prevent-potential-spectre-v1-gadget.patch (git-fixes CVE-2022-49122 bsc#1237983). - Update patches.suse/0014-drm-dp-Fix-OOB-read-when-handling-Post-Cursor2-regis.patch (bsc#1190786 CVE-2022-49218 bsc#1237785). - Update patches.suse/0015-bcache-avoid-journal-no-space-deadlock-by-reserving-.patch (git-fixes CVE-2022-49327 bsc#1238662). - Update patches.suse/0017-nbd-call-genl_unregister_family-first-in-nbd_cleanup.patch (git-fixes CVE-2022-49295 bsc#1238707). - Update patches.suse/0018-dm-mirror-log-round-up-region-bitmap-size-to-BITS_PE.patch (git-fixes CVE-2022-49710 bsc#1238417). - Update patches.suse/0018-nbd-fix-race-between-nbd_alloc_config-and-module-removal.patch (git-fixes CVE-2022-49300 bsc#1238183). - Update patches.suse/0019-block-Fix-handling-of-offline-queues-in-blk_mq_alloc.patch (git-fixes CVE-2022-49720 bsc#1238281). - Update patches.suse/0019-nbd-fix-io-hung-while-disconnecting-device.patch (git-fixes CVE-2022-49297 bsc#1238469). - Update patches.suse/9p-fix-fid-refcount-leak-in-v9fs_vfs_atomic_open_dot.patch (git-fixes CVE-2022-49705 bsc#1237990). - Update patches.suse/9p-fix-fid-refcount-leak-in-v9fs_vfs_get_link.patch (git-fixes CVE-2022-49704 bsc#1237780). - Update patches.suse/ACPI-CPPC-Avoid-out-of-bounds-access-when-parsing-_C.patch (git-fixes CVE-2022-49145 bsc#1238162). - Update patches.suse/ALSA-firewire-lib-fix-uninitialized-flag-for-AV-C-de.patch (git-fixes CVE-2022-49248 bsc#1238284). - Update patches.suse/ALSA-oss-Fix-PCM-OSS-buffer-allocation-overflow.patch (git-fixes CVE-2022-49292 bsc#1238625). - Update patches.suse/ALSA-pcm-Check-for-null-pointer-of-pointer-substream.patch (git-fixes CVE-2022-49498 bsc#1238825). - Update patches.suse/ALSA-pcm-Fix-potential-AB-BA-lock-with-buffer_mutex-.patch (CVE-2022-1048 bsc#1197331 CVE-2022-49272 bsc#1238272). - Update patches.suse/ALSA-pcm-Fix-races-among-concurrent-hw_params-and-hw.patch (CVE-2022-1048 bsc#1197331 git-fixes CVE-2022-49291 bsc#1238705). - Update patches.suse/ALSA-pcm-Fix-races-among-concurrent-prealloc-proc-wr.patch (CVE-2022-1048 bsc#1197331 git-fixes CVE-2022-49288 bsc#1238271). - Update patches.suse/ALSA-pcm-oss-Fix-race-at-SNDCTL_DSP_SYNC.patch (CVE-2022-3303 bsc#1203769 git-fixes CVE-2022-49733 bsc#1238454). - Update patches.suse/ALSA-usb-audio-Cancel-pending-work-at-closing-a-MIDI.patch (git-fixes CVE-2022-49545 bsc#1238729). - Update patches.suse/ARM-Fix-refcount-leak-in-axxia_boot_secondary.patch (git-fixes CVE-2022-49679 bsc#1238418). - Update patches.suse/ARM-cns3xxx-Fix-refcount-leak-in-cns3xxx_init.patch (git-fixes CVE-2022-49677 bsc#1238601). - Update patches.suse/ARM-exynos-Fix-refcount-leak-in-exynos_map_pmu.patch (git-fixes CVE-2022-49680 bsc#1238415). - Update patches.suse/ARM-hisi-Add-missing-of_node_put-after-of_find_compa.patch (git-fixes CVE-2022-49447 bsc#1238956). - Update patches.suse/ARM-meson-Fix-refcount-leak-in-meson_smp_prepare_cpu.patch (git-fixes CVE-2022-49656 bsc#1237812). - Update patches.suse/ASoC-Intel-sof_sdw-handle-errors-on-card-registratio.patch (git-fixes CVE-2022-49617 bsc#1238902). - Update patches.suse/ASoC-SOF-Intel-Fix-NULL-ptr-dereference-when-ENOMEM.patch (git-fixes CVE-2022-49268 bsc#1238090). - Update patches.suse/ASoC-atmel-Add-missing-of_node_put-in-at91sam9g20ek_.patch (git-fixes CVE-2022-49243 bsc#1238337). - Update patches.suse/ASoC-atmel-Fix-error-handling-in-sam9x5_wm8731_drive.patch (git-fixes CVE-2022-49241 bsc#1238116). - Update patches.suse/ASoC-atmel-Fix-error-handling-in-snd_proto_probe.patch (git-fixes CVE-2022-49246 bsc#1238302). - Update patches.suse/ASoC-codecs-rx-macro-fix-accessing-array-out-of-boun.patch (git-fixes CVE-2022-49252 bsc#1237787). - Update patches.suse/ASoC-codecs-rx-macro-fix-accessing-compander-for-aux.patch (git-fixes CVE-2022-49250 bsc#1238389). - Update patches.suse/ASoC-codecs-va-macro-fix-accessing-array-out-of-boun.patch (git-fixes CVE-2022-49251 bsc#1237835). - Update patches.suse/ASoC-codecs-wc938x-fix-accessing-array-out-of-bounds.patch (git-fixes CVE-2022-49249 bsc#1238339). - Update patches.suse/ASoC-codecs-wcd934x-Add-missing-of_node_put-in-wcd93.patch (git-fixes CVE-2022-49239 bsc#1238334). - Update patches.suse/ASoC-cs35l41-Fix-an-out-of-bounds-access-in-otp_pack.patch (bsc#1203699 CVE-2022-49515 bsc#1237817). - Update patches.suse/ASoC-fsl-Fix-refcount-leak-in-imx_sgtl5000_probe.patch (git-fixes CVE-2022-49486 bsc#1237946). - Update patches.suse/ASoC-imx-hdmi-Fix-refcount-leak-in-imx_hdmi_probe.patch (git-fixes CVE-2022-49480 bsc#1238799). - Update patches.suse/ASoC-mediatek-Fix-error-handling-in-mt8173_max98090_.patch (git-fixes CVE-2022-49514 bsc#1238429). - Update patches.suse/ASoC-mediatek-Fix-missing-of_node_put-in-mt2701_wm89.patch (git-fixes CVE-2022-49517 bsc#1237996). - Update patches.suse/ASoC-mediatek-mt8192-mt6359-Fix-error-handling-in-mt.patch (git-fixes CVE-2022-49244 bsc#1238176). - Update patches.suse/ASoC-mxs-Fix-error-handling-in-mxs_sgtl5000_probe.patch (git-fixes CVE-2022-49242 bsc#1238126). - Update patches.suse/ASoC-mxs-saif-Fix-refcount-leak-in-mxs_saif_probe.patch (git-fixes CVE-2022-49482 bsc#1238543). - Update patches.suse/ASoC-rt5645-Fix-errorenous-cleanup-order.patch (git-fixes CVE-2022-49493 bsc#1238939). - Update patches.suse/ASoC-rt7-sdw-harden-jack_detect_handler.patch (git-fixes CVE-2022-49616 bsc#1238898). - Update patches.suse/ASoC-rt711-sdca-fix-kernel-NULL-pointer-dereference-.patch (git-fixes CVE-2022-49615 bsc#1238897). - Update patches.suse/ASoC-samsung-Fix-refcount-leak-in-aries_audio_probe.patch (git-fixes CVE-2022-49477 bsc#1238295). - Update patches.suse/ASoC-ti-j721e-evm-Fix-refcount-leak-in-j721e_soc_pro.patch (git-fixes CVE-2022-49473 bsc#1238135). - Update patches.suse/Bluetooth-Fix-use-after-free-in-hci_send_acl.patch (git-fixes CVE-2022-49111 bsc#1237984). - Update patches.suse/Bluetooth-btmtksdio-Fix-kernel-oops-in-btmtksdio_int.patch (git-fixes CVE-2022-49200 bsc#1237958). - Update patches.suse/Bluetooth-fix-dangling-sco_conn-and-use-after-free-i.patch (git-fixes CVE-2022-49474 bsc#1238071). - Update patches.suse/Bluetooth-hci_qca-Use-del_timer_sync-before-freeing.patch (git-fixes CVE-2022-49555 bsc#1238231). - Update patches.suse/Bluetooth-use-memset-avoid-memory-leaks.patch (git-fixes CVE-2022-49116 bsc#1237922). - Update patches.suse/HID-elan-Fix-potential-double-free-in-elan_input_con.patch (git-fixes CVE-2022-49508 bsc#1237940). - Update patches.suse/IB-rdmavt-add-lock-to-call-to-rvt_error_qp-to-preven.patch (git-fixes CVE-2022-49089 bsc#1238041). - Update patches.suse/Input-gpio-keys-cancel-delayed-work-only-in-case-of-.patch (git-fixes CVE-2022-49430 bsc#1238870). - Update patches.suse/Input-sparcspkr-fix-refcount-leak-in-bbc_beep_probe.patch (git-fixes CVE-2022-49438 bsc#1238242). - Update patches.suse/KVM-Don-t-null-dereference-ops-destroy.patch (git-fixes CVE-2022-49568 bsc#1238792). - Update patches.suse/KVM-SVM-Use-kzalloc-for-sev-ioctl-interfaces-to-prev.patch (git-fixes CVE-2022-49556 bsc#1238134). - Update patches.suse/KVM-SVM-fix-panic-on-out-of-bounds-guest-IRQ.patch (git-fixes CVE-2022-49154 bsc#1238167). - Update patches.suse/KVM-VMX-Prevent-RSB-underflow-before-vmenter.patch (bsc#1199657 CVE-2022-29900 CVE-2022-29901 CVE-2022-49610 bsc#1238952). - Update patches.suse/KVM-x86-Drop-WARNs-that-assert-a-triple-fault-never-.patch (git-fixes CVE-2022-49559 bsc#1237942). - Update patches.suse/KVM-x86-Use-__try_cmpxchg_user-to-update-guest-PTE-A.patch (git-fixes CVE-2022-49562 bsc#1238309). - Update patches.suse/LSM-general-protection-fault-in-legacy_parse_param.patch (git-fixes CVE-2022-49180 bsc#1238110). - Update patches.suse/NFC-NULL-out-the-dev-rfkill-to-prevent-UAF.patch (git-fixes CVE-2022-49505 bsc#1238615). - Update patches.suse/NFS-Avoid-writeback-threads-getting-stuck-in-mempool.patch (git-fixes CVE-2022-49097 bsc#1237729). - Update patches.suse/NFSD-prevent-integer-overflow-on-32-bit-systems.patch (git-fixes CVE-2022-49279 bsc#1238655). - Update patches.suse/NFSD-prevent-underflow-in-nfssvc_decode_writeargs.patch (git-fixes CVE-2022-49280 bsc#1238630). - Update patches.suse/NFSv4-Don-t-hold-the-layoutget-locks-across-multiple.patch (git-fixes CVE-2022-49316 bsc#1238386). - Update patches.suse/NFSv4-Fix-free-of-uninitialized-nfs4_label-on-referr.patch (git-fixes CVE-2022-49418 bsc#1238878). - Update patches.suse/NFSv4.2-fix-reference-count-leaks-in-_nfs42_proc_cop.patch (git-fixes CVE-2022-49103 bsc#1238080). - Update patches.suse/PCI-Avoid-pci_dev_lock-AB-BA-deadlock-with-sriov_num.patch (git-fixes CVE-2022-49434 bsc#1238916). - Update patches.suse/PCI-endpoint-Fix-misused-goto-label.patch (git-fixes CVE-2022-49115 bsc#1237961). - Update patches.suse/PM-core-keep-irq-flags-in-device_pm_check_callbacks.patch (git-fixes CVE-2022-49175 bsc#1238099). - Update patches.suse/PM-devfreq-exynos-ppmu-Fix-refcount-leak-in-of_get_d.patch (git-fixes CVE-2022-49668 bsc#1237957). - Update patches.suse/PM-devfreq-rk3399_dmc-Disable-edev-on-remove.patch (git-fixes CVE-2022-49460 bsc#1238892). - Update patches.suse/PM-domains-Fix-sleep-in-atomic-bug-caused-by-genpd_d.patch (git-fixes CVE-2022-49265 bsc#1238432). - Update patches.suse/RDMA-cm-Fix-memory-leak-in-ib_cm_insert_listen.patch (git-fixes CVE-2022-49671 bsc#1238823). - Update patches.suse/RDMA-hfi1-Fix-potential-integer-multiplication-overf.patch (git-fixes CVE-2022-49404 bsc#1238430). - Update patches.suse/RDMA-hfi1-Fix-use-after-free-bug-for-mm-struct.patch (git-fixes CVE-2022-49076 bsc#1237738). - Update patches.suse/RDMA-hfi1-Prevent-panic-when-SDMA-is-disabled.patch (git-fixes CVE-2022-49429 bsc#1238889). - Update patches.suse/RDMA-hfi1-Prevent-use-of-lock-before-it-is-initializ.patch (git-fixes CVE-2022-49433 bsc#1238268). - Update patches.suse/RDMA-irdma-Fix-sleep-from-invalid-context-BUG.patch (git-fixes CVE-2022-49606 bsc#1238410). - Update patches.suse/RDMA-irdma-Prevent-some-integer-underflows.patch (git-fixes CVE-2022-49208 bsc#1238345). - Update patches.suse/RDMA-mlx5-Fix-memory-leak-in-error-flow-for-subscrib.patch (git-fixes CVE-2022-49206 bsc#1238343). - Update patches.suse/RDMA-nldev-Prevent-underflow-in-nldev_stat_set_count.patch (jsc#SLE-19249 CVE-2022-49199 bsc#1238234). - Update patches.suse/SUNRPC-Fix-the-svc_deferred_event-trace-class.patch (git-fixes CVE-2022-49065 bsc#1237739). - Update patches.suse/SUNRPC-Trap-RDMA-segment-overflows.patch (git-fixes CVE-2022-49356 bsc#1238444). - Update patches.suse/USB-host-isp116x-check-return-value-after-calling-pl.patch (git-fixes CVE-2022-49302 bsc#1238653). - Update patches.suse/afs-Fix-dynamic-root-getattr.patch (git-fixes CVE-2022-49688 bsc#1238423). - Update patches.suse/arch-arm64-Fix-topology-initialization-for-core-sche.patch (git-fixes CVE-2022-49090 bsc#1238021). - Update patches.suse/arm64-compat-Do-not-treat-syscall-number-as-ESR_ELx-.patch (git-fixes CVE-2022-49520 bsc#1238836). - Update patches.suse/arm64-ftrace-consistently-handle-PLTs.patch (git-fixes CVE-2022-49721 bsc#1237789). - Update patches.suse/ata-libata-core-fix-NULL-pointer-deref-in-ata_host_a.patch (git-fixes CVE-2022-49731 bsc#1239071). - Update patches.suse/ata-pata_octeon_cf-Fix-refcount-leak-in-octeon_cf_pr.patch (git-fixes CVE-2022-49354 bsc#1238636). - Update patches.suse/ata-sata_dwc_460ex-Fix-crash-due-to-OOB-write.patch (git-fixes CVE-2022-49073 bsc#1237746). - Update patches.suse/ath10k-Fix-error-handling-in-ath10k_setup_msa_resour.patch (git-fixes CVE-2022-49213 bsc#1238327). - Update patches.suse/ath10k-skip-ath10k_halt-during-suspend-for-driver-st.patch (git-fixes CVE-2022-49519 bsc#1238943). - Update patches.suse/ath11k-disable-spectral-scan-during-spectral-deinit.patch (git-fixes CVE-2022-49523 bsc#1238557). - Update patches.suse/ath11k-fix-kernel-panic-during-unload-load-ath11k-mo.patch (git-fixes CVE-2022-49131 bsc#1237966). - Update patches.suse/ath11k-mhi-use-mhi_sync_power_up.patch (git-fixes CVE-2022-49130 bsc#1237978). - Update patches.suse/ath11k-pci-fix-crash-on-suspend-if-board-file-is-not.patch (git-fixes CVE-2022-49132 bsc#1237976). - Update patches.suse/ath9k_htc-fix-potential-out-of-bounds-access-with-in.patch (git-fixes CVE-2022-49503 bsc#1238868). - Update patches.suse/ath9k_htc-fix-uninit-value-bugs.patch (git-fixes CVE-2022-49235 bsc#1238333). - Update patches.suse/bfq-Avoid-merging-queues-with-different-parents.patch (bsc#1197926 CVE-2022-49412 bsc#1238436). - Update patches.suse/bfq-Make-sure-bfqg-for-which-we-are-queueing-request.patch (bsc#1197926 CVE-2022-49411 bsc#1238307). - Update patches.suse/bfq-Update-cgroup-information-before-merging-bio.patch (bsc#1197926 CVE-2022-49413 bsc#1238710). - Update patches.suse/blk-iolatency-Fix-inflight-count-imbalances-and-IO-h.patch (bsc#1200825 CVE-2022-49394 bsc#1238712). - Update patches.suse/blk-mq-don-t-touch-tagset-in-blk_mq_get_sq_hctx.patch (bsc#1200824 CVE-2022-49377 bsc#1238545). - Update patches.suse/block-Fix-the-maximum-minor-value-is-blk_alloc_ext_m.patch (bsc#1198021 CVE-2022-49147 bsc#1237960). - Update patches.suse/block-don-t-delete-queue-kobject-before-its-children.patch (bsc#1198019 CVE-2022-49259 bsc#1238413). - Update patches.suse/block-fix-rq-qos-breakage-from-skipping-rq_qos_done_.patch (bsc#1202781 CVE-2022-49266 bsc#1238465). - Update patches.suse/bpf-Fix-UAF-due-to-race-between-btf_try_get_module-a.patch (git-fixes CVE-2022-49236 bsc#1238120). - Update patches.suse/bpf-arm64-Clear-prog-jited_len-along-prog-jited.patch (git-fixes CVE-2022-49341 bsc#1238381). - Update patches.suse/brcmfmac-pcie-Release-firmwares-in-the-brcmf_pcie_se.patch (git-fixes CVE-2022-49263 bsc#1238267). - Update patches.suse/bus-fsl-mc-bus-fix-KASAN-use-after-free-in-fsl_mc_bu.patch (git-fixes CVE-2022-49711 bsc#1238416). - Update patches.suse/can-gs_usb-gs_usb_open-close-fix-memory-leak.patch (git-fixes CVE-2022-49661 bsc#1237788). - Update patches.suse/can-isotp-sanitize-CAN-ID-checks-in-isotp_bind.patch (git-fixes CVE-2022-49269 bsc#1238533). - Update patches.suse/can-m_can-m_can_tx_handler-fix-use-after-free-of-skb.patch (git-fixes CVE-2022-49275 bsc#1238719). - Update patches.suse/can-mcba_usb-properly-check-endpoint-type.patch (git-fixes CVE-2022-49151 bsc#1237778). - Update patches.suse/ceph-fix-inode-reference-leakage-in-ceph_get_snapdir.patch (bsc#1206048 CVE-2022-49109 bsc#1237836). - Update patches.suse/ceph-fix-memory-leak-in-ceph_readdir-when-note_last_dentry-returns-error.patch (bsc#1206049 CVE-2022-49107 bsc#1237973). - Update patches.suse/cgroup-Use-separate-src-dst-nodes-when-preloading-css_sets-for-migration.patch (bsc#1201610 CVE-2022-49647 bsc#1238805). - Update patches.suse/char-xillybus-fix-a-refcount-leak-in-cleanup_dev.patch (git-fixes CVE-2022-49310 bsc#1238642). - Update patches.suse/cifs-fix-handlecache-and-multiuser.patch (bsc#1193629 CVE-2022-49281 bsc#1238635). - Update patches.suse/cifs-fix-potential-double-free-during-failed-mount.patch (bsc#1193629 CVE-2022-49541 bsc#1238727). - Update patches.suse/cifs-potential-buffer-overflow-in-handling-symlinks.patch (bsc#1193629 CVE-2022-49058 bsc#1237814). - Update patches.suse/cifs-prevent-bad-output-lengths-in-smb2_ioctl_query_info-.patch (CVE-2022-0168 bsc#1197472 CVE-2022-49271 bsc#1238626). - Update patches.suse/clk-Fix-clk_hw_get_clk-when-dev-is-NULL.patch (git-fixes CVE-2022-49187 bsc#1238011). - Update patches.suse/clk-qcom-clk-rcg2-Update-logic-to-calculate-D-value-.patch (git-fixes CVE-2022-49189 bsc#1238150). - Update patches.suse/clocksource-hyper-v-unexport-__init-annotated-hv_ini.patch (bsc#1201218 CVE-2022-49726 bsc#1238808). - Update patches.suse/cpufreq-pmac32-cpufreq-Fix-refcount-leak-bug.patch (git-fixes CVE-2022-49621 bsc#1239051). - Update patches.suse/crypto-ccree-Fix-use-after-free-in-cc_cipher_exit.patch (git-fixes CVE-2022-49258 bsc#1237952). - Update patches.suse/crypto-hisilicon-sec-fix-the-aead-software-fallback-.patch (bsc#1198240 CVE-2022-49260 bsc#1238458). - Update patches.suse/crypto-octeontx2-remove-CONFIG_DM_CRYPT-check.patch (git-fixes CVE-2022-49262 bsc#1238463). - Update patches.suse/crypto-qat-add-param-check-for-DH.patch (jsc#PED-1073 CVE-2022-49564 bsc#1238789). - Update patches.suse/crypto-qat-add-param-check-for-RSA.patch (jsc#PED-1073 CVE-2022-49563 bsc#1238787). - Update patches.suse/crypto-qat-fix-memory-leak-in-RSA.patch (git-fixes CVE-2022-49566 bsc#1238266). - Update patches.suse/dlm-fix-plock-invalid-read.patch (git-fixes CVE-2022-49407 bsc#1238180). - Update patches.suse/dm-raid-fix-KASAN-warning-in-raid5_add_disks.patch (git-fixes CVE-2022-49673 bsc#1238933). - Update patches.suse/dmaengine-idxd-Fix-the-error-handling-path-in-idxd_c.patch (git-fixes CVE-2022-49422 bsc#1237784). - Update patches.suse/dmaengine-ti-Fix-refcount-leak-in-ti_dra7_xbar_route.patch (git-fixes CVE-2022-49652 bsc#1238871). - Update patches.suse/dmaengine-zynqmp_dma-In-struct-zynqmp_dma_chan-fix-d.patch (git-fixes CVE-2022-49320 bsc#1238394). - Update patches.suse/dpaa2-ptp-Fix-refcount-leak-in-dpaa2_ptp_probe.patch (git-fixes CVE-2022-49088 bsc#1237724). - Update patches.suse/drbd-Fix-five-use-after-free-bugs-in-get_initial_state (git-fixes CVE-2022-49085 bsc#1238036). - Update patches.suse/driver-base-fix-UAF-when-driver_attach-failed.patch (git-fixes CVE-2022-49385 bsc#1237951). - Update patches.suse/driver-core-Fix-wait_for_device_probe-deferred_probe.patch (git-fixes CVE-2022-49379 bsc#1238446). - Update patches.suse/driver-core-fix-deadlock-in-__device_attach.patch (git-fixes CVE-2022-49371 bsc#1238546). - Update patches.suse/drivers-base-node.c-fix-compaction-sysfs-file-leak.patch (git-fixes CVE-2022-49442 bsc#1238243). - Update patches.suse/drivers-staging-rtl8192bs-Fix-deadlock-in-rtw_joinbs.patch (git-fixes CVE-2022-49311 bsc#1238632). - Update patches.suse/drivers-staging-rtl8192e-Fix-deadlock-in-rtllib_beac.patch (git-fixes CVE-2022-49315 bsc#1238638). - Update patches.suse/drivers-staging-rtl8192u-Fix-deadlock-in-ieee80211_b.patch (git-fixes CVE-2022-49305 bsc#1238645). - Update patches.suse/drivers-staging-rtl8723bs-Fix-deadlock-in-rtw_survey.patch (git-fixes CVE-2022-49309 bsc#1238640). - Update patches.suse/drivers-tty-serial-Fix-deadlock-in-sa1100_set_termio.patch (git-fixes CVE-2022-49304 bsc#1238639). - Update patches.suse/drivers-usb-host-Fix-deadlock-in-oxu_bus_suspend.patch (git-fixes CVE-2022-49313 bsc#1238633). - Update patches.suse/drm-amd-amdgpu-amdgpu_cs-fix-refcount-leak-of-a-dma_.patch (git-fixes CVE-2022-49137 bsc#1238155). - Update patches.suse/drm-amd-display-Check-if-modulo-is-0-before-dividing.patch (git-fixes CVE-2022-49294 bsc#1238147). - Update patches.suse/drm-amd-display-Fix-a-NULL-pointer-dereference-in-am.patch (git-fixes CVE-2022-49232 bsc#1238139). - Update patches.suse/drm-amd-display-Fix-memory-leak.patch (git-fixes CVE-2022-49135 bsc#1238006). - Update patches.suse/drm-amdgpu-cs-make-commands-with-0-chunks-illegal-be.patch (git-fixes CVE-2022-49335 bsc#1238377). - Update patches.suse/drm-amdkfd-Check-for-potential-null-return-of-kmallo.patch (git-fixes CVE-2022-49055 bsc#1237868). - Update patches.suse/drm-bridge-Add-missing-pm_runtime_put_sync.patch (git-fixes CVE-2022-49128 bsc#1237970). - Update patches.suse/drm-bridge-anx7625-Fix-overflow-issue-on-reading-EDI.patch (git-fixes CVE-2022-49222 bsc#1238328). - Update patches.suse/drm-etnaviv-check-for-reaped-mapping-in-etnaviv_iomm.patch (git-fixes CVE-2022-49336 bsc#1238397). - Update patches.suse/drm-i915-fix-a-possible-refcount-leak-in-intel_dp_ad.patch (git-fixes CVE-2022-49644 bsc#1238235). - Update patches.suse/drm-i915-gem-add-missing-boundary-check-in-vm_access.patch (git-fixes bsc#1211263 CVE-2023-28410 CVE-2022-49261 bsc#1238462). - Update patches.suse/drm-i915-reset-Fix-error_state_read-ptr-offset-use.patch (git-fixes CVE-2022-49723 bsc#1237997). - Update patches.suse/drm-imx-Fix-memory-leak-in-imx_pd_connector_get_mode.patch (git-fixes CVE-2022-49091 bsc#1237726). - Update patches.suse/drm-msm-a6xx-Fix-refcount-leak-in-a6xx_gpu_init.patch (git-fixes CVE-2022-49462 bsc#1238123). - Update patches.suse/drm-msm-disp-dpu1-set-vbif-hw-config-to-NULL-to-avoi.patch (git-fixes CVE-2022-49489 bsc#1238244). - Update patches.suse/drm-msm-dp-populate-connector-of-struct-dp_panel.patch (git-fixes CVE-2022-49221 bsc#1238326). - Update patches.suse/drm-msm-fix-possible-memory-leak-in-mdp5_crtc_cursor.patch (git-fixes CVE-2022-49467 bsc#1238815). - Update patches.suse/drm-msm-hdmi-check-return-value-after-calling-platfo.patch (git-fixes CVE-2022-49495 bsc#1237932). - Update patches.suse/drm-msm-mdp4-Fix-refcount-leak-in-mdp4_modeset_init_.patch (git-fixes CVE-2022-49693 bsc#1237954). - Update patches.suse/drm-msm-mdp5-Return-error-code-in-mdp5_mixer_release.patch (git-fixes CVE-2022-49488 bsc#1238600). - Update patches.suse/drm-msm-mdp5-Return-error-code-in-mdp5_pipe_release-.patch (git-fixes CVE-2022-49490 bsc#1238275). - Update patches.suse/drm-panfrost-Fix-shrinker-list-corruption-by-madvise.patch (git-fixes CVE-2022-49645 bsc#1238435). - Update patches.suse/drm-rockchip-vop-fix-possible-null-ptr-deref-in-vop_.patch (git-fixes CVE-2022-49491 bsc#1238539). - Update patches.suse/drm-tegra-Fix-reference-leak-in-tegra_dsi_ganged_pro.patch (git-fixes CVE-2022-49216 bsc#1238338). - Update patches.suse/drm-virtio-fix-NULL-pointer-dereference-in-virtio_gp.patch (git-fixes CVE-2022-49532 bsc#1238925). - Update patches.suse/efi-Do-not-import-certificates-from-UEFI-Secure-Boot.patch (git-fixes CVE-2022-49357 bsc#1238631). - Update patches.suse/exec-Force-single-empty-string-when-argv-is-empty.patch (bsc#1200571 CVE-2022-49264 bsc#1237815). - Update patches.suse/ext4-add-reserved-GDT-blocks-check.patch (bsc#1202712 CVE-2022-49707 bsc#1239035). - Update patches.suse/ext4-avoid-cycles-in-directory-h-tree.patch (bsc#1198577 CVE-2022-1184 CVE-2022-49343 bsc#1238382). - Update patches.suse/ext4-filter-out-EXT4_FC_REPLAY-from-on-disk-superblo.patch (bsc#1202771 CVE-2022-49348 bsc#1238383). - Update patches.suse/ext4-fix-bug_on-ext4_mb_use_inode_pa.patch (bsc#1200810 CVE-2022-49708 bsc#1238599). - Update patches.suse/ext4-fix-bug_on-in-__es_tree_search.patch (bsc#1200809 CVE-2022-49409 bsc#1238279). - Update patches.suse/ext4-fix-bug_on-in-ext4_writepages.patch (bsc#1200872 CVE-2022-49347 bsc#1238393). - Update patches.suse/ext4-fix-ext4_mb_mark_bb-with-flex_bg-with-fast_comm.patch (bsc#1207593 CVE-2022-49174 bsc#1238091). - Update patches.suse/ext4-fix-race-condition-between-ext4_write-and-ext4_.patch (bsc#1200807 CVE-2022-49414 bsc#1238623). - Update patches.suse/ext4-fix-use-after-free-in-ext4_rename_dir_prepare.patch (bsc#1200871 CVE-2022-49349 bsc#1238372). - Update patches.suse/ext4-fix-warning-in-ext4_handle_inode_extension.patch (bsc#1202711 CVE-2022-49352 bsc#1238395). - Update patches.suse/extcon-Modify-extcon-device-to-be-created-after-driv.patch (git-fixes CVE-2022-49308 bsc#1238654). - Update patches.suse/filemap-Handle-sibling-entries-in-filemap_get_read_b.patch (bsc#1202774 CVE-2022-49699 bsc#1238248). - Update patches.suse/firmware-arm_scmi-Fix-list-protocols-enumeration-in-.patch (git-fixes CVE-2022-49451 bsc#1238177). - Update patches.suse/firmware-dmi-sysfs-Fix-memory-leak-in-dmi_sysfs_regi.patch (git-fixes CVE-2022-49370 bsc#1238467). - Update patches.suse/firmware-sysfb-fix-platform-device-leak-in-error-pat.patch (git-fixes CVE-2022-49283 bsc#1238012). - Update patches.suse/ftrace-Clean-up-hash-direct_functions-on-register-failures.patch (git-fixes CVE-2022-49402 bsc#1238255). - Update patches.suse/gpio-gpio-xilinx-Fix-integer-overflow.patch (git-fixes CVE-2022-49570 bsc#1238298). - Update patches.suse/habanalabs-fix-possible-memory-leak-in-MMU-DR-fini.patch (git-fixes CVE-2022-49102 bsc#1238018). - Update patches.suse/hwrng-cavium-fix-NULL-but-dereferenced-coccicheck-er.patch (jsc#SLE-24682 CVE-2022-49177 bsc#1238010). - Update patches.suse/i2c-piix4-Fix-a-memory-leak-in-the-EFCH-MMIO-support.patch (git-fixes CVE-2022-49653 bsc#1238664). - Update patches.suse/i40e-Fix-call-trace-in-setup_tx_descriptors.patch (git-fixes CVE-2022-49725 bsc#1238016). - Update patches.suse/iavf-Fix-handling-of-dummy-receive-descriptors.patch (git-fixes CVE-2022-49583 bsc#1237818). - Update patches.suse/ibmvnic-fix-race-between-xmit-and-reset.patch (bsc#1197302 ltc#197259 CVE-2022-49201 bsc#1238256). - Update patches.suse/ice-Fix-memory-corruption-in-VF-driver.patch (git-fixes CVE-2022-49722 bsc#1238301). - Update patches.suse/ice-arfs-fix-use-after-free-when-freeing-rx_cpu_rmap.patch (git-fixes CVE-2022-49063 bsc#1237846). - Update patches.suse/ice-fix-scheduling-while-atomic-on-aux-critical-err-.patch (git-fixes CVE-2022-49193 bsc#1238283). - Update patches.suse/igb-fix-a-use-after-free-issue-in-igb_clean_tx_ring.patch (git-fixes CVE-2022-49695 bsc#1238556). - Update patches.suse/igc-Reinstate-IGC_REMOVED-logic-and-implement-it-pro.patch (jsc#SLE-18377 CVE-2022-49605 bsc#1238433). - Update patches.suse/igc-avoid-kernel-warning-when-changing-RX-ring-param.patch (git-fixes CVE-2022-49227 bsc#1237786). - Update patches.suse/iio-accel-mma8452-use-the-correct-logic-to-get-mma84.patch (git-fixes CVE-2022-49285 bsc#1238641). - Update patches.suse/iio-adc-adi-axi-adc-Fix-refcount-leak-in-adi_axi_adc.patch (git-fixes CVE-2022-49683 bsc#1238308). - Update patches.suse/iio-trigger-sysfs-fix-use-after-free-on-remove.patch (git-fixes CVE-2022-49685 bsc#1237963). - Update patches.suse/ima-Fix-a-potential-integer-overflow-in-ima_appraise.patch (git-fixes CVE-2022-49643 bsc#1238663). - Update patches.suse/ima-Fix-potential-memory-leak-in-ima_init_crypto.patch (git-fixes CVE-2022-49627 bsc#1237798). - Update patches.suse/iommu-arm-smmu-fix-possible-null-ptr-deref-in-arm_smmu_device_pr (git-fixes CVE-2022-49323 bsc#1238400). - Update patches.suse/iommu-arm-smmu-v3-check-return-value-after-calling-platform_get_ (git-fixes CVE-2022-49319 bsc#1238374). - Update patches.suse/iommu-arm-smmu-v3-sva-Fix-mm-use-after-free (git-fixes CVE-2022-49426 bsc#1238445). - Update patches.suse/iommu-mediatek-Fix-NULL-pointer-dereference-when-printing-dev_na (git-fixes CVE-2022-49424 bsc#1238247). - Update patches.suse/iommu-mediatek-Remove-clk_disable-in-mtk_iommu_remove (git-fixes CVE-2022-49427 bsc#1238246). - Update patches.suse/iommu-omap-Fix-regression-in-probe-for-NULL-pointer-dereference (git-fixes CVE-2022-49083 bsc#1237723). - Update patches.suse/ip-Fix-data-races-around-sysctl_ip_fwd_update_priori.patch (git-fixes CVE-2022-49603 bsc#1238867). - Update patches.suse/ipv4-Fix-data-races-around-sysctl_fib_multipath_hash.patch (git-fixes CVE-2022-49579 bsc#1238014). - Update patches.suse/ipw2x00-Fix-potential-NULL-dereference-in-libipw_xmi.patch (git-fixes CVE-2022-49544 bsc#1238721). - Update patches.suse/irqchip-gic-realview-Fix-refcount-leak-in-realview_g.patch (git-fixes CVE-2022-49719 bsc#1238262). - Update patches.suse/irqchip-gic-v3-Fix-GICR_CTLR.RWP-polling.patch (git-fixes CVE-2022-49074 bsc#1237728). - Update patches.suse/irqchip-gic-v3-Fix-error-handling-in-gic_populate_pp.patch (git-fixes CVE-2022-49716 bsc#1238288). - Update patches.suse/irqchip-gic-v3-Fix-refcount-leak-in-gic_populate_ppi.patch (git-fixes CVE-2022-49715 bsc#1238818). - Update patches.suse/irqchip-realtek-rtl-Fix-refcount-leak-in-map_interru.patch (git-fixes CVE-2022-49714 bsc#1238538). - Update patches.suse/ixgbe-Add-locking-to-prevent-panic-when-setting-srio.patch (git-fixes CVE-2022-49584 bsc#1237933). - Update patches.suse/jffs2-fix-memory-leak-in-jffs2_do_fill_super.patch (git-fixes CVE-2022-49381 bsc#1238112). - Update patches.suse/jffs2-fix-memory-leak-in-jffs2_do_mount_fs.patch (git-fixes CVE-2022-49277 bsc#1238144). - Update patches.suse/jffs2-fix-memory-leak-in-jffs2_scan_medium.patch (git-fixes CVE-2022-49276 bsc#1238142). - Update patches.suse/linux-dim-Fix-divide-by-0-in-RDMA-DIM.patch (git-fixes CVE-2022-49670 bsc#1238809). - Update patches.suse/list-fix-a-data-race-around-ep-rdllist.patch (git-fixes CVE-2022-49443 bsc#1238434). - Update patches.suse/lz4-fix-LZ4_decompress_safe_partial-read-out-of-boun.patch (git-fixes CVE-2022-49078 bsc#1237736). - Update patches.suse/mac80211-fix-potential-double-free-on-mesh-join.patch (git-fixes CVE-2022-49290 bsc#1238156). - Update patches.suse/md-Don-t-set-mddev-private-to-NULL-in-raid0-pers-fre.patch (git-fixes CVE-2022-49400 bsc#1238125). - Update patches.suse/md-bitmap-don-t-set-sb-values-if-can-t-pass-sanity-c.patch (bsc#1197158 CVE-2022-49526 bsc#1238030). - Update patches.suse/md-fix-double-free-of-io_acct_set-bioset.patch (git-fixes CVE-2022-49384 bsc#1237959). - Update patches.suse/media-cx25821-Fix-the-warning-when-removing-the-modu.patch (git-fixes CVE-2022-49525 bsc#1238022). - Update patches.suse/media-i2c-max9286-fix-kernel-oops-when-removing-modu.patch (git-fixes CVE-2022-49509 bsc#1238650). - Update patches.suse/media-imx-jpeg-Prevent-decoding-NV12M-jpegs-into-sin.patch (git-fixes CVE-2022-49165 bsc#1238106). - Update patches.suse/media-imx-jpeg-fix-a-bug-of-accessing-array-out-of-b.patch (git-fixes CVE-2022-49163 bsc#1238105). - Update patches.suse/media-pci-cx23885-Fix-the-error-handling-in-cx23885_.patch (git-fixes CVE-2022-49524 bsc#1238949). - Update patches.suse/media-pvrusb2-fix-array-index-out-of-bounds-in-pvr2_.patch (git-fixes CVE-2022-49478 bsc#1238000). - Update patches.suse/media-rga-fix-possible-memory-leak-in-rga_probe.patch (git-fixes CVE-2022-49502 bsc#1238834). - Update patches.suse/media-stk1160-If-start-stream-fails-return-buffers-w.patch (git-fixes CVE-2022-49247 bsc#1237783). - Update patches.suse/media-ti-vpe-cal-Fix-a-NULL-pointer-dereference-in-c.patch (git-fixes CVE-2022-49254 bsc#1238089). - Update patches.suse/media-usb-go7007-s2250-board-fix-leak-in-probe.patch (git-fixes CVE-2022-49253 bsc#1238420). - Update patches.suse/media-venus-hfi-avoid-null-dereference-in-deinit.patch (git-fixes CVE-2022-49527 bsc#1238013). - Update patches.suse/memory-renesas-rpc-if-fix-platform-device-leak-in-er.patch (git-fixes CVE-2022-49050 bsc#1237892). - Update patches.suse/memory-samsung-exynos5422-dmc-Fix-refcount-leak-in-o.patch (git-fixes CVE-2022-49676 bsc#1237821). - Update patches.suse/mfd-davinci_voicecodec-Fix-possible-null-ptr-deref-d.patch (git-fixes CVE-2022-49435 bsc#1238292). - Update patches.suse/misc-ocxl-fix-possible-double-free-in-ocxl_file_regi.patch (git-fixes CVE-2022-49455 bsc#1238229). - Update patches.suse/mm-slub-add-missing-TID-updates-on-slab-deactivation.patch (git-fixes CVE-2022-49700 bsc#1238249). - Update patches.suse/mmc-jz4740-Apply-DMA-engine-limits-to-maximum-segmen.patch (git-fixes CVE-2022-49522 bsc#1238948). - Update patches.suse/module-fix-e_shstrndx-.sh_size-0-OOB-access.patch (git-fixes CVE-2022-49444 bsc#1238127). - Update patches.suse/msft-hv-2554-Drivers-hv-vmbus-Deactivate-sysctl_record_panic_msg-.patch (bsc#1183682 CVE-2022-49054 bsc#1237931). - Update patches.suse/msft-hv-2555-Drivers-hv-vmbus-Fix-initialization-of-device-object.patch (git-fixes CVE-2022-49099 bsc#1237727). - Update patches.suse/msft-hv-2556-Drivers-hv-vmbus-Fix-potential-crash-on-module-unloa.patch (git-fixes CVE-2022-49098 bsc#1238079). - Update patches.suse/mt76-fix-monitor-mode-crash-with-sdio-driver.patch (git-fixes CVE-2022-49112 bsc#1237971). - Update patches.suse/mt76-fix-use-after-free-by-removing-a-non-RCU-wcid-p.patch (git-fixes CVE-2022-49328 bsc#1238391). - Update patches.suse/mt76-mt7921-fix-crash-when-startup-fails.patch (git-fixes CVE-2022-49129 bsc#1237968). - Update patches.suse/mtd-rawnand-atmel-fix-refcount-issue-in-atmel_nand_c.patch (git-fixes CVE-2022-49212 bsc#1238331). - Update patches.suse/mtd-rawnand-cadence-fix-possible-null-ptr-deref-in-c.patch (git-fixes CVE-2022-49494 bsc#1237955). - Update patches.suse/mtd-rawnand-denali-Use-managed-device-resources.patch (git-fixes CVE-2022-49512 bsc#1237986). - Update patches.suse/mtd-rawnand-intel-fix-possible-null-ptr-deref-in-ebu.patch (git-fixes CVE-2022-49487 bsc#1238115). - Update patches.suse/net-altera-Fix-refcount-leak-in-altera_tse_mdio_crea.patch (git-fixes CVE-2022-49351 bsc#1237939). - Update patches.suse/net-asix-add-proper-error-handling-of-usb-read-error.patch (git-fixes CVE-2022-49226 bsc#1238336). - Update patches.suse/net-bcmgenet-Use-stronger-register-read-writes-to-as.patch (git-fixes CVE-2022-49194 bsc#1238453). - Update patches.suse/net-bonding-fix-use-after-free-after-802.3ad-slave-u.patch (git-fixes CVE-2022-49667 bsc#1238282). - Update patches.suse/net-dsa-lantiq_gswip-Fix-refcount-leak-in-gswip_gphy.patch (git-fixes CVE-2022-49346 bsc#1238392). - Update patches.suse/net-dsa-microchip-ksz_common-Fix-refcount-leak-bug.patch (git-fixes CVE-2022-49591 bsc#1238666). - Update patches.suse/net-dsa-mv88e6xxx-Fix-refcount-leak-in-mv88e6xxx_mdi.patch (git-fixes CVE-2022-49367 bsc#1238447). - Update patches.suse/net-ethernet-bgmac-Fix-refcount-leak-in-bcma_mdio_mi.patch (git-fixes CVE-2022-49342 bsc#1238390). - Update patches.suse/net-ethernet-mtk_eth_soc-out-of-bounds-read-in-mtk_h.patch (git-fixes CVE-2022-49368 bsc#1237808). - Update patches.suse/net-ethernet-stmmac-fix-altr_tse_pcs-function-when-u.patch (git-fixes CVE-2022-49061 bsc#1238024). - Update patches.suse/net-ethernet-ti-am65-cpsw-nuss-Fix-some-refcount-lea.patch (git-fixes CVE-2022-49386 bsc#1237826). - Update patches.suse/net-hns3-add-vlan-list-lock-to-protect-vlan-list.patch (git-fixes CVE-2022-49182 bsc#1238260). - Update patches.suse/net-ipv4-fix-route-with-nexthop-object-delete-warnin.patch (bsc#1204171 CVE-2022-3435 CVE-2022-49092 bsc#1237779). - Update patches.suse/net-ipv6-unexport-__init-annotated-seg6_hmac_init.patch (bsc#1201218 CVE-2022-49339 bsc#1238388). - Update patches.suse/net-mdio-unexport-__init-annotated-mdio_bus_init.patch (bsc#1201218 CVE-2022-49350 bsc#1238387). - Update patches.suse/net-openvswitch-fix-leak-of-nested-actions.patch (git-fixes CVE-2022-49086 bsc#1238037). - Update patches.suse/net-phy-micrel-Allow-probing-without-.driver_data.patch (git-fixes CVE-2022-49472 bsc#1238951). - Update patches.suse/net-sfc-add-missing-xdp-queue-reinitialization.patch (git-fixes CVE-2022-49096 bsc#1238077). - Update patches.suse/net-smc-Fix-NULL-pointer-dereference-in-smc_pnet_find_ib (git-fixes CVE-2022-49060 bsc#1237845). - Update patches.suse/net-stmmac-dwc-qos-Disable-split-header-for-Tegra194.patch (bsc#1194904 CVE-2022-49642 bsc#1238437). - Update patches.suse/net-stmmac-fix-dma-queue-left-shift-overflow-issue.patch (git-fixes CVE-2022-49592 bsc#1238311). - Update patches.suse/net-stmmac-fix-leaks-in-probe.patch (git-fixes CVE-2022-49628 bsc#1238619). - Update patches.suse/net-tun-unlink-NAPI-from-device-on-destruction.patch (git-fixes CVE-2022-49672 bsc#1238816). - Update patches.suse/net-usb-aqc111-Fix-out-of-bounds-accesses-in-RX-fixu.patch (git-fixes CVE-2022-49051 bsc#1237903). - Update patches.suse/net-xfrm-unexport-__init-annotated-xfrm4_protocol_in.patch (bsc#1201218 CVE-2022-49345 bsc#1238238). - Update patches.suse/nfc-nci-add-flush_workqueue-to-prevent-uaf.patch (git-fixes CVE-2022-49059 bsc#1238007). - Update patches.suse/nfc-nfcmrvl-Fix-memory-leak-in-nfcmrvl_play_deferred.patch (git-fixes CVE-2022-49729 bsc#1239060). - Update patches.suse/nfc-st21nfca-fix-memory-leaks-in-EVT_TRANSACTION-han.patch (git-fixes CVE-2022-49331 bsc#1237813). - Update patches.suse/nvme-pci-fix-a-NULL-pointer-dereference-in-nvme_allo.patch (git-fixes CVE-2022-49492 bsc#1238954). - Update patches.suse/ocfs2-dlmfs-fix-error-handling-of-user_dlm_destroy_l.patch (bsc#1202778 CVE-2022-49337 bsc#1238376). - Update patches.suse/ocfs2-fix-crash-when-mount-with-quota-enabled.patch (bsc#1207640 CVE-2022-49274 bsc#1238668). - Update patches.suse/perf-core-Fix-data-race-between-perf_event_set_output-and-perf_mmap_close.patch (git fixes CVE-2022-49607 bsc#1238817). - Update patches.suse/phy-qcom-qmp-fix-reset-controller-leak-on-probe-erro.patch (git-fixes CVE-2022-49396 bsc#1238289). - Update patches.suse/phy-qcom-qmp-fix-struct-clk-leak-on-probe-errors.patch (git-fixes CVE-2022-49397 bsc#1237823). - Update patches.suse/pinctrl-aspeed-Fix-potential-NULL-dereference-in-asp.patch (git-fixes CVE-2022-49618 bsc#1238957). - Update patches.suse/pinctrl-nomadik-Add-missing-of_node_put-in-nmk_pinct.patch (git-fixes CVE-2022-49185 bsc#1238111). - Update patches.suse/pinctrl-renesas-core-Fix-possible-null-ptr-deref-in-.patch (git-fixes CVE-2022-49445 bsc#1238019). - Update patches.suse/pinctrl-renesas-rzn1-Fix-possible-null-ptr-deref-in-.patch (git-fixes CVE-2022-49449 bsc#1238936). - Update patches.suse/platform-x86-thinkpad_acpi-Fix-a-memory-leak-of-EFCH.patch (bsc#1210050 CVE-2022-49665 bsc#1238017). - Update patches.suse/power-reset-arm-versatile-Fix-refcount-leak-in-versa.patch (git-fixes CVE-2022-49609 bsc#1238241). - Update patches.suse/power-supply-ab8500-Fix-memory-leak-in-ab8500_fg_sys.patch (git-fixes CVE-2022-49224 bsc#1237998). - Update patches.suse/powerpc-64s-Don-t-use-DSISR-for-SLB-faults.patch (bsc#1194869 CVE-2022-49214 bsc#1238003). - Update patches.suse/powerpc-iommu-Add-missing-of_node_put-in-iommu_init_.patch (bsc#1194869 CVE-2022-49431 bsc#1238899). - Update patches.suse/powerpc-pseries-Fix-use-after-free-in-remove_phb_dyn.patch (bsc#1065729 bsc#1198660 ltc#197803 CVE-2022-49196 bsc#1238274). - Update patches.suse/powerpc-rtas-Keep-MSR-RI-set-when-calling-RTAS.patch (bsc#1197174 ltc#196362 CVE-2022-49440 bsc#1238945). - Update patches.suse/powerpc-secvar-fix-refcount-leak-in-format_show.patch (bsc#1194869 CVE-2022-49113 bsc#1237967). - Update patches.suse/powerpc-tm-Fix-more-userspace-r13-corruption.patch (bsc#1065729 CVE-2022-49164 bsc#1238108). - Update patches.suse/powerpc-xics-fix-refcount-leak-in-icp_opal_init.patch (bsc#1194869 CVE-2022-49432 bsc#1238950). - Update patches.suse/powerpc-xive-Fix-refcount-leak-in-xive_spapr_init.patch (fate#322438 git-fixes CVE-2022-49437 bsc#1238443). - Update patches.suse/powerpc-xive-spapr-correct-bitmap-allocation-size.patch (fate#322438 git-fixes CVE-2022-49623 bsc#1239040). - Update patches.suse/qede-confirm-skb-is-allocated-before-using.patch (git-fixes CVE-2022-49084 bsc#1237751). - Update patches.suse/raw-Fix-a-data-race-around-sysctl_raw_l3mdev_accept.patch (git-fixes CVE-2022-49631 bsc#1238814). - Update patches.suse/regulator-da9121-Fix-uninit-value-in-da9121_assign_c.patch (git-fixes CVE-2022-49507 bsc#1238811). - Update patches.suse/regulator-pfuze100-Fix-refcount-leak-in-pfuze_parse_.patch (git-fixes CVE-2022-49481 bsc#1238264). - Update patches.suse/regulator-scmi-Fix-refcount-leak-in-scmi_regulator_p.patch (git-fixes CVE-2022-49466 bsc#1238287). - Update patches.suse/remoteproc-Fix-count-check-in-rproc_coredump_write.patch (git-fixes CVE-2022-49278 bsc#1238253). - Update patches.suse/remoteproc-qcom_q6v5_mss-Fix-some-leaks-in-q6v5_allo.patch (git-fixes CVE-2022-49188 bsc#1238138). - Update patches.suse/rtc-mt6397-check-return-value-after-calling-platform.patch (git-fixes CVE-2022-49375 bsc#1238228). - Update patches.suse/rtc-pl031-fix-rtc-features-null-pointer-dereference.patch (git-fixes CVE-2022-49273 bsc#1238140). - Update patches.suse/rtl818x-Prevent-using-not-initialized-queues.patch (git-fixes CVE-2022-49326 bsc#1238646). - Update patches.suse/scsi-hisi_sas-Free-irq-vectors-in-order-for-v3-HW.patch (git-fixes CVE-2022-49118 bsc#1237979). - Update patches.suse/scsi-ibmvfc-Allocate-free-queue-resource-only-during.patch (jsc#SLE-15442 bsc#1180814 ltc#187461 git-fixes CVE-2022-49701 bsc#1237810). - Update patches.suse/scsi-ibmvfc-Store-vhost-pointer-during-subcrq-alloca.patch (jsc#SLE-15442 bsc#1180814 ltc#187461 git-fixes CVE-2022-49703 bsc#1238131). - Update patches.suse/scsi-libfc-Fix-use-after-free-in-fc_exch_abts_resp.patch (git-fixes CVE-2022-49114 bsc#1238146). - Update patches.suse/scsi-lpfc-Address-NULL-pointer-dereference-after-sta.patch (bsc#1201193 CVE-2022-49332 bsc#1238236). - Update patches.suse/scsi-lpfc-Fix-SCSI-I-O-completion-and-abort-handler-.patch (bsc#1200045 CVE-2022-49536 bsc#1238838). - Update patches.suse/scsi-lpfc-Fix-call-trace-observed-during-I-O-with-CM.patch (bsc#1200045 CVE-2022-49537 bsc#1238930). - Update patches.suse/scsi-lpfc-Fix-null-pointer-dereference-after-failing.patch (bsc#1200045 CVE-2022-49535 bsc#1238937). - Update patches.suse/scsi-lpfc-Fix-resource-leak-in-lpfc_sli4_send_seq_to.patch (bsc#1200045 CVE-2022-49521 bsc#1238938). - Update patches.suse/scsi-lpfc-Inhibit-aborts-if-external-loopback-plug-i.patch (bsc#1200045 CVE-2022-49504 bsc#1238835). - Update patches.suse/scsi-lpfc-Move-cfg_log_verbose-check-before-calling-.patch (bsc#1200045 CVE-2022-49542 bsc#1238722). - Update patches.suse/scsi-lpfc-Protect-memory-leak-for-NPIV-ports-sending.patch (bsc#1200045 CVE-2022-49534 bsc#1238893). - Update patches.suse/scsi-lpfc-Resolve-NULL-ptr-dereference-after-an-ELS-.patch (bsc#1201193 CVE-2022-49730 bsc#1239070). - Update patches.suse/scsi-mpi3mr-Fix-memory-leaks.patch (git-fixes CVE-2022-49126 bsc#1237929). - Update patches.suse/scsi-mpt3sas-Fix-use-after-free-in-_scsih_expander_node_remove (git-fixes CVE-2022-49082 bsc#1237740). - Update patches.suse/scsi-pm8001-Fix-abort-all-task-initialization.patch (git-fixes CVE-2022-49217 bsc#1238313). - Update patches.suse/scsi-pm8001-Fix-memory-leak-in-pm8001_chip_fw_flash_update_req.patch (git-fixes CVE-2022-49119 bsc#1237925). - Update patches.suse/scsi-pm8001-Fix-tag-leaks-on-error.patch (git-fixes CVE-2022-49121 bsc#1237926). - Update patches.suse/scsi-pm8001-Fix-task-leak-in-pm8001_send_abort_all.patch (git-fixes CVE-2022-49120 bsc#1237969). - Update patches.suse/scsi-qla2xxx-Fix-crash-during-module-load-unload-tes.patch (bsc#1197661 CVE-2022-49160 bsc#1238172). - Update patches.suse/scsi-qla2xxx-Fix-premature-hw-access-after-PCI-error.patch (bsc#1195823 CVE-2022-49157 bsc#1238169). - Update patches.suse/scsi-qla2xxx-Fix-scheduling-while-atomic.patch (bsc#1195823 CVE-2022-49156 bsc#1238168). - Update patches.suse/scsi-qla2xxx-Fix-warning-message-due-to-adisc-being-.patch (bsc#1195823 CVE-2022-49158 bsc#1238170). - Update patches.suse/scsi-qla2xxx-Implement-ref-count-for-SRB.patch (bsc#1195823 CVE-2022-49159 bsc#1238171). - Update patches.suse/scsi-qla2xxx-Suppress-a-kernel-complaint-in-qla_crea.patch (bsc#1195823 CVE-2022-49155 bsc#1237941). - Update patches.suse/scsi-sd-Fix-potential-NULL-pointer-dereference.patch (git-fixes CVE-2022-49376 bsc#1238103). - Update patches.suse/scsi-zorro7xx-Fix-a-resource-leak-in-zorro7xx_remove_one (git-fixes CVE-2022-49095 bsc#1237752). - Update patches.suse/serial-8250-Fix-PM-usage_count-for-console-handover.patch (git-fixes CVE-2022-49613 bsc#1238440). - Update patches.suse/serial-8250_aspeed_vuart-Fix-potential-NULL-derefere.patch (git-fixes CVE-2022-49392 bsc#1238113). - Update patches.suse/sfc-fix-considering-that-all-channels-have-TX-queues.patch (git-fixes CVE-2022-49378 bsc#1238286). - Update patches.suse/sfc-fix-kernel-panic-when-creating-VF.patch (git-fixes CVE-2022-49625 bsc#1238411). - Update patches.suse/sfc-fix-use-after-free-when-disabling-sriov.patch (git-fixes CVE-2022-49626 bsc#1238270). - Update patches.suse/skbuff-fix-coalescing-for-page_pool-fragment-recycli.patch (bsc#1190336 CVE-2022-49093 bsc#1237737). - Update patches.suse/soc-bcm-Check-for-NULL-return-of-devm_kzalloc.patch (git-fixes CVE-2022-49448 bsc#1238536). - Update patches.suse/soc-bcm-brcmstb-pm-pm-arm-Fix-refcount-leak-in-brcms.patch (git-fixes CVE-2022-49678 bsc#1238821). - Update patches.suse/soc-rockchip-Fix-refcount-leak-in-rockchip_grf_init.patch (git-fixes CVE-2022-49382 bsc#1238306). - Update patches.suse/soc-ti-ti_sci_pm_domains-Check-for-null-return-of-de.patch (git-fixes CVE-2022-49453 bsc#1239004). - Update patches.suse/spi-bcm2835-bcm2835_spi_handle_err-fix-NULL-pointer-.patch (git-fixes CVE-2022-49569 bsc#1238605). - Update patches.suse/spi-spi-fsl-qspi-check-return-value-after-calling-pl.patch (git-fixes CVE-2022-49475 bsc#1238617). - Update patches.suse/staging-rtl8712-fix-a-potential-memory-leak-in-r871x.patch (git-fixes CVE-2022-49312 bsc#1238157). - Update patches.suse/staging-rtl8712-fix-uninit-value-in-r871xu_drv_init.patch (git-fixes CVE-2022-49298 bsc#1238718). - Update patches.suse/staging-rtl8712-fix-uninit-value-in-usb_read8-and-fr.patch (git-fixes CVE-2022-49301 bsc#1238643). - Update patches.suse/staging-vchiq_arm-Avoid-NULL-ptr-deref-in-vchiq_dump.patch (git-fixes CVE-2022-49106 bsc#1237965). - Update patches.suse/staging-vchiq_core-handle-NULL-result-of-find_servic.patch (git-fixes CVE-2022-49104 bsc#1237999). - Update patches.suse/staging-wfx-fix-an-error-handling-in-wfx_init_common.patch (git-fixes CVE-2022-49105 bsc#1237975). - Update patches.suse/sysctl-Fix-data-races-in-proc_dou8vec_minmax.patch (git-fixes CVE-2022-49634 bsc#1237937). - Update patches.suse/sysctl-Fix-data-races-in-proc_douintvec.patch (git-fixes CVE-2022-49641 bsc#1237831). - Update patches.suse/sysctl-Fix-data-races-in-proc_douintvec_minmax.patch (git-fixes CVE-2022-49640 bsc#1237782). - Update patches.suse/thermal-core-Fix-memory-leak-in-__thermal_cooling_de.patch (git-fixes CVE-2022-49468 bsc#1238047). - Update patches.suse/thermal-drivers-broadcom-Fix-potential-NULL-derefere.patch (git-fixes CVE-2022-49459 bsc#1238046). - Update patches.suse/thermal-drivers-imx_sc_thermal-Fix-refcount-leak-in-.patch (git-fixes CVE-2022-49463 bsc#1238428). - Update patches.suse/tick-nohz-unexport-__init-annotated-tick_nohz_full_s.patch (bsc#1201218 CVE-2022-49675 bsc#1238431). - Update patches.suse/tpm-fix-reference-counting-for-struct-tpm_chip.patch (CVE-2022-2977 bsc#1202672 CVE-2022-49287 bsc#1238276). - Update patches.suse/tpm-use-try_get_ops-in-tpm-space.c.patch (git-fixes CVE-2022-49286 bsc#1238647). - Update patches.suse/tracing-Fix-potential-double-free-in-create_var_ref.patch (git-fixes CVE-2022-49410 bsc#1238441). - Update patches.suse/tracing-Fix-sleeping-function-called-from-invalid-context-on-RT-kernel.patch (git-fixes CVE-2022-49322 bsc#1238396). - Update patches.suse/tracing-histograms-Fix-memory-leak-problem.patch (git-fixes CVE-2022-49648 bsc#1238278). - Update patches.suse/tty-Fix-a-possible-resource-leak-in-icom_probe.patch (git-fixes CVE-2022-49314 bsc#1238158). - Update patches.suse/tty-fix-deadlock-caused-by-calling-printk-under-tty_.patch (git-fixes CVE-2022-49441 bsc#1238263). - Update patches.suse/tty-goldfish-Fix-free_irq-on-remove.patch (git-fixes CVE-2022-49724 bsc#1238869). - Update patches.suse/tty-goldfish-Use-tty_port_destroy-to-destroy-port.patch (git-fixes CVE-2022-49399 bsc#1237829). - Update patches.suse/tty-synclink_gt-Fix-null-pointer-dereference-in-slgt.patch (git-fixes CVE-2022-49307 bsc#1238149). - Update patches.suse/tunnels-do-not-assume-mac-header-is-set-in-skb_tunne.patch (git-fixes CVE-2022-49663 bsc#1238442). - Update patches.suse/usb-dwc2-Fix-memory-leak-in-dwc2_hcd_init.patch (git-fixes CVE-2022-49713 bsc#1238419). - Update patches.suse/usb-dwc2-gadget-don-t-reset-gadget-s-driver-bus.patch (git-fixes CVE-2022-49299 bsc#1238184). - Update patches.suse/usb-dwc3-gadget-Replace-list_for_each_entry_safe-if-.patch (git-fixes CVE-2022-49398 bsc#1238621). - Update patches.suse/usb-gadget-lpc32xx_udc-Fix-refcount-leak-in-lpc32xx_.patch (git-fixes CVE-2022-49712 bsc#1238239). - Update patches.suse/usb-isp1760-Fix-out-of-bounds-array-access.patch (git-fixes CVE-2022-49551 bsc#1237795). - Update patches.suse/usb-usbip-fix-a-refcount-leak-in-stub_probe.patch (git-fixes CVE-2022-49389 bsc#1238257). - Update patches.suse/usbnet-Run-unregister_netdev-before-unbind-again.patch (git-fixes CVE-2022-49501 bsc#1238830). - Update patches.suse/usbnet-fix-memory-leak-in-error-case.patch (git-fixes CVE-2022-49657 bsc#1238269). - Update patches.suse/veth-Ensure-eth-header-is-in-skb-s-linear-part.patch (git-fixes CVE-2022-49066 bsc#1237722). - Update patches.suse/video-fbdev-clcdfb-Fix-refcount-leak-in-clcdfb_of_vr.patch (git-fixes CVE-2022-49421 bsc#1238819). - Update patches.suse/video-fbdev-sm712fb-Fix-crash-in-smtcfb_write.patch (git-fixes CVE-2022-49162 bsc#1238096). - Update patches.suse/virtio_console-eliminate-anonymous-module_init-modul.patch (git-fixes CVE-2022-49100 bsc#1237735). - Update patches.suse/virtio_net-fix-xdp_rxq_info-bug-after-suspend-resume.patch (git-fixes CVE-2022-49687 bsc#1238181). - Update patches.suse/watch_queue-Actually-free-the-watch.patch (CVE-2022-0995 bsc#1197246 CVE-2022-49256 bsc#1238277). - Update patches.suse/watch_queue-Fix-NULL-dereference-in-error-cleanup.patch (CVE-2022-0995 bsc#1197246 CVE-2022-49257 bsc#1237987). - Update patches.suse/watch_queue-Free-the-page-array-when-watch_queue-is-.patch (git-fixes CVE-2022-49148 bsc#1237797). - Update patches.suse/watchdog-ts4800_wdt-Fix-refcount-leak-in-ts4800_wdt_.patch (git-fixes CVE-2022-49373 bsc#1238175). - Update patches.suse/wifi-mac80211-fix-queue-selection-for-mesh-OCB-inter.patch (git-fixes CVE-2022-49646 bsc#1239001). - Update patches.suse/wifi-mac80211-fix-use-after-free-in-chanctx-code.patch (git-fixes CVE-2022-49416 bsc#1238293). - Update patches.suse/wireguard-socket-free-skb-in-send6-when-ipv6-is-disa.patch (git-fixes CVE-2022-49153 bsc#1238166). - Update patches.suse/x86-MCE-AMD-Fix-memory-leak-when-threshold_create_ba.patch (git-fixes CVE-2022-49549 bsc#1238602). - Update patches.suse/x86-kexec-fix-memory-leak-of-elf-header-buffer.patch (bsc#1196444 CVE-2022-49546 bsc#1238750). - Update patches.suse/x86-speculation-Fill-RSB-on-vmexit-for-IBRS.patch (bsc#1199657 CVE-2022-29900 CVE-2022-29901 CVE-2022-49611 bsc#1238618). - Update patches.suse/xen-netback-avoid-entering-xenvif_rx_next_skb-with-a.patch (bsc#1201381 CVE-2022-49649 bsc#1238612). - Update patches.suse/xprtrdma-treat-all-calls-not-a-bcall-when-bc_serv-is.patch (git-fixes CVE-2022-49321 bsc#1238373). - commit a27d758 - Update patches.suse/0011-Revert-Revert-block-bfq-honor-already-setup-queue-merges.patch (git-fixes CVE-2021-47646 bsc#1237774). - Update patches.suse/ARM-davinci-da850-evm-Avoid-NULL-pointer-dereference.patch (git-fixes CVE-2021-47631 bsc#1237718). - Update patches.suse/ASoC-soc-compress-prevent-the-potentially-use-of-nul.patch (git-fixes CVE-2021-47650 bsc#1237742). - Update patches.suse/KVM-x86-mmu-Zap-_all_-roots-when-unmapping-gfn-range.patch (git-fixes CVE-2021-47639 bsc#1237824). - Update patches.suse/ath5k-fix-OOB-in-ath5k_eeprom_read_pcal_info_5111.patch (git-fixes CVE-2021-47633 bsc#1237768). - Update patches.suse/clk-qcom-ipq8074-fix-PCI-E-clock-oops.patch (git-fixes CVE-2021-47647 bsc#1237775). - Update patches.suse/drm-amd-pm-fix-a-potential-gpu_metrics_table-memory-.patch (git-fixes CVE-2021-4453 bsc#1237753). - Update patches.suse/drm-plane-Move-range-check-for-format_count-earlier.patch (git-fixes CVE-2021-47659 bsc#1237839). - Update patches.suse/drm-virtio-Ensure-that-objs-is-not-NULL-in-virtio_gp.patch (git-fixes CVE-2021-47657 bsc#1237837). - Update patches.suse/gpu-host1x-Fix-a-memory-leak-in-host1x_remove.patch (git-fixes CVE-2021-47648 bsc#1237725). - Update patches.suse/jffs2-fix-use-after-free-in-jffs2_clear_xattr_subsystem.patch (git-fixes CVE-2021-47656 bsc#1237827). - Update patches.suse/media-davinci-vpif-fix-use-after-free-on-driver-unbi.patch (git-fixes CVE-2021-47653 bsc#1237748). - Update patches.suse/media-ir_toy-free-before-error-exiting.patch (git-fixes CVE-2021-47643 bsc#1237743). - Update patches.suse/media-staging-media-zoran-calculate-the-right-buffer.patch (git-fixes CVE-2021-47645 bsc#1237767). - Update patches.suse/media-staging-media-zoran-move-videodev-alloc.patch (git-fixes CVE-2021-47644 bsc#1237766). - Update patches.suse/powerpc-set_memory-Avoid-spinlock-recursion-in-chang.patch (bsc#1194869 CVE-2021-47632 bsc#1237755). - Update patches.suse/samples-landlock-Fix-path_list-memory-leak.patch (git-fixes CVE-2021-47654 bsc#1237807). - Update patches.suse/soc-qcom-rpmpd-Check-for-null-return-of-devm_kcalloc.patch (git-fixes CVE-2021-47651 bsc#1237872). - Update patches.suse/ubifs-Fix-deadlock-in-concurrent-rename-whiteout-and-inode-writeback.patch (git-fixes CVE-2021-47637 bsc#1237761). - Update patches.suse/ubifs-Fix-read-out-of-bounds-in-ubifs_wbuf_write_nolock.patch (git-fixes CVE-2021-47636 bsc#1237904). - Update patches.suse/ubifs-Fix-to-add-refcount-once-page-is-set-private.patch (git-fixes CVE-2021-47635 bsc#1237759). - Update patches.suse/ubifs-rename_whiteout-Fix-double-free-for-whiteout_ui-data.patch (git-fixes CVE-2021-47638 bsc#1237763). - Update patches.suse/udmabuf-validate-ubuf-pagecount.patch (git-fixes CVE-2021-47649 bsc#1237745). - Update patches.suse/video-fbdev-cirrusfb-check-pixclock-to-avoid-divide-.patch (git-fixes CVE-2021-47641 bsc#1237734). - Update patches.suse/video-fbdev-nvidiafb-Use-strscpy-to-prevent-buffer-o.patch (git-fixes CVE-2021-47642 bsc#1237916). - Update patches.suse/video-fbdev-smscufx-Fix-null-ptr-deref-in-ufx_usb_pr.patch (git-fixes CVE-2021-47652 bsc#1237721). - commit e92be69 - net: rose: fix timer races against user threads (CVE-2025-21718 bsc#1239073). - commit 0089650 - net_sched: sch_sfq: don't allow 1 packet limit (CVE-2024-57996 bsc#1239076). - commit 1575e37 - wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy() (CVE-2024-58014 bsc#1239109) - commit a0ab5c3 - initcall_blacklist: Does not allow kernel_lockdown be blacklisted (bsc#1237521). - commit 248ffca - x86/bugs: Fix BHI retpoline check (git-fixes). - commit 083fa08 - Sort BHI mitigation patches - Refresh patches.suse/KVM-x86-Add-BHI_NO.patch. - Refresh patches.suse/x86-bhi-Add-BHI-mitigation-knob.patch. - Refresh patches.suse/x86-bhi-Add-support-for-clearing-branch-history-at-syscall.patch. - Refresh patches.suse/x86-bhi-Define-SPEC_CTRL_BHI_DIS_S.patch. - Refresh patches.suse/x86-bhi-Enumerate-Branch-History-Injection-BHI-bug.patch. - Refresh patches.suse/x86-bhi-Mitigate-KVM-by-default.patch. - commit 2ed304e - KVM: x86: Advertise CPUID.(EAX=7,ECX=2):EDX[5:0] to userspace (bsc#1217339 CVE-2024-2201). - commit 3e06375 - mm/mempolicy: fix mpol_new leak in shared_policy_replace (CVE-2022-49080 bsc#1238033). - commit ee261e8 - KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN (CVE-2024-53135 bsc#1234154). - commit c33dbae - net: wwan: fix global oob in wwan_rtnl_policy (CVE-2024-50128 bsc#1232905). - commit b1050a1 - ipv4/tcp: do not use per netns ctl sockets (bsc#1237693). - commit f950ad1 - x86/xen: add FRAME_END to xen_hypercall_hvm() (git-fixes). - commit e70ee83 - x86/xen: fix xen_hypercall_hvm() to not clobber %rbx (git-fixes). - commit 2ad21f6 - idpf: call set_real_num_queues in idpf_open (bsc#1236661 bsc#1237316). - commit 67a5892 - gfs2: Truncate address space when flipping GFS2_DIF_JDATA flag (bsc#1237139 CVE-2025-21699). - commit 94ceb50 - scsi: storvsc: Ratelimit warning logs to prevent VM denial of service (bsc#1237025 CVE-2025-21690). - scsi: storvsc: Use scsi_cmd_to_rq() instead of scsi_cmnd.request (git-fixes). - commit f3c7eea - Update patches.suse/cifs-Fix-UAF-in-cifs_demultiplex_thread-.patch (bsc#1208995 CVE-2023-1192 CVE-2023-52572 bsc#1220946). Move to the sorted section. - commit bb08640 - net: sched: fix ets qdisc OOB Indexing (bsc#1237028 CVE-2025-21692). - commit 947f160 - net: mana: Cleanup &quot;mana&quot; debugfs dir after cleanup of all children (bsc#1236760). - net: mana: Enable debugfs files for MANA device (bsc#1236758). - net: mana: Add get_link and get_link_ksettings in ethtool (bsc#1236761). - net: netvsc: Update default VMBus channels (bsc#1236757). - commit dd59602 - Update patches.suse/ALSA-6fire-Release-resources-at-card-release.patch (CVE-2024-53239 bsc#1235054 bsc#1234853). - Update patches.suse/Bluetooth-L2CAP-do-not-leave-dangling-sk-pointer-on-.patch (CVE-2024-56605 bsc#1235061 bsc#1234853). - Update patches.suse/KVM-nSVM-Ignore-nCR3-4-0-when-loading-PDPTEs-from-me.patch (CVE-2024-50115 bsc#1232919 bsc#1225742). - Update patches.suse/NFSv4.0-Fix-a-use-after-free-problem-in-the-asynchronous-open.patch (CVE-2024-53173 bsc#1234891 bsc#1234853). - Update patches.suse/hfsplus-don-t-query-the-device-logical-block-size-multiple-times.patch (bsc#1235073 CVE-2024-56548 bsc#1234853). - Update patches.suse/wifi-mwifiex-Fix-memcpy-field-spanning-write-warning-in-mwifiex_config_scan.patch (CVE-2024-56539 bsc#1234963 bsc#1234853). - commit c3c2bf8 - mac802154: check local interfaces before deleting sdata list (CVE-2024-57948 bsc#1236677). - commit 4de21f7 - media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format (CVE-2024-53104 bsc#1234025). - commit a0c98f3 - Fix sorting error ``` Error: Current series.conf is not sorted. Please run series_sort.py first and commit the result before adding new patches. ``` - commit a81b3e9 - kABI fix for net: defer final 'struct net' free in netns dismantle (CVE-2024-56658 bsc#1235441). Upstream commit 0f6ede9fbc74 (&quot;net: defer final 'struct net' free in netns dismantle&quot;) introduced a new struct element `defer_free_list` into `struct net`. In order to preserve the kABI, move the newly added element into a hole. ``` struct netns_nexthop nexthop; /* 560 72 */ /* XXX 8 bytes hole, try to pack */ /* --- cacheline 10 boundary (640 bytes) --- */ struct netns_ipv4 ipv4 __attribute__((__aligned__(64))); /* 640 704 */ ``` - commit 3fc1183 - net: defer final 'struct net' free in netns dismantle (CVE-2024-56658 bsc#1235441). - commit 8694248 - NFS: Trigger the &quot;ls -l&quot; readdir heuristic sooner (bsc#1231847). - commit eadd17e - NFS: Improve heuristic for readdirplus (bsc#1231847). - commit ea10ca2 - NFS: Adjust the amount of readahead performed by NFS readdir (bsc#1231847). - commit ec8e677 - NFS: Do not flush the readdir cache in nfs_dentry_iput() (bsc#1231847). - commit ac72a63 - smb: prevent use-after-free due to open_cached_dir error paths (CVE-2024-53177 bsc#1234896). - commit 43156cd - net: inet6: do not leave a dangling sk pointer in inet6_create() (CVE-2024-56600 bsc#1235217). - commit 4f3d37a - blacklist.conf: Not affected byy CVE-2024-44932 and CVE-2024-44964 - Delete patches.suse/idpf-fix-UAFs-when-destroying-the-queues.patch. - Delete patches.suse/idpf-fix-memory-leaks-and-crashes-while-performing-a.patch. This fixes bsc#1236628 - commit 6ceedf0 - netfilter: x_tables: fix LED ID check in led_tg_check() (CVE-2024-56650 bsc#1235430). - commit a130a9c - drm/amdkfd: Correct the migration DMA map direction (bsc#1235969 CVE-2024-57897) - commit e14ed1e - Refresh patches.suse/drm-dp_mst-Ensure-mst_primary-pointer-is-valid-in-dr.patch. Fix warning by removing unused label out_put_primary - commit 354b3cb - Update patches.suse/tipc-fix-NULL-deref-in-cleanup_bearer.patch (bsc#1235433 CVE-2024-56661 bsc#1234931). - commit cb91989 - 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 ea9bf7d - net: inet: do not leave a dangling sk pointer in inet_create() (CVE-2024-56601 bsc#1235230). - commit b4769c0 - btrfs: fix use-after-free when COWing tree bock and tracing is enabled (bsc#1235645 CVE-2024-56759). - commit e811c1c - powerpc/pseries/iommu: IOMMU incorrectly marks MMIO range in DDW (bsc#1218470 ltc#204531). - commit f5ab5f5 - scsi: qla2xxx: Fix use after free on unload (CVE-2024-56623 bsc#1235466). - block, bfq: fix bfqq uaf in bfq_limit_depth() (CVE-2024-53166 bsc#1234884). - commit 894e940 - Refresh patches.suse/x86-xen-don-t-do-PV-iret-hypercall-through-hypercall.patch. - commit df281af - x86/static-call: Remove early_boot_irqs_disabled check to fix Xen PVH dom0 (git-fixes). - commit 2c0880a - ALSA: seq: oss: Fix races at processing SysEx messages (CVE-2024-57893 bsc#1235920). - commit f05049d - drm/dp_mst: Ensure mst_primary pointer is valid in drm_dp_mst_handle_up_req() (CVE-2024-57798 bsc#1235818). - commit bfdad42 - drm/dp_mst: Ensure mst_primary pointer is valid in drm_dp_mst_handle_up_req() (CVE-2024-57798 bsc#1235818). - commit 15490f2 - net/smc: check return value of sock_recvmsg when draining clc data (CVE-2024-57791 bsc#1235759). - commit b879d55 - power: supply: gpio-charger: Fix set charge current limits (git-fixes CVE-2024-57792 bsc#1235764). - commit 80ed527 - bpf, sockmap: Fix race between element replace and close() (CVE-2024-56664 bsc#1235249). - commit 03e2626 - s390/cpum_sf: Handle CPU hotplug remove during sampling (CVE-2024-57849 bsc#1235814). - commit e03f9af - Update patches.suse/smb-client-fix-TCP-timers-deadlock-after-rmmod.patch (CVE-2024-53095 bsc#1233642 CVE-2024-54680 bsc#1235723). - commit 6deb1aa - mm/swapfile: skip HugeTLB pages for unuse_vma (CVE-2024-50199 bsc#1233112). - commit 63ec06b - tipc: fix NULL deref in cleanup_bearer() (bsc#1235433). - commit a0043a3 - scsi: sg: Fix slab-use-after-free read in sg_release() (CVE-2024-56631 bsc#1235480). - commit 9399f03 - 9p/xen: fix release of IRQ (CVE-2024-56704 bsc#1235584). - commit 614e74c - net: ieee802154: do not leave a dangling sk pointer in ieee802154_create() (CVE-2024-56602 bsc#1235521). - commit 4049cc5 - net: hsr: avoid potential out-of-bound access in fill_frame_info() (CVE-2024-56648 bsc#1235451). - commit 0a88cb0 - ovl: Filter invalid inodes with missing lookup function (bsc#1235035 CVE-2024-56570). - commit 54169ab - NFSv4.0: Fix a use-after-free problem in the asynchronous open() (CVE-2024-53173 bsc#1234891). - commit f801b5b - tipc: Fix use-after-free of kernel socket in cleanup_bearer() (CVE-2024-56642 bsc#1235433). - commit ec9cc8d - can: j1939: j1939_session_new(): fix skb reference counting (CVE-2024-56645 bsc#1235134). - commit 5011af1 - Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create() (CVE-2024-56605 bsc#1235061). - commit c461209 - idpf: trigger SW interrupt when exiting wb_on_itr mode (bsc#1235507). - idpf: add support for SW triggered interrupts (bsc#1235507). - net: mana: Increase the DEF_RX_BUFFERS_PER_QUEUE to 1024 (bsc#1235246). - idpf: enable WB_ON_ITR (bsc#1235507). - commit 3cbddc0 - smb: client: fix use-after-free of signing key (CVE-2024-53179 bsc#1234921). - commit 86400c7 - smb: client: fix TCP timers deadlock after rmmod (git-fixes) [hcarvalho: this fixes issue discussed in bsc#1233642]. - commit 3e3e1af - smb: client: Fix use-after-free of network namespace (CVE-2024-53095 bsc#1233642). [hcarvalho: remove netfs_tracker_* related code because we don't have such infrastructure.] - commit 97b2d9e - wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan() (CVE-2024-56539 bsc#1234963). - commit e27d4b2 - vfio/pci: Properly hide first-in-list PCIe extended capability (bsc#1235004 CVE-2024-53214). - commit f520125 - Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc() (bsc#1235056 CVE-2024-56604). - commit cf32d9d - 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 4de890e - nilfs2: fix potential out-of-bounds memory access in nilfs_find_entry() (bsc#1235224 CVE-2024-56619). - commit b3f788e - jfs: array-index-out-of-bounds fix in dtReadFirst (bsc#1235220 CVE-2024-56598). - commit 4762f9a - hfsplus: don't query the device logical block size multiple times (bsc#1235073 CVE-2024-56548). - commit 67473c2 - wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service() (CVE-2024-53156 bsc#1234846). - commit 747e664 - ALSA: 6fire: Release resources at card release (CVE-2024-53239 bsc#1235054). - commit 6995b0a - NFSD: Prevent a potential integer overflow (CVE-2024-53146 bsc#1234853). - commit 79b751c - Update patches.suse/tcp-Fix-use-after-free-of-nreq-in-reqsk_timer_handler.patch (CVE-2024-50154 bsc#1233070 CVE-2024-53206 bsc#1234960). - commit cdf9cb8 - Update patches.suse/media-s5p_cec-limit-msg.len-to-CEC_MAX_MSG_SIZE.patch (git-fixes CVE-2022-49035 bsc#1215304). - commit d91bb81 - x86/xen: use new hypercall functions instead of hypercall page (XSA-466 CVE-2024-53241 bsc#1234282). - commit 439afbb - x86/xen: add central hypercall functions (XSA-466 CVE-2024-53241 bsc#1234282). - commit 1784c5e - x86/xen: don't do PV iret hypercall through hypercall page (XSA-466 CVE-2024-53241 bsc#1234282). - commit 9f17f93 - x86/static-call: provide a way to do very early static-call updates (XSA-466 CVE-2024-53241 bsc#1234282). - Refresh patches.kabi/tracepoint-fix.patch. - commit 2e422a6 - objtool/x86: allow syscall instruction (XSA-466 CVE-2024-53241 bsc#1234282). - commit 1f61d5b - x86: make get_cpu_vendor() accessible from Xen code (XSA-466 CVE-2024-53241 bsc#1234282). - commit 4d90703 - xen/netfront: fix crash when removing device (XSA-465 CVE-2024-53240 bsc#1234281). - commit f11b367 - Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE (git-fixes, bsc#1230697, CVE-2024-8805). - commit cddc976 - Update patches.suse/initramfs-avoid-filename-buffer-overrun.patch (CVE-2024-53142 bsc#1232436). - commit 14f79ec - scsi: storvsc: Do not flag MAINTENANCE_IN return of SRB_STATUS_DATA_OVERRUN as an error (git-fixes). - commit fe5d084 - idpf: fix UAFs when destroying the queues (CVE-2024-44932 bsc#1229808). - idpf: fix memory leaks and crashes while performing a soft reset (CVE-2024-44964 bsc#1230220). - commit 4316b61 - USB: serial: io_edgeport: fix use after free in debug printk (CVE-2024-50267 bsc#1233456) - commit 5a7c927 - tcp: Fix use-after-free of nreq in reqsk_timer_handler() (CVE-2024-50154 bsc#1233070). - commit 9c54dc2 - README.BRANCH: Remove bouncing e-mail address. - commit 9d57d70 - netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() (CVE-2024-50259 bsc#1233214). - commit 3b589d0 - Update patches.suse/can-bcm-Fix-UAF-in-bcm_proc_show.patch (git-fixes CVE-2023-52922 bsc#1233977). - commit 624f722 - security/keys: fix slab-out-of-bounds in key_task_permission (CVE-2024-50301 bsc#1233490). - commit b8c1415 - media: cx24116: prevent overflows on SNR calculus (CVE-2024-50290 bsc#1233479). - commit c59cd01 - dm cache: fix out-of-bounds access to the dirty bitset when resizing (CVE-2024-50279 bsc#1233468). - commit 6c88f14 - Update config files. Enabled IDPF for ARM64 (bsc#1221309) - commit 8dd2b1c - HID: core: zero-initialize the report buffer (CVE-2024-50302 bsc#1233491). - commit 086ff16 - vsock/virtio: Initialization of the dangling pointer occurring in vsk-&gt;trans (CVE-2024-50264 bsc#1233453). - commit 008fbbf - Bluetooth: SCO: Fix UAF on sco_sock_timeout (CVE-2024-50125 bsc#1232928). - commit f9d799e - Update patches.suse/0002-x86-mm-ident_map-Use-gbpages-only-where-full-GB-page.patch (bsc#1220382 CVE-2024-50017 bsc#1232312). - commit 02ff322 - Update patches.suse/can-bcm-Fix-UAF-in-bcm_proc_show.patch (git-fixes CVE-2023-52922 bsc#1233977). - commit 82c5a0a - Refresh patches.suse/initramfs-avoid-filename-buffer-overrun.patch. - commit 145c949 - idpf: avoid vport access in idpf_get_link_ksettings (CVE-2024-50274 bsc#1233463). - commit 8971b65 - nilfs2: fix potential oob read in nilfs_btree_check_delete() (bsc#1232187 CVE-2024-47757). - commit d813a1d - media: dvbdev: prevent the risk of out of memory access (CVE-2024-53063 bsc#1233557). - commit 52a90e5 - media: s5p-jpeg: prevent buffer overflows (CVE-2024-53061 bsc#1233555). - commit aef5475 - firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier() (CVE-2024-53068 bsc#1233561). - commit e507b37 - x86/kvm: fix is_stale_page_fault() (bsc#1236675). (cherry picked from commit 332e96833f1a2a081df46c4419786e0131c9b5af) - commit 17eb2c1 - kernel-binary: Enable livepatch package only when livepatch is enabled Otherwise the filelist may be empty failing the build (bsc#1218644). - commit f730eec - Update config files (bsc#1218644). LIVEPATCH_IPA_CLONES=n =&gt; LIVEPATCH=n - commit 9c28790 - ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size() (CVE-2024-50205 bsc#1233293). - commit d31c5c9 - tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink() (CVE-2024-50154 bsc#1233070). - commit 2430e1b - unicode: Don't special case ignorable code points (CVE-2024-50089 bsc#1232860). - commit ba47e72 - mm/memory: add non-anonymous page check in the copy_present_page() (bsc#1231646). - commit 9f5cb06 - README.BRANCH: drop explicit maintainers kbuild already recognizes all downstream branch maintainers an merge their PRs so we do not need explicit maintainers for the cve branch itself. - commit cd6f8fb - KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory (CVE-2024-50115 bsc#1232919). - commit 4c6b1da - mptcp: fix double-free on socket dismantle (CVE-2024-26782 bsc#1222590). (cherry picked from commit 03ac3f085c702ef308481c09b021887b5a01d52b) - commit 7f40404 - net/ncsi: Disable the ncsi work before freeing the associated structure (CVE-2024-49945 bsc#1232165). - commit 0369bdb - net: sched: fix use-after-free in taprio_change() (CVE-2024-50127 bsc#1232907). - commit 88b0d06 - RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages (bsc#1233117 CVE-2024-50208) - commit da4098a - block: initialize integrity buffer to zero before writing it to media (CVE-2024-43854 bsc#1229345). - commit 2fc5adb - x86/mm/ident_map: Use gbpages only where full GB page should be mapped (bsc#1220382). - x86/kexec: Add EFI config table identity mapping for kexec kernel (bsc#1220382). - commit c11660d - initramfs: avoid filename buffer overrun (bsc#1232436). - commit 6855778 - fbdev: efifb: Register sysfs groups through driver core (bsc#1232224 CVE-2024-49925). - commit ed25954 - net: hisilicon: Fix potential use-after-free in hix5hd2_rx() (bsc#1231979 CVE-2022-48960) - commit e22014e - ipv6: avoid use-after-free in ip6_fragment() (CVE-2022-48956 bsc#1231893). - commit c192a62 - drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer (CVE-2024-49991 bsc#1232282). - commit 6ba5342 - vhost_vdpa: assign irq bypass producer token correctly (bsc#1232174 CVE-2024-47748). - commit 51b6257 - ext4: fix timer use-after-free on failed mount (CVE-2024-49960 bsc#1232395). - tipc: guard against string buffer overrun (CVE-2024-49995 bsc#1232432). - commit 7dec126 - net/xen-netback: prevent UAF in xenvif_flush_hash() (CVE-2024-49936 bsc#1232424). - commit 05a71d8 - Update patches.suse/IB-core-Implement-a-limit-on-UMAD-receive-List.patch (bsc#1228743 CVE-2024-42145 bsc#1223384). - Update patches.suse/aoe-fix-the-potential-use-after-free-problem-in-more.patch (bsc#1218562 CVE-2023-6270 CVE-2024-49982 bsc#1232097). - Update patches.suse/fuse-Initialize-beyond-EOF-page-contents-before-setti.patch (bsc#1229454 CVE-2024-44947 bsc#1229456). - Update patches.suse/media-edia-dvbdev-fix-a-use-after-free.patch (CVE-2024-27043 bsc#1223824 bsc#1218562). - commit 1967352 - Update patches.suse/i3c-mipi-i3c-hci-Fix-out-of-bounds-access-in-hci_dma.patch (git-fixes CVE-2023-52766 bsc#1230620). - Update patches.suse/nfc-nci-fix-possible-NULL-pointer-dereference-in-sen.patch (git-fixes CVE-2023-52919 bsc#1231988). - Update patches.suse/tcp-do-not-accept-ACK-of-bytes-we-never-sent.patch (CVE-2023-52881 bsc#1225611 bsc#1223384). - Update patches.suse/wifi-ath11k-fix-htt-pktlog-locking.patch (git-fixes CVE-2023-52800 bsc#1230600). - commit 4af6b80 - Update patches.suse/0001-af_unix-Get-user_ns-from-in_skb-in-unix_diag_get_exa.patch (bsc#1209290 CVE-2023-28327 CVE-2022-48970 bsc#1231887). - Update patches.suse/ALSA-seq-Fix-function-prototype-mismatch-in-snd_seq_.patch (git-fixes CVE-2022-48994 bsc#1232119). - Update patches.suse/ASoC-ops-Check-bounds-for-second-channel-in-snd_soc_.patch (git-fixes CVE-2022-48951 bsc#1231929). - Update patches.suse/ASoC-ops-Fix-bounds-check-for-_sx-controls.patch (git-fixes CVE-2022-49005 bsc#1232150). - Update patches.suse/ASoC-soc-pcm-Add-NULL-check-in-BE-reparenting.patch (git-fixes CVE-2022-48992 bsc#1232071). - Update patches.suse/Bluetooth-Fix-not-cleanup-led-when-bt_init-fails.patch (git-fixes CVE-2022-48971 bsc#1232037). - Update patches.suse/Bluetooth-L2CAP-Fix-u8-overflow.patch (CVE-2022-45934 bsc#1205796 CVE-2022-48947 bsc#1231895). - Update patches.suse/HID-core-fix-shift-out-of-bounds-in-hid_report_raw_e.patch (git-fixes CVE-2022-48978 bsc#1232038). - Update patches.suse/Input-raydium_ts_i2c-fix-memory-leak-in-raydium_i2c_.patch (git-fixes CVE-2022-48995 bsc#1232120). - Update patches.suse/NFC-nci-Bounds-check-struct-nfc_target-arrays.patch (git-fixes CVE-2022-48967 bsc#1232304). - Update patches.suse/afs-Fix-server-active-leak-in-afs_put_server.patch (git-fixes CVE-2022-49012 bsc#1232005). - Update patches.suse/btrfs-fix-hang-during-unmount-when-stopping-a-space-.patch (bsc#1232262 CVE-2024-49867 CVE-2022-48664 bsc#1223524). - Update patches.suse/can-af_can-fix-NULL-pointer-dereference-in-can_rcv_f.patch (bsc#1210627 CVE-2023-2166 CVE-2022-48977 bsc#1231883). - Update patches.suse/can-m_can-pci-add-missing-m_can_class_free_dev-in-pr.patch (git-fixes CVE-2022-49024 bsc#1232001). - Update patches.suse/char-tpm-Protect-tpm_pm_suspend-with-locks.patch (git-fixes CVE-2022-48997 bsc#1232035). - Update patches.suse/drm-shmem-helper-Remove-errant-put-in-error-path.patch (git-fixes CVE-2022-48981 bsc#1232229). - Update patches.suse/e100-Fix-possible-use-after-free-in-e100_xmit_prepar.patch (git-fixes CVE-2022-49026 bsc#1231997). - Update patches.suse/gpio-amd8111-Fix-PCI-device-reference-count-leak.patch (git-fixes CVE-2022-48973 bsc#1232039). - Update patches.suse/gpiolib-fix-memory-leak-in-gpiochip_setup_dev.patch (git-fixes CVE-2022-48975 bsc#1231885). - Update patches.suse/hwmon-coretemp-Check-for-null-before-removing-sysfs-.patch (git-fixes CVE-2022-49010 bsc#1232172). - Update patches.suse/hwmon-coretemp-fix-pci-device-refcount-leak-in-nv1a_.patch (git-fixes CVE-2022-49011 bsc#1232006). - Update patches.suse/hwmon-ibmpex-Fix-possible-UAF-when-ibmpex_register_b.patch (git-fixes CVE-2022-49029 bsc#1231995). - Update patches.suse/iavf-Fix-error-handling-in-iavf_init_module.patch (jsc#SLE-18385 CVE-2022-49027 bsc#1232007). - Update patches.suse/igb-Initialize-mailbox-message-for-VF-reset.patch (jsc#SLE-18379 CVE-2022-48949 bsc#1231897). - Update patches.suse/iio-health-afe4403-Fix-oob-read-in-afe4403_read_raw.patch (git-fixes CVE-2022-49031 bsc#1231992). - Update patches.suse/iio-health-afe4404-Fix-oob-read-in-afe4404_-read-wri.patch (git-fixes CVE-2022-49032 bsc#1231991). - Update patches.suse/iommu-vt-d-Fix-PCI-device-refcount-leak-in-dmar_dev_scope_init (git-fixes CVE-2022-49002 bsc#1232133). - Update patches.suse/iommu-vt-d-Fix-PCI-device-refcount-leak-in-has_external_pci (git-fixes CVE-2022-49000 bsc#1232123). - Update patches.suse/ipv4-Handle-attempt-to-delete-multipath-route-when-f.patch (bsc#1204171 CVE-2022-3435 CVE-2022-48999 bsc#1231936). - Update patches.suse/ixgbevf-Fix-resource-leak-in-ixgbevf_init_module.patch (git-fixes CVE-2022-49028 bsc#1231996). - Update patches.suse/mac802154-fix-missing-INIT_LIST_HEAD-in-ieee802154_i.patch (git-fixes CVE-2022-48972 bsc#1232025). - Update patches.suse/media-v4l2-dv-timings.c-fix-too-strict-blanking-sani.patch (git-fixes CVE-2022-48987 bsc#1232067). - Update patches.suse/msft-hv-2684-net-mana-Fix-race-on-per-CQ-variable-napi-work_done.patch (git-fixes bsc#1206188 CVE-2022-48985 bsc#1231958). - Update patches.suse/net-ethernet-nixge-fix-NULL-dereference.patch (git-fixes CVE-2022-49019 bsc#1231940). - Update patches.suse/net-mdio-fix-unbalanced-fwnode-reference-count-in-md.patch (git-fixes CVE-2022-48961 bsc#1232108). - Update patches.suse/net-mdiobus-fix-unbalanced-node-reference-count.patch (git-fixes CVE-2022-49016 bsc#1231937). - Update patches.suse/net-mlx5e-Fix-use-after-free-when-reverting-terminat.patch (jsc#SLE-19253 CVE-2022-49025 bsc#1231960). - Update patches.suse/net-phy-fix-null-ptr-deref-while-probe-failed.patch (git-fixes CVE-2022-49021 bsc#1231939). - Update patches.suse/net-thunderbolt-fix-memory-leak-in-tbnet_open.patch (git-fixes CVE-2022-48955 bsc#1231892). - Update patches.suse/net-tun-Fix-use-after-free-in-tun_detach.patch (git-fixes CVE-2022-49014 bsc#1231890). - Update patches.suse/nilfs2-fix-NULL-pointer-dereference-in-nilfs_palloc_.patch (git-fixes CVE-2022-49007 bsc#1232170). - Update patches.suse/nvme-fix-SRCU-protection-of-nvme_ns_head-list.patch (git-fixes CVE-2022-49003 bsc#1232136). - Update patches.suse/octeontx2-pf-Fix-potential-memory-leak-in-otx2_init_.patch (jsc#SLE-24682 CVE-2022-48968 bsc#1232237). - Update patches.suse/rtc-cmos-Fix-event-handler-registration-ordering-iss.patch (git-fixes CVE-2022-48953 bsc#1231941). - Update patches.suse/s390-qeth-fix-use-after-free-in-hsci.patch (bsc#1210449 git-fixes CVE-2022-48954 bsc#1231972). - Update patches.suse/tracing-Free-buffers-when-a-used-dynamic-event-is-removed.patch (git-fixes CVE-2022-49006 bsc#1232163). - Update patches.suse/udf-Fix-preallocation-discarding-at-indirect-extent-.patch (bsc#1213034 CVE-2022-48946 bsc#1231888). - Update patches.suse/usb-gadget-uvc-Prevent-buffer-overflow-in-setup-hand.patch (git-fixes CVE-2022-48948 bsc#1231896). - Update patches.suse/wifi-cfg80211-fix-buffer-overflow-in-elem-comparison.patch (git-fixes CVE-2022-49023 bsc#1231961). - Update patches.suse/wifi-mac8021-fix-possible-oob-access-in-ieee80211_ge.patch (git-fixes CVE-2022-49022 bsc#1231962). - Update patches.suse/xen-netfront-Fix-NULL-sring-after-live-migration.patch (git-fixes CVE-2022-48969 bsc#1232026). - commit 2377658 - Update patches.suse/drm-vc4-kms-Add-missing-drm_crtc_commit_put.patch (git-fixes CVE-2021-47534 bsc#1230903). - Update patches.suse/phy-mdio-fix-memory-leak.patch (git-fixes stable-5.14.12 CVE-2021-47416 bsc#1225336 bsc#1225189). - commit d4160e3 - NFSD: Force all NFSv4.2 COPY requests to be synchronous (CVE-2024-49974 bsc#1232383). - commit e488dd4 - ACPI: sysfs: validate return type of _STR method (bsc#1231861 CVE-2024-49860). - commit 1bb3615 - Delete patches.suse/scsi-Update-max_hw_sectors-on-rescan.patch (bsc#1216223) - commit c6f8315 - Refresh patches.suse/scsi-ibmvfc-Add-max_sectors-module-parameter.patch. - commit 707c768 - drm/amd/display: Fix index out of bounds in DCN30 color transformation (CVE-2024-49969 bsc#1232519). - commit a2392a3 - smb: client: fix UAF in async decryption (bsc#1232418 CVE-2024-50047). - commit dcba7ec - net: hisilicon: Fix potential use-after-free in hisi_femac_rx() (CVE-2022-48962 bsc#1232286). - commit 0f23f49 - btrfs: wait for fixup workers before stopping cleaner kthread during umount (bsc#1232262 CVE-2024-49867). - btrfs: fix hang during unmount when stopping a space reclaim worker (bsc#1232262 CVE-2024-49867). - commit b603fa4 - mm/khugepaged: fix collapse_pte_mapped_thp() to allow anon_vma (CVE-2022-48991 bsc#1232070 prerequisity git-fix). - mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths (CVE-2022-48991 bsc#1232070). - commit 3ab8533 - mm/khugepaged: fix GUP-fast interaction by sending IPI (CVE-2022-48991 bsc#1232070 prerequisity). - commit 327d525 - mm/khugepaged: take the right locks for page table retraction (CVE-2022-48991 bsc#1232070 prerequisity). - commit e43adf4 - mm: gup: fix the fast GUP race against THP collapse (CVE-2022-48991 bsc#1232070 prerequisity). - commit 262192e - s390/dasd: fix error recovery leading to data corruption on ESE devices (git-fixes bsc#1229452 CVE-2024-45026 bsc#1230454 bsc#1232281). - commit fc1d054 - net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition (CVE-2024-47747 bsc#1232145). - commit a1020b1 - drm/amd/display: Check msg_id before processing transcation (CVE-2024-46814 bsc#1231193). - commit 81681a2 - RDMA/mana_ib: use the correct page size for mapping user-mode doorbell page (bsc#1232036). - net: mana: Fix the extra HZ in mana_hwc_send_request (bsc#1232033). - commit 8c14fb0 - block, bfq: fix possible UAF for bfqq-&gt;bic with merge chain (CVE-2024-47706 bsc#1231942) - commit c5d0bc0 - tcp: check skb is non-NULL in tcp_rto_delta_us() (CVE-2024-47684 bsc#1231987) - commit 569d856 - net: hsr: Fix potential use-after-free (CVE-2022-49015 bsc#1231938) - commit 5883d13 - wifi: ath11k: fix array out-of-bound access in SoC stats (CVE-2024-49930 bsc#1232260). - commit e11de4c - Update patches.suse/memcg-Fix-possible-use-after-free-in-memcg_write_event_control.patch (bsc#1206344, CVE-2022-48988, bsc#1232069). - commit e7eaea8 - net: dsa: sja1105: fix memory leak in sja1105_setup_devlink_regions() (CVE-2022-48959 bsc#1231976). - commit ec81f5f - mm: avoid leaving partial pfn mappings around in error case (CVE-2024-47674 bsc#1231673). - commit 9910e8f - netem: fix return value if duplicate enqueue fails (CVE-2024-45016 bsc#1230429). - commit 2e9108a - lib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc() (CVE-2024-47668 bsc#1231502) - commit 45aa8b3 - dn_route: set rt neigh to blackhole_netdev instead of loopback_dev in ifdown (bsc#1216813). - commit 673d32f - xfrm: set dst dev to blackhole_netdev instead of loopback_dev in ifdown (bsc#1216813). - commit 0e5b278 - ipv6: blackhole_netdev needs snmp6 counters (bsc#1216813). - commit 0c7762c - ipv6: give an IPv6 dev to blackhole_netdev (bsc#1216813). - commit 5d1a23a - aoe: fix the potential use-after-free problem in more places (bsc#1218562 CVE-2023-6270). - commit e949a45 - efi: fix NULL-deref in init error path (bsc#1229556 CVE-2022-48879). - commit 41e1770 - dmaengine: altera-msgdma: properly free descriptor in msgdma_free_descriptor (bsc#1230715 CVE-2024-46716). - commit 92074a5 - bpf: Fix pointer-leak due to insufficient speculative store bypass mitigation (bsc#1231375). - commit fd93435 - drm/amd/display: Check gpio_id before used as array index (CVE-2024-46818 bsc#1231203). - commit 53caf4b - drm/amd/display: Check num_valid_sets before accessing reader_wm_sets (CVE-2024-46815 bsc#1231195). - commit ad18f86 - drm/amd/display: Stop amdgpu_dm initialize when link nums greater than max_links (CVE-2024-46816 bsc#1231197). - commit 1eea356 - Delete some more obsolete scripts - commit 0d4cf12 - drm/amd/display: Check link_index before accessing dc-&gt;links (CVE-2024-46813 bsc#1231191). - commit a97e1a4 - drm/amd/display: Stop amdgpu_dm initialize when stream nums greater than 6 (CVE-2024-46817 bsc#1231200). - commit 18cf241 - rpm/release-projects: Add SLFO projects (bsc#1231293). - commit 9f2c584 - NFSv3: only use NFS timeout for MOUNT when protocols are compatible (bsc#1231016). - commit 2b5943c - ASoC: meson: axg-card: fix 'use-after-free' (CVE-2024-46849 bsc#1231073) - commit a395e2d - rpm/check-for-config-changes: add HAVE_RUST and RUSTC_SUPPORTS_ to IGNORED_CONFIGS_RE They depend on SHADOW_CALL_STACK. - commit 65fa52b - usb: dwc3: st: fix probed platform device ref count on probe error path (bsc#1230507 CVE-2024-46674). - commit ffd5693 - scsi: ibmvfc: Add max_sectors module parameter (bsc#1216223). Delete patches.suse/ibmvfc-make-max_sectors-a-module-option.patch. - commit 13d3e25 - nvme: move stopping keep-alive into nvme_uninit_ctrl() (CVE-2024-45013 bsc#1230442) - commit 75bf6d9 - Update patches.suse/media-vivid-fix-compose-size-exceed-boundary.patch (git-fixes CVE-2022-48945 bsc#1230398). - Update patches.suse/powerpc-rtas-Prevent-Spectre-v1-gadget-construction-.patch (bsc#1227487 CVE-2024-46774 bsc#1230767). - Update patches.suse/sched-Fix-yet-more-sched_fork-races.patch (git fixes (sched/core) CVE-2022-48944 bsc#1229947). - commit be5b46d - SUNRPC: avoid soft lockup when transmitting UDP to reachable server (bsc#1225272 bsc#1231016). - commit d8ddf61 - kabi: add __nf_queue_get_refs() for kabi compliance. - netfilter: nf_queue: fix possible use-after-free (bsc#1229633, CVE-2022-48911). - commit 09526c9 - btrfs: prevent copying too big compressed lzo segment (CVE-2022-48923 bsc#1229662) - commit 9c5b30e - dev/parport: fix the array out-of-bounds risk (CVE-2024-42301 bsc#1229407). - commit 0515c56 - KABI: kcm: Serialise kcm_sendmsg() for the same socket (CVE-2024-44946 bsc#1230015). - commit 4220de4 - kcm: Serialise kcm_sendmsg() for the same socket (CVE-2024-44946 bsc#1230015). - commit 195f676 - Refresh patches.suse/Bluetooth-hci_ldisc-check-HCI_UART_PROTO_READY-flag-.patch. Update upstream status and move to the sorted section. - commit 43dbf50 - memcg_write_event_control(): fix a user-triggerable oops (CVE-2024-45021 bsc#1230434). - commit f5c92ca - Revert &quot;mm/sparsemem: fix race in accessing memory_section-&gt;usage&quot; This reverts commit 606bd9b8228bfe004cf6ab930ffb673a535e3c55. - commit 532bbfe - Revert &quot;mm, kmsan: fix infinite recursion due to RCU critical section&quot; This reverts commit 1702784a5db6b26695f0bc2c6b0cbe973db5c0f3. - commit e220e83 - Revert &quot;mm: prevent derefencing NULL ptr in pfn_section_valid()&quot; This reverts commit d77caa16c18115f0c470ecf5cdd3cdb6f9865aeb. - commit b38d226 - blk-mq: add helper for checking if one CPU is mapped to specified hctx (bsc#1223600). - blk-mq: don't schedule block kworker on isolated CPUs (bsc#1223600). - commit 4537dc0 - vfs: Don't evict inode under the inode lru traversing context (CVE-2024-45003 bsc#1230245). - commit 82e6e44 - Bluetooth: L2CAP: Fix deadlock (git-fixes). - commit 9438e54 - bluetooth/l2cap: sync sock recv cb and release (bsc#1228576 CVE-2024-41062). - commit 5b1f743 - Update references - commit a096907 - fuse: Initialize beyond-EOF page contents before setting uptodate (bsc#1229454 CVE-2024-44947). - commit ddfd2d7 - usb: vhci-hcd: Do not drop references before new references are gained (CVE-2024-43883 bsc#1229707). - commit 44d7bae - net: usb: qmi_wwan: fix memory leak for not ip packets (CVE-2024-43861 bsc#1229500). - commit 3e796c3 - PKCS#7: Check codeSigning EKU of certificates in PKCS#7 (bsc#1226666). - commit 95da232 - Update patches.suse/ASoC-ops-Shift-tested-values-in-snd_soc_put_volsw-by.patch (git-fixes CVE-2022-48917 bsc#1229637). - Update patches.suse/Bluetooth-hci_qca-Fix-driver-shutdown-on-closed-serd.patch (git-fixes CVE-2022-48878 bsc#1229554). - Update patches.suse/CDC-NCM-avoid-overflow-in-sanity-checking.patch (git-fixes CVE-2022-48938 bsc#1229664). - Update patches.suse/KVM-x86-mmu-make-apf-token-non-zero-to-fix-bug.patch (git-fixes CVE-2022-48943 bsc#1229645). - Update patches.suse/RDMA-cma-Do-not-change-route.addr.src_addr-outside-s.patch (git-fixes CVE-2022-48925 bsc#1229630). - Update patches.suse/RDMA-ib_srp-Fix-a-deadlock.patch (git-fixes CVE-2022-48930 bsc#1229624). - Update patches.suse/USB-gadgetfs-Fix-race-between-mounting-and-unmountin.patch (CVE-2022-4382 bsc#1206258 CVE-2022-48869 bsc#1229507). - Update patches.suse/auxdisplay-lcd2s-Fix-memory-leak-in-remove.patch (git-fixes CVE-2022-48907 bsc#1229608). - Update patches.suse/blktrace-fix-use-after-free-for-struct-blk_trace.patch (bsc#1198017 CVE-2022-48913 bsc#1229643). - Update patches.suse/bpf-Fix-crash-due-to-out-of-bounds-access-into-reg2b.patch (git-fixes bsc#1194111 bsc#1194765 bsc#1196261 CVE-2021-4204 CVE-2022-0500 CVE-2022-23222 CVE-2022-48929 bsc#1229625). - Update patches.suse/btrfs-fix-race-between-quota-rescan-and-disable-lead.patch (bsc#1207158 CVE-2023-52896 bsc#1229533). - Update patches.suse/btrfs-fix-relocation-crash-due-to-premature-return-f.patch (bsc#1203360 CVE-2022-48903 bsc#1229613). - Update patches.suse/cgroup-cpuset-Prevent-UAF-in-proc_cpuset_show.patch (bsc#1228801 CVE-2024-43853 bsc#1229292). - Update patches.suse/cifs-fix-double-free-race-when-mount-fails-in-cifs_get_root-.patch (bsc#1193629 CVE-2022-48919 bsc#1229657). - Update patches.suse/configfs-fix-a-race-in-configfs_-un-register_subsyst.patch (git-fixes CVE-2022-48931 bsc#1229623). - Update patches.suse/dmaengine-idxd-Let-probe-fail-when-workqueue-cannot-.patch (git-fixes CVE-2022-48868 bsc#1229506). - Update patches.suse/drm-msm-another-fix-for-the-headless-Adreno-GPU.patch (git-fixes CVE-2023-52911 bsc#1229522). - Update patches.suse/drm-msm-dp-do-not-complete-dp_aux_cmd_fifo_tx-if-irq.patch (git-fixes CVE-2022-48898 bsc#1229537). - Update patches.suse/drm-virtio-Fix-GEM-handle-creation-UAF.patch (git-fixes CVE-2022-48899 bsc#1229536). - Update patches.suse/gsmi-fix-null-deref-in-gsmi_get_variable.patch (git-fixes CVE-2023-52893 bsc#1229535). - Update patches.suse/hwmon-Handle-failure-to-register-sensor-with-thermal.patch (git-fixes CVE-2022-48942 bsc#1229612). - Update patches.suse/ibmvnic-free-reset-work-item-when-flushing.patch (bsc#1196516 ltc#196391 CVE-2022-48905 bsc#1229604). - Update patches.suse/ice-fix-concurrent-reset-and-removal-of-VFs.patch (git-fixes CVE-2022-48941 bsc#1229614). - Update patches.suse/iio-adc-men_z188_adc-Fix-a-resource-leak-in-an-error.patch (git-fixes CVE-2022-48928 bsc#1229626). - Update patches.suse/iio-adc-tsc2046-fix-memory-corruption-by-preventing-.patch (git-fixes CVE-2022-48927 bsc#1229628). - Update patches.suse/io_uring-add-a-schedule-point-in-io_add_buffers.patch (git-fixes CVE-2022-48937 bsc#1229617). - Update patches.suse/iommu-amd-Fix-I-O-page-table-memory-leak (git-fixes CVE-2022-48904 bsc#1229603). - Update patches.suse/iommu-vt-d-fix-double-list_add-when-enabling-vmd-in-scalable-mode (bsc#1196894 CVE-2022-48916 bsc#1229638). - Update patches.suse/iwlwifi-mvm-check-debugfs_dir-ptr-before-use.patch (git-fixes CVE-2022-48918 bsc#1229636). - Update patches.suse/ixgbe-fix-pci-device-refcount-leak.patch (jsc#SLE-18384 CVE-2022-48896 bsc#1229540). - Update patches.suse/misc-fastrpc-Don-t-remove-map-on-creater_process-and.patch (git-fixes CVE-2022-48873 bsc#1229512). - Update patches.suse/misc-fastrpc-Fix-use-after-free-race-condition-for-m.patch (git-fixes CVE-2022-48872 bsc#1229510). - Update patches.suse/net-mlx5-DR-Fix-slab-out-of-bounds-in-mlx5_cmd_dr_cr.patch (jsc#SLE-19253 CVE-2022-48932 bsc#1229622). - Update patches.suse/net-smc-fix-connection-leak (git-fixes CVE-2022-48909 bsc#1229611). - Update patches.suse/nfc-pn533-Wait-for-out_urb-s-completion-in-pn533_usb.patch (git-fixes CVE-2023-52907 bsc#1229526). - Update patches.suse/nfp-flower-Fix-a-potential-leak-in-nfp_tunnel_add_sh.patch (git-fixes CVE-2022-48934 bsc#1229620). - Update patches.suse/nilfs2-fix-general-protection-fault-in-nilfs_btree_i.patch (git-fixes CVE-2023-52900 bsc#1229581). - Update patches.suse/octeontx2-pf-Fix-resource-leakage-in-VF-driver-unbin.patch (git-fixes CVE-2023-52905 bsc#1229528). - Update patches.suse/platform-surface-aggregator-Add-missing-call-to-ssam.patch (git-fixes CVE-2022-48880 bsc#1229557). - Update patches.suse/regulator-da9211-Use-irq-handler-when-ready.patch (git-fixes CVE-2022-48891 bsc#1229565). - Update patches.suse/sched-fair-Fix-fault-in-reweight_entity.patch (git fixes (sched/core) CVE-2022-48921 bsc#1229635). - Update patches.suse/scsi-storvsc-Fix-swiotlb-bounce-buffer-leak-in-confi.patch (bsc#1206006 CVE-2022-48890 bsc#1229544). - Update patches.suse/spi-spi-zynq-qspi-Fix-a-NULL-pointer-dereference-in-.patch (git-fixes CVE-2021-4441 bsc#1229598). - Update patches.suse/thermal-core-Fix-TZ_GET_TRIP-NULL-pointer-dereferenc.patch (git-fixes CVE-2022-48915 bsc#1229639). - Update patches.suse/thermal-int340x-fix-memory-leak-in-int3400_notify.patch (git-fixes CVE-2022-48924 bsc#1229631). - Update patches.suse/tty-fix-possible-null-ptr-defer-in-spk_ttyio_release.patch (git-fixes CVE-2022-48870 bsc#1229508). - Update patches.suse/tty-serial-qcom-geni-serial-fix-slab-out-of-bounds-o.patch (git-fixes CVE-2022-48871 bsc#1229509). - Update patches.suse/usb-gadget-f_ncm-fix-potential-NULL-ptr-deref-in-ncm.patch (git-fixes CVE-2023-52894 bsc#1229566). - Update patches.suse/usb-gadget-rndis-add-spinlock-for-rndis-response-lis.patch (git-fixes CVE-2022-48926 bsc#1229629). - Update patches.suse/usb-xhci-Check-endpoint-is-valid-before-dereferencin.patch (git-fixes CVE-2023-52901 bsc#1229531). - Update patches.suse/wifi-mac80211-sdata-can-be-NULL-during-AMPDU-start.patch (git-fixes CVE-2022-48875 bsc#1229516). - Update patches.suse/xen-netfront-destroy-queues-before-real_num_tx_queue.patch (git-fixes CVE-2022-48914 bsc#1229642). - Update patches.suse/xhci-Fix-null-pointer-dereference-when-host-dies.patch (git-fixes CVE-2023-52898 bsc#1229568). - commit 5c5e4d7 - mm: prevent derefencing NULL ptr in pfn_section_valid() (git-fixes). - commit d77caa1 - mm, kmsan: fix infinite recursion due to RCU critical section (git-fixes). - commit 1702784 - mm/sparsemem: fix race in accessing memory_section-&gt;usage (bsc#1221326 CVE-2023-52489). - commit 606bd9b - jfs: Fix shift-out-of-bounds in dbDiscardAG (bsc#1229792 CVE-2024-44938). - commit 8003b7e - ata: libata-core: Fix double free on error (CVE-2024-41087,bsc#1228466). - commit b5892ca - ata: libata-core: Fix double free on error (CVE-2024-41087,bsc#1228466). - commit 0a4b370 - exec: Fix ToCToU between perm check and set-uid/gid usage (CVE-2024-43882 bsc#1229503). - commit 83a7456 - netfilter: nf_tables: unregister flowtable hooks on netns exit (CVE-2022-48935 bsc#1229619) - commit 3e33f70 - netfilter: fix use-after-free in __nf_register_net_hook() (CVE-2022-48912 bsc#1229641) - commit f8f42c3 - rpm/check-for-config-changes: Exclude ARCH_USING_PATCHABLE_FUNCTION_ENTRY gcc version dependent, at least on ppc - commit 16da158 - scsi: smartpqi: Expose SAS address for SATA drives (bsc#1223958). - commit 6711c21 - net/iucv: fix use after free in iucv_sock_close() (CVE-2024-42271 bsc#1229400 bsc#1228974). - commit 82bb6f3 - Update patches.suse/drm-amdkfd-don-t-allow-mapping-the-MMIO-HDP-page-wit.patch (CVE-2024-41011 bsc#1228115 bsc#1228114). - Update patches.suse/powerpc-pseries-Fix-scv-instruction-crash-with-kexec.patch (bsc#1194869 CVE-2024-42230 bsc#1228489). - commit f6019c1 - libceph: fix race between delayed_work() and ceph_monc_stop() (bsc#1228959 CVE-2024-42232). - commit 27160c2 - rpm/kernel-binary.spec.in: fix klp_symbols macro The commit below removed openSUSE filter from %ifs of the klp_symbols definition. But it removed -c of grep too and that causes: error: syntax error in expression: 01 &amp;&amp; ( || 1 ) error: ^ error: unmatched (: 01 &amp;&amp; ( || 1 ) error: ^ error: kernel-default.spec:137: bad %if condition: 01 &amp;&amp; ( || 1 ) So reintroduce -c to the PTF's grep. Fixes: fd0b293bebaf (kernel-binary.spec.in: Enable klp_symbols on openSUSE Tumbleweed (boo#1229042).) - commit 4a36fe3 - rpm/kernel-binary.spec.in: Fix build regression The previous fix forgot to take over grep -c option that broke the conditional expression - commit d29edf2 - kernel-binary.spec.in: Enable klp_symbols on openSUSE Tumbleweed (boo#1229042). After the Jump project the kernel used by SLE and openSUSE Leap are the same. As consequence the klp_symbols variable is set, enabling kernel-default-livepatch-devel on both SLE and openSUSE. The current rules to avoid enabling the package exclude openSUSE Tumbleweed alone, which doesn't makes sense for now. Enabling kernel-default-livepatch-devel on TW makes it easier to test the creation of kernel livepatches of the next SLE versions. - commit fd0b293 - Update patches.suse/powerpc-Avoid-nmi_enter-nmi_exit-in-real-mode-interr.patch (bsc#1221645 ltc#205739 bsc#1223191 CVE-2024-42126 bsc#1228718). Add CVE references. - commit 637c320 - Update patches.suse/0001-ocfs2-fix-DIO-failure-due-to-insufficient-transactio.patch (bsc#1216834 CVE-2024-42077 bsc#1228516). Add CVE references. - commit 8360e90 - ax25: Fix refcount imbalance on inbound connections (CVE-2024-40910 bsc#1227832). - commit 12cb329 - config.sh: generate and install compile_commands.json (bsc#1228971) This file contains the command line options used to compile every C file. It's useful for the livepatching team. - kernel-binary: generate and install compile_commands.json (bsc#1228971) This file contains the command line options used to compile every C file. It's useful for the livepatching team. - commit 314f719 - packaging: Add case-sensitive perl option parsing A recent change in Getopt::Long [1]: Changes in version 2.55 - ---------------------- * Fix long standing bug that duplicate options were not detected when the options differ in case while ignore_case is in effect. This will now yield a warning and become a fatal error in a future release. perl defaults to ignore_case by default, switch it off to avoid accidental misparsing of options. This was suggested after similar change in scripts/. - commit e978477 Package krb5 was updated: - Prevent overflow when calculating ulog block size. An authenticated attacker can cause kadmind to write beyond the end of the mapped region for the iprop log file, likely causing a process crash; (CVE-2025-24528); (bsc#1236619). - Add patch 0014-Prevent-overflow-when-calculating-ulog-block-size.patch Package libapparmor was updated: - Add dac_read_search capability for unix_chkpwd to allow it to read the shadow file even if it has 000 permissions. This is needed after the CVE-2024-10041 fix in PAM. * unix-chkpwd-add-read-capability.path, bsc#1241678 - Allow pam_unix to execute unix_chkpwd with abi/3.0 - remove dovecot-unix_chkpwd.diff - Add allow-pam_unix-to-execute-unix_chkpwd.patch - Add revert-abi-change-for-unix_chkpwd.patch (bsc#1234452, bsc#1232234) - Add dovecot-unix_chkpwd.diff to allow dovecot-auth to execute unix_chkpwd, and add a profile for unix_chkpwd. This is needed for PAM with CVE-2024-10041 (bsc#1234452) Package augeas was updated: - Add patch, fix for bsc#1239909 / CVE-2025-2588: * CVE-2025-2588.patch Package avahi was updated: - prerequire avahi in avahi-autipd as we user &quot;user avahi&quot; - Add avahi-CVE-2024-52616.patch: Backporting 1dade81c from upstream: Properly randomize query id of DNS packets. (CVE-2024-52616, bsc#1233420) - Add avahi-filter-bogus-services.patch: no longer supply bogus services to callbacks (bsc#1226586). Package util-linux was updated: - Skip aarch64 decode path for rest of the architectures (bsc#1229476, util-linux-lscpu-skip-aarch64-decode.patch). Package e2fsprogs was updated: - resize2fs-Check-number-of-group-descriptors-only-if-.patch: resize2fs: Check number of group descriptors only if meta_bg is disabled (bsc#1230145) 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 expat was updated: - version update to 2.7.1 Bug fixes: [#980] #989 Restore event pointer behavior from Expat 2.6.4 (that the fix to CVE-2024-8176 changed in 2.7.0); affected API functions are: - XML_GetCurrentByteCount - XML_GetCurrentByteIndex - XML_GetCurrentColumnNumber - XML_GetCurrentLineNumber - XML_GetInputContext Other changes: [#976] #977 Autotools: Integrate files &quot;fuzz/xml_lpm_fuzzer.{cpp,proto}&quot; with Automake that were missing from 2.7.0 release tarballs [#983] #984 Fix printf format specifiers for 32bit Emscripten [#992] docs: Promote OpenSSF Best Practices self-certification [#978] tests/benchmark: Resolve mistaken double close [#986] Address compiler warnings [#990] #993 Version info bumped from 11:1:10 (libexpat*.so.1.10.1) to 11:2:10 (libexpat*.so.1.10.2); see https://verbump.de/ for what these numbers do Infrastructure: [#982] CI: Start running Perl XML::Parser integration tests [#987] CI: Enforce Clang Static Analyzer clean code [#991] CI: Re-enable warning clang-analyzer-valist.Uninitialized for clang-tidy [#981] CI: Cover compilation with musl [#983] #984 CI: Cover compilation with 32bit Emscripten [#976] #977 CI: Protect against fuzzer files missing from future release archives - version update to 2.7.0 for SLE-15-SP4 - deleted patches - expat-CVE-2022-25235.patch (upstreamed) - expat-CVE-2022-25236-relax-fix.patch (upstreamed) - expat-CVE-2022-25236.patch (upstreamed) - expat-CVE-2022-25313-fix-regression.patch (upstreamed) - expat-CVE-2022-25313.patch (upstreamed) - expat-CVE-2022-25314.patch (upstreamed) - expat-CVE-2022-25315.patch (upstreamed) - expat-CVE-2022-40674.patch (upstreamed) - expat-CVE-2022-43680.patch (upstreamed) - expat-CVE-2023-52425-1.patch (upstreamed) - expat-CVE-2023-52425-2.patch (upstreamed) - expat-CVE-2023-52425-backport-parser-changes.patch (upstreamed) - expat-CVE-2023-52425-fix-tests.patch (upstreamed) - expat-CVE-2024-28757.patch (upstreamed) - expat-CVE-2024-45490.patch (upstreamed) - expat-CVE-2024-45491.patch (upstreamed) - expat-CVE-2024-45492.patch (upstreamed) - expat-CVE-2024-50602.patch (upstreamed) - version update to 2.7.0 (CVE-2024-8176 [bsc#1239618]) * Security fixes: [#893] #973 CVE-2024-8176 -- Fix crash from chaining a large number of entities caused by stack overflow by resolving use of recursion, for all three uses of entities: - general entities in character data (&quot;&lt;e&gt;&amp;g1;&lt;/e&gt;&quot;) - general entities in attribute values (&quot;&lt;e k1='&amp;g1;'/&gt;&quot;) - parameter entities (&quot;%p1;&quot;) Known impact is (reliable and easy) denial of service: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:H/RL:O/RC:C (Base Score: 7.5, Temporal Score: 7.2) Please note that a layer of compression around XML can significantly reduce the minimum attack payload size. * Other changes: [#935] #937 Autotools: Make generated CMake files look for libexpat.@SO_MAJOR@.dylib on macOS [#925] Autotools: Sync CMake templates with CMake 3.29 [#945] #962 #966 CMake: Drop support for CMake &lt;3.13 [#942] CMake: Small fuzzing related improvements [#921] docs: Add missing documentation of error code XML_ERROR_NOT_STARTED that was introduced with 2.6.4 [#941] docs: Document need for C++11 compiler for use from C++ [#959] tests/benchmark: Fix a (harmless) TOCTTOU [#944] Windows: Fix installer target location of file xmlwf.xml for CMake [#953] Windows: Address warning -Wunknown-warning-option about -Wno-pedantic-ms-format from LLVM MinGW [#971] Address Cppcheck warnings [#969] #970 Mass-migrate links from http:// to https:// [#947] #958 .. [#974] #975 Document changes since the previous release [#974] #975 Version info bumped from 11:0:10 (libexpat*.so.1.10.0) to 11:1:10 (libexpat*.so.1.10.1); see https://verbump.de/ for what these numbers do - no source changes, just adding jira reference: jsc#SLE-21253 - version update to 2.6.4 * Security fixes: [bsc#1232601][bsc#1232579] [#915] CVE-2024-50602 -- Fix crash within function XML_ResumeParser from a NULL pointer dereference by disallowing function XML_StopParser to (stop or) suspend an unstarted parser. A new error code XML_ERROR_NOT_STARTED was introduced to properly communicate this situation. // CWE-476 CWE-754 * Other changes: [#903] CMake: Add alias target &quot;expat::expat&quot; [#905] docs: Document use via CMake &gt;=3.18 with FetchContent and SOURCE_SUBDIR and its consequences [#902] tests: Reduce use of global parser instance [#904] tests: Resolve duplicate handler [#317] #918 tests: Improve tests on doctype closing (ex CVE-2019-15903) [#914] Fix signedness of format strings [#919] #920 Version info bumped from 10:3:9 (libexpat*.so.1.9.3) to 11:0:10 (libexpat*.so.1.10.0); see https://verbump.de/ for what these numbers do - updated keyring [https://build.suse.de/request/show/345282] - modified sources % expat.keyring Package freetype2 was updated: - enable brotli support (jsc#PED-12258) - Added patch: * CVE-2025-27363.patch + fixes bsc#1239465, CVE-2025-27363: out-of-bounds write when attempting to parse font subglyph structures related to TrueType GX and variable font files Package glib2 was updated: - Add glib2-CVE-2025-4373.patch: carefully handle gssize parameters (bsc#1242844 CVE-2025-4373 glgo#GNOME/glib#3677). - Add glib2-CVE-2025-3360.patch: Backport 8d60d7dc from upstream, Fix integer overflow when parsing very long ISO8601 inputs. This will only happen with invalid (or maliciously invalid) potential ISO8601 strings, but `g_date_time_new_from_iso8601()` needs to be robust against that. (CVE-2025-3360, bsc#1240897) - Add glib2-CVE-2024-52533.patch: fix a single byte buffer overflow (boo#1233282 CVE-2024-52533 glgo#GNOME/glib#3461). Package gnutls was updated: - Security fix [bsc#1236974, CVE-2024-12243] * gnutls: inefficient DER Decoding in libtasn1 could lead to remote DoS * Add gnutls-CVE-2024-12243.patch Package ncurses was updated: - Modify patch ncurses-5.9-ibm327x.dif * Backport sclp terminfo description entry if for s390 sclp terminal lines * Add a further sclp entry for qemu s390 based systems * Make use of dumb - Add patch ncurses-6.1-boo1229028.patch (boo#1229028) * Allow that terminal description based on static fallback entries can be freed. Package open-iscsi was updated: - Moved this patch upstream, so now it's part of open-iscsi-SUSE-latest.diff, and no longer needed here: * iscsid-clear-scanning-thread-pr_set_io_flusher-flag.patch - iscsid-clear-scanning-thread-pr_set_io_flusher-flag.patch: fix device discovery failure on systems with a large number of devices (bsc#1235606). - Fix issue with yast restarting the iscsid service without first restarting the iscsid socket, which upsets systemd (bsc#1206132). This is already fixed upstream. - Branched SLE-15-SP3 from Factory. No longer in sync with Tumbleweed. - Backported upstream commit, which sets 'safe_logout' and 'startup' in iscsid.conf, to address bsc#1207157 - Updated year in SPEC file Package openssl-1_1 was updated: - Security fix: [bsc#1236136, CVE-2024-13176] * timing side-channel in the ECDSA signature computation * Add openssl-CVE-2024-13176.patch - Security fix: [bsc#1220262, CVE-2023-50782] * Implicit rejection in PKCS#1 v1.5 * Add openssl-CVE-2023-50782.patch Package libpcap was updated: Package procps was updated: - Add patch CVE-2023-4016-part2.patch * Fix the ps command segfaults when pid argument has a leading space (bsc#1236842) Package python3 was updated: - Update CVE-2024-11168-validation-IPv6-addrs.patch according to the Debian version (gh#python/cpython#103848#issuecomment-2708135083). - Add CVE-2025-0938-sq-brackets-domain-names.patch which disallows square brackets ([ and ]) in domain names for parsed URLs (bsc#1236705, CVE-2025-0938, gh#python/cpython#105704) - Remove -IVendor/ from python-config boo#1231795 - Fix CVE-2024-11168-validation-IPv6-addrs.patch - PGO run of build freezes with parallel processing, switch to -j1 - Add CVE-2024-11168-validation-IPv6-addrs.patch fixing bsc#1233307 (CVE-2024-11168, gh#python/cpython#103848): Improper validation of IPv6 and IPvFuture addresses. - Add CVE-2024-9287-venv_path_unquoted.patch to properly quote path names provided when creating a virtual environment (bsc#1232241, CVE-2024-9287) - Drop .pyc files from docdir for reproducible builds (bsc#1230906). - Add CVE-2024-6232-ReDOS-backtrack-tarfile.patch prevent ReDos via excessive backtracking while parsing header values (bsc#1230227, CVE-2024-6232). - Add CVE-2024-5642-switch-off-NPN.patch switching off the NPN support eliminating bsc#1227233 (CVE-2024-5642). - Add CVE-2024-6923-email-hdr-inject.patch to prevent email header injection due to unquoted newlines (bsc#1228780, CVE-2024-6923). - Add CVE-2024-7592-quad-complex-cookies.patch fixing quadratic complexity in parsing cookies with backslashes (bsc#1229596, CVE-2024-7592) - %{profileopt} variable is set according to the variable %{do_profiling} (bsc#1227999) - Remove %suse_update_desktop_file macro as it is not useful any more. - Stop using %%defattr, it seems to be breaking proper executable attributes on /usr/bin/ scripts (bsc#1227378). Package librdkafka was updated: - 0001-Fix-timespec-conversion-to-avoid-infinite-loop-2108-.patch: avoid endless loops (bsc#1242842) Package libsolv was updated: - build both static and dynamic libraries on new suse distros- support the apk package and repository format (both v2 and v3) - new dataiterator_final_{repo,solvable} functions - bump version to 0.7.32 - Provide a symbol specific for the ruby-version so yast does not break across updates (boo#1235598) - fix replaces_installed_package using the wrong solvable id when checking the noupdate map - make POOL_FLAG_ADDFILEPROVIDESFILTERED behaviour more standard - add rpm_query_idarray query function - support rpm's &quot;orderwithrequires&quot; dependency - bump version to 0.7.31 Package sqlite3 was updated: - Sync version 3.49.1 from Factory (jsc#SLE-16032): * CVE-2025-29087, bsc#1241020: Fix a bug in the concat_ws() function, introduced in version 3.44.0, that could lead to a memory error if the separator string is very large (hundreds of megabytes). * CVE-2025-29088, bsc#1241078: Enhanced the SQLITE_DBCONFIG_LOOKASIDE interface to make it more robust against misuse. * Obsoletes sqlite3-rtree-i686.patch Package libssh was updated: - Fix CVE-2025-5318: Likely read beyond bounds in sftp server handle management (bsc#1245311) * Add patch libssh-CVE-2025-5318.patch - Fix CVE-2025-4877: Write beyond bounds in binary to base64 conversion functions (bsc#1245309) * Add patch libssh-CVE-2025-4877.patch - Fix CVE-2025-4878: Use of uninitialized variable in privatekey_from_file() (bsc#1245310) * Add patches: - libssh-CVE-2025-4878-1.patch - libssh-CVE-2025-4878-2.patch - Fix CVE-2025-5372: ssh_kdf() returns a success code on certain failures (bsc#1245314) * Add patch libssh-CVE-2025-5372.patch Package systemd was updated: - Import commit cba472567893618e15b4ab95a3cb0a762ad3ed10 0e8c003e1f core/unit: increase the NameOwnerChanged/GetNameOwner timeout to the unit's start timeout (bsc#1230272) 621e16c0b8 core/unit: add get_timeout_start_usec in UnitVTable and define it for service b4140d888a sd-bus: make bus_add_match_full accept timeout 81cb3a4fb5 udev-builtin-path_id: SAS wide ports must have num_phys &gt; 1 (bsc#1231610) 533e98fc6b sd-device: add helper to read a unsigned int attribute Package libtasn1 was updated: - Security fix: [bsc#1236878, CVE-2024-12133] * Potential DoS in handling of numerous SEQUENCE OF or SET OF elements * Add libtasn1-CVE-2024-12133.patch Package libxml2 was updated: - security update- added patches CVE-2025-49794 [bsc#1244554], heap use after free (UAF) can lead to Denial of service (DoS) CVE-2025-49796 [bsc#1244557], type confusion may lead to Denial of service (DoS) + libxml2-CVE-2025-49794,49796.patch - security update - added patches CVE-2025-6170 [bsc#1244700], stack buffer overflow may lead to a crash CVE-2025-6021 [bsc#1244580], Integer Overflow in xmlBuildQName() Leads to Stack Buffer Overflow in libxml2 + libxml2-CVE-2025-6170,6021.patch - security update - added patches CVE-2025-32414 [bsc#1241551], out-of-bounds read when parsing text via the Python API + libxml2-CVE-2025-32414.patch CVE-2025-32415 [bsc#1241453], a crafted XML document may lead to a heap-based buffer under-read + libxml2-CVE-2025-32415.patch - security update - added patches fix CVE-2024-56171 [bsc#1237363], use-after-free in xmlSchemaIDCFillNodeTables and xmlSchemaBubbleIDCNodeTables in xmlschemas.c + libxml2-CVE-2024-56171.patch fix CVE-2025-24928 [bsc#1237370], stack-based buffer overflow in xmlSnprintfElements in valid.c + libxml2-CVE-2025-24928.patch fix CVE-2025-27113 [bsc#1237418], NULL Pointer Dereference in libxml2 xmlPatMatch + libxml2-CVE-2025-27113.patch - security update - added patches fix CVE-2022-49043 [bsc#1236460], use-after-free in xmlXIncludeAddNode + libxml2-CVE-2022-49043.patch Package libzypp was updated: - Fix credential handling in HEAD requests (bsc#1244105)- version 17.37.5 (35) - RepoInfo: use pathNameSetTrailingSlash (fixes #643) - Fix wrong userdata parameter type when running zypp with debug verbosity (bsc#1239012) - version 17.37.4 (35) - Do not warn about no mirrors if mirrorlist was switched on automatically. (bsc#1243901) - Relax permission of cached packages to 0644 &amp; ~umask (bsc#1243887) - version 17.37.3 (35) - Add a note to service maintained .repo file entries (fixes #638) - Support using %{url} variable in a RIS service's repo section. - version 17.37.2 (35) - Use a cookie file to validate mirrorlist cache. This patch extends the mirrorlist code to use a cookie file to validate the contents of the cache against the source URL, making sure that we do not accidentially use a old cache when the mirrorlist url was changed. For example when migrating a system from one release to the next where the same repo alias might just have a different URL. - Let Service define and update gpgkey, mirrorlist and metalink. - Preserve a mirrorlist file in the raw cache during refresh. - version 17.37.1 (35) - Code16: Enable curl2 backend and parallel package download by default. In Code15 it's optional. Environment variables ZYPP_CURL2=&lt;0|1&gt; and ZYPP_PCK_PRELOAD=&lt;0|1&gt; can be used to turn the features on or off. - Make gpgKeyUrl the default source for gpg keys. When refreshing zypp now primarily uses gpgKeyUrl information from the repo files and only falls back to a automatically generated key Url if a gpgKeyUrl was not specified. - Introduce mirrors into the Media backends (bsc#1240132) - Drop MediaMultiCurl backend. - Throttle progress updates when preloading packages (bsc#1239543) - Check if request is in valid state in CURL callbacks (fixes openSUSE/zypper#605) - spec/CMake: add conditional build '--with[out] classic_rpmtrans_as_default'. classic_rpmtrans is the current builtin default for SUSE, otherwise it's single_rpmtrans. The `enable_preview_single_rpmtrans_as_default_for_zypper` switch was removed from the spec file. Accordingly the CMake option ENABLE_PREVIEW_SINGLE_RPMTRANS_AS_DEFAULT_FOR_ZYPPER was removed. - version 17.37.0 (35) - fixed build with boost 1.88. - XmlReader: Fix detection of bad input streams (fixes #635) libxml2 2.14 potentially reads the complete stream, so it may have the 'eof' bit set. Which is not 'good' but also not 'bad'. - rpm: Fix detection of %triggerscript starts (bsc#1222044) - RepoindexFileReader: add more &lt;repo&gt; related attributes a service may set. Add optional attributes gpgcheck, repo_gpgcheck, pkg_gpgcheck, keeppackages, gpgkey, mirrorlist, and metalink with the same semantic as in a .repo file. - version 17.36.7 (35) - Drop workaround for broken rpm-4.18 in Code16 (bsc#1237172) - BuildRequires: %{libsolv_devel_package} &gt;= 0.7.32. Code16 moved static libs to libsolv-devel-static. - Drop usage of SHA1 hash algorithm because it will become unavailable in FIPS mode (bsc#1240529) - Fix zypp.conf dupAllowVendorChange to reflect the correct default (false). The default was true in Code12 (libzypp-16.x) and changed to false with Code15 (libzypp-17.x). Unfortunately this was done by shipping a modified zypp.conf file rather than fixing the code. - zypp.conf: Add `lock_timeout` ($ZYPP_LOCK_TIMEOUT) (bsc#1239809) - version 17.36.6 (35) - Fix computation of RepStatus if Repo URLs change. - Fix lost double slash when appending to an absolute FTP url (bsc#1238315) Ftp actually differs between absolute and relative URL paths. Absolute path names begin with a double slash encoded as '/%2F'. This must be preserved when manipulating the path. - version 17.36.5 (35) - Add a transaction package preloader (fixes openSUSE/zypper#104) This patch adds a preloader that concurrently downloads files during a transaction commit. It's not yet enabled per default. To enable the preview set ZYPP_CURL2=1 and ZYPP_PCK_PRELOAD=1 in the environment. - RpmPkgSigCheck_test: Exchange the test package signingkey (fixes #622) - Exclude MediaCurl tests if DISABLE_MEDIABACKEND_TESTS (fixes #626) - Strip a mediahandler tag from baseUrl querystrings. - version 17.36.4 (35) - Disable zypp.conf:download.use_deltarpm by default (fixes #620) Measurements show that you don't benefit from using deltarpms unless your network connection is very slow. That's why most distributions even stop offering deltarpms. The default remains unchanged on SUSE-15.6 and older. - Make sure repo variables are evaluated in the right context (bsc#1237044) - Introducing MediaCurl2 a alternative HTTP backend. This patch adds MediaCurl2 as a testbed for experimenting with a more simple way to download files. Set ZYPP_CURL2=1 in the environment to use it. - version 17.36.3 (35) - Filesystem usrmerge must not be done in singletrans mode (bsc#1236481, bsc#1189788) Commit will amend the backend in case the transaction would perform a filesystem usrmerge. - Workaround bsc#1216091 on Code16. - version 17.36.2 (35) - Don't issue deprecated warnings if -DNDEBUG is set (bsc#1236983) Released libyui packages compile with -Werror=deprecated-declarations so we can't add deprecated warnings without breaking them. - make gcc15 happy (fixes #613) - version 17.36.1 (35) - Drop zypp-CheckAccessDeleted in favor of 'zypper ps'. - Fix Repoverification plugin not being executed (fixes #614) - Refresh: Fetch the master index file before key and signature (bsc#1236820) - Allow libzypp to compile with C++20. - Deprecate RepoReports we do not trigger. - version 17.36.0 (35) - Create '.keep_packages' in the package cache dir to enforce keeping downloaded packages of all repos cahed there (bsc#1232458) - version 17.35.19 (35) - Fix missing UID checks in repomanager workflow (fixes #603) - version 17.35.18 (35) - Move cmake config files to LIB_INSTALL_DIR/cmake/Zypp (fixes #28) - Fix 'zypper ps' when running in incus container (bsc#1229106) Should apply to lxc and lxd containers as well. - Re-enable 'rpm --runposttrans' usage for chrooted systems (bsc#1216091) - version 17.35.17 (35) - Url: queryparams without value should not have a trailing &quot;=&quot;. - 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) - The 20MB download limit must not apply to non-metadata files like package URLs provided via the CLI (bsc#1233393). - version 17.35.14 (35) - BuildCache: Don't try to retrieve missing raw metadata if no permission to write the cache (bsc#1225451) - RepoManager: throw RepoNoPermissionException if the user has no permission to update(write) the caches (bsc#1225451) - version 17.35.13 (35) - PluginFrame: Send unescaped colons in header values (bsc#1231043) According to the STOMP protocol it would be correct to escape a colon in a header-value, but it breaks plugin receivers which do not expect this. The first colon separates header-name from header-value, so escaping in the header-value is not needed anyway. Escaping in the header-value affects especially the urlresolver plugins. The input URL is passed in a header, but sent back as raw data in the frames body. If the plugin receiver does not correctly unescape the URL we may get back a &quot;https\c//&quot; which is not usable. - Do not ignore return value of std::remove_if in MediaSyncFacade (fixes #579) - Fix hang in curl code with no network connection (bsc#1230912) - version 17.35.12 (35) - Deprecate librpmDb::db_const_iterator default ctor (bsc#1230267) It's preferred to explicitly tell the root directory of the system whose database you want to query. - version 17.35.11 (35) - API refactoring. Prevent zypper from using now private libzypp symbols (bsc#1230267) - Conflicts: zypper &lt;= 1.14.76 - version 17.35.10 (35) - single_rpmtrans: fix installation of .src.rpms (bsc#1228647) - version 17.35.9 (35) Package shadow was updated: - bsc#1230972: Add useradd warnings when requested UID is outside the default range - add shadow-bsc1230972-useradd-warning.patch - bsc#1228337: chage -d date vs passwd -S output is off by one Remove shadow-bsc1176006-chage-date.patch Package logrotate was updated: - Backport 'ignoreduplicates' configuration flag (jsc#PED-10366) * Added patch logrotate-ignore-duplicates.patch * Allows log processing with duplicate logfile matches Package openssh was updated: - Added openssh-bsc1241045-kexalgo-gt-256bits.patch (bsc#1241045) from upstream, which allows KEX hashes greater than 256 bits. Thanks to Ali Abdallah &lt;ali.abdallah@suse.com&gt;. - Added openssh-cve-2025-32728.patch (bsc#1241012, CVE-2025-32728). This fixes an upstream logic error handling the DisableForwarding option. - Update openssh-7.6p1-audit_race_condition.patch (bsc#1232533), fixing failures with very large MOTDs. Thanks to Ali Abdallah &lt;ali.abdallah@suse.com&gt;. - Updated openssh-8.1p1-audit.patch (bsc#1228634) with modification from Jaroslav Jindrak (jjindrak@suse.com) to fix the hostname being left out of the audit output. - Backported patch to fix a MitM attack against OpenSSH's VerifyHostKeyDNS-enabled client (bsc#1237040, CVE-2025-26465): * fix-CVE-2025-26465.patch Package pam-config was updated: - Stop adding pam_env in AUTH stack, and be sure to put this module at the really end of the SESSION stack. [bsc#1243226, CVE-2025-6018, remove-pam_env-from-auth-stack.patch] - Change check for existence of modules. If we have a biarch architecture, we check that the 64bit PAM module is there and report an error if not. For the 32bit variant, we only issue a warning. [pam-config-change-check-for-existence-of-modules.patch, bsc#1227216] Package pam was updated: - pam_namespace: convert functions that may operate on a user-controlled path to operate on file descriptors instead of absolute path. And keep the bind-mount protection from protect_mount() as a defense in depthmeasure. [bsc#1244509 pam_inline-introduce-pam_asprintf-pam_snprintf-and-p.patch, pam_namespace-fix-potential-privilege-escalation.patch, pam_namespace-add-flags-to-indicate-path-safety.patch, pam_namespace-secure_opendir-do-not-look-at-the-grou.patch] - pam_namespace-fix-potential-privilege-escalation.patch adapted and includes changes from upstream commits: ds6242a, bc856cd. * pam_namespace fix logic in return value handling * pam_namespace move functions around - pam_env: Change the default to not read the user .pam_environment file [bsc#1243226, CVE-2025-6018, pam_env-change-the-default-to-not-read-the-user-env.patch] - pam_unix/passverify: (get_account_info) [!HELPER_COMPILE]: Always return PAM_UNIX_RUN_HELPER instead of trying to obtain the shadow password file entry. [passverify-always-run-the-helper-to-obtain-shadow_pwd.patch, bsc#1232234, CVE-2024-10041] - Do not reject the user with a hash assuming it's non-empty. [pam_unix-allow-empty-passwords-with-non-empty-hashes.patch] Package perl was updated: - do not change the current directory when cloning an open directory handle [bnc#1244079] [CVE-2025-40909] new patch: perl-dirdup.diff Package python3-setuptools was updated: - Add patch CVE-2025-47273.patch to fix A path traversal vulnerability. (bsc#1243313, CVE-2025-47273, gh#pypa/setuptools@250a6d17978f) Package rsyslog was updated: - fix PreserveFQDN option before daemon is restarted (bsc#1231229) add 0001-core-bugfix-rsyslog-messages-may-not-always-have-FQD.patch - restart daemon after update at the end of the transaction (bsc#1230984) Package runc was updated: - Update to runc v1.2.6. Upstream changelog is available from &lt;https://github.com/opencontainers/runc/releases/tag/v1.2.6&gt;. - Update to runc v1.2.5. Upstream changelog is available from &lt;https://github.com/opencontainers/runc/releases/tag/v1.2.5&gt;. - Update to runc v1.2.4. Upstream changelog is available from &lt;https://github.com/opencontainers/runc/releases/tag/v1.2.4&gt;. - Update runc.keyring to match upstream. - Update to runc v1.2.3. Upstream changelog is available from &lt;https://github.com/opencontainers/runc/releases/tag/v1.2.3&gt;. - Update to runc v1.2.2. Upstream changelog is available from &lt;https://github.com/opencontainers/runc/releases/tag/v1.2.2&gt;. - Update to runc v1.2.1. Upstream changelog is available from &lt;https://github.com/opencontainers/runc/releases/tag/v1.2.1&gt;. - Update to runc v1.2.0. Upstream changelog is available from &lt;https://github.com/opencontainers/runc/releases/tag/v1.2.0&gt;. - Remove upstreamed patches. - 0001-bsc1221050-libct-seccomp-patchbpf-rm-duplicated-code.patch - 0002-bsc1221050-seccomp-patchbpf-rename-nativeArch-linuxA.patch - 0003-bsc1221050-seccomp-patchbpf-always-include-native-ar.patch - 0004-bsc1214960-nsenter-cloned_binary-remove-bindfd-logic.patch - Update to runc v1.2.0~rc3. Upstream changelog is available from &lt;https://github.com/opencontainers/runc/releases/tag/v1.2.0-rc.3&gt;. Includes the patch for CVE-2024-45310. bsc#1230092 Package shim was updated: - Update shim-install to apply the missing fix for openSUSE Leap (bsc#1210382) fixed by Gary. * 86b73d1 Fix that bootx64.efi is not updated on Leap - Update shim-install to use the 'removable' way for SL-Micro (bsc#1230316) fixed by Gary. * 433cc4e Always use the removable way for SL-Micro Package 000release-packages:sle-module-basesystem-release was updated: Package 000release-packages:sle-module-containers-release was updated: Package 000release-packages:sle-module-public-cloud-release was updated: Package 000release-packages:sle-module-server-applications-release was updated: Package socat was updated: - Security fix for readline.sh: arbitrary file overwrite (bsc#1225462) - add CVE-2024-54661.patch Package sudo was updated: - Fix a possilbe local privilege escalation via the --host option [bsc#1245274, CVE-2025-32462] Package supportutils was updated: - Changes to version 3.2.10 + network.txt collect all firewalld zones (pr#233) + Collects gfs2 info (PED-11853, pr#235, pr#236) + Ignore tasks/threads to prevent collecting duplicate fd data in open_files (bsc#1230371, pr#237) + Added openldap2_5 support for SLES (pr#238) + Collects additional hawk details (pr#239) + Optimized filtering D/Z processes (pr#241) + Collect firewalld permanent configuration (pr#243) + ldap_info: support for multiple DBs and sanitize olcRootPW (bsc#1231838, pr#247) + Added dbus_info for dbus.txt (bsc#1222650, pr#248) - Changes to version 3.2.9 + Map running PIDs to RPM package owner aiding BPF program detection (bsc#1222896, bsc#1213291, PED-8221) + Supportconfig available in current distro (PED-7131) + Corrected display issues (bsc#1231396) + NFS takes too long, showmount times out (bsc#1231423) + Merged sle15 and master branches (bsc#1233726, PED-11669) Package suse-build-key was updated: - changed keys to use SHA256 UIDs instead of SHA1. (bsc#1237294 bsc#1236779 jsc#PED-12321) - gpg-pubkey-3fa1d6ce-67c856ee.asc to gpg-pubkey-09d9ea69-67c857f3.asc - gpg-pubkey-09d9ea69-645b99ce.asc to gpg-pubkey-3fa1d6ce-63c9481c.asc - suse_ptf_key_2023.asc, suse_ptf_key.asc: adjusted Package suseconnect-ng was updated: - Update version to 1.13: - Integrating uptime-tracker - Honor auto-import-gpg-keys flag on migration (bsc#1231328) - Only send labels if targetting SCC - Skip the docker auth generation on RMT (bsc#1231185) - Add --set-labels to register command to set labels at registration time on SCC - Add a new function to display suse-uptime-tracker version - Integrate with uptime-tracker ( https://github.com/SUSE/uptime-tracker/ ) - Add a command to show the info being gathered - Update version to 1.12: - Set the filesystem root on zypper when given (bsc#1230229,bsc#1229014) Package timezone was updated: - Update to 2025b: * New zone for Aysén Region in Chile (America/Coyhaique) which moves from -04/-03 to -03 - Refresh patches * revert-philippines-historical-data.patch * tzdata-china.diff - Update to 2025a: * Paraguay adopts permanent -03 starting spring 2024 * Improve pre-1991 data for the Philippines * Etc/Unknown is now reserved - Update to 2024b: * Improve historical data for Mexico, Mongolia, and Portugal. * System V names are now obsolescent. * The main data form now uses %z. * The code now conforms to RFC 8536 for early timestamps. * Support POSIX.1-2024, which removes asctime_r and ctime_r. * Assume POSIX.2-1992 or later for shell scripts. * SUPPORT_C89 now defaults to 1. - Add revert-philippines-historical-data.patch, revert-systemv-deprecation.patch * Fixes testsuite failures for other packages Package util-linux-systemd was updated: - Skip aarch64 decode path for rest of the architectures (bsc#1229476, util-linux-lscpu-skip-aarch64-decode.patch). Package vim was updated: - Fix bsc#1228776 / CVE-2024-41965.- Fix bsc#1239602 / CVE-2025-29768. - Refresh patch: vim-7.3-sh_is_bash.patch - Update to 9.1.1406: 9.1.1406: crash when importing invalid tuple 9.1.1405: tests: no test for mapping with special keys in session file 9.1.1404: wrong link to Chapter 2 in new-tutor 9.1.1403: expansion of 'tabpanelopt' value adds wrong values 9.1.1402: multi-byte mappings not properly stored in session file 9.1.1401: list not materialized in prop_list() 9.1.1400: [security]: use-after-free when evaluating tuple fails 9.1.1399: tests: test_codestyle fails for auto-generated files 9.1.1398: completion: trunc does not follow Pmenu highlighting attributes 9.1.1397: tabpanel not correctly updated on :tabonly 9.1.1396: 'errorformat' is a global option 9.1.1395: search_stat not reset when pattern differs in case 9.1.1394: tabpanel not correctly redrawn on tabonly 9.1.1393: missing test for switching buffers and reusing curbuf 9.1.1392: missing patch number 9.1.1391: Vim does not have a vertical tabpanel 9.1.1390: style: more wrong indentation 9.1.1389: completion: still some issue when 'isexpand' contains a space 9.1.1388: Scrolling one line too far with 'nosmoothscroll' page scrolling 9.1.1387: memory leak when buflist_new() fails to reuse curbuf 9.1.1386: MS-Windows: some minor problems building on AARCH64 9.1.1385: inefficient loop for 'nosmoothscroll' scrolling 9.1.1384: still some problem with the new tutors filetype plugin 9.1.1383: completion: 'isexpand' option does not handle space char correct 9.1.1382: if_ruby: unused compiler warnings from ruby internals 9.1.1381: completion: cannot return to original text 9.1.1380: 'eventignorewin' only checked for current buffer 9.1.1379: MS-Windows: error when running evim when space in path 9.1.1378: sign without text overwrites number option 9.1.1377: patch v9.1.1370 causes some GTK warning messages 9.1.1376: quickfix dummy buffer may remain as dummy buffer 9.1.1375: [security]: possible heap UAF with quickfix dummy buffer 9.1.1374: completion: 'smartcase' not respected when filtering matches 9.1.1373: 'completeopt' checking logic can be simplified 9.1.1372: style: braces issues in various files 9.1.1371: style: indentation and brace issues in insexpand.c 9.1.1370: CI Tests favor GTK2 over GTK3 9.1.1369: configure still using autoconf 2.71 9.1.1368: GTK3 and GTK4 will drop numeric cursor support. 9.1.1367: too many strlen() calls in gui.c 9.1.1366: v9.1.1364 unintentionally changed sign.c and sound.c 9.1.1365: MS-Windows: compile warnings and too many strlen() calls 9.1.1364: style: more indentation issues 9.1.1363: style: inconsistent indentation in various files 9.1.1362: Vim9: type ignored when adding tuple to instance list var 9.1.1361: [security]: possible use-after-free when closing a buffer 9.1.1360: filetype: GNU Radio companion files are not recognized 9.1.1359: filetype: GNU Radio config files are not recognized 9.1.1358: if_lua: compile warnings with gcc15 9.1.1357: Vim incorrectly escapes tags with &quot;[&quot; in a help buffer 9.1.1356: Vim9: crash when unletting variable 9.1.1355: The pum_redraw() function is too complex 9.1.1354: tests: Test_terminalwinscroll_topline() fails on Windows 9.1.1353: missing change from v9.1.1350 9.1.1352: style: inconsistent indent in insexpand.c 9.1.1351: Return value of getcmdline() inconsistent in CmdlineLeavePre 9.1.1350: tests: typo in Test_CmdlineLeavePre_cabbr() 9.1.1349: CmdlineLeavePre may trigger twice 9.1.1348: still E315 with the terminal feature 9.1.1347: small problems with gui_w32.c 9.1.1346: missing out-of-memory check in textformat.c 9.1.1345: tests: Test_xxd_color2() test failure dump diff is misleading 9.1.1344: double free in f_complete_match() (after v9.1.1341) 9.1.1343: filetype: IPython files are not recognized 9.1.1342: Shebang filetype detection can be improved 9.1.1341: cannot define completion triggers 9.1.1340: cannot complete :filetype arguments 9.1.1339: missing out-of-memory checks for enc_to_utf16()/utf16_to_enc() 9.1.1338: Calling expand() interferes with cmdcomplete_info() 9.1.1337: Undo corrupted with 'completeopt' &quot;preinsert&quot; when switching buffer 9.1.1336: comment plugin does not support case-insensitive 'commentstring' 9.1.1335: Coverity complains about Null pointer dereferences 9.1.1334: Coverity complains about unchecked return value 9.1.1333: Coverity: complains about unutilized variable 9.1.1332: Vim9: segfault when using super within a lambda 9.1.1331: Leaking memory with cmdcomplete() 9.1.1330: may receive E315 in terminal 9.1.1329: cannot get information about command line completion 9.1.1328: too many strlen() calls in indent.c 9.1.1327: filetype: nroff detection can be improved 9.1.1326: invalid cursor position after 'tagfunc' 9.1.1325: tests: not checking error numbers properly 9.1.1324: undefined behaviour if X11 connection dies 9.1.1323: b:undo_ftplugin not executed when re-using buffer 9.1.1322: small delete register cannot paste multi-line correctly 9.1.1321: filetype: MS ixx and mpp files are not recognized 9.1.1320: filetype: alsoft config files are not recognized 9.1.1319: Various typos in the code, issue with test_inst_complete.vim 9.1.1318: tests: test_format fails 9.1.1317: noisy error when restoring folds from session fails 9.1.1316: missing memory allocation failure in os_mswin.c 9.1.1315: completion: issue with fuzzy completion and 'completefuzzycollect' 9.1.1314: max allowed string width too small 9.1.1313: compile warning about uninitialized value 9.1.1312: tests: Test_backupskip() fails when HOME is defined 9.1.1311: completion: not possible to limit number of matches 9.1.1310: completion: redundant check for preinsert effect 9.1.1309: tests: no test for 'pummaxwidth' with non-truncated &quot;kind&quot; 9.1.1308: completion: cannot order matches by distance to cursor 9.1.1307: make syntax does not reliably detect different flavors 9.1.1306: completion menu rendering can be improved 9.1.1305: completion menu active after switching windows/tabs 9.1.1304: filetype: some man files are not recognized 9.1.1303: missing out-of-memory check in linematch.c 9.1.1302: Coverity warns about using uninitialized value 9.1.1301: completion: cannot configure completion functions with 'complete' 9.1.1300: wrong detection of -inf 9.1.1299: filetype: mbsyncrc files are not recognized 9.1.1298: define_function() is too long 9.1.1297: Ctrl-D scrolling can get stuck 9.1.1296: completion: incorrect truncation logic 9.1.1295: clientserver: does not handle :stopinsert correctly 9.1.1294: gui tabline menu does not use confirm when closing tabs 9.1.1293: comment plugin does not handle 'exclusive' selection for comment object 9.1.1292: statusline not correctly evaluated 9.1.1291: too many strlen() calls in buffer.c 9.1.1290: tests: missing cleanup in test_filetype.vim 9.1.1289: tests: no test for matchparen plugin with WinScrolled event 9.1.1288: Using wrong window in ll_resize_stack() 9.1.1287: quickfix code can be further improved 9.1.1286: filetype: help files not detected when 'iskeyword' includes &quot;:&quot; 9.1.1285: Vim9: no error message for missing method after &quot;super.&quot; 9.1.1284: not possible to configure pum truncation char 9.1.1283: quickfix stack is limited to 10 items 9.1.1282: Build and test failure without job feature 9.1.1281: extra newline output when editing stdin 9.1.1280: trailing additional semicolon in get_matches_in_str() 9.1.1279: Vim9: null_object and null_class are no reserved names 9.1.1278: Vim9: too long functions in vim9type.c 9.1.1277: tests: trailing comment char in test_popupwin 9.1.1276: inline word diff treats multibyte chars as word char 9.1.1275: MS-Windows: Not possible to pass additional flags to Make_mvc 9.1.1274: Vim9: no support for object&lt;type&gt; as variable type 9.1.1273: Coverity warns about using uninitialized value 9.1.1272: completion: in keyword completion Ctrl_P cannot go back after Ctrl_N 9.1.1271: filetype: Power Query files are not recognized 9.1.1270: missing out-of-memory checks in buffer.c 9.1.1269: completion: compl_shown_match is updated when starting keyword completion 9.1.1268: filetype: dax files are not recognized 9.1.1267: Vim9: no support for type list/dict&lt;object&lt;any&gt;&gt; 9.1.1266: MS-Windows: type conversion warnings 9.1.1265: tests: no tests for typing normal char during completion 9.1.1264: Vim9: error when comparing objects 9.1.1263: string length wrong in get_last_inserted_save() 9.1.1262: heap-buffer-overflow with narrow 'pummaxwidth' value 9.1.1261: No test for 'pummaxwidth' non-truncated items 9.1.1260: Hang when filtering buffer with NUL bytes 9.1.1259: some issues with comment package and tailing spaces 9.1.1258: regexp: max \U and \%U value is limited by INT_MAX 9.1.1257: Mixing vim_strsize() with mb_ptr2cells() in pum_redraw() 9.1.1256: if_python: duplicate tuple data entries 9.1.1255: missing test condition for 'pummaxwidth' setting 9.1.1254: need more tests for the comment plugin 9.1.1253: abort when closing window with attached quickfix data 9.1.1252: typos in code and docs related to 'diffopt' &quot;inline:&quot; 9.1.1251: if_python: build error with tuples and dynamic python 9.1.1250: cannot set the maximum popup menu width 9.1.1249: tests: no test that 'listchars' &quot;eol&quot; doesn't affect &quot;gM&quot; 9.1.1248: compile error when building without FEAT_QUICKFIX 9.1.1247: fragile setup to get (preferred) keys from key_name_entry 9.1.1246: coverity complains about some changes in v9.1.1243 9.1.1245: need some more tests for curly braces evaluation 9.1.1244: part of patch v9.1.1242 was wrong 9.1.1243: diff mode is lacking for changes within lines 9.1.1242: Crash when evaluating variable name 9.1.1241: wrong preprocessort indentation in term.c 9.1.1240: Regression with ic/ac text objects and comment plugin 9.1.1239: if_python: no tuple data type support 9.1.1238: wrong cursor column with 'set splitkeep=screen' 9.1.1237: Compile error with C89 compiler in term.c 9.1.1236: tests: test_comments leaves swapfiles around 9.1.1235: cproto files are outdated 9.1.1234: Compile error when SIZE_MAX is not defined 9.1.1233: Coverity warns about NULL pointer when triggering WinResized 9.1.1232: Vim script is missing the tuple data type 9.1.1231: filetype: SPA JSON files are not recognized 9.1.1230: inconsistent CTRL-C behaviour for popup windows 9.1.1229: the comment plugin can be improved 9.1.1228: completion: current position column wrong after got a match 9.1.1227: no tests for the comment package 9.1.1226: &quot;shellcmdline&quot; completion doesn't work with input() 9.1.1225: extra NULL check in VIM_CLEAR() 9.1.1224: cannot :put while keeping indent 9.1.1223: wrong translation used for encoding failures 9.1.1222: using wrong length for last inserted string 9.1.1221: Wrong cursor pos when leaving Insert mode just after 'autoindent' 9.1.1220: filetype: uv.lock file not recognized 9.1.1219: Strange error with wrong type for matchfuzzy() &quot;camelcase&quot; 9.1.1218: missing out-of-memory check in filepath.c 9.1.1217: tests: typos in test_matchfuzzy.vim 9.1.1216: Pasting the '.' register multiple times may not work 9.1.1215: Patch 9.1.1213 has some issues 9.1.1214: matchfuzzy() can be improved for camel case matches 9.1.1213: cannot :put while keeping indent 9.1.1212: too many strlen() calls in edit.c 9.1.1212: filetype: logrotate'd pacmanlogs are not recognized 9.1.1211: TabClosedPre is triggered just before the tab is being freed 9.1.1210: translation(ru): missing Russian translation for the new tutor 9.1.1209: colorcolumn not drawn after virtual text lines 9.1.1208: MS-Windows: not correctly restoring alternate screen on Win 10 9.1.1207: MS-Windows: build warning in filepath.c 9.1.1206: tests: test_filetype fails when a file is a directory 9.1.1205: completion: preinserted text not removed when closing pum 9.1.1204: MS-Windows: crash when passing long string to expand() 9.1.1203: matchparen keeps cursor on case label in sh filetype 9.1.1202: Missing TabClosedPre autocommand 9.1.1201: 'completefuzzycollect' does not handle dictionary correctly 9.1.1200: cmdline pum not cleared for input() completion 9.1.1199: gvim uses hardcoded xpm icon file 9.1.1198: [security]: potential data loss with zip.vim 9.1.1197: process_next_cpt_value() uses wrong condition 9.1.1196: filetype: config files for container tools are not recognized 9.1.1195: inside try-block: fn body executed with default arg undefined 9.1.1194: filetype: false positive help filetype detection 9.1.1193: Unnecessary use of STRCAT() in au_event_disable() 9.1.1192: Vim crashes with term response debug logging enabled 9.1.1191: tests: test for patch 9.1.1186 doesn't fail without the patch 9.1.1190: C indentation does not detect multibyte labels 9.1.1189: if_python: build error due to incompatible pointer types 9.1.1188: runtime(tera): tera support can be improved 9.1.1187: matchparen plugin wrong highlights shell case statement 9.1.1186: filetype: help files in git repos are not detected 9.1.1185: endless loop with completefuzzycollect and no match found 9.1.1184: Unnecessary use of vim_tolower() in vim_strnicmp_asc() 9.1.1083: &quot;above&quot; virtual text breaks cursorlineopt=number 9.1.1182: No cmdline completion for 'completefuzzycollect' 9.1.1181: Unnecessary STRLEN() calls in insexpand.c 9.1.1180: short-description 9.1.1179: too many strlen() calls in misc2.c 9.1.1178: not possible to generate completion candidates using fuzzy matching 9.1.1177: filetype: tera files not detected - Introduce patch to fix bsc#1235751 (regression). * vim-9.1.1134-revert-putty-terminal-colors.patch - Update to 9.1.1176. Changes: * 9.1.1176: wrong indent when expanding multiple lines * 9.1.1175: inconsistent behaviour with exclusive selection and motion commands * 9.1.1174: tests: Test_complete_cmdline() may fail * 9.1.1173: filetype: ABNF files are not detected * 9.1.1172: [security]: overflow with 'nostartofline' and Ex command in tag file * 9.1.1171: tests: wrong arguments passed to assert_equal() * 9.1.1170: wildmenu highlighting in popup can be improved * 9.1.1169: using global variable for get_insert()/get_lambda_name() * 9.1.1168: wrong flags passed down to nextwild() * 9.1.1167: mark '] wrong after copying text object * 9.1.1166: command-line auto-completion hard with wildmenu * 9.1.1165: diff: regression with multi-file diff blocks * 9.1.1164: [security]: code execution with tar.vim and special crafted tar files * 9.1.1163: $MYVIMDIR is set too late * 9.1.1162: completion popup not cleared in cmdline * 9.1.1161: preinsert requires bot &quot;menu&quot; and &quot;menuone&quot; to be set * 9.1.1160: Ctrl-Y does not work well with &quot;preinsert&quot; when completing items * 9.1.1159: $MYVIMDIR may not always be set * 9.1.1158: :verbose set has wrong file name with :compiler! * 9.1.1157: command completion wrong for input() * 9.1.1156: tests: No test for what patch 9.1.1152 fixes * 9.1.1155: Mode message not cleared after :silent message * 9.1.1154: Vim9: not able to use autoload class accross scripts * 9.1.1153: build error on Haiku * 9.1.1152: Patch v9.1.1151 causes problems * 9.1.1151: too many strlen() calls in getchar.c * 9.1.1150: :hi completion may complete to wrong value * 9.1.1149: Unix Makefile does not support Brazilian lang for the installer * 9.1.1148: Vim9: finding imported scripts can be further improved * 9.1.1147: preview-window does not scroll correctly * 9.1.1146: Vim9: wrong context being used when evaluating class member * 9.1.1145: multi-line completion has wrong indentation for last line * 9.1.1144: no way to create raw strings from a blob * 9.1.1143: illegal memory access when putting a register * 9.1.1142: tests: test_startup fails if $HOME/$XDG_CONFIG_HOME is defined * 9.1.1141: Misplaced comment in readfile() * 9.1.1140: filetype: m17ndb files are not detected * 9.1.1139: [fifo] is not displayed when editing a fifo * 9.1.1138: cmdline completion for :hi is too simplistic * 9.1.1137: ins_str() is inefficient by calling STRLEN() * 9.1.1136: Match highlighting marks a buffer region as changed * 9.1.1135: 'suffixesadd' doesn't work with multiple items * 9.1.1134: filetype: Guile init file not recognized * 9.1.1133: filetype: xkb files not recognized everywhere * 9.1.1132: Mark positions wrong after triggering multiline completion * 9.1.1131: potential out-of-memory issue in search.c * 9.1.1130: 'listchars' &quot;precedes&quot; is not drawn on Tabs. * 9.1.1129: missing out-of-memory test in buf_write() * 9.1.1128: patch 9.1.1119 caused a regression with imports * 9.1.1127: preinsert text is not cleaned up correctly * 9.1.1126: patch 9.1.1121 used a wrong way to handle enter * 9.1.1125: cannot loop through pum menu with multiline items * 9.1.1124: No test for 'listchars' &quot;precedes&quot; with double-width char * 9.1.1123: popup hi groups not falling back to defaults * 9.1.1122: too many strlen() calls in findfile.c * 9.1.1121: Enter does not insert newline with &quot;noselect&quot; * 9.1.1120: tests: Test_registers fails * 9.1.1119: Vim9: Not able to use an autoloaded class from another autoloaded script * 9.1.1118: tests: test_termcodes fails * 9.1.1117: there are a few minor style issues * 9.1.1116: Vim9: super not supported in lambda expressions * 9.1.1115: [security]: use-after-free in str_to_reg() * 9.1.1114: enabling termguicolors automatically confuses users * 9.1.1113: tests: Test_terminal_builtin_without_gui waits 2 seconds * 9.1.1112: Inconsistencies in get_next_or_prev_match() * 9.1.1111: Vim9: variable not found in transitive import * 9.1.1110: Vim tests are slow and flaky * 9.1.1109: cmdexpand.c hard to read * 9.1.1108: 'smoothscroll' gets stuck with 'listchars' &quot;eol&quot; * 9.1.1107: cannot loop through completion menu with fuzzy * 9.1.1106: tests: Test_log_nonexistent() causes asan failure * 9.1.1105: Vim9: no support for protected new() method * 9.1.1104: CI: using Ubuntu 22.04 Github runners * 9.1.1103: if_perl: still some compile errors with Perl 5.38 * 9.1.1102: tests: Test_WinScrolled_Resized_eiw() uses wrong filename - 9.1.1101 is a fix for: bsc#1229685 (CVE-2024-43790) bsc#1229822 (CVE-2024-43802) bsc#1230078 (CVE-2024-45306) bsc#1235695 (CVE-2025-22134) bsc#1236151 (CVE-2025-24014) bsc#1237137 (CVE-2025-1215) - Remove obsoleted patch: * vim-7.3-mktemp_tutor.patch - update to 9.1.1101 * insexpand.c hard to read * tests: Test_log_nonexistent only works on Linux * Update base-syntax, improve variable matching * Vim9: import with extends may crash * leaking memory with completing multi lines * --log with non-existent path causes a crash * if_perl: Perl 5.38 adds new symbols causing link failure * tests: matchparen plugin test wrongly named * Vim9: problem finding implemented method in type hierarchy * runtime(qf): Update syntax file, match second delimiter * tests: output of test ...win32_ctrl_z depends on python version * tests: fix expected return code for python 3.13 on Windows * tests: timeout might be a bit too small * tests: test_terminwscroll_topline2 unreliable * tests: No check when tests are run under Github actions * tests: plugin tests are named inconsistently * Vim9: import with extends may crash * completion doesn't work with multi lines * filetype: cmmt files are not recognized * Unable to persistently ignore events in a window and its buffers * improve syntax highlighting * setreg() doesn't correctly handle mbyte chars in blockwise mode * unexpected DCS responses may cause out of bounds reads * has('bsd') is true for GNU/Hurd * filetype: Mill files are not recognized * GUI late startup leads to uninitialized scrollbars * Add support for lz4 to tar &amp; gzip plugin * Terminal ansi colors off by one after tgc reset * included syntax items do not understand contains=TOP * vim_strnchr() is strange and unnecessary * Vim9: len variable not used in compile_load() * runtime(vim): Update base-syntax, match :debuggreedy count prefix * Strange error when heredoc marker starts with &quot;trim&quot; * tests: test_compiler fails on Windows without Maven * 'diffopt' &quot;linematch&quot; cannot be used with {n} less than 10 * args missing after failing to redefine a function * Cannot control cursor positioning of getchar() * preinsert text completions not deleted with &lt;C-W&gt;/&lt;C-U&gt; * getchar() can't distinguish between C-I and Tab * tests: Test_termwinscroll_topline2 fails on MacOS * heap-use-after-free and stack-use-after-scope with :14verbose * no digraph for &quot;Approaches the limit&quot; * not possible to use plural forms with gettext() * too many strlen() calls in userfunc.c * terminal: E315 when dragging the terminal with the mouse * runtime(openPlugin): fix unclosed parenthesis in GetWordUnderCursor() * runtime(doc): Tweak documentation style a bit * tests: test_glvs fails when unarchiver not available * Vim always enables 'termguicolors' in a terminal * completion: input text deleted with preinsert when adding leader * translation(sr): Missing Serbian translation for the tutor * Superfluous cleanup steps in test_ins_complete.vim * runtime(netrw): correct wrong version check * Vim doesn't highlight to be inserted text when completing * runtime(netrw): upstream snapshot of v176 * runtime(dist/vim9): fix regressions in dist#vim9#Open * runtime(hyprlang): fix string recognition * make install fails because of a missing dependency * runtime(asm): add byte directives to syntax script * Vim doesn't work well with TERM=xterm-direct * runtime(filetype): commit 99181205c5f8284a3 breaks V lang detection * runtime: decouple Open and Launch commands and gx mapping from netrw * &quot;nosort&quot; enables fuzzy filtering even if &quot;fuzzy&quot; isn't in 'completeopt' * runtime(just): fix typo in syntax file * runtime(filetype): Improve Verilog detection by checking for modules definition * tests: off-by-one error in CheckCWD in test_debugger.vim * tests: no support for env variables when running Vim in terminal * too many strlen() calls in os_unix.c * insert-completed items are always sorted * crash after scrolling and pasting in silent Ex mode * Makefiles uses non-portable syntax * fuzzymatching doesn't prefer matching camelcase * filetype: N-Tripels and TriG files are not recognized * Vim9: Patch 9.1.1014 causes regressions * translation(sr): Update Serbian messages translation - updade to 9.1.1043 * [security]: segfault in win_line() * update helptags * filetype: just files are not recognized * Update base-syntax, match ternary and falsy operators * Vim9: out-of-bound access when echoing an enum * Vim9: imported type cannot be used as func return type * runtime(kconfig): updated ftplugin and syntax script * runtime(doc): rename last t_BG reference to t_RB * Vim9: comments are outdated * tests: test_channel.py fails with IPv6 * runtime(vim): Update base-syntax, fix is/isnot operator matching * Vim9: confusing error when using abstract method via super * make install fails when using shadowdir * Vim9: memory leak with blob2str() * runtime(tex): add texEmphStyle to texMatchGroup in syntax script * runtime(netrw): upstream snapshot of v175 * Vim9: compiling abstract method fails without return * runtime(c): add new constexpr keyword to syntax file (C23) * tests: shaderslang was removed from test_filetype erroneously * link error when FEAT_SPELL not defined * Coverity complains about insecure data handling * runtime(sh): update syntax script * runtime(c): Add missing syntax test files * filetype: setting bash filetype is backwards incompatible * runtime(c): Update syntax and ftplugin files * the installer can be improved * too many strlen() calls in screen.c * no sanitize check when running linematch * filetype: swc configuration files are not recognized * runtime(netrw): change netrw maintainer * wrong return type of blob2str() * blob2str/str2blob() do not support list of strings * runtime(doc): fix typo in usr_02.txt * Coverity complains about dereferencing NULL pointer * linematch option value not completed * string might be used without a trailing NUL * no way to get current selected item in a async context * filetype: fd ignore files are not recognized * v9.1.0743 causes regression with diff mode * runtime(doc): fix base64 encode/decode examples * Vim9: Patch 9.1.1013 causes a few problems * Not possible to convert string2blob and blob2string * Coverity complains about dereferencing NULL value * Vim9: variable not found in transitive import * runtime(colors): Update colorschemes, include new unokai colorscheme * Vim9: Regression caused by patch v9.1.0646 * runtime(lyrics): support milliseconds in syntax script * runtime(vim): Split Vim legacy and Vim9 script indent tests * Vim9: class interface inheritance not correctly working * popupmenu internal error with some abbr in completion item * filetype: VisualCode setting file not recognized * diff feature can be improved * tests: test for patch 9.1.1006 doesn't fail without the patch * filetype: various ignore are not recognized * tests: Load screendump files with &quot;git vimdumps&quot; * PmenuMatch completion highlight can be combined * completion text is highlighted even with no pattern found * tests: a few termdebug tests are flaky * [security]: heap-buffer-overflow with visual mode * runtime(doc): add package-&lt;name&gt; helptags for included packages * Vim9: unknown func error with interface declaring func var * runtime(filetype): don't detect string interpolation as angular * ComplMatchIns highlight hard to read on light background * runtime(vim): Update base-syntax, highlight literal string quote escape * runtime(editorconfig): set omnifunc to syntaxcomplete func * tests: ruby tests fail with Ruby 3.4 * Vim9: leaking finished exception * runtime(tiasm): use correct syntax name tiasm in syntax script * filetype: TI assembly files are not recognized * too many strlen() calls in drawscreen.c * runtime(xf86conf): add section name OutputClass to syntax script * ComplMatchIns may highlight wrong text * runtime(vim): Update base-syntax, improve ex-bang matching * runtime(doc): clarify buffer deletion on popup_close() * filetype: shaderslang files are not detected * Vim9: not able to use comment after opening curly brace - update to 9.1.0993 * 9.1.0993: New 'cmdheight' behavior may be surprising * runtime(sh): fix typo in Last Change header * 9.1.0992: Vim9: double-free after v9.1.0988 * 9.1.0991: v:stacktrace has wrong type in Vim9 script * runtime(sh): add PS0 to bashSpecialVariables in syntax script * runtime(vim): Remove trailing comma from match_words * runtime(zsh): sync syntax script with upstream repo * runtime(doc): Capitalise the mnemonic &quot;Zero&quot; for the 'z' flag of search() * 9.1.0990: Inconsistent behavior when changing cmdheight * 9.1.0989: Vim9: Whitespace after the final enum value causes a syntax error * runtime(java): Quietly opt out for unsupported markdown.vim versions * runtime(vim): fix failing vim syntax test * 9.1.0988: Vim9: no error when using uninitialized var in new() * runtime(doc): update index.txt * 9.1.0987: filetype: cake files are not recognized * 9.1.0986: filetype: 'jj' filetype is a bit imprecise * runtime(jj): Support diffs in jj syntax * runtime(vim): Update matchit pattern, no Vim9 short names * 9.1.0985: Vim9: some ex commands can be shortened * 9.1.0984: exception handling can be improved * runtime(doc): update doc for :horizontal * runtime(doc): update index.txt, windows.txt and version9.txt * runtime(doc): Tweak documentation about base64 function * runtime(chordpro): update syntax script * 9.1.0983: not able to get the displayed items in complete_info() * runtime(doc): use standard SGR format at :h xterm-true-color * 9.1.0982: TI linker files are not recognized * runtime(vim): update vim generator syntax script * 9.1.0981: tests: typo in test_filetype.vim * 9.1.0980: no support for base64 en-/decoding functions in Vim Script * syntax(sh): Improve the recognition of bracket expressions * runtime(doc): mention how NUL bytes are handled * 9.1.0979: VMS: type warning with $XDG_VIMRC_FILE * 9.1.0978: GUI tests sometimes fail when setting 'scroll' options * 9.1.0977: filetype: msbuild filetypes are not recognized * 9.1.0976: Vim9: missing return statement with throw * 9.1.0975: Vim9: interpolated string expr not working in object methods * 9.1.0974: typo in change of commit v9.1.0873 * 9.1.0973: too many strlen() calls in fileio.c * runtime(sh): set shellcheck as the compiler for supported shells * runtime(doc): Fix enum example syntax * 9.1.0972: filetype: TI linker map files are not recognized * runtime(vim): Improve syntax script generator for Vim Script * 9.1.0971: filetype: SLNX files are not recognized * 9.1.0970: VMS: build errors on VMS architecture * runtime(doc): Fix documentation typos * runtime(doc): update for new keyprotocol option value (after v9.1.0969) * 9.1.0969: ghostty not using kitty protocol by default * 9.1.0968: tests: GetFileNameChecks() isn't fully sorted by filetype name * runtime(doc): update version9.txt for bash filetype * runtime(netrw): update last change header for #16265 * runtime(doc): fix doc error in :r behaviour * 9.1.0967: SpotBugs compiler setup can be further improved * 9.1.0966: Vim9: :enum command can be shortened * runtime(compiler): include a basic bash syntax checker compiler * 9.1.0965: filetype: sh filetype set when detecting the use of bash * runtime(doc): clarify ARCH value for 32-bit in INSTALLpc.txt * 9.1.0963: fuzzy-matching does not prefer full match * 9.1.0962: filetype: bun.lock file is not recognized * runtime(vim): update indentation plugin for Vim script * runtime(doc): tweak documentation style in helphelp.txt * runtime(vim): Update base-syntax, allow parens in default arguments * runtime(doc): mention auto-format using clang-format for sound.c/sign.c * runtime(help): fix typo s/additional/arbitrary/ * runtime(help): Add better support for language annotation highlighting * 9.1.0961: filetype: TI gel files are not recognized * 9.1.0960: filetype: hy history files are not recognized * translation(fi): Fix typoes in Finish menu translation * 9.1.0959: Coverity complains about type conversion * runtime(vim): Use supported syntax in indent tests * 9.1.0958: filetype: supertux2 config files detected as lisp * 9.1.0956: completion may crash, completion highlight wrong with preview window * 9.1.0955: Vim9: vim9compile.c can be further improved * runtime(doc): move help tag E1182 * runtime(graphql): contribute vim-graphql to Vim core * 9.1.0954: popupmenu.c can be improved * 9.1.0953: filetype: APKBUILD files not correctly detected * 9.1.0952: Vim9: missing type checking for any type assignment * 9.1.0951: filetype: jshell files are not recognized * runtime(dockerfile): do not set commentstring in syntax script * 9.1.0950: filetype: fennelrc files are not recognized * runtime(netrw): do not double escape Vim special characters * git: ignore reformatting change of netrw plugin * runtime(netrw): more reformating #16248 * runtime(doc): Add a note about handling symbolic links in starting.txt * 9.1.0949: popups inconsistently shifted to the left * git: ignore reformatting change of netrw plugin * runtime(netrw): change indent size from 1 to 2 * 9.1.0948: Missing cmdline completion for :pbuffer * runtime(tutor): Reformat tutor1 * 9.1.0947: short-description * 9.1.0946: cross-compiling fails on osx-arm64 * 9.1.0945: ComplMatchIns highlight doesn't end after inserted text * translation(sv): re-include the change from #16240 * 9.1.0944: tests: test_registers fails when not run under X11 * 9.1.0943: Vim9: vim9compile.c can be further improved * runtime(doc): Update README and mention make check to verify * translation(sv): partly revert commit 98874dca6d0b60ccd6fc3a140b3ec * runtime(vim): update base-syntax after v9.1.0936 * 9.1.0942: a few typos were found * 9.1.0941: ComplMatchIns doesn't work after multibyte chars * runtime(doc): Fix style in fold.txt * translation(sv): Fix typo in Swedish translation * 9.1.0940: Wrong cursor shape with &quot;gq&quot; and 'indentexpr' executes :normal * runtime(doc): fix some small errors * 9.1.0939: make installtutor fails * 9.1.0938: exclusive selection not respected when re-selecting block mode * 9.1.0937: test_undolist() is flaky * 9.1.0936: cannot highlight completed text * 9.1.0935: SpotBugs compiler can be improved * 9.1.0934: hard to view an existing buffer in the preview window * runtime(doc): document how to minimize fold computation costs * 9.1.0933: Vim9: vim9compile.c can be further improved * 9.1.0932: new Italian tutor not installed * runtime(doc): fix a few minor errors from the last doc updates * translation(it): add Italian translation for the interactive tutor * runtime(doc): update the change.txt help file * runtime(help): Add Vim lang annotation support for codeblocks * 9.1.0931: ml_get error in terminal buffer * 9.1.0930: tests: test_terminal2 may hang in GUI mode * 9.1.0929: filetype: lalrpop files are not recognized * 9.1.0928: tests: test_popupwin fails because the filter command fails * editorconfig: set trim_trailing_whitespace = false for src/testdir/test*.vim * 9.1.0927: style issues in insexpand.c * 9.1.0926: filetype: Pixi lock files are not recognized * runtime(doc): Add a reference to |++opt| and |+cmd| at `:h :pedit` * runtime(doc): add a note about inclusive motions and exclusive selection * 9.1.0925: Vim9: expression compiled when not necessary * 9.1.0924: patch 9.1.0923 causes issues * 9.1.0923: too many strlen() calls in filepath.c * 9.1.0923: wrong MIN macro in popupmenu.c * 9.1.0921: popupmenu logic is a bit convoluted * 9.1.0920: Vim9: compile_assignment() too long * 9.1.0919: filetype: some assembler files are not recognized * runtime(netrw): do not pollute search history with symlinks * 9.1.0918: tiny Vim crashes with fuzzy buffer completion * 9.1.0917: various vartabstop and shiftround bugs when shifting lines * runtime(typst): add definition lists to formatlistpat, update maintainer * 9.1.0916: messages.c is exceeding 80 columns * runtime(proto): include filetype plugin for protobuf * 9.1.0915: GVim: default font size a bit too small * 9.1.0914: Vim9: compile_assignment() is too long * 9.1.0913: no error check for neg values for 'messagesopt' * runtime(netrw): only check first arg of netrw_browsex_viewer for being executable * 9.1.0912: xxd: integer overflow with sparse files and -autoskip * 9.1.0911: Variable name for 'messagesopt' doesn't match short name * 9.1.0910: 'messagesopt' does not check max wait time * runtime(doc): update wrong Vietnamese localization tag * 9.1.0909: Vim9: crash when calling instance method - update to 9.1.0908 * refresh vim-7.3-mktemp_tutor.patch * 9.1.0908: not possible to configure :messages * 9.1.0907: printoptions:portrait does not change postscript Orientation * runtime(doc): Add vietnamese.txt to helps main TOC * 9.1.0906: filetype: Nvidia PTX files are not recognized * runtime(doc): updated version9.txt with changes from v9.1.0905 * 9.1.0905: Missing information in CompleteDone event * 9.1.0904: Vim9: copy-paste error in class_defining_member() * 9.1.0903: potential overflow in spell_soundfold_wsal() * runtime(netrw): do not detach when launching external programs in gvim * runtime(doc): make tag alignment more consistent in filetype.txt * runtime(doc): fix wrong syntax and style of vietnamese.txt * translation(it): update Italian manpage for vimtutor * runtime(lua): add optional lua function folding * Filelist: include translations for Chapter 2 tutor * translation(vi): Update Vietnamese translation * runtime(doc): include vietnamese.txt * runtime(tutor): fix another typo in tutor2 * runtime(doc): fix typo in vimtutor manpage * translation(it): update Italian manpage for vimtutor * translation(it): include Italian version of tutor chapter 2 * runtime(tutor): regenerated some translated tutor1 files * runtime(tutor): fix typo in Chapter 2 * 9.1.0902: filetype: Conda configuration files are not recognized * runtime(doc): Tweak documentation style a bit * runtime(tutor): update the tutor files and re-number the chapters * runtime(tutor): Update the makefiles for tutor1 and tutor2 files * 9.1.0901: MS-Windows: vimtutor batch script can be improved * runtime(doc): remove buffer-local completeopt todo item * 9.1.0900: Vim9: digraph_getlist() does not accept bool arg * runtime(typst): provide a formatlistpat in ftplugin * runtime(doc): Update documentation for &quot;noselect&quot; in 'completeopt' * 9.1.0899: default for 'backspace' can be set in C code * runtime(helptoc): reload cached g:helptoc.shell_prompt when starting toc * translation(ru): Updated messages translation * 9.1.0898: runtime(compiler): pytest compiler not included * 9.1.0897: filetype: pyrex files are not detected * runtime(compiler): update eslint compiler * 9.1.0896: completion list wrong after v9.1.0891 * runtime(doc): document changed default value for 'history' * 9.1.0895: default history value is too small * 9.1.0894: No test for what the spotbug compiler parses * 9.1.0893: No test that undofile format does not regress * translation(de): update German manpages * runtime(compiler): include spotbugs Java linter * 9.1.0892: the max value of 'tabheight' is limited by other tabpages * runtime(po): remove poDiffOld/New, add po-format flags to syntax file * 9.1.0891: building the completion list array is inefficient * patch 9.1.0890: %! item not allowed for 'rulerformat' * runtime(gzip): load undofile if there exists one * 9.1.0889: Possible unnecessary redraw after adding/deleting lines * 9.1.0888: leftcol property not available in getwininfo() * 9.1.0887: Wrong expression in sign.c * 9.1.0886: filetype: debian control file not detected * runtime(c3): include c3 filetype plugin * 9.1.0885: style of sign.c can be improved * 9.1.0884: gcc warns about uninitialized variable * runtime(apache): Update syntax directives for apache server 2.4.62 * translation(ru): updated vimtutor translation, update MAINTAINERS file * 9.1.0883: message history cleanup is missing some tests * runtime(doc): Expand docs on :! vs. :term * runtime(netrw): Fixing powershell execution issues on Windows * 9.1.0882: too many strlen() calls in insexpand.c * 9.1.0881: GUI: message dialog may not get focus * runtime(netrw): update netrw's decompress logic * runtime(apache): Update syntax keyword definition * runtime(misc): add Italian LICENSE and (top-level) README file * 9.1.0880: filetype: C3 files are not recognized * runtime(doc): add helptag for :HelpToc command * 9.1.0879: source is not consistently formatted * Add clang-format config file * runtime(compiler): fix escaping of arguments passed to :CompilerSet * 9.1.0878: termdebug: cannot enable DEBUG mode * 9.1.0877: tests: missing test for termdebug + decimal signs * 9.1.0876: filetype: openCL files are not recognized * 9.1.0875: filetype: hyprlang detection can be improved * 9.1.0874: filetype: karel files are not detected * 9.1.0873: filetype: Vivado files are not recognized * 9.1.0872: No test for W23 message * 9.1.0871: getcellpixels() can be further improved * 9.1.0870: too many strlen() calls in eval.c * 9.1.0869: Problem: curswant not set on gm in folded line * 9.1.0868: the warning about missing clipboard can be improved * runtime(doc): Makefile does not clean up all temporary files * 9.1.0867: ins_compl_add() has too many args * editorconfig: don't trim trailing whitespaces in runtime/doc * translation(am): Remove duplicate keys in desktop files * runtime(doc): update helptags * runtime(filetype): remove duplicated *.org file pattern * runtime(cfg): only consider leading // as starting a comment * 9.1.0866: filetype: LLVM IR files are not recognized * 9.1.0865: filetype: org files are not recognized * 9.1.0864: message history is fixed to 200 * 9.1.0863: getcellpixels() can be further improved * runtime(sh): better function support for bash/zsh in indent script * runtime(netrw): small fixes to netrw#BrowseX * 9.1.0862: 'wildmenu' not enabled by default in nocp mode * runtime(doc): update how to report issues for mac Vim * runtime(doc): mention option-backslash at :h CompilerSet * runtime(compiler): include a Java Maven compiler plugin * runtime(racket): update Racket runtime files * runtime(doc): improve indentation in examples for netrw-handler * runtime(doc): improve examples for netrw-handler functions * runtime(idris2): include filetype,indent+syntax plugins for (L)Idris2 + ipkg * runtime(doc): clarify the use of filters and external commands * 9.1.0861: Vim9: no runtime check for object member access of any var * runtime(compiler): update pylint linter * 9.1.0860: tests: mouse_shape tests use hard code sleep value * 9.1.0859: several problems with the GLVS plugin * 9.1.0858: Coverity complains about dead code * runtime(tar): Update tar.vim to support permissions * 9.1.0857: xxd: --- is incorrectly recognized as end-of-options * 9.1.0851: too many strlen() calls in getchar.c * 9.1.0850: Vim9: cannot access nested object inside objects * runtime(tex): extra Number highlighting causes issues * runtime(vim): Fix indent after :silent! function * 9.1.0849: there are a few typos in the source * runtime(netrw): directory symlink not resolved in tree view * runtime(doc): add a table of supported Operating Systems * runtime(tex): update Last Change header in syntax script * runtime(doc): fix typo in g:termdebug_config * runtime(vim): Update base-syntax, improve :normal highlighting * runtime(tex): add Number highlighting to syntax file * runtime(doc): Tweak documentation style a bit * 9.1.0848: if_lua: v:false/v:true are not evaluated to boolean * runtime(dune): use :setl instead of :set in ftplugin * runtime(termdebug): allow to use decimal signs * translation(it): Updated Italian vimtutor * runtime(compiler): improve cppcheck * git: git-blame-ignore-revs shown as an error on Github * 9.1.0847: tests: test_popupwin fails because of updated help file * 9.1.0846: debug symbols for xxd are not cleaned in Makefile * runtime(structurizr): Update structurizr syntax * runtime(8th): updated 8th syntax * runtime(doc): Add pi_tutor.txt to help TOC * runtime(compiler): add mypy and ruff compiler; update pylint linter * runtime(netrw): fix several bugs in netrw tree listing * runtime(netrw): prevent polluting the search history * 9.1.0845: vimtutor shell script can be improved * 9.1.0844: if_python: no way to pass local vars to python * 9.1.0843: too many strlen() calls in undo.c * runtime(doc): update default value for fillchars option * runtime(compiler): fix typo in cppcheck compiler plugin * runtime(doc): simplify vimtutor manpage a bit more * runtime(matchparen): Add matchparen_disable_cursor_hl config option * 9.1.0842: not checking for the sync() systemcall * 9.1.0841: tests: still preferring python2 over python3 * 9.1.0840: filetype: idris2 files are not recognized * 9.1.0839: filetype: leo files are not recognized * runtime(cook): include cook filetype plugin * runtime(debversions): Update Debian versions * patch 9.1.0838: vimtutor is bash-specific * runtime(doc): add help specific modeline to pi_tutor.txt * Filelist: vimtutor chapter 2 is missing in Filelist * 9.1.0837: cross-compiling has some issues * runtime(vimtutor): Add a second chapter - Provide latest 9.1.0836 release. - Fix for bsc#1230625 and bsc#1231846. - update to 9.1.0836 * 9.1.0836: The vimtutor can be improved * 9.1.0835: :setglobal doesn't work properly for 'ffu' and 'tsrfu' * 9.1.0834: tests: 2html test fails * 9.1.0833: CI: recent ASAN changes do not work for indent tests * 9.1.0832: :set doesn't work for 'cot' and 'bkc' after :setlocal * runtime(doc): update help-toc description * runtime(2html): Make links use color scheme colors in TOhtml * 9.1.0831: 'findexpr' can't be used as lambad or Funcref * Filelist: include helptoc package * runtime(doc): include a TOC Vim9 plugin * Filelist: ignore .git-blame-ignore-revs * 9.1.0830: using wrong highlight group for spaces for popupmenu * runtime(typst): synchronize updates from the upstream typst.vim * git: ignore reformatting commit for git-blame (after v9.1.0829) * 9.1.0829: Vim source code uses a mix of tabs and spaces * 9.1.0828: string_T struct could be used more often * 9.1.0827: CI: tests can be improved * runtime(doc): remove stray sentence in pi_netrw.txt * 9.1.0826: filetype: sway files are not recognized * runtime(doc): Include netrw-gp in TOC * runtime(doc): mention 'iskeyword' at :h charclass() * runtime(doc): update help tags * 9.1.0825: compile error for non-diff builds * runtime(netrw): fix E874 when browsing remote directory which contains `~` character * runtime(doc): update coding style documentation * runtime(debversions): Add plucky (25.04) as Ubuntu release name * 9.1.0824: too many strlen() calls in register.c * 9.1.0823: filetype: Zephyr overlay files not recognized * runtime(doc): Clean up minor formatting issues for builtin functions * runtime(netrw): make :Launch/Open autoloadable * runtime(netrw): fix regression with x mapping on Cygwin * runtime(netrw): fix filetype detection for remote files * 9.1.0822: topline might be changed in diff mode unexpectedly * CI: huge linux builds should also run syntax &amp; indent tests * 9.1.0821: 'findexpr' completion doesn't set v:fname to cmdline argument * 9.1.0820: tests: Mac OS tests are too flaky * runtime(awk): Highlight more awk comments in syntax script * runtime(netrw): add missing change for s:redir() * 9.1.0819: tests: using findexpr and imported func not tested * runtime(netrw): improve netrw's open-handling further * runtime(netrw): fix syntax error in netrwPlugin.vim * runtime(netrw): simplify gx file handling * 9.1.0818: some global functions are only used in single files * 9.1.0817: termdebug: cannot evaluate expr in a popup * runtime(defaults): Detect putty terminal and switch to dark background * 9.1.0816: tests: not clear what tests cause asan failures * runtime(doc): Remove some completed items from todo.txt * 9.1.0815: &quot;above&quot; virtual text causes wrong 'colorcolumn' position * runtime(syntax-tests): tiny vim fails because of line-continuation * 9.1.0814: mapset() may remove unrelated mapping * 9.1.0813: no error handling with setglobal and number types * 9.1.0812: Coverity warns about dereferencing NULL ptr * 9.1.0811: :find expansion does not consider 'findexpr' * 9.1.0810: cannot easily adjust the |:find| command * 9.1.0809: filetype: petalinux config files not recognized * 9.1.0808: Terminal scrollback doesn't shrink when decreasing 'termwinscroll' * 9.1.0807: tests: having 'nolist' in modelines isn't always desired * 9.1.0806: tests: no error check when setting global 'briopt' * 9.1.0805: tests: minor issues in gen_opt_test.vim * 9.1.0804: tests: no error check when setting global 'cc' * 9.1.0803: tests: no error check when setting global 'isk' * 9.1.0802: tests: no error check when setting global 'fdm' to empty value * 9.1.0801: tests: no error check when setting global 'termwinkey' * 9.1.0800: tests: no error check when setting global 'termwinsize' * runtime(doc): :ownsyntax also resets 'spelloptions' * 9.1.0799: tests: gettwinvar()/gettabwinvar() tests are not comprehensive * runtime(doc): Fix wrong Mac default options * 9.1.0798: too many strlen() calls in cmdhist.c * 9.1.0797: testing of options can be further improved * 9.1.0796: filetype: libtool files are not recognized * (typst): add folding to typst ftplugin * runtime(netrw): deprecate and remove netrwFileHandlers#Invoke() * 9.1.0795: filetype: Vivado memory info file are not recognized * 9.1.0794: tests: tests may fail on Windows environment * runtime(doc): improve the :colorscheme documentation * 9.1.0793: xxd: -e does add one extra space * 9.1.0792: tests: Test_set_values() is not comprehensive enough * runtime(swayconfig): add flag for bindsym/bindcode to syntax script * 9.1.0791: tests: errors in gen_opt_test.vim are not shown * runtime(compiler): check for compile_commands in build dirs for cppcheck * 9.1.0790: Amiga: AmigaOS4 build should use default runtime (newlib) * runtime(help): Update help syntax * runtime(help): fix end of sentence highlight in code examples * runtime(jinja): Support jinja syntax as secondary filetype * 9.1.0789: tests: ':resize + 5' has invalid space after '+' * 9.1.0788: &lt;CSI&gt;27;&lt;mod&gt;u is not decoded to literal Escape in kitty/foot * 9.1.0787: cursor position changed when using hidden terminal * 9.1.0786: tests: quickfix update test does not test location list * runtime(doc): add some docs for file-watcher programs * CI: uploading failed screendumps still fails on Cirrus CI * 9.1.0785: cannot preserve error position when setting quickfix list * 9.1.0784: there are several problems with python 3.13 * 9.1.0783: 'spell' option setting has problems * 9.1.0782: tests: using wrong neomuttlog file name * runtime(doc): add preview flag to statusline example * 9.1.0781: tests: test_filetype fails * 9.1.0780: MS-Windows: incorrect Win32 error checking * 9.1.0779: filetype: neomuttlog files are not recognized * 9.1.0778: filetype: lf config files are not recognized * runtime(comment): fix commment toggle with mixed tabs &amp; spaces * runtime(misc): Use consistent &quot;Vim script&quot; spelling * runtime(gleam): add ftplugin for gleam files * runtime(doc): link help-writing from write-local-help * 9.1.0777: filetype: Some upstream php files are not recognized * runtime(java): Define javaBlockStart and javaBlockOtherStart hl groups * runtime(doc): mention conversion rules for remote_expr() * runtime(tutor): Fix missing :s command in spanish translation section 4.4 * 9.1.0776: test_strftime may fail because of missing TZ data * translation(am): Add Armenian language translation * 9.1.0775: tests: not enough tests for setting options * 9.1.0774: &quot;shellcmdline&quot; doesn't work with getcompletion() * 9.1.0773: filetype: some Apache files are not recognized * 9.1.0772: some missing changes from v9.1.0771 * 9.1.0771: completion attribute hl_group is confusing * 9.1.0770: current command line completion is a bit limited * 9.1.0769: filetype: MLIR files are not recognized * 9.1.0768: MS-Windows: incorrect cursor position when restoring screen * runtime(nasm): Update nasm syntax script * 9.1.0767: A condition is always true in ex_getln.c * runtime(skill): Update syntax file to fix string escapes * runtime(help): highlight CTRL-&lt;Key&gt; correctly * runtime(doc): add missing usr_52 entry to toc * 9.1.0766: too many strlen() calls in ex_getln.c * runtime(doc): correct `vi` registers 1-9 documentation error * 9.1.0765: No test for patches 6.2.418 and 7.3.489 * runtime(spec): set comments and commentstring options * NSIS: Include libgcc_s_sjlj-1.dll again * runtime(doc): clarify the effect of 'startofline' option * 9.1.0764: [security]: use-after-free when closing a buffer * runtime(vim): Update base-syntax file, improve class, enum and interface highlighting * 9.1.0763: tests: cannot run single syntax tests * 9.1.0762: 'cedit', 'termwinkey' and 'wildchar' may not be parsed correctly * 9.1.0761: :cd completion fails on Windows with backslash in path * 9.1.0760: tests: no error reported, if gen_opt_test.vim fails * 9.1.0759: screenpos() may return invalid position * runtime(misc): unset compiler in various ftplugins * runtime(doc): update formatting and syntax * runtime(compiler): add cppcheck linter compiler plugin * runtime(doc): Fix style in documents * runtime(doc): Fix to two-space convention in user manual * runtime(comment): consider &amp;tabstop in lines after whitespace indent * 9.1.0758: it's possible to set an invalid key to 'wildcharm' * runtime(java): Manage circularity for every :syn-included syntax file * 9.1.0757: tests: messages files contains ANSI escape sequences * 9.1.0756: missing change from patch v9.1.0754 * 9.1.0755: quickfix list does not handle hardlinks well * runtime(doc): 'filetype', 'syntax' and 'keymap' only allow alphanumeric + some characters * runtime(systemd): small fixes to &amp;keywordprg in ftplugin * CI: macos-12 runner is being sunset, switch to 13 * 9.1.0754: fixed order of items in insert-mode completion menu * runtime(comment): commenting might be off by one column * 9.1.0753: Wrong display when typing in diff mode with 'smoothscroll' * 9.1.0752: can set 'cedit' to an invalid value * runtime(doc): add `usr` tag to usr_toc.txt * 9.1.0751: Error callback for term_start() not used * 9.1.0750: there are some Win9x legacy references * runtime(java): Recognise the CommonMark form (///) of Javadoc comments * 9.1.0749: filetype: http files not recognized * runtime(comment): fix syntax error * CI: uploading failed screendump tests does not work Cirrus * 9.1.0748: :keep* commmands are sometimes misidentified as :k * runtime(indent): allow matching negative numbers for gnu indent config file * runtime(comment): add gC mapping to (un)comment rest of line * 9.1.0747: various typos in repo found * 9.1.0746: tests: Test_halfpage_longline() fails on large terminals * runtime(doc): reformat gnat example * runtime(doc): reformat ada_standard_types section * 9.1.0745: filetype: bun and deno history files not recognized * runtime(glvs): Correct the tag name of glvs-autoinstal * runtime(doc): include short form for :earlier/:later * runtime(doc): remove completed TODO * 9.1.0744: filetype: notmuch configs are not recognised * 9.1.0743: diff mode does not handle overlapping diffs correctly * runtime(glvs): fix a few issues * runtime(doc): Fix typo in :help :command-modifiers * 9.1.0742: getcmdprompt() implementation can be improved * runtime(docs): update `:set?` command behavior table * runtime(doc): update vim90 to vim91 in docs * runtime(doc): fix typo in :h dos-colors * 9.1.0741: No way to get prompt for input()/confirm() * runtime(doc): fix typo in version9.txt nrformat -&gt; nrformats * runtime(rmd,rrst): 'fex' option not properly restored * runtime(netrw): remove extraneous closing bracket * 9.1.0740: incorrect internal diff with empty file * 9.1.0739: [security]: use-after-free in ex_getln.c * runtime(filetype): tests: Test_filetype_detection() fails * runtime(dist): do not output a message if executable is not found * 9.1.0738: filetype: rapid files are not recognized * runtime(modconf): remove erroneous :endif in ftplugin * runtime(lyrics): support multiple timestamps in syntax script * runtime(java): Optionally recognise _module_ import declarations * runtime(vim): Update base-syntax, improve folding function matches * CI: upload failed screendump tests also for Cirrus * 9.1.0737: tests: screendump tests may require a bit more time * runtime(misc): simplify keywordprg in various ftplugins * runtime(java): Optionally recognise all primitive constants in _switch-case_ labels * runtime(zsh,sh): set and unset compiler in ftplugin * runtime(netrw): using inefficient highlight pattern for 'mf' * 9.1.0736: Unicode tables are outdated * 9.1.0735: filetype: salt files are not recognized * 9.1.0734: filetype: jinja files are not recognized * runtime(zathurarc): add double-click-follow to syntax script * translation(ru): Updated messages translation * translation(it): updated xxd man page * translation(ru): updated xxd man page * 9.1.0733: keyword completion does not work with fuzzy * 9.1.0732: xxd: cannot use -b and -i together * runtime(java): Highlight javaConceptKind modifiers with StorageClass * runtime(doc): reword and reformat how to use defaults.vim * 9.1.0731: inconsistent case sensitive extension matching * runtime(vim): Update base-syntax, match Vim9 bool/null literal args to :if/:while/:return * runtime(netrw): delete confirmation not strict enough * 9.1.0730: Crash with cursor-screenline and narrow window * 9.1.0729: Wrong cursor-screenline when resizing window * 9.1.0728: [security]: heap-use-after-free in garbage collection with location list user data * runtime(doc): clarify the effect of the timeout for search()-functions * runtime(idlang): update syntax script * runtime(spec): Recognize epoch when making spec changelog in ftplugin * runtime(spec): add file triggers to syntax script * 9.1.0727: too many strlen() calls in option.c * runtime(make): add compiler/make.vim to reset compiler plugin settings * runtime(java): Recognise all available standard doclet tags * 9.1.0726: not using correct python3 API with dynamic linking * runtime(dosini): Update syntax script, spellcheck comments only * runtime(doc): Revert outdated comment in completeopt's fuzzy documentation * 9.1.0725: filetype: swiftinterface files are not recognized * runtime(pandoc): Update compiler plugin to use actual 'spelllang' * runtime(groff): Add compiler plugin for groff * 9.1.0724: if_python: link error with python 3.13 and stable ABI * 9.1.0723: if_python: dynamic linking fails with python3 &gt;= 3.13 * 9.1.0722: crash with large id in text_prop interface * 9.1.0721: tests: test_mksession does not consider XDG_CONFIG_HOME * runtime(glvs): update GetLatestVimScripts plugin * runtime(doc): Fix typo in :help :hide text * runtime(doc): buffers can be re-used * 9.1.0720: Wrong breakindentopt=list:-1 with multibyte or TABs * 9.1.0719: Resetting cell widths can make 'listchars' or 'fillchars' invalid * runtime(doc): Update version9.txt and mention $MYVIMDIR - Update to 9.1.0718: * v9.1.0718: hard to know the users personal Vim Runtime Directory * v9.1.0717: Unnecessary nextcmd NULL checks in parse_command_modifiers() Maintainers: fix typo in author name * v9.1.0716: resetting setcellwidth( doesn't update the screen runtime(hcl,terraform): Add runtime files for HCL and Terraform runtime(tmux): Update syntax script * v9.1.0715: Not correctly parsing color names (after v9.1.0709) * v9.1.0714: GuiEnter_Turkish test may fail * v9.1.0713: Newline causes E749 in Ex mode * v9.1.0712: missing dependency of Test_gettext_makefile * v9.1.0711: test_xxd may file when using different xxd * v9.1.0710: popup window may hide part of Command line runtime(vim): Update syntax, improve user-command matching * v9.1.0709: GUIEnter event not found in Turkish locale runtime(sudoers): improve recognized Runas_Spec and Tag_Spec items * v9.1.0708: Recursive window update does not account for reset skipcol runtime(nu): include filetype plugin * v9.1.0707: invalid cursor position may cause a crash * v9.1.0706: test_gettext fails when using shadow dir CI: Install locales-all package * v9.1.0705: Sorting of fuzzy filename completion is not stable translation(pt): update Portuguese/Brazilian menu translation runtime(vim): Update base-syntax, match bracket mark ranges runtime(doc): Update :help :command-complete list * v9.1.0704: inserting with a count is inefficient runtime(doc): use mkdir -p to save a command * v9.1.0703: crash with 2byte encoding and glob2regpat() runtime(hollywood): update syn highlight for If-Then statements and For-In-Loops * v9.1.0702: Patch 9.1.0700 broke CI * v9.1.0701: crash with NFA regex engine when searching for composing chars * v9.1.0700: crash with 2byte encoding and glob2regpat() * v9.1.0699: &quot;dvgo&quot; is not always an inclusive motion runtime(java): Provide support for syntax preview features * v9.1.0698: &quot;Untitled&quot; file not removed when running Test_crash1_3 alone * v9.1.0697: heap-buffer-overflow in ins_typebuf * v9.1.0696: installing runtime files fails when using SHADOWDIR runtime(doc): fix typo * v9.1.0695: test_crash leaves Untitled file around translation(br): Update Brazilian translation translation(pt): Update menu_pt_br * v9.1.0694: matchparen is slow on a long line * v9.1.0693: Configure doesn't show result when not using python3 stable abi * v9.1.0692: Wrong patlen value in ex_substitute() * v9.1.0691: stable-abi may cause segfault on Python 3.11 runtime(vim): Update base-syntax, match :loadkeymap after colon and bar runtime(mane): Improve &lt;Plug&gt;ManBS mapping * v9.1.0690: cannot set special highlight kind in popupmenu translation(pt): Revert and fix wrong Portuguese menu translation files translation(pt): revert Portuguese menu translation translation(br): Update Brazilian translations runtime(vim): Update base-syntax, improve :let-heredoc highlighting * v9.1.0689: buffer-overflow in do_search( with 'rightleft' runtime(vim): Improve heredoc handling for all embedded scripts * v9.1.0688: dereferences NULL pointer in check_type_is_value() * v9.1.0687: Makefile may not install desktop files runtime(man): Fix &lt;Plug&gt;ManBS runtime(java): Make the bundled &amp;foldtext function optional runtime(netrw): Change line on `mx` if command output exists runtime(netrw): Fix `mf`-selected entry highlighting runtime(htmlangular): add html syntax highlighting translation(it): Fix filemode of Italian manpages runtime(doc): Update outdated man.vim plugin information runtime(zip): simplify condition to detect MS-Windows * v9.1.0686: zip-plugin has problems with special characters runtime(pandoc): escape quotes in &amp;errorformat for pandoc translation(it): updated Italian manpage * v9.1.0685: too many strlen( calls in usercmd.c runtime(doc): fix grammar in :h :keeppatterns runtime(pandoc): refine pandoc compiler settings * v9.1.0684: completion is inserted on Enter with &quot;noselect&quot; translation(ru): update man pages * v9.1.0683: mode( returns wrong value with &lt;Cmd&gt; mapping runtime(doc): remove trailing whitespace in cmdline.txt * v9.1.0682: Segfault with uninitialized funcref * v9.1.0681: Analyzing failed screendumps is hard runtime(doc): more clarification for the :keeppatterns needed * v9.1.0680: VMS does not have defined uintptr_t runtime(doc): improve typedchar documentation for KeyInputPre autocmd runtime(dist): verify that executable is in $PATH translation(it): update Italian manpages runtime(doc): clarify the effect of :keeppatterns after * v9.1.0677 runtime(doc): update Makefile and make it portable between GNU and BSD * v9.1.0679: Rename from w_closing to w_locked is incomplete runtime(colors): update colorschemes runtime(vim): Update base-syntax, improve :let-heredoc highlighting runtime(doc): Updating the examples in the xxd manpage translation(ru): Updated uganda.rux runtime(yaml): do not re-indent when commenting out lines * v9.1.0678: use-after-free in alist_add() * v9.1.0677 :keepp does not retain the substitute pattern translation(ja): Update Japanese translations to latest release runtime(netrw): Drop committed trace lines runtime(netrw): Error popup not always used runtime(netrw): ErrorMsg( may throw E121 runtime(tutor): update Makefile and make it portable between GNU and BSD translation: improve the po/cleanup.vim script runtime(lang): update Makefile and make it portable between GNU and BSD * v9.1.0676: style issues with man pages * v9.1.0675: Patch v9.1.0674 causes problems runtime(dosbatch): Show %%i as an argument in syntax file runtime(dosbatch): Add syn-sync to syntax file runtime(sql, mysql): fix E169: Command too recursive with sql_type_default = &quot;mysql&quot; * v9.1.0674: compiling abstract method fails because of missing return runtime(javascript): fix a few issues with syntax higlighting runtime(mediawiki): fix typo in doc, test for b:did_ftplugin var runtime(termdebug): Fix wrong test for balloon feature runtime(doc): Remove mentioning of the voting feature runtime(doc): add help tags for json + markdown global variables * v9.1.0673: too recursive func calls when calling super-class method runtime(syntax-tests): Facilitate the viewing of rendered screendumps runtime(doc): fix a few style issues * v9.1.0672: marker folds may get corrupted on undo * v9.1.0671 Problem: crash with WinNewPre autocommand * v9.1.0670: po file encoding fails on *BSD during make translation(it): Update Italian translation translation: Stop using msgconv * v9.1.0669: stable python ABI not used by default Update .gitignore and .hgignore files * v9.1.0668: build-error with python3.12 and stable ABI translations: Update generated po files * v9.1.0667: Some other options reset curswant unnecessarily when set * v9.1.0666: assert_equal( doesn't show multibyte string correctly runtime(doc): clarify directory of Vim's executable vs CWD * v9.1.0665 :for loop runtime(proto): Add indent script for protobuf filetype * v9.1.0664: console vim did not switch back to main screen on exit runtime(zip): zip plugin does not work with Vim 9.0 * v9.1.0663: zip test still resets 'shellslash' option runtime(zip): use defer to restore old settings runtime(zip): add a generic Message function runtime(zip): increment base version of zip plugin runtime(zip): raise minimum Vim version to * v9.0 runtime(zip): refactor save and restore of options runtime(zip): remove test for fnameescape runtime(zip): use :echomsg instead of :echo runtime(zip): clean up and remove comments * v9.1.0662: filecopy( may return wrong value when readlink( fails * v9.1.0661: the zip plugin is not tested. runtime(zip): Fix for FreeBSD's unzip command runtime(doc): capitalize correctly * v9.1.0660: Shift-Insert does work on old conhost translation(it): update Italian manpage runtime(lua): add/subtract a 'shiftwidth' after '('/')' in indentexpr runtime(zip): escape '[' on Unix as well * v9.1.0659: MSVC Makefile is a bit hard to read runtime(doc): fix typo in syntax.txt runtime(doc): -x is only available when compiled with crypt feature * v9.1.0658: Coverity warns about dereferencing NULL pointer. runtime(colors): update Todo highlight in habamax colorscheme * v9.1.0657: MSVC build time can be optimized * v9.1.0656: MSVC Makefile CPU handling can be improved * v9.1.0655: goaccess config file not recognized CI: update clang compiler to version 20 runtime(netrw): honor `g:netrw_alt{o,v}` for `:{S,H,V}explore` * v9.1.0654: completion does not respect completeslash with fuzzy * v9.1.0653: Patch v9.1.0648 not completely right * v9.1.0652: too many strlen( calls in syntax.c * v9.1.0651 :append * v9.1.0650: Coverity warning in cstrncmp() * v9.1.0649: Wrong comment for &quot;len&quot; argument of call_simple_func() * v9.1.0648: [security] double-free in dialog_changed() * v9.1.0647: [security] use-after-free in tagstack_clear_entry runtime(doc): re-format tag example lines, mention ctags --list-kinds * v9.1.0646: imported function may not be found runtime(java): Document &quot;g:java_space_errors&quot; and &quot;g:java_comment_strings&quot; runtime(java): Cluster optional group definitions and their group links runtime(java): Tidy up the syntax file runtime(java): Tidy up the documentation for &quot;ft-java-syntax&quot; runtime(colors): update habamax scheme - tweak diff/search/todo colors runtime(nohlsearch): add missing loaded_hlsearch guard runtime(kivy): Updated maintainer info for syntax script Maintainers: Add maintainer for ondir ftplugin + syntax files runtime(netrw): removing trailing slash when copying files in same directory * v9.1.0645: wrong match when searching multi-byte char case-insensitive runtime(html): update syntax script to sync by 250 minlines by default * v9.1.0644: Unnecessary STRLEN( when applying mapping runtime(zip): Opening a remote zipfile don't work runtime(cuda): source c and cpp ftplugins * v9.1.0643: cursor may end up on invalid position * v9.1.0642: Check that mapping rhs starts with lhs fails if not simplified * v9.1.0641: OLE enabled in console version runtime(thrift): add ftplugin, indent and syntax scripts * v9.1.0640: Makefile can be improved * v9.1.0639: channel timeout may wrap around * v9.1.0638: E1510 may happen when formatting a message for smsg() * v9.1.0637: Style issues in MSVC Makefile - Update apparmor.vim to latest version (from AppArmor 4.0.2) - add support for &quot;all&quot; and &quot;userns&quot; rules, and new profile flags - Update to 9.1.0636: * 9.1.0636: filetype: ziggy files are not recognized * 9.1.0635: filetype: SuperHTML template files not recognized * 9.1.0634: Ctrl-P not working by default * 9.1.0633: Compilation warnings with `-Wunused-parameter` * 9.1.0632: MS-Windows: Compiler Warnings Add support for Files-Included in syntax script tweak documentation style a bit * 9.1.0631: wrong completion list displayed with non-existing dir + fuzzy completion * 9.1.0630: MS-Windows: build fails with VIMDLL and mzscheme * 9.1.0629: Rename of pum hl_group is incomplete * 9.1.0628: MinGW: coverage files are not cleaned up * 9.1.0627: MinGW: build-error when COVERAGE is enabled * 9.1.0626: Vim9: need more tests with null objects include initial filetype plugin * 9.1.0625: tests: test output all translated messages for all translations * 9.1.0624: ex command modifiers not found * 9.1.0623: Mingw: errors when trying to delete non-existing files * 9.1.0622: MS-Windows: mingw-build can be optimized * 9.1.0621: MS-Windows: startup code can be improved * 9.1.0620: Vim9: segfauls with null objects * 9.1.0619: tests: test_popup fails * 9.1.0618: cannot mark deprecated attributes in completion menu * 9.1.0617: Cursor moves beyond first line of folded end of buffer * 9.1.0616: filetype: Make syntax highlighting off for MS Makefiles * 9.1.0615: Unnecessary STRLEN() in make_percent_swname() Add single-line comment syntax Add syntax test for comments Update maintainer info * 9.1.0614: tests: screendump tests fail due to recent syntax changes * 9.1.0613: tests: termdebug test may fail and leave file around Update base-syntax, improve :set highlighting Optionally highlight the :: token for method references * 9.1.0612: filetype: deno.lock file not recognized Use delete() for deleting directory escape filename before trying to delete it * 9.1.0611: ambiguous mappings not correctly resolved with modifyOtherKeys correctly extract file from zip browser * 9.1.0610: filetype: OpenGL Shading Language files are not detected Fix endless recursion in netrw#Explore() * 9.1.0609: outdated comments in Makefile update syntax script Fix flow mapping key detection Remove orphaned YAML syntax dump files * 9.1.0608: Coverity warns about a few potential issues Update syntax script and remove syn sync * 9.1.0607: termdebug: uses inconsistent style * 9.1.0606: tests: generated files may cause failure in test_codestyle * 9.1.0605: internal error with fuzzy completion * 9.1.0604: popup_filter during Press Enter prompt seems to hang translation: Update Serbian messages translation * 9.1.0603: filetype: use correct extension for Dracula * 9.1.0602: filetype: Prolog detection can be improved fix more inconsistencies in assert function docs * 9.1.0601: Wrong cursor position with 'breakindent' when wide char doesn't fit Update base-syntax, improve :map highlighting * 9.1.0600: Unused function and unused error constants * 9.1.0599: Termdebug: still get E1023 when specifying arguments correct wrong comment options fix typo &quot;a xterm&quot; -&gt; &quot;an xterm&quot; * 9.1.0598: fuzzy completion does not work with default completion * 9.1.0597: KeyInputPre cannot get the (unmapped typed) key * 9.1.0596: filetype: devscripts config files are not recognized gdb file/folder check is now performed only in CWD. quote filename arguments using double quotes update syntax to SDC-standard 2.1 minor updates. Cleanup :match and :loadkeymap syntax test files Update base-syntax, match types in Vim9 variable declarations * 9.1.0595: make errors out with the po Makefile * 9.1.0594: Unnecessary redraw when setting 'winfixbuf' using wrong highlight for UTF-8 include simple syntax plugin * 9.1.0593: filetype: Asymptote files are not recognized add recommended indent options to ftplugin add recommended indent options to ftplugin add recommended indent options to ftplugin * 9.1.0592: filetype: Mediawiki files are not recognized * 9.1.0591: filetype: *.wl files are not recognized * 9.1.0590: Vim9: crash when accessing getregionpos() return value 'cpoptions': Include &quot;z&quot; in the documented default * 9.1.0589: vi: d{motion} and cw work differently than expected update included colorschemes grammar fixes in options.txt - Add &quot;Keywords&quot; to gvim.desktop to make searching for gvim easier - Removed patches, as they're no longer required (refreshing them deleted their contents): * vim-7.3-help_tags.patch * vim-7.4-highlight_fstab.patch - Reorganise all applied patches in the spec file. - Update to 9.1.0588: * 9.1.0588: The maze program no longer compiles on newer clang runtime(typst): Add typst runtime files * 9.1.0587: tests: Test_gui_lowlevel_keyevent is still flaky * 9.1.0586: ocaml runtime files are outdated runtime(termdebug): fix a few issues * 9.1.0585: tests: test_cpoptions leaves swapfiles around * 9.1.0584: Warning about redeclaring f_id() non-static runtime(doc): Add hint how to load termdebug from vimrc runtime(doc): document global insert behavior * 9.1.0583: filetype: *.pdf_tex files are not recognized * 9.1.0582: Printed line doesn't overwrite colon when pressing Enter in Ex mode * 9.1.0581: Various lines are indented inconsistently * 9.1.0580: :lmap mapping for keypad key not applied when typed in Select mode * 9.1.0579: Ex command is still executed after giving E1247 * 9.1.0578: no tests for :Tohtml * 9.1.0577: Unnecessary checks for v:sizeoflong in test_put.vim * 9.1.0576: tests: still an issue with test_gettext_make * 9.1.0575: Wrong comments in alt_tabpage() * 9.1.0574: ex: wrong handling of commands after bar runtime(doc): add a note for netrw bug reports * 9.1.0573: ex: no implicit print for single addresses runtime(vim): make &amp;indentexpr available from the outside * 9.1.0572: cannot specify tab page closing behaviour runtime(doc): remove obsolete Ex insert behavior * 9.1.0571: tests: Test_gui_lowlevel_keyevent is flaky runtime(logindefs): update syntax with new keywords * 9.1.0570: tests: test_gettext_make can be improved runtime(filetype): Fix Prolog file detection regex * 9.1.0569: fnamemodify() treats &quot;..&quot; and &quot;../&quot; differently runtime(mojo): include mojo ftplugin and indent script * 9.1.0568: Cannot expand paths from 'cdpath' setting * 9.1.0567: Cannot use relative paths as findfile() stop directories * 9.1.0566: Stop dir in findfile() doesn't work properly w/o trailing slash * 9.1.0565: Stop directory doesn't work properly in 'tags' * 9.1.0564: id() can be faster * 9.1.0563: Cannot process any Key event * 9.1.0562: tests: inconsistency in test_findfile.vim runtime(fstab): Add missing keywords to fstab syntax * 9.1.0561: netbeans: variable used un-initialized (Coverity) * 9.1.0560: bindtextdomain() does not indicate an error * 9.1.0559: translation of vim scripts can be improved * 9.1.0558: filetype: prolog detection can be improved * 9.1.0557: moving in the buffer list doesn't work as documented runtime(doc): fix inconsistencies in :h file-searching * 9.1.0556: :bwipe doesn't remove file from jumplist of other tabpages runtime(htmlangular): correct comment * 9.1.0555: filetype: angular ft detection is still problematic * 9.1.0554: :bw leaves jumplist and tagstack data around * 9.1.0553: filetype: *.mcmeta files are not recognized * 9.1.0552: No test for antlr4 filetype * 9.1.0551: filetype: htmlangular files are not properly detected * 9.1.0550: filetype: antlr4 files are not recognized * 9.1.0549: fuzzycollect regex based completion not working as expected runtime(doc): autocmd_add() accepts a list not a dict * 9.1.0548: it's not possible to get a unique id for some vars runtime(tmux): Update syntax script * 9.1.0547: No way to get the arity of a Vim function * 9.1.0546: vim-tiny fails on CTRL-X/CTRL-A runtime(hlsplaylist): include hlsplaylist ftplugin file runtime(doc): fix typo in :h ft-csv-syntax runtime(doc): Correct shell command to get $VIMRUNTIME into shell * 9.1.0545: MSVC conversion warning * 9.1.0544: filetype: ldapconf files are not recognized runtime(cmakecache): include cmakecache ftplugin file runtime(lex): include lex ftplugin file runtime(yacc): include yacc ftplugin file runtime(squirrel): include squirrel ftplugin file runtime(objcpp): include objcpp ftplugin file runtime(tf): include tf ftplugin file runtime(mysql): include mysql ftplugin file runtime(javacc): include javacc ftplugin file runtime(cabal): include cabal ftplugin file runtime(cuda): include CUDA ftplugin file runtime(editorconfig): include editorconfig ftplugin file runtime(kivy): update kivy syntax, include ftplugin runtime(syntax-tests): Stop generating redundant &quot;*_* 99.dump&quot; files * 9.1.0543: Behavior of CursorMovedC is strange runtime(vim): Update base-syntax, improve :match command highlighting * 9.1.0542: Vim9: confusing string() output for object functions * 9.1.0541: failing test with Vim configured without channel * 9.1.0540: Unused assignment in sign_define_cmd() runtime(doc): add page-scrolling keys to index.txt runtime(doc): add reference to xterm-focus-event from FocusGained/Lost * 9.1.0539: Not enough tests for what v9.1.0535 fixed runtime(doc): clarify how to re-init csv syntax file * 9.1.0538: not possible to assign priority when defining a sign * 9.1.0537: signed number detection for CTRL-X/A can be improved * 9.1.0536: filetype: zone files are not recognized * 9.1.0535: newline escape wrong in ex mode runtime(man): honor cmd modifiers before `g:ft_man_open_mode` runtime(man): use `nnoremap` to map to Ex commands * 9.1.0534: completion wrong with fuzzy when cycling back to original runtime(syntax-tests): Abort and report failed cursor progress runtime(syntax-tests): Introduce self tests for screen dumping runtime(syntax-tests): Clear and redraw the ruler line with the shell info runtime(syntax-tests): Allow for folded and wrapped lines in syntax test files * 9.1.0533: Vim9: need more tests for nested objects equality CI: Pre-v* 9.0.0110 versions generate bogus documentation tag entries runtime(doc): Remove wrong help tag CTRL-SHIFT-CR * 9.1.0532: filetype: Cedar files not recognized runtime(doc): document further keys that scroll page up/down * 9.1.0531: resource leak in mch_get_random() runtime(tutor): Fix wrong spanish translation runtime(netrw): fix remaining case of register clobber * 9.1.0530: xxd: MSVC warning about non-ASCII character * 9.1.0529: silent! causes following try/catch to not work runtime(rust): use shiftwidth() in indent script * 9.1.0528: spell completion message still wrong in translations * 9.1.0527: inconsistent parameter in Makefiles for Vim executable * 9.1.0526: Unwanted cursor movement with pagescroll at start of buffer runtime(doc): mention $XDG_CONFIG_HOME instead of $HOME/.config * 9.1.0525: Right release selects immediately when pum is truncated. * 9.1.0524: the recursive parameter in the *_equal functions can be removed runtime(termdebug): Add Deprecation warnings * 9.1.0523: Vim9: cannot downcast an object * 9.1.0522: Vim9: string(object) hangs for recursive references * 9.1.0521: if_py: _PyObject_CallFunction_SizeT is dropped in Python 3.13 * 9.1.0520: Vim9: incorrect type checking for modifying lists runtime(manpager): avoid readonly prompt * 9.1.0519: MS-Windows: libvterm compilation can be optimized * 9.1.0518: initialize the random buffer can be improved * 9.1.0517: MS-Windows: too long lines in Make_mvc.mak runtime(terraform): Add filetype plugin for terraform runtime(dockerfile): enable spellchecking of comments in syntax script runtime(doc): rename variable for pandoc markdown support runtime(doc): In builtin overview use {buf} as param for appendbufline/setbufline runtime(doc): clarify, that register 1-* 9 will always be shifted runtime(netrw): save and restore register 0-* 9, a and unnamed runtime(termdebug): Refactored StartDebug_term and EndDebug functions runtime(java): Compose &quot;g:java_highlight_signature&quot; and &quot;g:java_highlight_functions&quot; * 9.1.0516: need more tests for nested dicts and list comparision * 9.1.0515: Vim9: segfault in object_equal() * 9.1.0514: Vim9: issue with comparing objects recursively runtime(termdebug): Change some variables to Enums runtime(vim): Update base-syntax, fix function tail comments * 9.1.0513: Vim9: segfault with object comparison - Update to 9.1.0512: * Mode message for spell completion doesn't match allowed keys * CursorMovedC triggered wrongly with setcmdpos() * update runtime files * CI: test_gettext fails on MacOS14 + MSVC Win * not possible to translate Vim script messages * termdebug plugin can be further improved * add gomod filetype plugin * hard to detect cursor movement in the command line * Optionally highlight parameterised types * filetype: .envrc &amp; .prettierignore not recognized * filetype: Faust files are not recognized * inner-tag textobject confused about &quot;&gt;&quot; in attributes * cannot use fuzzy keyword completion * Remove the group exclusion list from @javaTop * wrong return type for execute() function * MS-Windows: too much legacy code * too complicated mapping restore in termdebug * simplify mapping * cannot switch buffer in a popup * MS-Windows: doesn't handle symlinks properly * getcmdcompltype() interferes with cmdline completion * termdebug can be further improved * update htmldjango detection * Improve Turkish documentation * include a simple csv filetype and syntax plugin * include the the simple nohlsearch package * matched text is highlighted case-sensitively * Matched text isn't highlighted in cmdline pum * Fix typos in several documents * clarify when text properties are cleared * improve the vim-shebang example * revert unintended formatting changes for termdebug * Add a config variable for commonly used compiler options * Wrong matched text highlighted in pum with 'rightleft' * bump length of character references in syntax script * properly check mapping variables using null_dict * fix KdlIndent and kdlComment in indent script * Test for patch 9.1.0489 doesn't fail without the fix * Fold multi-line comments with the syntax kind of &amp;fdm * using wrong type for PlaceSign() * filetype: Vim-script files not detected by shebang line * revert unintended change to zip#Write() * add another tag for vim-shebang feature * Cmdline pum doesn't work properly with 'rightleft' * minor style problems with patch 9.1.0487 * default completion may break with fuzzy * Wrong padding for pum &quot;kind&quot; with 'rightleft' * Update base-syntax, match shebang lines * MS-Windows: handle files with spaces properly * Restore HTML syntax file tests * completed item not update on fuzzy completion * filetype: Snakemake files are not recognized * make TermDebugSendCommand() a global function again * close all buffers in the same way * Matched text shouldn't be highlighted in &quot;kind&quot; and &quot;menu&quot; * fix wrong helptag for :defer * Update base-syntax, match :sleep arg * include Georgian keymap * Sorting of completeopt+=fuzzy is not stable * correctly test for windows in NetrwGlob() * glob() on windows fails with [] in directory name * rewrite mkdir() doc and simplify {flags} meaning * glob() not sufficiently tested * update return type for job_info() * termdebug plugin needs more love * correct return types for job_start() and job_status() * Update base-syntax, match :catch and :throw args * Include element values in non-marker annotations * Vim9: term_getjob() throws an exception on error * fuzzy string matching executed when not needed * fuzzy_match_str_with_pos() does unnecessary list operations * restore description of &quot;$&quot; in col() and virtcol() * deduplicate getpos(), line(), col(), virtcol() * Update g:vimsyn_comment_strings dump file tests * Use string interpolation instead of string concat * potential deref of NULL pointer in fuzzy_match_str_with_pos * block_editing errors out when using &lt;enter&gt; * Update base-syntax, configurable comment string highlighting * fix typos in syntax.txt * Cannot see matched text in popup menu * Update base-syntax, match multiline continued comments * clarify documentation for &quot;v&quot; position at line() * cmod_split modifier is always reset in term_start() * remove line-continuation characters * use shiftwidth() instead of &amp;tabstop in indent script * Remove orphaned screen dump files * include syntax, indent and ftplugin files * CI: Test_ColonEight() fails on github runners * add missing Enabled field in syntax script * basic svelte ftplugin file * term_start() does not clear vertical modifier * fix mousemodel restoration by comparing against null_string * Added definitions of Vim scripts and plugins * Exclude lambda expressions from _when_ _switch-case_ label clauses * Fix saved_mousemodel check * Inconsistencies between functions for option flags * Crash when using autocmd_get() after removing event inside autocmd * Fix small style issues * add return type info for Vim function descriptions * Update Italian Vim manpage * disable the q mapping * Change 'cms' for C++ to '// %s' * fix type mismatch error * Fix wrong email address * convert termdebug plugin to Vim9 script - Update to 9.1.0470: * tests Test_ColonEight_MultiByte() fails sporadically * Cannot have buffer-local value for 'completeopt' * GvimExt does not consult HKEY_CURRENT_USER * typos in some comments * runtime(vim): Update base-syntax, allow whitespace before :substitute pattern * Missing comments for fuzzy completion * runtime(man): update Vim manpage * runtime(comment): clarify the usage of 'commentstring' option value * runtime(doc): clarify how fuzzy 'completeopt' should work * runtime(netrw): prevent accidental data loss * missing filecopy() function * no whitespace padding in commentstring option in ftplugins * no fuzzy-matching support for insert-completion * eval5() and eval7 are too complex * too many strlen() calls in drawline.c * filetype lintstagedrc files are not recognized * Vim9 import autoload does not work with symlink * Coverity complains about division by zero * tests test_gui fails on Wayland * Left shift is incorrect with vartabstop and shiftwidth=0 * runtime(doc): clarify 'shortmess' flag &quot;S&quot; * MS-Windows compiler warning for size_t to int conversion * runtime(doc): include some vim9 script examples in the help * minor issues in test_filetype with rasi test * filetype rasi files are not recognized * runtime(java): Improve the matching of lambda expressions * Configure checks for libelf unnecessarily * No test for escaping '&lt;' with shellescape() * check.vim complains about overlong comment lines * translation(it): Update Italian translation * evalc. code too complex * MS-Windows Compiler warnings - Update to 9.1.0448: * compiler warning in eval.c * remove remaining css code * Add ft_hare.txt to Reference Manual TOC * re-generate vim syntax from generator * fix syntax vim bug * completion may be wrong when deleting all chars * getregionpos() inconsistent for partly-selected multibyte char * fix highlighting nested and escaped quotes in string props * remove the indent plugin since it has too many issues * update Debian runtime files * Coverity warning after 9.1.0440 * Not enough tests for getregion() with multibyte chars * Can't use blockwise selection with width for getregion() * update outdated syntax files * fix floating_modifier highlight * hare runtime files outdated * getregionpos() can't properly indicate positions beyond eol * function get_lval() is too long * Cannot filter the history * Wrong Ex command executed when :g uses '?' as delimiter * support floating_modifier none; revert broken highlighting * Motif requires non-const char pointer for XPM data * Crash when using '?' as separator for :s * filetype: cygport files are not recognized * make errors trying to access autoload/zig * Wrong yanking with exclusive selection and ve=all * add missing help tags file * Ancient XPM preprocessor hack may cause build errors * include basic rescript ftplugin file * eval.c is too long * getregionpos() doesn't handle one char selection * check for gdb file/dir before using as buffer name * refactor zig ftplugin, remove auto format * Coverity complains about eval.c refactor * Tag guessing leaves wrong search history with very short names * some issues with termdebug mapping test * update matchit plugin to v1.20 * too many strlen() calls in search.c * set commentstring option * update vb indent plugin as vim9script * filetype: purescript files are not recognized * filetype: slint files are not recognized * basic nim ftplugin file for comments * Add Arduino ftplugin and indent files * include basic typst ftplugin file * include basic prisma ftplugin file * include basic v ftplugin for comment support * getregionpos() wrong with blockwise mode and multibyte * function echo_string_core() is too long * hyprlang files are not recognized * add basic dart ftplugin file * basic ftplugin file for graphql * mention comment plugin at :h 'commentstring' * set commentstring for sql files in ftplugin * :browse oldfiles prompts even with single entry * eval.c not sufficiently tested * clarify why E195 is returned * clarify temporary file clean up * fix :NoMatchParen not working * Cannot move to previous/next rare word * add basic ftplugin file for sshdconfig * if_py: find_module has been removed in Python 3.12.0a7 * some screen dump tests can be improved * Some functions are not tested * clarify instal instructions for comment package * Unable to leave long line with 'smoothscroll' and 'scrolloff' * fix typo in vim9script help file * Remove trailing spaces * clarify {special} argument for shellescape() - update to 9.1.0413 * smoothscroll may cause infinite loop * add missing entries for the keys CTRL-W g&lt;Tab&gt; and &lt;C-Tab&gt; * update vi_diff.txt: add default value for 'flash' * typo in regexp_bt.c in DEBUG code * allow indented commands * Fix wrong define regex in ftplugin * Filter out non-Latin-1 characters for syntax tests * prefer scp over pscp * fix typo in usr_52.txt * too long functions in eval.c * warning about uninitialized variable * too many strlen() calls in the regexp engine * E16 fix, async keyword support for define * Stuck with long line and half-page scrolling * Divide by zero with getmousepos() and 'smoothscroll' * update and remove some invalid links * update translation of xxd manpage * Recursively delete directories by default with netrw delete command * Strive to remain compatible for at least Vim 7.0 * tests: xxd buffer overflow fails on 32-bit * Stop handpicking syntax groups for @javaTop * [security] xxd: buffer-overflow with specific flags * Vim9: not able to import file from start dir * filetype: mdd files detected as zsh filetype * filetype: zsh module files are not recognized * Remove hardcoded private.ppk logic from netrw * Vim9: confusing error message for unknown type * block_editing errors out when using del * add new items to scripts section in syntax plugin * Vim9: imported vars are not properly type checked * Wrong display with 'smoothscroll' when changing quickfix list * filetype: jj files are not recognized * getregionpos() may leak memory on error * The CODEOWNERS File is not useful * Remove and cleanup Win9x legacy from netrw * add MsgArea to 'highlight' option description * Cannot get a list of positions describing a region * Fix digit separator in syntax script for octals and floats * Update link to Wikipedia Vi page * clear $MANPAGER in ftplugin before shelling out * Fix typos in help documents * 'viewdir' not respecting $XDG_CONFIG_HOME * tests: Vim9 debug tests may be flaky * correct getscriptinfo() example * Vim9: could improve testing * test_sound fails on macos-12 * update Serbian menu * update Slovak menu * update Slovenian menu * update Portuguese menu * update Dutch menu * update Korean menu * update Icelandic menu * update Czech menu * update Afrikaans menu * update German menu * filetype: inko files are not recognized * filetype: templ files are not recognized * cursor() and getregion() don't handle v:maxcol well * Vim9: null value tests not sufficient * update Catalan menu * filetype: stylus files not recognized * update spanish menu localization * regenerate helptags * Vim9: crash with null_class and null_object * Add tags about lazyloading of menu * tests: vt420 terminfo entry may not be found * filetype: .out files recognized as tex files * filetype: Kbuild files are not recognized * cbuffer and similar commands don't accept a range * Improve the recognition of the &quot;indent&quot; method declarations * Fix a typo in usr_30.txt * remove undefined var s:save_cpoptions and add include setting * missing setlocal in indent plugin * Calculating line height for unnecessary amount of lines * improve syntax file performance * There are a few typos * Vim9: no comments allowed after class vars * CI: remove trailing white space in documentation * Formatting text wrong when 'breakindent' is set * Add oracular (24.10) as Ubuntu release name * Vim9: Trailing commands after class/enum keywords ignored * tests: 1-second delay after Test_BufEnter_botline() * update helptags for jq syntax * include syntax, ftplugin and compiler plugin * fix typo synconcealend -&gt; synconcealed * include a simple comment toggling plugin * wrong botline in BufEnter * clarify syntax vs matching mechanism * fix undefined variable in indent plugin * ops.c code uses too many strlen() calls * Calling CLEAR_FIELD() on the same struct twice * Vim9: compile_def_function() still too long * Update Serbian messages * clarify the effect of setting the shell to powershell * Improve the recognition of the &quot;style&quot; method declarations * Vim9: problem when importing autoloaded scripts * compile_def_function is too long * filetype: ondir files are not recognized * Crash when typing many keys with D- modifier * tests: test_vim9_builtin is a bit slow * update documentation * change the download URL of &quot;libsodium&quot; * tests: test_winfixbuf is a bit slow * Add filetype, syntax and indent plugin for Astro * expanding rc config files does not work well * Vim9: vim9type.c is too complicated * Vim9: does not handle autoloaded variables well * minor spell fix in starting.txt * wrong drawing in GUI with setcellwidth() * Add include and suffixesadd * Page scrolling should place cursor at window boundaries * align command line table * minor fixes to starting.txt * fix comment definition in filetype plugin * filetype: flake.lock files are not recognized * runtime(uci): No support for uci file types * Support &quot;g:ftplugin_java_source_path&quot; with archived files * tests: Test_autoload_import_relative_compiled fails on Windows * Finding cmd modifiers and cmdline-specials is inefficient * No test that completing a partial mapping clears 'showcmd' * tests: test_vim9_dissamble may fail * Vim9: need static type for typealias * X11 does not ignore smooth scroll event * A few typos in test_xdg when testing gvimrc * Patch v9.1.0338 fixed sourcing a script with import * Problem: gvimrc not sourced from XDG_CONFIG_HOME * Cursor wrong after using setcellwidth() in terminal * 'showcmd' wrong for partial mapping with multibyte * tests: test_taglist fails when 'helplang' contains non-english * Problem: a few memory leaks are found * Problem: Error with matchaddpos() and empty list * tests: xdg test uses screen dumps * Vim9: import through symlinks not correctly handled * Missing entry for XDG vimrc file in :version * tests: typo in test_xdg * runtime(i3config/swayconfig): update syntax scripts * document pandoc compiler and enable configuring arguments * String interpolation fails for List type * No test for highlight behavior with 'ambiwidth' * tests: test_xdg fails on the appimage repo * tests: some assert_equal() calls have wrong order of args * make install does not install all files * runtime(doc): fix typos in starting.txt Package wget was updated: - If wget for an http URL is redirected to a different site (hostname parts of URLs differ), then any &quot;Authenticate&quot; and &quot;Cookie&quot; header entries are discarded. [bsc#1185551, wget-do-not-propagate-credentials.patch, bsc#1230795, CVE-2021-31879] - Drop support for shorthand URLs * Breaking change to fix CVE-2024-10524. [+ drop-support-for-shorthand-URLs.patch, bsc#1233773] - Update 0001-possibly-truncate-pathname-components.patch * Take the patch from savannah repository where the checking of the file length doesn't include path length. * [bsc#1204720, bsc#1231661] Package wicked was updated: - Update to version 0.6.77 - compat-suse: use iftype in sysctl handling (bsc#1230911, gh#openSUSE/wicked#1043) - Always generate the ipv4/ipv6 &lt;enabled&gt;true|false&lt;/enabled&gt; node - Inherit all, default and interface sysctl settings also for loopback, except for use_tempaddr and accept_dad. - Consider only interface specific accept_redirects sysctl settings. - Adopt ifsysctl(5) manual page with wicked specific behavior. - route: fix family and destination processing (bsc#1231060) - man: improve wicked-config(5) file description (gh#openSUSE/wicked#1039) - dhcp4: add ignore-rfc3927-1-6 wicked-config(5) option (jsc#PED-10855, gh#openSUSE/wicked#1038) - team: set arp link watcher interval default to 1s (gh#openSUSE/wicked#1037) - systemd: use `BindsTo=dbus.service` in favor of `Requisite=` (bsc#1229745) - compat-suse: fix use of deprecated `INTERFACETYPE=dummy` (boo#1229555) - arp: don't set target broadcast hardware address (gh#openSUSE/wicked#1036) - dbus: don't memcpy empty/NULL array value (gh#openSUSE/wicked#1035) - ethtool: fix leak and free pause data in ethtool_free (gh#openSUSE/wicked#1030) - Removed patches included in the source archive: [- 0001-compat-suse-repair-dummy-interfaces-boo-1229555.patch] - compat-suse: fix dummy interfaces configuration with INTERFACETYPE=dummy (boo#1229555, gh#openSUSE/wicked#1031) [+ 0001-compat-suse-repair-dummy-interfaces-boo-1229555.patch] Package xen was updated: - bsc#1246112, bsc#1238896 - VUL-0: xen: More AMD transient execution attack (CVE-2024-36350, CVE-2024-36357, XSA-471) xsa471-01.patch xsa471-02.patch xsa471-03.patch xsa471-04.patch xsa471-05.patch xsa471-06.patch xsa471-07.patch xsa471-08.patch xsa471-09.patch xsa471-10.patch xsa471-11.patch xsa471-12.patch xsa471-13.patch xsa471-14.patch xsa471-15.patch xsa471-16.patch xsa471-17.patch xsa471-18.patch xsa471-19.patch xsa471-20.patch - bsc#1244644 - VUL-0: CVE-2025-27465: xen: x86: Incorrect stubs exception handling for flags recovery (XSA-470) xsa470.patch - bsc#1243117 - VUL-0: CVE-2024-28956: xen: Intel CPU: Indirect Target Selection (ITS) (XSA-469) xsa469-01.patch xsa469-02.patch xsa469-03.patch xsa469-04.patch xsa469-05.patch xsa469-06.patch xsa469-07.patch - bsc#1238043 - VUL-0: CVE-2025-1713: xen: deadlock potential with VT-d and legacy PCI device pass-through (XSA-467) xsa467.patch - bsc#1234282 - VUL-0: xen: XSA-466: Xen hypercall page unsafe against speculative attacks xsa466.patch - Update to Xen 4.16.7 security bug fix release (bsc#1027519) xen-4.16.7-testing-src.tar.bz2 * No upstream changelog found in sources or webpage - Dropped patches contained in new tarball 661d00b8-VMX-prevent-fallthrough-in-vmx_set_reg.patch 662a6a4c-x86-spec-reporting-of-BHB-clearing.patch 662a6a8d-x86-spec-adjust-logic-to-elide-LFENCE.patch 669662ea-x86-IRQ-avoid-double-unlock-in-map_domain_pirq.patch 66bb6f78-x86-IOMMU-move-tracking-in-iommu_identity_mapping.patch 66bb6fa5-x86-pass-through-document-as-security-unsupported.patch xen.stubdom.newlib.patch xsa462.patch xsa463-01.patch xsa463-02.patch xsa463-03.patch xsa463-04.patch xsa463-05.patch xsa463-06.patch xsa463-07.patch xsa463-08.patch xsa463-09.patch xsa463-10.patch xsa464.patch - bsc#1232622 - VUL-0: CVE-2024-45818: xen: Deadlock in x86 HVM standard VGA handling (XSA-463) xsa463-01.patch xsa463-02.patch xsa463-03.patch xsa463-04.patch xsa463-05.patch xsa463-06.patch xsa463-07.patch xsa463-08.patch xsa463-09.patch xsa463-10.patch - bsc#1232624 - VUL-0: CVE-2024-45819: xen: libxl leaks data to PVH guests via ACPI tables (XSA-464) xsa464.patch - Drop the following patches stdvga-cache.patch - bsc#1232542 - remove usage of net-tools-deprecated from supportconfig plugin - bsc#1230366 - VUL-0: CVE-2024-45817: xen: x86: Deadlock in vlapic_error() (XSA-462) xsa462.patch - bsc#1228201 - [Baremetal][sles15sp4][guest migration] xl migration fail , guest not shutdown. This also fixes, bsc#1222453 - VUL-0: CVE-2024-2201: xen: x86: Native Branch History Injection (XSA-456) 661d00b8-VMX-prevent-fallthrough-in-vmx_set_reg.patch - bsc#1228574 - VUL-0: CVE-2024-31145: xen: error handling in x86 IOMMU identity mapping (XSA-460) 66bb7316-x86-IOMMU-move-tracking-in-iommu_identity_mapping.patch - bsc#1228575 - VUL-0: CVE-2024-31146: xen: PCI device pass-through with shared resources (XSA-461) 66bb6fa5-x86-pass-through-document-as-security-unsupported.patch - Drop xsa458.patch in favor of upstream version (bsc#1227355) 669662ea-x86-IRQ-avoid-double-unlock-in-map_domain_pirq.patch - bsc#1227355 - VUL-0: CVE-2024-31143: xen: double unlock in x86 guest IRQ handling (XSA-458) xsa458.patch - bsc#1222453 - VUL-0: CVE-2024-2201: xen: x86: Native Branch History Injection (XSA-456) 662a6a4c-x86-spec-reporting-of-BHB-clearing.patch 662a6a8d-x86-spec-adjust-logic-to-elide-LFENCE.patch Package zypper was updated: - BuildRequires: libzypp-devel &gt;= 17.37.0.- Use libzypp improvements for preload and mirror handling. - xmlout.rnc: Update repo-element (bsc#1241463) Add the &quot;metalink&quot; attribute and reflect that the &quot;url&quot; elements list may in fact be empty, if no baseurls are defined in the .repo files. - man: update --allow-unsigned-rpm description. Explain how to achieve the same for packages provided by repositories. - version 1.14.90 - Updated translations (bsc#1230267) - version 1.14.89 - Do not double encode URL strings passed on the commandline (bsc#1237587) URLs passed on the commandline must have their special chars encoded already. We just want to check and encode forgotten unsafe chars like a blank. A '%' however must not be encoded again. - version 1.14.88 - Package preloader that concurrently downloads files. It's not yet enabled per default. To enable the preview set ZYPP_CURL2=1 and ZYPP_PCK_PRELOAD=1 in the environment. (#104) - BuildRequires: libzypp-devel &gt;= 17.36.4. - version 1.14.87 - refresh: add --include-all-archs (fixes #598) Future multi-arch repos may allow to download only those metadata which refer to packages actually compatible with the systems architecture. Some tools however want zypp to provide the full metadata of a repository without filtering incompatible architectures. - info,search: add option to search and list Enhances (bsc#1237949) - version 1.14.86 - Annonunce --root in commands not launching a Target (bsc#1237044) - BuildRequires: libzypp-devel &gt;= 17.36.3. - version 1.14.85 - Let zypper dup fail in case of (temporarily) unaccessible repos (bsc#1228434, bsc#1236939, fixes #446) - version 1.14.84 - New system-architecture command (bsc#1236384) Prints the detected system architecture. - version 1.14.83 - requires: libzypp &gt;= 17.36.0. - Change versioncmp command to return exit code according to the comparison result (#593) - version 1.14.82 - lr: show the repositories keep-packages flag (bsc#1232458) It is shown in the details view or by using -k,--keep-packages. In addition libyzpp supports to enforce keeping downloaded packages of all repos within a package cache by creating a '.keep_packages' file there. - version 1.14.81 - Try to refresh update repos first to have updated GPG keys on the fly (bsc#1234752) An update repo may contain a prolonged GPG key for the GA repo. Refreshing the update repo first updates a trusted key on the fly and avoids a 'key has expired' warning being issued when refreshing the GA repo. - Refresh: restore legacy behavior and suppress Exception reporting as non-root (bsc#1235636) - version 1.14.80 - info: Allow to query a specific version (jsc#PED-11268) To query for a specific version simply append &quot;-&lt;version&gt;&quot; or &quot;-&lt;version&gt;-&lt;release&gt;&quot; to the &quot;&lt;name&gt;&quot; pattern. Note that the edition part must always match exactly. - version 1.14.79 - Don't try to download missing raw metadata if cache is not writable (bsc#1225451) - man: Update 'search' command description. Hint to &quot;se -v&quot; showing the matches within the packages metadata. Explain that search strings starting with a &quot;/&quot; will implicitly look into the filelist as well. Otherfise an explicit &quot;-f&quot; is needed. - version 1.14.78 - API refactoring. Prevent zypper from using now private libzypp symbols (bsc#1230267) - BuildRequires: libzypp-devel &gt;= 17.35.10. - Fix wrong numbers used in CommitSummary skipped/failed messages. - version 1.14.77 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/sles-15-sp4-chost-byos-v20250721-x86-64/ Public Cloud Image Info https://www.suse.com/support/security/rating/ SUSE Security Ratings Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 aaa_base-84.87+git20180409.04c9dae-150300.10.28.2 apparmor-abstractions-3.0.4-150400.5.18.1 apparmor-parser-3.0.4-150400.5.18.1 bash-4.4-150400.27.3.2 bash-sh-4.4-150400.27.3.2 bind-utils-9.16.50-150400.5.46.1 ca-certificates-mozilla-2.74-150200.41.1 cifs-utils-6.15-150400.3.15.1 containerd-1.7.27-150000.123.1 containerd-ctr-1.7.27-150000.123.1 coreutils-8.32-150400.9.9.1 crypto-policies-20210917.c9d86d1-150400.3.8.1 curl-8.0.1-150400.5.62.1 docker-28.2.2_ce-150000.227.1 findutils-4.8.0-150300.3.3.2 glibc-2.31-150300.95.1 glibc-locale-2.31-150300.95.1 glibc-locale-base-2.31-150300.95.1 google-guest-agent-20250506.01-150000.1.63.1 google-guest-configs-20241205.00-150400.13.22.1 google-guest-oslogin-20240311.01-150000.1.53.1 google-osconfig-agent-20250416.02-150000.1.50.1 grub2-2.06-150400.11.60.1 grub2-i386-pc-2.06-150400.11.60.1 grub2-x86_64-efi-2.06-150400.11.60.1 haveged-1.9.14-150400.3.8.1 hwdata-0.394-150000.3.77.2 hwinfo-21.88-150400.3.18.1 iproute2-5.14-150400.3.3.1 iputils-20211215-150400.3.22.1 jq-1.6-150000.3.6.1 kbd-2.4.0-150400.5.9.1 kbd-legacy-2.4.0-150400.5.9.1 kernel-default-5.14.21-150400.24.167.1 krb5-1.19.2-150400.3.15.1 libapparmor1-3.0.4-150400.5.18.1 libaugeas0-1.12.0-150400.3.8.1 libavahi-client3-0.8-150400.7.20.1 libavahi-common3-0.8-150400.7.20.1 libblkid1-2.37.2-150400.8.35.2 libcom_err2-1.46.4-150400.3.9.2 libcryptsetup12-2.4.3-150400.3.6.2 libcurl4-8.0.1-150400.5.62.1 libexpat1-2.7.1-150400.3.28.1 libfdisk1-2.37.2-150400.8.35.2 libfreetype6-2.10.4-150000.4.22.1 libgcc_s1-14.2.0+git10526-150000.1.6.1 libglib-2_0-0-2.70.5-150400.3.23.1 libgnutls30-3.7.3-150400.4.47.1 libhavege2-1.9.14-150400.3.8.1 libjq1-1.6-150000.3.6.1 libmount1-2.37.2-150400.8.35.2 libncurses6-6.1-150000.5.30.1 libopeniscsiusr0_2_0-2.1.7-150400.39.14.1 libopenssl1_1-1.1.1l-150400.7.78.1 libpcap1-1.10.1-150400.3.6.2 libprocps8-3.3.17-150000.7.42.1 libpython3_6m1_0-3.6.15-150300.10.84.1 librdkafka1-0.11.6-150000.1.11.1 libreadline7-7.0-150400.27.3.2 libsmartcols1-2.37.2-150400.8.35.2 libsolv-tools-0.7.32-150400.3.35.1 libsolv-tools-base-0.7.32-150400.3.35.1 libsqlite3-0-3.49.1-150000.3.27.1 libssh-config-0.9.8-150400.3.9.1 libssh4-0.9.8-150400.3.9.1 libstdc++6-14.2.0+git10526-150000.1.6.1 libsystemd0-249.17-150400.8.46.1 libtasn1-4.13-150000.4.11.1 libtasn1-6-4.13-150000.4.11.1 libudev1-249.17-150400.8.46.1 libuuid1-2.37.2-150400.8.35.2 libxml2-2-2.9.14-150400.5.44.1 libzypp-17.37.5-150400.3.126.1 login_defs-4.8.1-150400.10.24.1 logrotate-3.18.1-150400.3.10.1 ncurses-utils-6.1-150000.5.30.1 open-iscsi-2.1.7-150400.39.14.1 openssh-8.4p1-150300.3.49.1 openssh-clients-8.4p1-150300.3.49.1 openssh-common-8.4p1-150300.3.49.1 openssh-server-8.4p1-150300.3.49.1 openssl-1_1-1.1.1l-150400.7.78.1 pam-1.3.0-150000.6.83.1 pam-config-1.1-150200.3.14.1 perl-5.26.1-150300.17.20.1 perl-base-5.26.1-150300.17.20.1 procps-3.3.17-150000.7.42.1 python3-3.6.15-150300.10.84.1 python3-base-3.6.15-150300.10.84.1 python3-bind-9.16.50-150400.5.46.1 python3-setuptools-44.1.1-150400.9.12.1 rsyslog-8.2306.0-150400.5.33.1 rsyslog-module-relp-8.2306.0-150400.5.33.1 runc-1.2.6-150000.73.2 shadow-4.8.1-150400.10.24.1 shim-15.8-150300.4.23.1 socat-1.8.0.0-150400.14.6.1 sudo-1.9.9-150400.4.39.1 supportutils-3.2.10-150300.7.35.36.4 suse-build-key-12.0-150000.8.58.1 suseconnect-ng-1.13.0-150400.3.42.1 systemd-249.17-150400.8.46.1 systemd-sysvinit-249.17-150400.8.46.1 terminfo-6.1-150000.5.30.1 terminfo-base-6.1-150000.5.30.1 timezone-2025b-150000.75.34.2 udev-249.17-150400.8.46.1 util-linux-2.37.2-150400.8.35.2 util-linux-systemd-2.37.2-150400.8.35.2 vim-9.1.1406-150000.5.75.1 vim-data-common-9.1.1406-150000.5.75.1 wget-1.20.3-150000.3.29.1 wicked-0.6.77-150400.3.36.1 wicked-service-0.6.77-150400.3.36.1 xen-libs-4.16.7_02-150400.4.72.1 zypper-1.14.90-150400.3.85.3 aaa_base-84.87+git20180409.04c9dae-150300.10.28.2 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 apparmor-abstractions-3.0.4-150400.5.18.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 apparmor-parser-3.0.4-150400.5.18.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 bash-4.4-150400.27.3.2 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 bash-sh-4.4-150400.27.3.2 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 bind-utils-9.16.50-150400.5.46.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 ca-certificates-mozilla-2.74-150200.41.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 cifs-utils-6.15-150400.3.15.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 containerd-1.7.27-150000.123.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 containerd-ctr-1.7.27-150000.123.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 coreutils-8.32-150400.9.9.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 crypto-policies-20210917.c9d86d1-150400.3.8.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 curl-8.0.1-150400.5.62.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 docker-28.2.2_ce-150000.227.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 findutils-4.8.0-150300.3.3.2 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 glibc-2.31-150300.95.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 glibc-locale-2.31-150300.95.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 glibc-locale-base-2.31-150300.95.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 google-guest-agent-20250506.01-150000.1.63.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 google-guest-configs-20241205.00-150400.13.22.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 google-guest-oslogin-20240311.01-150000.1.53.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 google-osconfig-agent-20250416.02-150000.1.50.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 grub2-2.06-150400.11.60.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 grub2-i386-pc-2.06-150400.11.60.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 grub2-x86_64-efi-2.06-150400.11.60.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 haveged-1.9.14-150400.3.8.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 hwdata-0.394-150000.3.77.2 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 hwinfo-21.88-150400.3.18.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 iproute2-5.14-150400.3.3.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 iputils-20211215-150400.3.22.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 jq-1.6-150000.3.6.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 kbd-2.4.0-150400.5.9.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 kbd-legacy-2.4.0-150400.5.9.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 kernel-default-5.14.21-150400.24.167.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 krb5-1.19.2-150400.3.15.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libapparmor1-3.0.4-150400.5.18.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libaugeas0-1.12.0-150400.3.8.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libavahi-client3-0.8-150400.7.20.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libavahi-common3-0.8-150400.7.20.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libblkid1-2.37.2-150400.8.35.2 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libcom_err2-1.46.4-150400.3.9.2 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libcryptsetup12-2.4.3-150400.3.6.2 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libcurl4-8.0.1-150400.5.62.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libexpat1-2.7.1-150400.3.28.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libfdisk1-2.37.2-150400.8.35.2 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libfreetype6-2.10.4-150000.4.22.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libgcc_s1-14.2.0+git10526-150000.1.6.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libglib-2_0-0-2.70.5-150400.3.23.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libgnutls30-3.7.3-150400.4.47.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libhavege2-1.9.14-150400.3.8.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libjq1-1.6-150000.3.6.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libmount1-2.37.2-150400.8.35.2 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libncurses6-6.1-150000.5.30.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libopeniscsiusr0_2_0-2.1.7-150400.39.14.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libopenssl1_1-1.1.1l-150400.7.78.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libpcap1-1.10.1-150400.3.6.2 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libprocps8-3.3.17-150000.7.42.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libpython3_6m1_0-3.6.15-150300.10.84.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 librdkafka1-0.11.6-150000.1.11.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libreadline7-7.0-150400.27.3.2 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libsmartcols1-2.37.2-150400.8.35.2 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libsolv-tools-0.7.32-150400.3.35.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libsolv-tools-base-0.7.32-150400.3.35.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libsqlite3-0-3.49.1-150000.3.27.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libssh-config-0.9.8-150400.3.9.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libssh4-0.9.8-150400.3.9.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libstdc++6-14.2.0+git10526-150000.1.6.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libsystemd0-249.17-150400.8.46.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libtasn1-4.13-150000.4.11.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libtasn1-6-4.13-150000.4.11.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libudev1-249.17-150400.8.46.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libuuid1-2.37.2-150400.8.35.2 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libxml2-2-2.9.14-150400.5.44.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 libzypp-17.37.5-150400.3.126.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 login_defs-4.8.1-150400.10.24.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 logrotate-3.18.1-150400.3.10.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 ncurses-utils-6.1-150000.5.30.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 open-iscsi-2.1.7-150400.39.14.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 openssh-8.4p1-150300.3.49.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 openssh-clients-8.4p1-150300.3.49.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 openssh-common-8.4p1-150300.3.49.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 openssh-server-8.4p1-150300.3.49.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 openssl-1_1-1.1.1l-150400.7.78.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 pam-1.3.0-150000.6.83.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 pam-config-1.1-150200.3.14.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 perl-5.26.1-150300.17.20.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 perl-base-5.26.1-150300.17.20.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 procps-3.3.17-150000.7.42.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 python3-3.6.15-150300.10.84.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 python3-base-3.6.15-150300.10.84.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 python3-bind-9.16.50-150400.5.46.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 python3-setuptools-44.1.1-150400.9.12.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 rsyslog-8.2306.0-150400.5.33.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 rsyslog-module-relp-8.2306.0-150400.5.33.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 runc-1.2.6-150000.73.2 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 shadow-4.8.1-150400.10.24.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 shim-15.8-150300.4.23.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 socat-1.8.0.0-150400.14.6.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 sudo-1.9.9-150400.4.39.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 supportutils-3.2.10-150300.7.35.36.4 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 suse-build-key-12.0-150000.8.58.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 suseconnect-ng-1.13.0-150400.3.42.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 systemd-249.17-150400.8.46.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 systemd-sysvinit-249.17-150400.8.46.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 terminfo-6.1-150000.5.30.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 terminfo-base-6.1-150000.5.30.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 timezone-2025b-150000.75.34.2 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 udev-249.17-150400.8.46.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 util-linux-2.37.2-150400.8.35.2 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 util-linux-systemd-2.37.2-150400.8.35.2 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 vim-9.1.1406-150000.5.75.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 vim-data-common-9.1.1406-150000.5.75.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 wget-1.20.3-150000.3.29.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 wicked-0.6.77-150400.3.36.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 wicked-service-0.6.77-150400.3.36.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 xen-libs-4.16.7_02-150400.4.72.1 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 zypper-1.14.90-150400.3.85.3 as a component of Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64 Systems with microprocessors utilizing speculative execution and branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis. CVE-2017-5753 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important 4.7 AV:L/AC:M/Au:N/C:C/I:N/A:N In libexpat before 2.2.8, crafted XML input could fool the parser into changing from DTD parsing to document parsing too early; a consecutive call to XML_GetCurrentLineNumber (or XML_GetCurrentColumnNumber) then resulted in a heap-based buffer over-read. CVE-2019-15903 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libexpat1-2.7.1-150400.3.28.1 important 5 AV:N/AC:L/Au:N/C:N/I:N/A:P GNU Wget through 1.21.1 does not omit the Authorization header upon a redirect to a different origin, a related issue to CVE-2018-1000007. CVE-2021-31879 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:wget-1.20.3-150000.3.29.1 moderate 5.8 AV:N/AC:M/Au:N/C:P/I:P/A:N An out-of-bounds (OOB) memory access flaw was found in the Linux kernel's eBPF due to an Improper Input Validation. This flaw allows a local attacker with a special privilege to crash the system or leak internal information. CVE-2021-4204 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: spi: spi-zynq-qspi: Fix a NULL pointer dereference in zynq_qspi_exec_mem_op() In zynq_qspi_exec_mem_op(), kzalloc() is directly used in memset(), which could lead to a NULL pointer dereference on failure of kzalloc(). Fix this bug by adding a check of tmpbuf. This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_SPI_ZYNQ_QSPI=m show no new warnings, and our static analyzer no longer warns about this code. CVE-2021-4441 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix a potential gpu_metrics_table memory leak Memory is allocated for gpu_metrics_table in renoir_init_smc_tables(), but not freed in int smu_v12_0_fini_smc_tables(). Free it! CVE-2021-4453 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: can: j1939: fix errant WARN_ON_ONCE in j1939_session_deactivate The conclusion "j1939_session_deactivate() should be called with a session ref-count of at least 2" is incorrect. In some concurrent scenarios, j1939_session_deactivate can be called with the session ref-count less than 2. But there is not any problem because it will check the session active state before session putting in j1939_session_deactivate_locked(). Here is the concurrent scenario of the problem reported by syzbot and my reproduction log. cpu0 cpu1 j1939_xtp_rx_eoma j1939_xtp_rx_abort_one j1939_session_get_by_addr [kref == 2] j1939_session_get_by_addr [kref == 3] j1939_session_deactivate [kref == 2] j1939_session_put [kref == 1] j1939_session_completed j1939_session_deactivate WARN_ON_ONCE(kref < 2) ===================================================== WARNING: CPU: 1 PID: 21 at net/can/j1939/transport.c:1088 j1939_session_deactivate+0x5f/0x70 CPU: 1 PID: 21 Comm: ksoftirqd/1 Not tainted 5.14.0-rc7+ #32 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014 RIP: 0010:j1939_session_deactivate+0x5f/0x70 Call Trace: j1939_session_deactivate_activate_next+0x11/0x28 j1939_xtp_rx_eoma+0x12a/0x180 j1939_tp_recv+0x4a2/0x510 j1939_can_recv+0x226/0x380 can_rcv_filter+0xf8/0x220 can_receive+0x102/0x220 ? process_backlog+0xf0/0x2c0 can_rcv+0x53/0xf0 __netif_receive_skb_one_core+0x67/0x90 ? process_backlog+0x97/0x2c0 __netif_receive_skb+0x22/0x80 CVE-2021-4454 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: phy: mdio: fix memory leak Syzbot reported memory leak in MDIO bus interface, the problem was in wrong state logic. MDIOBUS_ALLOCATED indicates 2 states: 1. Bus is only allocated 2. Bus allocated and __mdiobus_register() fails, but device_register() was called In case of device_register() has been called we should call put_device() to correctly free the memory allocated for this device, but mdiobus_free() calls just kfree(dev) in case of MDIOBUS_ALLOCATED state To avoid this behaviour we need to set bus->state to MDIOBUS_UNREGISTERED _before_ calling device_register(), because put_device() should be called even in case of device_register() failure. CVE-2021-47416 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 low In the Linux kernel, the following vulnerability has been resolved: drm/vc4: kms: Add missing drm_crtc_commit_put Commit 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit") introduced a global state for the HVS, with each FIFO storing the current CRTC commit so that we can properly synchronize commits. However, the refcounting was off and we thus ended up leaking the drm_crtc_commit structure every commit. Add a drm_crtc_commit_put to prevent the leakage. CVE-2021-47534 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ARM: davinci: da850-evm: Avoid NULL pointer dereference With newer versions of GCC, there is a panic in da850_evm_config_emac() when booting multi_v5_defconfig in QEMU under the palmetto-bmc machine: Unable to handle kernel NULL pointer dereference at virtual address 00000020 pgd = (ptrval) [00000020] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 5.15.0 #1 Hardware name: Generic DT based system PC is at da850_evm_config_emac+0x1c/0x120 LR is at do_one_initcall+0x50/0x1e0 The emac_pdata pointer in soc_info is NULL because davinci_soc_info only gets populated on davinci machines but da850_evm_config_emac() is called on all machines via device_initcall(). Move the rmii_en assignment below the machine check so that it is only dereferenced when running on a supported SoC. CVE-2021-47631 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: powerpc/set_memory: Avoid spinlock recursion in change_page_attr() Commit 1f9ad21c3b38 ("powerpc/mm: Implement set_memory() routines") included a spin_lock() to change_page_attr() in order to safely perform the three step operations. But then commit 9f7853d7609d ("powerpc/mm: Fix set_memory_*() against concurrent accesses") modify it to use pte_update() and do the operation safely against concurrent access. In the meantime, Maxime reported some spinlock recursion. [ 15.351649] BUG: spinlock recursion on CPU#0, kworker/0:2/217 [ 15.357540] lock: init_mm+0x3c/0x420, .magic: dead4ead, .owner: kworker/0:2/217, .owner_cpu: 0 [ 15.366563] CPU: 0 PID: 217 Comm: kworker/0:2 Not tainted 5.15.0+ #523 [ 15.373350] Workqueue: events do_free_init [ 15.377615] Call Trace: [ 15.380232] [e4105ac0] [800946a4] do_raw_spin_lock+0xf8/0x120 (unreliable) [ 15.387340] [e4105ae0] [8001f4ec] change_page_attr+0x40/0x1d4 [ 15.393413] [e4105b10] [801424e0] __apply_to_page_range+0x164/0x310 [ 15.400009] [e4105b60] [80169620] free_pcp_prepare+0x1e4/0x4a0 [ 15.406045] [e4105ba0] [8016c5a0] free_unref_page+0x40/0x2b8 [ 15.411979] [e4105be0] [8018724c] kasan_depopulate_vmalloc_pte+0x6c/0x94 [ 15.418989] [e4105c00] [801424e0] __apply_to_page_range+0x164/0x310 [ 15.425451] [e4105c50] [80187834] kasan_release_vmalloc+0xbc/0x134 [ 15.431898] [e4105c70] [8015f7a8] __purge_vmap_area_lazy+0x4e4/0xdd8 [ 15.438560] [e4105d30] [80160d10] _vm_unmap_aliases.part.0+0x17c/0x24c [ 15.445283] [e4105d60] [801642d0] __vunmap+0x2f0/0x5c8 [ 15.450684] [e4105db0] [800e32d0] do_free_init+0x68/0x94 [ 15.456181] [e4105dd0] [8005d094] process_one_work+0x4bc/0x7b8 [ 15.462283] [e4105e90] [8005d614] worker_thread+0x284/0x6e8 [ 15.468227] [e4105f00] [8006aaec] kthread+0x1f0/0x210 [ 15.473489] [e4105f40] [80017148] ret_from_kernel_thread+0x14/0x1c Remove the read / modify / write sequence to make the operation atomic and remove the spin_lock() in change_page_attr(). To do the operation atomically, we can't use pte modification helpers anymore. Because all platforms have different combination of bits, it is not easy to use those bits directly. But all have the _PAGE_KERNEL_{RO/ROX/RW/RWX} set of flags. All we need it to compare two sets to know which bits are set or cleared. For instance, by comparing _PAGE_KERNEL_ROX and _PAGE_KERNEL_RO you know which bit gets cleared and which bit get set when changing exec permission. CVE-2021-47632 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ath5k: fix OOB in ath5k_eeprom_read_pcal_info_5111 The bug was found during fuzzing. Stacktrace locates it in ath5k_eeprom_convert_pcal_info_5111. When none of the curve is selected in the loop, idx can go up to AR5K_EEPROM_N_PD_CURVES. The line makes pd out of bound. pd = &chinfo[pier].pd_curves[idx]; There are many OOB writes using pd later in the code. So I added a sanity check for idx. Checks for other loops involving AR5K_EEPROM_N_PD_CURVES are not needed as the loop index is not used outside the loops. The patch is NOT tested with real device. The following is the fuzzing report BUG: KASAN: slab-out-of-bounds in ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] Write of size 1 at addr ffff8880174a4d60 by task modprobe/214 CPU: 0 PID: 214 Comm: modprobe Not tainted 5.6.0 #1 Call Trace: dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] __kasan_report.cold+0x37/0x7c ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] kasan_report+0xe/0x20 ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] ? apic_timer_interrupt+0xa/0x20 ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k] ? ath5k_pci_eeprom_read+0x228/0x3c0 [ath5k] ath5k_eeprom_init+0x2513/0x6290 [ath5k] ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k] ? usleep_range+0xb8/0x100 ? apic_timer_interrupt+0xa/0x20 ? ath5k_eeprom_read_pcal_info_2413+0x2f20/0x2f20 [ath5k] ath5k_hw_init+0xb60/0x1970 [ath5k] ath5k_init_ah+0x6fe/0x2530 [ath5k] ? kasprintf+0xa6/0xe0 ? ath5k_stop+0x140/0x140 [ath5k] ? _dev_notice+0xf6/0xf6 ? apic_timer_interrupt+0xa/0x20 ath5k_pci_probe.cold+0x29a/0x3d6 [ath5k] ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k] ? mutex_lock+0x89/0xd0 ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k] local_pci_probe+0xd3/0x160 pci_device_probe+0x23f/0x3e0 ? pci_device_remove+0x280/0x280 ? pci_device_remove+0x280/0x280 really_probe+0x209/0x5d0 CVE-2021-47633 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: ubifs: Fix to add refcount once page is set private MM defined the rule [1] very clearly that once page was set with PG_private flag, we should increment the refcount in that page, also main flows like pageout(), migrate_page() will assume there is one additional page reference count if page_has_private() returns true. Otherwise, we may get a BUG in page migration: page:0000000080d05b9d refcount:-1 mapcount:0 mapping:000000005f4d82a8 index:0xe2 pfn:0x14c12 aops:ubifs_file_address_operations [ubifs] ino:8f1 dentry name:"f30e" flags: 0x1fffff80002405(locked|uptodate|owner_priv_1|private|node=0| zone=1|lastcpupid=0x1fffff) page dumped because: VM_BUG_ON_PAGE(page_count(page) != 0) ------------[ cut here ]------------ kernel BUG at include/linux/page_ref.h:184! invalid opcode: 0000 [#1] SMP CPU: 3 PID: 38 Comm: kcompactd0 Not tainted 5.15.0-rc5 RIP: 0010:migrate_page_move_mapping+0xac3/0xe70 Call Trace: ubifs_migrate_page+0x22/0xc0 [ubifs] move_to_new_page+0xb4/0x600 migrate_pages+0x1523/0x1cc0 compact_zone+0x8c5/0x14b0 kcompactd+0x2bc/0x560 kthread+0x18c/0x1e0 ret_from_fork+0x1f/0x30 Before the time, we should make clean a concept, what does refcount means in page gotten from grab_cache_page_write_begin(). There are 2 situations: Situation 1: refcount is 3, page is created by __page_cache_alloc. TYPE_A - the write process is using this page TYPE_B - page is assigned to one certain mapping by calling __add_to_page_cache_locked() TYPE_C - page is added into pagevec list corresponding current cpu by calling lru_cache_add() Situation 2: refcount is 2, page is gotten from the mapping's tree TYPE_B - page has been assigned to one certain mapping TYPE_A - the write process is using this page (by calling page_cache_get_speculative()) Filesystem releases one refcount by calling put_page() in xxx_write_end(), the released refcount corresponds to TYPE_A (write task is using it). If there are any processes using a page, page migration process will skip the page by judging whether expected_page_refs() equals to page refcount. The BUG is caused by following process: PA(cpu 0) kcompactd(cpu 1) compact_zone ubifs_write_begin page_a = grab_cache_page_write_begin add_to_page_cache_lru lru_cache_add pagevec_add // put page into cpu 0's pagevec (refcnf = 3, for page creation process) ubifs_write_end SetPagePrivate(page_a) // doesn't increase page count ! unlock_page(page_a) put_page(page_a) // refcnt = 2 [...] PB(cpu 0) filemap_read filemap_get_pages add_to_page_cache_lru lru_cache_add __pagevec_lru_add // traverse all pages in cpu 0's pagevec __pagevec_lru_add_fn SetPageLRU(page_a) isolate_migratepages isolate_migratepages_block get_page_unless_zero(page_a) // refcnt = 3 list_add(page_a, from_list) migrate_pages(from_list) __unmap_and_move move_to_new_page ubifs_migrate_page(page_a) migrate_page_move_mapping expected_page_refs get 3 (migration[1] + mapping[1] + private[1]) release_pages put_page_testzero(page_a) // refcnt = 3 page_ref_freeze // refcnt = 0 page_ref_dec_and_test(0 - 1 = -1) page_ref_unfreeze VM_BUG_ON_PAGE(-1 != 0, page) UBIFS doesn't increase the page refcount after setting private flag, which leads to page migration task believes the page is not used by any other processes, so the page is migrated. This causes concurrent accessing on page refcount between put_page() called by other process(eg. read process calls lru_cache_add) and page_ref_unfreeze() called by mi ---truncated--- CVE-2021-47635 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ubifs: Fix read out-of-bounds in ubifs_wbuf_write_nolock() Function ubifs_wbuf_write_nolock() may access buf out of bounds in following process: ubifs_wbuf_write_nolock(): aligned_len = ALIGN(len, 8); // Assume len = 4089, aligned_len = 4096 if (aligned_len <= wbuf->avail) ... // Not satisfy if (wbuf->used) { ubifs_leb_write() // Fill some data in avail wbuf len -= wbuf->avail; // len is still not 8-bytes aligned aligned_len -= wbuf->avail; } n = aligned_len >> c->max_write_shift; if (n) { n <<= c->max_write_shift; err = ubifs_leb_write(c, wbuf->lnum, buf + written, wbuf->offs, n); // n > len, read out of bounds less than 8(n-len) bytes } , which can be catched by KASAN: ========================================================= BUG: KASAN: slab-out-of-bounds in ecc_sw_hamming_calculate+0x1dc/0x7d0 Read of size 4 at addr ffff888105594ff8 by task kworker/u8:4/128 Workqueue: writeback wb_workfn (flush-ubifs_0_0) Call Trace: kasan_report.cold+0x81/0x165 nand_write_page_swecc+0xa9/0x160 ubifs_leb_write+0xf2/0x1b0 [ubifs] ubifs_wbuf_write_nolock+0x421/0x12c0 [ubifs] write_head+0xdc/0x1c0 [ubifs] ubifs_jnl_write_inode+0x627/0x960 [ubifs] wb_workfn+0x8af/0xb80 Function ubifs_wbuf_write_nolock() accepts that parameter 'len' is not 8 bytes aligned, the 'len' represents the true length of buf (which is allocated in 'ubifs_jnl_xxx', eg. ubifs_jnl_write_inode), so ubifs_wbuf_write_nolock() must handle the length read from 'buf' carefully to write leb safely. Fetch a reproducer in [Link]. CVE-2021-47636 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ubifs: Fix deadlock in concurrent rename whiteout and inode writeback Following hung tasks: [ 77.028764] task:kworker/u8:4 state:D stack: 0 pid: 132 [ 77.028820] Call Trace: [ 77.029027] schedule+0x8c/0x1b0 [ 77.029067] mutex_lock+0x50/0x60 [ 77.029074] ubifs_write_inode+0x68/0x1f0 [ubifs] [ 77.029117] __writeback_single_inode+0x43c/0x570 [ 77.029128] writeback_sb_inodes+0x259/0x740 [ 77.029148] wb_writeback+0x107/0x4d0 [ 77.029163] wb_workfn+0x162/0x7b0 [ 92.390442] task:aa state:D stack: 0 pid: 1506 [ 92.390448] Call Trace: [ 92.390458] schedule+0x8c/0x1b0 [ 92.390461] wb_wait_for_completion+0x82/0xd0 [ 92.390469] __writeback_inodes_sb_nr+0xb2/0x110 [ 92.390472] writeback_inodes_sb_nr+0x14/0x20 [ 92.390476] ubifs_budget_space+0x705/0xdd0 [ubifs] [ 92.390503] do_rename.cold+0x7f/0x187 [ubifs] [ 92.390549] ubifs_rename+0x8b/0x180 [ubifs] [ 92.390571] vfs_rename+0xdb2/0x1170 [ 92.390580] do_renameat2+0x554/0x770 , are caused by concurrent rename whiteout and inode writeback processes: rename_whiteout(Thread 1) wb_workfn(Thread2) ubifs_rename do_rename lock_4_inodes (Hold ui_mutex) ubifs_budget_space make_free_space shrink_liability __writeback_inodes_sb_nr bdi_split_work_to_wbs (Queue new wb work) wb_do_writeback(wb work) __writeback_single_inode ubifs_write_inode LOCK(ui_mutex) ^ wb_wait_for_completion (Wait wb work) <-- deadlock! Reproducer (Detail program in [Link]): 1. SYS_renameat2("/mp/dir/file", "/mp/dir/whiteout", RENAME_WHITEOUT) 2. Consume out of space before kernel(mdelay) doing budget for whiteout Fix it by doing whiteout space budget before locking ubifs inodes. BTW, it also fixes wrong goto tag 'out_release' in whiteout budget error handling path(It should at least recover dir i_size and unlock 4 ubifs inodes). CVE-2021-47637 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ubifs: rename_whiteout: Fix double free for whiteout_ui->data 'whiteout_ui->data' will be freed twice if space budget fail for rename whiteout operation as following process: rename_whiteout dev = kmalloc whiteout_ui->data = dev kfree(whiteout_ui->data) // Free first time iput(whiteout) ubifs_free_inode kfree(ui->data) // Double free! KASAN reports: ================================================================== BUG: KASAN: double-free or invalid-free in ubifs_free_inode+0x4f/0x70 Call Trace: kfree+0x117/0x490 ubifs_free_inode+0x4f/0x70 [ubifs] i_callback+0x30/0x60 rcu_do_batch+0x366/0xac0 __do_softirq+0x133/0x57f Allocated by task 1506: kmem_cache_alloc_trace+0x3c2/0x7a0 do_rename+0x9b7/0x1150 [ubifs] ubifs_rename+0x106/0x1f0 [ubifs] do_syscall_64+0x35/0x80 Freed by task 1506: kfree+0x117/0x490 do_rename.cold+0x53/0x8a [ubifs] ubifs_rename+0x106/0x1f0 [ubifs] do_syscall_64+0x35/0x80 The buggy address belongs to the object at ffff88810238bed8 which belongs to the cache kmalloc-8 of size 8 ================================================================== Let ubifs_free_inode() free 'whiteout_ui->data'. BTW, delete unused assignment 'whiteout_ui->data_len = 0', process 'ubifs_evict_inode() -> ubifs_jnl_delete_inode() -> ubifs_jnl_write_inode()' doesn't need it (because 'inc_nlink(whiteout)' won't be excuted by 'goto out_release', and the nlink of whiteout inode is 0). CVE-2021-47638 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Zap _all_ roots when unmapping gfn range in TDP MMU Zap both valid and invalid roots when zapping/unmapping a gfn range, as KVM must ensure it holds no references to the freed page after returning from the unmap operation. Most notably, the TDP MMU doesn't zap invalid roots in mmu_notifier callbacks. This leads to use-after-free and other issues if the mmu_notifier runs to completion while an invalid root zapper yields as KVM fails to honor the requirement that there must be _no_ references to the page after the mmu_notifier returns. The bug is most easily reproduced by hacking KVM to cause a collision between set_nx_huge_pages() and kvm_mmu_notifier_release(), but the bug exists between kvm_mmu_notifier_invalidate_range_start() and memslot updates as well. Invalidating a root ensures pages aren't accessible by the guest, and KVM won't read or write page data itself, but KVM will trigger e.g. kvm_set_pfn_dirty() when zapping SPTEs, and thus completing a zap of an invalid root _after_ the mmu_notifier returns is fatal. WARNING: CPU: 24 PID: 1496 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:173 [kvm] RIP: 0010:kvm_is_zone_device_pfn+0x96/0xa0 [kvm] Call Trace: <TASK> kvm_set_pfn_dirty+0xa8/0xe0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] zap_gfn_range+0x1f3/0x310 [kvm] kvm_tdp_mmu_zap_invalidated_roots+0x50/0x90 [kvm] kvm_mmu_zap_all_fast+0x177/0x1a0 [kvm] set_nx_huge_pages+0xb4/0x190 [kvm] param_attr_store+0x70/0x100 module_attr_store+0x19/0x30 kernfs_fop_write_iter+0x119/0x1b0 new_sync_write+0x11c/0x1b0 vfs_write+0x1cc/0x270 ksys_write+0x5f/0xe0 do_syscall_64+0x38/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae </TASK> CVE-2021-47639 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: video: fbdev: cirrusfb: check pixclock to avoid divide by zero Do a sanity check on pixclock value to avoid divide by zero. If the pixclock value is zero, the cirrusfb driver will round up pixclock to get the derived frequency as close to maxclock as possible. Syzkaller reported a divide error in cirrusfb_check_pixclock. divide error: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 14938 Comm: cirrusfb_test Not tainted 5.15.0-rc6 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2 RIP: 0010:cirrusfb_check_var+0x6f1/0x1260 Call Trace: fb_set_var+0x398/0xf90 do_fb_ioctl+0x4b8/0x6f0 fb_ioctl+0xeb/0x130 __x64_sys_ioctl+0x19d/0x220 do_syscall_64+0x3a/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae CVE-2021-47641 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: video: fbdev: nvidiafb: Use strscpy() to prevent buffer overflow Coverity complains of a possible buffer overflow. However, given the 'static' scope of nvidia_setup_i2c_bus() it looks like that can't happen after examiniing the call sites. CID 19036 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW) 1. fixed_size_dest: You might overrun the 48-character fixed-size string chan->adapter.name by copying name without checking the length. 2. parameter_as_source: Note: This defect has an elevated risk because the source argument is a parameter of the current function. 89 strcpy(chan->adapter.name, name); Fix this warning by using strscpy() which will silence the warning and prevent any future buffer overflows should the names used to identify the channel become much longer. CVE-2021-47642 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: ir_toy: free before error exiting Fix leak in error path. CVE-2021-47643 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: staging: media: zoran: move videodev alloc Move some code out of zr36057_init() and create new functions for handling zr->video_dev. This permit to ease code reading and fix a zr->video_dev memory leak. CVE-2021-47644 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: staging: media: zoran: calculate the right buffer number for zoran_reap_stat_com On the case tmp_dcim=1, the index of buffer is miscalculated. This generate a NULL pointer dereference later. So let's fix the calcul and add a check to prevent this to reappear. CVE-2021-47645 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: Revert "Revert "block, bfq: honor already-setup queue merges"" A crash [1] happened to be triggered in conjunction with commit 2d52c58b9c9b ("block, bfq: honor already-setup queue merges"). The latter was then reverted by commit ebc69e897e17 ("Revert "block, bfq: honor already-setup queue merges""). Yet, the reverted commit was not the one introducing the bug. In fact, it actually triggered a UAF introduced by a different commit, and now fixed by commit d29bd41428cf ("block, bfq: reset last_bfqq_created on group change"). So, there is no point in keeping commit 2d52c58b9c9b ("block, bfq: honor already-setup queue merges") out. This commit restores it. [1] https://bugzilla.kernel.org/show_bug.cgi?id=214503 CVE-2021-47646 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 low In the Linux kernel, the following vulnerability has been resolved: clk: qcom: ipq8074: fix PCI-E clock oops Fix PCI-E clock related kernel oops that are caused by a missing clock parent. pcie0_rchng_clk_src has num_parents set to 2 but only one parent is actually set via parent_hws, it should also have "XO" defined. This will cause the kernel to panic on a NULL pointer in clk_core_get_parent_by_index(). So, to fix this utilize clk_parent_data to provide gcc_xo_gpll0 parent data. Since there is already an existing static const char * const gcc_xo_gpll0[] used to provide the same parents via parent_names convert those users to clk_parent_data as well. Without this earlycon is needed to even catch the OOPS as it will reset the board before serial is initialized with the following: [ 0.232279] Unable to handle kernel paging request at virtual address 0000a00000000000 [ 0.232322] Mem abort info: [ 0.239094] ESR = 0x96000004 [ 0.241778] EC = 0x25: DABT (current EL), IL = 32 bits [ 0.244908] SET = 0, FnV = 0 [ 0.250377] EA = 0, S1PTW = 0 [ 0.253236] FSC = 0x04: level 0 translation fault [ 0.256277] Data abort info: [ 0.261141] ISV = 0, ISS = 0x00000004 [ 0.264262] CM = 0, WnR = 0 [ 0.267820] [0000a00000000000] address between user and kernel address ranges [ 0.270954] Internal error: Oops: 96000004 [#1] SMP [ 0.278067] Modules linked in: [ 0.282751] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.15.10 #0 [ 0.285882] Hardware name: Xiaomi AX3600 (DT) [ 0.292043] pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 0.296299] pc : clk_core_get_parent_by_index+0x68/0xec [ 0.303067] lr : __clk_register+0x1d8/0x820 [ 0.308273] sp : ffffffc01111b7d0 [ 0.312438] x29: ffffffc01111b7d0 x28: 0000000000000000 x27: 0000000000000040 [ 0.315919] x26: 0000000000000002 x25: 0000000000000000 x24: ffffff8000308800 [ 0.323037] x23: ffffff8000308850 x22: ffffff8000308880 x21: ffffff8000308828 [ 0.330155] x20: 0000000000000028 x19: ffffff8000309700 x18: 0000000000000020 [ 0.337272] x17: 000000005cc86990 x16: 0000000000000004 x15: ffffff80001d9d0a [ 0.344391] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000006 [ 0.351508] x11: 0000000000000003 x10: 0101010101010101 x9 : 0000000000000000 [ 0.358626] x8 : 7f7f7f7f7f7f7f7f x7 : 6468626f5e626266 x6 : 17000a3a403c1b06 [ 0.365744] x5 : 061b3c403a0a0017 x4 : 0000000000000000 x3 : 0000000000000001 [ 0.372863] x2 : 0000a00000000000 x1 : 0000000000000001 x0 : ffffff8000309700 [ 0.379982] Call trace: [ 0.387091] clk_core_get_parent_by_index+0x68/0xec [ 0.389351] __clk_register+0x1d8/0x820 [ 0.394210] devm_clk_hw_register+0x5c/0xe0 [ 0.398030] devm_clk_register_regmap+0x44/0x8c [ 0.402198] qcom_cc_really_probe+0x17c/0x1d0 [ 0.406711] qcom_cc_probe+0x34/0x44 [ 0.411224] gcc_ipq8074_probe+0x18/0x30 [ 0.414869] platform_probe+0x68/0xe0 [ 0.418776] really_probe.part.0+0x9c/0x30c [ 0.422336] __driver_probe_device+0x98/0x144 [ 0.426329] driver_probe_device+0x44/0x11c [ 0.430842] __device_attach_driver+0xb4/0x120 [ 0.434836] bus_for_each_drv+0x68/0xb0 [ 0.439349] __device_attach+0xb0/0x170 [ 0.443081] device_initial_probe+0x14/0x20 [ 0.446901] bus_probe_device+0x9c/0xa4 [ 0.451067] device_add+0x35c/0x834 [ 0.454886] of_device_add+0x54/0x64 [ 0.458360] of_platform_device_create_pdata+0xc0/0x100 [ 0.462181] of_platform_bus_create+0x114/0x370 [ 0.467128] of_platform_bus_create+0x15c/0x370 [ 0.471641] of_platform_populate+0x50/0xcc [ 0.476155] of_platform_default_populate_init+0xa8/0xc8 [ 0.480324] do_one_initcall+0x50/0x1b0 [ 0.485877] kernel_init_freeable+0x234/0x29c [ 0.489436] kernel_init+0x24/0x120 [ 0.493948] ret_from_fork+0x10/0x20 [ 0.497253] Code: d50323bf d65f03c0 f94002a2 b4000302 (f9400042) [ 0.501079] ---[ end trace 4ca7e1129da2abce ]--- CVE-2021-47647 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix a memory leak in 'host1x_remove()' Add a missing 'host1x_channel_list_free()' call in the remove function, as already done in the error handling path of the probe function. CVE-2021-47648 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: udmabuf: validate ubuf->pagecount Syzbot has reported GPF in sg_alloc_append_table_from_pages(). The problem was in ubuf->pages == ZERO_PTR. ubuf->pagecount is calculated from arguments passed from user-space. If user creates udmabuf with list.size == 0 then ubuf->pagecount will be also equal to zero; it causes kmalloc_array() to return ZERO_PTR. Fix it by validating ubuf->pagecount before passing it to kmalloc_array(). CVE-2021-47649 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: soc-compress: prevent the potentially use of null pointer There is one call trace that snd_soc_register_card() ->snd_soc_bind_card()->soc_init_pcm_runtime() ->snd_soc_dai_compress_new()->snd_soc_new_compress(). In the trace the 'codec_dai' transfers from card->dai_link, and we can see from the snd_soc_add_pcm_runtime() in snd_soc_bind_card() that, if value of card->dai_link->num_codecs is 0, then 'codec_dai' could be null pointer caused by index out of bound in 'asoc_rtd_to_codec(rtd, 0)'. And snd_soc_register_card() is called by various platforms. Therefore, it is better to add the check in the case of misusing. And because 'cpu_dai' has already checked in soc_init_pcm_runtime(), there is no need to check again. Adding the check as follow, then if 'codec_dai' is null, snd_soc_new_compress() will not pass through the check 'if (playback + capture != 1)', avoiding the leftover use of 'codec_dai'. CVE-2021-47650 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: soc: qcom: rpmpd: Check for null return of devm_kcalloc Because of the possible failure of the allocation, data->domains might be NULL pointer and will cause the dereference of the NULL pointer later. Therefore, it might be better to check it and directly return -ENOMEM without releasing data manually if fails, because the comment of the devm_kmalloc() says "Memory allocated with this function is automatically freed on driver detach.". CVE-2021-47651 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: video: fbdev: smscufx: Fix null-ptr-deref in ufx_usb_probe() I got a null-ptr-deref report: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... RIP: 0010:fb_destroy_modelist+0x38/0x100 ... Call Trace: ufx_usb_probe.cold+0x2b5/0xac1 [smscufx] usb_probe_interface+0x1aa/0x3c0 [usbcore] really_probe+0x167/0x460 ... ret_from_fork+0x1f/0x30 If fb_alloc_cmap() fails in ufx_usb_probe(), fb_destroy_modelist() will be called to destroy modelist in the error handling path. But modelist has not been initialized yet, so it will result in null-ptr-deref. Initialize modelist before calling fb_alloc_cmap() to fix this bug. CVE-2021-47652 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: davinci: vpif: fix use-after-free on driver unbind The driver allocates and registers two platform device structures during probe, but the devices were never deregistered on driver unbind. This results in a use-after-free on driver unbind as the device structures were allocated using devres and would be freed by driver core when remove() returns. Fix this by adding the missing deregistration calls to the remove() callback and failing probe on registration errors. Note that the platform device structures must be freed using a proper release callback to avoid leaking associated resources like device names. CVE-2021-47653 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: samples/landlock: Fix path_list memory leak Clang static analysis reports this error sandboxer.c:134:8: warning: Potential leak of memory pointed to by 'path_list' ret = 0; ^ path_list is allocated in parse_path() but never freed. CVE-2021-47654 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: jffs2: fix use-after-free in jffs2_clear_xattr_subsystem When we mount a jffs2 image, assume that the first few blocks of the image are normal and contain at least one xattr-related inode, but the next block is abnormal. As a result, an error is returned in jffs2_scan_eraseblock(). jffs2_clear_xattr_subsystem() is then called in jffs2_build_filesystem() and then again in jffs2_do_fill_super(). Finally we can observe the following report: ================================================================== BUG: KASAN: use-after-free in jffs2_clear_xattr_subsystem+0x95/0x6ac Read of size 8 at addr ffff8881243384e0 by task mount/719 Call Trace: dump_stack+0x115/0x16b jffs2_clear_xattr_subsystem+0x95/0x6ac jffs2_do_fill_super+0x84f/0xc30 jffs2_fill_super+0x2ea/0x4c0 mtd_get_sb+0x254/0x400 mtd_get_sb_by_nr+0x4f/0xd0 get_tree_mtd+0x498/0x840 jffs2_get_tree+0x25/0x30 vfs_get_tree+0x8d/0x2e0 path_mount+0x50f/0x1e50 do_mount+0x107/0x130 __se_sys_mount+0x1c5/0x2f0 __x64_sys_mount+0xc7/0x160 do_syscall_64+0x45/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Allocated by task 719: kasan_save_stack+0x23/0x60 __kasan_kmalloc.constprop.0+0x10b/0x120 kasan_slab_alloc+0x12/0x20 kmem_cache_alloc+0x1c0/0x870 jffs2_alloc_xattr_ref+0x2f/0xa0 jffs2_scan_medium.cold+0x3713/0x4794 jffs2_do_mount_fs.cold+0xa7/0x2253 jffs2_do_fill_super+0x383/0xc30 jffs2_fill_super+0x2ea/0x4c0 [...] Freed by task 719: kmem_cache_free+0xcc/0x7b0 jffs2_free_xattr_ref+0x78/0x98 jffs2_clear_xattr_subsystem+0xa1/0x6ac jffs2_do_mount_fs.cold+0x5e6/0x2253 jffs2_do_fill_super+0x383/0xc30 jffs2_fill_super+0x2ea/0x4c0 [...] The buggy address belongs to the object at ffff8881243384b8 which belongs to the cache jffs2_xattr_ref of size 48 The buggy address is located 40 bytes inside of 48-byte region [ffff8881243384b8, ffff8881243384e8) [...] ================================================================== The triggering of the BUG is shown in the following stack: ----------------------------------------------------------- jffs2_fill_super jffs2_do_fill_super jffs2_do_mount_fs jffs2_build_filesystem jffs2_scan_medium jffs2_scan_eraseblock <--- ERROR jffs2_clear_xattr_subsystem <--- free jffs2_clear_xattr_subsystem <--- free again ----------------------------------------------------------- An error is returned in jffs2_do_mount_fs(). If the error is returned by jffs2_sum_init(), the jffs2_clear_xattr_subsystem() does not need to be executed. If the error is returned by jffs2_build_filesystem(), the jffs2_clear_xattr_subsystem() also does not need to be executed again. So move jffs2_clear_xattr_subsystem() from 'out_inohash' to 'out_root' to fix this UAF problem. CVE-2021-47656 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Ensure that objs is not NULL in virtio_gpu_array_put_free() If virtio_gpu_object_shmem_init() fails (e.g. due to fault injection, as it happened in the bug report by syzbot), virtio_gpu_array_put_free() could be called with objs equal to NULL. Ensure that objs is not NULL in virtio_gpu_array_put_free(), or otherwise return from the function. CVE-2021-47657 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/plane: Move range check for format_count earlier While the check for format_count > 64 in __drm_universal_plane_init() shouldn't be hit (it's a WARN_ON), in its current position it will then leak the plane->format_types array and fail to call drm_mode_object_unregister() leaking the modeset identifier. Move it to the start of the function to avoid allocating those resources in the first place. CVE-2021-47659 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: can: etas_es58x: es58x_rx_err_msg(): fix memory leak in error path In es58x_rx_err_msg(), if can->do_set_mode() fails, the function directly returns without calling netif_rx(skb). This means that the skb previously allocated by alloc_can_err_skb() is not freed. In other terms, this is a memory leak. This patch simply removes the return statement in the error branch and let the function continue. Issue was found with GCC -fanalyzer, please follow the link below for details. CVE-2021-47671 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate A denial of service (DOS) issue was found in the Linux kernel's smb2_ioctl_query_info function in the fs/cifs/smb2ops.c Common Internet File System (CIFS) due to an incorrect return from the memdup_user function. This flaw allows a local, privileged (CAP_SYS_ADMIN) attacker to crash the system. CVE-2022-0168 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate A flaw was found in unrestricted eBPF usage by the BPF_BTF_LOAD, leading to a possible out-of-bounds memory write in the Linux kernel's BPF subsystem due to the way a user loads BTF. This flaw allows a local user to crash or escalate their privileges on the system. CVE-2022-0500 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important 7.2 AV:L/AC:L/Au:N/C:C/I:C/A:C An out-of-bounds (OOB) memory write flaw was found in the Linux kernel's watch_queue event notification subsystem. This flaw can overwrite parts of the kernel state, potentially allowing a local user to gain privileged access or cause a denial of service on the system. CVE-2022-0995 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important 7.2 AV:L/AC:L/Au:N/C:C/I:C/A:C A flaw was found in the Linux kernel in net/netfilter/nf_tables_core.c:nft_do_chain, which can cause a use-after-free. This issue needs to handle 'return' with proper preconditions, as it can lead to a kernel information leak problem caused by a local, unprivileged attacker. CVE-2022-1016 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate A use-after-free flaw was found in the Linux kernel's sound subsystem in the way a user triggers concurrent calls of PCM hw_params. The hw_free ioctls or similar race condition happens inside ALSA PCM for other ioctls. This flaw allows a local user to crash or potentially escalate their privileges on the system. CVE-2022-1048 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important 6.9 AV:L/AC:M/Au:N/C:C/I:C/A:C A use-after-free flaw was found in fs/ext4/namei.c:dx_insert_block() in the Linux kernel's filesystem sub-component. This flaw allows a local attacker with a user privilege to cause a denial of service. CVE-2022-1184 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate xmltok_impl.c in Expat (aka libexpat) before 2.4.5 lacks certain validation of encoding, such as checks for whether a UTF-8 character is valid in a certain context. CVE-2022-25235 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libexpat1-2.7.1-150400.3.28.1 important 7.5 AV:N/AC:L/Au:N/C:P/I:P/A:P xmlparse.c in Expat (aka libexpat) before 2.4.5 allows attackers to insert namespace-separator characters into namespace URIs. CVE-2022-25236 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libexpat1-2.7.1-150400.3.28.1 important 7.5 AV:N/AC:L/Au:N/C:P/I:P/A:P In Expat (aka libexpat) before 2.4.5, an attacker can trigger stack exhaustion in build_model via a large nesting depth in the DTD element. CVE-2022-25313 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libexpat1-2.7.1-150400.3.28.1 moderate 4.3 AV:N/AC:M/Au:N/C:N/I:N/A:P In Expat (aka libexpat) before 2.4.5, there is an integer overflow in copyString. CVE-2022-25314 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libexpat1-2.7.1-150400.3.28.1 important 5 AV:N/AC:L/Au:N/C:N/I:N/A:P In Expat (aka libexpat) before 2.4.5, there is an integer overflow in storeRawNames. CVE-2022-25315 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libexpat1-2.7.1-150400.3.28.1 important 7.5 AV:N/AC:L/Au:N/C:P/I:P/A:P A flaw was found in the Linux kernel implementation of proxied virtualized TPM devices. On a system where virtualized TPM devices are configured (this is not the default) a local attacker can create a use-after-free and create a situation where it may be possible to escalate privileges on the system. CVE-2022-2977 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate Mis-trained branch predictions for return instructions may allow arbitrary speculative code execution under certain microarchitecture-dependent conditions. CVE-2022-29900 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate 2.1 AV:L/AC:L/Au:N/C:P/I:N/A:N A race condition flaw was found in the Linux kernel sound subsystem due to improper locking. It could lead to a NULL pointer dereference while handling the SNDCTL_DSP_SYNC ioctl. A privileged local user (root or member of the audio group) could use this flaw to crash the system, resulting in a denial of service condition CVE-2022-3303 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate A vulnerability classified as problematic has been found in Linux Kernel. This affects the function fib_nh_match of the file net/ipv4/fib_semantics.c of the component IPv4 Handler. The manipulation leads to out-of-bounds read. It is possible to initiate the attack remotely. It is recommended to apply a patch to fix this issue. The identifier VDB-210357 was assigned to this vulnerability. CVE-2022-3435 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate A vulnerability classified as critical was found in Linux Kernel. Affected by this vulnerability is the function l2cap_reassemble_sdu of the file net/bluetooth/l2cap_core.c of the component Bluetooth. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-211087. CVE-2022-3564 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important A vulnerability has been found in Linux Kernel and classified as problematic. This vulnerability affects the function l2cap_recv_acldata of the file net/bluetooth/l2cap_core.c of the component Bluetooth. The manipulation leads to memory leak. It is recommended to apply a patch to fix this issue. VDB-211918 is the identifier assigned to this vulnerability. CVE-2022-3619 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate A vulnerability, which was classified as critical, was found in Linux Kernel. Affected is the function l2cap_conn_del of the file net/bluetooth/l2cap_core.c of the component Bluetooth. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211944. CVE-2022-3640 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important libexpat before 2.4.9 has a use-after-free in the doContent function in xmlparse.c. CVE-2022-40674 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libexpat1-2.7.1-150400.3.28.1 important In libexpat through 2.4.9, there is a use-after free caused by overeager destruction of a shared DTD in XML_ExternalEntityParserCreate in out-of-memory situations. CVE-2022-43680 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libexpat1-2.7.1-150400.3.28.1 important A use-after-free flaw caused by a race among the superblock operations in the gadgetfs Linux driver was found. It could be triggered by yanking out a device that is running the gadgetfs side. CVE-2022-4382 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important An issue was discovered in the Linux kernel through 6.0.10. l2cap_config_req in net/bluetooth/l2cap_core.c has an integer wraparound via L2CAP_CONF_REQ packets. CVE-2022-45934 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Let probe fail when workqueue cannot be enabled The workqueue is enabled when the appropriate driver is loaded and disabled when the driver is removed. When the driver is removed it assumes that the workqueue was enabled successfully and proceeds to free allocations made during workqueue enabling. Failure during workqueue enabling does not prevent the driver from being loaded. This is because the error path within drv_enable_wq() returns success unless a second failure is encountered during the error path. By returning success it is possible to load the driver even if the workqueue cannot be enabled and allocations that do not exist are attempted to be freed during driver remove. Some examples of problematic flows: (a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq(). (b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010 Fix the drv_enable_wq() error path by returning the original error that indicates failure of workqueue enabling. This ensures that the probe fails when an error is encountered and the driver remove paths are only attempted when the workqueue was enabled successfully. CVE-2022-48868 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: tty: fix possible null-ptr-defer in spk_ttyio_release Run the following tests on the qemu platform: syzkaller:~# modprobe speakup_audptr input: Speakup as /devices/virtual/input/input4 initialized device: /dev/synth, node (MAJOR 10, MINOR 125) speakup 3.1.6: initialized synth name on entry is: (null) synth probe spk_ttyio_initialise_ldisc failed because tty_kopen_exclusive returned failed (errno -16), then remove the module, we will get a null-ptr-defer problem, as follow: syzkaller:~# modprobe -r speakup_audptr releasing synth audptr BUG: kernel NULL pointer dereference, address: 0000000000000080 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP PTI CPU: 2 PID: 204 Comm: modprobe Not tainted 6.1.0-rc6-dirty #1 RIP: 0010:mutex_lock+0x14/0x30 Call Trace: <TASK> spk_ttyio_release+0x19/0x70 [speakup] synth_release.part.6+0xac/0xc0 [speakup] synth_remove+0x56/0x60 [speakup] __x64_sys_delete_module+0x156/0x250 ? fpregs_assert_state_consistent+0x1d/0x50 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> Modules linked in: speakup_audptr(-) speakup Dumping ftrace buffer: in_synth->dev was not initialized during modprobe, so we add check for in_synth->dev to fix this bug. CVE-2022-48870 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer Driver's probe allocates memory for RX FIFO (port->rx_fifo) based on default RX FIFO depth, e.g. 16. Later during serial startup the qcom_geni_serial_port_setup() updates the RX FIFO depth (port->rx_fifo_depth) to match real device capabilities, e.g. to 32. The RX UART handle code will read "port->rx_fifo_depth" number of words into "port->rx_fifo" buffer, thus exceeding the bounds. This can be observed in certain configurations with Qualcomm Bluetooth HCI UART device and KASAN: Bluetooth: hci0: QCA Product ID :0x00000010 Bluetooth: hci0: QCA SOC Version :0x400a0200 Bluetooth: hci0: QCA ROM Version :0x00000200 Bluetooth: hci0: QCA Patch Version:0x00000d2b Bluetooth: hci0: QCA controller version 0x02000200 Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2 Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2) Bluetooth: hci0: QCA Failed to download patch (-2) ================================================================== BUG: KASAN: slab-out-of-bounds in handle_rx_uart+0xa8/0x18c Write of size 4 at addr ffff279347d578c0 by task swapper/0/0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: dump_backtrace.part.0+0xe0/0xf0 show_stack+0x18/0x40 dump_stack_lvl+0x8c/0xb8 print_report+0x188/0x488 kasan_report+0xb4/0x100 __asan_store4+0x80/0xa4 handle_rx_uart+0xa8/0x18c qcom_geni_serial_handle_rx+0x84/0x9c qcom_geni_serial_isr+0x24c/0x760 __handle_irq_event_percpu+0x108/0x500 handle_irq_event+0x6c/0x110 handle_fasteoi_irq+0x138/0x2cc generic_handle_domain_irq+0x48/0x64 If the RX FIFO depth changes after probe, be sure to resize the buffer. CVE-2022-48871 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix use-after-free race condition for maps It is possible that in between calling fastrpc_map_get() until map->fl->lock is taken in fastrpc_free_map(), another thread can call fastrpc_map_lookup() and get a reference to a map that is about to be deleted. Rewrite fastrpc_map_get() to only increase the reference count of a map if it's non-zero. Propagate this to callers so they can know if a map is about to be deleted. Fixes this warning: refcount_t: addition on 0; use-after-free. WARNING: CPU: 5 PID: 10100 at lib/refcount.c:25 refcount_warn_saturate ... Call trace: refcount_warn_saturate [fastrpc_map_get inlined] [fastrpc_map_lookup inlined] fastrpc_map_create fastrpc_internal_invoke fastrpc_device_ioctl __arm64_sys_ioctl invoke_syscall CVE-2022-48872 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Don't remove map on creater_process and device_release Do not remove the map from the list on error path in fastrpc_init_create_process, instead call fastrpc_map_put, to avoid use-after-free. Do not remove it on fastrpc_device_release either, call fastrpc_map_put instead. The fastrpc_free_map is the only proper place to remove the map. This is called only after the reference count is 0. CVE-2022-48873 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: sdata can be NULL during AMPDU start ieee80211_tx_ba_session_handle_start() may get NULL for sdata when a deauthentication is ongoing. Here a trace triggering the race with the hostapd test multi_ap_fronthaul_on_ap: (gdb) list *drv_ampdu_action+0x46 0x8b16 is in drv_ampdu_action (net/mac80211/driver-ops.c:396). 391 int ret = -EOPNOTSUPP; 392 393 might_sleep(); 394 395 sdata = get_bss_sdata(sdata); 396 if (!check_sdata_in_driver(sdata)) 397 return -EIO; 398 399 trace_drv_ampdu_action(local, sdata, params); 400 wlan0: moving STA 02:00:00:00:03:00 to state 3 wlan0: associated wlan0: deauthenticating from 02:00:00:00:03:00 by local choice (Reason: 3=DEAUTH_LEAVING) wlan3.sta1: Open BA session requested for 02:00:00:00:00:00 tid 0 wlan3.sta1: dropped frame to 02:00:00:00:00:00 (unauthorized port) wlan0: moving STA 02:00:00:00:03:00 to state 2 wlan0: moving STA 02:00:00:00:03:00 to state 1 wlan0: Removed STA 02:00:00:00:03:00 wlan0: Destroyed STA 02:00:00:00:03:00 BUG: unable to handle page fault for address: fffffffffffffb48 PGD 11814067 P4D 11814067 PUD 11816067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 133397 Comm: kworker/u16:1 Tainted: G W 6.1.0-rc8-wt+ #59 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014 Workqueue: phy3 ieee80211_ba_session_work [mac80211] RIP: 0010:drv_ampdu_action+0x46/0x280 [mac80211] Code: 53 48 89 f3 be 89 01 00 00 e8 d6 43 bf ef e8 21 46 81 f0 83 bb a0 1b 00 00 04 75 0e 48 8b 9b 28 0d 00 00 48 81 eb 10 0e 00 00 <8b> 93 58 09 00 00 f6 c2 20 0f 84 3b 01 00 00 8b 05 dd 1c 0f 00 85 RSP: 0018:ffffc900025ebd20 EFLAGS: 00010287 RAX: 0000000000000000 RBX: fffffffffffff1f0 RCX: ffff888102228240 RDX: 0000000080000000 RSI: ffffffff918c5de0 RDI: ffff888102228b40 RBP: ffffc900025ebd40 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000000 R12: ffff888118c18ec0 R13: 0000000000000000 R14: ffffc900025ebd60 R15: ffff888018b7efb8 FS: 0000000000000000(0000) GS:ffff88817a600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffffffffffb48 CR3: 0000000105228006 CR4: 0000000000170ee0 Call Trace: <TASK> ieee80211_tx_ba_session_handle_start+0xd0/0x190 [mac80211] ieee80211_ba_session_work+0xff/0x2e0 [mac80211] process_one_work+0x29f/0x620 worker_thread+0x4d/0x3d0 ? process_one_work+0x620/0x620 kthread+0xfb/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> CVE-2022-48875 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Fix driver shutdown on closed serdev The driver shutdown callback (which sends EDL_SOC_RESET to the device over serdev) should not be invoked when HCI device is not open (e.g. if hci_dev_open_sync() failed), because the serdev and its TTY are not open either. Also skip this step if device is powered off (qca_power_shutdown()). The shutdown callback causes use-after-free during system reboot with Qualcomm Atheros Bluetooth: Unable to handle kernel paging request at virtual address 0072662f67726fd7 ... CPU: 6 PID: 1 Comm: systemd-shutdow Tainted: G W 6.1.0-rt5-00325-g8a5f56bcfcca #8 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: tty_driver_flush_buffer+0x4/0x30 serdev_device_write_flush+0x24/0x34 qca_serdev_shutdown+0x80/0x130 [hci_uart] device_shutdown+0x15c/0x260 kernel_restart+0x48/0xac KASAN report: BUG: KASAN: use-after-free in tty_driver_flush_buffer+0x1c/0x50 Read of size 8 at addr ffff16270c2e0018 by task systemd-shutdow/1 CPU: 7 PID: 1 Comm: systemd-shutdow Not tainted 6.1.0-next-20221220-00014-gb85aaf97fb01-dirty #28 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: dump_backtrace.part.0+0xdc/0xf0 show_stack+0x18/0x30 dump_stack_lvl+0x68/0x84 print_report+0x188/0x488 kasan_report+0xa4/0xf0 __asan_load8+0x80/0xac tty_driver_flush_buffer+0x1c/0x50 ttyport_write_flush+0x34/0x44 serdev_device_write_flush+0x48/0x60 qca_serdev_shutdown+0x124/0x274 device_shutdown+0x1e8/0x350 kernel_restart+0x48/0xb0 __do_sys_reboot+0x244/0x2d0 __arm64_sys_reboot+0x54/0x70 invoke_syscall+0x60/0x190 el0_svc_common.constprop.0+0x7c/0x160 do_el0_svc+0x44/0xf0 el0_svc+0x2c/0x6c el0t_64_sync_handler+0xbc/0x140 el0t_64_sync+0x190/0x194 CVE-2022-48878 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: efi: fix NULL-deref in init error path In cases where runtime services are not supported or have been disabled, the runtime services workqueue will never have been allocated. Do not try to destroy the workqueue unconditionally in the unlikely event that EFI initialisation fails to avoid dereferencing a NULL pointer. CVE-2022-48879 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: platform/surface: aggregator: Add missing call to ssam_request_sync_free() Although rare, ssam_request_sync_init() can fail. In that case, the request should be freed via ssam_request_sync_free(). Currently it is leaked instead. Fix this. CVE-2022-48880 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Fix swiotlb bounce buffer leak in confidential VM storvsc_queuecommand() maps the scatter/gather list using scsi_dma_map(), which in a confidential VM allocates swiotlb bounce buffers. If the I/O submission fails in storvsc_do_io(), the I/O is typically retried by higher level code, but the bounce buffer memory is never freed. The mostly like cause of I/O submission failure is a full VMBus channel ring buffer, which is not uncommon under high I/O loads. Eventually enough bounce buffer memory leaks that the confidential VM can't do any I/O. The same problem can arise in a non-confidential VM with kernel boot parameter swiotlb=force. Fix this by doing scsi_dma_unmap() in the case of an I/O submission error, which frees the bounce buffer memory. CVE-2022-48890 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: regulator: da9211: Use irq handler when ready If the system does not come from reset (like when it is kexec()), the regulator might have an IRQ waiting for us. If we enable the IRQ handler before its structures are ready, we crash. This patch fixes: [ 1.141839] Unable to handle kernel read from unreadable memory at virtual address 0000000000000078 [ 1.316096] Call trace: [ 1.316101] blocking_notifier_call_chain+0x20/0xa8 [ 1.322757] cpu cpu0: dummy supplies not allowed for exclusive requests [ 1.327823] regulator_notifier_call_chain+0x1c/0x2c [ 1.327825] da9211_irq_handler+0x68/0xf8 [ 1.327829] irq_thread+0x11c/0x234 [ 1.327833] kthread+0x13c/0x154 CVE-2022-48891 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ixgbe: fix pci device refcount leak As the comment of pci_get_domain_bus_and_slot() says, it returns a PCI device with refcount incremented, when finish using it, the caller must decrement the reference count by calling pci_dev_put(). In ixgbe_get_first_secondary_devfn() and ixgbe_x550em_a_has_mii(), pci_dev_put() is called to avoid leak. CVE-2022-48896 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer There are 3 possible interrupt sources are handled by DP controller, HPDstatus, Controller state changes and Aux read/write transaction. At every irq, DP controller have to check isr status of every interrupt sources and service the interrupt if its isr status bits shows interrupts are pending. There is potential race condition may happen at current aux isr handler implementation since it is always complete dp_aux_cmd_fifo_tx() even irq is not for aux read or write transaction. This may cause aux read transaction return premature if host aux data read is in the middle of waiting for sink to complete transferring data to host while irq happen. This will cause host's receiving buffer contains unexpected data. This patch fixes this problem by checking aux isr and return immediately at aux isr handler if there are no any isr status bits set. Current there is a bug report regrading eDP edid corruption happen during system booting up. After lengthy debugging to found that VIDEO_READY interrupt was continuously firing during system booting up which cause dp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data from aux hardware buffer which is not yet contains complete data transfer from sink. This cause edid corruption. Follows are the signature at kernel logs when problem happen, EDID has corrupt header panel-simple-dp-aux aux-aea0000.edp: Couldn't identify panel via EDID Changes in v2: -- do complete if (ret == IRQ_HANDLED) ay dp-aux_isr() -- add more commit text Changes in v3: -- add Stephen suggested -- dp_aux_isr() return IRQ_XXX back to caller -- dp_ctrl_isr() return IRQ_XXX back to caller Changes in v4: -- split into two patches Changes in v5: -- delete empty line between tags Changes in v6: -- remove extra "that" and fixed line more than 75 char at commit text Patchwork: https://patchwork.freedesktop.org/patch/516121/ CVE-2022-48898 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix GEM handle creation UAF Userspace can guess the handle value and try to race GEM object creation with handle close, resulting in a use-after-free if we dereference the object after dropping the handle's reference. For that reason, dropping the handle's reference must be done *after* we are done dereferencing the object. CVE-2022-48899 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: btrfs: fix relocation crash due to premature return from btrfs_commit_transaction() We are seeing crashes similar to the following trace: [38.969182] WARNING: CPU: 20 PID: 2105 at fs/btrfs/relocation.c:4070 btrfs_relocate_block_group+0x2dc/0x340 [btrfs] [38.973556] CPU: 20 PID: 2105 Comm: btrfs Not tainted 5.17.0-rc4 #54 [38.974580] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [38.976539] RIP: 0010:btrfs_relocate_block_group+0x2dc/0x340 [btrfs] [38.980336] RSP: 0000:ffffb0dd42e03c20 EFLAGS: 00010206 [38.981218] RAX: ffff96cfc4ede800 RBX: ffff96cfc3ce0000 RCX: 000000000002ca14 [38.982560] RDX: 0000000000000000 RSI: 4cfd109a0bcb5d7f RDI: ffff96cfc3ce0360 [38.983619] RBP: ffff96cfc309c000 R08: 0000000000000000 R09: 0000000000000000 [38.984678] R10: ffff96cec0000001 R11: ffffe84c80000000 R12: ffff96cfc4ede800 [38.985735] R13: 0000000000000000 R14: 0000000000000000 R15: ffff96cfc3ce0360 [38.987146] FS: 00007f11c15218c0(0000) GS:ffff96d6dfb00000(0000) knlGS:0000000000000000 [38.988662] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [38.989398] CR2: 00007ffc922c8e60 CR3: 00000001147a6001 CR4: 0000000000370ee0 [38.990279] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [38.991219] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [38.992528] Call Trace: [38.992854] <TASK> [38.993148] btrfs_relocate_chunk+0x27/0xe0 [btrfs] [38.993941] btrfs_balance+0x78e/0xea0 [btrfs] [38.994801] ? vsnprintf+0x33c/0x520 [38.995368] ? __kmalloc_track_caller+0x351/0x440 [38.996198] btrfs_ioctl_balance+0x2b9/0x3a0 [btrfs] [38.997084] btrfs_ioctl+0x11b0/0x2da0 [btrfs] [38.997867] ? mod_objcg_state+0xee/0x340 [38.998552] ? seq_release+0x24/0x30 [38.999184] ? proc_nr_files+0x30/0x30 [38.999654] ? call_rcu+0xc8/0x2f0 [39.000228] ? __x64_sys_ioctl+0x84/0xc0 [39.000872] ? btrfs_ioctl_get_supported_features+0x30/0x30 [btrfs] [39.001973] __x64_sys_ioctl+0x84/0xc0 [39.002566] do_syscall_64+0x3a/0x80 [39.003011] entry_SYSCALL_64_after_hwframe+0x44/0xae [39.003735] RIP: 0033:0x7f11c166959b [39.007324] RSP: 002b:00007fff2543e998 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [39.008521] RAX: ffffffffffffffda RBX: 00007f11c1521698 RCX: 00007f11c166959b [39.009833] RDX: 00007fff2543ea40 RSI: 00000000c4009420 RDI: 0000000000000003 [39.011270] RBP: 0000000000000003 R08: 0000000000000013 R09: 00007f11c16f94e0 [39.012581] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff25440df3 [39.014046] R13: 0000000000000000 R14: 00007fff2543ea40 R15: 0000000000000001 [39.015040] </TASK> [39.015418] ---[ end trace 0000000000000000 ]--- [43.131559] ------------[ cut here ]------------ [43.132234] kernel BUG at fs/btrfs/extent-tree.c:2717! [43.133031] invalid opcode: 0000 [#1] PREEMPT SMP PTI [43.133702] CPU: 1 PID: 1839 Comm: btrfs Tainted: G W 5.17.0-rc4 #54 [43.134863] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [43.136426] RIP: 0010:unpin_extent_range+0x37a/0x4f0 [btrfs] [43.139913] RSP: 0000:ffffb0dd4216bc70 EFLAGS: 00010246 [43.140629] RAX: 0000000000000000 RBX: ffff96cfc34490f8 RCX: 0000000000000001 [43.141604] RDX: 0000000080000001 RSI: 0000000051d00000 RDI: 00000000ffffffff [43.142645] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff96cfd07dca50 [43.143669] R10: ffff96cfc46e8a00 R11: fffffffffffec000 R12: 0000000041d00000 [43.144657] R13: ffff96cfc3ce0000 R14: ffffb0dd4216bd08 R15: 0000000000000000 [43.145686] FS: 00007f7657dd68c0(0000) GS:ffff96d6df640000(0000) knlGS:0000000000000000 [43.146808] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [43.147584] CR2: 00007f7fe81bf5b0 CR3: 00000001093ee004 CR4: 0000000000370ee0 [43.148589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [43.149581] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000000000 ---truncated--- CVE-2022-48903 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix I/O page table memory leak The current logic updates the I/O page table mode for the domain before calling the logic to free memory used for the page table. This results in IOMMU page table memory leak, and can be observed when launching VM w/ pass-through devices. Fix by freeing the memory used for page table before updating the mode. CVE-2022-48904 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ibmvnic: free reset-work-item when flushing Fix a tiny memory leak when flushing the reset work queue. CVE-2022-48905 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: auxdisplay: lcd2s: Fix memory leak in ->remove() Once allocated the struct lcd2s_data is never freed. Fix the memory leak by switching to devm_kzalloc(). CVE-2022-48907 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/smc: fix connection leak There's a potential leak issue under following execution sequence : smc_release smc_connect_work if (sk->sk_state == SMC_INIT) send_clc_confirim tcp_abort(); ... sk.sk_state = SMC_ACTIVE smc_close_active switch(sk->sk_state) { ... case SMC_ACTIVE: smc_close_final() // then wait peer closed Unfortunately, tcp_abort() may discard CLC CONFIRM messages that are still in the tcp send buffer, in which case our connection token cannot be delivered to the server side, which means that we cannot get a passive close message at all. Therefore, it is impossible for the to be disconnected at all. This patch tries a very simple way to avoid this issue, once the state has changed to SMC_ACTIVE after tcp_abort(), we can actively abort the smc connection, considering that the state is SMC_INIT before tcp_abort(), abandoning the complete disconnection process should not cause too much problem. In fact, this problem may exist as long as the CLC CONFIRM message is not received by the server. Whether a timer should be added after smc_close_final() needs to be discussed in the future. But even so, this patch provides a faster release for connection in above case, it should also be valuable. CVE-2022-48909 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_queue: fix possible use-after-free Eric Dumazet says: The sock_hold() side seems suspect, because there is no guarantee that sk_refcnt is not already 0. On failure, we cannot queue the packet and need to indicate an error. The packet will be dropped by the caller. v2: split skb prefetch hunk into separate change CVE-2022-48911 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: netfilter: fix use-after-free in __nf_register_net_hook() We must not dereference @new_hooks after nf_hook_mutex has been released, because other threads might have freed our allocated hooks already. BUG: KASAN: use-after-free in nf_hook_entries_get_hook_ops include/linux/netfilter.h:130 [inline] BUG: KASAN: use-after-free in hooks_validate net/netfilter/core.c:171 [inline] BUG: KASAN: use-after-free in __nf_register_net_hook+0x77a/0x820 net/netfilter/core.c:438 Read of size 2 at addr ffff88801c1a8000 by task syz-executor237/4430 CPU: 1 PID: 4430 Comm: syz-executor237 Not tainted 5.17.0-rc5-syzkaller-00306-g2293be58d6a1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x336 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 nf_hook_entries_get_hook_ops include/linux/netfilter.h:130 [inline] hooks_validate net/netfilter/core.c:171 [inline] __nf_register_net_hook+0x77a/0x820 net/netfilter/core.c:438 nf_register_net_hook+0x114/0x170 net/netfilter/core.c:571 nf_register_net_hooks+0x59/0xc0 net/netfilter/core.c:587 nf_synproxy_ipv6_init+0x85/0xe0 net/netfilter/nf_synproxy_core.c:1218 synproxy_tg6_check+0x30d/0x560 net/ipv6/netfilter/ip6t_SYNPROXY.c:81 xt_check_target+0x26c/0x9e0 net/netfilter/x_tables.c:1038 check_target net/ipv6/netfilter/ip6_tables.c:530 [inline] find_check_entry.constprop.0+0x7f1/0x9e0 net/ipv6/netfilter/ip6_tables.c:573 translate_table+0xc8b/0x1750 net/ipv6/netfilter/ip6_tables.c:735 do_replace net/ipv6/netfilter/ip6_tables.c:1153 [inline] do_ip6t_set_ctl+0x56e/0xb90 net/ipv6/netfilter/ip6_tables.c:1639 nf_setsockopt+0x83/0xe0 net/netfilter/nf_sockopt.c:101 ipv6_setsockopt+0x122/0x180 net/ipv6/ipv6_sockglue.c:1024 rawv6_setsockopt+0xd3/0x6a0 net/ipv6/raw.c:1084 __sys_setsockopt+0x2db/0x610 net/socket.c:2180 __do_sys_setsockopt net/socket.c:2191 [inline] __se_sys_setsockopt net/socket.c:2188 [inline] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2188 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f65a1ace7d9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 71 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f65a1a7f308 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 00007f65a1ace7d9 RDX: 0000000000000040 RSI: 0000000000000029 RDI: 0000000000000003 RBP: 00007f65a1b574c8 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000020000000 R11: 0000000000000246 R12: 00007f65a1b55130 R13: 00007f65a1b574c0 R14: 00007f65a1b24090 R15: 0000000000022000 </TASK> The buggy address belongs to the page: page:ffffea0000706a00 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1c1a8 flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000000000 ffffea0001c1b108 ffffea000046dd08 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as freed page last allocated via order 2, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 4430, ts 1061781545818, free_ts 1061791488993 prep_new_page mm/page_alloc.c:2434 [inline] get_page_from_freelist+0xa72/0x2f50 mm/page_alloc.c:4165 __alloc_pages+0x1b2/0x500 mm/page_alloc.c:5389 __alloc_pages_node include/linux/gfp.h:572 [inline] alloc_pages_node include/linux/gfp.h:595 [inline] kmalloc_large_node+0x62/0x130 mm/slub.c:4438 __kmalloc_node+0x35a/0x4a0 mm/slub. ---truncated--- CVE-2022-48912 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: blktrace: fix use after free for struct blk_trace When tracing the whole disk, 'dropped' and 'msg' will be created under 'q->debugfs_dir' and 'bt->dir' is NULL, thus blk_trace_free() won't remove those files. What's worse, the following UAF can be triggered because of accessing stale 'dropped' and 'msg': ================================================================== BUG: KASAN: use-after-free in blk_dropped_read+0x89/0x100 Read of size 4 at addr ffff88816912f3d8 by task blktrace/1188 CPU: 27 PID: 1188 Comm: blktrace Not tainted 5.17.0-rc4-next-20220217+ #469 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-4 Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_address_description.constprop.0.cold+0xab/0x381 ? blk_dropped_read+0x89/0x100 ? blk_dropped_read+0x89/0x100 kasan_report.cold+0x83/0xdf ? blk_dropped_read+0x89/0x100 kasan_check_range+0x140/0x1b0 blk_dropped_read+0x89/0x100 ? blk_create_buf_file_callback+0x20/0x20 ? kmem_cache_free+0xa1/0x500 ? do_sys_openat2+0x258/0x460 full_proxy_read+0x8f/0xc0 vfs_read+0xc6/0x260 ksys_read+0xb9/0x150 ? vfs_write+0x3d0/0x3d0 ? fpregs_assert_state_consistent+0x55/0x60 ? exit_to_user_mode_prepare+0x39/0x1e0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fbc080d92fd Code: ce 20 00 00 75 10 b8 00 00 00 00 0f 05 48 3d 01 f0 ff ff 73 31 c3 48 83 1 RSP: 002b:00007fbb95ff9cb0 EFLAGS: 00000293 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 00007fbb95ff9dc0 RCX: 00007fbc080d92fd RDX: 0000000000000100 RSI: 00007fbb95ff9cc0 RDI: 0000000000000045 RBP: 0000000000000045 R08: 0000000000406299 R09: 00000000fffffffd R10: 000000000153afa0 R11: 0000000000000293 R12: 00007fbb780008c0 R13: 00007fbb78000938 R14: 0000000000608b30 R15: 00007fbb780029c8 </TASK> Allocated by task 1050: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 do_blk_trace_setup+0xcb/0x410 __blk_trace_setup+0xac/0x130 blk_trace_ioctl+0xe9/0x1c0 blkdev_ioctl+0xf1/0x390 __x64_sys_ioctl+0xa5/0xe0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae Freed by task 1050: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0x103/0x180 kfree+0x9a/0x4c0 __blk_trace_remove+0x53/0x70 blk_trace_ioctl+0x199/0x1c0 blkdev_common_ioctl+0x5e9/0xb30 blkdev_ioctl+0x1a5/0x390 __x64_sys_ioctl+0xa5/0xe0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae The buggy address belongs to the object at ffff88816912f380 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 88 bytes inside of 96-byte region [ffff88816912f380, ffff88816912f3e0) The buggy address belongs to the page: page:000000009a1b4e7c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0f flags: 0x17ffffc0000200(slab|node=0|zone=2|lastcpupid=0x1fffff) raw: 0017ffffc0000200 ffffea00044f1100 dead000000000002 ffff88810004c780 raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88816912f280: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ffff88816912f300: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc >ffff88816912f380: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff88816912f400: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ffff88816912f480: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ================================================================== CVE-2022-48913 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: xen/netfront: destroy queues before real_num_tx_queues is zeroed xennet_destroy_queues() relies on info->netdev->real_num_tx_queues to delete queues. Since d7dac083414eb5bb99a6d2ed53dc2c1b405224e5 ("net-sysfs: update the queue counts in the unregistration path"), unregister_netdev() indirectly sets real_num_tx_queues to 0. Those two facts together means, that xennet_destroy_queues() called from xennet_remove() cannot do its job, because it's called after unregister_netdev(). This results in kfree-ing queues that are still linked in napi, which ultimately crashes: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 52 Comm: xenwatch Tainted: G W 5.16.10-1.32.fc32.qubes.x86_64+ #226 RIP: 0010:free_netdev+0xa3/0x1a0 Code: ff 48 89 df e8 2e e9 00 00 48 8b 43 50 48 8b 08 48 8d b8 a0 fe ff ff 48 8d a9 a0 fe ff ff 49 39 c4 75 26 eb 47 e8 ed c1 66 ff <48> 8b 85 60 01 00 00 48 8d 95 60 01 00 00 48 89 ef 48 2d 60 01 00 RSP: 0000:ffffc90000bcfd00 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88800edad000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffffc90000bcfc30 RDI: 00000000ffffffff RBP: fffffffffffffea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff88800edad050 R13: ffff8880065f8f88 R14: 0000000000000000 R15: ffff8880066c6680 FS: 0000000000000000(0000) GS:ffff8880f3300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000e998c006 CR4: 00000000003706e0 Call Trace: <TASK> xennet_remove+0x13d/0x300 [xen_netfront] xenbus_dev_remove+0x6d/0xf0 __device_release_driver+0x17a/0x240 device_release_driver+0x24/0x30 bus_remove_device+0xd8/0x140 device_del+0x18b/0x410 ? _raw_spin_unlock+0x16/0x30 ? klist_iter_exit+0x14/0x20 ? xenbus_dev_request_and_reply+0x80/0x80 device_unregister+0x13/0x60 xenbus_dev_changed+0x18e/0x1f0 xenwatch_thread+0xc0/0x1a0 ? do_wait_intr_irq+0xa0/0xa0 kthread+0x16b/0x190 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x22/0x30 </TASK> Fix this by calling xennet_destroy_queues() from xennet_uninit(), when real_num_tx_queues is still available. This ensures that queues are destroyed when real_num_tx_queues is set to 0, regardless of how unregister_netdev() was called. Originally reported at https://github.com/QubesOS/qubes-issues/issues/7257 CVE-2022-48914 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: thermal: core: Fix TZ_GET_TRIP NULL pointer dereference Do not call get_trip_hyst() from thermal_genl_cmd_tz_get_trip() if the thermal zone does not define one. CVE-2022-48915 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix double list_add when enabling VMD in scalable mode When enabling VMD and IOMMU scalable mode, the following kernel panic call trace/kernel log is shown in Eagle Stream platform (Sapphire Rapids CPU) during booting: pci 0000:59:00.5: Adding to iommu group 42 ... vmd 0000:59:00.5: PCI host bridge to bus 10000:80 pci 10000:80:01.0: [8086:352a] type 01 class 0x060400 pci 10000:80:01.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit] pci 10000:80:01.0: enabling Extended Tags pci 10000:80:01.0: PME# supported from D0 D3hot D3cold pci 10000:80:01.0: DMAR: Setup RID2PASID failed pci 10000:80:01.0: Failed to add to iommu group 42: -16 pci 10000:80:03.0: [8086:352b] type 01 class 0x060400 pci 10000:80:03.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit] pci 10000:80:03.0: enabling Extended Tags pci 10000:80:03.0: PME# supported from D0 D3hot D3cold ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.17.0-rc3+ #7 Hardware name: Lenovo ThinkSystem SR650V3/SB27A86647, BIOS ESE101Y-1.00 01/13/2022 Workqueue: events work_for_cpu_fn RIP: 0010:__list_add_valid.cold+0x26/0x3f Code: 9a 4a ab ff 4c 89 c1 48 c7 c7 40 0c d9 9e e8 b9 b1 fe ff 0f 0b 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 f0 0c d9 9e e8 a2 b1 fe ff <0f> 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 98 0c d9 9e e8 8b b1 fe RSP: 0000:ff5ad434865b3a40 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ff4d61160b74b880 RCX: ff4d61255e1fffa8 RDX: 0000000000000000 RSI: 00000000fffeffff RDI: ffffffff9fd34f20 RBP: ff4d611d8e245c00 R08: 0000000000000000 R09: ff5ad434865b3888 R10: ff5ad434865b3880 R11: ff4d61257fdc6fe8 R12: ff4d61160b74b8a0 R13: ff4d61160b74b8a0 R14: ff4d611d8e245c10 R15: ff4d611d8001ba70 FS: 0000000000000000(0000) GS:ff4d611d5ea00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ff4d611fa1401000 CR3: 0000000aa0210001 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> intel_pasid_alloc_table+0x9c/0x1d0 dmar_insert_one_dev_info+0x423/0x540 ? device_to_iommu+0x12d/0x2f0 intel_iommu_attach_device+0x116/0x290 __iommu_attach_device+0x1a/0x90 iommu_group_add_device+0x190/0x2c0 __iommu_probe_device+0x13e/0x250 iommu_probe_device+0x24/0x150 iommu_bus_notifier+0x69/0x90 blocking_notifier_call_chain+0x5a/0x80 device_add+0x3db/0x7b0 ? arch_memremap_can_ram_remap+0x19/0x50 ? memremap+0x75/0x140 pci_device_add+0x193/0x1d0 pci_scan_single_device+0xb9/0xf0 pci_scan_slot+0x4c/0x110 pci_scan_child_bus_extend+0x3a/0x290 vmd_enable_domain.constprop.0+0x63e/0x820 vmd_probe+0x163/0x190 local_pci_probe+0x42/0x80 work_for_cpu_fn+0x13/0x20 process_one_work+0x1e2/0x3b0 worker_thread+0x1c4/0x3a0 ? rescuer_thread+0x370/0x370 kthread+0xc7/0xf0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- ... Kernel panic - not syncing: Fatal exception Kernel Offset: 0x1ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]--- The following 'lspci' output shows devices '10000:80:*' are subdevices of the VMD device 0000:59:00.5: $ lspci ... 0000:59:00.5 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller (rev 20) ... 10000:80:01.0 PCI bridge: Intel Corporation Device 352a (rev 03) 10000:80:03.0 PCI bridge: Intel Corporation Device 352b (rev 03) 10000:80:05.0 PCI bridge: Intel Corporation Device 352c (rev 03) 10000:80:07.0 PCI bridge: Intel Corporation Device 352d (rev 03) 10000:81:00.0 Non-Volatile memory controller: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller] 10000:82:00 ---truncated--- CVE-2022-48916 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. CVE-2022-48917 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: iwlwifi: mvm: check debugfs_dir ptr before use When "debugfs=off" is used on the kernel command line, iwiwifi's mvm module uses an invalid/unchecked debugfs_dir pointer and causes a BUG: BUG: kernel NULL pointer dereference, address: 000000000000004f #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP CPU: 1 PID: 503 Comm: modprobe Tainted: G W 5.17.0-rc5 #7 Hardware name: Dell Inc. Inspiron 15 5510/076F7Y, BIOS 2.4.1 11/05/2021 RIP: 0010:iwl_mvm_dbgfs_register+0x692/0x700 [iwlmvm] Code: 69 a0 be 80 01 00 00 48 c7 c7 50 73 6a a0 e8 95 cf ee e0 48 8b 83 b0 1e 00 00 48 c7 c2 54 73 6a a0 be 64 00 00 00 48 8d 7d 8c <48> 8b 48 50 e8 15 22 07 e1 48 8b 43 28 48 8d 55 8c 48 c7 c7 5f 73 RSP: 0018:ffffc90000a0ba68 EFLAGS: 00010246 RAX: ffffffffffffffff RBX: ffff88817d6e3328 RCX: ffff88817d6e3328 RDX: ffffffffa06a7354 RSI: 0000000000000064 RDI: ffffc90000a0ba6c RBP: ffffc90000a0bae0 R08: ffffffff824e4880 R09: ffffffffa069d620 R10: ffffc90000a0ba00 R11: ffffffffffffffff R12: 0000000000000000 R13: ffffc90000a0bb28 R14: ffff88817d6e3328 R15: ffff88817d6e3320 FS: 00007f64dd92d740(0000) GS:ffff88847f640000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000004f CR3: 000000016fc79001 CR4: 0000000000770ee0 PKRU: 55555554 Call Trace: <TASK> ? iwl_mvm_mac_setup_register+0xbdc/0xda0 [iwlmvm] iwl_mvm_start_post_nvm+0x71/0x100 [iwlmvm] iwl_op_mode_mvm_start+0xab8/0xb30 [iwlmvm] _iwl_op_mode_start+0x6f/0xd0 [iwlwifi] iwl_opmode_register+0x6a/0xe0 [iwlwifi] ? 0xffffffffa0231000 iwl_mvm_init+0x35/0x1000 [iwlmvm] ? 0xffffffffa0231000 do_one_initcall+0x5a/0x1b0 ? kmem_cache_alloc+0x1e5/0x2f0 ? do_init_module+0x1e/0x220 do_init_module+0x48/0x220 load_module+0x2602/0x2bc0 ? __kernel_read+0x145/0x2e0 ? kernel_read_file+0x229/0x290 __do_sys_finit_module+0xc5/0x130 ? __do_sys_finit_module+0xc5/0x130 __x64_sys_finit_module+0x13/0x20 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f64dda564dd Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1b 29 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffdba393f88 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f64dda564dd RDX: 0000000000000000 RSI: 00005575399e2ab2 RDI: 0000000000000001 RBP: 000055753a91c5e0 R08: 0000000000000000 R09: 0000000000000002 R10: 0000000000000001 R11: 0000000000000246 R12: 00005575399e2ab2 R13: 000055753a91ceb0 R14: 0000000000000000 R15: 000055753a923018 </TASK> Modules linked in: btintel(+) btmtk bluetooth vfat snd_hda_codec_hdmi fat snd_hda_codec_realtek snd_hda_codec_generic iwlmvm(+) snd_sof_pci_intel_tgl mac80211 snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation soundwire_cadence soundwire_bus snd_sof_intel_hda snd_sof_pci snd_sof snd_sof_xtensa_dsp snd_soc_hdac_hda snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core btrfs snd_compress snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec raid6_pq iwlwifi snd_hda_core snd_pcm snd_timer snd soundcore cfg80211 intel_ish_ipc(+) thunderbolt rfkill intel_ishtp ucsi_acpi wmi i2c_hid_acpi i2c_hid evdev CR2: 000000000000004f ---[ end trace 0000000000000000 ]--- Check the debugfs_dir pointer for an error before using it. [change to make both conditional] CVE-2022-48918 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: cifs: fix double free race when mount fails in cifs_get_root() When cifs_get_root() fails during cifs_smb3_do_mount() we call deactivate_locked_super() which eventually will call delayed_free() which will free the context. In this situation we should not proceed to enter the out: section in cifs_smb3_do_mount() and free the same resources a second time. [Thu Feb 10 12:59:06 2022] BUG: KASAN: use-after-free in rcu_cblist_dequeue+0x32/0x60 [Thu Feb 10 12:59:06 2022] Read of size 8 at addr ffff888364f4d110 by task swapper/1/0 [Thu Feb 10 12:59:06 2022] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G OE 5.17.0-rc3+ #4 [Thu Feb 10 12:59:06 2022] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.0 12/17/2019 [Thu Feb 10 12:59:06 2022] Call Trace: [Thu Feb 10 12:59:06 2022] <IRQ> [Thu Feb 10 12:59:06 2022] dump_stack_lvl+0x5d/0x78 [Thu Feb 10 12:59:06 2022] print_address_description.constprop.0+0x24/0x150 [Thu Feb 10 12:59:06 2022] ? rcu_cblist_dequeue+0x32/0x60 [Thu Feb 10 12:59:06 2022] kasan_report.cold+0x7d/0x117 [Thu Feb 10 12:59:06 2022] ? rcu_cblist_dequeue+0x32/0x60 [Thu Feb 10 12:59:06 2022] __asan_load8+0x86/0xa0 [Thu Feb 10 12:59:06 2022] rcu_cblist_dequeue+0x32/0x60 [Thu Feb 10 12:59:06 2022] rcu_core+0x547/0xca0 [Thu Feb 10 12:59:06 2022] ? call_rcu+0x3c0/0x3c0 [Thu Feb 10 12:59:06 2022] ? __this_cpu_preempt_check+0x13/0x20 [Thu Feb 10 12:59:06 2022] ? lock_is_held_type+0xea/0x140 [Thu Feb 10 12:59:06 2022] rcu_core_si+0xe/0x10 [Thu Feb 10 12:59:06 2022] __do_softirq+0x1d4/0x67b [Thu Feb 10 12:59:06 2022] __irq_exit_rcu+0x100/0x150 [Thu Feb 10 12:59:06 2022] irq_exit_rcu+0xe/0x30 [Thu Feb 10 12:59:06 2022] sysvec_hyperv_stimer0+0x9d/0xc0 ... [Thu Feb 10 12:59:07 2022] Freed by task 58179: [Thu Feb 10 12:59:07 2022] kasan_save_stack+0x26/0x50 [Thu Feb 10 12:59:07 2022] kasan_set_track+0x25/0x30 [Thu Feb 10 12:59:07 2022] kasan_set_free_info+0x24/0x40 [Thu Feb 10 12:59:07 2022] ____kasan_slab_free+0x137/0x170 [Thu Feb 10 12:59:07 2022] __kasan_slab_free+0x12/0x20 [Thu Feb 10 12:59:07 2022] slab_free_freelist_hook+0xb3/0x1d0 [Thu Feb 10 12:59:07 2022] kfree+0xcd/0x520 [Thu Feb 10 12:59:07 2022] cifs_smb3_do_mount+0x149/0xbe0 [cifs] [Thu Feb 10 12:59:07 2022] smb3_get_tree+0x1a0/0x2e0 [cifs] [Thu Feb 10 12:59:07 2022] vfs_get_tree+0x52/0x140 [Thu Feb 10 12:59:07 2022] path_mount+0x635/0x10c0 [Thu Feb 10 12:59:07 2022] __x64_sys_mount+0x1bf/0x210 [Thu Feb 10 12:59:07 2022] do_syscall_64+0x5c/0xc0 [Thu Feb 10 12:59:07 2022] entry_SYSCALL_64_after_hwframe+0x44/0xae [Thu Feb 10 12:59:07 2022] Last potentially related work creation: [Thu Feb 10 12:59:07 2022] kasan_save_stack+0x26/0x50 [Thu Feb 10 12:59:07 2022] __kasan_record_aux_stack+0xb6/0xc0 [Thu Feb 10 12:59:07 2022] kasan_record_aux_stack_noalloc+0xb/0x10 [Thu Feb 10 12:59:07 2022] call_rcu+0x76/0x3c0 [Thu Feb 10 12:59:07 2022] cifs_umount+0xce/0xe0 [cifs] [Thu Feb 10 12:59:07 2022] cifs_kill_sb+0xc8/0xe0 [cifs] [Thu Feb 10 12:59:07 2022] deactivate_locked_super+0x5d/0xd0 [Thu Feb 10 12:59:07 2022] cifs_smb3_do_mount+0xab9/0xbe0 [cifs] [Thu Feb 10 12:59:07 2022] smb3_get_tree+0x1a0/0x2e0 [cifs] [Thu Feb 10 12:59:07 2022] vfs_get_tree+0x52/0x140 [Thu Feb 10 12:59:07 2022] path_mount+0x635/0x10c0 [Thu Feb 10 12:59:07 2022] __x64_sys_mount+0x1bf/0x210 [Thu Feb 10 12:59:07 2022] do_syscall_64+0x5c/0xc0 [Thu Feb 10 12:59:07 2022] entry_SYSCALL_64_after_hwframe+0x44/0xae CVE-2022-48919 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: sched/fair: Fix fault in reweight_entity Syzbot found a GPF in reweight_entity. This has been bisected to commit 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an invalid sched_task_group") There is a race between sched_post_fork() and setpriority(PRIO_PGRP) within a thread group that causes a null-ptr-deref in reweight_entity() in CFS. The scenario is that the main process spawns number of new threads, which then call setpriority(PRIO_PGRP, 0, -20), wait, and exit. For each of the new threads the copy_process() gets invoked, which adds the new task_struct and calls sched_post_fork() for it. In the above scenario there is a possibility that setpriority(PRIO_PGRP) and set_one_prio() will be called for a thread in the group that is just being created by copy_process(), and for which the sched_post_fork() has not been executed yet. This will trigger a null pointer dereference in reweight_entity(), as it will try to access the run queue pointer, which hasn't been set. Before the mentioned change the cfs_rq pointer for the task has been set in sched_fork(), which is called much earlier in copy_process(), before the new task is added to the thread_group. Now it is done in the sched_post_fork(), which is called after that. To fix the issue the remove the update_load param from the update_load param() function and call reweight_task() only if the task flag doesn't have the TASK_NEW flag set. CVE-2022-48921 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: btrfs: prevent copying too big compressed lzo segment Compressed length can be corrupted to be a lot larger than memory we have allocated for buffer. This will cause memcpy in copy_compressed_segment to write outside of allocated memory. This mostly results in stuck read syscall but sometimes when using btrfs send can get #GP kernel: general protection fault, probably for non-canonical address 0x841551d5c1000: 0000 [#1] PREEMPT SMP NOPTI kernel: CPU: 17 PID: 264 Comm: kworker/u256:7 Tainted: P OE 5.17.0-rc2-1 #12 kernel: Workqueue: btrfs-endio btrfs_work_helper [btrfs] kernel: RIP: 0010:lzo_decompress_bio (./include/linux/fortify-string.h:225 fs/btrfs/lzo.c:322 fs/btrfs/lzo.c:394) btrfs Code starting with the faulting instruction =========================================== 0:* 48 8b 06 mov (%rsi),%rax <-- trapping instruction 3: 48 8d 79 08 lea 0x8(%rcx),%rdi 7: 48 83 e7 f8 and $0xfffffffffffffff8,%rdi b: 48 89 01 mov %rax,(%rcx) e: 44 89 f0 mov %r14d,%eax 11: 48 8b 54 06 f8 mov -0x8(%rsi,%rax,1),%rdx kernel: RSP: 0018:ffffb110812efd50 EFLAGS: 00010212 kernel: RAX: 0000000000001000 RBX: 000000009ca264c8 RCX: ffff98996e6d8ff8 kernel: RDX: 0000000000000064 RSI: 000841551d5c1000 RDI: ffffffff9500435d kernel: RBP: ffff989a3be856c0 R08: 0000000000000000 R09: 0000000000000000 kernel: R10: 0000000000000000 R11: 0000000000001000 R12: ffff98996e6d8000 kernel: R13: 0000000000000008 R14: 0000000000001000 R15: 000841551d5c1000 kernel: FS: 0000000000000000(0000) GS:ffff98a09d640000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 00001e9f984d9ea8 CR3: 000000014971a000 CR4: 00000000003506e0 kernel: Call Trace: kernel: <TASK> kernel: end_compressed_bio_read (fs/btrfs/compression.c:104 fs/btrfs/compression.c:1363 fs/btrfs/compression.c:323) btrfs kernel: end_workqueue_fn (fs/btrfs/disk-io.c:1923) btrfs kernel: btrfs_work_helper (fs/btrfs/async-thread.c:326) btrfs kernel: process_one_work (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:212 ./include/trace/events/workqueue.h:108 kernel/workqueue.c:2312) kernel: worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2455) kernel: ? process_one_work (kernel/workqueue.c:2397) kernel: kthread (kernel/kthread.c:377) kernel: ? kthread_complete_and_exit (kernel/kthread.c:332) kernel: ret_from_fork (arch/x86/entry/entry_64.S:301) kernel: </TASK> CVE-2022-48923 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: thermal: int340x: fix memory leak in int3400_notify() It is easy to hit the below memory leaks in my TigerLake platform: unreferenced object 0xffff927c8b91dbc0 (size 32): comm "kworker/0:2", pid 112, jiffies 4294893323 (age 83.604s) hex dump (first 32 bytes): 4e 41 4d 45 3d 49 4e 54 33 34 30 30 20 54 68 65 NAME=INT3400 The 72 6d 61 6c 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 rmal.kkkkkkkkkk. backtrace: [<ffffffff9c502c3e>] __kmalloc_track_caller+0x2fe/0x4a0 [<ffffffff9c7b7c15>] kvasprintf+0x65/0xd0 [<ffffffff9c7b7d6e>] kasprintf+0x4e/0x70 [<ffffffffc04cb662>] int3400_notify+0x82/0x120 [int3400_thermal] [<ffffffff9c8b7358>] acpi_ev_notify_dispatch+0x54/0x71 [<ffffffff9c88f1a7>] acpi_os_execute_deferred+0x17/0x30 [<ffffffff9c2c2c0a>] process_one_work+0x21a/0x3f0 [<ffffffff9c2c2e2a>] worker_thread+0x4a/0x3b0 [<ffffffff9c2cb4dd>] kthread+0xfd/0x130 [<ffffffff9c201c1f>] ret_from_fork+0x1f/0x30 Fix it by calling kfree() accordingly. CVE-2022-48924 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Do not change route.addr.src_addr outside state checks If the state is not idle then resolve_prepare_src() should immediately fail and no change to global state should happen. However, it unconditionally overwrites the src_addr trying to build a temporary any address. For instance if the state is already RDMA_CM_LISTEN then this will corrupt the src_addr and would cause the test in cma_cancel_operation(): if (cma_any_addr(cma_src_addr(id_priv)) && !id_priv->cma_dev) Which would manifest as this trace from syzkaller: BUG: KASAN: use-after-free in __list_add_valid+0x93/0xa0 lib/list_debug.c:26 Read of size 8 at addr ffff8881546491e0 by task syz-executor.1/32204 CPU: 1 PID: 32204 Comm: syz-executor.1 Not tainted 5.12.0-rc8-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:232 __kasan_report mm/kasan/report.c:399 [inline] kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416 __list_add_valid+0x93/0xa0 lib/list_debug.c:26 __list_add include/linux/list.h:67 [inline] list_add_tail include/linux/list.h:100 [inline] cma_listen_on_all drivers/infiniband/core/cma.c:2557 [inline] rdma_listen+0x787/0xe00 drivers/infiniband/core/cma.c:3751 ucma_listen+0x16a/0x210 drivers/infiniband/core/ucma.c:1102 ucma_write+0x259/0x350 drivers/infiniband/core/ucma.c:1732 vfs_write+0x28e/0xa30 fs/read_write.c:603 ksys_write+0x1ee/0x250 fs/read_write.c:658 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae This is indicating that an rdma_id_private was destroyed without doing cma_cancel_listens(). Instead of trying to re-use the src_addr memory to indirectly create an any address derived from the dst build one explicitly on the stack and bind to that as any other normal flow would do. rdma_bind_addr() will copy it over the src_addr once it knows the state is valid. This is similar to commit bc0bdc5afaa7 ("RDMA/cma: Do not change route.addr.src_addr.ss_family") CVE-2022-48925 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: gadget: rndis: add spinlock for rndis response list There's no lock for rndis response list. It could cause list corruption if there're two different list_add at the same time like below. It's better to add in rndis_add_response / rndis_free_response / rndis_get_next_response to prevent any race condition on response list. [ 361.894299] [1: irq/191-dwc3:16979] list_add corruption. next->prev should be prev (ffffff80651764d0), but was ffffff883dc36f80. (next=ffffff80651764d0). [ 361.904380] [1: irq/191-dwc3:16979] Call trace: [ 361.904391] [1: irq/191-dwc3:16979] __list_add_valid+0x74/0x90 [ 361.904401] [1: irq/191-dwc3:16979] rndis_msg_parser+0x168/0x8c0 [ 361.904409] [1: irq/191-dwc3:16979] rndis_command_complete+0x24/0x84 [ 361.904417] [1: irq/191-dwc3:16979] usb_gadget_giveback_request+0x20/0xe4 [ 361.904426] [1: irq/191-dwc3:16979] dwc3_gadget_giveback+0x44/0x60 [ 361.904434] [1: irq/191-dwc3:16979] dwc3_ep0_complete_data+0x1e8/0x3a0 [ 361.904442] [1: irq/191-dwc3:16979] dwc3_ep0_interrupt+0x29c/0x3dc [ 361.904450] [1: irq/191-dwc3:16979] dwc3_process_event_entry+0x78/0x6cc [ 361.904457] [1: irq/191-dwc3:16979] dwc3_process_event_buf+0xa0/0x1ec [ 361.904465] [1: irq/191-dwc3:16979] dwc3_thread_interrupt+0x34/0x5c CVE-2022-48926 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: iio: adc: tsc2046: fix memory corruption by preventing array overflow On one side we have indio_dev->num_channels includes all physical channels + timestamp channel. On other side we have an array allocated only for physical channels. So, fix memory corruption by ARRAY_SIZE() instead of num_channels variable. Note the first case is a cleanup rather than a fix as the software timestamp channel bit in active_scanmask is never set by the IIO core. CVE-2022-48927 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: iio: adc: men_z188_adc: Fix a resource leak in an error handling path If iio_device_register() fails, a previous ioremap() is left unbalanced. Update the error handling path and add the missing iounmap() call, as already done in the remove function. CVE-2022-48928 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/ib_srp: Fix a deadlock Remove the flush_workqueue(system_long_wq) call since flushing system_long_wq is deadlock-prone and since that call is redundant with a preceding cancel_work_sync() CVE-2022-48930 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: configfs: fix a race in configfs_{,un}register_subsystem() When configfs_register_subsystem() or configfs_unregister_subsystem() is executing link_group() or unlink_group(), it is possible that two processes add or delete list concurrently. Some unfortunate interleavings of them can cause kernel panic. One of cases is: A --> B --> C --> D A <-- B <-- C <-- D delete list_head *B | delete list_head *C --------------------------------|----------------------------------- configfs_unregister_subsystem | configfs_unregister_subsystem unlink_group | unlink_group unlink_obj | unlink_obj list_del_init | list_del_init __list_del_entry | __list_del_entry __list_del | __list_del // next == C | next->prev = prev | | next->prev = prev prev->next = next | | // prev == B | prev->next = next Fix this by adding mutex when calling link_group() or unlink_group(), but parent configfs_subsystem is NULL when config_item is root. So I create a mutex configfs_subsystem_mutex. CVE-2022-48931 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/mlx5: DR, Fix slab-out-of-bounds in mlx5_cmd_dr_create_fte When adding a rule with 32 destinations, we hit the following out-of-band access issue: BUG: KASAN: slab-out-of-bounds in mlx5_cmd_dr_create_fte+0x18ee/0x1e70 This patch fixes the issue by both increasing the allocated buffers to accommodate for the needed actions and by checking the number of actions to prevent this issue when a rule with too many actions is provided. CVE-2022-48932 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfp: flower: Fix a potential leak in nfp_tunnel_add_shared_mac() ida_simple_get() returns an id between min (0) and max (NFP_MAX_MAC_INDEX) inclusive. So NFP_MAX_MAC_INDEX (0xff) is a valid id. In order for the error handling path to work correctly, the 'invalid' value for 'ida_idx' should not be in the 0..NFP_MAX_MAC_INDEX range, inclusive. So set it to -1. CVE-2022-48934 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unregister flowtable hooks on netns exit Unregister flowtable hooks before they are releases via nf_tables_flowtable_destroy() otherwise hook core reports UAF. BUG: KASAN: use-after-free in nf_hook_entries_grow+0x5a7/0x700 net/netfilter/core.c:142 net/netfilter/core.c:142 Read of size 4 at addr ffff8880736f7438 by task syz-executor579/3666 CPU: 0 PID: 3666 Comm: syz-executor579 Not tainted 5.16.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] __dump_stack lib/dump_stack.c:88 [inline] lib/dump_stack.c:106 dump_stack_lvl+0x1dc/0x2d8 lib/dump_stack.c:106 lib/dump_stack.c:106 print_address_description+0x65/0x380 mm/kasan/report.c:247 mm/kasan/report.c:247 __kasan_report mm/kasan/report.c:433 [inline] __kasan_report mm/kasan/report.c:433 [inline] mm/kasan/report.c:450 kasan_report+0x19a/0x1f0 mm/kasan/report.c:450 mm/kasan/report.c:450 nf_hook_entries_grow+0x5a7/0x700 net/netfilter/core.c:142 net/netfilter/core.c:142 __nf_register_net_hook+0x27e/0x8d0 net/netfilter/core.c:429 net/netfilter/core.c:429 nf_register_net_hook+0xaa/0x180 net/netfilter/core.c:571 net/netfilter/core.c:571 nft_register_flowtable_net_hooks+0x3c5/0x730 net/netfilter/nf_tables_api.c:7232 net/netfilter/nf_tables_api.c:7232 nf_tables_newflowtable+0x2022/0x2cf0 net/netfilter/nf_tables_api.c:7430 net/netfilter/nf_tables_api.c:7430 nfnetlink_rcv_batch net/netfilter/nfnetlink.c:513 [inline] nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:634 [inline] nfnetlink_rcv_batch net/netfilter/nfnetlink.c:513 [inline] net/netfilter/nfnetlink.c:652 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:634 [inline] net/netfilter/nfnetlink.c:652 nfnetlink_rcv+0x10e6/0x2550 net/netfilter/nfnetlink.c:652 net/netfilter/nfnetlink.c:652 __nft_release_hook() calls nft_unregister_flowtable_net_hooks() which only unregisters the hooks, then after RCU grace period, it is guaranteed that no packets add new entries to the flowtable (no flow offload rules and flowtable hooks are reachable from packet path), so it is safe to call nf_flow_table_free() which cleans up the remaining entries from the flowtable (both software and hardware) and it unbinds the flow_block. CVE-2022-48935 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: io_uring: add a schedule point in io_add_buffers() Looping ~65535 times doing kmalloc() calls can trigger soft lockups, especially with DEBUG features (like KASAN). [ 253.536212] watchdog: BUG: soft lockup - CPU#64 stuck for 26s! [b219417889:12575] [ 253.544433] Modules linked in: vfat fat i2c_mux_pca954x i2c_mux spidev cdc_acm xhci_pci xhci_hcd sha3_generic gq(O) [ 253.544451] CPU: 64 PID: 12575 Comm: b219417889 Tainted: G S O 5.17.0-smp-DEV #801 [ 253.544457] RIP: 0010:kernel_text_address (./include/asm-generic/sections.h:192 ./include/linux/kallsyms.h:29 kernel/extable.c:67 kernel/extable.c:98) [ 253.544464] Code: 0f 93 c0 48 c7 c1 e0 63 d7 a4 48 39 cb 0f 92 c1 20 c1 0f b6 c1 5b 5d c3 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 53 48 89 fb <48> c7 c0 00 00 80 a0 41 be 01 00 00 00 48 39 c7 72 0c 48 c7 c0 40 [ 253.544468] RSP: 0018:ffff8882d8baf4c0 EFLAGS: 00000246 [ 253.544471] RAX: 1ffff1105b175e00 RBX: ffffffffa13ef09a RCX: 00000000a13ef001 [ 253.544474] RDX: ffffffffa13ef09a RSI: ffff8882d8baf558 RDI: ffffffffa13ef09a [ 253.544476] RBP: ffff8882d8baf4d8 R08: ffff8882d8baf5e0 R09: 0000000000000004 [ 253.544479] R10: ffff8882d8baf5e8 R11: ffffffffa0d59a50 R12: ffff8882eab20380 [ 253.544481] R13: ffffffffa0d59a50 R14: dffffc0000000000 R15: 1ffff1105b175eb0 [ 253.544483] FS: 00000000016d3380(0000) GS:ffff88af48c00000(0000) knlGS:0000000000000000 [ 253.544486] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 253.544488] CR2: 00000000004af0f0 CR3: 00000002eabfa004 CR4: 00000000003706e0 [ 253.544491] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 253.544492] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 253.544494] Call Trace: [ 253.544496] <TASK> [ 253.544498] ? io_queue_sqe (fs/io_uring.c:7143) [ 253.544505] __kernel_text_address (kernel/extable.c:78) [ 253.544508] unwind_get_return_address (arch/x86/kernel/unwind_frame.c:19) [ 253.544514] arch_stack_walk (arch/x86/kernel/stacktrace.c:27) [ 253.544517] ? io_queue_sqe (fs/io_uring.c:7143) [ 253.544521] stack_trace_save (kernel/stacktrace.c:123) [ 253.544527] ____kasan_kmalloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:515) [ 253.544531] ? ____kasan_kmalloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:515) [ 253.544533] ? __kasan_kmalloc (mm/kasan/common.c:524) [ 253.544535] ? kmem_cache_alloc_trace (./include/linux/kasan.h:270 mm/slab.c:3567) [ 253.544541] ? io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828) [ 253.544544] ? __io_queue_sqe (fs/io_uring.c:?) [ 253.544551] __kasan_kmalloc (mm/kasan/common.c:524) [ 253.544553] kmem_cache_alloc_trace (./include/linux/kasan.h:270 mm/slab.c:3567) [ 253.544556] ? io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828) [ 253.544560] io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828) [ 253.544564] ? __kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469) [ 253.544567] ? __kasan_slab_alloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469) [ 253.544569] ? kmem_cache_alloc_bulk (mm/slab.h:732 mm/slab.c:3546) [ 253.544573] ? __io_alloc_req_refill (fs/io_uring.c:2078) [ 253.544578] ? io_submit_sqes (fs/io_uring.c:7441) [ 253.544581] ? __se_sys_io_uring_enter (fs/io_uring.c:10154 fs/io_uring.c:10096) [ 253.544584] ? __x64_sys_io_uring_enter (fs/io_uring.c:10096) [ 253.544587] ? do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) [ 253.544590] ? entry_SYSCALL_64_after_hwframe (??:?) [ 253.544596] __io_queue_sqe (fs/io_uring.c:?) [ 253.544600] io_queue_sqe (fs/io_uring.c:7143) [ 253.544603] io_submit_sqe (fs/io_uring.c:?) [ 253.544608] io_submit_sqes (fs/io_uring.c:?) [ 253.544612] __se_sys_io_uring_enter (fs/io_uring.c:10154 fs/io_uri ---truncated--- CVE-2022-48937 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: CDC-NCM: avoid overflow in sanity checking A broken device may give an extreme offset like 0xFFF0 and a reasonable length for a fragment. In the sanity check as formulated now, this will create an integer overflow, defeating the sanity check. Both offset and offset + len need to be checked in such a manner that no overflow can occur. And those quantities should be unsigned. CVE-2022-48938 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ice: fix concurrent reset and removal of VFs Commit c503e63200c6 ("ice: Stop processing VF messages during teardown") introduced a driver state flag, ICE_VF_DEINIT_IN_PROGRESS, which is intended to prevent some issues with concurrently handling messages from VFs while tearing down the VFs. This change was motivated by crashes caused while tearing down and bringing up VFs in rapid succession. It turns out that the fix actually introduces issues with the VF driver caused because the PF no longer responds to any messages sent by the VF during its .remove routine. This results in the VF potentially removing its DMA memory before the PF has shut down the device queues. Additionally, the fix doesn't actually resolve concurrency issues within the ice driver. It is possible for a VF to initiate a reset just prior to the ice driver removing VFs. This can result in the remove task concurrently operating while the VF is being reset. This results in similar memory corruption and panics purportedly fixed by that commit. Fix this concurrency at its root by protecting both the reset and removal flows using the existing VF cfg_lock. This ensures that we cannot remove the VF while any outstanding critical tasks such as a virtchnl message or a reset are occurring. This locking change also fixes the root cause originally fixed by commit c503e63200c6 ("ice: Stop processing VF messages during teardown"), so we can simply revert it. Note that I kept these two changes together because simply reverting the original commit alone would leave the driver vulnerable to worse race conditions. CVE-2022-48941 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: hwmon: Handle failure to register sensor with thermal zone correctly If an attempt is made to a sensor with a thermal zone and it fails, the call to devm_thermal_zone_of_sensor_register() may return -ENODEV. This may result in crashes similar to the following. Unable to handle kernel NULL pointer dereference at virtual address 00000000000003cd ... Internal error: Oops: 96000021 [#1] PREEMPT SMP ... pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mutex_lock+0x18/0x60 lr : thermal_zone_device_update+0x40/0x2e0 sp : ffff800014c4fc60 x29: ffff800014c4fc60 x28: ffff365ee3f6e000 x27: ffffdde218426790 x26: ffff365ee3f6e000 x25: 0000000000000000 x24: ffff365ee3f6e000 x23: ffffdde218426870 x22: ffff365ee3f6e000 x21: 00000000000003cd x20: ffff365ee8bf3308 x19: ffffffffffffffed x18: 0000000000000000 x17: ffffdde21842689c x16: ffffdde1cb7a0b7c x15: 0000000000000040 x14: ffffdde21a4889a0 x13: 0000000000000228 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000001120000 x7 : 0000000000000001 x6 : 0000000000000000 x5 : 0068000878e20f07 x4 : 0000000000000000 x3 : 00000000000003cd x2 : ffff365ee3f6e000 x1 : 0000000000000000 x0 : 00000000000003cd Call trace: mutex_lock+0x18/0x60 hwmon_notify_event+0xfc/0x110 0xffffdde1cb7a0a90 0xffffdde1cb7a0b7c irq_thread_fn+0x2c/0xa0 irq_thread+0x134/0x240 kthread+0x178/0x190 ret_from_fork+0x10/0x20 Code: d503201f d503201f d2800001 aa0103e4 (c8e47c02) Jon Hunter reports that the exact call sequence is: hwmon_notify_event() --> hwmon_thermal_notify() --> thermal_zone_device_update() --> update_temperature() --> mutex_lock() The hwmon core needs to handle all errors returned from calls to devm_thermal_zone_of_sensor_register(). If the call fails with -ENODEV, report that the sensor was not attached to a thermal zone but continue to register the hwmon device. CVE-2022-48942 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: make apf token non-zero to fix bug In current async pagefault logic, when a page is ready, KVM relies on kvm_arch_can_dequeue_async_page_present() to determine whether to deliver a READY event to the Guest. This function test token value of struct kvm_vcpu_pv_apf_data, which must be reset to zero by Guest kernel when a READY event is finished by Guest. If value is zero meaning that a READY event is done, so the KVM can deliver another. But the kvm_arch_setup_async_pf() may produce a valid token with zero value, which is confused with previous mention and may lead the loss of this READY event. This bug may cause task blocked forever in Guest: INFO: task stress:7532 blocked for more than 1254 seconds. Not tainted 5.10.0 #16 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:stress state:D stack: 0 pid: 7532 ppid: 1409 flags:0x00000080 Call Trace: __schedule+0x1e7/0x650 schedule+0x46/0xb0 kvm_async_pf_task_wait_schedule+0xad/0xe0 ? exit_to_user_mode_prepare+0x60/0x70 __kvm_handle_async_pf+0x4f/0xb0 ? asm_exc_page_fault+0x8/0x30 exc_page_fault+0x6f/0x110 ? asm_exc_page_fault+0x8/0x30 asm_exc_page_fault+0x1e/0x30 RIP: 0033:0x402d00 RSP: 002b:00007ffd31912500 EFLAGS: 00010206 RAX: 0000000000071000 RBX: ffffffffffffffff RCX: 00000000021a32b0 RDX: 000000000007d011 RSI: 000000000007d000 RDI: 00000000021262b0 RBP: 00000000021262b0 R08: 0000000000000003 R09: 0000000000000086 R10: 00000000000000eb R11: 00007fefbdf2baa0 R12: 0000000000000000 R13: 0000000000000002 R14: 000000000007d000 R15: 0000000000001000 CVE-2022-48943 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: sched: Fix yet more sched_fork() races Where commit 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an invalid sched_task_group") fixed a fork race vs cgroup, it opened up a race vs syscalls by not placing the task on the runqueue before it gets exposed through the pidhash. Commit 13765de8148f ("sched/fair: Fix fault in reweight_entity") is trying to fix a single instance of this, instead fix the whole class of issues, effectively reverting this commit. CVE-2022-48944 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix compose size exceed boundary syzkaller found a bug: BUG: unable to handle page fault for address: ffffc9000a3b1000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10015f067 PMD 1121ca067 PTE 0 Oops: 0002 [#1] PREEMPT SMP CPU: 0 PID: 23489 Comm: vivid-000-vid-c Not tainted 6.1.0-rc1+ #512 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:memcpy_erms+0x6/0x10 [...] Call Trace: <TASK> ? tpg_fill_plane_buffer+0x856/0x15b0 vivid_fillbuff+0x8ac/0x1110 vivid_thread_vid_cap_tick+0x361/0xc90 vivid_thread_vid_cap+0x21a/0x3a0 kthread+0x143/0x180 ret_from_fork+0x1f/0x30 </TASK> This is because we forget to check boundary after adjust compose->height int V4L2_SEL_TGT_CROP case. Add v4l2_rect_map_inside() to fix this problem for this case. CVE-2022-48945 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: udf: Fix preallocation discarding at indirect extent boundary When preallocation extent is the first one in the extent block, the code would corrupt extent tree header instead. Fix the problem and use udf_delete_aext() for deleting extent to avoid some code duplication. CVE-2022-48946 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Prevent buffer overflow in setup handler Setup function uvc_function_setup permits control transfer requests with up to 64 bytes of payload (UVC_MAX_REQUEST_SIZE), data stage handler for OUT transfer uses memcpy to copy req->actual bytes to uvc_event->data.data array of size 60. This may result in an overflow of 4 bytes. CVE-2022-48948 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: igb: Initialize mailbox message for VF reset When a MAC address is not assigned to the VF, that portion of the message sent to the VF is not set. The memory, however, is allocated from the stack meaning that information may be leaked to the VM. Initialize the message buffer to 0 so that no information is passed to the VM in this case. CVE-2022-48949 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx() The bounds checks in snd_soc_put_volsw_sx() are only being applied to the first channel, meaning it is possible to write out of bounds values to the second channel in stereo controls. Add appropriate checks. CVE-2022-48951 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: rtc: cmos: Fix event handler registration ordering issue Because acpi_install_fixed_event_handler() enables the event automatically on success, it is incorrect to call it before the handler routine passed to it is ready to handle events. Unfortunately, the rtc-cmos driver does exactly the incorrect thing by calling cmos_wake_setup(), which passes rtc_handler() to acpi_install_fixed_event_handler(), before cmos_do_probe(), because rtc_handler() uses dev_get_drvdata() to get to the cmos object pointer and the driver data pointer is only populated in cmos_do_probe(). This leads to a NULL pointer dereference in rtc_handler() on boot if the RTC fixed event happens to be active at the init time. To address this issue, change the initialization ordering of the driver so that cmos_wake_setup() is always called after a successful cmos_do_probe() call. While at it, change cmos_pnp_probe() to call cmos_do_probe() after the initial if () statement used for computing the IRQ argument to be passed to cmos_do_probe() which is cleaner than calling it in each branch of that if () (local variable "irq" can be of type int, because it is passed to that function as an argument of type int). Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number of systems, because previously it only affected systems with ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that commit. CVE-2022-48953 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: s390/qeth: fix use-after-free in hsci KASAN found that addr was dereferenced after br2dev_event_work was freed. ================================================================== BUG: KASAN: use-after-free in qeth_l2_br2dev_worker+0x5ba/0x6b0 Read of size 1 at addr 00000000fdcea440 by task kworker/u760:4/540 CPU: 17 PID: 540 Comm: kworker/u760:4 Tainted: G E 6.1.0-20221128.rc7.git1.5aa3bed4ce83.300.fc36.s390x+kasan #1 Hardware name: IBM 8561 T01 703 (LPAR) Workqueue: 0.0.8000_event qeth_l2_br2dev_worker Call Trace: [<000000016944d4ce>] dump_stack_lvl+0xc6/0xf8 [<000000016942cd9c>] print_address_description.constprop.0+0x34/0x2a0 [<000000016942d118>] print_report+0x110/0x1f8 [<0000000167a7bd04>] kasan_report+0xfc/0x128 [<000000016938d79a>] qeth_l2_br2dev_worker+0x5ba/0x6b0 [<00000001673edd1e>] process_one_work+0x76e/0x1128 [<00000001673ee85c>] worker_thread+0x184/0x1098 [<000000016740718a>] kthread+0x26a/0x310 [<00000001672c606a>] __ret_from_fork+0x8a/0xe8 [<00000001694711da>] ret_from_fork+0xa/0x40 Allocated by task 108338: kasan_save_stack+0x40/0x68 kasan_set_track+0x36/0x48 __kasan_kmalloc+0xa0/0xc0 qeth_l2_switchdev_event+0x25a/0x738 atomic_notifier_call_chain+0x9c/0xf8 br_switchdev_fdb_notify+0xf4/0x110 fdb_notify+0x122/0x180 fdb_add_entry.constprop.0.isra.0+0x312/0x558 br_fdb_add+0x59e/0x858 rtnl_fdb_add+0x58a/0x928 rtnetlink_rcv_msg+0x5f8/0x8d8 netlink_rcv_skb+0x1f2/0x408 netlink_unicast+0x570/0x790 netlink_sendmsg+0x752/0xbe0 sock_sendmsg+0xca/0x110 ____sys_sendmsg+0x510/0x6a8 ___sys_sendmsg+0x12a/0x180 __sys_sendmsg+0xe6/0x168 __do_sys_socketcall+0x3c8/0x468 do_syscall+0x22c/0x328 __do_syscall+0x94/0xf0 system_call+0x82/0xb0 Freed by task 540: kasan_save_stack+0x40/0x68 kasan_set_track+0x36/0x48 kasan_save_free_info+0x4c/0x68 ____kasan_slab_free+0x14e/0x1a8 __kasan_slab_free+0x24/0x30 __kmem_cache_free+0x168/0x338 qeth_l2_br2dev_worker+0x154/0x6b0 process_one_work+0x76e/0x1128 worker_thread+0x184/0x1098 kthread+0x26a/0x310 __ret_from_fork+0x8a/0xe8 ret_from_fork+0xa/0x40 Last potentially related work creation: kasan_save_stack+0x40/0x68 __kasan_record_aux_stack+0xbe/0xd0 insert_work+0x56/0x2e8 __queue_work+0x4ce/0xd10 queue_work_on+0xf4/0x100 qeth_l2_switchdev_event+0x520/0x738 atomic_notifier_call_chain+0x9c/0xf8 br_switchdev_fdb_notify+0xf4/0x110 fdb_notify+0x122/0x180 fdb_add_entry.constprop.0.isra.0+0x312/0x558 br_fdb_add+0x59e/0x858 rtnl_fdb_add+0x58a/0x928 rtnetlink_rcv_msg+0x5f8/0x8d8 netlink_rcv_skb+0x1f2/0x408 netlink_unicast+0x570/0x790 netlink_sendmsg+0x752/0xbe0 sock_sendmsg+0xca/0x110 ____sys_sendmsg+0x510/0x6a8 ___sys_sendmsg+0x12a/0x180 __sys_sendmsg+0xe6/0x168 __do_sys_socketcall+0x3c8/0x468 do_syscall+0x22c/0x328 __do_syscall+0x94/0xf0 system_call+0x82/0xb0 Second to last potentially related work creation: kasan_save_stack+0x40/0x68 __kasan_record_aux_stack+0xbe/0xd0 kvfree_call_rcu+0xb2/0x760 kernfs_unlink_open_file+0x348/0x430 kernfs_fop_release+0xc2/0x320 __fput+0x1ae/0x768 task_work_run+0x1bc/0x298 exit_to_user_mode_prepare+0x1a0/0x1a8 __do_syscall+0x94/0xf0 system_call+0x82/0xb0 The buggy address belongs to the object at 00000000fdcea400 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 64 bytes inside of 96-byte region [00000000fdcea400, 00000000fdcea460) The buggy address belongs to the physical page: page:000000005a9c26e8 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xfdcea flags: 0x3ffff00000000200(slab|node=0|zone=1|lastcpupid=0x1ffff) raw: 3ffff00000000200 0000000000000000 0000000100000122 000000008008cc00 raw: 0000000000000000 0020004100000000 ffffffff00000001 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: 00000000fdcea300: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc 00000000fdcea380: fb fb fb fb fb fb f ---truncated--- CVE-2022-48954 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: fix memory leak in tbnet_open() When tb_ring_alloc_rx() failed in tbnet_open(), ida that allocated in tb_xdomain_alloc_out_hopid() is not released. Add tb_xdomain_release_out_hopid() to the error path to release ida. CVE-2022-48955 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid use-after-free in ip6_fragment() Blamed commit claimed rcu_read_lock() was held by ip6_fragment() callers. It seems to not be always true, at least for UDP stack. syzbot reported: BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:245 [inline] BUG: KASAN: use-after-free in ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951 Read of size 8 at addr ffff88801d403e80 by task syz-executor.3/7618 CPU: 1 PID: 7618 Comm: syz-executor.3 Not tainted 6.1.0-rc6-syzkaller-00012-g4312098baf37 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x15e/0x45d mm/kasan/report.c:395 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495 ip6_dst_idev include/net/ip6_fib.h:245 [inline] ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951 __ip6_finish_output net/ipv6/ip6_output.c:193 [inline] ip6_finish_output+0x9a3/0x1170 net/ipv6/ip6_output.c:206 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227 dst_output include/net/dst.h:445 [inline] ip6_local_out+0xb3/0x1a0 net/ipv6/output_core.c:161 ip6_send_skb+0xbb/0x340 net/ipv6/ip6_output.c:1966 udp_v6_send_skb+0x82a/0x18a0 net/ipv6/udp.c:1286 udp_v6_push_pending_frames+0x140/0x200 net/ipv6/udp.c:1313 udpv6_sendmsg+0x18da/0x2c80 net/ipv6/udp.c:1606 inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xd3/0x120 net/socket.c:734 sock_write_iter+0x295/0x3d0 net/socket.c:1108 call_write_iter include/linux/fs.h:2191 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x9ed/0xdd0 fs/read_write.c:584 ksys_write+0x1ec/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fde3588c0d9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fde365b6168 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fde359ac050 RCX: 00007fde3588c0d9 RDX: 000000000000ffdc RSI: 00000000200000c0 RDI: 000000000000000a RBP: 00007fde358e7ae9 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fde35acfb1f R14: 00007fde365b6300 R15: 0000000000022000 </TASK> Allocated by task 7618: kasan_save_stack+0x22/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x82/0x90 mm/kasan/common.c:325 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slab.h:737 [inline] slab_alloc_node mm/slub.c:3398 [inline] slab_alloc mm/slub.c:3406 [inline] __kmem_cache_alloc_lru mm/slub.c:3413 [inline] kmem_cache_alloc+0x2b4/0x3d0 mm/slub.c:3422 dst_alloc+0x14a/0x1f0 net/core/dst.c:92 ip6_dst_alloc+0x32/0xa0 net/ipv6/route.c:344 ip6_rt_pcpu_alloc net/ipv6/route.c:1369 [inline] rt6_make_pcpu_route net/ipv6/route.c:1417 [inline] ip6_pol_route+0x901/0x1190 net/ipv6/route.c:2254 pol_lookup_func include/net/ip6_fib.h:582 [inline] fib6_rule_lookup+0x52e/0x6f0 net/ipv6/fib6_rules.c:121 ip6_route_output_flags_noref+0x2e6/0x380 net/ipv6/route.c:2625 ip6_route_output_flags+0x76/0x320 net/ipv6/route.c:2638 ip6_route_output include/net/ip6_route.h:98 [inline] ip6_dst_lookup_tail+0x5ab/0x1620 net/ipv6/ip6_output.c:1092 ip6_dst_lookup_flow+0x90/0x1d0 net/ipv6/ip6_output.c:1222 ip6_sk_dst_lookup_flow+0x553/0x980 net/ipv6/ip6_output.c:1260 udpv6_sendmsg+0x151d/0x2c80 net/ipv6/udp.c:1554 inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665 sock_sendmsg_nosec n ---truncated--- CVE-2022-48956 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: fix memory leak in sja1105_setup_devlink_regions() When dsa_devlink_region_create failed in sja1105_setup_devlink_regions(), priv->regions is not released. CVE-2022-48959 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: hisilicon: Fix potential use-after-free in hix5hd2_rx() The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free. CVE-2022-48960 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: net: mdio: fix unbalanced fwnode reference count in mdio_device_release() There is warning report about of_node refcount leak while probing mdio device: OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /spi/soc@0/mdio@710700c0/ethernet@4 In of_mdiobus_register_device(), we increase fwnode refcount by fwnode_handle_get() before associating the of_node with mdio device, but it has never been decreased in normal path. Since that, in mdio_device_release(), it needs to call fwnode_handle_put() in addition instead of calling kfree() directly. After above, just calling mdio_device_free() in the error handle path of of_mdiobus_register_device() is enough to keep the refcount balanced. CVE-2022-48961 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: hisilicon: Fix potential use-after-free in hisi_femac_rx() The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free. CVE-2022-48962 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: NFC: nci: Bounds check struct nfc_target arrays While running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported: memcpy: detected field-spanning write (size 129) of single field "target->sensf_res" at net/nfc/nci/ntf.c:260 (size 18) This appears to be a legitimate lack of bounds checking in nci_add_new_protocol(). Add the missing checks. CVE-2022-48967 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix potential memory leak in otx2_init_tc() In otx2_init_tc(), if rhashtable_init() failed, it does not free tc->tc_entries_bitmap which is allocated in otx2_tc_alloc_ent_bitmap(). CVE-2022-48968 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: xen-netfront: Fix NULL sring after live migration A NAPI is setup for each network sring to poll data to kernel The sring with source host is destroyed before live migration and new sring with target host is setup after live migration. The NAPI for the old sring is not deleted until setup new sring with target host after migration. With busy_poll/busy_read enabled, the NAPI can be polled before got deleted when resume VM. BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: xennet_poll+0xae/0xd20 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI Call Trace: finish_task_switch+0x71/0x230 timerqueue_del+0x1d/0x40 hrtimer_try_to_cancel+0xb5/0x110 xennet_alloc_rx_buffers+0x2a0/0x2a0 napi_busy_loop+0xdb/0x270 sock_poll+0x87/0x90 do_sys_poll+0x26f/0x580 tracing_map_insert+0x1d4/0x2f0 event_hist_trigger+0x14a/0x260 finish_task_switch+0x71/0x230 __schedule+0x256/0x890 recalc_sigpending+0x1b/0x50 xen_sched_clock+0x15/0x20 __rb_reserve_next+0x12d/0x140 ring_buffer_lock_reserve+0x123/0x3d0 event_triggers_call+0x87/0xb0 trace_event_buffer_commit+0x1c4/0x210 xen_clocksource_get_cycles+0x15/0x20 ktime_get_ts64+0x51/0xf0 SyS_ppoll+0x160/0x1a0 SyS_ppoll+0x160/0x1a0 do_syscall_64+0x73/0x130 entry_SYSCALL_64_after_hwframe+0x41/0xa6 ... RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900 CR2: 0000000000000008 ---[ end trace f8601785b354351c ]--- xen frontend should remove the NAPIs for the old srings before live migration as the bond srings are destroyed There is a tiny window between the srings are set to NULL and the NAPIs are disabled, It is safe as the NAPI threads are still frozen at that time CVE-2022-48969 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix not cleanup led when bt_init fails bt_init() calls bt_leds_init() to register led, but if it fails later, bt_leds_cleanup() is not called to unregister it. This can cause panic if the argument "bluetooth-power" in text is freed and then another led_trigger_register() tries to access it: BUG: unable to handle page fault for address: ffffffffc06d3bc0 RIP: 0010:strcmp+0xc/0x30 Call Trace: <TASK> led_trigger_register+0x10d/0x4f0 led_trigger_register_simple+0x7d/0x100 bt_init+0x39/0xf7 [bluetooth] do_one_initcall+0xd0/0x4e0 CVE-2022-48971 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: mac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add() Kernel fault injection test reports null-ptr-deref as follows: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:cfg802154_netdev_notifier_call+0x120/0x310 include/linux/list.h:114 Call Trace: <TASK> raw_notifier_call_chain+0x6d/0xa0 kernel/notifier.c:87 call_netdevice_notifiers_info+0x6e/0xc0 net/core/dev.c:1944 unregister_netdevice_many_notify+0x60d/0xcb0 net/core/dev.c:1982 unregister_netdevice_queue+0x154/0x1a0 net/core/dev.c:10879 register_netdevice+0x9a8/0xb90 net/core/dev.c:10083 ieee802154_if_add+0x6ed/0x7e0 net/mac802154/iface.c:659 ieee802154_register_hw+0x29c/0x330 net/mac802154/main.c:229 mcr20a_probe+0xaaa/0xcb1 drivers/net/ieee802154/mcr20a.c:1316 ieee802154_if_add() allocates wpan_dev as netdev's private data, but not init the list in struct wpan_dev. cfg802154_netdev_notifier_call() manage the list when device register/unregister, and may lead to null-ptr-deref. Use INIT_LIST_HEAD() on it to initialize it correctly. CVE-2022-48972 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: gpio: amd8111: Fix PCI device reference count leak for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() after the 'out' label. Since pci_dev_put() can handle NULL input parameter, there is no problem for the 'Device not found' branch. For the normal path, add pci_dev_put() in amd_gpio_exit(). CVE-2022-48973 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: gpiolib: fix memory leak in gpiochip_setup_dev() Here is a backtrace report about memory leak detected in gpiochip_setup_dev(): unreferenced object 0xffff88810b406400 (size 512): comm "python3", pid 1682, jiffies 4295346908 (age 24.090s) backtrace: kmalloc_trace device_add device_private_init at drivers/base/core.c:3361 (inlined by) device_add at drivers/base/core.c:3411 cdev_device_add gpiolib_cdev_register gpiochip_setup_dev gpiochip_add_data_with_key gcdev_register() & gcdev_unregister() would call device_add() & device_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to register/unregister device. However, if device_add() succeeds, some resource (like struct device_private allocated by device_private_init()) is not released by device_del(). Therefore, after device_add() succeeds by gcdev_register(), it needs to call put_device() to release resource in the error handle path. Here we move forward the register of release function, and let it release every piece of resource by put_device() instead of kfree(). While at it, fix another subtle issue, i.e. when gc->ngpio is equal to 0, we still call kcalloc() and, in case of further error, kfree() on the ZERO_PTR pointer, which is not NULL. It's not a bug per se, but rather waste of the resources and potentially wrong expectation about contents of the gdev->descs variable. CVE-2022-48975 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: HID: core: fix shift-out-of-bounds in hid_report_raw_event Syzbot reported shift-out-of-bounds in hid_report_raw_event. microsoft 0003:045E:07DA.0001: hid_field_extract() called with n (128) > 32! (swapper/0) ====================================================================== UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20 shift exponent 127 is too large for 32-bit type 'int' CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:151 [inline] __ubsan_handle_shift_out_of_bounds+0x3a6/0x420 lib/ubsan.c:322 snto32 drivers/hid/hid-core.c:1323 [inline] hid_input_fetch_field drivers/hid/hid-core.c:1572 [inline] hid_process_report drivers/hid/hid-core.c:1665 [inline] hid_report_raw_event+0xd56/0x18b0 drivers/hid/hid-core.c:1998 hid_input_report+0x408/0x4f0 drivers/hid/hid-core.c:2066 hid_irq_in+0x459/0x690 drivers/hid/usbhid/hid-core.c:284 __usb_hcd_giveback_urb+0x369/0x530 drivers/usb/core/hcd.c:1671 dummy_timer+0x86b/0x3110 drivers/usb/gadget/udc/dummy_hcd.c:1988 call_timer_fn+0xf5/0x210 kernel/time/timer.c:1474 expire_timers kernel/time/timer.c:1519 [inline] __run_timers+0x76a/0x980 kernel/time/timer.c:1790 run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1803 __do_softirq+0x277/0x75b kernel/softirq.c:571 __irq_exit_rcu+0xec/0x170 kernel/softirq.c:650 irq_exit_rcu+0x5/0x20 kernel/softirq.c:662 sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107 ====================================================================== If the size of the integer (unsigned n) is bigger than 32 in snto32(), shift exponent will be too large for 32-bit type 'int', resulting in a shift-out-of-bounds bug. Fix this by adding a check on the size of the integer (unsigned n) in snto32(). To add support for n greater than 32 bits, set n to 32, if n is greater than 32. CVE-2022-48978 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/shmem-helper: Remove errant put in error path drm_gem_shmem_mmap() doesn't own this reference, resulting in the GEM object getting prematurely freed leading to a later use-after-free. CVE-2022-48981 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: mana: Fix race on per-CQ variable napi work_done After calling napi_complete_done(), the NAPIF_STATE_SCHED bit may be cleared, and another CPU can start napi thread and access per-CQ variable, cq->work_done. If the other thread (for example, from busy_poll) sets it to a value >= budget, this thread will continue to run when it should stop, and cause memory corruption and panic. To fix this issue, save the per-CQ work_done variable in a local variable before napi_complete_done(), so it won't be corrupted by a possible concurrent thread after napi_complete_done(). Also, add a flag bit to advertise to the NIC firmware: the NAPI work_done variable race is fixed, so the driver is able to reliably support features like busy_poll. CVE-2022-48985 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: v4l2-dv-timings.c: fix too strict blanking sanity checks Sanity checks were added to verify the v4l2_bt_timings blanking fields in order to avoid integer overflows when userspace passes weird values. But that assumed that userspace would correctly fill in the front porch, backporch and sync values, but sometimes all you know is the total blanking, which is then assigned to just one of these fields. And that can fail with these checks. So instead set a maximum for the total horizontal and vertical blanking and check that each field remains below that. That is still sufficient to avoid integer overflows, but it also allows for more flexibility in how userspace fills in these fields. CVE-2022-48987 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 low In the Linux kernel, the following vulnerability has been resolved: memcg: fix possible use-after-free in memcg_write_event_control() memcg_write_event_control() accesses the dentry->d_name of the specified control fd to route the write call. As a cgroup interface file can't be renamed, it's safe to access d_name as long as the specified file is a regular cgroup file. Also, as these cgroup interface files can't be removed before the directory, it's safe to access the parent too. Prior to 347c4a874710 ("memcg: remove cgroup_event->cft"), there was a call to __file_cft() which verified that the specified file is a regular cgroupfs file before further accesses. The cftype pointer returned from __file_cft() was no longer necessary and the commit inadvertently dropped the file type check with it allowing any file to slip through. With the invarients broken, the d_name and parent accesses can now race against renames and removals of arbitrary files and cause use-after-free's. Fix the bug by resurrecting the file type check in __file_cft(). Now that cgroupfs is implemented through kernfs, checking the file operations needs to go through a layer of indirection. Instead, let's check the superblock and dentry type. CVE-2022-48988 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths Any codepath that zaps page table entries must invoke MMU notifiers to ensure that secondary MMUs (like KVM) don't keep accessing pages which aren't mapped anymore. Secondary MMUs don't hold their own references to pages that are mirrored over, so failing to notify them can lead to page use-after-free. I'm marking this as addressing an issue introduced in commit f3f0e1d2150b ("khugepaged: add support of collapse for tmpfs/shmem pages"), but most of the security impact of this only came in commit 27e1f8273113 ("khugepaged: enable collapse pmd for pte-mapped THP"), which actually omitted flushes for the removal of present PTEs, not just for the removal of empty page tables. CVE-2022-48991 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: ASoC: soc-pcm: Add NULL check in BE reparenting Add NULL check in dpcm_be_reparent API, to handle kernel NULL pointer dereference error. The issue occurred in fuzzing test. CVE-2022-48992 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Fix function prototype mismatch in snd_seq_expand_var_event With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. seq_copy_in_user() and seq_copy_in_kernel() did not have prototypes matching snd_seq_dump_func_t. Adjust this and remove the casts. There are not resulting binary output differences. This was found as a result of Clang's new -Wcast-function-type-strict flag, which is more sensitive than the simpler -Wcast-function-type, which only checks for type width mismatches. CVE-2022-48994 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: Input: raydium_ts_i2c - fix memory leak in raydium_i2c_send() There is a kmemleak when test the raydium_i2c_ts with bpf mock device: unreferenced object 0xffff88812d3675a0 (size 8): comm "python3", pid 349, jiffies 4294741067 (age 95.695s) hex dump (first 8 bytes): 11 0e 10 c0 01 00 04 00 ........ backtrace: [<0000000068427125>] __kmalloc+0x46/0x1b0 [<0000000090180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts] [<000000006e631aee>] raydium_i2c_initialize.cold+0xbc/0x3e4 [raydium_i2c_ts] [<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts] [<00000000a310de16>] i2c_device_probe+0x651/0x680 [<00000000f5a96bf3>] really_probe+0x17c/0x3f0 [<00000000096ba499>] __driver_probe_device+0xe3/0x170 [<00000000c5acb4d9>] driver_probe_device+0x49/0x120 [<00000000264fe082>] __device_attach_driver+0xf7/0x150 [<00000000f919423c>] bus_for_each_drv+0x114/0x180 [<00000000e067feca>] __device_attach+0x1e5/0x2d0 [<0000000054301fc2>] bus_probe_device+0x126/0x140 [<00000000aad93b22>] device_add+0x810/0x1130 [<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0 [<000000003c2c248c>] of_i2c_register_device+0xf1/0x110 [<00000000ffec4177>] of_i2c_notify+0x100/0x160 unreferenced object 0xffff88812d3675c8 (size 8): comm "python3", pid 349, jiffies 4294741070 (age 95.692s) hex dump (first 8 bytes): 22 00 36 2d 81 88 ff ff ".6-.... backtrace: [<0000000068427125>] __kmalloc+0x46/0x1b0 [<0000000090180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts] [<000000001d5c9620>] raydium_i2c_initialize.cold+0x223/0x3e4 [raydium_i2c_ts] [<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts] [<00000000a310de16>] i2c_device_probe+0x651/0x680 [<00000000f5a96bf3>] really_probe+0x17c/0x3f0 [<00000000096ba499>] __driver_probe_device+0xe3/0x170 [<00000000c5acb4d9>] driver_probe_device+0x49/0x120 [<00000000264fe082>] __device_attach_driver+0xf7/0x150 [<00000000f919423c>] bus_for_each_drv+0x114/0x180 [<00000000e067feca>] __device_attach+0x1e5/0x2d0 [<0000000054301fc2>] bus_probe_device+0x126/0x140 [<00000000aad93b22>] device_add+0x810/0x1130 [<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0 [<000000003c2c248c>] of_i2c_register_device+0xf1/0x110 [<00000000ffec4177>] of_i2c_notify+0x100/0x160 After BANK_SWITCH command from i2c BUS, no matter success or error happened, the tx_buf should be freed. CVE-2022-48995 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: char: tpm: Protect tpm_pm_suspend with locks Currently tpm transactions are executed unconditionally in tpm_pm_suspend() function, which may lead to races with other tpm accessors in the system. Specifically, the hw_random tpm driver makes use of tpm_get_random(), and this function is called in a loop from a kthread, which means it's not frozen alongside userspace, and so can race with the work done during system suspend: tpm tpm0: tpm_transmit: tpm_recv: error -52 tpm tpm0: invalid TPM_STS.x 0xff, dumping stack for forensics CPU: 0 PID: 1 Comm: init Not tainted 6.1.0-rc5+ #135 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014 Call Trace: tpm_tis_status.cold+0x19/0x20 tpm_transmit+0x13b/0x390 tpm_transmit_cmd+0x20/0x80 tpm1_pm_suspend+0xa6/0x110 tpm_pm_suspend+0x53/0x80 __pnp_bus_suspend+0x35/0xe0 __device_suspend+0x10f/0x350 Fix this by calling tpm_try_get_ops(), which itself is a wrapper around tpm_chip_start(), but takes the appropriate mutex. [Jason: reworked commit message, added metadata] CVE-2022-48997 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 low In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix PCI device refcount leak in has_external_pci() for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() before 'return true' to avoid reference count leak. CVE-2022-49000 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init() for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() for the error path to avoid reference count leak. CVE-2022-49002 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 low In the Linux kernel, the following vulnerability has been resolved: nvme: fix SRCU protection of nvme_ns_head list Walking the nvme_ns_head siblings list is protected by the head's srcu in nvme_ns_head_submit_bio() but not nvme_mpath_revalidate_paths(). Removing namespaces from the list also fails to synchronize the srcu. Concurrent scan work can therefore cause use-after-frees. Hold the head's srcu lock in nvme_mpath_revalidate_paths() and synchronize with the srcu, not the global RCU, in nvme_ns_remove(). Observed the following panic when making NVMe/RDMA connections with native multipath on the Rocky Linux 8.6 kernel (it seems the upstream kernel has the same race condition). Disassembly shows the faulting instruction is cmp 0x50(%rdx),%rcx; computing capacity != get_capacity(ns->disk). Address 0x50 is dereferenced because ns->disk is NULL. The NULL disk appears to be the result of concurrent scan work freeing the namespace (note the log line in the middle of the panic). [37314.206036] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 [37314.206036] nvme0n3: detected capacity change from 0 to 11811160064 [37314.299753] PGD 0 P4D 0 [37314.299756] Oops: 0000 [#1] SMP PTI [37314.299759] CPU: 29 PID: 322046 Comm: kworker/u98:3 Kdump: loaded Tainted: G W X --------- - - 4.18.0-372.32.1.el8test86.x86_64 #1 [37314.299762] Hardware name: Dell Inc. PowerEdge R720/0JP31P, BIOS 2.7.0 05/23/2018 [37314.299763] Workqueue: nvme-wq nvme_scan_work [nvme_core] [37314.299783] RIP: 0010:nvme_mpath_revalidate_paths+0x26/0xb0 [nvme_core] [37314.299790] Code: 1f 44 00 00 66 66 66 66 90 55 53 48 8b 5f 50 48 8b 83 c8 c9 00 00 48 8b 13 48 8b 48 50 48 39 d3 74 20 48 8d 42 d0 48 8b 50 20 <48> 3b 4a 50 74 05 f0 80 60 70 ef 48 8b 50 30 48 8d 42 d0 48 39 d3 [37315.058803] RSP: 0018:ffffabe28f913d10 EFLAGS: 00010202 [37315.121316] RAX: ffff927a077da800 RBX: ffff92991dd70000 RCX: 0000000001600000 [37315.206704] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff92991b719800 [37315.292106] RBP: ffff929a6b70c000 R08: 000000010234cd4a R09: c0000000ffff7fff [37315.377501] R10: 0000000000000001 R11: ffffabe28f913a30 R12: 0000000000000000 [37315.462889] R13: ffff92992716600c R14: ffff929964e6e030 R15: ffff92991dd70000 [37315.548286] FS: 0000000000000000(0000) GS:ffff92b87fb80000(0000) knlGS:0000000000000000 [37315.645111] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [37315.713871] CR2: 0000000000000050 CR3: 0000002208810006 CR4: 00000000000606e0 [37315.799267] Call Trace: [37315.828515] nvme_update_ns_info+0x1ac/0x250 [nvme_core] [37315.892075] nvme_validate_or_alloc_ns+0x2ff/0xa00 [nvme_core] [37315.961871] ? __blk_mq_free_request+0x6b/0x90 [37316.015021] nvme_scan_work+0x151/0x240 [nvme_core] [37316.073371] process_one_work+0x1a7/0x360 [37316.121318] ? create_worker+0x1a0/0x1a0 [37316.168227] worker_thread+0x30/0x390 [37316.212024] ? create_worker+0x1a0/0x1a0 [37316.258939] kthread+0x10a/0x120 [37316.297557] ? set_kthread_struct+0x50/0x50 [37316.347590] ret_from_fork+0x35/0x40 [37316.390360] Modules linked in: nvme_rdma nvme_tcp(X) nvme_fabrics nvme_core netconsole iscsi_tcp libiscsi_tcp dm_queue_length dm_service_time nf_conntrack_netlink br_netfilter bridge stp llc overlay nft_chain_nat ipt_MASQUERADE nf_nat xt_addrtype xt_CT nft_counter xt_state xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment xt_multiport nft_compat nf_tables libcrc32c nfnetlink dm_multipath tg3 rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm intel_rapl_msr iTCO_wdt iTCO_vendor_support dcdbas intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ipmi_ssif kvm irqbypass crct10dif_pclmul crc32_pclmul mlx5_ib ghash_clmulni_intel ib_uverbs rapl intel_cstate intel_uncore ib_core ipmi_si joydev mei_me pcspkr ipmi_devintf mei lpc_ich wmi ipmi_msghandler acpi_power_meter ex ---truncated--- CVE-2022-49003 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: ASoC: ops: Fix bounds check for _sx controls For _sx controls the semantics of the max field is not the usual one, max is the number of steps rather than the maximum value. This means that our check in snd_soc_put_volsw_sx() needs to just check against the maximum value. CVE-2022-49005 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: tracing: Free buffers when a used dynamic event is removed After 65536 dynamic events have been added and removed, the "type" field of the event then uses the first type number that is available (not currently used by other events). A type number is the identifier of the binary blobs in the tracing ring buffer (known as events) to map them to logic that can parse the binary blob. The issue is that if a dynamic event (like a kprobe event) is traced and is in the ring buffer, and then that event is removed (because it is dynamic, which means it can be created and destroyed), if another dynamic event is created that has the same number that new event's logic on parsing the binary blob will be used. To show how this can be an issue, the following can crash the kernel: # cd /sys/kernel/tracing # for i in `seq 65536`; do echo 'p:kprobes/foo do_sys_openat2 $arg1:u32' > kprobe_events # done For every iteration of the above, the writing to the kprobe_events will remove the old event and create a new one (with the same format) and increase the type number to the next available on until the type number reaches over 65535 which is the max number for the 16 bit type. After it reaches that number, the logic to allocate a new number simply looks for the next available number. When an dynamic event is removed, that number is then available to be reused by the next dynamic event created. That is, once the above reaches the max number, the number assigned to the event in that loop will remain the same. Now that means deleting one dynamic event and created another will reuse the previous events type number. This is where bad things can happen. After the above loop finishes, the kprobes/foo event which reads the do_sys_openat2 function call's first parameter as an integer. # echo 1 > kprobes/foo/enable # cat /etc/passwd > /dev/null # cat trace cat-2211 [005] .... 2007.849603: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849620: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849838: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849880: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 # echo 0 > kprobes/foo/enable Now if we delete the kprobe and create a new one that reads a string: # echo 'p:kprobes/foo do_sys_openat2 +0($arg2):string' > kprobe_events And now we can the trace: # cat trace sendmail-1942 [002] ..... 530.136320: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930817: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������" cat-2046 [004] ..... 530.930961: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������" cat-2046 [004] ..... 530.934278: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������" cat-2046 [004] ..... 530.934563: foo: (do_sys_openat2+0x0/0x240) arg1="��������������������������������������� ---truncated--- CVE-2022-49006 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry() Syzbot reported a null-ptr-deref bug: NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 PID: 3603 Comm: segctord Not tainted 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 RIP: 0010:nilfs_palloc_commit_free_entry+0xe5/0x6b0 fs/nilfs2/alloc.c:608 Code: 00 00 00 00 fc ff df 80 3c 02 00 0f 85 cd 05 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 73 08 49 8d 7e 10 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 26 05 00 00 49 8b 46 10 be a6 00 00 00 48 c7 c7 RSP: 0018:ffffc90003dff830 EFLAGS: 00010212 RAX: dffffc0000000000 RBX: ffff88802594e218 RCX: 000000000000000d RDX: 0000000000000002 RSI: 0000000000002000 RDI: 0000000000000010 RBP: ffff888071880222 R08: 0000000000000005 R09: 000000000000003f R10: 000000000000000d R11: 0000000000000000 R12: ffff888071880158 R13: ffff88802594e220 R14: 0000000000000000 R15: 0000000000000004 FS: 0000000000000000(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb1c08316a8 CR3: 0000000018560000 CR4: 0000000000350ee0 Call Trace: <TASK> nilfs_dat_commit_free fs/nilfs2/dat.c:114 [inline] nilfs_dat_commit_end+0x464/0x5f0 fs/nilfs2/dat.c:193 nilfs_dat_commit_update+0x26/0x40 fs/nilfs2/dat.c:236 nilfs_btree_commit_update_v+0x87/0x4a0 fs/nilfs2/btree.c:1940 nilfs_btree_commit_propagate_v fs/nilfs2/btree.c:2016 [inline] nilfs_btree_propagate_v fs/nilfs2/btree.c:2046 [inline] nilfs_btree_propagate+0xa00/0xd60 fs/nilfs2/btree.c:2088 nilfs_bmap_propagate+0x73/0x170 fs/nilfs2/bmap.c:337 nilfs_collect_file_data+0x45/0xd0 fs/nilfs2/segment.c:568 nilfs_segctor_apply_buffers+0x14a/0x470 fs/nilfs2/segment.c:1018 nilfs_segctor_scan_file+0x3f4/0x6f0 fs/nilfs2/segment.c:1067 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1197 [inline] nilfs_segctor_collect fs/nilfs2/segment.c:1503 [inline] nilfs_segctor_do_construct+0x12fc/0x6af0 fs/nilfs2/segment.c:2045 nilfs_segctor_construct+0x8e3/0xb30 fs/nilfs2/segment.c:2379 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2487 [inline] nilfs_segctor_thread+0x3c3/0xf30 fs/nilfs2/segment.c:2570 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> ... If DAT metadata file is corrupted on disk, there is a case where req->pr_desc_bh is NULL and blocknr is 0 at nilfs_dat_commit_end() during a b-tree operation that cascadingly updates ancestor nodes of the b-tree, because nilfs_dat_commit_alloc() for a lower level block can initialize the blocknr on the same DAT entry between nilfs_dat_prepare_end() and nilfs_dat_commit_end(). If this happens, nilfs_dat_commit_end() calls nilfs_dat_commit_free() without valid buffer heads in req->pr_desc_bh and req->pr_bitmap_bh, and causes the NULL pointer dereference above in nilfs_palloc_commit_free_entry() function, which leads to a crash. Fix this by adding a NULL check on req->pr_desc_bh and req->pr_bitmap_bh before nilfs_palloc_commit_free_entry() in nilfs_dat_commit_free(). This also calls nilfs_error() in that case to notify that there is a fatal flaw in the filesystem metadata and prevent further operations. CVE-2022-49007 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) Check for null before removing sysfs attrs If coretemp_add_core() gets an error then pdata->core_data[indx] is already NULL and has been kfreed. Don't pass that to sysfs_remove_group() as that will crash in sysfs_remove_group(). [Shortened for readability] [91854.020159] sysfs: cannot create duplicate filename '/devices/platform/coretemp.0/hwmon/hwmon2/temp20_label' <cpu offline> [91855.126115] BUG: kernel NULL pointer dereference, address: 0000000000000188 [91855.165103] #PF: supervisor read access in kernel mode [91855.194506] #PF: error_code(0x0000) - not-present page [91855.224445] PGD 0 P4D 0 [91855.238508] Oops: 0000 [#1] PREEMPT SMP PTI ... [91855.342716] RIP: 0010:sysfs_remove_group+0xc/0x80 ... [91855.796571] Call Trace: [91855.810524] coretemp_cpu_offline+0x12b/0x1dd [coretemp] [91855.841738] ? coretemp_cpu_online+0x180/0x180 [coretemp] [91855.871107] cpuhp_invoke_callback+0x105/0x4b0 [91855.893432] cpuhp_thread_fun+0x8e/0x150 ... Fix this by checking for NULL first. CVE-2022-49010 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new() As comment of pci_get_domain_bus_and_slot() says, it returns a pci device with refcount increment, when finish using it, the caller must decrement the reference count by calling pci_dev_put(). So call it after using to avoid refcount leak. CVE-2022-49011 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: afs: Fix server->active leak in afs_put_server The atomic_read was accidentally replaced with atomic_inc_return, which prevents the server from getting cleaned up and causes rmmod to hang with a warning: Can't purge s=00000001 CVE-2022-49012 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: tun: Fix use-after-free in tun_detach() syzbot reported use-after-free in tun_detach() [1]. This causes call trace like below: ================================================================== BUG: KASAN: use-after-free in notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75 Read of size 8 at addr ffff88807324e2a8 by task syz-executor.0/3673 CPU: 0 PID: 3673 Comm: syz-executor.0 Not tainted 6.1.0-rc5-syzkaller-00044-gcc675d22e422 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x15e/0x461 mm/kasan/report.c:395 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495 notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75 call_netdevice_notifiers_info+0x86/0x130 net/core/dev.c:1942 call_netdevice_notifiers_extack net/core/dev.c:1983 [inline] call_netdevice_notifiers net/core/dev.c:1997 [inline] netdev_wait_allrefs_any net/core/dev.c:10237 [inline] netdev_run_todo+0xbc6/0x1100 net/core/dev.c:10351 tun_detach drivers/net/tun.c:704 [inline] tun_chr_close+0xe4/0x190 drivers/net/tun.c:3467 __fput+0x27c/0xa90 fs/file_table.c:320 task_work_run+0x16f/0x270 kernel/task_work.c:179 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0xb3d/0x2a30 kernel/exit.c:820 do_group_exit+0xd4/0x2a0 kernel/exit.c:950 get_signal+0x21b1/0x2440 kernel/signal.c:2858 arch_do_signal_or_restart+0x86/0x2300 arch/x86/kernel/signal.c:869 exit_to_user_mode_loop kernel/entry/common.c:168 [inline] exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296 do_syscall_64+0x46/0xb0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x63/0xcd The cause of the issue is that sock_put() from __tun_detach() drops last reference count for struct net, and then notifier_call_chain() from netdev_state_change() accesses that struct net. This patch fixes the issue by calling sock_put() from tun_detach() after all necessary accesses for the struct net has done. CVE-2022-49014 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: net: hsr: Fix potential use-after-free The skb is delivered to netif_rx() which may free it, after calling this, dereferencing skb may trigger use-after-free. CVE-2022-49015 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: net: mdiobus: fix unbalanced node reference count I got the following report while doing device(mscc-miim) load test with CONFIG_OF_UNITTEST and CONFIG_OF_DYNAMIC enabled: OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /spi/soc@0/mdio@7107009c/ethernet-phy@0 If the 'fwnode' is not an acpi node, the refcount is get in fwnode_mdiobus_phy_device_register(), but it has never been put when the device is freed in the normal path. So call fwnode_handle_put() in phy_device_release() to avoid leak. If it's an acpi node, it has never been get, but it's put in the error path, so call fwnode_handle_get() before phy_device_register() to keep get/put operation balanced. CVE-2022-49016 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: ethernet: nixge: fix NULL dereference In function nixge_hw_dma_bd_release() dereference of NULL pointer priv->rx_bd_v is possible for the case of its allocation failure in nixge_hw_dma_bd_init(). Move for() loop with priv->rx_bd_v dereference under the check for its validity. Found by Linux Verification Center (linuxtesting.org) with SVACE. CVE-2022-49019 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: phy: fix null-ptr-deref while probe() failed I got a null-ptr-deref report as following when doing fault injection test: BUG: kernel NULL pointer dereference, address: 0000000000000058 Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 PID: 253 Comm: 507-spi-dm9051 Tainted: G B N 6.1.0-rc3+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:klist_put+0x2d/0xd0 Call Trace: <TASK> klist_remove+0xf1/0x1c0 device_release_driver_internal+0x23e/0x2d0 bus_remove_device+0x1bd/0x240 device_del+0x357/0x770 phy_device_remove+0x11/0x30 mdiobus_unregister+0xa5/0x140 release_nodes+0x6a/0xa0 devres_release_all+0xf8/0x150 device_unbind_cleanup+0x19/0xd0 //probe path: phy_device_register() device_add() phy_connect phy_attach_direct() //set device driver probe() //it's failed, driver is not bound device_bind_driver() // probe failed, it's not called //remove path: phy_device_remove() device_del() device_release_driver_internal() __device_release_driver() //dev->drv is not NULL klist_remove() <- knode_driver is not added yet, cause null-ptr-deref In phy_attach_direct(), after setting the 'dev->driver', probe() fails, device_bind_driver() is not called, so the knode_driver->n_klist is not set, then it causes null-ptr-deref in __device_release_driver() while deleting device. Fix this by setting dev->driver to NULL in the error path in phy_attach_direct(). CVE-2022-49021 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: mac8021: fix possible oob access in ieee80211_get_rate_duration Fix possible out-of-bound access in ieee80211_get_rate_duration routine as reported by the following UBSAN report: UBSAN: array-index-out-of-bounds in net/mac80211/airtime.c:455:47 index 15 is out of range for type 'u16 [12]' CPU: 2 PID: 217 Comm: kworker/u32:10 Not tainted 6.1.0-060100rc3-generic Hardware name: Acer Aspire TC-281/Aspire TC-281, BIOS R01-A2 07/18/2017 Workqueue: mt76 mt76u_tx_status_data [mt76_usb] Call Trace: <TASK> show_stack+0x4e/0x61 dump_stack_lvl+0x4a/0x6f dump_stack+0x10/0x18 ubsan_epilogue+0x9/0x43 __ubsan_handle_out_of_bounds.cold+0x42/0x47 ieee80211_get_rate_duration.constprop.0+0x22f/0x2a0 [mac80211] ? ieee80211_tx_status_ext+0x32e/0x640 [mac80211] ieee80211_calc_rx_airtime+0xda/0x120 [mac80211] ieee80211_calc_tx_airtime+0xb4/0x100 [mac80211] mt76x02_send_tx_status+0x266/0x480 [mt76x02_lib] mt76x02_tx_status_data+0x52/0x80 [mt76x02_lib] mt76u_tx_status_data+0x67/0xd0 [mt76_usb] process_one_work+0x225/0x400 worker_thread+0x50/0x3e0 ? process_one_work+0x400/0x400 kthread+0xe9/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 CVE-2022-49022 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: fix buffer overflow in elem comparison For vendor elements, the code here assumes that 5 octets are present without checking. Since the element itself is already checked to fit, we only need to check the length. CVE-2022-49023 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: can: m_can: pci: add missing m_can_class_free_dev() in probe/remove methods In m_can_pci_remove() and error handling path of m_can_pci_probe(), m_can_class_free_dev() should be called to free resource allocated by m_can_class_allocate_dev(), otherwise there will be memleak. CVE-2022-49024 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix use-after-free when reverting termination table When having multiple dests with termination tables and second one or afterwards fails the driver reverts usage of term tables but doesn't reset the assignment in attr->dests[num_vport_dests].termtbl which case a use-after-free when releasing the rule. Fix by resetting the assignment of termtbl to null. CVE-2022-49025 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: e100: Fix possible use after free in e100_xmit_prepare In e100_xmit_prepare(), if we can't map the skb, then return -ENOMEM, so e100_xmit_frame() will return NETDEV_TX_BUSY and the upper layer will resend the skb. But the skb is already freed, which will cause UAF bug when the upper layer resends the skb. Remove the harmful free. CVE-2022-49026 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: iavf: Fix error handling in iavf_init_module() The iavf_init_module() won't destroy workqueue when pci_register_driver() failed. Call destroy_workqueue() when pci_register_driver() failed to prevent the resource leak. Similar to the handling of u132_hcd_init in commit f276e002793c ("usb: u132-hcd: fix resource leak") CVE-2022-49027 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ixgbevf: Fix resource leak in ixgbevf_init_module() ixgbevf_init_module() won't destroy the workqueue created by create_singlethread_workqueue() when pci_register_driver() failed. Add destroy_workqueue() in fail path to prevent the resource leak. Similar to the handling of u132_hcd_init in commit f276e002793c ("usb: u132-hcd: fix resource leak") CVE-2022-49028 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails Smatch report warning as follows: drivers/hwmon/ibmpex.c:509 ibmpex_register_bmc() warn: '&data->list' not removed from list If ibmpex_find_sensors() fails in ibmpex_register_bmc(), data will be freed, but data->list will not be removed from driver_data.bmc_data, then list traversal may cause UAF. Fix by removeing it from driver_data.bmc_data before free(). CVE-2022-49029 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: iio: health: afe4403: Fix oob read in afe4403_read_raw KASAN report out-of-bounds read as follows: BUG: KASAN: global-out-of-bounds in afe4403_read_raw+0x42e/0x4c0 Read of size 4 at addr ffffffffc02ac638 by task cat/279 Call Trace: afe4403_read_raw iio_read_channel_info dev_attr_show The buggy address belongs to the variable: afe4403_channel_leds+0x18/0xffffffffffffe9e0 This issue can be reproduced by singe command: $ cat /sys/bus/spi/devices/spi0.0/iio\:device0/in_intensity6_raw The array size of afe4403_channel_leds is less than channels, so access with chan->address cause OOB read in afe4403_read_raw. Fix it by moving access before use it. CVE-2022-49031 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: iio: health: afe4404: Fix oob read in afe4404_[read|write]_raw KASAN report out-of-bounds read as follows: BUG: KASAN: global-out-of-bounds in afe4404_read_raw+0x2ce/0x380 Read of size 4 at addr ffffffffc00e4658 by task cat/278 Call Trace: afe4404_read_raw iio_read_channel_info dev_attr_show The buggy address belongs to the variable: afe4404_channel_leds+0x18/0xffffffffffffe9c0 This issue can be reproduce by singe command: $ cat /sys/bus/i2c/devices/0-0058/iio\:device0/in_intensity6_raw The array size of afe4404_channel_leds and afe4404_channel_offdacs are less than channels, so access with chan->address cause OOB read in afe4404_[read|write]_raw. Fix it by moving access before use them. CVE-2022-49032 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important xmlXIncludeAddNode in xinclude.c in libxml2 before 2.11.0 has a use-after-free. CVE-2022-49043 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libxml2-2-2.9.14-150400.5.44.1 important In the Linux kernel, the following vulnerability has been resolved: dm integrity: fix memory corruption when tag_size is less than digest size It is possible to set up dm-integrity in such a way that the "tag_size" parameter is less than the actual digest size. In this situation, a part of the digest beyond tag_size is ignored. In this case, dm-integrity would write beyond the end of the ic->recalc_tags array and corrupt memory. The corruption happened in integrity_recalc->integrity_sector_checksum->crypto_shash_final. Fix this corruption by increasing the tags array so that it has enough padding at the end to accomodate the loop in integrity_recalc() being able to write a full digest size for the last member of the tags array. CVE-2022-49044 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: memory: renesas-rpc-if: fix platform-device leak in error path Make sure to free the flash platform device in the event that registration fails during probe. CVE-2022-49050 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 low In the Linux kernel, the following vulnerability has been resolved: net: usb: aqc111: Fix out-of-bounds accesses in RX fixup aqc111_rx_fixup() contains several out-of-bounds accesses that can be triggered by a malicious (or defective) USB device, in particular: - The metadata array (desc_offset..desc_offset+2*pkt_count) can be out of bounds, causing OOB reads and (on big-endian systems) OOB endianness flips. - A packet can overlap the metadata array, causing a later OOB endianness flip to corrupt data used by a cloned SKB that has already been handed off into the network stack. - A packet SKB can be constructed whose tail is far beyond its end, causing out-of-bounds heap data to be considered part of the SKB's data. Found doing variant analysis. Tested it with another driver (ax88179_178a), since I don't have a aqc111 device to test it, but the code looks very similar. CVE-2022-49051 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcmu: Fix possible page UAF tcmu_try_get_data_page() looks up pages under cmdr_lock, but it does not take refcount properly and just returns page pointer. When tcmu_try_get_data_page() returns, the returned page may have been freed by tcmu_blocks_release(). We need to get_page() under cmdr_lock to avoid concurrent tcmu_blocks_release(). CVE-2022-49053 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Deactivate sysctl_record_panic_msg by default in isolated guests hv_panic_page might contain guest-sensitive information, do not dump it over to Hyper-V by default in isolated guests. While at it, update some comments in hyperv_{panic,die}_event(). CVE-2022-49054 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check for potential null return of kmalloc_array() As the kmalloc_array() may return null, the 'event_waiters[i].wait' would lead to null-pointer dereference. Therefore, it is better to check the return value of kmalloc_array() to avoid this confusion. CVE-2022-49055 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: cifs: potential buffer overflow in handling symlinks Smatch printed a warning: arch/x86/crypto/poly1305_glue.c:198 poly1305_update_arch() error: __memcpy() 'dctx->buf' too small (16 vs u32max) It's caused because Smatch marks 'link_len' as untrusted since it comes from sscanf(). Add a check to ensure that 'link_len' is not larger than the size of the 'link_str' buffer. CVE-2022-49058 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfc: nci: add flush_workqueue to prevent uaf Our detector found a concurrent use-after-free bug when detaching an NCI device. The main reason for this bug is the unexpected scheduling between the used delayed mechanism (timer and workqueue). The race can be demonstrated below: Thread-1 Thread-2 | nci_dev_up() | nci_open_device() | __nci_request(nci_reset_req) | nci_send_cmd | queue_work(cmd_work) nci_unregister_device() | nci_close_device() | ... del_timer_sync(cmd_timer)[1] | ... | Worker nci_free_device() | nci_cmd_work() kfree(ndev)[3] | mod_timer(cmd_timer)[2] In short, the cleanup routine thought that the cmd_timer has already been detached by [1] but the mod_timer can re-attach the timer [2], even it is already released [3], resulting in UAF. This UAF is easy to trigger, crash trace by POC is like below [ 66.703713] ================================================================== [ 66.703974] BUG: KASAN: use-after-free in enqueue_timer+0x448/0x490 [ 66.703974] Write of size 8 at addr ffff888009fb7058 by task kworker/u4:1/33 [ 66.703974] [ 66.703974] CPU: 1 PID: 33 Comm: kworker/u4:1 Not tainted 5.18.0-rc2 #5 [ 66.703974] Workqueue: nfc2_nci_cmd_wq nci_cmd_work [ 66.703974] Call Trace: [ 66.703974] <TASK> [ 66.703974] dump_stack_lvl+0x57/0x7d [ 66.703974] print_report.cold+0x5e/0x5db [ 66.703974] ? enqueue_timer+0x448/0x490 [ 66.703974] kasan_report+0xbe/0x1c0 [ 66.703974] ? enqueue_timer+0x448/0x490 [ 66.703974] enqueue_timer+0x448/0x490 [ 66.703974] __mod_timer+0x5e6/0xb80 [ 66.703974] ? mark_held_locks+0x9e/0xe0 [ 66.703974] ? try_to_del_timer_sync+0xf0/0xf0 [ 66.703974] ? lockdep_hardirqs_on_prepare+0x17b/0x410 [ 66.703974] ? queue_work_on+0x61/0x80 [ 66.703974] ? lockdep_hardirqs_on+0xbf/0x130 [ 66.703974] process_one_work+0x8bb/0x1510 [ 66.703974] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 66.703974] ? pwq_dec_nr_in_flight+0x230/0x230 [ 66.703974] ? rwlock_bug.part.0+0x90/0x90 [ 66.703974] ? _raw_spin_lock_irq+0x41/0x50 [ 66.703974] worker_thread+0x575/0x1190 [ 66.703974] ? process_one_work+0x1510/0x1510 [ 66.703974] kthread+0x2a0/0x340 [ 66.703974] ? kthread_complete_and_exit+0x20/0x20 [ 66.703974] ret_from_fork+0x22/0x30 [ 66.703974] </TASK> [ 66.703974] [ 66.703974] Allocated by task 267: [ 66.703974] kasan_save_stack+0x1e/0x40 [ 66.703974] __kasan_kmalloc+0x81/0xa0 [ 66.703974] nci_allocate_device+0xd3/0x390 [ 66.703974] nfcmrvl_nci_register_dev+0x183/0x2c0 [ 66.703974] nfcmrvl_nci_uart_open+0xf2/0x1dd [ 66.703974] nci_uart_tty_ioctl+0x2c3/0x4a0 [ 66.703974] tty_ioctl+0x764/0x1310 [ 66.703974] __x64_sys_ioctl+0x122/0x190 [ 66.703974] do_syscall_64+0x3b/0x90 [ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 66.703974] [ 66.703974] Freed by task 406: [ 66.703974] kasan_save_stack+0x1e/0x40 [ 66.703974] kasan_set_track+0x21/0x30 [ 66.703974] kasan_set_free_info+0x20/0x30 [ 66.703974] __kasan_slab_free+0x108/0x170 [ 66.703974] kfree+0xb0/0x330 [ 66.703974] nfcmrvl_nci_unregister_dev+0x90/0xd0 [ 66.703974] nci_uart_tty_close+0xdf/0x180 [ 66.703974] tty_ldisc_kill+0x73/0x110 [ 66.703974] tty_ldisc_hangup+0x281/0x5b0 [ 66.703974] __tty_hangup.part.0+0x431/0x890 [ 66.703974] tty_release+0x3a8/0xc80 [ 66.703974] __fput+0x1f0/0x8c0 [ 66.703974] task_work_run+0xc9/0x170 [ 66.703974] exit_to_user_mode_prepare+0x194/0x1a0 [ 66.703974] syscall_exit_to_user_mode+0x19/0x50 [ 66.703974] do_syscall_64+0x48/0x90 [ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0x ---truncated--- CVE-2022-49059 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/smc: Fix NULL pointer dereference in smc_pnet_find_ib() dev_name() was called with dev.parent as argument but without to NULL-check it before. Solve this by checking the pointer before the call to dev_name(). CVE-2022-49060 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: ethernet: stmmac: fix altr_tse_pcs function when using a fixed-link When using a fixed-link, the altr_tse_pcs driver crashes due to null-pointer dereference as no phy_device is provided to tse_pcs_fix_mac_speed function. Fix this by adding a check for phy_dev before calling the tse_pcs_fix_mac_speed() function. Also clean up the tse_pcs_fix_mac_speed function a bit. There is no need to check for splitter_base and sgmii_adapter_base because the driver will fail if these 2 variables are not derived from the device tree. CVE-2022-49061 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ice: arfs: fix use-after-free when freeing @rx_cpu_rmap The CI testing bots triggered the following splat: [ 718.203054] BUG: KASAN: use-after-free in free_irq_cpu_rmap+0x53/0x80 [ 718.206349] Read of size 4 at addr ffff8881bd127e00 by task sh/20834 [ 718.212852] CPU: 28 PID: 20834 Comm: sh Kdump: loaded Tainted: G S W IOE 5.17.0-rc8_nextqueue-devqueue-02643-g23f3121aca93 #1 [ 718.219695] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0012.070720200218 07/07/2020 [ 718.223418] Call Trace: [ 718.227139] [ 718.230783] dump_stack_lvl+0x33/0x42 [ 718.234431] print_address_description.constprop.9+0x21/0x170 [ 718.238177] ? free_irq_cpu_rmap+0x53/0x80 [ 718.241885] ? free_irq_cpu_rmap+0x53/0x80 [ 718.245539] kasan_report.cold.18+0x7f/0x11b [ 718.249197] ? free_irq_cpu_rmap+0x53/0x80 [ 718.252852] free_irq_cpu_rmap+0x53/0x80 [ 718.256471] ice_free_cpu_rx_rmap.part.11+0x37/0x50 [ice] [ 718.260174] ice_remove_arfs+0x5f/0x70 [ice] [ 718.263810] ice_rebuild_arfs+0x3b/0x70 [ice] [ 718.267419] ice_rebuild+0x39c/0xb60 [ice] [ 718.270974] ? asm_sysvec_apic_timer_interrupt+0x12/0x20 [ 718.274472] ? ice_init_phy_user_cfg+0x360/0x360 [ice] [ 718.278033] ? delay_tsc+0x4a/0xb0 [ 718.281513] ? preempt_count_sub+0x14/0xc0 [ 718.284984] ? delay_tsc+0x8f/0xb0 [ 718.288463] ice_do_reset+0x92/0xf0 [ice] [ 718.292014] ice_pci_err_resume+0x91/0xf0 [ice] [ 718.295561] pci_reset_function+0x53/0x80 <...> [ 718.393035] Allocated by task 690: [ 718.433497] Freed by task 20834: [ 718.495688] Last potentially related work creation: [ 718.568966] The buggy address belongs to the object at ffff8881bd127e00 which belongs to the cache kmalloc-96 of size 96 [ 718.574085] The buggy address is located 0 bytes inside of 96-byte region [ffff8881bd127e00, ffff8881bd127e60) [ 718.579265] The buggy address belongs to the page: [ 718.598905] Memory state around the buggy address: [ 718.601809] ffff8881bd127d00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc [ 718.604796] ffff8881bd127d80: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc [ 718.607794] >ffff8881bd127e00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc [ 718.610811] ^ [ 718.613819] ffff8881bd127e80: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc [ 718.617107] ffff8881bd127f00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc This is due to that free_irq_cpu_rmap() is always being called *after* (devm_)free_irq() and thus it tries to work with IRQ descs already freed. For example, on device reset the driver frees the rmap right before allocating a new one (the splat above). Make rmap creation and freeing function symmetrical with {request,free}_irq() calls i.e. do that on ifup/ifdown instead of device probe/remove/resume. These operations can be performed independently from the actual device aRFS configuration. Also, make sure ice_vsi_free_irq() clears IRQ affinity notifiers only when aRFS is disabled -- otherwise, CPU rmap sets and clears its own and they must not be touched manually. CVE-2022-49063 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix the svc_deferred_event trace class Fix a NULL deref crash that occurs when an svc_rqst is deferred while the sunrpc tracing subsystem is enabled. svc_revisit() sets dr->xprt to NULL, so it can't be relied upon in the tracepoint to provide the remote's address. Unfortunately we can't revert the "svc_deferred_class" hunk in commit ece200ddd54b ("sunrpc: Save remote presentation address in svc_xprt for trace events") because there is now a specific check of event format specifiers for unsafe dereferences. The warning that check emits is: event svc_defer_recv has unsafe dereference of argument 1 A "%pISpc" format specifier with a "struct sockaddr *" is indeed flagged by this check. Instead, take the brute-force approach used by the svcrdma_qp_error tracepoint. Convert the dr::addr field into a presentation address in the TP_fast_assign() arm of the trace event, and store that as a string. This fix can be backported to -stable kernels. In the meantime, commit c6ced22997ad ("tracing: Update print fmt check to handle new __get_sockaddr() macro") is now in v5.18, so this wonky fix can be replaced with __sockaddr() and friends properly during the v5.19 merge window. CVE-2022-49065 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: veth: Ensure eth header is in skb's linear part After feeding a decapsulated packet to a veth device with act_mirred, skb_headlen() may be 0. But veth_xmit() calls __dev_forward_skb(), which expects at least ETH_HLEN byte of linear data (as __dev_forward_skb2() calls eth_type_trans(), which pulls ETH_HLEN bytes unconditionally). Use pskb_may_pull() to ensure veth_xmit() respects this constraint. kernel BUG at include/linux/skbuff.h:2328! RIP: 0010:eth_type_trans+0xcf/0x140 Call Trace: <IRQ> __dev_forward_skb2+0xe3/0x160 veth_xmit+0x6e/0x250 [veth] dev_hard_start_xmit+0xc7/0x200 __dev_queue_xmit+0x47f/0x520 ? skb_ensure_writable+0x85/0xa0 ? skb_mpls_pop+0x98/0x1c0 tcf_mirred_act+0x442/0x47e [act_mirred] tcf_action_exec+0x86/0x140 fl_classify+0x1d8/0x1e0 [cls_flower] ? dma_pte_clear_level+0x129/0x1a0 ? dma_pte_clear_level+0x129/0x1a0 ? prb_fill_curr_block+0x2f/0xc0 ? skb_copy_bits+0x11a/0x220 __tcf_classify+0x58/0x110 tcf_classify_ingress+0x6b/0x140 __netif_receive_skb_core.constprop.0+0x47d/0xfd0 ? __iommu_dma_unmap_swiotlb+0x44/0x90 __netif_receive_skb_one_core+0x3d/0xa0 netif_receive_skb+0x116/0x170 be_process_rx+0x22f/0x330 [be2net] be_poll+0x13c/0x370 [be2net] __napi_poll+0x2a/0x170 net_rx_action+0x22f/0x2f0 __do_softirq+0xca/0x2a8 __irq_exit_rcu+0xc1/0xe0 common_interrupt+0x83/0xa0 CVE-2022-49066 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: Fix crash due to OOB write the driver uses libata's "tag" values from in various arrays. Since the mentioned patch bumped the ATA_TAG_INTERNAL to 32, the value of the SATA_DWC_QCMD_MAX needs to account for that. Otherwise ATA_TAG_INTERNAL usage cause similar crashes like this as reported by Tice Rex on the OpenWrt Forum and reproduced (with symbols) here: | BUG: Kernel NULL pointer dereference at 0x00000000 | Faulting instruction address: 0xc03ed4b8 | Oops: Kernel access of bad area, sig: 11 [#1] | BE PAGE_SIZE=4K PowerPC 44x Platform | CPU: 0 PID: 362 Comm: scsi_eh_1 Not tainted 5.4.163 #0 | NIP: c03ed4b8 LR: c03d27e8 CTR: c03ed36c | REGS: cfa59950 TRAP: 0300 Not tainted (5.4.163) | MSR: 00021000 <CE,ME> CR: 42000222 XER: 00000000 | DEAR: 00000000 ESR: 00000000 | GPR00: c03d27e8 cfa59a08 cfa55fe0 00000000 0fa46bc0 [...] | [..] | NIP [c03ed4b8] sata_dwc_qc_issue+0x14c/0x254 | LR [c03d27e8] ata_qc_issue+0x1c8/0x2dc | Call Trace: | [cfa59a08] [c003f4e0] __cancel_work_timer+0x124/0x194 (unreliable) | [cfa59a78] [c03d27e8] ata_qc_issue+0x1c8/0x2dc | [cfa59a98] [c03d2b3c] ata_exec_internal_sg+0x240/0x524 | [cfa59b08] [c03d2e98] ata_exec_internal+0x78/0xe0 | [cfa59b58] [c03d30fc] ata_read_log_page.part.38+0x1dc/0x204 | [cfa59bc8] [c03d324c] ata_identify_page_supported+0x68/0x130 | [...] This is because sata_dwc_dma_xfer_complete() NULLs the dma_pending's next neighbour "chan" (a *dma_chan struct) in this '32' case right here (line ~735): > hsdevp->dma_pending[tag] = SATA_DWC_DMA_PENDING_NONE; Then the next time, a dma gets issued; dma_dwc_xfer_setup() passes the NULL'd hsdevp->chan to the dmaengine_slave_config() which then causes the crash. With this patch, SATA_DWC_QCMD_MAX is now set to ATA_MAX_QUEUE + 1. This avoids the OOB. But please note, there was a worthwhile discussion on what ATA_TAG_INTERNAL and ATA_MAX_QUEUE is. And why there should not be a "fake" 33 command-long queue size. Ideally, the dw driver should account for the ATA_TAG_INTERNAL. In Damien Le Moal's words: "... having looked at the driver, it is a bigger change than just faking a 33rd "tag" that is in fact not a command tag at all." BugLink: https://github.com/openwrt/openwrt/issues/9505 CVE-2022-49073 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3: Fix GICR_CTLR.RWP polling It turns out that our polling of RWP is totally wrong when checking for it in the redistributors, as we test the *distributor* bit index, whereas it is a different bit number in the RDs... Oopsie boo. This is embarassing. Not only because it is wrong, but also because it took *8 years* to notice the blunder... Just fix the damn thing. CVE-2022-49074 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Fix use-after-free bug for mm struct Under certain conditions, such as MPI_Abort, the hfi1 cleanup code may represent the last reference held on the task mm. hfi1_mmu_rb_unregister() then drops the last reference and the mm is freed before the final use in hfi1_release_user_pages(). A new task may allocate the mm structure while it is still being used, resulting in problems. One manifestation is corruption of the mmap_sem counter leading to a hang in down_write(). Another is corruption of an mm struct that is in use by another task. CVE-2022-49076 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: lz4: fix LZ4_decompress_safe_partial read out of bound When partialDecoding, it is EOF if we've either filled the output buffer or can't proceed with reading an offset for following match. In some extreme corner cases when compressed data is suitably corrupted, UAF will occur. As reported by KASAN [1], LZ4_decompress_safe_partial may lead to read out of bound problem during decoding. lz4 upstream has fixed it [2] and this issue has been disscussed here [3] before. current decompression routine was ported from lz4 v1.8.3, bumping lib/lz4 to v1.9.+ is certainly a huge work to be done later, so, we'd better fix it first. [1] https://lore.kernel.org/all/000000000000830d1205cf7f0477@google.com/ [2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad# [3] https://lore.kernel.org/all/CC666AE8-4CA4-4951-B6FB-A2EFDE3AC03B@fb.com/ CVE-2022-49078 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: mm/mempolicy: fix mpol_new leak in shared_policy_replace If mpol_new is allocated but not used in restart loop, mpol_new will be freed via mpol_put before returning to the caller. But refcnt is not initialized yet, so mpol_put could not do the right things and might leak the unused mpol_new. This would happen if mempolicy was updated on the shared shmem file while the sp->lock has been dropped during the memory allocation. This issue could be triggered easily with the below code snippet if there are many processes doing the below work at the same time: shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT); shm = shmat(shmid, 0, 0); loop many times { mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0); mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask, maxnode, 0); } CVE-2022-49080 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix use after free in _scsih_expander_node_remove() The function mpt3sas_transport_port_remove() called in _scsih_expander_node_remove() frees the port field of the sas_expander structure, leading to the following use-after-free splat from KASAN when the ioc_info() call following that function is executed (e.g. when doing rmmod of the driver module): [ 3479.371167] ================================================================== [ 3479.378496] BUG: KASAN: use-after-free in _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.386936] Read of size 1 at addr ffff8881c037691c by task rmmod/1531 [ 3479.393524] [ 3479.395035] CPU: 18 PID: 1531 Comm: rmmod Not tainted 5.17.0-rc8+ #1436 [ 3479.401712] Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.1 06/02/2021 [ 3479.409263] Call Trace: [ 3479.411743] <TASK> [ 3479.413875] dump_stack_lvl+0x45/0x59 [ 3479.417582] print_address_description.constprop.0+0x1f/0x120 [ 3479.423389] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.429469] kasan_report.cold+0x83/0xdf [ 3479.433438] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.439514] _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.445411] ? _raw_spin_unlock_irqrestore+0x2d/0x40 [ 3479.452032] scsih_remove+0x525/0xc90 [mpt3sas] [ 3479.458212] ? mpt3sas_expander_remove+0x1d0/0x1d0 [mpt3sas] [ 3479.465529] ? down_write+0xde/0x150 [ 3479.470746] ? up_write+0x14d/0x460 [ 3479.475840] ? kernfs_find_ns+0x137/0x310 [ 3479.481438] pci_device_remove+0x65/0x110 [ 3479.487013] __device_release_driver+0x316/0x680 [ 3479.493180] driver_detach+0x1ec/0x2d0 [ 3479.498499] bus_remove_driver+0xe7/0x2d0 [ 3479.504081] pci_unregister_driver+0x26/0x250 [ 3479.510033] _mpt3sas_exit+0x2b/0x6cf [mpt3sas] [ 3479.516144] __x64_sys_delete_module+0x2fd/0x510 [ 3479.522315] ? free_module+0xaa0/0xaa0 [ 3479.527593] ? __cond_resched+0x1c/0x90 [ 3479.532951] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 3479.539607] ? syscall_enter_from_user_mode+0x21/0x70 [ 3479.546161] ? trace_hardirqs_on+0x1c/0x110 [ 3479.551828] do_syscall_64+0x35/0x80 [ 3479.556884] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 3479.563402] RIP: 0033:0x7f1fc482483b ... [ 3479.943087] ================================================================== Fix this by introducing the local variable port_id to store the port ID value before executing mpt3sas_transport_port_remove(). This local variable is then used in the call to ioc_info() instead of dereferencing the freed port structure. CVE-2022-49082 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: iommu/omap: Fix regression in probe for NULL pointer dereference Commit 3f6634d997db ("iommu: Use right way to retrieve iommu_ops") started triggering a NULL pointer dereference for some omap variants: __iommu_probe_device from probe_iommu_group+0x2c/0x38 probe_iommu_group from bus_for_each_dev+0x74/0xbc bus_for_each_dev from bus_iommu_probe+0x34/0x2e8 bus_iommu_probe from bus_set_iommu+0x80/0xc8 bus_set_iommu from omap_iommu_init+0x88/0xcc omap_iommu_init from do_one_initcall+0x44/0x24 This is caused by omap iommu probe returning 0 instead of ERR_PTR(-ENODEV) as noted by Jason Gunthorpe <jgg@ziepe.ca>. Looks like the regression already happened with an earlier commit 6785eb9105e3 ("iommu/omap: Convert to probe/release_device() call-backs") that changed the function return type and missed converting one place. CVE-2022-49083 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: qede: confirm skb is allocated before using qede_build_skb() assumes build_skb() always works and goes straight to skb_reserve(). However, build_skb() can fail under memory pressure. This results in a kernel panic because the skb to reserve is NULL. Add a check in case build_skb() failed to allocate and return NULL. The NULL return is handled correctly in callers to qede_build_skb(). CVE-2022-49084 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drbd: Fix five use after free bugs in get_initial_state In get_initial_state, it calls notify_initial_state_done(skb,..) if cb->args[5]==1. If genlmsg_put() failed in notify_initial_state_done(), the skb will be freed by nlmsg_free(skb). Then get_initial_state will goto out and the freed skb will be used by return value skb->len, which is a uaf bug. What's worse, the same problem goes even further: skb can also be freed in the notify_*_state_change -> notify_*_state calls below. Thus 4 additional uaf bugs happened. My patch lets the problem callee functions: notify_initial_state_done and notify_*_state_change return an error code if errors happen. So that the error codes could be propagated and the uaf bugs can be avoid. v2 reports a compilation warning. This v3 fixed this warning and built successfully in my local environment with no additional warnings. v2: https://lore.kernel.org/patchwork/patch/1435218/ CVE-2022-49085 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix leak of nested actions While parsing user-provided actions, openvswitch module may dynamically allocate memory and store pointers in the internal copy of the actions. So this memory has to be freed while destroying the actions. Currently there are only two such actions: ct() and set(). However, there are many actions that can hold nested lists of actions and ovs_nla_free_flow_actions() just jumps over them leaking the memory. For example, removal of the flow with the following actions will lead to a leak of the memory allocated by nf_ct_tmpl_alloc(): actions:clone(ct(commit),0) Non-freed set() action may also leak the 'dst' structure for the tunnel info including device references. Under certain conditions with a high rate of flow rotation that may cause significant memory leak problem (2MB per second in reporter's case). The problem is also hard to mitigate, because the user doesn't have direct control over the datapath flows generated by OVS. Fix that by iterating over all the nested actions and freeing everything that needs to be freed recursively. New build time assertion should protect us from this problem if new actions will be added in the future. Unfortunately, openvswitch module doesn't use NLA_F_NESTED, so all attributes has to be explicitly checked. sample() and clone() actions are mixing extra attributes into the user-provided action list. That prevents some code generalization too. CVE-2022-49086 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: dpaa2-ptp: Fix refcount leak in dpaa2_ptp_probe This node pointer is returned by of_find_compatible_node() with refcount incremented. Calling of_node_put() to aovid the refcount leak. CVE-2022-49088 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: IB/rdmavt: add lock to call to rvt_error_qp to prevent a race condition The documentation of the function rvt_error_qp says both r_lock and s_lock need to be held when calling that function. It also asserts using lockdep that both of those locks are held. However, the commit I referenced in Fixes accidentally makes the call to rvt_error_qp in rvt_ruc_loopback no longer covered by r_lock. This results in the lockdep assertion failing and also possibly in a race condition. CVE-2022-49089 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: arch/arm64: Fix topology initialization for core scheduling Arm64 systems rely on store_cpu_topology() to call update_siblings_masks() to transfer the toplogy to the various cpu masks. This needs to be done before the call to notify_cpu_starting() which tells the scheduler about each cpu found, otherwise the core scheduling data structures are setup in a way that does not match the actual topology. With smt_mask not setup correctly we bail on `cpumask_weight(smt_mask) == 1` for !leaders in: notify_cpu_starting() cpuhp_invoke_callback_range() sched_cpu_starting() sched_core_cpu_starting() which leads to rq->core not being correctly set for !leader-rq's. Without this change stress-ng (which enables core scheduling in its prctl tests in newer versions -- i.e. with PR_SCHED_CORE support) causes a warning and then a crash (trimmed for legibility): [ 1853.805168] ------------[ cut here ]------------ [ 1853.809784] task_rq(b)->core != rq->core [ 1853.809792] WARNING: CPU: 117 PID: 0 at kernel/sched/fair.c:11102 cfs_prio_less+0x1b4/0x1c4 ... [ 1854.015210] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... [ 1854.231256] Call trace: [ 1854.233689] pick_next_task+0x3dc/0x81c [ 1854.237512] __schedule+0x10c/0x4cc [ 1854.240988] schedule_idle+0x34/0x54 CVE-2022-49090 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/imx: Fix memory leak in imx_pd_connector_get_modes Avoid leaking the display mode variable if of_get_drm_display_mode fails. Addresses-Coverity-ID: 1443943 ("Resource leak") CVE-2022-49091 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: skbuff: fix coalescing for page_pool fragment recycling Fix a use-after-free when using page_pool with page fragments. We encountered this problem during normal RX in the hns3 driver: (1) Initially we have three descriptors in the RX queue. The first one allocates PAGE1 through page_pool, and the other two allocate one half of PAGE2 each. Page references look like this: RX_BD1 _______ PAGE1 RX_BD2 _______ PAGE2 RX_BD3 _________/ (2) Handle RX on the first descriptor. Allocate SKB1, eventually added to the receive queue by tcp_queue_rcv(). (3) Handle RX on the second descriptor. Allocate SKB2 and pass it to netif_receive_skb(): netif_receive_skb(SKB2) ip_rcv(SKB2) SKB3 = skb_clone(SKB2) SKB2 and SKB3 share a reference to PAGE2 through skb_shinfo()->dataref. The other ref to PAGE2 is still held by RX_BD3: SKB2 ---+- PAGE2 SKB3 __/ / RX_BD3 _________/ (3b) Now while handling TCP, coalesce SKB3 with SKB1: tcp_v4_rcv(SKB3) tcp_try_coalesce(to=SKB1, from=SKB3) // succeeds kfree_skb_partial(SKB3) skb_release_data(SKB3) // drops one dataref SKB1 _____ PAGE1 \____ SKB2 _____ PAGE2 / RX_BD3 _________/ In skb_try_coalesce(), __skb_frag_ref() takes a page reference to PAGE2, where it should instead have increased the page_pool frag reference, pp_frag_count. Without coalescing, when releasing both SKB2 and SKB3, a single reference to PAGE2 would be dropped. Now when releasing SKB1 and SKB2, two references to PAGE2 will be dropped, resulting in underflow. (3c) Drop SKB2: af_packet_rcv(SKB2) consume_skb(SKB2) skb_release_data(SKB2) // drops second dataref page_pool_return_skb_page(PAGE2) // drops one pp_frag_count SKB1 _____ PAGE1 \____ PAGE2 / RX_BD3 _________/ (4) Userspace calls recvmsg() Copies SKB1 and releases it. Since SKB3 was coalesced with SKB1, we release the SKB3 page as well: tcp_eat_recv_skb(SKB1) skb_release_data(SKB1) page_pool_return_skb_page(PAGE1) page_pool_return_skb_page(PAGE2) // drops second pp_frag_count (5) PAGE2 is freed, but the third RX descriptor was still using it! In our case this causes IOMMU faults, but it would silently corrupt memory if the IOMMU was disabled. Change the logic that checks whether pp_recycle SKBs can be coalesced. We still reject differing pp_recycle between 'from' and 'to' SKBs, but in order to avoid the situation described above, we also reject coalescing when both 'from' and 'to' are pp_recycled and 'from' is cloned. The new logic allows coalescing a cloned pp_recycle SKB into a page refcounted one, because in this case the release (4) will drop the right reference, the one taken by skb_try_coalesce(). CVE-2022-49093 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: zorro7xx: Fix a resource leak in zorro7xx_remove_one() The error handling path of the probe releases a resource that is not freed in the remove function. In some cases, a ioremap() must be undone. Add the missing iounmap() call in the remove function. CVE-2022-49095 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: sfc: add missing xdp queue reinitialization After rx/tx ring buffer size is changed, kernel panic occurs when it acts XDP_TX or XDP_REDIRECT. When tx/rx ring buffer size is changed(ethtool -G), sfc driver reallocates and reinitializes rx and tx queues and their buffer (tx_queue->buffer). But it misses reinitializing xdp queues(efx->xdp_tx_queues). So, while it is acting XDP_TX or XDP_REDIRECT, it uses the uninitialized tx_queue->buffer. A new function efx_set_xdp_channels() is separated from efx_set_channels() to handle only xdp queues. Splat looks like: BUG: kernel NULL pointer dereference, address: 000000000000002a #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#4] PREEMPT SMP NOPTI RIP: 0010:efx_tx_map_chunk+0x54/0x90 [sfc] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G D 5.17.0+ #55 e8beeee8289528f11357029357cf Code: 48 8b 8d a8 01 00 00 48 8d 14 52 4c 8d 2c d0 44 89 e0 48 85 c9 74 0e 44 89 e2 4c 89 f6 48 80 RSP: 0018:ffff92f121e45c60 EFLAGS: 00010297 RIP: 0010:efx_tx_map_chunk+0x54/0x90 [sfc] RAX: 0000000000000040 RBX: ffff92ea506895c0 RCX: ffffffffc0330870 RDX: 0000000000000001 RSI: 00000001139b10ce RDI: ffff92ea506895c0 RBP: ffffffffc0358a80 R08: 00000001139b110d R09: 0000000000000000 R10: 0000000000000001 R11: ffff92ea414c0088 R12: 0000000000000040 R13: 0000000000000018 R14: 00000001139b10ce R15: ffff92ea506895c0 FS: 0000000000000000(0000) GS:ffff92f121ec0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Code: 48 8b 8d a8 01 00 00 48 8d 14 52 4c 8d 2c d0 44 89 e0 48 85 c9 74 0e 44 89 e2 4c 89 f6 48 80 CR2: 000000000000002a CR3: 00000003e6810004 CR4: 00000000007706e0 RSP: 0018:ffff92f121e85c60 EFLAGS: 00010297 PKRU: 55555554 RAX: 0000000000000040 RBX: ffff92ea50689700 RCX: ffffffffc0330870 RDX: 0000000000000001 RSI: 00000001145a90ce RDI: ffff92ea50689700 RBP: ffffffffc0358a80 R08: 00000001145a910d R09: 0000000000000000 R10: 0000000000000001 R11: ffff92ea414c0088 R12: 0000000000000040 R13: 0000000000000018 R14: 00000001145a90ce R15: ffff92ea50689700 FS: 0000000000000000(0000) GS:ffff92f121e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000002a CR3: 00000003e6810005 CR4: 00000000007706e0 PKRU: 55555554 Call Trace: <IRQ> efx_xdp_tx_buffers+0x12b/0x3d0 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5] __efx_rx_packet+0x5c3/0x930 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5] efx_rx_packet+0x28c/0x2e0 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5] efx_ef10_ev_process+0x5f8/0xf40 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5] ? enqueue_task_fair+0x95/0x550 efx_poll+0xc4/0x360 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5] CVE-2022-49096 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: NFS: Avoid writeback threads getting stuck in mempool_alloc() In a low memory situation, allow the NFS writeback code to fail without getting stuck in infinite loops in mempool_alloc(). CVE-2022-49097 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Fix potential crash on module unload The vmbus driver relies on the panic notifier infrastructure to perform some operations when a panic event is detected. Since vmbus can be built as module, it is required that the driver handles both registering and unregistering such panic notifier callback. After commit 74347a99e73a ("x86/Hyper-V: Unload vmbus channel in hv panic callback") though, the panic notifier registration is done unconditionally in the module initialization routine whereas the unregistering procedure is conditionally guarded and executes only if HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE capability is set. This patch fixes that by unconditionally unregistering the panic notifier in the module's exit routine as well. CVE-2022-49098 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Fix initialization of device object in vmbus_device_register() Initialize the device's dma_{mask,parms} pointers and the device's dma_mask value before invoking device_register(). Address the following trace with 5.17-rc7: [ 49.646839] WARNING: CPU: 0 PID: 189 at include/linux/dma-mapping.h:543 netvsc_probe+0x37a/0x3a0 [hv_netvsc] [ 49.646928] Call Trace: [ 49.646930] <TASK> [ 49.646935] vmbus_probe+0x40/0x60 [hv_vmbus] [ 49.646942] really_probe+0x1ce/0x3b0 [ 49.646948] __driver_probe_device+0x109/0x180 [ 49.646952] driver_probe_device+0x23/0xa0 [ 49.646955] __device_attach_driver+0x76/0xe0 [ 49.646958] ? driver_allows_async_probing+0x50/0x50 [ 49.646961] bus_for_each_drv+0x84/0xd0 [ 49.646964] __device_attach+0xed/0x170 [ 49.646967] device_initial_probe+0x13/0x20 [ 49.646970] bus_probe_device+0x8f/0xa0 [ 49.646973] device_add+0x41a/0x8e0 [ 49.646975] ? hrtimer_init+0x28/0x80 [ 49.646981] device_register+0x1b/0x20 [ 49.646983] vmbus_device_register+0x5e/0xf0 [hv_vmbus] [ 49.646991] vmbus_add_channel_work+0x12d/0x190 [hv_vmbus] [ 49.646999] process_one_work+0x21d/0x3f0 [ 49.647002] worker_thread+0x4a/0x3b0 [ 49.647005] ? process_one_work+0x3f0/0x3f0 [ 49.647007] kthread+0xff/0x130 [ 49.647011] ? kthread_complete_and_exit+0x20/0x20 [ 49.647015] ret_from_fork+0x22/0x30 [ 49.647020] </TASK> [ 49.647021] ---[ end trace 0000000000000000 ]--- CVE-2022-49099 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: virtio_console: eliminate anonymous module_init & module_exit Eliminate anonymous module_init() and module_exit(), which can lead to confusion or ambiguity when reading System.map, crashes/oops/bugs, or an initcall_debug log. Give each of these init and exit functions unique driver-specific names to eliminate the anonymous names. Example 1: (System.map) ffffffff832fc78c t init ffffffff832fc79e t init ffffffff832fc8f8 t init Example 2: (initcall_debug log) calling init+0x0/0x12 @ 1 initcall init+0x0/0x12 returned 0 after 15 usecs calling init+0x0/0x60 @ 1 initcall init+0x0/0x60 returned 0 after 2 usecs calling init+0x0/0x9a @ 1 initcall init+0x0/0x9a returned 0 after 74 usecs CVE-2022-49100 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: habanalabs: fix possible memory leak in MMU DR fini This patch fixes what seems to be copy paste error. We will have a memory leak if the host-resident shadow is NULL (which will likely happen as the DR and HR are not dependent). CVE-2022-49102 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: NFSv4.2: fix reference count leaks in _nfs42_proc_copy_notify() [You don't often get email from xiongx18@fudan.edu.cn. Learn why this is important at http://aka.ms/LearnAboutSenderIdentification.] The reference counting issue happens in two error paths in the function _nfs42_proc_copy_notify(). In both error paths, the function simply returns the error code and forgets to balance the refcount of object `ctx`, bumped by get_nfs_open_context() earlier, which may cause refcount leaks. Fix it by balancing refcount of the `ctx` object before the function returns in both error paths. CVE-2022-49103 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 low In the Linux kernel, the following vulnerability has been resolved: staging: vchiq_core: handle NULL result of find_service_by_handle In case of an invalid handle the function find_servive_by_handle returns NULL. So take care of this and avoid a NULL pointer dereference. CVE-2022-49104 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: staging: wfx: fix an error handling in wfx_init_common() One error handler of wfx_init_common() return without calling ieee80211_free_hw(hw), which may result in memory leak. And I add one err label to unify the error handler, which is useful for the subsequent changes. CVE-2022-49105 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: staging: vchiq_arm: Avoid NULL ptr deref in vchiq_dump_platform_instances vchiq_get_state() can return a NULL pointer. So handle this cases and avoid a NULL pointer derefence in vchiq_dump_platform_instances. CVE-2022-49106 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ceph: fix memory leak in ceph_readdir when note_last_dentry returns error Reset the last_readdir at the same time, and add a comment explaining why we don't free last_readdir when dir_emit returns false. CVE-2022-49107 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ceph: fix inode reference leakage in ceph_get_snapdir() The ceph_get_inode() will search for or insert a new inode into the hash for the given vino, and return a reference to it. If new is non-NULL, its reference is consumed. We should release the reference when in error handing cases. CVE-2022-49109 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: revisit gc autotuning as of commit 4608fdfc07e1 ("netfilter: conntrack: collect all entries in one cycle") conntrack gc was changed to run every 2 minutes. On systems where conntrack hash table is set to large value, most evictions happen from gc worker rather than the packet path due to hash table distribution. This causes netlink event overflows when events are collected. This change collects average expiry of scanned entries and reschedules to the average remaining value, within 1 to 60 second interval. To avoid event overflows, reschedule after each bucket and add a limit for both run time and number of evictions per run. If more entries have to be evicted, reschedule and restart 1 jiffy into the future. CVE-2022-49110 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix use after free in hci_send_acl This fixes the following trace caused by receiving HCI_EV_DISCONN_PHY_LINK_COMPLETE which does call hci_conn_del without first checking if conn->type is in fact AMP_LINK and in case it is do properly cleanup upper layers with hci_disconn_cfm: ================================================================== BUG: KASAN: use-after-free in hci_send_acl+0xaba/0xc50 Read of size 8 at addr ffff88800e404818 by task bluetoothd/142 CPU: 0 PID: 142 Comm: bluetoothd Not tainted 5.17.0-rc5-00006-gda4022eeac1a #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x45/0x59 print_address_description.constprop.0+0x1f/0x150 kasan_report.cold+0x7f/0x11b hci_send_acl+0xaba/0xc50 l2cap_do_send+0x23f/0x3d0 l2cap_chan_send+0xc06/0x2cc0 l2cap_sock_sendmsg+0x201/0x2b0 sock_sendmsg+0xdc/0x110 sock_write_iter+0x20f/0x370 do_iter_readv_writev+0x343/0x690 do_iter_write+0x132/0x640 vfs_writev+0x198/0x570 do_writev+0x202/0x280 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RSP: 002b:00007ffce8a099b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 14 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10 RDX: 0000000000000001 RSI: 00007ffce8a099e0 RDI: 0000000000000015 RAX: ffffffffffffffda RBX: 00007ffce8a099e0 RCX: 00007f788fc3cf77 R10: 00007ffce8af7080 R11: 0000000000000246 R12: 000055e4ccf75580 RBP: 0000000000000015 R08: 0000000000000002 R09: 0000000000000001 </TASK> R13: 000055e4ccf754a0 R14: 000055e4ccf75cd0 R15: 000055e4ccf4a6b0 Allocated by task 45: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 hci_chan_create+0x9a/0x2f0 l2cap_conn_add.part.0+0x1a/0xdc0 l2cap_connect_cfm+0x236/0x1000 le_conn_complete_evt+0x15a7/0x1db0 hci_le_conn_complete_evt+0x226/0x2c0 hci_le_meta_evt+0x247/0x450 hci_event_packet+0x61b/0xe90 hci_rx_work+0x4d5/0xc50 process_one_work+0x8fb/0x15a0 worker_thread+0x576/0x1240 kthread+0x29d/0x340 ret_from_fork+0x1f/0x30 Freed by task 45: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0xfb/0x130 kfree+0xac/0x350 hci_conn_cleanup+0x101/0x6a0 hci_conn_del+0x27e/0x6c0 hci_disconn_phylink_complete_evt+0xe0/0x120 hci_event_packet+0x812/0xe90 hci_rx_work+0x4d5/0xc50 process_one_work+0x8fb/0x15a0 worker_thread+0x576/0x1240 kthread+0x29d/0x340 ret_from_fork+0x1f/0x30 The buggy address belongs to the object at ffff88800c0f0500 The buggy address is located 24 bytes inside of which belongs to the cache kmalloc-128 of size 128 The buggy address belongs to the page: 128-byte region [ffff88800c0f0500, ffff88800c0f0580) flags: 0x100000000000200(slab|node=0|zone=1) page:00000000fe45cd86 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xc0f0 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 raw: 0100000000000200 ffffea00003a2c80 dead000000000004 ffff8880078418c0 page dumped because: kasan: bad access detected ffff88800c0f0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc Memory state around the buggy address: >ffff88800c0f0500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88800c0f0480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800c0f0580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ---truncated--- CVE-2022-49111 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: mt76: fix monitor mode crash with sdio driver mt7921s driver may receive frames with fragment buffers. If there is a CTS packet received in monitor mode, the payload is 10 bytes only and need 6 bytes header padding after RXD buffer. However, only RXD in the first linear buffer, if we pull buffer size RXD-size+6 bytes with skb_pull(), that would trigger "BUG_ON(skb->len < skb->data_len)" in __skb_pull(). To avoid the nonlinear buffer issue, enlarge the RXD size from 128 to 256 to make sure all MCU operation in linear buffer. [ 52.007562] kernel BUG at include/linux/skbuff.h:2313! [ 52.007578] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 52.007987] pc : skb_pull+0x48/0x4c [ 52.008015] lr : mt7921_queue_rx_skb+0x494/0x890 [mt7921_common] [ 52.008361] Call trace: [ 52.008377] skb_pull+0x48/0x4c [ 52.008400] mt76s_net_worker+0x134/0x1b0 [mt76_sdio 35339a92c6eb7d4bbcc806a1d22f56365565135c] [ 52.008431] __mt76_worker_fn+0xe8/0x170 [mt76 ef716597d11a77150bc07e3fdd68eeb0f9b56917] [ 52.008449] kthread+0x148/0x3ac [ 52.008466] ret_from_fork+0x10/0x30 CVE-2022-49112 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: powerpc/secvar: fix refcount leak in format_show() Refcount leak will happen when format_show returns failure in multiple cases. Unified management of of_node_put can fix this problem. CVE-2022-49113 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: libfc: Fix use after free in fc_exch_abts_resp() fc_exch_release(ep) will decrease the ep's reference count. When the reference count reaches zero, it is freed. But ep is still used in the following code, which will lead to a use after free. Return after the fc_exch_release() call to avoid use after free. CVE-2022-49114 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Fix misused goto label Fix a misused goto label jump since that can result in a memory leak. CVE-2022-49115 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: Bluetooth: use memset avoid memory leaks Use memset to initialize structs to prevent memory leaks in l2cap_ecred_connect CVE-2022-49116 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: hisi_sas: Free irq vectors in order for v3 HW If the driver probe fails to request the channel IRQ or fatal IRQ, the driver will free the IRQ vectors before freeing the IRQs in free_irq(), and this will cause a kernel BUG like this: ------------[ cut here ]------------ kernel BUG at drivers/pci/msi.c:369! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Call trace: free_msi_irqs+0x118/0x13c pci_disable_msi+0xfc/0x120 pci_free_irq_vectors+0x24/0x3c hisi_sas_v3_probe+0x360/0x9d0 [hisi_sas_v3_hw] local_pci_probe+0x44/0xb0 work_for_cpu_fn+0x20/0x34 process_one_work+0x1d0/0x340 worker_thread+0x2e0/0x460 kthread+0x180/0x190 ret_from_fork+0x10/0x20 ---[ end trace b88990335b610c11 ]--- So we use devm_add_action() to control the order in which we free the vectors. CVE-2022-49118 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix memory leak in pm8001_chip_fw_flash_update_req() In pm8001_chip_fw_flash_update_build(), if pm8001_chip_fw_flash_update_build() fails, the struct fw_control_ex allocated must be freed. CVE-2022-49119 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix task leak in pm8001_send_abort_all() In pm8001_send_abort_all(), make sure to free the allocated sas task if pm8001_tag_alloc() or pm8001_mpi_build_cmd() fail. CVE-2022-49120 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix tag leaks on error In pm8001_chip_set_dev_state_req(), pm8001_chip_fw_flash_update_req(), pm80xx_chip_phy_ctl_req() and pm8001_chip_reg_dev_req() add missing calls to pm8001_tag_free() to free the allocated tag when pm8001_mpi_build_cmd() fails. Similarly, in pm8001_exec_internal_task_abort(), if the chip ->task_abort method fails, the tag allocated for the abort request task must be freed. Add the missing call to pm8001_tag_free(). CVE-2022-49121 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: dm ioctl: prevent potential spectre v1 gadget It appears like cmd could be a Spectre v1 gadget as it's supplied by a user and used as an array index. Prevent the contents of kernel memory from being leaked to userspace via speculative execution by using array_index_nospec. CVE-2022-49122 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix memory leaks Fix memory leaks related to operational reply queue's memory segments which are not getting freed while unloading the driver. CVE-2022-49126 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/bridge: Add missing pm_runtime_put_sync pm_runtime_get_sync() will increase the rumtime PM counter even when it returns an error. Thus a pairing decrement is needed to prevent refcount leak. Fix this by replacing this API with pm_runtime_resume_and_get(), which will not change the runtime PM counter on error. Besides, a matching decrement is needed on the error handling path to keep the counter balanced. CVE-2022-49128 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: mt76: mt7921: fix crash when startup fails. If the nic fails to start, it is possible that the reset_work has already been scheduled. Ensure the work item is canceled so we do not have use-after-free crash in case cleanup is called before the work item is executed. This fixes crash on my x86_64 apu2 when mt7921k radio fails to work. Radio still fails, but OS does not crash. CVE-2022-49129 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ath11k: mhi: use mhi_sync_power_up() If amss.bin was missing ath11k would crash during 'rmmod ath11k_pci'. The reason for that was that we were using mhi_async_power_up() which does not check any errors. But mhi_sync_power_up() on the other hand does check for errors so let's use that to fix the crash. I was not able to find a reason why an async version was used. ath11k_mhi_start() (which enables state ATH11K_MHI_POWER_ON) is called from ath11k_hif_power_up(), which can sleep. So sync version should be safe to use here. [ 145.569731] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN PTI [ 145.569789] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 145.569843] CPU: 2 PID: 1628 Comm: rmmod Kdump: loaded Tainted: G W 5.16.0-wt-ath+ #567 [ 145.569898] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021 [ 145.569956] RIP: 0010:ath11k_hal_srng_access_begin+0xb5/0x2b0 [ath11k] [ 145.570028] Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 ec 01 00 00 48 8b ab a8 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 ea 48 c1 ea 03 <0f> b6 14 02 48 89 e8 83 e0 07 83 c0 03 45 85 ed 75 48 38 d0 7c 08 [ 145.570089] RSP: 0018:ffffc900025d7ac0 EFLAGS: 00010246 [ 145.570144] RAX: dffffc0000000000 RBX: ffff88814fca2dd8 RCX: 1ffffffff50cb455 [ 145.570196] RDX: 0000000000000000 RSI: ffff88814fca2dd8 RDI: ffff88814fca2e80 [ 145.570252] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffa8659497 [ 145.570329] R10: fffffbfff50cb292 R11: 0000000000000001 R12: ffff88814fca0000 [ 145.570410] R13: 0000000000000000 R14: ffff88814fca2798 R15: ffff88814fca2dd8 [ 145.570465] FS: 00007fa399988540(0000) GS:ffff888233e00000(0000) knlGS:0000000000000000 [ 145.570519] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 145.570571] CR2: 00007fa399b51421 CR3: 0000000137898002 CR4: 00000000003706e0 [ 145.570623] Call Trace: [ 145.570675] <TASK> [ 145.570727] ? ath11k_ce_tx_process_cb+0x34b/0x860 [ath11k] [ 145.570797] ath11k_ce_tx_process_cb+0x356/0x860 [ath11k] [ 145.570864] ? tasklet_init+0x150/0x150 [ 145.570919] ? ath11k_ce_alloc_pipes+0x280/0x280 [ath11k] [ 145.570986] ? tasklet_clear_sched+0x42/0xe0 [ 145.571042] ? tasklet_kill+0xe9/0x1b0 [ 145.571095] ? tasklet_clear_sched+0xe0/0xe0 [ 145.571148] ? irq_has_action+0x120/0x120 [ 145.571202] ath11k_ce_cleanup_pipes+0x45a/0x580 [ath11k] [ 145.571270] ? ath11k_pci_stop+0x10e/0x170 [ath11k_pci] [ 145.571345] ath11k_core_stop+0x8a/0xc0 [ath11k] [ 145.571434] ath11k_core_deinit+0x9e/0x150 [ath11k] [ 145.571499] ath11k_pci_remove+0xd2/0x260 [ath11k_pci] [ 145.571553] pci_device_remove+0x9a/0x1c0 [ 145.571605] __device_release_driver+0x332/0x660 [ 145.571659] driver_detach+0x1e7/0x2c0 [ 145.571712] bus_remove_driver+0xe2/0x2d0 [ 145.571772] pci_unregister_driver+0x21/0x250 [ 145.571826] __do_sys_delete_module+0x30a/0x4b0 [ 145.571879] ? free_module+0xac0/0xac0 [ 145.571933] ? lockdep_hardirqs_on_prepare.part.0+0x18c/0x370 [ 145.571986] ? syscall_enter_from_user_mode+0x1d/0x50 [ 145.572039] ? lockdep_hardirqs_on+0x79/0x100 [ 145.572097] do_syscall_64+0x3b/0x90 [ 145.572153] entry_SYSCALL_64_after_hwframe+0x44/0xae Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPL_V1_V2_SILICONZ_LITE-2 CVE-2022-49130 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ath11k: fix kernel panic during unload/load ath11k modules Call netif_napi_del() from ath11k_ahb_free_ext_irq() to fix the following kernel panic when unload/load ath11k modules for few iterations. [ 971.201365] Unable to handle kernel paging request at virtual address 6d97a208 [ 971.204227] pgd = 594c2919 [ 971.211478] [6d97a208] *pgd=00000000 [ 971.214120] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 971.412024] CPU: 2 PID: 4435 Comm: insmod Not tainted 5.4.89 #0 [ 971.434256] Hardware name: Generic DT based system [ 971.440165] PC is at napi_by_id+0x10/0x40 [ 971.445019] LR is at netif_napi_add+0x160/0x1dc [ 971.743127] (napi_by_id) from [<807d89a0>] (netif_napi_add+0x160/0x1dc) [ 971.751295] (netif_napi_add) from [<7f1209ac>] (ath11k_ahb_config_irq+0xf8/0x414 [ath11k_ahb]) [ 971.759164] (ath11k_ahb_config_irq [ath11k_ahb]) from [<7f12135c>] (ath11k_ahb_probe+0x40c/0x51c [ath11k_ahb]) [ 971.768567] (ath11k_ahb_probe [ath11k_ahb]) from [<80666864>] (platform_drv_probe+0x48/0x94) [ 971.779670] (platform_drv_probe) from [<80664718>] (really_probe+0x1c8/0x450) [ 971.789389] (really_probe) from [<80664cc4>] (driver_probe_device+0x15c/0x1b8) [ 971.797547] (driver_probe_device) from [<80664f60>] (device_driver_attach+0x44/0x60) [ 971.805795] (device_driver_attach) from [<806650a0>] (__driver_attach+0x124/0x140) [ 971.814822] (__driver_attach) from [<80662adc>] (bus_for_each_dev+0x58/0xa4) [ 971.823328] (bus_for_each_dev) from [<80663a2c>] (bus_add_driver+0xf0/0x1e8) [ 971.831662] (bus_add_driver) from [<806658a4>] (driver_register+0xa8/0xf0) [ 971.839822] (driver_register) from [<8030269c>] (do_one_initcall+0x78/0x1ac) [ 971.847638] (do_one_initcall) from [<80392524>] (do_init_module+0x54/0x200) [ 971.855968] (do_init_module) from [<803945b0>] (load_module+0x1e30/0x1ffc) [ 971.864126] (load_module) from [<803948b0>] (sys_init_module+0x134/0x17c) [ 971.871852] (sys_init_module) from [<80301000>] (ret_fast_syscall+0x0/0x50) Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.6.0.1-00760-QCAHKSWPL_SILICONZ-1 CVE-2022-49131 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ath11k: pci: fix crash on suspend if board file is not found Mario reported that the kernel was crashing on suspend if ath11k was not able to find a board file: [ 473.693286] PM: Suspending system (s2idle) [ 473.693291] printk: Suspending console(s) (use no_console_suspend to debug) [ 474.407787] BUG: unable to handle page fault for address: 0000000000002070 [ 474.407791] #PF: supervisor read access in kernel mode [ 474.407794] #PF: error_code(0x0000) - not-present page [ 474.407798] PGD 0 P4D 0 [ 474.407801] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 474.407805] CPU: 2 PID: 2350 Comm: kworker/u32:14 Tainted: G W 5.16.0 #248 [...] [ 474.407868] Call Trace: [ 474.407870] <TASK> [ 474.407874] ? _raw_spin_lock_irqsave+0x2a/0x60 [ 474.407882] ? lock_timer_base+0x72/0xa0 [ 474.407889] ? _raw_spin_unlock_irqrestore+0x29/0x3d [ 474.407892] ? try_to_del_timer_sync+0x54/0x80 [ 474.407896] ath11k_dp_rx_pktlog_stop+0x49/0xc0 [ath11k] [ 474.407912] ath11k_core_suspend+0x34/0x130 [ath11k] [ 474.407923] ath11k_pci_pm_suspend+0x1b/0x50 [ath11k_pci] [ 474.407928] pci_pm_suspend+0x7e/0x170 [ 474.407935] ? pci_pm_freeze+0xc0/0xc0 [ 474.407939] dpm_run_callback+0x4e/0x150 [ 474.407947] __device_suspend+0x148/0x4c0 [ 474.407951] async_suspend+0x20/0x90 dmesg-efi-164255130401001: Oops#1 Part1 [ 474.407955] async_run_entry_fn+0x33/0x120 [ 474.407959] process_one_work+0x220/0x3f0 [ 474.407966] worker_thread+0x4a/0x3d0 [ 474.407971] kthread+0x17a/0x1a0 [ 474.407975] ? process_one_work+0x3f0/0x3f0 [ 474.407979] ? set_kthread_struct+0x40/0x40 [ 474.407983] ret_from_fork+0x22/0x30 [ 474.407991] </TASK> The issue here is that board file loading happens after ath11k_pci_probe() succesfully returns (ath11k initialisation happends asynchronously) and the suspend handler is still enabled, of course failing as ath11k is not properly initialised. Fix this by checking ATH11K_FLAG_QMI_FAIL during both suspend and resume. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPL_V1_V2_SILICONZ_LITE-2 CVE-2022-49132 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix memory leak [why] Resource release is needed on the error handling path to prevent memory leak. [how] Fix this by adding kfree on the error handling path. CVE-2022-49135 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence obj This issue takes place in an error path in amdgpu_cs_fence_to_handle_ioctl(). When `info->in.what` falls into default case, the function simply returns -EINVAL, forgetting to decrement the reference count of a dma_fence obj, which is bumped earlier by amdgpu_cs_get_fence(). This may result in reference count leaks. Fix it by decreasing the refcount of specific object before returning the error code. CVE-2022-49137 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 low In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix null ptr deref on hci_sync_conn_complete_evt This event is just specified for SCO and eSCO link types. On the reception of a HCI_Synchronous_Connection_Complete for a BDADDR of an existing LE connection, LE link type and a status that triggers the second case of the packet processing a NULL pointer dereference happens, as conn->link is NULL. CVE-2022-49139 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Avoid out of bounds access when parsing _CPC data If the NumEntries field in the _CPC return package is less than 2, do not attempt to access the "Revision" element of that package, because it may not be present then. BugLink: https://lore.kernel.org/lkml/20220322143534.GC32582@xsang-OptiPlex-9020/ CVE-2022-49145 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: block: Fix the maximum minor value is blk_alloc_ext_minor() ida_alloc_range(..., min, max, ...) returns values from min to max, inclusive. So, NR_EXT_DEVT is a valid idx returned by blk_alloc_ext_minor(). This is an issue because in device_add_disk(), this value is used in: ddev->devt = MKDEV(disk->major, disk->first_minor); and NR_EXT_DEVT is '(1 << MINORBITS)'. So, should 'disk->first_minor' be NR_EXT_DEVT, it would overflow. CVE-2022-49147 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: watch_queue: Free the page array when watch_queue is dismantled Commit 7ea1a0124b6d ("watch_queue: Free the alloc bitmap when the watch_queue is torn down") took care of the bitmap, but not the page array. BUG: memory leak unreferenced object 0xffff88810d9bc140 (size 32): comm "syz-executor335", pid 3603, jiffies 4294946994 (age 12.840s) hex dump (first 32 bytes): 40 a7 40 04 00 ea ff ff 00 00 00 00 00 00 00 00 @.@............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: kmalloc_array include/linux/slab.h:621 [inline] kcalloc include/linux/slab.h:652 [inline] watch_queue_set_size+0x12f/0x2e0 kernel/watch_queue.c:251 pipe_ioctl+0x82/0x140 fs/pipe.c:632 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] CVE-2022-49148 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: can: mcba_usb: properly check endpoint type Syzbot reported warning in usb_submit_urb() which is caused by wrong endpoint type. We should check that in endpoint is actually present to prevent this warning. Found pipes are now saved to struct mcba_priv and code uses them directly instead of making pipes in place. Fail log: | usb 5-1: BOGUS urb xfer, pipe 3 != type 1 | WARNING: CPU: 1 PID: 49 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 | Modules linked in: | CPU: 1 PID: 49 Comm: kworker/1:2 Not tainted 5.17.0-rc6-syzkaller-00184-g38f80f42147f #0 | Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 | Workqueue: usb_hub_wq hub_event | RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 | ... | Call Trace: | <TASK> | mcba_usb_start drivers/net/can/usb/mcba_usb.c:662 [inline] | mcba_usb_probe+0x8a3/0xc50 drivers/net/can/usb/mcba_usb.c:858 | usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 | call_driver_probe drivers/base/dd.c:517 [inline] CVE-2022-49151 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: wireguard: socket: free skb in send6 when ipv6 is disabled I got a memory leak report: unreferenced object 0xffff8881191fc040 (size 232): comm "kworker/u17:0", pid 23193, jiffies 4295238848 (age 3464.870s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff814c3ef4>] slab_post_alloc_hook+0x84/0x3b0 [<ffffffff814c8977>] kmem_cache_alloc_node+0x167/0x340 [<ffffffff832974fb>] __alloc_skb+0x1db/0x200 [<ffffffff82612b5d>] wg_socket_send_buffer_to_peer+0x3d/0xc0 [<ffffffff8260e94a>] wg_packet_send_handshake_initiation+0xfa/0x110 [<ffffffff8260ec81>] wg_packet_handshake_send_worker+0x21/0x30 [<ffffffff8119c558>] process_one_work+0x2e8/0x770 [<ffffffff8119ca2a>] worker_thread+0x4a/0x4b0 [<ffffffff811a88e0>] kthread+0x120/0x160 [<ffffffff8100242f>] ret_from_fork+0x1f/0x30 In function wg_socket_send_buffer_as_reply_to_skb() or wg_socket_send_ buffer_to_peer(), the semantics of send6() is required to free skb. But when CONFIG_IPV6 is disable, kfree_skb() is missing. This patch adds it to fix this bug. CVE-2022-49153 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 low In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: fix panic on out-of-bounds guest IRQ As guest_irq is coming from KVM_IRQFD API call, it may trigger crash in svm_update_pi_irte() due to out-of-bounds: crash> bt PID: 22218 TASK: ffff951a6ad74980 CPU: 73 COMMAND: "vcpu8" #0 [ffffb1ba6707fa40] machine_kexec at ffffffff8565b397 #1 [ffffb1ba6707fa90] __crash_kexec at ffffffff85788a6d #2 [ffffb1ba6707fb58] crash_kexec at ffffffff8578995d #3 [ffffb1ba6707fb70] oops_end at ffffffff85623c0d #4 [ffffb1ba6707fb90] no_context at ffffffff856692c9 #5 [ffffb1ba6707fbf8] exc_page_fault at ffffffff85f95b51 #6 [ffffb1ba6707fc50] asm_exc_page_fault at ffffffff86000ace [exception RIP: svm_update_pi_irte+227] RIP: ffffffffc0761b53 RSP: ffffb1ba6707fd08 RFLAGS: 00010086 RAX: ffffb1ba6707fd78 RBX: ffffb1ba66d91000 RCX: 0000000000000001 RDX: 00003c803f63f1c0 RSI: 000000000000019a RDI: ffffb1ba66db2ab8 RBP: 000000000000019a R8: 0000000000000040 R9: ffff94ca41b82200 R10: ffffffffffffffcf R11: 0000000000000001 R12: 0000000000000001 R13: 0000000000000001 R14: ffffffffffffffcf R15: 000000000000005f ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffb1ba6707fdb8] kvm_irq_routing_update at ffffffffc09f19a1 [kvm] #8 [ffffb1ba6707fde0] kvm_set_irq_routing at ffffffffc09f2133 [kvm] #9 [ffffb1ba6707fe18] kvm_vm_ioctl at ffffffffc09ef544 [kvm] RIP: 00007f143c36488b RSP: 00007f143a4e04b8 RFLAGS: 00000246 RAX: ffffffffffffffda RBX: 00007f05780041d0 RCX: 00007f143c36488b RDX: 00007f05780041d0 RSI: 000000004008ae6a RDI: 0000000000000020 RBP: 00000000000004e8 R8: 0000000000000008 R9: 00007f05780041e0 R10: 00007f0578004560 R11: 0000000000000246 R12: 00000000000004e0 R13: 000000000000001a R14: 00007f1424001c60 R15: 00007f0578003bc0 ORIG_RAX: 0000000000000010 CS: 0033 SS: 002b Vmx have been fix this in commit 3a8b0677fc61 (KVM: VMX: Do not BUG() on out-of-bounds guest IRQ), so we can just copy source from that to fix this. CVE-2022-49154 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Suppress a kernel complaint in qla_create_qpair() [ 12.323788] BUG: using smp_processor_id() in preemptible [00000000] code: systemd-udevd/1020 [ 12.332297] caller is qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx] [ 12.338417] CPU: 7 PID: 1020 Comm: systemd-udevd Tainted: G I --------- --- 5.14.0-29.el9.x86_64 #1 [ 12.348827] Hardware name: Dell Inc. PowerEdge R610/0F0XJ6, BIOS 6.6.0 05/22/2018 [ 12.356356] Call Trace: [ 12.358821] dump_stack_lvl+0x34/0x44 [ 12.362514] check_preemption_disabled+0xd9/0xe0 [ 12.367164] qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx] [ 12.372481] qla2x00_probe_one+0xa3a/0x1b80 [qla2xxx] [ 12.377617] ? _raw_spin_lock_irqsave+0x19/0x40 [ 12.384284] local_pci_probe+0x42/0x80 [ 12.390162] ? pci_match_device+0xd7/0x110 [ 12.396366] pci_device_probe+0xfd/0x1b0 [ 12.402372] really_probe+0x1e7/0x3e0 [ 12.408114] __driver_probe_device+0xfe/0x180 [ 12.414544] driver_probe_device+0x1e/0x90 [ 12.420685] __driver_attach+0xc0/0x1c0 [ 12.426536] ? __device_attach_driver+0xe0/0xe0 [ 12.433061] ? __device_attach_driver+0xe0/0xe0 [ 12.439538] bus_for_each_dev+0x78/0xc0 [ 12.445294] bus_add_driver+0x12b/0x1e0 [ 12.451021] driver_register+0x8f/0xe0 [ 12.456631] ? 0xffffffffc07bc000 [ 12.461773] qla2x00_module_init+0x1be/0x229 [qla2xxx] [ 12.468776] do_one_initcall+0x44/0x200 [ 12.474401] ? load_module+0xad3/0xba0 [ 12.479908] ? kmem_cache_alloc_trace+0x45/0x410 [ 12.486268] do_init_module+0x5c/0x280 [ 12.491730] __do_sys_init_module+0x12e/0x1b0 [ 12.497785] do_syscall_64+0x3b/0x90 [ 12.503029] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 12.509764] RIP: 0033:0x7f554f73ab2e CVE-2022-49155 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix scheduling while atomic The driver makes a call into midlayer (fc_remote_port_delete) which can put the thread to sleep. The thread that originates the call is in interrupt context. The combination of the two trigger a crash. Schedule the call in non-interrupt context where it is more safe. kernel: BUG: scheduling while atomic: swapper/7/0/0x00010000 kernel: Call Trace: kernel: <IRQ> kernel: dump_stack+0x66/0x81 kernel: __schedule_bug.cold.90+0x5/0x1d kernel: __schedule+0x7af/0x960 kernel: schedule+0x28/0x80 kernel: schedule_timeout+0x26d/0x3b0 kernel: wait_for_completion+0xb4/0x140 kernel: ? wake_up_q+0x70/0x70 kernel: __wait_rcu_gp+0x12c/0x160 kernel: ? sdev_evt_alloc+0xc0/0x180 [scsi_mod] kernel: synchronize_sched+0x6c/0x80 kernel: ? call_rcu_bh+0x20/0x20 kernel: ? __bpf_trace_rcu_invoke_callback+0x10/0x10 kernel: sdev_evt_alloc+0xfd/0x180 [scsi_mod] kernel: starget_for_each_device+0x85/0xb0 [scsi_mod] kernel: ? scsi_init_io+0x360/0x3d0 [scsi_mod] kernel: scsi_init_io+0x388/0x3d0 [scsi_mod] kernel: device_for_each_child+0x54/0x90 kernel: fc_remote_port_delete+0x70/0xe0 [scsi_transport_fc] kernel: qla2x00_schedule_rport_del+0x62/0xf0 [qla2xxx] kernel: qla2x00_mark_device_lost+0x9c/0xd0 [qla2xxx] kernel: qla24xx_handle_plogi_done_event+0x55f/0x570 [qla2xxx] kernel: qla2x00_async_login_sp_done+0xd2/0x100 [qla2xxx] kernel: qla24xx_logio_entry+0x13a/0x3c0 [qla2xxx] kernel: qla24xx_process_response_queue+0x306/0x400 [qla2xxx] kernel: qla24xx_msix_rsp_q+0x3f/0xb0 [qla2xxx] kernel: __handle_irq_event_percpu+0x40/0x180 kernel: handle_irq_event_percpu+0x30/0x80 kernel: handle_irq_event+0x36/0x60 CVE-2022-49156 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix premature hw access after PCI error After a recoverable PCI error has been detected and recovered, qla driver needs to check to see if the error condition still persist and/or wait for the OS to give the resume signal. Sep 8 22:26:03 localhost kernel: WARNING: CPU: 9 PID: 124606 at qla_tmpl.c:440 qla27xx_fwdt_entry_t266+0x55/0x60 [qla2xxx] Sep 8 22:26:03 localhost kernel: RIP: 0010:qla27xx_fwdt_entry_t266+0x55/0x60 [qla2xxx] Sep 8 22:26:03 localhost kernel: Call Trace: Sep 8 22:26:03 localhost kernel: ? qla27xx_walk_template+0xb1/0x1b0 [qla2xxx] Sep 8 22:26:03 localhost kernel: ? qla27xx_execute_fwdt_template+0x12a/0x160 [qla2xxx] Sep 8 22:26:03 localhost kernel: ? qla27xx_fwdump+0xa0/0x1c0 [qla2xxx] Sep 8 22:26:03 localhost kernel: ? qla2xxx_pci_mmio_enabled+0xfb/0x120 [qla2xxx] Sep 8 22:26:03 localhost kernel: ? report_mmio_enabled+0x44/0x80 Sep 8 22:26:03 localhost kernel: ? report_slot_reset+0x80/0x80 Sep 8 22:26:03 localhost kernel: ? pci_walk_bus+0x70/0x90 Sep 8 22:26:03 localhost kernel: ? aer_dev_correctable_show+0xc0/0xc0 Sep 8 22:26:03 localhost kernel: ? pcie_do_recovery+0x1bb/0x240 Sep 8 22:26:03 localhost kernel: ? aer_recover_work_func+0xaa/0xd0 Sep 8 22:26:03 localhost kernel: ? process_one_work+0x1a7/0x360 .. Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-8041:22: detected PCI disconnect. Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22: qla27xx_fwdt_entry_t262: dump ram MB failed. Area 5h start 198013h end 198013h Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22: Unable to capture FW dump Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-1015:22: cmd=0x0, waited 5221 msecs Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-680d:22: mmio enabled returning. Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-d04c:22: MBX Command timeout for cmd 0, iocontrol=ffffffff jiffies=10140f2e5 mb[0-3]=[0xffff 0xffff 0xffff 0xffff] CVE-2022-49157 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 low In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix warning message due to adisc being flushed Fix warning message due to adisc being flushed. Linux kernel triggered a warning message where a different error code type is not matching up with the expected type. Add additional translation of one error code type to another. WARNING: CPU: 2 PID: 1131623 at drivers/scsi/qla2xxx/qla_init.c:498 qla2x00_async_adisc_sp_done+0x294/0x2b0 [qla2xxx] CPU: 2 PID: 1131623 Comm: drmgr Not tainted 5.13.0-rc1-autotest #1 .. GPR28: c000000aaa9c8890 c0080000079ab678 c00000140a104800 c00000002bd19000 NIP [c00800000790857c] qla2x00_async_adisc_sp_done+0x294/0x2b0 [qla2xxx] LR [c008000007908578] qla2x00_async_adisc_sp_done+0x290/0x2b0 [qla2xxx] Call Trace: [c00000001cdc3620] [c008000007908578] qla2x00_async_adisc_sp_done+0x290/0x2b0 [qla2xxx] (unreliable) [c00000001cdc3710] [c0080000078f3080] __qla2x00_abort_all_cmds+0x1b8/0x580 [qla2xxx] [c00000001cdc3840] [c0080000078f589c] qla2x00_abort_all_cmds+0x34/0xd0 [qla2xxx] [c00000001cdc3880] [c0080000079153d8] qla2x00_abort_isp_cleanup+0x3f0/0x570 [qla2xxx] [c00000001cdc3920] [c0080000078fb7e8] qla2x00_remove_one+0x3d0/0x480 [qla2xxx] [c00000001cdc39b0] [c00000000071c274] pci_device_remove+0x64/0x120 [c00000001cdc39f0] [c0000000007fb818] device_release_driver_internal+0x168/0x2a0 [c00000001cdc3a30] [c00000000070e304] pci_stop_bus_device+0xb4/0x100 [c00000001cdc3a70] [c00000000070e4f0] pci_stop_and_remove_bus_device+0x20/0x40 [c00000001cdc3aa0] [c000000000073940] pci_hp_remove_devices+0x90/0x130 [c00000001cdc3b30] [c0080000070704d0] disable_slot+0x38/0x90 [rpaphp] [ c00000001cdc3b60] [c00000000073eb4c] power_write_file+0xcc/0x180 [c00000001cdc3be0] [c0000000007354bc] pci_slot_attr_store+0x3c/0x60 [c00000001cdc3c00] [c00000000055f820] sysfs_kf_write+0x60/0x80 [c00000001cdc3c20] [c00000000055df10] kernfs_fop_write_iter+0x1a0/0x290 [c00000001cdc3c70] [c000000000447c4c] new_sync_write+0x14c/0x1d0 [c00000001cdc3d10] [c00000000044b134] vfs_write+0x224/0x330 [c00000001cdc3d60] [c00000000044b3f4] ksys_write+0x74/0x130 [c00000001cdc3db0] [c00000000002df70] system_call_exception+0x150/0x2d0 [c00000001cdc3e10] [c00000000000d45c] system_call_common+0xec/0x278 CVE-2022-49158 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Implement ref count for SRB The timeout handler and the done function are racing. When qla2x00_async_iocb_timeout() starts to run it can be preempted by the normal response path (via the firmware?). qla24xx_async_gpsc_sp_done() releases the SRB unconditionally. When scheduling back to qla2x00_async_iocb_timeout() qla24xx_async_abort_cmd() will access an freed sp->qpair pointer: qla2xxx [0000:83:00.0]-2871:0: Async-gpsc timeout - hdl=63d portid=234500 50:06:0e:80:08:77:b6:21. qla2xxx [0000:83:00.0]-2853:0: Async done-gpsc res 0, WWPN 50:06:0e:80:08:77:b6:21 qla2xxx [0000:83:00.0]-2854:0: Async-gpsc OUT WWPN 20:45:00:27:f8:75:33:00 speeds=2c00 speed=0400. qla2xxx [0000:83:00.0]-28d8:0: qla24xx_handle_gpsc_event 50:06:0e:80:08:77:b6:21 DS 7 LS 6 rc 0 login 1|1 rscn 1|0 lid 5 BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: qla24xx_async_abort_cmd+0x1b/0x1c0 [qla2xxx] Obvious solution to this is to introduce a reference counter. One reference is taken for the normal code path (the 'good' case) and one for the timeout path. As we always race between the normal good case and the timeout/abort handler we need to serialize it. Also we cannot assume any order between the handlers. Since this is slow path we can use proper synchronization via locks. When we are able to cancel a timer (del_timer returns 1) we know there can't be any error handling in progress because the timeout handler hasn't expired yet, thus we can safely decrement the refcounter by one. If we are not able to cancel the timer, we know an abort handler is running. We have to make sure we call sp->done() in the abort handlers before calling kref_put(). CVE-2022-49159 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix crash during module load unload test During purex packet handling the driver was incorrectly freeing a pre-allocated structure. Fix this by skipping that entry. System crashed with the following stack during a module unload test. Call Trace: sbitmap_init_node+0x7f/0x1e0 sbitmap_queue_init_node+0x24/0x150 blk_mq_init_bitmaps+0x3d/0xa0 blk_mq_init_tags+0x68/0x90 blk_mq_alloc_map_and_rqs+0x44/0x120 blk_mq_alloc_set_map_and_rqs+0x63/0x150 blk_mq_alloc_tag_set+0x11b/0x230 scsi_add_host_with_dma.cold+0x3f/0x245 qla2x00_probe_one+0xd5a/0x1b80 [qla2xxx] Call Trace with slub_debug and debug kernel: kasan_report_invalid_free+0x50/0x80 __kasan_slab_free+0x137/0x150 slab_free_freelist_hook+0xc6/0x190 kfree+0xe8/0x2e0 qla2x00_free_device+0x3bb/0x5d0 [qla2xxx] qla2x00_remove_one+0x668/0xcf0 [qla2xxx] CVE-2022-49160 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: video: fbdev: sm712fb: Fix crash in smtcfb_write() When the sm712fb driver writes three bytes to the framebuffer, the driver will crash: BUG: unable to handle page fault for address: ffffc90001ffffff RIP: 0010:smtcfb_write+0x454/0x5b0 Call Trace: vfs_write+0x291/0xd60 ? do_sys_openat2+0x27d/0x350 ? __fget_light+0x54/0x340 ksys_write+0xce/0x190 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Fix it by removing the open-coded endianness fixup-code. CVE-2022-49162 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: imx-jpeg: fix a bug of accessing array out of bounds When error occurs in parsing jpeg, the slot isn't acquired yet, it may be the default value MXC_MAX_SLOTS. If the driver access the slot using the incorrect slot number, it will access array out of bounds. The result is the driver will change num_domains, which follows slot_data in struct mxc_jpeg_dev. Then the driver won't detach the pm domain at rmmod, which will lead to kernel panic when trying to insmod again. CVE-2022-49163 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: powerpc/tm: Fix more userspace r13 corruption Commit cf13435b730a ("powerpc/tm: Fix userspace r13 corruption") fixes a problem in treclaim where a SLB miss can occur on the thread_struct->ckpt_regs while SCRATCH0 is live with the saved user r13 value, clobbering it with the kernel r13 and ultimately resulting in kernel r13 being stored in ckpt_regs. There is an equivalent problem in trechkpt where the user r13 value is loaded into r13 from chkpt_regs to be recheckpointed, but a SLB miss could occur on ckpt_regs accesses after that, which will result in r13 being clobbered with a kernel value and that will get recheckpointed and then restored to user registers. The same memory page is accessed right before this critical window where a SLB miss could cause corruption, so hitting the bug requires the SLB entry be removed within a small window of instructions, which is possible if a SLB related MCE hits there. PAPR also permits the hypervisor to discard this SLB entry (because slb_shadow->persistent is only set to SLB_NUM_BOLTED) although it's not known whether any implementations would do this (KVM does not). So this is an extremely unlikely bug, only found by inspection. Fix this by also storing user r13 in a temporary location on the kernel stack and don't change the r13 register from kernel r13 until the RI=0 critical section that does not fault. The SCRATCH0 change is not strictly part of the fix, it's only used in the RI=0 section so it does not have the same problem as the previous SCRATCH0 bug. CVE-2022-49164 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: imx-jpeg: Prevent decoding NV12M jpegs into single-planar buffers If the application queues an NV12M jpeg as output buffer, but then queues a single planar capture buffer, the kernel will crash with "Unable to handle kernel NULL pointer dereference" in mxc_jpeg_addrs, prevent this by finishing the job with error. CVE-2022-49165 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: fix ext4_mb_mark_bb() with flex_bg with fast_commit In case of flex_bg feature (which is by default enabled), extents for any given inode might span across blocks from two different block group. ext4_mb_mark_bb() only reads the buffer_head of block bitmap once for the starting block group, but it fails to read it again when the extent length boundary overflows to another block group. Then in this below loop it accesses memory beyond the block group bitmap buffer_head and results into a data abort. for (i = 0; i < clen; i++) if (!mb_test_bit(blkoff + i, bitmap_bh->b_data) == !state) already++; This patch adds this functionality for checking block group boundary in ext4_mb_mark_bb() and update the buffer_head(bitmap_bh) for every different block group. w/o this patch, I was easily able to hit a data access abort using Power platform. <...> [ 74.327662] EXT4-fs error (device loop3): ext4_mb_generate_buddy:1141: group 11, block bitmap and bg descriptor inconsistent: 21248 vs 23294 free clusters [ 74.533214] EXT4-fs (loop3): shut down requested (2) [ 74.536705] Aborting journal on device loop3-8. [ 74.702705] BUG: Unable to handle kernel data access on read at 0xc00000005e980000 [ 74.703727] Faulting instruction address: 0xc0000000007bffb8 cpu 0xd: Vector: 300 (Data Access) at [c000000015db7060] pc: c0000000007bffb8: ext4_mb_mark_bb+0x198/0x5a0 lr: c0000000007bfeec: ext4_mb_mark_bb+0xcc/0x5a0 sp: c000000015db7300 msr: 800000000280b033 dar: c00000005e980000 dsisr: 40000000 current = 0xc000000027af6880 paca = 0xc00000003ffd5200 irqmask: 0x03 irq_happened: 0x01 pid = 5167, comm = mount <...> enter ? for help [c000000015db7380] c000000000782708 ext4_ext_clear_bb+0x378/0x410 [c000000015db7400] c000000000813f14 ext4_fc_replay+0x1794/0x2000 [c000000015db7580] c000000000833f7c do_one_pass+0xe9c/0x12a0 [c000000015db7710] c000000000834504 jbd2_journal_recover+0x184/0x2d0 [c000000015db77c0] c000000000841398 jbd2_journal_load+0x188/0x4a0 [c000000015db7880] c000000000804de8 ext4_fill_super+0x2638/0x3e10 [c000000015db7a40] c0000000005f8404 get_tree_bdev+0x2b4/0x350 [c000000015db7ae0] c0000000007ef058 ext4_get_tree+0x28/0x40 [c000000015db7b00] c0000000005f6344 vfs_get_tree+0x44/0x100 [c000000015db7b70] c00000000063c408 path_mount+0xdd8/0xe70 [c000000015db7c40] c00000000063c8f0 sys_mount+0x450/0x550 [c000000015db7d50] c000000000035770 system_call_exception+0x4a0/0x4e0 [c000000015db7e10] c00000000000c74c system_call_common+0xec/0x250 CVE-2022-49174 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: PM: core: keep irq flags in device_pm_check_callbacks() The function device_pm_check_callbacks() can be called under the spin lock (in the reported case it happens from genpd_add_device() -> dev_pm_domain_set(), when the genpd uses spinlocks rather than mutexes. However this function uncoditionally uses spin_lock_irq() / spin_unlock_irq(), thus not preserving the CPU flags. Use the irqsave/irqrestore instead. The backtrace for the reference: [ 2.752010] ------------[ cut here ]------------ [ 2.756769] raw_local_irq_restore() called with IRQs enabled [ 2.762596] WARNING: CPU: 4 PID: 1 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x34/0x50 [ 2.772338] Modules linked in: [ 2.775487] CPU: 4 PID: 1 Comm: swapper/0 Tainted: G S 5.17.0-rc6-00384-ge330d0d82eff-dirty #684 [ 2.781384] Freeing initrd memory: 46024K [ 2.785839] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.785841] pc : warn_bogus_irq_restore+0x34/0x50 [ 2.785844] lr : warn_bogus_irq_restore+0x34/0x50 [ 2.785846] sp : ffff80000805b7d0 [ 2.785847] x29: ffff80000805b7d0 x28: 0000000000000000 x27: 0000000000000002 [ 2.785850] x26: ffffd40e80930b18 x25: ffff7ee2329192b8 x24: ffff7edfc9f60800 [ 2.785853] x23: ffffd40e80930b18 x22: ffffd40e80930d30 x21: ffff7edfc0dffa00 [ 2.785856] x20: ffff7edfc09e3768 x19: 0000000000000000 x18: ffffffffffffffff [ 2.845775] x17: 6572206f74206465 x16: 6c696166203a3030 x15: ffff80008805b4f7 [ 2.853108] x14: 0000000000000000 x13: ffffd40e809550b0 x12: 00000000000003d8 [ 2.860441] x11: 0000000000000148 x10: ffffd40e809550b0 x9 : ffffd40e809550b0 [ 2.867774] x8 : 00000000ffffefff x7 : ffffd40e809ad0b0 x6 : ffffd40e809ad0b0 [ 2.875107] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.882440] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff7edfc03a8000 [ 2.889774] Call trace: [ 2.892290] warn_bogus_irq_restore+0x34/0x50 [ 2.896770] _raw_spin_unlock_irqrestore+0x94/0xa0 [ 2.901690] genpd_unlock_spin+0x20/0x30 [ 2.905724] genpd_add_device+0x100/0x2d0 [ 2.909850] __genpd_dev_pm_attach+0xa8/0x23c [ 2.914329] genpd_dev_pm_attach_by_id+0xc4/0x190 [ 2.919167] genpd_dev_pm_attach_by_name+0x3c/0xd0 [ 2.924086] dev_pm_domain_attach_by_name+0x24/0x30 [ 2.929102] psci_dt_attach_cpu+0x24/0x90 [ 2.933230] psci_cpuidle_probe+0x2d4/0x46c [ 2.937534] platform_probe+0x68/0xe0 [ 2.941304] really_probe.part.0+0x9c/0x2fc [ 2.945605] __driver_probe_device+0x98/0x144 [ 2.950085] driver_probe_device+0x44/0x15c [ 2.954385] __device_attach_driver+0xb8/0x120 [ 2.958950] bus_for_each_drv+0x78/0xd0 [ 2.962896] __device_attach+0xd8/0x180 [ 2.966843] device_initial_probe+0x14/0x20 [ 2.971144] bus_probe_device+0x9c/0xa4 [ 2.975092] device_add+0x380/0x88c [ 2.978679] platform_device_add+0x114/0x234 [ 2.983067] platform_device_register_full+0x100/0x190 [ 2.988344] psci_idle_init+0x6c/0xb0 [ 2.992113] do_one_initcall+0x74/0x3a0 [ 2.996060] kernel_init_freeable+0x2fc/0x384 [ 3.000543] kernel_init+0x28/0x130 [ 3.004132] ret_from_fork+0x10/0x20 [ 3.007817] irq event stamp: 319826 [ 3.011404] hardirqs last enabled at (319825): [<ffffd40e7eda0268>] __up_console_sem+0x78/0x84 [ 3.020332] hardirqs last disabled at (319826): [<ffffd40e7fd6d9d8>] el1_dbg+0x24/0x8c [ 3.028458] softirqs last enabled at (318312): [<ffffd40e7ec90410>] _stext+0x410/0x588 [ 3.036678] softirqs last disabled at (318299): [<ffffd40e7ed1bf68>] __irq_exit_rcu+0x158/0x174 [ 3.045607] ---[ end trace 0000000000000000 ]--- CVE-2022-49175 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: bfq: fix use-after-free in bfq_dispatch_request KASAN reports a use-after-free report when doing normal scsi-mq test [69832.239032] ================================================================== [69832.241810] BUG: KASAN: use-after-free in bfq_dispatch_request+0x1045/0x44b0 [69832.243267] Read of size 8 at addr ffff88802622ba88 by task kworker/3:1H/155 [69832.244656] [69832.245007] CPU: 3 PID: 155 Comm: kworker/3:1H Not tainted 5.10.0-10295-g576c6382529e #8 [69832.246626] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [69832.249069] Workqueue: kblockd blk_mq_run_work_fn [69832.250022] Call Trace: [69832.250541] dump_stack+0x9b/0xce [69832.251232] ? bfq_dispatch_request+0x1045/0x44b0 [69832.252243] print_address_description.constprop.6+0x3e/0x60 [69832.253381] ? __cpuidle_text_end+0x5/0x5 [69832.254211] ? vprintk_func+0x6b/0x120 [69832.254994] ? bfq_dispatch_request+0x1045/0x44b0 [69832.255952] ? bfq_dispatch_request+0x1045/0x44b0 [69832.256914] kasan_report.cold.9+0x22/0x3a [69832.257753] ? bfq_dispatch_request+0x1045/0x44b0 [69832.258755] check_memory_region+0x1c1/0x1e0 [69832.260248] bfq_dispatch_request+0x1045/0x44b0 [69832.261181] ? bfq_bfqq_expire+0x2440/0x2440 [69832.262032] ? blk_mq_delay_run_hw_queues+0xf9/0x170 [69832.263022] __blk_mq_do_dispatch_sched+0x52f/0x830 [69832.264011] ? blk_mq_sched_request_inserted+0x100/0x100 [69832.265101] __blk_mq_sched_dispatch_requests+0x398/0x4f0 [69832.266206] ? blk_mq_do_dispatch_ctx+0x570/0x570 [69832.267147] ? __switch_to+0x5f4/0xee0 [69832.267898] blk_mq_sched_dispatch_requests+0xdf/0x140 [69832.268946] __blk_mq_run_hw_queue+0xc0/0x270 [69832.269840] blk_mq_run_work_fn+0x51/0x60 [69832.278170] process_one_work+0x6d4/0xfe0 [69832.278984] worker_thread+0x91/0xc80 [69832.279726] ? __kthread_parkme+0xb0/0x110 [69832.280554] ? process_one_work+0xfe0/0xfe0 [69832.281414] kthread+0x32d/0x3f0 [69832.282082] ? kthread_park+0x170/0x170 [69832.282849] ret_from_fork+0x1f/0x30 [69832.283573] [69832.283886] Allocated by task 7725: [69832.284599] kasan_save_stack+0x19/0x40 [69832.285385] __kasan_kmalloc.constprop.2+0xc1/0xd0 [69832.286350] kmem_cache_alloc_node+0x13f/0x460 [69832.287237] bfq_get_queue+0x3d4/0x1140 [69832.287993] bfq_get_bfqq_handle_split+0x103/0x510 [69832.289015] bfq_init_rq+0x337/0x2d50 [69832.289749] bfq_insert_requests+0x304/0x4e10 [69832.290634] blk_mq_sched_insert_requests+0x13e/0x390 [69832.291629] blk_mq_flush_plug_list+0x4b4/0x760 [69832.292538] blk_flush_plug_list+0x2c5/0x480 [69832.293392] io_schedule_prepare+0xb2/0xd0 [69832.294209] io_schedule_timeout+0x13/0x80 [69832.295014] wait_for_common_io.constprop.1+0x13c/0x270 [69832.296137] submit_bio_wait+0x103/0x1a0 [69832.296932] blkdev_issue_discard+0xe6/0x160 [69832.297794] blk_ioctl_discard+0x219/0x290 [69832.298614] blkdev_common_ioctl+0x50a/0x1750 [69832.304715] blkdev_ioctl+0x470/0x600 [69832.305474] block_ioctl+0xde/0x120 [69832.306232] vfs_ioctl+0x6c/0xc0 [69832.306877] __se_sys_ioctl+0x90/0xa0 [69832.307629] do_syscall_64+0x2d/0x40 [69832.308362] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [69832.309382] [69832.309701] Freed by task 155: [69832.310328] kasan_save_stack+0x19/0x40 [69832.311121] kasan_set_track+0x1c/0x30 [69832.311868] kasan_set_free_info+0x1b/0x30 [69832.312699] __kasan_slab_free+0x111/0x160 [69832.313524] kmem_cache_free+0x94/0x460 [69832.314367] bfq_put_queue+0x582/0x940 [69832.315112] __bfq_bfqd_reset_in_service+0x166/0x1d0 [69832.317275] bfq_bfqq_expire+0xb27/0x2440 [69832.318084] bfq_dispatch_request+0x697/0x44b0 [69832.318991] __blk_mq_do_dispatch_sched+0x52f/0x830 [69832.319984] __blk_mq_sched_dispatch_requests+0x398/0x4f0 [69832.321087] blk_mq_sched_dispatch_requests+0xdf/0x140 [69832.322225] __blk_mq_run_hw_queue+0xc0/0x270 [69832.323114] blk_mq_run_work_fn+0x51/0x6 ---truncated--- CVE-2022-49176 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: hwrng: cavium - fix NULL but dereferenced coccicheck error Fix following coccicheck warning: ./drivers/char/hw_random/cavium-rng-vf.c:182:17-20: ERROR: pdev is NULL but dereferenced. CVE-2022-49177 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: block, bfq: don't move oom_bfqq Our test report a UAF: [ 2073.019181] ================================================================== [ 2073.019188] BUG: KASAN: use-after-free in __bfq_put_async_bfqq+0xa0/0x168 [ 2073.019191] Write of size 8 at addr ffff8000ccf64128 by task rmmod/72584 [ 2073.019192] [ 2073.019196] CPU: 0 PID: 72584 Comm: rmmod Kdump: loaded Not tainted 4.19.90-yk #5 [ 2073.019198] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 2073.019200] Call trace: [ 2073.019203] dump_backtrace+0x0/0x310 [ 2073.019206] show_stack+0x28/0x38 [ 2073.019210] dump_stack+0xec/0x15c [ 2073.019216] print_address_description+0x68/0x2d0 [ 2073.019220] kasan_report+0x238/0x2f0 [ 2073.019224] __asan_store8+0x88/0xb0 [ 2073.019229] __bfq_put_async_bfqq+0xa0/0x168 [ 2073.019233] bfq_put_async_queues+0xbc/0x208 [ 2073.019236] bfq_pd_offline+0x178/0x238 [ 2073.019240] blkcg_deactivate_policy+0x1f0/0x420 [ 2073.019244] bfq_exit_queue+0x128/0x178 [ 2073.019249] blk_mq_exit_sched+0x12c/0x160 [ 2073.019252] elevator_exit+0xc8/0xd0 [ 2073.019256] blk_exit_queue+0x50/0x88 [ 2073.019259] blk_cleanup_queue+0x228/0x3d8 [ 2073.019267] null_del_dev+0xfc/0x1e0 [null_blk] [ 2073.019274] null_exit+0x90/0x114 [null_blk] [ 2073.019278] __arm64_sys_delete_module+0x358/0x5a0 [ 2073.019282] el0_svc_common+0xc8/0x320 [ 2073.019287] el0_svc_handler+0xf8/0x160 [ 2073.019290] el0_svc+0x10/0x218 [ 2073.019291] [ 2073.019294] Allocated by task 14163: [ 2073.019301] kasan_kmalloc+0xe0/0x190 [ 2073.019305] kmem_cache_alloc_node_trace+0x1cc/0x418 [ 2073.019308] bfq_pd_alloc+0x54/0x118 [ 2073.019313] blkcg_activate_policy+0x250/0x460 [ 2073.019317] bfq_create_group_hierarchy+0x38/0x110 [ 2073.019321] bfq_init_queue+0x6d0/0x948 [ 2073.019325] blk_mq_init_sched+0x1d8/0x390 [ 2073.019330] elevator_switch_mq+0x88/0x170 [ 2073.019334] elevator_switch+0x140/0x270 [ 2073.019338] elv_iosched_store+0x1a4/0x2a0 [ 2073.019342] queue_attr_store+0x90/0xe0 [ 2073.019348] sysfs_kf_write+0xa8/0xe8 [ 2073.019351] kernfs_fop_write+0x1f8/0x378 [ 2073.019359] __vfs_write+0xe0/0x360 [ 2073.019363] vfs_write+0xf0/0x270 [ 2073.019367] ksys_write+0xdc/0x1b8 [ 2073.019371] __arm64_sys_write+0x50/0x60 [ 2073.019375] el0_svc_common+0xc8/0x320 [ 2073.019380] el0_svc_handler+0xf8/0x160 [ 2073.019383] el0_svc+0x10/0x218 [ 2073.019385] [ 2073.019387] Freed by task 72584: [ 2073.019391] __kasan_slab_free+0x120/0x228 [ 2073.019394] kasan_slab_free+0x10/0x18 [ 2073.019397] kfree+0x94/0x368 [ 2073.019400] bfqg_put+0x64/0xb0 [ 2073.019404] bfqg_and_blkg_put+0x90/0xb0 [ 2073.019408] bfq_put_queue+0x220/0x228 [ 2073.019413] __bfq_put_async_bfqq+0x98/0x168 [ 2073.019416] bfq_put_async_queues+0xbc/0x208 [ 2073.019420] bfq_pd_offline+0x178/0x238 [ 2073.019424] blkcg_deactivate_policy+0x1f0/0x420 [ 2073.019429] bfq_exit_queue+0x128/0x178 [ 2073.019433] blk_mq_exit_sched+0x12c/0x160 [ 2073.019437] elevator_exit+0xc8/0xd0 [ 2073.019440] blk_exit_queue+0x50/0x88 [ 2073.019443] blk_cleanup_queue+0x228/0x3d8 [ 2073.019451] null_del_dev+0xfc/0x1e0 [null_blk] [ 2073.019459] null_exit+0x90/0x114 [null_blk] [ 2073.019462] __arm64_sys_delete_module+0x358/0x5a0 [ 2073.019467] el0_svc_common+0xc8/0x320 [ 2073.019471] el0_svc_handler+0xf8/0x160 [ 2073.019474] el0_svc+0x10/0x218 [ 2073.019475] [ 2073.019479] The buggy address belongs to the object at ffff8000ccf63f00 which belongs to the cache kmalloc-1024 of size 1024 [ 2073.019484] The buggy address is located 552 bytes inside of 1024-byte region [ffff8000ccf63f00, ffff8000ccf64300) [ 2073.019486] The buggy address belongs to the page: [ 2073.019492] page:ffff7e000333d800 count:1 mapcount:0 mapping:ffff8000c0003a00 index:0x0 compound_mapcount: 0 [ 2073.020123] flags: 0x7ffff0000008100(slab|head) [ 2073.020403] raw: 07ffff0000008100 ffff7e0003334c08 ffff7e00001f5a08 ffff8000c0003a00 [ 2073.020409] ra ---truncated--- CVE-2022-49179 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: LSM: general protection fault in legacy_parse_param The usual LSM hook "bail on fail" scheme doesn't work for cases where a security module may return an error code indicating that it does not recognize an input. In this particular case Smack sees a mount option that it recognizes, and returns 0. A call to a BPF hook follows, which returns -ENOPARAM, which confuses the caller because Smack has processed its data. The SELinux hook incorrectly returns 1 on success. There was a time when this was correct, however the current expectation is that it return 0 on success. This is repaired. CVE-2022-49180 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: hns3: add vlan list lock to protect vlan list When adding port base VLAN, vf VLAN need to remove from HW and modify the vlan state in vf VLAN list as false. If the periodicity task is freeing the same node, it may cause "use after free" error. This patch adds a vlan list lock to protect the vlan list. CVE-2022-49182 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: pinctrl: nomadik: Add missing of_node_put() in nmk_pinctrl_probe This node pointer is returned by of_parse_phandle() with refcount incremented in this function. Calling of_node_put() to avoid the refcount leak. CVE-2022-49185 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: clk: Fix clk_hw_get_clk() when dev is NULL Any registered clk_core structure can have a NULL pointer in its dev field. While never actually documented, this is evidenced by the wide usage of clk_register and clk_hw_register with a NULL device pointer, and the fact that the core of_clk_hw_register() function also passes a NULL device pointer. A call to clk_hw_get_clk() on a clk_hw struct whose clk_core is in that case will result in a NULL pointer derefence when it calls dev_name() on that NULL device pointer. Add a test for this case and use NULL as the dev_id if the device pointer is NULL. CVE-2022-49187 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: remoteproc: qcom_q6v5_mss: Fix some leaks in q6v5_alloc_memory_region The device_node pointer is returned by of_parse_phandle() or of_get_child_by_name() with refcount incremented. We should use of_node_put() on it when done. This function only call of_node_put(node) when of_address_to_resource succeeds, missing error cases. CVE-2022-49188 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: clk: qcom: clk-rcg2: Update logic to calculate D value for RCG The display pixel clock has a requirement on certain newer platforms to support M/N as (2/3) and the final D value calculated results in underflow errors. As the current implementation does not check for D value is within the accepted range for a given M & N value. Update the logic to calculate the final D value based on the range. CVE-2022-49189 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ice: fix 'scheduling while atomic' on aux critical err interrupt There's a kernel BUG splat on processing aux critical error interrupts in ice_misc_intr(): [ 2100.917085] BUG: scheduling while atomic: swapper/15/0/0x00010000 ... [ 2101.060770] Call Trace: [ 2101.063229] <IRQ> [ 2101.065252] dump_stack+0x41/0x60 [ 2101.068587] __schedule_bug.cold.100+0x4c/0x58 [ 2101.073060] __schedule+0x6a4/0x830 [ 2101.076570] schedule+0x35/0xa0 [ 2101.079727] schedule_preempt_disabled+0xa/0x10 [ 2101.084284] __mutex_lock.isra.7+0x310/0x420 [ 2101.088580] ? ice_misc_intr+0x201/0x2e0 [ice] [ 2101.093078] ice_send_event_to_aux+0x25/0x70 [ice] [ 2101.097921] ice_misc_intr+0x220/0x2e0 [ice] [ 2101.102232] __handle_irq_event_percpu+0x40/0x180 [ 2101.106965] handle_irq_event_percpu+0x30/0x80 [ 2101.111434] handle_irq_event+0x36/0x53 [ 2101.115292] handle_edge_irq+0x82/0x190 [ 2101.119148] handle_irq+0x1c/0x30 [ 2101.122480] do_IRQ+0x49/0xd0 [ 2101.125465] common_interrupt+0xf/0xf [ 2101.129146] </IRQ> ... As Andrew correctly mentioned previously[0], the following call ladder happens: ice_misc_intr() <- hardirq ice_send_event_to_aux() device_lock() mutex_lock() might_sleep() might_resched() <- oops Add a new PF state bit which indicates that an aux critical error occurred and serve it in ice_service_task() in process context. The new ice_pf::oicr_err_reg is read-write in both hardirq and process contexts, but only 3 bits of non-critical data probably aren't worth explicit synchronizing (and they're even in the same byte [31:24]). [0] https://lore.kernel.org/all/YeSRUVmrdmlUXHDn@lunn.ch CVE-2022-49193 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: Use stronger register read/writes to assure ordering GCC12 appears to be much smarter about its dependency tracking and is aware that the relaxed variants are just normal loads and stores and this is causing problems like: [ 210.074549] ------------[ cut here ]------------ [ 210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet): transmit queue 1 timed out [ 210.086717] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:529 dev_watchdog+0x234/0x240 [ 210.095044] Modules linked in: genet(E) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat] [ 210.146561] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110 [ 210.146927] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 5.17.0-rc7G12+ #58 [ 210.153226] CPPC Cpufreq:cppc_scale_freq_workfn: failed to read perf counters [ 210.161349] Hardware name: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS EDK2-DEV 02/08/2022 [ 210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 210.161358] pc : dev_watchdog+0x234/0x240 [ 210.161364] lr : dev_watchdog+0x234/0x240 [ 210.161368] sp : ffff8000080a3a40 [ 210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20 [ 210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08 [ 210.212321] x23: 0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000 [ 210.219491] x20: 0000000000000001 x19: ffff55b1426884c8 x18: ffffffffffffffff [ 210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15: 6d736e617274203a [ 210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0 [ 210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9 : ffffcd4258bdad9c [ 210.248171] x8 : 00000000ffffdfff x7 : 000000000000003f x6 : 0000000000000000 [ 210.255341] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000001000 [ 210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 : 0000000000000044 [ 210.269682] Call trace: [ 210.272133] dev_watchdog+0x234/0x240 [ 210.275811] call_timer_fn+0x3c/0x15c [ 210.279489] __run_timers.part.0+0x288/0x310 [ 210.283777] run_timer_softirq+0x48/0x80 [ 210.287716] __do_softirq+0x128/0x360 [ 210.291392] __irq_exit_rcu+0x138/0x140 [ 210.295243] irq_exit_rcu+0x1c/0x30 [ 210.298745] el1_interrupt+0x38/0x54 [ 210.302334] el1h_64_irq_handler+0x18/0x24 [ 210.306445] el1h_64_irq+0x7c/0x80 [ 210.309857] arch_cpu_idle+0x18/0x2c [ 210.313445] default_idle_call+0x4c/0x140 [ 210.317470] cpuidle_idle_call+0x14c/0x1a0 [ 210.321584] do_idle+0xb0/0x100 [ 210.324737] cpu_startup_entry+0x30/0x8c [ 210.328675] secondary_start_kernel+0xe4/0x110 [ 210.333138] __secondary_switched+0x94/0x98 The assumption when these were relaxed seems to be that device memory would be mapped non reordering, and that other constructs (spinlocks/etc) would provide the barriers to assure that packet data and in memory rings/queues were ordered with respect to device register reads/writes. This itself seems a bit sketchy, but the real problem with GCC12 is that it is moving the actual reads/writes around at will as though they were independent operations when in truth they are not, but the compiler can't know that. When looking at the assembly dumps for many of these routines its possible to see very clean, but not strictly in program order operations occurring as the compiler would be free to do if these weren't actually register reads/write operations. Its possible to suppress the timeout with a liberal bit of dma_mb()'s sprinkled around but the device still seems unable to reliably send/receive data. A better plan is to use the safer readl/writel everywhere. Since this partially reverts an older commit, which notes the use of the relaxed variants for performance reasons. I would suggest that any performance problems ---truncated--- CVE-2022-49194 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Fix use after free in remove_phb_dynamic() In remove_phb_dynamic() we use &phb->io_resource, after we've called device_unregister(&host_bridge->dev). But the unregister may have freed phb, because pcibios_free_controller_deferred() is the release function for the host_bridge. If there are no outstanding references when we call device_unregister() then phb will be freed out from under us. This has gone mainly unnoticed, but with slub_debug and page_poison enabled it can lead to a crash: PID: 7574 TASK: c0000000d492cb80 CPU: 13 COMMAND: "drmgr" #0 [c0000000e4f075a0] crash_kexec at c00000000027d7dc #1 [c0000000e4f075d0] oops_end at c000000000029608 #2 [c0000000e4f07650] __bad_page_fault at c0000000000904b4 #3 [c0000000e4f076c0] do_bad_slb_fault at c00000000009a5a8 #4 [c0000000e4f076f0] data_access_slb_common_virt at c000000000008b30 Data SLB Access [380] exception frame: R0: c000000000167250 R1: c0000000e4f07a00 R2: c000000002a46100 R3: c000000002b39ce8 R4: 00000000000000c0 R5: 00000000000000a9 R6: 3894674d000000c0 R7: 0000000000000000 R8: 00000000000000ff R9: 0000000000000100 R10: 6b6b6b6b6b6b6b6b R11: 0000000000008000 R12: c00000000023da80 R13: c0000009ffd38b00 R14: 0000000000000000 R15: 000000011c87f0f0 R16: 0000000000000006 R17: 0000000000000003 R18: 0000000000000002 R19: 0000000000000004 R20: 0000000000000005 R21: 000000011c87ede8 R22: 000000011c87c5a8 R23: 000000011c87d3a0 R24: 0000000000000000 R25: 0000000000000001 R26: c0000000e4f07cc8 R27: c00000004d1cc400 R28: c0080000031d00e8 R29: c00000004d23d800 R30: c00000004d1d2400 R31: c00000004d1d2540 NIP: c000000000167258 MSR: 8000000000009033 OR3: c000000000e9f474 CTR: 0000000000000000 LR: c000000000167250 XER: 0000000020040003 CCR: 0000000024088420 MQ: 0000000000000000 DAR: 6b6b6b6b6b6b6ba3 DSISR: c0000000e4f07920 Syscall Result: fffffffffffffff2 [NIP : release_resource+56] [LR : release_resource+48] #5 [c0000000e4f07a00] release_resource at c000000000167258 (unreliable) #6 [c0000000e4f07a30] remove_phb_dynamic at c000000000105648 #7 [c0000000e4f07ab0] dlpar_remove_slot at c0080000031a09e8 [rpadlpar_io] #8 [c0000000e4f07b50] remove_slot_store at c0080000031a0b9c [rpadlpar_io] #9 [c0000000e4f07be0] kobj_attr_store at c000000000817d8c #10 [c0000000e4f07c00] sysfs_kf_write at c00000000063e504 #11 [c0000000e4f07c20] kernfs_fop_write_iter at c00000000063d868 #12 [c0000000e4f07c70] new_sync_write at c00000000054339c #13 [c0000000e4f07d10] vfs_write at c000000000546624 #14 [c0000000e4f07d60] ksys_write at c0000000005469f4 #15 [c0000000e4f07db0] system_call_exception at c000000000030840 #16 [c0000000e4f07e10] system_call_vectored_common at c00000000000c168 To avoid it, we can take a reference to the host_bridge->dev until we're done using phb. Then when we drop the reference the phb will be freed. CVE-2022-49196 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/nldev: Prevent underflow in nldev_stat_set_counter_dynamic_doit() This code checks "index" for an upper bound but it does not check for negatives. Change the type to unsigned to prevent underflows. CVE-2022-49199 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btmtksdio: Fix kernel oops in btmtksdio_interrupt Fix the following kernel oops in btmtksdio_interrrupt [ 14.339134] btmtksdio_interrupt+0x28/0x54 [ 14.339139] process_sdio_pending_irqs+0x68/0x1a0 [ 14.339144] sdio_irq_work+0x40/0x70 [ 14.339154] process_one_work+0x184/0x39c [ 14.339160] worker_thread+0x228/0x3e8 [ 14.339168] kthread+0x148/0x3ac [ 14.339176] ret_from_fork+0x10/0x30 That happened because hdev->power_on is already called before sdio_set_drvdata which btmtksdio_interrupt handler relies on is not properly set up. The details are shown as the below: hci_register_dev would run queue_work(hdev->req_workqueue, &hdev->power_on) as WQ_HIGHPRI workqueue_struct to complete the power-on sequeunce and thus hci_power_on may run before sdio_set_drvdata is done in btmtksdio_probe. The hci_dev_do_open in hci_power_on would initialize the device and enable the interrupt and thus it is possible that btmtksdio_interrupt is being called right before sdio_set_drvdata is filled out. When btmtksdio_interrupt is being called and sdio_set_drvdata is not filled , the kernel oops is going to happen because btmtksdio_interrupt access an uninitialized pointer. CVE-2022-49200 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ibmvnic: fix race between xmit and reset There is a race between reset and the transmit paths that can lead to ibmvnic_xmit() accessing an scrq after it has been freed in the reset path. It can result in a crash like: Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc0080000016189f8 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c0080000016189f8] ibmvnic_xmit+0x60/0xb60 [ibmvnic] LR [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 Call Trace: [c008000001618f08] ibmvnic_xmit+0x570/0xb60 [ibmvnic] (unreliable) [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 [c000000000c9cfcc] sch_direct_xmit+0xec/0x330 [c000000000bfe640] __dev_xmit_skb+0x3a0/0x9d0 [c000000000c00ad4] __dev_queue_xmit+0x394/0x730 [c008000002db813c] __bond_start_xmit+0x254/0x450 [bonding] [c008000002db8378] bond_start_xmit+0x40/0xc0 [bonding] [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 [c000000000c00ca4] __dev_queue_xmit+0x564/0x730 [c000000000cf97e0] neigh_hh_output+0xd0/0x180 [c000000000cfa69c] ip_finish_output2+0x31c/0x5c0 [c000000000cfd244] __ip_queue_xmit+0x194/0x4f0 [c000000000d2a3c4] __tcp_transmit_skb+0x434/0x9b0 [c000000000d2d1e0] __tcp_retransmit_skb+0x1d0/0x6a0 [c000000000d2d984] tcp_retransmit_skb+0x34/0x130 [c000000000d310e8] tcp_retransmit_timer+0x388/0x6d0 [c000000000d315ec] tcp_write_timer_handler+0x1bc/0x330 [c000000000d317bc] tcp_write_timer+0x5c/0x200 [c000000000243270] call_timer_fn+0x50/0x1c0 [c000000000243704] __run_timers.part.0+0x324/0x460 [c000000000243894] run_timer_softirq+0x54/0xa0 [c000000000ea713c] __do_softirq+0x15c/0x3e0 [c000000000166258] __irq_exit_rcu+0x158/0x190 [c000000000166420] irq_exit+0x20/0x40 [c00000000002853c] timer_interrupt+0x14c/0x2b0 [c000000000009a00] decrementer_common_virt+0x210/0x220 --- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2c The immediate cause of the crash is the access of tx_scrq in the following snippet during a reset, where the tx_scrq can be either NULL or an address that will soon be invalid: ibmvnic_xmit() { ... tx_scrq = adapter->tx_scrq[queue_num]; txq = netdev_get_tx_queue(netdev, queue_num); ind_bufp = &tx_scrq->ind_buf; if (test_bit(0, &adapter->resetting)) { ... } But beyond that, the call to ibmvnic_xmit() itself is not safe during a reset and the reset path attempts to avoid this by stopping the queue in ibmvnic_cleanup(). However just after the queue was stopped, an in-flight ibmvnic_complete_tx() could have restarted the queue even as the reset is progressing. Since the queue was restarted we could get a call to ibmvnic_xmit() which can then access the bad tx_scrq (or other fields). We cannot however simply have ibmvnic_complete_tx() check the ->resetting bit and skip starting the queue. This can race at the "back-end" of a good reset which just restarted the queue but has not cleared the ->resetting bit yet. If we skip restarting the queue due to ->resetting being true, the queue would remain stopped indefinitely potentially leading to transmit timeouts. IOW ->resetting is too broad for this purpose. Instead use a new flag that indicates whether or not the queues are active. Only the open/ reset paths control when the queues are active. ibmvnic_complete_tx() and others wake up the queue only if the queue is marked active. So we will have: A. reset/open thread in ibmvnic_cleanup() and __ibmvnic_open() ->resetting = true ->tx_queues_active = false disable tx queues ... ->tx_queues_active = true start tx queues B. Tx interrupt in ibmvnic_complete_tx(): if (->tx_queues_active) netif_wake_subqueue(); To ensure that ->tx_queues_active and state of the queues are consistent, we need a lock which: - must also be taken in the interrupt path (ibmvnic_complete_tx()) - shared across the multiple ---truncated--- CVE-2022-49201 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix memory leak in error flow for subscribe event routine In case the second xa_insert() fails, the obj_event is not released. Fix the error unwind flow to free that memory to avoid a memory leak. CVE-2022-49206 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent some integer underflows My static checker complains that: drivers/infiniband/hw/irdma/ctrl.c:3605 irdma_sc_ceq_init() warn: can subtract underflow 'info->dev->hmc_fpm_misc.max_ceqs'? It appears that "info->dev->hmc_fpm_misc.max_ceqs" comes from the firmware in irdma_sc_parse_fpm_query_buf() so, yes, there is a chance that it could be zero. Even if we trust the firmware, it's easy enough to change the condition just as a hardenning measure. CVE-2022-49208 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: atmel: fix refcount issue in atmel_nand_controller_init The reference counting issue happens in several error handling paths on a refcounted object "nc->dmac". In these paths, the function simply returns the error code, forgetting to balance the reference count of "nc->dmac", increased earlier by dma_request_channel(), which may cause refcount leaks. Fix it by decrementing the refcount of specific object in those error paths. CVE-2022-49212 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ath10k: Fix error handling in ath10k_setup_msa_resources The device_node pointer is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. This function only calls of_node_put() in the regular path. And it will cause refcount leak in error path. CVE-2022-49213 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: powerpc/64s: Don't use DSISR for SLB faults Since commit 46ddcb3950a2 ("powerpc/mm: Show if a bad page fault on data is read or write.") we use page_fault_is_write(regs->dsisr) in __bad_page_fault() to determine if the fault is for a read or write, and change the message printed accordingly. But SLB faults, aka Data Segment Interrupts, don't set DSISR (Data Storage Interrupt Status Register) to a useful value. All ISA versions from v2.03 through v3.1 specify that the Data Segment Interrupt sets DSISR "to an undefined value". As far as I can see there's no mention of SLB faults setting DSISR in any BookIV content either. This manifests as accesses that should be a read being incorrectly reported as writes, for example, using the xmon "dump" command: 0:mon> d 0x5deadbeef0000000 5deadbeef0000000 [359526.415354][ C6] BUG: Unable to handle kernel data access on write at 0x5deadbeef0000000 [359526.415611][ C6] Faulting instruction address: 0xc00000000010a300 cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf400] pc: c00000000010a300: mread+0x90/0x190 If we disassemble the PC, we see a load instruction: 0:mon> di c00000000010a300 c00000000010a300 89490000 lbz r10,0(r9) We can also see in exceptions-64s.S that the data_access_slb block doesn't set IDSISR=1, which means it doesn't load DSISR into pt_regs. So the value we're using to determine if the fault is a read/write is some stale value in pt_regs from a previous page fault. Rework the printing logic to separate the SLB fault case out, and only print read/write in the cases where we can determine it. The result looks like eg: 0:mon> d 0x5deadbeef0000000 5deadbeef0000000 [ 721.779525][ C6] BUG: Unable to handle kernel data access at 0x5deadbeef0000000 [ 721.779697][ C6] Faulting instruction address: 0xc00000000014cbe0 cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf390] 0:mon> d 0 0000000000000000 [ 742.793242][ C6] BUG: Kernel NULL pointer dereference at 0x00000000 [ 742.793316][ C6] Faulting instruction address: 0xc00000000014cbe0 cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf390] CVE-2022-49214 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix reference leak in tegra_dsi_ganged_probe The reference taken by 'of_find_device_by_node()' must be released when not needed anymore. Add put_device() call to fix this. CVE-2022-49216 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix abort all task initialization In pm80xx_send_abort_all(), the n_elem field of the ccb used is not initialized to 0. This missing initialization sometimes lead to the task completion path seeing the ccb with a non-zero n_elem resulting in the execution of invalid dma_unmap_sg() calls in pm8001_ccb_task_free(), causing a crash such as: [ 197.676341] RIP: 0010:iommu_dma_unmap_sg+0x6d/0x280 [ 197.700204] RSP: 0018:ffff889bbcf89c88 EFLAGS: 00010012 [ 197.705485] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff83d0bda0 [ 197.712687] RDX: 0000000000000002 RSI: 0000000000000000 RDI: ffff88810dffc0d0 [ 197.719887] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff8881c790098b [ 197.727089] R10: ffffed1038f20131 R11: 0000000000000001 R12: 0000000000000000 [ 197.734296] R13: ffff88810dffc0d0 R14: 0000000000000010 R15: 0000000000000000 [ 197.741493] FS: 0000000000000000(0000) GS:ffff889bbcf80000(0000) knlGS:0000000000000000 [ 197.749659] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 197.755459] CR2: 00007f16c1b42734 CR3: 0000000004814000 CR4: 0000000000350ee0 [ 197.762656] Call Trace: [ 197.765127] <IRQ> [ 197.767162] pm8001_ccb_task_free+0x5f1/0x820 [pm80xx] [ 197.772364] ? do_raw_spin_unlock+0x54/0x220 [ 197.776680] pm8001_mpi_task_abort_resp+0x2ce/0x4f0 [pm80xx] [ 197.782406] process_oq+0xe85/0x7890 [pm80xx] [ 197.786817] ? lock_acquire+0x194/0x490 [ 197.790697] ? handle_irq_event+0x10e/0x1b0 [ 197.794920] ? mpi_sata_completion+0x2d70/0x2d70 [pm80xx] [ 197.800378] ? __wake_up_bit+0x100/0x100 [ 197.804340] ? lock_is_held_type+0x98/0x110 [ 197.808565] pm80xx_chip_isr+0x94/0x130 [pm80xx] [ 197.813243] tasklet_action_common.constprop.0+0x24b/0x2f0 [ 197.818785] __do_softirq+0x1b5/0x82d [ 197.822485] ? do_raw_spin_unlock+0x54/0x220 [ 197.826799] __irq_exit_rcu+0x17e/0x1e0 [ 197.830678] irq_exit_rcu+0xa/0x20 [ 197.834114] common_interrupt+0x78/0x90 [ 197.840051] </IRQ> [ 197.844236] <TASK> [ 197.848397] asm_common_interrupt+0x1e/0x40 Avoid this issue by always initializing the ccb n_elem field to 0 in pm8001_send_abort_all(), pm8001_send_read_log() and pm80xx_send_abort_all(). CVE-2022-49217 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/dp: Fix OOB read when handling Post Cursor2 register The link_status array was not large enough to read the Adjust Request Post Cursor2 register, so remove the common helper function to avoid an OOB read, found with a -Warray-bounds build: drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_get_adjust_request_post_cursor': drivers/gpu/drm/drm_dp_helper.c:59:27: error: array subscript 10 is outside array bounds of 'const u8[6]' {aka 'const unsigned char[6]'} [-Werror=array-bounds] 59 | return link_status[r - DP_LANE0_1_STATUS]; | ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/drm_dp_helper.c:147:51: note: while referencing 'link_status' 147 | u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZE], | ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Replace the only user of the helper with an open-coded fetch and decode, similar to drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c. CVE-2022-49218 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: populate connector of struct dp_panel DP CTS test case 4.2.2.6 has valid edid with bad checksum on purpose and expect DP source return correct checksum. During drm edid read, correct edid checksum is calculated and stored at connector::real_edid_checksum. The problem is struct dp_panel::connector never be assigned, instead the connector is stored in struct msm_dp::connector. When we run compliance testing test case 4.2.2.6 dp_panel_handle_sink_request() won't have a valid edid set in struct dp_panel::edid so we'll try to use the connectors real_edid_checksum and hit a NULL pointer dereference error because the connector pointer is never assigned. Changes in V2: -- populate panel connector at msm_dp_modeset_init() instead of at dp_panel_read_sink_caps() Changes in V3: -- remove unhelpful kernel crash trace commit text -- remove renaming dp_display parameter to dp Changes in V4: -- add more details to commit text Changes in v10: -- group into one series Changes in v11: -- drop drm/msm/dp: dp_link_parse_sink_count() return immediately if aux read Signee-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com> CVE-2022-49221 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/bridge: anx7625: Fix overflow issue on reading EDID The length of EDID block can be longer than 256 bytes, so we should use `int` instead of `u8` for the `edid_pos` variable. CVE-2022-49222 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: power: supply: ab8500: Fix memory leak in ab8500_fg_sysfs_init kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add(): If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Fix memory leak by calling kobject_put(). CVE-2022-49224 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: asix: add proper error handling of usb read errors Syzbot once again hit uninit value in asix driver. The problem still the same -- asix_read_cmd() reads less bytes, than was requested by caller. Since all read requests are performed via asix_read_cmd() let's catch usb related error there and add __must_check notation to be sure all callers actually check return value. So, this patch adds sanity check inside asix_read_cmd(), that simply checks if bytes read are not less, than was requested and adds missing error handling of asix_read_cmd() all across the driver code. CVE-2022-49226 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: igc: avoid kernel warning when changing RX ring parameters Calling ethtool changing the RX ring parameters like this: $ ethtool -G eth0 rx 1024 on igc triggers kernel warnings like this: [ 225.198467] ------------[ cut here ]------------ [ 225.198473] Missing unregister, handled but fix driver [ 225.198485] WARNING: CPU: 7 PID: 959 at net/core/xdp.c:168 xdp_rxq_info_reg+0x79/0xd0 [...] [ 225.198601] Call Trace: [ 225.198604] <TASK> [ 225.198609] igc_setup_rx_resources+0x3f/0xe0 [igc] [ 225.198617] igc_ethtool_set_ringparam+0x30e/0x450 [igc] [ 225.198626] ethnl_set_rings+0x18a/0x250 [ 225.198631] genl_family_rcv_msg_doit+0xca/0x110 [ 225.198637] genl_rcv_msg+0xce/0x1c0 [ 225.198640] ? rings_prepare_data+0x60/0x60 [ 225.198644] ? genl_get_cmd+0xd0/0xd0 [ 225.198647] netlink_rcv_skb+0x4e/0xf0 [ 225.198652] genl_rcv+0x24/0x40 [ 225.198655] netlink_unicast+0x20e/0x330 [ 225.198659] netlink_sendmsg+0x23f/0x480 [ 225.198663] sock_sendmsg+0x5b/0x60 [ 225.198667] __sys_sendto+0xf0/0x160 [ 225.198671] ? handle_mm_fault+0xb2/0x280 [ 225.198676] ? do_user_addr_fault+0x1eb/0x690 [ 225.198680] __x64_sys_sendto+0x20/0x30 [ 225.198683] do_syscall_64+0x38/0x90 [ 225.198687] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 225.198693] RIP: 0033:0x7f7ae38ac3aa igc_ethtool_set_ringparam() copies the igc_ring structure but neglects to reset the xdp_rxq_info member before calling igc_setup_rx_resources(). This in turn calls xdp_rxq_info_reg() with an already registered xdp_rxq_info. Make sure to unregister the xdp_rxq_info structure first in igc_setup_rx_resources. CVE-2022-49227 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix a NULL pointer dereference in amdgpu_dm_connector_add_common_modes() In amdgpu_dm_connector_add_common_modes(), amdgpu_dm_create_common_mode() is assigned to mode and is passed to drm_mode_probed_add() directly after that. drm_mode_probed_add() passes &mode->head to list_add_tail(), and there is a dereference of it in list_add_tail() without recoveries, which could lead to NULL pointer dereference on failure of amdgpu_dm_create_common_mode(). Fix this by adding a NULL check of mode. This bug was found by a static analyzer. Builds with 'make allyesconfig' show no new warnings, and our static analyzer no longer warns about this code. CVE-2022-49232 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ath9k_htc: fix uninit value bugs Syzbot reported 2 KMSAN bugs in ath9k. All of them are caused by missing field initialization. In htc_connect_service() svc_meta_len and pad are not initialized. Based on code it looks like in current skb there is no service data, so simply initialize svc_meta_len to 0. htc_issue_send() does not initialize htc_frame_hdr::control array. Based on firmware code, it will initialize it by itself, so simply zero whole array to make KMSAN happy Fail logs: BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline] hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479 htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline] htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275 ... Uninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [inline] htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258 ... Bytes 4-7 of 18 are uninitialized Memory access of size 18 starts at ffff888027377e00 BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline] hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479 htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline] htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275 ... Uninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [inline] htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258 ... Bytes 16-17 of 18 are uninitialized Memory access of size 18 starts at ffff888027377e00 CVE-2022-49235 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF due to race between btf_try_get_module and load_module While working on code to populate kfunc BTF ID sets for module BTF from its initcall, I noticed that by the time the initcall is invoked, the module BTF can already be seen by userspace (and the BPF verifier). The existing btf_try_get_module calls try_module_get which only fails if mod->state == MODULE_STATE_GOING, i.e. it can increment module reference when module initcall is happening in parallel. Currently, BTF parsing happens from MODULE_STATE_COMING notifier callback. At this point, the module initcalls have not been invoked. The notifier callback parses and prepares the module BTF, allocates an ID, which publishes it to userspace, and then adds it to the btf_modules list allowing the kernel to invoke btf_try_get_module for the BTF. However, at this point, the module has not been fully initialized (i.e. its initcalls have not finished). The code in module.c can still fail and free the module, without caring for other users. However, nothing stops btf_try_get_module from succeeding between the state transition from MODULE_STATE_COMING to MODULE_STATE_LIVE. This leads to a use-after-free issue when BPF program loads successfully in the state transition, load_module's do_init_module call fails and frees the module, and BPF program fd on close calls module_put for the freed module. Future patch has test case to verify we don't regress in this area in future. There are multiple points after prepare_coming_module (in load_module) where failure can occur and module loading can return error. We illustrate and test for the race using the last point where it can practically occur (in module __init function). An illustration of the race: CPU 0 CPU 1 load_module notifier_call(MODULE_STATE_COMING) btf_parse_module btf_alloc_id // Published to userspace list_add(&btf_mod->list, btf_modules) mod->init(...) ... ^ bpf_check | check_pseudo_btf_id | btf_try_get_module | returns true | ... ... | module __init in progress return prog_fd | ... ... V if (ret < 0) free_module(mod) ... close(prog_fd) ... bpf_prog_free_deferred module_put(used_btf.mod) // use-after-free We fix this issue by setting a flag BTF_MODULE_F_LIVE, from the notifier callback when MODULE_STATE_LIVE state is reached for the module, so that we return NULL from btf_try_get_module for modules that are not fully formed. Since try_module_get already checks that module is not in MODULE_STATE_GOING state, and that is the only transition a live module can make before being removed from btf_modules list, this is enough to close the race and prevent the bug. A later selftest patch crafts the race condition artifically to verify that it has been fixed, and that verifier fails to load program (with ENXIO). Lastly, a couple of comments: 1. Even if this race didn't exist, it seems more appropriate to only access resources (ksyms and kfuncs) of a fully formed module which has been initialized completely. 2. This patch was born out of need for synchronization against module initcall for the next patch, so it is needed for correctness even without the aforementioned race condition. The BTF resources initialized by module initcall are set up once and then only looked up, so just waiting until the initcall has finished ensures correct behavior. CVE-2022-49236 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd934x: Add missing of_node_put() in wcd934x_codec_parse_data The device_node pointer is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. This is similar to commit 64b92de9603f ("ASoC: wcd9335: fix a leaked reference by adding missing of_node_put") CVE-2022-49239 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: atmel: Fix error handling in sam9x5_wm8731_driver_probe The device_node pointer is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. This function only calls of_node_put() in the regular path. And it will cause refcount leak in error path. CVE-2022-49241 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 low In the Linux kernel, the following vulnerability has been resolved: ASoC: mxs: Fix error handling in mxs_sgtl5000_probe This function only calls of_node_put() in the regular path. And it will cause refcount leak in error paths. For example, when codec_np is NULL, saif_np[0] and saif_np[1] are not NULL, it will cause leaks. of_node_put() will check if the node pointer is NULL, so we can call it directly to release the refcount of regular pointers. CVE-2022-49242 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: atmel: Add missing of_node_put() in at91sam9g20ek_audio_probe This node pointer is returned by of_parse_phandle() with refcount incremented in this function. Calling of_node_put() to avoid the refcount leak. CVE-2022-49243 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192-mt6359: Fix error handling in mt8192_mt6359_dev_probe The device_node pointer is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. This function only calls of_node_put() in the regular path. And it will cause refcount leak in error paths. Fix this by calling of_node_put() in error handling too. CVE-2022-49244 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: atmel: Fix error handling in snd_proto_probe The device_node pointer is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. This function only calls of_node_put() in the regular path. And it will cause refcount leak in error paths. Fix this by calling of_node_put() in error handling too. CVE-2022-49246 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: stk1160: If start stream fails, return buffers with VB2_BUF_STATE_QUEUED If the callback 'start_streaming' fails, then all queued buffers in the driver should be returned with state 'VB2_BUF_STATE_QUEUED'. Currently, they are returned with 'VB2_BUF_STATE_ERROR' which is wrong. Fix this. This also fixes the warning: [ 65.583633] WARNING: CPU: 5 PID: 593 at drivers/media/common/videobuf2/videobuf2-core.c:1612 vb2_start_streaming+0xd4/0x160 [videobuf2_common] [ 65.585027] Modules linked in: snd_usb_audio snd_hwdep snd_usbmidi_lib snd_rawmidi snd_soc_hdmi_codec dw_hdmi_i2s_audio saa7115 stk1160 videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc crct10dif_ce panfrost snd_soc_simple_card snd_soc_audio_graph_card snd_soc_spdif_tx snd_soc_simple_card_utils gpu_sched phy_rockchip_pcie snd_soc_rockchip_i2s rockchipdrm analogix_dp dw_mipi_dsi dw_hdmi cec drm_kms_helper drm rtc_rk808 rockchip_saradc industrialio_triggered_buffer kfifo_buf rockchip_thermal pcie_rockchip_host ip_tables x_tables ipv6 [ 65.589383] CPU: 5 PID: 593 Comm: v4l2src0:src Tainted: G W 5.16.0-rc4-62408-g32447129cb30-dirty #14 [ 65.590293] Hardware name: Radxa ROCK Pi 4B (DT) [ 65.590696] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 65.591304] pc : vb2_start_streaming+0xd4/0x160 [videobuf2_common] [ 65.591850] lr : vb2_start_streaming+0x6c/0x160 [videobuf2_common] [ 65.592395] sp : ffff800012bc3ad0 [ 65.592685] x29: ffff800012bc3ad0 x28: 0000000000000000 x27: ffff800012bc3cd8 [ 65.593312] x26: 0000000000000000 x25: ffff00000d8a7800 x24: 0000000040045612 [ 65.593938] x23: ffff800011323000 x22: ffff800012bc3cd8 x21: ffff00000908a8b0 [ 65.594562] x20: ffff00000908a8c8 x19: 00000000fffffff4 x18: ffffffffffffffff [ 65.595188] x17: 000000040044ffff x16: 00400034b5503510 x15: ffff800011323f78 [ 65.595813] x14: ffff000013163886 x13: ffff000013163885 x12: 00000000000002ce [ 65.596439] x11: 0000000000000028 x10: 0000000000000001 x9 : 0000000000000228 [ 65.597064] x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff726c5e78 [ 65.597690] x5 : ffff800012bc3990 x4 : 0000000000000000 x3 : ffff000009a34880 [ 65.598315] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000007cd99f0 [ 65.598940] Call trace: [ 65.599155] vb2_start_streaming+0xd4/0x160 [videobuf2_common] [ 65.599672] vb2_core_streamon+0x17c/0x1a8 [videobuf2_common] [ 65.600179] vb2_streamon+0x54/0x88 [videobuf2_v4l2] [ 65.600619] vb2_ioctl_streamon+0x54/0x60 [videobuf2_v4l2] [ 65.601103] v4l_streamon+0x3c/0x50 [videodev] [ 65.601521] __video_do_ioctl+0x1a4/0x428 [videodev] [ 65.601977] video_usercopy+0x320/0x828 [videodev] [ 65.602419] video_ioctl2+0x3c/0x58 [videodev] [ 65.602830] v4l2_ioctl+0x60/0x90 [videodev] [ 65.603227] __arm64_sys_ioctl+0xa8/0xe0 [ 65.603576] invoke_syscall+0x54/0x118 [ 65.603911] el0_svc_common.constprop.3+0x84/0x100 [ 65.604332] do_el0_svc+0x34/0xa0 [ 65.604625] el0_svc+0x1c/0x50 [ 65.604897] el0t_64_sync_handler+0x88/0xb0 [ 65.605264] el0t_64_sync+0x16c/0x170 [ 65.605587] ---[ end trace 578e0ba07742170d ]--- CVE-2022-49247 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-lib: fix uninitialized flag for AV/C deferred transaction AV/C deferred transaction was supported at a commit 00a7bb81c20f ("ALSA: firewire-lib: Add support for deferred transaction") while 'deferrable' flag can be uninitialized for non-control/notify AV/C transactions. UBSAN reports it: kernel: ================================================================================ kernel: UBSAN: invalid-load in /build/linux-aa0B4d/linux-5.15.0/sound/firewire/fcp.c:363:9 kernel: load of value 158 is not a valid value for type '_Bool' kernel: CPU: 3 PID: 182227 Comm: irq/35-firewire Tainted: P OE 5.15.0-18-generic #18-Ubuntu kernel: Hardware name: Gigabyte Technology Co., Ltd. AX370-Gaming 5/AX370-Gaming 5, BIOS F42b 08/01/2019 kernel: Call Trace: kernel: <IRQ> kernel: show_stack+0x52/0x58 kernel: dump_stack_lvl+0x4a/0x5f kernel: dump_stack+0x10/0x12 kernel: ubsan_epilogue+0x9/0x45 kernel: __ubsan_handle_load_invalid_value.cold+0x44/0x49 kernel: fcp_response.part.0.cold+0x1a/0x2b [snd_firewire_lib] kernel: fcp_response+0x28/0x30 [snd_firewire_lib] kernel: fw_core_handle_request+0x230/0x3d0 [firewire_core] kernel: handle_ar_packet+0x1d9/0x200 [firewire_ohci] kernel: ? handle_ar_packet+0x1d9/0x200 [firewire_ohci] kernel: ? transmit_complete_callback+0x9f/0x120 [firewire_core] kernel: ar_context_tasklet+0xa8/0x2e0 [firewire_ohci] kernel: tasklet_action_common.constprop.0+0xea/0xf0 kernel: tasklet_action+0x22/0x30 kernel: __do_softirq+0xd9/0x2e3 kernel: ? irq_finalize_oneshot.part.0+0xf0/0xf0 kernel: do_softirq+0x75/0xa0 kernel: </IRQ> kernel: <TASK> kernel: __local_bh_enable_ip+0x50/0x60 kernel: irq_forced_thread_fn+0x7e/0x90 kernel: irq_thread+0xba/0x190 kernel: ? irq_thread_fn+0x60/0x60 kernel: kthread+0x11e/0x140 kernel: ? irq_thread_check_affinity+0xf0/0xf0 kernel: ? set_kthread_struct+0x50/0x50 kernel: ret_from_fork+0x22/0x30 kernel: </TASK> kernel: ================================================================================ This commit fixes the bug. The bug has no disadvantage for the non- control/notify AV/C transactions since the flag has an effect for AV/C response with INTERIM (0x0f) status which is not used for the transactions in AV/C general specification. CVE-2022-49248 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wc938x: fix accessing array out of bounds for enum type Accessing enums using integer would result in array out of bounds access on platforms like aarch64 where sizeof(long) is 8 compared to enum size which is 4 bytes. Fix this by using enumerated items instead of integers. CVE-2022-49249 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: rx-macro: fix accessing compander for aux AUX interpolator does not have compander, so check before accessing compander data for this. Without this checkan array of out bounds access will be made in comp_enabled[] array. CVE-2022-49250 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: va-macro: fix accessing array out of bounds for enum type Accessing enums using integer would result in array out of bounds access on platforms like aarch64 where sizeof(long) is 8 compared to enum size which is 4 bytes. CVE-2022-49251 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: rx-macro: fix accessing array out of bounds for enum type Accessing enums using integer would result in array out of bounds access on platforms like aarch64 where sizeof(long) is 8 compared to enum size which is 4 bytes. CVE-2022-49252 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: usb: go7007: s2250-board: fix leak in probe() Call i2c_unregister_device(audio) on this error path. CVE-2022-49253 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: ti-vpe: cal: Fix a NULL pointer dereference in cal_ctx_v4l2_init_formats() In cal_ctx_v4l2_init_formats(), devm_kzalloc() is assigned to ctx->active_fmt and there is a dereference of it after that, which could lead to NULL pointer dereference on failure of devm_kzalloc(). Fix this bug by adding a NULL check of ctx->active_fmt. This bug was found by a static analyzer. Builds with 'make allyesconfig' show no new warnings, and our static analyzer no longer warns about this code. CVE-2022-49254 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: crypto: ccree - Fix use after free in cc_cipher_exit() kfree_sensitive(ctx_p->user.key) will free the ctx_p->user.key. But ctx_p->user.key is still used in the next line, which will lead to a use after free. We can call kfree_sensitive() after dev_dbg() to avoid the uaf. CVE-2022-49258 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: block: don't delete queue kobject before its children kobjects aren't supposed to be deleted before their child kobjects are deleted. Apparently this is usually benign; however, a WARN will be triggered if one of the child kobjects has a named attribute group: sysfs group 'modes' not found for kobject 'crypto' WARNING: CPU: 0 PID: 1 at fs/sysfs/group.c:278 sysfs_remove_group+0x72/0x80 ... Call Trace: sysfs_remove_groups+0x29/0x40 fs/sysfs/group.c:312 __kobject_del+0x20/0x80 lib/kobject.c:611 kobject_cleanup+0xa4/0x140 lib/kobject.c:696 kobject_release lib/kobject.c:736 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x53/0x70 lib/kobject.c:753 blk_crypto_sysfs_unregister+0x10/0x20 block/blk-crypto-sysfs.c:159 blk_unregister_queue+0xb0/0x110 block/blk-sysfs.c:962 del_gendisk+0x117/0x250 block/genhd.c:610 Fix this by moving the kobject_del() and the corresponding kobject_uevent() to the correct place. CVE-2022-49259 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/sec - fix the aead software fallback for engine Due to the subreq pointer misuse the private context memory. The aead soft crypto occasionally casues the OS panic as setting the 64K page. Here is fix it. CVE-2022-49260 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: crypto: octeontx2 - remove CONFIG_DM_CRYPT check No issues were found while using the driver with dm-crypt enabled. So CONFIG_DM_CRYPT check in the driver can be removed. This also fixes the NULL pointer dereference in driver release if CONFIG_DM_CRYPT is enabled. ... Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 ... Call trace: crypto_unregister_alg+0x68/0xfc crypto_unregister_skciphers+0x44/0x60 otx2_cpt_crypto_exit+0x100/0x1a0 otx2_cptvf_remove+0xf8/0x200 pci_device_remove+0x3c/0xd4 __device_release_driver+0x188/0x234 device_release_driver+0x2c/0x4c ... CVE-2022-49262 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: brcmfmac: pcie: Release firmwares in the brcmf_pcie_setup error path This avoids leaking memory if brcmf_chip_get_raminfo fails. Note that the CLM blob is released in the device remove path. CVE-2022-49263 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: exec: Force single empty string when argv is empty Quoting[1] Ariadne Conill: "In several other operating systems, it is a hard requirement that the second argument to execve(2) be the name of a program, thus prohibiting a scenario where argc < 1. POSIX 2017 also recommends this behaviour, but it is not an explicit requirement[2]: The argument arg0 should point to a filename string that is associated with the process being started by one of the exec functions. ... Interestingly, Michael Kerrisk opened an issue about this in 2008[3], but there was no consensus to support fixing this issue then. Hopefully now that CVE-2021-4034 shows practical exploitative use[4] of this bug in a shellcode, we can reconsider. This issue is being tracked in the KSPP issue tracker[5]." While the initial code searches[6][7] turned up what appeared to be mostly corner case tests, trying to that just reject argv == NULL (or an immediately terminated pointer list) quickly started tripping[8] existing userspace programs. The next best approach is forcing a single empty string into argv and adjusting argc to match. The number of programs depending on argc == 0 seems a smaller set than those calling execve with a NULL argv. Account for the additional stack space in bprm_stack_limits(). Inject an empty string when argc == 0 (and set argc = 1). Warn about the case so userspace has some notice about the change: process './argc0' launched './argc0' with NULL argv: empty string added Additionally WARN() and reject NULL argv usage for kernel threads. [1] https://lore.kernel.org/lkml/20220127000724.15106-1-ariadne@dereferenced.org/ [2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html [3] https://bugzilla.kernel.org/show_bug.cgi?id=8408 [4] https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt [5] https://github.com/KSPP/linux/issues/176 [6] https://codesearch.debian.net/search?q=execve%5C+*%5C%28%5B%5E%2C%5D%2B%2C+*NULL&literal=0 [7] https://codesearch.debian.net/search?q=execlp%3F%5Cs*%5C%28%5B%5E%2C%5D%2B%2C%5Cs*NULL&literal=0 [8] https://lore.kernel.org/lkml/20220131144352.GE16385@xsang-OptiPlex-9020/ CVE-2022-49264 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: PM: domains: Fix sleep-in-atomic bug caused by genpd_debug_remove() When a genpd with GENPD_FLAG_IRQ_SAFE gets removed, the following sleep-in-atomic bug will be seen, as genpd_debug_remove() will be called with a spinlock being held. [ 0.029183] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1460 [ 0.029204] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 1, name: swapper/0 [ 0.029219] preempt_count: 1, expected: 0 [ 0.029230] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.17.0-rc4+ #489 [ 0.029245] Hardware name: Thundercomm TurboX CM2290 (DT) [ 0.029256] Call trace: [ 0.029265] dump_backtrace.part.0+0xbc/0xd0 [ 0.029285] show_stack+0x3c/0xa0 [ 0.029298] dump_stack_lvl+0x7c/0xa0 [ 0.029311] dump_stack+0x18/0x34 [ 0.029323] __might_resched+0x10c/0x13c [ 0.029338] __might_sleep+0x4c/0x80 [ 0.029351] down_read+0x24/0xd0 [ 0.029363] lookup_one_len_unlocked+0x9c/0xcc [ 0.029379] lookup_positive_unlocked+0x10/0x50 [ 0.029392] debugfs_lookup+0x68/0xac [ 0.029406] genpd_remove.part.0+0x12c/0x1b4 [ 0.029419] of_genpd_remove_last+0xa8/0xd4 [ 0.029434] psci_cpuidle_domain_probe+0x174/0x53c [ 0.029449] platform_probe+0x68/0xe0 [ 0.029462] really_probe+0x190/0x430 [ 0.029473] __driver_probe_device+0x90/0x18c [ 0.029485] driver_probe_device+0x40/0xe0 [ 0.029497] __driver_attach+0xf4/0x1d0 [ 0.029508] bus_for_each_dev+0x70/0xd0 [ 0.029523] driver_attach+0x24/0x30 [ 0.029534] bus_add_driver+0x164/0x22c [ 0.029545] driver_register+0x78/0x130 [ 0.029556] __platform_driver_register+0x28/0x34 [ 0.029569] psci_idle_init_domains+0x1c/0x28 [ 0.029583] do_one_initcall+0x50/0x1b0 [ 0.029595] kernel_init_freeable+0x214/0x280 [ 0.029609] kernel_init+0x2c/0x13c [ 0.029622] ret_from_fork+0x10/0x20 It doesn't seem necessary to call genpd_debug_remove() with the lock, so move it out from locking to fix the problem. CVE-2022-49265 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: block: fix rq-qos breakage from skipping rq_qos_done_bio() a647a524a467 ("block: don't call rq_qos_ops->done_bio if the bio isn't tracked") made bio_endio() skip rq_qos_done_bio() if BIO_TRACKED is not set. While this fixed a potential oops, it also broke blk-iocost by skipping the done_bio callback for merged bios. Before, whether a bio goes through rq_qos_throttle() or rq_qos_merge(), rq_qos_done_bio() would be called on the bio on completion with BIO_TRACKED distinguishing the former from the latter. rq_qos_done_bio() is not called for bios which wenth through rq_qos_merge(). This royally confuses blk-iocost as the merged bios never finish and are considered perpetually in-flight. One reliably reproducible failure mode is an intermediate cgroup geting stuck active preventing its children from being activated due to the leaf-only rule, leading to loss of control. The following is from resctl-bench protection scenario which emulates isolating a web server like workload from a memory bomb run on an iocost configuration which should yield a reasonable level of protection. # cat /sys/block/nvme2n1/device/model Samsung SSD 970 PRO 512GB # cat /sys/fs/cgroup/io.cost.model 259:0 ctrl=user model=linear rbps=834913556 rseqiops=93622 rrandiops=102913 wbps=618985353 wseqiops=72325 wrandiops=71025 # cat /sys/fs/cgroup/io.cost.qos 259:0 enable=1 ctrl=user rpct=95.00 rlat=18776 wpct=95.00 wlat=8897 min=60.00 max=100.00 # resctl-bench -m 29.6G -r out.json run protection::scenario=mem-hog,loops=1 ... Memory Hog Summary ================== IO Latency: R p50=242u:336u/2.5m p90=794u:1.4m/7.5m p99=2.7m:8.0m/62.5m max=8.0m:36.4m/350m W p50=221u:323u/1.5m p90=709u:1.2m/5.5m p99=1.5m:2.5m/9.5m max=6.9m:35.9m/350m Isolation and Request Latency Impact Distributions: min p01 p05 p10 p25 p50 p75 p90 p95 p99 max mean stdev isol% 15.90 15.90 15.90 40.05 57.24 59.07 60.01 74.63 74.63 90.35 90.35 58.12 15.82 lat-imp% 0 0 0 0 0 4.55 14.68 15.54 233.5 548.1 548.1 53.88 143.6 Result: isol=58.12:15.82% lat_imp=53.88%:143.6 work_csv=100.0% missing=3.96% The isolation result of 58.12% is close to what this device would show without any IO control. Fix it by introducing a new flag BIO_QOS_MERGED to mark merged bios and calling rq_qos_done_bio() on them too. For consistency and clarity, rename BIO_TRACKED to BIO_QOS_THROTTLED. The flag checks are moved into rq_qos_done_bio() so that it's next to the code paths that set the flags. With the patch applied, the above same benchmark shows: # resctl-bench -m 29.6G -r out.json run protection::scenario=mem-hog,loops=1 ... Memory Hog Summary ================== IO Latency: R p50=123u:84.4u/985u p90=322u:256u/2.5m p99=1.6m:1.4m/9.5m max=11.1m:36.0m/350m W p50=429u:274u/995u p90=1.7m:1.3m/4.5m p99=3.4m:2.7m/11.5m max=7.9m:5.9m/26.5m Isolation and Request Latency Impact Distributions: min p01 p05 p10 p25 p50 p75 p90 p95 p99 max mean stdev isol% 84.91 84.91 89.51 90.73 92.31 94.49 96.36 98.04 98.71 100.0 100.0 94.42 2.81 lat-imp% 0 0 0 0 0 2.81 5.73 11.11 13.92 17.53 22.61 4.10 4.68 Result: isol=94.42:2.81% lat_imp=4.10%:4.68 work_csv=58.34% missing=0% CVE-2022-49266 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: Intel: Fix NULL ptr dereference when ENOMEM Do not call snd_dma_free_pages() when snd_dma_alloc_pages() returns -ENOMEM because it leads to a NULL pointer dereference bug. The dmesg says: [ T1387] sof-audio-pci-intel-tgl 0000:00:1f.3: error: memory alloc failed: -12 [ T1387] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ T1387] #PF: supervisor read access in kernel mode [ T1387] #PF: error_code(0x0000) - not-present page [ T1387] PGD 0 P4D 0 [ T1387] Oops: 0000 [#1] PREEMPT SMP NOPTI [ T1387] CPU: 6 PID: 1387 Comm: alsa-sink-HDA A Tainted: G W 5.17.0-rc4-superb-owl-00055-g80d47f5de5e3 [ T1387] Hardware name: HP HP Laptop 14s-dq2xxx/87FD, BIOS F.15 09/15/2021 [ T1387] RIP: 0010:dma_free_noncontiguous+0x37/0x80 [ T1387] Code: [... snip ...] [ T1387] RSP: 0000:ffffc90002b87770 EFLAGS: 00010246 [ T1387] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ T1387] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888101db30d0 [ T1387] RBP: 00000000fffffff4 R08: 0000000000000000 R09: 0000000000000000 [ T1387] R10: 0000000000000000 R11: ffffc90002b874d0 R12: 0000000000000001 [ T1387] R13: 0000000000058000 R14: ffff888105260c68 R15: ffff888105260828 [ T1387] FS: 00007f42e2ffd640(0000) GS:ffff888466b80000(0000) knlGS:0000000000000000 [ T1387] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ T1387] CR2: 0000000000000000 CR3: 000000014acf0003 CR4: 0000000000770ee0 [ T1387] PKRU: 55555554 [ T1387] Call Trace: [ T1387] <TASK> [ T1387] cl_stream_prepare+0x10a/0x120 [snd_sof_intel_hda_common 146addf995b9279ae7f509621078cccbe4f875e1] [... snip ...] [ T1387] </TASK> CVE-2022-49268 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: can: isotp: sanitize CAN ID checks in isotp_bind() Syzbot created an environment that lead to a state machine status that can not be reached with a compliant CAN ID address configuration. The provided address information consisted of CAN ID 0x6000001 and 0xC28001 which both boil down to 11 bit CAN IDs 0x001 in sending and receiving. Sanitize the SFF/EFF CAN ID values before performing the address checks. CVE-2022-49269 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: dm: fix use-after-free in dm_cleanup_zoned_dev() dm_cleanup_zoned_dev() uses queue, so it must be called before blk_cleanup_disk() starts its killing: blk_cleanup_disk->blk_cleanup_queue()->kobject_put()->blk_release_queue()-> ->...RCU...->blk_free_queue_rcu()->kmem_cache_free() Otherwise, RCU callback may be executed first and dm_cleanup_zoned_dev() will touch free'd memory: BUG: KASAN: use-after-free in dm_cleanup_zoned_dev+0x33/0xd0 Read of size 8 at addr ffff88805ac6e430 by task dmsetup/681 CPU: 4 PID: 681 Comm: dmsetup Not tainted 5.17.0-rc2+ #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x57/0x7d print_address_description.constprop.0+0x1f/0x150 ? dm_cleanup_zoned_dev+0x33/0xd0 kasan_report.cold+0x7f/0x11b ? dm_cleanup_zoned_dev+0x33/0xd0 dm_cleanup_zoned_dev+0x33/0xd0 __dm_destroy+0x26a/0x400 ? dm_blk_ioctl+0x230/0x230 ? up_write+0xd8/0x270 dev_remove+0x156/0x1d0 ctl_ioctl+0x269/0x530 ? table_clear+0x140/0x140 ? lock_release+0xb2/0x750 ? remove_all+0x40/0x40 ? rcu_read_lock_sched_held+0x12/0x70 ? lock_downgrade+0x3c0/0x3c0 ? rcu_read_lock_sched_held+0x12/0x70 dm_ctl_ioctl+0xa/0x10 __x64_sys_ioctl+0xb9/0xf0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fb6dfa95c27 CVE-2022-49270 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: rtc: pl031: fix rtc features null pointer dereference When there is no interrupt line, rtc alarm feature is disabled. The clearing of the alarm feature bit was being done prior to allocations of ldata->rtc device, resulting in a null pointer dereference. Clear RTC_FEATURE_ALARM after the rtc device is allocated. CVE-2022-49273 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix crash when mount with quota enabled There is a reported crash when mounting ocfs2 with quota enabled. RIP: 0010:ocfs2_qinfo_lock_res_init+0x44/0x50 [ocfs2] Call Trace: ocfs2_local_read_info+0xb9/0x6f0 [ocfs2] dquot_load_quota_sb+0x216/0x470 dquot_load_quota_inode+0x85/0x100 ocfs2_enable_quotas+0xa0/0x1c0 [ocfs2] ocfs2_fill_super.cold+0xc8/0x1bf [ocfs2] mount_bdev+0x185/0x1b0 legacy_get_tree+0x27/0x40 vfs_get_tree+0x25/0xb0 path_mount+0x465/0xac0 __x64_sys_mount+0x103/0x140 It is caused by when initializing dqi_gqlock, the corresponding dqi_type and dqi_sb are not properly initialized. This issue is introduced by commit 6c85c2c72819, which wants to avoid accessing uninitialized variables in error cases. So make global quota info properly initialized. CVE-2022-49274 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: can: m_can: m_can_tx_handler(): fix use after free of skb can_put_echo_skb() will clone skb then free the skb. Move the can_put_echo_skb() for the m_can version 3.0.x directly before the start of the xmit in hardware, similar to the 3.1.x branch. CVE-2022-49275 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: jffs2: fix memory leak in jffs2_scan_medium If an error is returned in jffs2_scan_eraseblock() and some memory has been added to the jffs2_summary *s, we can observe the following kmemleak report: -------------------------------------------- unreferenced object 0xffff88812b889c40 (size 64): comm "mount", pid 692, jiffies 4294838325 (age 34.288s) hex dump (first 32 bytes): 40 48 b5 14 81 88 ff ff 01 e0 31 00 00 00 50 00 @H........1...P. 00 00 01 00 00 00 01 00 00 00 02 00 00 00 09 08 ................ backtrace: [<ffffffffae93a3a3>] __kmalloc+0x613/0x910 [<ffffffffaf423b9c>] jffs2_sum_add_dirent_mem+0x5c/0xa0 [<ffffffffb0f3afa8>] jffs2_scan_medium.cold+0x36e5/0x4794 [<ffffffffb0f3dbe1>] jffs2_do_mount_fs.cold+0xa7/0x2267 [<ffffffffaf40acf3>] jffs2_do_fill_super+0x383/0xc30 [<ffffffffaf40c00a>] jffs2_fill_super+0x2ea/0x4c0 [<ffffffffb0315d64>] mtd_get_sb+0x254/0x400 [<ffffffffb0315f5f>] mtd_get_sb_by_nr+0x4f/0xd0 [<ffffffffb0316478>] get_tree_mtd+0x498/0x840 [<ffffffffaf40bd15>] jffs2_get_tree+0x25/0x30 [<ffffffffae9f358d>] vfs_get_tree+0x8d/0x2e0 [<ffffffffaea7a98f>] path_mount+0x50f/0x1e50 [<ffffffffaea7c3d7>] do_mount+0x107/0x130 [<ffffffffaea7c5c5>] __se_sys_mount+0x1c5/0x2f0 [<ffffffffaea7c917>] __x64_sys_mount+0xc7/0x160 [<ffffffffb10142f5>] do_syscall_64+0x45/0x70 unreferenced object 0xffff888114b54840 (size 32): comm "mount", pid 692, jiffies 4294838325 (age 34.288s) hex dump (first 32 bytes): c0 75 b5 14 81 88 ff ff 02 e0 02 00 00 00 02 00 .u.............. 00 00 84 00 00 00 44 00 00 00 6b 6b 6b 6b 6b a5 ......D...kkkkk. backtrace: [<ffffffffae93be24>] kmem_cache_alloc_trace+0x584/0x880 [<ffffffffaf423b04>] jffs2_sum_add_inode_mem+0x54/0x90 [<ffffffffb0f3bd44>] jffs2_scan_medium.cold+0x4481/0x4794 [...] unreferenced object 0xffff888114b57280 (size 32): comm "mount", pid 692, jiffies 4294838393 (age 34.357s) hex dump (first 32 bytes): 10 d5 6c 11 81 88 ff ff 08 e0 05 00 00 00 01 00 ..l............. 00 00 38 02 00 00 28 00 00 00 6b 6b 6b 6b 6b a5 ..8...(...kkkkk. backtrace: [<ffffffffae93be24>] kmem_cache_alloc_trace+0x584/0x880 [<ffffffffaf423c34>] jffs2_sum_add_xattr_mem+0x54/0x90 [<ffffffffb0f3a24f>] jffs2_scan_medium.cold+0x298c/0x4794 [...] unreferenced object 0xffff8881116cd510 (size 16): comm "mount", pid 692, jiffies 4294838395 (age 34.355s) hex dump (first 16 bytes): 00 00 00 00 00 00 00 00 09 e0 60 02 00 00 6b a5 ..........`...k. backtrace: [<ffffffffae93be24>] kmem_cache_alloc_trace+0x584/0x880 [<ffffffffaf423cc4>] jffs2_sum_add_xref_mem+0x54/0x90 [<ffffffffb0f3b2e3>] jffs2_scan_medium.cold+0x3a20/0x4794 [...] -------------------------------------------- Therefore, we should call jffs2_sum_reset_collected(s) on exit to release the memory added in s. In addition, a new tag "out_buf" is added to prevent the NULL pointer reference caused by s being NULL. (thanks to Zhang Yi for this analysis) CVE-2022-49276 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: jffs2: fix memory leak in jffs2_do_mount_fs If jffs2_build_filesystem() in jffs2_do_mount_fs() returns an error, we can observe the following kmemleak report: -------------------------------------------- unreferenced object 0xffff88811b25a640 (size 64): comm "mount", pid 691, jiffies 4294957728 (age 71.952s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffffa493be24>] kmem_cache_alloc_trace+0x584/0x880 [<ffffffffa5423a06>] jffs2_sum_init+0x86/0x130 [<ffffffffa5400e58>] jffs2_do_mount_fs+0x798/0xac0 [<ffffffffa540acf3>] jffs2_do_fill_super+0x383/0xc30 [<ffffffffa540c00a>] jffs2_fill_super+0x2ea/0x4c0 [...] unreferenced object 0xffff88812c760000 (size 65536): comm "mount", pid 691, jiffies 4294957728 (age 71.952s) hex dump (first 32 bytes): bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ backtrace: [<ffffffffa493a449>] __kmalloc+0x6b9/0x910 [<ffffffffa5423a57>] jffs2_sum_init+0xd7/0x130 [<ffffffffa5400e58>] jffs2_do_mount_fs+0x798/0xac0 [<ffffffffa540acf3>] jffs2_do_fill_super+0x383/0xc30 [<ffffffffa540c00a>] jffs2_fill_super+0x2ea/0x4c0 [...] -------------------------------------------- This is because the resources allocated in jffs2_sum_init() are not released. Call jffs2_sum_exit() to release these resources to solve the problem. CVE-2022-49277 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: remoteproc: Fix count check in rproc_coredump_write() Check count for 0, to avoid a potential underflow. Make the check the same as the one in rproc_recovery_write(). CVE-2022-49278 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: NFSD: prevent integer overflow on 32 bit systems On a 32 bit system, the "len * sizeof(*p)" operation can have an integer overflow. CVE-2022-49279 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: NFSD: prevent underflow in nfssvc_decode_writeargs() Smatch complains: fs/nfsd/nfsxdr.c:341 nfssvc_decode_writeargs() warn: no lower bound on 'args->len' Change the type to unsigned to prevent this issue. CVE-2022-49280 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: cifs: fix handlecache and multiuser In multiuser each individual user has their own tcon structure for the share and thus their own handle for a cached directory. When we umount such a share we much make sure to release the pinned down dentry for each such tcon and not just the master tcon. Otherwise we will get nasty warnings on umount that dentries are still in use: [ 3459.590047] BUG: Dentry 00000000115c6f41{i=12000000019d95,n=/} still in use\ (2) [unmount of cifs cifs] ... [ 3459.590492] Call Trace: [ 3459.590500] d_walk+0x61/0x2a0 [ 3459.590518] ? shrink_lock_dentry.part.0+0xe0/0xe0 [ 3459.590526] shrink_dcache_for_umount+0x49/0x110 [ 3459.590535] generic_shutdown_super+0x1a/0x110 [ 3459.590542] kill_anon_super+0x14/0x30 [ 3459.590549] cifs_kill_sb+0xf5/0x104 [cifs] [ 3459.590773] deactivate_locked_super+0x36/0xa0 [ 3459.590782] cleanup_mnt+0x131/0x190 [ 3459.590789] task_work_run+0x5c/0x90 [ 3459.590798] exit_to_user_mode_loop+0x151/0x160 [ 3459.590809] exit_to_user_mode_prepare+0x83/0xd0 [ 3459.590818] syscall_exit_to_user_mode+0x12/0x30 [ 3459.590828] do_syscall_64+0x48/0x90 [ 3459.590833] entry_SYSCALL_64_after_hwframe+0x44/0xae CVE-2022-49281 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: firmware: sysfb: fix platform-device leak in error path Make sure to free the platform device also in the unlikely event that registration fails. CVE-2022-49283 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: iio: accel: mma8452: use the correct logic to get mma8452_data The original logic to get mma8452_data is wrong, the *dev point to the device belong to iio_dev. we can't use this dev to find the correct i2c_client. The original logic happen to work because it finally use dev->driver_data to get iio_dev. Here use the API to_i2c_client() is wrong and make reader confuse. To correct the logic, it should be like this struct mma8452_data *data = iio_priv(dev_get_drvdata(dev)); But after commit 8b7651f25962 ("iio: iio_device_alloc(): Remove unnecessary self drvdata"), the upper logic also can't work. When try to show the avialable scale in userspace, will meet kernel dump, kernel handle NULL pointer dereference. So use dev_to_iio_dev() to correct the logic. Dual fixes tags as the second reflects when the bug was exposed, whilst the first reflects when the original bug was introduced. CVE-2022-49285 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: tpm: use try_get_ops() in tpm-space.c As part of the series conversion to remove nested TPM operations: https://lore.kernel.org/all/20190205224723.19671-1-jarkko.sakkinen@linux.intel.com/ exposure of the chip->tpm_mutex was removed from much of the upper level code. In this conversion, tpm2_del_space() was missed. This didn't matter much because it's usually called closely after a converted operation, so there's only a very tiny race window where the chip can be removed before the space flushing is done which causes a NULL deref on the mutex. However, there are reports of this window being hit in practice, so fix this by converting tpm2_del_space() to use tpm_try_get_ops(), which performs all the teardown checks before acquring the mutex. CVE-2022-49286 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: mac80211: fix potential double free on mesh join While commit 6a01afcf8468 ("mac80211: mesh: Free ie data when leaving mesh") fixed a memory leak on mesh leave / teardown it introduced a potential memory corruption caused by a double free when rejoining the mesh: ieee80211_leave_mesh() -> kfree(sdata->u.mesh.ie); ... ieee80211_join_mesh() -> copy_mesh_setup() -> old_ie = ifmsh->ie; -> kfree(old_ie); This double free / kernel panics can be reproduced by using wpa_supplicant with an encrypted mesh (if set up without encryption via "iw" then ifmsh->ie is always NULL, which avoids this issue). And then calling: $ iw dev mesh0 mesh leave $ iw dev mesh0 mesh join my-mesh Note that typically these commands are not used / working when using wpa_supplicant. And it seems that wpa_supplicant or wpa_cli are going through a NETDEV_DOWN/NETDEV_UP cycle between a mesh leave and mesh join where the NETDEV_UP resets the mesh.ie to NULL via a memcpy of default_mesh_setup in cfg80211_netdev_notifier_call, which then avoids the memory corruption, too. The issue was first observed in an application which was not using wpa_supplicant but "Senf" instead, which implements its own calls to nl80211. Fixing the issue by removing the kfree()'ing of the mesh IE in the mesh join function and leaving it solely up to the mesh leave to free the mesh IE. CVE-2022-49290 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ALSA: oss: Fix PCM OSS buffer allocation overflow We've got syzbot reports hitting INT_MAX overflow at vmalloc() allocation that is called from snd_pcm_plug_alloc(). Although we apply the restrictions to input parameters, it's based only on the hw_params of the underlying PCM device. Since the PCM OSS layer allocates a temporary buffer for the data conversion, the size may become unexpectedly large when more channels or higher rates is given; in the reported case, it went over INT_MAX, hence it hits WARN_ON(). This patch is an attempt to avoid such an overflow and an allocation for too large buffers. First off, it adds the limit of 1MB as the upper bound for period bytes. This must be large enough for all use cases, and we really don't want to handle a larger temporary buffer than this size. The size check is performed at two places, where the original period bytes is calculated and where the plugin buffer size is calculated. In addition, the driver uses array_size() and array3_size() for multiplications to catch overflows for the converted period size and buffer bytes. CVE-2022-49292 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check if modulo is 0 before dividing. [How & Why] If a value of 0 is read, then this will cause a divide-by-0 panic. CVE-2022-49294 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: nbd: call genl_unregister_family() first in nbd_cleanup() Otherwise there may be race between module removal and the handling of netlink command, which can lead to the oops as shown below: BUG: kernel NULL pointer dereference, address: 0000000000000098 Oops: 0002 [#1] SMP PTI CPU: 1 PID: 31299 Comm: nbd-client Tainted: G E 5.14.0-rc4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:down_write+0x1a/0x50 Call Trace: start_creating+0x89/0x130 debugfs_create_dir+0x1b/0x130 nbd_start_device+0x13d/0x390 [nbd] nbd_genl_connect+0x42f/0x748 [nbd] genl_family_rcv_msg_doit.isra.0+0xec/0x150 genl_rcv_msg+0xe5/0x1e0 netlink_rcv_skb+0x55/0x100 genl_rcv+0x29/0x40 netlink_unicast+0x1a8/0x250 netlink_sendmsg+0x21b/0x430 ____sys_sendmsg+0x2a4/0x2d0 ___sys_sendmsg+0x81/0xc0 __sys_sendmsg+0x62/0xb0 __x64_sys_sendmsg+0x1f/0x30 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Modules linked in: nbd(E-) CVE-2022-49295 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: nbd: fix io hung while disconnecting device In our tests, "qemu-nbd" triggers a io hung: INFO: task qemu-nbd:11445 blocked for more than 368 seconds. Not tainted 5.18.0-rc3-next-20220422-00003-g2176915513ca #884 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:qemu-nbd state:D stack: 0 pid:11445 ppid: 1 flags:0x00000000 Call Trace: <TASK> __schedule+0x480/0x1050 ? _raw_spin_lock_irqsave+0x3e/0xb0 schedule+0x9c/0x1b0 blk_mq_freeze_queue_wait+0x9d/0xf0 ? ipi_rseq+0x70/0x70 blk_mq_freeze_queue+0x2b/0x40 nbd_add_socket+0x6b/0x270 [nbd] nbd_ioctl+0x383/0x510 [nbd] blkdev_ioctl+0x18e/0x3e0 __x64_sys_ioctl+0xac/0x120 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fd8ff706577 RSP: 002b:00007fd8fcdfebf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000040000000 RCX: 00007fd8ff706577 RDX: 000000000000000d RSI: 000000000000ab00 RDI: 000000000000000f RBP: 000000000000000f R08: 000000000000fbe8 R09: 000055fe497c62b0 R10: 00000002aff20000 R11: 0000000000000246 R12: 000000000000006d R13: 0000000000000000 R14: 00007ffe82dc5e70 R15: 00007fd8fcdff9c0 "qemu-ndb -d" will call ioctl 'NBD_DISCONNECT' first, however, following message was found: block nbd0: Send disconnect failed -32 Which indicate that something is wrong with the server. Then, "qemu-nbd -d" will call ioctl 'NBD_CLEAR_SOCK', however ioctl can't clear requests after commit 2516ab1543fd("nbd: only clear the queue on device teardown"). And in the meantime, request can't complete through timeout because nbd_xmit_timeout() will always return 'BLK_EH_RESET_TIMER', which means such request will never be completed in this situation. Now that the flag 'NBD_CMD_INFLIGHT' can make sure requests won't complete multiple times, switch back to call nbd_clear_sock() in nbd_clear_sock_ioctl(), so that inflight requests can be cleared. CVE-2022-49297 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: staging: rtl8712: fix uninit-value in r871xu_drv_init() When 'tmpU1b' returns from r8712_read8(padapter, EE_9346CR) is 0, 'mac[6]' will not be initialized. BUG: KMSAN: uninit-value in r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541 r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396 really_probe+0x653/0x14b0 drivers/base/dd.c:596 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [inline] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238 usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293 really_probe+0x653/0x14b0 drivers/base/dd.c:596 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [inline] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_new_device+0x1b8e/0x2950 drivers/usb/core/hub.c:2566 hub_port_connect drivers/usb/core/hub.c:5358 [inline] hub_port_connect_change drivers/usb/core/hub.c:5502 [inline] port_event drivers/usb/core/hub.c:5660 [inline] hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5742 process_one_work+0xdb6/0x1820 kernel/workqueue.c:2307 worker_thread+0x10b3/0x21e0 kernel/workqueue.c:2454 kthread+0x3c7/0x500 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 Local variable mac created at: r871xu_drv_init+0x1771/0x3070 drivers/staging/rtl8712/usb_intf.c:394 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396 KMSAN: uninit-value in r871xu_drv_init https://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8 CVE-2022-49298 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. CVE-2022-49299 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between nbd_alloc_config() and module removal When nbd module is being removing, nbd_alloc_config() may be called concurrently by nbd_genl_connect(), although try_module_get() will return false, but nbd_alloc_config() doesn't handle it. The race may lead to the leak of nbd_config and its related resources (e.g, recv_workq) and oops in nbd_read_stat() due to the unload of nbd module as shown below: BUG: kernel NULL pointer dereference, address: 0000000000000040 Oops: 0000 [#1] SMP PTI CPU: 5 PID: 13840 Comm: kworker/u17:33 Not tainted 5.14.0+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: knbd16-recv recv_work [nbd] RIP: 0010:nbd_read_stat.cold+0x130/0x1a4 [nbd] Call Trace: recv_work+0x3b/0xb0 [nbd] process_one_work+0x1ed/0x390 worker_thread+0x4a/0x3d0 kthread+0x12a/0x150 ret_from_fork+0x22/0x30 Fixing it by checking the return value of try_module_get() in nbd_alloc_config(). As nbd_alloc_config() may return ERR_PTR(-ENODEV), assign nbd->config only when nbd_alloc_config() succeeds to ensure the value of nbd->config is binary (valid or NULL). Also adding a debug message to check the reference counter of nbd_config during module removal. CVE-2022-49300 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: staging: rtl8712: fix uninit-value in usb_read8() and friends When r8712_usbctrl_vendorreq() returns negative, 'data' in usb_read{8,16,32} will not be initialized. BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:643 [inline] BUG: KMSAN: uninit-value in string+0x4ec/0x6f0 lib/vsprintf.c:725 string_nocheck lib/vsprintf.c:643 [inline] string+0x4ec/0x6f0 lib/vsprintf.c:725 vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806 va_format lib/vsprintf.c:1704 [inline] pointer+0x18e6/0x1f70 lib/vsprintf.c:2443 vsnprintf+0x1a9b/0x3650 lib/vsprintf.c:2810 vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158 vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256 dev_vprintk_emit+0x5ef/0x6d0 drivers/base/core.c:4604 dev_printk_emit+0x1dd/0x21f drivers/base/core.c:4615 __dev_printk+0x3be/0x440 drivers/base/core.c:4627 _dev_info+0x1ea/0x22f drivers/base/core.c:4673 r871xu_drv_init+0x1929/0x3070 drivers/staging/rtl8712/usb_intf.c:401 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396 really_probe+0x6c7/0x1350 drivers/base/dd.c:621 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [inline] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238 usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293 really_probe+0x6c7/0x1350 drivers/base/dd.c:621 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [inline] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_new_device+0x1b91/0x2950 drivers/usb/core/hub.c:2566 hub_port_connect drivers/usb/core/hub.c:5363 [inline] hub_port_connect_change drivers/usb/core/hub.c:5507 [inline] port_event drivers/usb/core/hub.c:5665 [inline] hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5747 process_one_work+0xdb6/0x1820 kernel/workqueue.c:2289 worker_thread+0x10d0/0x2240 kernel/workqueue.c:2436 kthread+0x3c7/0x500 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 Local variable data created at: usb_read8+0x5d/0x130 drivers/staging/rtl8712/usb_ops.c:33 r8712_read8+0xa5/0xd0 drivers/staging/rtl8712/rtl8712_io.c:29 KMSAN: uninit-value in r871xu_drv_init https://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8 CVE-2022-49301 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: USB: host: isp116x: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. CVE-2022-49302 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drivers: tty: serial: Fix deadlock in sa1100_set_termios() There is a deadlock in sa1100_set_termios(), which is shown below: (Thread 1) | (Thread 2) | sa1100_enable_ms() sa1100_set_termios() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | sa1100_timeout() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold sport->port.lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need sport->port.lock in position (2) of thread 2. As a result, sa1100_set_termios() will block forever. This patch moves del_timer_sync() before spin_lock_irqsave() in order to prevent the deadlock. CVE-2022-49304 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drivers: staging: rtl8192u: Fix deadlock in ieee80211_beacons_stop() There is a deadlock in ieee80211_beacons_stop(), which is shown below: (Thread 1) | (Thread 2) | ieee80211_send_beacon() ieee80211_beacons_stop() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | ieee80211_send_beacon_cb() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold ieee->beacon_lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need ieee->beacon_lock in position (2) of thread 2. As a result, ieee80211_beacons_stop() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irqsave(), which could let timer handler to obtain the needed lock. CVE-2022-49305 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: tty: synclink_gt: Fix null-pointer-dereference in slgt_clean() When the driver fails at alloc_hdlcdev(), and then we remove the driver module, we will get the following splat: [ 25.065966] general protection fault, probably for non-canonical address 0xdffffc0000000182: 0000 [#1] PREEMPT SMP KASAN PTI [ 25.066914] KASAN: null-ptr-deref in range [0x0000000000000c10-0x0000000000000c17] [ 25.069262] RIP: 0010:detach_hdlc_protocol+0x2a/0x3e0 [ 25.077709] Call Trace: [ 25.077924] <TASK> [ 25.078108] unregister_hdlc_device+0x16/0x30 [ 25.078481] slgt_cleanup+0x157/0x9f0 [synclink_gt] Fix this by checking whether the 'info->netdev' is a null pointer first. CVE-2022-49307 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: extcon: Modify extcon device to be created after driver data is set Currently, someone can invoke the sysfs such as state_show() intermittently before dev_set_drvdata() is done. And it can be a cause of kernel Oops because of edev is Null at that time. So modified the driver registration to after setting drviver data. - Oops's backtrace. Backtrace: [<c067865c>] (state_show) from [<c05222e8>] (dev_attr_show) [<c05222c0>] (dev_attr_show) from [<c02c66e0>] (sysfs_kf_seq_show) [<c02c6648>] (sysfs_kf_seq_show) from [<c02c496c>] (kernfs_seq_show) [<c02c4938>] (kernfs_seq_show) from [<c025e2a0>] (seq_read) [<c025e11c>] (seq_read) from [<c02c50a0>] (kernfs_fop_read) [<c02c5064>] (kernfs_fop_read) from [<c0231cac>] (__vfs_read) [<c0231c5c>] (__vfs_read) from [<c0231ee0>] (vfs_read) [<c0231e34>] (vfs_read) from [<c0232464>] (ksys_read) [<c02323f0>] (ksys_read) from [<c02324fc>] (sys_read) [<c02324e4>] (sys_read) from [<c00091d0>] (__sys_trace_return) CVE-2022-49308 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drivers: staging: rtl8723bs: Fix deadlock in rtw_surveydone_event_callback() There is a deadlock in rtw_surveydone_event_callback(), which is shown below: (Thread 1) | (Thread 2) | _set_timer() rtw_surveydone_event_callback()| mod_timer() spin_lock_bh() //(1) | (wait a time) ... | rtw_scan_timeout_handler() del_timer_sync() | spin_lock_bh() //(2) (wait timer to stop) | ... We hold pmlmepriv->lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need pmlmepriv->lock in position (2) of thread 2. As a result, rtw_surveydone_event_callback() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_bh(), which could let timer handler to obtain the needed lock. What`s more, we change spin_lock_bh() in rtw_scan_timeout_handler() to spin_lock_irq(). Otherwise, spin_lock_bh() will also cause deadlock() in timer handler. CVE-2022-49309 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: char: xillybus: fix a refcount leak in cleanup_dev() usb_get_dev is called in xillyusb_probe. So it is better to call usb_put_dev before xdev is released. CVE-2022-49310 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drivers: staging: rtl8192bs: Fix deadlock in rtw_joinbss_event_prehandle() There is a deadlock in rtw_joinbss_event_prehandle(), which is shown below: (Thread 1) | (Thread 2) | _set_timer() rtw_joinbss_event_prehandle()| mod_timer() spin_lock_bh() //(1) | (wait a time) ... | _rtw_join_timeout_handler() del_timer_sync() | spin_lock_bh() //(2) (wait timer to stop) | ... We hold pmlmepriv->lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need pmlmepriv->lock in position (2) of thread 2. As a result, rtw_joinbss_event_prehandle() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_bh(), which could let timer handler to obtain the needed lock. What`s more, we change spin_lock_bh() to spin_lock_irq() in _rtw_join_timeout_handler() in order to prevent deadlock. CVE-2022-49311 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: staging: rtl8712: fix a potential memory leak in r871xu_drv_init() In r871xu_drv_init(), if r8712_init_drv_sw() fails, then the memory allocated by r8712_alloc_io_queue() in r8712_usb_dvobj_init() is not properly released as there is no action will be performed by r8712_usb_dvobj_deinit(). To properly release it, we should call r8712_free_io_queue() in r8712_usb_dvobj_deinit(). Besides, in r871xu_dev_remove(), r8712_usb_dvobj_deinit() will be called by r871x_dev_unload() under condition `padapter->bup` and r8712_free_io_queue() is called by r8712_free_drv_sw(). However, r8712_usb_dvobj_deinit() does not rely on `padapter->bup` and calling r8712_free_io_queue() in r8712_free_drv_sw() is negative for better understading the code. So I move r8712_usb_dvobj_deinit() into r871xu_dev_remove(), and remove r8712_free_io_queue() from r8712_free_drv_sw(). CVE-2022-49312 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drivers: usb: host: Fix deadlock in oxu_bus_suspend() There is a deadlock in oxu_bus_suspend(), which is shown below: (Thread 1) | (Thread 2) | timer_action() oxu_bus_suspend() | mod_timer() spin_lock_irq() //(1) | (wait a time) ... | oxu_watchdog() del_timer_sync() | spin_lock_irq() //(2) (wait timer to stop) | ... We hold oxu->lock in position (1) of thread 1, and use del_timer_sync() to wait timer to stop, but timer handler also need oxu->lock in position (2) of thread 2. As a result, oxu_bus_suspend() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irq(), which could let timer handler to obtain the needed lock. CVE-2022-49313 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: tty: Fix a possible resource leak in icom_probe When pci_read_config_dword failed, call pci_release_regions() and pci_disable_device() to recycle the resource previously allocated. CVE-2022-49314 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drivers: staging: rtl8192e: Fix deadlock in rtllib_beacons_stop() There is a deadlock in rtllib_beacons_stop(), which is shown below: (Thread 1) | (Thread 2) | rtllib_send_beacon() rtllib_beacons_stop() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | rtllib_send_beacon_cb() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold ieee->beacon_lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need ieee->beacon_lock in position (2) of thread 2. As a result, rtllib_beacons_stop() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irqsave(), which could let timer handler to obtain the needed lock. CVE-2022-49315 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: NFSv4: Don't hold the layoutget locks across multiple RPC calls When doing layoutget as part of the open() compound, we have to be careful to release the layout locks before we can call any further RPC calls, such as setattr(). The reason is that those calls could trigger a recall, which could deadlock. CVE-2022-49316 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu-v3: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. CVE-2022-49319 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: dmaengine: zynqmp_dma: In struct zynqmp_dma_chan fix desc_size data type In zynqmp_dma_alloc/free_chan_resources functions there is a potential overflow in the below expressions. dma_alloc_coherent(chan->dev, (2 * chan->desc_size * ZYNQMP_DMA_NUM_DESCS), &chan->desc_pool_p, GFP_KERNEL); dma_free_coherent(chan->dev,(2 * ZYNQMP_DMA_DESC_SIZE(chan) * ZYNQMP_DMA_NUM_DESCS), chan->desc_pool_v, chan->desc_pool_p); The arguments desc_size and ZYNQMP_DMA_NUM_DESCS were 32 bit. Though this overflow condition is not observed but it is a potential problem in the case of 32-bit multiplication. Hence fix it by changing the desc_size data type to size_t. In addition to coverity fix it also reuse ZYNQMP_DMA_DESC_SIZE macro in dma_alloc_coherent API argument. Addresses-Coverity: Event overflow_before_widen. CVE-2022-49320 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: xprtrdma: treat all calls not a bcall when bc_serv is NULL When a rdma server returns a fault format reply, nfs v3 client may treats it as a bcall when bc service is not exist. The debug message at rpcrdma_bc_receive_call are, [56579.837169] RPC: rpcrdma_bc_receive_call: callback XID 00000001, length=20 [56579.837174] RPC: rpcrdma_bc_receive_call: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 After that, rpcrdma_bc_receive_call will meets NULL pointer as, [ 226.057890] BUG: unable to handle kernel NULL pointer dereference at 00000000000000c8 ... [ 226.058704] RIP: 0010:_raw_spin_lock+0xc/0x20 ... [ 226.059732] Call Trace: [ 226.059878] rpcrdma_bc_receive_call+0x138/0x327 [rpcrdma] [ 226.060011] __ib_process_cq+0x89/0x170 [ib_core] [ 226.060092] ib_cq_poll_work+0x26/0x80 [ib_core] [ 226.060257] process_one_work+0x1a7/0x360 [ 226.060367] ? create_worker+0x1a0/0x1a0 [ 226.060440] worker_thread+0x30/0x390 [ 226.060500] ? create_worker+0x1a0/0x1a0 [ 226.060574] kthread+0x116/0x130 [ 226.060661] ? kthread_flush_work_fn+0x10/0x10 [ 226.060724] ret_from_fork+0x35/0x40 ... CVE-2022-49321 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: tracing: Fix sleeping function called from invalid context on RT kernel When setting bootparams="trace_event=initcall:initcall_start tp_printk=1" in the cmdline, the output_printk() was called, and the spin_lock_irqsave() was called in the atomic and irq disable interrupt context suitation. On the PREEMPT_RT kernel, these locks are replaced with sleepable rt-spinlock, so the stack calltrace will be triggered. Fix it by raw_spin_lock_irqsave when PREEMPT_RT and "trace_event=initcall:initcall_start tp_printk=1" enabled. BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0 preempt_count: 2, expected: 0 RCU nest depth: 0, expected: 0 Preemption disabled at: [<ffffffff8992303e>] try_to_wake_up+0x7e/0xba0 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.1-rt17+ #19 34c5812404187a875f32bee7977f7367f9679ea7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x60/0x8c dump_stack+0x10/0x12 __might_resched.cold+0x11d/0x155 rt_spin_lock+0x40/0x70 trace_event_buffer_commit+0x2fa/0x4c0 ? map_vsyscall+0x93/0x93 trace_event_raw_event_initcall_start+0xbe/0x110 ? perf_trace_initcall_finish+0x210/0x210 ? probe_sched_wakeup+0x34/0x40 ? ttwu_do_wakeup+0xda/0x310 ? trace_hardirqs_on+0x35/0x170 ? map_vsyscall+0x93/0x93 do_one_initcall+0x217/0x3c0 ? trace_event_raw_event_initcall_level+0x170/0x170 ? push_cpu_stop+0x400/0x400 ? cblist_init_generic+0x241/0x290 kernel_init_freeable+0x1ac/0x347 ? _raw_spin_unlock_irq+0x65/0x80 ? rest_init+0xf0/0xf0 kernel_init+0x1e/0x150 ret_from_fork+0x22/0x30 </TASK> CVE-2022-49322 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu: fix possible null-ptr-deref in arm_smmu_device_probe() It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code. CVE-2022-49323 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: rtl818x: Prevent using not initialized queues Using not existing queues can panic the kernel with rtl8180/rtl8185 cards. Ignore the skb priority for those cards, they only have one tx queue. Pierre Asselin (pa@panix.com) reported the kernel crash in the Gentoo forum: https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html He also confirmed that this patch fixes the issue. In summary this happened: After updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a "divide error: 0000" when connecting to an AP. Control port tx now tries to use IEEE80211_AC_VO for the priority, which wpa_supplicants starts to use in 2.10. Since only the rtl8187se part of the driver supports QoS, the priority of the skb is set to IEEE80211_AC_BE (2) by mac80211 for rtl8180/rtl8185 cards. rtl8180 is then unconditionally reading out the priority and finally crashes on drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without this patch: idx = (ring->idx + skb_queue_len(&ring->queue)) % ring->entries "ring->entries" is zero for rtl8180/rtl8185 cards, tx_ring[2] never got initialized. CVE-2022-49326 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: bcache: avoid journal no-space deadlock by reserving 1 journal bucket The journal no-space deadlock was reported time to time. Such deadlock can happen in the following situation. When all journal buckets are fully filled by active jset with heavy write I/O load, the cache set registration (after a reboot) will load all active jsets and inserting them into the btree again (which is called journal replay). If a journaled bkey is inserted into a btree node and results btree node split, new journal request might be triggered. For example, the btree grows one more level after the node split, then the root node record in cache device super block will be upgrade by bch_journal_meta() from bch_btree_set_root(). But there is no space in journal buckets, the journal replay has to wait for new journal bucket to be reclaimed after at least one journal bucket replayed. This is one example that how the journal no-space deadlock happens. The solution to avoid the deadlock is to reserve 1 journal bucket in run time, and only permit the reserved journal bucket to be used during cache set registration procedure for things like journal replay. Then the journal space will never be fully filled, there is no chance for journal no-space deadlock to happen anymore. This patch adds a new member "bool do_reserve" in struct journal, it is inititalized to 0 (false) when struct journal is allocated, and set to 1 (true) by bch_journal_space_reserve() when all initialization done in run_cache_set(). In the run time when journal_reclaim() tries to allocate a new journal bucket, free_journal_buckets() is called to check whether there are enough free journal buckets to use. If there is only 1 free journal bucket and journal->do_reserve is 1 (true), the last bucket is reserved and free_journal_buckets() will return 0 to indicate no free journal bucket. Then journal_reclaim() will give up, and try next time to see whetheer there is free journal bucket to allocate. By this method, there is always 1 jouranl bucket reserved in run time. During the cache set registration, journal->do_reserve is 0 (false), so the reserved journal bucket can be used to avoid the no-space deadlock. CVE-2022-49327 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: mt76: fix use-after-free by removing a non-RCU wcid pointer Fixes an issue caught by KASAN about use-after-free in mt76_txq_schedule by protecting mtxq->wcid with rcu_lock between mt76_txq_schedule and sta_info_[alloc, free]. [18853.876689] ================================================================== [18853.876751] BUG: KASAN: use-after-free in mt76_txq_schedule+0x204/0xaf8 [mt76] [18853.876773] Read of size 8 at addr ffffffaf989a2138 by task mt76-tx phy0/883 [18853.876786] [18853.876810] CPU: 5 PID: 883 Comm: mt76-tx phy0 Not tainted 5.10.100-fix-510-56778d365941-kasan #5 0b01fbbcf41a530f52043508fec2e31a4215 [18853.876840] Call trace: [18853.876861] dump_backtrace+0x0/0x3ec [18853.876878] show_stack+0x20/0x2c [18853.876899] dump_stack+0x11c/0x1ac [18853.876918] print_address_description+0x74/0x514 [18853.876934] kasan_report+0x134/0x174 [18853.876948] __asan_report_load8_noabort+0x44/0x50 [18853.876976] mt76_txq_schedule+0x204/0xaf8 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2] [18853.877002] mt76_txq_schedule_all+0x2c/0x48 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2] [18853.877030] mt7921_tx_worker+0xa0/0x1cc [mt7921_common f0875ebac9d7b4754e1010549e7db50fbd90a047] [18853.877054] __mt76_worker_fn+0x190/0x22c [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2] [18853.877071] kthread+0x2f8/0x3b8 [18853.877087] ret_from_fork+0x10/0x30 [18853.877098] [18853.877112] Allocated by task 941: [18853.877131] kasan_save_stack+0x38/0x68 [18853.877147] __kasan_kmalloc+0xd4/0xfc [18853.877163] kasan_kmalloc+0x10/0x1c [18853.877177] __kmalloc+0x264/0x3c4 [18853.877294] sta_info_alloc+0x460/0xf88 [mac80211] [18853.877410] ieee80211_prep_connection+0x204/0x1ee0 [mac80211] [18853.877523] ieee80211_mgd_auth+0x6c4/0xa4c [mac80211] [18853.877635] ieee80211_auth+0x20/0x2c [mac80211] [18853.877733] rdev_auth+0x7c/0x438 [cfg80211] [18853.877826] cfg80211_mlme_auth+0x26c/0x390 [cfg80211] [18853.877919] nl80211_authenticate+0x6d4/0x904 [cfg80211] [18853.877938] genl_rcv_msg+0x748/0x93c [18853.877954] netlink_rcv_skb+0x160/0x2a8 [18853.877969] genl_rcv+0x3c/0x54 [18853.877985] netlink_unicast_kernel+0x104/0x1ec [18853.877999] netlink_unicast+0x178/0x268 [18853.878015] netlink_sendmsg+0x3cc/0x5f0 [18853.878030] sock_sendmsg+0xb4/0xd8 [18853.878043] ____sys_sendmsg+0x2f8/0x53c [18853.878058] ___sys_sendmsg+0xe8/0x150 [18853.878071] __sys_sendmsg+0xc4/0x1f4 [18853.878087] __arm64_compat_sys_sendmsg+0x88/0x9c [18853.878101] el0_svc_common+0x1b4/0x390 [18853.878115] do_el0_svc_compat+0x8c/0xdc [18853.878131] el0_svc_compat+0x10/0x1c [18853.878146] el0_sync_compat_handler+0xa8/0xcc [18853.878161] el0_sync_compat+0x188/0x1c0 [18853.878171] [18853.878183] Freed by task 10927: [18853.878200] kasan_save_stack+0x38/0x68 [18853.878215] kasan_set_track+0x28/0x3c [18853.878228] kasan_set_free_info+0x24/0x48 [18853.878244] __kasan_slab_free+0x11c/0x154 [18853.878259] kasan_slab_free+0x14/0x24 [18853.878273] slab_free_freelist_hook+0xac/0x1b0 [18853.878287] kfree+0x104/0x390 [18853.878402] sta_info_free+0x198/0x210 [mac80211] [18853.878515] __sta_info_destroy_part2+0x230/0x2d4 [mac80211] [18853.878628] __sta_info_flush+0x300/0x37c [mac80211] [18853.878740] ieee80211_set_disassoc+0x2cc/0xa7c [mac80211] [18853.878851] ieee80211_mgd_deauth+0x4a4/0x10a0 [mac80211] [18853.878962] ieee80211_deauth+0x20/0x2c [mac80211] [18853.879057] rdev_deauth+0x7c/0x438 [cfg80211] [18853.879150] cfg80211_mlme_deauth+0x274/0x414 [cfg80211] [18853.879243] cfg80211_mlme_down+0xe4/0x118 [cfg80211] [18853.879335] cfg80211_disconnect+0x218/0x2d8 [cfg80211] [18853.879427] __cfg80211_leave+0x17c/0x240 [cfg80211] [18853.879519] cfg80211_leave+0x3c/0x58 [cfg80211] [18853.879611] wiphy_suspend+0xdc/0x200 [cfg80211] [18853.879628] dpm_run_callback+0x58/0x408 [18853.879642] __device_suspend+0x4cc/0x864 [18853.879658] async_suspend+0x34/0xf4 [18 ---truncated--- CVE-2022-49328 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling Error paths do not free previously allocated memory. Add devm_kfree() to those failure paths. CVE-2022-49331 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Address NULL pointer dereference after starget_to_rport() Calls to starget_to_rport() may return NULL. Add check for NULL rport before dereference. CVE-2022-49332 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/cs: make commands with 0 chunks illegal behaviour. Submitting a cs with 0 chunks, causes an oops later, found trying to execute the wrong userspace driver. MESA_LOADER_DRIVER_OVERRIDE=v3d glxinfo [172536.665184] BUG: kernel NULL pointer dereference, address: 00000000000001d8 [172536.665188] #PF: supervisor read access in kernel mode [172536.665189] #PF: error_code(0x0000) - not-present page [172536.665191] PGD 6712a0067 P4D 6712a0067 PUD 5af9ff067 PMD 0 [172536.665195] Oops: 0000 [#1] SMP NOPTI [172536.665197] CPU: 7 PID: 2769838 Comm: glxinfo Tainted: P O 5.10.81 #1-NixOS [172536.665199] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CROSSHAIR V FORMULA-Z, BIOS 2201 03/23/2015 [172536.665272] RIP: 0010:amdgpu_cs_ioctl+0x96/0x1ce0 [amdgpu] [172536.665274] Code: 75 18 00 00 4c 8b b2 88 00 00 00 8b 46 08 48 89 54 24 68 49 89 f7 4c 89 5c 24 60 31 d2 4c 89 74 24 30 85 c0 0f 85 c0 01 00 00 <48> 83 ba d8 01 00 00 00 48 8b b4 24 90 00 00 00 74 16 48 8b 46 10 [172536.665276] RSP: 0018:ffffb47c0e81bbe0 EFLAGS: 00010246 [172536.665277] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [172536.665278] RDX: 0000000000000000 RSI: ffffb47c0e81be28 RDI: ffffb47c0e81bd68 [172536.665279] RBP: ffff936524080010 R08: 0000000000000000 R09: ffffb47c0e81be38 [172536.665281] R10: ffff936524080010 R11: ffff936524080000 R12: ffffb47c0e81bc40 [172536.665282] R13: ffffb47c0e81be28 R14: ffff9367bc410000 R15: ffffb47c0e81be28 [172536.665283] FS: 00007fe35e05d740(0000) GS:ffff936c1edc0000(0000) knlGS:0000000000000000 [172536.665284] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [172536.665286] CR2: 00000000000001d8 CR3: 0000000532e46000 CR4: 00000000000406e0 [172536.665287] Call Trace: [172536.665322] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] [172536.665332] drm_ioctl_kernel+0xaa/0xf0 [drm] [172536.665338] drm_ioctl+0x201/0x3b0 [drm] [172536.665369] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] [172536.665372] ? selinux_file_ioctl+0x135/0x230 [172536.665399] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] [172536.665403] __x64_sys_ioctl+0x83/0xb0 [172536.665406] do_syscall_64+0x33/0x40 [172536.665409] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2018 CVE-2022-49335 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/etnaviv: check for reaped mapping in etnaviv_iommu_unmap_gem When the mapping is already reaped the unmap must be a no-op, as we would otherwise try to remove the mapping twice, corrupting the involved data structures. CVE-2022-49336 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock When user_dlm_destroy_lock failed, it didn't clean up the flags it set before exit. For USER_LOCK_IN_TEARDOWN, if this function fails because of lock is still in used, next time when unlink invokes this function, it will return succeed, and then unlink will remove inode and dentry if lock is not in used(file closed), but the dlm lock is still linked in dlm lock resource, then when bast come in, it will trigger a panic due to user-after-free. See the following panic call trace. To fix this, USER_LOCK_IN_TEARDOWN should be reverted if fail. And also error should be returned if USER_LOCK_IN_TEARDOWN is set to let user know that unlink fail. For the case of ocfs2_dlm_unlock failure, besides USER_LOCK_IN_TEARDOWN, USER_LOCK_BUSY is also required to be cleared. Even though spin lock is released in between, but USER_LOCK_IN_TEARDOWN is still set, for USER_LOCK_BUSY, if before every place that waits on this flag, USER_LOCK_IN_TEARDOWN is checked to bail out, that will make sure no flow waits on the busy flag set by user_dlm_destroy_lock(), then we can simplely revert USER_LOCK_BUSY when ocfs2_dlm_unlock fails. Fix user_dlm_cluster_lock() which is the only function not following this. [ 941.336392] (python,26174,16):dlmfs_unlink:562 ERROR: unlink 004fb0000060000b5a90b8c847b72e1, error -16 from destroy [ 989.757536] ------------[ cut here ]------------ [ 989.757709] kernel BUG at fs/ocfs2/dlmfs/userdlm.c:173! [ 989.757876] invalid opcode: 0000 [#1] SMP [ 989.758027] Modules linked in: ksplice_2zhuk2jr_ib_ipoib_new(O) ksplice_2zhuk2jr(O) mptctl mptbase xen_netback xen_blkback xen_gntalloc xen_gntdev xen_evtchn cdc_ether usbnet mii ocfs2 jbd2 rpcsec_gss_krb5 auth_rpcgss nfsv4 nfsv3 nfs_acl nfs fscache lockd grace ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fc fcoe libfcoe libfc scsi_transport_fc sunrpc ipmi_devintf bridge stp llc rds_rdma rds bonding ib_sdp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm falcon_lsm_serviceable(PE) falcon_nf_netcontain(PE) mlx4_vnic falcon_kal(E) falcon_lsm_pinned_13402(E) mlx4_ib ib_sa ib_mad ib_core ib_addr xenfs xen_privcmd dm_multipath iTCO_wdt iTCO_vendor_support pcspkr sb_edac edac_core i2c_i801 lpc_ich mfd_core ipmi_ssif i2c_core ipmi_si ipmi_msghandler [ 989.760686] ioatdma sg ext3 jbd mbcache sd_mod ahci libahci ixgbe dca ptp pps_core vxlan udp_tunnel ip6_udp_tunnel megaraid_sas mlx4_core crc32c_intel be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi wmi dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ksplice_2zhuk2jr_ib_ipoib_old] [ 989.761987] CPU: 10 PID: 19102 Comm: dlm_thread Tainted: P OE 4.1.12-124.57.1.el6uek.x86_64 #2 [ 989.762290] Hardware name: Oracle Corporation ORACLE SERVER X5-2/ASM,MOTHERBOARD,1U, BIOS 30350100 06/17/2021 [ 989.762599] task: ffff880178af6200 ti: ffff88017f7c8000 task.ti: ffff88017f7c8000 [ 989.762848] RIP: e030:[<ffffffffc07d4316>] [<ffffffffc07d4316>] __user_dlm_queue_lockres.part.4+0x76/0x80 [ocfs2_dlmfs] [ 989.763185] RSP: e02b:ffff88017f7cbcb8 EFLAGS: 00010246 [ 989.763353] RAX: 0000000000000000 RBX: ffff880174d48008 RCX: 0000000000000003 [ 989.763565] RDX: 0000000000120012 RSI: 0000000000000003 RDI: ffff880174d48170 [ 989.763778] RBP: ffff88017f7cbcc8 R08: ffff88021f4293b0 R09: 0000000000000000 [ 989.763991] R10: ffff880179c8c000 R11: 0000000000000003 R12: ffff880174d48008 [ 989.764204] R13: 0000000000000003 R14: ffff880179c8c000 R15: ffff88021db7a000 [ 989.764422] FS: 0000000000000000(0000) GS:ffff880247480000(0000) knlGS:ffff880247480000 [ 989.764685] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 989.764865] CR2: ffff8000007f6800 CR3: 0000000001ae0000 CR4: 0000000000042660 [ 989.765081] Stack: [ 989.765167] 00000000000 ---truncated--- CVE-2022-49337 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: ipv6: unexport __init-annotated seg6_hmac_init() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. There are two ways to fix it: - Remove __init - Remove EXPORT_SYMBOL I chose the latter for this case because the caller (net/ipv6/seg6.c) and the callee (net/ipv6/seg6_hmac.c) belong to the same module. It seems an internal function call in ipv6.ko. CVE-2022-49339 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: bpf, arm64: Clear prog->jited_len along prog->jited syzbot reported an illegal copy_to_user() attempt from bpf_prog_get_info_by_fd() [1] There was no repro yet on this bug, but I think that commit 0aef499f3172 ("mm/usercopy: Detect vmalloc overruns") is exposing a prior bug in bpf arm64. bpf_prog_get_info_by_fd() looks at prog->jited_len to determine if the JIT image can be copied out to user space. My theory is that syzbot managed to get a prog where prog->jited_len has been set to 43, while prog->bpf_func has ben cleared. It is not clear why copy_to_user(uinsns, NULL, ulen) is triggering this particular warning. I thought find_vma_area(NULL) would not find a vm_struct. As we do not hold vmap_area_lock spinlock, it might be possible that the found vm_struct was garbage. [1] usercopy: Kernel memory exposure attempt detected from vmalloc (offset 792633534417210172, size 43)! kernel BUG at mm/usercopy.c:101! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 25002 Comm: syz-executor.1 Not tainted 5.18.0-syzkaller-10139-g8291eaafed36 #0 Hardware name: linux,dummy-virt (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usercopy_abort+0x90/0x94 mm/usercopy.c:101 lr : usercopy_abort+0x90/0x94 mm/usercopy.c:89 sp : ffff80000b773a20 x29: ffff80000b773a30 x28: faff80000b745000 x27: ffff80000b773b48 x26: 0000000000000000 x25: 000000000000002b x24: 0000000000000000 x23: 00000000000000e0 x22: ffff80000b75db67 x21: 0000000000000001 x20: 000000000000002b x19: ffff80000b75db3c x18: 00000000fffffffd x17: 2820636f6c6c616d x16: 76206d6f72662064 x15: 6574636574656420 x14: 74706d6574746120 x13: 2129333420657a69 x12: 73202c3237313031 x11: 3237313434333533 x10: 3336323937207465 x9 : 657275736f707865 x8 : ffff80000a30c550 x7 : ffff80000b773830 x6 : ffff80000b773830 x5 : 0000000000000000 x4 : ffff00007fbbaa10 x3 : 0000000000000000 x2 : 0000000000000000 x1 : f7ff000028fc0000 x0 : 0000000000000064 Call trace: usercopy_abort+0x90/0x94 mm/usercopy.c:89 check_heap_object mm/usercopy.c:186 [inline] __check_object_size mm/usercopy.c:252 [inline] __check_object_size+0x198/0x36c mm/usercopy.c:214 check_object_size include/linux/thread_info.h:199 [inline] check_copy_size include/linux/thread_info.h:235 [inline] copy_to_user include/linux/uaccess.h:159 [inline] bpf_prog_get_info_by_fd.isra.0+0xf14/0xfdc kernel/bpf/syscall.c:3993 bpf_obj_get_info_by_fd+0x12c/0x510 kernel/bpf/syscall.c:4253 __sys_bpf+0x900/0x2150 kernel/bpf/syscall.c:4956 __do_sys_bpf kernel/bpf/syscall.c:5021 [inline] __se_sys_bpf kernel/bpf/syscall.c:5019 [inline] __arm64_sys_bpf+0x28/0x40 kernel/bpf/syscall.c:5019 __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline] invoke_syscall+0x48/0x114 arch/arm64/kernel/syscall.c:52 el0_svc_common.constprop.0+0x44/0xec arch/arm64/kernel/syscall.c:142 do_el0_svc+0xa0/0xc0 arch/arm64/kernel/syscall.c:206 el0_svc+0x44/0xb0 arch/arm64/kernel/entry-common.c:624 el0t_64_sync_handler+0x1ac/0x1b0 arch/arm64/kernel/entry-common.c:642 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:581 Code: aa0003e3 d00038c0 91248000 97fff65f (d4210000) CVE-2022-49341 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: ethernet: bgmac: Fix refcount leak in bcma_mdio_mii_register of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. CVE-2022-49342 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: xfrm: unexport __init-annotated xfrm4_protocol_init() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. There are two ways to fix it: - Remove __init - Remove EXPORT_SYMBOL I chose the latter for this case because the only in-tree call-site, net/ipv4/xfrm4_policy.c is never compiled as modular. (CONFIG_XFRM is boolean) CVE-2022-49345 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: dsa: lantiq_gswip: Fix refcount leak in gswip_gphy_fw_list Every iteration of for_each_available_child_of_node() decrements the reference count of the previous node. when breaking early from a for_each_available_child_of_node() loop, we need to explicitly call of_node_put() on the gphy_fw_np. Add missing of_node_put() to avoid refcount leak. CVE-2022-49346 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: fix bug_on in ext4_writepages we got issue as follows: EXT4-fs error (device loop0): ext4_mb_generate_buddy:1141: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free cls ------------[ cut here ]------------ kernel BUG at fs/ext4/inode.c:2708! invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 2 PID: 2147 Comm: rep Not tainted 5.18.0-rc2-next-20220413+ #155 RIP: 0010:ext4_writepages+0x1977/0x1c10 RSP: 0018:ffff88811d3e7880 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88811c098000 RDX: 0000000000000000 RSI: ffff88811c098000 RDI: 0000000000000002 RBP: ffff888128140f50 R08: ffffffffb1ff6387 R09: 0000000000000000 R10: 0000000000000007 R11: ffffed10250281ea R12: 0000000000000001 R13: 00000000000000a4 R14: ffff88811d3e7bb8 R15: ffff888128141028 FS: 00007f443aed9740(0000) GS:ffff8883aef00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020007200 CR3: 000000011c2a4000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> do_writepages+0x130/0x3a0 filemap_fdatawrite_wbc+0x83/0xa0 filemap_flush+0xab/0xe0 ext4_alloc_da_blocks+0x51/0x120 __ext4_ioctl+0x1534/0x3210 __x64_sys_ioctl+0x12c/0x170 do_syscall_64+0x3b/0x90 It may happen as follows: 1. write inline_data inode vfs_write new_sync_write ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin ext4_da_write_inline_data_begin -> If inline data size too small will allocate block to write, then mapping will has dirty page ext4_da_convert_inline_data_to_extent ->clear EXT4_STATE_MAY_INLINE_DATA 2. fallocate do_vfs_ioctl ioctl_preallocate vfs_fallocate ext4_fallocate ext4_convert_inline_data ext4_convert_inline_data_nolock ext4_map_blocks -> fail will goto restore data ext4_restore_inline_data ext4_create_inline_data ext4_write_inline_data ext4_set_inode_state -> set inode EXT4_STATE_MAY_INLINE_DATA 3. writepages __ext4_ioctl ext4_alloc_da_blocks filemap_flush filemap_fdatawrite_wbc do_writepages ext4_writepages if (ext4_has_inline_data(inode)) BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) The root cause of this issue is we destory inline data until call ext4_writepages under delay allocation mode. But there maybe already convert from inline to extent. To solve this issue, we call filemap_flush first.. CVE-2022-49347 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: filter out EXT4_FC_REPLAY from on-disk superblock field s_state The EXT4_FC_REPLAY bit in sbi->s_mount_state is used to indicate that we are in the middle of replay the fast commit journal. This was actually a mistake, since the sbi->s_mount_info is initialized from es->s_state. Arguably s_mount_state is misleadingly named, but the name is historical --- s_mount_state and s_state dates back to ext2. What should have been used is the ext4_{set,clear,test}_mount_flag() inline functions, which sets EXT4_MF_* bits in sbi->s_mount_flags. The problem with using EXT4_FC_REPLAY is that a maliciously corrupted superblock could result in EXT4_FC_REPLAY getting set in s_mount_state. This bypasses some sanity checks, and this can trigger a BUG() in ext4_es_cache_extent(). As a easy-to-backport-fix, filter out the EXT4_FC_REPLAY bit for now. We should eventually transition away from EXT4_FC_REPLAY to something like EXT4_MF_REPLAY. CVE-2022-49348 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: fix use-after-free in ext4_rename_dir_prepare We got issue as follows: EXT4-fs (loop0): mounted filesystem without journal. Opts: ,errors=continue ext4_get_first_dir_block: bh->b_data=0xffff88810bee6000 len=34478 ext4_get_first_dir_block: *parent_de=0xffff88810beee6ae bh->b_data=0xffff88810bee6000 ext4_rename_dir_prepare: [1] parent_de=0xffff88810beee6ae ================================================================== BUG: KASAN: use-after-free in ext4_rename_dir_prepare+0x152/0x220 Read of size 4 at addr ffff88810beee6ae by task rep/1895 CPU: 13 PID: 1895 Comm: rep Not tainted 5.10.0+ #241 Call Trace: dump_stack+0xbe/0xf9 print_address_description.constprop.0+0x1e/0x220 kasan_report.cold+0x37/0x7f ext4_rename_dir_prepare+0x152/0x220 ext4_rename+0xf44/0x1ad0 ext4_rename2+0x11c/0x170 vfs_rename+0xa84/0x1440 do_renameat2+0x683/0x8f0 __x64_sys_renameat+0x53/0x60 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f45a6fc41c9 RSP: 002b:00007ffc5a470218 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f45a6fc41c9 RDX: 0000000000000005 RSI: 0000000020000180 RDI: 0000000000000005 RBP: 00007ffc5a470240 R08: 00007ffc5a470160 R09: 0000000020000080 R10: 00000000200001c0 R11: 0000000000000246 R12: 0000000000400bb0 R13: 00007ffc5a470320 R14: 0000000000000000 R15: 0000000000000000 The buggy address belongs to the page: page:00000000440015ce refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x10beee flags: 0x200000000000000() raw: 0200000000000000 ffffea00043ff4c8 ffffea0004325608 0000000000000000 raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88810beee580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88810beee680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88810beee700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint ext4_rename_dir_prepare: [2] parent_de->inode=3537895424 ext4_rename_dir_prepare: [3] dir=0xffff888124170140 ext4_rename_dir_prepare: [4] ino=2 ext4_rename_dir_prepare: ent->dir->i_ino=2 parent=-757071872 Reason is first directory entry which 'rec_len' is 34478, then will get illegal parent entry. Now, we do not check directory entry after read directory block in 'ext4_get_first_dir_block'. To solve this issue, check directory entry in 'ext4_get_first_dir_block'. [ Trigger an ext4_error() instead of just warning if the directory is missing a '.' or '..' entry. Also make sure we return an error code if the file system is corrupted. -TYT ] CVE-2022-49349 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: mdio: unexport __init-annotated mdio_bus_init() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. There are two ways to fix it: - Remove __init - Remove EXPORT_SYMBOL I chose the latter for this case because the only in-tree call-site, drivers/net/phy/phy_device.c is never compiled as modular. (CONFIG_PHYLIB is boolean) CVE-2022-49350 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: altera: Fix refcount leak in altera_tse_mdio_create Every iteration of for_each_child_of_node() decrements the reference count of the previous node. When break from a for_each_child_of_node() loop, we need to explicitly call of_node_put() on the child node when not need anymore. Add missing of_node_put() to avoid refcount leak. CVE-2022-49351 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: fix warning in ext4_handle_inode_extension We got issue as follows: EXT4-fs error (device loop0) in ext4_reserve_inode_write:5741: Out of memory EXT4-fs error (device loop0): ext4_setattr:5462: inode #13: comm syz-executor.0: mark_inode_dirty error EXT4-fs error (device loop0) in ext4_setattr:5519: Out of memory EXT4-fs error (device loop0): ext4_ind_map_blocks:595: inode #13: comm syz-executor.0: Can't allocate blocks for non-extent mapped inodes with bigalloc ------------[ cut here ]------------ WARNING: CPU: 1 PID: 4361 at fs/ext4/file.c:301 ext4_file_write_iter+0x11c9/0x1220 Modules linked in: CPU: 1 PID: 4361 Comm: syz-executor.0 Not tainted 5.10.0+ #1 RIP: 0010:ext4_file_write_iter+0x11c9/0x1220 RSP: 0018:ffff924d80b27c00 EFLAGS: 00010282 RAX: ffffffff815a3379 RBX: 0000000000000000 RCX: 000000003b000000 RDX: ffff924d81601000 RSI: 00000000000009cc RDI: 00000000000009cd RBP: 000000000000000d R08: ffffffffbc5a2c6b R09: 0000902e0e52a96f R10: ffff902e2b7c1b40 R11: ffff902e2b7c1b40 R12: 000000000000000a R13: 0000000000000001 R14: ffff902e0e52aa10 R15: ffffffffffffff8b FS: 00007f81a7f65700(0000) GS:ffff902e3bc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffff600400 CR3: 000000012db88001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: do_iter_readv_writev+0x2e5/0x360 do_iter_write+0x112/0x4c0 do_pwritev+0x1e5/0x390 __x64_sys_pwritev2+0x7e/0xa0 do_syscall_64+0x37/0x50 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Above issue may happen as follows: Assume inode.i_size=4096 EXT4_I(inode)->i_disksize=4096 step 1: set inode->i_isize = 8192 ext4_setattr if (attr->ia_size != inode->i_size) EXT4_I(inode)->i_disksize = attr->ia_size; rc = ext4_mark_inode_dirty ext4_reserve_inode_write ext4_get_inode_loc __ext4_get_inode_loc sb_getblk --> return -ENOMEM ... if (!error) ->will not update i_size i_size_write(inode, attr->ia_size); Now: inode.i_size=4096 EXT4_I(inode)->i_disksize=8192 step 2: Direct write 4096 bytes ext4_file_write_iter ext4_dio_write_iter iomap_dio_rw ->return error if (extend) ext4_handle_inode_extension WARN_ON_ONCE(i_size_read(inode) < EXT4_I(inode)->i_disksize); ->Then trigger warning. To solve above issue, if mark inode dirty failed in ext4_setattr just set 'EXT4_I(inode)->i_disksize' with old value. CVE-2022-49352 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ata: pata_octeon_cf: Fix refcount leak in octeon_cf_probe of_find_device_by_node() takes reference, we should use put_device() to release it when not need anymore. Add missing put_device() to avoid refcount leak. CVE-2022-49354 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Trap RDMA segment overflows Prevent svc_rdma_build_writes() from walking off the end of a Write chunk's segment array. Caught with KASAN. The test that this fix replaces is invalid, and might have been left over from an earlier prototype of the PCL work. CVE-2022-49356 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: efi: Do not import certificates from UEFI Secure Boot for T2 Macs On Apple T2 Macs, when Linux attempts to read the db and dbx efi variables at early boot to load UEFI Secure Boot certificates, a page fault occurs in Apple firmware code and EFI runtime services are disabled with the following logs: [Firmware Bug]: Page fault caused by firmware at PA: 0xffffb1edc0068000 WARNING: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x50/0xf0 (Removed some logs from here) Call Trace: <TASK> page_fault_oops+0x4f/0x2c0 ? search_bpf_extables+0x6b/0x80 ? search_module_extables+0x50/0x80 ? search_exception_tables+0x5b/0x60 kernelmode_fixup_or_oops+0x9e/0x110 __bad_area_nosemaphore+0x155/0x190 bad_area_nosemaphore+0x16/0x20 do_kern_addr_fault+0x8c/0xa0 exc_page_fault+0xd8/0x180 asm_exc_page_fault+0x1e/0x30 (Removed some logs from here) ? __efi_call+0x28/0x30 ? switch_mm+0x20/0x30 ? efi_call_rts+0x19a/0x8e0 ? process_one_work+0x222/0x3f0 ? worker_thread+0x4a/0x3d0 ? kthread+0x17a/0x1a0 ? process_one_work+0x3f0/0x3f0 ? set_kthread_struct+0x40/0x40 ? ret_from_fork+0x22/0x30 </TASK> ---[ end trace 1f82023595a5927f ]--- efi: Froze efi_rts_wq and disabled EFI Runtime Services integrity: Couldn't get size: 0x8000000000000015 integrity: MODSIGN: Couldn't get UEFI db list efi: EFI Runtime Services are disabled! integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get UEFI dbx list integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get mokx list integrity: Couldn't get size: 0x80000000 So we avoid reading these UEFI variables and thus prevent the crash. CVE-2022-49357 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Fix refcount leak in mv88e6xxx_mdios_register of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. mv88e6xxx_mdio_register() pass the device node to of_mdiobus_register(). We don't need the device node after it. Add missing of_node_put() to avoid refcount leak. CVE-2022-49367 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_eth_soc: out of bounds read in mtk_hwlro_get_fdir_entry() The "fsp->location" variable comes from user via ethtool_get_rxnfc(). Check that it is valid to prevent an out of bounds read. CVE-2022-49368 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add() If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Fix this issue by calling kobject_put(). CVE-2022-49370 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: driver core: fix deadlock in __device_attach In __device_attach function, The lock holding logic is as follows: ... __device_attach device_lock(dev) // get lock dev async_schedule_dev(__device_attach_async_helper, dev); // func async_schedule_node async_schedule_node_domain(func) entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC); /* when fail or work limit, sync to execute func, but __device_attach_async_helper will get lock dev as well, which will lead to A-A deadlock. */ if (!entry || atomic_read(&entry_count) > MAX_WORK) { func; else queue_work_node(node, system_unbound_wq, &entry->work) device_unlock(dev) As shown above, when it is allowed to do async probes, because of out of memory or work limit, async work is not allowed, to do sync execute instead. it will lead to A-A deadlock because of __device_attach_async_helper getting lock dev. To fix the deadlock, move the async_schedule_dev outside device_lock, as we can see, in async_schedule_node_domain, the parameter of queue_work_node is system_unbound_wq, so it can accept concurrent operations. which will also not change the code logic, and will not lead to deadlock. CVE-2022-49371 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: watchdog: ts4800_wdt: Fix refcount leak in ts4800_wdt_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() in some error paths. CVE-2022-49373 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: rtc: mt6397: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. CVE-2022-49375 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix potential NULL pointer dereference If sd_probe() sees an early error before sdkp->device is initialized, sd_zbc_release_disk() is called. This causes a NULL pointer dereference when sd_is_zoned() is called inside that function. Avoid this by removing the call to sd_zbc_release_disk() in sd_probe() error path. This change is safe and does not result in zone information memory leakage because the zone information for a zoned disk is allocated only when sd_revalidate_disk() is called, at which point sdkp->disk_dev is fully set, resulting in sd_disk_release() being called when needed to cleanup a disk zone information using sd_zbc_release_disk(). CVE-2022-49376 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: blk-mq: don't touch ->tagset in blk_mq_get_sq_hctx blk_mq_run_hw_queues() could be run when there isn't queued request and after queue is cleaned up, at that time tagset is freed, because tagset lifetime is covered by driver, and often freed after blk_cleanup_queue() returns. So don't touch ->tagset for figuring out current default hctx by the mapping built in request queue, so use-after-free on tagset can be avoided. Meantime this way should be fast than retrieving mapping from tagset. CVE-2022-49377 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: sfc: fix considering that all channels have TX queues Normally, all channels have RX and TX queues, but this is not true if modparam efx_separate_tx_channels=1 is used. In that cases, some channels only have RX queues and others only TX queues (or more preciselly, they have them allocated, but not initialized). Fix efx_channel_has_tx_queues to return the correct value for this case too. Messages shown at probe time before the fix: sfc 0000:03:00.0 ens6f0np0: MC command 0x82 inlen 544 failed rc=-22 (raw=0) arg=0 ------------[ cut here ]------------ netdevice: ens6f0np0: failed to initialise TXQ -1 WARNING: CPU: 1 PID: 626 at drivers/net/ethernet/sfc/ef10.c:2393 efx_ef10_tx_init+0x201/0x300 [sfc] [...] stripped RIP: 0010:efx_ef10_tx_init+0x201/0x300 [sfc] [...] stripped Call Trace: efx_init_tx_queue+0xaa/0xf0 [sfc] efx_start_channels+0x49/0x120 [sfc] efx_start_all+0x1f8/0x430 [sfc] efx_net_open+0x5a/0xe0 [sfc] __dev_open+0xd0/0x190 __dev_change_flags+0x1b3/0x220 dev_change_flags+0x21/0x60 [...] stripped Messages shown at remove time before the fix: sfc 0000:03:00.0 ens6f0np0: failed to flush 10 queues sfc 0000:03:00.0 ens6f0np0: failed to flush queues CVE-2022-49378 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: driver core: Fix wait_for_device_probe() & deferred_probe_timeout interaction Mounting NFS rootfs was timing out when deferred_probe_timeout was non-zero [1]. This was because ip_auto_config() initcall times out waiting for the network interfaces to show up when deferred_probe_timeout was non-zero. While ip_auto_config() calls wait_for_device_probe() to make sure any currently running deferred probe work or asynchronous probe finishes, that wasn't sufficient to account for devices being deferred until deferred_probe_timeout. Commit 35a672363ab3 ("driver core: Ensure wait_for_device_probe() waits until the deferred_probe_timeout fires") tried to fix that by making sure wait_for_device_probe() waits for deferred_probe_timeout to expire before returning. However, if wait_for_device_probe() is called from the kernel_init() context: - Before deferred_probe_initcall() [2], it causes the boot process to hang due to a deadlock. - After deferred_probe_initcall() [3], it blocks kernel_init() from continuing till deferred_probe_timeout expires and beats the point of deferred_probe_timeout that's trying to wait for userspace to load modules. Neither of this is good. So revert the changes to wait_for_device_probe(). [1] - https://lore.kernel.org/lkml/TYAPR01MB45443DF63B9EF29054F7C41FD8C60@TYAPR01MB4544.jpnprd01.prod.outlook.com/ [2] - https://lore.kernel.org/lkml/YowHNo4sBjr9ijZr@dev-arch.thelio-3990X/ [3] - https://lore.kernel.org/lkml/Yo3WvGnNk3LvLb7R@linutronix.de/ CVE-2022-49379 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: jffs2: fix memory leak in jffs2_do_fill_super If jffs2_iget() or d_make_root() in jffs2_do_fill_super() returns an error, we can observe the following kmemleak report: -------------------------------------------- unreferenced object 0xffff888105a65340 (size 64): comm "mount", pid 710, jiffies 4302851558 (age 58.239s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff859c45e5>] kmem_cache_alloc_trace+0x475/0x8a0 [<ffffffff86160146>] jffs2_sum_init+0x96/0x1a0 [<ffffffff86140e25>] jffs2_do_mount_fs+0x745/0x2120 [<ffffffff86149fec>] jffs2_do_fill_super+0x35c/0x810 [<ffffffff8614aae9>] jffs2_fill_super+0x2b9/0x3b0 [...] unreferenced object 0xffff8881bd7f0000 (size 65536): comm "mount", pid 710, jiffies 4302851558 (age 58.239s) hex dump (first 32 bytes): bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ backtrace: [<ffffffff858579ba>] kmalloc_order+0xda/0x110 [<ffffffff85857a11>] kmalloc_order_trace+0x21/0x130 [<ffffffff859c2ed1>] __kmalloc+0x711/0x8a0 [<ffffffff86160189>] jffs2_sum_init+0xd9/0x1a0 [<ffffffff86140e25>] jffs2_do_mount_fs+0x745/0x2120 [<ffffffff86149fec>] jffs2_do_fill_super+0x35c/0x810 [<ffffffff8614aae9>] jffs2_fill_super+0x2b9/0x3b0 [...] -------------------------------------------- This is because the resources allocated in jffs2_sum_init() are not released. Call jffs2_sum_exit() to release these resources to solve the problem. CVE-2022-49381 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: soc: rockchip: Fix refcount leak in rockchip_grf_init of_find_matching_node_and_match returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. CVE-2022-49382 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: md: fix double free of io_acct_set bioset Now io_acct_set is alloc and free in personality. Remove the codes that free io_acct_set in md_free and md_stop. CVE-2022-49384 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: driver: base: fix UAF when driver_attach failed When driver_attach(drv); failed, the driver_private will be freed. But it has been added to the bus, which caused a UAF. To fix it, we need to delete it from the bus when failed. CVE-2022-49385 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: am65-cpsw-nuss: Fix some refcount leaks of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. am65_cpsw_init_cpts() and am65_cpsw_nuss_probe() don't release the refcount in error case. Add missing of_node_put() to avoid refcount leak. CVE-2022-49386 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: usbip: fix a refcount leak in stub_probe() usb_get_dev() is called in stub_device_alloc(). When stub_probe() fails after that, usb_put_dev() needs to be called to release the reference. Fix this by moving usb_put_dev() to sdev_free error path handling. Find this by code review. CVE-2022-49389 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: serial: 8250_aspeed_vuart: Fix potential NULL dereference in aspeed_vuart_probe platform_get_resource() may fail and return NULL, so we should better check it's return value to avoid a NULL pointer dereference. CVE-2022-49392 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: blk-iolatency: Fix inflight count imbalances and IO hangs on offline iolatency needs to track the number of inflight IOs per cgroup. As this tracking can be expensive, it is disabled when no cgroup has iolatency configured for the device. To ensure that the inflight counters stay balanced, iolatency_set_limit() freezes the request_queue while manipulating the enabled counter, which ensures that no IO is in flight and thus all counters are zero. Unfortunately, iolatency_set_limit() isn't the only place where the enabled counter is manipulated. iolatency_pd_offline() can also dec the counter and trigger disabling. As this disabling happens without freezing the q, this can easily happen while some IOs are in flight and thus leak the counts. This can be easily demonstrated by turning on iolatency on an one empty cgroup while IOs are in flight in other cgroups and then removing the cgroup. Note that iolatency shouldn't have been enabled elsewhere in the system to ensure that removing the cgroup disables iolatency for the whole device. The following keeps flipping on and off iolatency on sda: echo +io > /sys/fs/cgroup/cgroup.subtree_control while true; do mkdir -p /sys/fs/cgroup/test echo '8:0 target=100000' > /sys/fs/cgroup/test/io.latency sleep 1 rmdir /sys/fs/cgroup/test sleep 1 done and there's concurrent fio generating direct rand reads: fio --name test --filename=/dev/sda --direct=1 --rw=randread \ --runtime=600 --time_based --iodepth=256 --numjobs=4 --bs=4k while monitoring with the following drgn script: while True: for css in css_for_each_descendant_pre(prog['blkcg_root'].css.address_of_()): for pos in hlist_for_each(container_of(css, 'struct blkcg', 'css').blkg_list): blkg = container_of(pos, 'struct blkcg_gq', 'blkcg_node') pd = blkg.pd[prog['blkcg_policy_iolatency'].plid] if pd.value_() == 0: continue iolat = container_of(pd, 'struct iolatency_grp', 'pd') inflight = iolat.rq_wait.inflight.counter.value_() if inflight: print(f'inflight={inflight} {disk_name(blkg.q.disk).decode("utf-8")} ' f'{cgroup_path(css.cgroup).decode("utf-8")}') time.sleep(1) The monitoring output looks like the following: inflight=1 sda /user.slice inflight=1 sda /user.slice ... inflight=14 sda /user.slice inflight=13 sda /user.slice inflight=17 sda /user.slice inflight=15 sda /user.slice inflight=18 sda /user.slice inflight=17 sda /user.slice inflight=20 sda /user.slice inflight=19 sda /user.slice <- fio stopped, inflight stuck at 19 inflight=19 sda /user.slice inflight=19 sda /user.slice If a cgroup with stuck inflight ends up getting throttled, the throttled IOs will never get issued as there's no completion event to wake it up leading to an indefinite hang. This patch fixes the bug by unifying enable handling into a work item which is automatically kicked off from iolatency_set_min_lat_nsec() which is called from both iolatency_set_limit() and iolatency_pd_offline() paths. Punting to a work item is necessary as iolatency_pd_offline() is called under spinlocks while freezing a request_queue requires a sleepable context. This also simplifies the code reducing LOC sans the comments and avoids the unnecessary freezes which were happening whenever a cgroup's latency target is newly set or cleared. CVE-2022-49394 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: phy: qcom-qmp: fix reset-controller leak on probe errors Make sure to release the lane reset controller in case of a late probe error (e.g. probe deferral). Note that due to the reset controller being defined in devicetree in "lane" child nodes, devm_reset_control_get_exclusive() cannot be used directly. CVE-2022-49396 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: phy: qcom-qmp: fix struct clk leak on probe errors Make sure to release the pipe clock reference in case of a late probe error (e.g. probe deferral). CVE-2022-49397 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: gadget: Replace list_for_each_entry_safe() if using giveback The list_for_each_entry_safe() macro saves the current item (n) and the item after (n+1), so that n can be safely removed without corrupting the list. However, when traversing the list and removing items using gadget giveback, the DWC3 lock is briefly released, allowing other routines to execute. There is a situation where, while items are being removed from the cancelled_list using dwc3_gadget_ep_cleanup_cancelled_requests(), the pullup disable routine is running in parallel (due to UDC unbind). As the cleanup routine removes n, and the pullup disable removes n+1, once the cleanup retakes the DWC3 lock, it references a request who was already removed/handled. With list debug enabled, this leads to a panic. Ensure all instances of the macro are replaced where gadget giveback is used. Example call stack: Thread#1: __dwc3_gadget_ep_set_halt() - CLEAR HALT -> dwc3_gadget_ep_cleanup_cancelled_requests() ->list_for_each_entry_safe() ->dwc3_gadget_giveback(n) ->dwc3_gadget_del_and_unmap_request()- n deleted[cancelled_list] ->spin_unlock ->Thread#2 executes ... ->dwc3_gadget_giveback(n+1) ->Already removed! Thread#2: dwc3_gadget_pullup() ->waiting for dwc3 spin_lock ... ->Thread#1 released lock ->dwc3_stop_active_transfers() ->dwc3_remove_requests() ->fetches n+1 item from cancelled_list (n removed by Thread#1) ->dwc3_gadget_giveback() ->dwc3_gadget_del_and_unmap_request()- n+1 deleted[cancelled_list] ->spin_unlock CVE-2022-49398 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: tty: goldfish: Use tty_port_destroy() to destroy port In goldfish_tty_probe(), the port initialized through tty_port_init() should be destroyed in error paths.In goldfish_tty_remove(), qtty->port also should be destroyed or else might leak resources. Fix the above by calling tty_port_destroy(). CVE-2022-49399 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: md: Don't set mddev private to NULL in raid0 pers->free In normal stop process, it does like this: do_md_stop | __md_stop (pers->free(); mddev->private=NULL) | md_free (free mddev) __md_stop sets mddev->private to NULL after pers->free. The raid device will be stopped and mddev memory is free. But in reshape, it doesn't free the mddev and mddev will still be used in new raid. In reshape, it first sets mddev->private to new_pers and then runs old_pers->free(). Now raid0 sets mddev->private to NULL in raid0_free. The new raid can't work anymore. It will panic when dereference mddev->private because of NULL pointer dereference. It can panic like this: [63010.814972] kernel BUG at drivers/md/raid10.c:928! [63010.819778] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [63010.825011] CPU: 3 PID: 44437 Comm: md0_resync Kdump: loaded Not tainted 5.14.0-86.el9.x86_64 #1 [63010.833789] Hardware name: Dell Inc. PowerEdge R6415/07YXFK, BIOS 1.15.0 09/11/2020 [63010.841440] RIP: 0010:raise_barrier+0x161/0x170 [raid10] [63010.865508] RSP: 0018:ffffc312408bbc10 EFLAGS: 00010246 [63010.870734] RAX: 0000000000000000 RBX: ffffa00bf7d39800 RCX: 0000000000000000 [63010.877866] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffa00bf7d39800 [63010.884999] RBP: 0000000000000000 R08: fffffa4945e74400 R09: 0000000000000000 [63010.892132] R10: ffffa00eed02f798 R11: 0000000000000000 R12: ffffa00bbc435200 [63010.899266] R13: ffffa00bf7d39800 R14: 0000000000000400 R15: 0000000000000003 [63010.906399] FS: 0000000000000000(0000) GS:ffffa00eed000000(0000) knlGS:0000000000000000 [63010.914485] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [63010.920229] CR2: 00007f5cfbe99828 CR3: 0000000105efe000 CR4: 00000000003506e0 [63010.927363] Call Trace: [63010.929822] ? bio_reset+0xe/0x40 [63010.933144] ? raid10_alloc_init_r10buf+0x60/0xa0 [raid10] [63010.938629] raid10_sync_request+0x756/0x1610 [raid10] [63010.943770] md_do_sync.cold+0x3e4/0x94c [63010.947698] md_thread+0xab/0x160 [63010.951024] ? md_write_inc+0x50/0x50 [63010.954688] kthread+0x149/0x170 [63010.957923] ? set_kthread_struct+0x40/0x40 [63010.962107] ret_from_fork+0x22/0x30 Removing the code that sets mddev->private to NULL in raid0 can fix problem. CVE-2022-49400 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ftrace: Clean up hash direct_functions on register failures We see the following GPF when register_ftrace_direct fails: [ ] general protection fault, probably for non-canonical address \ 0x200000000000010: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI [...] [ ] RIP: 0010:ftrace_find_rec_direct+0x53/0x70 [ ] Code: 48 c1 e0 03 48 03 42 08 48 8b 10 31 c0 48 85 d2 74 [...] [ ] RSP: 0018:ffffc9000138bc10 EFLAGS: 00010206 [ ] RAX: 0000000000000000 RBX: ffffffff813e0df0 RCX: 000000000000003b [ ] RDX: 0200000000000000 RSI: 000000000000000c RDI: ffffffff813e0df0 [ ] RBP: ffffffffa00a3000 R08: ffffffff81180ce0 R09: 0000000000000001 [ ] R10: ffffc9000138bc18 R11: 0000000000000001 R12: ffffffff813e0df0 [ ] R13: ffffffff813e0df0 R14: ffff888171b56400 R15: 0000000000000000 [ ] FS: 00007fa9420c7780(0000) GS:ffff888ff6a00000(0000) knlGS:000000000 [ ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ ] CR2: 000000000770d000 CR3: 0000000107d50003 CR4: 0000000000370ee0 [ ] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ ] Call Trace: [ ] <TASK> [ ] register_ftrace_direct+0x54/0x290 [ ] ? render_sigset_t+0xa0/0xa0 [ ] bpf_trampoline_update+0x3f5/0x4a0 [ ] ? 0xffffffffa00a3000 [ ] bpf_trampoline_link_prog+0xa9/0x140 [ ] bpf_tracing_prog_attach+0x1dc/0x450 [ ] bpf_raw_tracepoint_open+0x9a/0x1e0 [ ] ? find_held_lock+0x2d/0x90 [ ] ? lock_release+0x150/0x430 [ ] __sys_bpf+0xbd6/0x2700 [ ] ? lock_is_held_type+0xd8/0x130 [ ] __x64_sys_bpf+0x1c/0x20 [ ] do_syscall_64+0x3a/0x80 [ ] entry_SYSCALL_64_after_hwframe+0x44/0xae [ ] RIP: 0033:0x7fa9421defa9 [ ] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 9 f8 [...] [ ] RSP: 002b:00007ffed743bd78 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 [ ] RAX: ffffffffffffffda RBX: 00000000069d2480 RCX: 00007fa9421defa9 [ ] RDX: 0000000000000078 RSI: 00007ffed743bd80 RDI: 0000000000000011 [ ] RBP: 00007ffed743be00 R08: 0000000000bb7270 R09: 0000000000000000 [ ] R10: 00000000069da210 R11: 0000000000000246 R12: 0000000000000001 [ ] R13: 00007ffed743c4b0 R14: 00000000069d2480 R15: 0000000000000001 [ ] </TASK> [ ] Modules linked in: klp_vm(OK) [ ] ---[ end trace 0000000000000000 ]--- One way to trigger this is: 1. load a livepatch that patches kernel function xxx; 2. run bpftrace -e 'kfunc:xxx {}', this will fail (expected for now); 3. repeat #2 => gpf. This is because the entry is added to direct_functions, but not removed. Fix this by remove the entry from direct_functions when register_ftrace_direct fails. Also remove the last trailing space from ftrace.c, so we don't have to worry about it anymore. CVE-2022-49402 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Fix potential integer multiplication overflow errors When multiplying of different types, an overflow is possible even when storing the result in a larger type. This is because the conversion is done after the multiplication. So arithmetic overflow and thus in incorrect value is possible. Correct an instance of this in the inter packet delay calculation. Fix by ensuring one of the operands is u64 which will promote the other to u64 as well ensuring no overflow. CVE-2022-49404 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: dlm: fix plock invalid read This patch fixes an invalid read showed by KASAN. A unlock will allocate a "struct plock_op" and a followed send_op() will append it to a global send_list data structure. In some cases a followed dev_read() moves it to recv_list and dev_write() will cast it to "struct plock_xop" and access fields which are only available in those structures. At this point an invalid read happens by accessing those fields. To fix this issue the "callback" field is moved to "struct plock_op" to indicate that a cast to "plock_xop" is allowed and does the additional "plock_xop" handling if set. Example of the KASAN output which showed the invalid read: [ 2064.296453] ================================================================== [ 2064.304852] BUG: KASAN: slab-out-of-bounds in dev_write+0x52b/0x5a0 [dlm] [ 2064.306491] Read of size 8 at addr ffff88800ef227d8 by task dlm_controld/7484 [ 2064.308168] [ 2064.308575] CPU: 0 PID: 7484 Comm: dlm_controld Kdump: loaded Not tainted 5.14.0+ #9 [ 2064.310292] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 2064.311618] Call Trace: [ 2064.312218] dump_stack_lvl+0x56/0x7b [ 2064.313150] print_address_description.constprop.8+0x21/0x150 [ 2064.314578] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.315610] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.316595] kasan_report.cold.14+0x7f/0x11b [ 2064.317674] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.318687] dev_write+0x52b/0x5a0 [dlm] [ 2064.319629] ? dev_read+0x4a0/0x4a0 [dlm] [ 2064.320713] ? bpf_lsm_kernfs_init_security+0x10/0x10 [ 2064.321926] vfs_write+0x17e/0x930 [ 2064.322769] ? __fget_light+0x1aa/0x220 [ 2064.323753] ksys_write+0xf1/0x1c0 [ 2064.324548] ? __ia32_sys_read+0xb0/0xb0 [ 2064.325464] do_syscall_64+0x3a/0x80 [ 2064.326387] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 2064.327606] RIP: 0033:0x7f807e4ba96f [ 2064.328470] Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 39 87 f8 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 7c 87 f8 ff 48 [ 2064.332902] RSP: 002b:00007ffd50cfe6e0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 [ 2064.334658] RAX: ffffffffffffffda RBX: 000055cc3886eb30 RCX: 00007f807e4ba96f [ 2064.336275] RDX: 0000000000000040 RSI: 00007ffd50cfe7e0 RDI: 0000000000000010 [ 2064.337980] RBP: 00007ffd50cfe7e0 R08: 0000000000000000 R09: 0000000000000001 [ 2064.339560] R10: 000055cc3886eb30 R11: 0000000000000293 R12: 000055cc3886eb80 [ 2064.341237] R13: 000055cc3886eb00 R14: 000055cc3886f590 R15: 0000000000000001 [ 2064.342857] [ 2064.343226] Allocated by task 12438: [ 2064.344057] kasan_save_stack+0x1c/0x40 [ 2064.345079] __kasan_kmalloc+0x84/0xa0 [ 2064.345933] kmem_cache_alloc_trace+0x13b/0x220 [ 2064.346953] dlm_posix_unlock+0xec/0x720 [dlm] [ 2064.348811] do_lock_file_wait.part.32+0xca/0x1d0 [ 2064.351070] fcntl_setlk+0x281/0xbc0 [ 2064.352879] do_fcntl+0x5e4/0xfe0 [ 2064.354657] __x64_sys_fcntl+0x11f/0x170 [ 2064.356550] do_syscall_64+0x3a/0x80 [ 2064.358259] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 2064.360745] [ 2064.361511] Last potentially related work creation: [ 2064.363957] kasan_save_stack+0x1c/0x40 [ 2064.365811] __kasan_record_aux_stack+0xaf/0xc0 [ 2064.368100] call_rcu+0x11b/0xf70 [ 2064.369785] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm] [ 2064.372404] receive_from_sock+0x290/0x770 [dlm] [ 2064.374607] process_recv_sockets+0x32/0x40 [dlm] [ 2064.377290] process_one_work+0x9a8/0x16e0 [ 2064.379357] worker_thread+0x87/0xbf0 [ 2064.381188] kthread+0x3ac/0x490 [ 2064.383460] ret_from_fork+0x22/0x30 [ 2064.385588] [ 2064.386518] Second to last potentially related work creation: [ 2064.389219] kasan_save_stack+0x1c/0x40 [ 2064.391043] __kasan_record_aux_stack+0xaf/0xc0 [ 2064.393303] call_rcu+0x11b/0xf70 [ 2064.394885] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm] [ 2064.397694] receive_from_sock+0x290/0x770 ---truncated--- CVE-2022-49407 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: fix bug_on in __es_tree_search Hulk Robot reported a BUG_ON: ================================================================== kernel BUG at fs/ext4/extents_status.c:199! [...] RIP: 0010:ext4_es_end fs/ext4/extents_status.c:199 [inline] RIP: 0010:__es_tree_search+0x1e0/0x260 fs/ext4/extents_status.c:217 [...] Call Trace: ext4_es_cache_extent+0x109/0x340 fs/ext4/extents_status.c:766 ext4_cache_extents+0x239/0x2e0 fs/ext4/extents.c:561 ext4_find_extent+0x6b7/0xa20 fs/ext4/extents.c:964 ext4_ext_map_blocks+0x16b/0x4b70 fs/ext4/extents.c:4384 ext4_map_blocks+0xe26/0x19f0 fs/ext4/inode.c:567 ext4_getblk+0x320/0x4c0 fs/ext4/inode.c:980 ext4_bread+0x2d/0x170 fs/ext4/inode.c:1031 ext4_quota_read+0x248/0x320 fs/ext4/super.c:6257 v2_read_header+0x78/0x110 fs/quota/quota_v2.c:63 v2_check_quota_file+0x76/0x230 fs/quota/quota_v2.c:82 vfs_load_quota_inode+0x5d1/0x1530 fs/quota/dquot.c:2368 dquot_enable+0x28a/0x330 fs/quota/dquot.c:2490 ext4_quota_enable fs/ext4/super.c:6137 [inline] ext4_enable_quotas+0x5d7/0x960 fs/ext4/super.c:6163 ext4_fill_super+0xa7c9/0xdc00 fs/ext4/super.c:4754 mount_bdev+0x2e9/0x3b0 fs/super.c:1158 mount_fs+0x4b/0x1e4 fs/super.c:1261 [...] ================================================================== Above issue may happen as follows: ------------------------------------- ext4_fill_super ext4_enable_quotas ext4_quota_enable ext4_iget __ext4_iget ext4_ext_check_inode ext4_ext_check __ext4_ext_check ext4_valid_extent_entries Check for overlapping extents does't take effect dquot_enable vfs_load_quota_inode v2_check_quota_file v2_read_header ext4_quota_read ext4_bread ext4_getblk ext4_map_blocks ext4_ext_map_blocks ext4_find_extent ext4_cache_extents ext4_es_cache_extent ext4_es_cache_extent __es_tree_search ext4_es_end BUG_ON(es->es_lblk + es->es_len < es->es_lblk) The error ext4 extents is as follows: 0af3 0300 0400 0000 00000000 extent_header 00000000 0100 0000 12000000 extent1 00000000 0100 0000 18000000 extent2 02000000 0400 0000 14000000 extent3 In the ext4_valid_extent_entries function, if prev is 0, no error is returned even if lblock<=prev. This was intended to skip the check on the first extent, but in the error image above, prev=0+1-1=0 when checking the second extent, so even though lblock<=prev, the function does not return an error. As a result, bug_ON occurs in __es_tree_search and the system panics. To solve this problem, we only need to check that: 1. The lblock of the first extent is not less than 0. 2. The lblock of the next extent is not less than the next block of the previous extent. The same applies to extent_idx. CVE-2022-49409 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: tracing: Fix potential double free in create_var_ref() In create_var_ref(), init_var_ref() is called to initialize the fields of variable ref_field, which is allocated in the previous function call to create_hist_field(). Function init_var_ref() allocates the corresponding fields such as ref_field->system, but frees these fields when the function encounters an error. The caller later calls destroy_hist_field() to conduct error handling, which frees the fields and the variable itself. This results in double free of the fields which are already freed in the previous function. Fix this by storing NULL to the corresponding fields when they are freed in init_var_ref(). CVE-2022-49410 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: bfq: Make sure bfqg for which we are queueing requests is online Bios queued into BFQ IO scheduler can be associated with a cgroup that was already offlined. This may then cause insertion of this bfq_group into a service tree. But this bfq_group will get freed as soon as last bio associated with it is completed leading to use after free issues for service tree users. Fix the problem by making sure we always operate on online bfq_group. If the bfq_group associated with the bio is not online, we pick the first online parent. CVE-2022-49411 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: bfq: Avoid merging queues with different parents It can happen that the parent of a bfqq changes between the moment we decide two queues are worth to merge (and set bic->stable_merge_bfqq) and the moment bfq_setup_merge() is called. This can happen e.g. because the process submitted IO for a different cgroup and thus bfqq got reparented. It can even happen that the bfqq we are merging with has parent cgroup that is already offline and going to be destroyed in which case the merge can lead to use-after-free issues such as: BUG: KASAN: use-after-free in __bfq_deactivate_entity+0x9cb/0xa50 Read of size 8 at addr ffff88800693c0c0 by task runc:[2:INIT]/10544 CPU: 0 PID: 10544 Comm: runc:[2:INIT] Tainted: G E 5.15.2-0.g5fb85fd-default #1 openSUSE Tumbleweed (unreleased) f1f3b891c72369aebecd2e43e4641a6358867c70 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014 Call Trace: <IRQ> dump_stack_lvl+0x46/0x5a print_address_description.constprop.0+0x1f/0x140 ? __bfq_deactivate_entity+0x9cb/0xa50 kasan_report.cold+0x7f/0x11b ? __bfq_deactivate_entity+0x9cb/0xa50 __bfq_deactivate_entity+0x9cb/0xa50 ? update_curr+0x32f/0x5d0 bfq_deactivate_entity+0xa0/0x1d0 bfq_del_bfqq_busy+0x28a/0x420 ? resched_curr+0x116/0x1d0 ? bfq_requeue_bfqq+0x70/0x70 ? check_preempt_wakeup+0x52b/0xbc0 __bfq_bfqq_expire+0x1a2/0x270 bfq_bfqq_expire+0xd16/0x2160 ? try_to_wake_up+0x4ee/0x1260 ? bfq_end_wr_async_queues+0xe0/0xe0 ? _raw_write_unlock_bh+0x60/0x60 ? _raw_spin_lock_irq+0x81/0xe0 bfq_idle_slice_timer+0x109/0x280 ? bfq_dispatch_request+0x4870/0x4870 __hrtimer_run_queues+0x37d/0x700 ? enqueue_hrtimer+0x1b0/0x1b0 ? kvm_clock_get_cycles+0xd/0x10 ? ktime_get_update_offsets_now+0x6f/0x280 hrtimer_interrupt+0x2c8/0x740 Fix the problem by checking that the parent of the two bfqqs we are merging in bfq_setup_merge() is the same. CVE-2022-49412 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: bfq: Update cgroup information before merging bio When the process is migrated to a different cgroup (or in case of writeback just starts submitting bios associated with a different cgroup) bfq_merge_bio() can operate with stale cgroup information in bic. Thus the bio can be merged to a request from a different cgroup or it can result in merging of bfqqs for different cgroups or bfqqs of already dead cgroups and causing possible use-after-free issues. Fix the problem by updating cgroup information in bfq_merge_bio(). CVE-2022-49413 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: ext4: fix race condition between ext4_write and ext4_convert_inline_data Hulk Robot reported a BUG_ON: ================================================================== EXT4-fs error (device loop3): ext4_mb_generate_buddy:805: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free clusters kernel BUG at fs/ext4/ext4_jbd2.c:53! invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 25371 Comm: syz-executor.3 Not tainted 5.10.0+ #1 RIP: 0010:ext4_put_nojournal fs/ext4/ext4_jbd2.c:53 [inline] RIP: 0010:__ext4_journal_stop+0x10e/0x110 fs/ext4/ext4_jbd2.c:116 [...] Call Trace: ext4_write_inline_data_end+0x59a/0x730 fs/ext4/inline.c:795 generic_perform_write+0x279/0x3c0 mm/filemap.c:3344 ext4_buffered_write_iter+0x2e3/0x3d0 fs/ext4/file.c:270 ext4_file_write_iter+0x30a/0x11c0 fs/ext4/file.c:520 do_iter_readv_writev+0x339/0x3c0 fs/read_write.c:732 do_iter_write+0x107/0x430 fs/read_write.c:861 vfs_writev fs/read_write.c:934 [inline] do_pwritev+0x1e5/0x380 fs/read_write.c:1031 [...] ================================================================== Above issue may happen as follows: cpu1 cpu2 __________________________|__________________________ do_pwritev vfs_writev do_iter_write ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin vfs_fallocate ext4_fallocate ext4_convert_inline_data ext4_convert_inline_data_nolock ext4_destroy_inline_data_nolock clear EXT4_STATE_MAY_INLINE_DATA ext4_map_blocks ext4_ext_map_blocks ext4_mb_new_blocks ext4_mb_regular_allocator ext4_mb_good_group_nolock ext4_mb_init_group ext4_mb_init_cache ext4_mb_generate_buddy --> error ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA) ext4_restore_inline_data set EXT4_STATE_MAY_INLINE_DATA ext4_block_write_begin ext4_da_write_end ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA) ext4_write_inline_data_end handle=NULL ext4_journal_stop(handle) __ext4_journal_stop ext4_put_nojournal(handle) ref_cnt = (unsigned long)handle BUG_ON(ref_cnt == 0) ---> BUG_ON The lock held by ext4_convert_inline_data is xattr_sem, but the lock held by generic_perform_write is i_rwsem. Therefore, the two locks can be concurrent. To solve above issue, we add inode_lock() for ext4_convert_inline_data(). At the same time, move ext4_convert_inline_data() in front of ext4_punch_hole(), remove similar handling from ext4_punch_hole(). CVE-2022-49414 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix use-after-free in chanctx code In ieee80211_vif_use_reserved_context(), when we have an old context and the new context's replace_state is set to IEEE80211_CHANCTX_REPLACE_NONE, we free the old context in ieee80211_vif_use_reserved_reassign(). Therefore, we cannot check the old_ctx anymore, so we should set it to NULL after this point. However, since the new_ctx replace state is clearly not IEEE80211_CHANCTX_REPLACES_OTHER, we're not going to do anything else in this function and can just return to avoid accessing the freed old_ctx. CVE-2022-49416 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: NFSv4: Fix free of uninitialized nfs4_label on referral lookup. Send along the already-allocated fattr along with nfs4_fs_locations, and drop the memcpy of fattr. We end up growing two more allocations, but this fixes up a crash as: PID: 790 TASK: ffff88811b43c000 CPU: 0 COMMAND: "ls" #0 [ffffc90000857920] panic at ffffffff81b9bfde #1 [ffffc900008579c0] do_trap at ffffffff81023a9b #2 [ffffc90000857a10] do_error_trap at ffffffff81023b78 #3 [ffffc90000857a58] exc_stack_segment at ffffffff81be1f45 #4 [ffffc90000857a80] asm_exc_stack_segment at ffffffff81c009de #5 [ffffc90000857b08] nfs_lookup at ffffffffa0302322 [nfs] #6 [ffffc90000857b70] __lookup_slow at ffffffff813a4a5f #7 [ffffc90000857c60] walk_component at ffffffff813a86c4 #8 [ffffc90000857cb8] path_lookupat at ffffffff813a9553 #9 [ffffc90000857cf0] filename_lookup at ffffffff813ab86b CVE-2022-49418 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: video: fbdev: clcdfb: Fix refcount leak in clcdfb_of_vram_setup of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. CVE-2022-49421 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Fix the error handling path in idxd_cdev_register() If a call to alloc_chrdev_region() fails, the already allocated resources are leaking. Add the needed error handling path to fix the leak. CVE-2022-49422 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: iommu/mediatek: Fix NULL pointer dereference when printing dev_name When larbdev is NULL (in the case I hit, the node is incorrectly set iommus = <&iommu NUM>), it will cause device_link_add() fail and kernel crashes when we try to print dev_name(larbdev). Let's fail the probe if a larbdev is NULL to avoid invalid inputs from dts. It should work for normal correct setting and avoid the crash caused by my incorrect setting. Error log: [ 18.189042][ T301] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 ... [ 18.344519][ T301] pstate: a0400005 (NzCv daif +PAN -UAO) [ 18.345213][ T301] pc : mtk_iommu_probe_device+0xf8/0x118 [mtk_iommu] [ 18.346050][ T301] lr : mtk_iommu_probe_device+0xd0/0x118 [mtk_iommu] [ 18.346884][ T301] sp : ffffffc00a5635e0 [ 18.347392][ T301] x29: ffffffc00a5635e0 x28: ffffffd44a46c1d8 [ 18.348156][ T301] x27: ffffff80c39a8000 x26: ffffffd44a80cc38 [ 18.348917][ T301] x25: 0000000000000000 x24: ffffffd44a80cc38 [ 18.349677][ T301] x23: ffffffd44e4da4c6 x22: ffffffd44a80cc38 [ 18.350438][ T301] x21: ffffff80cecd1880 x20: 0000000000000000 [ 18.351198][ T301] x19: ffffff80c439f010 x18: ffffffc00a50d0c0 [ 18.351959][ T301] x17: ffffffffffffffff x16: 0000000000000004 [ 18.352719][ T301] x15: 0000000000000004 x14: ffffffd44eb5d420 [ 18.353480][ T301] x13: 0000000000000ad2 x12: 0000000000000003 [ 18.354241][ T301] x11: 00000000fffffad2 x10: c0000000fffffad2 [ 18.355003][ T301] x9 : a0d288d8d7142d00 x8 : a0d288d8d7142d00 [ 18.355763][ T301] x7 : ffffffd44c2bc640 x6 : 0000000000000000 [ 18.356524][ T301] x5 : 0000000000000080 x4 : 0000000000000001 [ 18.357284][ T301] x3 : 0000000000000000 x2 : 0000000000000005 [ 18.358045][ T301] x1 : 0000000000000000 x0 : 0000000000000000 [ 18.360208][ T301] Hardware name: MT6873 (DT) [ 18.360771][ T301] Call trace: [ 18.361168][ T301] dump_backtrace+0xf8/0x1f0 [ 18.361737][ T301] dump_stack_lvl+0xa8/0x11c [ 18.362305][ T301] dump_stack+0x1c/0x2c [ 18.362816][ T301] mrdump_common_die+0x184/0x40c [mrdump] [ 18.363575][ T301] ipanic_die+0x24/0x38 [mrdump] [ 18.364230][ T301] atomic_notifier_call_chain+0x128/0x2b8 [ 18.364937][ T301] die+0x16c/0x568 [ 18.365394][ T301] __do_kernel_fault+0x1e8/0x214 [ 18.365402][ T301] do_page_fault+0xb8/0x678 [ 18.366934][ T301] do_translation_fault+0x48/0x64 [ 18.368645][ T301] do_mem_abort+0x68/0x148 [ 18.368652][ T301] el1_abort+0x40/0x64 [ 18.368660][ T301] el1h_64_sync_handler+0x54/0x88 [ 18.368668][ T301] el1h_64_sync+0x68/0x6c [ 18.368673][ T301] mtk_iommu_probe_device+0xf8/0x118 [mtk_iommu] ... CVE-2022-49424 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu-v3-sva: Fix mm use-after-free We currently call arm64_mm_context_put() without holding a reference to the mm, which can result in use-after-free. Call mmgrab()/mmdrop() to ensure the mm only gets freed after we unpinned the ASID. CVE-2022-49426 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: iommu/mediatek: Remove clk_disable in mtk_iommu_remove After the commit b34ea31fe013 ("iommu/mediatek: Always enable the clk on resume"), the iommu clock is controlled by the runtime callback. thus remove the clk control in the mtk_iommu_remove. Otherwise, it will warning like: echo 14018000.iommu > /sys/bus/platform/drivers/mtk-iommu/unbind [ 51.413044] ------------[ cut here ]------------ [ 51.413648] vpp0_smi_iommu already disabled [ 51.414233] WARNING: CPU: 2 PID: 157 at */v5.15-rc1/kernel/mediatek/ drivers/clk/clk.c:952 clk_core_disable+0xb0/0xb8 [ 51.417174] Hardware name: MT8195V/C(ENG) (DT) [ 51.418635] pc : clk_core_disable+0xb0/0xb8 [ 51.419177] lr : clk_core_disable+0xb0/0xb8 ... [ 51.429375] Call trace: [ 51.429694] clk_core_disable+0xb0/0xb8 [ 51.430193] clk_core_disable_lock+0x24/0x40 [ 51.430745] clk_disable+0x20/0x30 [ 51.431189] mtk_iommu_remove+0x58/0x118 [ 51.431705] platform_remove+0x28/0x60 [ 51.432197] device_release_driver_internal+0x110/0x1f0 [ 51.432873] device_driver_detach+0x18/0x28 [ 51.433418] unbind_store+0xd4/0x108 [ 51.433886] drv_attr_store+0x24/0x38 [ 51.434363] sysfs_kf_write+0x40/0x58 [ 51.434843] kernfs_fop_write_iter+0x164/0x1e0 CVE-2022-49427 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Prevent panic when SDMA is disabled If the hfi1 module is loaded with HFI1_CAP_SDMA off, a call to hfi1_write_iter() will dereference a NULL pointer and panic. A typical stack frame is: sdma_select_user_engine [hfi1] hfi1_user_sdma_process_request [hfi1] hfi1_write_iter [hfi1] do_iter_readv_writev do_iter_write vfs_writev do_writev do_syscall_64 The fix is to test for SDMA in hfi1_write_iter() and fail the I/O with EINVAL. CVE-2022-49429 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: Input: gpio-keys - cancel delayed work only in case of GPIO gpio_keys module can either accept gpios or interrupts. The module initializes delayed work in case of gpios only and is only used if debounce timer is not used, so make sure cancel_delayed_work_sync() is called only when its gpio-backed and debounce_use_hrtimer is false. This fixes the issue seen below when the gpio_keys module is unloaded and an interrupt pin is used instead of GPIO: [ 360.297569] ------------[ cut here ]------------ [ 360.302303] WARNING: CPU: 0 PID: 237 at kernel/workqueue.c:3066 __flush_work+0x414/0x470 [ 360.310531] Modules linked in: gpio_keys(-) [ 360.314797] CPU: 0 PID: 237 Comm: rmmod Not tainted 5.18.0-rc5-arm64-renesas-00116-g73636105874d-dirty #166 [ 360.324662] Hardware name: Renesas SMARC EVK based on r9a07g054l2 (DT) [ 360.331270] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 360.338318] pc : __flush_work+0x414/0x470 [ 360.342385] lr : __cancel_work_timer+0x140/0x1b0 [ 360.347065] sp : ffff80000a7fba00 [ 360.350423] x29: ffff80000a7fba00 x28: ffff000012b9c5c0 x27: 0000000000000000 [ 360.357664] x26: ffff80000a7fbb80 x25: ffff80000954d0a8 x24: 0000000000000001 [ 360.364904] x23: ffff800009757000 x22: 0000000000000000 x21: ffff80000919b000 [ 360.372143] x20: ffff00000f5974e0 x19: ffff00000f5974e0 x18: ffff8000097fcf48 [ 360.379382] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000053f40 [ 360.386622] x14: ffff800009850e88 x13: 0000000000000002 x12: 000000000000a60c [ 360.393861] x11: 000000000000a610 x10: 0000000000000000 x9 : 0000000000000008 [ 360.401100] x8 : 0101010101010101 x7 : 00000000a473c394 x6 : 0080808080808080 [ 360.408339] x5 : 0000000000000001 x4 : 0000000000000000 x3 : ffff80000919b458 [ 360.415578] x2 : ffff8000097577f0 x1 : 0000000000000001 x0 : 0000000000000000 [ 360.422818] Call trace: [ 360.425299] __flush_work+0x414/0x470 [ 360.429012] __cancel_work_timer+0x140/0x1b0 [ 360.433340] cancel_delayed_work_sync+0x10/0x18 [ 360.437931] gpio_keys_quiesce_key+0x28/0x58 [gpio_keys] [ 360.443327] devm_action_release+0x10/0x18 [ 360.447481] release_nodes+0x8c/0x1a0 [ 360.451194] devres_release_all+0x90/0x100 [ 360.455346] device_unbind_cleanup+0x14/0x60 [ 360.459677] device_release_driver_internal+0xe8/0x168 [ 360.464883] driver_detach+0x4c/0x90 [ 360.468509] bus_remove_driver+0x54/0xb0 [ 360.472485] driver_unregister+0x2c/0x58 [ 360.476462] platform_driver_unregister+0x10/0x18 [ 360.481230] gpio_keys_exit+0x14/0x828 [gpio_keys] [ 360.486088] __arm64_sys_delete_module+0x1e0/0x270 [ 360.490945] invoke_syscall+0x40/0xf8 [ 360.494661] el0_svc_common.constprop.3+0xf0/0x110 [ 360.499515] do_el0_svc+0x20/0x78 [ 360.502877] el0_svc+0x48/0xf8 [ 360.505977] el0t_64_sync_handler+0x88/0xb0 [ 360.510216] el0t_64_sync+0x148/0x14c [ 360.513930] irq event stamp: 4306 [ 360.517288] hardirqs last enabled at (4305): [<ffff8000080b0300>] __cancel_work_timer+0x130/0x1b0 [ 360.526359] hardirqs last disabled at (4306): [<ffff800008d194fc>] el1_dbg+0x24/0x88 [ 360.534204] softirqs last enabled at (4278): [<ffff8000080104a0>] _stext+0x4a0/0x5e0 [ 360.542133] softirqs last disabled at (4267): [<ffff8000080932ac>] irq_exit_rcu+0x18c/0x1b0 [ 360.550591] ---[ end trace 0000000000000000 ]--- CVE-2022-49430 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: powerpc/iommu: Add missing of_node_put in iommu_init_early_dart The device_node pointer is returned by of_find_compatible_node with refcount incremented. We should use of_node_put() to avoid the refcount leak. CVE-2022-49431 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: powerpc/xics: fix refcount leak in icp_opal_init() The of_find_compatible_node() function returns a node pointer with refcount incremented, use of_node_put() on it when done. CVE-2022-49432 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Prevent use of lock before it is initialized If there is a failure during probe of hfi1 before the sdma_map_lock is initialized, the call to hfi1_free_devdata() will attempt to use a lock that has not been initialized. If the locking correctness validator is on then an INFO message and stack trace resembling the following may be seen: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. Call Trace: register_lock_class+0x11b/0x880 __lock_acquire+0xf3/0x7930 lock_acquire+0xff/0x2d0 _raw_spin_lock_irq+0x46/0x60 sdma_clean+0x42a/0x660 [hfi1] hfi1_free_devdata+0x3a7/0x420 [hfi1] init_one+0x867/0x11a0 [hfi1] pci_device_probe+0x40e/0x8d0 The use of sdma_map_lock in sdma_clean() is for freeing the sdma_map memory, and sdma_map is not allocated/initialized until after sdma_map_lock has been initialized. This code only needs to be run if sdma_map is not NULL, and so checking for that condition will avoid trying to use the lock before it is initialized. CVE-2022-49433 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: PCI: Avoid pci_dev_lock() AB/BA deadlock with sriov_numvfs_store() The sysfs sriov_numvfs_store() path acquires the device lock before the config space access lock: sriov_numvfs_store device_lock # A (1) acquire device lock sriov_configure vfio_pci_sriov_configure # (for example) vfio_pci_core_sriov_configure pci_disable_sriov sriov_disable pci_cfg_access_lock pci_wait_cfg # B (4) wait for dev->block_cfg_access == 0 Previously, pci_dev_lock() acquired the config space access lock before the device lock: pci_dev_lock pci_cfg_access_lock dev->block_cfg_access = 1 # B (2) set dev->block_cfg_access = 1 device_lock # A (3) wait for device lock Any path that uses pci_dev_lock(), e.g., pci_reset_function(), may deadlock with sriov_numvfs_store() if the operations occur in the sequence (1) (2) (3) (4). Avoid the deadlock by reversing the order in pci_dev_lock() so it acquires the device lock before the config space access lock, the same as the sriov_numvfs_store() path. [bhelgaas: combined and adapted commit log from Jay Zhou's independent subsequent posting: https://lore.kernel.org/r/20220404062539.1710-1-jianjay.zhou@huawei.com] CVE-2022-49434 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: mfd: davinci_voicecodec: Fix possible null-ptr-deref davinci_vc_probe() It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code. CVE-2022-49435 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: powerpc/xive: Fix refcount leak in xive_spapr_init of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. CVE-2022-49437 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: Input: sparcspkr - fix refcount leak in bbc_beep_probe of_find_node_by_path() calls of_find_node_opts_by_path(), which returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. CVE-2022-49438 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: powerpc/rtas: Keep MSR[RI] set when calling RTAS RTAS runs in real mode (MSR[DR] and MSR[IR] unset) and in 32-bit big endian mode (MSR[SF,LE] unset). The change in MSR is done in enter_rtas() in a relatively complex way, since the MSR value could be hardcoded. Furthermore, a panic has been reported when hitting the watchdog interrupt while running in RTAS, this leads to the following stack trace: watchdog: CPU 24 Hard LOCKUP watchdog: CPU 24 TB:997512652051031, last heartbeat TB:997504470175378 (15980ms ago) ... Supported: No, Unreleased kernel CPU: 24 PID: 87504 Comm: drmgr Kdump: loaded Tainted: G E X 5.14.21-150400.71.1.bz196362_2-default #1 SLE15-SP4 (unreleased) 0d821077ef4faa8dfaf370efb5fdca1fa35f4e2c NIP: 000000001fb41050 LR: 000000001fb4104c CTR: 0000000000000000 REGS: c00000000fc33d60 TRAP: 0100 Tainted: G E X (5.14.21-150400.71.1.bz196362_2-default) MSR: 8000000002981000 <SF,VEC,VSX,ME> CR: 48800002 XER: 20040020 CFAR: 000000000000011c IRQMASK: 1 GPR00: 0000000000000003 ffffffffffffffff 0000000000000001 00000000000050dc GPR04: 000000001ffb6100 0000000000000020 0000000000000001 000000001fb09010 GPR08: 0000000020000000 0000000000000000 0000000000000000 0000000000000000 GPR12: 80040000072a40a8 c00000000ff8b680 0000000000000007 0000000000000034 GPR16: 000000001fbf6e94 000000001fbf6d84 000000001fbd1db0 000000001fb3f008 GPR20: 000000001fb41018 ffffffffffffffff 000000000000017f fffffffffffff68f GPR24: 000000001fb18fe8 000000001fb3e000 000000001fb1adc0 000000001fb1cf40 GPR28: 000000001fb26000 000000001fb460f0 000000001fb17f18 000000001fb17000 NIP [000000001fb41050] 0x1fb41050 LR [000000001fb4104c] 0x1fb4104c Call Trace: Instruction dump: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX Oops: Unrecoverable System Reset, sig: 6 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries ... Supported: No, Unreleased kernel CPU: 24 PID: 87504 Comm: drmgr Kdump: loaded Tainted: G E X 5.14.21-150400.71.1.bz196362_2-default #1 SLE15-SP4 (unreleased) 0d821077ef4faa8dfaf370efb5fdca1fa35f4e2c NIP: 000000001fb41050 LR: 000000001fb4104c CTR: 0000000000000000 REGS: c00000000fc33d60 TRAP: 0100 Tainted: G E X (5.14.21-150400.71.1.bz196362_2-default) MSR: 8000000002981000 <SF,VEC,VSX,ME> CR: 48800002 XER: 20040020 CFAR: 000000000000011c IRQMASK: 1 GPR00: 0000000000000003 ffffffffffffffff 0000000000000001 00000000000050dc GPR04: 000000001ffb6100 0000000000000020 0000000000000001 000000001fb09010 GPR08: 0000000020000000 0000000000000000 0000000000000000 0000000000000000 GPR12: 80040000072a40a8 c00000000ff8b680 0000000000000007 0000000000000034 GPR16: 000000001fbf6e94 000000001fbf6d84 000000001fbd1db0 000000001fb3f008 GPR20: 000000001fb41018 ffffffffffffffff 000000000000017f fffffffffffff68f GPR24: 000000001fb18fe8 000000001fb3e000 000000001fb1adc0 000000001fb1cf40 GPR28: 000000001fb26000 000000001fb460f0 000000001fb17f18 000000001fb17000 NIP [000000001fb41050] 0x1fb41050 LR [000000001fb4104c] 0x1fb4104c Call Trace: Instruction dump: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ---[ end trace 3ddec07f638c34a2 ]--- This happens because MSR[RI] is unset when entering RTAS but there is no valid reason to not set it here. RTAS is expected to be called with MSR[RI] as specified in PAPR+ section "7.2.1 Machine State": R1-7.2.1-9. If called with MSR[RI] equal to 1, then RTAS must protect its own critical regions from recursion by setting the MSR[RI] bit to 0 when in the critical regions. Fixing this by reviewing the way MSR is compute before calling RTAS. Now a hardcoded value meaning real ---truncated--- CVE-2022-49440 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: tty: fix deadlock caused by calling printk() under tty_port->lock pty_write() invokes kmalloc() which may invoke a normal printk() to print failure message. This can cause a deadlock in the scenario reported by syz-bot below: CPU0 CPU1 CPU2 ---- ---- ---- lock(console_owner); lock(&port_lock_key); lock(&port->lock); lock(&port_lock_key); lock(&port->lock); lock(console_owner); As commit dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes") said, such deadlock can be prevented by using printk_deferred() in kmalloc() (which is invoked in the section guarded by the port->lock). But there are too many printk() on the kmalloc() path, and kmalloc() can be called from anywhere, so changing printk() to printk_deferred() is too complicated and inelegant. Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so that printk() will not be called, and this deadlock problem can be avoided. Syzbot reported the following lockdep error: ====================================================== WARNING: possible circular locking dependency detected 5.4.143-00237-g08ccc19a-dirty #10 Not tainted ------------------------------------------------------ syz-executor.4/29420 is trying to acquire lock: ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline] ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023 but task is already holding lock: ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&port->lock){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock); tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47 serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767 serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854 serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key); serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870 serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126 __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156 [...] -> #1 (&port_lock_key){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198 <-- lock(&port_lock_key); call_console_drivers kernel/printk/printk.c:1819 [inline] console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504 vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner); vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 register_console+0x8b3/0xc10 kernel/printk/printk.c:2829 univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681 console_init+0x49d/0x6d3 kernel/printk/printk.c:2915 start_kernel+0x5e9/0x879 init/main.c:713 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241 -> #0 (console_owner){....}-{0:0}: [...] lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734 console_trylock_spinning kernel/printk/printk.c:1773 ---truncated--- CVE-2022-49441 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drivers/base/node.c: fix compaction sysfs file leak Compaction sysfs file is created via compaction_register_node in register_node. But we forgot to remove it in unregister_node. Thus compaction sysfs file is leaked. Using compaction_unregister_node to fix this issue. CVE-2022-49442 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: list: fix a data-race around ep->rdllist ep_poll() first calls ep_events_available() with no lock held and checks if ep->rdllist is empty by list_empty_careful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing. Note INIT_LIST_HEAD_RCU() already has the annotation for both prev and next. Commit bf3b9f6372c4 ("epoll: Add busy poll support to epoll with socket fds.") added the first lockless ep_events_available(), and commit c5a282e9635e ("fs/epoll: reduce the scope of wq lock in epoll_wait()") made some ep_events_available() calls lockless and added single call under a lock, finally commit e59d3c64cba6 ("epoll: eliminate unnecessary lock for zero timeout") made the last ep_events_available() lockless. BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0xffff88810480c7d0 -> 0xffff888103c15098 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 CVE-2022-49443 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: module: fix [e_shstrndx].sh_size=0 OOB access It is trivial to craft a module to trigger OOB access in this line: if (info->secstrings[strhdr->sh_size - 1] != '\0') { BUG: unable to handle page fault for address: ffffc90000aa0fff PGD 100000067 P4D 100000067 PUD 100066067 PMD 10436f067 PTE 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 7 PID: 1215 Comm: insmod Not tainted 5.18.0-rc5-00007-g9bf578647087-dirty #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014 RIP: 0010:load_module+0x19b/0x2391 [rebased patch onto modules-next] CVE-2022-49444 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: pinctrl: renesas: core: Fix possible null-ptr-deref in sh_pfc_map_resources() It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code. CVE-2022-49445 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ARM: hisi: Add missing of_node_put after of_find_compatible_node of_find_compatible_node will increment the refcount of the returned device_node. Calling of_node_put() to avoid the refcount leak CVE-2022-49447 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: soc: bcm: Check for NULL return of devm_kzalloc() As the potential failure of allocation, devm_kzalloc() may return NULL. Then the 'pd->pmb' and the follow lines of code may bring null pointer dereference. Therefore, it is better to check the return value of devm_kzalloc() to avoid this confusion. CVE-2022-49448 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: pinctrl: renesas: rzn1: Fix possible null-ptr-deref in sh_pfc_map_resources() It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code. CVE-2022-49449 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix list protocols enumeration in the base protocol While enumerating protocols implemented by the SCMI platform using BASE_DISCOVER_LIST_PROTOCOLS, the number of returned protocols is currently validated in an improper way since the check employs a sum between unsigned integers that could overflow and cause the check itself to be silently bypassed if the returned value 'loop_num_ret' is big enough. Fix the validation avoiding the addition. CVE-2022-49451 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: soc: ti: ti_sci_pm_domains: Check for null return of devm_kcalloc The allocation funciton devm_kcalloc may fail and return a null pointer, which would cause a null-pointer dereference later. It might be better to check it and directly return -ENOMEM just like the usage of devm_kcalloc in previous code. CVE-2022-49453 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: misc: ocxl: fix possible double free in ocxl_file_register_afu info_release() will be called in device_unregister() when info->dev's reference count is 0. So there is no need to call ocxl_afu_put() and kfree() again. Fix this by adding free_minor() and return to err_unregister error path. CVE-2022-49455 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/broadcom: Fix potential NULL dereference in sr_thermal_probe platform_get_resource() may return NULL, add proper check to avoid potential NULL dereferencing. CVE-2022-49459 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: rk3399_dmc: Disable edev on remove() Otherwise we hit an unablanced enable-count when unbinding the DFI device: [ 1279.659119] ------------[ cut here ]------------ [ 1279.659179] WARNING: CPU: 2 PID: 5638 at drivers/devfreq/devfreq-event.c:360 devfreq_event_remove_edev+0x84/0x8c ... [ 1279.659352] Hardware name: Google Kevin (DT) [ 1279.659363] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO BTYPE=--) [ 1279.659371] pc : devfreq_event_remove_edev+0x84/0x8c [ 1279.659380] lr : devm_devfreq_event_release+0x1c/0x28 ... [ 1279.659571] Call trace: [ 1279.659582] devfreq_event_remove_edev+0x84/0x8c [ 1279.659590] devm_devfreq_event_release+0x1c/0x28 [ 1279.659602] release_nodes+0x1cc/0x244 [ 1279.659611] devres_release_all+0x44/0x60 [ 1279.659621] device_release_driver_internal+0x11c/0x1ac [ 1279.659629] device_driver_detach+0x20/0x2c [ 1279.659641] unbind_store+0x7c/0xb0 [ 1279.659650] drv_attr_store+0x2c/0x40 [ 1279.659663] sysfs_kf_write+0x44/0x58 [ 1279.659672] kernfs_fop_write_iter+0xf4/0x190 [ 1279.659684] vfs_write+0x2b0/0x2e4 [ 1279.659693] ksys_write+0x80/0xec [ 1279.659701] __arm64_sys_write+0x24/0x30 [ 1279.659714] el0_svc_common+0xf0/0x1d8 [ 1279.659724] do_el0_svc_compat+0x28/0x3c [ 1279.659738] el0_svc_compat+0x10/0x1c [ 1279.659746] el0_sync_compat_handler+0xa8/0xcc [ 1279.659758] el0_sync_compat+0x188/0x1c0 [ 1279.659768] ---[ end trace cec200e5094155b4 ]--- CVE-2022-49460 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/msm/a6xx: Fix refcount leak in a6xx_gpu_init of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. a6xx_gmu_init() passes the node to of_find_device_by_node() and of_dma_configure(), of_find_device_by_node() will takes its reference, of_dma_configure() doesn't need the node after usage. Add missing of_node_put() to avoid refcount leak. CVE-2022-49462 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/imx_sc_thermal: Fix refcount leak in imx_sc_thermal_probe of_find_node_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. CVE-2022-49463 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: blk-throttle: Set BIO_THROTTLED when bio has been throttled 1.In current process, all bio will set the BIO_THROTTLED flag after __blk_throtl_bio(). 2.If bio needs to be throttled, it will start the timer and stop submit bio directly. Bio will submit in blk_throtl_dispatch_work_fn() when the timer expires.But in the current process, if bio is throttled. The BIO_THROTTLED will be set to bio after timer start. If the bio has been completed, it may cause use-after-free blow. BUG: KASAN: use-after-free in blk_throtl_bio+0x12f0/0x2c70 Read of size 2 at addr ffff88801b8902d4 by task fio/26380 dump_stack+0x9b/0xce print_address_description.constprop.6+0x3e/0x60 kasan_report.cold.9+0x22/0x3a blk_throtl_bio+0x12f0/0x2c70 submit_bio_checks+0x701/0x1550 submit_bio_noacct+0x83/0xc80 submit_bio+0xa7/0x330 mpage_readahead+0x380/0x500 read_pages+0x1c1/0xbf0 page_cache_ra_unbounded+0x471/0x6f0 do_page_cache_ra+0xda/0x110 ondemand_readahead+0x442/0xae0 page_cache_async_ra+0x210/0x300 generic_file_buffered_read+0x4d9/0x2130 generic_file_read_iter+0x315/0x490 blkdev_read_iter+0x113/0x1b0 aio_read+0x2ad/0x450 io_submit_one+0xc8e/0x1d60 __se_sys_io_submit+0x125/0x350 do_syscall_64+0x2d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Allocated by task 26380: kasan_save_stack+0x19/0x40 __kasan_kmalloc.constprop.2+0xc1/0xd0 kmem_cache_alloc+0x146/0x440 mempool_alloc+0x125/0x2f0 bio_alloc_bioset+0x353/0x590 mpage_alloc+0x3b/0x240 do_mpage_readpage+0xddf/0x1ef0 mpage_readahead+0x264/0x500 read_pages+0x1c1/0xbf0 page_cache_ra_unbounded+0x471/0x6f0 do_page_cache_ra+0xda/0x110 ondemand_readahead+0x442/0xae0 page_cache_async_ra+0x210/0x300 generic_file_buffered_read+0x4d9/0x2130 generic_file_read_iter+0x315/0x490 blkdev_read_iter+0x113/0x1b0 aio_read+0x2ad/0x450 io_submit_one+0xc8e/0x1d60 __se_sys_io_submit+0x125/0x350 do_syscall_64+0x2d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 0: kasan_save_stack+0x19/0x40 kasan_set_track+0x1c/0x30 kasan_set_free_info+0x1b/0x30 __kasan_slab_free+0x111/0x160 kmem_cache_free+0x94/0x460 mempool_free+0xd6/0x320 bio_free+0xe0/0x130 bio_put+0xab/0xe0 bio_endio+0x3a6/0x5d0 blk_update_request+0x590/0x1370 scsi_end_request+0x7d/0x400 scsi_io_completion+0x1aa/0xe50 scsi_softirq_done+0x11b/0x240 blk_mq_complete_request+0xd4/0x120 scsi_mq_done+0xf0/0x200 virtscsi_vq_done+0xbc/0x150 vring_interrupt+0x179/0x390 __handle_irq_event_percpu+0xf7/0x490 handle_irq_event_percpu+0x7b/0x160 handle_irq_event+0xcc/0x170 handle_edge_irq+0x215/0xb20 common_interrupt+0x60/0x120 asm_common_interrupt+0x1e/0x40 Fix this by move BIO_THROTTLED set into the queue_lock. CVE-2022-49465 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: regulator: scmi: Fix refcount leak in scmi_regulator_probe of_find_node_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. CVE-2022-49466 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm: msm: fix possible memory leak in mdp5_crtc_cursor_set() drm_gem_object_lookup will call drm_gem_object_get inside. So cursor_bo needs to be put when msm_gem_get_and_pin_iova fails. CVE-2022-49467 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: thermal/core: Fix memory leak in __thermal_cooling_device_register() I got memory leak as follows when doing fault injection test: unreferenced object 0xffff888010080000 (size 264312): comm "182", pid 102533, jiffies 4296434960 (age 10.100s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 40 7f 1f b9 ff ff ff ff ........@....... backtrace: [<0000000038b2f4fc>] kmalloc_order_trace+0x1d/0x110 mm/slab_common.c:969 [<00000000ebcb8da5>] __kmalloc+0x373/0x420 include/linux/slab.h:510 [<0000000084137f13>] thermal_cooling_device_setup_sysfs+0x15d/0x2d0 include/linux/slab.h:586 [<00000000352b8755>] __thermal_cooling_device_register+0x332/0xa60 drivers/thermal/thermal_core.c:927 [<00000000fb9f331b>] devm_thermal_of_cooling_device_register+0x6b/0xf0 drivers/thermal/thermal_core.c:1041 [<000000009b8012d2>] max6650_probe.cold+0x557/0x6aa drivers/hwmon/max6650.c:211 [<00000000da0b7e04>] i2c_device_probe+0x472/0xac0 drivers/i2c/i2c-core-base.c:561 If device_register() fails, thermal_cooling_device_destroy_sysfs() need be called to free the memory allocated in thermal_cooling_device_setup_sysfs(). CVE-2022-49468 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 low In the Linux kernel, the following vulnerability has been resolved: net: phy: micrel: Allow probing without .driver_data Currently, if the .probe element is present in the phy_driver structure and the .driver_data is not, a NULL pointer dereference happens. Allow passing .probe without .driver_data by inserting NULL checks for priv->type. CVE-2022-49472 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: ti: j721e-evm: Fix refcount leak in j721e_soc_probe_* of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak. CVE-2022-49473 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix dangling sco_conn and use-after-free in sco_sock_timeout Connecting the same socket twice consecutively in sco_sock_connect() could lead to a race condition where two sco_conn objects are created but only one is associated with the socket. If the socket is closed before the SCO connection is established, the timer associated with the dangling sco_conn object won't be canceled. As the sock object is being freed, the use-after-free problem happens when the timer callback function sco_sock_timeout() accesses the socket. Here's the call trace: dump_stack+0x107/0x163 ? refcount_inc+0x1c/ print_address_description.constprop.0+0x1c/0x47e ? refcount_inc+0x1c/0x7b kasan_report+0x13a/0x173 ? refcount_inc+0x1c/0x7b check_memory_region+0x132/0x139 refcount_inc+0x1c/0x7b sco_sock_timeout+0xb2/0x1ba process_one_work+0x739/0xbd1 ? cancel_delayed_work+0x13f/0x13f ? __raw_spin_lock_init+0xf0/0xf0 ? to_kthread+0x59/0x85 worker_thread+0x593/0x70e kthread+0x346/0x35a ? drain_workqueue+0x31a/0x31a ? kthread_bind+0x4b/0x4b ret_from_fork+0x1f/0x30 CVE-2022-49474 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-qspi: check return value after calling platform_get_resource_byname() It will cause null-ptr-deref if platform_get_resource_byname() returns NULL, we need check the return value. CVE-2022-49475 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: samsung: Fix refcount leak in aries_audio_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. If extcon_find_edev_by_node() fails, it doesn't call of_node_put() Calling of_node_put() after extcon_find_edev_by_node() to fix this. CVE-2022-49477 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix array-index-out-of-bounds in pvr2_i2c_core_init Syzbot reported that -1 is used as array index. The problem was in missing validation check. hdw->unit_number is initialized with -1 and then if init table walk fails this value remains unchanged. Since code blindly uses this member for array indexing adding sanity check is the easiest fix for that. hdw->workpoll initialization moved upper to prevent warning in __flush_work. CVE-2022-49478 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: imx-hdmi: Fix refcount leak in imx_hdmi_probe of_find_device_by_node() takes reference, we should use put_device() to release it. when devm_kzalloc() fails, it doesn't have a put_device(), it will cause refcount leak. Add missing put_device() to fix this. CVE-2022-49480 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: regulator: pfuze100: Fix refcount leak in pfuze_parse_regulators_dt of_node_get() returns a node with refcount incremented. Calling of_node_put() to drop the reference when not needed anymore. CVE-2022-49481 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: mxs-saif: Fix refcount leak in mxs_saif_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. CVE-2022-49482 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl: Fix refcount leak in imx_sgtl5000_probe of_find_i2c_device_by_node() takes a reference, In error paths, we should call put_device() to drop the reference to aviod refount leak. CVE-2022-49486 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: intel: fix possible null-ptr-deref in ebu_nand_probe() It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. CVE-2022-49487 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp5: Return error code in mdp5_mixer_release when deadlock is detected There is a possibility for mdp5_get_global_state to return -EDEADLK when acquiring the modeset lock, but currently global_state in mdp5_mixer_release doesn't check for if an error is returned. To avoid a NULL dereference error, let's have mdp5_mixer_release check if an error is returned and propagate that error. Patchwork: https://patchwork.freedesktop.org/patch/485181/ CVE-2022-49488 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/msm/disp/dpu1: set vbif hw config to NULL to avoid use after memory free during pm runtime resume BUG: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6be3 Call trace: dpu_vbif_init_memtypes+0x40/0xb8 dpu_runtime_resume+0xcc/0x1c0 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x134/0x258 __rpm_callback+0x98/0x138 rpm_callback+0x30/0x88 rpm_resume+0x36c/0x49c __pm_runtime_resume+0x80/0xb0 dpu_core_irq_uninstall+0x30/0xb0 dpu_irq_uninstall+0x18/0x24 msm_drm_uninit+0xd8/0x16c Patchwork: https://patchwork.freedesktop.org/patch/483255/ [DB: fixed Fixes tag] CVE-2022-49489 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp5: Return error code in mdp5_pipe_release when deadlock is detected mdp5_get_global_state runs the risk of hitting a -EDEADLK when acquiring the modeset lock, but currently mdp5_pipe_release doesn't check for if an error is returned. Because of this, there is a possibility of mdp5_pipe_release hitting a NULL dereference error. To avoid this, let's have mdp5_pipe_release check if mdp5_get_global_state returns an error and propogate that error. Changes since v1: - Separated declaration and initialization of *new_state to avoid compiler warning - Fixed some spelling mistakes in commit message Changes since v2: - Return 0 in case where hwpipe is NULL as this is considered normal behavior - Added 2nd patch in series to fix a similar NULL dereference issue in mdp5_mixer_release Patchwork: https://patchwork.freedesktop.org/patch/485179/ CVE-2022-49490 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: fix possible null-ptr-deref in vop_bind() It will cause null-ptr-deref in resource_size(), if platform_get_resource() returns NULL, move calling resource_size() after devm_ioremap_resource() that will check 'res' to avoid null-ptr-deref. CVE-2022-49491 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: nvme-pci: fix a NULL pointer dereference in nvme_alloc_admin_tags In nvme_alloc_admin_tags, the admin_q can be set to an error (typically -ENOMEM) if the blk_mq_init_queue call fails to set up the queue, which is checked immediately after the call. However, when we return the error message up the stack, to nvme_reset_work the error takes us to nvme_remove_dead_ctrl() nvme_dev_disable() nvme_suspend_queue(&dev->queues[0]). Here, we only check that the admin_q is non-NULL, rather than not an error or NULL, and begin quiescing a queue that never existed, leading to bad / NULL pointer dereference. CVE-2022-49492 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: rt5645: Fix errorenous cleanup order There is a logic error when removing rt5645 device as the function rt5645_i2c_remove() first cancel the &rt5645->jack_detect_work and delete the &rt5645->btn_check_timer latter. However, since the timer handler rt5645_btn_check_callback() will re-queue the jack_detect_work, this cleanup order is buggy. That is, once the del_timer_sync in rt5645_i2c_remove is concurrently run with the rt5645_btn_check_callback, the canceled jack_detect_work will be rescheduled again, leading to possible use-after-free. This patch fix the issue by placing the del_timer_sync function before the cancel_delayed_work_sync. CVE-2022-49493 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix possible null-ptr-deref in cadence_nand_dt_probe() It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code. CVE-2022-49494 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/msm/hdmi: check return value after calling platform_get_resource_byname() It will cause null-ptr-deref if platform_get_resource_byname() returns NULL, we need check the return value. Patchwork: https://patchwork.freedesktop.org/patch/482992/ CVE-2022-49495 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Check for null pointer of pointer substream before dereferencing it Pointer substream is being dereferenced on the assignment of pointer card before substream is being null checked with the macro PCM_RUNTIME_CHECK. Although PCM_RUNTIME_CHECK calls BUG_ON, it still is useful to perform the the pointer check before card is assigned. CVE-2022-49498 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: usbnet: Run unregister_netdev() before unbind() again Commit 2c9d6c2b871d ("usbnet: run unbind() before unregister_netdev()") sought to fix a use-after-free on disconnect of USB Ethernet adapters. It turns out that a different fix is necessary to address the issue: https://lore.kernel.org/netdev/18b3541e5372bc9b9fc733d422f4e698c089077c.1650177997.git.lukas@wunner.de/ So the commit was not necessary. The commit made binding and unbinding of USB Ethernet asymmetrical: Before, usbnet_probe() first invoked the ->bind() callback and then register_netdev(). usbnet_disconnect() mirrored that by first invoking unregister_netdev() and then ->unbind(). Since the commit, the order in usbnet_disconnect() is reversed and no longer mirrors usbnet_probe(). One consequence is that a PHY disconnected (and stopped) in ->unbind() is afterwards stopped once more by unregister_netdev() as it closes the netdev before unregistering. That necessitates a contortion in ->stop() because the PHY may only be stopped if it hasn't already been disconnected. Reverting the commit allows making the call to phy_stop() unconditional in ->stop(). CVE-2022-49501 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: rga: fix possible memory leak in rga_probe rga->m2m_dev needs to be freed when rga_probe fails. CVE-2022-49502 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 low In the Linux kernel, the following vulnerability has been resolved: ath9k_htc: fix potential out of bounds access with invalid rxstatus->rs_keyix The "rxstatus->rs_keyix" eventually gets passed to test_bit() so we need to ensure that it is within the bitmap. drivers/net/wireless/ath/ath9k/common.c:46 ath9k_cmn_rx_accept() error: passing untrusted data 'rx_stats->rs_keyix' to 'test_bit()' CVE-2022-49503 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Inhibit aborts if external loopback plug is inserted After running a short external loopback test, when the external loopback is removed and a normal cable inserted that is directly connected to a target device, the system oops in the llpfc_set_rrq_active() routine. When the loopback was inserted an FLOGI was transmit. As we're looped back, we receive the FLOGI request. The FLOGI is ABTS'd as we recognize the same wppn thus understand it's a loopback. However, as the ABTS sends address information the port is not set to (fffffe), the ABTS is dropped on the wire. A short 1 frame loopback test is run and completes before the ABTS times out. The looback is unplugged and the new cable plugged in, and the an FLOGI to the new device occurs and completes. Due to a mixup in ref counting the completion of the new FLOGI releases the fabric ndlp. Then the original ABTS completes and references the released ndlp generating the oops. Correct by no-op'ing the ABTS when in loopback mode (it will be dropped anyway). Added a flag to track the mode to recognize when it should be no-op'd. CVE-2022-49504 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: NFC: NULL out the dev->rfkill to prevent UAF Commit 3e3b5dfcd16a ("NFC: reorder the logic in nfc_{un,}register_device") assumes the device_is_registered() in function nfc_dev_up() will help to check when the rfkill is unregistered. However, this check only take effect when device_del(&dev->dev) is done in nfc_unregister_device(). Hence, the rfkill object is still possible be dereferenced. The crash trace in latest kernel (5.18-rc2): [ 68.760105] ================================================================== [ 68.760330] BUG: KASAN: use-after-free in __lock_acquire+0x3ec1/0x6750 [ 68.760756] Read of size 8 at addr ffff888009c93018 by task fuzz/313 [ 68.760756] [ 68.760756] CPU: 0 PID: 313 Comm: fuzz Not tainted 5.18.0-rc2 #4 [ 68.760756] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 68.760756] Call Trace: [ 68.760756] <TASK> [ 68.760756] dump_stack_lvl+0x57/0x7d [ 68.760756] print_report.cold+0x5e/0x5db [ 68.760756] ? __lock_acquire+0x3ec1/0x6750 [ 68.760756] kasan_report+0xbe/0x1c0 [ 68.760756] ? __lock_acquire+0x3ec1/0x6750 [ 68.760756] __lock_acquire+0x3ec1/0x6750 [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 68.760756] ? register_lock_class+0x18d0/0x18d0 [ 68.760756] lock_acquire+0x1ac/0x4f0 [ 68.760756] ? rfkill_blocked+0xe/0x60 [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 68.760756] ? mutex_lock_io_nested+0x12c0/0x12c0 [ 68.760756] ? nla_get_range_signed+0x540/0x540 [ 68.760756] ? _raw_spin_lock_irqsave+0x4e/0x50 [ 68.760756] _raw_spin_lock_irqsave+0x39/0x50 [ 68.760756] ? rfkill_blocked+0xe/0x60 [ 68.760756] rfkill_blocked+0xe/0x60 [ 68.760756] nfc_dev_up+0x84/0x260 [ 68.760756] nfc_genl_dev_up+0x90/0xe0 [ 68.760756] genl_family_rcv_msg_doit+0x1f4/0x2f0 [ 68.760756] ? genl_family_rcv_msg_attrs_parse.constprop.0+0x230/0x230 [ 68.760756] ? security_capable+0x51/0x90 [ 68.760756] genl_rcv_msg+0x280/0x500 [ 68.760756] ? genl_get_cmd+0x3c0/0x3c0 [ 68.760756] ? lock_acquire+0x1ac/0x4f0 [ 68.760756] ? nfc_genl_dev_down+0xe0/0xe0 [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 68.760756] netlink_rcv_skb+0x11b/0x340 [ 68.760756] ? genl_get_cmd+0x3c0/0x3c0 [ 68.760756] ? netlink_ack+0x9c0/0x9c0 [ 68.760756] ? netlink_deliver_tap+0x136/0xb00 [ 68.760756] genl_rcv+0x1f/0x30 [ 68.760756] netlink_unicast+0x430/0x710 [ 68.760756] ? memset+0x20/0x40 [ 68.760756] ? netlink_attachskb+0x740/0x740 [ 68.760756] ? __build_skb_around+0x1f4/0x2a0 [ 68.760756] netlink_sendmsg+0x75d/0xc00 [ 68.760756] ? netlink_unicast+0x710/0x710 [ 68.760756] ? netlink_unicast+0x710/0x710 [ 68.760756] sock_sendmsg+0xdf/0x110 [ 68.760756] __sys_sendto+0x19e/0x270 [ 68.760756] ? __ia32_sys_getpeername+0xa0/0xa0 [ 68.760756] ? fd_install+0x178/0x4c0 [ 68.760756] ? fd_install+0x195/0x4c0 [ 68.760756] ? kernel_fpu_begin_mask+0x1c0/0x1c0 [ 68.760756] __x64_sys_sendto+0xd8/0x1b0 [ 68.760756] ? lockdep_hardirqs_on+0xbf/0x130 [ 68.760756] ? syscall_enter_from_user_mode+0x1d/0x50 [ 68.760756] do_syscall_64+0x3b/0x90 [ 68.760756] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 68.760756] RIP: 0033:0x7f67fb50e6b3 ... [ 68.760756] RSP: 002b:00007f67fa91fe90 EFLAGS: 00000293 ORIG_RAX: 000000000000002c [ 68.760756] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f67fb50e6b3 [ 68.760756] RDX: 000000000000001c RSI: 0000559354603090 RDI: 0000000000000003 [ 68.760756] RBP: 00007f67fa91ff00 R08: 00007f67fa91fedc R09: 000000000000000c [ 68.760756] R10: 0000000000000000 R11: 0000000000000293 R12: 00007ffe824d496e [ 68.760756] R13: 00007ffe824d496f R14: 00007f67fa120000 R15: 0000000000000003 [ 68.760756] </TASK> [ 68.760756] [ 68.760756] Allocated by task 279: [ 68.760756] kasan_save_stack+0x1e/0x40 [ ---truncated--- CVE-2022-49505 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Add vblank register/unregister callback functions We encountered a kernel panic issue that callback data will be NULL when it's using in ovl irq handler. There is a timing issue between mtk_disp_ovl_irq_handler() and mtk_ovl_disable_vblank(). To resolve this issue, we use the flow to register/unregister vblank cb: - Register callback function and callback data when crtc creates. - Unregister callback function and callback data when crtc destroies. With this solution, we can assure callback data will not be NULL when vblank is disable. CVE-2022-49506 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: regulator: da9121: Fix uninit-value in da9121_assign_chip_model() KASAN report slab-out-of-bounds in __regmap_init as follows: BUG: KASAN: slab-out-of-bounds in __regmap_init drivers/base/regmap/regmap.c:841 Read of size 1 at addr ffff88803678cdf1 by task xrun/9137 CPU: 0 PID: 9137 Comm: xrun Tainted: G W 5.18.0-rc2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xe8/0x15a lib/dump_stack.c:88 print_report.cold+0xcd/0x69b mm/kasan/report.c:313 kasan_report+0x8e/0xc0 mm/kasan/report.c:491 __regmap_init+0x4540/0x4ba0 drivers/base/regmap/regmap.c:841 __devm_regmap_init+0x7a/0x100 drivers/base/regmap/regmap.c:1266 __devm_regmap_init_i2c+0x65/0x80 drivers/base/regmap/regmap-i2c.c:394 da9121_i2c_probe+0x386/0x6d1 drivers/regulator/da9121-regulator.c:1039 i2c_device_probe+0x959/0xac0 drivers/i2c/i2c-core-base.c:563 This happend when da9121 device is probe by da9121_i2c_id, but with invalid dts. Thus, chip->subvariant_id is set to -EINVAL, and later da9121_assign_chip_model() will access 'regmap' without init it. Fix it by return -EINVAL from da9121_assign_chip_model() if 'chip->subvariant_id' is invalid. CVE-2022-49507 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: HID: elan: Fix potential double free in elan_input_configured 'input' is a managed resource allocated with devm_input_allocate_device(), so there is no need to call input_free_device() explicitly or there will be a double free. According to the doc of devm_input_allocate_device(): * Managed input devices do not need to be explicitly unregistered or * freed as it will be done automatically when owner device unbinds from * its driver (or binding fails). CVE-2022-49508 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: i2c: max9286: fix kernel oops when removing module When removing the max9286 module we get a kernel oops: Unable to handle kernel paging request at virtual address 000000aa00000094 Mem abort info: ESR = 0x96000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000880d85000 [000000aa00000094] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Modules linked in: fsl_jr_uio caam_jr rng_core libdes caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine max9271 authenc crct10dif_ce mxc_jpeg_encdec CPU: 2 PID: 713 Comm: rmmod Tainted: G C 5.15.5-00057-gaebcd29c8ed7-dirty #5 Hardware name: Freescale i.MX8QXP MEK (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : i2c_mux_del_adapters+0x24/0xf0 lr : max9286_remove+0x28/0xd0 [max9286] sp : ffff800013a9bbf0 x29: ffff800013a9bbf0 x28: ffff00080b6da940 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: ffff000801a5b970 x22: ffff0008048b0890 x21: ffff800009297000 x20: ffff0008048b0f70 x19: 000000aa00000064 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000014 x13: 0000000000000000 x12: ffff000802da49e8 x11: ffff000802051918 x10: ffff000802da4920 x9 : ffff000800030098 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffffffffffffffff x1 : ffff00080b6da940 x0 : 0000000000000000 Call trace: i2c_mux_del_adapters+0x24/0xf0 max9286_remove+0x28/0xd0 [max9286] i2c_device_remove+0x40/0x110 __device_release_driver+0x188/0x234 driver_detach+0xc4/0x150 bus_remove_driver+0x60/0xe0 driver_unregister+0x34/0x64 i2c_del_driver+0x58/0xa0 max9286_i2c_driver_exit+0x1c/0x490 [max9286] __arm64_sys_delete_module+0x194/0x260 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0xd4/0xfc do_el0_svc+0x2c/0x94 el0_svc+0x28/0x80 el0t_64_sync_handler+0xa8/0x130 el0t_64_sync+0x1a0/0x1a4 The Oops happens because the I2C client data does not point to max9286_priv anymore but to v4l2_subdev. The change happened in max9286_init() which calls v4l2_i2c_subdev_init() later on... Besides fixing the max9286_remove() function, remove the call to i2c_set_clientdata() in max9286_probe(), to avoid confusion, and make the necessary changes to max9286_init() so that it doesn't have to use i2c_get_clientdata() in order to fetch the pointer to priv. CVE-2022-49509 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: denali: Use managed device resources All of the resources used by this driver has managed interfaces, so use them. Otherwise we will get the following splat: [ 4.472703] denali-nand-pci 0000:00:05.0: timeout while waiting for irq 0x1000 [ 4.474071] denali-nand-pci: probe of 0000:00:05.0 failed with error -5 [ 4.473538] nand: No NAND device found [ 4.474068] BUG: unable to handle page fault for address: ffffc90005000410 [ 4.475169] #PF: supervisor write access in kernel mode [ 4.475579] #PF: error_code(0x0002) - not-present page [ 4.478362] RIP: 0010:iowrite32+0x9/0x50 [ 4.486068] Call Trace: [ 4.486269] <IRQ> [ 4.486443] denali_isr+0x15b/0x300 [denali] [ 4.486788] ? denali_direct_write+0x50/0x50 [denali] [ 4.487189] __handle_irq_event_percpu+0x161/0x3b0 [ 4.487571] handle_irq_event+0x7d/0x1b0 [ 4.487884] handle_fasteoi_irq+0x2b0/0x770 [ 4.488219] __common_interrupt+0xc8/0x1b0 [ 4.488549] common_interrupt+0x9a/0xc0 CVE-2022-49512 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: Fix error handling in mt8173_max98090_dev_probe Call of_node_put(platform_node) to avoid refcount leak in the error path. CVE-2022-49514 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l41: Fix an out-of-bounds access in otp_packed_element_t The CS35L41_NUM_OTP_ELEM is 100, but only 99 entries are defined in the array otp_map_1/2[CS35L41_NUM_OTP_ELEM], this will trigger UBSAN to report a shift-out-of-bounds warning in the cs35l41_otp_unpack() since the last entry in the array will result in GENMASK(-1, 0). UBSAN reports this problem: UBSAN: shift-out-of-bounds in /home/hwang4/build/jammy/jammy/sound/soc/codecs/cs35l41-lib.c:836:8 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 10 PID: 595 Comm: systemd-udevd Not tainted 5.15.0-23-generic #23 Hardware name: LENOVO \x02MFG_IN_GO/\x02MFG_IN_GO, BIOS N3GET19W (1.00 ) 03/11/2022 Call Trace: <TASK> show_stack+0x52/0x58 dump_stack_lvl+0x4a/0x5f dump_stack+0x10/0x12 ubsan_epilogue+0x9/0x45 __ubsan_handle_shift_out_of_bounds.cold+0x61/0xef ? regmap_unlock_mutex+0xe/0x10 cs35l41_otp_unpack.cold+0x1c6/0x2b2 [snd_soc_cs35l41_lib] cs35l41_hda_probe+0x24f/0x33a [snd_hda_scodec_cs35l41] cs35l41_hda_i2c_probe+0x65/0x90 [snd_hda_scodec_cs35l41_i2c] ? cs35l41_hda_i2c_remove+0x20/0x20 [snd_hda_scodec_cs35l41_i2c] i2c_device_probe+0x252/0x2b0 CVE-2022-49515 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: Fix missing of_node_put in mt2701_wm8960_machine_probe This node pointer is returned by of_parse_phandle() with refcount incremented in this function. Calling of_node_put() to avoid the refcount leak. CVE-2022-49517 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ath10k: skip ath10k_halt during suspend for driver state RESTARTING Double free crash is observed when FW recovery(caused by wmi timeout/crash) is followed by immediate suspend event. The FW recovery is triggered by ath10k_core_restart() which calls driver clean up via ath10k_halt(). When the suspend event occurs between the FW recovery, the restart worker thread is put into frozen state until suspend completes. The suspend event triggers ath10k_stop() which again triggers ath10k_halt() The double invocation of ath10k_halt() causes ath10k_htt_rx_free() to be called twice(Note: ath10k_htt_rx_alloc was not called by restart worker thread because of its frozen state), causing the crash. To fix this, during the suspend flow, skip call to ath10k_halt() in ath10k_stop() when the current driver state is ATH10K_STATE_RESTARTING. Also, for driver state ATH10K_STATE_RESTARTING, call ath10k_wait_for_suspend() in ath10k_stop(). This is because call to ath10k_wait_for_suspend() is skipped later in [ath10k_halt() > ath10k_core_stop()] for the driver state ATH10K_STATE_RESTARTING. The frozen restart worker thread will be cancelled during resume when the device comes out of suspend. Below is the crash stack for reference: [ 428.469167] ------------[ cut here ]------------ [ 428.469180] kernel BUG at mm/slub.c:4150! [ 428.469193] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 428.469219] Workqueue: events_unbound async_run_entry_fn [ 428.469230] RIP: 0010:kfree+0x319/0x31b [ 428.469241] RSP: 0018:ffffa1fac015fc30 EFLAGS: 00010246 [ 428.469247] RAX: ffffedb10419d108 RBX: ffff8c05262b0000 [ 428.469252] RDX: ffff8c04a8c07000 RSI: 0000000000000000 [ 428.469256] RBP: ffffa1fac015fc78 R08: 0000000000000000 [ 428.469276] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 428.469285] Call Trace: [ 428.469295] ? dma_free_attrs+0x5f/0x7d [ 428.469320] ath10k_core_stop+0x5b/0x6f [ 428.469336] ath10k_halt+0x126/0x177 [ 428.469352] ath10k_stop+0x41/0x7e [ 428.469387] drv_stop+0x88/0x10e [ 428.469410] __ieee80211_suspend+0x297/0x411 [ 428.469441] rdev_suspend+0x6e/0xd0 [ 428.469462] wiphy_suspend+0xb1/0x105 [ 428.469483] ? name_show+0x2d/0x2d [ 428.469490] dpm_run_callback+0x8c/0x126 [ 428.469511] ? name_show+0x2d/0x2d [ 428.469517] __device_suspend+0x2e7/0x41b [ 428.469523] async_suspend+0x1f/0x93 [ 428.469529] async_run_entry_fn+0x3d/0xd1 [ 428.469535] process_one_work+0x1b1/0x329 [ 428.469541] worker_thread+0x213/0x372 [ 428.469547] kthread+0x150/0x15f [ 428.469552] ? pr_cont_work+0x58/0x58 [ 428.469558] ? kthread_blkcg+0x31/0x31 Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1 CVE-2022-49519 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: arm64: compat: Do not treat syscall number as ESR_ELx for a bad syscall If a compat process tries to execute an unknown system call above the __ARM_NR_COMPAT_END number, the kernel sends a SIGILL signal to the offending process. Information about the error is printed to dmesg in compat_arm_syscall() -> arm64_notify_die() -> arm64_force_sig_fault() -> arm64_show_signal(). arm64_show_signal() interprets a non-zero value for current->thread.fault_code as an exception syndrome and displays the message associated with the ESR_ELx.EC field (bits 31:26). current->thread.fault_code is set in compat_arm_syscall() -> arm64_notify_die() with the bad syscall number instead of a valid ESR_ELx value. This means that the ESR_ELx.EC field has the value that the user set for the syscall number and the kernel can end up printing bogus exception messages*. For example, for the syscall number 0x68000000, which evaluates to ESR_ELx.EC value of 0x1A (ESR_ELx_EC_FPAC) the kernel prints this error: [ 18.349161] syscall[300]: unhandled exception: ERET/ERETAA/ERETAB, ESR 0x68000000, Oops - bad compat syscall(2) in syscall[10000+50000] [ 18.350639] CPU: 2 PID: 300 Comm: syscall Not tainted 5.18.0-rc1 #79 [ 18.351249] Hardware name: Pine64 RockPro64 v2.0 (DT) [..] which is misleading, as the bad compat syscall has nothing to do with pointer authentication. Stop arm64_show_signal() from printing exception syndrome information by having compat_arm_syscall() set the ESR_ELx value to 0, as it has no meaning for an invalid system call number. The example above now becomes: [ 19.935275] syscall[301]: unhandled exception: Oops - bad compat syscall(2) in syscall[10000+50000] [ 19.936124] CPU: 1 PID: 301 Comm: syscall Not tainted 5.18.0-rc1-00005-g7e08006d4102 #80 [ 19.936894] Hardware name: Pine64 RockPro64 v2.0 (DT) [..] which although shows less information because the syscall number, wrongfully advertised as the ESR value, is missing, it is better than showing plainly wrong information. The syscall number can be easily obtained with strace. *A 32-bit value above or equal to 0x8000_0000 is interpreted as a negative integer in compat_arm_syscal() and the condition scno < __ARM_NR_COMPAT_END evaluates to true; the syscall will exit to userspace in this case with the ENOSYS error code instead of arm64_notify_die() being called. CVE-2022-49520 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 low In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix resource leak in lpfc_sli4_send_seq_to_ulp() If no handler is found in lpfc_complete_unsol_iocb() to match the rctl of a received frame, the frame is dropped and resources are leaked. Fix by returning resources when discarding an unhandled frame type. Update lpfc_fc_frame_check() handling of NOP basic link service. CVE-2022-49521 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: mmc: jz4740: Apply DMA engine limits to maximum segment size Do what is done in other DMA-enabled MMC host drivers (cf. host/mmci.c) and limit the maximum segment size based on the DMA engine's capabilities. This is needed to avoid warnings like the following with CONFIG_DMA_API_DEBUG=y. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 21 at kernel/dma/debug.c:1162 debug_dma_map_sg+0x2f4/0x39c DMA-API: jz4780-dma 13420000.dma-controller: mapping sg segment longer than device claims to support [len=98304] [max=65536] CPU: 0 PID: 21 Comm: kworker/0:1H Not tainted 5.18.0-rc1 #19 Workqueue: kblockd blk_mq_run_work_fn Stack : 81575aec 00000004 80620000 80620000 80620000 805e7358 00000009 801537ac 814c832c 806276e3 806e34b4 80620000 81575aec 00000001 81575ab8 09291444 00000000 00000000 805e7358 81575958 ffffffea 8157596c 00000000 636f6c62 6220646b 80387a70 0000000f 6d5f6b6c 80620000 00000000 81575ba4 00000009 805e170c 80896640 00000001 00010000 00000000 00000000 00006098 806e0000 ... Call Trace: [<80107670>] show_stack+0x84/0x120 [<80528cd8>] __warn+0xb8/0xec [<80528d78>] warn_slowpath_fmt+0x6c/0xb8 [<8016f1d4>] debug_dma_map_sg+0x2f4/0x39c [<80169d4c>] __dma_map_sg_attrs+0xf0/0x118 [<8016a27c>] dma_map_sg_attrs+0x14/0x28 [<804f66b4>] jz4740_mmc_prepare_dma_data+0x74/0xa4 [<804f6714>] jz4740_mmc_pre_request+0x30/0x54 [<804f4ff4>] mmc_blk_mq_issue_rq+0x6e0/0x7bc [<804f5590>] mmc_mq_queue_rq+0x220/0x2d4 [<8038b2c0>] blk_mq_dispatch_rq_list+0x480/0x664 [<80391040>] blk_mq_do_dispatch_sched+0x2dc/0x370 [<80391468>] __blk_mq_sched_dispatch_requests+0xec/0x164 [<80391540>] blk_mq_sched_dispatch_requests+0x44/0x94 [<80387900>] __blk_mq_run_hw_queue+0xb0/0xcc [<80134c14>] process_one_work+0x1b8/0x264 [<80134ff8>] worker_thread+0x2ec/0x3b8 [<8013b13c>] kthread+0x104/0x10c [<80101dcc>] ret_from_kernel_thread+0x14/0x1c ---[ end trace 0000000000000000 ]--- CVE-2022-49522 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ath11k: disable spectral scan during spectral deinit When ath11k modules are removed using rmmod with spectral scan enabled, crash is observed. Different crash trace is observed for each crash. Send spectral scan disable WMI command to firmware before cleaning the spectral dbring in the spectral_deinit API to avoid this crash. call trace from one of the crash observed: [ 1252.880802] Unable to handle kernel NULL pointer dereference at virtual address 00000008 [ 1252.882722] pgd = 0f42e886 [ 1252.890955] [00000008] *pgd=00000000 [ 1252.893478] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 1253.093035] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.89 #0 [ 1253.115261] Hardware name: Generic DT based system [ 1253.121149] PC is at ath11k_spectral_process_data+0x434/0x574 [ath11k] [ 1253.125940] LR is at 0x88e31017 [ 1253.132448] pc : [<7f9387b8>] lr : [<88e31017>] psr: a0000193 [ 1253.135488] sp : 80d01bc8 ip : 00000001 fp : 970e0000 [ 1253.141737] r10: 88e31000 r9 : 970ec000 r8 : 00000080 [ 1253.146946] r7 : 94734040 r6 : a0000113 r5 : 00000057 r4 : 00000000 [ 1253.152159] r3 : e18cb694 r2 : 00000217 r1 : 1df1f000 r0 : 00000001 [ 1253.158755] Flags: NzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [ 1253.165266] Control: 10c0383d Table: 5e71006a DAC: 00000055 [ 1253.172472] Process swapper/0 (pid: 0, stack limit = 0x60870141) [ 1253.458055] [<7f9387b8>] (ath11k_spectral_process_data [ath11k]) from [<7f917fdc>] (ath11k_dbring_buffer_release_event+0x214/0x2e4 [ath11k]) [ 1253.466139] [<7f917fdc>] (ath11k_dbring_buffer_release_event [ath11k]) from [<7f8ea3c4>] (ath11k_wmi_tlv_op_rx+0x1840/0x29cc [ath11k]) [ 1253.478807] [<7f8ea3c4>] (ath11k_wmi_tlv_op_rx [ath11k]) from [<7f8fe868>] (ath11k_htc_rx_completion_handler+0x180/0x4e0 [ath11k]) [ 1253.490699] [<7f8fe868>] (ath11k_htc_rx_completion_handler [ath11k]) from [<7f91308c>] (ath11k_ce_per_engine_service+0x2c4/0x3b4 [ath11k]) [ 1253.502386] [<7f91308c>] (ath11k_ce_per_engine_service [ath11k]) from [<7f9a4198>] (ath11k_pci_ce_tasklet+0x28/0x80 [ath11k_pci]) [ 1253.514811] [<7f9a4198>] (ath11k_pci_ce_tasklet [ath11k_pci]) from [<8032227c>] (tasklet_action_common.constprop.2+0x64/0xe8) [ 1253.526476] [<8032227c>] (tasklet_action_common.constprop.2) from [<803021e8>] (__do_softirq+0x130/0x2d0) [ 1253.537756] [<803021e8>] (__do_softirq) from [<80322610>] (irq_exit+0xcc/0xe8) [ 1253.547304] [<80322610>] (irq_exit) from [<8036a4a4>] (__handle_domain_irq+0x60/0xb4) [ 1253.554428] [<8036a4a4>] (__handle_domain_irq) from [<805eb348>] (gic_handle_irq+0x4c/0x90) [ 1253.562321] [<805eb348>] (gic_handle_irq) from [<80301a78>] (__irq_svc+0x58/0x8c) Tested-on: QCN6122 hw1.0 AHB WLAN.HK.2.6.0.1-00851-QCAHKSWPL_SILICONZ-1 CVE-2022-49523 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: pci: cx23885: Fix the error handling in cx23885_initdev() When the driver fails to call the dma_set_mask(), the driver will get the following splat: [ 55.853884] BUG: KASAN: use-after-free in __process_removed_driver+0x3c/0x240 [ 55.854486] Read of size 8 at addr ffff88810de60408 by task modprobe/590 [ 55.856822] Call Trace: [ 55.860327] __process_removed_driver+0x3c/0x240 [ 55.861347] bus_for_each_dev+0x102/0x160 [ 55.861681] i2c_del_driver+0x2f/0x50 This is because the driver has initialized the i2c related resources in cx23885_dev_setup() but not released them in error handling, fix this bug by modifying the error path that jumps after failing to call the dma_set_mask(). CVE-2022-49524 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: cx25821: Fix the warning when removing the module When removing the module, we will get the following warning: [ 14.746697] remove_proc_entry: removing non-empty directory 'irq/21', leaking at least 'cx25821[1]' [ 14.747449] WARNING: CPU: 4 PID: 368 at fs/proc/generic.c:717 remove_proc_entry+0x389/0x3f0 [ 14.751611] RIP: 0010:remove_proc_entry+0x389/0x3f0 [ 14.759589] Call Trace: [ 14.759792] <TASK> [ 14.759975] unregister_irq_proc+0x14c/0x170 [ 14.760340] irq_free_descs+0x94/0xe0 [ 14.760640] mp_unmap_irq+0xb6/0x100 [ 14.760937] acpi_unregister_gsi_ioapic+0x27/0x40 [ 14.761334] acpi_pci_irq_disable+0x1d3/0x320 [ 14.761688] pci_disable_device+0x1ad/0x380 [ 14.762027] ? _raw_spin_unlock_irqrestore+0x2d/0x60 [ 14.762442] ? cx25821_shutdown+0x20/0x9f0 [cx25821] [ 14.762848] cx25821_finidev+0x48/0xc0 [cx25821] [ 14.763242] pci_device_remove+0x92/0x240 Fix this by freeing the irq before call pci_disable_device(). CVE-2022-49525 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: md/bitmap: don't set sb values if can't pass sanity check If bitmap area contains invalid data, kernel will crash then mdadm triggers "Segmentation fault". This is cluster-md speical bug. In non-clustered env, mdadm will handle broken metadata case. In clustered array, only kernel space handles bitmap slot info. But even this bug only happened in clustered env, current sanity check is wrong, the code should be changed. How to trigger: (faulty injection) dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sda dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sdb mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sda /dev/sdb mdadm -Ss echo aaa > magic.txt == below modifying slot 2 bitmap data == dd if=magic.txt of=/dev/sda seek=16384 bs=1 count=3 <== destroy magic dd if=/dev/zero of=/dev/sda seek=16436 bs=1 count=4 <== ZERO chunksize mdadm -A /dev/md0 /dev/sda /dev/sdb == kernel crashes. mdadm outputs "Segmentation fault" == Reason of kernel crash: In md_bitmap_read_sb (called by md_bitmap_create), bad bitmap magic didn't block chunksize assignment, and zero value made DIV_ROUND_UP_SECTOR_T() trigger "divide error". Crash log: kernel: md: md0 stopped. kernel: md/raid1:md0: not clean -- starting background reconstruction kernel: md/raid1:md0: active with 2 out of 2 mirrors kernel: dlm: ... ... kernel: md-cluster: Joined cluster 44810aba-38bb-e6b8-daca-bc97a0b254aa slot 1 kernel: md0: invalid bitmap file superblock: bad magic kernel: md_bitmap_copy_from_slot can't get bitmap from slot 2 kernel: md-cluster: Could not gather bitmaps from slot 2 kernel: divide error: 0000 [#1] SMP NOPTI kernel: CPU: 0 PID: 1603 Comm: mdadm Not tainted 5.14.6-1-default kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod] kernel: RSP: 0018:ffffc22ac0843ba0 EFLAGS: 00010246 kernel: ... ... kernel: Call Trace: kernel: ? dlm_lock_sync+0xd0/0xd0 [md_cluster 77fe..7a0] kernel: md_bitmap_copy_from_slot+0x2c/0x290 [md_mod 24ea..d3a] kernel: load_bitmaps+0xec/0x210 [md_cluster 77fe..7a0] kernel: md_bitmap_load+0x81/0x1e0 [md_mod 24ea..d3a] kernel: do_md_run+0x30/0x100 [md_mod 24ea..d3a] kernel: md_ioctl+0x1290/0x15a0 [md_mod 24ea....d3a] kernel: ? mddev_unlock+0xaa/0x130 [md_mod 24ea..d3a] kernel: ? blkdev_ioctl+0xb1/0x2b0 kernel: block_ioctl+0x3b/0x40 kernel: __x64_sys_ioctl+0x7f/0xb0 kernel: do_syscall_64+0x59/0x80 kernel: ? exit_to_user_mode_prepare+0x1ab/0x230 kernel: ? syscall_exit_to_user_mode+0x18/0x40 kernel: ? do_syscall_64+0x69/0x80 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xae kernel: RIP: 0033:0x7f4a15fa722b kernel: ... ... kernel: ---[ end trace 8afa7612f559c868 ]--- kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod] CVE-2022-49526 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: venus: hfi: avoid null dereference in deinit If venus_probe fails at pm_runtime_put_sync the error handling first calls hfi_destroy and afterwards hfi_core_deinit. As hfi_destroy sets core->ops to NULL, hfi_core_deinit cannot call the core_deinit function anymore. Avoid this null pointer derefence by skipping the call when necessary. CVE-2022-49527 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes drm_cvt_mode may return NULL and we should check it. This bug is found by syzkaller: FAULT_INJECTION stacktrace: [ 168.567394] FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 1 [ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567408] Call trace: [ 168.567414] dump_backtrace+0x0/0x310 [ 168.567418] show_stack+0x28/0x38 [ 168.567423] dump_stack+0xec/0x15c [ 168.567427] should_fail+0x3ac/0x3d0 [ 168.567437] __should_failslab+0xb8/0x120 [ 168.567441] should_failslab+0x28/0xc0 [ 168.567445] kmem_cache_alloc_trace+0x50/0x640 [ 168.567454] drm_mode_create+0x40/0x90 [ 168.567458] drm_cvt_mode+0x48/0xc78 [ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu] [ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567492] drm_mode_getconnector+0x2e0/0xa70 [ 168.567496] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567514] drm_ioctl+0x558/0x6d0 [ 168.567522] do_vfs_ioctl+0x160/0xf30 [ 168.567525] ksys_ioctl+0x98/0xd8 [ 168.567530] __arm64_sys_ioctl+0x50/0xc8 [ 168.567536] el0_svc_common+0xc8/0x320 [ 168.567540] el0_svc_handler+0xf8/0x160 [ 168.567544] el0_svc+0x10/0x218 KASAN stacktrace: [ 168.567561] BUG: KASAN: null-ptr-deref in virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567565] Read of size 4 at addr 0000000000000054 by task syz/6425 [ 168.567566] [ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567575] Call trace: [ 168.567578] dump_backtrace+0x0/0x310 [ 168.567582] show_stack+0x28/0x38 [ 168.567586] dump_stack+0xec/0x15c [ 168.567591] kasan_report+0x244/0x2f0 [ 168.567594] __asan_load4+0x58/0xb0 [ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567617] drm_mode_getconnector+0x2e0/0xa70 [ 168.567621] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567624] drm_ioctl+0x558/0x6d0 [ 168.567628] do_vfs_ioctl+0x160/0xf30 [ 168.567632] ksys_ioctl+0x98/0xd8 [ 168.567636] __arm64_sys_ioctl+0x50/0xc8 [ 168.567641] el0_svc_common+0xc8/0x320 [ 168.567645] el0_svc_handler+0xf8/0x160 [ 168.567649] el0_svc+0x10/0x218 CVE-2022-49532 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Protect memory leak for NPIV ports sending PLOGI_RJT There is a potential memory leak in lpfc_ignore_els_cmpl() and lpfc_els_rsp_reject() that was allocated from NPIV PLOGI_RJT (lpfc_rcv_plogi()'s login_mbox). Check if cmdiocb->context_un.mbox was allocated in lpfc_ignore_els_cmpl(), and then free it back to phba->mbox_mem_pool along with mbox->ctx_buf for service parameters. For lpfc_els_rsp_reject() failure, free both the ctx_buf for service parameters and the login_mbox. CVE-2022-49534 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 low In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix null pointer dereference after failing to issue FLOGI and PLOGI If lpfc_issue_els_flogi() fails and returns non-zero status, the node reference count is decremented to trigger the release of the nodelist structure. However, if there is a prior registration or dev-loss-evt work pending, the node may be released prematurely. When dev-loss-evt completes, the released node is referenced causing a use-after-free null pointer dereference. Similarly, when processing non-zero ELS PLOGI completion status in lpfc_cmpl_els_plogi(), the ndlp flags are checked for a transport registration before triggering node removal. If dev-loss-evt work is pending, the node may be released prematurely and a subsequent call to lpfc_dev_loss_tmo_handler() results in a use after free ndlp dereference. Add test for pending dev-loss before decrementing the node reference count for FLOGI, PLOGI, PRLI, and ADISC handling. CVE-2022-49535 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix SCSI I/O completion and abort handler deadlock During stress I/O tests with 500+ vports, hard LOCKUP call traces are observed. CPU A: native_queued_spin_lock_slowpath+0x192 _raw_spin_lock_irqsave+0x32 lpfc_handle_fcp_err+0x4c6 lpfc_fcp_io_cmd_wqe_cmpl+0x964 lpfc_sli4_fp_handle_cqe+0x266 __lpfc_sli4_process_cq+0x105 __lpfc_sli4_hba_process_cq+0x3c lpfc_cq_poll_hdler+0x16 irq_poll_softirq+0x76 __softirqentry_text_start+0xe4 irq_exit+0xf7 do_IRQ+0x7f CPU B: native_queued_spin_lock_slowpath+0x5b _raw_spin_lock+0x1c lpfc_abort_handler+0x13e scmd_eh_abort_handler+0x85 process_one_work+0x1a7 worker_thread+0x30 kthread+0x112 ret_from_fork+0x1f Diagram of lockup: CPUA CPUB ---- ---- lpfc_cmd->buf_lock phba->hbalock lpfc_cmd->buf_lock phba->hbalock Fix by reordering the taking of the lpfc_cmd->buf_lock and phba->hbalock in lpfc_abort_handler routine so that it tries to take the lpfc_cmd->buf_lock first before phba->hbalock. CVE-2022-49536 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix call trace observed during I/O with CMF enabled The following was seen with CMF enabled: BUG: using smp_processor_id() in preemptible code: systemd-udevd/31711 kernel: caller is lpfc_update_cmf_cmd+0x214/0x420 [lpfc] kernel: CPU: 12 PID: 31711 Comm: systemd-udevd kernel: Call Trace: kernel: <TASK> kernel: dump_stack_lvl+0x44/0x57 kernel: check_preemption_disabled+0xbf/0xe0 kernel: lpfc_update_cmf_cmd+0x214/0x420 [lpfc] kernel: lpfc_nvme_fcp_io_submit+0x23b4/0x4df0 [lpfc] this_cpu_ptr() calls smp_processor_id() in a preemptible context. Fix by using per_cpu_ptr() with raw_smp_processor_id() instead. CVE-2022-49537 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: cifs: fix potential double free during failed mount RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=2088799 CVE-2022-49541 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Move cfg_log_verbose check before calling lpfc_dmp_dbg() In an attempt to log message 0126 with LOG_TRACE_EVENT, the following hard lockup call trace hangs the system. Call Trace: _raw_spin_lock_irqsave+0x32/0x40 lpfc_dmp_dbg.part.32+0x28/0x220 [lpfc] lpfc_cmpl_els_fdisc+0x145/0x460 [lpfc] lpfc_sli_cancel_jobs+0x92/0xd0 [lpfc] lpfc_els_flush_cmd+0x43c/0x670 [lpfc] lpfc_els_flush_all_cmd+0x37/0x60 [lpfc] lpfc_sli4_async_event_proc+0x956/0x1720 [lpfc] lpfc_do_work+0x1485/0x1d70 [lpfc] kthread+0x112/0x130 ret_from_fork+0x1f/0x40 Kernel panic - not syncing: Hard LOCKUP The same CPU tries to claim the phba->port_list_lock twice. Move the cfg_log_verbose checks as part of the lpfc_printf_vlog() and lpfc_printf_log() macros before calling lpfc_dmp_dbg(). There is no need to take the phba->port_list_lock within lpfc_dmp_dbg(). CVE-2022-49542 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ipw2x00: Fix potential NULL dereference in libipw_xmit() crypt and crypt->ops could be null, so we need to checking null before dereference CVE-2022-49544 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Cancel pending work at closing a MIDI substream At closing a USB MIDI output substream, there might be still a pending work, which would eventually access the rawmidi runtime object that is being released. For fixing the race, make sure to cancel the pending work at closing. CVE-2022-49545 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: x86/kexec: fix memory leak of elf header buffer This is reported by kmemleak detector: unreferenced object 0xffffc900002a9000 (size 4096): comm "kexec", pid 14950, jiffies 4295110793 (age 373.951s) hex dump (first 32 bytes): 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 .ELF............ 04 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00 ..>............. backtrace: [<0000000016a8ef9f>] __vmalloc_node_range+0x101/0x170 [<000000002b66b6c0>] __vmalloc_node+0xb4/0x160 [<00000000ad40107d>] crash_prepare_elf64_headers+0x8e/0xcd0 [<0000000019afff23>] crash_load_segments+0x260/0x470 [<0000000019ebe95c>] bzImage64_load+0x814/0xad0 [<0000000093e16b05>] arch_kexec_kernel_image_load+0x1be/0x2a0 [<000000009ef2fc88>] kimage_file_alloc_init+0x2ec/0x5a0 [<0000000038f5a97a>] __do_sys_kexec_file_load+0x28d/0x530 [<0000000087c19992>] do_syscall_64+0x3b/0x90 [<0000000066e063a4>] entry_SYSCALL_64_after_hwframe+0x44/0xae In crash_prepare_elf64_headers(), a buffer is allocated via vmalloc() to store elf headers. While it's not freed back to system correctly when kdump kernel is reloaded or unloaded. Then memory leak is caused. Fix it by introducing x86 specific function arch_kimage_file_post_load_cleanup(), and freeing the buffer there. And also remove the incorrect elf header buffer freeing code. Before calling arch specific kexec_file loading function, the image instance has been initialized. So 'image->elf_headers' must be NULL. It doesn't make sense to free the elf header buffer in the place. Three different people have reported three bugs about the memory leak on x86_64 inside Redhat. CVE-2022-49546 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 low In the Linux kernel, the following vulnerability has been resolved: x86/MCE/AMD: Fix memory leak when threshold_create_bank() fails In mce_threshold_create_device(), if threshold_create_bank() fails, the previously allocated threshold banks array @bp will be leaked because the call to mce_threshold_remove_device() will not free it. This happens because mce_threshold_remove_device() fetches the pointer through the threshold_banks per-CPU variable but bp is written there only after the bank creation is successful, and not before, when threshold_create_bank() fails. Add a helper which unwinds all the bank creation work previously done and pass into it the previously allocated threshold banks array for freeing. [ bp: Massage. ] CVE-2022-49549 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: isp1760: Fix out-of-bounds array access Running the driver through kasan gives an interesting splat: BUG: KASAN: global-out-of-bounds in isp1760_register+0x180/0x70c Read of size 20 at addr f1db2e64 by task swapper/0/1 (...) isp1760_register from isp1760_plat_probe+0x1d8/0x220 (...) This happens because the loop reading the regmap fields for the different ISP1760 variants look like this: for (i = 0; i < HC_FIELD_MAX; i++) { ... } Meaning it expects the arrays to be at least HC_FIELD_MAX - 1 long. However the arrays isp1760_hc_reg_fields[], isp1763_hc_reg_fields[], isp1763_hc_volatile_ranges[] and isp1763_dc_volatile_ranges[] are dynamically sized during compilation. Fix this by putting an empty assignment to the [HC_FIELD_MAX] and [DC_FIELD_MAX] array member at the end of each array. This will make the array one member longer than it needs to be, but avoids the risk of overwriting whatever is inside [HC_FIELD_MAX - 1] and is simple and intuitive to read. Also add comments explaining what is going on. CVE-2022-49551 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Use del_timer_sync() before freeing While looking at a crash report on a timer list being corrupted, which usually happens when a timer is freed while still active. This is commonly triggered by code calling del_timer() instead of del_timer_sync() just before freeing. One possible culprit is the hci_qca driver, which does exactly that. Eric mentioned that wake_retrans_timer could be rearmed via the work queue, so also move the destruction of the work queue before del_timer_sync(). CVE-2022-49555 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Use kzalloc for sev ioctl interfaces to prevent kernel data leak For some sev ioctl interfaces, the length parameter that is passed maybe less than or equal to SEV_FW_BLOB_MAX_SIZE, but larger than the data that PSP firmware returns. In this case, kmalloc will allocate memory that is the size of the input rather than the size of the data. Since PSP firmware doesn't fully overwrite the allocated buffer, these sev ioctl interface may return uninitialized kernel slab memory. CVE-2022-49556 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Drop WARNs that assert a triple fault never "escapes" from L2 Remove WARNs that sanity check that KVM never lets a triple fault for L2 escape and incorrectly end up in L1. In normal operation, the sanity check is perfectly valid, but it incorrectly assumes that it's impossible for userspace to induce KVM_REQ_TRIPLE_FAULT without bouncing through KVM_RUN (which guarantees kvm_check_nested_state() will see and handle the triple fault). The WARN can currently be triggered if userspace injects a machine check while L2 is active and CR4.MCE=0. And a future fix to allow save/restore of KVM_REQ_TRIPLE_FAULT, e.g. so that a synthesized triple fault isn't lost on migration, will make it trivially easy for userspace to trigger the WARN. Clearing KVM_REQ_TRIPLE_FAULT when forcibly leaving guest mode is tempting, but wrong, especially if/when the request is saved/restored, e.g. if userspace restores events (including a triple fault) and then restores nested state (which may forcibly leave guest mode). Ignoring the fact that KVM doesn't currently provide the necessary APIs, it's userspace's responsibility to manage pending events during save/restore. ------------[ cut here ]------------ WARNING: CPU: 7 PID: 1399 at arch/x86/kvm/vmx/nested.c:4522 nested_vmx_vmexit+0x7fe/0xd90 [kvm_intel] Modules linked in: kvm_intel kvm irqbypass CPU: 7 PID: 1399 Comm: state_test Not tainted 5.17.0-rc3+ #808 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:nested_vmx_vmexit+0x7fe/0xd90 [kvm_intel] Call Trace: <TASK> vmx_leave_nested+0x30/0x40 [kvm_intel] vmx_set_nested_state+0xca/0x3e0 [kvm_intel] kvm_arch_vcpu_ioctl+0xf49/0x13e0 [kvm] kvm_vcpu_ioctl+0x4b9/0x660 [kvm] __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae </TASK> ---[ end trace 0000000000000000 ]--- CVE-2022-49559 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Use __try_cmpxchg_user() to update guest PTE A/D bits Use the recently introduced __try_cmpxchg_user() to update guest PTE A/D bits instead of mapping the PTE into kernel address space. The VM_PFNMAP path is broken as it assumes that vm_pgoff is the base pfn of the mapped VMA range, which is conceptually wrong as vm_pgoff is the offset relative to the file and has nothing to do with the pfn. The horrific hack worked for the original use case (backing guest memory with /dev/mem), but leads to accessing "random" pfns for pretty much any other VM_PFNMAP case. CVE-2022-49562 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: crypto: qat - add param check for RSA Reject requests with a source buffer that is bigger than the size of the key. This is to prevent a possible integer underflow that might happen when copying the source scatterlist into a linear buffer. CVE-2022-49563 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: crypto: qat - add param check for DH Reject requests with a source buffer that is bigger than the size of the key. This is to prevent a possible integer underflow that might happen when copying the source scatterlist into a linear buffer. CVE-2022-49564 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: crypto: qat - fix memory leak in RSA When an RSA key represented in form 2 (as defined in PKCS #1 V2.1) is used, some components of the private key persist even after the TFM is released. Replace the explicit calls to free the buffers in qat_rsa_exit_tfm() with a call to qat_rsa_clear_ctx() which frees all buffers referenced in the TFM context. CVE-2022-49566 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: KVM: Don't null dereference ops->destroy A KVM device cleanup happens in either of two callbacks: 1) destroy() which is called when the VM is being destroyed; 2) release() which is called when a device fd is closed. Most KVM devices use 1) but Book3s's interrupt controller KVM devices (XICS, XIVE, XIVE-native) use 2) as they need to close and reopen during the machine execution. The error handling in kvm_ioctl_create_device() assumes destroy() is always defined which leads to NULL dereference as discovered by Syzkaller. This adds a checks for destroy!=NULL and adds a missing release(). This is not changing kvm_destroy_devices() as devices with defined release() should have been removed from the KVM devices list by then. CVE-2022-49568 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: spi: bcm2835: bcm2835_spi_handle_err(): fix NULL pointer deref for non DMA transfers In case a IRQ based transfer times out the bcm2835_spi_handle_err() function is called. Since commit 1513ceee70f2 ("spi: bcm2835: Drop dma_pending flag") the TX and RX DMA transfers are unconditionally canceled, leading to NULL pointer derefs if ctlr->dma_tx or ctlr->dma_rx are not set. Fix the NULL pointer deref by checking that ctlr->dma_tx and ctlr->dma_rx are valid pointers before accessing them. CVE-2022-49569 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: gpio: gpio-xilinx: Fix integer overflow Current implementation is not able to configure more than 32 pins due to incorrect data type. So type casting with unsigned long to avoid it. CVE-2022-49570 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ipv4: Fix data-races around sysctl_fib_multipath_hash_policy. While reading sysctl_fib_multipath_hash_policy, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. CVE-2022-49579 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: be2net: Fix buffer overflow in be_get_module_eeprom be_cmd_read_port_transceiver_data assumes that it is given a buffer that is at least PAGE_DATA_LEN long, or twice that if the module supports SFF 8472. However, this is not always the case. Fix this by passing the desired offset and length to be_cmd_read_port_transceiver_data so that we only copy the bytes once. CVE-2022-49581 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: iavf: Fix handling of dummy receive descriptors Fix memory leak caused by not handling dummy receive descriptor properly. iavf_get_rx_buffer now sets the rx_buffer return value for dummy receive descriptors. Without this patch, when the hardware writes a dummy descriptor, iavf would not free the page allocated for the previous receive buffer. This is an unlikely event but can still happen. [Jesse: massaged commit message] CVE-2022-49583 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ixgbe: Add locking to prevent panic when setting sriov_numvfs to zero It is possible to disable VFs while the PF driver is processing requests from the VF driver. This can result in a panic. BUG: unable to handle kernel paging request at 000000000000106c PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 8 PID: 0 Comm: swapper/8 Kdump: loaded Tainted: G I --------- - Hardware name: Dell Inc. PowerEdge R740/06WXJT, BIOS 2.8.2 08/27/2020 RIP: 0010:ixgbe_msg_task+0x4c8/0x1690 [ixgbe] Code: 00 00 48 8d 04 40 48 c1 e0 05 89 7c 24 24 89 fd 48 89 44 24 10 83 ff 01 0f 84 b8 04 00 00 4c 8b 64 24 10 4d 03 a5 48 22 00 00 <41> 80 7c 24 4c 00 0f 84 8a 03 00 00 0f b7 c7 83 f8 08 0f 84 8f 0a RSP: 0018:ffffb337869f8df8 EFLAGS: 00010002 RAX: 0000000000001020 RBX: 0000000000000000 RCX: 000000000000002b RDX: 0000000000000002 RSI: 0000000000000008 RDI: 0000000000000006 RBP: 0000000000000006 R08: 0000000000000002 R09: 0000000000029780 R10: 00006957d8f42832 R11: 0000000000000000 R12: 0000000000001020 R13: ffff8a00e8978ac0 R14: 000000000000002b R15: ffff8a00e8979c80 FS: 0000000000000000(0000) GS:ffff8a07dfd00000(0000) knlGS:00000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000106c CR3: 0000000063e10004 CR4: 00000000007726e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ? ttwu_do_wakeup+0x19/0x140 ? try_to_wake_up+0x1cd/0x550 ? ixgbevf_update_xcast_mode+0x71/0xc0 [ixgbevf] ixgbe_msix_other+0x17e/0x310 [ixgbe] __handle_irq_event_percpu+0x40/0x180 handle_irq_event_percpu+0x30/0x80 handle_irq_event+0x36/0x53 handle_edge_irq+0x82/0x190 handle_irq+0x1c/0x30 do_IRQ+0x49/0xd0 common_interrupt+0xf/0xf This can be eventually be reproduced with the following script: while : do echo 63 > /sys/class/net/<devname>/device/sriov_numvfs sleep 1 echo 0 > /sys/class/net/<devname>/device/sriov_numvfs sleep 1 done Add lock when disabling SR-IOV to prevent process VF mailbox communication. CVE-2022-49584 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: ksz_common: Fix refcount leak bug In ksz_switch_register(), we should call of_node_put() for the reference returned by of_get_child_by_name() which has increased the refcount. CVE-2022-49591 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix dma queue left shift overflow issue When queue number is > 4, left shift overflows due to 32 bits integer variable. Mask calculation is wrong for MTL_RXQ_DMA_MAP1. If CONFIG_UBSAN is enabled, kernel dumps below warning: [ 10.363842] ================================================================== [ 10.363882] UBSAN: shift-out-of-bounds in /build/linux-intel-iotg-5.15-8e6Tf4/ linux-intel-iotg-5.15-5.15.0/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c:224:12 [ 10.363929] shift exponent 40 is too large for 32-bit type 'unsigned int' [ 10.363953] CPU: 1 PID: 599 Comm: NetworkManager Not tainted 5.15.0-1003-intel-iotg [ 10.363956] Hardware name: ADLINK Technology Inc. LEC-EL/LEC-EL, BIOS 0.15.11 12/22/2021 [ 10.363958] Call Trace: [ 10.363960] <TASK> [ 10.363963] dump_stack_lvl+0x4a/0x5f [ 10.363971] dump_stack+0x10/0x12 [ 10.363974] ubsan_epilogue+0x9/0x45 [ 10.363976] __ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e [ 10.363979] ? wake_up_klogd+0x4a/0x50 [ 10.363983] ? vprintk_emit+0x8f/0x240 [ 10.363986] dwmac4_map_mtl_dma.cold+0x42/0x91 [stmmac] [ 10.364001] stmmac_mtl_configuration+0x1ce/0x7a0 [stmmac] [ 10.364009] ? dwmac410_dma_init_channel+0x70/0x70 [stmmac] [ 10.364020] stmmac_hw_setup.cold+0xf/0xb14 [stmmac] [ 10.364030] ? page_pool_alloc_pages+0x4d/0x70 [ 10.364034] ? stmmac_clear_tx_descriptors+0x6e/0xe0 [stmmac] [ 10.364042] stmmac_open+0x39e/0x920 [stmmac] [ 10.364050] __dev_open+0xf0/0x1a0 [ 10.364054] __dev_change_flags+0x188/0x1f0 [ 10.364057] dev_change_flags+0x26/0x60 [ 10.364059] do_setlink+0x908/0xc40 [ 10.364062] ? do_setlink+0xb10/0xc40 [ 10.364064] ? __nla_validate_parse+0x4c/0x1a0 [ 10.364068] __rtnl_newlink+0x597/0xa10 [ 10.364072] ? __nla_reserve+0x41/0x50 [ 10.364074] ? __kmalloc_node_track_caller+0x1d0/0x4d0 [ 10.364079] ? pskb_expand_head+0x75/0x310 [ 10.364082] ? nla_reserve_64bit+0x21/0x40 [ 10.364086] ? skb_free_head+0x65/0x80 [ 10.364089] ? security_sock_rcv_skb+0x2c/0x50 [ 10.364094] ? __cond_resched+0x19/0x30 [ 10.364097] ? kmem_cache_alloc_trace+0x15a/0x420 [ 10.364100] rtnl_newlink+0x49/0x70 This change fixes MTL_RXQ_DMA_MAP1 mask issue and channel/queue mapping warning. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216195 CVE-2022-49592 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ip: Fix data-races around sysctl_ip_fwd_update_priority. While reading sysctl_ip_fwd_update_priority, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. CVE-2022-49603 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: igc: Reinstate IGC_REMOVED logic and implement it properly The initially merged version of the igc driver code (via commit 146740f9abc4, "igc: Add support for PF") contained the following IGC_REMOVED checks in the igc_rd32/wr32() MMIO accessors: u32 igc_rd32(struct igc_hw *hw, u32 reg) { u8 __iomem *hw_addr = READ_ONCE(hw->hw_addr); u32 value = 0; if (IGC_REMOVED(hw_addr)) return ~value; value = readl(&hw_addr[reg]); /* reads should not return all F's */ if (!(~value) && (!reg || !(~readl(hw_addr)))) hw->hw_addr = NULL; return value; } And: #define wr32(reg, val) \ do { \ u8 __iomem *hw_addr = READ_ONCE((hw)->hw_addr); \ if (!IGC_REMOVED(hw_addr)) \ writel((val), &hw_addr[(reg)]); \ } while (0) E.g. igb has similar checks in its MMIO accessors, and has a similar macro E1000_REMOVED, which is implemented as follows: #define E1000_REMOVED(h) unlikely(!(h)) These checks serve to detect and take note of an 0xffffffff MMIO read return from the device, which can be caused by a PCIe link flap or some other kind of PCI bus error, and to avoid performing MMIO reads and writes from that point onwards. However, the IGC_REMOVED macro was not originally implemented: #ifndef IGC_REMOVED #define IGC_REMOVED(a) (0) #endif /* IGC_REMOVED */ This led to the IGC_REMOVED logic to be removed entirely in a subsequent commit (commit 3c215fb18e70, "igc: remove IGC_REMOVED function"), with the rationale that such checks matter only for virtualization and that igc does not support virtualization -- but a PCIe device can become detached even without virtualization being in use, and without proper checks, a PCIe bus error affecting an igc adapter will lead to various NULL pointer dereferences, as the first access after the error will set hw->hw_addr to NULL, and subsequent accesses will blindly dereference this now-NULL pointer. This patch reinstates the IGC_REMOVED checks in igc_rd32/wr32(), and implements IGC_REMOVED the way it is done for igb, by checking for the unlikely() case of hw_addr being NULL. This change prevents the oopses seen when a PCIe link flap occurs on an igc adapter. CVE-2022-49605 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix sleep from invalid context BUG Taking the qos_mutex to process RoCEv2 QP's on netdev events causes a kernel splat. Fix this by removing the handling for RoCEv2 in irdma_cm_teardown_connections that uses the mutex. This handling is only needed for iWARP to avoid having connections established while the link is down or having connections remain functional after the IP address is removed. BUG: sleeping function called from invalid context at kernel/locking/mutex. Call Trace: kernel: dump_stack+0x66/0x90 kernel: ___might_sleep.cold.92+0x8d/0x9a kernel: mutex_lock+0x1c/0x40 kernel: irdma_cm_teardown_connections+0x28e/0x4d0 [irdma] kernel: ? check_preempt_curr+0x7a/0x90 kernel: ? select_idle_sibling+0x22/0x3c0 kernel: ? select_task_rq_fair+0x94c/0xc90 kernel: ? irdma_exec_cqp_cmd+0xc27/0x17c0 [irdma] kernel: ? __wake_up_common+0x7a/0x190 kernel: irdma_if_notify+0x3cc/0x450 [irdma] kernel: ? sched_clock_cpu+0xc/0xb0 kernel: irdma_inet6addr_event+0xc6/0x150 [irdma] CVE-2022-49606 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix data race between perf_event_set_output() and perf_mmap_close() Yang Jihing reported a race between perf_event_set_output() and perf_mmap_close(): CPU1 CPU2 perf_mmap_close(e2) if (atomic_dec_and_test(&e2->rb->mmap_count)) // 1 - > 0 detach_rest = true ioctl(e1, IOC_SET_OUTPUT, e2) perf_event_set_output(e1, e2) ... list_for_each_entry_rcu(e, &e2->rb->event_list, rb_entry) ring_buffer_attach(e, NULL); // e1 isn't yet added and // therefore not detached ring_buffer_attach(e1, e2->rb) list_add_rcu(&e1->rb_entry, &e2->rb->event_list) After this; e1 is attached to an unmapped rb and a subsequent perf_mmap() will loop forever more: again: mutex_lock(&e->mmap_mutex); if (event->rb) { ... if (!atomic_inc_not_zero(&e->rb->mmap_count)) { ... mutex_unlock(&e->mmap_mutex); goto again; } } The loop in perf_mmap_close() holds e2->mmap_mutex, while the attach in perf_event_set_output() holds e1->mmap_mutex. As such there is no serialization to avoid this race. Change perf_event_set_output() to take both e1->mmap_mutex and e2->mmap_mutex to alleviate that problem. Additionally, have the loop in perf_mmap() detach the rb directly, this avoids having to wait for the concurrent perf_mmap_close() to get around to doing it to make progress. CVE-2022-49607 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: power/reset: arm-versatile: Fix refcount leak in versatile_reboot_probe of_find_matching_node_and_match() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. CVE-2022-49609 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: serial: 8250: Fix PM usage_count for console handover When console is enabled, univ8250_console_setup() calls serial8250_console_setup() before .dev is set to uart_port. Therefore, it will not call pm_runtime_get_sync(). Later, when the actual driver is going to take over univ8250_console_exit() is called. As .dev is already set, serial8250_console_exit() makes pm_runtime_put_sync() call with usage count being zero triggering PM usage count warning (extra debug for univ8250_console_setup(), univ8250_console_exit(), and serial8250_register_ports()): [ 0.068987] univ8250_console_setup ttyS0 nodev [ 0.499670] printk: console [ttyS0] enabled [ 0.717955] printk: console [ttyS0] printing thread started [ 1.960163] serial8250_register_ports assigned dev for ttyS0 [ 1.976830] printk: console [ttyS0] disabled [ 1.976888] printk: console [ttyS0] printing thread stopped [ 1.977073] univ8250_console_exit ttyS0 usage:0 [ 1.977075] serial8250 serial8250: Runtime PM usage count underflow! [ 1.977429] dw-apb-uart.6: ttyS0 at MMIO 0x4010006000 (irq = 33, base_baud = 115200) is a 16550A [ 1.977812] univ8250_console_setup ttyS0 usage:2 [ 1.978167] printk: console [ttyS0] printing thread started [ 1.978203] printk: console [ttyS0] enabled To fix the issue, call pm_runtime_get_sync() in serial8250_register_ports() as soon as .dev is set for an uart_port if it has console enabled. This problem became apparent only recently because 82586a721595 ("PM: runtime: Avoid device usage count underflows") added the warning printout. I confirmed this problem also occurs with v5.18 (w/o the warning printout, obviously). CVE-2022-49613 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: rt711-sdca: fix kernel NULL pointer dereference when IO error The initial settings will be written before the codec probe function. But, the rt711->component doesn't be assigned yet. If IO error happened during initial settings operations, it will cause the kernel panic. This patch changed component->dev to slave->dev to fix this issue. CVE-2022-49615 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: rt7*-sdw: harden jack_detect_handler Realtek headset codec drivers typically check if the card is instantiated before proceeding with the jack detection. The rt700, rt711 and rt711-sdca are however missing a check on the card pointer, which can lead to NULL dereferences encountered in driver bind/unbind tests. CVE-2022-49616 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: sof_sdw: handle errors on card registration If the card registration fails, typically because of deferred probes, the device properties added for headset codecs are not removed, which leads to kernel oopses in driver bind/unbind tests. We already clean-up the device properties when the card is removed, this code can be moved as a helper and called upon card registration errors. CVE-2022-49617 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: pinctrl: aspeed: Fix potential NULL dereference in aspeed_pinmux_set_mux() pdesc could be null but still dereference pdesc->name and it will lead to a null pointer access. So we move a null check before dereference. CVE-2022-49618 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: cpufreq: pmac32-cpufreq: Fix refcount leak bug In pmac_cpufreq_init_MacRISC3(), we need to add corresponding of_node_put() for the three node pointers whose refcount have been incremented by of_find_node_by_name(). CVE-2022-49621 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 low In the Linux kernel, the following vulnerability has been resolved: powerpc/xive/spapr: correct bitmap allocation size kasan detects access beyond the end of the xibm->bitmap allocation: BUG: KASAN: slab-out-of-bounds in _find_first_zero_bit+0x40/0x140 Read of size 8 at addr c00000001d1d0118 by task swapper/0/1 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc2-00001-g90df023b36dd #28 Call Trace: [c00000001d98f770] [c0000000012baab8] dump_stack_lvl+0xac/0x108 (unreliable) [c00000001d98f7b0] [c00000000068faac] print_report+0x37c/0x710 [c00000001d98f880] [c0000000006902c0] kasan_report+0x110/0x354 [c00000001d98f950] [c000000000692324] __asan_load8+0xa4/0xe0 [c00000001d98f970] [c0000000011c6ed0] _find_first_zero_bit+0x40/0x140 [c00000001d98f9b0] [c0000000000dbfbc] xive_spapr_get_ipi+0xcc/0x260 [c00000001d98fa70] [c0000000000d6d28] xive_setup_cpu_ipi+0x1e8/0x450 [c00000001d98fb30] [c000000004032a20] pSeries_smp_probe+0x5c/0x118 [c00000001d98fb60] [c000000004018b44] smp_prepare_cpus+0x944/0x9ac [c00000001d98fc90] [c000000004009f9c] kernel_init_freeable+0x2d4/0x640 [c00000001d98fd90] [c0000000000131e8] kernel_init+0x28/0x1d0 [c00000001d98fe10] [c00000000000cd54] ret_from_kernel_thread+0x5c/0x64 Allocated by task 0: kasan_save_stack+0x34/0x70 __kasan_kmalloc+0xb4/0xf0 __kmalloc+0x268/0x540 xive_spapr_init+0x4d0/0x77c pseries_init_irq+0x40/0x27c init_IRQ+0x44/0x84 start_kernel+0x2a4/0x538 start_here_common+0x1c/0x20 The buggy address belongs to the object at c00000001d1d0118 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes inside of 8-byte region [c00000001d1d0118, c00000001d1d0120) The buggy address belongs to the physical page: page:c00c000000074740 refcount:1 mapcount:0 mapping:0000000000000000 index:0xc00000001d1d0558 pfn:0x1d1d flags: 0x7ffff000000200(slab|node=0|zone=0|lastcpupid=0x7ffff) raw: 007ffff000000200 c00000001d0003c8 c00000001d0003c8 c00000001d010480 raw: c00000001d1d0558 0000000001e1000a 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: c00000001d1d0000: fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0080: fc fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc >c00000001d1d0100: fc fc fc 02 fc fc fc fc fc fc fc fc fc fc fc fc ^ c00000001d1d0180: fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0200: fc fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc This happens because the allocation uses the wrong unit (bits) when it should pass (BITS_TO_LONGS(count) * sizeof(long)) or equivalent. With small numbers of bits, the allocated object can be smaller than sizeof(long), which results in invalid accesses. Use bitmap_zalloc() to allocate and initialize the irq bitmap, paired with bitmap_free() for consistency. CVE-2022-49623 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: sfc: fix kernel panic when creating VF When creating VFs a kernel panic can happen when calling to efx_ef10_try_update_nic_stats_vf. When releasing a DMA coherent buffer, sometimes, I don't know in what specific circumstances, it has to unmap memory with vunmap. It is disallowed to do that in IRQ context or with BH disabled. Otherwise, we hit this line in vunmap, causing the crash: BUG_ON(in_interrupt()); This patch reenables BH to release the buffer. Log messages when the bug is hit: kernel BUG at mm/vmalloc.c:2727! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 6 PID: 1462 Comm: NetworkManager Kdump: loaded Tainted: G I --------- --- 5.14.0-119.el9.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/06WXJT, BIOS 2.8.2 08/27/2020 RIP: 0010:vunmap+0x2e/0x30 ...skip... Call Trace: __iommu_dma_free+0x96/0x100 efx_nic_free_buffer+0x2b/0x40 [sfc] efx_ef10_try_update_nic_stats_vf+0x14a/0x1c0 [sfc] efx_ef10_update_stats_vf+0x18/0x40 [sfc] efx_start_all+0x15e/0x1d0 [sfc] efx_net_open+0x5a/0xe0 [sfc] __dev_open+0xe7/0x1a0 __dev_change_flags+0x1d7/0x240 dev_change_flags+0x21/0x60 ...skip... CVE-2022-49625 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: sfc: fix use after free when disabling sriov Use after free is detected by kfence when disabling sriov. What was read after being freed was vf->pci_dev: it was freed from pci_disable_sriov and later read in efx_ef10_sriov_free_vf_vports, called from efx_ef10_sriov_free_vf_vswitching. Set the pointer to NULL at release time to not trying to read it later. Reproducer and dmesg log (note that kfence doesn't detect it every time): $ echo 1 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs $ echo 0 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs BUG: KFENCE: use-after-free read in efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc] Use-after-free read at 0x00000000ff3c1ba5 (in kfence-#224): efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc] efx_ef10_pci_sriov_disable+0x38/0x70 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xfe/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae kfence-#224: 0x00000000edb8ef95-0x00000000671f5ce1, size=2792, cache=kmalloc-4k allocated by task 6771 on cpu 10 at 3137.860196s: pci_alloc_dev+0x21/0x60 pci_iov_add_virtfn+0x2a2/0x320 sriov_enable+0x212/0x3e0 efx_ef10_sriov_configure+0x67/0x80 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xba/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae freed by task 6771 on cpu 12 at 3170.991309s: device_release+0x34/0x90 kobject_cleanup+0x3a/0x130 pci_iov_remove_virtfn+0xd9/0x120 sriov_disable+0x30/0xe0 efx_ef10_pci_sriov_disable+0x57/0x70 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xfe/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae CVE-2022-49626 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ima: Fix potential memory leak in ima_init_crypto() On failure to allocate the SHA1 tfm, IMA fails to initialize and exits without freeing the ima_algo_array. Add the missing kfree() for ima_algo_array to avoid the potential memory leak. CVE-2022-49627 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix leaks in probe These two error paths should clean up before returning. CVE-2022-49628 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: raw: Fix a data-race around sysctl_raw_l3mdev_accept. While reading sysctl_raw_l3mdev_accept, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader. CVE-2022-49631 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: sysctl: Fix data-races in proc_dou8vec_minmax(). A sysctl variable is accessed concurrently, and there is always a chance of data-race. So, all readers and writers need some basic protection to avoid load/store-tearing. This patch changes proc_dou8vec_minmax() to use READ_ONCE() and WRITE_ONCE() internally to fix data-races on the sysctl side. For now, proc_dou8vec_minmax() itself is tolerant to a data-race, but we still need to add annotations on the other subsystem's side. CVE-2022-49634 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: sysctl: Fix data races in proc_douintvec_minmax(). A sysctl variable is accessed concurrently, and there is always a chance of data-race. So, all readers and writers need some basic protection to avoid load/store-tearing. This patch changes proc_douintvec_minmax() to use READ_ONCE() and WRITE_ONCE() internally to fix data-races on the sysctl side. For now, proc_douintvec_minmax() itself is tolerant to a data-race, but we still need to add annotations on the other subsystem's side. CVE-2022-49640 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: sysctl: Fix data races in proc_douintvec(). A sysctl variable is accessed concurrently, and there is always a chance of data-race. So, all readers and writers need some basic protection to avoid load/store-tearing. This patch changes proc_douintvec() to use READ_ONCE() and WRITE_ONCE() internally to fix data-races on the sysctl side. For now, proc_douintvec() itself is tolerant to a data-race, but we still need to add annotations on the other subsystem's side. CVE-2022-49641 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: stmmac: dwc-qos: Disable split header for Tegra194 There is a long-standing issue with the Synopsys DWC Ethernet driver for Tegra194 where random system crashes have been observed [0]. The problem occurs when the split header feature is enabled in the stmmac driver. In the bad case, a larger than expected buffer length is received and causes the calculation of the total buffer length to overflow. This results in a very large buffer length that causes the kernel to crash. Why this larger buffer length is received is not clear, however, the feedback from the NVIDIA design team is that the split header feature is not supported for Tegra194. Therefore, disable split header support for Tegra194 to prevent these random crashes from occurring. [0] https://lore.kernel.org/linux-tegra/b0b17697-f23e-8fa5-3757-604a86f3a095@nvidia.com/ CVE-2022-49642 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ima: Fix a potential integer overflow in ima_appraise_measurement When the ima-modsig is enabled, the rc passed to evm_verifyxattr() may be negative, which may cause the integer overflow problem. CVE-2022-49643 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/i915: fix a possible refcount leak in intel_dp_add_mst_connector() If drm_connector_init fails, intel_connector_free will be called to take care of proper free. So it is necessary to drop the refcount of port before intel_connector_free. (cherry picked from commit cea9ed611e85d36a05db52b6457bf584b7d969e2) CVE-2022-49644 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/panfrost: Fix shrinker list corruption by madvise IOCTL Calling madvise IOCTL twice on BO causes memory shrinker list corruption and crashes kernel because BO is already on the list and it's added to the list again, while BO should be removed from the list before it's re-added. Fix it. CVE-2022-49645 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix queue selection for mesh/OCB interfaces When using iTXQ, the code assumes that there is only one vif queue for broadcast packets, using the BE queue. Allowing non-BE queue marking violates that assumption and txq->ac == skb_queue_mapping is no longer guaranteed. This can cause issues with queue handling in the driver and also causes issues with the recent ATF change, resulting in an AQL underflow warning. CVE-2022-49646 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: cgroup: Use separate src/dst nodes when preloading css_sets for migration Each cset (css_set) is pinned by its tasks. When we're moving tasks around across csets for a migration, we need to hold the source and destination csets to ensure that they don't go away while we're moving tasks about. This is done by linking cset->mg_preload_node on either the mgctx->preloaded_src_csets or mgctx->preloaded_dst_csets list. Using the same cset->mg_preload_node for both the src and dst lists was deemed okay as a cset can't be both the source and destination at the same time. Unfortunately, this overloading becomes problematic when multiple tasks are involved in a migration and some of them are identity noop migrations while others are actually moving across cgroups. For example, this can happen with the following sequence on cgroup1: #1> mkdir -p /sys/fs/cgroup/misc/a/b #2> echo $$ > /sys/fs/cgroup/misc/a/cgroup.procs #3> RUN_A_COMMAND_WHICH_CREATES_MULTIPLE_THREADS & #4> PID=$! #5> echo $PID > /sys/fs/cgroup/misc/a/b/tasks #6> echo $PID > /sys/fs/cgroup/misc/a/cgroup.procs the process including the group leader back into a. In this final migration, non-leader threads would be doing identity migration while the group leader is doing an actual one. After #3, let's say the whole process was in cset A, and that after #4, the leader moves to cset B. Then, during #6, the following happens: 1. cgroup_migrate_add_src() is called on B for the leader. 2. cgroup_migrate_add_src() is called on A for the other threads. 3. cgroup_migrate_prepare_dst() is called. It scans the src list. 4. It notices that B wants to migrate to A, so it tries to A to the dst list but realizes that its ->mg_preload_node is already busy. 5. and then it notices A wants to migrate to A as it's an identity migration, it culls it by list_del_init()'ing its ->mg_preload_node and putting references accordingly. 6. The rest of migration takes place with B on the src list but nothing on the dst list. This means that A isn't held while migration is in progress. If all tasks leave A before the migration finishes and the incoming task pins it, the cset will be destroyed leading to use-after-free. This is caused by overloading cset->mg_preload_node for both src and dst preload lists. We wanted to exclude the cset from the src list but ended up inadvertently excluding it from the dst list too. This patch fixes the issue by separating out cset->mg_preload_node into ->mg_src_preload_node and ->mg_dst_preload_node, so that the src and dst preloadings don't interfere with each other. CVE-2022-49647 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: tracing/histograms: Fix memory leak problem This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac. As commit 46bbe5c671e0 ("tracing: fix double free") said, the "double free" problem reported by clang static analyzer is: > In parse_var_defs() if there is a problem allocating > var_defs.expr, the earlier var_defs.name is freed. > This free is duplicated by free_var_defs() which frees > the rest of the list. However, if there is a problem allocating N-th var_defs.expr: + in parse_var_defs(), the freed 'earlier var_defs.name' is actually the N-th var_defs.name; + then in free_var_defs(), the names from 0th to (N-1)-th are freed; IF ALLOCATING PROBLEM HAPPENED HERE!!! -+ \ | 0th 1th (N-1)-th N-th V +-------------+-------------+-----+-------------+----------- var_defs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+----------- These two frees don't act on same name, so there was no "double free" problem before. Conversely, after that commit, we get a "memory leak" problem because the above "N-th var_defs.name" is not freed. If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th var_defs.expr allocated, then execute on shell like: $ echo 'hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger Then kmemleak reports: unreferenced object 0xffff8fb100ef3518 (size 8): comm "bash", pid 196, jiffies 4295681690 (age 28.538s) hex dump (first 8 bytes): 76 31 00 00 b1 8f ff ff v1...... backtrace: [<0000000038fe4895>] kstrdup+0x2d/0x60 [<00000000c99c049a>] event_hist_trigger_parse+0x206f/0x20e0 [<00000000ae70d2cc>] trigger_process_regex+0xc0/0x110 [<0000000066737a4c>] event_trigger_write+0x75/0xd0 [<000000007341e40c>] vfs_write+0xbb/0x2a0 [<0000000087fde4c2>] ksys_write+0x59/0xd0 [<00000000581e9cdf>] do_syscall_64+0x3a/0x80 [<00000000cf3b065c>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 CVE-2022-49648 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: xen/netback: avoid entering xenvif_rx_next_skb() with an empty rx queue xenvif_rx_next_skb() is expecting the rx queue not being empty, but in case the loop in xenvif_rx_action() is doing multiple iterations, the availability of another skb in the rx queue is not being checked. This can lead to crashes: [40072.537261] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080 [40072.537407] IP: xenvif_rx_skb+0x23/0x590 [xen_netback] [40072.537534] PGD 0 P4D 0 [40072.537644] Oops: 0000 [#1] SMP NOPTI [40072.537749] CPU: 0 PID: 12505 Comm: v1-c40247-q2-gu Not tainted 4.12.14-122.121-default #1 SLE12-SP5 [40072.537867] Hardware name: HP ProLiant DL580 Gen9/ProLiant DL580 Gen9, BIOS U17 11/23/2021 [40072.537999] task: ffff880433b38100 task.stack: ffffc90043d40000 [40072.538112] RIP: e030:xenvif_rx_skb+0x23/0x590 [xen_netback] [40072.538217] RSP: e02b:ffffc90043d43de0 EFLAGS: 00010246 [40072.538319] RAX: 0000000000000000 RBX: ffffc90043cd7cd0 RCX: 00000000000000f7 [40072.538430] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffffc90043d43df8 [40072.538531] RBP: 000000000000003f R08: 000077ff80000000 R09: 0000000000000008 [40072.538644] R10: 0000000000007ff0 R11: 00000000000008f6 R12: ffffc90043ce2708 [40072.538745] R13: 0000000000000000 R14: ffffc90043d43ed0 R15: ffff88043ea748c0 [40072.538861] FS: 0000000000000000(0000) GS:ffff880484600000(0000) knlGS:0000000000000000 [40072.538988] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [40072.539088] CR2: 0000000000000080 CR3: 0000000407ac8000 CR4: 0000000000040660 [40072.539211] Call Trace: [40072.539319] xenvif_rx_action+0x71/0x90 [xen_netback] [40072.539429] xenvif_kthread_guest_rx+0x14a/0x29c [xen_netback] Fix that by stopping the loop in case the rx queue becomes empty. CVE-2022-49649 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: dmaengine: qcom: bam_dma: fix runtime PM underflow Commit dbad41e7bb5f ("dmaengine: qcom: bam_dma: check if the runtime pm enabled") caused unbalanced pm_runtime_get/put() calls when the bam is controlled remotely. This commit reverts it and just enables pm_runtime in all cases, the clk_* functions already just nop when the clock is NULL. Also clean up a bit by removing unnecessary bamclk null checks. CVE-2022-49650 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: Fix refcount leak in ti_dra7_xbar_route_allocate of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not needed anymore. Add missing of_node_put() in to fix this. CVE-2022-49652 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: i2c: piix4: Fix a memory leak in the EFCH MMIO support The recently added support for EFCH MMIO regions introduced a memory leak in that code path. The leak is caused by the fact that release_resource() merely removes the resource from the tree but does not free its memory. We need to call release_mem_region() instead, which does free the memory. As a nice side effect, this brings back some symmetry between the legacy and MMIO paths. CVE-2022-49653 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ARM: meson: Fix refcount leak in meson_smp_prepare_cpus of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. CVE-2022-49656 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: usbnet: fix memory leak in error case usbnet_write_cmd_async() mixed up which buffers need to be freed in which error case. v2: add Fixes tag v3: fix uninitialized buf pointer CVE-2022-49657 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_open/close(): fix memory leak The gs_usb driver appears to suffer from a malady common to many USB CAN adapter drivers in that it performs usb_alloc_coherent() to allocate a number of USB request blocks (URBs) for RX, and then later relies on usb_kill_anchored_urbs() to free them, but this doesn't actually free them. As a result, this may be leaking DMA memory that's been used by the driver. This commit is an adaptation of the techniques found in the esd_usb2 driver where a similar design pattern led to a memory leak. It explicitly frees the RX URBs and their DMA memory via a call to usb_free_coherent(). Since the RX URBs were allocated in the gs_can_open(), we remove them in gs_can_close() rather than in the disconnect function as was done in esd_usb2. For more information, see the 928150fad41b ("can: esd_usb2: fix memory leak"). CVE-2022-49661 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume mac header is set in skb_tunnel_check_pmtu() Recently added debug in commit f9aefd6b2aa3 ("net: warn if mac header was not set") caught a bug in skb_tunnel_check_pmtu(), as shown in this syzbot report [1]. In ndo_start_xmit() paths, there is really no need to use skb->mac_header, because skb->data is supposed to point at it. [1] WARNING: CPU: 1 PID: 8604 at include/linux/skbuff.h:2784 skb_mac_header_len include/linux/skbuff.h:2784 [inline] WARNING: CPU: 1 PID: 8604 at include/linux/skbuff.h:2784 skb_tunnel_check_pmtu+0x5de/0x2f90 net/ipv4/ip_tunnel_core.c:413 Modules linked in: CPU: 1 PID: 8604 Comm: syz-executor.3 Not tainted 5.19.0-rc2-syzkaller-00443-g8720bd951b8e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:skb_mac_header_len include/linux/skbuff.h:2784 [inline] RIP: 0010:skb_tunnel_check_pmtu+0x5de/0x2f90 net/ipv4/ip_tunnel_core.c:413 Code: 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 80 3c 02 00 0f 84 b9 fe ff ff 4c 89 ff e8 7c 0f d7 f9 e9 ac fe ff ff e8 c2 13 8a f9 <0f> 0b e9 28 fc ff ff e8 b6 13 8a f9 48 8b 54 24 70 48 b8 00 00 00 RSP: 0018:ffffc90002e4f520 EFLAGS: 00010212 RAX: 0000000000000324 RBX: ffff88804d5fd500 RCX: ffffc90005b52000 RDX: 0000000000040000 RSI: ffffffff87f05e3e RDI: 0000000000000003 RBP: ffffc90002e4f650 R08: 0000000000000003 R09: 000000000000ffff R10: 000000000000ffff R11: 0000000000000000 R12: 000000000000ffff R13: 0000000000000000 R14: 000000000000ffcd R15: 000000000000001f FS: 00007f3babba9700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000075319000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> geneve_xmit_skb drivers/net/geneve.c:927 [inline] geneve_xmit+0xcf8/0x35d0 drivers/net/geneve.c:1107 __netdev_start_xmit include/linux/netdevice.h:4805 [inline] netdev_start_xmit include/linux/netdevice.h:4819 [inline] __dev_direct_xmit+0x500/0x730 net/core/dev.c:4309 dev_direct_xmit include/linux/netdevice.h:3007 [inline] packet_direct_xmit+0x1b8/0x2c0 net/packet/af_packet.c:282 packet_snd net/packet/af_packet.c:3073 [inline] packet_sendmsg+0x21f4/0x55d0 net/packet/af_packet.c:3104 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:734 ____sys_sendmsg+0x6eb/0x810 net/socket.c:2489 ___sys_sendmsg+0xf3/0x170 net/socket.c:2543 __sys_sendmsg net/socket.c:2572 [inline] __do_sys_sendmsg net/socket.c:2581 [inline] __se_sys_sendmsg net/socket.c:2579 [inline] __x64_sys_sendmsg+0x132/0x220 net/socket.c:2579 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f3baaa89109 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f3babba9168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f3baab9bf60 RCX: 00007f3baaa89109 RDX: 0000000000000000 RSI: 0000000020000a00 RDI: 0000000000000003 RBP: 00007f3baaae305d R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffe74f2543f R14: 00007f3babba9300 R15: 0000000000022000 </TASK> CVE-2022-49663 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: platform/x86: thinkpad_acpi: Fix a memory leak of EFCH MMIO resource Unlike release_mem_region(), a call to release_resource() does not free the resource, so it has to be freed explicitly to avoid a memory leak. CVE-2022-49665 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free after 802.3ad slave unbind commit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection"), resolve case, when there is several aggregation groups in the same bond. bond_3ad_unbind_slave will invalidate (clear) aggregator when __agg_active_ports return zero. So, ad_clear_agg can be executed even, when num_of_ports!=0. Than bond_3ad_unbind_slave can be executed again for, previously cleared aggregator. NOTE: at this time bond_3ad_unbind_slave will not update slave ports list, because lag_ports==NULL. So, here we got slave ports, pointing to freed aggregator memory. Fix with checking actual number of ports in group (as was before commit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection") ), before ad_clear_agg(). The KASAN logs are as follows: [ 767.617392] ================================================================== [ 767.630776] BUG: KASAN: use-after-free in bond_3ad_state_machine_handler+0x13dc/0x1470 [ 767.638764] Read of size 2 at addr ffff00011ba9d430 by task kworker/u8:7/767 [ 767.647361] CPU: 3 PID: 767 Comm: kworker/u8:7 Tainted: G O 5.15.11 #15 [ 767.655329] Hardware name: DNI AmazonGo1 A7040 board (DT) [ 767.660760] Workqueue: lacp_1 bond_3ad_state_machine_handler [ 767.666468] Call trace: [ 767.668930] dump_backtrace+0x0/0x2d0 [ 767.672625] show_stack+0x24/0x30 [ 767.675965] dump_stack_lvl+0x68/0x84 [ 767.679659] print_address_description.constprop.0+0x74/0x2b8 [ 767.685451] kasan_report+0x1f0/0x260 [ 767.689148] __asan_load2+0x94/0xd0 [ 767.692667] bond_3ad_state_machine_handler+0x13dc/0x1470 CVE-2022-49667 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: exynos-ppmu: Fix refcount leak in of_get_devfreq_events of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. This function only calls of_node_put() in normal path, missing it in error paths. Add missing of_node_put() to avoid refcount leak. CVE-2022-49668 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: linux/dim: Fix divide by 0 in RDMA DIM Fix a divide 0 error in rdma_dim_stats_compare() when prev->cpe_ratio == 0. CallTrace: Hardware name: H3C R4900 G3/RS33M2C9S, BIOS 2.00.37P21 03/12/2020 task: ffff880194b78000 task.stack: ffffc90006714000 RIP: 0010:backport_rdma_dim+0x10e/0x240 [mlx_compat] RSP: 0018:ffff880c10e83ec0 EFLAGS: 00010202 RAX: 0000000000002710 RBX: ffff88096cd7f780 RCX: 0000000000000064 RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000001 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 000000001d7c6c09 R13: ffff88096cd7f780 R14: ffff880b174fe800 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff880c10e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000a0965b00 CR3: 000000000200a003 CR4: 00000000007606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ib_poll_handler+0x43/0x80 [ib_core] irq_poll_softirq+0xae/0x110 __do_softirq+0xd1/0x28c irq_exit+0xde/0xf0 do_IRQ+0x54/0xe0 common_interrupt+0x8f/0x8f </IRQ> ? cpuidle_enter_state+0xd9/0x2a0 ? cpuidle_enter_state+0xc7/0x2a0 ? do_idle+0x170/0x1d0 ? cpu_startup_entry+0x6f/0x80 ? start_secondary+0x1b9/0x210 ? secondary_startup_64+0xa5/0xb0 Code: 0f 87 e1 00 00 00 8b 4c 24 14 44 8b 43 14 89 c8 4d 63 c8 44 29 c0 99 31 d0 29 d0 31 d2 48 98 48 8d 04 80 48 8d 04 80 48 c1 e0 02 <49> f7 f1 48 83 f8 0a 0f 86 c1 00 00 00 44 39 c1 7f 10 48 89 df RIP: backport_rdma_dim+0x10e/0x240 [mlx_compat] RSP: ffff880c10e83ec0 CVE-2022-49670 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/cm: Fix memory leak in ib_cm_insert_listen cm_alloc_id_priv() allocates resource for the cm_id_priv. When cm_init_listen() fails it doesn't free it, leading to memory leak. Add the missing error unwind. CVE-2022-49671 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: tun: unlink NAPI from device on destruction Syzbot found a race between tun file and device destruction. NAPIs live in struct tun_file which can get destroyed before the netdev so we have to del them explicitly. The current code is missing deleting the NAPI if the queue was detached first. CVE-2022-49672 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: dm raid: fix KASAN warning in raid5_add_disks There's a KASAN warning in raid5_add_disk when running the LVM testsuite. The warning happens in the test lvconvert-raid-reshape-linear_to_raid6-single-type.sh. We fix the warning by verifying that rdev->saved_raid_disk is within limits. CVE-2022-49673 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: dm raid: fix accesses beyond end of raid member array On dm-raid table load (using raid_ctr), dm-raid allocates an array rs->devs[rs->raid_disks] for the raid device members. rs->raid_disks is defined by the number of raid metadata and image tupples passed into the target's constructor. In the case of RAID layout changes being requested, that number can be different from the current number of members for existing raid sets as defined in their superblocks. Example RAID layout changes include: - raid1 legs being added/removed - raid4/5/6/10 number of stripes changed (stripe reshaping) - takeover to higher raid level (e.g. raid5 -> raid6) When accessing array members, rs->raid_disks must be used in control loops instead of the potentially larger value in rs->md.raid_disks. Otherwise it will cause memory access beyond the end of the rs->devs array. Fix this by changing code that is prone to out-of-bounds access. Also fix validate_raid_redundancy() to validate all devices that are added. Also, use braces to help clean up raid_iterate_devices(). The out-of-bounds memory accesses was discovered using KASAN. This commit was verified to pass all LVM2 RAID tests (with KASAN enabled). CVE-2022-49674 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: tick/nohz: unexport __init-annotated tick_nohz_full_setup() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it had been broken for a decade. Commit 28438794aba4 ("modpost: fix section mismatch check for exported init/exit sections") fixed it so modpost started to warn it again, then this showed up: MODPOST vmlinux.symvers WARNING: modpost: vmlinux.o(___ksymtab_gpl+tick_nohz_full_setup+0x0): Section mismatch in reference from the variable __ksymtab_tick_nohz_full_setup to the function .init.text:tick_nohz_full_setup() The symbol tick_nohz_full_setup is exported and annotated __init Fix this by removing the __init annotation of tick_nohz_full_setup or drop the export. Drop the export because tick_nohz_full_setup() is only called from the built-in code in kernel/sched/isolation.c. CVE-2022-49675 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: memory: samsung: exynos5422-dmc: Fix refcount leak in of_get_dram_timings of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. This function doesn't call of_node_put() in some error paths. To unify the structure, Add put_node label and goto it on errors. CVE-2022-49676 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ARM: cns3xxx: Fix refcount leak in cns3xxx_init of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. CVE-2022-49677 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: soc: bcm: brcmstb: pm: pm-arm: Fix refcount leak in brcmstb_pm_probe of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. In brcmstb_init_sram, it pass dn to of_address_to_resource(), of_address_to_resource() will call of_find_device_by_node() to take reference, so we should release the reference returned by of_find_matching_node(). CVE-2022-49678 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ARM: Fix refcount leak in axxia_boot_secondary of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. CVE-2022-49679 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ARM: exynos: Fix refcount leak in exynos_map_pmu of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. of_node_put() checks null pointer. CVE-2022-49680 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: iio: adc: adi-axi-adc: Fix refcount leak in adi_axi_adc_attach_client of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. CVE-2022-49683 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: iio: trigger: sysfs: fix use-after-free on remove Ensure that the irq_work has completed before the trigger is freed. ================================================================== BUG: KASAN: use-after-free in irq_work_run_list Read of size 8 at addr 0000000064702248 by task python3/25 Call Trace: irq_work_run_list irq_work_tick update_process_times tick_sched_handle tick_sched_timer __hrtimer_run_queues hrtimer_interrupt Allocated by task 25: kmem_cache_alloc_trace iio_sysfs_trig_add dev_attr_store sysfs_kf_write kernfs_fop_write_iter new_sync_write vfs_write ksys_write sys_write Freed by task 25: kfree iio_sysfs_trig_remove dev_attr_store sysfs_kf_write kernfs_fop_write_iter new_sync_write vfs_write ksys_write sys_write ================================================================== CVE-2022-49685 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: virtio_net: fix xdp_rxq_info bug after suspend/resume The following sequence currently causes a driver bug warning when using virtio_net: # ip link set eth0 up # echo mem > /sys/power/state (or e.g. # rtcwake -s 10 -m mem) <resume> # ip link set eth0 down Missing register, driver bug WARNING: CPU: 0 PID: 375 at net/core/xdp.c:138 xdp_rxq_info_unreg+0x58/0x60 Call trace: xdp_rxq_info_unreg+0x58/0x60 virtnet_close+0x58/0xac __dev_close_many+0xac/0x140 __dev_change_flags+0xd8/0x210 dev_change_flags+0x24/0x64 do_setlink+0x230/0xdd0 ... This happens because virtnet_freeze() frees the receive_queue completely (including struct xdp_rxq_info) but does not call xdp_rxq_info_unreg(). Similarly, virtnet_restore() sets up the receive_queue again but does not call xdp_rxq_info_reg(). Actually, parts of virtnet_freeze_down() and virtnet_restore_up() are almost identical to virtnet_close() and virtnet_open(): only the calls to xdp_rxq_info_(un)reg() are missing. This means that we can fix this easily and avoid such problems in the future by just calling virtnet_close()/open() from the freeze/restore handlers. Aside from adding the missing xdp_rxq_info calls the only difference is that the refill work is only cancelled if netif_running(). However, this should not make any functional difference since the refill work should only be active if the network interface is actually up. CVE-2022-49687 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: afs: Fix dynamic root getattr The recent patch to make afs_getattr consult the server didn't account for the pseudo-inodes employed by the dynamic root-type afs superblock not having a volume or a server to access, and thus an oops occurs if such a directory is stat'd. Fix this by checking to see if the vnode->volume pointer actually points anywhere before following it in afs_getattr(). This can be tested by stat'ing a directory in /afs. It may be sufficient just to do "ls /afs" and the oops looks something like: BUG: kernel NULL pointer dereference, address: 0000000000000020 ... RIP: 0010:afs_getattr+0x8b/0x14b ... Call Trace: <TASK> vfs_statx+0x79/0xf5 vfs_fstatat+0x49/0x62 CVE-2022-49688 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp4: Fix refcount leak in mdp4_modeset_init_intf of_graph_get_remote_node() returns remote device node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Patchwork: https://patchwork.freedesktop.org/patch/488473/ CVE-2022-49693 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: igb: fix a use-after-free issue in igb_clean_tx_ring Fix the following use-after-free bug in igb_clean_tx_ring routine when the NIC is running in XDP mode. The issue can be triggered redirecting traffic into the igb NIC and then closing the device while the traffic is flowing. [ 73.322719] CPU: 1 PID: 487 Comm: xdp_redirect Not tainted 5.18.3-apu2 #9 [ 73.330639] Hardware name: PC Engines APU2/APU2, BIOS 4.0.7 02/28/2017 [ 73.337434] RIP: 0010:refcount_warn_saturate+0xa7/0xf0 [ 73.362283] RSP: 0018:ffffc9000081f798 EFLAGS: 00010282 [ 73.367761] RAX: 0000000000000000 RBX: ffffc90000420f80 RCX: 0000000000000000 [ 73.375200] RDX: ffff88811ad22d00 RSI: ffff88811ad171e0 RDI: ffff88811ad171e0 [ 73.382590] RBP: 0000000000000900 R08: ffffffff82298f28 R09: 0000000000000058 [ 73.390008] R10: 0000000000000219 R11: ffffffff82280f40 R12: 0000000000000090 [ 73.397356] R13: ffff888102343a40 R14: ffff88810359e0e4 R15: 0000000000000000 [ 73.404806] FS: 00007ff38d31d740(0000) GS:ffff88811ad00000(0000) knlGS:0000000000000000 [ 73.413129] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 73.419096] CR2: 000055cff35f13f8 CR3: 0000000106391000 CR4: 00000000000406e0 [ 73.426565] Call Trace: [ 73.429087] <TASK> [ 73.431314] igb_clean_tx_ring+0x43/0x140 [igb] [ 73.436002] igb_down+0x1d7/0x220 [igb] [ 73.439974] __igb_close+0x3c/0x120 [igb] [ 73.444118] igb_xdp+0x10c/0x150 [igb] [ 73.447983] ? igb_pci_sriov_configure+0x70/0x70 [igb] [ 73.453362] dev_xdp_install+0xda/0x110 [ 73.457371] dev_xdp_attach+0x1da/0x550 [ 73.461369] do_setlink+0xfd0/0x10f0 [ 73.465166] ? __nla_validate_parse+0x89/0xc70 [ 73.469714] rtnl_setlink+0x11a/0x1e0 [ 73.473547] rtnetlink_rcv_msg+0x145/0x3d0 [ 73.477709] ? rtnl_calcit.isra.0+0x130/0x130 [ 73.482258] netlink_rcv_skb+0x8d/0x110 [ 73.486229] netlink_unicast+0x230/0x340 [ 73.490317] netlink_sendmsg+0x215/0x470 [ 73.494395] __sys_sendto+0x179/0x190 [ 73.498268] ? move_addr_to_user+0x37/0x70 [ 73.502547] ? __sys_getsockname+0x84/0xe0 [ 73.506853] ? netlink_setsockopt+0x1c1/0x4a0 [ 73.511349] ? __sys_setsockopt+0xc8/0x1d0 [ 73.515636] __x64_sys_sendto+0x20/0x30 [ 73.519603] do_syscall_64+0x3b/0x80 [ 73.523399] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 73.528712] RIP: 0033:0x7ff38d41f20c [ 73.551866] RSP: 002b:00007fff3b945a68 EFLAGS: 00000246 ORIG_RAX: 000000000000002c [ 73.559640] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ff38d41f20c [ 73.567066] RDX: 0000000000000034 RSI: 00007fff3b945b30 RDI: 0000000000000003 [ 73.574457] RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000 [ 73.581852] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff3b945ab0 [ 73.589179] R13: 0000000000000000 R14: 0000000000000003 R15: 00007fff3b945b30 [ 73.596545] </TASK> [ 73.598842] ---[ end trace 0000000000000000 ]--- CVE-2022-49695 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: filemap: Handle sibling entries in filemap_get_read_batch() If a read races with an invalidation followed by another read, it is possible for a folio to be replaced with a higher-order folio. If that happens, we'll see a sibling entry for the new folio in the next iteration of the loop. This manifests as a NULL pointer dereference while holding the RCU read lock. Handle this by simply returning. The next call will find the new folio and handle it correctly. The other ways of handling this rare race are more complex and it's just not worth it. CVE-2022-49699 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: mm/slub: add missing TID updates on slab deactivation The fastpath in slab_alloc_node() assumes that c->slab is stable as long as the TID stays the same. However, two places in __slab_alloc() currently don't update the TID when deactivating the CPU slab. If multiple operations race the right way, this could lead to an object getting lost; or, in an even more unlikely situation, it could even lead to an object being freed onto the wrong slab's freelist, messing up the `inuse` counter and eventually causing a page to be freed to the page allocator while it still contains slab objects. (I haven't actually tested these cases though, this is just based on looking at the code. Writing testcases for this stuff seems like it'd be a pain...) The race leading to state inconsistency is (all operations on the same CPU and kmem_cache): - task A: begin do_slab_free(): - read TID - read pcpu freelist (==NULL) - check `slab == c->slab` (true) - [PREEMPT A->B] - task B: begin slab_alloc_node(): - fastpath fails (`c->freelist` is NULL) - enter __slab_alloc() - slub_get_cpu_ptr() (disables preemption) - enter ___slab_alloc() - take local_lock_irqsave() - read c->freelist as NULL - get_freelist() returns NULL - write `c->slab = NULL` - drop local_unlock_irqrestore() - goto new_slab - slub_percpu_partial() is NULL - get_partial() returns NULL - slub_put_cpu_ptr() (enables preemption) - [PREEMPT B->A] - task A: finish do_slab_free(): - this_cpu_cmpxchg_double() succeeds() - [CORRUPT STATE: c->slab==NULL, c->freelist!=NULL] From there, the object on c->freelist will get lost if task B is allowed to continue from here: It will proceed to the retry_load_slab label, set c->slab, then jump to load_freelist, which clobbers c->freelist. But if we instead continue as follows, we get worse corruption: - task A: run __slab_free() on object from other struct slab: - CPU_PARTIAL_FREE case (slab was on no list, is now on pcpu partial) - task A: run slab_alloc_node() with NUMA node constraint: - fastpath fails (c->slab is NULL) - call __slab_alloc() - slub_get_cpu_ptr() (disables preemption) - enter ___slab_alloc() - c->slab is NULL: goto new_slab - slub_percpu_partial() is non-NULL - set c->slab to slub_percpu_partial(c) - [CORRUPT STATE: c->slab points to slab-1, c->freelist has objects from slab-2] - goto redo - node_match() fails - goto deactivate_slab - existing c->freelist is passed into deactivate_slab() - inuse count of slab-1 is decremented to account for object from slab-2 At this point, the inuse count of slab-1 is 1 lower than it should be. This means that if we free all allocated objects in slab-1 except for one, SLUB will think that slab-1 is completely unused, and may free its page, leading to use-after-free. CVE-2022-49700 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: ibmvfc: Allocate/free queue resource only during probe/remove Currently, the sub-queues and event pool resources are allocated/freed for every CRQ connection event such as reset and LPM. This exposes the driver to a couple issues. First the inefficiency of freeing and reallocating memory that can simply be resued after being sanitized. Further, a system under memory pressue runs the risk of allocation failures that could result in a crippled driver. Finally, there is a race window where command submission/compeletion can try to pull/return elements from/to an event pool that is being deleted or already has been deleted due to the lack of host state around freeing/allocating resources. The following is an example of list corruption following a live partition migration (LPM): Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: vfat fat isofs cdrom ext4 mbcache jbd2 nft_counter nft_compat nf_tables nfnetlink rpadlpar_io rpaphp xsk_diag nfsv3 nfs_acl nfs lockd grace fscache netfs rfkill bonding tls sunrpc pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc scsi_transport_fc ibmveth vmx_crypto dm_multipath dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse CPU: 0 PID: 2108 Comm: ibmvfc_0 Kdump: loaded Not tainted 5.14.0-70.9.1.el9_0.ppc64le #1 NIP: c0000000007c4bb0 LR: c0000000007c4bac CTR: 00000000005b9a10 REGS: c00000025c10b760 TRAP: 0700 Not tainted (5.14.0-70.9.1.el9_0.ppc64le) MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 2800028f XER: 0000000f CFAR: c0000000001f55bc IRQMASK: 0 GPR00: c0000000007c4bac c00000025c10ba00 c000000002a47c00 000000000000004e GPR04: c0000031e3006f88 c0000031e308bd00 c00000025c10b768 0000000000000027 GPR08: 0000000000000000 c0000031e3009dc0 00000031e0eb0000 0000000000000000 GPR12: c0000031e2ffffa8 c000000002dd0000 c000000000187108 c00000020fcee2c0 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 c008000002f81300 GPR24: 5deadbeef0000100 5deadbeef0000122 c000000263ba6910 c00000024cc88000 GPR28: 000000000000003c c0000002430a0000 c0000002430ac300 000000000000c300 NIP [c0000000007c4bb0] __list_del_entry_valid+0x90/0x100 LR [c0000000007c4bac] __list_del_entry_valid+0x8c/0x100 Call Trace: [c00000025c10ba00] [c0000000007c4bac] __list_del_entry_valid+0x8c/0x100 (unreliable) [c00000025c10ba60] [c008000002f42284] ibmvfc_free_queue+0xec/0x210 [ibmvfc] [c00000025c10bb10] [c008000002f4246c] ibmvfc_deregister_scsi_channel+0xc4/0x160 [ibmvfc] [c00000025c10bba0] [c008000002f42580] ibmvfc_release_sub_crqs+0x78/0x130 [ibmvfc] [c00000025c10bc20] [c008000002f4f6cc] ibmvfc_do_work+0x5c4/0xc70 [ibmvfc] [c00000025c10bce0] [c008000002f4fdec] ibmvfc_work+0x74/0x1e8 [ibmvfc] [c00000025c10bda0] [c0000000001872b8] kthread+0x1b8/0x1c0 [c00000025c10be10] [c00000000000cd64] ret_from_kernel_thread+0x5c/0x64 Instruction dump: 40820034 38600001 38210060 4e800020 7c0802a6 7c641b78 3c62fe7a 7d254b78 3863b590 f8010070 4ba309cd 60000000 <0fe00000> 7c0802a6 3c62fe7a 3863b640 ---[ end trace 11a2b65a92f8b66c ]--- ibmvfc 30000003: Send warning. Receive queue closed, will retry. Add registration/deregistration helpers that are called instead during connection resets to sanitize and reconfigure the queues. CVE-2022-49701 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: ibmvfc: Store vhost pointer during subcrq allocation Currently the back pointer from a queue to the vhost adapter isn't set until after subcrq interrupt registration. The value is available when a queue is first allocated and can/should be also set for primary and async queues as well as subcrqs. This fixes a crash observed during kexec/kdump on Power 9 with legacy XICS interrupt controller where a pending subcrq interrupt from the previous kernel can be replayed immediately upon IRQ registration resulting in dereference of a garbage backpointer in ibmvfc_interrupt_scsi(). Kernel attempted to read user page (58) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000058 Faulting instruction address: 0xc008000003216a08 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c008000003216a08] ibmvfc_interrupt_scsi+0x40/0xb0 [ibmvfc] LR [c0000000082079e8] __handle_irq_event_percpu+0x98/0x270 Call Trace: [c000000047fa3d80] [c0000000123e6180] 0xc0000000123e6180 (unreliable) [c000000047fa3df0] [c0000000082079e8] __handle_irq_event_percpu+0x98/0x270 [c000000047fa3ea0] [c000000008207d18] handle_irq_event+0x98/0x188 [c000000047fa3ef0] [c00000000820f564] handle_fasteoi_irq+0xc4/0x310 [c000000047fa3f40] [c000000008205c60] generic_handle_irq+0x50/0x80 [c000000047fa3f60] [c000000008015c40] __do_irq+0x70/0x1a0 [c000000047fa3f90] [c000000008016d7c] __do_IRQ+0x9c/0x130 [c000000014622f60] [0000000020000000] 0x20000000 [c000000014622ff0] [c000000008016e50] do_IRQ+0x40/0xa0 [c000000014623020] [c000000008017044] replay_soft_interrupts+0x194/0x2f0 [c000000014623210] [c0000000080172a8] arch_local_irq_restore+0x108/0x170 [c000000014623240] [c000000008eb1008] _raw_spin_unlock_irqrestore+0x58/0xb0 [c000000014623270] [c00000000820b12c] __setup_irq+0x49c/0x9f0 [c000000014623310] [c00000000820b7c0] request_threaded_irq+0x140/0x230 [c000000014623380] [c008000003212a50] ibmvfc_register_scsi_channel+0x1e8/0x2f0 [ibmvfc] [c000000014623450] [c008000003213d1c] ibmvfc_init_sub_crqs+0xc4/0x1f0 [ibmvfc] [c0000000146234d0] [c0080000032145a8] ibmvfc_reset_crq+0x150/0x210 [ibmvfc] [c000000014623550] [c0080000032147c8] ibmvfc_init_crq+0x160/0x280 [ibmvfc] [c0000000146235f0] [c00800000321a9cc] ibmvfc_probe+0x2a4/0x530 [ibmvfc] CVE-2022-49703 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: 9p: fix fid refcount leak in v9fs_vfs_get_link we check for protocol version later than required, after a fid has been obtained. Just move the version check earlier. CVE-2022-49704 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: 9p: fix fid refcount leak in v9fs_vfs_atomic_open_dotl We need to release directory fid if we fail halfway through open This fixes fid leaking with xfstests generic 531 CVE-2022-49705 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: add reserved GDT blocks check We capture a NULL pointer issue when resizing a corrupt ext4 image which is freshly clear resize_inode feature (not run e2fsck). It could be simply reproduced by following steps. The problem is because of the resize_inode feature was cleared, and it will convert the filesystem to meta_bg mode in ext4_resize_fs(), but the es->s_reserved_gdt_blocks was not reduced to zero, so could we mistakenly call reserve_backup_gdb() and passing an uninitialized resize_inode to it when adding new group descriptors. mkfs.ext4 /dev/sda 3G tune2fs -O ^resize_inode /dev/sda #forget to run requested e2fsck mount /dev/sda /mnt resize2fs /dev/sda 8G ======== BUG: kernel NULL pointer dereference, address: 0000000000000028 CPU: 19 PID: 3243 Comm: resize2fs Not tainted 5.18.0-rc7-00001-gfde086c5ebfd #748 ... RIP: 0010:ext4_flex_group_add+0xe08/0x2570 ... Call Trace: <TASK> ext4_resize_fs+0xbec/0x1660 __ext4_ioctl+0x1749/0x24e0 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0xa6/0x110 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f2dd739617b ======== The fix is simple, add a check in ext4_resize_begin() to make sure that the es->s_reserved_gdt_blocks is zero when the resize_inode feature is disabled. CVE-2022-49707 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: fix bug_on ext4_mb_use_inode_pa Hulk Robot reported a BUG_ON: ================================================================== kernel BUG at fs/ext4/mballoc.c:3211! [...] RIP: 0010:ext4_mb_mark_diskspace_used.cold+0x85/0x136f [...] Call Trace: ext4_mb_new_blocks+0x9df/0x5d30 ext4_ext_map_blocks+0x1803/0x4d80 ext4_map_blocks+0x3a4/0x1a10 ext4_writepages+0x126d/0x2c30 do_writepages+0x7f/0x1b0 __filemap_fdatawrite_range+0x285/0x3b0 file_write_and_wait_range+0xb1/0x140 ext4_sync_file+0x1aa/0xca0 vfs_fsync_range+0xfb/0x260 do_fsync+0x48/0xa0 [...] ================================================================== Above issue may happen as follows: ------------------------------------- do_fsync vfs_fsync_range ext4_sync_file file_write_and_wait_range __filemap_fdatawrite_range do_writepages ext4_writepages mpage_map_and_submit_extent mpage_map_one_extent ext4_map_blocks ext4_mb_new_blocks ext4_mb_normalize_request >>> start + size <= ac->ac_o_ex.fe_logical ext4_mb_regular_allocator ext4_mb_simple_scan_group ext4_mb_use_best_found ext4_mb_new_preallocation ext4_mb_new_inode_pa ext4_mb_use_inode_pa >>> set ac->ac_b_ex.fe_len <= 0 ext4_mb_mark_diskspace_used >>> BUG_ON(ac->ac_b_ex.fe_len <= 0); we can easily reproduce this problem with the following commands: `fallocate -l100M disk` `mkfs.ext4 -b 1024 -g 256 disk` `mount disk /mnt` `fsstress -d /mnt -l 0 -n 1000 -p 1` The size must be smaller than or equal to EXT4_BLOCKS_PER_GROUP. Therefore, "start + size <= ac->ac_o_ex.fe_logical" may occur when the size is truncated. So start should be the start position of the group where ac_o_ex.fe_logical is located after alignment. In addition, when the value of fe_logical or EXT4_BLOCKS_PER_GROUP is very large, the value calculated by start_off is more accurate. CVE-2022-49708 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: dm mirror log: round up region bitmap size to BITS_PER_LONG The code in dm-log rounds up bitset_size to 32 bits. It then uses find_next_zero_bit_le on the allocated region. find_next_zero_bit_le accesses the bitmap using unsigned long pointers. So, on 64-bit architectures, it may access 4 bytes beyond the allocated size. Fix this bug by rounding up bitset_size to BITS_PER_LONG. This bug was found by running the lvm2 testsuite with kasan. CVE-2022-49710 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: bus: fsl-mc-bus: fix KASAN use-after-free in fsl_mc_bus_remove() In fsl_mc_bus_remove(), mc->root_mc_bus_dev->mc_io is passed to fsl_destroy_mc_io(). However, mc->root_mc_bus_dev is already freed in fsl_mc_device_remove(). Then reference to mc->root_mc_bus_dev->mc_io triggers KASAN use-after-free. To avoid the use-after-free, keep the reference to mc->root_mc_bus_dev->mc_io in a local variable and pass to fsl_destroy_mc_io(). This patch needs rework to apply to kernels older than v5.15. CVE-2022-49711 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: gadget: lpc32xx_udc: Fix refcount leak in lpc32xx_udc_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. of_node_put() will check NULL pointer. CVE-2022-49712 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: Fix memory leak in dwc2_hcd_init usb_create_hcd will alloc memory for hcd, and we should call usb_put_hcd to free it when platform_get_resource() fails to prevent memory leak. goto error2 label instead error1 to fix this. CVE-2022-49713 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: irqchip/realtek-rtl: Fix refcount leak in map_interrupts of_find_node_by_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. This function doesn't call of_node_put() in error path. Call of_node_put() directly after of_property_read_u32() to cover both normal path and error path. CVE-2022-49714 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3: Fix refcount leak in gic_populate_ppi_partitions of_find_node_by_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. CVE-2022-49715 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3: Fix error handling in gic_populate_ppi_partitions of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. When kcalloc fails, it missing of_node_put() and results in refcount leak. Fix this by goto out_put_node label. CVE-2022-49716 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: irqchip/gic/realview: Fix refcount leak in realview_gic_of_init of_find_matching_node_and_match() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. CVE-2022-49719 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: block: Fix handling of offline queues in blk_mq_alloc_request_hctx() This patch prevents that test nvme/004 triggers the following: UBSAN: array-index-out-of-bounds in block/blk-mq.h:135:9 index 512 is out of range for type 'long unsigned int [512]' Call Trace: show_stack+0x52/0x58 dump_stack_lvl+0x49/0x5e dump_stack+0x10/0x12 ubsan_epilogue+0x9/0x3b __ubsan_handle_out_of_bounds.cold+0x44/0x49 blk_mq_alloc_request_hctx+0x304/0x310 __nvme_submit_sync_cmd+0x70/0x200 [nvme_core] nvmf_connect_io_queue+0x23e/0x2a0 [nvme_fabrics] nvme_loop_connect_io_queues+0x8d/0xb0 [nvme_loop] nvme_loop_create_ctrl+0x58e/0x7d0 [nvme_loop] nvmf_create_ctrl+0x1d7/0x4d0 [nvme_fabrics] nvmf_dev_write+0xae/0x111 [nvme_fabrics] vfs_write+0x144/0x560 ksys_write+0xb7/0x140 __x64_sys_write+0x42/0x50 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae CVE-2022-49720 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: arm64: ftrace: consistently handle PLTs. Sometimes it is necessary to use a PLT entry to call an ftrace trampoline. This is handled by ftrace_make_call() and ftrace_make_nop(), with each having *almost* identical logic, but this is not handled by ftrace_modify_call() since its introduction in commit: 3b23e4991fb66f6d ("arm64: implement ftrace with regs") Due to this, if we ever were to call ftrace_modify_call() for a callsite which requires a PLT entry for a trampoline, then either: a) If the old addr requires a trampoline, ftrace_modify_call() will use an out-of-range address to generate the 'old' branch instruction. This will result in warnings from aarch64_insn_gen_branch_imm() and ftrace_modify_code(), and no instructions will be modified. As ftrace_modify_call() will return an error, this will result in subsequent internal ftrace errors. b) If the old addr does not require a trampoline, but the new addr does, ftrace_modify_call() will use an out-of-range address to generate the 'new' branch instruction. This will result in warnings from aarch64_insn_gen_branch_imm(), and ftrace_modify_code() will replace the 'old' branch with a BRK. This will result in a kernel panic when this BRK is later executed. Practically speaking, case (a) is vastly more likely than case (b), and typically this will result in internal ftrace errors that don't necessarily affect the rest of the system. This can be demonstrated with an out-of-tree test module which triggers ftrace_modify_call(), e.g. | # insmod test_ftrace.ko | test_ftrace: Function test_function raw=0xffffb3749399201c, callsite=0xffffb37493992024 | branch_imm_common: offset out of range | branch_imm_common: offset out of range | ------------[ ftrace bug ]------------ | ftrace failed to modify | [<ffffb37493992024>] test_function+0x8/0x38 [test_ftrace] | actual: 1d:00:00:94 | Updating ftrace call site to call a different ftrace function | ftrace record flags: e0000002 | (2) R | expected tramp: ffffb374ae42ed54 | ------------[ cut here ]------------ | WARNING: CPU: 0 PID: 165 at kernel/trace/ftrace.c:2085 ftrace_bug+0x280/0x2b0 | Modules linked in: test_ftrace(+) | CPU: 0 PID: 165 Comm: insmod Not tainted 5.19.0-rc2-00002-g4d9ead8b45ce #13 | Hardware name: linux,dummy-virt (DT) | pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : ftrace_bug+0x280/0x2b0 | lr : ftrace_bug+0x280/0x2b0 | sp : ffff80000839ba00 | x29: ffff80000839ba00 x28: 0000000000000000 x27: ffff80000839bcf0 | x26: ffffb37493994180 x25: ffffb374b0991c28 x24: ffffb374b0d70000 | x23: 00000000ffffffea x22: ffffb374afcc33b0 x21: ffffb374b08f9cc8 | x20: ffff572b8462c000 x19: ffffb374b08f9000 x18: ffffffffffffffff | x17: 6c6c6163202c6331 x16: ffffb374ae5ad110 x15: ffffb374b0d51ee4 | x14: 0000000000000000 x13: 3435646532346561 x12: 3437336266666666 | x11: 203a706d61727420 x10: 6465746365707865 x9 : ffffb374ae5149e8 | x8 : 336266666666203a x7 : 706d617274206465 x6 : 00000000fffff167 | x5 : ffff572bffbc4a08 x4 : 00000000fffff167 x3 : 0000000000000000 | x2 : 0000000000000000 x1 : ffff572b84461e00 x0 : 0000000000000022 | Call trace: | ftrace_bug+0x280/0x2b0 | ftrace_replace_code+0x98/0xa0 | ftrace_modify_all_code+0xe0/0x144 | arch_ftrace_update_code+0x14/0x20 | ftrace_startup+0xf8/0x1b0 | register_ftrace_function+0x38/0x90 | test_ftrace_init+0xd0/0x1000 [test_ftrace] | do_one_initcall+0x50/0x2b0 | do_init_module+0x50/0x1f0 | load_module+0x17c8/0x1d64 | __do_sys_finit_module+0xa8/0x100 | __arm64_sys_finit_module+0x2c/0x3c | invoke_syscall+0x50/0x120 | el0_svc_common.constprop.0+0xdc/0x100 | do_el0_svc+0x3c/0xd0 | el0_svc+0x34/0xb0 | el0t_64_sync_handler+0xbc/0x140 | el0t_64_sync+0x18c/0x190 | ---[ end trace 0000000000000000 ]--- We can solve this by consistently determining whether to use a PLT entry for an address. Note that since (the earlier) commit: f1a54ae9 ---truncated--- CVE-2022-49721 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ice: Fix memory corruption in VF driver Disable VF's RX/TX queues, when it's disabled. VF can have queues enabled, when it requests a reset. If PF driver assumes that VF is disabled, while VF still has queues configured, VF may unmap DMA resources. In such scenario device still can map packets to memory, which ends up silently corrupting it. Previously, VF driver could experience memory corruption, which lead to crash: [ 5119.170157] BUG: unable to handle kernel paging request at 00001b9780003237 [ 5119.170166] PGD 0 P4D 0 [ 5119.170173] Oops: 0002 [#1] PREEMPT_RT SMP PTI [ 5119.170181] CPU: 30 PID: 427592 Comm: kworker/u96:2 Kdump: loaded Tainted: G W I --------- - - 4.18.0-372.9.1.rt7.166.el8.x86_64 #1 [ 5119.170189] Hardware name: Dell Inc. PowerEdge R740/014X06, BIOS 2.3.10 08/15/2019 [ 5119.170193] Workqueue: iavf iavf_adminq_task [iavf] [ 5119.170219] RIP: 0010:__page_frag_cache_drain+0x5/0x30 [ 5119.170238] Code: 0f 0f b6 77 51 85 f6 74 07 31 d2 e9 05 df ff ff e9 90 fe ff ff 48 8b 05 49 db 33 01 eb b4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 <f0> 29 77 34 74 01 c3 48 8b 07 f6 c4 80 74 0f 0f b6 77 51 85 f6 74 [ 5119.170244] RSP: 0018:ffffa43b0bdcfd78 EFLAGS: 00010282 [ 5119.170250] RAX: ffffffff896b3e40 RBX: ffff8fb282524000 RCX: 0000000000000002 [ 5119.170254] RDX: 0000000049000000 RSI: 0000000000000000 RDI: 00001b9780003203 [ 5119.170259] RBP: ffff8fb248217b00 R08: 0000000000000022 R09: 0000000000000009 [ 5119.170262] R10: 2b849d6300000000 R11: 0000000000000020 R12: 0000000000000000 [ 5119.170265] R13: 0000000000001000 R14: 0000000000000009 R15: 0000000000000000 [ 5119.170269] FS: 0000000000000000(0000) GS:ffff8fb1201c0000(0000) knlGS:0000000000000000 [ 5119.170274] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5119.170279] CR2: 00001b9780003237 CR3: 00000008f3e1a003 CR4: 00000000007726e0 [ 5119.170283] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 5119.170286] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 5119.170290] PKRU: 55555554 [ 5119.170292] Call Trace: [ 5119.170298] iavf_clean_rx_ring+0xad/0x110 [iavf] [ 5119.170324] iavf_free_rx_resources+0xe/0x50 [iavf] [ 5119.170342] iavf_free_all_rx_resources.part.51+0x30/0x40 [iavf] [ 5119.170358] iavf_virtchnl_completion+0xd8a/0x15b0 [iavf] [ 5119.170377] ? iavf_clean_arq_element+0x210/0x280 [iavf] [ 5119.170397] iavf_adminq_task+0x126/0x2e0 [iavf] [ 5119.170416] process_one_work+0x18f/0x420 [ 5119.170429] worker_thread+0x30/0x370 [ 5119.170437] ? process_one_work+0x420/0x420 [ 5119.170445] kthread+0x151/0x170 [ 5119.170452] ? set_kthread_struct+0x40/0x40 [ 5119.170460] ret_from_fork+0x35/0x40 [ 5119.170477] Modules linked in: iavf sctp ip6_udp_tunnel udp_tunnel mlx4_en mlx4_core nfp tls vhost_net vhost vhost_iotlb tap tun xt_CHECKSUM ipt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache sunrpc intel_rapl_msr iTCO_wdt iTCO_vendor_support dell_smbios wmi_bmof dell_wmi_descriptor dcdbas kvm_intel kvm irqbypass intel_rapl_common isst_if_common skx_edac irdma nfit libnvdimm x86_pkg_temp_thermal i40e intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ib_uverbs rapl ipmi_ssif intel_cstate intel_uncore mei_me pcspkr acpi_ipmi ib_core mei lpc_ich i2c_i801 ipmi_si ipmi_devintf wmi ipmi_msghandler acpi_power_meter xfs libcrc32c sd_mod t10_pi sg mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ice ahci drm libahci crc32c_intel libata tg3 megaraid_sas [ 5119.170613] i2c_algo_bit dm_mirror dm_region_hash dm_log dm_mod fuse [last unloaded: iavf] [ 5119.170627] CR2: 00001b9780003237 CVE-2022-49722 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/i915/reset: Fix error_state_read ptr + offset use Fix our pointer offset usage in error_state_read when there is no i915_gpu_coredump but buf offset is non-zero. This fixes a kernel page fault can happen when multiple tests are running concurrently in a loop and one is producing engine resets and consuming the i915 error_state dump while the other is forcing full GT resets. (takes a while to trigger). The dmesg call trace: [ 5590.803000] BUG: unable to handle page fault for address: ffffffffa0b0e000 [ 5590.803009] #PF: supervisor read access in kernel mode [ 5590.803013] #PF: error_code(0x0000) - not-present page [ 5590.803016] PGD 5814067 P4D 5814067 PUD 5815063 PMD 109de4067 PTE 0 [ 5590.803022] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 5590.803026] CPU: 5 PID: 13656 Comm: i915_hangman Tainted: G U 5.17.0-rc5-ups69-guc-err-capt-rev6+ #136 [ 5590.803033] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-M LP4x RVP, BIOS ADLPFWI1.R00. 3031.A02.2201171222 01/17/2022 [ 5590.803039] RIP: 0010:memcpy_erms+0x6/0x10 [ 5590.803045] Code: fe ff ff cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe [ 5590.803054] RSP: 0018:ffffc90003a8fdf0 EFLAGS: 00010282 [ 5590.803057] RAX: ffff888107ee9000 RBX: ffff888108cb1a00 RCX: 0000000000000f8f [ 5590.803061] RDX: 0000000000001000 RSI: ffffffffa0b0e000 RDI: ffff888107ee9071 [ 5590.803065] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001 [ 5590.803069] R10: 0000000000000001 R11: 0000000000000002 R12: 0000000000000019 [ 5590.803073] R13: 0000000000174fff R14: 0000000000001000 R15: ffff888107ee9000 [ 5590.803077] FS: 00007f62a99bee80(0000) GS:ffff88849f880000(0000) knlGS:0000000000000000 [ 5590.803082] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5590.803085] CR2: ffffffffa0b0e000 CR3: 000000010a1a8004 CR4: 0000000000770ee0 [ 5590.803089] PKRU: 55555554 [ 5590.803091] Call Trace: [ 5590.803093] <TASK> [ 5590.803096] error_state_read+0xa1/0xd0 [i915] [ 5590.803175] kernfs_fop_read_iter+0xb2/0x1b0 [ 5590.803180] new_sync_read+0x116/0x1a0 [ 5590.803185] vfs_read+0x114/0x1b0 [ 5590.803189] ksys_read+0x63/0xe0 [ 5590.803193] do_syscall_64+0x38/0xc0 [ 5590.803197] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 5590.803201] RIP: 0033:0x7f62aaea5912 [ 5590.803204] Code: c0 e9 b2 fe ff ff 50 48 8d 3d 5a b9 0c 00 e8 05 19 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24 [ 5590.803213] RSP: 002b:00007fff5b659ae8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 5590.803218] RAX: ffffffffffffffda RBX: 0000000000100000 RCX: 00007f62aaea5912 [ 5590.803221] RDX: 000000000008b000 RSI: 00007f62a8c4000f RDI: 0000000000000006 [ 5590.803225] RBP: 00007f62a8bcb00f R08: 0000000000200010 R09: 0000000000101000 [ 5590.803229] R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000006 [ 5590.803233] R13: 0000000000075000 R14: 00007f62a8acb010 R15: 0000000000200000 [ 5590.803238] </TASK> [ 5590.803240] Modules linked in: i915 ttm drm_buddy drm_dp_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops prime_numbers nfnetlink br_netfilter overlay mei_pxp mei_hdcp x86_pkg_temp_thermal coretemp kvm_intel snd_hda_codec_hdmi snd_hda_intel ---truncated--- CVE-2022-49723 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: tty: goldfish: Fix free_irq() on remove Pass the correct dev_id to free_irq() to fix this splat when the driver is unbound: WARNING: CPU: 0 PID: 30 at kernel/irq/manage.c:1895 free_irq Trying to free already-free IRQ 65 Call Trace: warn_slowpath_fmt free_irq goldfish_tty_remove platform_remove device_remove device_release_driver_internal device_driver_detach unbind_store drv_attr_store ... CVE-2022-49724 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: i40e: Fix call trace in setup_tx_descriptors After PF reset and ethtool -t there was call trace in dmesg sometimes leading to panic. When there was some time, around 5 seconds, between reset and test there were no errors. Problem was that pf reset calls i40e_vsi_close in prep_for_reset and ethtool -t calls i40e_vsi_close in diag_test. If there was not enough time between those commands the second i40e_vsi_close starts before previous i40e_vsi_close was done which leads to crash. Add check to diag_test if pf is in reset and don't start offline tests if it is true. Add netif_info("testing failed") into unhappy path of i40e_diag_test() CVE-2022-49725 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: clocksource: hyper-v: unexport __init-annotated hv_init_clocksource() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. There are two ways to fix it: - Remove __init - Remove EXPORT_SYMBOL I chose the latter for this case because the only in-tree call-site, arch/x86/kernel/cpu/mshyperv.c is never compiled as modular. (CONFIG_HYPERVISOR_GUEST is boolean) CVE-2022-49726 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred Similar to the handling of play_deferred in commit 19cfe912c37b ("Bluetooth: btusb: Fix memory leak in play_deferred"), we thought a patch might be needed here as well. Currently usb_submit_urb is called directly to submit deferred tx urbs after unanchor them. So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb and cause memory leak. Put those urbs in tx_anchor to avoid the leak, and also fix the error handling. CVE-2022-49729 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 low This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. CVE-2022-49730 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo() In an unlikely (and probably wrong?) case that the 'ppi' parameter of ata_host_alloc_pinfo() points to an array starting with a NULL pointer, there's going to be a kernel oops as the 'pi' local variable won't get reassigned from the initial value of NULL. Initialize 'pi' instead to '&ata_dummy_port_info' to fix the possible kernel oops for good... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. CVE-2022-49731 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: gfs2: Always check inode size of inline inodes Check if the inode size of stuffed (inline) inodes is within the allowed range when reading inodes from disk (gfs2_dinode_in()). This prevents us from on-disk corruption. The two checks in stuffed_readpage() and gfs2_unstuffer_page() that just truncate inline data to the maximum allowed size don't actually make sense, and they can be removed now as well. CVE-2022-49739 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: fbdev: smscufx: fix error handling code in ufx_usb_probe The current error handling code in ufx_usb_probe have many unmatching issues, e.g., missing ufx_free_usb_list, destroy_modedb label should only include framebuffer_release, fb_dealloc_cmap only matches fb_alloc_cmap. My local syzkaller reports a memory leak bug: memory leak in ufx_usb_probe BUG: memory leak unreferenced object 0xffff88802f879580 (size 128): comm "kworker/0:7", pid 17416, jiffies 4295067474 (age 46.710s) hex dump (first 32 bytes): 80 21 7c 2e 80 88 ff ff 18 d0 d0 0c 80 88 ff ff .!|............. 00 d0 d0 0c 80 88 ff ff e0 ff ff ff 0f 00 00 00 ................ backtrace: [<ffffffff814c99a0>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1045 [<ffffffff824d219c>] kmalloc include/linux/slab.h:553 [inline] [<ffffffff824d219c>] kzalloc include/linux/slab.h:689 [inline] [<ffffffff824d219c>] ufx_alloc_urb_list drivers/video/fbdev/smscufx.c:1873 [inline] [<ffffffff824d219c>] ufx_usb_probe+0x11c/0x15a0 drivers/video/fbdev/smscufx.c:1655 [<ffffffff82d17927>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [<ffffffff82712f0d>] call_driver_probe drivers/base/dd.c:560 [inline] [<ffffffff82712f0d>] really_probe+0x12d/0x390 drivers/base/dd.c:639 [<ffffffff8271322f>] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778 [<ffffffff827132da>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:808 [<ffffffff82713c27>] __device_attach_driver+0xf7/0x150 drivers/base/dd.c:936 [<ffffffff82710137>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427 [<ffffffff827136b5>] __device_attach+0x105/0x2d0 drivers/base/dd.c:1008 [<ffffffff82711d36>] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487 [<ffffffff8270e242>] device_add+0x642/0xdc0 drivers/base/core.c:3517 [<ffffffff82d14d5f>] usb_set_configuration+0x8ef/0xb80 drivers/usb/core/message.c:2170 [<ffffffff82d2576c>] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238 [<ffffffff82d16ffc>] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293 [<ffffffff82712f0d>] call_driver_probe drivers/base/dd.c:560 [inline] [<ffffffff82712f0d>] really_probe+0x12d/0x390 drivers/base/dd.c:639 [<ffffffff8271322f>] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778 Fix this bug by rewriting the error handling code in ufx_usb_probe. CVE-2022-49741 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: dmaengine: imx-sdma: Fix a possible memory leak in sdma_transfer_init If the function sdma_load_context() fails, the sdma_desc will be freed, but the allocated desc->bd is forgot to be freed. We already met the sdma_load_context() failure case and the log as below: [ 450.699064] imx-sdma 30bd0000.dma-controller: Timeout waiting for CH0 ready ... In this case, the desc->bd will not be freed without this change. CVE-2022-49746 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd: fix potential integer overflow on shift of a int The left shift of int 32 bit integer constant 1 is evaluated using 32 bit arithmetic and then passed as a 64 bit function argument. In the case where i is 32 or more this can lead to an overflow. Avoid this by shifting using the BIT_ULL macro instead. CVE-2022-49748 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: w1: fix WARNING after calling w1_process() I got the following WARNING message while removing driver(ds2482): ------------[ cut here ]------------ do not call blocking ops when !TASK_RUNNING; state=1 set at [<000000002d50bfb6>] w1_process+0x9e/0x1d0 [wire] WARNING: CPU: 0 PID: 262 at kernel/sched/core.c:9817 __might_sleep+0x98/0xa0 CPU: 0 PID: 262 Comm: w1_bus_master1 Tainted: G N 6.1.0-rc3+ #307 RIP: 0010:__might_sleep+0x98/0xa0 Call Trace: exit_signals+0x6c/0x550 do_exit+0x2b4/0x17e0 kthread_exit+0x52/0x60 kthread+0x16d/0x1e0 ret_from_fork+0x1f/0x30 The state of task is set to TASK_INTERRUPTIBLE in loop in w1_process(), set it to TASK_RUNNING when it breaks out of the loop to avoid the warning. CVE-2022-49751 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: dmaengine: Fix double increment of client_count in dma_chan_get() The first time dma_chan_get() is called for a channel the channel client_count is incorrectly incremented twice for public channels, first in balance_ref_count(), and again prior to returning. This results in an incorrect client count which will lead to the channel resources not being freed when they should be. A simple test of repeated module load and unload of async_tx on a Dell Power Edge R7425 also shows this resulting in a kref underflow warning. [ 124.329662] async_tx: api initialized (async) [ 129.000627] async_tx: api initialized (async) [ 130.047839] ------------[ cut here ]------------ [ 130.052472] refcount_t: underflow; use-after-free. [ 130.057279] WARNING: CPU: 3 PID: 19364 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110 [ 130.065811] Modules linked in: async_tx(-) rfkill intel_rapl_msr intel_rapl_common amd64_edac edac_mce_amd ipmi_ssif kvm_amd dcdbas kvm mgag200 drm_shmem_helper acpi_ipmi irqbypass drm_kms_helper ipmi_si syscopyarea sysfillrect rapl pcspkr ipmi_devintf sysimgblt fb_sys_fops k10temp i2c_piix4 ipmi_msghandler acpi_power_meter acpi_cpufreq vfat fat drm fuse xfs libcrc32c sd_mod t10_pi sg ahci crct10dif_pclmul libahci crc32_pclmul crc32c_intel ghash_clmulni_intel igb megaraid_sas i40e libata i2c_algo_bit ccp sp5100_tco dca dm_mirror dm_region_hash dm_log dm_mod [last unloaded: async_tx] [ 130.117361] CPU: 3 PID: 19364 Comm: modprobe Kdump: loaded Not tainted 5.14.0-185.el9.x86_64 #1 [ 130.126091] Hardware name: Dell Inc. PowerEdge R7425/02MJ3T, BIOS 1.18.0 01/17/2022 [ 130.133806] RIP: 0010:refcount_warn_saturate+0xba/0x110 [ 130.139041] Code: 01 01 e8 6d bd 55 00 0f 0b e9 72 9d 8a 00 80 3d 26 18 9c 01 00 75 85 48 c7 c7 f8 a3 03 9d c6 05 16 18 9c 01 01 e8 4a bd 55 00 <0f> 0b e9 4f 9d 8a 00 80 3d 01 18 9c 01 00 0f 85 5e ff ff ff 48 c7 [ 130.157807] RSP: 0018:ffffbf98898afe68 EFLAGS: 00010286 [ 130.163036] RAX: 0000000000000000 RBX: ffff9da06028e598 RCX: 0000000000000000 [ 130.170172] RDX: ffff9daf9de26480 RSI: ffff9daf9de198a0 RDI: ffff9daf9de198a0 [ 130.177316] RBP: ffff9da7cddf3970 R08: 0000000000000000 R09: 00000000ffff7fff [ 130.184459] R10: ffffbf98898afd00 R11: ffffffff9d9e8c28 R12: ffff9da7cddf1970 [ 130.191596] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 130.198739] FS: 00007f646435c740(0000) GS:ffff9daf9de00000(0000) knlGS:0000000000000000 [ 130.206832] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 130.212586] CR2: 00007f6463b214f0 CR3: 00000008ab98c000 CR4: 00000000003506e0 [ 130.219729] Call Trace: [ 130.222192] <TASK> [ 130.224305] dma_chan_put+0x10d/0x110 [ 130.227988] dmaengine_put+0x7a/0xa0 [ 130.231575] __do_sys_delete_module.constprop.0+0x178/0x280 [ 130.237157] ? syscall_trace_enter.constprop.0+0x145/0x1d0 [ 130.242652] do_syscall_64+0x5c/0x90 [ 130.246240] ? exc_page_fault+0x62/0x150 [ 130.250178] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 130.255243] RIP: 0033:0x7f6463a3f5ab [ 130.258830] Code: 73 01 c3 48 8b 0d 75 a8 1b 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 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 45 a8 1b 00 f7 d8 64 89 01 48 [ 130.277591] RSP: 002b:00007fff22f972c8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [ 130.285164] RAX: ffffffffffffffda RBX: 000055b6786edd40 RCX: 00007f6463a3f5ab [ 130.292303] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055b6786edda8 [ 130.299443] RBP: 000055b6786edd40 R08: 0000000000000000 R09: 0000000000000000 [ 130.306584] R10: 00007f6463b9eac0 R11: 0000000000000206 R12: 000055b6786edda8 [ 130.313731] R13: 0000000000000000 R14: 000055b6786edda8 R15: 00007fff22f995f8 [ 130.320875] </TASK> [ 130.323081] ---[ end trace eff7156d56b5cf25 ]--- cat /sys/class/dma/dma0chan*/in_use would get the wrong result. 2 2 2 Test-by: Jie Hai <haijie1@huawei.com> CVE-2022-49753 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Prevent race during ffs_ep0_queue_wait While performing fast composition switch, there is a possibility that the process of ffs_ep0_write/ffs_ep0_read get into a race condition due to ep0req being freed up from functionfs_unbind. Consider the scenario that the ffs_ep0_write calls the ffs_ep0_queue_wait by taking a lock &ffs->ev.waitq.lock. However, the functionfs_unbind isn't bounded so it can go ahead and mark the ep0req to NULL, and since there is no NULL check in ffs_ep0_queue_wait we will end up in use-after-free. Fix this by making a serialized execution between the two functions using a mutex_lock(ffs->mutex). CVE-2022-49755 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: VMCI: Use threaded irqs instead of tasklets The vmci_dispatch_dgs() tasklet function calls vmci_read_data() which uses wait_event() resulting in invalid sleep in an atomic context (and therefore potentially in a deadlock). Use threaded irqs to fix this issue and completely remove usage of tasklets. [ 20.264639] BUG: sleeping function called from invalid context at drivers/misc/vmw_vmci/vmci_guest.c:145 [ 20.264643] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 762, name: vmtoolsd [ 20.264645] preempt_count: 101, expected: 0 [ 20.264646] RCU nest depth: 0, expected: 0 [ 20.264647] 1 lock held by vmtoolsd/762: [ 20.264648] #0: ffff0000874ae440 (sk_lock-AF_VSOCK){+.+.}-{0:0}, at: vsock_connect+0x60/0x330 [vsock] [ 20.264658] Preemption disabled at: [ 20.264659] [<ffff80000151d7d8>] vmci_send_datagram+0x44/0xa0 [vmw_vmci] [ 20.264665] CPU: 0 PID: 762 Comm: vmtoolsd Not tainted 5.19.0-0.rc8.20220727git39c3c396f813.60.fc37.aarch64 #1 [ 20.264667] Hardware name: VMware, Inc. VBSA/VBSA, BIOS VEFI 12/31/2020 [ 20.264668] Call trace: [ 20.264669] dump_backtrace+0xc4/0x130 [ 20.264672] show_stack+0x24/0x80 [ 20.264673] dump_stack_lvl+0x88/0xb4 [ 20.264676] dump_stack+0x18/0x34 [ 20.264677] __might_resched+0x1a0/0x280 [ 20.264679] __might_sleep+0x58/0x90 [ 20.264681] vmci_read_data+0x74/0x120 [vmw_vmci] [ 20.264683] vmci_dispatch_dgs+0x64/0x204 [vmw_vmci] [ 20.264686] tasklet_action_common.constprop.0+0x13c/0x150 [ 20.264688] tasklet_action+0x40/0x50 [ 20.264689] __do_softirq+0x23c/0x6b4 [ 20.264690] __irq_exit_rcu+0x104/0x214 [ 20.264691] irq_exit_rcu+0x1c/0x50 [ 20.264693] el1_interrupt+0x38/0x6c [ 20.264695] el1h_64_irq_handler+0x18/0x24 [ 20.264696] el1h_64_irq+0x68/0x6c [ 20.264697] preempt_count_sub+0xa4/0xe0 [ 20.264698] _raw_spin_unlock_irqrestore+0x64/0xb0 [ 20.264701] vmci_send_datagram+0x7c/0xa0 [vmw_vmci] [ 20.264703] vmci_datagram_dispatch+0x84/0x100 [vmw_vmci] [ 20.264706] vmci_datagram_send+0x2c/0x40 [vmw_vmci] [ 20.264709] vmci_transport_send_control_pkt+0xb8/0x120 [vmw_vsock_vmci_transport] [ 20.264711] vmci_transport_connect+0x40/0x7c [vmw_vsock_vmci_transport] [ 20.264713] vsock_connect+0x278/0x330 [vsock] [ 20.264715] __sys_connect_file+0x8c/0xc0 [ 20.264718] __sys_connect+0x84/0xb4 [ 20.264720] __arm64_sys_connect+0x2c/0x3c [ 20.264721] invoke_syscall+0x78/0x100 [ 20.264723] el0_svc_common.constprop.0+0x68/0x124 [ 20.264724] do_el0_svc+0x38/0x4c [ 20.264725] el0_svc+0x60/0x180 [ 20.264726] el0t_64_sync_handler+0x11c/0x150 [ 20.264728] el0t_64_sync+0x190/0x194 CVE-2022-49759 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: 9p/trans_fd: always use O_NONBLOCK read/write syzbot is reporting hung task at p9_fd_close() [1], for p9_mux_poll_stop() from p9_conn_destroy() from p9_fd_close() is failing to interrupt already started kernel_read() from p9_fd_read() from p9_read_work() and/or kernel_write() from p9_fd_write() from p9_write_work() requests. Since p9_socket_open() sets O_NONBLOCK flag, p9_mux_poll_stop() does not need to interrupt kernel_read()/kernel_write(). However, since p9_fd_open() does not set O_NONBLOCK flag, but pipe blocks unless signal is pending, p9_mux_poll_stop() needs to interrupt kernel_read()/kernel_write() when the file descriptor refers to a pipe. In other words, pipe file descriptor needs to be handled as if socket file descriptor. We somehow need to interrupt kernel_read()/kernel_write() on pipes. A minimal change, which this patch is doing, is to set O_NONBLOCK flag from p9_fd_open(), for O_NONBLOCK flag does not affect reading/writing of regular files. But this approach changes O_NONBLOCK flag on userspace- supplied file descriptors (which might break userspace programs), and O_NONBLOCK flag could be changed by userspace. It would be possible to set O_NONBLOCK flag every time p9_fd_read()/p9_fd_write() is invoked, but still remains small race window for clearing O_NONBLOCK flag. If we don't want to manipulate O_NONBLOCK flag, we might be able to surround kernel_read()/kernel_write() with set_thread_flag(TIF_SIGPENDING) and recalc_sigpending(). Since p9_read_work()/p9_write_work() works are processed by kernel threads which process global system_wq workqueue, signals could not be delivered from remote threads when p9_mux_poll_stop() from p9_conn_destroy() from p9_fd_close() is called. Therefore, calling set_thread_flag(TIF_SIGPENDING)/recalc_sigpending() every time would be needed if we count on signals for making kernel_read()/kernel_write() non-blocking. [Dominique: add comment at Christian's suggestion] CVE-2022-49767 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: gfs2: Check sb_bsize_shift after reading superblock Fuzzers like to scribble over sb_bsize_shift but in reality it's very unlikely that this field would be corrupted on its own. Nevertheless it should be checked to avoid the possibility of messy mount errors due to bad calculations. It's always a fixed value based on the block size so we can just check that it's the expected value. Tested with: mkfs.gfs2 -O -p lock_nolock /dev/vdb for i in 0 -1 64 65 32 33; do gfs2_edit -p sb field sb_bsize_shift $i /dev/vdb mount /dev/vdb /mnt/test && umount /mnt/test done Before this patch we get a withdraw after [ 76.413681] gfs2: fsid=loop0.0: fatal: invalid metadata block [ 76.413681] bh = 19 (type: exp=5, found=4) [ 76.413681] function = gfs2_meta_buffer, file = fs/gfs2/meta_io.c, line = 492 and with UBSAN configured we also get complaints like [ 76.373395] UBSAN: shift-out-of-bounds in fs/gfs2/ops_fstype.c:295:19 [ 76.373815] shift exponent 4294967287 is too large for 64-bit type 'long unsigned int' After the patch, these complaints don't appear, mount fails immediately and we get an explanation in dmesg. CVE-2022-49769 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ceph: avoid putting the realm twice when decoding snaps fails When decoding the snaps fails it maybe leaving the 'first_realm' and 'realm' pointing to the same snaprealm memory. And then it'll put it twice and could cause random use-after-free, BUG_ON, etc issues. CVE-2022-49770 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: dm ioctl: fix misbehavior if list_versions races with module loading __list_versions will first estimate the required space using the "dm_target_iterate(list_version_get_needed, &needed)" call and then will fill the space using the "dm_target_iterate(list_version_get_info, &iter_info)" call. Each of these calls locks the targets using the "down_read(&_lock)" and "up_read(&_lock)" calls, however between the first and second "dm_target_iterate" there is no lock held and the target modules can be loaded at this point, so the second "dm_target_iterate" call may need more space than what was the first "dm_target_iterate" returned. The code tries to handle this overflow (see the beginning of list_version_get_info), however this handling is incorrect. The code sets "param->data_size = param->data_start + needed" and "iter_info.end = (char *)vers+len" - "needed" is the size returned by the first dm_target_iterate call; "len" is the size of the buffer allocated by userspace. "len" may be greater than "needed"; in this case, the code will write up to "len" bytes into the buffer, however param->data_size is set to "needed", so it may write data past the param->data_size value. The ioctl interface copies only up to param->data_size into userspace, thus part of the result will be truncated. Fix this bug by setting "iter_info.end = (char *)vers + needed;" - this guarantees that the second "dm_target_iterate" call will write only up to the "needed" buffer and it will exit with "DM_BUFFER_FULL_FLAG" if it overflows the "needed" space - in this case, userspace will allocate a larger buffer and retry. Note that there is also a bug in list_version_get_needed - we need to add "strlen(tt->name) + 1" to the needed size, not "strlen(tt->name)". CVE-2022-49771 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Drop snd_BUG_ON() from snd_usbmidi_output_open() snd_usbmidi_output_open() has a check of the NULL port with snd_BUG_ON(). snd_BUG_ON() was used as this shouldn't have happened, but in reality, the NULL port may be seen when the device gives an invalid endpoint setup at the descriptor, hence the driver skips the allocation. That is, the check itself is valid and snd_BUG_ON() should be dropped from there. Otherwise it's confusing as if it were a real bug, as recently syzbot stumbled on it. CVE-2022-49772 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: tcp: cdg: allow tcp_cdg_release() to be called multiple times Apparently, mptcp is able to call tcp_disconnect() on an already disconnected flow. This is generally fine, unless current congestion control is CDG, because it might trigger a double-free [1] Instead of fixing MPTCP, and future bugs, we can make tcp_disconnect() more resilient. [1] BUG: KASAN: double-free in slab_free mm/slub.c:3539 [inline] BUG: KASAN: double-free in kfree+0xe2/0x580 mm/slub.c:4567 CPU: 0 PID: 3645 Comm: kworker/0:7 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Workqueue: events mptcp_worker Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x719 mm/kasan/report.c:433 kasan_report_invalid_free+0x81/0x190 mm/kasan/report.c:462 ____kasan_slab_free+0x18b/0x1c0 mm/kasan/common.c:356 kasan_slab_free include/linux/kasan.h:200 [inline] slab_free_hook mm/slub.c:1759 [inline] slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1785 slab_free mm/slub.c:3539 [inline] kfree+0xe2/0x580 mm/slub.c:4567 tcp_disconnect+0x980/0x1e20 net/ipv4/tcp.c:3145 __mptcp_close_ssk+0x5ca/0x7e0 net/mptcp/protocol.c:2327 mptcp_do_fastclose net/mptcp/protocol.c:2592 [inline] mptcp_worker+0x78c/0xff0 net/mptcp/protocol.c:2627 process_one_work+0x991/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> Allocated by task 3671: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:45 [inline] set_alloc_info mm/kasan/common.c:437 [inline] ____kasan_kmalloc mm/kasan/common.c:516 [inline] ____kasan_kmalloc mm/kasan/common.c:475 [inline] __kasan_kmalloc+0xa9/0xd0 mm/kasan/common.c:525 kmalloc_array include/linux/slab.h:640 [inline] kcalloc include/linux/slab.h:671 [inline] tcp_cdg_init+0x10d/0x170 net/ipv4/tcp_cdg.c:380 tcp_init_congestion_control+0xab/0x550 net/ipv4/tcp_cong.c:193 tcp_reinit_congestion_control net/ipv4/tcp_cong.c:217 [inline] tcp_set_congestion_control+0x96c/0xaa0 net/ipv4/tcp_cong.c:391 do_tcp_setsockopt+0x505/0x2320 net/ipv4/tcp.c:3513 tcp_setsockopt+0xd4/0x100 net/ipv4/tcp.c:3801 mptcp_setsockopt+0x35f/0x2570 net/mptcp/sockopt.c:844 __sys_setsockopt+0x2d6/0x690 net/socket.c:2252 __do_sys_setsockopt net/socket.c:2263 [inline] __se_sys_setsockopt net/socket.c:2260 [inline] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2260 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task 16: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track+0x21/0x30 mm/kasan/common.c:45 kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370 ____kasan_slab_free mm/kasan/common.c:367 [inline] ____kasan_slab_free+0x166/0x1c0 mm/kasan/common.c:329 kasan_slab_free include/linux/kasan.h:200 [inline] slab_free_hook mm/slub.c:1759 [inline] slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1785 slab_free mm/slub.c:3539 [inline] kfree+0xe2/0x580 mm/slub.c:4567 tcp_cleanup_congestion_control+0x70/0x120 net/ipv4/tcp_cong.c:226 tcp_v4_destroy_sock+0xdd/0x750 net/ipv4/tcp_ipv4.c:2254 tcp_v6_destroy_sock+0x11/0x20 net/ipv6/tcp_ipv6.c:1969 inet_csk_destroy_sock+0x196/0x440 net/ipv4/inet_connection_sock.c:1157 tcp_done+0x23b/0x340 net/ipv4/tcp.c:4649 tcp_rcv_state_process+0x40e7/0x4990 net/ipv4/tcp_input.c:6624 tcp_v6_do_rcv+0x3fc/0x13c0 net/ipv6/tcp_ipv6.c:1525 tcp_v6_rcv+0x2e8e/0x3830 net/ipv6/tcp_ipv6.c:1759 ip6_protocol_deliver_rcu+0x2db/0x1950 net/ipv6/ip6_input.c:439 ip6_input_finish+0x14c/0x2c0 net/ipv6/ip6_input.c:484 NF_HOOK include/linux/netfilter.h:302 [inline] NF_HOOK include/linux/netfilter.h:296 [inline] ip6_input+0x9c/0xd ---truncated--- CVE-2022-49775 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: macvlan: enforce a consistent minimal mtu macvlan should enforce a minimal mtu of 68, even at link creation. This patch avoids the current behavior (which could lead to crashes in ipv6 stack if the link is brought up) $ ip link add macvlan1 link eno1 mtu 8 type macvlan # This should fail ! $ ip link sh dev macvlan1 5: macvlan1@eno1: <BROADCAST,MULTICAST> mtu 8 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 02:47:6c:24:74:82 brd ff:ff:ff:ff:ff:ff $ ip link set macvlan1 mtu 67 Error: mtu less than device minimum. $ ip link set macvlan1 mtu 68 $ ip link set macvlan1 mtu 8 Error: mtu less than device minimum. CVE-2022-49776 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: Input: i8042 - fix leaking of platform device on module removal Avoid resetting the module-wide i8042_platform_device pointer in i8042_probe() or i8042_remove(), so that the device can be properly destroyed by i8042_exit() on module unload. CVE-2022-49777 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: kprobes: Skip clearing aggrprobe's post_handler in kprobe-on-ftrace case In __unregister_kprobe_top(), if the currently unregistered probe has post_handler but other child probes of the aggrprobe do not have post_handler, the post_handler of the aggrprobe is cleared. If this is a ftrace-based probe, there is a problem. In later calls to disarm_kprobe(), we will use kprobe_ftrace_ops because post_handler is NULL. But we're armed with kprobe_ipmodify_ops. This triggers a WARN in __disarm_kprobe_ftrace() and may even cause use-after-free: Failed to disarm kprobe-ftrace at kernel_clone+0x0/0x3c0 (error -2) WARNING: CPU: 5 PID: 137 at kernel/kprobes.c:1135 __disarm_kprobe_ftrace.isra.21+0xcf/0xe0 Modules linked in: testKprobe_007(-) CPU: 5 PID: 137 Comm: rmmod Not tainted 6.1.0-rc4-dirty #18 [...] Call Trace: <TASK> __disable_kprobe+0xcd/0xe0 __unregister_kprobe_top+0x12/0x150 ? mutex_lock+0xe/0x30 unregister_kprobes.part.23+0x31/0xa0 unregister_kprobe+0x32/0x40 __x64_sys_delete_module+0x15e/0x260 ? do_user_addr_fault+0x2cd/0x6b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] For the kprobe-on-ftrace case, we keep the post_handler setting to identify this aggrprobe armed with kprobe_ipmodify_ops. This way we can disarm it correctly. CVE-2022-49779 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Drop fpregs lock before inheriting FPU permissions Mike Galbraith reported the following against an old fork of preempt-rt but the same issue also applies to the current preempt-rt tree. BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: systemd preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 Preemption disabled at: fpu_clone CPU: 6 PID: 1 Comm: systemd Tainted: G E (unreleased) Call Trace: <TASK> dump_stack_lvl ? fpu_clone __might_resched rt_spin_lock fpu_clone ? copy_thread ? copy_process ? shmem_alloc_inode ? kmem_cache_alloc ? kernel_clone ? __do_sys_clone ? do_syscall_64 ? __x64_sys_rt_sigprocmask ? syscall_exit_to_user_mode ? do_syscall_64 ? syscall_exit_to_user_mode ? do_syscall_64 ? syscall_exit_to_user_mode ? do_syscall_64 ? exc_page_fault ? entry_SYSCALL_64_after_hwframe </TASK> Mike says: The splat comes from fpu_inherit_perms() being called under fpregs_lock(), and us reaching the spin_lock_irq() therein due to fpu_state_size_dynamic() returning true despite static key __fpu_state_size_dynamic having never been enabled. Mike's assessment looks correct. fpregs_lock on a PREEMPT_RT kernel disables preemption so calling spin_lock_irq() in fpu_inherit_perms() is unsafe. This problem exists since commit 9e798e9aa14c ("x86/fpu: Prepare fpu_clone() for dynamically enabled features"). Even though the original bug report should not have enabled the paths at all, the bug still exists. fpregs_lock is necessary when editing the FPU registers or a task's FP state but it is not necessary for fpu_inherit_perms(). The only write of any FP state in fpu_inherit_perms() is for the new child which is not running yet and cannot context switch or be borrowed by a kernel thread yet. Hence, fpregs_lock is not protecting anything in the new child until clone() completes and can be dropped earlier. The siglock still needs to be acquired by fpu_inherit_perms() as the read of the parent's permissions has to be serialised. [ bp: Cleanup splat. ] CVE-2022-49783 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: mmc: sdhci-pci: Fix possible memory leak caused by missing pci_dev_put() pci_get_device() will increase the reference count for the returned pci_dev. We need to use pci_dev_put() to decrease the reference count before amd_probe() returns. There is no problem for the 'smbus_dev == NULL' branch because pci_dev_put() can also handle the NULL input parameter case. CVE-2022-49787 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: misc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram() `struct vmci_event_qp` allocated by qp_notify_peer() contains padding, which may carry uninitialized data to the userspace, as observed by KMSAN: BUG: KMSAN: kernel-infoleak in instrument_copy_to_user ./include/linux/instrumented.h:121 instrument_copy_to_user ./include/linux/instrumented.h:121 _copy_to_user+0x5f/0xb0 lib/usercopy.c:33 copy_to_user ./include/linux/uaccess.h:169 vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:431 vmci_host_unlocked_ioctl+0x33d/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:925 vfs_ioctl fs/ioctl.c:51 ... Uninit was stored to memory at: kmemdup+0x74/0xb0 mm/util.c:131 dg_dispatch_as_host drivers/misc/vmw_vmci/vmci_datagram.c:271 vmci_datagram_dispatch+0x4f8/0xfc0 drivers/misc/vmw_vmci/vmci_datagram.c:339 qp_notify_peer+0x19a/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1479 qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662 qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750 vmci_qp_broker_alloc+0x96/0xd0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1940 vmci_host_do_alloc_queuepair drivers/misc/vmw_vmci/vmci_host.c:488 vmci_host_unlocked_ioctl+0x24fd/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:927 ... Local variable ev created at: qp_notify_peer+0x54/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1456 qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662 qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750 Bytes 28-31 of 48 are uninitialized Memory access of size 48 starts at ffff888035155e00 Data copied to user address 0000000020000100 Use memset() to prevent the infoleaks. Also speculatively fix qp_notify_peer_local(), which may suffer from the same problem. CVE-2022-49788 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: zfcp: Fix double free of FSF request when qdio send fails We used to use the wrong type of integer in 'zfcp_fsf_req_send()' to cache the FSF request ID when sending a new FSF request. This is used in case the sending fails and we need to remove the request from our internal hash table again (so we don't keep an invalid reference and use it when we free the request again). In 'zfcp_fsf_req_send()' we used to cache the ID as 'int' (signed and 32 bit wide), but the rest of the zfcp code (and the firmware specification) handles the ID as 'unsigned long'/'u64' (unsigned and 64 bit wide [s390x ELF ABI]). For one this has the obvious problem that when the ID grows past 32 bit (this can happen reasonably fast) it is truncated to 32 bit when storing it in the cache variable and so doesn't match the original ID anymore. The second less obvious problem is that even when the original ID has not yet grown past 32 bit, as soon as the 32nd bit is set in the original ID (0x80000000 = 2'147'483'648) we will have a mismatch when we cast it back to 'unsigned long'. As the cached variable is of a signed type, the compiler will choose a sign-extending instruction to load the 32 bit variable into a 64 bit register (e.g.: 'lgf %r11,188(%r15)'). So once we pass the cached variable into 'zfcp_reqlist_find_rm()' to remove the request again all the leading zeros will be flipped to ones to extend the sign and won't match the original ID anymore (this has been observed in practice). If we can't successfully remove the request from the hash table again after 'zfcp_qdio_send()' fails (this happens regularly when zfcp cannot notify the adapter about new work because the adapter is already gone during e.g. a ChpID toggle) we will end up with a double free. We unconditionally free the request in the calling function when 'zfcp_fsf_req_send()' fails, but because the request is still in the hash table we end up with a stale memory reference, and once the zfcp adapter is either reset during recovery or shutdown we end up freeing the same memory twice. The resulting stack traces vary depending on the kernel and have no direct correlation to the place where the bug occurs. Here are three examples that have been seen in practice: list_del corruption. next->prev should be 00000001b9d13800, but was 00000000dead4ead. (next=00000001bd131a00) ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:62! monitor event: 0040 ilc:2 [#1] PREEMPT SMP Modules linked in: ... CPU: 9 PID: 1617 Comm: zfcperp0.0.1740 Kdump: loaded Hardware name: ... Krnl PSW : 0704d00180000000 00000003cbeea1f8 (__list_del_entry_valid+0x98/0x140) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 Krnl GPRS: 00000000916d12f1 0000000080000000 000000000000006d 00000003cb665cd6 0000000000000001 0000000000000000 0000000000000000 00000000d28d21e8 00000000d3844000 00000380099efd28 00000001bd131a00 00000001b9d13800 00000000d3290100 0000000000000000 00000003cbeea1f4 00000380099efc70 Krnl Code: 00000003cbeea1e8: c020004f68a7 larl %r2,00000003cc8d7336 00000003cbeea1ee: c0e50027fd65 brasl %r14,00000003cc3e9cb8 #00000003cbeea1f4: af000000 mc 0,0 >00000003cbeea1f8: c02000920440 larl %r2,00000003cd12aa78 00000003cbeea1fe: c0e500289c25 brasl %r14,00000003cc3fda48 00000003cbeea204: b9040043 lgr %r4,%r3 00000003cbeea208: b9040051 lgr %r5,%r1 00000003cbeea20c: b9040032 lgr %r3,%r2 Call Trace: [<00000003cbeea1f8>] __list_del_entry_valid+0x98/0x140 ([<00000003cbeea1f4>] __list_del_entry_valid+0x94/0x140) [<000003ff7ff502fe>] zfcp_fsf_req_dismiss_all+0xde/0x150 [zfcp] [<000003ff7ff49cd0>] zfcp_erp_strategy_do_action+0x160/0x280 [zfcp] ---truncated--- CVE-2022-49789 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: Input: iforce - invert valid length check when fetching device IDs syzbot is reporting uninitialized value at iforce_init_device() [1], for commit 6ac0aec6b0a6 ("Input: iforce - allow callers supply data buffer when fetching device IDs") is checking that valid length is shorter than bytes to read. Since iforce_get_id_packet() stores valid length when returning 0, the caller needs to check that valid length is longer than or equals to bytes to read. CVE-2022-49790 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: iio: adc: mp2629: fix potential array out of bound access Add sentinel at end of maps to avoid potential array out of bound access in iio core. CVE-2022-49792 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: iio: trigger: sysfs: fix possible memory leak in iio_sysfs_trig_init() dev_set_name() allocates memory for name, it need be freed when device_add() fails, call put_device() to give up the reference that hold in device_initialize(), so that it can be freed in kobject_cleanup() when the refcount hit to 0. Fault injection test can trigger this: unreferenced object 0xffff8e8340a7b4c0 (size 32): comm "modprobe", pid 243, jiffies 4294678145 (age 48.845s) hex dump (first 32 bytes): 69 69 6f 5f 73 79 73 66 73 5f 74 72 69 67 67 65 iio_sysfs_trigge 72 00 a7 40 83 8e ff ff 00 86 13 c4 f6 ee ff ff r..@............ backtrace: [<0000000074999de8>] __kmem_cache_alloc_node+0x1e9/0x360 [<00000000497fd30b>] __kmalloc_node_track_caller+0x44/0x1a0 [<000000003636c520>] kstrdup+0x2d/0x60 [<0000000032f84da2>] kobject_set_name_vargs+0x1e/0x90 [<0000000092efe493>] dev_set_name+0x4e/0x70 CVE-2022-49793 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: iio: adc: at91_adc: fix possible memory leak in at91_adc_allocate_trigger() If iio_trigger_register() returns error, it should call iio_trigger_free() to give up the reference that hold in iio_trigger_alloc(), so that it can call iio_trig_release() to free memory when the refcount hit to 0. CVE-2022-49794 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: tracing: kprobe: Fix potential null-ptr-deref on trace_array in kprobe_event_gen_test_exit() When test_gen_kprobe_cmd() failed after kprobe_event_gen_cmd_end(), it will goto delete, which will call kprobe_event_delete() and release the corresponding resource. However, the trace_array in gen_kretprobe_test will point to the invalid resource. Set gen_kretprobe_test to NULL after called kprobe_event_delete() to prevent null-ptr-deref. BUG: kernel NULL pointer dereference, address: 0000000000000070 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 246 Comm: modprobe Tainted: G W 6.1.0-rc1-00174-g9522dc5c87da-dirty #248 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:__ftrace_set_clr_event_nolock+0x53/0x1b0 Code: e8 82 26 fc ff 49 8b 1e c7 44 24 0c ea ff ff ff 49 39 de 0f 84 3c 01 00 00 c7 44 24 18 00 00 00 00 e8 61 26 fc ff 48 8b 6b 10 <44> 8b 65 70 4c 8b 6d 18 41 f7 c4 00 02 00 00 75 2f RSP: 0018:ffffc9000159fe00 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff88810971d268 RCX: 0000000000000000 RDX: ffff8881080be600 RSI: ffffffff811b48ff RDI: ffff88810971d058 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: ffffc9000159fe58 R11: 0000000000000001 R12: ffffffffa0001064 R13: ffffffffa000106c R14: ffff88810971d238 R15: 0000000000000000 FS: 00007f89eeff6540(0000) GS:ffff88813b600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000070 CR3: 000000010599e004 CR4: 0000000000330ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __ftrace_set_clr_event+0x3e/0x60 trace_array_set_clr_event+0x35/0x50 ? 0xffffffffa0000000 kprobe_event_gen_test_exit+0xcd/0x10b [kprobe_event_gen_test] __x64_sys_delete_module+0x206/0x380 ? lockdep_hardirqs_on_prepare+0xd8/0x190 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f89eeb061b7 CVE-2022-49796 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: tracing: kprobe: Fix potential null-ptr-deref on trace_event_file in kprobe_event_gen_test_exit() When trace_get_event_file() failed, gen_kretprobe_test will be assigned as the error code. If module kprobe_event_gen_test is removed now, the null pointer dereference will happen in kprobe_event_gen_test_exit(). Check if gen_kprobe_test or gen_kretprobe_test is error code or NULL before dereference them. BUG: kernel NULL pointer dereference, address: 0000000000000012 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 3 PID: 2210 Comm: modprobe Not tainted 6.1.0-rc1-00171-g2159299a3b74-dirty #217 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:kprobe_event_gen_test_exit+0x1c/0xb5 [kprobe_event_gen_test] Code: Unable to access opcode bytes at 0xffffffff9ffffff2. RSP: 0018:ffffc900015bfeb8 EFLAGS: 00010246 RAX: ffffffffffffffea RBX: ffffffffa0002080 RCX: 0000000000000000 RDX: ffffffffa0001054 RSI: ffffffffa0001064 RDI: ffffffffdfc6349c RBP: ffffffffa0000000 R08: 0000000000000004 R09: 00000000001e95c0 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000800 R13: ffffffffa0002420 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f56b75be540(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff9ffffff2 CR3: 000000010874a006 CR4: 0000000000330ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __x64_sys_delete_module+0x206/0x380 ? lockdep_hardirqs_on_prepare+0xd8/0x190 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd CVE-2022-49797 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: tracing: Fix wild-memory-access in register_synth_event() In register_synth_event(), if set_synth_event_print_fmt() failed, then both trace_remove_event_call() and unregister_trace_event() will be called, which means the trace_event_call will call __unregister_trace_event() twice. As the result, the second unregister will causes the wild-memory-access. register_synth_event set_synth_event_print_fmt failed trace_remove_event_call event_remove if call->event.funcs then __unregister_trace_event (first call) unregister_trace_event __unregister_trace_event (second call) Fix the bug by avoiding to call the second __unregister_trace_event() by checking if the first one is called. general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN PTI KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] CPU: 0 PID: 3807 Comm: modprobe Not tainted 6.1.0-rc1-00186-g76f33a7eedb4 #299 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:unregister_trace_event+0x6e/0x280 Code: 00 fc ff df 4c 89 ea 48 c1 ea 03 80 3c 02 00 0f 85 0e 02 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 63 08 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f 85 e2 01 00 00 49 89 2c 24 48 85 ed 74 28 e8 7a 9b RSP: 0018:ffff88810413f370 EFLAGS: 00010a06 RAX: dffffc0000000000 RBX: ffff888105d050b0 RCX: 0000000000000000 RDX: 1bd5a00000000024 RSI: ffff888119e276e0 RDI: ffffffff835a8b20 RBP: dead000000000100 R08: 0000000000000000 R09: fffffbfff0913481 R10: ffffffff8489a407 R11: fffffbfff0913480 R12: dead000000000122 R13: ffff888105d050b8 R14: 0000000000000000 R15: ffff888105d05028 FS: 00007f7823e8d540(0000) GS:ffff888119e00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7823e7ebec CR3: 000000010a058002 CR4: 0000000000330ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __create_synth_event+0x1e37/0x1eb0 create_or_delete_synth_event+0x110/0x250 synth_event_run_command+0x2f/0x110 test_gen_synth_cmd+0x170/0x2eb [synth_event_gen_test] synth_event_gen_test_init+0x76/0x9bc [synth_event_gen_test] do_one_initcall+0xdb/0x480 do_init_module+0x1cf/0x680 load_module+0x6a50/0x70a0 __do_sys_finit_module+0x12f/0x1c0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd CVE-2022-49799 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: tracing: Fix memory leak in test_gen_synth_cmd() and test_empty_synth_event() test_gen_synth_cmd() only free buf in fail path, hence buf will leak when there is no failure. Add kfree(buf) to prevent the memleak. The same reason and solution in test_empty_synth_event(). unreferenced object 0xffff8881127de000 (size 2048): comm "modprobe", pid 247, jiffies 4294972316 (age 78.756s) hex dump (first 32 bytes): 20 67 65 6e 5f 73 79 6e 74 68 5f 74 65 73 74 20 gen_synth_test 20 70 69 64 5f 74 20 6e 65 78 74 5f 70 69 64 5f pid_t next_pid_ backtrace: [<000000004254801a>] kmalloc_trace+0x26/0x100 [<0000000039eb1cf5>] 0xffffffffa00083cd [<000000000e8c3bc8>] 0xffffffffa00086ba [<00000000c293d1ea>] do_one_initcall+0xdb/0x480 [<00000000aa189e6d>] do_init_module+0x1cf/0x680 [<00000000d513222b>] load_module+0x6a50/0x70a0 [<000000001fd4d529>] __do_sys_finit_module+0x12f/0x1c0 [<00000000b36c4c0f>] do_syscall_64+0x3f/0x90 [<00000000bbf20cf3>] entry_SYSCALL_64_after_hwframe+0x63/0xcd unreferenced object 0xffff8881127df000 (size 2048): comm "modprobe", pid 247, jiffies 4294972324 (age 78.728s) hex dump (first 32 bytes): 20 65 6d 70 74 79 5f 73 79 6e 74 68 5f 74 65 73 empty_synth_tes 74 20 20 70 69 64 5f 74 20 6e 65 78 74 5f 70 69 t pid_t next_pi backtrace: [<000000004254801a>] kmalloc_trace+0x26/0x100 [<00000000d4db9a3d>] 0xffffffffa0008071 [<00000000c31354a5>] 0xffffffffa00086ce [<00000000c293d1ea>] do_one_initcall+0xdb/0x480 [<00000000aa189e6d>] do_init_module+0x1cf/0x680 [<00000000d513222b>] load_module+0x6a50/0x70a0 [<000000001fd4d529>] __do_sys_finit_module+0x12f/0x1c0 [<00000000b36c4c0f>] do_syscall_64+0x3f/0x90 [<00000000bbf20cf3>] entry_SYSCALL_64_after_hwframe+0x63/0xcd CVE-2022-49800 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: tracing: Fix memory leak in tracing_read_pipe() kmemleak reports this issue: unreferenced object 0xffff888105a18900 (size 128): comm "test_progs", pid 18933, jiffies 4336275356 (age 22801.766s) hex dump (first 32 bytes): 25 73 00 90 81 88 ff ff 26 05 00 00 42 01 58 04 %s......&...B.X. 03 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000560143a1>] __kmalloc_node_track_caller+0x4a/0x140 [<000000006af00822>] krealloc+0x8d/0xf0 [<00000000c309be6a>] trace_iter_expand_format+0x99/0x150 [<000000005a53bdb6>] trace_check_vprintf+0x1e0/0x11d0 [<0000000065629d9d>] trace_event_printf+0xb6/0xf0 [<000000009a690dc7>] trace_raw_output_bpf_trace_printk+0x89/0xc0 [<00000000d22db172>] print_trace_line+0x73c/0x1480 [<00000000cdba76ba>] tracing_read_pipe+0x45c/0x9f0 [<0000000015b58459>] vfs_read+0x17b/0x7c0 [<000000004aeee8ed>] ksys_read+0xed/0x1c0 [<0000000063d3d898>] do_syscall_64+0x3b/0x90 [<00000000a06dda7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd iter->fmt alloced in tracing_read_pipe() -> .. ->trace_iter_expand_format(), but not freed, to fix, add free in tracing_release_pipe() CVE-2022-49801 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix null pointer dereference in ftrace_add_mod() The @ftrace_mod is allocated by kzalloc(), so both the members {prev,next} of @ftrace_mode->list are NULL, it's not a valid state to call list_del(). If kstrdup() for @ftrace_mod->{func|module} fails, it goes to @out_free tag and calls free_ftrace_mod() to destroy @ftrace_mod, then list_del() will write prev->next and next->prev, where null pointer dereference happens. BUG: kernel NULL pointer dereference, address: 0000000000000008 Oops: 0002 [#1] PREEMPT SMP NOPTI Call Trace: <TASK> ftrace_mod_callback+0x20d/0x220 ? do_filp_open+0xd9/0x140 ftrace_process_regex.isra.51+0xbf/0x130 ftrace_regex_write.isra.52.part.53+0x6e/0x90 vfs_write+0xee/0x3a0 ? __audit_filter_op+0xb1/0x100 ? auditd_test_task+0x38/0x50 ksys_write+0xa5/0xe0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Kernel panic - not syncing: Fatal exception So call INIT_LIST_HEAD() to initialize the list member to fix this issue. CVE-2022-49802 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: nvmet: fix a memory leak in nvmet_auth_set_key When changing dhchap secrets we need to release the old secrets as well. kmemleak complaint: -- unreferenced object 0xffff8c7f44ed8180 (size 64): comm "check", pid 7304, jiffies 4295686133 (age 72034.246s) hex dump (first 32 bytes): 44 48 48 43 2d 31 3a 30 30 3a 4c 64 4c 4f 64 71 DHHC-1:00:LdLOdq 79 56 69 67 77 48 55 32 6d 5a 59 4c 7a 35 59 38 yVigwHU2mZYLz5Y8 backtrace: [<00000000b6fc5071>] kstrdup+0x2e/0x60 [<00000000f0f4633f>] 0xffffffffc0e07ee6 [<0000000053006c05>] 0xffffffffc0dff783 [<00000000419ae922>] configfs_write_iter+0xb1/0x120 [<000000008183c424>] vfs_write+0x2be/0x3c0 [<000000009005a2a5>] ksys_write+0x5f/0xe0 [<00000000cd495c89>] do_syscall_64+0x38/0x90 [<00000000f2a84ac5>] entry_SYSCALL_64_after_hwframe+0x63/0xcd CVE-2022-49807 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/x25: Fix skb leak in x25_lapb_receive_frame() x25_lapb_receive_frame() using skb_copy() to get a private copy of skb, the new skb should be freed in the undersized/fragmented skb error handling path. Otherwise there is a memory leak. CVE-2022-49809 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: netfs: Fix missing xas_retry() calls in xarray iteration netfslib has a number of places in which it performs iteration of an xarray whilst being under the RCU read lock. It *should* call xas_retry() as the first thing inside of the loop and do "continue" if it returns true in case the xarray walker passed out a special value indicating that the walk needs to be redone from the root[*]. Fix this by adding the missing retry checks. [*] I wonder if this should be done inside xas_find(), xas_next_node() and suchlike, but I'm told that's not an simple change to effect. This can cause an oops like that below. Note the faulting address - this is an internal value (|0x2) returned from xarray. BUG: kernel NULL pointer dereference, address: 0000000000000402 ... RIP: 0010:netfs_rreq_unlock+0xef/0x380 [netfs] ... Call Trace: netfs_rreq_assess+0xa6/0x240 [netfs] netfs_readpage+0x173/0x3b0 [netfs] ? init_wait_var_entry+0x50/0x50 filemap_read_page+0x33/0xf0 filemap_get_pages+0x2f2/0x3f0 filemap_read+0xaa/0x320 ? do_filp_open+0xb2/0x150 ? rmqueue+0x3be/0xe10 ceph_read_iter+0x1fe/0x680 [ceph] ? new_sync_read+0x115/0x1a0 new_sync_read+0x115/0x1a0 vfs_read+0xf3/0x180 ksys_read+0x5f/0xe0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Changes: ======== ver #2) - Changed an unsigned int to a size_t to reduce the likelihood of an overflow as per Willy's suggestion. - Added an additional patch to fix the maths. CVE-2022-49810 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: bridge: switchdev: Fix memory leaks when changing VLAN protocol The bridge driver can offload VLANs to the underlying hardware either via switchdev or the 8021q driver. When the former is used, the VLAN is marked in the bridge driver with the 'BR_VLFLAG_ADDED_BY_SWITCHDEV' private flag. To avoid the memory leaks mentioned in the cited commit, the bridge driver will try to delete a VLAN via the 8021q driver if the VLAN is not marked with the previously mentioned flag. When the VLAN protocol of the bridge changes, switchdev drivers are notified via the 'SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL' attribute, but the 8021q driver is also called to add the existing VLANs with the new protocol and delete them with the old protocol. In case the VLANs were offloaded via switchdev, the above behavior is both redundant and buggy. Redundant because the VLANs are already programmed in hardware and drivers that support VLAN protocol change (currently only mlx5) change the protocol upon the switchdev attribute notification. Buggy because the 8021q driver is called despite these VLANs being marked with 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. This leads to memory leaks [1] when the VLANs are deleted. Fix by not calling the 8021q driver for VLANs that were already programmed via switchdev. [1] unreferenced object 0xffff8881f6771200 (size 256): comm "ip", pid 446855, jiffies 4298238841 (age 55.240s) hex dump (first 32 bytes): 00 00 7f 0e 83 88 ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000012819ac>] vlan_vid_add+0x437/0x750 [<00000000f2281fad>] __br_vlan_set_proto+0x289/0x920 [<000000000632b56f>] br_changelink+0x3d6/0x13f0 [<0000000089d25f04>] __rtnl_newlink+0x8ae/0x14c0 [<00000000f6276baf>] rtnl_newlink+0x5f/0x90 [<00000000746dc902>] rtnetlink_rcv_msg+0x336/0xa00 [<000000001c2241c0>] netlink_rcv_skb+0x11d/0x340 [<0000000010588814>] netlink_unicast+0x438/0x710 [<00000000e1a4cd5c>] netlink_sendmsg+0x788/0xc40 [<00000000e8992d4e>] sock_sendmsg+0xb0/0xe0 [<00000000621b8f91>] ____sys_sendmsg+0x4ff/0x6d0 [<000000000ea26996>] ___sys_sendmsg+0x12e/0x1b0 [<00000000684f7e25>] __sys_sendmsg+0xab/0x130 [<000000004538b104>] do_syscall_64+0x3d/0x90 [<0000000091ed9678>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 CVE-2022-49812 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 low In the Linux kernel, the following vulnerability has been resolved: net: ena: Fix error handling in ena_init() The ena_init() won't destroy workqueue created by create_singlethread_workqueue() when pci_register_driver() failed. Call destroy_workqueue() when pci_register_driver() failed to prevent the resource leak. CVE-2022-49813 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: mISDN: fix misuse of put_device() in mISDN_register_device() We should not release reference by put_device() before calling device_initialize(). CVE-2022-49818 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: mISDN: fix possible memory leak in mISDN_dsp_element_register() Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, use put_device() to give up the reference, so that the name can be freed in kobject_cleanup() when the refcount is 0. The 'entry' is going to be freed in mISDN_dsp_dev_release(), so the kfree() is removed. list_del() is called in mISDN_dsp_dev_release(), so it need be initialized. CVE-2022-49821 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: cifs: Fix connections leak when tlink setup failed If the tlink setup failed, lost to put the connections, then the module refcnt leak since the cifsd kthread not exit. Also leak the fscache info, and for next mount with fsc, it will print the follow errors: CIFS: Cache volume key already in use (cifs,127.0.0.1:445,TEST) Let's check the result of tlink setup, and do some cleanup. CVE-2022-49822 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ata: libata-transport: fix error handling in ata_tdev_add() In ata_tdev_add(), the return value of transport_add_device() is not checked. As a result, it causes null-ptr-deref while removing the module, because transport_remove_device() is called to remove the device that was not added. Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0 CPU: 13 PID: 13603 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #36 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x48/0x3a0 lr : device_del+0x44/0x3a0 Call trace: device_del+0x48/0x3a0 attribute_container_class_device_del+0x28/0x40 transport_remove_classdev+0x60/0x7c attribute_container_device_trigger+0x118/0x120 transport_remove_device+0x20/0x30 ata_tdev_delete+0x24/0x50 [libata] ata_tlink_delete+0x40/0xa0 [libata] ata_tport_delete+0x2c/0x60 [libata] ata_port_detach+0x148/0x1b0 [libata] ata_pci_remove_one+0x50/0x80 [libata] ahci_remove_one+0x4c/0x8c [ahci] Fix this by checking and handling return value of transport_add_device() in ata_tdev_add(). In the error path, device_del() is called to delete the device which was added earlier in this function, and ata_tdev_free() is called to free ata_dev. CVE-2022-49823 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ata: libata-transport: fix error handling in ata_tlink_add() In ata_tlink_add(), the return value of transport_add_device() is not checked. As a result, it causes null-ptr-deref while removing the module, because transport_remove_device() is called to remove the device that was not added. Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0 CPU: 33 PID: 13850 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #12 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x48/0x39c lr : device_del+0x44/0x39c Call trace: device_del+0x48/0x39c attribute_container_class_device_del+0x28/0x40 transport_remove_classdev+0x60/0x7c attribute_container_device_trigger+0x118/0x120 transport_remove_device+0x20/0x30 ata_tlink_delete+0x88/0xb0 [libata] ata_tport_delete+0x2c/0x60 [libata] ata_port_detach+0x148/0x1b0 [libata] ata_pci_remove_one+0x50/0x80 [libata] ahci_remove_one+0x4c/0x8c [ahci] Fix this by checking and handling return value of transport_add_device() in ata_tlink_add(). CVE-2022-49824 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ata: libata-transport: fix error handling in ata_tport_add() In ata_tport_add(), the return value of transport_add_device() is not checked. As a result, it causes null-ptr-deref while removing the module, because transport_remove_device() is called to remove the device that was not added. Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0 CPU: 12 PID: 13605 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #8 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x48/0x39c lr : device_del+0x44/0x39c Call trace: device_del+0x48/0x39c attribute_container_class_device_del+0x28/0x40 transport_remove_classdev+0x60/0x7c attribute_container_device_trigger+0x118/0x120 transport_remove_device+0x20/0x30 ata_tport_delete+0x34/0x60 [libata] ata_port_detach+0x148/0x1b0 [libata] ata_pci_remove_one+0x50/0x80 [libata] ahci_remove_one+0x4c/0x8c [ahci] Fix this by checking and handling return value of transport_add_device() in ata_tport_add(). CVE-2022-49825 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ata: libata-transport: fix double ata_host_put() in ata_tport_add() In the error path in ata_tport_add(), when calling put_device(), ata_tport_release() is called, it will put the refcount of 'ap->host'. And then ata_host_put() is called again, the refcount is decreased to 0, ata_host_release() is called, all ports are freed and set to null. When unbinding the device after failure, ata_host_stop() is called to release the resources, it leads a null-ptr-deref(), because all the ports all freed and null. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 CPU: 7 PID: 18671 Comm: modprobe Kdump: loaded Tainted: G E 6.1.0-rc3+ #8 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ata_host_stop+0x3c/0x84 [libata] lr : release_nodes+0x64/0xd0 Call trace: ata_host_stop+0x3c/0x84 [libata] release_nodes+0x64/0xd0 devres_release_all+0xbc/0x1b0 device_unbind_cleanup+0x20/0x70 really_probe+0x158/0x320 __driver_probe_device+0x84/0x120 driver_probe_device+0x44/0x120 __driver_attach+0xb4/0x220 bus_for_each_dev+0x78/0xdc driver_attach+0x2c/0x40 bus_add_driver+0x184/0x240 driver_register+0x80/0x13c __pci_register_driver+0x4c/0x60 ahci_pci_driver_init+0x30/0x1000 [ahci] Fix this by removing redundant ata_host_put() in the error path. CVE-2022-49826 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm: Fix potential null-ptr-deref in drm_vblank_destroy_worker() drm_vblank_init() call drmm_add_action_or_reset() with drm_vblank_init_release() as action. If __drmm_add_action() failed, will directly call drm_vblank_init_release() with the vblank whose worker is NULL. As the resule, a null-ptr-deref will happen in kthread_destroy_worker(). Add the NULL check before calling drm_vblank_destroy_worker(). BUG: null-ptr-deref KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f] CPU: 5 PID: 961 Comm: modprobe Not tainted 6.0.0-11331-gd465bff130bf-dirty RIP: 0010:kthread_destroy_worker+0x25/0xb0 Call Trace: <TASK> drm_vblank_init_release+0x124/0x220 [drm] ? drm_crtc_vblank_restore+0x8b0/0x8b0 [drm] __drmm_add_action_or_reset+0x41/0x50 [drm] drm_vblank_init+0x282/0x310 [drm] vkms_init+0x35f/0x1000 [vkms] ? 0xffffffffc4508000 ? lock_is_held_type+0xd7/0x130 ? __kmem_cache_alloc_node+0x1c2/0x2b0 ? lock_is_held_type+0xd7/0x130 ? 0xffffffffc4508000 do_one_initcall+0xd0/0x4f0 ... do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 CVE-2022-49827 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/drv: Fix potential memory leak in drm_dev_init() drm_dev_init() will add drm_dev_init_release() as a callback. When drmm_add_action() failed, the release function won't be added. As the result, the ref cnt added by device_get() in drm_dev_init() won't be put by drm_dev_init_release(), which leads to the memleak. Use drmm_add_action_or_reset() instead of drmm_add_action() to prevent memleak. unreferenced object 0xffff88810bc0c800 (size 2048): comm "modprobe", pid 8322, jiffies 4305809845 (age 15.292s) hex dump (first 32 bytes): e8 cc c0 0b 81 88 ff ff ff ff ff ff 00 00 00 00 ................ 20 24 3c 0c 81 88 ff ff 18 c8 c0 0b 81 88 ff ff $<............. backtrace: [<000000007251f72d>] __kmalloc+0x4b/0x1c0 [<0000000045f21f26>] platform_device_alloc+0x2d/0xe0 [<000000004452a479>] platform_device_register_full+0x24/0x1c0 [<0000000089f4ea61>] 0xffffffffa0736051 [<00000000235b2441>] do_one_initcall+0x7a/0x380 [<0000000001a4a177>] do_init_module+0x5c/0x230 [<000000002bf8a8e2>] load_module+0x227d/0x2420 [<00000000637d6d0a>] __do_sys_finit_module+0xd5/0x140 [<00000000c99fc324>] do_syscall_64+0x3f/0x90 [<000000004d85aa77>] entry_SYSCALL_64_after_hwframe+0x63/0xcd CVE-2022-49830 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 low In the Linux kernel, the following vulnerability has been resolved: pinctrl: devicetree: fix null pointer dereferencing in pinctrl_dt_to_map Here is the BUG report by KASAN about null pointer dereference: BUG: KASAN: null-ptr-deref in strcmp+0x2e/0x50 Read of size 1 at addr 0000000000000000 by task python3/2640 Call Trace: strcmp __of_find_property of_find_property pinctrl_dt_to_map kasprintf() would return NULL pointer when kmalloc() fail to allocate. So directly return ENOMEM, if kasprintf() return NULL pointer. CVE-2022-49832 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix use-after-free bug of ns_writer on remount If a nilfs2 filesystem is downgraded to read-only due to metadata corruption on disk and is remounted read/write, or if emergency read-only remount is performed, detaching a log writer and synchronizing the filesystem can be done at the same time. In these cases, use-after-free of the log writer (hereinafter nilfs->ns_writer) can happen as shown in the scenario below: Task1 Task2 -------------------------------- ------------------------------ nilfs_construct_segment nilfs_segctor_sync init_wait init_waitqueue_entry add_wait_queue schedule nilfs_remount (R/W remount case) nilfs_attach_log_writer nilfs_detach_log_writer nilfs_segctor_destroy kfree finish_wait _raw_spin_lock_irqsave __raw_spin_lock_irqsave do_raw_spin_lock debug_spin_lock_before <-- use-after-free While Task1 is sleeping, nilfs->ns_writer is freed by Task2. After Task1 waked up, Task1 accesses nilfs->ns_writer which is already freed. This scenario diagram is based on the Shigeru Yoshida's post [1]. This patch fixes the issue by not detaching nilfs->ns_writer on remount so that this UAF race doesn't happen. Along with this change, this patch also inserts a few necessary read-only checks with superblock instance where only the ns_writer pointer was used to check if the filesystem is read-only. CVE-2022-49834 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: fix potential memleak in 'add_widget_node' As 'kobject_add' may allocated memory for 'kobject->name' when return error. And in this function, if call 'kobject_add' failed didn't free kobject. So call 'kobject_put' to recycling resources. CVE-2022-49835 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: siox: fix possible memory leak in siox_device_add() If device_register() returns error in siox_device_add(), the name allocated by dev_set_name() need be freed. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So fix this by calling put_device(), then the name can be freed in kobject_cleanup(), and sdevice is freed in siox_device_release(), set it to null in error path. CVE-2022-49836 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_transport_sas: Fix error handling in sas_phy_add() If transport_add_device() fails in sas_phy_add(), the kernel will crash trying to delete the device in transport_remove_device() called from sas_remove_host(). Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108 CPU: 61 PID: 42829 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc1+ #173 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x54/0x3d0 lr : device_del+0x37c/0x3d0 Call trace: device_del+0x54/0x3d0 attribute_container_class_device_del+0x28/0x38 transport_remove_classdev+0x6c/0x80 attribute_container_device_trigger+0x108/0x110 transport_remove_device+0x28/0x38 sas_phy_delete+0x30/0x60 [scsi_transport_sas] do_sas_phy_delete+0x6c/0x80 [scsi_transport_sas] device_for_each_child+0x68/0xb0 sas_remove_children+0x40/0x50 [scsi_transport_sas] sas_remove_host+0x20/0x38 [scsi_transport_sas] hisi_sas_remove+0x40/0x68 [hisi_sas_main] hisi_sas_v2_remove+0x20/0x30 [hisi_sas_v2_hw] platform_remove+0x2c/0x60 Fix this by checking and handling return value of transport_add_device() in sas_phy_add(). CVE-2022-49839 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: serial: imx: Add missing .thaw_noirq hook The following warning is seen with non-console UART instance when system hibernates. [ 37.371969] ------------[ cut here ]------------ [ 37.376599] uart3_root_clk already disabled [ 37.380810] WARNING: CPU: 0 PID: 296 at drivers/clk/clk.c:952 clk_core_disable+0xa4/0xb0 ... [ 37.506986] Call trace: [ 37.509432] clk_core_disable+0xa4/0xb0 [ 37.513270] clk_disable+0x34/0x50 [ 37.516672] imx_uart_thaw+0x38/0x5c [ 37.520250] platform_pm_thaw+0x30/0x6c [ 37.524089] dpm_run_callback.constprop.0+0x3c/0xd4 [ 37.528972] device_resume+0x7c/0x160 [ 37.532633] dpm_resume+0xe8/0x230 [ 37.536036] hibernation_snapshot+0x288/0x430 [ 37.540397] hibernate+0x10c/0x2e0 [ 37.543798] state_store+0xc4/0xd0 [ 37.547203] kobj_attr_store+0x1c/0x30 [ 37.550953] sysfs_kf_write+0x48/0x60 [ 37.554619] kernfs_fop_write_iter+0x118/0x1ac [ 37.559063] new_sync_write+0xe8/0x184 [ 37.562812] vfs_write+0x230/0x290 [ 37.566214] ksys_write+0x68/0xf4 [ 37.569529] __arm64_sys_write+0x20/0x2c [ 37.573452] invoke_syscall.constprop.0+0x50/0xf0 [ 37.578156] do_el0_svc+0x11c/0x150 [ 37.581648] el0_svc+0x30/0x140 [ 37.584792] el0t_64_sync_handler+0xe8/0xf0 [ 37.588976] el0t_64_sync+0x1a0/0x1a4 [ 37.592639] ---[ end trace 56e22eec54676d75 ]--- On hibernating, pm core calls into related hooks in sequence like: .freeze .freeze_noirq .thaw_noirq .thaw With .thaw_noirq hook being absent, the clock will be disabled in a unbalanced call which results the warning above. imx_uart_freeze() clk_prepare_enable() imx_uart_suspend_noirq() clk_disable() imx_uart_thaw clk_disable_unprepare() Adding the missing .thaw_noirq hook as imx_uart_resume_noirq() will have the call sequence corrected as below and thus fix the warning. imx_uart_freeze() clk_prepare_enable() imx_uart_suspend_noirq() clk_disable() imx_uart_resume_noirq() clk_enable() imx_uart_thaw clk_disable_unprepare() CVE-2022-49841 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: core: Fix use-after-free in snd_soc_exit() KASAN reports a use-after-free: BUG: KASAN: use-after-free in device_del+0xb5b/0xc60 Read of size 8 at addr ffff888008655050 by task rmmod/387 CPU: 2 PID: 387 Comm: rmmod Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dump_stack_lvl+0x79/0x9a print_report+0x17f/0x47b kasan_report+0xbb/0xf0 device_del+0xb5b/0xc60 platform_device_del.part.0+0x24/0x200 platform_device_unregister+0x2e/0x40 snd_soc_exit+0xa/0x22 [snd_soc_core] __do_sys_delete_module.constprop.0+0x34f/0x5b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd ... </TASK> It's bacause in snd_soc_init(), snd_soc_util_init() is possble to fail, but its ret is ignored, which makes soc_dummy_dev unregistered twice. snd_soc_init() snd_soc_util_init() platform_device_register_simple(soc_dummy_dev) platform_driver_register() # fail platform_device_unregister(soc_dummy_dev) platform_driver_register() # success ... snd_soc_exit() snd_soc_util_exit() # soc_dummy_dev will be unregistered for second time To fix it, handle error and stop snd_soc_init() when util_init() fail. Also clean debugfs when util_init() or driver_register() fail. CVE-2022-49842 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: can: j1939: j1939_send_one(): fix missing CAN header initialization The read access to struct canxl_frame::len inside of a j1939 created skbuff revealed a missing initialization of reserved and later filled elements in struct can_frame. This patch initializes the 8 byte CAN header with zero. CVE-2022-49845 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: udf: Fix a slab-out-of-bounds write bug in udf_find_entry() Syzbot reported a slab-out-of-bounds Write bug: loop0: detected capacity change from 0 to 2048 ================================================================== BUG: KASAN: slab-out-of-bounds in udf_find_entry+0x8a5/0x14f0 fs/udf/namei.c:253 Write of size 105 at addr ffff8880123ff896 by task syz-executor323/3610 CPU: 0 PID: 3610 Comm: syz-executor323 Not tainted 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:284 print_report+0x107/0x1f0 mm/kasan/report.c:395 kasan_report+0xcd/0x100 mm/kasan/report.c:495 kasan_check_range+0x2a7/0x2e0 mm/kasan/generic.c:189 memcpy+0x3c/0x60 mm/kasan/shadow.c:66 udf_find_entry+0x8a5/0x14f0 fs/udf/namei.c:253 udf_lookup+0xef/0x340 fs/udf/namei.c:309 lookup_open fs/namei.c:3391 [inline] open_last_lookups fs/namei.c:3481 [inline] path_openat+0x10e6/0x2df0 fs/namei.c:3710 do_filp_open+0x264/0x4f0 fs/namei.c:3740 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline] __do_sys_creat fs/open.c:1402 [inline] __se_sys_creat fs/open.c:1396 [inline] __x64_sys_creat+0x11f/0x160 fs/open.c:1396 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7ffab0d164d9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe1a7e6bb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000055 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffab0d164d9 RDX: 00007ffab0d164d9 RSI: 0000000000000000 RDI: 0000000020000180 RBP: 00007ffab0cd5a10 R08: 0000000000000000 R09: 0000000000000000 R10: 00005555573552c0 R11: 0000000000000246 R12: 00007ffab0cd5aa0 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Allocated by task 3610: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x3d/0x60 mm/kasan/common.c:52 ____kasan_kmalloc mm/kasan/common.c:371 [inline] __kasan_kmalloc+0x97/0xb0 mm/kasan/common.c:380 kmalloc include/linux/slab.h:576 [inline] udf_find_entry+0x7b6/0x14f0 fs/udf/namei.c:243 udf_lookup+0xef/0x340 fs/udf/namei.c:309 lookup_open fs/namei.c:3391 [inline] open_last_lookups fs/namei.c:3481 [inline] path_openat+0x10e6/0x2df0 fs/namei.c:3710 do_filp_open+0x264/0x4f0 fs/namei.c:3740 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline] __do_sys_creat fs/open.c:1402 [inline] __se_sys_creat fs/open.c:1396 [inline] __x64_sys_creat+0x11f/0x160 fs/open.c:1396 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd The buggy address belongs to the object at ffff8880123ff800 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 150 bytes inside of 256-byte region [ffff8880123ff800, ffff8880123ff900) The buggy address belongs to the physical page: page:ffffea000048ff80 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x123fe head:ffffea000048ff80 order:1 compound_mapcount:0 compound_pincount:0 flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000010200 ffffea00004b8500 dead000000000003 ffff888012041b40 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x0(), pid 1, tgid 1 (swapper/0), ts 1841222404, free_ts 0 create_dummy_stack mm/page_owner.c: ---truncated--- CVE-2022-49846 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix deadlock in nilfs_count_free_blocks() A semaphore deadlock can occur if nilfs_get_block() detects metadata corruption while locating data blocks and a superblock writeback occurs at the same time: task 1 task 2 ------ ------ * A file operation * nilfs_truncate() nilfs_get_block() down_read(rwsem A) <-- nilfs_bmap_lookup_contig() ... generic_shutdown_super() nilfs_put_super() * Prepare to write superblock * down_write(rwsem B) <-- nilfs_cleanup_super() * Detect b-tree corruption * nilfs_set_log_cursor() nilfs_bmap_convert_error() nilfs_count_free_blocks() __nilfs_error() down_read(rwsem A) <-- nilfs_set_error() down_write(rwsem B) <-- *** DEADLOCK *** Here, nilfs_get_block() readlocks rwsem A (= NILFS_MDT(dat_inode)->mi_sem) and then calls nilfs_bmap_lookup_contig(), but if it fails due to metadata corruption, __nilfs_error() is called from nilfs_bmap_convert_error() inside the lock section. Since __nilfs_error() calls nilfs_set_error() unless the filesystem is read-only and nilfs_set_error() attempts to writelock rwsem B (= nilfs->ns_sem) to write back superblock exclusively, hierarchical lock acquisition occurs in the order rwsem A -> rwsem B. Now, if another task starts updating the superblock, it may writelock rwsem B during the lock sequence above, and can deadlock trying to readlock rwsem A in nilfs_count_free_blocks(). However, there is actually no need to take rwsem A in nilfs_count_free_blocks() because it, within the lock section, only reads a single integer data on a shared struct with nilfs_sufile_get_ncleansegs(). This has been the case after commit aa474a220180 ("nilfs2: add local variable to cache the number of clean segments"), that is, even before this bug was introduced. So, this resolves the deadlock problem by just not taking the semaphore in nilfs_count_free_blocks(). CVE-2022-49850 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: macvlan: fix memory leaks of macvlan_common_newlink kmemleak reports memory leaks in macvlan_common_newlink, as follows: ip link add link eth0 name .. type macvlan mode source macaddr add <MAC-ADDR> kmemleak reports: unreferenced object 0xffff8880109bb140 (size 64): comm "ip", pid 284, jiffies 4294986150 (age 430.108s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 b8 aa 5a 12 80 88 ff ff ..........Z..... 80 1b fa 0d 80 88 ff ff 1e ff ac af c7 c1 6b 6b ..............kk backtrace: [<ffffffff813e06a7>] kmem_cache_alloc_trace+0x1c7/0x300 [<ffffffff81b66025>] macvlan_hash_add_source+0x45/0xc0 [<ffffffff81b66a67>] macvlan_changelink_sources+0xd7/0x170 [<ffffffff81b6775c>] macvlan_common_newlink+0x38c/0x5a0 [<ffffffff81b6797e>] macvlan_newlink+0xe/0x20 [<ffffffff81d97f8f>] __rtnl_newlink+0x7af/0xa50 [<ffffffff81d98278>] rtnl_newlink+0x48/0x70 ... In the scenario where the macvlan mode is configured as 'source', macvlan_changelink_sources() will be execured to reconfigure list of remote source mac addresses, at the same time, if register_netdevice() return an error, the resource generated by macvlan_changelink_sources() is not cleaned up. Using this patch, in the case of an error, it will execute macvlan_flush_sources() to ensure that the resource is cleaned up. CVE-2022-49853 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix SQE threshold checking Current way of checking available SQE count which is based on HW updated SQB count could result in driver submitting an SQE even before CQE for the previously transmitted SQE at the same index is processed in NAPI resulting losing SKB pointers, hence a leak. Fix this by checking a consumer index which is updated once CQE is processed. CVE-2022-49858 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: k3-udma-glue: fix memory leak when register device fail If device_register() fails, it should call put_device() to give up reference, the name allocated in dev_set_name() can be freed in callback function kobject_cleanup(). CVE-2022-49860 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: dmaengine: mv_xor_v2: Fix a resource leak in mv_xor_v2_remove() A clk_prepare_enable() call in the probe is not balanced by a corresponding clk_disable_unprepare() in the remove function. Add the missing call. CVE-2022-49861 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: can: af_can: fix NULL pointer dereference in can_rx_register() It causes NULL pointer dereference when testing as following: (a) use syscall(__NR_socket, 0x10ul, 3ul, 0) to create netlink socket. (b) use syscall(__NR_sendmsg, ...) to create bond link device and vxcan link device, and bind vxcan device to bond device (can also use ifenslave command to bind vxcan device to bond device). (c) use syscall(__NR_socket, 0x1dul, 3ul, 1) to create CAN socket. (d) use syscall(__NR_bind, ...) to bind the bond device to CAN socket. The bond device invokes the can-raw protocol registration interface to receive CAN packets. However, ml_priv is not allocated to the dev, dev_rcv_lists is assigned to NULL in can_rx_register(). In this case, it will occur the NULL pointer dereference issue. The following is the stack information: BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 122a4067 P4D 122a4067 PUD 1223c067 PMD 0 Oops: 0000 [#1] PREEMPT SMP RIP: 0010:can_rx_register+0x12d/0x1e0 Call Trace: <TASK> raw_enable_filters+0x8d/0x120 raw_enable_allfilters+0x3b/0x130 raw_bind+0x118/0x4f0 __sys_bind+0x163/0x1a0 __x64_sys_bind+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> CVE-2022-49863 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix NULL pointer dereference in svm_migrate_to_ram() ./drivers/gpu/drm/amd/amdkfd/kfd_migrate.c:985:58-62: ERROR: p is NULL but dereferenced. CVE-2022-49864 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ipv6: addrlabel: fix infoleak when sending struct ifaddrlblmsg to network When copying a `struct ifaddrlblmsg` to the network, __ifal_reserved remained uninitialized, resulting in a 1-byte infoleak: BUG: KMSAN: kernel-network-infoleak in __netdev_start_xmit ./include/linux/netdevice.h:4841 __netdev_start_xmit ./include/linux/netdevice.h:4841 netdev_start_xmit ./include/linux/netdevice.h:4857 xmit_one net/core/dev.c:3590 dev_hard_start_xmit+0x1dc/0x800 net/core/dev.c:3606 __dev_queue_xmit+0x17e8/0x4350 net/core/dev.c:4256 dev_queue_xmit ./include/linux/netdevice.h:3009 __netlink_deliver_tap_skb net/netlink/af_netlink.c:307 __netlink_deliver_tap+0x728/0xad0 net/netlink/af_netlink.c:325 netlink_deliver_tap net/netlink/af_netlink.c:338 __netlink_sendskb net/netlink/af_netlink.c:1263 netlink_sendskb+0x1d9/0x200 net/netlink/af_netlink.c:1272 netlink_unicast+0x56d/0xf50 net/netlink/af_netlink.c:1360 nlmsg_unicast ./include/net/netlink.h:1061 rtnl_unicast+0x5a/0x80 net/core/rtnetlink.c:758 ip6addrlbl_get+0xfad/0x10f0 net/ipv6/addrlabel.c:628 rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082 ... Uninit was created at: slab_post_alloc_hook+0x118/0xb00 mm/slab.h:742 slab_alloc_node mm/slub.c:3398 __kmem_cache_alloc_node+0x4f2/0x930 mm/slub.c:3437 __do_kmalloc_node mm/slab_common.c:954 __kmalloc_node_track_caller+0x117/0x3d0 mm/slab_common.c:975 kmalloc_reserve net/core/skbuff.c:437 __alloc_skb+0x27a/0xab0 net/core/skbuff.c:509 alloc_skb ./include/linux/skbuff.h:1267 nlmsg_new ./include/net/netlink.h:964 ip6addrlbl_get+0x490/0x10f0 net/ipv6/addrlabel.c:608 rtnetlink_rcv_msg+0xb33/0x1570 net/core/rtnetlink.c:6082 netlink_rcv_skb+0x299/0x550 net/netlink/af_netlink.c:2540 rtnetlink_rcv+0x26/0x30 net/core/rtnetlink.c:6109 netlink_unicast_kernel net/netlink/af_netlink.c:1319 netlink_unicast+0x9ab/0xf50 net/netlink/af_netlink.c:1345 netlink_sendmsg+0xebc/0x10f0 net/netlink/af_netlink.c:1921 ... This patch ensures that the reserved field is always initialized. CVE-2022-49865 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: phy: ralink: mt7621-pci: add sentinel to quirks table With mt7621 soc_dev_attr fixed to register the soc as a device, kernel will experience an oops in soc_device_match_attr This quirk test was introduced in the staging driver in commit 9445ccb3714c ("staging: mt7621-pci-phy: add quirks for 'E2' revision using 'soc_device_attribute'"). The staging driver was removed, and later re-added in commit d87da32372a0 ("phy: ralink: Add PHY driver for MT7621 PCIe PHY") for kernel 5.11 CVE-2022-49868 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix possible crash in bnxt_hwrm_set_coal() During the error recovery sequence, the rtnl_lock is not held for the entire duration and some datastructures may be freed during the sequence. Check for the BNXT_STATE_OPEN flag instead of netif_running() to ensure that the device is fully operational before proceeding to reconfigure the coalescing settings. This will fix a possible crash like this: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 10 PID: 181276 Comm: ethtool Kdump: loaded Tainted: G IOE --------- - - 4.18.0-348.el8.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/0F9N89, BIOS 2.3.10 08/15/2019 RIP: 0010:bnxt_hwrm_set_coal+0x1fb/0x2a0 [bnxt_en] Code: c2 66 83 4e 22 08 66 89 46 1c e8 10 cb 00 00 41 83 c6 01 44 39 b3 68 01 00 00 0f 8e a3 00 00 00 48 8b 93 c8 00 00 00 49 63 c6 <48> 8b 2c c2 48 8b 85 b8 02 00 00 48 85 c0 74 2e 48 8b 74 24 08 f6 RSP: 0018:ffffb11c8dcaba50 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8d168a8b0ac0 RCX: 00000000000000c5 RDX: 0000000000000000 RSI: ffff8d162f72c000 RDI: ffff8d168a8b0b28 RBP: 0000000000000000 R08: b6e1f68a12e9a7eb R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000037 R12: ffff8d168a8b109c R13: ffff8d168a8b10aa R14: 0000000000000000 R15: ffffffffc01ac4e0 FS: 00007f3852e4c740(0000) GS:ffff8d24c0080000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000041b3ee003 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ethnl_set_coalesce+0x3ce/0x4c0 genl_family_rcv_msg_doit.isra.15+0x10f/0x150 genl_family_rcv_msg+0xb3/0x160 ? coalesce_fill_reply+0x480/0x480 genl_rcv_msg+0x47/0x90 ? genl_family_rcv_msg+0x160/0x160 netlink_rcv_skb+0x4c/0x120 genl_rcv+0x24/0x40 netlink_unicast+0x196/0x230 netlink_sendmsg+0x204/0x3d0 sock_sendmsg+0x4c/0x50 __sys_sendto+0xee/0x160 ? syscall_trace_enter+0x1d3/0x2c0 ? __audit_syscall_exit+0x249/0x2a0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x5b/0x1a0 entry_SYSCALL_64_after_hwframe+0x65/0xca RIP: 0033:0x7f38524163bb CVE-2022-49869 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: capabilities: fix undefined behavior in bit shift for CAP_TO_MASK Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in security/commoncap.c:1252:2 left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: <TASK> dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c cap_task_prctl+0x561/0x6f0 security_task_prctl+0x5a/0xb0 __x64_sys_prctl+0x61/0x8f0 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> CVE-2022-49870 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: tun: Fix memory leaks of napi_get_frags kmemleak reports after running test_progs: unreferenced object 0xffff8881b1672dc0 (size 232): comm "test_progs", pid 394388, jiffies 4354712116 (age 841.975s) hex dump (first 32 bytes): e0 84 d7 a8 81 88 ff ff 80 2c 67 b1 81 88 ff ff .........,g..... 00 40 c5 9b 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace: [<00000000c8f01748>] napi_skb_cache_get+0xd4/0x150 [<0000000041c7fc09>] __napi_build_skb+0x15/0x50 [<00000000431c7079>] __napi_alloc_skb+0x26e/0x540 [<000000003ecfa30e>] napi_get_frags+0x59/0x140 [<0000000099b2199e>] tun_get_user+0x183d/0x3bb0 [tun] [<000000008a5adef0>] tun_chr_write_iter+0xc0/0x1b1 [tun] [<0000000049993ff4>] do_iter_readv_writev+0x19f/0x320 [<000000008f338ea2>] do_iter_write+0x135/0x630 [<000000008a3377a4>] vfs_writev+0x12e/0x440 [<00000000a6b5639a>] do_writev+0x104/0x280 [<00000000ccf065d8>] do_syscall_64+0x3b/0x90 [<00000000d776e329>] entry_SYSCALL_64_after_hwframe+0x63/0xcd The issue occurs in the following scenarios: tun_get_user() napi_gro_frags() napi_frags_finish() case GRO_NORMAL: gro_normal_one() list_add_tail(&skb->list, &napi->rx_list); <-- While napi->rx_count < READ_ONCE(gro_normal_batch), <-- gro_normal_list() is not called, napi->rx_list is not empty <-- not ask to complete the gro work, will cause memory leaks in <-- following tun_napi_del() ... tun_napi_del() netif_napi_del() __netif_napi_del() <-- &napi->rx_list is not empty, which caused memory leaks To fix, add napi_complete() after napi_gro_frags(). CVE-2022-49871 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: HID: hyperv: fix possible memory leak in mousevsc_probe() If hid_add_device() returns error, it should call hid_destroy_device() to free hid_dev which is allocated in hid_allocate_device(). CVE-2022-49874 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: fix BUG_ON() when directory entry has invalid rec_len The rec_len field in the directory entry has to be a multiple of 4. A corrupted filesystem image can be used to hit a BUG() in ext4_rec_len_to_disk(), called from make_indexed_dir(). ------------[ cut here ]------------ kernel BUG at fs/ext4/ext4.h:2413! ... RIP: 0010:make_indexed_dir+0x53f/0x5f0 ... Call Trace: <TASK> ? add_dirent_to_buf+0x1b2/0x200 ext4_add_entry+0x36e/0x480 ext4_add_nondir+0x2b/0xc0 ext4_create+0x163/0x200 path_openat+0x635/0xe90 do_filp_open+0xb4/0x160 ? __create_object.isra.0+0x1de/0x3b0 ? _raw_spin_unlock+0x12/0x30 do_sys_openat2+0x91/0x150 __x64_sys_open+0x6c/0xa0 do_syscall_64+0x3c/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 The fix simply adds a call to ext4_check_dir_entry() to validate the directory entry, returning -EFSCORRUPTED if the entry is invalid. CVE-2022-49879 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: fix warning in 'ext4_da_release_space' Syzkaller report issue as follows: EXT4-fs (loop0): Free/Dirty block details EXT4-fs (loop0): free_blocks=0 EXT4-fs (loop0): dirty_blocks=0 EXT4-fs (loop0): Block reservation details EXT4-fs (loop0): i_reserved_data_blocks=0 EXT4-fs warning (device loop0): ext4_da_release_space:1527: ext4_da_release_space: ino 18, to_free 1 with only 0 reserved data blocks ------------[ cut here ]------------ WARNING: CPU: 0 PID: 92 at fs/ext4/inode.c:1528 ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1524 Modules linked in: CPU: 0 PID: 92 Comm: kworker/u4:4 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Workqueue: writeback wb_workfn (flush-7:0) RIP: 0010:ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1528 RSP: 0018:ffffc900015f6c90 EFLAGS: 00010296 RAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00 RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000 RBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5 R10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000 R13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740 FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ext4_es_remove_extent+0x1ab/0x260 fs/ext4/extents_status.c:1461 mpage_release_unused_pages+0x24d/0xef0 fs/ext4/inode.c:1589 ext4_writepages+0x12eb/0x3be0 fs/ext4/inode.c:2852 do_writepages+0x3c3/0x680 mm/page-writeback.c:2469 __writeback_single_inode+0xd1/0x670 fs/fs-writeback.c:1587 writeback_sb_inodes+0xb3b/0x18f0 fs/fs-writeback.c:1870 wb_writeback+0x41f/0x7b0 fs/fs-writeback.c:2044 wb_do_writeback fs/fs-writeback.c:2187 [inline] wb_workfn+0x3cb/0xef0 fs/fs-writeback.c:2227 process_one_work+0x877/0xdb0 kernel/workqueue.c:2289 worker_thread+0xb14/0x1330 kernel/workqueue.c:2436 kthread+0x266/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> Above issue may happens as follows: ext4_da_write_begin ext4_create_inline_data ext4_clear_inode_flag(inode, EXT4_INODE_EXTENTS); ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA); __ext4_ioctl ext4_ext_migrate -> will lead to eh->eh_entries not zero, and set extent flag ext4_da_write_begin ext4_da_convert_inline_data_to_extent ext4_da_write_inline_data_begin ext4_da_map_blocks ext4_insert_delayed_block if (!ext4_es_scan_clu(inode, &ext4_es_is_delonly, lblk)) if (!ext4_es_scan_clu(inode, &ext4_es_is_mapped, lblk)) ext4_clu_mapped(inode, EXT4_B2C(sbi, lblk)); -> will return 1 allocated = true; ext4_es_insert_delayed_block(inode, lblk, allocated); ext4_writepages mpage_map_and_submit_extent(handle, &mpd, &give_up_on_write); -> return -ENOSPC mpage_release_unused_pages(&mpd, give_up_on_write); -> give_up_on_write == 1 ext4_es_remove_extent ext4_da_release_space(inode, reserved); if (unlikely(to_free > ei->i_reserved_data_blocks)) -> to_free == 1 but ei->i_reserved_data_blocks == 0 -> then trigger warning as above To solve above issue, forbid inode do migrate which has inline data. CVE-2022-49880 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: fix memory leak in query_regdb_file() In the function query_regdb_file() the alpha2 parameter is duplicated using kmemdup() and subsequently freed in regdb_fw_cb(). However, request_firmware_nowait() can fail without calling regdb_fw_cb() and thus leak memory. CVE-2022-49881 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ACPI: APEI: Fix integer overflow in ghes_estatus_pool_init() Change num_ghes from int to unsigned int, preventing an overflow and causing subsequent vmalloc() to fail. The overflow happens in ghes_estatus_pool_init() when calculating len during execution of the statement below as both multiplication operands here are signed int: len += (num_ghes * GHES_ESOURCE_PREALLOC_MAX_SIZE); The following call trace is observed because of this bug: [ 9.317108] swapper/0: vmalloc error: size 18446744071562596352, exceeds total pages, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0-1 [ 9.317131] Call Trace: [ 9.317134] <TASK> [ 9.317137] dump_stack_lvl+0x49/0x5f [ 9.317145] dump_stack+0x10/0x12 [ 9.317146] warn_alloc.cold+0x7b/0xdf [ 9.317150] ? __device_attach+0x16a/0x1b0 [ 9.317155] __vmalloc_node_range+0x702/0x740 [ 9.317160] ? device_add+0x17f/0x920 [ 9.317164] ? dev_set_name+0x53/0x70 [ 9.317166] ? platform_device_add+0xf9/0x240 [ 9.317168] __vmalloc_node+0x49/0x50 [ 9.317170] ? ghes_estatus_pool_init+0x43/0xa0 [ 9.317176] vmalloc+0x21/0x30 [ 9.317177] ghes_estatus_pool_init+0x43/0xa0 [ 9.317179] acpi_hest_init+0x129/0x19c [ 9.317185] acpi_init+0x434/0x4a4 [ 9.317188] ? acpi_sleep_proc_init+0x2a/0x2a [ 9.317190] do_one_initcall+0x48/0x200 [ 9.317195] kernel_init_freeable+0x221/0x284 [ 9.317200] ? rest_init+0xe0/0xe0 [ 9.317204] kernel_init+0x1a/0x130 [ 9.317205] ret_from_fork+0x22/0x30 [ 9.317208] </TASK> [ rjw: Subject and changelog edits ] CVE-2022-49885 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: fix possible refcount leak in vdec_probe() v4l2_device_unregister need to be called to put the refcount got by v4l2_device_register when vdec_probe fails or vdec_remove is called. CVE-2022-49887 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: arm64: entry: avoid kprobe recursion The cortex_a76_erratum_1463225_debug_handler() function is called when handling debug exceptions (and synchronous exceptions from BRK instructions), and so is called when a probed function executes. If the compiler does not inline cortex_a76_erratum_1463225_debug_handler(), it can be probed. If cortex_a76_erratum_1463225_debug_handler() is probed, any debug exception or software breakpoint exception will result in recursive exceptions leading to a stack overflow. This can be triggered with the ftrace multiple_probes selftest, and as per the example splat below. This is a regression caused by commit: 6459b8469753e9fe ("arm64: entry: consolidate Cortex-A76 erratum 1463225 workaround") ... which removed the NOKPROBE_SYMBOL() annotation associated with the function. My intent was that cortex_a76_erratum_1463225_debug_handler() would be inlined into its caller, el1_dbg(), which is marked noinstr and cannot be probed. Mark cortex_a76_erratum_1463225_debug_handler() as __always_inline to ensure this. Example splat prior to this patch (with recursive entries elided): | # echo p cortex_a76_erratum_1463225_debug_handler > /sys/kernel/debug/tracing/kprobe_events | # echo p do_el0_svc >> /sys/kernel/debug/tracing/kprobe_events | # echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable | Insufficient stack space to handle exception! | ESR: 0x0000000096000047 -- DABT (current EL) | FAR: 0xffff800009cefff0 | Task stack: [0xffff800009cf0000..0xffff800009cf4000] | IRQ stack: [0xffff800008000000..0xffff800008004000] | Overflow stack: [0xffff00007fbc00f0..0xffff00007fbc10f0] | CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2 | Hardware name: linux,dummy-virt (DT) | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : arm64_enter_el1_dbg+0x4/0x20 | lr : el1_dbg+0x24/0x5c | sp : ffff800009cf0000 | x29: ffff800009cf0000 x28: ffff000002c74740 x27: 0000000000000000 | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 | x23: 00000000604003c5 x22: ffff80000801745c x21: 0000aaaac95ac068 | x20: 00000000f2000004 x19: ffff800009cf0040 x18: 0000000000000000 | x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 | x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 | x11: 0000000000000010 x10: ffff800008c87190 x9 : ffff800008ca00d0 | x8 : 000000000000003c x7 : 0000000000000000 x6 : 0000000000000000 | x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000043a4 | x2 : 00000000f2000004 x1 : 00000000f2000004 x0 : ffff800009cf0040 | Kernel panic - not syncing: kernel stack overflow | CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2 | Hardware name: linux,dummy-virt (DT) | Call trace: | dump_backtrace+0xe4/0x104 | show_stack+0x18/0x4c | dump_stack_lvl+0x64/0x7c | dump_stack+0x18/0x38 | panic+0x14c/0x338 | test_taint+0x0/0x2c | panic_bad_stack+0x104/0x118 | handle_bad_stack+0x34/0x48 | __bad_stack+0x78/0x7c | arm64_enter_el1_dbg+0x4/0x20 | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | cortex_a76_erratum_1463225_debug_handler+0x0/0x34 ... | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | cortex_a76_erratum_1463225_debug_handler+0x0/0x34 ... | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | cortex_a76_erratum_1463225_debug_handler+0x0/0x34 | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | do_el0_svc+0x0/0x28 | el0t_64_sync_handler+0x84/0xf0 | el0t_64_sync+0x18c/0x190 | Kernel Offset: disabled | CPU features: 0x0080,00005021,19001080 | Memory Limit: none | ---[ end Kernel panic - not syncing: kernel stack overflow ]--- With this patch, cortex_a76_erratum_1463225_debug_handler() is inlined into el1_dbg(), and el1_dbg() cannot be probed: | # echo p cortex_a76_erratum_1463225_debug_handler > /sys/kernel/debug/tracing/kprobe_events | sh: write error: No such file or directory | # grep -w cortex_a76_errat ---truncated--- CVE-2022-49888 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Check for NULL cpu_buffer in ring_buffer_wake_waiters() On some machines the number of listed CPUs may be bigger than the actual CPUs that exist. The tracing subsystem allocates a per_cpu directory with access to the per CPU ring buffer via a cpuX file. But to save space, the ring buffer will only allocate buffers for online CPUs, even though the CPU array will be as big as the nr_cpu_ids. With the addition of waking waiters on the ring buffer when closing the file, the ring_buffer_wake_waiters() now needs to make sure that the buffer is allocated (with the irq_work allocated with it) before trying to wake waiters, as it will cause a NULL pointer dereference. While debugging this, I added a NULL check for the buffer itself (which is OK to do), and also NULL pointer checks against buffer->buffers (which is not fine, and will WARN) as well as making sure the CPU number passed in is within the nr_cpu_ids (which is also not fine if it isn't). Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1204705 CVE-2022-49889 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: capabilities: fix potential memleak on error path from vfs_getxattr_alloc() In cap_inode_getsecurity(), we will use vfs_getxattr_alloc() to complete the memory allocation of tmpbuf, if we have completed the memory allocation of tmpbuf, but failed to call handler->get(...), there will be a memleak in below logic: |-- ret = (int)vfs_getxattr_alloc(mnt_userns, ...) | /* ^^^ alloc for tmpbuf */ |-- value = krealloc(*xattr_value, error + 1, flags) | /* ^^^ alloc memory */ |-- error = handler->get(handler, ...) | /* error! */ |-- *xattr_value = value | /* xattr_value is &tmpbuf (memory leak!) */ So we will try to free(tmpbuf) after vfs_getxattr_alloc() fails to fix it. [PM: subject line and backtrace tweaks] CVE-2022-49890 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: tracing: kprobe: Fix memory leak in test_gen_kprobe/kretprobe_cmd() test_gen_kprobe_cmd() only free buf in fail path, hence buf will leak when there is no failure. Move kfree(buf) from fail path to common path to prevent the memleak. The same reason and solution in test_gen_kretprobe_cmd(). unreferenced object 0xffff888143b14000 (size 2048): comm "insmod", pid 52490, jiffies 4301890980 (age 40.553s) hex dump (first 32 bytes): 70 3a 6b 70 72 6f 62 65 73 2f 67 65 6e 5f 6b 70 p:kprobes/gen_kp 72 6f 62 65 5f 74 65 73 74 20 64 6f 5f 73 79 73 robe_test do_sys backtrace: [<000000006d7b836b>] kmalloc_trace+0x27/0xa0 [<0000000009528b5b>] 0xffffffffa059006f [<000000008408b580>] do_one_initcall+0x87/0x2a0 [<00000000c4980a7e>] do_init_module+0xdf/0x320 [<00000000d775aad0>] load_module+0x3006/0x3390 [<00000000e9a74b80>] __do_sys_finit_module+0x113/0x1b0 [<000000003726480d>] do_syscall_64+0x35/0x80 [<000000003441e93b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 CVE-2022-49891 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix use-after-free for dynamic ftrace_ops KASAN reported a use-after-free with ftrace ops [1]. It was found from vmcore that perf had registered two ops with the same content successively, both dynamic. After unregistering the second ops, a use-after-free occurred. In ftrace_shutdown(), when the second ops is unregistered, the FTRACE_UPDATE_CALLS command is not set because there is another enabled ops with the same content. Also, both ops are dynamic and the ftrace callback function is ftrace_ops_list_func, so the FTRACE_UPDATE_TRACE_FUNC command will not be set. Eventually the value of 'command' will be 0 and ftrace_shutdown() will skip the rcu synchronization. However, ftrace may be activated. When the ops is released, another CPU may be accessing the ops. Add the missing synchronization to fix this problem. [1] BUG: KASAN: use-after-free in __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline] BUG: KASAN: use-after-free in ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049 Read of size 8 at addr ffff56551965bbc8 by task syz-executor.2/14468 CPU: 1 PID: 14468 Comm: syz-executor.2 Not tainted 5.10.0 #7 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x40c arch/arm64/kernel/stacktrace.c:132 show_stack+0x30/0x40 arch/arm64/kernel/stacktrace.c:196 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1b4/0x248 lib/dump_stack.c:118 print_address_description.constprop.0+0x28/0x48c mm/kasan/report.c:387 __kasan_report mm/kasan/report.c:547 [inline] kasan_report+0x118/0x210 mm/kasan/report.c:564 check_memory_region_inline mm/kasan/generic.c:187 [inline] __asan_load8+0x98/0xc0 mm/kasan/generic.c:253 __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline] ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049 ftrace_graph_call+0x0/0x4 __might_sleep+0x8/0x100 include/linux/perf_event.h:1170 __might_fault mm/memory.c:5183 [inline] __might_fault+0x58/0x70 mm/memory.c:5171 do_strncpy_from_user lib/strncpy_from_user.c:41 [inline] strncpy_from_user+0x1f4/0x4b0 lib/strncpy_from_user.c:139 getname_flags+0xb0/0x31c fs/namei.c:149 getname+0x2c/0x40 fs/namei.c:209 [...] Allocated by task 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc mm/kasan/common.c:479 [inline] __kasan_kmalloc.constprop.0+0x110/0x13c mm/kasan/common.c:449 kasan_kmalloc+0xc/0x14 mm/kasan/common.c:493 kmem_cache_alloc_trace+0x440/0x924 mm/slub.c:2950 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:675 [inline] perf_event_alloc.part.0+0xb4/0x1350 kernel/events/core.c:11230 perf_event_alloc kernel/events/core.c:11733 [inline] __do_sys_perf_event_open kernel/events/core.c:11831 [inline] __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 __arm64_sys_perf_event_open+0x6c/0x80 kernel/events/core.c:11723 [...] Freed by task 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track+0x24/0x34 mm/kasan/common.c:56 kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:358 __kasan_slab_free.part.0+0x11c/0x1b0 mm/kasan/common.c:437 __kasan_slab_free mm/kasan/common.c:445 [inline] kasan_slab_free+0x2c/0x40 mm/kasan/common.c:446 slab_free_hook mm/slub.c:1569 [inline] slab_free_freelist_hook mm/slub.c:1608 [inline] slab_free mm/slub.c:3179 [inline] kfree+0x12c/0xc10 mm/slub.c:4176 perf_event_alloc.part.0+0xa0c/0x1350 kernel/events/core.c:11434 perf_event_alloc kernel/events/core.c:11733 [inline] __do_sys_perf_event_open kernel/events/core.c:11831 [inline] __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 [...] CVE-2022-49892 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: i2c: piix4: Fix adapter not be removed in piix4_remove() In piix4_probe(), the piix4 adapter will be registered in: piix4_probe() piix4_add_adapters_sb800() / piix4_add_adapter() i2c_add_adapter() Based on the probed device type, piix4_add_adapters_sb800() or single piix4_add_adapter() will be called. For the former case, piix4_adapter_count is set as the number of adapters, while for antoher case it is not set and kept default *zero*. When piix4 is removed, piix4_remove() removes the adapters added in piix4_probe(), basing on the piix4_adapter_count value. Because the count is zero for the single adapter case, the adapter won't be removed and makes the sources allocated for adapter leaked, such as the i2c client and device. These sources can still be accessed by i2c or bus and cause problems. An easily reproduced case is that if a new adapter is registered, i2c will get the leaked adapter and try to call smbus_algorithm, which was already freed: Triggered by: rmmod i2c_piix4 && modprobe max31730 BUG: unable to handle page fault for address: ffffffffc053d860 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 3752 Comm: modprobe Tainted: G Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:i2c_default_probe (drivers/i2c/i2c-core-base.c:2259) i2c_core RSP: 0018:ffff888107477710 EFLAGS: 00000246 ... <TASK> i2c_detect (drivers/i2c/i2c-core-base.c:2302) i2c_core __process_new_driver (drivers/i2c/i2c-core-base.c:1336) i2c_core bus_for_each_dev (drivers/base/bus.c:301) i2c_for_each_dev (drivers/i2c/i2c-core-base.c:1823) i2c_core i2c_register_driver (drivers/i2c/i2c-core-base.c:1861) i2c_core do_one_initcall (init/main.c:1296) do_init_module (kernel/module/main.c:2455) ... </TASK> ---[ end trace 0000000000000000 ]--- Fix this problem by correctly set piix4_adapter_count as 1 for the single adapter so it can be normally removed. CVE-2022-49900 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/smc: Fix possible leaked pernet namespace in smc_init() In smc_init(), register_pernet_subsys(&smc_net_stat_ops) is called without any error handling. If it fails, registering of &smc_net_ops won't be reverted. And if smc_nl_init() fails, &smc_net_stat_ops itself won't be reverted. This leaves wild ops in subsystem linkedlist and when another module tries to call register_pernet_operations() it triggers page fault: BUG: unable to handle page fault for address: fffffbfff81b964c RIP: 0010:register_pernet_operations+0x1b9/0x5f0 Call Trace: <TASK> register_pernet_subsys+0x29/0x40 ebtables_init+0x58/0x1000 [ebtables] ... CVE-2022-49905 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Free rwi on reset success Free the rwi structure in the event that the last rwi in the list processed successfully. The logic in commit 4f408e1fa6e1 ("ibmvnic: retry reset if there are no other resets") introduces an issue that results in a 32 byte memory leak whenever the last rwi in the list gets processed. CVE-2022-49906 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: mISDN: fix possible memory leak in mISDN_register_device() Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, add put_device() to give up the reference, so that the name can be freed in kobject_cleanup() when the refcount is 0. Set device class before put_device() to avoid null release() function WARN message in device_release(). CVE-2022-49915 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: rose: Fix NULL pointer dereference in rose_send_frame() The syzkaller reported an issue: KASAN: null-ptr-deref in range [0x0000000000000380-0x0000000000000387] CPU: 0 PID: 4069 Comm: kworker/0:15 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Workqueue: rcu_gp srcu_invoke_callbacks RIP: 0010:rose_send_frame+0x1dd/0x2f0 net/rose/rose_link.c:101 Call Trace: <IRQ> rose_transmit_clear_request+0x1d5/0x290 net/rose/rose_link.c:255 rose_rx_call_request+0x4c0/0x1bc0 net/rose/af_rose.c:1009 rose_loopback_timer+0x19e/0x590 net/rose/rose_loopback.c:111 call_timer_fn+0x1a0/0x6b0 kernel/time/timer.c:1474 expire_timers kernel/time/timer.c:1519 [inline] __run_timers.part.0+0x674/0xa80 kernel/time/timer.c:1790 __run_timers kernel/time/timer.c:1768 [inline] run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1803 __do_softirq+0x1d0/0x9c8 kernel/softirq.c:571 [...] </IRQ> It triggers NULL pointer dereference when 'neigh->dev->dev_addr' is called in the rose_send_frame(). It's the first occurrence of the `neigh` is in rose_loopback_timer() as `rose_loopback_neigh', and the 'dev' in 'rose_loopback_neigh' is initialized sa nullptr. It had been fixed by commit 3b3fd068c56e3fbea30090859216a368398e39bf ("rose: Fix Null pointer dereference in rose_send_frame()") ever. But it's introduced by commit 3c53cd65dece47dd1f9d3a809f32e59d1d87b2b8 ("rose: check NULL rose_loopback_neigh->loopback") again. We fix it by add NULL check in rose_transmit_clear_request(). When the 'dev' in 'neigh' is NULL, we don't reply the request and just clear it. syzkaller don't provide repro, and I provide a syz repro like: r0 = syz_init_net_socket$bt_sco(0x1f, 0x5, 0x2) ioctl$sock_inet_SIOCSIFFLAGS(r0, 0x8914, &(0x7f0000000180)={'rose0\x00', 0x201}) r1 = syz_init_net_socket$rose(0xb, 0x5, 0x0) bind$rose(r1, &(0x7f00000000c0)=@full={0xb, @dev, @null, 0x0, [@null, @null, @netrom, @netrom, @default, @null]}, 0x40) connect$rose(r1, &(0x7f0000000240)=@short={0xb, @dev={0xbb, 0xbb, 0xbb, 0x1, 0x0}, @remote={0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0x1}, 0x1, @netrom={0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x0, 0x0}}, 0x1c) CVE-2022-49916 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send() nfcmrvl_i2c_nci_send() will be called by nfcmrvl_nci_send(), and skb should be freed in nfcmrvl_i2c_nci_send(). However, nfcmrvl_nci_send() will only free skb when i2c_master_send() return >=0, which means skb will memleak when i2c_master_send() failed. Free skb no matter whether i2c_master_send() succeeds. CVE-2022-49922 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfc: nxp-nci: Fix potential memory leak in nxp_nci_send() nxp_nci_send() will call nxp_nci_i2c_write(), and only free skb when nxp_nci_i2c_write() failed. However, even if the nxp_nci_i2c_write() run succeeds, the skb will not be freed in nxp_nci_i2c_write(). As the result, the skb will memleak. nxp_nci_send() should also free the skb when nxp_nci_i2c_write() succeeds. CVE-2022-49923 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfc: fdp: Fix potential memory leak in fdp_nci_send() fdp_nci_send() will call fdp_nci_i2c_write that will not free skb in the function. As a result, when fdp_nci_i2c_write() finished, the skb will memleak. fdp_nci_send() should free skb after fdp_nci_i2c_write() finished. CVE-2022-49924 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix null-ptr-deref in ib_core_cleanup() KASAN reported a null-ptr-deref error: KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] CPU: 1 PID: 379 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:destroy_workqueue+0x2f/0x740 RSP: 0018:ffff888016137df8 EFLAGS: 00000202 ... Call Trace: ib_core_cleanup+0xa/0xa1 [ib_core] __do_sys_delete_module.constprop.0+0x34f/0x5b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fa1a0d221b7 ... It is because the fail of roce_gid_mgmt_init() is ignored: ib_core_init() roce_gid_mgmt_init() gid_cache_wq = alloc_ordered_workqueue # fail ... ib_core_cleanup() roce_gid_mgmt_cleanup() destroy_workqueue(gid_cache_wq) # destroy an unallocated wq Fix this by catching the fail of roce_gid_mgmt_init() in ib_core_init(). CVE-2022-49925 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfs4: Fix kmemleak when allocate slot failed If one of the slot allocate failed, should cleanup all the other allocated slots, otherwise, the allocated slots will leak: unreferenced object 0xffff8881115aa100 (size 64): comm ""mount.nfs"", pid 679, jiffies 4294744957 (age 115.037s) hex dump (first 32 bytes): 00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff ...s......Z..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000007a4c434a>] nfs4_find_or_create_slot+0x8e/0x130 [<000000005472a39c>] nfs4_realloc_slot_table+0x23f/0x270 [<00000000cd8ca0eb>] nfs40_init_client+0x4a/0x90 [<00000000128486db>] nfs4_init_client+0xce/0x270 [<000000008d2cacad>] nfs4_set_client+0x1a2/0x2b0 [<000000000e593b52>] nfs4_create_server+0x300/0x5f0 [<00000000e4425dd2>] nfs4_try_get_tree+0x65/0x110 [<00000000d3a6176f>] vfs_get_tree+0x41/0xf0 [<0000000016b5ad4c>] path_mount+0x9b3/0xdd0 [<00000000494cae71>] __x64_sys_mount+0x190/0x1d0 [<000000005d56bdec>] do_syscall_64+0x35/0x80 [<00000000687c9ae4>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 CVE-2022-49927 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix null-ptr-deref when xps sysfs alloc failed There is a null-ptr-deref when xps sysfs alloc failed: BUG: KASAN: null-ptr-deref in sysfs_do_create_link_sd+0x40/0xd0 Read of size 8 at addr 0000000000000030 by task gssproxy/457 CPU: 5 PID: 457 Comm: gssproxy Not tainted 6.0.0-09040-g02357b27ee03 #9 Call Trace: <TASK> dump_stack_lvl+0x34/0x44 kasan_report+0xa3/0x120 sysfs_do_create_link_sd+0x40/0xd0 rpc_sysfs_client_setup+0x161/0x1b0 rpc_new_client+0x3fc/0x6e0 rpc_create_xprt+0x71/0x220 rpc_create+0x1d4/0x350 gssp_rpc_create+0xc3/0x160 set_gssp_clnt+0xbc/0x140 write_gssp+0x116/0x1a0 proc_reg_write+0xd6/0x130 vfs_write+0x177/0x690 ksys_write+0xb9/0x150 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 When the xprt_switch sysfs alloc failed, should not add xprt and switch sysfs to it, otherwise, maybe null-ptr-deref; also initialize the 'xps_sysfs' to NULL to avoid oops when destroy it. CVE-2022-49928 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Correctly move list in sc_disable() Commit 13bac861952a ("IB/hfi1: Fix abba locking issue with sc_disable()") incorrectly tries to move a list from one list head to another. The result is a kernel crash. The crash is triggered when a link goes down and there are waiters for a send to complete. The following signature is seen: BUG: kernel NULL pointer dereference, address: 0000000000000030 [...] Call Trace: sc_disable+0x1ba/0x240 [hfi1] pio_freeze+0x3d/0x60 [hfi1] handle_freeze+0x27/0x1b0 [hfi1] process_one_work+0x1b0/0x380 ? process_one_work+0x380/0x380 worker_thread+0x30/0x360 ? process_one_work+0x380/0x380 kthread+0xd7/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 The fix is to use the correct call to move the list. CVE-2022-49931 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate A buffer overflow vulnerability was found in the Netfilter subsystem in the Linux Kernel. This issue could allow the leakage of both stack and heap addresses, and potentially allow Local Privilege Escalation to the root user via arbitrary code execution. CVE-2023-0179 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important A use-after-free flaw was found in smb2_is_status_io_timeout() in CIFS in the Linux Kernel. After CIFS transfers response data to a system call, there are still local variable points to the memory region, and if the system call frees it faster than CIFS uses it, CIFS will access a free memory region, leading to a denial of service. CVE-2023-1192 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate A use-after-free flaw was found in nfsd4_ssc_setup_dul in fs/nfsd/nfs4proc.c in the NFS filesystem in the Linux Kernel. This issue could allow a local attacker to crash the system or it may lead to a kernel information leak problem. CVE-2023-1652 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important A use-after-free flaw was found in ndlc_remove in drivers/nfc/st-nci/ndlc.c in the Linux Kernel. This flaw could allow an attacker to crash the system due to a race problem. CVE-2023-1990 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important A use-after-free vulnerability was found in iscsi_sw_tcp_session_create in drivers/scsi/iscsi_tcp.c in SCSI sub-component in the Linux Kernel. In this flaw an attacker could leak kernel internal information. CVE-2023-2162 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important A null pointer dereference issue was found in can protocol in net/can/af_can.c in the Linux before Linux. ml_priv may not be initialized in the receive path of CAN frames. A local user could use this flaw to crash the system or potentially cause a denial of service. CVE-2023-2166 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate A NULL pointer dereference flaw was found in the UNIX protocol in net/unix/diag.c In unix_diag_get_exact in the Linux Kernel. The newly allocated skb does not have sk, leading to a NULL pointer. This flaw allows a local user to crash or potentially cause a denial of service. CVE-2023-28327 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate Improper restriction of operations within the bounds of a memory buffer in some Intel(R) i915 Graphics drivers for linux before kernel version 6.2.10 may allow an authenticated user to potentially enable escalation of privilege via local access. CVE-2023-28410 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important A use-after-free flaw was found in vcs_read in drivers/tty/vt/vc_screen.c in vc_screen in the Linux Kernel. This issue may allow an attacker with local user access to cause a system crash or leak internal kernel information. CVE-2023-3567 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important Under some circumstances, this weakness allows a user who has access to run the “ps” utility on a machine, the ability to write almost unlimited amounts of unfiltered data into the process heap. CVE-2023-4016 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libprocps8-3.3.17-150000.7.42.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:procps-3.3.17-150000.7.42.1 low 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:docker-28.2.2_ce-150000.227.1 important OpenTelemetry-Go Contrib is a collection of third-party packages for OpenTelemetry-Go. Starting in version 0.37.0 and 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:docker-28.2.2_ce-150000.227.1 important A flaw was found in the python-cryptography package. This issue may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data. CVE-2023-50782 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libopenssl1_1-1.1.1l-150400.7.78.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:openssl-1_1-1.1.1l-150400.7.78.1 moderate libexpat through 2.5.0 allows a denial of service (resource consumption) because many full reparsings are required in the case of a large token for which multiple buffer fills are needed. CVE-2023-52425 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libexpat1-2.7.1-150400.3.28.1 moderate In the Linux kernel, the following vulnerability has been resolved: mm/sparsemem: fix race in accessing memory_section->usage The below race is observed on a PFN which falls into the device memory region with the system memory configuration where PFN's are such that [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL]. Since normal zone start and end pfn contains the device memory PFN's as well, the compaction triggered will try on the device memory PFN's too though they end up in NOP(because pfn_to_online_page() returns NULL for ZONE_DEVICE memory sections). When from other core, the section mappings are being removed for the ZONE_DEVICE region, that the PFN in question belongs to, on which compaction is currently being operated is resulting into the kernel crash with CONFIG_SPASEMEM_VMEMAP enabled. The crash logs can be seen at [1]. compact_zone() memunmap_pages ------------- --------------- __pageblock_pfn_to_page ...... (a)pfn_valid(): valid_section()//return true (b)__remove_pages()-> sparse_remove_section()-> section_deactivate(): [Free the array ms->usage and set ms->usage = NULL] pfn_section_valid() [Access ms->usage which is NULL] NOTE: From the above it can be said that the race is reduced to between the pfn_valid()/pfn_section_valid() and the section deactivate with SPASEMEM_VMEMAP enabled. The commit b943f045a9af("mm/sparse: fix kernel crash with pfn_section_valid check") tried to address the same problem by clearing the SECTION_HAS_MEM_MAP with the expectation of valid_section() returns false thus ms->usage is not accessed. Fix this issue by the below steps: a) Clear SECTION_HAS_MEM_MAP before freeing the ->usage. b) RCU protected read side critical section will either return NULL when SECTION_HAS_MEM_MAP is cleared or can successfully access ->usage. c) Free the ->usage with kfree_rcu() and set ms->usage = NULL. No attempt will be made to access ->usage after this as the SECTION_HAS_MEM_MAP is cleared thus valid_section() return false. Thanks to David/Pavan for their inputs on this patch. [1] https://lore.kernel.org/linux-mm/994410bb-89aa-d987-1f50-f514903c55aa@quicinc.com/ On Snapdragon SoC, with the mentioned memory configuration of PFN's as [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL], we are able to see bunch of issues daily while testing on a device farm. For this particular issue below is the log. Though the below log is not directly pointing to the pfn_section_valid(){ ms->usage;}, when we loaded this dump on T32 lauterbach tool, it is pointing. [ 540.578056] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 540.578068] Mem abort info: [ 540.578070] ESR = 0x0000000096000005 [ 540.578073] EC = 0x25: DABT (current EL), IL = 32 bits [ 540.578077] SET = 0, FnV = 0 [ 540.578080] EA = 0, S1PTW = 0 [ 540.578082] FSC = 0x05: level 1 translation fault [ 540.578085] Data abort info: [ 540.578086] ISV = 0, ISS = 0x00000005 [ 540.578088] CM = 0, WnR = 0 [ 540.579431] pstate: 82400005 (Nzcv daif +PAN -UAO +TCO -DIT -SSBSBTYPE=--) [ 540.579436] pc : __pageblock_pfn_to_page+0x6c/0x14c [ 540.579454] lr : compact_zone+0x994/0x1058 [ 540.579460] sp : ffffffc03579b510 [ 540.579463] x29: ffffffc03579b510 x28: 0000000000235800 x27:000000000000000c [ 540.579470] x26: 0000000000235c00 x25: 0000000000000068 x24:ffffffc03579b640 [ 540.579477] x23: 0000000000000001 x22: ffffffc03579b660 x21:0000000000000000 [ 540.579483] x20: 0000000000235bff x19: ffffffdebf7e3940 x18:ffffffdebf66d140 [ 540.579489] x17: 00000000739ba063 x16: 00000000739ba063 x15:00000000009f4bff [ 540.579495] x14: 0000008000000000 x13: 0000000000000000 x12:0000000000000001 [ 540.579501] x11: 0000000000000000 x10: 0000000000000000 x9 :ffffff897d2cd440 [ 540.579507] x8 : 0000000000000000 x7 : 0000000000000000 x6 :ffffffc03579b5b4 [ 540.579512] x5 : 0000000000027f25 x4 : ffffffc03579b5b8 x3 :0000000000000 ---truncated--- CVE-2023-52489 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: i3c: mipi-i3c-hci: Fix out of bounds access in hci_dma_irq_handler Do not loop over ring headers in hci_dma_irq_handler() that are not allocated and enabled in hci_dma_init(). Otherwise out of bounds access will occur from rings->headers[i] access when i >= number of allocated ring headers. CVE-2023-52766 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix htt pktlog locking The ath11k active pdevs are protected by RCU but the htt pktlog handling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a read-side critical section. Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues. Compile tested only. CVE-2023-52800 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: tcp: do not accept ACK of bytes we never sent This patch is based on a detailed report and ideas from Yepeng Pan and Christian Rossow. ACK seq validation is currently following RFC 5961 5.2 guidelines: The ACK value is considered acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back. It needs to be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return". The "ignored" above implies that the processing of the incoming data segment continues, which means the ACK value is treated as acceptable. This mitigation makes the ACK check more stringent since any ACK < SND.UNA wouldn't be accepted, instead only ACKs that are in the range ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through. This can be refined for new (and possibly spoofed) flows, by not accepting ACK for bytes that were never sent. This greatly improves TCP security at a little cost. I added a Fixes: tag to make sure this patch will reach stable trees, even if the 'blamed' patch was adhering to the RFC. tp->bytes_acked was added in linux-4.2 Following packetdrill test (courtesy of Yepeng Pan) shows the issue at hand: 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1024) = 0 // ---------------- Handshake ------------------- // // when window scale is set to 14 the window size can be extended to // 65535 * (2^14) = 1073725440. Linux would accept an ACK packet // with ack number in (Server_ISN+1-1073725440. Server_ISN+1) // ,though this ack number acknowledges some data never // sent by the server. +0 < S 0:0(0) win 65535 <mss 1400,nop,wscale 14> +0 > S. 0:0(0) ack 1 <...> +0 < . 1:1(0) ack 1 win 65535 +0 accept(3, ..., ...) = 4 // For the established connection, we send an ACK packet, // the ack packet uses ack number 1 - 1073725300 + 2^32, // where 2^32 is used to wrap around. // Note: we used 1073725300 instead of 1073725440 to avoid possible // edge cases. // 1 - 1073725300 + 2^32 = 3221241997 // Oops, old kernels happily accept this packet. +0 < . 1:1001(1000) ack 3221241997 win 65535 // After the kernel fix the following will be replaced by a challenge ACK, // and prior malicious frame would be dropped. +0 > . 1:1(0) ack 1001 CVE-2023-52881 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: gsmi: fix null-deref in gsmi_get_variable We can get EFI variables without fetching the attribute, so we must allow for that in gsmi. commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore access layer") added a new get_variable call with attr=NULL, which triggers panic in gsmi. CVE-2023-52893 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate() In Google internal bug 265639009 we've received an (as yet) unreproducible crash report from an aarch64 GKI 5.10.149-android13 running device. AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify() with the crash at: ncm_do_notify+0x98/0x270 Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b) Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c] which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget)); My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c) heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget)); which calls: ncm_bitrate(NULL) which then calls: gadget_is_superspeed(NULL) which reads ((struct usb_gadget *)NULL)->max_speed and hits a panic. AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C. (remember there's a GKI KABI reservation of 16 bytes in struct work_struct) It's not at all clear to me how this is all supposed to work... but returning 0 seems much better than panic-ing... CVE-2023-52894 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race between quota rescan and disable leading to NULL pointer deref If we have one task trying to start the quota rescan worker while another one is trying to disable quotas, we can end up hitting a race that results in the quota rescan worker doing a NULL pointer dereference. The steps for this are the following: 1) Quotas are enabled; 2) Task A calls the quota rescan ioctl and enters btrfs_qgroup_rescan(). It calls qgroup_rescan_init() which returns 0 (success) and then joins a transaction and commits it; 3) Task B calls the quota disable ioctl and enters btrfs_quota_disable(). It clears the bit BTRFS_FS_QUOTA_ENABLED from fs_info->flags and calls btrfs_qgroup_wait_for_completion(), which returns immediately since the rescan worker is not yet running. Then it starts a transaction and locks fs_info->qgroup_ioctl_lock; 4) Task A queues the rescan worker, by calling btrfs_queue_work(); 5) The rescan worker starts, and calls rescan_should_stop() at the start of its while loop, which results in 0 iterations of the loop, since the flag BTRFS_FS_QUOTA_ENABLED was cleared from fs_info->flags by task B at step 3); 6) Task B sets fs_info->quota_root to NULL; 7) The rescan worker tries to start a transaction and uses fs_info->quota_root as the root argument for btrfs_start_transaction(). This results in a NULL pointer dereference down the call chain of btrfs_start_transaction(). The stack trace is something like the one reported in Link tag below: general protection fault, probably for non-canonical address 0xdffffc0000000041: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f] CPU: 1 PID: 34 Comm: kworker/u4:2 Not tainted 6.1.0-syzkaller-13872-gb6bb9676f216 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Workqueue: btrfs-qgroup-rescan btrfs_work_helper RIP: 0010:start_transaction+0x48/0x10f0 fs/btrfs/transaction.c:564 Code: 48 89 fb 48 (...) RSP: 0018:ffffc90000ab7ab0 EFLAGS: 00010206 RAX: 0000000000000041 RBX: 0000000000000208 RCX: ffff88801779ba80 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: dffffc0000000000 R08: 0000000000000001 R09: fffff52000156f5d R10: fffff52000156f5d R11: 1ffff92000156f5c R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2bea75b718 CR3: 000000001d0cc000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> btrfs_qgroup_rescan_worker+0x3bb/0x6a0 fs/btrfs/qgroup.c:3402 btrfs_work_helper+0x312/0x850 fs/btrfs/async-thread.c:280 process_one_work+0x877/0xdb0 kernel/workqueue.c:2289 worker_thread+0xb14/0x1330 kernel/workqueue.c:2436 kthread+0x266/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 </TASK> Modules linked in: So fix this by having the rescan worker function not attempt to start a transaction if it didn't do any rescan work. CVE-2023-52896 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: xhci: Fix null pointer dereference when host dies Make sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race and cause null pointer dereference when host suddenly dies. Usb core may call xhci_free_dev() which frees the xhci->devs[slot_id] virt device at the same time that xhci_kill_endpoint_urbs() tries to loop through all the device's endpoints, checking if there are any cancelled urbs left to give back. hold the xhci spinlock while freeing the virt device CVE-2023-52898 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix general protection fault in nilfs_btree_insert() If nilfs2 reads a corrupted disk image and tries to reads a b-tree node block by calling __nilfs_btree_get_block() against an invalid virtual block address, it returns -ENOENT because conversion of the virtual block address to a disk block address fails. However, this return value is the same as the internal code that b-tree lookup routines return to indicate that the block being searched does not exist, so functions that operate on that b-tree may misbehave. When nilfs_btree_insert() receives this spurious 'not found' code from nilfs_btree_do_lookup(), it misunderstands that the 'not found' check was successful and continues the insert operation using incomplete lookup path data, causing the following crash: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] ... RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline] RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline] RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238 Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89 ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 <42> 80 3c 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02 ... Call Trace: <TASK> nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline] nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147 nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101 __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991 __block_write_begin fs/buffer.c:2041 [inline] block_write_begin+0x93/0x1e0 fs/buffer.c:2102 nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261 generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772 __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900 generic_file_write_iter+0xab/0x310 mm/filemap.c:3932 call_write_iter include/linux/fs.h:2186 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd ... </TASK> This patch fixes the root cause of this problem by replacing the error code that __nilfs_btree_get_block() returns on block address conversion failure from -ENOENT to another internal code -EINVAL which means that the b-tree metadata is corrupted. By returning -EINVAL, it propagates without glitches, and for all relevant b-tree operations, functions in the upper bmap layer output an error message indicating corrupted b-tree metadata via nilfs_bmap_convert_error(), and code -EIO will be eventually returned as it should be. CVE-2023-52900 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Check endpoint is valid before dereferencing it When the host controller is not responding, all URBs queued to all endpoints need to be killed. This can cause a kernel panic if we dereference an invalid endpoint. Fix this by using xhci_get_virt_ep() helper to find the endpoint and checking if the endpoint is valid before dereferencing it. [233311.853271] xhci-hcd xhci-hcd.1.auto: xHCI host controller not responding, assume dead [233311.853393] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000e8 [233311.853964] pc : xhci_hc_died+0x10c/0x270 [233311.853971] lr : xhci_hc_died+0x1ac/0x270 [233311.854077] Call trace: [233311.854085] xhci_hc_died+0x10c/0x270 [233311.854093] xhci_stop_endpoint_command_watchdog+0x100/0x1a4 [233311.854105] call_timer_fn+0x50/0x2d4 [233311.854112] expire_timers+0xac/0x2e4 [233311.854118] run_timer_softirq+0x300/0xabc [233311.854127] __do_softirq+0x148/0x528 [233311.854135] irq_exit+0x194/0x1a8 [233311.854143] __handle_domain_irq+0x164/0x1d0 [233311.854149] gic_handle_irq.22273+0x10c/0x188 [233311.854156] el1_irq+0xfc/0x1a8 [233311.854175] lpm_cpuidle_enter+0x25c/0x418 [msm_pm] [233311.854185] cpuidle_enter_state+0x1f0/0x764 [233311.854194] do_idle+0x594/0x6ac [233311.854201] cpu_startup_entry+0x7c/0x80 [233311.854209] secondary_start_kernel+0x170/0x198 CVE-2023-52901 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix resource leakage in VF driver unbind resources allocated like mcam entries to support the Ntuple feature and hash tables for the tc feature are not getting freed in driver unbind. This patch fixes the issue. CVE-2023-52905 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: Wait for out_urb's completion in pn533_usb_send_frame() Fix a use-after-free that occurs in hcd when in_urb sent from pn533_usb_send_frame() is completed earlier than out_urb. Its callback frees the skb data in pn533_send_async_complete() that is used as a transfer buffer of out_urb. Wait before sending in_urb until the callback of out_urb is called. To modify the callback of out_urb alone, separate the complete function of out_urb and ack_urb. Found by a modified version of syzkaller. BUG: KASAN: use-after-free in dummy_timer Call Trace: memcpy (mm/kasan/shadow.c:65) dummy_perform_transfer (drivers/usb/gadget/udc/dummy_hcd.c:1352) transfer (drivers/usb/gadget/udc/dummy_hcd.c:1453) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:1972) arch_static_branch (arch/x86/include/asm/jump_label.h:27) static_key_false (include/linux/jump_label.h:207) timer_expire_exit (include/trace/events/timer.h:127) call_timer_fn (kernel/time/timer.c:1475) expire_timers (kernel/time/timer.c:1519) __run_timers (kernel/time/timer.c:1790) run_timer_softirq (kernel/time/timer.c:1803) CVE-2023-52907 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/msm: another fix for the headless Adreno GPU Fix another oops reproducible when rebooting the board with the Adreno GPU working in the headless mode (e.g. iMX platforms). Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read [00000000] *pgd=74936831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] ARM CPU: 0 PID: 51 Comm: reboot Not tainted 6.2.0-rc1-dirty #11 Hardware name: Freescale i.MX53 (Device Tree Support) PC is at msm_atomic_commit_tail+0x50/0x970 LR is at commit_tail+0x9c/0x188 pc : [<c06aa430>] lr : [<c067a214>] psr: 600e0013 sp : e0851d30 ip : ee4eb7eb fp : 00090acc r10: 00000058 r9 : c2193014 r8 : c4310000 r7 : c4759380 r6 : 07bef61d r5 : 00000000 r4 : 00000000 r3 : c44cc440 r2 : 00000000 r1 : 00000000 r0 : 00000000 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 74910019 DAC: 00000051 Register r0 information: NULL pointer Register r1 information: NULL pointer Register r2 information: NULL pointer Register r3 information: slab kmalloc-1k start c44cc400 pointer offset 64 size 1024 Register r4 information: NULL pointer Register r5 information: NULL pointer Register r6 information: non-paged memory Register r7 information: slab kmalloc-128 start c4759380 pointer offset 0 size 128 Register r8 information: slab kmalloc-2k start c4310000 pointer offset 0 size 2048 Register r9 information: non-slab/vmalloc memory Register r10 information: non-paged memory Register r11 information: non-paged memory Register r12 information: non-paged memory Process reboot (pid: 51, stack limit = 0xc80046d9) Stack: (0xe0851d30 to 0xe0852000) 1d20: c4759380 fbd77200 000005ff 002b9c70 1d40: c4759380 c4759380 00000000 07bef61d 00000600 c0d6fe7c c2193014 00000058 1d60: 00090acc c067a214 00000000 c4759380 c4310000 00000000 c44cc854 c067a89c 1d80: 00000000 00000000 00000000 c4310468 00000000 c4759380 c4310000 c4310468 1da0: c4310470 c0643258 c4759380 00000000 00000000 c0c4ee24 00000000 c44cc810 1dc0: 00000000 c0c4ee24 00000000 c44cc810 00000000 0347d2a8 e0851e00 e0851e00 1de0: c4759380 c067ad20 c4310000 00000000 c44cc810 c27f8718 c44cc854 c067adb8 1e00: c4933000 00000002 00000001 00000000 00000000 c2130850 00000000 c2130854 1e20: c25fc488 00000000 c0ff162c 00000000 00000001 00000002 00000000 00000000 1e40: c43102c0 c43102c0 00000000 0347d2a8 c44cc810 c44cc814 c2133da8 c06d1a60 1e60: 00000000 00000000 00079028 c2012f24 fee1dead c4933000 00000058 c01431e4 1e80: 01234567 c0143a20 00000000 00000000 00000000 00000000 00000000 00000000 1ea0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 1ec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 1ee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 1f00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 1f20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 1f40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 1f60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 1f80: 00000000 00000000 00000000 0347d2a8 00000002 00000004 00000078 00000058 1fa0: c010028c c0100060 00000002 00000004 fee1dead 28121969 01234567 00079028 1fc0: 00000002 00000004 00000078 00000058 0002fdc5 00000000 00000000 00090acc 1fe0: 00000058 becc9c64 b6e97e05 b6e0e5f6 600e0030 fee1dead 00000000 00000000 msm_atomic_commit_tail from commit_tail+0x9c/0x188 commit_tail from drm_atomic_helper_commit+0x160/0x188 drm_atomic_helper_commit from drm_atomic_commit+0xac/0xe0 drm_atomic_commit from drm_atomic_helper_disable_all+0x1b0/0x1c0 drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x88/0x140 drm_atomic_helper_shutdown from device_shutdown+0x16c/0x240 device_shutdown from kernel_restart+0x38/0x90 kernel_restart from __do_sys_reboot+0x ---truncated--- CVE-2023-52911 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix possible NULL pointer dereference in send_acknowledge() Handle memory allocation failure from nci_skb_alloc() (calling alloc_skb()) to avoid possible NULL pointer dereference. CVE-2023-52919 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: can: bcm: Fix UAF in bcm_proc_show() BUG: KASAN: slab-use-after-free in bcm_proc_show+0x969/0xa80 Read of size 8 at addr ffff888155846230 by task cat/7862 CPU: 1 PID: 7862 Comm: cat Not tainted 6.5.0-rc1-00153-gc8746099c197 #230 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xd5/0x150 print_report+0xc1/0x5e0 kasan_report+0xba/0xf0 bcm_proc_show+0x969/0xa80 seq_read_iter+0x4f6/0x1260 seq_read+0x165/0x210 proc_reg_read+0x227/0x300 vfs_read+0x1d5/0x8d0 ksys_read+0x11e/0x240 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd Allocated by task 7846: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x9e/0xa0 bcm_sendmsg+0x264b/0x44e0 sock_sendmsg+0xda/0x180 ____sys_sendmsg+0x735/0x920 ___sys_sendmsg+0x11d/0x1b0 __sys_sendmsg+0xfa/0x1d0 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task 7846: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x27/0x40 ____kasan_slab_free+0x161/0x1c0 slab_free_freelist_hook+0x119/0x220 __kmem_cache_free+0xb4/0x2e0 rcu_core+0x809/0x1bd0 bcm_op is freed before procfs entry be removed in bcm_release(), this lead to bcm_proc_show() may read the freed bcm_op. CVE-2023-52922 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix potential bit_17 double-free A userspace with multiple threads racing I915_GEM_SET_TILING to set the tiling to I915_TILING_NONE could trigger a double free of the bit_17 bitmask. (Or conversely leak memory on the transition to tiled.) Move allocation/free'ing of the bitmask within the section protected by the obj lock. [tursulin: Correct fixes tag and added cc stable.] (cherry picked from commit 10e0cbaaf1104f449d695c80bcacf930dcd3c42e) CVE-2023-52930 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: Squashfs: fix handling and sanity checking of xattr_ids count A Sysbot [1] corrupted filesystem exposes two flaws in the handling and sanity checking of the xattr_ids count in the filesystem. Both of these flaws cause computation overflow due to incorrect typing. In the corrupted filesystem the xattr_ids value is 4294967071, which stored in a signed variable becomes the negative number -225. Flaw 1 (64-bit systems only): The signed integer xattr_ids variable causes sign extension. This causes variable overflow in the SQUASHFS_XATTR_*(A) macros. The variable is first multiplied by sizeof(struct squashfs_xattr_id) where the type of the sizeof operator is "unsigned long". On a 64-bit system this is 64-bits in size, and causes the negative number to be sign extended and widened to 64-bits and then become unsigned. This produces the very large number 18446744073709548016 or 2^64 - 3600. This number when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and divided by SQUASHFS_METADATA_SIZE overflows and produces a length of 0 (stored in len). Flaw 2 (32-bit systems only): On a 32-bit system the integer variable is not widened by the unsigned long type of the sizeof operator (32-bits), and the signedness of the variable has no effect due it always being treated as unsigned. The above corrupted xattr_ids value of 4294967071, when multiplied overflows and produces the number 4294963696 or 2^32 - 3400. This number when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and divided by SQUASHFS_METADATA_SIZE overflows again and produces a length of 0. The effect of the 0 length computation: In conjunction with the corrupted xattr_ids field, the filesystem also has a corrupted xattr_table_start value, where it matches the end of filesystem value of 850. This causes the following sanity check code to fail because the incorrectly computed len of 0 matches the incorrect size of the table reported by the superblock (0 bytes). len = SQUASHFS_XATTR_BLOCK_BYTES(*xattr_ids); indexes = SQUASHFS_XATTR_BLOCKS(*xattr_ids); /* * The computed size of the index table (len bytes) should exactly * match the table start and end points */ start = table_start + sizeof(*id_table); end = msblk->bytes_used; if (len != (end - start)) return ERR_PTR(-EINVAL); Changing the xattr_ids variable to be "usigned int" fixes the flaw on a 64-bit system. This relies on the fact the computation is widened by the unsigned long type of the sizeof operator. Casting the variable to u64 in the above macro fixes this flaw on a 32-bit system. It also means 64-bit systems do not implicitly rely on the type of the sizeof operator to widen the computation. [1] https://lore.kernel.org/lkml/000000000000cd44f005f1a0f17f@google.com/ CVE-2023-52933 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: mm/khugepaged: fix ->anon_vma race If an ->anon_vma is attached to the VMA, collapse_and_free_pmd() requires it to be locked. Page table traversal is allowed under any one of the mmap lock, the anon_vma lock (if the VMA is associated with an anon_vma), and the mapping lock (if the VMA is associated with a mapping); and so to be able to remove page tables, we must hold all three of them. retract_page_tables() bails out if an ->anon_vma is attached, but does this check before holding the mmap lock (as the comment above the check explains). If we racily merged an existing ->anon_vma (shared with a child process) from a neighboring VMA, subsequent rmap traversals on pages belonging to the child will be able to see the page tables that we are concurrently removing while assuming that nothing else can access them. Repeat the ->anon_vma check once we hold the mmap lock to ensure that there really is no concurrent page table access. Hitting this bug causes a lockdep warning in collapse_and_free_pmd(), in the line "lockdep_assert_held_write(&vma->anon_vma->root->rwsem)". It can also lead to use-after-free access. CVE-2023-52935 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: mm: memcg: fix NULL pointer in mem_cgroup_track_foreign_dirty_slowpath() As commit 18365225f044 ("hwpoison, memcg: forcibly uncharge LRU pages"), hwpoison will forcibly uncharg a LRU hwpoisoned page, the folio_memcg could be NULl, then, mem_cgroup_track_foreign_dirty_slowpath() could occurs a NULL pointer dereference, let's do not record the foreign writebacks for folio memcg is null in mem_cgroup_track_foreign_dirty() to fix it. CVE-2023-52939 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: can: isotp: split tx timer into transmission and timeout The timer for the transmission of isotp PDUs formerly had two functions: 1. send two consecutive frames with a given time gap 2. monitor the timeouts for flow control frames and the echo frames This led to larger txstate checks and potentially to a problem discovered by syzbot which enabled the panic_on_warn feature while testing. The former 'txtimer' function is split into 'txfrtimer' and 'txtimer' to handle the two above functionalities with separate timer callbacks. The two simplified timers now run in one-shot mode and make the state transitions (especially with isotp_rcv_echo) better understandable. CVE-2023-52941 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: iscsi_tcp: Fix UAF during logout when accessing the shost ipaddress Bug report and analysis from Ding Hui. During iSCSI session logout, if another task accesses the shost ipaddress attr, we can get a KASAN UAF report like this: [ 276.942144] BUG: KASAN: use-after-free in _raw_spin_lock_bh+0x78/0xe0 [ 276.942535] Write of size 4 at addr ffff8881053b45b8 by task cat/4088 [ 276.943511] CPU: 2 PID: 4088 Comm: cat Tainted: G E 6.1.0-rc8+ #3 [ 276.943997] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 [ 276.944470] Call Trace: [ 276.944943] <TASK> [ 276.945397] dump_stack_lvl+0x34/0x48 [ 276.945887] print_address_description.constprop.0+0x86/0x1e7 [ 276.946421] print_report+0x36/0x4f [ 276.947358] kasan_report+0xad/0x130 [ 276.948234] kasan_check_range+0x35/0x1c0 [ 276.948674] _raw_spin_lock_bh+0x78/0xe0 [ 276.949989] iscsi_sw_tcp_host_get_param+0xad/0x2e0 [iscsi_tcp] [ 276.951765] show_host_param_ISCSI_HOST_PARAM_IPADDRESS+0xe9/0x130 [scsi_transport_iscsi] [ 276.952185] dev_attr_show+0x3f/0x80 [ 276.953005] sysfs_kf_seq_show+0x1fb/0x3e0 [ 276.953401] seq_read_iter+0x402/0x1020 [ 276.954260] vfs_read+0x532/0x7b0 [ 276.955113] ksys_read+0xed/0x1c0 [ 276.955952] do_syscall_64+0x38/0x90 [ 276.956347] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 276.956769] RIP: 0033:0x7f5d3a679222 [ 276.957161] Code: c0 e9 b2 fe ff ff 50 48 8d 3d 32 c0 0b 00 e8 a5 fe 01 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24 [ 276.958009] RSP: 002b:00007ffc864d16a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 276.958431] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5d3a679222 [ 276.958857] RDX: 0000000000020000 RSI: 00007f5d3a4fe000 RDI: 0000000000000003 [ 276.959281] RBP: 00007f5d3a4fe000 R08: 00000000ffffffff R09: 0000000000000000 [ 276.959682] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000020000 [ 276.960126] R13: 0000000000000003 R14: 0000000000000000 R15: 0000557a26dada58 [ 276.960536] </TASK> [ 276.961357] Allocated by task 2209: [ 276.961756] kasan_save_stack+0x1e/0x40 [ 276.962170] kasan_set_track+0x21/0x30 [ 276.962557] __kasan_kmalloc+0x7e/0x90 [ 276.962923] __kmalloc+0x5b/0x140 [ 276.963308] iscsi_alloc_session+0x28/0x840 [scsi_transport_iscsi] [ 276.963712] iscsi_session_setup+0xda/0xba0 [libiscsi] [ 276.964078] iscsi_sw_tcp_session_create+0x1fd/0x330 [iscsi_tcp] [ 276.964431] iscsi_if_create_session.isra.0+0x50/0x260 [scsi_transport_iscsi] [ 276.964793] iscsi_if_recv_msg+0xc5a/0x2660 [scsi_transport_iscsi] [ 276.965153] iscsi_if_rx+0x198/0x4b0 [scsi_transport_iscsi] [ 276.965546] netlink_unicast+0x4d5/0x7b0 [ 276.965905] netlink_sendmsg+0x78d/0xc30 [ 276.966236] sock_sendmsg+0xe5/0x120 [ 276.966576] ____sys_sendmsg+0x5fe/0x860 [ 276.966923] ___sys_sendmsg+0xe0/0x170 [ 276.967300] __sys_sendmsg+0xc8/0x170 [ 276.967666] do_syscall_64+0x38/0x90 [ 276.968028] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 276.968773] Freed by task 2209: [ 276.969111] kasan_save_stack+0x1e/0x40 [ 276.969449] kasan_set_track+0x21/0x30 [ 276.969789] kasan_save_free_info+0x2a/0x50 [ 276.970146] __kasan_slab_free+0x106/0x190 [ 276.970470] __kmem_cache_free+0x133/0x270 [ 276.970816] device_release+0x98/0x210 [ 276.971145] kobject_cleanup+0x101/0x360 [ 276.971462] iscsi_session_teardown+0x3fb/0x530 [libiscsi] [ 276.971775] iscsi_sw_tcp_session_destroy+0xd8/0x130 [iscsi_tcp] [ 276.972143] iscsi_if_recv_msg+0x1bf1/0x2660 [scsi_transport_iscsi] [ 276.972485] iscsi_if_rx+0x198/0x4b0 [scsi_transport_iscsi] [ 276.972808] netlink_unicast+0x4d5/0x7b0 [ 276.973201] netlink_sendmsg+0x78d/0xc30 [ 276.973544] sock_sendmsg+0xe5/0x120 [ 276.973864] ____sys_sendmsg+0x5fe/0x860 [ 276.974248] ___sys_ ---truncated--- CVE-2023-52975 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: efi: fix potential NULL deref in efi_mem_reserve_persistent When iterating on a linked list, a result of memremap is dereferenced without checking it for NULL. This patch adds a check that falls back on allocating a new page in case memremap doesn't succeed. Found by Linux Verification Center (linuxtesting.org) with SVACE. [ardb: return -ENOMEM instead of breaking out of the loop] CVE-2023-52976 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. CVE-2023-52979 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix uaf for bfqq in bic_set_bfqq() After commit 64dc8c732f5c ("block, bfq: fix possible uaf for 'bfqq->bic'"), bic->bfqq will be accessed in bic_set_bfqq(), however, in some context bic->bfqq will be freed, and bic_set_bfqq() is called with the freed bic->bfqq. Fix the problem by always freeing bfqq after bic_set_bfqq(). CVE-2023-52983 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83822: Fix null pointer access on DP83825/DP83826 devices The probe() function is only used for the DP83822 PHY, leaving the private data pointer uninitialized for the smaller DP83825/26 models. While all uses of the private data structure are hidden in 82822 specific callbacks, configuring the interrupt is shared across all models. This causes a NULL pointer dereference on the smaller PHYs as it accesses the private data unchecked. Verifying the pointer avoids that. CVE-2023-52984 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ALSA: hda/via: Avoid potential array out-of-bound in add_secret_dac_path() snd_hda_get_connections() can return a negative error code. It may lead to accessing 'conn' array at a negative index. Found by Linux Verification Center (linuxtesting.org) with SVACE. CVE-2023-52988 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: firewire: fix memory leak for payload of request subaction to IEC 61883-1 FCP region This patch is fix for Linux kernel v2.6.33 or later. For request subaction to IEC 61883-1 FCP region, Linux FireWire subsystem have had an issue of use-after-free. The subsystem allows multiple user space listeners to the region, while data of the payload was likely released before the listeners execute read(2) to access to it for copying to user space. The issue was fixed by a commit 281e20323ab7 ("firewire: core: fix use-after-free regression in FCP handler"). The object of payload is duplicated in kernel space for each listener. When the listener executes ioctl(2) with FW_CDEV_IOC_SEND_RESPONSE request, the object is going to be released. However, it causes memory leak since the commit relies on call of release_request() in drivers/firewire/core-cdev.c. Against the expectation, the function is never called due to the design of release_client_resource(). The function delegates release task to caller when called with non-NULL fourth argument. The implementation of ioctl_send_response() is the case. It should release the object explicitly. This commit fixes the bug. CVE-2023-52989 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: bpf: Skip task with pid=1 in send_signal_common() The following kernel panic can be triggered when a task with pid=1 attaches a prog that attempts to send killing signal to itself, also see [1] for more details: Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b CPU: 3 PID: 1 Comm: systemd Not tainted 6.1.0-09652-g59fe41b5255f #148 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x100/0x178 lib/dump_stack.c:106 panic+0x2c4/0x60f kernel/panic.c:275 do_exit.cold+0x63/0xe4 kernel/exit.c:789 do_group_exit+0xd4/0x2a0 kernel/exit.c:950 get_signal+0x2460/0x2600 kernel/signal.c:2858 arch_do_signal_or_restart+0x78/0x5d0 arch/x86/kernel/signal.c:306 exit_to_user_mode_loop kernel/entry/common.c:168 [inline] exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296 do_syscall_64+0x44/0xb0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x63/0xcd So skip task with pid=1 in bpf_send_signal_common() to avoid the panic. [1] https://lore.kernel.org/bpf/20221222043507.33037-1-sunhao.th@gmail.com CVE-2023-52992 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL Baoquan reported that after triggering a crash the subsequent crash-kernel fails to boot about half of the time. It triggers a NULL pointer dereference in the periodic tick code. This happens because the legacy timer interrupt (IRQ0) is resent in software which happens in soft interrupt (tasklet) context. In this context get_irq_regs() returns NULL which leads to the NULL pointer dereference. The reason for the resend is a spurious APIC interrupt on the IRQ0 vector which is captured and leads to a resend when the legacy timer interrupt is enabled. This is wrong because the legacy PIC interrupts are level triggered and therefore should never be resent in software, but nothing ever sets the IRQ_LEVEL flag on those interrupts, so the core code does not know about their trigger type. Ensure that IRQ_LEVEL is set when the legacy PCI interrupts are set up. CVE-2023-52993 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: trace_events_hist: add check for return value of 'create_hist_field' Function 'create_hist_field' is called recursively at trace_events_hist.c:1954 and can return NULL-value that's why we have to check it to avoid null pointer dereference. Found by Linux Verification Center (linuxtesting.org) with SVACE. CVE-2023-53005 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: cifs: Fix oops due to uncleared server->smbd_conn in reconnect In smbd_destroy(), clear the server->smbd_conn pointer after freeing the smbd_connection struct that it points to so that reconnection doesn't get confused. CVE-2023-53006 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: tracing: Make sure trace_printk() can output as soon as it can be used Currently trace_printk() can be used as soon as early_trace_init() is called from start_kernel(). But if a crash happens, and "ftrace_dump_on_oops" is set on the kernel command line, all you get will be: [ 0.456075] <idle>-0 0dN.2. 347519us : Unknown type 6 [ 0.456075] <idle>-0 0dN.2. 353141us : Unknown type 6 [ 0.456075] <idle>-0 0dN.2. 358684us : Unknown type 6 This is because the trace_printk() event (type 6) hasn't been registered yet. That gets done via an early_initcall(), which may be early, but not early enough. Instead of registering the trace_printk() event (and other ftrace events, which are not trace events) via an early_initcall(), have them registered at the same time that trace_printk() can be used. This way, if there is a crash before early_initcall(), then the trace_printk()s will actually be useful. CVE-2023-53007 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: cifs: fix potential memory leaks in session setup Make sure to free cifs_ses::auth_key.response before allocating it as we might end up leaking memory in reconnect or mounting. CVE-2023-53008 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: bnxt: Do not read past the end of test names Test names were being concatenated based on a offset beyond the end of the first name, which tripped the buffer overflow detection logic: detected buffer overflow in strnlen [...] Call Trace: bnxt_ethtool_init.cold+0x18/0x18 Refactor struct hwrm_selftest_qlist_output to use an actual array, and adjust the concatenation to use snprintf() rather than a series of strncat() calls. CVE-2023-53010 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: HID: betop: check shape of output reports betopff_init() only checks the total sum of the report counts for each report field to be at least 4, but hid_betopff_play() expects 4 report fields. A device advertising an output report with one field and 4 report counts would pass the check but crash the kernel with a NULL pointer dereference in hid_betopff_play(). CVE-2023-53015 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix possible deadlock in rfcomm_sk_state_change syzbot reports a possible deadlock in rfcomm_sk_state_change [1]. While rfcomm_sock_connect acquires the sk lock and waits for the rfcomm lock, rfcomm_sock_release could have the rfcomm lock and hit a deadlock for acquiring the sk lock. Here's a simplified flow: rfcomm_sock_connect: lock_sock(sk) rfcomm_dlc_open: rfcomm_lock() rfcomm_sock_release: rfcomm_sock_shutdown: rfcomm_lock() __rfcomm_dlc_close: rfcomm_k_state_change: lock_sock(sk) This patch drops the sk lock before calling rfcomm_dlc_open to avoid the possible deadlock and holds sk's reference count to prevent use-after-free after rfcomm_dlc_open completes. CVE-2023-53016 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: mdio: validate parameter addr in mdiobus_get_phy() The caller may pass any value as addr, what may result in an out-of-bounds access to array mdio_map. One existing case is stmmac_init_phy() that may pass -1 as addr. Therefore validate addr before using it. CVE-2023-53019 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: nfc: Fix use-after-free in local_cleanup() Fix a use-after-free that occurs in kfree_skb() called from local_cleanup(). This could happen when killing nfc daemon (e.g. neard) after detaching an nfc device. When detaching an nfc device, local_cleanup() called from nfc_llcp_unregister_device() frees local->rx_pending and decreases local->ref by kref_put() in nfc_llcp_local_put(). In the terminating process, nfc daemon releases all sockets and it leads to decreasing local->ref. After the last release of local->ref, local_cleanup() called from local_release() frees local->rx_pending again, which leads to the bug. Setting local->rx_pending to NULL in local_cleanup() could prevent use-after-free when local_cleanup() is called twice. Found by a modified version of syzkaller. BUG: KASAN: use-after-free in kfree_skb() Call Trace: dump_stack_lvl (lib/dump_stack.c:106) print_address_description.constprop.0.cold (mm/kasan/report.c:306) kasan_check_range (mm/kasan/generic.c:189) kfree_skb (net/core/skbuff.c:955) local_cleanup (net/nfc/llcp_core.c:159) nfc_llcp_local_put.part.0 (net/nfc/llcp_core.c:172) nfc_llcp_local_put (net/nfc/llcp_core.c:181) llcp_sock_destruct (net/nfc/llcp_sock.c:959) __sk_destruct (net/core/sock.c:2133) sk_destruct (net/core/sock.c:2181) __sk_free (net/core/sock.c:2192) sk_free (net/core/sock.c:2203) llcp_sock_release (net/nfc/llcp_sock.c:646) __sock_release (net/socket.c:650) sock_close (net/socket.c:1365) __fput (fs/file_table.c:306) task_work_run (kernel/task_work.c:179) ptrace_notify (kernel/signal.c:2354) syscall_exit_to_user_mode_prepare (kernel/entry/common.c:278) syscall_exit_to_user_mode (kernel/entry/common.c:296) do_syscall_64 (arch/x86/entry/common.c:86) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:106) Allocated by task 4719: kasan_save_stack (mm/kasan/common.c:45) __kasan_slab_alloc (mm/kasan/common.c:325) slab_post_alloc_hook (mm/slab.h:766) kmem_cache_alloc_node (mm/slub.c:3497) __alloc_skb (net/core/skbuff.c:552) pn533_recv_response (drivers/nfc/pn533/usb.c:65) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1671) usb_giveback_urb_bh (drivers/usb/core/hcd.c:1704) tasklet_action_common.isra.0 (kernel/softirq.c:797) __do_softirq (kernel/softirq.c:571) Freed by task 1901: kasan_save_stack (mm/kasan/common.c:45) kasan_set_track (mm/kasan/common.c:52) kasan_save_free_info (mm/kasan/genericdd.c:518) __kasan_slab_free (mm/kasan/common.c:236) kmem_cache_free (mm/slub.c:3809) kfree_skbmem (net/core/skbuff.c:874) kfree_skb (net/core/skbuff.c:931) local_cleanup (net/nfc/llcp_core.c:159) nfc_llcp_unregister_device (net/nfc/llcp_core.c:1617) nfc_unregister_device (net/nfc/core.c:1179) pn53x_unregister_nfc (drivers/nfc/pn533/pn533.c:2846) pn533_usb_disconnect (drivers/nfc/pn533/usb.c:579) usb_unbind_interface (drivers/usb/core/driver.c:458) device_release_driver_internal (drivers/base/dd.c:1279) bus_remove_device (drivers/base/bus.c:529) device_del (drivers/base/core.c:3665) usb_disable_device (drivers/usb/core/message.c:1420) usb_disconnect (drivers/usb/core.c:2261) hub_event (drivers/usb/core/hub.c:5833) process_one_work (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:212 include/trace/events/workqueue.h:108 kernel/workqueue.c:2281) worker_thread (include/linux/list.h:282 kernel/workqueue.c:2423) kthread (kernel/kthread.c:319) ret_from_fork (arch/x86/entry/entry_64.S:301) CVE-2023-53023 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: bpf: Fix pointer-leak due to insufficient speculative store bypass mitigation To mitigate Spectre v4, 2039f26f3aca ("bpf: Fix leakage due to insufficient speculative store bypass mitigation") inserts lfence instructions after 1) initializing a stack slot and 2) spilling a pointer to the stack. However, this does not cover cases where a stack slot is first initialized with a pointer (subject to sanitization) but then overwritten with a scalar (not subject to sanitization because the slot was already initialized). In this case, the second write may be subject to speculative store bypass (SSB) creating a speculative pointer-as-scalar type confusion. This allows the program to subsequently leak the numerical pointer value using, for example, a branch-based cache side channel. To fix this, also sanitize scalars if they write a stack slot that previously contained a pointer. Assuming that pointer-spills are only generated by LLVM on register-pressure, the performance impact on most real-world BPF programs should be small. The following unprivileged BPF bytecode drafts a minimal exploit and the mitigation: [...] // r6 = 0 or 1 (skalar, unknown user input) // r7 = accessible ptr for side channel // r10 = frame pointer (fp), to be leaked // r9 = r10 # fp alias to encourage ssb *(u64 *)(r9 - 8) = r10 // fp[-8] = ptr, to be leaked // lfence added here because of pointer spill to stack. // // Ommitted: Dummy bpf_ringbuf_output() here to train alias predictor // for no r9-r10 dependency. // *(u64 *)(r10 - 8) = r6 // fp[-8] = scalar, overwrites ptr // 2039f26f3aca: no lfence added because stack slot was not STACK_INVALID, // store may be subject to SSB // // fix: also add an lfence when the slot contained a ptr // r8 = *(u64 *)(r9 - 8) // r8 = architecturally a scalar, speculatively a ptr // // leak ptr using branch-based cache side channel: r8 &= 1 // choose bit to leak if r8 == 0 goto SLOW // no mispredict // architecturally dead code if input r6 is 0, // only executes speculatively iff ptr bit is 1 r8 = *(u64 *)(r7 + 0) # encode bit in cache (0: slow, 1: fast) SLOW: [...] After running this, the program can time the access to *(r7 + 0) to determine whether the chosen pointer bit was 0 or 1. Repeat this 64 times to recover the whole address on amd64. In summary, sanitization can only be skipped if one scalar is overwritten with another scalar. Scalar-confusion due to speculative store bypass can not lead to invalid accesses because the pointer bounds deducted during verification are enforced using branchless logic. See 979d63d50c0c ("bpf: prevent out of bounds speculation on pointer arithmetic") for details. Do not make the mitigation depend on !env->allow_{uninit_stack,ptr_leaks} because speculative leaks are likely unexpected if these were enabled. For example, leaking the address to a protected log file may be acceptable while disabling the mitigation might unintentionally leak the address into the cached-state of a map that is accessible to unprivileged processes. CVE-2023-53024 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix ib block iterator counter overflow When registering a new DMA MR after selecting the best aligned page size for it, we iterate over the given sglist to split each entry to smaller, aligned to the selected page size, DMA blocks. In given circumstances where the sg entry and page size fit certain sizes and the sg entry is not aligned to the selected page size, the total size of the aligned pages we need to cover the sg entry is >= 4GB. Under this circumstances, while iterating page aligned blocks, the counter responsible for counting how much we advanced from the start of the sg entry is overflowed because its type is u32 and we pass 4GB in size. This can lead to an infinite loop inside the iterator function because the overflow prevents the counter to be larger than the size of the sg entry. Fix the presented problem by changing the advancement condition to eliminate overflow. Backtrace: [ 192.374329] efa_reg_user_mr_dmabuf [ 192.376783] efa_register_mr [ 192.382579] pgsz_bitmap 0xfffff000 rounddown 0x80000000 [ 192.386423] pg_sz [0x80000000] umem_length[0xc0000000] [ 192.392657] start 0x0 length 0xc0000000 params.page_shift 31 params.page_num 3 [ 192.399559] hp_cnt[3], pages_in_hp[524288] [ 192.403690] umem->sgt_append.sgt.nents[1] [ 192.407905] number entries: [1], pg_bit: [31] [ 192.411397] biter->__sg_nents [1] biter->__sg [0000000008b0c5d8] [ 192.415601] biter->__sg_advance [665837568] sg_dma_len[3221225472] [ 192.419823] biter->__sg_nents [1] biter->__sg [0000000008b0c5d8] [ 192.423976] biter->__sg_advance [2813321216] sg_dma_len[3221225472] [ 192.428243] biter->__sg_nents [1] biter->__sg [0000000008b0c5d8] [ 192.432397] biter->__sg_advance [665837568] sg_dma_len[3221225472] CVE-2023-53026 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: Revert "wifi: mac80211: fix memory leak in ieee80211_if_add()" This reverts commit 13e5afd3d773c6fc6ca2b89027befaaaa1ea7293. ieee80211_if_free() is already called from free_netdev(ndev) because ndev->priv_destructor == ieee80211_if_free syzbot reported: general protection fault, probably for non-canonical address 0xdffffc0000000004: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] CPU: 0 PID: 10041 Comm: syz-executor.0 Not tainted 6.2.0-rc2-syzkaller-00388-g55b98837e37d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 RIP: 0010:pcpu_get_page_chunk mm/percpu.c:262 [inline] RIP: 0010:pcpu_chunk_addr_search mm/percpu.c:1619 [inline] RIP: 0010:free_percpu mm/percpu.c:2271 [inline] RIP: 0010:free_percpu+0x186/0x10f0 mm/percpu.c:2254 Code: 80 3c 02 00 0f 85 f5 0e 00 00 48 8b 3b 48 01 ef e8 cf b3 0b 00 48 ba 00 00 00 00 00 fc ff df 48 8d 78 20 48 89 f9 48 c1 e9 03 <80> 3c 11 00 0f 85 3b 0e 00 00 48 8b 58 20 48 b8 00 00 00 00 00 fc RSP: 0018:ffffc90004ba7068 EFLAGS: 00010002 RAX: 0000000000000000 RBX: ffff88823ffe2b80 RCX: 0000000000000004 RDX: dffffc0000000000 RSI: ffffffff81c1f4e7 RDI: 0000000000000020 RBP: ffffe8fffe8fc220 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 1ffffffff2179ab2 R12: ffff8880b983d000 R13: 0000000000000003 R14: 0000607f450fc220 R15: ffff88823ffe2988 FS: 00007fcb349de700(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b32220000 CR3: 000000004914f000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> netdev_run_todo+0x6bf/0x1100 net/core/dev.c:10352 ieee80211_register_hw+0x2663/0x4040 net/mac80211/main.c:1411 mac80211_hwsim_new_radio+0x2537/0x4d80 drivers/net/wireless/mac80211_hwsim.c:4583 hwsim_new_radio_nl+0xa09/0x10f0 drivers/net/wireless/mac80211_hwsim.c:5176 genl_family_rcv_msg_doit.isra.0+0x1e6/0x2d0 net/netlink/genetlink.c:968 genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline] genl_rcv_msg+0x4ff/0x7e0 net/netlink/genetlink.c:1065 netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2564 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1330 [inline] netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1356 netlink_sendmsg+0x91b/0xe10 net/netlink/af_netlink.c:1932 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xd3/0x120 net/socket.c:734 ____sys_sendmsg+0x712/0x8c0 net/socket.c:2476 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2530 __sys_sendmsg+0xf7/0x1c0 net/socket.c:2559 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd CVE-2023-53028 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix the use of GFP_KERNEL in atomic context on rt The commit 4af1b64f80fb ("octeontx2-pf: Fix lmtst ID used in aura free") uses the get/put_cpu() to protect the usage of percpu pointer in ->aura_freeptr() callback, but it also unnecessarily disable the preemption for the blockable memory allocation. The commit 87b93b678e95 ("octeontx2-pf: Avoid use of GFP_KERNEL in atomic context") tried to fix these sleep inside atomic warnings. But it only fix the one for the non-rt kernel. For the rt kernel, we still get the similar warnings like below. BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0 preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 3 locks held by swapper/0/1: #0: ffff800009fc5fe8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock+0x24/0x30 #1: ffff000100c276c0 (&mbox->lock){+.+.}-{3:3}, at: otx2_init_hw_resources+0x8c/0x3a4 #2: ffffffbfef6537e0 (&cpu_rcache->lock){+.+.}-{2:2}, at: alloc_iova_fast+0x1ac/0x2ac Preemption disabled at: [<ffff800008b1908c>] otx2_rq_aura_pool_init+0x14c/0x284 CPU: 20 PID: 1 Comm: swapper/0 Tainted: G W 6.2.0-rc3-rt1-yocto-preempt-rt #1 Hardware name: Marvell OcteonTX CN96XX board (DT) Call trace: dump_backtrace.part.0+0xe8/0xf4 show_stack+0x20/0x30 dump_stack_lvl+0x9c/0xd8 dump_stack+0x18/0x34 __might_resched+0x188/0x224 rt_spin_lock+0x64/0x110 alloc_iova_fast+0x1ac/0x2ac iommu_dma_alloc_iova+0xd4/0x110 __iommu_dma_map+0x80/0x144 iommu_dma_map_page+0xe8/0x260 dma_map_page_attrs+0xb4/0xc0 __otx2_alloc_rbuf+0x90/0x150 otx2_rq_aura_pool_init+0x1c8/0x284 otx2_init_hw_resources+0xe4/0x3a4 otx2_open+0xf0/0x610 __dev_open+0x104/0x224 __dev_change_flags+0x1e4/0x274 dev_change_flags+0x2c/0x7c ic_open_devs+0x124/0x2f8 ip_auto_config+0x180/0x42c do_one_initcall+0x90/0x4dc do_basic_setup+0x10c/0x14c kernel_init_freeable+0x10c/0x13c kernel_init+0x2c/0x140 ret_from_fork+0x10/0x20 Of course, we can shuffle the get/put_cpu() to only wrap the invocation of ->aura_freeptr() as what commit 87b93b678e95 does. But there are only two ->aura_freeptr() callbacks, otx2_aura_freeptr() and cn10k_aura_freeptr(). There is no usage of perpcu variable in the otx2_aura_freeptr() at all, so the get/put_cpu() seems redundant to it. We can move the get/put_cpu() into the corresponding callback which really has the percpu variable usage and avoid the sprinkling of get/put_cpu() in several places. CVE-2023-53029 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Avoid use of GFP_KERNEL in atomic context Using GFP_KERNEL in preemption disable context, causing below warning when CONFIG_DEBUG_ATOMIC_SLEEP is enabled. [ 32.542271] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 [ 32.550883] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0 [ 32.558707] preempt_count: 1, expected: 0 [ 32.562710] RCU nest depth: 0, expected: 0 [ 32.566800] CPU: 3 PID: 1 Comm: swapper/0 Tainted: G W 6.2.0-rc2-00269-gae9dcb91c606 #7 [ 32.576188] Hardware name: Marvell CN106XX board (DT) [ 32.581232] Call trace: [ 32.583670] dump_backtrace.part.0+0xe0/0xf0 [ 32.587937] show_stack+0x18/0x30 [ 32.591245] dump_stack_lvl+0x68/0x84 [ 32.594900] dump_stack+0x18/0x34 [ 32.598206] __might_resched+0x12c/0x160 [ 32.602122] __might_sleep+0x48/0xa0 [ 32.605689] __kmem_cache_alloc_node+0x2b8/0x2e0 [ 32.610301] __kmalloc+0x58/0x190 [ 32.613610] otx2_sq_aura_pool_init+0x1a8/0x314 [ 32.618134] otx2_open+0x1d4/0x9d0 To avoid use of GFP_ATOMIC for memory allocation, disable preemption after all memory allocation is done. CVE-2023-53030 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel-infoleak in nilfs_ioctl_wrap_copy() The ioctl helper function nilfs_ioctl_wrap_copy(), which exchanges a metadata array to/from user space, may copy uninitialized buffer regions to user space memory for read-only ioctl commands NILFS_IOCTL_GET_SUINFO and NILFS_IOCTL_GET_CPINFO. This can occur when the element size of the user space metadata given by the v_size member of the argument nilfs_argv structure is larger than the size of the metadata element (nilfs_suinfo structure or nilfs_cpinfo structure) on the file system side. KMSAN-enabled kernels detect this issue as follows: BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xc0/0x100 lib/usercopy.c:33 instrument_copy_to_user include/linux/instrumented.h:121 [inline] _copy_to_user+0xc0/0x100 lib/usercopy.c:33 copy_to_user include/linux/uaccess.h:169 [inline] nilfs_ioctl_wrap_copy+0x6fa/0xc10 fs/nilfs2/ioctl.c:99 nilfs_ioctl_get_info fs/nilfs2/ioctl.c:1173 [inline] nilfs_ioctl+0x2402/0x4450 fs/nilfs2/ioctl.c:1290 nilfs_compat_ioctl+0x1b8/0x200 fs/nilfs2/ioctl.c:1343 __do_compat_sys_ioctl fs/ioctl.c:968 [inline] __se_compat_sys_ioctl+0x7dd/0x1000 fs/ioctl.c:910 __ia32_compat_sys_ioctl+0x93/0xd0 fs/ioctl.c:910 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Uninit was created at: __alloc_pages+0x9f6/0xe90 mm/page_alloc.c:5572 alloc_pages+0xab0/0xd80 mm/mempolicy.c:2287 __get_free_pages+0x34/0xc0 mm/page_alloc.c:5599 nilfs_ioctl_wrap_copy+0x223/0xc10 fs/nilfs2/ioctl.c:74 nilfs_ioctl_get_info fs/nilfs2/ioctl.c:1173 [inline] nilfs_ioctl+0x2402/0x4450 fs/nilfs2/ioctl.c:1290 nilfs_compat_ioctl+0x1b8/0x200 fs/nilfs2/ioctl.c:1343 __do_compat_sys_ioctl fs/ioctl.c:968 [inline] __se_compat_sys_ioctl+0x7dd/0x1000 fs/ioctl.c:910 __ia32_compat_sys_ioctl+0x93/0xd0 fs/ioctl.c:910 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Bytes 16-127 of 3968 are uninitialized ... This eliminates the leak issue by initializing the page allocated as buffer using get_zeroed_page(). CVE-2023-53035 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Check kzalloc() in lpfc_sli4_cgn_params_read() If kzalloc() fails in lpfc_sli4_cgn_params_read(), then we rely on lpfc_read_object()'s routine to NULL check pdata. Currently, an early return error is thrown from lpfc_read_object() to protect us from NULL ptr dereference, but the errno code is -ENODEV. Change the errno code to a more appropriate -ENOMEM. CVE-2023-53038 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: ipc: Fix potential use-after-free in work function When a reset notify IPC message is received, the ISR schedules a work function and passes the ISHTP device to it via a global pointer ishtp_dev. If ish_probe() fails, the devm-managed device resources including ishtp_dev are freed, but the work is not cancelled, causing a use-after-free when the work function tries to access ishtp_dev. Use devm_work_autocancel() instead, so that the work is automatically cancelled if probe fails. CVE-2023-53039 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ca8210: fix mac_len negative array access This patch fixes a buffer overflow access of skb->data if ieee802154_hdr_peek_addrs() fails. CVE-2023-53040 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Perform lockless command completion in abort path While adding and removing the controller, the following call trace was observed: WARNING: CPU: 3 PID: 623596 at kernel/dma/mapping.c:532 dma_free_attrs+0x33/0x50 CPU: 3 PID: 623596 Comm: sh Kdump: loaded Not tainted 5.14.0-96.el9.x86_64 #1 RIP: 0010:dma_free_attrs+0x33/0x50 Call Trace: qla2x00_async_sns_sp_done+0x107/0x1b0 [qla2xxx] qla2x00_abort_srb+0x8e/0x250 [qla2xxx] ? ql_dbg+0x70/0x100 [qla2xxx] __qla2x00_abort_all_cmds+0x108/0x190 [qla2xxx] qla2x00_abort_all_cmds+0x24/0x70 [qla2xxx] qla2x00_abort_isp_cleanup+0x305/0x3e0 [qla2xxx] qla2x00_remove_one+0x364/0x400 [qla2xxx] pci_device_remove+0x36/0xa0 __device_release_driver+0x17a/0x230 device_release_driver+0x24/0x30 pci_stop_bus_device+0x68/0x90 pci_stop_and_remove_bus_device_locked+0x16/0x30 remove_store+0x75/0x90 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 ? do_user_addr_fault+0x1d8/0x680 ? do_syscall_64+0x69/0x80 ? exc_page_fault+0x62/0x140 ? asm_exc_page_fault+0x8/0x30 entry_SYSCALL_64_after_hwframe+0x44/0xae The command was completed in the abort path during driver unload with a lock held, causing the warning in abort path. Hence complete the command without any lock held. CVE-2023-53041 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: dm stats: check for and propagate alloc_percpu failure Check alloc_precpu()'s return value and return an error from dm_stats_init() if it fails. Update alloc_dev() to fail if dm_stats_init() does. Otherwise, a NULL pointer dereference will occur in dm_stats_cleanup() even if dm-stats isn't being actively used. CVE-2023-53044 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_audio: don't let userspace block driver unbind In the unbind callback for f_uac1 and f_uac2, a call to snd_card_free() via g_audio_cleanup() will disconnect the card and then wait for all resources to be released, which happens when the refcount falls to zero. Since userspace can keep the refcount incremented by not closing the relevant file descriptor, the call to unbind may block indefinitely. This can cause a deadlock during reboot, as evidenced by the following blocked task observed on my machine: task:reboot state:D stack:0 pid:2827 ppid:569 flags:0x0000000c Call trace: __switch_to+0xc8/0x140 __schedule+0x2f0/0x7c0 schedule+0x60/0xd0 schedule_timeout+0x180/0x1d4 wait_for_completion+0x78/0x180 snd_card_free+0x90/0xa0 g_audio_cleanup+0x2c/0x64 afunc_unbind+0x28/0x60 ... kernel_restart+0x4c/0xac __do_sys_reboot+0xcc/0x1ec __arm64_sys_reboot+0x28/0x30 invoke_syscall+0x4c/0x110 ... The issue can also be observed by opening the card with arecord and then stopping the process through the shell before unbinding: # arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null Recording WAVE '/dev/null' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo ^Z[1]+ Stopped arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null # echo gadget.0 > /sys/bus/gadget/drivers/configfs-gadget/unbind (observe that the unbind command never finishes) Fix the problem by using snd_card_free_when_closed() instead, which will still disconnect the card as desired, but defer the task of freeing the resources to the core once userspace closes its file descriptor. CVE-2023-53045 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: ucsi: Fix NULL pointer deref in ucsi_connector_change() When ucsi_init() fails, ucsi->connector is NULL, yet in case of ucsi_acpi we may still get events which cause the ucs_acpi code to call ucsi_connector_change(), which then derefs the NULL ucsi->connector pointer. Fix this by not setting ucsi->ntfy inside ucsi_init() until ucsi_init() has succeeded, so that ucsi_connector_change() ignores the events because UCSI_ENABLE_NTFY_CONNECTOR_CHANGE is not set in the ntfy mask. CVE-2023-53049 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: dm crypt: add cond_resched() to dmcrypt_write() The loop in dmcrypt_write may be running for unbounded amount of time, thus we need cond_resched() in it. This commit fixes the following warning: [ 3391.153255][ C12] watchdog: BUG: soft lockup - CPU#12 stuck for 23s! [dmcrypt_write/2:2897] ... [ 3391.387210][ C12] Call trace: [ 3391.390338][ C12] blk_attempt_bio_merge.part.6+0x38/0x158 [ 3391.395970][ C12] blk_attempt_plug_merge+0xc0/0x1b0 [ 3391.401085][ C12] blk_mq_submit_bio+0x398/0x550 [ 3391.405856][ C12] submit_bio_noacct+0x308/0x380 [ 3391.410630][ C12] dmcrypt_write+0x1e4/0x208 [dm_crypt] [ 3391.416005][ C12] kthread+0x130/0x138 [ 3391.419911][ C12] ret_from_fork+0x10/0x18 CVE-2023-53051 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: cifs: fix use-after-free bug in refresh_cache_worker() The UAF bug occurred because we were putting DFS root sessions in cifs_umount() while DFS cache refresher was being executed. Make DFS root sessions have same lifetime as DFS tcons so we can avoid the use-after-free bug is DFS cache refresher and other places that require IPCs to get new DFS referrals on. Also, get rid of mount group handling in DFS cache as we no longer need it. This fixes below use-after-free bug catched by KASAN [ 379.946955] BUG: KASAN: use-after-free in __refresh_tcon.isra.0+0x10b/0xc10 [cifs] [ 379.947642] Read of size 8 at addr ffff888018f57030 by task kworker/u4:3/56 [ 379.948096] [ 379.948208] CPU: 0 PID: 56 Comm: kworker/u4:3 Not tainted 6.2.0-rc7-lku #23 [ 379.948661] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552-rebuilt.opensuse.org 04/01/2014 [ 379.949368] Workqueue: cifs-dfscache refresh_cache_worker [cifs] [ 379.949942] Call Trace: [ 379.950113] <TASK> [ 379.950260] dump_stack_lvl+0x50/0x67 [ 379.950510] print_report+0x16a/0x48e [ 379.950759] ? __virt_addr_valid+0xd8/0x160 [ 379.951040] ? __phys_addr+0x41/0x80 [ 379.951285] kasan_report+0xdb/0x110 [ 379.951533] ? __refresh_tcon.isra.0+0x10b/0xc10 [cifs] [ 379.952056] ? __refresh_tcon.isra.0+0x10b/0xc10 [cifs] [ 379.952585] __refresh_tcon.isra.0+0x10b/0xc10 [cifs] [ 379.953096] ? __pfx___refresh_tcon.isra.0+0x10/0x10 [cifs] [ 379.953637] ? __pfx___mutex_lock+0x10/0x10 [ 379.953915] ? lock_release+0xb6/0x720 [ 379.954167] ? __pfx_lock_acquire+0x10/0x10 [ 379.954443] ? refresh_cache_worker+0x34e/0x6d0 [cifs] [ 379.954960] ? __pfx_wb_workfn+0x10/0x10 [ 379.955239] refresh_cache_worker+0x4ad/0x6d0 [cifs] [ 379.955755] ? __pfx_refresh_cache_worker+0x10/0x10 [cifs] [ 379.956323] ? __pfx_lock_acquired+0x10/0x10 [ 379.956615] ? read_word_at_a_time+0xe/0x20 [ 379.956898] ? lockdep_hardirqs_on_prepare+0x12/0x220 [ 379.957235] process_one_work+0x535/0x990 [ 379.957509] ? __pfx_process_one_work+0x10/0x10 [ 379.957812] ? lock_acquired+0xb7/0x5f0 [ 379.958069] ? __list_add_valid+0x37/0xd0 [ 379.958341] ? __list_add_valid+0x37/0xd0 [ 379.958611] worker_thread+0x8e/0x630 [ 379.958861] ? __pfx_worker_thread+0x10/0x10 [ 379.959148] kthread+0x17d/0x1b0 [ 379.959369] ? __pfx_kthread+0x10/0x10 [ 379.959630] ret_from_fork+0x2c/0x50 [ 379.959879] </TASK> CVE-2023-53052 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: fix a devres leak in hw_enable upon suspend resume Each time the platform goes to low power, PM suspend / resume routines call: __dwc2_lowlevel_hw_enable -> devm_add_action_or_reset(). This adds a new devres each time. This may also happen at runtime, as dwc2_lowlevel_hw_enable() can be called from udc_start(). This can be seen with tracing: - echo 1 > /sys/kernel/debug/tracing/events/dev/devres_log/enable - go to low power - cat /sys/kernel/debug/tracing/trace A new "ADD" entry is found upon each low power cycle: ... devres_log: 49000000.usb-otg ADD 82a13bba devm_action_release (8 bytes) ... devres_log: 49000000.usb-otg ADD 49889daf devm_action_release (8 bytes) ... A second issue is addressed here: - regulator_bulk_enable() is called upon each PM cycle (suspend/resume). - regulator_bulk_disable() never gets called. So the reference count for these regulators constantly increase, by one upon each low power cycle, due to missing regulator_bulk_disable() call in __dwc2_lowlevel_hw_disable(). The original fix that introduced the devm_add_action_or_reset() call, fixed an issue during probe, that happens due to other errors in dwc2_driver_probe() -> dwc2_core_reset(). Then the probe fails without disabling regulators, when dr_mode == USB_DR_MODE_PERIPHERAL. Rather fix the error path: disable all the low level hardware in the error path, by using the "hsotg->ll_hw_enabled" flag. Checking dr_mode has been introduced to avoid a dual call to dwc2_lowlevel_hw_disable(). "ll_hw_enabled" should achieve the same (and is used currently in the remove() routine). CVE-2023-53054 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Synchronize the IOCB count to be in order A system hang was observed with the following call trace: BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 15 PID: 86747 Comm: nvme Kdump: loaded Not tainted 6.2.0+ #1 Hardware name: Dell Inc. PowerEdge R6515/04F3CJ, BIOS 2.7.3 03/31/2022 RIP: 0010:__wake_up_common+0x55/0x190 Code: 41 f6 01 04 0f 85 b2 00 00 00 48 8b 43 08 4c 8d 40 e8 48 8d 43 08 48 89 04 24 48 89 c6\ 49 8d 40 18 48 39 c6 0f 84 e9 00 00 00 <49> 8b 40 18 89 6c 24 14 31 ed 4c 8d 60 e8 41 8b 18 f6 c3 04 75 5d RSP: 0018:ffffb05a82afbba0 EFLAGS: 00010082 RAX: 0000000000000000 RBX: ffff8f9b83a00018 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff8f9b83a00020 RDI: ffff8f9b83a00018 RBP: 0000000000000001 R08: ffffffffffffffe8 R09: ffffb05a82afbbf8 R10: 70735f7472617473 R11: 5f30307832616c71 R12: 0000000000000001 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f815cf4c740(0000) GS:ffff8f9eeed80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010633a000 CR4: 0000000000350ee0 Call Trace: <TASK> __wake_up_common_lock+0x83/0xd0 qla_nvme_ls_req+0x21b/0x2b0 [qla2xxx] __nvme_fc_send_ls_req+0x1b5/0x350 [nvme_fc] nvme_fc_xmt_disconnect_assoc+0xca/0x110 [nvme_fc] nvme_fc_delete_association+0x1bf/0x220 [nvme_fc] ? nvme_remove_namespaces+0x9f/0x140 [nvme_core] nvme_do_delete_ctrl+0x5b/0xa0 [nvme_core] nvme_sysfs_delete+0x5f/0x70 [nvme_core] kernfs_fop_write_iter+0x12b/0x1c0 vfs_write+0x2a3/0x3b0 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x90 ? syscall_exit_work+0x103/0x130 ? syscall_exit_to_user_mode+0x12/0x30 ? do_syscall_64+0x69/0x90 ? exit_to_user_mode_loop+0xd0/0x130 ? exit_to_user_mode_prepare+0xec/0x100 ? syscall_exit_to_user_mode+0x12/0x30 ? do_syscall_64+0x69/0x90 ? syscall_exit_to_user_mode+0x12/0x30 ? do_syscall_64+0x69/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f815cd3eb97 The IOCB counts are out of order and that would block any commands from going out and subsequently hang the system. Synchronize the IOCB count to be in correct order. CVE-2023-53056 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/mlx5: E-Switch, Fix an Oops in error handling code The error handling dereferences "vport". There is nothing we can do if it is an error pointer except returning the error code. CVE-2023-53058 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: platform/chrome: cros_ec_chardev: fix kernel data leak from ioctl It is possible to peep kernel page's data by providing larger `insize` in struct cros_ec_command[1] when invoking EC host commands. Fix it by using zeroed memory. [1]: https://elixir.bootlin.com/linux/v6.2/source/include/linux/platform_data/cros_ec_proto.h#L74 CVE-2023-53059 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: igb: revert rtnl_lock() that causes deadlock The commit 6faee3d4ee8b ("igb: Add lock to avoid data race") adds rtnl_lock to eliminate a false data race shown below (FREE from device detaching) | (USE from netdev core) igb_remove | igb_ndo_get_vf_config igb_disable_sriov | vf >= adapter->vfs_allocated_count? kfree(adapter->vf_data) | adapter->vfs_allocated_count = 0 | | memcpy(... adapter->vf_data[vf] The above race will never happen and the extra rtnl_lock causes deadlock below [ 141.420169] <TASK> [ 141.420672] __schedule+0x2dd/0x840 [ 141.421427] schedule+0x50/0xc0 [ 141.422041] schedule_preempt_disabled+0x11/0x20 [ 141.422678] __mutex_lock.isra.13+0x431/0x6b0 [ 141.423324] unregister_netdev+0xe/0x20 [ 141.423578] igbvf_remove+0x45/0xe0 [igbvf] [ 141.423791] pci_device_remove+0x36/0xb0 [ 141.423990] device_release_driver_internal+0xc1/0x160 [ 141.424270] pci_stop_bus_device+0x6d/0x90 [ 141.424507] pci_stop_and_remove_bus_device+0xe/0x20 [ 141.424789] pci_iov_remove_virtfn+0xba/0x120 [ 141.425452] sriov_disable+0x2f/0xf0 [ 141.425679] igb_disable_sriov+0x4e/0x100 [igb] [ 141.426353] igb_remove+0xa0/0x130 [igb] [ 141.426599] pci_device_remove+0x36/0xb0 [ 141.426796] device_release_driver_internal+0xc1/0x160 [ 141.427060] driver_detach+0x44/0x90 [ 141.427253] bus_remove_driver+0x55/0xe0 [ 141.427477] pci_unregister_driver+0x2a/0xa0 [ 141.428296] __x64_sys_delete_module+0x141/0x2b0 [ 141.429126] ? mntput_no_expire+0x4a/0x240 [ 141.429363] ? syscall_trace_enter.isra.19+0x126/0x1a0 [ 141.429653] do_syscall_64+0x5b/0x80 [ 141.429847] ? exit_to_user_mode_prepare+0x14d/0x1c0 [ 141.430109] ? syscall_exit_to_user_mode+0x12/0x30 [ 141.430849] ? do_syscall_64+0x67/0x80 [ 141.431083] ? syscall_exit_to_user_mode_prepare+0x183/0x1b0 [ 141.431770] ? syscall_exit_to_user_mode+0x12/0x30 [ 141.432482] ? do_syscall_64+0x67/0x80 [ 141.432714] ? exc_page_fault+0x64/0x140 [ 141.432911] entry_SYSCALL_64_after_hwframe+0x72/0xdc Since the igb_disable_sriov() will call pci_disable_sriov() before releasing any resources, the netdev core will synchronize the cleanup to avoid any races. This patch removes the useless rtnl_(un)lock to guarantee correctness. CVE-2023-53060 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: usb: smsc95xx: Limit packet length to skb->len Packet length retrieved from descriptor may be larger than the actual socket buffer length. In such case the cloned skb passed up the network stack will leak kernel memory contents. CVE-2023-53062 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: iavf: fix hang on reboot with ice When a system with E810 with existing VFs gets rebooted the following hang may be observed. Pid 1 is hung in iavf_remove(), part of a network driver: PID: 1 TASK: ffff965400e5a340 CPU: 24 COMMAND: "systemd-shutdow" #0 [ffffaad04005fa50] __schedule at ffffffff8b3239cb #1 [ffffaad04005fae8] schedule at ffffffff8b323e2d #2 [ffffaad04005fb00] schedule_hrtimeout_range_clock at ffffffff8b32cebc #3 [ffffaad04005fb80] usleep_range_state at ffffffff8b32c930 #4 [ffffaad04005fbb0] iavf_remove at ffffffffc12b9b4c [iavf] #5 [ffffaad04005fbf0] pci_device_remove at ffffffff8add7513 #6 [ffffaad04005fc10] device_release_driver_internal at ffffffff8af08baa #7 [ffffaad04005fc40] pci_stop_bus_device at ffffffff8adcc5fc #8 [ffffaad04005fc60] pci_stop_and_remove_bus_device at ffffffff8adcc81e #9 [ffffaad04005fc70] pci_iov_remove_virtfn at ffffffff8adf9429 #10 [ffffaad04005fca8] sriov_disable at ffffffff8adf98e4 #11 [ffffaad04005fcc8] ice_free_vfs at ffffffffc04bb2c8 [ice] #12 [ffffaad04005fd10] ice_remove at ffffffffc04778fe [ice] #13 [ffffaad04005fd38] ice_shutdown at ffffffffc0477946 [ice] #14 [ffffaad04005fd50] pci_device_shutdown at ffffffff8add58f1 #15 [ffffaad04005fd70] device_shutdown at ffffffff8af05386 #16 [ffffaad04005fd98] kernel_restart at ffffffff8a92a870 #17 [ffffaad04005fda8] __do_sys_reboot at ffffffff8a92abd6 #18 [ffffaad04005fee0] do_syscall_64 at ffffffff8b317159 #19 [ffffaad04005ff08] __context_tracking_enter at ffffffff8b31b6fc #20 [ffffaad04005ff18] syscall_exit_to_user_mode at ffffffff8b31b50d #21 [ffffaad04005ff28] do_syscall_64 at ffffffff8b317169 #22 [ffffaad04005ff50] entry_SYSCALL_64_after_hwframe at ffffffff8b40009b RIP: 00007f1baa5c13d7 RSP: 00007fffbcc55a98 RFLAGS: 00000202 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1baa5c13d7 RDX: 0000000001234567 RSI: 0000000028121969 RDI: 00000000fee1dead RBP: 00007fffbcc55ca0 R8: 0000000000000000 R9: 00007fffbcc54e90 R10: 00007fffbcc55050 R11: 0000000000000202 R12: 0000000000000005 R13: 0000000000000000 R14: 00007fffbcc55af0 R15: 0000000000000000 ORIG_RAX: 00000000000000a9 CS: 0033 SS: 002b During reboot all drivers PM shutdown callbacks are invoked. In iavf_shutdown() the adapter state is changed to __IAVF_REMOVE. In ice_shutdown() the call chain above is executed, which at some point calls iavf_remove(). However iavf_remove() expects the VF to be in one of the states __IAVF_RUNNING, __IAVF_DOWN or __IAVF_INIT_FAILED. If that's not the case it sleeps forever. So if iavf_shutdown() gets invoked before iavf_remove() the system will hang indefinitely because the adapter is already in state __IAVF_REMOVE. Fix this by returning from iavf_remove() if the state is __IAVF_REMOVE, as we already went through iavf_shutdown(). CVE-2023-53064 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix perf_output_begin parameter is incorrectly invoked in perf_event_bpf_output syzkaller reportes a KASAN issue with stack-out-of-bounds. The call trace is as follows: dump_stack+0x9c/0xd3 print_address_description.constprop.0+0x19/0x170 __kasan_report.cold+0x6c/0x84 kasan_report+0x3a/0x50 __perf_event_header__init_id+0x34/0x290 perf_event_header__init_id+0x48/0x60 perf_output_begin+0x4a4/0x560 perf_event_bpf_output+0x161/0x1e0 perf_iterate_sb_cpu+0x29e/0x340 perf_iterate_sb+0x4c/0xc0 perf_event_bpf_event+0x194/0x2c0 __bpf_prog_put.constprop.0+0x55/0xf0 __cls_bpf_delete_prog+0xea/0x120 [cls_bpf] cls_bpf_delete_prog_work+0x1c/0x30 [cls_bpf] process_one_work+0x3c2/0x730 worker_thread+0x93/0x650 kthread+0x1b8/0x210 ret_from_fork+0x1f/0x30 commit 267fb27352b6 ("perf: Reduce stack usage of perf_output_begin()") use on-stack struct perf_sample_data of the caller function. However, perf_event_bpf_output uses incorrect parameter to convert small-sized data (struct perf_bpf_event) into large-sized data (struct perf_sample_data), which causes memory overwriting occurs in __perf_event_header__init_id. CVE-2023-53065 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: qed/qed_sriov: guard against NULL derefs from qed_iov_get_vf_info We have to make sure that the info returned by the helper is valid before using it. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. CVE-2023-53066 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: usb: lan78xx: Limit packet length to skb->len Packet length retrieved from descriptor may be larger than the actual socket buffer length. In such case the cloned skb passed up the network stack will leak kernel memory contents. Additionally prevent integer underflow when size is less than ETH_FCS_LEN. CVE-2023-53068 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix invalid address access in lookup_rec() when index is 0 KASAN reported follow problem: BUG: KASAN: use-after-free in lookup_rec Read of size 8 at addr ffff000199270ff0 by task modprobe CPU: 2 Comm: modprobe Call trace: kasan_report __asan_load8 lookup_rec ftrace_location arch_check_ftrace_location check_kprobe_address_safe register_kprobe When checking pg->records[pg->index - 1].ip in lookup_rec(), it can get a pg which is newly added to ftrace_pages_start in ftrace_process_locs(). Before the first pg->index++, index is 0 and accessing pg->records[-1].ip will cause this problem. Don't check the ip when pg->index is 0. CVE-2023-53075 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix shift-out-of-bounds in CalculateVMAndRowBytes [WHY] When PTEBufferSizeInRequests is zero, UBSAN reports the following warning because dml_log2 returns an unexpected negative value: shift exponent 4294966273 is too large for 32-bit type 'int' [HOW] In the case PTEBufferSizeInRequests is zero, skip the dml_log2() and assign the result directly. CVE-2023-53077 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_dh_alua: Fix memleak for 'qdata' in alua_activate() If alua_rtpg_queue() failed from alua_activate(), then 'qdata' is not freed, which will cause following memleak: unreferenced object 0xffff88810b2c6980 (size 32): comm "kworker/u16:2", pid 635322, jiffies 4355801099 (age 1216426.076s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 40 39 24 c1 ff ff ff ff 00 f8 ea 0a 81 88 ff ff @9$............. backtrace: [<0000000098f3a26d>] alua_activate+0xb0/0x320 [<000000003b529641>] scsi_dh_activate+0xb2/0x140 [<000000007b296db3>] activate_path_work+0xc6/0xe0 [dm_multipath] [<000000007adc9ace>] process_one_work+0x3c5/0x730 [<00000000c457a985>] worker_thread+0x93/0x650 [<00000000cb80e628>] kthread+0x1ba/0x210 [<00000000a1e61077>] ret_from_fork+0x22/0x30 Fix the problem by freeing 'qdata' in error path. CVE-2023-53078 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix steering rules cleanup vport's mc, uc and multicast rules are not deleted in teardown path when EEH happens. Since the vport's promisc settings(uc, mc and all) in firmware are reset after EEH, mlx5 driver will try to delete the above rules in the initialization path. This cause kernel crash because these software rules are no longer valid. Fix by nullifying these rules right after delete to avoid accessing any dangling pointers. Call Trace: __list_del_entry_valid+0xcc/0x100 (unreliable) tree_put_node+0xf4/0x1b0 [mlx5_core] tree_remove_node+0x30/0x70 [mlx5_core] mlx5_del_flow_rules+0x14c/0x1f0 [mlx5_core] esw_apply_vport_rx_mode+0x10c/0x200 [mlx5_core] esw_update_vport_rx_mode+0xb4/0x180 [mlx5_core] esw_vport_change_handle_locked+0x1ec/0x230 [mlx5_core] esw_enable_vport+0x130/0x260 [mlx5_core] mlx5_eswitch_enable_sriov+0x2a0/0x2f0 [mlx5_core] mlx5_device_enable_sriov+0x74/0x440 [mlx5_core] mlx5_load_one+0x114c/0x1550 [mlx5_core] mlx5_pci_resume+0x68/0xf0 [mlx5_core] eeh_report_resume+0x1a4/0x230 eeh_pe_dev_traverse+0x98/0x170 eeh_handle_normal_event+0x3e4/0x640 eeh_handle_event+0x4c/0x370 eeh_event_handler+0x14c/0x210 kthread+0x168/0x1b0 ret_from_kernel_thread+0x5c/0x84 CVE-2023-53079 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix data corruption after failed write When buffered write fails to copy data into underlying page cache page, ocfs2_write_end_nolock() just zeroes out and dirties the page. This can leave dirty page beyond EOF and if page writeback tries to write this page before write succeeds and expands i_size, page gets into inconsistent state where page dirty bit is clear but buffer dirty bits stay set resulting in page data never getting written and so data copied to the page is lost. Fix the problem by invalidating page beyond EOF after failed write. CVE-2023-53081 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/shmem-helper: Remove another errant put in error path drm_gem_shmem_mmap() doesn't own reference in error code path, resulting in the dma-buf shmem GEM object getting prematurely freed leading to a later use-after-free. CVE-2023-53084 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/i915/active: Fix misuse of non-idle barriers as fence trackers Users reported oopses on list corruptions when using i915 perf with a number of concurrently running graphics applications. Root cause analysis pointed at an issue in barrier processing code -- a race among perf open / close replacing active barriers with perf requests on kernel context and concurrent barrier preallocate / acquire operations performed during user context first pin / last unpin. When adding a request to a composite tracker, we try to reuse an existing fence tracker, already allocated and registered with that composite. The tracker we obtain may already track another fence, may be an idle barrier, or an active barrier. If the tracker we get occurs a non-idle barrier then we try to delete that barrier from a list of barrier tasks it belongs to. However, while doing that we don't respect return value from a function that performs the barrier deletion. Should the deletion ever fail, we would end up reusing the tracker still registered as a barrier task. Since the same structure field is reused with both fence callback lists and barrier tasks list, list corruptions would likely occur. Barriers are now deleted from a barrier tasks list by temporarily removing the list content, traversing that content with skip over the node to be deleted, then populating the list back with the modified content. Should that intentionally racy concurrent deletion attempts be not serialized, one or more of those may fail because of the list being temporary empty. Related code that ignores the results of barrier deletion was initially introduced in v5.4 by commit d8af05ff38ae ("drm/i915: Allow sharing the idle-barrier from other kernel requests"). However, all users of the barrier deletion routine were apparently serialized at that time, then the issue didn't exhibit itself. Results of git bisect with help of a newly developed igt@gem_barrier_race@remote-request IGT test indicate that list corruptions might start to appear after commit 311770173fac ("drm/i915/gt: Schedule request retirement when timeline idles"), introduced in v5.5. Respect results of barrier deletion attempts -- mark the barrier as idle only if successfully deleted from the list. Then, before proceeding with setting our fence as the one currently tracked, make sure that the tracker we've got is not a non-idle barrier. If that check fails then don't use that tracker but go back and try to acquire a new, usable one. v3: use unlikely() to document what outcome we expect (Andi), - fix bad grammar in commit description. v2: no code changes, - blame commit 311770173fac ("drm/i915/gt: Schedule request retirement when timeline idles"), v5.5, not commit d8af05ff38ae ("drm/i915: Allow sharing the idle-barrier from other kernel requests"), v5.4, - reword commit description. (cherry picked from commit 506006055769b10d1b2b4e22f636f3b45e0e9fc7) CVE-2023-53087 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: fix task hung in ext4_xattr_delete_inode Syzbot reported a hung task problem: ================================================================== INFO: task syz-executor232:5073 blocked for more than 143 seconds. Not tainted 6.2.0-rc2-syzkaller-00024-g512dee0c00ad #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-exec232 state:D stack:21024 pid:5073 ppid:5072 flags:0x00004004 Call Trace: <TASK> context_switch kernel/sched/core.c:5244 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6555 schedule+0xcb/0x190 kernel/sched/core.c:6631 __wait_on_freeing_inode fs/inode.c:2196 [inline] find_inode_fast+0x35a/0x4c0 fs/inode.c:950 iget_locked+0xb1/0x830 fs/inode.c:1273 __ext4_iget+0x22e/0x3ed0 fs/ext4/inode.c:4861 ext4_xattr_inode_iget+0x68/0x4e0 fs/ext4/xattr.c:389 ext4_xattr_inode_dec_ref_all+0x1a7/0xe50 fs/ext4/xattr.c:1148 ext4_xattr_delete_inode+0xb04/0xcd0 fs/ext4/xattr.c:2880 ext4_evict_inode+0xd7c/0x10b0 fs/ext4/inode.c:296 evict+0x2a4/0x620 fs/inode.c:664 ext4_orphan_cleanup+0xb60/0x1340 fs/ext4/orphan.c:474 __ext4_fill_super fs/ext4/super.c:5516 [inline] ext4_fill_super+0x81cd/0x8700 fs/ext4/super.c:5644 get_tree_bdev+0x400/0x620 fs/super.c:1282 vfs_get_tree+0x88/0x270 fs/super.c:1489 do_new_mount+0x289/0xad0 fs/namespace.c:3145 do_mount fs/namespace.c:3488 [inline] __do_sys_mount fs/namespace.c:3697 [inline] __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fa5406fd5ea RSP: 002b:00007ffc7232f968 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fa5406fd5ea RDX: 0000000020000440 RSI: 0000000020000000 RDI: 00007ffc7232f970 RBP: 00007ffc7232f970 R08: 00007ffc7232f9b0 R09: 0000000000000432 R10: 0000000000804a03 R11: 0000000000000202 R12: 0000000000000004 R13: 0000555556a7a2c0 R14: 00007ffc7232f9b0 R15: 0000000000000000 </TASK> ================================================================== The problem is that the inode contains an xattr entry with ea_inum of 15 when cleaning up an orphan inode <15>. When evict inode <15>, the reference counting of the corresponding EA inode is decreased. When EA inode <15> is found by find_inode_fast() in __ext4_iget(), it is found that the EA inode holds the I_FREEING flag and waits for the EA inode to complete deletion. As a result, when inode <15> is being deleted, we wait for inode <15> to complete the deletion, resulting in an infinite loop and triggering Hung Task. To solve this problem, we only need to check whether the ino of EA inode and parent is the same before getting EA inode. CVE-2023-53089 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix an illegal memory access In the kfd_wait_on_events() function, the kfd_event_waiter structure is allocated by alloc_event_waiters(), but the event field of the waiter structure is not initialized; When copy_from_user() fails in the kfd_wait_on_events() function, it will enter exception handling to release the previously allocated memory of the waiter structure; Due to the event field of the waiters structure being accessed in the free_waiters() function, this results in illegal memory access and system crash, here is the crash log: localhost kernel: RIP: 0010:native_queued_spin_lock_slowpath+0x185/0x1e0 localhost kernel: RSP: 0018:ffffaa53c362bd60 EFLAGS: 00010082 localhost kernel: RAX: ff3d3d6bff4007cb RBX: 0000000000000282 RCX: 00000000002c0000 localhost kernel: RDX: ffff9e855eeacb80 RSI: 000000000000279c RDI: ffffe7088f6a21d0 localhost kernel: RBP: ffffe7088f6a21d0 R08: 00000000002c0000 R09: ffffaa53c362be64 localhost kernel: R10: ffffaa53c362bbd8 R11: 0000000000000001 R12: 0000000000000002 localhost kernel: R13: ffff9e7ead15d600 R14: 0000000000000000 R15: ffff9e7ead15d698 localhost kernel: FS: 0000152a3d111700(0000) GS:ffff9e855ee80000(0000) knlGS:0000000000000000 localhost kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 localhost kernel: CR2: 0000152938000010 CR3: 000000044d7a4000 CR4: 00000000003506e0 localhost kernel: Call Trace: localhost kernel: _raw_spin_lock_irqsave+0x30/0x40 localhost kernel: remove_wait_queue+0x12/0x50 localhost kernel: kfd_wait_on_events+0x1b6/0x490 [hydcu] localhost kernel: ? ftrace_graph_caller+0xa0/0xa0 localhost kernel: kfd_ioctl+0x38c/0x4a0 [hydcu] localhost kernel: ? kfd_ioctl_set_trap_handler+0x70/0x70 [hydcu] localhost kernel: ? kfd_ioctl_create_queue+0x5a0/0x5a0 [hydcu] localhost kernel: ? ftrace_graph_caller+0xa0/0xa0 localhost kernel: __x64_sys_ioctl+0x8e/0xd0 localhost kernel: ? syscall_trace_enter.isra.18+0x143/0x1b0 localhost kernel: do_syscall_64+0x33/0x80 localhost kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 localhost kernel: RIP: 0033:0x152a4dff68d7 Allocate the structure with kcalloc, and remove redundant 0-initialization and a redundant loop condition check. CVE-2023-53090 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: update s_journal_inum if it changes after journal replay When mounting a crafted ext4 image, s_journal_inum may change after journal replay, which is obviously unreasonable because we have successfully loaded and replayed the journal through the old s_journal_inum. And the new s_journal_inum bypasses some of the checks in ext4_get_journal(), which may trigger a null pointer dereference problem. So if s_journal_inum changes after the journal replay, we ignore the change, and rewrite the current journal_inum to the superblock. CVE-2023-53091 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: interconnect: exynos: fix node leak in probe PM QoS error path Make sure to add the newly allocated interconnect node to the provider before adding the PM QoS request so that the node is freed on errors. CVE-2023-53092 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: tracing: Do not let histogram values have some modifiers Histogram values can not be strings, stacktraces, graphs, symbols, syscalls, or grouped in buckets or log. Give an error if a value is set to do so. Note, the histogram code was not prepared to handle these modifiers for histograms and caused a bug. Mark Rutland reported: # echo 'p:copy_to_user __arch_copy_to_user n=$arg2' >> /sys/kernel/tracing/kprobe_events # echo 'hist:keys=n:vals=hitcount.buckets=8:sort=hitcount' > /sys/kernel/tracing/events/kprobes/copy_to_user/trigger # cat /sys/kernel/tracing/events/kprobes/copy_to_user/hist [ 143.694628] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 143.695190] Mem abort info: [ 143.695362] ESR = 0x0000000096000004 [ 143.695604] EC = 0x25: DABT (current EL), IL = 32 bits [ 143.695889] SET = 0, FnV = 0 [ 143.696077] EA = 0, S1PTW = 0 [ 143.696302] FSC = 0x04: level 0 translation fault [ 143.702381] Data abort info: [ 143.702614] ISV = 0, ISS = 0x00000004 [ 143.702832] CM = 0, WnR = 0 [ 143.703087] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000448f9000 [ 143.703407] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 143.704137] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 143.704714] Modules linked in: [ 143.705273] CPU: 0 PID: 133 Comm: cat Not tainted 6.2.0-00003-g6fc512c10a7c #3 [ 143.706138] Hardware name: linux,dummy-virt (DT) [ 143.706723] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 143.707120] pc : hist_field_name.part.0+0x14/0x140 [ 143.707504] lr : hist_field_name.part.0+0x104/0x140 [ 143.707774] sp : ffff800008333a30 [ 143.707952] x29: ffff800008333a30 x28: 0000000000000001 x27: 0000000000400cc0 [ 143.708429] x26: ffffd7a653b20260 x25: 0000000000000000 x24: ffff10d303ee5800 [ 143.708776] x23: ffffd7a6539b27b0 x22: ffff10d303fb8c00 x21: 0000000000000001 [ 143.709127] x20: ffff10d303ec2000 x19: 0000000000000000 x18: 0000000000000000 [ 143.709478] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 143.709824] x14: 0000000000000000 x13: 203a6f666e692072 x12: 6567676972742023 [ 143.710179] x11: 0a230a6d6172676f x10: 000000000000002c x9 : ffffd7a6521e018c [ 143.710584] x8 : 000000000000002c x7 : 7f7f7f7f7f7f7f7f x6 : 000000000000002c [ 143.710915] x5 : ffff10d303b0103e x4 : ffffd7a653b20261 x3 : 000000000000003d [ 143.711239] x2 : 0000000000020001 x1 : 0000000000000001 x0 : 0000000000000000 [ 143.711746] Call trace: [ 143.712115] hist_field_name.part.0+0x14/0x140 [ 143.712642] hist_field_name.part.0+0x104/0x140 [ 143.712925] hist_field_print+0x28/0x140 [ 143.713125] event_hist_trigger_print+0x174/0x4d0 [ 143.713348] hist_show+0xf8/0x980 [ 143.713521] seq_read_iter+0x1bc/0x4b0 [ 143.713711] seq_read+0x8c/0xc4 [ 143.713876] vfs_read+0xc8/0x2a4 [ 143.714043] ksys_read+0x70/0xfc [ 143.714218] __arm64_sys_read+0x24/0x30 [ 143.714400] invoke_syscall+0x50/0x120 [ 143.714587] el0_svc_common.constprop.0+0x4c/0x100 [ 143.714807] do_el0_svc+0x44/0xd0 [ 143.714970] el0_svc+0x2c/0x84 [ 143.715134] el0t_64_sync_handler+0xbc/0x140 [ 143.715334] el0t_64_sync+0x190/0x194 [ 143.715742] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (f9400000) [ 143.716510] ---[ end trace 0000000000000000 ]--- Segmentation fault CVE-2023-53093 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: interconnect: fix mem leak when freeing nodes The node link array is allocated when adding links to a node but is not deallocated when nodes are destroyed. CVE-2023-53096 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: rc: gpio-ir-recv: add remove function In case runtime PM is enabled, do runtime PM clean up to remove cpu latency qos request, otherwise driver removal may have below kernel dump: [ 19.463299] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000048 [ 19.472161] Mem abort info: [ 19.474985] ESR = 0x0000000096000004 [ 19.478754] EC = 0x25: DABT (current EL), IL = 32 bits [ 19.484081] SET = 0, FnV = 0 [ 19.487149] EA = 0, S1PTW = 0 [ 19.490361] FSC = 0x04: level 0 translation fault [ 19.495256] Data abort info: [ 19.498149] ISV = 0, ISS = 0x00000004 [ 19.501997] CM = 0, WnR = 0 [ 19.504977] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000049f81000 [ 19.511432] [0000000000000048] pgd=0000000000000000, p4d=0000000000000000 [ 19.518245] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 19.524520] Modules linked in: gpio_ir_recv(+) rc_core [last unloaded: rc_core] [ 19.531845] CPU: 0 PID: 445 Comm: insmod Not tainted 6.2.0-rc1-00028-g2c397a46d47c #72 [ 19.531854] Hardware name: FSL i.MX8MM EVK board (DT) [ 19.531859] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 19.551777] pc : cpu_latency_qos_remove_request+0x20/0x110 [ 19.557277] lr : gpio_ir_recv_runtime_suspend+0x18/0x30 [gpio_ir_recv] [ 19.557294] sp : ffff800008ce3740 [ 19.557297] x29: ffff800008ce3740 x28: 0000000000000000 x27: ffff800008ce3d50 [ 19.574270] x26: ffffc7e3e9cea100 x25: 00000000000f4240 x24: ffffc7e3f9ef0e30 [ 19.574284] x23: 0000000000000000 x22: ffff0061803820f4 x21: 0000000000000008 [ 19.574296] x20: ffffc7e3fa75df30 x19: 0000000000000020 x18: ffffffffffffffff [ 19.588570] x17: 0000000000000000 x16: ffffc7e3f9efab70 x15: ffffffffffffffff [ 19.595712] x14: ffff800008ce37b8 x13: ffff800008ce37aa x12: 0000000000000001 [ 19.602853] x11: 0000000000000001 x10: ffffcbe3ec0dff87 x9 : 0000000000000008 [ 19.609991] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 000000000f0bfe9f [ 19.624261] x5 : 00ffffffffffffff x4 : 0025ab8e00000000 x3 : ffff006180382010 [ 19.631405] x2 : ffffc7e3e9ce8030 x1 : ffffc7e3fc3eb810 x0 : 0000000000000020 [ 19.638548] Call trace: [ 19.640995] cpu_latency_qos_remove_request+0x20/0x110 [ 19.646142] gpio_ir_recv_runtime_suspend+0x18/0x30 [gpio_ir_recv] [ 19.652339] pm_generic_runtime_suspend+0x2c/0x44 [ 19.657055] __rpm_callback+0x48/0x1dc [ 19.660807] rpm_callback+0x6c/0x80 [ 19.664301] rpm_suspend+0x10c/0x640 [ 19.667880] rpm_idle+0x250/0x2d0 [ 19.671198] update_autosuspend+0x38/0xe0 [ 19.675213] pm_runtime_set_autosuspend_delay+0x40/0x60 [ 19.680442] gpio_ir_recv_probe+0x1b4/0x21c [gpio_ir_recv] [ 19.685941] platform_probe+0x68/0xc0 [ 19.689610] really_probe+0xc0/0x3dc [ 19.693189] __driver_probe_device+0x7c/0x190 [ 19.697550] driver_probe_device+0x3c/0x110 [ 19.701739] __driver_attach+0xf4/0x200 [ 19.705578] bus_for_each_dev+0x70/0xd0 [ 19.709417] driver_attach+0x24/0x30 [ 19.712998] bus_add_driver+0x17c/0x240 [ 19.716834] driver_register+0x78/0x130 [ 19.720676] __platform_driver_register+0x28/0x34 [ 19.725386] gpio_ir_recv_driver_init+0x20/0x1000 [gpio_ir_recv] [ 19.731404] do_one_initcall+0x44/0x2ac [ 19.735243] do_init_module+0x48/0x1d0 [ 19.739003] load_module+0x19fc/0x2034 [ 19.742759] __do_sys_finit_module+0xac/0x12c [ 19.747124] __arm64_sys_finit_module+0x20/0x30 [ 19.751664] invoke_syscall+0x48/0x114 [ 19.755420] el0_svc_common.constprop.0+0xcc/0xec [ 19.760132] do_el0_svc+0x38/0xb0 [ 19.763456] el0_svc+0x2c/0x84 [ 19.766516] el0t_64_sync_handler+0xf4/0x120 [ 19.770789] el0t_64_sync+0x190/0x194 [ 19.774460] Code: 910003fd a90153f3 aa0003f3 91204021 (f9401400) [ 19.780556] ---[ end trace 0000000000000000 ]--- CVE-2023-53098 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: firmware: xilinx: don't make a sleepable memory allocation from an atomic context The following issue was discovered using lockdep: [ 6.691371] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:209 [ 6.694602] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 1, name: swapper/0 [ 6.702431] 2 locks held by swapper/0/1: [ 6.706300] #0: ffffff8800f6f188 (&dev->mutex){....}-{3:3}, at: __device_driver_lock+0x4c/0x90 [ 6.714900] #1: ffffffc009a2abb8 (enable_lock){....}-{2:2}, at: clk_enable_lock+0x4c/0x140 [ 6.723156] irq event stamp: 304030 [ 6.726596] hardirqs last enabled at (304029): [<ffffffc008d17ee0>] _raw_spin_unlock_irqrestore+0xc0/0xd0 [ 6.736142] hardirqs last disabled at (304030): [<ffffffc00876bc5c>] clk_enable_lock+0xfc/0x140 [ 6.744742] softirqs last enabled at (303958): [<ffffffc0080904f0>] _stext+0x4f0/0x894 [ 6.752655] softirqs last disabled at (303951): [<ffffffc0080e53b8>] irq_exit+0x238/0x280 [ 6.760744] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G U 5.15.36 #2 [ 6.768048] Hardware name: xlnx,zynqmp (DT) [ 6.772179] Call trace: [ 6.774584] dump_backtrace+0x0/0x300 [ 6.778197] show_stack+0x18/0x30 [ 6.781465] dump_stack_lvl+0xb8/0xec [ 6.785077] dump_stack+0x1c/0x38 [ 6.788345] ___might_sleep+0x1a8/0x2a0 [ 6.792129] __might_sleep+0x6c/0xd0 [ 6.795655] kmem_cache_alloc_trace+0x270/0x3d0 [ 6.800127] do_feature_check_call+0x100/0x220 [ 6.804513] zynqmp_pm_invoke_fn+0x8c/0xb0 [ 6.808555] zynqmp_pm_clock_getstate+0x90/0xe0 [ 6.813027] zynqmp_pll_is_enabled+0x8c/0x120 [ 6.817327] zynqmp_pll_enable+0x38/0xc0 [ 6.821197] clk_core_enable+0x144/0x400 [ 6.825067] clk_core_enable+0xd4/0x400 [ 6.828851] clk_core_enable+0xd4/0x400 [ 6.832635] clk_core_enable+0xd4/0x400 [ 6.836419] clk_core_enable+0xd4/0x400 [ 6.840203] clk_core_enable+0xd4/0x400 [ 6.843987] clk_core_enable+0xd4/0x400 [ 6.847771] clk_core_enable+0xd4/0x400 [ 6.851555] clk_core_enable_lock+0x24/0x50 [ 6.855683] clk_enable+0x24/0x40 [ 6.858952] fclk_probe+0x84/0xf0 [ 6.862220] platform_probe+0x8c/0x110 [ 6.865918] really_probe+0x110/0x5f0 [ 6.869530] __driver_probe_device+0xcc/0x210 [ 6.873830] driver_probe_device+0x64/0x140 [ 6.877958] __driver_attach+0x114/0x1f0 [ 6.881828] bus_for_each_dev+0xe8/0x160 [ 6.885698] driver_attach+0x34/0x50 [ 6.889224] bus_add_driver+0x228/0x300 [ 6.893008] driver_register+0xc0/0x1e0 [ 6.896792] __platform_driver_register+0x44/0x60 [ 6.901436] fclk_driver_init+0x1c/0x28 [ 6.905220] do_one_initcall+0x104/0x590 [ 6.909091] kernel_init_freeable+0x254/0x2bc [ 6.913390] kernel_init+0x24/0x130 [ 6.916831] ret_from_fork+0x10/0x20 Fix it by passing the GFP_ATOMIC gfp flag for the corresponding memory allocation. CVE-2023-53099 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: fix WARNING in ext4_update_inline_data Syzbot found the following issue: EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none. fscrypt: AES-256-CTS-CBC using implementation "cts-cbc-aes-aesni" fscrypt: AES-256-XTS using implementation "xts-aes-aesni" ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5071 at mm/page_alloc.c:5525 __alloc_pages+0x30a/0x560 mm/page_alloc.c:5525 Modules linked in: CPU: 1 PID: 5071 Comm: syz-executor263 Not tainted 6.2.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 RIP: 0010:__alloc_pages+0x30a/0x560 mm/page_alloc.c:5525 RSP: 0018:ffffc90003c2f1c0 EFLAGS: 00010246 RAX: ffffc90003c2f220 RBX: 0000000000000014 RCX: 0000000000000000 RDX: 0000000000000028 RSI: 0000000000000000 RDI: ffffc90003c2f248 RBP: ffffc90003c2f2d8 R08: dffffc0000000000 R09: ffffc90003c2f220 R10: fffff52000785e49 R11: 1ffff92000785e44 R12: 0000000000040d40 R13: 1ffff92000785e40 R14: dffffc0000000000 R15: 1ffff92000785e3c FS: 0000555556c0d300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f95d5e04138 CR3: 00000000793aa000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __alloc_pages_node include/linux/gfp.h:237 [inline] alloc_pages_node include/linux/gfp.h:260 [inline] __kmalloc_large_node+0x95/0x1e0 mm/slab_common.c:1113 __do_kmalloc_node mm/slab_common.c:956 [inline] __kmalloc+0xfe/0x190 mm/slab_common.c:981 kmalloc include/linux/slab.h:584 [inline] kzalloc include/linux/slab.h:720 [inline] ext4_update_inline_data+0x236/0x6b0 fs/ext4/inline.c:346 ext4_update_inline_dir fs/ext4/inline.c:1115 [inline] ext4_try_add_inline_entry+0x328/0x990 fs/ext4/inline.c:1307 ext4_add_entry+0x5a4/0xeb0 fs/ext4/namei.c:2385 ext4_add_nondir+0x96/0x260 fs/ext4/namei.c:2772 ext4_create+0x36c/0x560 fs/ext4/namei.c:2817 lookup_open fs/namei.c:3413 [inline] open_last_lookups fs/namei.c:3481 [inline] path_openat+0x12ac/0x2dd0 fs/namei.c:3711 do_filp_open+0x264/0x4f0 fs/namei.c:3741 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline] __do_sys_openat fs/open.c:1342 [inline] __se_sys_openat fs/open.c:1337 [inline] __x64_sys_openat+0x243/0x290 fs/open.c:1337 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Above issue happens as follows: ext4_iget ext4_find_inline_data_nolock ->i_inline_off=164 i_inline_size=60 ext4_try_add_inline_entry __ext4_mark_inode_dirty ext4_expand_extra_isize_ea ->i_extra_isize=32 s_want_extra_isize=44 ext4_xattr_shift_entries ->after shift i_inline_off is incorrect, actually is change to 176 ext4_try_add_inline_entry ext4_update_inline_dir get_max_inline_xattr_value_size if (EXT4_I(inode)->i_inline_off) entry = (struct ext4_xattr_entry *)((void *)raw_inode + EXT4_I(inode)->i_inline_off); free += EXT4_XATTR_SIZE(le32_to_cpu(entry->e_value_size)); ->As entry is incorrect, then 'free' may be negative ext4_update_inline_data value = kzalloc(len, GFP_NOFS); -> len is unsigned int, maybe very large, then trigger warning when 'kzalloc()' To resolve the above issue we need to update 'i_inline_off' after 'ext4_xattr_shift_entries()'. We do not need to set EXT4_STATE_MAY_INLINE_DATA flag here, since ext4_mark_inode_dirty() already sets this flag if needed. Setting EXT4_STATE_MAY_INLINE_DATA when it is needed may trigger a BUG_ON in ext4_writepages(). CVE-2023-53100 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: zero i_disksize when initializing the bootloader inode If the boot loader inode has never been used before, the EXT4_IOC_SWAP_BOOT inode will initialize it, including setting the i_size to 0. However, if the "never before used" boot loader has a non-zero i_size, then i_disksize will be non-zero, and the inconsistency between i_size and i_disksize can trigger a kernel warning: WARNING: CPU: 0 PID: 2580 at fs/ext4/file.c:319 CPU: 0 PID: 2580 Comm: bb Not tainted 6.3.0-rc1-00004-g703695902cfa RIP: 0010:ext4_file_write_iter+0xbc7/0xd10 Call Trace: vfs_write+0x3b1/0x5c0 ksys_write+0x77/0x160 __x64_sys_write+0x22/0x30 do_syscall_64+0x39/0x80 Reproducer: 1. create corrupted image and mount it: mke2fs -t ext4 /tmp/foo.img 200 debugfs -wR "sif <5> size 25700" /tmp/foo.img mount -t ext4 /tmp/foo.img /mnt cd /mnt echo 123 > file 2. Run the reproducer program: posix_memalign(&buf, 1024, 1024) fd = open("file", O_RDWR | O_DIRECT); ioctl(fd, EXT4_IOC_SWAP_BOOT); write(fd, buf, 1024); Fix this by setting i_disksize as well as i_size to zero when initiaizing the boot loader inode. CVE-2023-53101 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/iucv: Fix size of interrupt data iucv_irq_data needs to be 4 bytes larger. These bytes are not used by the iucv module, but written by the z/VM hypervisor in case a CPU is deconfigured. Reported as: BUG dma-kmalloc-64 (Not tainted): kmalloc Redzone overwritten ----------------------------------------------------------------------------- 0x0000000000400564-0x0000000000400567 @offset=1380. First byte 0x80 instead of 0xcc Allocated in iucv_cpu_prepare+0x44/0xd0 age=167839 cpu=2 pid=1 __kmem_cache_alloc_node+0x166/0x450 kmalloc_node_trace+0x3a/0x70 iucv_cpu_prepare+0x44/0xd0 cpuhp_invoke_callback+0x156/0x2f0 cpuhp_issue_call+0xf0/0x298 __cpuhp_setup_state_cpuslocked+0x136/0x338 __cpuhp_setup_state+0xf4/0x288 iucv_init+0xf4/0x280 do_one_initcall+0x78/0x390 do_initcalls+0x11a/0x140 kernel_init_freeable+0x25e/0x2a0 kernel_init+0x2e/0x170 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 Freed in iucv_init+0x92/0x280 age=167839 cpu=2 pid=1 __kmem_cache_free+0x308/0x358 iucv_init+0x92/0x280 do_one_initcall+0x78/0x390 do_initcalls+0x11a/0x140 kernel_init_freeable+0x25e/0x2a0 kernel_init+0x2e/0x170 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 Slab 0x0000037200010000 objects=32 used=30 fp=0x0000000000400640 flags=0x1ffff00000010200(slab|head|node=0|zone=0| Object 0x0000000000400540 @offset=1344 fp=0x0000000000000000 Redzone 0000000000400500: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 0000000000400510: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 0000000000400520: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 0000000000400530: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Object 0000000000400540: 00 01 00 03 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object 0000000000400550: f3 86 81 f2 f4 82 f8 82 f0 f0 f0 f0 f0 f0 f0 f2 ................ Object 0000000000400560: 00 00 00 00 80 00 00 00 cc cc cc cc cc cc cc cc ................ Object 0000000000400570: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 0000000000400580: cc cc cc cc cc cc cc cc ........ Padding 00000000004005d4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ Padding 00000000004005e4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ Padding 00000000004005f4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ CPU: 6 PID: 121030 Comm: 116-pai-crypto. Not tainted 6.3.0-20230221.rc0.git4.99b8246b2d71.300.fc37.s390x+debug #1 Hardware name: IBM 3931 A01 704 (z/VM 7.3.0) Call Trace: [<000000032aa034ec>] dump_stack_lvl+0xac/0x100 [<0000000329f5a6cc>] check_bytes_and_report+0x104/0x140 [<0000000329f5aa78>] check_object+0x370/0x3c0 [<0000000329f5ede6>] free_debug_processing+0x15e/0x348 [<0000000329f5f06a>] free_to_partial_list+0x9a/0x2f0 [<0000000329f5f4a4>] __slab_free+0x1e4/0x3a8 [<0000000329f61768>] __kmem_cache_free+0x308/0x358 [<000000032a91465c>] iucv_cpu_dead+0x6c/0x88 [<0000000329c2fc66>] cpuhp_invoke_callback+0x156/0x2f0 [<000000032aa062da>] _cpu_down.constprop.0+0x22a/0x5e0 [<0000000329c3243e>] cpu_device_down+0x4e/0x78 [<000000032a61dee0>] device_offline+0xc8/0x118 [<000000032a61e048>] online_store+0x60/0xe0 [<000000032a08b6b0>] kernfs_fop_write_iter+0x150/0x1e8 [<0000000329fab65c>] vfs_write+0x174/0x360 [<0000000329fab9fc>] ksys_write+0x74/0x100 [<000000032aa03a5a>] __do_syscall+0x1da/0x208 [<000000032aa177b2>] system_call+0x82/0xb0 INFO: lockdep is turned off. FIX dma-kmalloc-64: Restoring kmalloc Redzone 0x0000000000400564-0x0000000000400567=0xcc FIX dma-kmalloc-64: Object at 0x0000000000400540 not freed CVE-2023-53108 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: loop: Fix use-after-free issues do_req_filebacked() calls blk_mq_complete_request() synchronously or asynchronously when using asynchronous I/O unless memory allocation fails. Hence, modify loop_handle_cmd() such that it does not dereference 'cmd' nor 'rq' after do_req_filebacked() finished unless we are sure that the request has not yet been completed. This patch fixes the following kernel crash: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000054 Call trace: css_put.42938+0x1c/0x1ac loop_process_work+0xc8c/0xfd4 loop_rootcg_workfn+0x24/0x34 process_one_work+0x244/0x558 worker_thread+0x400/0x8fc kthread+0x16c/0x1e0 ret_from_fork+0x10/0x20 CVE-2023-53111 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: i40e: Fix kernel crash during reboot when adapter is in recovery mode If the driver detects during probe that firmware is in recovery mode then i40e_init_recovery_mode() is called and the rest of probe function is skipped including pci_set_drvdata(). Subsequent i40e_shutdown() called during shutdown/reboot dereferences NULL pointer as pci_get_drvdata() returns NULL. To fix call pci_set_drvdata() also during entering to recovery mode. Reproducer: 1) Lets have i40e NIC with firmware in recovery mode 2) Run reboot Result: [ 139.084698] i40e: Intel(R) Ethernet Connection XL710 Network Driver [ 139.090959] i40e: Copyright (c) 2013 - 2019 Intel Corporation. [ 139.108438] i40e 0000:02:00.0: Firmware recovery mode detected. Limiting functionality. [ 139.116439] i40e 0000:02:00.0: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for details on firmware recovery mode. [ 139.129499] i40e 0000:02:00.0: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a] [ 139.215932] i40e 0000:02:00.0 enp2s0f0: renamed from eth0 [ 139.223292] i40e 0000:02:00.1: Firmware recovery mode detected. Limiting functionality. [ 139.231292] i40e 0000:02:00.1: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for details on firmware recovery mode. [ 139.244406] i40e 0000:02:00.1: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a] [ 139.329209] i40e 0000:02:00.1 enp2s0f1: renamed from eth0 ... [ 156.311376] BUG: kernel NULL pointer dereference, address: 00000000000006c2 [ 156.318330] #PF: supervisor write access in kernel mode [ 156.323546] #PF: error_code(0x0002) - not-present page [ 156.328679] PGD 0 P4D 0 [ 156.331210] Oops: 0002 [#1] PREEMPT SMP NOPTI [ 156.335567] CPU: 26 PID: 15119 Comm: reboot Tainted: G E 6.2.0+ #1 [ 156.343126] Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.4 04/13/2022 [ 156.353369] RIP: 0010:i40e_shutdown+0x15/0x130 [i40e] [ 156.358430] Code: c1 fc ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 55 48 89 fd 53 48 8b 9f 48 01 00 00 <f0> 80 8b c2 06 00 00 04 f0 80 8b c0 06 00 00 08 48 8d bb 08 08 00 [ 156.377168] RSP: 0018:ffffb223c8447d90 EFLAGS: 00010282 [ 156.382384] RAX: ffffffffc073ee70 RBX: 0000000000000000 RCX: 0000000000000001 [ 156.389510] RDX: 0000000080000001 RSI: 0000000000000246 RDI: ffff95db49988000 [ 156.396634] RBP: ffff95db49988000 R08: ffffffffffffffff R09: ffffffff8bd17d40 [ 156.403759] R10: 0000000000000001 R11: ffffffff8a5e3d28 R12: ffff95db49988000 [ 156.410882] R13: ffffffff89a6fe17 R14: ffff95db49988150 R15: 0000000000000000 [ 156.418007] FS: 00007fe7c0cc3980(0000) GS:ffff95ea8ee80000(0000) knlGS:0000000000000000 [ 156.426083] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 156.431819] CR2: 00000000000006c2 CR3: 00000003092fc005 CR4: 0000000000770ee0 [ 156.438944] PKRU: 55555554 [ 156.441647] Call Trace: [ 156.444096] <TASK> [ 156.446199] pci_device_shutdown+0x38/0x60 [ 156.450297] device_shutdown+0x163/0x210 [ 156.454215] kernel_restart+0x12/0x70 [ 156.457872] __do_sys_reboot+0x1ab/0x230 [ 156.461789] ? vfs_writev+0xa6/0x1a0 [ 156.465362] ? __pfx_file_free_rcu+0x10/0x10 [ 156.469635] ? __call_rcu_common.constprop.85+0x109/0x5a0 [ 156.475034] do_syscall_64+0x3e/0x90 [ 156.478611] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 156.483658] RIP: 0033:0x7fe7bff37ab7 CVE-2023-53114 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: nvmet: avoid potential UAF in nvmet_req_complete() An nvme target ->queue_response() operation implementation may free the request passed as argument. Such implementation potentially could result in a use after free of the request pointer when percpu_ref_put() is called in nvmet_req_complete(). Avoid such problem by using a local variable to save the sq pointer before calling __nvmet_req_complete(), thus avoiding dereferencing the req pointer after that function call. CVE-2023-53116 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix a procfs host directory removal regression scsi_proc_hostdir_rm() decreases a reference counter and hence must only be called once per host that is removed. This change does not require a scsi_add_host_with_dma() change since scsi_add_host_with_dma() will return 0 (success) if scsi_proc_host_add() is called. CVE-2023-53118 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: initialize struct pn533_out_arg properly struct pn533_out_arg used as a temporary context for out_urb is not initialized properly. Its uninitialized 'phy' field can be dereferenced in error cases inside pn533_out_complete() callback function. It causes the following failure: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.2.0-rc3-next-20230110-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 RIP: 0010:pn533_out_complete.cold+0x15/0x44 drivers/nfc/pn533/usb.c:441 Call Trace: <IRQ> __usb_hcd_giveback_urb+0x2b6/0x5c0 drivers/usb/core/hcd.c:1671 usb_hcd_giveback_urb+0x384/0x430 drivers/usb/core/hcd.c:1754 dummy_timer+0x1203/0x32d0 drivers/usb/gadget/udc/dummy_hcd.c:1988 call_timer_fn+0x1da/0x800 kernel/time/timer.c:1700 expire_timers+0x234/0x330 kernel/time/timer.c:1751 __run_timers kernel/time/timer.c:2022 [inline] __run_timers kernel/time/timer.c:1995 [inline] run_timer_softirq+0x326/0x910 kernel/time/timer.c:2035 __do_softirq+0x1fb/0xaf6 kernel/softirq.c:571 invoke_softirq kernel/softirq.c:445 [inline] __irq_exit_rcu+0x123/0x180 kernel/softirq.c:650 irq_exit_rcu+0x9/0x20 kernel/softirq.c:662 sysvec_apic_timer_interrupt+0x97/0xc0 arch/x86/kernel/apic/apic.c:1107 Initialize the field with the pn533_usb_phy currently used. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. CVE-2023-53119 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: PCI: s390: Fix use-after-free of PCI resources with per-function hotplug On s390 PCI functions may be hotplugged individually even when they belong to a multi-function device. In particular on an SR-IOV device VFs may be removed and later re-added. In commit a50297cf8235 ("s390/pci: separate zbus creation from scanning") it was missed however that struct pci_bus and struct zpci_bus's resource list retained a reference to the PCI functions MMIO resources even though those resources are released and freed on hot-unplug. These stale resources may subsequently be claimed when the PCI function re-appears resulting in use-after-free. One idea of fixing this use-after-free in s390 specific code that was investigated was to simply keep resources around from the moment a PCI function first appeared until the whole virtual PCI bus created for a multi-function device disappears. The problem with this however is that due to the requirement of artificial MMIO addreesses (address cookies) extra logic is then needed to keep the address cookies compatible on re-plug. At the same time the MMIO resources semantically belong to the PCI function so tying their lifecycle to the function seems more logical. Instead a simpler approach is to remove the resources of an individually hot-unplugged PCI function from the PCI bus's resource list while keeping the resources of other PCI functions on the PCI bus untouched. This is done by introducing pci_bus_remove_resource() to remove an individual resource. Similarly the resource also needs to be removed from the struct zpci_bus's resource list. It turns out however, that there is really no need to add the MMIO resources to the struct zpci_bus's resource list at all and instead we can simply use the zpci_bar_struct's resource pointer directly. CVE-2023-53123 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix NULL pointer access in mpt3sas_transport_port_add() Port is allocated by sas_port_alloc_num() and rphy is allocated by either sas_end_device_alloc() or sas_expander_alloc(), all of which may return NULL. So we need to check the rphy to avoid possible NULL pointer access. If sas_rphy_add() returned with failure, rphy is set to NULL. We would access the rphy in the following lines which would also result NULL pointer access. CVE-2023-53124 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: usb: smsc75xx: Limit packet length to skb->len Packet length retrieved from skb data may be larger than the actual socket buffer length (up to 9026 bytes). In such case the cloned skb passed up the network stack will leak kernel memory contents. CVE-2023-53125 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix a server shutdown leak Fix a race where kthread_stop() may prevent the threadfn from ever getting called. If that happens the svc_rqst will not be cleaned up. CVE-2023-53131 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Avoid order-5 memory allocation for TPA data The driver needs to keep track of all the possible concurrent TPA (GRO/LRO) completions on the aggregation ring. On P5 chips, the maximum number of concurrent TPA is 256 and the amount of memory we allocate is order-5 on systems using 4K pages. Memory allocation failure has been reported: NetworkManager: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0-1 CPU: 15 PID: 2995 Comm: NetworkManager Kdump: loaded Not tainted 5.10.156 #1 Hardware name: Dell Inc. PowerEdge R660/0M1CC5, BIOS 0.2.25 08/12/2022 Call Trace: dump_stack+0x57/0x6e warn_alloc.cold.120+0x7b/0xdd ? _cond_resched+0x15/0x30 ? __alloc_pages_direct_compact+0x15f/0x170 __alloc_pages_slowpath.constprop.108+0xc58/0xc70 __alloc_pages_nodemask+0x2d0/0x300 kmalloc_order+0x24/0xe0 kmalloc_order_trace+0x19/0x80 bnxt_alloc_mem+0x1150/0x15c0 [bnxt_en] ? bnxt_get_func_stat_ctxs+0x13/0x60 [bnxt_en] __bnxt_open_nic+0x12e/0x780 [bnxt_en] bnxt_open+0x10b/0x240 [bnxt_en] __dev_open+0xe9/0x180 __dev_change_flags+0x1af/0x220 dev_change_flags+0x21/0x60 do_setlink+0x35c/0x1100 Instead of allocating this big chunk of memory and dividing it up for the concurrent TPA instances, allocate each small chunk separately for each TPA instance. This will reduce it to order-0 allocations. CVE-2023-53134 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. CVE-2023-53137 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfc: fdp: add null check of devm_kmalloc_array in fdp_nci_i2c_read_device_properties devm_kmalloc_array may fails, *fw_vsc_cfg might be null and cause out-of-bounds write in device_property_read_u8_array later. CVE-2023-53139 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: core: Remove the /proc/scsi/${proc_name} directory earlier Remove the /proc/scsi/${proc_name} directory earlier to fix a race condition between unloading and reloading kernel modules. This fixes a bug introduced in 2009 by commit 77c019768f06 ("[SCSI] fix /proc memory leak in the SCSI core"). Fix the following kernel warning: proc_dir_entry 'scsi/scsi_debug' already registered WARNING: CPU: 19 PID: 27986 at fs/proc/generic.c:376 proc_register+0x27d/0x2e0 Call Trace: proc_mkdir+0xb5/0xe0 scsi_proc_hostdir_add+0xb5/0x170 scsi_host_alloc+0x683/0x6c0 sdebug_driver_probe+0x6b/0x2d0 [scsi_debug] really_probe+0x159/0x540 __driver_probe_device+0xdc/0x230 driver_probe_device+0x4f/0x120 __device_attach_driver+0xef/0x180 bus_for_each_drv+0xe5/0x130 __device_attach+0x127/0x290 device_initial_probe+0x17/0x20 bus_probe_device+0x110/0x130 device_add+0x673/0xc80 device_register+0x1e/0x30 sdebug_add_host_helper+0x1a7/0x3b0 [scsi_debug] scsi_debug_init+0x64f/0x1000 [scsi_debug] do_one_initcall+0xd7/0x470 do_init_module+0xe7/0x330 load_module+0x122a/0x12c0 __do_sys_finit_module+0x124/0x1a0 __x64_sys_finit_module+0x46/0x50 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 CVE-2023-53140 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ice: copy last block omitted in ice_get_module_eeprom() ice_get_module_eeprom() is broken since commit e9c9692c8a81 ("ice: Reimplement module reads used by ethtool") In this refactor, ice_get_module_eeprom() reads the eeprom in blocks of size 8. But the condition that should protect the buffer overflow ignores the last block. The last block always contains zeros. Bug uncovered by ethtool upstream commit 9538f384b535 ("netlink: eeprom: Defer page requests to individual parsers") After this commit, ethtool reads a block with length = 1; to read the SFF-8024 identifier value. unpatched driver: $ ethtool -m enp65s0f0np0 offset 0x90 length 8 Offset Values ------ ------ 0x0090: 00 00 00 00 00 00 00 00 $ ethtool -m enp65s0f0np0 offset 0x90 length 12 Offset Values ------ ------ 0x0090: 00 00 01 a0 4d 65 6c 6c 00 00 00 00 $ $ ethtool -m enp65s0f0np0 Offset Values ------ ------ 0x0000: 11 06 06 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 08 00 0x0070: 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 patched driver: $ ethtool -m enp65s0f0np0 offset 0x90 length 8 Offset Values ------ ------ 0x0090: 00 00 01 a0 4d 65 6c 6c $ ethtool -m enp65s0f0np0 offset 0x90 length 12 Offset Values ------ ------ 0x0090: 00 00 01 a0 4d 65 6c 6c 61 6e 6f 78 $ ethtool -m enp65s0f0np0 Identifier : 0x11 (QSFP28) Extended identifier : 0x00 Extended identifier description : 1.5W max. Power consumption Extended identifier description : No CDR in TX, No CDR in RX Extended identifier description : High Power Class (> 3.5 W) not enabled Connector : 0x23 (No separable connector) Transceiver codes : 0x88 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Transceiver type : 40G Ethernet: 40G Base-CR4 Transceiver type : 25G Ethernet: 25G Base-CR CA-N Encoding : 0x05 (64B/66B) BR, Nominal : 25500Mbps Rate identifier : 0x00 Length (SMF,km) : 0km Length (OM3 50um) : 0m Length (OM2 50um) : 0m Length (OM1 62.5um) : 0m Length (Copper or Active cable) : 1m Transmitter technology : 0xa0 (Copper cable unequalized) Attenuation at 2.5GHz : 4db Attenuation at 5.0GHz : 5db Attenuation at 7.0GHz : 7db Attenuation at 12.9GHz : 10db ........ .... CVE-2023-53142 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: fix another off-by-one fsmap error on 1k block filesystems Apparently syzbot figured out that issuing this FSMAP call: struct fsmap_head cmd = { .fmh_count = ...; .fmh_keys = { { .fmr_device = /* ext4 dev */, .fmr_physical = 0, }, { .fmr_device = /* ext4 dev */, .fmr_physical = 0, }, }, ... }; ret = ioctl(fd, FS_IOC_GETFSMAP, &cmd); Produces this crash if the underlying filesystem is a 1k-block ext4 filesystem: kernel BUG at fs/ext4/ext4.h:3331! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 3 PID: 3227965 Comm: xfs_io Tainted: G W O 6.2.0-rc8-achx Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:ext4_mb_load_buddy_gfp+0x47c/0x570 [ext4] RSP: 0018:ffffc90007c03998 EFLAGS: 00010246 RAX: ffff888004978000 RBX: ffffc90007c03a20 RCX: ffff888041618000 RDX: 0000000000000000 RSI: 00000000000005a4 RDI: ffffffffa0c99b11 RBP: ffff888012330000 R08: ffffffffa0c2b7d0 R09: 0000000000000400 R10: ffffc90007c03950 R11: 0000000000000000 R12: 0000000000000001 R13: 00000000ffffffff R14: 0000000000000c40 R15: ffff88802678c398 FS: 00007fdf2020c880(0000) GS:ffff88807e100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffd318a5fe8 CR3: 000000007f80f001 CR4: 00000000001706e0 Call Trace: <TASK> ext4_mballoc_query_range+0x4b/0x210 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] ext4_getfsmap_datadev+0x713/0x890 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] ext4_getfsmap+0x2b7/0x330 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] ext4_ioc_getfsmap+0x153/0x2b0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] __ext4_ioctl+0x2a7/0x17e0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] __x64_sys_ioctl+0x82/0xa0 do_syscall_64+0x2b/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7fdf20558aff RSP: 002b:00007ffd318a9e30 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000000200c0 RCX: 00007fdf20558aff RDX: 00007fdf1feb2010 RSI: 00000000c0c0583b RDI: 0000000000000003 RBP: 00005625c0634be0 R08: 00005625c0634c40 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fdf1feb2010 R13: 00005625be70d994 R14: 0000000000000800 R15: 0000000000000000 For GETFSMAP calls, the caller selects a physical block device by writing its block number into fsmap_head.fmh_keys[01].fmr_device. To query mappings for a subrange of the device, the starting byte of the range is written to fsmap_head.fmh_keys[0].fmr_physical and the last byte of the range goes in fsmap_head.fmh_keys[1].fmr_physical. IOWs, to query what mappings overlap with bytes 3-14 of /dev/sda, you'd set the inputs as follows: fmh_keys[0] = { .fmr_device = major(8, 0), .fmr_physical = 3}, fmh_keys[1] = { .fmr_device = major(8, 0), .fmr_physical = 14}, Which would return you whatever is mapped in the 12 bytes starting at physical offset 3. The crash is due to insufficient range validation of keys[1] in ext4_getfsmap_datadev. On 1k-block filesystems, block 0 is not part of the filesystem, which means that s_first_data_block is nonzero. ext4_get_group_no_and_offset subtracts this quantity from the blocknr argument before cracking it into a group number and a block number within a group. IOWs, block group 0 spans blocks 1-8192 (1-based) instead of 0-8191 (0-based) like what happens with larger blocksizes. The net result of this encoding is that blocknr < s_first_data_block is not a valid input to this function. The end_fsb variable is set from the keys that are copied from userspace, which means that in the above example, its value is zero. That leads to an underflow here: blocknr = blocknr - le32_to_cpu(es->s_first_data_block); The division then operates on -1: offset = do_div(blocknr, EXT4_BLOCKS_PER_GROUP(sb)) >> EXT4_SB(sb)->s_cluster_bits; Leaving an impossibly large group number (2^32-1) in blocknr. ext4_getfsmap_check_keys checked that keys[0 ---truncated--- CVE-2023-53143 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btsdio: fix use after free bug in btsdio_remove due to race condition In btsdio_probe, the data->work is bound with btsdio_work. It will be started in btsdio_send_frame. If the btsdio_remove runs with a unfinished work, there may be a race condition that hdev is freed but used in btsdio_work. Fix it by canceling the work before do cleanup in btsdio_remove. CVE-2023-53145 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of service condition or potential code execution. CVE-2023-6270 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate A vulnerability was found in PAM. The secret information is stored in memory, where the attacker can trigger the victim program to execute by sending characters to its standard input (stdin). As this occurs, the attacker can train the branch predictor to execute an ROP chain speculatively. This flaw could result in leaked passwords, such as those found in /etc/shadow while performing authentications. CVE-2024-10041 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:apparmor-abstractions-3.0.4-150400.5.18.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:apparmor-parser-3.0.4-150400.5.18.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libapparmor1-3.0.4-150400.5.18.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:pam-1.3.0-150000.6.83.1 moderate Applications that use Wget to access a remote resource using shorthand URLs and pass arbitrary user credentials in the URL are vulnerable. In these cases attackers can enter crafted credentials which will cause Wget to access an arbitrary host. CVE-2024-10524 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:wget-1.20.3-150000.3.29.1 moderate When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances. This flaw only manifests itself if the netrc file has an entry that matches the redirect target hostname but the entry either omits just the password or omits both login and password. CVE-2024-11053 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:curl-8.0.1-150400.5.62.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libcurl4-8.0.1-150400.5.62.1 moderate The urllib.parse.urlsplit() and urlparse() functions improperly validated bracketed hosts (`[]`), allowing hosts that weren't IPv6 or IPvFuture. This behavior was not conformant to RFC 3986 and potentially enabled SSRF if a URL is processed by more than one URL parser. CVE-2024-11168 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:python3-3.6.15-150300.10.84.1 low It is possible to construct a zone such that some queries to it will generate responses containing numerous records in the Additional section. An attacker sending many such queries can cause either the authoritative server itself or an independent resolver to use disproportionate resources processing the queries. Zones will usually need to have been deliberately crafted to attack this exposure. This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.32, 9.20.0 through 9.20.4, 9.21.0 through 9.21.3, 9.11.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.32-S1. CVE-2024-11187 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:bind-utils-9.16.50-150400.5.46.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:python3-bind-9.16.50-150400.5.46.1 important A flaw in libtasn1 causes inefficient handling of specific certificate data. When processing a large number of elements in a certificate, libtasn1 takes much longer than expected, which can slow down or even crash the system. This flaw allows an attacker to send a specially crafted certificate, causing a denial of service attack. CVE-2024-12133 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libtasn1-4.13-150000.4.11.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libtasn1-6-4.13-150000.4.11.1 important A flaw was found in GnuTLS, which relies on libtasn1 for ASN.1 data processing. Due to an inefficient algorithm in libtasn1, decoding certain DER-encoded certificate data can take excessive time, leading to increased resource consumption. This flaw allows a remote attacker to send a specially crafted certificate, causing GnuTLS to become unresponsive or slow, resulting in a denial-of-service condition. CVE-2024-12243 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libgnutls30-3.7.3-150400.4.47.1 moderate Issue summary: A timing side-channel which could potentially allow recovering the private key exists in the ECDSA signature computation. Impact summary: A timing side-channel in ECDSA signature computations could allow recovering the private key by an attacker. However, measuring the timing would require either local access to the signing application or a very fast network connection with low latency. There is a timing signal of around 300 nanoseconds when the top word of the inverted ECDSA nonce value is zero. This can happen with significant probability only for some of the supported elliptic curves. In particular the NIST P-521 curve is affected. To be able to measure this leak, the attacker process must either be located in the same physical computer or must have a very fast network connection with low latency. For that reason the severity of this vulnerability is Low. The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are affected by this issue. CVE-2024-13176 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libopenssl1_1-1.1.1l-150400.7.78.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:openssl-1_1-1.1.1l-150400.7.78.1 moderate A cross-privilege Spectre v2 vulnerability allows attackers to bypass all deployed mitigations, including the recent Fine(IBT), and to leak arbitrary Linux kernel memory on Intel systems. CVE-2024-2201 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:xen-libs-4.16.7_02-150400.4.72.1 moderate jq is a command-line JSON processor. In versions up to and including 1.7.1, an integer overflow arises when assigning value using an index of 2147483647, the signed integer limit. This causes a denial of service. Commit de21386681c0df0104a99d9d09db23a9b2a78b1e contains a patch for the issue. CVE-2024-23337 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:jq-1.6-150000.3.6.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libjq1-1.6-150000.3.6.1 moderate The various Is methods (IsPrivate, IsLoopback, etc) did not work as expected for IPv4-mapped IPv6 addresses, returning false for addresses which would return true in their traditional IPv4 forms. CVE-2024-24790 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:google-osconfig-agent-20250416.02-150000.1.50.1 moderate In the Linux kernel, the following vulnerability has been resolved: mptcp: fix double-free on socket dismantle when MPTCP server accepts an incoming connection, it clones its listener socket. However, the pointer to 'inet_opt' for the new socket has the same value as the original one: as a consequence, on program exit it's possible to observe the following splat: BUG: KASAN: double-free in inet_sock_destruct+0x54f/0x8b0 Free of addr ffff888485950880 by task swapper/25/0 CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Not tainted 6.8.0-rc1+ #609 Hardware name: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF/iF, BIOS 3.0 07/26/2013 Call Trace: <IRQ> dump_stack_lvl+0x32/0x50 print_report+0xca/0x620 kasan_report_invalid_free+0x64/0x90 __kasan_slab_free+0x1aa/0x1f0 kfree+0xed/0x2e0 inet_sock_destruct+0x54f/0x8b0 __sk_destruct+0x48/0x5b0 rcu_do_batch+0x34e/0xd90 rcu_core+0x559/0xac0 __do_softirq+0x183/0x5a4 irq_exit_rcu+0x12d/0x170 sysvec_apic_timer_interrupt+0x6b/0x80 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x16/0x20 RIP: 0010:cpuidle_enter_state+0x175/0x300 Code: 30 00 0f 84 1f 01 00 00 83 e8 01 83 f8 ff 75 e5 48 83 c4 18 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc fb 45 85 ed <0f> 89 60 ff ff ff 48 c1 e5 06 48 c7 43 18 00 00 00 00 48 83 44 2b RSP: 0018:ffff888481cf7d90 EFLAGS: 00000202 RAX: 0000000000000000 RBX: ffff88887facddc8 RCX: 0000000000000000 RDX: 1ffff1110ff588b1 RSI: 0000000000000019 RDI: ffff88887fac4588 RBP: 0000000000000004 R08: 0000000000000002 R09: 0000000000043080 R10: 0009b02ea273363f R11: ffff88887fabf42b R12: ffffffff932592e0 R13: 0000000000000004 R14: 0000000000000000 R15: 00000022c880ec80 cpuidle_enter+0x4a/0xa0 do_idle+0x310/0x410 cpu_startup_entry+0x51/0x60 start_secondary+0x211/0x270 secondary_startup_64_no_verify+0x184/0x18b </TASK> Allocated by task 6853: kasan_save_stack+0x1c/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0xa6/0xb0 __kmalloc+0x1eb/0x450 cipso_v4_sock_setattr+0x96/0x360 netlbl_sock_setattr+0x132/0x1f0 selinux_netlbl_socket_post_create+0x6c/0x110 selinux_socket_post_create+0x37b/0x7f0 security_socket_post_create+0x63/0xb0 __sock_create+0x305/0x450 __sys_socket_create.part.23+0xbd/0x130 __sys_socket+0x37/0xb0 __x64_sys_socket+0x6f/0xb0 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Freed by task 6858: kasan_save_stack+0x1c/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x12c/0x1f0 kfree+0xed/0x2e0 inet_sock_destruct+0x54f/0x8b0 __sk_destruct+0x48/0x5b0 subflow_ulp_release+0x1f0/0x250 tcp_cleanup_ulp+0x6e/0x110 tcp_v4_destroy_sock+0x5a/0x3a0 inet_csk_destroy_sock+0x135/0x390 tcp_fin+0x416/0x5c0 tcp_data_queue+0x1bc8/0x4310 tcp_rcv_state_process+0x15a3/0x47b0 tcp_v4_do_rcv+0x2c1/0x990 tcp_v4_rcv+0x41fb/0x5ed0 ip_protocol_deliver_rcu+0x6d/0x9f0 ip_local_deliver_finish+0x278/0x360 ip_local_deliver+0x182/0x2c0 ip_rcv+0xb5/0x1c0 __netif_receive_skb_one_core+0x16e/0x1b0 process_backlog+0x1e3/0x650 __napi_poll+0xa6/0x500 net_rx_action+0x740/0xbb0 __do_softirq+0x183/0x5a4 The buggy address belongs to the object at ffff888485950880 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes inside of 64-byte region [ffff888485950880, ffff8884859508c0) The buggy address belongs to the physical page: page:0000000056d1e95e refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888485950700 pfn:0x485950 flags: 0x57ffffc0000800(slab|node=1|zone=2|lastcpupid=0x1fffff) page_type: 0xffffffff() raw: 0057ffffc0000800 ffff88810004c640 ffffea00121b8ac0 dead000000000006 raw: ffff888485950700 0000000000200019 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888485950780: fa fb fb ---truncated--- CVE-2024-26782 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: edia: dvbdev: fix a use-after-free In dvb_register_device, *pdvbdev is set equal to dvbdev, which is freed in several error-handling paths. However, *pdvbdev is not set to NULL after dvbdev's deallocation, causing use-after-frees in many places, for example, in the following call chain: budget_register |-> dvb_dmxdev_init |-> dvb_register_device |-> dvb_dmxdev_release |-> dvb_unregister_device |-> dvb_remove_device |-> dvb_device_put |-> kref_put When calling dvb_unregister_device, dmxdev->dvbdev (i.e. *pdvbdev in dvb_register_device) could point to memory that had been freed in dvb_register_device. Thereafter, this pointer is transferred to kref_put and triggering a use-after-free. CVE-2024-27043 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important libexpat through 2.6.1 allows an XML Entity Expansion attack when there is isolated use of external parsers (created via XML_ExternalEntityParserCreate). CVE-2024-28757 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libexpat1-2.7.1-150400.3.28.1 important Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access. CVE-2024-28956 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:xen-libs-4.16.7_02-150400.4.72.1 moderate An optional feature of PCI MSI called "Multiple Message" allows a device to use multiple consecutive interrupt vectors. Unlike for MSI-X, the setting up of these consecutive vectors needs to happen all in one go. In this handling an error path could be taken in different situations, with or without a particular lock held. This error path wrongly releases the lock even when it is not currently held. CVE-2024-31143 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:xen-libs-4.16.7_02-150400.4.72.1 important Certain PCI devices in a system might be assigned Reserved Memory Regions (specified via Reserved Memory Region Reporting, "RMRR") for Intel VT-d or Unity Mapping ranges for AMD-Vi. These are typically used for platform tasks such as legacy USB emulation. Since the precise purpose of these regions is unknown, once a device associated with such a region is active, the mappings of these regions need to remain continuouly accessible by the device. In the logic establishing these mappings, error handling was flawed, resulting in such mappings to potentially remain in place when they should have been removed again. Respective guests would then gain access to memory regions which they aren't supposed to have access to. CVE-2024-31145 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:xen-libs-4.16.7_02-150400.4.72.1 important When multiple devices share resources and one of them is to be passed through to a guest, security of the entire system and of respective guests individually cannot really be guaranteed without knowing internals of any of the involved guests. Therefore such a configuration cannot really be security-supported, yet making that explicit was so far missing. Resources the sharing of which is known to be problematic include, but are not limited to - - PCI Base Address Registers (BARs) of multiple devices mapping to the same page (4k on x86), - - INTx lines. CVE-2024-31146 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:xen-libs-4.16.7_02-150400.4.72.1 moderate A transient execution vulnerability in some AMD processors may allow an attacker to infer data from previous stores, potentially resulting in the leakage of privileged information. CVE-2024-36350 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:xen-libs-4.16.7_02-150400.4.72.1 moderate containerd is an open-source container runtime. A bug was found in containerd prior to versions 1.6.38, 1.7.27, and 2.0.4 where containers launched with a User set as a `UID:GID` larger than the maximum 32-bit signed integer can cause an overflow condition where the container ultimately runs as root (UID 0). This could cause unexpected behavior for environments that require containers to run as a non-root user. This bug has been fixed in containerd 1.6.38, 1.7.27, and 2.04. As a workaround, ensure that only trusted images are used and that only trusted users have permissions to import images. CVE-2024-40635 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:containerd-1.7.27-150000.123.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:containerd-ctr-1.7.27-150000.123.1 moderate In the Linux kernel, the following vulnerability has been resolved: ax25: Fix refcount imbalance on inbound connections When releasing a socket in ax25_release(), we call netdev_put() to decrease the refcount on the associated ax.25 device. However, the execution path for accepting an incoming connection never calls netdev_hold(). This imbalance leads to refcount errors, and ultimately to kernel crashes. A typical call trace for the above situation will start with one of the following errors: refcount_t: decrement hit 0; leaking memory. refcount_t: underflow; use-after-free. And will then have a trace like: Call Trace: <TASK> ? show_regs+0x64/0x70 ? __warn+0x83/0x120 ? refcount_warn_saturate+0xb2/0x100 ? report_bug+0x158/0x190 ? prb_read_valid+0x20/0x30 ? handle_bug+0x3e/0x70 ? exc_invalid_op+0x1c/0x70 ? asm_exc_invalid_op+0x1f/0x30 ? refcount_warn_saturate+0xb2/0x100 ? refcount_warn_saturate+0xb2/0x100 ax25_release+0x2ad/0x360 __sock_release+0x35/0xa0 sock_close+0x19/0x20 [...] On reboot (or any attempt to remove the interface), the kernel gets stuck in an infinite loop: unregister_netdevice: waiting for ax0 to become free. Usage count = 0 This patch corrects these issues by ensuring that we call netdev_hold() and ax25_dev_hold() for new connections in ax25_accept(). This makes the logic leading to ax25_accept() match the logic for ax25_bind(): in both cases we increment the refcount, which is ultimately decremented in ax25_release(). CVE-2024-40910 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: don't allow mapping the MMIO HDP page with large pages We don't get the right offset in that case. The GPU has an unused 4K area of the register BAR space into which you can remap registers. We remap the HDP flush registers into this space to allow userspace (CPU or GPU) to flush the HDP when it updates VRAM. However, on systems with >4K pages, we end up exposing PAGE_SIZE of MMIO space. CVE-2024-41011 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: bluetooth/l2cap: sync sock recv cb and release The problem occurs between the system call to close the sock and hci_rx_work, where the former releases the sock and the latter accesses it without lock protection. CPU0 CPU1 ---- ---- sock_close hci_rx_work l2cap_sock_release hci_acldata_packet l2cap_sock_kill l2cap_recv_frame sk_free l2cap_conless_channel l2cap_sock_recv_cb If hci_rx_work processes the data that needs to be received before the sock is closed, then everything is normal; Otherwise, the work thread may access the released sock when receiving data. Add a chan mutex in the rx callback of the sock to achieve synchronization between the sock release and recv cb. Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer. CVE-2024-41062 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: Fix double free on error If e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump to the err_out label, which will call devres_release_group(). devres_release_group() will trigger a call to ata_host_release(). ata_host_release() calls kfree(host), so executing the kfree(host) in ata_host_alloc() will lead to a double free: kernel BUG at mm/slub.c:553! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:kfree+0x2cf/0x2f0 Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246 RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320 RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0 RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780 R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006 FS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x6a/0x90 ? kfree+0x2cf/0x2f0 ? exc_invalid_op+0x50/0x70 ? kfree+0x2cf/0x2f0 ? asm_exc_invalid_op+0x1a/0x20 ? ata_host_alloc+0xf5/0x120 [libata] ? ata_host_alloc+0xf5/0x120 [libata] ? kfree+0x2cf/0x2f0 ata_host_alloc+0xf5/0x120 [libata] ata_host_alloc_pinfo+0x14/0xa0 [libata] ahci_init_one+0x6c9/0xd20 [ahci] Ensure that we will not call kfree(host) twice, by performing the kfree() only if the devres_open_group() call failed. CVE-2024-41087 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Fix potential UAF by revoke of fence registers CI has been sporadically reporting the following issue triggered by igt@i915_selftest@live@hangcheck on ADL-P and similar machines: <6> [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence ... <6> [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled <6> [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled <3> [414.070354] Unable to pin Y-tiled fence; err:-4 <3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active)) ... <4>[ 609.603992] ------------[ cut here ]------------ <2>[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301! <4>[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI <4>[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1 <4>[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 <4>[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915] <4>[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915] ... <4>[ 609.604271] Call Trace: <4>[ 609.604273] <TASK> ... <4>[ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915] <4>[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915] <4>[ 609.604977] force_unbind+0x24/0xa0 [i915] <4>[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915] <4>[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915] <4>[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915] <4>[ 609.605440] process_scheduled_works+0x351/0x690 ... In the past, there were similar failures reported by CI from other IGT tests, observed on other platforms. Before commit 63baf4f3d587 ("drm/i915/gt: Only wait for GPU activity before unbinding a GGTT fence"), i915_vma_revoke_fence() was waiting for idleness of vma->active via fence_update(). That commit introduced vma->fence->active in order for the fence_update() to be able to wait selectively on that one instead of vma->active since only idleness of fence registers was needed. But then, another commit 0d86ee35097a ("drm/i915/gt: Make fence revocation unequivocal") replaced the call to fence_update() in i915_vma_revoke_fence() with only fence_write(), and also added that GEM_BUG_ON(!i915_active_is_idle(&fence->active)) in front. No justification was provided on why we might then expect idleness of vma->fence->active without first waiting on it. The issue can be potentially caused by a race among revocation of fence registers on one side and sequential execution of signal callbacks invoked on completion of a request that was using them on the other, still processed in parallel to revocation of those fence registers. Fix it by waiting for idleness of vma->fence->active in i915_vma_revoke_fence(). (cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1) CVE-2024-41092 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:docker-28.2.2_ce-150000.227.1 critical Vim is an open source command line text editor. double-free in dialog_changed() in Vim < v9.1.0648. When abandoning a buffer, Vim may ask the user what to do with the modified buffer. If the user wants the changed buffer to be saved, Vim may create a new Untitled file, if the buffer did not have a name yet. However, when setting the buffer name to Unnamed, Vim will falsely free a pointer twice, leading to a double-free and possibly later to a heap-use-after-free, which can lead to a crash. The issue has been fixed as of Vim patch v9.1.0648. CVE-2024-41965 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:vim-9.1.1406-150000.5.75.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:vim-data-common-9.1.1406-150000.5.75.1 low In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix DIO failure due to insufficient transaction credits The code in ocfs2_dio_end_io_write() estimates number of necessary transaction credits using ocfs2_calc_extend_credits(). This however does not take into account that the IO could be arbitrarily large and can contain arbitrary number of extents. Extent tree manipulations do often extend the current transaction but not in all of the cases. For example if we have only single block extents in the tree, ocfs2_mark_extent_written() will end up calling ocfs2_replace_extent_rec() all the time and we will never extend the current transaction and eventually exhaust all the transaction credits if the IO contains many single block extents. Once that happens a WARN_ON(jbd2_handle_buffer_credits(handle) <= 0) is triggered in jbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to this error. This was actually triggered by one of our customers on a heavily fragmented OCFS2 filesystem. To fix the issue make sure the transaction always has enough credits for one extent insert before each call of ocfs2_mark_extent_written(). Heming Zhao said: ------ PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error" PID: xxx TASK: xxxx CPU: 5 COMMAND: "SubmitThread-CA" #0 machine_kexec at ffffffff8c069932 #1 __crash_kexec at ffffffff8c1338fa #2 panic at ffffffff8c1d69b9 #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2] #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2] #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2] #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2] #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2] #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2] #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2] #10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2] #11 dio_complete at ffffffff8c2b9fa7 #12 do_blockdev_direct_IO at ffffffff8c2bc09f #13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2] #14 generic_file_direct_write at ffffffff8c1dcf14 #15 __generic_file_write_iter at ffffffff8c1dd07b #16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2] #17 aio_write at ffffffff8c2cc72e #18 kmem_cache_alloc at ffffffff8c248dde #19 do_io_submit at ffffffff8c2ccada #20 do_syscall_64 at ffffffff8c004984 #21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba CVE-2024-42077 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: crypto: ecdh - explicitly zeroize private_key private_key is overwritten with the key parameter passed in by the caller (if present), or alternatively a newly generated private key. However, it is possible that the caller provides a key (or the newly generated key) which is shorter than the previous key. In that scenario, some key material from the previous key would not be overwritten. The easiest solution is to explicitly zeroize the entire private_key array first. Note that this patch slightly changes the behavior of this function: previously, if the ecc_gen_privkey failed, the old private_key would remain. Now, the private_key is always zeroized. This behavior is consistent with the case where params.key is set and ecc_is_key_valid fails. CVE-2024-42098 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: powerpc: Avoid nmi_enter/nmi_exit in real mode interrupt. nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel crash when invoked during real mode interrupt handling (e.g. early HMI/MCE interrupt handler) if percpu allocation comes from vmalloc area. Early HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI() wrapper which invokes nmi_enter/nmi_exit calls. We don't see any issue when percpu allocation is from the embedded first chunk. However with CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK enabled there are chances where percpu allocation can come from the vmalloc area. With kernel command line "percpu_alloc=page" we can force percpu allocation to come from vmalloc area and can see kernel crash in machine_check_early: [ 1.215714] NIP [c000000000e49eb4] rcu_nmi_enter+0x24/0x110 [ 1.215717] LR [c0000000000461a0] machine_check_early+0xf0/0x2c0 [ 1.215719] --- interrupt: 200 [ 1.215720] [c000000fffd73180] [0000000000000000] 0x0 (unreliable) [ 1.215722] [c000000fffd731b0] [0000000000000000] 0x0 [ 1.215724] [c000000fffd73210] [c000000000008364] machine_check_early_common+0x134/0x1f8 Fix this by avoiding use of nmi_enter()/nmi_exit() in real mode if percpu first chunk is not embedded. CVE-2024-42126 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: IB/core: Implement a limit on UMAD receive List The existing behavior of ib_umad, which maintains received MAD packets in an unbounded list, poses a risk of uncontrolled growth. As user-space applications extract packets from this list, the rate of extraction may not match the rate of incoming packets, leading to potential list overflow. To address this, we introduce a limit to the size of the list. After considering typical scenarios, such as OpenSM processing, which can handle approximately 100k packets per second, and the 1-second retry timeout for most packets, we set the list size limit to 200k. Packets received beyond this limit are dropped, assuming they are likely timed out by the time they are handled by user-space. Notably, packets queued on the receive list due to reasons like timed-out sends are preserved even when the list is full. CVE-2024-42145 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: crypto: aead,cipher - zeroize key buffer after use I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding cryptographic information should be zeroized once they are no longer needed. Accomplish this by using kfree_sensitive for buffers that previously held the private key. CVE-2024-42229 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Fix scv instruction crash with kexec kexec on pseries disables AIL (reloc_on_exc), required for scv instruction support, before other CPUs have been shut down. This means they can execute scv instructions after AIL is disabled, which causes an interrupt at an unexpected entry location that crashes the kernel. Change the kexec sequence to disable AIL after other CPUs have been brought down. As a refresher, the real-mode scv interrupt vector is 0x17000, and the fixed-location head code probably couldn't easily deal with implementing such high addresses so it was just decided not to support that interrupt at all. CVE-2024-42230 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: libceph: fix race between delayed_work() and ceph_monc_stop() The way the delayed work is handled in ceph_monc_stop() is prone to races with mon_fault() and possibly also finish_hunting(). Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after cancel_delayed_work_sync() runs -- __close_session() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic. This part was missed in commit b5d91704f53e ("libceph: behave in mon_fault() if cur_mon < 0") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused. To fix this: - clear monc->cur_mon and monc->hunting as part of closing the session in ceph_monc_stop() - bail from delayed_work() if monc->cur_mon is cleared, similar to how it's done in mon_fault() and finish_hunting() (based on monc->hunting) - call cancel_delayed_work_sync() after the session is closed CVE-2024-42232 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: x86/bhi: Avoid warning in #DB handler due to BHI mitigation When BHI mitigation is enabled, if SYSENTER is invoked with the TF flag set then entry_SYSENTER_compat() uses CLEAR_BRANCH_HISTORY and calls the clear_bhb_loop() before the TF flag is cleared. This causes the #DB handler (exc_debug_kernel()) to issue a warning because single-step is used outside the entry_SYSENTER_compat() function. To address this issue, entry_SYSENTER_compat() should use CLEAR_BRANCH_HISTORY after making sure the TF flag is cleared. The problem can be reproduced with the following sequence: $ cat sysenter_step.c int main() { asm("pushf; pop %ax; bts $8,%ax; push %ax; popf; sysenter"); } $ gcc -o sysenter_step sysenter_step.c $ ./sysenter_step Segmentation fault (core dumped) The program is expected to crash, and the #DB handler will issue a warning. Kernel log: WARNING: CPU: 27 PID: 7000 at arch/x86/kernel/traps.c:1009 exc_debug_kernel+0xd2/0x160 ... RIP: 0010:exc_debug_kernel+0xd2/0x160 ... Call Trace: <#DB> ? show_regs+0x68/0x80 ? __warn+0x8c/0x140 ? exc_debug_kernel+0xd2/0x160 ? report_bug+0x175/0x1a0 ? handle_bug+0x44/0x90 ? exc_invalid_op+0x1c/0x70 ? asm_exc_invalid_op+0x1f/0x30 ? exc_debug_kernel+0xd2/0x160 exc_debug+0x43/0x50 asm_exc_debug+0x1e/0x40 RIP: 0010:clear_bhb_loop+0x0/0xb0 ... </#DB> <TASK> ? entry_SYSENTER_compat_after_hwframe+0x6e/0x8d </TASK> [ bp: Massage commit message. ] CVE-2024-42240 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use after free in iucv_sock_close() iucv_sever_path() is called from process context and from bh context. iucv->path is used as indicator whether somebody else is taking care of severing the path (or it is already removed / never existed). This needs to be done with atomic compare and swap, otherwise there is a small window where iucv_sock_close() will try to work with a path that has already been severed and freed by iucv_callback_connrej() called by iucv_tasklet_fn(). Example: [452744.123844] Call Trace: [452744.123845] ([<0000001e87f03880>] 0x1e87f03880) [452744.123966] [<00000000d593001e>] iucv_path_sever+0x96/0x138 [452744.124330] [<000003ff801ddbca>] iucv_sever_path+0xc2/0xd0 [af_iucv] [452744.124336] [<000003ff801e01b6>] iucv_sock_close+0xa6/0x310 [af_iucv] [452744.124341] [<000003ff801e08cc>] iucv_sock_release+0x3c/0xd0 [af_iucv] [452744.124345] [<00000000d574794e>] __sock_release+0x5e/0xe8 [452744.124815] [<00000000d5747a0c>] sock_close+0x34/0x48 [452744.124820] [<00000000d5421642>] __fput+0xba/0x268 [452744.124826] [<00000000d51b382c>] task_work_run+0xbc/0xf0 [452744.124832] [<00000000d5145710>] do_notify_resume+0x88/0x90 [452744.124841] [<00000000d5978096>] system_call+0xe2/0x2c8 [452744.125319] Last Breaking-Event-Address: [452744.125321] [<00000000d5930018>] iucv_path_sever+0x90/0x138 [452744.125324] [452744.125325] Kernel panic - not syncing: Fatal exception in interrupt Note that bh_lock_sock() is not serializing the tasklet context against process context, because the check for sock_owned_by_user() and corresponding handling is missing. Ideas for a future clean-up patch: A) Correct usage of bh_lock_sock() in tasklet context, as described in Re-enqueue, if needed. This may require adding return values to the tasklet functions and thus changes to all users of iucv. B) Change iucv tasklet into worker and use only lock_sock() in af_iucv. CVE-2024-42271 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: dev/parport: fix the array out-of-bounds risk Fixed array out-of-bounds issues caused by sprintf by replacing it with snprintf for safer data copying, ensuring the destination buffer is not overflowed. Below is the stack trace I encountered during the actual issue: [ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport] [ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm: QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2 [ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp [ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024 [ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace: [ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0 [ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20 [ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c [ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc [ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38 [ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport] CVE-2024-42301 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate Vim is an open source command line text editor. When performing a search and displaying the search-count message is disabled (:set shm+=S), the search pattern is displayed at the bottom of the screen in a buffer (msgbuf). When right-left mode (:set rl) is enabled, the search pattern is reversed. This happens by allocating a new buffer. If the search pattern contains some ASCII NUL characters, the buffer allocated will be smaller than the original allocated buffer (because for allocating the reversed buffer, the strlen() function is called, which only counts until it notices an ASCII NUL byte ) and thus the original length indicator is wrong. This causes an overflow when accessing characters inside the msgbuf by the previously (now wrong) length of the msgbuf. The issue has been fixed as of Vim patch v9.1.0689. CVE-2024-43790 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:vim-9.1.1406-150000.5.75.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:vim-data-common-9.1.1406-150000.5.75.1 moderate Vim is an improved version of the unix vi text editor. When flushing the typeahead buffer, Vim moves the current position in the typeahead buffer but does not check whether there is enough space left in the buffer to handle the next characters. So this may lead to the tb_off position within the typebuf variable to point outside of the valid buffer size, which can then later lead to a heap-buffer overflow in e.g. ins_typebuf(). Therefore, when flushing the typeahead buffer, check if there is enough space left before advancing the off position. If not, fall back to flush current typebuf contents. It's not quite clear yet, what can lead to this situation. It seems to happen when error messages occur (which will cause Vim to flush the typeahead buffer) in comnination with several long mappgins and so it may eventually move the off position out of a valid buffer size. Impact is low since it is not easily reproducible and requires to have several mappings active and run into some error condition. But when this happens, this will cause a crash. The issue has been fixed as of Vim patch v9.1.0697. Users are advised to upgrade. There are no known workarounds for this issue. CVE-2024-43802 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:vim-9.1.1406-150000.5.75.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:vim-data-common-9.1.1406-150000.5.75.1 moderate In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: Prevent UAF in proc_cpuset_show() An UAF can happen when /proc/cpuset is read as reported in [1]. This can be reproduced by the following methods: 1.add an mdelay(1000) before acquiring the cgroup_lock In the cgroup_path_ns function. 2.$cat /proc/<pid>/cpuset repeatly. 3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/ $umount /sys/fs/cgroup/cpuset/ repeatly. The race that cause this bug can be shown as below: (umount) | (cat /proc/<pid>/cpuset) css_release | proc_cpuset_show css_release_work_fn | css = task_get_css(tsk, cpuset_cgrp_id); css_free_rwork_fn | cgroup_path_ns(css->cgroup, ...); cgroup_destroy_root | mutex_lock(&cgroup_mutex); rebind_subsystems | cgroup_free_root | | // cgrp was freed, UAF | cgroup_path_ns_locked(cgrp,..); When the cpuset is initialized, the root node top_cpuset.css.cgrp will point to &cgrp_dfl_root.cgrp. In cgroup v1, the mount operation will allocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated &cgroup_root.cgrp. When the umount operation is executed, top_cpuset.css.cgrp will be rebound to &cgrp_dfl_root.cgrp. The problem is that when rebinding to cgrp_dfl_root, there are cases where the cgroup_root allocated by setting up the root for cgroup v1 is cached. This could lead to a Use-After-Free (UAF) if it is subsequently freed. The descendant cgroups of cgroup v1 can only be freed after the css is released. However, the css of the root will never be released, yet the cgroup_root should be freed when it is unmounted. This means that obtaining a reference to the css of the root does not guarantee that css.cgrp->root will not be freed. Fix this problem by using rcu_read_lock in proc_cpuset_show(). As cgroup_root is kfree_rcu after commit d23b5c577715 ("cgroup: Make operations on the cgroup root_list RCU safe"), css->cgroup won't be freed during the critical section. To call cgroup_path_ns_locked, css_set_lock is needed, so it is safe to replace task_get_css with task_css. [1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd CVE-2024-43853 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: block: initialize integrity buffer to zero before writing it to media Metadata added by bio_integrity_prep is using plain kmalloc, which leads to random kernel memory being written media. For PI metadata this is limited to the app tag that isn't used by kernel generated metadata, but for non-PI metadata the entire buffer leaks kernel memory. Fix this by adding the __GFP_ZERO flag to allocations for writes. CVE-2024-43854 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: usb: qmi_wwan: fix memory leak for not ip packets Free the unused skb when not ip packets arrive. CVE-2024-43861 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: usb: vhci-hcd: Do not drop references before new references are gained At a few places the driver carries stale pointers to references that can still be used. Make sure that does not happen. This strictly speaking closes ZDI-CAN-22273, though there may be similar races in the driver. CVE-2024-43883 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: idpf: fix UAFs when destroying the queues The second tagged commit started sometimes (very rarely, but possible) throwing WARNs from net/core/page_pool.c:page_pool_disable_direct_recycling(). Turned out idpf frees interrupt vectors with embedded NAPIs *before* freeing the queues making page_pools' NAPI pointers lead to freed memory before these pools are destroyed by libeth. It's not clear whether there are other accesses to the freed vectors when destroying the queues, but anyway, we usually free queue/interrupt vectors only when the queues are destroyed and the NAPIs are guaranteed to not be referenced anywhere. Invert the allocation and freeing logic making queue/interrupt vectors be allocated first and freed last. Vectors don't require queues to be present, so this is safe. Additionally, this change allows to remove that useless queue->q_vector pointer cleanup, as vectors are still valid when freeing the queues (+ both are freed within one function, so it's not clear why nullify the pointers at all). CVE-2024-44932 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: jfs: Fix shift-out-of-bounds in dbDiscardAG When searching for the next smaller log2 block, BLKSTOL2() returned 0, causing shift exponent -1 to be negative. This patch fixes the issue by exiting the loop directly when negative shift is found. CVE-2024-44938 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: kcm: Serialise kcm_sendmsg() for the same socket. syzkaller reported UAF in kcm_release(). [0] The scenario is 1. Thread A builds a skb with MSG_MORE and sets kcm->seq_skb. 2. Thread A resumes building skb from kcm->seq_skb but is blocked by sk_stream_wait_memory() 3. Thread B calls sendmsg() concurrently, finishes building kcm->seq_skb and puts the skb to the write queue 4. Thread A faces an error and finally frees skb that is already in the write queue 5. kcm_release() does double-free the skb in the write queue When a thread is building a MSG_MORE skb, another thread must not touch it. Let's add a per-sk mutex and serialise kcm_sendmsg(). [0]: BUG: KASAN: slab-use-after-free in __skb_unlink include/linux/skbuff.h:2366 [inline] BUG: KASAN: slab-use-after-free in __skb_dequeue include/linux/skbuff.h:2385 [inline] BUG: KASAN: slab-use-after-free in __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline] BUG: KASAN: slab-use-after-free in __skb_queue_purge include/linux/skbuff.h:3181 [inline] BUG: KASAN: slab-use-after-free in kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691 Read of size 8 at addr ffff0000ced0fc80 by task syz-executor329/6167 CPU: 1 PID: 6167 Comm: syz-executor329 Tainted: G B 6.8.0-rc5-syzkaller-g9abbc24128bc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:291 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:298 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0x178/0x518 mm/kasan/report.c:488 kasan_report+0xd8/0x138 mm/kasan/report.c:601 __asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381 __skb_unlink include/linux/skbuff.h:2366 [inline] __skb_dequeue include/linux/skbuff.h:2385 [inline] __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline] __skb_queue_purge include/linux/skbuff.h:3181 [inline] kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691 __sock_release net/socket.c:659 [inline] sock_close+0xa4/0x1e8 net/socket.c:1421 __fput+0x30c/0x738 fs/file_table.c:376 ____fput+0x20/0x30 fs/file_table.c:404 task_work_run+0x230/0x2e0 kernel/task_work.c:180 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0x618/0x1f64 kernel/exit.c:871 do_group_exit+0x194/0x22c kernel/exit.c:1020 get_signal+0x1500/0x15ec kernel/signal.c:2893 do_signal+0x23c/0x3b44 arch/arm64/kernel/signal.c:1249 do_notify_resume+0x74/0x1f4 arch/arm64/kernel/entry-common.c:148 exit_to_user_mode_prepare arch/arm64/kernel/entry-common.c:169 [inline] exit_to_user_mode arch/arm64/kernel/entry-common.c:178 [inline] el0_svc+0xac/0x168 arch/arm64/kernel/entry-common.c:713 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Allocated by task 6166: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x70/0x84 mm/kasan/generic.c:626 unpoison_slab_object mm/kasan/common.c:314 [inline] __kasan_slab_alloc+0x74/0x8c mm/kasan/common.c:340 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3813 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_node+0x204/0x4c0 mm/slub.c:3903 __alloc_skb+0x19c/0x3d8 net/core/skbuff.c:641 alloc_skb include/linux/skbuff.h:1296 [inline] kcm_sendmsg+0x1d3c/0x2124 net/kcm/kcmsock.c:783 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_sendmsg+0x220/0x2c0 net/socket.c:768 splice_to_socket+0x7cc/0xd58 fs/splice.c:889 do_splice_from fs/splice.c:941 [inline] direct_splice_actor+0xec/0x1d8 fs/splice.c:1164 splice_direct_to_actor+0x438/0xa0c fs/splice.c:1108 do_splice_direct_actor ---truncated--- CVE-2024-44946 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: fuse: Initialize beyond-EOF page contents before setting uptodate fuse_notify_store(), unlike fuse_do_readpage(), does not enable page zeroing (because it can be used to change partial page contents). So fuse_notify_store() must be more careful to fully initialize page contents (including parts of the page that are beyond end-of-file) before marking the page uptodate. The current code can leave beyond-EOF page contents uninitialized, which makes these uninitialized page contents visible to userspace via mmap(). This is an information leak, but only affects systems which do not enable init-on-alloc (via CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y or the corresponding kernel command line parameter). CVE-2024-44947 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: idpf: fix memory leaks and crashes while performing a soft reset The second tagged commit introduced a UAF, as it removed restoring q_vector->vport pointers after reinitializating the structures. This is due to that all queue allocation functions are performed here with the new temporary vport structure and those functions rewrite the backpointers to the vport. Then, this new struct is freed and the pointers start leading to nowhere. But generally speaking, the current logic is very fragile. It claims to be more reliable when the system is low on memory, but in fact, it consumes two times more memory as at the moment of running this function, there are two vports allocated with their queues and vectors. Moreover, it claims to prevent the driver from running into "bad state", but in fact, any error during the rebuild leaves the old vport in the partially allocated state. Finally, if the interface is down when the function is called, it always allocates a new queue set, but when the user decides to enable the interface later on, vport_open() allocates them once again, IOW there's a clear memory leak here. Just don't allocate a new queue set when performing a reset, that solves crashes and memory leaks. Readd the old queue number and reopen the interface on rollback - that solves limbo states when the device is left disabled and/or without HW queues enabled. CVE-2024-44964 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: vfs: Don't evict inode under the inode lru traversing context The inode reclaiming process(See function prune_icache_sb) collects all reclaimable inodes and mark them with I_FREEING flag at first, at that time, other processes will be stuck if they try getting these inodes (See function find_inode_fast), then the reclaiming process destroy the inodes by function dispose_list(). Some filesystems(eg. ext4 with ea_inode feature, ubifs with xattr) may do inode lookup in the inode evicting callback function, if the inode lookup is operated under the inode lru traversing context, deadlock problems may happen. Case 1: In function ext4_evict_inode(), the ea inode lookup could happen if ea_inode feature is enabled, the lookup process will be stuck under the evicting context like this: 1. File A has inode i_reg and an ea inode i_ea 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea 3. Then, following three processes running like this: PA PB echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // i_reg is added into lru, lru->i_ea->i_reg prune_icache_sb list_lru_walk_one inode_lru_isolate i_ea->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(i_reg) spin_unlock(&i_reg->i_lock) spin_unlock(lru_lock) rm file A i_reg->nlink = 0 iput(i_reg) // i_reg->nlink is 0, do evict ext4_evict_inode ext4_xattr_delete_inode ext4_xattr_inode_dec_ref_all ext4_xattr_inode_iget ext4_iget(i_ea->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(i_ea) -----> AA deadlock dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&i_ea->i_state) Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file deleting process holds BASEHD's wbuf->io_mutex while getting the xattr inode, which could race with inode reclaiming process(The reclaiming process could try locking BASEHD's wbuf->io_mutex in inode evicting function), then an ABBA deadlock problem would happen as following: 1. File A has inode ia and a xattr(with inode ixa), regular file B has inode ib and a xattr. 2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa 3. Then, following three processes running like this: PA PB PC echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // ib and ia are added into lru, lru->ixa->ib->ia prune_icache_sb list_lru_walk_one inode_lru_isolate ixa->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(ib) spin_unlock(&ib->i_lock) spin_unlock(lru_lock) rm file B ib->nlink = 0 rm file A iput(ia) ubifs_evict_inode(ia) ubifs_jnl_delete_inode(ia) ubifs_jnl_write_inode(ia) make_reservation(BASEHD) // Lock wbuf->io_mutex ubifs_iget(ixa->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(ixa) | iput(ib) // ib->nlink is 0, do evict | ubifs_evict_inode | ubifs_jnl_delete_inode(ib) v ubifs_jnl_write_inode ABBA deadlock <------make_reservation(BASEHD) dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&ixa->i_state) Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING to pin the inode in memory while inode_lru_isolate( ---truncated--- CVE-2024-45003 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: nvme: move stopping keep-alive into nvme_uninit_ctrl() Commit 4733b65d82bd ("nvme: start keep-alive after admin queue setup") moves starting keep-alive from nvme_start_ctrl() into nvme_init_ctrl_finish(), but don't move stopping keep-alive into nvme_uninit_ctrl(), so keep-alive work can be started and keep pending after failing to start controller, finally use-after-free is triggered if nvme host driver is unloaded. This patch fixes kernel panic when running nvme/004 in case that connection failure is triggered, by moving stopping keep-alive into nvme_uninit_ctrl(). This way is reasonable because keep-alive is now started in nvme_init_ctrl_finish(). CVE-2024-45013 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: netem: fix return value if duplicate enqueue fails There is a bug in netem_enqueue() introduced by commit 5845f706388a ("net: netem: fix skb length BUG_ON in __skb_to_sgvec") that can lead to a use-after-free. This commit made netem_enqueue() always return NET_XMIT_SUCCESS when a packet is duplicated, which can cause the parent qdisc's q.qlen to be mistakenly incremented. When this happens qlen_notify() may be skipped on the parent during destruction, leaving a dangling pointer for some classful qdiscs like DRR. There are two ways for the bug happen: - If the duplicated packet is dropped by rootq->enqueue() and then the original packet is also dropped. - If rootq->enqueue() sends the duplicated packet to a different qdisc and the original packet is dropped. In both cases NET_XMIT_SUCCESS is returned even though no packets are enqueued at the netem qdisc. The fix is to defer the enqueue of the duplicate packet until after the original packet has been guaranteed to return NET_XMIT_SUCCESS. CVE-2024-45016 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: memcg_write_event_control(): fix a user-triggerable oops we are *not* guaranteed that anything past the terminating NUL is mapped (let alone initialized with anything sane). CVE-2024-45021 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix error recovery leading to data corruption on ESE devices Extent Space Efficient (ESE) or thin provisioned volumes need to be formatted on demand during usual IO processing. The dasd_ese_needs_format function checks for error codes that signal the non existence of a proper track format. The check for incorrect length is to imprecise since other error cases leading to transport of insufficient data also have this flag set. This might lead to data corruption in certain error cases for example during a storage server warmstart. Fix by removing the check for incorrect length and replacing by explicitly checking for invalid track format in transport mode. Also remove the check for file protected since this is not a valid ESE handling case. CVE-2024-45026 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate Vim is an open source, command line text editor. Patch v9.1.0038 optimized how the cursor position is calculated and removed a loop, that verified that the cursor position always points inside a line and does not become invalid by pointing beyond the end of a line. Back then we assumed this loop is unnecessary. However, this change made it possible that the cursor position stays invalid and points beyond the end of a line, which would eventually cause a heap-buffer-overflow when trying to access the line pointer at the specified cursor position. It's not quite clear yet, what can lead to this situation that the cursor points to an invalid position. That's why patch v9.1.0707 does not include a test case. The only observed impact has been a program crash. This issue has been addressed in with the patch v9.1.0707. All users are advised to upgrade. CVE-2024-45306 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:vim-9.1.1406-150000.5.75.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:vim-data-common-9.1.1406-150000.5.75.1 moderate runc is a CLI tool for spawning and running containers according to the OCI specification. runc 1.1.13 and earlier, as well as 1.2.0-rc2 and earlier, can be tricked into creating empty files or directories in arbitrary locations in the host filesystem by sharing a volume between two containers and exploiting a race with `os.MkdirAll`. While this could be used to create empty files, existing files would not be truncated. An attacker must have the ability to start containers using some kind of custom volume configuration. Containers using user namespaces are still affected, but the scope of places an attacker can create inodes can be significantly reduced. Sufficiently strict LSM policies (SELinux/Apparmor) can also in principle block this attack -- we suspect the industry standard SELinux policy may restrict this attack's scope but the exact scope of protection hasn't been analysed. This is exploitable using runc directly as well as through Docker and Kubernetes. The issue is fixed in runc v1.1.14 and v1.2.0-rc3. Some workarounds are available. Using user namespaces restricts this attack fairly significantly such that the attacker can only create inodes in directories that the remapped root user/group has write access to. Unless the root user is remapped to an actual user on the host (such as with rootless containers that don't use `/etc/sub[ug]id`), this in practice means that an attacker would only be able to create inodes in world-writable directories. A strict enough SELinux or AppArmor policy could in principle also restrict the scope if a specific label is applied to the runc runtime, though neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested. CVE-2024-45310 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:runc-1.2.6-150000.73.2 low Applications and libraries which misuse connection.serverAuthenticate (via callback field ServerConfig.PublicKeyCallback) may be susceptible to an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions. For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key. Since this API is widely misused, as a partial mitigation golang.org/x/cry...@v0.31.0 enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance. CVE-2024-45337 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:google-guest-agent-20250506.01-150000.1.63.1 important When logs are written to a widely-writable directory (the default), an unprivileged attacker may predict a privileged process's log file path and pre-create a symbolic link to a sensitive file in its place. When that privileged process runs, it will follow the planted symlink and overwrite that sensitive file. To fix that, glog now causes the program to exit (with status code 2) when it finds that the configured log file already exists. CVE-2024-45339 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:google-osconfig-agent-20250416.02-150000.1.50.1 important An issue was discovered in libexpat before 2.6.3. xmlparse.c does not reject a negative length for XML_ParseBuffer. CVE-2024-45490 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libexpat1-2.7.1-150400.3.28.1 moderate An issue was discovered in libexpat before 2.6.3. dtdCopy in xmlparse.c can have an integer overflow for nDefaultAtts on 32-bit platforms (where UINT_MAX equals SIZE_MAX). CVE-2024-45491 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libexpat1-2.7.1-150400.3.28.1 moderate An issue was discovered in libexpat before 2.6.3. nextScaffoldPart in xmlparse.c can have an integer overflow for m_groupSize on 32-bit platforms (where UINT_MAX equals SIZE_MAX). CVE-2024-45492 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libexpat1-2.7.1-150400.3.28.1 moderate A flaw was found in grub2. A specially crafted JPEG file can cause the JPEG parser of grub2 to incorrectly check the bounds of its internal buffers, resulting in an out-of-bounds write. The possibility of overwriting sensitive information to bypass secure boot protections is not discarded. CVE-2024-45774 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-i386-pc-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-x86_64-efi-2.06-150400.11.60.1 moderate A flaw was found in grub2 where the grub_extcmd_dispatcher() function calls grub_arg_list_alloc() to allocate memory for the grub's argument list. However, it fails to check in case the memory allocation fails. Once the allocation fails, a NULL point will be processed by the parse_option() function, leading grub to crash or, in some rare scenarios, corrupt the IVT data. CVE-2024-45775 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-i386-pc-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-x86_64-efi-2.06-150400.11.60.1 moderate When reading the language .mo file in grub_mofile_open(), grub2 fails to verify an integer overflow when allocating its internal buffer. A crafted .mo file may lead the buffer size calculation to overflow, leading to out-of-bound reads and writes. This flaw allows an attacker to leak sensitive data or overwrite critical data, possibly circumventing secure boot protections. CVE-2024-45776 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-i386-pc-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-x86_64-efi-2.06-150400.11.60.1 moderate A flaw was found in grub2. The calculation of the translation buffer when reading a language .mo file in grub_gettext_getstr_from_position() may overflow, leading to a Out-of-bound write. This issue can be leveraged by an attacker to overwrite grub2's sensitive heap data, eventually leading to the circumvention of secure boot protections. CVE-2024-45777 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-i386-pc-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-x86_64-efi-2.06-150400.11.60.1 moderate A stack overflow flaw was found when reading a BFS file system. A crafted BFS filesystem may lead to an uncontrolled loop, causing grub2 to crash. CVE-2024-45778 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-i386-pc-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-x86_64-efi-2.06-150400.11.60.1 moderate An integer overflow flaw was found in the BFS file system driver in grub2. When reading a file with an indirect extent map, grub2 fails to validate the number of extent entries to be read. A crafted or corrupted BFS filesystem may cause an integer overflow during the file reading, leading to a heap of bounds read. As a consequence, sensitive data may be leaked, or grub2 will crash. CVE-2024-45779 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-i386-pc-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-x86_64-efi-2.06-150400.11.60.1 moderate A flaw was found in grub2. When reading tar files, grub2 allocates an internal buffer for the file name. However, it fails to properly verify the allocation against possible integer overflows. It's possible to cause the allocation length to overflow with a crafted tar file, leading to a heap out-of-bounds write. This flaw eventually allows an attacker to circumvent secure boot protections. CVE-2024-45780 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-i386-pc-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-x86_64-efi-2.06-150400.11.60.1 moderate A flaw was found in grub2. When reading a symbolic link's name from a UFS filesystem, grub2 fails to validate the string length taken as an input. The lack of validation may lead to a heap out-of-bounds write, causing data integrity issues and eventually allowing an attacker to circumvent secure boot protections. CVE-2024-45781 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-i386-pc-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-x86_64-efi-2.06-150400.11.60.1 moderate A flaw was found in the HFS filesystem. When reading an HFS volume's name at grub_fs_mount(), the HFS filesystem driver performs a strcpy() using the user-provided volume name as input without properly validating the volume name's length. This issue may read to a heap-based out-of-bounds writer, impacting grub's sensitive data integrity and eventually leading to a secure boot protection bypass. CVE-2024-45782 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-i386-pc-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-x86_64-efi-2.06-150400.11.60.1 moderate A flaw was found in grub2. When failing to mount an HFS+ grub, the hfsplus filesystem driver doesn't properly set an ERRNO value. This issue may lead to a NULL pointer access. CVE-2024-45783 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-i386-pc-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-x86_64-efi-2.06-150400.11.60.1 moderate In x86's APIC (Advanced Programmable Interrupt Controller) architecture, error conditions are reported in a status register. Furthermore, the OS can opt to receive an interrupt when a new error occurs. It is possible to configure the error interrupt with an illegal vector, which generates an error when an error interrupt is raised. This case causes Xen to recurse through vlapic_error(). The recursion itself is bounded; errors accumulate in the the status register and only generate an interrupt when a new status bit becomes set. However, the lock protecting this state in Xen will try to be taken recursively, and deadlock. CVE-2024-45817 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:xen-libs-4.16.7_02-150400.4.72.1 moderate The hypervisor contains code to accelerate VGA memory accesses for HVM guests, when the (virtual) VGA is in "standard" mode. Locking involved there has an unusual discipline, leaving a lock acquired past the return from the function that acquired it. This behavior results in a problem when emulating an instruction with two memory accesses, both of which touch VGA memory (plus some further constraints which aren't relevant here). When emulating the 2nd access, the lock that is already being held would be attempted to be re-acquired, resulting in a deadlock. This deadlock was already found when the code was first introduced, but was analysed incorrectly and the fix was incomplete. Analysis in light of the new finding cannot find a way to make the existing locking discipline work. In staging, this logic has all been removed because it was discovered to be accidentally disabled since Xen 4.7. Therefore, we are fixing the locking problem by backporting the removal of most of the feature. Note that even with the feature disabled, the lock would still be acquired for any accesses to the VGA MMIO region. CVE-2024-45818 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:xen-libs-4.16.7_02-150400.4.72.1 moderate PVH guests have their ACPI tables constructed by the toolstack. The construction involves building the tables in local memory, which are then copied into guest memory. While actually used parts of the local memory are filled in correctly, excess space that is being allocated is left with its prior contents. CVE-2024-45819 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:xen-libs-4.16.7_02-150400.4.72.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: st: fix probed platform device ref count on probe error path The probe function never performs any paltform device allocation, thus error path "undo_platform_dev_alloc" is entirely bogus. It drops the reference count from the platform device being probed. If error path is triggered, this will lead to unbalanced device reference counts and premature release of device resources, thus possible use-after-free when releasing remaining devm-managed resources. CVE-2024-46674 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: dmaengine: altera-msgdma: properly free descriptor in msgdma_free_descriptor Remove list_del call in msgdma_chan_desc_cleanup, this should be the role of msgdma_free_descriptor. In consequence replace list_add_tail with list_move_tail in msgdma_free_descriptor. This fixes the path: msgdma_free_chan_resources -> msgdma_free_descriptors -> msgdma_free_desc_list -> msgdma_free_descriptor which does not correctly free the descriptors as first nodes were not removed from the list. CVE-2024-46716 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: powerpc/rtas: Prevent Spectre v1 gadget construction in sys_rtas() Smatch warns: arch/powerpc/kernel/rtas.c:1932 __do_sys_rtas() warn: potential spectre issue 'args.args' [r] (local cap) The 'nargs' and 'nret' locals come directly from a user-supplied buffer and are used as indexes into a small stack-based array and as inputs to copy_to_user() after they are subject to bounds checks. Use array_index_nospec() after the bounds checks to clamp these values for speculative execution. CVE-2024-46774 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: mana: Fix error handling in mana_create_txq/rxq's NAPI cleanup Currently napi_disable() gets called during rxq and txq cleanup, even before napi is enabled and hrtimer is initialized. It causes kernel panic. ? page_fault_oops+0x136/0x2b0 ? page_counter_cancel+0x2e/0x80 ? do_user_addr_fault+0x2f2/0x640 ? refill_obj_stock+0xc4/0x110 ? exc_page_fault+0x71/0x160 ? asm_exc_page_fault+0x27/0x30 ? __mmdrop+0x10/0x180 ? __mmdrop+0xec/0x180 ? hrtimer_active+0xd/0x50 hrtimer_try_to_cancel+0x2c/0xf0 hrtimer_cancel+0x15/0x30 napi_disable+0x65/0x90 mana_destroy_rxq+0x4c/0x2f0 mana_create_rxq.isra.0+0x56c/0x6d0 ? mana_uncfg_vport+0x50/0x50 mana_alloc_queues+0x21b/0x320 ? skb_dequeue+0x5f/0x80 CVE-2024-46784 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_index before accessing dc->links[] [WHY & HOW] dc->links[] has max size of MAX_LINKS and NULL is return when trying to access with out-of-bound index. This fixes 3 OVERRUN and 1 RESOURCE_LEAK issues reported by Coverity. CVE-2024-46813 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check msg_id before processing transcation [WHY & HOW] HDCP_MESSAGE_ID_INVALID (-1) is not a valid msg_id nor is it a valid array index, and it needs checking before used. This fixes 4 OVERRUN issues reported by Coverity. CVE-2024-46814 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check num_valid_sets before accessing reader_wm_sets[] [WHY & HOW] num_valid_sets needs to be checked to avoid a negative index when accessing reader_wm_sets[num_valid_sets - 1]. This fixes an OVERRUN issue reported by Coverity. CVE-2024-46815 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Stop amdgpu_dm initialize when link nums greater than max_links [Why] Coverity report OVERRUN warning. There are only max_links elements within dc->links. link count could up to AMDGPU_DM_MAX_DISPLAY_INDEX 31. [How] Make sure link count less than max_links. CVE-2024-46816 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Stop amdgpu_dm initialize when stream nums greater than 6 [Why] Coverity reports OVERRUN warning. Should abort amdgpu_dm initialize. [How] Return failure to amdgpu_dm_init. CVE-2024-46817 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check gpio_id before used as array index [WHY & HOW] GPIO_ID_UNKNOWN (-1) is not a valid value for array index and therefore should be checked in advance. This fixes 5 OVERRUN issues reported by Coverity. CVE-2024-46818 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: ASoC: meson: axg-card: fix 'use-after-free' Buffer 'card->dai_link' is reallocated in 'meson_card_reallocate_links()', so move 'pad' pointer initialization after this function when memory is already reallocated. Kasan bug report: ================================================================== BUG: KASAN: slab-use-after-free in axg_card_add_link+0x76c/0x9bc Read of size 8 at addr ffff000000e8b260 by task modprobe/356 CPU: 0 PID: 356 Comm: modprobe Tainted: G O 6.9.12-sdkernel #1 Call trace: dump_backtrace+0x94/0xec show_stack+0x18/0x24 dump_stack_lvl+0x78/0x90 print_report+0xfc/0x5c0 kasan_report+0xb8/0xfc __asan_load8+0x9c/0xb8 axg_card_add_link+0x76c/0x9bc [snd_soc_meson_axg_sound_card] meson_card_probe+0x344/0x3b8 [snd_soc_meson_card_utils] platform_probe+0x8c/0xf4 really_probe+0x110/0x39c __driver_probe_device+0xb8/0x18c driver_probe_device+0x108/0x1d8 __driver_attach+0xd0/0x25c bus_for_each_dev+0xe0/0x154 driver_attach+0x34/0x44 bus_add_driver+0x134/0x294 driver_register+0xa8/0x1e8 __platform_driver_register+0x44/0x54 axg_card_pdrv_init+0x20/0x1000 [snd_soc_meson_axg_sound_card] do_one_initcall+0xdc/0x25c do_init_module+0x10c/0x334 load_module+0x24c4/0x26cc init_module_from_file+0xd4/0x128 __arm64_sys_finit_module+0x1f4/0x41c invoke_syscall+0x60/0x188 el0_svc_common.constprop.0+0x78/0x13c do_el0_svc+0x30/0x40 el0_svc+0x38/0x78 el0t_64_sync_handler+0x100/0x12c el0t_64_sync+0x190/0x194 CVE-2024-46849 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: lib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc() If we need to increase the tree depth, allocate a new node, and then race with another thread that increased the tree depth before us, we'll still have a preallocated node that might be used later. If we then use that node for a new non-root node, it'll still have a pointer to the old root instead of being zeroed - fix this by zeroing it in the cmpxchg failure path. CVE-2024-47668 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: mm: avoid leaving partial pfn mappings around in error case As Jann points out, PFN mappings are special, because unlike normal memory mappings, there is no lifetime information associated with the mapping - it is just a raw mapping of PFNs with no reference counting of a 'struct page'. That's all very much intentional, but it does mean that it's easy to mess up the cleanup in case of errors. Yes, a failed mmap() will always eventually clean up any partial mappings, but without any explicit lifetime in the page table mapping itself, it's very easy to do the error handling in the wrong order. In particular, it's easy to mistakenly free the physical backing store before the page tables are actually cleaned up and (temporarily) have stale dangling PTE entries. To make this situation less error-prone, just make sure that any partial pfn mapping is torn down early, before any other error handling. CVE-2024-47674 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated--- CVE-2024-47684 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible UAF for bfqq->bic with merge chain 1) initial state, three tasks: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) | ^ | ^ | ^ | | | | | | V | V | V | bfqq1 bfqq2 bfqq3 process ref: 1 1 1 2) bfqq1 merged to bfqq2: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) | | | ^ \--------------\| | | V V | bfqq1--------->bfqq2 bfqq3 process ref: 0 2 1 3) bfqq2 merged to bfqq3: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) here -> ^ | | \--------------\ \-------------\| V V bfqq1--------->bfqq2---------->bfqq3 process ref: 0 1 3 In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1. bfq_insert_request -> by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -> get bfqq3 from bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> handle IO by bfqq3 Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible): ================================================================== BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595 CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_requeue_work Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757 bfq_init_rq block/bfq-iosched.c:6876 [inline] bfq_insert_request block/bfq-iosched.c:6254 [inline] bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 </TASK> Allocated by task 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3458 [inline] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [inline] ---truncated--- CVE-2024-47706 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove. CVE-2024-47747 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: vhost_vdpa: assign irq bypass producer token correctly We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the token pointer is still valid or not. Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status(). Fixing this by setting up irq bypass producer's token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set. CVE-2024-47748 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case. CVE-2024-47757 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of _STR method Only buffer objects are valid return values of _STR. If something else is returned description_show() will access invalid memory. CVE-2024-49860 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated--- CVE-2024-49867 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: fbdev: efifb: Register sysfs groups through driver core The driver core can register and cleanup sysfs groups already. Make use of that functionality to simplify the error handling and cleanup. Also avoid a UAF race during unregistering where the sysctl attributes were usable after the info struct was freed. CVE-2024-49925 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix array out-of-bound access in SoC stats Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx() function access ath11k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath11k_dp_process_rx() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 CVE-2024-49930 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: net/xen-netback: prevent UAF in xenvif_flush_hash() During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free. Therefore, to solve this, you need to change it to list_for_each_entry_safe. CVE-2024-49936 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: net/ncsi: Disable the ncsi work before freeing the associated structure The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic. CVE-2024-49945 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd. CVE-2024-49960 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max CVE-2024-49969 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches. CVE-2024-49974 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug. CVE-2024-49991 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. CVE-2024-49995 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence. CVE-2024-50017 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: smb: client: fix UAF in async decryption Doing an async decryption (large read) crashes with a slab-use-after-free way down in the crypto API. Reproducer: # mount.cifs -o ...,seal,esize=1 //srv/share /mnt # dd if=/mnt/largefile of=/dev/null ... [ 194.196391] ================================================================== [ 194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110 [ 194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899 [ 194.197707] [ 194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty #43 [ 194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 [ 194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs] [ 194.200032] Call Trace: [ 194.200191] <TASK> [ 194.200327] dump_stack_lvl+0x4e/0x70 [ 194.200558] ? gf128mul_4k_lle+0xc1/0x110 [ 194.200809] print_report+0x174/0x505 [ 194.201040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 194.201352] ? srso_return_thunk+0x5/0x5f [ 194.201604] ? __virt_addr_valid+0xdf/0x1c0 [ 194.201868] ? gf128mul_4k_lle+0xc1/0x110 [ 194.202128] kasan_report+0xc8/0x150 [ 194.202361] ? gf128mul_4k_lle+0xc1/0x110 [ 194.202616] gf128mul_4k_lle+0xc1/0x110 [ 194.202863] ghash_update+0x184/0x210 [ 194.203103] shash_ahash_update+0x184/0x2a0 [ 194.203377] ? __pfx_shash_ahash_update+0x10/0x10 [ 194.203651] ? srso_return_thunk+0x5/0x5f [ 194.203877] ? crypto_gcm_init_common+0x1ba/0x340 [ 194.204142] gcm_hash_assoc_remain_continue+0x10a/0x140 [ 194.204434] crypt_message+0xec1/0x10a0 [cifs] [ 194.206489] ? __pfx_crypt_message+0x10/0x10 [cifs] [ 194.208507] ? srso_return_thunk+0x5/0x5f [ 194.209205] ? srso_return_thunk+0x5/0x5f [ 194.209925] ? srso_return_thunk+0x5/0x5f [ 194.210443] ? srso_return_thunk+0x5/0x5f [ 194.211037] decrypt_raw_data+0x15f/0x250 [cifs] [ 194.212906] ? __pfx_decrypt_raw_data+0x10/0x10 [cifs] [ 194.214670] ? srso_return_thunk+0x5/0x5f [ 194.215193] smb2_decrypt_offload+0x12a/0x6c0 [cifs] This is because TFM is being used in parallel. Fix this by allocating a new AEAD TFM for async decryption, but keep the existing one for synchronous READ cases (similar to what is done in smb3_calc_signature()). Also remove the calls to aead_request_set_callback() and crypto_wait_req() since it's always going to be a synchronous operation. CVE-2024-50047 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. CVE-2024-50089 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't enforce 32-byte alignment of nCR3. In the absolute worst case scenario, failure to ignore bits 4:0 can result in an out-of-bounds read, e.g. if the target page is at the end of a memslot, and the VMM isn't using guard pages. Per the APM: The CR3 register points to the base address of the page-directory-pointer table. The page-directory-pointer table is aligned on a 32-byte boundary, with the low 5 address bits 4:0 assumed to be 0. And the SDM's much more explicit: 4:0 Ignored Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow that is broken. CVE-2024-50115 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix UAF on sco_sock_timeout conn->sk maybe have been unlinked/freed while waiting for sco_conn_lock so this checks if the conn->sk is still valid by checking if it part of sco_sk_list. CVE-2024-50125 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: net: sched: fix use-after-free in taprio_change() In 'taprio_change()', 'admin' pointer may become dangling due to sched switch / removal caused by 'advance_sched()', and critical section protected by 'q->current_entry_lock' is too small to prevent from such a scenario (which causes use-after-free detected by KASAN). Fix this by prefer 'rcu_replace_pointer()' over 'rcu_assign_pointer()' to update 'admin' immediately before an attempt to schedule freeing. CVE-2024-50127 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: net: wwan: fix global oob in wwan_rtnl_policy The variable wwan_rtnl_link_ops assign a *bigger* maxtype which leads to a global out-of-bounds read when parsing the netlink attributes. Exactly same bug cause as the oob fixed in commit b33fb5b801c6 ("net: qualcomm: rmnet: fix global oob in rmnet_policy"). ================================================================== BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:388 [inline] BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603 Read of size 1 at addr ffffffff8b09cb60 by task syz.1.66276/323862 CPU: 0 PID: 323862 Comm: syz.1.66276 Not tainted 6.1.70 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x177/0x231 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x14f/0x750 mm/kasan/report.c:395 kasan_report+0x139/0x170 mm/kasan/report.c:495 validate_nla lib/nlattr.c:388 [inline] __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603 __nla_parse+0x3c/0x50 lib/nlattr.c:700 nla_parse_nested_deprecated include/net/netlink.h:1269 [inline] __rtnl_newlink net/core/rtnetlink.c:3514 [inline] rtnl_newlink+0x7bc/0x1fd0 net/core/rtnetlink.c:3623 rtnetlink_rcv_msg+0x794/0xef0 net/core/rtnetlink.c:6122 netlink_rcv_skb+0x1de/0x420 net/netlink/af_netlink.c:2508 netlink_unicast_kernel net/netlink/af_netlink.c:1326 [inline] netlink_unicast+0x74b/0x8c0 net/netlink/af_netlink.c:1352 netlink_sendmsg+0x882/0xb90 net/netlink/af_netlink.c:1874 sock_sendmsg_nosec net/socket.c:716 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x5cc/0x8f0 net/socket.c:2499 ___sys_sendmsg+0x21c/0x290 net/socket.c:2553 __sys_sendmsg net/socket.c:2582 [inline] __do_sys_sendmsg net/socket.c:2591 [inline] __se_sys_sendmsg+0x19e/0x270 net/socket.c:2589 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x45/0x90 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f67b19a24ad RSP: 002b:00007f67b17febb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f67b1b45f80 RCX: 00007f67b19a24ad RDX: 0000000000000000 RSI: 0000000020005e40 RDI: 0000000000000004 RBP: 00007f67b1a1e01d R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffd2513764f R14: 00007ffd251376e0 R15: 00007f67b17fed40 </TASK> The buggy address belongs to the variable: wwan_rtnl_policy+0x20/0x40 The buggy address belongs to the physical page: page:ffffea00002c2700 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xb09c flags: 0xfff00000001000(reserved|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000001000 ffffea00002c2708 ffffea00002c2708 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner info is not present (never set?) Memory state around the buggy address: ffffffff8b09ca00: 05 f9 f9 f9 05 f9 f9 f9 00 01 f9 f9 00 01 f9 f9 ffffffff8b09ca80: 00 00 00 05 f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 >ffffffff8b09cb00: 00 00 00 00 05 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 ^ ffffffff8b09cb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== According to the comment of `nla_parse_nested_deprecated`, use correct size `IFLA_WWAN_MAX` here to fix this issue. CVE-2024-50128 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink(). Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler(). """ We are seeing a use-after-free from a bpf prog attached to trace_tcp_retransmit_synack. The program passes the req->sk to the bpf_sk_storage_get_tracing kernel helper which does check for null before using it. """ The commit 83fccfc3940c ("inet: fix potential deadlock in reqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() not to call del_timer_sync() from reqsk_timer_handler(), but it introduced a small race window. Before the timer is called, expire_timers() calls detach_timer(timer, true) to clear timer->entry.pprev and marks it as not pending. If reqsk_queue_unlink() checks timer_pending() just after expire_timers() calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires. The reported UAF could happen if req->sk is close()d earlier than the timer expiration, which is 63s by default. The scenario would be 1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(), but del_timer_sync() is missed 2. reqsk timer is executed and scheduled again 3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but reqsk timer still has another one, and inet_csk_accept() does not clear req->sk for non-TFO sockets 4. sk is close()d 5. reqsk timer is executed again, and BPF touches req->sk Let's not use timer_pending() by passing the caller context to __inet_csk_reqsk_queue_drop(). Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1] [0] BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0 Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpf_sk_storage_get_tracing+0x2e/0x1b0 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda bpf_trace_run2+0x4c/0xc0 tcp_rtx_synack+0xf9/0x100 reqsk_timer_handler+0xda/0x3d0 run_timer_softirq+0x292/0x8a0 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 intel_idle_irq+0x5a/0xa0 cpuidle_enter_state+0x94/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6 allocated by task 0 on cpu 9 at 260507.901592s: sk_prot_alloc+0x35/0x140 sk_clone_lock+0x1f/0x3f0 inet_csk_clone_lock+0x15/0x160 tcp_create_openreq_child+0x1f/0x410 tcp_v6_syn_recv_sock+0x1da/0x700 tcp_check_req+0x1fb/0x510 tcp_v6_rcv+0x98b/0x1420 ipv6_list_rcv+0x2258/0x26e0 napi_complete_done+0x5b1/0x2990 mlx5e_napi_poll+0x2ae/0x8d0 net_rx_action+0x13e/0x590 irq_exit_rcu+0xf5/0x320 common_interrupt+0x80/0x90 asm_common_interrupt+0x22/0x40 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb freed by task 0 on cpu 9 at 260507.927527s: rcu_core_si+0x4ff/0xf10 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb CVE-2024-50154 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it. CVE-2024-50199 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size() The step variable is initialized to zero. It is changed in the loop, but if it's not changed it will remain zero. Add a variable check before the division. The observed behavior was introduced by commit 826b5de90c0b ("ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size"), and it is difficult to show that any of the interval parameters will satisfy the snd_interval_test() condition with data from the amdtp_rate_table[] table. Found by Linux Verification Center (linuxtesting.org) with SVACE. CVE-2024-50205 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages Avoid memory corruption while setting up Level-2 PBL pages for the non MR resources when num_pages > 256K. There will be a single PDE page address (contiguous pages in the case of > PAGE_SIZE), but, current logic assumes multiple pages, leading to invalid memory access after 256K PBL entries in the PDE. CVE-2024-50208 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly. CVE-2024-50259 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The "dev_dbg(&urb->dev->dev, ..." which happens after usb_free_urb(urb) is a use after free of the "urb" pointer. Store the "dev" pointer at the start of the function to avoid this issue. CVE-2024-50267 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: idpf: avoid vport access in idpf_get_link_ksettings When the device control plane is removed or the platform running device control plane is rebooted, a reset is detected on the driver. On driver reset, it releases the resources and waits for the reset to complete. If the reset fails, it takes the error path and releases the vport lock. At this time if the monitoring tools tries to access link settings, it call traces for accessing released vport pointer. To avoid it, move link_speed_mbps to netdev_priv structure which removes the dependency on vport pointer and the vport lock in idpf_get_link_ksettings. Also use netif_carrier_ok() to check the link status and adjust the offsetof to use link_up instead of link_speed_mbps. CVE-2024-50274 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table "0 65536 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented. CVE-2024-50279 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that. CVE-2024-50290 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.] CVE-2024-50301 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important An issue was discovered in libexpat before 2.6.4. There is a crash within the XML_ResumeParser function because XML_StopParser can stop/suspend an unstarted parser. CVE-2024-50602 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libexpat1-2.7.1-150400.3.28.1 moderate gio/gsocks4aproxy.c in GNOME GLib before 2.82.1 has an off-by-one error and resultant buffer overflow because SOCKS4_CONN_MSG_LEN is not sufficient for a trailing '\0' character. CVE-2024-52533 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libglib-2_0-0-2.70.5-150400.3.23.1 important A flaw was found in the Avahi-daemon, where it initializes DNS transaction IDs randomly only once at startup, incrementing them sequentially after that. This predictable behavior facilitates DNS spoofing attacks, allowing attackers to guess transaction IDs. CVE-2024-52616 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libavahi-client3-0.8-150400.7.20.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libavahi-common3-0.8-150400.7.20.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment. CVE-2024-53061 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: idpf: fix idpf_vc_core_init error path In an event where the platform running the device control plane is rebooted, reset is detected on the driver. It releases all the resources and waits for the reset to complete. Once the reset is done, it tries to build the resources back. At this time if the device control plane is not yet started, then the driver timeouts on the virtchnl message and retries to establish the mailbox again. In the retry flow, mailbox is deinitialized but the mailbox workqueue is still alive and polling for the mailbox message. This results in accessing the released control queue leading to null-ptr-deref. Fix it by unrolling the work queue cancellation and mailbox deinitialization in the reverse order which they got initialized. CVE-2024-53064 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier() The scmi_dev->name is released prematurely in __scmi_device_destroy(), which causes slab-use-after-free when accessing scmi_dev->name in scmi_bus_notifier(). So move the release of scmi_dev->name to scmi_device_release() to avoid slab-use-after-free. | BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec | Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1 | | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1 | Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT) | Call trace: | dump_backtrace+0x94/0x114 | show_stack+0x18/0x24 | dump_stack_lvl+0x48/0x60 | print_report+0xf4/0x5b0 | kasan_report+0xa4/0xec | __asan_report_load1_noabort+0x20/0x2c | strncmp+0xe4/0xec | scmi_bus_notifier+0x5c/0x54c | notifier_call_chain+0xb4/0x31c | blocking_notifier_call_chain+0x68/0x9c | bus_notify+0x54/0x78 | device_del+0x1bc/0x840 | device_unregister+0x20/0xb4 | __scmi_device_destroy+0xac/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Allocated by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_alloc_info+0x24/0x34 | __kasan_kmalloc+0xa0/0xb8 | __kmalloc_node_track_caller+0x6c/0x104 | kstrdup+0x48/0x84 | kstrdup_const+0x34/0x40 | __scmi_device_create.part.0+0x8c/0x408 | scmi_device_create+0x104/0x370 | scmi_chan_setup+0x2a0/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Freed by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_free_info+0x38/0x5c | __kasan_slab_free+0xe8/0x164 | __kmem_cache_free+0x11c/0x230 | kfree+0x70/0x130 | kfree_const+0x20/0x40 | __scmi_device_destroy+0x70/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 CVE-2024-53068 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free of network namespace. Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0] The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying. The root cause is wrong reference counting for network namespace. CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens. The repro steps are roughly: 1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled. When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers. Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 ("smc: Fix use-after-free in tcp_write_timer_handler()."). Note that we need to move put_net() from cifs_put_tcp_session() to clean_demultiplex_info(); otherwise, __sock_create() still could touch a freed netns while cifsd tries to reconnect from cifs_demultiplex_thread(). Also, maybe_get_net() cannot be put just before __sock_create() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns. [0]: CIFS: VFS: \\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace: fib_rules_lookup+0x44/0x238 __fib_lookup+0x64/0xbc ip_route_output_key_hash_rcu+0x2c4/0x398 ip_route_output_key_hash+0x60/0x8c tcp_v4_connect+0x290/0x488 __inet_stream_connect+0x108/0x3d0 inet_stream_connect+0x50/0x78 kernel_connect+0x6c/0xac generic_ip_conne ---truncated--- CVE-2024-53095 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN Hide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable support for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are myriad bugs in the implementation, some of which are fatal to the guest, and others which put the stability and health of the host at risk. For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and *stays* disabled prior to VM-Enter, which is necessary as hardware disallows loading (the guest's) RTIT_CTL if tracing is enabled (enforced via a VMX consistency check). Per the SDM: If the logical processor is operating with Intel PT enabled (if IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the "load IA32_RTIT_CTL" VM-entry control must be 0. On the host side, KVM doesn't validate the guest CPUID configuration provided by userspace, and even worse, uses the guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring guest CPUID to enumerate more address ranges than are supported in hardware will result in KVM trying to passthrough, save, and load non-existent MSRs, which generates a variety of WARNs, ToPA ERRORs in the host, a potential deadlock, etc. CVE-2024-53135 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix bfqq uaf in bfq_limit_depth() Set new allocated bfqq to bic or remove freed bfqq from bic are both protected by bfqd->lock, however bfq_limit_depth() is deferencing bfqq from bic without the lock, this can lead to UAF if the io_context is shared by multiple tasks. For example, test bfq with io_uring can trigger following UAF in v6.6: ================================================================== BUG: KASAN: slab-use-after-free in bfqq_group+0x15/0x50 Call Trace: <TASK> dump_stack_lvl+0x47/0x80 print_address_description.constprop.0+0x66/0x300 print_report+0x3e/0x70 kasan_report+0xb4/0xf0 bfqq_group+0x15/0x50 bfqq_request_over_limit+0x130/0x9a0 bfq_limit_depth+0x1b5/0x480 __blk_mq_alloc_requests+0x2b5/0xa00 blk_mq_get_new_requests+0x11d/0x1d0 blk_mq_submit_bio+0x286/0xb00 submit_bio_noacct_nocheck+0x331/0x400 __block_write_full_folio+0x3d0/0x640 writepage_cb+0x3b/0xc0 write_cache_pages+0x254/0x6c0 write_cache_pages+0x254/0x6c0 do_writepages+0x192/0x310 filemap_fdatawrite_wbc+0x95/0xc0 __filemap_fdatawrite_range+0x99/0xd0 filemap_write_and_wait_range.part.0+0x4d/0xa0 blkdev_read_iter+0xef/0x1e0 io_read+0x1b6/0x8a0 io_issue_sqe+0x87/0x300 io_wq_submit_work+0xeb/0x390 io_worker_handle_work+0x24d/0x550 io_wq_worker+0x27f/0x6c0 ret_from_fork_asm+0x1b/0x30 </TASK> Allocated by task 808602: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_slab_alloc+0x83/0x90 kmem_cache_alloc_node+0x1b1/0x6d0 bfq_get_queue+0x138/0xfa0 bfq_get_bfqq_handle_split+0xe3/0x2c0 bfq_init_rq+0x196/0xbb0 bfq_insert_request.isra.0+0xb5/0x480 bfq_insert_requests+0x156/0x180 blk_mq_insert_request+0x15d/0x440 blk_mq_submit_bio+0x8a4/0xb00 submit_bio_noacct_nocheck+0x331/0x400 __blkdev_direct_IO_async+0x2dd/0x330 blkdev_write_iter+0x39a/0x450 io_write+0x22a/0x840 io_issue_sqe+0x87/0x300 io_wq_submit_work+0xeb/0x390 io_worker_handle_work+0x24d/0x550 io_wq_worker+0x27f/0x6c0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x1b/0x30 Freed by task 808589: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x27/0x40 __kasan_slab_free+0x126/0x1b0 kmem_cache_free+0x10c/0x750 bfq_put_queue+0x2dd/0x770 __bfq_insert_request.isra.0+0x155/0x7a0 bfq_insert_request.isra.0+0x122/0x480 bfq_insert_requests+0x156/0x180 blk_mq_dispatch_plug_list+0x528/0x7e0 blk_mq_flush_plug_list.part.0+0xe5/0x590 __blk_flush_plug+0x3b/0x90 blk_finish_plug+0x40/0x60 do_writepages+0x19d/0x310 filemap_fdatawrite_wbc+0x95/0xc0 __filemap_fdatawrite_range+0x99/0xd0 filemap_write_and_wait_range.part.0+0x4d/0xa0 blkdev_read_iter+0xef/0x1e0 io_read+0x1b6/0x8a0 io_issue_sqe+0x87/0x300 io_wq_submit_work+0xeb/0x390 io_worker_handle_work+0x24d/0x550 io_wq_worker+0x27f/0x6c0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x1b/0x30 Fix the problem by protecting bic_to_bfqq() with bfqd->lock. CVE-2024-53166 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important 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 Read of size 1 at addr ffff888111f322cd by task swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 Call Trace: <IRQ> dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 kasan_report+0xbd/0xf0 tcp_write_timer_handler+0x156/0x3e0 tcp_write_timer+0x66/0x170 call_timer_fn+0xfb/0x1d0 __run_timers+0x3f8/0x480 run_timer_softirq+0x9b/0x100 handle_softirqs+0x153/0x390 __irq_exit_rcu+0x103/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x76/0x90 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 RIP: 0010:default_idle+0xf/0x20 Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242 RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590f RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835d R10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000 R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 default_idle_call+0x6b/0xa0 cpuidle_idle_call+0x1af/0x1f0 do_idle+0xbc/0x130 cpu_startup_entry+0x33/0x40 rest_init+0x11f/0x210 start_kernel+0x39a/0x420 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x97/0xa0 common_startup_64+0x13e/0x141 </TASK> Allocated by task 595: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30 Reproduction script: mkdir -p /mnt/nfsshare mkdir -p /mnt/nfs/netns_1 mkfs.ext4 /dev/sdb mount /dev/sdb /mnt/nfsshare systemctl restart nfs-server chmod 777 /mnt/nfsshare exportfs -i -o rw,no_root_squash *:/mnt/nfsshare ip netns add netns_1 ip link add name veth_1_peer type veth peer veth_1 ifconfig veth_1_peer 11.11.0.254 up ip link set veth_1 netns netns_1 ip netns exec netns_1 ifconfig veth_1 11.11.0.1 ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp \ --tcp-flags FIN FIN -j DROP (note: In my environment, a DESTROY_CLIENTID operation is always sent immediately, breaking the nfs tcp connection.) ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 \ 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1 ip netns del netns_1 The reason here is that the tcp socket in netns_1 (nfs side) has been shutdown and closed (done in xs_destroy), but the FIN message (with ack) is discarded, and the nfsd side keeps sending retransmission messages. As a result, when the tcp sock in netns_1 processes the received message, it sends the message (FIN message) in the sending queue, and the tcp timer is re-established. When the network namespace is deleted, the net structure accessed by tcp's timer handler function causes problems. To fix this problem, let's hold netns refcnt for the tcp kernel socket as done in other modules. This is an ugly hack which can easily be backported to earlier kernels. A proper fix which cleans up the interfaces will follow, but may not be so easy to backport. CVE-2024-53168 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: smb: prevent use-after-free due to open_cached_dir error paths If open_cached_dir() encounters an error parsing the lease from the server, the error handling may race with receiving a lease break, resulting in open_cached_dir() freeing the cfid while the queued work is pending. Update open_cached_dir() to drop refs rather than directly freeing the cfid. Have cached_dir_lease_break(), cfids_laundromat_worker(), and invalidate_all_cached_dirs() clear has_lease immediately while still holding cfids->cfid_list_lock, and then use this to also simplify the reference counting in cfids_laundromat_worker() and invalidate_all_cached_dirs(). Fixes this KASAN splat (which manually injects an error and lease break in open_cached_dir()): ================================================================== BUG: KASAN: slab-use-after-free in smb2_cached_lease_break+0x27/0xb0 Read of size 8 at addr ffff88811cc24c10 by task kworker/3:1/65 CPU: 3 UID: 0 PID: 65 Comm: kworker/3:1 Not tainted 6.12.0-rc6-g255cf264e6e5-dirty #87 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Workqueue: cifsiod smb2_cached_lease_break Call Trace: <TASK> dump_stack_lvl+0x77/0xb0 print_report+0xce/0x660 kasan_report+0xd3/0x110 smb2_cached_lease_break+0x27/0xb0 process_one_work+0x50a/0xc50 worker_thread+0x2ba/0x530 kthread+0x17c/0x1c0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 2464: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 open_cached_dir+0xa7d/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 2464: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x51/0x70 kfree+0x174/0x520 open_cached_dir+0x97f/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Last potentially related work creation: kasan_save_stack+0x33/0x60 __kasan_record_aux_stack+0xad/0xc0 insert_work+0x32/0x100 __queue_work+0x5c9/0x870 queue_work_on+0x82/0x90 open_cached_dir+0x1369/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The buggy address belongs to the object at ffff88811cc24c00 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 16 bytes inside of freed 1024-byte region [ffff88811cc24c00, ffff88811cc25000) CVE-2024-53177 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: x86/xen: don't do PV iret hypercall through hypercall page Instead of jumping to the Xen hypercall page for doing the iret hypercall, directly code the required sequence in xen-asm.S. This is done in preparation of no longer using hypercall page at all, as it has shown to cause problems with speculation mitigations. This is part of XSA-466 / CVE-2024-53241. CVE-2024-53241 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate readline.sh in socat before1.8.0.2 relies on the /tmp/$USER/stderr2 file. CVE-2024-54661 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:socat-1.8.0.0-150400.14.6.1 moderate libxml2 before 2.12.10 and 2.13.x before 2.13.6 has a use-after-free in xmlSchemaIDCFillNodeTables and xmlSchemaBubbleIDCNodeTables in xmlschemas.c. To exploit this, a crafted XML document must be validated against an XML schema with certain identity constraints, or a crafted XML schema must be used. CVE-2024-56171 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libxml2-2-2.9.14-150400.5.44.1 important CPython 3.9 and earlier doesn't disallow configuring an empty list ("[]") for SSLContext.set_npn_protocols() which is an invalid value for the underlying OpenSSL API. This results in a buffer over-read when NPN is used (see CVE-2024-5535 for OpenSSL). This vulnerability is of low severity due to NPN being not widely used and specifying an empty list likely being uncommon in-practice (typically a protocol name would be configured). CVE-2024-5642 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:python3-3.6.15-150300.10.84.1 moderate 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: nfsd: make sure exp active before svc_export_show The function `e_show` was called with protection from RCU. This only ensures that `exp` will not be freed. Therefore, the reference count for `exp` can drop to zero, which will trigger a refcount use-after-free warning when `exp_get` is called. To resolve this issue, use `cache_get_rcu` to ensure that `exp` remains active. ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 3 PID: 819 at lib/refcount.c:25 refcount_warn_saturate+0xb1/0x120 CPU: 3 UID: 0 PID: 819 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb1/0x120 ... Call Trace: <TASK> e_show+0x20b/0x230 [nfsd] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e CVE-2024-56558 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: ovl: Filter invalid inodes with missing lookup function Add a check to the ovl_dentry_weird() function to prevent the processing of directory inodes that lack the lookup function. This is important because such inodes can cause errors in overlayfs when passed to the lowerstack. CVE-2024-56570 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: net: inet6: do not leave a dangling sk pointer in inet6_create() sock_init_data() attaches the allocated sk pointer to the provided sock object. If inet6_create() fails later, the sk object is released, but the sock object retains the dangling sk pointer, which may cause use-after-free later. Clear the sock sk pointer on error. CVE-2024-56600 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: net: inet: do not leave a dangling sk pointer in inet_create() sock_init_data() attaches the allocated sk object to the provided sock object. If inet_create() fails later, the sk object is freed, but the sock object retains the dangling pointer, which may create use-after-free later. Clear the sk pointer in the sock object on error. CVE-2024-56601 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: net: ieee802154: do not leave a dangling sk pointer in ieee802154_create() sock_init_data() attaches the allocated sk object to the provided sock object. If ieee802154_create() fails later, the allocated sk object is freed, but the dangling pointer remains in the provided sock object, which may allow use-after-free. Clear the sk pointer in the sock object on error. CVE-2024-56602 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential out-of-bounds memory access in nilfs_find_entry() Syzbot reported that when searching for records in a directory where the inode's i_size is corrupted and has a large value, memory access outside the folio/page range may occur, or a use-after-free bug may be detected if KASAN is enabled. This is because nilfs_last_byte(), which is called by nilfs_find_entry() and others to calculate the number of valid bytes of directory data in a page from i_size and the page index, loses the upper 32 bits of the 64-bit size information due to an inappropriate type of local variable to which the i_size value is assigned. This caused a large byte offset value due to underflow in the end address calculation in the calling nilfs_find_entry(), resulting in memory access that exceeds the folio/page size. Fix this issue by changing the type of the local variable causing the bit loss from "unsigned int" to "u64". The return value of nilfs_last_byte() is also of type "unsigned int", but it is truncated so as not to exceed PAGE_SIZE and no bit loss occurs, so no change is required. CVE-2024-56619 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix use after free on unload System crash is observed with stack trace warning of use after free. There are 2 signals to tell dpc_thread to terminate (UNLOADING flag and kthread_stop). On setting the UNLOADING flag when dpc_thread happens to run at the time and sees the flag, this causes dpc_thread to exit and clean up itself. When kthread_stop is called for final cleanup, this causes use after free. Remove UNLOADING signal to terminate dpc_thread. Use the kthread_stop as the main signal to exit dpc_thread. [596663.812935] kernel BUG at mm/slub.c:294! [596663.812950] invalid opcode: 0000 [#1] SMP PTI [596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G IOE --------- - - 4.18.0-240.el8.x86_64 #1 [596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012 [596663.812974] RIP: 0010:__slab_free+0x17d/0x360 ... [596663.813008] Call Trace: [596663.813022] ? __dentry_kill+0x121/0x170 [596663.813030] ? _cond_resched+0x15/0x30 [596663.813034] ? _cond_resched+0x15/0x30 [596663.813039] ? wait_for_completion+0x35/0x190 [596663.813048] ? try_to_wake_up+0x63/0x540 [596663.813055] free_task+0x5a/0x60 [596663.813061] kthread_stop+0xf3/0x100 [596663.813103] qla2x00_remove_one+0x284/0x440 [qla2xxx] CVE-2024-56623 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: tipc: Fix use-after-free of kernel socket in cleanup_bearer(). syzkaller reported a use-after-free of UDP kernel socket in cleanup_bearer() without repro. [0][1] When bearer_disable() calls tipc_udp_disable(), cleanup of the UDP kernel socket is deferred by work calling cleanup_bearer(). tipc_exit_net() waits for such works to finish by checking tipc_net(net)->wq_count. However, the work decrements the count too early before releasing the kernel socket, unblocking cleanup_net() and resulting in use-after-free. Let's move the decrement after releasing the socket in cleanup_bearer(). [0]: ref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at sk_alloc+0x438/0x608 inet_create+0x4c8/0xcb0 __sock_create+0x350/0x6b8 sock_create_kern+0x58/0x78 udp_sock_create4+0x68/0x398 udp_sock_create+0x88/0xc8 tipc_udp_enable+0x5e8/0x848 __tipc_nl_bearer_enable+0x84c/0xed8 tipc_nl_bearer_enable+0x38/0x60 genl_family_rcv_msg_doit+0x170/0x248 genl_rcv_msg+0x400/0x5b0 netlink_rcv_skb+0x1dc/0x398 genl_rcv+0x44/0x68 netlink_unicast+0x678/0x8b0 netlink_sendmsg+0x5e4/0x898 ____sys_sendmsg+0x500/0x830 [1]: BUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline] BUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 udp_hashslot include/net/udp.h:85 [inline] udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 sk_common_release+0xaf/0x3f0 net/core/sock.c:3820 inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437 inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489 __sock_release net/socket.c:658 [inline] sock_release+0xa0/0x210 net/socket.c:686 cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244 Uninit was created at: slab_free_hook mm/slub.c:2269 [inline] slab_free mm/slub.c:4580 [inline] kmem_cache_free+0x207/0xc40 mm/slub.c:4682 net_free net/core/net_namespace.c:454 [inline] cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244 CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: events cleanup_bearer CVE-2024-56642 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: can: j1939: j1939_session_new(): fix skb reference counting Since j1939_session_skb_queue() does an extra skb_get() for each new skb, do the same for the initial one in j1939_session_new() to avoid refcount underflow. [mkl: clean up commit message] CVE-2024-56645 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: net: hsr: avoid potential out-of-bound access in fill_frame_info() syzbot is able to feed a packet with 14 bytes, pretending it is a vlan one. Since fill_frame_info() is relying on skb->mac_len already, extend the check to cover this case. BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline] BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724 fill_frame_info net/hsr/hsr_forward.c:709 [inline] hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724 hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606 __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434 dev_queue_xmit include/linux/netdevice.h:3168 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3146 [inline] packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:726 __sys_sendto+0x594/0x750 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200 x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1323 [inline] alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881 packet_alloc_skb net/packet/af_packet.c:2995 [inline] packet_snd net/packet/af_packet.c:3089 [inline] packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:726 __sys_sendto+0x594/0x750 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200 x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f CVE-2024-56648 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: fix LED ID check in led_tg_check() Syzbot has reported the following BUG detected by KASAN: BUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70 Read of size 1 at addr ffff8881022da0c8 by task repro/5879 ... Call Trace: <TASK> dump_stack_lvl+0x241/0x360 ? __pfx_dump_stack_lvl+0x10/0x10 ? __pfx__printk+0x10/0x10 ? _printk+0xd5/0x120 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x183/0x530 print_report+0x169/0x550 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x45f/0x530 ? __phys_addr+0xba/0x170 ? strlen+0x58/0x70 kasan_report+0x143/0x180 ? strlen+0x58/0x70 strlen+0x58/0x70 kstrdup+0x20/0x80 led_tg_check+0x18b/0x3c0 xt_check_target+0x3bb/0xa40 ? __pfx_xt_check_target+0x10/0x10 ? stack_depot_save_flags+0x6e4/0x830 ? nft_target_init+0x174/0xc30 nft_target_init+0x82d/0xc30 ? __pfx_nft_target_init+0x10/0x10 ? nf_tables_newrule+0x1609/0x2980 ? nf_tables_newrule+0x1609/0x2980 ? rcu_is_watching+0x15/0xb0 ? nf_tables_newrule+0x1609/0x2980 ? nf_tables_newrule+0x1609/0x2980 ? __kmalloc_noprof+0x21a/0x400 nf_tables_newrule+0x1860/0x2980 ? __pfx_nf_tables_newrule+0x10/0x10 ? __nla_parse+0x40/0x60 nfnetlink_rcv+0x14e5/0x2ab0 ? __pfx_validate_chain+0x10/0x10 ? __pfx_nfnetlink_rcv+0x10/0x10 ? __lock_acquire+0x1384/0x2050 ? netlink_deliver_tap+0x2e/0x1b0 ? __pfx_lock_release+0x10/0x10 ? netlink_deliver_tap+0x2e/0x1b0 netlink_unicast+0x7f8/0x990 ? __pfx_netlink_unicast+0x10/0x10 ? __virt_addr_valid+0x183/0x530 ? __check_object_size+0x48e/0x900 netlink_sendmsg+0x8e4/0xcb0 ? __pfx_netlink_sendmsg+0x10/0x10 ? aa_sock_msg_perm+0x91/0x160 ? __pfx_netlink_sendmsg+0x10/0x10 __sock_sendmsg+0x223/0x270 ____sys_sendmsg+0x52a/0x7e0 ? __pfx_____sys_sendmsg+0x10/0x10 __sys_sendmsg+0x292/0x380 ? __pfx___sys_sendmsg+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? exc_page_fault+0x590/0x8c0 ? do_syscall_64+0xb6/0x230 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... </TASK> Since an invalid (without '\0' byte at all) byte sequence may be passed from userspace, add an extra check to ensure that such a sequence is rejected as possible ID and so never passed to 'kstrdup()' and further. CVE-2024-56650 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: can: hi311x: hi3110_can_ist(): fix potential use-after-free The commit a22bd630cfff ("can: hi311x: do not report txerr and rxerr during bus-off") removed the reporting of rxerr and txerr even in case of correct operation (i. e. not bus-off). The error count information added to the CAN frame after netif_rx() is a potential use after free, since there is no guarantee that the skb is in the same state. It might be freed or reused. Fix the issue by postponing the netif_rx() call in case of txerr and rxerr reporting. CVE-2024-56651 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: net: defer final 'struct net' free in netns dismantle Ilya reported a slab-use-after-free in dst_destroy [1] Issue is in xfrm6_net_init() and xfrm4_net_init() : They copy xfrm[46]_dst_ops_template into net->xfrm.xfrm[46]_dst_ops. But net structure might be freed before all the dst callbacks are called. So when dst_destroy() calls later : if (dst->ops->destroy) dst->ops->destroy(dst); dst->ops points to the old net->xfrm.xfrm[46]_dst_ops, which has been freed. See a relevant issue fixed in : ac888d58869b ("net: do not delay dst_entries_add() in dst_release()") A fix is to queue the 'struct net' to be freed after one another cleanup_net() round (and existing rcu_barrier()) [1] BUG: KASAN: slab-use-after-free in dst_destroy (net/core/dst.c:112) Read of size 8 at addr ffff8882137ccab0 by task swapper/37/0 Dec 03 05:46:18 kernel: CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: loaded Not tainted 6.12.0 #67 Hardware name: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 04/01/2014 Call Trace: <IRQ> dump_stack_lvl (lib/dump_stack.c:124) print_address_description.constprop.0 (mm/kasan/report.c:378) ? dst_destroy (net/core/dst.c:112) print_report (mm/kasan/report.c:489) ? dst_destroy (net/core/dst.c:112) ? kasan_addr_to_slab (mm/kasan/common.c:37) kasan_report (mm/kasan/report.c:603) ? dst_destroy (net/core/dst.c:112) ? rcu_do_batch (kernel/rcu/tree.c:2567) dst_destroy (net/core/dst.c:112) rcu_do_batch (kernel/rcu/tree.c:2567) ? __pfx_rcu_do_batch (kernel/rcu/tree.c:2491) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4339 kernel/locking/lockdep.c:4406) rcu_core (kernel/rcu/tree.c:2825) handle_softirqs (kernel/softirq.c:554) __irq_exit_rcu (kernel/softirq.c:589 kernel/softirq.c:428 kernel/softirq.c:637) irq_exit_rcu (kernel/softirq.c:651) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049 arch/x86/kernel/apic/apic.c:1049) </IRQ> <TASK> asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:702) RIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:743) Code: 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 6e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 0f 00 2d c7 c9 27 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 RSP: 0018:ffff888100d2fe00 EFLAGS: 00000246 RAX: 00000000001870ed RBX: 1ffff110201a5fc2 RCX: ffffffffb61a3e46 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb3d4d123 RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed11c7e1835d R10: ffff888e3f0c1aeb R11: 0000000000000000 R12: 0000000000000000 R13: ffff888100d20000 R14: dffffc0000000000 R15: 0000000000000000 ? ct_kernel_exit.constprop.0 (kernel/context_tracking.c:148) ? cpuidle_idle_call (kernel/sched/idle.c:186) default_idle_call (./include/linux/cpuidle.h:143 kernel/sched/idle.c:118) cpuidle_idle_call (kernel/sched/idle.c:186) ? __pfx_cpuidle_idle_call (kernel/sched/idle.c:168) ? lock_release (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5848) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4347 kernel/locking/lockdep.c:4406) ? tsc_verify_tsc_adjust (arch/x86/kernel/tsc_sync.c:59) do_idle (kernel/sched/idle.c:326) cpu_startup_entry (kernel/sched/idle.c:423 (discriminator 1)) start_secondary (arch/x86/kernel/smpboot.c:202 arch/x86/kernel/smpboot.c:282) ? __pfx_start_secondary (arch/x86/kernel/smpboot.c:232) ? soft_restart_cpu (arch/x86/kernel/head_64.S:452) common_startup_64 (arch/x86/kernel/head_64.S:414) </TASK> Dec 03 05:46:18 kernel: Allocated by task 12184: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (./arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69) __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345) kmem_cache_alloc_noprof (mm/slub.c:4085 mm/slub.c:4134 mm/slub.c:4141) copy_net_ns (net/core/net_namespace.c:421 net/core/net_namespace.c:480) create_new_namespaces ---truncated--- CVE-2024-56658 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: tipc: fix NULL deref in cleanup_bearer() syzbot found [1] that after blamed commit, ub->ubsock->sk was NULL when attempting the atomic_dec() : atomic_dec(&tipc_net(sock_net(ub->ubsock->sk))->wq_count); Fix this by caching the tipc_net pointer. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] CPU: 0 UID: 0 PID: 5896 Comm: kworker/0:3 Not tainted 6.13.0-rc1-next-20241203-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: events cleanup_bearer RIP: 0010:read_pnet include/net/net_namespace.h:387 [inline] RIP: 0010:sock_net include/net/sock.h:655 [inline] RIP: 0010:cleanup_bearer+0x1f7/0x280 net/tipc/udp_media.c:820 Code: 18 48 89 d8 48 c1 e8 03 42 80 3c 28 00 74 08 48 89 df e8 3c f7 99 f6 48 8b 1b 48 83 c3 30 e8 f0 e4 60 00 48 89 d8 48 c1 e8 03 <42> 80 3c 28 00 74 08 48 89 df e8 1a f7 99 f6 49 83 c7 e8 48 8b 1b RSP: 0018:ffffc9000410fb70 EFLAGS: 00010206 RAX: 0000000000000006 RBX: 0000000000000030 RCX: ffff88802fe45a00 RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffc9000410f900 RBP: ffff88807e1f0908 R08: ffffc9000410f907 R09: 1ffff92000821f20 R10: dffffc0000000000 R11: fffff52000821f21 R12: ffff888031d19980 R13: dffffc0000000000 R14: dffffc0000000000 R15: ffff88807e1f0918 FS: 0000000000000000(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556ca050b000 CR3: 0000000031c0c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 CVE-2024-56661 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix race between element replace and close() Element replace (with a socket different from the one stored) may race with socket's close() link popping & unlinking. __sock_map_delete() unconditionally unrefs the (wrong) element: // set map[0] = s0 map_update_elem(map, 0, s0) // drop fd of s0 close(s0) sock_map_close() lock_sock(sk) (s0!) sock_map_remove_links(sk) link = sk_psock_link_pop() sock_map_unlink(sk, link) sock_map_delete_from_link // replace map[0] with s1 map_update_elem(map, 0, s1) sock_map_update_elem (s1!) lock_sock(sk) sock_map_update_common psock = sk_psock(sk) spin_lock(&stab->lock) osk = stab->sks[idx] sock_map_add_link(..., &stab->sks[idx]) sock_map_unref(osk, &stab->sks[idx]) psock = sk_psock(osk) sk_psock_put(sk, psock) if (refcount_dec_and_test(&psock)) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) unlock_sock(sk) __sock_map_delete spin_lock(&stab->lock) sk = *psk // s1 replaced s0; sk == s1 if (!sk_test || sk_test == sk) // sk_test (s0) != sk (s1); no branch sk = xchg(psk, NULL) if (sk) sock_map_unref(sk, psk) // unref s1; sks[idx] will dangle psock = sk_psock(sk) sk_psock_put(sk, psock) if (refcount_dec_and_test()) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) release_sock(sk) Then close(map) enqueues bpf_map_free_deferred, which finally calls sock_map_free(). This results in some refcount_t warnings along with a KASAN splat [1]. Fix __sock_map_delete(), do not allow sock_map_unref() on elements that may have been replaced. [1]: BUG: KASAN: slab-use-after-free in sock_map_free+0x10e/0x330 Write of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063 CPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ #125 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Workqueue: events_unbound bpf_map_free_deferred Call Trace: <TASK> dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 kasan_report+0xb9/0x190 kasan_check_range+0x10f/0x1e0 sock_map_free+0x10e/0x330 bpf_map_free_deferred+0x173/0x320 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 1202: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x85/0x90 kmem_cache_alloc_noprof+0x131/0x450 sk_prot_alloc+0x5b/0x220 sk_alloc+0x2c/0x870 unix_create1+0x88/0x8a0 unix_create+0xc5/0x180 __sock_create+0x241/0x650 __sys_socketpair+0x1ce/0x420 __x64_sys_socketpair+0x92/0x100 do_syscall_64+0x93/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 46: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kmem_cache_free+0x1a1/0x590 __sk_destruct+0x388/0x5a0 sk_psock_destroy+0x73e/0xa50 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 The bu ---truncated--- CVE-2024-56664 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate GNU GRUB (aka GRUB2) through 2.12 has a heap-based buffer overflow in fs/hfs.c via crafted sblock data in an HFS filesystem. CVE-2024-56737 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-i386-pc-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-x86_64-efi-2.06-150400.11.60.1 important In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free when COWing tree bock and tracing is enabled When a COWing a tree block, at btrfs_cow_block(), and we have the tracepoint trace_btrfs_cow_block() enabled and preemption is also enabled (CONFIG_PREEMPT=y), we can trigger a use-after-free in the COWed extent buffer while inside the tracepoint code. This is because in some paths that call btrfs_cow_block(), such as btrfs_search_slot(), we are holding the last reference on the extent buffer @buf so btrfs_force_cow_block() drops the last reference on the @buf extent buffer when it calls free_extent_buffer_stale(buf), which schedules the release of the extent buffer with RCU. This means that if we are on a kernel with preemption, the current task may be preempted before calling trace_btrfs_cow_block() and the extent buffer already released by the time trace_btrfs_cow_block() is called, resulting in a use-after-free. Fix this by moving the trace_btrfs_cow_block() from btrfs_cow_block() to btrfs_force_cow_block() before the COWed extent buffer is freed. This also has a side effect of invoking the tracepoint in the tree defrag code, at defrag.c:btrfs_realloc_node(), since btrfs_force_cow_block() is called there, but this is fine and it was actually missing there. CVE-2024-56759 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: net/smc: check return value of sock_recvmsg when draining clc data When receiving clc msg, the field length in smc_clc_msg_hdr indicates the length of msg should be received from network and the value should not be fully trusted as it is from the network. Once the value of length exceeds the value of buflen in function smc_clc_wait_msg it may run into deadloop when trying to drain the remaining data exceeding buflen. This patch checks the return value of sock_recvmsg when draining data in case of deadloop in draining. CVE-2024-57791 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: power: supply: gpio-charger: Fix set charge current limits Fix set charge current limits for devices which allow to set the lowest charge current limit to be greater zero. If requested charge current limit is below lowest limit, the index equals current_limit_map_size which leads to accessing memory beyond allocated memory. CVE-2024-57792 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: s390/cpum_sf: Handle CPU hotplug remove during sampling CPU hotplug remove handling triggers the following function call sequence: CPUHP_AP_PERF_S390_SF_ONLINE --> s390_pmu_sf_offline_cpu() ... CPUHP_AP_PERF_ONLINE --> perf_event_exit_cpu() The s390 CPUMF sampling CPU hotplug handler invokes: s390_pmu_sf_offline_cpu() +--> cpusf_pmu_setup() +--> setup_pmc_cpu() +--> deallocate_buffers() This function de-allocates all sampling data buffers (SDBs) allocated for that CPU at event initialization. It also clears the PMU_F_RESERVED bit. The CPU is gone and can not be sampled. With the event still being active on the removed CPU, the CPU event hotplug support in kernel performance subsystem triggers the following function calls on the removed CPU: perf_event_exit_cpu() +--> perf_event_exit_cpu_context() +--> __perf_event_exit_context() +--> __perf_remove_from_context() +--> event_sched_out() +--> cpumsf_pmu_del() +--> cpumsf_pmu_stop() +--> hw_perf_event_update() to stop and remove the event. During removal of the event, the sampling device driver tries to read out the remaining samples from the sample data buffers (SDBs). But they have already been freed (and may have been re-assigned). This may lead to a use after free situation in which case the samples are most likely invalid. In the best case the memory has not been reassigned and still contains valid data. Remedy this situation and check if the CPU is still in reserved state (bit PMU_F_RESERVED set). In this case the SDBs have not been released an contain valid data. This is always the case when the event is removed (and no CPU hotplug off occured). If the PMU_F_RESERVED bit is not set, the SDB buffers are gone. CVE-2024-57849 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: oss: Fix races at processing SysEx messages OSS sequencer handles the SysEx messages split in 6 bytes packets, and ALSA sequencer OSS layer tries to combine those. It stores the data in the internal buffer and this access is racy as of now, which may lead to the out-of-bounds access. As a temporary band-aid fix, introduce a mutex for serializing the process of the SysEx message packets. CVE-2024-57893 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Correct the migration DMA map direction The SVM DMA device map direction should be set the same as the DMA unmap setting, otherwise the DMA core will report the following warning. Before finialize this solution, there're some discussion on the DMA mapping type(stream-based or coherent) in this KFD migration case, followed by https://lore.kernel.org/all/04d4ab32 -45a1-4b88-86ee-fb0f35a0ca40@amd.com/T/. As there's no dma_sync_single_for_*() in the DMA buffer accessed that because this migration operation should be sync properly and automatically. Give that there's might not be a performance problem in various cache sync policy of DMA sync. Therefore, in order to simplify the DMA direction setting alignment, let's set the DMA map direction as BIDIRECTIONAL. [ 150.834218] WARNING: CPU: 8 PID: 1812 at kernel/dma/debug.c:1028 check_unmap+0x1cc/0x930 [ 150.834225] Modules linked in: amdgpu(OE) amdxcp drm_exec(OE) gpu_sched drm_buddy(OE) drm_ttm_helper(OE) ttm(OE) drm_suballoc_helper(OE) drm_display_helper(OE) drm_kms_helper(OE) i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc sch_fq_codel intel_rapl_msr amd_atl intel_rapl_common snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd snd_pci_acp6x snd_hda_codec snd_acp_config snd_hda_core snd_hwdep snd_soc_acpi kvm_amd sunrpc snd_pcm kvm binfmt_misc snd_seq_midi crct10dif_pclmul snd_seq_midi_event ghash_clmulni_intel sha512_ssse3 snd_rawmidi nls_iso8859_1 sha256_ssse3 sha1_ssse3 snd_seq aesni_intel snd_seq_device crypto_simd snd_timer cryptd input_leds [ 150.834310] wmi_bmof serio_raw k10temp rapl snd sp5100_tco ipmi_devintf soundcore ccp ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport efi_pstore drm(OE) ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii [ 150.834354] CPU: 8 PID: 1812 Comm: rocrtst64 Tainted: G OE 6.10.0-custom #492 [ 150.834358] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021 [ 150.834360] RIP: 0010:check_unmap+0x1cc/0x930 [ 150.834363] Code: c0 4c 89 4d c8 e8 34 bf 86 00 4c 8b 4d c8 4c 8b 45 c0 48 8b 4d b8 48 89 c6 41 57 4c 89 ea 48 c7 c7 80 49 b4 84 e8 b4 81 f3 ff <0f> 0b 48 c7 c7 04 83 ac 84 e8 76 ba fc ff 41 8b 76 4c 49 8d 7e 50 [ 150.834365] RSP: 0018:ffffaac5023739e0 EFLAGS: 00010086 [ 150.834368] RAX: 0000000000000000 RBX: ffffffff8566a2e0 RCX: 0000000000000027 [ 150.834370] RDX: ffff8f6a8f621688 RSI: 0000000000000001 RDI: ffff8f6a8f621680 [ 150.834372] RBP: ffffaac502373a30 R08: 00000000000000c9 R09: ffffaac502373850 [ 150.834373] R10: ffffaac502373848 R11: ffffffff84f46328 R12: ffffaac502373a40 [ 150.834375] R13: ffff8f6741045330 R14: ffff8f6741a77700 R15: ffffffff84ac831b [ 150.834377] FS: 00007faf0fc94c00(0000) GS:ffff8f6a8f600000(0000) knlGS:0000000000000000 [ 150.834379] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 150.834381] CR2: 00007faf0b600020 CR3: 000000010a52e000 CR4: 0000000000350ef0 [ 150.834383] Call Trace: [ 150.834385] <TASK> [ 150.834387] ? show_regs+0x6d/0x80 [ 150.834393] ? __warn+0x8c/0x140 [ 150.834397] ? check_unmap+0x1cc/0x930 [ 150.834400] ? report_bug+0x193/0x1a0 [ 150.834406] ? handle_bug+0x46/0x80 [ 150.834410] ? exc_invalid_op+0x1d/0x80 [ 150.834413] ? asm_exc_invalid_op+0x1f/0x30 [ 150.834420] ? check_unmap+0x1cc/0x930 [ 150.834425] debug_dma_unmap_page+0x86/0x90 [ 150.834431] ? srso_return_thunk+0x5/0x5f [ 150.834435] ---truncated--- CVE-2024-57897 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: mac802154: check local interfaces before deleting sdata list syzkaller reported a corrupted list in ieee802154_if_remove. [1] Remove an IEEE 802.15.4 network interface after unregister an IEEE 802.15.4 hardware device from the system. CPU0 CPU1 ==== ==== genl_family_rcv_msg_doit ieee802154_unregister_hw ieee802154_del_iface ieee802154_remove_interfaces rdev_del_virtual_intf_deprecated list_del(&sdata->list) ieee802154_if_remove list_del_rcu The net device has been unregistered, since the rcu grace period, unregistration must be run before ieee802154_if_remove. To avoid this issue, add a check for local->interfaces before deleting sdata list. [1] kernel BUG at lib/list_debug.c:58! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 6277 Comm: syz-executor157 Not tainted 6.12.0-rc6-syzkaller-00005-g557329bcecc2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__list_del_entry_valid_or_report+0xf4/0x140 lib/list_debug.c:56 Code: e8 a1 7e 00 07 90 0f 0b 48 c7 c7 e0 37 60 8c 4c 89 fe e8 8f 7e 00 07 90 0f 0b 48 c7 c7 40 38 60 8c 4c 89 fe e8 7d 7e 00 07 90 <0f> 0b 48 c7 c7 a0 38 60 8c 4c 89 fe e8 6b 7e 00 07 90 0f 0b 48 c7 RSP: 0018:ffffc9000490f3d0 EFLAGS: 00010246 RAX: 000000000000004e RBX: dead000000000122 RCX: d211eee56bb28d00 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffff88805b278dd8 R08: ffffffff8174a12c R09: 1ffffffff2852f0d R10: dffffc0000000000 R11: fffffbfff2852f0e R12: dffffc0000000000 R13: dffffc0000000000 R14: dead000000000100 R15: ffff88805b278cc0 FS: 0000555572f94380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000056262e4a3000 CR3: 0000000078496000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __list_del_entry_valid include/linux/list.h:124 [inline] __list_del_entry include/linux/list.h:215 [inline] list_del_rcu include/linux/rculist.h:157 [inline] ieee802154_if_remove+0x86/0x1e0 net/mac802154/iface.c:687 rdev_del_virtual_intf_deprecated net/ieee802154/rdev-ops.h:24 [inline] ieee802154_del_iface+0x2c0/0x5c0 net/ieee802154/nl-phy.c:323 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0xb14/0xec0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2551 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8e4/0xcb0 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:744 ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2607 ___sys_sendmsg net/socket.c:2661 [inline] __sys_sendmsg+0x292/0x380 net/socket.c:2690 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f CVE-2024-57948 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net_sched: sch_sfq: don't allow 1 packet limit The current implementation does not work correctly with a limit of 1. iproute2 actually checks for this and this patch adds the check in kernel as well. This fixes the following syzkaller reported crash: UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:210:6 index 65535 is out of range for type 'struct sfq_head[128]' CPU: 0 PID: 2569 Comm: syz-executor101 Not tainted 5.10.0-smp-DEV #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x125/0x19f lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:148 [inline] __ubsan_handle_out_of_bounds+0xed/0x120 lib/ubsan.c:347 sfq_link net/sched/sch_sfq.c:210 [inline] sfq_dec+0x528/0x600 net/sched/sch_sfq.c:238 sfq_dequeue+0x39b/0x9d0 net/sched/sch_sfq.c:500 sfq_reset+0x13/0x50 net/sched/sch_sfq.c:525 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 tbf_reset+0x3d/0x100 net/sched/sch_tbf.c:319 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 dev_reset_queue+0x8c/0x140 net/sched/sch_generic.c:1296 netdev_for_each_tx_queue include/linux/netdevice.h:2350 [inline] dev_deactivate_many+0x6dc/0xc20 net/sched/sch_generic.c:1362 __dev_close_many+0x214/0x350 net/core/dev.c:1468 dev_close_many+0x207/0x510 net/core/dev.c:1506 unregister_netdevice_many+0x40f/0x16b0 net/core/dev.c:10738 unregister_netdevice_queue+0x2be/0x310 net/core/dev.c:10695 unregister_netdevice include/linux/netdevice.h:2893 [inline] __tun_detach+0x6b6/0x1600 drivers/net/tun.c:689 tun_detach drivers/net/tun.c:705 [inline] tun_chr_close+0x104/0x1b0 drivers/net/tun.c:3640 __fput+0x203/0x840 fs/file_table.c:280 task_work_run+0x129/0x1b0 kernel/task_work.c:185 exit_task_work include/linux/task_work.h:33 [inline] do_exit+0x5ce/0x2200 kernel/exit.c:931 do_group_exit+0x144/0x310 kernel/exit.c:1046 __do_sys_exit_group kernel/exit.c:1057 [inline] __se_sys_exit_group kernel/exit.c:1055 [inline] __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1055 do_syscall_64+0x6c/0xd0 entry_SYSCALL_64_after_hwframe+0x61/0xcb RIP: 0033:0x7fe5e7b52479 Code: Unable to access opcode bytes at RIP 0x7fe5e7b5244f. RSP: 002b:00007ffd3c800398 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe5e7b52479 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000 RBP: 00007fe5e7bcd2d0 R08: ffffffffffffffb8 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe5e7bcd2d0 R13: 0000000000000000 R14: 00007fe5e7bcdd20 R15: 00007fe5e7b24270 The crash can be also be reproduced with the following (with a tc recompiled to allow for sfq limits of 1): tc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s ../iproute2-6.9.0/tc/tc qdisc add dev dummy0 handle 2: parent 1:10 sfq limit 1 ifconfig dummy0 up ping -I dummy0 -f -c2 -W0.1 8.8.8.8 sleep 1 Scenario that triggers the crash: * the first packet is sent and queued in TBF and SFQ; qdisc qlen is 1 * TBF dequeues: it peeks from SFQ which moves the packet to the gso_skb list and keeps qdisc qlen set to 1. TBF is out of tokens so it schedules itself for later. * the second packet is sent and TBF tries to queues it to SFQ. qdisc qlen is now 2 and because the SFQ limit is 1 the packet is dropped by SFQ. At this point qlen is 1, and all of the SFQ slots are empty, however q->tail is not NULL. At this point, assuming no more packets are queued, when sch_dequeue runs again it will decrement the qlen for the current empty slot causing an underflow and the subsequent out of bounds access. CVE-2024-57996 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy() In 'wlc_phy_iqcal_gainparams_nphy()', add gain range check to WARN() instead of possible out-of-bounds 'tbl_iqcal_gainparams_nphy' access. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. CVE-2024-58014 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: KVM: Explicitly verify target vCPU is online in kvm_get_vcpu() Explicitly verify the target vCPU is fully online _prior_ to clamping the index in kvm_get_vcpu(). If the index is "bad", the nospec clamping will generate '0', i.e. KVM will return vCPU0 instead of NULL. In practice, the bug is unlikely to cause problems, as it will only come into play if userspace or the guest is buggy or misbehaving, e.g. KVM may send interrupts to vCPU0 instead of dropping them on the floor. However, returning vCPU0 when it shouldn't exist per online_vcpus is problematic now that KVM uses an xarray for the vCPUs array, as KVM needs to insert into the xarray before publishing the vCPU to userspace (see commit c5b077549136 ("KVM: Convert the kvm->vcpus array to a xarray")), i.e. before vCPU creation is guaranteed to succeed. As a result, incorrectly providing access to vCPU0 will trigger a use-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu() bails out of vCPU creation due to an error and frees vCPU0. Commit afb2acb2e3a3 ("KVM: Fix vcpu_array[0] races") papered over that issue, but in doing so introduced an unsolvable teardown conundrum. Preventing accesses to vCPU0 before it's fully online will allow reverting commit afb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race. CVE-2024-58083 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate There is a MEDIUM severity vulnerability affecting CPython. Regular expressions that allowed excessive backtracking during tarfile.TarFile header parsing are vulnerable to ReDoS via specifically-crafted tar archives. CVE-2024-6232 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:python3-3.6.15-150300.10.84.1 important There is a MEDIUM severity vulnerability affecting CPython. The email module didn't properly quote newlines for email headers when serializing an email message allowing for header injection when an email is serialized. CVE-2024-6923 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:python3-3.6.15-150300.10.84.1 important There is a LOW severity vulnerability affecting CPython, specifically the 'http.cookies' standard library module. When parsing cookies that contained backslashes for quoted characters in the cookie value, the parser would use an algorithm with quadratic complexity, resulting in excess CPU resources being used while parsing the value. CVE-2024-7592 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:python3-3.6.15-150300.10.84.1 moderate A stack overflow vulnerability exists in the libexpat library due to the way it handles recursive entity expansion in XML documents. When parsing an XML document with deeply nested entity references, libexpat can be forced to recurse indefinitely, exhausting the stack space and causing a crash. This issue could lead to denial of service (DoS) or, in some cases, exploitable memory corruption, depending on the environment and library usage. CVE-2024-8176 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libexpat1-2.7.1-150400.3.28.1 important 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 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important A vulnerability has been found in the CPython `venv` module and CLI where path names provided when creating a virtual environment were not quoted properly, allowing the creator to inject commands into virtual environment "activation" scripts (ie "source venv/bin/activate"). This means that attacker-controlled virtual environments are able to run commands when the virtual environment is activated. Virtual environments which are not created by an attacker or which aren't activated before being used (ie "./venv/bin/python") are not affected. CVE-2024-9287 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:python3-3.6.15-150300.10.84.1 moderate When curl is asked to use HSTS, the expiry time for a subdomain might overwrite a parent domain's cache entry, making it end sooner or later than otherwise intended. This affects curl using applications that enable HSTS and use URLs with the insecure `HTTP://` scheme and perform transfers with hosts like `x.example.com` as well as `example.com` where the first host is a subdomain of the second host. (The HSTS cache either needs to have been populated manually or there needs to have been previous HTTPS accesses done as the cache needs to have entries for the domains involved to trigger this problem.) When `x.example.com` responds with `Strict-Transport-Security:` headers, this bug can make the subdomain's expiry timeout *bleed over* and get set for the parent domain `example.com` in curl's HSTS cache. The result of a triggered bug is that HTTP accesses to `example.com` get converted to HTTPS for a different period of time than what was asked for by the origin server. If `example.com` for example stops supporting HTTPS at its expiry time, curl might then fail to access `http://example.com` until the (wrongly set) timeout expires. This bug can also expire the parent's entry *earlier*, thus making curl inadvertently switch back to insecure HTTP earlier than otherwise intended. CVE-2024-9681 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:curl-8.0.1-150400.5.62.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libcurl4-8.0.1-150400.5.62.1 moderate When asked to use a `.netrc` file for credentials **and** to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances. This flaw only manifests itself if the netrc file has a `default` entry that omits both login and password. A rare circumstance. CVE-2025-0167 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:curl-8.0.1-150400.5.62.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libcurl4-8.0.1-150400.5.62.1 moderate When the assert() function in the GNU C Library versions 2.13 to 2.40 fails, it does not allocate enough space for the assertion failure message string and size information, which may lead to a buffer overflow if the message string size aligns to page size. CVE-2025-0395 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:glibc-2.31-150300.95.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:glibc-locale-2.31-150300.95.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:glibc-locale-base-2.31-150300.95.1 low Buildx is a Docker CLI plugin that extends build capabilities using BuildKit. Cache backends support credentials by setting secrets directly as attribute values in cache-to/cache-from configuration. When supplied as user input, these secure values may be inadvertently captured in OpenTelemetry traces as part of the arguments and flags for the traced CLI command. OpenTelemetry traces are also saved in BuildKit daemon's history records. This vulnerability does not impact secrets passed to the Github cache backend via environment variables or registry authentication. CVE-2025-0495 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:docker-28.2.2_ce-150000.227.1 moderate A flaw was found in command/gpg. In some scenarios, hooks created by loaded modules are not removed when the related module is unloaded. This flaw allows an attacker to force grub2 to call the hooks once the module that registered it was unloaded, leading to a use-after-free vulnerability. If correctly exploited, this vulnerability may result in arbitrary code execution, eventually allowing the attacker to bypass secure boot protections. CVE-2025-0622 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-i386-pc-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-x86_64-efi-2.06-150400.11.60.1 moderate A flaw was found in grub2. During the network boot process, when trying to search for the configuration file, grub copies data from a user controlled environment variable into an internal buffer using the grub_strcpy() function. During this step, it fails to consider the environment variable length when allocating the internal buffer, resulting in an out-of-bounds write. If correctly exploited, this issue may result in remote code execution through the same network segment grub is searching for the boot information, which can be used to by-pass secure boot protections. CVE-2025-0624 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-i386-pc-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-x86_64-efi-2.06-150400.11.60.1 important A flaw was found in grub2. When performing a symlink lookup, the grub's UFS module checks the inode's data size to allocate the internal buffer to read the file content, however, it fails to check if the symlink data size has overflown. When this occurs, grub_malloc() may be called with a smaller value than needed. When further reading the data from the disk into the buffer, the grub_ufs_lookup_symlink() function will write past the end of the allocated size. An attack can leverage this by crafting a malicious filesystem, and as a result, it will corrupt data stored in the heap, allowing for arbitrary code execution used to by-pass secure boot mechanisms. CVE-2025-0677 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-i386-pc-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-x86_64-efi-2.06-150400.11.60.1 moderate A flaw was found in grub2. When reading data from a squash4 filesystem, grub's squash4 fs module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciously crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the direct_read() will perform a heap based out-of-bounds write during data reading. This flaw may be leveraged to corrupt grub's internal critical data and may result in arbitrary code execution, by-passing secure boot protections. CVE-2025-0678 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-i386-pc-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-x86_64-efi-2.06-150400.11.60.1 moderate A flaw was found in grub2. When performing a symlink lookup from a reiserfs filesystem, grub's reiserfs fs module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciouly crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the grub_reiserfs_read_symlink() will call grub_reiserfs_read_real() with a overflown length parameter, leading to a heap based out-of-bounds write during data reading. This flaw may be leveraged to corrupt grub's internal critical data and can result in arbitrary code execution, by-passing secure boot protections. CVE-2025-0684 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-i386-pc-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-x86_64-efi-2.06-150400.11.60.1 moderate A flaw was found in grub2. When reading data from a jfs filesystem, grub's jfs filesystem module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciouly crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the grub_jfs_lookup_symlink() function will write past the internal buffer length during grub_jfs_read_file(). This issue can be leveraged to corrupt grub's internal critical data and may result in arbitrary code execution, by-passing secure boot protections. CVE-2025-0685 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-i386-pc-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-x86_64-efi-2.06-150400.11.60.1 moderate A flaw was found in grub2. When performing a symlink lookup from a romfs filesystem, grub's romfs filesystem module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciously crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the grub_romfs_read_symlink() may cause out-of-bounds writes when the calling grub_disk_read() function. This issue may be leveraged to corrupt grub's internal critical data and can result in arbitrary code execution by-passing secure boot protections. CVE-2025-0686 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-i386-pc-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-x86_64-efi-2.06-150400.11.60.1 moderate When reading data from disk, the grub's UDF filesystem module utilizes the user controlled data length metadata to allocate its internal buffers. In certain scenarios, while iterating through disk sectors, it assumes the read size from the disk is always smaller than the allocated buffer size which is not guaranteed. A crafted filesystem image may lead to a heap-based buffer overflow resulting in critical data to be corrupted, resulting in the risk of arbitrary code execution by-passing secure boot protections. CVE-2025-0689 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-i386-pc-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-x86_64-efi-2.06-150400.11.60.1 moderate The read command is used to read the keyboard input from the user, while reads it keeps the input length in a 32-bit integer value which is further used to reallocate the line buffer to accept the next character. During this process, with a line big enough it's possible to make this variable to overflow leading to a out-of-bounds write in the heap based buffer. This flaw may be leveraged to corrupt grub's internal critical data and secure boot bypass is not discarded as consequence. CVE-2025-0690 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-i386-pc-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-x86_64-efi-2.06-150400.11.60.1 moderate When libcurl is asked to perform automatic gzip decompression of content-encoded HTTP responses with the `CURLOPT_ACCEPT_ENCODING` option, **using zlib 1.2.0.3 or older**, an attacker-controlled integer overflow would make libcurl perform a buffer overflow. CVE-2025-0725 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:curl-8.0.1-150400.5.62.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libcurl4-8.0.1-150400.5.62.1 moderate The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn't valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers. CVE-2025-0938 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:python3-3.6.15-150300.10.84.1 moderate A flaw was found in grub2. Grub's dump command is not blocked when grub is in lockdown mode, which allows the user to read any memory information, and an attacker may leverage this in order to extract signatures, salts, and other sensitive information from the memory. CVE-2025-1118 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-i386-pc-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-x86_64-efi-2.06-150400.11.60.1 moderate When reading data from a hfs filesystem, grub's hfs filesystem module uses user-controlled parameters from the filesystem metadata to calculate the internal buffers size, however it misses to properly check for integer overflows. A maliciouly crafted filesystem may lead some of those buffer size calculation to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result the hfsplus_open_compressed_real() function will write past of the internal buffer length. This flaw may be leveraged to corrupt grub's internal critical data and may result in arbitrary code execution by-passing secure boot protections. CVE-2025-1125 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-i386-pc-2.06-150400.11.60.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:grub2-x86_64-efi-2.06-150400.11.60.1 moderate A vulnerability classified as problematic was found in vim up to 9.1.1096. This vulnerability affects unknown code of the file src/main.c. The manipulation of the argument --log leads to memory corruption. It is possible to launch the attack on the local host. Upgrading to version 9.1.1097 is able to address this issue. The patch is identified as c5654b84480822817bb7b69ebc97c174c91185e9. It is recommended to upgrade the affected component. CVE-2025-1215 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:vim-9.1.1406-150000.5.75.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:vim-data-common-9.1.1406-150000.5.75.1 low When setting up interrupt remapping for legacy PCI(-X) devices, including PCI(-X) bridges, a lookup of the upstream bridge is required. This lookup, itself involving acquiring of a lock, is done in a context where acquiring that lock is unsafe. This can lead to a deadlock. CVE-2025-1713 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:xen-libs-4.16.7_02-150400.4.72.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Ratelimit warning logs to prevent VM denial of service If there's a persistent error in the hypervisor, the SCSI warning for failed I/O can flood the kernel log and max out CPU utilization, preventing troubleshooting from the VM side. Ratelimit the warning so it doesn't DoS the VM. CVE-2025-21690 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: sched: fix ets qdisc OOB Indexing Haowei Yan <g1042620637@gmail.com> found that ets_class_from_arg() can index an Out-Of-Bound class in ets_class_from_arg() when passed clid of 0. The overflow may cause local privilege escalation. [ 18.852298] ------------[ cut here ]------------ [ 18.853271] UBSAN: array-index-out-of-bounds in net/sched/sch_ets.c:93:20 [ 18.853743] index 18446744073709551615 is out of range for type 'ets_class [16]' [ 18.854254] CPU: 0 UID: 0 PID: 1275 Comm: poc Not tainted 6.12.6-dirty #17 [ 18.854821] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 18.856532] Call Trace: [ 18.857441] <TASK> [ 18.858227] dump_stack_lvl+0xc2/0xf0 [ 18.859607] dump_stack+0x10/0x20 [ 18.860908] __ubsan_handle_out_of_bounds+0xa7/0xf0 [ 18.864022] ets_class_change+0x3d6/0x3f0 [ 18.864322] tc_ctl_tclass+0x251/0x910 [ 18.864587] ? lock_acquire+0x5e/0x140 [ 18.865113] ? __mutex_lock+0x9c/0xe70 [ 18.866009] ? __mutex_lock+0xa34/0xe70 [ 18.866401] rtnetlink_rcv_msg+0x170/0x6f0 [ 18.866806] ? __lock_acquire+0x578/0xc10 [ 18.867184] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 [ 18.867503] netlink_rcv_skb+0x59/0x110 [ 18.867776] rtnetlink_rcv+0x15/0x30 [ 18.868159] netlink_unicast+0x1c3/0x2b0 [ 18.868440] netlink_sendmsg+0x239/0x4b0 [ 18.868721] ____sys_sendmsg+0x3e2/0x410 [ 18.869012] ___sys_sendmsg+0x88/0xe0 [ 18.869276] ? rseq_ip_fixup+0x198/0x260 [ 18.869563] ? rseq_update_cpu_node_id+0x10a/0x190 [ 18.869900] ? trace_hardirqs_off+0x5a/0xd0 [ 18.870196] ? syscall_exit_to_user_mode+0xcc/0x220 [ 18.870547] ? do_syscall_64+0x93/0x150 [ 18.870821] ? __memcg_slab_free_hook+0x69/0x290 [ 18.871157] __sys_sendmsg+0x69/0xd0 [ 18.871416] __x64_sys_sendmsg+0x1d/0x30 [ 18.871699] x64_sys_call+0x9e2/0x2670 [ 18.871979] do_syscall_64+0x87/0x150 [ 18.873280] ? do_syscall_64+0x93/0x150 [ 18.874742] ? lock_release+0x7b/0x160 [ 18.876157] ? do_user_addr_fault+0x5ce/0x8f0 [ 18.877833] ? irqentry_exit_to_user_mode+0xc2/0x210 [ 18.879608] ? irqentry_exit+0x77/0xb0 [ 18.879808] ? clear_bhb_loop+0x15/0x70 [ 18.880023] ? clear_bhb_loop+0x15/0x70 [ 18.880223] ? clear_bhb_loop+0x15/0x70 [ 18.880426] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 18.880683] RIP: 0033:0x44a957 [ 18.880851] Code: ff ff e8 fc 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 8974 24 10 [ 18.881766] RSP: 002b:00007ffcdd00fad8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e [ 18.882149] RAX: ffffffffffffffda RBX: 00007ffcdd010db8 RCX: 000000000044a957 [ 18.882507] RDX: 0000000000000000 RSI: 00007ffcdd00fb70 RDI: 0000000000000003 [ 18.885037] RBP: 00007ffcdd010bc0 R08: 000000000703c770 R09: 000000000703c7c0 [ 18.887203] R10: 0000000000000080 R11: 0000000000000246 R12: 0000000000000001 [ 18.888026] R13: 00007ffcdd010da8 R14: 00000000004ca7d0 R15: 0000000000000001 [ 18.888395] </TASK> [ 18.888610] ---[ end trace ]--- CVE-2025-21692 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: mm: zswap: properly synchronize freeing resources during CPU hotunplug In zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx of the current CPU at the beginning of the operation is retrieved and used throughout. However, since neither preemption nor migration are disabled, it is possible that the operation continues on a different CPU. If the original CPU is hotunplugged while the acomp_ctx is still in use, we run into a UAF bug as some of the resources attached to the acomp_ctx are freed during hotunplug in zswap_cpu_comp_dead() (i.e. acomp_ctx.buffer, acomp_ctx.req, or acomp_ctx.acomp). The problem was introduced in commit 1ec3b5fe6eec ("mm/zswap: move to use crypto_acomp API for hardware acceleration") when the switch to the crypto_acomp API was made. Prior to that, the per-CPU crypto_comp was retrieved using get_cpu_ptr() which disables preemption and makes sure the CPU cannot go away from under us. Preemption cannot be disabled with the crypto_acomp API as a sleepable context is needed. Use the acomp_ctx.mutex to synchronize CPU hotplug callbacks allocating and freeing resources with compression/decompression paths. Make sure that acomp_ctx.req is NULL when the resources are freed. In the compression/decompression paths, check if acomp_ctx.req is NULL after acquiring the mutex (meaning the CPU was offlined) and retry on the new CPU. The initialization of acomp_ctx.mutex is moved from the CPU hotplug callback to the pool initialization where it belongs (where the mutex is allocated). In addition to adding clarity, this makes sure that CPU hotplug cannot reinitialize a mutex that is already locked by compression/decompression. Previously a fix was attempted by holding cpus_read_lock() [1]. This would have caused a potential deadlock as it is possible for code already holding the lock to fall into reclaim and enter zswap (causing a deadlock). A fix was also attempted using SRCU for synchronization, but Johannes pointed out that synchronize_srcu() cannot be used in CPU hotplug notifiers [2]. Alternative fixes that were considered/attempted and could have worked: - Refcounting the per-CPU acomp_ctx. This involves complexity in handling the race between the refcount dropping to zero in zswap_[de]compress() and the refcount being re-initialized when the CPU is onlined. - Disabling migration before getting the per-CPU acomp_ctx [3], but that's discouraged and is a much bigger hammer than needed, and could result in subtle performance issues. [1]https://lkml.kernel.org/20241219212437.2714151-1-yosryahmed@google.com/ [2]https://lkml.kernel.org/20250107074724.1756696-2-yosryahmed@google.com/ [3]https://lkml.kernel.org/20250107222236.2715883-2-yosryahmed@google.com/ [yosryahmed@google.com: remove comment] CVE-2025-21693 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: gfs2: Truncate address space when flipping GFS2_DIF_JDATA flag Truncate an inode's address space when flipping the GFS2_DIF_JDATA flag: depending on that flag, the pages in the address space will either use buffer heads or iomap_folio_state structs, and we cannot mix the two. CVE-2025-21699 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix implicit ODP use after free Prevent double queueing of implicit ODP mr destroy work by using __xa_cmpxchg() to make sure this is the only time we are destroying this specific mr. Without this change, we could try to invalidate this mr twice, which in turn could result in queuing a MR work destroy twice, and eventually the second work could execute after the MR was freed due to the first work, causing a user after free and trace below. refcount_t: underflow; use-after-free. WARNING: CPU: 2 PID: 12178 at lib/refcount.c:28 refcount_warn_saturate+0x12b/0x130 Modules linked in: bonding ib_ipoib vfio_pci ip_gre geneve nf_tables ip6_gre gre ip6_tunnel tunnel6 ipip tunnel4 ib_umad rdma_ucm mlx5_vfio_pci vfio_pci_core vfio_iommu_type1 mlx5_ib vfio ib_uverbs mlx5_core iptable_raw openvswitch nsh rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay zram zsmalloc fuse [last unloaded: ib_uverbs] CPU: 2 PID: 12178 Comm: kworker/u20:5 Not tainted 6.5.0-rc1_net_next_mlx5_58c644e #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: events_unbound free_implicit_child_mr_work [mlx5_ib] RIP: 0010:refcount_warn_saturate+0x12b/0x130 Code: 48 c7 c7 38 95 2a 82 c6 05 bc c6 fe 00 01 e8 0c 66 aa ff 0f 0b 5b c3 48 c7 c7 e0 94 2a 82 c6 05 a7 c6 fe 00 01 e8 f5 65 aa ff <0f> 0b 5b c3 90 8b 07 3d 00 00 00 c0 74 12 83 f8 01 74 13 8d 50 ff RSP: 0018:ffff8881008e3e40 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000027 RDX: ffff88852c91b5c8 RSI: 0000000000000001 RDI: ffff88852c91b5c0 RBP: ffff8881dacd4e00 R08: 00000000ffffffff R09: 0000000000000019 R10: 000000000000072e R11: 0000000063666572 R12: ffff88812bfd9e00 R13: ffff8881c792d200 R14: ffff88810011c005 R15: ffff8881002099c0 FS: 0000000000000000(0000) GS:ffff88852c900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5694b5e000 CR3: 00000001153f6003 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? refcount_warn_saturate+0x12b/0x130 free_implicit_child_mr_work+0x180/0x1b0 [mlx5_ib] process_one_work+0x1cc/0x3c0 worker_thread+0x218/0x3c0 kthread+0xc6/0xf0 ret_from_fork+0x1f/0x30 </TASK> CVE-2025-21714 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: rose: fix timer races against user threads Rose timers only acquire the socket spinlock, without checking if the socket is owned by one user thread. Add a check and rearm the timers if needed. BUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 Read of size 2 at addr ffff88802f09b82a by task swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 call_timer_fn+0x187/0x650 kernel/time/timer.c:1793 expire_timers kernel/time/timer.c:1844 [inline] __run_timers kernel/time/timer.c:2418 [inline] __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430 run_timer_base kernel/time/timer.c:2439 [inline] run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049 </IRQ> CVE-2025-21718 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: padata: avoid UAF for reorder_work Although the previous patch can avoid ps and ps UAF for _do_serial, it can not avoid potential UAF issue for reorder_work. This issue can happen just as below: crypto_request crypto_request crypto_del_alg padata_do_serial ... padata_reorder // processes all remaining // requests then breaks while (1) { if (!padata) break; ... } padata_do_serial // new request added list_add // sees the new request queue_work(reorder_work) padata_reorder queue_work_on(squeue->work) ... <kworker context> padata_serial_worker // completes new request, // no more outstanding // requests crypto_del_alg // free pd <kworker context> invoke_padata_reorder // UAF of pd To avoid UAF for 'reorder_work', get 'pd' ref before put 'reorder_work' into the 'serial_wq' and put 'pd' ref until the 'serial_wq' finish. CVE-2025-21726 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix a race for an ODP MR which leads to CQE with error This patch addresses a race condition for an ODP MR that can result in a CQE with an error on the UMR QP. During the __mlx5_ib_dereg_mr() flow, the following sequence of calls occurs: mlx5_revoke_mr() mlx5r_umr_revoke_mr() mlx5r_umr_post_send_wait() At this point, the lkey is freed from the hardware's perspective. However, concurrently, mlx5_ib_invalidate_range() might be triggered by another task attempting to invalidate a range for the same freed lkey. This task will: - Acquire the umem_odp->umem_mutex lock. - Call mlx5r_umr_update_xlt() on the UMR QP. - Since the lkey has already been freed, this can lead to a CQE error, causing the UMR QP to enter an error state [1]. To resolve this race condition, the umem_odp->umem_mutex lock is now also acquired as part of the mlx5_revoke_mr() scope. Upon successful revoke, we set umem_odp->private which points to that MR to NULL, preventing any further invalidation attempts on its lkey. [1] From dmesg: infiniband rocep8s0f0: dump_cqe:277:(pid 0): WC error: 6, Message: memory bind operation error cqe_dump: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000030: 00 00 00 00 08 00 78 06 25 00 11 b9 00 0e dd d2 WARNING: CPU: 15 PID: 1506 at drivers/infiniband/hw/mlx5/umr.c:394 mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib] Modules linked in: ip6table_mangle ip6table_natip6table_filter ip6_tables iptable_mangle xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm mlx5_ib ib_uverbs ib_core fuse mlx5_core CPU: 15 UID: 0 PID: 1506 Comm: ibv_rc_pingpong Not tainted 6.12.0-rc7+ #1626 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib] [..] Call Trace: <TASK> mlx5r_umr_update_xlt+0x23c/0x3e0 [mlx5_ib] mlx5_ib_invalidate_range+0x2e1/0x330 [mlx5_ib] __mmu_notifier_invalidate_range_start+0x1e1/0x240 zap_page_range_single+0xf1/0x1a0 madvise_vma_behavior+0x677/0x6e0 do_madvise+0x1a2/0x4b0 __x64_sys_madvise+0x25/0x30 do_syscall_64+0x6b/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e CVE-2025-21732 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free when attempting to join an aborted transaction When we are trying to join the current transaction and if it's aborted, we read its 'aborted' field after unlocking fs_info->trans_lock and without holding any extra reference count on it. This means that a concurrent task that is aborting the transaction may free the transaction before we read its 'aborted' field, leading to a use-after-free. Fix this by reading the 'aborted' field while holding fs_info->trans_lock since any freeing task must first acquire that lock and set fs_info->running_transaction to NULL before freeing the transaction. This was reported by syzbot and Dmitry with the following stack traces from KASAN: ================================================================== BUG: KASAN: slab-use-after-free in join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 Read of size 4 at addr ffff888011839024 by task kworker/u4:9/1128 CPU: 0 UID: 0 PID: 1128 Comm: kworker/u4:9 Not tainted 6.13.0-rc7-syzkaller-00019-gc45323b7560e #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: events_unbound btrfs_async_reclaim_data_space Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 flush_space+0x448/0xcf0 fs/btrfs/space-info.c:803 btrfs_async_reclaim_data_space+0x159/0x510 fs/btrfs/space-info.c:1321 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317 worker_thread+0x870/0xd30 kernel/workqueue.c:3398 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Allocated by task 5315: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329 kmalloc_noprof include/linux/slab.h:901 [inline] join_transaction+0x144/0xda0 fs/btrfs/transaction.c:308 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 btrfs_create_common+0x1b2/0x2e0 fs/btrfs/inode.c:6572 lookup_open fs/namei.c:3649 [inline] open_last_lookups fs/namei.c:3748 [inline] path_openat+0x1c03/0x3590 fs/namei.c:3984 do_filp_open+0x27f/0x4e0 fs/namei.c:4014 do_sys_openat2+0x13e/0x1d0 fs/open.c:1402 do_sys_open fs/open.c:1417 [inline] __do_sys_creat fs/open.c:1495 [inline] __se_sys_creat fs/open.c:1489 [inline] __x64_sys_creat+0x123/0x170 fs/open.c:1489 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 5336: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4613 [inline] kfree+0x196/0x430 mm/slub.c:4761 cleanup_transaction fs/btrfs/transaction.c:2063 [inline] btrfs_commit_transaction+0x2c97/0x3720 fs/btrfs/transaction.c:2598 insert_balance_item+0x1284/0x20b0 fs/btrfs/volumes.c:3757 btrfs_balance+0x992/ ---truncated--- CVE-2025-21753 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: partitions: mac: fix handling of bogus partition table Fix several issues in partition probing: - The bailout for a bad partoffset must use put_dev_sector(), since the preceding read_part_sector() succeeded. - If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory. - We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp(). CVE-2025-21772 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: avoid buffer overflow attach in smu_sys_set_pp_table() It malicious user provides a small pptable through sysfs and then a bigger pptable, it may cause buffer overflow attack in function smu_sys_set_pp_table(). CVE-2025-21780 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array The loop that detects/populates cache information already has a bounds check on the array size but does not account for cache levels with separate data/instructions cache. Fix this by incrementing the index for any populated leaf (instead of any populated level). CVE-2025-21785 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: vrf: use RCU protection in l3mdev_l3_out() l3mdev_l3_out() can be called without RCU being held: raw_sendmsg() ip_push_pending_frames() ip_send_skb() ip_local_out() __ip_local_out() l3mdev_ip_out() Add rcu_read_lock() / rcu_read_unlock() pair to avoid a potential UAF. CVE-2025-21791 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: ax25: rcu protect dev->ax25_ptr syzbot found a lockdep issue [1]. We should remove ax25 RTNL dependency in ax25_setsockopt() This should also fix a variety of possible UAF in ax25. [1] WARNING: possible circular locking dependency detected 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted ------------------------------------------------------ syz.5.1818/12806 is trying to acquire lock: ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 but task is already holding lock: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (sk_lock-AF_AX25){+.+.}-{0:0}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 lock_sock_nested+0x48/0x100 net/core/sock.c:3642 lock_sock include/net/sock.h:1618 [inline] ax25_kill_by_device net/ax25/af_ax25.c:101 [inline] ax25_device_event+0x24d/0x580 net/ax25/af_ax25.c:146 notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85 __dev_notify_flags+0x207/0x400 dev_change_flags+0xf0/0x1a0 net/core/dev.c:9026 dev_ifsioc+0x7c8/0xe70 net/core/dev_ioctl.c:563 dev_ioctl+0x719/0x1340 net/core/dev_ioctl.c:820 sock_do_ioctl+0x240/0x460 net/socket.c:1234 sock_ioctl+0x626/0x8e0 net/socket.c:1339 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (rtnl_mutex){+.+.}-{4:4}: check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/locking/lockdep.c:3280 [inline] validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904 __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735 ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 do_sock_setsockopt+0x3af/0x720 net/socket.c:2324 __sys_setsockopt net/socket.c:2349 [inline] __do_sys_setsockopt net/socket.c:2355 [inline] __se_sys_setsockopt net/socket.c:2352 [inline] __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sk_lock-AF_AX25); lock(rtnl_mutex); lock(sk_lock-AF_AX25); lock(rtnl_mutex); *** DEADLOCK *** 1 lock held by syz.5.1818/12806: #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574 stack backtrace: CPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074 check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206 check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/lockin ---truncated--- CVE-2025-21812 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Load DR6 with guest value only before entering .vcpu_run() loop Move the conditional loading of hardware DR6 with the guest's DR6 value out of the core .vcpu_run() loop to fix a bug where KVM can load hardware with a stale vcpu->arch.dr6. When the guest accesses a DR and host userspace isn't debugging the guest, KVM disables DR interception and loads the guest's values into hardware on VM-Enter and saves them on VM-Exit. This allows the guest to access DRs at will, e.g. so that a sequence of DR accesses to configure a breakpoint only generates one VM-Exit. For DR0-DR3, the logic/behavior is identical between VMX and SVM, and also identical between KVM_DEBUGREG_BP_ENABLED (userspace debugging the guest) and KVM_DEBUGREG_WONT_EXIT (guest using DRs), and so KVM handles loading DR0-DR3 in common code, _outside_ of the core kvm_x86_ops.vcpu_run() loop. But for DR6, the guest's value doesn't need to be loaded into hardware for KVM_DEBUGREG_BP_ENABLED, and SVM provides a dedicated VMCB field whereas VMX requires software to manually load the guest value, and so loading the guest's value into DR6 is handled by {svm,vmx}_vcpu_run(), i.e. is done _inside_ the core run loop. Unfortunately, saving the guest values on VM-Exit is initiated by common x86, again outside of the core run loop. If the guest modifies DR6 (in hardware, when DR interception is disabled), and then the next VM-Exit is a fastpath VM-Exit, KVM will reload hardware DR6 with vcpu->arch.dr6 and clobber the guest's actual value. The bug shows up primarily with nested VMX because KVM handles the VMX preemption timer in the fastpath, and the window between hardware DR6 being modified (in guest context) and DR6 being read by guest software is orders of magnitude larger in a nested setup. E.g. in non-nested, the VMX preemption timer would need to fire precisely between #DB injection and the #DB handler's read of DR6, whereas with a KVM-on-KVM setup, the window where hardware DR6 is "dirty" extends all the way from L1 writing DR6 to VMRESUME (in L1). L1's view: ========== <L1 disables DR interception> CPU 0/KVM-7289 [023] d.... 2925.640961: kvm_entry: vcpu 0 A: L1 Writes DR6 CPU 0/KVM-7289 [023] d.... 2925.640963: <hack>: Set DRs, DR6 = 0xffff0ff1 B: CPU 0/KVM-7289 [023] d.... 2925.640967: kvm_exit: vcpu 0 reason EXTERNAL_INTERRUPT intr_info 0x800000ec D: L1 reads DR6, arch.dr6 = 0 CPU 0/KVM-7289 [023] d.... 2925.640969: <hack>: Sync DRs, DR6 = 0xffff0ff0 CPU 0/KVM-7289 [023] d.... 2925.640976: kvm_entry: vcpu 0 L2 reads DR6, L1 disables DR interception CPU 0/KVM-7289 [023] d.... 2925.640980: kvm_exit: vcpu 0 reason DR_ACCESS info1 0x0000000000000216 CPU 0/KVM-7289 [023] d.... 2925.640983: kvm_entry: vcpu 0 CPU 0/KVM-7289 [023] d.... 2925.640983: <hack>: Set DRs, DR6 = 0xffff0ff0 L2 detects failure CPU 0/KVM-7289 [023] d.... 2925.640987: kvm_exit: vcpu 0 reason HLT L1 reads DR6 (confirms failure) CPU 0/KVM-7289 [023] d.... 2925.640990: <hack>: Sync DRs, DR6 = 0xffff0ff0 L0's view: ========== L2 reads DR6, arch.dr6 = 0 CPU 23/KVM-5046 [001] d.... 3410.005610: kvm_exit: vcpu 23 reason DR_ACCESS info1 0x0000000000000216 CPU 23/KVM-5046 [001] ..... 3410.005610: kvm_nested_vmexit: vcpu 23 reason DR_ACCESS info1 0x0000000000000216 L2 => L1 nested VM-Exit CPU 23/KVM-5046 [001] ..... 3410.005610: kvm_nested_vmexit_inject: reason: DR_ACCESS ext_inf1: 0x0000000000000216 CPU 23/KVM-5046 [001] d.... 3410.005610: kvm_entry: vcpu 23 CPU 23/KVM-5046 [001] d.... 3410.005611: kvm_exit: vcpu 23 reason VMREAD CPU 23/KVM-5046 [001] d.... 3410.005611: kvm_entry: vcpu 23 CPU 23/KVM-5046 [001] d.... 3410. ---truncated--- CVE-2025-21839 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix implicit ODP hang on parent deregistration Fix the destroy_unused_implicit_child_mr() to prevent hanging during parent deregistration as of below [1]. Upon entering destroy_unused_implicit_child_mr(), the reference count for the implicit MR parent is incremented using: refcount_inc_not_zero(). A corresponding decrement must be performed if free_implicit_child_mr_work() is not called. The code has been updated to properly manage the reference count that was incremented. [1] INFO: task python3:2157 blocked for more than 120 seconds. Not tainted 6.12.0-rc7+ #1633 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:python3 state:D stack:0 pid:2157 tgid:2157 ppid:1685 flags:0x00000000 Call Trace: <TASK> __schedule+0x420/0xd30 schedule+0x47/0x130 __mlx5_ib_dereg_mr+0x379/0x5d0 [mlx5_ib] ? __pfx_autoremove_wake_function+0x10/0x10 ib_dereg_mr_user+0x5f/0x120 [ib_core] ? lock_release+0xc6/0x280 destroy_hw_idr_uobject+0x1d/0x60 [ib_uverbs] uverbs_destroy_uobject+0x58/0x1d0 [ib_uverbs] uobj_destroy+0x3f/0x70 [ib_uverbs] ib_uverbs_cmd_verbs+0x3e4/0xbb0 [ib_uverbs] ? __pfx_uverbs_destroy_def_handler+0x10/0x10 [ib_uverbs] ? lock_acquire+0xc1/0x2f0 ? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs] ? ib_uverbs_ioctl+0x116/0x170 [ib_uverbs] ? lock_release+0xc6/0x280 ib_uverbs_ioctl+0xe7/0x170 [ib_uverbs] ? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs] __x64_sys_ioctl+0x1b0/0xa70 ? kmem_cache_free+0x221/0x400 do_syscall_64+0x6b/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f20f21f017b RSP: 002b:00007ffcfc4a77c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffcfc4a78d8 RCX: 00007f20f21f017b RDX: 00007ffcfc4a78c0 RSI: 00000000c0181b01 RDI: 0000000000000003 RBP: 00007ffcfc4a78a0 R08: 000056147d125190 R09: 00007f20f1f14c60 R10: 0000000000000001 R11: 0000000000000246 R12: 00007ffcfc4a7890 R13: 000000000000001c R14: 000056147d100fc0 R15: 00007f20e365c9d0 </TASK> CVE-2025-21886 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix a WARN during dereg_mr for DM type Memory regions (MR) of type DM (device memory) do not have an associated umem. In the __mlx5_ib_dereg_mr() -> mlx5_free_priv_descs() flow, the code incorrectly takes the wrong branch, attempting to call dma_unmap_single() on a DMA address that is not mapped. This results in a WARN [1], as shown below. The issue is resolved by properly accounting for the DM type and ensuring the correct branch is selected in mlx5_free_priv_descs(). [1] WARNING: CPU: 12 PID: 1346 at drivers/iommu/dma-iommu.c:1230 iommu_dma_unmap_page+0x79/0x90 Modules linked in: ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry ovelay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core fuse mlx5_core CPU: 12 UID: 0 PID: 1346 Comm: ibv_rc_pingpong Not tainted 6.12.0-rc7+ #1631 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:iommu_dma_unmap_page+0x79/0x90 Code: 2b 49 3b 29 72 26 49 3b 69 08 73 20 4d 89 f0 44 89 e9 4c 89 e2 48 89 ee 48 89 df 5b 5d 41 5c 41 5d 41 5e 41 5f e9 07 b8 88 ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 66 0f 1f 44 00 RSP: 0018:ffffc90001913a10 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810194b0a8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001 RBP: ffff88810194b0a8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f537abdd740(0000) GS:ffff88885fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f537aeb8000 CR3: 000000010c248001 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __warn+0x84/0x190 ? iommu_dma_unmap_page+0x79/0x90 ? report_bug+0xf8/0x1c0 ? handle_bug+0x55/0x90 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? iommu_dma_unmap_page+0x79/0x90 dma_unmap_page_attrs+0xe6/0x290 mlx5_free_priv_descs+0xb0/0xe0 [mlx5_ib] __mlx5_ib_dereg_mr+0x37e/0x520 [mlx5_ib] ? _raw_spin_unlock_irq+0x24/0x40 ? wait_for_completion+0xfe/0x130 ? rdma_restrack_put+0x63/0xe0 [ib_core] ib_dereg_mr_user+0x5f/0x120 [ib_core] ? lock_release+0xc6/0x280 destroy_hw_idr_uobject+0x1d/0x60 [ib_uverbs] uverbs_destroy_uobject+0x58/0x1d0 [ib_uverbs] uobj_destroy+0x3f/0x70 [ib_uverbs] ib_uverbs_cmd_verbs+0x3e4/0xbb0 [ib_uverbs] ? __pfx_uverbs_destroy_def_handler+0x10/0x10 [ib_uverbs] ? lock_acquire+0xc1/0x2f0 ? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs] ? ib_uverbs_ioctl+0x116/0x170 [ib_uverbs] ? lock_release+0xc6/0x280 ib_uverbs_ioctl+0xe7/0x170 [ib_uverbs] ? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs] __x64_sys_ioctl+0x1b0/0xa70 do_syscall_64+0x6b/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f537adaf17b Code: 0f 1e fa 48 8b 05 1d ad 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ed ac 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffff218f0b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffff218f1d8 RCX: 00007f537adaf17b RDX: 00007ffff218f1c0 RSI: 00000000c0181b01 RDI: 0000000000000003 RBP: 00007ffff218f1a0 R08: 00007f537aa8d010 R09: 0000561ee2e4f270 R10: 00007f537aace3a8 R11: 0000000000000246 R12: 00007ffff218f190 R13: 000000000000001c R14: 0000561ee2e4d7c0 R15: 00007ffff218f450 </TASK> CVE-2025-21888 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: proc: fix UAF in proc_get_inode() Fix race between rmmod and /proc/XXX's inode instantiation. The bug is that pde->proc_ops don't belong to /proc, it belongs to a module, therefore dereferencing it after /proc entry has been registered is a bug unless use_pde/unuse_pde() pair has been used. use_pde/unuse_pde can be avoided (2 atomic ops!) because pde->proc_ops never changes so information necessary for inode instantiation can be saved _before_ proc_register() in PDE itself and used later, avoiding pde->proc_ops->... dereference. rmmod lookup sys_delete_module proc_lookup_de pde_get(de); proc_get_inode(dir->i_sb, de); mod->exit() proc_remove remove_proc_subtree proc_entry_rundown(de); free_module(mod); if (S_ISREG(inode->i_mode)) if (de->proc_ops->proc_read_iter) --> As module is already freed, will trigger UAF BUG: unable to handle page fault for address: fffffbfff80a702b PGD 817fc4067 P4D 817fc4067 PUD 817fc0067 PMD 102ef4067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 26 UID: 0 PID: 2667 Comm: ls Tainted: G Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:proc_get_inode+0x302/0x6e0 RSP: 0018:ffff88811c837998 EFLAGS: 00010a06 RAX: dffffc0000000000 RBX: ffffffffc0538140 RCX: 0000000000000007 RDX: 1ffffffff80a702b RSI: 0000000000000001 RDI: ffffffffc0538158 RBP: ffff8881299a6000 R08: 0000000067bbe1e5 R09: 1ffff11023906f20 R10: ffffffffb560ca07 R11: ffffffffb2b43a58 R12: ffff888105bb78f0 R13: ffff888100518048 R14: ffff8881299a6004 R15: 0000000000000001 FS: 00007f95b9686840(0000) GS:ffff8883af100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffbfff80a702b CR3: 0000000117dd2000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> proc_lookup_de+0x11f/0x2e0 __lookup_slow+0x188/0x350 walk_component+0x2ab/0x4f0 path_lookupat+0x120/0x660 filename_lookup+0x1ce/0x560 vfs_statx+0xac/0x150 __do_sys_newstat+0x96/0x110 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e [adobriyan@gmail.com: don't do 2 atomic ops on the common path] CVE-2025-21999 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: net: atm: fix use after free in lec_send() The ->send() operation frees skb so save the length before calling ->send() to avoid a use after free. CVE-2025-22004 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: memstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove This fixes the following crash: ================================================================== BUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] Read of size 8 at addr ffff888136335380 by task kworker/6:0/140241 CPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1 Tainted: [E]=UNSIGNED_MODULE Hardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024 Workqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms] Call Trace: <TASK> dump_stack_lvl+0x51/0x70 print_address_description.constprop.0+0x27/0x320 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] print_report+0x3e/0x70 kasan_report+0xab/0xe0 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms] ? __pfx___schedule+0x10/0x10 ? kick_pool+0x3b/0x270 process_one_work+0x357/0x660 worker_thread+0x390/0x4c0 ? __pfx_worker_thread+0x10/0x10 kthread+0x190/0x1d0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 161446: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x1a7/0x470 memstick_alloc_host+0x1f/0xe0 [memstick] rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms] platform_probe+0x60/0xe0 call_driver_probe+0x35/0x120 really_probe+0x123/0x410 __driver_probe_device+0xc7/0x1e0 driver_probe_device+0x49/0xf0 __device_attach_driver+0xc6/0x160 bus_for_each_drv+0xe4/0x160 __device_attach+0x13a/0x2b0 bus_probe_device+0xbd/0xd0 device_add+0x4a5/0x760 platform_device_add+0x189/0x370 mfd_add_device+0x587/0x5e0 mfd_add_devices+0xb1/0x130 rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb] usb_probe_interface+0x15c/0x460 call_driver_probe+0x35/0x120 really_probe+0x123/0x410 __driver_probe_device+0xc7/0x1e0 driver_probe_device+0x49/0xf0 __device_attach_driver+0xc6/0x160 bus_for_each_drv+0xe4/0x160 __device_attach+0x13a/0x2b0 rebind_marked_interfaces.isra.0+0xcc/0x110 usb_reset_device+0x352/0x410 usbdev_do_ioctl+0xe5c/0x1860 usbdev_ioctl+0xa/0x20 __x64_sys_ioctl+0xc5/0xf0 do_syscall_64+0x59/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 161506: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x36/0x60 __kasan_slab_free+0x34/0x50 kfree+0x1fd/0x3b0 device_release+0x56/0xf0 kobject_cleanup+0x73/0x1c0 rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms] platform_remove+0x2f/0x50 device_release_driver_internal+0x24b/0x2e0 bus_remove_device+0x124/0x1d0 device_del+0x239/0x530 platform_device_del.part.0+0x19/0xe0 platform_device_unregister+0x1c/0x40 mfd_remove_devices_fn+0x167/0x170 device_for_each_child_reverse+0xc9/0x130 mfd_remove_devices+0x6e/0xa0 rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb] usb_unbind_interface+0xf3/0x3f0 device_release_driver_internal+0x24b/0x2e0 proc_disconnect_claim+0x13d/0x220 usbdev_do_ioctl+0xb5e/0x1860 usbdev_ioctl+0xa/0x20 __x64_sys_ioctl+0xc5/0xf0 do_syscall_64+0x59/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Last potentially related work creation: kasan_save_stack+0x20/0x40 kasan_record_aux_stack+0x85/0x90 insert_work+0x29/0x100 __queue_work+0x34a/0x540 call_timer_fn+0x2a/0x160 expire_timers+0x5f/0x1f0 __run_timer_base.part.0+0x1b6/0x1e0 run_timer_softirq+0x8b/0xe0 handle_softirqs+0xf9/0x360 __irq_exit_rcu+0x114/0x130 sysvec_apic_timer_interrupt+0x72/0x90 asm_sysvec_apic_timer_interrupt+0x16/0x20 Second to last potentially related work creation: kasan_save_stack+0x20/0x40 kasan_record_aux_stack+0x85/0x90 insert_work+0x29/0x100 __queue_work+0x34a/0x540 call_timer_fn+0x2a/0x160 expire_timers+0x5f/0x1f0 __run_timer_base.part.0+0x1b6/0x1e0 run_timer_softirq+0x8b/0xe0 handle_softirqs+0xf9/0x ---truncated--- CVE-2025-22020 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. CVE-2025-22029 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: x86/mm: Fix flush_tlb_range() when used for zapping normal PMDs On the following path, flush_tlb_range() can be used for zapping normal PMD entries (PMD entries that point to page tables) together with the PTE entries in the pointed-to page table: collapse_pte_mapped_thp pmdp_collapse_flush flush_tlb_range The arm64 version of flush_tlb_range() has a comment describing that it can be used for page table removal, and does not use any last-level invalidation optimizations. Fix the X86 version by making it behave the same way. Currently, X86 only uses this information for the following two purposes, which I think means the issue doesn't have much impact: - In native_flush_tlb_multi() for checking if lazy TLB CPUs need to be IPI'd to avoid issues with speculative page table walks. - In Hyper-V TLB paravirtualization, again for lazy TLB stuff. The patch "x86/mm: only invalidate final translations with INVLPGB" which is currently under review (see <https://lore.kernel.org/all/20241230175550.4046587-13-riel@surriel.com/>) would probably be making the impact of this a lot worse. CVE-2025-22045 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: fix geneve_opt length integer overflow struct geneve_opt uses 5 bit length for each single option, which means every vary size option should be smaller than 128 bytes. However, all current related Netlink policies cannot promise this length condition and the attacker can exploit a exact 128-byte size option to *fake* a zero length option and confuse the parsing logic, further achieve heap out-of-bounds read. One example crash log is like below: [ 3.905425] ================================================================== [ 3.905925] BUG: KASAN: slab-out-of-bounds in nla_put+0xa9/0xe0 [ 3.906255] Read of size 124 at addr ffff888005f291cc by task poc/177 [ 3.906646] [ 3.906775] CPU: 0 PID: 177 Comm: poc-oob-read Not tainted 6.1.132 #1 [ 3.907131] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 3.907784] Call Trace: [ 3.907925] <TASK> [ 3.908048] dump_stack_lvl+0x44/0x5c [ 3.908258] print_report+0x184/0x4be [ 3.909151] kasan_report+0xc5/0x100 [ 3.909539] kasan_check_range+0xf3/0x1a0 [ 3.909794] memcpy+0x1f/0x60 [ 3.909968] nla_put+0xa9/0xe0 [ 3.910147] tunnel_key_dump+0x945/0xba0 [ 3.911536] tcf_action_dump_1+0x1c1/0x340 [ 3.912436] tcf_action_dump+0x101/0x180 [ 3.912689] tcf_exts_dump+0x164/0x1e0 [ 3.912905] fw_dump+0x18b/0x2d0 [ 3.913483] tcf_fill_node+0x2ee/0x460 [ 3.914778] tfilter_notify+0xf4/0x180 [ 3.915208] tc_new_tfilter+0xd51/0x10d0 [ 3.918615] rtnetlink_rcv_msg+0x4a2/0x560 [ 3.919118] netlink_rcv_skb+0xcd/0x200 [ 3.919787] netlink_unicast+0x395/0x530 [ 3.921032] netlink_sendmsg+0x3d0/0x6d0 [ 3.921987] __sock_sendmsg+0x99/0xa0 [ 3.922220] __sys_sendto+0x1b7/0x240 [ 3.922682] __x64_sys_sendto+0x72/0x90 [ 3.922906] do_syscall_64+0x5e/0x90 [ 3.923814] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 3.924122] RIP: 0033:0x7e83eab84407 [ 3.924331] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 3.925330] RSP: 002b:00007ffff505e370 EFLAGS: 00000202 ORIG_RAX: 000000000000002c [ 3.925752] RAX: ffffffffffffffda RBX: 00007e83eaafa740 RCX: 00007e83eab84407 [ 3.926173] RDX: 00000000000001a8 RSI: 00007ffff505e3c0 RDI: 0000000000000003 [ 3.926587] RBP: 00007ffff505f460 R08: 00007e83eace1000 R09: 000000000000000c [ 3.926977] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffff505f3c0 [ 3.927367] R13: 00007ffff505f5c8 R14: 00007e83ead1b000 R15: 00005d4fbbe6dcb8 Fix these issues by enforing correct length condition in related policies. CVE-2025-22055 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_tunnel: fix geneve_opt type confusion addition When handling multiple NFTA_TUNNEL_KEY_OPTS_GENEVE attributes, the parsing logic should place every geneve_opt structure one by one compactly. Hence, when deciding the next geneve_opt position, the pointer addition should be in units of char *. However, the current implementation erroneously does type conversion before the addition, which will lead to heap out-of-bounds write. [ 6.989857] ================================================================== [ 6.990293] BUG: KASAN: slab-out-of-bounds in nft_tunnel_obj_init+0x977/0xa70 [ 6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178 [ 6.991162] [ 6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1 [ 6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 6.992281] Call Trace: [ 6.992423] <TASK> [ 6.992586] dump_stack_lvl+0x44/0x5c [ 6.992801] print_report+0x184/0x4be [ 6.993790] kasan_report+0xc5/0x100 [ 6.994252] kasan_check_range+0xf3/0x1a0 [ 6.994486] memcpy+0x38/0x60 [ 6.994692] nft_tunnel_obj_init+0x977/0xa70 [ 6.995677] nft_obj_init+0x10c/0x1b0 [ 6.995891] nf_tables_newobj+0x585/0x950 [ 6.996922] nfnetlink_rcv_batch+0xdf9/0x1020 [ 6.998997] nfnetlink_rcv+0x1df/0x220 [ 6.999537] netlink_unicast+0x395/0x530 [ 7.000771] netlink_sendmsg+0x3d0/0x6d0 [ 7.001462] __sock_sendmsg+0x99/0xa0 [ 7.001707] ____sys_sendmsg+0x409/0x450 [ 7.002391] ___sys_sendmsg+0xfd/0x170 [ 7.003145] __sys_sendmsg+0xea/0x170 [ 7.004359] do_syscall_64+0x5e/0x90 [ 7.005817] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 7.006127] RIP: 0033:0x7ec756d4e407 [ 7.006339] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIG_RAX: 000000000000002e [ 7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407 [ 7.008223] RDX: 0000000000000000 RSI: 00007ffed5d467f0 RDI: 0000000000000003 [ 7.008620] RBP: 00007ffed5d468a0 R08: 0000000000000000 R09: 0000000000000000 [ 7.009039] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 [ 7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8 Fix this bug with correct pointer addition and conversion in parse and dump code. CVE-2025-22056 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: Prevent parser TCAM memory corruption Protect the parser TCAM/SRAM memory, and the cached (shadow) SRAM information, from concurrent modifications. Both the TCAM and SRAM tables are indirectly accessed by configuring an index register that selects the row to read or write to. This means that operations must be atomic in order to, e.g., avoid spreading writes across multiple rows. Since the shadow SRAM array is used to find free rows in the hardware table, it must also be protected in order to avoid TOCTOU errors where multiple cores allocate the same row. This issue was detected in a situation where `mvpp2_set_rx_mode()` ran concurrently on two CPUs. In this particular case the MVPP2_PE_MAC_UC_PROMISCUOUS entry was corrupted, causing the classifier unit to drop all incoming unicast - indicated by the `rx_classifier_drops` counter. CVE-2025-22060 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/vkms: Fix use after free and double free on init error If the driver initialization fails, the vkms_exit() function might access an uninitialized or freed default_config pointer and it might double free it. Fix both possible errors by initializing default_config only when the driver initialization succeeded. CVE-2025-22097 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important When switching to other buffers using the :all command and visual mode still being active, this may cause a heap-buffer overflow, because Vim does not properly end visual mode and therefore may try to access beyond the end of a line in a buffer. In Patch 9.1.1003 Vim will correctly reset the visual mode before opening other windows and buffers and therefore fix this bug. In addition it does verify that it won't try to access a position if the position is greater than the corresponding buffer line. Impact is medium since the user must have switched on visual mode when executing the :all ex command. The Vim project would like to thank github user gandalf4a for reporting this issue. The issue has been fixed as of Vim patch v9.1.1003 CVE-2025-22134 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:vim-9.1.1406-150000.5.75.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:vim-data-common-9.1.1406-150000.5.75.1 moderate An attacker can pass a malicious malformed token which causes unexpected memory to be consumed during parsing. CVE-2025-22868 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:docker-28.2.2_ce-150000.227.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:google-guest-agent-20250506.01-150000.1.63.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:google-osconfig-agent-20250416.02-150000.1.50.1 important SSH servers which implement file transfer protocols are vulnerable to a denial of service attack from clients which complete the key exchange slowly, or not at all, causing pending content to be read into memory, but never transmitted. CVE-2025-22869 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:docker-28.2.2_ce-150000.227.1 important The tokenizer incorrectly interprets tags with unquoted attribute values that end with a solidus character (/) as self-closing. When directly using Tokenizer, this can result in such tags incorrectly being marked as self-closing, and when using the Parse functions, this can result in content following such tags as being placed in the wrong scope during DOM construction, but only when tags are in foreign content (e.g. <math>, <svg>, etc contexts). CVE-2025-22872 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:docker-28.2.2_ce-150000.227.1 moderate A flaw was found in cifs-utils. When trying to obtain Kerberos credentials, the cifs.upcall program from the cifs-utils package makes an upcall to the wrong namespace in containerized environments. This issue may lead to disclosing sensitive data from the host's Kerberos credentials cache. CVE-2025-2312 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:cifs-utils-6.15-150400.3.15.1 moderate In the Linux kernel, the following vulnerability has been resolved: watch_queue: fix pipe accounting mismatch Currently, watch_queue_set_size() modifies the pipe buffers charged to user->pipe_bufs without updating the pipe->nr_accounted on the pipe itself, due to the if (!pipe_has_watch_queue()) test in pipe_resize_ring(). This means that when the pipe is ultimately freed, we decrement user->pipe_bufs by something other than what than we had charged to it, potentially leading to an underflow. This in turn can cause subsequent too_many_pipe_buffers_soft() tests to fail with -EPERM. To remedy this, explicitly account for the pipe usage in watch_queue_set_size() to match the number set via account_pipe_buffers() (It's unclear why watch_queue_set_size() does not update nr_accounted; it may be due to intentional overprovisioning in watch_queue_set_size()?) CVE-2025-23138 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: mptcp: fix NULL pointer in can_accept_new_subflow When testing valkey benchmark tool with MPTCP, the kernel panics in 'mptcp_can_accept_new_subflow' because subflow_req->msk is NULL. Call trace: mptcp_can_accept_new_subflow (./net/mptcp/subflow.c:63 (discriminator 4)) (P) subflow_syn_recv_sock (./net/mptcp/subflow.c:854) tcp_check_req (./net/ipv4/tcp_minisocks.c:863) tcp_v4_rcv (./net/ipv4/tcp_ipv4.c:2268) ip_protocol_deliver_rcu (./net/ipv4/ip_input.c:207) ip_local_deliver_finish (./net/ipv4/ip_input.c:234) ip_local_deliver (./net/ipv4/ip_input.c:254) ip_rcv_finish (./net/ipv4/ip_input.c:449) ... According to the debug log, the same req received two SYN-ACK in a very short time, very likely because the client retransmits the syn ack due to multiple reasons. Even if the packets are transmitted with a relevant time interval, they can be processed by the server on different CPUs concurrently). The 'subflow_req->msk' ownership is transferred to the subflow the first, and there will be a risk of a null pointer dereference here. This patch fixes this issue by moving the 'subflow_req->msk' under the `own_req == true` conditional. Note that the !msk check in subflow_hmac_valid() can be dropped, because the same check already exists under the own_req mpj branch where the code has been moved to. CVE-2025-23145 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 important Vim is an open source, command line text editor. A segmentation fault was found in Vim before 9.1.1043. In silent Ex mode (-s -e), Vim typically doesn't show a screen and just operates silently in batch mode. However, it is still possible to trigger the function that handles the scrolling of a gui version of Vim by feeding some binary characters to Vim. The function that handles the scrolling however may be triggering a redraw, which will access the ScreenLines pointer, even so this variable hasn't been allocated (since there is no screen). This vulnerability is fixed in 9.1.1043. CVE-2025-24014 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:vim-9.1.1406-150000.5.75.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:vim-data-common-9.1.1406-150000.5.75.1 moderate In MIT Kerberos 5 (aka krb5) before 1.22 (with incremental propagation), there is an integer overflow for a large update size to resize() in kdb_log.c. An authenticated attacker can cause an out-of-bounds write and kadmind daemon crash. CVE-2025-24528 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:krb5-1.19.2-150400.3.15.1 moderate libxml2 before 2.12.10 and 2.13.x before 2.13.6 has a stack-based buffer overflow in xmlSnprintfElements in valid.c. To exploit this, DTD validation must occur for an untrusted document or untrusted DTD. NOTE: this is similar to CVE-2017-9047. CVE-2025-24928 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libxml2-2-2.9.14-150400.5.44.1 moderate A vulnerability has been found in Hercules Augeas 1.14.1 and classified as problematic. This vulnerability affects the function re_case_expand of the file src/fa.c. The manipulation of the argument re leads to null pointer dereference. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. CVE-2025-2588 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libaugeas0-1.12.0-150400.3.8.1 low A vulnerability was found in OpenSSH when the VerifyHostKeyDNS option is enabled. A machine-in-the-middle attack can be performed by a malicious machine impersonating a legit server. This issue occurs due to how OpenSSH mishandles error codes in specific conditions when verifying the host key. For an attack to be considered successful, the attacker needs to manage to exhaust the client's memory resource first, turning the attack complexity high. CVE-2025-26465 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:openssh-8.4p1-150300.3.49.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:openssh-clients-8.4p1-150300.3.49.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:openssh-common-8.4p1-150300.3.49.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:openssh-server-8.4p1-150300.3.49.1 moderate libxml2 before 2.12.10 and 2.13.x before 2.13.6 has a NULL pointer dereference in xmlPatMatch in pattern.c. CVE-2025-27113 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libxml2-2-2.9.14-150400.5.44.1 moderate An out of bounds write exists in FreeType versions 2.13.0 and below (newer versions of FreeType are not vulnerable) when attempting to parse font subglyph structures related to TrueType GX and variable font files. The vulnerable code assigns a signed short value to an unsigned long and then adds a static value causing it to wrap around and allocate too small of a heap buffer. The code then writes up to 6 signed long integers out of bounds relative to this buffer. This may result in arbitrary code execution. This vulnerability may have been exploited in the wild. CVE-2025-27363 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libfreetype6-2.10.4-150000.4.22.1 important Certain instructions need intercepting and emulating by Xen. In some cases Xen emulates the instruction by replaying it, using an executable stub. Some instructions may raise an exception, which is supposed to be handled gracefully. Certain replayed instructions have additional logic to set up and recover the changes to the arithmetic flags. For replayed instructions where the flags recovery logic is used, the metadata for exception handling was incorrect, preventing Xen from handling the the exception gracefully, treating it as fatal instead. CVE-2025-27465 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:xen-libs-4.16.7_02-150400.4.72.1 moderate In SQLite 3.44.0 through 3.49.0 before 3.49.1, the concat_ws() SQL function can cause memory to be written beyond the end of a malloc-allocated buffer. If the separator argument is attacker-controlled and has a large string (e.g., 2MB or more), an integer overflow occurs in calculating the size of the result buffer, and thus malloc may not allocate enough memory. CVE-2025-29087 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libsqlite3-0-3.49.1-150000.3.27.1 moderate In SQLite 3.49.0 before 3.49.1, certain argument values to sqlite3_db_config (in the C-language API) can cause a denial of service (application crash). An sz*nBig multiplication is not cast to a 64-bit integer, and consequently some memory allocations may be incorrect. CVE-2025-29088 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libsqlite3-0-3.49.1-150000.3.27.1 moderate Vim, a text editor, is vulnerable to potential data loss with zip.vim and special crafted zip files in versions prior to 9.1.1198. The impact is medium because a user must be made to view such an archive with Vim and then press 'x' on such a strange filename. The issue has been fixed as of Vim patch v9.1.1198. CVE-2025-29768 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:vim-9.1.1406-150000.5.75.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:vim-data-common-9.1.1406-150000.5.75.1 moderate In libxml2 before 2.13.8 and 2.14.x before 2.14.2, out-of-bounds memory access can occur in the Python API (Python bindings) because of an incorrect return value. This occurs in xmlPythonFileRead and xmlPythonFileReadRaw because of a difference between bytes and characters. CVE-2025-32414 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libxml2-2-2.9.14-150400.5.44.1 moderate In libxml2 before 2.13.8 and 2.14.x before 2.14.2, xmlSchemaIDCFillNodeTables in xmlschemas.c has a heap-based buffer under-read. To exploit this, a crafted XML document must be validated against an XML schema with certain identity constraints, or a crafted XML schema must be used. CVE-2025-32415 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libxml2-2-2.9.14-150400.5.44.1 low Sudo before 1.9.17p1, when used with a sudoers file that specifies a host that is neither the current host nor ALL, allows listed users to execute commands on unintended machines. CVE-2025-32462 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:sudo-1.9.9-150400.4.39.1 important In sshd in OpenSSH before 10.0, the DisableForwarding directive does not adhere to the documentation stating that it disables X11 and agent forwarding. CVE-2025-32728 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:openssh-8.4p1-150300.3.49.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:openssh-clients-8.4p1-150300.3.49.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:openssh-common-8.4p1-150300.3.49.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:openssh-server-8.4p1-150300.3.49.1 moderate A flaw was found in GLib. An integer overflow and buffer under-read occur when parsing a long invalid ISO 8601 timestamp with the g_date_time_new_from_iso8601() function. CVE-2025-3360 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libglib-2_0-0-2.70.5-150400.3.23.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: fix OOB read when checking dotdot dir Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed). ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block. If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access. Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero). Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read. This issue was found by syzkaller tool. Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] <TASK> [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfx___dquot_initialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? __pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e CVE-2025-37785 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix nested key length validation in the set() action It's not safe to access nla_len(ovs_key) if the data is smaller than the netlink header. Check that the attribute is OK first. CVE-2025-37789 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs A malicious BPF program may manipulate the branch history to influence what the hardware speculates will happen next. On exit from a BPF program, emit the BHB mititgation sequence. This is only applied for 'classic' cBPF programs that are loaded by seccomp. CVE-2025-37948 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 moderate In the Linux kernel, the following vulnerability has been resolved: arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users Support for eBPF programs loaded by unprivileged users is typically disabled. This means only cBPF programs need to be mitigated for BHB. In addition, only mitigate cBPF programs that were loaded by an unprivileged user. Privileged users can also load the same program via eBPF, making the mitigation pointless. CVE-2025-37963 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:kernel-default-5.14.21-150400.24.167.1 low Perl threads have a working directory race condition where file operations may target unintended paths. If a directory handle is open at thread creation, the process-wide current working directory is temporarily changed in order to clone that handle for the new thread, which is visible from any third (or more) thread already running. This may lead to unintended operations such as loading code or accessing files from unexpected locations, which a local attacker may be able to exploit. The bug was introduced in commit 11a11ecf4bea72b17d250cfb43c897be1341861e and released in Perl version 5.13.6 CVE-2025-40909 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:perl-5.26.1-150300.17.20.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:perl-base-5.26.1-150300.17.20.1 moderate A flaw was found in GLib, which is vulnerable to an integer overflow in the g_string_insert_unichar() function. When the position at which to insert the character is large, the position will overflow, leading to a buffer underwrite. CVE-2025-4373 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libglib-2_0-0-2.70.5-150400.3.23.1 moderate ping in iputils before 20250602 allows a denial of service (application error or incorrect data collection) via a crafted ICMP Echo Reply packet, because of a signed 64-bit integer overflow in timestamp multiplication. CVE-2025-47268 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:iputils-20211215-150400.3.22.1 moderate setuptools is a package that allows users to download, build, install, upgrade, and uninstall Python packages. A path traversal vulnerability in `PackageIndex` is present in setuptools prior to version 78.1.1. An attacker would be allowed to write files to arbitrary locations on the filesystem with the permissions of the process running the Python code, which could escalate to remote code execution depending on the context. Version 78.1.1 fixes the issue. CVE-2025-47273 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:python3-setuptools-44.1.1-150400.9.12.1 important Untrusted LD_LIBRARY_PATH environment variable vulnerability in the GNU C Library version 2.27 to 2.38 allows attacker controlled loading of dynamically shared library in statically compiled setuid binaries that call dlopen (including internal dlopen calls after setlocale or calls to NSS functions such as getaddrinfo). CVE-2025-4802 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:glibc-2.31-150300.95.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:glibc-locale-2.31-150300.95.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:glibc-locale-base-2.31-150300.95.1 important There's a vulnerability in the libssh package where when a libssh consumer passes in an unexpectedly large input buffer to ssh_get_fingerprint_hash() function. In such cases the bin_to_base64() function can experience an integer overflow leading to a memory under allocation, when that happens it's possible that the program perform out of bounds write leading to a heap corruption. This issue affects only 32-bits builds of libssh. CVE-2025-4877 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libssh-config-0.9.8-150400.3.9.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libssh4-0.9.8-150400.3.9.1 moderate A vulnerability was found in libssh, where an uninitialized variable exists under certain conditions in the privatekey_from_file() function. This flaw can be triggered if the file specified by the filename doesn't exist and may lead to possible signing failures or heap corruption. CVE-2025-4878 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libssh-config-0.9.8-150400.3.9.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libssh4-0.9.8-150400.3.9.1 moderate ping in iputils before 20250602 allows a denial of service (application error in adaptive ping mode or incorrect data collection) via a crafted ICMP Echo Reply packet, because a zero timestamp can lead to large intermediate values that have an integer overflow when squared during statistics calculations. NOTE: this issue exists because of an incomplete fix for CVE-2025-47268 (that fix was only about timestamp calculations, and it did not account for a specific scenario where the original timestamp in the ICMP payload is zero). CVE-2025-48964 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:iputils-20211215-150400.3.22.1 moderate A use-after-free vulnerability was found in libxml2. This issue occurs when parsing XPath elements under certain circumstances when the XML schematron has the <sch:name path="..."/> schema elements. This flaw allows a malicious actor to craft a malicious XML document used as input for libxml, resulting in the program's crash using libxml or other possible undefined behaviors. CVE-2025-49794 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libxml2-2-2.9.14-150400.5.44.1 important A vulnerability was found in libxml2. Processing certain sch:name elements from the input XML file can trigger a memory corruption issue. This flaw allows an attacker to craft a malicious XML input file that can lead libxml to crash, resulting in a denial of service or other possible undefined behavior due to sensitive data being corrupted in memory. CVE-2025-49796 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libxml2-2-2.9.14-150400.5.44.1 important A flaw was found in GNU Coreutils. The sort utility's begfield() function is vulnerable to a heap buffer under-read. The program may access memory outside the allocated buffer if a user runs a crafted command using the traditional key format. A malicious input could lead to a crash or leak sensitive data. CVE-2025-5278 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:coreutils-8.32-150400.9.9.1 moderate A flaw was found in the libssh library in versions less than 0.11.2. An out-of-bounds read can be triggered in the sftp_handle function due to an incorrect comparison check that permits the function to access memory beyond the valid handle list and to return an invalid pointer, which is used in further processing. This vulnerability allows an authenticated remote attacker to potentially read unintended memory regions, exposing sensitive information or affect service behavior. CVE-2025-5318 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libssh-config-0.9.8-150400.3.9.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libssh4-0.9.8-150400.3.9.1 moderate A flaw was found in libssh versions built with OpenSSL versions older than 3.0, specifically in the ssh_kdf() function responsible for key derivation. Due to inconsistent interpretation of return values where OpenSSL uses 0 to indicate failure and libssh uses 0 for success-the function may mistakenly return a success status even when key derivation fails. This results in uninitialized cryptographic key buffers being used in subsequent communication, potentially compromising SSH sessions' confidentiality, integrity, and availability. CVE-2025-5372 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libssh-config-0.9.8-150400.3.9.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libssh4-0.9.8-150400.3.9.1 important A Local Privilege Escalation (LPE) vulnerability has been discovered in pam-config within Linux Pluggable Authentication Modules (PAM). This flaw allows an unprivileged local attacker (for example, a user logged in via SSH) to obtain the elevated privileges normally reserved for a physically present, "allow_active" user. The highest risk is that the attacker can then perform all allow_active yes Polkit actions, which are typically restricted to console users, potentially gaining unauthorized control over system configurations, services, or other sensitive operations. CVE-2025-6018 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:pam-1.3.0-150000.6.83.1 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:pam-config-1.1-150200.3.14.1 important A flaw was found in libxml2's xmlBuildQName function, where integer overflows in buffer size calculations can lead to a stack-based buffer overflow. This issue can result in memory corruption or a denial of service when processing crafted input. CVE-2025-6021 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libxml2-2-2.9.14-150400.5.44.1 important A flaw was found in the interactive shell of the xmllint command-line tool, used for parsing XML files. When a user inputs an overly long command, the program does not check the input size properly, which can cause it to crash. This issue might allow attackers to run harmful code in rare configurations without modern protections. CVE-2025-6170 Public Cloud Image google/sles-15-sp4-chost-byos-v20250721-x86-64:libxml2-2-2.9.14-150400.5.44.1 moderate