<?xml version="1.0" encoding="UTF-8"?>
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
  <DocumentTitle xml:lang="en">SUSE-IU-2025:389-1</DocumentTitle>
  <DocumentType>SUSE Image</DocumentType>
  <DocumentPublisher Type="Vendor">
    <ContactDetails>security@suse.de</ContactDetails>
    <IssuingAuthority>SUSE Security Team</IssuingAuthority>
  </DocumentPublisher>
  <DocumentTracking>
    <Identification>
      <ID>SUSE Image SUSE-IU-2025:389-1</ID>
    </Identification>
    <Status>Interim</Status>
    <Version>1</Version>
    <RevisionHistory>
      <Revision>
        <Number>1</Number>
        <Date>2025-08-25T15:06:32Z</Date>
        <Description>current</Description>
      </Revision>
    </RevisionHistory>
    <InitialReleaseDate>2025-01-29T01:00:00Z</InitialReleaseDate>
    <CurrentReleaseDate>2025-01-29T01:00:00Z</CurrentReleaseDate>
    <Generator>
      <Engine>cve-database/bin/generate-cvrf-publiccloud.pl</Engine>
      <Date>2021-02-18T01:00:00Z</Date>
    </Generator>
  </DocumentTracking>
  <DocumentNotes>
    <Note Title="Topic" Type="Summary" Ordinal="1" xml:lang="en">Image update for SUSE-IU-2025:389-1 / google/sles-15-sp6-byos-v20250129-x86-64</Note>
    <Note Title="Details" Type="General" Ordinal="2" xml:lang="en">This image update for google/sles-15-sp6-byos-v20250129-x86-64 contains the following changes:
Package aaa_base was updated:

- Add patch git-50-845b509c9a005340a0455cb8a7fe084d1b8f1946.patch  * Add mc helpers for both tcsh and bash resources (boo#1203617)

Package binutils was updated:

- Update to current 2.43.1 branch [PED-10254, PED-10306]:  * s390 - Add arch15 instructions
  * various fixes from upstream: PR32153, PR32171, PR32189,
    PR32196, PR32191, PR32109, PR32372, PR32387
- Adjusted binutils-2.43-branch.diff.gz.
- Disable zstd-by-default again (needs adjustments in at least
  golang,llvm15,llvm17 first)
- Add binutils-fix-branch.diff.
- Check non-changing of flex/bison inputs only after applying
  branch and fix-branch diffs.

- drop ld-relro.diff (relro is the default for some time)
  and it warns on avr spuriously (bsc#1233520)

- Add loongarch64 as new target

- Enable zstd compression algorithm (instead of zlib)
  for debug info sections by default.

Package cloud-regionsrv-client was updated:

- Update to 10.3.11 (bsc#1234050)  + Send registration code for the extensions, not only base product

- Update to 10.3.8 (bsc#1233333)
  + Fix the package requirements for cloud-regionsrv-client
  + Follow changes to suseconnect error reporting from stdout to stderr

- Update to 10.3.7 (bsc#1232770)
  + Fix the product triplet for LTSS, it is always SLES-LTSS, not
    $BASEPRODUCT-LTSS

- Update to 10.3.6 (jsc#PCT-471, bsc#1230615)
  + Fix sudo setup
    ~ permissions cloudguestregistryauth
    ~ directory ownership /etc/sudoers.d
  + spec file
    ~ Remove traces of registry related entries on SLE 12
  + Forward port
    ~ fix-for-sles12-disable-registry.patch
    ~ fix-for-sles12-no-trans_update.patch
  + Deregister non free extensions at registercloudguest --clean
  + Fix registry cleanup at registercloudguest --clean, don't remove files
  + Prevent duplicate search entries in registry setup
- Update EC2 plugin to 1.0.5
  + Switch to using the region endpoint from IMDS to determine the region
    instead of deriving the data from the availability zone

- Update to 10.3.5
  + Update spec file to build in all code streams,
    SLE 12, SLE 15, ALP, and SLFO and have proper dependencies

Package containerd was updated:

- Update to containerd v1.7.23. Upstream release notes:  &amp;lt;https://github.com/containerd/containerd/releases/tag/v1.7.23&amp;gt;
- Rebase patches:
  * 0001-BUILD-SLE12-revert-btrfs-depend-on-kernel-UAPI-inste.patch

- Update to containerd v1.7.22. Upstream release notes:
  &amp;lt;https://github.com/containerd/containerd/releases/tag/v1.7.22&amp;gt;
- Bump minimum Go version to 1.22.
- Rebase patches:
  * 0001-BUILD-SLE12-revert-btrfs-depend-on-kernel-UAPI-inste.patch

Package curl was updated:

- smtp: for starttls, do full upgrade [bsc#1235151]  * Make sure the TLS handshake after a successful STARTTLS command
    is fully done before further sending/receiving on the connection.
  * Add curl-mstp-starttls.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

Package dhcp was updated:

- bsc#1192020: Add 'Requires(pre): group(nogroup)' to fix user  creation in pre scriptlet for dhcp-server.

Package docker was updated:

- Update docker-buildx to v0.19.2. See upstream changelog online at  &amp;lt;https://github.com/docker/buildx/releases/tag/v0.19.2&amp;gt;.
  Some notable changelogs from the last update:
  * &amp;lt;https://github.com/docker/buildx/releases/tag/v0.19.0&amp;gt;
  * &amp;lt;https://github.com/docker/buildx/releases/tag/v0.18.0&amp;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 &amp;gt; /etc/docker/suse-secrets-enable
  and restart Docker. In order to re-enable them, just do
    echo 1 &amp;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
  &amp;lt;https://github.com/docker/buildx/releases/tag/v0.17.1&amp;gt;

- Allow users to disable SUSE secrets support by setting
  DOCKER_SUSE_SECRETS_ENABLE=0 in /etc/sysconfig/docker. bsc#1231348
  bsc#1232999

- Add %{_sysconfdir}/audit/rules.d to filelist.

- Mark docker-buildx as required since classic &amp;quot;docker build&amp;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
  &amp;lt;https://docs.docker.com/engine/release-notes/26.1/#2615&amp;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 dracut was updated:

- Update to version 059+suse.543.g98d7f037:  * fix(dm): remove 59-persistent-storage-dm.rules (bsc#1232063)

Package glib2 was updated:

- Have the glib2-tools postun trigger exit normally if  glib2-compile-schemas can't be run. Fixes error when uninstalling
  if libgio is uninstalled first (bsc#1231463).

- Add glib2-CVE-2024-52533.patch: fix a single byte buffer overflow
  (boo#1233282 CVE-2024-52533 glgo#GNOME/glib#3461).

Package glibc was updated:

- prctl-syscall-wrapper.patch: Linux: Switch back to assembly syscall  wrapper for prctl (bsc#1234665, BZ #29770)

- Correctly determine livepatching support

- Remove nss-systemd from default nsswitch.conf (bsc#1233699)

Package google-guest-agent was updated:

- Update to version 20241011.01 (bsc#1231775, bsc#1231776)  * 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 &amp;quot;network/netplan: Adjust link-local accordingly (#443)&amp;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 &amp;quot;user already belogs to group&amp;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 &amp;quot;user already belogs to group&amp;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 &amp;quot;user already belogs to group&amp;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:

- 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=&amp;quot;compat:suse:google_up.sh&amp;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 &amp;quot;Revert 3 commits:&amp;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-osconfig-agent was updated:

- Update to version 20240926.03 (bsc#1231775, bsc#1231776)  * Revert &amp;quot;Bump go.opentelemetry.io/otel from 1.24.0 to 1.30.0 (#679)&amp;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 &amp;quot;bump version of the gRPC&amp;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 &amp;quot;Update grpc library and other dependencies. (#664)&amp;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 &amp;quot;update osconfig api to v1.13.0 &amp;amp; indirect dependency update&amp;quot; (#659)
- from version 20240822.00
  * Revert &amp;quot;Source package info delivery to control-plane (#639)&amp;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;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 &amp;quot;Adding Architecture to the packages being installed/updated in yum repo&amp;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;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 &amp;quot;Initial configuration of the dependabot
    for the direct and indirect dâ¦&amp;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 xen package contains debug_info files with the .module suffix by moving  them to a separate xen-debug subpackage (bsc#1232573)

- Fix not a directory error from the minix filesystem, as leftover data on disk
  may contain its magic header so it gets misdetected (bsc#1231604)
  * grub2-install-fix-not-a-directory-error.patch

Package kdump was updated:

- upgrade to version kdump-2.0.6+git19.ge6e33ae:  * allow negative KDUMP_KEEP_OLD_DUMPS (bsc#1234845)

Package kernel-default was updated:

- Revert &amp;quot;btrfs: fix use-after-free waiting for encoded read endios (bsc#1235128)&amp;quot;- commit 4296cd8

- Delete XHCI patch for regression (bsc#1235550)
  Deleted:
  patches.suse/xhci-fix-possible-null-pointer-deref-during-xhci-urb.patch
- commit 9b365a6

- Update
  patches.suse/Bluetooth-L2CAP-do-not-leave-dangling-sk-pointer-on-.patch
  (stable-fixes CVE-2024-56605 bsc#1235061).
- Update
  patches.suse/can-j1939-j1939_session_new-fix-skb-reference-counti.patch
  (git-fixes CVE-2024-56645 bsc#1235134).
- Update patches.suse/drm-amdgpu-fix-usage-slab-after-free.patch
  (stable-fixes CVE-2024-56551 bsc#1235075).
- commit 3b5652e

- 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 561bd1f

- smb: client: fix TCP timers deadlock after rmmod (git-fixes)
  [hcarvalho: fix issue described in bsc#1233642]
- commit 6448f16

- smb: client: Fix use-after-free of network namespace
  (CVE-2024-53095 bsc#1233642).
- commit a29a1bc

- smb: client: fix use-after-free of signing key (CVE-2024-53179
  bsc#1234921).
- commit fb9831c

- powerpc/book3s64/hugetlb: Fix disabling hugetlb when fadump
  is active (bsc#1235108).
- commit c2d7be7

- nvmet-loop: avoid using mutex in IO hotpath (git-fixes).
- commit c6bd393

- nvme-pci: 512 byte aligned dma pool segment quirk (git-fixes).
- commit c9efbed

- nvme-rdma: unquiesce admin_q before destroy it (git-fixes).
- nvme-tcp: fix the memleak while create new ctrl failed
  (git-fixes).
- nvme/multipath: Fix RCU list traversal to use SRCU primitive
  (git-fixes).
- nvme: fix metadata handling in nvme-passthrough (git-fixes).
- nvme: apple: fix device reference counting (git-fixes).
- commit d75a9f8

- workqueue: Do not warn when cancelling WQ_MEM_RECLAIM work
  from !WQ_MEM_RECLAIM worker (bsc#1235416).
- commit 1f8402d

- btrfs: fix use-after-free waiting for encoded read endios (bsc#1235128)
- commit 1c811b2

- scsi: lpfc: Copyright updates for 14.4.0.7 patches
  (bsc#1235409).
- scsi: lpfc: Update lpfc version to 14.4.0.7 (bsc#1235409).
- scsi: lpfc: Add support for large fw object application layer
  reads (bsc#1235409).
- scsi: lpfc: Update definition of firmware configuration mbox
  cmds (bsc#1235409).
- scsi: lpfc: Change lpfc_nodelist save_flags member into a
  bitmask (bsc#1235409).
- scsi: lpfc: Add handling for LS_RJT reason explanation
  authentication required (bsc#1235409).
- scsi: lpfc: Modify handling of ADISC based on ndlp state and
  RPI registration (bsc#1235409).
- scsi: lpfc: Delete NLP_TARGET_REMOVE flag due to obsolete usage
  (bsc#1235409).
- scsi: lpfc: Restrict the REG_FCFI MAM field to FCoE adapters
  only (bsc#1235409).
- scsi: lpfc: Redefine incorrect type in lpfc_create_device_data()
  (bsc#1235409).
- commit 9acd44f

- btrfs: fix use-after-free in btrfs_encoded_read_endio() (CVE-2024-56582 bsc#1235128)
- commit 03199ca

- scsi: qla2xxx: Update version to 10.02.09.400-k (bsc#1235406).
- scsi: qla2xxx: Supported speed displayed incorrectly for VPorts
  (bsc#1235406).
- scsi: qla2xxx: Fix NVMe and NPIV connect issue (bsc#1235406).
- scsi: qla2xxx: Remove check req_sg_cnt should be equal to
  rsp_sg_cnt (bsc#1235406).
- scsi: qla2xxx: Fix use after free on unload (bsc#1235406).
- scsi: qla2xxx: Fix abort in bsg timeout (bsc#1235406).
- scsi: qla2xxx: Remove the unused 'del_list_entry' field in
  struct fc_port (bsc#1235406).
- commit 7f98a5d

- vfio/pci: Properly hide first-in-list PCIe extended capability
  (bsc#1235004 CVE-2024-53214).
- commit 84c948c

- wifi: ath10k: avoid NULL pointer error during sdio remove
  (CVE-2024-56599 bsc#1235138).
- commit ee28d42

- xhci: fix possible null pointer deref during xhci urb enqueue
  (git-fixes).
- commit 743e834

- erofs: handle NONHEAD !delta[1] lclusters gracefully
  (bsc#1235045 CVE-2024-53234).
- commit ac75a6e

- mm/slub: Avoid list corruption when removing a slab from the
  full list (CVE-2024-56566 bsc#1235033).
- commit fa88fa6

- Drivers: hv: util: Avoid accessing a ringbuffer not initialized
  yet (git-fixes).
- tools: hv: change permissions of NetworkManager configuration
  file (git-fixes).
- x86/hyperv: Fix hv tsc page based sched_clock for hibernation
  (git-fixes).
- commit b596020

- soc: qcom: geni-se: Add M_TX_FIFO_NOT_EMPTY bit definition
  (git-fixes).
- commit 01eee89

- zram: fix NULL pointer in comp_algorithm_show() (bsc#1234974
  CVE-2024-53222).
- commit ddd5fff

- xhci: Add usb cold attach (CAS) as a reason to resume root hub
  (git-fixes).
- commit 585f519

- slub: Replace cmpxchg_double() - KABI fix (bsc#1220773).
- commit 3c58884

- Bluetooth: RFCOMM: avoid leaving dangling sk pointer in
  rfcomm_sock_alloc() (bsc#1235056 CVE-2024-56604).
- 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 9ad4dd1

- RAS/AMD/ATL: Translate normalized to system physical addresses using PRM (jsc#PED-10467).
- commit eb8da28

- ACPI: PRM: Add PRM handler direct call support (jsc#PED-10467).
- commit bbc75ff

- serial: qcom-geni: introduce qcom_geni_serial_poll_bitfield()
  (git-fixes).
- serial: qcom-geni: fix arg types for qcom_geni_serial_poll_bit()
  (git-fixes).
- soc: qcom: geni-se: add GP_LENGTH/IRQ_EN_SET/IRQ_EN_CLEAR
  registers (git-fixes).
- commit 89e9015

- serial: imx: only set receiver level if it is zero (git-fixes).
- serial: stm32: do not always set SER_RS485_RX_DURING_TX if
  RS485 is enabled (git-fixes).
- commit f2c678b

- serial: qcom-geni: fix receiver enable (git-fixes).
- serial: qcom-geni: fix dma rx cancellation (git-fixes).
- serial: qcom-geni: fix shutdown race (git-fixes).
- serial: qcom-geni: revert broken hibernation support
  (git-fixes).
- serial: qcom-geni: fix polled console initialisation
  (git-fixes).
- serial: qcom-geni: fix polled console corruption (git-fixes).
- serial: qcom-geni: disable interrupts during console writes
  (git-fixes).
- serial: qcom-geni: fix console corruption (git-fixes).
- serial: qcom-geni: fix false console tx restart (git-fixes).
- serial: qcom-geni: fix fifo polling timeout (git-fixes).
- serial: don't use uninitialized value in uart_poll_init()
  (git-fixes).
- serial: qcom-geni: fix hard lockup on buffer flush (git-fixes).
- serial: qcom-geni: fix soft lockup on sw flow control and
  suspend (git-fixes).
- serial: imx: set receiver level before starting uart
  (git-fixes).
- serial: 8250_dw: Don't use struct dw8250_data outside of 8250_dw
  (git-fixes).
- Refresh
  patches.suse/serial-8250_dw-Add-Sophgo-SG2044-quirk.patch.
- serial: stm32: Return IRQ_NONE in the ISR if no handling happend
  (git-fixes).
- serial: 8250_dw: Replace ACPI device check by a quirk
  (git-fixes).
- serial: qcom-geni: Don't cancel/abort if we can't get the port
  lock (git-fixes).
- serial: Do not hold the port lock when setting rx-during-tx GPIO
  (git-fixes).
- tty: serial: kgdboc: Fix 8250_* kgdb over serial (git-fixes).
- hvc/xen: fix console unplug (git-fixes).
- hvc/xen: fix error path in xen_hvc_init() to always register
  frontend driver (git-fixes).
- hvc/xen: fix event channel handling for secondary consoles
  (git-fixes).
- commit 2277c72

- RDMA/rtrs: Ensure 'ib_sge list' is accessible (git-fixes)
- commit c3bd473

- RDMA/hns: Fix missing flush CQE for DWQE (git-fixes)
- commit a1a14cc

- RDMA/hns: Fix warning storm caused by invalid input in IO path (git-fixes)
- commit 953ada2

- RDMA/hns: Fix accessing invalid dip_ctx during destroying QP (git-fixes)
- commit e65781e

- RDMA/hns: Fix mapping error of zero-hop WQE buffer (git-fixes)
- commit 3c13231

- RDMA/bnxt_re: Fix the locking while accessing the QP table (git-fixes)
- commit ed2aacf

- RDMA/bnxt_re: Disable use of reserved wqes (git-fixes)
- commit 353c5fc

- RDMA/bnxt_re: Fix max_qp_wrs reported (git-fixes)
- commit aa6d51f

- RDMA/bnxt_re: Fix reporting hw_ver in query_device (git-fixes)
- commit fa157d3

- RDMA/bnxt_re: Add check for path mtu in modify_qp (git-fixes)
- commit c25c45b

- RDMA/bnxt_re: Fix the check for 9060 condition (git-fixes)
- commit 6ff31c0

- RDMA/core: Fix ENODEV error for iWARP test over vlan (git-fixes)
- commit 7974be7

- RDMA/bnxt_re: Avoid sending the modify QP workaround for latest adapters (git-fixes)
- commit 02a3ccc

- RDMA/bnxt_re: Avoid initializing the software queue for user queues (git-fixes)
- commit 3b41756

- RDMA/mlx5: Enforce same type port association for multiport RoCE (git-fixes)
- commit 1eb4b60

- RDMA/uverbs: Prevent integer overflow issue (git-fixes)
- commit d8e26f5

- RDMA/bnxt_re: Remove always true dattr validity check (git-fixes)
- commit 39ec21b

- sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket
  (git-fixes).
- nfs: ignore SB_RDONLY when mounting nfs (git-fixes).
- NFSD: initialize copy-&amp;gt;cp_clp early in nfsd4_copy for use by
  trace point (git-fixes).
- commit f025866

- Refresh patches.suse/NFSv3-only-use-NFS-timeout-for-MOUNT-when-protocols-.patch.
  Add upstream commit id.
- commit 4b11aed

- nfsd: fix UAF when access ex_uuid or ex_stats (CVE-2024-53216
  bsc#1235003).
- SUNRPC: no need get cache ref when protected by rcu
  (CVE-2024-53216 bsc#1235003).
- nfsd: no need get cache ref when protected by rcu
  (CVE-2024-53216 bsc#1235003).
- SUNRPC: introduce cache_check_rcu to help check in rcu context
  (CVE-2024-53216 bsc#1235003).
- commit 4d2bea1

- blacklist.conf:
- Delete
  patches.suse/nfsd-release-svc_expkey-svc_export-with-rcu_work.patch.
  This was reverted upstream.  There is a better fix.
- commit 49617fd

- Delete patches.suse/drdb-Convert-to-use-bdev_open_by_path.patch.
  See bsc#1234668. This backport did not copile correctly, and
  needed too many other patches to work correctly, since it was
  part of a larger series. So remove it.
- commit 7f1c582

- ALSA hda/realtek: Add quirk for Framework F111:000C
  (stable-fixes).
- ALSA: seq: oss: Fix races at processing SysEx messages
  (stable-fixes).
- ALSA: hda/realtek: Fix headset mic on Acer Nitro 5
  (stable-fixes).
- commit d982feb

- wifi: cw1200: Fix potential NULL dereference (git-fixes).
- pinctrl: mcp23s08: Fix sleeping in atomic context due to regmap
  locking (git-fixes).
- ALSA: seq: Check UMP support for midi_version change
  (git-fixes).
- ALSA: usb-audio: US16x08: Initialize array before use
  (git-fixes).
- drm: adv7511: Drop dsi single lane support (git-fixes).
- drm: adv7511: Fix use-after-free in adv7533_attach_dsi()
  (git-fixes).
- drm/bridge: adv7511_audio: Update Audio InfoFrame properly
  (git-fixes).
- drm/i915/dg1: Fix power gate sequence (git-fixes).
- commit f7b7a9b

- netfs/fscache: Add a memory barrier for FSCACHE_VOLUME_CREATING
  (CVE-2024-56755 bsc#1234920).
- cachefiles: Fix NULL pointer dereference in object-&amp;gt;file
  (CVE-2024-56549 bsc#1234912).
- commit 785eb5b

- netfilter: ipset: add missing range check in bitmap_ip_uadt (CVE-2024-53141 bsc#1234381)
- commit 51ec3c0

- Update
  patches.suse/ALSA-pcm-Add-sanity-NULL-check-for-the-default-mmap-.patch
  (stable-fixes CVE-2024-53180 bsc#1234929).
- Update
  patches.suse/ALSA-usb-audio-Fix-out-of-bounds-reads-when-finding-.patch
  (stable-fixes CVE-2024-53150 bsc#1234834).
- Update patches.suse/Bluetooth-MGMT-Fix-possible-deadlocks.patch
  (git-fixes CVE-2024-53207 bsc#1234907).
- Update
  patches.suse/Bluetooth-MGMT-Fix-slab-use-after-free-Read-in-set_p.patch
  (git-fixes CVE-2024-53208 bsc#1234909).
- Update
  patches.suse/Bluetooth-fix-use-after-free-in-device_for_each_chil.patch
  (git-fixes CVE-2024-53237 bsc#1235007).
- 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).
- Update
  patches.suse/NFSD-Prevent-NULL-dereference-in-nfsd4_process_cb_update.patch
  (git-fixes CVE-2024-53217 bsc#1234999).
- Update
  patches.suse/NFSD-Prevent-a-potential-integer-overflow.patch
  (git-fixes CVE-2024-53146 bsc#1234853).
- Update
  patches.suse/NFSv4.0-Fix-a-use-after-free-problem-in-the-asynchronous-open.patch
  (git-fixes CVE-2024-53173 bsc#1234891).
- Update
  patches.suse/RDMA-mlx5-Move-events-notifier-registration-to-be-af.patch
  (git-fixes CVE-2024-53224 bsc#1235009).
- Update
  patches.suse/RDMA-rxe-Fix-the-qp-flush-warnings-in-req.patch
  (git-fixes CVE-2024-53229 bsc#1234905).
- Update
  patches.suse/Revert-mmc-dw_mmc-Fix-IDMAC-operation-with-pages-big.patch
  (git-fixes CVE-2024-53127 bsc#1234153).
- Update
  patches.suse/SUNRPC-make-sure-cache-entry-active-before-cache_show.patch
  (git-fixes CVE-2024-53174 bsc#1234899).
- Update
  patches.suse/ad7780-fix-division-by-zero-in-ad7780_write_raw.patch
  (git-fixes CVE-2024-56567 bsc#1234916).
- Update
  patches.suse/blk-iocost-do-not-WARN-if-iocg-was-already-offlined.patch
  (bsc#1234147 CVE-2024-36908 bsc#1225743).
- Update
  patches.suse/block-bfq-fix-bfqq-uaf-in-bfq_limit_depth.patch
  (bsc#1234160 CVE-2024-53166 bsc#1234884).
- Update
  patches.suse/block-bfq-fix-uaf-for-accessing-waker_bfqq-after-spl.patch
  (bsc#1234279 CVE-2024-49854 bsc#1232193).
- Update
  patches.suse/bnxt_en-Fix-receive-ring-space-parameters-when-XDP-i.patch
  (git-fixes CVE-2024-53209 bsc#1235002).
- Update
  patches.suse/clk-clk-apple-nco-Add-NULL-check-in-applnco_probe.patch
  (git-fixes CVE-2024-53154 bsc#1234826).
- Update
  patches.suse/comedi-Flush-partial-mappings-in-error-case.patch
  (git-fixes CVE-2024-53148 bsc#1234832).
- Update
  patches.suse/crypto-caam-Fix-the-pointer-passed-to-caam_qi_shutdo.patch
  (git-fixes CVE-2024-56754 bsc#1234918).
- Update
  patches.suse/crypto-qat-qat_4xxx-fix-off-by-one-in-uof_get_name.patch
  (git-fixes CVE-2024-53162 bsc#1234843).
- Update
  patches.suse/drm-amd-display-Add-NULL-check-for-clk_mgr-in-dcn32_.patch
  (stable-fixes CVE-2024-49915 bsc#1231963).
- Update
  patches.suse/drm-amd-display-Avoid-overflow-assignment-in-link_dp.patch
  (stable-fixes CVE-2024-50016 bsc#1232420).
- Update
  patches.suse/drm-amd-display-Fix-null-check-for-pipe_ctx-plane_st-2bc96c9.patch
  (git-fixes CVE-2024-53200 bsc#1234968).
- Update
  patches.suse/drm-amd-display-Fix-null-check-for-pipe_ctx-plane_st.patch
  (git-fixes CVE-2024-53201 bsc#1234969).
- Update
  patches.suse/drm-i915-Fix-NULL-pointer-dereference-in-capture_eng.patch
  (git-fixes CVE-2024-56667 bsc#1235016).
- Update
  patches.suse/drm-nouveau-gr-gf100-Fix-missing-unlock-in-gf100_gr_.patch
  (git-fixes CVE-2024-56752 bsc#1234937).
- Update
  patches.suse/drm-rockchip-vop-Fix-a-dereferenced-before-check-war.patch
  (git-fixes CVE-2024-53129 bsc#1234155).
- Update
  patches.suse/filemap-Fix-bounds-checking-in-filemap_read.patch
  (bsc#1234209 CVE-2024-50272 bsc#1233461).
- Update
  patches.suse/firmware-arm_scpi-Check-the-DVFS-OPP-count-returned-.patch
  (git-fixes CVE-2024-53157 bsc#1234827).
- Update
  patches.suse/firmware_loader-Fix-possible-resource-leak-in-fw_log.patch
  (git-fixes CVE-2024-53202 bsc#1234970).
- Update
  patches.suse/hwmon-nct6775-core-Fix-overflows-seen-when-writing-l.patch
  (git-fixes CVE-2024-53159 bsc#1234848).
- Update
  patches.suse/i3c-master-Fix-miss-free-init_dyn_addr-at-i3c_master.patch
  (git-fixes CVE-2024-56562 bsc#1234930).
- Update
  patches.suse/kdb-Fix-buffer-overflow-during-tab-complete.patch
  (bsc#1234652 CVE-2024-39480 bsc#1227445).
- Update
  patches.suse/media-i2c-tc358743-Fix-crash-in-the-probe-error-path.patch
  (git-fixes CVE-2024-56576 bsc#1235019).
- Update
  patches.suse/mm-revert-mm-shmem-fix-data-race-in-shmem_getattr.patch
  (CVE-2024-50228 bsc#1233204 git fixes (mm/shmem) CVE-2024-53136
  bsc#1234161).
- Update
  patches.suse/msft-hv-3081-hv_sock-Initializing-vsk-trans-to-NULL-to-prevent-a-.patch
  (git-fixes CVE-2024-53103 bsc#1234024).
- Update
  patches.suse/net-usb-lan78xx-Fix-double-free-issue-with-interrupt.patch
  (git-fixes CVE-2024-53213 bsc#1234973).
- Update
  patches.suse/nfsd-release-svc_expkey-svc_export-with-rcu_work.patch
  (git-fixes CVE-2024-53216 bsc#1235003).
- Update
  patches.suse/nvme-fabrics-fix-kernel-crash-while-shutting-down-co.patch
  (git-fixes CVE-2024-53169 bsc#1234900).
- Update
  patches.suse/nvme-pci-fix-freeing-of-the-HMB-descriptor-table.patch
  (git-fixes CVE-2024-56756 bsc#1234922).
- Update
  patches.suse/ocfs2-fix-uninitialized-value-in-ocfs2_file_read_iter.patch
  (git-fixes CVE-2024-53155 bsc#1234855).
- Update
  patches.suse/s390-iucv-MSG_PEEK-causes-memory-leak-in-iucv_sock_destruct.patch
  (git-fixes CVE-2024-53210 bsc#1234971).
- Update patches.suse/smb-client-fix-UAF-in-async-decryption.patch
  (bsc#1232418 (CVE-2024-50047) CVE-2024-50047).
- Update
  patches.suse/soc-qcom-geni-se-fix-array-underflow-in-geni_se_clk_.patch
  (git-fixes CVE-2024-53158 bsc#1234811).
- Update patches.suse/svcrdma-Address-an-integer-overflow.patch
  (git-fixes CVE-2024-53151 bsc#1234829).
- Update
  patches.suse/svcrdma-fix-miss-destroy-percpu_counter-in-svc_rdma_proc_init.patch
  (git-fixes CVE-2024-53215 bsc#1234962).
- 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).
- Update
  patches.suse/ubifs-authentication-Fix-use-after-free-in-ubifs_tnc_end_commit.patch
  (git-fixes CVE-2024-53171 bsc#1234889).
- Update patches.suse/vdpa-solidrun-Fix-UB-bug-with-devres.patch
  (git-fixes CVE-2024-53126 bsc#1234158).
- Update patches.suse/wifi-ath12k-fix-crash-when-unbinding.patch
  (git-fixes CVE-2024-53188 bsc#1234948).
- Update patches.suse/wifi-ath12k-fix-warning-when-unbinding.patch
  (git-fixes CVE-2024-53191 bsc#1234952).
- Update
  patches.suse/wifi-ath9k-add-range-check-for-conn_rsp_epid-in-htc_.patch
  (git-fixes CVE-2024-53156 bsc#1234846).
- Update
  patches.suse/wifi-cw1200-Fix-potential-NULL-dereference.patch
  (git-fixes CVE-2024-56536 bsc#1234911).
- Update
  patches.suse/wifi-mwifiex-Fix-memcpy-field-spanning-write-warning-d241a13.patch
  (git-fixes CVE-2024-56539 bsc#1234963).
- Update
  patches.suse/wifi-rtlwifi-Drastically-reduce-the-attempts-to-read.patch
  (stable-fixes CVE-2024-53190 bsc#1234950).
- commit 525626c

- drm/amdkfd: pause autosuspend when creating pdd (stable-fixes).
- commit 22dc4b9

- ALSA: seq: ump: Fix seq port updates per FB info notify
  (git-fixes).
- commit d51bef7

- drm/amdkfd: Use device based logging for errors (stable-fixes).
- commit bcbc5e4

- ALSA: seq: ump: Use automatic cleanup of kfree() (stable-fixes).
- Refresh
  patches.suse/ALSA-seq-ump-Skip-useless-ports-for-static-blocks.patch.
- commit 013a8a9

- drm/dp_mst: Ensure mst_primary pointer is valid in
  drm_dp_mst_handle_up_req() (stable-fixes).
- regmap: Use correct format specifier for logging range errors
  (stable-fixes).
- platform/x86: asus-nb-wmi: Ignore unknown event 0xCF
  (stable-fixes).
- ALSA: seq: ump: Use guard() for locking (stable-fixes).
- commit 19dff9a

- EDAC/bluefield: Fix potential integer overflow (CVE-2024-53161
  bsc#1234856).
- commit 7e4b5c0

- ice: Unbind the workqueue (bsc#1234989)
- commit 0570b37

- swiotlb: Reinstate page-alignment for mappings &amp;gt;= PAGE_SIZE
  (git-fixes).
- swiotlb: Enforce page alignment in swiotlb_alloc() (git-fixes).
- commit c0aa9ec

- rcu/kvfree: Fix data-race in __mod_timer / kvfree_call_rcu
  (bsc#1234810 CVE-2024-53160).
- commit 94f148d

- io_uring: check if iowq is killed before queuing (git-fixes).
- io_uring: Fix registered ring file refcount leak (git-fixes).
- commit 3d9d45c

- io_uring: always lock __io_cqring_overflow_flush (git-fixes).
- io_uring/rw: avoid punting to io-wq directly (git-fixes).
- commit b99f1b6

- io_uring/tctx: work around xa_store() allocation error issue
  (git-fixes).
- commit 38adcdb

- Drop recent ACPI fixes for kABI breakage
  Deleted:
  patches.suse/ACPI-x86-Make-UART-skip-quirks-work-on-PCI-UARTs-wit.patch
  patches.suse/ACPI-x86-Move-acpi_quirk_skip_serdev_enumeration-out.patch
- commit c49880b

- wifi: mac80211: clean up 'ret' in sta_link_apply_parameters()
  (stable-fixes).
- Refresh
  patches.suse/wifi-mac80211-fix-station-NSS-capability-initializat.patch.
- commit 484b5d2

- serial: amba-pl011: Use port lock wrappers (stable-fixes).
- Refresh patches.suse/ARM-PL011-Fix-DMA-support.patch.
- commit acf4ef9

- power: supply: gpio-charger: Fix set charge current limits
  (git-fixes).
- USB: serial: option: add Telit FE910C04 rmnet compositions
  (stable-fixes).
- USB: serial: option: add MediaTek T7XX compositions
  (stable-fixes).
- USB: serial: option: add Netprisma LCUK54 modules for WWAN Ready
  (stable-fixes).
- USB: serial: option: add MeiG Smart SLM770A (stable-fixes).
- USB: serial: option: add TCL IK512 MBIM &amp;amp; ECM (stable-fixes).
- usb: dwc2: Fix HCD port connection race (git-fixes).
- usb: dwc2: hcd: Fix GetPortStatus &amp;amp; SetPortFeature (git-fixes).
- usb: dwc2: Fix HCD resume (git-fixes).
- usb: gadget: u_serial: Fix the issue that gs_start_io crashed
  due to accessing null pointer (git-fixes).
- usb: dwc3: xilinx: make sure pipe clock is deselected in usb2
  only mode (git-fixes).
- usb: typec: anx7411: fix OF node reference leaks in
  anx7411_typec_switch_probe() (git-fixes).
- usb: typec: anx7411: fix fwnode_handle reference leak
  (git-fixes).
- usb: host: max3421-hcd: Correctly abort a USB request
  (git-fixes).
- usb: ehci-hcd: fix call balance of clocks handling routines
  (git-fixes).
- spi: aspeed: Fix an error handling path in
  aspeed_spi_[read|write]_user() (git-fixes).
- wifi: cfg80211: sme: init n_channels before channels[] access
  (git-fixes).
- wifi: mac80211: init cnt before accessing elem in
  ieee80211_copy_mbssid_beacon (git-fixes).
- rtc: cmos: avoid taking rtc_lock for extended period of time
  (stable-fixes).
- serial: amba-pl011: fix build regression (git-fixes).
- serial: amba-pl011: Fix RX stall when DMA is used (git-fixes).
- serial: 8250_dw: Add Sophgo SG2044 quirk (stable-fixes).
- usb: dwc3: ep0: Don't clear ep0 DWC3_EP_TRANSFER_STARTED
  (git-fixes).
- usb: chipidea: udc: handle USB Error Interrupt if IOC not set
  (stable-fixes).
- pinmux: Use sequential access to access desc-&amp;gt;pinmux data
  (stable-fixes).
- thermal/drivers/qcom/tsens-v1: Add support for MSM8937 tsens
  (stable-fixes).
- wifi: brcmfmac: Fix oops due to NULL pointer dereference in
  brcmf_sdiod_sglist_rw() (stable-fixes).
- wifi: ipw2x00: libipw_rx_any(): fix bad alignment
  (stable-fixes).
- wifi: rtw89: check return value of ieee80211_probereq_get()
  for RNR (stable-fixes).
- soc: fsl: cpm1: qmc: Set the ret error code on
  platform_get_irq() failure (git-fixes).
- soc: imx8m: Probe the SoC driver as platform driver
  (stable-fixes).
- soc: fsl: cpm1: qmc: Introduce qmc_{init,exit}_xcc() and their
  CPM1 version (stable-fixes).
- soc: fsl: cpm1: qmc: Introduce qmc_init_resource() and its
  CPM1 version (stable-fixes).
- soc: fsl: cpm1: qmc: Re-order probe() operations (stable-fixes).
- soc: fsl: cpm1: qmc: Fix blank line and spaces (stable-fixes).
- usb: dwc3: ep0: Don't reset resource alloc flag (including ep0)
  (git-fixes).
- usb: dwc2: gadget: Don't write invalid mapped sg entries into
  dma_desc with iommu enabled (stable-fixes).
- usb: cdns3-ti: Add workaround for Errata i2409 (stable-fixes).
- usb: cdns3: Add quirk flag to enable suspend residency
  (stable-fixes).
- usb: dwc3: ep0: Don't reset resource alloc flag (git-fixes).
- xhci: Allow RPM on the USB controller (1022:43f7) by default
  (stable-fixes).
- usb: dwc3: gadget: Rewrite endpoint allocation flow
  (stable-fixes).
- soc/fsl: cpm: qmc: Convert to platform remove callback returning
  void (stable-fixes).
- commit 07f38d1

- PCI/MSI: Handle lack of irqdomain gracefully (git-fixes).
- i2c: microchip-core: fix &amp;quot;ghost&amp;quot; detections (git-fixes).
- i2c: microchip-core: actually use repeated sends (git-fixes).
- i2c: imx: add imx7d compatible string for applying erratum
  ERR007805 (git-fixes).
- linux/dmaengine.h: fix a few kernel-doc warnings (git-fixes).
- phy: core: Fix an OF node refcount leakage in
  of_phy_provider_lookup() (git-fixes).
- phy: core: Fix an OF node refcount leakage in _of_phy_get()
  (git-fixes).
- phy: core: Fix that API devm_phy_destroy() fails to destroy
  the phy (git-fixes).
- phy: core: Fix that API devm_of_phy_provider_unregister()
  fails to unregister the phy provider (git-fixes).
- phy: core: Fix that API devm_phy_put() fails to release the phy
  (git-fixes).
- phy: qcom-qmp: Fix register name in RX Lane config of SC8280XP
  (git-fixes).
- phy: rockchip: naneng-combphy: fix phy reset (git-fixes).
- phy: usb: Toggle the PHY power during init (git-fixes).
- mtd: rawnand: arasan: Fix missing de-registration of NAND
  (git-fixes).
- mtd: rawnand: arasan: Fix double assertion of chip-select
  (git-fixes).
- mtd: diskonchip: Cast an operand to prevent potential overflow
  (git-fixes).
- mtd: rawnand: fix double free in atmel_pmecc_create_user()
  (git-fixes).
- of/irq: Fix using uninitialized variable @addr_len in API
  of_irq_parse_one() (git-fixes).
- of: Fix refcount leakage for OF node returned by
  __of_get_dma_parent() (git-fixes).
- of: Fix error path in of_parse_phandle_with_args_map()
  (git-fixes).
- media: dvb-frontends: dib3000mb: fix uninit-value in
  dib3000_write_reg (git-fixes).
- hwmon: (tmp513) Fix interpretation of values of Temperature
  Result and Limit Registers (git-fixes).
- hwmon: (tmp513) Fix Current Register value interpretation
  (git-fixes).
- hwmon: (tmp513) Fix interpretation of values of Shunt Voltage
  and Limit Registers (git-fixes).
- i915/guc: Accumulate active runtime on gt reset (git-fixes).
- i915/guc: Ensure busyness counter increases motonically
  (git-fixes).
- i915/guc: Reset engine utilization buffer before registration
  (git-fixes).
- mmc: sdhci-tegra: Remove SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC
  quirk (git-fixes).
- i2c: riic: Always round-up when calculating bus period
  (git-fixes).
- i2c: pnx: Fix timeout in wait functions (git-fixes).
- mmc: sdhci-pci: Add DMI quirk for missing CD GPIO on Vexia
  Edu Atla 10 tablet (stable-fixes).
- PCI: vmd: Add DID 8086:B06F and 8086:B60B for Intel client SKUs
  (stable-fixes).
- PCI: qcom: Add support for IPQ9574 (stable-fixes).
- PCI: Add ACS quirk for Wangxun FF5xxx NICs (stable-fixes).
- PCI: Detect and trust built-in Thunderbolt chips (stable-fixes).
- PCI: Add 'reset_subordinate' to reset hierarchy below bridge
  (stable-fixes).
- PCI: vmd: Set devices to D0 before enabling PM L1 Substates
  (stable-fixes).
- pinctrl: qcom: spmi-mpp: Add PM8937 compatible (stable-fixes).
- pinctrl: qcom-pmic-gpio: add support for PM8937 (stable-fixes).
- leds: class: Protect brightness_show() with led_cdev-&amp;gt;led_access
  mutex (stable-fixes).
- media: cx231xx: Add support for Dexatek USB Video Grabber
  1d19:6108 (stable-fixes).
- media: uvcvideo: Add a quirk for the Kaiweets KTI-W02 infrared
  camera (stable-fixes).
- media: uvcvideo: RealSense D421 Depth module metadata
  (stable-fixes).
- mmc: mtk-sd: Fix MMC_CAP2_CRYPTO flag setting (git-fixes).
- mmc: mtk-sd: fix devm_clk_get_optional usage (stable-fixes).
- mmc: sdhci-esdhc-imx: enable quirks SDHCI_QUIRK_NO_LED
  (stable-fixes).
- mmc: core: Add SD card quirk for broken poweroff notification
  (stable-fixes).
- hwmon: (nct6775) Add 665-ACE/600M-CL to ASUS WMI monitoring list
  (stable-fixes).
- of: address: Report error on resource bounds overflow
  (stable-fixes).
- PCI/AER: Disable AER service on suspend (stable-fixes).
- PCI: Use preserve_config in place of pci_flags (stable-fixes).
- PCI: Add ACS quirk for Broadcom BCM5760X NIC (stable-fixes).
- hwmon: (tmp513) Use SI constants from units.h (stable-fixes).
- hwmon: (tmp513) Simplify with dev_err_probe() (stable-fixes).
- hwmon: (tmp513) Don't use &amp;quot;proxy&amp;quot; headers (stable-fixes).
- commit 5b99336

- drm/amdgpu: don't access invalid sched (git-fixes).
- drm/modes: Avoid divide by zero harder in drm_mode_vrefresh()
  (stable-fixes).
- drm/panel: novatek-nt35950: fix return value check in
  nt35950_probe() (git-fixes).
- drm/i915: Fix memory leak by correcting cache object name in
  error handler (git-fixes).
- drm/i915: Fix NULL pointer dereference in capture_engine
  (git-fixes).
- HID: magicmouse: Apple Magic Trackpad 2 USB-C driver support
  (stable-fixes).
- gpio: grgpio: Add NULL check in grgpio_probe (git-fixes).
- gpio: grgpio: use a helper variable to store the address of
  ofdev-&amp;gt;dev (stable-fixes).
- commit caf7811

- dmaengine: tegra: Return correct DMA status when paused
  (git-fixes).
- dmaengine: mv_xor: fix child node refcount handling in early
  exit (git-fixes).
- dmaengine: apple-admac: Avoid accessing registers in probe
  (git-fixes).
- dmaengine: dw: Select only supported masters for ACPI devices
  (git-fixes).
- dmaengine: at_xdmac: avoid null_prt_deref in
  at_xdmac_prep_dma_memset (git-fixes).
- amdgpu/uvd: get ring reference from rq scheduler (git-fixes).
- Documentation: PM: Clarify pm_runtime_resume_and_get() return
  value (git-fixes).
- ACPICA: events/evxfregn: don't release the ContextMutex that
  was never acquired (git-fixes).
- ACPI: resource: Fix memory resource type union access
  (git-fixes).
- acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl
  (git-fixes).
- ASoC: amd: yc: Fix the wrong return value (git-fixes).
- ALSA: usb-audio: Add implicit feedback quirk for Yamaha THR5
  (stable-fixes).
- Bluetooth: hci_event: Fix using rcu_read_(un)lock while
  iterating (git-fixes).
- drm/amdgpu/hdp5.2: do a posting read when flushing HDP
  (stable-fixes).
- drm/dp_mst: Verify request type in the corresponding down
  message reply (stable-fixes).
- drm/dp_mst: Fix MST sideband message body length check
  (stable-fixes).
- dma-buf: fix dma_fence_array_signaled v4 (stable-fixes).
- drm/amdgpu/vcn: reset fw_shared when VCPU buffers corrupted
  on vcn v4.0.3 (stable-fixes).
- ASoC: amd: yc: Add quirk for microphone on Lenovo Thinkpad
  T14s Gen 6 21M1CTO1WW (stable-fixes).
- ASoC: amd: yc: fix internal mic on Redmi G 2022 (stable-fixes).
- driver core: fw_devlink: Stop trying to optimize cycle detection
  logic (git-fixes).
- ACPI: x86: Clean up Asus entries in acpi_quirk_skip_dmi_ids[]
  (stable-fixes).
- ACPI: x86: Add skip i2c clients quirk for Acer Iconia One 8
  A1-840 (stable-fixes).
- drm/bridge: it6505: Fix inverted reset polarity (git-fixes).
- drm/amdgpu: set the right AMDGPU sg segment limitation
  (stable-fixes).
- drm/amdgpu: skip amdgpu_device_cache_pci_state under sriov
  (stable-fixes).
- drm/sched: memset() 'job' in drm_sched_job_init()
  (stable-fixes).
- drm/panel: simple: Add Microchip AC69T88A LVDS Display panel
  (stable-fixes).
- drm/amdgpu: refine error handling in amdgpu_ttm_tt_pin_userptr
  (stable-fixes).
- drm/amdgpu: Dereference the ATCS ACPI buffer (stable-fixes).
- drm/amdgpu: clear RB_OVERFLOW bit when enabling interrupts
  for vega20_ih (stable-fixes).
- drm/radeon/r600_cs: Fix possible int overflow in
  r600_packet3_check() (stable-fixes).
- drm/display: Fix building with GCC 15 (stable-fixes).
- drm/mcde: Enable module autoloading (stable-fixes).
- drm/bridge: it6505: Enable module autoloading (stable-fixes).
- drm: panel-orientation-quirks: Add quirk for AYA NEO GEEK
  (stable-fixes).
- drm: panel-orientation-quirks: Add quirk for AYA NEO Founder
  edition (stable-fixes).
- drm: panel-orientation-quirks: Add quirk for AYA NEO 2 model
  (stable-fixes).
- drm/vc4: hvs: Set AXI panic modes for the HVS (stable-fixes).
- drm/vc4: hdmi: Avoid log spam for audio start failure
  (stable-fixes).
- ASoC: hdmi-codec: reorder channel allocation list
  (stable-fixes).
- dma-debug: fix a possible deadlock on radix_lock (stable-fixes).
- Bluetooth: hci_core: Fix not checking skb length on
  hci_acldata_packet (stable-fixes).
- Bluetooth: btusb: Add RTL8852BE device 0489:e123 to device
  tables (stable-fixes).
- Bluetooth: L2CAP: do not leave dangling sk pointer on error
  in l2cap_sock_create() (stable-fixes).
- ACPI: x86: Make UART skip quirks work on PCI UARTs without an
  UID (stable-fixes).
- ASoC: Intel: sof_sdw: add quirk for Dell SKU 0B8C
  (stable-fixes).
- ASoC: Intel: sof_sdw: fix jack detection on ADL-N variant RVP
  (stable-fixes).
- drm/bridge: it6505: update usleep_range for RC circuit charge
  time (stable-fixes).
- can: gs_usb: add VID/PID for Xylanta SAINT3 product family
  (stable-fixes).
- driver core: Add FWLINK_FLAG_IGNORE to completely ignore a
  fwnode link (stable-fixes).
- driver core: fw_devlink: Improve logs for cycle detection
  (stable-fixes).
- Bluetooth: ISO: Reassociate a socket with an active BIS
  (stable-fixes).
- commit e98af40

- selftests/bpf: Test PROBE_MEM of VSYSCALL_ADDR on x86-64
  (git-fixes).
- bpf, x86: Fix PROBE_MEM runtime load check (git-fixes).
- commit 2300edd

- bpf: verifier: prevent userspace memory access (git-fixes).
- commit d3fc797

- bpf: Check validity of link-&amp;gt;type in bpf_link_show_fdinfo()
  (bsc#1233772 CVE-2024-53099).
- commit 8a3e410

- x86/static-call: fix 32-bit build (git-fixes).
  Branch maintainer: Fix git-fixes warning when merging backport of
  upstream 0ef8047b737d.
  We don't support 32bit but fix is innocuous so we may as well take
  it vs blacklisting.
- commit 74a7f88

- nfsd: restore callback functionality for NFSv4.0 (git-fixes).
- commit 4f425ba

- jffs2: Fix rtime decompressor (git-fixes).
- commit 2f65fdf

- proc/softirqs: replace seq_printf with seq_put_decimal_ull_width
  (git-fixes).
- commit 5dd7a98

- 9p: v9fs_fid_find: also lookup by inode if not found dentry
  (git-fixes).
- commit 1b79331

- NFS/pnfs: Fix a live lock between recalled layouts and layoutget
  (git-fixes).
- commit 996e161

- jffs2: Prevent rtime decompress memory corruption (git-fixes).
- commit cb042eb

- jfs: add a check to prevent array-index-out-of-bounds in
  dbAdjTree (git-fixes).
- commit 25ee5c2

- jfs: fix array-index-out-of-bounds in jfs_readdir (git-fixes).
- commit 5229c06

- jfs: fix shift-out-of-bounds in dbSplit (git-fixes).
- commit 865ea26

- jfs: array-index-out-of-bounds fix in dtReadFirst (git-fixes).
- commit ed99429

- xfs: return from xfs_symlink_verify early on V4 filesystems
  (git-fixes).
- commit 5b38871

- xfs: fix sb_spino_align checks for large fsblock sizes
  (git-fixes).
- commit 241e030

- nilfs2: fix buffer head leaks in calls to truncate_inode_pages()
  (git-fixes).
- commit 8d5832a

- nilfs2: prevent use of deleted inode (git-fixes).
- commit 73e5fc2

- wifi: ath5k: add PCI ID for Arcadyan devices (git-fixes).
- wifi: ath5k: add PCI ID for SX76X (git-fixes).
- genirq/irqdesc: Honor caller provided affinity in alloc_desc()
  (git-fixes).
- genirq/cpuhotplug: Retry with cpu_online_mask when migration
  fails (git-fixes).
- genirq/cpuhotplug: Skip suspended interrupts when restoring
  affinity (git-fixes).
- irqflags: Explicitly ignore lockdep_hrtimer_exit() argument
  (git-fixes).
- arch: consolidate arch_irq_work_raise prototypes (git-fixes).
- commit 8315804

- blk-cgroup: Fix UAF in blkcg_unpin_online() (bsc#1234726).
- commit b60b794

- af_unix: Call manage_oob() for every skb in
  unix_stream_read_generic() (bsc#1234725).
- commit 03c4c99

- idpf: fix idpf_vc_core_init error path (CVE-2024-53064
  bsc#1233558 bsc#1234464).
- commit a3dcc3f

- ACPI/HMAT: Move HMAT messages to pr_debug() (bsc#1234294)
- commit ca90bb6

- x86/xen: use new hypercall functions instead of hypercall page
  (XSA-466 CVE-2024-53241 bsc#1234282).
- commit 6b3f759

- x86/xen: add central hypercall functions (XSA-466 CVE-2024-53241
  bsc#1234282).
- commit 46aadaa

- x86/xen: don't do PV iret hypercall through hypercall page
  (XSA-466 CVE-2024-53241 bsc#1234282).
- commit 65b9ccb

- x86/static-call: provide a way to do very early static-call
  updates (XSA-466 CVE-2024-53241 bsc#1234282).
- commit ad3c5c8

- objtool/x86: allow syscall instruction (XSA-466 CVE-2024-53241
  bsc#1234282).
- commit 05fb6a1

- x86: make get_cpu_vendor() accessible from Xen code (XSA-466
  CVE-2024-53241 bsc#1234282).
- commit e26e99c

- xen/netfront: fix crash when removing device (XSA-465
  CVE-2024-53240 bsc#1234281).
- commit a1f1eb9

- kdb: Use the passed prompt in kdb_position_cursor()
  (bsc#1234654).
- commit c2f5353

- tpm_tis_spi: Release chip select when flow control fails (bsc#1234338)
- commit d89ca9b

- kdb: address -Wformat-security warnings (bsc#1234659).
- commit 4f4b3af

- kdb: Use format-specifiers rather than memset() for padding
  in kdb_read() (bsc#1234658).
- commit 4289748

- kdb: Merge identical case statements in kdb_read()
  (bsc#1234657).
- commit a8f379d

- kdb: Fix console handling when editing and tab-completing
  commands (bsc#1234655).
- commit dfcc116

- kdb: Use format-strings rather than '\0' injection in kdb_read()
  (bsc#1234654).
- commit 02dd473

- kdb: Fix buffer overflow during tab-complete (bsc#1234652).
- commit aa371d8

- kgdb: Flush console before entering kgdb on panic (bsc#1234651).
- commit 56f2413

- Update
  patches.suse/Bluetooth-hci_event-Align-BR-EDR-JUST_WORKS-paring-w.patch
  (git-fixes, bsc#1230697, CVE-2024-8805).
- commit c30f45f

- bpf: sync_linked_regs() must preserve subreg_def (bsc#1234156
  CVE-2024-53125).
- commit 84688aa

- s390/cpum_sf: Remove WARN_ON_ONCE statements (git-fixes).
- commit aa00e1d

- s390/facility: Disable compile time optimization for
  decompressor code (git-fixes).
- commit 0a4f48e

- s390/cpum_sf: Handle CPU hotplug remove during sampling
  (git-fixes).
- commit 775e5ae

- s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()
  (git-fixes).
- commit 7e74f7b

- s390/pageattr: Implement missing kernel_page_present()
  (git-fixes).
- commit 566fa19

- s390/cio: Do not unregister the subchannel based on DNV
  (git-fixes).
- commit 1c87aa1

- net: Make copy_safe_from_sockptr() match documentation
  (git-fixes CVE-2024-36915 bsc#1225758).
- commit 169ff54

- IB/mlx5: Allocate resources just before first QP/SRQ is created (git-fixes)
  Refresh patches.suse/RDMA-mlx5-Move-events-notifier-registration-to-be-af.patch
- commit 1acdd4a

- arm64: Ensure bits ASID[15:8] are masked out when the kernel uses (bsc#1234605)
- commit ac850b9

- autofs: fix memory leak of waitqueues in autofs_catatonic_mode
  (git-fixes).
- Refresh
  patches.suse/autofs-use-wake_up-instead-of-wake_up_interruptible.patch.
- commit 232ce22

- Delete patches.suse/NFSD-Convert-the-callback-workqueue-to-use-delayed_w.patch.  (bsc#1233837)
- Delete patches.suse/NFSD-Reschedule-CB-operations-when-backchannel-rpc_c.patch.  (bsc#1233837)
- commit 5e13c63

- Update references for patches.suse/net-mlx5e-CT-Fix-null-ptr-deref-in-add-rule-err-flow.patch (CVE-2024-53120 bsc#1234075 git-fixes).
- commit 76825cc

- kabi/severities: make vcap_find_actionfield PASS (bsc#1220773)
- commit 9b653b7

- locking/atomic/x86: Correct the definition of __arch_try_cmpxchg128() (bsc#1220773 git-fix).
- commit 60d5cb5

- parisc: Raise minimal GCC version to 12.0.0 (bsc#1220773 git-fix).
- commit 99aca5f

- percpu: Fix self-assignment of __old in raw_cpu_generic_try_cmpxchg() (bsc#1220773 git-fix).
- commit ceecf8a

- rpm/kernel-binary.spec.in: fix KMPs build on 6.13+ (bsc#1234454)
  Upstream commit 822b11a74ba2 (kbuild: use absolute path in the generated
  wrapper Makefile) sets also KBUILD_OUTPUT in objdir's Makefile before
  including srcdir's Makefile.
  So emulate this too, otherwise KMPs fail to build:
  /usr/src/linux-6.13.0-rc2-1.gf92fc5d/Makefile:782: /usr/src/linux-6.13.0-rc2-1.gf92fc5d/include/config/auto.conf: No such file or directory
- commit 46168e5

- Bluetooth: SCO: Add support for 16 bits transparent voice
  setting (git-fixes).
- Bluetooth: iso: Fix recursive locking warning (git-fixes).
- batman-adv: Do not let TT changes list grows indefinitely
  (git-fixes).
- batman-adv: Remove uninitialized data in full table TT response
  (git-fixes).
- batman-adv: Do not send uninitialized TT changes (git-fixes).
- wifi: mac80211: fix station NSS capability initialization order
  (git-fixes).
- wifi: nl80211: fix NL80211_ATTR_MLO_LINK_ID off-by-one
  (git-fixes).
- commit 54fd934

- vsock: fix recursive -&amp;gt;recvmsg calls (CVE-2024-44996 bsc#1230205)
- commit d60b119

- bpf: Fix out-of-bounds write in trie_get_next_key() (CVE-2024-50262 bsc#1233239)
- commit 31aa98f

- Update references for patches.suse/bpf-arm64-Fix-address-emission-with-tag-based-KASAN-enabled.patch (CVE-2024-50203 bsc#1233328 git-fixes)
- commit 6ae65a2

- pmdomain: imx93-blk-ctrl: correct remove path (CVE-2024-53134 bsc#1234159)
- commit 3b944bf

- mptcp: cope racing subflow creation in mptcp_rcv_space_adjust (CVE-2024-53122 bsc#1234076)
- commit 129e03d

- virtio/vsock: Improve MSG_ZEROCOPY error handling (CVE-2024-53117 bsc#1234079)
- commit 827fecc

- virtio/vsock: Fix accept_queue memory leak (CVE-2024-53119 bsc#1234073)
- commit 506378c

- vsock: Fix sk_error_queue memory leak (CVE-2024-53118 bsc#1234071)
- commit 0bc6237

- drm/i915/hdcp: Add encoder check in hdcp2_get_capability (CVE-2024-53050 bsc#1233546)
- commit 410a89a

- iommu/io-pgtable-arm: Fix stage-2 map/unmap for concatenated
  tables (git-fixes).
- commit 0c9ae1f

- xfs: remove unknown compat feature check in superblock write
  validation (git-fixes).
- commit 6933b9b

- xfs: sb_spino_align is not verified (git-fixes).
- commit de8458a

- xfs: don't allocate COW extents when unsharing a hole
  (git-fixes).
- commit 3a93bda

- ocfs2: free inode when ocfs2_get_init_inode() fails (git-fixes).
- commit 04cafb7

- ocfs2: fix uninitialized value in ocfs2_file_read_iter()
  (git-fixes).
- commit e44ccda

- nilfs2: fix potential out-of-bounds memory access in
  nilfs_find_entry() (git-fixes).
- commit cb9e5a0

- jffs2: fix use of uninitialized variable (git-fixes).
- commit 63ec3f3

- ubifs: authentication: Fix use-after-free in
  ubifs_tnc_end_commit (git-fixes).
- commit 7f48142

- ubifs: Correct the total block count by deducting journal
  reservation (git-fixes).
- commit 3145547

- igb: Fix potential invalid memory access in igb_init_module()
  (git-fixes).
- ixgbe: downgrade logging of unsupported VF API version to debug
  (git-fixes).
- ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5
  (git-fixes).
- ice: fix PHY Clock Recovery availability check (git-fixes).
- net/mlx5e: Remove workaround to avoid syndrome for internal port
  (git-fixes).
- net/qed: allow old cards not supporting &amp;quot;num_images&amp;quot; to work
  (git-fixes).
- bnxt_en: Fix receive ring space parameters when XDP is active
  (git-fixes).
- bnxt_en: Set backplane link modes correctly for ethtool
  (git-fixes).
- bnxt_en: Reserve rings after PCIe AER recovery if NIC interface
  is down (git-fixes).
- vdpa/mlx5: Fix suboptimal range on iotlb iteration (git-fixes).
- i40e: Fix handling changed priv flags (git-fixes).
- ice: consistently use q_idx in ice_vc_cfg_qs_msg() (git-fixes).
- Revert &amp;quot;igb: Disable threaded IRQ for igb_msix_other&amp;quot;
  (git-fixes).
- net/mlx5e: CT: Fix null-ptr-deref in add rule err flow
  (git-fixes).
- net/mlx5e: clear xdp features on non-uplink representors
  (git-fixes).
- vdpa/mlx5: Fix PA offset with unaligned starting iotlb map
  (git-fixes).
- vDPA/ifcvf: Fix pci_read_config_byte() return code handling
  (git-fixes).
- vdpa: solidrun: Fix UB bug with devres (git-fixes).
- drivers: net: ionic: add missed debugfs cleanup to ionic_probe()
  error path (git-fixes).
- ice: change q_index variable type to s16 to store -1 value
  (git-fixes).
- Octeontx2-pf: Free send queue buffers incase of leaf to inner
  (git-fixes).
- devlink: Fix length of eswitch inline-mode (git-fixes).
- net: Return error from sk_stream_wait_connect() if
  sk_wait_event() fails (git-fixes).
- commit fa15ce4

- erofs: avoid debugging output for (de)compressed data
  (git-fixes).
- commit 3480b45

- NFSD: Fix nfsd4_shutdown_copy() (git-fixes).
- commit a4ffb65

- NFSD: Async COPY result needs to return a write verifier
  (git-fixes).
- commit e395e20

- sunrpc: handle -ENOTCONN in xs_tcp_setup_socket() (git-fixes).
- commit 4da96b5

- svcrdma: Address an integer overflow (git-fixes).
- commit b19353d

- NFSD: Remove a never-true comparison (git-fixes).
- commit 931734c

- NFSD: Prevent NULL dereference in nfsd4_process_cb_update()
  (git-fixes).
- commit ea6cf72

- NFSD: Cap the number of bytes copied by nfs4_reset_recoverydir()
  (git-fixes).
- commit 046d0f2

- nfsd: make sure exp active before svc_export_show (git-fixes).
- commit 2126f12

- nfsd: release svc_expkey/svc_export with rcu_work (git-fixes).
- commit e769a61

- svcrdma: fix miss destroy percpu_counter in svc_rdma_proc_init()
  (git-fixes).
- commit e0af091

- NFSv4.0: Fix a use-after-free problem in the asynchronous open()
  (git-fixes).
- commit 9d06142

- SUNRPC: timeout and cancel TLS handshake with -ETIMEDOUT
  (git-fixes).
- commit 6f9adf8

- sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport
  (git-fixes).
- commit 053db51

- nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur
  (git-fixes).
- commit 2eafa33

- SUNRPC: make sure cache entry active before cache_show
  (git-fixes).
- commit 8e9b27b

- NFSD: Prevent a potential integer overflow (git-fixes).
- commit 1b6cbfa

- exfat: fix uninit-value in __exfat_get_dentry_set (git-fixes).
- commit 6f6d820

- hfsplus: don't query the device logical block size multiple
  times (git-fixes).
- commit 163ca69

- afs: Fix missing subdir edit when renamed between parent dirs
  (git-fixes).
- commit f215f1c

- afs: Automatically generate trace tag enums (git-fixes).
- commit 6c948f0

- jfs: xattr: check invalid xattr size more strictly (git-fixes).
- commit 74de9a6

- drm/amd/display: Add HDR workaround for specific eDP
  (stable-fixes).
- commit 343cf80

- drm/amd/display: Allow backlight to go below
  `AMDGPU_DM_DEFAULT_MIN_BACKLIGHT` (stable-fixes).
- drm/amdkfd: Fix resource leak in criu restore queue
  (stable-fixes).
- drm/amdgpu: enable gfxoff quirk on HP 705G4 (stable-fixes).
- drm/amdgpu: add raven1 gfxoff quirk (stable-fixes).
- drm/amdgpu/gfx10: use rlc safe mode for soft recovery
  (stable-fixes).
- drm/amdgpu/gfx11: use rlc safe mode for soft recovery
  (stable-fixes).
- drm/amd/display: Fix Synaptics Cascaded Panamera DSC
  Determination (stable-fixes).
- drm/printer: Allow NULL data in devcoredump printer
  (stable-fixes).
- drm/amdgpu/gfx9: use rlc safe mode for soft recovery
  (stable-fixes).
- drm/amdgpu: Block MMR_READ IOCTL in reset (stable-fixes).
- drm/radeon/r100: Handle unknown family in
  r100_cp_init_microcode() (stable-fixes).
- drm/amdgpu: fix unchecked return value warning for amdgpu_gfx
  (stable-fixes).
- drm/amd/display: Revert Avoid overflow assignment
  (stable-fixes).
- drm/amd/display: Use gpuvm_min_page_size_kbytes for DML2
  surfaces (stable-fixes).
- drm/amd/display: Avoid overflow assignment in link_dp_cts
  (stable-fixes).
- drm/amdgpu/gfx9: properly handle error ints on all pipes
  (stable-fixes).
- drm/nouveau/gsp: Use the sg allocator for level 2 of radix3
  (stable-fixes).
- drm/amdgpu/umsch: don't execute umsch test when GPU is in
  reset/suspend (stable-fixes).
- drm/amdgpu/pm: Remove gpu_od if it's an empty directory
  (stable-fixes).
- drm/amdgpu: differentiate external rev id for gfx 11.5.0
  (stable-fixes).
- drm/amd/pm: fix the high voltage issue after unload
  (stable-fixes).
- drm/amdgpu: add smu 14.0.1 discovery support (stable-fixes).
- drm/amdgpu/umsch: reinitialize write pointer in hw init
  (stable-fixes).
- commit f0f6440

- Add already cherry-picked ids to AMDGPU patch
- commit bf5122e

- Revert &amp;quot;unicode: Don't special case ignorable code points&amp;quot;
  (stable-fixes).
- crypto: x86/sha256 - Add parentheses around macros' single
  arguments (stable-fixes).
- crypto: qat - disable IOV in adf_dev_stop() (git-fixes).
- accel/habanalabs: fix debugfs files permissions (stable-fixes).
- accel/habanalabs: increase HL_MAX_STR to 64 bytes to avoid
  warnings (stable-fixes).
- accel/habanalabs: export dma-buf only if size/offset multiples
  of PAGE_SIZE (stable-fixes).
- accel/habanalabs/gaudi2: unsecure tpc count registers
  (stable-fixes).
- commit 64f4d90

- netfilter: nf_reject_ipv6: fix potential crash in
  nf_send_reset6() (CVE-2024-50256 bsc#1233200).
- net: napi: Prevent overflow of napi_defer_hard_irqs
  (CVE-2024-50018 bsc#1232419).
- commit bb4ef32

- net: preserve kabi for napi_struct and net_device
  (CVE-2024-50018 bsc#1232419).
- commit 8d46390

- Refresh
  patches.suse/block-sed-opal-add-ioctl-ioc_opal_set_sid_pw.patch.
- commit 85490e8

- Move kABI workaround patch to correct folder
- commit 3c8636b

- afs: Fix lock recursion (bsc#1233637 CVE-2024-53090).
- commit 5df3cda

- nilfs2: propagate directory read errors from nilfs_find_entry()
  (bsc#1233324 CVE-2024-50202).
- commit 3d85d69

- dm cache: fix potential out-of-bounds access on the first resume
  (bsc#1233467, CVE-2024-50278).
- dm cache: optimize dirty bit checking with find_next_bit when
  resizing (bsc#1233467, CVE-2024-50278).
- dm cache: fix flushing uninitialized delayed_work on cache_ctr
  error (bsc#1233467, CVE-2024-50278, bsc#1233469, CVE-2024-50280).
- dm cache: correct the number of origin blocks to match the
  target length (bsc#1233467, CVE-2024-50278).
- commit 44af9e6

- Update References: field,
  patches.suse/dm-cache-fix-out-of-bounds-access-to-the-dirty-bitset-when-resizing.patch
  (bsc#1233467, bsc#1233468, CVE-2024-50278, CVE-2024-50279).
- commit c98dcb1

- netfilter: nf_tables: prefer nft_chain_validate (CVE-2024-41042
  bsc#1228526).
- commit 2eab656

- Delete
  patches.suse/smb-client-Fix-use-after-free-of-network-namespace-.patch
  (bsc#1233642 CVE-2024-53095).
  [hcarvalho: revert because the fix is incomplete. The patch fixes UAF of
  network namespace but causes in another UAF (of the socket) when the
  cifs module is removed].
- commit 928bab1

- kABI fix for netfilter: bridge: replace physindev with physinif
  in nf_bridge_info (CVE-2024-35839 bsc#1224726).
- commit cf24c71

- PCI: Add T_PERST_CLK_US macro (git-fixes).
- PCI: j721e: Add suspend and resume support (git-fixes).
- PCI: j721e: Use T_PERST_CLK_US macro (git-fixes).
- Refresh
  patches.suse/PCI-j721e-Deassert-PERST-after-a-delay-of-PCIE_T_PVP.patch.
- commit 48f05ae

- dmaengine: idxd: Check for driver name match before sva user
  feature (bsc#1234357).
- commit 2a8f3bf

- tpm/eventlog: Limit memory allocations for event logs with
  excessive size (bsc#1233260 bsc#1233259 bsc#1232421).
- commit 9c38d71

- Move upstreamed sound patches into sorted section
- commit 8c19caa

- netfilter: bridge: replace physindev with physinif in
  nf_bridge_info (CVE-2024-35839 bsc#1224726).
- netfilter: propagate net to nf_bridge_get_physindev
  (CVE-2024-35839 bsc#1224726).
- netfilter: nf_queue: remove excess nf_bridge variable
  (CVE-2024-35839 bsc#1224726).
- netfilter: nfnetlink_log: use proper helper for fetching
  physinif (CVE-2024-35839 bsc#1224726).
- commit bcdb77b

- netfilter: nf_tables: use timestamp to check for set element
  timeout (CVE-2024-27397 bsc#1224095).
- netfilter: nft_set_rbtree: .deactivate fails if element has
  expired (CVE-2024-27397 bsc#1224095).
- commit 7c6b7ec

- kABI workaround for struct drm_dp_mst_topology_mgr (git-fixes).
- commit 9d1af7b

- drm/dp_mst: Fix resetting msg rx state after topology removal
  (git-fixes).
- ALSA: usb-audio: Notify xrun for low-latency mode (git-fixes).
- commit 4cb8f05

- drm/amdgpu: prevent BO_HANDLES error from being overwritten
  (git-fixes).
- commit c78cf7d

- platform/x86: thinkpad_acpi: Fix for ThinkPad's with ECFW
  showing incorrect fan speed (stable-fixes).
- commit 16ab399

- serial: 8250_fintek: Add support for F81216E (stable-fixes).
- drm/amdgpu: fix usage slab after free (stable-fixes).
- drm/amdkfd: Use the correct wptr size (stable-fixes).
- drm/radeon: Fix spurious unplug event on radeon HDMI
  (git-fixes).
- drm/amd/pm: update current_socclk and current_uclk in
  gpu_metrics on smu v13.0.7 (stable-fixes).
- ASoC: amd: yc: Add a quirk for microfone on Lenovo ThinkPad
  P14s Gen 5 21MES00B00 (stable-fixes).
- counter: ti-ecap-capture: Add check for clk_enable()
  (git-fixes).
- counter: stm32-timer-cnt: Add check for clk_enable()
  (git-fixes).
- Bluetooth: MGMT: Fix possible deadlocks (git-fixes).
- PCI: Fix use-after-free of slot-&amp;gt;bus on hot remove
  (stable-fixes).
- checkpatch: always parse orig_commit in fixes tag (git-fixes).
- mtd: hyperbus: rpc-if: Add missing MODULE_DEVICE_TABLE
  (git-fixes).
- mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices
  (git-fixes).
- mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device
  (git-fixes).
- mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device
  (git-fixes).
- mfd: da9052-spi: Change read-mask to write-mask (git-fixes).
- drm/etnaviv: flush shader L1 cache after user commandstream
  (stable-fixes).
- Bluetooth: Fix type of len in rfcomm_sock_getsockopt{,_old}()
  (stable-fixes).
- wifi: rtlwifi: Drastically reduce the attempts to read efuse
  in case of failures (stable-fixes).
- clocksource/drivers/timer-ti-dm: Fix child node refcount
  handling (git-fixes).
- clocksource/drivers:sp804: Make user selectable (git-fixes).
- hwmon: (pmbus/core) clear faults after setting smbalert mask
  (git-fixes).
- drm: panel-orientation-quirks: Make Lenovo Yoga Tab 3 X90F
  DMI match less strict (stable-fixes).
- regulator: rk808: Add apply_bit for BUCK3 on RK809
  (stable-fixes).
- can: j1939: fix error in J1939 documentation (stable-fixes).
- platform/x86: dell-wmi-base: Handle META key Lock/Unlock events
  (stable-fixes).
- platform/x86: dell-smbios-base: Extends support to Alienware
  products (stable-fixes).
- soc: qcom: socinfo: fix revision check in qcom_socinfo_probe()
  (git-fixes).
- soc: qcom: Add check devm_kasprintf() returned value
  (stable-fixes).
- firmware: arm_scmi: Reject clear channel request on A2P
  (stable-fixes).
- usb: typec: use cleanup facility for 'altmodes_node'
  (stable-fixes).
- mac80211: fix user-power when emulating chanctx (stable-fixes).
- wifi: iwlwifi: mvm: Use the sync timepoint API in suspend
  (stable-fixes).
- net: usb: qmi_wwan: add Quectel RG650V (stable-fixes).
- usb: add support for new USB device ID 0x17EF:0x3098 for the
  r8152 driver (stable-fixes).
- PCI: j721e: Add reset GPIO to struct j721e_pcie (stable-fixes).
- PCI: cadence: Set cdns_pcie_host_init() global (stable-fixes).
- PCI: cadence: Extract link setup sequence from
  cdns_pcie_host_setup() (stable-fixes).
- PCI: cpqphp: Use PCI_POSSIBLE_ERROR() to check config reads
  (stable-fixes).
- drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw
  (stable-fixes).
- drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit
  (stable-fixes).
- drm/radeon: change rdev-&amp;gt;ddev to rdev_to_drm(rdev)
  (stable-fixes).
- drm/radeon: add helper rdev_to_drm(rdev) (stable-fixes).
- checkpatch: check for missing Fixes tags (stable-fixes).
- hwmon: (pmbus_core) Allow to hook PMBUS_SMBALERT_MASK
  (stable-fixes).
- PCI: j721e: Add PCIe 4x lane selection support (stable-fixes).
- PCI: j721e: Add per platform maximum lane settings
  (stable-fixes).
- mtd: hyperbus: rpc-if: Convert to platform remove callback
  returning void (stable-fixes).
- commit c2f6105

- nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint
  (bsc#1234219 CVE-2024-53130).
- commit c6f7b3e

- nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint
  (bsc#1234220 CVE-2024-53131).
- commit 6de8c49

- Update tags in
  patches.suse/udf-refactor-inode_bmap-to-handle-error.patch
  (bsc#1234242 bsc#1233096 CVE-2024-50211).
- commit 18aa07e

- Update tags in:
  patches.suse/udf-fix-uninit-value-use-in-udf_get_fileshortad.patch
  (bsc#1234243 bsc#1233038 CVE-2024-50143).
- commit 420cdda

- mm: fix NULL pointer dereference in alloc_pages_bulk_noprof
  (CVE-2024-53113 bsc#1234077).
- commit 0c80b5e

- mm/mremap: fix address wraparound in move_page_tables()
  (CVE-2024-53111 bsc#1234086).
- commit 85bf967

- mm: page_alloc: move mlocked flag clearance into
  free_pages_prepare() (CVE-2024-53105 bsc#1234069).
- commit d988d1d

- kABI: Restore deleted EXPORT_SYMBOL(__qdisc_calculate_pkt_len)
  (CVE-2024-50039 bsc#1231909).
- commit cc27caf

- net/ipv6: release expired exception dst cached in socket
  (bsc#1216813).
- commit 138c9d6

- Update
  patches.suse/initramfs-avoid-filename-buffer-overrun.patch
  (CVE-2024-53142 bsc#1232436).
- commit d5d0ad8

- drm/amd/display: Handle dml allocation failure to avoid crash (bsc#1234221 CVE-2024-53133)
  Added an additional fixes tag refering to commit abd26a3252cb (&amp;quot;drm/amd/display:
  Add dml2 copy functions&amp;quot;).
- commit 100a7fa

- net/sched: accept TCA_STAB only for root qdisc (CVE-2024-50039
  bsc#1231909).
- commit 72cfcc2

- sched/numa: fix memory leak due to the overwritten
  vma-&amp;gt;numab_state (git fixes (sched/numa)).
- commit 639ae96

- netfilter: nft_set_pipapo: do not free live element
  (CVE-2024-26924 bsc#1223387).
- commit e933c39

- net: bridge: mcast: wait for previous gc cycles when removing
  port (CVE-2024-44934 bsc#1229809).
- commit 4999b27

- scsi: storvsc: Do not flag MAINTENANCE_IN return of
  SRB_STATUS_DATA_OVERRUN as an error (git-fixes).
- net :mana :Request a V2 response version for MANA_QUERY_GF_STAT
  (git-fixes).
- commit 5ae2067

- iio: magnetometer: yas530: use signed integer type for clamp
  limits (git-fixes).
- scatterlist: fix incorrect func name in kernel-doc (git-fixes).
- kasan: make report_lock a raw spinlock (git-fixes).
- commit c03eb5e

- ASoC: Intel: avs: da7219: Remove suspend_pre() and resume_post()
  (stable-fixes).
- ALSA: hda/realtek: Add support for Samsung Galaxy Book3 360
  (NP730QFG) (stable-fixes).
- ALSA: hda/realtek: Enable mute and micmute LED on HP ProBook
  430 G8 (stable-fixes).
- ALSA: usb-audio: add mixer mapping for Corsair HS80
  (stable-fixes).
- ALSA: hda/conexant: fix Z60MR100 startup pop issue
  (stable-fixes).
- commit 8c25a0a

- drm/v3d: Enable Performance Counters before clearing them
  (git-fixes).
- drm/sti: Add __iomem for mixer_dbg_mxn's parameter (git-fixes).
- dma-fence: Use kernel's sort for merging fences (git-fixes).
- dma-fence: Fix reference leak on fence merge failure path
  (git-fixes).
- ASoC: mediatek: mt8188-mt6359: Remove hardcoded dmic codec
  (git-fixes).
- ASoC: SOF: ipc3-topology: fix resource leaks in
  sof_ipc3_widget_setup_comp_dai() (git-fixes).
- ALSA: usb-audio: Fix a DMA to stack memory bug (git-fixes).
- regmap: detach regmap from dev on regmap_exit (git-fixes).
- spi: mpc52xx: Add cancel_work_sync before module remove
  (git-fixes).
- mmc: core: Further prevent card detect during shutdown
  (git-fixes).
- commit 87e627e

- block, bfq: fix procress reference leakage for bfqq in merge
  chain (bsc#1234280).
- commit e551f87

- block, bfq: fix uaf for accessing waker_bfqq after splitting
  (bsc#1234279).
- commit 82b47d2

- ext4: allow for the last group to be marked as trimmed
  (bsc#1234278).
- commit 086b5d2

- net/mlx5e: kTLS, Fix incorrect page refcounting (CVE-2024-53138
  bsc#1234223).
- ice: protect XDP configuration with a mutex (CVE-2024-46765
  bsc#1230807).
- sch/netem: fix use after free in netem_dequeue (CVE-2024-46800
  bsc#1230827).
- commit c9f3783

- vp_vdpa: fix id_table array not null terminated error
  (CVE-2024-53110 bsc#1234085).
- commit ffc9457

- net/mlx5: fs, lock FTE when checking if active (CVE-2024-53121
  bsc#1234078).
- mlxsw: spectrum_ipip: Fix memory leak when changing remote
  IPv6 address (CVE-2024-50252 bsc#1233201).
- commit 06c045b

- netdevsim: copy addresses for both in and out paths (git-fixes).
- commit daf115e

- can: j1939: j1939_session_new(): fix skb reference counting
  (git-fixes).
- can: mcp251xfd: mcp251xfd_get_tef_len(): work around erratum
  DS80000789E 6 (git-fixes).
- can: ems_usb: ems_usb_rx_err(): fix {rx,tx}_errors statistics
  (git-fixes).
- can: sun4i_can: sun4i_can_err(): fix {rx,tx}_errors statistics
  (git-fixes).
- can: sja1000: sja1000_err(): fix {rx,tx}_errors statistics
  (git-fixes).
- can: hi311x: hi3110_can_ist(): fix {rx,tx}_errors statistics
  (git-fixes).
- can: ifi_canfd: ifi_canfd_handle_lec_err(): fix {rx,tx}_errors
  statistics (git-fixes).
- can: m_can: m_can_handle_lec_err(): fix {rx,tx}_errors
  statistics (git-fixes).
- can: hi311x: hi3110_can_ist(): fix potential use-after-free
  (git-fixes).
- can: sun4i_can: sun4i_can_err(): call can_change_state()
  even if cf is NULL (git-fixes).
- can: c_can: c_can_handle_bus_err(): update statistics if skb
  allocation fails (git-fixes).
- can: dev: can_set_termination(): allow sleeping GPIOs
  (git-fixes).
- HID: wacom: fix when get product name maybe null pointer
  (git-fixes).
- watchdog: rti: of: honor timeout-sec property (git-fixes).
- watchdog: mediatek: Make sure system reset gets asserted in
  mtk_wdt_restart() (git-fixes).
- watchdog: apple: Actually flush writes after requesting watchdog
  restart (git-fixes).
- iTCO_wdt: mask NMI_NOW bit for update_no_reboot_bit() call
  (git-fixes).
- commit 535e699

- arm64: dts: rockchip: Correct GPIO polarity on brcm BT nodes (git-fixes)
- commit ed87dba

- arm64: dts: rockchip: remove num-slots property from (git-fixes)
- commit cb47197

- kABI: Restore exported __arm_smccc_sve_check (git-fixes)
- commit 3817c3a

- drm/i915/hdcp: Add encoder check in intel_hdcp_get_capability (CVE-2024-53051 bsc#1233547)
- commit 5262489

- mctp i2c: handle NULL header address (CVE-2024-53043 bsc#1233523)
- commit 5a81634

- wifi: iwlwifi: mvm: fix 6 GHz scan construction (CVE-2024-53055 bsc#1233550)
- commit c2d5beb

- drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy() (CVE-2024-53056 bsc#1233568)
- commit 95cef70

- Bluetooth: btnxpuart: Resolve TX timeout error in power save stress test (bsc#1230557)
- commit 9ca14b5

- Bluetooth: btnxpuart: Fix random crash seen while removing driver (CVE-2024-46680 bsc#1230557)
- commit 3831431

- net: dsa: fix netdev_priv() dereference before check on non-DSA netdevice events (CVE-2024-26596 bsc#1220355)
- commit 4861dc8

- net: hns3: fix kernel crash when uninstalling driver (CVE-2024-50296 bsc#1233485)
- commit 6e41fd9

- powerpc/fadump: Move fadump_cma_init to setup_arch() after
  initmem_init() (bsc#1215199).
- powerpc/fadump: Refactor and prepare fadump_cma_init for late
  init (bsc#1215199).
- powerpc/pseries: Use correct data types from pseries_hp_errorlog
  struct (bsc#1215199).
- powerpc/vdso: Inconditionally use CFUNC macro (bsc#1215199).
- powerpc/64s: Fix unnecessary copy to 0 when kernel is booted
  at address 0 (bsc#1215199).
- commit d36d28e

- bpf, arm64: Remove garbage frame for struct_ops trampoline (git-fixes)
- commit e1353aa

- arm64: dts: allwinner: pinephone: Add mount matrix to accelerometer (git-fixes)
- commit 6a9e851

- arm64: dts: freescale: imx8mp-verdin: Fix SD regulator startup delay (git-fixes)
- commit c644bc4

- arm64: dts: freescale: imx8mm-verdin: Fix SD regulator startup delay (git-fixes)
- commit c8b850b

- arm64: tls: Fix context-switching of tpidrro_el0 when kpti is enabled (git-fixes)
- commit dd2d99e

- arm64: fix .data.rel.ro size assertion when CONFIG_LTO_CLANG (git-fixes)
- commit b16f3b1

- arm64: smccc: Remove broken support for SMCCCv1.3 SVE discard hint (git-fixes)
- commit 10c58e2

- arm64: smccc: replace custom COUNT_ARGS() &amp;amp; CONCATENATE() (git-fixes)
- commit 75545f9

- arm64: dts: rockchip: remove orphaned pinctrl-names from pinephone (git-fixes)
- commit cc13a0d

- arm64: dts: rockchip: Fix LED triggers on rk3308-roc-cc (git-fixes)
- commit a83a13f

- arm64: dts: rockchip: Remove #cooling-cells from fan on Theobroma (git-fixes)
- commit ad38ac0

- arm64: dts: rockchip: Remove undocumented supports-emmc property (git-fixes)
- commit 2a5a31d

- arm64: dts: rockchip: Fix bluetooth properties on Rock960 boards (git-fixes)
- commit 8dd2fe4

- arm64: dts: rockchip: Fix bluetooth properties on rk3566 box demo (git-fixes)
- commit af29eab

- arm64: dts: rockchip: fix i2c2 pinctrl-names property on (git-fixes)
- commit bffe233

- arm64: dts: rockchip: Fix reset-gpios property on brcm BT nodes (git-fixes)
- commit 34a0cb0

- arm64: dts: rockchip: Fix wakeup prop names on PineNote BT node (git-fixes)
- commit 600dbb4

- powerpc/kexec: Fix return of uninitialized variable
  (bsc#1194869).
- powerpc/pseries: Fix KVM guest detection for disabling
  hardlockup detector (bsc#1194869).
- powerpc/pseries: Fix dtl_access_lock to be a rw_semaphore
  (bsc#1194869).
- powerpc/mm/fault: Fix kfence page fault reporting (bsc#1194869).
- powerpc/powernv: Free name on error in opal_event_init()
  (bsc#1194869).
- powerpc/atomic: Use YZ constraints for DS-form instructions
  (bsc#1194869).
- powerpc/mm: Fix boot warning with hugepages and
  CONFIG_DEBUG_VIRTUAL (bsc#1194869).
- powerpc/mm: Fix boot crash with FLATMEM (bsc#1194869).
- commit 290216a

- block: Call .limit_depth() after .hctx has been set
  (bsc#1234148).
- commit f4f848a

- arm64: dts: rockchip: Remove hdmi's 2nd interrupt on rk3328 (git-fixes)
- commit 428c79d

- arm64: dts: rockchip: Fix rt5651 compatible value on (git-fixes)
- commit 3b24a1d

- arm64: dts: rockchip: Fix rt5651 compatible value on rk3399-eaidk-610 (git-fixes)
- commit eac58a3

- udf: fix uninit-value use in udf_get_fileshortad (bsc#1234243).
- commit d1c25f9

- udf: refactor inode_bmap() to handle error (bsc#1234242).
- commit df30224

- udf: refactor udf_next_aext() to handle error (bsc#1234241).
- commit 0d11420

- udf: refactor udf_current_aext() to handle error (bsc#1234240).
- commit 9c77357

- udf: prevent integer overflow in udf_bitmap_free_blocks()
  (bsc#1234239).
- commit 76d68df

- arm64: dts: imx8-ss-vpu: Fix imx8qm VPU IRQs (git-fixes)
- commit 225491d

- udf: Fix lock ordering in udf_evict_inode() (bsc#1234238).
- commit c22c8e4

- bpf, arm64: Fix address emission with tag-based KASAN enabled (git-fixes)
- commit a6cd1e5

- udf: udftime: prevent overflow in udf_disk_stamp_to_time()
  (bsc#1234237).
- commit 8f83c05

- arm64: dts: rockchip: Add DTS for FriendlyARM NanoPi R2S Plus (git-fixes)
- commit 8261b13

- arm64: tegra: Move AGX Orin nodes to correct location (git-fixes)
- commit 8c00b3f

- arm64: dts: imx93: add nvmem property for eqos (git-fixes)
- commit 05664af

- arm64: dts: imx93: add nvmem property for fec1 (git-fixes)
- commit 428b0c1

- arm64: dts: imx93: add ocotp node (git-fixes)
- commit 9645cb0

- arm64: dts: imx8qxp: Add VPU subsystem file (git-fixes)
- commit 1bf0ccc

- filemap: add a per-mapping stable writes flag (bsc#1234141).
- commit 110d99d

- readahead: use ilog2 instead of a while loop in
  page_cache_ra_order() (bsc#1234208).
- commit e601535

- quota: simplify drop_dquot_ref() (bsc#1234197).
- commit 1257140

- ext4: fix slab-use-after-free in ext4_es_insert_extent()
  (bsc#1234170).
- commit 1a90d2d

- ext4: make ext4_zeroout_es() return void (bsc#1234170).
- commit cbdfdf7

- ext4: make ext4_es_insert_extent() return void (bsc#1234170).
- commit 93d5ddc

- ext4: make ext4_es_insert_delayed_block() return void
  (bsc#1234170).
- commit e62b7d4

- ext4: make ext4_es_remove_extent() return void (bsc#1234170).
- commit 34c391b

- ext4: using nofail preallocation in ext4_es_insert_extent()
  (bsc#1234170).
- commit 1fd6c4c

- ext4: using nofail preallocation in
  ext4_es_insert_delayed_block() (bsc#1234170).
- commit 7a53aa3

- ext4: using nofail preallocation in ext4_es_remove_extent()
  (bsc#1234170).
- commit a219fcf

- ext4: use pre-allocated es in __es_remove_extent()
  (bsc#1234170).
- commit 0ea150c

- ext4: use pre-allocated es in __es_insert_extent()
  (bsc#1234170).
- commit f357cbb

- ext4: factor out __es_alloc_extent() and __es_free_extent()
  (bsc#1234170).
- commit 2c56856

- ext4: add a new helper to check if es must be kept
  (bsc#1234170).
- commit 63c0132

- filemap: Fix bounds checking in filemap_read() (bsc#1234209).
- commit 3a4a9d6

- mm/readahead: limit page cache size in page_cache_ra_order()
  (bsc#1234208).
- commit c878e72

- fs/writeback: bail out if there is no more inodes for IO and
  queued once (bsc#1234207).
- commit 749caac

- patches.suse/blk-wbt-Fix-detection-of-dirty-throttled-tasks.patch:
  Update tags
- commit da0ffe9

- mm/readahead: do not allow order-1 folio (bsc#1234205).
- commit 88a9212

- mm/filemap: avoid buffered read/write race to read inconsistent
  data (bsc#1234204).
- commit fe65737

- writeback, cgroup: switch inodes with dirty timestamps to
  release dying cgwbs (bsc#1234203).
- commit c53bcd7

- vfs: fix readahead(2) on block devices (bsc#1234201).
- commit c9130e1

- fs-writeback: do not requeue a clean inode having skipped pages
  (bsc#1234200).
- commit c03201b

- isofs: handle CDs with bad root inode but good Joliet root
  directory (bsc#1234199).
- commit 70006a0

- fsnotify: fix sending inotify event with unexpected filename
  (bsc#1234198).
- commit cab81ed

- quota: Fix rcu annotations of inode dquot pointers
  (bsc#1234197).
- commit 5ff0028

- quota: explicitly forbid quota files from being encrypted
  (bsc#1234196).
- commit bcedf7e

- quota: flush quota_release_work upon quota writeback
  (bsc#1234195).
- commit f01f6aa

- ext4: propagate errors from ext4_find_extent() in
  ext4_insert_range() (bsc#1234194).
- commit a2d285b

- ext4: avoid negative min_clusters in find_group_orlov()
  (bsc#1234193).
- commit 53ef0ad

- ext4: avoid potential buffer_head leak in __ext4_new_inode()
  (bsc#1234192).
- commit d719b7d

- ext4: avoid buffer_head leak in ext4_mark_inode_used()
  (bsc#1234191).
- commit be4102e

- ext4: clear EXT4_GROUP_INFO_WAS_TRIMMED_BIT even mount with
  discard (bsc#1234190).
- commit 639ad7f

- ext4: nested locking for xattr inode (bsc#1234189).
- commit 1695943

- ext4: fix incorrect tid assumption in
  jbd2_journal_shrink_checkpoint_list() (bsc#1234188).
- commit 38cda9c

- ext4: fix incorrect tid assumption in
  __jbd2_log_wait_for_space() (bsc#1234188).
- commit 623004d

- ext4: fix incorrect tid assumption in
  ext4_wait_for_tail_page_commit() (bsc#1234188).
- commit caeda6d

- ext4: avoid writing unitialized memory to disk in EA inodes
  (bsc#1234187).
- commit c282dd5

- ext4: check the extent status again before inserting delalloc
  block (bsc#1234186).
- commit d4fbc74

- ext4: factor out a common helper to query extent map
  (bsc#1234186).
- commit cdc4dd6

- ext4: fix uninitialized variable in ext4_inlinedir_to_tree
  (bsc#1234185).
- commit e2e93f7

- ext4: remove the redundant folio_wait_stable() (bsc#1234184).
- commit b11c6f2

- ext4: fix potential unnitialized variable (bsc#1234183).
- commit 26e1d3b

- ext4: set the type of max_zeroout to unsigned int to avoid
  overflow (bsc#1234182).
- commit 0667b2e

- ext4: set type of ac_groups_linear_remaining to __u32 to avoid
  overflow (bsc#1234181).
- commit 8e12e03

- ext4: avoid excessive credit estimate in ext4_tmpfile()
  (bsc#1234180).
- commit ced7ba8

- ext4: correct best extent lstart adjustment logic (bsc#1234179).
- commit 0735258

- ext4: forbid commit inconsistent quota data when
  errors=remount-ro (bsc#1234178).
- commit be3e759

- ext4: correct the hole length returned by ext4_map_blocks()
  (bsc#1234178).
- commit 5fa5898

- ext4: convert to exclusive lock while inserting delalloc extents
  (bsc#1234178).
- commit 840bfbc

- ext4: refactor ext4_da_map_blocks() (bsc#1234178).
- commit b2de03b

- ext4: do not trim the group with corrupted block bitmap
  (bsc#1234177).
- commit bba6b7f

- ext4: fix inconsistent between segment fstrim and full fstrim
  (bsc#1234176).
- commit bd13722

- ext4: mark buffer new if it is unwritten to avoid stale data
  exposure (bsc#1234175).
- commit 4f219a3

- ext4: move 'ix' sanity check to corrent position (bsc#1234174).
- commit 5718e1c

- ext4: remove gdb backup copy for meta bg in
  setup_new_flex_group_blocks (bsc#1234173).
- commit 0b21c6d

- ext4: correct return value of ext4_convert_meta_bg
  (bsc#1234172).
- commit b8da54d

- ext4: add missed brelse in update_backups (bsc#1234171).
- commit a9136e3

- ext4: make sure allocate pending entry not fail (bsc#1234170).
- commit c166e64

- ext4: correct the start block of counting reserved clusters
  (bsc#1234169).
- commit e1691cc

- ext4: fix race between writepages and remount (bsc#1234168).
- commit 6a5446c

- ext4: fix rec_len verify error (bsc#1234167).
- commit 13a341e

- ext4: do not let fstrim block system suspend
  (https://bugzilla.kernel.org/show_bug.cgi?id=216322
  bsc#1234166).
- commit 97d74ff

- ext4: move setting of trimmed bit into ext4_try_to_trim_range()
  (bsc#1234165).
- commit c721601

- ext4: add correct group descriptors and reserved GDT blocks
  to system zone (bsc#1234164).
- commit b2d7f10

- ext4: fix memory leaks in
  ext4_fname_{setup_filename,prepare_lookup} (bsc#1214954).
- commit 858c12d

- ext4: correct grp validation in ext4_mb_good_group
  (bsc#1234163).
- commit 779294e

- ext4: avoid overlapping preallocations due to overflow
  (bsc#1234162).
- commit 8a1e02a

- block, bfq: fix bfqq uaf in bfq_limit_depth() (bsc#1234160).
- commit 261dfc3

- block, bfq: don't break merge chain in bfq_split_bfqq()
  (bsc#1234150).
- commit 3951083

- block, bfq: choose the last bfqq from merge chain in
  bfq_setup_cooperator() (bsc#1234149).
- commit 31f51cb

- block/mq-deadline: Fix the tag reservation code (bsc#1234148).
- commit 7ec4caf

- blk-iocost: do not WARN if iocg was already offlined
  (bsc#1234147).
- commit 01ff221

- Revert &amp;quot;block/mq-deadline: use correct way to throttling write
  requests&amp;quot; (bsc#1234146).
- commit bfb157c

- block: Fix where bio IO priority gets set (bsc#1234145).
- commit 9c05b3f

- blk-iocost: Fix an UBSAN shift-out-of-bounds warning
  (bsc#1234144).
- commit 8757100

- loop: fix the the direct I/O support check when used on top
  of block devices (bsc#1234143).
- commit 19fc4dd

- block: prevent an integer overflow in bvec_try_merge_hw_page
  (bsc#1234142).
- commit 0a4f58a

- block: update the stable_writes flag in bdev_add (bsc#1234141).
- commit 91e3842

- blk-throttle: fix lockdep warning of &amp;quot;cgroup_mutex or RCU read
  lock required!&amp;quot; (bsc#1234140).
- commit 1c37ba4

- blk-core: use pr_warn_ratelimited() in bio_check_ro()
  (bsc#1234139).
- commit d9ec72f

- nfsd: remove unsafe BUG_ON from set_change_info (bsc#1234121).
- commit 6c0f124

- tcp: Fix use-after-free of nreq in reqsk_timer_handler()
  (CVE-2024-50154 bsc#1233070).
- commit 297942f

- f2fs: get out of a repeat loop when getting a locked data page
  (bsc#1234011).
- commit dfe277f

- drm: Expand max DRM device number to full MINORBITS (jsc#PED-11580).
- commit d737023

- accel: Use XArray instead of IDR for minors (jsc#PED-11580).
- commit 013fbaa

- drm: Use XArray instead of IDR for minors (jsc#PED-11580).
- commit b04b73a

- drm/amd/display: fix a UBSAN warning in DML2.1 (bsc#1233115 CVE-2024-50177)
- commit 2f6004f

- smb: client: Fix use-after-free of network namespace
  (bsc#1233642 CVE-2024-53095).
  Also applies:
  smb: client: fix warning in generic_ip_connect()
- commit 97b3d9a

- jbd2: fix kernel-doc for j_transaction_overhead_buffers
  (bsc#1234042).
- commit 20d4b12

- sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start (CVE-2024-49944 bsc#1232166)
- commit c7bd304

- netfilter: nf_tables: prevent nf_skb_duplicated corruption (CVE-2024-49952 bsc#1232157)
- commit d0f307b

- jbd2: Move j_transaction_overhead_buffers into a hole
  (bsc#1234042).
- commit 1c42745

- Update
  patches.suse/drm-amd-display-Adjust-VSDB-parser-for-replay-featur.patch
  (stable-fixes CVE-2024-53108 bsc#1234081).
- Update
  patches.suse/fs-ntfs3-Fixed-overflow-check-in-mi_enum_attr.patch
  (bsc#1233207 CVE-2024-27407 bsc#1224429).
- Update
  patches.suse/ima-fix-buffer-overrun-in-ima_eventdigest_init_commo.patch
  (git-fixes CVE-2024-53106 bsc#1234083).
- Update
  patches.suse/keys-Fix-overwrite-of-key-expiration-on-instantiation.patch
  (git-fixes CVE-2024-36031 bsc#1225713).
- Update
  patches.suse/media-uvcvideo-Skip-parsing-frames-of-type-UVC_VS_UN.patch
  (git-fixes CVE-2024-53104 bsc#1234025).
- Update
  patches.suse/net-relax-socket-state-check-at-accept-time.patch
  (git-fixes CVE-2024-36484 bsc#1226872).
- Update
  patches.suse/nvme-multipath-defer-partition-scanning.patch
  (bsc#122824 git-fixes CVE-2024-53093 bsc#1233640).
- Update
  patches.suse/nvme-tcp-avoid-race-between-queue_lock-lock-and-dest.patch
  (git-fixes CVE-2024-53100 bsc#1233771).
- Update
  patches.suse/ocfs2-uncache-inode-which-has-failed-entering-the-group.patch
  (git-fixes CVE-2024-53112 bsc#1234087).
- Update
  patches.suse/scsi-mpi3mr-Avoid-memcpy-field-spanning-write-WARNING.patch
  (git-fixes CVE-2024-36920 bsc#1225768).
- Update
  patches.suse/scsi-pm80xx-Set-phy-enable_completion-only-when-we-wait-for-it.patch
  (git-fixes CVE-2024-47666 bsc#1231453).
- Update
  patches.suse/tcp-Fix-refcnt-handling-in-__inet_hash_connect.patch
  (git-fixes CVE-2024-26864 bsc#1223112).
- Update
  patches.suse/tracing-osnoise-Use-a-cpumask-to-know-what-threads-are-kthreads.patch
  (git-fixes CVE-2024-46788 bsc#1230817).
- Update
  patches.suse/tracing-timerlat-Move-hrtimer_init-to-timerlat_fd-open.patch
  (git-fixes CVE-2024-26703 bsc#1222423).
- Update
  patches.suse/x86-CPU-AMD-Clear-virtualized-VMLOAD-VMSAVE-on-Zen4-client
  (bsc#1233443 CVE-2024-53114 bsc#1234072).
- commit 420eea1

- Bluetooth: SCO: Fix UAF on sco_sock_timeout (CVE-2024-50125
  bsc#1232928).
- Refresh
  patches.suse/Bluetooth-ISO-Fix-UAF-on-iso_sock_timeout.patch.
  Revert Bluetooth-ISO-Fix-UAF-on-iso_sock_timeout.patch to the upstream
  version of the patch.
  The reverted version was a mix of 1bf4470a and 246b435a, since they were
  accidentally identified as two different commits doing the same changes.
  The changes are indeed mostly the same, but to different files.
- commit 5725fe5

- cgroup/bpf: only cgroup v2 can be attached by bpf programs
  (bsc#1234108).
- Revert &amp;quot;cgroup: Fix memory leak caused by missing
  cgroup_bpf_offline&amp;quot; (bsc#1234108).
- commit 6a48bcc

- kexec_file: fix elfcorehdr digest exclusion when
  CONFIG_CRASH_HOTPLUG=y (git-fixes).
- commit 1b2a54a

- signal: restore the override_rlimit logic (CVE-2024-50271
  bsc#1233460).
- ucounts: fix counter leak in inc_rlimit_get_ucounts()
  (bsc#1233460).
- commit 232c2a6

- hv_sock: Initializing vsk-&amp;gt;trans to NULL to prevent a dangling pointer (git-fixes).
- commit 109e508

- posix-cpu-timers: Clear TICK_DEP_BIT_POSIX_TIMER on clone
  (bsc#1234098).
- commit 362812c

- signal: Replace BUG_ON()s (bsc#1234093).
- commit dad9530

- dm cache: fix out-of-bounds access to the dirty bitset when
  resizing (CVE-2024-50279 bsc#1233468).
- commit 2080b22

- ipv4: ip_tunnel: Fix suspicious RCU usage warning in
  ip_tunnel_init_flow() (CVE-2024-53042 bsc#1233540).
- commit 6649f10

- intel_idle: fix ACPI _CST matching for newer Xeon platforms
  (bsc#1231630).
- commit 0f23b16

- intel_idle: add Granite Rapids Xeon support (bsc#1231630).
- commit 111abfc

- Update config files.
  Enabled IDPF for ARM64 (bsc#1221309)
- commit adee356

- selftests/bpf: validate fake register spill/fill precision
  backtracking logic (bsc#1232823 CVE-2023-52920).
- bpf: handle fake register spill to stack with BPF_ST_MEM
  instruction (bsc#1232823 CVE-2023-52920).
- commit 52cdf87

- btrfs: fix a NULL pointer dereference when failed to start a
  new trasacntion (CVE-2024-49868 bsc#1232272).
- commit cc68ee3

- PCI: j721e: Deassert PERST# after a delay of PCIE_T_PVPERL_MS
  milliseconds (git-fixes).
- PCI: Add T_PVPERL macro (git-fixes).
- commit 664a849

- mm/thp: fix deferred split unqueue naming and locking
  (CVE-2024-53079 bsc#1233570).
- commit b50ea3e

- cxl: downgrade a warning message to debug level in
  cxl_probe_component_regs() (bsc#1229165).
- commit 388d64b

- nvme-fabrics: fix kernel crash while shutting down controller
  (git-fixes).
- nvme-pci: reverse request order in nvme_queue_rqs (git-fixes).
- nvme-pci: fix freeing of the HMB descriptor table (git-fixes).
- nvme/host: Fix RCU list traversal to use SRCU primitive
  (git-fixes).
- commit 9f9c907

- nvme-loop: flush off pending I/O while shutting down loop
  controller (git-fixes).
- commit 85bcc27

- Rename to
  patches.suse/nvme-multipath-defer-partition-scanning.patch. (git-fixes bsc#122824)
- commit 79fcf69

- nvme: tcp: avoid race between queue_lock lock and destroy
  (git-fixes).
- commit 0d6537a

- Update
  patches.suse/scsi-qla2xxx-Update-version-to-10.02.09.300-k.patch
  (bsc#1228850 jsc#PED-9943 jsc#PED-11316).
  This is the latest greatest version of qla2xxx. Add the jira
  reference so that it is tracked.
- commit 8eff9b2

- scsi: lpfc: Copyright updates for 14.4.0.6 patches (bsc#1233241
  jsc#PED-9943).
- scsi: lpfc: Update lpfc version to 14.4.0.6 (bsc#1233241
  jsc#PED-9943).
- scsi: lpfc: Change lpfc_nodelist nlp_flag member into a bitmask
  (bsc#1233241 jsc#PED-9943).
- scsi: lpfc: Remove NLP_RELEASE_RPI flag from nodelist structure
  (bsc#1233241 jsc#PED-9943).
- scsi: lpfc: Prevent NDLP reference count underflow in
  dev_loss_tmo callback (bsc#1233241 jsc#PED-9943).
- scsi: lpfc: Add cleanup of nvmels_wq after HBA reset
  (bsc#1233241 jsc#PED-9943).
- scsi: lpfc: Check SLI_ACTIVE flag in FDMI cmpl before submitting
  follow up FDMI (bsc#1233241 jsc#PED-9943).
- scsi: lpfc: Update lpfc_els_flush_cmd() to check for SLI_ACTIVE
  before BSG flag (bsc#1233241 jsc#PED-9943).
- scsi: lpfc: Call lpfc_sli4_queue_unset() in restart and rmmod
  paths (bsc#1233241 jsc#PED-9943).
- scsi: lpfc: Check devloss callbk done flag for potential stale
  NDLP ptrs (bsc#1233241 jsc#PED-9943).
- scsi: lpfc: Modify CGN warning signal calculation based on
  EDC response (bsc#1233241 jsc#PED-9943).
- commit 566c7c9

- mm: always initialise folio-&amp;gt;_deferred_list (CVE-2024-53079
  bsc#1233570 prerequisity).
- commit 3c832a9

- mm/hugetlb: fix nodes huge page allocation when there are
  surplus pages (bsc#1234012).
- commit 9fde6f7

- Input: xpad - add support for MSI Claw A1M (git-fixes).
- commit d37ec4c

- Input: xpad - add support for 8BitDo Ultimate 2C Wireless
  Controller (git-fixes).
- commit 0d7bec2

- Input: xpad - add support for Machenike G5 Pro Controller
  (git-fixes).
- commit f071586

- Input: xpad - sort xpad_device by vendor and product ID
  (git-fixes).
- Refresh
  patches.suse/Input-xpad-add-support-for-Snakebyte-GAMEPADs.patch.
- commit 5f46bd9

- Input: xpad - add GameSir T4 Kaleid Controller support
  (git-fixes).
- commit d80239f

- Input: xpad - add GameSir VID for Xbox One controllers
  (git-fixes).
- commit 993ca75

- Input: xpad - fix support for some third-party controllers
  (git-fixes).
- commit 1d5b082

- Input: xpad - spelling fixes for &amp;quot;Xbox&amp;quot; (git-fixes).
- Refresh
  patches.suse/Input-xpad-add-HyperX-Clutch-Gladiate-Support.patch.
- Refresh
  patches.suse/Input-xpad-add-Lenovo-Legion-Go-controllers.patch.
- Refresh patches.suse/Input-xpad-add-PXN-V900-support.patch.
- Refresh
  patches.suse/Input-xpad-add-additional-HyperX-Controller-Identifi.patch.
- Refresh
  patches.suse/Input-xpad-add-support-for-ASUS-ROG-RAIKIRI.patch.
- Refresh
  patches.suse/Input-xpad-add-support-for-Snakebyte-GAMEPADs.patch.
- commit 15a1c29

- jbd2: fix soft lockup in journal_finish_inode_data_buffers()
  (bsc#1234046).
- commit f32d01d

- jbd2: correct the printing of write_flags in
  jbd2_write_superblock() (bsc#1234045).
- commit fe6bf4e

- jbd2: fix potential data lost in recovering journal raced with
  synchronizing fs bdev (bsc#1234044).
- commit 5fbdfed

- mm: convert free_transhuge_folio() to
  folio_undo_large_rmappable() (CVE-2024-53079 bsc#1233570
  prerequisity).
- commit 4e7d9f6

- jbd2: avoid memleak in jbd2_journal_write_metadata_buffer
  (bsc#1234043).
- commit ffe100a

- jbd2: precompute number of transaction descriptor blocks
  (bsc#1234042).
- commit 3ed7ebf

- jbd2: make jbd2_journal_get_max_txn_bufs() internal
  (bsc#1234041).
- commit ad2f96f

- jbd2: avoid mount failed when commit block is partial submitted
  (bsc#1234040).
- commit 7226fe5

- jbd2: avoid infinite transaction commit loop (bsc#1234039).
- commit ad1118f

- ext4: fix unttached inode after power cut with orphan file
  feature enabled (bsc#1234009).
- commit 3e057c0

- net: arc: fix the device for dma_map_single/dma_unmap_single
  (CVE-2024-50295 bsc#1233484).
- net: vertexcom: mse102x: Fix possible double free of TX skb
  (CVE-2024-50276 bsc#1233465).
- net: enetc: allocate vf_state during PF probes (CVE-2024-50298
  bsc#1233487).
- net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged
  SKB data (CVE-2024-53058 bsc#1233552).
- commit ae38000

- x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client
  (bsc#1233443).
- commit 5beba61

- x86: Increase brk randomness entropy for 64-bit systems (git-fixes).
- commit 7e88dd7

- x86/resctrl: Remove hard-coded memory bandwidth limit (git-fixes).
- Refresh patches.suse/x86-resctrl-Annotate-get_mem_config-functions-as-__init.patch.
- commit 6888d66

- Update
  patches.suse/ASoC-dapm-fix-bounds-checker-error-in-dapm_widget_li.patch
  (git-fixes CVE-2024-53045 bsc#1233524).
- Update
  patches.suse/ASoC-stm32-spdifrx-fix-dma-channel-release-in-stm32_.patch
  (git-fixes CVE-2024-50292 bsc#1233481).
- Update
  patches.suse/HID-core-zero-initialize-the-report-buffer.patch
  (git-fixes CVE-2024-50302 bsc#1233491).
- Update
  patches.suse/USB-serial-io_edgeport-fix-use-after-free-in-debug-p.patch
  (git-fixes CVE-2024-50267 bsc#1233456).
- Update patches.suse/can-bcm-Fix-UAF-in-bcm_proc_show.patch
  (bsc#1012628 CVE-2023-52922 bsc#1233977).
- Update
  patches.suse/drm-amdgpu-add-missing-size-check-in-amdgpu_debugfs_.patch
  (stable-fixes CVE-2024-50282 bsc#1233471).
- Update
  patches.suse/drm-amdgpu-fix-possible-UAF-in-amdgpu_cs_pass1.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-52921
  bsc#1233452).
- Update
  patches.suse/drm-amdgpu-prevent-NULL-pointer-dereference-if-ATIF-.patch
  (git-fixes CVE-2024-53060 bsc#1233554).
- Update
  patches.suse/firmware-arm_scmi-Fix-slab-use-after-free-in-scmi_bu.patch
  (git-fixes CVE-2024-53068 bsc#1233561).
- Update
  patches.suse/fs-Fix-uninitialized-value-issue-in-from_kuid-and-from_kgid.patch
  (git-fixes CVE-2024-53101 bsc#1233769).
- Update
  patches.suse/i40e-fix-race-condition-by-adding-filter-s-intermedi.patch
  (git-fixes CVE-2024-53088 bsc#1233580).
- Update
  patches.suse/iio-gts-helper-Fix-memory-leaks-for-the-error-path-o.patch
  (git-fixes CVE-2024-53076 bsc#1233567).
- Update
  patches.suse/io_uring-rw-fix-missing-NOWAIT-check-for-O_DIRECT-st.patch
  (git-fixes CVE-2024-53052 bsc#1233548).
- Update
  patches.suse/media-ar0521-don-t-overflow-when-checking-PLL-values.patch
  (git-fixes CVE-2024-53081 bsc#1233572).
- Update
  patches.suse/media-cx24116-prevent-overflows-on-SNR-calculus.patch
  (git-fixes CVE-2024-50290 bsc#1233479).
- Update
  patches.suse/media-dvbdev-prevent-the-risk-of-out-of-memory-acces.patch
  (git-fixes CVE-2024-53063 bsc#1233557).
- Update
  patches.suse/media-s5p-jpeg-prevent-buffer-overflows.patch
  (git-fixes CVE-2024-53061 bsc#1233555).
- Update
  patches.suse/media-v4l2-tpg-prevent-the-risk-of-a-division-by-zer.patch
  (git-fixes CVE-2024-50287 bsc#1233476).
- Update
  patches.suse/nfs-Fix-KMSAN-warning-in-decode_getfattr_attrs.patch
  (git-fixes CVE-2024-53066 bsc#1233560).
- Update
  patches.suse/ocfs2-remove-entry-once-instead-of-null-ptr-dereference-in-ocfs2_xa_remove.patch
  (git-fixes CVE-2024-50265 bsc#1233454).
- Update
  patches.suse/platform-x86-amd-pmc-Detect-when-STB-is-not-availabl.patch
  (git-fixes CVE-2024-53072 bsc#1233564).
- Update
  patches.suse/posix-clock-posix-clock-Fix-unbalanced-locking-in-pc.patch
  (CVE-2024-50195 bsc#1233103 CVE-2024-50210 bsc#1233097).
- Update
  patches.suse/scsi-wd33c93-Don-t-use-stale-scsi_pointer-value.patch
  (git-fixes CVE-2024-50026 bsc#1231952).
- Update
  patches.suse/security-keys-fix-slab-out-of-bounds-in-key_task_per.patch
  (git-fixes CVE-2024-50301 bsc#1233490).
- Update
  patches.suse/tpm-Lock-TPM-chip-in-tpm_pm_suspend-first.patch
  (bsc#1082555 git-fixes CVE-2024-53085 bsc#1233577).
- Update
  patches.suse/usb-musb-sunxi-Fix-accessing-an-released-usb-phy.patch
  (git-fixes CVE-2024-50269 bsc#1233458).
- Update
  patches.suse/usb-typec-fix-potential-out-of-bounds-in-ucsi_ccg_up.patch
  (git-fixes CVE-2024-50268 bsc#1233457).
- Update
  patches.suse/wifi-iwlwifi-mvm-Fix-response-handling-in-iwl_mvm_se.patch
  (git-fixes CVE-2024-53059 bsc#1233553).
- Update
  patches.suse/wifi-iwlwifi-mvm-don-t-leak-a-link-on-AP-removal.patch
  (git-fixes CVE-2024-53074 bsc#1233566).
- commit 5a024cd

- x86/tdx: Enable CPU topology enumeration (git-fixes).
- commit cf1674b

- x86/tdx: Dynamically disable SEPT violations from causing #VEs (git-fixes).
- commit 29f8884

- x86/tdx: Rename tdx_parse_tdinfo() to tdx_setup() (git-fixes).
- commit a66f7df

- x86/tdx: Introduce wrappers to read and write TD metadata (git-fixes).
- commit 182660e

- x86/microcode/intel: Remove unnecessary cache writeback and invalidation (git-fixes).
- commit dc97c33

- x86/traps: move kmsan check after instrumentation_begin (git-fixes).
- commit 788cc4b

- x86: fix off-by-one in access_ok() (git-fixes).
- commit ada1011

- x86/syscall: Avoid memcpy() for ia32 syscall_get_arguments() (git-fixes).
- commit a421b7f

- s390/cpum_sf: Convert to cmpxchg128() (bsc#1220773).
- arch: Remove cmpxchg_double (bsc#1220773).
- slub: Replace cmpxchg_double() (bsc#1220773).
- x86,intel_iommu: Replace cmpxchg_double() (bsc#1220773).
- commit e59d679

- x86,amd_iommu: Replace cmpxchg_double() (bsc#1220773).
- Refresh for the above change,
  patches.suse/iommu-amd-Remove-the-unused-struct-amd_ir_data.ref.
- commit 8594442

- parisc: Raise minimal GCC version (bsc#1220773).
- commit 7e72ff3

- percpu: Wire up cmpxchg128 (bsc#1220773).
- Refresh for the above change,
  patches.kabi/kabi-partial-revert-commit-20516d6e51dd.patch.
  patches.suse/x86-Stop-using-weak-symbols-for-__iowrite32_copy.patch.
- commit afeecf1

- percpu: Add {raw,this}_cpu_try_cmpxchg() (bsc#1220773).
- instrumentation: Wire up cmpxchg128() (bsc#1220773).
- arch: Introduce arch_{,try_}_cmpxchg128{,_local}() (bsc#1220773).
- types: Introduce [us]128 (bsc#1220773).
- cyrpto/b128ops: Remove struct u128 (bsc#1220773).
- commit 83bf8ec

- tools/power turbostat: Fix trailing '\n' parsing (git-fixes).
- modpost: remove incorrect code in do_eisa_entry() (git-fixes).
- rtc: ab-eoz9: don't fail temperature reads on undervoltage
  notification (git-fixes).
- rtc: rzn1: fix BCD to rtc_time conversion errors (git-fixes).
- rtc: check if __rtc_read_time was successful in
  rtc_timer_do_work() (git-fixes).
- rtc: abx80x: Fix WDT bit position of the status register
  (git-fixes).
- rtc: bbnsm: add remove hook (git-fixes).
- rtc: st-lpc: Use IRQF_NO_AUTOEN flag in request_irq()
  (git-fixes).
- tty: ldsic: fix tty_ldisc_autoload sysctl's proc_handler
  (git-fixes).
- serial: 8250: omap: Move pm_runtime_get_sync (git-fixes).
- commit 003de2e

- arm64: dts: imx8mp: correct sdhc ipg clk (git-fixes).
- commit babea1e

- arm64: Force position-independent veneers (git-fixes).
- commit a8752e0

- USB: chaoskey: Fix possible deadlock chaoskey_list_lock
  (git-fixes).
- commit bc5d0b3

- ALSA: hda: Show the codec quirk info at probing (stable-fixes).
- ALSA: hda/realtek: Set PCBeep to default value for ALC274
  (stable-fixes).
- ALSA: usb-audio: Fix out of bounds reads when finding clock
  sources (stable-fixes).
- ALSA: pcm: Add sanity NULL check for the default mmap fault
  handler (stable-fixes).
- commit 0da3d44

- drm/amd/display: Fix null check for pipe_ctx-&amp;gt;plane_state in
  hwss_setup_dpp (git-fixes).
- drm/amd/display: Fix null check for pipe_ctx-&amp;gt;plane_state in
  dcn20_program_pipe (git-fixes).
- drm/amd: Add some missing straps from NBIO 7.11.0 (git-fixes).
- ASoC: SOF: ipc3-topology: Convert the topology pin index to
  ALH dai index (git-fixes).
- ASoC: amd: yc: Fix for enabling DMIC on acp6x via _DSD entry
  (git-fixes).
- ALSA: ump: Fix evaluation of MIDI 1.0 FB info (git-fixes).
- ALSA: hda/realtek: Update ALC225 depop procedure (git-fixes).
- ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy
  and Mbox devices (git-fixes).
- ALSA: hda/realtek: Update ALC256 depop procedure (git-fixes).
- ALSA: ac97: bus: Fix the mistake in the comment (git-fixes).
- =?UTF-8?q?iio:=20accel:=20kxcjk-1013:=20Remove=20redundan?=
  =?UTF-8?q?t=20I=C2=B2C=20ID?= (git-fixes).
- iio: Fix fwnode_handle in __fwnode_iio_channel_get_by_name()
  (git-fixes).
- iio: accel: kx022a: Fix raw read format (git-fixes).
- iio: gts: fix infinite loop for gain_to_scaletables()
  (git-fixes).
- iio: gts: Fix uninitialized symbol 'ret' (git-fixes).
- ad7780: fix division by zero in ad7780_write_raw() (git-fixes).
- iio: adc: ad7923: Fix buffer overflow for tx_buf and ring_xfer
  (git-fixes).
- comedi: Flush partial mappings in error case (git-fixes).
- goldfish: Fix unused const variable 'goldfish_pipe_acpi_match'
  (git-fixes).
- iio: adc: ad7606: Fix typo in the driver name (git-fixes).
- iio: light: al3010: Fix an error handling path in al3010_probe()
  (git-fixes).
- misc: apds990x: Fix missing pm_runtime_disable() (git-fixes).
- firmware_loader: Fix possible resource leak in
  fw_log_firmware_info() (git-fixes).
- usb: dwc3: gadget: Fix looping of queued SG entries (git-fixes).
- usb: dwc3: gadget: Fix checking for number of TRBs left
  (git-fixes).
- Revert &amp;quot;usb: gadget: composite: fix OS descriptors w_value
  logic&amp;quot; (git-fixes).
- usb: ehci-spear: fix call balance of sehci clk handling routines
  (git-fixes).
- USB: serial: ftdi_sio: Fix atomicity violation in
  get_serial_info() (git-fixes).
- usb: dwc3: gadget: Add missing check for single port RAM in
  TxFIFO resizing logic (git-fixes).
- usb: musb: Fix hardware lockup on first Rx endpoint request
  (git-fixes).
- usb: xhci: Fix TD invalidation under pending Set TR Dequeue
  (git-fixes).
- USB: chaoskey: fail open after removal (git-fixes).
- usb: yurex: make waiting on yurex_write interruptible
  (git-fixes).
- usb: using mutex lock and supporting O_NONBLOCK flag in
  iowarrior_read() (git-fixes).
- apparmor: fix 'Do simple duplicate message elimination'
  (git-fixes).
- apparmor: test: Fix memory leak for aa_unpack_strdup()
  (git-fixes).
- apparmor: use kvfree_sensitive to free data-&amp;gt;data (git-fixes).
- commit 875afee

- RDMA/hns: Disassociate mmap pages for all uctx when HW is being reset (git-fixes)
- commit 41e9c5b

- icmp: change the order of rate limits (CVE-2024-47678
  bsc#1231854).
- commit 7296c43

- bpf, vsock: Drop static vsock_bpf_prot initialization (git-fixes).
- commit 939d649

- vsock: Update msg_count on read_skb() (git-fixes).
- commit fce5f41

- vsock: Update rx_bytes on read_skb() (git-fixes, bsc#1233320,
  CVE-2024-50169).
- commit acfc5df

- bpf, sockmap: SK_DROP on attempted redirects of unsupported af_vsock (git-fixes).
- commit 8db08f8

- mm: revert &amp;quot;mm: shmem: fix data-race in shmem_getattr()&amp;quot;
  (CVE-2024-50228, bsc#1233204, git fixes (mm/shmem)).
  CVE is likely a non-issue while the fix introduces real bugs.
- commit b77756a

- Bluetooth: MGMT: Fix slab-use-after-free Read in
  set_powered_sync (git-fixes).
- net: mdio-ipq4019: add missing error check (git-fixes).
- net: usb: lan78xx: Fix refcounting and autosuspend on invalid
  WoL configuration (git-fixes).
- net: usb: lan78xx: Fix memory leak on device unplug by freeing
  PHY device (git-fixes).
- net: usb: lan78xx: Fix double free issue with interrupt buffer
  allocation (git-fixes).
- spi: Fix acpi deferred irq probe (git-fixes).
- spi: atmel-quadspi: Fix register name in verbose logging
  function (git-fixes).
- power: supply: rt9471: Use IC status regfield to report real
  charger status (git-fixes).
- power: supply: rt9471: Fix wrong WDT function regfield
  declaration (git-fixes).
- power: supply: bq27xxx: Fix registers of bq27426 (git-fixes).
- power: supply: core: Remove might_sleep() from
  power_supply_put() (git-fixes).
- commit 0e6f9cb

- pktgen: use cpus_read_lock() in pg_net_init() (bsc#1230558
  CVE-2024-46681).
- commit ad3c579

- posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime() (CVE-2024-50195 bsc#1233103)
- commit 6192694

- media: av7110: fix a spectre vulnerability (CVE-2024-50289
  bsc#1233478).
- commit 2969047

- Drop OCFS2 patch causing a regression (bsc#1233255)
  Deleted:
  patches.suse/ocfs2-fix-the-la-space-leak-when-unmounting-an-ocfs2-volume.patch
- commit 2a24fc4

- net: fix out-of-bounds access in ops_init (CVE-2024-36883
  bsc#1225725).
- commit f1b40e8

- efi/memattr: Ignore table if the size is clearly bogus
  (bsc#1231465).
- commit c92a68e

- thermal: int3400: Fix reading of current_uuid for active policy
  (git-fixes).
- gpio: exar: set value when external pull-up or pull-down is
  present (git-fixes).
- gpio: zevio: Add missed label initialisation (git-fixes).
- commit a62e144

- ALSA: hda/realtek: Apply quirk for Medion E15433 (bsc#1233298).
- commit 9a99613

- ice: fix crash on probe for DPLL enabled E810 LOM
  (CVE-2024-53048 bsc#1233721).
- commit 5f7ca77

- Update references for patches.suse/RDMA-siw-Add-sendpage_ok-check-to-disable-MSG_SPLICE.patch (bsc#1233641 CVE-2024-53094)
- commit 1f528cf

- mm/hugetlb: fix missing hugetlb_lock for resv uncharge
  (bsc#1224548 CVE-2024-36000).
- commit 92c1bc7

- mm/huge_memory: don't unpoison huge_zero_folio (bsc#1227842
  CVE-2024-40914).
- commit 14bb799

- net: xfrm: preserve kabi for xfrm_state (bsc#1233754).
- idpf: avoid vport access in idpf_get_link_ksettings
  (CVE-2024-50274 bsc#1233463).
- xfrm: Export symbol xfrm_dev_state_delete (bsc#1233754).
- xfrm: Fix unregister netdevice hang on hardware offload
  (bsc#1233754).
- commit 8c4cfeb

- hwmon: (tps23861) Fix reporting of negative temperatures
  (git-fixes).
- i3c: master: svc: Fix pm_runtime_set_suspended() with runtime
  pm enabled (git-fixes).
- i3c: master: Fix miss free init_dyn_addr at
  i3c_master_put_i3c_addrs() (git-fixes).
- PCI: Fix reset_method_store() memory leak (git-fixes).
- PCI: rockchip-ep: Fix address translation unit programming
  (git-fixes).
- PCI: keystone: Add link up check to ks_pcie_other_map_bus()
  (git-fixes).
- PCI: keystone: Set mode as Root Complex for &amp;quot;ti,keystone-pcie&amp;quot;
  compatible (git-fixes).
- PCI: endpoint: Clear secondary (not primary) EPC in
  pci_epc_remove_epf() (git-fixes).
- commit 29a3aa9

- Move kabi netfilter fix into patches.kabi
- commit 6c82cf8

- virtio_net: Add hash_key_length check (CVE-2024-53082
  bsc#1233573).
- commit 1273e47

- net: relax socket state check at accept time (git-fixes).
- netfilter: nf_tables: missing iterator type in lookup walk
  (git-fixes).
- commit 180e959

- net: hns3: fix a deadlock problem when config TC during
  resetting (CVE-2024-44995 bsc#1230231).
- commit e1fa968

- KVM: PPC: Book3S HV: Avoid returning to nested hypervisor on
  pending doorbells (bsc#1215199).
- KVM: PPC: Book3S HV: Stop using vc-&amp;gt;dpdes for nested KVM guests
  (bsc#1215199).
- Revert &amp;quot;KVM: PPC: Book3S HV Nested: Stop forwarding all HFUs
  to L1&amp;quot; (bsc#1215199).
- commit d27c0c3

- mailbox: arm_mhuv2: clean up loop in get_irq_chan_comb()
  (git-fixes).
- pinctrl: k210: Undef K210_PC_DEFAULT (git-fixes).
- pinctrl: qcom: spmi: fix debugfs drive strength (git-fixes).
- pinctrl: zynqmp: drop excess struct member description
  (git-fixes).
- lib: string_helpers: silence snprintf() output truncation
  warning (git-fixes).
- fbdev: sh7760fb: Fix a possible memory leak in
  sh7760fb_alloc_mem() (git-fixes).
- Input: hycon-hy46xx - add missing dependency on REGMAP_I2C
  (git-fixes).
- Input: hideep - add missing dependency on REGMAP_I2C
  (git-fixes).
- commit 17f846a

- KVM: PPC: Book3S HV: remove unused varible (bsc#1194869).
- commit 932ea3b

- netrom: fix possible dead-lock in nr_rt_ioctl() (CVE-2024-38589
  bsc#1226748).
- commit 0e7a285

- tpm: Lock TPM chip in tpm_pm_suspend() first (bsc#1082555
  git-fixes).
- commit 4594f81

- kABI fix for netfilter: nft_set_pipapo: walk over current view
  on netlink dump (CVE-2024-27017 bsc#1223733).
- commit 2be46c1

- Update references for
  patches.suse/mm-resolve-faulty-mmap_region-error-path-behaviour.patch
  (git-fixes CVE-2024-53096 bsc#1233756).
- commit 6c0d091

- ALSA: hda/realtek: Enable speaker pins for Medion E15443
  platform (bsc#1233298).
- ALSA: hda/realtek: Fix Internal Speaker and Mic boost of
  Infinix Y4 Max (bsc#1233298).
- commit dd8caae

- Move upstreamed patches into sorted section
- commit b72de8f

- kabi, mm: refactor arch_calc_vm_flag_bits() and arm64 MTE
  handling (git-fixes kabi).
- mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling
  (git-fixes).
- commit f31b0e3

- mm: resolve faulty mmap_region() error path behaviour
  (git-fixes).
- commit 84c4dfc

- mm: refactor map_deny_write_exec() (git-fixes).
- commit 8c66a90

- mm: unconditionally close VMAs on error (git-fixes).
- commit f81f7df

- mm: move dummy_vm_ops out of a header (git-fixes prerequisity).
- commit e1045c0

- mm: avoid unsafe VMA hook invocation when error arises on mmap
  hook (git-fixes).
- commit 2b96063

- fsl/fman: Fix refcount handling of fman-related devices
  (CVE-2024-50166 bsc#1233050).
- fsl/fman: Save device references taken in mac_probe()
  (CVE-2024-50166 bsc#1233050).
- commit cff0dea

- tcp: Fix refcnt handling in __inet_hash_connect() (git-fixes).
- commit 2b4c1a0

- tipc: fix UAF in error path (CVE-2024-36886 bsc#1225730).
- commit be7d8d3

- ipv4: Fix uninit-value access in __ip_make_skb() (CVE-2024-36927
  bsc#1225813).
- commit 5457624

- vsock/virtio: Initialization of the dangling pointer occurring
  in vsk-&amp;gt;trans (CVE-2024-50264 bsc#1233453).
- arm64/sve: Discard stale CPU state when handling SVE traps
  (CVE-2024-50275 bsc#1233464).
- commit 2855c61

- tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets
  (CVE-2024-36905 bsc#1225742).
- commit 84c8bd7

- kasan: move checks to do_strncpy_from_user (git-fixes).
- commit ca3142b

- tipc: fix a possible memleak in tipc_buf_append (CVE-2024-36954
  bsc#1225764).
- commit b7093a9

- erspan: make sure erspan_base_hdr is present in skb-&amp;gt;head
  (CVE-2024-35888 bsc#1224518).
- commit aaa779d

- net: esp: fix bad handling of pages from page_pool
  (CVE-2024-26953 bsc#1223656).
- commit b0a65f5

- netfilter: nft_set_pipapo: walk over current view on netlink
  dump (CVE-2024-27017 bsc#1223733).
- commit d1885c4

- dccp/tcp: Unhash sk from ehash for tb2 alloc failure after
  check_estalblished() (CVE-2024-26741 bsc#1222587).
- commit 9a5ac8a

- minmax: scsi: fix mis-use of 'clamp()' in sr.c (git-fixes).
- commit 46d200b

- Fix warning in patches.suse/RDMA-mlx5-Move-events-notifier-registration-to-be-af.patch
  Fixes: ff613dcf3cc9c8aa5b4cc959d0bdfac2dec81854
- commit 56a258b

- Move upstreamed crypto patches into sorted section
- commit 7706550

- maple_tree: refine mas_store_root() on storing NULL (git-fixes).
- maple_tree: fix alloc node fail issue (git-fixes).
- unicode: Fix utf8_load() error path (git-fixes).
- commit 7f4b1c4

- RDMA/mlx5: Move events notifier registration to be after device registration (git-fixes)
- commit ff613dc

- RDMA/hns: Fix different dgids mapping to the same dip_idx (git-fixes)
- commit 482b364

- RDMA/hns: Use macro instead of magic number (git-fixes)
- commit d6d944a

- RDMA/hns: Add mutex_destroy() (git-fixes)
- commit 096658f

- RDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg() (git-fixes)
- commit abdac11

- RDMA/hns: Fix out-of-order issue of requester when setting FENCE (git-fixes)
- commit a53ecd7

- RDMA/rxe: Set queue pair cur_qp_state when being queried (git-fixes)
- commit 74c369b

- RDMA/bnxt_re: Check cqe flags to know imm_data vs inv_irkey (git-fixes)
- commit 7a90d31

- RDMA/rxe: Fix the qp flush warnings in req (git-fixes)
- commit 678f36e

- RDMA/hns: Fix cpu stuck caused by printings during reset (git-fixes)
- commit 0c19d33

- RDMA/hns: Use dev_* printings in hem code instead of ibdev_* (git-fixes)
- commit 21d3575

- RDMA/hns: Fix flush cqe error when racing with destroy qp (git-fixes)
- commit 4c3bddb

- RDMA/hns: Fix an AEQE overflow error caused by untimely update of eq_db_ci (git-fixes)
- commit c0d9dba

- cpufreq: CPPC: Fix wrong return value in cppc_get_cpu_power()
  (git-fixes).
- cpufreq: CPPC: Fix wrong return value in cppc_get_cpu_cost()
  (git-fixes).
- commit b53ff09

- cpufreq: mediatek-hw: Fix wrong return value in
  mtk_cpufreq_get_cpu_power() (git-fixes).
- cpufreq: CPPC: Fix possible null-ptr-deref for
  cppc_get_cpu_cost() (git-fixes).
- cpufreq: CPPC: Fix possible null-ptr-deref for
  cpufreq_cpu_get_raw() (git-fixes).
- Revert &amp;quot;cpufreq: brcmstb-avs-cpufreq: Fix initial command check&amp;quot;
  (stable-fixes).
- cpufreq: loongson2: Unregister platform_driver on failure
  (git-fixes).
- mtd: rawnand: atmel: Fix possible memory leak (git-fixes).
- mtd: spi-nor: core: replace dummy buswidth from addr to data
  (git-fixes).
- clk: qcom: clk-alpha-pll: fix lucid 5lpe pll enabled check
  (git-fixes).
- clk: qcom: clk-alpha-pll: drop lucid-evo pll enabled warning
  (git-fixes).
- clk: qcom: gcc-qcs404: fix initial rate of GPLL3 (git-fixes).
- clk: clk-axi-clkgen: make sure to enable the AXI bus clock
  (git-fixes).
- clk: sunxi-ng: d1: Fix PLL_AUDIO0 preset (git-fixes).
- clk: imx: clk-scu: fix clk enable state save and restore
  (git-fixes).
- clk: imx: fracn-gppll: fix pll power up (git-fixes).
- clk: imx: fracn-gppll: correct PLL initialization flow
  (git-fixes).
- clk: imx: lpcg-scu: SW workaround for errata (e10858)
  (git-fixes).
- clk: renesas: rzg2l: Fix FOUTPOSTDIV clk (git-fixes).
- clk: clk-apple-nco: Add NULL check in applnco_probe (git-fixes).
- leds: lp55xx: Remove redundant test for invalid channel number
  (git-fixes).
- mfd: rt5033: Fix missing regmap_del_irq_chip() (git-fixes).
- mfd: tps65010: Use IRQF_NO_AUTOEN flag in request_irq() to
  fix race (git-fixes).
- drm/amd: Fix initialization mistake for NBIO 7.7.0
  (stable-fixes).
- drm/amd/display: Adjust VSDB parser for replay feature
  (stable-fixes).
- media: dvbdev: fix the logic when DVB_DYNAMIC_MINORS is not set
  (stable-fixes).
- commit 15015b2

- scsi: cdrom: kABI: fix cdrom_dev_ops change (git-fixes).
- commit ab3e426

- netfilter: Fix use-after-free in get_info() (CVE-2024-50257
  bsc#1233244).
- commit 1f00653

- ALSA: usb-audio: Make mic volume workarounds globally applicable
  (stable-fixes).
- Refresh
  patches.suse/ALSA-usb-audio-Add-quirk-for-HP-320-FHD-Webcam.patch.
- commit 777a5df

- drm/vc4: Match drm_dev_enter and exit calls in vc4_hvs_lut_load
  (git-fixes).
- ALSA: hda: Poll jack events for LS7A HD-Audio (stable-fixes).
- ALSA: usb-audio: Add Pioneer DJ/AlphaTheta DJM-A9 Mixer
  (stable-fixes).
- ALSA: usb-audio: Use snprintf instead of sprintf in
  build_mixer_unit_ctl (stable-fixes).
- ALSA: ice1712: Remove redundant code in stac9460_dac_vol_put
  (stable-fixes).
- commit e772374

- drm/amdkfd: Fix wrong usage of INIT_WORK() (git-fixes).
- drm/panfrost: Add missing OPP table refcnt decremental
  (git-fixes).
- drm: use ATOMIC64_INIT() for atomic64_t (git-fixes).
- drm/vkms: Drop unnecessary call to drm_crtc_cleanup()
  (git-fixes).
- drm/etnaviv: hold GPU lock across perfmon sampling (git-fixes).
- drm/etnaviv: Request pages from DMA32 zone on addressing_limited
  (git-fixes).
- drm/amd/display: Fix brightness level not retained over reboot
  (git-fixes).
- drm/msm/dpu: cast crtc_clk calculation to u64 in
  _dpu_core_perf_calc_clk() (git-fixes).
- drm/mediatek: Fix child node refcount handling in early exit
  (git-fixes).
- drm/msm/gpu: Check the status of registration to PM QoS
  (git-fixes).
- drm/msm/adreno: Use IRQF_NO_AUTOEN flag in request_irq()
  (git-fixes).
- drm/msm: Fix some typos in comment (git-fixes).
- drm/msm/dpu: drop LM_3 / LM_4 on MSM8998 (git-fixes).
- drm/msm/dpu: drop LM_3 / LM_4 on SDM845 (git-fixes).
- drm/msm/dpu: on SDM845 move DSPP_3 to LM_5 block (git-fixes).
- drm: xlnx: zynqmp_dpsub: fix hotplug detection (git-fixes).
- drm: zynqmp_kms: Unplug DRM device before removal (git-fixes).
- drm/nouveau/gr/gf100: Fix missing unlock in gf100_gr_chan_new()
  (git-fixes).
- drm/panfrost: Remove unused id_mask from struct panfrost_model
  (git-fixes).
- drm/amdgpu: Fix JPEG v4.0.3 register write (git-fixes).
- drm/bridge: tc358767: Fix link properties discovery (git-fixes).
- drm/vc4: Match drm_dev_enter and exit calls in
  vc4_hvs_atomic_flush (git-fixes).
- drm/bridge: it6505: Drop EDID cache on bridge power off
  (git-fixes).
- drm/bridge: anx7625: Drop EDID cache on bridge power off
  (git-fixes).
- drm/v3d: Address race-condition in MMU flush (git-fixes).
- drm/sti: avoid potential dereference of error pointers
  (git-fixes).
- drm/sti: avoid potential dereference of error pointers in
  sti_gdp_atomic_check (git-fixes).
- drm/sti: avoid potential dereference of error pointers in
  sti_hqvdp_atomic_check (git-fixes).
- drm/imx/ipuv3: Use IRQF_NO_AUTOEN flag in request_irq()
  (git-fixes).
- drm/imx/dcss: Use IRQF_NO_AUTOEN flag in request_irq()
  (git-fixes).
- drm/omap: Fix locking in omap_gem_new_dmabuf() (git-fixes).
- drm/omap: Fix possible NULL dereference (git-fixes).
- drm/vc4: hvs: Correct logic on stopping an HVS channel
  (git-fixes).
- drm/vc4: hvs: Remove incorrect limit from hvs_dlist debugfs
  function (git-fixes).
- drm/vc4: hvs: Fix dlist debug not resetting the next entry
  pointer (git-fixes).
- drm/vc4: hdmi: Avoid hang with debug registers when suspended
  (git-fixes).
- drm/vc4: hvs: Don't write gamma luts on 2711 (git-fixes).
- drm/mm: Mark drm_mm_interval_tree*() functions with
  __maybe_unused (git-fixes).
- ASoC: codecs: Fix atomicity violation in
  snd_soc_component_get_drvdata() (git-fixes).
- ASoC: rt722-sdca: Remove logically deadcode in rt722-sdca.c
  (git-fixes).
- ASoC: fsl_micfil: fix regmap_write_bits usage (git-fixes).
- ALSA: 6fire: Release resources at card release (git-fixes).
- ALSA: caiaq: Use snd_card_free_when_closed() at disconnection
  (git-fixes).
- ALSA: us122l: Use snd_card_free_when_closed() at disconnection
  (git-fixes).
- ALSA: usx2y: Use snd_card_free_when_closed() at disconnection
  (git-fixes).
- Bluetooth: fix use-after-free in device_for_each_child()
  (git-fixes).
- wifi: brcmfmac: release 'root' node in all execution paths
  (git-fixes).
- wifi: cw1200: Fix potential NULL dereference (git-fixes).
- wifi: wfx: Fix error handling in wfx_core_init() (git-fixes).
- wifi: ath12k: fix warning when unbinding (git-fixes).
- wifi: ath12k: fix crash when unbinding (git-fixes).
- wifi: ath12k: remove msdu_end structure for WCN7850 (git-fixes).
- wifi: ath11k: Fix CE offset address calculation for WCN6750
  in SSR (git-fixes).
- wifi: ath12k: Skip Rx TID cleanup for self peer (git-fixes).
- wifi: ath10k: fix invalid VHT parameters in
  supported_vht_mcs_rate_nss2 (git-fixes).
- wifi: ath10k: fix invalid VHT parameters in
  supported_vht_mcs_rate_nss1 (git-fixes).
- wifi: ath9k: add range check for conn_rsp_epid in
  htc_connect_service() (git-fixes).
- wifi: mwifiex: Fix memcpy() field-spanning write warning in
  mwifiex_config_scan() (git-fixes).
- wifi: mwifiex: Use IRQF_NO_AUTOEN flag in request_irq()
  (git-fixes).
- wifi: p54: Use IRQF_NO_AUTOEN flag in request_irq() (git-fixes).
- commit c54011d

- scsi: kABI: restore no_start_on_resume to scsi_device
  (git-fixes).
- scsi: sd_zbc: Use kvzalloc() to allocate REPORT ZONES buffer
  (git-fixes).
- scsi: mpi3mr: Validate SAS port assignments (git-fixes).
- scsi: scsi_transport_fc: Allow setting rport state to current
  state (git-fixes).
- scsi: wd33c93: Don't use stale scsi_pointer value (git-fixes).
- scsi: pm8001: Do not overwrite PCI queue mapping (git-fixes).
- scsi: smartpqi: correct stream detection (git-fixes).
- scsi: NCR5380: Initialize buffer for MSG IN and STATUS transfers
  (git-fixes).
- scsi: NCR5380: Check for phase match during PDMA fixup
  (git-fixes).
- scsi: mac_scsi: Disallow bus errors during PDMA send
  (git-fixes).
- scsi: mac_scsi: Refactor polling loop (git-fixes).
- scsi: mac_scsi: Revise printk(KERN_DEBUG ...) messages
  (git-fixes).
- scsi: smartpqi: revert
  propagate-the-multipath-failure-to-SML-quickly (git-fixes).
- scsi: aacraid: Rearrange order of struct aac_srb_unit
  (git-fixes).
- scsi: sd: Ignore command SYNCHRONIZE CACHE error if format in
  progress (git-fixes).
- scsi: core: Fix the return value of scsi_logical_block_count()
  (git-fixes).
- scsi: mpt3sas: Avoid IOMMU page faults on REPORT ZONES
  (git-fixes).
- scsi: mpi3mr: Avoid IOMMU page faults on REPORT ZONES
  (git-fixes).
- scsi: pm80xx: Set phy-&amp;gt;enable_completion only when we wait
  for it (git-fixes).
- scsi: libsas: Fix exp-attached device scan after probe failure
  scanned in again after probe failed (git-fixes).
- scsi: mpi3mr: Fix ATA NCQ priority support (git-fixes).
- scsi: core: Disable CDL by default (git-fixes).
- scsi: core: Handle devices which return an unusually large
  VPD page count (git-fixes).
- scsi: qedf: Set qed_slowpath_params to zero before use
  (git-fixes).
- scsi: sr: Fix unintentional arithmetic wraparound (git-fixes).
- scsi: core: alua: I/O errors for ALUA state transitions
  (git-fixes).
- scsi: hpsa: Fix allocation size for Scsi_Host private data
  (git-fixes).
- scsi: libsas: Fix the failure of adding phy with zero-address
  to port (git-fixes).
- scsi: mpi3mr: Avoid possible run-time warning with long
  manufacturer strings (git-fixes).
- scsi: core: Fix handling of SCMD_FAIL_IF_RECOVERING (git-fixes).
- scsi: hisi_sas: Handle the NCQ error returned by D2H frame
  (git-fixes).
- scsi: mpi3mr: Avoid memcpy field-spanning write WARNING
  (git-fixes).
- scsi: spi: Fix sshdr use (git-fixes).
- scsi: Remove scsi device no_start_on_resume flag (git-fixes).
- commit d5d37f8

- soc: fsl: rcpm: fix missing of_node_put() in
  copy_ippdexpcr1_setting() (git-fixes).
- firmware: arm_scpi: Check the DVFS OPP count returned by the
  firmware (git-fixes).
- soc: ti: smartreflex: Use IRQF_NO_AUTOEN flag in request_irq()
  (git-fixes).
- soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get()
  (git-fixes).
- drivers: soc: xilinx: add the missing kfree in
  xlnx_add_cb_for_suspend() (git-fixes).
- efi/libstub: Free correct pointer on failure (git-fixes).
- tpm: fix signed/unsigned bug when checking event logs
  (git-fixes).
- efi/libstub: fix efi_parse_options() ignoring the default
  command line (git-fixes).
- platform/x86: panasonic-laptop: Return errno correctly in show
  callback (git-fixes).
- media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED
  in uvc_parse_format (git-fixes).
- media: platform: exynos4-is: Fix an OF node reference leak in
  fimc_md_is_isp_available (git-fixes).
- media: atomisp: Add check for rgby_data memory allocation
  failure (git-fixes).
- media: gspca: ov534-ov772x: Fix off-by-one error in
  set_frame_rate() (git-fixes).
- media: venus: Fix pm_runtime_set_suspended() with runtime pm
  enabled (git-fixes).
- media: amphion: Fix pm_runtime_set_suspended() with runtime
  pm enabled (git-fixes).
- media: i2c: dw9768: Fix pm_runtime_set_suspended() with runtime
  pm enabled (git-fixes).
- media: mantis: remove orphan mantis_core.h (git-fixes).
- media: vb2: Fix comment (git-fixes).
- media: uvcvideo: Stop stream during unregister (git-fixes).
- media: ts2020: fix null-ptr-deref in ts2020_probe() (git-fixes).
- media: platform: allegro-dvt: Fix possible memory leak in
  allocate_buffers_internal() (git-fixes).
- media: i2c: tc358743: Fix crash in the probe error path when
  using polling (git-fixes).
- media: wl128x: Fix atomicity violation in fmc_send_cmd()
  (git-fixes).
- media: imx-jpeg: Ensure power suppliers be suspended before
  detach them (git-fixes).
- media: amphion: Set video drvdata before register video device
  (git-fixes).
- media: imx-jpeg: Set video drvdata before register video device
  (git-fixes).
- media: mtk-jpeg: Fix null-ptr-deref during unload module
  (git-fixes).
- media: uvcvideo: Require entities to have a non-zero unique ID
  (git-fixes).
- HID: wacom: Interpret tilt data from Intuos Pro BT as signed
  values (git-fixes).
- mmc: mmc_spi: drop buggy snprintf() (git-fixes).
- =?UTF-8?q?spi:=20zynqmp-gqspi:=20Undo=20runtime=20PM=20ch?=
  =?UTF-8?q?anges=20at=20driver=20exit=20time=E2=80=8B?=
  (git-fixes).
- spi: tegra210-quad: Avoid shift-out-of-bounds (git-fixes).
- regmap: irq: Set lockdep class for hierarchical IRQ domains
  (git-fixes).
- Documentation: kgdb: Correct parameter error (git-fixes).
- efi/libstub: zboot.lds: Discard .discard sections
  (stable-fixes).
- commit fbb8e93

- doc: rcu: update printed dynticks counter bits (git-fixes).
- hwmon: (nct6775-core) Fix overflows seen when writing limit
  attributes (git-fixes).
- ACPI: CPPC: Fix _CPC register setting issue (git-fixes).
- thermal: core: Initialize thermal zones before registering them
  (git-fixes).
- amd-pstate: Set min_perf to nominal_perf for active mode
  performance gov (git-fixes).
- crypto: cavium - Fix an error handling path in
  cpt_ucode_load_fw() (git-fixes).
- crypto: bcm - add error check in the ahash_hmac_init function
  (git-fixes).
- crypto: caam - add error check to caam_rsa_set_priv_key_form
  (git-fixes).
- crypto: inside-secure - Fix the return value of
  safexcel_xcbcmac_cra_init() (git-fixes).
- crypto: cavium - Fix the if condition to exit loop after timeout
  (git-fixes).
- crypto: x86/aegis128 - access 32-bit arguments as 32-bit
  (git-fixes).
- crypto: pcrypt - Call crypto layer directly when
  padata_do_parallel() return -EBUSY (git-fixes).
- crypto: qat - remove faulty arbiter config reset (git-fixes).
- crypto: qat/qat_4xxx - fix off by one in uof_get_name()
  (git-fixes).
- crypto: qat - remove check after debugfs_create_dir()
  (git-fixes).
- crypto: caam - Fix the pointer passed to caam_qi_shutdown()
  (git-fixes).
- firmware: google: Unregister driver_info on failure (git-fixes).
- platform/chrome: cros_ec_typec: fix missing fwnode reference
  decrement (git-fixes).
- acpi/arm64: Adjust error handling procedure in
  gtdt_parse_timer_block() (git-fixes).
- commit af7e948

- btrfs: reinitialize delayed ref list after deleting it from
  the list (bsc#1233462 CVE-2024-50273).
- commit 174bbc2

- 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 =&amp;gt; LIVEPATCH=n
- commit cabd446

- ASoC: audio-graph-card2: Purge absent supplies for device tree
  nodes (stable-fixes).
- ALSA: hda/realtek: fix mute/micmute LEDs for a HP EliteBook
  645 G10 (stable-fixes).
- ALSA: hda/realtek - Fixed Clevo platform headset Mic issue
  (stable-fixes).
- ALSA: usb-audio: Fix Yamaha P-125 Quirk Entry (stable-fixes).
- commit 03ba04a

- drm/amdgpu: fix check in gmc_v9_0_get_vm_pte() (git-fixes).
- drm/bridge: tc358768: Fix DSI command tx (git-fixes).
- nouveau/dp: handle retries for AUX CH transfers with GSP
  (git-fixes).
- nouveau: handle EBUSY and EAGAIN for GSP aux errors (git-fixes).
- nouveau: fw: sync dma after setup is called (git-fixes).
- drm/rockchip: vop: Fix a dereferenced before check warning
  (git-fixes).
- Revert &amp;quot;mmc: dw_mmc: Fix IDMAC operation with pages bigger
  than 4K&amp;quot; (git-fixes).
- mmc: sunxi-mmc: Fix A100 compatible description (git-fixes).
- ALSA: hda/realtek - update set GPIO3 to default for Thinkpad
  with ALC1318 (git-fixes).
- ASoC: fsl_micfil: Add sample rate constraint (stable-fixes).
- ASoC: rt722-sdca: increase clk_stop_timeout to fix clock stop
  issue (stable-fixes).
- ASoC: amd: yc: Fix non-functional mic on ASUS E1404FA
  (stable-fixes).
- ASoC: amd: yc: Add quirk for ASUS Vivobook S15 M3502RA
  (stable-fixes).
- net: usb: qmi_wwan: add Fibocom FG132 0x0112 composition
  (stable-fixes).
- net: wwan: fix global oob in wwan_rtnl_policy (git-fixes).
- HID: lenovo: Add support for Thinkpad X1 Tablet Gen 3 keyboard
  (stable-fixes).
- HID: multitouch: Add quirk for Logitech Bolt receiver w/
  Casa touchpad (stable-fixes).
- drm/vmwgfx: Limit display layout ioctl array size to
  VMWGFX_NUM_DISPLAY_UNITS (stable-fixes).
- drm/amdkfd: Accounting pdd vram_usage for svm (stable-fixes).
- crypto: api - Fix liveliness check in crypto_alg_tested
  (stable-fixes).
- HID: multitouch: Add quirk for HONOR MagicBook Art 14 touchpad
  (stable-fixes).
- HID: multitouch: Add support for B2402FVA track point
  (stable-fixes).
- commit 42778ee

- ocfs2: uncache inode which has failed entering the group
  (git-fixes).
- commit 4caa305

- ocfs2: fix UBSAN warning in ocfs2_verify_volume() (git-fixes).
- commit fe96ee2

- ocfs2: remove entry once instead of null-ptr-dereference in
  ocfs2_xa_remove() (git-fixes).
- commit 7a347a0

- fs: Fix uninitialized value issue in from_kuid and from_kgid
  (git-fixes).
- commit 46de67d

- Revert &amp;quot;RDMA/core: Fix ENODEV error for iWARP test over vlan&amp;quot; (git-fixes)
- commit 89dc95f

- RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES (git-fixes)
- commit 1e78f0f

- Bluetooth: ISO: Fix UAF on iso_sock_timeout (CVE-2024-50124
  bsc#1232926).
- commit 25f5727

- tools/power turbostat: Increase the limit for fd opened
  (bsc#1233119).
- commit 58c7a4f

- posix-clock: Fix missing timespec64 check in pc_clock_settime() (CVE-2024-50195 bsc#1233103)
- commit 5c410cf

- bpf: Use raw_spinlock_t in ringbuf (CVE-2024-50138 bsc#1232935)
- commit 949411a

- net: systemport: fix potential memory leak in bcm_sysport_xmit() (CVE-2024-50171 bsc#1233057)
- commit 24f9c7b

- crypto: aes-gcm-p10 - Use the correct bit to test for P10
  (bsc#1232704).
- commit 52eb6a0

- add bugreference to a hv_netvsc patch (bsc#1232413).
- commit 14b76c0

- scsi: target: core: Fix null-ptr-deref in target_alloc_device()
  (CVE-2024-50153 bsc#1233061).
- commit 76e65bc

- octeon_ep: Add SKB allocation failures handling in
  __octep_oq_process_rx() (CVE-2024-50145 bsc#1233044).
- octeon_ep: Implement helper for iterating packets in Rx queue
  (CVE-2024-50145 bsc#1233044).
- commit 6b574c1

- Fix for kABI fix for Bluetooth: L2CAP: Fix
  div-by-zero in l2cap_le_flowctl_init() (CVE-2024-36968 bsc#1226130).
  The chosen position of `mtu` in the `struct hci_conn` in the first
  iteration of this patch was done based on the wrong version of the header
  and therefore on the wrong position. Correct that.
  Fixes: d93ac77c0df4b8dfe469c26e60d4fb45fc305341
- commit 77fc56a

- net: wwan: fix global oob in wwan_rtnl_policy (CVE-2024-50128
  bsc#1232905).
- commit c939671

- xfrm: fix one more kernel-infoleak in algo dumping
  (CVE-2024-50110 bsc#1232885).
- commit 2ae0e01

- scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down
  (CVE-2024-50098 bsc#1232881).
- commit f344a8e

- Update
  patches.suse/thermal-intel-int340x-processor-Fix-warning-during-m.patch
  (git-fixes bsc#1232877 CVE-2024-50093).
- commit 6ec2cb2

- Bluetooth: btintel: Direct exception event to bluetooth stack
  (git-fixes).
- Bluetooth: hci_core: Fix calling mgmt_device_connected
  (git-fixes).
- USB: serial: qcserial: add support for Sierra Wireless EM86xx
  (stable-fixes).
- USB: serial: option: add Quectel RG650V (stable-fixes).
- USB: serial: option: add Fibocom FG132 0x0112 composition
  (stable-fixes).
- tools/lib/thermal: Fix sampling handler context ptr (git-fixes).
- drm/amdgpu: add missing size check in
  amdgpu_debugfs_gprwave_read() (stable-fixes).
- drm/amdgpu: Adjust debugfs eviction and IB access permissions
  (stable-fixes).
- drm/amdgpu: Adjust debugfs register access permissions
  (stable-fixes).
- drm/amdgpu: prevent NULL pointer dereference if ATIF is not
  supported (git-fixes).
- net: phy: ti: add PHY_RST_AFTER_CLK_EN flag (git-fixes).
- net: wwan: t7xx: Fix off-by-one error in
  t7xx_dpmaif_rx_buf_alloc() (git-fixes).
- net: phy: dp83822: Fix reset pin definitions (git-fixes).
- commit 48ec995

- Delete patches.suse/wifi-mac80211-fix-RCU-list-iterations.patch
  It was reverted on 6.6.x stable
- commit e2ead50

- net: explicitly clear the sk pointer, when pf-&amp;gt;create fails
  (CVE-2024-50186 bsc#1233110).
- commit dfaff4b

- secretmem: disable memfd_secret() if arch cannot set direct map
  (CVE-2024-50182 bsc#1233129).
- commit 0d23f21

- Update
  patches.suse/ACPI-CPPC-Make-rmw_lock-a-raw_spin_lock.patch
  (git-fixes CVE-2024-50249 bsc#1233197).
- Update
  patches.suse/ACPI-PRM-Find-EFI_MEMORY_RUNTIME-block-for-PRM-handl.patch
  (git-fixes CVE-2024-50141 bsc#1233065).
- Update
  patches.suse/ALSA-firewire-lib-Avoid-division-by-zero-in-apply_co.patch
  (git-fixes CVE-2024-50205 bsc#1233293).
- Update
  patches.suse/ALSA-hda-cs8409-Fix-possible-NULL-dereference.patch
  (git-fixes CVE-2024-50160 bsc#1233074).
- Update
  patches.suse/ASoC-qcom-Fix-NULL-Dereference-in-asoc_qcom_lpass_cp.patch
  (git-fixes CVE-2024-50103 bsc#1232878).
- Update
  patches.suse/Bluetooth-bnep-fix-wild-memory-access-in-proto_unreg.patch
  (git-fixes CVE-2024-50148 bsc#1233063).
- Update
  patches.suse/Bluetooth-hci-fix-null-ptr-deref-in-hci_read_support.patch
  (git-fixes CVE-2024-50255 bsc#1233238).
- Update
  patches.suse/HID-amd_sfh-Switch-to-device-managed-dmam_alloc_cohe.patch
  (git-fixes CVE-2024-50189 bsc#1233105).
- Update
  patches.suse/RDMA-bnxt_re-Add-a-check-for-memory-allocation.patch
  (git-fixes CVE-2024-50209 bsc#1233114).
- Update
  patches.suse/RDMA-bnxt_re-Avoid-CPU-lockups-due-fifo-occupancy-ch.patch
  (git-fixes CVE-2024-50157 bsc#1233032).
- Update
  patches.suse/RDMA-bnxt_re-Fix-a-bug-while-setting-up-Level-2-PBL-.patch
  (git-fixes CVE-2024-50208 bsc#1233117).
- Update
  patches.suse/RDMA-bnxt_re-Fix-a-possible-memory-leak.patch
  (git-fixes CVE-2024-50172 bsc#1233029).
- Update patches.suse/RDMA-bnxt_re-Fix-out-of-bound-check.patch
  (git-fixes CVE-2024-50158 bsc#1233036).
- Update
  patches.suse/RDMA-mad-Improve-handling-of-timed-out-WRs-of-mad-ag.patch
  (git-fixes CVE-2024-50095 bsc#1232873).
- Update
  patches.suse/USB-gadget-dummy-hcd-Fix-task-hung-problem.patch
  (git-fixes CVE-2024-50100 bsc#1232876).
- Update
  patches.suse/arm64-probes-Fix-uprobes-for-big-endian-kernels.patch
  (git-fixes CVE-2024-50194 bsc#1233111).
- Update
  patches.suse/arm64-probes-Remove-broken-LDR-literal-uprobe-support.patch
  (git-fixes CVE-2024-50099 bsc#1232887).
- Update
  patches.suse/ceph-remove-the-incorrect-Fw-reference-check-when-dir.patch
  (bsc#1231182 CVE-2024-50179 bsc#1233123).
- Update
  patches.suse/clk-imx-Remove-CLK_SET_PARENT_GATE-for-DRAM-mux-for-.patch
  (stable-fixes CVE-2024-50181 bsc#1233127).
- Update
  patches.suse/drm-amd-Guard-against-bad-data-for-ATIF-ACPI-method.patch
  (git-fixes CVE-2024-50117 bsc#1232897).
- Update
  patches.suse/drm-amd-display-Disable-PSR-SU-on-Parade-08-01-TCON-.patch
  (stable-fixes CVE-2024-50108 bsc#1232884).
- Update
  patches.suse/drm-amd-pm-Vangogh-Fix-kernel-memory-out-of-bounds-w.patch
  (git-fixes CVE-2024-50221 bsc#1233185).
- Update
  patches.suse/drm-msm-Avoid-NULL-dereference-in-msm_disp_state_pri.patch
  (git-fixes CVE-2024-50156 bsc#1233073).
- Update patches.suse/drm-radeon-Fix-encoder-possible_clones.patch
  (git-fixes CVE-2024-50201 bsc#1233104).
- Update
  patches.suse/drm-vboxvideo-Replace-fake-VLA-at-end-of-vbva_mouse_.patch
  (stable-fixes CVE-2024-50134 bsc#1232890).
- Update
  patches.suse/drm-vc4-Stop-the-active-perfmon-before-being-destroy.patch
  (git-fixes CVE-2024-50187 bsc#1233108).
- Update
  patches.suse/ext4-fix-slab-use-after-free-in-ext4_split_extent_at.patch
  (bsc#1232201 CVE-2024-49884 bsc#1232198).
- Update patches.suse/fbdev-sisfb-Fix-strbuf-array-overflow.patch
  (stable-fixes CVE-2024-50180 bsc#1233125).
- Update
  patches.suse/firmware-arm_scmi-Fix-the-double-free-in-scmi_debugf.patch
  (git-fixes CVE-2024-50159 bsc#1233041).
- Update
  patches.suse/iio-adc-ad7124-fix-division-by-zero-in-ad7124_set_ch.patch
  (git-fixes CVE-2024-50232 bsc#1233209).
- Update
  patches.suse/iio-gts-helper-Fix-memory-leaks-in-iio_gts_build_ava.patch
  (git-fixes CVE-2024-50231 bsc#1233208).
- Update
  patches.suse/iio-light-veml6030-fix-IIO-device-retrieval-from-emb.patch
  (git-fixes CVE-2024-50198 bsc#1233100).
- Update
  patches.suse/iommu-vt-d-Fix-incorrect-pci_for_each_dma_alias-for-.patch
  (git-fixes CVE-2024-50101 bsc#1232869).
- Update
  patches.suse/maple_tree-correct-tree-corruption-on-spanning-store.patch
  (git-fixes CVE-2024-50200 bsc#1233088).
- Update
  patches.suse/media-qcom-camss-Remove-use_count-guard-in-stop_stre.patch
  (git-fixes CVE-2024-50175 bsc#1233092).
- Update
  patches.suse/net-mlx5-Fix-command-bitmask-initialization.patch
  (git-fixes CVE-2024-50147 bsc#1233067).
- Update
  patches.suse/net-mlx5-Unregister-notifier-on-eswitch-init-failure.patch
  (git-fixes CVE-2024-50136 bsc#1232914).
- Update
  patches.suse/net-mlx5e-Don-t-call-cleanup-on-profile-rollback-fai.patch
  (git-fixes CVE-2024-50146 bsc#1233056).
- Update
  patches.suse/net-phy-dp83869-fix-memory-corruption-when-enabling-.patch
  (git-fixes CVE-2024-50188 bsc#1233107).
- Update
  patches.suse/netdevsim-use-cond_resched-in-nsim_dev_trap_report_w.patch
  (git-fixes CVE-2024-50155 bsc#1233035).
- Update
  patches.suse/nfsd-cancel-nfsd_shrinker_work-using-sync-mode-in-nf.patch
  (git-fixes CVE-2024-50121 bsc#1232925).
- Update
  patches.suse/nilfs2-fix-kernel-bug-due-to-missing-clearing-of-buffer-delay-flag.patch
  (git-fixes CVE-2024-50116 bsc#1232892).
- Update
  patches.suse/nilfs2-fix-potential-deadlock-with-newly-created-symlinks.patch
  (git-fixes CVE-2024-50229 bsc#1233205).
- Update
  patches.suse/nouveau-dmem-Fix-vulnerability-in-migrate_to_ram-upo.patch
  (git-fixes CVE-2024-50096 bsc#1232870).
- Update
  patches.suse/nvme-pci-fix-race-condition-between-reset-and-nvme_d.patch
  (git-fixes CVE-2024-50135 bsc#1232888).
- Update
  patches.suse/nvmet-auth-assign-dh_key-to-NULL-after-kfree_sensiti.patch
  (git-fixes CVE-2024-50215 bsc#1233189).
- Update
  patches.suse/ocfs2-pass-u64-to-ocfs2_truncate_inline-maybe-overflow.patch
  (git-fixes CVE-2024-50218 bsc#1233191).
- Update
  patches.suse/phy-qcom-qmp-usb-fix-NULL-deref-on-runtime-suspend.patch
  (git-fixes CVE-2024-50240 bsc#1233217).
- Update
  patches.suse/pinctrl-ocelot-fix-system-hang-on-level-based-interr.patch
  (stable-fixes CVE-2024-50196 bsc#1233113).
- Update
  patches.suse/remoteproc-k3-r5-Fix-error-handling-when-power-up-fa.patch
  (git-fixes CVE-2024-50176 bsc#1233091).
- Update
  patches.suse/scsi-lpfc-Ensure-DA_ID-handling-completion-before-de.patch
  (bsc#1232757 CVE-2024-50183 bsc#1233130).
- Update
  patches.suse/spi-spi-fsl-dspi-Fix-crash-when-not-using-GPIO-chip-.patch
  (git-fixes CVE-2024-50224 bsc#1233188).
- Update
  patches.suse/staging-iio-frequency-ad9832-fix-division-by-zero-in.patch
  (git-fixes CVE-2024-50233 bsc#1233210).
- Update
  patches.suse/thermal-intel-int340x-processor-Fix-warning-during-m.patch
  (git-fixes CVE-2024-50093 bsc#1232877).
- Update
  patches.suse/tracing-Consider-the-NULL-character-when-validating-the-event-length.patch
  (git-fixes CVE-2024-50131 bsc#1232896).
- Update
  patches.suse/tracing-timerlat-Drop-interface_lock-in-stop_kthread.patch
  (git-fixes CVE-2024-49976 bsc#1232103).
- Update
  patches.suse/tracing-timerlat-Only-clear-timer-if-a-kthread-exists.patch
  (git-fixes CVE-2024-46845 bsc#1231076).
- Update
  patches.suse/unicode-Don-t-special-case-ignorable-code-points.patch
  (stable-fixes CVE-2024-50089 bsc#1232860).
- Update
  patches.suse/uprobe-avoid-out-of-bounds-memory-access-of-fetching-args.patch
  (git-fixes CVE-2024-50067 bsc#1232416).
- Update
  patches.suse/uprobes-fix-kernel-info-leak-via-uprobes-vma.patch
  (bsc#1231114 CVE-2024-46828 CVE-2024-49975 bsc#1232104).
- Update
  patches.suse/usb-typec-altmode-should-keep-reference-to-parent.patch
  (git-fixes CVE-2024-50150 bsc#1233051).
- Update
  patches.suse/wifi-ath10k-Fix-memory-leak-in-management-tx.patch
  (git-fixes CVE-2024-50236 bsc#1233212).
- Update
  patches.suse/wifi-cfg80211-clear-wdev-cqm_config-pointer-on-free.patch
  (git-fixes CVE-2024-50235 bsc#1233176).
- Update
  patches.suse/wifi-iwlegacy-Clear-stale-interrupts-before-resuming.patch
  (stable-fixes CVE-2024-50234 bsc#1233211).
- Update
  patches.suse/wifi-mac80211-do-not-pass-a-stopped-vif-to-the-drive.patch
  (git-fixes CVE-2024-50237 bsc#1233216).
- Update
  patches.suse/x86-fix-user-address-masking-non-canonical-speculation-iss.patch
  (git-fixes CVE-2024-50102 bsc#1232880).
- Update
  patches.suse/xfs-fix-finding-a-last-resort-AG-in-xfs_filestream_pick_ag.patch
  (git-fixes CVE-2024-50216 bsc#1233179).
- commit 7d67ea3

- btrfs: fix error propagation of split bios (CVE-2024-50225 bsc#1233193)
- commit ec9c552

- btrfs: merge btrfs_orig_bbio_end_io() into btrfs_bio_end_io() (bsc#1233193)
- commit b9564da

- Update references in patches.suse/ntfs3-Add-bounds-checking-to-mi_enum_attr.patch (CVE-2024-50248 bsc#1233219 bsc#1233207)
- commit 56e1d55

- fs/ntfs3: Sequential field availability check in mi_enum_attr() (bsc#1233207)
- commit 95663e2

- fs/ntfs3: Add rough attr alloc_size check (CVE-2024-50246 bsc#1233207)
- commit 378df6a

- ntfs3: Add bounds checking to mi_enum_attr() (bsc#1233207)
- commit 418f82a

- fs/ntfs3: Fixed overflow check in mi_enum_attr() (bsc#1233207)
- commit 6744037

- fs/ntfs3: Add more attributes checks in mi_enum_attr() (bsc#1233207)
- commit 766ca6e

- fs/ntfs3: Fix possible deadlock in mi_read (CVE-2024-50245 bsc#1233203)
- commit 5f9c2da

- Rename to
  patches.kabi/kABI-fix-for-Bluetooth-L2CAP-Fix-div-by-zero-in-l2ca.patch.
  Fixes: d93ac77c0df4b8dfe469c26e60d4fb45fc305341
- commit 1f6a42b

- virtio_pmem: Check device status before requesting flush
  (CVE-2024-50184 bsc#1233135).
- commit 4e28ae6

- KVM: SEV-ES: Fix svm_get_msr()/svm_set_msr() for KVM_SEV_ES_INIT
  guests (bsc#1232207).
- commit 4b9eff5

- KVM: SEV-ES: Prevent MSR access post VMSA encryption
  (bsc#1232207).
- commit 61f28ae

- u64_stats: fix u64_stats_init() for lockdep when used repeatedly
  in one file (git-fixes).
- commit 017d59a

- Update tags in
  patches.suse/ext4-fix-slab-use-after-free-in-ext4_split_extent_at.patch
  (bsc#1232201 CVE-2024-49884 bsc#1232198).
- commit 9d4c3ec

- tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink()
  (CVE-2024-50154 bsc#1233070).
- commit 43fc2d5

- Refresh patches.kabi/bpf-verifier-kABI-workarounds.patch (bsc#1233350)
  Correctly workaround kABI breakage that was introduced with fixes
  backported for bsc#1225903.
- commit 52684a5

- ASoC: SOF: ipc4-topology: Only handle dai_config with HW_PARAMS
  for ChainDMA (bsc#1233305).
- commit 1b06409

- io_uring/rw: fix missing NOWAIT check for O_DIRECT start write
  (git-fixes).
- io_uring/sqpoll: close race on waiting for sqring entries
  (git-fixes).
- commit 83eaece

- mm: shmem: fix data-race in shmem_getattr() (CVE-2024-50228,
  bsc#1233204, git fixes (mm/shmem)).
- commit 89c94b7

- irqchip/gic-v4: Correctly deal with set_affinity on
  lazily-mapped VPEs (CVE-2024-50192 bsc#1233106).
- commit 4258dbe

- irqchip/gic-v4: Don't allow a VMOVP on a dying VPE
  (CVE-2024-50192 bsc#1233106).
- kABI: Don't allow a VMOVP on a dying VPE (kabi CVE-2024-50192
  bsc#1233106).
- irqchip/gic-v3-its: Avoid explicit cpumask allocation on stack
  (git-fixes).
- commit 9bd7834

- selftests/bpf: add stack access precision test (bsc#1232823
  CVE-2023-52920).
- bpf: support non-r10 register spill/fill to/from stack in
  precision tracking (bsc#1232823 CVE-2023-52920).
- Refresh patches.suse/bpf-Fix-accesses-to-uninit-stack-slots.patch
- Refresh patches.kabi/bpf-verifier-kABI-workarounds.patch
- commit 2dc84ae

- kABI fix for - Bluetooth: L2CAP: Fix
  div-by-zero in l2cap_le_flowctl_init()
  (CVE-2024-36968 bsc#1226130). - Refresh
  patches.suse/Bluetooth-Ignore-too-large-handle-values-in-BIG.patch.
- Refresh
  patches.suse/Bluetooth-L2CAP-Fix-deadlock.patch. - Refresh
  patches.suse/Bluetooth-btnxpuart-Enable-Power-Save-feature-on-sta.patch.
- Refresh
  patches.suse/bluetooth-hci-disallow-setting-handle-bigger-than-HC.patch.
- Refresh
  patches.suse/bluetooth-l2cap-sync-sock-recv-cb-and-release.patch.
- commit d93ac77

- macsec: Fix use-after-free while sending the offloading packet
  (CVE-2024-50261 bsc#1233253).
- commit 493a21e

- kABI workaround for ASoC SOF (bsc#1233305).
- commit d8b041e

- ASoC: SOF: ipc4-topology: Add definition for generic switch/enum
  control (bsc#1233305).
- Refresh
  patches.suse/ASoC-SOF-ipc4-topology-Correct-data-structures-for-t-e238b68.patch.
- commit 6d4ee28

- ASoC: SOF: topology: Parse DAI type token for dspless mode
  (bsc#1233305).
- ASoC: SOF: topology: dynamically allocate and store DAI
  widget-&amp;gt;private (bsc#1233305).
- ASoC: SOF: ipc4-topology: change chain_dma handling in
  dai_config (bsc#1233305).
- ASoC: SOF: ipc4-topology: set config_length based on
  device_count (bsc#1233305).
- ASoC: SOF: Rename amd_bt sof_dai_type (bsc#1233305).
- ASoC: SOF: Add i2s bt dai configuration support for AMD
  platforms (bsc#1233305).
- ASoC: SOF: Refactor sof_i2s_tokens reading to update acpbt dai
  (bsc#1233305).
- ASoC: SOF: IPC4: synchronize fw_config_params with fw
  definitions (bsc#1233305).
- ASoC: SOF: Wire up buffer flags (bsc#1233305).
- ASoC: SOF: add alignment for topology header file struct
  definition (bsc#1233305).
- ASoC: SOF: align topology header file with sof topology header
  (bsc#1233305).
- ASoC: SOF: ipc4-topology: Add module ID print during module
  set up (bsc#1233305).
- ASoC: SOF: ipc4: Add data struct for module notification
  message from firmware (bsc#1233305).
- ASoC: SOF: ipc4-topology: Helper to find an swidget by
  module/instance id (bsc#1233305).
- ASoC: SOF: Add support for configuring PDM interface from
  topology (bsc#1233305).
- ASoC: SOF: IPC4: get pipeline priority from topology
  (bsc#1233305).
- ASoC: SOF: ipc4-mtrace: move debug slot related definitions
  to header.h (bsc#1233305).
- ASoC: SOF: ipc4-control: Add support for ALSA enum control
  (bsc#1233305).
- ASoC: SOF: ipc4-control: Add support for ALSA switch control
  (bsc#1233305).
- ASoC: SOF: ipc4-topology: export
  sof_ipc4_copier_is_single_format (bsc#1233305).
- ASoC: SOF: ipc4: Add new message type:
  SOF_IPC4_GLB_LOAD_LIBRARY_PREPARE (bsc#1233305).
- ASoC: SOF: ipc4-topology: Add deep buffer size to debug prints
  (bsc#1233305).
- ASoC: SOF: Deprecate invalid enums in IPC3 (bsc#1233305).
- commit ccbfc43

- ima: fix buffer overrun in ima_eventdigest_init_common
  (git-fixes).
- commit 200c852

- KVM: arm64: Fix shift-out-of-bounds bug (CVE-2024-50139
  bsc#1233062).
- commit dc4add6

- KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory
  (CVE-2024-50115 bsc#1232919).
- commit b8f7c4d

- Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()
  (CVE-2024-36968 bsc#1226130).
- Refresh
  patches.suse/Bluetooth-Ignore-too-large-handle-values-in-BIG.patch.
- Refresh patches.suse/Bluetooth-L2CAP-Fix-deadlock.patch.
- Refresh
  patches.suse/Bluetooth-btnxpuart-Enable-Power-Save-feature-on-sta.patch.
- Refresh
  patches.suse/bluetooth-hci-disallow-setting-handle-bigger-than-HC.patch.
- Refresh
  patches.suse/bluetooth-l2cap-sync-sock-recv-cb-and-release.patch.
- commit c95a285

- net: sched: fix use-after-free in taprio_change()
  (CVE-2024-50127 bsc#1232907).
- commit 8d80c7f

- fsdax: dax_unshare_iter needs to copy entire blocks
  (bsc#1233226, CVE-2024-50250).
- fsdax: remove zeroing code from dax_unshare_iter  (bsc#1233226,
  CVE-2024-50250).
- commit 94457ab

- nilfs2: fix kernel bug due to missing clearing of checked flag
  (bsc#1233206 CVE-2024-50230).
- commit ba9ac5c

- drm/amd/display: Check null pointers before used (bsc#1232371 CVE-2024-49921)
- commit 3bf6629

- net/ncsi: Disable the ncsi work before freeing the associated
  structure (CVE-2024-49945 bsc#1232165).
- commit 75d875c

- e1000e: Remove Meteor Lake SMBUS workarounds (git-fixes).
- i40e: fix race condition by adding filter's intermediate sync
  state (git-fixes).
- commit f4e661d

- Revert &amp;quot;mm/writeback: fix possible divide-by-zero in
  wb_dirty_limits(), again&amp;quot; (CVE-2024-42102 bsc#1233132).
- commit 696592c

- i2c: designware: do not hold SCL low when I2C_DYNAMIC_TAR_UPDATE
  is not set (git-fixes).
- USB: serial: io_edgeport: fix use after free in debug printk
  (git-fixes).
- usb: typec: fix potential out of bounds in
  ucsi_ccg_update_set_new_cam_cmd() (git-fixes).
- usb: musb: sunxi: Fix accessing an released usb phy (git-fixes).
- commit d16f490

- ASoC: stm: Prevent potential division by zero in
  stm32_sai_get_clk_div() (stable-fixes).
- ASoC: stm: Prevent potential division by zero in
  stm32_sai_mclk_round_rate() (stable-fixes).
- ASoC: amd: yc: Support dmic on another model of Lenovo Thinkpad
  E14 Gen 6 (stable-fixes).
- ASoC: amd: yc: fix internal mic on Xiaomi Book Pro 14 2022
  (stable-fixes).
- ASoC: tas2781: Add new driver version for tas2563 &amp;amp; tas2781
  qfn chip (stable-fixes).
- commit 1f9992e

- drm/amdgpu: Fix DPX valid mode check on GC 9.4.3 (git-fixes).
- ASoC: SOF: sof-client-probes-ipc4: Set param_size extension bits
  (git-fixes).
- ASoC: stm32: spdifrx: fix dma channel release in
  stm32_spdifrx_remove (git-fixes).
- ALSA: firewire-lib: fix return value on fail in
  amdtp_tscm_init() (git-fixes).
- media: pulse8-cec: fix data timestamp at pulse8_setup()
  (git-fixes).
- media: stb0899_algo: initialize cfr before using it (git-fixes).
- media: adv7604: prevent underflow condition when reporting
  colorspace (git-fixes).
- media: cx24116: prevent overflows on SNR calculus (git-fixes).
- media: ar0521: don't overflow when checking PLL values
  (git-fixes).
- media: s5p-jpeg: prevent buffer overflows (git-fixes).
- media: dvb_frontend: don't play tricks with underflow values
  (git-fixes).
- media: dvbdev: prevent the risk of out of memory access
  (git-fixes).
- media: v4l2-tpg: prevent the risk of a division by zero
  (git-fixes).
- media: v4l2-ctrls-api: fix error handling for v4l2_g_ctrl()
  (git-fixes).
- thunderbolt: Honor TMU requirements in the domain when setting
  TMU mode (stable-fixes).
- wifi: iwlegacy: Clear stale interrupts before resuming device
  (stable-fixes).
- USB: gadget: dummy-hcd: Fix &amp;quot;task hung&amp;quot; problem (git-fixes).
- usb: gadget: dummy_hcd: execute hrtimer callback in softirq
  context (git-fixes).
- usb: gadget: dummy_hcd: Set transfer interval to 1 microframe
  (stable-fixes).
- usb: gadget: dummy_hcd: Switch to hrtimer transfer scheduler
  (stable-fixes).
- commit c5281d0

- nfs: avoid i_lock contention in nfs_clear_invalid_mapping
  (git-fixes).
- commit e6016a1

- nfs: Fix KMSAN warning in decode_getfattr_attrs() (git-fixes).
- commit 9358249

- NFS: remove revoked delegation from server's delegation list
  (git-fixes).
- commit 6feb8eb

- SUNRPC: Remove BUG_ON call sites (git-fixes).
- commit 5969339

- nilfs2: fix potential deadlock with newly created symlinks
  (git-fixes).
- commit 002996c

- cpufreq: amd-pstate: add check for cpufreq_cpu_get's return
  value (CVE-2024-50009 bsc#1232318).
- commit 15f7e86

- ext4: fix error message when rejecting the default hash
  (bsc#1232264 CVE-2024-49968).
- commit 5d137c7

- sched/deadline: Fix task_struct reference leak (CVE-2024-41023
  bsc#1228430).
- commit 3a83981

- be2net: fix potential memory leak in be_xmit() (CVE-2024-50167
  bsc#1233049).
- commit 376f8c7

- can: mcp251xfd: mcp251xfd_get_tef_len(): fix length calculation
  (git-fixes).
- can: mcp251xfd: mcp251xfd_ring_alloc(): fix coalescing
  configuration when switching CAN modes (git-fixes).
- can: c_can: fix {rx,tx}_errors statistics (git-fixes).
- pwm: imx-tpm: Use correct MODULO value for EPWM mode
  (git-fixes).
- commit c5fa961

- blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race (CVE-2024-50082 bsc#1232500)
- commit 6a67bac

- btrfs: fix uninitialized pointer free on read_alloc_one_name() error (CVE-2024-50087 bsc#1232499)
- commit a3c097a

- btrfs: fix uninitialized pointer free in add_inode_ref() (CVE-2024-50088 bsc#1232498)
- commit 75b1127

- net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test() (CVE-2024-50084 bsc#1232494)
- commit e53e21a

- drm/amd/display: fix double free issue during amdgpu module unload (CVE-2024-49989 bsc#1232483)
- commit 6511376

- drm/amd/display: update DML2 policy EnhancedPrefetchScheduleAccelerationFinal DCN35 (CVE-2024-50004 bsc#1232396)
- commit d5739f8

- drm/amd/display: Fix system hang while resume with TBT monitor (CVE-2024-50003 bsc#1232385)
- commit 24ceb7a

- thermal: intel: int340x: processor: Fix warning during module
  unload (git-fixes).
- commit 2c3d870

- mptcp: fix double-free on socket dismantle (CVE-2024-26782
  bsc#1222590).
- mptcp: deal with large GSO size (CVE-2023-52778 bsc#1224948).
- commit 86ee052

- ext4: ext4_search_dir should return a proper error (bsc#1231920
  CVE-2024-47701).
- commit 7c02130

- ext4: explicitly exit when ext4_find_inline_entry returns an
  error (bsc#1231920 CVE-2024-47701).
- commit e600961

- ext4: return error on ext4_find_inline_entry (bsc#1231920
  CVE-2024-47701).
- commit 39b6acc

- igb: Disable threaded IRQ for igb_msix_other (git-fixes).
- commit b8afad1

- fs/inode: Prevent dump_mapping() accessing invalid
  dentry.d_name.name (bsc#1232387 CVE-2024-49934).
- commit cf2a806

- ext4: filesystems without casefold feature cannot be mounted
  with siphash (bsc#1232264 CVE-2024-49968).
- commit 1907014

- ext4: drop ppath from ext4_ext_replay_update_ex() to avoid
  double-free (bsc#1232096 CVE-2024-49983).
- commit 4a6ac53

- vfs: fix race between evice_inodes() and find_inode()&amp;amp;iput()
  (bsc#1231930 CVE-2024-47679).
- commit dcf9f6e

- ext4: avoid OOB when system.data xattr changes underneath the
  filesystem (bsc#1231920 CVE-2024-47701).
- commit f292cb3

- security/keys: fix slab-out-of-bounds in key_task_permission
  (git-fixes).
- platform/x86/amd/pmc: Detect when STB is not available
  (git-fixes).
- HID: core: zero-initialize the report buffer (git-fixes).
- commit 277fa5f

- mlxbf_gige: disable RX filters until RX path initialized
  (git-fixes).
- commit f2b07e9

- selftests/bpf: Add tests for sdiv/smod overflow cases
  (CVE-2024-49888 bsc#1232208).
- commit b193d4f

- initramfs: avoid filename buffer overrun (bsc#1232436).
- commit 4918398

- netfilter: bpf: must hold reference on net namespace
  (bsc#1232894 CVE-2024-50130).
- commit 7d292ad

- bpftool: Fix undefined behavior in qsort(NULL, 0,
  ...) (bsc#1232258 CVE-2024-49987).
- commit 80f8e64

- Update
  patches.suse/mm-mmap-no-need-to-call-khugepaged_enter_vma-for-sta.patch
  (jsc#PED-11442).
- commit d087a3b

- fbdev: efifb: Register sysfs groups through driver core
  (bsc#1232224 CVE-2024-49925).
- commit 4fd0365

- aes-gcm-p10: Use the correct bit to test for P10 (bsc#1232704).
- commit f0dea0e

- ublk: don't allow user copy for unprivileged device
  (CVE-2024-50080 bsc#1232502).
- commit 267c92f

- blk-mq: setup queue -&amp;gt;tag_set before initializing hctx
  (CVE-2024-50081 bsc#1232501).
- commit 87d4a82

- media: core: v4l2-ioctl: check if ioctl is known to avoid NULL
  name (git-fixes).
- commit c862b93

- media: videobuf2: fix typo: vb2_dbuf -&amp;gt; vb2_qbuf (git-fixes).
- commit 92209c4

- media: bttv: use audio defaults for winfast2000 (git-fixes).
- commit 6e1da70

- scsi: elx: libefc: Fix potential use after free in
  efc_nport_vport_del() (CVE-2024-49852 bsc#1232819).
- commit 51395e6

- Update config files.
  c37e85c135ce (&amp;quot;clocksource: Loosen clocksource watchdog constraints&amp;quot;)
  introduced a new default for the time skew measured by the clocksource
  watchdog. The value was raised from 100 to 125 microseconds. Reflect this
  change in the kernel config. This is an x86_64 option only.
- commit 14c1b2d

- ALSA: usb-audio: Add quirk for HP 320 FHD Webcam (bsc#1232768).
- commit 7c39137

- kABI: bpf: struct bpf_func_state kABI workaround (CVE-2024-47703
  bsc#1231946).
- commit fd45833

- selftests/bpf: Workaround strict bpf_lsm return value check
  (CVE-2024-47703 bsc#1231946).
- selftests/bpf: Add verifier tests for bpf lsm (CVE-2024-47703
  bsc#1231946).
- selftests/bpf: Add return value checks for failed tests
  (CVE-2024-47703 bsc#1231946).
- bpf: Fix compare error in function retval_range_within
  (CVE-2024-47703 bsc#1231946).
- bpf, lsm: Add check for BPF LSM return value (CVE-2024-47703
  bsc#1231946).
- Refresh patches.suse/bpf-Fail-verification-for-sign-extension-of-packet-d.patch
- Refresh patches.kabi/bpf-struct-bpf_insn_access_aux-workaround.patch
- selftests/bpf: fix timer/test_bad_ret subtest on
  test_progs-cpuv4 flavor (CVE-2024-47703 bsc#1231946).
- commit a0c7d4f

- rpmsg: glink: Handle rejected intent request better (git-fixes).
- firmware: arm_scmi: Fix slab-use-after-free in
  scmi_bus_notifier() (git-fixes).
- commit 01fe6bf

- Update references for patches.suse/tracing-timerlat-Fix-a-race-during-cpuhp-processing.patch (CVE-2024-49866 bsc#1232259 git-fixes)
- commit d9311d0

- Move out-of-tree patch into a proper section
- commit c581359

- Revert &amp;quot;ALSA: hda/conexant: Mute speakers at suspend / shutdown&amp;quot;
  (bsc#1228269).
- commit 13ce240

- scsi: lpfc: Update lpfc version to 14.4.0.5 (bsc#1232757).
- scsi: lpfc: Support loopback tests with VMID enabled
  (bsc#1232757).
- scsi: lpfc: Revise TRACE_EVENT log flag severities from KERN_ERR
  to KERN_WARNING (bsc#1232757).
- scsi: lpfc: Ensure DA_ID handling completion before deleting
  an NPIV instance (bsc#1232757).
- scsi: lpfc: Fix kref imbalance on fabric ndlps from dev_loss_tmo
  handler (bsc#1232757).
- scsi: lpfc: Restrict support for 32 byte CDBs to specific HBAs
  (bsc#1232757 bsc#1228119).
- scsi: lpfc: Update phba link state conditional before sending
  CMF_SYNC_WQE (bsc#1232757).
- scsi: lpfc: Add ELS_RSP cmd to the list of WQEs to flush in
  lpfc_els_flush_cmd() (bsc#1232757).
- scsi: lpfc: Remove trailing space after \n newline
  (bsc#1232757).
- commit 3cf27b4

- ext4: fix timer use-after-free on failed mount (CVE-2024-49960
  bsc#1232395).
- commit bd6997d

- net/xen-netback: prevent UAF in xenvif_flush_hash()
  (CVE-2024-49936 bsc#1232424).
- commit ae05dab

- tipc: guard against string buffer overrun (CVE-2024-49995
  bsc#1232432).
- commit ada263e

- drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer
  (CVE-2024-49991 bsc#1232282).
- commit 1b15839

- nvme: re-fix error-handling for io_uring nvme-passthrough
  (git-fixes).
- nvmet-auth: assign dh_key to NULL after kfree_sensitive
  (git-fixes).
- nvme-pci: fix race condition between reset and
  nvme_dev_disable() (git-fixes).
- nvme: null terminate nvme_tls_attrs (git-fixes).
- nvme-pci: set doorbell config before unquiescing (git-fixes).
- commit d7598b1

- mm: split critical region in remap_file_pages() and invoke
  LSMs in between (CVE-2024-47745 bsc#1232135 git-fix).
- commit 8228ecb

- Add alt-commit to AMDGPU patch
- commit 9e50980

- phy: tegra: xusb: Add error pointer check in xusb.c (git-fixes).
- phy: freescale: imx8m-pcie: Do CMN_RST just before PHY PLL
  lock check (git-fixes).
- phy: ti: phy-j721e-wiz: fix usxgmii configuration (git-fixes).
- phy: qcom: qmp-combo: move driver data initialisation earlier
  (git-fixes).
- phy: qcom: qmp-usb: fix NULL-deref on runtime suspend
  (git-fixes).
- dmaengine: ti: k3-udma: Set EOP for all TRs in cyclic BCDMA
  transfer (git-fixes).
- dmaengine: sh: rz-dmac: handle configs where one address is zero
  (git-fixes).
- Revert &amp;quot;driver core: Fix uevent_show() vs driver detach race&amp;quot;
  (git-fixes).
- usb: phy: Fix API devm_usb_put_phy() can not release the phy
  (git-fixes).
- usb: typec: fix unreleased fwnode_handle in
  typec_port_register_altmodes() (git-fixes).
- xhci: Fix Link TRB DMA in command ring stopped completion event
  (git-fixes).
- xhci: Use pm_runtime_get to prevent RPM on unsupported systems
  (git-fixes).
- usbip: tools: Fix detach_port() invalid port error path
  (git-fixes).
- iio: adc: ad7124: fix division by zero in
  ad7124_set_channel_odr() (git-fixes).
- staging: iio: frequency: ad9832: fix division by zero in
  ad9832_calc_freqreg() (git-fixes).
- iio: light: veml6030: fix microlux value calculation
  (git-fixes).
- iio: gts-helper: Fix memory leaks for the error path of
  iio_gts_build_avail_scale_table() (git-fixes).
- iio: gts-helper: Fix memory leaks in
  iio_gts_build_avail_scale_table() (git-fixes).
- mei: use kvmalloc for read buffer (git-fixes).
- Input: edt-ft5x06 - fix regmap leak when probe fails
  (git-fixes).
- modpost: fix input MODULE_DEVICE_TABLE() built for 64-bit on
  32-bit host (git-fixes).
- modpost: fix acpi MODULE_DEVICE_TABLE built with mismatched
  endianness (git-fixes).
- sumversion: Fix a memory leak in get_src_version() (git-fixes).
- genirq/msi: Fix off-by-one error in msi_domain_alloc()
  (git-fixes).
- commit df7fb9d

- Refresh
  patches.suse/PCI-Fix-pci_enable_acs-support-for-the-ACS-quirks.patch.
  Update upstream status.
- commit f283868

- nfsd: cancel nfsd_shrinker_work using sync mode in
  nfs4_state_shutdown_net (git-fixes).
- commit ed2b339

- NFSv3: only use NFS timeout for MOUNT when protocols are
  compatible (bsc#1231016).
- commit ddbeb4f

- Update
  patches.suse/0002-x86-mm-ident_map-Use-gbpages-only-where-full-GB-page.patch
  (bsc#1220382 CVE-2024-50017 bsc#1232312).
- Update patches.suse/ACPI-PAD-fix-crash-in-exit_round_robin.patch
  (stable-fixes CVE-2024-49935 bsc#1232370).
- Update
  patches.suse/ACPI-battery-Fix-possible-crash-when-unregistering-a.patch
  (git-fixes CVE-2024-49955 bsc#1232154).
- Update
  patches.suse/ACPI-sysfs-validate-return-type-of-_STR-method.patch
  (git-fixes CVE-2024-49860 bsc#1231861).
- Update
  patches.suse/ACPICA-check-null-return-of-ACPI_ALLOCATE_ZEROED-in-.patch
  (stable-fixes CVE-2024-49962 bsc#1232314).
- Update
  patches.suse/ALSA-asihpi-Fix-potential-OOB-array-access.patch
  (stable-fixes CVE-2024-50007 bsc#1232394).
- Update
  patches.suse/Bluetooth-Call-iso_exit-on-module-unload.patch
  (git-fixes CVE-2024-50078 bsc#1232503).
- Update
  patches.suse/Bluetooth-ISO-Fix-multiple-init-when-debugfs-is-disa.patch
  (git-fixes CVE-2024-50077 bsc#1232504).
- Update
  patches.suse/Bluetooth-RFCOMM-FIX-possible-deadlock-in-rfcomm_sk_.patch
  (git-fixes CVE-2024-50044 bsc#1231904).
- Update
  patches.suse/IB-core-Fix-ib_cache_setup_one-error-flow-cleanup.patch
  (git-fixes CVE-2024-47693 bsc#1232013).
- Update
  patches.suse/IB-core-Implement-a-limit-on-UMAD-receive-List.patch
  (bsc#1228743 CVE-2024-42145 bsc#1223384).
- Update
  patches.suse/Input-adp5589-keys-fix-NULL-pointer-dereference.patch
  (git-fixes CVE-2024-49871 bsc#1232287).
- Update
  patches.suse/KEYS-prevent-NULL-pointer-dereference-in-find_asymme.patch
  (git-fixes CVE-2024-47743 bsc#1232129).
- Update
  patches.suse/KVM-Use-dedicated-mutex-to-protect-kvm_usage_count-t.patch
  (git-fixes CVE-2024-47744 bsc#1232132).
- Update
  patches.suse/PCI-keystone-Fix-if-statement-expression-in-ks_pcie_.patch
  (git-fixes CVE-2024-47756 bsc#1232185).
- Update
  patches.suse/PCI-kirin-Fix-buffer-overflow-in-kirin_pcie_parse_po.patch
  (git-fixes CVE-2024-47751 bsc#1232127).
- Update
  patches.suse/RDMA-cxgb4-Added-NULL-check-for-lookup_atid.patch
  (git-fixes CVE-2024-47749 bsc#1232180).
- Update
  patches.suse/RDMA-hns-Fix-Use-After-Free-of-rsv_qp-on-HIP08.patch
  (git-fixes CVE-2024-47750 bsc#1232182).
- Update
  patches.suse/RDMA-hns-Fix-spin_unlock_irqrestore-called-with-IRQs.patch
  (git-fixes CVE-2024-47735 bsc#1232111).
- Update
  patches.suse/RDMA-iwcm-Fix-WARNING-at_kernel-workqueue.c-check_fl.patch
  (git-fixes CVE-2024-47696 bsc#1231864).
- Update
  patches.suse/RDMA-rtrs-clt-Reset-cid-to-con_num-1-to-stay-in-boun.patch
  (git-fixes CVE-2024-47695 bsc#1231931).
- Update
  patches.suse/RDMA-rtrs-srv-Avoid-null-pointer-deref-during-path-e.patch
  (git-fixes CVE-2024-50062 bsc#1232232).
- 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/bpf-Fail-verification-for-sign-extension-of-packet-d.patch
  (git-fixes CVE-2024-47702 bsc#1231924).
- Update
  patches.suse/bpf-Fix-helper-writes-to-read-only-maps.patch
  (git-fixes CVE-2024-49861 bsc#1232254).
- Update
  patches.suse/bpf-Fix-use-after-free-in-bpf_uprobe_multi_link_attach.patch
  (git-fixes CVE-2024-47675 bsc#1231926).
- Update
  patches.suse/bpf-Zero-former-ARG_PTR_TO_-LONG-INT-args-in-case-of.patch
  (git-fixes CVE-2024-47728 bsc#1232076).
- Update
  patches.suse/bpf-correctly-handle-malformed-BPF_CORE_TYPE_ID_LOCA.patch
  (git-fixes CVE-2024-49850 bsc#1232189).
- Update
  patches.suse/cachefiles-fix-dentry-leak-in-cachefiles_open_file.patch
  (bsc#1231183 CVE-2024-49870 bsc#1232279).
- Update
  patches.suse/can-bcm-Clear-bo-bcm_proc_read-after-remove_proc_ent.patch
  (git-fixes CVE-2024-47709 bsc#1232048).
- Update
  patches.suse/crypto-iaa-Fix-potential-use-after-free-bug.patch
  (git-fixes CVE-2024-47732 bsc#1232109).
- Update
  patches.suse/cxl-pci-Fix-disabling-memory-if-DVSEC-CXL-Range-does.patch
  (git-fixes CVE-2024-26761 bsc#1230375).
- Update
  patches.suse/driver-core-Fix-a-potential-null-ptr-deref-in-module.patch
  (git-fixes CVE-2024-47688 bsc#1232009).
- Update
  patches.suse/driver-core-bus-Fix-double-free-in-driver-API-bus_re.patch
  (stable-fixes CVE-2024-50055 bsc#1232329).
- Update
  patches.suse/drivers-media-dvb-frontends-rtl2830-fix-an-out-of-bo.patch
  (git-fixes CVE-2024-47697 bsc#1231858).
- Update
  patches.suse/drivers-media-dvb-frontends-rtl2832-fix-an-out-of-bo.patch
  (git-fixes CVE-2024-47698 bsc#1231859).
- Update
  patches.suse/drm-amd-display-Add-null-check-for-set_output_gamma-.patch
  (git-fixes CVE-2024-47720 bsc#1232043).
- Update
  patches.suse/drm-amd-display-Check-null-pointer-before-dereferenc.patch
  (stable-fixes CVE-2024-50049 bsc#1232309).
- Update
  patches.suse/drm-amd-display-fixed-integer-types-and-null-check-l.patch
  (git-fixes CVE-2024-26767 bsc#1230339).
- Update
  patches.suse/drm-omapdrm-Add-missing-check-for-alloc_ordered_work.patch
  (git-fixes CVE-2024-49879 bsc#1232349).
- Update
  patches.suse/drm-v3d-Stop-the-active-perfmon-before-being-destroy.patch
  (git-fixes CVE-2024-50031 bsc#1231947).
- Update
  patches.suse/efistub-tpm-Use-ACPI-reclaim-memory-for-event-log-to.patch
  (stable-fixes CVE-2024-49858 bsc#1232251).
- Update
  patches.suse/ep93xx-clock-Fix-off-by-one-in-ep93xx_div_recalc_rat.patch
  (git-fixes CVE-2024-47686 bsc#1232000).
- Update
  patches.suse/exfat-fix-memory-leak-in-exfat_load_bitmap.patch
  (git-fixes CVE-2024-50013 bsc#1232080).
- Update
  patches.suse/fbcon-Fix-a-NULL-pointer-dereference-issue-in-fbcon_.patch
  (stable-fixes CVE-2024-50048 bsc#1232310).
- Update
  patches.suse/firmware-arm_scmi-Fix-double-free-in-OPTEE-transport.patch
  (git-fixes CVE-2024-49853 bsc#1232192).
- Update patches.suse/firmware_loader-Block-path-traversal.patch
  (git-fixes CVE-2024-47742 bsc#1232126).
- Update
  patches.suse/i2c-stm32f7-Do-not-prepare-unprepare-clock-during-ru.patch
  (git-fixes CVE-2024-49985 bsc#1232094).
- Update
  patches.suse/i3c-master-cdns-Fix-use-after-free-vulnerability-in-.patch
  (stable-fixes CVE-2024-50061 bsc#1232263).
- Update
  patches.suse/i3c-master-svc-Fix-use-after-free-vulnerability-in-s.patch
  (git-fixes CVE-2024-49874 bsc#1232295).
- Update
  patches.suse/i40e-Fix-XDP-program-unloading-while-removing-the-dr.patch
  (git-fixes CVE-2024-41047 bsc#1228537).
- Update
  patches.suse/idpf-fix-UAFs-when-destroying-the-queues.patch
  (git-fixes CVE-2024-44932 bsc#1229808).
- Update
  patches.suse/idpf-fix-memory-leaks-and-crashes-while-performing-a.patch
  (git-fixes CVE-2024-44964 bsc#1230220).
- Update
  patches.suse/iommufd-Protect-against-overflow-of-ALIGN-during-iov.patch
  (git-fixes CVE-2024-47719 bsc#1231865).
- Update
  patches.suse/jffs2-prevent-xattr-node-from-overflowing-the-eraseblock.patch
  (git-fixes CVE-2024-38599 bsc#1226848 bsc#1223384).
- Update patches.suse/jfs-Fix-uaf-in-dbFreeBits.patch (git-fixes
  CVE-2024-49903 bsc#1232362).
- Update
  patches.suse/jfs-Fix-uninit-value-access-of-new_ea-in-ea_buffer.patch
  (git-fixes CVE-2024-49900 bsc#1232359).
- Update
  patches.suse/jfs-check-if-leafidx-greater-than-num-leaves-per-dmap-tree.patch
  (git-fixes CVE-2024-49902 bsc#1232378).
- Update
  patches.suse/jfs-fix-out-of-bounds-in-dbNextAG-and-diAlloc.patch
  (git-fixes CVE-2024-47723 bsc#1232050).
- Update
  patches.suse/mailbox-bcm2835-Fix-timeout-during-suspend-mode.patch
  (git-fixes CVE-2024-49963 bsc#1232147).
- Update
  patches.suse/md-Don-t-ignore-suspended-array-in-md_check_recovery-1baa.patch
  (bsc#1219596 CVE-2024-26758 bsc#1230341).
- Update patches.suse/media-edia-dvbdev-fix-a-use-after-free.patch
  (git-fixes CVE-2024-27043 bsc#1223824 bsc#1218562).
- Update
  patches.suse/media-i2c-ar0521-Use-cansleep-version-of-gpiod_set_v.patch
  (git-fixes CVE-2024-49961 bsc#1232148).
- Update
  patches.suse/media-venus-fix-use-after-free-bug-in-venus_remove-d.patch
  (git-fixes CVE-2024-49981 bsc#1232098).
- Update
  patches.suse/nbd-fix-race-between-timeout-and-normal-completion.patch
  (bsc#1230918 CVE-2024-49855 bsc#1232195).
- Update
  patches.suse/net-phy-Remove-LED-entry-from-LEDs-list-on-unregiste.patch
  (git-fixes CVE-2024-50023 bsc#1231955).
- Update
  patches.suse/net-test-for-not-too-small-csum_start-in-virtio_net_.patch
  (git-fixes CVE-2024-49947 bsc#1232162).
- Update
  patches.suse/nfsd-call-cache_put-if-xdr_reserve_space-returns-NULL.patch
  (git-fixes CVE-2024-47737 bsc#1232056).
- Update
  patches.suse/nfsd-map-the-EBADMSG-to-nfserr_io-to-avoid-warning.patch
  (git-fixes CVE-2024-49875 bsc#1232333).
- Update
  patches.suse/nilfs2-fix-potential-null-ptr-deref-in-nilfs_btree_insert.patch
  (git-fixes CVE-2024-47699 bsc#1231916).
- Update
  patches.suse/nilfs2-fix-potential-oob-read-in-nilfs_btree_check_delete.patch
  (git-fixes CVE-2024-47757 bsc#1232187).
- Update
  patches.suse/nouveau-dmem-handle-kcalloc-allocation-failure.patch
  (git-fixes CVE-2024-26943 bsc#1230527).
- Update
  patches.suse/ocfs2-cancel-dqi_sync_work-before-freeing-oinfo.patch
  (git-fixes CVE-2024-49966 bsc#1232141).
- Update
  patches.suse/ocfs2-fix-null-ptr-deref-when-journal-load-failed.patch
  (git-fixes CVE-2024-49957 bsc#1232152).
- Update
  patches.suse/ocfs2-fix-possible-null-ptr-deref-in-ocfs2_set_buffer_uptodate.patch
  (git-fixes CVE-2024-49877 bsc#1232339).
- Update
  patches.suse/ocfs2-remove-unreasonable-unlock-in-ocfs2_read_blocks.patch
  (git-fixes CVE-2024-49965 bsc#1232142).
- Update
  patches.suse/parport-Proper-fix-for-array-out-of-bounds-access.patch
  (git-fixes CVE-2024-50074 bsc#1232507).
- Update
  patches.suse/pinctrl-apple-check-devm_kasprintf-returned-value.patch
  (git-fixes CVE-2024-50069 bsc#1232511).
- Update
  patches.suse/platform-x86-ISST-Fix-the-KASAN-report-slab-out-of-b.patch
  (git-fixes CVE-2024-49886 bsc#1232196).
- Update
  patches.suse/powercap-intel_rapl-Fix-off-by-one-in-get_rpi.patch
  (git-fixes CVE-2024-49862 bsc#1231871).
- Update
  patches.suse/resource-fix-region_intersects-vs-add_memory_driver_.patch
  (git-fixes CVE-2024-49878 bsc#1232340).
- Update
  patches.suse/scsi-fnic-Move-flush_work-initialization-out-of-if-b.patch
  (bsc#1230055 CVE-2024-50025 bsc#1231953).
- Update
  patches.suse/scsi-lpfc-validate-hdwq-pointers-before-dereferencing-in.patch
  (bsc#1229429 jsc#PED-9899 CVE-2024-49891 bsc#1232218).
- Update
  patches.suse/scsi-sd-Fix-off-by-one-error-in-sd_read_block_charac.patch
  (bsc#1223848 CVE-2024-47682 bsc#1231856).
- Update
  patches.suse/serial-protect-uart_port_dtr_rts-in-uart_shutdown-to.patch
  (stable-fixes CVE-2024-50058 bsc#1232285).
- Update
  patches.suse/tpm-Clean-up-TPM-space-after-command-failure.patch
  (git-fixes CVE-2024-49851 bsc#1232134).
- Update
  patches.suse/tty-n_gsm-Fix-use-after-free-in-gsm_cleanup_mux.patch
  (stable-fixes CVE-2024-50073 bsc#1232520).
- Update
  patches.suse/vhost-scsi-null-ptr-dereference-in-vhost_scsi_get_re.patch
  (git-fixes CVE-2024-49863 bsc#1232255).
- Update
  patches.suse/vhost_vdpa-assign-irq-bypass-producer-token-correctl.patch
  (git-fixes CVE-2024-47748 bsc#1232174).
- Update patches.suse/vmxnet3-Fix-missing-reserved-tailroom.patch
  (bsc#1226498 CVE-2024-27026 bsc#1223700).
- Update
  patches.suse/vt-prevent-kernel-infoleak-in-con_font_get.patch
  (git-fixes CVE-2024-50076 bsc#1232505).
- Update
  patches.suse/wifi-ath11k-fix-array-out-of-bound-access-in-SoC-sta.patch
  (stable-fixes CVE-2024-49930 bsc#1232260).
- Update
  patches.suse/wifi-ath12k-fix-array-out-of-bound-access-in-SoC-sta.patch
  (stable-fixes CVE-2024-49931 bsc#1232275).
- Update
  patches.suse/wifi-ath9k_htc-Use-__skb_set_length-for-resetting-ur.patch
  (stable-fixes CVE-2024-49938 bsc#1232552).
- Update
  patches.suse/wifi-cfg80211-Set-correct-chandef-when-starting-CAC.patch
  (stable-fixes CVE-2024-49937 bsc#1232427).
- Update
  patches.suse/wifi-iwlwifi-mvm-avoid-NULL-pointer-dereference.patch
  (stable-fixes CVE-2024-49929 bsc#1232253).
- Update
  patches.suse/wifi-mac80211-don-t-use-rate-mask-for-offchannel-TX-.patch
  (git-fixes CVE-2024-47738 bsc#1232114).
- Update
  patches.suse/wifi-mac80211-use-two-phase-skb-reclamation-in-ieee8.patch
  (git-fixes CVE-2024-47713 bsc#1232016).
- Update
  patches.suse/wifi-mt76-mt7915-fix-oops-on-non-dbdc-mt7986.patch
  (git-fixes CVE-2024-47715 bsc#1231860).
- Update
  patches.suse/wifi-mt76-mt7996-fix-NULL-pointer-dereference-in-mt7.patch
  (git-fixes CVE-2024-47681 bsc#1231855).
- Update
  patches.suse/wifi-mt76-mt7996-use-hweight16-to-get-correct-tx-ant.patch
  (git-fixes CVE-2024-47714 bsc#1232018).
- Update
  patches.suse/wifi-mwifiex-Fix-memcpy-field-spanning-write-warning.patch
  (stable-fixes CVE-2024-50008 bsc#1232317).
- Update
  patches.suse/wifi-rtw88-always-wait-for-both-firmware-loading-att.patch
  (git-fixes CVE-2024-47718 bsc#1232015).
- Update
  patches.suse/wifi-rtw89-avoid-reading-out-of-bounds-when-loading-.patch
  (stable-fixes CVE-2024-49928 bsc#1232250).
- Update
  patches.suse/wifi-rtw89-avoid-to-add-interface-to-list-twice-when.patch
  (stable-fixes CVE-2024-49939 bsc#1232381).
- Update
  patches.suse/wifi-wilc1000-fix-potential-RCU-dereference-issue-in.patch
  (git-fixes CVE-2024-47712 bsc#1232017).
- Update
  patches.suse/xhci-tegra-fix-checked-USB2-port-number.patch
  (git-fixes CVE-2024-50075 bsc#1232506).
- commit a270265

- 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/media-pci-cx23885-check-cx23885_vdev_init-return.patch
  (stable-fixes CVE-2023-52918 bsc#1232047).
- Update
  patches.suse/nfc-nci-fix-possible-NULL-pointer-dereference-in-sen.patch
  (git-fixes CVE-2023-52919 bsc#1231988).
- Update
  patches.suse/ntb-intel-Fix-the-NULL-vs-IS_ERR-bug-for-debugfs_cre.patch
  (git-fixes CVE-2023-52917 bsc#1231849).
- 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 9859953

- NFSD: Force all NFSv4.2 COPY requests to be synchronous
  (CVE-2024-49974 bsc#1232383).
- commit 16045fc

- fgraph: Change the name of cpuhp state to &amp;quot;fgraph:online&amp;quot;
  (git-fixes).
- commit 59421b3

- fgraph: Fix missing unlock in register_ftrace_graph()
  (git-fixes).
- commit 60d91ed

- fs/9p: drop inodes immediately on non-.L too (git-fixes).
- commit 5fa5f19

- 9p: explicitly deny setlease attempts (git-fixes).
- commit 474852b

- fs/9p: fix the cache always being enabled on files with qid
  flags (git-fixes).
- commit 362152c

- zonefs: Improve error handling (git-fixes).
- commit cb63c4c

- debugfs: fix automount d_fsdata usage (git-fixes).
- commit 5f78a06

- splice: fsnotify_access(in), fsnotify_modify(out) on success
  in tee (git-fixes).
- commit d518e6d

- splice: fsnotify_access(fd)/fsnotify_modify(fd) in vmsplice
  (git-fixes).
- commit d630f18

- splice: always fsnotify_access(in), fsnotify_modify(out)
  on success (git-fixes).
- commit e7f8947

- keys: Fix overwrite of key expiration on instantiation
  (git-fixes).
- commit 323181d

- audit: don't WARN_ON_ONCE(!current-&amp;gt;mm) in audit_exe_compare()
  (git-fixes).
- commit e2db423

- ocfs2: fix uninit-value in ocfs2_get_block() (git-fixes).
- commit 426a4b1

- keys, dns: Allow key types (eg. DNS) to be reclaimed immediately
  on expiry (git-fixes).
- commit ce262a7

- Revert &amp;quot;KEYS: encrypted: Add check for strsep&amp;quot; (git-fixes).
- commit 7aa308c

- ubifs: add check for crypto_shash_tfm_digest (git-fixes).
- commit ea9ba15

- ubifs: dbg_orphan_check: Fix missed key type checking
  (git-fixes).
- commit 465ad1a

- ubifs: Fix adding orphan entry twice for the same inode
  (git-fixes).
- commit 93096ab

- Revert &amp;quot;ubifs: ubifs_symlink: Fix memleak of inode-&amp;gt;i_link in
  error path&amp;quot; (git-fixes).
- commit 0a7c17d

- ubifs: Fix unattached xattr inode if powercut happens after
  deleting (git-fixes).
- commit 6c90268

- audit: don't take task_lock() in audit_exe_compare() code path
  (git-fixes).
- Refresh patches.suse/vfs-add-super_operations-get_inode_dev.
- commit d4e23ef

- uprobes: fix kernel info leak via &amp;quot;[uprobes]&amp;quot; vma (bsc#1231114
  CVE-2024-46828).
- uprobes: turn xol_area-&amp;gt;pages into xol_area-&amp;gt;page (bsc#1231114).
- uprobes: introduce the global struct vm_special_mapping
  xol_mapping (bsc#1231114).
- commit 4f9954c

- sched: sch_cake: fix bulk flow accounting logic for host
  fairness (bsc#1231114 CVE-2024-46828).
- commit ad42d5f

- xfs: fix finding a last resort AG in xfs_filestream_pick_ag
  (git-fixes).
- commit a10af4c

- static_call: Handle module init failure correctly in
  static_call_del_module() (bsc#1232083 CVE-2024-50002).
- commit af953b9

- ALSA: hda/realtek: Refactor and simplify Samsung Galaxy Book
  init (stable-fixes).
- Refresh
  patches.suse/ALSA-hda-realtek-Add-quirk-for-Huawei-MateBook-13-KL.patch.
- commit 98d4026

- ALSA: hda/realtek: Enable mic on Vaio VJFH52 (stable-fixes).
- commit 7075c22

- ALSA: hda/realtek: tas2781: Fix ROG ALLY X audio (stable-fixes).
- commit e26a542

- ALSA: hda/realtek: Fix headset mic on TUXEDO Stellaris 16 Gen6
  mb1 (stable-fixes).
- ALSA: hda/realtek: Fix headset mic on TUXEDO Gemini 17 Gen3
  (stable-fixes).
- ALSA: usb-audio: Add quirks for Dell WD19 dock (stable-fixes).
- ASoC: dapm: fix bounds checker error in dapm_widget_list_create
  (git-fixes).
- ASoC: Intel: sst: Fix used of uninitialized ctx to log an error
  (git-fixes).
- ASoC: Intel: sst: Support LPE0F28 ACPI HID (stable-fixes).
- ASoC: Intel: bytcr_rt5640: Add DMI quirk for Vexia Edu Atla
  10 tablet (stable-fixes).
- ASoC: Intel: bytcr_rt5640: Add support for non ACPI instantiated
  codec (stable-fixes).
- ASoC: codecs: rt5640: Always disable IRQs from
  rt5640_cancel_work() (stable-fixes).
- ALSA: hda/realtek: Add subwoofer quirk for Infinix ZERO BOOK 13
  (stable-fixes).
- ALSA: hda/realtek: Limit internal Mic boost on Dell platform
  (stable-fixes).
- commit 0d350ca

- drm/mediatek: Fix get efuse issue for MT8188 DPTX (git-fixes).
- drm/amd/pm: Vangogh: Fix kernel memory out of bounds write
  (git-fixes).
- ACPI: CPPC: Make rmw_lock a raw_spin_lock (git-fixes).
- firmware: arm_sdei: Fix the input parameter of
  cpuhp_remove_state() (git-fixes).
- kasan: Fix Software Tag-Based KASAN with GCC (git-fixes).
- commit 2a07e04

- Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs
  (git-fixes).
- wifi: cfg80211: clear wdev-&amp;gt;cqm_config pointer on free
  (git-fixes).
- Revert &amp;quot;wifi: iwlwifi: remove retry loops in start&amp;quot; (git-fixes).
- wifi: iwlwifi: mvm: don't add default link in fw restart flow
  (git-fixes).
- wifi: iwlwifi: mvm: Fix response handling in
  iwl_mvm_send_recovery_cmd() (git-fixes).
- wifi: iwlwifi: mvm: don't leak a link on AP removal (git-fixes).
- wifi: ath11k: Fix invalid ring usage in full monitor mode
  (git-fixes).
- wifi: ath10k: Fix memory leak in management tx (git-fixes).
- wifi: brcm80211: BRCM_TRACING should depend on TRACING
  (git-fixes).
- wifi: mac80211: skip non-uploaded keys in ieee80211_iter_keys
  (git-fixes).
- wifi: mac80211: do not pass a stopped vif to the driver in
  .get_txpower (git-fixes).
- mac80211: MAC80211_MESSAGE_TRACING should depend on TRACING
  (git-fixes).
- wifi: iwlegacy: Fix &amp;quot;field-spanning write&amp;quot; warning in
  il_enqueue_hcmd() (git-fixes).
- ASoC: cs42l51: Fix some error handling paths in cs42l51_probe()
  (git-fixes).
- platform/x86: dell-wmi: Ignore suspend notifications
  (stable-fixes).
- ACPI: button: Add DMI quirk for Samsung Galaxy Book2 to fix
  initial lid detection issue (stable-fixes).
- ACPI: resource: Add LG 16T90SP to irq1_level_low_skip_override[]
  (stable-fixes).
- drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too
  (stable-fixes).
- drm/amd: Guard against bad data for ATIF ACPI method
  (git-fixes).
- usb: gadget: f_uac2: fix return value for UAC2_ATTRIBUTE_STRING
  store (git-fixes).
- accel/qaic: Fix the for loop used to walk SG table (git-fixes).
- drm/amd/amdgpu: Fix double unlock in amdgpu_mes_add_ring
  (git-fixes).
- drm/msm/dpu: don't always program merge_3d block (git-fixes).
- drm/msm: Allocate memory for disp snapshot with kvzalloc()
  (git-fixes).
- drm/msm: Avoid NULL dereference in msm_disp_state_print_regs()
  (git-fixes).
- drm/msm/dsi: fix 32-bit signed integer extension in pclk_rate
  calculation (git-fixes).
- drm/msm/dsi: improve/fix dsc pclk calculation (git-fixes).
- drm/msm/dpu: check for overflow in _dpu_crtc_setup_lm_bounds()
  (git-fixes).
- drm/msm/dpu: move CRTC resource assignment to
  dpu_encoder_virt_atomic_check (git-fixes).
- drm/msm/dpu: make sure phys resources are properly initialized
  (git-fixes).
- platform/x86: dell-sysman: add support for alienware products
  (stable-fixes).
- drm/vboxvideo: Replace fake VLA at end of
  vbva_mouse_pointer_shape with real VLA (stable-fixes).
- usb: gadget: f_uac2: fix non-newline-terminated function name
  (stable-fixes).
- usb: gadget: f_uac2: Replace snprintf() with the safer
  scnprintf() variant (stable-fixes).
- commit 09f40f7

- drm/amd/display: Check null pointers before using them (CVE-2024-49922 bsc#1232374)
- commit 342005c

- drm/amd/display: Handle null 'stream_status' in 'planes_changed_for_existing_stream' (CVE-2024-49912 bsc#1232367)
- commit 2394db2

- drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func (CVE-2024-49911 bsc#1232366)
- commit 6c83ea7

- drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags (CVE-2024-49923 bsc#1232361)
- commit 3759560

- drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation (CVE-2024-49895 bsc#1232352)
- commit f36c162

- drm/amd/display: Initialize denominators' default to 1 (CVE-2024-49899 bsc#1232358)
- commit 282fa51

- Update references for patches.suse/0001-drm-amd-display-Add-null-check-for-afb-in-amdgpu_dm_.patch (bsc#1232335 CVE-2024-49908 bsc#1232357 CVE-2024-49905)
- commit fa3a85a

- drm/amd/display: Check phantom_stream before it is used (CVE-2024-49897 bsc#1232355)
- commit d3fcaed

- drm/amd/display: Fix index out of bounds in degamma hardware format translation (CVE-2024-49894 bsc#1232354)
- commit db76ccb

- drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func (CVE-2024-49909 bsc#1232337)
- commit 11facc9

- drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream (CVE-2024-49913 bsc#1232307)
- commit 60f7853

- drm/msm/adreno: Assign msm_gpu-&amp;gt;pdev earlier to avoid nullptrs (CVE-2024-49901 bsc#1232305)
- commit 69be7bb

- RAS/AMD/ATL: Implement DF 4.5 NP2 denormalization (jsc#PED-10559).
- commit 52d40f4

- RAS/AMD/ATL: Validate address map when information is gathered (jsc#PED-10559).
- commit 94e412f

- RAS/AMD/ATL: Expand helpers for adding and removing base and hole (jsc#PED-10559).
- commit 2b18348

- RAS/AMD/ATL: Read DRAM hole base early (jsc#PED-10559).
- commit e1cf5b5

- RAS/AMD/ATL: Add amd_atl pr_fmt() prefix (jsc#PED-10559).
- commit 17f78f9

- drm/amd/display: Check null pointer before try to access it (bsc#1232332 CVE-2024-49906)
- commit f2b2892

- drm/amd/display: Add null check for pipe_ctx-&amp;gt;plane_state in (bsc#1232369 CVE-2024-49914)
- commit c236474

- drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (bsc#1232335 CVE-2024-49908)
- commit 64a943f

- drm/amd/display: Check null pointers before using dc-&amp;gt;clk_mgr (bsc#1232334 CVE-2024-49907)
- commit 366c63a

- RDMA/bnxt_re: synchronize the qp-handle table array (git-fixes)
- commit 866dbc5

- RDMA/bnxt_re: Fix the usage of control path spin locks (git-fixes)
- commit c834f25

- RDMA/mlx5: Round max_rd_atomic/max_dest_rd_atomic up instead of down (git-fixes)
- commit 3c270f2

- RDMA/cxgb4: Dump vendor specific QP details (git-fixes)
- commit 587d3b0

- ext4: fix access to uninitialised lock in fc replay path (CVE-2024-50014 bsc#1232446)
- commit 1b2ba45

- ext4: fix i_data_sem unlock order in ext4_ind_migrate() (CVE-2024-50006 bsc#1232442)
- commit de0e62b

- scsi: ufs: core: Remove SCSI host only if added (CVE-2024-46843
  bsc#1231100).
- commit b455bee

- io_uring: check if we need to reschedule during overflow flush
  (bsc#1232417 CVE-2024-50060).
- commit 695bc5f

- iommu/vt-d: Fix potential lockup if qi_submit_sync called
  with 0 count (bsc#1232316 CVE-2024-49993).
- commit f1e5ce7

- ext4: dax: fix overflowing extents beyond inode size when partially writing (CVE-2024-50015 bsc#1232079)
- commit 9768b7c

- jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error (CVE-2024-49959 bsc#1232149)
- commit 8307a3a

- of: Add cleanup.h based auto release via __free(device_node) markings (bsc#1232386)
- commit 794e5ba

- net: stmmac: dwmac-tegra: Fix link bring-up sequence (git-fixes)
- commit 277d940

- cpufreq: Avoid a bad reference count on CPU node (CVE-2024-50012 bsc#1232386)
- commit 283b9a0

- ext4: update orig_path in ext4_find_extent() (CVE-2024-49881 bsc#1232201)
- commit 2ed2a04

- ext4: fix slab-use-after-free in ext4_split_extent_at() (bsc#1232201)
- commit c78e4be

- btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info()
  in walk_down_proc() (CVE-2024-46841 bsc#1231094).
- commit fb4a0c7

- ext4: aovid use-after-free in ext4_ext_insert_extent() (CVE-2024-49883 bsc#1232199)
- commit 2db9cb5

- blk_iocost: fix more out of bound shifts (CVE-2024-49933 bsc#1232368)
- commit df53397

- drm/amd/display: Fix index out of bounds in DCN30 color
  transformation (CVE-2024-49969 bsc#1232519).
- commit 7d6c264

- static_call: Replace pointless WARN_ON() in
  static_call_module_notify() (bsc#1232155 CVE-2024-49954).
- commit 03b6c35

- module: abort module loading when sysfs setup suffer errors
  (git-fixes).
- Refresh patches.suse/add-suse-supported-flag.patch.
- commit db27509

- bpf,perf: Fix perf_event_detach_bpf_prog error handling
  (git-fixes).
- commit 5b6b2d4

- tracing: Consider the NULL character when validating the event
  length (git-fixes).
- commit 6b1d97f

- uprobe: avoid out-of-bounds memory access of fetching args
  (git-fixes).
- uprobes: encapsulate preparation of uprobe args buffer
  (git-fixes).
- commit ead6cfe

- s390/pci: Handle PCI error codes other than 0x3a (git-fixes
  bsc#1232629).
- commit e4948be

- s390/sclp: Deactivate sclp after all its users (git-fixes
  bsc#1232628).
- commit 9e889e7

- s390/sclp_vt220: Convert newlines to CRLF instead of LFCR
  (git-fixes bsc#1232627).
- commit 5725ee0

- KVM: s390: Change virtual to physical address access in diag
  0x258 handler (git-fixes bsc#1232626).
- commit 2b0b1e9

- KVM: s390: gaccess: Check if guest address is in memslot
  (git-fixes bsc#1232623).
- commit b583687

- fgraph: Use CPU hotplug mechanism to initialize idle shadow
  stacks (git-fixes).
- commit 4265ef9

- mm: khugepaged: fix the arguments order in
  khugepaged_collapse_file trace point (git-fixes).
- commit 43546b6

- tracing/hwlat: Fix a race during cpuhp processing (git-fixes).
- tracing/timerlat: Fix a race during cpuhp processing
  (git-fixes).
- tracing/timerlat: Drop interface_lock in stop_kthread()
  (git-fixes).
- tracing/timerlat: Fix duplicated kthread creation due to CPU
  online/offline (git-fixes).
- tracing/osnoise: Fix build when timerlat is not enabled
  (git-fixes).
- tracing/timerlat: Add interface_lock around clearing of kthread
  in stop_kthread() (git-fixes).
- tracing/timerlat: Only clear timer if a kthread exists
  (git-fixes).
- tracing/osnoise: Use a cpumask to know what threads are kthreads
  (git-fixes).
- tracing/timerlat: Move hrtimer_init to timerlat_fd open()
  (git-fixes).
- tracing/timerlat: Add user-space interface (git-fixes).
- tracing/osnoise: Skip running osnoise if all instances are off
  (git-fixes).
- tracing/osnoise: Switch from PF_NO_SETAFFINITY to
  migrate_disable (git-fixes).
- commit 8482ad0

- ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow
  (git-fixes).
- commit 24fea60

- Refresh patches.suse/x86-fix-user-address-masking-non-canonical-speculation-iss.patch. (bsc#1232529)
  Give check_range a unique label. Otherwise the macro's 1b label
  conflicts with __get_user_1's 1 label and this causes the exception fixup
  entry, installed at the end of the file to match the wrong thing.
  Instead of matching __get_user_1's 1b label it will match check_range's 1b
  label when this macro is expanded for the last time in __get_user_8.
  This fixes intermittent random crashes when copying data from userspace.
- commit 3a35fd0

- jump_label: Fix static_key_slow_dec() yet again (git-fixes).
- commit ab363f5

- SUNRPC: Fixup gss_status tracepoint error output (git-fixes).
- commit 84cc417

- drm/amd/display: Deallocate DML memory if allocation fails (CVE-2024-49972 bsc#1232315)
- commit dd5ab13

- drm/amd/display: Check stream before comparing them (CVE-2024-49896 bsc#1232221)
- commit 930546b

- drm/amd/pm: ensure the fw_info is not null before using it (CVE-2024-49890 bsc#1232217)
- commit a0e8b9f

- drm/amd/display: Initialize get_bytes_per_element's default to 1 (CVE-2024-49892 bsc#1232220)
- commit e1539d0

- drivers/perf: Fix ali_drw_pmu driver interrupt status clearing (CVE-2024-47731 bsc#1232117)
- commit 774dc33

- padata: use integer wrap around to prevent deadlock on seq_nr overflow (CVE-2024-47739 bsc#1232124)
- commit 7e58560

- media: mediatek: vcodec: Fix H264 stateless decoder smatch warning (CVE-2024-47752 bsc#1232130)
- commit 086cd43

- media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning (CVE-2024-47754 bsc#1232131)
- commit dacb1c6

- media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning (CVE-2024-47753 bsc#1231868)
- commit fed66a9

- iommu/vt-d: Always reserve a domain ID for identity setup
  (git-fixes).
- commit f7ecad0

- btrfs: clean up our handling of refs == 0 in snapshot delete (CVE-2024-46840 bsc#1231105)
- commit 788d396

- kABI: bpf: struct bpf_map kABI workaround (CVE-2024-50063
  bsc#1232435).
- selftests/bpf: Add test for lsm tail call (CVE-2024-50063
  bsc#1232435).
- bpf: Prevent tail call between progs attached to different hooks
  (CVE-2024-50063 bsc#1232435).
- commit 666246a

- iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI
  devices (git-fixes).
- commit 28951a9

- drm/amd/display: Check null pointers before multiple uses (bsc#1232313 CVE-2024-49920)
- commit 5447aa1

- drm/amd/display: Check link_res-&amp;gt;hpo_dp_link_enc before using it (bsc#1231944)
- commit bf57b96

- drm/amd/display: Check null-initialized variables (bsc#1232222 CVE-2024-49898)
- commit a00bfda

- drm/amd/display: Check link_res-&amp;gt;hpo_dp_link_enc before using it (bsc#1231944 CVE-2024-47704)
- commit 931c899

- spi: spi-fsl-dspi: Fix crash when not using GPIO chip select
  (git-fixes).
- spi: mtk-snfi: fix kerneldoc for mtk_snand_is_page_ops()
  (git-fixes).
- spi: atmel-quadspi: Fix wrong register value written to MR
  (git-fixes).
- commit fd0b348

- crypto: stm32/cryp - call finalize with bh disabled
  (CVE-2024-47658 bsc#1231436).
- commit 2854148

- smb: client: fix UAF in async decryption (bsc#1232418
  CVE-2024-50047).
- commit 381863e

- e1000e: fix force smbus during suspend flow (git-fixes).
- commit f9cbf12

- btrfs: wait for fixup workers before stopping cleaner kthread
  during umount (bsc#1232262 CVE-2024-49867).
- btrfs: fix race setting file private on concurrent lseek using
  same fd (bsc#1231869 CVE-2024-47741).
- commit af36a3e

- ppp: fix ppp_async_encode() illegal access (CVE-2024-50035
  bsc#1232392).
- net: avoid potential underflow in qdisc_pkt_len_init() with UFO
  (CVE-2024-49949 bsc#1232160).
- commit f4bcea0

- ice: map XDP queues to vectors in ice_vsi_map_rings_to_vectors()
  (git-fixes).
- Refresh
  patches.suse/ice-move-netif_queue_set_napi-to-rtnl-protected-sect.patch.
- commit 7b44c3c

- net/mlx5: Check capability for fw_reset (git-fixes).
- Refresh
  patches.suse/net-mlx5-Fix-MTMP-register-capability-offset-in-MCAM.patch.
- commit 480249d

- net/mlx5e: Don't call cleanup on profile rollback failure
  (git-fixes).
- net/mlx5: Unregister notifier on eswitch init failure
  (git-fixes).
- net/mlx5: Fix command bitmask initialization (git-fixes).
- net/mlx5: Check for invalid vector index on EQ creation
  (git-fixes).
- e1000e: change I219 (19) devices to ADP (git-fixes).
- ice: Flush FDB entries before reset (git-fixes).
- ice: Fix netif_is_ice() in Safe Mode (git-fixes).
- ice: fix VLAN replay after reset (git-fixes).
- ice: disallow DPLL_PIN_STATE_SELECTABLE for dpll output pins
  (git-fixes).
- ice: clear port vlan config during reset (git-fixes).
- ice: set correct dst VSI in only LAN filters (git-fixes).
- net/mlx5: Added cond_resched() to crdump collection (git-fixes).
- vduse: avoid using __GFP_NOFAIL (git-fixes).
- igb: Always call igb_xdp_ring_update_tail() under Tx lock
  (git-fixes).
- ice: fix VSI lists confusion when adding VLANs (git-fixes).
- ice: fix accounting for filters shared by multiple VSIs
  (git-fixes).
- ice: Fix lldp packets dropping after changing the number of
  channels (git-fixes).
- net/mlx5: Add missing masks and QoS bit masks for scheduling
  elements (git-fixes).
- net/mlx5: Explicitly set scheduling element and TSAR type
  (git-fixes).
- net/mlx5e: Add missing link mode to ptys2ext_ethtool_map
  (git-fixes).
- net/mlx5e: Add missing link modes to ptys2ethtool_map
  (git-fixes).
- net/mlx5: Update the list of the PCI supported devices
  (git-fixes).
- ice: do not bring the VSI up, if it was down before the XDP
  setup (git-fixes).
- igc: Unlock on error in igc_io_resume() (git-fixes).
- igb: Fix not clearing TimeSync interrupts for 82580 (git-fixes).
- ice: fix truesize operations for PAGE_SIZE &amp;gt;= 8192 (git-fixes).
- ice: fix ICE_LAST_OFFSET formula (git-fixes).
- ice: fix page reuse when PAGE_SIZE is over 8k (git-fixes).
- cxgb4: add forgotten u64 ivlan cast before shift (git-fixes).
- igc: Fix qbv tx latency by setting gtxoffset (git-fixes).
- igc: Fix reset adapter logics when tx mode change (git-fixes).
- igc: Fix qbv_config_change_errors logics (git-fixes).
- igc: Fix packet still tx after gate close by reducing i226
  MAC retry buffer (git-fixes).
- net/mlx5e: Correctly report errors for ethtool rx flows
  (git-fixes).
- ice: Fix reset handler (git-fixes).
- idpf: fix UAFs when destroying the queues (git-fixes).
- idpf: fix memleak in vport interrupt configuration (git-fixes).
- idpf: fix memory leaks and crashes while performing a soft reset
  (git-fixes).
- igc: Fix double reset adapter triggered from a single taprio
  cmd (git-fixes).
- net/mlx5e: Add a check for the return value from
  mlx5_port_set_eth_ptys (git-fixes).
- net/mlx5e: Require mlx5 tc classifier action support for IPsec
  prio capability (git-fixes).
- net/mlx5: Lag, don't use the hardcoded value of the first port
  (git-fixes).
- net/mlx5: Fix error handling in irq_pool_request_irq
  (git-fixes).
- ice: add missing WRITE_ONCE when clearing ice_rx_ring::xdp_prog
  (git-fixes).
- ice: replace synchronize_rcu with synchronize_net (git-fixes).
- ice: don't busy wait for Rx queue disable in ice_qp_dis()
  (git-fixes).
- ice: respect netif readiness in AF_XDP ZC related ndo's
  (git-fixes).
- gve: Fix an edge case for TSO skb validity check (git-fixes).
- ice: Fix recipe read procedure (git-fixes).
- gve: Fix XDP TX completion handling when counters overflow
  (git-fixes).
- RDMA/mlx5: Use sq timestamp as QP timestamp when RoCE is
  disabled (git-fixes).
- idpf: avoid bloating &amp;amp;idpf_q_vector with big %NR_CPUS
  (git-fixes).
- i40e: Fix XDP program unloading while removing the driver
  (git-fixes).
- ice: use proper macro for testing bit (git-fixes).
- ice: Reject pin requests with unsupported flags (git-fixes).
- e1000e: Fix S0ix residency on corporate systems (git-fixes).
- net/mlx5e: Add mqprio_rl cleanup and free in
  mlx5e_priv_cleanup() (git-fixes).
- ice: Rebuild TC queues on VSI queue reconfiguration (git-fixes).
- bnxt_en: Restore PTP tx_avail count in case of skb_pad() error
  (git-fixes).
- ice: Fix VSI list rule with ICE_SW_LKUP_LAST type (git-fixes).
- ice: implement AQ download pkg retry (git-fixes).
- ice: fix 200G link speed message log (git-fixes).
- ice: avoid IRQ collision to fix init failure on ACPI S3 resume
  (git-fixes).
- bnxt_en: Cap the size of HWRM_PORT_PHY_QCFG forwarded response
  (git-fixes).
- gve: ignore nonrelevant GSO type bits when processing TSO
  headers (git-fixes).
- net/mlx5e: Fix features validation check for tunneled UDP
  (non-VXLAN) packets (git-fixes).
- ice: add flag to distinguish reset from .ndo_bpf in XDP rings
  config (git-fixes).
- ice: remove af_xdp_zc_qps bitmap (git-fixes).
- ice: fix reads from NVM Shadow RAM on E830 and E825-C devices
  (git-fixes).
- ice: fix iteration of TLVs in Preserved Fields Area (git-fixes).
- net/mlx5: Stop waiting for PCI if pci channel is offline
  (git-fixes).
- ice: fix 200G PHY types to link speed mapping (git-fixes).
- e1000e: move force SMBUS near the end of enable_ulp function
  (git-fixes).
- ice: fix accounting if a VLAN already exists (git-fixes).
- idpf: don't enable NAPI and interrupts prior to allocating Rx
  buffers (git-fixes).
- net/mlx5e: Fix UDP GSO for encapsulated packets (git-fixes).
- net/mlx5e: Use rx_missed_errors instead of rx_dropped for
  reporting buffer exhaustion (git-fixes).
- net/mlx5e: Fix IPsec tunnel mode offload feature check
  (git-fixes).
- net/mlx5: Lag, do bond only if slaves agree on roce state
  (git-fixes).
- idpf: Interpret .set_channels() input differently (git-fixes).
- ice: Interpret .set_channels() input differently (git-fixes).
- idpf: don't skip over ethtool tcp-data-split setting
  (git-fixes).
- ice: Fix package download algorithm (git-fixes).
- mlx5: stop warning for 64KB pages (git-fixes).
- mlx5: avoid truncating error message (git-fixes).
- qed: avoid truncating work queue length (git-fixes).
- cxgb4: unnecessary check for 0 in the free_sge_txq_uld()
  function (git-fixes).
- cxgb4: Properly lock TX queue for the selftest (git-fixes).
- net: qede: use return from qede_parse_actions() (git-fixes).
- net: qede: use return from qede_parse_flow_attr() for flow_spec
  (git-fixes).
- net: qede: use return from qede_parse_flow_attr() for flower
  (git-fixes).
- net: qede: sanitize 'rc' in qede_add_tc_flower_fltr()
  (git-fixes).
- iavf: Fix TC config comparison with existing adapter TC config
  (git-fixes).
- i40e: Report MFS in decimal base instead of hex (git-fixes).
- eth: bnxt: fix counting packets discarded due to OOM and netpoll
  (git-fixes).
- bnxt_en: Fix error recovery for 5760X (P7) chips (git-fixes).
- bnxt_en: Fix the PCI-AER routines (git-fixes).
- bnxt_en: refactor reset close code (git-fixes).
- ice: Fix checking for unsupported keys on non-tunnel device
  (git-fixes).
- ice: tc: allow zero flags in parsing tc flower (git-fixes).
- ice: tc: check src_vsi in case of traffic from VF (git-fixes).
- vdpa: Fix an error handling path in eni_vdpa_probe()
  (git-fixes).
- vdpa_sim_blk: allocate the buffer zeroed (git-fixes).
- vdpa_sim_blk: Fix the potential leak of mgmt_dev (git-fixes).
- commit 58c03fe

- dcache: keep dentry_hashtable or d_hash_shift even when not used (git-fixes).
- commit d6ce9b3

- x86: fix user address masking non-canonical speculation issue (git-fixes).
- commit 561e50e

- x86: make the masked_user_access_begin() macro use its argument only  once (git-fixes).
- commit aa2495e

- x86: do the user address masking outside the user access area (git-fixes).
- commit a4b9c7b

- x86: support user address masking instead of non-speculative conditional (git-fixes).
- commit 6536d1f

- runtime constants: add x86 architecture support (git-fixes).
- commit 32e2def

- runtime constants: add default dummy infrastructure (git-fixes).
- commit dd17ee6

- vfs: dcache: move hashlen_hash() from callers into d_hash() (git-fixes).
- commit c440ebe

- hv_netvsc: Fix VF namespace also in synthetic NIC NETDEV_REGISTER event (git-fixes).
- commit 3dc5225

- Drop USB dwc2 patch that caused a regression on RPi3 (bsc#1232342)
- commit c84227d

- ACPI: PRM: Clean up guid type in struct prm_handler_info
  (git-fixes).
- commit 8c8a801

- ALSA: hda/realtek: Add subwoofer quirk for Acer Predator G9-593
  (stable-fixes).
- commit 595e400

- ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and
  context (git-fixes).
- ata: libata: Set DID_TIME_OUT for commands that actually timed
  out (git-fixes).
- ASoC: max98388: Fix missing increment of variable slot_found
  (git-fixes).
- ASoC: qcom: Fix NULL Dereference in
  asoc_qcom_lpass_cpu_platform_probe() (git-fixes).
- ALSA: hda/realtek: Update default depop procedure (git-fixes).
- ALSA: hda/tas2781: select CRC32 instead of CRC32_SARWATE
  (git-fixes).
- ALSA: firewire-lib: Avoid division by zero in
  apply_constraint_to_size() (git-fixes).
- cpufreq/amd-pstate: Fix amd_pstate mode switch on shared memory
  systems (git-fixes).
- ntb: intel: Fix the NULL vs IS_ERR() bug for
  debugfs_create_dir() (git-fixes).
- commit 33d7ff7

- platform/x86: x86-android-tablets: Fix use after free on
  platform_device_register() errors (bsc#1232093 CVE-2024-49986).
- commit a5650bf

- thermal: core: Free tzp copy along with the thermal zone
  (bsc#1231951 CVE-2024-50027).
- commit 5199a1f

- device-dax: correct pgoff align in dax_set_mapping()
  (bsc#1231956 CVE-2024-50022).
- commit 527a95e

- ntb: ntb_hw_switchtec: Fix use after free vulnerability in
  switchtec_ntb_remove due to race condition (CVE-2024-50059
  bsc#1232345).
- commit 4d86c47

- mm: call the security_mmap_file() LSM hook in remap_file_pages()
  (CVE-2024-47745 bsc#1232135).
- commit 18a36ea

- Bluetooth: L2CAP: Fix uaf in l2cap_connect (CVE-2024-49950
  bsc#1232159).
- commit c906740

- rxrpc: Fix a race between socket set up and I/O thread creation
  (CVE-2024-49864 bsc#1232256).
- commit 9a8fa8a

- jfs: Fix sanity check in dbMount (git-fixes).
- commit 82a9085

- net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc()
  (CVE-2024-50000 bsc#1232085).
- commit fe8d0fb

- ext4: fix double brelse() the buffer of the extents path
  (bsc#1232200 CVE-2024-49882).
- ext4: no need to continue when the number of entries is 1
  (bsc#1232140 CVE-2024-49967).
- commit 4a7f79c

- nvme: disable CC.CRIME (NVME_CC_CRIME) (jsc#PED-9901).
- commit e02c81e

- ice: Fix improper handling of refcount in
  ice_sriov_set_msix_vec_count() (CVE-2024-50020 bsc#1231989).
- Refresh patches.suse/ice-Fix-increasing-MSI-X-on-VF.patch.
- commit 879bb19

- igb: Do not bring the device up after non-fatal error
  (CVE-2024-50040 bsc#1231908).
- ice: Fix improper handling of refcount in
  ice_dpll_init_rclk_pins() (CVE-2024-50021 bsc#1231957).
- ppp: do not assume bh is held in ppp_channel_bridge_input()
  (CVE-2024-49946 bsc#1232164).
- net/mlx5e: Fix crash caused by calling __xfrm_state_delete()
  twice (CVE-2024-49953 bsc#1232156).
- net/mlx5: Fix error path in multi-packet WQE transmit
  (CVE-2024-50001 bsc#1232084).
- net: seeq: Fix use after free vulnerability in ether3 Driver
  Due to Race Condition (CVE-2024-47747 bsc#1232145).
- vdpa/mlx5: Fix invalid mr resource destroy (CVE-2024-47687
  bsc#1232003).
- Revert &amp;quot;ixgbe: Manual AN-37 for troublesome link partners for
  X550 SFI&amp;quot; (git-fixes).
- commit bf0d04c

- net: usb: usbnet: fix name regression (get-fixes).
- commit 05e3778

- r8169: add tally counter fields added with RTL8125 (CVE-2024-49973 bsc#1232105)
- commit bda1225

- crypto: hisilicon/qm - flush all work before driver removed (bsc#1232075)
- commit fe52020

- crypto: hisilicon/qm - inject error before stopping queue (CVE-2024-47730 bsc#1232075)
- commit 2ca1dd9

- sock_map: Add a cond_resched() in sock_hash_free() (CVE-2024-47710 bsc#1232049)
- commit 0ac9917

- cifs: Fix buffer overflow when parsing NFS reparse points
  (bsc#1232089, CVE-2024-49996).
- commit f42a100

- netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() (CVE-2024-47685 bsc#1231998)
- commit 8da2621

- net: Fix an unsafe loop on the list (CVE-2024-50024 bsc#1231954)
- commit 89e6925

- ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() (CVE-2024-47707 bsc#1231935)
- commit cc8f915

- netfilter: br_netfilter: fix panic with metadata_dst skb (CVE-2024-50045 bsc#1231903)
- commit e6591d1

- block, bfq: fix possible UAF for bfqq-&amp;gt;bic with merge chain (CVE-2024-47706 bsc#1231942)
- commit 5c1066e

- tcp: check skb is non-NULL in tcp_rto_delta_us() (CVE-2024-47684 bsc#1231987)
- commit e27a5c2

- add bug references to existing mana changes (bsc#1232033, bsc#1232034, bsc#1232036).
- commit e93ce92

- filemap: remove use of wait bookmarks  (bsc#1224088).
- commit 323bb54

- config: Disable LAM on x86 (bsc#1217845)
  LAM is affected by speculative execution vulnerabilities so until LASS
  lands it's advisable to be disabled.
- commit 405fa97

- selftests/bpf: adjust global_func15 test to validate prog exit
  precision (CVE-2024-47703 bsc#1231946).
- selftests/bpf: validate async callback return value check
  correctness (CVE-2024-47703 bsc#1231946).
- bpf: enforce precision of R0 on program/async callback return
  (CVE-2024-47703 bsc#1231946).
- bpf: unify async callback and program retval checks
  (CVE-2024-47703 bsc#1231946).
- commit d5ff894

- bpf: enforce precise retval range on program exit
  (CVE-2024-47703 bsc#1231946).
- selftests/bpf: add selftest validating callback result is
  enforced (CVE-2024-47703 bsc#1231946).
- bpf: enforce exact retval range on subprog/callback exit
  (CVE-2024-47703 bsc#1231946).
- Refresh patches.kabi/bpf-verifier-kABI-workarounds.patch
- bpf: provide correct register name for exception callback
  retval check (CVE-2024-47703 bsc#1231946).
- bpf: rearrange bpf_func_state fields to save a bit of memory
  (CVE-2024-47703 bsc#1231946).
- Refresh patches.suse/bpf-Add-some-comments-to-stack-representation.patch
- Refresh patches.kabi/bpf-verifier-kABI-workarounds.patch
- bpf: Treat first argument as return value for bpf_throw
  (CVE-2024-47703 bsc#1231946).
- commit 5efe683

- drm/amd/display: Add null check for head_pipe in
  dcn32_acquire_idle_pipe_for_head_pipe_in_layer (CVE-2024-49918
  bsc#1231967).
- commit 0e6515f

- drm/amd/display: Add NULL check for clk_mgr and clk_mgr-&amp;gt;funcs
  in dcn30_init_hw (bsc#1231965 CVE-2024-49917).
- commit 0859f94

- ocfs2: reserve space for inline xattr before attaching reflink
  tree (bsc#1232151 CVE-2024-49958).
- commit 9d01096

- arm64: probes: Fix uprobes for big-endian kernels (git-fixes)
- commit 5114e0b

- arm64: probes: Fix simulate_ldr*_literal() (git-fixes)
- commit 2795830

- arm64: probes: Remove broken LDR (literal) uprobe support (git-fixes)
- commit 83d2001

- spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware (CVE-2024-47664 bsc#1231442)
- commit 89945c9

- arm64: Subscribe Microsoft Azure Cobalt 100 to erratum 3194386 (git-fixes)
- commit ad9716f

- arm64: errata: Expand speculative SSBS workaround once more (git-fixes)
- commit f66e878

- arm64: cputype: Add Neoverse-N3 definitions (git-fixes)
- commit 6a20007

- arm64: esr: Define ESR_ELx_EC_* constants as UL (git-fixes)
- commit 28e8491

- printk: Add notation to console_srcu locking (bsc#1232183).
- commit b5edcce

- Update patches.suse/kthread-unpark-only-parked-kthread.patch
  (git-fixes, bsc#1231990, CVE-2024-50019).
- commit 1ac001a

- x86/bugs: Do not use UNTRAIN_RET with IBPB on entry (git-fixes).
- commit 9059d40

- x86/bugs: Skip RSB fill at VMEXIT (git-fixes).
- commit 1c2e2e9

- supported.conf: mark ultravisor userspace access as supported (bsc#1232090)
  This is needed for secure execution attestations feature.
- commit 9d4c7ad

- x86/entry: Have entry_ibpb() invalidate return predictions (git-fixes).
- commit 8e4a09c

- x86/cpufeatures: Add a IBPB_NO_RET BUG flag (git-fixes).
- commit 4411a53

- x86/cpufeatures: Define X86_FEATURE_AMD_IBPB_RET (git-fixes).
- commit 589671a

- x86/tdx: Fix &amp;quot;in-kernel MMIO&amp;quot; check (bsc#1232116 CVE-2024-47727).
- commit 9b65946

- selftests/bpf: Add test for sign extension in
  coerce_subreg_to_size_sx() (git-fixes).
- selftests/bpf: Add test for truncation after sign extension
  in coerce_reg_to_size_sx() (git-fixes).
- bpf: Fix truncation bug in coerce_reg_to_size_sx() (git-fixes).
- selftests/bpf: Add test for sign extension in
  coerce_subreg_to_size_sx() (git-fixes).
- selftests/bpf: Add test for truncation after sign extension
  in coerce_reg_to_size_sx() (git-fixes).
- bpf: Fix truncation bug in coerce_reg_to_size_sx() (git-fixes).
- commit 34bee66

- xfs: fix freeing speculative preallocations for preallocated
  files (git-fixes).
- commit 80e4f70

- selftests/bpf: Add test for lsm tail call (CVE-2024-50063).
- commit 810e00e

- xfs: make sure sb_fdblocks is non-negative (git-fixes).
- commit 258a678

- xfs: remove a racy if_bytes check in xfs_reflink_end_cow_extent
  (git-fixes).
- commit 4ab4091

- xfs: convert delayed extents to unwritten when zeroing post
  eof blocks (git-fixes).
- commit 6f12db2

- xfs: make xfs_bmapi_convert_delalloc() to allocate the target
  offset (git-fixes).
- commit 9f0f731

- xfs: make the seq argument to xfs_bmapi_convert_delalloc()
  optional (git-fixes).
- commit 504e0bc

- xfs: validate recovered name buffers when recovering xattr items
  (git-fixes).
- commit a53fc5e

- xfs: check shortform attr entry flags specifically (git-fixes).
- commit 621ec11

- kABI: bpf: struct bpf_map kABI workaround (CVE-2024-50063).
- bpf: Prevent tail call between progs attached to different hooks
  (CVE-2024-50063).
- commit cef79ef

- xfs: check opcode and iovec count match in
  xlog_recover_attri_commit_pass2 (git-fixes).
- commit 2398ba4

- fat: fix uninitialized variable (git-fixes).
- commit 77f5dad

- drm/amd/display: Add null check for head_pipe in
  dcn201_acquire_free_pipe_for_layer (CVE-2024-49919 bsc#1231968).
- commit ff31b31

- slip: make slhc_remember() more robust against malicious packets
  (CVE-2024-50033 bsc#1231914).
- i40e: Fix macvlan leak by synchronizing access to
  mac_filter_hash (CVE-2024-50041 bsc#1231907).
- ice: Fix increasing MSI-X on VF (CVE-2024-50042 bsc#1231906).
- commit a1fb8a8

- pinctrl: ocelot: fix system hang on level based interrupts
  (stable-fixes).
- tty: n_gsm: Fix use-after-free in gsm_cleanup_mux
  (stable-fixes).
- USB: serial: option: add Telit FN920C04 MBIM compositions
  (stable-fixes).
- USB: serial: option: add support for Quectel EG916Q-GL
  (stable-fixes).
- drm/vmwgfx: Handle surface check failure correctly (git-fixes).
- drm/amdgpu/swsmu: Only force workload setup on init (git-fixes).
- drm/radeon: Fix encoder-&amp;gt;possible_clones (git-fixes).
- commit 4fdf5d1

- thermal: core: Reference count the zone in
  thermal_zone_get_by_id() (CVE-2024-50028 bsc#1231950).
- commit a5813a1

- bpf: Fix a sdiv overflow issue (CVE-2024-49888 bsc#1232208).
- commit ce8f994

- kabi fix for NFSv4: Prevent NULL-pointer dereference in
  nfs42_complete_copies() (bsc#1231902 CVE-2024-50046).
- NFSv4: Prevent NULL-pointer dereference in
  nfs42_complete_copies() (bsc#1231902 CVE-2024-50046).
- commit e5e1a89

- zram: don't free statically defined names (CVE-2024-50064
  bsc#1231901).
- commit 645eb93

- zram: free secondary algorithms names (CVE-2024-50064
  bsc#1231901).
- commit 293822f

- block: fix potential invalid pointer dereference in
  blk_add_partition (bsc#1231872 CVE-2024-47705).
- block: print symbolic error name instead of error code
  (bsc#1231872).
- commit fcde2ed

- nfsd: return -EINVAL when namelen is 0 (CVE-2024-47692
  bsc#1231857).
- commit 9ee6831

- PCI: Fix pci_enable_acs() support for the ACS quirks (bsc#1229019).
- commit 1bd1860

- nilfs2: fix kernel bug due to missing clearing of buffer delay
  flag (git-fixes).
- commit 472d949

- Update
  patches.suse/xen-move-max_pfn-in-xen_memory_setup-out-of-function.patch
  (bsc#1226003 bsc#1231828).
- commit ec3e6a6

- x86/sev: Check for MWAITX and MONITORX opcodes in the #VC handler (git-fixes).
- commit 23789e3

- x86/apic: Make x2apic_disable() work correctly (git-fixes).
- commit 546101e

- x86/entry: Remove unwanted instrumentation in common_interrupt() (git-fixes).
- commit 846156b

- x86/mm: Use IPIs to synchronize LAM enablement (git-fixes).
- commit 8a7a0be

- x86/amd_nb: Add new PCI IDs for AMD family 1Ah model 60h (git-fixes).
- commit 60a5f34

- x86/PCI: Check pcie_find_root_port() return for NULL (git-fixes).
- commit 7c1cc11

- maple_tree: correct tree corruption on spanning store
  (git-fixes).
- commit 2b034f1

- x86/resctrl: Avoid overflow in MB settings in bw_validate() (git-fixes).
- commit b2f0d6d

- x86/resctrl: Annotate get_mem_config() functions as __init (git-fixes).
- commit 7e80f38

- x86/apic: Always explicitly disarm TSC-deadline timer (git-fixes).
- commit 312d3e7

- x86/CPU/AMD: Only apply Zenbleed fix for Zen2 during late microcode  load (git-fixes).
- commit 0cb125d

- ethtool: fail closed if we can't get max channel used in
  indirection tables (CVE-2024-46834 bsc#1231096).
- commit 5cacc93

- Bluetooth: btusb: Fix regression with fake CSR controllers
  0a12:0001 (git-fixes).
- Bluetooth: bnep: fix wild-memory-access in proto_unregister
  (git-fixes).
- Bluetooth: Remove debugfs directory on module init failure
  (git-fixes).
- Bluetooth: Call iso_exit() on module unload (git-fixes).
- Bluetooth: ISO: Fix multiple init when debugfs is disabled
  (git-fixes).
- pinctrl: apple: check devm_kasprintf() returned value
  (git-fixes).
- parport: Proper fix for array out-of-bounds access (git-fixes).
- iio: frequency: admv4420: fix missing select REMAP_SPI in
  Kconfig (git-fixes).
- iio: adc: ti-ads8688: add missing select IIO_(TRIGGERED_)BUFFER
  in Kconfig (git-fixes).
- iio: hid-sensors: Fix an error handling path in
  _hid_sensor_set_report_latency() (git-fixes).
- iio: dac: stm32-dac-core: add missing select REGMAP_MMIO in
  Kconfig (git-fixes).
- iio: dac: ltc1660: add missing select REGMAP_SPI in Kconfig
  (git-fixes).
- iio: dac: ad5770r: add missing select REGMAP_SPI in Kconfig
  (git-fixes).
- iio: amplifiers: ada4250: add missing select REGMAP_SPI in
  Kconfig (git-fixes).
- iio: frequency: adf4377: add missing select REMAP_SPI in Kconfig
  (git-fixes).
- iio: proximity: mb1232: add missing select
  IIO_(TRIGGERED_)BUFFER in Kconfig (git-fixes).
- iio: dac: ad5766: add missing select IIO_(TRIGGERED_)BUFFER
  in Kconfig (git-fixes).
- iio: dac: ad3552r: add missing select IIO_(TRIGGERED_)BUFFER
  in Kconfig (git-fixes).
- iio: adc: ti-lmp92064: add missing select REGMAP_SPI in Kconfig
  (git-fixes).
- iio: adc: ti-ads124s08: add missing select
  IIO_(TRIGGERED_)BUFFER in Kconfig (git-fixes).
- iio: accel: kx022a: add missing select IIO_(TRIGGERED_)BUFFER
  in Kconfig (git-fixes).
- iio: light: veml6030: fix ALS sensor resolution (git-fixes).
- iio: light: opt3001: add missing full-scale range value
  (git-fixes).
- iio: light: veml6030: fix IIO device retrieval from embedded
  device (git-fixes).
- iio: accel: bma400: Fix uninitialized variable field_value in
  tap event handling (git-fixes).
- serial: imx: Update mctrl old_status on RTSD interrupt
  (git-fixes).
- vt: prevent kernel-infoleak in con_font_get() (git-fixes).
- xhci: Mitigate failed set dequeue pointer commands (git-fixes).
- xhci: Fix incorrect stream context type macro (git-fixes).
- xhci: tegra: fix checked USB2 port number (git-fixes).
- usb: dwc3: Wait for EndXfer completion before restoring
  GUSB2PHYCFG (git-fixes).
- usb: typec: altmode should keep reference to parent (git-fixes).
- commit 5e08e81

- supported.conf: mark nhpoly1305 module as supported (bsc#1231035)
  In 59d03d7c990c, we marked adiantum as a supported module, I'm afraid
  we need to mark nhpoly1305 as supported too (as a dependecy) if we
  want adiantum to work.
  This makes tcrypt test case 219 (adiantum) pass on SLE15-SP6 (tested
  on z15 VM).
- commit 01d2906

- vmxnet3: Fix packet corruption in vmxnet3_xdp_xmit_frame
  (bsc#1226498).
- vmxnet3: Fix missing reserved tailroom (bsc#1226498).
- commit 1bd55aa

- vmxnet3: update to version 9 (bsc#1226498).
- vmxnet3: add command to allow disabling of offloads
  (bsc#1226498).
- vmxnet3: add latency measurement support in vmxnet3
  (bsc#1226498).
- vmxnet3: prepare for version 9 changes (bsc#1226498).
- vmxnet3: Add XDP support (bsc#1226498).
- commit 3fdc8e3

- SUNRPC: Fix integer overflow in decode_rc_list() (git-fixes).
- commit 15be003

- NFSD: Mark filecache &amp;quot;down&amp;quot; if init fails (git-fixes).
- commit ceca4b8

- SUNRPC: clnt.c: Remove misleading comment (git-fixes).
- commit 2e12710

- nfs: fix memory leak in error path of nfs4_do_reclaim
  (git-fixes).
- commit 1994ef6

- nfsd: fix delegation_blocked() to block correctly for at least
  30 seconds (git-fixes).
- commit f66078d

- nfsd: return -EINVAL when namelen is 0 (git-fixes).
- commit 1bc1c36

- nfsd: call cache_put if xdr_reserve_space returns NULL
  (git-fixes).
- commit 003f784

- nfsd: map the EBADMSG to nfserr_io to avoid warning (git-fixes).
- commit 5b8020a

- NFSD: Fix NFSv4's PUTPUBFH operation (git-fixes).
- commit 88290fb

- nfsd: fix refcount leak when file is unhashed after being found
  (git-fixes).
- commit 5a551a1

- nfsd: remove unneeded EEXIST error check in nfsd_do_file_acquire
  (git-fixes).
- commit 6d18e0e

- NFS: Avoid unnecessary rescanning of the per-server delegation
  list (git-fixes).
- commit e5841ef

- NFSv4: Fix clearing of layout segments in layoutreturn
  (git-fixes).
- commit ec4c812

- ALSA: hda/conexant - Use cached pin control for Node 0x1d on
  HP EliteOne 1000 G2 (git-fixes).
- ALSA/hda: intel-sdw-acpi: simplify sdw-master-count property
  read (stable-fixes).
- ALSA/hda: intel-sdw-acpi: fetch fwnode once in
  sdw_intel_scan_controller() (stable-fixes).
- ALSA/hda: intel-sdw-acpi: cleanup sdw_intel_scan_controller
  (stable-fixes).
- ALSA: hda/tas2781: Add new quirk for Lenovo, ASUS, Dell projects
  (stable-fixes).
- ALSA: line6: update contact information (stable-fixes).
- ALSA: hda/conexant - Fix audio routing for HP EliteOne 1000 G2
  (stable-fixes).
- ALSA: hda: Sound support for HP Spectre x360 16 inch model 2024
  (stable-fixes).
- commit fb6c2ec

- firmware: arm_scmi: Fix the double free in
  scmi_debugfs_common_setup() (git-fixes).
- ALSA: hda/cs8409: Fix possible NULL dereference (git-fixes).
- netdevsim: use cond_resched() in nsim_dev_trap_report_work()
  (git-fixes).
- macsec: don't increment counters for an unrelated SA
  (git-fixes).
- net: usb: usbnet: fix race in probe failure (git-fixes).
- HID: plantronics: Workaround for an unexcepted opposite volume
  key (stable-fixes).
- usb: xhci: Fix problem with xhci resume from suspend
  (stable-fixes).
- usb: storage: ignore bogus device raised by JieLi BR21 USB
  sound chip (stable-fixes).
- net: phy: Remove LED entry from LEDs list on unregister
  (git-fixes).
- net: phy: bcm84881: Fix some error handling paths (git-fixes).
- net: phy: dp83869: fix memory corruption when enabling fiber
  (git-fixes).
- kthread: unpark only parked kthread (git-fixes).
- unicode: Don't special case ignorable code points
  (stable-fixes).
- fbdev: sisfb: Fix strbuf array overflow (stable-fixes).
- fbcon: Fix a NULL pointer dereference issue in fbcon_putcs
  (stable-fixes).
- drm/amd/display: Check null pointer before dereferencing se
  (stable-fixes).
- driver core: bus: Fix double free in driver API bus_register()
  (stable-fixes).
- driver core: bus: Return -EIO instead of 0 when show/store
  invalid bus attribute (stable-fixes).
- comedi: ni_routing: tools: Check when the file could not be
  opened (stable-fixes).
- serial: protect uart_port_dtr_rts() in uart_shutdown() too
  (stable-fixes).
- usb: dwc2: Adjust the timing of USB Driver Interrupt
  Registration in the Crashkernel Scenario (stable-fixes).
- usb: chipidea: udc: enable suspend interrupt after usb reset
  (stable-fixes).
- i3c: master: cdns: Fix use after free vulnerability in
  cdns_i3c_master Driver Due to Race Condition (stable-fixes).
- media: videobuf2-core: clear memory related fields in
  __vb2_plane_dmabuf_put() (stable-fixes).
- clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D
  (stable-fixes).
- clk: bcm: bcm53573: fix OF node leak in init (stable-fixes).
- i2c: i801: Use a different adapter-name for IDF adapters
  (stable-fixes).
- mfd: intel_soc_pmic_chtwc: Make Lenovo Yoga Tab 3 X90F DMI
  match less strict (stable-fixes).
- soundwire: intel_bus_common: enable interrupts before exiting
  reset (stable-fixes).
- PCI: Mark Creative Labs EMU20k2 INTx masking as broken
  (stable-fixes).
- PCI: Add ACS quirk for Qualcomm SA8775P (stable-fixes).
- PCI: Add function 0 DMA alias quirk for Glenfly Arise chip
  (stable-fixes).
- drm/amd/display: Revert &amp;quot;Check HDCP returned status&amp;quot;
  (stable-fixes).
- HID: multitouch: Add support for lenovo Y9000P Touchpad
  (stable-fixes).
- drm/amd/display: Remove a redundant check in authenticated_dp
  (stable-fixes).
- HID: i2c-hid: Remove I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV quirk
  (stable-fixes).
- commit f829d20

- RDMA/mlx5: Enforce umem boundaries for explicit ODP page faults (git-fixes)
- commit b9b835e

- RDMA/rtrs-srv: Avoid null pointer deref during path establishment (git-fixes)
- commit cf9eccb

- RDMA/mad: Improve handling of timed out WRs of mad agent (git-fixes)
- commit 72bef76

- io_uring/sqpoll: do not put cpumask on stack (git-fixes).
- io_uring/sqpoll: retain test for whether the CPU is valid
  (git-fixes).
- commit ff84c2d

- mm: avoid leaving partial pfn mappings around in error case
  (CVE-2024-47674 bsc#1231673).
- commit 83d1625

- RDMA/bnxt_re: Avoid CPU lockups due fifo occupancy check loop (git-fixes)
- commit 21fb93d

- RDMA/bnxt_re: Fix the GID table length (git-fixes)
- commit 6a0779e

- RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages (git-fixes)
- commit d91ede3

- RDMA/bnxt_re: Change the sequence of updating the CQ toggle value (git-fixes)
- commit 414cbde

- RDMA/bnxt_re: Return more meaningful error (git-fixes)
- commit 6755798

- RDMA/bnxt_re: Fix incorrect dereference of srq in async event (git-fixes)
- commit 4e1ef61

- RDMA/bnxt_re: Fix out of bound check (git-fixes)
- commit d8d1339

- RDMA/bnxt_re: Fix the max CQ WQEs for older adapters (git-fixes)
- commit 598626b

- RDMA/srpt: Make slab cache names unique (git-fixes)
- commit 29c0fcb

- RDMA/irdma: Fix misspelling of &amp;quot;accept*&amp;quot; (git-fixes)
- commit 2566da7

- RDMA/cxgb4: Fix RDMA_CM_EVENT_UNREACHABLE error for iWARP (git-fixes)
- commit 89fa27f

- RDMA/core: Fix ENODEV error for iWARP test over vlan (git-fixes)
- commit 4c15511

- RDMA/bnxt_re: Add a check for memory allocation (git-fixes)
- commit abea295

- RDMA/bnxt_re: Fix incorrect AVID type in WQE structure (git-fixes)
- commit ae91db1

- RDMA/bnxt_re: Fix a possible memory leak (git-fixes)
- commit 77c3f34

- io_uring/rw: fix cflags posting for single issue multishot read
  (git-fixes).
- commit 320c7ee

- io_uring/net: harden multishot termination case for recv
  (git-fixes).
- commit 6529e65

- io_uring: check for presence of task_work rather than
  TIF_NOTIFY_SIGNAL (git-fixes).
- commit 5b92400

- io_uring/io-wq: inherit cpuset of cgroup in io worker
  (git-fixes).
- commit 474a07e

- io_uring/io-wq: do not allow pinning outside of cpuset
  (git-fixes).
- commit e99d8a8

- io_uring/rw: treat -EOPNOTSUPP for IOCB_NOWAIT like -EAGAIN
  (git-fixes).
- io_uring/sqpoll: do not allow pinning outside of cpuset
  (git-fixes).
- commit 37d0dce

- io_uring/eventfd: move to more idiomatic RCU free usage
  (git-fixes).
- commit 4e262c3

- udf: Avoid excessive partition lengths (bsc#1230773
  CVE-2024-46777).
- commit ec61258

- fsnotify: clear PARENT_WATCHED flags lazily (bsc#1231439
  CVE-2024-47660).
- commit 133a7e9

- netem: fix return value if duplicate enqueue fails
  (CVE-2024-45016 bsc#1230429).
- commit 8c9c269

- media: pci: ipu3-cio2: Initialise timing struct to avoid a
  compiler warning (git-fixes).
- commit c21df3e

- wifi: rtw88: Fix USB/SDIO devices not transmitting beacons
  (git-fixes).
- commit d46bb93

- crypto: powerpc/p10-aes-gcm - Add dependency on CRYPTO_SIMD and
  re-enable CRYPTO_AES_GCM_P10 (bsc#1230501 ltc#208632).
  - Update config files.
- crypto: powerpc/p10-aes-gcm - Register modules as SIMD
  (bsc#1230501 ltc#208632).
- crypto: powerpc/p10-aes-gcm - Re-write AES/GCM stitched
  implementation (bsc#1230501 ltc#208632).
- crypto: powerpc/p10-aes-gcm - Disable CRYPTO_AES_GCM_P10
  (bsc#1230501 ltc#208632).
- powerpc/crypto: don't build aes-gcm-p10 by default (bsc#1230501
  ltc#208632).
- powerpc/crypto: fix missing skcipher dependency for aes-gcm-p10
  (bsc#1230501 ltc#208632).
- commit a579f42

- powercap: intel_rapl: Fix off by one in get_rpi() (git-fixes).
- commit 6c73c0c

- drm/amd/display: Disable DMCUB timeout for DCN35 (bsc#1231435 CVE-2024-46870)
- commit 0a39326

- drm/amd/display: Add disable timeout option (bsc#1231435)
- commit cb303b5

- Refresh patches.suse/paddings-add-paddings-to-TypeC-stuff.patch
  Drop superfluous file mode modifications in the patch that broke the
  patch expansion recently
- commit e7ac9e1

- Move upstreamed scsi patch into sorted section
- commit 5db43b0

- nbd: fix race between timeout and normal completion
  (bsc#1230918).
- commit 57c54c8

- ext4: mark fc as ineligible using an handle in ext4_xattr_set()
  (bsc#1231640).
- ext4: use handle to mark fc as ineligible in
  __track_dentry_update() (bsc#1231639).
- jbd2: correctly compare tids with tid_geq function in
  jbd2_fc_begin_commit (bsc#1231638).
- ext4: fix incorrect tid assumption in ext4_fc_mark_ineligible()
  (bsc#1231637).
- ext4: fix fast commit inode enqueueing during a full journal
  commit (bsc#1231636).
- ext4: don't track ranges in fast_commit if inode has inlined
  data (bsc#1231635).
- ext4: fix possible tid_t sequence overflows (bsc#1231634).
- commit 6951914

- net: sysfs: Fix /sys/class/net/&amp;lt;iface&amp;gt; path for statistics
  (git-fixes).
- commit 54925d7

- devlink: Fix command annotation documentation (git-fixes).
- commit 2b95827

- x86/Documentation: Indent 'note::' directive for protocol
  version number note (git-fixes).
- commit ec31602

- mm/filemap: optimize filemap folio adding (bsc#1231617).
- lib/xarray: introduce a new helper xas_get_order (bsc#1231617).
- mm/filemap: return early if failed to allocate memory for split
  (bsc#1231617).
- commit c3c5888

- srcu: Fix callbacks acceleration mishandling (git-fixes).
- task_work: add kerneldoc annotation for 'data' argument
  (git-fixes).
- commit a4661ee

- HID: amd_sfh: Switch to device-managed dmam_alloc_coherent()
  (git-fixes).
- hid: intel-ish-hid: Fix uninitialized variable 'rv' in
  ish_fw_xfer_direct_dma (git-fixes).
- usb: dwc3: core: Stop processing of pending events if controller
  is halted (git-fixes).
- usb: gadget: core: force synchronous registration (git-fixes).
- commit 2bb6fd5

- hwmon: (adt7470) Add missing dependency on REGMAP_I2C
  (git-fixes).
- hwmon: (adm9240) Add missing dependency on REGMAP_I2C
  (git-fixes).
- hwmon: (mc34vr500) Add missing dependency on REGMAP_I2C
  (git-fixes).
- hwmon: (tmp513) Add missing dependency on REGMAP_I2C
  (git-fixes).
- hwmon: intel-m10-bmc-hwmon: relabel Columbiaville to CVL Die
  Temperature (git-fixes).
- commit 07e1f67

- gpio: aspeed: Use devm_clk api to manage clock source
  (git-fixes).
- gpio: aspeed: Add the flush write to ensure the write complete
  (git-fixes).
- ata: libata: avoid superfluous disk spin down + spin up during
  hibernation (git-fixes).
- nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy
  error (git-fixes).
- nouveau/dmem: Fix privileged error in copy engine channel
  (git-fixes).
- drm/vc4: Stop the active perfmon before being destroyed
  (git-fixes).
- drm/v3d: Stop the active perfmon before being destroyed
  (git-fixes).
- drm/i915/hdcp: fix connector refcounting (git-fixes).
- commit 8534efe

- kABI: bpf: struct bpf_insn_acces_aux kABI workaround (git-fixes).
- commit c2cff36

- Update patches.suse/ASoC-meson-axg-card-fix-use-after-free.patch
  (git-fixes CVE-2024-46849 bsc#1231073).
- Update
  patches.suse/KVM-x86-Acquire-kvm-srcu-when-handling-KVM_SET_VCPU_.patch
  (git-fixes CVE-2024-46830 bsc#1231116).
- Update
  patches.suse/PCI-keystone-Add-workaround-for-Errata-i2037-AM65x-S.patch
  (stable-fixes CVE-2024-47667 bsc#1231481).
- Update patches.suse/USB-usbtmc-prevent-kernel-usb-infoleak.patch
  (git-fixes CVE-2024-47671 bsc#1231541).
- Update patches.suse/arm64-tlb-Fix-TLBI-RANGE-operand.patch
  (bsc#1229585 CVE-2024-35980 bsc#1224574).
- Update
  patches.suse/dma-buf-heaps-Fix-off-by-one-in-CMA-heap-fault-handl.patch
  (git-fixes CVE-2024-46852 bsc#1231082).
- Update
  patches.suse/drm-amd-amdgpu-Check-tbo-resource-pointer.patch
  (stable-fixes CVE-2024-46807 bsc#1231138).
- Update
  patches.suse/drm-amd-display-Add-array-index-check-for-hdcp-ddc-a.patch
  (stable-fixes CVE-2024-46804 bsc#1231132).
- Update
  patches.suse/drm-amd-display-Avoid-overflow-from-uint32_t-to-uint.patch
  (stable-fixes CVE-2024-47661 bsc#1231496).
- Update
  patches.suse/drm-amd-display-Avoid-race-between-dcn10_set_drr-and.patch
  (git-fixes CVE-2024-46851 bsc#1231081).
- Update
  patches.suse/drm-amd-display-Check-BIOS-images-before-it-is-used.patch
  (stable-fixes CVE-2024-46809 bsc#1231148).
- Update
  patches.suse/drm-amd-display-Check-gpio_id-before-used-as-array-i.patch
  (stable-fixes CVE-2024-46818 bsc#1231203).
- Update
  patches.suse/drm-amd-display-Check-msg_id-before-processing-trans.patch
  (stable-fixes CVE-2024-46814 bsc#1231193).
- Update
  patches.suse/drm-amd-display-Check-num_valid_sets-before-accessin.patch
  (stable-fixes CVE-2024-46815 bsc#1231195).
- Update
  patches.suse/drm-amd-display-Correct-the-defined-value-for-AMDGPU.patch
  (stable-fixes CVE-2024-46871 bsc#1231434).
- Update
  patches.suse/drm-amd-display-Fix-index-may-exceed-array-range-wit.patch
  (stable-fixes CVE-2024-46811 bsc#1231179).
- Update
  patches.suse/drm-amd-display-Remove-register-from-DCN35-DMCUB-dia.patch
  (stable-fixes CVE-2024-47662 bsc#1231440).
- Update
  patches.suse/drm-amd-display-Skip-inactive-planes-within-ModeSupp.patch
  (stable-fixes CVE-2024-46812 bsc#1231187).
- Update
  patches.suse/drm-amd-display-Stop-amdgpu_dm-initialize-when-strea.patch
  (stable-fixes CVE-2024-46817 bsc#1231200).
- Update
  patches.suse/drm-amd-display-added-NULL-check-at-start-of-dc_vali.patch
  (stable-fixes CVE-2024-46802 bsc#1231111).
- Update
  patches.suse/drm-amd-pm-Fix-negative-array-index-read.patch
  (stable-fixes CVE-2024-46821 bsc#1231169).
- Update
  patches.suse/drm-amdgpu-Fix-smatch-static-checker-warning.patch
  (stable-fixes CVE-2024-46835 bsc#1231098).
- Update
  patches.suse/drm-amdgpu-Fix-the-warning-division-or-modulo-by-zer.patch
  (stable-fixes CVE-2024-46806 bsc#1231136).
- Update
  patches.suse/drm-amdgpu-fix-the-waring-dereferencing-hive.patch
  (stable-fixes CVE-2024-46805 bsc#1231135).
- Update
  patches.suse/drm-amdgpu-the-warning-dereferencing-obj-for-nbio_v7.patch
  (stable-fixes CVE-2024-46819 bsc#1231202).
- Update
  patches.suse/drm-amdkfd-Check-debug-trap-enable-before-write-dbg_.patch
  (stable-fixes CVE-2024-46803 bsc#1231131).
- Update
  patches.suse/drm-bridge-tc358767-Check-if-fully-initialized-befor.patch
  (stable-fixes CVE-2024-46810 bsc#1231178).
- Update
  patches.suse/i3c-mipi-i3c-hci-Error-out-instead-on-BUG_ON-in-IBI-.patch
  (stable-fixes CVE-2024-47665 bsc#1231452).
- Update
  patches.suse/lib-generic-radix-tree.c-Fix-rare-race-in-__genradix.patch
  (stable-fixes CVE-2024-47668 bsc#1231502).
- Update
  patches.suse/msft-hv-3054-x86-hyperv-fix-kexec-crash-due-to-VP-assist-page-cor.patch
  (git-fixes CVE-2024-46864 bsc#1231108).
- Update
  patches.suse/nilfs2-fix-state-management-in-error-path-of-log-writing-function.patch
  (git-fixes CVE-2024-47669 bsc#1231474).
- Update
  patches.suse/ocfs2-add-bounds-checking-to-ocfs2_xattr_find_entry.patch
  (bsc#1228410 CVE-2024-41016 CVE-2024-47670 bsc#1231537).
- Update
  patches.suse/perf-x86-intel-Limit-the-period-on-Haswell.patch
  (git-fixes CVE-2024-46848 bsc#1231072).
- Update
  patches.suse/platform-x86-panasonic-laptop-Fix-SINF-array-out-of-.patch
  (git-fixes CVE-2024-46859 bsc#1231089).
- Update
  patches.suse/rcu-Fix-buffer-overflow-in-print_cpu_stall_info.patch
  (bsc#1226623 CVE-2024-38576).
- Update
  patches.suse/rcu-tasks-Fix-show_rcu_tasks_trace_gp_kthread-buffer-overflow.patch
  (bsc#1226631 CVE-2024-38577).
- Update
  patches.suse/scsi-lpfc-Handle-mailbox-timeouts-in-lpfc_get_sfp_in.patch
  (bsc#1228857 CVE-2024-46842 bsc#1231101).
- Update
  patches.suse/spi-nxp-fspi-fix-the-KASAN-report-out-of-bounds-bug.patch
  (git-fixes CVE-2024-46853 bsc#1231083).
- Update
  patches.suse/spi-rockchip-Resolve-unbalanced-runtime-PM-system-PM.patch
  (git-fixes CVE-2024-46846 bsc#1231075).
- Update
  patches.suse/staging-iio-frequency-ad9834-Validate-frequency-para.patch
  (git-fixes CVE-2024-47663 bsc#1231441).
- Update
  patches.suse/usb-gadget-aspeed_udc-validate-endpoint-index-for-as.patch
  (stable-fixes CVE-2024-46836 bsc#1231092).
- Update
  patches.suse/usbnet-ipheth-do-not-stop-RX-on-failing-RX-callback.patch
  (git-fixes CVE-2024-46861 bsc#1231102).
- Update
  patches.suse/wifi-ath12k-fix-firmware-crash-due-to-invalid-peer-n.patch
  (stable-fixes CVE-2024-46827 bsc#1231171).
- Update
  patches.suse/wifi-iwlwifi-mvm-don-t-wait-for-tx-queues-if-firmwar.patch
  (stable-fixes CVE-2024-47672 bsc#1231540).
- Update
  patches.suse/wifi-iwlwifi-mvm-pause-TCM-when-the-firmware-is-stop.patch
  (stable-fixes CVE-2024-47673 bsc#1231539).
- Update
  patches.suse/wifi-iwlwifi-mvm-use-IWL_FW_CHECK-for-link-ID-check.patch
  (stable-fixes CVE-2024-46825 bsc#1231170).
- Update
  patches.suse/wifi-mt76-mt7921-fix-NULL-pointer-access-in-mt7921_i.patch
  (stable-fixes CVE-2024-46860 bsc#1231093).
- commit 1ed6329

- sched/smt: Fix unbalance sched_smt_present dec/inc
  (CVE-2024-44958 bsc#1230179).
- sched/smt: Introduce sched_smt_present_inc/dec() helper
  (CVE-2024-44958 bsc#1230179).
- commit b09820b

- crypto: octeontx* - Select CRYPTO_AUTHENC (git-fixes).
- commit 155c418

- spi: spi-imx: Fix pm_runtime_set_suspended() with runtime pm
  enabled (git-fixes).
- spi: s3c64xx: fix timeout counters in flush_fifo (git-fixes).
- i2c: synquacer: Deal with optional PCLK correctly (git-fixes).
- media: imx335: Fix reset-gpio handling (git-fixes).
- i2c: xiic: Try re-initialization on bus busy timeout
  (git-fixes).
- platform/x86: touchscreen_dmi: add nanote-next quirk
  (stable-fixes).
- platform/x86: lenovo-ymc: Ignore the 0x0 state (stable-fixes).
- hwmon: (nct6775) add G15CF to ASUS WMI monitoring list
  (stable-fixes).
- power: reset: brcmstb: Do not go into infinite loop if reset
  fails (stable-fixes).
- wifi: ath9k_htc: Use __skb_set_length() for resetting urb
  before resubmit (stable-fixes).
- wifi: mt76: mt7915: hold dev-&amp;gt;mt76.mutex while disabling tx
  worker (stable-fixes).
- wifi: mt76: mt7915: add dummy HW offload of IEEE 802.11
  fragmentation (stable-fixes).
- wifi: mt76: mt7915: disable tx worker during tx BA session
  enable/disable (stable-fixes).
- wifi: rtw89: avoid reading out of bounds when loading TX power
  FW elements (stable-fixes).
- wifi: rtw89: correct base HT rate mask for firmware
  (stable-fixes).
- wifi: mwifiex: Fix memcpy() field-spanning write warning in
  mwifiex_cmd_802_11_scan_ext() (stable-fixes).
- wifi: cfg80211: Set correct chandef when starting CAC
  (stable-fixes).
- wifi: mac80211: fix RCU list iterations (stable-fixes).
- wifi: iwlwifi: mvm: avoid NULL pointer dereference
  (stable-fixes).
- wifi: iwlwifi: allow only CN mcc from WRDD (stable-fixes).
- wifi: iwlwifi: mvm: drop wrong STA selection in TX
  (stable-fixes).
- wifi: iwlwifi: mvm: Fix a race in scan abort flow
  (stable-fixes).
- wifi: iwlwifi: mvm: use correct key iteration (stable-fixes).
- wifi: ath9k: fix possible integer overflow in
  ath9k_get_et_stats() (stable-fixes).
- wifi: ath11k: fix array out-of-bound access in SoC stats
  (stable-fixes).
- wifi: ath12k: fix array out-of-bound access in SoC stats
  (stable-fixes).
- wifi: rtw89: avoid to add interface to list twice when SER
  (stable-fixes).
- wifi: rtw88: select WANT_DEV_COREDUMP (stable-fixes).
- i2c: xiic: improve error message when transfer fails to start
  (stable-fixes).
- i2c: synquacer: Remove a clk reference from struct synquacer_i2c
  (stable-fixes).
- media: i2c: imx335: Enable regulator supplies (stable-fixes).
- commit 490fb1f

- ALSA: usb-audio: Replace complex quirk lines with macros
  (stable-fixes).
- commit 6f67136

- Bluetooth: RFCOMM: FIX possible deadlock in
  rfcomm_sk_state_change (git-fixes).
- ACPI: battery: Fix possible crash when unregistering a battery
  hook (git-fixes).
- ACPI: battery: Simplify battery hook locking (stable-fixes).
- ACPI: resource: Add Asus ExpertBook B2502CVA to
  irq1_level_low_skip_override[] (stable-fixes).
- ACPI: resource: Add Asus Vivobook X1704VAP to
  irq1_level_low_skip_override[] (stable-fixes).
- HID: Ignore battery for all ELAN I2C-HID devices (stable-fixes).
- HID: multitouch: Add support for Thinkpad X12 Gen 2 Kbd
  Portfolio (stable-fixes).
- ASoC: codecs: wsa883x: Handle reading version failure
  (stable-fixes).
- ALSA: usb-audio: Add logitech Audio profile quirk
  (stable-fixes).
- ALSA: usb-audio: Define macros for quirk table entries
  (stable-fixes).
- ALSA: hdsp: Break infinite MIDI input flush loop (stable-fixes).
- ALSA: asihpi: Fix potential OOB array access (stable-fixes).
- ALSA: usb-audio: Add input value sanity checks for standard
  types (stable-fixes).
- ACPI: PAD: fix crash in exit_round_robin() (stable-fixes).
- ACPI: video: Add force_vendor quirk for Panasonic Toughbook
  CF-18 (stable-fixes).
- ACPI: CPPC: Add support for setting EPP register in FFH
  (stable-fixes).
- ACPI: EC: Do not release locks during operation region accesses
  (stable-fixes).
- ACPICA: iasl: handle empty connection_node (stable-fixes).
- ACPICA: Fix memory leak if acpi_ps_get_next_field() fails
  (stable-fixes).
- ACPICA: Fix memory leak if acpi_ps_get_next_namepath() fails
  (stable-fixes).
- ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in
  acpi_db_convert_to_package() (stable-fixes).
- crypto: octeontx2 - Fix authenc setkey (stable-fixes).
- crypto: octeontx - Fix authenc setkey (stable-fixes).
- Bluetooth: btusb: Add Realtek RTL8852C support ID 0x0489:0xe122
  (stable-fixes).
- can: netlink: avoid call to do_set_data_bittiming callback
  with stale can_priv::ctrlmode (stable-fixes).
- commit 650f32e

- ocfs2: fix the la space leak when unmounting an ocfs2 volume
  (git-fixes).
- commit 92d1b30

- jfs: Fix uninit-value access of new_ea in ea_buffer (git-fixes).
- commit b1e0ef1

- jfs: check if leafidx greater than num leaves per dmap tree
  (git-fixes).
- commit 4cb79e7

- jfs: Fix uaf in dbFreeBits (git-fixes).
- commit da4aab1

- jfs: UBSAN: shift-out-of-bounds in dbFindBits (git-fixes).
- commit fee8a70

- kABI: bpf: enum bpf_{type_flag,arg_type} kABI workaround (git-fixes).
- commit 93e6047

- iommu/amd: Allocate the page table root using GFP_KERNEL
  (git-fixes).
- commit cdbbb3f

- iommu/amd: Fix typo of , instead of ; (git-fixes).
- commit baf85d0

- block: sed-opal: add ioctl IOC_OPAL_SET_SID_PW (bsc#1229677).
- commit 5ca02dc

- nvme-multipath: suppress partition scan until the disk is ready
  (bsc#1228244).
- commit 5accc60

- fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE
  (CVE-2024-45025 bsc#1230456).
- commit c3824ef

- i2c: core: Setup i2c_adapter runtime-pm before calling
  device_add() (git-fixes).
- commit 5095dfb

- i2c: ismt: kill transaction in hardware on timeout (git-fixes).
- commit f6029bb

- iommufd: Check the domain owner of the parent before creating
  a nesting domain (git-fixes).
- commit 3ff7340

- iommufd: Protect against overflow of ALIGN() during iova
  allocation (git-fixes).
- commit fffeb67

- iommu/amd: Do not set the D bit on AMD v2 table entries
  (git-fixes).
- commit e3053a9

- i2c: omap: wakeup the controller during suspend() callback
  (git-fixes).
- commit 52f3dad

- i2c: omap: switch to NOIRQ_SYSTEM_SLEEP_PM_OPS() and
  RUNTIME_PM_OPS() (git-fixes).
- commit 3fe2f94

- Drop the previous HD-audio TAS2781 fix (bsc#1230132)
  The proposed fix turned out to be incorrect
- commit b3a4c29

- Update config files: Enable NFSD_V2 (bsc#1230914)
  NFSv2 was disabled because of the upstream kernel commit 2f3a4b2ac2f2
  (&amp;quot;nfsd: allow disabling NFSv2 at compile time&amp;quot;).
  Enable it for the few users who cannot upgrade to NFSv3.
  https://bugzilla.suse.com/show_bug.cgi?id=1230914#c5
- commit 9e3254d

- i2c: stm32f7: perform most of irq job in threaded handler
  (git-fixes).
- commit 4a35980

- i2c: i801: Add lis3lv02d for Dell XPS 15 7590 (git-fixes).
- commit 38f58af

- i2c: i801: Add lis3lv02d for Dell Precision 3540 (git-fixes).
- commit 036aff9

- i2c: cpm: Remove linux,i2c-index conversion from be32
  (git-fixes).
- commit 5d04b4e

- i2c: ocores: Move system PM hooks to the NOIRQ phase
  (git-fixes).
- commit 0df7a53

- i2c: ocores: Remove #ifdef guards for PM related functions
  (git-fixes).
- commit ead06ad

- wifi: iwlwifi: config: label 'gl' devices as discrete
  (git-fixes).
- commit 6321867

- kconfig: qconf: fix buffer overflow in debug links (git-fixes).
- platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug
  (git-fixes).
- i2c: stm32f7: Do not prepare/unprepare clock during runtime
  suspend/resume (git-fixes).
- gpio: davinci: fix lazy disable (git-fixes).
- drm/i915/gem: fix bitwise and logical AND mixup (git-fixes).
- drm/sched: Always wake up correct scheduler in
  drm_sched_entity_push_job (git-fixes).
- drm/sched: Add locking to drm_sched_entity_modify_sched
  (git-fixes).
- drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS
  (git-fixes).
- Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE
  (git-fixes).
- Bluetooth: btmrvl: Use IRQF_NO_AUTOEN flag in request_irq()
  (git-fixes).
- ieee802154: Fix build error (git-fixes).
- Input: adp5589-keys - fix adp5589_gpio_get_value() (git-fixes).
- Input: adp5589-keys - fix NULL pointer dereference (git-fixes).
- drm/amdgpu/vcn: enable AV1 on both instances (stable-fixes).
- drm/amd/display: Validate backlight caps are sane
  (stable-fixes).
- drm/amd/display: Skip to enable dsc if it has been off
  (stable-fixes).
- drm/amd/display: Add HDMI DSC native YCbCr422 support
  (stable-fixes).
- drm/amd/display: Clean up dsc blocks in accelerated mode
  (stable-fixes).
- drm/amd/display: Round calculated vtotal (stable-fixes).
- efistub/tpm: Use ACPI reclaim memory for event log to avoid
  corruption (stable-fixes).
- iio: magnetometer: ak8975: drop incorrect AK09116 compatible
  (git-fixes).
- Input: i8042 - add TUXEDO Stellaris 15 Slim Gen6 AMD to i8042
  quirk table (stable-fixes).
- Input: i8042 - add another board name for TUXEDO Stellaris
  Gen5 AMD line (stable-fixes).
- Input: i8042 - add TUXEDO Stellaris 16 Gen5 AMD to i8042 quirk
  table (stable-fixes).
- hwmon: (max16065) Fix alarm attributes (git-fixes).
- ACPI: resource: Add another DMI match for the TongFang GMxXGxx
  (stable-fixes).
- wifi: rtw88: 8821cu: Remove VID/PID 0bda:c82c (stable-fixes).
- ASoC: tas2781: Use of_property_read_reg() (stable-fixes).
- wifi: iwlwifi: remove AX101, AX201 and AX203 support from LNL
  (stable-fixes).
- hwmon: (max16065) Remove use of i2c_match_id() (stable-fixes).
- nouveau/gsp: Avoid addressing beyond end of rpc-&amp;gt;entries
  (stable-fixes).
- thunderbolt: Improve DisplayPort tunnel setup process to be
  more robust (stable-fixes).
- iio: magnetometer: ak8975: Fix 'Unexpected device' error
  (git-fixes).
- iio: magnetometer: ak8975: Convert enum-&amp;gt;pointer for data in
  the match tables (stable-fixes).
- commit 85984c8

- i2c: core: fix lockdep warning for sparsely nested adapter chain
  (git-fixes).
- commit 691570d

- i2c: exynos5: Calculate t_scl_l, t_scl_h according to i2c spec
  (git-fixes).
- commit cbbb120

- i2c: i801: add helper i801_restore_regs (git-fixes).
- commit 3839f86

- i2c: rcar: properly format a debug output (git-fixes).
- commit e7085c8

- selftests/bpf: Add a test case to write mtu result into .rodata
  (git-fixes).
- selftests/bpf: Add a test case to write strtol result into
  .rodata (git-fixes).
- commit 805bbba

- selftests/bpf: Rename ARG_PTR_TO_LONG test description
  (git-fixes).
- selftests/bpf: Fix ARG_PTR_TO_LONG {half-,}uninitialized test
  (git-fixes).
- bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error
  (git-fixes).
- bpf: Improve check_raw_mode_ok test for MEM_UNINIT-tagged types
  (git-fixes).
- commit 4580630

- bpf: Fix helper writes to read-only maps (git-fixes).
- bpf: Remove truncation test in bpf_strtol and bpf_strtoul
  helpers (git-fixes).
- bpf: Fix bpf_strtol and bpf_strtoul helpers for 32bit
  (git-fixes).
- commit 5fc2ffd

- bpf: Remove tst_run from lwt_seg6local_prog_ops (bsc#1230801
  CVE-2024-46754).
- commit a7335b8

- bpf: Fix error message on kfunc arg type mismatch (git-fixes).
- commit 04ed437

- selftests/bpf: test for malformed BPF_CORE_TYPE_ID_LOCAL
  relocation (git-fixes).
- bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos
  (git-fixes).
- commit 67ebe66

- selftests/bpf: Add tests for ldsx of pkt data/data_end/data_meta
  accesses (git-fixes).
- bpf: Fail verification for sign-extension of packet
  data/data_end/data_meta (git-fixes).
- bpf, lsm: Add disabled BPF LSM hook list (git-fixes).
- commit df1486e

- bpf, net: Fix a potential race in do_sock_getsockopt()
  (git-fixes).
- bpf: Fix tailcall cases in test_bpf (git-fixes).
- bpf, x64: Remove tail call detection (git-fixes).
- bpf, verifier: Correct tail_call_reachable for bpf prog
  (git-fixes).
- commit e072387

- add bug reference for a mana change (bsc#1229769).
- commit 64c619e

- net/sched: taprio: extend minimum interval restriction to entire cycle too (CVE-2024-36244 bsc#1226797)
- commit 5ade9d6

- arm64: fix selection of HAVE_DYNAMIC_FTRACE_WITH_ARGS
  (git-fixes).
- commit 7e90455

- arm64: errata: Enable the AC03_CPU_38 workaround for ampere1a
  (git-fixes).
- commit 994f16f

- aoe: fix the potential use-after-free problem in more places
  (bsc#1218562 CVE-2023-6270).
- commit 1a991ba

- ALSA: hda: tas2781: Fix missing setup at runtime PM
  (bsc#1230132).
- commit 3dc7842

- Move upstreamed sound patch into sorted section
- commit b11079c

- kbuild,bpf: Add module-specific pahole flags for distilled
  base BTF (bsc#1230414 bsc#1229450).
- kbuild: bpf: Tell pahole to DECL_TAG kfuncs (bsc#1230414
  bsc#1229450).
- kbuild, bpf: Use test-ge check for v1.25-only pahole
  (bsc#1230414 bsc#1229450).
- kbuild,bpf: Switch to using --btf_features for pahole v1.26
  and later (bsc#1230414 bsc#1229450).
- kbuild: avoid too many execution of scripts/pahole-flags.sh
  (bsc#1230414 bsc#1229450).
- btf, scripts: rust: drop is_rust_module.sh (bsc#1230414
  bsc#1229450).
- commit e2cacce

- Use pahole -j1 option for reproducible builds (bsc#1230414
  bsc#1229450).
- commit 340585e

- ceph: fix cap ref leak via netfs init_request (bsc#1231384).
- commit ca24d43

- vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()
  (git-fixes).
- commit 267df6b

- virtio_console: fix misc probe bugs (git-fixes).
- commit f7d3065

- RDMA/mana_ib: use the correct page size for mapping user-mode
  doorbell page (git-fixes).
- RDMA/mana_ib: use the correct page table index based on hardware
  page size (git-fixes).
- tools: hv: rm .*.cmd when make clean (git-fixes).
- x86/hyperv: Set X86_FEATURE_TSC_KNOWN_FREQ when Hyper-V provides
  frequency (git-fixes).
- commit 059fd95

- KVM: VMX: Set PFERR_GUEST_{FINAL,PAGE}_MASK if and only if
  the GVA is valid (git-fixes).
- commit bb6f3d3

- KVM: x86/mmu: Skip emulation on page fault iff 1+ SPs were
  unprotected (git-fixes).
- commit bcfafe2

- KVM: x86/mmu: Trigger unprotect logic only on write-protection
  page faults (git-fixes).
- commit 322cf36

- KVM: VMX: Also clear SGX EDECCSSA in KVM CPU caps when SGX is
  disabled (git-fixes).
- commit d7b7771

- btrfs: send: fix invalid clone operation for file that got
  its size decreased (git-fixes).
- commit 26ee3ac

- KVM: x86: Exit to userspace if fastpath triggers one on
  instruction skip (git-fixes).
- commit 1621f7b

- KVM: x86: Dedup fastpath MSR post-handling logic (git-fixes).
- commit c20ff7c

- KVM: x86: Re-enter guest if WRMSR(X2APIC_ICR) fastpath is
  successful (git-fixes).
- commit 0dc4c78

- kABI fix of VM: x86: Re-split x2APIC ICR into ICR+ICR2 for AMD
  (x2AVIC) (git-fixes).
- commit 0a6716e

- KVM: x86: Re-split x2APIC ICR into ICR+ICR2 for AMD (x2AVIC)
  (git-fixes).
- commit 6a07b23

- KVM: x86: Move x2APIC ICR helper above kvm_apic_write_nodecode()
  (git-fixes).
- commit 4f194f7

- USB: misc: yurex: fix race between read and write (git-fixes).
- commit 7f6ab55

- USB: misc: cypress_cy7c63: check for short transfer (git-fixes).
- commit 3dcfad1

- USB: appledisplay: close race between probe and completion
  handler (git-fixes).
- commit 888718f

- KVM: x86: Enforce x2APIC's must-be-zero reserved ICR bits
  (git-fixes).
- commit 891c3ef

- usb: xhci: fix loss of data on Cadence xHC (git-fixes).
- commit 9e9d585

- KVM: Write the per-page &amp;quot;segment&amp;quot; when clearing (part of)
  a guest page (git-fixes).
- commit dae8f10

- xhci: Add a quirk for writing ERST in high-low order
  (git-fixes).
- commit d0eccfc

- drm/amd/display: Validate function returns (bsc#1230774 CVE-2024-46775)
- commit fc9ad2b

- KVM: Fix coalesced_mmio_has_room() to avoid premature userspace
  exit (git-fixes).
- commit 93dbc58

- KVM: Use dedicated mutex to protect kvm_usage_count to avoid
  deadlock (git-fixes).
- commit 2ff88a8

- Delete some more obsolete scripts
- commit 9bb77f8

- KVM: SVM: Disallow guest from changing userspace's
  MSR_AMD64_DE_CFG value (git-fixes).
- commit c8fa16d

- drm/amd/display: Stop amdgpu_dm initialize when link nums greater than max_links (CVE-2024-46816 bsc#1231197).
- commit c05e7e2

- net: test for not too small csum_start in
  virtio_net_hdr_to_skb() (git-fixes).
- commit ed78dff

- vhost_vdpa: assign irq bypass producer token correctly
  (git-fixes).
- commit 1a9cba6

- drm/amd/display: Check link_index before accessing dc-&amp;gt;links (CVE-2024-46813 bsc#1231191).
- commit eb31596

- minmax: avoid overly complex min()/max() macro arguments in xen
  (git-fixes).
- Refresh
  patches.suse/xen-move-max_pfn-in-xen_memory_setup-out-of-function.patch.
- commit 754808b

- ALSA: hda/conexant: Fix conflicting quirk for System76 Pangolin
  (git-fixes).
- ALSA: line6: add hw monitor volume control to POD HD500X
  (stable-fixes).
- ALSA: usb-audio: Add native DSD support for Luxman D-08u
  (stable-fixes).
- ALSA: core: add isascii() check to card ID generator
  (stable-fixes).
- ASoC: qcom: sm8250: add qrb4210-rb2-sndcard compatible string
  (stable-fixes).
- ASoC: imx-card: Set card.owner to avoid a warning calltrace
  if SND=m (git-fixes).
- ASoC: fsl_sai: Enable 'FIFO continue on error' FCONT bit
  (stable-fixes).
- ASoC: codecs: lpass-rx-macro: add missing
  CDC_RX_BCL_VBAT_RF_PROC2 to default regs values (stable-fixes).
- ASoC: atmel: mchp-pdmc: Skip ALSA restoration if substream
  runtime is uninitialized (git-fixes).
- ASoC: amd: yc: Add quirk for HP Dragonfly pro one
  (stable-fixes).
- Revert &amp;quot;ALSA: hda: Conditionally use snooping for AMD HDMI&amp;quot;
  (stable-fixes).
- ALSA: hda/realtek: Add a quirk for HP Pavilion 15z-ec200
  (stable-fixes).
- ALSA: silence integer wrapping warning (stable-fixes).
- ALSA: Reorganize kerneldoc parameter names (stable-fixes).
- ALSA: hda/realtek: Fix the push button function for the ALC257
  (git-fixes).
- ALSA: hda/conexant: fix some typos (stable-fixes).
- ALSA: mixer_oss: Remove some incorrect kfree_const() usages
  (git-fixes).
- ALSA: hda/realtek: Add quirk for Huawei MateBook 13 KLV-WX9
  (stable-fixes).
- ALSA: usb-audio: Add delay quirk for VIVO USB-C HEADSET
  (stable-fixes).
- ALSA: hda/tas2781: Add new quirk for Lenovo Y990 Laptop
  (stable-fixes).
- ALSA: hda/realtek: fix mute/micmute LED for HP mt645 G8
  (stable-fixes).
- commit 1cdc743

- rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow
  (bsc#1226631).
- commit 36faf07

- scsi: fnic: Move flush_work initialization out of if block
  (bsc#1230055).
- commit 9b5b899

- rcu: Fix buffer overflow in print_cpu_stall_info()
  (bsc#1226623).
- commit b695829

- Replace ALP with SLFO
- Refresh patches.suse/kernel-add-product-identifying-information-to-kernel-build.patch
- Update config files.
- commit 267a9d3

- rpm/release-projects: Add SLFO projects (bsc#1231293).
- commit 9f2c584

- Update patches.suse/powerpc-qspinlock-Fix-deadlock-in-MCS-queue.patch
  (bsc#1230295 ltc#206656 CVE-2024-46797 bsc#1230831).
- commit af09bb2

- KVM: s390: Fix SORTL and DFLTCC instruction format error in
  __insn32_query (git-fixes bsc#1231276).
- commit 39bab2d

- s390/mm: Add cond_resched() to cmm_alloc/free_pages()
  (bsc#1228747).
- commit d0c79ab

- ELF: fix kernel.randomize_va_space double read (CVE-2024-46826 bsc#1231115)
- commit 0519fb0

- net/mlx5: Fix bridge mode operations when there are no VFs (CVE-2024-46857 bsc#1231087)
- commit b20fc2c

- netfilter: nft_socket: fix sk refcount leaks (CVE-2024-46855 bsc#1231085)
- commit 6c66212

- net: microchip: vcap: Fix use-after-free error in kunit test
  (CVE-2024-46831 bsc#1231117).
- commit 630e2e8

- vmalloc: modify the alloc_vmap_area() error message for better
  diagnostics (jsc#PED-10978).
- mm: mmap: no need to call khugepaged_enter_vma() for stack
  (jsc#PED-10978).
- commit 41e1775

- nvme-pci: qdepth 1 quirk (git-fixes).
- commit ee2b909

- ALSA: hda/generic: Unconditionally prefer preferred_dacs pairs
  (bsc#1219803).
- commit 020b49a

- powerpc/code-patching: Add generic memory patching
  (bsc#1194869).
- powerpc/code-patching: Perform hwsync in __patch_instruction()
  in case of failure (bsc#1194869).
- commit 33b01a6

- usbnet: fix cyclical race on disconnect with work queue
  (git-fixes).
- Refresh
  patches.suse/0002-Add-a-void-suse_kabi_padding-placeholder-to-some-USB.patch.
- commit 8272f2d

- apparmor: fix possible NULL pointer dereference (CVE-2024-46721 bsc#1230710)
- commit 2d35a7c

- powerpc/64: Convert patch_instruction() to patch_u32()
  (bsc#1194869).
- powerpc/boot: Only free if realloc() succeeds (bsc#1194869).
- powerpc/boot: Handle allocation failure in simple_realloc()
  (bsc#1194869).
- powerpc/xics: Check return value of kasprintf in
  icp_native_map_one_cpu (bsc#1194869).
- powerpc/vdso: Fix VDSO data access when running in a non-root
  time namespace (bsc#1194869).
- commit 0dec2e8

- net: mana: Improve mana_set_channels() in low mem conditions
  (bsc#1230289).
- net: mana: Implement get_ringparam/set_ringparam for mana
  (bsc#1229891).
- net: dpaa: Pad packets to ETH_ZLEN (CVE-2024-46854 bsc#1231084).
- ice: move netif_queue_set_napi to rtnl-protected sections
  (CVE-2024-46766 bsc#1230762).
- ice: Add netif_device_attach/detach into PF reset flow
  (CVE-2024-46770 bsc#1230763).
- bonding: change ipsec_lock from spin lock to mutex
  (CVE-2024-46678 bsc#1230550).
- bonding: extract the use of real_device into local variable
  (CVE-2024-46678 bsc#1230550).
- bonding: implement xdo_dev_state_free and call it after deletion
  (CVE-2024-46678 bsc#1230550).
- commit 9ee67ad

- powerpc/xmon: Fix disassembly CPU feature checks (bsc#1065729).
- commit c675509

Package avahi was updated:

- Add avahi-CVE-2024-52616.patch:  Backporting 1dade81c from upstream: Properly randomize query id
  of DNS packets.
  (CVE-2024-52616, bsc#1233420)

Package expat was updated:

- security update- added patches
  fix CVE-2024-50602 [bsc#1232579], DoS via XML_ResumeParser
  + expat-CVE-2024-50602.patch

Package ldb was updated:

- Update to 2.8.2  * libldb: fix performance issue with indexes; (bso#15590).

Package nfs-utils was updated:

- nfsd: Revert &amp;quot;nfsd: Remove the ability to enable NFS v2.&amp;quot;  (bsc#1230914)
  - add 0005-Revert-nfsd-Remove-the-ability-to-enable-NFS-v2.patch
- mount.nfs: Revert &amp;quot;mount: Remove NFS v2 support from mount.nfs&amp;quot;
  (bsc#1230914)
  - add 0006-Revert-mount-Remove-NFS-v2-support-from-mount.nfs.patch

Package libnl3 was updated:

- Update to release 3.9  * route/link: add bonding interface options set rtnl apis
  * route: fix memleak in rtnl_act_parse()
  * route/tc: avoid integer overflow in rtnl_tc_calc_cell_log()

- Update to release 3.8
  * addr: create an all-zero addresses when parsing &amp;quot;any&amp;quot; or &amp;quot;default&amp;quot;
  * addr: allow constructing all-zero addresses
  * route: construct all-zero addresses for default route destination
  * bridge: Add support for link_info of a bridge
  * bridge: extend libnl with options needed for VLAN aware forwarding
  * route/link: add accessor API for IPv6 DEVCONF
  * neigh: add support of NHID attribute
  * route: add nh type

- Update to release 3.7
  * route/mdb: fix buffer overflow in mdb_msg_parser()
  * route/act: add NAT action

- Update to release 3.6.0
  * route/mdb: add support for MAC multicast entries
  * mdb: support bridge multicast database notification
  * Support Hardware offload capability for MACsec
  * nflog: add CT support
  * Add IPv6 GRE support
  * Add IPv6 VTI support
  * Add support for team devices
- Drop 0001-route-link-add-RTNL_LINK_REASM_OVERLAPS-stat.patch
  (merged)

- Add 0001-route-link-add-RTNL_LINK_REASM_OVERLAPS-stat.patch
  [boo#1189451]

- Modernize specfile constructs.

- Update to release 3.5.0
  * route/qdisc: add 64-bit rate/ceil support for htb class
  * xfrmi: introduce XFRM interfaces support
  * xfrm: fix memory corruption (dangling pointer) when when
    setting xfrmnl_sa
  * route/link: avoid dangling pointer in rtnl_link_set_slave_type()
  * nla_ok: fix overrun in attribute iteration.
  * route:act: add vlan action
  * route:tc: allow to set chain index for tc objects
  * route:qdisc: add MQPRIO Qdisc
  * if_tunnel: update IFLA defines up to FWMARK
  * Add support for cloning cgroup filter objects
  * neigh: cache updates as well query AF_BRIDGE neigh
  * route:cls: add matchall classifier
  * neigh: support bridge entries for vxlan interfaces
  * rule: add support for protocol and port ranges
  * link: add Geneve support

- Update to new upstream release 3.4.0 [boo#1082756]
  * route/link: add accessor API for IPv6 flags
  * Provide accessors for actions (rtnl_act).
  * rule: Add support for l3mdev in FIB rules
  * addr: add AF_VSOCK to translation table
  * addr: Add support for AF_MPLS
  * route: Add support for MPLS address family
  * route: Add support for TTL propagation in MPLS routes
  * route: Add support for lwtunnel and MPLS  encapsulations

Package libnvme was updated:

- Update to version 1.8+79.g69e7772:  * tree: optionally skip namespaces during scanning (bsc#1232616)
  * fabrics: do not attempt to import keys if tls is not enabled (bsc#1216982 bsc#1226216)
  * linux: do not do any keyring ops when no key is provided (bsc#1216982 bsc#1226216)
  * linux: do not return w/o OpenSSL support enabled (bsc#1216982 bsc#1226216)
  * linux: fix derive_psk_digest OpenSSL 1.1 version (bsc#1216982 bsc#1226216)
  * json: do not escape strings when printing the configuration (bsc#1216982 bsc#1226216)
  * tree: do no export tls keys when not provided by user (bsc#1216982 bsc#1226216)
  * linux: fixup PSK HMAC type '0' handling (bsc#1216982 bsc#1226216)
  * util: added error code for ENOKEY (bsc#1216982 bsc#1226216)
  * fabrics: fix map error level in __nvmf_add_ctrl (bsc#1216982 bsc#1226216)
  * fabrics: add ctrl connect interface (bsc#1216982 bsc#1226216)
  * fabrics: use hex numbers when generating command line options (bsc#1216982 bsc#1226216)
  * fabrics: rename first argument for argument macros (bsc#1216982 bsc#1226216)
  * linux: handle key import correctly (bsc#1216982 bsc#1226216)
  * linux: export keys to config (bsc#1216982 bsc#1226216)
  * tree: read tls_configured_key and tls_keyring from sysfs (bsc#1216982 bsc#1226216)
  * tree: move dhchap and tls sysfs parser into separate functions (bsc#1216982 bsc#1226216)
  * test: add pre-shared key json tests (bsc#1216982 bsc#1226216)
  * json: move keystore operations out of the JSON parser (bsc#1216982 bsc#1226216)
  * tree: add getter/setters for TLS PSK (bsc#1216982 bsc#1226216)
  * test: extend psk to test new 'versioned' API (bsc#1216982 bsc#1226216)
  * linux: add import/export function for TLS pre-shared keys (bsc#1216982 bsc#1226216)
  * test: add test case for importing/exporting PSKs (bsc#1216982 bsc#1226216)
  * test: make config-diff more flexible to use (bsc#1216982 bsc#1226216)
  * linux: only return the description of a key (bsc#1216982 bsc#1226216)
  * linux: use ssize_t as return type for nvme_identity_len (bsc#1216982 bsc#1226216)
  * linux: reorder variable declarations (bsc#1216982 bsc#1226216 (bsc#1216982 bsc#1226216)
  * util: Add string constant for ENVME_CONNECT_IGNORED
  * linux: Remove the use of OpenSSL Engine API

Package libproxy was updated:

- Add libproxy-handle-empty-proxy-ignore-entry.patch: Properly  handle empty proxy ignore entry (bsc#1234940).

- Add libproxy-ignore-invalid-uri.patch: Ignore invalid proxy URI
  to suppress GUri warnings (bsc#1235097).

Package python3 was updated:

- 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.

Package libsolv was updated:

- 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 &amp;quot;orderwithrequires&amp;quot; dependency
- bump version to 0.7.31

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

Package systemd was updated:

- Add 5004-udev-allow-denylist-for-reading-sysfs-attributes-whe.patch (bsc#1234015)  Temporarily add this patch. It will be integrated in the git repository if
  no issues are reported in the coming months.

- Import commit eddf52fb14391c30ee2f45fd0c3cab1be116c951
  807fe76411 udev: add new builtin net_driver
  3a48b5f21d udev-builtin-net_id: split-out pci_get_onboard_index() from dev_pci_onboard()
  5359c1d6d4 udev-builtin-net_id: split-out get_pci_slot_specifiers()
  1cd915ac7b udev-builtin-net_id: introduce get_port_specifier() helper function
  72a4218155 udev-builtin-net_id: split out get_dev_port() and make its failure critical
  f6c721b4da udev-builtin-net_id: split-out pci_get_hotplug_slot() and pci_get_hotplug_slot_from_address()
  9e16c3cf27 udev-builtin-net_id: return earlier when hotplug slot is not found
  4851355767 udev-builtin-net_id: skip non-directory entry earlier
  a571e5f1dd udev-builtin-net_id: make names_xen() self-contained
  9acc241d5f udev-builtin-net_id: use sd_device_get_sysnum() to get index of netdevsim
  ca8a431b55 udev-builtin-net_id: make names_netdevsim() self-contained
  a66251d666 udev-builtin-net_id: make names_platform() self-contained
  1e834d7157 udev-builtin-net_id: make names_vio() self-contained
  8b236dcd7a udev-builtin-net_id: make names_ccw() self-contained
  7d70e2fa7d udev-builtin-net_id: make dev_devicetree_onboard() self-contained
  46158a6e91 udev-builtin-net_id: make names_mac() self-contained
  7789e7f886 udev-builtin-net_id: split out get_ifname_prefix()
  9b0062a667 udev-builtin-net_id: swap arguments for streq() and friends
  181a775b40 udev-builtin-net_id: drop unused value from NetNameType
  Refactoring to prepare for backporting the filtering mechanism of specific
  sysfs attributes during predictable NIC name generation.

- Add 0003-Drop-support-for-efivar-SystemdOptions.patch (bsc#1220338)
  Upstream deprecated it and plan to drop it in the future.
  Let's get ahead and drop it now as this feature is unlikely to be used on SUSE
  distros and it might be used to gain access to encrypted SLEM systems with
  unattended disk unlock and with secure boot disabled.

- Import commit 600986ba4d9c562390d99513416f49a5be5559f3 (merge of v254.21)
  This merge includes the following fix:
    a467a411f pid1: make clear that $WATCHDOG_USEC is set for the shutdown binary, noone else (bsc#1232227)
  For a complete list of changes, visit:
  https://github.com/openSUSE/systemd/compare/f7f6a3454e3321f92cbdf8e30aeb8b17bc1ff8e8...600986ba4d9c562390d99513416f49a5be5559f3

- Import commit f7f6a3454e3321f92cbdf8e30aeb8b17bc1ff8e8 (merge of v254.20)
  This merge includes the following fix:
    8b6ae951d3 udev: skipping empty udev rules file while collecting the stats (bsc#1232844)
  For a complete list of changes, visit:
  https://github.com/openSUSE/systemd/compare/0cbb02c0273374b14188f30e89874c9e8ae425c9...f7f6a3454e3321f92cbdf8e30aeb8b17bc1ff8e8

- Import commit 0cbb02c0273374b14188f30e89874c9e8ae425c9 (merge of v254.19)
  For a complete list of changes, visit:
  https://github.com/openSUSE/systemd/compare/44943af96be1422c2d7bdf271e4a77b42f4b41ec...0cbb02c0273374b14188f30e89874c9e8ae425c9

- Clean up some remnants from when homed was in the experimental sub-package (bsc#1231048)

Package libuv was updated:

- Fixed CVE-2024-24806: libuv: Improper Domain Lookup that potentially  leads to SSRF attacks (bsc#1219724)
  Added:
  0001-fix-always-zero-terminate-idna-output.patch
  0002-fix-reject-zero-length-idna-inputs.patch
  0003-test-empty-strings-are-not-valid-IDNA.patch

Package libzypp was updated:

- Url: queryparams without value should not have a trailing &amp;quot;=&amp;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)

Package nvme-cli was updated:

- Update to version 2.8+87.g29df38e:  * netapp-smdev: add verbose output (bsc#1234217)
  * netapp-smdev-doc: add verbose details (bsc#1234217)
  * netapp-smdev: remove redundant code (bsc#1234217)
  * nvme-netapp: update err messages (bsc#1234217)
  * netapp-ontapdev: fix JSON output for nsze &amp;amp; nuse (bsc#1234217)
  * netapp-ontapdev: fix fw version handling (bsc#1234217)
  * fabrics: skip namespace scan for fabric commands (bsc#1232616)
  * netapp-ontapdev-doc: add verbose details (bsc#1232616)
  * netapp-ontapdev: add verbose output (bsc#1232616)
  * docs: update check-tls-key arguments (bsc#1216982 bsc#1226216)
  * nvme: add support to append TLS PSK to keyfile for check-tls-key (bsc#1216982 bsc#1226216)
  * nvme: return correct error code in append_keyfile (bsc#1216982 bsc#1226216)
  * docs: update gen-tls-key arguments (bsc#1216982 bsc#1226216)
  * nvme: add support to add derive TLS PSK to keyfile (bsc#1216982 bsc#1226216)
  * nvme: rename identity to version (bsc#1216982 bsc#1226216)
  * nvme: set file permission for keyfile to owner only (bsc#1216982 bsc#1226216)
  * nvme: export tls keys honoring version and hmac (bsc#1216982 bsc#1226216)
  * nvmf-keys: add udev rule to import tls keys (bsc#1216982 bsc#1226216)
  * docs: update TLS options (bsc#1216982 bsc#1226216)
  * fabrics: add support to connect to accept a PSK command line (bsc#1216982 bsc#1226216)
  * fabrics: add support to connect to accept a configuration (bsc#1216982 bsc#1226216)
  * nvme: use unsigned char for hmac and identity (bsc#1216982 bsc#1226216)

Package openssh was updated:

- Use %{with ...} instead of 0%{with ...}
- Add a patch to fix a regression introduced in 9.6 that makes X11
  forwarding very slow. Submitted to upstream in
  https://bugzilla.mindrot.org/show_bug.cgi?id=3655#c4 . Fixes
  bsc#1229449:
  * fix-x11-regression-bsc1229449.patch
- Add a openssl11 bcond to the spec file for the SLE12 case
  instead of checking suse_version in different parts.
- Move conditional patches to a number &amp;gt;= 1000.
- Several spec file fixes so the package builds and can be
  installed in SLE 15 SP5 and SLE 12 SP5
- Drop most of openssh-6.6p1-keycat.patch (actually, it was just
  commented out). The keycat binary isn't really installed nor
  supported, so we can drop it, except for the code that is used
  by other SELinux patches, which is what I kept from that patch
  (boo#1229072).
- Add patch submitted to upstream to fix RFC4256 implementation
  so that keyboard-interactive authentication method can send
  instructions and sshd shows them to users even before a prompt
  is requested. This fixes MFA push notifications (boo#1229010).
  * 0001-auth-pam-Immediately-report-instructions-to-clients-and-fix-handling-in-ssh-client.patch
- Fix a dbus connection leaked in the logind patch that was
  missing a sd_bus_unref call (found by Matthias Gerstner):
  * logind_set_tty.patch
- Add a patch that fixes a small memory leak when parsing the
  subsystem configuration option:
  * fix-memleak-in-process_server_config_line_depth.patch

Package patterns-base was updated:

- Updated patterns-base removing the plymouth recommendation only on s390x  * Our certification team run into an issue,(jsc#PED-10532)
    when they run bare metal installation with fully encrypted disk.
    If the whole disk is crypted,
    the prompt for the password is sent to plymouth,
    which is obviously showing nothing
    because for booting bare metal (LPAR) is used terminal in HMC.

Package permissions was updated:

- Update to version 20240826:  * chkstat: backport support to operate in insecure mode via envvar opt-in (bsc#1219736)

Package polkit-default-privs was updated:

- Update to version 13.2+20241216.68f9867:  * profiles: xfce4-power-manager (bsc#1232244)

Package python-Jinja2 was updated:

Package salt was updated:

- Fix failing x509 tests with OpenSSL &amp;lt; 1.1- Avoid explicit reading of /etc/salt/minion (bsc#1220357)
- Allow NamedLoaderContexts to be returned from loader
- Revert the change making reactor less blocking (bsc#1230322)
- Use --cachedir for extension_modules in salt-call (bsc#1226141)
- Prevent using SyncWrapper with no reason
- Fix the SELinux context for Salt Minion service (bsc#1219041)
- Set contextvars as a build requirement for package
- Increase warn_until_date date for code we still support
- The test_debian test now uses port 80 for ubuntu keyserver
- Fix too frequent systemd service restart in test_system test
- Avoid crash on wrong output of systemctl version (bsc#1229539)
- Improve error handling with different OpenSSL versions
- Remove redundant run_func from salt.master.MWorker._handle_aes
- Fix cloud minion configuration for multiple masters (bsc#1229109)
- Use Pygit2 id instead of deprecated oid in gitfs
- Fix few failing tests to work with both Salt and Salt bundle
- Skip testing unsupported OpenSSL crypto algorithms
- Added:
  * revert-the-change-making-reactor-less-blocking-bsc-1.patch
  * fix-x509-test-fails-on-old-openssl-systems-682.patch
  * prevent-using-syncwrapper-with-no-reason.patch
  * avoid-crash-on-wrong-output-of-systemctl-version-bsc.patch
  * allow-namedloadercontexts-to-be-returned-from-loader.patch
  * fix-deprecated-code-677.patch
  * fix-test_debian-to-work-in-our-infrastructure-676.patch
  * fix-the-selinux-context-for-salt-minion-service-bsc-.patch
  * use-cachedir-for-extension_modules-in-salt-call-bsc-.patch
  * fix-test_system-flaky-setup_teardown-fn.patch
  * join-masters-if-it-is-a-list-671.patch
  * replace-use-of-pygit2-deprecated-and-removed-1.15.0-.patch
  * remove-redundant-run_func-from-salt.master.mworker._.patch
  * make-tests-compatible-with-venv-bundle.patch
  * avoid-explicit-reading-of-etc-salt-minion-bsc-122035.patch
  * skip-more-tests-related-to-old-openssl-algorithms.patch
  * improve-error-handling-with-different-openssl-versio.patch

Package rsync was updated:

- Fix duplication of flag causing illegal hashkey failures.  * Added rsync-fix-duplicate.patch

- Security update,CVE-2024-12747, bsc#1235475 race condition in handling symbolic links
  * Added rsync-CVE-2024-12747.patch

- Security update, fix multiple vulnerabilities:
  * CVE-2024-12084, bsc#1234100 - Heap Buffer Overflow in Checksum Parsing
  * CVE-2024-12085, bsc#1234101 - Info Leak via uninitialized Stack contents defeats ASLR
  * CVE-2024-12086, bsc#1234102 - Server leaks arbitrary client files
  * CVE-2024-12087, bsc#1234103 - Server can make client write files outside of destination directory using symbolic links
  * CVE-2024-12088, bsc#1234104 - --safe-links Bypass
  * Added rsync-CVE-2024-12084-overflow-01.patch
  * Added rsync-CVE-2024-12084-overflow-02.patch
  * Added rsync-CVE-2024-12085.patch
  * Added rsync-CVE-2024-12086_01.patch
  * Added rsync-CVE-2024-12086_02.patch
  * Added rsync-CVE-2024-12086_03.patch
  * Added rsync-CVE-2024-12086_04.patch
  * Added rsync-CVE-2024-12087_01.patch
  * Added rsync-CVE-2024-12087_02.patch
  * Added rsync-CVE-2024-12088.patch

Package rubygem-nokogiri was updated:

- added only-complain-about-version-diff-if-it-is-older.patch:  make nokogiri only complain about mismatching libxml2 version
  if the runtime version is older than the build version as we
  assume newer versions should be ABI compatible (boo#1213999)

Package samba was updated:

- Update to 4.19.9  * libldb: performance issue with indexes (ldb 2.8.2 is already
    released); (bso#15590).
  * DH reconnect error handling can lead to stale sharemode
    entries; (bso#15624).
  * Incorrect FSCTL_QUERY_ALLOCATED_RANGES response when
    truncated; (bso#15699).
  * irpc_destructor may crash during shutdown; (bso#15280).
  * Compound SMB2 requests don't return
    NT_STATUS_NETWORK_SESSION_EXPIRED for all requests, confuses
    MacOSX clients; (bso#15696).
  * Crash when readlinkat fails; (bso#15700).

-  Adjust spec to split out rpcd_* binaries into a separate
  sub package; (bsc#1231414).

Package shared-mime-info was updated:

- Uninstall silently if update-mime-database is not present  (bsc#1231463).

Package vim was updated:

- Fix for bsc#1234333 / bsc#1234214 / bsc#1234245.  These three bugs all have the same root cause:
  Package 'xxd' has been obsoleted by Vim, as it provides the xxd
  files directly.
  However, because the &amp;quot;Obsoletes&amp;quot; entry was versioned, depending on
  which version of 'xxd' that is installed, the &amp;quot;Obsoletes&amp;quot; isn't
  actually triggered. Thus, there is a conflict between &amp;quot;vim&amp;quot; and
  &amp;quot;xxd&amp;quot; in these cases.
  Fixing this by removing the version completely. The 'vim' package
  should always replace 'xxd', even if people are migrating from an
  older SLE15 service pack which has the exact same version.

- Fix for bsc#1231373 / CVE-2024-47814.
- Fix for bsc#1229238 / CVE-2024-43374.
- 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;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: &amp;quot;above&amp;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: &amp;lt;CSI&amp;gt;27;&amp;lt;mod&amp;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;amp; spaces
  * runtime(misc): Use consistent &amp;quot;Vim script&amp;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: &amp;quot;shellcmdline&amp;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-&amp;lt;Key&amp;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;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;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 -&amp;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 &amp;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: &amp;quot;dvgo&amp;quot; is not always an inclusive motion
    runtime(java): Provide support for syntax preview features
  * v9.1.0698: &amp;quot;Untitled&amp;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 &amp;lt;Plug&amp;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 &amp;lt;Plug&amp;gt;ManBS
    runtime(java): Make the bundled &amp;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;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 &amp;quot;noselect&amp;quot;
    translation(ru): update man pages
  * v9.1.0683: mode( returns wrong value with &amp;lt;Cmd&amp;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 = &amp;quot;mysql&amp;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 &amp;quot;len&amp;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 &amp;quot;g:java_space_errors&amp;quot; and &amp;quot;g:java_comment_strings&amp;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 &amp;quot;ft-java-syntax&amp;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 &amp;quot;all&amp;quot; and &amp;quot;userns&amp;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 &amp;quot;a xterm&amp;quot; -&amp;gt; &amp;quot;an xterm&amp;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 &amp;quot;z&amp;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 &amp;quot;Keywords&amp;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;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 &amp;quot;..&amp;quot; and &amp;quot;../&amp;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 &amp;quot;*_* 99.dump&amp;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 &amp;quot;g:java_highlight_signature&amp;quot; and
    &amp;quot;g:java_highlight_functions&amp;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;amp; .prettierignore not recognized
  * filetype: Faust files are not recognized
  * inner-tag textobject confused about &amp;quot;&amp;gt;&amp;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;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 &amp;quot;kind&amp;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 &amp;quot;kind&amp;quot; and &amp;quot;menu&amp;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 &amp;quot;$&amp;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 &amp;lt;enter&amp;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 &amp;quot;v&amp;quot; position at line()
  * cmod_split modifier is always reset in term_start()
  * remove line-continuation characters
  * use shiftwidth() instead of &amp;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 &amp;quot;S&amp;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 '&amp;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&amp;lt;Tab&amp;gt; and &amp;lt;C-Tab&amp;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 &amp;quot;indent&amp;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 -&amp;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 &amp;quot;style&amp;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 &amp;quot;libsodium&amp;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 &amp;quot;g:ftplugin_java_source_path&amp;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:

- Drop support for shorthand URLs  * Breaking change to fix CVE-2024-10524.
  [+ drop-support-for-shorthand-URLs.patch, bsc#1233773]

Package xen was updated:

- Upstream bug fixes (bsc#1027519)  67645902-libxg-increase-LZMA_BLOCK_SIZE.patch
  6776dea1-x86-spec-ctrl-SRSO_U-S_NO-and-SRSO_MSR_FIX.patch

- Update to Xen 4.18.4 security bug fix release (bsc#1027519)
  xen-4.18.4-testing-src.tar.bz2
  * x86: Prefer ACPI reboot over UEFI ResetSystem() run time service call
  * No other changes mentioned in upstream changelog, sources, or webpage
- Dropped patches contained in new tarball
  6617d62c-x86-hvm-Misra-Rule-19-1-regression.patch
  66cf737b-x86-Dom0-disable-SMAP-for-PV-only.patch
  66d6dca8-libxl-nul-termination-in-xen_console_read_line.patch
  66d8690f-SUPPORT-split-XSM-from-Flask.patch
  66e29480-x86-HVM-properly-reject-indirect-VRAM-writes.patch
  66e44ae2-x86-ucode-AMD-buffer-underrun.patch
  66f2af41-x86-vLAPIC-undue-recursion-of-vlapic_error.patch
  66f2fd92-x86-ucode-Intel-stricter-sanity-check.patch
  gcc14-fixes.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
  xsa464.patch
  xsa466.patch

- bsc#1234282 - VUL-0: CVE-2024-53241: xen: XSA-466: Xen hypercall
  page unsafe against speculative attacks
  xsa466.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
- bsc#1232624 - VUL-0: CVE-2024-45819: xen: libxl leaks data to PVH
  guests via ACPI tables (XSA-464)
  xsa464.patch
- Drop 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)
  66f2af41-x86-vLAPIC-undue-recursion-of-vlapic_error.patch
  Drop xsa462.patch
- Upstream bug fixes (bsc#1027519)
  66cf737b-x86-Dom0-disable-SMAP-for-PV-only.patch
  66d6dca8-libxl-nul-termination-in-xen_console_read_line.patch
  66d8690f-SUPPORT-split-XSM-from-Flask.patch
  66e29480-x86-HVM-properly-reject-indirect-VRAM-writes.patch
  66e44ae2-x86-ucode-AMD-buffer-underrun.patch
  66f2fd92-x86-ucode-Intel-stricter-sanity-check.patch

Package yast2-installation was updated:

- Self-update fix (bsc#1234661)  - Properly compare the package versions from the inst-sys and
    the self-update repository
  - Remove the architecture suffix when reading the package version
    from the inst-sys (the /.packages.root file)
  - This fixes false alarm about incorrect self-update repository
    when the installation is booted from PXE using the updated
    tftpboot-installation-* packages (not the GA version)

Package yast2-iscsi-client was updated:

- Fix typo introduced by previous change (bsc#1231385, bsc#1233351)- 4.6.5

- Fixes for bsc#1231385
  - Do not call iscsi_offload.sh script anymore using the iscsi
    ifaces created by autoLogOn directly and exposing them in the
    UI instead of the offload card selection.
- 4.6.4

Package yast2-network was updated:

- Try to assign default global routes to an specific connection  when  possible (bsc#1232531).
- 4.6.10

Package zypper was updated:

- info: Allow to query a specific version (jsc#PED-11268)  To query for a specific version simply append &amp;quot;-&amp;lt;version&amp;gt;&amp;quot; or
  &amp;quot;-&amp;lt;version&amp;gt;-&amp;lt;release&amp;gt;&amp;quot; to the &amp;quot;&amp;lt;name&amp;gt;&amp;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 &amp;quot;se -v&amp;quot; showing the matches within the packages metadata.
  Explain that search strings starting with a &amp;quot;/&amp;quot; will implicitly
  look into the filelist as well. Otherfise an explicit &amp;quot;-f&amp;quot; is
  needed.
- version 1.14.78

</Note>
    <Note Title="Terms of Use" Type="Legal Disclaimer" Ordinal="3" xml:lang="en">The CVRF data is provided by SUSE under the Creative Commons License 4.0 with Attribution (CC-BY-4.0).</Note>
  </DocumentNotes>
  <DocumentReferences>
    <Reference Type="Self">
      <URL>https://publiccloudimagechangeinfo.suse.com/google/sles-15-sp6-byos-v20250129-x86-64/</URL>
      <Description>Public Cloud Image Info</Description>
    </Reference>
    <Reference Type="Self">
      <URL>https://www.suse.com/support/security/rating/</URL>
      <Description>SUSE Security Ratings</Description>
    </Reference>
  </DocumentReferences>
  <ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
    <Branch Type="Product Family" Name="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <Branch Type="Product Name" Name="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
        <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
      </Branch>
    </Branch>
    <Branch Type="Product Version" Name="aaa_base-84.87+git20180409.04c9dae-150300.10.23.1">
      <FullProductName ProductID="aaa_base-84.87+git20180409.04c9dae-150300.10.23.1">aaa_base-84.87+git20180409.04c9dae-150300.10.23.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="aaa_base-extras-84.87+git20180409.04c9dae-150300.10.23.1">
      <FullProductName ProductID="aaa_base-extras-84.87+git20180409.04c9dae-150300.10.23.1">aaa_base-extras-84.87+git20180409.04c9dae-150300.10.23.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="binutils-2.43-150100.7.52.1">
      <FullProductName ProductID="binutils-2.43-150100.7.52.1">binutils-2.43-150100.7.52.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cloud-regionsrv-client-10.3.11-150300.13.19.1">
      <FullProductName ProductID="cloud-regionsrv-client-10.3.11-150300.13.19.1">cloud-regionsrv-client-10.3.11-150300.13.19.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.19.1">
      <FullProductName ProductID="cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.19.1">cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.19.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="containerd-1.7.23-150000.120.1">
      <FullProductName ProductID="containerd-1.7.23-150000.120.1">containerd-1.7.23-150000.120.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="curl-8.6.0-150600.4.18.1">
      <FullProductName ProductID="curl-8.6.0-150600.4.18.1">curl-8.6.0-150600.4.18.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="dhcp-4.3.6.P1-150000.6.22.1">
      <FullProductName ProductID="dhcp-4.3.6.P1-150000.6.22.1">dhcp-4.3.6.P1-150000.6.22.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="dhcp-client-4.3.6.P1-150000.6.22.1">
      <FullProductName ProductID="dhcp-client-4.3.6.P1-150000.6.22.1">dhcp-client-4.3.6.P1-150000.6.22.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="docker-26.1.5_ce-150000.212.1">
      <FullProductName ProductID="docker-26.1.5_ce-150000.212.1">docker-26.1.5_ce-150000.212.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="dracut-059+suse.543.g98d7f037-150600.3.14.2">
      <FullProductName ProductID="dracut-059+suse.543.g98d7f037-150600.3.14.2">dracut-059+suse.543.g98d7f037-150600.3.14.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glib2-tools-2.78.6-150600.4.8.1">
      <FullProductName ProductID="glib2-tools-2.78.6-150600.4.8.1">glib2-tools-2.78.6-150600.4.8.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-2.38-150600.14.20.3">
      <FullProductName ProductID="glibc-2.38-150600.14.20.3">glibc-2.38-150600.14.20.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-i18ndata-2.38-150600.14.20.3">
      <FullProductName ProductID="glibc-i18ndata-2.38-150600.14.20.3">glibc-i18ndata-2.38-150600.14.20.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-locale-2.38-150600.14.20.3">
      <FullProductName ProductID="glibc-locale-2.38-150600.14.20.3">glibc-locale-2.38-150600.14.20.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-locale-base-2.38-150600.14.20.3">
      <FullProductName ProductID="glibc-locale-base-2.38-150600.14.20.3">glibc-locale-base-2.38-150600.14.20.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-guest-agent-20241011.01-150000.1.51.1">
      <FullProductName ProductID="google-guest-agent-20241011.01-150000.1.51.1">google-guest-agent-20241011.01-150000.1.51.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-guest-configs-20241205.00-150400.13.17.1">
      <FullProductName ProductID="google-guest-configs-20241205.00-150400.13.17.1">google-guest-configs-20241205.00-150400.13.17.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-osconfig-agent-20240926.03-150000.1.38.1">
      <FullProductName ProductID="google-osconfig-agent-20240926.03-150000.1.38.1">google-osconfig-agent-20240926.03-150000.1.38.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grub2-2.12-150600.8.12.1">
      <FullProductName ProductID="grub2-2.12-150600.8.12.1">grub2-2.12-150600.8.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grub2-i386-pc-2.12-150600.8.12.1">
      <FullProductName ProductID="grub2-i386-pc-2.12-150600.8.12.1">grub2-i386-pc-2.12-150600.8.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grub2-x86_64-efi-2.12-150600.8.12.1">
      <FullProductName ProductID="grub2-x86_64-efi-2.12-150600.8.12.1">grub2-x86_64-efi-2.12-150600.8.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kdump-2.0.6+git19.ge6e33ae-150600.3.6.2">
      <FullProductName ProductID="kdump-2.0.6+git19.ge6e33ae-150600.3.6.2">kdump-2.0.6+git19.ge6e33ae-150600.3.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kernel-default-6.4.0-150600.23.33.1">
      <FullProductName ProductID="kernel-default-6.4.0-150600.23.33.1">kernel-default-6.4.0-150600.23.33.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libavahi-client3-0.8-150600.15.6.1">
      <FullProductName ProductID="libavahi-client3-0.8-150600.15.6.1">libavahi-client3-0.8-150600.15.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libavahi-common3-0.8-150600.15.6.1">
      <FullProductName ProductID="libavahi-common3-0.8-150600.15.6.1">libavahi-common3-0.8-150600.15.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libctf-nobfd0-2.43-150100.7.52.1">
      <FullProductName ProductID="libctf-nobfd0-2.43-150100.7.52.1">libctf-nobfd0-2.43-150100.7.52.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libctf0-2.43-150100.7.52.1">
      <FullProductName ProductID="libctf0-2.43-150100.7.52.1">libctf0-2.43-150100.7.52.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libcurl4-8.6.0-150600.4.18.1">
      <FullProductName ProductID="libcurl4-8.6.0-150600.4.18.1">libcurl4-8.6.0-150600.4.18.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libexpat1-2.4.4-150400.3.25.1">
      <FullProductName ProductID="libexpat1-2.4.4-150400.3.25.1">libexpat1-2.4.4-150400.3.25.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgio-2_0-0-2.78.6-150600.4.8.1">
      <FullProductName ProductID="libgio-2_0-0-2.78.6-150600.4.8.1">libgio-2_0-0-2.78.6-150600.4.8.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libglib-2_0-0-2.78.6-150600.4.8.1">
      <FullProductName ProductID="libglib-2_0-0-2.78.6-150600.4.8.1">libglib-2_0-0-2.78.6-150600.4.8.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgmodule-2_0-0-2.78.6-150600.4.8.1">
      <FullProductName ProductID="libgmodule-2_0-0-2.78.6-150600.4.8.1">libgmodule-2_0-0-2.78.6-150600.4.8.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgobject-2_0-0-2.78.6-150600.4.8.1">
      <FullProductName ProductID="libgobject-2_0-0-2.78.6-150600.4.8.1">libgobject-2_0-0-2.78.6-150600.4.8.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libldb2-2.8.2-150600.3.6.1">
      <FullProductName ProductID="libldb2-2.8.2-150600.3.6.1">libldb2-2.8.2-150600.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libnfsidmap1-1.0-150600.28.6.2">
      <FullProductName ProductID="libnfsidmap1-1.0-150600.28.6.2">libnfsidmap1-1.0-150600.28.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libnl-config-3.9.0-150600.15.4.4">
      <FullProductName ProductID="libnl-config-3.9.0-150600.15.4.4">libnl-config-3.9.0-150600.15.4.4</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libnl3-200-3.9.0-150600.15.4.4">
      <FullProductName ProductID="libnl3-200-3.9.0-150600.15.4.4">libnl3-200-3.9.0-150600.15.4.4</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libnvme-mi1-1.8+79.g69e7772-150600.3.12.2">
      <FullProductName ProductID="libnvme-mi1-1.8+79.g69e7772-150600.3.12.2">libnvme-mi1-1.8+79.g69e7772-150600.3.12.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libnvme1-1.8+79.g69e7772-150600.3.12.2">
      <FullProductName ProductID="libnvme1-1.8+79.g69e7772-150600.3.12.2">libnvme1-1.8+79.g69e7772-150600.3.12.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libproxy1-0.5.3-150600.4.6.2">
      <FullProductName ProductID="libproxy1-0.5.3-150600.4.6.2">libproxy1-0.5.3-150600.4.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpxbackend-1_0-0.5.3-150600.4.6.2">
      <FullProductName ProductID="libpxbackend-1_0-0.5.3-150600.4.6.2">libpxbackend-1_0-0.5.3-150600.4.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpython3_6m1_0-3.6.15-150300.10.78.1">
      <FullProductName ProductID="libpython3_6m1_0-3.6.15-150300.10.78.1">libpython3_6m1_0-3.6.15-150300.10.78.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsolv-tools-base-0.7.31-150600.8.7.2">
      <FullProductName ProductID="libsolv-tools-base-0.7.31-150600.8.7.2">libsolv-tools-base-0.7.31-150600.8.7.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsuseconnect-1.13.0-150600.3.11.1">
      <FullProductName ProductID="libsuseconnect-1.13.0-150600.3.11.1">libsuseconnect-1.13.0-150600.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsystemd0-254.21-150600.4.21.1">
      <FullProductName ProductID="libsystemd0-254.21-150600.4.21.1">libsystemd0-254.21-150600.4.21.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libudev1-254.21-150600.4.21.1">
      <FullProductName ProductID="libudev1-254.21-150600.4.21.1">libudev1-254.21-150600.4.21.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libuv1-1.44.2-150500.3.5.1">
      <FullProductName ProductID="libuv1-1.44.2-150500.3.5.1">libuv1-1.44.2-150500.3.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libzypp-17.35.16-150600.3.41.1">
      <FullProductName ProductID="libzypp-17.35.16-150600.3.41.1">libzypp-17.35.16-150600.3.41.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="nfs-client-2.6.4-150600.28.6.2">
      <FullProductName ProductID="nfs-client-2.6.4-150600.28.6.2">nfs-client-2.6.4-150600.28.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="nfs-kernel-server-2.6.4-150600.28.6.2">
      <FullProductName ProductID="nfs-kernel-server-2.6.4-150600.28.6.2">nfs-kernel-server-2.6.4-150600.28.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="nscd-2.38-150600.14.20.3">
      <FullProductName ProductID="nscd-2.38-150600.14.20.3">nscd-2.38-150600.14.20.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="nvme-cli-2.8+87.g29df38e-150600.3.12.2">
      <FullProductName ProductID="nvme-cli-2.8+87.g29df38e-150600.3.12.2">nvme-cli-2.8+87.g29df38e-150600.3.12.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-9.6p1-150600.6.12.1">
      <FullProductName ProductID="openssh-9.6p1-150600.6.12.1">openssh-9.6p1-150600.6.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-clients-9.6p1-150600.6.12.1">
      <FullProductName ProductID="openssh-clients-9.6p1-150600.6.12.1">openssh-clients-9.6p1-150600.6.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-common-9.6p1-150600.6.12.1">
      <FullProductName ProductID="openssh-common-9.6p1-150600.6.12.1">openssh-common-9.6p1-150600.6.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-server-9.6p1-150600.6.12.1">
      <FullProductName ProductID="openssh-server-9.6p1-150600.6.12.1">openssh-server-9.6p1-150600.6.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="patterns-base-minimal_base-20200124-150600.32.3.2">
      <FullProductName ProductID="patterns-base-minimal_base-20200124-150600.32.3.2">patterns-base-minimal_base-20200124-150600.32.3.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="permissions-20240826-150600.10.12.1">
      <FullProductName ProductID="permissions-20240826-150600.10.12.1">permissions-20240826-150600.10.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="polkit-default-privs-13.2+20241216.68f9867-150600.3.3.1">
      <FullProductName ProductID="polkit-default-privs-13.2+20241216.68f9867-150600.3.3.1">polkit-default-privs-13.2+20241216.68f9867-150600.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-3.6.15-150300.10.78.1">
      <FullProductName ProductID="python3-3.6.15-150300.10.78.1">python3-3.6.15-150300.10.78.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-Jinja2-2.10.1-150000.3.18.1">
      <FullProductName ProductID="python3-Jinja2-2.10.1-150000.3.18.1">python3-Jinja2-2.10.1-150000.3.18.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-base-3.6.15-150300.10.78.1">
      <FullProductName ProductID="python3-base-3.6.15-150300.10.78.1">python3-base-3.6.15-150300.10.78.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-curses-3.6.15-150300.10.78.1">
      <FullProductName ProductID="python3-curses-3.6.15-150300.10.78.1">python3-curses-3.6.15-150300.10.78.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-salt-3006.0-150500.4.44.2">
      <FullProductName ProductID="python3-salt-3006.0-150500.4.44.2">python3-salt-3006.0-150500.4.44.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-solv-0.7.31-150600.8.7.2">
      <FullProductName ProductID="python3-solv-0.7.31-150600.8.7.2">python3-solv-0.7.31-150600.8.7.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="rsync-3.2.7-150600.3.8.1">
      <FullProductName ProductID="rsync-3.2.7-150600.3.8.1">rsync-3.2.7-150600.3.8.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ruby-solv-0.7.31-150600.8.7.2">
      <FullProductName ProductID="ruby-solv-0.7.31-150600.8.7.2">ruby-solv-0.7.31-150600.8.7.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ruby2.5-rubygem-nokogiri-1.8.5-150400.14.6.1">
      <FullProductName ProductID="ruby2.5-rubygem-nokogiri-1.8.5-150400.14.6.1">ruby2.5-rubygem-nokogiri-1.8.5-150400.14.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="salt-3006.0-150500.4.44.2">
      <FullProductName ProductID="salt-3006.0-150500.4.44.2">salt-3006.0-150500.4.44.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="salt-minion-3006.0-150500.4.44.2">
      <FullProductName ProductID="salt-minion-3006.0-150500.4.44.2">salt-minion-3006.0-150500.4.44.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="samba-client-libs-4.19.8+git.399.71536ca297e-150600.3.9.6">
      <FullProductName ProductID="samba-client-libs-4.19.8+git.399.71536ca297e-150600.3.9.6">samba-client-libs-4.19.8+git.399.71536ca297e-150600.3.9.6</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="shared-mime-info-2.4-150600.3.3.2">
      <FullProductName ProductID="shared-mime-info-2.4-150600.3.3.2">shared-mime-info-2.4-150600.3.3.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suseconnect-ng-1.13.0-150600.3.11.1">
      <FullProductName ProductID="suseconnect-ng-1.13.0-150600.3.11.1">suseconnect-ng-1.13.0-150600.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suseconnect-ruby-bindings-1.13.0-150600.3.11.1">
      <FullProductName ProductID="suseconnect-ruby-bindings-1.13.0-150600.3.11.1">suseconnect-ruby-bindings-1.13.0-150600.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-254.21-150600.4.21.1">
      <FullProductName ProductID="systemd-254.21-150600.4.21.1">systemd-254.21-150600.4.21.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-sysvcompat-254.21-150600.4.21.1">
      <FullProductName ProductID="systemd-sysvcompat-254.21-150600.4.21.1">systemd-sysvcompat-254.21-150600.4.21.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="udev-254.21-150600.4.21.1">
      <FullProductName ProductID="udev-254.21-150600.4.21.1">udev-254.21-150600.4.21.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="vim-9.1.0836-150500.20.18.1">
      <FullProductName ProductID="vim-9.1.0836-150500.20.18.1">vim-9.1.0836-150500.20.18.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="vim-data-common-9.1.0836-150500.20.18.1">
      <FullProductName ProductID="vim-data-common-9.1.0836-150500.20.18.1">vim-data-common-9.1.0836-150500.20.18.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="wget-1.20.3-150600.19.9.1">
      <FullProductName ProductID="wget-1.20.3-150600.19.9.1">wget-1.20.3-150600.19.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="xen-libs-4.18.4_02-150600.3.15.2">
      <FullProductName ProductID="xen-libs-4.18.4_02-150600.3.15.2">xen-libs-4.18.4_02-150600.3.15.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-installation-4.6.14-150600.3.6.1">
      <FullProductName ProductID="yast2-installation-4.6.14-150600.3.6.1">yast2-installation-4.6.14-150600.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-iscsi-client-4.6.5-150600.3.11.2">
      <FullProductName ProductID="yast2-iscsi-client-4.6.5-150600.3.11.2">yast2-iscsi-client-4.6.5-150600.3.11.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-network-4.6.10-150600.3.3.2">
      <FullProductName ProductID="yast2-network-4.6.10-150600.3.3.2">yast2-network-4.6.10-150600.3.3.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="zypper-1.14.79-150600.10.19.1">
      <FullProductName ProductID="zypper-1.14.79-150600.10.19.1">zypper-1.14.79-150600.10.19.1</FullProductName>
    </Branch>
    <Relationship ProductReference="aaa_base-84.87+git20180409.04c9dae-150300.10.23.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:aaa_base-84.87+git20180409.04c9dae-150300.10.23.1">aaa_base-84.87+git20180409.04c9dae-150300.10.23.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="aaa_base-extras-84.87+git20180409.04c9dae-150300.10.23.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:aaa_base-extras-84.87+git20180409.04c9dae-150300.10.23.1">aaa_base-extras-84.87+git20180409.04c9dae-150300.10.23.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="binutils-2.43-150100.7.52.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:binutils-2.43-150100.7.52.1">binutils-2.43-150100.7.52.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cloud-regionsrv-client-10.3.11-150300.13.19.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:cloud-regionsrv-client-10.3.11-150300.13.19.1">cloud-regionsrv-client-10.3.11-150300.13.19.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.19.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.19.1">cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.19.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="containerd-1.7.23-150000.120.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:containerd-1.7.23-150000.120.1">containerd-1.7.23-150000.120.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="curl-8.6.0-150600.4.18.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:curl-8.6.0-150600.4.18.1">curl-8.6.0-150600.4.18.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="dhcp-4.3.6.P1-150000.6.22.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:dhcp-4.3.6.P1-150000.6.22.1">dhcp-4.3.6.P1-150000.6.22.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="dhcp-client-4.3.6.P1-150000.6.22.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:dhcp-client-4.3.6.P1-150000.6.22.1">dhcp-client-4.3.6.P1-150000.6.22.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="docker-26.1.5_ce-150000.212.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:docker-26.1.5_ce-150000.212.1">docker-26.1.5_ce-150000.212.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="dracut-059+suse.543.g98d7f037-150600.3.14.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:dracut-059+suse.543.g98d7f037-150600.3.14.2">dracut-059+suse.543.g98d7f037-150600.3.14.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glib2-tools-2.78.6-150600.4.8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:glib2-tools-2.78.6-150600.4.8.1">glib2-tools-2.78.6-150600.4.8.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-2.38-150600.14.20.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:glibc-2.38-150600.14.20.3">glibc-2.38-150600.14.20.3 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-i18ndata-2.38-150600.14.20.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:glibc-i18ndata-2.38-150600.14.20.3">glibc-i18ndata-2.38-150600.14.20.3 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-locale-2.38-150600.14.20.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:glibc-locale-2.38-150600.14.20.3">glibc-locale-2.38-150600.14.20.3 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-locale-base-2.38-150600.14.20.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:glibc-locale-base-2.38-150600.14.20.3">glibc-locale-base-2.38-150600.14.20.3 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-guest-agent-20241011.01-150000.1.51.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:google-guest-agent-20241011.01-150000.1.51.1">google-guest-agent-20241011.01-150000.1.51.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-guest-configs-20241205.00-150400.13.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:google-guest-configs-20241205.00-150400.13.17.1">google-guest-configs-20241205.00-150400.13.17.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-osconfig-agent-20240926.03-150000.1.38.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:google-osconfig-agent-20240926.03-150000.1.38.1">google-osconfig-agent-20240926.03-150000.1.38.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-2.12-150600.8.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:grub2-2.12-150600.8.12.1">grub2-2.12-150600.8.12.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-i386-pc-2.12-150600.8.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:grub2-i386-pc-2.12-150600.8.12.1">grub2-i386-pc-2.12-150600.8.12.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-x86_64-efi-2.12-150600.8.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:grub2-x86_64-efi-2.12-150600.8.12.1">grub2-x86_64-efi-2.12-150600.8.12.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kdump-2.0.6+git19.ge6e33ae-150600.3.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kdump-2.0.6+git19.ge6e33ae-150600.3.6.2">kdump-2.0.6+git19.ge6e33ae-150600.3.6.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kernel-default-6.4.0-150600.23.33.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1">kernel-default-6.4.0-150600.23.33.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libavahi-client3-0.8-150600.15.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libavahi-client3-0.8-150600.15.6.1">libavahi-client3-0.8-150600.15.6.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libavahi-common3-0.8-150600.15.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libavahi-common3-0.8-150600.15.6.1">libavahi-common3-0.8-150600.15.6.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libctf-nobfd0-2.43-150100.7.52.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libctf-nobfd0-2.43-150100.7.52.1">libctf-nobfd0-2.43-150100.7.52.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libctf0-2.43-150100.7.52.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libctf0-2.43-150100.7.52.1">libctf0-2.43-150100.7.52.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libcurl4-8.6.0-150600.4.18.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libcurl4-8.6.0-150600.4.18.1">libcurl4-8.6.0-150600.4.18.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libexpat1-2.4.4-150400.3.25.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libexpat1-2.4.4-150400.3.25.1">libexpat1-2.4.4-150400.3.25.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgio-2_0-0-2.78.6-150600.4.8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libgio-2_0-0-2.78.6-150600.4.8.1">libgio-2_0-0-2.78.6-150600.4.8.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libglib-2_0-0-2.78.6-150600.4.8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libglib-2_0-0-2.78.6-150600.4.8.1">libglib-2_0-0-2.78.6-150600.4.8.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgmodule-2_0-0-2.78.6-150600.4.8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libgmodule-2_0-0-2.78.6-150600.4.8.1">libgmodule-2_0-0-2.78.6-150600.4.8.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgobject-2_0-0-2.78.6-150600.4.8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libgobject-2_0-0-2.78.6-150600.4.8.1">libgobject-2_0-0-2.78.6-150600.4.8.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libldb2-2.8.2-150600.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libldb2-2.8.2-150600.3.6.1">libldb2-2.8.2-150600.3.6.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libnfsidmap1-1.0-150600.28.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libnfsidmap1-1.0-150600.28.6.2">libnfsidmap1-1.0-150600.28.6.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libnl-config-3.9.0-150600.15.4.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libnl-config-3.9.0-150600.15.4.4">libnl-config-3.9.0-150600.15.4.4 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libnl3-200-3.9.0-150600.15.4.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libnl3-200-3.9.0-150600.15.4.4">libnl3-200-3.9.0-150600.15.4.4 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libnvme-mi1-1.8+79.g69e7772-150600.3.12.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libnvme-mi1-1.8+79.g69e7772-150600.3.12.2">libnvme-mi1-1.8+79.g69e7772-150600.3.12.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libnvme1-1.8+79.g69e7772-150600.3.12.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libnvme1-1.8+79.g69e7772-150600.3.12.2">libnvme1-1.8+79.g69e7772-150600.3.12.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libproxy1-0.5.3-150600.4.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libproxy1-0.5.3-150600.4.6.2">libproxy1-0.5.3-150600.4.6.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpxbackend-1_0-0.5.3-150600.4.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libpxbackend-1_0-0.5.3-150600.4.6.2">libpxbackend-1_0-0.5.3-150600.4.6.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpython3_6m1_0-3.6.15-150300.10.78.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libpython3_6m1_0-3.6.15-150300.10.78.1">libpython3_6m1_0-3.6.15-150300.10.78.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsolv-tools-base-0.7.31-150600.8.7.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libsolv-tools-base-0.7.31-150600.8.7.2">libsolv-tools-base-0.7.31-150600.8.7.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsuseconnect-1.13.0-150600.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libsuseconnect-1.13.0-150600.3.11.1">libsuseconnect-1.13.0-150600.3.11.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsystemd0-254.21-150600.4.21.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libsystemd0-254.21-150600.4.21.1">libsystemd0-254.21-150600.4.21.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libudev1-254.21-150600.4.21.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libudev1-254.21-150600.4.21.1">libudev1-254.21-150600.4.21.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libuv1-1.44.2-150500.3.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libuv1-1.44.2-150500.3.5.1">libuv1-1.44.2-150500.3.5.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libzypp-17.35.16-150600.3.41.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libzypp-17.35.16-150600.3.41.1">libzypp-17.35.16-150600.3.41.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="nfs-client-2.6.4-150600.28.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:nfs-client-2.6.4-150600.28.6.2">nfs-client-2.6.4-150600.28.6.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="nfs-kernel-server-2.6.4-150600.28.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:nfs-kernel-server-2.6.4-150600.28.6.2">nfs-kernel-server-2.6.4-150600.28.6.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="nscd-2.38-150600.14.20.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:nscd-2.38-150600.14.20.3">nscd-2.38-150600.14.20.3 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="nvme-cli-2.8+87.g29df38e-150600.3.12.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:nvme-cli-2.8+87.g29df38e-150600.3.12.2">nvme-cli-2.8+87.g29df38e-150600.3.12.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-9.6p1-150600.6.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:openssh-9.6p1-150600.6.12.1">openssh-9.6p1-150600.6.12.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-clients-9.6p1-150600.6.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:openssh-clients-9.6p1-150600.6.12.1">openssh-clients-9.6p1-150600.6.12.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-common-9.6p1-150600.6.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:openssh-common-9.6p1-150600.6.12.1">openssh-common-9.6p1-150600.6.12.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-server-9.6p1-150600.6.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:openssh-server-9.6p1-150600.6.12.1">openssh-server-9.6p1-150600.6.12.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="patterns-base-minimal_base-20200124-150600.32.3.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:patterns-base-minimal_base-20200124-150600.32.3.2">patterns-base-minimal_base-20200124-150600.32.3.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="permissions-20240826-150600.10.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:permissions-20240826-150600.10.12.1">permissions-20240826-150600.10.12.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="polkit-default-privs-13.2+20241216.68f9867-150600.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:polkit-default-privs-13.2+20241216.68f9867-150600.3.3.1">polkit-default-privs-13.2+20241216.68f9867-150600.3.3.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-3.6.15-150300.10.78.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:python3-3.6.15-150300.10.78.1">python3-3.6.15-150300.10.78.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-Jinja2-2.10.1-150000.3.18.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:python3-Jinja2-2.10.1-150000.3.18.1">python3-Jinja2-2.10.1-150000.3.18.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-base-3.6.15-150300.10.78.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:python3-base-3.6.15-150300.10.78.1">python3-base-3.6.15-150300.10.78.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-curses-3.6.15-150300.10.78.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:python3-curses-3.6.15-150300.10.78.1">python3-curses-3.6.15-150300.10.78.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-salt-3006.0-150500.4.44.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:python3-salt-3006.0-150500.4.44.2">python3-salt-3006.0-150500.4.44.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-solv-0.7.31-150600.8.7.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:python3-solv-0.7.31-150600.8.7.2">python3-solv-0.7.31-150600.8.7.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="rsync-3.2.7-150600.3.8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:rsync-3.2.7-150600.3.8.1">rsync-3.2.7-150600.3.8.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ruby-solv-0.7.31-150600.8.7.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:ruby-solv-0.7.31-150600.8.7.2">ruby-solv-0.7.31-150600.8.7.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ruby2.5-rubygem-nokogiri-1.8.5-150400.14.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:ruby2.5-rubygem-nokogiri-1.8.5-150400.14.6.1">ruby2.5-rubygem-nokogiri-1.8.5-150400.14.6.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="salt-3006.0-150500.4.44.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:salt-3006.0-150500.4.44.2">salt-3006.0-150500.4.44.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="salt-minion-3006.0-150500.4.44.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:salt-minion-3006.0-150500.4.44.2">salt-minion-3006.0-150500.4.44.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="samba-client-libs-4.19.8+git.399.71536ca297e-150600.3.9.6" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:samba-client-libs-4.19.8+git.399.71536ca297e-150600.3.9.6">samba-client-libs-4.19.8+git.399.71536ca297e-150600.3.9.6 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="shared-mime-info-2.4-150600.3.3.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:shared-mime-info-2.4-150600.3.3.2">shared-mime-info-2.4-150600.3.3.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suseconnect-ng-1.13.0-150600.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:suseconnect-ng-1.13.0-150600.3.11.1">suseconnect-ng-1.13.0-150600.3.11.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suseconnect-ruby-bindings-1.13.0-150600.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:suseconnect-ruby-bindings-1.13.0-150600.3.11.1">suseconnect-ruby-bindings-1.13.0-150600.3.11.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-254.21-150600.4.21.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:systemd-254.21-150600.4.21.1">systemd-254.21-150600.4.21.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-sysvcompat-254.21-150600.4.21.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:systemd-sysvcompat-254.21-150600.4.21.1">systemd-sysvcompat-254.21-150600.4.21.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="udev-254.21-150600.4.21.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:udev-254.21-150600.4.21.1">udev-254.21-150600.4.21.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-9.1.0836-150500.20.18.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:vim-9.1.0836-150500.20.18.1">vim-9.1.0836-150500.20.18.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-data-common-9.1.0836-150500.20.18.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:vim-data-common-9.1.0836-150500.20.18.1">vim-data-common-9.1.0836-150500.20.18.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="wget-1.20.3-150600.19.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:wget-1.20.3-150600.19.9.1">wget-1.20.3-150600.19.9.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="xen-libs-4.18.4_02-150600.3.15.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:xen-libs-4.18.4_02-150600.3.15.2">xen-libs-4.18.4_02-150600.3.15.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-installation-4.6.14-150600.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:yast2-installation-4.6.14-150600.3.6.1">yast2-installation-4.6.14-150600.3.6.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-iscsi-client-4.6.5-150600.3.11.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:yast2-iscsi-client-4.6.5-150600.3.11.2">yast2-iscsi-client-4.6.5-150600.3.11.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-network-4.6.10-150600.3.3.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:yast2-network-4.6.10-150600.3.3.2">yast2-network-4.6.10-150600.3.3.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="zypper-1.14.79-150600.10.19.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:zypper-1.14.79-150600.10.19.1">zypper-1.14.79-150600.10.19.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64</FullProductName>
    </Relationship>
  </ProductTree>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2023-45142</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:docker-26.1.5_ce-150000.212.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">OpenTelemetry-Go Contrib is a collection of third-party packages for OpenTelemetry-Go. Prior to version 0.46.0, the grpc Unary Server Interceptor out of the box adds labels `net.peer.sock.addr` and `net.peer.sock.port` that have unbound cardinality. It leads to the server's potential memory exhaustion when many malicious requests are sent. An attacker can easily flood the peer address and port for requests. Version 0.46.0 contains a fix for this issue. As a workaround to stop being affected, a view removing the attributes can be used. The other possibility is to disable grpc metrics instrumentation by passing `otelgrpc.WithMeterProvider` option with `noop.NewMeterProvider`.</Note>
    </Notes>
    <CVE>CVE-2023-47108</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:docker-26.1.5_ce-150000.212.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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-&gt;headers[i] access when i &gt;= number of allocated
ring headers.</Note>
    </Notes>
    <CVE>CVE-2023-52766</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mptcp: deal with large GSO size

After the blamed commit below, the TCP sockets (and the MPTCP subflows)
can build egress packets larger than 64K. That exceeds the maximum DSS
data size, the length being misrepresent on the wire and the stream being
corrupted, as later observed on the receiver:

  WARNING: CPU: 0 PID: 9696 at net/mptcp/protocol.c:705 __mptcp_move_skbs_from_subflow+0x2604/0x26e0
  CPU: 0 PID: 9696 Comm: syz-executor.7 Not tainted 6.6.0-rc5-gcd8bdf563d46 #45
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
  netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'.
  RIP: 0010:__mptcp_move_skbs_from_subflow+0x2604/0x26e0 net/mptcp/protocol.c:705
  RSP: 0018:ffffc90000006e80 EFLAGS: 00010246
  RAX: ffffffff83e9f674 RBX: ffff88802f45d870 RCX: ffff888102ad0000
  netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'.
  RDX: 0000000080000303 RSI: 0000000000013908 RDI: 0000000000003908
  RBP: ffffc90000007110 R08: ffffffff83e9e078 R09: 1ffff1100e548c8a
  R10: dffffc0000000000 R11: ffffed100e548c8b R12: 0000000000013908
  R13: dffffc0000000000 R14: 0000000000003908 R15: 000000000031cf29
  FS:  00007f239c47e700(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f239c45cd78 CR3: 000000006a66c006 CR4: 0000000000770ef0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
  PKRU: 55555554
  Call Trace:
   &lt;IRQ&gt;
   mptcp_data_ready+0x263/0xac0 net/mptcp/protocol.c:819
   subflow_data_ready+0x268/0x6d0 net/mptcp/subflow.c:1409
   tcp_data_queue+0x21a1/0x7a60 net/ipv4/tcp_input.c:5151
   tcp_rcv_established+0x950/0x1d90 net/ipv4/tcp_input.c:6098
   tcp_v6_do_rcv+0x554/0x12f0 net/ipv6/tcp_ipv6.c:1483
   tcp_v6_rcv+0x2e26/0x3810 net/ipv6/tcp_ipv6.c:1749
   ip6_protocol_deliver_rcu+0xd6b/0x1ae0 net/ipv6/ip6_input.c:438
   ip6_input+0x1c5/0x470 net/ipv6/ip6_input.c:483
   ipv6_rcv+0xef/0x2c0 include/linux/netfilter.h:304
   __netif_receive_skb+0x1ea/0x6a0 net/core/dev.c:5532
   process_backlog+0x353/0x660 net/core/dev.c:5974
   __napi_poll+0xc6/0x5a0 net/core/dev.c:6536
   net_rx_action+0x6a0/0xfd0 net/core/dev.c:6603
   __do_softirq+0x184/0x524 kernel/softirq.c:553
   do_softirq+0xdd/0x130 kernel/softirq.c:454

Address the issue explicitly bounding the maximum GSO size to what MPTCP
actually allows.</Note>
    </Notes>
    <CVE>CVE-2023-52778</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2023-52800</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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) &lt;= SEG.ACK &lt;=
   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 &lt; SND.UNA), it can be ignored.  If the ACK
   acknowledges something not yet sent (SEG.ACK &gt; 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 &lt; SND.UNA wouldn't be
   accepted, instead only ACKs that are in the range ((SND.UNA -
   MAX.SND.WND) &lt;= SEG.ACK &lt;= 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-&gt;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 &lt; S 0:0(0) win 65535 &lt;mss 1400,nop,wscale 14&gt;
+0 &gt; S. 0:0(0) ack 1 &lt;...&gt;
+0 &lt; . 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 &lt; . 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 &gt; . 1:1(0) ack 1001</Note>
    </Notes>
    <CVE>CVE-2023-52881</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2023-52917</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: pci: cx23885: check cx23885_vdev_init() return

cx23885_vdev_init() can return a NULL pointer, but that pointer
is used in the next line without a check.

Add a NULL pointer check and go to the error unwind if it is NULL.</Note>
    </Notes>
    <CVE>CVE-2023-52918</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2023-52919</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: support non-r10 register spill/fill to/from stack in precision tracking

Use instruction (jump) history to record instructions that performed
register spill/fill to/from stack, regardless if this was done through
read-only r10 register, or any other register after copying r10 into it
*and* potentially adjusting offset.

To make this work reliably, we push extra per-instruction flags into
instruction history, encoding stack slot index (spi) and stack frame
number in extra 10 bit flags we take away from prev_idx in instruction
history. We don't touch idx field for maximum performance, as it's
checked most frequently during backtracking.

This change removes basically the last remaining practical limitation of
precision backtracking logic in BPF verifier. It fixes known
deficiencies, but also opens up new opportunities to reduce number of
verified states, explored in the subsequent patches.

There are only three differences in selftests' BPF object files
according to veristat, all in the positive direction (less states).

File                                    Program        Insns (A)  Insns (B)  Insns  (DIFF)  States (A)  States (B)  States (DIFF)
--------------------------------------  -------------  ---------  ---------  -------------  ----------  ----------  -------------
test_cls_redirect_dynptr.bpf.linked3.o  cls_redirect        2987       2864  -123 (-4.12%)         240         231    -9 (-3.75%)
xdp_synproxy_kern.bpf.linked3.o         syncookie_tc       82848      82661  -187 (-0.23%)        5107        5073   -34 (-0.67%)
xdp_synproxy_kern.bpf.linked3.o         syncookie_xdp      85116      84964  -152 (-0.18%)        5162        5130   -32 (-0.62%)

Note, I avoided renaming jmp_history to more generic insn_hist to
minimize number of lines changed and potential merge conflicts between
bpf and bpf-next trees.

Notice also cur_hist_entry pointer reset to NULL at the beginning of
instruction verification loop. This pointer avoids the problem of
relying on last jump history entry's insn_idx to determine whether we
already have entry for current instruction or not. It can happen that we
added jump history entry because current instruction is_jmp_point(), but
also we need to add instruction flags for stack access. In this case, we
don't want to entries, so we need to reuse last added entry, if it is
present.

Relying on insn_idx comparison has the same ambiguity problem as the one
that was fixed recently in [0], so we avoid that.

  [0] https://patchwork.kernel.org/project/netdevbpf/patch/20231110002638.4168352-3-andrii@kernel.org/</Note>
    </Notes>
    <CVE>CVE-2023-52920</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: fix possible UAF in amdgpu_cs_pass1()

Since the gang_size check is outside of chunk parsing
loop, we need to reset i before we free the chunk data.

Suggested by Ye Zhang (@VAR10CK) of Baidu Security.</Note>
    </Notes>
    <CVE>CVE-2023-52921</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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:
 &lt;TASK&gt;
 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.</Note>
    </Notes>
    <CVE>CVE-2023-52922</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2023-6270</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-10524</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:wget-1.20.3-150600.19.9.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-11053</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:curl-8.6.0-150600.4.18.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libcurl4-8.6.0-150600.4.18.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-11168</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:python3-3.6.15-150300.10.78.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:python3-curses-3.6.15-150300.10.78.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A heap-based buffer overflow flaw was found in the rsync daemon. This issue is due to improper handling of attacker-controlled checksum lengths (s2length) in the code. When MAX_DIGEST_LEN exceeds the fixed SUM_LENGTH (16 bytes), an attacker can write out of bounds in the sum2 buffer.</Note>
    </Notes>
    <CVE>CVE-2024-12084</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:rsync-3.2.7-150600.3.8.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>critical</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in rsync which could be triggered when rsync compares file checksums. This flaw allows an attacker to manipulate the checksum length (s2length) to cause a comparison between a checksum and uninitialized memory and leak one byte of uninitialized stack data at a time.</Note>
    </Notes>
    <CVE>CVE-2024-12085</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:rsync-3.2.7-150600.3.8.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in rsync. It could allow a server to enumerate the contents of an arbitrary file from the client's machine. This issue occurs when files are being copied from a client to a server. During this process, the rsync server will send checksums of local data to the client to compare with in order to determine what data needs to be sent to the server. By sending specially constructed checksum values for arbitrary files, an attacker may be able to reconstruct the data of those files byte-by-byte based on the responses from the client.</Note>
    </Notes>
    <CVE>CVE-2024-12086</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:rsync-3.2.7-150600.3.8.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A path traversal vulnerability exists in rsync. It stems from behavior enabled by the `--inc-recursive` option, a default-enabled option for many client options and can be enabled by the server even if not explicitly enabled by the client. When using the `--inc-recursive` option, a lack of proper symlink verification coupled with deduplication checks occurring on a per-file-list basis could allow a server to write files outside of the client's intended destination directory. A malicious server could write malicious files to arbitrary locations named after valid directories/paths on the client.</Note>
    </Notes>
    <CVE>CVE-2024-12087</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:rsync-3.2.7-150600.3.8.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in rsync. When using the `--safe-links` option, the rsync client fails to properly verify if a symbolic link destination sent from the server contains another symbolic link within it. This results in a path traversal vulnerability, which may lead to arbitrary file write outside the desired directory.</Note>
    </Notes>
    <CVE>CVE-2024-12088</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:rsync-3.2.7-150600.3.8.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in rsync. This vulnerability arises from a race condition during rsync's handling of symbolic links. Rsync's default behavior when encountering symbolic links is to skip them. If an attacker replaced a regular file with a symbolic link at the right time, it was possible to bypass the default behavior and traverse symbolic links. Depending on the privileges of the rsync process, an attacker could leak sensitive information, potentially leading to privilege escalation.</Note>
    </Notes>
    <CVE>CVE-2024-12747</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:rsync-3.2.7-150600.3.8.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">libuv is a multi-platform support library with a focus on asynchronous I/O. The `uv_getaddrinfo` function in `src/unix/getaddrinfo.c` (and its windows counterpart `src/win/getaddrinfo.c`), truncates hostnames to 256 characters before calling `getaddrinfo`. This behavior can be exploited to create addresses like `0x00007f000001`, which are considered valid by `getaddrinfo` and could allow an attacker to craft payloads that resolve to unintended IP addresses, bypassing developer checks. The vulnerability arises due to how the `hostname_ascii` variable (with a length of 256 bytes) is handled in `uv_getaddrinfo` and subsequently in `uv__idna_toascii`. When the hostname exceeds 256 characters, it gets truncated without a terminating null byte. As a result attackers may be able to access internal APIs or for websites (similar to MySpace) that allows users to have `username.example.com` pages. Internal services that crawl or cache these user pages can be exposed to SSRF attacks if a malicious user chooses a long vulnerable username. This issue has been addressed in release version 1.48.0. Users are advised to upgrade. There are no known workarounds for this vulnerability.</Note>
    </Notes>
    <CVE>CVE-2024-24806</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libuv1-1.44.2-150500.3.5.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: dsa: fix netdev_priv() dereference before check on non-DSA netdevice events

After the blamed commit, we started doing this dereference for every
NETDEV_CHANGEUPPER and NETDEV_PRECHANGEUPPER event in the system.

static inline struct dsa_port *dsa_user_to_port(const struct net_device *dev)
{
	struct dsa_user_priv *p = netdev_priv(dev);

	return p-&gt;dp;
}

Which is obviously bogus, because not all net_devices have a netdev_priv()
of type struct dsa_user_priv. But struct dsa_user_priv is fairly small,
and p-&gt;dp means dereferencing 8 bytes starting with offset 16. Most
drivers allocate that much private memory anyway, making our access not
fault, and we discard the bogus data quickly afterwards, so this wasn't
caught.

But the dummy interface is somewhat special in that it calls
alloc_netdev() with a priv size of 0. So every netdev_priv() dereference
is invalid, and we get this when we emit a NETDEV_PRECHANGEUPPER event
with a VLAN as its new upper:

$ ip link add dummy1 type dummy
$ ip link add link dummy1 name dummy1.100 type vlan id 100
[   43.309174] ==================================================================
[   43.316456] BUG: KASAN: slab-out-of-bounds in dsa_user_prechangeupper+0x30/0xe8
[   43.323835] Read of size 8 at addr ffff3f86481d2990 by task ip/374
[   43.330058]
[   43.342436] Call trace:
[   43.366542]  dsa_user_prechangeupper+0x30/0xe8
[   43.371024]  dsa_user_netdevice_event+0xb38/0xee8
[   43.375768]  notifier_call_chain+0xa4/0x210
[   43.379985]  raw_notifier_call_chain+0x24/0x38
[   43.384464]  __netdev_upper_dev_link+0x3ec/0x5d8
[   43.389120]  netdev_upper_dev_link+0x70/0xa8
[   43.393424]  register_vlan_dev+0x1bc/0x310
[   43.397554]  vlan_newlink+0x210/0x248
[   43.401247]  rtnl_newlink+0x9fc/0xe30
[   43.404942]  rtnetlink_rcv_msg+0x378/0x580

Avoid the kernel oops by dereferencing after the type check, as customary.</Note>
    </Notes>
    <CVE>CVE-2024-26596</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tracing/timerlat: Move hrtimer_init to timerlat_fd open()

Currently, the timerlat's hrtimer is initialized at the first read of
timerlat_fd, and destroyed at close(). It works, but it causes an error
if the user program open() and close() the file without reading.

Here's an example:

 # echo NO_OSNOISE_WORKLOAD &gt; /sys/kernel/debug/tracing/osnoise/options
 # echo timerlat &gt; /sys/kernel/debug/tracing/current_tracer

 # cat &lt;&lt;EOF &gt; ./timerlat_load.py
 # !/usr/bin/env python3

 timerlat_fd = open("/sys/kernel/tracing/osnoise/per_cpu/cpu0/timerlat_fd", 'r')
 timerlat_fd.close();
 EOF

 # ./taskset -c 0 ./timerlat_load.py
&lt;BOOM&gt;

 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: 0000 [#1] PREEMPT SMP NOPTI
 CPU: 1 PID: 2673 Comm: python3 Not tainted 6.6.13-200.fc39.x86_64 #1
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014
 RIP: 0010:hrtimer_active+0xd/0x50
 Code: 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 48 8b 57 30 &lt;8b&gt; 42 10 a8 01 74 09 f3 90 8b 42 10 a8 01 75 f7 80 7f 38 00 75 1d
 RSP: 0018:ffffb031009b7e10 EFLAGS: 00010286
 RAX: 000000000002db00 RBX: ffff9118f786db08 RCX: 0000000000000000
 RDX: 0000000000000000 RSI: ffff9117a0e64400 RDI: ffff9118f786db08
 RBP: ffff9118f786db80 R08: ffff9117a0ddd420 R09: ffff9117804d4f70
 R10: 0000000000000000 R11: 0000000000000000 R12: ffff9118f786db08
 R13: ffff91178fdd5e20 R14: ffff9117840978c0 R15: 0000000000000000
 FS:  00007f2ffbab1740(0000) GS:ffff9118f7840000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 00000001b402e000 CR4: 0000000000750ee0
 PKRU: 55555554
 Call Trace:
  &lt;TASK&gt;
  ? __die+0x23/0x70
  ? page_fault_oops+0x171/0x4e0
  ? srso_alias_return_thunk+0x5/0x7f
  ? avc_has_extended_perms+0x237/0x520
  ? exc_page_fault+0x7f/0x180
  ? asm_exc_page_fault+0x26/0x30
  ? hrtimer_active+0xd/0x50
  hrtimer_cancel+0x15/0x40
  timerlat_fd_release+0x48/0xe0
  __fput+0xf5/0x290
  __x64_sys_close+0x3d/0x80
  do_syscall_64+0x60/0x90
  ? srso_alias_return_thunk+0x5/0x7f
  ? __x64_sys_ioctl+0x72/0xd0
  ? srso_alias_return_thunk+0x5/0x7f
  ? syscall_exit_to_user_mode+0x2b/0x40
  ? srso_alias_return_thunk+0x5/0x7f
  ? do_syscall_64+0x6c/0x90
  ? srso_alias_return_thunk+0x5/0x7f
  ? exit_to_user_mode_prepare+0x142/0x1f0
  ? srso_alias_return_thunk+0x5/0x7f
  ? syscall_exit_to_user_mode+0x2b/0x40
  ? srso_alias_return_thunk+0x5/0x7f
  ? do_syscall_64+0x6c/0x90
  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
 RIP: 0033:0x7f2ffb321594
 Code: 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 80 3d d5 cd 0d 00 00 74 13 b8 03 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 3c c3 0f 1f 00 55 48 89 e5 48 83 ec 10 89 7d
 RSP: 002b:00007ffe8d8eef18 EFLAGS: 00000202 ORIG_RAX: 0000000000000003
 RAX: ffffffffffffffda RBX: 00007f2ffba4e668 RCX: 00007f2ffb321594
 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
 RBP: 00007ffe8d8eef40 R08: 0000000000000000 R09: 0000000000000000
 R10: 55c926e3167eae79 R11: 0000000000000202 R12: 0000000000000003
 R13: 00007ffe8d8ef030 R14: 0000000000000000 R15: 00007f2ffba4e668
  &lt;/TASK&gt;
 CR2: 0000000000000010
 ---[ end trace 0000000000000000 ]---

Move hrtimer_init to timerlat_fd open() to avoid this problem.</Note>
    </Notes>
    <CVE>CVE-2024-26703</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dccp/tcp: Unhash sk from ehash for tb2 alloc failure after check_estalblished().

syzkaller reported a warning [0] in inet_csk_destroy_sock() with no
repro.

  WARN_ON(inet_sk(sk)-&gt;inet_num &amp;&amp; !inet_csk(sk)-&gt;icsk_bind_hash);

However, the syzkaller's log hinted that connect() failed just before
the warning due to FAULT_INJECTION.  [1]

When connect() is called for an unbound socket, we search for an
available ephemeral port.  If a bhash bucket exists for the port, we
call __inet_check_established() or __inet6_check_established() to check
if the bucket is reusable.

If reusable, we add the socket into ehash and set inet_sk(sk)-&gt;inet_num.

Later, we look up the corresponding bhash2 bucket and try to allocate
it if it does not exist.

Although it rarely occurs in real use, if the allocation fails, we must
revert the changes by check_established().  Otherwise, an unconnected
socket could illegally occupy an ehash entry.

Note that we do not put tw back into ehash because sk might have
already responded to a packet for tw and it would be better to free
tw earlier under such memory presure.

[0]:
WARNING: CPU: 0 PID: 350830 at net/ipv4/inet_connection_sock.c:1193 inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193)
Modules linked in:
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
RIP: 0010:inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193)
Code: 41 5c 41 5d 41 5e e9 2d 4a 3d fd e8 28 4a 3d fd 48 89 ef e8 f0 cd 7d ff 5b 5d 41 5c 41 5d 41 5e e9 13 4a 3d fd e8 0e 4a 3d fd &lt;0f&gt; 0b e9 61 fe ff ff e8 02 4a 3d fd 4c 89 e7 be 03 00 00 00 e8 05
RSP: 0018:ffffc9000b21fd38 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000009e78 RCX: ffffffff840bae40
RDX: ffff88806e46c600 RSI: ffffffff840bb012 RDI: ffff88811755cca8
RBP: ffff88811755c880 R08: 0000000000000003 R09: 0000000000000000
R10: 0000000000009e78 R11: 0000000000000000 R12: ffff88811755c8e0
R13: ffff88811755c892 R14: ffff88811755c918 R15: 0000000000000000
FS:  00007f03e5243800(0000) GS:ffff88811ae00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b32f21000 CR3: 0000000112ffe001 CR4: 0000000000770ef0
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 ? inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193)
 dccp_close (net/dccp/proto.c:1078)
 inet_release (net/ipv4/af_inet.c:434)
 __sock_release (net/socket.c:660)
 sock_close (net/socket.c:1423)
 __fput (fs/file_table.c:377)
 __fput_sync (fs/file_table.c:462)
 __x64_sys_close (fs/open.c:1557 fs/open.c:1539 fs/open.c:1539)
 do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
 entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
RIP: 0033:0x7f03e53852bb
Code: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 43 c9 f5 ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 a1 c9 f5 ff 8b 44
RSP: 002b:00000000005dfba0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003
RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f03e53852bb
RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000167c
R10: 0000000008a79680 R11: 0000000000000293 R12: 00007f03e4e43000
R13: 00007f03e4e43170 R14: 00007f03e4e43178 R15: 00007f03e4e43170
 &lt;/TASK&gt;

[1]:
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 0 PID: 350833 Comm: syz-executor.1 Not tainted 6.7.0-12272-g2121c43f88f5 #9
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1))
 should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153)
 should_failslab (mm/slub.c:3748)
 kmem_cache_alloc (mm/slub.c:3763 mm/slub.c:3842 mm/slub.c:3867)
 inet_bind2_bucket_create 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-26741</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

md: Don't ignore suspended array in md_check_recovery()

mddev_suspend() never stop sync_thread, hence it doesn't make sense to
ignore suspended array in md_check_recovery(), which might cause
sync_thread can't be unregistered.

After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following
hang can be triggered by test shell/integrity-caching.sh:

1) suspend the array:
raid_postsuspend
 mddev_suspend

2) stop the array:
raid_dtr
 md_stop
  __md_stop_writes
   stop_sync_thread
    set_bit(MD_RECOVERY_INTR, &amp;mddev-&gt;recovery);
    md_wakeup_thread_directly(mddev-&gt;sync_thread);
    wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &amp;mddev-&gt;recovery))

3) sync thread done:
md_do_sync
 set_bit(MD_RECOVERY_DONE, &amp;mddev-&gt;recovery);
 md_wakeup_thread(mddev-&gt;thread);

4) daemon thread can't unregister sync thread:
md_check_recovery
 if (mddev-&gt;suspended)
   return; -&gt; return directly
 md_read_sync_thread
 clear_bit(MD_RECOVERY_RUNNING, &amp;mddev-&gt;recovery);
 -&gt; MD_RECOVERY_RUNNING can't be cleared, hence step 2 hang;

This problem is not just related to dm-raid, fix it by ignoring
suspended array in md_check_recovery(). And follow up patches will
improve dm-raid better to frozen sync thread during suspend.</Note>
    </Notes>
    <CVE>CVE-2024-26758</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cxl/pci: Fix disabling memory if DVSEC CXL Range does not match a CFMWS window

The Linux CXL subsystem is built on the assumption that HPA == SPA.
That is, the host physical address (HPA) the HDM decoder registers are
programmed with are system physical addresses (SPA).

During HDM decoder setup, the DVSEC CXL range registers (cxl-3.1,
8.1.3.8) are checked if the memory is enabled and the CXL range is in
a HPA window that is described in a CFMWS structure of the CXL host
bridge (cxl-3.1, 9.18.1.3).

Now, if the HPA is not an SPA, the CXL range does not match a CFMWS
window and the CXL memory range will be disabled then. The HDM decoder
stops working which causes system memory being disabled and further a
system hang during HDM decoder initialization, typically when a CXL
enabled kernel boots.

Prevent a system hang and do not disable the HDM decoder if the
decoder's CXL range is not found in a CFMWS window.

Note the change only fixes a hardware hang, but does not implement
HPA/SPA translation. Support for this can be added in a follow on
patch series.</Note>
    </Notes>
    <CVE>CVE-2024-26761</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: fixed integer types and null check locations

[why]:
issues fixed:
- comparison with wider integer type in loop condition which can cause
infinite loops
- pointer dereference before null check</Note>
    </Notes>
    <CVE>CVE-2024-26767</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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:
   &lt;IRQ&gt;
   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
   &lt;/IRQ&gt;
   &lt;TASK&gt;
   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 &lt;0f&gt; 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
   &lt;/TASK&gt;

  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---</Note>
    </Notes>
    <CVE>CVE-2024-26782</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tcp: Fix refcnt handling in __inet_hash_connect().

syzbot reported a warning in sk_nulls_del_node_init_rcu().

The commit 66b60b0c8c4a ("dccp/tcp: Unhash sk from ehash for tb2 alloc
failure after check_estalblished().") tried to fix an issue that an
unconnected socket occupies an ehash entry when bhash2 allocation fails.

In such a case, we need to revert changes done by check_established(),
which does not hold refcnt when inserting socket into ehash.

So, to revert the change, we need to __sk_nulls_add_node_rcu() instead
of sk_nulls_add_node_rcu().

Otherwise, sock_put() will cause refcnt underflow and leak the socket.

[0]:
WARNING: CPU: 0 PID: 23948 at include/net/sock.h:799 sk_nulls_del_node_init_rcu+0x166/0x1a0 include/net/sock.h:799
Modules linked in:
CPU: 0 PID: 23948 Comm: syz-executor.2 Not tainted 6.8.0-rc6-syzkaller-00159-gc055fc00c07b #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
RIP: 0010:sk_nulls_del_node_init_rcu+0x166/0x1a0 include/net/sock.h:799
Code: e8 7f 71 c6 f7 83 fb 02 7c 25 e8 35 6d c6 f7 4d 85 f6 0f 95 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 1b 6d c6 f7 90 &lt;0f&gt; 0b 90 eb b2 e8 10 6d c6 f7 4c 89 e7 be 04 00 00 00 e8 63 e7 d2
RSP: 0018:ffffc900032d7848 EFLAGS: 00010246
RAX: ffffffff89cd0035 RBX: 0000000000000001 RCX: 0000000000040000
RDX: ffffc90004de1000 RSI: 000000000003ffff RDI: 0000000000040000
RBP: 1ffff1100439ac26 R08: ffffffff89ccffe3 R09: 1ffff1100439ac28
R10: dffffc0000000000 R11: ffffed100439ac29 R12: ffff888021cd6140
R13: dffffc0000000000 R14: ffff88802a9bf5c0 R15: ffff888021cd6130
FS:  00007f3b823f16c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f3b823f0ff8 CR3: 000000004674a000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 __inet_hash_connect+0x140f/0x20b0 net/ipv4/inet_hashtables.c:1139
 dccp_v6_connect+0xcb9/0x1480 net/dccp/ipv6.c:956
 __inet_stream_connect+0x262/0xf30 net/ipv4/af_inet.c:678
 inet_stream_connect+0x65/0xa0 net/ipv4/af_inet.c:749
 __sys_connect_file net/socket.c:2048 [inline]
 __sys_connect+0x2df/0x310 net/socket.c:2065
 __do_sys_connect net/socket.c:2075 [inline]
 __se_sys_connect net/socket.c:2072 [inline]
 __x64_sys_connect+0x7a/0x90 net/socket.c:2072
 do_syscall_64+0xf9/0x240
 entry_SYSCALL_64_after_hwframe+0x6f/0x77
RIP: 0033:0x7f3b8167dda9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 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 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f3b823f10c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 00007f3b817abf80 RCX: 00007f3b8167dda9
RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003
RBP: 00007f3b823f1120 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
R13: 000000000000000b R14: 00007f3b817abf80 R15: 00007ffd3beb57b8
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-26864</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nft_set_pipapo: do not free live element

Pablo reports a crash with large batches of elements with a
back-to-back add/remove pattern.  Quoting Pablo:

  add_elem("00000000") timeout 100 ms
  ...
  add_elem("0000000X") timeout 100 ms
  del_elem("0000000X") &lt;---------------- delete one that was just added
  ...
  add_elem("00005000") timeout 100 ms

  1) nft_pipapo_remove() removes element 0000000X
  Then, KASAN shows a splat.

Looking at the remove function there is a chance that we will drop a
rule that maps to a non-deactivated element.

Removal happens in two steps, first we do a lookup for key k and return the
to-be-removed element and mark it as inactive in the next generation.
Then, in a second step, the element gets removed from the set/map.

The _remove function does not work correctly if we have more than one
element that share the same key.

This can happen if we insert an element into a set when the set already
holds an element with same key, but the element mapping to the existing
key has timed out or is not active in the next generation.

In such case its possible that removal will unmap the wrong element.
If this happens, we will leak the non-deactivated element, it becomes
unreachable.

The element that got deactivated (and will be freed later) will
remain reachable in the set data structure, this can result in
a crash when such an element is retrieved during lookup (stale
pointer).

Add a check that the fully matching key does in fact map to the element
that we have marked as inactive in the deactivation step.
If not, we need to continue searching.

Add a bug/warn trap at the end of the function as well, the remove
function must not ever be called with an invisible/unreachable/non-existent
element.

v2: avoid uneeded temporary variable (Stefano)</Note>
    </Notes>
    <CVE>CVE-2024-26924</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nouveau/dmem: handle kcalloc() allocation failure

The kcalloc() in nouveau_dmem_evict_chunk() will return null if
the physical memory has run out. As a result, if we dereference
src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs
will happen.

Moreover, the GPU is going away. If the kcalloc() fails, we could not
evict all pages mapping a chunk. So this patch adds a __GFP_NOFAIL
flag in kcalloc().

Finally, as there is no need to have physically contiguous memory,
this patch switches kcalloc() to kvcalloc() in order to avoid
failing allocations.</Note>
    </Notes>
    <CVE>CVE-2024-26943</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: esp: fix bad handling of pages from page_pool

When the skb is reorganized during esp_output (!esp-&gt;inline), the pages
coming from the original skb fragments are supposed to be released back
to the system through put_page. But if the skb fragment pages are
originating from a page_pool, calling put_page on them will trigger a
page_pool leak which will eventually result in a crash.

This leak can be easily observed when using CONFIG_DEBUG_VM and doing
ipsec + gre (non offloaded) forwarding:

  BUG: Bad page state in process ksoftirqd/16  pfn:1451b6
  page:00000000de2b8d32 refcount:0 mapcount:0 mapping:0000000000000000 index:0x1451b6000 pfn:0x1451b6
  flags: 0x200000000000000(node=0|zone=2)
  page_type: 0xffffffff()
  raw: 0200000000000000 dead000000000040 ffff88810d23c000 0000000000000000
  raw: 00000001451b6000 0000000000000001 00000000ffffffff 0000000000000000
  page dumped because: page_pool leak
  Modules linked in: ip_gre gre mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay zram zsmalloc fuse [last unloaded: mlx5_core]
  CPU: 16 PID: 96 Comm: ksoftirqd/16 Not tainted 6.8.0-rc4+ #22
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
  Call Trace:
   &lt;TASK&gt;
   dump_stack_lvl+0x36/0x50
   bad_page+0x70/0xf0
   free_unref_page_prepare+0x27a/0x460
   free_unref_page+0x38/0x120
   esp_ssg_unref.isra.0+0x15f/0x200
   esp_output_tail+0x66d/0x780
   esp_xmit+0x2c5/0x360
   validate_xmit_xfrm+0x313/0x370
   ? validate_xmit_skb+0x1d/0x330
   validate_xmit_skb_list+0x4c/0x70
   sch_direct_xmit+0x23e/0x350
   __dev_queue_xmit+0x337/0xba0
   ? nf_hook_slow+0x3f/0xd0
   ip_finish_output2+0x25e/0x580
   iptunnel_xmit+0x19b/0x240
   ip_tunnel_xmit+0x5fb/0xb60
   ipgre_xmit+0x14d/0x280 [ip_gre]
   dev_hard_start_xmit+0xc3/0x1c0
   __dev_queue_xmit+0x208/0xba0
   ? nf_hook_slow+0x3f/0xd0
   ip_finish_output2+0x1ca/0x580
   ip_sublist_rcv_finish+0x32/0x40
   ip_sublist_rcv+0x1b2/0x1f0
   ? ip_rcv_finish_core.constprop.0+0x460/0x460
   ip_list_rcv+0x103/0x130
   __netif_receive_skb_list_core+0x181/0x1e0
   netif_receive_skb_list_internal+0x1b3/0x2c0
   napi_gro_receive+0xc8/0x200
   gro_cell_poll+0x52/0x90
   __napi_poll+0x25/0x1a0
   net_rx_action+0x28e/0x300
   __do_softirq+0xc3/0x276
   ? sort_range+0x20/0x20
   run_ksoftirqd+0x1e/0x30
   smpboot_thread_fn+0xa6/0x130
   kthread+0xcd/0x100
   ? kthread_complete_and_exit+0x20/0x20
   ret_from_fork+0x31/0x50
   ? kthread_complete_and_exit+0x20/0x20
   ret_from_fork_asm+0x11/0x20
   &lt;/TASK&gt;

The suggested fix is to introduce a new wrapper (skb_page_unref) that
covers page refcounting for page_pool pages as well.</Note>
    </Notes>
    <CVE>CVE-2024-26953</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nft_set_pipapo: walk over current view on netlink dump

The generation mask can be updated while netlink dump is in progress.
The pipapo set backend walk iterator cannot rely on it to infer what
view of the datastructure is to be used. Add notation to specify if user
wants to read/update the set.

Based on patch from Florian Westphal.</Note>
    </Notes>
    <CVE>CVE-2024-27017</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vmxnet3: Fix missing reserved tailroom

Use rbi-&gt;len instead of rcd-&gt;len for non-dataring packet.

Found issue:
  XDP_WARN: xdp_update_frame_from_buff(line:278): Driver BUG: missing reserved tailroom
  WARNING: CPU: 0 PID: 0 at net/core/xdp.c:586 xdp_warn+0xf/0x20
  CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W  O       6.5.1 #1
  RIP: 0010:xdp_warn+0xf/0x20
  ...
  ? xdp_warn+0xf/0x20
  xdp_do_redirect+0x15f/0x1c0
  vmxnet3_run_xdp+0x17a/0x400 [vmxnet3]
  vmxnet3_process_xdp+0xe4/0x760 [vmxnet3]
  ? vmxnet3_tq_tx_complete.isra.0+0x21e/0x2c0 [vmxnet3]
  vmxnet3_rq_rx_complete+0x7ad/0x1120 [vmxnet3]
  vmxnet3_poll_rx_only+0x2d/0xa0 [vmxnet3]
  __napi_poll+0x20/0x180
  net_rx_action+0x177/0x390</Note>
    </Notes>
    <CVE>CVE-2024-27026</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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
  |-&gt; dvb_dmxdev_init
        |-&gt; dvb_register_device
  |-&gt; dvb_dmxdev_release
        |-&gt; dvb_unregister_device
              |-&gt; dvb_remove_device
                    |-&gt; dvb_device_put
                          |-&gt; kref_put

When calling dvb_unregister_device, dmxdev-&gt;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.</Note>
    </Notes>
    <CVE>CVE-2024-27043</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: use timestamp to check for set element timeout

Add a timestamp field at the beginning of the transaction, store it
in the nftables per-netns area.

Update set backend .insert, .deactivate and sync gc path to use the
timestamp, this avoids that an element expires while control plane
transaction is still unfinished.

.lookup and .update, which are used from packet path, still use the
current time to check if the element has expired. And .get path and dump
also since this runs lockless under rcu read size lock. Then, there is
async gc which also needs to check the current time since it runs
asynchronously from a workqueue.</Note>
    </Notes>
    <CVE>CVE-2024-27397</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Fixed overflow check in mi_enum_attr()</Note>
    </Notes>
    <CVE>CVE-2024-27407</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: bridge: replace physindev with physinif in nf_bridge_info

An skb can be added to a neigh-&gt;arp_queue while waiting for an arp
reply. Where original skb's skb-&gt;dev can be different to neigh's
neigh-&gt;dev. For instance in case of bridging dnated skb from one veth to
another, the skb would be added to a neigh-&gt;arp_queue of the bridge.

As skb-&gt;dev can be reset back to nf_bridge-&gt;physindev and used, and as
there is no explicit mechanism that prevents this physindev from been
freed under us (for instance neigh_flush_dev doesn't cleanup skbs from
different device's neigh queue) we can crash on e.g. this stack:

arp_process
  neigh_update
    skb = __skb_dequeue(&amp;neigh-&gt;arp_queue)
      neigh_resolve_output(..., skb)
        ...
          br_nf_dev_xmit
            br_nf_pre_routing_finish_bridge_slow
              skb-&gt;dev = nf_bridge-&gt;physindev
              br_handle_frame_finish

Let's use plain ifindex instead of net_device link. To peek into the
original net_device we will use dev_get_by_index_rcu(). Thus either we
get device and are safe to use it or we don't get it and drop skb.</Note>
    </Notes>
    <CVE>CVE-2024-35839</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

erspan: make sure erspan_base_hdr is present in skb-&gt;head

syzbot reported a problem in ip6erspan_rcv() [1]

Issue is that ip6erspan_rcv() (and erspan_rcv()) no longer make
sure erspan_base_hdr is present in skb linear part (skb-&gt;head)
before getting @ver field from it.

Add the missing pskb_may_pull() calls.

v2: Reload iph pointer in erspan_rcv() after pskb_may_pull()
    because skb-&gt;head might have changed.

[1]

 BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]
 BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [inline]
 BUG: KMSAN: uninit-value in ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]
 BUG: KMSAN: uninit-value in gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610
  pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]
  pskb_may_pull include/linux/skbuff.h:2756 [inline]
  ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]
  gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610
  ip6_protocol_deliver_rcu+0x1d4c/0x2ca0 net/ipv6/ip6_input.c:438
  ip6_input_finish net/ipv6/ip6_input.c:483 [inline]
  NF_HOOK include/linux/netfilter.h:314 [inline]
  ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492
  ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586
  dst_input include/net/dst.h:460 [inline]
  ip6_rcv_finish+0x955/0x970 net/ipv6/ip6_input.c:79
  NF_HOOK include/linux/netfilter.h:314 [inline]
  ipv6_rcv+0xde/0x390 net/ipv6/ip6_input.c:310
  __netif_receive_skb_one_core net/core/dev.c:5538 [inline]
  __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5652
  netif_receive_skb_internal net/core/dev.c:5738 [inline]
  netif_receive_skb+0x58/0x660 net/core/dev.c:5798
  tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1549
  tun_get_user+0x5566/0x69e0 drivers/net/tun.c:2002
  tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
  call_write_iter include/linux/fs.h:2108 [inline]
  new_sync_write fs/read_write.c:497 [inline]
  vfs_write+0xb63/0x1520 fs/read_write.c:590
  ksys_write+0x20f/0x4c0 fs/read_write.c:643
  __do_sys_write fs/read_write.c:655 [inline]
  __se_sys_write fs/read_write.c:652 [inline]
  __x64_sys_write+0x93/0xe0 fs/read_write.c:652
 do_syscall_64+0xd5/0x1f0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75

Uninit was created at:
  slab_post_alloc_hook mm/slub.c:3804 [inline]
  slab_alloc_node mm/slub.c:3845 [inline]
  kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888
  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577
  __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668
  alloc_skb include/linux/skbuff.h:1318 [inline]
  alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504
  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795
  tun_alloc_skb drivers/net/tun.c:1525 [inline]
  tun_get_user+0x209a/0x69e0 drivers/net/tun.c:1846
  tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
  call_write_iter include/linux/fs.h:2108 [inline]
  new_sync_write fs/read_write.c:497 [inline]
  vfs_write+0xb63/0x1520 fs/read_write.c:590
  ksys_write+0x20f/0x4c0 fs/read_write.c:643
  __do_sys_write fs/read_write.c:655 [inline]
  __se_sys_write fs/read_write.c:652 [inline]
  __x64_sys_write+0x93/0xe0 fs/read_write.c:652
 do_syscall_64+0xd5/0x1f0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75

CPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0</Note>
    </Notes>
    <CVE>CVE-2024-35888</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

arm64: tlb: Fix TLBI RANGE operand

KVM/arm64 relies on TLBI RANGE feature to flush TLBs when the dirty
pages are collected by VMM and the page table entries become write
protected during live migration. Unfortunately, the operand passed
to the TLBI RANGE instruction isn't correctly sorted out due to the
commit 117940aa6e5f ("KVM: arm64: Define kvm_tlb_flush_vmid_range()").
It leads to crash on the destination VM after live migration because
TLBs aren't flushed completely and some of the dirty pages are missed.

For example, I have a VM where 8GB memory is assigned, starting from
0x40000000 (1GB). Note that the host has 4KB as the base page size.
In the middile of migration, kvm_tlb_flush_vmid_range() is executed
to flush TLBs. It passes MAX_TLBI_RANGE_PAGES as the argument to
__kvm_tlb_flush_vmid_range() and __flush_s2_tlb_range_op(). SCALE#3
and NUM#31, corresponding to MAX_TLBI_RANGE_PAGES, isn't supported
by __TLBI_RANGE_NUM(). In this specific case, -1 has been returned
from __TLBI_RANGE_NUM() for SCALE#3/2/1/0 and rejected by the loop
in the __flush_tlb_range_op() until the variable @scale underflows
and becomes -9, 0xffff708000040000 is set as the operand. The operand
is wrong since it's sorted out by __TLBI_VADDR_RANGE() according to
invalid @scale and @num.

Fix it by extending __TLBI_RANGE_NUM() to support the combination of
SCALE#3 and NUM#31. With the changes, [-1 31] instead of [-1 30] can
be returned from the macro, meaning the TLBs for 0x200000 pages in the
above example can be flushed in one shoot with SCALE#3 and NUM#31. The
macro TLBI_RANGE_MASK is dropped since no one uses it any more. The
comments are also adjusted accordingly.</Note>
    </Notes>
    <CVE>CVE-2024-35980</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm/hugetlb: fix missing hugetlb_lock for resv uncharge

There is a recent report on UFFDIO_COPY over hugetlb:

https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/

350:	lockdep_assert_held(&amp;hugetlb_lock);

Should be an issue in hugetlb but triggered in an userfault context, where
it goes into the unlikely path where two threads modifying the resv map
together.  Mike has a fix in that path for resv uncharge but it looks like
the locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd()
will update the cgroup pointer, so it requires to be called with the lock
held.</Note>
    </Notes>
    <CVE>CVE-2024-36000</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

keys: Fix overwrite of key expiration on instantiation

The expiry time of a key is unconditionally overwritten during
instantiation, defaulting to turn it permanent. This causes a problem
for DNS resolution as the expiration set by user-space is overwritten to
TIME64_MAX, disabling further DNS updates. Fix this by restoring the
condition that key_set_expiry is only called when the pre-parser sets a
specific expiry.</Note>
    </Notes>
    <CVE>CVE-2024-36031</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/sched: taprio: extend minimum interval restriction to entire cycle too

It is possible for syzbot to side-step the restriction imposed by the
blamed commit in the Fixes: tag, because the taprio UAPI permits a
cycle-time different from (and potentially shorter than) the sum of
entry intervals.

We need one more restriction, which is that the cycle time itself must
be larger than N * ETH_ZLEN bit times, where N is the number of schedule
entries. This restriction needs to apply regardless of whether the cycle
time came from the user or was the implicit, auto-calculated value, so
we move the existing "cycle == 0" check outside the "if "(!new-&gt;cycle_time)"
branch. This way covers both conditions and scenarios.

Add a selftest which illustrates the issue triggered by syzbot.</Note>
    </Notes>
    <CVE>CVE-2024-36244</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: relax socket state check at accept time.

Christoph reported the following splat:

WARNING: CPU: 1 PID: 772 at net/ipv4/af_inet.c:761 __inet_accept+0x1f4/0x4a0
Modules linked in:
CPU: 1 PID: 772 Comm: syz-executor510 Not tainted 6.9.0-rc7-g7da7119fe22b #56
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
RIP: 0010:__inet_accept+0x1f4/0x4a0 net/ipv4/af_inet.c:759
Code: 04 38 84 c0 0f 85 87 00 00 00 41 c7 04 24 03 00 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ec b7 da fd &lt;0f&gt; 0b e9 7f fe ff ff e8 e0 b7 da fd 0f 0b e9 fe fe ff ff 89 d9 80
RSP: 0018:ffffc90000c2fc58 EFLAGS: 00010293
RAX: ffffffff836bdd14 RBX: 0000000000000000 RCX: ffff888104668000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: dffffc0000000000 R08: ffffffff836bdb89 R09: fffff52000185f64
R10: dffffc0000000000 R11: fffff52000185f64 R12: dffffc0000000000
R13: 1ffff92000185f98 R14: ffff88810754d880 R15: ffff8881007b7800
FS:  000000001c772880(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fb9fcf2e178 CR3: 00000001045d2002 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 inet_accept+0x138/0x1d0 net/ipv4/af_inet.c:786
 do_accept+0x435/0x620 net/socket.c:1929
 __sys_accept4_file net/socket.c:1969 [inline]
 __sys_accept4+0x9b/0x110 net/socket.c:1999
 __do_sys_accept net/socket.c:2016 [inline]
 __se_sys_accept net/socket.c:2013 [inline]
 __x64_sys_accept+0x7d/0x90 net/socket.c:2013
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0x58/0x100 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x4315f9
Code: fd ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 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 &lt;48&gt; 3d 01 f0 ff ff 0f 83 ab b4 fd ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffdb26d9c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002b
RAX: ffffffffffffffda RBX: 0000000000400300 RCX: 00000000004315f9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004
RBP: 00000000006e1018 R08: 0000000000400300 R09: 0000000000400300
R10: 0000000000400300 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000040cdf0 R14: 000000000040ce80 R15: 0000000000000055
 &lt;/TASK&gt;

The reproducer invokes shutdown() before entering the listener status.
After commit 94062790aedb ("tcp: defer shutdown(SEND_SHUTDOWN) for
TCP_SYN_RECV sockets"), the above causes the child to reach the accept
syscall in FIN_WAIT1 status.

Eric noted we can relax the existing assertion in __inet_accept()</Note>
    </Notes>
    <CVE>CVE-2024-36484</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: fix out-of-bounds access in ops_init

net_alloc_generic is called by net_alloc, which is called without any
locking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. It
is read twice, first to allocate an array, then to set s.len, which is
later used to limit the bounds of the array access.

It is possible that the array is allocated and another thread is
registering a new pernet ops, increments max_gen_ptrs, which is then used
to set s.len with a larger than allocated length for the variable array.

Fix it by reading max_gen_ptrs only once in net_alloc_generic. If
max_gen_ptrs is later incremented, it will be caught in net_assign_generic.</Note>
    </Notes>
    <CVE>CVE-2024-36883</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tipc: fix UAF in error path

Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported
a UAF in the tipc_buf_append() error path:

BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0
linux/net/core/skbuff.c:1183
Read of size 8 at addr ffff88804d2a7c80 by task poc/8034

CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.0-debian-1.16.0-5 04/01/2014
Call Trace:
 &lt;IRQ&gt;
 __dump_stack linux/lib/dump_stack.c:88
 dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106
 print_address_description linux/mm/kasan/report.c:377
 print_report+0xc4/0x620 linux/mm/kasan/report.c:488
 kasan_report+0xda/0x110 linux/mm/kasan/report.c:601
 kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183
 skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026
 skb_release_all linux/net/core/skbuff.c:1094
 __kfree_skb linux/net/core/skbuff.c:1108
 kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144
 kfree_skb linux/./include/linux/skbuff.h:1244
 tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186
 tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324
 tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824
 tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159
 tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390
 udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108
 udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186
 udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346
 __udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422
 ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205
 ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233
 NF_HOOK linux/./include/linux/netfilter.h:314
 NF_HOOK linux/./include/linux/netfilter.h:308
 ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254
 dst_input linux/./include/net/dst.h:461
 ip_rcv_finish linux/net/ipv4/ip_input.c:449
 NF_HOOK linux/./include/linux/netfilter.h:314
 NF_HOOK linux/./include/linux/netfilter.h:308
 ip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569
 __netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534
 __netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648
 process_backlog+0x101/0x6b0 linux/net/core/dev.c:5976
 __napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576
 napi_poll linux/net/core/dev.c:6645
 net_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781
 __do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553
 do_softirq linux/kernel/softirq.c:454
 do_softirq+0xb2/0xf0 linux/kernel/softirq.c:441
 &lt;/IRQ&gt;
 &lt;TASK&gt;
 __local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381
 local_bh_enable linux/./include/linux/bottom_half.h:33
 rcu_read_unlock_bh linux/./include/linux/rcupdate.h:851
 __dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378
 dev_queue_xmit linux/./include/linux/netdevice.h:3169
 neigh_hh_output linux/./include/net/neighbour.h:526
 neigh_output linux/./include/net/neighbour.h:540
 ip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235
 __ip_finish_output linux/net/ipv4/ip_output.c:313
 __ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295
 ip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323
 NF_HOOK_COND linux/./include/linux/netfilter.h:303
 ip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433
 dst_output linux/./include/net/dst.h:451
 ip_local_out linux/net/ipv4/ip_output.c:129
 ip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492
 udp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963
 udp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250
 inet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850
 sock_sendmsg_nosec linux/net/socket.c:730
 __sock_sendmsg linux/net/socket.c:745
 __sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191
 __do_sys_sendto linux/net/socket.c:2203
 __se_sys_sendto linux/net/socket.c:2199
 __x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199
 do_syscall_x64 linux/arch/x86/entry/common.c:52
 do_syscall_
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-36886</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets

TCP_SYN_RECV state is really special, it is only used by
cross-syn connections, mostly used by fuzzers.

In the following crash [1], syzbot managed to trigger a divide
by zero in tcp_rcv_space_adjust()

A socket makes the following state transitions,
without ever calling tcp_init_transfer(),
meaning tcp_init_buffer_space() is also not called.

         TCP_CLOSE
connect()
         TCP_SYN_SENT
         TCP_SYN_RECV
shutdown() -&gt; tcp_shutdown(sk, SEND_SHUTDOWN)
         TCP_FIN_WAIT1

To fix this issue, change tcp_shutdown() to not
perform a TCP_SYN_RECV -&gt; TCP_FIN_WAIT1 transition,
which makes no sense anyway.

When tcp_rcv_state_process() later changes socket state
from TCP_SYN_RECV to TCP_ESTABLISH, then look at
sk-&gt;sk_shutdown to finally enter TCP_FIN_WAIT1 state,
and send a FIN packet from a sane socket state.

This means tcp_send_fin() can now be called from BH
context, and must use GFP_ATOMIC allocations.

[1]
divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
 RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767
Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 &lt;48&gt; f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48
RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246
RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7
R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30
R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da
FS:  00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0
Call Trace:
 &lt;TASK&gt;
  tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513
  tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578
  inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680
  sock_recvmsg_nosec net/socket.c:1046 [inline]
  sock_recvmsg+0x109/0x280 net/socket.c:1068
  ____sys_recvmsg+0x1db/0x470 net/socket.c:2803
  ___sys_recvmsg net/socket.c:2845 [inline]
  do_recvmmsg+0x474/0xae0 net/socket.c:2939
  __sys_recvmmsg net/socket.c:3018 [inline]
  __do_sys_recvmmsg net/socket.c:3041 [inline]
  __se_sys_recvmmsg net/socket.c:3034 [inline]
  __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7faeb6363db9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 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 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9
RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005
RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c
R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001</Note>
    </Notes>
    <CVE>CVE-2024-36905</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

blk-iocost: do not WARN if iocg was already offlined

In iocg_pay_debt(), warn is triggered if 'active_list' is empty, which
is intended to confirm iocg is active when it has debt. However, warn
can be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn()
is run at that time:

  WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190
  Call trace:
  iocg_pay_debt+0x14c/0x190
  iocg_kick_waitq+0x438/0x4c0
  iocg_waitq_timer_fn+0xd8/0x130
  __run_hrtimer+0x144/0x45c
  __hrtimer_run_queues+0x16c/0x244
  hrtimer_interrupt+0x2cc/0x7b0

The warn in this situation is meaningless. Since this iocg is being
removed, the state of the 'active_list' is irrelevant, and 'waitq_timer'
is canceled after removing 'active_list' in ioc_pd_free(), which ensures
iocg is freed after iocg_waitq_timer_fn() returns.

Therefore, add the check if iocg was already offlined to avoid warn
when removing a blkcg or disk.</Note>
    </Notes>
    <CVE>CVE-2024-36908</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfc: llcp: fix nfc_llcp_setsockopt() unsafe copies

syzbot reported unsafe calls to copy_from_sockptr() [1]

Use copy_safe_from_sockptr() instead.

[1]

BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
 BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]
 BUG: KASAN: slab-out-of-bounds in nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255
Read of size 4 at addr ffff88801caa1ec3 by task syz-executor459/5078

CPU: 0 PID: 5078 Comm: syz-executor459 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
 &lt;TASK&gt;
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
  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
  copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
  copy_from_sockptr include/linux/sockptr.h:55 [inline]
  nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255
  do_sock_setsockopt+0x3b1/0x720 net/socket.c:2311
  __sys_setsockopt+0x1ae/0x250 net/socket.c:2334
  __do_sys_setsockopt net/socket.c:2343 [inline]
  __se_sys_setsockopt net/socket.c:2340 [inline]
  __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
 do_syscall_64+0xfd/0x240
 entry_SYSCALL_64_after_hwframe+0x6d/0x75
RIP: 0033:0x7f7fac07fd89
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 18 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 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fff660eb788 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f7fac07fd89
RDX: 0000000000000000 RSI: 0000000000000118 RDI: 0000000000000004
RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000000
R10: 0000000020000a80 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000</Note>
    </Notes>
    <CVE>CVE-2024-36915</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: mpi3mr: Avoid memcpy field-spanning write WARNING

When the "storcli2 show" command is executed for eHBA-9600, mpi3mr driver
prints this WARNING message:

  memcpy: detected field-spanning write (size 128) of single field "bsg_reply_buf-&gt;reply_buf" at drivers/scsi/mpi3mr/mpi3mr_app.c:1658 (size 1)
  WARNING: CPU: 0 PID: 12760 at drivers/scsi/mpi3mr/mpi3mr_app.c:1658 mpi3mr_bsg_request+0x6b12/0x7f10 [mpi3mr]

The cause of the WARN is 128 bytes memcpy to the 1 byte size array "__u8
replay_buf[1]" in the struct mpi3mr_bsg_in_reply_buf. The array is intended
to be a flexible length array, so the WARN is a false positive.

To suppress the WARN, remove the constant number '1' from the array
declaration and clarify that it has flexible length. Also, adjust the
memory allocation size to match the change.</Note>
    </Notes>
    <CVE>CVE-2024-36920</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipv4: Fix uninit-value access in __ip_make_skb()

KMSAN reported uninit-value access in __ip_make_skb() [1].  __ip_make_skb()
tests HDRINCL to know if the skb has icmphdr. However, HDRINCL can cause a
race condition. If calling setsockopt(2) with IP_HDRINCL changes HDRINCL
while __ip_make_skb() is running, the function will access icmphdr in the
skb even if it is not included. This causes the issue reported by KMSAN.

Check FLOWI_FLAG_KNOWN_NH on fl4-&gt;flowi4_flags instead of testing HDRINCL
on the socket.

Also, fl4-&gt;fl4_icmp_type and fl4-&gt;fl4_icmp_code are not initialized. These
are union in struct flowi4 and are implicitly initialized by
flowi4_init_output(), but we should not rely on specific union layout.

Initialize these explicitly in raw_sendmsg().

[1]
BUG: KMSAN: uninit-value in __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481
 __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481
 ip_finish_skb include/net/ip.h:243 [inline]
 ip_push_pending_frames+0x4c/0x5c0 net/ipv4/ip_output.c:1508
 raw_sendmsg+0x2381/0x2690 net/ipv4/raw.c:654
 inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg+0x274/0x3c0 net/socket.c:745
 __sys_sendto+0x62c/0x7b0 net/socket.c:2191
 __do_sys_sendto net/socket.c:2203 [inline]
 __se_sys_sendto net/socket.c:2199 [inline]
 __x64_sys_sendto+0x130/0x200 net/socket.c:2199
 do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x6d/0x75

Uninit was created at:
 slab_post_alloc_hook mm/slub.c:3804 [inline]
 slab_alloc_node mm/slub.c:3845 [inline]
 kmem_cache_alloc_node+0x5f6/0xc50 mm/slub.c:3888
 kmalloc_reserve+0x13c/0x4a0 net/core/skbuff.c:577
 __alloc_skb+0x35a/0x7c0 net/core/skbuff.c:668
 alloc_skb include/linux/skbuff.h:1318 [inline]
 __ip_append_data+0x49ab/0x68c0 net/ipv4/ip_output.c:1128
 ip_append_data+0x1e7/0x260 net/ipv4/ip_output.c:1365
 raw_sendmsg+0x22b1/0x2690 net/ipv4/raw.c:648
 inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg+0x274/0x3c0 net/socket.c:745
 __sys_sendto+0x62c/0x7b0 net/socket.c:2191
 __do_sys_sendto net/socket.c:2203 [inline]
 __se_sys_sendto net/socket.c:2199 [inline]
 __x64_sys_sendto+0x130/0x200 net/socket.c:2199
 do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x6d/0x75

CPU: 1 PID: 15709 Comm: syz-executor.7 Not tainted 6.8.0-11567-gb3603fcb79b1 #25
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014</Note>
    </Notes>
    <CVE>CVE-2024-36927</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tipc: fix a possible memleak in tipc_buf_append

__skb_linearize() doesn't free the skb when it fails, so move
'*buf = NULL' after __skb_linearize(), so that the skb can be
freed on the err path.</Note>
    </Notes>
    <CVE>CVE-2024-36954</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()

l2cap_le_flowctl_init() can cause both div-by-zero and an integer
overflow since hdev-&gt;le_mtu may not fall in the valid range.

Move MTU from hci_dev to hci_conn to validate MTU and stop the connection
process earlier if MTU is invalid.
Also, add a missing validation in read_buffer_size() and make it return
an error value if the validation fails.
Now hci_conn_add() returns ERR_PTR() as it can fail due to the both a
kzalloc failure and invalid MTU value.

divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G        W          6.9.0-rc5+ #20
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Workqueue: hci0 hci_rx_work
RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547
Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c
89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 &lt;66&gt; f7 f3 89 c3 ff c3 4d 8d
b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42
RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246
RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000
RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f
RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa
R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084
R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000
FS:  0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline]
 l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline]
 l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline]
 l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809
 l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506
 hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline]
 hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176
 process_one_work kernel/workqueue.c:3254 [inline]
 process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335
 worker_thread+0x926/0xe70 kernel/workqueue.c:3416
 kthread+0x2e3/0x380 kernel/kthread.c:388
 ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
 &lt;/TASK&gt;
Modules linked in:
---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2024-36968</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

rcu: Fix buffer overflow in print_cpu_stall_info()

The rcuc-starvation output from print_cpu_stall_info() might overflow the
buffer if there is a huge difference in jiffies difference.  The situation
might seem improbable, but computers sometimes get very confused about
time, which can result in full-sized integers, and, in this case,
buffer overflow.

Also, the unsigned jiffies difference is printed using %ld, which is
normally for signed integers.  This is intentional for debugging purposes,
but it is not obvious from the code.

This commit therefore changes sprintf() to snprintf() and adds a
clarifying comment about intention of %ld format.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2024-38576</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow

There is a possibility of buffer overflow in
show_rcu_tasks_trace_gp_kthread() if counters, passed
to sprintf() are huge. Counter numbers, needed for this
are unrealistically high, but buffer overflow is still
possible.

Use snprintf() with buffer size instead of sprintf().

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2024-38577</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netrom: fix possible dead-lock in nr_rt_ioctl()

syzbot loves netrom, and found a possible deadlock in nr_rt_ioctl [1]

Make sure we always acquire nr_node_list_lock before nr_node_lock(nr_node)

[1]
WARNING: possible circular locking dependency detected
6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted
------------------------------------------------------
syz-executor350/5129 is trying to acquire lock:
 ffff8880186e2070 (&amp;nr_node-&gt;node_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
 ffff8880186e2070 (&amp;nr_node-&gt;node_lock){+...}-{2:2}, at: nr_node_lock include/net/netrom.h:152 [inline]
 ffff8880186e2070 (&amp;nr_node-&gt;node_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:464 [inline]
 ffff8880186e2070 (&amp;nr_node-&gt;node_lock){+...}-{2:2}, at: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697

but task is already holding lock:
 ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
 ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline]
 ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-&gt; #1 (nr_node_list_lock){+...}-{2:2}:
        lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
        __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]
        _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178
        spin_lock_bh include/linux/spinlock.h:356 [inline]
        nr_remove_node net/netrom/nr_route.c:299 [inline]
        nr_del_node+0x4b4/0x820 net/netrom/nr_route.c:355
        nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683
        sock_do_ioctl+0x158/0x460 net/socket.c:1222
        sock_ioctl+0x629/0x8e0 net/socket.c:1341
        vfs_ioctl fs/ioctl.c:51 [inline]
        __do_sys_ioctl fs/ioctl.c:904 [inline]
        __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
        do_syscall_x64 arch/x86/entry/common.c:52 [inline]
        do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
       entry_SYSCALL_64_after_hwframe+0x77/0x7f

-&gt; #0 (&amp;nr_node-&gt;node_lock){+...}-{2:2}:
        check_prev_add kernel/locking/lockdep.c:3134 [inline]
        check_prevs_add kernel/locking/lockdep.c:3253 [inline]
        validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869
        __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137
        lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
        __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]
        _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178
        spin_lock_bh include/linux/spinlock.h:356 [inline]
        nr_node_lock include/net/netrom.h:152 [inline]
        nr_dec_obs net/netrom/nr_route.c:464 [inline]
        nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697
        sock_do_ioctl+0x158/0x460 net/socket.c:1222
        sock_ioctl+0x629/0x8e0 net/socket.c:1341
        vfs_ioctl fs/ioctl.c:51 [inline]
        __do_sys_ioctl fs/ioctl.c:904 [inline]
        __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
        do_syscall_x64 arch/x86/entry/common.c:52 [inline]
        do_syscall_64+0xf5/0x240 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(nr_node_list_lock);
                               lock(&amp;nr_node-&gt;node_lock);
                               lock(nr_node_list_lock);
  lock(&amp;nr_node-&gt;node_lock);

 *** DEADLOCK ***

1 lock held by syz-executor350/5129:
  #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
  #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline]
  #0: ffffffff8f70
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-38589</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

jffs2: prevent xattr node from overflowing the eraseblock

Add a check to make sure that the requested xattr node size is no larger
than the eraseblock minus the cleanmarker.

Unlike the usual inode nodes, the xattr nodes aren't split into parts
and spread across multiple eraseblocks, which means that a xattr node
must not occupy more than one eraseblock. If the requested xattr value is
too large, the xattr node can spill onto the next eraseblock, overwriting
the nodes and causing errors such as:

jffs2: argh. node added in wrong place at 0x0000b050(2)
jffs2: nextblock 0x0000a000, expected at 0000b00c
jffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050,
read=0xfc892c93, calc=0x000000
jffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed
at 0x01e00c. {848f,2fc4,0fef511f,59a3d171}
jffs2: Node at 0x0000000c with length 0x00001044 would run over the
end of the erase block
jffs2: Perhaps the file system was created with the wrong erase size?
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found
at 0x00000010: 0x1044 instead

This breaks the filesystem and can lead to KASAN crashes such as:

BUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0
Read of size 4 at addr ffff88802c31e914 by task repro/830
CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS Arch Linux 1.16.3-1-1 04/01/2014
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0xc6/0x120
 print_report+0xc4/0x620
 ? __virt_addr_valid+0x308/0x5b0
 kasan_report+0xc1/0xf0
 ? jffs2_sum_add_kvec+0x125e/0x15d0
 ? jffs2_sum_add_kvec+0x125e/0x15d0
 jffs2_sum_add_kvec+0x125e/0x15d0
 jffs2_flash_direct_writev+0xa8/0xd0
 jffs2_flash_writev+0x9c9/0xef0
 ? __x64_sys_setxattr+0xc4/0x160
 ? do_syscall_64+0x69/0x140
 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
 [...]

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.</Note>
    </Notes>
    <CVE>CVE-2024-38599</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

kdb: Fix buffer overflow during tab-complete

Currently, when the user attempts symbol completion with the Tab key, kdb
will use strncpy() to insert the completed symbol into the command buffer.
Unfortunately it passes the size of the source buffer rather than the
destination to strncpy() with predictably horrible results. Most obviously
if the command buffer is already full but cp, the cursor position, is in
the middle of the buffer, then we will write past the end of the supplied
buffer.

Fix this by replacing the dubious strncpy() calls with memmove()/memcpy()
calls plus explicit boundary checks to make sure we have enough space
before we start moving characters around.</Note>
    </Notes>
    <CVE>CVE-2024-39480</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm/huge_memory: don't unpoison huge_zero_folio

When I did memory failure tests recently, below panic occurs:

 kernel BUG at include/linux/mm.h:1135!
 invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
 CPU: 9 PID: 137 Comm: kswapd1 Not tainted 6.9.0-rc4-00491-gd5ce28f156fe-dirty #14
 RIP: 0010:shrink_huge_zero_page_scan+0x168/0x1a0
 RSP: 0018:ffff9933c6c57bd0 EFLAGS: 00000246
 RAX: 000000000000003e RBX: 0000000000000000 RCX: ffff88f61fc5c9c8
 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff88f61fc5c9c0
 RBP: ffffcd7c446b0000 R08: ffffffff9a9405f0 R09: 0000000000005492
 R10: 00000000000030ea R11: ffffffff9a9405f0 R12: 0000000000000000
 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88e703c4ac00
 FS:  0000000000000000(0000) GS:ffff88f61fc40000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 000055f4da6e9878 CR3: 0000000c71048000 CR4: 00000000000006f0
 Call Trace:
  &lt;TASK&gt;
  do_shrink_slab+0x14f/0x6a0
  shrink_slab+0xca/0x8c0
  shrink_node+0x2d0/0x7d0
  balance_pgdat+0x33a/0x720
  kswapd+0x1f3/0x410
  kthread+0xd5/0x100
  ret_from_fork+0x2f/0x50
  ret_from_fork_asm+0x1a/0x30
  &lt;/TASK&gt;
 Modules linked in: mce_inject hwpoison_inject
 ---[ end trace 0000000000000000 ]---
 RIP: 0010:shrink_huge_zero_page_scan+0x168/0x1a0
 RSP: 0018:ffff9933c6c57bd0 EFLAGS: 00000246
 RAX: 000000000000003e RBX: 0000000000000000 RCX: ffff88f61fc5c9c8
 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff88f61fc5c9c0
 RBP: ffffcd7c446b0000 R08: ffffffff9a9405f0 R09: 0000000000005492
 R10: 00000000000030ea R11: ffffffff9a9405f0 R12: 0000000000000000
 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88e703c4ac00
 FS:  0000000000000000(0000) GS:ffff88f61fc40000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 000055f4da6e9878 CR3: 0000000c71048000 CR4: 00000000000006f0

The root cause is that HWPoison flag will be set for huge_zero_folio
without increasing the folio refcnt.  But then unpoison_memory() will
decrease the folio refcnt unexpectedly as it appears like a successfully
hwpoisoned folio leading to VM_BUG_ON_PAGE(page_ref_count(page) == 0) when
releasing huge_zero_folio.

Skip unpoisoning huge_zero_folio in unpoison_memory() to fix this issue. 
We're not prepared to unpoison huge_zero_folio yet.</Note>
    </Notes>
    <CVE>CVE-2024-40914</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry()

xattr in ocfs2 maybe 'non-indexed', which saved with additional space
requested.  It's better to check if the memory is out of bound before
memcmp, although this possibility mainly comes from crafted poisonous
images.</Note>
    </Notes>
    <CVE>CVE-2024-41016</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sched/deadline: Fix task_struct reference leak

During the execution of the following stress test with linux-rt:

stress-ng --cyclic 30 --timeout 30 --minimize --quiet

kmemleak frequently reported a memory leak concerning the task_struct:

unreferenced object 0xffff8881305b8000 (size 16136):
  comm "stress-ng", pid 614, jiffies 4294883961 (age 286.412s)
  object hex dump (first 32 bytes):
    02 40 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  ................
  debug hex dump (first 16 bytes):
    53 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00  S...............
  backtrace:
    [&lt;00000000046b6790&gt;] dup_task_struct+0x30/0x540
    [&lt;00000000c5ca0f0b&gt;] copy_process+0x3d9/0x50e0
    [&lt;00000000ced59777&gt;] kernel_clone+0xb0/0x770
    [&lt;00000000a50befdc&gt;] __do_sys_clone+0xb6/0xf0
    [&lt;000000001dbf2008&gt;] do_syscall_64+0x5d/0xf0
    [&lt;00000000552900ff&gt;] entry_SYSCALL_64_after_hwframe+0x6e/0x76

The issue occurs in start_dl_timer(), which increments the task_struct
reference count and sets a timer. The timer callback, dl_task_timer,
is supposed to decrement the reference count upon expiration. However,
if enqueue_task_dl() is called before the timer expires and cancels it,
the reference count is not decremented, leading to the leak.

This patch fixes the reference leak by ensuring the task_struct
reference count is properly decremented when the timer is canceled.</Note>
    </Notes>
    <CVE>CVE-2024-41023</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: prefer nft_chain_validate

nft_chain_validate already performs loop detection because a cycle will
result in a call stack overflow (ctx-&gt;level &gt;= NFT_JUMP_STACK_SIZE).

It also follows maps via -&gt;validate callback in nft_lookup, so there
appears no reason to iterate the maps again.

nf_tables_check_loops() and all its helper functions can be removed.
This improves ruleset load time significantly, from 23s down to 12s.

This also fixes a crash bug. Old loop detection code can result in
unbounded recursion:

BUG: TASK stack guard page was hit at ....
Oops: stack guard page: 0000 [#1] PREEMPT SMP KASAN
CPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1
[..]

with a suitable ruleset during validation of register stores.

I can't see any actual reason to attempt to check for this from
nft_validate_register_store(), at this point the transaction is still in
progress, so we don't have a full picture of the rule graph.

For nf-next it might make sense to either remove it or make this depend
on table-&gt;validate_state in case we could catch an error earlier
(for improved error reporting to userspace).</Note>
    </Notes>
    <CVE>CVE-2024-41042</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i40e: Fix XDP program unloading while removing the driver

The commit 6533e558c650 ("i40e: Fix reset path while removing
the driver") introduced a new PF state "__I40E_IN_REMOVE" to block
modifying the XDP program while the driver is being removed.
Unfortunately, such a change is useful only if the ".ndo_bpf()"
callback was called out of the rmmod context because unloading the
existing XDP program is also a part of driver removing procedure.
In other words, from the rmmod context the driver is expected to
unload the XDP program without reporting any errors. Otherwise,
the kernel warning with callstack is printed out to dmesg.

Example failing scenario:
 1. Load the i40e driver.
 2. Load the XDP program.
 3. Unload the i40e driver (using "rmmod" command).

The example kernel warning log:

[  +0.004646] WARNING: CPU: 94 PID: 10395 at net/core/dev.c:9290 unregister_netdevice_many_notify+0x7a9/0x870
[...]
[  +0.010959] RIP: 0010:unregister_netdevice_many_notify+0x7a9/0x870
[...]
[  +0.002726] Call Trace:
[  +0.002457]  &lt;TASK&gt;
[  +0.002119]  ? __warn+0x80/0x120
[  +0.003245]  ? unregister_netdevice_many_notify+0x7a9/0x870
[  +0.005586]  ? report_bug+0x164/0x190
[  +0.003678]  ? handle_bug+0x3c/0x80
[  +0.003503]  ? exc_invalid_op+0x17/0x70
[  +0.003846]  ? asm_exc_invalid_op+0x1a/0x20
[  +0.004200]  ? unregister_netdevice_many_notify+0x7a9/0x870
[  +0.005579]  ? unregister_netdevice_many_notify+0x3cc/0x870
[  +0.005586]  unregister_netdevice_queue+0xf7/0x140
[  +0.004806]  unregister_netdev+0x1c/0x30
[  +0.003933]  i40e_vsi_release+0x87/0x2f0 [i40e]
[  +0.004604]  i40e_remove+0x1a1/0x420 [i40e]
[  +0.004220]  pci_device_remove+0x3f/0xb0
[  +0.003943]  device_release_driver_internal+0x19f/0x200
[  +0.005243]  driver_detach+0x48/0x90
[  +0.003586]  bus_remove_driver+0x6d/0xf0
[  +0.003939]  pci_unregister_driver+0x2e/0xb0
[  +0.004278]  i40e_exit_module+0x10/0x5f0 [i40e]
[  +0.004570]  __do_sys_delete_module.isra.0+0x197/0x310
[  +0.005153]  do_syscall_64+0x85/0x170
[  +0.003684]  ? syscall_exit_to_user_mode+0x69/0x220
[  +0.004886]  ? do_syscall_64+0x95/0x170
[  +0.003851]  ? exc_page_fault+0x7e/0x180
[  +0.003932]  entry_SYSCALL_64_after_hwframe+0x71/0x79
[  +0.005064] RIP: 0033:0x7f59dc9347cb
[  +0.003648] Code: 73 01 c3 48 8b 0d 65 16 0c 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 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 35 16 0c 00 f7 d8 64 89 01 48
[  +0.018753] RSP: 002b:00007ffffac99048 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
[  +0.007577] RAX: ffffffffffffffda RBX: 0000559b9bb2f6e0 RCX: 00007f59dc9347cb
[  +0.007140] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 0000559b9bb2f748
[  +0.007146] RBP: 00007ffffac99070 R08: 1999999999999999 R09: 0000000000000000
[  +0.007133] R10: 00007f59dc9a5ac0 R11: 0000000000000206 R12: 0000000000000000
[  +0.007141] R13: 00007ffffac992d8 R14: 0000559b9bb2f6e0 R15: 0000000000000000
[  +0.007151]  &lt;/TASK&gt;
[  +0.002204] ---[ end trace 0000000000000000 ]---

Fix this by checking if the XDP program is being loaded or unloaded.
Then, block only loading a new program while "__I40E_IN_REMOVE" is set.
Also, move testing "__I40E_IN_REMOVE" flag to the beginning of XDP_SETUP
callback to avoid unnecessary operations and checks.</Note>
    </Notes>
    <CVE>CVE-2024-41047</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-41110</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:docker-26.1.5_ce-150000.212.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>critical</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Revert "mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again"

Patch series "mm: Avoid possible overflows in dirty throttling".

Dirty throttling logic assumes dirty limits in page units fit into
32-bits.  This patch series makes sure this is true (see patch 2/2 for
more details).


This patch (of 2):

This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.

The commit is broken in several ways.  Firstly, the removed (u64) cast
from the multiplication will introduce a multiplication overflow on 32-bit
archs if wb_thresh * bg_thresh &gt;= 1&lt;&lt;32 (which is actually common - the
default settings with 4GB of RAM will trigger this).  Secondly, the
div64_u64() is unnecessarily expensive on 32-bit archs.  We have
div64_ul() in case we want to be safe &amp; cheap.  Thirdly, if dirty
thresholds are larger than 1&lt;&lt;32 pages, then dirty balancing is going to
blow up in many other spectacular ways anyway so trying to fix one
possible overflow is just moot.</Note>
    </Notes>
    <CVE>CVE-2024-42102</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-42145</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">The UNIX editor Vim prior to version 9.1.0678 has a use-after-free error in argument list handling. When adding a new file to the argument list, this triggers `Buf*` autocommands. If in such an autocommand the buffer that was just opened is closed (including the window where it is shown), this causes the window structure to be freed which contains a reference to the argument list that we are actually modifying. Once the autocommands are completed, the references to the window and argument list are no longer valid and as such cause an use-after-free. Impact is low since the user must either intentionally add some unusual autocommands that wipe a buffer during creation (either manually or by sourcing a malicious plugin), but it will crash Vim. The issue has been fixed as of Vim patch v9.1.0678.</Note>
    </Notes>
    <CVE>CVE-2024-43374</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:vim-9.1.0836-150500.20.18.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:vim-data-common-9.1.0836-150500.20.18.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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-&gt;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).</Note>
    </Notes>
    <CVE>CVE-2024-44932</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: bridge: mcast: wait for previous gc cycles when removing port

syzbot hit a use-after-free[1] which is caused because the bridge doesn't
make sure that all previous garbage has been collected when removing a
port. What happens is:
      CPU 1                   CPU 2
 start gc cycle           remove port
                         acquire gc lock first
 wait for lock
                         call br_multicasg_gc() directly
 acquire lock now but    free port
 the port can be freed
 while grp timers still
 running

Make sure all previous gc cycles have finished by using flush_work before
freeing the port.

[1]
  BUG: KASAN: slab-use-after-free in br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861
  Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699

  CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0
  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024
  Call Trace:
   &lt;IRQ&gt;
   __dump_stack lib/dump_stack.c:88 [inline]
   dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114
   print_address_description mm/kasan/report.c:377 [inline]
   print_report+0xc3/0x620 mm/kasan/report.c:488
   kasan_report+0xd9/0x110 mm/kasan/report.c:601
   br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861
   call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792
   expire_timers kernel/time/timer.c:1843 [inline]
   __run_timers+0x74b/0xaf0 kernel/time/timer.c:2417
   __run_timer_base kernel/time/timer.c:2428 [inline]
   __run_timer_base kernel/time/timer.c:2421 [inline]
   run_timer_base+0x111/0x190 kernel/time/timer.c:2437</Note>
    </Notes>
    <CVE>CVE-2024-44934</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sched/smt: Fix unbalance sched_smt_present dec/inc

I got the following warn report while doing stress test:

jump label: negative count!
WARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0
Call Trace:
 &lt;TASK&gt;
 __static_key_slow_dec_cpuslocked+0x16/0x70
 sched_cpu_deactivate+0x26e/0x2a0
 cpuhp_invoke_callback+0x3ad/0x10d0
 cpuhp_thread_fun+0x3f5/0x680
 smpboot_thread_fn+0x56d/0x8d0
 kthread+0x309/0x400
 ret_from_fork+0x41/0x70
 ret_from_fork_asm+0x1b/0x30
 &lt;/TASK&gt;

Because when cpuset_cpu_inactive() fails in sched_cpu_deactivate(),
the cpu offline failed, but sched_smt_present is decremented before
calling sched_cpu_deactivate(), it leads to unbalanced dec/inc, so
fix it by incrementing sched_smt_present in the error path.</Note>
    </Notes>
    <CVE>CVE-2024-44958</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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-&gt;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.</Note>
    </Notes>
    <CVE>CVE-2024-44964</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: hns3: fix a deadlock problem when config TC during resetting

When config TC during the reset process, may cause a deadlock, the flow is
as below:
                             pf reset start
                                 |
                                 ▼
                              ......
setup tc                         |
    |                            ▼
    ▼                      DOWN: napi_disable()
napi_disable()(skip)             |
    |                            |
    ▼                            ▼
  ......                      ......
    |                            |
    ▼                            |
napi_enable()                    |
                                 ▼
                           UINIT: netif_napi_del()
                                 |
                                 ▼
                              ......
                                 |
                                 ▼
                           INIT: netif_napi_add()
                                 |
                                 ▼
                              ......                 global reset start
                                 |                      |
                                 ▼                      ▼
                           UP: napi_enable()(skip)    ......
                                 |                      |
                                 ▼                      ▼
                              ......                 napi_disable()

In reset process, the driver will DOWN the port and then UINIT, in this
case, the setup tc process will UP the port before UINIT, so cause the
problem. Adds a DOWN process in UINIT to fix it.</Note>
    </Notes>
    <CVE>CVE-2024-44995</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vsock: fix recursive -&gt;recvmsg calls

After a vsock socket has been added to a BPF sockmap, its prot-&gt;recvmsg
has been replaced with vsock_bpf_recvmsg(). Thus the following
recursiion could happen:

vsock_bpf_recvmsg()
 -&gt; __vsock_recvmsg()
  -&gt; vsock_connectible_recvmsg()
   -&gt; prot-&gt;recvmsg()
    -&gt; vsock_bpf_recvmsg() again

We need to fix it by calling the original -&gt;recvmsg() without any BPF
sockmap logic in __vsock_recvmsg().</Note>
    </Notes>
    <CVE>CVE-2024-44996</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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-&gt;enqueue() and then
  the original packet is also dropped.
- If rootq-&gt;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.</Note>
    </Notes>
    <CVE>CVE-2024-45016</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE

copy_fd_bitmaps(new, old, count) is expected to copy the first
count/BITS_PER_LONG bits from old-&gt;full_fds_bits[] and fill
the rest with zeroes.  What it does is copying enough words
(BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest.
That works fine, *if* all bits past the cutoff point are
clear.  Otherwise we are risking garbage from the last word
we'd copied.

For most of the callers that is true - expand_fdtable() has
count equal to old-&gt;max_fds, so there's no open descriptors
past count, let alone fully occupied words in -&gt;open_fds[],
which is what bits in -&gt;full_fds_bits[] correspond to.

The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds),
which is the smallest multiple of BITS_PER_LONG that covers all
opened descriptors below max_fds.  In the common case (copying on
fork()) max_fds is ~0U, so all opened descriptors will be below
it and we are fine, by the same reasons why the call in expand_fdtable()
is safe.

Unfortunately, there is a case where max_fds is less than that
and where we might, indeed, end up with junk in -&gt;full_fds_bits[] -
close_range(from, to, CLOSE_RANGE_UNSHARE) with
	* descriptor table being currently shared
	* 'to' being above the current capacity of descriptor table
	* 'from' being just under some chunk of opened descriptors.
In that case we end up with observably wrong behaviour - e.g. spawn
a child with CLONE_FILES, get all descriptors in range 0..127 open,
then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending
up with descriptor #128, despite #64 being observably not open.

The minimally invasive fix would be to deal with that in dup_fd().
If this proves to add measurable overhead, we can go that way, but
let's try to fix copy_fd_bitmaps() first.

* new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).
* make copy_fd_bitmaps() take the bitmap size in words, rather than
bits; it's 'count' argument is always a multiple of BITS_PER_LONG,
so we are not losing any information, and that way we can use the
same helper for all three bitmaps - compiler will see that count
is a multiple of BITS_PER_LONG for the large ones, so it'll generate
plain memcpy()+memset().

Reproducer added to tools/testing/selftests/core/close_range_test.c</Note>
    </Notes>
    <CVE>CVE-2024-45025</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-45817</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:xen-libs-4.18.4_02-150600.3.15.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-45818</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:xen-libs-4.18.4_02-150600.3.15.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-45819</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:xen-libs-4.18.4_02-150600.3.15.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bonding: change ipsec_lock from spin lock to mutex

In the cited commit, bond-&gt;ipsec_lock is added to protect ipsec_list,
hence xdo_dev_state_add and xdo_dev_state_delete are called inside
this lock. As ipsec_lock is a spin lock and such xfrmdev ops may sleep,
"scheduling while atomic" will be triggered when changing bond's
active slave.

[  101.055189] BUG: scheduling while atomic: bash/902/0x00000200
[  101.055726] Modules linked in:
[  101.058211] CPU: 3 PID: 902 Comm: bash Not tainted 6.9.0-rc4+ #1
[  101.058760] Hardware name:
[  101.059434] Call Trace:
[  101.059436]  &lt;TASK&gt;
[  101.060873]  dump_stack_lvl+0x51/0x60
[  101.061275]  __schedule_bug+0x4e/0x60
[  101.061682]  __schedule+0x612/0x7c0
[  101.062078]  ? __mod_timer+0x25c/0x370
[  101.062486]  schedule+0x25/0xd0
[  101.062845]  schedule_timeout+0x77/0xf0
[  101.063265]  ? asm_common_interrupt+0x22/0x40
[  101.063724]  ? __bpf_trace_itimer_state+0x10/0x10
[  101.064215]  __wait_for_common+0x87/0x190
[  101.064648]  ? usleep_range_state+0x90/0x90
[  101.065091]  cmd_exec+0x437/0xb20 [mlx5_core]
[  101.065569]  mlx5_cmd_do+0x1e/0x40 [mlx5_core]
[  101.066051]  mlx5_cmd_exec+0x18/0x30 [mlx5_core]
[  101.066552]  mlx5_crypto_create_dek_key+0xea/0x120 [mlx5_core]
[  101.067163]  ? bonding_sysfs_store_option+0x4d/0x80 [bonding]
[  101.067738]  ? kmalloc_trace+0x4d/0x350
[  101.068156]  mlx5_ipsec_create_sa_ctx+0x33/0x100 [mlx5_core]
[  101.068747]  mlx5e_xfrm_add_state+0x47b/0xaa0 [mlx5_core]
[  101.069312]  bond_change_active_slave+0x392/0x900 [bonding]
[  101.069868]  bond_option_active_slave_set+0x1c2/0x240 [bonding]
[  101.070454]  __bond_opt_set+0xa6/0x430 [bonding]
[  101.070935]  __bond_opt_set_notify+0x2f/0x90 [bonding]
[  101.071453]  bond_opt_tryset_rtnl+0x72/0xb0 [bonding]
[  101.071965]  bonding_sysfs_store_option+0x4d/0x80 [bonding]
[  101.072567]  kernfs_fop_write_iter+0x10c/0x1a0
[  101.073033]  vfs_write+0x2d8/0x400
[  101.073416]  ? alloc_fd+0x48/0x180
[  101.073798]  ksys_write+0x5f/0xe0
[  101.074175]  do_syscall_64+0x52/0x110
[  101.074576]  entry_SYSCALL_64_after_hwframe+0x4b/0x53

As bond_ipsec_add_sa_all and bond_ipsec_del_sa_all are only called
from bond_change_active_slave, which requires holding the RTNL lock.
And bond_ipsec_add_sa and bond_ipsec_del_sa are xfrm state
xdo_dev_state_add and xdo_dev_state_delete APIs, which are in user
context. So ipsec_lock doesn't have to be spin lock, change it to
mutex, and thus the above issue can be resolved.</Note>
    </Notes>
    <CVE>CVE-2024-46678</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btnxpuart: Fix random crash seen while removing driver

This fixes the random kernel crash seen while removing the driver, when
running the load/unload test over multiple iterations.

1) modprobe btnxpuart
2) hciconfig hci0 reset
3) hciconfig (check hci0 interface up with valid BD address)
4) modprobe -r btnxpuart
Repeat steps 1 to 4

The ps_wakeup() call in btnxpuart_close() schedules the psdata-&gt;work(),
which gets scheduled after module is removed, causing a kernel crash.

This hidden issue got highlighted after enabling Power Save by default
in 4183a7be7700 (Bluetooth: btnxpuart: Enable Power Save feature on
startup)

The new ps_cleanup() deasserts UART break immediately while closing
serdev device, cancels any scheduled ps_work and destroys the ps_lock
mutex.

[   85.884604] Unable to handle kernel paging request at virtual address ffffd4a61638f258
[   85.884624] Mem abort info:
[   85.884625]   ESR = 0x0000000086000007
[   85.884628]   EC = 0x21: IABT (current EL), IL = 32 bits
[   85.884633]   SET = 0, FnV = 0
[   85.884636]   EA = 0, S1PTW = 0
[   85.884638]   FSC = 0x07: level 3 translation fault
[   85.884642] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000041dd0000
[   85.884646] [ffffd4a61638f258] pgd=1000000095fff003, p4d=1000000095fff003, pud=100000004823d003, pmd=100000004823e003, pte=0000000000000000
[   85.884662] Internal error: Oops: 0000000086000007 [#1] PREEMPT SMP
[   85.890932] Modules linked in: algif_hash algif_skcipher af_alg overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce polyval_generic snd_soc_imx_spdif snd_soc_imx_card snd_soc_ak5558 snd_soc_ak4458 caam secvio error snd_soc_fsl_spdif snd_soc_fsl_micfil snd_soc_fsl_sai snd_soc_fsl_utils gpio_ir_recv rc_core fuse [last unloaded: btnxpuart(O)]
[   85.927297] CPU: 1 PID: 67 Comm: kworker/1:3 Tainted: G           O       6.1.36+g937b1be4345a #1
[   85.936176] Hardware name: FSL i.MX8MM EVK board (DT)
[   85.936182] Workqueue: events 0xffffd4a61638f380
[   85.936198] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   85.952817] pc : 0xffffd4a61638f258
[   85.952823] lr : 0xffffd4a61638f258
[   85.952827] sp : ffff8000084fbd70
[   85.952829] x29: ffff8000084fbd70 x28: 0000000000000000 x27: 0000000000000000
[   85.963112] x26: ffffd4a69133f000 x25: ffff4bf1c8540990 x24: ffff4bf215b87305
[   85.963119] x23: ffff4bf215b87300 x22: ffff4bf1c85409d0 x21: ffff4bf1c8540970
[   85.977382] x20: 0000000000000000 x19: ffff4bf1c8540880 x18: 0000000000000000
[   85.977391] x17: 0000000000000000 x16: 0000000000000133 x15: 0000ffffe2217090
[   85.977399] x14: 0000000000000001 x13: 0000000000000133 x12: 0000000000000139
[   85.977407] x11: 0000000000000001 x10: 0000000000000a60 x9 : ffff8000084fbc50
[   85.977417] x8 : ffff4bf215b7d000 x7 : ffff4bf215b83b40 x6 : 00000000000003e8
[   85.977424] x5 : 00000000410fd030 x4 : 0000000000000000 x3 : 0000000000000000
[   85.977432] x2 : 0000000000000000 x1 : ffff4bf1c4265880 x0 : 0000000000000000
[   85.977443] Call trace:
[   85.977446]  0xffffd4a61638f258
[   85.977451]  0xffffd4a61638f3e8
[   85.977455]  process_one_work+0x1d4/0x330
[   85.977464]  worker_thread+0x6c/0x430
[   85.977471]  kthread+0x108/0x10c
[   85.977476]  ret_from_fork+0x10/0x20
[   85.977488] Code: bad PC value
[   85.977491] ---[ end trace 0000000000000000 ]---

Preset since v6.9.11</Note>
    </Notes>
    <CVE>CVE-2024-46680</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pktgen: use cpus_read_lock() in pg_net_init()

I have seen the WARN_ON(smp_processor_id() != cpu) firing
in pktgen_thread_worker() during tests.

We must use cpus_read_lock()/cpus_read_unlock()
around the for_each_online_cpu(cpu) loop.

While we are at it use WARN_ON_ONCE() to avoid a possible syslog flood.</Note>
    </Notes>
    <CVE>CVE-2024-46681</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

apparmor: fix possible NULL pointer dereference

profile-&gt;parent-&gt;dents[AAFS_PROF_DIR] could be NULL only if its parent is made
from __create_missing_ancestors(..) and 'ent-&gt;old' is NULL in
aa_replace_profiles(..).
In that case, it must return an error code and the code, -ENOENT represents
its state that the path of its parent is not existed yet.

BUG: kernel NULL pointer dereference, address: 0000000000000030
PGD 0 P4D 0
PREEMPT SMP PTI
CPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
RIP: 0010:aafs_create.constprop.0+0x7f/0x130
Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc &lt;4d&gt; 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae
RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0
Call Trace:
 &lt;TASK&gt;
 ? show_regs+0x6d/0x80
 ? __die+0x24/0x80
 ? page_fault_oops+0x99/0x1b0
 ? kernelmode_fixup_or_oops+0xb2/0x140
 ? __bad_area_nosemaphore+0x1a5/0x2c0
 ? find_vma+0x34/0x60
 ? bad_area_nosemaphore+0x16/0x30
 ? do_user_addr_fault+0x2a2/0x6b0
 ? exc_page_fault+0x83/0x1b0
 ? asm_exc_page_fault+0x27/0x30
 ? aafs_create.constprop.0+0x7f/0x130
 ? aafs_create.constprop.0+0x51/0x130
 __aafs_profile_mkdir+0x3d6/0x480
 aa_replace_profiles+0x83f/0x1270
 policy_update+0xe3/0x180
 profile_load+0xbc/0x150
 ? rw_verify_area+0x47/0x140
 vfs_write+0x100/0x480
 ? __x64_sys_openat+0x55/0xa0
 ? syscall_exit_to_user_mode+0x86/0x260
 ksys_write+0x73/0x100
 __x64_sys_write+0x19/0x30
 x64_sys_call+0x7e/0x25c0
 do_syscall_64+0x7f/0x180
 entry_SYSCALL_64_after_hwframe+0x78/0x80
RIP: 0033:0x7be9f211c574
Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89
RSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574
RDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004
RBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000
R10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80
R13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30
 &lt;/TASK&gt;
Modules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesas
CR2: 0000000000000030
---[ end trace 0000000000000000 ]---
RIP: 0010:aafs_create.constprop.0+0x7f/0x130
Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc &lt;4d&gt; 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae
RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-46721</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Remove tst_run from lwt_seg6local_prog_ops.

The syzbot reported that the lwt_seg6 related BPF ops can be invoked
via bpf_test_run() without without entering input_action_end_bpf()
first.

Martin KaFai Lau said that self test for BPF_PROG_TYPE_LWT_SEG6LOCAL
probably didn't work since it was introduced in commit 04d4b274e2a
("ipv6: sr: Add seg6local action End.BPF"). The reason is that the
per-CPU variable seg6_bpf_srh_states::srh is never assigned in the self
test case but each BPF function expects it.

Remove test_run for BPF_PROG_TYPE_LWT_SEG6LOCAL.</Note>
    </Notes>
    <CVE>CVE-2024-46754</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ice: protect XDP configuration with a mutex

The main threat to data consistency in ice_xdp() is a possible asynchronous
PF reset. It can be triggered by a user or by TX timeout handler.

XDP setup and PF reset code access the same resources in the following
sections:
* ice_vsi_close() in ice_prepare_for_reset() - already rtnl-locked
* ice_vsi_rebuild() for the PF VSI - not protected
* ice_vsi_open() - already rtnl-locked

With an unfortunate timing, such accesses can result in a crash such as the
one below:

[ +1.999878] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 14
[ +2.002992] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 18
[Mar15 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: transmit queue 14 timed out 80692736 ms
[ +0.000093] ice 0000:b1:00.0 ens801f0np0: tx_timeout: VSI_num: 6, Q 14, NTC: 0x0, HW_HEAD: 0x0, NTU: 0x0, INT: 0x4000001
[ +0.000012] ice 0000:b1:00.0 ens801f0np0: tx_timeout recovery level 1, txqueue 14
[ +0.394718] ice 0000:b1:00.0: PTP reset successful
[ +0.006184] BUG: kernel NULL pointer dereference, address: 0000000000000098
[ +0.000045] #PF: supervisor read access in kernel mode
[ +0.000023] #PF: error_code(0x0000) - not-present page
[ +0.000023] PGD 0 P4D 0
[ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 Not tainted 6.8.0-rc7 #1
[ +0.000031] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021
[ +0.000036] Workqueue: ice ice_service_task [ice]
[ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [ice]
[...]
[ +0.000013] Call Trace:
[ +0.000016] &lt;TASK&gt;
[ +0.000014] ? __die+0x1f/0x70
[ +0.000029] ? page_fault_oops+0x171/0x4f0
[ +0.000029] ? schedule+0x3b/0xd0
[ +0.000027] ? exc_page_fault+0x7b/0x180
[ +0.000022] ? asm_exc_page_fault+0x22/0x30
[ +0.000031] ? ice_clean_tx_ring+0xa/0xd0 [ice]
[ +0.000194] ice_free_tx_ring+0xe/0x60 [ice]
[ +0.000186] ice_destroy_xdp_rings+0x157/0x310 [ice]
[ +0.000151] ice_vsi_decfg+0x53/0xe0 [ice]
[ +0.000180] ice_vsi_rebuild+0x239/0x540 [ice]
[ +0.000186] ice_vsi_rebuild_by_type+0x76/0x180 [ice]
[ +0.000145] ice_rebuild+0x18c/0x840 [ice]
[ +0.000145] ? delay_tsc+0x4a/0xc0
[ +0.000022] ? delay_tsc+0x92/0xc0
[ +0.000020] ice_do_reset+0x140/0x180 [ice]
[ +0.000886] ice_service_task+0x404/0x1030 [ice]
[ +0.000824] process_one_work+0x171/0x340
[ +0.000685] worker_thread+0x277/0x3a0
[ +0.000675] ? preempt_count_add+0x6a/0xa0
[ +0.000677] ? _raw_spin_lock_irqsave+0x23/0x50
[ +0.000679] ? __pfx_worker_thread+0x10/0x10
[ +0.000653] kthread+0xf0/0x120
[ +0.000635] ? __pfx_kthread+0x10/0x10
[ +0.000616] ret_from_fork+0x2d/0x50
[ +0.000612] ? __pfx_kthread+0x10/0x10
[ +0.000604] ret_from_fork_asm+0x1b/0x30
[ +0.000604] &lt;/TASK&gt;

The previous way of handling this through returning -EBUSY is not viable,
particularly when destroying AF_XDP socket, because the kernel proceeds
with removal anyway.

There is plenty of code between those calls and there is no need to create
a large critical section that covers all of them, same as there is no need
to protect ice_vsi_rebuild() with rtnl_lock().

Add xdp_state_lock mutex to protect ice_vsi_rebuild() and ice_xdp().

Leaving unprotected sections in between would result in two states that
have to be considered:
1. when the VSI is closed, but not yet rebuild
2. when VSI is already rebuild, but not yet open

The latter case is actually already handled through !netif_running() case,
we just need to adjust flag checking a little. The former one is not as
trivial, because between ice_vsi_close() and ice_vsi_rebuild(), a lot of
hardware interaction happens, this can make adding/deleting rings exit
with an error. Luckily, VSI rebuild is pending and can apply new
configuration for us in a managed fashion.

Therefore, add an additional VSI state flag ICE_VSI_REBUILD_PENDING to
indicate that ice_x
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-46765</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ice: move netif_queue_set_napi to rtnl-protected sections

Currently, netif_queue_set_napi() is called from ice_vsi_rebuild() that is
not rtnl-locked when called from the reset. This creates the need to take
the rtnl_lock just for a single function and complicates the
synchronization with .ndo_bpf. At the same time, there no actual need to
fill napi-to-queue information at this exact point.

Fill napi-to-queue information when opening the VSI and clear it when the
VSI is being closed. Those routines are already rtnl-locked.

Also, rewrite napi-to-queue assignment in a way that prevents inclusion of
XDP queues, as this leads to out-of-bounds writes, such as one below.

[  +0.000004] BUG: KASAN: slab-out-of-bounds in netif_queue_set_napi+0x1c2/0x1e0
[  +0.000012] Write of size 8 at addr ffff889881727c80 by task bash/7047
[  +0.000006] CPU: 24 PID: 7047 Comm: bash Not tainted 6.10.0-rc2+ #2
[  +0.000004] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021
[  +0.000003] Call Trace:
[  +0.000003]  &lt;TASK&gt;
[  +0.000002]  dump_stack_lvl+0x60/0x80
[  +0.000007]  print_report+0xce/0x630
[  +0.000007]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[  +0.000007]  ? __virt_addr_valid+0x1c9/0x2c0
[  +0.000005]  ? netif_queue_set_napi+0x1c2/0x1e0
[  +0.000003]  kasan_report+0xe9/0x120
[  +0.000004]  ? netif_queue_set_napi+0x1c2/0x1e0
[  +0.000004]  netif_queue_set_napi+0x1c2/0x1e0
[  +0.000005]  ice_vsi_close+0x161/0x670 [ice]
[  +0.000114]  ice_dis_vsi+0x22f/0x270 [ice]
[  +0.000095]  ice_pf_dis_all_vsi.constprop.0+0xae/0x1c0 [ice]
[  +0.000086]  ice_prepare_for_reset+0x299/0x750 [ice]
[  +0.000087]  pci_dev_save_and_disable+0x82/0xd0
[  +0.000006]  pci_reset_function+0x12d/0x230
[  +0.000004]  reset_store+0xa0/0x100
[  +0.000006]  ? __pfx_reset_store+0x10/0x10
[  +0.000002]  ? __pfx_mutex_lock+0x10/0x10
[  +0.000004]  ? __check_object_size+0x4c1/0x640
[  +0.000007]  kernfs_fop_write_iter+0x30b/0x4a0
[  +0.000006]  vfs_write+0x5d6/0xdf0
[  +0.000005]  ? fd_install+0x180/0x350
[  +0.000005]  ? __pfx_vfs_write+0x10/0xA10
[  +0.000004]  ? do_fcntl+0x52c/0xcd0
[  +0.000004]  ? kasan_save_track+0x13/0x60
[  +0.000003]  ? kasan_save_free_info+0x37/0x60
[  +0.000006]  ksys_write+0xfa/0x1d0
[  +0.000003]  ? __pfx_ksys_write+0x10/0x10
[  +0.000002]  ? __x64_sys_fcntl+0x121/0x180
[  +0.000004]  ? _raw_spin_lock+0x87/0xe0
[  +0.000005]  do_syscall_64+0x80/0x170
[  +0.000007]  ? _raw_spin_lock+0x87/0xe0
[  +0.000004]  ? __pfx__raw_spin_lock+0x10/0x10
[  +0.000003]  ? file_close_fd_locked+0x167/0x230
[  +0.000005]  ? syscall_exit_to_user_mode+0x7d/0x220
[  +0.000005]  ? do_syscall_64+0x8c/0x170
[  +0.000004]  ? do_syscall_64+0x8c/0x170
[  +0.000003]  ? do_syscall_64+0x8c/0x170
[  +0.000003]  ? fput+0x1a/0x2c0
[  +0.000004]  ? filp_close+0x19/0x30
[  +0.000004]  ? do_dup2+0x25a/0x4c0
[  +0.000004]  ? __x64_sys_dup2+0x6e/0x2e0
[  +0.000002]  ? syscall_exit_to_user_mode+0x7d/0x220
[  +0.000004]  ? do_syscall_64+0x8c/0x170
[  +0.000003]  ? __count_memcg_events+0x113/0x380
[  +0.000005]  ? handle_mm_fault+0x136/0x820
[  +0.000005]  ? do_user_addr_fault+0x444/0xa80
[  +0.000004]  ? clear_bhb_loop+0x25/0x80
[  +0.000004]  ? clear_bhb_loop+0x25/0x80
[  +0.000002]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[  +0.000005] RIP: 0033:0x7f2033593154</Note>
    </Notes>
    <CVE>CVE-2024-46766</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ice: Add netif_device_attach/detach into PF reset flow

Ethtool callbacks can be executed while reset is in progress and try to
access deleted resources, e.g. getting coalesce settings can result in a
NULL pointer dereference seen below.

Reproduction steps:
Once the driver is fully initialized, trigger reset:
	# echo 1 &gt; /sys/class/net/&lt;interface&gt;/device/reset
when reset is in progress try to get coalesce settings using ethtool:
	# ethtool -c &lt;interface&gt;

BUG: kernel NULL pointer dereference, address: 0000000000000020
PGD 0 P4D 0
Oops: Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 11 PID: 19713 Comm: ethtool Tainted: G S                 6.10.0-rc7+ #7
RIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice]
RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206
RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000
R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40
FS:  00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0
Call Trace:
&lt;TASK&gt;
ice_get_coalesce+0x17/0x30 [ice]
coalesce_prepare_data+0x61/0x80
ethnl_default_doit+0xde/0x340
genl_family_rcv_msg_doit+0xf2/0x150
genl_rcv_msg+0x1b3/0x2c0
netlink_rcv_skb+0x5b/0x110
genl_rcv+0x28/0x40
netlink_unicast+0x19c/0x290
netlink_sendmsg+0x222/0x490
__sys_sendto+0x1df/0x1f0
__x64_sys_sendto+0x24/0x30
do_syscall_64+0x82/0x160
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7faee60d8e27

Calling netif_device_detach() before reset makes the net core not call
the driver when ethtool command is issued, the attempt to execute an
ethtool command during reset will result in the following message:

    netlink error: No such device

instead of NULL pointer dereference. Once reset is done and
ice_rebuild() is executing, the netif_device_attach() is called to allow
for ethtool operations to occur again in a safe manner.</Note>
    </Notes>
    <CVE>CVE-2024-46770</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Validate function returns

[WHAT &amp; HOW]
Function return values must be checked before data can be used
in subsequent functions.

This fixes 4 CHECKED_RETURN issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-46775</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

udf: Avoid excessive partition lengths

Avoid mounting filesystems where the partition would overflow the
32-bits used for block number. Also refuse to mount filesystems where
the partition length is so large we cannot safely index bits in a
block bitmap.</Note>
    </Notes>
    <CVE>CVE-2024-46777</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tracing/osnoise: Use a cpumask to know what threads are kthreads

The start_kthread() and stop_thread() code was not always called with the
interface_lock held. This means that the kthread variable could be
unexpectedly changed causing the kthread_stop() to be called on it when it
should not have been, leading to:

 while true; do
   rtla timerlat top -u -q &amp; PID=$!;
   sleep 5;
   kill -INT $PID;
   sleep 0.001;
   kill -TERM $PID;
   wait $PID;
  done

Causing the following OOPS:

 Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI
 KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
 CPU: 5 UID: 0 PID: 885 Comm: timerlatu/5 Not tainted 6.11.0-rc4-test-00002-gbc754cc76d1b-dirty #125 a533010b71dab205ad2f507188ce8c82203b0254
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
 RIP: 0010:hrtimer_active+0x58/0x300
 Code: 48 c1 ee 03 41 54 48 01 d1 48 01 d6 55 53 48 83 ec 20 80 39 00 0f 85 30 02 00 00 49 8b 6f 30 4c 8d 75 10 4c 89 f0 48 c1 e8 03 &lt;0f&gt; b6 3c 10 4c 89 f0 83 e0 07 83 c0 03 40 38 f8 7c 09 40 84 ff 0f
 RSP: 0018:ffff88811d97f940 EFLAGS: 00010202
 RAX: 0000000000000002 RBX: ffff88823c6b5b28 RCX: ffffed10478d6b6b
 RDX: dffffc0000000000 RSI: ffffed10478d6b6c RDI: ffff88823c6b5b28
 RBP: 0000000000000000 R08: ffff88823c6b5b58 R09: ffff88823c6b5b60
 R10: ffff88811d97f957 R11: 0000000000000010 R12: 00000000000a801d
 R13: ffff88810d8b35d8 R14: 0000000000000010 R15: ffff88823c6b5b28
 FS:  0000000000000000(0000) GS:ffff88823c680000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000561858ad7258 CR3: 000000007729e001 CR4: 0000000000170ef0
 Call Trace:
  &lt;TASK&gt;
  ? die_addr+0x40/0xa0
  ? exc_general_protection+0x154/0x230
  ? asm_exc_general_protection+0x26/0x30
  ? hrtimer_active+0x58/0x300
  ? __pfx_mutex_lock+0x10/0x10
  ? __pfx_locks_remove_file+0x10/0x10
  hrtimer_cancel+0x15/0x40
  timerlat_fd_release+0x8e/0x1f0
  ? security_file_release+0x43/0x80
  __fput+0x372/0xb10
  task_work_run+0x11e/0x1f0
  ? _raw_spin_lock+0x85/0xe0
  ? __pfx_task_work_run+0x10/0x10
  ? poison_slab_object+0x109/0x170
  ? do_exit+0x7a0/0x24b0
  do_exit+0x7bd/0x24b0
  ? __pfx_migrate_enable+0x10/0x10
  ? __pfx_do_exit+0x10/0x10
  ? __pfx_read_tsc+0x10/0x10
  ? ktime_get+0x64/0x140
  ? _raw_spin_lock_irq+0x86/0xe0
  do_group_exit+0xb0/0x220
  get_signal+0x17ba/0x1b50
  ? vfs_read+0x179/0xa40
  ? timerlat_fd_read+0x30b/0x9d0
  ? __pfx_get_signal+0x10/0x10
  ? __pfx_timerlat_fd_read+0x10/0x10
  arch_do_signal_or_restart+0x8c/0x570
  ? __pfx_arch_do_signal_or_restart+0x10/0x10
  ? vfs_read+0x179/0xa40
  ? ksys_read+0xfe/0x1d0
  ? __pfx_ksys_read+0x10/0x10
  syscall_exit_to_user_mode+0xbc/0x130
  do_syscall_64+0x74/0x110
  ? __pfx___rseq_handle_notify_resume+0x10/0x10
  ? __pfx_ksys_read+0x10/0x10
  ? fpregs_restore_userregs+0xdb/0x1e0
  ? fpregs_restore_userregs+0xdb/0x1e0
  ? syscall_exit_to_user_mode+0x116/0x130
  ? do_syscall_64+0x74/0x110
  ? do_syscall_64+0x74/0x110
  ? do_syscall_64+0x74/0x110
  entry_SYSCALL_64_after_hwframe+0x71/0x79
 RIP: 0033:0x7ff0070eca9c
 Code: Unable to access opcode bytes at 0x7ff0070eca72.
 RSP: 002b:00007ff006dff8c0 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: 0000000000000000 RBX: 0000000000000005 RCX: 00007ff0070eca9c
 RDX: 0000000000000400 RSI: 00007ff006dff9a0 RDI: 0000000000000003
 RBP: 00007ff006dffde0 R08: 0000000000000000 R09: 00007ff000000ba0
 R10: 00007ff007004b08 R11: 0000000000000246 R12: 0000000000000003
 R13: 00007ff006dff9a0 R14: 0000000000000007 R15: 0000000000000008
  &lt;/TASK&gt;
 Modules linked in: snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hwdep snd_hda_core
 ---[ end trace 0000000000000000 ]---

This is because it would mistakenly call kthread_stop() on a user space
thread making it "exit" before it actually exits.

Since kthread
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-46788</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

powerpc/qspinlock: Fix deadlock in MCS queue

If an interrupt occurs in queued_spin_lock_slowpath() after we increment
qnodesp-&gt;count and before node-&gt;lock is initialized, another CPU might
see stale lock values in get_tail_qnode(). If the stale lock value happens
to match the lock on that CPU, then we write to the "next" pointer of
the wrong qnode. This causes a deadlock as the former CPU, once it becomes
the head of the MCS queue, will spin indefinitely until it's "next" pointer
is set by its successor in the queue.

Running stress-ng on a 16 core (16EC/16VP) shared LPAR, results in
occasional lockups similar to the following:

   $ stress-ng --all 128 --vm-bytes 80% --aggressive \
               --maximize --oomable --verify  --syslog \
               --metrics  --times  --timeout 5m

   watchdog: CPU 15 Hard LOCKUP
   ......
   NIP [c0000000000b78f4] queued_spin_lock_slowpath+0x1184/0x1490
   LR [c000000001037c5c] _raw_spin_lock+0x6c/0x90
   Call Trace:
    0xc000002cfffa3bf0 (unreliable)
    _raw_spin_lock+0x6c/0x90
    raw_spin_rq_lock_nested.part.135+0x4c/0xd0
    sched_ttwu_pending+0x60/0x1f0
    __flush_smp_call_function_queue+0x1dc/0x670
    smp_ipi_demux_relaxed+0xa4/0x100
    xive_muxed_ipi_action+0x20/0x40
    __handle_irq_event_percpu+0x80/0x240
    handle_irq_event_percpu+0x2c/0x80
    handle_percpu_irq+0x84/0xd0
    generic_handle_irq+0x54/0x80
    __do_irq+0xac/0x210
    __do_IRQ+0x74/0xd0
    0x0
    do_IRQ+0x8c/0x170
    hardware_interrupt_common_virt+0x29c/0x2a0
   --- interrupt: 500 at queued_spin_lock_slowpath+0x4b8/0x1490
   ......
   NIP [c0000000000b6c28] queued_spin_lock_slowpath+0x4b8/0x1490
   LR [c000000001037c5c] _raw_spin_lock+0x6c/0x90
   --- interrupt: 500
    0xc0000029c1a41d00 (unreliable)
    _raw_spin_lock+0x6c/0x90
    futex_wake+0x100/0x260
    do_futex+0x21c/0x2a0
    sys_futex+0x98/0x270
    system_call_exception+0x14c/0x2f0
    system_call_vectored_common+0x15c/0x2ec

The following code flow illustrates how the deadlock occurs.
For the sake of brevity, assume that both locks (A and B) are
contended and we call the queued_spin_lock_slowpath() function.

        CPU0                                   CPU1
        ----                                   ----
  spin_lock_irqsave(A)                          |
  spin_unlock_irqrestore(A)                     |
    spin_lock(B)                                |
         |                                      |
         ▼                                      |
   id = qnodesp-&gt;count++;                       |
  (Note that nodes[0].lock == A)                |
         |                                      |
         ▼                                      |
      Interrupt                                 |
  (happens before "nodes[0].lock = B")          |
         |                                      |
         ▼                                      |
  spin_lock_irqsave(A)                          |
         |                                      |
         ▼                                      |
   id = qnodesp-&gt;count++                        |
   nodes[1].lock = A                            |
         |                                      |
         ▼                                      |
  Tail of MCS queue                             |
         |                             spin_lock_irqsave(A)
         ▼                                      |
  Head of MCS queue                             ▼
         |                             CPU0 is previous tail
         ▼                                      |
   Spin indefinitely                            ▼
  (until "nodes[1].next != NULL")      prev = get_tail_qnode(A, CPU0)
                                                |
                                                ▼
                                       prev == &amp;qnodes[CPU0].nodes[0]
                                     (as qnodes
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-46797</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sch/netem: fix use after free in netem_dequeue

If netem_dequeue() enqueues packet to inner qdisc and that qdisc
returns __NET_XMIT_STOLEN. The packet is dropped but
qdisc_tree_reduce_backlog() is not called to update the parent's
q.qlen, leading to the similar use-after-free as Commit
e04991a48dbaf382 ("netem: fix return value if duplicate enqueue
fails")

Commands to trigger KASAN UaF:

ip link add type dummy
ip link set lo up
ip link set dummy0 up
tc qdisc add dev lo parent root handle 1: drr
tc filter add dev lo parent 1: basic classid 1:1
tc class add dev lo classid 1:1 drr
tc qdisc add dev lo parent 1:1 handle 2: netem
tc qdisc add dev lo parent 2: handle 3: drr
tc filter add dev lo parent 3: basic classid 3:1 action mirred egress
redirect dev dummy0
tc class add dev lo classid 3:1 drr
ping -c1 -W0.01 localhost # Trigger bug
tc class del dev lo classid 1:1
tc class add dev lo classid 1:1 drr
ping -c1 -W0.01 localhost # UaF</Note>
    </Notes>
    <CVE>CVE-2024-46800</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: added NULL check at start of dc_validate_stream

[Why]
prevent invalid memory access

[How]
check if dc and stream are NULL</Note>
    </Notes>
    <CVE>CVE-2024-46802</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Check debug trap enable before write dbg_ev_file

In interrupt context, write dbg_ev_file will be run by work queue. It
will cause write dbg_ev_file execution after debug_trap_disable, which
will cause NULL pointer access.
v2: cancel work "debug_event_workarea" before set dbg_ev_file as NULL.</Note>
    </Notes>
    <CVE>CVE-2024-46803</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add array index check for hdcp ddc access

[Why]
Coverity reports OVERRUN warning. Do not check if array
index valid.

[How]
Check msg_id valid and valid array index.</Note>
    </Notes>
    <CVE>CVE-2024-46804</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: fix the waring dereferencing hive

Check the amdgpu_hive_info *hive that maybe is NULL.</Note>
    </Notes>
    <CVE>CVE-2024-46805</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: Fix the warning division or modulo by zero

Checks the partition mode and returns an error for an invalid mode.</Note>
    </Notes>
    <CVE>CVE-2024-46806</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/amdgpu: Check tbo resource pointer

Validate tbo resource pointer, skip if NULL</Note>
    </Notes>
    <CVE>CVE-2024-46807</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check BIOS images before it is used

BIOS images may fail to load and null checks are added before they are
used.

This fixes 6 NULL_RETURNS issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-46809</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/bridge: tc358767: Check if fully initialized before signalling HPD event via IRQ

Make sure the connector is fully initialized before signalling any
HPD events via drm_kms_helper_hotplug_event(), otherwise this may
lead to NULL pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2024-46810</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix index may exceed array range within fpu_update_bw_bounding_box

[Why]
Coverity reports OVERRUN warning. soc.num_states could
be 40. But array range of bw_params-&gt;clk_table.entries is 8.

[How]
Assert if soc.num_states greater than 8.</Note>
    </Notes>
    <CVE>CVE-2024-46811</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Skip inactive planes within ModeSupportAndSystemConfiguration

[Why]
Coverity reports Memory - illegal accesses.

[How]
Skip inactive planes.</Note>
    </Notes>
    <CVE>CVE-2024-46812</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check link_index before accessing dc-&gt;links[]

[WHY &amp; HOW]
dc-&gt;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.</Note>
    </Notes>
    <CVE>CVE-2024-46813</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check msg_id before processing transcation

[WHY &amp; 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.</Note>
    </Notes>
    <CVE>CVE-2024-46814</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check num_valid_sets before accessing reader_wm_sets[]

[WHY &amp; 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.</Note>
    </Notes>
    <CVE>CVE-2024-46815</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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-&gt;links. link
count could up to AMDGPU_DM_MAX_DISPLAY_INDEX 31.

[How]
Make sure link count less than max_links.</Note>
    </Notes>
    <CVE>CVE-2024-46816</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-46817</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check gpio_id before used as array index

[WHY &amp; 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.</Note>
    </Notes>
    <CVE>CVE-2024-46818</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: the warning dereferencing obj for nbio_v7_4

if ras_manager obj null, don't print NBIO err data</Note>
    </Notes>
    <CVE>CVE-2024-46819</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/pm: Fix negative array index read

Avoid using the negative values
for clk_idex as an index into an array pptable-&gt;DpmDescriptor.

V2: fix clk_index return check (Tim Huang)</Note>
    </Notes>
    <CVE>CVE-2024-46821</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: use IWL_FW_CHECK for link ID check

The lookup function iwl_mvm_rcu_fw_link_id_to_link_conf() is
normally called with input from the firmware, so it should use
IWL_FW_CHECK() instead of WARN_ON().</Note>
    </Notes>
    <CVE>CVE-2024-46825</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ELF: fix kernel.randomize_va_space double read

ELF loader uses "randomize_va_space" twice. It is sysctl and can change
at any moment, so 2 loads could see 2 different values in theory with
unpredictable consequences.

Issue exactly one load for consistent value across one exec.</Note>
    </Notes>
    <CVE>CVE-2024-46826</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: fix firmware crash due to invalid peer nss

Currently, if the access point receives an association
request containing an Extended HE Capabilities Information
Element with an invalid MCS-NSS, it triggers a firmware
crash.

This issue arises when EHT-PHY capabilities shows support
for a bandwidth and MCS-NSS set for that particular
bandwidth is filled by zeros and due to this, driver obtains
peer_nss as 0 and sending this value to firmware causes
crash.

Address this issue by implementing a validation step for
the peer_nss value before passing it to the firmware. If
the value is greater than zero, proceed with forwarding
it to the firmware. However, if the value is invalid,
reject the association request to prevent potential
firmware crashes.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1</Note>
    </Notes>
    <CVE>CVE-2024-46827</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sched: sch_cake: fix bulk flow accounting logic for host fairness

In sch_cake, we keep track of the count of active bulk flows per host,
when running in dst/src host fairness mode, which is used as the
round-robin weight when iterating through flows. The count of active
bulk flows is updated whenever a flow changes state.

This has a peculiar interaction with the hash collision handling: when a
hash collision occurs (after the set-associative hashing), the state of
the hash bucket is simply updated to match the new packet that collided,
and if host fairness is enabled, that also means assigning new per-host
state to the flow. For this reason, the bulk flow counters of the
host(s) assigned to the flow are decremented, before new state is
assigned (and the counters, which may not belong to the same host
anymore, are incremented again).

Back when this code was introduced, the host fairness mode was always
enabled, so the decrement was unconditional. When the configuration
flags were introduced the *increment* was made conditional, but
the *decrement* was not. Which of course can lead to a spurious
decrement (and associated wrap-around to U16_MAX).

AFAICT, when host fairness is disabled, the decrement and wrap-around
happens as soon as a hash collision occurs (which is not that common in
itself, due to the set-associative hashing). However, in most cases this
is harmless, as the value is only used when host fairness mode is
enabled. So in order to trigger an array overflow, sch_cake has to first
be configured with host fairness disabled, and while running in this
mode, a hash collision has to occur to cause the overflow. Then, the
qdisc has to be reconfigured to enable host fairness, which leads to the
array out-of-bounds because the wrapped-around value is retained and
used as an array index. It seems that syzbot managed to trigger this,
which is quite impressive in its own right.

This patch fixes the issue by introducing the same conditional check on
decrement as is used on increment.

The original bug predates the upstreaming of cake, but the commit listed
in the Fixes tag touched that code, meaning that this patch won't apply
before that.</Note>
    </Notes>
    <CVE>CVE-2024-46828</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: Acquire kvm-&gt;srcu when handling KVM_SET_VCPU_EVENTS

Grab kvm-&gt;srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly
leave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX
reads guest memory.

Note, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN
via sync_regs(), which already holds SRCU.  I.e. trying to precisely use
kvm_vcpu_srcu_read_lock() around the problematic SMM code would cause
problems.  Acquiring SRCU isn't all that expensive, so for simplicity,
grab it unconditionally for KVM_SET_VCPU_EVENTS.

 =============================
 WARNING: suspicious RCU usage
 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted
 -----------------------------
 include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage!

 other info that might help us debug this:

 rcu_scheduler_active = 2, debug_locks = 1
 1 lock held by repro/1071:
  #0: ffff88811e424430 (&amp;vcpu-&gt;mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm]

 stack backtrace:
 CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
 Call Trace:
  &lt;TASK&gt;
  dump_stack_lvl+0x7f/0x90
  lockdep_rcu_suspicious+0x13f/0x1a0
  kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm]
  kvm_vcpu_read_guest+0x3e/0x90 [kvm]
  nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel]
  load_vmcs12_host_state+0x432/0xb40 [kvm_intel]
  vmx_leave_nested+0x30/0x40 [kvm_intel]
  kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm]
  kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm]
  ? mark_held_locks+0x49/0x70
  ? kvm_vcpu_ioctl+0x7d/0x970 [kvm]
  ? kvm_vcpu_ioctl+0x497/0x970 [kvm]
  kvm_vcpu_ioctl+0x497/0x970 [kvm]
  ? lock_acquire+0xba/0x2d0
  ? find_held_lock+0x2b/0x80
  ? do_user_addr_fault+0x40c/0x6f0
  ? lock_release+0xb7/0x270
  __x64_sys_ioctl+0x82/0xb0
  do_syscall_64+0x6c/0x170
  entry_SYSCALL_64_after_hwframe+0x4b/0x53
 RIP: 0033:0x7ff11eb1b539
  &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-46830</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: microchip: vcap: Fix use-after-free error in kunit test

This is a clear use-after-free error. We remove it, and rely on checking
the return code of vcap_del_rule.</Note>
    </Notes>
    <CVE>CVE-2024-46831</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ethtool: fail closed if we can't get max channel used in indirection tables

Commit 0d1b7d6c9274 ("bnxt: fix crashes when reducing ring count with
active RSS contexts") proves that allowing indirection table to contain
channels with out of bounds IDs may lead to crashes. Currently the
max channel check in the core gets skipped if driver can't fetch
the indirection table or when we can't allocate memory.

Both of those conditions should be extremely rare but if they do
happen we should try to be safe and fail the channel change.</Note>
    </Notes>
    <CVE>CVE-2024-46834</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: Fix smatch static checker warning

adev-&gt;gfx.imu.funcs could be NULL</Note>
    </Notes>
    <CVE>CVE-2024-46835</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: aspeed_udc: validate endpoint index for ast udc

We should verify the bound of the array to assure that host
may not manipulate the index to point past endpoint array.

Found by static analysis.</Note>
    </Notes>
    <CVE>CVE-2024-46836</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: clean up our handling of refs == 0 in snapshot delete

In reada we BUG_ON(refs == 0), which could be unkind since we aren't
holding a lock on the extent leaf and thus could get a transient
incorrect answer.  In walk_down_proc we also BUG_ON(refs == 0), which
could happen if we have extent tree corruption.  Change that to return
-EUCLEAN.  In do_walk_down() we catch this case and handle it correctly,
however we return -EIO, which -EUCLEAN is a more appropriate error code.
Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convert
that to proper error handling.  Also adjust the error message so we can
actually do something with the information.</Note>
    </Notes>
    <CVE>CVE-2024-46840</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc()

We handle errors here properly, ENOMEM isn't fatal, return the error.</Note>
    </Notes>
    <CVE>CVE-2024-46841</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Handle mailbox timeouts in lpfc_get_sfp_info

The MBX_TIMEOUT return code is not handled in lpfc_get_sfp_info and the
routine unconditionally frees submitted mailbox commands regardless of
return status.  The issue is that for MBX_TIMEOUT cases, when firmware
returns SFP information at a later time, that same mailbox memory region
references previously freed memory in its cmpl routine.

Fix by adding checks for the MBX_TIMEOUT return code.  During mailbox
resource cleanup, check the mbox flag to make sure that the wait did not
timeout.  If the MBOX_WAKE flag is not set, then do not free the resources
because it will be freed when firmware completes the mailbox at a later
time in its cmpl routine.

Also, increase the timeout from 30 to 60 seconds to accommodate boot
scripts requiring longer timeouts.</Note>
    </Notes>
    <CVE>CVE-2024-46842</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: ufs: core: Remove SCSI host only if added

If host tries to remove ufshcd driver from a UFS device it would cause a
kernel panic if ufshcd_async_scan fails during ufshcd_probe_hba before
adding a SCSI host with scsi_add_host and MCQ is enabled since SCSI host
has been defered after MCQ configuration introduced by commit 0cab4023ec7b
("scsi: ufs: core: Defer adding host to SCSI if MCQ is supported").

To guarantee that SCSI host is removed only if it has been added, set the
scsi_host_added flag to true after adding a SCSI host and check whether it
is set or not before removing it.</Note>
    </Notes>
    <CVE>CVE-2024-46843</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tracing/timerlat: Only clear timer if a kthread exists

The timerlat tracer can use user space threads to check for osnoise and
timer latency. If the program using this is killed via a SIGTERM, the
threads are shutdown one at a time and another tracing instance can start
up resetting the threads before they are fully closed. That causes the
hrtimer assigned to the kthread to be shutdown and freed twice when the
dying thread finally closes the file descriptors, causing a use-after-free
bug.

Only cancel the hrtimer if the associated thread is still around. Also add
the interface_lock around the resetting of the tlat_var-&gt;kthread.

Note, this is just a quick fix that can be backported to stable. A real
fix is to have a better synchronization between the shutdown of old
threads and the starting of new ones.</Note>
    </Notes>
    <CVE>CVE-2024-46845</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

spi: rockchip: Resolve unbalanced runtime PM / system PM handling

Commit e882575efc77 ("spi: rockchip: Suspend and resume the bus during
NOIRQ_SYSTEM_SLEEP_PM ops") stopped respecting runtime PM status and
simply disabled clocks unconditionally when suspending the system. This
causes problems when the device is already runtime suspended when we go
to sleep -- in which case we double-disable clocks and produce a
WARNing.

Switch back to pm_runtime_force_{suspend,resume}(), because that still
seems like the right thing to do, and the aforementioned commit makes no
explanation why it stopped using it.

Also, refactor some of the resume() error handling, because it's not
actually a good idea to re-disable clocks on failure.</Note>
    </Notes>
    <CVE>CVE-2024-46846</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

perf/x86/intel: Limit the period on Haswell

Running the ltp test cve-2015-3290 concurrently reports the following
warnings.

perfevents: irq loop stuck!
  WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174
  intel_pmu_handle_irq+0x285/0x370
  Call Trace:
   &lt;NMI&gt;
   ? __warn+0xa4/0x220
   ? intel_pmu_handle_irq+0x285/0x370
   ? __report_bug+0x123/0x130
   ? intel_pmu_handle_irq+0x285/0x370
   ? __report_bug+0x123/0x130
   ? intel_pmu_handle_irq+0x285/0x370
   ? report_bug+0x3e/0xa0
   ? handle_bug+0x3c/0x70
   ? exc_invalid_op+0x18/0x50
   ? asm_exc_invalid_op+0x1a/0x20
   ? irq_work_claim+0x1e/0x40
   ? intel_pmu_handle_irq+0x285/0x370
   perf_event_nmi_handler+0x3d/0x60
   nmi_handle+0x104/0x330

Thanks to Thomas Gleixner's analysis, the issue is caused by the low
initial period (1) of the frequency estimation algorithm, which triggers
the defects of the HW, specifically erratum HSW11 and HSW143. (For the
details, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/)

The HSW11 requires a period larger than 100 for the INST_RETIRED.ALL
event, but the initial period in the freq mode is 1. The erratum is the
same as the BDM11, which has been supported in the kernel. A minimum
period of 128 is enforced as well on HSW.

HSW143 is regarding that the fixed counter 1 may overcount 32 with the
Hyper-Threading is enabled. However, based on the test, the hardware
has more issues than it tells. Besides the fixed counter 1, the message
'interrupt took too long' can be observed on any counter which was armed
with a period &lt; 32 and two events expired in the same NMI. A minimum
period of 32 is enforced for the rest of the events.
The recommended workaround code of the HSW143 is not implemented.
Because it only addresses the issue for the fixed counter. It brings
extra overhead through extra MSR writing. No related overcounting issue
has been reported so far.</Note>
    </Notes>
    <CVE>CVE-2024-46848</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ASoC: meson: axg-card: fix 'use-after-free'

Buffer 'card-&gt;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</Note>
    </Notes>
    <CVE>CVE-2024-46849</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Avoid race between dcn10_set_drr() and dc_state_destruct()

dc_state_destruct() nulls the resource context of the DC state. The pipe
context passed to dcn10_set_drr() is a member of this resource context.

If dc_state_destruct() is called parallel to the IRQ processing (which
calls dcn10_set_drr() at some point), we can end up using already nulled
function callback fields of struct stream_resource.

The logic in dcn10_set_drr() already tries to avoid this, by checking tg
against NULL. But if the nulling happens exactly after the NULL check and
before the next access, then we get a race.

Avoid this by copying tg first to a local variable, and then use this
variable for all the operations. This should work, as long as nobody
frees the resource pool where the timing generators live.

(cherry picked from commit a3cc326a43bdc48fbdf53443e1027a03e309b643)</Note>
    </Notes>
    <CVE>CVE-2024-46851</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dma-buf: heaps: Fix off-by-one in CMA heap fault handler

Until VM_DONTEXPAND was added in commit 1c1914d6e8c6 ("dma-buf: heaps:
Don't track CMA dma-buf pages under RssFile") it was possible to obtain
a mapping larger than the buffer size via mremap and bypass the overflow
check in dma_buf_mmap_internal. When using such a mapping to attempt to
fault past the end of the buffer, the CMA heap fault handler also checks
the fault offset against the buffer size, but gets the boundary wrong by
1. Fix the boundary check so that we don't read off the end of the pages
array and insert an arbitrary page in the mapping.</Note>
    </Notes>
    <CVE>CVE-2024-46852</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

spi: nxp-fspi: fix the KASAN report out-of-bounds bug

Change the memcpy length to fix the out-of-bounds issue when writing the
data that is not 4 byte aligned to TX FIFO.

To reproduce the issue, write 3 bytes data to NOR chip.

dd if=3b of=/dev/mtd0
[   36.926103] ==================================================================
[   36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838
[   36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455
[   36.946721]
[   36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070
[   36.956185] Hardware name: Freescale i.MX8QM MEK (DT)
[   36.961260] Call trace:
[   36.963723]  dump_backtrace+0x90/0xe8
[   36.967414]  show_stack+0x18/0x24
[   36.970749]  dump_stack_lvl+0x78/0x90
[   36.974451]  print_report+0x114/0x5cc
[   36.978151]  kasan_report+0xa4/0xf0
[   36.981670]  __asan_report_load_n_noabort+0x1c/0x28
[   36.986587]  nxp_fspi_exec_op+0x26ec/0x2838
[   36.990800]  spi_mem_exec_op+0x8ec/0xd30
[   36.994762]  spi_mem_no_dirmap_read+0x190/0x1e0
[   36.999323]  spi_mem_dirmap_write+0x238/0x32c
[   37.003710]  spi_nor_write_data+0x220/0x374
[   37.007932]  spi_nor_write+0x110/0x2e8
[   37.011711]  mtd_write_oob_std+0x154/0x1f0
[   37.015838]  mtd_write_oob+0x104/0x1d0
[   37.019617]  mtd_write+0xb8/0x12c
[   37.022953]  mtdchar_write+0x224/0x47c
[   37.026732]  vfs_write+0x1e4/0x8c8
[   37.030163]  ksys_write+0xec/0x1d0
[   37.033586]  __arm64_sys_write+0x6c/0x9c
[   37.037539]  invoke_syscall+0x6c/0x258
[   37.041327]  el0_svc_common.constprop.0+0x160/0x22c
[   37.046244]  do_el0_svc+0x44/0x5c
[   37.049589]  el0_svc+0x38/0x78
[   37.052681]  el0t_64_sync_handler+0x13c/0x158
[   37.057077]  el0t_64_sync+0x190/0x194
[   37.060775]
[   37.062274] Allocated by task 455:
[   37.065701]  kasan_save_stack+0x2c/0x54
[   37.069570]  kasan_save_track+0x20/0x3c
[   37.073438]  kasan_save_alloc_info+0x40/0x54
[   37.077736]  __kasan_kmalloc+0xa0/0xb8
[   37.081515]  __kmalloc_noprof+0x158/0x2f8
[   37.085563]  mtd_kmalloc_up_to+0x120/0x154
[   37.089690]  mtdchar_write+0x130/0x47c
[   37.093469]  vfs_write+0x1e4/0x8c8
[   37.096901]  ksys_write+0xec/0x1d0
[   37.100332]  __arm64_sys_write+0x6c/0x9c
[   37.104287]  invoke_syscall+0x6c/0x258
[   37.108064]  el0_svc_common.constprop.0+0x160/0x22c
[   37.112972]  do_el0_svc+0x44/0x5c
[   37.116319]  el0_svc+0x38/0x78
[   37.119401]  el0t_64_sync_handler+0x13c/0x158
[   37.123788]  el0t_64_sync+0x190/0x194
[   37.127474]
[   37.128977] The buggy address belongs to the object at ffff00081037c2a0
[   37.128977]  which belongs to the cache kmalloc-8 of size 8
[   37.141177] The buggy address is located 0 bytes inside of
[   37.141177]  allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3)
[   37.153465]
[   37.154971] The buggy address belongs to the physical page:
[   37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c
[   37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff)
[   37.175149] page_type: 0xfdffffff(slab)
[   37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000
[   37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000
[   37.194553] page dumped because: kasan: bad access detected
[   37.200144]
[   37.201647] Memory state around the buggy address:
[   37.206460]  ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc
[   37.213701]  ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc
[   37.220946] &gt;ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc
[   37.228186]                                ^
[   37.232473]  ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   37.239718]  ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   37.246962] ==============================================================
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-46853</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: dpaa: Pad packets to ETH_ZLEN

When sending packets under 60 bytes, up to three bytes of the buffer
following the data may be leaked. Avoid this by extending all packets to
ETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be
reproduced by running

	$ ping -s 11 destination</Note>
    </Notes>
    <CVE>CVE-2024-46854</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nft_socket: fix sk refcount leaks

We must put 'sk' reference before returning.</Note>
    </Notes>
    <CVE>CVE-2024-46855</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: Fix bridge mode operations when there are no VFs

Currently, trying to set the bridge mode attribute when numvfs=0 leads to a
crash:

bridge link set dev eth2 hwmode vepa

[  168.967392] BUG: kernel NULL pointer dereference, address: 0000000000000030
[...]
[  168.969989] RIP: 0010:mlx5_add_flow_rules+0x1f/0x300 [mlx5_core]
[...]
[  168.976037] Call Trace:
[  168.976188]  &lt;TASK&gt;
[  168.978620]  _mlx5_eswitch_set_vepa_locked+0x113/0x230 [mlx5_core]
[  168.979074]  mlx5_eswitch_set_vepa+0x7f/0xa0 [mlx5_core]
[  168.979471]  rtnl_bridge_setlink+0xe9/0x1f0
[  168.979714]  rtnetlink_rcv_msg+0x159/0x400
[  168.980451]  netlink_rcv_skb+0x54/0x100
[  168.980675]  netlink_unicast+0x241/0x360
[  168.980918]  netlink_sendmsg+0x1f6/0x430
[  168.981162]  ____sys_sendmsg+0x3bb/0x3f0
[  168.982155]  ___sys_sendmsg+0x88/0xd0
[  168.985036]  __sys_sendmsg+0x59/0xa0
[  168.985477]  do_syscall_64+0x79/0x150
[  168.987273]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[  168.987773] RIP: 0033:0x7f8f7950f917

(esw-&gt;fdb_table.legacy.vepa_fdb is null)

The bridge mode is only relevant when there are multiple functions per
port. Therefore, prevent setting and getting this setting when there are no
VFs.

Note that after this change, there are no settings to change on the PF
interface using `bridge link` when there are no VFs, so the interface no
longer appears in the `bridge link` output.</Note>
    </Notes>
    <CVE>CVE-2024-46857</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

platform/x86: panasonic-laptop: Fix SINF array out of bounds accesses

The panasonic laptop code in various places uses the SINF array with index
values of 0 - SINF_CUR_BRIGHT(0x0d) without checking that the SINF array
is big enough.

Not all panasonic laptops have this many SINF array entries, for example
the Toughbook CF-18 model only has 10 SINF array entries. So it only
supports the AC+DC brightness entries and mute.

Check that the SINF array has a minimum size which covers all AC+DC
brightness entries and refuse to load if the SINF array is smaller.

For higher SINF indexes hide the sysfs attributes when the SINF array
does not contain an entry for that attribute, avoiding show()/store()
accessing the array out of bounds and add bounds checking to the probe()
and resume() code accessing these.</Note>
    </Notes>
    <CVE>CVE-2024-46859</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7921: fix NULL pointer access in mt7921_ipv6_addr_change

When disabling wifi mt7921_ipv6_addr_change() is called as a notifier.
At this point mvif-&gt;phy is already NULL so we cannot use it here.</Note>
    </Notes>
    <CVE>CVE-2024-46860</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usbnet: ipheth: do not stop RX on failing RX callback

RX callbacks can fail for multiple reasons:

* Payload too short
* Payload formatted incorrecly (e.g. bad NCM framing)
* Lack of memory

None of these should cause the driver to seize up.

Make such failures non-critical and continue processing further
incoming URBs.</Note>
    </Notes>
    <CVE>CVE-2024-46861</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

x86/hyperv: fix kexec crash due to VP assist page corruption

commit 9636be85cc5b ("x86/hyperv: Fix hyperv_pcpu_input_arg handling when
CPUs go online/offline") introduces a new cpuhp state for hyperv
initialization.

cpuhp_setup_state() returns the state number if state is
CPUHP_AP_ONLINE_DYN or CPUHP_BP_PREPARE_DYN and 0 for all other states.
For the hyperv case, since a new cpuhp state was introduced it would
return 0. However, in hv_machine_shutdown(), the cpuhp_remove_state() call
is conditioned upon "hyperv_init_cpuhp &gt; 0". This will never be true and
so hv_cpu_die() won't be called on all CPUs. This means the VP assist page
won't be reset. When the kexec kernel tries to setup the VP assist page
again, the hypervisor corrupts the memory region of the old VP assist page
causing a panic in case the kexec kernel is using that memory elsewhere.
This was originally fixed in commit dfe94d4086e4 ("x86/hyperv: Fix kexec
panic/hang issues").

Get rid of hyperv_init_cpuhp entirely since we are no longer using a
dynamic cpuhp state and use CPUHP_AP_HYPERV_ONLINE directly with
cpuhp_remove_state().</Note>
    </Notes>
    <CVE>CVE-2024-46864</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Disable DMCUB timeout for DCN35

[Why]
DMCUB can intermittently take longer than expected to process commands.

Old ASIC policy was to continue while logging a diagnostic error - which
works fine for ASIC without IPS, but with IPS this could lead to a race
condition where we attempt to access DCN state while it's inaccessible,
leading to a system hang when the NIU port is not disabled or register
accesses that timeout and the display configuration in an undefined
state.

[How]
We need to investigate why these accesses take longer than expected, but
for now we should disable the timeout on DCN35 to avoid this race
condition. Since the waits happen only at lower interrupt levels the
risk of taking too long at higher IRQ and causing a system watchdog
timeout are minimal.</Note>
    </Notes>
    <CVE>CVE-2024-46870</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Correct the defined value for AMDGPU_DMUB_NOTIFICATION_MAX

[Why &amp; How]
It actually exposes '6' types in enum dmub_notification_type. Not 5. Using smaller
number to create array dmub_callback &amp; dmub_thread_offload has potential to access
item out of array bound. Fix it.</Note>
    </Notes>
    <CVE>CVE-2024-46871</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

crypto: stm32/cryp - call finalize with bh disabled

The finalize operation in interrupt mode produce a produces a spinlock
recursion warning. The reason is the fact that BH must be disabled
during this process.</Note>
    </Notes>
    <CVE>CVE-2024-47658</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fsnotify: clear PARENT_WATCHED flags lazily

In some setups directories can have many (usually negative) dentries.
Hence __fsnotify_update_child_dentry_flags() function can take a
significant amount of time. Since the bulk of this function happens
under inode-&gt;i_lock this causes a significant contention on the lock
when we remove the watch from the directory as the
__fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask()
races with __fsnotify_update_child_dentry_flags() calls from
__fsnotify_parent() happening on children. This can lead upto softlockup
reports reported by users.

Fix the problem by calling fsnotify_update_children_dentry_flags() to
set PARENT_WATCHED flags only when parent starts watching children.

When parent stops watching children, clear false positive PARENT_WATCHED
flags lazily in __fsnotify_parent() for each accessed child.</Note>
    </Notes>
    <CVE>CVE-2024-47660</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Avoid overflow from uint32_t to uint8_t

[WHAT &amp; HOW]
dmub_rb_cmd's ramping_boundary has size of uint8_t and it is assigned
0xFFFF. Fix it by changing it to uint8_t with value of 0xFF.

This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-47661</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Remove register from DCN35 DMCUB diagnostic collection

[Why]
These registers should not be read from driver and triggering the
security violation when DMCUB work times out and diagnostics are
collected blocks Z8 entry.

[How]
Remove the register read from DCN35.</Note>
    </Notes>
    <CVE>CVE-2024-47662</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

staging: iio: frequency: ad9834: Validate frequency parameter value

In ad9834_write_frequency() clk_get_rate() can return 0. In such case
ad9834_calc_freqreg() call will lead to division by zero. Checking
'if (fout &gt; (clk_freq / 2))' doesn't protect in case of 'fout' is 0.
ad9834_write_frequency() is called from ad9834_write(), where fout is
taken from text buffer, which can contain any value.

Modify parameters checking.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2024-47663</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware

If the value of max_speed_hz is 0, it may cause a division by zero
error in hisi_calc_effective_speed().
The value of max_speed_hz is provided by firmware.
Firmware is generally considered as a trusted domain. However, as
division by zero errors can cause system failure, for defense measure,
the value of max_speed is validated here. So 0 is regarded as invalid
and an error code is returned.</Note>
    </Notes>
    <CVE>CVE-2024-47664</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i3c: mipi-i3c-hci: Error out instead on BUG_ON() in IBI DMA setup

Definitely condition dma_get_cache_alignment * defined value &gt; 256
during driver initialization is not reason to BUG_ON(). Turn that to
graceful error out with -EINVAL.</Note>
    </Notes>
    <CVE>CVE-2024-47665</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: pm80xx: Set phy-&gt;enable_completion only when we wait for it

pm8001_phy_control() populates the enable_completion pointer with a stack
address, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, and
returns. The problem arises when a phy control response comes late.  After
300 ms the pm8001_phy_control() function returns and the passed
enable_completion stack address is no longer valid. Late phy control
response invokes complete() on a dangling enable_completion pointer which
leads to a kernel crash.</Note>
    </Notes>
    <CVE>CVE-2024-47666</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)

Errata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0
(SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an
inbound PCIe TLP spans more than two internal AXI 128-byte bursts,
the bus may corrupt the packet payload and the corrupt data may
cause associated applications or the processor to hang.

The workaround for Errata #i2037 is to limit the maximum read
request size and maximum payload size to 128 bytes. Add workaround
for Errata #i2037 here.

The errata and workaround is applicable only to AM65x SR 1.0 and
later versions of the silicon will have this fixed.

[1] -&gt; https://www.ti.com/lit/er/sprz452i/sprz452i.pdf</Note>
    </Notes>
    <CVE>CVE-2024-47667</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-47668</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix state management in error path of log writing function

After commit a694291a6211 ("nilfs2: separate wait function from
nilfs_segctor_write") was applied, the log writing function
nilfs_segctor_do_construct() was able to issue I/O requests continuously
even if user data blocks were split into multiple logs across segments,
but two potential flaws were introduced in its error handling.

First, if nilfs_segctor_begin_construction() fails while creating the
second or subsequent logs, the log writing function returns without
calling nilfs_segctor_abort_construction(), so the writeback flag set on
pages/folios will remain uncleared.  This causes page cache operations to
hang waiting for the writeback flag.  For example,
truncate_inode_pages_final(), which is called via nilfs_evict_inode() when
an inode is evicted from memory, will hang.

Second, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. 
As a result, if the next log write involves checkpoint creation, that's
fine, but if a partial log write is performed that does not, inodes with
NILFS_I_COLLECTED set are erroneously removed from the "sc_dirty_files"
list, and their data and b-tree blocks may not be written to the device,
corrupting the block mapping.

Fix these issues by uniformly calling nilfs_segctor_abort_construction()
on failure of each step in the loop in nilfs_segctor_do_construct(),
having it clean up logs and segment usages according to progress, and
correcting the conditions for calling nilfs_redirty_inodes() to ensure
that the NILFS_I_COLLECTED flag is cleared.</Note>
    </Notes>
    <CVE>CVE-2024-47669</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

USB: usbtmc: prevent kernel-usb-infoleak

The syzbot reported a kernel-usb-infoleak in usbtmc_write,
we need to clear the structure before filling fields.</Note>
    </Notes>
    <CVE>CVE-2024-47671</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: don't wait for tx queues if firmware is dead

There is a WARNING in iwl_trans_wait_tx_queues_empty() (that was
recently converted from just a message), that can be hit if we
wait for TX queues to become empty after firmware died. Clearly,
we can't expect anything from the firmware after it's declared dead.

Don't call iwl_trans_wait_tx_queues_empty() in this case. While it could
be a good idea to stop the flow earlier, the flush functions do some
maintenance work that is not related to the firmware, so keep that part
of the code running even when the firmware is not running.

[edit commit message]</Note>
    </Notes>
    <CVE>CVE-2024-47672</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: pause TCM when the firmware is stopped

Not doing so will make us send a host command to the transport while the
firmware is not alive, which will trigger a WARNING.

bad state = 0
WARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]
RIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]
Call Trace:
 &lt;TASK&gt;
 iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm]
 iwl_mvm_config_scan+0x198/0x260 [iwlmvm]
 iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm]
 iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm]
 process_one_work+0x29e/0x640
 worker_thread+0x2df/0x690
 ? rescuer_thread+0x540/0x540
 kthread+0x192/0x1e0
 ? set_kthread_struct+0x90/0x90
 ret_from_fork+0x22/0x30</Note>
    </Notes>
    <CVE>CVE-2024-47673</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-47674</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix use-after-free in bpf_uprobe_multi_link_attach()

If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the
error_free label and frees the array of bpf_uprobe's without calling
bpf_uprobe_unregister().

This leaks bpf_uprobe-&gt;uprobe and worse, this frees bpf_uprobe-&gt;consumer
without removing it from the uprobe-&gt;consumers list.</Note>
    </Notes>
    <CVE>CVE-2024-47675</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

icmp: change the order of rate limits

ICMP messages are ratelimited :

After the blamed commits, the two rate limiters are applied in this order:

1) host wide ratelimit (icmp_global_allow())

2) Per destination ratelimit (inetpeer based)

In order to avoid side-channels attacks, we need to apply
the per destination check first.

This patch makes the following change :

1) icmp_global_allow() checks if the host wide limit is reached.
   But credits are not yet consumed. This is deferred to 3)

2) The per destination limit is checked/updated.
   This might add a new node in inetpeer tree.

3) icmp_global_consume() consumes tokens if prior operations succeeded.

This means that host wide ratelimit is still effective
in keeping inetpeer tree small even under DDOS.

As a bonus, I removed icmp_global.lock as the fast path
can use a lock-free operation.</Note>
    </Notes>
    <CVE>CVE-2024-47678</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vfs: fix race between evice_inodes() and find_inode()&amp;iput()

Hi, all

Recently I noticed a bug[1] in btrfs, after digged it into
and I believe it'a race in vfs.

Let's assume there's a inode (ie ino 261) with i_count 1 is
called by iput(), and there's a concurrent thread calling
generic_shutdown_super().

cpu0:                              cpu1:
iput() // i_count is 1
  -&gt;spin_lock(inode)
  -&gt;dec i_count to 0
  -&gt;iput_final()                    generic_shutdown_super()
    -&gt;__inode_add_lru()               -&gt;evict_inodes()
      // cause some reason[2]           -&gt;if (atomic_read(inode-&gt;i_count)) continue;
      // return before                  // inode 261 passed the above check
      // list_lru_add_obj()             // and then schedule out
   -&gt;spin_unlock()
// note here: the inode 261
// was still at sb list and hash list,
// and I_FREEING|I_WILL_FREE was not been set

btrfs_iget()
  // after some function calls
  -&gt;find_inode()
    // found the above inode 261
    -&gt;spin_lock(inode)
   // check I_FREEING|I_WILL_FREE
   // and passed
      -&gt;__iget()
    -&gt;spin_unlock(inode)                // schedule back
                                        -&gt;spin_lock(inode)
                                        // check (I_NEW|I_FREEING|I_WILL_FREE) flags,
                                        // passed and set I_FREEING
iput()                                  -&gt;spin_unlock(inode)
  -&gt;spin_lock(inode)			  -&gt;evict()
  // dec i_count to 0
  -&gt;iput_final()
    -&gt;spin_unlock()
    -&gt;evict()

Now, we have two threads simultaneously evicting
the same inode, which may trigger the BUG(inode-&gt;i_state &amp; I_CLEAR)
statement both within clear_inode() and iput().

To fix the bug, recheck the inode-&gt;i_count after holding i_lock.
Because in the most scenarios, the first check is valid, and
the overhead of spin_lock() can be reduced.

If there is any misunderstanding, please let me know, thanks.

[1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/
[2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable()
return false when I reproduced the bug.</Note>
    </Notes>
    <CVE>CVE-2024-47679</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he

Fix the NULL pointer dereference in mt7996_mcu_sta_bfer_he
routine adding an sta interface to the mt7996 driver.

Found by code review.</Note>
    </Notes>
    <CVE>CVE-2024-47681</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: sd: Fix off-by-one error in sd_read_block_characteristics()

Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for
example), sd_read_block_characteristics() may attempt an out-of-bounds
memory access when accessing the zoned field at offset 8.</Note>
    </Notes>
    <CVE>CVE-2024-47682</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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 &lt;48&gt; 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---</Note>
    </Notes>
    <CVE>CVE-2024-47684</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()

syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending
garbage on the four reserved tcp bits (th-&gt;res1)

Use skb_put_zero() to clear the whole TCP header,
as done in nf_reject_ip_tcphdr_put()

BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255
  nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255
  nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344
  nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48
  expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
  nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288
  nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161
  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
  nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626
  nf_hook include/linux/netfilter.h:269 [inline]
  NF_HOOK include/linux/netfilter.h:312 [inline]
  ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310
  __netif_receive_skb_one_core net/core/dev.c:5661 [inline]
  __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775
  process_backlog+0x4ad/0xa50 net/core/dev.c:6108
  __napi_poll+0xe7/0x980 net/core/dev.c:6772
  napi_poll net/core/dev.c:6841 [inline]
  net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963
  handle_softirqs+0x1ce/0x800 kernel/softirq.c:554
  __do_softirq+0x14/0x1a kernel/softirq.c:588
  do_softirq+0x9a/0x100 kernel/softirq.c:455
  __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382
  local_bh_enable include/linux/bottom_half.h:33 [inline]
  rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline]
  __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450
  dev_queue_xmit include/linux/netdevice.h:3105 [inline]
  neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565
  neigh_output include/net/neighbour.h:542 [inline]
  ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141
  __ip6_finish_output net/ipv6/ip6_output.c:215 [inline]
  ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226
  NF_HOOK_COND include/linux/netfilter.h:303 [inline]
  ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247
  dst_output include/net/dst.h:450 [inline]
  NF_HOOK include/linux/netfilter.h:314 [inline]
  ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366
  inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135
  __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466
  tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]
  tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143
  tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333
  __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679
  inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750
  __sys_connect_file net/socket.c:2061 [inline]
  __sys_connect+0x606/0x690 net/socket.c:2078
  __do_sys_connect net/socket.c:2088 [inline]
  __se_sys_connect net/socket.c:2085 [inline]
  __x64_sys_connect+0x91/0xe0 net/socket.c:2085
  x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43
  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 stored to memory at:
  nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249
  nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344
  nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48
  expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
  nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288
  nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161
  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
  nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626
  nf_hook include/linux/netfilter.h:269 [inline]
  NF_HOOK include/linux/netfilter.h:312 [inline]
  ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310
  __netif_receive_skb_one_core
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-47685</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate()

The psc-&gt;div[] array has psc-&gt;num_div elements.  These values come from
when we call clk_hw_register_div().  It's adc_divisors and
ARRAY_SIZE(adc_divisors)) and so on.  So this condition needs to be &gt;=
instead of &gt; to prevent an out of bounds read.</Note>
    </Notes>
    <CVE>CVE-2024-47686</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vdpa/mlx5: Fix invalid mr resource destroy

Certain error paths from mlx5_vdpa_dev_add() can end up releasing mr
resources which never got initialized in the first place.

This patch adds the missing check in mlx5_vdpa_destroy_mr_resources()
to block releasing non-initialized mr resources.

Reference trace:

  mlx5_core 0000:08:00.2: mlx5_vdpa_dev_add:3274:(pid 2700) warning: No mac address provisioned?
  BUG: kernel NULL pointer dereference, address: 0000000000000000
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 140216067 P4D 0
  Oops: 0000 [#1] PREEMPT SMP NOPTI
  CPU: 8 PID: 2700 Comm: vdpa Kdump: loaded Not tainted 5.14.0-496.el9.x86_64 #1
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
  RIP: 0010:vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb]
  Code: [...]
  RSP: 0018:ff1c823ac23077f0 EFLAGS: 00010246
  RAX: ffffffffc1a21a60 RBX: ffffffff899567a0 RCX: 0000000000000000
  RDX: ffffffffffffffff RSI: 0000000000000000 RDI: 0000000000000000
  RBP: ff1bda1f7c21e800 R08: 0000000000000000 R09: ff1c823ac2307670
  R10: ff1c823ac2307668 R11: ffffffff8a9e7b68 R12: 0000000000000000
  R13: 0000000000000000 R14: ff1bda1f43e341a0 R15: 00000000ffffffea
  FS:  00007f56eba7c740(0000) GS:ff1bda269f800000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000000 CR3: 0000000104d90001 CR4: 0000000000771ef0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  PKRU: 55555554
  Call Trace:

   ? show_trace_log_lvl+0x1c4/0x2df
   ? show_trace_log_lvl+0x1c4/0x2df
   ? mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa]
   ? __die_body.cold+0x8/0xd
   ? page_fault_oops+0x134/0x170
   ? __irq_work_queue_local+0x2b/0xc0
   ? irq_work_queue+0x2c/0x50
   ? exc_page_fault+0x62/0x150
   ? asm_exc_page_fault+0x22/0x30
   ? __pfx_mlx5_vdpa_free+0x10/0x10 [mlx5_vdpa]
   ? vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb]
   mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa]
   vdpa_release_dev+0x1e/0x50 [vdpa]
   device_release+0x31/0x90
   kobject_cleanup+0x37/0x130
   mlx5_vdpa_dev_add+0x2d2/0x7a0 [mlx5_vdpa]
   vdpa_nl_cmd_dev_add_set_doit+0x277/0x4c0 [vdpa]
   genl_family_rcv_msg_doit+0xd9/0x130
   genl_family_rcv_msg+0x14d/0x220
   ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa]
   ? _copy_to_user+0x1a/0x30
   ? move_addr_to_user+0x4b/0xe0
   genl_rcv_msg+0x47/0xa0
   ? __import_iovec+0x46/0x150
   ? __pfx_genl_rcv_msg+0x10/0x10
   netlink_rcv_skb+0x54/0x100
   genl_rcv+0x24/0x40
   netlink_unicast+0x245/0x370
   netlink_sendmsg+0x206/0x440
   __sys_sendto+0x1dc/0x1f0
   ? do_read_fault+0x10c/0x1d0
   ? do_pte_missing+0x10d/0x190
   __x64_sys_sendto+0x20/0x30
   do_syscall_64+0x5c/0xf0
   ? __count_memcg_events+0x4f/0xb0
   ? mm_account_fault+0x6c/0x100
   ? handle_mm_fault+0x116/0x270
   ? do_user_addr_fault+0x1d6/0x6a0
   ? do_syscall_64+0x6b/0xf0
   ? clear_bhb_loop+0x25/0x80
   ? clear_bhb_loop+0x25/0x80
   ? clear_bhb_loop+0x25/0x80
   ? clear_bhb_loop+0x25/0x80
   ? clear_bhb_loop+0x25/0x80
   entry_SYSCALL_64_after_hwframe+0x78/0x80</Note>
    </Notes>
    <CVE>CVE-2024-47687</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

driver core: Fix a potential null-ptr-deref in module_add_driver()

Inject fault while probing of-fpga-region, if kasprintf() fails in
module_add_driver(), the second sysfs_remove_link() in exit path will cause
null-ptr-deref as below because kernfs_name_hash() will call strlen() with
NULL driver_name.

Fix it by releasing resources based on the exit path sequence.

	 KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
	 Mem abort info:
	   ESR = 0x0000000096000005
	   EC = 0x25: DABT (current EL), IL = 32 bits
	   SET = 0, FnV = 0
	   EA = 0, S1PTW = 0
	   FSC = 0x05: level 1 translation fault
	 Data abort info:
	   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
	   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
	   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
	 [dfffffc000000000] address between user and kernel address ranges
	 Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
	 Dumping ftrace buffer:
	    (ftrace buffer empty)
	 Modules linked in: of_fpga_region(+) fpga_region fpga_bridge cfg80211 rfkill 8021q garp mrp stp llc ipv6 [last unloaded: of_fpga_region]
	 CPU: 2 UID: 0 PID: 2036 Comm: modprobe Not tainted 6.11.0-rc2-g6a0e38264012 #295
	 Hardware name: linux,dummy-virt (DT)
	 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
	 pc : strlen+0x24/0xb0
	 lr : kernfs_name_hash+0x1c/0xc4
	 sp : ffffffc081f97380
	 x29: ffffffc081f97380 x28: ffffffc081f97b90 x27: ffffff80c821c2a0
	 x26: ffffffedac0be418 x25: 0000000000000000 x24: ffffff80c09d2000
	 x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000
	 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000001840
	 x17: 0000000000000000 x16: 0000000000000000 x15: 1ffffff8103f2e42
	 x14: 00000000f1f1f1f1 x13: 0000000000000004 x12: ffffffb01812d61d
	 x11: 1ffffff01812d61c x10: ffffffb01812d61c x9 : dfffffc000000000
	 x8 : 0000004fe7ed29e4 x7 : ffffff80c096b0e7 x6 : 0000000000000001
	 x5 : ffffff80c096b0e0 x4 : 1ffffffdb990efa2 x3 : 0000000000000000
	 x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000000
	 Call trace:
	  strlen+0x24/0xb0
	  kernfs_name_hash+0x1c/0xc4
	  kernfs_find_ns+0x118/0x2e8
	  kernfs_remove_by_name_ns+0x80/0x100
	  sysfs_remove_link+0x74/0xa8
	  module_add_driver+0x278/0x394
	  bus_add_driver+0x1f0/0x43c
	  driver_register+0xf4/0x3c0
	  __platform_driver_register+0x60/0x88
	  of_fpga_region_init+0x20/0x1000 [of_fpga_region]
	  do_one_initcall+0x110/0x788
	  do_init_module+0x1dc/0x5c8
	  load_module+0x3c38/0x4cac
	  init_module_from_file+0xd4/0x128
	  idempotent_init_module+0x2cc/0x528
	  __arm64_sys_finit_module+0xac/0x100
	  invoke_syscall+0x6c/0x258
	  el0_svc_common.constprop.0+0x160/0x22c
	  do_el0_svc+0x44/0x5c
	  el0_svc+0x48/0xb8
	  el0t_64_sync_handler+0x13c/0x158
	  el0t_64_sync+0x190/0x194
	 Code: f2fbffe1 a90157f4 12000802 aa0003f5 (38e16861)
	 ---[ end trace 0000000000000000 ]---
	 Kernel panic - not syncing: Oops: Fatal exception</Note>
    </Notes>
    <CVE>CVE-2024-47688</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfsd: return -EINVAL when namelen is 0

When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may
result in namelen being 0, which will cause memdup_user() to return
ZERO_SIZE_PTR.
When we access the name.data that has been assigned the value of
ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is
triggered.

[ T1205] ==================================================================
[ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260
[ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205
[ T1205]
[ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406
[ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014
[ T1205] Call Trace:
[ T1205]  dump_stack+0x9a/0xd0
[ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260
[ T1205]  __kasan_report.cold+0x34/0x84
[ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260
[ T1205]  kasan_report+0x3a/0x50
[ T1205]  nfs4_client_to_reclaim+0xe9/0x260
[ T1205]  ? nfsd4_release_lockowner+0x410/0x410
[ T1205]  cld_pipe_downcall+0x5ca/0x760
[ T1205]  ? nfsd4_cld_tracking_exit+0x1d0/0x1d0
[ T1205]  ? down_write_killable_nested+0x170/0x170
[ T1205]  ? avc_policy_seqno+0x28/0x40
[ T1205]  ? selinux_file_permission+0x1b4/0x1e0
[ T1205]  rpc_pipe_write+0x84/0xb0
[ T1205]  vfs_write+0x143/0x520
[ T1205]  ksys_write+0xc9/0x170
[ T1205]  ? __ia32_sys_read+0x50/0x50
[ T1205]  ? ktime_get_coarse_real_ts64+0xfe/0x110
[ T1205]  ? ktime_get_coarse_real_ts64+0xa2/0x110
[ T1205]  do_syscall_64+0x33/0x40
[ T1205]  entry_SYSCALL_64_after_hwframe+0x67/0xd1
[ T1205] RIP: 0033:0x7fdbdb761bc7
[ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 514
[ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7
[ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008
[ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001
[ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b
[ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000
[ T1205] ==================================================================

Fix it by checking namelen.</Note>
    </Notes>
    <CVE>CVE-2024-47692</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

IB/core: Fix ib_cache_setup_one error flow cleanup

When ib_cache_update return an error, we exit ib_cache_setup_one
instantly with no proper cleanup, even though before this we had
already successfully done gid_table_setup_one, that results in
the kernel WARN below.

Do proper cleanup using gid_table_cleanup_one before returning
the err in order to fix the issue.

WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0
Modules linked in:
CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:gid_table_release_one+0x181/0x1a0
Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff &lt;0f&gt; 0b 4c 8b 75 30 e9 54 ff ff ff 48 8    3 c4 10 5b 5d 41 5c 41 5d 41
RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527
RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001
RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631
R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001
R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001
FS:  00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 ? show_regs+0x94/0xa0
 ? __warn+0x9e/0x1c0
 ? gid_table_release_one+0x181/0x1a0
 ? report_bug+0x1f9/0x340
 ? gid_table_release_one+0x181/0x1a0
 ? handle_bug+0xa2/0x110
 ? exc_invalid_op+0x31/0xa0
 ? asm_exc_invalid_op+0x16/0x20
 ? __warn_printk+0xc7/0x180
 ? __warn_printk+0xd4/0x180
 ? gid_table_release_one+0x181/0x1a0
 ib_device_release+0x71/0xe0
 ? __pfx_ib_device_release+0x10/0x10
 device_release+0x44/0xd0
 kobject_put+0x135/0x3d0
 put_device+0x20/0x30
 rxe_net_add+0x7d/0xa0
 rxe_newlink+0xd7/0x190
 nldev_newlink+0x1b0/0x2a0
 ? __pfx_nldev_newlink+0x10/0x10
 rdma_nl_rcv_msg+0x1ad/0x2e0
 rdma_nl_rcv_skb.constprop.0+0x176/0x210
 netlink_unicast+0x2de/0x400
 netlink_sendmsg+0x306/0x660
 __sock_sendmsg+0x110/0x120
 ____sys_sendmsg+0x30e/0x390
 ___sys_sendmsg+0x9b/0xf0
 ? kstrtouint+0x6e/0xa0
 ? kstrtouint_from_user+0x7c/0xb0
 ? get_pid_task+0xb0/0xd0
 ? proc_fail_nth_write+0x5b/0x140
 ? __fget_light+0x9a/0x200
 ? preempt_count_add+0x47/0xa0
 __sys_sendmsg+0x61/0xd0
 do_syscall_64+0x50/0x110
 entry_SYSCALL_64_after_hwframe+0x76/0x7e</Note>
    </Notes>
    <CVE>CVE-2024-47693</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds

In the function init_conns(), after the create_con() and create_cm() for
loop if something fails. In the cleanup for loop after the destroy tag, we
access out of bound memory because cid is set to clt_path-&gt;s.con_num.

This commits resets the cid to clt_path-&gt;s.con_num - 1, to stay in bounds
in the cleanup loop later.</Note>
    </Notes>
    <CVE>CVE-2024-47695</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency

In the commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to
destroying CM IDs"), the function flush_workqueue is invoked to flush the
work queue iwcm_wq.

But at that time, the work queue iwcm_wq was created via the function
alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM.

Because the current process is trying to flush the whole iwcm_wq, if
iwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current
process is not reclaiming memory or running on a workqueue which doesn't
have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee
leading to a deadlock.

The call trace is as below:

[  125.350876][ T1430] Call Trace:
[  125.356281][ T1430]  &lt;TASK&gt;
[ 125.361285][ T1430] ? __warn (kernel/panic.c:693)
[ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))
[ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219)
[ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239)
[ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))
[ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621)
[ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))
[ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))
[ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970)
[ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151)
[ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm
[ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910)
[ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)
[ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161)
[ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm
[ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma
[ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma
[ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231)
[ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393)
[ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339)
[ 125.531837][ T1430] kthread (kernel/kthread.c:389)
[ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342)
[ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147)
[ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342)
[ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257)
[  125.566487][ T1430]  &lt;/TASK&gt;
[  125.566488][ T1430] ---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2024-47696</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error

Ensure index in rtl2830_pid_filter does not exceed 31 to prevent
out-of-bounds access.

dev-&gt;filters is a 32-bit value, so set_bit and clear_bit functions should
only operate on indices from 0 to 31. If index is 32, it will attempt to
access a non-existent 33rd bit, leading to out-of-bounds access.
Change the boundary check from index &gt; 32 to index &gt;= 32 to resolve this
issue.</Note>
    </Notes>
    <CVE>CVE-2024-47697</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error

Ensure index in rtl2832_pid_filter does not exceed 31 to prevent
out-of-bounds access.

dev-&gt;filters is a 32-bit value, so set_bit and clear_bit functions should
only operate on indices from 0 to 31. If index is 32, it will attempt to
access a non-existent 33rd bit, leading to out-of-bounds access.
Change the boundary check from index &gt; 32 to index &gt;= 32 to resolve this
issue.

[hverkuil: added fixes tag, rtl2830_pid_filter -&gt; rtl2832_pid_filter in logmsg]</Note>
    </Notes>
    <CVE>CVE-2024-47698</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix potential null-ptr-deref in nilfs_btree_insert()

Patch series "nilfs2: fix potential issues with empty b-tree nodes".

This series addresses three potential issues with empty b-tree nodes that
can occur with corrupted filesystem images, including one recently
discovered by syzbot.


This patch (of 3):

If a b-tree is broken on the device, and the b-tree height is greater than
2 (the level of the root node is greater than 1) even if the number of
child nodes of the b-tree root is 0, a NULL pointer dereference occurs in
nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert().

This is because, when the number of child nodes of the b-tree root is 0,
nilfs_btree_do_lookup() does not set the block buffer head in any of
path[x].bp_bh, leaving it as the initial value of NULL, but if the level
of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(),
which accesses the buffer memory of path[x].bp_bh, is called.

Fix this issue by adding a check to nilfs_btree_root_broken(), which
performs sanity checks when reading the root node from the device, to
detect this inconsistency.

Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause
early on.</Note>
    </Notes>
    <CVE>CVE-2024-47699</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: avoid OOB when system.data xattr changes underneath the filesystem

When looking up for an entry in an inlined directory, if e_value_offs is
changed underneath the filesystem by some change in the block device, it
will lead to an out-of-bounds access that KASAN detects as an UAF.

EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none.
loop0: detected capacity change from 2048 to 2047
==================================================================
BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500
Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103

CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:93 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
 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
 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500
 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697
 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573
 ext4_lookup_entry fs/ext4/namei.c:1727 [inline]
 ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795
 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633
 filename_create+0x297/0x540 fs/namei.c:3980
 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587
 __do_sys_symlinkat fs/namei.c:4610 [inline]
 __se_sys_symlinkat fs/namei.c:4607 [inline]
 __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607
 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
RIP: 0033:0x7f3e73ced469
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 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 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a
RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469
RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0
RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290
R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c
R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0
 &lt;/TASK&gt;

Calling ext4_xattr_ibody_find right after reading the inode with
ext4_get_inode_loc will lead to a check of the validity of the xattrs,
avoiding this problem.</Note>
    </Notes>
    <CVE>CVE-2024-47701</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Fail verification for sign-extension of packet data/data_end/data_meta

syzbot reported a kernel crash due to
  commit 1f1e864b6555 ("bpf: Handle sign-extenstin ctx member accesses").
The reason is due to sign-extension of 32-bit load for
packet data/data_end/data_meta uapi field.

The original code looks like:
        r2 = *(s32 *)(r1 + 76) /* load __sk_buff-&gt;data */
        r3 = *(u32 *)(r1 + 80) /* load __sk_buff-&gt;data_end */
        r0 = r2
        r0 += 8
        if r3 &gt; r0 goto +1
        ...
Note that __sk_buff-&gt;data load has 32-bit sign extension.

After verification and convert_ctx_accesses(), the final asm code looks like:
        r2 = *(u64 *)(r1 +208)
        r2 = (s32)r2
        r3 = *(u64 *)(r1 +80)
        r0 = r2
        r0 += 8
        if r3 &gt; r0 goto pc+1
        ...
Note that 'r2 = (s32)r2' may make the kernel __sk_buff-&gt;data address invalid
which may cause runtime failure.

Currently, in C code, typically we have
        void *data = (void *)(long)skb-&gt;data;
        void *data_end = (void *)(long)skb-&gt;data_end;
        ...
and it will generate
        r2 = *(u64 *)(r1 +208)
        r3 = *(u64 *)(r1 +80)
        r0 = r2
        r0 += 8
        if r3 &gt; r0 goto pc+1

If we allow sign-extension,
        void *data = (void *)(long)(int)skb-&gt;data;
        void *data_end = (void *)(long)skb-&gt;data_end;
        ...
the generated code looks like
        r2 = *(u64 *)(r1 +208)
        r2 &lt;&lt;= 32
        r2 s&gt;&gt;= 32
        r3 = *(u64 *)(r1 +80)
        r0 = r2
        r0 += 8
        if r3 &gt; r0 goto pc+1
and this will cause verification failure since "r2 &lt;&lt;= 32" is not allowed
as "r2" is a packet pointer.

To fix this issue for case
  r2 = *(s32 *)(r1 + 76) /* load __sk_buff-&gt;data */
this patch added additional checking in is_valid_access() callback
function for packet data/data_end/data_meta access. If those accesses
are with sign-extenstion, the verification will fail.

  [1] https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/</Note>
    </Notes>
    <CVE>CVE-2024-47702</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf, lsm: Add check for BPF LSM return value

A bpf prog returning a positive number attached to file_alloc_security
hook makes kernel panic.

This happens because file system can not filter out the positive number
returned by the LSM prog using IS_ERR, and misinterprets this positive
number as a file pointer.

Given that hook file_alloc_security never returned positive number
before the introduction of BPF LSM, and other BPF LSM hooks may
encounter similar issues, this patch adds LSM return value check
in verifier, to ensure no unexpected value is returned.</Note>
    </Notes>
    <CVE>CVE-2024-47703</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check link_res-&gt;hpo_dp_link_enc before using it

[WHAT &amp; HOW]
Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res
without initializing hpo_dp_link_enc and it is necessary to check for
null before dereferencing.

This fixes 2 FORWARD_NULL issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-47704</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

block: fix potential invalid pointer dereference in blk_add_partition

The blk_add_partition() function initially used a single if-condition
(IS_ERR(part)) to check for errors when adding a partition. This was
modified to handle the specific case of -ENXIO separately, allowing the
function to proceed without logging the error in this case. However,
this change unintentionally left a path where md_autodetect_dev()
could be called without confirming that part is a valid pointer.

This commit separates the error handling logic by splitting the
initial if-condition, improving code readability and handling specific
error scenarios explicitly. The function now distinguishes the general
error case from -ENXIO without altering the existing behavior of
md_autodetect_dev() calls.</Note>
    </Notes>
    <CVE>CVE-2024-47705</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

block, bfq: fix possible UAF for bfqq-&gt;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---------&gt;bfqq2		  bfqq3
process ref:	   0		    2		    1

3) bfqq2 merged to bfqq3:

		Process 1       Process 2	Process 3
		 (BIC1)          (BIC2)		 (BIC3)
	 here -&gt; Λ                |		  |
		  \--------------\ \-------------\|
		                  V		  V
		  bfqq1---------&gt;bfqq2----------&gt;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-&gt;bic to BIC1.

bfq_insert_request
-&gt; by Process 1
 bfqq = bfq_init_rq(rq)
  bfqq = bfq_get_bfqq_handle_split
   bfqq = bic_to_bfqq
   -&gt; get bfqq2 from BIC1
 bfqq-&gt;ref++
 rq-&gt;elv.priv[0] = bic
 rq-&gt;elv.priv[1] = bfqq
 if (bfqq_process_refs(bfqq) == 1)
  bfqq-&gt;bic = bic
  -&gt; record BIC1 to bfqq2

  __bfq_insert_request
   new_bfqq = bfq_setup_cooperator
   -&gt; get bfqq3 from bfqq2-&gt;new_bfqq
   bfqq_request_freed(bfqq)
   new_bfqq-&gt;ref++
   rq-&gt;elv.priv[1] = new_bfqq
   -&gt; 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:
 &lt;TASK&gt;
 __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
 &lt;/TASK&gt;

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---</Note>
    </Notes>
    <CVE>CVE-2024-47706</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()

Blamed commit accidentally removed a check for rt-&gt;rt6i_idev being NULL,
as spotted by syzbot:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline]
 RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914
Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df &lt;80&gt; 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06
RSP: 0018:ffffc900047374e0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000
RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0
RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c
R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18
R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930
FS:  0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
  addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856
 addrconf_notify+0x3cb/0x1020
  notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93
  call_netdevice_notifiers_extack net/core/dev.c:2032 [inline]
  call_netdevice_notifiers net/core/dev.c:2046 [inline]
  unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352
  unregister_netdevice_many net/core/dev.c:11414 [inline]
  unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289
  unregister_netdevice include/linux/netdevice.h:3129 [inline]
  __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685
  tun_detach drivers/net/tun.c:701 [inline]
  tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510
  __fput+0x24a/0x8a0 fs/file_table.c:422
  task_work_run+0x24f/0x310 kernel/task_work.c:228
  exit_task_work include/linux/task_work.h:40 [inline]
  do_exit+0xa2f/0x27f0 kernel/exit.c:882
  do_group_exit+0x207/0x2c0 kernel/exit.c:1031
  __do_sys_exit_group kernel/exit.c:1042 [inline]
  __se_sys_exit_group kernel/exit.c:1040 [inline]
  __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040
  x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232
  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
RIP: 0033:0x7f1acc77def9
Code: Unable to access opcode bytes at 0x7f1acc77decf.
RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043
RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0
 &lt;/TASK&gt;
Modules linked in:
---[ end trace 0000000000000000 ]---
 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline]
 RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914
Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df &lt;80&gt; 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06
RSP: 0018:ffffc900047374e0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000
RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0
R
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-47707</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

can: bcm: Clear bo-&gt;bcm_proc_read after remove_proc_entry().

syzbot reported a warning in bcm_release(). [0]

The blamed change fixed another warning that is triggered when
connect() is issued again for a socket whose connect()ed device has
been unregistered.

However, if the socket is just close()d without the 2nd connect(), the
remaining bo-&gt;bcm_proc_read triggers unnecessary remove_proc_entry()
in bcm_release().

Let's clear bo-&gt;bcm_proc_read after remove_proc_entry() in bcm_notify().

[0]
name '4986'
WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711
Modules linked in:
CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711
Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 &lt;0f&gt; 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07
RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246
RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a
R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640
R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000
FS:  0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 bcm_release+0x250/0x880 net/can/bcm.c:1578
 __sock_release net/socket.c:659 [inline]
 sock_close+0xbc/0x240 net/socket.c:1421
 __fput+0x24a/0x8a0 fs/file_table.c:422
 task_work_run+0x24f/0x310 kernel/task_work.c:228
 exit_task_work include/linux/task_work.h:40 [inline]
 do_exit+0xa2f/0x27f0 kernel/exit.c:882
 do_group_exit+0x207/0x2c0 kernel/exit.c:1031
 __do_sys_exit_group kernel/exit.c:1042 [inline]
 __se_sys_exit_group kernel/exit.c:1040 [inline]
 __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040
 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232
 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
RIP: 0033:0x7fcfb51ee969
Code: Unable to access opcode bytes at 0x7fcfb51ee93f.
RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969
RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001
RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000
R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0
R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-47709</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sock_map: Add a cond_resched() in sock_hash_free()

Several syzbot soft lockup reports all have in common sock_hash_free()

If a map with a large number of buckets is destroyed, we need to yield
the cpu when needed.</Note>
    </Notes>
    <CVE>CVE-2024-47710</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param

In the `wilc_parse_join_bss_param` function, the TSF field of the `ies`
structure is accessed after the RCU read-side critical section is
unlocked. According to RCU usage rules, this is illegal. Reusing this
pointer can lead to unpredictable behavior, including accessing memory
that has been updated or causing use-after-free issues.

This possible bug was identified using a static analysis tool developed
by myself, specifically designed to detect RCU-related issues.

To address this, the TSF value is now stored in a local variable
`ies_tsf` before the RCU lock is released. The `param-&gt;tsf_lo` field is
then assigned using this local variable, ensuring that the TSF value is
safely accessed.</Note>
    </Notes>
    <CVE>CVE-2024-47712</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()

Since '__dev_queue_xmit()' should be called with interrupts enabled,
the following backtrace:

ieee80211_do_stop()
 ...
 spin_lock_irqsave(&amp;local-&gt;queue_stop_reason_lock, flags)
 ...
 ieee80211_free_txskb()
  ieee80211_report_used_skb()
   ieee80211_report_ack_skb()
    cfg80211_mgmt_tx_status_ext()
     nl80211_frame_tx_status()
      genlmsg_multicast_netns()
       genlmsg_multicast_netns_filtered()
        nlmsg_multicast_filtered()
	 netlink_broadcast_filtered()
	  do_one_broadcast()
	   netlink_broadcast_deliver()
	    __netlink_sendskb()
	     netlink_deliver_tap()
	      __netlink_deliver_tap_skb()
	       dev_queue_xmit()
	        __dev_queue_xmit() ; with IRQS disabled
 ...
 spin_unlock_irqrestore(&amp;local-&gt;queue_stop_reason_lock, flags)

issues the warning (as reported by syzbot reproducer):

WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120

Fix this by implementing a two-phase skb reclamation in
'ieee80211_do_stop()', where actual work is performed
outside of a section with interrupts disabled.</Note>
    </Notes>
    <CVE>CVE-2024-47713</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7996: use hweight16 to get correct tx antenna

The chainmask is u16 so using hweight8 cannot get correct tx_ant.
Without this patch, the tx_ant of band 2 would be -1 and lead to the
following issue:
BUG: KASAN: stack-out-of-bounds in mt7996_mcu_add_sta+0x12e0/0x16e0 [mt7996e]</Note>
    </Notes>
    <CVE>CVE-2024-47714</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7915: fix oops on non-dbdc mt7986

mt7915_band_config() sets band_idx = 1 on the main phy for mt7986
with MT7975_ONE_ADIE or MT7976_ONE_ADIE.

Commit 0335c034e726 ("wifi: mt76: fix race condition related to
checking tx queue fill status") introduced a dereference of the
phys array indirectly indexed by band_idx via wcid-&gt;phy_idx in
mt76_wcid_cleanup(). This caused the following Oops on affected
mt7986 devices:

 Unable to handle kernel read from unreadable memory at virtual address 0000000000000024
 Mem abort info:
   ESR = 0x0000000096000005
   EC = 0x25: DABT (current EL), IL = 32 bits
   SET = 0, FnV = 0
   EA = 0, S1PTW = 0
   FSC = 0x05: level 1 translation fault
 Data abort info:
   ISV = 0, ISS = 0x00000005
   CM = 0, WnR = 0
 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000
 [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
 Internal error: Oops: 0000000096000005 [#1] SMP
 Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ...
 CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0
 Hardware name: ZyXEL EX5700 (Telenor) (DT)
 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : mt76_wcid_cleanup+0x84/0x22c [mt76]
 lr : mt76_wcid_cleanup+0x64/0x22c [mt76]
 sp : ffffffc00a803700
 x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00
 x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001
 x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8
 x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000
 x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0
 x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000
 x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28
 x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000
 x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001
 x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024
 Call trace:
  mt76_wcid_cleanup+0x84/0x22c [mt76]
  __mt76_sta_remove+0x70/0xbc [mt76]
  mt76_sta_state+0x8c/0x1a4 [mt76]
  mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e]
  drv_sta_state+0x144/0x274 [mac80211]
  sta_info_move_state+0x1cc/0x2a4 [mac80211]
  sta_set_sinfo+0xaf8/0xc24 [mac80211]
  sta_info_destroy_addr_bss+0x4c/0x6c [mac80211]

  ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211]
  cfg80211_check_station_change+0x1360/0x4710 [cfg80211]
  genl_family_rcv_msg_doit+0xb4/0x110
  genl_rcv_msg+0xd0/0x1bc
  netlink_rcv_skb+0x58/0x120
  genl_rcv+0x34/0x50
  netlink_unicast+0x1f0/0x2ec
  netlink_sendmsg+0x198/0x3d0
  ____sys_sendmsg+0x1b0/0x210
  ___sys_sendmsg+0x80/0xf0
  __sys_sendmsg+0x44/0xa0
  __arm64_sys_sendmsg+0x20/0x30
  invoke_syscall.constprop.0+0x4c/0xe0
  do_el0_svc+0x40/0xd0
  el0_svc+0x14/0x4c
  el0t_64_sync_handler+0x100/0x110
  el0t_64_sync+0x15c/0x160
 Code: d2800002 910092c0 52800023 f9800011 (885f7c01)
 ---[ end trace 7e42dd9a39ed2281 ]---

Fix by using mt76_dev_phy() which will map band_idx to the correct phy
for all hardware combinations.</Note>
    </Notes>
    <CVE>CVE-2024-47715</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: rtw88: always wait for both firmware loading attempts

In 'rtw_wait_firmware_completion()', always wait for both (regular and
wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()'
has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue
'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually
the wowlan one) is still in progress, causing UAF detected by KASAN.</Note>
    </Notes>
    <CVE>CVE-2024-47718</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iommufd: Protect against overflow of ALIGN() during iova allocation

Userspace can supply an iova and uptr such that the target iova alignment
becomes really big and ALIGN() overflows which corrupts the selected area
range during allocation. CONFIG_IOMMUFD_TEST can detect this:

   WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline]
   WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352
   Modules linked in:
   CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0
   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024
   RIP: 0010:iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline]
   RIP: 0010:iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352
   Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 &lt;0f&gt; 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38
   RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293
   RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00
   RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000
   RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942
   R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010
   R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00
   FS:  000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
   CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0
   DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
   DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
   Call Trace:
    &lt;TASK&gt;
    iommufd_ioas_copy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274
    iommufd_fops_ioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421
    vfs_ioctl fs/ioctl.c:51 [inline]
    __do_sys_ioctl fs/ioctl.c:907 [inline]
    __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
    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

Cap the automatic alignment to the huge page size, which is probably a
better idea overall. Huge automatic alignments can fragment and chew up
the available IOVA space without any reason.</Note>
    </Notes>
    <CVE>CVE-2024-47719</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func

This commit adds a null check for the set_output_gamma function pointer
in the  dcn30_set_output_transfer_func function. Previously,
set_output_gamma was being checked for nullity at line 386, but then it
was being dereferenced without any nullity check at line 401. This
could potentially lead to a null pointer dereference error if
set_output_gamma is indeed null.

To fix this, we now ensure that set_output_gamma is not null before
dereferencing it. We do this by adding a nullity check for
set_output_gamma before the call to set_output_gamma at line 401. If
set_output_gamma is null, we log an error message and do not call the
function.

This fix prevents a potential null pointer dereference error.

drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func()
error: we previously assumed 'mpc-&gt;funcs-&gt;set_output_gamma' could be null (see line 386)

drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c
    373 bool dcn30_set_output_transfer_func(struct dc *dc,
    374                                 struct pipe_ctx *pipe_ctx,
    375                                 const struct dc_stream_state *stream)
    376 {
    377         int mpcc_id = pipe_ctx-&gt;plane_res.hubp-&gt;inst;
    378         struct mpc *mpc = pipe_ctx-&gt;stream_res.opp-&gt;ctx-&gt;dc-&gt;res_pool-&gt;mpc;
    379         const struct pwl_params *params = NULL;
    380         bool ret = false;
    381
    382         /* program OGAM or 3DLUT only for the top pipe*/
    383         if (pipe_ctx-&gt;top_pipe == NULL) {
    384                 /*program rmu shaper and 3dlut in MPC*/
    385                 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream);
    386                 if (ret == false &amp;&amp; mpc-&gt;funcs-&gt;set_output_gamma) {
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL

    387                         if (stream-&gt;out_transfer_func.type == TF_TYPE_HWPWL)
    388                                 params = &amp;stream-&gt;out_transfer_func.pwl;
    389                         else if (pipe_ctx-&gt;stream-&gt;out_transfer_func.type ==
    390                                         TF_TYPE_DISTRIBUTED_POINTS &amp;&amp;
    391                                         cm3_helper_translate_curve_to_hw_format(
    392                                         &amp;stream-&gt;out_transfer_func,
    393                                         &amp;mpc-&gt;blender_params, false))
    394                                 params = &amp;mpc-&gt;blender_params;
    395                          /* there are no ROM LUTs in OUTGAM */
    396                         if (stream-&gt;out_transfer_func.type == TF_TYPE_PREDEFINED)
    397                                 BREAK_TO_DEBUGGER();
    398                 }
    399         }
    400
--&gt; 401         mpc-&gt;funcs-&gt;set_output_gamma(mpc, mpcc_id, params);
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash

    402         return ret;
    403 }</Note>
    </Notes>
    <CVE>CVE-2024-47720</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

jfs: fix out-of-bounds in dbNextAG() and diAlloc()

In dbNextAG() , there is no check for the case where bmp-&gt;db_numag is
greater or same than MAXAG due to a polluted image, which causes an
out-of-bounds. Therefore, a bounds check should be added in dbMount().

And in dbNextAG(), a check for the case where agpref is greater than
bmp-&gt;db_numag should be added, so an out-of-bounds exception should be
prevented.

Additionally, a check for the case where agno is greater or same than
MAXAG should be added in diAlloc() to prevent out-of-bounds.</Note>
    </Notes>
    <CVE>CVE-2024-47723</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

x86/tdx: Fix "in-kernel MMIO" check

TDX only supports kernel-initiated MMIO operations. The handle_mmio()
function checks if the #VE exception occurred in the kernel and rejects
the operation if it did not.

However, userspace can deceive the kernel into performing MMIO on its
behalf. For example, if userspace can point a syscall to an MMIO address,
syscall does get_user() or put_user() on it, triggering MMIO #VE. The
kernel will treat the #VE as in-kernel MMIO.

Ensure that the target MMIO address is within the kernel before decoding
instruction.</Note>
    </Notes>
    <CVE>CVE-2024-47727</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error

For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input
arguments, zero the value for the case of an error as otherwise it could leak
memory. For tracing, it is not needed given CAP_PERFMON can already read all
kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped
in here.

Also, the MTU helpers mtu_len pointer value is being written but also read.
Technically, the MEM_UNINIT should not be there in order to always force init.
Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now
implies two things actually: i) write into memory, ii) memory does not have
to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory,
ii) memory must be initialized. This means that for bpf_*_check_mtu() we're
readding the issue we're trying to fix, that is, it would then be able to
write back into things like .rodata BPF maps. Follow-up work will rework the
MEM_UNINIT semantics such that the intent can be better expressed. For now
just clear the *mtu_len on error path which can be lifted later again.</Note>
    </Notes>
    <CVE>CVE-2024-47728</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

crypto: hisilicon/qm - inject error before stopping queue

The master ooo cannot be completely closed when the
accelerator core reports memory error. Therefore, the driver
needs to inject the qm error to close the master ooo. Currently,
the qm error is injected after stopping queue, memory may be
released immediately after stopping queue, causing the device to
access the released memory. Therefore, error is injected to close master
ooo before stopping queue to ensure that the device does not access
the released memory.</Note>
    </Notes>
    <CVE>CVE-2024-47730</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drivers/perf: Fix ali_drw_pmu driver interrupt status clearing

The alibaba_uncore_pmu driver forgot to clear all interrupt status
in the interrupt processing function. After the PMU counter overflow
interrupt occurred, an interrupt storm occurred, causing the system
to hang.

Therefore, clear the correct interrupt status in the interrupt handling
function to fix it.</Note>
    </Notes>
    <CVE>CVE-2024-47731</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

crypto: iaa - Fix potential use after free bug

The free_device_compression_mode(iaa_device, device_mode) function frees
"device_mode" but it iss passed to iaa_compression_modes[i]-&gt;free() a few
lines later resulting in a use after free.

The good news is that, so far as I can tell, nothing implements the
-&gt;free() function and the use after free happens in dead code.  But, with
this fix, when something does implement it, we'll be ready.  :)</Note>
    </Notes>
    <CVE>CVE-2024-47732</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled

Fix missuse of spin_lock_irq()/spin_unlock_irq() when
spin_lock_irqsave()/spin_lock_irqrestore() was hold.

This was discovered through the lock debugging, and the corresponding
log is as follows:

raw_local_irq_restore() called with IRQs enabled
WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40
...
Call trace:
 warn_bogus_irq_restore+0x30/0x40
 _raw_spin_unlock_irqrestore+0x84/0xc8
 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2]
 hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2]
 hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2]
 create_qp+0x138/0x258
 ib_create_qp_kernel+0x50/0xe8
 create_mad_qp+0xa8/0x128
 ib_mad_port_open+0x218/0x448
 ib_mad_init_device+0x70/0x1f8
 add_client_context+0xfc/0x220
 enable_device_and_get+0xd0/0x140
 ib_register_device.part.0+0xf4/0x1c8
 ib_register_device+0x34/0x50
 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2]
 hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2]
 __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2]
 hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]</Note>
    </Notes>
    <CVE>CVE-2024-47735</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfsd: call cache_put if xdr_reserve_space returns NULL

If not enough buffer space available, but idmap_lookup has triggered
lookup_fn which calls cache_get and returns successfully. Then we
missed to call cache_put here which pairs with cache_get.

Reviwed-by: Jeff Layton &lt;jlayton@kernel.org&gt;</Note>
    </Notes>
    <CVE>CVE-2024-47737</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: don't use rate mask for offchannel TX either

Like the commit ab9177d83c04 ("wifi: mac80211: don't use rate mask for
scanning"), ignore incorrect settings to avoid no supported rate warning
reported by syzbot.

The syzbot did bisect and found cause is commit 9df66d5b9f45 ("cfg80211:
fix default HE tx bitrate mask in 2G band"), which however corrects
bitmask of HE MCS and recognizes correctly settings of empty legacy rate
plus HE MCS rate instead of returning -EINVAL.

As suggestions [1], follow the change of SCAN TX to consider this case of
offchannel TX as well.

[1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024</Note>
    </Notes>
    <CVE>CVE-2024-47738</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

padata: use integer wrap around to prevent deadlock on seq_nr overflow

When submitting more than 2^32 padata objects to padata_do_serial, the
current sorting implementation incorrectly sorts padata objects with
overflowed seq_nr, causing them to be placed before existing objects in
the reorder list. This leads to a deadlock in the serialization process
as padata_find_next cannot match padata-&gt;seq_nr and pd-&gt;processed
because the padata instance with overflowed seq_nr will be selected
next.

To fix this, we use an unsigned integer wrap around to correctly sort
padata objects in scenarios with integer overflow.</Note>
    </Notes>
    <CVE>CVE-2024-47739</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix race setting file private on concurrent lseek using same fd

When doing concurrent lseek(2) system calls against the same file
descriptor, using multiple threads belonging to the same process, we have
a short time window where a race happens and can result in a memory leak.

The race happens like this:

1) A program opens a file descriptor for a file and then spawns two
   threads (with the pthreads library for example), lets call them
   task A and task B;

2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at
   file.c:find_desired_extent() while holding a read lock on the inode;

3) At the start of find_desired_extent(), it extracts the file's
   private_data pointer into a local variable named 'private', which has
   a value of NULL;

4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode
   in shared mode and enters file.c:find_desired_extent(), where it also
   extracts file-&gt;private_data into its local variable 'private', which
   has a NULL value;

5) Because it saw a NULL file private, task A allocates a private
   structure and assigns to the file structure;

6) Task B also saw a NULL file private so it also allocates its own file
   private and then assigns it to the same file structure, since both
   tasks are using the same file descriptor.

   At this point we leak the private structure allocated by task A.

Besides the memory leak, there's also the detail that both tasks end up
using the same cached state record in the private structure (struct
btrfs_file_private::llseek_cached_state), which can result in a
use-after-free problem since one task can free it while the other is
still using it (only one task took a reference count on it). Also, sharing
the cached state is not a good idea since it could result in incorrect
results in the future - right now it should not be a problem because it
end ups being used only in extent-io-tree.c:count_range_bits() where we do
range validation before using the cached state.

Fix this by protecting the private assignment and check of a file while
holding the inode's spinlock and keep track of the task that allocated
the private, so that it's used only by that task in order to prevent
user-after-free issues with the cached state record as well as potentially
using it incorrectly in the future.</Note>
    </Notes>
    <CVE>CVE-2024-47741</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

firmware_loader: Block path traversal

Most firmware names are hardcoded strings, or are constructed from fairly
constrained format strings where the dynamic parts are just some hex
numbers or such.

However, there are a couple codepaths in the kernel where firmware file
names contain string components that are passed through from a device or
semi-privileged userspace; the ones I could find (not counting interfaces
that require root privileges) are:

 - lpfc_sli4_request_firmware_update() seems to construct the firmware
   filename from "ModelName", a string that was previously parsed out of
   some descriptor ("Vital Product Data") in lpfc_fill_vpd()
 - nfp_net_fw_find() seems to construct a firmware filename from a model
   name coming from nfp_hwinfo_lookup(pf-&gt;hwinfo, "nffw.partno"), which I
   think parses some descriptor that was read from the device.
   (But this case likely isn't exploitable because the format string looks
   like "netronome/nic_%s", and there shouldn't be any *folders* starting
   with "netronome/nic_". The previous case was different because there,
   the "%s" is *at the start* of the format string.)
 - module_flash_fw_schedule() is reachable from the
   ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as
   GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is
   enough to pass the privilege check), and takes a userspace-provided
   firmware name.
   (But I think to reach this case, you need to have CAP_NET_ADMIN over a
   network namespace that a special kind of ethernet device is mapped into,
   so I think this is not a viable attack path in practice.)

Fix it by rejecting any firmware names containing ".." path components.

For what it's worth, I went looking and haven't found any USB device
drivers that use the firmware loader dangerously.</Note>
    </Notes>
    <CVE>CVE-2024-47742</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

KEYS: prevent NULL pointer dereference in find_asymmetric_key()

In find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2}
arguments, the kernel will first emit WARN but then have an oops
because id_2 gets dereferenced anyway.

Add the missing id_2 check and move WARN_ON() to the final else branch
to avoid duplicate NULL checks.

Found by Linux Verification Center (linuxtesting.org) with Svace static
analysis tool.</Note>
    </Notes>
    <CVE>CVE-2024-47743</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock

Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock
on x86 due to a chain of locks and SRCU synchronizations.  Translating the
below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on
CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the
fairness of r/w semaphores).

    CPU0                     CPU1                     CPU2
1   lock(&amp;kvm-&gt;slots_lock);
2                                                     lock(&amp;vcpu-&gt;mutex);
3                                                     lock(&amp;kvm-&gt;srcu);
4                            lock(cpu_hotplug_lock);
5                            lock(kvm_lock);
6                            lock(&amp;kvm-&gt;slots_lock);
7                                                     lock(cpu_hotplug_lock);
8   sync(&amp;kvm-&gt;srcu);

Note, there are likely more potential deadlocks in KVM x86, e.g. the same
pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with
__kvmclock_cpufreq_notifier():

  cpuhp_cpufreq_online()
  |
  -&gt; cpufreq_online()
     |
     -&gt; cpufreq_gov_performance_limits()
        |
        -&gt; __cpufreq_driver_target()
           |
           -&gt; __target_index()
              |
              -&gt; cpufreq_freq_transition_begin()
                 |
                 -&gt; cpufreq_notify_transition()
                    |
                    -&gt; ... __kvmclock_cpufreq_notifier()

But, actually triggering such deadlocks is beyond rare due to the
combination of dependencies and timings involved.  E.g. the cpufreq
notifier is only used on older CPUs without a constant TSC, mucking with
the NX hugepage mitigation while VMs are running is very uncommon, and
doing so while also onlining/offlining a CPU (necessary to generate
contention on cpu_hotplug_lock) would be even more unusual.

The most robust solution to the general cpu_hotplug_lock issue is likely
to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq
notifier doesn't to take kvm_lock.  For now, settle for fixing the most
blatant deadlock, as switching to an RCU-protected list is a much more
involved change, but add a comment in locking.rst to call out that care
needs to be taken when walking holding kvm_lock and walking vm_list.

  ======================================================
  WARNING: possible circular locking dependency detected
  6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S         O
  ------------------------------------------------------
  tee/35048 is trying to acquire lock:
  ff6a80eced71e0a8 (&amp;kvm-&gt;slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm]

  but task is already holding lock:
  ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm]

  which lock already depends on the new lock.

   the existing dependency chain (in reverse order) is:

  -&gt; #3 (kvm_lock){+.+.}-{3:3}:
         __mutex_lock+0x6a/0xb40
         mutex_lock_nested+0x1f/0x30
         kvm_dev_ioctl+0x4fb/0xe50 [kvm]
         __se_sys_ioctl+0x7b/0xd0
         __x64_sys_ioctl+0x21/0x30
         x64_sys_call+0x15d0/0x2e60
         do_syscall_64+0x83/0x160
         entry_SYSCALL_64_after_hwframe+0x76/0x7e

  -&gt; #2 (cpu_hotplug_lock){++++}-{0:0}:
         cpus_read_lock+0x2e/0xb0
         static_key_slow_inc+0x16/0x30
         kvm_lapic_set_base+0x6a/0x1c0 [kvm]
         kvm_set_apic_base+0x8f/0xe0 [kvm]
         kvm_set_msr_common+0x9ae/0xf80 [kvm]
         vmx_set_msr+0xa54/0xbe0 [kvm_intel]
         __kvm_set_msr+0xb6/0x1a0 [kvm]
         kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm]
         kvm_vcpu_ioctl+0x485/0x5b0 [kvm]
         __se_sys_ioctl+0x7b/0xd0
         __x64_sys_ioctl+0x21/0x30
         x64_sys_call+0x15d0/0x2e60
         do_syscall_64+0x83/0x160
         entry_SYSCALL_64_after_hwframe+0x76/0x7e

  -&gt; #1 (&amp;kvm-&gt;srcu){.+.+}-{0:0}:
         __synchronize_srcu+0x44/0x1a0
      
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-47744</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm: call the security_mmap_file() LSM hook in remap_file_pages()

The remap_file_pages syscall handler calls do_mmap() directly, which
doesn't contain the LSM security check. And if the process has called
personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for
RW pages, this will actually result in remapping the pages to RWX,
bypassing a W^X policy enforced by SELinux.

So we should check prot by security_mmap_file LSM hook in the
remap_file_pages syscall handler before do_mmap() is called. Otherwise, it
potentially permits an attacker to bypass a W^X policy enforced by
SELinux.

The bypass is similar to CVE-2016-10044, which bypass the same thing via
AIO and can be found in [1].

The PoC:

$ cat &gt; test.c

int main(void) {
	size_t pagesz = sysconf(_SC_PAGE_SIZE);
	int mfd = syscall(SYS_memfd_create, "test", 0);
	const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE,
		MAP_SHARED, mfd, 0);
	unsigned int old = syscall(SYS_personality, 0xffffffff);
	syscall(SYS_personality, READ_IMPLIES_EXEC | old);
	syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0);
	syscall(SYS_personality, old);
	// show the RWX page exists even if W^X policy is enforced
	int fd = open("/proc/self/maps", O_RDONLY);
	unsigned char buf2[1024];
	while (1) {
		int ret = read(fd, buf2, 1024);
		if (ret &lt;= 0) break;
		write(1, buf2, ret);
	}
	close(fd);
}

$ gcc test.c -o test
$ ./test | grep rwx
7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted)

[PM: subject line tweaks]</Note>
    </Notes>
    <CVE>CVE-2024-47745</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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 &amp;prev(dev)-&gt;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)-&gt;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.</Note>
    </Notes>
    <CVE>CVE-2024-47747</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-47748</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/cxgb4: Added NULL check for lookup_atid

The lookup_atid() function can return NULL if the ATID is
invalid or does not exist in the identifier table, which
could lead to dereferencing a null pointer without a
check in the `act_establish()` and `act_open_rpl()` functions.
Add a NULL check to prevent null pointer dereferencing.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2024-47749</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08

Currently rsv_qp is freed before ib_unregister_device() is called
on HIP08. During the time interval, users can still dereg MR and
rsv_qp will be used in this process, leading to a UAF. Move the
release of rsv_qp after calling ib_unregister_device() to fix it.</Note>
    </Notes>
    <CVE>CVE-2024-47750</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port()

Within kirin_pcie_parse_port(), the pcie-&gt;num_slots is compared to
pcie-&gt;gpio_id_reset size (MAX_PCI_SLOTS) which is correct and would lead
to an overflow.

Thus, fix condition to pcie-&gt;num_slots + 1 &gt;= MAX_PCI_SLOTS and move
pcie-&gt;num_slots increment below the if-statement to avoid out-of-bounds
array access.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

[kwilczynski: commit log]</Note>
    </Notes>
    <CVE>CVE-2024-47751</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: mediatek: vcodec: Fix H264 stateless decoder smatch warning

Fix a smatch static checker warning on vdec_h264_req_if.c.
Which leads to a kernel crash when fb is NULL.</Note>
    </Notes>
    <CVE>CVE-2024-47752</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning

Fix a smatch static checker warning on vdec_vp8_req_if.c.
Which leads to a kernel crash when fb is NULL.</Note>
    </Notes>
    <CVE>CVE-2024-47753</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning

Fix a smatch static checker warning on vdec_h264_req_multi_if.c.
Which leads to a kernel crash when fb is NULL.</Note>
    </Notes>
    <CVE>CVE-2024-47754</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

PCI: keystone: Fix if-statement expression in ks_pcie_quirk()

This code accidentally uses &amp;&amp; where || was intended.  It potentially
results in a NULL dereference.

Thus, fix the if-statement expression to use the correct condition.

[kwilczynski: commit log]</Note>
    </Notes>
    <CVE>CVE-2024-47756</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-47757</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Vim is an open source, command line text editor. A use-after-free was found in Vim &lt; 9.1.0764. When closing a buffer (visible in a window) a BufWinLeave auto command can cause an use-after-free if this auto command happens to re-open the same buffer in a new split window. Impact is low since the user must have intentionally set up such a strange auto command and run some buffer unload commands. However this may lead to a crash. This issue has been addressed in version 9.1.0764 and all users are advised to upgrade. There are no known workarounds for this vulnerability.</Note>
    </Notes>
    <CVE>CVE-2024-47814</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:vim-9.1.0836-150500.20.18.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:vim-data-common-9.1.0836-150500.20.18.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos

In case of malformed relocation record of kind BPF_CORE_TYPE_ID_LOCAL
referencing a non-existing BTF type, function bpf_core_calc_relo_insn
would cause a null pointer deference.

Fix this by adding a proper check upper in call stack, as malformed
relocation records could be passed from user space.

Simplest reproducer is a program:

    r0 = 0
    exit

With a single relocation record:

    .insn_off = 0,          /* patch first instruction */
    .type_id = 100500,      /* this type id does not exist */
    .access_str_off = 6,    /* offset of string "0" */
    .kind = BPF_CORE_TYPE_ID_LOCAL,

See the link for original reproducer or next commit for a test case.</Note>
    </Notes>
    <CVE>CVE-2024-49850</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tpm: Clean up TPM space after command failure

tpm_dev_transmit prepares the TPM space before attempting command
transmission. However if the command fails no rollback of this
preparation is done. This can result in transient handles being leaked
if the device is subsequently closed with no further commands performed.

Fix this by flushing the space in the event of command transmission
failure.</Note>
    </Notes>
    <CVE>CVE-2024-49851</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del()

The kref_put() function will call nport-&gt;release if the refcount drops to
zero.  The nport-&gt;release release function is _efc_nport_free() which frees
"nport".  But then we dereference "nport" on the next line which is a use
after free.  Re-order these lines to avoid the use after free.</Note>
    </Notes>
    <CVE>CVE-2024-49852</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

firmware: arm_scmi: Fix double free in OPTEE transport

Channels can be shared between protocols, avoid freeing the same channel
descriptors twice when unloading the stack.</Note>
    </Notes>
    <CVE>CVE-2024-49853</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

block, bfq: fix uaf for accessing waker_bfqq after splitting

After commit 42c306ed7233 ("block, bfq: don't break merge chain in
bfq_split_bfqq()"), if the current procress is the last holder of bfqq,
the bfqq can be freed after bfq_split_bfqq(). Hence recored the bfqq and
then access bfqq-&gt;waker_bfqq may trigger UAF. What's more, the waker_bfqq
may in the merge chain of bfqq, hence just recored waker_bfqq is still
not safe.

Fix the problem by adding a helper bfq_waker_bfqq() to check if
bfqq-&gt;waker_bfqq is in the merge chain, and current procress is the only
holder.</Note>
    </Notes>
    <CVE>CVE-2024-49854</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nbd: fix race between timeout and normal completion

If request timetout is handled by nbd_requeue_cmd(), normal completion
has to be stopped for avoiding to complete this requeued request, other
use-after-free can be triggered.

Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime
make sure that cmd-&gt;lock is grabbed for clearing the flag and the
requeue.</Note>
    </Notes>
    <CVE>CVE-2024-49855</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption

The TPM event log table is a Linux specific construct, where the data
produced by the GetEventLog() boot service is cached in memory, and
passed on to the OS using an EFI configuration table.

The use of EFI_LOADER_DATA here results in the region being left
unreserved in the E820 memory map constructed by the EFI stub, and this
is the memory description that is passed on to the incoming kernel by
kexec, which is therefore unaware that the region should be reserved.

Even though the utility of the TPM2 event log after a kexec is
questionable, any corruption might send the parsing code off into the
weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY
instead, which is always treated as reserved by the E820 conversion
logic.</Note>
    </Notes>
    <CVE>CVE-2024-49858</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-49860</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix helper writes to read-only maps

Lonial found an issue that despite user- and BPF-side frozen BPF map
(like in case of .rodata), it was still possible to write into it from
a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT}
as arguments.

In check_func_arg() when the argument is as mentioned, the meta-&gt;raw_mode
is never set. Later, check_helper_mem_access(), under the case of
PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the
subsequent call to check_map_access_type() and given the BPF map is
read-only it succeeds.

The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT
when results are written into them as opposed to read out of them. The
latter indicates that it's okay to pass a pointer to uninitialized memory
as the memory is written to anyway.

However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM
just with additional alignment requirement. So it is better to just get
rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the
fixed size memory types. For this, add MEM_ALIGNED to additionally ensure
alignment given these helpers write directly into the args via *&lt;ptr&gt; = val.
The .arg*_size has been initialized reflecting the actual sizeof(*&lt;ptr&gt;).

MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated
argument types, since in !MEM_FIXED_SIZE cases the verifier does not know
the buffer size a priori and therefore cannot blindly write *&lt;ptr&gt; = val.</Note>
    </Notes>
    <CVE>CVE-2024-49861</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

powercap: intel_rapl: Fix off by one in get_rpi()

The rp-&gt;priv-&gt;rpi array is either rpi_msr or rpi_tpmi which have
NR_RAPL_PRIMITIVES number of elements.  Thus the &gt; needs to be &gt;=
to prevent an off by one access.</Note>
    </Notes>
    <CVE>CVE-2024-49862</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()

Since commit 3f8ca2e115e5 ("vhost/scsi: Extract common handling code
from control queue handler") a null pointer dereference bug can be
triggered when guest sends an SCSI AN request.

In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with
`&amp;v_req.tmf.lun[1]` within a switch-case block and is then passed to
vhost_scsi_get_req() which extracts `vc-&gt;req` and `tpg`. However, for
a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is
set to NULL in this branch. Later, in vhost_scsi_get_req(),
`vc-&gt;target` is dereferenced without being checked, leading to a null
pointer dereference bug. This bug can be triggered from guest.

When this bug occurs, the vhost_worker process is killed while holding
`vq-&gt;mutex` and the corresponding tpg will remain occupied
indefinitely.

Below is the KASAN report:
Oops: general protection fault, probably for non-canonical address
0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1
Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS
1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:vhost_scsi_get_req+0x165/0x3a0
Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00
48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 &lt;0f&gt; b6
04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00
RSP: 0018:ffff888017affb50 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8
RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000
FS:  000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0
Call Trace:
 &lt;TASK&gt;
 ? show_regs+0x86/0xa0
 ? die_addr+0x4b/0xd0
 ? exc_general_protection+0x163/0x260
 ? asm_exc_general_protection+0x27/0x30
 ? vhost_scsi_get_req+0x165/0x3a0
 vhost_scsi_ctl_handle_vq+0x2a4/0xca0
 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10
 ? __switch_to+0x721/0xeb0
 ? __schedule+0xda5/0x5710
 ? __kasan_check_write+0x14/0x30
 ? _raw_spin_lock+0x82/0xf0
 vhost_scsi_ctl_handle_kick+0x52/0x90
 vhost_run_work_list+0x134/0x1b0
 vhost_task_fn+0x121/0x350
...
 &lt;/TASK&gt;
---[ end trace 0000000000000000 ]---

Let's add a check in vhost_scsi_get_req.

[whitespace fixes]</Note>
    </Notes>
    <CVE>CVE-2024-49863</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

rxrpc: Fix a race between socket set up and I/O thread creation

In rxrpc_open_socket(), it sets up the socket and then sets up the I/O
thread that will handle it.  This is a problem, however, as there's a gap
between the two phases in which a packet may come into rxrpc_encap_rcv()
from the UDP packet but we oops when trying to wake the not-yet created I/O
thread.

As a quick fix, just make rxrpc_encap_rcv() discard the packet if there's
no I/O thread yet.

A better, but more intrusive fix would perhaps be to rearrange things such
that the socket creation is done by the I/O thread.</Note>
    </Notes>
    <CVE>CVE-2024-49864</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tracing/timerlat: Fix a race during cpuhp processing

There is another found exception that the "timerlat/1" thread was
scheduled on CPU0, and lead to timer corruption finally:

```
ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220
WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0
Modules linked in:
CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:debug_print_object+0x7d/0xb0
...
Call Trace:
 &lt;TASK&gt;
 ? __warn+0x7c/0x110
 ? debug_print_object+0x7d/0xb0
 ? report_bug+0xf1/0x1d0
 ? prb_read_valid+0x17/0x20
 ? handle_bug+0x3f/0x70
 ? exc_invalid_op+0x13/0x60
 ? asm_exc_invalid_op+0x16/0x20
 ? debug_print_object+0x7d/0xb0
 ? debug_print_object+0x7d/0xb0
 ? __pfx_timerlat_irq+0x10/0x10
 __debug_object_init+0x110/0x150
 hrtimer_init+0x1d/0x60
 timerlat_main+0xab/0x2d0
 ? __pfx_timerlat_main+0x10/0x10
 kthread+0xb7/0xe0
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x2d/0x40
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;
```

After tracing the scheduling event, it was discovered that the migration
of the "timerlat/1" thread was performed during thread creation. Further
analysis confirmed that it is because the CPU online processing for
osnoise is implemented through workers, which is asynchronous with the
offline processing. When the worker was scheduled to create a thread, the
CPU may has already been removed from the cpu_online_mask during the offline
process, resulting in the inability to select the right CPU:

T1                       | T2
[CPUHP_ONLINE]           | cpu_device_down()
osnoise_hotplug_workfn() |
                         |     cpus_write_lock()
                         |     takedown_cpu(1)
                         |     cpus_write_unlock()
[CPUHP_OFFLINE]          |
    cpus_read_lock()     |
    start_kthread(1)     |
    cpus_read_unlock()   |

To fix this, skip online processing if the CPU is already offline.</Note>
    </Notes>
    <CVE>CVE-2024-49866</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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:
   &lt;TASK&gt;
   __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
   &lt;/TASK&gt;

  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---</Note>
    </Notes>
    <CVE>CVE-2024-49867</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix a NULL pointer dereference when failed to start a new trasacntion

[BUG]
Syzbot reported a NULL pointer dereference with the following crash:

  FAULT_INJECTION: forcing a failure.
   start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676
   prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642
   relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678
  ...
  BTRFS info (device loop0): balance: ended with status: -12
  Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI
  KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667]
  RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926
  Call Trace:
   &lt;TASK&gt;
   commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496
   btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430
   del_balance_item fs/btrfs/volumes.c:3678 [inline]
   reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742
   btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574
   btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673
   vfs_ioctl fs/ioctl.c:51 [inline]
   __do_sys_ioctl fs/ioctl.c:907 [inline]
   __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893
   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

[CAUSE]
The allocation failure happens at the start_transaction() inside
prepare_to_relocate(), and during the error handling we call
unset_reloc_control(), which makes fs_info-&gt;balance_ctl to be NULL.

Then we continue the error path cleanup in btrfs_balance() by calling
reset_balance_state() which will call del_balance_item() to fully delete
the balance item in the root tree.

However during the small window between set_reloc_contrl() and
unset_reloc_control(), we can have a subvolume tree update and created a
reloc_root for that subvolume.

Then we go into the final btrfs_commit_transaction() of
del_balance_item(), and into btrfs_update_reloc_root() inside
commit_fs_roots().

That function checks if fs_info-&gt;reloc_ctl is in the merge_reloc_tree
stage, but since fs_info-&gt;reloc_ctl is NULL, it results a NULL pointer
dereference.

[FIX]
Just add extra check on fs_info-&gt;reloc_ctl inside
btrfs_update_reloc_root(), before checking
fs_info-&gt;reloc_ctl-&gt;merge_reloc_tree.

That DEAD_RELOC_TREE handling is to prevent further modification to the
reloc tree during merge stage, but since there is no reloc_ctl at all,
we do not need to bother that.</Note>
    </Notes>
    <CVE>CVE-2024-49868</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cachefiles: fix dentry leak in cachefiles_open_file()

A dentry leak may be caused when a lookup cookie and a cull are concurrent:

            P1             |             P2
-----------------------------------------------------------
cachefiles_lookup_cookie
  cachefiles_look_up_object
    lookup_one_positive_unlocked
     // get dentry
                            cachefiles_cull
                              inode-&gt;i_flags |= S_KERNEL_FILE;
    cachefiles_open_file
      cachefiles_mark_inode_in_use
        __cachefiles_mark_inode_in_use
          can_use = false
          if (!(inode-&gt;i_flags &amp; S_KERNEL_FILE))
            can_use = true
	  return false
        return false
        // Returns an error but doesn't put dentry

After that the following WARNING will be triggered when the backend folder
is umounted:

==================================================================
BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img}  still in use (1) [unmount of ext4 sda]
WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70
CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25
RIP: 0010:umount_check+0x5d/0x70
Call Trace:
 &lt;TASK&gt;
 d_walk+0xda/0x2b0
 do_one_tree+0x20/0x40
 shrink_dcache_for_umount+0x2c/0x90
 generic_shutdown_super+0x20/0x160
 kill_block_super+0x1a/0x40
 ext4_kill_sb+0x22/0x40
 deactivate_locked_super+0x35/0x80
 cleanup_mnt+0x104/0x160
==================================================================

Whether cachefiles_open_file() returns true or false, the reference count
obtained by lookup_positive_unlocked() in cachefiles_look_up_object()
should be released.

Therefore release that reference count in cachefiles_look_up_object() to
fix the above issue and simplify the code.</Note>
    </Notes>
    <CVE>CVE-2024-49870</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Input: adp5589-keys - fix NULL pointer dereference

We register a devm action to call adp5589_clear_config() and then pass
the i2c client as argument so that we can call i2c_get_clientdata() in
order to get our device object. However, i2c_set_clientdata() is only
being set at the end of the probe function which means that we'll get a
NULL pointer dereference in case the probe function fails early.</Note>
    </Notes>
    <CVE>CVE-2024-49871</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition

In the svc_i3c_master_probe function, &amp;master-&gt;hj_work is bound with
svc_i3c_master_hj_work, &amp;master-&gt;ibi_work is bound with
svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work  can start the
hj_work, svc_i3c_master_irq_handler can start the ibi_work.

If we remove the module which will call svc_i3c_master_remove to
make cleanup, it will free master-&gt;base through i3c_master_unregister
while the work mentioned above will be used. The sequence of operations
that may lead to a UAF bug is as follows:

CPU0                                         CPU1

                                    | svc_i3c_master_hj_work
svc_i3c_master_remove               |
i3c_master_unregister(&amp;master-&gt;base)|
device_unregister(&amp;master-&gt;dev)     |
device_release                      |
//free master-&gt;base                 |
                                    | i3c_master_do_daa(&amp;master-&gt;base)
                                    | //use master-&gt;base

Fix it by ensuring that the work is canceled before proceeding with the
cleanup in svc_i3c_master_remove.</Note>
    </Notes>
    <CVE>CVE-2024-49874</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfsd: map the EBADMSG to nfserr_io to avoid warning

Ext4 will throw -EBADMSG through ext4_readdir when a checksum error
occurs, resulting in the following WARNING.

Fix it by mapping EBADMSG to nfserr_io.

nfsd_buffered_readdir
 iterate_dir // -EBADMSG -74
  ext4_readdir // .iterate_shared
   ext4_dx_readdir
    ext4_htree_fill_tree
     htree_dirblock_to_tree
      ext4_read_dirblock
       __ext4_read_dirblock
        ext4_dirblock_csum_verify
         warn_no_space_for_csum
          __warn_no_space_for_csum
        return ERR_PTR(-EFSBADCRC) // -EBADMSG -74
 nfserrno // WARNING

[  161.115610] ------------[ cut here ]------------
[  161.116465] nfsd: non-standard errno: -74
[  161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0
[  161.118596] Modules linked in:
[  161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138
[  161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe
mu.org 04/01/2014
[  161.123601] RIP: 0010:nfserrno+0x9d/0xd0
[  161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6
 05 ce 2b 61 03 01 e8 99 20 d8 00 &lt;0f&gt; 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33
[  161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286
[  161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[  161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a
[  161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827
[  161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021
[  161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8
[  161.135244] FS:  0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000
[  161.136695] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0
[  161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  161.141519] PKRU: 55555554
[  161.142076] Call Trace:
[  161.142575]  ? __warn+0x9b/0x140
[  161.143229]  ? nfserrno+0x9d/0xd0
[  161.143872]  ? report_bug+0x125/0x150
[  161.144595]  ? handle_bug+0x41/0x90
[  161.145284]  ? exc_invalid_op+0x14/0x70
[  161.146009]  ? asm_exc_invalid_op+0x12/0x20
[  161.146816]  ? nfserrno+0x9d/0xd0
[  161.147487]  nfsd_buffered_readdir+0x28b/0x2b0
[  161.148333]  ? nfsd4_encode_dirent_fattr+0x380/0x380
[  161.149258]  ? nfsd_buffered_filldir+0xf0/0xf0
[  161.150093]  ? wait_for_concurrent_writes+0x170/0x170
[  161.151004]  ? generic_file_llseek_size+0x48/0x160
[  161.151895]  nfsd_readdir+0x132/0x190
[  161.152606]  ? nfsd4_encode_dirent_fattr+0x380/0x380
[  161.153516]  ? nfsd_unlink+0x380/0x380
[  161.154256]  ? override_creds+0x45/0x60
[  161.155006]  nfsd4_encode_readdir+0x21a/0x3d0
[  161.155850]  ? nfsd4_encode_readlink+0x210/0x210
[  161.156731]  ? write_bytes_to_xdr_buf+0x97/0xe0
[  161.157598]  ? __write_bytes_to_xdr_buf+0xd0/0xd0
[  161.158494]  ? lock_downgrade+0x90/0x90
[  161.159232]  ? nfs4svc_decode_voidarg+0x10/0x10
[  161.160092]  nfsd4_encode_operation+0x15a/0x440
[  161.160959]  nfsd4_proc_compound+0x718/0xe90
[  161.161818]  nfsd_dispatch+0x18e/0x2c0
[  161.162586]  svc_process_common+0x786/0xc50
[  161.163403]  ? nfsd_svc+0x380/0x380
[  161.164137]  ? svc_printk+0x160/0x160
[  161.164846]  ? svc_xprt_do_enqueue.part.0+0x365/0x380
[  161.165808]  ? nfsd_svc+0x380/0x380
[  161.166523]  ? rcu_is_watching+0x23/0x40
[  161.167309]  svc_process+0x1a5/0x200
[  161.168019]  nfsd+0x1f5/0x380
[  161.168663]  ? nfsd_shutdown_threads+0x260/0x260
[  161.169554]  kthread+0x1c4/0x210
[  161.170224]  ? kthread_insert_work_sanity_check+0x80/0x80
[  161.171246]  ret_from_fork+0x1f/0x30</Note>
    </Notes>
    <CVE>CVE-2024-49875</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate

When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger
NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if
bh is NULL.</Note>
    </Notes>
    <CVE>CVE-2024-49877</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

resource: fix region_intersects() vs add_memory_driver_managed()

On a system with CXL memory, the resource tree (/proc/iomem) related to
CXL memory may look like something as follows.

490000000-50fffffff : CXL Window 0
  490000000-50fffffff : region0
    490000000-50fffffff : dax0.0
      490000000-50fffffff : System RAM (kmem)

Because drivers/dax/kmem.c calls add_memory_driver_managed() during
onlining CXL memory, which makes "System RAM (kmem)" a descendant of "CXL
Window X".  This confuses region_intersects(), which expects all "System
RAM" resources to be at the top level of iomem_resource.  This can lead to
bugs.

For example, when the following command line is executed to write some
memory in CXL memory range via /dev/mem,

 $ dd if=data of=/dev/mem bs=$((1 &lt;&lt; 10)) seek=$((0x490000000 &gt;&gt; 10)) count=1
 dd: error writing '/dev/mem': Bad address
 1+0 records in
 0+0 records out
 0 bytes copied, 0.0283507 s, 0.0 kB/s

the command fails as expected.  However, the error code is wrong.  It
should be "Operation not permitted" instead of "Bad address".  More
seriously, the /dev/mem permission checking in devmem_is_allowed() passes
incorrectly.  Although the accessing is prevented later because ioremap()
isn't allowed to map system RAM, it is a potential security issue.  During
command executing, the following warning is reported in the kernel log for
calling ioremap() on system RAM.

 ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff
 WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d
 Call Trace:
  memremap+0xcb/0x184
  xlate_dev_mem_ptr+0x25/0x2f
  write_mem+0x94/0xfb
  vfs_write+0x128/0x26d
  ksys_write+0xac/0xfe
  do_syscall_64+0x9a/0xfd
  entry_SYSCALL_64_after_hwframe+0x4b/0x53

The details of command execution process are as follows.  In the above
resource tree, "System RAM" is a descendant of "CXL Window 0" instead of a
top level resource.  So, region_intersects() will report no System RAM
resources in the CXL memory region incorrectly, because it only checks the
top level resources.  Consequently, devmem_is_allowed() will return 1
(allow access via /dev/mem) for CXL memory region incorrectly. 
Fortunately, ioremap() doesn't allow to map System RAM and reject the
access.

So, region_intersects() needs to be fixed to work correctly with the
resource tree with "System RAM" not at top level as above.  To fix it, if
we found a unmatched resource in the top level, we will continue to search
matched resources in its descendant resources.  So, we will not miss any
matched resources in resource tree anymore.

In the new implementation, an example resource tree

|------------- "CXL Window 0" ------------|
|-- "System RAM" --|

will behave similar as the following fake resource tree for
region_intersects(, IORESOURCE_SYSTEM_RAM, ),

|-- "System RAM" --||-- "CXL Window 0a" --|

Where "CXL Window 0a" is part of the original "CXL Window 0" that
isn't covered by "System RAM".</Note>
    </Notes>
    <CVE>CVE-2024-49878</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm: omapdrm: Add missing check for alloc_ordered_workqueue

As it may return NULL pointer and cause NULL pointer dereference. Add check
for the return value of alloc_ordered_workqueue.</Note>
    </Notes>
    <CVE>CVE-2024-49879</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: update orig_path in ext4_find_extent()

In ext4_find_extent(), if the path is not big enough, we free it and set
*orig_path to NULL. But after reallocating and successfully initializing
the path, we don't update *orig_path, in which case the caller gets a
valid path but a NULL ppath, and this may cause a NULL pointer dereference
or a path memory leak. For example:

ext4_split_extent
  path = *ppath = 2000
  ext4_find_extent
    if (depth &gt; path[0].p_maxdepth)
      kfree(path = 2000);
      *orig_path = path = NULL;
      path = kcalloc() = 3000
  ext4_split_extent_at(*ppath = NULL)
    path = *ppath;
    ex = path[depth].p_ext;
    // NULL pointer dereference!

==================================================================
BUG: kernel NULL pointer dereference, address: 0000000000000010
CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847
RIP: 0010:ext4_split_extent_at+0x6d/0x560
Call Trace:
 &lt;TASK&gt;
 ext4_split_extent.isra.0+0xcb/0x1b0
 ext4_ext_convert_to_initialized+0x168/0x6c0
 ext4_ext_handle_unwritten_extents+0x325/0x4d0
 ext4_ext_map_blocks+0x520/0xdb0
 ext4_map_blocks+0x2b0/0x690
 ext4_iomap_begin+0x20e/0x2c0
[...]
==================================================================

Therefore, *orig_path is updated when the extent lookup succeeds, so that
the caller can safely use path or *ppath.</Note>
    </Notes>
    <CVE>CVE-2024-49881</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: fix double brelse() the buffer of the extents path

In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been
released, otherwise it may be released twice. An example of what triggers
this is as follows:

  split2    map    split1
|--------|-------|--------|

ext4_ext_map_blocks
 ext4_ext_handle_unwritten_extents
  ext4_split_convert_extents
   // path-&gt;p_depth == 0
   ext4_split_extent
     // 1. do split1
     ext4_split_extent_at
       |ext4_ext_insert_extent
       |  ext4_ext_create_new_leaf
       |    ext4_ext_grow_indepth
       |      le16_add_cpu(&amp;neh-&gt;eh_depth, 1)
       |    ext4_find_extent
       |      // return -ENOMEM
       |// get error and try zeroout
       |path = ext4_find_extent
       |  path-&gt;p_depth = 1
       |ext4_ext_try_to_merge
       |  ext4_ext_try_to_merge_up
       |    path-&gt;p_depth = 0
       |    brelse(path[1].p_bh)  ---&gt; not set to NULL here
       |// zeroout success
     // 2. update path
     ext4_find_extent
     // 3. do split2
     ext4_split_extent_at
       ext4_ext_insert_extent
         ext4_ext_create_new_leaf
           ext4_ext_grow_indepth
             le16_add_cpu(&amp;neh-&gt;eh_depth, 1)
           ext4_find_extent
             path[0].p_bh = NULL;
             path-&gt;p_depth = 1
             read_extent_tree_block  ---&gt; return err
             // path[1].p_bh is still the old value
             ext4_free_ext_path
               ext4_ext_drop_refs
                 // path-&gt;p_depth == 1
                 brelse(path[1].p_bh)  ---&gt; brelse a buffer twice

Finally got the following WARRNING when removing the buffer from lru:

============================================
VFS: brelse: Trying to free free buffer
WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90
CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716
RIP: 0010:__brelse+0x58/0x90
Call Trace:
 &lt;TASK&gt;
 __find_get_block+0x6e7/0x810
 bdev_getblk+0x2b/0x480
 __ext4_get_inode_loc+0x48a/0x1240
 ext4_get_inode_loc+0xb2/0x150
 ext4_reserve_inode_write+0xb7/0x230
 __ext4_mark_inode_dirty+0x144/0x6a0
 ext4_ext_insert_extent+0x9c8/0x3230
 ext4_ext_map_blocks+0xf45/0x2dc0
 ext4_map_blocks+0x724/0x1700
 ext4_do_writepages+0x12d6/0x2a70
[...]
============================================</Note>
    </Notes>
    <CVE>CVE-2024-49882</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: aovid use-after-free in ext4_ext_insert_extent()

As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is
reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and
cause UAF. Below is a sample trace with dummy values:

ext4_ext_insert_extent
  path = *ppath = 2000
  ext4_ext_create_new_leaf(ppath)
    ext4_find_extent(ppath)
      path = *ppath = 2000
      if (depth &gt; path[0].p_maxdepth)
            kfree(path = 2000);
            *ppath = path = NULL;
      path = kcalloc() = 3000
      *ppath = 3000;
      return path;
  /* here path is still 2000, UAF! */
  eh = path[depth].p_hdr

==================================================================
BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330
Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179
CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866
Call Trace:
 &lt;TASK&gt;
 ext4_ext_insert_extent+0x26d4/0x3330
 ext4_ext_map_blocks+0xe22/0x2d40
 ext4_map_blocks+0x71e/0x1700
 ext4_do_writepages+0x1290/0x2800
[...]

Allocated by task 179:
 ext4_find_extent+0x81c/0x1f70
 ext4_ext_map_blocks+0x146/0x2d40
 ext4_map_blocks+0x71e/0x1700
 ext4_do_writepages+0x1290/0x2800
 ext4_writepages+0x26d/0x4e0
 do_writepages+0x175/0x700
[...]

Freed by task 179:
 kfree+0xcb/0x240
 ext4_find_extent+0x7c0/0x1f70
 ext4_ext_insert_extent+0xa26/0x3330
 ext4_ext_map_blocks+0xe22/0x2d40
 ext4_map_blocks+0x71e/0x1700
 ext4_do_writepages+0x1290/0x2800
 ext4_writepages+0x26d/0x4e0
 do_writepages+0x175/0x700
[...]
==================================================================

So use *ppath to update the path to avoid the above problem.</Note>
    </Notes>
    <CVE>CVE-2024-49883</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: fix slab-use-after-free in ext4_split_extent_at()

We hit the following use-after-free:

==================================================================
BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0
Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40
CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724
Call Trace:
 &lt;TASK&gt;
 kasan_report+0x93/0xc0
 ext4_split_extent_at+0xba8/0xcc0
 ext4_split_extent.isra.0+0x18f/0x500
 ext4_split_convert_extents+0x275/0x750
 ext4_ext_handle_unwritten_extents+0x73e/0x1580
 ext4_ext_map_blocks+0xe20/0x2dc0
 ext4_map_blocks+0x724/0x1700
 ext4_do_writepages+0x12d6/0x2a70
[...]

Allocated by task 40:
 __kmalloc_noprof+0x1ac/0x480
 ext4_find_extent+0xf3b/0x1e70
 ext4_ext_map_blocks+0x188/0x2dc0
 ext4_map_blocks+0x724/0x1700
 ext4_do_writepages+0x12d6/0x2a70
[...]

Freed by task 40:
 kfree+0xf1/0x2b0
 ext4_find_extent+0xa71/0x1e70
 ext4_ext_insert_extent+0xa22/0x3260
 ext4_split_extent_at+0x3ef/0xcc0
 ext4_split_extent.isra.0+0x18f/0x500
 ext4_split_convert_extents+0x275/0x750
 ext4_ext_handle_unwritten_extents+0x73e/0x1580
 ext4_ext_map_blocks+0xe20/0x2dc0
 ext4_map_blocks+0x724/0x1700
 ext4_do_writepages+0x12d6/0x2a70
[...]
==================================================================

The flow of issue triggering is as follows:

ext4_split_extent_at
  path = *ppath
  ext4_ext_insert_extent(ppath)
    ext4_ext_create_new_leaf(ppath)
      ext4_find_extent(orig_path)
        path = *orig_path
        read_extent_tree_block
          // return -ENOMEM or -EIO
        ext4_free_ext_path(path)
          kfree(path)
        *orig_path = NULL
  a. If err is -ENOMEM:
  ext4_ext_dirty(path + path-&gt;p_depth)
  // path use-after-free !!!
  b. If err is -EIO and we have EXT_DEBUG defined:
  ext4_ext_show_leaf(path)
    eh = path[depth].p_hdr
    // path also use-after-free !!!

So when trying to zeroout or fix the extent length, call ext4_find_extent()
to update the path.

In addition we use *ppath directly as an ext4_ext_show_leaf() input to
avoid possible use-after-free when EXT_DEBUG is defined, and to avoid
unnecessary path updates.</Note>
    </Notes>
    <CVE>CVE-2024-49884</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug

Attaching SST PCI device to VM causes "BUG: KASAN: slab-out-of-bounds".
kasan report:
[   19.411889] ==================================================================
[   19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common]
[   19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113
[   19.417368]
[   19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G            E      6.9.0 #10
[   19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022
[   19.422687] Call Trace:
[   19.424091]  &lt;TASK&gt;
[   19.425448]  dump_stack_lvl+0x5d/0x80
[   19.426963]  ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common]
[   19.428694]  print_report+0x19d/0x52e
[   19.430206]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[   19.431837]  ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common]
[   19.433539]  kasan_report+0xf0/0x170
[   19.435019]  ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common]
[   19.436709]  _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common]
[   19.438379]  ? __pfx_sched_clock_cpu+0x10/0x10
[   19.439910]  isst_if_cpu_online+0x406/0x58f [isst_if_common]
[   19.441573]  ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common]
[   19.443263]  ? ttwu_queue_wakelist+0x2c1/0x360
[   19.444797]  cpuhp_invoke_callback+0x221/0xec0
[   19.446337]  cpuhp_thread_fun+0x21b/0x610
[   19.447814]  ? __pfx_cpuhp_thread_fun+0x10/0x10
[   19.449354]  smpboot_thread_fn+0x2e7/0x6e0
[   19.450859]  ? __pfx_smpboot_thread_fn+0x10/0x10
[   19.452405]  kthread+0x29c/0x350
[   19.453817]  ? __pfx_kthread+0x10/0x10
[   19.455253]  ret_from_fork+0x31/0x70
[   19.456685]  ? __pfx_kthread+0x10/0x10
[   19.458114]  ret_from_fork_asm+0x1a/0x30
[   19.459573]  &lt;/TASK&gt;
[   19.460853]
[   19.462055] Allocated by task 1198:
[   19.463410]  kasan_save_stack+0x30/0x50
[   19.464788]  kasan_save_track+0x14/0x30
[   19.466139]  __kasan_kmalloc+0xaa/0xb0
[   19.467465]  __kmalloc+0x1cd/0x470
[   19.468748]  isst_if_cdev_register+0x1da/0x350 [isst_if_common]
[   19.470233]  isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr]
[   19.471670]  do_one_initcall+0xa4/0x380
[   19.472903]  do_init_module+0x238/0x760
[   19.474105]  load_module+0x5239/0x6f00
[   19.475285]  init_module_from_file+0xd1/0x130
[   19.476506]  idempotent_init_module+0x23b/0x650
[   19.477725]  __x64_sys_finit_module+0xbe/0x130
[   19.476506]  idempotent_init_module+0x23b/0x650
[   19.477725]  __x64_sys_finit_module+0xbe/0x130
[   19.478920]  do_syscall_64+0x82/0x160
[   19.480036]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[   19.481292]
[   19.482205] The buggy address belongs to the object at ffff888829e65000
 which belongs to the cache kmalloc-512 of size 512
[   19.484818] The buggy address is located 0 bytes to the right of
 allocated 512-byte region [ffff888829e65000, ffff888829e65200)
[   19.487447]
[   19.488328] The buggy address belongs to the physical page:
[   19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60
[   19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
[   19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff)
[   19.493914] page_type: 0xffffffff()
[   19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001
[   19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000
[   19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001
[   19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000
[   19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff
[   19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000
[   19.503784] page dumped because: k
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-49886</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix a sdiv overflow issue

Zac Ecob reported a problem where a bpf program may cause kernel crash due
to the following error:
  Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI

The failure is due to the below signed divide:
  LLONG_MIN/-1 where LLONG_MIN equals to -9,223,372,036,854,775,808.
LLONG_MIN/-1 is supposed to give a positive number 9,223,372,036,854,775,808,
but it is impossible since for 64-bit system, the maximum positive
number is 9,223,372,036,854,775,807. On x86_64, LLONG_MIN/-1 will
cause a kernel exception. On arm64, the result for LLONG_MIN/-1 is
LLONG_MIN.

Further investigation found all the following sdiv/smod cases may trigger
an exception when bpf program is running on x86_64 platform:
  - LLONG_MIN/-1 for 64bit operation
  - INT_MIN/-1 for 32bit operation
  - LLONG_MIN%-1 for 64bit operation
  - INT_MIN%-1 for 32bit operation
where -1 can be an immediate or in a register.

On arm64, there are no exceptions:
  - LLONG_MIN/-1 = LLONG_MIN
  - INT_MIN/-1 = INT_MIN
  - LLONG_MIN%-1 = 0
  - INT_MIN%-1 = 0
where -1 can be an immediate or in a register.

Insn patching is needed to handle the above cases and the patched codes
produced results aligned with above arm64 result. The below are pseudo
codes to handle sdiv/smod exceptions including both divisor -1 and divisor 0
and the divisor is stored in a register.

sdiv:
      tmp = rX
      tmp += 1 /* [-1, 0] -&gt; [0, 1]
      if tmp &gt;(unsigned) 1 goto L2
      if tmp == 0 goto L1
      rY = 0
  L1:
      rY = -rY;
      goto L3
  L2:
      rY /= rX
  L3:

smod:
      tmp = rX
      tmp += 1 /* [-1, 0] -&gt; [0, 1]
      if tmp &gt;(unsigned) 1 goto L1
      if tmp == 1 (is64 ? goto L2 : goto L3)
      rY = 0;
      goto L2
  L1:
      rY %= rX
  L2:
      goto L4  // only when !is64
  L3:
      wY = wY  // only when !is64
  L4:

  [1] https://lore.kernel.org/bpf/tPJLTEh7S_DxFEqAI2Ji5MBSoZVg7_G-Py2iaZpAaWtM961fFTWtsnlzwvTbzBzaUzwQAoNATXKUlt0LZOFgnDcIyKCswAnAGdUF3LBrhGQ=@protonmail.com/</Note>
    </Notes>
    <CVE>CVE-2024-49888</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/pm: ensure the fw_info is not null before using it

This resolves the dereference null return value warning
reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-49890</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths

When the HBA is undergoing a reset or is handling an errata event, NULL ptr
dereference crashes may occur in routines such as
lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or
lpfc_abort_handler().

Add NULL ptr checks before dereferencing hdwq pointers that may have been
freed due to operations colliding with a reset or errata event handler.</Note>
    </Notes>
    <CVE>CVE-2024-49891</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Initialize get_bytes_per_element's default to 1

Variables, used as denominators and maybe not assigned to other values,
should not be 0. bytes_per_element_y &amp; bytes_per_element_c are
initialized by get_bytes_per_element() which should never return 0.

This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-49892</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix index out of bounds in degamma hardware format translation

Fixes index out of bounds issue in
`cm_helper_translate_curve_to_degamma_hw_format` function. 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.

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf-&gt;tf_pts.red' 1025 &lt;= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf-&gt;tf_pts.green' 1025 &lt;= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf-&gt;tf_pts.blue' 1025 &lt;= s32max</Note>
    </Notes>
    <CVE>CVE-2024-49894</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation

This commit addresses a potential index out of bounds issue in the
`cm3_helper_translate_curve_to_degamma_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.

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf-&gt;tf_pts.red' 1025 &lt;= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf-&gt;tf_pts.green' 1025 &lt;= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf-&gt;tf_pts.blue' 1025 &lt;= s32max</Note>
    </Notes>
    <CVE>CVE-2024-49895</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check stream before comparing them

[WHAT &amp; HOW]
amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is
necessary to check for null before dereferencing them.

This fixes 1 FORWARD_NULL issue reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-49896</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check phantom_stream before it is used

dcn32_enable_phantom_stream can return null, so returned value
must be checked before used.

This fixes 1 NULL_RETURNS issue reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-49897</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check null-initialized variables

[WHAT &amp; HOW]
drr_timing and subvp_pipe are initialized to null and they are not
always assigned new values. It is necessary to check for null before
dereferencing.

This fixes 2 FORWARD_NULL issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-49898</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Initialize denominators' default to 1

[WHAT &amp; HOW]
Variables used as denominators and maybe not assigned to other values,
should not be 0. Change their default to 1 so they are never 0.

This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-49899</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

jfs: Fix uninit-value access of new_ea in ea_buffer

syzbot reports that lzo1x_1_do_compress is using uninit-value:

=====================================================
BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178

...

Uninit was stored to memory at:
 ea_put fs/jfs/xattr.c:639 [inline]

...

Local variable ea_buf created at:
 __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662
 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934

=====================================================

The reason is ea_buf-&gt;new_ea is not initialized properly.

Fix this by using memset to empty its content at the beginning
in ea_get().</Note>
    </Notes>
    <CVE>CVE-2024-49900</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/msm/adreno: Assign msm_gpu-&gt;pdev earlier to avoid nullptrs

There are some cases, such as the one uncovered by Commit 46d4efcccc68
("drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails")
where

msm_gpu_cleanup() : platform_set_drvdata(gpu-&gt;pdev, NULL);

is called on gpu-&gt;pdev == NULL, as the GPU device has not been fully
initialized yet.

Turns out that there's more than just the aforementioned path that
causes this to happen (e.g. the case when there's speedbin data in the
catalog, but opp-supported-hw is missing in DT).

Assigning msm_gpu-&gt;pdev earlier seems like the least painful solution
to this, therefore do so.

Patchwork: https://patchwork.freedesktop.org/patch/602742/</Note>
    </Notes>
    <CVE>CVE-2024-49901</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

jfs: check if leafidx greater than num leaves per dmap tree

syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater
than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf.

Shaggy:
Modified sanity check to apply to control pages as well as leaf pages.</Note>
    </Notes>
    <CVE>CVE-2024-49902</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

jfs: Fix uaf in dbFreeBits

[syzbot reported]
==================================================================
BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline]
BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752
Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216

CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:93 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
 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
 __mutex_lock_common kernel/locking/mutex.c:587 [inline]
 __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752
 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390
 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline]
 dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409
 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650
 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100
 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:907 [inline]
 __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83

Freed by task 5218:
 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+0xe0/0x150 mm/kasan/common.c:240
 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256
 kasan_slab_free include/linux/kasan.h:184 [inline]
 slab_free_hook mm/slub.c:2252 [inline]
 slab_free mm/slub.c:4473 [inline]
 kfree+0x149/0x360 mm/slub.c:4594
 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278
 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247
 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454
 reconfigure_super+0x445/0x880 fs/super.c:1083
 vfs_cmd_reconfigure fs/fsopen.c:263 [inline]
 vfs_fsconfig_locked fs/fsopen.c:292 [inline]
 __do_sys_fsconfig fs/fsopen.c:473 [inline]
 __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345
 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

[Analysis]
There are two paths (dbUnmount and jfs_ioc_trim) that generate race
condition when accessing bmap, which leads to the occurrence of uaf.

Use the lock s_umount to synchronize them, in order to avoid uaf caused
by race condition.</Note>
    </Notes>
    <CVE>CVE-2024-49903</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check null pointer before try to access it

[why &amp; how]
Change the order of the pipe_ctx-&gt;plane_state check to ensure that
plane_state is not null before accessing it.</Note>
    </Notes>
    <CVE>CVE-2024-49906</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check null pointers before using dc-&gt;clk_mgr

[WHY &amp; HOW]
dc-&gt;clk_mgr is null checked previously in the same function, indicating
it might be null.

Passing "dc" to "dc-&gt;hwss.apply_idle_power_optimizations", which
dereferences null "dc-&gt;clk_mgr". (The function pointer resolves to
"dcn35_apply_idle_power_optimizations".)

This fixes 1 FORWARD_NULL issue reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-49907</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2)

This commit adds a null check for the 'afb' variable in the
amdgpu_dm_update_cursor function. Previously, 'afb' was assumed to be
null at line 8388, but was used later in the code without a null check.
This could potentially lead to a null pointer dereference.

Changes since v1:
- Moved the null check for 'afb' to the line where 'afb' is used. (Alex)

Fixes the below:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8433 amdgpu_dm_update_cursor()
	error: we previously assumed 'afb' could be null (see line 8388)</Note>
    </Notes>
    <CVE>CVE-2024-49908</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func

This commit adds a null check for the set_output_gamma function pointer
in the dcn32_set_output_transfer_func function. Previously,
set_output_gamma was being checked for null, but then it was being
dereferenced without any null check. This could lead to a null pointer
dereference if set_output_gamma is null.

To fix this, we now ensure that set_output_gamma is not null before
dereferencing it. We do this by adding a null check for set_output_gamma
before the call to set_output_gamma.</Note>
    </Notes>
    <CVE>CVE-2024-49909</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func

This commit adds a null check for the set_output_gamma function pointer
in the dcn20_set_output_transfer_func function. Previously,
set_output_gamma was being checked for null at line 1030, but then it
was being dereferenced without any null check at line 1048. This could
potentially lead to a null pointer dereference error if set_output_gamma
is null.

To fix this, we now ensure that set_output_gamma is not null before
dereferencing it. We do this by adding a null check for set_output_gamma
before the call to set_output_gamma at line 1048.</Note>
    </Notes>
    <CVE>CVE-2024-49911</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Handle null 'stream_status' in 'planes_changed_for_existing_stream'

This commit adds a null check for 'stream_status' in the function
'planes_changed_for_existing_stream'. Previously, the code assumed
'stream_status' could be null, but did not handle the case where it was
actually null. This could lead to a null pointer dereference.

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:3784 planes_changed_for_existing_stream() error: we previously assumed 'stream_status' could be null (see line 3774)</Note>
    </Notes>
    <CVE>CVE-2024-49912</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream

This commit addresses a null pointer dereference issue in the
`commit_planes_for_stream` function at line 4140. The issue could occur
when `top_pipe_to_program` is null.

The fix adds a check to ensure `top_pipe_to_program` is not null before
accessing its stream_res. This prevents a null pointer dereference.

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906)</Note>
    </Notes>
    <CVE>CVE-2024-49913</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add null check for pipe_ctx-&gt;plane_state in dcn20_program_pipe

This commit addresses a null pointer dereference issue in the
`dcn20_program_pipe` function. The issue could occur when
`pipe_ctx-&gt;plane_state` is null.

The fix adds a check to ensure `pipe_ctx-&gt;plane_state` is not null
before accessing. This prevents a null pointer dereference.

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx-&gt;plane_state' could be null (see line 1877)</Note>
    </Notes>
    <CVE>CVE-2024-49914</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw

This commit addresses a potential null pointer dereference issue in the
`dcn32_init_hw` function. The issue could occur when `dc-&gt;clk_mgr` is
null.

The fix adds a check to ensure `dc-&gt;clk_mgr` is not null before
accessing its functions. This prevents a potential null pointer
dereference.

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed 'dc-&gt;clk_mgr' could be null (see line 782)</Note>
    </Notes>
    <CVE>CVE-2024-49915</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add NULL check for clk_mgr and clk_mgr-&gt;funcs in dcn30_init_hw

This commit addresses a potential null pointer dereference issue in the
`dcn30_init_hw` function. The issue could occur when `dc-&gt;clk_mgr` or
`dc-&gt;clk_mgr-&gt;funcs` is null.

The fix adds a check to ensure `dc-&gt;clk_mgr` and `dc-&gt;clk_mgr-&gt;funcs` is
not null before accessing its functions. This prevents a potential null
pointer dereference.

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc-&gt;clk_mgr' could be null (see line 628)</Note>
    </Notes>
    <CVE>CVE-2024-49917</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add null check for head_pipe in dcn32_acquire_idle_pipe_for_head_pipe_in_layer

This commit addresses a potential null pointer dereference issue in the
`dcn32_acquire_idle_pipe_for_head_pipe_in_layer` function. The issue
could occur when `head_pipe` is null.

The fix adds a check to ensure `head_pipe` is not null before asserting
it. If `head_pipe` is null, the function returns NULL to prevent a
potential null pointer dereference.

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2690 dcn32_acquire_idle_pipe_for_head_pipe_in_layer() error: we previously assumed 'head_pipe' could be null (see line 2681)</Note>
    </Notes>
    <CVE>CVE-2024-49918</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer

This commit addresses a potential null pointer dereference issue in the
`dcn201_acquire_free_pipe_for_layer` function. The issue could occur
when `head_pipe` is null.

The fix adds a check to ensure `head_pipe` is not null before asserting
it. If `head_pipe` is null, the function returns NULL to prevent a
potential null pointer dereference.

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 dcn201_acquire_free_pipe_for_layer() error: we previously assumed 'head_pipe' could be null (see line 1010)</Note>
    </Notes>
    <CVE>CVE-2024-49919</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check null pointers before multiple uses

[WHAT &amp; HOW]
Poniters, such as stream_enc and dc-&gt;bw_vbios, are null checked previously
in the same function, so Coverity warns "implies that stream_enc and
dc-&gt;bw_vbios might be null". They are used multiple times in the
subsequent code and need to be checked.

This fixes 10 FORWARD_NULL issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-49920</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check null pointers before used

[WHAT &amp; HOW]
Poniters, such as dc-&gt;clk_mgr, are null checked previously in the same
function, so Coverity warns "implies that "dc-&gt;clk_mgr" might be null".
As a result, these pointers need to be checked when used again.

This fixes 10 FORWARD_NULL issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-49921</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check null pointers before using them

[WHAT &amp; HOW]
These pointers are null checked previously in the same function,
indicating they might be null as reported by Coverity. As a result,
they need to be checked when used again.

This fixes 3 FORWARD_NULL issue reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-49922</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags

[WHAT &amp; HOW]
"dcn20_validate_apply_pipe_split_flags" dereferences merge, and thus it
cannot be a null pointer. Let's pass a valid pointer to avoid null
dereference.

This fixes 2 FORWARD_NULL issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-49923</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-49925</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: rtw89: avoid reading out of bounds when loading TX power FW elements

Because the loop-expression will do one more time before getting false from
cond-expression, the original code copied one more entry size beyond valid
region.

Fix it by moving the entry copy to loop-body.</Note>
    </Notes>
    <CVE>CVE-2024-49928</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: avoid NULL pointer dereference

iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta
pointer is not NULL.
It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is
dereferencing the ieee80211_sta pointer.
If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL
pointer.
Fix this by checking the sta pointer before retrieving the mvmsta
from it. If sta is not NULL, then mvmsta isn't either.</Note>
    </Notes>
    <CVE>CVE-2024-49929</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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</Note>
    </Notes>
    <CVE>CVE-2024-49930</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: fix array out-of-bound access in SoC stats

Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a
maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process()
function access ath12k_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 ath12k_dp_rx_process() to use the normal ring ID
directly instead of the SRNG ring ID to avoid out-of-bounds array access.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1</Note>
    </Notes>
    <CVE>CVE-2024-49931</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

blk_iocost: fix more out of bound shifts

Recently running UBSAN caught few out of bound shifts in the
ioc_forgive_debts() function:

UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38
shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long
long')
...
UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30
shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long
long')
...
Call Trace:
&lt;IRQ&gt;
dump_stack_lvl+0xca/0x130
__ubsan_handle_shift_out_of_bounds+0x22c/0x280
? __lock_acquire+0x6441/0x7c10
ioc_timer_fn+0x6cec/0x7750
? blk_iocost_init+0x720/0x720
? call_timer_fn+0x5d/0x470
call_timer_fn+0xfa/0x470
? blk_iocost_init+0x720/0x720
__run_timer_base+0x519/0x700
...

Actual impact of this issue was not identified but I propose to fix the
undefined behaviour.
The proposed fix to prevent those out of bound shifts consist of
precalculating exponent before using it the shift operations by taking
min value from the actual exponent and maximum possible number of bits.</Note>
    </Notes>
    <CVE>CVE-2024-49933</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name

It's observed that a crash occurs during hot-remove a memory device,
in which user is accessing the hugetlb. See calltrace as following:

------------[ cut here ]------------
WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790
Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s
mirror dm_region_hash dm_log dm_mod
CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
RIP: 0010:do_user_addr_fault+0x2a0/0x790
Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff &lt;0f&gt; 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41
RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046
RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658
R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000
FS:  00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 ? __warn+0x8d/0x190
 ? do_user_addr_fault+0x2a0/0x790
 ? report_bug+0x1c3/0x1d0
 ? handle_bug+0x3c/0x70
 ? exc_invalid_op+0x14/0x70
 ? asm_exc_invalid_op+0x16/0x20
 ? do_user_addr_fault+0x2a0/0x790
 ? exc_page_fault+0x31/0x200
 exc_page_fault+0x68/0x200
&lt;...snip...&gt;
BUG: unable to handle page fault for address: 0000000000001000
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0
 Oops: Oops: 0000 [#1] PREEMPT SMP PTI
 ---[ end trace 0000000000000000 ]---
 BUG: unable to handle page fault for address: 0000000000001000
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0
 Oops: Oops: 0000 [#1] PREEMPT SMP PTI
 CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G        W          6.10.0-rc2-lizhijian+ #492
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
 RIP: 0010:dentry_name+0x1f4/0x440
&lt;...snip...&gt;
? dentry_name+0x2fa/0x440
vsnprintf+0x1f3/0x4f0
vprintk_store+0x23a/0x540
vprintk_emit+0x6d/0x330
_printk+0x58/0x80
dump_mapping+0x10b/0x1a0
? __pfx_free_object_rcu+0x10/0x10
__dump_page+0x26b/0x3e0
? vprintk_emit+0xe0/0x330
? _printk+0x58/0x80
? dump_page+0x17/0x50
dump_page+0x17/0x50
do_migrate_range+0x2f7/0x7f0
? do_migrate_range+0x42/0x7f0
? offline_pages+0x2f4/0x8c0
offline_pages+0x60a/0x8c0
memory_subsys_offline+0x9f/0x1c0
? lockdep_hardirqs_on+0x77/0x100
? _raw_spin_unlock_irqrestore+0x38/0x60
device_offline+0xe3/0x110
state_store+0x6e/0xc0
kernfs_fop_write_iter+0x143/0x200
vfs_write+0x39f/0x560
ksys_write+0x65/0xf0
do_syscall_64+0x62/0x130

Previously, some sanity check have been done in dump_mapping() before
the print facility parsing '%pd' though, it's still possible to run into
an invalid dentry.d_name.name.

Since dump_mapping() only needs to dump the filename only, retrieve it
by itself in a safer way to prevent an unnecessary crash.

Note that either retrieving the filename with '%pd' or
strncpy_from_kernel_nofault(), the filename could be unreliable.</Note>
    </Notes>
    <CVE>CVE-2024-49934</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ACPI: PAD: fix crash in exit_round_robin()

The kernel occasionally crashes in cpumask_clear_cpu(), which is called
within exit_round_robin(), because when executing clear_bit(nr, addr) with
nr set to 0xffffffff, the address calculation may cause misalignment within
the memory, leading to access to an invalid memory address.

----------
BUG: unable to handle kernel paging request at ffffffffe0740618
        ...
CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G           OE  X --------- -  - 4.18.0-425.19.2.el8_7.x86_64 #1
        ...
RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad]
Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 &lt;f0&gt; 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31
RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202
RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8
R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e
R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e
FS:  0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 ? acpi_pad_add+0x120/0x120 [acpi_pad]
 kthread+0x10b/0x130
 ? set_kthread_struct+0x50/0x50
 ret_from_fork+0x1f/0x40
        ...
CR2: ffffffffe0740618

crash&gt; dis -lr ffffffffc0726923
        ...
/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114
0xffffffffc0726918 &lt;power_saving_thread+776&gt;:	mov    %r12d,%r12d
/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325
0xffffffffc072691b &lt;power_saving_thread+779&gt;:	mov    -0x3f8d7de0(,%r12,4),%eax
/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80
0xffffffffc0726923 &lt;power_saving_thread+787&gt;:	lock btr %rax,0x19cf4(%rip)        # 0xffffffffc0740620 &lt;pad_busy_cpus_bits&gt;

crash&gt; px tsk_in_cpu[14]
$66 = 0xffffffff

crash&gt; px 0xffffffffc072692c+0x19cf4
$99 = 0xffffffffc0740620

crash&gt; sym 0xffffffffc0740620
ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad]

crash&gt; px pad_busy_cpus_bits[0]
$42 = 0xfffc0
----------

To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling
cpumask_clear_cpu() in exit_round_robin(), just as it is done in
round_robin_cpu().

[ rjw: Subject edit, avoid updates to the same value ]</Note>
    </Notes>
    <CVE>CVE-2024-49935</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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-&gt;next after the entry becomes free.

Therefore, to solve this, you need to change it to list_for_each_entry_safe.</Note>
    </Notes>
    <CVE>CVE-2024-49936</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: cfg80211: Set correct chandef when starting CAC

When starting CAC in a mode other than AP mode, it return a
"WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]"
caused by the chandef.chan being null at the end of CAC.

Solution: Ensure the channel definition is set for the different modes
when starting CAC to avoid getting a NULL 'chan' at the end of CAC.

 Call Trace:
  ? show_regs.part.0+0x14/0x16
  ? __warn+0x67/0xc0
  ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]
  ? report_bug+0xa7/0x130
  ? exc_overflow+0x30/0x30
  ? handle_bug+0x27/0x50
  ? exc_invalid_op+0x18/0x60
  ? handle_exception+0xf6/0xf6
  ? exc_overflow+0x30/0x30
  ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]
  ? exc_overflow+0x30/0x30
  ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]
  ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211]
  ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211]
  ? process_one_work+0x165/0x280
  ? worker_thread+0x120/0x3f0
  ? kthread+0xc2/0xf0
  ? process_one_work+0x280/0x280
  ? kthread_complete_and_exit+0x20/0x20
  ? ret_from_fork+0x19/0x24

[shorten subject, remove OCB, reorder cases to match previous list]</Note>
    </Notes>
    <CVE>CVE-2024-49937</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit

Syzbot points out that skb_trim() has a sanity check on the existing length of
the skb, which can be uninitialised in some error paths. The intent here is
clearly just to reset the length to zero before resubmitting, so switch to
calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length()
already contains a call to skb_reset_tail_pointer(), so remove the redundant
call.

The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar
usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.</Note>
    </Notes>
    <CVE>CVE-2024-49938</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: rtw89: avoid to add interface to list twice when SER

If SER L2 occurs during the WoWLAN resume flow, the add interface flow
is triggered by ieee80211_reconfig(). However, due to
rtw89_wow_resume() return failure, it will cause the add interface flow
to be executed again, resulting in a double add list and causing a kernel
panic. Therefore, we have added a check to prevent double adding of the
list.

list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628.
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:37!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G        W  O       6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7
Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021
Workqueue: events_freezable ieee80211_restart_work [mac80211]
RIP: 0010:__list_add_valid_or_report+0x5e/0xb0
Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 &lt;0f&gt; 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12
RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246
RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900
RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001
RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0
R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060
R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010
FS:  0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0
Call Trace:
 &lt;TASK&gt;
 ? __die_body+0x1f/0x70
 ? die+0x3d/0x60
 ? do_trap+0xa4/0x110
 ? __list_add_valid_or_report+0x5e/0xb0
 ? do_error_trap+0x6d/0x90
 ? __list_add_valid_or_report+0x5e/0xb0
 ? handle_invalid_op+0x30/0x40
 ? __list_add_valid_or_report+0x5e/0xb0
 ? exc_invalid_op+0x3c/0x50
 ? asm_exc_invalid_op+0x16/0x20
 ? __list_add_valid_or_report+0x5e/0xb0
 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f]
 drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]
 ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]
 ? finish_wait+0x3e/0x90
 ? synchronize_rcu_expedited+0x174/0x260
 ? sync_rcu_exp_done_unlocked+0x50/0x50
 ? wake_bit_function+0x40/0x40
 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]
 process_scheduled_works+0x1e5/0x480
 worker_thread+0xea/0x1e0
 kthread+0xdb/0x110
 ? move_linked_works+0x90/0x90
 ? kthread_associate_blkcg+0xa0/0xa0
 ret_from_fork+0x3b/0x50
 ? kthread_associate_blkcg+0xa0/0xa0
 ret_from_fork_asm+0x11/0x20
 &lt;/TASK&gt;
Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev
gsmi: Log Shutdown Reason 0x03
---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2024-49939</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start

In sctp_listen_start() invoked by sctp_inet_listen(), it should set the
sk_state back to CLOSED if sctp_autobind() fails due to whatever reason.

Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)-&gt;reuse
is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)-&gt;bind_hash will
be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash
is NULL.

  KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
  RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617
  Call Trace:
   &lt;TASK&gt;
   __sys_listen_socket net/socket.c:1883 [inline]
   __sys_listen+0x1b7/0x230 net/socket.c:1894
   __do_sys_listen net/socket.c:1902 [inline]</Note>
    </Notes>
    <CVE>CVE-2024-49944</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-49945</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ppp: do not assume bh is held in ppp_channel_bridge_input()

Networking receive path is usually handled from BH handler.
However, some protocols need to acquire the socket lock, and
packets might be stored in the socket backlog is the socket was
owned by a user process.

In this case, release_sock(), __release_sock(), and sk_backlog_rcv()
might call the sk-&gt;sk_backlog_rcv() handler in process context.

sybot caught ppp was not considering this case in
ppp_channel_bridge_input() :

WARNING: inconsistent lock state
6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted
--------------------------------
inconsistent {SOFTIRQ-ON-W} -&gt; {IN-SOFTIRQ-W} usage.
ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes:
 ffff0000db7f11e0 (&amp;pch-&gt;downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline]
 ffff0000db7f11e0 (&amp;pch-&gt;downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline]
 ffff0000db7f11e0 (&amp;pch-&gt;downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304
{SOFTIRQ-ON-W} state was registered at:
   lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759
   __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]
   _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154
   spin_lock include/linux/spinlock.h:351 [inline]
   ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline]
   ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304
   pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379
   sk_backlog_rcv include/net/sock.h:1111 [inline]
   __release_sock+0x1a8/0x3d8 net/core/sock.c:3004
   release_sock+0x68/0x1b8 net/core/sock.c:3558
   pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903
   sock_sendmsg_nosec net/socket.c:730 [inline]
   __sock_sendmsg net/socket.c:745 [inline]
   __sys_sendto+0x374/0x4f4 net/socket.c:2204
   __do_sys_sendto net/socket.c:2216 [inline]
   __se_sys_sendto net/socket.c:2212 [inline]
   __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212
   __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
   invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49
   el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132
   do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151
   el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712
   el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730
   el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598
irq event stamp: 282914
 hardirqs last  enabled at (282914): [&lt;ffff80008b42e30c&gt;] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline]
 hardirqs last  enabled at (282914): [&lt;ffff80008b42e30c&gt;] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194
 hardirqs last disabled at (282913): [&lt;ffff80008b42e13c&gt;] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]
 hardirqs last disabled at (282913): [&lt;ffff80008b42e13c&gt;] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162
 softirqs last  enabled at (282904): [&lt;ffff8000801f8e88&gt;] softirq_handle_end kernel/softirq.c:400 [inline]
 softirqs last  enabled at (282904): [&lt;ffff8000801f8e88&gt;] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582
 softirqs last disabled at (282909): [&lt;ffff8000801fbdf8&gt;] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&amp;pch-&gt;downl);
  &lt;Interrupt&gt;
    lock(&amp;pch-&gt;downl);

 *** DEADLOCK ***

1 lock held by ksoftirqd/1/24:
  #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325

stack backtrace:
CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
Call trace:
  dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319
  show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326
  __dump_sta
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-49946</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: test for not too small csum_start in virtio_net_hdr_to_skb()

syzbot was able to trigger this warning [1], after injecting a
malicious packet through af_packet, setting skb-&gt;csum_start and thus
the transport header to an incorrect value.

We can at least make sure the transport header is after
the end of the network header (with a estimated minimal size).

[1]
[   67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0
mac=(-1,-1) mac_len=0 net=(16,-6) trans=10
shinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0))
csum(0xa start=10 offset=0 ip_summed=3 complete_sw=0 valid=0 level=0)
hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0
priority=0x0 mark=0x0 alloc_cpu=10 vlan_all=0x0
encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0)
[   67.877172] dev name=veth0_vlan feat=0x000061164fdd09e9
[   67.877764] sk family=17 type=3 proto=0
[   67.878279] skb linear:   00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00
[   67.879128] skb frag:     00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02
[   67.879877] skb frag:     00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   67.880647] skb frag:     00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00
[   67.881156] skb frag:     00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   67.881753] skb frag:     00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   67.882173] skb frag:     00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   67.882790] skb frag:     00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   67.883171] skb frag:     00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   67.883733] skb frag:     00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   67.884206] skb frag:     00000090: 00 00 00 00 00 00 00 00 00 00 69 70 76 6c 61 6e
[   67.884704] skb frag:     000000a0: 31 00 00 00 00 00 00 00 00 00 2b 00 00 00 00 00
[   67.885139] skb frag:     000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   67.885677] skb frag:     000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   67.886042] skb frag:     000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   67.886408] skb frag:     000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   67.887020] skb frag:     000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   67.887384] skb frag:     00000100: 00 00
[   67.887878] ------------[ cut here ]------------
[   67.887908] offset (-6) &gt;= skb_headlen() (14)
[   67.888445] WARNING: CPU: 10 PID: 2088 at net/core/dev.c:3332 skb_checksum_help (net/core/dev.c:3332 (discriminator 2))
[   67.889353] Modules linked in: macsec macvtap macvlan hsr wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 libchacha poly1305_x86_64 dummy bridge sr_mod cdrom evdev pcspkr i2c_piix4 9pnet_virtio 9p 9pnet netfs
[   67.890111] CPU: 10 UID: 0 PID: 2088 Comm: b363492833 Not tainted 6.11.0-virtme #1011
[   67.890183] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[   67.890309] RIP: 0010:skb_checksum_help (net/core/dev.c:3332 (discriminator 2))
[   67.891043] Call Trace:
[   67.891173]  &lt;TASK&gt;
[   67.891274] ? __warn (kernel/panic.c:741)
[   67.891320] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2))
[   67.891333] ? report_bug (lib/bug.c:180 lib/bug.c:219)
[   67.891348] ? handle_bug (arch/x86/kernel/traps.c:239)
[   67.891363] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))
[   67.891372] ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)
[   67.891388] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2))
[   67.891399] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2))
[   67.891416] ip_do_fragment (net/ipv4/ip_output.c:777 (discriminator 1))
[   67.891448] ? __ip_local_out (./include/linux/skbuff.h:1146 ./include/net/l3mdev.h:196 ./include/net/l3mdev.h:213 ne
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-49947</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: avoid potential underflow in qdisc_pkt_len_init() with UFO

After commit 7c6d2ecbda83 ("net: be more gentle about silly gso
requests coming from user") virtio_net_hdr_to_skb() had sanity check
to detect malicious attempts from user space to cook a bad GSO packet.

Then commit cf9acc90c80ec ("net: virtio_net_hdr_to_skb: count
transport header in UFO") while fixing one issue, allowed user space
to cook a GSO packet with the following characteristic :

IPv4 SKB_GSO_UDP, gso_size=3, skb-&gt;len = 28.

When this packet arrives in qdisc_pkt_len_init(), we end up
with hdr_len = 28 (IPv4 header + UDP header), matching skb-&gt;len

Then the following sets gso_segs to 0 :

gso_segs = DIV_ROUND_UP(skb-&gt;len - hdr_len,
                        shinfo-&gt;gso_size);

Then later we set qdisc_skb_cb(skb)-&gt;pkt_len to back to zero :/

qdisc_skb_cb(skb)-&gt;pkt_len += (gso_segs - 1) * hdr_len;

This leads to the following crash in fq_codel [1]

qdisc_pkt_len_init() is best effort, we only want an estimation
of the bytes sent on the wire, not crashing the kernel.

This patch is fixing this particular issue, a following one
adds more sanity checks for another potential bug.

[1]
[   70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000
[   70.724561] #PF: supervisor read access in kernel mode
[   70.724561] #PF: error_code(0x0000) - not-present page
[   70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0
[   70.724561] Oops: Oops: 0000 [#1] SMP NOPTI
[   70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991
[   70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[   70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel
[ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 &lt;49&gt; 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49
All code
========
   0:	24 08                	and    $0x8,%al
   2:	49 c1 e1 06          	shl    $0x6,%r9
   6:	44 89 7c 24 18       	mov    %r15d,0x18(%rsp)
   b:	45 31 ed             	xor    %r13d,%r13d
   e:	45 31 c0             	xor    %r8d,%r8d
  11:	31 ff                	xor    %edi,%edi
  13:	89 44 24 14          	mov    %eax,0x14(%rsp)
  17:	4c 03 8b 90 01 00 00 	add    0x190(%rbx),%r9
  1e:	eb 04                	jmp    0x24
  20:	39 ca                	cmp    %ecx,%edx
  22:	73 37                	jae    0x5b
  24:	4d 8b 39             	mov    (%r9),%r15
  27:	83 c7 01             	add    $0x1,%edi
  2a:*	49 8b 17             	mov    (%r15),%rdx		&lt;-- trapping instruction
  2d:	49 89 11             	mov    %rdx,(%r9)
  30:	41 8b 57 28          	mov    0x28(%r15),%edx
  34:	45 8b 5f 34          	mov    0x34(%r15),%r11d
  38:	49 c7 07 00 00 00 00 	movq   $0x0,(%r15)
  3f:	49                   	rex.WB

Code starting with the faulting instruction
===========================================
   0:	49 8b 17             	mov    (%r15),%rdx
   3:	49 89 11             	mov    %rdx,(%r9)
   6:	41 8b 57 28          	mov    0x28(%r15),%edx
   a:	45 8b 5f 34          	mov    0x34(%r15),%r11d
   e:	49 c7 07 00 00 00 00 	movq   $0x0,(%r15)
  15:	49                   	rex.WB
[   70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202
[   70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000
[   70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
[   70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000
[   70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58
[   70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000
[   70.724561] FS:  000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000
[   70.724561] CS:  0010 DS: 0000 ES: 0000 C
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-49949</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: Fix uaf in l2cap_connect

[Syzbot reported]
BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949
Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54

CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
Workqueue: hci2 hci_rx_work
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:93 [inline]
 dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0xc3/0x620 mm/kasan/report.c:488
 kasan_report+0xd9/0x110 mm/kasan/report.c:601
 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949
 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline]
 l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline]
 l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline]
 l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825
 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514
 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline]
 hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028
 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231
 process_scheduled_works kernel/workqueue.c:3312 [inline]
 worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389
 kthread+0x2c1/0x3a0 kernel/kthread.c:389
 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
...

Freed by task 5245:
 kasan_save_stack+0x33/0x60 mm/kasan/common.c:47
 kasan_save_track+0x14/0x30 mm/kasan/common.c:68
 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579
 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240
 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256
 kasan_slab_free include/linux/kasan.h:184 [inline]
 slab_free_hook mm/slub.c:2256 [inline]
 slab_free mm/slub.c:4477 [inline]
 kfree+0x12a/0x3b0 mm/slub.c:4598
 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline]
 kref_put include/linux/kref.h:65 [inline]
 l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline]
 l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802
 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241
 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline]
 hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265
 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583
 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917
 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328
 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231
 process_scheduled_works kernel/workqueue.c:3312 [inline]
 worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389
 kthread+0x2c1/0x3a0 kernel/kthread.c:389
 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244</Note>
    </Notes>
    <CVE>CVE-2024-49950</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: prevent nf_skb_duplicated corruption

syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write
per-cpu variable nf_skb_duplicated in an unsafe way [1].

Disabling preemption as hinted by the splat is not enough,
we have to disable soft interrupts as well.

[1]
BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316
 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87
CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
Call Trace:
 &lt;TASK&gt;
  __dump_stack lib/dump_stack.c:93 [inline]
  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
  check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49
  nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87
  nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30
  expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
  nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288
  nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23
  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
  nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626
  nf_hook+0x2c4/0x450 include/linux/netfilter.h:269
  NF_HOOK_COND include/linux/netfilter.h:302 [inline]
  ip_output+0x185/0x230 net/ipv4/ip_output.c:433
  ip_local_out net/ipv4/ip_output.c:129 [inline]
  ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495
  udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981
  udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x1a6/0x270 net/socket.c:745
  ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597
  ___sys_sendmsg net/socket.c:2651 [inline]
  __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737
  __do_sys_sendmmsg net/socket.c:2766 [inline]
  __se_sys_sendmmsg net/socket.c:2763 [inline]
  __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763
  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
RIP: 0033:0x7f4ce4f7def9
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 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9
RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006
RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-49952</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice

The km.state is not checked in driver's delayed work. When
xfrm_state_check_expire() is called, the state can be reset to
XFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This
happens when xfrm state is deleted, but not freed yet. As
__xfrm_state_delete() is called again in xfrm timer, the following
crash occurs.

To fix this issue, skip xfrm_state_check_expire() if km.state is not
XFRM_STATE_VALID.

 Oops: general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP
 CPU: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 Not tainted 6.11.0-rc2+ #1
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
 Workqueue: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core]
 RIP: 0010:__xfrm_state_delete+0x3d/0x1b0
 Code: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 &lt;48&gt; 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48
 RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246
 RAX: dead000000000122 RBX: ffffffff82afa940 RCX: 0000000000000036
 RDX: dead000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980
 RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000
 R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246
 R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400
 FS:  0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 Call Trace:
  &lt;IRQ&gt;
  ? die_addr+0x33/0x90
  ? exc_general_protection+0x1a2/0x390
  ? asm_exc_general_protection+0x22/0x30
  ? __xfrm_state_delete+0x3d/0x1b0
  ? __xfrm_state_delete+0x2f/0x1b0
  xfrm_timer_handler+0x174/0x350
  ? __xfrm_state_delete+0x1b0/0x1b0
  __hrtimer_run_queues+0x121/0x270
  hrtimer_run_softirq+0x88/0xd0
  handle_softirqs+0xcc/0x270
  do_softirq+0x3c/0x50
  &lt;/IRQ&gt;
  &lt;TASK&gt;
  __local_bh_enable_ip+0x47/0x50
  mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core]
  process_one_work+0x137/0x2d0
  worker_thread+0x28d/0x3a0
  ? rescuer_thread+0x480/0x480
  kthread+0xb8/0xe0
  ? kthread_park+0x80/0x80
  ret_from_fork+0x2d/0x50
  ? kthread_park+0x80/0x80
  ret_from_fork_asm+0x11/0x20
  &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-49953</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

static_call: Replace pointless WARN_ON() in static_call_module_notify()

static_call_module_notify() triggers a WARN_ON(), when memory allocation
fails in __static_call_add_module().

That's not really justified, because the failure case must be correctly
handled by the well known call chain and the error code is passed
through to the initiating userspace application.

A memory allocation fail is not a fatal problem, but the WARN_ON() takes
the machine out when panic_on_warn is set.

Replace it with a pr_warn().</Note>
    </Notes>
    <CVE>CVE-2024-49954</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ACPI: battery: Fix possible crash when unregistering a battery hook

When a battery hook returns an error when adding a new battery, then
the battery hook is automatically unregistered.
However the battery hook provider cannot know that, so it will later
call battery_hook_unregister() on the already unregistered battery
hook, resulting in a crash.

Fix this by using the list head to mark already unregistered battery
hooks as already being unregistered so that they can be ignored by
battery_hook_unregister().</Note>
    </Notes>
    <CVE>CVE-2024-49955</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix null-ptr-deref when journal load failed.

During the mounting process, if journal_reset() fails because of too short
journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. 
Subsequently, ocfs2_journal_shutdown() calls
jbd2_journal_flush()-&gt;jbd2_cleanup_journal_tail()-&gt;
__jbd2_update_log_tail()-&gt;jbd2_journal_update_sb_log_tail()
-&gt;lock_buffer(journal-&gt;j_sb_buffer), resulting in a null-pointer
dereference error.

To resolve this issue, we should check the JBD2_LOADED flag to ensure the
journal was properly loaded.  Additionally, use journal instead of
osb-&gt;journal directly to simplify the code.</Note>
    </Notes>
    <CVE>CVE-2024-49957</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: reserve space for inline xattr before attaching reflink tree

One of our customers reported a crash and a corrupted ocfs2 filesystem. 
The crash was due to the detection of corruption.  Upon troubleshooting,
the fsck -fn output showed the below corruption

[EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record,
but fsck believes the largest valid value is 227.  Clamp the next record value? n

The stat output from the debugfs.ocfs2 showed the following corruption
where the "Next Free Rec:" had overshot the "Count:" in the root metadata
block.

        Inode: 33080590   Mode: 0640   Generation: 2619713622 (0x9c25a856)
        FS Generation: 904309833 (0x35e6ac49)
        CRC32: 00000000   ECC: 0000
        Type: Regular   Attr: 0x0   Flags: Valid
        Dynamic Features: (0x16) HasXattr InlineXattr Refcounted
        Extended Attributes Block: 0  Extended Attributes Inline Size: 256
        User: 0 (root)   Group: 0 (root)   Size: 281320357888
        Links: 1   Clusters: 141738
        ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024
        atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024
        mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024
        dtime: 0x0 -- Wed Dec 31 17:00:00 1969
        Refcount Block: 2777346
        Last Extblk: 2886943   Orphan Slot: 0
        Sub Alloc Slot: 0   Sub Alloc Bit: 14
        Tree Depth: 1   Count: 227   Next Free Rec: 230
        ## Offset        Clusters       Block#
        0  0             2310           2776351
        1  2310          2139           2777375
        2  4449          1221           2778399
        3  5670          731            2779423
        4  6401          566            2780447
        .......          ....           .......
        .......          ....           .......

The issue was in the reflink workfow while reserving space for inline
xattr.  The problematic function is ocfs2_reflink_xattr_inline().  By the
time this function is called the reflink tree is already recreated at the
destination inode from the source inode.  At this point, this function
reserves space for inline xattrs at the destination inode without even
checking if there is space at the root metadata block.  It simply reduces
the l_count from 243 to 227 thereby making space of 256 bytes for inline
xattr whereas the inode already has extents beyond this index (in this
case up to 230), thereby causing corruption.

The fix for this is to reserve space for inline metadata at the destination
inode before the reflink tree gets recreated. The customer has verified the
fix.</Note>
    </Notes>
    <CVE>CVE-2024-49958</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error

In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail()
to recover some journal space. But if an error occurs while executing
jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free
space right away, we try other branches, and if j_committing_transaction
is NULL (i.e., the tid is 0), we will get the following complain:

============================================
JBD2: I/O error when updating journal superblock for sdd-8.
__jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available
__jbd2_log_wait_for_space: no way to get more journal space in sdd-8
------------[ cut here ]------------
WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0
Modules linked in:
CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1
RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0
Call Trace:
 &lt;TASK&gt;
 add_transaction_credits+0x5d1/0x5e0
 start_this_handle+0x1ef/0x6a0
 jbd2__journal_start+0x18b/0x340
 ext4_dirty_inode+0x5d/0xb0
 __mark_inode_dirty+0xe4/0x5d0
 generic_update_time+0x60/0x70
[...]
============================================

So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to
clean up at the moment, continue to try to reclaim free space in other ways.

Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt
when updating journal superblock fails") to make jbd2_cleanup_journal_tail
return the correct error code.</Note>
    </Notes>
    <CVE>CVE-2024-49959</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-49960</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: i2c: ar0521: Use cansleep version of gpiod_set_value()

If we use GPIO reset from I2C port expander, we must use *_cansleep()
variant of GPIO functions.
This was not done in ar0521_power_on()/ar0521_power_off() functions.
Let's fix that.

------------[ cut here ]------------
WARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c
Modules linked in:
CPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53
Hardware name: Diasom DS-RK3568-SOM-EVB (DT)
Workqueue: events_unbound deferred_probe_work_func
pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : gpiod_set_value+0x74/0x7c
lr : ar0521_power_on+0xcc/0x290
sp : ffffff8001d7ab70
x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000
x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088
x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088
x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80
x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000
x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930
x11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0
x8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780
x5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000
x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001
Call trace:
 gpiod_set_value+0x74/0x7c
 ar0521_power_on+0xcc/0x290
...</Note>
    </Notes>
    <CVE>CVE-2024-49961</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package()

ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0

ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause
NULL pointer dereference later.

[ rjw: Subject and changelog edits ]</Note>
    </Notes>
    <CVE>CVE-2024-49962</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mailbox: bcm2835: Fix timeout during suspend mode

During noirq suspend phase the Raspberry Pi power driver suffer of
firmware property timeouts. The reason is that the IRQ of the underlying
BCM2835 mailbox is disabled and rpi_firmware_property_list() will always
run into a timeout [1].

Since the VideoCore side isn't consider as a wakeup source, set the
IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled
during suspend-resume cycle.

[1]
PM: late suspend of devices complete after 1.754 msecs
WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128
 rpi_firmware_property_list+0x204/0x22c
Firmware transaction 0x00028001 timeout
Modules linked in:
CPU: 0 PID: 438 Comm: bash Tainted: G         C         6.9.3-dirty #17
Hardware name: BCM2835
Call trace:
unwind_backtrace from show_stack+0x18/0x1c
show_stack from dump_stack_lvl+0x34/0x44
dump_stack_lvl from __warn+0x88/0xec
__warn from warn_slowpath_fmt+0x7c/0xb0
warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c
rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c
rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0
rpi_firmware_set_power from _genpd_power_off+0xe4/0x148
_genpd_power_off from genpd_sync_power_off+0x7c/0x11c
genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0
genpd_finish_suspend from dpm_run_callback+0x78/0xd0
dpm_run_callback from device_suspend_noirq+0xc0/0x238
device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168
dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac
suspend_devices_and_enter from pm_suspend+0x254/0x2e4
pm_suspend from state_store+0xa8/0xd4
state_store from kernfs_fop_write_iter+0x154/0x1a0
kernfs_fop_write_iter from vfs_write+0x12c/0x184
vfs_write from ksys_write+0x78/0xc0
ksys_write from ret_fast_syscall+0x0/0x54
Exception stack(0xcc93dfa8 to 0xcc93dff0)
[...]
PM: noirq suspend of devices complete after 3095.584 msecs</Note>
    </Notes>
    <CVE>CVE-2024-49963</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: remove unreasonable unlock in ocfs2_read_blocks

Patch series "Misc fixes for ocfs2_read_blocks", v5.

This series contains 2 fixes for ocfs2_read_blocks().  The first patch fix
the issue reported by syzbot, which detects bad unlock balance in
ocfs2_read_blocks().  The second patch fixes an issue reported by Heming
Zhao when reviewing above fix.


This patch (of 2):

There was a lock release before exiting, so remove the unreasonable unlock.</Note>
    </Notes>
    <CVE>CVE-2024-49965</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: cancel dqi_sync_work before freeing oinfo

ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the
end, if error occurs after successfully reading global quota, it will
trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled:

ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c

This reports that there is an active delayed work when freeing oinfo in
error handling, so cancel dqi_sync_work first.  BTW, return status instead
of -1 when .read_file_info fails.</Note>
    </Notes>
    <CVE>CVE-2024-49966</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2024-49967</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: filesystems without casefold feature cannot be mounted with siphash

When mounting the ext4 filesystem, if the default hash version is set to
DX_HASH_SIPHASH but the casefold feature is not set, exit the mounting.</Note>
    </Notes>
    <CVE>CVE-2024-49968</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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-&gt;tf_pts.red' 1025 &lt;= 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-&gt;tf_pts.green' 1025 &lt;= 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-&gt;tf_pts.blue' 1025 &lt;= s32max</Note>
    </Notes>
    <CVE>CVE-2024-49969</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Deallocate DML memory if allocation fails

[Why]
When DC state create DML memory allocation fails, memory is not
deallocated subsequently, resulting in uninitialized structure
that is not NULL.

[How]
Deallocate memory if DML memory allocation fails.</Note>
    </Notes>
    <CVE>CVE-2024-49972</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

r8169: add tally counter fields added with RTL8125

RTL8125 added fields to the tally counter, what may result in the chip
dma'ing these new fields to unallocated memory. Therefore make sure
that the allocated memory area is big enough to hold all of the
tally counter values, even if we use only parts of it.</Note>
    </Notes>
    <CVE>CVE-2024-49973</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-49974</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tracing/timerlat: Drop interface_lock in stop_kthread()

stop_kthread() is the offline callback for "trace/osnoise:online", since
commit 5bfbcd1ee57b ("tracing/timerlat: Add interface_lock around clearing
of kthread in stop_kthread()"), the following ABBA deadlock scenario is
introduced:

T1                            | T2 [BP]               | T3 [AP]
osnoise_hotplug_workfn()      | work_for_cpu_fn()     | cpuhp_thread_fun()
                              |   _cpu_down()         |   osnoise_cpu_die()
  mutex_lock(&amp;interface_lock) |                       |     stop_kthread()
                              |     cpus_write_lock() |       mutex_lock(&amp;interface_lock)
  cpus_read_lock()            |     cpuhp_kick_ap()   |

As the interface_lock here in just for protecting the "kthread" field of
the osn_var, use xchg() instead to fix this issue. Also use
for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take
cpu_read_lock() again.</Note>
    </Notes>
    <CVE>CVE-2024-49976</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: venus: fix use after free bug in venus_remove due to race condition

in venus_probe, core-&gt;work is bound with venus_sys_error_handler, which is
used to handle error. The code use core-&gt;sys_err_done to make sync work.
The core-&gt;work is started in venus_event_notify.

If we call venus_remove, there might be an unfished work. The possible
sequence is as follows:

CPU0                  CPU1

                     |venus_sys_error_handler
venus_remove         |
hfi_destroy	 		 |
venus_hfi_destroy	 |
kfree(hdev);	     |
                     |hfi_reinit
					 |venus_hfi_queues_reinit
                     |//use hdev

Fix it by canceling the work in venus_remove.</Note>
    </Notes>
    <CVE>CVE-2024-49981</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free

When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(),
the 'ppath' is updated but it is the 'path' that is freed, thus potentially
triggering a double-free in the following process:

ext4_ext_replay_update_ex
  ppath = path
  ext4_force_split_extent_at(&amp;ppath)
    ext4_split_extent_at
      ext4_ext_insert_extent
        ext4_ext_create_new_leaf
          ext4_ext_grow_indepth
            ext4_find_extent
              if (depth &gt; path[0].p_maxdepth)
                kfree(path)                 ---&gt; path First freed
                *orig_path = path = NULL    ---&gt; null ppath
  kfree(path)                               ---&gt; path double-free !!!

So drop the unnecessary ppath and use path directly to avoid this problem.
And use ext4_find_extent() directly to update path, avoiding unnecessary
memory allocation and freeing. Also, propagate the error returned by
ext4_find_extent() instead of using strange error codes.</Note>
    </Notes>
    <CVE>CVE-2024-49983</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume

In case there is any sort of clock controller attached to this I2C bus
controller, for example Versaclock or even an AIC32x4 I2C codec, then
an I2C transfer triggered from the clock controller clk_ops .prepare
callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex.

This is because the clock controller first grabs the prepare_lock mutex
and then performs the prepare operation, including its I2C access. The
I2C access resumes this I2C bus controller via .runtime_resume callback,
which calls clk_prepare_enable(), which attempts to grab the prepare_lock
mutex again and deadlocks.

Since the clock are already prepared since probe() and unprepared in
remove(), use simple clk_enable()/clk_disable() calls to enable and
disable the clock on runtime suspend and resume, to avoid hitting the
prepare_lock mutex.</Note>
    </Notes>
    <CVE>CVE-2024-49985</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors

x86_android_tablet_remove() frees the pdevs[] array, so it should not
be used after calling x86_android_tablet_remove().

When platform_device_register() fails, store the pdevs[x] PTR_ERR() value
into the local ret variable before calling x86_android_tablet_remove()
to avoid using pdevs[] after it has been freed.</Note>
    </Notes>
    <CVE>CVE-2024-49986</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpftool: Fix undefined behavior in qsort(NULL, 0, ...)

When netfilter has no entry to display, qsort is called with
qsort(NULL, 0, ...). This results in undefined behavior, as UBSan
reports:

net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null

Although the C standard does not explicitly state whether calling qsort
with a NULL pointer when the size is 0 constitutes undefined behavior,
Section 7.1.4 of the C standard (Use of library functions) mentions:

"Each of the following statements applies unless explicitly stated
otherwise in the detailed descriptions that follow: If an argument to a
function has an invalid value (such as a value outside the domain of
the function, or a pointer outside the address space of the program, or
a null pointer, or a pointer to non-modifiable storage when the
corresponding parameter is not const-qualified) or a type (after
promotion) not expected by a function with variable number of
arguments, the behavior is undefined."

To avoid this, add an early return when nf_link_info is NULL to prevent
calling qsort with a NULL pointer.</Note>
    </Notes>
    <CVE>CVE-2024-49987</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: fix double free issue during amdgpu module unload

Flexible endpoints use DIGs from available inflexible endpoints,
so only the encoders of inflexible links need to be freed.
Otherwise, a double free issue may occur when unloading the
amdgpu module.

[  279.190523] RIP: 0010:__slab_free+0x152/0x2f0
[  279.190577] Call Trace:
[  279.190580]  &lt;TASK&gt;
[  279.190582]  ? show_regs+0x69/0x80
[  279.190590]  ? die+0x3b/0x90
[  279.190595]  ? do_trap+0xc8/0xe0
[  279.190601]  ? do_error_trap+0x73/0xa0
[  279.190605]  ? __slab_free+0x152/0x2f0
[  279.190609]  ? exc_invalid_op+0x56/0x70
[  279.190616]  ? __slab_free+0x152/0x2f0
[  279.190642]  ? asm_exc_invalid_op+0x1f/0x30
[  279.190648]  ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu]
[  279.191096]  ? __slab_free+0x152/0x2f0
[  279.191102]  ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu]
[  279.191469]  kfree+0x260/0x2b0
[  279.191474]  dcn10_link_encoder_destroy+0x19/0x30 [amdgpu]
[  279.191821]  link_destroy+0xd7/0x130 [amdgpu]
[  279.192248]  dc_destruct+0x90/0x270 [amdgpu]
[  279.192666]  dc_destroy+0x19/0x40 [amdgpu]
[  279.193020]  amdgpu_dm_fini+0x16e/0x200 [amdgpu]
[  279.193432]  dm_hw_fini+0x26/0x40 [amdgpu]
[  279.193795]  amdgpu_device_fini_hw+0x24c/0x400 [amdgpu]
[  279.194108]  amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu]
[  279.194436]  amdgpu_pci_remove+0x40/0x80 [amdgpu]
[  279.194632]  pci_device_remove+0x3a/0xa0
[  279.194638]  device_remove+0x40/0x70
[  279.194642]  device_release_driver_internal+0x1ad/0x210
[  279.194647]  driver_detach+0x4e/0xa0
[  279.194650]  bus_remove_driver+0x6f/0xf0
[  279.194653]  driver_unregister+0x33/0x60
[  279.194657]  pci_unregister_driver+0x44/0x90
[  279.194662]  amdgpu_exit+0x19/0x1f0 [amdgpu]
[  279.194939]  __do_sys_delete_module.isra.0+0x198/0x2f0
[  279.194946]  __x64_sys_delete_module+0x16/0x20
[  279.194950]  do_syscall_64+0x58/0x120
[  279.194954]  entry_SYSCALL_64_after_hwframe+0x6e/0x76
[  279.194980]  &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-49989</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-49991</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2024-49993</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2024-49995</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cifs: Fix buffer overflow when parsing NFS reparse points

ReparseDataLength is sum of the InodeType size and DataBuffer size.
So to get DataBuffer size it is needed to subtract InodeType's size from
ReparseDataLength.

Function cifs_strndup_from_utf16() is currentlly accessing buf-&gt;DataBuffer
at position after the end of the buffer because it does not subtract
InodeType size from the length. Fix this problem and correctly subtract
variable len.

Member InodeType is present only when reparse buffer is large enough. Check
for ReparseDataLength before accessing InodeType to prevent another invalid
memory access.

Major and minor rdev values are present also only when reparse buffer is
large enough. Check for reparse buffer size before calling reparse_mkdev().</Note>
    </Notes>
    <CVE>CVE-2024-49996</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc()

In mlx5e_tir_builder_alloc() kvzalloc() may return NULL
which is dereferenced on the next line in a reference
to the modify field.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2024-50000</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: Fix error path in multi-packet WQE transmit

Remove the erroneous unmap in case no DMA mapping was established

The multi-packet WQE transmit code attempts to obtain a DMA mapping for
the skb. This could fail, e.g. under memory pressure, when the IOMMU
driver just can't allocate more memory for page tables. While the code
tries to handle this in the path below the err_unmap label it erroneously
unmaps one entry from the sq's FIFO list of active mappings. Since the
current map attempt failed this unmap is removing some random DMA mapping
that might still be required. If the PCI function now presents that IOVA,
the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI
function in error state.

The erroneous behavior was seen in a stress-test environment that created
memory pressure.</Note>
    </Notes>
    <CVE>CVE-2024-50001</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

static_call: Handle module init failure correctly in static_call_del_module()

Module insertion invokes static_call_add_module() to initialize the static
calls in a module. static_call_add_module() invokes __static_call_init(),
which allocates a struct static_call_mod to either encapsulate the built-in
static call sites of the associated key into it so further modules can be
added or to append the module to the module chain.

If that allocation fails the function returns with an error code and the
module core invokes static_call_del_module() to clean up eventually added
static_call_mod entries.

This works correctly, when all keys used by the module were converted over
to a module chain before the failure. If not then static_call_del_module()
causes a #GP as it blindly assumes that key::mods points to a valid struct
static_call_mod.

The problem is that key::mods is not a individual struct member of struct
static_call_key, it's part of a union to save space:

        union {
                /* bit 0: 0 = mods, 1 = sites */
                unsigned long type;
                struct static_call_mod *mods;
                struct static_call_site *sites;
	};

key::sites is a pointer to the list of built-in usage sites of the static
call. The type of the pointer is differentiated by bit 0. A mods pointer
has the bit clear, the sites pointer has the bit set.

As static_call_del_module() blidly assumes that the pointer is a valid
static_call_mod type, it fails to check for this failure case and
dereferences the pointer to the list of built-in call sites, which is
obviously bogus.

Cure it by checking whether the key has a sites or a mods pointer.

If it's a sites pointer then the key is not to be touched. As the sites are
walked in the same order as in __static_call_init() the site walk can be
terminated because all subsequent sites have not been touched by the init
code due to the error exit.

If it was converted before the allocation fail, then the inner loop which
searches for a module match will find nothing.

A fail in the second allocation in __static_call_init() is harmless and
does not require special treatment. The first allocation succeeded and
converted the key to a module chain. That first entry has mod::mod == NULL
and mod::next == NULL, so the inner loop of static_call_del_module() will
neither find a module match nor a module chain. The next site in the walk
was either already converted, but can't match the module, or it will exit
the outer loop because it has a static_call_site pointer and not a
static_call_mod pointer.</Note>
    </Notes>
    <CVE>CVE-2024-50002</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix system hang while resume with TBT monitor

[Why]
Connected with a Thunderbolt monitor and do the suspend and the system
may hang while resume.

The TBT monitor HPD will be triggered during the resume procedure
and call the drm_client_modeset_probe() while
struct drm_connector connector-&gt;dev-&gt;master is NULL.

It will mess up the pipe topology after resume.

[How]
Skip the TBT monitor HPD during the resume procedure because we
currently will probe the connectors after resume by default.

(cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85)</Note>
    </Notes>
    <CVE>CVE-2024-50003</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: update DML2 policy EnhancedPrefetchScheduleAccelerationFinal DCN35

[WHY &amp; HOW]
Mismatch in DCN35 DML2 cause bw validation failed to acquire unexpected DPP pipe to cause
grey screen and system hang. Remove EnhancedPrefetchScheduleAccelerationFinal value override
to match HW spec.

(cherry picked from commit 9dad21f910fcea2bdcff4af46159101d7f9cd8ba)</Note>
    </Notes>
    <CVE>CVE-2024-50004</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: fix i_data_sem unlock order in ext4_ind_migrate()

Fuzzing reports a possible deadlock in jbd2_log_wait_commit.

This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require
synchronous updates because the file descriptor is opened with O_SYNC.
This can lead to the jbd2_journal_stop() function calling
jbd2_might_wait_for_commit(), potentially causing a deadlock if the
EXT4_IOC_MIGRATE call races with a write(2) system call.

This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this
case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the
jbd2_journal_stop function while i_data_sem is locked. This triggers
lockdep because the jbd2_journal_start function might also lock the same
jbd2_handle simultaneously.

Found by Linux Verification Center (linuxtesting.org) with syzkaller.

Rule: add</Note>
    </Notes>
    <CVE>CVE-2024-50006</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: asihpi: Fix potential OOB array access

ASIHPI driver stores some values in the static array upon a response
from the driver, and its index depends on the firmware.  We shouldn't
trust it blindly.

This patch adds a sanity check of the array index to fit in the array
size.</Note>
    </Notes>
    <CVE>CVE-2024-50007</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext()

Replace one-element array with a flexible-array member in
`struct host_cmd_ds_802_11_scan_ext`.

With this, fix the following warning:

elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------
elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field "ext_scan-&gt;tlv_buffer" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1)
elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex]</Note>
    </Notes>
    <CVE>CVE-2024-50008</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value

cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it
and return in case of error.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2024-50009</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cpufreq: Avoid a bad reference count on CPU node

In the parse_perf_domain function, if the call to
of_parse_phandle_with_args returns an error, then the reference to the
CPU device node that was acquired at the start of the function would not
be properly decremented.

Address this by declaring the variable with the __free(device_node)
cleanup attribute.</Note>
    </Notes>
    <CVE>CVE-2024-50012</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

exfat: fix memory leak in exfat_load_bitmap()

If the first directory entry in the root directory is not a bitmap
directory entry, 'bh' will not be released and reassigned, which
will cause a memory leak.</Note>
    </Notes>
    <CVE>CVE-2024-50013</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: fix access to uninitialised lock in fc replay path

The following kernel trace can be triggered with fstest generic/629 when
executed against a filesystem with fast-commit feature enabled:

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.
CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x66/0x90
 register_lock_class+0x759/0x7d0
 __lock_acquire+0x85/0x2630
 ? __find_get_block+0xb4/0x380
 lock_acquire+0xd1/0x2d0
 ? __ext4_journal_get_write_access+0xd5/0x160
 _raw_spin_lock+0x33/0x40
 ? __ext4_journal_get_write_access+0xd5/0x160
 __ext4_journal_get_write_access+0xd5/0x160
 ext4_reserve_inode_write+0x61/0xb0
 __ext4_mark_inode_dirty+0x79/0x270
 ? ext4_ext_replay_set_iblocks+0x2f8/0x450
 ext4_ext_replay_set_iblocks+0x330/0x450
 ext4_fc_replay+0x14c8/0x1540
 ? jread+0x88/0x2e0
 ? rcu_is_watching+0x11/0x40
 do_one_pass+0x447/0xd00
 jbd2_journal_recover+0x139/0x1b0
 jbd2_journal_load+0x96/0x390
 ext4_load_and_init_journal+0x253/0xd40
 ext4_fill_super+0x2cc6/0x3180
...

In the replay path there's an attempt to lock sbi-&gt;s_bdev_wb_lock in
function ext4_check_bdev_write_error().  Unfortunately, at this point this
spinlock has not been initialized yet.  Moving it's initialization to an
earlier point in __ext4_fill_super() fixes this splat.</Note>
    </Notes>
    <CVE>CVE-2024-50014</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: dax: fix overflowing extents beyond inode size when partially writing

The dax_iomap_rw() does two things in each iteration: map written blocks
and copy user data to blocks. If the process is killed by user(See signal
handling in dax_iomap_iter()), the copied data will be returned and added
on inode size, which means that the length of written extents may exceed
the inode size, then fsck will fail. An example is given as:

dd if=/dev/urandom of=file bs=4M count=1
 dax_iomap_rw
  iomap_iter // round 1
   ext4_iomap_begin
    ext4_iomap_alloc // allocate 0~2M extents(written flag)
  dax_iomap_iter // copy 2M data
  iomap_iter // round 2
   iomap_iter_advance
    iter-&gt;pos += iter-&gt;processed // iter-&gt;pos = 2M
   ext4_iomap_begin
    ext4_iomap_alloc // allocate 2~4M extents(written flag)
  dax_iomap_iter
   fatal_signal_pending
  done = iter-&gt;pos - iocb-&gt;ki_pos // done = 2M
 ext4_handle_inode_extension
  ext4_update_inode_size // inode size = 2M

fsck reports: Inode 13, i_size is 2097152, should be 4194304.  Fix?

Fix the problem by truncating extents if the written length is smaller
than expected.</Note>
    </Notes>
    <CVE>CVE-2024-50015</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2024-50016</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-50017</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2024-50018</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

kthread: unpark only parked kthread

Calling into kthread unparking unconditionally is mostly harmless when
the kthread is already unparked. The wake up is then simply ignored
because the target is not in TASK_PARKED state.

However if the kthread is per CPU, the wake up is preceded by a call
to kthread_bind() which expects the task to be inactive and in
TASK_PARKED state, which obviously isn't the case if it is unparked.

As a result, calling kthread_stop() on an unparked per-cpu kthread
triggers such a warning:

	WARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525
	 &lt;TASK&gt;
	 kthread_stop+0x17a/0x630 kernel/kthread.c:707
	 destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810
	 wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257
	 netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693
	 default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769
	 ops_exit_list net/core/net_namespace.c:178 [inline]
	 cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640
	 process_one_work kernel/workqueue.c:3231 [inline]
	 process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312
	 worker_thread+0x86d/0xd70 kernel/workqueue.c:3393
	 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
	 &lt;/TASK&gt;

Fix this with skipping unecessary unparking while stopping a kthread.</Note>
    </Notes>
    <CVE>CVE-2024-50019</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count()

This patch addresses an issue with improper reference count handling in the
ice_sriov_set_msix_vec_count() function.

First, the function calls ice_get_vf_by_id(), which increments the
reference count of the vf pointer. If the subsequent call to
ice_get_vf_vsi() fails, the function currently returns an error without
decrementing the reference count of the vf pointer, leading to a reference
count leak. The correct behavior, as implemented in this patch, is to
decrement the reference count using ice_put_vf(vf) before returning an
error when vsi is NULL.

Second, the function calls ice_sriov_get_irqs(), which sets
vf-&gt;first_vector_idx. If this call returns a negative value, indicating an
error, the function returns an error without decrementing the reference
count of the vf pointer, resulting in another reference count leak. The
patch addresses this by adding a call to ice_put_vf(vf) before returning
an error when vf-&gt;first_vector_idx &lt; 0.

This bug was identified by an experimental static analysis tool developed
by our team. The tool specializes in analyzing reference count operations
and identifying potential mismanagement of reference counts. In this case,
the tool flagged the missing decrement operation as a potential issue,
leading to this patch.</Note>
    </Notes>
    <CVE>CVE-2024-50020</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins()

This patch addresses a reference count handling issue in the
ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(),
which increments the reference count of the relevant resources. However,
if the condition WARN_ON((!vsi || !vsi-&gt;netdev)) is met, the function
currently returns an error without properly releasing the resources
acquired by ice_dpll_get_pins(), leading to a reference count leak.

To resolve this, the check has been moved to the top of the function. This
ensures that the function verifies the state before any resources are
acquired, avoiding the need for additional resource management in the
error path.

This bug was identified by an experimental static analysis tool developed
by our team. The tool specializes in analyzing reference count operations
and detecting potential issues where resources are not properly managed.
In this case, the tool flagged the missing release operation as a
potential problem, which led to the development of this patch.</Note>
    </Notes>
    <CVE>CVE-2024-50021</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

device-dax: correct pgoff align in dax_set_mapping()

pgoff should be aligned using ALIGN_DOWN() instead of ALIGN().  Otherwise,
vmf-&gt;address not aligned to fault_size will be aligned to the next
alignment, that can result in memory failure getting the wrong address.

It's a subtle situation that only can be observed in
page_mapped_in_vma() after the page is page fault handled by
dev_dax_huge_fault.  Generally, there is little chance to perform
page_mapped_in_vma in dev-dax's page unless in specific error injection
to the dax device to trigger an MCE - memory-failure.  In that case,
page_mapped_in_vma() will be triggered to determine which task is
accessing the failure address and kill that task in the end.


We used self-developed dax device (which is 2M aligned mapping) , to
perform error injection to random address.  It turned out that error
injected to non-2M-aligned address was causing endless MCE until panic.
Because page_mapped_in_vma() kept resulting wrong address and the task
accessing the failure address was never killed properly:


[ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: 
Recovered
[ 3784.049006] mce: Uncorrected hardware memory error in user-access at 
200c9742380
[ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: 
Recovered
[ 3784.448042] mce: Uncorrected hardware memory error in user-access at 
200c9742380
[ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: 
Recovered
[ 3784.792026] mce: Uncorrected hardware memory error in user-access at 
200c9742380
[ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: 
Recovered
[ 3785.162502] mce: Uncorrected hardware memory error in user-access at 
200c9742380
[ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: 
Recovered
[ 3785.461116] mce: Uncorrected hardware memory error in user-access at 
200c9742380
[ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: 
Recovered
[ 3785.764730] mce: Uncorrected hardware memory error in user-access at 
200c9742380
[ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: 
Recovered
[ 3786.042128] mce: Uncorrected hardware memory error in user-access at 
200c9742380
[ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: 
Recovered
[ 3786.464293] mce: Uncorrected hardware memory error in user-access at 
200c9742380
[ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: 
Recovered
[ 3786.818090] mce: Uncorrected hardware memory error in user-access at 
200c9742380
[ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: 
Recovered
[ 3787.085297] mce: Uncorrected hardware memory error in user-access at 
200c9742380
[ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: 
Recovered

It took us several weeks to pinpoint this problem,   but we eventually
used bpftrace to trace the page fault and mce address and successfully
identified the issue.


Joao added:

; Likely we never reproduce in production because we always pin
: device-dax regions in the region align they provide (Qemu does
: similarly with prealloc in hugetlb/file backed memory).  I think this
: bug requires that we touch *unpinned* device-dax regions unaligned to
: the device-dax selected alignment (page size i.e.  4K/2M/1G)</Note>
    </Notes>
    <CVE>CVE-2024-50022</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: phy: Remove LED entry from LEDs list on unregister

Commit c938ab4da0eb ("net: phy: Manual remove LEDs to ensure correct
ordering") correctly fixed a problem with using devm_ but missed
removing the LED entry from the LEDs list.

This cause kernel panic on specific scenario where the port for the PHY
is torn down and up and the kmod for the PHY is removed.

On setting the port down the first time, the assosiacted LEDs are
correctly unregistered. The associated kmod for the PHY is now removed.
The kmod is now added again and the port is now put up, the associated LED
are registered again.
On putting the port down again for the second time after these step, the
LED list now have 4 elements. With the first 2 already unregistered
previously and the 2 new one registered again.

This cause a kernel panic as the first 2 element should have been
removed.

Fix this by correctly removing the element when LED is unregistered.</Note>
    </Notes>
    <CVE>CVE-2024-50023</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: Fix an unsafe loop on the list

The kernel may crash when deleting a genetlink family if there are still
listeners for that family:

Oops: Kernel access of bad area, sig: 11 [#1]
  ...
  NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0
  LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0
  Call Trace:
__netlink_clear_multicast_users+0x74/0xc0
genl_unregister_family+0xd4/0x2d0

Change the unsafe loop on the list to a safe one, because inside the
loop there is an element removal from this list.</Note>
    </Notes>
    <CVE>CVE-2024-50024</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: fnic: Move flush_work initialization out of if block

After commit 379a58caa199 ("scsi: fnic: Move fnic_fnic_flush_tx() to a
work queue"), it can happen that a work item is sent to an uninitialized
work queue.  This may has the effect that the item being queued is never
actually queued, and any further actions depending on it will not
proceed.

The following warning is observed while the fnic driver is loaded:

kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410
kernel:  &lt;IRQ&gt;
kernel:  queue_work_on+0x3a/0x50
kernel:  fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24]
kernel:  fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24]
kernel:  __handle_irq_event_percpu+0x36/0x1a0
kernel:  handle_irq_event_percpu+0x30/0x70
kernel:  handle_irq_event+0x34/0x60
kernel:  handle_edge_irq+0x7e/0x1a0
kernel:  __common_interrupt+0x3b/0xb0
kernel:  common_interrupt+0x58/0xa0
kernel:  &lt;/IRQ&gt;

It has been observed that this may break the rediscovery of Fibre
Channel devices after a temporary fabric failure.

This patch fixes it by moving the work queue initialization out of
an if block in fnic_probe().</Note>
    </Notes>
    <CVE>CVE-2024-50025</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: wd33c93: Don't use stale scsi_pointer value

A regression was introduced with commit dbb2da557a6a ("scsi: wd33c93:
Move the SCSI pointer to private command data") which results in an oops
in wd33c93_intr(). That commit added the scsi_pointer variable and
initialized it from hostdata-&gt;connected. However, during selection,
hostdata-&gt;connected is not yet valid. Fix this by getting the current
scsi_pointer from hostdata-&gt;selecting.</Note>
    </Notes>
    <CVE>CVE-2024-50026</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

thermal: core: Free tzp copy along with the thermal zone

The object pointed to by tz-&gt;tzp may still be accessed after being
freed in thermal_zone_device_unregister(), so move the freeing of it
to the point after the removal completion has been completed at which
it cannot be accessed any more.</Note>
    </Notes>
    <CVE>CVE-2024-50027</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

thermal: core: Reference count the zone in thermal_zone_get_by_id()

There are places in the thermal netlink code where nothing prevents
the thermal zone object from going away while being accessed after it
has been returned by thermal_zone_get_by_id().

To address this, make thermal_zone_get_by_id() get a reference on the
thermal zone device object to be returned with the help of get_device(),
under thermal_list_lock, and adjust all of its callers to this change
with the help of the cleanup.h infrastructure.</Note>
    </Notes>
    <CVE>CVE-2024-50028</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/v3d: Stop the active perfmon before being destroyed

When running `kmscube` with one or more performance monitors enabled
via `GALLIUM_HUD`, the following kernel panic can occur:

[   55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4
[   55.008368] Mem abort info:
[   55.008377]   ESR = 0x0000000096000005
[   55.008387]   EC = 0x25: DABT (current EL), IL = 32 bits
[   55.008402]   SET = 0, FnV = 0
[   55.008412]   EA = 0, S1PTW = 0
[   55.008421]   FSC = 0x05: level 1 translation fault
[   55.008434] Data abort info:
[   55.008442]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
[   55.008455]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[   55.008467]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[   55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000
[   55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
[   55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
[   55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper
gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb
drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight
[   55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G         C         6.6.47+rpt-rpi-v8 #1  Debian 1:6.6.47-1+rpt1
[   55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT)
[   55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   55.008855] pc : __mutex_lock.constprop.0+0x90/0x608
[   55.008879] lr : __mutex_lock.constprop.0+0x58/0x608
[   55.008895] sp : ffffffc080673cf0
[   55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28
[   55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148
[   55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38
[   55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000
[   55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90
[   55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0
[   55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04
[   55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857
[   55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470
[   55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470
[   55.013292] Call trace:
[   55.013959]  __mutex_lock.constprop.0+0x90/0x608
[   55.014646]  __mutex_lock_slowpath+0x1c/0x30
[   55.015317]  mutex_lock+0x50/0x68
[   55.015961]  v3d_perfmon_stop+0x40/0xe0 [v3d]
[   55.016627]  v3d_bin_job_run+0x10c/0x2d8 [v3d]
[   55.017282]  drm_sched_main+0x178/0x3f8 [gpu_sched]
[   55.017921]  kthread+0x11c/0x128
[   55.018554]  ret_from_fork+0x10/0x20
[   55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401)
[   55.019776] ---[ end trace 0000000000000000 ]---
[   55.020411] note: v3d_bin[166] exited with preempt_count 1

This issue arises because, upon closing the file descriptor (which happens
when we interrupt `kmscube`), the active performance monitor is not
stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`,
the active performance monitor's pointer (`v3d-&gt;active_perfmon`) is still
retained.

If `kmscube` is run again, the driver will attempt to stop the active
performance monitor using the stale pointer in `v3d-&gt;active_perfmon`.
However, this pointer is no longer valid because the previous process has
already terminated, and all performance monitors associated with it have
been destroyed and freed.

To fix this, when the active performance monitor belongs to a given
process, explicitly stop it before destroying and freeing it.</Note>
    </Notes>
    <CVE>CVE-2024-50031</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

slip: make slhc_remember() more robust against malicious packets

syzbot found that slhc_remember() was missing checks against
malicious packets [1].

slhc_remember() only checked the size of the packet was at least 20,
which is not good enough.

We need to make sure the packet includes the IPv4 and TCP header
that are supposed to be carried.

Add iph and th pointers to make the code more readable.

[1]

BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666
  slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666
  ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455
  ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline]
  ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212
  ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327
  pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379
  sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113
  __release_sock+0x1da/0x330 net/core/sock.c:3072
  release_sock+0x6b/0x250 net/core/sock.c:3626
  pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903
  sock_sendmsg_nosec net/socket.c:729 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:744
  ____sys_sendmsg+0x903/0xb60 net/socket.c:2602
  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
  __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
  __do_sys_sendmmsg net/socket.c:2771 [inline]
  __se_sys_sendmmsg net/socket.c:2768 [inline]
  __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768
  x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308
  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:1322 [inline]
  sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732
  pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867
  sock_sendmsg_nosec net/socket.c:729 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:744
  ____sys_sendmsg+0x903/0xb60 net/socket.c:2602
  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
  __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
  __do_sys_sendmmsg net/socket.c:2771 [inline]
  __se_sys_sendmmsg net/socket.c:2768 [inline]
  __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768
  x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308
  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

CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024</Note>
    </Notes>
    <CVE>CVE-2024-50033</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ppp: fix ppp_async_encode() illegal access

syzbot reported an issue in ppp_async_encode() [1]

In this case, pppoe_sendmsg() is called with a zero size.
Then ppp_async_encode() is called with an empty skb.

BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]
 BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675
  ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]
  ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675
  ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634
  ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline]
  ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304
  pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379
  sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113
  __release_sock+0x1da/0x330 net/core/sock.c:3072
  release_sock+0x6b/0x250 net/core/sock.c:3626
  pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903
  sock_sendmsg_nosec net/socket.c:729 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:744
  ____sys_sendmsg+0x903/0xb60 net/socket.c:2602
  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
  __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
  __do_sys_sendmmsg net/socket.c:2771 [inline]
  __se_sys_sendmmsg net/socket.c:2768 [inline]
  __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768
  x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308
  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:4092 [inline]
  slab_alloc_node mm/slub.c:4135 [inline]
  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187
  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587
  __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678
  alloc_skb include/linux/skbuff.h:1322 [inline]
  sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732
  pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867
  sock_sendmsg_nosec net/socket.c:729 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:744
  ____sys_sendmsg+0x903/0xb60 net/socket.c:2602
  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
  __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
  __do_sys_sendmmsg net/socket.c:2771 [inline]
  __se_sys_sendmmsg net/socket.c:2768 [inline]
  __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768
  x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308
  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

CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024</Note>
    </Notes>
    <CVE>CVE-2024-50035</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/sched: accept TCA_STAB only for root qdisc

Most qdiscs maintain their backlog using qdisc_pkt_len(skb)
on the assumption it is invariant between the enqueue()
and dequeue() handlers.

Unfortunately syzbot can crash a host rather easily using
a TBF + SFQ combination, with an STAB on SFQ [1]

We can't support TCA_STAB on arbitrary level, this would
require to maintain per-qdisc storage.

[1]
[   88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000
[   88.798611] #PF: supervisor read access in kernel mode
[   88.799014] #PF: error_code(0x0000) - not-present page
[   88.799506] PGD 0 P4D 0
[   88.799829] Oops: Oops: 0000 [#1] SMP NOPTI
[   88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117
[   88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[   88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq
[ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a &lt;4c&gt; 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00
All code
========
   0:	0f b7 50 12          	movzwl 0x12(%rax),%edx
   4:	48 8d 04 d5 00 00 00 	lea    0x0(,%rdx,8),%rax
   b:	00
   c:	48 89 d6             	mov    %rdx,%rsi
   f:	48 29 d0             	sub    %rdx,%rax
  12:	48 8b 91 c0 01 00 00 	mov    0x1c0(%rcx),%rdx
  19:	48 c1 e0 03          	shl    $0x3,%rax
  1d:	48 01 c2             	add    %rax,%rdx
  20:	66 83 7a 1a 00       	cmpw   $0x0,0x1a(%rdx)
  25:	7e c0                	jle    0xffffffffffffffe7
  27:	48 8b 3a             	mov    (%rdx),%rdi
  2a:*	4c 8b 07             	mov    (%rdi),%r8		&lt;-- trapping instruction
  2d:	4c 89 02             	mov    %r8,(%rdx)
  30:	49 89 50 08          	mov    %rdx,0x8(%r8)
  34:	48 c7 47 08 00 00 00 	movq   $0x0,0x8(%rdi)
  3b:	00
  3c:	48                   	rex.W
  3d:	c7                   	.byte 0xc7
  3e:	07                   	(bad)
	...

Code starting with the faulting instruction
===========================================
   0:	4c 8b 07             	mov    (%rdi),%r8
   3:	4c 89 02             	mov    %r8,(%rdx)
   6:	49 89 50 08          	mov    %rdx,0x8(%r8)
   a:	48 c7 47 08 00 00 00 	movq   $0x0,0x8(%rdi)
  11:	00
  12:	48                   	rex.W
  13:	c7                   	.byte 0xc7
  14:	07                   	(bad)
	...
[   88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206
[   88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800
[   88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000
[   88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f
[   88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140
[   88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac
[   88.806734] FS:  00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000
[   88.807225] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0
[   88.808165] Call Trace:
[   88.808459]  &lt;TASK&gt;
[   88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434)
[   88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715)
[   88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539)
[   88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)
[   88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq
[   88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq
[   88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-50039</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

igb: Do not bring the device up after non-fatal error

Commit 004d25060c78 ("igb: Fix igb_down hung on surprise removal")
changed igb_io_error_detected() to ignore non-fatal pcie errors in order
to avoid hung task that can happen when igb_down() is called multiple
times. This caused an issue when processing transient non-fatal errors.
igb_io_resume(), which is called after igb_io_error_detected(), assumes
that device is brought down by igb_io_error_detected() if the interface
is up. This resulted in panic with stacktrace below.

[ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down
[  T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0
[  T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID)
[  T292] igb 0000:09:00.0:   device [8086:1537] error status/mask=00004000/00000000
[  T292] igb 0000:09:00.0:    [14] CmpltTO [  200.105524,009][  T292] igb 0000:09:00.0: AER:   TLP Header: 00000000 00000000 00000000 00000000
[  T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message
[  T292] igb 0000:09:00.0: Non-correctable non-fatal error reported.
[  T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message
[  T292] pcieport 0000:00:1c.5: AER: broadcast resume message
[  T292] ------------[ cut here ]------------
[  T292] kernel BUG at net/core/dev.c:6539!
[  T292] invalid opcode: 0000 [#1] PREEMPT SMP
[  T292] RIP: 0010:napi_enable+0x37/0x40
[  T292] Call Trace:
[  T292]  &lt;TASK&gt;
[  T292]  ? die+0x33/0x90
[  T292]  ? do_trap+0xdc/0x110
[  T292]  ? napi_enable+0x37/0x40
[  T292]  ? do_error_trap+0x70/0xb0
[  T292]  ? napi_enable+0x37/0x40
[  T292]  ? napi_enable+0x37/0x40
[  T292]  ? exc_invalid_op+0x4e/0x70
[  T292]  ? napi_enable+0x37/0x40
[  T292]  ? asm_exc_invalid_op+0x16/0x20
[  T292]  ? napi_enable+0x37/0x40
[  T292]  igb_up+0x41/0x150
[  T292]  igb_io_resume+0x25/0x70
[  T292]  report_resume+0x54/0x70
[  T292]  ? report_frozen_detected+0x20/0x20
[  T292]  pci_walk_bus+0x6c/0x90
[  T292]  ? aer_print_port_info+0xa0/0xa0
[  T292]  pcie_do_recovery+0x22f/0x380
[  T292]  aer_process_err_devices+0x110/0x160
[  T292]  aer_isr+0x1c1/0x1e0
[  T292]  ? disable_irq_nosync+0x10/0x10
[  T292]  irq_thread_fn+0x1a/0x60
[  T292]  irq_thread+0xe3/0x1a0
[  T292]  ? irq_set_affinity_notifier+0x120/0x120
[  T292]  ? irq_affinity_notify+0x100/0x100
[  T292]  kthread+0xe2/0x110
[  T292]  ? kthread_complete_and_exit+0x20/0x20
[  T292]  ret_from_fork+0x2d/0x50
[  T292]  ? kthread_complete_and_exit+0x20/0x20
[  T292]  ret_from_fork_asm+0x11/0x20
[  T292]  &lt;/TASK&gt;

To fix this issue igb_io_resume() checks if the interface is running and
the device is not down this means igb_io_error_detected() did not bring
the device down and there is no need to bring it up.</Note>
    </Notes>
    <CVE>CVE-2024-50040</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i40e: Fix macvlan leak by synchronizing access to mac_filter_hash

This patch addresses a macvlan leak issue in the i40e driver caused by
concurrent access to vsi-&gt;mac_filter_hash. The leak occurs when multiple
threads attempt to modify the mac_filter_hash simultaneously, leading to
inconsistent state and potential memory leaks.

To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing
vf-&gt;default_lan_addr.addr with spin_lock/unlock_bh(&amp;vsi-&gt;mac_filter_hash_lock),
ensuring atomic operations and preventing concurrent access.

Additionally, we add lockdep_assert_held(&amp;vsi-&gt;mac_filter_hash_lock) in
i40e_add_mac_filter() to help catch similar issues in the future.

Reproduction steps:
1. Spawn VFs and configure port vlan on them.
2. Trigger concurrent macvlan operations (e.g., adding and deleting
	portvlan and/or mac filters).
3. Observe the potential memory leak and inconsistent state in the
	mac_filter_hash.

This synchronization ensures the integrity of the mac_filter_hash and prevents
the described leak.</Note>
    </Notes>
    <CVE>CVE-2024-50041</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ice: Fix increasing MSI-X on VF

Increasing MSI-X value on a VF leads to invalid memory operations. This
is caused by not reallocating some arrays.

Reproducer:
  modprobe ice
  echo 0 &gt; /sys/bus/pci/devices/$PF_PCI/sriov_drivers_autoprobe
  echo 1 &gt; /sys/bus/pci/devices/$PF_PCI/sriov_numvfs
  echo 17 &gt; /sys/bus/pci/devices/$VF0_PCI/sriov_vf_msix_count

Default MSI-X is 16, so 17 and above triggers this issue.

KASAN reports:

  BUG: KASAN: slab-out-of-bounds in ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice]
  Read of size 8 at addr ffff8888b937d180 by task bash/28433
  (...)

  Call Trace:
   (...)
   ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice]
   kasan_report+0xed/0x120
   ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice]
   ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice]
   ice_vsi_cfg_def+0x3360/0x4770 [ice]
   ? mutex_unlock+0x83/0xd0
   ? __pfx_ice_vsi_cfg_def+0x10/0x10 [ice]
   ? __pfx_ice_remove_vsi_lkup_fltr+0x10/0x10 [ice]
   ice_vsi_cfg+0x7f/0x3b0 [ice]
   ice_vf_reconfig_vsi+0x114/0x210 [ice]
   ice_sriov_set_msix_vec_count+0x3d0/0x960 [ice]
   sriov_vf_msix_count_store+0x21c/0x300
   (...)

  Allocated by task 28201:
   (...)
   ice_vsi_cfg_def+0x1c8e/0x4770 [ice]
   ice_vsi_cfg+0x7f/0x3b0 [ice]
   ice_vsi_setup+0x179/0xa30 [ice]
   ice_sriov_configure+0xcaa/0x1520 [ice]
   sriov_numvfs_store+0x212/0x390
   (...)

To fix it, use ice_vsi_rebuild() instead of ice_vf_reconfig_vsi(). This
causes the required arrays to be reallocated taking the new queue count
into account (ice_vsi_realloc_stat_arrays()). Set req_txq and req_rxq
before ice_vsi_rebuild(), so that realloc uses the newly set queue
count.

Additionally, ice_vsi_rebuild() does not remove VSI filters
(ice_fltr_remove_all()), so ice_vf_init_host_cfg() is no longer
necessary.</Note>
    </Notes>
    <CVE>CVE-2024-50042</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change

rfcomm_sk_state_change attempts to use sock_lock so it must never be
called with it locked but rfcomm_sock_ioctl always attempt to lock it
causing the following trace:

======================================================
WARNING: possible circular locking dependency detected
6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted
------------------------------------------------------
syz-executor386/5093 is trying to acquire lock:
ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline]
ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73

but task is already holding lock:
ffff88807badfd28 (&amp;d-&gt;lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491</Note>
    </Notes>
    <CVE>CVE-2024-50044</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: br_netfilter: fix panic with metadata_dst skb

Fix a kernel panic in the br_netfilter module when sending untagged
traffic via a VxLAN device.
This happens during the check for fragmentation in br_nf_dev_queue_xmit.

It is dependent on:
1) the br_netfilter module being loaded;
2) net.bridge.bridge-nf-call-iptables set to 1;
3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port;
4) untagged frames with size higher than the VxLAN MTU forwarded/flooded

When forwarding the untagged packet to the VxLAN bridge port, before
the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and
changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type
of dst, i.e., skb_valid_dst(skb) is false, and metadata-&gt;dst.dev is NULL.

Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check
for frames that needs to be fragmented: frames with higher MTU than the
VxLAN device end up calling br_nf_ip_fragment, which in turns call
ip_skb_dst_mtu.

The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst
with valid dst-&gt;dev, thus the crash.

This case was never supported in the first place, so drop the packet
instead.

PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data.
[  176.291791] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000110
[  176.292101] Mem abort info:
[  176.292184]   ESR = 0x0000000096000004
[  176.292322]   EC = 0x25: DABT (current EL), IL = 32 bits
[  176.292530]   SET = 0, FnV = 0
[  176.292709]   EA = 0, S1PTW = 0
[  176.292862]   FSC = 0x04: level 0 translation fault
[  176.293013] Data abort info:
[  176.293104]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[  176.293488]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[  176.293787]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[  176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000
[  176.294166] [0000000000000110] pgd=0000000000000000,
p4d=0000000000000000
[  176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
[  176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth
br_netfilter bridge stp llc ipv6 crct10dif_ce
[  176.295923] CPU: 0 PID: 188 Comm: ping Not tainted
6.8.0-rc3-g5b3fbd61b9d1 #2
[  176.296314] Hardware name: linux,dummy-virt (DT)
[  176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS
BTYPE=--)
[  176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter]
[  176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter]
[  176.297636] sp : ffff800080003630
[  176.297743] x29: ffff800080003630 x28: 0000000000000008 x27:
ffff6828c49ad9f8
[  176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24:
00000000000003e8
[  176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21:
ffff6828c3b16d28
[  176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18:
0000000000000014
[  176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15:
0000000095744632
[  176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12:
ffffb7e137926a70
[  176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 :
0000000000000000
[  176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 :
f20e0100bebafeca
[  176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 :
0000000000000000
[  176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 :
ffff6828c7f918f0
[  176.300889] Call trace:
[  176.301123]  br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter]
[  176.301411]  br_nf_post_routing+0x2a8/0x3e4 [br_netfilter]
[  176.301703]  nf_hook_slow+0x48/0x124
[  176.302060]  br_forward_finish+0xc8/0xe8 [bridge]
[  176.302371]  br_nf_hook_thresh+0x124/0x134 [br_netfilter]
[  176.302605]  br_nf_forward_finish+0x118/0x22c [br_netfilter]
[  176.302824]  br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter]
[  176.303136]  br_nf_forward+0x2b8/0x4e0 [br_netfilter]
[  176.303359]  nf_hook_slow+0x48/0x124
[  176.303
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-50045</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()

On the node of an NFS client, some files saved in the mountpoint of the
NFS server were copied to another location of the same NFS server.
Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference
crash with the following syslog:

[232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116
[232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116
[232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058
[232066.588586] Mem abort info:
[232066.588701]   ESR = 0x0000000096000007
[232066.588862]   EC = 0x25: DABT (current EL), IL = 32 bits
[232066.589084]   SET = 0, FnV = 0
[232066.589216]   EA = 0, S1PTW = 0
[232066.589340]   FSC = 0x07: level 3 translation fault
[232066.589559] Data abort info:
[232066.589683]   ISV = 0, ISS = 0x00000007
[232066.589842]   CM = 0, WnR = 0
[232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400
[232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000
[232066.590757] Internal error: Oops: 96000007 [#1] SMP
[232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2
[232066.591052]  vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs
[232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1
[232066.597356] Hardware name: Great Wall .\x93\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06
[232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4]
[232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4]
[232066.598595] sp : ffff8000f568fc70
[232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000
[232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001
[232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050
[232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000
[232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000
[232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6
[232066.600498] x11: 00000000000000
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-50046</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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]  &lt;TASK&gt;
    [  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.</Note>
    </Notes>
    <CVE>CVE-2024-50047</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fbcon: Fix a NULL pointer dereference issue in fbcon_putcs

syzbot has found a NULL pointer dereference bug in fbcon.
Here is the simplified C reproducer:

struct param {
	uint8_t type;
	struct tiocl_selection ts;
};

int main()
{
	struct fb_con2fbmap con2fb;
	struct param param;

	int fd = open("/dev/fb1", 0, 0);

	con2fb.console = 0x19;
	con2fb.framebuffer = 0;
	ioctl(fd, FBIOPUT_CON2FBMAP, &amp;con2fb);

	param.type = 2;
	param.ts.xs = 0; param.ts.ys = 0;
	param.ts.xe = 0; param.ts.ye = 0;
	param.ts.sel_mode = 0;

	int fd1 = open("/dev/tty1", O_RDWR, 0);
	ioctl(fd1, TIOCLINUX, &amp;param);

	con2fb.console = 1;
	con2fb.framebuffer = 0;
	ioctl(fd, FBIOPUT_CON2FBMAP, &amp;con2fb);

	return 0;
}

After calling ioctl(fd1, TIOCLINUX, &amp;param), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, &amp;con2fb)
causes the kernel to follow a different execution path:

 set_con2fb_map
  -&gt; con2fb_init_display
   -&gt; fbcon_set_disp
    -&gt; redraw_screen
     -&gt; hide_cursor
      -&gt; clear_selection
       -&gt; highlight
        -&gt; invert_screen
         -&gt; do_update_region
          -&gt; fbcon_putcs
           -&gt; ops-&gt;putcs

Since ops-&gt;putcs is a NULL pointer, this leads to a kernel panic.
To prevent this, we need to call set_blitting_type() within set_con2fb_map()
to properly initialize ops-&gt;putcs.</Note>
    </Notes>
    <CVE>CVE-2024-50048</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check null pointer before dereferencing se

[WHAT &amp; HOW]
se is null checked previously in the same function, indicating
it might be null; therefore, it must be checked when used again.

This fixes 1 FORWARD_NULL issue reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-50049</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

driver core: bus: Fix double free in driver API bus_register()

For bus_register(), any error which happens after kset_register() will
cause that @priv are freed twice, fixed by setting @priv with NULL after
the first free.</Note>
    </Notes>
    <CVE>CVE-2024-50055</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

serial: protect uart_port_dtr_rts() in uart_shutdown() too

Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part
3) added few uport == NULL checks. It added one to uart_shutdown(), so
the commit assumes, uport can be NULL in there. But right after that
protection, there is an unprotected "uart_port_dtr_rts(uport, false);"
call. That is invoked only if HUPCL is set, so I assume that is the
reason why we do not see lots of these reports.

Or it cannot be NULL at this point at all for some reason :P.

Until the above is investigated, stay on the safe side and move this
dereference to the if too.

I got this inconsistency from Coverity under CID 1585130. Thanks.</Note>
    </Notes>
    <CVE>CVE-2024-50058</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition

In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev
function, then &amp;sndev-&gt;check_link_status_work is bound with
check_link_status_work. switchtec_ntb_link_notification may be called
to start the work.

If we remove the module which will call switchtec_ntb_remove to make
cleanup, it will free sndev through kfree(sndev), while the work
mentioned above will be used. The sequence of operations that may lead
to a UAF bug is as follows:

CPU0                                 CPU1

                        | check_link_status_work
switchtec_ntb_remove    |
kfree(sndev);           |
                        | if (sndev-&gt;link_force_down)
                        | // use sndev

Fix it by ensuring that the work is canceled before proceeding with
the cleanup in switchtec_ntb_remove.</Note>
    </Notes>
    <CVE>CVE-2024-50059</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

io_uring: check if we need to reschedule during overflow flush

In terms of normal application usage, this list will always be empty.
And if an application does overflow a bit, it'll have a few entries.
However, nothing obviously prevents syzbot from running a test case
that generates a ton of overflow entries, and then flushing them can
take quite a while.

Check for needing to reschedule while flushing, and drop our locks and
do so if necessary. There's no state to maintain here as overflows
always prune from head-of-list, hence it's fine to drop and reacquire
the locks at the end of the loop.</Note>
    </Notes>
    <CVE>CVE-2024-50060</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition

In the cdns_i3c_master_probe function, &amp;master-&gt;hj_work is bound with
cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call
cnds_i3c_master_demux_ibis function to start the work.

If we remove the module which will call cdns_i3c_master_remove to
make cleanup, it will free master-&gt;base through i3c_master_unregister
while the work mentioned above will be used. The sequence of operations
that may lead to a UAF bug is as follows:

CPU0                                      CPU1

                                     | cdns_i3c_master_hj
cdns_i3c_master_remove               |
i3c_master_unregister(&amp;master-&gt;base) |
device_unregister(&amp;master-&gt;dev)      |
device_release                       |
//free master-&gt;base                  |
                                     | i3c_master_do_daa(&amp;master-&gt;base)
                                     | //use master-&gt;base

Fix it by ensuring that the work is canceled before proceeding with
the cleanup in cdns_i3c_master_remove.</Note>
    </Notes>
    <CVE>CVE-2024-50061</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/rtrs-srv: Avoid null pointer deref during path establishment

For RTRS path establishment, RTRS client initiates and completes con_num
of connections. After establishing all its connections, the information
is exchanged between the client and server through the info_req message.
During this exchange, it is essential that all connections have been
established, and the state of the RTRS srv path is CONNECTED.

So add these sanity checks, to make sure we detect and abort process in
error scenarios to avoid null pointer deref.</Note>
    </Notes>
    <CVE>CVE-2024-50062</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Prevent tail call between progs attached to different hooks

bpf progs can be attached to kernel functions, and the attached functions
can take different parameters or return different return values. If
prog attached to one kernel function tail calls prog attached to another
kernel function, the ctx access or return value verification could be
bypassed.

For example, if prog1 is attached to func1 which takes only 1 parameter
and prog2 is attached to func2 which takes two parameters. Since verifier
assumes the bpf ctx passed to prog2 is constructed based on func2's
prototype, verifier allows prog2 to access the second parameter from
the bpf ctx passed to it. The problem is that verifier does not prevent
prog1 from passing its bpf ctx to prog2 via tail call. In this case,
the bpf ctx passed to prog2 is constructed from func1 instead of func2,
that is, the assumption for ctx access verification is bypassed.

Another example, if BPF LSM prog1 is attached to hook file_alloc_security,
and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier
knows the return value rules for these two hooks, e.g. it is legal for
bpf_lsm_audit_rule_known to return positive number 1, and it is illegal
for file_alloc_security to return positive number. So verifier allows
prog2 to return positive number 1, but does not allow prog1 to return
positive number. The problem is that verifier does not prevent prog1
from calling prog2 via tail call. In this case, prog2's return value 1
will be used as the return value for prog1's hook file_alloc_security.
That is, the return value rule is bypassed.

This patch adds restriction for tail call to prevent such bypasses.</Note>
    </Notes>
    <CVE>CVE-2024-50063</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

zram: free secondary algorithms names

We need to kfree() secondary algorithms names when reset zram device that
had multi-streams, otherwise we leak memory.

[senozhatsky@chromium.org: kfree(NULL) is legal]</Note>
    </Notes>
    <CVE>CVE-2024-50064</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

uprobe: avoid out-of-bounds memory access of fetching args

Uprobe needs to fetch args into a percpu buffer, and then copy to ring
buffer to avoid non-atomic context problem.

Sometimes user-space strings, arrays can be very large, but the size of
percpu buffer is only page size. And store_trace_args() won't check
whether these data exceeds a single page or not, caused out-of-bounds
memory access.

It could be reproduced by following steps:
1. build kernel with CONFIG_KASAN enabled
2. save follow program as test.c

```
\#include &lt;stdio.h&gt;
\#include &lt;stdlib.h&gt;
\#include &lt;string.h&gt;

// If string length large than MAX_STRING_SIZE, the fetch_store_strlen()
// will return 0, cause __get_data_size() return shorter size, and
// store_trace_args() will not trigger out-of-bounds access.
// So make string length less than 4096.
\#define STRLEN 4093

void generate_string(char *str, int n)
{
    int i;
    for (i = 0; i &lt; n; ++i)
    {
        char c = i % 26 + 'a';
        str[i] = c;
    }
    str[n-1] = '\0';
}

void print_string(char *str)
{
    printf("%s\n", str);
}

int main()
{
    char tmp[STRLEN];

    generate_string(tmp, STRLEN);
    print_string(tmp);

    return 0;
}
```
3. compile program
`gcc -o test test.c`

4. get the offset of `print_string()`
```
objdump -t test | grep -w print_string
0000000000401199 g     F .text  000000000000001b              print_string
```

5. configure uprobe with offset 0x1199
```
off=0x1199

cd /sys/kernel/debug/tracing/
echo "p /root/test:${off} arg1=+0(%di):ustring arg2=\$comm arg3=+0(%di):ustring"
 &gt; uprobe_events
echo 1 &gt; events/uprobes/enable
echo 1 &gt; tracing_on
```

6. run `test`, and kasan will report error.
==================================================================
BUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0
Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18
Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x55/0x70
 print_address_description.constprop.0+0x27/0x310
 kasan_report+0x10f/0x120
 ? strncpy_from_user+0x1d6/0x1f0
 strncpy_from_user+0x1d6/0x1f0
 ? rmqueue.constprop.0+0x70d/0x2ad0
 process_fetch_insn+0xb26/0x1470
 ? __pfx_process_fetch_insn+0x10/0x10
 ? _raw_spin_lock+0x85/0xe0
 ? __pfx__raw_spin_lock+0x10/0x10
 ? __pte_offset_map+0x1f/0x2d0
 ? unwind_next_frame+0xc5f/0x1f80
 ? arch_stack_walk+0x68/0xf0
 ? is_bpf_text_address+0x23/0x30
 ? kernel_text_address.part.0+0xbb/0xd0
 ? __kernel_text_address+0x66/0xb0
 ? unwind_get_return_address+0x5e/0xa0
 ? __pfx_stack_trace_consume_entry+0x10/0x10
 ? arch_stack_walk+0xa2/0xf0
 ? _raw_spin_lock_irqsave+0x8b/0xf0
 ? __pfx__raw_spin_lock_irqsave+0x10/0x10
 ? depot_alloc_stack+0x4c/0x1f0
 ? _raw_spin_unlock_irqrestore+0xe/0x30
 ? stack_depot_save_flags+0x35d/0x4f0
 ? kasan_save_stack+0x34/0x50
 ? kasan_save_stack+0x24/0x50
 ? mutex_lock+0x91/0xe0
 ? __pfx_mutex_lock+0x10/0x10
 prepare_uprobe_buffer.part.0+0x2cd/0x500
 uprobe_dispatcher+0x2c3/0x6a0
 ? __pfx_uprobe_dispatcher+0x10/0x10
 ? __kasan_slab_alloc+0x4d/0x90
 handler_chain+0xdd/0x3e0
 handle_swbp+0x26e/0x3d0
 ? __pfx_handle_swbp+0x10/0x10
 ? uprobe_pre_sstep_notifier+0x151/0x1b0
 irqentry_exit_to_user_mode+0xe2/0x1b0
 asm_exc_int3+0x39/0x40
RIP: 0033:0x401199
Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce
RSP: 002b:00007ffdf00576a8 EFLAGS: 00000206
RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2
RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0
RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20
R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040
R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000
 &lt;/TASK&gt;

This commit enforces the buffer's maxlen less than a page-size to avoid
store_trace_args() out-of-memory access.</Note>
    </Notes>
    <CVE>CVE-2024-50067</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pinctrl: apple: check devm_kasprintf() returned value

devm_kasprintf() can return a NULL pointer on failure but this returned
value is not checked. Fix this lack and check the returned value.

Found by code review.</Note>
    </Notes>
    <CVE>CVE-2024-50069</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tty: n_gsm: Fix use-after-free in gsm_cleanup_mux

BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0
drivers/tty/n_gsm.c:3160 [n_gsm]
Read of size 8 at addr ffff88815fe99c00 by task poc/3379
CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56
Hardware name: VMware, Inc. VMware Virtual Platform/440BX
Desktop Reference Platform, BIOS 6.00 11/12/2020
Call Trace:
 &lt;TASK&gt;
 gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm]
 __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm]
 __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389
 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500
 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846
 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161
 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm]
 _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107
 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm]
 ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195
 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79
 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338
 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805
 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818

Allocated by task 65:
 gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm]
 gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm]
 gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm]
 gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm]
 tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391
 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39
 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445
 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229
 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391
 kthread+0x2a3/0x370 kernel/kthread.c:389
 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257

Freed by task 3367:
 kfree+0x126/0x420 mm/slub.c:4580
 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm]
 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm]
 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818

[Analysis]
gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux
can be freed by multi threads through ioctl,which leads
to the occurrence of uaf. Protect it by gsm tx lock.</Note>
    </Notes>
    <CVE>CVE-2024-50073</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

parport: Proper fix for array out-of-bounds access

The recent fix for array out-of-bounds accesses replaced sprintf()
calls blindly with snprintf().  However, since snprintf() returns the
would-be-printed size, not the actually output size, the length
calculation can still go over the given limit.

Use scnprintf() instead of snprintf(), which returns the actually
output letters, for addressing the potential out-of-bounds access
properly.</Note>
    </Notes>
    <CVE>CVE-2024-50074</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xhci: tegra: fix checked USB2 port number

If USB virtualizatoin is enabled, USB2 ports are shared between all
Virtual Functions. The USB2 port number owned by an USB2 root hub in
a Virtual Function may be less than total USB2 phy number supported
by the Tegra XUSB controller.

Using total USB2 phy number as port number to check all PORTSC values
would cause invalid memory access.

[  116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f
...
[  117.213640] Call trace:
[  117.216783]  tegra_xusb_enter_elpg+0x23c/0x658
[  117.222021]  tegra_xusb_runtime_suspend+0x40/0x68
[  117.227260]  pm_generic_runtime_suspend+0x30/0x50
[  117.232847]  __rpm_callback+0x84/0x3c0
[  117.237038]  rpm_suspend+0x2dc/0x740
[  117.241229] pm_runtime_work+0xa0/0xb8
[  117.245769]  process_scheduled_works+0x24c/0x478
[  117.251007]  worker_thread+0x23c/0x328
[  117.255547]  kthread+0x104/0x1b0
[  117.259389]  ret_from_fork+0x10/0x20
[  117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100)</Note>
    </Notes>
    <CVE>CVE-2024-50075</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vt: prevent kernel-infoleak in con_font_get()

font.data may not initialize all memory spaces depending on the implementation
of vc-&gt;vc_sw-&gt;con_font_get. This may cause info-leak, so to prevent this, it
is safest to modify it to initialize the allocated memory space to 0, and it
generally does not affect the overall performance of the system.</Note>
    </Notes>
    <CVE>CVE-2024-50076</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: ISO: Fix multiple init when debugfs is disabled

If bt_debugfs is not created successfully, which happens if either
CONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init()
returns early and does not set iso_inited to true. This means that a
subsequent call to iso_init() will result in duplicate calls to
proto_register(), bt_sock_register(), etc.

With CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the
duplicate call to proto_register() triggers this BUG():

  list_add double add: new=ffffffffc0b280d0, prev=ffffffffbab56250,
    next=ffffffffc0b280d0.
  ------------[ cut here ]------------
  kernel BUG at lib/list_debug.c:35!
  Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI
  CPU: 2 PID: 887 Comm: bluetoothd Not tainted 6.10.11-1-ao-desktop #1
  RIP: 0010:__list_add_valid_or_report+0x9a/0xa0
  ...
    __list_add_valid_or_report+0x9a/0xa0
    proto_register+0x2b5/0x340
    iso_init+0x23/0x150 [bluetooth]
    set_iso_socket_func+0x68/0x1b0 [bluetooth]
    kmem_cache_free+0x308/0x330
    hci_sock_sendmsg+0x990/0x9e0 [bluetooth]
    __sock_sendmsg+0x7b/0x80
    sock_write_iter+0x9a/0x110
    do_iter_readv_writev+0x11d/0x220
    vfs_writev+0x180/0x3e0
    do_writev+0xca/0x100
  ...

This change removes the early return. The check for iso_debugfs being
NULL was unnecessary, it is always NULL when iso_inited is false.</Note>
    </Notes>
    <CVE>CVE-2024-50077</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: Call iso_exit() on module unload

If iso_init() has been called, iso_exit() must be called on module
unload. Without that, the struct proto that iso_init() registered with
proto_register() becomes invalid, which could cause unpredictable
problems later. In my case, with CONFIG_LIST_HARDENED and
CONFIG_BUG_ON_DATA_CORRUPTION enabled, loading the module again usually
triggers this BUG():

  list_add corruption. next-&gt;prev should be prev (ffffffffb5355fd0),
    but was 0000000000000068. (next=ffffffffc0a010d0).
  ------------[ cut here ]------------
  kernel BUG at lib/list_debug.c:29!
  Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI
  CPU: 1 PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1
  RIP: 0010:__list_add_valid_or_report+0x61/0xa0
  ...
    __list_add_valid_or_report+0x61/0xa0
    proto_register+0x299/0x320
    hci_sock_init+0x16/0xc0 [bluetooth]
    bt_init+0x68/0xd0 [bluetooth]
    __pfx_bt_init+0x10/0x10 [bluetooth]
    do_one_initcall+0x80/0x2f0
    do_init_module+0x8b/0x230
    __do_sys_init_module+0x15f/0x190
    do_syscall_64+0x68/0x110
  ...</Note>
    </Notes>
    <CVE>CVE-2024-50078</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ublk: don't allow user copy for unprivileged device

UBLK_F_USER_COPY requires userspace to call write() on ublk char
device for filling request buffer, and unprivileged device can't
be trusted.

So don't allow user copy for unprivileged device.</Note>
    </Notes>
    <CVE>CVE-2024-50080</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

blk-mq: setup queue -&gt;tag_set before initializing hctx

Commit 7b815817aa58 ("blk-mq: add helper for checking if one CPU is mapped to specified hctx")
needs to check queue mapping via tag set in hctx's cpuhp handler.

However, q-&gt;tag_set may not be setup yet when the cpuhp handler is
enabled, then kernel oops is triggered.

Fix the issue by setup queue tag_set before initializing hctx.</Note>
    </Notes>
    <CVE>CVE-2024-50081</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race

We're seeing crashes from rq_qos_wake_function that look like this:

  BUG: unable to handle page fault for address: ffffafe180a40084
  #PF: supervisor write access in kernel mode
  #PF: error_code(0x0002) - not-present page
  PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0
  Oops: Oops: 0002 [#1] PREEMPT SMP PTI
  CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
  RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40
  Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 &lt;f0&gt; 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00
  RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046
  RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011
  RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084
  RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011
  R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002
  R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003
  FS:  0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  PKRU: 55555554
  Call Trace:
   &lt;IRQ&gt;
   try_to_wake_up+0x5a/0x6a0
   rq_qos_wake_function+0x71/0x80
   __wake_up_common+0x75/0xa0
   __wake_up+0x36/0x60
   scale_up.part.0+0x50/0x110
   wb_timer_fn+0x227/0x450
   ...

So rq_qos_wake_function() calls wake_up_process(data-&gt;task), which calls
try_to_wake_up(), which faults in raw_spin_lock_irqsave(&amp;p-&gt;pi_lock).

p comes from data-&gt;task, and data comes from the waitqueue entry, which
is stored on the waiter's stack in rq_qos_wait(). Analyzing the core
dump with drgn, I found that the waiter had already woken up and moved
on to a completely unrelated code path, clobbering what was previously
data-&gt;task. Meanwhile, the waker was passing the clobbered garbage in
data-&gt;task to wake_up_process(), leading to the crash.

What's happening is that in between rq_qos_wake_function() deleting the
waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding
that it already got a token and returning. The race looks like this:

rq_qos_wait()                           rq_qos_wake_function()
==============================================================
prepare_to_wait_exclusive()
                                        data-&gt;got_token = true;
                                        list_del_init(&amp;curr-&gt;entry);
if (data.got_token)
        break;
finish_wait(&amp;rqw-&gt;wait, &amp;data.wq);
  ^- returns immediately because
     list_empty_careful(&amp;wq_entry-&gt;entry)
     is true
... return, go do something else ...
                                        wake_up_process(data-&gt;task)
                                          (NO LONGER VALID!)-^

Normally, finish_wait() is supposed to synchronize against the waker.
But, as noted above, it is returning immediately because the waitqueue
entry has already been removed from the waitqueue.

The bug is that rq_qos_wake_function() is accessing the waitqueue entry
AFTER deleting it. Note that autoremove_wake_function() wakes the waiter
and THEN deletes the waitqueue entry, which is the proper order.

Fix it by swapping the order. We also need to use
list_del_init_careful() to match the list_empty_careful() in
finish_wait().</Note>
    </Notes>
    <CVE>CVE-2024-50082</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test()

Commit a3c1e45156ad ("net: microchip: vcap: Fix use-after-free error in
kunit test") fixed the use-after-free error, but introduced below
memory leaks by removing necessary vcap_free_rule(), add it to fix it.

	unreferenced object 0xffffff80ca58b700 (size 192):
	  comm "kunit_try_catch", pid 1215, jiffies 4294898264
	  hex dump (first 32 bytes):
	    00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00  ..z.........d...
	    00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff  ................
	  backtrace (crc 9c09c3fe):
	    [&lt;0000000052a0be73&gt;] kmemleak_alloc+0x34/0x40
	    [&lt;0000000043605459&gt;] __kmalloc_cache_noprof+0x26c/0x2f4
	    [&lt;0000000040a01b8d&gt;] vcap_alloc_rule+0x3cc/0x9c4
	    [&lt;000000003fe86110&gt;] vcap_api_encode_rule_test+0x1ac/0x16b0
	    [&lt;00000000b3595fc4&gt;] kunit_try_run_case+0x13c/0x3ac
	    [&lt;0000000010f5d2bf&gt;] kunit_generic_run_threadfn_adapter+0x80/0xec
	    [&lt;00000000c5d82c9a&gt;] kthread+0x2e8/0x374
	    [&lt;00000000f4287308&gt;] ret_from_fork+0x10/0x20
	unreferenced object 0xffffff80cc0b0400 (size 64):
	  comm "kunit_try_catch", pid 1215, jiffies 4294898265
	  hex dump (first 32 bytes):
	    80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff  ..........X.....
	    39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff  9...............
	  backtrace (crc daf014e9):
	    [&lt;0000000052a0be73&gt;] kmemleak_alloc+0x34/0x40
	    [&lt;0000000043605459&gt;] __kmalloc_cache_noprof+0x26c/0x2f4
	    [&lt;000000000ff63fd4&gt;] vcap_rule_add_key+0x2cc/0x528
	    [&lt;00000000dfdb1e81&gt;] vcap_api_encode_rule_test+0x224/0x16b0
	    [&lt;00000000b3595fc4&gt;] kunit_try_run_case+0x13c/0x3ac
	    [&lt;0000000010f5d2bf&gt;] kunit_generic_run_threadfn_adapter+0x80/0xec
	    [&lt;00000000c5d82c9a&gt;] kthread+0x2e8/0x374
	    [&lt;00000000f4287308&gt;] ret_from_fork+0x10/0x20
	unreferenced object 0xffffff80cc0b0700 (size 64):
	  comm "kunit_try_catch", pid 1215, jiffies 4294898265
	  hex dump (first 32 bytes):
	    80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff  ........(.X.....
	    3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff  &lt;......../......
	  backtrace (crc 8d877792):
	    [&lt;0000000052a0be73&gt;] kmemleak_alloc+0x34/0x40
	    [&lt;0000000043605459&gt;] __kmalloc_cache_noprof+0x26c/0x2f4
	    [&lt;000000006eadfab7&gt;] vcap_rule_add_action+0x2d0/0x52c
	    [&lt;00000000323475d1&gt;] vcap_api_encode_rule_test+0x4d4/0x16b0
	    [&lt;00000000b3595fc4&gt;] kunit_try_run_case+0x13c/0x3ac
	    [&lt;0000000010f5d2bf&gt;] kunit_generic_run_threadfn_adapter+0x80/0xec
	    [&lt;00000000c5d82c9a&gt;] kthread+0x2e8/0x374
	    [&lt;00000000f4287308&gt;] ret_from_fork+0x10/0x20
	unreferenced object 0xffffff80cc0b0900 (size 64):
	  comm "kunit_try_catch", pid 1215, jiffies 4294898266
	  hex dump (first 32 bytes):
	    80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff  ................
	    7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00  }...............
	  backtrace (crc 34181e56):
	    [&lt;0000000052a0be73&gt;] kmemleak_alloc+0x34/0x40
	    [&lt;0000000043605459&gt;] __kmalloc_cache_noprof+0x26c/0x2f4
	    [&lt;000000000ff63fd4&gt;] vcap_rule_add_key+0x2cc/0x528
	    [&lt;00000000991e3564&gt;] vcap_val_rule+0xcf0/0x13e8
	    [&lt;00000000fc9868e5&gt;] vcap_api_encode_rule_test+0x678/0x16b0
	    [&lt;00000000b3595fc4&gt;] kunit_try_run_case+0x13c/0x3ac
	    [&lt;0000000010f5d2bf&gt;] kunit_generic_run_threadfn_adapter+0x80/0xec
	    [&lt;00000000c5d82c9a&gt;] kthread+0x2e8/0x374
	    [&lt;00000000f4287308&gt;] ret_from_fork+0x10/0x20
	unreferenced object 0xffffff80cc0b0980 (size 64):
	  comm "kunit_try_catch", pid 1215, jiffies 4294898266
	  hex dump (first 32 bytes):
	    18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff  ..X.............
	    67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff  g.........t.....
	  backtrace (crc 275fd9be):
	    [&lt;0000000052a0be73&gt;] kmemleak_alloc+0x34/0x40
	    [&lt;0000000043605459&gt;] __kmalloc_cache_noprof+0x26c/0x2f4
	    [&lt;000000000ff63fd4&gt;] vcap_rule_add_key+0x2cc/0x528
	    [&lt;000000001396a1a2&gt;] test_add_de
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-50084</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix uninitialized pointer free on read_alloc_one_name() error

The function read_alloc_one_name() does not initialize the name field of
the passed fscrypt_str struct if kmalloc fails to allocate the
corresponding buffer.  Thus, it is not guaranteed that
fscrypt_str.name is initialized when freeing it.

This is a follow-up to the linked patch that fixes the remaining
instances of the bug introduced by commit e43eec81c516 ("btrfs: use
struct qstr instead of name and namelen pairs").</Note>
    </Notes>
    <CVE>CVE-2024-50087</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix uninitialized pointer free in add_inode_ref()

The add_inode_ref() function does not initialize the "name" struct when
it is declared.  If any of the following calls to "read_one_inode()
returns NULL,

	dir = read_one_inode(root, parent_objectid);
	if (!dir) {
		ret = -ENOENT;
		goto out;
	}

	inode = read_one_inode(root, inode_objectid);
	if (!inode) {
		ret = -EIO;
		goto out;
	}

then "name.name" would be freed on "out" before being initialized.

out:
	...
	kfree(name.name);

This issue was reported by Coverity with CID 1526744.</Note>
    </Notes>
    <CVE>CVE-2024-50088</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2024-50089</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

thermal: intel: int340x: processor: Fix warning during module unload

The processor_thermal driver uses pcim_device_enable() to enable a PCI
device, which means the device will be automatically disabled on driver
detach.  Thus there is no need to call pci_disable_device() again on it.

With recent PCI device resource management improvements, e.g. commit
f748a07a0b64 ("PCI: Remove legacy pcim_release()"), this problem is
exposed and triggers the warining below.

 [  224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device
 [  224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100
 ...
 [  224.010844] Call Trace:
 [  224.010845]  &lt;TASK&gt;
 [  224.010847]  ? show_regs+0x6d/0x80
 [  224.010851]  ? __warn+0x8c/0x140
 [  224.010854]  ? pci_disable_device+0xe5/0x100
 [  224.010856]  ? report_bug+0x1c9/0x1e0
 [  224.010859]  ? handle_bug+0x46/0x80
 [  224.010862]  ? exc_invalid_op+0x1d/0x80
 [  224.010863]  ? asm_exc_invalid_op+0x1f/0x30
 [  224.010867]  ? pci_disable_device+0xe5/0x100
 [  224.010869]  ? pci_disable_device+0xe5/0x100
 [  224.010871]  ? kfree+0x21a/0x2b0
 [  224.010873]  pcim_disable_device+0x20/0x30
 [  224.010875]  devm_action_release+0x16/0x20
 [  224.010878]  release_nodes+0x47/0xc0
 [  224.010880]  devres_release_all+0x9f/0xe0
 [  224.010883]  device_unbind_cleanup+0x12/0x80
 [  224.010885]  device_release_driver_internal+0x1ca/0x210
 [  224.010887]  driver_detach+0x4e/0xa0
 [  224.010889]  bus_remove_driver+0x6f/0xf0
 [  224.010890]  driver_unregister+0x35/0x60
 [  224.010892]  pci_unregister_driver+0x44/0x90
 [  224.010894]  proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci]
 ...
 [  224.010921] ---[ end trace 0000000000000000 ]---

Remove the excess pci_disable_device() calls.

[ rjw: Subject and changelog edits ]</Note>
    </Notes>
    <CVE>CVE-2024-50093</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/mad: Improve handling of timed out WRs of mad agent

Current timeout handler of mad agent acquires/releases mad_agent_priv
lock for every timed out WRs. This causes heavy locking contention
when higher no. of WRs are to be handled inside timeout handler.

This leads to softlockup with below trace in some use cases where
rdma-cm path is used to establish connection between peer nodes

Trace:
-----
 BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767]
 CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE
     -------  ---  5.14.0-427.13.1.el9_4.x86_64 #1
 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019
 Workqueue: ib_mad1 timeout_sends [ib_core]
 RIP: 0010:__do_softirq+0x78/0x2ac
 RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246
 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f
 RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b
 RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000
 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000
 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040
 FS:  0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 PKRU: 55555554
 Call Trace:
  &lt;IRQ&gt;
  ? show_trace_log_lvl+0x1c4/0x2df
  ? show_trace_log_lvl+0x1c4/0x2df
  ? __irq_exit_rcu+0xa1/0xc0
  ? watchdog_timer_fn+0x1b2/0x210
  ? __pfx_watchdog_timer_fn+0x10/0x10
  ? __hrtimer_run_queues+0x127/0x2c0
  ? hrtimer_interrupt+0xfc/0x210
  ? __sysvec_apic_timer_interrupt+0x5c/0x110
  ? sysvec_apic_timer_interrupt+0x37/0x90
  ? asm_sysvec_apic_timer_interrupt+0x16/0x20
  ? __do_softirq+0x78/0x2ac
  ? __do_softirq+0x60/0x2ac
  __irq_exit_rcu+0xa1/0xc0
  sysvec_call_function_single+0x72/0x90
  &lt;/IRQ&gt;
  &lt;TASK&gt;
  asm_sysvec_call_function_single+0x16/0x20
 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30
 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247
 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800
 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c
 RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000
 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538
 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c
  cm_process_send_error+0x122/0x1d0 [ib_cm]
  timeout_sends+0x1dd/0x270 [ib_core]
  process_one_work+0x1e2/0x3b0
  ? __pfx_worker_thread+0x10/0x10
  worker_thread+0x50/0x3a0
  ? __pfx_worker_thread+0x10/0x10
  kthread+0xdd/0x100
  ? __pfx_kthread+0x10/0x10
  ret_from_fork+0x29/0x50
  &lt;/TASK&gt;

Simplified timeout handler by creating local list of timed out WRs
and invoke send handler post creating the list. The new method acquires/
releases lock once to fetch the list and hence helps to reduce locking
contetiong when processing higher no. of WRs</Note>
    </Notes>
    <CVE>CVE-2024-50095</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error

The `nouveau_dmem_copy_one` function ensures that the copy push command is
sent to the device firmware but does not track whether it was executed
successfully.

In the case of a copy error (e.g., firmware or hardware failure), the
copy push command will be sent via the firmware channel, and
`nouveau_dmem_copy_one` will likely report success, leading to the
`migrate_to_ram` function returning a dirty HIGH_USER page to the user.

This can result in a security vulnerability, as a HIGH_USER page that may
contain sensitive or corrupted data could be returned to the user.

To prevent this vulnerability, we allocate a zero page. Thus, in case of
an error, a non-dirty (zero) page will be returned to the user.</Note>
    </Notes>
    <CVE>CVE-2024-50096</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down

There is a history of deadlock if reboot is performed at the beginning
of booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFS
shutdown, and at that time the audio driver was waiting on
blk_mq_submit_bio() holding a mutex_lock while reading the fw binary.
After that, a deadlock issue occurred while audio driver shutdown was
waiting for mutex_unlock of blk_mq_submit_bio(). To solve this, set
SDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes down
after a UFS shutdown will return an error.

[   31.907781]I[0:      swapper/0:    0]        1        130705007       1651079834      11289729804                0 D(   2) 3 ffffff882e208000 *             init [device_shutdown]
[   31.907793]I[0:      swapper/0:    0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49]
[   31.907806]I[0:      swapper/0:    0] Call trace:
[   31.907810]I[0:      swapper/0:    0]  __switch_to+0x174/0x338
[   31.907819]I[0:      swapper/0:    0]  __schedule+0x5ec/0x9cc
[   31.907826]I[0:      swapper/0:    0]  schedule+0x7c/0xe8
[   31.907834]I[0:      swapper/0:    0]  schedule_preempt_disabled+0x24/0x40
[   31.907842]I[0:      swapper/0:    0]  __mutex_lock+0x408/0xdac
[   31.907849]I[0:      swapper/0:    0]  __mutex_lock_slowpath+0x14/0x24
[   31.907858]I[0:      swapper/0:    0]  mutex_lock+0x40/0xec
[   31.907866]I[0:      swapper/0:    0]  device_shutdown+0x108/0x280
[   31.907875]I[0:      swapper/0:    0]  kernel_restart+0x4c/0x11c
[   31.907883]I[0:      swapper/0:    0]  __arm64_sys_reboot+0x15c/0x280
[   31.907890]I[0:      swapper/0:    0]  invoke_syscall+0x70/0x158
[   31.907899]I[0:      swapper/0:    0]  el0_svc_common+0xb4/0xf4
[   31.907909]I[0:      swapper/0:    0]  do_el0_svc+0x2c/0xb0
[   31.907918]I[0:      swapper/0:    0]  el0_svc+0x34/0xe0
[   31.907928]I[0:      swapper/0:    0]  el0t_64_sync_handler+0x68/0xb4
[   31.907937]I[0:      swapper/0:    0]  el0t_64_sync+0x1a0/0x1a4

[   31.908774]I[0:      swapper/0:    0]       49                0         11960702      11236868007                0 D(   2) 6 ffffff882e28cb00 *      kworker/6:0 [__bio_queue_enter]
[   31.908783]I[0:      swapper/0:    0] Call trace:
[   31.908788]I[0:      swapper/0:    0]  __switch_to+0x174/0x338
[   31.908796]I[0:      swapper/0:    0]  __schedule+0x5ec/0x9cc
[   31.908803]I[0:      swapper/0:    0]  schedule+0x7c/0xe8
[   31.908811]I[0:      swapper/0:    0]  __bio_queue_enter+0xb8/0x178
[   31.908818]I[0:      swapper/0:    0]  blk_mq_submit_bio+0x194/0x67c
[   31.908827]I[0:      swapper/0:    0]  __submit_bio+0xb8/0x19c</Note>
    </Notes>
    <CVE>CVE-2024-50098</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

arm64: probes: Remove broken LDR (literal) uprobe support

The simulate_ldr_literal() and simulate_ldrsw_literal() functions are
unsafe to use for uprobes. Both functions were originally written for
use with kprobes, and access memory with plain C accesses. When uprobes
was added, these were reused unmodified even though they cannot safely
access user memory.

There are three key problems:

1) The plain C accesses do not have corresponding extable entries, and
   thus if they encounter a fault the kernel will treat these as
   unintentional accesses to user memory, resulting in a BUG() which
   will kill the kernel thread, and likely lead to further issues (e.g.
   lockup or panic()).

2) The plain C accesses are subject to HW PAN and SW PAN, and so when
   either is in use, any attempt to simulate an access to user memory
   will fault. Thus neither simulate_ldr_literal() nor
   simulate_ldrsw_literal() can do anything useful when simulating a
   user instruction on any system with HW PAN or SW PAN.

3) The plain C accesses are privileged, as they run in kernel context,
   and in practice can access a small range of kernel virtual addresses.
   The instructions they simulate have a range of +/-1MiB, and since the
   simulated instructions must itself be a user instructions in the
   TTBR0 address range, these can address the final 1MiB of the TTBR1
   acddress range by wrapping downwards from an address in the first
   1MiB of the TTBR0 address range.

   In contemporary kernels the last 8MiB of TTBR1 address range is
   reserved, and accesses to this will always fault, meaning this is no
   worse than (1).

   Historically, it was theoretically possible for the linear map or
   vmemmap to spill into the final 8MiB of the TTBR1 address range, but
   in practice this is extremely unlikely to occur as this would
   require either:

   * Having enough physical memory to fill the entire linear map all the
     way to the final 1MiB of the TTBR1 address range.

   * Getting unlucky with KASLR randomization of the linear map such
     that the populated region happens to overlap with the last 1MiB of
     the TTBR address range.

   ... and in either case if we were to spill into the final page there
   would be larger problems as the final page would alias with error
   pointers.

Practically speaking, (1) and (2) are the big issues. Given there have
been no reports of problems since the broken code was introduced, it
appears that no-one is relying on probing these instructions with
uprobes.

Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW
(literal), limiting the use of simulate_ldr_literal() and
simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR
(literal) and LDRSW (literal) will be rejected as
arm_probe_decode_insn() will return INSN_REJECTED. In future we can
consider introducing working uprobes support for these instructions, but
this will require more significant work.</Note>
    </Notes>
    <CVE>CVE-2024-50099</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

USB: gadget: dummy-hcd: Fix "task hung" problem

The syzbot fuzzer has been encountering "task hung" problems ever
since the dummy-hcd driver was changed to use hrtimers instead of
regular timers.  It turns out that the problems are caused by a subtle
difference between the timer_pending() and hrtimer_active() APIs.

The changeover blindly replaced the first by the second.  However,
timer_pending() returns True when the timer is queued but not when its
callback is running, whereas hrtimer_active() returns True when the
hrtimer is queued _or_ its callback is running.  This difference
occasionally caused dummy_urb_enqueue() to think that the callback
routine had not yet started when in fact it was almost finished.  As a
result the hrtimer was not restarted, which made it impossible for the
driver to dequeue later the URB that was just enqueued.  This caused
usb_kill_urb() to hang, and things got worse from there.

Since hrtimers have no API for telling when they are queued and the
callback isn't running, the driver must keep track of this for itself.
That's what this patch does, adding a new "timer_pending" flag and
setting or clearing it at the appropriate times.</Note>
    </Notes>
    <CVE>CVE-2024-50100</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices

Previously, the domain_context_clear() function incorrectly called
pci_for_each_dma_alias() to set up context entries for non-PCI devices.
This could lead to kernel hangs or other unexpected behavior.

Add a check to only call pci_for_each_dma_alias() for PCI devices. For
non-PCI devices, domain_context_clear_one() is called directly.</Note>
    </Notes>
    <CVE>CVE-2024-50101</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

x86: fix user address masking non-canonical speculation issue

It turns out that AMD has a "Meltdown Lite(tm)" issue with non-canonical
accesses in kernel space.  And so using just the high bit to decide
whether an access is in user space or kernel space ends up with the good
old "leak speculative data" if you have the right gadget using the
result:

  CVE-2020-12965 "Transient Execution of Non-Canonical Accesses"

Now, the kernel surrounds the access with a STAC/CLAC pair, and those
instructions end up serializing execution on older Zen architectures,
which closes the speculation window.

But that was true only up until Zen 5, which renames the AC bit [1].
That improves performance of STAC/CLAC a lot, but also means that the
speculation window is now open.

Note that this affects not just the new address masking, but also the
regular valid_user_address() check used by access_ok(), and the asm
version of the sign bit check in the get_user() helpers.

It does not affect put_user() or clear_user() variants, since there's no
speculative result to be used in a gadget for those operations.</Note>
    </Notes>
    <CVE>CVE-2024-50102</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()

A devm_kzalloc() in asoc_qcom_lpass_cpu_platform_probe() could
possibly return NULL pointer. NULL Pointer Dereference may be
triggerred without addtional check.
Add a NULL check for the returned pointer.</Note>
    </Notes>
    <CVE>CVE-2024-50103</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too

Stuart Hayhurst has found that both at bootup and fullscreen VA-API video
is leading to black screens for around 1 second and kernel WARNING [1] traces
when calling dmub_psr_enable() with Parade 08-01 TCON.

These symptoms all go away with PSR-SU disabled for this TCON, so disable
it for now while DMUB traces [2] from the failure can be analyzed and the failure
state properly root caused.

(cherry picked from commit afb634a6823d8d9db23c5fb04f79c5549349628b)</Note>
    </Notes>
    <CVE>CVE-2024-50108</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xfrm: fix one more kernel-infoleak in algo dumping

During fuzz testing, the following issue was discovered:

BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x598/0x2a30
 _copy_to_iter+0x598/0x2a30
 __skb_datagram_iter+0x168/0x1060
 skb_copy_datagram_iter+0x5b/0x220
 netlink_recvmsg+0x362/0x1700
 sock_recvmsg+0x2dc/0x390
 __sys_recvfrom+0x381/0x6d0
 __x64_sys_recvfrom+0x130/0x200
 x64_sys_call+0x32c8/0x3cc0
 do_syscall_64+0xd8/0x1c0
 entry_SYSCALL_64_after_hwframe+0x79/0x81

Uninit was stored to memory at:
 copy_to_user_state_extra+0xcc1/0x1e00
 dump_one_state+0x28c/0x5f0
 xfrm_state_walk+0x548/0x11e0
 xfrm_dump_sa+0x1e0/0x840
 netlink_dump+0x943/0x1c40
 __netlink_dump_start+0x746/0xdb0
 xfrm_user_rcv_msg+0x429/0xc00
 netlink_rcv_skb+0x613/0x780
 xfrm_netlink_rcv+0x77/0xc0
 netlink_unicast+0xe90/0x1280
 netlink_sendmsg+0x126d/0x1490
 __sock_sendmsg+0x332/0x3d0
 ____sys_sendmsg+0x863/0xc30
 ___sys_sendmsg+0x285/0x3e0
 __x64_sys_sendmsg+0x2d6/0x560
 x64_sys_call+0x1316/0x3cc0
 do_syscall_64+0xd8/0x1c0
 entry_SYSCALL_64_after_hwframe+0x79/0x81

Uninit was created at:
 __kmalloc+0x571/0xd30
 attach_auth+0x106/0x3e0
 xfrm_add_sa+0x2aa0/0x4230
 xfrm_user_rcv_msg+0x832/0xc00
 netlink_rcv_skb+0x613/0x780
 xfrm_netlink_rcv+0x77/0xc0
 netlink_unicast+0xe90/0x1280
 netlink_sendmsg+0x126d/0x1490
 __sock_sendmsg+0x332/0x3d0
 ____sys_sendmsg+0x863/0xc30
 ___sys_sendmsg+0x285/0x3e0
 __x64_sys_sendmsg+0x2d6/0x560
 x64_sys_call+0x1316/0x3cc0
 do_syscall_64+0xd8/0x1c0
 entry_SYSCALL_64_after_hwframe+0x79/0x81

Bytes 328-379 of 732 are uninitialized
Memory access of size 732 starts at ffff88800e18e000
Data copied to user address 00007ff30f48aff0

CPU: 2 PID: 18167 Comm: syz-executor.0 Not tainted 6.8.11 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014

Fixes copying of xfrm algorithms where some random
data of the structure fields can end up in userspace.
Padding in structures may be filled with random (possibly sensitve)
data and should never be given directly to user-space.

A similar issue was resolved in the commit
8222d5910dae ("xfrm: Zero padding when dumping algos and encap")

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.</Note>
    </Notes>
    <CVE>CVE-2024-50110</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-50115</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix kernel bug due to missing clearing of buffer delay flag

Syzbot reported that after nilfs2 reads a corrupted file system image
and degrades to read-only, the BUG_ON check for the buffer delay flag
in submit_bh_wbc() may fail, causing a kernel bug.

This is because the buffer delay flag is not cleared when clearing the
buffer state flags to discard a page/folio or a buffer head. So, fix
this.

This became necessary when the use of nilfs2's own page clear routine
was expanded.  This state inconsistency does not occur if the buffer
is written normally by log writing.</Note>
    </Notes>
    <CVE>CVE-2024-50116</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd: Guard against bad data for ATIF ACPI method

If a BIOS provides bad data in response to an ATIF method call
this causes a NULL pointer dereference in the caller.

```
? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1))
? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434)
? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2))
? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1))
? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642)
? exc_page_fault (arch/x86/mm/fault.c:1542)
? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)
? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu
? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu
```

It has been encountered on at least one system, so guard for it.

(cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee)</Note>
    </Notes>
    <CVE>CVE-2024-50117</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfsd: cancel nfsd_shrinker_work using sync mode in nfs4_state_shutdown_net

In the normal case, when we excute `echo 0 &gt; /proc/fs/nfsd/threads`, the
function `nfs4_state_destroy_net` in `nfs4_state_shutdown_net` will
release all resources related to the hashed `nfs4_client`. If the
`nfsd_client_shrinker` is running concurrently, the `expire_client`
function will first unhash this client and then destroy it. This can
lead to the following warning. Additionally, numerous use-after-free
errors may occur as well.

nfsd_client_shrinker         echo 0 &gt; /proc/fs/nfsd/threads

expire_client                nfsd_shutdown_net
  unhash_client                ...
                               nfs4_state_shutdown_net
                                 /* won't wait shrinker exit */
  /*                             cancel_work(&amp;nn-&gt;nfsd_shrinker_work)
   * nfsd_file for this          /* won't destroy unhashed client1 */
   * client1 still alive         nfs4_state_destroy_net
   */

                               nfsd_file_cache_shutdown
                                 /* trigger warning */
                                 kmem_cache_destroy(nfsd_file_slab)
                                 kmem_cache_destroy(nfsd_file_mark_slab)
  /* release nfsd_file and mark */
  __destroy_client

====================================================================
BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on
__kmem_cache_shutdown()
--------------------------------------------------------------------
CPU: 4 UID: 0 PID: 764 Comm: sh Not tainted 6.12.0-rc3+ #1

 dump_stack_lvl+0x53/0x70
 slab_err+0xb0/0xf0
 __kmem_cache_shutdown+0x15c/0x310
 kmem_cache_destroy+0x66/0x160
 nfsd_file_cache_shutdown+0xac/0x210 [nfsd]
 nfsd_destroy_serv+0x251/0x2a0 [nfsd]
 nfsd_svc+0x125/0x1e0 [nfsd]
 write_threads+0x16a/0x2a0 [nfsd]
 nfsctl_transaction_write+0x74/0xa0 [nfsd]
 vfs_write+0x1a5/0x6d0
 ksys_write+0xc1/0x160
 do_syscall_64+0x5f/0x170
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

====================================================================
BUG nfsd_file_mark (Tainted: G    B   W         ): Objects remaining
nfsd_file_mark on __kmem_cache_shutdown()
--------------------------------------------------------------------

 dump_stack_lvl+0x53/0x70
 slab_err+0xb0/0xf0
 __kmem_cache_shutdown+0x15c/0x310
 kmem_cache_destroy+0x66/0x160
 nfsd_file_cache_shutdown+0xc8/0x210 [nfsd]
 nfsd_destroy_serv+0x251/0x2a0 [nfsd]
 nfsd_svc+0x125/0x1e0 [nfsd]
 write_threads+0x16a/0x2a0 [nfsd]
 nfsctl_transaction_write+0x74/0xa0 [nfsd]
 vfs_write+0x1a5/0x6d0
 ksys_write+0xc1/0x160
 do_syscall_64+0x5f/0x170
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

To resolve this issue, cancel `nfsd_shrinker_work` using synchronous
mode in nfs4_state_shutdown_net.</Note>
    </Notes>
    <CVE>CVE-2024-50121</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: ISO: Fix UAF on iso_sock_timeout

conn-&gt;sk maybe have been unlinked/freed while waiting for iso_conn_lock
so this checks if the conn-&gt;sk is still valid by checking if it part of
iso_sk_list.</Note>
    </Notes>
    <CVE>CVE-2024-50124</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: SCO: Fix UAF on sco_sock_timeout

conn-&gt;sk maybe have been unlinked/freed while waiting for sco_conn_lock
so this checks if the conn-&gt;sk is still valid by checking if it part of
sco_sk_list.</Note>
    </Notes>
    <CVE>CVE-2024-50125</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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-&gt;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.</Note>
    </Notes>
    <CVE>CVE-2024-50127</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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:
 &lt;TASK&gt;
 __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
 &lt;/TASK&gt;

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
&gt;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.</Note>
    </Notes>
    <CVE>CVE-2024-50128</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: bpf: must hold reference on net namespace

BUG: KASAN: slab-use-after-free in __nf_unregister_net_hook+0x640/0x6b0
Read of size 8 at addr ffff8880106fe400 by task repro/72=
bpf_nf_link_release+0xda/0x1e0
bpf_link_free+0x139/0x2d0
bpf_link_release+0x68/0x80
__fput+0x414/0xb60

Eric says:
 It seems that bpf was able to defer the __nf_unregister_net_hook()
 after exit()/close() time.
 Perhaps a netns reference is missing, because the netns has been
 dismantled/freed already.
 bpf_nf_link_attach() does :
 link-&gt;net = net;
 But I do not see a reference being taken on net.

Add such a reference and release it after hook unreg.
Note that I was unable to get syzbot reproducer to work, so I
do not know if this resolves this splat.</Note>
    </Notes>
    <CVE>CVE-2024-50130</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tracing: Consider the NULL character when validating the event length

strlen() returns a string length excluding the null byte. If the string
length equals to the maximum buffer length, the buffer will have no
space for the NULL terminating character.

This commit checks this condition and returns failure for it.</Note>
    </Notes>
    <CVE>CVE-2024-50131</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA

Replace the fake VLA at end of the vbva_mouse_pointer_shape shape with
a real VLA to fix a "memcpy: detected field-spanning write error" warning:

[   13.319813] memcpy: detected field-spanning write (size 16896) of single field "p-&gt;data" at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4)
[   13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo]
[   13.320038] Call Trace:
[   13.320173]  hgsmi_update_pointer_shape [vboxvideo]
[   13.320184]  vbox_cursor_atomic_update [vboxvideo]

Note as mentioned in the added comment it seems the original length
calculation for the allocated and send hgsmi buffer is 4 bytes too large.
Changing this is not the goal of this patch, so this behavior is kept.</Note>
    </Notes>
    <CVE>CVE-2024-50134</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nvme-pci: fix race condition between reset and nvme_dev_disable()

nvme_dev_disable() modifies the dev-&gt;online_queues field, therefore
nvme_pci_update_nr_queues() should avoid racing against it, otherwise
we could end up passing invalid values to blk_mq_update_nr_hw_queues().

 WARNING: CPU: 39 PID: 61303 at drivers/pci/msi/api.c:347
          pci_irq_get_affinity+0x187/0x210
 Workqueue: nvme-reset-wq nvme_reset_work [nvme]
 RIP: 0010:pci_irq_get_affinity+0x187/0x210
 Call Trace:
  &lt;TASK&gt;
  ? blk_mq_pci_map_queues+0x87/0x3c0
  ? pci_irq_get_affinity+0x187/0x210
  blk_mq_pci_map_queues+0x87/0x3c0
  nvme_pci_map_queues+0x189/0x460 [nvme]
  blk_mq_update_nr_hw_queues+0x2a/0x40
  nvme_reset_work+0x1be/0x2a0 [nvme]

Fix the bug by locking the shutdown_lock mutex before using
dev-&gt;online_queues. Give up if nvme_dev_disable() is running or if
it has been executed already.</Note>
    </Notes>
    <CVE>CVE-2024-50135</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: Unregister notifier on eswitch init failure

It otherwise remains registered and a subsequent attempt at eswitch
enabling might trigger warnings of the sort:

[  682.589148] ------------[ cut here ]------------
[  682.590204] notifier callback eswitch_vport_event [mlx5_core] already registered
[  682.590256] WARNING: CPU: 13 PID: 2660 at kernel/notifier.c:31 notifier_chain_register+0x3e/0x90
[...snipped]
[  682.610052] Call Trace:
[  682.610369]  &lt;TASK&gt;
[  682.610663]  ? __warn+0x7c/0x110
[  682.611050]  ? notifier_chain_register+0x3e/0x90
[  682.611556]  ? report_bug+0x148/0x170
[  682.611977]  ? handle_bug+0x36/0x70
[  682.612384]  ? exc_invalid_op+0x13/0x60
[  682.612817]  ? asm_exc_invalid_op+0x16/0x20
[  682.613284]  ? notifier_chain_register+0x3e/0x90
[  682.613789]  atomic_notifier_chain_register+0x25/0x40
[  682.614322]  mlx5_eswitch_enable_locked+0x1d4/0x3b0 [mlx5_core]
[  682.614965]  mlx5_eswitch_enable+0xc9/0x100 [mlx5_core]
[  682.615551]  mlx5_device_enable_sriov+0x25/0x340 [mlx5_core]
[  682.616170]  mlx5_core_sriov_configure+0x50/0x170 [mlx5_core]
[  682.616789]  sriov_numvfs_store+0xb0/0x1b0
[  682.617248]  kernfs_fop_write_iter+0x117/0x1a0
[  682.617734]  vfs_write+0x231/0x3f0
[  682.618138]  ksys_write+0x63/0xe0
[  682.618536]  do_syscall_64+0x4c/0x100
[  682.618958]  entry_SYSCALL_64_after_hwframe+0x4b/0x53</Note>
    </Notes>
    <CVE>CVE-2024-50136</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Use raw_spinlock_t in ringbuf

The function __bpf_ringbuf_reserve is invoked from a tracepoint, which
disables preemption. Using spinlock_t in this context can lead to a
"sleep in atomic" warning in the RT variant. This issue is illustrated
in the example below:

BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 556208, name: test_progs
preempt_count: 1, expected: 0
RCU nest depth: 1, expected: 1
INFO: lockdep is turned off.
Preemption disabled at:
[&lt;ffffd33a5c88ea44&gt;] migrate_enable+0xc0/0x39c
CPU: 7 PID: 556208 Comm: test_progs Tainted: G
Hardware name: Qualcomm SA8775P Ride (DT)
Call trace:
 dump_backtrace+0xac/0x130
 show_stack+0x1c/0x30
 dump_stack_lvl+0xac/0xe8
 dump_stack+0x18/0x30
 __might_resched+0x3bc/0x4fc
 rt_spin_lock+0x8c/0x1a4
 __bpf_ringbuf_reserve+0xc4/0x254
 bpf_ringbuf_reserve_dynptr+0x5c/0xdc
 bpf_prog_ac3d15160d62622a_test_read_write+0x104/0x238
 trace_call_bpf+0x238/0x774
 perf_call_bpf_enter.isra.0+0x104/0x194
 perf_syscall_enter+0x2f8/0x510
 trace_sys_enter+0x39c/0x564
 syscall_trace_enter+0x220/0x3c0
 do_el0_svc+0x138/0x1dc
 el0_svc+0x54/0x130
 el0t_64_sync_handler+0x134/0x150
 el0t_64_sync+0x17c/0x180

Switch the spinlock to raw_spinlock_t to avoid this error.</Note>
    </Notes>
    <CVE>CVE-2024-50138</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

KVM: arm64: Fix shift-out-of-bounds bug

Fix a shift-out-of-bounds bug reported by UBSAN when running
VM with MTE enabled host kernel.

UBSAN: shift-out-of-bounds in arch/arm64/kvm/sys_regs.c:1988:14
shift exponent 33 is too large for 32-bit type 'int'
CPU: 26 UID: 0 PID: 7629 Comm: qemu-kvm Not tainted 6.12.0-rc2 #34
Hardware name: IEI NF5280R7/Mitchell MB, BIOS 00.00. 2024-10-12 09:28:54 10/14/2024
Call trace:
 dump_backtrace+0xa0/0x128
 show_stack+0x20/0x38
 dump_stack_lvl+0x74/0x90
 dump_stack+0x18/0x28
 __ubsan_handle_shift_out_of_bounds+0xf8/0x1e0
 reset_clidr+0x10c/0x1c8
 kvm_reset_sys_regs+0x50/0x1c8
 kvm_reset_vcpu+0xec/0x2b0
 __kvm_vcpu_set_target+0x84/0x158
 kvm_vcpu_set_target+0x138/0x168
 kvm_arch_vcpu_ioctl_vcpu_init+0x40/0x2b0
 kvm_arch_vcpu_ioctl+0x28c/0x4b8
 kvm_vcpu_ioctl+0x4bc/0x7a8
 __arm64_sys_ioctl+0xb4/0x100
 invoke_syscall+0x70/0x100
 el0_svc_common.constprop.0+0x48/0xf0
 do_el0_svc+0x24/0x38
 el0_svc+0x3c/0x158
 el0t_64_sync_handler+0x120/0x130
 el0t_64_sync+0x194/0x198</Note>
    </Notes>
    <CVE>CVE-2024-50139</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context

PRMT needs to find the correct type of block to translate the PA-VA
mapping for EFI runtime services.

The issue arises because the PRMT is finding a block of type
EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services
as described in Section 2.2.2 (Runtime Services) of the UEFI
Specification [1]. Since the PRM handler is a type of runtime service,
this causes an exception when the PRM handler is called.

    [Firmware Bug]: Unable to handle paging request in EFI runtime service
    WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341
        __efi_queue_work+0x11c/0x170
    Call trace:

Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM
context.

If no suitable block is found, a warning message will be printed, but
the procedure continues to manage the next PRM handler.

However, if the PRM handler is actually called without proper allocation,
it would result in a failure during error handling.

By using the correct memory types for runtime services, ensure that the
PRM handler and the context are properly mapped in the virtual address
space during runtime, preventing the paging request error.

The issue is really that only memory that has been remapped for runtime
by the firmware can be used by the PRM handler, and so the region needs
to have the EFI_MEMORY_RUNTIME attribute.

[ rjw: Subject and changelog edits ]</Note>
    </Notes>
    <CVE>CVE-2024-50141</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

udf: fix uninit-value use in udf_get_fileshortad

Check for overflow when computing alen in udf_current_aext to mitigate
later uninit-value use in udf_get_fileshortad KMSAN bug[1].
After applying the patch reproducer did not trigger any issue[2].

[1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df
[2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000</Note>
    </Notes>
    <CVE>CVE-2024-50143</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

octeon_ep: Add SKB allocation failures handling in __octep_oq_process_rx()

build_skb() returns NULL in case of a memory allocation failure so handle
it inside __octep_oq_process_rx() to avoid NULL pointer dereference.

__octep_oq_process_rx() is called during NAPI polling by the driver. If
skb allocation fails, keep on pulling packets out of the Rx DMA queue: we
shouldn't break the polling immediately and thus falsely indicate to the
octep_napi_poll() that the Rx pressure is going down. As there is no
associated skb in this case, don't process the packets and don't push them
up the network stack - they are skipped.

Helper function is implemented to unmmap/flush all the fragment buffers
used by the dropped packet. 'alloc_failures' counter is incremented to
mark the skb allocation error in driver statistics.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2024-50145</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Don't call cleanup on profile rollback failure

When profile rollback fails in mlx5e_netdev_change_profile, the netdev
profile var is left set to NULL. Avoid a crash when unloading the driver
by not calling profile-&gt;cleanup in such a case.

This was encountered while testing, with the original trigger that
the wq rescuer thread creation got interrupted (presumably due to
Ctrl+C-ing modprobe), which gets converted to ENOMEM (-12) by
mlx5e_priv_init, the profile rollback also fails for the same reason
(signal still active) so the profile is left as NULL, leading to a crash
later in _mlx5e_remove.

 [  732.473932] mlx5_core 0000:08:00.1: E-Switch: Unload vfs: mode(OFFLOADS), nvfs(2), necvfs(0), active vports(2)
 [  734.525513] workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR
 [  734.557372] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init failed, err=-12
 [  734.559187] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: new profile init failed, -12
 [  734.560153] workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR
 [  734.589378] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init failed, err=-12
 [  734.591136] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12
 [  745.537492] BUG: kernel NULL pointer dereference, address: 0000000000000008
 [  745.538222] #PF: supervisor read access in kernel mode
&lt;snipped&gt;
 [  745.551290] Call Trace:
 [  745.551590]  &lt;TASK&gt;
 [  745.551866]  ? __die+0x20/0x60
 [  745.552218]  ? page_fault_oops+0x150/0x400
 [  745.555307]  ? exc_page_fault+0x79/0x240
 [  745.555729]  ? asm_exc_page_fault+0x22/0x30
 [  745.556166]  ? mlx5e_remove+0x6b/0xb0 [mlx5_core]
 [  745.556698]  auxiliary_bus_remove+0x18/0x30
 [  745.557134]  device_release_driver_internal+0x1df/0x240
 [  745.557654]  bus_remove_device+0xd7/0x140
 [  745.558075]  device_del+0x15b/0x3c0
 [  745.558456]  mlx5_rescan_drivers_locked.part.0+0xb1/0x2f0 [mlx5_core]
 [  745.559112]  mlx5_unregister_device+0x34/0x50 [mlx5_core]
 [  745.559686]  mlx5_uninit_one+0x46/0xf0 [mlx5_core]
 [  745.560203]  remove_one+0x4e/0xd0 [mlx5_core]
 [  745.560694]  pci_device_remove+0x39/0xa0
 [  745.561112]  device_release_driver_internal+0x1df/0x240
 [  745.561631]  driver_detach+0x47/0x90
 [  745.562022]  bus_remove_driver+0x84/0x100
 [  745.562444]  pci_unregister_driver+0x3b/0x90
 [  745.562890]  mlx5_cleanup+0xc/0x1b [mlx5_core]
 [  745.563415]  __x64_sys_delete_module+0x14d/0x2f0
 [  745.563886]  ? kmem_cache_free+0x1b0/0x460
 [  745.564313]  ? lockdep_hardirqs_on_prepare+0xe2/0x190
 [  745.564825]  do_syscall_64+0x6d/0x140
 [  745.565223]  entry_SYSCALL_64_after_hwframe+0x4b/0x53
 [  745.565725] RIP: 0033:0x7f1579b1288b</Note>
    </Notes>
    <CVE>CVE-2024-50146</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: Fix command bitmask initialization

Command bitmask have a dedicated bit for MANAGE_PAGES command, this bit
isn't Initialize during command bitmask Initialization, only during
MANAGE_PAGES.

In addition, mlx5_cmd_trigger_completions() is trying to trigger
completion for MANAGE_PAGES command as well.

Hence, in case health error occurred before any MANAGE_PAGES command
have been invoke (for example, during mlx5_enable_hca()),
mlx5_cmd_trigger_completions() will try to trigger completion for
MANAGE_PAGES command, which will result in null-ptr-deref error.[1]

Fix it by Initialize command bitmask correctly.

While at it, re-write the code for better understanding.

[1]
BUG: KASAN: null-ptr-deref in mlx5_cmd_trigger_completions+0x1db/0x600 [mlx5_core]
Write of size 4 at addr 0000000000000214 by task kworker/u96:2/12078
CPU: 10 PID: 12078 Comm: kworker/u96:2 Not tainted 6.9.0-rc2_for_upstream_debug_2024_04_07_19_01 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Workqueue: mlx5_health0000:08:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core]
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x7e/0xc0
 kasan_report+0xb9/0xf0
 kasan_check_range+0xec/0x190
 mlx5_cmd_trigger_completions+0x1db/0x600 [mlx5_core]
 mlx5_cmd_flush+0x94/0x240 [mlx5_core]
 enter_error_state+0x6c/0xd0 [mlx5_core]
 mlx5_fw_fatal_reporter_err_work+0xf3/0x480 [mlx5_core]
 process_one_work+0x787/0x1490
 ? lockdep_hardirqs_on_prepare+0x400/0x400
 ? pwq_dec_nr_in_flight+0xda0/0xda0
 ? assign_work+0x168/0x240
 worker_thread+0x586/0xd30
 ? rescuer_thread+0xae0/0xae0
 kthread+0x2df/0x3b0
 ? kthread_complete_and_exit+0x20/0x20
 ret_from_fork+0x2d/0x70
 ? kthread_complete_and_exit+0x20/0x20
 ret_from_fork_asm+0x11/0x20
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-50147</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: bnep: fix wild-memory-access in proto_unregister

There's issue as follows:
  KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f]
  CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G        W
  RIP: 0010:proto_unregister+0xee/0x400
  Call Trace:
   &lt;TASK&gt;
   __do_sys_delete_module+0x318/0x580
   do_syscall_64+0xc1/0x1d0
   entry_SYSCALL_64_after_hwframe+0x77/0x7f

As bnep_init() ignore bnep_sock_init()'s return value, and bnep_sock_init()
will cleanup all resource. Then when remove bnep module will call
bnep_sock_cleanup() to cleanup sock's resource.
To solve above issue just return bnep_sock_init()'s return value in
bnep_exit().</Note>
    </Notes>
    <CVE>CVE-2024-50148</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: typec: altmode should keep reference to parent

The altmode device release refers to its parent device, but without keeping
a reference to it.

When registering the altmode, get a reference to the parent and put it in
the release function.

Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues
like this:

[   43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000)
[   43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000)
[   43.574407] kobject: 'port0' (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000)
[   43.575059] kobject: 'port1.0' (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000)
[   43.575908] kobject: 'port1.1' (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000)
[   43.576908] kobject: 'typec' (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000)
[   43.577769] kobject: 'port1' (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000)
[   46.612867] ==================================================================
[   46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129
[   46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48
[   46.614538]
[   46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535
[   46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
[   46.616042] Workqueue: events kobject_delayed_cleanup
[   46.616446] Call Trace:
[   46.616648]  &lt;TASK&gt;
[   46.616820]  dump_stack_lvl+0x5b/0x7c
[   46.617112]  ? typec_altmode_release+0x38/0x129
[   46.617470]  print_report+0x14c/0x49e
[   46.617769]  ? rcu_read_unlock_sched+0x56/0x69
[   46.618117]  ? __virt_addr_valid+0x19a/0x1ab
[   46.618456]  ? kmem_cache_debug_flags+0xc/0x1d
[   46.618807]  ? typec_altmode_release+0x38/0x129
[   46.619161]  kasan_report+0x8d/0xb4
[   46.619447]  ? typec_altmode_release+0x38/0x129
[   46.619809]  ? process_scheduled_works+0x3cb/0x85f
[   46.620185]  typec_altmode_release+0x38/0x129
[   46.620537]  ? process_scheduled_works+0x3cb/0x85f
[   46.620907]  device_release+0xaf/0xf2
[   46.621206]  kobject_delayed_cleanup+0x13b/0x17a
[   46.621584]  process_scheduled_works+0x4f6/0x85f
[   46.621955]  ? __pfx_process_scheduled_works+0x10/0x10
[   46.622353]  ? hlock_class+0x31/0x9a
[   46.622647]  ? lock_acquired+0x361/0x3c3
[   46.622956]  ? move_linked_works+0x46/0x7d
[   46.623277]  worker_thread+0x1ce/0x291
[   46.623582]  ? __kthread_parkme+0xc8/0xdf
[   46.623900]  ? __pfx_worker_thread+0x10/0x10
[   46.624236]  kthread+0x17e/0x190
[   46.624501]  ? kthread+0xfb/0x190
[   46.624756]  ? __pfx_kthread+0x10/0x10
[   46.625015]  ret_from_fork+0x20/0x40
[   46.625268]  ? __pfx_kthread+0x10/0x10
[   46.625532]  ret_from_fork_asm+0x1a/0x30
[   46.625805]  &lt;/TASK&gt;
[   46.625953]
[   46.626056] Allocated by task 678:
[   46.626287]  kasan_save_stack+0x24/0x44
[   46.626555]  kasan_save_track+0x14/0x2d
[   46.626811]  __kasan_kmalloc+0x3f/0x4d
[   46.627049]  __kmalloc_noprof+0x1bf/0x1f0
[   46.627362]  typec_register_port+0x23/0x491
[   46.627698]  cros_typec_probe+0x634/0xbb6
[   46.628026]  platform_probe+0x47/0x8c
[   46.628311]  really_probe+0x20a/0x47d
[   46.628605]  device_driver_attach+0x39/0x72
[   46.628940]  bind_store+0x87/0xd7
[   46.629213]  kernfs_fop_write_iter+0x1aa/0x218
[   46.629574]  vfs_write+0x1d6/0x29b
[   46.629856]  ksys_write+0xcd/0x13b
[   46.630128]  do_syscall_64+0xd4/0x139
[   46.630420]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[   46.630820]
[   46.630946] Freed by task 48:
[   46.631182]  kasan_save_stack+0x24/0x44
[   46.631493]  kasan_save_track+0x14/0x2d
[   46.631799]  kasan_save_free_info+0x3f/0x4d
[   46.632144]  __kasan_slab_free+0x37/0x45
[   46.632474]
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-50150</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: target: core: Fix null-ptr-deref in target_alloc_device()

There is a null-ptr-deref issue reported by KASAN:

BUG: KASAN: null-ptr-deref in target_alloc_device+0xbc4/0xbe0 [target_core_mod]
...
 kasan_report+0xb9/0xf0
 target_alloc_device+0xbc4/0xbe0 [target_core_mod]
 core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod]
 target_core_init_configfs+0x205/0x420 [target_core_mod]
 do_one_initcall+0xdd/0x4e0
...
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

In target_alloc_device(), if allocing memory for dev queues fails, then
dev will be freed by dev-&gt;transport-&gt;free_device(), but dev-&gt;transport
is not initialized at that time, which will lead to a null pointer
reference problem.

Fixing this bug by freeing dev with hba-&gt;backend-&gt;ops-&gt;free_device().</Note>
    </Notes>
    <CVE>CVE-2024-50153</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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-&gt;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-&gt;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-&gt;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-&gt;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-&gt;sk for non-TFO sockets

  4. sk is close()d

  5. reqsk timer is executed again, and BPF touches req-&gt;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</Note>
    </Notes>
    <CVE>CVE-2024-50154</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netdevsim: use cond_resched() in nsim_dev_trap_report_work()

I am still seeing many syzbot reports hinting that syzbot
might fool nsim_dev_trap_report_work() with hundreds of ports [1]

Lets use cond_resched(), and system_unbound_wq
instead of implicit system_wq.

[1]
INFO: task syz-executor:20633 blocked for more than 143 seconds.
      Not tainted 6.12.0-rc2-syzkaller-00205-g1d227fcc7222 #0
"echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor    state:D stack:25856 pid:20633 tgid:20633 ppid:1      flags:0x00004006
...
NMI backtrace for cpu 1
CPU: 1 UID: 0 PID: 16760 Comm: kworker/1:0 Not tainted 6.12.0-rc2-syzkaller-00205-g1d227fcc7222 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Workqueue: events nsim_dev_trap_report_work
 RIP: 0010:__sanitizer_cov_trace_pc+0x0/0x70 kernel/kcov.c:210
Code: 89 fb e8 23 00 00 00 48 8b 3d 04 fb 9c 0c 48 89 de 5b e9 c3 c7 5d 00 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 &lt;f3&gt; 0f 1e fa 48 8b 04 24 65 48 8b 0c 25 c0 d7 03 00 65 8b 15 60 f0
RSP: 0018:ffffc90000a187e8 EFLAGS: 00000246
RAX: 0000000000000100 RBX: ffffc90000a188e0 RCX: ffff888027d3bc00
RDX: ffff888027d3bc00 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff88804a2e6000 R08: ffffffff8a4bc495 R09: ffffffff89da3577
R10: 0000000000000004 R11: ffffffff8a4bc2b0 R12: dffffc0000000000
R13: ffff88806573b503 R14: dffffc0000000000 R15: ffff8880663cca00
FS:  0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fc90a747f98 CR3: 000000000e734000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 000000000000002b DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Call Trace:
 &lt;NMI&gt;
 &lt;/NMI&gt;
 &lt;TASK&gt;
  __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382
  spin_unlock_bh include/linux/spinlock.h:396 [inline]
  nsim_dev_trap_report drivers/net/netdevsim/dev.c:820 [inline]
  nsim_dev_trap_report_work+0x75d/0xaa0 drivers/net/netdevsim/dev.c:850
  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
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-50155</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/msm: Avoid NULL dereference in msm_disp_state_print_regs()

If the allocation in msm_disp_state_dump_regs() failed then
`block-&gt;state` can be NULL. The msm_disp_state_print_regs() function
_does_ have code to try to handle it with:

  if (*reg)
    dump_addr = *reg;

...but since "dump_addr" is initialized to NULL the above is actually
a noop. The code then goes on to dereference `dump_addr`.

Make the function print "Registers not stored" when it sees a NULL to
solve this. Since we're touching the code, fix
msm_disp_state_print_regs() not to pointlessly take a double-pointer
and properly mark the pointer as `const`.

Patchwork: https://patchwork.freedesktop.org/patch/619657/</Note>
    </Notes>
    <CVE>CVE-2024-50156</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/bnxt_re: Avoid CPU lockups due fifo occupancy check loop

Driver waits indefinitely for the fifo occupancy to go below a threshold
as soon as the pacing interrupt is received. This can cause soft lockup on
one of the processors, if the rate of DB is very high.

Add a loop count for FPGA and exit the __wait_for_fifo_occupancy_below_th
if the loop is taking more time. Pacing will be continuing until the
occupancy is below the threshold. This is ensured by the checks in
bnxt_re_pacing_timer_exp and further scheduling the work for pacing based
on the fifo occupancy.</Note>
    </Notes>
    <CVE>CVE-2024-50157</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/bnxt_re: Fix out of bound check

Driver exports pacing stats only on GenP5 and P7 adapters. But while
parsing the pacing stats, driver has a check for "rdev-&gt;dbr_pacing".  This
caused a trace when KASAN is enabled.

BUG: KASAN: slab-out-of-bounds in bnxt_re_get_hw_stats+0x2b6a/0x2e00 [bnxt_re]
Write of size 8 at addr ffff8885942a6340 by task modprobe/4809</Note>
    </Notes>
    <CVE>CVE-2024-50158</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

firmware: arm_scmi: Fix the double free in scmi_debugfs_common_setup()

Clang static checker(scan-build) throws below warning:
  |  drivers/firmware/arm_scmi/driver.c:line 2915, column 2
  |        Attempt to free released memory.

When devm_add_action_or_reset() fails, scmi_debugfs_common_cleanup()
will run twice which causes double free of 'dbg-&gt;name'.

Remove the redundant scmi_debugfs_common_cleanup() to fix this problem.</Note>
    </Notes>
    <CVE>CVE-2024-50159</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: hda/cs8409: Fix possible NULL dereference

If snd_hda_gen_add_kctl fails to allocate memory and returns NULL, then
NULL pointer dereference will occur in the next line.

Since dolphin_fixups function is a hda_fixup function which is not supposed
to return any errors, add simple check before dereference, ignore the fail.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2024-50160</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fsl/fman: Fix refcount handling of fman-related devices

In mac_probe() there are multiple calls to of_find_device_by_node(),
fman_bind() and fman_port_bind() which takes references to of_dev-&gt;dev.
Not all references taken by these calls are released later on error path
in mac_probe() and in mac_remove() which lead to reference leaks.

Add references release.</Note>
    </Notes>
    <CVE>CVE-2024-50166</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

be2net: fix potential memory leak in be_xmit()

The be_xmit() returns NETDEV_TX_OK without freeing skb
in case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it.</Note>
    </Notes>
    <CVE>CVE-2024-50167</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vsock: Update rx_bytes on read_skb()

Make sure virtio_transport_inc_rx_pkt() and virtio_transport_dec_rx_pkt()
calls are balanced (i.e. virtio_vsock_sock::rx_bytes doesn't lie) after
vsock_transport::read_skb().

While here, also inform the peer that we've freed up space and it has more
credit.

Failing to update rx_bytes after packet is dequeued leads to a warning on
SOCK_STREAM recv():

[  233.396654] rx_queue is empty, but rx_bytes is non-zero
[  233.396702] WARNING: CPU: 11 PID: 40601 at net/vmw_vsock/virtio_transport_common.c:589</Note>
    </Notes>
    <CVE>CVE-2024-50169</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: systemport: fix potential memory leak in bcm_sysport_xmit()

The bcm_sysport_xmit() returns NETDEV_TX_OK without freeing skb
in case of dma_map_single() fails, add dev_kfree_skb() to fix it.</Note>
    </Notes>
    <CVE>CVE-2024-50171</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/bnxt_re: Fix a possible memory leak

In bnxt_re_setup_chip_ctx() when bnxt_qplib_map_db_bar() fails
driver is not freeing the memory allocated for "rdev-&gt;chip_ctx".</Note>
    </Notes>
    <CVE>CVE-2024-50172</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: qcom: camss: Remove use_count guard in stop_streaming

The use_count check was introduced so that multiple concurrent Raw Data
Interfaces RDIs could be driven by different virtual channels VCs on the
CSIPHY input driving the video pipeline.

This is an invalid use of use_count though as use_count pertains to the
number of times a video entity has been opened by user-space not the number
of active streams.

If use_count and stream-on count don't agree then stop_streaming() will
break as is currently the case and has become apparent when using CAMSS
with libcamera's released softisp 0.3.

The use of use_count like this is a bit hacky and right now breaks regular
usage of CAMSS for a single stream case. Stopping qcam results in the splat
below, and then it cannot be started again and any attempts to do so fails
with -EBUSY.

[ 1265.509831] WARNING: CPU: 5 PID: 919 at drivers/media/common/videobuf2/videobuf2-core.c:2183 __vb2_queue_cancel+0x230/0x2c8 [videobuf2_common]
...
[ 1265.510630] Call trace:
[ 1265.510636]  __vb2_queue_cancel+0x230/0x2c8 [videobuf2_common]
[ 1265.510648]  vb2_core_streamoff+0x24/0xcc [videobuf2_common]
[ 1265.510660]  vb2_ioctl_streamoff+0x5c/0xa8 [videobuf2_v4l2]
[ 1265.510673]  v4l_streamoff+0x24/0x30 [videodev]
[ 1265.510707]  __video_do_ioctl+0x190/0x3f4 [videodev]
[ 1265.510732]  video_usercopy+0x304/0x8c4 [videodev]
[ 1265.510757]  video_ioctl2+0x18/0x34 [videodev]
[ 1265.510782]  v4l2_ioctl+0x40/0x60 [videodev]
...
[ 1265.510944] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 0 in active state
[ 1265.511175] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 1 in active state
[ 1265.511398] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 2 in active st

One CAMSS specific way to handle multiple VCs on the same RDI might be:

- Reference count each pipeline enable for CSIPHY, CSID, VFE and RDIx.
- The video buffers are already associated with msm_vfeN_rdiX so
  release video buffers when told to do so by stop_streaming.
- Only release the power-domains for the CSIPHY, CSID and VFE when
  their internal refcounts drop.

Either way refusing to release video buffers based on use_count is
erroneous and should be reverted. The silicon enabling code for selecting
VCs is perfectly fine. Its a "known missing feature" that concurrent VCs
won't work with CAMSS right now.

Initial testing with this code didn't show an error but, SoftISP and "real"
usage with Google Hangouts breaks the upstream code pretty quickly, we need
to do a partial revert and take another pass at VCs.

This commit partially reverts commit 89013969e232 ("media: camss: sm8250:
Pipeline starting and stopping for multiple virtual channels")</Note>
    </Notes>
    <CVE>CVE-2024-50175</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

remoteproc: k3-r5: Fix error handling when power-up failed

By simply bailing out, the driver was violating its rule and internal
assumptions that either both or no rproc should be initialized. E.g.,
this could cause the first core to be available but not the second one,
leading to crashes on its shutdown later on while trying to dereference
that second instance.</Note>
    </Notes>
    <CVE>CVE-2024-50176</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: fix a UBSAN warning in DML2.1

When programming phantom pipe, since cursor_width is explicity set to 0,
this causes calculation logic to trigger overflow for an unsigned int
triggering the kernel's UBSAN check as below:

[   40.962845] UBSAN: shift-out-of-bounds in /tmp/amd.EfpumTkO/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3312:34
[   40.962849] shift exponent 4294967170 is too large for 32-bit type 'unsigned int'
[   40.962852] CPU: 1 PID: 1670 Comm: gnome-shell Tainted: G        W  OE      6.5.0-41-generic #41~22.04.2-Ubuntu
[   40.962854] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F21 01/10/2024
[   40.962856] Call Trace:
[   40.962857]  &lt;TASK&gt;
[   40.962860]  dump_stack_lvl+0x48/0x70
[   40.962870]  dump_stack+0x10/0x20
[   40.962872]  __ubsan_handle_shift_out_of_bounds+0x1ac/0x360
[   40.962878]  calculate_cursor_req_attributes.cold+0x1b/0x28 [amdgpu]
[   40.963099]  dml_core_mode_support+0x6b91/0x16bc0 [amdgpu]
[   40.963327]  ? srso_alias_return_thunk+0x5/0x7f
[   40.963331]  ? CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport+0x18b8/0x2790 [amdgpu]
[   40.963534]  ? srso_alias_return_thunk+0x5/0x7f
[   40.963536]  ? dml_core_mode_support+0xb3db/0x16bc0 [amdgpu]
[   40.963730]  dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu]
[   40.963906]  ? srso_alias_return_thunk+0x5/0x7f
[   40.963909]  ? dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu]
[   40.964078]  core_dcn4_mode_support+0x72/0xbf0 [amdgpu]
[   40.964247]  dml2_top_optimization_perform_optimization_phase+0x1d3/0x2a0 [amdgpu]
[   40.964420]  dml2_build_mode_programming+0x23d/0x750 [amdgpu]
[   40.964587]  dml21_validate+0x274/0x770 [amdgpu]
[   40.964761]  ? srso_alias_return_thunk+0x5/0x7f
[   40.964763]  ? resource_append_dpp_pipes_for_plane_composition+0x27c/0x3b0 [amdgpu]
[   40.964942]  dml2_validate+0x504/0x750 [amdgpu]
[   40.965117]  ? dml21_copy+0x95/0xb0 [amdgpu]
[   40.965291]  ? srso_alias_return_thunk+0x5/0x7f
[   40.965295]  dcn401_validate_bandwidth+0x4e/0x70 [amdgpu]
[   40.965491]  update_planes_and_stream_state+0x38d/0x5c0 [amdgpu]
[   40.965672]  update_planes_and_stream_v3+0x52/0x1e0 [amdgpu]
[   40.965845]  ? srso_alias_return_thunk+0x5/0x7f
[   40.965849]  dc_update_planes_and_stream+0x71/0xb0 [amdgpu]

Fix this by adding a guard for checking cursor width before triggering
the size calculation.</Note>
    </Notes>
    <CVE>CVE-2024-50177</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ceph: remove the incorrect Fw reference check when dirtying pages

When doing the direct-io reads it will also try to mark pages dirty,
but for the read path it won't hold the Fw caps and there is case
will it get the Fw reference.</Note>
    </Notes>
    <CVE>CVE-2024-50179</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fbdev: sisfb: Fix strbuf array overflow

The values of the variables xres and yres are placed in strbuf.
These variables are obtained from strbuf1.
The strbuf1 array contains digit characters
and a space if the array contains non-digit characters.
Then, when executing sprintf(strbuf, "%ux%ux8", xres, yres);
more than 16 bytes will be written to strbuf.
It is suggested to increase the size of the strbuf array to 24.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2024-50180</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2024-50181</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

secretmem: disable memfd_secret() if arch cannot set direct map

Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map().  This
is the case for example on some arm64 configurations, where marking 4k
PTEs in the direct map not present can only be done if the direct map is
set up at 4k granularity in the first place (as ARM's break-before-make
semantics do not easily allow breaking apart large/gigantic pages).

More precisely, on arm64 systems with !can_set_direct_map(),
set_direct_map_invalid_noflush() is a no-op, however it returns success
(0) instead of an error.  This means that memfd_secret will seemingly
"work" (e.g.  syscall succeeds, you can mmap the fd and fault in pages),
but it does not actually achieve its goal of removing its memory from the
direct map.

Note that with this patch, memfd_secret() will start erroring on systems
where can_set_direct_map() returns false (arm64 with
CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and
CONFIG_KFENCE=n), but that still seems better than the current silent
failure.  Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most
arm64 systems actually have a working memfd_secret() and aren't be
affected.

From going through the iterations of the original memfd_secret patch
series, it seems that disabling the syscall in these scenarios was the
intended behavior [1] (preferred over having
set_direct_map_invalid_noflush return an error as that would result in
SIGBUSes at page-fault time), however the check for it got dropped between
v16 [2] and v17 [3], when secretmem moved away from CMA allocations.

[1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/
[2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t
[3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/</Note>
    </Notes>
    <CVE>CVE-2024-50182</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance

Deleting an NPIV instance requires all fabric ndlps to be released before
an NPIV's resources can be torn down.  Failure to release fabric ndlps
beforehand opens kref imbalance race conditions.  Fix by forcing the DA_ID
to complete synchronously with usage of wait_queue.</Note>
    </Notes>
    <CVE>CVE-2024-50183</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

virtio_pmem: Check device status before requesting flush

If a pmem device is in a bad status, the driver side could wait for
host ack forever in virtio_pmem_flush(), causing the system to hang.

So add a status check in the beginning of virtio_pmem_flush() to return
early if the device is not activated.</Note>
    </Notes>
    <CVE>CVE-2024-50184</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: explicitly clear the sk pointer, when pf-&gt;create fails

We have recently noticed the exact same KASAN splat as in commit
6cd4a78d962b ("net: do not leave a dangling sk pointer, when socket
creation fails"). The problem is that commit did not fully address the
problem, as some pf-&gt;create implementations do not use sk_common_release
in their error paths.

For example, we can use the same reproducer as in the above commit, but
changing ping to arping. arping uses AF_PACKET socket and if packet_create
fails, it will just sk_free the allocated sk object.

While we could chase all the pf-&gt;create implementations and make sure they
NULL the freed sk object on error from the socket, we can't guarantee
future protocols will not make the same mistake.

So it is easier to just explicitly NULL the sk pointer upon return from
pf-&gt;create in __sock_create. We do know that pf-&gt;create always releases the
allocated sk object on error, so if the pointer is not NULL, it is
definitely dangling.</Note>
    </Notes>
    <CVE>CVE-2024-50186</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/vc4: Stop the active perfmon before being destroyed

Upon closing the file descriptor, the active performance monitor is not
stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`,
the active performance monitor's pointer (`vc4-&gt;active_perfmon`) is still
retained.

If we open a new file descriptor and submit a few jobs with performance
monitors, the driver will attempt to stop the active performance monitor
using the stale pointer in `vc4-&gt;active_perfmon`. However, this pointer
is no longer valid because the previous process has already terminated,
and all performance monitors associated with it have been destroyed and
freed.

To fix this, when the active performance monitor belongs to a given
process, explicitly stop it before destroying and freeing it.</Note>
    </Notes>
    <CVE>CVE-2024-50187</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: phy: dp83869: fix memory corruption when enabling fiber

When configuring the fiber port, the DP83869 PHY driver incorrectly
calls linkmode_set_bit() with a bit mask (1 &lt;&lt; 10) rather than a bit
number (10). This corrupts some other memory location -- in case of
arm64 the priv pointer in the same structure.

Since the advertising flags are updated from supported at the end of the
function the incorrect line isn't needed at all and can be removed.</Note>
    </Notes>
    <CVE>CVE-2024-50188</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

HID: amd_sfh: Switch to device-managed dmam_alloc_coherent()

Using the device-managed version allows to simplify clean-up in probe()
error path.

Additionally, this device-managed ensures proper cleanup, which helps to
resolve memory errors, page faults, btrfs going read-only, and btrfs
disk corruption.</Note>
    </Notes>
    <CVE>CVE-2024-50189</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

irqchip/gic-v4: Don't allow a VMOVP on a dying VPE

Kunkun Jiang reported that there is a small window of opportunity for
userspace to force a change of affinity for a VPE while the VPE has already
been unmapped, but the corresponding doorbell interrupt still visible in
/proc/irq/.

Plug the race by checking the value of vmapp_count, which tracks whether
the VPE is mapped ot not, and returning an error in this case.

This involves making vmapp_count common to both GICv4.1 and its v4.0
ancestor.</Note>
    </Notes>
    <CVE>CVE-2024-50192</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

arm64: probes: Fix uprobes for big-endian kernels

The arm64 uprobes code is broken for big-endian kernels as it doesn't
convert the in-memory instruction encoding (which is always
little-endian) into the kernel's native endianness before analyzing and
simulating instructions. This may result in a few distinct problems:

* The kernel may may erroneously reject probing an instruction which can
  safely be probed.

* The kernel may erroneously erroneously permit stepping an
  instruction out-of-line when that instruction cannot be stepped
  out-of-line safely.

* The kernel may erroneously simulate instruction incorrectly dur to
  interpretting the byte-swapped encoding.

The endianness mismatch isn't caught by the compiler or sparse because:

* The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so
  the compiler and sparse have no idea these contain a little-endian
  32-bit value. The core uprobes code populates these with a memcpy()
  which similarly does not handle endianness.

* While the uprobe_opcode_t type is an alias for __le32, both
  arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[]
  to the similarly-named probe_opcode_t, which is an alias for u32.
  Hence there is no endianness conversion warning.

Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and
adding the appropriate __le32_to_cpu() conversions prior to consuming
the instruction encoding. The core uprobes copies these fields as opaque
ranges of bytes, and so is unaffected by this change.

At the same time, remove MAX_UINSN_BYTES and consistently use
AARCH64_INSN_SIZE for clarity.

Tested with the following:

| #include &lt;stdio.h&gt;
| #include &lt;stdbool.h&gt;
|
| #define noinline __attribute__((noinline))
|
| static noinline void *adrp_self(void)
| {
|         void *addr;
|
|         asm volatile(
|         "       adrp    %x0, adrp_self\n"
|         "       add     %x0, %x0, :lo12:adrp_self\n"
|         : "=r" (addr));
| }
|
|
| int main(int argc, char *argv)
| {
|         void *ptr = adrp_self();
|         bool equal = (ptr == adrp_self);
|
|         printf("adrp_self   =&gt; %p\n"
|                "adrp_self() =&gt; %p\n"
|                "%s\n",
|                adrp_self, ptr, equal ? "EQUAL" : "NOT EQUAL");
|
|         return 0;
| }

.... where the adrp_self() function was compiled to:

| 00000000004007e0 &lt;adrp_self&gt;:
|   4007e0:       90000000        adrp    x0, 400000 &lt;__ehdr_start&gt;
|   4007e4:       911f8000        add     x0, x0, #0x7e0
|   4007e8:       d65f03c0        ret

Before this patch, the ADRP is not recognized, and is assumed to be
steppable, resulting in corruption of the result:

| # ./adrp-self
| adrp_self   =&gt; 0x4007e0
| adrp_self() =&gt; 0x4007e0
| EQUAL
| # echo 'p /root/adrp-self:0x007e0' &gt; /sys/kernel/tracing/uprobe_events
| # echo 1 &gt; /sys/kernel/tracing/events/uprobes/enable
| # ./adrp-self
| adrp_self   =&gt; 0x4007e0
| adrp_self() =&gt; 0xffffffffff7e0
| NOT EQUAL

After this patch, the ADRP is correctly recognized and simulated:

| # ./adrp-self
| adrp_self   =&gt; 0x4007e0
| adrp_self() =&gt; 0x4007e0
| EQUAL
| #
| # echo 'p /root/adrp-self:0x007e0' &gt; /sys/kernel/tracing/uprobe_events
| # echo 1 &gt; /sys/kernel/tracing/events/uprobes/enable
| # ./adrp-self
| adrp_self   =&gt; 0x4007e0
| adrp_self() =&gt; 0x4007e0
| EQUAL</Note>
    </Notes>
    <CVE>CVE-2024-50194</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

posix-clock: Fix missing timespec64 check in pc_clock_settime()

As Andrew pointed out, it will make sense that the PTP core
checked timespec64 struct's tv_sec and tv_nsec range before calling
ptp-&gt;info-&gt;settime64().

As the man manual of clock_settime() said, if tp.tv_sec is negative or
tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL,
which include dynamic clocks which handles PTP clock, and the condition is
consistent with timespec64_valid(). As Thomas suggested, timespec64_valid()
only check the timespec is valid, but not ensure that the time is
in a valid range, so check it ahead using timespec64_valid_strict()
in pc_clock_settime() and return -EINVAL if not valid.

There are some drivers that use tp-&gt;tv_sec and tp-&gt;tv_nsec directly to
write registers without validity checks and assume that the higher layer
has checked it, which is dangerous and will benefit from this, such as
hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(),
and some drivers can remove the checks of itself.</Note>
    </Notes>
    <CVE>CVE-2024-50195</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pinctrl: ocelot: fix system hang on level based interrupts

The current implementation only calls chained_irq_enter() and
chained_irq_exit() if it detects pending interrupts.

```
for (i = 0; i &lt; info-&gt;stride; i++) {
	uregmap_read(info-&gt;map, id_reg + 4 * i, &amp;reg);
	if (!reg)
		continue;

	chained_irq_enter(parent_chip, desc);
```

However, in case of GPIO pin configured in level mode and the parent
controller configured in edge mode, GPIO interrupt might be lowered by the
hardware. In the result, if the interrupt is short enough, the parent
interrupt is still pending while the GPIO interrupt is cleared;
chained_irq_enter() never gets called and the system hangs trying to
service the parent interrupt.

Moving chained_irq_enter() and chained_irq_exit() outside the for loop
ensures that they are called even when GPIO interrupt is lowered by the
hardware.

The similar code with chained_irq_enter() / chained_irq_exit() functions
wrapping interrupt checking loop may be found in many other drivers:
```
grep -r -A 10 chained_irq_enter drivers/pinctrl
```</Note>
    </Notes>
    <CVE>CVE-2024-50196</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iio: light: veml6030: fix IIO device retrieval from embedded device

The dev pointer that is received as an argument in the
in_illuminance_period_available_show function references the device
embedded in the IIO device, not in the i2c client.

dev_to_iio_dev() must be used to accessthe right data. The current
implementation leads to a segmentation fault on every attempt to read
the attribute because indio_dev gets a NULL assignment.

This bug has been present since the first appearance of the driver,
apparently since the last version (V6) before getting applied. A
constant attribute was used until then, and the last modifications might
have not been tested again.</Note>
    </Notes>
    <CVE>CVE-2024-50198</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

maple_tree: correct tree corruption on spanning store

Patch series "maple_tree: correct tree corruption on spanning store", v3.

There has been a nasty yet subtle maple tree corruption bug that appears
to have been in existence since the inception of the algorithm.

This bug seems far more likely to happen since commit f8d112a4e657
("mm/mmap: avoid zeroing vma tree in mmap_region()"), which is the point
at which reports started to be submitted concerning this bug.

We were made definitely aware of the bug thanks to the kind efforts of
Bert Karwatzki who helped enormously in my being able to track this down
and identify the cause of it.

The bug arises when an attempt is made to perform a spanning store across
two leaf nodes, where the right leaf node is the rightmost child of the
shared parent, AND the store completely consumes the right-mode node.

This results in mas_wr_spanning_store() mitakenly duplicating the new and
existing entries at the maximum pivot within the range, and thus maple
tree corruption.

The fix patch corrects this by detecting this scenario and disallowing the
mistaken duplicate copy.

The fix patch commit message goes into great detail as to how this occurs.

This series also includes a test which reliably reproduces the issue, and
asserts that the fix works correctly.

Bert has kindly tested the fix and confirmed it resolved his issues.  Also
Mikhail Gavrilov kindly reported what appears to be precisely the same
bug, which this fix should also resolve.


This patch (of 2):

There has been a subtle bug present in the maple tree implementation from
its inception.

This arises from how stores are performed - when a store occurs, it will
overwrite overlapping ranges and adjust the tree as necessary to
accommodate this.

A range may always ultimately span two leaf nodes.  In this instance we
walk the two leaf nodes, determine which elements are not overwritten to
the left and to the right of the start and end of the ranges respectively
and then rebalance the tree to contain these entries and the newly
inserted one.

This kind of store is dubbed a 'spanning store' and is implemented by
mas_wr_spanning_store().

In order to reach this stage, mas_store_gfp() invokes
mas_wr_preallocate(), mas_wr_store_type() and mas_wr_walk() in turn to
walk the tree and update the object (mas) to traverse to the location
where the write should be performed, determining its store type.

When a spanning store is required, this function returns false stopping at
the parent node which contains the target range, and mas_wr_store_type()
marks the mas-&gt;store_type as wr_spanning_store to denote this fact.

When we go to perform the store in mas_wr_spanning_store(), we first
determine the elements AFTER the END of the range we wish to store (that
is, to the right of the entry to be inserted) - we do this by walking to
the NEXT pivot in the tree (i.e.  r_mas.last + 1), starting at the node we
have just determined contains the range over which we intend to write.

We then turn our attention to the entries to the left of the entry we are
inserting, whose state is represented by l_mas, and copy these into a 'big
node', which is a special node which contains enough slots to contain two
leaf node's worth of data.

We then copy the entry we wish to store immediately after this - the copy
and the insertion of the new entry is performed by mas_store_b_node().

After this we copy the elements to the right of the end of the range which
we are inserting, if we have not exceeded the length of the node (i.e. 
r_mas.offset &lt;= r_mas.end).

Herein lies the bug - under very specific circumstances, this logic can
break and corrupt the maple tree.

Consider the following tree:

Height
  0                             Root Node
                                 /      \
                 pivot = 0xffff /        \ pivot = ULONG_MAX
                               /          
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-50200</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/radeon: Fix encoder-&gt;possible_clones

Include the encoder itself in its possible_clones bitmask.
In the past nothing validated that drivers were populating
possible_clones correctly, but that changed in commit
74d2aacbe840 ("drm: Validate encoder-&gt;possible_clones").
Looks like radeon never got the memo and is still not
following the rules 100% correctly.

This results in some warnings during driver initialization:
Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7)
WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c
...

(cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)</Note>
    </Notes>
    <CVE>CVE-2024-50201</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nilfs2: propagate directory read errors from nilfs_find_entry()

Syzbot reported that a task hang occurs in vcs_open() during a fuzzing
test for nilfs2.

The root cause of this problem is that in nilfs_find_entry(), which
searches for directory entries, ignores errors when loading a directory
page/folio via nilfs_get_folio() fails.

If the filesystem images is corrupted, and the i_size of the directory
inode is large, and the directory page/folio is successfully read but
fails the sanity check, for example when it is zero-filled,
nilfs_check_folio() may continue to spit out error messages in bursts.

Fix this issue by propagating the error to the callers when loading a
page/folio fails in nilfs_find_entry().

The current interface of nilfs_find_entry() and its callers is outdated
and cannot propagate error codes such as -EIO and -ENOMEM returned via
nilfs_find_entry(), so fix it together.</Note>
    </Notes>
    <CVE>CVE-2024-50202</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf, arm64: Fix address emission with tag-based KASAN enabled

When BPF_TRAMP_F_CALL_ORIG is enabled, the address of a bpf_tramp_image
struct on the stack is passed during the size calculation pass and
an address on the heap is passed during code generation. This may
cause a heap buffer overflow if the heap address is tagged because
emit_a64_mov_i64() will emit longer code than it did during the size
calculation pass. The same problem could occur without tag-based
KASAN if one of the 16-bit words of the stack address happened to
be all-ones during the size calculation pass. Fix the problem by
assuming the worst case (4 instructions) when calculating the size
of the bpf_tramp_image address emission.</Note>
    </Notes>
    <CVE>CVE-2024-50203</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-50205</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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 &gt; 256K.

There will be a single PDE page address (contiguous pages in the case of &gt;
PAGE_SIZE), but, current logic assumes multiple pages, leading to invalid
memory access after 256K PBL entries in the PDE.</Note>
    </Notes>
    <CVE>CVE-2024-50208</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/bnxt_re: Add a check for memory allocation

__alloc_pbl() can return error when memory allocation fails.
Driver is not checking the status on one of the instances.</Note>
    </Notes>
    <CVE>CVE-2024-50209</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

udf: refactor inode_bmap() to handle error

Refactor inode_bmap() to handle error since udf_next_aext() can return
error now. On situations like ftruncate, udf_extend_file() can now
detect errors and bail out early without resorting to checking for
particular offsets and assuming internal behavior of these functions.</Note>
    </Notes>
    <CVE>CVE-2024-50211</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nvmet-auth: assign dh_key to NULL after kfree_sensitive

ctrl-&gt;dh_key might be used across multiple calls to nvmet_setup_dhgroup()
for the same controller. So it's better to nullify it after release on
error path in order to avoid double free later in nvmet_destroy_auth().

Found by Linux Verification Center (linuxtesting.org) with Svace.</Note>
    </Notes>
    <CVE>CVE-2024-50215</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xfs: fix finding a last resort AG in xfs_filestream_pick_ag

When the main loop in xfs_filestream_pick_ag fails to find a suitable
AG it tries to just pick the online AG.  But the loop for that uses
args-&gt;pag as loop iterator while the later code expects pag to be
set.  Fix this by reusing the max_pag case for this last resort, and
also add a check for impossible case of no AG just to make sure that
the uninitialized pag doesn't even escape in theory.</Note>
    </Notes>
    <CVE>CVE-2024-50216</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow

Syzbot reported a kernel BUG in ocfs2_truncate_inline.  There are two
reasons for this: first, the parameter value passed is greater than
ocfs2_max_inline_data_with_xattr, second, the start and end parameters of
ocfs2_truncate_inline are "unsigned int".

So, we need to add a sanity check for byte_start and byte_len right before
ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater
than ocfs2_max_inline_data_with_xattr return -EINVAL.</Note>
    </Notes>
    <CVE>CVE-2024-50218</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/pm: Vangogh: Fix kernel memory out of bounds write

KASAN reports that the GPU metrics table allocated in
vangogh_tables_init() is not large enough for the memset done in
smu_cmn_init_soft_gpu_metrics(). Condensed report follows:

[   33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu]
[   33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067
...
[   33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G        W          6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544
[   33.861816] Tainted: [W]=WARN
[   33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023
[   33.861822] Call Trace:
[   33.861826]  &lt;TASK&gt;
[   33.861829]  dump_stack_lvl+0x66/0x90
[   33.861838]  print_report+0xce/0x620
[   33.861853]  kasan_report+0xda/0x110
[   33.862794]  kasan_check_range+0xfd/0x1a0
[   33.862799]  __asan_memset+0x23/0x40
[   33.862803]  smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]
[   33.863306]  vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]
[   33.864257]  vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]
[   33.865682]  amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]
[   33.866160]  amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779]
[   33.867135]  dev_attr_show+0x43/0xc0
[   33.867147]  sysfs_kf_seq_show+0x1f1/0x3b0
[   33.867155]  seq_read_iter+0x3f8/0x1140
[   33.867173]  vfs_read+0x76c/0xc50
[   33.867198]  ksys_read+0xfb/0x1d0
[   33.867214]  do_syscall_64+0x90/0x160
...
[   33.867353] Allocated by task 378 on cpu 7 at 22.794876s:
[   33.867358]  kasan_save_stack+0x33/0x50
[   33.867364]  kasan_save_track+0x17/0x60
[   33.867367]  __kasan_kmalloc+0x87/0x90
[   33.867371]  vangogh_init_smc_tables+0x3f9/0x840 [amdgpu]
[   33.867835]  smu_sw_init+0xa32/0x1850 [amdgpu]
[   33.868299]  amdgpu_device_init+0x467b/0x8d90 [amdgpu]
[   33.868733]  amdgpu_driver_load_kms+0x19/0xf0 [amdgpu]
[   33.869167]  amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu]
[   33.869608]  local_pci_probe+0xda/0x180
[   33.869614]  pci_device_probe+0x43f/0x6b0

Empirically we can confirm that the former allocates 152 bytes for the
table, while the latter memsets the 168 large block.

Root cause appears that when GPU metrics tables for v2_4 parts were added
it was not considered to enlarge the table to fit.

The fix in this patch is rather "brute force" and perhaps later should be
done in a smarter way, by extracting and consolidating the part version to
size logic to a common helper, instead of brute forcing the largest
possible allocation. Nevertheless, for now this works and fixes the out of
bounds write.

v2:
 * Drop impossible v3_0 case. (Mario)

(cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703)</Note>
    </Notes>
    <CVE>CVE-2024-50221</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

spi: spi-fsl-dspi: Fix crash when not using GPIO chip select

Add check for the return value of spi_get_csgpiod() to avoid passing a NULL
pointer to gpiod_direction_output(), preventing a crash when GPIO chip
select is not used.

Fix below crash:
[    4.251960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[    4.260762] Mem abort info:
[    4.263556]   ESR = 0x0000000096000004
[    4.267308]   EC = 0x25: DABT (current EL), IL = 32 bits
[    4.272624]   SET = 0, FnV = 0
[    4.275681]   EA = 0, S1PTW = 0
[    4.278822]   FSC = 0x04: level 0 translation fault
[    4.283704] Data abort info:
[    4.286583]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[    4.292074]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[    4.297130]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[    4.302445] [0000000000000000] user address but active_mm is swapper
[    4.308805] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
[    4.315072] Modules linked in:
[    4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359
[    4.328130] Hardware name: LS1046A QDS Board (DT)
[    4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    4.339794] pc : gpiod_direction_output+0x34/0x5c
[    4.344505] lr : gpiod_direction_output+0x18/0x5c
[    4.349208] sp : ffff80008003b8f0
[    4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068
[    4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810
[    4.366800] x23: 0000000000000000 x22: 0000000011e1a300 x21: 0000000000020002
[    4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff
[    4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007
[    4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e
[    4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9 : 0000000000000008
[    4.402502] x8 : 0000000000000002 x7 : 0000000000000007 x6 : 0000000000000000
[    4.409641] x5 : 0000000000000200 x4 : 0000000002000000 x3 : 0000000000000000
[    4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000
[    4.423921] Call trace:
[    4.426362]  gpiod_direction_output+0x34/0x5c (P)
[    4.431067]  gpiod_direction_output+0x18/0x5c (L)
[    4.435771]  dspi_setup+0x220/0x334</Note>
    </Notes>
    <CVE>CVE-2024-50224</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix error propagation of split bios

The purpose of btrfs_bbio_propagate_error() shall be propagating an error
of split bio to its original btrfs_bio, and tell the error to the upper
layer. However, it's not working well on some cases.

* Case 1. Immediate (or quick) end_bio with an error

When btrfs sends btrfs_bio to mirrored devices, btrfs calls
btrfs_bio_end_io() when all the mirroring bios are completed. If that
btrfs_bio was split, it is from btrfs_clone_bioset and its end_io function
is btrfs_orig_write_end_io. For this case, btrfs_bbio_propagate_error()
accesses the orig_bbio's bio context to increase the error count.

That works well in most cases. However, if the end_io is called enough
fast, orig_bbio's (remaining part after split) bio context may not be
properly set at that time. Since the bio context is set when the orig_bbio
(the last btrfs_bio) is sent to devices, that might be too late for earlier
split btrfs_bio's completion.  That will result in NULL pointer
dereference.

That bug is easily reproducible by running btrfs/146 on zoned devices [1]
and it shows the following trace.

[1] You need raid-stripe-tree feature as it create "-d raid0 -m raid1" FS.

  BUG: kernel NULL pointer dereference, address: 0000000000000020
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: Oops: 0000 [#1] PREEMPT SMP PTI
  CPU: 1 UID: 0 PID: 13 Comm: kworker/u32:1 Not tainted 6.11.0-rc7-BTRFS-ZNS+ #474
  Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
  Workqueue: writeback wb_workfn (flush-btrfs-5)
  RIP: 0010:btrfs_bio_end_io+0xae/0xc0 [btrfs]
  BTRFS error (device dm-0): bdev /dev/mapper/error-test errs: wr 2, rd 0, flush 0, corrupt 0, gen 0
  RSP: 0018:ffffc9000006f248 EFLAGS: 00010246
  RAX: 0000000000000000 RBX: ffff888005a7f080 RCX: ffffc9000006f1dc
  RDX: 0000000000000000 RSI: 000000000000000a RDI: ffff888005a7f080
  RBP: ffff888011dfc540 R08: 0000000000000000 R09: 0000000000000001
  R10: ffffffff82e508e0 R11: 0000000000000005 R12: ffff88800ddfbe58
  R13: ffff888005a7f080 R14: ffff888005a7f158 R15: ffff888005a7f158
  FS:  0000000000000000(0000) GS:ffff88803ea80000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000020 CR3: 0000000002e22006 CR4: 0000000000370ef0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  Call Trace:
   &lt;TASK&gt;
   ? __die_body.cold+0x19/0x26
   ? page_fault_oops+0x13e/0x2b0
   ? _printk+0x58/0x73
   ? do_user_addr_fault+0x5f/0x750
   ? exc_page_fault+0x76/0x240
   ? asm_exc_page_fault+0x22/0x30
   ? btrfs_bio_end_io+0xae/0xc0 [btrfs]
   ? btrfs_log_dev_io_error+0x7f/0x90 [btrfs]
   btrfs_orig_write_end_io+0x51/0x90 [btrfs]
   dm_submit_bio+0x5c2/0xa50 [dm_mod]
   ? find_held_lock+0x2b/0x80
   ? blk_try_enter_queue+0x90/0x1e0
   __submit_bio+0xe0/0x130
   ? ktime_get+0x10a/0x160
   ? lockdep_hardirqs_on+0x74/0x100
   submit_bio_noacct_nocheck+0x199/0x410
   btrfs_submit_bio+0x7d/0x150 [btrfs]
   btrfs_submit_chunk+0x1a1/0x6d0 [btrfs]
   ? lockdep_hardirqs_on+0x74/0x100
   ? __folio_start_writeback+0x10/0x2c0
   btrfs_submit_bbio+0x1c/0x40 [btrfs]
   submit_one_bio+0x44/0x60 [btrfs]
   submit_extent_folio+0x13f/0x330 [btrfs]
   ? btrfs_set_range_writeback+0xa3/0xd0 [btrfs]
   extent_writepage_io+0x18b/0x360 [btrfs]
   extent_write_locked_range+0x17c/0x340 [btrfs]
   ? __pfx_end_bbio_data_write+0x10/0x10 [btrfs]
   run_delalloc_cow+0x71/0xd0 [btrfs]
   btrfs_run_delalloc_range+0x176/0x500 [btrfs]
   ? find_lock_delalloc_range+0x119/0x260 [btrfs]
   writepage_delalloc+0x2ab/0x480 [btrfs]
   extent_write_cache_pages+0x236/0x7d0 [btrfs]
   btrfs_writepages+0x72/0x130 [btrfs]
   do_writepages+0xd4/0x240
   ? find_held_lock+0x2b/0x80
   ? wbc_attach_and_unlock_inode+0x12c/0x290
   ? wbc_attach_and_unlock_inode+0x12c/0x29
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-50225</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2024-50228</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix potential deadlock with newly created symlinks

Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers
memory reclamation involving the filesystem layer, which can result in
circular lock dependencies among the reader/writer semaphore
nilfs-&gt;ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the
fs_reclaim pseudo lock.

This is because after commit 21fc61c73c39 ("don't put symlink bodies in
pagecache into highmem"), the gfp flags of the page cache for symbolic
links are overwritten to GFP_KERNEL via inode_nohighmem().

This is not a problem for symlinks read from the backing device, because
the __GFP_FS flag is dropped after inode_nohighmem() is called.  However,
when a new symlink is created with nilfs_symlink(), the gfp flags remain
overwritten to GFP_KERNEL.  Then, memory allocation called from
page_symlink() etc.  triggers memory reclamation including the FS layer,
which may call nilfs_evict_inode() or nilfs_dirty_inode().  And these can
cause a deadlock if they are called while nilfs-&gt;ns_segctor_sem is held:

Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags
of newly created symlinks in the same way that nilfs_new_inode() and
__nilfs_read_inode() do, as a workaround until we adopt nofs allocation
scope consistently or improve the locking constraints.</Note>
    </Notes>
    <CVE>CVE-2024-50229</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix kernel bug due to missing clearing of checked flag

Syzbot reported that in directory operations after nilfs2 detects
filesystem corruption and degrades to read-only,
__block_write_begin_int(), which is called to prepare block writes, may
fail the BUG_ON check for accesses exceeding the folio/page size,
triggering a kernel bug.

This was found to be because the "checked" flag of a page/folio was not
cleared when it was discarded by nilfs2's own routine, which causes the
sanity check of directory entries to be skipped when the directory
page/folio is reloaded.  So, fix that.

This was necessary when the use of nilfs2's own page discard routine was
applied to more than just metadata files.</Note>
    </Notes>
    <CVE>CVE-2024-50230</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table()

modprobe iio-test-gts and rmmod it, then the following memory leak
occurs:

	unreferenced object 0xffffff80c810be00 (size 64):
	  comm "kunit_try_catch", pid 1654, jiffies 4294913981
	  hex dump (first 32 bytes):
	    02 00 00 00 08 00 00 00 20 00 00 00 40 00 00 00  ........ ...@...
	    80 00 00 00 00 02 00 00 00 04 00 00 00 08 00 00  ................
	  backtrace (crc a63d875e):
	    [&lt;0000000028c1b3c2&gt;] kmemleak_alloc+0x34/0x40
	    [&lt;000000001d6ecc87&gt;] __kmalloc_noprof+0x2bc/0x3c0
	    [&lt;00000000393795c1&gt;] devm_iio_init_iio_gts+0x4b4/0x16f4
	    [&lt;0000000071bb4b09&gt;] 0xffffffdf052a62e0
	    [&lt;000000000315bc18&gt;] 0xffffffdf052a6488
	    [&lt;00000000f9dc55b5&gt;] kunit_try_run_case+0x13c/0x3ac
	    [&lt;00000000175a3fd4&gt;] kunit_generic_run_threadfn_adapter+0x80/0xec
	    [&lt;00000000f505065d&gt;] kthread+0x2e8/0x374
	    [&lt;00000000bbfb0e5d&gt;] ret_from_fork+0x10/0x20
	unreferenced object 0xffffff80cbfe9e70 (size 16):
	  comm "kunit_try_catch", pid 1658, jiffies 4294914015
	  hex dump (first 16 bytes):
	    10 00 00 00 40 00 00 00 80 00 00 00 00 00 00 00  ....@...........
	  backtrace (crc 857f0cb4):
	    [&lt;0000000028c1b3c2&gt;] kmemleak_alloc+0x34/0x40
	    [&lt;000000001d6ecc87&gt;] __kmalloc_noprof+0x2bc/0x3c0
	    [&lt;00000000393795c1&gt;] devm_iio_init_iio_gts+0x4b4/0x16f4
	    [&lt;0000000071bb4b09&gt;] 0xffffffdf052a62e0
	    [&lt;000000007d089d45&gt;] 0xffffffdf052a6864
	    [&lt;00000000f9dc55b5&gt;] kunit_try_run_case+0x13c/0x3ac
	    [&lt;00000000175a3fd4&gt;] kunit_generic_run_threadfn_adapter+0x80/0xec
	    [&lt;00000000f505065d&gt;] kthread+0x2e8/0x374
	    [&lt;00000000bbfb0e5d&gt;] ret_from_fork+0x10/0x20
	......

It includes 5*5 times "size 64" memory leaks, which correspond to 5 times
test_init_iio_gain_scale() calls with gts_test_gains size 10 (10*size(int))
and gts_test_itimes size 5. It also includes 5*1 times "size 16"
memory leak, which correspond to one time __test_init_iio_gain_scale()
call with gts_test_gains_gain_low size 3 (3*size(int)) and gts_test_itimes
size 5.

The reason is that the per_time_gains[i] is not freed which is allocated in
the "gts-&gt;num_itime" for loop in iio_gts_build_avail_scale_table().</Note>
    </Notes>
    <CVE>CVE-2024-50231</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr()

In the ad7124_write_raw() function, parameter val can potentially
be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST()
is called within ad7124_set_channel_odr(). The ad7124_write_raw()
function is invoked through the sequence: iio_write_channel_raw() -&gt;
iio_write_channel_attribute() -&gt; iio_channel_write(), with no checks
in place to ensure val is non-zero.</Note>
    </Notes>
    <CVE>CVE-2024-50232</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg()

In the ad9832_write_frequency() function, clk_get_rate() might return 0.
This can lead to a division by zero when calling ad9832_calc_freqreg().
The check if (fout &gt; (clk_get_rate(st-&gt;mclk) / 2)) does not protect
against the case when fout is 0. The ad9832_write_frequency() function
is called from ad9832_write(), and fout is derived from a text buffer,
which can contain any value.</Note>
    </Notes>
    <CVE>CVE-2024-50233</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlegacy: Clear stale interrupts before resuming device

iwl4965 fails upon resume from hibernation on my laptop. The reason
seems to be a stale interrupt which isn't being cleared out before
interrupts are enabled. We end up with a race beween the resume
trying to bring things back up, and the restart work (queued form
the interrupt handler) trying to bring things down. Eventually
the whole thing blows up.

Fix the problem by clearing out any stale interrupts before
interrupts get enabled during resume.

Here's a debug log of the indicent:
[   12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000
[   12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000
[   12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio.
[   12.042653] iwl4965 0000:10:00.0: On demand firmware reload
[   12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282
[   12.052207] ieee80211 phy0: il4965_mac_start enter
[   12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff
[   12.052244] ieee80211 phy0: il4965_set_hw_ready hardware  ready
[   12.052324] ieee80211 phy0: il_apm_init Init card's basic functions
[   12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S
[   12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm
[   12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm
[   12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK
[   12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations
[   12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up
[   12.058737] ieee80211 phy0: il4965_mac_start Start UP work done.
[   12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down
[   12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout
[   12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort
[   12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver
[   12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared
[   12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state
[   12.058827] ieee80211 phy0: _il_apm_stop_master stop master
[   12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear.
[   12.058869] ieee80211 phy0: Hardware restart was requested
[   16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms.
[   16.132303] ------------[ cut here ]------------
[   16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue.
[   16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211]
[   16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev
[   16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143
[   16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010
[   16.132463] Workqueue: async async_run_entry_fn
[   16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211]
[   16.132501] Code: da 02 00 0
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-50234</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: cfg80211: clear wdev-&gt;cqm_config pointer on free

When we free wdev-&gt;cqm_config when unregistering, we also
need to clear out the pointer since the same wdev/netdev
may get re-registered in another network namespace, then
destroyed later, running this code again, which results in
a double-free.</Note>
    </Notes>
    <CVE>CVE-2024-50235</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath10k: Fix memory leak in management tx

In the current logic, memory is allocated for storing the MSDU context
during management packet TX but this memory is not being freed during
management TX completion. Similar leaks are seen in the management TX
cleanup logic.

Kmemleak reports this problem as below,

unreferenced object 0xffffff80b64ed250 (size 16):
  comm "kworker/u16:7", pid 148, jiffies 4294687130 (age 714.199s)
  hex dump (first 16 bytes):
    00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00  .+.......t......
  backtrace:
    [&lt;ffffffe6e7b245dc&gt;] __kmem_cache_alloc_node+0x1e4/0x2d8
    [&lt;ffffffe6e7adde88&gt;] kmalloc_trace+0x48/0x110
    [&lt;ffffffe6bbd765fc&gt;] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core]
    [&lt;ffffffe6bbd3eed4&gt;] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core]
    [&lt;ffffffe6e78d5974&gt;] process_scheduled_works+0x1ac/0x400
    [&lt;ffffffe6e78d60b8&gt;] worker_thread+0x208/0x328
    [&lt;ffffffe6e78dc890&gt;] kthread+0x100/0x1c0
    [&lt;ffffffe6e78166c0&gt;] ret_from_fork+0x10/0x20

Free the memory during completion and cleanup to fix the leak.

Protect the mgmt_pending_tx idr_remove() operation in
ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar-&gt;data_lock similar to
other instances.

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1</Note>
    </Notes>
    <CVE>CVE-2024-50236</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower

Avoid potentially crashing in the driver because of uninitialized private data</Note>
    </Notes>
    <CVE>CVE-2024-50237</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

phy: qcom: qmp-usb: fix NULL-deref on runtime suspend

Commit 413db06c05e7 ("phy: qcom-qmp-usb: clean up probe initialisation")
removed most users of the platform device driver data, but mistakenly
also removed the initialisation despite the data still being used in the
runtime PM callbacks.

Restore the driver data initialisation at probe to avoid a NULL-pointer
dereference on runtime suspend.

Apparently no one uses runtime PM, which currently needs to be enabled
manually through sysfs, with this driver.</Note>
    </Notes>
    <CVE>CVE-2024-50240</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Fix possible deadlock in mi_read

Mutex lock with another subclass used in ni_lock_dir().</Note>
    </Notes>
    <CVE>CVE-2024-50245</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Add rough attr alloc_size check</Note>
    </Notes>
    <CVE>CVE-2024-50246</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ntfs3: Add bounds checking to mi_enum_attr()

Added bounds checking to make sure that every attr don't stray beyond
valid memory region.</Note>
    </Notes>
    <CVE>CVE-2024-50248</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ACPI: CPPC: Make rmw_lock a raw_spin_lock

The following BUG was triggered:

=============================
[ BUG: Invalid wait context ]
6.12.0-rc2-XXX #406 Not tainted
-----------------------------
kworker/1:1/62 is trying to lock:
ffffff8801593030 (&amp;cpc_ptr-&gt;rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370
other info that might help us debug this:
context-{5:5}
2 locks held by kworker/1:1/62:
  #0: ffffff897ef5ec98 (&amp;rq-&gt;__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50
  #1: ffffff880154e238 (&amp;sg_policy-&gt;update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280
stack backtrace:
CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406
Workqueue:  0x0 (events)
Call trace:
  dump_backtrace+0xa4/0x130
  show_stack+0x20/0x38
  dump_stack_lvl+0x90/0xd0
  dump_stack+0x18/0x28
  __lock_acquire+0x480/0x1ad8
  lock_acquire+0x114/0x310
  _raw_spin_lock+0x50/0x70
  cpc_write+0xcc/0x370
  cppc_set_perf+0xa0/0x3a8
  cppc_cpufreq_fast_switch+0x40/0xc0
  cpufreq_driver_fast_switch+0x4c/0x218
  sugov_update_shared+0x234/0x280
  update_load_avg+0x6ec/0x7b8
  dequeue_entities+0x108/0x830
  dequeue_task_fair+0x58/0x408
  __schedule+0x4f0/0x1070
  schedule+0x54/0x130
  worker_thread+0xc0/0x2e8
  kthread+0x130/0x148
  ret_from_fork+0x10/0x20

sugov_update_shared() locks a raw_spinlock while cpc_write() locks a
spinlock.

To have a correct wait-type order, update rmw_lock to a raw spinlock and
ensure that interrupts will be disabled on the CPU holding it.

[ rjw: Changelog edits ]</Note>
    </Notes>
    <CVE>CVE-2024-50249</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fsdax: dax_unshare_iter needs to copy entire blocks

The code that copies data from srcmap to iomap in dax_unshare_iter is
very very broken, which bfoster's recent fsx changes have exposed.

If the pos and len passed to dax_file_unshare are not aligned to an
fsblock boundary, the iter pos and length in the _iter function will
reflect this unalignment.

dax_iomap_direct_access always returns a pointer to the start of the
kmapped fsdax page, even if its pos argument is in the middle of that
page.  This is catastrophic for data integrity when iter-&gt;pos is not
aligned to a page, because daddr/saddr do not point to the same byte in
the file as iter-&gt;pos.  Hence we corrupt user data by copying it to the
wrong place.

If iter-&gt;pos + iomap_length() in the _iter function not aligned to a
page, then we fail to copy a full block, and only partially populate the
destination block.  This is catastrophic for data confidentiality
because we expose stale pmem contents.

Fix both of these issues by aligning copy_pos/copy_len to a page
boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that
we always copy full blocks.

We're not done yet -- there's no call to invalidate_inode_pages2_range,
so programs that have the file range mmap'd will continue accessing the
old memory mapping after the file metadata updates have completed.

Be careful with the return value -- if the unshare succeeds, we still
need to return the number of bytes that the iomap iter thinks we're
operating on.</Note>
    </Notes>
    <CVE>CVE-2024-50250</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address

The device stores IPv6 addresses that are used for encapsulation in
linear memory that is managed by the driver.

Changing the remote address of an ip6gre net device never worked
properly, but since cited commit the following reproducer [1] would
result in a warning [2] and a memory leak [3]. The problem is that the
new remote address is never added by the driver to its hash table (and
therefore the device) and the old address is never removed from it.

Fix by programming the new address when the configuration of the ip6gre
net device changes and removing the old one. If the address did not
change, then the above would result in increasing the reference count of
the address and then decreasing it.

[1]
 # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit
 # ip link set dev bla type ip6gre remote 2001:db8:3::1
 # ip link del dev bla
 # devlink dev reload pci/0000:01:00.0

[2]
WARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0
Modules linked in:
CPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151
Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023
RIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0
[...]
Call Trace:
 &lt;TASK&gt;
 mlxsw_sp_router_netdevice_event+0x55f/0x1240
 notifier_call_chain+0x5a/0xd0
 call_netdevice_notifiers_info+0x39/0x90
 unregister_netdevice_many_notify+0x63e/0x9d0
 rtnl_dellink+0x16b/0x3a0
 rtnetlink_rcv_msg+0x142/0x3f0
 netlink_rcv_skb+0x50/0x100
 netlink_unicast+0x242/0x390
 netlink_sendmsg+0x1de/0x420
 ____sys_sendmsg+0x2bd/0x320
 ___sys_sendmsg+0x9a/0xe0
 __sys_sendmsg+0x7a/0xd0
 do_syscall_64+0x9e/0x1a0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

[3]
unreferenced object 0xffff898081f597a0 (size 32):
  comm "ip", pid 1626, jiffies 4294719324
  hex dump (first 32 bytes):
    20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01   ...............
    21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00  !Ia.............
  backtrace (crc fd9be911):
    [&lt;00000000df89c55d&gt;] __kmalloc_cache_noprof+0x1da/0x260
    [&lt;00000000ff2a1ddb&gt;] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340
    [&lt;000000009ddd445d&gt;] mlxsw_sp_router_netdevice_event+0x47b/0x1240
    [&lt;00000000743e7757&gt;] notifier_call_chain+0x5a/0xd0
    [&lt;000000007c7b9e13&gt;] call_netdevice_notifiers_info+0x39/0x90
    [&lt;000000002509645d&gt;] register_netdevice+0x5f7/0x7a0
    [&lt;00000000c2e7d2a9&gt;] ip6gre_newlink_common.isra.0+0x65/0x130
    [&lt;0000000087cd6d8d&gt;] ip6gre_newlink+0x72/0x120
    [&lt;000000004df7c7cc&gt;] rtnl_newlink+0x471/0xa20
    [&lt;0000000057ed632a&gt;] rtnetlink_rcv_msg+0x142/0x3f0
    [&lt;0000000032e0d5b5&gt;] netlink_rcv_skb+0x50/0x100
    [&lt;00000000908bca63&gt;] netlink_unicast+0x242/0x390
    [&lt;00000000cdbe1c87&gt;] netlink_sendmsg+0x1de/0x420
    [&lt;0000000011db153e&gt;] ____sys_sendmsg+0x2bd/0x320
    [&lt;000000003b6d53eb&gt;] ___sys_sendmsg+0x9a/0xe0
    [&lt;00000000cae27c62&gt;] __sys_sendmsg+0x7a/0xd0</Note>
    </Notes>
    <CVE>CVE-2024-50252</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs

Fix __hci_cmd_sync_sk() to return not NULL for unknown opcodes.

__hci_cmd_sync_sk() returns NULL if a command returns a status event.
However, it also returns NULL where an opcode doesn't exist in the
hci_cc table because hci_cmd_complete_evt() assumes status = skb-&gt;data[0]
for unknown opcodes.
This leads to null-ptr-deref in cmd_sync for HCI_OP_READ_LOCAL_CODECS as
there is no hci_cc for HCI_OP_READ_LOCAL_CODECS, which always assumes
status = skb-&gt;data[0].

KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]
CPU: 1 PID: 2000 Comm: kworker/u9:5 Not tainted 6.9.0-ga6bcb805883c-dirty #10
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Workqueue: hci7 hci_power_on
RIP: 0010:hci_read_supported_codecs+0xb9/0x870 net/bluetooth/hci_codec.c:138
Code: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 &lt;0f&gt; b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78
RSP: 0018:ffff888120bafac8 EFLAGS: 00010212
RAX: 0000000000000000 RBX: 000000000000000e RCX: ffff8881173f0040
RDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4
RBP: ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054
R10: dffffc0000000000 R11: fffffbfff4ef1055 R12: 0000000000000070
R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000
FS:  0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [inline]
 hci_init_stage_sync net/bluetooth/hci_sync.c:3441 [inline]
 hci_init4_sync net/bluetooth/hci_sync.c:4706 [inline]
 hci_init_sync net/bluetooth/hci_sync.c:4742 [inline]
 hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [inline]
 hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994
 hci_dev_do_open net/bluetooth/hci_core.c:483 [inline]
 hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015
 process_one_work kernel/workqueue.c:3267 [inline]
 process_scheduled_works+0x8ef/0x14f0 kernel/workqueue.c:3348
 worker_thread+0x91f/0xe50 kernel/workqueue.c:3429
 kthread+0x2cb/0x360 kernel/kthread.c:388
 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244</Note>
    </Notes>
    <CVE>CVE-2024-50255</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()

I got a syzbot report without a repro [1] crashing in nf_send_reset6()

I think the issue is that dev-&gt;hard_header_len is zero, and we attempt
later to push an Ethernet header.

Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c.

[1]

skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun
 kernel BUG at net/core/skbuff.c:206 !
Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]
 RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216
Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 &lt;0f&gt; 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3
RSP: 0018:ffffc900045269b0 EFLAGS: 00010282
RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800
RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000
RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc
R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140
R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c
FS:  00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
  skb_push+0xe5/0x100 net/core/skbuff.c:2636
  eth_header+0x38/0x1f0 net/ethernet/eth.c:83
  dev_hard_header include/linux/netdevice.h:3208 [inline]
  nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358
  nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48
  expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
  nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288
  nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161
  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
  nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626
  nf_hook include/linux/netfilter.h:269 [inline]
  NF_HOOK include/linux/netfilter.h:312 [inline]
  br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184
  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
  nf_hook_bridge_pre net/bridge/br_input.c:277 [inline]
  br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424
  __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562
  __netif_receive_skb_one_core net/core/dev.c:5666 [inline]
  __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781
  netif_receive_skb_internal net/core/dev.c:5867 [inline]
  netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926
  tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550
  tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007
  tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053
  new_sync_write fs/read_write.c:590 [inline]
  vfs_write+0xa6d/0xc90 fs/read_write.c:683
  ksys_write+0x183/0x2b0 fs/read_write.c:736
  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
RIP: 0033:0x7fdbeeb7d1ff
Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48
RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff
RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8
RBP: 00007fdbeebf12be R08: 0000000
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-50256</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: Fix use-after-free in get_info()

ip6table_nat module unload has refcnt warning for UAF. call trace is:

WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80
Modules linked in: ip6table_nat(-)
CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:module_put+0x6f/0x80
Call Trace:
 &lt;TASK&gt;
 get_info+0x128/0x180
 do_ip6t_get_ctl+0x6a/0x430
 nf_getsockopt+0x46/0x80
 ipv6_getsockopt+0xb9/0x100
 rawv6_getsockopt+0x42/0x190
 do_sock_getsockopt+0xaa/0x180
 __sys_getsockopt+0x70/0xc0
 __x64_sys_getsockopt+0x20/0x30
 do_syscall_64+0xa2/0x1a0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Concurrent execution of module unload and get_info() trigered the warning.
The root cause is as follows:

cpu0				      cpu1
module_exit
//mod-&gt;state = MODULE_STATE_GOING
  ip6table_nat_exit
    xt_unregister_template
	kfree(t)
	//removed from templ_list
				      getinfo()
					  t = xt_find_table_lock
						list_for_each_entry(tmpl, &amp;xt_templates[af]...)
							if (strcmp(tmpl-&gt;name, name))
								continue;  //table not found
							try_module_get
						list_for_each_entry(t, &amp;xt_net-&gt;tables[af]...)
							return t;  //not get refcnt
					  module_put(t-&gt;me) //uaf
    unregister_pernet_subsys
    //remove table from xt_net list

While xt_table module was going away and has been removed from
xt_templates list, we couldnt get refcnt of xt_table-&gt;me. Check
module in xt_net-&gt;tables list re-traversal to fix it.</Note>
    </Notes>
    <CVE>CVE-2024-50257</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

macsec: Fix use-after-free while sending the offloading packet

KASAN reports the following UAF. The metadata_dst, which is used to
store the SCI value for macsec offload, is already freed by
metadata_dst_free() in macsec_free_netdev(), while driver still use it
for sending the packet.

To fix this issue, dst_release() is used instead to release
metadata_dst. So it is not freed instantly in macsec_free_netdev() if
still referenced by skb.

 BUG: KASAN: slab-use-after-free in mlx5e_xmit+0x1e8f/0x4190 [mlx5_core]
 Read of size 2 at addr ffff88813e42e038 by task kworker/7:2/714
 [...]
 Workqueue: mld mld_ifc_work
 Call Trace:
  &lt;TASK&gt;
  dump_stack_lvl+0x51/0x60
  print_report+0xc1/0x600
  kasan_report+0xab/0xe0
  mlx5e_xmit+0x1e8f/0x4190 [mlx5_core]
  dev_hard_start_xmit+0x120/0x530
  sch_direct_xmit+0x149/0x11e0
  __qdisc_run+0x3ad/0x1730
  __dev_queue_xmit+0x1196/0x2ed0
  vlan_dev_hard_start_xmit+0x32e/0x510 [8021q]
  dev_hard_start_xmit+0x120/0x530
  __dev_queue_xmit+0x14a7/0x2ed0
  macsec_start_xmit+0x13e9/0x2340
  dev_hard_start_xmit+0x120/0x530
  __dev_queue_xmit+0x14a7/0x2ed0
  ip6_finish_output2+0x923/0x1a70
  ip6_finish_output+0x2d7/0x970
  ip6_output+0x1ce/0x3a0
  NF_HOOK.constprop.0+0x15f/0x190
  mld_sendpack+0x59a/0xbd0
  mld_ifc_work+0x48a/0xa80
  process_one_work+0x5aa/0xe50
  worker_thread+0x79c/0x1290
  kthread+0x28f/0x350
  ret_from_fork+0x2d/0x70
  ret_from_fork_asm+0x11/0x20
  &lt;/TASK&gt;

 Allocated by task 3922:
  kasan_save_stack+0x20/0x40
  kasan_save_track+0x10/0x30
  __kasan_kmalloc+0x77/0x90
  __kmalloc_noprof+0x188/0x400
  metadata_dst_alloc+0x1f/0x4e0
  macsec_newlink+0x914/0x1410
  __rtnl_newlink+0xe08/0x15b0
  rtnl_newlink+0x5f/0x90
  rtnetlink_rcv_msg+0x667/0xa80
  netlink_rcv_skb+0x12c/0x360
  netlink_unicast+0x551/0x770
  netlink_sendmsg+0x72d/0xbd0
  __sock_sendmsg+0xc5/0x190
  ____sys_sendmsg+0x52e/0x6a0
  ___sys_sendmsg+0xeb/0x170
  __sys_sendmsg+0xb5/0x140
  do_syscall_64+0x4c/0x100
  entry_SYSCALL_64_after_hwframe+0x4b/0x53

 Freed by task 4011:
  kasan_save_stack+0x20/0x40
  kasan_save_track+0x10/0x30
  kasan_save_free_info+0x37/0x50
  poison_slab_object+0x10c/0x190
  __kasan_slab_free+0x11/0x30
  kfree+0xe0/0x290
  macsec_free_netdev+0x3f/0x140
  netdev_run_todo+0x450/0xc70
  rtnetlink_rcv_msg+0x66f/0xa80
  netlink_rcv_skb+0x12c/0x360
  netlink_unicast+0x551/0x770
  netlink_sendmsg+0x72d/0xbd0
  __sock_sendmsg+0xc5/0x190
  ____sys_sendmsg+0x52e/0x6a0
  ___sys_sendmsg+0xeb/0x170
  __sys_sendmsg+0xb5/0x140
  do_syscall_64+0x4c/0x100
  entry_SYSCALL_64_after_hwframe+0x4b/0x53</Note>
    </Notes>
    <CVE>CVE-2024-50261</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix out-of-bounds write in trie_get_next_key()

trie_get_next_key() allocates a node stack with size trie-&gt;max_prefixlen,
while it writes (trie-&gt;max_prefixlen + 1) nodes to the stack when it has
full paths from the root to leaves. For example, consider a trie with
max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ...
0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with
.prefixlen = 8 make 9 nodes be written on the node stack with size 8.</Note>
    </Notes>
    <CVE>CVE-2024-50262</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vsock/virtio: Initialization of the dangling pointer occurring in vsk-&gt;trans

During loopback communication, a dangling pointer can be created in
vsk-&gt;trans, potentially leading to a Use-After-Free condition.  This
issue is resolved by initializing vsk-&gt;trans to NULL.</Note>
    </Notes>
    <CVE>CVE-2024-50264</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove()

Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove():

[   57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12
[   57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper.  Leaking 1 clusters and removing the entry
[   57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004
[...]
[   57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0
[...]
[   57.331328] Call Trace:
[   57.331477]  &lt;TASK&gt;
[...]
[   57.333511]  ? do_user_addr_fault+0x3e5/0x740
[   57.333778]  ? exc_page_fault+0x70/0x170
[   57.334016]  ? asm_exc_page_fault+0x2b/0x30
[   57.334263]  ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10
[   57.334596]  ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0
[   57.334913]  ocfs2_xa_remove_entry+0x23/0xc0
[   57.335164]  ocfs2_xa_set+0x704/0xcf0
[   57.335381]  ? _raw_spin_unlock+0x1a/0x40
[   57.335620]  ? ocfs2_inode_cache_unlock+0x16/0x20
[   57.335915]  ? trace_preempt_on+0x1e/0x70
[   57.336153]  ? start_this_handle+0x16c/0x500
[   57.336410]  ? preempt_count_sub+0x50/0x80
[   57.336656]  ? _raw_read_unlock+0x20/0x40
[   57.336906]  ? start_this_handle+0x16c/0x500
[   57.337162]  ocfs2_xattr_block_set+0xa6/0x1e0
[   57.337424]  __ocfs2_xattr_set_handle+0x1fd/0x5d0
[   57.337706]  ? ocfs2_start_trans+0x13d/0x290
[   57.337971]  ocfs2_xattr_set+0xb13/0xfb0
[   57.338207]  ? dput+0x46/0x1c0
[   57.338393]  ocfs2_xattr_trusted_set+0x28/0x30
[   57.338665]  ? ocfs2_xattr_trusted_set+0x28/0x30
[   57.338948]  __vfs_removexattr+0x92/0xc0
[   57.339182]  __vfs_removexattr_locked+0xd5/0x190
[   57.339456]  ? preempt_count_sub+0x50/0x80
[   57.339705]  vfs_removexattr+0x5f/0x100
[...]

Reproducer uses faultinject facility to fail ocfs2_xa_remove() -&gt;
ocfs2_xa_value_truncate() with -ENOMEM.

In this case the comment mentions that we can return 0 if
ocfs2_xa_cleanup_value_truncate() is going to wipe the entry
anyway. But the following 'rc' check is wrong and execution flow do
'ocfs2_xa_remove_entry(loc);' twice:
* 1st: in ocfs2_xa_cleanup_value_truncate();
* 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'.

Fix this by skipping the 2nd removal of the same entry and making
syzkaller repro happy.</Note>
    </Notes>
    <CVE>CVE-2024-50265</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

USB: serial: io_edgeport: fix use after free in debug printk

The "dev_dbg(&amp;urb-&gt;dev-&gt;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.</Note>
    </Notes>
    <CVE>CVE-2024-50267</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd()

The "*cmd" variable can be controlled by the user via debugfs.  That means
"new_cam" can be as high as 255 while the size of the uc-&gt;updated[] array
is UCSI_MAX_ALTMODES (30).

The call tree is:
ucsi_cmd() // val comes from simple_attr_write_xsigned()
-&gt; ucsi_send_command()
   -&gt; ucsi_send_command_common()
      -&gt; ucsi_run_command() // calls ucsi-&gt;ops-&gt;sync_control()
         -&gt; ucsi_ccg_sync_control()</Note>
    </Notes>
    <CVE>CVE-2024-50268</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: musb: sunxi: Fix accessing an released usb phy

Commit 6ed05c68cbca ("usb: musb: sunxi: Explicitly release USB PHY on
exit") will cause that usb phy @glue-&gt;xceiv is accessed after released.

1) register platform driver @sunxi_musb_driver
// get the usb phy @glue-&gt;xceiv
sunxi_musb_probe() -&gt; devm_usb_get_phy().

2) register and unregister platform driver @musb_driver
musb_probe() -&gt; sunxi_musb_init()
use the phy here
//the phy is released here
musb_remove() -&gt; sunxi_musb_exit() -&gt; devm_usb_put_phy()

3) register @musb_driver again
musb_probe() -&gt; sunxi_musb_init()
use the phy here but the phy has been released at 2).
...

Fixed by reverting the commit, namely, removing devm_usb_put_phy()
from sunxi_musb_exit().</Note>
    </Notes>
    <CVE>CVE-2024-50269</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

signal: restore the override_rlimit logic

Prior to commit d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of
ucounts") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of
signals.  However now it's enforced unconditionally, even if
override_rlimit is set.  This behavior change caused production issues.  

For example, if the limit is reached and a process receives a SIGSEGV
signal, sigqueue_alloc fails to allocate the necessary resources for the
signal delivery, preventing the signal from being delivered with siginfo. 
This prevents the process from correctly identifying the fault address and
handling the error.  From the user-space perspective, applications are
unaware that the limit has been reached and that the siginfo is
effectively 'corrupted'.  This can lead to unpredictable behavior and
crashes, as we observed with java applications.

Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip
the comparison to max there if override_rlimit is set.  This effectively
restores the old behavior.</Note>
    </Notes>
    <CVE>CVE-2024-50271</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

filemap: Fix bounds checking in filemap_read()

If the caller supplies an iocb-&gt;ki_pos value that is close to the
filesystem upper limit, and an iterator with a count that causes us to
overflow that limit, then filemap_read() enters an infinite loop.

This behaviour was discovered when testing xfstests generic/525 with the
"localio" optimisation for loopback NFS mounts.</Note>
    </Notes>
    <CVE>CVE-2024-50272</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: reinitialize delayed ref list after deleting it from the list

At insert_delayed_ref() if we need to update the action of an existing
ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's
ref_add_list using list_del(), which leaves the ref's add_list member
not reinitialized, as list_del() sets the next and prev members of the
list to LIST_POISON1 and LIST_POISON2, respectively.

If later we end up calling drop_delayed_ref() against the ref, which can
happen during merging or when destroying delayed refs due to a transaction
abort, we can trigger a crash since at drop_delayed_ref() we call
list_empty() against the ref's add_list, which returns false since
the list was not reinitialized after the list_del() and as a consequence
we call list_del() again at drop_delayed_ref(). This results in an
invalid list access since the next and prev members are set to poison
pointers, resulting in a splat if CONFIG_LIST_HARDENED and
CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences
otherwise.

So fix this by deleting from the list with list_del_init() instead.</Note>
    </Notes>
    <CVE>CVE-2024-50273</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-50274</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

arm64/sve: Discard stale CPU state when handling SVE traps

The logic for handling SVE traps manipulates saved FPSIMD/SVE state
incorrectly, and a race with preemption can result in a task having
TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state
is stale (e.g. with SVE traps enabled). This has been observed to result
in warnings from do_sve_acc() where SVE traps are not expected while
TIF_SVE is set:

|         if (test_and_set_thread_flag(TIF_SVE))
|                 WARN_ON(1); /* SVE access shouldn't have trapped */

Warnings of this form have been reported intermittently, e.g.

  https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/
  https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/

The race can occur when the SVE trap handler is preempted before and
after manipulating the saved FPSIMD/SVE state, starting and ending on
the same CPU, e.g.

| void do_sve_acc(unsigned long esr, struct pt_regs *regs)
| {
|         // Trap on CPU 0 with TIF_SVE clear, SVE traps enabled
|         // task-&gt;fpsimd_cpu is 0.
|         // per_cpu_ptr(&amp;fpsimd_last_state, 0) is task.
|
|         ...
|
|         // Preempted; migrated from CPU 0 to CPU 1.
|         // TIF_FOREIGN_FPSTATE is set.
|
|         get_cpu_fpsimd_context();
|
|         if (test_and_set_thread_flag(TIF_SVE))
|                 WARN_ON(1); /* SVE access shouldn't have trapped */
|
|         sve_init_regs() {
|                 if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {
|                         ...
|                 } else {
|                         fpsimd_to_sve(current);
|                         current-&gt;thread.fp_type = FP_STATE_SVE;
|                 }
|         }
|
|         put_cpu_fpsimd_context();
|
|         // Preempted; migrated from CPU 1 to CPU 0.
|         // task-&gt;fpsimd_cpu is still 0
|         // If per_cpu_ptr(&amp;fpsimd_last_state, 0) is still task then:
|         // - Stale HW state is reused (with SVE traps enabled)
|         // - TIF_FOREIGN_FPSTATE is cleared
|         // - A return to userspace skips HW state restore
| }

Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set
by calling fpsimd_flush_task_state() to detach from the saved CPU
state. This ensures that a subsequent context switch will not reuse the
stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the
new state to be reloaded from memory prior to a return to userspace.</Note>
    </Notes>
    <CVE>CVE-2024-50275</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: vertexcom: mse102x: Fix possible double free of TX skb

The scope of the TX skb is wider than just mse102x_tx_frame_spi(),
so in case the TX skb room needs to be expanded, we should free the
the temporary skb instead of the original skb. Otherwise the original
TX skb pointer would be freed again in mse102x_tx_work(), which leads
to crashes:

  Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP
  CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G      D            6.6.23
  Hardware name: chargebyte Charge SOM DC-ONE (DT)
  Workqueue: events mse102x_tx_work [mse102x]
  pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
  pc : skb_release_data+0xb8/0x1d8
  lr : skb_release_data+0x1ac/0x1d8
  sp : ffff8000819a3cc0
  x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0
  x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff
  x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50
  x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc
  x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000
  x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000
  x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8
  x8 : fffffc00001bc008
  x7 : 0000000000000000 x6 : 0000000000000008
  x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009
  x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000
  Call trace:
   skb_release_data+0xb8/0x1d8
   kfree_skb_reason+0x48/0xb0
   mse102x_tx_work+0x164/0x35c [mse102x]
   process_one_work+0x138/0x260
   worker_thread+0x32c/0x438
   kthread+0x118/0x11c
   ret_from_fork+0x10/0x20
  Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)</Note>
    </Notes>
    <CVE>CVE-2024-50276</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dm cache: fix potential out-of-bounds access on the first resume

Out-of-bounds access occurs if the fast device is expanded unexpectedly
before the first-time resume of the cache table. This happens because
expanding the fast device requires reloading the cache table for
cache_create to allocate new in-core data structures that fit the new
size, and the check in cache_preresume is not performed during the
first resume, leading to the issue.

Reproduce steps:

1. prepare component devices:

dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"
dmsetup create cdata --table "0 65536 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

2. load a cache table of 512 cache blocks, and deliberately expand the
   fast device before resuming the cache, making the in-core data
   structures inadequate.

dmsetup create cache --notable
dmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \
/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"
dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192"
dmsetup resume cdata
dmsetup resume cache

3. suspend the cache to write out the in-core dirty bitset and hint
   array, leading to out-of-bounds access to the dirty bitset at offset
   0x40:

dmsetup suspend cache

KASAN reports:

  BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80
  Read of size 8 at addr ffffc90000085040 by task dmsetup/90

  (...snip...)
  The buggy address belongs to the virtual mapping at
   [ffffc90000085000, ffffc90000087000) created by:
   cache_ctr+0x176a/0x35f0

  (...snip...)
  Memory state around the buggy address:
   ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
   ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
  &gt;ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8
                                             ^
   ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
   ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8

Fix by checking the size change on the first resume.</Note>
    </Notes>
    <CVE>CVE-2024-50278</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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
  &gt;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.</Note>
    </Notes>
    <CVE>CVE-2024-50279</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read()

Avoid a possible buffer overflow if size is larger than 4K.

(cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)</Note>
    </Notes>
    <CVE>CVE-2024-50282</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: v4l2-tpg: prevent the risk of a division by zero

As reported by Coverity, the logic at tpg_precalculate_line()
blindly rescales the buffer even when scaled_witdh is equal to
zero. If this ever happens, this will cause a division by zero.

Instead, add a WARN_ON_ONCE() to trigger such cases and return
without doing any precalculation.</Note>
    </Notes>
    <CVE>CVE-2024-50287</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: av7110: fix a spectre vulnerability

As warned by smatch:
	drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110-&gt;ci_slot' [w] (local cap)

There is a spectre-related vulnerability at the code. Fix it.</Note>
    </Notes>
    <CVE>CVE-2024-50289</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-50290</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove

In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not
null. So the release of the dma channel leads to the following issue:
[    4.879000] st,stm32-spdifrx 500d0000.audio-controller:
dma_request_slave_channel error -19
[    4.888975] Unable to handle kernel NULL pointer dereference
at virtual address 000000000000003d
[...]
[    5.096577] Call trace:
[    5.099099]  dma_release_channel+0x24/0x100
[    5.103235]  stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx]
[    5.109494]  stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx]

To avoid this issue, release channel only if the pointer is valid.</Note>
    </Notes>
    <CVE>CVE-2024-50292</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: arc: fix the device for dma_map_single/dma_unmap_single

The ndev-&gt;dev and pdev-&gt;dev aren't the same device, use ndev-&gt;dev.parent
which has dma_mask, ndev-&gt;dev.parent is just pdev-&gt;dev.
Or it would cause the following issue:

[   39.933526] ------------[ cut here ]------------
[   39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8</Note>
    </Notes>
    <CVE>CVE-2024-50295</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: hns3: fix kernel crash when uninstalling driver

When the driver is uninstalled and the VF is disabled concurrently, a
kernel crash occurs. The reason is that the two actions call function
pci_disable_sriov(). The num_VFs is checked to determine whether to
release the corresponding resources. During the second calling, num_VFs
is not 0 and the resource release function is called. However, the
corresponding resource has been released during the first invoking.
Therefore, the problem occurs:

[15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
...
[15278.131557][T50670] Call trace:
[15278.134686][T50670]  klist_put+0x28/0x12c
[15278.138682][T50670]  klist_del+0x14/0x20
[15278.142592][T50670]  device_del+0xbc/0x3c0
[15278.146676][T50670]  pci_remove_bus_device+0x84/0x120
[15278.151714][T50670]  pci_stop_and_remove_bus_device+0x6c/0x80
[15278.157447][T50670]  pci_iov_remove_virtfn+0xb4/0x12c
[15278.162485][T50670]  sriov_disable+0x50/0x11c
[15278.166829][T50670]  pci_disable_sriov+0x24/0x30
[15278.171433][T50670]  hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3]
[15278.178039][T50670]  hclge_exit+0x28/0xd0 [hclge]
[15278.182730][T50670]  __se_sys_delete_module.isra.0+0x164/0x230
[15278.188550][T50670]  __arm64_sys_delete_module+0x1c/0x30
[15278.193848][T50670]  invoke_syscall+0x50/0x11c
[15278.198278][T50670]  el0_svc_common.constprop.0+0x158/0x164
[15278.203837][T50670]  do_el0_svc+0x34/0xcc
[15278.207834][T50670]  el0_svc+0x20/0x30

For details, see the following figure.

     rmmod hclge              disable VFs
----------------------------------------------------
hclge_exit()            sriov_numvfs_store()
  ...                     device_lock()
  pci_disable_sriov()     hns3_pci_sriov_configure()
                            pci_disable_sriov()
                              sriov_disable()
    sriov_disable()             if !num_VFs :
      if !num_VFs :               return;
        return;                 sriov_del_vfs()
      sriov_del_vfs()             ...
        ...                       klist_put()
        klist_put()               ...
        ...                     num_VFs = 0;
      num_VFs = 0;        device_unlock();

In this patch, when driver is removing, we get the device_lock()
to protect num_VFs, just like sriov_numvfs_store().</Note>
    </Notes>
    <CVE>CVE-2024-50296</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: enetc: allocate vf_state during PF probes

In the previous implementation, vf_state is allocated memory only when VF
is enabled. However, net_device_ops::ndo_set_vf_mac() may be called before
VF is enabled to configure the MAC address of VF. If this is the case,
enetc_pf_set_vf_mac() will access vf_state, resulting in access to a null
pointer. The simplified error log is as follows.

root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89
[  173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004
[  173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy
[  173.641973] lr : do_setlink+0x4a8/0xec8
[  173.732292] Call trace:
[  173.734740]  enetc_pf_set_vf_mac+0x3c/0x80
[  173.738847]  __rtnl_newlink+0x530/0x89c
[  173.742692]  rtnl_newlink+0x50/0x7c
[  173.746189]  rtnetlink_rcv_msg+0x128/0x390
[  173.750298]  netlink_rcv_skb+0x60/0x130
[  173.754145]  rtnetlink_rcv+0x18/0x24
[  173.757731]  netlink_unicast+0x318/0x380
[  173.761665]  netlink_sendmsg+0x17c/0x3c8</Note>
    </Notes>
    <CVE>CVE-2024-50298</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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-&gt;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
              +------&gt;+---+
      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.]</Note>
    </Notes>
    <CVE>CVE-2024-50301</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-50302</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-50602</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libexpat1-2.4.4-150400.3.25.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-52533</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:glib2-tools-2.78.6-150600.4.8.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libgio-2_0-0-2.78.6-150600.4.8.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libglib-2_0-0-2.78.6-150600.4.8.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libgmodule-2_0-0-2.78.6-150600.4.8.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libgobject-2_0-0-2.78.6-150600.4.8.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-52616</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libavahi-client3-0.8-150600.15.6.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:libavahi-common3-0.8-150600.15.6.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow()

There are code paths from which the function is called without holding
the RCU read lock, resulting in a suspicious RCU usage warning [1].

Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire
the RCU read lock before calling
l3mdev_master_upper_ifindex_by_index_rcu().

[1]
WARNING: suspicious RCU usage
6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted
-----------------------------
net/core/dev.c:876 RCU-list traversed in non-reader section!!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
1 lock held by ip/361:
 #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60

stack backtrace:
CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0xba/0x110
 lockdep_rcu_suspicious.cold+0x4f/0xd6
 dev_get_by_index_rcu+0x1d3/0x210
 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0
 ip_tunnel_bind_dev+0x72f/0xa00
 ip_tunnel_newlink+0x368/0x7a0
 ipgre_newlink+0x14c/0x170
 __rtnl_newlink+0x1173/0x19c0
 rtnl_newlink+0x6c/0xa0
 rtnetlink_rcv_msg+0x3cc/0xf60
 netlink_rcv_skb+0x171/0x450
 netlink_unicast+0x539/0x7f0
 netlink_sendmsg+0x8c1/0xd80
 ____sys_sendmsg+0x8f9/0xc20
 ___sys_sendmsg+0x197/0x1e0
 __sys_sendmsg+0x122/0x1f0
 do_syscall_64+0xbb/0x1d0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f</Note>
    </Notes>
    <CVE>CVE-2024-53042</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mctp i2c: handle NULL header address

daddr can be NULL if there is no neighbour table entry present,
in that case the tx packet should be dropped.

saddr will usually be set by MCTP core, but check for NULL in case a
packet is transmitted by a different protocol.</Note>
    </Notes>
    <CVE>CVE-2024-53043</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ASoC: dapm: fix bounds checker error in dapm_widget_list_create

The widgets array in the snd_soc_dapm_widget_list has a __counted_by
attribute attached to it, which points to the num_widgets variable. This
attribute is used in bounds checking, and if it is not set before the
array is filled, then the bounds sanitizer will issue a warning or a
kernel panic if CONFIG_UBSAN_TRAP is set.

This patch sets the size of the widgets list calculated with
list_for_each as the initial value for num_widgets as it is used for
allocating memory for the array. It is updated with the actual number of
added elements after the array is filled.</Note>
    </Notes>
    <CVE>CVE-2024-53045</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ice: fix crash on probe for DPLL enabled E810 LOM

The E810 Lan On Motherboard (LOM) design is vendor specific. Intel
provides the reference design, but it is up to vendor on the final
product design. For some cases, like Linux DPLL support, the static
values defined in the driver does not reflect the actual LOM design.
Current implementation of dpll pins is causing the crash on probe
of the ice driver for such DPLL enabled E810 LOM designs:

WARNING: (...) at drivers/dpll/dpll_core.c:495 dpll_pin_get+0x2c4/0x330
...
Call Trace:
 &lt;TASK&gt;
 ? __warn+0x83/0x130
 ? dpll_pin_get+0x2c4/0x330
 ? report_bug+0x1b7/0x1d0
 ? handle_bug+0x42/0x70
 ? exc_invalid_op+0x18/0x70
 ? asm_exc_invalid_op+0x1a/0x20
 ? dpll_pin_get+0x117/0x330
 ? dpll_pin_get+0x2c4/0x330
 ? dpll_pin_get+0x117/0x330
 ice_dpll_get_pins.isra.0+0x52/0xe0 [ice]
...

The number of dpll pins enabled by LOM vendor is greater than expected
and defined in the driver for Intel designed NICs, which causes the crash.

Prevent the crash and allow generic pin initialization within Linux DPLL
subsystem for DPLL enabled E810 LOM designs.

Newly designed solution for described issue will be based on "per HW
design" pin initialization. It requires pin information dynamically
acquired from the firmware and is already in progress, planned for
next-tree only.</Note>
    </Notes>
    <CVE>CVE-2024-53048</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/i915/hdcp: Add encoder check in hdcp2_get_capability

Add encoder check in intel_hdcp2_get_capability to avoid
null pointer error.</Note>
    </Notes>
    <CVE>CVE-2024-53050</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/i915/hdcp: Add encoder check in intel_hdcp_get_capability

Sometimes during hotplug scenario or suspend/resume scenario encoder is
not always initialized when intel_hdcp_get_capability add
a check to avoid kernel null pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2024-53051</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

io_uring/rw: fix missing NOWAIT check for O_DIRECT start write

When io_uring starts a write, it'll call kiocb_start_write() to bump the
super block rwsem, preventing any freezes from happening while that
write is in-flight. The freeze side will grab that rwsem for writing,
excluding any new writers from happening and waiting for existing writes
to finish. But io_uring unconditionally uses kiocb_start_write(), which
will block if someone is currently attempting to freeze the mount point.
This causes a deadlock where freeze is waiting for previous writes to
complete, but the previous writes cannot complete, as the task that is
supposed to complete them is blocked waiting on starting a new write.
This results in the following stuck trace showing that dependency with
the write blocked starting a new write:

task:fio             state:D stack:0     pid:886   tgid:886   ppid:876
Call trace:
 __switch_to+0x1d8/0x348
 __schedule+0x8e8/0x2248
 schedule+0x110/0x3f0
 percpu_rwsem_wait+0x1e8/0x3f8
 __percpu_down_read+0xe8/0x500
 io_write+0xbb8/0xff8
 io_issue_sqe+0x10c/0x1020
 io_submit_sqes+0x614/0x2110
 __arm64_sys_io_uring_enter+0x524/0x1038
 invoke_syscall+0x74/0x268
 el0_svc_common.constprop.0+0x160/0x238
 do_el0_svc+0x44/0x60
 el0_svc+0x44/0xb0
 el0t_64_sync_handler+0x118/0x128
 el0t_64_sync+0x168/0x170
INFO: task fsfreeze:7364 blocked for more than 15 seconds.
      Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963

with the attempting freezer stuck trying to grab the rwsem:

task:fsfreeze        state:D stack:0     pid:7364  tgid:7364  ppid:995
Call trace:
 __switch_to+0x1d8/0x348
 __schedule+0x8e8/0x2248
 schedule+0x110/0x3f0
 percpu_down_write+0x2b0/0x680
 freeze_super+0x248/0x8a8
 do_vfs_ioctl+0x149c/0x1b18
 __arm64_sys_ioctl+0xd0/0x1a0
 invoke_syscall+0x74/0x268
 el0_svc_common.constprop.0+0x160/0x238
 do_el0_svc+0x44/0x60
 el0_svc+0x44/0xb0
 el0t_64_sync_handler+0x118/0x128
 el0t_64_sync+0x168/0x170

Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a
blocking grab of the super block rwsem if it isn't set. For normal issue
where IOCB_NOWAIT would always be set, this returns -EAGAIN which will
have io_uring core issue a blocking attempt of the write. That will in
turn also get completions run, ensuring forward progress.

Since freezing requires CAP_SYS_ADMIN in the first place, this isn't
something that can be triggered by a regular user.</Note>
    </Notes>
    <CVE>CVE-2024-53052</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: fix 6 GHz scan construction

If more than 255 colocated APs exist for the set of all
APs found during 2.4/5 GHz scanning, then the 6 GHz scan
construction will loop forever since the loop variable
has type u8, which can never reach the number found when
that's bigger than 255, and is stored in a u32 variable.
Also move it into the loops to have a smaller scope.

Using a u32 there is fine, we limit the number of APs in
the scan list and each has a limit on the number of RNR
entries due to the frame size. With a limit of 1000 scan
results, a frame size upper bound of 4096 (really it's
more like ~2300) and a TBTT entry size of at least 11,
we get an upper bound for the number of ~372k, well in
the bounds of a u32.</Note>
    </Notes>
    <CVE>CVE-2024-53055</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy()

In mtk_crtc_create(), if the call to mbox_request_channel() fails then we
set the "mtk_crtc-&gt;cmdq_client.chan" pointer to NULL.  In that situation,
we do not call cmdq_pkt_create().

During the cleanup, we need to check if the "mtk_crtc-&gt;cmdq_client.chan"
is NULL first before calling cmdq_pkt_destroy().  Calling
cmdq_pkt_destroy() is unnecessary if we didn't call cmdq_pkt_create() and
it will result in a NULL pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2024-53056</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data

In case the non-paged data of a SKB carries protocol header and protocol
payload to be transmitted on a certain platform that the DMA AXI address
width is configured to 40-bit/48-bit, or the size of the non-paged data
is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI
address width is configured to 32-bit, then this SKB requires at least
two DMA transmit descriptors to serve it.

For example, three descriptors are allocated to split one DMA buffer
mapped from one piece of non-paged data:
    dma_desc[N + 0],
    dma_desc[N + 1],
    dma_desc[N + 2].
Then three elements of tx_q-&gt;tx_skbuff_dma[] will be allocated to hold
extra information to be reused in stmmac_tx_clean():
    tx_q-&gt;tx_skbuff_dma[N + 0],
    tx_q-&gt;tx_skbuff_dma[N + 1],
    tx_q-&gt;tx_skbuff_dma[N + 2].
Now we focus on tx_q-&gt;tx_skbuff_dma[entry].buf, which is the DMA buffer
address returned by DMA mapping call. stmmac_tx_clean() will try to
unmap the DMA buffer _ONLY_IF_ tx_q-&gt;tx_skbuff_dma[entry].buf
is a valid buffer address.

The expected behavior that saves DMA buffer address of this non-paged
data to tx_q-&gt;tx_skbuff_dma[entry].buf is:
    tx_q-&gt;tx_skbuff_dma[N + 0].buf = NULL;
    tx_q-&gt;tx_skbuff_dma[N + 1].buf = NULL;
    tx_q-&gt;tx_skbuff_dma[N + 2].buf = dma_map_single();
Unfortunately, the current code misbehaves like this:
    tx_q-&gt;tx_skbuff_dma[N + 0].buf = dma_map_single();
    tx_q-&gt;tx_skbuff_dma[N + 1].buf = NULL;
    tx_q-&gt;tx_skbuff_dma[N + 2].buf = NULL;

On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the
DMA engine, tx_q-&gt;tx_skbuff_dma[N + 0].buf is a valid buffer address
obviously, then the DMA buffer will be unmapped immediately.
There may be a rare case that the DMA engine does not finish the
pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go
horribly wrong, DMA is going to access a unmapped/unreferenced memory
region, corrupted data will be transmited or iommu fault will be
triggered :(

In contrast, the for-loop that maps SKB fragments behaves perfectly
as expected, and that is how the driver should do for both non-paged
data and paged frags actually.

This patch corrects DMA map/unmap sequences by fixing the array index
for tx_q-&gt;tx_skbuff_dma[entry].buf when assigning DMA buffer address.

Tested and verified on DWXGMAC CORE 3.20a</Note>
    </Notes>
    <CVE>CVE-2024-53058</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd()

1. The size of the response packet is not validated.
2. The response buffer is not freed.

Resolve these issues by switching to iwl_mvm_send_cmd_status(),
which handles both size validation and frees the buffer.</Note>
    </Notes>
    <CVE>CVE-2024-53059</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported

acpi_evaluate_object() may return AE_NOT_FOUND (failure), which
would result in dereferencing buffer.pointer (obj) while being NULL.

Although this case may be unrealistic for the current code, it is
still better to protect against possible bugs.

Bail out also when status is AE_NOT_FOUND.

This fixes 1 FORWARD_NULL issue reported by Coverity
Report: CID 1600951:  Null pointer dereferences  (FORWARD_NULL)

(cherry picked from commit 91c9e221fe2553edf2db71627d8453f083de87a1)</Note>
    </Notes>
    <CVE>CVE-2024-53060</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-53061</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-53063</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-53064</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfs: Fix KMSAN warning in decode_getfattr_attrs()

Fix the following KMSAN warning:

CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G    B
Tainted: [B]=BAD_PAGE
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)
=====================================================
=====================================================
BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90
 decode_getfattr_attrs+0x2d6d/0x2f90
 decode_getfattr_generic+0x806/0xb00
 nfs4_xdr_dec_getattr+0x1de/0x240
 rpcauth_unwrap_resp_decode+0xab/0x100
 rpcauth_unwrap_resp+0x95/0xc0
 call_decode+0x4ff/0xb50
 __rpc_execute+0x57b/0x19d0
 rpc_execute+0x368/0x5e0
 rpc_run_task+0xcfe/0xee0
 nfs4_proc_getattr+0x5b5/0x990
 __nfs_revalidate_inode+0x477/0xd00
 nfs_access_get_cached+0x1021/0x1cc0
 nfs_do_access+0x9f/0xae0
 nfs_permission+0x1e4/0x8c0
 inode_permission+0x356/0x6c0
 link_path_walk+0x958/0x1330
 path_lookupat+0xce/0x6b0
 filename_lookup+0x23e/0x770
 vfs_statx+0xe7/0x970
 vfs_fstatat+0x1f2/0x2c0
 __se_sys_newfstatat+0x67/0x880
 __x64_sys_newfstatat+0xbd/0x120
 x64_sys_call+0x1826/0x3cf0
 do_syscall_64+0xd0/0x1b0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

The KMSAN warning is triggered in decode_getfattr_attrs(), when calling
decode_attr_mdsthreshold(). It appears that fattr-&gt;mdsthreshold is not
initialized.

Fix the issue by initializing fattr-&gt;mdsthreshold to NULL in
nfs_fattr_init().</Note>
    </Notes>
    <CVE>CVE-2024-53066</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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-&gt;name is released prematurely in __scmi_device_destroy(),
which causes slab-use-after-free when accessing scmi_dev-&gt;name in
scmi_bus_notifier(). So move the release of scmi_dev-&gt;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</Note>
    </Notes>
    <CVE>CVE-2024-53068</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

platform/x86/amd/pmc: Detect when STB is not available

Loading the amd_pmc module as:

    amd_pmc enable_stb=1

...can result in the following messages in the kernel ring buffer:

    amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff
    ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff
    WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340

Further debugging reveals that this occurs when the requests for
S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0,
indicating that the STB is inaccessible. To prevent the ioremap
warning and provide clarity to the user, handle the invalid address
and display an error message.</Note>
    </Notes>
    <CVE>CVE-2024-53072</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: don't leak a link on AP removal

Release the link mapping resource in AP removal. This impacted devices
that do not support the MLD API (9260 and down).
On those devices, we couldn't start the AP again after the AP has been
already started and stopped.</Note>
    </Notes>
    <CVE>CVE-2024-53074</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table()

If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loop
of iio_gts_build_avail_scale_table(), the err_free_out will fail to call
kfree() each time when i is reduced to 0, so all the per_time_scales[0]
and per_time_gains[0] will not be freed, which will cause memory leaks.

Fix it by checking if i &gt;= 0.</Note>
    </Notes>
    <CVE>CVE-2024-53076</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm/thp: fix deferred split unqueue naming and locking

Recent changes are putting more pressure on THP deferred split queues:
under load revealing long-standing races, causing list_del corruptions,
"Bad page state"s and worse (I keep BUGs in both of those, so usually
don't get to see how badly they end up without).  The relevant recent
changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin,
improved swap allocation, and underused THP splitting.

Before fixing locking: rename misleading folio_undo_large_rmappable(),
which does not undo large_rmappable, to folio_unqueue_deferred_split(),
which is what it does.  But that and its out-of-line __callee are mm
internals of very limited usability: add comment and WARN_ON_ONCEs to
check usage; and return a bool to say if a deferred split was unqueued,
which can then be used in WARN_ON_ONCEs around safety checks (sparing
callers the arcane conditionals in __folio_unqueue_deferred_split()).

Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all
of whose callers now call it beforehand (and if any forget then bad_page()
will tell) - except for its caller put_pages_list(), which itself no
longer has any callers (and will be deleted separately).

Swapout: mem_cgroup_swapout() has been resetting folio-&gt;memcg_data 0
without checking and unqueueing a THP folio from deferred split list;
which is unfortunate, since the split_queue_lock depends on the memcg
(when memcg is enabled); so swapout has been unqueueing such THPs later,
when freeing the folio, using the pgdat's lock instead: potentially
corrupting the memcg's list.  __remove_mapping() has frozen refcount to 0
here, so no problem with calling folio_unqueue_deferred_split() before
resetting memcg_data.

That goes back to 5.4 commit 87eaceb3faa5 ("mm: thp: make deferred split
shrinker memcg aware"): which included a check on swapcache before adding
to deferred queue, but no check on deferred queue before adding THP to
swapcache.  That worked fine with the usual sequence of events in reclaim
(though there were a couple of rare ways in which a THP on deferred queue
could have been swapped out), but 6.12 commit dafff3f4c850 ("mm: split
underused THPs") avoids splitting underused THPs in reclaim, which makes
swapcache THPs on deferred queue commonplace.

Keep the check on swapcache before adding to deferred queue?  Yes: it is
no longer essential, but preserves the existing behaviour, and is likely
to be a worthwhile optimization (vmstat showed much more traffic on the
queue under swapping load if the check was removed); update its comment.

Memcg-v1 move (deprecated): mem_cgroup_move_account() has been changing
folio-&gt;memcg_data without checking and unqueueing a THP folio from the
deferred list, sometimes corrupting "from" memcg's list, like swapout. 
Refcount is non-zero here, so folio_unqueue_deferred_split() can only be
used in a WARN_ON_ONCE to validate the fix, which must be done earlier:
mem_cgroup_move_charge_pte_range() first try to split the THP (splitting
of course unqueues), or skip it if that fails.  Not ideal, but moving
charge has been requested, and khugepaged should repair the THP later:
nobody wants new custom unqueueing code just for this deprecated case.

The 87eaceb3faa5 commit did have the code to move from one deferred list
to another (but was not conscious of its unsafety while refcount non-0);
but that was removed by 5.6 commit fac0516b5534 ("mm: thp: don't need care
deferred split queue in memcg charge move path"), which argued that the
existence of a PMD mapping guarantees that the THP cannot be on a deferred
list.  As above, false in rare cases, and now commonly false.

Backport to 6.11 should be straightforward.  Earlier backports must take
care that other _deferred_list fixes and dependencies are included.  There
is not a strong case for backports, but they can fix cornercases.</Note>
    </Notes>
    <CVE>CVE-2024-53079</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: ar0521: don't overflow when checking PLL values

The PLL checks are comparing 64 bit integers with 32 bit
ones, as reported by Coverity. Depending on the values of
the variables, this may underflow.

Fix it ensuring that both sides of the expression are u64.</Note>
    </Notes>
    <CVE>CVE-2024-53081</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

virtio_net: Add hash_key_length check

Add hash_key_length check in virtnet_probe() to avoid possible out of
bound errors when setting/reading the hash key.</Note>
    </Notes>
    <CVE>CVE-2024-53082</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tpm: Lock TPM chip in tpm_pm_suspend() first

Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy
according, as this leaves window for tpm_hwrng_read() to be called while
the operation is in progress. The recent bug report gives also evidence of
this behaviour.

Aadress this by locking the TPM chip before checking any chip-&gt;flags both
in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED
check inside tpm_get_random() so that it will be always checked only when
the lock is reserved.</Note>
    </Notes>
    <CVE>CVE-2024-53085</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i40e: fix race condition by adding filter's intermediate sync state

Fix a race condition in the i40e driver that leads to MAC/VLAN filters
becoming corrupted and leaking. Address the issue that occurs under
heavy load when multiple threads are concurrently modifying MAC/VLAN
filters by setting mac and port VLAN.

1. Thread T0 allocates a filter in i40e_add_filter() within
        i40e_ndo_set_vf_port_vlan().
2. Thread T1 concurrently frees the filter in __i40e_del_filter() within
        i40e_ndo_set_vf_mac().
3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which
        refers to the already freed filter memory, causing corruption.

Reproduction steps:
1. Spawn multiple VFs.
2. Apply a concurrent heavy load by running parallel operations to change
        MAC addresses on the VFs and change port VLANs on the host.
3. Observe errors in dmesg:
"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX,
	please set promiscuous on manually for VF XX".

Exact code for stable reproduction Intel can't open-source now.

The fix involves implementing a new intermediate filter state,
I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list.
These filters cannot be deleted from the hash list directly but
must be removed using the full process.</Note>
    </Notes>
    <CVE>CVE-2024-53088</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

afs: Fix lock recursion

afs_wake_up_async_call() can incur lock recursion.  The problem is that it
is called from AF_RXRPC whilst holding the -&gt;notify_lock, but it tries to
take a ref on the afs_call struct in order to pass it to a work queue - but
if the afs_call is already queued, we then have an extraneous ref that must
be put... calling afs_put_call() may call back down into AF_RXRPC through
rxrpc_kernel_shutdown_call(), however, which might try taking the
-&gt;notify_lock again.

This case isn't very common, however, so defer it to a workqueue.  The oops
looks something like:

  BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646
   lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0
  CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351
  Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
  Call Trace:
   &lt;TASK&gt;
   dump_stack_lvl+0x47/0x70
   do_raw_spin_lock+0x3c/0x90
   rxrpc_kernel_shutdown_call+0x83/0xb0
   afs_put_call+0xd7/0x180
   rxrpc_notify_socket+0xa0/0x190
   rxrpc_input_split_jumbo+0x198/0x1d0
   rxrpc_input_data+0x14b/0x1e0
   ? rxrpc_input_call_packet+0xc2/0x1f0
   rxrpc_input_call_event+0xad/0x6b0
   rxrpc_input_packet_on_conn+0x1e1/0x210
   rxrpc_input_packet+0x3f2/0x4d0
   rxrpc_io_thread+0x243/0x410
   ? __pfx_rxrpc_io_thread+0x10/0x10
   kthread+0xcf/0xe0
   ? __pfx_kthread+0x10/0x10
   ret_from_fork+0x24/0x40
   ? __pfx_kthread+0x10/0x10
   ret_from_fork_asm+0x1a/0x30
   &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-53090</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nvme-multipath: defer partition scanning

We need to suppress the partition scan from occuring within the
controller's scan_work context. If a path error occurs here, the IO will
wait until a path becomes available or all paths are torn down, but that
action also occurs within scan_work, so it would deadlock. Defer the
partion scan to a different context that does not block scan_work.</Note>
    </Notes>
    <CVE>CVE-2024-53093</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES

While running ISER over SIW, the initiator machine encounters a warning
from skb_splice_from_iter() indicating that a slab page is being used in
send_page. To address this, it is better to add a sendpage_ok() check
within the driver itself, and if it returns 0, then MSG_SPLICE_PAGES flag
should be disabled before entering the network stack.

A similar issue has been discussed for NVMe in this thread:
https://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/

  WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320
  Call Trace:
   tcp_sendmsg_locked+0x368/0xe40
   siw_tx_hdt+0x695/0xa40 [siw]
   siw_qp_sq_process+0x102/0xb00 [siw]
   siw_sq_resume+0x39/0x110 [siw]
   siw_run_sq+0x74/0x160 [siw]
   kthread+0xd2/0x100
   ret_from_fork+0x34/0x40
   ret_from_fork_asm+0x1a/0x30</Note>
    </Notes>
    <CVE>CVE-2024-53094</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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---</Note>
    </Notes>
    <CVE>CVE-2024-53095</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm: resolve faulty mmap_region() error path behaviour

The mmap_region() function is somewhat terrifying, with spaghetti-like
control flow and numerous means by which issues can arise and incomplete
state, memory leaks and other unpleasantness can occur.

A large amount of the complexity arises from trying to handle errors late
in the process of mapping a VMA, which forms the basis of recently
observed issues with resource leaks and observable inconsistent state.

Taking advantage of previous patches in this series we move a number of
checks earlier in the code, simplifying things by moving the core of the
logic into a static internal function __mmap_region().

Doing this allows us to perform a number of checks up front before we do
any real work, and allows us to unwind the writable unmap check
unconditionally as required and to perform a CONFIG_DEBUG_VM_MAPLE_TREE
validation unconditionally also.

We move a number of things here:

1. We preallocate memory for the iterator before we call the file-backed
   memory hook, allowing us to exit early and avoid having to perform
   complicated and error-prone close/free logic. We carefully free
   iterator state on both success and error paths.

2. The enclosing mmap_region() function handles the mapping_map_writable()
   logic early. Previously the logic had the mapping_map_writable() at the
   point of mapping a newly allocated file-backed VMA, and a matching
   mapping_unmap_writable() on success and error paths.

   We now do this unconditionally if this is a file-backed, shared writable
   mapping. If a driver changes the flags to eliminate VM_MAYWRITE, however
   doing so does not invalidate the seal check we just performed, and we in
   any case always decrement the counter in the wrapper.

   We perform a debug assert to ensure a driver does not attempt to do the
   opposite.

3. We also move arch_validate_flags() up into the mmap_region()
   function. This is only relevant on arm64 and sparc64, and the check is
   only meaningful for SPARC with ADI enabled. We explicitly add a warning
   for this arch if a driver invalidates this check, though the code ought
   eventually to be fixed to eliminate the need for this.

With all of these measures in place, we no longer need to explicitly close
the VMA on error paths, as we place all checks which might fail prior to a
call to any driver mmap hook.

This eliminates an entire class of errors, makes the code easier to reason
about and more robust.</Note>
    </Notes>
    <CVE>CVE-2024-53096</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Check validity of link-&gt;type in bpf_link_show_fdinfo()

If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessing
bpf_link_type_strs[link-&gt;type] may result in an out-of-bounds access.

To spot such missed invocations early in the future, checking the
validity of link-&gt;type in bpf_link_show_fdinfo() and emitting a warning
when such invocations are missed.</Note>
    </Notes>
    <CVE>CVE-2024-53099</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nvme: tcp: avoid race between queue_lock lock and destroy

Commit 76d54bf20cdc ("nvme-tcp: don't access released socket during
error recovery") added a mutex_lock() call for the queue-&gt;queue_lock
in nvme_tcp_get_address(). However, the mutex_lock() races with
mutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below.

DEBUG_LOCKS_WARN_ON(lock-&gt;magic != lock)
WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220
Modules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd 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 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs]
CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:__mutex_lock+0xcf0/0x1220
Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd &lt;0f&gt; 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1
RSP: 0018:ffff88811305f760 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001
RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341
R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000
R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058
FS:  00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 ? __warn.cold+0x5b/0x1af
 ? __mutex_lock+0xcf0/0x1220
 ? report_bug+0x1ec/0x390
 ? handle_bug+0x3c/0x80
 ? exc_invalid_op+0x13/0x40
 ? asm_exc_invalid_op+0x16/0x20
 ? __mutex_lock+0xcf0/0x1220
 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]
 ? __pfx___mutex_lock+0x10/0x10
 ? __lock_acquire+0xd6a/0x59e0
 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]
 nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]
 ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp]
 nvme_sysfs_show_address+0x81/0xc0 [nvme_core]
 dev_attr_show+0x42/0x80
 ? __asan_memset+0x1f/0x40
 sysfs_kf_seq_show+0x1f0/0x370
 seq_read_iter+0x2cb/0x1130
 ? rw_verify_area+0x3b1/0x590
 ? __mutex_lock+0x433/0x1220
 vfs_read+0x6a6/0xa20
 ? lockdep_hardirqs_on+0x78/0x100
 ? __pfx_vfs_read+0x10/0x10
 ksys_read+0xf7/0x1d0
 ? __pfx_ksys_read+0x10/0x10
 ? __x64_sys_openat+0x105/0x1d0
 do_syscall_64+0x93/0x180
 ? lockdep_hardirqs_on_prepare+0x16d/0x400
 ? do_syscall_64+0x9f/0x180
 ? lockdep_hardirqs_on+0x78/0x100
 ? do_syscall_64+0x9f/0x180
 ? __pfx_ksys_read+0x10/0x10
 ? lockdep_hardirqs_on_prepare+0x16d/0x400
 ? do_syscall_64+0x9f/0x180
 ? lockdep_hardirqs_on+0x78/0x100
 ? do_syscall_64+0x9f/0x180
 ? lockdep_hardirqs_on_prepare+0x16d/0x400
 ? do_syscall_64+0x9f/0x180
 ? lockdep_hardirqs_on+0x78/0x100
 ? do_syscall_64+0x9f/0x180
 ? lockdep_hardirqs_on_prepare+0x16d/0x400
 ? do_syscall_64+0x9f/0x180
 ? lockdep_hardirqs_on+0x78/0x100
 ? do_syscall_64+0x9f/0x180
 ? lockdep_hardirqs_on_prepare+0x16d/0x400
 ? do_syscall_64+0x9f/0x180
 ? lockdep_hardirqs_on+0x78/0x100
 ? do_syscall_64+0x9f/0x180
 ? do_syscall_64+0x9f/0x180
 entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7f9713f55cfa
Code: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-53100</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fs: Fix uninitialized value issue in from_kuid and from_kgid

ocfs2_setattr() uses attr-&gt;ia_mode, attr-&gt;ia_uid and attr-&gt;ia_gid in
a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set.

Initialize all fields of newattrs to avoid uninitialized variables, by
checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.</Note>
    </Notes>
    <CVE>CVE-2024-53101</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hv_sock: Initializing vsk-&gt;trans to NULL to prevent a dangling pointer

When hvs is released, there is a possibility that vsk-&gt;trans may not
be initialized to NULL, which could lead to a dangling pointer.
This issue is resolved by initializing vsk-&gt;trans to NULL.</Note>
    </Notes>
    <CVE>CVE-2024-53103</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-53104</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm: page_alloc: move mlocked flag clearance into free_pages_prepare()

Syzbot reported a bad page state problem caused by a page being freed
using free_page() still having a mlocked flag at free_pages_prepare()
stage:

  BUG: Bad page state in process syz.5.504  pfn:61f45
  page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x61f45
  flags: 0xfff00000080204(referenced|workingset|mlocked|node=0|zone=1|lastcpupid=0x7ff)
  raw: 00fff00000080204 0000000000000000 dead000000000122 0000000000000000
  raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
  page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
  page_owner tracks the page as allocated
  page last allocated via order 0, migratetype Unmovable, gfp_mask 0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), pid 8443, tgid 8442 (syz.5.504), ts 201884660643, free_ts 201499827394
   set_page_owner include/linux/page_owner.h:32 [inline]
   post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1537
   prep_new_page mm/page_alloc.c:1545 [inline]
   get_page_from_freelist+0x303f/0x3190 mm/page_alloc.c:3457
   __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4733
   alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265
   kvm_coalesced_mmio_init+0x1f/0xf0 virt/kvm/coalesced_mmio.c:99
   kvm_create_vm virt/kvm/kvm_main.c:1235 [inline]
   kvm_dev_ioctl_create_vm virt/kvm/kvm_main.c:5488 [inline]
   kvm_dev_ioctl+0x12dc/0x2240 virt/kvm/kvm_main.c:5530
   __do_compat_sys_ioctl fs/ioctl.c:1007 [inline]
   __se_compat_sys_ioctl+0x510/0xc90 fs/ioctl.c:950
   do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline]
   __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386
   do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411
   entry_SYSENTER_compat_after_hwframe+0x84/0x8e
  page last free pid 8399 tgid 8399 stack trace:
   reset_page_owner include/linux/page_owner.h:25 [inline]
   free_pages_prepare mm/page_alloc.c:1108 [inline]
   free_unref_folios+0xf12/0x18d0 mm/page_alloc.c:2686
   folios_put_refs+0x76c/0x860 mm/swap.c:1007
   free_pages_and_swap_cache+0x5c8/0x690 mm/swap_state.c:335
   __tlb_batch_free_encoded_pages mm/mmu_gather.c:136 [inline]
   tlb_batch_pages_flush mm/mmu_gather.c:149 [inline]
   tlb_flush_mmu_free mm/mmu_gather.c:366 [inline]
   tlb_flush_mmu+0x3a3/0x680 mm/mmu_gather.c:373
   tlb_finish_mmu+0xd4/0x200 mm/mmu_gather.c:465
   exit_mmap+0x496/0xc40 mm/mmap.c:1926
   __mmput+0x115/0x390 kernel/fork.c:1348
   exit_mm+0x220/0x310 kernel/exit.c:571
   do_exit+0x9b2/0x28e0 kernel/exit.c:926
   do_group_exit+0x207/0x2c0 kernel/exit.c:1088
   __do_sys_exit_group kernel/exit.c:1099 [inline]
   __se_sys_exit_group kernel/exit.c:1097 [inline]
   __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097
   x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232
   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
  Modules linked in:
  CPU: 0 UID: 0 PID: 8442 Comm: syz.5.504 Not tainted 6.12.0-rc6-syzkaller #0
  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
  Call Trace:
   &lt;TASK&gt;
   __dump_stack lib/dump_stack.c:94 [inline]
   dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
   bad_page+0x176/0x1d0 mm/page_alloc.c:501
   free_page_is_bad mm/page_alloc.c:918 [inline]
   free_pages_prepare mm/page_alloc.c:1100 [inline]
   free_unref_page+0xed0/0xf20 mm/page_alloc.c:2638
   kvm_destroy_vm virt/kvm/kvm_main.c:1327 [inline]
   kvm_put_kvm+0xc75/0x1350 virt/kvm/kvm_main.c:1386
   kvm_vcpu_release+0x54/0x60 virt/kvm/kvm_main.c:4143
   __fput+0x23f/0x880 fs/file_table.c:431
   task_work_run+0x24f/0x310 kernel/task_work.c:239
   exit_task_work include/linux/task_work.h:43 [inline]
   do_exit+0xa2f/0x28e0 kernel/exit.c:939
   do_group_exit+0x207/0x2c0 kernel/exit.c:1088
   __do_sys_exit_group kernel/exit.c:1099 [in
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-53105</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ima: fix buffer overrun in ima_eventdigest_init_common

Function ima_eventdigest_init() calls ima_eventdigest_init_common()
with HASH_ALGO__LAST which is then used to access the array
hash_digest_size[] leading to buffer overrun. Have a conditional
statement to handle this.</Note>
    </Notes>
    <CVE>CVE-2024-53106</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Adjust VSDB parser for replay feature

At some point, the IEEE ID identification for the replay check in the
AMD EDID was added. However, this check causes the following
out-of-bounds issues when using KASAN:

[   27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu]
[   27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383

...

[   27.821207] Memory state around the buggy address:
[   27.821215]  ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   27.821224]  ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   27.821234] &gt;ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   27.821243]                    ^
[   27.821250]  ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   27.821259]  ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   27.821268] ==================================================================

This is caused because the ID extraction happens outside of the range of
the edid lenght. This commit addresses this issue by considering the
amd_vsdb_block size.

(cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8)</Note>
    </Notes>
    <CVE>CVE-2024-53108</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vp_vdpa: fix id_table array not null terminated error

Allocate one extra virtio_device_id as null terminator, otherwise
vdpa_mgmtdev_get_classes() may iterate multiple times and visit
undefined memory.</Note>
    </Notes>
    <CVE>CVE-2024-53110</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm/mremap: fix address wraparound in move_page_tables()

On 32-bit platforms, it is possible for the expression `len + old_addr &lt;
old_end` to be false-positive if `len + old_addr` wraps around. 
`old_addr` is the cursor in the old range up to which page table entries
have been moved; so if the operation succeeded, `old_addr` is the *end* of
the old region, and adding `len` to it can wrap.

The overflow causes mremap() to mistakenly believe that PTEs have been
copied; the consequence is that mremap() bails out, but doesn't move the
PTEs back before the new VMA is unmapped, causing anonymous pages in the
region to be lost.  So basically if userspace tries to mremap() a
private-anon region and hits this bug, mremap() will return an error and
the private-anon region's contents appear to have been zeroed.

The idea of this check is that `old_end - len` is the original start
address, and writing the check that way also makes it easier to read; so
fix the check by rearranging the comparison accordingly.

(An alternate fix would be to refactor this function by introducing an
"orig_old_start" variable or such.)


Tested in a VM with a 32-bit X86 kernel; without the patch:

```
user@horn:~/big_mremap$ cat test.c
#define _GNU_SOURCE
#include &lt;stdlib.h&gt;
#include &lt;stdio.h&gt;
#include &lt;err.h&gt;
#include &lt;sys/mman.h&gt;

#define ADDR1 ((void*)0x60000000)
#define ADDR2 ((void*)0x10000000)
#define SIZE          0x50000000uL

int main(void) {
  unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE,
      MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0);
  if (p1 == MAP_FAILED)
    err(1, "mmap 1");
  unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE,
      MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0);
  if (p2 == MAP_FAILED)
    err(1, "mmap 2");
  *p1 = 0x41;
  printf("first char is 0x%02hhx\n", *p1);
  unsigned char *p3 = mremap(p1, SIZE, SIZE,
      MREMAP_MAYMOVE|MREMAP_FIXED, p2);
  if (p3 == MAP_FAILED) {
    printf("mremap() failed; first char is 0x%02hhx\n", *p1);
  } else {
    printf("mremap() succeeded; first char is 0x%02hhx\n", *p3);
  }
}
user@horn:~/big_mremap$ gcc -static -o test test.c
user@horn:~/big_mremap$ setarch -R ./test
first char is 0x41
mremap() failed; first char is 0x00
```

With the patch:

```
user@horn:~/big_mremap$ setarch -R ./test
first char is 0x41
mremap() succeeded; first char is 0x41
```</Note>
    </Notes>
    <CVE>CVE-2024-53111</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: uncache inode which has failed entering the group

Syzbot has reported the following BUG:

kernel BUG at fs/ocfs2/uptodate.c:509!
...
Call Trace:
 &lt;TASK&gt;
 ? __die_body+0x5f/0xb0
 ? die+0x9e/0xc0
 ? do_trap+0x15a/0x3a0
 ? ocfs2_set_new_buffer_uptodate+0x145/0x160
 ? do_error_trap+0x1dc/0x2c0
 ? ocfs2_set_new_buffer_uptodate+0x145/0x160
 ? __pfx_do_error_trap+0x10/0x10
 ? handle_invalid_op+0x34/0x40
 ? ocfs2_set_new_buffer_uptodate+0x145/0x160
 ? exc_invalid_op+0x38/0x50
 ? asm_exc_invalid_op+0x1a/0x20
 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160
 ? ocfs2_set_new_buffer_uptodate+0x144/0x160
 ? ocfs2_set_new_buffer_uptodate+0x145/0x160
 ocfs2_group_add+0x39f/0x15a0
 ? __pfx_ocfs2_group_add+0x10/0x10
 ? __pfx_lock_acquire+0x10/0x10
 ? mnt_get_write_access+0x68/0x2b0
 ? __pfx_lock_release+0x10/0x10
 ? rcu_read_lock_any_held+0xb7/0x160
 ? __pfx_rcu_read_lock_any_held+0x10/0x10
 ? smack_log+0x123/0x540
 ? mnt_get_write_access+0x68/0x2b0
 ? mnt_get_write_access+0x68/0x2b0
 ? mnt_get_write_access+0x226/0x2b0
 ocfs2_ioctl+0x65e/0x7d0
 ? __pfx_ocfs2_ioctl+0x10/0x10
 ? smack_file_ioctl+0x29e/0x3a0
 ? __pfx_smack_file_ioctl+0x10/0x10
 ? lockdep_hardirqs_on_prepare+0x43d/0x780
 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10
 ? __pfx_ocfs2_ioctl+0x10/0x10
 __se_sys_ioctl+0xfb/0x170
 do_syscall_64+0xf3/0x230
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
...
 &lt;/TASK&gt;

When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particular
inode in 'ocfs2_verify_group_and_input()', corresponding buffer head
remains cached and subsequent call to the same 'ioctl()' for the same
inode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (trying
to cache the same buffer head of that inode). Fix this by uncaching
the buffer head with 'ocfs2_remove_from_cache()' on error path in
'ocfs2_group_add()'.</Note>
    </Notes>
    <CVE>CVE-2024-53112</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm: fix NULL pointer dereference in alloc_pages_bulk_noprof

We triggered a NULL pointer dereference for ac.preferred_zoneref-&gt;zone in
alloc_pages_bulk_noprof() when the task is migrated between cpusets.

When cpuset is enabled, in prepare_alloc_pages(), ac-&gt;nodemask may be
&amp;current-&gt;mems_allowed.  when first_zones_zonelist() is called to find
preferred_zoneref, the ac-&gt;nodemask may be modified concurrently if the
task is migrated between different cpusets.  Assuming we have 2 NUMA Node,
when traversing Node1 in ac-&gt;zonelist, the nodemask is 2, and when
traversing Node2 in ac-&gt;zonelist, the nodemask is 1.  As a result, the
ac-&gt;preferred_zoneref points to NULL zone.

In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a
allowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leading
to NULL pointer dereference.

__alloc_pages_noprof() fixes this issue by checking NULL pointer in commit
ea57485af8f4 ("mm, page_alloc: fix check for NULL preferred_zone") and
commit df76cee6bbeb ("mm, page_alloc: remove redundant checks from alloc
fastpath").

To fix it, check NULL pointer for preferred_zoneref-&gt;zone.</Note>
    </Notes>
    <CVE>CVE-2024-53113</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client

A number of Zen4 client SoCs advertise the ability to use virtualized
VMLOAD/VMSAVE, but using these instructions is reported to be a cause
of a random host reboot.

These instructions aren't intended to be advertised on Zen4 client
so clear the capability.</Note>
    </Notes>
    <CVE>CVE-2024-53114</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

virtio/vsock: Improve MSG_ZEROCOPY error handling

Add a missing kfree_skb() to prevent memory leaks.</Note>
    </Notes>
    <CVE>CVE-2024-53117</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vsock: Fix sk_error_queue memory leak

Kernel queues MSG_ZEROCOPY completion notifications on the error queue.
Where they remain, until explicitly recv()ed. To prevent memory leaks,
clean up the queue when the socket is destroyed.

unreferenced object 0xffff8881028beb00 (size 224):
  comm "vsock_test", pid 1218, jiffies 4294694897
  hex dump (first 32 bytes):
    90 b0 21 17 81 88 ff ff 90 b0 21 17 81 88 ff ff  ..!.......!.....
    00 00 00 00 00 00 00 00 00 b0 21 17 81 88 ff ff  ..........!.....
  backtrace (crc 6c7031ca):
    [&lt;ffffffff81418ef7&gt;] kmem_cache_alloc_node_noprof+0x2f7/0x370
    [&lt;ffffffff81d35882&gt;] __alloc_skb+0x132/0x180
    [&lt;ffffffff81d2d32b&gt;] sock_omalloc+0x4b/0x80
    [&lt;ffffffff81d3a8ae&gt;] msg_zerocopy_realloc+0x9e/0x240
    [&lt;ffffffff81fe5cb2&gt;] virtio_transport_send_pkt_info+0x412/0x4c0
    [&lt;ffffffff81fe6183&gt;] virtio_transport_stream_enqueue+0x43/0x50
    [&lt;ffffffff81fe0813&gt;] vsock_connectible_sendmsg+0x373/0x450
    [&lt;ffffffff81d233d5&gt;] ____sys_sendmsg+0x365/0x3a0
    [&lt;ffffffff81d246f4&gt;] ___sys_sendmsg+0x84/0xd0
    [&lt;ffffffff81d26f47&gt;] __sys_sendmsg+0x47/0x80
    [&lt;ffffffff820d3df3&gt;] do_syscall_64+0x93/0x180
    [&lt;ffffffff8220012b&gt;] entry_SYSCALL_64_after_hwframe+0x76/0x7e</Note>
    </Notes>
    <CVE>CVE-2024-53118</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

virtio/vsock: Fix accept_queue memory leak

As the final stages of socket destruction may be delayed, it is possible
that virtio_transport_recv_listen() will be called after the accept_queue
has been flushed, but before the SOCK_DONE flag has been set. As a result,
sockets enqueued after the flush would remain unremoved, leading to a
memory leak.

vsock_release
  __vsock_release
    lock
    virtio_transport_release
      virtio_transport_close
        schedule_delayed_work(close_work)
    sk_shutdown = SHUTDOWN_MASK
(!) flush accept_queue
    release
                                        virtio_transport_recv_pkt
                                          vsock_find_bound_socket
                                          lock
                                          if flag(SOCK_DONE) return
                                          virtio_transport_recv_listen
                                            child = vsock_create_connected
                                      (!)   vsock_enqueue_accept(child)
                                          release
close_work
  lock
  virtio_transport_do_close
    set_flag(SOCK_DONE)
    virtio_transport_remove_sock
      vsock_remove_sock
        vsock_remove_bound
  release

Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during
socket destruction.

unreferenced object 0xffff888109e3f800 (size 2040):
  comm "kworker/5:2", pid 371, jiffies 4294940105
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00  (..@............
  backtrace (crc 9e5f4e84):
    [&lt;ffffffff81418ff1&gt;] kmem_cache_alloc_noprof+0x2c1/0x360
    [&lt;ffffffff81d27aa0&gt;] sk_prot_alloc+0x30/0x120
    [&lt;ffffffff81d2b54c&gt;] sk_alloc+0x2c/0x4b0
    [&lt;ffffffff81fe049a&gt;] __vsock_create.constprop.0+0x2a/0x310
    [&lt;ffffffff81fe6d6c&gt;] virtio_transport_recv_pkt+0x4dc/0x9a0
    [&lt;ffffffff81fe745d&gt;] vsock_loopback_work+0xfd/0x140
    [&lt;ffffffff810fc6ac&gt;] process_one_work+0x20c/0x570
    [&lt;ffffffff810fce3f&gt;] worker_thread+0x1bf/0x3a0
    [&lt;ffffffff811070dd&gt;] kthread+0xdd/0x110
    [&lt;ffffffff81044fdd&gt;] ret_from_fork+0x2d/0x50
    [&lt;ffffffff8100785a&gt;] ret_from_fork_asm+0x1a/0x30</Note>
    </Notes>
    <CVE>CVE-2024-53119</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: CT: Fix null-ptr-deref in add rule err flow

In error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add()
callback returns error, zone_rule-&gt;attr is used uninitiated. Fix it to
use attr which has the needed pointer value.

Kernel log:
 BUG: kernel NULL pointer dereference, address: 0000000000000110
 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core]
…
 Call Trace:
  &lt;TASK&gt;
  ? __die+0x20/0x70
  ? page_fault_oops+0x150/0x3e0
  ? exc_page_fault+0x74/0x140
  ? asm_exc_page_fault+0x22/0x30
  ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core]
  ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core]
  mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core]
  ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table]
  nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table]
  flow_offload_work_handler+0x142/0x320 [nf_flow_table]
  ? finish_task_switch.isra.0+0x15b/0x2b0
  process_one_work+0x16c/0x320
  worker_thread+0x28c/0x3a0
  ? __pfx_worker_thread+0x10/0x10
  kthread+0xb8/0xf0
  ? __pfx_kthread+0x10/0x10
  ret_from_fork+0x2d/0x50
  ? __pfx_kthread+0x10/0x10
  ret_from_fork_asm+0x1a/0x30
  &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-53120</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: fs, lock FTE when checking if active

The referenced commits introduced a two-step process for deleting FTEs:

- Lock the FTE, delete it from hardware, set the hardware deletion function
  to NULL and unlock the FTE.
- Lock the parent flow group, delete the software copy of the FTE, and
  remove it from the xarray.

However, this approach encounters a race condition if a rule with the same
match value is added simultaneously. In this scenario, fs_core may set the
hardware deletion function to NULL prematurely, causing a panic during
subsequent rule deletions.

To prevent this, ensure the active flag of the FTE is checked under a lock,
which will prevent the fs_core layer from attaching a new steering rule to
an FTE that is in the process of deletion.

[  438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func
[  438.968205] ------------[ cut here ]------------
[  438.968654] refcount_t: decrement hit 0; leaking memory.
[  438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110
[  438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_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 rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower]
[  438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8
[  438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
[  438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110
[  438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff &lt;0f&gt; 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90
[  438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286
[  438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000
[  438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0
[  438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0
[  438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0
[  438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0
[  438.980607] FS:  00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000
[  438.983984] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0
[  438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  438.986507] Call Trace:
[  438.986799]  &lt;TASK&gt;
[  438.987070]  ? __warn+0x7d/0x110
[  438.987426]  ? refcount_warn_saturate+0xfb/0x110
[  438.987877]  ? report_bug+0x17d/0x190
[  438.988261]  ? prb_read_valid+0x17/0x20
[  438.988659]  ? handle_bug+0x53/0x90
[  438.989054]  ? exc_invalid_op+0x14/0x70
[  438.989458]  ? asm_exc_invalid_op+0x16/0x20
[  438.989883]  ? refcount_warn_saturate+0xfb/0x110
[  438.990348]  mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core]
[  438.990932]  __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core]
[  438.991519]  ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core]
[  438.992054]  ? xas_load+0x9/0xb0
[  438.992407]  mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core]
[  438.993037]  mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core]
[  438.993623]  mlx5e_flow_put+0x29/0x60 [mlx5_core]
[  438.994161]  mlx5e_delete_flower+0x261/0x390 [mlx5_core]
[  438.994728]  tc_setup_cb_destroy+0xb9/0x190
[  438.995150]  fl_hw_destroy_filter+0x94/0xc0 [cls_flower]
[  438.995650]  fl_change+0x11a4/0x13c0 [cls_flower]
[  438.996105]  tc_new_tfilter+0x347/0xbc0
[  438.996503]  ? __
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-53121</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mptcp: cope racing subflow creation in mptcp_rcv_space_adjust

Additional active subflows - i.e. created by the in kernel path
manager - are included into the subflow list before starting the
3whs.

A racing recvmsg() spooling data received on an already established
subflow would unconditionally call tcp_cleanup_rbuf() on all the
current subflows, potentially hitting a divide by zero error on
the newly created ones.

Explicitly check that the subflow is in a suitable state before
invoking tcp_cleanup_rbuf().</Note>
    </Notes>
    <CVE>CVE-2024-53122</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: sync_linked_regs() must preserve subreg_def

Range propagation must not affect subreg_def marks, otherwise the
following example is rewritten by verifier incorrectly when
BPF_F_TEST_RND_HI32 flag is set:

  0: call bpf_ktime_get_ns                   call bpf_ktime_get_ns
  1: r0 &amp;= 0x7fffffff       after verifier   r0 &amp;= 0x7fffffff
  2: w1 = w0                rewrites         w1 = w0
  3: if w0 &lt; 10 goto +0     --------------&gt;  r11 = 0x2f5674a6     (r)
  4: r1 &gt;&gt;= 32                               r11 &lt;&lt;= 32           (r)
  5: r0 = r1                                 r1 |= r11            (r)
  6: exit;                                   if w0 &lt; 0xa goto pc+0
                                             r1 &gt;&gt;= 32
                                             r0 = r1
                                             exit

(or zero extension of w1 at (2) is missing for architectures that
 require zero extension for upper register half).

The following happens w/o this patch:
- r0 is marked as not a subreg at (0);
- w1 is marked as subreg at (2);
- w1 subreg_def is overridden at (3) by copy_register_state();
- w1 is read at (5) but mark_insn_zext() does not mark (2)
  for zero extension, because w1 subreg_def is not set;
- because of BPF_F_TEST_RND_HI32 flag verifier inserts random
  value for hi32 bits of (2) (marked (r));
- this random value is read at (5).</Note>
    </Notes>
    <CVE>CVE-2024-53125</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vdpa: solidrun: Fix UB bug with devres

In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to
pcim_iomap_regions() is placed on the stack. Neither
pcim_iomap_regions() nor the functions it calls copy that string.

Should the string later ever be used, this, consequently, causes
undefined behavior since the stack frame will by then have disappeared.

Fix the bug by allocating the strings on the heap through
devm_kasprintf().</Note>
    </Notes>
    <CVE>CVE-2024-53126</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Revert "mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K"

The commit 8396c793ffdf ("mmc: dw_mmc: Fix IDMAC operation with pages
bigger than 4K") increased the max_req_size, even for 4K pages, causing
various issues:
- Panic booting the kernel/rootfs from an SD card on Rockchip RK3566
- Panic booting the kernel/rootfs from an SD card on StarFive JH7100
- "swiotlb buffer is full" and data corruption on StarFive JH7110

At this stage no fix have been found, so it's probably better to just
revert the change.

This reverts commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890.</Note>
    </Notes>
    <CVE>CVE-2024-53127</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/rockchip: vop: Fix a dereferenced before check warning

The 'state' can't be NULL, we should check crtc_state.

Fix warning:
drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096
vop_plane_atomic_async_check() warn: variable dereferenced before check
'state' (see line 1077)</Note>
    </Notes>
    <CVE>CVE-2024-53129</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint

When using the "block:block_dirty_buffer" tracepoint, mark_buffer_dirty()
may cause a NULL pointer dereference, or a general protection fault when
KASAN is enabled.

This happens because, since the tracepoint was added in
mark_buffer_dirty(), it references the dev_t member bh-&gt;b_bdev-&gt;bd_dev
regardless of whether the buffer head has a pointer to a block_device
structure.

In the current implementation, nilfs_grab_buffer(), which grabs a buffer
to read (or create) a block of metadata, including b-tree node blocks,
does not set the block device, but instead does so only if the buffer is
not in the "uptodate" state for each of its caller block reading
functions.  However, if the uptodate flag is set on a folio/page, and the
buffer heads are detached from it by try_to_free_buffers(), and new buffer
heads are then attached by create_empty_buffers(), the uptodate flag may
be restored to each buffer without the block device being set to
bh-&gt;b_bdev, and mark_buffer_dirty() may be called later in that state,
resulting in the bug mentioned above.

Fix this issue by making nilfs_grab_buffer() always set the block device
of the super block structure to the buffer head, regardless of the state
of the buffer's uptodate flag.</Note>
    </Notes>
    <CVE>CVE-2024-53130</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint

Patch series "nilfs2: fix null-ptr-deref bugs on block tracepoints".

This series fixes null pointer dereference bugs that occur when using
nilfs2 and two block-related tracepoints.


This patch (of 2):

It has been reported that when using "block:block_touch_buffer"
tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a
NULL pointer dereference, or a general protection fault when KASAN is
enabled.

This happens because since the tracepoint was added in touch_buffer(), it
references the dev_t member bh-&gt;b_bdev-&gt;bd_dev regardless of whether the
buffer head has a pointer to a block_device structure.  In the current
implementation, the block_device structure is set after the function
returns to the caller.

Here, touch_buffer() is used to mark the folio/page that owns the buffer
head as accessed, but the common search helper for folio/page used by the
caller function was optimized to mark the folio/page as accessed when it
was reimplemented a long time ago, eliminating the need to call
touch_buffer() here in the first place.

So this solves the issue by eliminating the touch_buffer() call itself.</Note>
    </Notes>
    <CVE>CVE-2024-53131</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Handle dml allocation failure to avoid crash

[Why]
In the case where a dml allocation fails for any reason, the
current state's dml contexts would no longer be valid. Then
subsequent calls dc_state_copy_internal would shallow copy
invalid memory and if the new state was released, a double
free would occur.

[How]
Reset dml pointers in new_state to NULL and avoid invalid
pointer

(cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c)</Note>
    </Notes>
    <CVE>CVE-2024-53133</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pmdomain: imx93-blk-ctrl: correct remove path

The check condition should be 'i &lt; bc-&gt;onecell_data.num_domains', not
'bc-&gt;onecell_data.num_domains' which will make the look never finish
and cause kernel panic.

Also disable runtime to address
"imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!"</Note>
    </Notes>
    <CVE>CVE-2024-53134</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: kTLS, Fix incorrect page refcounting

The kTLS tx handling code is using a mix of get_page() and
page_ref_inc() APIs to increment the page reference. But on the release
path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used.

This is an issue when using pages from large folios: the get_page()
references are stored on the folio page while the page_ref_inc()
references are stored directly in the given page. On release the folio
page will be dereferenced too many times.

This was found while doing kTLS testing with sendfile() + ZC when the
served file was read from NFS on a kernel with NFS large folios support
(commit 49b29a573da8 ("nfs: add support for large folios")).</Note>
    </Notes>
    <CVE>CVE-2024-53138</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: ipset: add missing range check in bitmap_ip_uadt

When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists,
the values of ip and ip_to are slightly swapped. Therefore, the range check
for ip should be done later, but this part is missing and it seems that the
vulnerability occurs.

So we should add missing range checks and remove unnecessary range checks.</Note>
    </Notes>
    <CVE>CVE-2024-53141</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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 &gt;&gt; /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) &amp; 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.</Note>
    </Notes>
    <CVE>CVE-2024-53142</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

NFSD: Prevent a potential integer overflow

If the tag length is &gt;= 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.</Note>
    </Notes>
    <CVE>CVE-2024-53146</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

comedi: Flush partial mappings in error case

If some remap_pfn_range() calls succeeded before one failed, we still have
buffer pages mapped into the userspace page tables when we drop the buffer
reference with comedi_buf_map_put(bm). The userspace mappings are only
cleaned up later in the mmap error path.

Fix it by explicitly flushing all mappings in our VMA on the error path.

See commit 79a61cc3fc04 ("mm: avoid leaving partial pfn mappings around in
error case").</Note>
    </Notes>
    <CVE>CVE-2024-53148</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb-audio: Fix out of bounds reads when finding clock sources

The current USB-audio driver code doesn't check bLength of each
descriptor at traversing for clock descriptors.  That is, when a
device provides a bogus descriptor with a shorter bLength, the driver
might hit out-of-bounds reads.

For addressing it, this patch adds sanity checks to the validator
functions for the clock descriptor traversal.  When the descriptor
length is shorter than expected, it's skipped in the loop.

For the clock source and clock multiplier descriptors, we can just
check bLength against the sizeof() of each descriptor type.
OTOH, the clock selector descriptor of UAC2 and UAC3 has an array
of bNrInPins elements and two more fields at its tail, hence those
have to be checked in addition to the sizeof() check.</Note>
    </Notes>
    <CVE>CVE-2024-53150</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

svcrdma: Address an integer overflow

Dan Carpenter reports:
&gt; Commit 78147ca8b4a9 ("svcrdma: Add a "parsed chunk list" data
&gt; structure") from Jun 22, 2020 (linux-next), leads to the following
&gt; Smatch static checker warning:
&gt;
&gt;	net/sunrpc/xprtrdma/svc_rdma_recvfrom.c:498 xdr_check_write_chunk()
&gt;	warn: potential user controlled sizeof overflow 'segcount * 4 * 4'
&gt;
&gt; net/sunrpc/xprtrdma/svc_rdma_recvfrom.c
&gt;     488 static bool xdr_check_write_chunk(struct svc_rdma_recv_ctxt *rctxt)
&gt;     489 {
&gt;     490         u32 segcount;
&gt;     491         __be32 *p;
&gt;     492
&gt;     493         if (xdr_stream_decode_u32(&amp;rctxt-&gt;rc_stream, &amp;segcount))
&gt;                                                               ^^^^^^^^
&gt;
&gt;     494                 return false;
&gt;     495
&gt;     496         /* A bogus segcount causes this buffer overflow check to fail. */
&gt;     497         p = xdr_inline_decode(&amp;rctxt-&gt;rc_stream,
&gt; --&gt; 498                               segcount * rpcrdma_segment_maxsz * sizeof(*p));
&gt;
&gt;
&gt; segcount is an untrusted u32.  On 32bit systems anything &gt;= SIZE_MAX / 16 will
&gt; have an integer overflow and some those values will be accepted by
&gt; xdr_inline_decode().</Note>
    </Notes>
    <CVE>CVE-2024-53151</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

clk: clk-apple-nco: Add NULL check in applnco_probe

Add NULL check in applnco_probe, to handle kernel NULL pointer
dereference error.</Note>
    </Notes>
    <CVE>CVE-2024-53154</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix uninitialized value in ocfs2_file_read_iter()

Syzbot has reported the following KMSAN splat:

BUG: KMSAN: uninit-value in ocfs2_file_read_iter+0x9a4/0xf80
 ocfs2_file_read_iter+0x9a4/0xf80
 __io_read+0x8d4/0x20f0
 io_read+0x3e/0xf0
 io_issue_sqe+0x42b/0x22c0
 io_wq_submit_work+0xaf9/0xdc0
 io_worker_handle_work+0xd13/0x2110
 io_wq_worker+0x447/0x1410
 ret_from_fork+0x6f/0x90
 ret_from_fork_asm+0x1a/0x30

Uninit was created at:
 __alloc_pages_noprof+0x9a7/0xe00
 alloc_pages_mpol_noprof+0x299/0x990
 alloc_pages_noprof+0x1bf/0x1e0
 allocate_slab+0x33a/0x1250
 ___slab_alloc+0x12ef/0x35e0
 kmem_cache_alloc_bulk_noprof+0x486/0x1330
 __io_alloc_req_refill+0x84/0x560
 io_submit_sqes+0x172f/0x2f30
 __se_sys_io_uring_enter+0x406/0x41c0
 __x64_sys_io_uring_enter+0x11f/0x1a0
 x64_sys_call+0x2b54/0x3ba0
 do_syscall_64+0xcd/0x1e0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Since an instance of 'struct kiocb' may be passed from the block layer
with 'private' field uninitialized, introduce 'ocfs2_iocb_init_rw_locked()'
and use it from where 'ocfs2_dio_end_io()' might take care, i.e. in
'ocfs2_file_read_iter()' and 'ocfs2_file_write_iter()'.</Note>
    </Notes>
    <CVE>CVE-2024-53155</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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:
   &lt;TASK&gt;
   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.</Note>
    </Notes>
    <CVE>CVE-2024-53156</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

firmware: arm_scpi: Check the DVFS OPP count returned by the firmware

Fix a kernel crash with the below call trace when the SCPI firmware
returns OPP count of zero.

dvfs_info.opp_count may be zero on some platforms during the reboot
test, and the kernel will crash after dereferencing the pointer to
kcalloc(info-&gt;count, sizeof(*opp), GFP_KERNEL).

  |  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028
  |  Mem abort info:
  |    ESR = 0x96000004
  |    Exception class = DABT (current EL), IL = 32 bits
  |    SET = 0, FnV = 0
  |    EA = 0, S1PTW = 0
  |  Data abort info:
  |    ISV = 0, ISS = 0x00000004
  |    CM = 0, WnR = 0
  |  user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c
  |  [0000000000000028] pgd=0000000000000000
  |  Internal error: Oops: 96000004 [#1] SMP
  |  scpi-hwmon: probe of PHYT000D:00 failed with error -110
  |  Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c)
  |  CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1
  |  Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS
  |  pstate: 60000005 (nZCv daif -PAN -UAO)
  |  pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi]
  |  lr : clk_register+0x438/0x720
  |  Call trace:
  |   scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi]
  |   devm_clk_hw_register+0x50/0xa0
  |   scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi]
  |   scpi_clocks_probe+0x528/0x70c [clk_scpi]
  |   platform_drv_probe+0x58/0xa8
  |   really_probe+0x260/0x3d0
  |   driver_probe_device+0x12c/0x148
  |   device_driver_attach+0x74/0x98
  |   __driver_attach+0xb4/0xe8
  |   bus_for_each_dev+0x88/0xe0
  |   driver_attach+0x30/0x40
  |   bus_add_driver+0x178/0x2b0
  |   driver_register+0x64/0x118
  |   __platform_driver_register+0x54/0x60
  |   scpi_clocks_driver_init+0x24/0x1000 [clk_scpi]
  |   do_one_initcall+0x54/0x220
  |   do_init_module+0x54/0x1c8
  |   load_module+0x14a4/0x1668
  |   __se_sys_finit_module+0xf8/0x110
  |   __arm64_sys_finit_module+0x24/0x30
  |   el0_svc_common+0x78/0x170
  |   el0_svc_handler+0x38/0x78
  |   el0_svc+0x8/0x340
  |  Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820)
  |  ---[ end trace 06feb22469d89fa8 ]---
  |  Kernel panic - not syncing: Fatal exception
  |  SMP: stopping secondary CPUs
  |  Kernel Offset: disabled
  |  CPU features: 0x10,a0002008
  |  Memory Limit: none</Note>
    </Notes>
    <CVE>CVE-2024-53157</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get()

This loop is supposed to break if the frequency returned from
clk_round_rate() is the same as on the previous iteration.  However,
that check doesn't make sense on the first iteration through the loop.
It leads to reading before the start of these-&gt;clk_perf_tbl[] array.</Note>
    </Notes>
    <CVE>CVE-2024-53158</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2024-53159</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

rcu/kvfree: Fix data-race in __mod_timer / kvfree_call_rcu

KCSAN reports a data race when access the krcp-&gt;monitor_work.timer.expires
variable in the schedule_delayed_monitor_work() function:

&lt;snip&gt;
BUG: KCSAN: data-race in __mod_timer / kvfree_call_rcu

read to 0xffff888237d1cce8 of 8 bytes by task 10149 on cpu 1:
 schedule_delayed_monitor_work kernel/rcu/tree.c:3520 [inline]
 kvfree_call_rcu+0x3b8/0x510 kernel/rcu/tree.c:3839
 trie_update_elem+0x47c/0x620 kernel/bpf/lpm_trie.c:441
 bpf_map_update_value+0x324/0x350 kernel/bpf/syscall.c:203
 generic_map_update_batch+0x401/0x520 kernel/bpf/syscall.c:1849
 bpf_map_do_batch+0x28c/0x3f0 kernel/bpf/syscall.c:5143
 __sys_bpf+0x2e5/0x7a0
 __do_sys_bpf kernel/bpf/syscall.c:5741 [inline]
 __se_sys_bpf kernel/bpf/syscall.c:5739 [inline]
 __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5739
 x64_sys_call+0x2625/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:322
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xc9/0x1c0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

write to 0xffff888237d1cce8 of 8 bytes by task 56 on cpu 0:
 __mod_timer+0x578/0x7f0 kernel/time/timer.c:1173
 add_timer_global+0x51/0x70 kernel/time/timer.c:1330
 __queue_delayed_work+0x127/0x1a0 kernel/workqueue.c:2523
 queue_delayed_work_on+0xdf/0x190 kernel/workqueue.c:2552
 queue_delayed_work include/linux/workqueue.h:677 [inline]
 schedule_delayed_monitor_work kernel/rcu/tree.c:3525 [inline]
 kfree_rcu_monitor+0x5e8/0x660 kernel/rcu/tree.c:3643
 process_one_work kernel/workqueue.c:3229 [inline]
 process_scheduled_works+0x483/0x9a0 kernel/workqueue.c:3310
 worker_thread+0x51d/0x6f0 kernel/workqueue.c:3391
 kthread+0x1d1/0x210 kernel/kthread.c:389
 ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Reported by Kernel Concurrency Sanitizer on:
CPU: 0 UID: 0 PID: 56 Comm: kworker/u8:4 Not tainted 6.12.0-rc2-syzkaller-00050-g5b7c893ed5ed #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Workqueue: events_unbound kfree_rcu_monitor
&lt;snip&gt;

kfree_rcu_monitor() rearms the work if a "krcp" has to be still
offloaded and this is done without holding krcp-&gt;lock, whereas
the kvfree_call_rcu() holds it.

Fix it by acquiring the "krcp-&gt;lock" for kfree_rcu_monitor() so
both functions do not race anymore.</Note>
    </Notes>
    <CVE>CVE-2024-53160</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

EDAC/bluefield: Fix potential integer overflow

The 64-bit argument for the "get DIMM info" SMC call consists of mem_ctrl_idx
left-shifted 16 bits and OR-ed with DIMM index.  With mem_ctrl_idx defined as
32-bits wide the left-shift operation truncates the upper 16 bits of
information during the calculation of the SMC argument.

The mem_ctrl_idx stack variable must be defined as 64-bits wide to prevent any
potential integer overflow, i.e. loss of data from upper 16 bits.</Note>
    </Notes>
    <CVE>CVE-2024-53161</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

crypto: qat/qat_4xxx - fix off by one in uof_get_name()

The fw_objs[] array has "num_objs" elements so the &gt; needs to be &gt;= to
prevent an out of bounds read.</Note>
    </Notes>
    <CVE>CVE-2024-53162</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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-&gt;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:
 &lt;TASK&gt;
 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
 &lt;/TASK&gt;

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-&gt;lock.</Note>
    </Notes>
    <CVE>CVE-2024-53166</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nvme-fabrics: fix kernel crash while shutting down controller

The nvme keep-alive operation, which executes at a periodic interval,
could potentially sneak in while shutting down a fabric controller.
This may lead to a race between the fabric controller admin queue
destroy code path (invoked while shutting down controller) and hw/hctx
queue dispatcher called from the nvme keep-alive async request queuing
operation. This race could lead to the kernel crash shown below:

Call Trace:
    autoremove_wake_function+0x0/0xbc (unreliable)
    __blk_mq_sched_dispatch_requests+0x114/0x24c
    blk_mq_sched_dispatch_requests+0x44/0x84
    blk_mq_run_hw_queue+0x140/0x220
    nvme_keep_alive_work+0xc8/0x19c [nvme_core]
    process_one_work+0x200/0x4e0
    worker_thread+0x340/0x504
    kthread+0x138/0x140
    start_kernel_thread+0x14/0x18

While shutting down fabric controller, if nvme keep-alive request sneaks
in then it would be flushed off. The nvme_keep_alive_end_io function is
then invoked to handle the end of the keep-alive operation which
decrements the admin-&gt;q_usage_counter and assuming this is the last/only
request in the admin queue then the admin-&gt;q_usage_counter becomes zero.
If that happens then blk-mq destroy queue operation (blk_mq_destroy_
queue()) which could be potentially running simultaneously on another
cpu (as this is the controller shutdown code path) would forward
progress and deletes the admin queue. So, now from this point onward
we are not supposed to access the admin queue resources. However the
issue here's that the nvme keep-alive thread running hw/hctx queue
dispatch operation hasn't yet finished its work and so it could still
potentially access the admin queue resource while the admin queue had
been already deleted and that causes the above crash.

The above kernel crash is regression caused due to changes implemented
in commit a54a93d0e359 ("nvme: move stopping keep-alive into
nvme_uninit_ctrl()"). Ideally we should stop keep-alive before destroyin
g the admin queue and freeing the admin tagset so that it wouldn't sneak
in during the shutdown operation. However we removed the keep alive stop
operation from the beginning of the controller shutdown code path in commit
a54a93d0e359 ("nvme: move stopping keep-alive into nvme_uninit_ctrl()")
and added it under nvme_uninit_ctrl() which executes very late in the
shutdown code path after the admin queue is destroyed and its tagset is
removed. So this change created the possibility of keep-alive sneaking in
and interfering with the shutdown operation and causing observed kernel
crash.

To fix the observed crash, we decided to move nvme_stop_keep_alive() from
nvme_uninit_ctrl() to nvme_remove_admin_tag_set(). This change would ensure
that we don't forward progress and delete the admin queue until the keep-
alive operation is finished (if it's in-flight) or cancelled and that would
help contain the race condition explained above and hence avoid the crash.

Moving nvme_stop_keep_alive() to nvme_remove_admin_tag_set() instead of
adding nvme_stop_keep_alive() to the beginning of the controller shutdown
code path in nvme_stop_ctrl(), as was the case earlier before commit
a54a93d0e359 ("nvme: move stopping keep-alive into nvme_uninit_ctrl()"),
would help save one callsite of nvme_stop_keep_alive().</Note>
    </Notes>
    <CVE>CVE-2024-53169</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ubifs: authentication: Fix use-after-free in ubifs_tnc_end_commit

After an insertion in TNC, the tree might split and cause a node to
change its `znode-&gt;parent`. A further deletion of other nodes in the
tree (which also could free the nodes), the aforementioned node's
`znode-&gt;cparent` could still point to a freed node. This
`znode-&gt;cparent` may not be updated when getting nodes to commit in
`ubifs_tnc_start_commit()`. This could then trigger a use-after-free
when accessing the `znode-&gt;cparent` in `write_index()` in
`ubifs_tnc_end_commit()`.

This can be triggered by running

  rm -f /etc/test-file.bin
  dd if=/dev/urandom of=/etc/test-file.bin bs=1M count=60 conv=fsync

in a loop, and with `CONFIG_UBIFS_FS_AUTHENTICATION`. KASAN then
reports:

  BUG: KASAN: use-after-free in ubifs_tnc_end_commit+0xa5c/0x1950
  Write of size 32 at addr ffffff800a3af86c by task ubifs_bgt0_20/153

  Call trace:
   dump_backtrace+0x0/0x340
   show_stack+0x18/0x24
   dump_stack_lvl+0x9c/0xbc
   print_address_description.constprop.0+0x74/0x2b0
   kasan_report+0x1d8/0x1f0
   kasan_check_range+0xf8/0x1a0
   memcpy+0x84/0xf4
   ubifs_tnc_end_commit+0xa5c/0x1950
   do_commit+0x4e0/0x1340
   ubifs_bg_thread+0x234/0x2e0
   kthread+0x36c/0x410
   ret_from_fork+0x10/0x20

  Allocated by task 401:
   kasan_save_stack+0x38/0x70
   __kasan_kmalloc+0x8c/0xd0
   __kmalloc+0x34c/0x5bc
   tnc_insert+0x140/0x16a4
   ubifs_tnc_add+0x370/0x52c
   ubifs_jnl_write_data+0x5d8/0x870
   do_writepage+0x36c/0x510
   ubifs_writepage+0x190/0x4dc
   __writepage+0x58/0x154
   write_cache_pages+0x394/0x830
   do_writepages+0x1f0/0x5b0
   filemap_fdatawrite_wbc+0x170/0x25c
   file_write_and_wait_range+0x140/0x190
   ubifs_fsync+0xe8/0x290
   vfs_fsync_range+0xc0/0x1e4
   do_fsync+0x40/0x90
   __arm64_sys_fsync+0x34/0x50
   invoke_syscall.constprop.0+0xa8/0x260
   do_el0_svc+0xc8/0x1f0
   el0_svc+0x34/0x70
   el0t_64_sync_handler+0x108/0x114
   el0t_64_sync+0x1a4/0x1a8

  Freed by task 403:
   kasan_save_stack+0x38/0x70
   kasan_set_track+0x28/0x40
   kasan_set_free_info+0x28/0x4c
   __kasan_slab_free+0xd4/0x13c
   kfree+0xc4/0x3a0
   tnc_delete+0x3f4/0xe40
   ubifs_tnc_remove_range+0x368/0x73c
   ubifs_tnc_remove_ino+0x29c/0x2e0
   ubifs_jnl_delete_inode+0x150/0x260
   ubifs_evict_inode+0x1d4/0x2e4
   evict+0x1c8/0x450
   iput+0x2a0/0x3c4
   do_unlinkat+0x2cc/0x490
   __arm64_sys_unlinkat+0x90/0x100
   invoke_syscall.constprop.0+0xa8/0x260
   do_el0_svc+0xc8/0x1f0
   el0_svc+0x34/0x70
   el0t_64_sync_handler+0x108/0x114
   el0t_64_sync+0x1a4/0x1a8

The offending `memcpy()` in `ubifs_copy_hash()` has a use-after-free
when a node becomes root in TNC but still has a `cparent` to an already
freed node. More specifically, consider the following TNC:

         zroot
         /
        /
      zp1
      /
     /
    zn

Inserting a new node `zn_new` with a key smaller then `zn` will trigger
a split in `tnc_insert()` if `zp1` is full:

         zroot
         /   \
        /     \
      zp1     zp2
      /         \
     /           \
  zn_new          zn

`zn-&gt;parent` has now been moved to `zp2`, *but* `zn-&gt;cparent` still
points to `zp1`.

Now, consider a removal of all the nodes _except_ `zn`. Just when
`tnc_delete()` is about to delete `zroot` and `zp2`:

         zroot
             \
              \
              zp2
                \
                 \
                 zn

`zroot` and `zp2` get freed and the tree collapses:

           zn

`zn` now becomes the new `zroot`.

`get_znodes_to_commit()` will now only find `zn`, the new `zroot`, and
`write_index()` will check its `znode-&gt;cparent` that wrongly points to
the already freed `zp1`. `ubifs_copy_hash()` thus gets wrongly called
with `znode-&gt;cparent-&gt;zbranch[znode-&gt;iip].hash` that triggers the
use-after-free!

Fix this by explicitly setting `znode-&gt;cparent` to `NULL` in
`get_znodes_to_commit()` for the root node. The search for the dirty
nodes
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-53171</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-53173</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

SUNRPC: make sure cache entry active before cache_show

The function `c_show` was called with protection from RCU. This only
ensures that `cp` will not be freed. Therefore, the reference count for
`cp` can drop to zero, which will trigger a refcount use-after-free
warning when `cache_get` is called. To resolve this issue, use
`cache_get_rcu` to ensure that `cp` remains active.

------------[ cut here ]------------
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 7 PID: 822 at lib/refcount.c:25
refcount_warn_saturate+0xb1/0x120
CPU: 7 UID: 0 PID: 822 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:
 &lt;TASK&gt;
 c_show+0x2fc/0x380 [sunrpc]
 seq_read_iter+0x589/0x770
 seq_read+0x1e5/0x270
 proc_reg_read+0xe1/0x140
 vfs_read+0x125/0x530
 ksys_read+0xc1/0x160
 do_syscall_64+0x5f/0x170
 entry_SYSCALL_64_after_hwframe+0x76/0x7e</Note>
    </Notes>
    <CVE>CVE-2024-53174</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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-&gt;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-&gt;auth_key.response by
checking whether @ses-&gt;ses_status is SES_GOOD or SES_EXITING with
@ses-&gt;ses_lock held.  After commit 24a9799aa8ef ("smb: client: fix UAF
in smb2_reconnect_server()"), we made sure to call -&gt;logoff() only
when @ses was known to be good (e.g. valid -&gt;auth_key.response), so
it's safe to access signing key when @ses-&gt;ses_status == SES_EXITING.</Note>
    </Notes>
    <CVE>CVE-2024-53179</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: pcm: Add sanity NULL check for the default mmap fault handler

A driver might allow the mmap access before initializing its
runtime-&gt;dma_area properly.  Add a proper NULL check before passing to
virt_to_page() for avoiding a panic.</Note>
    </Notes>
    <CVE>CVE-2024-53180</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: fix crash when unbinding

If there is an error during some initialization related to firmware,
the function ath12k_dp_cc_cleanup is called to release resources.
However this is released again when the device is unbinded (ath12k_pci),
and we get:
BUG: kernel NULL pointer dereference, address: 0000000000000020
at RIP: 0010:ath12k_dp_cc_cleanup.part.0+0xb6/0x500 [ath12k]
Call Trace:
ath12k_dp_cc_cleanup
ath12k_dp_free
ath12k_core_deinit
ath12k_pci_remove
...

The issue is always reproducible from a VM because the MSI addressing
initialization is failing.

In order to fix the issue, just set to NULL the released structure in
ath12k_dp_cc_cleanup at the end.</Note>
    </Notes>
    <CVE>CVE-2024-53188</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures

Syzkaller reported a hung task with uevent_show() on stack trace. That
specific issue was addressed by another commit [0], but even with that
fix applied (for example, running v6.12-rc5) we face another type of hung
task that comes from the same reproducer [1]. By investigating that, we
could narrow it to the following path:

(a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and
dummy_hcd infrastructure.

(b) During the probe of rtl8192cu, the driver ends-up performing an efuse
read procedure (which is related to EEPROM load IIUC), and here lies the
issue: the function read_efuse() calls read_efuse_byte() many times, as
loop iterations depending on the efuse size (in our example, 512 in total).

This procedure for reading efuse bytes relies in a loop that performs an
I/O read up to *10k* times in case of failures. We measured the time of
the loop inside read_efuse_byte() alone, and in this reproducer (which
involves the dummy_hcd emulation layer), it takes 15 seconds each. As a
consequence, we have the driver stuck in its probe routine for big time,
exposing a stack trace like below if we attempt to reboot the system, for
example:

task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000
Workqueue: usb_hub_wq hub_event
Call Trace:
 __schedule+0xe22/0xeb6
 schedule_timeout+0xe7/0x132
 __wait_for_common+0xb5/0x12e
 usb_start_wait_urb+0xc5/0x1ef
 ? usb_alloc_urb+0x95/0xa4
 usb_control_msg+0xff/0x184
 _usbctrl_vendorreq_sync+0xa0/0x161
 _usb_read_sync+0xb3/0xc5
 read_efuse_byte+0x13c/0x146
 read_efuse+0x351/0x5f0
 efuse_read_all_map+0x42/0x52
 rtl_efuse_shadow_map_update+0x60/0xef
 rtl_get_hwinfo+0x5d/0x1c2
 rtl92cu_read_eeprom_info+0x10a/0x8d5
 ? rtl92c_read_chip_version+0x14f/0x17e
 rtl_usb_probe+0x323/0x851
 usb_probe_interface+0x278/0x34b
 really_probe+0x202/0x4a4
 __driver_probe_device+0x166/0x1b2
 driver_probe_device+0x2f/0xd8
 [...]

We propose hereby to drastically reduce the attempts of doing the I/O
reads in case of failures, restricted to USB devices (given that
they're inherently slower than PCIe ones). By retrying up to 10 times
(instead of 10000), we got reponsiveness in the reproducer, while seems
reasonable to believe that there's no sane USB device implementation in
the field requiring this amount of retries at every I/O read in order
to properly work. Based on that assumption, it'd be good to have it
backported to stable but maybe not since driver implementation (the 10k
number comes from day 0), perhaps up to 6.x series makes sense.

[0] Commit 15fffc6a5624 ("driver core: Fix uevent_show() vs driver detach race")

[1] A note about that: this syzkaller report presents multiple reproducers
that differs by the type of emulated USB device. For this specific case,
check the entry from 2024/08/08 06:23 in the list of crashes; the C repro
is available at https://syzkaller.appspot.com/text?tag=ReproC&amp;x=1521fc83980000.</Note>
    </Notes>
    <CVE>CVE-2024-53190</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: fix warning when unbinding

If there is an error during some initialization related to firmware,
the buffers dp-&gt;tx_ring[i].tx_status are released.
However this is released again when the device is unbinded (ath12k_pci),
and we get:
WARNING: CPU: 0 PID: 2098 at mm/slub.c:4689 free_large_kmalloc+0x4d/0x80
Call Trace:
free_large_kmalloc
ath12k_dp_free
ath12k_core_deinit
ath12k_pci_remove
...

The issue is always reproducible from a VM because the MSI addressing
initialization is failing.

In order to fix the issue, just set the buffers to NULL after releasing in
order to avoid the double free.</Note>
    </Notes>
    <CVE>CVE-2024-53191</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix null check for pipe_ctx-&gt;plane_state in hwss_setup_dpp

This commit addresses a null pointer dereference issue in
hwss_setup_dpp(). The issue could occur when pipe_ctx-&gt;plane_state is
null. The fix adds a check to ensure `pipe_ctx-&gt;plane_state` is not null
before accessing. This prevents a null pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2024-53200</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix null check for pipe_ctx-&gt;plane_state in dcn20_program_pipe

This commit addresses a null pointer dereference issue in
dcn20_program_pipe(). Previously, commit 8e4ed3cf1642 ("drm/amd/display:
Add null check for pipe_ctx-&gt;plane_state in dcn20_program_pipe")
partially fixed the null pointer dereference issue. However, in
dcn20_update_dchubp_dpp(), the variable pipe_ctx is passed in, and
plane_state is accessed again through pipe_ctx. Multiple if statements
directly call attributes of plane_state, leading to potential null
pointer dereference issues. This patch adds necessary null checks to
ensure stability.</Note>
    </Notes>
    <CVE>CVE-2024-53201</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

firmware_loader: Fix possible resource leak in fw_log_firmware_info()

The alg instance should be released under the exception path, otherwise
there may be resource leak here.

To mitigate this, free the alg instance with crypto_free_shash when kmalloc
fails.</Note>
    </Notes>
    <CVE>CVE-2024-53202</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: MGMT: Fix possible deadlocks

This fixes possible deadlocks like the following caused by
hci_cmd_sync_dequeue causing the destroy function to run:

 INFO: task kworker/u19:0:143 blocked for more than 120 seconds.
       Tainted: G        W  O        6.8.0-2024-03-19-intel-next-iLS-24ww14 #1
 "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
 task:kworker/u19:0   state:D stack:0     pid:143   tgid:143   ppid:2      flags:0x00004000
 Workqueue: hci0 hci_cmd_sync_work [bluetooth]
 Call Trace:
  &lt;TASK&gt;
  __schedule+0x374/0xaf0
  schedule+0x3c/0xf0
  schedule_preempt_disabled+0x1c/0x30
  __mutex_lock.constprop.0+0x3ef/0x7a0
  __mutex_lock_slowpath+0x13/0x20
  mutex_lock+0x3c/0x50
  mgmt_set_connectable_complete+0xa4/0x150 [bluetooth]
  ? kfree+0x211/0x2a0
  hci_cmd_sync_dequeue+0xae/0x130 [bluetooth]
  ? __pfx_cmd_complete_rsp+0x10/0x10 [bluetooth]
  cmd_complete_rsp+0x26/0x80 [bluetooth]
  mgmt_pending_foreach+0x4d/0x70 [bluetooth]
  __mgmt_power_off+0x8d/0x180 [bluetooth]
  ? _raw_spin_unlock_irq+0x23/0x40
  hci_dev_close_sync+0x445/0x5b0 [bluetooth]
  hci_set_powered_sync+0x149/0x250 [bluetooth]
  set_powered_sync+0x24/0x60 [bluetooth]
  hci_cmd_sync_work+0x90/0x150 [bluetooth]
  process_one_work+0x13e/0x300
  worker_thread+0x2f7/0x420
  ? __pfx_worker_thread+0x10/0x10
  kthread+0x107/0x140
  ? __pfx_kthread+0x10/0x10
  ret_from_fork+0x3d/0x60
  ? __pfx_kthread+0x10/0x10
  ret_from_fork_asm+0x1b/0x30
  &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-53207</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: MGMT: Fix slab-use-after-free Read in set_powered_sync

This fixes the following crash:

==================================================================
BUG: KASAN: slab-use-after-free in set_powered_sync+0x3a/0xc0 net/bluetooth/mgmt.c:1353
Read of size 8 at addr ffff888029b4dd18 by task kworker/u9:0/54

CPU: 1 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-01155-gf723224742fc #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
Workqueue: hci0 hci_cmd_sync_work
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:93 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0x169/0x550 mm/kasan/report.c:488
q kasan_report+0x143/0x180 mm/kasan/report.c:601
 set_powered_sync+0x3a/0xc0 net/bluetooth/mgmt.c:1353
 hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:328
 process_one_work kernel/workqueue.c:3231 [inline]
 process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312
 worker_thread+0x86d/0xd10 kernel/workqueue.c:3389
 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
 &lt;/TASK&gt;

Allocated by task 5247:
 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:370 [inline]
 __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387
 kasan_kmalloc include/linux/kasan.h:211 [inline]
 __kmalloc_cache_noprof+0x19c/0x2c0 mm/slub.c:4193
 kmalloc_noprof include/linux/slab.h:681 [inline]
 kzalloc_noprof include/linux/slab.h:807 [inline]
 mgmt_pending_new+0x65/0x250 net/bluetooth/mgmt_util.c:269
 mgmt_pending_add+0x36/0x120 net/bluetooth/mgmt_util.c:296
 set_powered+0x3cd/0x5e0 net/bluetooth/mgmt.c:1394
 hci_mgmt_cmd+0xc47/0x11d0 net/bluetooth/hci_sock.c:1712
 hci_sock_sendmsg+0x7b8/0x11c0 net/bluetooth/hci_sock.c:1832
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg+0x221/0x270 net/socket.c:745
 sock_write_iter+0x2dd/0x400 net/socket.c:1160
 new_sync_write fs/read_write.c:497 [inline]
 vfs_write+0xa72/0xc90 fs/read_write.c:590
 ksys_write+0x1a0/0x2c0 fs/read_write.c:643
 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 5246:
 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+0xe0/0x150 mm/kasan/common.c:240
 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256
 kasan_slab_free include/linux/kasan.h:184 [inline]
 slab_free_hook mm/slub.c:2256 [inline]
 slab_free mm/slub.c:4477 [inline]
 kfree+0x149/0x360 mm/slub.c:4598
 settings_rsp+0x2bc/0x390 net/bluetooth/mgmt.c:1443
 mgmt_pending_foreach+0xd1/0x130 net/bluetooth/mgmt_util.c:259
 __mgmt_power_off+0x112/0x420 net/bluetooth/mgmt.c:9455
 hci_dev_close_sync+0x665/0x11a0 net/bluetooth/hci_sync.c:5191
 hci_dev_do_close net/bluetooth/hci_core.c:483 [inline]
 hci_dev_close+0x112/0x210 net/bluetooth/hci_core.c:508
 sock_do_ioctl+0x158/0x460 net/socket.c:1222
 sock_ioctl+0x629/0x8e0 net/socket.c:1341
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:907 [inline]
 __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83gv
 entry_SYSCALL_64_after_hwframe+0x77/0x7f</Note>
    </Notes>
    <CVE>CVE-2024-53208</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bnxt_en: Fix receive ring space parameters when XDP is active

The MTU setting at the time an XDP multi-buffer is attached
determines whether the aggregation ring will be used and the
rx_skb_func handler.  This is done in bnxt_set_rx_skb_mode().

If the MTU is later changed, the aggregation ring setting may need
to be changed and it may become out-of-sync with the settings
initially done in bnxt_set_rx_skb_mode().  This may result in
random memory corruption and crashes as the HW may DMA data larger
than the allocated buffer size, such as:

BUG: kernel NULL pointer dereference, address: 00000000000003c0
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 17 PID: 0 Comm: swapper/17 Kdump: loaded Tainted: G S         OE      6.1.0-226bf9805506 #1
Hardware name: Wiwynn Delta Lake PVT BZA.02601.0150/Delta Lake-Class1, BIOS F0E_3A12 08/26/2021
RIP: 0010:bnxt_rx_pkt+0xe97/0x1ae0 [bnxt_en]
Code: 8b 95 70 ff ff ff 4c 8b 9d 48 ff ff ff 66 41 89 87 b4 00 00 00 e9 0b f7 ff ff 0f b7 43 0a 49 8b 95 a8 04 00 00 25 ff 0f 00 00 &lt;0f&gt; b7 14 42 48 c1 e2 06 49 03 95 a0 04 00 00 0f b6 42 33f
RSP: 0018:ffffa19f40cc0d18 EFLAGS: 00010202
RAX: 00000000000001e0 RBX: ffff8e2c805c6100 RCX: 00000000000007ff
RDX: 0000000000000000 RSI: ffff8e2c271ab990 RDI: ffff8e2c84f12380
RBP: ffffa19f40cc0e48 R08: 000000000001000d R09: 974ea2fcddfa4cbf
R10: 0000000000000000 R11: ffffa19f40cc0ff8 R12: ffff8e2c94b58980
R13: ffff8e2c952d6600 R14: 0000000000000016 R15: ffff8e2c271ab990
FS:  0000000000000000(0000) GS:ffff8e3b3f840000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000003c0 CR3: 0000000e8580a004 CR4: 00000000007706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 &lt;IRQ&gt;
 __bnxt_poll_work+0x1c2/0x3e0 [bnxt_en]

To address the issue, we now call bnxt_set_rx_skb_mode() within
bnxt_change_mtu() to properly set the AGG rings configuration and
update rx_skb_func based on the new MTU value.
Additionally, BNXT_FLAG_NO_AGG_RINGS is cleared at the beginning of
bnxt_set_rx_skb_mode() to make sure it gets set or cleared based on
the current MTU.</Note>
    </Notes>
    <CVE>CVE-2024-53209</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()

Passing MSG_PEEK flag to skb_recv_datagram() increments skb refcount
(skb-&gt;users) and iucv_sock_recvmsg() does not decrement skb refcount
at exit.
This results in skb memory leak in skb_queue_purge() and WARN_ON in
iucv_sock_destruct() during socket close. To fix this decrease
skb refcount by one if MSG_PEEK is set in order to prevent memory
leak and WARN_ON.

WARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv]
CPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G        W          6.10.0-rc7 #1
Hardware name: IBM 3931 A01 704 (z/VM 7.3.0)
Call Trace:
        [&lt;001587c682c4aa98&gt;] iucv_sock_destruct+0x148/0x1a0 [af_iucv]
        [&lt;001587c682c4a9d0&gt;] iucv_sock_destruct+0x80/0x1a0 [af_iucv]
        [&lt;001587c704117a32&gt;] __sk_destruct+0x52/0x550
        [&lt;001587c704104a54&gt;] __sock_release+0xa4/0x230
        [&lt;001587c704104c0c&gt;] sock_close+0x2c/0x40
        [&lt;001587c702c5f5a8&gt;] __fput+0x2e8/0x970
        [&lt;001587c7024148c4&gt;] task_work_run+0x1c4/0x2c0
        [&lt;001587c7023b0716&gt;] do_exit+0x996/0x1050
        [&lt;001587c7023b13aa&gt;] do_group_exit+0x13a/0x360
        [&lt;001587c7023b1626&gt;] __s390x_sys_exit_group+0x56/0x60
        [&lt;001587c7022bccca&gt;] do_syscall+0x27a/0x380
        [&lt;001587c7049a6a0c&gt;] __do_syscall+0x9c/0x160
        [&lt;001587c7049ce8a8&gt;] system_call+0x70/0x98
        Last Breaking-Event-Address:
        [&lt;001587c682c4a9d4&gt;] iucv_sock_destruct+0x84/0x1a0 [af_iucv]</Note>
    </Notes>
    <CVE>CVE-2024-53210</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: usb: lan78xx: Fix double free issue with interrupt buffer allocation

In lan78xx_probe(), the buffer `buf` was being freed twice: once
implicitly through `usb_free_urb(dev-&gt;urb_intr)` with the
`URB_FREE_BUFFER` flag and again explicitly by `kfree(buf)`. This caused
a double free issue.

To resolve this, reordered `kmalloc()` and `usb_alloc_urb()` calls to
simplify the initialization sequence and removed the redundant
`kfree(buf)`.  Now, `buf` is allocated after `usb_alloc_urb()`, ensuring
it is correctly managed by  `usb_fill_int_urb()` and freed by
`usb_free_urb()` as intended.</Note>
    </Notes>
    <CVE>CVE-2024-53213</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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-&gt;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:
 &lt;TASK&gt;
 ? 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</Note>
    </Notes>
    <CVE>CVE-2024-53214</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

svcrdma: fix miss destroy percpu_counter in svc_rdma_proc_init()

There's issue as follows:
RPC: Registered rdma transport module.
RPC: Registered rdma backchannel transport module.
RPC: Unregistered rdma transport module.
RPC: Unregistered rdma backchannel transport module.
BUG: unable to handle page fault for address: fffffbfff80c609a
PGD 123fee067 P4D 123fee067 PUD 123fea067 PMD 10c624067 PTE 0
Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI
RIP: 0010:percpu_counter_destroy_many+0xf7/0x2a0
Call Trace:
 &lt;TASK&gt;
 __die+0x1f/0x70
 page_fault_oops+0x2cd/0x860
 spurious_kernel_fault+0x36/0x450
 do_kern_addr_fault+0xca/0x100
 exc_page_fault+0x128/0x150
 asm_exc_page_fault+0x26/0x30
 percpu_counter_destroy_many+0xf7/0x2a0
 mmdrop+0x209/0x350
 finish_task_switch.isra.0+0x481/0x840
 schedule_tail+0xe/0xd0
 ret_from_fork+0x23/0x80
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;

If register_sysctl() return NULL, then svc_rdma_proc_cleanup() will not
destroy the percpu counters which init in svc_rdma_proc_init().
If CONFIG_HOTPLUG_CPU is enabled, residual nodes may be in the
'percpu_counters' list. The above issue may occur once the module is
removed. If the CONFIG_HOTPLUG_CPU configuration is not enabled, memory
leakage occurs.
To solve above issue just destroy all percpu counters when
register_sysctl() return NULL.</Note>
    </Notes>
    <CVE>CVE-2024-53215</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfsd: release svc_expkey/svc_export with rcu_work

The last reference for `cache_head` can be reduced to zero in `c_show`
and `e_show`(using `rcu_read_lock` and `rcu_read_unlock`). Consequently,
`svc_export_put` and `expkey_put` will be invoked, leading to two
issues:

1. The `svc_export_put` will directly free ex_uuid. However,
   `e_show`/`c_show` will access `ex_uuid` after `cache_put`, which can
   trigger a use-after-free issue, shown below.

   ==================================================================
   BUG: KASAN: slab-use-after-free in svc_export_show+0x362/0x430 [nfsd]
   Read of size 1 at addr ff11000010fdc120 by task cat/870

   CPU: 1 UID: 0 PID: 870 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
   Call Trace:
    &lt;TASK&gt;
    dump_stack_lvl+0x53/0x70
    print_address_description.constprop.0+0x2c/0x3a0
    print_report+0xb9/0x280
    kasan_report+0xae/0xe0
    svc_export_show+0x362/0x430 [nfsd]
    c_show+0x161/0x390 [sunrpc]
    seq_read_iter+0x589/0x770
    seq_read+0x1e5/0x270
    proc_reg_read+0xe1/0x140
    vfs_read+0x125/0x530
    ksys_read+0xc1/0x160
    do_syscall_64+0x5f/0x170
    entry_SYSCALL_64_after_hwframe+0x76/0x7e

   Allocated by task 830:
    kasan_save_stack+0x20/0x40
    kasan_save_track+0x14/0x30
    __kasan_kmalloc+0x8f/0xa0
    __kmalloc_node_track_caller_noprof+0x1bc/0x400
    kmemdup_noprof+0x22/0x50
    svc_export_parse+0x8a9/0xb80 [nfsd]
    cache_do_downcall+0x71/0xa0 [sunrpc]
    cache_write_procfs+0x8e/0xd0 [sunrpc]
    proc_reg_write+0xe1/0x140
    vfs_write+0x1a5/0x6d0
    ksys_write+0xc1/0x160
    do_syscall_64+0x5f/0x170
    entry_SYSCALL_64_after_hwframe+0x76/0x7e

   Freed by task 868:
    kasan_save_stack+0x20/0x40
    kasan_save_track+0x14/0x30
    kasan_save_free_info+0x3b/0x60
    __kasan_slab_free+0x37/0x50
    kfree+0xf3/0x3e0
    svc_export_put+0x87/0xb0 [nfsd]
    cache_purge+0x17f/0x1f0 [sunrpc]
    nfsd_destroy_serv+0x226/0x2d0 [nfsd]
    nfsd_svc+0x125/0x1e0 [nfsd]
    write_threads+0x16a/0x2a0 [nfsd]
    nfsctl_transaction_write+0x74/0xa0 [nfsd]
    vfs_write+0x1a5/0x6d0
    ksys_write+0xc1/0x160
    do_syscall_64+0x5f/0x170
    entry_SYSCALL_64_after_hwframe+0x76/0x7e

2. We cannot sleep while using `rcu_read_lock`/`rcu_read_unlock`.
   However, `svc_export_put`/`expkey_put` will call path_put, which
   subsequently triggers a sleeping operation due to the following
   `dput`.

   =============================
   WARNING: suspicious RCU usage
   5.10.0-dirty #141 Not tainted
   -----------------------------
   ...
   Call Trace:
   dump_stack+0x9a/0xd0
   ___might_sleep+0x231/0x240
   dput+0x39/0x600
   path_put+0x1b/0x30
   svc_export_put+0x17/0x80
   e_show+0x1c9/0x200
   seq_read_iter+0x63f/0x7c0
   seq_read+0x226/0x2d0
   vfs_read+0x113/0x2c0
   ksys_read+0xc9/0x170
   do_syscall_64+0x33/0x40
   entry_SYSCALL_64_after_hwframe+0x67/0xd1

Fix these issues by using `rcu_work` to help release
`svc_expkey`/`svc_export`. This approach allows for an asynchronous
context to invoke `path_put` and also facilitates the freeing of
`uuid/exp/key` after an RCU grace period.</Note>
    </Notes>
    <CVE>CVE-2024-53216</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

NFSD: Prevent NULL dereference in nfsd4_process_cb_update()

@ses is initialized to NULL. If __nfsd4_find_backchannel() finds no
available backchannel session, setup_callback_client() will try to
dereference @ses and segfault.</Note>
    </Notes>
    <CVE>CVE-2024-53217</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

zram: fix NULL pointer in comp_algorithm_show()

LTP reported a NULL pointer dereference as followed:

 CPU: 7 UID: 0 PID: 5995 Comm: cat Kdump: loaded Not tainted 6.12.0-rc6+ #3
 Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : __pi_strcmp+0x24/0x140
 lr : zcomp_available_show+0x60/0x100 [zram]
 sp : ffff800088b93b90
 x29: ffff800088b93b90 x28: 0000000000000001 x27: 0000000000400cc0
 x26: 0000000000000ffe x25: ffff80007b3e2388 x24: 0000000000000000
 x23: ffff80007b3e2390 x22: ffff0004041a9000 x21: ffff80007b3e2900
 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000
 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
 x11: 0000000000000000 x10: ffff80007b3e2900 x9 : ffff80007b3cb280
 x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000
 x5 : 0000000000000040 x4 : 0000000000000000 x3 : 00656c722d6f7a6c
 x2 : 0000000000000000 x1 : ffff80007b3e2900 x0 : 0000000000000000
 Call trace:
  __pi_strcmp+0x24/0x140
  comp_algorithm_show+0x40/0x70 [zram]
  dev_attr_show+0x28/0x80
  sysfs_kf_seq_show+0x90/0x140
  kernfs_seq_show+0x34/0x48
  seq_read_iter+0x1d4/0x4e8
  kernfs_fop_read_iter+0x40/0x58
  new_sync_read+0x9c/0x168
  vfs_read+0x1a8/0x1f8
  ksys_read+0x74/0x108
  __arm64_sys_read+0x24/0x38
  invoke_syscall+0x50/0x120
  el0_svc_common.constprop.0+0xc8/0xf0
  do_el0_svc+0x24/0x38
  el0_svc+0x38/0x138
  el0t_64_sync_handler+0xc0/0xc8
  el0t_64_sync+0x188/0x190

The zram-&gt;comp_algs[ZRAM_PRIMARY_COMP] can be NULL in zram_add() if
comp_algorithm_set() has not been called.  User can access the zram device
by sysfs after device_add_disk(), so there is a time window to trigger the
NULL pointer dereference.  Move it ahead device_add_disk() to make sure
when user can access the zram device, it is ready.  comp_algorithm_set()
is protected by zram-&gt;init_lock in other places and no such problem.</Note>
    </Notes>
    <CVE>CVE-2024-53222</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/mlx5: Move events notifier registration to be after device registration

Move pkey change work initialization and cleanup from device resources
stage to notifier stage, since this is the stage which handles this work
events.

Fix a race between the device deregistration and pkey change work by moving
MLX5_IB_STAGE_DEVICE_NOTIFIER to be after MLX5_IB_STAGE_IB_REG in order to
ensure that the notifier is deregistered before the device during cleanup.
Which ensures there are no works that are being executed after the
device has already unregistered which can cause the panic below.

BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 1 PID: 630071 Comm: kworker/1:2 Kdump: loaded Tainted: G W OE --------- --- 5.14.0-162.6.1.el9_1.x86_64 #1
Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 02/27/2023
Workqueue: events pkey_change_handler [mlx5_ib]
RIP: 0010:setup_qp+0x38/0x1f0 [mlx5_ib]
Code: ee 41 54 45 31 e4 55 89 f5 53 48 89 fb 48 83 ec 20 8b 77 08 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 48 8b 07 48 8d 4c 24 16 &lt;4c&gt; 8b 38 49 8b 87 80 0b 00 00 4c 89 ff 48 8b 80 08 05 00 00 8b 40
RSP: 0018:ffffbcc54068be20 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff954054494128 RCX: ffffbcc54068be36
RDX: ffff954004934000 RSI: 0000000000000001 RDI: ffff954054494128
RBP: 0000000000000023 R08: ffff954001be2c20 R09: 0000000000000001
R10: ffff954001be2c20 R11: ffff9540260133c0 R12: 0000000000000000
R13: 0000000000000023 R14: 0000000000000000 R15: ffff9540ffcb0905
FS: 0000000000000000(0000) GS:ffff9540ffc80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000010625c001 CR4: 00000000003706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
mlx5_ib_gsi_pkey_change+0x20/0x40 [mlx5_ib]
process_one_work+0x1e8/0x3c0
worker_thread+0x50/0x3b0
? rescuer_thread+0x380/0x380
kthread+0x149/0x170
? set_kthread_struct+0x50/0x50
ret_from_fork+0x22/0x30
Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) mlx5_fwctl(OE) fwctl(OE) ib_uverbs(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlx_compat(OE) psample mlxfw(OE) tls knem(OE) netconsole nfsv3 nfs_acl nfs lockd grace fscache netfs qrtr rfkill sunrpc intel_rapl_msr intel_rapl_common rapl hv_balloon hv_utils i2c_piix4 pcspkr joydev fuse ext4 mbcache jbd2 sr_mod sd_mod cdrom t10_pi sg ata_generic pci_hyperv pci_hyperv_intf hyperv_drm drm_shmem_helper drm_kms_helper hv_storvsc syscopyarea hv_netvsc sysfillrect sysimgblt hid_hyperv fb_sys_fops scsi_transport_fc hyperv_keyboard drm ata_piix crct10dif_pclmul crc32_pclmul crc32c_intel libata ghash_clmulni_intel hv_vmbus serio_raw [last unloaded: ib_core]
CR2: 0000000000000000
---[ end trace f6f8be4eae12f7bc ]---</Note>
    </Notes>
    <CVE>CVE-2024-53224</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/rxe: Fix the qp flush warnings in req

When the qp is in error state, the status of WQEs in the queue should be
set to error. Or else the following will appear.

[  920.617269] WARNING: CPU: 1 PID: 21 at drivers/infiniband/sw/rxe/rxe_comp.c:756 rxe_completer+0x989/0xcc0 [rdma_rxe]
[  920.617744] Modules linked in: rnbd_client(O) rtrs_client(O) rtrs_core(O) rdma_ucm rdma_cm iw_cm ib_cm crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel ib_uverbs ib_core loop brd null_blk ipv6
[  920.618516] CPU: 1 PID: 21 Comm: ksoftirqd/1 Tainted: G           O       6.1.113-storage+ #65
[  920.618986] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[  920.619396] RIP: 0010:rxe_completer+0x989/0xcc0 [rdma_rxe]
[  920.619658] Code: 0f b6 84 24 3a 02 00 00 41 89 84 24 44 04 00 00 e9 2a f7 ff ff 39 ca bb 03 00 00 00 b8 0e 00 00 00 48 0f 45 d8 e9 15 f7 ff ff &lt;0f&gt; 0b e9 cb f8 ff ff 41 bf f5 ff ff ff e9 08 f8 ff ff 49 8d bc 24
[  920.620482] RSP: 0018:ffff97b7c00bbc38 EFLAGS: 00010246
[  920.620817] RAX: 0000000000000000 RBX: 000000000000000c RCX: 0000000000000008
[  920.621183] RDX: ffff960dc396ebc0 RSI: 0000000000005400 RDI: ffff960dc4e2fbac
[  920.621548] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffac406450
[  920.621884] R10: ffffffffac4060c0 R11: 0000000000000001 R12: ffff960dc4e2f800
[  920.622254] R13: ffff960dc4e2f928 R14: ffff97b7c029c580 R15: 0000000000000000
[  920.622609] FS:  0000000000000000(0000) GS:ffff960ef7d00000(0000) knlGS:0000000000000000
[  920.622979] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  920.623245] CR2: 00007fa056965e90 CR3: 00000001107f1000 CR4: 00000000000006e0
[  920.623680] Call Trace:
[  920.623815]  &lt;TASK&gt;
[  920.623933]  ? __warn+0x79/0xc0
[  920.624116]  ? rxe_completer+0x989/0xcc0 [rdma_rxe]
[  920.624356]  ? report_bug+0xfb/0x150
[  920.624594]  ? handle_bug+0x3c/0x60
[  920.624796]  ? exc_invalid_op+0x14/0x70
[  920.624976]  ? asm_exc_invalid_op+0x16/0x20
[  920.625203]  ? rxe_completer+0x989/0xcc0 [rdma_rxe]
[  920.625474]  ? rxe_completer+0x329/0xcc0 [rdma_rxe]
[  920.625749]  rxe_do_task+0x80/0x110 [rdma_rxe]
[  920.626037]  rxe_requester+0x625/0xde0 [rdma_rxe]
[  920.626310]  ? rxe_cq_post+0xe2/0x180 [rdma_rxe]
[  920.626583]  ? do_complete+0x18d/0x220 [rdma_rxe]
[  920.626812]  ? rxe_completer+0x1a3/0xcc0 [rdma_rxe]
[  920.627050]  rxe_do_task+0x80/0x110 [rdma_rxe]
[  920.627285]  tasklet_action_common.constprop.0+0xa4/0x120
[  920.627522]  handle_softirqs+0xc2/0x250
[  920.627728]  ? sort_range+0x20/0x20
[  920.627942]  run_ksoftirqd+0x1f/0x30
[  920.628158]  smpboot_thread_fn+0xc7/0x1b0
[  920.628334]  kthread+0xd6/0x100
[  920.628504]  ? kthread_complete_and_exit+0x20/0x20
[  920.628709]  ret_from_fork+0x1f/0x30
[  920.628892]  &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-53229</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

erofs: handle NONHEAD !delta[1] lclusters gracefully

syzbot reported a WARNING in iomap_iter_done:
 iomap_fiemap+0x73b/0x9b0 fs/iomap/fiemap.c:80
 ioctl_fiemap fs/ioctl.c:220 [inline]

Generally, NONHEAD lclusters won't have delta[1]==0, except for crafted
images and filesystems created by pre-1.0 mkfs versions.

Previously, it would immediately bail out if delta[1]==0, which led to
inadequate decompressed lengths (thus FIEMAP is impacted).  Treat it as
delta[1]=1 to work around these legacy mkfs versions.

`lclusterbits &gt; 14` is illegal for compact indexes, error out too.</Note>
    </Notes>
    <CVE>CVE-2024-53234</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: fix use-after-free in device_for_each_child()

Syzbot has reported the following KASAN splat:

BUG: KASAN: slab-use-after-free in device_for_each_child+0x18f/0x1a0
Read of size 8 at addr ffff88801f605308 by task kbnepd bnep0/4980

CPU: 0 UID: 0 PID: 4980 Comm: kbnepd bnep0 Not tainted 6.12.0-rc4-00161-gae90f6a6170d #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x100/0x190
 ? device_for_each_child+0x18f/0x1a0
 print_report+0x13a/0x4cb
 ? __virt_addr_valid+0x5e/0x590
 ? __phys_addr+0xc6/0x150
 ? device_for_each_child+0x18f/0x1a0
 kasan_report+0xda/0x110
 ? device_for_each_child+0x18f/0x1a0
 ? __pfx_dev_memalloc_noio+0x10/0x10
 device_for_each_child+0x18f/0x1a0
 ? __pfx_device_for_each_child+0x10/0x10
 pm_runtime_set_memalloc_noio+0xf2/0x180
 netdev_unregister_kobject+0x1ed/0x270
 unregister_netdevice_many_notify+0x123c/0x1d80
 ? __mutex_trylock_common+0xde/0x250
 ? __pfx_unregister_netdevice_many_notify+0x10/0x10
 ? trace_contention_end+0xe6/0x140
 ? __mutex_lock+0x4e7/0x8f0
 ? __pfx_lock_acquire.part.0+0x10/0x10
 ? rcu_is_watching+0x12/0xc0
 ? unregister_netdev+0x12/0x30
 unregister_netdevice_queue+0x30d/0x3f0
 ? __pfx_unregister_netdevice_queue+0x10/0x10
 ? __pfx_down_write+0x10/0x10
 unregister_netdev+0x1c/0x30
 bnep_session+0x1fb3/0x2ab0
 ? __pfx_bnep_session+0x10/0x10
 ? __pfx_lock_release+0x10/0x10
 ? __pfx_woken_wake_function+0x10/0x10
 ? __kthread_parkme+0x132/0x200
 ? __pfx_bnep_session+0x10/0x10
 ? kthread+0x13a/0x370
 ? __pfx_bnep_session+0x10/0x10
 kthread+0x2b7/0x370
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x48/0x80
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;

Allocated by task 4974:
 kasan_save_stack+0x30/0x50
 kasan_save_track+0x14/0x30
 __kasan_kmalloc+0xaa/0xb0
 __kmalloc_noprof+0x1d1/0x440
 hci_alloc_dev_priv+0x1d/0x2820
 __vhci_create_device+0xef/0x7d0
 vhci_write+0x2c7/0x480
 vfs_write+0x6a0/0xfc0
 ksys_write+0x12f/0x260
 do_syscall_64+0xc7/0x250
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 4979:
 kasan_save_stack+0x30/0x50
 kasan_save_track+0x14/0x30
 kasan_save_free_info+0x3b/0x60
 __kasan_slab_free+0x4f/0x70
 kfree+0x141/0x490
 hci_release_dev+0x4d9/0x600
 bt_host_release+0x6a/0xb0
 device_release+0xa4/0x240
 kobject_put+0x1ec/0x5a0
 put_device+0x1f/0x30
 vhci_release+0x81/0xf0
 __fput+0x3f6/0xb30
 task_work_run+0x151/0x250
 do_exit+0xa79/0x2c30
 do_group_exit+0xd5/0x2a0
 get_signal+0x1fcd/0x2210
 arch_do_signal_or_restart+0x93/0x780
 syscall_exit_to_user_mode+0x140/0x290
 do_syscall_64+0xd4/0x250
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

In 'hci_conn_del_sysfs()', 'device_unregister()' may be called when
an underlying (kobject) reference counter is greater than 1. This
means that reparenting (happened when the device is actually freed)
is delayed and, during that delay, parent controller device (hciX)
may be deleted. Since the latter may create a dangling pointer to
freed parent, avoid that scenario by reparenting to NULL explicitly.</Note>
    </Notes>
    <CVE>CVE-2024-53237</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-53240</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-53241</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:xen-libs-4.18.4_02-150600.3.15.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Jinja is an extensible templating engine. Prior to 3.1.5, An oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to store a reference to a malicious string's format method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox. This vulnerability is fixed in 3.1.5.</Note>
    </Notes>
    <CVE>CVE-2024-56326</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:python3-Jinja2-2.10.1-150000.3.18.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: cw1200: Fix potential NULL dereference

A recent refactoring was identified by static analysis to
cause a potential NULL dereference, fix this!</Note>
    </Notes>
    <CVE>CVE-2024-56536</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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-&gt;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-&gt;ssid_list[i].ssid_len;
    [...]
    memcpy(wildcard_ssid_tlv-&gt;ssid,
           user_scan_in-&gt;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.</Note>
    </Notes>
    <CVE>CVE-2024-56539</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cachefiles: Fix NULL pointer dereference in object-&gt;file

At present, the object-&gt;file has the NULL pointer dereference problem in
ondemand-mode. The root cause is that the allocated fd and object-&gt;file
lifetime are inconsistent, and the user-space invocation to anon_fd uses
object-&gt;file. Following is the process that triggers the issue:

	  [write fd]				[umount]
cachefiles_ondemand_fd_write_iter
				       fscache_cookie_state_machine
					 cachefiles_withdraw_cookie
  if (!file) return -ENOBUFS
					   cachefiles_clean_up_object
					     cachefiles_unmark_inode_in_use
					     fput(object-&gt;file)
					     object-&gt;file = NULL
  // file NULL pointer dereference!
  __cachefiles_write(..., file, ...)

Fix this issue by add an additional reference count to the object-&gt;file
before write/llseek, and decrement after it finished.</Note>
    </Notes>
    <CVE>CVE-2024-56549</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: fix usage slab after free

[  +0.000021] BUG: KASAN: slab-use-after-free in drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]
[  +0.000027] Read of size 8 at addr ffff8881b8605f88 by task amd_pci_unplug/2147

[  +0.000023] CPU: 6 PID: 2147 Comm: amd_pci_unplug Not tainted 6.10.0+ #1
[  +0.000016] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020
[  +0.000016] Call Trace:
[  +0.000008]  &lt;TASK&gt;
[  +0.000009]  dump_stack_lvl+0x76/0xa0
[  +0.000017]  print_report+0xce/0x5f0
[  +0.000017]  ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]
[  +0.000019]  ? srso_return_thunk+0x5/0x5f
[  +0.000015]  ? kasan_complete_mode_report_info+0x72/0x200
[  +0.000016]  ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]
[  +0.000019]  kasan_report+0xbe/0x110
[  +0.000015]  ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]
[  +0.000023]  __asan_report_load8_noabort+0x14/0x30
[  +0.000014]  drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]
[  +0.000020]  ? srso_return_thunk+0x5/0x5f
[  +0.000013]  ? __kasan_check_write+0x14/0x30
[  +0.000016]  ? __pfx_drm_sched_entity_flush+0x10/0x10 [gpu_sched]
[  +0.000020]  ? srso_return_thunk+0x5/0x5f
[  +0.000013]  ? __kasan_check_write+0x14/0x30
[  +0.000013]  ? srso_return_thunk+0x5/0x5f
[  +0.000013]  ? enable_work+0x124/0x220
[  +0.000015]  ? __pfx_enable_work+0x10/0x10
[  +0.000013]  ? srso_return_thunk+0x5/0x5f
[  +0.000014]  ? free_large_kmalloc+0x85/0xf0
[  +0.000016]  drm_sched_entity_destroy+0x18/0x30 [gpu_sched]
[  +0.000020]  amdgpu_vce_sw_fini+0x55/0x170 [amdgpu]
[  +0.000735]  ? __kasan_check_read+0x11/0x20
[  +0.000016]  vce_v4_0_sw_fini+0x80/0x110 [amdgpu]
[  +0.000726]  amdgpu_device_fini_sw+0x331/0xfc0 [amdgpu]
[  +0.000679]  ? mutex_unlock+0x80/0xe0
[  +0.000017]  ? __pfx_amdgpu_device_fini_sw+0x10/0x10 [amdgpu]
[  +0.000662]  ? srso_return_thunk+0x5/0x5f
[  +0.000014]  ? __kasan_check_write+0x14/0x30
[  +0.000013]  ? srso_return_thunk+0x5/0x5f
[  +0.000013]  ? mutex_unlock+0x80/0xe0
[  +0.000016]  amdgpu_driver_release_kms+0x16/0x80 [amdgpu]
[  +0.000663]  drm_minor_release+0xc9/0x140 [drm]
[  +0.000081]  drm_release+0x1fd/0x390 [drm]
[  +0.000082]  __fput+0x36c/0xad0
[  +0.000018]  __fput_sync+0x3c/0x50
[  +0.000014]  __x64_sys_close+0x7d/0xe0
[  +0.000014]  x64_sys_call+0x1bc6/0x2680
[  +0.000014]  do_syscall_64+0x70/0x130
[  +0.000014]  ? srso_return_thunk+0x5/0x5f
[  +0.000014]  ? irqentry_exit_to_user_mode+0x60/0x190
[  +0.000015]  ? srso_return_thunk+0x5/0x5f
[  +0.000014]  ? irqentry_exit+0x43/0x50
[  +0.000012]  ? srso_return_thunk+0x5/0x5f
[  +0.000013]  ? exc_page_fault+0x7c/0x110
[  +0.000015]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[  +0.000014] RIP: 0033:0x7ffff7b14f67
[  +0.000013] Code: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff
[  +0.000026] RSP: 002b:00007fffffffe378 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
[  +0.000019] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffff7b14f67
[  +0.000014] RDX: 0000000000000000 RSI: 00007ffff7f6f47a RDI: 0000000000000003
[  +0.000014] RBP: 00007fffffffe3a0 R08: 0000555555569890 R09: 0000000000000000
[  +0.000014] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffffffe5c8
[  +0.000013] R13: 00005555555552a9 R14: 0000555555557d48 R15: 00007ffff7ffd040
[  +0.000020]  &lt;/TASK&gt;

[  +0.000016] Allocated by task 383 on cpu 7 at 26.880319s:
[  +0.000014]  kasan_save_stack+0x28/0x60
[  +0.000008]  kasan_save_track+0x18/0x70
[  +0.000007]  kasan_save_alloc_info+0x38/0x60
[  +0.000007]  __kasan_kmalloc+0xc1/0xd0
[  +0.000007]  kmalloc_trace_noprof+0x180/0x380
[  +0.000007]  drm_sched_init+0x411/0xec0 [gpu_sched]
[  +0.000012]  amdgpu_device_init+0x695f/0xa610 [amdgpu]
[  +0.000658]  amdgpu_driver_load_kms+0x1a/0x120 [amdgpu]
[  +0.000662]  amdgpu_pci_p
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-56551</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i3c: master: Fix miss free init_dyn_addr at i3c_master_put_i3c_addrs()

if (dev-&gt;boardinfo &amp;&amp; dev-&gt;boardinfo-&gt;init_dyn_addr)
                                      ^^^ here check "init_dyn_addr"
	i3c_bus_set_addr_slot_status(&amp;master-&gt;bus, dev-&gt;info.dyn_addr, ...)
						             ^^^^
							free "dyn_addr"
Fix copy/paste error "dyn_addr" by replacing it with "init_dyn_addr".</Note>
    </Notes>
    <CVE>CVE-2024-56562</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm/slub: Avoid list corruption when removing a slab from the full list

Boot with slub_debug=UFPZ.

If allocated object failed in alloc_consistency_checks, all objects of
the slab will be marked as used, and then the slab will be removed from
the partial list.

When an object belonging to the slab got freed later, the remove_full()
function is called. Because the slab is neither on the partial list nor
on the full list, it eventually lead to a list corruption (actually a
list poison being detected).

So we need to mark and isolate the slab page with metadata corruption,
do not put it back in circulation.

Because the debug caches avoid all the fastpaths, reusing the frozen bit
to mark slab page with metadata corruption seems to be fine.

[ 4277.385669] list_del corruption, ffffea00044b3e50-&gt;next is LIST_POISON1 (dead000000000100)
[ 4277.387023] ------------[ cut here ]------------
[ 4277.387880] kernel BUG at lib/list_debug.c:56!
[ 4277.388680] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[ 4277.389562] CPU: 5 PID: 90 Comm: kworker/5:1 Kdump: loaded Tainted: G           OE      6.6.1-1 #1
[ 4277.392113] Workqueue: xfs-inodegc/vda1 xfs_inodegc_worker [xfs]
[ 4277.393551] RIP: 0010:__list_del_entry_valid_or_report+0x7b/0xc0
[ 4277.394518] Code: 48 91 82 e8 37 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 28 49 91 82 e8 26 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 58 49 91
[ 4277.397292] RSP: 0018:ffffc90000333b38 EFLAGS: 00010082
[ 4277.398202] RAX: 000000000000004e RBX: ffffea00044b3e50 RCX: 0000000000000000
[ 4277.399340] RDX: 0000000000000002 RSI: ffffffff828f8715 RDI: 00000000ffffffff
[ 4277.400545] RBP: ffffea00044b3e40 R08: 0000000000000000 R09: ffffc900003339f0
[ 4277.401710] R10: 0000000000000003 R11: ffffffff82d44088 R12: ffff888112cf9910
[ 4277.402887] R13: 0000000000000001 R14: 0000000000000001 R15: ffff8881000424c0
[ 4277.404049] FS:  0000000000000000(0000) GS:ffff88842fd40000(0000) knlGS:0000000000000000
[ 4277.405357] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4277.406389] CR2: 00007f2ad0b24000 CR3: 0000000102a3a006 CR4: 00000000007706e0
[ 4277.407589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 4277.408780] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 4277.410000] PKRU: 55555554
[ 4277.410645] Call Trace:
[ 4277.411234]  &lt;TASK&gt;
[ 4277.411777]  ? die+0x32/0x80
[ 4277.412439]  ? do_trap+0xd6/0x100
[ 4277.413150]  ? __list_del_entry_valid_or_report+0x7b/0xc0
[ 4277.414158]  ? do_error_trap+0x6a/0x90
[ 4277.414948]  ? __list_del_entry_valid_or_report+0x7b/0xc0
[ 4277.415915]  ? exc_invalid_op+0x4c/0x60
[ 4277.416710]  ? __list_del_entry_valid_or_report+0x7b/0xc0
[ 4277.417675]  ? asm_exc_invalid_op+0x16/0x20
[ 4277.418482]  ? __list_del_entry_valid_or_report+0x7b/0xc0
[ 4277.419466]  ? __list_del_entry_valid_or_report+0x7b/0xc0
[ 4277.420410]  free_to_partial_list+0x515/0x5e0
[ 4277.421242]  ? xfs_iext_remove+0x41a/0xa10 [xfs]
[ 4277.422298]  xfs_iext_remove+0x41a/0xa10 [xfs]
[ 4277.423316]  ? xfs_inodegc_worker+0xb4/0x1a0 [xfs]
[ 4277.424383]  xfs_bmap_del_extent_delay+0x4fe/0x7d0 [xfs]
[ 4277.425490]  __xfs_bunmapi+0x50d/0x840 [xfs]
[ 4277.426445]  xfs_itruncate_extents_flags+0x13a/0x490 [xfs]
[ 4277.427553]  xfs_inactive_truncate+0xa3/0x120 [xfs]
[ 4277.428567]  xfs_inactive+0x22d/0x290 [xfs]
[ 4277.429500]  xfs_inodegc_worker+0xb4/0x1a0 [xfs]
[ 4277.430479]  process_one_work+0x171/0x340
[ 4277.431227]  worker_thread+0x277/0x390
[ 4277.431962]  ? __pfx_worker_thread+0x10/0x10
[ 4277.432752]  kthread+0xf0/0x120
[ 4277.433382]  ? __pfx_kthread+0x10/0x10
[ 4277.434134]  ret_from_fork+0x2d/0x50
[ 4277.434837]  ? __pfx_kthread+0x10/0x10
[ 4277.435566]  ret_from_fork_asm+0x1b/0x30
[ 4277.436280]  &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-56566</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ad7780: fix division by zero in ad7780_write_raw()

In the ad7780_write_raw() , val2 can be zero, which might lead to a
division by zero error in DIV_ROUND_CLOSEST(). The ad7780_write_raw()
is based on iio_info's write_raw. While val is explicitly declared that
can be zero (in read mode), val2 is not specified to be non-zero.</Note>
    </Notes>
    <CVE>CVE-2024-56567</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: i2c: tc358743: Fix crash in the probe error path when using polling

If an error occurs in the probe() function, we should remove the polling
timer that was alarmed earlier, otherwise the timer is called with
arguments that are already freed, which results in a crash.

------------[ cut here ]------------
WARNING: CPU: 3 PID: 0 at kernel/time/timer.c:1830 __run_timers+0x244/0x268
Modules linked in:
CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.11.0 #226
Hardware name: Diasom DS-RK3568-SOM-EVB (DT)
pstate: 804000c9 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __run_timers+0x244/0x268
lr : __run_timers+0x1d4/0x268
sp : ffffff80eff2baf0
x29: ffffff80eff2bb50 x28: 7fffffffffffffff x27: ffffff80eff2bb00
x26: ffffffc080f669c0 x25: ffffff80efef6bf0 x24: ffffff80eff2bb00
x23: 0000000000000000 x22: dead000000000122 x21: 0000000000000000
x20: ffffff80efef6b80 x19: ffffff80041c8bf8 x18: ffffffffffffffff
x17: ffffffc06f146000 x16: ffffff80eff27dc0 x15: 000000000000003e
x14: 0000000000000000 x13: 00000000000054da x12: 0000000000000000
x11: 00000000000639c0 x10: 000000000000000c x9 : 0000000000000009
x8 : ffffff80eff2cb40 x7 : ffffff80eff2cb40 x6 : ffffff8002bee480
x5 : ffffffc080cb2220 x4 : ffffffc080cb2150 x3 : 00000000000f4240
x2 : 0000000000000102 x1 : ffffff80eff2bb00 x0 : ffffff80041c8bf0
Call trace:
  __run_timers+0x244/0x268
  timer_expire_remote+0x50/0x68
  tmigr_handle_remote+0x388/0x39c
  run_timer_softirq+0x38/0x44
  handle_softirqs+0x138/0x298
  __do_softirq+0x14/0x20
  ____do_softirq+0x10/0x1c
  call_on_irq_stack+0x24/0x4c
  do_softirq_own_stack+0x1c/0x2c
  irq_exit_rcu+0x9c/0xcc
  el1_interrupt+0x48/0xc0
  el1h_64_irq_handler+0x18/0x24
  el1h_64_irq+0x7c/0x80
  default_idle_call+0x34/0x68
  do_idle+0x23c/0x294
  cpu_startup_entry+0x38/0x3c
  secondary_start_kernel+0x128/0x160
  __secondary_switched+0xb8/0xbc
---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2024-56576</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix use-after-free in btrfs_encoded_read_endio()

Shinichiro reported the following use-after free that sometimes is
happening in our CI system when running fstests' btrfs/284 on a TCMU
runner device:

  BUG: KASAN: slab-use-after-free in lock_release+0x708/0x780
  Read of size 8 at addr ffff888106a83f18 by task kworker/u80:6/219

  CPU: 8 UID: 0 PID: 219 Comm: kworker/u80:6 Not tainted 6.12.0-rc6-kts+ #15
  Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020
  Workqueue: btrfs-endio btrfs_end_bio_work [btrfs]
  Call Trace:
   &lt;TASK&gt;
   dump_stack_lvl+0x6e/0xa0
   ? lock_release+0x708/0x780
   print_report+0x174/0x505
   ? lock_release+0x708/0x780
   ? __virt_addr_valid+0x224/0x410
   ? lock_release+0x708/0x780
   kasan_report+0xda/0x1b0
   ? lock_release+0x708/0x780
   ? __wake_up+0x44/0x60
   lock_release+0x708/0x780
   ? __pfx_lock_release+0x10/0x10
   ? __pfx_do_raw_spin_lock+0x10/0x10
   ? lock_is_held_type+0x9a/0x110
   _raw_spin_unlock_irqrestore+0x1f/0x60
   __wake_up+0x44/0x60
   btrfs_encoded_read_endio+0x14b/0x190 [btrfs]
   btrfs_check_read_bio+0x8d9/0x1360 [btrfs]
   ? lock_release+0x1b0/0x780
   ? trace_lock_acquire+0x12f/0x1a0
   ? __pfx_btrfs_check_read_bio+0x10/0x10 [btrfs]
   ? process_one_work+0x7e3/0x1460
   ? lock_acquire+0x31/0xc0
   ? process_one_work+0x7e3/0x1460
   process_one_work+0x85c/0x1460
   ? __pfx_process_one_work+0x10/0x10
   ? assign_work+0x16c/0x240
   worker_thread+0x5e6/0xfc0
   ? __pfx_worker_thread+0x10/0x10
   kthread+0x2c3/0x3a0
   ? __pfx_kthread+0x10/0x10
   ret_from_fork+0x31/0x70
   ? __pfx_kthread+0x10/0x10
   ret_from_fork_asm+0x1a/0x30
   &lt;/TASK&gt;

  Allocated by task 3661:
   kasan_save_stack+0x30/0x50
   kasan_save_track+0x14/0x30
   __kasan_kmalloc+0xaa/0xb0
   btrfs_encoded_read_regular_fill_pages+0x16c/0x6d0 [btrfs]
   send_extent_data+0xf0f/0x24a0 [btrfs]
   process_extent+0x48a/0x1830 [btrfs]
   changed_cb+0x178b/0x2ea0 [btrfs]
   btrfs_ioctl_send+0x3bf9/0x5c20 [btrfs]
   _btrfs_ioctl_send+0x117/0x330 [btrfs]
   btrfs_ioctl+0x184a/0x60a0 [btrfs]
   __x64_sys_ioctl+0x12e/0x1a0
   do_syscall_64+0x95/0x180
   entry_SYSCALL_64_after_hwframe+0x76/0x7e

  Freed by task 3661:
   kasan_save_stack+0x30/0x50
   kasan_save_track+0x14/0x30
   kasan_save_free_info+0x3b/0x70
   __kasan_slab_free+0x4f/0x70
   kfree+0x143/0x490
   btrfs_encoded_read_regular_fill_pages+0x531/0x6d0 [btrfs]
   send_extent_data+0xf0f/0x24a0 [btrfs]
   process_extent+0x48a/0x1830 [btrfs]
   changed_cb+0x178b/0x2ea0 [btrfs]
   btrfs_ioctl_send+0x3bf9/0x5c20 [btrfs]
   _btrfs_ioctl_send+0x117/0x330 [btrfs]
   btrfs_ioctl+0x184a/0x60a0 [btrfs]
   __x64_sys_ioctl+0x12e/0x1a0
   do_syscall_64+0x95/0x180
   entry_SYSCALL_64_after_hwframe+0x76/0x7e

  The buggy address belongs to the object at ffff888106a83f00
   which belongs to the cache kmalloc-rnd-07-96 of size 96
  The buggy address is located 24 bytes inside of
   freed 96-byte region [ffff888106a83f00, ffff888106a83f60)

  The buggy address belongs to the physical page:
  page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888106a83800 pfn:0x106a83
  flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)
  page_type: f5(slab)
  raw: 0017ffffc0000000 ffff888100053680 ffffea0004917200 0000000000000004
  raw: ffff888106a83800 0000000080200019 00000001f5000000 0000000000000000
  page dumped because: kasan: bad access detected

  Memory state around the buggy address:
   ffff888106a83e00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
   ffff888106a83e80: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
  &gt;ffff888106a83f00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
                              ^
   ffff888106a83f80: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
   ffff888106a84000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  ==================================================================

Further analyzing the trace and 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-56582</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath10k: avoid NULL pointer error during sdio remove

When running 'rmmod ath10k', ath10k_sdio_remove() will free sdio
workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON
is set to yes, kernel panic will happen:
Call trace:
 destroy_workqueue+0x1c/0x258
 ath10k_sdio_remove+0x84/0x94
 sdio_bus_remove+0x50/0x16c
 device_release_driver_internal+0x188/0x25c
 device_driver_detach+0x20/0x2c

This is because during 'rmmod ath10k', ath10k_sdio_remove() will call
ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()
will finally be called in ath10k_core_destroy(). This function will free
struct cfg80211_registered_device *rdev and all its members, including
wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio
workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.

After device release, destroy_workqueue() will use NULL pointer then the
kernel panic happen.

Call trace:
ath10k_sdio_remove
  -&gt;ath10k_core_unregister
    ……
    -&gt;ath10k_core_stop
      -&gt;ath10k_hif_stop
        -&gt;ath10k_sdio_irq_disable
    -&gt;ath10k_hif_power_down
      -&gt;del_timer_sync(&amp;ar_sdio-&gt;sleep_timer)
  -&gt;ath10k_core_destroy
    -&gt;ath10k_mac_destroy
      -&gt;ieee80211_free_hw
        -&gt;wiphy_free
    ……
          -&gt;wiphy_dev_release
  -&gt;destroy_workqueue

Need to call destroy_workqueue() before ath10k_core_destroy(), free
the work queue buffer first and then free pointer of work queue by
ath10k_core_destroy(). This order matches the error path order in
ath10k_sdio_probe().

No work will be queued on sdio workqueue between it is destroyed and
ath10k_core_destroy() is called. Based on the call_stack above, the
reason is:
Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and
ath10k_sdio_irq_disable() will queue work on sdio workqueue.
Sleep timer will be deleted before ath10k_core_destroy() in
ath10k_hif_power_down().
ath10k_sdio_irq_disable() only be called in ath10k_hif_stop().
ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif
bus, so ath10k_sdio_hif_tx_sg() won't be called anymore.

Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189</Note>
    </Notes>
    <CVE>CVE-2024-56599</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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().</Note>
    </Notes>
    <CVE>CVE-2024-56604</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-56605</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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]</Note>
    </Notes>
    <CVE>CVE-2024-56645</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/i915: Fix NULL pointer dereference in capture_engine

When the intel_context structure contains NULL,
it raises a NULL pointer dereference error in drm_info().

(cherry picked from commit 754302a5bc1bd8fd3b7d85c168b0a1af6d4bba4d)</Note>
    </Notes>
    <CVE>CVE-2024-56667</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/nouveau/gr/gf100: Fix missing unlock in gf100_gr_chan_new()

When the call to gf100_grctx_generate() fails, unlock gr-&gt;fecs.mutex
before returning the error.

Fixes smatch warning:

drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:480 gf100_gr_chan_new() warn: inconsistent returns '&amp;gr-&gt;fecs.mutex'.</Note>
    </Notes>
    <CVE>CVE-2024-56752</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

crypto: caam - Fix the pointer passed to caam_qi_shutdown()

The type of the last parameter given to devm_add_action_or_reset() is
"struct caam_drv_private *", but in caam_qi_shutdown(), it is casted to
"struct device *".

Pass the correct parameter to devm_add_action_or_reset() so that the
resources are released as expected.</Note>
    </Notes>
    <CVE>CVE-2024-56754</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfs/fscache: Add a memory barrier for FSCACHE_VOLUME_CREATING

In fscache_create_volume(), there is a missing memory barrier between the
bit-clearing operation and the wake-up operation. This may cause a
situation where, after a wake-up, the bit-clearing operation hasn't been
detected yet, leading to an indefinite wait. The triggering process is as
follows:

  [cookie1]                [cookie2]                  [volume_work]
fscache_perform_lookup
  fscache_create_volume
                        fscache_perform_lookup
                          fscache_create_volume
			                        fscache_create_volume_work
                                                  cachefiles_acquire_volume
                                                  clear_and_wake_up_bit
    test_and_set_bit
                            test_and_set_bit
                              goto maybe_wait
      goto no_wait

In the above process, cookie1 and cookie2 has the same volume. When cookie1
enters the -no_wait- process, it will clear the bit and wake up the waiting
process. If a barrier is missing, it may cause cookie2 to remain in the
-wait- process indefinitely.

In commit 3288666c7256 ("fscache: Use clear_and_wake_up_bit() in
fscache_create_volume_work()"), barriers were added to similar operations
in fscache_create_volume_work(), but fscache_create_volume() was missed.

By combining the clear and wake operations into clear_and_wake_up_bit() to
fix this issue.</Note>
    </Notes>
    <CVE>CVE-2024-56755</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nvme-pci: fix freeing of the HMB descriptor table

The HMB descriptor table is sized to the maximum number of descriptors
that could be used for a given device, but __nvme_alloc_host_mem could
break out of the loop earlier on memory allocation failure and end up
using less descriptors than planned for, which leads to an incorrect
size passed to dma_free_coherent.

In practice this was not showing up because the number of descriptors
tends to be low and the dma coherent allocator always allocates and
frees at least a page.</Note>
    </Notes>
    <CVE>CVE-2024-56756</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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.</Note>
    </Notes>
    <CVE>CVE-2024-8805</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250129-x86-64:kernel-default-6.4.0-150600.23.33.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
</cvrfdoc>
