<?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:105-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:105-1</ID>
    </Identification>
    <Status>Interim</Status>
    <Version>1</Version>
    <RevisionHistory>
      <Revision>
        <Number>1</Number>
        <Date>2025-10-09T16:54:29Z</Date>
        <Description>current</Description>
      </Revision>
    </RevisionHistory>
    <InitialReleaseDate>2025-01-10T01:00:00Z</InitialReleaseDate>
    <CurrentReleaseDate>2025-01-10T01: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:105-1 / google/sle-hpc-15-sp5-byos-v20250110-x86-64</Note>
    <Note Title="Details" Type="General" Ordinal="2" xml:lang="en">This image update for google/sle-hpc-15-sp5-byos-v20250110-x86-64 contains the following changes:
Package 000release-packages:SLE_HPC-release was updated:

Package aaa_base was updated:

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

Package bash was updated:

- Add patch boo1227807.patch  * Load completion file eveh if a brace expansion is in the
    command line included (boo#1227807)

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.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 cpupower was updated:

- Fix uncore frequency file string (bsc#1221765)  * Print uncore config also for machines using the new cluster API
  A tools-power-turbostat-Expand-probe_intel_uncore_frequency.patch

Package curl was updated:

- Security fix: [bsc#1234068, CVE-2024-11053]  * curl could leak the password used for the first host to the
    followed-to host under certain circumstances.
  * netrc: address several netrc parser flaws
  * Add curl-CVE-2024-11053.patch

- Security fix: [bsc#1232528, CVE-2024-9681]
  * HSTS subdomain overwrites parent cache entry
  * Add curl-CVE-2024-9681.patch

- Make special characters in URL work with aws-sigv4 [bsc#1230516]
  * http_aws_sigv4: canonicalize the query [fc76a24c]
  * test439: verify query canonization for aws-sigv4 [65661016]
  * http_aws_sigv4: skip the op if the query pair is zero bytes [16bdc09e]
  * aws_sigv4: the query canon code miscounted URL encoded input [a1532a33]
  * http_aws_sigv4: canonicalise valueless query params [bbba69da]
  * aws-sigv4: url encode the canonical path [768909d8]
  * Add upstream patches:
  - curl-aws_sigv4-canonicalize-the-query.patch
  - curl-aws_sigv4-verify-query-canonization.patch
  - curl-aws_sigv4-skip-the-op-if-the-query-pair-is-zero-bytes.patch
  - curl-aws_sigv4-the-query-canon-code-miscounted-url-encoded-input.patch
  - curl-aws_sigv4-canonicalise-valueless-query-params.patch
  - curl-aws_sigv4-url-encode-the-canonical-path.patch

Package deltarpm was updated:

- update to deltarpm-3.6.5  * support for archive files bigger than 2GByte [bnc#1230547]

Package lvm2 was updated:

- LVM2 mirror attached to another node couldn't be converted into linear LV (bsc#1231796)  + bug-1231796_lvconvert-fix-lvconvert-m-0-for-in-sync-legs.patch

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 055+suse.396.g701c6212:  * fix(dasd-rules): handle all possible options in `rd.dasd` (bsc#1230110)

- Update to version 055+suse.394.ga838b0c7:
  * fix(zfcp_rules): check for presence of legacy rules (bsc#1230330)

Package e2fsprogs was updated:

- resize2fs-Check-number-of-group-descriptors-only-if-.patch: resize2fs: Check  number of group descriptors only if meta_bg is disabled (bsc#1230145)

Package glib2 was updated:

- 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:

- tcache-thread-shutdown.patch: malloc: Initiate tcache shutdown even  without allocations (bsc#1228661, BZ #28028)

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:

- 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

- Fix OOM error in loading loopback file (bsc#1230840)
  * 0001-tpm-Skip-loopback-image-measurement.patch

- grub2.spec: Add ofnet to signed grub.elf to support powerpc net boot
  installation when secure boot is enabled (bsc#1217761) (bsc#1228866)
- Improved check for disk device when looking for PReP partition
  * 0004-Introduce-prep_load_env-command.patch

Package kernel-default was updated:

- sch/netem: fix use after free in netem_dequeue (CVE-2024-46800  bsc#1230827).
- commit 4fa3f93

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

- idpf: fix UAFs when destroying the queues (CVE-2024-44932
  bsc#1229808).
- idpf: fix memory leaks and crashes while performing a soft reset
  (CVE-2024-44964 bsc#1230220).
- commit 4316b61

- media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED
  in uvc_parse_format (CVE-2024-53104 bsc#1234025).
- commit 1c41c2f

- can: j1939: j1939_session_new(): fix skb reference counting
  (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: 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: 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).
- 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).
- iTCO_wdt: mask NMI_NOW bit for update_no_reboot_bit() call
  (git-fixes).
- HID: wacom: Interpret tilt data from Intuos Pro BT as signed
  values (git-fixes).
- commit 6f2f0c6

- arm64/uprobes: change the uprobe_opcode_t typedef to fix the sparse warning (git-fixes)
  Refresh patches.suse/arm64-probes-Fix-uprobes-for-big-endian-kernels.patch.
- commit 8fb43aa

- kABI: Restore exported __arm_smccc_sve_check (git-fixes)
- commit c8e82c2

- USB: serial: io_edgeport: fix use after free in debug printk (CVE-2024-50267 bsc#1233456)
- commit 5a7c927

- kernel.h: split out COUNT_ARGS() and CONCATENATE() to args.h (git-fixes)
- commit ce86139

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

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

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

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

- arm64/sve: Discard stale CPU state when handling SVE traps (git-fixes)
- commit 019ef42

- 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).
- powerpc/asm: Remove UPD_CONSTR after GCC 4.9 removal
  (bsc#1194869).
- powerpc: remove GCC version check for UPD_CONSTR (bsc#1194869).
- commit 2d82b73

- net/mlx5: Unregister notifier on eswitch init failure
  (git-fixes).
- igb: Fix not clearing TimeSync interrupts for 82580 (git-fixes).
- net/mlx5e: Take state lock during tx timeout reporter
  (git-fixes).
- net/mlx5e: Correct snprintf truncation handling for fw_version
  buffer used by representors (git-fixes).
- net/mlx5e: Correct snprintf truncation handling for fw_version
  buffer (git-fixes).
- iavf: in iavf_down, disable queues when removing the driver
  (git-fixes).
- commit c073e57

- net: ena: Fix potential sign extension issue (git-fixes).
- Refresh
  patches.suse/net-ena-Fix-redundant-device-NUMA-node-override.patch.
- commit f3d6416

- idpf: distinguish vports by the dev_port attribute (git-fixes).
- Refresh patches.suse/0001-idpf-extend-tx-watchdog-timeout.patch.
- commit 3fa63a5

- vdpa/mlx5: preserve CVQ vringh index (git-fixes).
- Refresh patches.suse/vdpa-mlx5-Allow-CVQ-size-changes.patch.
- commit dbac474

- net/mlx5: Drain health before unregistering devlink (git-fixes).
- Refresh
  patches.suse/net-mlx5-Register-devlink-first-under-devlink-lock.patch.
- commit fa0f96d

- iavf: send VLAN offloading caps once after VFR (git-fixes).
- Refresh
  patches.suse/iavf-fix-a-deadlock-caused-by-rtnl-and-driver-s-lock.patch.
- commit 39965fe

- net/mlx5: Use recovery timeout on sync reset flow (git-fixes).
- Refresh
  patches.suse/net-mlx5-Fix-missing-lock-on-sync-reset-reload.patch.
- commit 0f9e3d5

- bnxt_en: Reserve rings after PCIe AER recovery if NIC interface
  is down (git-fixes).
- net/mlx5e: CT: Fix null-ptr-deref in add rule err flow
  (git-fixes).
- net/mlx5e: kTLS, Fix incorrect page refcounting (git-fixes).
- net/mlx5: fs, lock FTE when checking if active (git-fixes).
- ice: change q_index variable type to s16 to store -1 value
  (git-fixes).
- ice: Fix netif_is_ice() in Safe Mode (git-fixes).
- ice: fix VLAN replay after reset (git-fixes).
- net/mlx5: Added cond_resched() to crdump collection (git-fixes).
- igb: Always call igb_xdp_ring_update_tail() under Tx lock
  (git-fixes).
- ice: fix accounting for filters shared by multiple VSIs
  (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 modes to ptys2ethtool_map
  (git-fixes).
- net/mlx5: Update the list of the PCI supported devices
  (git-fixes).
- igc: Unlock on error in igc_io_resume() (git-fixes).
- ice: fix ICE_LAST_OFFSET formula (git-fixes).
- cxgb4: add forgotten u64 ivlan cast before shift (git-fixes).
- net/mlx5e: Correctly report errors for ethtool rx flows
  (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).
- net/mlx5e: Add a check for the return value from
  mlx5_port_set_eth_ptys (git-fixes).
- net/mlx5: Lag, don't use the hardcoded value of the first port
  (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).
- 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).
- i40e: Fix XDP program unloading while removing the driver
  (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).
- 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).
- 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: 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).
- Revert &amp;quot;ixgbe: Manual AN-37 for troublesome link partners for
  X550 SFI&amp;quot; (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_flow_attr() for flow_spec
  (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 the PCI-AER routines (git-fixes).
- bnxt_en: refactor reset close code (git-fixes).
- ice: tc: allow zero flags in parsing tc flower (git-fixes).
- net/mlx5: Lag, restore buckets number to default after hash
  LAG deactivation (git-fixes).
- net: ena: Wrong missing IO completions check order (git-fixes).
- net/mlx5e: HTB, Fix inconsistencies with QoS SQs number
  (git-fixes).
- net/mlx5: Correctly compare pkt reformat ids (git-fixes).
- bnxt_en: Reset PTP tx_avail after possible firmware reset
  (git-fixes).
- ixgbe: avoid sleeping allocation in ixgbe_ipsec_vf_add_sa()
  (git-fixes).
- igb: Fix missing time sync events (git-fixes).
- igc: Fix missing time sync events (git-fixes).
- net: ena: Remove ena_select_queue (git-fixes).
- ice: virtchnl: stop pretending to support RSS over AQ or
  registers (git-fixes).
- idpf: disable local BH when scheduling napi for marker packets
  (git-fixes).
- net/mlx5e: Change the warning when ignore_flow_level is not
  supported (git-fixes).
- i40e: disable NAPI right after disabling irqs when handling
  xsk_pool (git-fixes).
- ixgbe: {dis, en}able irqs in ixgbe_txrx_ring_{dis, en}able
  (git-fixes).
- igb: extend PTP timestamp adjustments to i211 (git-fixes).
- tun: Fix xdp_rxq_info's queue_index when detaching (git-fixes).
- igc: Remove temporary workaround (git-fixes).
- i40e: take into account XDP Tx queues when stopping rings
  (git-fixes).
- i40e: avoid double calling i40e_pf_rxq_wait() (git-fixes).
- i40e: Fix waiting for queues of all VSIs to be disabled
  (git-fixes).
- idpf: avoid compiler padding in virtchnl2_ptype struct
  (git-fixes).
- gve: Fix skb truesize underestimation (git-fixes).
- net/mlx5e: Allow software parsing when IPsec crypto is enabled
  (git-fixes).
- net/mlx5: Use mlx5 device constant for selecting CQ period
  mode for ASO (git-fixes).
- net/mlx5: DR, Can't go to uplink vport on RX rule (git-fixes).
- net/mlx5: DR, Use the right GVMI number for drop action
  (git-fixes).
- bnxt_en: Wait for FLR to complete during probe (git-fixes).
- igc: Fix hicredit calculation (git-fixes).
- i40e: Restore VF MSI-X state during PCI reset (git-fixes).
- i40e: fix use-after-free in i40e_aqc_add_filters() (git-fixes).
- bnxt_en: Remove mis-applied code from bnxt_cfg_ntp_filters()
  (git-fixes).
- igc: Check VLAN EtherType mask (git-fixes).
- igc: Check VLAN TCI mask (git-fixes).
- igc: Report VLAN EtherType matching back to user (git-fixes).
- i40e: Fix filter input checks to prevent config with invalid
  values (git-fixes).
- ice: Shut down VSI with &amp;quot;link-down-on-close&amp;quot; enabled
  (git-fixes).
- ice: Fix link_down_on_close message (git-fixes).
- idpf: avoid compiler introduced padding in virtchnl2_rss_key
  struct (git-fixes).
- idpf: fix corrupted frames and skb leaks in singleq mode
  (git-fixes).
- sfc: fix a double-free bug in efx_probe_filters (git-fixes).
- net/mlx5: Fix fw tracer first block check (git-fixes).
- net/mlx5e: fix a potential double-free in fs_udp_create_groups
  (git-fixes).
- net/mlx5e: Fix slab-out-of-bounds in
  mlx5_query_nic_vport_mac_list() (git-fixes).
- net/mlx5e: fix double free of encap_header (git-fixes).
- iavf: Introduce new state machines for flow director
  (git-fixes).
- net/mlx5e: Fix possible deadlock on mlx5e_tx_timeout_work
  (git-fixes).
- iavf: validate tx_coalesce_usecs even if rx_coalesce_usecs is
  zero (git-fixes).
- net/mlx5e: Check return value of snprintf writing to fw_version
  buffer for representors (git-fixes).
- net/mlx5e: Check return value of snprintf writing to fw_version
  buffer (git-fixes).
- net/mlx5e: Reduce the size of icosq_str (git-fixes).
- net/mlx5e: Fix pedit endianness (git-fixes).
- chtls: fix tp-&amp;gt;rcv_tstamp initialization (git-fixes).
- iavf: Fix promiscuous mode configuration flow messages
  (git-fixes).
- iavf: initialize waitqueues before starting watchdog_task
  (git-fixes).
- tun: prevent negative ifindex (git-fixes).
- net/mlx5e: Don't offload internal port if filter device is
  out device (git-fixes).
- net/mlx5: Handle fw tracer change ownership event based on MTRC
  (git-fixes).
- net/mlx5: E-switch, register event handler before arming the
  event (git-fixes).
- ice: reset first in crash dump kernels (git-fixes).
- ice: fix over-shifted variable (git-fixes).
- net/mlx5e: Again mutually exclude RX-FCS and RX-port-timestamp
  (git-fixes).
- ixgbe: fix crash with empty VF macvlan list (git-fixes).
- iavf: do not process adminq tasks when __IAVF_IN_REMOVE_TASK
  is set (git-fixes).
- ixgbe: fix timestamp configuration code (git-fixes).
- net/mlx5: Use RMW accessors for changing LNKCTL (git-fixes).
- sfc: Check firmware supports Ethernet PTP filter (git-fixes).
- ice: avoid executing commands on other ports when driving sync
  (git-fixes).
- ice: ice_aq_check_events: fix off-by-one check when filling
  buffer (git-fixes).
- ice: Fix NULL pointer deref during VF reset (git-fixes).
- ice: fix receive buffer size miscalculation (git-fixes).
- iavf: fix FDIR rule fields masks validation (git-fixes).
- ice: Block switchdev mode when ADQ is active and vice versa
  (git-fixes).
- sfc: don't unregister flow_indr if it was never registered
  (git-fixes).
- net/mlx5: Skip clock update work when device is in error state
  (git-fixes).
- net/mlx5: LAG, Check correct bucket when modifying LAG
  (git-fixes).
- net/mlx5: Allow 0 for total host VFs (git-fixes).
- drivers: net: prevent tun_build_skb() to exceed the packet
  size limit (git-fixes).
- net/mlx5e: Move representor neigh cleanup to profile cleanup_tx
  (git-fixes).
- net/mlx5e: Fix crash moving to switchdev mode when ntuple
  offload is set (git-fixes).
- net/mlx5e: fix return value check in
  mlx5e_ipsec_remove_trailer() (git-fixes).
- net/mlx5: fix potential memory leak in mlx5e_init_rep_rx
  (git-fixes).
- net/mlx5: DR, fix memory leak in mlx5dr_cmd_create_reformat_ctx
  (git-fixes).
- net/mlx5e: fix double free in
  macsec_fs_tx_create_crypto_table_groups (git-fixes).
- commit 8552b15

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

- netdevsim: Add trailing zero to terminate the string
  in nsim_nexthop_bucket_activity_write() (CVE-2024-50259
  bsc#1233214).
- commit 3b589d0

- Update patches.suse/can-bcm-Fix-UAF-in-bcm_proc_show.patch
  (git-fixes CVE-2023-52922 bsc#1233977).
- commit 624f722

- Update
  patches.suse/ACPI-CPPC-Make-rmw_lock-a-raw_spin_lock.patch
  (git-fixes CVE-2024-50249 bsc#1233197).
- Update
  patches.suse/ASoC-stm32-spdifrx-fix-dma-channel-release-in-stm32_.patch
  (git-fixes CVE-2024-50292 bsc#1233481).
- 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-core-zero-initialize-the-report-buffer.patch
  (git-fixes CVE-2024-50302 bsc#1233491).
- Update
  patches.suse/KVM-arm64-vgic-v2-Check-for-non-NULL-vCPU-in-vgic_v2.patch
  (git-fixes CVE-2024-36953 bsc#1225812).
- 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/arm64-tlb-Fix-TLBI-RANGE-operand.patch
  (bsc#1229585 CVE-2024-35980 bsc#1224574).
- 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
  (git-fixes 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/erofs-fix-pcluster-use-after-free-on-UP-platforms.patch
  (git-fixes CVE-2022-48674 bsc#1223942).
- Update
  patches.suse/filelock-fix-potential-use-after-free-in-posix_lock_inode.patch
  (git-fixes CVE-2024-41049 bsc#1228486).
- Update
  patches.suse/media-cx24116-prevent-overflows-on-SNR-calculus.patch
  (git-fixes CVE-2024-50290 bsc#1233479).
- Update
  patches.suse/media-dvb-usb-v2-af9035-Fix-null-ptr-deref-in-af9035.patch
  (stable-fixes CVE-2023-52915 bsc#1230270).
- Update
  patches.suse/media-pci-cx23885-check-cx23885_vdev_init-return.patch
  (stable-fixes CVE-2023-52918 bsc#1232047).
- 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/net-drop-bad-gso-csum_start-and-offset-in-virtio_net.patch
  (git-fixes CVE-2024-43897 bsc#1229752).
- Update patches.suse/net-missing-check-virtio.patch (git-fixes
  CVE-2024-43817 bsc#1229312).
- Update
  patches.suse/net-relax-socket-state-check-at-accept-time.patch
  (git-fixes CVE-2024-36484 bsc#1226872).
- 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/rcu-tasks-Fix-show_rcu_tasks_trace_gp_kthread-buffer-overflow.patch
  (bsc#1226631 CVE-2024-38577).
- 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/staging-iio-frequency-ad9832-fix-division-by-zero-in.patch
  (git-fixes CVE-2024-50233 bsc#1233210).
- 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).
- commit 5ad850f

- 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 965f18d

- 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 bb8ec61

- kexec: fix a memory leak in crash_shrink_memory() (git-fixes).
- commit 67db122

- security/keys: fix slab-out-of-bounds in key_task_permission
  (CVE-2024-50301 bsc#1233490).
- commit b8c1415

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

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

- posix-cpu-timers: Clear TICK_DEP_BIT_POSIX_TIMER on clone
  (bsc#1234098).
  +KABI restoration patch
- commit e4b780d

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

- media: cx24116: prevent overflows on SNR calculus
  (CVE-2024-50290 bsc#1233479).
- commit c59cd01

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

- 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-pci: fix race condition between reset and
  nvme_dev_disable() (git-fixes bsc#1232888 CVE-2024-50135).
- commit 9354fff

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

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

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

- PCI: keystone: Set mode as Root Complex for &amp;quot;ti,keystone-pcie&amp;quot;
  compatible (git-fixes).
- PCI: j721e: Deassert PERST# after a delay of PCIE_T_PVPERL_MS
  milliseconds (git-fixes).
- PCI: endpoint: Clear secondary (not primary) EPC in
  pci_epc_remove_epf() (git-fixes).
- PCI: Add T_PVPERL macro (git-fixes).
- commit ae00716

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

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

- net: esp: fix bad handling of pages from page_pool
  (CVE-2024-26953 bsc#1223656).
  Back-port by using `page_pool_return_skb_page()`.
  Original patch uses `napi_pp_put_page()` which was only introduced later
  and is a renamed and slightly extended version of
  `page_pool_return_skb_page()`.
- commit 533a05f

- HID: core: zero-initialize the report buffer (CVE-2024-50302
  bsc#1233491).
- commit 086ff16

- vsock/virtio: Initialization of the dangling pointer occurring
  in vsk-&amp;gt;trans (CVE-2024-50264 bsc#1233453).
- commit 008fbbf

- Input: i8042 - add TUXEDO Stellaris 15 Slim Gen6 AMD to i8042
  quirk table (git-fixes).
- commit afbd0bc

- Input: i8042 - add another board name for TUXEDO Stellaris
  Gen5 AMD line (git-fixes).
- commit 5a2b5e0

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

- net: arc: fix the device for dma_map_single/dma_unmap_single
  (CVE-2024-50295 bsc#1233484).
- 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 56d9e2a

- Bluetooth: SCO: Fix UAF on sco_sock_timeout (CVE-2024-50125
  bsc#1232928).
- commit 9dd8cd5

- Input: i8042 - add TUXEDO Stellaris 16 Gen5 AMD to i8042 quirk
  table (git-fixes).
- commit d68dfa0

- Update
  patches.suse/Bluetooth-ISO-Fix-UAF-on-iso_sock_timeout.patch
  (CVE-2024-50124 bsc#1232926).
  Revert to upstream version of 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 f3fab2d

- Input: i8042 - add Fujitsu Lifebook E756 to i8042 quirk table
  (git-fixes).
- commit 0792816

- Input: i8042 - add Ayaneo Kun to i8042 quirk table (git-fixes).
- commit 64769ef

- Bluetooth: SCO: Fix UAF on sco_sock_timeout (CVE-2024-50125
  bsc#1232928).
- commit f9d799e

- blk-throttle: Fix io statistics for cgroup v1 (bsc#1233528).
- commit 8c6ab5e

- Update
  patches.suse/ACPI-CPPC-Make-rmw_lock-a-raw_spin_lock.patch
  (git-fixes CVE-2024-50249 bsc#1233197).
- Update
  patches.suse/ASoC-stm32-spdifrx-fix-dma-channel-release-in-stm32_.patch
  (git-fixes CVE-2024-50292 bsc#1233481).
- 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-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/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
  (git-fixes 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/media-cx24116-prevent-overflows-on-SNR-calculus.patch
  (git-fixes CVE-2024-50290 bsc#1233479).
- Update
  patches.suse/media-pci-cx23885-check-cx23885_vdev_init-return.patch
  (stable-fixes CVE-2023-52918 bsc#1232047).
- 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/security-keys-fix-slab-out-of-bounds-in-key_task_per.patch
  (git-fixes CVE-2024-50301 bsc#1233490).
- Update
  patches.suse/staging-iio-frequency-ad9832-fix-division-by-zero-in.patch
  (git-fixes CVE-2024-50233 bsc#1233210).
- 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).
- commit 2084c99

- Update patches.suse/can-bcm-Fix-UAF-in-bcm_proc_show.patch
  (git-fixes CVE-2023-52922 bsc#1233977).
- commit 82c5a0a

- modpost: remove incorrect code in do_eisa_entry() (git-fixes).
- rtc: ab-eoz9: don't fail temperature reads on undervoltage
  notification (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: st-lpc: Use IRQF_NO_AUTOEN flag in request_irq()
  (git-fixes).
- serial: 8250: omap: Move pm_runtime_get_sync (git-fixes).
- commit 1d73f32

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

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

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

- ASoC: amd: yc: Fix for enabling DMIC on acp6x via _DSD entry
  (git-fixes).
- ALSA: hda/realtek: Update ALC225 depop procedure (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).
- 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).
- 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: 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).
- commit 75ee7d4

- io_uring/rw: fix missing NOWAIT check for O_DIRECT start write
  (bsc#1233548 CVE-2024-53052).
- commit db98042

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

- Bluetooth: MGMT: Fix slab-use-after-free Read in
  set_powered_sync (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).
- spi: Fix acpi deferred irq probe (git-fixes).
- spi: atmel-quadspi: Fix register name in verbose logging
  function (git-fixes).
- power: supply: bq27xxx: Fix registers of bq27426 (git-fixes).
- power: supply: core: Remove might_sleep() from
  power_supply_put() (git-fixes).
- commit 01635d8

- Refresh
  patches.suse/initramfs-avoid-filename-buffer-overrun.patch.
- commit 145c949

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

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

- net: relax socket state check at accept time (git-fixes).
- commit 75020f0

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

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

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

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

- idpf: avoid vport access in idpf_get_link_ksettings
  (CVE-2024-50274 bsc#1233463).
- commit 8971b65

- i40e: fix race condition by adding filter's intermediate sync
  state (CVE-2024-53088 bsc#1233580).
- i40e: fix i40e_count_filters() to count only active/new filters
  (CVE-2024-53088 bsc#1233580).
- commit 2251801

- hwmon: (tps23861) Fix reporting of negative temperatures
  (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).
- commit eb819fb

- nilfs2: fix potential oob read in nilfs_btree_check_delete()
  (bsc#1232187 CVE-2024-47757).
- commit d813a1d

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

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

- media: dvbdev: prevent the risk of out of memory access
  (CVE-2024-53063 bsc#1233557).
- commit 52a90e5

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

- mptcp: never allow the PM to close a listener subflow
  (CVE-2021-47594 bsc#1226560).
- commit 639c494

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

- scsi: sd_zbc: Use kvzalloc() to allocate REPORT ZONES buffer
  (git-fixes).
- scsi: scsi_transport_fc: Allow setting rport state to current
  state (git-fixes).
- commit 502ca69

- media: s5p-jpeg: prevent buffer overflows (CVE-2024-53061
  bsc#1233555).
- commit aef5475

- firmware: arm_scmi: Fix slab-use-after-free in
  scmi_bus_notifier() (CVE-2024-53068 bsc#1233561).
- commit e507b37

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

- ibmvnic: Ensure login failure recovery is safe from other resets
  (bsc#1233150).
- ibmvnic: Do partial reset on login failure (bsc#1233150).
- ibmvnic: Handle DMA unmapping of login buffs in release
  functions (bsc#1233150).
- ibmvnic: Unmap DMA login rsp buffer on send login fail
  (bsc#1233150).
- ibmvnic: Enforce stronger sanity checks on login response
  (bsc#1233150).
- commit 10ef085

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

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

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

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

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

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

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

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

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

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

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

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

- RDMA/hns: Remove unnecessary QP type checks (git-fixes)
- commit 5a2c4d9

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

- RDMA/hns: Add clear_hem return value to log (git-fixes)
- commit ff0016c

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

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

- drm/amd: Fix initialization mistake for NBIO 7.7.0
  (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).
- commit 46d58c4

- drm/etnaviv: Request pages from DMA32 zone on addressing_limited
  (git-fixes).
- drm/msm/dpu: cast crtc_clk calculation to u64 in
  _dpu_core_perf_calc_clk() (git-fixes).
- drm/msm/adreno: Use IRQF_NO_AUTOEN flag in request_irq()
  (git-fixes).
- drm/panfrost: Remove unused id_mask from struct panfrost_model
  (git-fixes).
- drm/bridge: tc358767: Fix link properties discovery (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/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: 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: 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).
- 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).
- 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 4ce629c

- x86/kvm: fix is_stale_page_fault() (bsc#1221333).
- commit 332e968

- 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: 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).
- commit 5f244c5

- 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 9c28790

- drm/bridge: tc358768: Fix DSI command tx (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).
- net: usb: qmi_wwan: add Fibocom FG132 0x0112 composition
  (stable-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).
- HID: multitouch: Add quirk for HONOR MagicBook Art 14 touchpad
  (stable-fixes).
- HID: multitouch: Add support for B2402FVA track point
  (stable-fixes).
- commit 8da6f10

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

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

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

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

- tty: n_gsm: Fix use-after-free in gsm_cleanup_mux (CVE-2024-50073 bsc#1232520)
- commit 3e72b22

- 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).
- 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: prevent NULL pointer dereference if ATIF is not
  supported (git-fixes).
- ALSA: usb-audio: Add quirk for HP 320 FHD Webcam (stable-fixes).
- ALSA: hda/realtek: Fix headset mic on TUXEDO Gemini 17 Gen3
  (stable-fixes).
- media: dvb-usb-v2: af9035: fix missing unlock (git-fixes).
- media: dvb-usb-v2: af9035: Fix null-ptr-deref in
  af9035_i2c_master_xfer (stable-fixes).
- commit 8316036

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

- ALSA: firewire-lib: Avoid division by zero in
  apply_constraint_to_size() (CVE-2024-50205 bsc#1233293).
- commit d31c5c9

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

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

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

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

- thermal: intel: int340x: processor: Fix warning during module
  unload (CVE-2024-50093 bsc#1232877).
- commit ef3b2be

- net: phy: dp83869: fix memory corruption when enabling fiber
  (CVE-2024-50188 bsc#1233107).
- commit a27c339

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

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

- Update
  patches.suse/0001-PCI-keystone-Fix-if-statement-expression-in-ks_pcie_.patch
  (git-fixes CVE-2024-47756 bsc#1232185).
- 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/0544-drm-amdgpu-fix-use-after-free-during-gpu-recovery.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225 jsc#PED-2849
  CVE-2022-48990 bsc#1232028).
- Update
  patches.suse/0551-drm-amd-display-fix-array-index-out-of-bound-error-i.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225 jsc#PED-2849
  CVE-2022-48979 bsc#1232293).
- Update patches.suse/ACPI-PAD-fix-crash-in-exit_round_robin.patch
  (stable-fixes CVE-2024-49935 bsc#1232370).
- 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-asihpi-Fix-potential-OOB-array-access.patch
  (stable-fixes CVE-2024-50007 bsc#1232394).
- 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-Call-iso_exit-on-module-unload.patch
  (git-fixes CVE-2024-50078 bsc#1232503).
- Update
  patches.suse/Bluetooth-Fix-crash-when-replugging-CSR-fake-control.patch
  (git-fixes CVE-2022-48982 bsc#1231978).
- 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/Bluetooth-bnep-fix-wild-memory-access-in-proto_unreg.patch
  (git-fixes CVE-2024-50148 bsc#1233063).
- Update
  patches.suse/HID-amd_sfh-Switch-to-device-managed-dmam_alloc_cohe.patch
  (git-fixes CVE-2024-50189 bsc#1233105).
- Update
  patches.suse/IB-core-Fix-ib_cache_setup_one-error-flow-cleanup.patch
  (git-fixes CVE-2024-47693 bsc#1232013).
- Update
  patches.suse/Input-adp5589-keys-fix-NULL-pointer-dereference.patch
  (git-fixes CVE-2024-49871 bsc#1232287).
- Update
  patches.suse/PCI-keystone-Add-workaround-for-Errata-i2037-AM65x-S.patch
  (stable-fixes CVE-2024-47667 bsc#1231481).
- Update
  patches.suse/RDMA-bnxt_re-Add-a-check-for-memory-allocation.patch
  (git-fixes CVE-2024-50209 bsc#1233114).
- 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-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-mad-Improve-handling-of-timed-out-WRs-of-mad-ag.patch
  (git-fixes CVE-2024-50095 bsc#1232873).
- 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/USB-usbtmc-prevent-kernel-usb-infoleak.patch
  (git-fixes CVE-2024-47671 bsc#1231541).
- 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/bpf-Fix-helper-writes-to-read-only-maps.patch
  (git-fixes CVE-2024-49861 bsc#1232254).
- 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#1231181 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/ceph-remove-the-incorrect-Fw-reference-check-when-dir.patch
  (bsc#1231180 CVE-2024-50179 bsc#1233123).
- 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-Guard-against-bad-data-for-ATIF-ACPI-method.patch
  (git-fixes CVE-2024-50117 bsc#1232897).
- 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-Add-null-check-for-afb-in-amdgpu_dm_.patch
  (stable-fixes bsc#1232335 CVE-2024-49908 CVE-2024-49905
  bsc#1232357).
- Update
  patches.suse/drm-amd-display-Check-null-pointers-before-using-dc-.patch
  (stable-fixes CVE-2024-49907 bsc#1232334).
- 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-system-hang-while-resume-with-TB.patch
  (stable-fixes CVE-2024-50003 bsc#1232385).
- 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-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-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-bridge-tc358767-Check-if-fully-initialized-befor.patch
  (stable-fixes CVE-2024-46810 bsc#1231178).
- 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-omapdrm-Add-missing-check-for-alloc_ordered_work.patch
  (git-fixes CVE-2024-49879 bsc#1232349).
- Update patches.suse/drm-radeon-Fix-encoder-possible_clones.patch
  (git-fixes CVE-2024-50201 bsc#1233104).
- Update
  patches.suse/drm-v3d-Stop-the-active-perfmon-before-being-destroy.patch
  (git-fixes CVE-2024-50031 bsc#1231947).
- Update
  patches.suse/drm-vc4-Stop-the-active-perfmon-before-being-destroy.patch
  (git-fixes CVE-2024-50187 bsc#1233108).
- Update
  patches.suse/exfat-fix-memory-leak-in-exfat_load_bitmap.patch
  (git-fixes CVE-2024-50013 bsc#1232080).
- 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-pxafb-Fix-possible-use-after-free-in-pxafb_tas.patch
  (stable-fixes CVE-2024-49924 bsc#1232364).
- Update patches.suse/fbdev-sisfb-Fix-strbuf-array-overflow.patch
  (stable-fixes CVE-2024-50180 bsc#1233125).
- Update patches.suse/firmware_loader-Block-path-traversal.patch
  (git-fixes CVE-2024-47742 bsc#1232126).
- Update
  patches.suse/fscache-Fix-oops-due-to-race-with-cookie_lru-and-use_cookie.patch
  (jsc#SES-1880 CVE-2022-48989 bsc#1232027).
- Update
  patches.suse/i2c-stm32f7-Do-not-prepare-unprepare-clock-during-ru.patch
  (git-fixes CVE-2024-49985 bsc#1232094).
- 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/iio-light-veml6030-fix-IIO-device-retrieval-from-emb.patch
  (git-fixes CVE-2024-50198 bsc#1233100).
- 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/media-venus-fix-use-after-free-bug-in-venus_remove-d.patch
  (git-fixes CVE-2024-49981 bsc#1232098).
- 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/nbd-fix-race-between-timeout-and-normal-completion.patch
  (bsc#1230918 CVE-2024-49855 bsc#1232195).
- 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/netdevsim-use-cond_resched-in-nsim_dev_trap_report_w.patch
  (git-fixes CVE-2024-50155 bsc#1233035).
- 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-kernel-bug-due-to-missing-clearing-of-buffer-delay-flag.patch
  (git-fixes CVE-2024-50116 bsc#1232892).
- 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/nilfs2-fix-state-management-in-error-path-of-log-writing-function.patch
  (git-fixes CVE-2024-47669 bsc#1231474).
- Update
  patches.suse/nouveau-dmem-Fix-vulnerability-in-migrate_to_ram-upo.patch
  (git-fixes CVE-2024-50096 bsc#1232870).
- 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/nvmet-auth-assign-dh_key-to-NULL-after-kfree_sensiti.patch
  (git-fixes CVE-2024-50215 bsc#1233189).
- 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/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-pass-u64-to-ocfs2_truncate_inline-maybe-overflow.patch
  (git-fixes CVE-2024-50218 bsc#1233191).
- 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/platform-x86-panasonic-laptop-Fix-SINF-array-out-of-.patch
  (git-fixes CVE-2024-46859 bsc#1231089).
- Update
  patches.suse/scsi-elx-libefc-Fix-potential-use-after-free-in-efc_nport_vport_del.patch
  (git-fixes CVE-2024-49852 bsc#1232819).
- 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-Ensure-DA_ID-handling-completion-before-de.patch
  (bsc#1232757 CVE-2024-50183 bsc#1233130).
- Update
  patches.suse/scsi-lpfc-Handle-mailbox-timeouts-in-lpfc_get_sfp_in.patch
  (bsc#1228857 CVE-2024-46842 bsc#1231101).
- Update
  patches.suse/scsi-lpfc-Validate-hdwq-pointers-before-dereferencin.patch
  (bsc#1229429 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/scsi-wd33c93-Don-t-use-stale-scsi_pointer-value.patch
  (git-fixes CVE-2024-50026 bsc#1231952).
- 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/staging-iio-frequency-ad9834-Validate-frequency-para.patch
  (git-fixes CVE-2024-47663 bsc#1231441).
- Update
  patches.suse/tpm-Clean-up-TPM-space-after-command-failure.patch
  (git-fixes CVE-2024-49851 bsc#1232134).
- Update
  patches.suse/tracing-Consider-the-NULL-character-when-validating-the-event-length.patch
  (git-fixes CVE-2024-50131 bsc#1232896).
- Update
  patches.suse/uprobe-avoid-out-of-bounds-memory-access-of-fetching-args.patch
  (git-fixes CVE-2024-50067 bsc#1232416).
- Update
  patches.suse/usb-typec-altmode-should-keep-reference-to-parent.patch
  (git-fixes CVE-2024-50150 bsc#1233051).
- Update
  patches.suse/vhost-scsi-null-ptr-dereference-in-vhost_scsi_get_re.patch
  (git-fixes CVE-2024-49863 bsc#1232255).
- 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-mac80211-use-two-phase-skb-reclamation-in-ieee8.patch
  (git-fixes CVE-2024-47713 bsc#1232016).
- 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-wilc1000-fix-potential-RCU-dereference-issue-in.patch
  (git-fixes CVE-2024-47712 bsc#1232017).
- commit e33d75f

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

- 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 ad996bf

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

- Refresh patches.kabi/bpf-callback-fixes-kABI-workaround.patch (bsc#1233350)
- add commit message for the kABI patch
- adapt same struct naming as similar kABI workaround in SLE15-SP6
  (prefixed with &amp;quot;suse_&amp;quot; to make it more obvious its a downstream thing.
- commit b6821d4

- unicode: Don't special case ignorable code points
  (CVE-2024-50089 bsc#1232860).
- commit ba47e72

- mm/memory: add non-anonymous page check in the
  copy_present_page() (bsc#1231646).
- commit 9f5cb06

- irqchip/gic-v3-its: Fix VSYNC referencing an unmapped VPE on
  GIC v4.1 (git-fixes).
- commit 1fa30cf

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

- 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 1772267

- README.BRANCH: drop explicit maintainers
  kbuild already recognizes all downstream branch maintainers an
  merge their PRs so we do not need explicit maintainers for the cve
  branch itself.
- commit cd6f8fb

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

- io_uring: Fix a null-ptr-deref in io_tctx_exit_cb()
  (CVE-2022-48983 bsc#1231959).
- commit cb16389

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

- mptcp: fix double-free on socket dismantle (CVE-2024-26782
  bsc#1222590).
  (cherry picked from commit 03ac3f085c702ef308481c09b021887b5a01d52b)
- mptcp: fix double-free on socket dismantle (CVE-2024-26782
  bsc#1222590).
- commit 7f40404

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

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

- nilfs2: fix potential deadlock with newly created symlinks
  (bsc#1233205 CVE-2024-50229).
- commit 22257d1

- Update
  patches.suse/iio-adc-ad7124-fix-division-by-zero-in-ad7124_set_ch.patch
  (CVE-2024-50232 bsc#1233209 git-fixes).
- commit c0912d0

- Update patches.suse/drm-amd-Guard-against-bad-data-for-ATIF-ACPI-method.patch (git-fixes bsc#1232897 CVE-2024-50117).
- commit 4fc44d0

- Update
  patches.suse/wifi-ath10k-Fix-memory-leak-in-management-tx.patch
  (CVE-2024-50236 bsc#1233212 git-fixes).
- Update
  patches.suse/wifi-iwlegacy-Clear-stale-interrupts-before-resuming.patch
  (CVE-2024-50234 bsc#1233211 stable-fixes).
- Update
  patches.suse/wifi-mac80211-do-not-pass-a-stopped-vif-to-the-drive.patch
  (CVE-2024-50237 bsc#1233216 git-fixes).
- commit bb693c7

- drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape (bsc#1232890 CVE-2024-50134)
- commit f5103e7

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

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

- Fix regression on AMDGPU driver (bsc#1233134)
  Drop a hunk in an AMDGPU fix patch that caused the missing VT console
  and possibly other side-effects.
  Refreshed:
  patches.suse/drm-amd-display-Check-null-pointers-before-using-the.patch.
- commit c4d3cf0

- Update tags
  patches.suse/mm-Avoid-overflows-in-dirty-throttling-logic.patch
  (bsc#1222364 CVE-2024-42131 bsc#1228650).
- commit 42963b8

- 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).
- 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: 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).
- can: c_can: fix {rx,tx}_errors statistics (git-fixes).
- security/keys: fix slab-out-of-bounds in key_task_permission
  (git-fixes).
- HID: core: zero-initialize the report buffer (git-fixes).
- phy: tegra: xusb: Add error pointer check in xusb.c (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).
- mei: use kvmalloc for read buffer (git-fixes).
- genirq/msi: Fix off-by-one error in msi_domain_alloc()
  (git-fixes).
- ACPI: CPPC: Make rmw_lock a raw_spin_lock (git-fixes).
- Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs
  (git-fixes).
- wifi: iwlwifi: mvm: Fix response handling in
  iwl_mvm_send_recovery_cmd() (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: Clear stale interrupts before resuming device
  (stable-fixes).
- ALSA: hda/realtek: Fix headset mic on TUXEDO Stellaris 16 Gen6
  mb1 (stable-fixes).
- ALSA: usb-audio: Add quirks for Dell WD19 dock (stable-fixes).
- ASoC: cs42l51: Fix some error handling paths in cs42l51_probe()
  (git-fixes).
- ALSA: hda/realtek: Limit internal Mic boost on Dell platform
  (stable-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).
- ALSA: hda/realtek: Add subwoofer quirk for Acer Predator G9-593
  (stable-fixes).
- net: usb: usbnet: fix race in probe failure (git-fixes).
- thermal: intel: int340x: processor: Fix warning during module
  unload (git-fixes).
- platform/x86: dell-sysman: add support for alienware products
  (stable-fixes).
- ASoC: qcom: sm8250: add qrb4210-rb2-sndcard compatible string
  (stable-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).
- drm/vboxvideo: Replace fake VLA at end of
  vbva_mouse_pointer_shape with real VLA (stable-fixes).
- platform/surface: aggregator: Fix warning when controller is
  destroyed in probe (git-fixes).
- HID: wacom: Defer calculation of resolution until
  resolution_code is known (git-fixes).
- XHCI: Separate PORT and CAPs macros into dedicated file
  (stable-fixes).
- media: pci: cx23885: check cx23885_vdev_init() return
  (stable-fixes).
- wifi: iwlwifi: mvm: disconnect station vifs if recovery failed
  (stable-fixes).
- commit 4f83ccb

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

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

- pinctrl: ocelot: fix system hang on level based interrupts
  (CVE-2024-50196 bsc#1233113).
- commit 722d7d5

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

- RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages (bsc#1233117 CVE-2024-50208)
- commit da4098a

- cpufreq: exit() callback is optional (CVE-2024-38615
  bsc#1226592).
- commit de52ec2

- cpufreq: Rearrange locking in cpufreq_remove_dev()
  (CVE-2024-38615 bsc#1226592).
- commit f83b7ff

- cpufreq: Split cpufreq_offline() (CVE-2024-38615 bsc#1226592).
- commit 71730ce

- cpufreq: Reorganize checks in cpufreq_offline() (CVE-2024-38615
  bsc#1226592).
- commit c8f486b

- cpufreq: amd-pstate: fix memory leak on CPU EPP exit
  (CVE-2024-40997 bsc#1227853).
- commit bd37b8f

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

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

- be2net: fix potential memory leak in be_xmit() (CVE-2024-50167
  bsc#1233049).
- net/mlx5e: Don't call cleanup on profile rollback failure
  (CVE-2024-50146 bsc#1233056).
- net/mlx5: Fix command bitmask initialization (CVE-2024-50147
  bsc#1233067).
- commit 30967e3

- arm64:uprobe fix the uprobe SWBP_INSN in big-endian (git-fixes)
- commit ef49fc2

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

- drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too (CVE-2024-50108 bsc#1232884)
- commit e6eb1e9

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

- Refresh
  patches.suse/scsi-fnic-Move-flush_work-initialization-out-of-if-b.patch.
- commit c3feb06

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

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

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

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

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

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

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

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

- wifi: cfg80211: check A-MSDU format more carefully (stable-fixes
  CVE-2024-35937 bsc#1224526).
- blacklist.conf: remove the entry that we're just adding
- commit 81bb44e

- x86/mm: Move is_vsyscall_vaddr() into asm/vsyscall.h (bsc#1223202 CVE-2024-26906).
- commit 35585b4

- x86/mm: Disallow vsyscall page read for copy_from_kernel_nofault() (bsc#1223202 CVE-2024-26906).
- commit fd679d8

- Refresh patches.kabi/bpf-bpf_map-kABI-workaround.patch.
- Removed the duplicated check of
  static_assert(sizeof(struct work_struct) &amp;gt;= sizeof(struct rcu_head)).
- Removed unnecessary white-space change in kernel/bpf/syscall.c
- commit d99887e

- Refresh patches.kabi/bpf-bpf_map-kABI-workaround.patch.
  Ensure that the free_after_mult_rcu_gp field fits into struct hole on
  all architecture by cloning struct bpf_map then use static_assert() to
  check.
- commit 9056822

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

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

- net: hisilicon: Fix potential use-after-free in hix5hd2_rx() (bsc#1231979 CVE-2022-48960)
- commit e22014e

- driver core: bus: Fix double free in driver API bus_register()
  (CVE-2024-50055 bsc#1232329).
- commit 90fa355

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

- block: Avoid leaking hctx-&amp;gt;nr_active counter on batched
  completion (bsc#1231923).
- commit 06a9b00

- ipv6: avoid use-after-free in ip6_fragment() (CVE-2022-48956
  bsc#1231893).
- commit c192a62

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

- vhost_vdpa: assign irq bypass producer token correctly
  (bsc#1232174 CVE-2024-47748).
- commit 51b6257

- octeontx2-af: avoid off-by-one read from userspace
  (CVE-2024-36957 bsc#1225762).
- commit 82a42a7

- Update
  patches.suse/scsi-lpfc-Restrict-support-for-32-byte-CDBs-to-specific-HBAs.patch
  (git-fixes bsc#1232757 bsc#1228119).
- commit ba604a8

- ext4: fix timer use-after-free on failed mount (CVE-2024-49960
  bsc#1232395).
- tipc: guard against string buffer overrun (CVE-2024-49995
  bsc#1232432).
- commit 7dec126

- Drop HD-audio conexant patch that caused a regression on Thinkpad (bsc#1228269)
- commit 147923a

- uprobes: fix kernel info leak via &amp;quot;[uprobes]&amp;quot; vma (bsc#1232104
  CVE-2024-49975).
- commit 98e2376

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

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

- 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: 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 acff620

- bpf,perf: Fix perf_event_detach_bpf_prog error handling
  (git-fixes).
- commit 23dff14

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

- uprobe: avoid out-of-bounds memory access of fetching args
  (git-fixes).
- uprobes: encapsulate preparation of uprobe args buffer
  (git-fixes).
- tracing/uprobes: Use trace_event_buffer_reserve() helper
  (git-fixes).
- commit c9bed4e

- fgraph: Change the name of cpuhp state to &amp;quot;fgraph:online&amp;quot;
  (git-fixes).
- fgraph: Fix missing unlock in register_ftrace_graph()
  (git-fixes).
- commit 25b5fcd

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

- tracing/hwlat: Fix a race during cpuhp processing (git-fixes).
- commit da4b9b4

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

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

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

- static_call: Don't make __static_call_return0 static
  (git-fixes).
- Refresh patches.kabi/tracepoint-fix.patch.
- commit e74c3f0

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

- nvmet-auth: assign dh_key to NULL after kfree_sensitive
  (git-fixes).
- nvme-multipath: system fails to create generic nvme device
  (git-fixes).
- nvme-pci: qdepth 1 quirk (git-fixes).
- commit 50acd8c

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

- PCI: Fix pci_enable_acs() support for the ACS quirks
  (bsc#1229019).
- commit d675594

- nfsd: map the EBADMSG to nfserr_io to avoid warning (git-fixes).
- NFSD: Fix NFSv4's PUTPUBFH operation (git-fixes).
- commit 9122478

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

- Update
  patches.suse/IB-core-Implement-a-limit-on-UMAD-receive-List.patch
  (bsc#1228743 CVE-2024-42145 bsc#1223384).
- Update
  patches.suse/aoe-fix-the-potential-use-after-free-problem-in-more.patch
  (bsc#1218562 CVE-2023-6270 CVE-2024-49982 bsc#1232097).
- Update
  patches.suse/fuse-Initialize-beyond-EOF-page-contents-before-setti.patch
  (bsc#1229454 CVE-2024-44947 bsc#1229456).
- Update patches.suse/media-edia-dvbdev-fix-a-use-after-free.patch
  (CVE-2024-27043 bsc#1223824 bsc#1218562).
- commit 1967352

- Update
  patches.suse/i3c-mipi-i3c-hci-Fix-out-of-bounds-access-in-hci_dma.patch
  (git-fixes CVE-2023-52766 bsc#1230620).
- Update
  patches.suse/nfc-nci-fix-possible-NULL-pointer-dereference-in-sen.patch
  (git-fixes CVE-2023-52919 bsc#1231988).
- Update
  patches.suse/tcp-do-not-accept-ACK-of-bytes-we-never-sent.patch
  (CVE-2023-52881 bsc#1225611 bsc#1223384).
- Update patches.suse/wifi-ath11k-fix-htt-pktlog-locking.patch
  (git-fixes CVE-2023-52800 bsc#1230600).
- commit 4af6b80

- Update
  patches.suse/0001-af_unix-Get-user_ns-from-in_skb-in-unix_diag_get_exa.patch
  (bsc#1209290 CVE-2023-28327 CVE-2022-48970 bsc#1231887).
- Update
  patches.suse/ALSA-seq-Fix-function-prototype-mismatch-in-snd_seq_.patch
  (git-fixes CVE-2022-48994 bsc#1232119).
- Update
  patches.suse/ASoC-ops-Check-bounds-for-second-channel-in-snd_soc_.patch
  (git-fixes CVE-2022-48951 bsc#1231929).
- Update
  patches.suse/ASoC-ops-Fix-bounds-check-for-_sx-controls.patch
  (git-fixes CVE-2022-49005 bsc#1232150).
- Update
  patches.suse/ASoC-soc-pcm-Add-NULL-check-in-BE-reparenting.patch
  (git-fixes CVE-2022-48992 bsc#1232071).
- Update
  patches.suse/Bluetooth-Fix-not-cleanup-led-when-bt_init-fails.patch
  (git-fixes CVE-2022-48971 bsc#1232037).
- Update patches.suse/Bluetooth-L2CAP-Fix-u8-overflow.patch
  (CVE-2022-45934 bsc#1205796 CVE-2022-48947 bsc#1231895).
- Update
  patches.suse/HID-core-fix-shift-out-of-bounds-in-hid_report_raw_e.patch
  (git-fixes CVE-2022-48978 bsc#1232038).
- Update
  patches.suse/Input-raydium_ts_i2c-fix-memory-leak-in-raydium_i2c_.patch
  (git-fixes CVE-2022-48995 bsc#1232120).
- Update
  patches.suse/NFC-nci-Bounds-check-struct-nfc_target-arrays.patch
  (git-fixes CVE-2022-48967 bsc#1232304).
- Update
  patches.suse/afs-Fix-server-active-leak-in-afs_put_server.patch
  (git-fixes CVE-2022-49012 bsc#1232005).
- Update
  patches.suse/btrfs-fix-hang-during-unmount-when-stopping-a-space-.patch
  (bsc#1232262 CVE-2024-49867 CVE-2022-48664 bsc#1223524).
- Update
  patches.suse/can-af_can-fix-NULL-pointer-dereference-in-can_rcv_f.patch
  (bsc#1210627 CVE-2023-2166 CVE-2022-48977 bsc#1231883).
- Update
  patches.suse/can-m_can-pci-add-missing-m_can_class_free_dev-in-pr.patch
  (git-fixes CVE-2022-49024 bsc#1232001).
- Update
  patches.suse/char-tpm-Protect-tpm_pm_suspend-with-locks.patch
  (git-fixes CVE-2022-48997 bsc#1232035).
- Update
  patches.suse/drm-shmem-helper-Remove-errant-put-in-error-path.patch
  (git-fixes CVE-2022-48981 bsc#1232229).
- Update
  patches.suse/e100-Fix-possible-use-after-free-in-e100_xmit_prepar.patch
  (git-fixes CVE-2022-49026 bsc#1231997).
- Update
  patches.suse/gpio-amd8111-Fix-PCI-device-reference-count-leak.patch
  (git-fixes CVE-2022-48973 bsc#1232039).
- Update
  patches.suse/gpiolib-fix-memory-leak-in-gpiochip_setup_dev.patch
  (git-fixes CVE-2022-48975 bsc#1231885).
- Update
  patches.suse/hwmon-coretemp-Check-for-null-before-removing-sysfs-.patch
  (git-fixes CVE-2022-49010 bsc#1232172).
- Update
  patches.suse/hwmon-coretemp-fix-pci-device-refcount-leak-in-nv1a_.patch
  (git-fixes CVE-2022-49011 bsc#1232006).
- Update
  patches.suse/hwmon-ibmpex-Fix-possible-UAF-when-ibmpex_register_b.patch
  (git-fixes CVE-2022-49029 bsc#1231995).
- Update
  patches.suse/iavf-Fix-error-handling-in-iavf_init_module.patch
  (jsc#SLE-18385 CVE-2022-49027 bsc#1232007).
- Update
  patches.suse/igb-Initialize-mailbox-message-for-VF-reset.patch
  (jsc#SLE-18379 CVE-2022-48949 bsc#1231897).
- Update
  patches.suse/iio-health-afe4403-Fix-oob-read-in-afe4403_read_raw.patch
  (git-fixes CVE-2022-49031 bsc#1231992).
- Update
  patches.suse/iio-health-afe4404-Fix-oob-read-in-afe4404_-read-wri.patch
  (git-fixes CVE-2022-49032 bsc#1231991).
- Update
  patches.suse/iommu-vt-d-Fix-PCI-device-refcount-leak-in-dmar_dev_scope_init
  (git-fixes CVE-2022-49002 bsc#1232133).
- Update
  patches.suse/iommu-vt-d-Fix-PCI-device-refcount-leak-in-has_external_pci
  (git-fixes CVE-2022-49000 bsc#1232123).
- Update
  patches.suse/ipv4-Handle-attempt-to-delete-multipath-route-when-f.patch
  (bsc#1204171 CVE-2022-3435 CVE-2022-48999 bsc#1231936).
- Update
  patches.suse/ixgbevf-Fix-resource-leak-in-ixgbevf_init_module.patch
  (git-fixes CVE-2022-49028 bsc#1231996).
- Update
  patches.suse/mac802154-fix-missing-INIT_LIST_HEAD-in-ieee802154_i.patch
  (git-fixes CVE-2022-48972 bsc#1232025).
- Update
  patches.suse/media-v4l2-dv-timings.c-fix-too-strict-blanking-sani.patch
  (git-fixes CVE-2022-48987 bsc#1232067).
- Update
  patches.suse/msft-hv-2684-net-mana-Fix-race-on-per-CQ-variable-napi-work_done.patch
  (git-fixes bsc#1206188 CVE-2022-48985 bsc#1231958).
- Update
  patches.suse/net-ethernet-nixge-fix-NULL-dereference.patch
  (git-fixes CVE-2022-49019 bsc#1231940).
- Update
  patches.suse/net-mdio-fix-unbalanced-fwnode-reference-count-in-md.patch
  (git-fixes CVE-2022-48961 bsc#1232108).
- Update
  patches.suse/net-mdiobus-fix-unbalanced-node-reference-count.patch
  (git-fixes CVE-2022-49016 bsc#1231937).
- Update
  patches.suse/net-mlx5e-Fix-use-after-free-when-reverting-terminat.patch
  (jsc#SLE-19253 CVE-2022-49025 bsc#1231960).
- Update
  patches.suse/net-phy-fix-null-ptr-deref-while-probe-failed.patch
  (git-fixes CVE-2022-49021 bsc#1231939).
- Update
  patches.suse/net-thunderbolt-fix-memory-leak-in-tbnet_open.patch
  (git-fixes CVE-2022-48955 bsc#1231892).
- Update
  patches.suse/net-tun-Fix-use-after-free-in-tun_detach.patch
  (git-fixes CVE-2022-49014 bsc#1231890).
- Update
  patches.suse/nilfs2-fix-NULL-pointer-dereference-in-nilfs_palloc_.patch
  (git-fixes CVE-2022-49007 bsc#1232170).
- Update
  patches.suse/nvme-fix-SRCU-protection-of-nvme_ns_head-list.patch
  (git-fixes CVE-2022-49003 bsc#1232136).
- Update
  patches.suse/octeontx2-pf-Fix-potential-memory-leak-in-otx2_init_.patch
  (jsc#SLE-24682 CVE-2022-48968 bsc#1232237).
- Update
  patches.suse/rtc-cmos-Fix-event-handler-registration-ordering-iss.patch
  (git-fixes CVE-2022-48953 bsc#1231941).
- Update patches.suse/s390-qeth-fix-use-after-free-in-hsci.patch
  (bsc#1210449 git-fixes CVE-2022-48954 bsc#1231972).
- Update
  patches.suse/tracing-Free-buffers-when-a-used-dynamic-event-is-removed.patch
  (git-fixes CVE-2022-49006 bsc#1232163).
- Update
  patches.suse/udf-Fix-preallocation-discarding-at-indirect-extent-.patch
  (bsc#1213034 CVE-2022-48946 bsc#1231888).
- Update
  patches.suse/usb-gadget-uvc-Prevent-buffer-overflow-in-setup-hand.patch
  (git-fixes CVE-2022-48948 bsc#1231896).
- Update
  patches.suse/wifi-cfg80211-fix-buffer-overflow-in-elem-comparison.patch
  (git-fixes CVE-2022-49023 bsc#1231961).
- Update
  patches.suse/wifi-mac8021-fix-possible-oob-access-in-ieee80211_ge.patch
  (git-fixes CVE-2022-49022 bsc#1231962).
- Update
  patches.suse/xen-netfront-Fix-NULL-sring-after-live-migration.patch
  (git-fixes CVE-2022-48969 bsc#1232026).
- commit 2377658

- Update
  patches.suse/drm-vc4-kms-Add-missing-drm_crtc_commit_put.patch
  (git-fixes CVE-2021-47534 bsc#1230903).
- Update patches.suse/phy-mdio-fix-memory-leak.patch (git-fixes
  stable-5.14.12 CVE-2021-47416 bsc#1225336 bsc#1225189).
- commit d4160e3

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

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

- Update references in patches.suse/drm-amd-display-Handle-null-stream_status-in-planes_.patch (CVE-2024-49912 bsc#1232367 stable-fixes)
- commit 82ff3c5

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

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

- Update references in patches.suse/drm-amd-display-Fix-index-out-of-bounds-in-DCN30-deg.patch (CVE-2024-49895 bsc#1232352 stable-fixes)
- commit 30b332b

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

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

- Update references in patches.suse/drm-amd-display-Fix-index-out-of-bounds-in-degamma-h.patch (CVE-2024-49894 bsc#1232354 stable-fixes)
- commit 31682a2

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

- Update references for patches.suse/drm-amd-display-Add-null-check-for-top_pipe_to_progr.patch (CVE-2024-49913 bsc#1232307 stable-fixes)
- commit 809100c

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

- Update references in patches.suse/drm-amd-display-Check-null-pointer-before-dereferenc.patch (CVE-2024-50049 bsc#1232309 stable-fixes)
- commit dbbbdf6

- Rename to
  patches.suse/scsi-pm8001-Do-not-overwrite-PCI-queue-mapping.patch.
  An upstream git-fix replaces an existing SUSE-only patch. The
  contents are essentially the same, but the meta-data and patch
  filename have changed.
- commit 658b404

- Update patches.suse/drm-amd-display-Add-null-check-for-afb-in-amdgpu_dm_.patch (stable-fixes bsc#1232335 CVE-2024-49908).
- commit d6e1a21

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

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

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

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

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

- RDMA/cxgb4: Dump vendor specific QP details (git-fixes)
- commit 9ec5789

- scsi: wd33c93: Don't use stale scsi_pointer value (git-fixes).
- scsi: lpfc: Restrict support for 32 byte CDBs to specific HBAs
  (git-fixes).
- drbd: Fix atomicity violation in drbd_uuid_set_bm() (git-fixes).
- scsi: smartpqi: correct stream detection (git-fixes).
- scsi: elx: libefc: Fix potential use after free in
  efc_nport_vport_del() (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).
- drbd: Add NULL check for net_conf to prevent dereference in
  state validation (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: 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: 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: 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: spi: Fix sshdr use (git-fixes).
- commit 2156f82

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

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

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

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

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

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

- ACPI: sysfs: validate return type of _STR method (bsc#1231861
  CVE-2024-49860).
- commit 1bb3615

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

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

- arm64: dts: rockchip: override BIOS_DISABLE signal via GPIO
  hog on RK3399 Puma (git-fixes).
- commit cf1f6ea

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

- wifi: iwlwifi: mvm: avoid NULL pointer dereference (CVE-2024-49929 bsc#1232253)
- commit 58431d9

- Update references in patches.suse/efistub-tpm-Use-ACPI-reclaim-memory-for-event-log-to.patch (CVE-2024-49858 bsc#1232251 stable-fixes)
- commit 643a630

- tracing/timerlat: Fix a race during cpuhp processing (CVE-2024-49866 bsc#1232259)
- commit 5a5e6bb

- fbcon: Fix a NULL pointer dereference issue in fbcon_putcs (CVE-2024-50048 bsc#1232310)
- commit 58eb9a7

- ACPI: PRM: Clean up guid type in struct prm_handler_info
  (git-fixes).
- commit 3b24754

- ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and
  context (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: firewire-lib: Avoid division by zero in
  apply_constraint_to_size() (git-fixes).
- drm/amd: Guard against bad data for ATIF ACPI method
  (git-fixes).
- net: usb: usbnet: fix name regression (git-fixes).
- USB: serial: option: add Telit FN920C04 MBIM compositions
  (stable-fixes).
- USB: serial: option: add support for Quectel EG916Q-GL
  (stable-fixes).
- ALSA: hda/conexant - Use cached pin control for Node 0x1d on
  HP EliteOne 1000 G2 (git-fixes).
- ALSA: hda/conexant - Fix audio routing for HP EliteOne 1000 G2
  (stable-fixes).
- commit 738bedb

- Revert PM changes that caused a regression on S4 resume (bsc#1231578)
  The recent PM fixes seem causing a regression and broke the resume from
  suspend-to-disk.  Revert those temporarily as a workaround.
- commit 214736e

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

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

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

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

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

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

- serial: protect uart_port_dtr_rts() in uart_shutdown() too
  (CVE-2024-50058 bsc#1232285).
- commit 34995da

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

- Update references in patches.suse/ACPICA-check-null-return-of-ACPI_ALLOCATE_ZEROED-in-.patch (CVE-2024-49962 bsc#1232314 stable-fixes)
- commit f0fdf4d

- Update references in patches.suse/drm-amd-display-Check-stream-before-comparing-them.patch (CVE-2024-49896 bsc#1232221 stable-fixes).
- commit 0424fac

- Update references in patches.suse/drm-amd-pm-ensure-the-fw_info-is-not-null-before-usi.patch (CVE-2024-49890 bsc#1232217 stable-fixes)
- commit 10dd27d

- Update references in patches.suse/drm-amd-display-Initialize-get_bytes_per_element-s-d.patch (CVE-2024-49892 bsc#1232220 stable-fixes)
- commit 53b7a11

- ACPI: battery: Fix possible crash when unregistering a battery hook (CVE-2024-49955 bsc#1232154)
- commit 9b71864

- ACPI: battery: Simplify battery hook locking (bsc#1232154)
- commit fe3f1c8

- ACPI: battery: Call power_supply_changed() when adding hooks (bsc#1232154)
- commit 3384bbc

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

- drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func (CVE-2024-47720 bsc#1232043)
- commit c17fe2d

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

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

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

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

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

- 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).
- Refresh patches.kabi/bpf-bpf_map-kABI-workaround.patch
- selftests/bpf: Add a test for using a cpumap from an
  freplace-to-XDP program (CVE-2024-50063 bsc#1232435).
- bpf: Resolve fext program type when checking map compatibility
  (CVE-2024-50063 bsc#1232435).
- Refresh patches.suse/bpf-Fix-null-pointer-dereference-in-resolve_prog_typ.patch
- Refresh patches.suse/bpf-Fix-updating-attached-freplace-prog-in-prog_arra.patch
- commit 0f72f86

- net: mvneta: Fix an out of bounds check (CVE-2022-48966
  bsc#1232191).
- commit 8b86532

- net: hisilicon: Fix potential use-after-free in hisi_femac_rx()
  (CVE-2022-48962 bsc#1232286).
- commit 0f23f49

- btrfs: wait for fixup workers before stopping cleaner kthread
  during umount (bsc#1232262 CVE-2024-49867).
- btrfs: fix hang during unmount when stopping a space reclaim
  worker (bsc#1232262 CVE-2024-49867).
- commit b603fa4

- 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).
- net: dsa: sja1105: avoid out of bounds access in
  sja1105_init_l2_policing() (CVE-2022-48980 bsc#1232233).
- net: mvneta: Prevent out of bounds read in mvneta_config_rss()
  (CVE-2022-48966 bsc#1232191).
- net/9p: Fix a potential socket leak in p9_socket_open
  (CVE-2022-49020 bsc#1232175).
- commit f80d8c6

- wifi: rtw89: avoid to add interface to list twice when SER
  (CVE-2024-49939 bsc#1232381).
- commit 11b12a3

- kbuild: add test-{ge,gt,le,lt} macros (bsc#1230414 bsc#1229450).
- Makefile.compiler: replace cc-ifversion with compiler-specific
  macros (bsc#1230414 bsc#1229450).
- commit 333c031

- SUNRPC: clnt.c: Remove misleading comment (git-fixes).
- commit 18e56f7

- fs: Fix file_set_fowner LSM hook inconsistencies (git-fixes).
- commit 5011da4

- filelock: fix potential use-after-free in posix_lock_inode
  (git-fixes).
- commit a756cfc

- fs/pipe: Fix lockdep false-positive in watchqueue pipe_write()
  (git-fixes).
- commit 2d51bab

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

- erofs: avoid infinite loop in z_erofs_do_read_page() when
  reading beyond EOF (git-fixes).
- commit 974bef0

- erofs: fix potential overflow calculating xattr_isize
  (git-fixes).
- commit 4298ffd

- erofs: stop parsing non-compact HEAD index if clusterofs is
  invalid (git-fixes).
- commit 7d6a607

- fs/namespace: fnic: Switch to use %ptTd (git-fixes).
- Refresh
  patches.suse/mount-warn-only-once-about-timestamp-range-expiratio.patch.
- commit eb6d674

- exportfs: use pr_debug for unreachable debug statements
  (git-fixes).
- commit 6f07ce6

- erofs: fix pcluster use-after-free on UP platforms (git-fixes).
- commit bc3c731

- erofs: avoid consecutive detection for Highmem memory
  (git-fixes).
- commit 1f8a3b1

- afs: Revert &amp;quot;afs: Hide silly-rename files from userspace&amp;quot;
  (git-fixes).
- commit 514f9ab

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

- hv_netvsc: Fix VF namespace also in synthetic NIC NETDEV_REGISTER event (git-fixes).
- commit d50701c

- Drop USB dwc2 patch that caused a regression on RPi3 (bsc#1232342)
- commit 9eb10ce

- Update patch reference for NTB fix (CVE-2024-50059 bsc#1232345)
- commit 7e7191a

- mm: call the security_mmap_file() LSM hook in remap_file_pages()
  (CVE-2024-47745 bsc#1232135).
- commit 20b76bc

- mm/khugepaged: fix collapse_pte_mapped_thp() to allow anon_vma
  (CVE-2022-48991 bsc#1232070 prerequisity git-fix).
- mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths
  (CVE-2022-48991 bsc#1232070).
- commit 3ab8533

- mm/khugepaged: fix GUP-fast interaction by sending IPI
  (CVE-2022-48991 bsc#1232070 prerequisity).
- commit 327d525

- mm/khugepaged: take the right locks for page table retraction
  (CVE-2022-48991 bsc#1232070 prerequisity).
- commit e43adf4

- mm: gup: fix the fast GUP race against THP collapse
  (CVE-2022-48991 bsc#1232070 prerequisity).
- commit 262192e

- Bluetooth: L2CAP: Fix uaf in l2cap_connect (CVE-2024-49950
  bsc#1232159).
- commit 640a739

- net: seeq: Fix use after free vulnerability in ether3 Driver
  Due to Race Condition (CVE-2024-47747 bsc#1232145).
- commit a1020b1

- 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 52da641

- ppp: do not assume bh is held in ppp_channel_bridge_input()
  (CVE-2024-49946 bsc#1232164).
- net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc()
  (CVE-2024-50000 bsc#1232085).
- net/mlx5: Fix error path in multi-packet WQE transmit
  (CVE-2024-50001 bsc#1232084).
- ethernet: aeroflex: fix potential skb leak in greth_init_rings()
  (CVE-2022-48958 bsc#1231889).
- commit 25ee2f4

- jfs: Fix sanity check in dbMount (git-fixes).
- commit 35da5b4

- drm/amd/display: Fix index may exceed array range within fpu_update_bw_bounding_box (CVE-2024-46811 bsc#1231179).
- commit 1bc47f7

- drm/amd/display: Check msg_id before processing transcation (CVE-2024-46814 bsc#1231193).
- commit 81681a2

- i3c: master: cdns: Fix use after free vulnerability in
  cdns_i3c_master Driver Due to Race Condition (CVE-2024-50061
  bsc#1232263).
- commit 6ed9c96

- r8169: add tally counter fields added with RTL8125 (CVE-2024-49973 bsc#1232105)
- commit 4e4fc3c

- crypto: hisilicon/qm - inject error before stopping queue (CVE-2024-47730 bsc#1232075)
- commit 9699bc1

- crypto: hisilicon/qm - re-enable communicate interrupt before notifying PF (bsc#1232075)
- commit 368c724

- crypto: hisilicon - Remove pci_aer_clear_nonfatal_status() call (bsc#1232075)
- commit 0b80db6

- sock_map: Add a cond_resched() in sock_hash_free() (CVE-2024-47710 bsc#1232049)
- commit 5cc4002

- cifs: Fix buffer overflow when parsing NFS reparse points
  (bsc#1232089, CVE-2024-49996).
- commit 629d06c

- tipc: re-fetch skb cb after tipc_msg_validate (CVE-2022-49017 bsc#1232004)
- commit b9d33e0

- netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() (CVE-2024-47685 bsc#1231998)
- commit d7fe249

- net: Fix an unsafe loop on the list (CVE-2024-50024 bsc#1231954)
- commit f700b14

- ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() (CVE-2024-47707 bsc#1231935)
- commit 64e3b6a

- netfilter: br_netfilter: fix panic with metadata_dst skb (CVE-2024-50045 bsc#1231903)
- commit 727e945

- block, bfq: fix possible UAF for bfqq-&amp;gt;bic with merge chain (CVE-2024-47706 bsc#1231942)
- commit c5d0bc0

- tcp: check skb is non-NULL in tcp_rto_delta_us() (CVE-2024-47684 bsc#1231987)
- commit 569d856

- net: hsr: Fix potential use-after-free (CVE-2022-49015 bsc#1231938)
- commit 5883d13

- add bug references to existing mana changes (bsc#1232033, bsc#1232034, bsc#1232036).
- commit 3e74daa

- wifi: ath11k: fix array out-of-bound access in SoC stats
  (CVE-2024-49930 bsc#1232260).
- commit e11de4c

- platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug
  (CVE-2024-49886 bsc#1232196).
- commit b27a545

- Refresh
  patches.suse/gpio-pca953x-fix-pca953x_irq_bus_sync_unlock-race.patch.
  The gpio-pca953x driver wasn't yet converted to guard-style locking
  in kernel v5.14, so use traditional locking directives.
- commit 3464b98

- arm64: probes: Fix uprobes for big-endian kernels (git-fixes)
- commit 105bb8d

- arm64: probes: Fix simulate_ldr*_literal() (git-fixes)
- commit d94196b

- arm64: probes: Remove broken LDR (literal) uprobe support (git-fixes)
- commit eda3a0b

- arm64: errata: Expand speculative SSBS workaround once more (git-fixes)
- commit 1391273

- arm64: cputype: Add Neoverse-N3 definitions (git-fixes)
- commit 4aef76b

- 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 a445095

- arm64: esr: Define ESR_ELx_EC_* constants as UL (git-fixes)
- commit b215a2f

- arm64: Add Cortex-715 CPU part definition (git-fixes)
  Refresh patches.suse/arm64-Add-Cortex-A520-CPU-part-definition.patch.
  Refresh patches.suse/arm64-cputype-Add-Cortex-X4-definitions.patch.
- commit 5d98446

- wifi: mac80211: don't use rate mask for offchannel TX either
  (CVE-2024-47738 bsc#1232114).
- wifi: mac80211: don't use rate mask for scanning (CVE-2024-47738
  bsc#1232114).
- commit 67fbe82

- 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 c6bb88b

- md/raid5: fix deadlock that raid5d() wait for itself to clear
  MD_SB_CHANGE_PENDING (CVE-2024-39476 bsc#1227437).
- commit ee734c0

- ocfs2: reserve space for inline xattr before attaching reflink
  tree (bsc#1232151 CVE-2024-49958).
- commit 8a206c2

- kthread: unpark only parked kthread (git-fixes, bsc#1231990,
  CVE-2024-50019).
- commit ad67452

- x86/bugs: Do not use UNTRAIN_RET with IBPB on entry (git-fixes).
- commit 6a38280

- x86/bugs: Skip RSB fill at VMEXIT (git-fixes).
- commit d16b07d

- x86/entry: Have entry_ibpb() invalidate return predictions (git-fixes).
- commit 6ee6f75

- x86/cpufeatures: Add a IBPB_NO_RET BUG flag (git-fixes).
- commit 783b4c0

- x86/cpufeatures: Define X86_FEATURE_AMD_IBPB_RET (git-fixes).
- commit f222561

- x86/tdx: Fix &amp;quot;in-kernel MMIO&amp;quot; check (bsc#1232116 CVE-2024-47727).
- commit c381359

- fat: fix uninitialized variable (git-fixes).
- commit 457698b

- Update
  patches.suse/memcg-Fix-possible-use-after-free-in-memcg_write_event_control.patch
  (bsc#1206344, CVE-2022-48988, bsc#1232069).
- commit e7eaea8

- drm/amd/display: Add null check for head_pipe in
  dcn201_acquire_free_pipe_for_layer (CVE-2024-49919 bsc#1231968).
- commit afcb4c9

- dpaa2-switch: Fix memory leak in dpaa2_switch_acl_entry_add()
  and dpaa2_switch_acl_entry_remove()  (CVE-2022-48957
  bsc#1231973).
- commit b3f573c

- 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).
- commit bf7bdd1

- net: dsa: sja1105: fix memory leak in
  sja1105_setup_devlink_regions() (CVE-2022-48959 bsc#1231976).
- commit ec81f5f

- x86/hyperv: Set X86_FEATURE_TSC_KNOWN_FREQ when Hyper-V provides frequency (git-fixes).
- commit 0e442b9

- thermal: core: Reference count the zone in
  thermal_zone_get_by_id() (CVE-2024-50028 bsc#1231950).
- commit cae3a79

- kabi fix for NFSv4: Prevent NULL-pointer dereference in
  nfs42_complete_copies() (bsc#1231902 CVE-2024-50046).
- commit 2c3b231

- NFSv4: Prevent NULL-pointer dereference in
  nfs42_complete_copies() (bsc#1231902 CVE-2024-50046).
- commit 8c78cbf

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

- xhci: Mitigate failed set dequeue pointer commands (git-fixes).
- xhci: Fix incorrect stream context type macro (git-fixes).
- usb: typec: altmode should keep reference to parent (git-fixes).
- Revert &amp;quot;usb: yurex: Replace snprintf() with the safer
  scnprintf() variant&amp;quot; (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).
- USB: misc: yurex: fix race between read and write
  (stable-fixes).
- USB: misc: cypress_cy7c63: check for short transfer
  (stable-fixes).
- USB: appledisplay: close race between probe and completion
  handler (stable-fixes).
- USB: serial: pl2303: add device id for Macrosilicon MS3020
  (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).
- spi: spi-fsl-lpspi: Undo runtime PM changes at driver exit time
  (git-fixes).
- platform/x86: touchscreen_dmi: add nanote-next quirk
  (stable-fixes).
- power: reset: brcmstb: Do not go into infinite loop if reset
  fails (stable-fixes).
- spi: bcm63xx: Fix module autoloading (git-fixes).
- spi: ppc4xx: Avoid returning 0 when failed to parse and map IRQ
  (git-fixes).
- spi: ppc4xx: handle irq_of_parse_and_map() errors (git-fixes).
- wifi: ath9k_htc: Use __skb_set_length() for resetting urb
  before resubmit (stable-fixes).
- wifi: mwifiex: Fix memcpy() field-spanning write warning in
  mwifiex_cmd_802_11_scan_ext() (stable-fixes).
- wifi: ath9k: Remove error checks when creating debugfs entries
  (git-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: rtw88: select WANT_DEV_COREDUMP (stable-fixes).
- spi: spidev: Add missing spi_device_id for jg10309-01
  (git-fixes).
- spi: bcm63xx: Enable module autoloading (stable-fixes).
- wifi: iwlwifi: clear trans-&amp;gt;state earlier upon error
  (stable-fixes).
- wifi: iwlwifi: mvm: fix iwl_mvm_scan_fits() calculation
  (stable-fixes).
- wifi: iwlwifi: lower message level for FW buffer destination
  (stable-fixes).
- platform/surface: aggregator_registry: Add support for Surface
  Laptop Go 3 (stable-fixes).
- usbnet: ipheth: fix carrier detection in modes 1 and 4
  (stable-fixes).
- usb: yurex: Fix inconsistent locking bug in yurex_read()
  (git-fixes).
- usb: yurex: Replace snprintf() with the safer scnprintf()
  variant (stable-fixes).
- wifi: ath9k: fix parameter check in ath9k_init_debug()
  (stable-fixes).
- spi: lpspi: Simplify some error message (git-fixes).
- spi: lpspi: release requested DMA channels (stable-fixes).
- spi: lpspi: Silence error message upon deferred probe
  (stable-fixes).
- commit f956c13

- parport: Proper fix for array out-of-bounds access (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: proximity: mb1232: 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).
- netdevsim: use cond_resched() in nsim_dev_trap_report_work()
  (git-fixes).
- media: videobuf2-core: clear memory related fields in
  __vb2_plane_dmabuf_put() (stable-fixes).
- ntb: ntb_hw_switchtec: Fix use after free vulnerability in
  switchtec_ntb_remove due to race condition (stable-fixes).
- ntb: intel: Fix the NULL vs IS_ERR() bug for
  debugfs_create_dir() (git-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).
- Input: synaptics - enable SMBus for HP Elitebook 840 G2
  (stable-fixes).
- Input: ads7846 - ratelimit the spi_sync error message
  (stable-fixes).
- Input: goodix - use the new soc_intel_is_byt() helper
  (stable-fixes).
- commit dcfb1af

- HID: multitouch: Add support for GT7868Q (stable-fixes).
- Refresh
  patches.kabi/restore-renamed-device-IDs-for-USB-HID-devices.patch.
- commit 3c7db56

- i2c: xiic: Switch from waitqueue to completion (stable-fixes).
- Refresh patches.suse/i2c-xiic-Make-bus-names-unique.patch.
- commit a465fd8

- 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).
- iio: light: veml6030: fix IIO device retrieval from embedded
  device (git-fixes).
- cpufreq/amd-pstate: Fix amd_pstate mode switch on shared memory
  systems (git-fixes).
- drm/vmwgfx: Handle surface check failure correctly (git-fixes).
- drm/radeon: Fix encoder-&amp;gt;possible_clones (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/dpu: make sure phys resources are properly initialized
  (git-fixes).
- HID: plantronics: Workaround for an unexcepted opposite volume
  key (stable-fixes).
- i2c: stm32f7: Do not prepare/unprepare clock during runtime
  suspend/resume (git-fixes).
- drm/amd/display: Fix system hang while resume with TBT monitor
  (stable-fixes).
- i2c: xiic: Fix pm_runtime_set_suspended() with runtime pm
  enabled (git-fixes).
- fbdev: sisfb: Fix strbuf array overflow (stable-fixes).
- drm/amd/display: Allow backlight to go below
  `AMDGPU_DM_DEFAULT_MIN_BACKLIGHT` (stable-fixes).
- drm/amd/display: Validate backlight caps are sane
  (stable-fixes).
- drm/amd/display: Check null pointer before dereferencing se
  (stable-fixes).
- drm/amd/display: Round calculated vtotal (stable-fixes).
- driver core: bus: Return -EIO instead of 0 when show/store
  invalid bus attribute (stable-fixes).
- efistub/tpm: Use ACPI reclaim memory for event log to avoid
  corruption (stable-fixes).
- comedi: ni_routing: tools: Check when the file could not be
  opened (stable-fixes).
- i2c: i801: Use a different adapter-name for IDF adapters
  (stable-fixes).
- i2c: xiic: Try re-initialization on bus busy timeout
  (git-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/amd/display: Fix Synaptics Cascaded Panamera DSC
  Determination (stable-fixes).
- drm/printer: Allow NULL data in devcoredump printer
  (stable-fixes).
- drm/amd/pm: ensure the fw_info is not null before using it
  (stable-fixes).
- drm/amd/display: Add null check for 'afb' in
  amdgpu_dm_plane_handle_cursor_update (v2) (stable-fixes).
- drm/amd/display: Check null pointers before using dc-&amp;gt;clk_mgr
  (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: Handle null 'stream_status' in
  'planes_changed_for_existing_stream' (stable-fixes).
- drm/amd/display: Initialize get_bytes_per_element's default to 1
  (stable-fixes).
- drm/amd/display: Add null check for top_pipe_to_program in
  commit_planes_for_stream (stable-fixes).
- drm/radeon: properly handle vbios fake edid sizing (git-fixes).
- drm/amdgpu: properly handle vbios fake edid sizing (git-fixes).
- drm/amd/display: Fix index out of bounds in DCN30 color
  transformation (stable-fixes).
- drm/amd/display: Fix index out of bounds in degamma hardware
  format translation (stable-fixes).
- drm/amd/display: Fix index out of bounds in DCN30 degamma
  hardware format translation (stable-fixes).
- drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit
  (stable-fixes).
- drm/amd/display: Check stream before comparing them
  (stable-fixes).
- HID: multitouch: Add support for Thinkpad X12 Gen 2 Kbd
  Portfolio (stable-fixes).
- fbdev: pxafb: Fix possible use after free in pxafb_task()
  (stable-fixes).
- bus: integrator-lm: fix OF node leak in probe() (git-fixes).
- firmware: tegra: bpmp: Drop unused mbox_client_to_bpmp()
  (git-fixes).
- i2c: xiic: improve error message when transfer fails to start
  (stable-fixes).
- i2c: xiic: Use devm_clk_get_enabled() (stable-fixes).
- i2c: xiic: xiic_xfer(): Fix runtime PM leak on error path
  (git-fixes).
- drm/amdgpu: Replace one-element array with flexible-array member
  (stable-fixes).
- drm/radeon: Replace one-element array with flexible-array member
  (stable-fixes).
- drm/rockchip: support gamma control on RK3399 (stable-fixes).
- drm/rockchip: define gamma registers for RK3399 (stable-fixes).
- i2c: xiic: Fix RX IRQ busy check (stable-fixes).
- i2c: xiic: Fix broken locking on tx_msg (stable-fixes).
- commit 9daeadb

- Bluetooth: ISO: Fix multiple init when debugfs is disabled
  (git-fixes).
- ALSA: hda/cs8409: Fix possible NULL dereference (git-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).
- 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).
- ALSA: hda/realtek: Add a quirk for HP Pavilion 15z-ec200
  (stable-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).
- ASoC: rt5682: Return devm_of_clk_add_hw_provider to transfer
  the error (git-fixes).
- ALSA: usb-audio: Add logitech Audio profile quirk
  (stable-fixes).
- ALSA: hda: cs35l41: fix module autoloading (git-fixes).
- ALSA: usb-audio: Replace complex quirk lines with macros
  (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: resource: Add another DMI match for the TongFang GMxXGxx
  (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).
- ASoC: tda7419: fix module autoloading (stable-fixes).
- ASoC: intel: fix module autoloading (stable-fixes).
- ASoC: allow module autoloading for table db1200_pids
  (stable-fixes).
- commit f59a49f

- 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 629456f

- nfsd: return -EINVAL when namelen is 0 (CVE-2024-47692
  bsc#1231857).
- commit 3ec0b50

- nilfs2: fix kernel bug due to missing clearing of buffer delay
  flag (git-fixes).
- commit fa778cc

- Refresh
  patches.suse/KVM-Reject-overly-excessive-IDs-in-KVM_CREATE_VCPU.patch
  (fix build warning).
- commit 4509600

- ethtool: fail closed if we can't get max channel used in
  indirection tables (CVE-2024-46834 bsc#1231096).
- commit 92f1041

- 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).
- commit 11f0889

- gpio: prevent potential speculation leaks in
  gpio_device_get_desc() (stable-fixes CVE-2024-44931
  bsc#1229837).
- commit fd874e3

- gpio: pca953x: fix pca953x_irq_bus_sync_unlock race
  (stable-fixes CVE-2024-42253 bsc#1229005).
- commit 1b7d3e6

- SUNRPC: Fix integer overflow in decode_rc_list() (git-fixes).
- commit e96d6b6

- NFSD: Mark filecache &amp;quot;down&amp;quot; if init fails (git-fixes).
- commit 2bc13b1

- nfs: fix memory leak in error path of nfs4_do_reclaim
  (git-fixes).
- commit 78b8702

- nfsd: fix delegation_blocked() to block correctly for at least
  30 seconds (git-fixes).
- commit a755d72

- nfsd: return -EINVAL when namelen is 0 (git-fixes).
- commit c0a4772

- nfsd: call cache_put if xdr_reserve_space returns NULL
  (git-fixes).
- commit bea413a

- nfsd: fix refcount leak when file is unhashed after being found
  (git-fixes).
- commit a3bda73

- nfsd: remove unneeded EEXIST error check in nfsd_do_file_acquire
  (git-fixes).
- commit 1bee667

- NFS: Avoid unnecessary rescanning of the per-server delegation
  list (git-fixes).
- commit 5a9ecaa

- NFSv4: Fix clearing of layout segments in layoutreturn
  (git-fixes).
- commit 21968b2

- ocfs2: fix the la space leak when unmounting an ocfs2 volume
  (git-fixes).
- commit 2bcef50

- jfs: Fix uninit-value access of new_ea in ea_buffer (git-fixes).
- commit 894e3e9

- jfs: check if leafidx greater than num leaves per dmap tree
  (git-fixes).
- commit 2a190ef

- jfs: Fix uaf in dbFreeBits (git-fixes).
- commit 77fee8f

- jfs: UBSAN: shift-out-of-bounds in dbFindBits (git-fixes).
- commit bdbc194

- RDMA/rtrs-srv: Avoid null pointer deref during path establishment (git-fixes)
- commit 06d0a1f

- RDMA/mad: Improve handling of timed out WRs of mad agent (git-fixes)
- commit a59c1e5

- RDMA/hns: Refactor the abnormal interrupt handler function (git-fixes)
  Refresh patches.suse/RDMA-hns-Fix-VF-triggering-PF-reset-in-abnormal-inte.patch
- commit 16f4f98

- RDMA/hns: Fix the wrong type of return value of the interrupt handler (git-fixes)
  Refresh:
  - patches.suse/RDMA-hns-Fix-VF-triggering-PF-reset-in-abnormal-inte.patch
-  patches.suse/RDMA-hns-Fix-soft-lockup-under-heavy-CEQE-load.patch
- commit 10cd6d3

- RDMA/hns: Remove unused abnormal interrupt of type RAS (git-fixes)
- commit 05afe22

- mm: avoid leaving partial pfn mappings around in error case
  (CVE-2024-47674 bsc#1231673).
- commit 9910e8f

- RDMA/bnxt_re: Fix the GID table length (git-fixes)
- commit bc97910

- RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages (git-fixes)
- commit d91cca2

- RDMA/bnxt_re: Return more meaningful error (git-fixes)
- commit 530c748

- RDMA/bnxt_re: Fix the max CQ WQEs for older adapters (git-fixes)
- commit 04af073

- RDMA/srpt: Make slab cache names unique (git-fixes)
- commit d1c01aa

- RDMA/irdma: Fix misspelling of &amp;quot;accept*&amp;quot; (git-fixes)
- commit 5a68e97

- RDMA/cxgb4: Fix RDMA_CM_EVENT_UNREACHABLE error for iWARP (git-fixes)
- commit e2cb15f

- RDMA/bnxt_re: Add a check for memory allocation (git-fixes)
- commit a888491

- RDMA/bnxt_re: Fix incorrect AVID type in WQE structure (git-fixes)
- commit 21e34e7

- udf: Avoid excessive partition lengths (bsc#1230773
  CVE-2024-46777).
- commit 43cca3d

- fsnotify: clear PARENT_WATCHED flags lazily (bsc#1231439
  CVE-2024-47660).
- commit 66d4cf0

- netem: fix return value if duplicate enqueue fails
  (CVE-2024-45016 bsc#1230429).
- commit 2e9108a

- net: test for not too small csum_start in
  virtio_net_hdr_to_skb() (git-fixes).
- commit 78a3945

- KVM: fix memoryleak in kvm_init() (git-fixes).
- commit 066c2d8

- kabi: fix after KVM: arm64: mixed-width check should be skipped
  for uninitialized vCPUs (git-fixes).
- commit bbf2daf

- kabi: fix after kvm: add guest_state_{enter,exit}_irqoff()
  (git-fixes).
- commit baf8de4

- kab: fix after net: add more sanity check in
  virtio_net_hdr_to_skb() (git-fixes).
- commit e85c3fa

- kABI: bpf: struct bpf_func_proto kABI workaround (git-fixes).
- commit 880c9eb

- nbd: fix race between timeout and normal completion
  (bsc#1230918).
- commit 3f6c035

- 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 27bf420

- hwmon: (adm9240) Add missing dependency on REGMAP_I2C
  (git-fixes).
- hwmon: (tmp513) Add missing dependency on REGMAP_I2C
  (git-fixes).
- 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).
- nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy
  error (git-fixes).
- drm/vc4: Stop the active perfmon before being destroyed
  (git-fixes).
- drm/v3d: Stop the active perfmon before being destroyed
  (git-fixes).
- Bluetooth: RFCOMM: FIX possible deadlock in
  rfcomm_sk_state_change (git-fixes).
- spi: spi-imx: Fix pm_runtime_set_suspended() with runtime pm
  enabled (git-fixes).
- spi: s3c64xx: fix timeout counters in flush_fifo (git-fixes).
- gpio: davinci: fix lazy disable (git-fixes).
- ALSA: hda/conexant: Fix conflicting quirk for System76 Pangolin
  (git-fixes).
- ASoC: imx-card: Set card.owner to avoid a warning calltrace
  if SND=m (git-fixes).
- ALSA: hda/generic: Unconditionally prefer preferred_dacs pairs
  (git-fixes).
- ALSA: hda/realtek: Fix the push button function for the ALC257
  (git-fixes).
- ALSA: mixer_oss: Remove some incorrect kfree_const() usages
  (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).
- Input: adp5589-keys - fix adp5589_gpio_get_value() (git-fixes).
- Input: adp5589-keys - fix NULL pointer dereference (git-fixes).
- drm: komeda: Fix an issue related to normalized zpos
  (stable-fixes).
- ALSA: hda/realtek - FIxed ALC285 headphone no sound
  (stable-fixes).
- ALSA: hda/realtek - Fixed ALC256 headphone no sound
  (stable-fixes).
- ALSA: hda: Fix kctl-&amp;gt;id initialization (git-fixes).
- ASoC: soc-pcm: Don't zero TDM masks in __soc_pcm_open()
  (git-fixes).
- commit 05e9a52

- perf/x86/intel: Limit the period on Haswell (bsc#1231072,
  CVE-2024-46848).
- commit f8c2996

- sched/smt: Fix unbalance sched_smt_present dec/inc
  (CVE-2024-44958 bsc#1230179).
- commit 2c63e21

- wifi: iwlwifi: mvm: pause TCM when the firmware is stopped
  (CVE-2024-47673 bsc#1231539).
- commit 775f803

- wifi: iwlwifi: mvm: don't wait for tx queues if firmware is dead
  (CVE-2024-47672 bsc#1231540).
- commit 01e4e8b

- kABI: bpf: enum bpf_{type_flag,arg_type} kABI workaround (git-fixes).
- commit 56416b7

- spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware (CVE-2024-47664 bsc#1231442)
- commit c0024fd

- drm/amd/display: Avoid overflow from uint32_t to uint8_t (CVE-2024-47661 bsc#1231496)
- commit 8f65382

- lib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc() (CVE-2024-47668 bsc#1231502)
- commit 45aa8b3

- dn_route: set rt neigh to blackhole_netdev instead of
  loopback_dev in ifdown (bsc#1216813).
- commit 44138e3

- xfrm: set dst dev to blackhole_netdev instead of loopback_dev
  in ifdown (bsc#1216813).
- commit 89c7a24

- ipv6: blackhole_netdev needs snmp6 counters (bsc#1216813).
- commit faf59f1

- ipv6: give an IPv6 dev to blackhole_netdev (bsc#1216813).
- commit 13cc498

- selftests/bpf: Add a test case to write mtu result into .rodata
  (git-fixes).
- commit c1c2650

- selftests/bpf: Add a test case to write strtol result into
  .rodata (git-fixes).
- commit 1de69ac

- selftests/bpf: Rename ARG_PTR_TO_LONG test description
  (git-fixes).
- commit 6cf4336

- selftests/bpf: Fix ARG_PTR_TO_LONG {half-,}uninitialized test
  (git-fixes).
- commit fd06ef1

- 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 6b5690f

- 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).
- bpf: Allow helpers to accept pointers with a fixed size
  (git-fixes).
- Refresh patches.suse/bpf-Tidy-up-verifier-check_func_arg.patch
- commit b017693

- 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 262d8c3

- KVM: x86: Use a stable condition around all VT-d PI paths
  (git-fixes).
- Refresh
  patches.suse/KVM-VMX-Don-t-unblock-vCPU-w-Posted-IRQ-if-IRQs-are-.patch.
- commit d33f58c

- bpf, lsm: Add disabled BPF LSM hook list (git-fixes).
- commit fe7fa3e

- KVM: x86/mmu: Rename slot_handle_leaf to slot_handle_level_4k
  (git-fixes).
- Refresh
  patches.suse/KVM-x86-mmu-Remove-spurious-TLB-flushes-in-TDP-MMU-z.patch.
- commit 6e463a6

- bpf, net: Fix a potential race in do_sock_getsockopt()
  (git-fixes).
- net: socket: suppress unused warning (git-fixes).
- commit 62fee56

- KVM: x86/mmu: Fold rmap_recycle into rmap_add (git-fixes).
- commit 9bc72d6

- fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE
  (CVE-2024-45025 bsc#1230456).
- commit 19343d1

- Update kabi files.
  Based on October maintenance update:
  kernel-64kb-devel-5.14.21-150500.55.83.1.aarch64.rpm
  kernel-default-devel-5.14.21-150500.55.83.1.aarch64.rpm
  kernel-default-devel-5.14.21-150500.55.83.1.ppc64le.rpm
  kernel-default-devel-5.14.21-150500.55.83.1.s390x.rpm
  kernel-default-devel-5.14.21-150500.55.83.1.x86_64.rpm
  so that we can track newly added symbols.
- commit 8427d2e

- KVM: SVM: Disallow guest from changing userspace's
  MSR_AMD64_DE_CFG value (git-fixes).
- commit 0b0882c

- KVM: SVM: Don't advertise Bus Lock Detect to guest if SVM
  support is missing (git-fixes).
- commit 26a295a

- KVM: SVM: fix emulation of msr reads/writes of MSR_FS_BASE
  and MSR_GS_BASE (git-fixes).
- commit 4b12471

- kabi fix of KVM: arm64: Preserve PSTATE.SS for the guest while
  single-step is enabled (git-fixes).
- commit 29756fe

- 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).
- commit 4a96266

- bpf: Fix tailcall cases in test_bpf (git-fixes).
- bpf, x64: Remove tail call detection (git-fixes).
- commit ab13605

- KVM: arm64: Preserve PSTATE.SS for the guest while single-step
  is enabled (git-fixes).
- commit 9b95067

- add bug reference for a mana change (bsc#1229769).
- commit 279dcec

- KVM: arm64: mixed-width check should be skipped for
  uninitialized vCPUs (git-fixes).
- commit 39f0f9f

- bpf, verifier: Correct tail_call_reachable for bpf prog
  (git-fixes).
- bpf: Check for helper calls in check_subprogs() (git-fixes).
- commit 41df3fb

- usb: xhci: prevent potential failure in handle_tx_event()
  for Transfer events without TRB (CVE-2024-42226 bsc#1228709).
- commit e76988e

- kvm: add guest_state_{enter,exit}_irqoff() (git-fixes).
- commit 96c07ae

- bpf: Remove tst_run from lwt_seg6local_prog_ops (bsc#1230801
  CVE-2024-46754).
- commit 8b4a412

- kvm/arm64: rework guest entry logic (git-fixes).
- Refresh
  patches.suse/KVM-arm64-Treat-PMCR_EL1.LC-as-RES1-on-asymmetric-systems.patch.
- commit dfd24e5

- KVM: Pre-allocate cpumasks for
  kvm_make_all_cpus_request_except() (git-fixes).
- Refresh
  patches.suse/Revert-KVM-set-owner-of-cpu-and-vm-file-operations.patch.
- commit 83b6823

- KVM: Optimize kvm_make_vcpus_request_mask() a bit (git-fixes).
- commit 709720b

- KVM: Write the per-page &amp;quot;segment&amp;quot; when clearing (part of)
  a guest page (git-fixes).
- commit 9811c1e

- KVM: Fix coalesced_mmio_has_room() to avoid premature userspace
  exit (git-fixes).
- commit 5a089f5

- KVM: arm64: Release pfn, i.e. put page, if copying MTE tags
  hits ZONE_DEVICE (git-fixes).
- commit a55326d

- KVM: arm64: Invalidate EL1&amp;amp;0 TLB entries for all VMIDs in nvhe
  hyp init (git-fixes).
- commit 2e75c88

- KVM: Reject overly excessive IDs in KVM_CREATE_VCPU (git-fixes).
- commit b54be89

- KVM: arm64: Allow AArch32 PSTATE.M to be restored as System mode
  (git-fixes).
- commit 7476735

- KVM: arm64: Fix AArch32 register narrowing on userspace write
  (git-fixes).
- commit 517e742

- KVM: arm64: vgic-v2: Check for non-NULL vCPU in
  vgic_v2_parse_attr() (git-fixes).
- commit 9f76023

- KVM: arm64: vgic-its: Test for valid IRQ in MOVALL handler
  (git-fixes).
- commit 8fff566

- KVM: arm64: vgic-its: Test for valid IRQ in
  its_sync_lpi_pending_table() (git-fixes).
- commit b695d86

- KVM: arm64: Add missing memory barriers when switching to
  pKVM's hyp pgd (git-fixes).
- commit 606dda9

- KVM: arm64: vgic-v4: Restore pending state on host userspace
  write (git-fixes).
- commit c4e4df2

- Revert &amp;quot;KVM: Prevent module exit until all VMs are freed&amp;quot;
  (git-fixes).
- commit 5f68725

- KVM: arm64: GICv4: Do not perform a map to a mapped vLPI
  (git-fixes).
- commit 1f3e21a

- KVM: arm64: vgic-v2: Use cpuid from userspace as vcpu_id
  (git-fixes).
- commit 89273cb

- KVM: Grab a reference to KVM for VM and vCPU stats file
  descriptors (git-fixes).
- commit d99dedf

- kvm: Add support for arch compat vm ioctls (git-fixes).
- commit c1d9461

- KVM: Unconditionally get a ref to /dev/kvm module when creating
  a VM (git-fixes).
- commit 7df3401

- KVM: Fix lockdep false negative during host resume (git-fixes).
- commit 72fbff6

- KVM: eventfd: Fix false positive RCU usage warning (git-fixes).
- commit a76a2b9

- net/sched: taprio: extend minimum interval restriction to entire cycle too (CVE-2024-36244 bsc#1226797)
- commit 39420f6

- net/sched: taprio: Limit TCA_TAPRIO_ATTR_SCHED_CYCLE_TIME to INT_MAX (bsc#1226797)
- commit ddff31f

- vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()
  (git-fixes).
- commit 46f17cb

- bpf: Add --skip_encoding_btf_inconsistent_proto,
  - -btf_gen_optimized to pahole flags for v1.25 (bsc#1230414
  bsc#1229450).
- Refresh patches.suse/kbuild-Add-skip_encoding_btf_enum64-option-to-pahole.patch
- Refresh patches.suse/make-module-BTF-toggleable.patch
- btf, scripts: Exclude Rust CUs with pahole (bsc#1230414
  bsc#1229450).
- Refresh patches.suse/kbuild-Add-skip_encoding_btf_enum64-option-to-pahole.patch
- Refresh patches.suse/make-module-BTF-toggleable.patch
- Update config files.
- commit 536f189

- virtio_console: fix misc probe bugs (git-fixes).
- commit 2cea93c

- vhost_vdpa: assign irq bypass producer token correctly
  (git-fixes).
- commit e82b017

- virtio-net: synchronize probe with ndo_set_features (git-fixes).
- commit aa85f12

- aoe: fix the potential use-after-free problem in more places
  (bsc#1218562 CVE-2023-6270).
- commit e949a45

- virtio_net: fixing XDP for fully checksummed packets handling
  (git-fixes).
- commit f3d52ed

- vsock/virtio: fix packet delivery to tap device (git-fixes).
- commit 50a25ba

- kbuild,bpf: Add module-specific pahole flags for distilled
  base BTF (bsc#1230414 bsc#1229450).
- Refresh patches.suse/kbuild-Add-skip_encoding_btf_enum64-option-to-pahole.patch
- 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).
- Refresh patches.suse/kbuild-Add-skip_encoding_btf_enum64-option-to-pahole.patch
- kbuild: avoid too many execution of scripts/pahole-flags.sh
  (bsc#1230414 bsc#1229450).
- Refresh patches.suse/kbuild-Add-skip_encoding_btf_enum64-option-to-pahole.patch
- commit 05f7b0b

- Use pahole -j1 option for reproducible builds (bsc#1230414
  bsc#1229450).
- commit 486aef8

- net: add more sanity check in virtio_net_hdr_to_skb()
  (git-fixes).
- commit c9cb665

- ceph: fix cap ref leak via netfs init_request (bsc#1231383).
- commit 61990ab

- Update
  patches.suse/usb-typec-ucsi-Fix-null-pointer-dereference-in-trace.patch
  (CVE-2024-46719 bsc#1230722).
  Added CVE
- commit 04ed2dd

- efi: fix NULL-deref in init error path (bsc#1229556
  CVE-2022-48879).
- commit 41e1770

- dmaengine: altera-msgdma: properly free descriptor in
  msgdma_free_descriptor (bsc#1230715 CVE-2024-46716).
- commit 92074a5

- bpf: Fix pointer-leak due to insufficient speculative store
  bypass mitigation (bsc#1231375).
- commit fd93435

- drm/amd/display: Check gpio_id before used as array index (CVE-2024-46818 bsc#1231203).
- commit 53caf4b

- drm/amd/display: Check num_valid_sets before accessing reader_wm_sets (CVE-2024-46815 bsc#1231195).
- commit ad18f86

- ice: Unbind the workqueue (bsc#1231344).
- commit fa8a96c

- drm/amd/display: Validate function returns (bsc#1230774 CVE-2024-46775)
- commit a72450c

- drm/amd/display: Stop amdgpu_dm initialize when link nums greater than max_links (CVE-2024-46816 bsc#1231197).
- commit 1eea356

- Delete some more obsolete scripts
- commit 0d4cf12

- char: tpm: Fix possible memory leak in
  tpm_bios_measurements_open() (git-fixes).
- commit e53c1af

- drm/amd/display: Check link_index before accessing dc-&amp;gt;links (CVE-2024-46813 bsc#1231191).
- commit a97e1a4

- sched/isolation: Prevent boot crash when the boot CPU is (bsc#1231327)
- commit a3438e4

- rcu: Add rcutree.nohz_full_patience_delay to reduce nohz_full (bsc#1231327)
- commit 670f96b

- rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow
  (bsc#1226631).
- commit 2c24b8c

- scsi: fnic: Move flush_work initialization out of if block
  (bsc#1230055).
- commit 3f71444

- workqueue: mark power efficient workqueue as unbounded if (bsc#1231327)
- commit 2a22cf9

- workqueue: Avoid using isolated cpus' timers on (bsc#1231327)
- commit ab862e0

- 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: 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 057bf3f

- drm/amd/display: Stop amdgpu_dm initialize when stream nums greater than 6 (CVE-2024-46817 bsc#1231200).
- commit 18cf241

- rpm/release-projects: Add SLFO projects (bsc#1231293).
- commit 9f2c584

- KVM: s390: Fix SORTL and DFLTCC instruction format error in
  __insn32_query (git-fixes bsc#1231277).
- commit cce5574

- s390/mm: Add cond_resched() to cmm_alloc/free_pages()
  (bsc#1228747).
- commit 41a09b7

- ASoC: meson: axg-card: fix 'use-after-free' (CVE-2024-46849 bsc#1231073)
- commit a395e2d

- ELF: fix kernel.randomize_va_space double read (CVE-2024-46826 bsc#1231115)
- commit d14eaf0

- powerpc: Allow clearing and restoring registers independent
  of saved breakpoint state (bsc#1194869).
- commit fab6193

- powerpc/tlb: Add local flush for page given mm_struct and psize
  (bsc#1194869).
- commit 819e69d

- net/mlx5: Fix bridge mode operations when there are no VFs (CVE-2024-46857 bsc#1231087)
- commit b275110

- netfilter: nft_socket: fix sk refcount leaks (CVE-2024-46855 bsc#1231085)
- commit b9b2afb

- powerpc/imc-pmu: Use the correct spinlock initializer
  (bsc#1054914 fate#322448 git-fixes).
- commit 1a80d47

- powerpc/code-patching: introduce patch_instructions()
  (bsc#1194869).
- commit ce19d55

- powerpc/code-patching: Remove #ifdef CONFIG_STRICT_KERNEL_RWX
  (bsc#1194869).
- commit 347af82

- powerpc/code-patching: Fix oops with DEBUG_VM enabled
  (bsc#1194869).
- powerpc/code-patching: Consolidate and cache per-cpu patching
  context (bsc#1194869).
- powerpc/code-patching: Use temporary mm for Radix MMU
  (bsc#1194869).
- powerpc/code-patching: Use WARN_ON and fix check in poking_init
  (bsc#1194869).
- powerpc/code-patching: Speed up page mapping/unmapping
  (bsc#1194869).
- powerpc/code-patching: Use jump_label to check if poking_init()
  is done (bsc#1194869).
- powerpc/code-patching: Don't call is_vmalloc_or_module_addr()
  without CONFIG_MODULES (bsc#1194869).
- powerpc/code-patching: Pre-map patch area (bsc#1194869).
- powerpc/code-patching: Reorganise do_patch_instruction()
  to ease error handling (bsc#1194869).
- powerpc/code-patching: Fix unmap_patch_area() error handling
  (bsc#1194869).
- powerpc/code-patching: Fix error handling in
  do_patch_instruction() (bsc#1194869).
- commit 630a906

- powerpc/code-patching: Remove pr_debug()/pr_devel() messages
  and fix check() (bsc#1194869).
- powerpc/lib: Add __init attribute to eligible functions
  (bsc#1194869).
- powerpc/inst: Refactor ___get_user_instr() (bsc#1194869).
- commit d1c574c

- powerpc/code-patching: Add generic memory patching
  (bsc#1194869).
- powerpc/code-patching: Perform hwsync in __patch_instruction()
  in case of failure (bsc#1194869).
- powerpc/ftrace: Use patch_instruction() return directly
  (bsc#1194869).
- commit 358e581

- 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 1cf5de8

- Refresh sorted patches.
- commit c7484f7

- 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).
- powerpc/vdso: Merge vdso64 and vdso32 into a single directory
  (bsc#1194869).
- Refresh patches.suse/powerpc-vdso-Remove-cvdso_call_time-macro.patch
- powerpc/vdso: Rework VDSO32 makefile to add a prefix to object
  files (bsc#1194869).
- powerpc/vdso: augment VDSO32 functions to support 64 bits build
  (bsc#1194869).
- commit 319aee2

- powerpc/xmon: Fix disassembly CPU feature checks (bsc#1065729).
- powerpc/imc-pmu: Fix use of mutex in IRQs disabled section
  (bsc#1054914 fate#322448 git-fixes).
- commit 3f22c10

- cachefiles: fix dentry leak in cachefiles_open_file()
  (bsc#1231181).
- ceph: remove the incorrect Fw reference check when dirtying
  pages (bsc#1231180).
- commit 47c22dc

- rpm/check-for-config-changes: add HAVE_RUST and RUSTC_SUPPORTS_ to IGNORED_CONFIGS_RE
  They depend on SHADOW_CALL_STACK.
- commit 65fa52b

- KVM: x86: Acquire kvm-&amp;gt;srcu when handling KVM_SET_VCPU_EVENTS
  (CVE-2024-46830 bsc#1231116).
- commit 5d5e02e

- usb: xhci: fix loss of data on Cadence xHC (git-fixes).
- commit 1b1ffa2

- usb: cdnsp: Fix incorrect usb_request status (git-fixes).
- commit 901f16d

- USB: usbtmc: prevent kernel-usb-infoleak (git-fixes).
- commit 0627e93

- xhci: Set quirky xHC PCI hosts to D3 _after_ stopping and
  freeing them (git-fixes).
- commit e8a76c0

- drm/amd/display: Check BIOS images before it is used (CVE-2024-46809 bsc#1231148).
- commit 8c8b606

- usb: dwc3: st: fix probed platform device ref count on probe
  error path (bsc#1230507 CVE-2024-46674).
- commit ffd5693

- tomoyo: fallback to realpath if symlink's pathname does not
  exist (git-fixes).
- tty: rp2: Fix reset with non forgiving PCIe host bridges
  (git-fixes).
- USB: class: CDC-ACM: fix race between get_serial and set_serial
  (git-fixes).
- usb: dwc2: drd: fix clock gating on USB role switch (git-fixes).
- usb: cdnsp: Fix incorrect usb_request status (git-fixes).
- USB: usbtmc: prevent kernel-usb-infoleak (git-fixes).
- USB: serial: kobil_sct: restore initial terminal settings
  (git-fixes).
- xhci: Set quirky xHC PCI hosts to D3 _after_ stopping and
  freeing them (git-fixes).
- usb: dwc2: Skip clock gating on Broadcom SoCs (git-fixes).
- rtc: at91sam9: fix OF node leak in probe() error path
  (git-fixes).
- watchdog: imx_sc_wdt: Don't disable WDT in suspend (git-fixes).
- pinctrl: single: fix missing error code in pcs_probe()
  (git-fixes).
- PCI: xilinx-nwl: Fix register misspelling (git-fixes).
- PCI: xilinx-nwl: Fix off-by-one in INTx IRQ handler (git-fixes).
- xz: cleanup CRC32 edits from 2018 (git-fixes).
- pinctrl: single: fix potential NULL dereference in
  pcs_get_function() (git-fixes).
- thunderbolt: Mark XDomain as unplugged when router is removed
  (stable-fixes).
- commit b15f073

- mailbox: bcm2835: Fix timeout during suspend mode (git-fixes).
- mailbox: rockchip: fix a typo in module autoloading (git-fixes).
- firmware_loader: Block path traversal (git-fixes).
- iio: magnetometer: ak8975: Fix reading for ak099xx sensors
  (git-fixes).
- iio: chemical: bme680: Fix read/write ops to device by adding
  mutexes (git-fixes).
- iio: adc: ad7606: fix standby gpio state to match the
  documentation (git-fixes).
- iio: adc: ad7606: fix oversampling gpio array (git-fixes).
- Input: ps2-gpio - use IRQF_NO_AUTOEN flag in request_irq()
  (git-fixes).
- Input: ilitek_ts_i2c - add report id message validation
  (git-fixes).
- Input: ilitek_ts_i2c - avoid wrong input subsystem sync
  (git-fixes).
- media: sun4i_csi: Implement link validate for sun4i_csi subdev
  (git-fixes).
- media: venus: fix use after free bug in venus_remove due to
  race condition (git-fixes).
- media: vicodec: allow en/decoder cmd w/o CAPTURE (git-fixes).
- Revert &amp;quot;media: tuners: fix error return code of
  hybrid_tuner_request_state()&amp;quot; (stable-fixes).
- drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds
  write error (git-fixes).
- drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds
  write error (git-fixes).
- media: uapi/linux/cec.h: cec_msg_set_reply_to: zero flags
  (git-fixes).
- apparmor: fix possible NULL pointer dereference (stable-fixes).
- commit 0120ced

- nvme-fabrics: use reserved tag for reg read/write command
  (bsc#1228620 CVE-2024-41082).
- nvme: change __nvme_submit_sync_cmd() calling conventions
  (bsc#1228620 CVE-2024-41082).
  Refresh:
  - patches.suse/nvme-auth-retry-command-if-DNR-bit-is-not-set.patch
- commit 4effcb1

- kthread: Fix task state in kthread worker if being frozen
  (bsc#1231146).
- commit 2398294

- Refresh
  patches.suse/bpf-kprobe-remove-unused-declaring-of-bpf_kprobe_override.patch.
- commit ba454fb

- tracing: Avoid possible softlockup in tracing_iter_reset()
  (git-fixes).
- commit 1959490

- tracing: Fix overflow in get_free_elt() (git-fixes
  CVE-2024-43890 bsc#1229764).
- commit 867d207

- arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry (bsc#1231120 CVE-2024-46822)
- commit ec589da

- arm64: acpi: Move get_cpu_for_acpi_id() to a header (bsc#1231120 CVE-2024-46822)
- commit fb3eb08

- nf_conntrack_proto_udp: do not accept packets with IPS_NAT_CLASH
  (bsc#1199769).
- commit 8283ab9

- scsi: sd: Fix off-by-one error in
  sd_read_block_characteristics() (bsc#1223848).
- commit 04f7eb0

- scsi: ibmvfc: Add max_sectors module parameter (bsc#1216223).
- commit b81ed11

- af_unix: Fix data races around sk-&amp;gt;sk_shutdown (bsc#1226846).
- af_unix: annotate lockless accesses to sk-&amp;gt;sk_err (bsc#1226846).
- commit 7b544cf

- arm64: dts: rockchip: Raise Pinebook Pro's panel backlight
  PWM frequency (git-fixes).
- commit 3f7057a

- arm64: dts: rockchip: Correct the Pinebook Pro battery design
  capacity (git-fixes).
- commit 7f351fe

- PCI: Support BAR sizes up to 8TB (bsc#1231017)
- commit 3d80de5

- arm64: dts: rockchip: fix PMIC interrupt pin in pinctrl for
  ROCK Pi E (git-fixes).
- commit 293aaa9

- i2c: lpi2c: Avoid calling clk_get_rate during transfer
  (bsc#1227885 CVE-2024-40965).
- clk: Provide !COMMON_CLK dummy for devm_clk_rate_exclusive_get()
  (bsc#1227885).
- clk: Add a devm variant of clk_rate_exclusive_get()
  (bsc#1227885).
- i2c: imx-lpi2c: return -EINVAL when i2c peripheral clk doesn't
  work (bsc#1227885).
- i2c: imx-lpi2c: use bulk clk API (bsc#1227885).
- commit f4066a3

- arm64: acpi: Move get_cpu_for_acpi_id() to a header (git-fixes).
- commit 24cf4b5

- ipmi:ssif: Improve detecting during probing (bsc#1228771)
  Move patch into the sorted section.
- commit 790aa5a

- Update patches.suse/ALSA-line6-Fix-racy-access-to-midibuf.patch
  (stable-fixes CVE-2024-44954 bsc#1230176).
- Update
  patches.suse/ASoC-dapm-Fix-UAF-for-snd_soc_pcm_runtime-object.patch
  (git-fixes CVE-2024-46798 bsc#1230830).
- Update
  patches.suse/HID-amd_sfh-free-driver_data-after-destroying-hid-de.patch
  (stable-fixes CVE-2024-46746 bsc#1230751).
- Update
  patches.suse/HID-cougar-fix-slab-out-of-bounds-Read-in-cougar_rep.patch
  (stable-fixes CVE-2024-46747 bsc#1230752).
- Update
  patches.suse/Input-uinput-reject-requests-with-unreasonable-numbe.patch
  (stable-fixes CVE-2024-46745 bsc#1230748).
- Update
  patches.suse/Squashfs-sanity-check-symbolic-link-size.patch
  (git-fixes CVE-2024-46744 bsc#1230747).
- Update
  patches.suse/VMCI-Fix-use-after-free-when-removing-resource-in-vm.patch
  (git-fixes CVE-2024-46738 bsc#1230731).
- Update
  patches.suse/bpf-Fix-a-kernel-verifier-crash-in-stacksafe.patch
  (bsc#1225903 CVE-2024-45020 bsc#1230433).
- Update
  patches.suse/can-bcm-Remove-proc-entry-when-dev-is-unregistered.patch
  (git-fixes CVE-2024-46771 bsc#1230766).
- Update
  patches.suse/can-mcp251x-fix-deadlock-if-an-interrupt-occurs-duri.patch
  (git-fixes CVE-2024-46791 bsc#1230821).
- Update
  patches.suse/char-xillybus-Check-USB-endpoints-when-probing-devic.patch
  (git-fixes CVE-2024-45011 bsc#1230440).
- Update
  patches.suse/drm-amd-display-Assign-linear_pitch_alignment-even-f.patch
  (stable-fixes CVE-2024-46732 bsc#1230711).
- Update
  patches.suse/drm-amd-display-Check-denominator-pbn_div-before-use.patch
  (stable-fixes CVE-2024-46773 bsc#1230791).
- Update
  patches.suse/drm-amd-display-Ensure-index-calculation-will-not-ov.patch
  (stable-fixes CVE-2024-46726 bsc#1230706).
- Update
  patches.suse/drm-amd-display-Skip-wbscl_set_scaler_filter-if-filt.patch
  (stable-fixes CVE-2024-46714 bsc#1230699).
- Update
  patches.suse/drm-amd-display-avoid-using-null-object-of-framebuff.patch
  (git-fixes CVE-2024-46694 bsc#1230511).
- Update
  patches.suse/drm-amd-pm-fix-the-Out-of-bounds-read-warning.patch
  (stable-fixes CVE-2024-46731 bsc#1230709).
- Update
  patches.suse/drm-amdgpu-Fix-out-of-bounds-read-of-df_v1_7_channel.patch
  (stable-fixes CVE-2024-46724 bsc#1230725).
- Update
  patches.suse/drm-amdgpu-Fix-out-of-bounds-write-warning.patch
  (stable-fixes CVE-2024-46725 bsc#1230705).
- Update patches.suse/drm-amdgpu-Validate-TA-binary-size.patch
  (stable-fixes CVE-2024-44977 bsc#1230217).
- Update
  patches.suse/drm-amdgpu-fix-dereference-after-null-check.patch
  (stable-fixes CVE-2024-46720 bsc#1230724).
- Update
  patches.suse/drm-amdgpu-fix-mc_data-out-of-bounds-read-warning.patch
  (stable-fixes CVE-2024-46722 bsc#1230712).
- Update
  patches.suse/drm-amdgpu-fix-ucode-out-of-bounds-read-warning.patch
  (stable-fixes CVE-2024-46723 bsc#1230702).
- Update
  patches.suse/drm-mgag200-Bind-I2C-lifetime-to-DRM-device.patch
  (git-fixes CVE-2024-44967 bsc#1230224).
- Update
  patches.suse/drm-msm-dpu-cleanup-FB-if-dpu_format_populate_layout.patch
  (git-fixes CVE-2024-44982 bsc#1230204).
- Update
  patches.suse/fs-netfs-fscache_cookie-add-missing-n_accesses-check.patch
  (bsc#1229453 CVE-2024-45000 bsc#1230170).
- Update
  patches.suse/fscache-delete-fscache_cookie_lru_timer-when-fscache-.patch
  (bsc#1230592 CVE-2024-46786 bsc#1230813).
- Update
  patches.suse/hwmon-adc128d818-Fix-underflows-seen-when-writing-li.patch
  (stable-fixes CVE-2024-46759 bsc#1230814).
- Update
  patches.suse/hwmon-lm95234-Fix-underflows-seen-when-writing-limit.patch
  (stable-fixes CVE-2024-46758 bsc#1230812).
- Update
  patches.suse/hwmon-w83627ehf-Fix-underflows-seen-when-writing-lim.patch
  (stable-fixes CVE-2024-46756 bsc#1230806).
- Update
  patches.suse/mmc-mmc_test-Fix-NULL-dereference-on-allocation-fail.patch
  (git-fixes CVE-2024-45028 bsc#1230450).
- Update
  patches.suse/msft-hv-3046-uio_hv_generic-Fix-kernel-NULL-pointer-dereference-i.patch
  (git-fixes CVE-2024-46739 bsc#1230732).
- Update
  patches.suse/msft-hv-3048-net-mana-Fix-error-handling-in-mana_create_txq-rxq-s.patch
  (git-fixes CVE-2024-46784 bsc#1230771).
- Update
  patches.suse/net-mana-Fix-RX-buf-alloc_size-alignment-and-atomic-.patch
  (bsc#1229086 CVE-2024-45001 bsc#1230244).
- Update
  patches.suse/nfc-pn533-Add-poll-mod-list-filling-check.patch
  (git-fixes CVE-2024-46676 bsc#1230535).
- Update
  patches.suse/nilfs2-fix-missing-cleanup-on-rollforward-recovery-error.patch
  (git-fixes CVE-2024-46781 bsc#1230768).
- Update
  patches.suse/nilfs2-protect-references-to-superblock-parameters-exposed-in-sysfs.patch
  (git-fixes CVE-2024-46780 bsc#1230808).
- Update
  patches.suse/nvmet-tcp-fix-kernel-crash-if-commands-allocation-fa.patch
  (git-fixes CVE-2024-46737 bsc#1230730).
- Update
  patches.suse/pci-hotplug-pnv_php-Fix-hotplug-driver-crash-on-Powe.patch
  (stable-fixes CVE-2024-46761 bsc#1230761).
- Update
  patches.suse/s390-dasd-fix-error-recovery-leading-to-data-corruption-on-ESE-devices.patch
  (git-fixes bsc#1229573 CVE-2024-45026 bsc#1230454).
- Update
  patches.suse/s390-sclp-Prevent-release-of-buffer-in-I-O.patch
  (git-fixes bsc#1229572 CVE-2024-44969 bsc#1230200).
- Update
  patches.suse/usb-dwc3-core-Prevent-USB-core-invalid-event-buffer-.patch
  (git-fixes CVE-2024-46675 bsc#1230533).
- Update
  patches.suse/usb-dwc3-st-fix-probed-platform-device-ref-count-on-.patch
  (git-fixes CVE-2024-46674 bsc#1230507).
- Update
  patches.suse/wifi-mwifiex-Do-not-return-unused-priv-in-mwifiex_ge.patch
  (stable-fixes CVE-2024-46755 bsc#1230802).
- Update
  patches.suse/x86-mtrr-Check-if-fixed-MTRRs-exist-before-saving-them.patch
  (git-fixes CVE-2024-44948 bsc#1230174).
- Update
  patches.suse/xhci-Fix-Panther-point-NULL-pointer-deref-at-full-sp.patch
  (git-fixes CVE-2024-45006 bsc#1230247).
- commit 3ab4fc7

- Update
  patches.suse/media-vivid-fix-compose-size-exceed-boundary.patch
  (git-fixes CVE-2022-48945 bsc#1230398).
- Update
  patches.suse/powerpc-rtas-Prevent-Spectre-v1-gadget-construction-.patch
  (bsc#1227487 CVE-2024-46774 bsc#1230767).
- Update patches.suse/sched-Fix-yet-more-sched_fork-races.patch
  (git fixes (sched/core) CVE-2022-48944 bsc#1229947).
- commit be5b46d

- userfaultfd: fix checks for huge PMDs (CVE-2024-46787
  bsc#1230815).
- commit 731ca61

- cachefiles: Fix non-taking of sb_writers around set/removexattr
  (bsc#1231013).
- commit 8d75b42

- PCI: dwc: Expose dw_pcie_ep_exit() to module (git-fixes).
- commit afe0b92

- PCI: xilinx-nwl: Clean up clock on probe failure/removal
  (git-fixes).
- PCI: xilinx-nwl: Fix off-by-one in INTx IRQ handler (git-fixes).
- PCI: dra7xx: Fix error handling when IRQ request fails in probe
  (git-fixes).
- PCI: Wait for Link before restoring Downstream Buses
  (git-fixes).
- PCI: al: Check IORESOURCE_BUS existence during probe
  (git-fixes).
- PCI: dwc: Restore MSI Receiver mask during resume (git-fixes).
- Refresh
  patches.suse/PCI-dwc-Add-dw_pcie_ops.host_deinit-callback.patch.
- commit 1275322

- Update
  patches.suse/PCI-Add-missing-bridge-lock-to-pci_bus_lock.patch
  (stable-fixes CVE-2024-46750 bsc#1230783).
- commit c259807

- exfat: fix memory leak in exfat_load_bitmap() (git-fixes).
- commit bfe7fd1

- PCI: keystone: Fix if-statement expression in ks_pcie_quirk()
  (git-fixes).
- commit 644bf81

- net: ip_tunnel: prevent perpetual headroom growth
  (CVE-2024-26804 bsc#1222629).
- net: tunnels: annotate lockless accesses to dev-&amp;gt;needed_headroom
  (CVE-2024-26804 bsc#1222629).
- commit 319c5b5

- kabi: add __nf_queue_get_refs() for kabi compliance.
  (bsc#1229633, CVE-2022-48911)
  (cherry picked from commit 09526c9424a7fbc2a4d656f79c4ad7878f435ecb)
- netfilter: nf_queue: fix possible use-after-free (bsc#1229633,
  CVE-2022-48911).
  (cherry picked from commit 758c6b1299c09ef730f452c74ec7f72a9327354f)
- kabi: add __nf_queue_get_refs() for kabi compliance.
- netfilter: nf_queue: fix possible use-after-free (bsc#1229633,
  CVE-2022-48911).
- commit 0bf9c36

- drm/amd/display: Check index for aux_rd_interval before using (bsc#1230703 CVE-2024-46728)
- commit 6a51cab

- RDMA/irdma: fix error message in irdma_modify_qp_roce() (git-fixes)
- commit e49b867

- RDMA/cxgb4: Added NULL check for lookup_atid (git-fixes)
- commit 50d4a10

- RDMA/hns: Optimize hem allocation performance (git-fixes)
- commit 813af9f

- RDMA/hns: Fix VF triggering PF reset in abnormal interrupt handler (git-fixes)
- commit 2bb823b

- RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled (git-fixes)
- commit f6fcd8c

- RDMA/hns: Fix the overflow risk of hem_list_calc_ba_range() (git-fixes)
- commit 328d52f

- RDMA/hns: Don't modify rq next block addr in HIP09 QPC (git-fixes)
- commit 33ac85f

- IB/core: Fix ib_cache_setup_one error flow cleanup (git-fixes)
- commit 01729dd

- RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds (git-fixes)
- commit 68948b5

- RDMA/rtrs: Reset hb_missed_cnt after receiving other traffic from peer (git-fixes)
- commit 65bf6d4

- RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency (git-fixes)
- commit dfdb2f8

- RDMA/core: Remove unused declaration rdma_resolve_ip_route() (git-fixes)
- commit 97307dd

- btrfs: handle errors from btrfs_dec_ref() properly (CVE-2024-46753 bsc#1230796)
- commit 65fd2b1

- btrfs: prevent copying too big compressed lzo segment (CVE-2022-48923 bsc#1229662)
- commit 9c5b30e

- net: tighten bad gso csum offset check in virtio_net_hdr
  (git-fixes).
- commit 34aa4c1

- udp: fix receiving fraglist GSO packets (git-fixes).
- commit fa1c6cd

- xen/swiotlb: fix allocated size (git-fixes).
- commit 6131ead

- xen/swiotlb: add alignment check for dma buffers (bsc#1229928).
- commit eee6dcc

- xen: tolerate ACPI NVS memory overlapping with Xen allocated
  memory (bsc#1226003).
- commit c0747b9

- xen: allow mapping ACPI data using a different physical address
  (bsc#1226003).
- commit c94b5d0

- xen: add capability to remap non-RAM pages to different PFNs
  (bsc#1226003).
- commit 489b422

- xen: move max_pfn in xen_memory_setup() out of function scope
  (bsc#1226003).
- commit 88edee6

- media: vicodec: allow en/decoder cmd w/o CAPTURE (git-fixes).
- commit 6843c76

- media: qcom: camss: Fix ordering of pm_runtime_enable
  (git-fixes).
- commit 262114a

- Revert &amp;quot;media: tuners: fix error return code of
  hybrid_tuner_request_state()&amp;quot; (git-fixes).
- commit 1d6cee4

- xen: move checks for e820 conflicts further up (bsc#1226003).
- commit 305f805

- drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds
  write error (git-fixes).
- commit 8a8aa4d

- net: bridge: xmit: make sure we have at least eth header len
  bytes (CVE-2024-38538 bsc#1226606).
- commit de593a5

- drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds
  write error (git-fixes).
- commit 28bc636

- xen: introduce generic helper checking for memory map conflicts
  (bsc#1226003).
- commit b5a62b0

- xen: use correct end address of kernel for conflict checking
  (bsc#1226003).
- commit 864cea2

- x86/xen: Convert comma to semicolon (git-fixes).
- commit aea0e48

- net: drop bad gso csum_start and offset in virtio_net_hdr
  (git-fixes).
- commit 89b9f35

- crypto: virtio - Wait for tasklet to complete on device remove
  (git-fixes).
- commit 3c716ae

- x86/kaslr: Expose and use the end of the physical memory
  address space (bsc#1230405).
- commit 3201b4e

- Update references for patches.suse/pci-hotplug-pnv_php-Fix-hotplug-driver-crash-on-Powe.patch (CVE-2024-46761 bsc#1230761)
- commit dcc7841

- x86/tdx: Fix data leak in mmio_read() (CVE-2024-46794 bsc#1230825)
- commit c8c34cc

- Update references for patches.suse/hwmon-adc128d818-Fix-underflows-seen-when-writing-li.patch (CVE-2024-46759 bsc#1230814)
- commit 246b51d

- Update references for patches.suse/HID-cougar-fix-slab-out-of-bounds-Read-in-cougar_rep.patch (CVE-2024-46747 bsc#1230752)
- commit d22b00d

- Update references for patches.suse/Input-uinput-reject-requests-with-unreasonable-numbe.patch (CVE-2024-46745 bsc#1230748)
- commit 584f3d0

- Update references for patches.suse/HID-amd_sfh-free-driver_data-after-destroying-hid-de.patch (CVE-2024-46746 bsc#1230751)
- commit 20864a7

- tcp_bpf: fix return value of tcp_bpf_sendmsg() (CVE-2024-46783 bsc#1230810)
- commit 72de3c2

- Update references for patches.suse/fscache-delete-fscache_cookie_lru_timer-when-fscache-.patch (CVE-2024-46786 bsc#1230592 bsc#1230813)
- commit b23da3a

- Update references for patches.suse/nvmet-tcp-fix-kernel-crash-if-commands-allocation-fa.patch (CVE-2024-46737 bsc#1230730)
- commit a2b9776

- scsi: lpfc: Copyright updates for 14.4.0.4 patches
  (bsc#1229429).
- scsi: lpfc: Update lpfc version to 14.4.0.4 (bsc#1229429).
- scsi: lpfc: Update PRLO handling in direct attached topology
  (bsc#1229429).
- scsi: lpfc: Fix unsolicited FLOGI kref imbalance when in direct
  attached topology (bsc#1229429).
- scsi: lpfc: Fix unintentional double clearing of vmid_flag
  (bsc#1229429).
- scsi: lpfc: Validate hdwq pointers before dereferencing in
  reset/errata paths (bsc#1229429).
- scsi: lpfc: Remove redundant vport assignment when building
  an abort request (bsc#1229429).
- scsi: lpfc: Change diagnostic log flag during receipt of
  unknown ELS cmds (bsc#1229429).
- scsi: lpfc: Fix overflow build issue (bsc#1229429).
- commit 6dfc9ed

- net/mlx5e: SHAMPO, Fix incorrect page release (CVE-2024-46717 bsc#1230719)
- commit dcc83f4

- btrfs: don't BUG_ON() when 0 reference count at
  btrfs_lookup_extent_info() (bsc#1230786 CVE-2024-46751).
- btrfs: reduce nesting for extent processing at
  btrfs_lookup_extent_info() (bsc#1230794 CVE-2024-46752).
- btrfs: remove superfluous metadata check at
  btrfs_lookup_extent_info() (bsc#1230794 CVE-2024-46752).
- btrfs: replace BUG_ON() with error handling at
  update_ref_for_cow() (bsc#1230794 CVE-2024-46752).
- btrfs: simplify setting the full backref flag at
  update_ref_for_cow() (bsc#1230794 CVE-2024-46752).
- btrfs: remove NULL transaction support for
  btrfs_lookup_extent_info() (bsc#1230794 CVE-2024-46752).
- btrfs: remove level argument from btrfs_set_block_flags
  (bsc#1230794 CVE-2024-46752).
- btrfs: sink parameter is_data to btrfs_set_disk_extent_flags
  (bsc#1230794 CVE-2024-46752).
- commit c2d0eaf

- kABI, crypto: virtio - Handle dataq logic with tasklet
  (git-fixes).
- commit 7b17b1c

- nvmet: Identify-Active Namespace ID List command should reject
  invalid nsid (git-fixes).
- nvme-pci: Add sleep quirk for Samsung 990 Evo (git-fixes).
- nvmet-tcp: fix kernel crash if commands allocation fails
  (git-fixes).
- nvme: move stopping keep-alive into nvme_uninit_ctrl()
  (git-fixes).
- nvme/pci: Add APST quirk for Lenovo N60z laptop (git-fixes).
- nvmet-rdma: fix possible bad dereference when freeing rsps
  (git-fixes).
- nvmet-tcp: do not continue for invalid icreq (git-fixes).
- nvmet-trace: avoid dereferencing pointer too early (git-fixes).
- commit 14b1d67

- drm/amd/display: Ensure array index tg_inst won't be -1 (bsc#1230701 CVE-2024-46730)
- commit 45e46f9

- Update
  patches.suse/vfio-pci-fix-potential-memory-leak-in-vfio_intx_enab.patch
  (git-fixes CVE-2024-38632 bsc#1226860).
  Add CVE references.
- commit bd2cc38

- nilfs2: fix potential oob read in nilfs_btree_check_delete()
  (git-fixes).
- commit 157099e

- nilfs2: determine empty node blocks as corrupted (git-fixes).
- commit 657f164

- nilfs2: fix potential null-ptr-deref in nilfs_btree_insert()
  (git-fixes).
- commit 24419a8

- media: mtk-vcodec: potential null pointer deference in SCP (CVE-2024-40973 bsc#1227890)
- commit d0ab63e

- btrfs: do not start relocation until in progress drops are done
  (bsc#1229607 CVE-2022-48901).
- Refresh
  patches.suse/btrfs-sysfs-update-fs-features-directory-asynchronou.patch.
- commit a5756e7

- of/irq: Prevent device address out-of-bounds read in interrupt
  map walk (CVE-2024-46743 bsc#1230756).
- commit 2dc0a89

- ocfs2: cancel dqi_sync_work before freeing oinfo (git-fixes).
- commit f3e346f

- ocfs2: remove unreasonable unlock in ocfs2_read_blocks
  (git-fixes).
- commit 2d8f102

- ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate
  (git-fixes).
- commit e09cbac

- ocfs2: fix null-ptr-deref when journal load failed (git-fixes).
- commit 25c83fa

- jfs: fix out-of-bounds in dbNextAG() and diAlloc() (git-fixes).
- commit 2205648

- driver: iio: add missing checks on iio_info's callback access
  (CVE-2024-46715 bsc#1230700).
- commit 44ce0f3

- i2c: qcom-geni: Use IRQF_NO_AUTOEN flag in request_irq()
  (git-fixes).
- i2c: isch: Add missed 'else' (git-fixes).
- i2c: xiic: Wait for TX empty to avoid missed TX NAKs
  (git-fixes).
- i2c: aspeed: Update the stop sw state when the bus recovery
  occurs (git-fixes).
- drivers:drm:exynos_drm_gsc:Fix wrong assignment in gsc_bind()
  (git-fixes).
- drm/msm: fix %s null argument error (git-fixes).
- drm/msm/a5xx: workaround early ring-buffer emptiness check
  (git-fixes).
- drm/msm/a5xx: fix races in preemption evaluation stage
  (git-fixes).
- drm/msm/a5xx: properly clear preemption records on resume
  (git-fixes).
- drm/msm/a5xx: disable preemption in submits by default
  (git-fixes).
- drm/msm: Fix incorrect file name output in adreno_request_fw()
  (git-fixes).
- drm: omapdrm: Add missing check for alloc_ordered_workqueue
  (git-fixes).
- drm/radeon/evergreen_cs: fix int overflow errors in cs track
  offsets (git-fixes).
- drm/amd/amdgpu: Properly tune the size of struct (git-fixes).
- drm/amdgpu: fix a possible null pointer dereference (git-fixes).
- drm/radeon: fix null pointer dereference in
  radeon_add_common_modes (git-fixes).
- drm/bridge: lontium-lt8912b: Validate mode in
  drm_bridge_funcs::mode_valid() (git-fixes).
- drm/rockchip: dw_hdmi: Fix reading EDID when using a forced mode
  (git-fixes).
- drm/rockchip: vop: Allow 4096px width scaling (git-fixes).
- drm/stm: ltdc: check memory returned by devm_kzalloc()
  (git-fixes).
- tpm: Clean up TPM space after command failure (git-fixes).
- ipmi: docs: don't advertise deprecated sysfs entries
  (git-fixes).
- commit a7fb7f8

- md/raid5: avoid BUG_ON() while continue reshape after
  reassembling (bsc#1229790, CVE-2024-43914).
- commit 3bf0292

- NFS: Reduce use of uncached readdir (bsc#1226662).
- NFS: Don't re-read the entire page cache to find the next cookie
  (bsc#1226662).
- commit 25632eb

- pinctrl: single: fix potential NULL dereference in pcs_get_function() (CVE-2024-46685 bsc#1230515)
- commit 16fd035

- thunderbolt: Mark XDomain as unplugged when router is removed (CVE-2024-46702 bsc#1230589)
- commit 0a04e5e

- soc: qcom: cmd-db: Map shared memory as WC, not WB (CVE-2024-46689 bsc#1230524)
- commit d574d3c

- smb/client: avoid dereferencing rdata=NULL in smb2_new_read_req() (CVE-2024-46686 bsc#1230517)
- commit eecf85c

- scsi: aacraid: Fix double-free on probe failure (CVE-2024-46673 bsc#1230506)
- commit 23b1681

- apparmor: fix possible NULL pointer dereference (CVE-2024-46721 bsc#1230710)
- commit 02a056d

- gtp: fix a potential NULL pointer dereference (CVE-2024-46677 bsc#1230549)
- commit e4c4047

- ethtool: check device is present when getting link settings (CVE-2024-46679 bsc#1230556)
- commit 12d1e30

- vhost-vdpa: switch to use vmf_insert_pfn() in the fault handler
  (git-fixes).
- commit a4cc5f2

- net: missing check virtio (git-fixes).
- commit 5c4c37d

- virtio_net: checksum offloading handling fix (git-fixes).
- commit d5e193e

- virtio: delete vq in vp_find_vqs_msix() when request_irq()
  fails (CVE-2024-37353 bsc#1226875).
- commit 7853f36

- vhost: Add smp_rmb() in vhost_vq_avail_empty() (git-fixes).
- commit 1d51d93

- virtio: reenable config if freezing device failed (git-fixes).
- commit 92899fb

- virtio-blk: Ensure no requests in virtqueues before deleting
  vqs (git-fixes).
- commit 5677525

- virtio_net: Fix &amp;quot;'%d' directive writing between 1 and 11 bytes into
  a region of size 10&amp;quot; warnings (git-fixes).
- commit c6eef4e

- virtio/vsock: fix logic which reduces credit update messages
  (git-fixes).
- commit ba4fb58

- KABI: kcm: Serialise kcm_sendmsg() for the same socket
  (CVE-2024-44946 bsc#1230015).
- commit 4220de4

- kcm: Serialise kcm_sendmsg() for the same socket
  (CVE-2024-44946 bsc#1230015).
- commit 195f676

- crypto: virtio - Handle dataq logic with tasklet (git-fixes).
- commit a7e32aa

- vsock/virtio: remove socket from connected/bound list on
  shutdown (git-fixes).
- commit 0f347cf

- virtio_net: use u64_stats_t infra to avoid data-races
  (git-fixes).
- commit 463733f

- vsock/virtio: initialize the_virtio_vsock before using VQs
  (git-fixes).
- commit 1fec77b

- tools/virtio: fix build (git-fixes).
- commit e7f47cc

- xfs: don't include bnobt blocks when reserving free block pool
  (git-fixes).
- commit 3c9db4e

- vsock/virtio: add support for device suspend/resume (git-fixes).
- commit 010c69d

- vsock/virtio: factor our the code to initialize and delete VQs
  (git-fixes).
- commit 21a4d2a

- fbdev: hpfb: Fix an error handling path in hpfb_dio_probe()
  (git-fixes).
- hwmon: (ntc_thermistor) fix module autoloading (git-fixes).
- hwmon: (max16065) Fix overflows seen when writing limits
  (git-fixes).
- mtd: powernv: Add check devm_kasprintf() returned value
  (git-fixes).
- mtd: slram: insert break after errors in parsing the map
  (git-fixes).
- power: supply: hwmon: Fix missing temp1_max_alarm attribute
  (git-fixes).
- power: supply: Drop use_cnt check from
  power_supply_property_is_writeable() (git-fixes).
- power: supply: max17042_battery: Fix SOC threshold calc w/
  no current sense (git-fixes).
- power: supply: axp20x_battery: Remove design from min and max
  voltage (git-fixes).
- drm/amdgpu/atomfirmware: Silence UBSAN warning (stable-fixes).
- drm/msm/adreno: Fix error return if missing firmware-name
  (stable-fixes).
- commit 392a8e2

- Update patches.suse/NFS-never-reuse-a-NFSv4-0-lock-owner.patch
  (bsc#1227726 bsc#1230733).
- commit c293534

- x86/mm/ident_map: Use gbpages only where full GB page should
  be mapped (bsc#1220382).
- x86/kexec: Add EFI config table identity mapping for kexec
  kernel (bsc#1220382).
- commit 0e4e6bb

- Refresh
  patches.suse/Bluetooth-hci_ldisc-check-HCI_UART_PROTO_READY-flag-.patch.
  Update upstream status and move to the sorted section.
- commit 43dbf50

- Refresh
  patches.suse/0001-drm-amdgpu-don-t-use-BACO-for-reset-in-S3.patch.
  Add alternative commit ID.
- commit c139057

- PCI/ASPM: Remove struct aspm_latency (bsc#1226915)
- commit daa2cc5

- PCI/ASPM: Stop caching device L0s, L1 acceptable exit latencies (bsc#1226915)
- commit 1a96576

- PCI/ASPM: Stop caching link L0s, L1 exit latencies (bsc#1226915)
- commit 99a4208

- PCI/ASPM: Move pci_function_0() upward (bsc#1226915)
- commit 9dc3dba

- cpufreq: ti-cpufreq: Introduce quirks to handle syscon fails
  appropriately (git-fixes).
- ACPI: CPPC: Fix MASK_VAL() usage (git-fixes).
- ACPI: PMIC: Remove unneeded check in
  tps68470_pmic_opregion_probe() (git-fixes).
- ACPI: sysfs: validate return type of _STR method (git-fixes).
- hwrng: mtk - Use devm_pm_runtime_enable (git-fixes).
- crypto: ccp - Properly unregister /dev/sev on sev
  PLATFORM_STATUS failure (git-fixes).
- hwrng: cctrng - Add missing clk_disable_unprepare in
  cctrng_resume (git-fixes).
- hwrng: bcm2835 - Add missing clk_disable_unprepare in
  bcm2835_rng_init (git-fixes).
- crypto: xor - fix template benchmarking (git-fixes).
- can: bcm: Clear bo-&amp;gt;bcm_proc_read after remove_proc_entry()
  (git-fixes).
- Bluetooth: btusb: Fix not handling ZPL/short-transfer
  (git-fixes).
- Bluetooth: hci_sync: Ignore errors from
  HCI_OP_REMOTE_NAME_REQ_CANCEL (git-fixes).
- Bluetooth: hci_core: Fix sending MGMT_EV_CONNECT_FAILED
  (git-fixes).
- wifi: mt76: mt7615: check devm_kasprintf() returned value
  (git-fixes).
- wifi: mt76: mt7915: fix rx filter setting for bfee functionality
  (git-fixes).
- wifi: rtw88: remove CPT execution branch never used (git-fixes).
- wifi: wilc1000: fix potential RCU dereference issue in
  wilc_parse_join_bss_param (git-fixes).
- wifi: mac80211: use two-phase skb reclamation in
  ieee80211_do_stop() (git-fixes).
- wifi: cfg80211: fix two more possible UBSAN-detected off-by-one
  errors (git-fixes).
- wifi: cfg80211: fix UBSAN noise in cfg80211_wext_siwscan()
  (git-fixes).
- wifi: iwlwifi: mvm: increase the time between ranging
  measurements (git-fixes).
- wifi: rtw88: always wait for both firmware loading attempts
  (git-fixes).
- wifi: rtw88: 8822c: Fix reported RX band width (git-fixes).
- can: j1939: use correct function name in comment (git-fixes).
- commit b2930fe

- KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3
  (CVE-2024-46707 bsc#1230582).
- commit bb45424

- x86/xen: Convert comma to semicolon (git-fixes).
- commit f308bb3

- Refresh
  patches.suse/virtio-blk-scsi-use-block-layer-helpers-to-calculate.patch.
  The compiler is unhappy with the types. Add a cast to tell what the
  compiler should do.
- commit aba9465

- usb: dwc3: core: update LC timer as per USB Spec V3.2
  (git-fixes).
- commit b3f5137

- usb: uas: set host status byte on data completion error
  (git-fixes).
- commit 842e02d

- fscache: delete fscache_cookie_lru_timer when fscache exits
  to avoid  UAF (bsc#1230592).
- virtiofs: forbid newlines in tags (bsc#1230591).
- commit 03e6dba

- x86/hyperv: fix kexec crash due to VP assist page corruption
  (git-fixes).
- Drivers: hv: vmbus: Fix the misplaced function description
  (git-fixes).
- commit f7a5c89

- NFSv4: Add missing rescheduling points in
  nfs_client_return_marked_delegations (git-fixes).
- NFSD: Fix frame size warning in svc_export_parse() (git-fixes).
- NFSD: Rewrite synopsis of nfsd_percpu_counters_init()
  (git-fixes).
- commit 6327192

- ASoC: meson: axg-card: fix 'use-after-free' (git-fixes).
- commit 3824ded

- spi: nxp-fspi: fix the KASAN report out-of-bounds bug
  (git-fixes).
- drm/i915/guc: prevent a possible int overflow in wq offsets
  (git-fixes).
- platform/x86: panasonic-laptop: Allocate 1 entry extra in the
  sinf array (git-fixes).
- platform/x86: panasonic-laptop: Fix SINF array out of bounds
  accesses (git-fixes).
- usb: dwc3: core: update LC timer as per USB Spec V3.2
  (stable-fixes).
- ALSA: hda/realtek: Support mute LED on HP Laptop 14-dq2xxx
  (stable-fixes).
- ALSA: hda/realtek: add patch for internal mic in Lenovo V145
  (stable-fixes).
- ALSA: hda/conexant: Add pincfg quirk to enable top speakers
  on Sirius devices (stable-fixes).
- ata: libata: Fix memory leak for error path in ata_host_alloc()
  (git-fixes).
- Input: uinput - reject requests with unreasonable number of
  slots (stable-fixes).
- ata: pata_macio: Use WARN instead of BUG (stable-fixes).
- HID: amd_sfh: free driver_data after destroying hid device
  (stable-fixes).
- HID: cougar: fix slab-out-of-bounds Read in cougar_report_fixup
  (stable-fixes).
- i2c: Use IS_REACHABLE() for substituting empty ACPI functions
  (git-fixes).
- i2c: Fix conditional for substituting empty ACPI functions
  (stable-fixes).
- i3c: mipi-i3c-hci: Error out instead on BUG_ON() in IBI DMA
  setup (stable-fixes).
- devres: Initialize an uninitialized struct member
  (stable-fixes).
- pcmcia: Use resource_size function on resource object
  (stable-fixes).
- pci/hotplug/pnv_php: Fix hotplug driver crash on Powernv
  (stable-fixes).
- PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)
  (stable-fixes).
- PCI: Add missing bridge lock to pci_bus_lock() (stable-fixes).
- usb: uas: set host status byte on data completion error
  (stable-fixes).
- usb: typec: ucsi: Fix null pointer dereference in trace
  (stable-fixes).
- usbip: Don't submit special requests twice (stable-fixes).
- ASoC: topology: Properly initialize soc_enum values
  (stable-fixes).
- ALSA: hda: Add input value sanity checks to HDMI channel map
  controls (stable-fixes).
- drm/amdgpu: Set no_hw_access when VF request full GPU fails
  (stable-fixes).
- drm/amdgpu: check for LINEAR_ALIGNED correctly in
  check_tiling_flags_gfx6 (stable-fixes).
- drm/amd/display: Check denominator pbn_div before used
  (stable-fixes).
- drm/amdgpu: clear RB_OVERFLOW bit when enabling interrupts
  (stable-fixes).
- drm/amdgpu: Fix smatch static checker warning (stable-fixes).
- drm/amd/display: Check HDCP returned status (stable-fixes).
- media: qcom: camss: Add check for v4l2_fwnode_endpoint_parse
  (stable-fixes).
- media: vivid: don't set HDMI TX controls if there are no HDMI
  outputs (stable-fixes).
- media: vivid: fix wrong sizeimage value for mplane
  (stable-fixes).
- media: uvcvideo: Enforce alignment of frame and interval
  (stable-fixes).
- wifi: mwifiex: Do not return unused priv in
  mwifiex_get_priv_by_id() (stable-fixes).
- wifi: brcmsmac: advertise MFP_CAPABLE to enable WPA3
  (stable-fixes).
- hwmon: (w83627ehf) Fix underflows seen when writing limit
  attributes (stable-fixes).
- hwmon: (lm95234) Fix underflows seen when writing limit
  attributes (stable-fixes).
- hwmon: (adc128d818) Fix underflows seen when writing limit
  attributes (stable-fixes).
- ACPI: processor: Fix memory leaks in error paths of
  processor_add() (stable-fixes).
- ACPI: processor: Return an error if acpi_processor_get_info()
  fails in processor_add() (stable-fixes).
- commit c0216a0

- nvme: move stopping keep-alive into nvme_uninit_ctrl() (CVE-2024-45013 bsc#1230442)
- commit 5ac8578

- i2c: tegra: Do not mark ACPI devices as irq safe (CVE-2024-45029 bsc#1230451)
- commit 12f7852

- netfilter: flowtable: initialise extack before use (CVE-2024-45018 bsc#1230431)
- commit 25df9d1

- drm/msm/disp/dpu: use atomic enable/disable callbacks for encoder (bsc#1230444)
- commit 4fb379d

- memcg_write_event_control(): fix a user-triggerable oops
  (CVE-2024-45021 bsc#1230434).
- commit f5c92ca

- usbnet: ipheth: race between ipheth_close and error handling
  (git-fixes).
- commit 7ee6be8

- Refresh
  patches.suse/USB-serial-option-add-MeiG-Smart-SRM825L.patch.
- commit 7c21712

- memcg_write_event_control(): fix a user-triggerable oops
  (CVE-2024-45021 bsc#1230434).
- commit d21e438

- Squashfs: sanity check symbolic link size (git-fixes).
- commit 38be121

- Revert &amp;quot;mm/sparsemem: fix race in accessing memory_section-&amp;gt;usage&amp;quot;
  This reverts commit 606bd9b8228bfe004cf6ab930ffb673a535e3c55.
- commit 532bbfe

- Revert &amp;quot;mm, kmsan: fix infinite recursion due to RCU critical section&amp;quot;
  This reverts commit 1702784a5db6b26695f0bc2c6b0cbe973db5c0f3.
- commit e220e83

- Revert &amp;quot;mm: prevent derefencing NULL ptr in pfn_section_valid()&amp;quot;
  This reverts commit d77caa16c18115f0c470ecf5cdd3cdb6f9865aeb.
- commit b38d226

- drm/msm/dpu: move dpu_encoder's connector assignment to (bsc#1230444 CVE-2024-45015)
- commit baea6a3

- media: aspeed: Fix memory overwrite if timing is 1600x900 (bsc#1230269 CVE-2023-52916)
- commit 1c1f90d

- media: aspeed: Fix no complete irq for non-64-aligned width (bsc#1230269)
- commit 63b4ff1

- RDMA/efa: Properly handle unexpected AQ completions (git-fixes)
- commit 9995679

- net: dsa: bcm_sf2: Fix a possible memory leak in bcm_sf2_mdio_register() (CVE-2024-44971 bsc#1230211)
- commit 6f30d53

- bonding: fix xfrm real_dev null pointer dereference (CVE-2024-44989 bsc#1230193)
- commit 656ad24

- Input: MT - limit max slots (CVE-2024-45008 bsc#1230248).
- commit 9c6f084

- net/mlx5e: SHAMPO, Fix invalid WQ linked list unlink
  (CVE-2024-44970 bsc#1230209).
- commit 204a351

- bonding: fix null pointer deref in bond_ipsec_offload_ok
  (CVE-2024-44990 bsc#1230194).
- commit caaca9d

- blk-mq: issue warning when offlining hctx with online isolcpus
  (bsc#1229034).
- commit c169848

- Refresh
  patches.suse/net-bridge-switchdev-Skip-MDB-replays-of-deferred-ev.patch.
- commit 0ae4275

- media: Revert &amp;quot;media: dvb-usb: Fix unexpected infinite loop
  in dvb_usb_read_remote_control()&amp;quot; (git-fixes).
- commit 69c4bbe

- lirc: rc_dev_get_from_fd(): fix file leak (git-fixes).
- commit 5094611

- drm/amd/display: fixed integer types and null check locations
  (CVE-2024-26767 bsc#1230339).
- commit 91909ca

- Fix KABI for
  patches.suse/dm_blk_ioctl-implement-path-failover-for-SG_IO.patch
  (bsc#1230392).
- Update
  patches.suse/dm_blk_ioctl-implement-path-failover-for-SG_IO.patch
  (bsc#1230392).
- commit cbecb11

- net: dsa: mv88e6xxx: Fix out-of-bound access (CVE-2024-44988 bsc#1230192)
- commit e74f32c

- ipv6: prevent UAF in ip6_send_skb() (CVE-2024-44987 bsc#1230185)
- commit fd19d1b

- ipv6: fix possible UAF in ip6_finish_output2() (CVE-2024-44986 bsc#1230230)
- commit 6ffd49a

- gtp: pull network headers in gtp_dev_xmit() (CVE-2024-44999 bsc#1230233)
- commit e1f3131

- ipmi:ssif: Improve detecting during probing (bsc#1228771)
- commit fac58ad

- mm/swap: fix race when skipping swapcache (CVE-2024-26759
  bsc#1230340).
- commit 8d9f1de

- filemap: remove use of wait bookmarks (bsc#1224085).
- commit a120011

- VMCI: Fix use-after-free when removing resource in
  vmci_resource_remove() (git-fixes).
- iio: fix scale application in
  iio_convert_raw_to_processed_unlocked (git-fixes).
- iio: adc: ad7124: fix config comparison (git-fixes).
- iio: adc: ad7124: fix chip ID mismatch (git-fixes).
- iio: buffer-dmaengine: fix releasing dma channel on error
  (git-fixes).
- staging: iio: frequency: ad9834: Validate frequency parameter
  value (git-fixes).
- drm/amd/display: Skip wbscl_set_scaler_filter if filter is null
  (stable-fixes).
- drm/amd/display: Correct the defined value for
  AMDGPU_DMUB_NOTIFICATION_MAX (stable-fixes).
- drm/amd/display: added NULL check at start of dc_validate_stream
  (stable-fixes).
- drm/bridge: tc358767: Check if fully initialized before
  signalling HPD event via IRQ (stable-fixes).
- commit fae29ce

- ALSA: hda/conexant: Mute speakers at suspend / shutdown
  (stable-fixes).
- ALSA: hda/generic: Add a helper to mute speakers at
  suspend/shutdown (stable-fixes).
- drm/meson: plane: Add error handling (stable-fixes).
- drm/amdgpu: update type of buf size to u32 for eeprom functions
  (stable-fixes).
- drm/amd/pm: check negtive return for table entries
  (stable-fixes).
- drm/amdgpu: the warning dereferencing obj for nbio_v7_4
  (stable-fixes).
- drm/amd/pm: check specific index for aldebaran (stable-fixes).
- drm/amdgpu: fix the waring dereferencing hive (stable-fixes).
- drm/amdgpu: fix dereference after null check (stable-fixes).
- drm/amdgpu/pm: Check input value for CUSTOM profile mode
  setting on legacy SOCs (stable-fixes).
- drm/amdkfd: Reconcile the definition and use of oem_id in
  struct kfd_topology_device (stable-fixes).
- drm/amdgpu: fix mc_data out-of-bounds read warning
  (stable-fixes).
- drm/amdgpu: fix ucode out-of-bounds read warning (stable-fixes).
- drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number
  (stable-fixes).
- drm/amdgpu: Fix out-of-bounds write warning (stable-fixes).
- drm/amdgpu/pm: Fix uninitialized variable agc_btc_response
  (stable-fixes).
- drm/amdgpu/pm: Fix uninitialized variable warning for smu10
  (stable-fixes).
- drm/amd/pm: fix uninitialized variable warnings for vangogh_ppt
  (stable-fixes).
- drm/amd/amdgpu: Check tbo resource pointer (stable-fixes).
- drm/amd/display: Skip inactive planes within
  ModeSupportAndSystemConfiguration (stable-fixes).
- drm/amd/display: Ensure index calculation will not overflow
  (stable-fixes).
- drm/amd/display: Spinlock before reading event (stable-fixes).
- drm/amd/display: Fix Coverity INTEGER_OVERFLOW within
  dal_gpio_service_create (stable-fixes).
- drm/amd/display: Check msg_id before processing transcation
  (stable-fixes).
- drm/amd/display: Check num_valid_sets before accessing
  reader_wm_sets[] (stable-fixes).
- drm/amd/display: Add array index check for hdcp ddc access
  (stable-fixes).
- drm/amd/display: Stop amdgpu_dm initialize when stream nums
  greater than 6 (stable-fixes).
- drm/amd/display: Check gpio_id before used as array index
  (stable-fixes).
- drm/amdgpu: avoid reading vf2pf info size from FB
  (stable-fixes).
- drm/amd/pm: fix uninitialized variable warnings for vega10_hwmgr
  (stable-fixes).
- drm/amd/pm: fix the Out-of-bounds read warning (stable-fixes).
- drm/amd/pm: Fix negative array index read (stable-fixes).
- drm/amd/pm: fix warning using uninitialized value of
  max_vid_step (stable-fixes).
- drm/amd/pm: fix uninitialized variable warning for smu8_hwmgr
  (stable-fixes).
- drm/amd/pm: fix uninitialized variable warning (stable-fixes).
- drm/amdgpu/pm: Check the return value of smum_send_msg_to_smc
  (stable-fixes).
- drm/amdgpu: fix overflowed array index read warning
  (stable-fixes).
- drm/amd/display: Assign linear_pitch_alignment even for VM
  (stable-fixes).
- drm/amdgpu: Fix uninitialized variable warning in
  amdgpu_afmt_acr (stable-fixes).
- commit 22196ae

- Drivers: hv: vmbus: Fix rescind handling in uio_hv_generic
  (git-fixes).
- uio_hv_generic: Fix kernel NULL pointer dereference in
  hv_uio_rescind (git-fixes).
- net: mana: Fix error handling in mana_create_txq/rxq's NAPI
  cleanup (git-fixes).
- commit 392d522

- usb: dwc3: st: add missing depopulate in probe error path
  (git-fixes).
- commit 5abd1b6

- usb: dwc3: st: fix probed platform device ref count on probe
  error path (git-fixes).
- commit 7faef21

- usb: dwc3: omap: add missing depopulate in probe error path
  (git-fixes).
- commit 50650b1

- clk: qcom: clk-alpha-pll: Fix zonda set_rate failure when PLL
  is disabled (git-fixes).
- clk: qcom: clk-alpha-pll: Fix the trion pll postdiv set rate
  API (git-fixes).
- clk: qcom: clk-alpha-pll: Fix the pll post div mask (git-fixes).
- ASoC: sunxi: sun4i-i2s: fix LRCLK polarity in i2s mode
  (git-fixes).
- ASoc: SOF: topology: Clear SOF link platform name upon unload
  (git-fixes).
- ASoC: tegra: Fix CBB error during probe() (git-fixes).
- ASoC: dapm: Fix UAF for snd_soc_pcm_runtime object (git-fixes).
- mmc: cqhci: Fix checking of CQHCI_HALT state (git-fixes).
- mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K
  (git-fixes).
- mmc: sdhci-of-aspeed: fix module autoloading (git-fixes).
- drm/i915/fence: Mark debug_fence_free() with __maybe_unused
  (git-fixes).
- drm/i915/fence: Mark debug_fence_init_onstack() with
  __maybe_unused (git-fixes).
- commit 3d813e4

- wifi: nl80211: disallow setting special AP channel widths (CVE-2024-43912 bsc#1229830)
- commit 58d7754

- Restore dropped fields for bluetooth MGMT/SMP structs
  (git-fixes).
- commit 697b5de

- usbnet: modern method to get random MAC (git-fixes).
- Bluetooth: MGMT: Ignore keys being loaded with invalid type
  (git-fixes).
- Revert &amp;quot;Bluetooth: MGMT/SMP: Fix address type when using SMP
  over BREDR/LE&amp;quot; (git-fixes).
- can: mcp251x: fix deadlock if an interrupt occurs during
  mcp251x_open (git-fixes).
- can: bcm: Remove proc entry when dev is unregistered
  (git-fixes).
- platform/x86: dell-smbios: Fix error path in dell_smbios_init()
  (git-fixes).
- commit 2df245a

- ext4: check dot and dotdot of dx_root before making dir indexed
  (bsc#1229363 CVE-2024-42305).
- commit 85db03a

- vfs: Don't evict inode under the inode lru traversing context
  (CVE-2024-45003 bsc#1230245).
- commit 82e6e44

- char: xillybus: Check USB endpoints when probing device
  (git-fixes).
- char: xillybus: Refine workqueue handling (CVE-2024-45007
  bsc#1230175).
- char: xillybus: Don't destroy workqueue from work item running
  on it (CVE-2024-45007 bsc#1230175).
- commit 47704bc

- serial: sc16is7xx: fix invalid FIFO access with special register
  set (CVE-2024-44950 bsc#1230180).
- commit 6ff419f

- ACPI: SBS: manage alarm sysfs attribute through psy core
  (git-fixes).
- ACPI: battery: create alarm sysfs attribute atomically
  (git-fixes).
- commit 272cbf0

- NFS: never reuse a NFSv4.0 lock-owner (bsc#1227726).
- commit 9dc4a6f

- driver core: Add missing parameter description to
  __fwnode_link_add() (git-fixes).
- commit b36a347

- ext4: sanity check for NULL pointer after ext4_force_shutdown
  (bsc#1229753 CVE-2024-43898).
- commit 5e594a9

- ext4: fix infinite loop when replaying fast_commit (bsc#1229394
  CVE-2024-43828).
- commit c02cd83

- udf: Avoid using corrupted block bitmap buffer (bsc#1229362
  CVE-2024-42306).
- commit 461fe08

- protect the fetch of -&amp;gt;fd[fd] in do_dup2() from mispredictions
  (bsc#1229334 CVE-2024-42265).
- commit 1129dda

- ext4: make sure the first directory block is not a hole
  (bsc#1229364 CVE-2024-42304).
- commit 26f77f8

- driver core: Fix uevent_show() vs driver detach race
  (CVE-2024-44952 bsc#1230178).
- commit 0d8efe8

- atm: idt77252: prevent use after free in dequeue_rx()
  (CVE-2024-44998 bsc#1230171).
- commit ea6216f

- tcp: add sanity checks to rx zerocopy (CVE-2024-26640
  bsc#1221650).
- commit 57d4108

- driver core: fw_devlink: Consolidate device link flag
  computation (git-fixes).
- driver core: fw_devlink: Allow marking a fwnode link as being
  part of a cycle (git-fixes).
- driver core: fw_devlink: Don't purge child fwnode's consumer
  links (git-fixes).
  Refresh
  patches.suse/driver-core-Introduce-device_link_wait_removal.patch.
- driver core: Add wait_for_init_devices_probe helper function
  (git-fixes).
  Refresh
  patches.suse/driver-core-Introduce-device_link_wait_removal.patch.
- driver core: Add debug logs when fwnode links are added/deleted
  (git-fixes).
- driver core: Create __fwnode_link_del() helper function
  (git-fixes).
- driver core: Set deferred probe reason when deferred by driver
  core (git-fixes).
- commit 164932e

- net: bridge: switchdev: Skip MDB replays of deferred events
  on offload (CVE-2024-26837 bsc#1222973).
- commit 3cf54c6

- USB: serial: option: add MeiG Smart SRM825L (git-fixes).
- commit 7b935d7

- cdc-acm: Add DISABLE_ECHO quirk for GE HealthCare UI Controller
  (git-fixes).
- commit 2395491

- usb: dwc3: core: Prevent USB core invalid event buffer address
  access (git-fixes).
- commit 55d4338

- usb: dwc3: core: Skip setting event buffers for host only
  controllers (git-fixes).
- commit 352e074

- nilfs2: fix state management in error path of log writing
  function (git-fixes).
- commit d45c3fc

- nilfs2: fix missing cleanup on rollforward recovery error
  (git-fixes).
- commit 819efb5

- nilfs2: protect references to superblock parameters exposed
  in sysfs (git-fixes).
- commit 85cfeab

- nilfs2: Constify struct kobj_type (git-fixes).
- commit 157952f

- nilfs2: use default_groups in kobj_type (git-fixes).
- commit 9ed2d62

- nilfs2: replace snprintf in show functions with sysfs_emit
  (git-fixes).
- commit 137f088

- gfs2: setattr_chown: Add missing initialization (git-fixes).
- commit 3d57dce

- IB/hfi1: Fix potential deadlock on &amp;amp;irq_src_lock and &amp;amp;dd-&amp;gt;uctxt_lock (git-fixes)
- commit a8ffc3d

- RDMA/rtrs: Fix the problem of variable not initialized fully (git-fixes)
- commit 264a15d

- arm64: tlb: Allow range operation for MAX_TLBI_RANGE_PAGES (bsc#1229585)
- commit e2ccb4d

- arm64: tlb: Improve __TLBI_VADDR_RANGE() (bsc#1229585)
- commit 0534ffe

- arm64: tlb: Fix TLBI RANGE operand (bsc#1229585)
- commit 21c5e59

- arm64/mm: Update tlb invalidation routines for FEAT_LPA2 (bsc#1229585)
- commit a1743f6

- arm64/mm: Modify range-based tlbi to decrement scale (bsc#1229585)
- commit 823cdf8

- net/sched: act_ct: fix skb leak and crash on ooo frags
  (CVE-2023-52610 bsc#1221610).
- commit 57db46f

- netfilter: ctnetlink: use helper function to calculate expect ID
  (CVE-2024-44944 bsc#1229899).
- commit 744b379

- sctp: Fix null-ptr-deref in reuseport_add_sock()
  (CVE-2024-44935 bsc#1229810).
- commit d4709fe

- Bluetooth: L2CAP: Fix deadlock (git-fixes).
- commit 9438e54

- bluetooth/l2cap: sync sock recv cb and release (bsc#1228576
  CVE-2024-41062).
- commit 5b1f743

- Update references
- commit a096907

- fuse: update stats for pages in dropped aux writeback list
  (bsc#1230130).
- fuse: use unsigned type for getxattr/listxattr size truncation
  (bsc#1230129).
- commit 32e32b0

- fuse: Initialize beyond-EOF page contents before setting
  uptodate (bsc#1229454 CVE-2024-44947).
- commit ddfd2d7

- Bluetooth: Fix usage of __hci_cmd_sync_status (git-fixes).
- commit 6d0732e

- efi/unaccepted: touch soft lockup during memory accept
  (bsc#1225773 CVE-2024-36936).
- commit 29d2eb8

- vdpa: ifcvf: Do proper cleanup if IFCVF init fails (bsc#1225524
  CVE-2022-48706).
- commit 023b108

- usb: vhci-hcd: Do not drop references before new references
  are gained (CVE-2024-43883 bsc#1229707).
- commit 44d7bae

- Bluetooth: L2CAP: Fix deadlock (git-fixes).
- commit 717d839

- swiotlb: fix swiotlb_bounce() to do partial sync's correctly
  (git-fixes).
- commit b02e597

- bluetooth/l2cap: sync sock recv cb and release (bsc#1228576
  CVE-2024-41062).
- commit 07bd1e3

- net: usb: qmi_wwan: fix memory leak for not ip packets
  (CVE-2024-43861 bsc#1229500).
- commit 3e796c3

- ocfs2: use coarse time for new created files (git-fixes).
- commit 82dc1eb

- drm/i915/gem: Fix Virtual Memory mapping boundaries calculation (bsc#1229156 CVE-2024-42259)
- commit acc20fb

- PKCS#7: Check codeSigning EKU of certificates in PKCS#7
  (bsc#1226666).
- commit c1bc9ca

- net: mana: Fix race of mana_hwc_post_rx_wqe and new hwc response (git-fixes).
- commit f65ae14

- xfs: Fix missing interval for missing_owner in xfs fsmap
  (git-fixes).
- commit 3005438

- xfs: use XFS_BUF_DADDR_NULL for daddrs in getfsmap code
  (git-fixes).
- commit b060763

- xfs: Fix the owner setting issue for rmap query in xfs fsmap
  (git-fixes).
- commit 264a4ea

- Update
  patches.suse/0001-net-rds-fix-possible-cp-null-dereference.patch
  (git-fixes CVE-2024-35902 bsc#1224496).
- Update
  patches.suse/ALSA-usb-audio-Fix-possible-NULL-pointer-dereference.patch
  (git-fixes CVE-2023-52904 bsc#1229529).
- Update
  patches.suse/ASoC-Intel-sof-nau8825-fix-module-alias-overflow.patch
  (git-fixes CVE-2022-48889 bsc#1229545).
- Update
  patches.suse/ASoC-amd-Adjust-error-handling-in-case-of-absent-cod.patch
  (git-fixes CVE-2024-43818 bsc#1229296).
- Update
  patches.suse/PCI-DPC-Fix-use-after-free-on-concurrent-DPC-and-hot.patch
  (git-fixes CVE-2024-42302 bsc#1229366).
- Update
  patches.suse/PCI-keystone-Fix-NULL-pointer-dereference-in-case-of.patch
  (git-fixes CVE-2024-43823 bsc#1229303).
- Update
  patches.suse/RDMA-hns-Fix-soft-lockup-under-heavy-CEQE-load.patch
  (git-fixes CVE-2024-43872 bsc#1229489).
- Update
  patches.suse/RDMA-iwcm-Fix-a-use-after-free-related-to-destroying.patch
  (git-fixes CVE-2024-42285 bsc#1229381).
- Update
  patches.suse/Revert-ALSA-firewire-lib-operate-for-period-elapse-e.patch
  (bsc#1208783 CVE-2024-42274 bsc#1229417).
- Update patches.suse/bpf-Add-schedule-points-in-batch-ops.patch
  (jsc#PED-1377 CVE-2022-48939 bsc#1229616).
- Update
  patches.suse/bpf-Fix-crash-due-to-incorrect-copy_map_value.patch
  (jsc#PED-1377 CVE-2022-48940 bsc#1229615).
- Update
  patches.suse/btrfs-prevent-copying-too-big-compressed-lzo-segment.patch
  (git-fixes CVE-2022-48923 bsc#1229662).
- Update
  patches.suse/devres-Fix-memory-leakage-caused-by-driver-API-devm_.patch
  (git-fixes CVE-2024-43871 bsc#1229490).
- Update
  patches.suse/dma-fix-call-order-in-dmam_free_coherent.patch
  (git-fixes CVE-2024-43856 bsc#1229346).
- Update
  patches.suse/drm-amd-display-Add-NULL-check-for-afb-before-derefe.patch
  (stable-fixes CVE-2024-43903 bsc#1229781).
- Update
  patches.suse/drm-amd-display-Skip-Recompute-DSC-Params-if-no-Stre.patch
  (stable-fixes CVE-2024-43895 bsc#1229755).
- Update
  patches.suse/drm-amd-pm-Fix-the-null-pointer-dereference-for-vega.patch
  (stable-fixes CVE-2024-43905 bsc#1229784).
- Update
  patches.suse/drm-amdgpu-Fix-potential-NULL-dereference.patch
  (bsc#1206843 CVE-2023-52908 bsc#1229525).
- Update
  patches.suse/drm-amdgpu-Fix-the-null-pointer-dereference-to-ras_m.patch
  (stable-fixes CVE-2024-43908 bsc#1229788).
- Update
  patches.suse/drm-amdgpu-Fixed-bug-on-error-when-unloading-amdgpu.patch
  (bsc#1206843 CVE-2023-52912 bsc#1229588).
- Update
  patches.suse/drm-amdgpu-pm-Fix-the-null-pointer-dereference-for-s.patch
  (stable-fixes CVE-2024-43909 bsc#1229789).
- Update
  patches.suse/drm-amdgpu-pm-Fix-the-null-pointer-dereference-in-ap.patch
  (stable-fixes CVE-2024-43907 bsc#1229787).
- Update
  patches.suse/drm-client-fix-null-pointer-dereference-in-drm_clien.patch
  (git-fixes CVE-2024-43894 bsc#1229746).
- Update
  patches.suse/drm-gma500-fix-null-pointer-dereference-in-cdv_intel.patch
  (git-fixes CVE-2024-42310 bsc#1229358).
- Update
  patches.suse/drm-gma500-fix-null-pointer-dereference-in-psb_intel.patch
  (git-fixes CVE-2024-42309 bsc#1229359).
- Update patches.suse/drm-i915-Fix-potential-context-UAFs.patch
  (git-fixes CVE-2023-52913 bsc#1229521).
- Update
  patches.suse/drm-i915-gt-Cleanup-partial-engine-discovery-failure.patch
  (git-fixes CVE-2022-48893 bsc#1229576).
- Update
  patches.suse/drm-msm-dpu-Fix-memory-leak-in-msm_mdss_parse_data_b.patch
  (git-fixes CVE-2022-48888 bsc#1229546).
- Update
  patches.suse/drm-nouveau-prime-fix-refcount-underflow.patch
  (git-fixes CVE-2024-43867 bsc#1229493).
- Update patches.suse/drm-qxl-Add-check-for-drm_cvt_mode.patch
  (git-fixes CVE-2024-43829 bsc#1229341).
- Update
  patches.suse/drm-vmwgfx-Fix-a-deadlock-in-dma-buf-fence-polling.patch
  (git-fixes CVE-2024-43863 bsc#1229497).
- Update
  patches.suse/drm-vmwgfx-Remove-rcu-locks-from-user-resources.patch
  (bsc#1203329 CVE-2022-40133 bsc#1203330 CVE-2022-38457
  bsc#1213632 CVE-2022-48887 bsc#1229547).
- Update
  patches.suse/drop_monitor-replace-spin_lock-by-raw_spin_lock.patch
  (References: CVE-2021-47546 bsc#1227937 CVE-2024-40980).
- Update
  patches.suse/exfat-fix-potential-deadlock-on-__exfat_get_dentry_set.patch
  (git-fixes CVE-2024-42315 bsc#1229354).
- Update
  patches.suse/genirq-cpuhotplug-x86-vector-Prevent-vector-leak-dur.patch
  (git-fixes CVE-2024-31076 bsc#1226765).
- Update
  patches.suse/hfs-fix-to-initialize-fields-of-hfs_inode_info-after-hfs_alloc_inode.patch
  (git-fixes CVE-2024-42311 bsc#1229413).
- Update patches.suse/ice-Add-check-for-kzalloc.patch (jsc#PED-376
  CVE-2022-48886 bsc#1229548).
- Update
  patches.suse/ice-Fix-potential-memory-leak-in-ice_gnss_tty_write.patch
  (jsc#PED-376 CVE-2022-48885 bsc#1229564).
- Update
  patches.suse/iommu-iova-Fix-alloc-iova-overflows-issue.patch
  (git-fixes CVE-2023-52910 bsc#1229523).
- Update
  patches.suse/jfs-Fix-array-index-out-of-bounds-in-diFree.patch
  (git-fixes CVE-2024-43858 bsc#1229414).
- Update
  patches.suse/kobject_uevent-Fix-OOB-access-within-zap_modalias_en.patch
  (git-fixes CVE-2024-42292 bsc#1229373).
- Update
  patches.suse/leds-trigger-Unregister-sysfs-attributes-before-call.patch
  (git-fixes CVE-2024-43830 bsc#1229305).
- Update
  patches.suse/lib-objagg-Fix-general-protection-fault.patch
  (git-fixes CVE-2024-43846 bsc#1229360).
- Update
  patches.suse/media-venus-fix-use-after-free-in-vdec_close.patch
  (git-fixes CVE-2024-42313 bsc#1229356).
- Update
  patches.suse/memcg-protect-concurrent-access-to-mem_cgroup_idr.patch
  (git-fixes CVE-2024-43892 bsc#1229761).
- Update
  patches.suse/net-ipv6-ensure-we-call-ipv6_mc_down-at-most-once.patch
  (git-fixes CVE-2022-48910 bsc#1229632).
- Update
  patches.suse/net-ks8851-Fix-deadlock-with-the-SPI-chip-variant.patch
  (git-fixes CVE-2024-41036 bsc#1228496).
- Update
  patches.suse/net-ks8851-Queue-RX-packets-in-IRQ-handler-instead-o.patch
  (CVE-2024-35971 bsc#1224578 CVE-2024-36962 bsc#1225827).
- Update
  patches.suse/net-mlx5-Fix-command-stats-access-after-free.patch
  (jsc#PED-1549 CVE-2022-48884 bsc#1229562).
- Update
  patches.suse/net-mlx5e-Fix-macsec-possible-null-dereference-when-.patch
  (jsc#PED-1549 CVE-2022-48882 bsc#1229558).
- Update
  patches.suse/net-mlx5e-IPoIB-Block-PKEY-interfaces-with-less-rx-q.patch
  (jsc#PED-1549 CVE-2022-48883 bsc#1229560).
- Update
  patches.suse/net-usb-qmi_wwan-fix-memory-leak-for-not-ip-packets.patch
  (git-fixes CVE-2024-43861 bsc#1229500).
- Update
  patches.suse/nfsd-fix-handling-of-cached-open-files-in-nfsd4_open.patch
  (git-fixes CVE-2023-52909 bsc#1229524).
- Update
  patches.suse/nvme-pci-add-missing-condition-check-for-existence-o.patch
  (git-fixes CVE-2024-42276 bsc#1229410).
- Update
  patches.suse/padata-Fix-possible-divide-by-0-panic-in-padata_mt_h.patch
  (git-fixes CVE-2024-43889 bsc#1229743).
- Update
  patches.suse/platform-x86-amd-Fix-refcount-leak-in-amd_pmc_probe.patch
  (bsc#1210644 CVE-2022-48881 bsc#1229559).
- Update
  patches.suse/powerpc-pseries-Whitelist-dtl-slub-object-for-copyin.patch
  (bsc#1194869 CVE-2024-41065 bsc#1228636).
- Update
  patches.suse/s390-dasd-fix-error-checks-in-dasd_copy_pair_store.patch
  (git-fixes bsc#1229190 CVE-2024-42320 bsc#1229349).
- Update
  patches.suse/scsi-lpfc-Revise-lpfc_prep_embed_io-routine-with-pro.patch
  (bsc#1228857 CVE-2024-43816 bsc#1229318).
- Update
  patches.suse/scsi-qla2xxx-Complete-command-early-within-lock.patch
  (bsc#1228850 CVE-2024-42287 bsc#1229392).
- Update
  patches.suse/scsi-qla2xxx-During-vport-delete-send-async-logout-e.patch
  (bsc#1228850 CVE-2024-42289 bsc#1229399).
- Update
  patches.suse/scsi-qla2xxx-Fix-for-possible-memory-corruption.patch
  (bsc#1228850 CVE-2024-42288 bsc#1229398).
- Update
  patches.suse/scsi-qla2xxx-validate-nvme_local_port-correctly.patch
  (bsc#1228850 CVE-2024-42286 bsc#1229395).
- Update
  patches.suse/wifi-cfg80211-handle-2x996-RU-allocation-in-cfg80211.patch
  (git-fixes CVE-2024-43879 bsc#1229482).
- Update
  patches.suse/wifi-rtw89-Fix-array-index-mistake-in-rtw89_sta_info.patch
  (git-fixes CVE-2024-43842 bsc#1229317).
- commit 777a4e3

- Update
  patches.suse/ASoC-ops-Shift-tested-values-in-snd_soc_put_volsw-by.patch
  (git-fixes CVE-2022-48917 bsc#1229637).
- Update
  patches.suse/Bluetooth-hci_qca-Fix-driver-shutdown-on-closed-serd.patch
  (git-fixes CVE-2022-48878 bsc#1229554).
- Update
  patches.suse/CDC-NCM-avoid-overflow-in-sanity-checking.patch
  (git-fixes CVE-2022-48938 bsc#1229664).
- Update
  patches.suse/KVM-x86-mmu-make-apf-token-non-zero-to-fix-bug.patch
  (git-fixes CVE-2022-48943 bsc#1229645).
- Update
  patches.suse/RDMA-cma-Do-not-change-route.addr.src_addr-outside-s.patch
  (git-fixes CVE-2022-48925 bsc#1229630).
- Update patches.suse/RDMA-ib_srp-Fix-a-deadlock.patch (git-fixes
  CVE-2022-48930 bsc#1229624).
- Update
  patches.suse/USB-gadgetfs-Fix-race-between-mounting-and-unmountin.patch
  (CVE-2022-4382 bsc#1206258 CVE-2022-48869 bsc#1229507).
- Update
  patches.suse/auxdisplay-lcd2s-Fix-memory-leak-in-remove.patch
  (git-fixes CVE-2022-48907 bsc#1229608).
- Update
  patches.suse/blktrace-fix-use-after-free-for-struct-blk_trace.patch
  (bsc#1198017 CVE-2022-48913 bsc#1229643).
- Update
  patches.suse/bpf-Fix-crash-due-to-out-of-bounds-access-into-reg2b.patch
  (git-fixes bsc#1194111 bsc#1194765 bsc#1196261 CVE-2021-4204
  CVE-2022-0500 CVE-2022-23222 CVE-2022-48929 bsc#1229625).
- Update
  patches.suse/btrfs-fix-race-between-quota-rescan-and-disable-lead.patch
  (bsc#1207158 CVE-2023-52896 bsc#1229533).
- Update
  patches.suse/btrfs-fix-relocation-crash-due-to-premature-return-f.patch
  (bsc#1203360 CVE-2022-48903 bsc#1229613).
- Update
  patches.suse/cgroup-cpuset-Prevent-UAF-in-proc_cpuset_show.patch
  (bsc#1228801 CVE-2024-43853 bsc#1229292).
- Update
  patches.suse/cifs-fix-double-free-race-when-mount-fails-in-cifs_get_root-.patch
  (bsc#1193629 CVE-2022-48919 bsc#1229657).
- Update
  patches.suse/configfs-fix-a-race-in-configfs_-un-register_subsyst.patch
  (git-fixes CVE-2022-48931 bsc#1229623).
- Update
  patches.suse/dmaengine-idxd-Let-probe-fail-when-workqueue-cannot-.patch
  (git-fixes CVE-2022-48868 bsc#1229506).
- Update
  patches.suse/drm-msm-another-fix-for-the-headless-Adreno-GPU.patch
  (git-fixes CVE-2023-52911 bsc#1229522).
- Update
  patches.suse/drm-msm-dp-do-not-complete-dp_aux_cmd_fifo_tx-if-irq.patch
  (git-fixes CVE-2022-48898 bsc#1229537).
- Update patches.suse/drm-virtio-Fix-GEM-handle-creation-UAF.patch
  (git-fixes CVE-2022-48899 bsc#1229536).
- Update
  patches.suse/gsmi-fix-null-deref-in-gsmi_get_variable.patch
  (git-fixes CVE-2023-52893 bsc#1229535).
- Update
  patches.suse/hwmon-Handle-failure-to-register-sensor-with-thermal.patch
  (git-fixes CVE-2022-48942 bsc#1229612).
- Update
  patches.suse/ibmvnic-free-reset-work-item-when-flushing.patch
  (bsc#1196516 ltc#196391 CVE-2022-48905 bsc#1229604).
- Update
  patches.suse/ice-fix-concurrent-reset-and-removal-of-VFs.patch
  (git-fixes CVE-2022-48941 bsc#1229614).
- Update
  patches.suse/iio-adc-men_z188_adc-Fix-a-resource-leak-in-an-error.patch
  (git-fixes CVE-2022-48928 bsc#1229626).
- Update
  patches.suse/iio-adc-tsc2046-fix-memory-corruption-by-preventing-.patch
  (git-fixes CVE-2022-48927 bsc#1229628).
- Update
  patches.suse/io_uring-add-a-schedule-point-in-io_add_buffers.patch
  (git-fixes CVE-2022-48937 bsc#1229617).
- Update patches.suse/iommu-amd-Fix-I-O-page-table-memory-leak
  (git-fixes CVE-2022-48904 bsc#1229603).
- Update
  patches.suse/iommu-vt-d-fix-double-list_add-when-enabling-vmd-in-scalable-mode
  (bsc#1196894 CVE-2022-48916 bsc#1229638).
- Update
  patches.suse/iwlwifi-mvm-check-debugfs_dir-ptr-before-use.patch
  (git-fixes CVE-2022-48918 bsc#1229636).
- Update patches.suse/ixgbe-fix-pci-device-refcount-leak.patch
  (jsc#SLE-18384 CVE-2022-48896 bsc#1229540).
- Update
  patches.suse/misc-fastrpc-Don-t-remove-map-on-creater_process-and.patch
  (git-fixes CVE-2022-48873 bsc#1229512).
- Update
  patches.suse/misc-fastrpc-Fix-use-after-free-race-condition-for-m.patch
  (git-fixes CVE-2022-48872 bsc#1229510).
- Update
  patches.suse/net-mlx5-DR-Fix-slab-out-of-bounds-in-mlx5_cmd_dr_cr.patch
  (jsc#SLE-19253 CVE-2022-48932 bsc#1229622).
- Update patches.suse/net-smc-fix-connection-leak (git-fixes
  CVE-2022-48909 bsc#1229611).
- Update
  patches.suse/nfc-pn533-Wait-for-out_urb-s-completion-in-pn533_usb.patch
  (git-fixes CVE-2023-52907 bsc#1229526).
- Update
  patches.suse/nfp-flower-Fix-a-potential-leak-in-nfp_tunnel_add_sh.patch
  (git-fixes CVE-2022-48934 bsc#1229620).
- Update
  patches.suse/nilfs2-fix-general-protection-fault-in-nilfs_btree_i.patch
  (git-fixes CVE-2023-52900 bsc#1229581).
- Update
  patches.suse/octeontx2-pf-Fix-resource-leakage-in-VF-driver-unbin.patch
  (git-fixes CVE-2023-52905 bsc#1229528).
- Update
  patches.suse/platform-surface-aggregator-Add-missing-call-to-ssam.patch
  (git-fixes CVE-2022-48880 bsc#1229557).
- Update
  patches.suse/regulator-da9211-Use-irq-handler-when-ready.patch
  (git-fixes CVE-2022-48891 bsc#1229565).
- Update
  patches.suse/sched-fair-Fix-fault-in-reweight_entity.patch
  (git fixes (sched/core) CVE-2022-48921 bsc#1229635).
- Update
  patches.suse/scsi-storvsc-Fix-swiotlb-bounce-buffer-leak-in-confi.patch
  (bsc#1206006 CVE-2022-48890 bsc#1229544).
- Update
  patches.suse/spi-spi-zynq-qspi-Fix-a-NULL-pointer-dereference-in-.patch
  (git-fixes CVE-2021-4441 bsc#1229598).
- Update
  patches.suse/thermal-core-Fix-TZ_GET_TRIP-NULL-pointer-dereferenc.patch
  (git-fixes CVE-2022-48915 bsc#1229639).
- Update
  patches.suse/thermal-int340x-fix-memory-leak-in-int3400_notify.patch
  (git-fixes CVE-2022-48924 bsc#1229631).
- Update
  patches.suse/tty-fix-possible-null-ptr-defer-in-spk_ttyio_release.patch
  (git-fixes CVE-2022-48870 bsc#1229508).
- Update
  patches.suse/tty-serial-qcom-geni-serial-fix-slab-out-of-bounds-o.patch
  (git-fixes CVE-2022-48871 bsc#1229509).
- Update
  patches.suse/usb-gadget-f_ncm-fix-potential-NULL-ptr-deref-in-ncm.patch
  (git-fixes CVE-2023-52894 bsc#1229566).
- Update
  patches.suse/usb-gadget-rndis-add-spinlock-for-rndis-response-lis.patch
  (git-fixes CVE-2022-48926 bsc#1229629).
- Update
  patches.suse/usb-xhci-Check-endpoint-is-valid-before-dereferencin.patch
  (git-fixes CVE-2023-52901 bsc#1229531).
- Update
  patches.suse/wifi-mac80211-sdata-can-be-NULL-during-AMPDU-start.patch
  (git-fixes CVE-2022-48875 bsc#1229516).
- Update
  patches.suse/xen-netfront-destroy-queues-before-real_num_tx_queue.patch
  (git-fixes CVE-2022-48914 bsc#1229642).
- Update
  patches.suse/xhci-Fix-null-pointer-dereference-when-host-dies.patch
  (git-fixes CVE-2023-52898 bsc#1229568).
- commit 5c5e4d7

- Fix reference in patches.suse/netfilter-tproxy-bail-out-if-IP-has-been-disabled-on.patch (CVE-2024-36270 bsc#1226798)
- commit 7d81a29

- iommu/amd: Convert comma to semicolon (git-fixes).
- commit f13afd4

- mm: prevent derefencing NULL ptr in pfn_section_valid()
  (git-fixes).
- commit d77caa1

- mm, kmsan: fix infinite recursion due to RCU critical section
  (git-fixes).
- commit 1702784

- mm/sparsemem: fix race in accessing memory_section-&amp;gt;usage
  (bsc#1221326 CVE-2023-52489).
- commit 606bd9b

- drm/amd/display: avoid using null object of framebuffer
  (git-fixes).
- nfc: pn533: Add poll mod list filling check (git-fixes).
- wifi: iwlwifi: fw: fix wgds rev 3 exact size (git-fixes).
- wifi: mwifiex: duplicate static structs used in driver instances
  (git-fixes).
- Bluetooth: hci_core: Fix not handling hibernation actions
  (git-fixes).
- drm/amdgpu: Validate TA binary size (stable-fixes).
- ALSA: usb-audio: Support Yamaha P-125 quirk entry
  (stable-fixes).
- ALSA: usb-audio: Add delay quirk for VIVO USB-C-XE710 HEADSET
  (stable-fixes).
- drm/amdgpu: Actually check flags for all context ops
  (stable-fixes).
- drm/amdgpu/jpeg2: properly set atomics vmid field
  (stable-fixes).
- ALSA: usb: Fix UBSAN warning in parse_audio_unit()
  (stable-fixes).
- drm/amdgpu: fix dereference null return value for the function
  amdgpu_vm_pt_parent (stable-fixes).
- drm/lima: set gp bus_stop bit before hard reset (stable-fixes).
- Revert &amp;quot;drm/amd/display: Validate hw_points_num before using it&amp;quot;
  (stable-fixes).
- drm/amd/display: Validate hw_points_num before using it
  (stable-fixes).
- drm/amd/amdgpu/imu_v11_0: Increase buffer size to ensure all
  possible values can be stored (stable-fixes).
- drm/tegra: Zero-initialize iosys_map (stable-fixes).
- drm/bridge: tc358768: Attempt to fix DSI horizontal timings
  (stable-fixes).
- commit 91b4876

- serial: core: check uartclk for zero to avoid divide by zero
  (bsc#1229759 CVE-2024-43893).
- commit d3f6894

- scsi: lpfc: Fix a possible null pointer dereference (bsc#1229315
  CVE-2024-43821).
- commit e13b213

- syscalls: fix compat_sys_io_pgetevents_time64 usage (git-fixes).
- commit 427ff01

- tracing: Return from tracing_buffers_read() if the file has
  been closed (bsc#1229136 git-fixes).
- commit 6961c54

- kprobes: Fix to check symbol prefixes correctly (git-fixes).
- commit 9927afc

- bpf: kprobe: remove unused declaring of bpf_kprobe_override
  (git-fixes).
- commit ff5617f

- media: xc2028: avoid use-after-free in load_firmware_cb()
  (CVE-2024-43900 bsc#1229756).
- commit c954239

- jfs: Fix shift-out-of-bounds in dbDiscardAG (bsc#1229792
  CVE-2024-44938).
- commit 8003b7e

- jfs: fix null ptr deref in dtInsertEntry (bsc#1229820
  CVE-2024-44939).
- commit 02ccaa1

- ata: libata-core: Fix double free on error
  (CVE-2024-41087,bsc#1228466).
- commit b5892ca

- iommu: sprd: Avoid NULL deref in sprd_iommu_hw_en
  (CVE-2024-42277 bsc#1229409).
- commit a4daba4

- drm/amd/display: Add null checker before passing variables (CVE-2024-43902 bsc#1229767).
- commit d450d98

- drm/amd/display: Add null checks for 'stream' and 'plane' before dereferencing (CVE-2024-43904 bsc#1229768)
- commit c2331c0

- kabi: lib: objagg: Put back removed metod in struct objagg_ops
  (CVE-2024-43880 bsc#1229481).
- ip6_tunnel: Fix broken GRO (bsc#1229444).
- commit 2e1b5f5

- Bluetooth: MGMT: Add error handling to pair_device() (CVE-2024-43884 bsc#1229739)
- commit ca65d0a

- net/sched: initialize noop_qdisc owner (git-fixes).
- commit 32a510a

- drm/amd/display: Fix null pointer deref in dcn20_resource.c (CVE-2024-43899 bsc#1229754).
- commit 13ec104

- btrfs: get rid of warning on transaction commit when using
  flushoncommit (bsc#1229658 CVE-2022-48920).
- commit a558155

- net/sched: act_mpls: Fix warning during failed attribute
  validation (CVE-2023-52906 bsc#1229527).
- commit 5be67dc

- exec: Fix ToCToU between perm check and set-uid/gid usage
  (CVE-2024-43882 bsc#1229503).
- commit 83a7456

- net/mlx5: Always drain health in shutdown callback
  (CVE-2024-43866 bsc#1229495).
- mlxsw: spectrum_acl_erp: Fix object nesting warning
  (CVE-2024-43880 bsc#1229481).
- commit f5f318d

- kABI: vfio: struct virqfd kABI workaround (CVE-2024-26812
  bsc#1222808).
- vfio/pci: fix potential memory leak in vfio_intx_enable()
  (git-fixes).
- commit 5a53e2c

- netfilter: nf_tables: unregister flowtable hooks on netns exit (CVE-2022-48935 bsc#1229619)
- commit 3e33f70

- vfio: Introduce interface to flush virqfd inject workqueue
  (bsc#1222808 CVE-2024-26812).
- commit 31be414

- netfilter: fix use-after-free in __nf_register_net_hook() (CVE-2022-48912 bsc#1229641)
- commit f8f42c3

- vfio/pci: Create persistent INTx handler (bsc#1222808
  CVE-2024-26812).
- commit 9d86cff

- net/sched: Fix mirred deadlock on device recursion
  (CVE-2024-27010 bsc#1223720).
- commit 4342cf9

- mptcp: Correctly set DATA_FIN timeout when number of retransmits is large (CVE-2022-48906 bsc#1229605)
- commit a7a3da6

- net: qdisc: preserve kabi for struct QDisc (CVE-2024-27010 bsc#1223720).
- commit af12745

- s390/pkey: Wipe copies of protected- and secure-keys
  (CVE-2024-42155 bsc#1228733).
- commit 78df5c8

- Reapply &amp;quot;drm/vc4: hdmi: Enforce the minimum rate at
  This reverts commit 048f829d4b52520058c31bae2ef1ec08563c460a.
- commit 5126762

- s390/pkey: Wipe copies of clear-key structures on failure
  (CVE-2024-42156 bsc#1228722).
- commit b3fe404

- Add exception protection processing for vd in
  axi_chan_handle_err function (CVE-2023-52899 bsc#1229569).
- commit 510675c

- rpm/check-for-config-changes: Exclude ARCH_USING_PATCHABLE_FUNCTION_ENTRY
  gcc version dependent, at least on ppc
- commit 16da158

- s390/pkey: Use kfree_sensitive() to fix Coccinelle warnings
  (CVE-2024-42158 bsc#1228720).
- commit ccfe5a9

- af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg
  (bsc#1226846 CVE-2024-38596).
- Update
  patches.suse/af_unix-Fix-data-races-around-sk-sk_shutdown.patch
  (git-fixes bsc#1226846).
- commit 297df1b

- ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work
  (CVE-2024-26631 bsc#1221630).
- commit f41507c

- vhost/vsock: always initialize seqpacket_allow (CVE-2024-43873 bsc#1229488)
- commit d4e35ee

- ipv6: fix possible race in __fib6_drop_pcpu_from() (CVE-2024-40905 bsc#1227761)
- commit 91482e3

- ipv6: sr: fix memleak in seg6_hmac_init_algo (CVE-2024-39489 bsc#1227623)
- commit 9ac27bb

- netfilter: nf_tables: fix use-after-free in nft_set_catchall_destroy() (CVE-2021-47106 bsc#1220962)
- commit e6e6065

- drivers: ethernet: cpsw: fix panic when interrupt coaleceing
  is set via ethtool (CVE-2021-47517 bsc#1225428).
- commit f131073

- ethtool: do not perform operations on net devices being
  unregistered (CVE-2021-47517 bsc#1225428).
- ethtool: return error from ethnl_ops_begin if dev is NULL
  (CVE-2021-47517 bsc#1225428).
- ethtool: runtime-resume netdev parent in ethnl_ops_begin
  (CVE-2021-47517 bsc#1225428).
- ethtool: move netif_device_present check from
  ethnl_parse_header_dev_get to ethnl_ops_begin (CVE-2021-47517
  bsc#1225428).
- ethtool: move implementation of ethnl_ops_begin/complete to
  netlink.c (CVE-2021-47517 bsc#1225428).
- commit 2e58867

- tls: fix missing memory barrier in tls_init (CVE-2024-36489 bsc#1226874)
- commit 134cc98

- exfat: fix potential deadlock on __exfat_get_dentry_set
  (git-fixes).
- commit 2294924

- afs: Don't cross .backup mountpoint from backup volume
  (git-fixes).
- commit b94ac2d

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

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

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

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

- exfat: fix inode-&amp;gt;i_blocks for non-512 byte sector size device
  (git-fixes).
- commit a3a46dd

- exfat: redefine DIR_DELETED as the bad cluster number
  (git-fixes).
- commit 52b33f6

- exfat: support dynamic allocate bh for exfat_entry_set_cache
  (git-fixes).
- commit dd685aa

- nilfs2: Remove check for PageError (git-fixes).
- commit cd97d8f

- drop_monitor: replace spin_lock by raw_spin_lock (References:
  CVE-2021-47546 bsc#1227937).
- commit dd4f366

- RDMA/mana_ib: Use virtual address in dma regions for MRs (git-fixes).
- commit b7df97b

- drm/msm/dpu: cleanup FB if dpu_format_populate_layout fails
  (git-fixes).
- drm/msm/dp: reset the link phy params before link training
  (git-fixes).
- drm/msm/dpu: don't play tricks with debug macros (git-fixes).
- mmc: mmc_test: Fix NULL dereference on allocation failure
  (git-fixes).
- mmc: dw_mmc: allow biu and ciu clocks to defer (git-fixes).
- commit 0a0202d

- supported.conf: Sort with tool
  No functional change intended
- commit 4d22f17

- filelock: Fix fcntl/close race recovery compat path (bsc#1228427
  CVE-2024-41020).
- commit 31787dd

- supported.conf: Fix comment placement.
  We have a script for automated sorting of this file.
  However, it can only work with comments that are placed together with
  the module name on the same line, not with comments on their own line.
- commit d1c37d4

- iommu/vt-d: Fix NULL domain on device release (bsc#1223742
  CVE-2024-27079).
- commit 6daa607

- netfilter: nf_tables: discard table flag update with pending
  basechain deletion (CVE-2024-35897 bsc#1224510).
- netfilter: nf_tables: reject table flag and netdev basechain
  updates (CVE-2024-35897 bsc#1224510).
- netfilter: nf_tables: disable toggling dormant table state
  more than once (CVE-2024-35897 bsc#1224510).
- commit c138803

- kabi: restore const specifier in flow_offload_route_init()
  (CVE-2024-27403 bsc#1224415).
- netfilter: nft_flow_offload: reset dst in route object after
  setting up flow (CVE-2024-27403 bsc#1224415).
- commit 15b1876

- netfilter: nf_tables: fix memleak in map from abort path
  (CVE-2024-27011 bsc#1223803).
- commit 081f6b0

- bpf: Fix a kernel verifier crash in stacksafe() (bsc#1225903).
- commit 4e175b8

- kvm: s390: Reject memory region operations for ucontrol VMs
  (CVE-2024-43819 bsc#1229290 git-fixes).
- commit 4b042b0

- netfilter: nft_limit: reject configurations that cause integer
  overflow (CVE-2024-26668 bsc#1222335).
- commit 7074520

- netfilter: nf_tables: set dormant flag on hook register failure
  (CVE-2024-26835 bsc#1222967).
- commit 5731bf5

- netfilter: nft_chain_filter: handle NETDEV_UNREGISTER for
  inet/ingress basechain (CVE-2024-26808 bsc#1222634).
- commit 3f2b4eb

- kabi: hide include of ppp files from genksyms (CVE-2024-27016
  bsc#1223807).
- commit db3abd4

- net: phy: phy_device: Prevent nullptr exceptions on ISR
  (CVE-2024-35945 bsc#1224639).
- net: phy: allow a phy to opt-out of interrupt handling
  (CVE-2024-35945 bsc#1224639).
- net: phy: Deduplicate interrupt disablement on PHY attach
  (CVE-2024-35945 bsc#1224639).
- commit 2a46e5f

- netfilter: nf_tables: fix memleak when more than 255 elements
  expired (CVE-2023-52581 bsc#1220877).
- commit f901f47

- netfilter: flowtable: validate pppoe header (CVE-2024-27016
  bsc#1223807).
- commit ad249c6

- netfilter: flowtable: Fix QinQ and pppoe support for inet table
  (CVE-2024-27016 bsc#1223807).
- commit 0b940a3

- Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_connect()
  (bsc#1225578 CVE-2024-36013).
- commit 11d3282

- bpf: Fix updating attached freplace prog in prog_array map
  (bsc#1229297 CVE-2024-43837).
- commit 886bbe9

- ice: Add a per-VF limit on number of FDIR filters
  (CVE-2024-42291 bsc#1229374).
- commit 99e9416

- net/mlx5: Fix missing lock on sync reset reload (CVE-2024-42268
  bsc#1229391).
- commit 230ddc2

- xdp: fix invalid wait context of page_pool_destroy() (CVE-2024-43834 bsc#1229314)
- commit 4c196fd

- netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu() (CVE-2024-36286 bsc#1226801)
- commit 52bf670

- netfilter: tproxy: bail out if IP has been disabled on the device (CVE-2024-36270 1226798)
- commit 3e4f173

- netfilter: nf_conntrack_h323: Add protection for bmp length out of range (CVE-2024-26851 bsc#1223074)
- commit ff5170b

- s390/pkey: Wipe sensitive data on failure (bsc#1228727
  CVE-2024-42157 git-fixes).
- commit bfb03ba

- s390/dasd: fix error recovery leading to data corruption on
  ESE devices (git-fixes bsc#1229573).
- commit 5bbca6e

- s390/sclp: Prevent release of buffer in I/O (git-fixes
  bsc#1229572).
- commit de7864e

- perf: hisi: Fix use-after-free when register pmu fails
  (bsc#1225582 CVE-2023-52859).
- commit 256d260

- selftests/bpf: Test for null-pointer-deref bugfix in
  resolve_prog_type() (bsc#1229297 CVE-2024-43837).
- bpf: Fix null pointer dereference in resolve_prog_type()
  for BPF_PROG_TYPE_EXT (bsc#1229297 CVE-2024-43837).
- commit aa78187

- ceph: periodically flush the cap releases (bsc#1225162).
- ceph: issue a cap release immediately if no cap exists
  (bsc#1225162).
- commit 3fe7ed5

- arm64: cpufeature: Fix the visibility of compat hwcaps (git-fixes)
- commit 03a8502

- arm64: cpufeature: Add missing .field_width for GIC system registers (git-fixes)
- commit af4907d

- nfsd: return error if nfs4_setacl fails (git-fixes).
- NFSD: fix regression with setting ACLs (git-fixes).
- commit 7de02e0

- SUNRPC: Fix a race to wake a sync task (git-fixes).
- xprtrdma: Fix rpcrdma_reqs_reset() (git-fixes).
- gss_krb5: Fix the error handling path for
  crypto_sync_skcipher_setkey (git-fixes).
- nfs: make the rpc_stat per net namespace (git-fixes).
- nfs: expose /proc/net/sunrpc/nfs in net namespaces (git-fixes).
- sunrpc: add a struct rpc_stats arg to rpc_create_args
  (git-fixes).
- nfsd: use locks_inode_context helper (git-fixes).
- NFSD: Increase NFSD_MAX_OPS_PER_COMPOUND (git-fixes).
- lockd: move from strlcpy with unused retval to strscpy
  (git-fixes).
- NFSD: move from strlcpy with unused retval to strscpy
  (git-fixes).
- NFSD: add posix ACLs to struct nfsd_attrs (git-fixes).
- NFSD: add security label to struct nfsd_attrs (git-fixes).
- NFSD: set attributes when creating symlinks (git-fixes).
- NFSD: introduce struct nfsd_attrs (git-fixes).
- NFSD: Fix strncpy() fortify warning (git-fixes).
- NFSD: Optimize DRC bucket pruning (git-fixes).
- commit 7da24f6

- mISDN: Fix a use after free in hfcmulti_tx() (CVE-2024-42280 bsc#1229388)
- commit 82fce1f

- tipc: Return non-zero value from tipc_udp_addr2str() on error (CVE-2024-42284 bsc#1229382)
- commit 7943dda

- net: nexthop: Initialize all fields in dumped nexthops (CVE-2024-42283 bsc#1229383)
- commit 2f1fd70

- sysctl: always initialize i_uid/i_gid (CVE-2024-42312 bsc#1229357)
- commit 3e19d8c

- block: initialize integrity buffer to zero before writing it to media (CVE-2024-43854 bsc#1229345)
- commit 51cef10

- net: remove two BUG() from skb_checksum_help() (bsc#1229312).
- commit 87f8b26

- ipvs: properly dereference pe in ip_vs_add_service (CVE-2024-42322 bsc#1229347)
- commit fa634c1

- Update DRM patch reference (CVE-2024-42308 bsc#1229411)
- commit c8788c0

- dev/parport: fix the array out-of-bounds risk (CVE-2024-42301
  bsc#1229407).
- commit 0f7f361

- arm64: cpufeature: Always specify and use a field width for capabilities (git-fixes)
  Refresh patches.suse/arm64-cpufeature-Fix-field-sign-for-DIT-hwcap-detection.patch.
  Refresh patches.suse/arm64-cpufeature-Force-HWCAP-to-be-based-on-the-sysreg-visible-to-user-space.patch.
- commit 8d157b0

- xhci: Fix Panther point NULL pointer deref at full-speed
  re-enumeration (git-fixes).
- commit 817012e

- Revert &amp;quot;usb: typec: tcpm: clear pd_event queue in PORT_RESET&amp;quot;
  (git-fixes).
- commit 8e189b9

- landlock: Don't lose track of restrictions on cred_transfer
  (bsc#1229351 CVE-2024-42318).
- commit a85e801

- kABI fix for net/sched: flower: Fix chain template offload
  (CVE-2024-26669 bsc#1222350).
- commit a7d20d9

- apparmor: Fix null pointer deref when receiving skb during sock creation (bsc#1229287, CVE-2023-52889).
- commit 9ffdd2d

- arm64: Fix KASAN random tag seed initialization (git-fixes)
- commit 828e8df

- net: enetc: move enetc_set_psfp() out of the common
  enetc_set_features() (CVE-2022-48645 bsc#1223508).
- commit 995bd04

- tcp: use signed arithmetic in tcp_rtx_probe0_timed_out()
  (CVE-2024-41007 bsc#1227863).
- commit 7e08cca

- net: tcp: fix unexcepted socket die when snd_wnd is 0
  (CVE-2024-41007 bsc#1227863).
- commit 226da79

- net: nsh: Use correct mac_offset to unwind gso skb in
  nsh_gso_segment() (CVE-2024-36933 bsc#1225832).
- commit a887eae

- nilfs2: handle inconsistent state in nilfs_btnode_create_block()
  (bsc#1229370 CVE-2024-42295).
- commit 765d56f

- arm64: ACPI: NUMA: initialize all values of acpi_early_node_map to (git-fixes)
- commit ac167d3

- arm64: errata: Expand speculative SSBS workaround (again) (git-fixes)
- commit 245f980

- arm64: cputype: Add Cortex-A725 definitions (git-fixes)
- commit eabaf05

- arm64: cputype: Add Cortex-X1C definitions (git-fixes)
- commit a2d18fc

- arm64: errata: Expand speculative SSBS workaround (git-fixes)
- commit dabff04

- arm64: errata: Unify speculative SSBS errata logic (git-fixes)
  Also update default configuration.
- commit c115971

- arm64: cputype: Add Cortex-X925 definitions (git-fixes)
- commit 9e86d7f

- arm64: cputype: Add Cortex-A720 definitions (git-fixes)
- commit cca3066

- arm64: cputype: Add Cortex-X3 definitions (git-fixes)
- commit b5d9595

- arm64: errata: Add workaround for Arm errata 3194386 and 3312417 (git-fixes)
  Refresh capability reservation patch and enable workarounds.
- commit f1638b8

- arm64: cputype: Add Neoverse-V3 definitions (git-fixes)
- commit 5592cab

- arm64: cputype: Add Cortex-X4 definitions (git-fixes)
- commit e63daa2

- arm64: barrier: Restore spec_bar() macro (git-fixes)
- commit 525b096

- arm64: Add Neoverse-V2 part (git-fixes)
- commit 9d204de

- arm64: cpufeature: Force HWCAP to be based on the sysreg visible to (git-fixes)
- commit ed48e5e

- mailbox: mtk-cmdq: Move devm_mbox_controller_register() after
  devm_pm_runtime_enable() (CVE-2024-42319 bsc#1229350).
- commit 7de6296

- remoteproc: imx_rproc: Skip over memory region when node value
  is NULL (CVE-2024-43860 bsc#1229319).
- commit eb0027b

- arm64: dts: rockchip: Increase VOP clk rate on RK3328 (git-fixes)
- commit bb0530e

- media: mediatek: vcodec: Handle invalid decoder vsi
  (CVE-2024-43831 bsc#1229309).
- commit 5fa7be4

- arm64: armv8_deprecated: Fix warning in isndep cpuhp starting process (git-fixes)
- commit 0be5a80

- soc: qcom: pdr: protect locator_addr with the main mutex
  (CVE-2024-43849 bsc#1229307).
- commit 2a0434d

- wifi: virt_wifi: don't use strlen() in const context
  (CVE-2024-43841 bsc#1229304).
- wifi: virt_wifi: avoid reporting connection success with wrong
  SSID (CVE-2024-43841 bsc#1229304).
- commit 4c3129e

- net: mana: Add support for page sizes other than 4KB on ARM64
  (jsc#PED-8491 bsc#1226530).
- commit 681a377

- bna: adjust 'name' buf size of bna_tcb and bna_ccb structures
  (CVE-2024-43839 bsc#1229301).
- can: mcp251xfd: fix infinite loop when xmit fails
  (CVE-2024-41088 bsc#1228469).
- can: mcp251xfd: move TX handling into separate file
  (CVE-2024-41088 bsc#1228469).
- commit 11bb8df

- hfs: fix to initialize fields of hfs_inode_info after
  hfs_alloc_inode() (git-fixes).
- commit 9abb2d6

- fuse: Initialize beyond-EOF page contents before setting
  uptodate (bsc#1229454).
- fs/netfs/fscache_cookie: add missing &amp;quot;n_accesses&amp;quot; check
  (bsc#1229453).
- commit 803fe7f

- Refresh patches.suse/drm-amd-display-Fix-vs-typos.patch (git-fixes)
  Alt-commit
- commit c32dc85

- drm/amd/display: Fix &amp;amp;&amp;amp; vs || typos (git-fixes).
- commit e43afc5

- blacklist.conf: Change entry to alt-commit
- Refresh patches.suse/platform-x86-intel-uncore-freq-Prevent-driver-loading-in-guests.patch.
- commit 90be679

- blacklist.conf: Change entry to alt-commit
- Refresh patches.suse/net-USB-Fix-wrong-direction-WARNING-in-plusb.c.patch.
- commit 7b2122f

- Refresh patches.suse/drm-amd-display-fix-cursor-offset-on-rotation-180.patch (git-fixes)
  Alt-commit
- commit 9bfc3c1

- Refresh patches.suse/drm-i915-vma-Fix-UAF-on-destroy-against-retire-race.patch (git-fixes)
  Alt-commit
- commit 050ccc2

- Refresh patches.suse/drm-amdgpu-validate-the-parameters-of-bo-mapping-ope.patch (git-fixes)
  Alt-commit
- commit b9a2ae1

- Refresh patches.suse/drm-amd-Flush-GFXOFF-requests-in-prepare-stage.patch (git-fixes)
  Alt-commit
- commit 5d001ff

- Refresh patches.suse/drm-amd-display-Preserve-original-aspect-ratio-in-cr.patch (git-fixes)
  Alt-commit
- commit 7a0957e

- Refresh patches.suse/0001-drm-amd-display-Implement-bounds-check-for-stream-en.patch (git-fixes)
  Alt-commit
- commit 83a8df8

- Refresh patches.suse/0001-drm-amd-display-Add-NULL-test-for-timing-generator-i.patch (git-fixes)
  Alt-commit
- commit 96ead93

- Refresh patches.suse/drm-amd-pm-fix-a-memleak-in-aldebaran_tables_init.patch (git-fixes)
  Alt-commit
- commit c97f053

- bpf: Fix a segment issue when downgrading gso_size (bsc#1229386
  CVE-2024-42281).
- commit 6eeb5fc

- cachefiles: propagate errors from vfs_getxattr() to avoid
  infinite  loop (bsc#1229418).
- commit e9340b2

- net/iucv: fix use after free in iucv_sock_close()
  (CVE-2024-42271 bsc#1229400 bsc#1228974).
- commit 82bb6f3

- Refresh sorted patches.
- Refresh patches.suse/cpu-SMT-Enable-SMT-only-if-a-core-is-online.patch.
- Refresh patches.suse/powerpc-topology-Check-if-a-core-is-online.patch.
- commit f56b67a

- Update patches.suse/cpu-SMT-Enable-SMT-only-if-a-core-is-online.patch
  (bsc#1214285 bsc#1205462 ltc#200161 ltc#200588 git-fixes
  bsc#1229327 ltc#206365).
- Update patches.suse/powerpc-topology-Check-if-a-core-is-online.patch
  (bsc#1214285 bsc#1205462 ltc#200161 ltc#200588 git-fixes
  bsc#1229327 ltc#206365).
- commit 66923e5

- net/rds: fix possible cp null dereference (git-fixes).
- commit 266afb9

- Refresh
  patches.suse/SUNRPC-avoid-soft-lockup-when-transmitting-UDP-to-re.patch.
  Add git commit and move to sorted section.
- commit 89d3015

- RDMA/rxe: Fix incomplete state save in rxe_requester (git-fixes)
- commit 06d3b72

- RDMA/rxe: Fix rxe_modify_srq (git-fixes)
- commit fdf3d9e

- RDMA/rxe: Move work queue code to subroutines (git-fixes)
- commit 582ab23

- Subject: RDMA/rxe: Handle zero length rdma (git-fixes)
- commit d8ea1d2

- Update
  patches.suse/drm-amdkfd-don-t-allow-mapping-the-MMIO-HDP-page-wit.patch
  (CVE-2024-41011 bsc#1228115 bsc#1228114).
- Update
  patches.suse/powerpc-pseries-Fix-scv-instruction-crash-with-kexec.patch
  (bsc#1194869 CVE-2024-42230 bsc#1228489).
- commit f6019c1

- arm64: dts: rockchip: Increase VOP clk rate on RK3328 (git-fixes)
- commit 6cb46c4

- arm64: armv8_deprecated: Fix warning in isndep cpuhp starting process (git-fixes)
- commit 6a10c09

- arm64: Fix KASAN random tag seed initialization (git-fixes)
- commit 3d017fc

- arm64: ACPI: NUMA: initialize all values of acpi_early_node_map to (git-fixes)
- commit 587e4e9

- ALSA: hda/realtek: Fix noise from speakers on Lenovo IdeaPad
  3 15IAU7 (git-fixes).
- ALSA: timer: Relax start tick time check for slave timer
  elements (git-fixes).
- commit 1158708

- net: mana: Fix doorbell out of order violation and avoid
  unnecessary doorbell rings (bsc#1229154).
- net: mana: Fix RX buf alloc_size alignment and atomic op panic
  (bsc#1229086).
- commit 79ff759

- io_uring: fix possible deadlock in
  io_register_iowq_max_workers() (bsc#1228616 CVE-2024-41080).
- commit 3aa0f11

- powerpc/kexec_file: fix cpus node update to FDT (bsc#1194869).
- powerpc/pseries: Whitelist dtl slub object for copying to
  userspace (bsc#1194869).
- powerpc/kexec: make the update_cpus_node() function public
  (bsc#1194869).
- powerpc/xmon: Check cpu id in commands &amp;quot;c#&amp;quot;, &amp;quot;dp#&amp;quot; and &amp;quot;dx#&amp;quot;
  (bsc#1194869).
- powerpc/64: Set _IO_BASE to POISON_POINTER_DELTA not 0 for
  CONFIG_PCI=n (bsc#1194869).
- powerpc/io: Avoid clang null pointer arithmetic warnings
  (bsc#1194869).
- powerpc/pseries: Add failure related checks for h_get_mpp and
  h_get_ppp (bsc#1194869).
- powerpc/kexec: split CONFIG_KEXEC_FILE and CONFIG_CRASH_DUMP
  (bsc#1194869).
- powerpc: xor_vmx: Add '-mhard-float' to CFLAGS (bsc#1194869).
- powerpc/radix: Move some functions into #ifdef
  CONFIG_KVM_BOOK3S_HV_POSSIBLE (bsc#1194869).
- powerpc: Fail build if using recordmcount with binutils v2.37
  (bsc#1194869).
- powerpc: use generic version of arch_is_kernel_initmem_freed()
  (bsc#1194869).
- Refresh patches.suse/powerpc-vmlinux.lds-Add-an-explicit-symbol-for-the-S.patch
- powerpc: Mark .opd section read-only (bsc#1194869).
- commit 2160944

- s390/dasd: fix error checks in dasd_copy_pair_store()
  (git-fixes bsc#1229190).
- commit 8da5fb8

- s390/uv: Panic for set and remove shared access UVC errors
  (git-fixes bsc#1229188).
- commit f8287f7

- s390/cpacf: Make use of invalid opcode produce a link error
  (git-fixes bsc#1227079).
- s390/cpacf: Split and rework cpacf query functions (git-fixes
  bsc#1229187).
- s390/cpacf: get rid of register asm (git-fixes bsc#1227079
  bsc#1229187).
- commit ef080ed

- drm: panel-orientation-quirks: Add quirk for OrangePi Neo
  (stable-fixes).
- drm: add missing MODULE_DESCRIPTION() macros (stable-fixes).
- drm: panel-orientation-quirks: Add labels for both Valve Steam
  Deck revisions (stable-fixes).
- commit e806b26

- docs: KVM: Fix register ID of SPSR_FIQ (git-fixes).
- drm/amd/display: Skip Recompute DSC Params if no Stream on Link
  (stable-fixes).
- ALSA: hda/realtek: Add Framework Laptop 13 (Intel Core Ultra)
  to quirks (stable-fixes).
- ALSA: hda/hdmi: Yet more pin fix for HP EliteDesk 800 G4
  (stable-fixes).
- ALSA: hda: Add HP MP9 G4 Retail System AMS to force connect list
  (stable-fixes).
- ALSA: line6: Fix racy access to midibuf (stable-fixes).
- drm/dp_mst: Skip CSN if topology probing is not done yet
  (stable-fixes).
- Revert &amp;quot;drm/amd/display: Add NULL check for 'afb' before
  dereferencing in amdgpu_dm_plane_handle_cursor_update&amp;quot;
  (stable-fixes).
- drm/amd/display: Add NULL check for 'afb' before dereferencing
  in amdgpu_dm_plane_handle_cursor_update (stable-fixes).
- drm/bridge: analogix_dp: properly handle zero sized AUX
  transactions (stable-fixes).
- drm/amd/pm: Fix the null pointer dereference for vega10_hwmgr
  (stable-fixes).
- drm/amdgpu: Add lock around VF RLCG interface (stable-fixes).
- drm/amdgpu/pm: Fix the null pointer dereference in
  apply_state_adjust_rules (stable-fixes).
- drm/amdgpu: Fix the null pointer dereference to ras_manager
  (stable-fixes).
- drm/amdgpu/pm: Fix the null pointer dereference for smu7
  (stable-fixes).
- drm/amdgpu/pm: Fix the param type of set_power_profile_mode
  (stable-fixes).
- drm: panel-orientation-quirks: Add quirk for Aya Neo KUN
  (stable-fixes).
- drm: panel-orientation-quirks: Add quirk for Lenovo Yoga Tab
  3 X90F (stable-fixes).
- drm: panel-orientation-quirks: Add quirk for Nanote UMPC-01
  (stable-fixes).
- commit f4c5b8f

- net, sunrpc: Remap EPERM in case of connection failure in
  xs_tcp_setup_socket (CVE-2024-42246 bsc#1228989).
- commit e5ad6b1

- btrfs: fix leak of qgroup extent records after transaction abort
  (git-fixes).
- btrfs: make btrfs_destroy_delayed_refs() return void
  (git-fixes).
- btrfs: remove unnecessary prototype declarations at disk-io.c
  (git-fixes).
- commit d462b94

- powerpc/topology: Check if a core is online (bsc#1214285
  bsc#1205462 ltc#200161 ltc#200588 git-fixes).
- cpu/SMT: Enable SMT only if a core is online (bsc#1214285
  bsc#1205462 ltc#200161 ltc#200588 git-fixes).
- commit d553d97

- platform/x86/amd/hsmp: Check HSMP support on AMD family of processors (jsc#PED-8779).
- commit 1be5f1f

- platform/x86/amd/hsmp: switch to use device_add_groups() (jsc#PED-8779).
- commit 06e9d31

- platform/x86/amd/hsmp: Change devm_kzalloc() to devm_kcalloc() (jsc#PED-8779).
- commit 5b03027

- platform/x86/amd/hsmp: Remove extra parenthesis and add a space (jsc#PED-8779).
- commit 1a47b84

- platform/x86/amd/hsmp: Check num_sockets against MAX_AMD_SOCKETS (jsc#PED-8779).
- commit 3ebff38

- platform/x86/amd/hsmp: Non-ACPI support for AMD F1A_M00~0Fh (jsc#PED-8779).
- commit 3876087

- platform/x86/amd/hsmp: Add support for ACPI based probing (jsc#PED-8779).
- commit 1c4efdd

- platform/x86/amd/hsmp: Restructure sysfs group creation (jsc#PED-8779).
- commit f11ea1a

- platform/x86/amd/hsmp: Move dev from platdev to hsmp_socket (jsc#PED-8779).
- commit ec733e8

- platform/x86/amd/hsmp: Define a struct to hold mailbox regs (jsc#PED-8779).
- commit dfa3da1

- platform/x86/amd/hsmp: Create static func to handle platdev (jsc#PED-8779).
- commit c01d7b5

- platform/x86/amd/hsmp: Cache pci_dev in struct hsmp_socket (jsc#PED-8779).
- commit 7ba0b5e

- platform/x86/amd/hsmp: Move hsmp_test to probe (jsc#PED-8779).
- commit e8c18c1

- tcp_metrics: validate source addr length
  (CVE-2024-42154 bsc#1228507).
- commit 4c817e3

- memcg: protect concurrent access to mem_cgroup_idr (git-fixes).
- commit 2c5d7b8

- libceph: fix race between delayed_work() and ceph_monc_stop()
  (bsc#1228959 CVE-2024-42232).
- commit 27160c2

- ipv6: sr: fix incorrect unregister order (git-fixes).
- commit 430794a

- ipv6: sr: fix possible use-after-free and null-ptr-deref
  (CVE-2024-26735 bsc#1222372).
- commit 9456b6b

- x86/APM: drop the duplicate APM_MINOR_DEV macro (git-fixes).
- commit 64f81fd

- net/sched: flower: Fix chain template offload (CVE-2024-26669
  bsc#1222350).
- commit 04f92b6

- x86/mm: Fix pti_clone_entry_text() for i386 (git-fixes).
- commit aac2b6a

- x86/pm: Work around false positive kmemleak report in msr_build_context() (git-fixes).
- commit 7560f66

- x86/insn: Fix PUSH instruction in x86 instruction decoder opcode map (git-fixes).
- commit 8b41557

- x86/mtrr: Check if fixed MTRRs exist before saving them (git-fixes).
- commit 358a165

- inet_diag: Initialize pad field in struct inet_diag_req_v2
  (CVE-2024-42106 bsc#1228493).
- commit 082b3ea

- selftests/bpf: Cover verifier checks for mutating
  sockmap/sockhash (bsc#1226885 CVE-2024-38662).
- Revert &amp;quot;bpf, sockmap: Prevent lock inversion deadlock in map
  delete elem&amp;quot; (bsc#1226885 CVE-2024-38662).
- bpf: Allow delete from sockmap/sockhash only if update is
  allowed (bsc#1226885 CVE-2024-38662).
- commit ae18577

- genirq: Take the proposed affinity at face value if force==true
  (git-fixes).
- commit 01fe9f9

- rpm/kernel-binary.spec.in: fix klp_symbols macro
  The commit below removed openSUSE filter from %ifs of the klp_symbols
  definition. But it removed -c of grep too and that causes:
  error: syntax error in expression:  01 &amp;amp;&amp;amp; (  || 1 )
  error:                                        ^
  error: unmatched (:  01 &amp;amp;&amp;amp; (  || 1 )
  error:                     ^
  error: kernel-default.spec:137: bad %if condition:  01 &amp;amp;&amp;amp; (  || 1 )
  So reintroduce -c to the PTF's grep.
  Fixes: fd0b293bebaf (kernel-binary.spec.in: Enable klp_symbols on openSUSE Tumbleweed (boo#1229042).)
- commit 4a36fe3

- i2c: smbus: Send alert notifications to all devices if source
  not found (git-fixes).
- i2c: smbus: Improve handling of stuck alerts (git-fixes).
- spi: spi-fsl-lpspi: Fix scldiv calculation (git-fixes).
- drm/client: fix null pointer dereference in
  drm_client_modeset_probe (git-fixes).
- ASoC: meson: axg-fifo: fix irq scheduling issue with PREEMPT_RT
  (git-fixes).
- ASoC: codecs: wsa881x: Correct Soundwire ports mask (git-fixes).
- ASoC: codecs: wcd938x-sdw: Correct Soundwire ports mask
  (git-fixes).
- ALSA: usb-audio: Re-add ScratchAmp quirk entries (git-fixes).
- commit 3bff740

- kernel-binary.spec.in: Enable klp_symbols on openSUSE Tumbleweed (boo#1229042).
  After the Jump project the kernel used by SLE and openSUSE Leap are the
  same. As consequence the klp_symbols variable is set, enabling
  kernel-default-livepatch-devel on both SLE and openSUSE.
  The current rules to avoid enabling the package exclude openSUSE
  Tumbleweed alone, which doesn't makes sense for now. Enabling
  kernel-default-livepatch-devel on TW makes it easier to test the
  creation of kernel livepatches of the next SLE versions.
- commit fd0b293

- net: ks8851: Fix potential TX stall after interface reopen
  (git-fixes).
- net: ks8851: Fix deadlock with the SPI chip variant (git-fixes).
- net: ks8851: Fix another TX stall caused by wrong ISR flag
  handling (git-fixes).
- commit 7cb23d2

- net: ks8851: Queue RX packets in IRQ handler instead of
  disabling BHs (CVE-2024-35971 bsc#1224578).
- net: ks8851: Handle softirqs at the end of IRQ thread to fix
  hang (CVE-2024-35971 bsc#1224578).
- net: ks8851: Inline ks8851_rx_skb() (CVE-2024-35971
  bsc#1224578).
- net: ks8851: Fix TX stall caused by TX buffer overrun
  (gix-fixes).
- commit a0911e3

- blk-mq: use hk cpus only when isolcpus=io_queue is enabled
  (bsc#1229034).
- lib/group_cpus.c: honor housekeeping config when grouping CPUs
  (bsc#1229034).
- virtio: blk/scsi: use block layer helpers to calculate num of
  queues (bsc#1229034).
- scsi: use block layer helpers to calculate num of queues
  (bsc#1229034).
- nvme-pci: use block layer helpers to calculate num of queues
  (bsc#1229034).
- blk-mq: add number of queue calc helper (bsc#1229034).
- virtio: blk/scs: replace blk_mq_virtio_map_queues with
  blk_mq_dev_map_queues (bsc#1229034).
- nvme: replace blk_mq_pci_map_queues with blk_mq_dev_map_queues
  (bsc#1229034).
- scsi: replace blk_mq_pci_map_queues with blk_mq_dev_map_queues
  (bsc#1229034).
- blk-mq: introduce blk_mq_dev_map_queues (bsc#1229034).
- virito: add APIs for retrieving vq affinity (bsc#1229034).
- scsi: pm8001: do not overwrite PCI queue mapping (bsc#1229034).
- commit 8efabbc

- ACPI: bus: Indicate support for IRQ ResourceSource thru _OSC
  (git-fixes).
- commit dc74872

- ACPI: bus: Indicate support for the Generic Event Device thru
  _OSC (git-fixes).
- Refresh
  patches.suse/ACPI-Fix-Generic-Initiator-Affinity-_OSC-bit.patch.
- commit 5e88627

- lib/group_cpus.c: avoid acquiring cpu hotplug lock in
  group_cpus_evenly (bsc#1229031).
- lib/group_cpus: Export group_cpus_evenly() (bsc#1229031).
- genirq/affinity: Only build SMP-only helper functions on SMP
  kernels (bsc#1229031).
- blk-mq: Build default queue map via group_cpus_evenly()
  (bsc#1229031).
- genirq/affinity: Move group_cpus_evenly() into lib/
  (bsc#1229031).
- genirq/affinity: Rename irq_build_affinity_masks as
  group_cpus_evenly (bsc#1229031).
- genirq/affinity: Don't pass irq_affinity_desc array to
  irq_build_affinity_masks (bsc#1229031).
- genirq/affinity: Pass affinity managed mask array to
  irq_build_affinity_masks (bsc#1229031).
- genirq/affinity: Remove the 'firstvec' parameter from
  irq_build_affinity_masks (bsc#1229031).
- genirq/affinity: Replace cpumask_weight() with cpumask_empty()
  where appropriate (bsc#1229031).
- commit 614293b

- cpuidle, ACPI: Evaluate LPI arch_flags for broadcast timer
  (git-fixes).
- commit 39678ad

- ACPI: x86: s2idle: Post-increment variables when getting
  constraints (git-fixes).
- Refresh
  patches.suse/ACPI-x86-s2idle-Fix-a-logic-error-parsing-AMD-constr.patch.
- commit f30def6

- Update
  patches.suse/0001-ocfs2-fix-DIO-failure-due-to-insufficient-transactio.patch
  (bsc#1216834 CVE-2024-42077 bsc#1228516).
  Add CVE references.
- commit 8360e90

- Update
  patches.suse/ALSA-emux-improve-patch-ioctl-data-validation.patch
  (stable-fixes CVE-2024-42097 bsc#1228766).
- Update
  patches.suse/ASoC-amd-acp-add-a-null-check-for-chip_pdev-structur.patch
  (git-fixes CVE-2024-42074 bsc#1228481).
- Update
  patches.suse/ASoC-fsl-asoc-card-set-priv-pdev-before-using-it.patch
  (git-fixes CVE-2024-42089 bsc#1228450).
- Update
  patches.suse/Bluetooth-qca-Fix-BT-enable-failure-again-for-QCA639.patch
  (git-fixes CVE-2024-42137 bsc#1228563).
- Update
  patches.suse/RDMA-restrack-Fix-potential-invalid-address-access.patch
  (git-fixes CVE-2024-42080 bsc#1228673).
- Update
  patches.suse/USB-core-Fix-duplicate-endpoint-bug-by-clearing-rese.patch
  (git-fixes CVE-2024-41035 bsc#1228485).
- Update patches.suse/USB-serial-mos7840-fix-crash-on-resume.patch
  (git-fixes CVE-2024-42244 bsc#1228967).
- Update
  patches.suse/ata-libata-core-Fix-null-pointer-dereference-on-erro.patch
  (git-fixes CVE-2024-41098 bsc#1228467).
- Update
  patches.suse/block-add-check-that-partition-length-needs-to-be-aligned-with-block-size.patch
  (bsc#1227867 CVE-2024-41000 CVE-2023-52458 bsc#1220428).
- Update
  patches.suse/bpf-Fail-bpf_timer_cancel-when-callback-is-being-can.patch
  (bsc#1228531 CVE-2024-41045 CVE-2024-42239 bsc#1228979).
- Update
  patches.suse/crypto-aead-cipher-zeroize-key-buffer-after-use.patch
  (stable-fixes CVE-2024-42229 bsc#1228708).
- Update
  patches.suse/crypto-ecdh-explicitly-zeroize-private_key.patch
  (stable-fixes CVE-2024-42098 bsc#1228779).
- Update
  patches.suse/drm-amd-display-Check-index-msg_id-before-read-or-wr.patch
  (stable-fixes CVE-2024-42121 bsc#1228590).
- Update
  patches.suse/drm-amd-display-Check-pipe-offset-before-setting-vbl.patch
  (stable-fixes CVE-2024-42120 bsc#1228588).
- Update
  patches.suse/drm-amd-display-Skip-finding-free-audio-for-unknown-.patch
  (stable-fixes CVE-2024-42119 bsc#1228584).
- Update
  patches.suse/drm-amdgpu-Fix-signedness-bug-in-sdma_v4_0_process_t.patch
  (git-fixes CVE-2024-41022 bsc#1228429).
- Update
  patches.suse/drm-amdgpu-avoid-using-null-object-of-framebuffer.patch
  (stable-fixes CVE-2024-41093 bsc#1228660).
- Update
  patches.suse/drm-i915-gt-Fix-potential-UAF-by-revoke-of-fence-reg.patch
  (git-fixes CVE-2024-41092 bsc#1228483).
- Update
  patches.suse/drm-lima-fix-shared-irq-handling-on-driver-remove.patch
  (stable-fixes CVE-2024-42127 bsc#1228721).
- Update
  patches.suse/drm-nouveau-dispnv04-fix-null-pointer-dereference-in-66edf3f.patch
  (stable-fixes CVE-2024-41095 bsc#1228662).
- Update
  patches.suse/drm-nouveau-dispnv04-fix-null-pointer-dereference-in.patch
  (stable-fixes CVE-2024-41089 bsc#1228658).
- Update
  patches.suse/drm-nouveau-fix-null-pointer-dereference-in-nouveau_.patch
  (git-fixes CVE-2024-42101 bsc#1228495).
- Update
  patches.suse/drm-panel-ilitek-ili9881c-Fix-warning-with-GPIO-cont.patch
  (stable-fixes CVE-2024-42087 bsc#1228677).
- Update
  patches.suse/drm-radeon-check-bo_va-bo-is-non-NULL-before-using-i.patch
  (stable-fixes CVE-2024-41060 bsc#1228567).
- Update
  patches.suse/firmware-cs_dsp-Fix-overflow-checking-of-wmfw-header.patch
  (git-fixes CVE-2024-41039 bsc#1228515).
- Update
  patches.suse/firmware-cs_dsp-Prevent-buffer-overrun-when-processi.patch
  (git-fixes CVE-2024-41038 bsc#1228509).
- Update
  patches.suse/firmware-cs_dsp-Return-error-if-block-header-overflo.patch
  (git-fixes CVE-2024-42238 bsc#1228991).
- Update
  patches.suse/firmware-cs_dsp-Use-strnlen-on-name-fields-in-V1-wmf.patch
  (git-fixes CVE-2024-41056 bsc#1228480).
- Update
  patches.suse/firmware-cs_dsp-Validate-payload-length-before-proce.patch
  (git-fixes CVE-2024-42237 bsc#1228992).
- Update
  patches.suse/gpio-davinci-Validate-the-obtained-number-of-IRQs.patch
  (git-fixes CVE-2024-42092 bsc#1228447).
- Update
  patches.suse/iio-chemical-bme680-Fix-overflows-in-compensate-func.patch
  (git-fixes CVE-2024-42086 bsc#1228452).
- Update
  patches.suse/jffs2-Fix-potential-illegal-address-access-in-jffs2_free_inode.patch
  (git-fixes CVE-2024-42115 bsc#1228656).
- Update
  patches.suse/libceph-fix-race-between-delayed_work-and-ceph_monc_s.patch
  (bsc#1228190 CVE-2024-42232 bsc#1228959).
- Update
  patches.suse/media-dvb-frontends-tda10048-Fix-integer-overflow.patch
  (stable-fixes CVE-2024-42223 bsc#1228726).
- Update
  patches.suse/msft-hv-3022-net-mana-Fix-possible-double-free-in-error-handling-.patch
  (git-fixes CVE-2024-42069 bsc#1228463).
- Update
  patches.suse/net-can-j1939-Initialize-unused-data-in-j1939_send_o.patch
  (git-fixes CVE-2024-42076 bsc#1228484).
- Update
  patches.suse/net-can-j1939-enhanced-error-handling-for-tightly-re.patch
  (git-fixes CVE-2023-52887 bsc#1228426).
- Update
  patches.suse/nfc-nci-Add-the-inconsistency-check-between-the-inpu.patch
  (stable-fixes CVE-2024-42130 bsc#1228687).
- Update
  patches.suse/nilfs2-add-missing-check-for-inode-numbers-on-directory-entries.patch
  (git-fixes CVE-2024-42104 bsc#1228654).
- Update patches.suse/nvme-avoid-double-free-special-payload.patch
  (git-fixes CVE-2024-41073 bsc#1228635).
- Update patches.suse/nvmet-always-initialize-cqe.result.patch
  (git-fixes CVE-2024-41079 bsc#1228615).
- Update
  patches.suse/nvmet-fix-a-possible-leak-when-destroy-a-ctrl-during.patch
  (git-fixes CVE-2024-42152 bsc#1228724).
- Update
  patches.suse/ocfs2-strict-bound-check-before-memcmp-in-ocfs2_xatt.patch
  (bsc#1228410 CVE-2024-41016).
- Update patches.suse/orangefs-fix-out-of-bounds-fsid-access.patch
  (git-fixes CVE-2024-42143 bsc#1228748).
- Update
  patches.suse/pinctrl-fix-deadlock-in-create_pinctrl-when-handling.patch
  (git-fixes CVE-2024-42090 bsc#1228449).
- Update
  patches.suse/powerpc-Avoid-nmi_enter-nmi_exit-in-real-mode-interr.patch
  (bsc#1221645 ltc#205739 bsc#1223191 CVE-2024-42126 bsc#1228718).
- Update
  patches.suse/usb-atm-cxacru-fix-endpoint-checking-in-cxacru_bind.patch
  (git-fixes CVE-2024-41097 bsc#1228513).
- Update
  patches.suse/usb-dwc3-core-remove-lock-of-otg-mode-during-gadget-.patch
  (git-fixes CVE-2024-42085 bsc#1228456).
- Update
  patches.suse/usb-gadget-configfs-Prevent-OOB-read-write-in-usb_st.patch
  (stable-fixes CVE-2024-42236 bsc#1228964).
- Update
  patches.suse/wifi-cfg80211-restrict-NL80211_ATTR_TXQ_QUANTUM-valu.patch
  (git-fixes CVE-2024-42114 bsc#1228564).
- Update
  patches.suse/wifi-mt76-replace-skb_put-with-skb_put_zero.patch
  (stable-fixes CVE-2024-42225 bsc#1228710).
- Update
  patches.suse/x86-bhi-Avoid-warning-in-DB-handler-due-to-BHI-mitigation.patch
  (git-fixes CVE-2024-42240 bsc#1228966).
  Add CVE references.
- commit 05086b1

- ACPI: thermal: Drop nocrt parameter (git-fixes).
- commit 5de370b

- perf/smmuv3: Enable HiSilicon Erratum 162001900 quirk for
  HIP08/09 (git-fixes).
- commit 9250a1e

- Bluetooth: l2cap: always unlock channel in
  l2cap_conless_channel() (git-fixes).
- net: usb: qmi_wwan: fix memory leak for not ip packets
  (git-fixes).
- padata: Fix possible divide-by-0 panic in padata_mt_helper()
  (git-fixes).
- commit 29bbfef

- ACPI: bus: Rework system-level device notification handling
  (git-fixes).
- Refresh
  patches.suse/ACPI-bus-Ensure-that-notify-handlers-are-not-running.patch.
- commit 7dcab46

- irqdomain: Fixed unbalanced fwnode get and put (git-fixes).
- genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU
  offline (git-fixes).
- genirq/generic_chip: Make irq_remove_generic_chip() irqdomain
  aware (git-fixes).
- genirq/matrix: Exclude managed interrupts in
  irq_matrix_allocated() (git-fixes).
- genirq/ipi: Fix NULL pointer deref in
  irq_data_get_affinity_mask() (git-fixes).
- irqdomain: Fix domain registration race (git-fixes).
- irqdomain: Fix mapping-creation race (git-fixes).
- irqdomain: Refactor __irq_domain_alloc_irqs() (git-fixes).
- irqdomain: Look for existing mapping only once (git-fixes).
- irqdomain: Drop bogus fwspec-mapping error handling (git-fixes).
- irqdomain: Fix disassociation race (git-fixes).
- irqdomain: Fix association race (git-fixes).
- genirq: Add might_sleep() to disable_irq() (git-fixes).
- kernel/irq/irqdomain.c: fix memory leak with using
  debugfs_lookup() (git-fixes).
- genirq/irqdesc: Don't try to remove non-existing sysfs files
  (git-fixes).
- irqdomain: Report irq number for NOMAP domains (git-fixes).
- genirq: Don't return error on missing optional
  irq_request_resources() (git-fixes).
- genirq: Always limit the affinity to online CPUs (git-fixes).
- genirq/msi: Shutdown managed interrupts with unsatifiable
  affinities (git-fixes).
- commit 2fd5320

- net: ntb_netdev: Move ntb_netdev_rx_handler() to call netif_rx()
  from __netif_rx() (CVE-2024-42110 bsc#1228501).
- commit 096fa1d

- wireguard: allowedips: avoid unaligned 64-bit memory accesses
  (CVE-2024-42247 bsc#1228988).
- commit 9870725

- ax25: Fix refcount imbalance on inbound connections
  (CVE-2024-40910 bsc#1227832).
- commit 12cb329

- tipc: fix kernel panic when enabling bearer (CVE-2022-48865
  bsc#1228065).
- commit 2f9875a

- PM: sleep: Fix possible deadlocks in core system-wide PM code
  (bsc#1221269 CVE-2023-52498).
- async: Introduce async_schedule_dev_nocall() (bsc#1221269).
- async: Split async_schedule_node_domain() (bsc#1221269).
- commit 14accb2

- s390/sclp: Fix sclp_init() cleanup on failure (bsc#1228579
  CVE-2024-41068).
- commit 77769f2

- net: dsa: fix panic when DSA master device unbinds on shutdown
  (CVE-2022-48808 bsc#1227958).
- commit 1e672d7

- serial: 8250_omap: Fix Errata i2310 with RX FIFO level check
  (bsc#1228446 CVE-2024-42095).
- commit 082abd5

- serial: 8250_omap: Implementation of Errata i2310 (bsc#1228446
  CVE-2024-42095).
- commit f99b96f

- tcp: avoid too many retransmit packets (CVE-2024-41007
  bsc#1227863).
- commit ddec32c

- config.sh: generate and install compile_commands.json (bsc#1228971)
  This file contains the command line options used to compile every C file.
  It's useful for the livepatching team.
- kernel-binary: generate and install compile_commands.json (bsc#1228971)
  This file contains the command line options used to compile every C file.
  It's useful for the livepatching team.
- commit 0d8cf49

- power: supply: axp288_charger: Round constant_charge_voltage
  writes down (git-fixes).
- power: supply: axp288_charger: Fix constant_charge_voltage
  writes (git-fixes).
- commit db1c6e2

- bpf: Defer work in bpf_timer_cancel_and_free (bsc#1228531
  CVE-2024-41045).
- bpf: Fail bpf_timer_cancel when callback is being cancelled
  (bsc#1228531 CVE-2024-41045).
- bpf: Check map-&amp;gt;usercnt after timer-&amp;gt;timer is assigned
  (bsc#1228531 CVE-2024-41045).
- commit 13bca15

- scsi: qedi: Fix crash while reading debugfs attribute
  (bsc#1227929 CVE-2024-40978).
- block/ioctl: prefer different overflow check (bsc#1227867
  CVE-2024-41000).
- block: add check that partition length needs to be aligned
  with block size (bsc#1227867 CVE-2024-41000).
- commit f6a3a4f

- ice: Don't process extts if PTP is disabled (CVE-2024-42107
  bsc#1228494).
- ice: Fix improper extts handling (CVE-2024-42139 bsc#1228503).
- bnx2x: Fix multiple UBSAN array-index-out-of-bounds
  (CVE-2024-42148 bsc#1228487).
- net/mlx5: E-switch, Create ingress ACL when needed
  (CVE-2024-42142 bsc#1228491).
- gve: Account for stopped queues when reading NIC stats
  (CVE-2024-42162 bsc#1228706).
- commit 52582b0

- packaging: Add case-sensitive perl option parsing
  A recent change in Getopt::Long [1]:
  Changes in version 2.55
  - ----------------------
  * Fix long standing bug that duplicate options were not detected
  when the options differ in case while ignore_case is in effect.
  This will now yield a warning and become a fatal error in a future
  release.
  perl defaults to ignore_case by default, switch it off to avoid
  accidental misparsing of options.
  This was suggested after similar change in scripts/.
- commit e978477

- xdp: Remove WARN() from __xdp_reg_mem_model() (bsc#1228482
  CVE-2024-42082).
- commit 3fdab8d

- netfilter: nf_tables: prefer nft_chain_validate (CVE-2024-41042
  bsc#1228526).
- Refresh
  patches.kabi/netfilter-KABI-workaround-for-CVE-2023-3610-bsc-1213.patch.
- commit 05a5b4a

- drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc (CVE-2024-42228 bsc#1228667).
- commit 8a881f9

- btrfs: sysfs: update fs features directory asynchronously
  (bsc#1226168).
- commit a738a53

- tipc: force a dst refcount before doing decryption (CVE-2024-40983 bsc#1227819).
- commit af53498

Package avahi was updated:

- prerequire avahi in avahi-autipd as we user &amp;quot;user avahi&amp;quot;
- Add avahi-CVE-2024-52616.patch:
  Backporting 1dade81c from upstream: Properly randomize query id
  of DNS packets.
  (CVE-2024-52616, bsc#1233420)

- Add avahi-filter-bogus-services.patch: no longer supply bogus
  services to callbacks (bsc#1226586).

Package util-linux was updated:

- Skip aarch64 decode path for rest of the architectures  (bsc#1229476, util-linux-lscpu-skip-aarch64-decode.patch).

Package expat was updated:

- security update- added patches
  fix CVE-2024-50602 [bsc#1232579], DoS via XML_ResumeParser
  + expat-CVE-2024-50602.patch

Package ncurses was updated:

- Add patch ncurses-6.1-boo1229028.patch (boo#1229028)  * Allow that terminal description based on static fallback
    entries can be freed.

Package openssl-1_1 was updated:

- Security fix: [bsc#1220262, CVE-2023-50782]  * Implicit rejection in PKCS#1 v1.5
  * Add openssl-CVE-2023-50782.patch

Package libpcap was updated:

Package 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.

- Add CVE-2024-9287-venv_path_unquoted.patch to properly quote
  path names provided when creating a virtual environment
  (bsc#1232241, CVE-2024-9287)

- Drop .pyc files from docdir for reproducible builds
  (bsc#1230906).

- Add CVE-2024-6232-ReDOS-backtrack-tarfile.patch prevent
  ReDos via excessive backtracking while parsing header values
  (bsc#1230227, CVE-2024-6232).

- Add CVE-2024-5642-switch-off-NPN.patch switching off the NPN
  support eliminating bsc#1227233 (CVE-2024-5642).

- Add CVE-2024-6923-email-hdr-inject.patch to prevent email
  header injection due to unquoted newlines (bsc#1228780,
  CVE-2024-6923).
- Add CVE-2024-7592-quad-complex-cookies.patch fixing quadratic
  complexity in parsing cookies with backslashes (bsc#1229596,
  CVE-2024-7592)
- %{profileopt} variable is set according to the variable
  %{do_profiling} (bsc#1227999)

- Remove %suse_update_desktop_file macro as it is not useful any
  more.

- Stop using %%defattr, it seems to be breaking proper executable
  attributes on /usr/bin/ scripts (bsc#1227378).

Package ruby2.5 was updated:

- backport REXML from 3.3  - fix denial of service when parsing a XML that has many deep
    elements with the same local name attributes
    (boo#1229673 CVE-2024-43398)
  - fix denial of service when parsing an XML that contains many
    specific characters such as whitespaces, &amp;gt;] and ]&amp;gt;
    (boo#1228794 CVE-2024-41123)
  - fix denial of service when parsing an XML that has many entity
    expansions with SAX2 or pull parser API
    (boo#1228799 CVE-2024-41946)
  - fix denial of service when parsing an XML that has many left
    angled brackets in an attribute value
    (boo#1224390 CVE-2024-35176)
  - fix ReDoS when parsing an XML that has many specific characters
    (boo#1228072 CVE-2024-39908)

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

- Update version to 1.12:
  - Set the filesystem root on zypper when given (bsc#1230229,bsc#1229014)

Package systemd was updated:

- Import commit cba472567893618e15b4ab95a3cb0a762ad3ed10  0e8c003e1f core/unit: increase the NameOwnerChanged/GetNameOwner timeout to the unit's start timeout (bsc#1230272)
  621e16c0b8 core/unit: add get_timeout_start_usec in UnitVTable and define it for service
  b4140d888a sd-bus: make bus_add_match_full accept timeout
  81cb3a4fb5 udev-builtin-path_id: SAS wide ports must have num_phys &amp;gt; 1 (bsc#1231610)
  533e98fc6b sd-device: add helper to read a unsigned int attribute

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)

- PluginFrame: Send unescaped colons in header values
  (bsc#1231043)
  According to the STOMP protocol it would be correct to escape a
  colon in a header-value, but it breaks plugin receivers which do
  not expect this. The first colon separates header-name from
  header-value, so escaping in the header-value is not needed
  anyway.
  Escaping in the header-value affects especially the urlresolver
  plugins. The input URL is passed in a header, but sent back as
  raw data in the frames body. If the plugin receiver does not
  correctly unescape the URL we may get back a &amp;quot;https\c//&amp;quot; which is
  not usable.
- Do not ignore return value of std::remove_if in MediaSyncFacade
  (fixes #579)
- Fix hang in curl code with no network connection (bsc#1230912)
- version 17.35.12 (35)

- Deprecate librpmDb::db_const_iterator default ctor (bsc#1230267)
  It's preferred to explicitly tell the root directory of the
  system whose database you want to query.
- version 17.35.11 (35)

- API refactoring. Prevent zypper from using now private libzypp
  symbols (bsc#1230267)
- Conflicts: zypper &amp;lt;= 1.14.76
- version 17.35.10 (35)

- single_rpmtrans: fix installation of .src.rpms (bsc#1228647)
- version 17.35.9 (35)

Package shadow was updated:

- bsc#1230972: Add useradd warnings when requested UID is outside  the default range
- add shadow-bsc1230972-useradd-warning.patch

- bsc#1228337: chage -d date vs passwd -S output is off by one
  Remove shadow-bsc1176006-chage-date.patch

Package logrotate was updated:

- Backport 'ignoreduplicates' configuration flag (jsc#PED-10366)  * Added patch logrotate-ignore-duplicates.patch
  * Allows log processing with duplicate logfile matches

Package pam-config was updated:

- Change check for existence of modules.  If we have a biarch architecture, we check that the 64bit
  PAM module is there and report an error if not. For the 32bit
  variant, we only issue a warning.
  [pam-config-change-check-for-existence-of-modules.patch, bsc#1227216]

Package 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

- Fix rich rule comparison in firewalld module (bsc#1222684)
- test_vultrpy: adjust test expectation to prevent failure after Debian 10 EOL
- Make auth.pam more robust with Salt Bundle and fix tests
- Fix performance of user.list_groups with many remote groups
- Fix &amp;quot;status.diskusage&amp;quot; function and exclude some tests for Salt Bundle
- Skip certain tests if necessary for some OSes and set flaky ones
- Add a timer to delete old env post update for venv-minion
- Several fixes for tests to avoid errors and failures in some OSes
- Added:
  * firewalld-normalize-new-rich-rules-before-comparing-.patch
  * several-fixes-for-tests-to-avoid-errors-and-failures.patch
  * test_vultrpy-adjust-test-expectation-to-prevent-fail.patch
  * fix-status.diskusage-and-exclude-some-tests-to-run-w.patch
  * skip-certain-tests-if-necessary-and-mark-some-flaky-.patch
  * some-more-small-tests-fixes-enhancements-661.patch
  * provide-systemd-timer-unit.patch
  * fix-user.list_groups-omits-remote-groups.patch

Package rsyslog was updated:

- fix PreserveFQDN option before daemon is restarted (bsc#1231229)  add 0001-core-bugfix-rsyslog-messages-may-not-always-have-FQD.patch

- restart daemon after update at the end of the transaction
  (bsc#1230984)

Package 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:

-  Adjust spec to split out rpcd_* binaries into a separate  sub package; (bsc#1231414).

- Incorrect FSCTL_QUERY_ALLOCATED_RANGES response when truncated;
  (bso#15699); (bsc#1229684).

- Regression DFS not working with widelinks = true, updated to
  fix DFS link enumeration; (bso#15435); (bsc#1213607);

- use-after-free in aio_del_req_from_fsp during smbd shutdown
  after failed IPC FSCTL_PIPE_TRANSCEIVE; (bsc#1223345);
  (bso#15423).

- Reduce winbind error msg to debug for a PDC/NT4 domain
  (bsc#1221168).

Package shim was updated:

- Update shim-install to apply the missing fix for openSUSE Leap  (bsc#1210382) fixed by Gary.
  * 86b73d1 Fix that bootx64.efi is not updated on Leap
- Update shim-install to use the 'removable' way for SL-Micro
  (bsc#1230316) fixed by Gary.
  * 433cc4e Always use the removable way for SL-Micro

Package 000release-packages:sle-module-basesystem-release was updated:

Package 000release-packages:sle-module-containers-release was updated:

Package 000release-packages:sle-module-desktop-applications-release was updated:

Package 000release-packages:sle-module-development-tools-release was updated:

Package 000release-packages:sle-module-hpc-release was updated:

Package 000release-packages:sle-module-public-cloud-release was updated:

Package 000release-packages:sle-module-server-applications-release was updated:

Package strace was updated:

- Change the license to the correct LGPL-2.1-or-later  (bsc#1228216).

Package tuned was updated:

- added uncore plugin (jsc#PED-8397)  A uncore-477.patch
  A uncore-590.patch
  A uncore-606.patch
- own directory /usr/lib/kernel/install.d to fix build

Package util-linux-systemd was updated:

- Skip aarch64 decode path for rest of the architectures  (bsc#1229476, util-linux-lscpu-skip-aarch64-decode.patch).

Package vim was updated:

- Fix 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]

- Update 0001-possibly-truncate-pathname-components.patch
  * Take the patch from savannah repository where the checking of the file
    length doesn't include path length.
  * [bsc#1204720, bsc#1231661]

Package wicked was updated:

- Update to version 0.6.77  - compat-suse: use iftype in sysctl handling (bsc#1230911, gh#openSUSE/wicked#1043)
  - Always generate the ipv4/ipv6 &amp;lt;enabled&amp;gt;true|false&amp;lt;/enabled&amp;gt; node
  - Inherit all, default and interface sysctl settings also for loopback,
    except for use_tempaddr and accept_dad.
  - Consider only interface specific accept_redirects sysctl settings.
  - Adopt ifsysctl(5) manual page with wicked specific behavior.
  - route: fix family and destination processing (bsc#1231060)
  - man: improve wicked-config(5) file description (gh#openSUSE/wicked#1039)
  - dhcp4: add ignore-rfc3927-1-6 wicked-config(5) option (jsc#PED-10855, gh#openSUSE/wicked#1038)
  - team: set arp link watcher interval default to 1s (gh#openSUSE/wicked#1037)
  - systemd: use `BindsTo=dbus.service` in favor of `Requisite=` (bsc#1229745)
  - compat-suse: fix use of deprecated `INTERFACETYPE=dummy` (boo#1229555)
  - arp: don't set target broadcast hardware address (gh#openSUSE/wicked#1036)
  - dbus: don't memcpy empty/NULL array value (gh#openSUSE/wicked#1035)
  - ethtool: fix leak and free pause data in ethtool_free (gh#openSUSE/wicked#1030)
- Removed patches included in the source archive:
  [- 0001-compat-suse-repair-dummy-interfaces-boo-1229555.patch]

- compat-suse: fix dummy interfaces configuration with
  INTERFACETYPE=dummy (boo#1229555, gh#openSUSE/wicked#1031)
  [+ 0001-compat-suse-repair-dummy-interfaces-boo-1229555.patch]

Package xen was updated:

- bsc#1232622 - VUL-0: CVE-2024-45818: xen: Deadlock in x86 HVM  standard VGA handling (XSA-463)
  xsa463-01.patch
  xsa463-02.patch
  xsa463-03.patch
  xsa463-04.patch
  xsa463-05.patch
  xsa463-06.patch
  xsa463-07.patch
  xsa463-08.patch
  xsa463-09.patch
  xsa463-10.patch
- bsc#1232624 - VUL-0: CVE-2024-45819: xen: libxl leaks data to PVH
  guests via ACPI tables (XSA-464)
  xsa464.patch
- Drop the following patches
  66e29480-x86-HVM-properly-reject-indirect-VRAM-writes.patch
  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

- bsc#1230366 - VUL-0: CVE-2024-45817: xen: x86: Deadlock in
  vlapic_error() (XSA-462)
  xsa462.patch

Package yast2-network was updated:

- Try to assign default global routes to an specific connection  when  possible (bsc#1232531).
- 4.5.25

Package zypper was updated:

- 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

- API refactoring. Prevent zypper from using now private libzypp
  symbols (bsc#1230267)
- BuildRequires:  libzypp-devel &amp;gt;= 17.35.10.
- Fix wrong numbers used in CommitSummary skipped/failed messages.
- version 1.14.77

</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/sle-hpc-15-sp5-byos-v20250110-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/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <Branch Type="Product Name" Name="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
        <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-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="bash-4.4-150400.27.3.2">
      <FullProductName ProductID="bash-4.4-150400.27.3.2">bash-4.4-150400.27.3.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="bash-sh-4.4-150400.27.3.2">
      <FullProductName ProductID="bash-sh-4.4-150400.27.3.2">bash-sh-4.4-150400.27.3.2</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.7-150300.13.14.1">
      <FullProductName ProductID="cloud-regionsrv-client-10.3.7-150300.13.14.1">cloud-regionsrv-client-10.3.7-150300.13.14.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.14.1">
      <FullProductName ProductID="cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.14.1">cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.14.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cpupower-5.14-150500.9.6.2">
      <FullProductName ProductID="cpupower-5.14-150500.9.6.2">cpupower-5.14-150500.9.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="crypto-policies-20210917.c9d86d1-150400.3.8.1">
      <FullProductName ProductID="crypto-policies-20210917.c9d86d1-150400.3.8.1">crypto-policies-20210917.c9d86d1-150400.3.8.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="curl-8.0.1-150400.5.59.1">
      <FullProductName ProductID="curl-8.0.1-150400.5.59.1">curl-8.0.1-150400.5.59.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="deltarpm-3.6.5-150000.5.6.3">
      <FullProductName ProductID="deltarpm-3.6.5-150000.5.6.3">deltarpm-3.6.5-150000.5.6.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="device-mapper-2.03.22_1.02.196-150500.7.12.2">
      <FullProductName ProductID="device-mapper-2.03.22_1.02.196-150500.7.12.2">device-mapper-2.03.22_1.02.196-150500.7.12.2</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-055+suse.396.g701c6212-150500.3.29.2">
      <FullProductName ProductID="dracut-055+suse.396.g701c6212-150500.3.29.2">dracut-055+suse.396.g701c6212-150500.3.29.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="e2fsprogs-1.46.4-150400.3.9.2">
      <FullProductName ProductID="e2fsprogs-1.46.4-150400.3.9.2">e2fsprogs-1.46.4-150400.3.9.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glib2-tools-2.70.5-150400.3.17.1">
      <FullProductName ProductID="glib2-tools-2.70.5-150400.3.17.1">glib2-tools-2.70.5-150400.3.17.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-2.31-150300.89.2">
      <FullProductName ProductID="glibc-2.31-150300.89.2">glibc-2.31-150300.89.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-32bit-2.31-150300.89.1">
      <FullProductName ProductID="glibc-32bit-2.31-150300.89.1">glibc-32bit-2.31-150300.89.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-devel-2.31-150300.89.2">
      <FullProductName ProductID="glibc-devel-2.31-150300.89.2">glibc-devel-2.31-150300.89.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-i18ndata-2.31-150300.89.2">
      <FullProductName ProductID="glibc-i18ndata-2.31-150300.89.2">glibc-i18ndata-2.31-150300.89.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-locale-2.31-150300.89.2">
      <FullProductName ProductID="glibc-locale-2.31-150300.89.2">glibc-locale-2.31-150300.89.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-locale-base-2.31-150300.89.2">
      <FullProductName ProductID="glibc-locale-base-2.31-150300.89.2">glibc-locale-base-2.31-150300.89.2</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-20241121.00-150400.13.14.1">
      <FullProductName ProductID="google-guest-configs-20241121.00-150400.13.14.1">google-guest-configs-20241121.00-150400.13.14.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.06-150500.29.37.1">
      <FullProductName ProductID="grub2-2.06-150500.29.37.1">grub2-2.06-150500.29.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grub2-i386-pc-2.06-150500.29.37.1">
      <FullProductName ProductID="grub2-i386-pc-2.06-150500.29.37.1">grub2-i386-pc-2.06-150500.29.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grub2-x86_64-efi-2.06-150500.29.37.1">
      <FullProductName ProductID="grub2-x86_64-efi-2.06-150500.29.37.1">grub2-x86_64-efi-2.06-150500.29.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kernel-default-5.14.21-150500.55.88.1">
      <FullProductName ProductID="kernel-default-5.14.21-150500.55.88.1">kernel-default-5.14.21-150500.55.88.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libatomic1-14.2.0+git10526-150000.1.6.1">
      <FullProductName ProductID="libatomic1-14.2.0+git10526-150000.1.6.1">libatomic1-14.2.0+git10526-150000.1.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libavahi-client3-0.8-150400.7.20.1">
      <FullProductName ProductID="libavahi-client3-0.8-150400.7.20.1">libavahi-client3-0.8-150400.7.20.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libavahi-common3-0.8-150400.7.20.1">
      <FullProductName ProductID="libavahi-common3-0.8-150400.7.20.1">libavahi-common3-0.8-150400.7.20.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libblkid1-2.37.4-150500.9.17.2">
      <FullProductName ProductID="libblkid1-2.37.4-150500.9.17.2">libblkid1-2.37.4-150500.9.17.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libcom_err2-1.46.4-150400.3.9.2">
      <FullProductName ProductID="libcom_err2-1.46.4-150400.3.9.2">libcom_err2-1.46.4-150400.3.9.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libcpupower0-5.14-150500.9.6.2">
      <FullProductName ProductID="libcpupower0-5.14-150500.9.6.2">libcpupower0-5.14-150500.9.6.2</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.0.1-150400.5.59.1">
      <FullProductName ProductID="libcurl4-8.0.1-150400.5.59.1">libcurl4-8.0.1-150400.5.59.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libdevmapper-event1_03-2.03.22_1.02.196-150500.7.12.2">
      <FullProductName ProductID="libdevmapper-event1_03-2.03.22_1.02.196-150500.7.12.2">libdevmapper-event1_03-2.03.22_1.02.196-150500.7.12.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libdevmapper1_03-2.03.22_1.02.196-150500.7.12.2">
      <FullProductName ProductID="libdevmapper1_03-2.03.22_1.02.196-150500.7.12.2">libdevmapper1_03-2.03.22_1.02.196-150500.7.12.2</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="libext2fs2-1.46.4-150400.3.9.2">
      <FullProductName ProductID="libext2fs2-1.46.4-150400.3.9.2">libext2fs2-1.46.4-150400.3.9.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libfdisk1-2.37.4-150500.9.17.2">
      <FullProductName ProductID="libfdisk1-2.37.4-150500.9.17.2">libfdisk1-2.37.4-150500.9.17.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgcc_s1-14.2.0+git10526-150000.1.6.1">
      <FullProductName ProductID="libgcc_s1-14.2.0+git10526-150000.1.6.1">libgcc_s1-14.2.0+git10526-150000.1.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgfortran5-14.2.0+git10526-150000.1.6.1">
      <FullProductName ProductID="libgfortran5-14.2.0+git10526-150000.1.6.1">libgfortran5-14.2.0+git10526-150000.1.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgio-2_0-0-2.70.5-150400.3.17.1">
      <FullProductName ProductID="libgio-2_0-0-2.70.5-150400.3.17.1">libgio-2_0-0-2.70.5-150400.3.17.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libglib-2_0-0-2.70.5-150400.3.17.1">
      <FullProductName ProductID="libglib-2_0-0-2.70.5-150400.3.17.1">libglib-2_0-0-2.70.5-150400.3.17.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgmodule-2_0-0-2.70.5-150400.3.17.1">
      <FullProductName ProductID="libgmodule-2_0-0-2.70.5-150400.3.17.1">libgmodule-2_0-0-2.70.5-150400.3.17.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgobject-2_0-0-2.70.5-150400.3.17.1">
      <FullProductName ProductID="libgobject-2_0-0-2.70.5-150400.3.17.1">libgobject-2_0-0-2.70.5-150400.3.17.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgomp1-14.2.0+git10526-150000.1.6.1">
      <FullProductName ProductID="libgomp1-14.2.0+git10526-150000.1.6.1">libgomp1-14.2.0+git10526-150000.1.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libitm1-14.2.0+git10526-150000.1.6.1">
      <FullProductName ProductID="libitm1-14.2.0+git10526-150000.1.6.1">libitm1-14.2.0+git10526-150000.1.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="liblsan0-14.2.0+git10526-150000.1.6.1">
      <FullProductName ProductID="liblsan0-14.2.0+git10526-150000.1.6.1">liblsan0-14.2.0+git10526-150000.1.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="liblvm2cmd2_03-2.03.22-150500.7.12.2">
      <FullProductName ProductID="liblvm2cmd2_03-2.03.22-150500.7.12.2">liblvm2cmd2_03-2.03.22-150500.7.12.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libmount1-2.37.4-150500.9.17.2">
      <FullProductName ProductID="libmount1-2.37.4-150500.9.17.2">libmount1-2.37.4-150500.9.17.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libncurses6-6.1-150000.5.27.1">
      <FullProductName ProductID="libncurses6-6.1-150000.5.27.1">libncurses6-6.1-150000.5.27.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libopenssl1_1-1.1.1l-150500.17.37.1">
      <FullProductName ProductID="libopenssl1_1-1.1.1l-150500.17.37.1">libopenssl1_1-1.1.1l-150500.17.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpcap1-1.10.1-150400.3.6.2">
      <FullProductName ProductID="libpcap1-1.10.1-150400.3.6.2">libpcap1-1.10.1-150400.3.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="libquadmath0-14.2.0+git10526-150000.1.6.1">
      <FullProductName ProductID="libquadmath0-14.2.0+git10526-150000.1.6.1">libquadmath0-14.2.0+git10526-150000.1.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libreadline7-7.0-150400.27.3.2">
      <FullProductName ProductID="libreadline7-7.0-150400.27.3.2">libreadline7-7.0-150400.27.3.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libruby2_5-2_5-2.5.9-150000.4.32.1">
      <FullProductName ProductID="libruby2_5-2_5-2.5.9-150000.4.32.1">libruby2_5-2_5-2.5.9-150000.4.32.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsmartcols1-2.37.4-150500.9.17.2">
      <FullProductName ProductID="libsmartcols1-2.37.4-150500.9.17.2">libsmartcols1-2.37.4-150500.9.17.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsodium23-1.0.18-150000.4.8.1">
      <FullProductName ProductID="libsodium23-1.0.18-150000.4.8.1">libsodium23-1.0.18-150000.4.8.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsolv-tools-0.7.31-150500.6.5.1">
      <FullProductName ProductID="libsolv-tools-0.7.31-150500.6.5.1">libsolv-tools-0.7.31-150500.6.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsolv-tools-base-0.7.31-150500.6.5.1">
      <FullProductName ProductID="libsolv-tools-base-0.7.31-150500.6.5.1">libsolv-tools-base-0.7.31-150500.6.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libstdc++6-14.2.0+git10526-150000.1.6.1">
      <FullProductName ProductID="libstdc++6-14.2.0+git10526-150000.1.6.1">libstdc++6-14.2.0+git10526-150000.1.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsuseconnect-1.13.0-150500.3.32.1">
      <FullProductName ProductID="libsuseconnect-1.13.0-150500.3.32.1">libsuseconnect-1.13.0-150500.3.32.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsystemd0-249.17-150400.8.46.1">
      <FullProductName ProductID="libsystemd0-249.17-150400.8.46.1">libsystemd0-249.17-150400.8.46.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libubsan1-14.2.0+git10526-150000.1.6.1">
      <FullProductName ProductID="libubsan1-14.2.0+git10526-150000.1.6.1">libubsan1-14.2.0+git10526-150000.1.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libudev1-249.17-150400.8.46.1">
      <FullProductName ProductID="libudev1-249.17-150400.8.46.1">libudev1-249.17-150400.8.46.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libuuid-devel-2.37.4-150500.9.17.2">
      <FullProductName ProductID="libuuid-devel-2.37.4-150500.9.17.2">libuuid-devel-2.37.4-150500.9.17.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libuuid1-2.37.4-150500.9.17.2">
      <FullProductName ProductID="libuuid1-2.37.4-150500.9.17.2">libuuid1-2.37.4-150500.9.17.2</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-150500.6.31.1">
      <FullProductName ProductID="libzypp-17.35.16-150500.6.31.1">libzypp-17.35.16-150500.6.31.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="login_defs-4.8.1-150400.10.24.1">
      <FullProductName ProductID="login_defs-4.8.1-150400.10.24.1">login_defs-4.8.1-150400.10.24.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="logrotate-3.18.1-150400.3.10.1">
      <FullProductName ProductID="logrotate-3.18.1-150400.3.10.1">logrotate-3.18.1-150400.3.10.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="lvm2-2.03.22-150500.7.12.2">
      <FullProductName ProductID="lvm2-2.03.22-150500.7.12.2">lvm2-2.03.22-150500.7.12.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="mailx-12.5-150000.3.5.1">
      <FullProductName ProductID="mailx-12.5-150000.3.5.1">mailx-12.5-150000.3.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ncurses-utils-6.1-150000.5.27.1">
      <FullProductName ProductID="ncurses-utils-6.1-150000.5.27.1">ncurses-utils-6.1-150000.5.27.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="nscd-2.31-150300.89.2">
      <FullProductName ProductID="nscd-2.31-150300.89.2">nscd-2.31-150300.89.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssl-1_1-1.1.1l-150500.17.37.1">
      <FullProductName ProductID="openssl-1_1-1.1.1l-150500.17.37.1">openssl-1_1-1.1.1l-150500.17.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="pam-config-1.1-150200.3.9.1">
      <FullProductName ProductID="pam-config-1.1-150200.3.9.1">pam-config-1.1-150200.3.9.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-150500.6.5.1">
      <FullProductName ProductID="python3-solv-0.7.31-150500.6.5.1">python3-solv-0.7.31-150500.6.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-zypp-plugin-0.6.4-150500.16.2.2">
      <FullProductName ProductID="python3-zypp-plugin-0.6.4-150500.16.2.2">python3-zypp-plugin-0.6.4-150500.16.2.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="rsyslog-8.2306.0-150400.5.33.1">
      <FullProductName ProductID="rsyslog-8.2306.0-150400.5.33.1">rsyslog-8.2306.0-150400.5.33.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ruby-solv-0.7.31-150500.6.5.1">
      <FullProductName ProductID="ruby-solv-0.7.31-150500.6.5.1">ruby-solv-0.7.31-150500.6.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ruby2.5-2.5.9-150000.4.32.1">
      <FullProductName ProductID="ruby2.5-2.5.9-150000.4.32.1">ruby2.5-2.5.9-150000.4.32.1</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="ruby2.5-stdlib-2.5.9-150000.4.32.1">
      <FullProductName ProductID="ruby2.5-stdlib-2.5.9-150000.4.32.1">ruby2.5-stdlib-2.5.9-150000.4.32.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.17.12+git.485.dd39ea0501e-150500.3.26.5">
      <FullProductName ProductID="samba-client-libs-4.17.12+git.485.dd39ea0501e-150500.3.26.5">samba-client-libs-4.17.12+git.485.dd39ea0501e-150500.3.26.5</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="shadow-4.8.1-150400.10.24.1">
      <FullProductName ProductID="shadow-4.8.1-150400.10.24.1">shadow-4.8.1-150400.10.24.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="shim-15.8-150300.4.23.1">
      <FullProductName ProductID="shim-15.8-150300.4.23.1">shim-15.8-150300.4.23.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="strace-5.14-150400.3.3.2">
      <FullProductName ProductID="strace-5.14-150400.3.3.2">strace-5.14-150400.3.3.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suse-build-key-12.0-150000.8.55.1">
      <FullProductName ProductID="suse-build-key-12.0-150000.8.55.1">suse-build-key-12.0-150000.8.55.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suseconnect-ng-1.13.0-150500.3.32.1">
      <FullProductName ProductID="suseconnect-ng-1.13.0-150500.3.32.1">suseconnect-ng-1.13.0-150500.3.32.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suseconnect-ruby-bindings-1.13.0-150500.3.32.1">
      <FullProductName ProductID="suseconnect-ruby-bindings-1.13.0-150500.3.32.1">suseconnect-ruby-bindings-1.13.0-150500.3.32.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-249.17-150400.8.46.1">
      <FullProductName ProductID="systemd-249.17-150400.8.46.1">systemd-249.17-150400.8.46.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-sysvinit-249.17-150400.8.46.1">
      <FullProductName ProductID="systemd-sysvinit-249.17-150400.8.46.1">systemd-sysvinit-249.17-150400.8.46.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="terminfo-6.1-150000.5.27.1">
      <FullProductName ProductID="terminfo-6.1-150000.5.27.1">terminfo-6.1-150000.5.27.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="terminfo-base-6.1-150000.5.27.1">
      <FullProductName ProductID="terminfo-base-6.1-150000.5.27.1">terminfo-base-6.1-150000.5.27.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="tuned-2.10.0-150500.23.3.1">
      <FullProductName ProductID="tuned-2.10.0-150500.23.3.1">tuned-2.10.0-150500.23.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="udev-249.17-150400.8.46.1">
      <FullProductName ProductID="udev-249.17-150400.8.46.1">udev-249.17-150400.8.46.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="util-linux-2.37.4-150500.9.17.2">
      <FullProductName ProductID="util-linux-2.37.4-150500.9.17.2">util-linux-2.37.4-150500.9.17.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="util-linux-systemd-2.37.4-150500.9.17.2">
      <FullProductName ProductID="util-linux-systemd-2.37.4-150500.9.17.2">util-linux-systemd-2.37.4-150500.9.17.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="vim-9.1.0836-150500.20.15.1">
      <FullProductName ProductID="vim-9.1.0836-150500.20.15.1">vim-9.1.0836-150500.20.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="vim-data-common-9.1.0836-150500.20.15.1">
      <FullProductName ProductID="vim-data-common-9.1.0836-150500.20.15.1">vim-data-common-9.1.0836-150500.20.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="wget-1.20.3-150000.3.26.1">
      <FullProductName ProductID="wget-1.20.3-150000.3.26.1">wget-1.20.3-150000.3.26.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="wicked-0.6.77-150500.3.39.1">
      <FullProductName ProductID="wicked-0.6.77-150500.3.39.1">wicked-0.6.77-150500.3.39.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="wicked-service-0.6.77-150500.3.39.1">
      <FullProductName ProductID="wicked-service-0.6.77-150500.3.39.1">wicked-service-0.6.77-150500.3.39.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="xen-libs-4.17.5_06-150500.3.42.1">
      <FullProductName ProductID="xen-libs-4.17.5_06-150500.3.42.1">xen-libs-4.17.5_06-150500.3.42.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-network-4.5.25-150500.3.17.2">
      <FullProductName ProductID="yast2-network-4.5.25-150500.3.17.2">yast2-network-4.5.25-150500.3.17.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="zypper-1.14.78-150500.6.14.1">
      <FullProductName ProductID="zypper-1.14.78-150500.6.14.1">zypper-1.14.78-150500.6.14.1</FullProductName>
    </Branch>
    <Relationship ProductReference="aaa_base-84.87+git20180409.04c9dae-150300.10.23.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-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/sle-hpc-15-sp5-byos-v20250110-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/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-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/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="bash-4.4-150400.27.3.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:bash-4.4-150400.27.3.2">bash-4.4-150400.27.3.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="bash-sh-4.4-150400.27.3.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:bash-sh-4.4-150400.27.3.2">bash-sh-4.4-150400.27.3.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="binutils-2.43-150100.7.52.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:binutils-2.43-150100.7.52.1">binutils-2.43-150100.7.52.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cloud-regionsrv-client-10.3.7-150300.13.14.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:cloud-regionsrv-client-10.3.7-150300.13.14.1">cloud-regionsrv-client-10.3.7-150300.13.14.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.14.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.14.1">cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.14.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cpupower-5.14-150500.9.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:cpupower-5.14-150500.9.6.2">cpupower-5.14-150500.9.6.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="crypto-policies-20210917.c9d86d1-150400.3.8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:crypto-policies-20210917.c9d86d1-150400.3.8.1">crypto-policies-20210917.c9d86d1-150400.3.8.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="curl-8.0.1-150400.5.59.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:curl-8.0.1-150400.5.59.1">curl-8.0.1-150400.5.59.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="deltarpm-3.6.5-150000.5.6.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:deltarpm-3.6.5-150000.5.6.3">deltarpm-3.6.5-150000.5.6.3 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="device-mapper-2.03.22_1.02.196-150500.7.12.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:device-mapper-2.03.22_1.02.196-150500.7.12.2">device-mapper-2.03.22_1.02.196-150500.7.12.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="docker-26.1.5_ce-150000.212.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-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/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="dracut-055+suse.396.g701c6212-150500.3.29.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:dracut-055+suse.396.g701c6212-150500.3.29.2">dracut-055+suse.396.g701c6212-150500.3.29.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="e2fsprogs-1.46.4-150400.3.9.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:e2fsprogs-1.46.4-150400.3.9.2">e2fsprogs-1.46.4-150400.3.9.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glib2-tools-2.70.5-150400.3.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:glib2-tools-2.70.5-150400.3.17.1">glib2-tools-2.70.5-150400.3.17.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-2.31-150300.89.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:glibc-2.31-150300.89.2">glibc-2.31-150300.89.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-32bit-2.31-150300.89.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:glibc-32bit-2.31-150300.89.1">glibc-32bit-2.31-150300.89.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-devel-2.31-150300.89.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:glibc-devel-2.31-150300.89.2">glibc-devel-2.31-150300.89.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-i18ndata-2.31-150300.89.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:glibc-i18ndata-2.31-150300.89.2">glibc-i18ndata-2.31-150300.89.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-locale-2.31-150300.89.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:glibc-locale-2.31-150300.89.2">glibc-locale-2.31-150300.89.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-locale-base-2.31-150300.89.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:glibc-locale-base-2.31-150300.89.2">glibc-locale-base-2.31-150300.89.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-guest-agent-20241011.01-150000.1.51.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-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/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-guest-configs-20241121.00-150400.13.14.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:google-guest-configs-20241121.00-150400.13.14.1">google-guest-configs-20241121.00-150400.13.14.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-osconfig-agent-20240926.03-150000.1.38.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-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/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-2.06-150500.29.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:grub2-2.06-150500.29.37.1">grub2-2.06-150500.29.37.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-i386-pc-2.06-150500.29.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:grub2-i386-pc-2.06-150500.29.37.1">grub2-i386-pc-2.06-150500.29.37.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-x86_64-efi-2.06-150500.29.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:grub2-x86_64-efi-2.06-150500.29.37.1">grub2-x86_64-efi-2.06-150500.29.37.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kernel-default-5.14.21-150500.55.88.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:kernel-default-5.14.21-150500.55.88.1">kernel-default-5.14.21-150500.55.88.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libatomic1-14.2.0+git10526-150000.1.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libatomic1-14.2.0+git10526-150000.1.6.1">libatomic1-14.2.0+git10526-150000.1.6.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libavahi-client3-0.8-150400.7.20.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libavahi-client3-0.8-150400.7.20.1">libavahi-client3-0.8-150400.7.20.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libavahi-common3-0.8-150400.7.20.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libavahi-common3-0.8-150400.7.20.1">libavahi-common3-0.8-150400.7.20.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libblkid1-2.37.4-150500.9.17.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libblkid1-2.37.4-150500.9.17.2">libblkid1-2.37.4-150500.9.17.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libcom_err2-1.46.4-150400.3.9.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libcom_err2-1.46.4-150400.3.9.2">libcom_err2-1.46.4-150400.3.9.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libcpupower0-5.14-150500.9.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libcpupower0-5.14-150500.9.6.2">libcpupower0-5.14-150500.9.6.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libctf-nobfd0-2.43-150100.7.52.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-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/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libctf0-2.43-150100.7.52.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libctf0-2.43-150100.7.52.1">libctf0-2.43-150100.7.52.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libcurl4-8.0.1-150400.5.59.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libcurl4-8.0.1-150400.5.59.1">libcurl4-8.0.1-150400.5.59.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libdevmapper-event1_03-2.03.22_1.02.196-150500.7.12.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libdevmapper-event1_03-2.03.22_1.02.196-150500.7.12.2">libdevmapper-event1_03-2.03.22_1.02.196-150500.7.12.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libdevmapper1_03-2.03.22_1.02.196-150500.7.12.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libdevmapper1_03-2.03.22_1.02.196-150500.7.12.2">libdevmapper1_03-2.03.22_1.02.196-150500.7.12.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libexpat1-2.4.4-150400.3.25.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-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/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libext2fs2-1.46.4-150400.3.9.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libext2fs2-1.46.4-150400.3.9.2">libext2fs2-1.46.4-150400.3.9.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libfdisk1-2.37.4-150500.9.17.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libfdisk1-2.37.4-150500.9.17.2">libfdisk1-2.37.4-150500.9.17.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgcc_s1-14.2.0+git10526-150000.1.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libgcc_s1-14.2.0+git10526-150000.1.6.1">libgcc_s1-14.2.0+git10526-150000.1.6.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgfortran5-14.2.0+git10526-150000.1.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libgfortran5-14.2.0+git10526-150000.1.6.1">libgfortran5-14.2.0+git10526-150000.1.6.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgio-2_0-0-2.70.5-150400.3.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libgio-2_0-0-2.70.5-150400.3.17.1">libgio-2_0-0-2.70.5-150400.3.17.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libglib-2_0-0-2.70.5-150400.3.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libglib-2_0-0-2.70.5-150400.3.17.1">libglib-2_0-0-2.70.5-150400.3.17.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgmodule-2_0-0-2.70.5-150400.3.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libgmodule-2_0-0-2.70.5-150400.3.17.1">libgmodule-2_0-0-2.70.5-150400.3.17.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgobject-2_0-0-2.70.5-150400.3.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libgobject-2_0-0-2.70.5-150400.3.17.1">libgobject-2_0-0-2.70.5-150400.3.17.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgomp1-14.2.0+git10526-150000.1.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libgomp1-14.2.0+git10526-150000.1.6.1">libgomp1-14.2.0+git10526-150000.1.6.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libitm1-14.2.0+git10526-150000.1.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libitm1-14.2.0+git10526-150000.1.6.1">libitm1-14.2.0+git10526-150000.1.6.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="liblsan0-14.2.0+git10526-150000.1.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:liblsan0-14.2.0+git10526-150000.1.6.1">liblsan0-14.2.0+git10526-150000.1.6.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="liblvm2cmd2_03-2.03.22-150500.7.12.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:liblvm2cmd2_03-2.03.22-150500.7.12.2">liblvm2cmd2_03-2.03.22-150500.7.12.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libmount1-2.37.4-150500.9.17.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libmount1-2.37.4-150500.9.17.2">libmount1-2.37.4-150500.9.17.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libncurses6-6.1-150000.5.27.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libncurses6-6.1-150000.5.27.1">libncurses6-6.1-150000.5.27.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libopenssl1_1-1.1.1l-150500.17.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libopenssl1_1-1.1.1l-150500.17.37.1">libopenssl1_1-1.1.1l-150500.17.37.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpcap1-1.10.1-150400.3.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libpcap1-1.10.1-150400.3.6.2">libpcap1-1.10.1-150400.3.6.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-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/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-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/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libquadmath0-14.2.0+git10526-150000.1.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libquadmath0-14.2.0+git10526-150000.1.6.1">libquadmath0-14.2.0+git10526-150000.1.6.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libreadline7-7.0-150400.27.3.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libreadline7-7.0-150400.27.3.2">libreadline7-7.0-150400.27.3.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libruby2_5-2_5-2.5.9-150000.4.32.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libruby2_5-2_5-2.5.9-150000.4.32.1">libruby2_5-2_5-2.5.9-150000.4.32.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsmartcols1-2.37.4-150500.9.17.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libsmartcols1-2.37.4-150500.9.17.2">libsmartcols1-2.37.4-150500.9.17.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsodium23-1.0.18-150000.4.8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libsodium23-1.0.18-150000.4.8.1">libsodium23-1.0.18-150000.4.8.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsolv-tools-0.7.31-150500.6.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libsolv-tools-0.7.31-150500.6.5.1">libsolv-tools-0.7.31-150500.6.5.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsolv-tools-base-0.7.31-150500.6.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libsolv-tools-base-0.7.31-150500.6.5.1">libsolv-tools-base-0.7.31-150500.6.5.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libstdc++6-14.2.0+git10526-150000.1.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libstdc++6-14.2.0+git10526-150000.1.6.1">libstdc++6-14.2.0+git10526-150000.1.6.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsuseconnect-1.13.0-150500.3.32.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libsuseconnect-1.13.0-150500.3.32.1">libsuseconnect-1.13.0-150500.3.32.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsystemd0-249.17-150400.8.46.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libsystemd0-249.17-150400.8.46.1">libsystemd0-249.17-150400.8.46.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libubsan1-14.2.0+git10526-150000.1.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libubsan1-14.2.0+git10526-150000.1.6.1">libubsan1-14.2.0+git10526-150000.1.6.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libudev1-249.17-150400.8.46.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libudev1-249.17-150400.8.46.1">libudev1-249.17-150400.8.46.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libuuid-devel-2.37.4-150500.9.17.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libuuid-devel-2.37.4-150500.9.17.2">libuuid-devel-2.37.4-150500.9.17.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libuuid1-2.37.4-150500.9.17.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libuuid1-2.37.4-150500.9.17.2">libuuid1-2.37.4-150500.9.17.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libuv1-1.44.2-150500.3.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-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/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libzypp-17.35.16-150500.6.31.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:libzypp-17.35.16-150500.6.31.1">libzypp-17.35.16-150500.6.31.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="login_defs-4.8.1-150400.10.24.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:login_defs-4.8.1-150400.10.24.1">login_defs-4.8.1-150400.10.24.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="logrotate-3.18.1-150400.3.10.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:logrotate-3.18.1-150400.3.10.1">logrotate-3.18.1-150400.3.10.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="lvm2-2.03.22-150500.7.12.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:lvm2-2.03.22-150500.7.12.2">lvm2-2.03.22-150500.7.12.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="mailx-12.5-150000.3.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:mailx-12.5-150000.3.5.1">mailx-12.5-150000.3.5.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ncurses-utils-6.1-150000.5.27.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:ncurses-utils-6.1-150000.5.27.1">ncurses-utils-6.1-150000.5.27.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="nscd-2.31-150300.89.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:nscd-2.31-150300.89.2">nscd-2.31-150300.89.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssl-1_1-1.1.1l-150500.17.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:openssl-1_1-1.1.1l-150500.17.37.1">openssl-1_1-1.1.1l-150500.17.37.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="pam-config-1.1-150200.3.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:pam-config-1.1-150200.3.9.1">pam-config-1.1-150200.3.9.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-3.6.15-150300.10.78.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-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/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-Jinja2-2.10.1-150000.3.18.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-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/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-base-3.6.15-150300.10.78.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-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/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-curses-3.6.15-150300.10.78.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-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/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-salt-3006.0-150500.4.44.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-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/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-solv-0.7.31-150500.6.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:python3-solv-0.7.31-150500.6.5.1">python3-solv-0.7.31-150500.6.5.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-zypp-plugin-0.6.4-150500.16.2.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:python3-zypp-plugin-0.6.4-150500.16.2.2">python3-zypp-plugin-0.6.4-150500.16.2.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="rsyslog-8.2306.0-150400.5.33.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:rsyslog-8.2306.0-150400.5.33.1">rsyslog-8.2306.0-150400.5.33.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ruby-solv-0.7.31-150500.6.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:ruby-solv-0.7.31-150500.6.5.1">ruby-solv-0.7.31-150500.6.5.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ruby2.5-2.5.9-150000.4.32.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:ruby2.5-2.5.9-150000.4.32.1">ruby2.5-2.5.9-150000.4.32.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-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/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-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/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ruby2.5-stdlib-2.5.9-150000.4.32.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:ruby2.5-stdlib-2.5.9-150000.4.32.1">ruby2.5-stdlib-2.5.9-150000.4.32.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="salt-3006.0-150500.4.44.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:salt-3006.0-150500.4.44.2">salt-3006.0-150500.4.44.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="salt-minion-3006.0-150500.4.44.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-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/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="samba-client-libs-4.17.12+git.485.dd39ea0501e-150500.3.26.5" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:samba-client-libs-4.17.12+git.485.dd39ea0501e-150500.3.26.5">samba-client-libs-4.17.12+git.485.dd39ea0501e-150500.3.26.5 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="shadow-4.8.1-150400.10.24.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:shadow-4.8.1-150400.10.24.1">shadow-4.8.1-150400.10.24.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="shim-15.8-150300.4.23.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:shim-15.8-150300.4.23.1">shim-15.8-150300.4.23.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="strace-5.14-150400.3.3.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:strace-5.14-150400.3.3.2">strace-5.14-150400.3.3.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suse-build-key-12.0-150000.8.55.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:suse-build-key-12.0-150000.8.55.1">suse-build-key-12.0-150000.8.55.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suseconnect-ng-1.13.0-150500.3.32.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:suseconnect-ng-1.13.0-150500.3.32.1">suseconnect-ng-1.13.0-150500.3.32.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suseconnect-ruby-bindings-1.13.0-150500.3.32.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:suseconnect-ruby-bindings-1.13.0-150500.3.32.1">suseconnect-ruby-bindings-1.13.0-150500.3.32.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-249.17-150400.8.46.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:systemd-249.17-150400.8.46.1">systemd-249.17-150400.8.46.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-sysvinit-249.17-150400.8.46.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:systemd-sysvinit-249.17-150400.8.46.1">systemd-sysvinit-249.17-150400.8.46.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="terminfo-6.1-150000.5.27.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:terminfo-6.1-150000.5.27.1">terminfo-6.1-150000.5.27.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="terminfo-base-6.1-150000.5.27.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:terminfo-base-6.1-150000.5.27.1">terminfo-base-6.1-150000.5.27.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="tuned-2.10.0-150500.23.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:tuned-2.10.0-150500.23.3.1">tuned-2.10.0-150500.23.3.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="udev-249.17-150400.8.46.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:udev-249.17-150400.8.46.1">udev-249.17-150400.8.46.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="util-linux-2.37.4-150500.9.17.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:util-linux-2.37.4-150500.9.17.2">util-linux-2.37.4-150500.9.17.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="util-linux-systemd-2.37.4-150500.9.17.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:util-linux-systemd-2.37.4-150500.9.17.2">util-linux-systemd-2.37.4-150500.9.17.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-9.1.0836-150500.20.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:vim-9.1.0836-150500.20.15.1">vim-9.1.0836-150500.20.15.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-data-common-9.1.0836-150500.20.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:vim-data-common-9.1.0836-150500.20.15.1">vim-data-common-9.1.0836-150500.20.15.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="wget-1.20.3-150000.3.26.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:wget-1.20.3-150000.3.26.1">wget-1.20.3-150000.3.26.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="wicked-0.6.77-150500.3.39.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:wicked-0.6.77-150500.3.39.1">wicked-0.6.77-150500.3.39.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="wicked-service-0.6.77-150500.3.39.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:wicked-service-0.6.77-150500.3.39.1">wicked-service-0.6.77-150500.3.39.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="xen-libs-4.17.5_06-150500.3.42.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:xen-libs-4.17.5_06-150500.3.42.1">xen-libs-4.17.5_06-150500.3.42.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-network-4.5.25-150500.3.17.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:yast2-network-4.5.25-150500.3.17.2">yast2-network-4.5.25-150500.3.17.2 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="zypper-1.14.78-150500.6.14.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-x86-64:zypper-1.14.78-150500.6.14.1">zypper-1.14.78-150500.6.14.1 as a component of Public Cloud Image google/sle-hpc-15-sp5-byos-v20250110-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">An out-of-bounds (OOB) memory access flaw was found in the Linux kernel's eBPF due to an Improper Input Validation. This flaw allows a local attacker with a special privilege to crash the system or leak internal information.</Note>
    </Notes>
    <CVE>CVE-2021-4204</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-zynq-qspi: Fix a NULL pointer dereference in zynq_qspi_exec_mem_op()

In zynq_qspi_exec_mem_op(), kzalloc() is directly used in memset(),
which could lead to a NULL pointer dereference on failure of
kzalloc().

Fix this bug by adding a check of tmpbuf.

This bug was found by a static analyzer. The analysis employs
differential checking to identify inconsistent security operations
(e.g., checks or kfrees) between two code paths and confirms that the
inconsistent operations are not recovered in the current function or
the callers, so they constitute bugs.

Note that, as a bug found by static analysis, it can be a false
positive or hard to trigger. Multiple researchers have cross-reviewed
the bug.

Builds with CONFIG_SPI_ZYNQ_QSPI=m show no new warnings,
and our static analyzer no longer warns about this code.</Note>
    </Notes>
    <CVE>CVE-2021-4441</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix use-after-free in nft_set_catchall_destroy()

We need to use list_for_each_entry_safe() iterator
because we can not access @catchall after kfree_rcu() call.

syzbot reported:

BUG: KASAN: use-after-free in nft_set_catchall_destroy net/netfilter/nf_tables_api.c:4486 [inline]
BUG: KASAN: use-after-free in nft_set_destroy net/netfilter/nf_tables_api.c:4504 [inline]
BUG: KASAN: use-after-free in nft_set_destroy+0x3fd/0x4f0 net/netfilter/nf_tables_api.c:4493
Read of size 8 at addr ffff8880716e5b80 by task syz-executor.3/8871

CPU: 1 PID: 8871 Comm: syz-executor.3 Not tainted 5.16.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
 print_address_description.constprop.0.cold+0x8d/0x2ed mm/kasan/report.c:247
 __kasan_report mm/kasan/report.c:433 [inline]
 kasan_report.cold+0x83/0xdf mm/kasan/report.c:450
 nft_set_catchall_destroy net/netfilter/nf_tables_api.c:4486 [inline]
 nft_set_destroy net/netfilter/nf_tables_api.c:4504 [inline]
 nft_set_destroy+0x3fd/0x4f0 net/netfilter/nf_tables_api.c:4493
 __nft_release_table+0x79f/0xcd0 net/netfilter/nf_tables_api.c:9626
 nft_rcv_nl_event+0x4f8/0x670 net/netfilter/nf_tables_api.c:9688
 notifier_call_chain+0xb5/0x200 kernel/notifier.c:83
 blocking_notifier_call_chain kernel/notifier.c:318 [inline]
 blocking_notifier_call_chain+0x67/0x90 kernel/notifier.c:306
 netlink_release+0xcb6/0x1dd0 net/netlink/af_netlink.c:788
 __sock_release+0xcd/0x280 net/socket.c:649
 sock_close+0x18/0x20 net/socket.c:1314
 __fput+0x286/0x9f0 fs/file_table.c:280
 task_work_run+0xdd/0x1a0 kernel/task_work.c:164
 tracehook_notify_resume include/linux/tracehook.h:189 [inline]
 exit_to_user_mode_loop kernel/entry/common.c:175 [inline]
 exit_to_user_mode_prepare+0x27e/0x290 kernel/entry/common.c:207
 __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline]
 syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:300
 do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f75fbf28adb
Code: 0f 05 48 3d 00 f0 ff ff 77 45 c3 0f 1f 40 00 48 83 ec 18 89 7c 24 0c e8 63 fc ff 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 fc ff ff 8b 44
RSP: 002b:00007ffd8da7ec10 EFLAGS: 00000293 ORIG_RAX: 0000000000000003
RAX: 0000000000000000 RBX: 0000000000000004 RCX: 00007f75fbf28adb
RDX: 00007f75fc08e828 RSI: ffffffffffffffff RDI: 0000000000000003
RBP: 00007f75fc08a960 R08: 0000000000000000 R09: 00007f75fc08e830
R10: 00007ffd8da7ed10 R11: 0000000000000293 R12: 00000000002067c3
R13: 00007ffd8da7ed10 R14: 00007f75fc088f60 R15: 0000000000000032
 &lt;/TASK&gt;

Allocated by task 8886:
 kasan_save_stack+0x1e/0x50 mm/kasan/common.c:38
 kasan_set_track mm/kasan/common.c:46 [inline]
 set_alloc_info mm/kasan/common.c:434 [inline]
 ____kasan_kmalloc mm/kasan/common.c:513 [inline]
 ____kasan_kmalloc mm/kasan/common.c:472 [inline]
 __kasan_kmalloc+0xa6/0xd0 mm/kasan/common.c:522
 kasan_kmalloc include/linux/kasan.h:269 [inline]
 kmem_cache_alloc_trace+0x1ea/0x4a0 mm/slab.c:3575
 kmalloc include/linux/slab.h:590 [inline]
 nft_setelem_catchall_insert net/netfilter/nf_tables_api.c:5544 [inline]
 nft_setelem_insert net/netfilter/nf_tables_api.c:5562 [inline]
 nft_add_set_elem+0x232e/0x2f40 net/netfilter/nf_tables_api.c:5936
 nf_tables_newsetelem+0x6ff/0xbb0 net/netfilter/nf_tables_api.c:6032
 nfnetlink_rcv_batch+0x1710/0x25f0 net/netfilter/nfnetlink.c:513
 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:634 [inline]
 nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:652
 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
 netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1345
 netlink_sendmsg+0x904/0xdf0 net/netlink/af_netlink.c:1921
 sock_sendmsg_nosec net/
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47106</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mdio: fix memory leak

Syzbot reported memory leak in MDIO bus interface, the problem was in
wrong state logic.

MDIOBUS_ALLOCATED indicates 2 states:
	1. Bus is only allocated
	2. Bus allocated and __mdiobus_register() fails, but
	   device_register() was called

In case of device_register() has been called we should call put_device()
to correctly free the memory allocated for this device, but mdiobus_free()
calls just kfree(dev) in case of MDIOBUS_ALLOCATED state

To avoid this behaviour we need to set bus-&gt;state to MDIOBUS_UNREGISTERED
_before_ calling device_register(), because put_device() should be
called even in case of device_register() failure.</Note>
    </Notes>
    <CVE>CVE-2021-47416</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

ethtool: do not perform operations on net devices being unregistered

There is a short period between a net device starts to be unregistered
and when it is actually gone. In that time frame ethtool operations
could still be performed, which might end up in unwanted or undefined
behaviours[1].

Do not allow ethtool operations after a net device starts its
unregistration. This patch targets the netlink part as the ioctl one
isn't affected: the reference to the net device is taken and the
operation is executed within an rtnl lock section and the net device
won't be found after unregister.

[1] For example adding Tx queues after unregister ends up in NULL
    pointer exceptions and UaFs, such as:

      BUG: KASAN: use-after-free in kobject_get+0x14/0x90
      Read of size 1 at addr ffff88801961248c by task ethtool/755

      CPU: 0 PID: 755 Comm: ethtool Not tainted 5.15.0-rc6+ #778
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/014
      Call Trace:
       dump_stack_lvl+0x57/0x72
       print_address_description.constprop.0+0x1f/0x140
       kasan_report.cold+0x7f/0x11b
       kobject_get+0x14/0x90
       kobject_add_internal+0x3d1/0x450
       kobject_init_and_add+0xba/0xf0
       netdev_queue_update_kobjects+0xcf/0x200
       netif_set_real_num_tx_queues+0xb4/0x310
       veth_set_channels+0x1c3/0x550
       ethnl_set_channels+0x524/0x610</Note>
    </Notes>
    <CVE>CVE-2021-47517</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: kms: Add missing drm_crtc_commit_put

Commit 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a
commit") introduced a global state for the HVS, with each FIFO storing
the current CRTC commit so that we can properly synchronize commits.

However, the refcounting was off and we thus ended up leaking the
drm_crtc_commit structure every commit. Add a drm_crtc_commit_put to
prevent the leakage.</Note>
    </Notes>
    <CVE>CVE-2021-47534</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix memory leak in fib6_rule_suppress

The kernel leaks memory when a `fib` rule is present in IPv6 nftables
firewall rules and a suppress_prefix rule is present in the IPv6 routing
rules (used by certain tools such as wg-quick). In such scenarios, every
incoming packet will leak an allocation in `ip6_dst_cache` slab cache.

After some hours of `bpftrace`-ing and source code reading, I tracked
down the issue to ca7a03c41753 ("ipv6: do not free rt if
FIB_LOOKUP_NOREF is set on suppress rule").

The problem with that change is that the generic `args-&gt;flags` always have
`FIB_LOOKUP_NOREF` set[1][2] but the IPv6-specific flag
`RT6_LOOKUP_F_DST_NOREF` might not be, leading to `fib6_rule_suppress` not
decreasing the refcount when needed.

How to reproduce:
 - Add the following nftables rule to a prerouting chain:
     meta nfproto ipv6 fib saddr . mark . iif oif missing drop
   This can be done with:
     sudo nft create table inet test
     sudo nft create chain inet test test_chain '{ type filter hook prerouting priority filter + 10; policy accept; }'
     sudo nft add rule inet test test_chain meta nfproto ipv6 fib saddr . mark . iif oif missing drop
 - Run:
     sudo ip -6 rule add table main suppress_prefixlength 0
 - Watch `sudo slabtop -o | grep ip6_dst_cache` to see memory usage increase
   with every incoming ipv6 packet.

This patch exposes the protocol-specific flags to the protocol
specific `suppress` function, and check the protocol-specific `flags`
argument for RT6_LOOKUP_F_DST_NOREF instead of the generic
FIB_LOOKUP_NOREF when decreasing the refcount, like this.

[1]: https://github.com/torvalds/linux/blob/ca7a03c4175366a92cee0ccc4fec0038c3266e26/net/ipv6/fib6_rules.c#L71
[2]: https://github.com/torvalds/linux/blob/ca7a03c4175366a92cee0ccc4fec0038c3266e26/net/ipv6/fib6_rules.c#L99</Note>
    </Notes>
    <CVE>CVE-2021-47546</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

mptcp: never allow the PM to close a listener subflow

Currently, when deleting an endpoint the netlink PM treverses
all the local MPTCP sockets, regardless of their status.

If an MPTCP listener socket is bound to the IP matching the
delete endpoint, the listener TCP socket will be closed.
That is unexpected, the PM should only affect data subflows.

Additionally, syzbot was able to trigger a NULL ptr dereference
due to the above:

general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
CPU: 1 PID: 6550 Comm: syz-executor122 Not tainted 5.16.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:__lock_acquire+0xd7d/0x54a0 kernel/locking/lockdep.c:4897
Code: 0f 0e 41 be 01 00 00 00 0f 86 c8 00 00 00 89 05 69 cc 0f 0e e9 bd 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 &lt;80&gt; 3c 02 00 0f 85 f3 2f 00 00 48 81 3b 20 75 17 8f 0f 84 52 f3 ff
RSP: 0018:ffffc90001f2f818 EFLAGS: 00010016
RAX: dffffc0000000000 RBX: 0000000000000018 RCX: 0000000000000000
RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000001
RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000000 R11: 000000000000000a R12: 0000000000000000
R13: ffff88801b98d700 R14: 0000000000000000 R15: 0000000000000001
FS:  00007f177cd3d700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f177cd1b268 CR3: 000000001dd55000 CR4: 0000000000350ee0
Call Trace:
 &lt;TASK&gt;
 lock_acquire kernel/locking/lockdep.c:5637 [inline]
 lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5602
 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
 _raw_spin_lock_irqsave+0x39/0x50 kernel/locking/spinlock.c:162
 finish_wait+0xc0/0x270 kernel/sched/wait.c:400
 inet_csk_wait_for_connect net/ipv4/inet_connection_sock.c:464 [inline]
 inet_csk_accept+0x7de/0x9d0 net/ipv4/inet_connection_sock.c:497
 mptcp_accept+0xe5/0x500 net/mptcp/protocol.c:2865
 inet_accept+0xe4/0x7b0 net/ipv4/af_inet.c:739
 mptcp_stream_accept+0x2e7/0x10e0 net/mptcp/protocol.c:3345
 do_accept+0x382/0x510 net/socket.c:1773
 __sys_accept4_file+0x7e/0xe0 net/socket.c:1816
 __sys_accept4+0xb0/0x100 net/socket.c:1846
 __do_sys_accept net/socket.c:1864 [inline]
 __se_sys_accept net/socket.c:1861 [inline]
 __x64_sys_accept+0x71/0xb0 net/socket.c:1861
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f177cd8b8e9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 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:00007f177cd3d308 EFLAGS: 00000246 ORIG_RAX: 000000000000002b
RAX: ffffffffffffffda RBX: 00007f177ce13408 RCX: 00007f177cd8b8e9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
RBP: 00007f177ce13400 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f177ce1340c
R13: 00007f177cde1004 R14: 6d705f706374706d R15: 0000000000022000
 &lt;/TASK&gt;

Fix the issue explicitly skipping MPTCP socket in TCP_LISTEN
status.</Note>
    </Notes>
    <CVE>CVE-2021-47594</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 unrestricted eBPF usage by the BPF_BTF_LOAD, leading to a possible out-of-bounds memory write in the Linux kernel's BPF subsystem due to the way a user loads BTF. This flaw allows a local user to crash or escalate their privileges on the system.</Note>
    </Notes>
    <CVE>CVE-2022-0500</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>7.2</BaseScore>
        <Vector>AV:L/AC:L/Au:N/C:C/I:C/A:C</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability 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 vulnerability classified as problematic has been found in Linux Kernel. This affects the function fib_nh_match of the file net/ipv4/fib_semantics.c of the component IPv4 Handler. The manipulation leads to out-of-bounds read. It is possible to initiate the attack remotely. It is recommended to apply a patch to fix this issue. The identifier VDB-210357 was assigned to this vulnerability.</Note>
    </Notes>
    <CVE>CVE-2022-3435</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 use-after-free(UAF) vulnerability was found in function 'vmw_execbuf_tie_context' in drivers/gpu/vmxgfx/vmxgfx_execbuf.c in Linux kernel's vmwgfx driver with device file '/dev/dri/renderD128 (or Dxxx)'. This flaw allows a local attacker with a user account on the system to gain privilege, causing a denial of service(DoS).</Note>
    </Notes>
    <CVE>CVE-2022-40133</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 use-after-free flaw caused by a race among the superblock operations in the gadgetfs Linux driver was found. It could be triggered by yanking out a device that is running the gadgetfs side.</Note>
    </Notes>
    <CVE>CVE-2022-4382</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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 the Linux kernel through 6.0.10. l2cap_config_req in net/bluetooth/l2cap_core.c has an integer wraparound via L2CAP_CONF_REQ packets.</Note>
    </Notes>
    <CVE>CVE-2022-45934</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: deny offload of tc-based TSN features on VF interfaces

TSN features on the ENETC (taprio, cbs, gate, police) are configured
through a mix of command BD ring messages and port registers:
enetc_port_rd(), enetc_port_wr().

Port registers are a region of the ENETC memory map which are only
accessible from the PCIe Physical Function. They are not accessible from
the Virtual Functions.

Moreover, attempting to access these registers crashes the kernel:

$ echo 1 &gt; /sys/bus/pci/devices/0000\:00\:00.0/sriov_numvfs
pci 0000:00:01.0: [1957:ef00] type 00 class 0x020001
fsl_enetc_vf 0000:00:01.0: Adding to iommu group 15
fsl_enetc_vf 0000:00:01.0: enabling device (0000 -&gt; 0002)
fsl_enetc_vf 0000:00:01.0 eno0vf0: renamed from eth0
$ tc qdisc replace dev eno0vf0 root taprio num_tc 8 map 0 1 2 3 4 5 6 7 \
	queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \
	sched-entry S 0x7f 900000 sched-entry S 0x80 100000 flags 0x2
Unable to handle kernel paging request at virtual address ffff800009551a08
Internal error: Oops: 96000007 [#1] PREEMPT SMP
pc : enetc_setup_tc_taprio+0x170/0x47c
lr : enetc_setup_tc_taprio+0x16c/0x47c
Call trace:
 enetc_setup_tc_taprio+0x170/0x47c
 enetc_setup_tc+0x38/0x2dc
 taprio_change+0x43c/0x970
 taprio_init+0x188/0x1e0
 qdisc_create+0x114/0x470
 tc_modify_qdisc+0x1fc/0x6c0
 rtnetlink_rcv_msg+0x12c/0x390

Split enetc_setup_tc() into separate functions for the PF and for the
VF drivers. Also remove enetc_qos.o from being included into
enetc-vf.ko, since it serves absolutely no purpose there.</Note>
    </Notes>
    <CVE>CVE-2022-48645</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix pcluster use-after-free on UP platforms

During stress testing with CONFIG_SMP disabled, KASAN reports as below:

==================================================================
BUG: KASAN: use-after-free in __mutex_lock+0xe5/0xc30
Read of size 8 at addr ffff8881094223f8 by task stress/7789

CPU: 0 PID: 7789 Comm: stress Not tainted 6.0.0-rc1-00002-g0d53d2e882f9 #3
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
Call Trace:
 &lt;TASK&gt;
..
 __mutex_lock+0xe5/0xc30
..
 z_erofs_do_read_page+0x8ce/0x1560
..
 z_erofs_readahead+0x31c/0x580
..
Freed by task 7787
 kasan_save_stack+0x1e/0x40
 kasan_set_track+0x20/0x30
 kasan_set_free_info+0x20/0x40
 __kasan_slab_free+0x10c/0x190
 kmem_cache_free+0xed/0x380
 rcu_core+0x3d5/0xc90
 __do_softirq+0x12d/0x389

Last potentially related work creation:
 kasan_save_stack+0x1e/0x40
 __kasan_record_aux_stack+0x97/0xb0
 call_rcu+0x3d/0x3f0
 erofs_shrink_workstation+0x11f/0x210
 erofs_shrink_scan+0xdc/0x170
 shrink_slab.constprop.0+0x296/0x530
 drop_slab+0x1c/0x70
 drop_caches_sysctl_handler+0x70/0x80
 proc_sys_call_handler+0x20a/0x2f0
 vfs_write+0x555/0x6c0
 ksys_write+0xbe/0x160
 do_syscall_64+0x3b/0x90

The root cause is that erofs_workgroup_unfreeze() doesn't reset to
orig_val thus it causes a race that the pcluster reuses unexpectedly
before freeing.

Since UP platforms are quite rare now, such path becomes unnecessary.
Let's drop such specific-designed path directly instead.</Note>
    </Notes>
    <CVE>CVE-2022-48674</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ifcvf: Do proper cleanup if IFCVF init fails

ifcvf_mgmt_dev leaks memory if it is not freed before
returning. Call is made to correct return statement
so memory does not leak. ifcvf_init_hw does not take
care of this so it is needed to do it here.</Note>
    </Notes>
    <CVE>CVE-2022-48706</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 panic when DSA master device unbinds on shutdown

Rafael reports that on a system with LX2160A and Marvell DSA switches,
if a reboot occurs while the DSA master (dpaa2-eth) is up, the following
panic can be seen:

systemd-shutdown[1]: Rebooting.
Unable to handle kernel paging request at virtual address 00a0000800000041
[00a0000800000041] address between user and kernel address ranges
Internal error: Oops: 96000004 [#1] PREEMPT SMP
CPU: 6 PID: 1 Comm: systemd-shutdow Not tainted 5.16.5-00042-g8f5585009b24 #32
pc : dsa_slave_netdevice_event+0x130/0x3e4
lr : raw_notifier_call_chain+0x50/0x6c
Call trace:
 dsa_slave_netdevice_event+0x130/0x3e4
 raw_notifier_call_chain+0x50/0x6c
 call_netdevice_notifiers_info+0x54/0xa0
 __dev_close_many+0x50/0x130
 dev_close_many+0x84/0x120
 unregister_netdevice_many+0x130/0x710
 unregister_netdevice_queue+0x8c/0xd0
 unregister_netdev+0x20/0x30
 dpaa2_eth_remove+0x68/0x190
 fsl_mc_driver_remove+0x20/0x5c
 __device_release_driver+0x21c/0x220
 device_release_driver_internal+0xac/0xb0
 device_links_unbind_consumers+0xd4/0x100
 __device_release_driver+0x94/0x220
 device_release_driver+0x28/0x40
 bus_remove_device+0x118/0x124
 device_del+0x174/0x420
 fsl_mc_device_remove+0x24/0x40
 __fsl_mc_device_remove+0xc/0x20
 device_for_each_child+0x58/0xa0
 dprc_remove+0x90/0xb0
 fsl_mc_driver_remove+0x20/0x5c
 __device_release_driver+0x21c/0x220
 device_release_driver+0x28/0x40
 bus_remove_device+0x118/0x124
 device_del+0x174/0x420
 fsl_mc_bus_remove+0x80/0x100
 fsl_mc_bus_shutdown+0xc/0x1c
 platform_shutdown+0x20/0x30
 device_shutdown+0x154/0x330
 __do_sys_reboot+0x1cc/0x250
 __arm64_sys_reboot+0x20/0x30
 invoke_syscall.constprop.0+0x4c/0xe0
 do_el0_svc+0x4c/0x150
 el0_svc+0x24/0xb0
 el0t_64_sync_handler+0xa8/0xb0
 el0t_64_sync+0x178/0x17c

It can be seen from the stack trace that the problem is that the
deregistration of the master causes a dev_close(), which gets notified
as NETDEV_GOING_DOWN to dsa_slave_netdevice_event().
But dsa_switch_shutdown() has already run, and this has unregistered the
DSA slave interfaces, and yet, the NETDEV_GOING_DOWN handler attempts to
call dev_close_many() on those slave interfaces, leading to the problem.

The previous attempt to avoid the NETDEV_GOING_DOWN on the master after
dsa_switch_shutdown() was called seems improper. Unregistering the slave
interfaces is unnecessary and unhelpful. Instead, after the slaves have
stopped being uppers of the DSA master, we can now reset to NULL the
master-&gt;dsa_ptr pointer, which will make DSA start ignoring all future
notifier events on the master.</Note>
    </Notes>
    <CVE>CVE-2022-48808</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 kernel panic when enabling bearer

When enabling a bearer on a node, a kernel panic is observed:

[    4.498085] RIP: 0010:tipc_mon_prep+0x4e/0x130 [tipc]
...
[    4.520030] Call Trace:
[    4.520689]  &lt;IRQ&gt;
[    4.521236]  tipc_link_build_proto_msg+0x375/0x750 [tipc]
[    4.522654]  tipc_link_build_state_msg+0x48/0xc0 [tipc]
[    4.524034]  __tipc_node_link_up+0xd7/0x290 [tipc]
[    4.525292]  tipc_rcv+0x5da/0x730 [tipc]
[    4.526346]  ? __netif_receive_skb_core+0xb7/0xfc0
[    4.527601]  tipc_l2_rcv_msg+0x5e/0x90 [tipc]
[    4.528737]  __netif_receive_skb_list_core+0x20b/0x260
[    4.530068]  netif_receive_skb_list_internal+0x1bf/0x2e0
[    4.531450]  ? dev_gro_receive+0x4c2/0x680
[    4.532512]  napi_complete_done+0x6f/0x180
[    4.533570]  virtnet_poll+0x29c/0x42e [virtio_net]
...

The node in question is receiving activate messages in another
thread after changing bearer status to allow message sending/
receiving in current thread:

         thread 1           |              thread 2
         --------           |              --------
                            |
tipc_enable_bearer()        |
  test_and_set_bit_lock()   |
    tipc_bearer_xmit_skb()  |
                            | tipc_l2_rcv_msg()
                            |   tipc_rcv()
                            |     __tipc_node_link_up()
                            |       tipc_link_build_state_msg()
                            |         tipc_link_build_proto_msg()
                            |           tipc_mon_prep()
                            |           {
                            |             ...
                            |             // null-pointer dereference
                            |             u16 gen = mon-&gt;dom_gen;
                            |             ...
                            |           }
  // Not being executed yet |
  tipc_mon_create()         |
  {                         |
    ...                     |
    // allocate             |
    mon = kzalloc();        |
    ...                     |
  }                         |

Monitoring pointer in thread 2 is dereferenced before monitoring data
is allocated in thread 1. This causes kernel panic.

This commit fixes it by allocating the monitoring data before enabling
the bearer to receive messages.</Note>
    </Notes>
    <CVE>CVE-2022-48865</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dmaengine: idxd: Let probe fail when workqueue cannot be enabled

The workqueue is enabled when the appropriate driver is loaded and
disabled when the driver is removed. When the driver is removed it
assumes that the workqueue was enabled successfully and proceeds to
free allocations made during workqueue enabling.

Failure during workqueue enabling does not prevent the driver from
being loaded. This is because the error path within drv_enable_wq()
returns success unless a second failure is encountered
during the error path. By returning success it is possible to load
the driver even if the workqueue cannot be enabled and
allocations that do not exist are attempted to be freed during
driver remove.

Some examples of problematic flows:
(a)

 idxd_dmaengine_drv_probe() -&gt; drv_enable_wq() -&gt; idxd_wq_request_irq():
 In above flow, if idxd_wq_request_irq() fails then
 idxd_wq_unmap_portal() is called on error exit path, but
 drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The
 driver is thus loaded successfully.

 idxd_dmaengine_drv_remove()-&gt;drv_disable_wq()-&gt;idxd_wq_unmap_portal()
 Above flow on driver unload triggers the WARN in devm_iounmap() because
 the device resource has already been removed during error path of
 drv_enable_wq().

(b)

 idxd_dmaengine_drv_probe() -&gt; drv_enable_wq() -&gt; idxd_wq_request_irq():
 In above flow, if idxd_wq_request_irq() fails then
 idxd_wq_init_percpu_ref() is never called to initialize the percpu
 counter, yet the driver loads successfully because drv_enable_wq()
 returns 0.

 idxd_dmaengine_drv_remove()-&gt;__idxd_wq_quiesce()-&gt;percpu_ref_kill():
 Above flow on driver unload triggers a BUG when attempting to drop the
 initial ref of the uninitialized percpu ref:
 BUG: kernel NULL pointer dereference, address: 0000000000000010

Fix the drv_enable_wq() error path by returning the original error that
indicates failure of workqueue enabling. This ensures that the probe
fails when an error is encountered and the driver remove paths are only
attempted when the workqueue was enabled successfully.</Note>
    </Notes>
    <CVE>CVE-2022-48868</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix possible null-ptr-defer in spk_ttyio_release

Run the following tests on the qemu platform:

syzkaller:~# modprobe speakup_audptr
 input: Speakup as /devices/virtual/input/input4
 initialized device: /dev/synth, node (MAJOR 10, MINOR 125)
 speakup 3.1.6: initialized
 synth name on entry is: (null)
 synth probe

spk_ttyio_initialise_ldisc failed because tty_kopen_exclusive returned
failed (errno -16), then remove the module, we will get a null-ptr-defer
problem, as follow:

syzkaller:~# modprobe -r speakup_audptr
 releasing synth audptr
 BUG: kernel NULL pointer dereference, address: 0000000000000080
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 0 P4D 0
 Oops: 0002 [#1] PREEMPT SMP PTI
 CPU: 2 PID: 204 Comm: modprobe Not tainted 6.1.0-rc6-dirty #1
 RIP: 0010:mutex_lock+0x14/0x30
 Call Trace:
 &lt;TASK&gt;
  spk_ttyio_release+0x19/0x70 [speakup]
  synth_release.part.6+0xac/0xc0 [speakup]
  synth_remove+0x56/0x60 [speakup]
  __x64_sys_delete_module+0x156/0x250
  ? fpregs_assert_state_consistent+0x1d/0x50
  do_syscall_64+0x37/0x90
  entry_SYSCALL_64_after_hwframe+0x63/0xcd
 &lt;/TASK&gt;
 Modules linked in: speakup_audptr(-) speakup
 Dumping ftrace buffer:

in_synth-&gt;dev was not initialized during modprobe, so we add check
for in_synth-&gt;dev to fix this bug.</Note>
    </Notes>
    <CVE>CVE-2022-48870</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer

Driver's probe allocates memory for RX FIFO (port-&gt;rx_fifo) based on
default RX FIFO depth, e.g. 16.  Later during serial startup the
qcom_geni_serial_port_setup() updates the RX FIFO depth
(port-&gt;rx_fifo_depth) to match real device capabilities, e.g. to 32.

The RX UART handle code will read "port-&gt;rx_fifo_depth" number of words
into "port-&gt;rx_fifo" buffer, thus exceeding the bounds.  This can be
observed in certain configurations with Qualcomm Bluetooth HCI UART
device and KASAN:

  Bluetooth: hci0: QCA Product ID   :0x00000010
  Bluetooth: hci0: QCA SOC Version  :0x400a0200
  Bluetooth: hci0: QCA ROM Version  :0x00000200
  Bluetooth: hci0: QCA Patch Version:0x00000d2b
  Bluetooth: hci0: QCA controller version 0x02000200
  Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv
  bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2
  Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2)
  Bluetooth: hci0: QCA Failed to download patch (-2)
  ==================================================================
  BUG: KASAN: slab-out-of-bounds in handle_rx_uart+0xa8/0x18c
  Write of size 4 at addr ffff279347d578c0 by task swapper/0/0

  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26
  Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
  Call trace:
   dump_backtrace.part.0+0xe0/0xf0
   show_stack+0x18/0x40
   dump_stack_lvl+0x8c/0xb8
   print_report+0x188/0x488
   kasan_report+0xb4/0x100
   __asan_store4+0x80/0xa4
   handle_rx_uart+0xa8/0x18c
   qcom_geni_serial_handle_rx+0x84/0x9c
   qcom_geni_serial_isr+0x24c/0x760
   __handle_irq_event_percpu+0x108/0x500
   handle_irq_event+0x6c/0x110
   handle_fasteoi_irq+0x138/0x2cc
   generic_handle_domain_irq+0x48/0x64

If the RX FIFO depth changes after probe, be sure to resize the buffer.</Note>
    </Notes>
    <CVE>CVE-2022-48871</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

misc: fastrpc: Fix use-after-free race condition for maps

It is possible that in between calling fastrpc_map_get() until
map-&gt;fl-&gt;lock is taken in fastrpc_free_map(), another thread can call
fastrpc_map_lookup() and get a reference to a map that is about to be
deleted.

Rewrite fastrpc_map_get() to only increase the reference count of a map
if it's non-zero. Propagate this to callers so they can know if a map is
about to be deleted.

Fixes this warning:
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 5 PID: 10100 at lib/refcount.c:25 refcount_warn_saturate
...
Call trace:
 refcount_warn_saturate
 [fastrpc_map_get inlined]
 [fastrpc_map_lookup inlined]
 fastrpc_map_create
 fastrpc_internal_invoke
 fastrpc_device_ioctl
 __arm64_sys_ioctl
 invoke_syscall</Note>
    </Notes>
    <CVE>CVE-2022-48872</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

misc: fastrpc: Don't remove map on creater_process and device_release

Do not remove the map from the list on error path in
fastrpc_init_create_process, instead call fastrpc_map_put, to avoid
use-after-free. Do not remove it on fastrpc_device_release either,
call fastrpc_map_put instead.

The fastrpc_free_map is the only proper place to remove the map.
This is called only after the reference count is 0.</Note>
    </Notes>
    <CVE>CVE-2022-48873</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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: mac80211: sdata can be NULL during AMPDU start

ieee80211_tx_ba_session_handle_start() may get NULL for sdata when a
deauthentication is ongoing.

Here a trace triggering the race with the hostapd test
multi_ap_fronthaul_on_ap:

(gdb) list *drv_ampdu_action+0x46
0x8b16 is in drv_ampdu_action (net/mac80211/driver-ops.c:396).
391             int ret = -EOPNOTSUPP;
392
393             might_sleep();
394
395             sdata = get_bss_sdata(sdata);
396             if (!check_sdata_in_driver(sdata))
397                     return -EIO;
398
399             trace_drv_ampdu_action(local, sdata, params);
400

wlan0: moving STA 02:00:00:00:03:00 to state 3
wlan0: associated
wlan0: deauthenticating from 02:00:00:00:03:00 by local choice (Reason: 3=DEAUTH_LEAVING)
wlan3.sta1: Open BA session requested for 02:00:00:00:00:00 tid 0
wlan3.sta1: dropped frame to 02:00:00:00:00:00 (unauthorized port)
wlan0: moving STA 02:00:00:00:03:00 to state 2
wlan0: moving STA 02:00:00:00:03:00 to state 1
wlan0: Removed STA 02:00:00:00:03:00
wlan0: Destroyed STA 02:00:00:00:03:00
BUG: unable to handle page fault for address: fffffffffffffb48
PGD 11814067 P4D 11814067 PUD 11816067 PMD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 2 PID: 133397 Comm: kworker/u16:1 Tainted: G        W          6.1.0-rc8-wt+ #59
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014
Workqueue: phy3 ieee80211_ba_session_work [mac80211]
RIP: 0010:drv_ampdu_action+0x46/0x280 [mac80211]
Code: 53 48 89 f3 be 89 01 00 00 e8 d6 43 bf ef e8 21 46 81 f0 83 bb a0 1b 00 00 04 75 0e 48 8b 9b 28 0d 00 00 48 81 eb 10 0e 00 00 &lt;8b&gt; 93 58 09 00 00 f6 c2 20 0f 84 3b 01 00 00 8b 05 dd 1c 0f 00 85
RSP: 0018:ffffc900025ebd20 EFLAGS: 00010287
RAX: 0000000000000000 RBX: fffffffffffff1f0 RCX: ffff888102228240
RDX: 0000000080000000 RSI: ffffffff918c5de0 RDI: ffff888102228b40
RBP: ffffc900025ebd40 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000000 R12: ffff888118c18ec0
R13: 0000000000000000 R14: ffffc900025ebd60 R15: ffff888018b7efb8
FS:  0000000000000000(0000) GS:ffff88817a600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffffffffffb48 CR3: 0000000105228006 CR4: 0000000000170ee0
Call Trace:
 &lt;TASK&gt;
 ieee80211_tx_ba_session_handle_start+0xd0/0x190 [mac80211]
 ieee80211_ba_session_work+0xff/0x2e0 [mac80211]
 process_one_work+0x29f/0x620
 worker_thread+0x4d/0x3d0
 ? process_one_work+0x620/0x620
 kthread+0xfb/0x120
 ? kthread_complete_and_exit+0x20/0x20
 ret_from_fork+0x22/0x30
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2022-48875</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_qca: Fix driver shutdown on closed serdev

The driver shutdown callback (which sends EDL_SOC_RESET to the device
over serdev) should not be invoked when HCI device is not open (e.g. if
hci_dev_open_sync() failed), because the serdev and its TTY are not open
either.  Also skip this step if device is powered off
(qca_power_shutdown()).

The shutdown callback causes use-after-free during system reboot with
Qualcomm Atheros Bluetooth:

  Unable to handle kernel paging request at virtual address
  0072662f67726fd7
  ...
  CPU: 6 PID: 1 Comm: systemd-shutdow Tainted: G        W
  6.1.0-rt5-00325-g8a5f56bcfcca #8
  Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
  Call trace:
   tty_driver_flush_buffer+0x4/0x30
   serdev_device_write_flush+0x24/0x34
   qca_serdev_shutdown+0x80/0x130 [hci_uart]
   device_shutdown+0x15c/0x260
   kernel_restart+0x48/0xac

KASAN report:

  BUG: KASAN: use-after-free in tty_driver_flush_buffer+0x1c/0x50
  Read of size 8 at addr ffff16270c2e0018 by task systemd-shutdow/1

  CPU: 7 PID: 1 Comm: systemd-shutdow Not tainted
  6.1.0-next-20221220-00014-gb85aaf97fb01-dirty #28
  Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
  Call trace:
   dump_backtrace.part.0+0xdc/0xf0
   show_stack+0x18/0x30
   dump_stack_lvl+0x68/0x84
   print_report+0x188/0x488
   kasan_report+0xa4/0xf0
   __asan_load8+0x80/0xac
   tty_driver_flush_buffer+0x1c/0x50
   ttyport_write_flush+0x34/0x44
   serdev_device_write_flush+0x48/0x60
   qca_serdev_shutdown+0x124/0x274
   device_shutdown+0x1e8/0x350
   kernel_restart+0x48/0xb0
   __do_sys_reboot+0x244/0x2d0
   __arm64_sys_reboot+0x54/0x70
   invoke_syscall+0x60/0x190
   el0_svc_common.constprop.0+0x7c/0x160
   do_el0_svc+0x44/0xf0
   el0_svc+0x2c/0x6c
   el0t_64_sync_handler+0xbc/0x140
   el0t_64_sync+0x190/0x194</Note>
    </Notes>
    <CVE>CVE-2022-48878</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

efi: fix NULL-deref in init error path

In cases where runtime services are not supported or have been disabled,
the runtime services workqueue will never have been allocated.

Do not try to destroy the workqueue unconditionally in the unlikely
event that EFI initialisation fails to avoid dereferencing a NULL
pointer.</Note>
    </Notes>
    <CVE>CVE-2022-48879</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/surface: aggregator: Add missing call to ssam_request_sync_free()

Although rare, ssam_request_sync_init() can fail. In that case, the
request should be freed via ssam_request_sync_free(). Currently it is
leaked instead. Fix this.</Note>
    </Notes>
    <CVE>CVE-2022-48880</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix refcount leak in amd_pmc_probe

pci_get_domain_bus_and_slot() takes reference, the caller should release
the reference by calling pci_dev_put() after use. Call pci_dev_put() in
the error path to fix this.</Note>
    </Notes>
    <CVE>CVE-2022-48881</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 macsec possible null dereference when updating MAC security entity (SecY)

Upon updating MAC security entity (SecY) in hw offload path, the macsec
security association (SA) initialization routine is called. In case of
extended packet number (epn) is enabled the salt and ssci attributes are
retrieved using the MACsec driver rx_sa context which is unavailable when
updating a SecY property such as encoding-sa hence the null dereference.
Fix by using the provided SA to set those attributes.</Note>
    </Notes>
    <CVE>CVE-2022-48882</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: IPoIB, Block PKEY interfaces with less rx queues than parent

A user is able to configure an arbitrary number of rx queues when
creating an interface via netlink. This doesn't work for child PKEY
interfaces because the child interface uses the parent receive channels.

Although the child shares the parent's receive channels, the number of
rx queues is important for the channel_stats array: the parent's rx
channel index is used to access the child's channel_stats. So the array
has to be at least as large as the parent's rx queue size for the
counting to work correctly and to prevent out of bound accesses.

This patch checks for the mentioned scenario and returns an error when
trying to create the interface. The error is propagated to the user.</Note>
    </Notes>
    <CVE>CVE-2022-48883</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 stats access after free

Command may fail while driver is reloading and can't accept FW commands
till command interface is reinitialized. Such command failure is being
logged to command stats. This results in NULL pointer access as command
stats structure is being freed and reallocated during mlx5 devlink
reload (see kernel log below).

Fix it by making command stats statically allocated on driver probe.

Kernel log:
[ 2394.808802] BUG: unable to handle kernel paging request at 000000000002a9c0
[ 2394.810610] PGD 0 P4D 0
[ 2394.811811] Oops: 0002 [#1] SMP NOPTI
...
[ 2394.815482] RIP: 0010:native_queued_spin_lock_slowpath+0x183/0x1d0
...
[ 2394.829505] Call Trace:
[ 2394.830667]  _raw_spin_lock_irq+0x23/0x26
[ 2394.831858]  cmd_status_err+0x55/0x110 [mlx5_core]
[ 2394.833020]  mlx5_access_reg+0xe7/0x150 [mlx5_core]
[ 2394.834175]  mlx5_query_port_ptys+0x78/0xa0 [mlx5_core]
[ 2394.835337]  mlx5e_ethtool_get_link_ksettings+0x74/0x590 [mlx5_core]
[ 2394.836454]  ? kmem_cache_alloc_trace+0x140/0x1c0
[ 2394.837562]  __rh_call_get_link_ksettings+0x33/0x100
[ 2394.838663]  ? __rtnl_unlock+0x25/0x50
[ 2394.839755]  __ethtool_get_link_ksettings+0x72/0x150
[ 2394.840862]  duplex_show+0x6e/0xc0
[ 2394.841963]  dev_attr_show+0x1c/0x40
[ 2394.843048]  sysfs_kf_seq_show+0x9b/0x100
[ 2394.844123]  seq_read+0x153/0x410
[ 2394.845187]  vfs_read+0x91/0x140
[ 2394.846226]  ksys_read+0x4f/0xb0
[ 2394.847234]  do_syscall_64+0x5b/0x1a0
[ 2394.848228]  entry_SYSCALL_64_after_hwframe+0x65/0xca</Note>
    </Notes>
    <CVE>CVE-2022-48884</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 potential memory leak in ice_gnss_tty_write()

The ice_gnss_tty_write() return directly if the write_buf alloc failed,
leaking the cmd_buf.

Fix by free cmd_buf if write_buf alloc failed.</Note>
    </Notes>
    <CVE>CVE-2022-48885</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 check for kzalloc

Add the check for the return value of kzalloc in order to avoid
NULL pointer dereference.
Moreover, use the goto-label to share the clean code.</Note>
    </Notes>
    <CVE>CVE-2022-48886</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/vmwgfx: Remove rcu locks from user resources

User resource lookups used rcu to avoid two extra atomics. Unfortunately
the rcu paths were buggy and it was easy to make the driver crash by
submitting command buffers from two different threads. Because the
lookups never show up in performance profiles replace them with a
regular spin lock which fixes the races in accesses to those shared
resources.

Fixes kernel oops'es in IGT's vmwgfx execution_buffer stress test and
seen crashes with apps using shared resources.</Note>
    </Notes>
    <CVE>CVE-2022-48887</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/dpu: Fix memory leak in msm_mdss_parse_data_bus_icc_path

of_icc_get() alloc resources for path1, we should release it when not
need anymore. Early return when IS_ERR_OR_NULL(path0) may leak path1.
Defer getting path1 to fix this.

Patchwork: https://patchwork.freedesktop.org/patch/514264/</Note>
    </Notes>
    <CVE>CVE-2022-48888</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Intel: sof-nau8825: fix module alias overflow

The maximum name length for a platform_device_id entry is 20 characters
including the trailing NUL byte. The sof_nau8825.c file exceeds that,
which causes an obscure error message:

sound/soc/intel/boards/snd-soc-sof_nau8825.mod.c:35:45: error: illegal character encoding in string literal [-Werror,-Winvalid-source-encoding]
MODULE_ALIAS("platform:adl_max98373_nau8825&lt;U+0018&gt;&lt;AA&gt;");
                                                   ^~~~
include/linux/module.h:168:49: note: expanded from macro 'MODULE_ALIAS'
                                                ^~~~~~
include/linux/module.h:165:56: note: expanded from macro 'MODULE_INFO'
                                                       ^~~~
include/linux/moduleparam.h:26:47: note: expanded from macro '__MODULE_INFO'
                = __MODULE_INFO_PREFIX __stringify(tag) "=" info

I could not figure out how to make the module handling robust enough
to handle this better, but as a quick fix, using slightly shorter
names that are still unique avoids the build issue.</Note>
    </Notes>
    <CVE>CVE-2022-48889</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: storvsc: Fix swiotlb bounce buffer leak in confidential VM

storvsc_queuecommand() maps the scatter/gather list using scsi_dma_map(),
which in a confidential VM allocates swiotlb bounce buffers. If the I/O
submission fails in storvsc_do_io(), the I/O is typically retried by higher
level code, but the bounce buffer memory is never freed.  The mostly like
cause of I/O submission failure is a full VMBus channel ring buffer, which
is not uncommon under high I/O loads.  Eventually enough bounce buffer
memory leaks that the confidential VM can't do any I/O. The same problem
can arise in a non-confidential VM with kernel boot parameter
swiotlb=force.

Fix this by doing scsi_dma_unmap() in the case of an I/O submission
error, which frees the bounce buffer memory.</Note>
    </Notes>
    <CVE>CVE-2022-48890</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

regulator: da9211: Use irq handler when ready

If the system does not come from reset (like when it is kexec()), the
regulator might have an IRQ waiting for us.

If we enable the IRQ handler before its structures are ready, we crash.

This patch fixes:

[    1.141839] Unable to handle kernel read from unreadable memory at virtual address 0000000000000078
[    1.316096] Call trace:
[    1.316101]  blocking_notifier_call_chain+0x20/0xa8
[    1.322757] cpu cpu0: dummy supplies not allowed for exclusive requests
[    1.327823]  regulator_notifier_call_chain+0x1c/0x2c
[    1.327825]  da9211_irq_handler+0x68/0xf8
[    1.327829]  irq_thread+0x11c/0x234
[    1.327833]  kthread+0x13c/0x154</Note>
    </Notes>
    <CVE>CVE-2022-48891</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/gt: Cleanup partial engine discovery failures

If we abort driver initialisation in the middle of gt/engine discovery,
some engines will be fully setup and some not. Those incompletely setup
engines only have 'engine-&gt;release == NULL' and so will leak any of the
common objects allocated.

v2:
 - Drop the destroy_pinned_context() helper for now.  It's not really
   worth it with just a single callsite at the moment.  (Janusz)</Note>
    </Notes>
    <CVE>CVE-2022-48893</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ixgbe: fix pci device refcount leak

As the comment of pci_get_domain_bus_and_slot() says, it
returns a PCI device with refcount incremented, when finish
using it, the caller must decrement the reference count by
calling pci_dev_put().

In ixgbe_get_first_secondary_devfn() and ixgbe_x550em_a_has_mii(),
pci_dev_put() is called to avoid leak.</Note>
    </Notes>
    <CVE>CVE-2022-48896</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer

There are 3 possible interrupt sources are handled by DP controller,
HPDstatus, Controller state changes and Aux read/write transaction.
At every irq, DP controller have to check isr status of every interrupt
sources and service the interrupt if its isr status bits shows interrupts
are pending. There is potential race condition may happen at current aux
isr handler implementation since it is always complete dp_aux_cmd_fifo_tx()
even irq is not for aux read or write transaction. This may cause aux read
transaction return premature if host aux data read is in the middle of
waiting for sink to complete transferring data to host while irq happen.
This will cause host's receiving buffer contains unexpected data. This
patch fixes this problem by checking aux isr and return immediately at
aux isr handler if there are no any isr status bits set.

Current there is a bug report regrading eDP edid corruption happen during
system booting up. After lengthy debugging to found that VIDEO_READY
interrupt was continuously firing during system booting up which cause
dp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data
from aux hardware buffer which is not yet contains complete data transfer
from sink. This cause edid corruption.

Follows are the signature at kernel logs when problem happen,
EDID has corrupt header
panel-simple-dp-aux aux-aea0000.edp: Couldn't identify panel via EDID

Changes in v2:
-- do complete if (ret == IRQ_HANDLED) ay dp-aux_isr()
-- add more commit text

Changes in v3:
-- add Stephen suggested
-- dp_aux_isr() return IRQ_XXX back to caller
-- dp_ctrl_isr() return IRQ_XXX back to caller

Changes in v4:
-- split into two patches

Changes in v5:
-- delete empty line between tags

Changes in v6:
-- remove extra "that" and fixed line more than 75 char at commit text

Patchwork: https://patchwork.freedesktop.org/patch/516121/</Note>
    </Notes>
    <CVE>CVE-2022-48898</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/virtio: Fix GEM handle creation UAF

Userspace can guess the handle value and try to race GEM object creation
with handle close, resulting in a use-after-free if we dereference the
object after dropping the handle's reference.  For that reason, dropping
the handle's reference must be done *after* we are done dereferencing
the object.</Note>
    </Notes>
    <CVE>CVE-2022-48899</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: do not start relocation until in progress drops are done

We hit a bug with a recovering relocation on mount for one of our file
systems in production.  I reproduced this locally by injecting errors
into snapshot delete with balance running at the same time.  This
presented as an error while looking up an extent item

  WARNING: CPU: 5 PID: 1501 at fs/btrfs/extent-tree.c:866 lookup_inline_extent_backref+0x647/0x680
  CPU: 5 PID: 1501 Comm: btrfs-balance Not tainted 5.16.0-rc8+ #8
  RIP: 0010:lookup_inline_extent_backref+0x647/0x680
  RSP: 0018:ffffae0a023ab960 EFLAGS: 00010202
  RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000
  RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000000000
  RBP: ffff943fd2a39b60 R08: 0000000000000000 R09: 0000000000000001
  R10: 0001434088152de0 R11: 0000000000000000 R12: 0000000001d05000
  R13: ffff943fd2a39b60 R14: ffff943fdb96f2a0 R15: ffff9442fc923000
  FS:  0000000000000000(0000) GS:ffff944e9eb40000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f1157b1fca8 CR3: 000000010f092000 CR4: 0000000000350ee0
  Call Trace:
   &lt;TASK&gt;
   insert_inline_extent_backref+0x46/0xd0
   __btrfs_inc_extent_ref.isra.0+0x5f/0x200
   ? btrfs_merge_delayed_refs+0x164/0x190
   __btrfs_run_delayed_refs+0x561/0xfa0
   ? btrfs_search_slot+0x7b4/0xb30
   ? btrfs_update_root+0x1a9/0x2c0
   btrfs_run_delayed_refs+0x73/0x1f0
   ? btrfs_update_root+0x1a9/0x2c0
   btrfs_commit_transaction+0x50/0xa50
   ? btrfs_update_reloc_root+0x122/0x220
   prepare_to_merge+0x29f/0x320
   relocate_block_group+0x2b8/0x550
   btrfs_relocate_block_group+0x1a6/0x350
   btrfs_relocate_chunk+0x27/0xe0
   btrfs_balance+0x777/0xe60
   balance_kthread+0x35/0x50
   ? btrfs_balance+0xe60/0xe60
   kthread+0x16b/0x190
   ? set_kthread_struct+0x40/0x40
   ret_from_fork+0x22/0x30
   &lt;/TASK&gt;

Normally snapshot deletion and relocation are excluded from running at
the same time by the fs_info-&gt;cleaner_mutex.  However if we had a
pending balance waiting to get the -&gt;cleaner_mutex, and a snapshot
deletion was running, and then the box crashed, we would come up in a
state where we have a half deleted snapshot.

Again, in the normal case the snapshot deletion needs to complete before
relocation can start, but in this case relocation could very well start
before the snapshot deletion completes, as we simply add the root to the
dead roots list and wait for the next time the cleaner runs to clean up
the snapshot.

Fix this by setting a bit on the fs_info if we have any DEAD_ROOT's that
had a pending drop_progress key.  If they do then we know we were in the
middle of the drop operation and set a flag on the fs_info.  Then
balance can wait until this flag is cleared to start up again.

If there are DEAD_ROOT's that don't have a drop_progress set then we're
safe to start balance right away as we'll be properly protected by the
cleaner_mutex.</Note>
    </Notes>
    <CVE>CVE-2022-48901</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 relocation crash due to premature return from btrfs_commit_transaction()

We are seeing crashes similar to the following trace:

[38.969182] WARNING: CPU: 20 PID: 2105 at fs/btrfs/relocation.c:4070 btrfs_relocate_block_group+0x2dc/0x340 [btrfs]
[38.973556] CPU: 20 PID: 2105 Comm: btrfs Not tainted 5.17.0-rc4 #54
[38.974580] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
[38.976539] RIP: 0010:btrfs_relocate_block_group+0x2dc/0x340 [btrfs]
[38.980336] RSP: 0000:ffffb0dd42e03c20 EFLAGS: 00010206
[38.981218] RAX: ffff96cfc4ede800 RBX: ffff96cfc3ce0000 RCX: 000000000002ca14
[38.982560] RDX: 0000000000000000 RSI: 4cfd109a0bcb5d7f RDI: ffff96cfc3ce0360
[38.983619] RBP: ffff96cfc309c000 R08: 0000000000000000 R09: 0000000000000000
[38.984678] R10: ffff96cec0000001 R11: ffffe84c80000000 R12: ffff96cfc4ede800
[38.985735] R13: 0000000000000000 R14: 0000000000000000 R15: ffff96cfc3ce0360
[38.987146] FS:  00007f11c15218c0(0000) GS:ffff96d6dfb00000(0000) knlGS:0000000000000000
[38.988662] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[38.989398] CR2: 00007ffc922c8e60 CR3: 00000001147a6001 CR4: 0000000000370ee0
[38.990279] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[38.991219] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[38.992528] Call Trace:
[38.992854]  &lt;TASK&gt;
[38.993148]  btrfs_relocate_chunk+0x27/0xe0 [btrfs]
[38.993941]  btrfs_balance+0x78e/0xea0 [btrfs]
[38.994801]  ? vsnprintf+0x33c/0x520
[38.995368]  ? __kmalloc_track_caller+0x351/0x440
[38.996198]  btrfs_ioctl_balance+0x2b9/0x3a0 [btrfs]
[38.997084]  btrfs_ioctl+0x11b0/0x2da0 [btrfs]
[38.997867]  ? mod_objcg_state+0xee/0x340
[38.998552]  ? seq_release+0x24/0x30
[38.999184]  ? proc_nr_files+0x30/0x30
[38.999654]  ? call_rcu+0xc8/0x2f0
[39.000228]  ? __x64_sys_ioctl+0x84/0xc0
[39.000872]  ? btrfs_ioctl_get_supported_features+0x30/0x30 [btrfs]
[39.001973]  __x64_sys_ioctl+0x84/0xc0
[39.002566]  do_syscall_64+0x3a/0x80
[39.003011]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[39.003735] RIP: 0033:0x7f11c166959b
[39.007324] RSP: 002b:00007fff2543e998 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[39.008521] RAX: ffffffffffffffda RBX: 00007f11c1521698 RCX: 00007f11c166959b
[39.009833] RDX: 00007fff2543ea40 RSI: 00000000c4009420 RDI: 0000000000000003
[39.011270] RBP: 0000000000000003 R08: 0000000000000013 R09: 00007f11c16f94e0
[39.012581] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff25440df3
[39.014046] R13: 0000000000000000 R14: 00007fff2543ea40 R15: 0000000000000001
[39.015040]  &lt;/TASK&gt;
[39.015418] ---[ end trace 0000000000000000 ]---
[43.131559] ------------[ cut here ]------------
[43.132234] kernel BUG at fs/btrfs/extent-tree.c:2717!
[43.133031] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[43.133702] CPU: 1 PID: 1839 Comm: btrfs Tainted: G        W         5.17.0-rc4 #54
[43.134863] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
[43.136426] RIP: 0010:unpin_extent_range+0x37a/0x4f0 [btrfs]
[43.139913] RSP: 0000:ffffb0dd4216bc70 EFLAGS: 00010246
[43.140629] RAX: 0000000000000000 RBX: ffff96cfc34490f8 RCX: 0000000000000001
[43.141604] RDX: 0000000080000001 RSI: 0000000051d00000 RDI: 00000000ffffffff
[43.142645] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff96cfd07dca50
[43.143669] R10: ffff96cfc46e8a00 R11: fffffffffffec000 R12: 0000000041d00000
[43.144657] R13: ffff96cfc3ce0000 R14: ffffb0dd4216bd08 R15: 0000000000000000
[43.145686] FS:  00007f7657dd68c0(0000) GS:ffff96d6df640000(0000) knlGS:0000000000000000
[43.146808] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[43.147584] CR2: 00007f7fe81bf5b0 CR3: 00000001093ee004 CR4: 0000000000370ee0
[43.148589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[43.149581] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000000000
---truncated---</Note>
    </Notes>
    <CVE>CVE-2022-48903</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/amd: Fix I/O page table memory leak

The current logic updates the I/O page table mode for the domain
before calling the logic to free memory used for the page table.
This results in IOMMU page table memory leak, and can be observed
when launching VM w/ pass-through devices.

Fix by freeing the memory used for page table before updating the mode.</Note>
    </Notes>
    <CVE>CVE-2022-48904</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

ibmvnic: free reset-work-item when flushing

Fix a tiny memory leak when flushing the reset work queue.</Note>
    </Notes>
    <CVE>CVE-2022-48905</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Correctly set DATA_FIN timeout when number of retransmits is large

Syzkaller with UBSAN uncovered a scenario where a large number of
DATA_FIN retransmits caused a shift-out-of-bounds in the DATA_FIN
timeout calculation:

================================================================================
UBSAN: shift-out-of-bounds in net/mptcp/protocol.c:470:29
shift exponent 32 is too large for 32-bit type 'unsigned int'
CPU: 1 PID: 13059 Comm: kworker/1:0 Not tainted 5.17.0-rc2-00630-g5fbf21c90c60 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Workqueue: events mptcp_worker
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
 ubsan_epilogue+0xb/0x5a lib/ubsan.c:151
 __ubsan_handle_shift_out_of_bounds.cold+0xb2/0x20e lib/ubsan.c:330
 mptcp_set_datafin_timeout net/mptcp/protocol.c:470 [inline]
 __mptcp_retrans.cold+0x72/0x77 net/mptcp/protocol.c:2445
 mptcp_worker+0x58a/0xa70 net/mptcp/protocol.c:2528
 process_one_work+0x9df/0x16d0 kernel/workqueue.c:2307
 worker_thread+0x95/0xe10 kernel/workqueue.c:2454
 kthread+0x2f4/0x3b0 kernel/kthread.c:377
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
 &lt;/TASK&gt;
================================================================================

This change limits the maximum timeout by limiting the size of the
shift, which keeps all intermediate values in-bounds.</Note>
    </Notes>
    <CVE>CVE-2022-48906</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

auxdisplay: lcd2s: Fix memory leak in -&gt;remove()

Once allocated the struct lcd2s_data is never freed.
Fix the memory leak by switching to devm_kzalloc().</Note>
    </Notes>
    <CVE>CVE-2022-48907</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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/smc: fix connection leak

There's a potential leak issue under following execution sequence :

smc_release  				smc_connect_work
if (sk-&gt;sk_state == SMC_INIT)
					send_clc_confirim
	tcp_abort();
					...
					sk.sk_state = SMC_ACTIVE
smc_close_active
switch(sk-&gt;sk_state) {
...
case SMC_ACTIVE:
	smc_close_final()
	// then wait peer closed

Unfortunately, tcp_abort() may discard CLC CONFIRM messages that are
still in the tcp send buffer, in which case our connection token cannot
be delivered to the server side, which means that we cannot get a
passive close message at all. Therefore, it is impossible for the to be
disconnected at all.

This patch tries a very simple way to avoid this issue, once the state
has changed to SMC_ACTIVE after tcp_abort(), we can actively abort the
smc connection, considering that the state is SMC_INIT before
tcp_abort(), abandoning the complete disconnection process should not
cause too much problem.

In fact, this problem may exist as long as the CLC CONFIRM message is
not received by the server. Whether a timer should be added after
smc_close_final() needs to be discussed in the future. But even so, this
patch provides a faster release for connection in above case, it should
also be valuable.</Note>
    </Notes>
    <CVE>CVE-2022-48909</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ipv6: ensure we call ipv6_mc_down() at most once

There are two reasons for addrconf_notify() to be called with NETDEV_DOWN:
either the network device is actually going down, or IPv6 was disabled
on the interface.

If either of them stays down while the other is toggled, we repeatedly
call the code for NETDEV_DOWN, including ipv6_mc_down(), while never
calling the corresponding ipv6_mc_up() in between. This will cause a
new entry in idev-&gt;mc_tomb to be allocated for each multicast group
the interface is subscribed to, which in turn leaks one struct ifmcaddr6
per nontrivial multicast group the interface is subscribed to.

The following reproducer will leak at least $n objects:

ip addr add ff2e::4242/32 dev eth0 autojoin
sysctl -w net.ipv6.conf.eth0.disable_ipv6=1
for i in $(seq 1 $n); do
	ip link set up eth0; ip link set down eth0
done

Joining groups with IPV6_ADD_MEMBERSHIP (unprivileged) or setting the
sysctl net.ipv6.conf.eth0.forwarding to 1 (=&gt; subscribing to ff02::2)
can also be used to create a nontrivial idev-&gt;mc_list, which will the
leak objects with the right up-down-sequence.

Based on both sources for NETDEV_DOWN events the interface IPv6 state
should be considered:

 - not ready if the network interface is not ready OR IPv6 is disabled
   for it
 - ready if the network interface is ready AND IPv6 is enabled for it

The functions ipv6_mc_up() and ipv6_down() should only be run when this
state changes.

Implement this by remembering when the IPv6 state is ready, and only
run ipv6_mc_down() if it actually changed from ready to not ready.

The other direction (not ready -&gt; ready) already works correctly, as:

 - the interface notification triggered codepath for NETDEV_UP /
   NETDEV_CHANGE returns early if ipv6 is disabled, and
 - the disable_ipv6=0 triggered codepath skips fully initializing the
   interface as long as addrconf_link_ready(dev) returns false
 - calling ipv6_mc_up() repeatedly does not leak anything</Note>
    </Notes>
    <CVE>CVE-2022-48910</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_queue: fix possible use-after-free

Eric Dumazet says:
  The sock_hold() side seems suspect, because there is no guarantee
  that sk_refcnt is not already 0.

On failure, we cannot queue the packet and need to indicate an
error.  The packet will be dropped by the caller.

v2: split skb prefetch hunk into separate change</Note>
    </Notes>
    <CVE>CVE-2022-48911</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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: fix use-after-free in __nf_register_net_hook()

We must not dereference @new_hooks after nf_hook_mutex has been released,
because other threads might have freed our allocated hooks already.

BUG: KASAN: use-after-free in nf_hook_entries_get_hook_ops include/linux/netfilter.h:130 [inline]
BUG: KASAN: use-after-free in hooks_validate net/netfilter/core.c:171 [inline]
BUG: KASAN: use-after-free in __nf_register_net_hook+0x77a/0x820 net/netfilter/core.c:438
Read of size 2 at addr ffff88801c1a8000 by task syz-executor237/4430

CPU: 1 PID: 4430 Comm: syz-executor237 Not tainted 5.17.0-rc5-syzkaller-00306-g2293be58d6a1 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
 print_address_description.constprop.0.cold+0x8d/0x336 mm/kasan/report.c:255
 __kasan_report mm/kasan/report.c:442 [inline]
 kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
 nf_hook_entries_get_hook_ops include/linux/netfilter.h:130 [inline]
 hooks_validate net/netfilter/core.c:171 [inline]
 __nf_register_net_hook+0x77a/0x820 net/netfilter/core.c:438
 nf_register_net_hook+0x114/0x170 net/netfilter/core.c:571
 nf_register_net_hooks+0x59/0xc0 net/netfilter/core.c:587
 nf_synproxy_ipv6_init+0x85/0xe0 net/netfilter/nf_synproxy_core.c:1218
 synproxy_tg6_check+0x30d/0x560 net/ipv6/netfilter/ip6t_SYNPROXY.c:81
 xt_check_target+0x26c/0x9e0 net/netfilter/x_tables.c:1038
 check_target net/ipv6/netfilter/ip6_tables.c:530 [inline]
 find_check_entry.constprop.0+0x7f1/0x9e0 net/ipv6/netfilter/ip6_tables.c:573
 translate_table+0xc8b/0x1750 net/ipv6/netfilter/ip6_tables.c:735
 do_replace net/ipv6/netfilter/ip6_tables.c:1153 [inline]
 do_ip6t_set_ctl+0x56e/0xb90 net/ipv6/netfilter/ip6_tables.c:1639
 nf_setsockopt+0x83/0xe0 net/netfilter/nf_sockopt.c:101
 ipv6_setsockopt+0x122/0x180 net/ipv6/ipv6_sockglue.c:1024
 rawv6_setsockopt+0xd3/0x6a0 net/ipv6/raw.c:1084
 __sys_setsockopt+0x2db/0x610 net/socket.c:2180
 __do_sys_setsockopt net/socket.c:2191 [inline]
 __se_sys_setsockopt net/socket.c:2188 [inline]
 __x64_sys_setsockopt+0xba/0x150 net/socket.c:2188
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f65a1ace7d9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 71 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &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:00007f65a1a7f308 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 00007f65a1ace7d9
RDX: 0000000000000040 RSI: 0000000000000029 RDI: 0000000000000003
RBP: 00007f65a1b574c8 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000020000000 R11: 0000000000000246 R12: 00007f65a1b55130
R13: 00007f65a1b574c0 R14: 00007f65a1b24090 R15: 0000000000022000
 &lt;/TASK&gt;

The buggy address belongs to the page:
page:ffffea0000706a00 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1c1a8
flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000000000 ffffea0001c1b108 ffffea000046dd08 0000000000000000
raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as freed
page last allocated via order 2, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 4430, ts 1061781545818, free_ts 1061791488993
 prep_new_page mm/page_alloc.c:2434 [inline]
 get_page_from_freelist+0xa72/0x2f50 mm/page_alloc.c:4165
 __alloc_pages+0x1b2/0x500 mm/page_alloc.c:5389
 __alloc_pages_node include/linux/gfp.h:572 [inline]
 alloc_pages_node include/linux/gfp.h:595 [inline]
 kmalloc_large_node+0x62/0x130 mm/slub.c:4438
 __kmalloc_node+0x35a/0x4a0 mm/slub.
---truncated---</Note>
    </Notes>
    <CVE>CVE-2022-48912</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

blktrace: fix use after free for struct blk_trace

When tracing the whole disk, 'dropped' and 'msg' will be created
under 'q-&gt;debugfs_dir' and 'bt-&gt;dir' is NULL, thus blk_trace_free()
won't remove those files. What's worse, the following UAF can be
triggered because of accessing stale 'dropped' and 'msg':

==================================================================
BUG: KASAN: use-after-free in blk_dropped_read+0x89/0x100
Read of size 4 at addr ffff88816912f3d8 by task blktrace/1188

CPU: 27 PID: 1188 Comm: blktrace Not tainted 5.17.0-rc4-next-20220217+ #469
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-4
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x34/0x44
 print_address_description.constprop.0.cold+0xab/0x381
 ? blk_dropped_read+0x89/0x100
 ? blk_dropped_read+0x89/0x100
 kasan_report.cold+0x83/0xdf
 ? blk_dropped_read+0x89/0x100
 kasan_check_range+0x140/0x1b0
 blk_dropped_read+0x89/0x100
 ? blk_create_buf_file_callback+0x20/0x20
 ? kmem_cache_free+0xa1/0x500
 ? do_sys_openat2+0x258/0x460
 full_proxy_read+0x8f/0xc0
 vfs_read+0xc6/0x260
 ksys_read+0xb9/0x150
 ? vfs_write+0x3d0/0x3d0
 ? fpregs_assert_state_consistent+0x55/0x60
 ? exit_to_user_mode_prepare+0x39/0x1e0
 do_syscall_64+0x35/0x80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7fbc080d92fd
Code: ce 20 00 00 75 10 b8 00 00 00 00 0f 05 48 3d 01 f0 ff ff 73 31 c3 48 83 1
RSP: 002b:00007fbb95ff9cb0 EFLAGS: 00000293 ORIG_RAX: 0000000000000000
RAX: ffffffffffffffda RBX: 00007fbb95ff9dc0 RCX: 00007fbc080d92fd
RDX: 0000000000000100 RSI: 00007fbb95ff9cc0 RDI: 0000000000000045
RBP: 0000000000000045 R08: 0000000000406299 R09: 00000000fffffffd
R10: 000000000153afa0 R11: 0000000000000293 R12: 00007fbb780008c0
R13: 00007fbb78000938 R14: 0000000000608b30 R15: 00007fbb780029c8
 &lt;/TASK&gt;

Allocated by task 1050:
 kasan_save_stack+0x1e/0x40
 __kasan_kmalloc+0x81/0xa0
 do_blk_trace_setup+0xcb/0x410
 __blk_trace_setup+0xac/0x130
 blk_trace_ioctl+0xe9/0x1c0
 blkdev_ioctl+0xf1/0x390
 __x64_sys_ioctl+0xa5/0xe0
 do_syscall_64+0x35/0x80
 entry_SYSCALL_64_after_hwframe+0x44/0xae

Freed by task 1050:
 kasan_save_stack+0x1e/0x40
 kasan_set_track+0x21/0x30
 kasan_set_free_info+0x20/0x30
 __kasan_slab_free+0x103/0x180
 kfree+0x9a/0x4c0
 __blk_trace_remove+0x53/0x70
 blk_trace_ioctl+0x199/0x1c0
 blkdev_common_ioctl+0x5e9/0xb30
 blkdev_ioctl+0x1a5/0x390
 __x64_sys_ioctl+0xa5/0xe0
 do_syscall_64+0x35/0x80
 entry_SYSCALL_64_after_hwframe+0x44/0xae

The buggy address belongs to the object at ffff88816912f380
 which belongs to the cache kmalloc-96 of size 96
The buggy address is located 88 bytes inside of
 96-byte region [ffff88816912f380, ffff88816912f3e0)
The buggy address belongs to the page:
page:000000009a1b4e7c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0f
flags: 0x17ffffc0000200(slab|node=0|zone=2|lastcpupid=0x1fffff)
raw: 0017ffffc0000200 ffffea00044f1100 dead000000000002 ffff88810004c780
raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff88816912f280: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
 ffff88816912f300: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
&gt;ffff88816912f380: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
                                                    ^
 ffff88816912f400: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
 ffff88816912f480: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
==================================================================</Note>
    </Notes>
    <CVE>CVE-2022-48913</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: destroy queues before real_num_tx_queues is zeroed

xennet_destroy_queues() relies on info-&gt;netdev-&gt;real_num_tx_queues to
delete queues. Since d7dac083414eb5bb99a6d2ed53dc2c1b405224e5
("net-sysfs: update the queue counts in the unregistration path"),
unregister_netdev() indirectly sets real_num_tx_queues to 0. Those two
facts together means, that xennet_destroy_queues() called from
xennet_remove() cannot do its job, because it's called after
unregister_netdev(). This results in kfree-ing queues that are still
linked in napi, which ultimately crashes:

    BUG: kernel NULL pointer dereference, address: 0000000000000000
    #PF: supervisor read access in kernel mode
    #PF: error_code(0x0000) - not-present page
    PGD 0 P4D 0
    Oops: 0000 [#1] PREEMPT SMP PTI
    CPU: 1 PID: 52 Comm: xenwatch Tainted: G        W         5.16.10-1.32.fc32.qubes.x86_64+ #226
    RIP: 0010:free_netdev+0xa3/0x1a0
    Code: ff 48 89 df e8 2e e9 00 00 48 8b 43 50 48 8b 08 48 8d b8 a0 fe ff ff 48 8d a9 a0 fe ff ff 49 39 c4 75 26 eb 47 e8 ed c1 66 ff &lt;48&gt; 8b 85 60 01 00 00 48 8d 95 60 01 00 00 48 89 ef 48 2d 60 01 00
    RSP: 0000:ffffc90000bcfd00 EFLAGS: 00010286
    RAX: 0000000000000000 RBX: ffff88800edad000 RCX: 0000000000000000
    RDX: 0000000000000001 RSI: ffffc90000bcfc30 RDI: 00000000ffffffff
    RBP: fffffffffffffea0 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000001 R12: ffff88800edad050
    R13: ffff8880065f8f88 R14: 0000000000000000 R15: ffff8880066c6680
    FS:  0000000000000000(0000) GS:ffff8880f3300000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000000 CR3: 00000000e998c006 CR4: 00000000003706e0
    Call Trace:
     &lt;TASK&gt;
     xennet_remove+0x13d/0x300 [xen_netfront]
     xenbus_dev_remove+0x6d/0xf0
     __device_release_driver+0x17a/0x240
     device_release_driver+0x24/0x30
     bus_remove_device+0xd8/0x140
     device_del+0x18b/0x410
     ? _raw_spin_unlock+0x16/0x30
     ? klist_iter_exit+0x14/0x20
     ? xenbus_dev_request_and_reply+0x80/0x80
     device_unregister+0x13/0x60
     xenbus_dev_changed+0x18e/0x1f0
     xenwatch_thread+0xc0/0x1a0
     ? do_wait_intr_irq+0xa0/0xa0
     kthread+0x16b/0x190
     ? set_kthread_struct+0x40/0x40
     ret_from_fork+0x22/0x30
     &lt;/TASK&gt;

Fix this by calling xennet_destroy_queues() from xennet_uninit(),
when real_num_tx_queues is still available. This ensures that queues are
destroyed when real_num_tx_queues is set to 0, regardless of how
unregister_netdev() was called.

Originally reported at
https://github.com/QubesOS/qubes-issues/issues/7257</Note>
    </Notes>
    <CVE>CVE-2022-48914</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix TZ_GET_TRIP NULL pointer dereference

Do not call get_trip_hyst() from thermal_genl_cmd_tz_get_trip() if
the thermal zone does not define one.</Note>
    </Notes>
    <CVE>CVE-2022-48915</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 double list_add when enabling VMD in scalable mode

When enabling VMD and IOMMU scalable mode, the following kernel panic
call trace/kernel log is shown in Eagle Stream platform (Sapphire Rapids
CPU) during booting:

pci 0000:59:00.5: Adding to iommu group 42
...
vmd 0000:59:00.5: PCI host bridge to bus 10000:80
pci 10000:80:01.0: [8086:352a] type 01 class 0x060400
pci 10000:80:01.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]
pci 10000:80:01.0: enabling Extended Tags
pci 10000:80:01.0: PME# supported from D0 D3hot D3cold
pci 10000:80:01.0: DMAR: Setup RID2PASID failed
pci 10000:80:01.0: Failed to add to iommu group 42: -16
pci 10000:80:03.0: [8086:352b] type 01 class 0x060400
pci 10000:80:03.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]
pci 10000:80:03.0: enabling Extended Tags
pci 10000:80:03.0: PME# supported from D0 D3hot D3cold
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:29!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.17.0-rc3+ #7
Hardware name: Lenovo ThinkSystem SR650V3/SB27A86647, BIOS ESE101Y-1.00 01/13/2022
Workqueue: events work_for_cpu_fn
RIP: 0010:__list_add_valid.cold+0x26/0x3f
Code: 9a 4a ab ff 4c 89 c1 48 c7 c7 40 0c d9 9e e8 b9 b1 fe ff 0f
      0b 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 f0 0c d9 9e e8 a2 b1
      fe ff &lt;0f&gt; 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 98 0c d9
      9e e8 8b b1 fe
RSP: 0000:ff5ad434865b3a40 EFLAGS: 00010246
RAX: 0000000000000058 RBX: ff4d61160b74b880 RCX: ff4d61255e1fffa8
RDX: 0000000000000000 RSI: 00000000fffeffff RDI: ffffffff9fd34f20
RBP: ff4d611d8e245c00 R08: 0000000000000000 R09: ff5ad434865b3888
R10: ff5ad434865b3880 R11: ff4d61257fdc6fe8 R12: ff4d61160b74b8a0
R13: ff4d61160b74b8a0 R14: ff4d611d8e245c10 R15: ff4d611d8001ba70
FS:  0000000000000000(0000) GS:ff4d611d5ea00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ff4d611fa1401000 CR3: 0000000aa0210001 CR4: 0000000000771ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 intel_pasid_alloc_table+0x9c/0x1d0
 dmar_insert_one_dev_info+0x423/0x540
 ? device_to_iommu+0x12d/0x2f0
 intel_iommu_attach_device+0x116/0x290
 __iommu_attach_device+0x1a/0x90
 iommu_group_add_device+0x190/0x2c0
 __iommu_probe_device+0x13e/0x250
 iommu_probe_device+0x24/0x150
 iommu_bus_notifier+0x69/0x90
 blocking_notifier_call_chain+0x5a/0x80
 device_add+0x3db/0x7b0
 ? arch_memremap_can_ram_remap+0x19/0x50
 ? memremap+0x75/0x140
 pci_device_add+0x193/0x1d0
 pci_scan_single_device+0xb9/0xf0
 pci_scan_slot+0x4c/0x110
 pci_scan_child_bus_extend+0x3a/0x290
 vmd_enable_domain.constprop.0+0x63e/0x820
 vmd_probe+0x163/0x190
 local_pci_probe+0x42/0x80
 work_for_cpu_fn+0x13/0x20
 process_one_work+0x1e2/0x3b0
 worker_thread+0x1c4/0x3a0
 ? rescuer_thread+0x370/0x370
 kthread+0xc7/0xf0
 ? kthread_complete_and_exit+0x20/0x20
 ret_from_fork+0x1f/0x30
 &lt;/TASK&gt;
Modules linked in:
---[ end trace 0000000000000000 ]---
...
Kernel panic - not syncing: Fatal exception
Kernel Offset: 0x1ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
---[ end Kernel panic - not syncing: Fatal exception ]---

The following 'lspci' output shows devices '10000:80:*' are subdevices of
the VMD device 0000:59:00.5:

  $ lspci
  ...
  0000:59:00.5 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller (rev 20)
  ...
  10000:80:01.0 PCI bridge: Intel Corporation Device 352a (rev 03)
  10000:80:03.0 PCI bridge: Intel Corporation Device 352b (rev 03)
  10000:80:05.0 PCI bridge: Intel Corporation Device 352c (rev 03)
  10000:80:07.0 PCI bridge: Intel Corporation Device 352d (rev 03)
  10000:81:00.0 Non-Volatile memory controller: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller]
  10000:82:00
---truncated---</Note>
    </Notes>
    <CVE>CVE-2022-48916</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-2022-48917</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iwlwifi: mvm: check debugfs_dir ptr before use

When "debugfs=off" is used on the kernel command line, iwiwifi's
mvm module uses an invalid/unchecked debugfs_dir pointer and causes
a BUG:

 BUG: kernel NULL pointer dereference, address: 000000000000004f
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: 0000 [#1] PREEMPT SMP
 CPU: 1 PID: 503 Comm: modprobe Tainted: G        W         5.17.0-rc5 #7
 Hardware name: Dell Inc. Inspiron 15 5510/076F7Y, BIOS 2.4.1 11/05/2021
 RIP: 0010:iwl_mvm_dbgfs_register+0x692/0x700 [iwlmvm]
 Code: 69 a0 be 80 01 00 00 48 c7 c7 50 73 6a a0 e8 95 cf ee e0 48 8b 83 b0 1e 00 00 48 c7 c2 54 73 6a a0 be 64 00 00 00 48 8d 7d 8c &lt;48&gt; 8b 48 50 e8 15 22 07 e1 48 8b 43 28 48 8d 55 8c 48 c7 c7 5f 73
 RSP: 0018:ffffc90000a0ba68 EFLAGS: 00010246
 RAX: ffffffffffffffff RBX: ffff88817d6e3328 RCX: ffff88817d6e3328
 RDX: ffffffffa06a7354 RSI: 0000000000000064 RDI: ffffc90000a0ba6c
 RBP: ffffc90000a0bae0 R08: ffffffff824e4880 R09: ffffffffa069d620
 R10: ffffc90000a0ba00 R11: ffffffffffffffff R12: 0000000000000000
 R13: ffffc90000a0bb28 R14: ffff88817d6e3328 R15: ffff88817d6e3320
 FS:  00007f64dd92d740(0000) GS:ffff88847f640000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 000000000000004f CR3: 000000016fc79001 CR4: 0000000000770ee0
 PKRU: 55555554
 Call Trace:
  &lt;TASK&gt;
  ? iwl_mvm_mac_setup_register+0xbdc/0xda0 [iwlmvm]
  iwl_mvm_start_post_nvm+0x71/0x100 [iwlmvm]
  iwl_op_mode_mvm_start+0xab8/0xb30 [iwlmvm]
  _iwl_op_mode_start+0x6f/0xd0 [iwlwifi]
  iwl_opmode_register+0x6a/0xe0 [iwlwifi]
  ? 0xffffffffa0231000
  iwl_mvm_init+0x35/0x1000 [iwlmvm]
  ? 0xffffffffa0231000
  do_one_initcall+0x5a/0x1b0
  ? kmem_cache_alloc+0x1e5/0x2f0
  ? do_init_module+0x1e/0x220
  do_init_module+0x48/0x220
  load_module+0x2602/0x2bc0
  ? __kernel_read+0x145/0x2e0
  ? kernel_read_file+0x229/0x290
  __do_sys_finit_module+0xc5/0x130
  ? __do_sys_finit_module+0xc5/0x130
  __x64_sys_finit_module+0x13/0x20
  do_syscall_64+0x38/0x90
  entry_SYSCALL_64_after_hwframe+0x44/0xae
 RIP: 0033:0x7f64dda564dd
 Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1b 29 0f 00 f7 d8 64 89 01 48
 RSP: 002b:00007ffdba393f88 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f64dda564dd
 RDX: 0000000000000000 RSI: 00005575399e2ab2 RDI: 0000000000000001
 RBP: 000055753a91c5e0 R08: 0000000000000000 R09: 0000000000000002
 R10: 0000000000000001 R11: 0000000000000246 R12: 00005575399e2ab2
 R13: 000055753a91ceb0 R14: 0000000000000000 R15: 000055753a923018
  &lt;/TASK&gt;
 Modules linked in: btintel(+) btmtk bluetooth vfat snd_hda_codec_hdmi fat snd_hda_codec_realtek snd_hda_codec_generic iwlmvm(+) snd_sof_pci_intel_tgl mac80211 snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation soundwire_cadence soundwire_bus snd_sof_intel_hda snd_sof_pci snd_sof snd_sof_xtensa_dsp snd_soc_hdac_hda snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core btrfs snd_compress snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec raid6_pq iwlwifi snd_hda_core snd_pcm snd_timer snd soundcore cfg80211 intel_ish_ipc(+) thunderbolt rfkill intel_ishtp ucsi_acpi wmi i2c_hid_acpi i2c_hid evdev
 CR2: 000000000000004f
 ---[ end trace 0000000000000000 ]---

Check the debugfs_dir pointer for an error before using it.

[change to make both conditional]</Note>
    </Notes>
    <CVE>CVE-2022-48918</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 double free race when mount fails in cifs_get_root()

When cifs_get_root() fails during cifs_smb3_do_mount() we call
deactivate_locked_super() which eventually will call delayed_free() which
will free the context.
In this situation we should not proceed to enter the out: section in
cifs_smb3_do_mount() and free the same resources a second time.

[Thu Feb 10 12:59:06 2022] BUG: KASAN: use-after-free in rcu_cblist_dequeue+0x32/0x60
[Thu Feb 10 12:59:06 2022] Read of size 8 at addr ffff888364f4d110 by task swapper/1/0

[Thu Feb 10 12:59:06 2022] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G           OE     5.17.0-rc3+ #4
[Thu Feb 10 12:59:06 2022] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.0 12/17/2019
[Thu Feb 10 12:59:06 2022] Call Trace:
[Thu Feb 10 12:59:06 2022]  &lt;IRQ&gt;
[Thu Feb 10 12:59:06 2022]  dump_stack_lvl+0x5d/0x78
[Thu Feb 10 12:59:06 2022]  print_address_description.constprop.0+0x24/0x150
[Thu Feb 10 12:59:06 2022]  ? rcu_cblist_dequeue+0x32/0x60
[Thu Feb 10 12:59:06 2022]  kasan_report.cold+0x7d/0x117
[Thu Feb 10 12:59:06 2022]  ? rcu_cblist_dequeue+0x32/0x60
[Thu Feb 10 12:59:06 2022]  __asan_load8+0x86/0xa0
[Thu Feb 10 12:59:06 2022]  rcu_cblist_dequeue+0x32/0x60
[Thu Feb 10 12:59:06 2022]  rcu_core+0x547/0xca0
[Thu Feb 10 12:59:06 2022]  ? call_rcu+0x3c0/0x3c0
[Thu Feb 10 12:59:06 2022]  ? __this_cpu_preempt_check+0x13/0x20
[Thu Feb 10 12:59:06 2022]  ? lock_is_held_type+0xea/0x140
[Thu Feb 10 12:59:06 2022]  rcu_core_si+0xe/0x10
[Thu Feb 10 12:59:06 2022]  __do_softirq+0x1d4/0x67b
[Thu Feb 10 12:59:06 2022]  __irq_exit_rcu+0x100/0x150
[Thu Feb 10 12:59:06 2022]  irq_exit_rcu+0xe/0x30
[Thu Feb 10 12:59:06 2022]  sysvec_hyperv_stimer0+0x9d/0xc0
...
[Thu Feb 10 12:59:07 2022] Freed by task 58179:
[Thu Feb 10 12:59:07 2022]  kasan_save_stack+0x26/0x50
[Thu Feb 10 12:59:07 2022]  kasan_set_track+0x25/0x30
[Thu Feb 10 12:59:07 2022]  kasan_set_free_info+0x24/0x40
[Thu Feb 10 12:59:07 2022]  ____kasan_slab_free+0x137/0x170
[Thu Feb 10 12:59:07 2022]  __kasan_slab_free+0x12/0x20
[Thu Feb 10 12:59:07 2022]  slab_free_freelist_hook+0xb3/0x1d0
[Thu Feb 10 12:59:07 2022]  kfree+0xcd/0x520
[Thu Feb 10 12:59:07 2022]  cifs_smb3_do_mount+0x149/0xbe0 [cifs]
[Thu Feb 10 12:59:07 2022]  smb3_get_tree+0x1a0/0x2e0 [cifs]
[Thu Feb 10 12:59:07 2022]  vfs_get_tree+0x52/0x140
[Thu Feb 10 12:59:07 2022]  path_mount+0x635/0x10c0
[Thu Feb 10 12:59:07 2022]  __x64_sys_mount+0x1bf/0x210
[Thu Feb 10 12:59:07 2022]  do_syscall_64+0x5c/0xc0
[Thu Feb 10 12:59:07 2022]  entry_SYSCALL_64_after_hwframe+0x44/0xae

[Thu Feb 10 12:59:07 2022] Last potentially related work creation:
[Thu Feb 10 12:59:07 2022]  kasan_save_stack+0x26/0x50
[Thu Feb 10 12:59:07 2022]  __kasan_record_aux_stack+0xb6/0xc0
[Thu Feb 10 12:59:07 2022]  kasan_record_aux_stack_noalloc+0xb/0x10
[Thu Feb 10 12:59:07 2022]  call_rcu+0x76/0x3c0
[Thu Feb 10 12:59:07 2022]  cifs_umount+0xce/0xe0 [cifs]
[Thu Feb 10 12:59:07 2022]  cifs_kill_sb+0xc8/0xe0 [cifs]
[Thu Feb 10 12:59:07 2022]  deactivate_locked_super+0x5d/0xd0
[Thu Feb 10 12:59:07 2022]  cifs_smb3_do_mount+0xab9/0xbe0 [cifs]
[Thu Feb 10 12:59:07 2022]  smb3_get_tree+0x1a0/0x2e0 [cifs]
[Thu Feb 10 12:59:07 2022]  vfs_get_tree+0x52/0x140
[Thu Feb 10 12:59:07 2022]  path_mount+0x635/0x10c0
[Thu Feb 10 12:59:07 2022]  __x64_sys_mount+0x1bf/0x210
[Thu Feb 10 12:59:07 2022]  do_syscall_64+0x5c/0xc0
[Thu Feb 10 12:59:07 2022]  entry_SYSCALL_64_after_hwframe+0x44/0xae</Note>
    </Notes>
    <CVE>CVE-2022-48919</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: get rid of warning on transaction commit when using flushoncommit

When using the flushoncommit mount option, during almost every transaction
commit we trigger a warning from __writeback_inodes_sb_nr():

  $ cat fs/fs-writeback.c:
  (...)
  static void __writeback_inodes_sb_nr(struct super_block *sb, ...
  {
        (...)
        WARN_ON(!rwsem_is_locked(&amp;sb-&gt;s_umount));
        (...)
  }
  (...)

The trace produced in dmesg looks like the following:

  [947.473890] WARNING: CPU: 5 PID: 930 at fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3
  [947.481623] Modules linked in: nfsd nls_cp437 cifs asn1_decoder cifs_arc4 fscache cifs_md4 ipmi_ssif
  [947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti Not tainted 95.16.3-srb-asrock-00001-g36437ad63879 #186
  [947.497969] RIP: 0010:__writeback_inodes_sb_nr+0x7e/0xb3
  [947.502097] Code: 24 10 4c 89 44 24 18 c6 (...)
  [947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246
  [947.523818] RAX: 0000000000000000 RBX: 0000000000963300 RCX: 0000000000000000
  [947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50
  [947.535740] RBP: ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000
  [947.541701] R10: 0000000000000002 R11: 0000000000000001 R12: ffff888100963488
  [947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460
  [947.553621] FS:  0000000000000000(0000) GS:ffff88841fd40000(0000) knlGS:0000000000000000
  [947.560537] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e0
  [947.571072] Call Trace:
  [947.572354]  &lt;TASK&gt;
  [947.573266]  btrfs_commit_transaction+0x1f1/0x998
  [947.576785]  ? start_transaction+0x3ab/0x44e
  [947.579867]  ? schedule_timeout+0x8a/0xdd
  [947.582716]  transaction_kthread+0xe9/0x156
  [947.585721]  ? btrfs_cleanup_transaction.isra.0+0x407/0x407
  [947.590104]  kthread+0x131/0x139
  [947.592168]  ? set_kthread_struct+0x32/0x32
  [947.595174]  ret_from_fork+0x22/0x30
  [947.597561]  &lt;/TASK&gt;
  [947.598553] ---[ end trace 644721052755541c ]---

This is because we started using writeback_inodes_sb() to flush delalloc
when committing a transaction (when using -o flushoncommit), in order to
avoid deadlocks with filesystem freeze operations. This change was made
by commit ce8ea7cc6eb313 ("btrfs: don't call btrfs_start_delalloc_roots
in flushoncommit"). After that change we started producing that warning,
and every now and then a user reports this since the warning happens too
often, it spams dmesg/syslog, and a user is unsure if this reflects any
problem that might compromise the filesystem's reliability.

We can not just lock the sb-&gt;s_umount semaphore before calling
writeback_inodes_sb(), because that would at least deadlock with
filesystem freezing, since at fs/super.c:freeze_super() sync_filesystem()
is called while we are holding that semaphore in write mode, and that can
trigger a transaction commit, resulting in a deadlock. It would also
trigger the same type of deadlock in the unmount path. Possibly, it could
also introduce some other locking dependencies that lockdep would report.

To fix this call try_to_writeback_inodes_sb() instead of
writeback_inodes_sb(), because that will try to read lock sb-&gt;s_umount
and then will only call writeback_inodes_sb() if it was able to lock it.
This is fine because the cases where it can't read lock sb-&gt;s_umount
are during a filesystem unmount or during a filesystem freeze - in those
cases sb-&gt;s_umount is write locked and sync_filesystem() is called, which
calls writeback_inodes_sb(). In other words, in all cases where we can't
take a read lock on sb-&gt;s_umount, writeback is already being triggered
elsewhere.

An alternative would be to call btrfs_start_delalloc_roots() with a
number of pages different from LONG_MAX, for example matching the number
of delalloc bytes we currently have, in 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2022-48920</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/fair: Fix fault in reweight_entity

Syzbot found a GPF in reweight_entity. This has been bisected to
commit 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an invalid
sched_task_group")

There  is a race between sched_post_fork() and setpriority(PRIO_PGRP)
within a thread group that causes a null-ptr-deref  in
reweight_entity() in CFS. The scenario is that the main process spawns
number of new threads, which then call setpriority(PRIO_PGRP, 0, -20),
wait, and exit.  For each of the new threads the copy_process() gets
invoked, which adds the new task_struct and calls sched_post_fork()
for it.

In the above scenario there is a possibility that
setpriority(PRIO_PGRP) and set_one_prio() will be called for a thread
in the group that is just being created by copy_process(), and for
which the sched_post_fork() has not been executed yet. This will
trigger a null pointer dereference in reweight_entity(),  as it will
try to access the run queue pointer, which hasn't been set.

Before the mentioned change the cfs_rq pointer for the task  has been
set in sched_fork(), which is called much earlier in copy_process(),
before the new task is added to the thread_group.  Now it is done in
the sched_post_fork(), which is called after that.  To fix the issue
the remove the update_load param from the update_load param() function
and call reweight_task() only if the task flag doesn't have the
TASK_NEW flag set.</Note>
    </Notes>
    <CVE>CVE-2022-48921</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: prevent copying too big compressed lzo segment

Compressed length can be corrupted to be a lot larger than memory
we have allocated for buffer.
This will cause memcpy in copy_compressed_segment to write outside
of allocated memory.

This mostly results in stuck read syscall but sometimes when using
btrfs send can get #GP

  kernel: general protection fault, probably for non-canonical address 0x841551d5c1000: 0000 [#1] PREEMPT SMP NOPTI
  kernel: CPU: 17 PID: 264 Comm: kworker/u256:7 Tainted: P           OE     5.17.0-rc2-1 #12
  kernel: Workqueue: btrfs-endio btrfs_work_helper [btrfs]
  kernel: RIP: 0010:lzo_decompress_bio (./include/linux/fortify-string.h:225 fs/btrfs/lzo.c:322 fs/btrfs/lzo.c:394) btrfs
  Code starting with the faulting instruction
  ===========================================
     0:*  48 8b 06                mov    (%rsi),%rax              &lt;-- trapping instruction
     3:   48 8d 79 08             lea    0x8(%rcx),%rdi
     7:   48 83 e7 f8             and    $0xfffffffffffffff8,%rdi
     b:   48 89 01                mov    %rax,(%rcx)
     e:   44 89 f0                mov    %r14d,%eax
    11:   48 8b 54 06 f8          mov    -0x8(%rsi,%rax,1),%rdx
  kernel: RSP: 0018:ffffb110812efd50 EFLAGS: 00010212
  kernel: RAX: 0000000000001000 RBX: 000000009ca264c8 RCX: ffff98996e6d8ff8
  kernel: RDX: 0000000000000064 RSI: 000841551d5c1000 RDI: ffffffff9500435d
  kernel: RBP: ffff989a3be856c0 R08: 0000000000000000 R09: 0000000000000000
  kernel: R10: 0000000000000000 R11: 0000000000001000 R12: ffff98996e6d8000
  kernel: R13: 0000000000000008 R14: 0000000000001000 R15: 000841551d5c1000
  kernel: FS:  0000000000000000(0000) GS:ffff98a09d640000(0000) knlGS:0000000000000000
  kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  kernel: CR2: 00001e9f984d9ea8 CR3: 000000014971a000 CR4: 00000000003506e0
  kernel: Call Trace:
  kernel:  &lt;TASK&gt;
  kernel: end_compressed_bio_read (fs/btrfs/compression.c:104 fs/btrfs/compression.c:1363 fs/btrfs/compression.c:323) btrfs
  kernel: end_workqueue_fn (fs/btrfs/disk-io.c:1923) btrfs
  kernel: btrfs_work_helper (fs/btrfs/async-thread.c:326) btrfs
  kernel: process_one_work (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:212 ./include/trace/events/workqueue.h:108 kernel/workqueue.c:2312)
  kernel: worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2455)
  kernel: ? process_one_work (kernel/workqueue.c:2397)
  kernel: kthread (kernel/kthread.c:377)
  kernel: ? kthread_complete_and_exit (kernel/kthread.c:332)
  kernel: ret_from_fork (arch/x86/entry/entry_64.S:301)
  kernel:  &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2022-48923</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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: int340x: fix memory leak in int3400_notify()

It is easy to hit the below memory leaks in my TigerLake platform:

unreferenced object 0xffff927c8b91dbc0 (size 32):
  comm "kworker/0:2", pid 112, jiffies 4294893323 (age 83.604s)
  hex dump (first 32 bytes):
    4e 41 4d 45 3d 49 4e 54 33 34 30 30 20 54 68 65  NAME=INT3400 The
    72 6d 61 6c 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5  rmal.kkkkkkkkkk.
  backtrace:
    [&lt;ffffffff9c502c3e&gt;] __kmalloc_track_caller+0x2fe/0x4a0
    [&lt;ffffffff9c7b7c15&gt;] kvasprintf+0x65/0xd0
    [&lt;ffffffff9c7b7d6e&gt;] kasprintf+0x4e/0x70
    [&lt;ffffffffc04cb662&gt;] int3400_notify+0x82/0x120 [int3400_thermal]
    [&lt;ffffffff9c8b7358&gt;] acpi_ev_notify_dispatch+0x54/0x71
    [&lt;ffffffff9c88f1a7&gt;] acpi_os_execute_deferred+0x17/0x30
    [&lt;ffffffff9c2c2c0a&gt;] process_one_work+0x21a/0x3f0
    [&lt;ffffffff9c2c2e2a&gt;] worker_thread+0x4a/0x3b0
    [&lt;ffffffff9c2cb4dd&gt;] kthread+0xfd/0x130
    [&lt;ffffffff9c201c1f&gt;] ret_from_fork+0x1f/0x30

Fix it by calling kfree() accordingly.</Note>
    </Notes>
    <CVE>CVE-2022-48924</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/cma: Do not change route.addr.src_addr outside state checks

If the state is not idle then resolve_prepare_src() should immediately
fail and no change to global state should happen. However, it
unconditionally overwrites the src_addr trying to build a temporary any
address.

For instance if the state is already RDMA_CM_LISTEN then this will corrupt
the src_addr and would cause the test in cma_cancel_operation():

           if (cma_any_addr(cma_src_addr(id_priv)) &amp;&amp; !id_priv-&gt;cma_dev)

Which would manifest as this trace from syzkaller:

  BUG: KASAN: use-after-free in __list_add_valid+0x93/0xa0 lib/list_debug.c:26
  Read of size 8 at addr ffff8881546491e0 by task syz-executor.1/32204

  CPU: 1 PID: 32204 Comm: syz-executor.1 Not tainted 5.12.0-rc8-syzkaller #0
  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
  Call Trace:
   __dump_stack lib/dump_stack.c:79 [inline]
   dump_stack+0x141/0x1d7 lib/dump_stack.c:120
   print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:232
   __kasan_report mm/kasan/report.c:399 [inline]
   kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416
   __list_add_valid+0x93/0xa0 lib/list_debug.c:26
   __list_add include/linux/list.h:67 [inline]
   list_add_tail include/linux/list.h:100 [inline]
   cma_listen_on_all drivers/infiniband/core/cma.c:2557 [inline]
   rdma_listen+0x787/0xe00 drivers/infiniband/core/cma.c:3751
   ucma_listen+0x16a/0x210 drivers/infiniband/core/ucma.c:1102
   ucma_write+0x259/0x350 drivers/infiniband/core/ucma.c:1732
   vfs_write+0x28e/0xa30 fs/read_write.c:603
   ksys_write+0x1ee/0x250 fs/read_write.c:658
   do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
   entry_SYSCALL_64_after_hwframe+0x44/0xae

This is indicating that an rdma_id_private was destroyed without doing
cma_cancel_listens().

Instead of trying to re-use the src_addr memory to indirectly create an
any address derived from the dst build one explicitly on the stack and
bind to that as any other normal flow would do. rdma_bind_addr() will copy
it over the src_addr once it knows the state is valid.

This is similar to commit bc0bdc5afaa7 ("RDMA/cma: Do not change
route.addr.src_addr.ss_family")</Note>
    </Notes>
    <CVE>CVE-2022-48925</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: rndis: add spinlock for rndis response list

There's no lock for rndis response list. It could cause list corruption
if there're two different list_add at the same time like below.
It's better to add in rndis_add_response / rndis_free_response
/ rndis_get_next_response to prevent any race condition on response list.

[  361.894299] [1:   irq/191-dwc3:16979] list_add corruption.
next-&gt;prev should be prev (ffffff80651764d0),
but was ffffff883dc36f80. (next=ffffff80651764d0).

[  361.904380] [1:   irq/191-dwc3:16979] Call trace:
[  361.904391] [1:   irq/191-dwc3:16979]  __list_add_valid+0x74/0x90
[  361.904401] [1:   irq/191-dwc3:16979]  rndis_msg_parser+0x168/0x8c0
[  361.904409] [1:   irq/191-dwc3:16979]  rndis_command_complete+0x24/0x84
[  361.904417] [1:   irq/191-dwc3:16979]  usb_gadget_giveback_request+0x20/0xe4
[  361.904426] [1:   irq/191-dwc3:16979]  dwc3_gadget_giveback+0x44/0x60
[  361.904434] [1:   irq/191-dwc3:16979]  dwc3_ep0_complete_data+0x1e8/0x3a0
[  361.904442] [1:   irq/191-dwc3:16979]  dwc3_ep0_interrupt+0x29c/0x3dc
[  361.904450] [1:   irq/191-dwc3:16979]  dwc3_process_event_entry+0x78/0x6cc
[  361.904457] [1:   irq/191-dwc3:16979]  dwc3_process_event_buf+0xa0/0x1ec
[  361.904465] [1:   irq/191-dwc3:16979]  dwc3_thread_interrupt+0x34/0x5c</Note>
    </Notes>
    <CVE>CVE-2022-48926</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: tsc2046: fix memory corruption by preventing array overflow

On one side we have indio_dev-&gt;num_channels includes all physical channels +
timestamp channel. On other side we have an array allocated only for
physical channels. So, fix memory corruption by ARRAY_SIZE() instead of
num_channels variable.

Note the first case is a cleanup rather than a fix as the software
timestamp channel bit in active_scanmask is never set by the IIO core.</Note>
    </Notes>
    <CVE>CVE-2022-48927</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: men_z188_adc: Fix a resource leak in an error handling path

If iio_device_register() fails, a previous ioremap() is left unbalanced.

Update the error handling path and add the missing iounmap() call, as
already done in the remove function.</Note>
    </Notes>
    <CVE>CVE-2022-48928</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/ib_srp: Fix a deadlock

Remove the flush_workqueue(system_long_wq) call since flushing
system_long_wq is deadlock-prone and since that call is redundant with a
preceding cancel_work_sync()</Note>
    </Notes>
    <CVE>CVE-2022-48930</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

configfs: fix a race in configfs_{,un}register_subsystem()

When configfs_register_subsystem() or configfs_unregister_subsystem()
is executing link_group() or unlink_group(),
it is possible that two processes add or delete list concurrently.
Some unfortunate interleavings of them can cause kernel panic.

One of cases is:
A --&gt; B --&gt; C --&gt; D
A &lt;-- B &lt;-- C &lt;-- D

     delete list_head *B        |      delete list_head *C
--------------------------------|-----------------------------------
configfs_unregister_subsystem   |   configfs_unregister_subsystem
  unlink_group                  |     unlink_group
    unlink_obj                  |       unlink_obj
      list_del_init             |         list_del_init
        __list_del_entry        |           __list_del_entry
          __list_del            |             __list_del
            // next == C        |
            next-&gt;prev = prev   |
                                |               next-&gt;prev = prev
            prev-&gt;next = next   |
                                |                 // prev == B
                                |                 prev-&gt;next = next

Fix this by adding mutex when calling link_group() or unlink_group(),
but parent configfs_subsystem is NULL when config_item is root.
So I create a mutex configfs_subsystem_mutex.</Note>
    </Notes>
    <CVE>CVE-2022-48931</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: DR, Fix slab-out-of-bounds in mlx5_cmd_dr_create_fte

When adding a rule with 32 destinations, we hit the following out-of-band
access issue:

  BUG: KASAN: slab-out-of-bounds in mlx5_cmd_dr_create_fte+0x18ee/0x1e70

This patch fixes the issue by both increasing the allocated buffers to
accommodate for the needed actions and by checking the number of actions
to prevent this issue when a rule with too many actions is provided.</Note>
    </Notes>
    <CVE>CVE-2022-48932</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfp: flower: Fix a potential leak in nfp_tunnel_add_shared_mac()

ida_simple_get() returns an id between min (0) and max (NFP_MAX_MAC_INDEX)
inclusive.
So NFP_MAX_MAC_INDEX (0xff) is a valid id.

In order for the error handling path to work correctly, the 'invalid'
value for 'ida_idx' should not be in the 0..NFP_MAX_MAC_INDEX range,
inclusive.

So set it to -1.</Note>
    </Notes>
    <CVE>CVE-2022-48934</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: unregister flowtable hooks on netns exit

Unregister flowtable hooks before they are releases via
nf_tables_flowtable_destroy() otherwise hook core reports UAF.

BUG: KASAN: use-after-free in nf_hook_entries_grow+0x5a7/0x700 net/netfilter/core.c:142 net/netfilter/core.c:142
Read of size 4 at addr ffff8880736f7438 by task syz-executor579/3666

CPU: 0 PID: 3666 Comm: syz-executor579 Not tainted 5.16.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 __dump_stack lib/dump_stack.c:88 [inline] lib/dump_stack.c:106
 dump_stack_lvl+0x1dc/0x2d8 lib/dump_stack.c:106 lib/dump_stack.c:106
 print_address_description+0x65/0x380 mm/kasan/report.c:247 mm/kasan/report.c:247
 __kasan_report mm/kasan/report.c:433 [inline]
 __kasan_report mm/kasan/report.c:433 [inline] mm/kasan/report.c:450
 kasan_report+0x19a/0x1f0 mm/kasan/report.c:450 mm/kasan/report.c:450
 nf_hook_entries_grow+0x5a7/0x700 net/netfilter/core.c:142 net/netfilter/core.c:142
 __nf_register_net_hook+0x27e/0x8d0 net/netfilter/core.c:429 net/netfilter/core.c:429
 nf_register_net_hook+0xaa/0x180 net/netfilter/core.c:571 net/netfilter/core.c:571
 nft_register_flowtable_net_hooks+0x3c5/0x730 net/netfilter/nf_tables_api.c:7232 net/netfilter/nf_tables_api.c:7232
 nf_tables_newflowtable+0x2022/0x2cf0 net/netfilter/nf_tables_api.c:7430 net/netfilter/nf_tables_api.c:7430
 nfnetlink_rcv_batch net/netfilter/nfnetlink.c:513 [inline]
 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:634 [inline]
 nfnetlink_rcv_batch net/netfilter/nfnetlink.c:513 [inline] net/netfilter/nfnetlink.c:652
 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:634 [inline] net/netfilter/nfnetlink.c:652
 nfnetlink_rcv+0x10e6/0x2550 net/netfilter/nfnetlink.c:652 net/netfilter/nfnetlink.c:652

__nft_release_hook() calls nft_unregister_flowtable_net_hooks() which
only unregisters the hooks, then after RCU grace period, it is
guaranteed that no packets add new entries to the flowtable (no flow
offload rules and flowtable hooks are reachable from packet path), so it
is safe to call nf_flow_table_free() which cleans up the remaining
entries from the flowtable (both software and hardware) and it unbinds
the flow_block.</Note>
    </Notes>
    <CVE>CVE-2022-48935</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: add a schedule point in io_add_buffers()

Looping ~65535 times doing kmalloc() calls can trigger soft lockups,
especially with DEBUG features (like KASAN).

[  253.536212] watchdog: BUG: soft lockup - CPU#64 stuck for 26s! [b219417889:12575]
[  253.544433] Modules linked in: vfat fat i2c_mux_pca954x i2c_mux spidev cdc_acm xhci_pci xhci_hcd sha3_generic gq(O)
[  253.544451] CPU: 64 PID: 12575 Comm: b219417889 Tainted: G S         O      5.17.0-smp-DEV #801
[  253.544457] RIP: 0010:kernel_text_address (./include/asm-generic/sections.h:192 ./include/linux/kallsyms.h:29 kernel/extable.c:67 kernel/extable.c:98)
[  253.544464] Code: 0f 93 c0 48 c7 c1 e0 63 d7 a4 48 39 cb 0f 92 c1 20 c1 0f b6 c1 5b 5d c3 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 53 48 89 fb &lt;48&gt; c7 c0 00 00 80 a0 41 be 01 00 00 00 48 39 c7 72 0c 48 c7 c0 40
[  253.544468] RSP: 0018:ffff8882d8baf4c0 EFLAGS: 00000246
[  253.544471] RAX: 1ffff1105b175e00 RBX: ffffffffa13ef09a RCX: 00000000a13ef001
[  253.544474] RDX: ffffffffa13ef09a RSI: ffff8882d8baf558 RDI: ffffffffa13ef09a
[  253.544476] RBP: ffff8882d8baf4d8 R08: ffff8882d8baf5e0 R09: 0000000000000004
[  253.544479] R10: ffff8882d8baf5e8 R11: ffffffffa0d59a50 R12: ffff8882eab20380
[  253.544481] R13: ffffffffa0d59a50 R14: dffffc0000000000 R15: 1ffff1105b175eb0
[  253.544483] FS:  00000000016d3380(0000) GS:ffff88af48c00000(0000) knlGS:0000000000000000
[  253.544486] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  253.544488] CR2: 00000000004af0f0 CR3: 00000002eabfa004 CR4: 00000000003706e0
[  253.544491] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  253.544492] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  253.544494] Call Trace:
[  253.544496]  &lt;TASK&gt;
[  253.544498] ? io_queue_sqe (fs/io_uring.c:7143)
[  253.544505] __kernel_text_address (kernel/extable.c:78)
[  253.544508] unwind_get_return_address (arch/x86/kernel/unwind_frame.c:19)
[  253.544514] arch_stack_walk (arch/x86/kernel/stacktrace.c:27)
[  253.544517] ? io_queue_sqe (fs/io_uring.c:7143)
[  253.544521] stack_trace_save (kernel/stacktrace.c:123)
[  253.544527] ____kasan_kmalloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:515)
[  253.544531] ? ____kasan_kmalloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:515)
[  253.544533] ? __kasan_kmalloc (mm/kasan/common.c:524)
[  253.544535] ? kmem_cache_alloc_trace (./include/linux/kasan.h:270 mm/slab.c:3567)
[  253.544541] ? io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828)
[  253.544544] ? __io_queue_sqe (fs/io_uring.c:?)
[  253.544551] __kasan_kmalloc (mm/kasan/common.c:524)
[  253.544553] kmem_cache_alloc_trace (./include/linux/kasan.h:270 mm/slab.c:3567)
[  253.544556] ? io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828)
[  253.544560] io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828)
[  253.544564] ? __kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)
[  253.544567] ? __kasan_slab_alloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)
[  253.544569] ? kmem_cache_alloc_bulk (mm/slab.h:732 mm/slab.c:3546)
[  253.544573] ? __io_alloc_req_refill (fs/io_uring.c:2078)
[  253.544578] ? io_submit_sqes (fs/io_uring.c:7441)
[  253.544581] ? __se_sys_io_uring_enter (fs/io_uring.c:10154 fs/io_uring.c:10096)
[  253.544584] ? __x64_sys_io_uring_enter (fs/io_uring.c:10096)
[  253.544587] ? do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
[  253.544590] ? entry_SYSCALL_64_after_hwframe (??:?)
[  253.544596] __io_queue_sqe (fs/io_uring.c:?)
[  253.544600] io_queue_sqe (fs/io_uring.c:7143)
[  253.544603] io_submit_sqe (fs/io_uring.c:?)
[  253.544608] io_submit_sqes (fs/io_uring.c:?)
[  253.544612] __se_sys_io_uring_enter (fs/io_uring.c:10154 fs/io_uri
---truncated---</Note>
    </Notes>
    <CVE>CVE-2022-48937</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

CDC-NCM: avoid overflow in sanity checking

A broken device may give an extreme offset like 0xFFF0
and a reasonable length for a fragment. In the sanity
check as formulated now, this will create an integer
overflow, defeating the sanity check. Both offset
and offset + len need to be checked in such a manner
that no overflow can occur.
And those quantities should be unsigned.</Note>
    </Notes>
    <CVE>CVE-2022-48938</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Add schedule points in batch ops

syzbot reported various soft lockups caused by bpf batch operations.

 INFO: task kworker/1:1:27 blocked for more than 140 seconds.
 INFO: task hung in rcu_barrier

Nothing prevents batch ops to process huge amount of data,
we need to add schedule points in them.

Note that maybe_wait_bpf_programs(map) calls from
generic_map_delete_batch() can be factorized by moving
the call after the loop.

This will be done later in -next tree once we get this fix merged,
unless there is strong opinion doing this optimization sooner.</Note>
    </Notes>
    <CVE>CVE-2022-48939</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 crash due to incorrect copy_map_value

When both bpf_spin_lock and bpf_timer are present in a BPF map value,
copy_map_value needs to skirt both objects when copying a value into and
out of the map. However, the current code does not set both s_off and
t_off in copy_map_value, which leads to a crash when e.g. bpf_spin_lock
is placed in map value with bpf_timer, as bpf_map_update_elem call will
be able to overwrite the other timer object.

When the issue is not fixed, an overwriting can produce the following
splat:

[root@(none) bpf]# ./test_progs -t timer_crash
[   15.930339] bpf_testmod: loading out-of-tree module taints kernel.
[   16.037849] ==================================================================
[   16.038458] BUG: KASAN: user-memory-access in __pv_queued_spin_lock_slowpath+0x32b/0x520
[   16.038944] Write of size 8 at addr 0000000000043ec0 by task test_progs/325
[   16.039399]
[   16.039514] CPU: 0 PID: 325 Comm: test_progs Tainted: G           OE     5.16.0+ #278
[   16.039983] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ArchLinux 1.15.0-1 04/01/2014
[   16.040485] Call Trace:
[   16.040645]  &lt;TASK&gt;
[   16.040805]  dump_stack_lvl+0x59/0x73
[   16.041069]  ? __pv_queued_spin_lock_slowpath+0x32b/0x520
[   16.041427]  kasan_report.cold+0x116/0x11b
[   16.041673]  ? __pv_queued_spin_lock_slowpath+0x32b/0x520
[   16.042040]  __pv_queued_spin_lock_slowpath+0x32b/0x520
[   16.042328]  ? memcpy+0x39/0x60
[   16.042552]  ? pv_hash+0xd0/0xd0
[   16.042785]  ? lockdep_hardirqs_off+0x95/0xd0
[   16.043079]  __bpf_spin_lock_irqsave+0xdf/0xf0
[   16.043366]  ? bpf_get_current_comm+0x50/0x50
[   16.043608]  ? jhash+0x11a/0x270
[   16.043848]  bpf_timer_cancel+0x34/0xe0
[   16.044119]  bpf_prog_c4ea1c0f7449940d_sys_enter+0x7c/0x81
[   16.044500]  bpf_trampoline_6442477838_0+0x36/0x1000
[   16.044836]  __x64_sys_nanosleep+0x5/0x140
[   16.045119]  do_syscall_64+0x59/0x80
[   16.045377]  ? lock_is_held_type+0xe4/0x140
[   16.045670]  ? irqentry_exit_to_user_mode+0xa/0x40
[   16.046001]  ? mark_held_locks+0x24/0x90
[   16.046287]  ? asm_exc_page_fault+0x1e/0x30
[   16.046569]  ? asm_exc_page_fault+0x8/0x30
[   16.046851]  ? lockdep_hardirqs_on+0x7e/0x100
[   16.047137]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[   16.047405] RIP: 0033:0x7f9e4831718d
[   16.047602] Code: b4 0c 00 0f 05 eb a9 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d b3 6c 0c 00 f7 d8 64 89 01 48
[   16.048764] RSP: 002b:00007fff488086b8 EFLAGS: 00000206 ORIG_RAX: 0000000000000023
[   16.049275] RAX: ffffffffffffffda RBX: 00007f9e48683740 RCX: 00007f9e4831718d
[   16.049747] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007fff488086d0
[   16.050225] RBP: 00007fff488086f0 R08: 00007fff488085d7 R09: 00007f9e4cb594a0
[   16.050648] R10: 0000000000000000 R11: 0000000000000206 R12: 00007f9e484cde30
[   16.051124] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[   16.051608]  &lt;/TASK&gt;
[   16.051762] ==================================================================</Note>
    </Notes>
    <CVE>CVE-2022-48940</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 concurrent reset and removal of VFs

Commit c503e63200c6 ("ice: Stop processing VF messages during teardown")
introduced a driver state flag, ICE_VF_DEINIT_IN_PROGRESS, which is
intended to prevent some issues with concurrently handling messages from
VFs while tearing down the VFs.

This change was motivated by crashes caused while tearing down and
bringing up VFs in rapid succession.

It turns out that the fix actually introduces issues with the VF driver
caused because the PF no longer responds to any messages sent by the VF
during its .remove routine. This results in the VF potentially removing
its DMA memory before the PF has shut down the device queues.

Additionally, the fix doesn't actually resolve concurrency issues within
the ice driver. It is possible for a VF to initiate a reset just prior
to the ice driver removing VFs. This can result in the remove task
concurrently operating while the VF is being reset. This results in
similar memory corruption and panics purportedly fixed by that commit.

Fix this concurrency at its root by protecting both the reset and
removal flows using the existing VF cfg_lock. This ensures that we
cannot remove the VF while any outstanding critical tasks such as a
virtchnl message or a reset are occurring.

This locking change also fixes the root cause originally fixed by commit
c503e63200c6 ("ice: Stop processing VF messages during teardown"), so we
can simply revert it.

Note that I kept these two changes together because simply reverting the
original commit alone would leave the driver vulnerable to worse race
conditions.</Note>
    </Notes>
    <CVE>CVE-2022-48941</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hwmon: Handle failure to register sensor with thermal zone correctly

If an attempt is made to a sensor with a thermal zone and it fails,
the call to devm_thermal_zone_of_sensor_register() may return -ENODEV.
This may result in crashes similar to the following.

Unable to handle kernel NULL pointer dereference at virtual address 00000000000003cd
...
Internal error: Oops: 96000021 [#1] PREEMPT SMP
...
pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : mutex_lock+0x18/0x60
lr : thermal_zone_device_update+0x40/0x2e0
sp : ffff800014c4fc60
x29: ffff800014c4fc60 x28: ffff365ee3f6e000 x27: ffffdde218426790
x26: ffff365ee3f6e000 x25: 0000000000000000 x24: ffff365ee3f6e000
x23: ffffdde218426870 x22: ffff365ee3f6e000 x21: 00000000000003cd
x20: ffff365ee8bf3308 x19: ffffffffffffffed x18: 0000000000000000
x17: ffffdde21842689c x16: ffffdde1cb7a0b7c x15: 0000000000000040
x14: ffffdde21a4889a0 x13: 0000000000000228 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
x8 : 0000000001120000 x7 : 0000000000000001 x6 : 0000000000000000
x5 : 0068000878e20f07 x4 : 0000000000000000 x3 : 00000000000003cd
x2 : ffff365ee3f6e000 x1 : 0000000000000000 x0 : 00000000000003cd
Call trace:
 mutex_lock+0x18/0x60
 hwmon_notify_event+0xfc/0x110
 0xffffdde1cb7a0a90
 0xffffdde1cb7a0b7c
 irq_thread_fn+0x2c/0xa0
 irq_thread+0x134/0x240
 kthread+0x178/0x190
 ret_from_fork+0x10/0x20
Code: d503201f d503201f d2800001 aa0103e4 (c8e47c02)

Jon Hunter reports that the exact call sequence is:

hwmon_notify_event()
  --&gt; hwmon_thermal_notify()
    --&gt; thermal_zone_device_update()
      --&gt; update_temperature()
        --&gt; mutex_lock()

The hwmon core needs to handle all errors returned from calls
to devm_thermal_zone_of_sensor_register(). If the call fails
with -ENODEV, report that the sensor was not attached to a
thermal zone  but continue to register the hwmon device.</Note>
    </Notes>
    <CVE>CVE-2022-48942</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/mmu: make apf token non-zero to fix bug

In current async pagefault logic, when a page is ready, KVM relies on
kvm_arch_can_dequeue_async_page_present() to determine whether to deliver
a READY event to the Guest. This function test token value of struct
kvm_vcpu_pv_apf_data, which must be reset to zero by Guest kernel when a
READY event is finished by Guest. If value is zero meaning that a READY
event is done, so the KVM can deliver another.
But the kvm_arch_setup_async_pf() may produce a valid token with zero
value, which is confused with previous mention and may lead the loss of
this READY event.

This bug may cause task blocked forever in Guest:
 INFO: task stress:7532 blocked for more than 1254 seconds.
       Not tainted 5.10.0 #16
 "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
 task:stress          state:D stack:    0 pid: 7532 ppid:  1409
 flags:0x00000080
 Call Trace:
  __schedule+0x1e7/0x650
  schedule+0x46/0xb0
  kvm_async_pf_task_wait_schedule+0xad/0xe0
  ? exit_to_user_mode_prepare+0x60/0x70
  __kvm_handle_async_pf+0x4f/0xb0
  ? asm_exc_page_fault+0x8/0x30
  exc_page_fault+0x6f/0x110
  ? asm_exc_page_fault+0x8/0x30
  asm_exc_page_fault+0x1e/0x30
 RIP: 0033:0x402d00
 RSP: 002b:00007ffd31912500 EFLAGS: 00010206
 RAX: 0000000000071000 RBX: ffffffffffffffff RCX: 00000000021a32b0
 RDX: 000000000007d011 RSI: 000000000007d000 RDI: 00000000021262b0
 RBP: 00000000021262b0 R08: 0000000000000003 R09: 0000000000000086
 R10: 00000000000000eb R11: 00007fefbdf2baa0 R12: 0000000000000000
 R13: 0000000000000002 R14: 000000000007d000 R15: 0000000000001000</Note>
    </Notes>
    <CVE>CVE-2022-48943</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix yet more sched_fork() races

Where commit 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an
invalid sched_task_group") fixed a fork race vs cgroup, it opened up a
race vs syscalls by not placing the task on the runqueue before it
gets exposed through the pidhash.

Commit 13765de8148f ("sched/fair: Fix fault in reweight_entity") is
trying to fix a single instance of this, instead fix the whole class
of issues, effectively reverting this commit.</Note>
    </Notes>
    <CVE>CVE-2022-48944</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: vivid: fix compose size exceed boundary

syzkaller found a bug:

 BUG: unable to handle page fault for address: ffffc9000a3b1000
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 100000067 P4D 100000067 PUD 10015f067 PMD 1121ca067 PTE 0
 Oops: 0002 [#1] PREEMPT SMP
 CPU: 0 PID: 23489 Comm: vivid-000-vid-c Not tainted 6.1.0-rc1+ #512
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
 RIP: 0010:memcpy_erms+0x6/0x10
[...]
 Call Trace:
  &lt;TASK&gt;
  ? tpg_fill_plane_buffer+0x856/0x15b0
  vivid_fillbuff+0x8ac/0x1110
  vivid_thread_vid_cap_tick+0x361/0xc90
  vivid_thread_vid_cap+0x21a/0x3a0
  kthread+0x143/0x180
  ret_from_fork+0x1f/0x30
  &lt;/TASK&gt;

This is because we forget to check boundary after adjust compose-&gt;height
int V4L2_SEL_TGT_CROP case. Add v4l2_rect_map_inside() to fix this problem
for this case.</Note>
    </Notes>
    <CVE>CVE-2022-48945</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

udf: Fix preallocation discarding at indirect extent boundary

When preallocation extent is the first one in the extent block, the
code would corrupt extent tree header instead. Fix the problem and use
udf_delete_aext() for deleting extent to avoid some code duplication.</Note>
    </Notes>
    <CVE>CVE-2022-48946</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: uvc: Prevent buffer overflow in setup handler

Setup function uvc_function_setup permits control transfer
requests with up to 64 bytes of payload (UVC_MAX_REQUEST_SIZE),
data stage handler for OUT transfer uses memcpy to copy req-&gt;actual
bytes to uvc_event-&gt;data.data array of size 60. This may result
in an overflow of 4 bytes.</Note>
    </Notes>
    <CVE>CVE-2022-48948</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Initialize mailbox message for VF reset

When a MAC address is not assigned to the VF, that portion of the message
sent to the VF is not set. The memory, however, is allocated from the
stack meaning that information may be leaked to the VM. Initialize the
message buffer to 0 so that no information is passed to the VM in this
case.</Note>
    </Notes>
    <CVE>CVE-2022-48949</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ops: Check bounds for second channel in snd_soc_put_volsw_sx()

The bounds checks in snd_soc_put_volsw_sx() are only being applied to the
first channel, meaning it is possible to write out of bounds values to the
second channel in stereo controls. Add appropriate checks.</Note>
    </Notes>
    <CVE>CVE-2022-48951</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

rtc: cmos: Fix event handler registration ordering issue

Because acpi_install_fixed_event_handler() enables the event
automatically on success, it is incorrect to call it before the
handler routine passed to it is ready to handle events.

Unfortunately, the rtc-cmos driver does exactly the incorrect thing
by calling cmos_wake_setup(), which passes rtc_handler() to
acpi_install_fixed_event_handler(), before cmos_do_probe(), because
rtc_handler() uses dev_get_drvdata() to get to the cmos object
pointer and the driver data pointer is only populated in
cmos_do_probe().

This leads to a NULL pointer dereference in rtc_handler() on boot
if the RTC fixed event happens to be active at the init time.

To address this issue, change the initialization ordering of the
driver so that cmos_wake_setup() is always called after a successful
cmos_do_probe() call.

While at it, change cmos_pnp_probe() to call cmos_do_probe() after
the initial if () statement used for computing the IRQ argument to
be passed to cmos_do_probe() which is cleaner than calling it in
each branch of that if () (local variable "irq" can be of type int,
because it is passed to that function as an argument of type int).

Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check
ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number
of systems, because previously it only affected systems with
ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that
commit.</Note>
    </Notes>
    <CVE>CVE-2022-48953</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/qeth: fix use-after-free in hsci

KASAN found that addr was dereferenced after br2dev_event_work was freed.

==================================================================
BUG: KASAN: use-after-free in qeth_l2_br2dev_worker+0x5ba/0x6b0
Read of size 1 at addr 00000000fdcea440 by task kworker/u760:4/540
CPU: 17 PID: 540 Comm: kworker/u760:4 Tainted: G            E      6.1.0-20221128.rc7.git1.5aa3bed4ce83.300.fc36.s390x+kasan #1
Hardware name: IBM 8561 T01 703 (LPAR)
Workqueue: 0.0.8000_event qeth_l2_br2dev_worker
Call Trace:
 [&lt;000000016944d4ce&gt;] dump_stack_lvl+0xc6/0xf8
 [&lt;000000016942cd9c&gt;] print_address_description.constprop.0+0x34/0x2a0
 [&lt;000000016942d118&gt;] print_report+0x110/0x1f8
 [&lt;0000000167a7bd04&gt;] kasan_report+0xfc/0x128
 [&lt;000000016938d79a&gt;] qeth_l2_br2dev_worker+0x5ba/0x6b0
 [&lt;00000001673edd1e&gt;] process_one_work+0x76e/0x1128
 [&lt;00000001673ee85c&gt;] worker_thread+0x184/0x1098
 [&lt;000000016740718a&gt;] kthread+0x26a/0x310
 [&lt;00000001672c606a&gt;] __ret_from_fork+0x8a/0xe8
 [&lt;00000001694711da&gt;] ret_from_fork+0xa/0x40
Allocated by task 108338:
 kasan_save_stack+0x40/0x68
 kasan_set_track+0x36/0x48
 __kasan_kmalloc+0xa0/0xc0
 qeth_l2_switchdev_event+0x25a/0x738
 atomic_notifier_call_chain+0x9c/0xf8
 br_switchdev_fdb_notify+0xf4/0x110
 fdb_notify+0x122/0x180
 fdb_add_entry.constprop.0.isra.0+0x312/0x558
 br_fdb_add+0x59e/0x858
 rtnl_fdb_add+0x58a/0x928
 rtnetlink_rcv_msg+0x5f8/0x8d8
 netlink_rcv_skb+0x1f2/0x408
 netlink_unicast+0x570/0x790
 netlink_sendmsg+0x752/0xbe0
 sock_sendmsg+0xca/0x110
 ____sys_sendmsg+0x510/0x6a8
 ___sys_sendmsg+0x12a/0x180
 __sys_sendmsg+0xe6/0x168
 __do_sys_socketcall+0x3c8/0x468
 do_syscall+0x22c/0x328
 __do_syscall+0x94/0xf0
 system_call+0x82/0xb0
Freed by task 540:
 kasan_save_stack+0x40/0x68
 kasan_set_track+0x36/0x48
 kasan_save_free_info+0x4c/0x68
 ____kasan_slab_free+0x14e/0x1a8
 __kasan_slab_free+0x24/0x30
 __kmem_cache_free+0x168/0x338
 qeth_l2_br2dev_worker+0x154/0x6b0
 process_one_work+0x76e/0x1128
 worker_thread+0x184/0x1098
 kthread+0x26a/0x310
 __ret_from_fork+0x8a/0xe8
 ret_from_fork+0xa/0x40
Last potentially related work creation:
 kasan_save_stack+0x40/0x68
 __kasan_record_aux_stack+0xbe/0xd0
 insert_work+0x56/0x2e8
 __queue_work+0x4ce/0xd10
 queue_work_on+0xf4/0x100
 qeth_l2_switchdev_event+0x520/0x738
 atomic_notifier_call_chain+0x9c/0xf8
 br_switchdev_fdb_notify+0xf4/0x110
 fdb_notify+0x122/0x180
 fdb_add_entry.constprop.0.isra.0+0x312/0x558
 br_fdb_add+0x59e/0x858
 rtnl_fdb_add+0x58a/0x928
 rtnetlink_rcv_msg+0x5f8/0x8d8
 netlink_rcv_skb+0x1f2/0x408
 netlink_unicast+0x570/0x790
 netlink_sendmsg+0x752/0xbe0
 sock_sendmsg+0xca/0x110
 ____sys_sendmsg+0x510/0x6a8
 ___sys_sendmsg+0x12a/0x180
 __sys_sendmsg+0xe6/0x168
 __do_sys_socketcall+0x3c8/0x468
 do_syscall+0x22c/0x328
 __do_syscall+0x94/0xf0
 system_call+0x82/0xb0
Second to last potentially related work creation:
 kasan_save_stack+0x40/0x68
 __kasan_record_aux_stack+0xbe/0xd0
 kvfree_call_rcu+0xb2/0x760
 kernfs_unlink_open_file+0x348/0x430
 kernfs_fop_release+0xc2/0x320
 __fput+0x1ae/0x768
 task_work_run+0x1bc/0x298
 exit_to_user_mode_prepare+0x1a0/0x1a8
 __do_syscall+0x94/0xf0
 system_call+0x82/0xb0
The buggy address belongs to the object at 00000000fdcea400
 which belongs to the cache kmalloc-96 of size 96
The buggy address is located 64 bytes inside of
 96-byte region [00000000fdcea400, 00000000fdcea460)
The buggy address belongs to the physical page:
page:000000005a9c26e8 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xfdcea
flags: 0x3ffff00000000200(slab|node=0|zone=1|lastcpupid=0x1ffff)
raw: 3ffff00000000200 0000000000000000 0000000100000122 000000008008cc00
raw: 0000000000000000 0020004100000000 ffffffff00000001 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
 00000000fdcea300: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
 00000000fdcea380: fb fb fb fb fb fb f
---truncated---</Note>
    </Notes>
    <CVE>CVE-2022-48954</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: thunderbolt: fix memory leak in tbnet_open()

When tb_ring_alloc_rx() failed in tbnet_open(), ida that allocated in
tb_xdomain_alloc_out_hopid() is not released. Add
tb_xdomain_release_out_hopid() to the error path to release ida.</Note>
    </Notes>
    <CVE>CVE-2022-48955</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 use-after-free in ip6_fragment()

Blamed commit claimed rcu_read_lock() was held by ip6_fragment() callers.

It seems to not be always true, at least for UDP stack.

syzbot reported:

BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:245 [inline]
BUG: KASAN: use-after-free in ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951
Read of size 8 at addr ffff88801d403e80 by task syz-executor.3/7618

CPU: 1 PID: 7618 Comm: syz-executor.3 Not tainted 6.1.0-rc6-syzkaller-00012-g4312098baf37 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:284 [inline]
 print_report+0x15e/0x45d mm/kasan/report.c:395
 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495
 ip6_dst_idev include/net/ip6_fib.h:245 [inline]
 ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951
 __ip6_finish_output net/ipv6/ip6_output.c:193 [inline]
 ip6_finish_output+0x9a3/0x1170 net/ipv6/ip6_output.c:206
 NF_HOOK_COND include/linux/netfilter.h:291 [inline]
 ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227
 dst_output include/net/dst.h:445 [inline]
 ip6_local_out+0xb3/0x1a0 net/ipv6/output_core.c:161
 ip6_send_skb+0xbb/0x340 net/ipv6/ip6_output.c:1966
 udp_v6_send_skb+0x82a/0x18a0 net/ipv6/udp.c:1286
 udp_v6_push_pending_frames+0x140/0x200 net/ipv6/udp.c:1313
 udpv6_sendmsg+0x18da/0x2c80 net/ipv6/udp.c:1606
 inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665
 sock_sendmsg_nosec net/socket.c:714 [inline]
 sock_sendmsg+0xd3/0x120 net/socket.c:734
 sock_write_iter+0x295/0x3d0 net/socket.c:1108
 call_write_iter include/linux/fs.h:2191 [inline]
 new_sync_write fs/read_write.c:491 [inline]
 vfs_write+0x9ed/0xdd0 fs/read_write.c:584
 ksys_write+0x1ec/0x250 fs/read_write.c:637
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fde3588c0d9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &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:00007fde365b6168 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007fde359ac050 RCX: 00007fde3588c0d9
RDX: 000000000000ffdc RSI: 00000000200000c0 RDI: 000000000000000a
RBP: 00007fde358e7ae9 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fde35acfb1f R14: 00007fde365b6300 R15: 0000000000022000
 &lt;/TASK&gt;

Allocated by task 7618:
 kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
 kasan_set_track+0x25/0x30 mm/kasan/common.c:52
 __kasan_slab_alloc+0x82/0x90 mm/kasan/common.c:325
 kasan_slab_alloc include/linux/kasan.h:201 [inline]
 slab_post_alloc_hook mm/slab.h:737 [inline]
 slab_alloc_node mm/slub.c:3398 [inline]
 slab_alloc mm/slub.c:3406 [inline]
 __kmem_cache_alloc_lru mm/slub.c:3413 [inline]
 kmem_cache_alloc+0x2b4/0x3d0 mm/slub.c:3422
 dst_alloc+0x14a/0x1f0 net/core/dst.c:92
 ip6_dst_alloc+0x32/0xa0 net/ipv6/route.c:344
 ip6_rt_pcpu_alloc net/ipv6/route.c:1369 [inline]
 rt6_make_pcpu_route net/ipv6/route.c:1417 [inline]
 ip6_pol_route+0x901/0x1190 net/ipv6/route.c:2254
 pol_lookup_func include/net/ip6_fib.h:582 [inline]
 fib6_rule_lookup+0x52e/0x6f0 net/ipv6/fib6_rules.c:121
 ip6_route_output_flags_noref+0x2e6/0x380 net/ipv6/route.c:2625
 ip6_route_output_flags+0x76/0x320 net/ipv6/route.c:2638
 ip6_route_output include/net/ip6_route.h:98 [inline]
 ip6_dst_lookup_tail+0x5ab/0x1620 net/ipv6/ip6_output.c:1092
 ip6_dst_lookup_flow+0x90/0x1d0 net/ipv6/ip6_output.c:1222
 ip6_sk_dst_lookup_flow+0x553/0x980 net/ipv6/ip6_output.c:1260
 udpv6_sendmsg+0x151d/0x2c80 net/ipv6/udp.c:1554
 inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665
 sock_sendmsg_nosec n
---truncated---</Note>
    </Notes>
    <CVE>CVE-2022-48956</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

dpaa2-switch: Fix memory leak in dpaa2_switch_acl_entry_add() and dpaa2_switch_acl_entry_remove()

The cmd_buff needs to be freed when error happened in
dpaa2_switch_acl_entry_add() and dpaa2_switch_acl_entry_remove().</Note>
    </Notes>
    <CVE>CVE-2022-48957</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ethernet: aeroflex: fix potential skb leak in greth_init_rings()

The greth_init_rings() function won't free the newly allocated skb when
dma_mapping_error() returns error, so add dev_kfree_skb() to fix it.

Compile tested only.</Note>
    </Notes>
    <CVE>CVE-2022-48958</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sja1105: fix memory leak in sja1105_setup_devlink_regions()

When dsa_devlink_region_create failed in sja1105_setup_devlink_regions(),
priv-&gt;regions is not released.</Note>
    </Notes>
    <CVE>CVE-2022-48959</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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: hisilicon: Fix potential use-after-free in hix5hd2_rx()

The skb is delivered to napi_gro_receive() which may free it, after
calling this, dereferencing skb may trigger use-after-free.</Note>
    </Notes>
    <CVE>CVE-2022-48960</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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: mdio: fix unbalanced fwnode reference count in mdio_device_release()

There is warning report about of_node refcount leak
while probing mdio device:

OF: ERROR: memory leak, expected refcount 1 instead of 2,
of_node_get()/of_node_put() unbalanced - destroy cset entry:
attach overlay node /spi/soc@0/mdio@710700c0/ethernet@4

In of_mdiobus_register_device(), we increase fwnode refcount
by fwnode_handle_get() before associating the of_node with
mdio device, but it has never been decreased in normal path.
Since that, in mdio_device_release(), it needs to call
fwnode_handle_put() in addition instead of calling kfree()
directly.

After above, just calling mdio_device_free() in the error handle
path of of_mdiobus_register_device() is enough to keep the
refcount balanced.</Note>
    </Notes>
    <CVE>CVE-2022-48961</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: hisilicon: Fix potential use-after-free in hisi_femac_rx()

The skb is delivered to napi_gro_receive() which may free it, after
calling this, dereferencing skb may trigger use-after-free.</Note>
    </Notes>
    <CVE>CVE-2022-48962</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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: mvneta: Prevent out of bounds read in mvneta_config_rss()

The pp-&gt;indir[0] value comes from the user.  It is passed to:

	if (cpu_online(pp-&gt;rxq_def))

inside the mvneta_percpu_elect() function.  It needs bounds checkeding
to ensure that it is not beyond the end of the cpu bitmap.</Note>
    </Notes>
    <CVE>CVE-2022-48966</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Bounds check struct nfc_target arrays

While running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported:

  memcpy: detected field-spanning write (size 129) of single field "target-&gt;sensf_res" at net/nfc/nci/ntf.c:260 (size 18)

This appears to be a legitimate lack of bounds checking in
nci_add_new_protocol(). Add the missing checks.</Note>
    </Notes>
    <CVE>CVE-2022-48967</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

octeontx2-pf: Fix potential memory leak in otx2_init_tc()

In otx2_init_tc(), if rhashtable_init() failed, it does not free
tc-&gt;tc_entries_bitmap which is allocated in otx2_tc_alloc_ent_bitmap().</Note>
    </Notes>
    <CVE>CVE-2022-48968</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 NULL sring after live migration

A NAPI is setup for each network sring to poll data to kernel
The sring with source host is destroyed before live migration and
new sring with target host is setup after live migration.
The NAPI for the old sring is not deleted until setup new sring
with target host after migration. With busy_poll/busy_read enabled,
the NAPI can be polled before got deleted when resume VM.

BUG: unable to handle kernel NULL pointer dereference at
0000000000000008
IP: xennet_poll+0xae/0xd20
PGD 0 P4D 0
Oops: 0000 [#1] SMP PTI
Call Trace:
 finish_task_switch+0x71/0x230
 timerqueue_del+0x1d/0x40
 hrtimer_try_to_cancel+0xb5/0x110
 xennet_alloc_rx_buffers+0x2a0/0x2a0
 napi_busy_loop+0xdb/0x270
 sock_poll+0x87/0x90
 do_sys_poll+0x26f/0x580
 tracing_map_insert+0x1d4/0x2f0
 event_hist_trigger+0x14a/0x260

 finish_task_switch+0x71/0x230
 __schedule+0x256/0x890
 recalc_sigpending+0x1b/0x50
 xen_sched_clock+0x15/0x20
 __rb_reserve_next+0x12d/0x140
 ring_buffer_lock_reserve+0x123/0x3d0
 event_triggers_call+0x87/0xb0
 trace_event_buffer_commit+0x1c4/0x210
 xen_clocksource_get_cycles+0x15/0x20
 ktime_get_ts64+0x51/0xf0
 SyS_ppoll+0x160/0x1a0
 SyS_ppoll+0x160/0x1a0
 do_syscall_64+0x73/0x130
 entry_SYSCALL_64_after_hwframe+0x41/0xa6
...
RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900
CR2: 0000000000000008
---[ end trace f8601785b354351c ]---

xen frontend should remove the NAPIs for the old srings before live
migration as the bond srings are destroyed

There is a tiny window between the srings are set to NULL and
the NAPIs are disabled, It is safe as the NAPI threads are still
frozen at that time</Note>
    </Notes>
    <CVE>CVE-2022-48969</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 not cleanup led when bt_init fails

bt_init() calls bt_leds_init() to register led, but if it fails later,
bt_leds_cleanup() is not called to unregister it.

This can cause panic if the argument "bluetooth-power" in text is freed
and then another led_trigger_register() tries to access it:

BUG: unable to handle page fault for address: ffffffffc06d3bc0
RIP: 0010:strcmp+0xc/0x30
  Call Trace:
    &lt;TASK&gt;
    led_trigger_register+0x10d/0x4f0
    led_trigger_register_simple+0x7d/0x100
    bt_init+0x39/0xf7 [bluetooth]
    do_one_initcall+0xd0/0x4e0</Note>
    </Notes>
    <CVE>CVE-2022-48971</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add()

Kernel fault injection test reports null-ptr-deref as follows:

BUG: kernel NULL pointer dereference, address: 0000000000000008
RIP: 0010:cfg802154_netdev_notifier_call+0x120/0x310 include/linux/list.h:114
Call Trace:
 &lt;TASK&gt;
 raw_notifier_call_chain+0x6d/0xa0 kernel/notifier.c:87
 call_netdevice_notifiers_info+0x6e/0xc0 net/core/dev.c:1944
 unregister_netdevice_many_notify+0x60d/0xcb0 net/core/dev.c:1982
 unregister_netdevice_queue+0x154/0x1a0 net/core/dev.c:10879
 register_netdevice+0x9a8/0xb90 net/core/dev.c:10083
 ieee802154_if_add+0x6ed/0x7e0 net/mac802154/iface.c:659
 ieee802154_register_hw+0x29c/0x330 net/mac802154/main.c:229
 mcr20a_probe+0xaaa/0xcb1 drivers/net/ieee802154/mcr20a.c:1316

ieee802154_if_add() allocates wpan_dev as netdev's private data, but not
init the list in struct wpan_dev. cfg802154_netdev_notifier_call() manage
the list when device register/unregister, and may lead to null-ptr-deref.

Use INIT_LIST_HEAD() on it to initialize it correctly.</Note>
    </Notes>
    <CVE>CVE-2022-48972</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gpio: amd8111: Fix PCI device reference count leak

for_each_pci_dev() is implemented by pci_get_device(). The comment of
pci_get_device() says that it will increase the reference count for the
returned pci_dev and also decrease the reference count for the input
pci_dev @from if it is not NULL.

If we break for_each_pci_dev() loop with pdev not NULL, we need to call
pci_dev_put() to decrease the reference count. Add the missing
pci_dev_put() after the 'out' label. Since pci_dev_put() can handle NULL
input parameter, there is no problem for the 'Device not found' branch.
For the normal path, add pci_dev_put() in amd_gpio_exit().</Note>
    </Notes>
    <CVE>CVE-2022-48973</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gpiolib: fix memory leak in gpiochip_setup_dev()

Here is a backtrace report about memory leak detected in
gpiochip_setup_dev():

unreferenced object 0xffff88810b406400 (size 512):
  comm "python3", pid 1682, jiffies 4295346908 (age 24.090s)
  backtrace:
    kmalloc_trace
    device_add		device_private_init at drivers/base/core.c:3361
			(inlined by) device_add at drivers/base/core.c:3411
    cdev_device_add
    gpiolib_cdev_register
    gpiochip_setup_dev
    gpiochip_add_data_with_key

gcdev_register() &amp; gcdev_unregister() would call device_add() &amp;
device_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to
register/unregister device.

However, if device_add() succeeds, some resource (like
struct device_private allocated by device_private_init())
is not released by device_del().

Therefore, after device_add() succeeds by gcdev_register(), it
needs to call put_device() to release resource in the error handle
path.

Here we move forward the register of release function, and let it
release every piece of resource by put_device() instead of kfree().

While at it, fix another subtle issue, i.e. when gc-&gt;ngpio is equal
to 0, we still call kcalloc() and, in case of further error, kfree()
on the ZERO_PTR pointer, which is not NULL. It's not a bug per se,
but rather waste of the resources and potentially wrong expectation
about contents of the gdev-&gt;descs variable.</Note>
    </Notes>
    <CVE>CVE-2022-48975</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix shift-out-of-bounds in hid_report_raw_event

Syzbot reported shift-out-of-bounds in hid_report_raw_event.

microsoft 0003:045E:07DA.0001: hid_field_extract() called with n (128) &gt;
32! (swapper/0)
======================================================================
UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20
shift exponent 127 is too large for 32-bit type 'int'
CPU: 0 PID: 0 Comm: swapper/0 Not tainted
6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0
Hardware name: Google Compute Engine/Google Compute Engine, BIOS
Google 10/26/2022
Call Trace:
 &lt;IRQ&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106
 ubsan_epilogue lib/ubsan.c:151 [inline]
 __ubsan_handle_shift_out_of_bounds+0x3a6/0x420 lib/ubsan.c:322
 snto32 drivers/hid/hid-core.c:1323 [inline]
 hid_input_fetch_field drivers/hid/hid-core.c:1572 [inline]
 hid_process_report drivers/hid/hid-core.c:1665 [inline]
 hid_report_raw_event+0xd56/0x18b0 drivers/hid/hid-core.c:1998
 hid_input_report+0x408/0x4f0 drivers/hid/hid-core.c:2066
 hid_irq_in+0x459/0x690 drivers/hid/usbhid/hid-core.c:284
 __usb_hcd_giveback_urb+0x369/0x530 drivers/usb/core/hcd.c:1671
 dummy_timer+0x86b/0x3110 drivers/usb/gadget/udc/dummy_hcd.c:1988
 call_timer_fn+0xf5/0x210 kernel/time/timer.c:1474
 expire_timers kernel/time/timer.c:1519 [inline]
 __run_timers+0x76a/0x980 kernel/time/timer.c:1790
 run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1803
 __do_softirq+0x277/0x75b kernel/softirq.c:571
 __irq_exit_rcu+0xec/0x170 kernel/softirq.c:650
 irq_exit_rcu+0x5/0x20 kernel/softirq.c:662
 sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107
======================================================================

If the size of the integer (unsigned n) is bigger than 32 in snto32(),
shift exponent will be too large for 32-bit type 'int', resulting in a
shift-out-of-bounds bug.
Fix this by adding a check on the size of the integer (unsigned n) in
snto32(). To add support for n greater than 32 bits, set n to 32, if n
is greater than 32.</Note>
    </Notes>
    <CVE>CVE-2022-48978</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 array index out of bound error in DCN32 DML

[Why&amp;How]
LinkCapacitySupport array is indexed with the number of voltage states and
not the number of max DPPs. Fix the error by changing the array
declaration to use the correct (larger) array size of total number of
voltage states.</Note>
    </Notes>
    <CVE>CVE-2022-48979</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sja1105: avoid out of bounds access in sja1105_init_l2_policing()

The SJA1105 family has 45 L2 policing table entries
(SJA1105_MAX_L2_POLICING_COUNT) and SJA1110 has 110
(SJA1110_MAX_L2_POLICING_COUNT). Keeping the table structure but
accounting for the difference in port count (5 in SJA1105 vs 10 in
SJA1110) does not fully explain the difference. Rather, the SJA1110 also
has L2 ingress policers for multicast traffic. If a packet is classified
as multicast, it will be processed by the policer index 99 + SRCPORT.

The sja1105_init_l2_policing() function initializes all L2 policers such
that they don't interfere with normal packet reception by default. To have
a common code between SJA1105 and SJA1110, the index of the multicast
policer for the port is calculated because it's an index that is out of
bounds for SJA1105 but in bounds for SJA1110, and a bounds check is
performed.

The code fails to do the proper thing when determining what to do with the
multicast policer of port 0 on SJA1105 (ds-&gt;num_ports = 5). The "mcast"
index will be equal to 45, which is also equal to
table-&gt;ops-&gt;max_entry_count (SJA1105_MAX_L2_POLICING_COUNT). So it passes
through the check. But at the same time, SJA1105 doesn't have multicast
policers. So the code programs the SHARINDX field of an out-of-bounds
element in the L2 Policing table of the static config.

The comparison between index 45 and 45 entries should have determined the
code to not access this policer index on SJA1105, since its memory wasn't
even allocated.

With enough bad luck, the out-of-bounds write could even overwrite other
valid kernel data, but in this case, the issue was detected using KASAN.

Kernel log:

sja1105 spi5.0: Probed switch chip: SJA1105Q
==================================================================
BUG: KASAN: slab-out-of-bounds in sja1105_setup+0x1cbc/0x2340
Write of size 8 at addr ffffff880bd57708 by task kworker/u8:0/8
...
Workqueue: events_unbound deferred_probe_work_func
Call trace:
...
sja1105_setup+0x1cbc/0x2340
dsa_register_switch+0x1284/0x18d0
sja1105_probe+0x748/0x840
...
Allocated by task 8:
...
sja1105_setup+0x1bcc/0x2340
dsa_register_switch+0x1284/0x18d0
sja1105_probe+0x748/0x840
...</Note>
    </Notes>
    <CVE>CVE-2022-48980</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/shmem-helper: Remove errant put in error path

drm_gem_shmem_mmap() doesn't own this reference, resulting in the GEM
object getting prematurely freed leading to a later use-after-free.</Note>
    </Notes>
    <CVE>CVE-2022-48981</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 crash when replugging CSR fake controllers

It seems fake CSR 5.0 clones can cause the suspend notifier to be
registered twice causing the following kernel panic:

[   71.986122] Call Trace:
[   71.986124]  &lt;TASK&gt;
[   71.986125]  blocking_notifier_chain_register+0x33/0x60
[   71.986130]  hci_register_dev+0x316/0x3d0 [bluetooth 99b5497ea3d09708fa1366c1dc03288bf3cca8da]
[   71.986154]  btusb_probe+0x979/0xd85 [btusb e1e0605a4f4c01984a4b9c8ac58c3666ae287477]
[   71.986159]  ? __pm_runtime_set_status+0x1a9/0x300
[   71.986162]  ? ktime_get_mono_fast_ns+0x3e/0x90
[   71.986167]  usb_probe_interface+0xe3/0x2b0
[   71.986171]  really_probe+0xdb/0x380
[   71.986174]  ? pm_runtime_barrier+0x54/0x90
[   71.986177]  __driver_probe_device+0x78/0x170
[   71.986180]  driver_probe_device+0x1f/0x90
[   71.986183]  __device_attach_driver+0x89/0x110
[   71.986186]  ? driver_allows_async_probing+0x70/0x70
[   71.986189]  bus_for_each_drv+0x8c/0xe0
[   71.986192]  __device_attach+0xb2/0x1e0
[   71.986195]  bus_probe_device+0x92/0xb0
[   71.986198]  device_add+0x422/0x9a0
[   71.986201]  ? sysfs_merge_group+0xd4/0x110
[   71.986205]  usb_set_configuration+0x57a/0x820
[   71.986208]  usb_generic_driver_probe+0x4f/0x70
[   71.986211]  usb_probe_device+0x3a/0x110
[   71.986213]  really_probe+0xdb/0x380
[   71.986216]  ? pm_runtime_barrier+0x54/0x90
[   71.986219]  __driver_probe_device+0x78/0x170
[   71.986221]  driver_probe_device+0x1f/0x90
[   71.986224]  __device_attach_driver+0x89/0x110
[   71.986227]  ? driver_allows_async_probing+0x70/0x70
[   71.986230]  bus_for_each_drv+0x8c/0xe0
[   71.986232]  __device_attach+0xb2/0x1e0
[   71.986235]  bus_probe_device+0x92/0xb0
[   71.986237]  device_add+0x422/0x9a0
[   71.986239]  ? _dev_info+0x7d/0x98
[   71.986242]  ? blake2s_update+0x4c/0xc0
[   71.986246]  usb_new_device.cold+0x148/0x36d
[   71.986250]  hub_event+0xa8a/0x1910
[   71.986255]  process_one_work+0x1c4/0x380
[   71.986259]  worker_thread+0x51/0x390
[   71.986262]  ? rescuer_thread+0x3b0/0x3b0
[   71.986264]  kthread+0xdb/0x110
[   71.986266]  ? kthread_complete_and_exit+0x20/0x20
[   71.986268]  ret_from_fork+0x1f/0x30
[   71.986273]  &lt;/TASK&gt;
[   71.986274] ---[ end trace 0000000000000000 ]---
[   71.986284] btusb: probe of 2-1.6:1.0 failed with error -17</Note>
    </Notes>
    <CVE>CVE-2022-48982</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix a null-ptr-deref in io_tctx_exit_cb()

Syzkaller reports a NULL deref bug as follows:

 BUG: KASAN: null-ptr-deref in io_tctx_exit_cb+0x53/0xd3
 Read of size 4 at addr 0000000000000138 by task file1/1955

 CPU: 1 PID: 1955 Comm: file1 Not tainted 6.1.0-rc7-00103-gef4d3ea40565 #75
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
 Call Trace:
  &lt;TASK&gt;
  dump_stack_lvl+0xcd/0x134
  ? io_tctx_exit_cb+0x53/0xd3
  kasan_report+0xbb/0x1f0
  ? io_tctx_exit_cb+0x53/0xd3
  kasan_check_range+0x140/0x190
  io_tctx_exit_cb+0x53/0xd3
  task_work_run+0x164/0x250
  ? task_work_cancel+0x30/0x30
  get_signal+0x1c3/0x2440
  ? lock_downgrade+0x6e0/0x6e0
  ? lock_downgrade+0x6e0/0x6e0
  ? exit_signals+0x8b0/0x8b0
  ? do_raw_read_unlock+0x3b/0x70
  ? do_raw_spin_unlock+0x50/0x230
  arch_do_signal_or_restart+0x82/0x2470
  ? kmem_cache_free+0x260/0x4b0
  ? putname+0xfe/0x140
  ? get_sigframe_size+0x10/0x10
  ? do_execveat_common.isra.0+0x226/0x710
  ? lockdep_hardirqs_on+0x79/0x100
  ? putname+0xfe/0x140
  ? do_execveat_common.isra.0+0x238/0x710
  exit_to_user_mode_prepare+0x15f/0x250
  syscall_exit_to_user_mode+0x19/0x50
  do_syscall_64+0x42/0xb0
  entry_SYSCALL_64_after_hwframe+0x63/0xcd
 RIP: 0023:0x0
 Code: Unable to access opcode bytes at 0xffffffffffffffd6.
 RSP: 002b:00000000fffb7790 EFLAGS: 00000200 ORIG_RAX: 000000000000000b
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
  &lt;/TASK&gt;
 Kernel panic - not syncing: panic_on_warn set ...

This happens because the adding of task_work from io_ring_exit_work()
isn't synchronized with canceling all work items from eg exec. The
execution of the two are ordered in that they are both run by the task
itself, but if io_tctx_exit_cb() is queued while we're canceling all
work items off exec AND gets executed when the task exits to userspace
rather than in the main loop in io_uring_cancel_generic(), then we can
find current-&gt;io_uring == NULL and hit the above crash.

It's safe to add this NULL check here, because the execution of the two
paths are done by the task itself.

[axboe: add code comment and also put an explanation in the commit msg]</Note>
    </Notes>
    <CVE>CVE-2022-48983</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mana: Fix race on per-CQ variable napi work_done

After calling napi_complete_done(), the NAPIF_STATE_SCHED bit may be
cleared, and another CPU can start napi thread and access per-CQ variable,
cq-&gt;work_done. If the other thread (for example, from busy_poll) sets
it to a value &gt;= budget, this thread will continue to run when it should
stop, and cause memory corruption and panic.

To fix this issue, save the per-CQ work_done variable in a local variable
before napi_complete_done(), so it won't be corrupted by a possible
concurrent thread after napi_complete_done().

Also, add a flag bit to advertise to the NIC firmware: the NAPI work_done
variable race is fixed, so the driver is able to reliably support features
like busy_poll.</Note>
    </Notes>
    <CVE>CVE-2022-48985</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-dv-timings.c: fix too strict blanking sanity checks

Sanity checks were added to verify the v4l2_bt_timings blanking fields
in order to avoid integer overflows when userspace passes weird values.

But that assumed that userspace would correctly fill in the front porch,
backporch and sync values, but sometimes all you know is the total
blanking, which is then assigned to just one of these fields.

And that can fail with these checks.

So instead set a maximum for the total horizontal and vertical
blanking and check that each field remains below that.

That is still sufficient to avoid integer overflows, but it also
allows for more flexibility in how userspace fills in these fields.</Note>
    </Notes>
    <CVE>CVE-2022-48987</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

memcg: fix possible use-after-free in memcg_write_event_control()

memcg_write_event_control() accesses the dentry-&gt;d_name of the specified
control fd to route the write call.  As a cgroup interface file can't be
renamed, it's safe to access d_name as long as the specified file is a
regular cgroup file.  Also, as these cgroup interface files can't be
removed before the directory, it's safe to access the parent too.

Prior to 347c4a874710 ("memcg: remove cgroup_event-&gt;cft"), there was a
call to __file_cft() which verified that the specified file is a regular
cgroupfs file before further accesses.  The cftype pointer returned from
__file_cft() was no longer necessary and the commit inadvertently dropped
the file type check with it allowing any file to slip through.  With the
invarients broken, the d_name and parent accesses can now race against
renames and removals of arbitrary files and cause use-after-free's.

Fix the bug by resurrecting the file type check in __file_cft().  Now that
cgroupfs is implemented through kernfs, checking the file operations needs
to go through a layer of indirection.  Instead, let's check the superblock
and dentry type.</Note>
    </Notes>
    <CVE>CVE-2022-48988</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

fscache: Fix oops due to race with cookie_lru and use_cookie

If a cookie expires from the LRU and the LRU_DISCARD flag is set, but
the state machine has not run yet, it's possible another thread can call
fscache_use_cookie and begin to use it.

When the cookie_worker finally runs, it will see the LRU_DISCARD flag
set, transition the cookie-&gt;state to LRU_DISCARDING, which will then
withdraw the cookie.  Once the cookie is withdrawn the object is removed
the below oops will occur because the object associated with the cookie
is now NULL.

Fix the oops by clearing the LRU_DISCARD bit if another thread uses the
cookie before the cookie_worker runs.

  BUG: kernel NULL pointer dereference, address: 0000000000000008
  ...
  CPU: 31 PID: 44773 Comm: kworker/u130:1 Tainted: G     E    6.0.0-5.dneg.x86_64 #1
  Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022
  Workqueue: events_unbound netfs_rreq_write_to_cache_work [netfs]
  RIP: 0010:cachefiles_prepare_write+0x28/0x90 [cachefiles]
  ...
  Call Trace:
    netfs_rreq_write_to_cache_work+0x11c/0x320 [netfs]
    process_one_work+0x217/0x3e0
    worker_thread+0x4a/0x3b0
    kthread+0xd6/0x100</Note>
    </Notes>
    <CVE>CVE-2022-48989</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 use-after-free during gpu recovery

[Why]
    [  754.862560] refcount_t: underflow; use-after-free.
    [  754.862898] Call Trace:
    [  754.862903]  &lt;TASK&gt;
    [  754.862913]  amdgpu_job_free_cb+0xc2/0xe1 [amdgpu]
    [  754.863543]  drm_sched_main.cold+0x34/0x39 [amd_sched]

[How]
    The fw_fence may be not init, check whether dma_fence_init
    is performed before job free</Note>
    </Notes>
    <CVE>CVE-2022-48990</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/khugepaged: invoke MMU notifiers in shmem/file collapse paths

Any codepath that zaps page table entries must invoke MMU notifiers to
ensure that secondary MMUs (like KVM) don't keep accessing pages which
aren't mapped anymore.  Secondary MMUs don't hold their own references to
pages that are mirrored over, so failing to notify them can lead to page
use-after-free.

I'm marking this as addressing an issue introduced in commit f3f0e1d2150b
("khugepaged: add support of collapse for tmpfs/shmem pages"), but most of
the security impact of this only came in commit 27e1f8273113 ("khugepaged:
enable collapse pmd for pte-mapped THP"), which actually omitted flushes
for the removal of present PTEs, not just for the removal of empty page
tables.</Note>
    </Notes>
    <CVE>CVE-2022-48991</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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: soc-pcm: Add NULL check in BE reparenting

Add NULL check in dpcm_be_reparent API, to handle
kernel NULL pointer dereference error.
The issue occurred in fuzzing test.</Note>
    </Notes>
    <CVE>CVE-2022-48992</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: seq: Fix function prototype mismatch in snd_seq_expand_var_event

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed.

seq_copy_in_user() and seq_copy_in_kernel() did not have prototypes
matching snd_seq_dump_func_t. Adjust this and remove the casts. There
are not resulting binary output differences.

This was found as a result of Clang's new -Wcast-function-type-strict
flag, which is more sensitive than the simpler -Wcast-function-type,
which only checks for type width mismatches.</Note>
    </Notes>
    <CVE>CVE-2022-48994</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>not set</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: raydium_ts_i2c - fix memory leak in raydium_i2c_send()

There is a kmemleak when test the raydium_i2c_ts with bpf mock device:

  unreferenced object 0xffff88812d3675a0 (size 8):
    comm "python3", pid 349, jiffies 4294741067 (age 95.695s)
    hex dump (first 8 bytes):
      11 0e 10 c0 01 00 04 00                          ........
    backtrace:
      [&lt;0000000068427125&gt;] __kmalloc+0x46/0x1b0
      [&lt;0000000090180f91&gt;] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts]
      [&lt;000000006e631aee&gt;] raydium_i2c_initialize.cold+0xbc/0x3e4 [raydium_i2c_ts]
      [&lt;00000000dc6fcf38&gt;] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts]
      [&lt;00000000a310de16&gt;] i2c_device_probe+0x651/0x680
      [&lt;00000000f5a96bf3&gt;] really_probe+0x17c/0x3f0
      [&lt;00000000096ba499&gt;] __driver_probe_device+0xe3/0x170
      [&lt;00000000c5acb4d9&gt;] driver_probe_device+0x49/0x120
      [&lt;00000000264fe082&gt;] __device_attach_driver+0xf7/0x150
      [&lt;00000000f919423c&gt;] bus_for_each_drv+0x114/0x180
      [&lt;00000000e067feca&gt;] __device_attach+0x1e5/0x2d0
      [&lt;0000000054301fc2&gt;] bus_probe_device+0x126/0x140
      [&lt;00000000aad93b22&gt;] device_add+0x810/0x1130
      [&lt;00000000c086a53f&gt;] i2c_new_client_device+0x352/0x4e0
      [&lt;000000003c2c248c&gt;] of_i2c_register_device+0xf1/0x110
      [&lt;00000000ffec4177&gt;] of_i2c_notify+0x100/0x160
  unreferenced object 0xffff88812d3675c8 (size 8):
    comm "python3", pid 349, jiffies 4294741070 (age 95.692s)
    hex dump (first 8 bytes):
      22 00 36 2d 81 88 ff ff                          ".6-....
    backtrace:
      [&lt;0000000068427125&gt;] __kmalloc+0x46/0x1b0
      [&lt;0000000090180f91&gt;] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts]
      [&lt;000000001d5c9620&gt;] raydium_i2c_initialize.cold+0x223/0x3e4 [raydium_i2c_ts]
      [&lt;00000000dc6fcf38&gt;] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts]
      [&lt;00000000a310de16&gt;] i2c_device_probe+0x651/0x680
      [&lt;00000000f5a96bf3&gt;] really_probe+0x17c/0x3f0
      [&lt;00000000096ba499&gt;] __driver_probe_device+0xe3/0x170
      [&lt;00000000c5acb4d9&gt;] driver_probe_device+0x49/0x120
      [&lt;00000000264fe082&gt;] __device_attach_driver+0xf7/0x150
      [&lt;00000000f919423c&gt;] bus_for_each_drv+0x114/0x180
      [&lt;00000000e067feca&gt;] __device_attach+0x1e5/0x2d0
      [&lt;0000000054301fc2&gt;] bus_probe_device+0x126/0x140
      [&lt;00000000aad93b22&gt;] device_add+0x810/0x1130
      [&lt;00000000c086a53f&gt;] i2c_new_client_device+0x352/0x4e0
      [&lt;000000003c2c248c&gt;] of_i2c_register_device+0xf1/0x110
      [&lt;00000000ffec4177&gt;] of_i2c_notify+0x100/0x160

After BANK_SWITCH command from i2c BUS, no matter success or error
happened, the tx_buf should be freed.</Note>
    </Notes>
    <CVE>CVE-2022-48995</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

char: tpm: Protect tpm_pm_suspend with locks

Currently tpm transactions are executed unconditionally in
tpm_pm_suspend() function, which may lead to races with other tpm
accessors in the system.

Specifically, the hw_random tpm driver makes use of tpm_get_random(),
and this function is called in a loop from a kthread, which means it's
not frozen alongside userspace, and so can race with the work done
during system suspend:

  tpm tpm0: tpm_transmit: tpm_recv: error -52
  tpm tpm0: invalid TPM_STS.x 0xff, dumping stack for forensics
  CPU: 0 PID: 1 Comm: init Not tainted 6.1.0-rc5+ #135
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014
  Call Trace:
   tpm_tis_status.cold+0x19/0x20
   tpm_transmit+0x13b/0x390
   tpm_transmit_cmd+0x20/0x80
   tpm1_pm_suspend+0xa6/0x110
   tpm_pm_suspend+0x53/0x80
   __pnp_bus_suspend+0x35/0xe0
   __device_suspend+0x10f/0x350

Fix this by calling tpm_try_get_ops(), which itself is a wrapper around
tpm_chip_start(), but takes the appropriate mutex.

[Jason: reworked commit message, added metadata]</Note>
    </Notes>
    <CVE>CVE-2022-48997</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

iommu/vt-d: Fix PCI device refcount leak in has_external_pci()

for_each_pci_dev() is implemented by pci_get_device(). The comment of
pci_get_device() says that it will increase the reference count for the
returned pci_dev and also decrease the reference count for the input
pci_dev @from if it is not NULL.

If we break for_each_pci_dev() loop with pdev not NULL, we need to call
pci_dev_put() to decrease the reference count. Add the missing
pci_dev_put() before 'return true' to avoid reference count leak.</Note>
    </Notes>
    <CVE>CVE-2022-49000</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init()

for_each_pci_dev() is implemented by pci_get_device(). The comment of
pci_get_device() says that it will increase the reference count for the
returned pci_dev and also decrease the reference count for the input
pci_dev @from if it is not NULL.

If we break for_each_pci_dev() loop with pdev not NULL, we need to call
pci_dev_put() to decrease the reference count. Add the missing
pci_dev_put() for the error path to avoid reference count leak.</Note>
    </Notes>
    <CVE>CVE-2022-49002</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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: fix SRCU protection of nvme_ns_head list

Walking the nvme_ns_head siblings list is protected by the head's srcu
in nvme_ns_head_submit_bio() but not nvme_mpath_revalidate_paths().
Removing namespaces from the list also fails to synchronize the srcu.
Concurrent scan work can therefore cause use-after-frees.

Hold the head's srcu lock in nvme_mpath_revalidate_paths() and
synchronize with the srcu, not the global RCU, in nvme_ns_remove().

Observed the following panic when making NVMe/RDMA connections
with native multipath on the Rocky Linux 8.6 kernel
(it seems the upstream kernel has the same race condition).
Disassembly shows the faulting instruction is cmp 0x50(%rdx),%rcx;
computing capacity != get_capacity(ns-&gt;disk).
Address 0x50 is dereferenced because ns-&gt;disk is NULL.
The NULL disk appears to be the result of concurrent scan work
freeing the namespace (note the log line in the middle of the panic).

[37314.206036] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
[37314.206036] nvme0n3: detected capacity change from 0 to 11811160064
[37314.299753] PGD 0 P4D 0
[37314.299756] Oops: 0000 [#1] SMP PTI
[37314.299759] CPU: 29 PID: 322046 Comm: kworker/u98:3 Kdump: loaded Tainted: G        W      X --------- -  - 4.18.0-372.32.1.el8test86.x86_64 #1
[37314.299762] Hardware name: Dell Inc. PowerEdge R720/0JP31P, BIOS 2.7.0 05/23/2018
[37314.299763] Workqueue: nvme-wq nvme_scan_work [nvme_core]
[37314.299783] RIP: 0010:nvme_mpath_revalidate_paths+0x26/0xb0 [nvme_core]
[37314.299790] Code: 1f 44 00 00 66 66 66 66 90 55 53 48 8b 5f 50 48 8b 83 c8 c9 00 00 48 8b 13 48 8b 48 50 48 39 d3 74 20 48 8d 42 d0 48 8b 50 20 &lt;48&gt; 3b 4a 50 74 05 f0 80 60 70 ef 48 8b 50 30 48 8d 42 d0 48 39 d3
[37315.058803] RSP: 0018:ffffabe28f913d10 EFLAGS: 00010202
[37315.121316] RAX: ffff927a077da800 RBX: ffff92991dd70000 RCX: 0000000001600000
[37315.206704] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff92991b719800
[37315.292106] RBP: ffff929a6b70c000 R08: 000000010234cd4a R09: c0000000ffff7fff
[37315.377501] R10: 0000000000000001 R11: ffffabe28f913a30 R12: 0000000000000000
[37315.462889] R13: ffff92992716600c R14: ffff929964e6e030 R15: ffff92991dd70000
[37315.548286] FS:  0000000000000000(0000) GS:ffff92b87fb80000(0000) knlGS:0000000000000000
[37315.645111] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[37315.713871] CR2: 0000000000000050 CR3: 0000002208810006 CR4: 00000000000606e0
[37315.799267] Call Trace:
[37315.828515]  nvme_update_ns_info+0x1ac/0x250 [nvme_core]
[37315.892075]  nvme_validate_or_alloc_ns+0x2ff/0xa00 [nvme_core]
[37315.961871]  ? __blk_mq_free_request+0x6b/0x90
[37316.015021]  nvme_scan_work+0x151/0x240 [nvme_core]
[37316.073371]  process_one_work+0x1a7/0x360
[37316.121318]  ? create_worker+0x1a0/0x1a0
[37316.168227]  worker_thread+0x30/0x390
[37316.212024]  ? create_worker+0x1a0/0x1a0
[37316.258939]  kthread+0x10a/0x120
[37316.297557]  ? set_kthread_struct+0x50/0x50
[37316.347590]  ret_from_fork+0x35/0x40
[37316.390360] Modules linked in: nvme_rdma nvme_tcp(X) nvme_fabrics nvme_core netconsole iscsi_tcp libiscsi_tcp dm_queue_length dm_service_time nf_conntrack_netlink br_netfilter bridge stp llc overlay nft_chain_nat ipt_MASQUERADE nf_nat xt_addrtype xt_CT nft_counter xt_state xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment xt_multiport nft_compat nf_tables libcrc32c nfnetlink dm_multipath tg3 rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm intel_rapl_msr iTCO_wdt iTCO_vendor_support dcdbas intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ipmi_ssif kvm irqbypass crct10dif_pclmul crc32_pclmul mlx5_ib ghash_clmulni_intel ib_uverbs rapl intel_cstate intel_uncore ib_core ipmi_si joydev mei_me pcspkr ipmi_devintf mei lpc_ich wmi ipmi_msghandler acpi_power_meter ex
---truncated---</Note>
    </Notes>
    <CVE>CVE-2022-49003</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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: ops: Fix bounds check for _sx controls

For _sx controls the semantics of the max field is not the usual one, max
is the number of steps rather than the maximum value. This means that our
check in snd_soc_put_volsw_sx() needs to just check against the maximum
value.</Note>
    </Notes>
    <CVE>CVE-2022-49005</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Free buffers when a used dynamic event is removed

After 65536 dynamic events have been added and removed, the "type" field
of the event then uses the first type number that is available (not
currently used by other events). A type number is the identifier of the
binary blobs in the tracing ring buffer (known as events) to map them to
logic that can parse the binary blob.

The issue is that if a dynamic event (like a kprobe event) is traced and
is in the ring buffer, and then that event is removed (because it is
dynamic, which means it can be created and destroyed), if another dynamic
event is created that has the same number that new event's logic on
parsing the binary blob will be used.

To show how this can be an issue, the following can crash the kernel:

 # cd /sys/kernel/tracing
 # for i in `seq 65536`; do
     echo 'p:kprobes/foo do_sys_openat2 $arg1:u32' &gt; kprobe_events
 # done

For every iteration of the above, the writing to the kprobe_events will
remove the old event and create a new one (with the same format) and
increase the type number to the next available on until the type number
reaches over 65535 which is the max number for the 16 bit type. After it
reaches that number, the logic to allocate a new number simply looks for
the next available number. When an dynamic event is removed, that number
is then available to be reused by the next dynamic event created. That is,
once the above reaches the max number, the number assigned to the event in
that loop will remain the same.

Now that means deleting one dynamic event and created another will reuse
the previous events type number. This is where bad things can happen.
After the above loop finishes, the kprobes/foo event which reads the
do_sys_openat2 function call's first parameter as an integer.

 # echo 1 &gt; kprobes/foo/enable
 # cat /etc/passwd &gt; /dev/null
 # cat trace
             cat-2211    [005] ....  2007.849603: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196
             cat-2211    [005] ....  2007.849620: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196
             cat-2211    [005] ....  2007.849838: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196
             cat-2211    [005] ....  2007.849880: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196
 # echo 0 &gt; kprobes/foo/enable

Now if we delete the kprobe and create a new one that reads a string:

 # echo 'p:kprobes/foo do_sys_openat2 +0($arg2):string' &gt; kprobe_events

And now we can the trace:

 # cat trace
        sendmail-1942    [002] .....   530.136320: foo: (do_sys_openat2+0x0/0x240) arg1=             cat-2046    [004] .....   530.930817: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������"
             cat-2046    [004] .....   530.930961: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������"
             cat-2046    [004] .....   530.934278: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������"
             cat-2046    [004] .....   530.934563: foo: (do_sys_openat2+0x0/0x240) arg1="���������������������������������������
---truncated---</Note>
    </Notes>
    <CVE>CVE-2022-49006</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 pointer dereference in nilfs_palloc_commit_free_entry()

Syzbot reported a null-ptr-deref bug:

 NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP
 frequency &lt; 30 seconds
 general protection fault, probably for non-canonical address
 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN
 KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
 CPU: 1 PID: 3603 Comm: segctord Not tainted
 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0
 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google
 10/11/2022
 RIP: 0010:nilfs_palloc_commit_free_entry+0xe5/0x6b0
 fs/nilfs2/alloc.c:608
 Code: 00 00 00 00 fc ff df 80 3c 02 00 0f 85 cd 05 00 00 48 b8 00 00 00
 00 00 fc ff df 4c 8b 73 08 49 8d 7e 10 48 89 fa 48 c1 ea 03 &lt;80&gt; 3c 02
 00 0f 85 26 05 00 00 49 8b 46 10 be a6 00 00 00 48 c7 c7
 RSP: 0018:ffffc90003dff830 EFLAGS: 00010212
 RAX: dffffc0000000000 RBX: ffff88802594e218 RCX: 000000000000000d
 RDX: 0000000000000002 RSI: 0000000000002000 RDI: 0000000000000010
 RBP: ffff888071880222 R08: 0000000000000005 R09: 000000000000003f
 R10: 000000000000000d R11: 0000000000000000 R12: ffff888071880158
 R13: ffff88802594e220 R14: 0000000000000000 R15: 0000000000000004
 FS:  0000000000000000(0000) GS:ffff8880b9b00000(0000)
 knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 00007fb1c08316a8 CR3: 0000000018560000 CR4: 0000000000350ee0
 Call Trace:
  &lt;TASK&gt;
  nilfs_dat_commit_free fs/nilfs2/dat.c:114 [inline]
  nilfs_dat_commit_end+0x464/0x5f0 fs/nilfs2/dat.c:193
  nilfs_dat_commit_update+0x26/0x40 fs/nilfs2/dat.c:236
  nilfs_btree_commit_update_v+0x87/0x4a0 fs/nilfs2/btree.c:1940
  nilfs_btree_commit_propagate_v fs/nilfs2/btree.c:2016 [inline]
  nilfs_btree_propagate_v fs/nilfs2/btree.c:2046 [inline]
  nilfs_btree_propagate+0xa00/0xd60 fs/nilfs2/btree.c:2088
  nilfs_bmap_propagate+0x73/0x170 fs/nilfs2/bmap.c:337
  nilfs_collect_file_data+0x45/0xd0 fs/nilfs2/segment.c:568
  nilfs_segctor_apply_buffers+0x14a/0x470 fs/nilfs2/segment.c:1018
  nilfs_segctor_scan_file+0x3f4/0x6f0 fs/nilfs2/segment.c:1067
  nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1197 [inline]
  nilfs_segctor_collect fs/nilfs2/segment.c:1503 [inline]
  nilfs_segctor_do_construct+0x12fc/0x6af0 fs/nilfs2/segment.c:2045
  nilfs_segctor_construct+0x8e3/0xb30 fs/nilfs2/segment.c:2379
  nilfs_segctor_thread_construct fs/nilfs2/segment.c:2487 [inline]
  nilfs_segctor_thread+0x3c3/0xf30 fs/nilfs2/segment.c:2570
  kthread+0x2e4/0x3a0 kernel/kthread.c:376
  ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
  &lt;/TASK&gt;
 ...

If DAT metadata file is corrupted on disk, there is a case where
req-&gt;pr_desc_bh is NULL and blocknr is 0 at nilfs_dat_commit_end() during
a b-tree operation that cascadingly updates ancestor nodes of the b-tree,
because nilfs_dat_commit_alloc() for a lower level block can initialize
the blocknr on the same DAT entry between nilfs_dat_prepare_end() and
nilfs_dat_commit_end().

If this happens, nilfs_dat_commit_end() calls nilfs_dat_commit_free()
without valid buffer heads in req-&gt;pr_desc_bh and req-&gt;pr_bitmap_bh, and
causes the NULL pointer dereference above in
nilfs_palloc_commit_free_entry() function, which leads to a crash.

Fix this by adding a NULL check on req-&gt;pr_desc_bh and req-&gt;pr_bitmap_bh
before nilfs_palloc_commit_free_entry() in nilfs_dat_commit_free().

This also calls nilfs_error() in that case to notify that there is a fatal
flaw in the filesystem metadata and prevent further operations.</Note>
    </Notes>
    <CVE>CVE-2022-49007</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hwmon: (coretemp) Check for null before removing sysfs attrs

If coretemp_add_core() gets an error then pdata-&gt;core_data[indx]
is already NULL and has been kfreed. Don't pass that to
sysfs_remove_group() as that will crash in sysfs_remove_group().

[Shortened for readability]
[91854.020159] sysfs: cannot create duplicate filename '/devices/platform/coretemp.0/hwmon/hwmon2/temp20_label'
&lt;cpu offline&gt;
[91855.126115] BUG: kernel NULL pointer dereference, address: 0000000000000188
[91855.165103] #PF: supervisor read access in kernel mode
[91855.194506] #PF: error_code(0x0000) - not-present page
[91855.224445] PGD 0 P4D 0
[91855.238508] Oops: 0000 [#1] PREEMPT SMP PTI
...
[91855.342716] RIP: 0010:sysfs_remove_group+0xc/0x80
...
[91855.796571] Call Trace:
[91855.810524]  coretemp_cpu_offline+0x12b/0x1dd [coretemp]
[91855.841738]  ? coretemp_cpu_online+0x180/0x180 [coretemp]
[91855.871107]  cpuhp_invoke_callback+0x105/0x4b0
[91855.893432]  cpuhp_thread_fun+0x8e/0x150
...

Fix this by checking for NULL first.</Note>
    </Notes>
    <CVE>CVE-2022-49010</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new()

As comment of pci_get_domain_bus_and_slot() says, it returns
a pci device with refcount increment, when finish using it,
the caller must decrement the reference count by calling
pci_dev_put(). So call it after using to avoid refcount leak.</Note>
    </Notes>
    <CVE>CVE-2022-49011</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 server-&gt;active leak in afs_put_server

The atomic_read was accidentally replaced with atomic_inc_return,
which prevents the server from getting cleaned up and causes rmmod
to hang with a warning:

    Can't purge s=00000001</Note>
    </Notes>
    <CVE>CVE-2022-49012</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: tun: Fix use-after-free in tun_detach()

syzbot reported use-after-free in tun_detach() [1].  This causes call
trace like below:

==================================================================
BUG: KASAN: use-after-free in notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75
Read of size 8 at addr ffff88807324e2a8 by task syz-executor.0/3673

CPU: 0 PID: 3673 Comm: syz-executor.0 Not tainted 6.1.0-rc5-syzkaller-00044-gcc675d22e422 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:284 [inline]
 print_report+0x15e/0x461 mm/kasan/report.c:395
 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495
 notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75
 call_netdevice_notifiers_info+0x86/0x130 net/core/dev.c:1942
 call_netdevice_notifiers_extack net/core/dev.c:1983 [inline]
 call_netdevice_notifiers net/core/dev.c:1997 [inline]
 netdev_wait_allrefs_any net/core/dev.c:10237 [inline]
 netdev_run_todo+0xbc6/0x1100 net/core/dev.c:10351
 tun_detach drivers/net/tun.c:704 [inline]
 tun_chr_close+0xe4/0x190 drivers/net/tun.c:3467
 __fput+0x27c/0xa90 fs/file_table.c:320
 task_work_run+0x16f/0x270 kernel/task_work.c:179
 exit_task_work include/linux/task_work.h:38 [inline]
 do_exit+0xb3d/0x2a30 kernel/exit.c:820
 do_group_exit+0xd4/0x2a0 kernel/exit.c:950
 get_signal+0x21b1/0x2440 kernel/signal.c:2858
 arch_do_signal_or_restart+0x86/0x2300 arch/x86/kernel/signal.c:869
 exit_to_user_mode_loop kernel/entry/common.c:168 [inline]
 exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203
 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
 syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296
 do_syscall_64+0x46/0xb0 arch/x86/entry/common.c:86
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

The cause of the issue is that sock_put() from __tun_detach() drops
last reference count for struct net, and then notifier_call_chain()
from netdev_state_change() accesses that struct net.

This patch fixes the issue by calling sock_put() from tun_detach()
after all necessary accesses for the struct net has done.</Note>
    </Notes>
    <CVE>CVE-2022-49014</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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: hsr: Fix potential use-after-free

The skb is delivered to netif_rx() which may free it, after calling this,
dereferencing skb may trigger use-after-free.</Note>
    </Notes>
    <CVE>CVE-2022-49015</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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: mdiobus: fix unbalanced node reference count

I got the following report while doing device(mscc-miim) load test
with CONFIG_OF_UNITTEST and CONFIG_OF_DYNAMIC enabled:

  OF: ERROR: memory leak, expected refcount 1 instead of 2,
  of_node_get()/of_node_put() unbalanced - destroy cset entry:
  attach overlay node /spi/soc@0/mdio@7107009c/ethernet-phy@0

If the 'fwnode' is not an acpi node, the refcount is get in
fwnode_mdiobus_phy_device_register(), but it has never been
put when the device is freed in the normal path. So call
fwnode_handle_put() in phy_device_release() to avoid leak.

If it's an acpi node, it has never been get, but it's put
in the error path, so call fwnode_handle_get() before
phy_device_register() to keep get/put operation balanced.</Note>
    </Notes>
    <CVE>CVE-2022-49016</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: re-fetch skb cb after tipc_msg_validate

As the call trace shows, the original skb was freed in tipc_msg_validate(),
and dereferencing the old skb cb would cause an use-after-free crash.

  BUG: KASAN: use-after-free in tipc_crypto_rcv_complete+0x1835/0x2240 [tipc]
  Call Trace:
   &lt;IRQ&gt;
   tipc_crypto_rcv_complete+0x1835/0x2240 [tipc]
   tipc_crypto_rcv+0xd32/0x1ec0 [tipc]
   tipc_rcv+0x744/0x1150 [tipc]
  ...
  Allocated by task 47078:
   kmem_cache_alloc_node+0x158/0x4d0
   __alloc_skb+0x1c1/0x270
   tipc_buf_acquire+0x1e/0xe0 [tipc]
   tipc_msg_create+0x33/0x1c0 [tipc]
   tipc_link_build_proto_msg+0x38a/0x2100 [tipc]
   tipc_link_timeout+0x8b8/0xef0 [tipc]
   tipc_node_timeout+0x2a1/0x960 [tipc]
   call_timer_fn+0x2d/0x1c0
  ...
  Freed by task 47078:
   tipc_msg_validate+0x7b/0x440 [tipc]
   tipc_crypto_rcv_complete+0x4b5/0x2240 [tipc]
   tipc_crypto_rcv+0xd32/0x1ec0 [tipc]
   tipc_rcv+0x744/0x1150 [tipc]

This patch fixes it by re-fetching the skb cb from the new allocated skb
after calling tipc_msg_validate().</Note>
    </Notes>
    <CVE>CVE-2022-49017</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ethernet: nixge: fix NULL dereference

In function nixge_hw_dma_bd_release() dereference of NULL pointer
priv-&gt;rx_bd_v is possible for the case of its allocation failure in
nixge_hw_dma_bd_init().

Move for() loop with priv-&gt;rx_bd_v dereference under the check for
its validity.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2022-49019</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/9p: Fix a potential socket leak in p9_socket_open

Both p9_fd_create_tcp() and p9_fd_create_unix() will call
p9_socket_open(). If the creation of p9_trans_fd fails,
p9_fd_create_tcp() and p9_fd_create_unix() will return an
error directly instead of releasing the cscoket, which will
result in a socket leak.

This patch adds sock_release() to fix the leak issue.</Note>
    </Notes>
    <CVE>CVE-2022-49020</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix null-ptr-deref while probe() failed

I got a null-ptr-deref report as following when doing fault injection test:

BUG: kernel NULL pointer dereference, address: 0000000000000058
Oops: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 1 PID: 253 Comm: 507-spi-dm9051 Tainted: G    B            N 6.1.0-rc3+
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:klist_put+0x2d/0xd0
Call Trace:
 &lt;TASK&gt;
 klist_remove+0xf1/0x1c0
 device_release_driver_internal+0x23e/0x2d0
 bus_remove_device+0x1bd/0x240
 device_del+0x357/0x770
 phy_device_remove+0x11/0x30
 mdiobus_unregister+0xa5/0x140
 release_nodes+0x6a/0xa0
 devres_release_all+0xf8/0x150
 device_unbind_cleanup+0x19/0xd0

//probe path:
phy_device_register()
  device_add()

phy_connect
  phy_attach_direct() //set device driver
    probe() //it's failed, driver is not bound
    device_bind_driver() // probe failed, it's not called

//remove path:
phy_device_remove()
  device_del()
    device_release_driver_internal()
      __device_release_driver() //dev-&gt;drv is not NULL
        klist_remove() &lt;- knode_driver is not added yet, cause null-ptr-deref

In phy_attach_direct(), after setting the 'dev-&gt;driver', probe() fails,
device_bind_driver() is not called, so the knode_driver-&gt;n_klist is not
set, then it causes null-ptr-deref in __device_release_driver() while
deleting device. Fix this by setting dev-&gt;driver to NULL in the error
path in phy_attach_direct().</Note>
    </Notes>
    <CVE>CVE-2022-49021</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mac8021: fix possible oob access in ieee80211_get_rate_duration

Fix possible out-of-bound access in ieee80211_get_rate_duration routine
as reported by the following UBSAN report:

UBSAN: array-index-out-of-bounds in net/mac80211/airtime.c:455:47
index 15 is out of range for type 'u16 [12]'
CPU: 2 PID: 217 Comm: kworker/u32:10 Not tainted 6.1.0-060100rc3-generic
Hardware name: Acer Aspire TC-281/Aspire TC-281, BIOS R01-A2 07/18/2017
Workqueue: mt76 mt76u_tx_status_data [mt76_usb]
Call Trace:
 &lt;TASK&gt;
 show_stack+0x4e/0x61
 dump_stack_lvl+0x4a/0x6f
 dump_stack+0x10/0x18
 ubsan_epilogue+0x9/0x43
 __ubsan_handle_out_of_bounds.cold+0x42/0x47
ieee80211_get_rate_duration.constprop.0+0x22f/0x2a0 [mac80211]
 ? ieee80211_tx_status_ext+0x32e/0x640 [mac80211]
 ieee80211_calc_rx_airtime+0xda/0x120 [mac80211]
 ieee80211_calc_tx_airtime+0xb4/0x100 [mac80211]
 mt76x02_send_tx_status+0x266/0x480 [mt76x02_lib]
 mt76x02_tx_status_data+0x52/0x80 [mt76x02_lib]
 mt76u_tx_status_data+0x67/0xd0 [mt76_usb]
 process_one_work+0x225/0x400
 worker_thread+0x50/0x3e0
 ? process_one_work+0x400/0x400
 kthread+0xe9/0x110
 ? kthread_complete_and_exit+0x20/0x20
 ret_from_fork+0x22/0x30</Note>
    </Notes>
    <CVE>CVE-2022-49022</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix buffer overflow in elem comparison

For vendor elements, the code here assumes that 5 octets
are present without checking. Since the element itself is
already checked to fit, we only need to check the length.</Note>
    </Notes>
    <CVE>CVE-2022-49023</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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: m_can: pci: add missing m_can_class_free_dev() in probe/remove methods

In m_can_pci_remove() and error handling path of m_can_pci_probe(),
m_can_class_free_dev() should be called to free resource allocated by
m_can_class_allocate_dev(), otherwise there will be memleak.</Note>
    </Notes>
    <CVE>CVE-2022-49024</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 use-after-free when reverting termination table

When having multiple dests with termination tables and second one
or afterwards fails the driver reverts usage of term tables but
doesn't reset the assignment in attr-&gt;dests[num_vport_dests].termtbl
which case a use-after-free when releasing the rule.
Fix by resetting the assignment of termtbl to null.</Note>
    </Notes>
    <CVE>CVE-2022-49025</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

e100: Fix possible use after free in e100_xmit_prepare

In e100_xmit_prepare(), if we can't map the skb, then return -ENOMEM, so
e100_xmit_frame() will return NETDEV_TX_BUSY and the upper layer will
resend the skb. But the skb is already freed, which will cause UAF bug
when the upper layer resends the skb.

Remove the harmful free.</Note>
    </Notes>
    <CVE>CVE-2022-49026</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iavf: Fix error handling in iavf_init_module()

The iavf_init_module() won't destroy workqueue when pci_register_driver()
failed. Call destroy_workqueue() when pci_register_driver() failed to
prevent the resource leak.

Similar to the handling of u132_hcd_init in commit f276e002793c
("usb: u132-hcd: fix resource leak")</Note>
    </Notes>
    <CVE>CVE-2022-49027</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ixgbevf: Fix resource leak in ixgbevf_init_module()

ixgbevf_init_module() won't destroy the workqueue created by
create_singlethread_workqueue() when pci_register_driver() failed. Add
destroy_workqueue() in fail path to prevent the resource leak.

Similar to the handling of u132_hcd_init in commit f276e002793c
("usb: u132-hcd: fix resource leak")</Note>
    </Notes>
    <CVE>CVE-2022-49028</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails

Smatch report warning as follows:

drivers/hwmon/ibmpex.c:509 ibmpex_register_bmc() warn:
  '&amp;data-&gt;list' not removed from list

If ibmpex_find_sensors() fails in ibmpex_register_bmc(), data will
be freed, but data-&gt;list will not be removed from driver_data.bmc_data,
then list traversal may cause UAF.

Fix by removeing it from driver_data.bmc_data before free().</Note>
    </Notes>
    <CVE>CVE-2022-49029</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: health: afe4403: Fix oob read in afe4403_read_raw

KASAN report out-of-bounds read as follows:

BUG: KASAN: global-out-of-bounds in afe4403_read_raw+0x42e/0x4c0
Read of size 4 at addr ffffffffc02ac638 by task cat/279

Call Trace:
 afe4403_read_raw
 iio_read_channel_info
 dev_attr_show

The buggy address belongs to the variable:
 afe4403_channel_leds+0x18/0xffffffffffffe9e0

This issue can be reproduced by singe command:

 $ cat /sys/bus/spi/devices/spi0.0/iio\:device0/in_intensity6_raw

The array size of afe4403_channel_leds is less than channels, so access
with chan-&gt;address cause OOB read in afe4403_read_raw. Fix it by moving
access before use it.</Note>
    </Notes>
    <CVE>CVE-2022-49031</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: health: afe4404: Fix oob read in afe4404_[read|write]_raw

KASAN report out-of-bounds read as follows:

BUG: KASAN: global-out-of-bounds in afe4404_read_raw+0x2ce/0x380
Read of size 4 at addr ffffffffc00e4658 by task cat/278

Call Trace:
 afe4404_read_raw
 iio_read_channel_info
 dev_attr_show

The buggy address belongs to the variable:
 afe4404_channel_leds+0x18/0xffffffffffffe9c0

This issue can be reproduce by singe command:

 $ cat /sys/bus/i2c/devices/0-0058/iio\:device0/in_intensity6_raw

The array size of afe4404_channel_leds and afe4404_channel_offdacs
are less than channels, so access with chan-&gt;address cause OOB read
in afe4404_[read|write]_raw. Fix it by moving access before use them.</Note>
    </Notes>
    <CVE>CVE-2022-49032</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 null pointer dereference issue was found in can protocol in net/can/af_can.c in the Linux before Linux. ml_priv may not be initialized in the receive path of CAN frames. A local user could use this flaw to crash the system or potentially cause a denial of service.</Note>
    </Notes>
    <CVE>CVE-2023-2166</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 NULL pointer dereference flaw was found in the UNIX protocol in net/unix/diag.c In unix_diag_get_exact in the Linux Kernel. The newly allocated skb does not have sk, leading to a NULL pointer. This flaw allows a local user to crash or potentially cause a denial of service.</Note>
    </Notes>
    <CVE>CVE-2023-28327</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.

Flaw in the error handling of bound chains causes a use-after-free in the abort path of NFT_MSG_NEWRULE. The vulnerability requires CAP_NET_ADMIN to be triggered.

We recommend upgrading past commit 4bedf9eee016286c835e3d8fa981ddece5338795.</Note>
    </Notes>
    <CVE>CVE-2023-3610</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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. 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"/>
    </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"/>
    </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 python-cryptography package. This issue may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.</Note>
    </Notes>
    <CVE>CVE-2023-50782</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/sparsemem: fix race in accessing memory_section-&gt;usage

The below race is observed on a PFN which falls into the device memory
region with the system memory configuration where PFN's are such that
[ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL].  Since normal zone start and end
pfn contains the device memory PFN's as well, the compaction triggered
will try on the device memory PFN's too though they end up in NOP(because
pfn_to_online_page() returns NULL for ZONE_DEVICE memory sections).  When
from other core, the section mappings are being removed for the
ZONE_DEVICE region, that the PFN in question belongs to, on which
compaction is currently being operated is resulting into the kernel crash
with CONFIG_SPASEMEM_VMEMAP enabled.  The crash logs can be seen at [1].

compact_zone()			memunmap_pages
-------------			---------------
__pageblock_pfn_to_page
   ......
 (a)pfn_valid():
     valid_section()//return true
			      (b)__remove_pages()-&gt;
				  sparse_remove_section()-&gt;
				    section_deactivate():
				    [Free the array ms-&gt;usage and set
				     ms-&gt;usage = NULL]
     pfn_section_valid()
     [Access ms-&gt;usage which
     is NULL]

NOTE: From the above it can be said that the race is reduced to between
the pfn_valid()/pfn_section_valid() and the section deactivate with
SPASEMEM_VMEMAP enabled.

The commit b943f045a9af("mm/sparse: fix kernel crash with
pfn_section_valid check") tried to address the same problem by clearing
the SECTION_HAS_MEM_MAP with the expectation of valid_section() returns
false thus ms-&gt;usage is not accessed.

Fix this issue by the below steps:

a) Clear SECTION_HAS_MEM_MAP before freeing the -&gt;usage.

b) RCU protected read side critical section will either return NULL
   when SECTION_HAS_MEM_MAP is cleared or can successfully access -&gt;usage.

c) Free the -&gt;usage with kfree_rcu() and set ms-&gt;usage = NULL.  No
   attempt will be made to access -&gt;usage after this as the
   SECTION_HAS_MEM_MAP is cleared thus valid_section() return false.

Thanks to David/Pavan for their inputs on this patch.

[1] https://lore.kernel.org/linux-mm/994410bb-89aa-d987-1f50-f514903c55aa@quicinc.com/

On Snapdragon SoC, with the mentioned memory configuration of PFN's as
[ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL], we are able to see bunch of
issues daily while testing on a device farm.

For this particular issue below is the log.  Though the below log is
not directly pointing to the pfn_section_valid(){ ms-&gt;usage;}, when we
loaded this dump on T32 lauterbach tool, it is pointing.

[  540.578056] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000000
[  540.578068] Mem abort info:
[  540.578070]   ESR = 0x0000000096000005
[  540.578073]   EC = 0x25: DABT (current EL), IL = 32 bits
[  540.578077]   SET = 0, FnV = 0
[  540.578080]   EA = 0, S1PTW = 0
[  540.578082]   FSC = 0x05: level 1 translation fault
[  540.578085] Data abort info:
[  540.578086]   ISV = 0, ISS = 0x00000005
[  540.578088]   CM = 0, WnR = 0
[  540.579431] pstate: 82400005 (Nzcv daif +PAN -UAO +TCO -DIT -SSBSBTYPE=--)
[  540.579436] pc : __pageblock_pfn_to_page+0x6c/0x14c
[  540.579454] lr : compact_zone+0x994/0x1058
[  540.579460] sp : ffffffc03579b510
[  540.579463] x29: ffffffc03579b510 x28: 0000000000235800 x27:000000000000000c
[  540.579470] x26: 0000000000235c00 x25: 0000000000000068 x24:ffffffc03579b640
[  540.579477] x23: 0000000000000001 x22: ffffffc03579b660 x21:0000000000000000
[  540.579483] x20: 0000000000235bff x19: ffffffdebf7e3940 x18:ffffffdebf66d140
[  540.579489] x17: 00000000739ba063 x16: 00000000739ba063 x15:00000000009f4bff
[  540.579495] x14: 0000008000000000 x13: 0000000000000000 x12:0000000000000001
[  540.579501] x11: 0000000000000000 x10: 0000000000000000 x9 :ffffff897d2cd440
[  540.579507] x8 : 0000000000000000 x7 : 0000000000000000 x6 :ffffffc03579b5b4
[  540.579512] x5 : 0000000000027f25 x4 : ffffffc03579b5b8 x3 :0000000000000
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-52489</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

PM: sleep: Fix possible deadlocks in core system-wide PM code

It is reported that in low-memory situations the system-wide resume core
code deadlocks, because async_schedule_dev() executes its argument
function synchronously if it cannot allocate memory (and not only in
that case) and that function attempts to acquire a mutex that is already
held.  Executing the argument function synchronously from within
dpm_async_fn() may also be problematic for ordering reasons (it may
cause a consumer device's resume callback to be invoked before a
requisite supplier device's one, for example).

Address this by changing the code in question to use
async_schedule_dev_nocall() for scheduling the asynchronous
execution of device suspend and resume functions and to directly
run them synchronously if async_schedule_dev_nocall() returns false.</Note>
    </Notes>
    <CVE>CVE-2023-52498</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix memleak when more than 255 elements expired

When more than 255 elements expired we're supposed to switch to a new gc
container structure.

This never happens: u8 type will wrap before reaching the boundary
and nft_trans_gc_space() always returns true.

This means we recycle the initial gc container structure and
lose track of the elements that came before.

While at it, don't deref 'gc' after we've passed it to call_rcu.</Note>
    </Notes>
    <CVE>CVE-2023-52581</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: act_ct: fix skb leak and crash on ooo frags

act_ct adds skb-&gt;users before defragmentation. If frags arrive in order,
the last frag's reference is reset in:

  inet_frag_reasm_prepare
    skb_morph

which is not straightforward.

However when frags arrive out of order, nobody unref the last frag, and
all frags are leaked. The situation is even worse, as initiating packet
capture can lead to a crash[0] when skb has been cloned and shared at the
same time.

Fix the issue by removing skb_get() before defragmentation. act_ct
returns TC_ACT_CONSUMED when defrag failed or in progress.

[0]:
[  843.804823] ------------[ cut here ]------------
[  843.809659] kernel BUG at net/core/skbuff.c:2091!
[  843.814516] invalid opcode: 0000 [#1] PREEMPT SMP
[  843.819296] CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G S 6.7.0-rc3 #2
[  843.824107] Hardware name: XFUSION 1288H V6/BC13MBSBD, BIOS 1.29 11/25/2022
[  843.828953] RIP: 0010:pskb_expand_head+0x2ac/0x300
[  843.833805] Code: 8b 70 28 48 85 f6 74 82 48 83 c6 08 bf 01 00 00 00 e8 38 bd ff ff 8b 83 c0 00 00 00 48 03 83 c8 00 00 00 e9 62 ff ff ff 0f 0b &lt;0f&gt; 0b e8 8d d0 ff ff e9 b3 fd ff ff 81 7c 24 14 40 01 00 00 4c 89
[  843.843698] RSP: 0018:ffffc9000cce07c0 EFLAGS: 00010202
[  843.848524] RAX: 0000000000000002 RBX: ffff88811a211d00 RCX: 0000000000000820
[  843.853299] RDX: 0000000000000640 RSI: 0000000000000000 RDI: ffff88811a211d00
[  843.857974] RBP: ffff888127d39518 R08: 00000000bee97314 R09: 0000000000000000
[  843.862584] R10: 0000000000000000 R11: ffff8881109f0000 R12: 0000000000000880
[  843.867147] R13: ffff888127d39580 R14: 0000000000000640 R15: ffff888170f7b900
[  843.871680] FS:  0000000000000000(0000) GS:ffff889ffffc0000(0000) knlGS:0000000000000000
[  843.876242] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  843.880778] CR2: 00007fa42affcfb8 CR3: 000000011433a002 CR4: 0000000000770ef0
[  843.885336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  843.889809] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  843.894229] PKRU: 55555554
[  843.898539] Call Trace:
[  843.902772]  &lt;IRQ&gt;
[  843.906922]  ? __die_body+0x1e/0x60
[  843.911032]  ? die+0x3c/0x60
[  843.915037]  ? do_trap+0xe2/0x110
[  843.918911]  ? pskb_expand_head+0x2ac/0x300
[  843.922687]  ? do_error_trap+0x65/0x80
[  843.926342]  ? pskb_expand_head+0x2ac/0x300
[  843.929905]  ? exc_invalid_op+0x50/0x60
[  843.933398]  ? pskb_expand_head+0x2ac/0x300
[  843.936835]  ? asm_exc_invalid_op+0x1a/0x20
[  843.940226]  ? pskb_expand_head+0x2ac/0x300
[  843.943580]  inet_frag_reasm_prepare+0xd1/0x240
[  843.946904]  ip_defrag+0x5d4/0x870
[  843.950132]  nf_ct_handle_fragments+0xec/0x130 [nf_conntrack]
[  843.953334]  tcf_ct_act+0x252/0xd90 [act_ct]
[  843.956473]  ? tcf_mirred_act+0x516/0x5a0 [act_mirred]
[  843.959657]  tcf_action_exec+0xa1/0x160
[  843.962823]  fl_classify+0x1db/0x1f0 [cls_flower]
[  843.966010]  ? skb_clone+0x53/0xc0
[  843.969173]  tcf_classify+0x24d/0x420
[  843.972333]  tc_run+0x8f/0xf0
[  843.975465]  __netif_receive_skb_core+0x67a/0x1080
[  843.978634]  ? dev_gro_receive+0x249/0x730
[  843.981759]  __netif_receive_skb_list_core+0x12d/0x260
[  843.984869]  netif_receive_skb_list_internal+0x1cb/0x2f0
[  843.987957]  ? mlx5e_handle_rx_cqe_mpwrq_rep+0xfa/0x1a0 [mlx5_core]
[  843.991170]  napi_complete_done+0x72/0x1a0
[  843.994305]  mlx5e_napi_poll+0x28c/0x6d0 [mlx5_core]
[  843.997501]  __napi_poll+0x25/0x1b0
[  844.000627]  net_rx_action+0x256/0x330
[  844.003705]  __do_softirq+0xb3/0x29b
[  844.006718]  irq_exit_rcu+0x9e/0xc0
[  844.009672]  common_interrupt+0x86/0xa0
[  844.012537]  &lt;/IRQ&gt;
[  844.015285]  &lt;TASK&gt;
[  844.017937]  asm_common_interrupt+0x26/0x40
[  844.020591] RIP: 0010:acpi_safe_halt+0x1b/0x20
[  844.023247] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 65 48 8b 04 25 00 18 03 00 48 8b 00 a8 08 75 0c 66 90 0f 00 2d 81 d0 44 00 fb
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-52610</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: hisi: Fix use-after-free when register pmu fails

When we fail to register the uncore pmu, the pmu context may not been
allocated. The error handing will call cpuhp_state_remove_instance()
to call uncore pmu offline callback, which migrate the pmu context.
Since that's liable to lead to some kind of use-after-free.

Use cpuhp_state_remove_instance_nocalls() instead of
cpuhp_state_remove_instance() so that the notifiers don't execute after
the PMU device has been failed to register.</Note>
    </Notes>
    <CVE>CVE-2023-52859</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new

This patch enhances error handling in scenarios with RTS (Request to
Send) messages arriving closely. It replaces the less informative WARN_ON_ONCE
backtraces with a new error handling method. This provides clearer error
messages and allows for the early termination of problematic sessions.
Previously, sessions were only released at the end of j1939_xtp_rx_rts().

Potentially this could be reproduced with something like:
testj1939 -r vcan0:0x80 &amp;
while true; do
	# send first RTS
	cansend vcan0 18EC8090#1014000303002301;
	# send second RTS
	cansend vcan0 18EC8090#1014000303002301;
	# send abort
	cansend vcan0 18EC8090#ff00000000002301;
done</Note>
    </Notes>
    <CVE>CVE-2023-52887</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 null pointer deref when receiving skb during sock creation

The panic below is observed when receiving ICMP packets with secmark set
while an ICMP raw socket is being created. SK_CTX(sk)-&gt;label is updated
in apparmor_socket_post_create(), but the packet is delivered to the
socket before that, causing the null pointer dereference.
Drop the packet if label context is not set.

    BUG: kernel NULL pointer dereference, address: 000000000000004c
    #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: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df
    Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020
    RIP: 0010:aa_label_next_confined+0xb/0x40
    Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 &lt;8b&gt; 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2
    RSP: 0018:ffffa92940003b08 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e
    RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000
    RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002
    R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400
    R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000
    FS:  00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0
    PKRU: 55555554
    Call Trace:
     &lt;IRQ&gt;
     ? __die+0x23/0x70
     ? page_fault_oops+0x171/0x4e0
     ? exc_page_fault+0x7f/0x180
     ? asm_exc_page_fault+0x26/0x30
     ? aa_label_next_confined+0xb/0x40
     apparmor_secmark_check+0xec/0x330
     security_sock_rcv_skb+0x35/0x50
     sk_filter_trim_cap+0x47/0x250
     sock_queue_rcv_skb_reason+0x20/0x60
     raw_rcv+0x13c/0x210
     raw_local_deliver+0x1f3/0x250
     ip_protocol_deliver_rcu+0x4f/0x2f0
     ip_local_deliver_finish+0x76/0xa0
     __netif_receive_skb_one_core+0x89/0xa0
     netif_receive_skb+0x119/0x170
     ? __netdev_alloc_skb+0x3d/0x140
     vmxnet3_rq_rx_complete+0xb23/0x1010 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]
     vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]
     __napi_poll+0x28/0x1b0
     net_rx_action+0x2a4/0x380
     __do_softirq+0xd1/0x2c8
     __irq_exit_rcu+0xbb/0xf0
     common_interrupt+0x86/0xa0
     &lt;/IRQ&gt;
     &lt;TASK&gt;
     asm_common_interrupt+0x26/0x40
    RIP: 0010:apparmor_socket_post_create+0xb/0x200
    Code: 08 48 85 ff 75 a1 eb b1 0f 1f 80 00 00 00 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 41 54 &lt;55&gt; 48 89 fd 53 45 85 c0 0f 84 b2 00 00 00 48 8b 1d 80 56 3f 02 48
    RSP: 0018:ffffa92940ce7e50 EFLAGS: 00000286
    RAX: ffffffffbc756440 RBX: 0000000000000000 RCX: 0000000000000001
    RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff8b574eaab740
    RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
    R10: ffff8b57444cec70 R11: 0000000000000000 R12: 0000000000000003
    R13: 0000000000000002 R14: ffff8b574eaab740 R15: ffffffffbd8e4748
     ? __pfx_apparmor_socket_post_create+0x10/0x10
     security_socket_post_create+0x4b/0x80
     __sock_create+0x176/0x1f0
     __sys_socket+0x89/0x100
     __x64_sys_socket+0x17/0x20
     do_syscall_64+0x5d/0x90
     ? do_syscall_64+0x6c/0x90
     ? do_syscall_64+0x6c/0x90
     ? do_syscall_64+0x6c/0x90
     entry_SYSCALL_64_after_hwframe+0x72/0xdc</Note>
    </Notes>
    <CVE>CVE-2023-52889</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gsmi: fix null-deref in gsmi_get_variable

We can get EFI variables without fetching the attribute, so we must
allow for that in gsmi.

commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore
access layer") added a new get_variable call with attr=NULL, which
triggers panic in gsmi.</Note>
    </Notes>
    <CVE>CVE-2023-52893</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: f_ncm: fix potential NULL ptr deref in ncm_bitrate()

In Google internal bug 265639009 we've received an (as yet) unreproducible
crash report from an aarch64 GKI 5.10.149-android13 running device.

AFAICT the source code is at:
  https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10

The call stack is:
  ncm_close() -&gt; ncm_notify() -&gt; ncm_do_notify()
with the crash at:
  ncm_do_notify+0x98/0x270
Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)

Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...):

  // halfword (16-bit) store presumably to event-&gt;wLength (at offset 6 of struct usb_cdc_notification)
  0B 0D 00 79    strh w11, [x8, #6]

  // word (32-bit) store presumably to req-&gt;Length (at offset 8 of struct usb_request)
  6C 0A 00 B9    str  w12, [x19, #8]

  // x10 (NULL) was read here from offset 0 of valid pointer x9
  // IMHO we're reading 'cdev-&gt;gadget' and getting NULL
  // gadget is indeed at offset 0 of struct usb_composite_dev
  2A 01 40 F9    ldr  x10, [x9]

  // loading req-&gt;buf pointer, which is at offset 0 of struct usb_request
  69 02 40 F9    ldr  x9, [x19]

  // x10 is null, crash, appears to be attempt to read cdev-&gt;gadget-&gt;max_speed
  4B 5D 40 B9    ldr  w11, [x10, #0x5c]

which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment:

  event-&gt;wLength = cpu_to_le16(8);
  req-&gt;length = NCM_STATUS_BYTECOUNT;

  /* SPEED_CHANGE data is up/down speeds in bits/sec */
  data = req-&gt;buf + sizeof *event;
  data[0] = cpu_to_le32(ncm_bitrate(cdev-&gt;gadget));

My analysis of registers and NULL ptr deref crash offset
  (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)
heavily suggests that the crash is due to 'cdev-&gt;gadget' being NULL when executing:
  data[0] = cpu_to_le32(ncm_bitrate(cdev-&gt;gadget));
which calls:
  ncm_bitrate(NULL)
which then calls:
  gadget_is_superspeed(NULL)
which reads
  ((struct usb_gadget *)NULL)-&gt;max_speed
and hits a panic.

AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.
(remember there's a GKI KABI reservation of 16 bytes in struct work_struct)

It's not at all clear to me how this is all supposed to work...
but returning 0 seems much better than panic-ing...</Note>
    </Notes>
    <CVE>CVE-2023-52894</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 between quota rescan and disable leading to NULL pointer deref

If we have one task trying to start the quota rescan worker while another
one is trying to disable quotas, we can end up hitting a race that results
in the quota rescan worker doing a NULL pointer dereference. The steps for
this are the following:

1) Quotas are enabled;

2) Task A calls the quota rescan ioctl and enters btrfs_qgroup_rescan().
   It calls qgroup_rescan_init() which returns 0 (success) and then joins a
   transaction and commits it;

3) Task B calls the quota disable ioctl and enters btrfs_quota_disable().
   It clears the bit BTRFS_FS_QUOTA_ENABLED from fs_info-&gt;flags and calls
   btrfs_qgroup_wait_for_completion(), which returns immediately since the
   rescan worker is not yet running.
   Then it starts a transaction and locks fs_info-&gt;qgroup_ioctl_lock;

4) Task A queues the rescan worker, by calling btrfs_queue_work();

5) The rescan worker starts, and calls rescan_should_stop() at the start
   of its while loop, which results in 0 iterations of the loop, since
   the flag BTRFS_FS_QUOTA_ENABLED was cleared from fs_info-&gt;flags by
   task B at step 3);

6) Task B sets fs_info-&gt;quota_root to NULL;

7) The rescan worker tries to start a transaction and uses
   fs_info-&gt;quota_root as the root argument for btrfs_start_transaction().
   This results in a NULL pointer dereference down the call chain of
   btrfs_start_transaction(). The stack trace is something like the one
   reported in Link tag below:

   general protection fault, probably for non-canonical address 0xdffffc0000000041: 0000 [#1] PREEMPT SMP KASAN
   KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f]
   CPU: 1 PID: 34 Comm: kworker/u4:2 Not tainted 6.1.0-syzkaller-13872-gb6bb9676f216 #0
   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
   Workqueue: btrfs-qgroup-rescan btrfs_work_helper
   RIP: 0010:start_transaction+0x48/0x10f0 fs/btrfs/transaction.c:564
   Code: 48 89 fb 48 (...)
   RSP: 0018:ffffc90000ab7ab0 EFLAGS: 00010206
   RAX: 0000000000000041 RBX: 0000000000000208 RCX: ffff88801779ba80
   RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
   RBP: dffffc0000000000 R08: 0000000000000001 R09: fffff52000156f5d
   R10: fffff52000156f5d R11: 1ffff92000156f5c R12: 0000000000000000
   R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000003
   FS:  0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
   CR2: 00007f2bea75b718 CR3: 000000001d0cc000 CR4: 00000000003506e0
   DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
   DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
   Call Trace:
    &lt;TASK&gt;
    btrfs_qgroup_rescan_worker+0x3bb/0x6a0 fs/btrfs/qgroup.c:3402
    btrfs_work_helper+0x312/0x850 fs/btrfs/async-thread.c:280
    process_one_work+0x877/0xdb0 kernel/workqueue.c:2289
    worker_thread+0xb14/0x1330 kernel/workqueue.c:2436
    kthread+0x266/0x300 kernel/kthread.c:376
    ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
    &lt;/TASK&gt;
   Modules linked in:

So fix this by having the rescan worker function not attempt to start a
transaction if it didn't do any rescan work.</Note>
    </Notes>
    <CVE>CVE-2023-52896</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix null pointer dereference when host dies

Make sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race
and cause null pointer dereference when host suddenly dies.

Usb core may call xhci_free_dev() which frees the xhci-&gt;devs[slot_id]
virt device at the same time that xhci_kill_endpoint_urbs() tries to
loop through all the device's endpoints, checking if there are any
cancelled urbs left to give back.

hold the xhci spinlock while freeing the virt device</Note>
    </Notes>
    <CVE>CVE-2023-52898</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Add exception protection processing for vd in axi_chan_handle_err function

Since there is no protection for vd, a kernel panic will be
triggered here in exceptional cases.

You can refer to the processing of axi_chan_block_xfer_complete function

The triggered kernel panic is as follows:

[   67.848444] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060
[   67.848447] Mem abort info:
[   67.848449]   ESR = 0x96000004
[   67.848451]   EC = 0x25: DABT (current EL), IL = 32 bits
[   67.848454]   SET = 0, FnV = 0
[   67.848456]   EA = 0, S1PTW = 0
[   67.848458] Data abort info:
[   67.848460]   ISV = 0, ISS = 0x00000004
[   67.848462]   CM = 0, WnR = 0
[   67.848465] user pgtable: 4k pages, 48-bit VAs, pgdp=00000800c4c0b000
[   67.848468] [0000000000000060] pgd=0000000000000000, p4d=0000000000000000
[   67.848472] Internal error: Oops: 96000004 [#1] SMP
[   67.848475] Modules linked in: dmatest
[   67.848479] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.100-emu_x2rc+ #11
[   67.848483] pstate: 62000085 (nZCv daIf -PAN -UAO +TCO BTYPE=--)
[   67.848487] pc : axi_chan_handle_err+0xc4/0x230
[   67.848491] lr : axi_chan_handle_err+0x30/0x230
[   67.848493] sp : ffff0803fe55ae50
[   67.848495] x29: ffff0803fe55ae50 x28: ffff800011212200
[   67.848500] x27: ffff0800c42c0080 x26: ffff0800c097c080
[   67.848504] x25: ffff800010d33880 x24: ffff80001139d850
[   67.848508] x23: ffff0800c097c168 x22: 0000000000000000
[   67.848512] x21: 0000000000000080 x20: 0000000000002000
[   67.848517] x19: ffff0800c097c080 x18: 0000000000000000
[   67.848521] x17: 0000000000000000 x16: 0000000000000000
[   67.848525] x15: 0000000000000000 x14: 0000000000000000
[   67.848529] x13: 0000000000000000 x12: 0000000000000040
[   67.848533] x11: ffff0800c0400248 x10: ffff0800c040024a
[   67.848538] x9 : ffff800010576cd4 x8 : ffff0800c0400270
[   67.848542] x7 : 0000000000000000 x6 : ffff0800c04003e0
[   67.848546] x5 : ffff0800c0400248 x4 : ffff0800c4294480
[   67.848550] x3 : dead000000000100 x2 : dead000000000122
[   67.848555] x1 : 0000000000000100 x0 : ffff0800c097c168
[   67.848559] Call trace:
[   67.848562]  axi_chan_handle_err+0xc4/0x230
[   67.848566]  dw_axi_dma_interrupt+0xf4/0x590
[   67.848569]  __handle_irq_event_percpu+0x60/0x220
[   67.848573]  handle_irq_event+0x64/0x120
[   67.848576]  handle_fasteoi_irq+0xc4/0x220
[   67.848580]  __handle_domain_irq+0x80/0xe0
[   67.848583]  gic_handle_irq+0xc0/0x138
[   67.848585]  el1_irq+0xc8/0x180
[   67.848588]  arch_cpu_idle+0x14/0x2c
[   67.848591]  default_idle_call+0x40/0x16c
[   67.848594]  do_idle+0x1f0/0x250
[   67.848597]  cpu_startup_entry+0x2c/0x60
[   67.848600]  rest_init+0xc0/0xcc
[   67.848603]  arch_call_rest_init+0x14/0x1c
[   67.848606]  start_kernel+0x4cc/0x500
[   67.848610] Code: eb0002ff 9a9f12d6 f2fbd5a2 f2fbd5a3 (a94602c1)
[   67.848613] ---[ end trace 585a97036f88203a ]---</Note>
    </Notes>
    <CVE>CVE-2023-52899</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 general protection fault in nilfs_btree_insert()

If nilfs2 reads a corrupted disk image and tries to reads a b-tree node
block by calling __nilfs_btree_get_block() against an invalid virtual
block address, it returns -ENOENT because conversion of the virtual block
address to a disk block address fails.  However, this return value is the
same as the internal code that b-tree lookup routines return to indicate
that the block being searched does not exist, so functions that operate on
that b-tree may misbehave.

When nilfs_btree_insert() receives this spurious 'not found' code from
nilfs_btree_do_lookup(), it misunderstands that the 'not found' check was
successful and continues the insert operation using incomplete lookup path
data, causing the following crash:

 general protection fault, probably for non-canonical address
 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN
 KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
 ...
 RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline]
 RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline]
 RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238
 Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89
 ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 &lt;42&gt; 80 3c
 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02
 ...
 Call Trace:
 &lt;TASK&gt;
  nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline]
  nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147
  nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101
  __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991
  __block_write_begin fs/buffer.c:2041 [inline]
  block_write_begin+0x93/0x1e0 fs/buffer.c:2102
  nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261
  generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772
  __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900
  generic_file_write_iter+0xab/0x310 mm/filemap.c:3932
  call_write_iter include/linux/fs.h:2186 [inline]
  new_sync_write fs/read_write.c:491 [inline]
  vfs_write+0x7dc/0xc50 fs/read_write.c:584
  ksys_write+0x177/0x2a0 fs/read_write.c:637
  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
  do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
  entry_SYSCALL_64_after_hwframe+0x63/0xcd
 ...
 &lt;/TASK&gt;

This patch fixes the root cause of this problem by replacing the error
code that __nilfs_btree_get_block() returns on block address conversion
failure from -ENOENT to another internal code -EINVAL which means that the
b-tree metadata is corrupted.

By returning -EINVAL, it propagates without glitches, and for all relevant
b-tree operations, functions in the upper bmap layer output an error
message indicating corrupted b-tree metadata via
nilfs_bmap_convert_error(), and code -EIO will be eventually returned as
it should be.</Note>
    </Notes>
    <CVE>CVE-2023-52900</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: xhci: Check endpoint is valid before dereferencing it

When the host controller is not responding, all URBs queued to all
endpoints need to be killed. This can cause a kernel panic if we
dereference an invalid endpoint.

Fix this by using xhci_get_virt_ep() helper to find the endpoint and
checking if the endpoint is valid before dereferencing it.

[233311.853271] xhci-hcd xhci-hcd.1.auto: xHCI host controller not responding, assume dead
[233311.853393] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000e8

[233311.853964] pc : xhci_hc_died+0x10c/0x270
[233311.853971] lr : xhci_hc_died+0x1ac/0x270

[233311.854077] Call trace:
[233311.854085]  xhci_hc_died+0x10c/0x270
[233311.854093]  xhci_stop_endpoint_command_watchdog+0x100/0x1a4
[233311.854105]  call_timer_fn+0x50/0x2d4
[233311.854112]  expire_timers+0xac/0x2e4
[233311.854118]  run_timer_softirq+0x300/0xabc
[233311.854127]  __do_softirq+0x148/0x528
[233311.854135]  irq_exit+0x194/0x1a8
[233311.854143]  __handle_domain_irq+0x164/0x1d0
[233311.854149]  gic_handle_irq.22273+0x10c/0x188
[233311.854156]  el1_irq+0xfc/0x1a8
[233311.854175]  lpm_cpuidle_enter+0x25c/0x418 [msm_pm]
[233311.854185]  cpuidle_enter_state+0x1f0/0x764
[233311.854194]  do_idle+0x594/0x6ac
[233311.854201]  cpu_startup_entry+0x7c/0x80
[233311.854209]  secondary_start_kernel+0x170/0x198</Note>
    </Notes>
    <CVE>CVE-2023-52901</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 possible NULL pointer dereference in snd_usb_pcm_has_fixed_rate()

The subs function argument may be NULL, so do not use it before the NULL check.</Note>
    </Notes>
    <CVE>CVE-2023-52904</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

octeontx2-pf: Fix resource leakage in VF driver unbind

resources allocated like mcam entries to support the Ntuple feature
and hash tables for the tc feature are not getting freed in driver
unbind. This patch fixes the issue.</Note>
    </Notes>
    <CVE>CVE-2023-52905</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: act_mpls: Fix warning during failed attribute validation

The 'TCA_MPLS_LABEL' attribute is of 'NLA_U32' type, but has a
validation type of 'NLA_VALIDATE_FUNCTION'. This is an invalid
combination according to the comment above 'struct nla_policy':

"
Meaning of `validate' field, use via NLA_POLICY_VALIDATE_FN:
   NLA_BINARY           Validation function called for the attribute.
   All other            Unused - but note that it's a union
"

This can trigger the warning [1] in nla_get_range_unsigned() when
validation of the attribute fails. Despite being of 'NLA_U32' type, the
associated 'min'/'max' fields in the policy are negative as they are
aliased by the 'validate' field.

Fix by changing the attribute type to 'NLA_BINARY' which is consistent
with the above comment and all other users of NLA_POLICY_VALIDATE_FN().
As a result, move the length validation to the validation function.

No regressions in MPLS tests:

 # ./tdc.py -f tc-tests/actions/mpls.json
 [...]
 # echo $?
 0

[1]
WARNING: CPU: 0 PID: 17743 at lib/nlattr.c:118
nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117
Modules linked in:
CPU: 0 PID: 17743 Comm: syz-executor.0 Not tainted 6.1.0-rc8 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014
RIP: 0010:nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117
[...]
Call Trace:
 &lt;TASK&gt;
 __netlink_policy_dump_write_attr+0x23d/0x990 net/netlink/policy.c:310
 netlink_policy_dump_write_attr+0x22/0x30 net/netlink/policy.c:411
 netlink_ack_tlv_fill net/netlink/af_netlink.c:2454 [inline]
 netlink_ack+0x546/0x760 net/netlink/af_netlink.c:2506
 netlink_rcv_skb+0x1b7/0x240 net/netlink/af_netlink.c:2546
 rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:6109
 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
 netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1345
 netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1921
 sock_sendmsg_nosec net/socket.c:714 [inline]
 sock_sendmsg net/socket.c:734 [inline]
 ____sys_sendmsg+0x38f/0x500 net/socket.c:2482
 ___sys_sendmsg net/socket.c:2536 [inline]
 __sys_sendmsg+0x197/0x230 net/socket.c:2565
 __do_sys_sendmsg net/socket.c:2574 [inline]
 __se_sys_sendmsg net/socket.c:2572 [inline]
 __x64_sys_sendmsg+0x42/0x50 net/socket.c:2572
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd</Note>
    </Notes>
    <CVE>CVE-2023-52906</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: pn533: Wait for out_urb's completion in pn533_usb_send_frame()

Fix a use-after-free that occurs in hcd when in_urb sent from
pn533_usb_send_frame() is completed earlier than out_urb. Its callback
frees the skb data in pn533_send_async_complete() that is used as a
transfer buffer of out_urb. Wait before sending in_urb until the
callback of out_urb is called. To modify the callback of out_urb alone,
separate the complete function of out_urb and ack_urb.

Found by a modified version of syzkaller.

BUG: KASAN: use-after-free in dummy_timer
Call Trace:
 memcpy (mm/kasan/shadow.c:65)
 dummy_perform_transfer (drivers/usb/gadget/udc/dummy_hcd.c:1352)
 transfer (drivers/usb/gadget/udc/dummy_hcd.c:1453)
 dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:1972)
 arch_static_branch (arch/x86/include/asm/jump_label.h:27)
 static_key_false (include/linux/jump_label.h:207)
 timer_expire_exit (include/trace/events/timer.h:127)
 call_timer_fn (kernel/time/timer.c:1475)
 expire_timers (kernel/time/timer.c:1519)
 __run_timers (kernel/time/timer.c:1790)
 run_timer_softirq (kernel/time/timer.c:1803)</Note>
    </Notes>
    <CVE>CVE-2023-52907</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 potential NULL dereference

Fix potential NULL dereference, in the case when "man", the resource manager
might be NULL, when/if we print debug information.</Note>
    </Notes>
    <CVE>CVE-2023-52908</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix handling of cached open files in nfsd4_open codepath

Commit fb70bf124b05 ("NFSD: Instantiate a struct file when creating a
regular NFSv4 file") added the ability to cache an open fd over a
compound. There are a couple of problems with the way this currently
works:

It's racy, as a newly-created nfsd_file can end up with its PENDING bit
cleared while the nf is hashed, and the nf_file pointer is still zeroed
out. Other tasks can find it in this state and they expect to see a
valid nf_file, and can oops if nf_file is NULL.

Also, there is no guarantee that we'll end up creating a new nfsd_file
if one is already in the hash. If an extant entry is in the hash with a
valid nf_file, nfs4_get_vfs_file will clobber its nf_file pointer with
the value of op_file and the old nf_file will leak.

Fix both issues by making a new nfsd_file_acquirei_opened variant that
takes an optional file pointer. If one is present when this is called,
we'll take a new reference to it instead of trying to open the file. If
the nfsd_file already has a valid nf_file, we'll just ignore the
optional file and pass the nfsd_file back as-is.

Also rework the tracepoints a bit to allow for an "opened" variant and
don't try to avoid counting acquisitions in the case where we already
have a cached open file.</Note>
    </Notes>
    <CVE>CVE-2023-52909</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/iova: Fix alloc iova overflows issue

In __alloc_and_insert_iova_range, there is an issue that retry_pfn
overflows. The value of iovad-&gt;anchor.pfn_hi is ~0UL, then when
iovad-&gt;cached_node is iovad-&gt;anchor, curr_iova-&gt;pfn_hi + 1 will
overflow. As a result, if the retry logic is executed, low_pfn is
updated to 0, and then new_pfn &lt; low_pfn returns false to make the
allocation successful.

This issue occurs in the following two situations:
1. The first iova size exceeds the domain size. When initializing
iova domain, iovad-&gt;cached_node is assigned as iovad-&gt;anchor. For
example, the iova domain size is 10M, start_pfn is 0x1_F000_0000,
and the iova size allocated for the first time is 11M. The
following is the log information, new-&gt;pfn_lo is smaller than
iovad-&gt;cached_node.

Example log as follows:
[  223.798112][T1705487] sh: [name:iova&amp;]__alloc_and_insert_iova_range
start_pfn:0x1f0000,retry_pfn:0x0,size:0xb00,limit_pfn:0x1f0a00
[  223.799590][T1705487] sh: [name:iova&amp;]__alloc_and_insert_iova_range
success start_pfn:0x1f0000,new-&gt;pfn_lo:0x1efe00,new-&gt;pfn_hi:0x1f08ff

2. The node with the largest iova-&gt;pfn_lo value in the iova domain
is deleted, iovad-&gt;cached_node will be updated to iovad-&gt;anchor,
and then the alloc iova size exceeds the maximum iova size that can
be allocated in the domain.

After judging that retry_pfn is less than limit_pfn, call retry_pfn+1
to fix the overflow issue.</Note>
    </Notes>
    <CVE>CVE-2023-52910</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: another fix for the headless Adreno GPU

Fix another oops reproducible when rebooting the board with the Adreno
GPU working in the headless mode (e.g. iMX platforms).

Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read
[00000000] *pgd=74936831, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1] ARM
CPU: 0 PID: 51 Comm: reboot Not tainted 6.2.0-rc1-dirty #11
Hardware name: Freescale i.MX53 (Device Tree Support)
PC is at msm_atomic_commit_tail+0x50/0x970
LR is at commit_tail+0x9c/0x188
pc : [&lt;c06aa430&gt;]    lr : [&lt;c067a214&gt;]    psr: 600e0013
sp : e0851d30  ip : ee4eb7eb  fp : 00090acc
r10: 00000058  r9 : c2193014  r8 : c4310000
r7 : c4759380  r6 : 07bef61d  r5 : 00000000  r4 : 00000000
r3 : c44cc440  r2 : 00000000  r1 : 00000000  r0 : 00000000
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5387d  Table: 74910019  DAC: 00000051
Register r0 information: NULL pointer
Register r1 information: NULL pointer
Register r2 information: NULL pointer
Register r3 information: slab kmalloc-1k start c44cc400 pointer offset 64 size 1024
Register r4 information: NULL pointer
Register r5 information: NULL pointer
Register r6 information: non-paged memory
Register r7 information: slab kmalloc-128 start c4759380 pointer offset 0 size 128
Register r8 information: slab kmalloc-2k start c4310000 pointer offset 0 size 2048
Register r9 information: non-slab/vmalloc memory
Register r10 information: non-paged memory
Register r11 information: non-paged memory
Register r12 information: non-paged memory
Process reboot (pid: 51, stack limit = 0xc80046d9)
Stack: (0xe0851d30 to 0xe0852000)
1d20:                                     c4759380 fbd77200 000005ff 002b9c70
1d40: c4759380 c4759380 00000000 07bef61d 00000600 c0d6fe7c c2193014 00000058
1d60: 00090acc c067a214 00000000 c4759380 c4310000 00000000 c44cc854 c067a89c
1d80: 00000000 00000000 00000000 c4310468 00000000 c4759380 c4310000 c4310468
1da0: c4310470 c0643258 c4759380 00000000 00000000 c0c4ee24 00000000 c44cc810
1dc0: 00000000 c0c4ee24 00000000 c44cc810 00000000 0347d2a8 e0851e00 e0851e00
1de0: c4759380 c067ad20 c4310000 00000000 c44cc810 c27f8718 c44cc854 c067adb8
1e00: c4933000 00000002 00000001 00000000 00000000 c2130850 00000000 c2130854
1e20: c25fc488 00000000 c0ff162c 00000000 00000001 00000002 00000000 00000000
1e40: c43102c0 c43102c0 00000000 0347d2a8 c44cc810 c44cc814 c2133da8 c06d1a60
1e60: 00000000 00000000 00079028 c2012f24 fee1dead c4933000 00000058 c01431e4
1e80: 01234567 c0143a20 00000000 00000000 00000000 00000000 00000000 00000000
1ea0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1ec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1ee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1f00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1f20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1f40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1f60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1f80: 00000000 00000000 00000000 0347d2a8 00000002 00000004 00000078 00000058
1fa0: c010028c c0100060 00000002 00000004 fee1dead 28121969 01234567 00079028
1fc0: 00000002 00000004 00000078 00000058 0002fdc5 00000000 00000000 00090acc
1fe0: 00000058 becc9c64 b6e97e05 b6e0e5f6 600e0030 fee1dead 00000000 00000000
 msm_atomic_commit_tail from commit_tail+0x9c/0x188
 commit_tail from drm_atomic_helper_commit+0x160/0x188
 drm_atomic_helper_commit from drm_atomic_commit+0xac/0xe0
 drm_atomic_commit from drm_atomic_helper_disable_all+0x1b0/0x1c0
 drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x88/0x140
 drm_atomic_helper_shutdown from device_shutdown+0x16c/0x240
 device_shutdown from kernel_restart+0x38/0x90
 kernel_restart from __do_sys_reboot+0x
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-52911</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fixed bug on error when unloading amdgpu

Fixed bug on error when unloading amdgpu.

The error message is as follows:
[  377.706202] kernel BUG at drivers/gpu/drm/drm_buddy.c:278!
[  377.706215] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[  377.706222] CPU: 4 PID: 8610 Comm: modprobe Tainted: G          IOE      6.0.0-thomas #1
[  377.706231] Hardware name: ASUS System Product Name/PRIME Z390-A, BIOS 2004 11/02/2021
[  377.706238] RIP: 0010:drm_buddy_free_block+0x26/0x30 [drm_buddy]
[  377.706264] Code: 00 00 00 90 0f 1f 44 00 00 48 8b 0e 89 c8 25 00 0c 00 00 3d 00 04 00 00 75 10 48 8b 47 18 48 d3 e0 48 01 47 28 e9 fa fe ff ff &lt;0f&gt; 0b 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 55 48 89 f5 53
[  377.706282] RSP: 0018:ffffad2dc4683cb8 EFLAGS: 00010287
[  377.706289] RAX: 0000000000000000 RBX: ffff8b1743bd5138 RCX: 0000000000000000
[  377.706297] RDX: ffff8b1743bd5160 RSI: ffff8b1743bd5c78 RDI: ffff8b16d1b25f70
[  377.706304] RBP: ffff8b1743bd59e0 R08: 0000000000000001 R09: 0000000000000001
[  377.706311] R10: ffff8b16c8572400 R11: ffffad2dc4683cf0 R12: ffff8b16d1b25f70
[  377.706318] R13: ffff8b16d1b25fd0 R14: ffff8b1743bd59c0 R15: ffff8b16d1b25f70
[  377.706325] FS:  00007fec56c72c40(0000) GS:ffff8b1836500000(0000) knlGS:0000000000000000
[  377.706334] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  377.706340] CR2: 00007f9b88c1ba50 CR3: 0000000110450004 CR4: 00000000003706e0
[  377.706347] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  377.706354] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  377.706361] Call Trace:
[  377.706365]  &lt;TASK&gt;
[  377.706369]  drm_buddy_free_list+0x2a/0x60 [drm_buddy]
[  377.706376]  amdgpu_vram_mgr_fini+0xea/0x180 [amdgpu]
[  377.706572]  amdgpu_ttm_fini+0x12e/0x1a0 [amdgpu]
[  377.706650]  amdgpu_bo_fini+0x22/0x90 [amdgpu]
[  377.706727]  gmc_v11_0_sw_fini+0x26/0x30 [amdgpu]
[  377.706821]  amdgpu_device_fini_sw+0xa1/0x3c0 [amdgpu]
[  377.706897]  amdgpu_driver_release_kms+0x12/0x30 [amdgpu]
[  377.706975]  drm_dev_release+0x20/0x40 [drm]
[  377.707006]  release_nodes+0x35/0xb0
[  377.707014]  devres_release_all+0x8b/0xc0
[  377.707020]  device_unbind_cleanup+0xe/0x70
[  377.707027]  device_release_driver_internal+0xee/0x160
[  377.707033]  driver_detach+0x44/0x90
[  377.707039]  bus_remove_driver+0x55/0xe0
[  377.707045]  pci_unregister_driver+0x3b/0x90
[  377.707052]  amdgpu_exit+0x11/0x6c [amdgpu]
[  377.707194]  __x64_sys_delete_module+0x142/0x2b0
[  377.707201]  ? fpregs_assert_state_consistent+0x22/0x50
[  377.707208]  ? exit_to_user_mode_prepare+0x3e/0x190
[  377.707215]  do_syscall_64+0x38/0x90
[  377.707221]  entry_SYSCALL_64_after_hwframe+0x63/0xcd</Note>
    </Notes>
    <CVE>CVE-2023-52912</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 potential context UAFs

gem_context_register() makes the context visible to userspace, and which
point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
So we need to ensure that nothing uses the ctx ptr after this.  And we
need to ensure that adding the ctx to the xarray is the *last* thing
that gem_context_register() does with the ctx pointer.

[tursulin: Stable and fixes tags add/tidy.]
(cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c)</Note>
    </Notes>
    <CVE>CVE-2023-52913</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: dvb-usb-v2: af9035: Fix null-ptr-deref in af9035_i2c_master_xfer

In af9035_i2c_master_xfer, msg is controlled by user. When msg[i].buf
is null and msg[i].len is zero, former checks on msg[i].buf would be
passed. Malicious data finally reach af9035_i2c_master_xfer. If accessing
msg[i].buf[0] without sanity check, null ptr deref would happen.
We add check on msg[i].len to prevent crash.

Similar commit:
commit 0ed554fd769a
("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")</Note>
    </Notes>
    <CVE>CVE-2023-52915</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: aspeed: Fix memory overwrite if timing is 1600x900

When capturing 1600x900, system could crash when system memory usage is
tight.

The way to reproduce this issue:
1. Use 1600x900 to display on host
2. Mount ISO through 'Virtual media' on OpenBMC's web
3. Run script as below on host to do sha continuously
  #!/bin/bash
  while [ [1] ];
  do
	find /media -type f -printf '"%h/%f"\n' | xargs sha256sum
  done
4. Open KVM on OpenBMC's web

The size of macro block captured is 8x8. Therefore, we should make sure
the height of src-buf is 8 aligned to fix this issue.</Note>
    </Notes>
    <CVE>CVE-2023-52916</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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"/>
    </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">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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mcast: fix data-race in ipv6_mc_down / mld_ifc_work

idev-&gt;mc_ifc_count can be written over without proper locking.

Originally found by syzbot [1], fix this issue by encapsulating calls
to mld_ifc_stop_work() (and mld_gq_stop_work() for good measure) with
mutex_lock() and mutex_unlock() accordingly as these functions
should only be called with mc_lock per their declarations.

[1]
BUG: KCSAN: data-race in ipv6_mc_down / mld_ifc_work

write to 0xffff88813a80c832 of 1 bytes by task 3771 on cpu 0:
 mld_ifc_stop_work net/ipv6/mcast.c:1080 [inline]
 ipv6_mc_down+0x10a/0x280 net/ipv6/mcast.c:2725
 addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949
 addrconf_notify+0x310/0x980
 notifier_call_chain kernel/notifier.c:93 [inline]
 raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461
 __dev_notify_flags+0x205/0x3d0
 dev_change_flags+0xab/0xd0 net/core/dev.c:8685
 do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916
 rtnl_group_changelink net/core/rtnetlink.c:3458 [inline]
 __rtnl_newlink net/core/rtnetlink.c:3717 [inline]
 rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754
 rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558
 netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545
 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6576
 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]
 netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368
 netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c:1910
 ...

write to 0xffff88813a80c832 of 1 bytes by task 22 on cpu 1:
 mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653
 process_one_work kernel/workqueue.c:2627 [inline]
 process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2700
 worker_thread+0x525/0x730 kernel/workqueue.c:2781
 ...</Note>
    </Notes>
    <CVE>CVE-2024-26631</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: add sanity checks to rx zerocopy

TCP rx zerocopy intent is to map pages initially allocated
from NIC drivers, not pages owned by a fs.

This patch adds to can_map_frag() these additional checks:

- Page must not be a compound one.
- page-&gt;mapping must be NULL.

This fixes the panic reported by ZhangPeng.

syzbot was able to loopback packets built with sendfile(),
mapping pages owned by an ext4 file to TCP rx zerocopy.

r3 = socket$inet_tcp(0x2, 0x1, 0x0)
mmap(&amp;(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0)
r4 = socket$inet_tcp(0x2, 0x1, 0x0)
bind$inet(r4, &amp;(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10)
connect$inet(r4, &amp;(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10)
r5 = openat$dir(0xffffffffffffff9c, &amp;(0x7f00000000c0)='./file0\x00',
    0x181e42, 0x0)
fallocate(r5, 0x0, 0x0, 0x85b8)
sendfile(r4, r5, 0x0, 0x8ba0)
getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23,
    &amp;(0x7f00000001c0)={&amp;(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0,
    0x0, 0x0, 0x0, 0x0}, &amp;(0x7f0000000440)=0x40)
r6 = openat$dir(0xffffffffffffff9c, &amp;(0x7f00000000c0)='./file0\x00',
    0x181e42, 0x0)</Note>
    </Notes>
    <CVE>CVE-2024-26640</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_limit: reject configurations that cause integer overflow

Reject bogus configs where internal token counter wraps around.
This only occurs with very very large requests, such as 17gbyte/s.

Its better to reject this rather than having incorrect ratelimit.</Note>
    </Notes>
    <CVE>CVE-2024-26668</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: flower: Fix chain template offload

When a qdisc is deleted from a net device the stack instructs the
underlying driver to remove its flow offload callback from the
associated filter block using the 'FLOW_BLOCK_UNBIND' command. The stack
then continues to replay the removal of the filters in the block for
this driver by iterating over the chains in the block and invoking the
'reoffload' operation of the classifier being used. In turn, the
classifier in its 'reoffload' operation prepares and emits a
'FLOW_CLS_DESTROY' command for each filter.

However, the stack does not do the same for chain templates and the
underlying driver never receives a 'FLOW_CLS_TMPLT_DESTROY' command when
a qdisc is deleted. This results in a memory leak [1] which can be
reproduced using [2].

Fix by introducing a 'tmplt_reoffload' operation and have the stack
invoke it with the appropriate arguments as part of the replay.
Implement the operation in the sole classifier that supports chain
templates (flower) by emitting the 'FLOW_CLS_TMPLT_{CREATE,DESTROY}'
command based on whether a flow offload callback is being bound to a
filter block or being unbound from one.

As far as I can tell, the issue happens since cited commit which
reordered tcf_block_offload_unbind() before tcf_block_flush_all_chains()
in __tcf_block_put(). The order cannot be reversed as the filter block
is expected to be freed after flushing all the chains.

[1]
unreferenced object 0xffff888107e28800 (size 2048):
  comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s)
  hex dump (first 32 bytes):
    b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff  ..|......[......
    01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff  ................
  backtrace:
    [&lt;ffffffff81c06a68&gt;] __kmem_cache_alloc_node+0x1e8/0x320
    [&lt;ffffffff81ab374e&gt;] __kmalloc+0x4e/0x90
    [&lt;ffffffff832aec6d&gt;] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0
    [&lt;ffffffff832bc195&gt;] mlxsw_sp_flower_tmplt_create+0x145/0x180
    [&lt;ffffffff832b2e1a&gt;] mlxsw_sp_flow_block_cb+0x1ea/0x280
    [&lt;ffffffff83a10613&gt;] tc_setup_cb_call+0x183/0x340
    [&lt;ffffffff83a9f85a&gt;] fl_tmplt_create+0x3da/0x4c0
    [&lt;ffffffff83a22435&gt;] tc_ctl_chain+0xa15/0x1170
    [&lt;ffffffff838a863c&gt;] rtnetlink_rcv_msg+0x3cc/0xed0
    [&lt;ffffffff83ac87f0&gt;] netlink_rcv_skb+0x170/0x440
    [&lt;ffffffff83ac6270&gt;] netlink_unicast+0x540/0x820
    [&lt;ffffffff83ac6e28&gt;] netlink_sendmsg+0x8d8/0xda0
    [&lt;ffffffff83793def&gt;] ____sys_sendmsg+0x30f/0xa80
    [&lt;ffffffff8379d29a&gt;] ___sys_sendmsg+0x13a/0x1e0
    [&lt;ffffffff8379d50c&gt;] __sys_sendmsg+0x11c/0x1f0
    [&lt;ffffffff843b9ce0&gt;] do_syscall_64+0x40/0xe0
unreferenced object 0xffff88816d2c0400 (size 1024):
  comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s)
  hex dump (first 32 bytes):
    40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00  @.......W.8.....
    10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff  ..,m......,m....
  backtrace:
    [&lt;ffffffff81c06a68&gt;] __kmem_cache_alloc_node+0x1e8/0x320
    [&lt;ffffffff81ab36c1&gt;] __kmalloc_node+0x51/0x90
    [&lt;ffffffff81a8ed96&gt;] kvmalloc_node+0xa6/0x1f0
    [&lt;ffffffff82827d03&gt;] bucket_table_alloc.isra.0+0x83/0x460
    [&lt;ffffffff82828d2b&gt;] rhashtable_init+0x43b/0x7c0
    [&lt;ffffffff832aed48&gt;] mlxsw_sp_acl_ruleset_get+0x428/0x7a0
    [&lt;ffffffff832bc195&gt;] mlxsw_sp_flower_tmplt_create+0x145/0x180
    [&lt;ffffffff832b2e1a&gt;] mlxsw_sp_flow_block_cb+0x1ea/0x280
    [&lt;ffffffff83a10613&gt;] tc_setup_cb_call+0x183/0x340
    [&lt;ffffffff83a9f85a&gt;] fl_tmplt_create+0x3da/0x4c0
    [&lt;ffffffff83a22435&gt;] tc_ctl_chain+0xa15/0x1170
    [&lt;ffffffff838a863c&gt;] rtnetlink_rcv_msg+0x3cc/0xed0
    [&lt;ffffffff83ac87f0&gt;] netlink_rcv_skb+0x170/0x440
    [&lt;ffffffff83ac6270&gt;] netlink_unicast+0x540/0x820
    [&lt;ffffffff83ac6e28&gt;] netlink_sendmsg+0x8d8/0xda0
    [&lt;ffffffff83793def&gt;] ____sys_sendmsg+0x30f/0xa80

[2]
 # tc qdisc add dev swp1 clsact
 # tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32
 # tc qdisc del dev
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-26669</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sr: fix possible use-after-free and null-ptr-deref

The pernet operations structure for the subsystem must be registered
before registering the generic netlink family.</Note>
    </Notes>
    <CVE>CVE-2024-26735</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/swap: fix race when skipping swapcache

When skipping swapcache for SWP_SYNCHRONOUS_IO, if two or more threads
swapin the same entry at the same time, they get different pages (A, B). 
Before one thread (T0) finishes the swapin and installs page (A) to the
PTE, another thread (T1) could finish swapin of page (B), swap_free the
entry, then swap out the possibly modified page reusing the same entry. 
It breaks the pte_same check in (T0) because PTE value is unchanged,
causing ABA problem.  Thread (T0) will install a stalled page (A) into the
PTE and cause data corruption.

One possible callstack is like this:

CPU0                                 CPU1
----                                 ----
do_swap_page()                       do_swap_page() with same entry
&lt;direct swapin path&gt;                 &lt;direct swapin path&gt;
&lt;alloc page A&gt;                       &lt;alloc page B&gt;
swap_read_folio() &lt;- read to page A  swap_read_folio() &lt;- read to page B
&lt;slow on later locks or interrupt&gt;   &lt;finished swapin first&gt;
...                                  set_pte_at()
                                     swap_free() &lt;- entry is free
                                     &lt;write to page B, now page A stalled&gt;
                                     &lt;swap out page B to same swap entry&gt;
pte_same() &lt;- Check pass, PTE seems
              unchanged, but page A
              is stalled!
swap_free() &lt;- page B content lost!
set_pte_at() &lt;- staled page A installed!

And besides, for ZRAM, swap_free() allows the swap device to discard the
entry content, so even if page (B) is not modified, if swap_read_folio()
on CPU0 happens later than swap_free() on CPU1, it may also cause data
loss.

To fix this, reuse swapcache_prepare which will pin the swap entry using
the cache flag, and allow only one thread to swap it in, also prevent any
parallel code from putting the entry in the cache.  Release the pin after
PT unlocked.

Racers just loop and wait since it's a rare and very short event.  A
schedule_timeout_uninterruptible(1) call is added to avoid repeated page
faults wasting too much CPU, causing livelock or adding too much noise to
perf statistics.  A similar livelock issue was described in commit
029c4628b2eb ("mm: swap: get rid of livelock in swapin readahead")

Reproducer:

This race issue can be triggered easily using a well constructed
reproducer and patched brd (with a delay in read path) [1]:

With latest 6.8 mainline, race caused data loss can be observed easily:
$ gcc -g -lpthread test-thread-swap-race.c &amp;&amp; ./a.out
  Polulating 32MB of memory region...
  Keep swapping out...
  Starting round 0...
  Spawning 65536 workers...
  32746 workers spawned, wait for done...
  Round 0: Error on 0x5aa00, expected 32746, got 32743, 3 data loss!
  Round 0: Error on 0x395200, expected 32746, got 32743, 3 data loss!
  Round 0: Error on 0x3fd000, expected 32746, got 32737, 9 data loss!
  Round 0 Failed, 15 data loss!

This reproducer spawns multiple threads sharing the same memory region
using a small swap device.  Every two threads updates mapped pages one by
one in opposite direction trying to create a race, with one dedicated
thread keep swapping out the data out using madvise.

The reproducer created a reproduce rate of about once every 5 minutes, so
the race should be totally possible in production.

After this patch, I ran the reproducer for over a few hundred rounds and
no data loss observed.

Performance overhead is minimal, microbenchmark swapin 10G from 32G
zram:

Before:     10934698 us
After:      11157121 us
Cached:     13155355 us (Dropping SWP_SYNCHRONOUS_IO flag)

[kasong@tencent.com: v4]</Note>
    </Notes>
    <CVE>CVE-2024-26759</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ip_tunnel: prevent perpetual headroom growth

syzkaller triggered following kasan splat:
BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170
Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191
[..]
 kasan_report+0xda/0x110 mm/kasan/report.c:588
 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170
 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline]
 ___skb_get_hash net/core/flow_dissector.c:1791 [inline]
 __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856
 skb_get_hash include/linux/skbuff.h:1556 [inline]
 ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748
 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308
 __netdev_start_xmit include/linux/netdevice.h:4940 [inline]
 netdev_start_xmit include/linux/netdevice.h:4954 [inline]
 xmit_one net/core/dev.c:3548 [inline]
 dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564
 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349
 dev_queue_xmit include/linux/netdevice.h:3134 [inline]
 neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592
 ...
 ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235
 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323
 ..
 iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82
 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831
 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665
 __netdev_start_xmit include/linux/netdevice.h:4940 [inline]
 netdev_start_xmit include/linux/netdevice.h:4954 [inline]
 xmit_one net/core/dev.c:3548 [inline]
 dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564
 ...

The splat occurs because skb-&gt;data points past skb-&gt;head allocated area.
This is because neigh layer does:
  __skb_pull(skb, skb_network_offset(skb));

... but skb_network_offset() returns a negative offset and __skb_pull()
arg is unsigned.  IOW, we skb-&gt;data gets "adjusted" by a huge value.

The negative value is returned because skb-&gt;head and skb-&gt;data distance is
more than 64k and skb-&gt;network_header (u16) has wrapped around.

The bug is in the ip_tunnel infrastructure, which can cause
dev-&gt;needed_headroom to increment ad infinitum.

The syzkaller reproducer consists of packets getting routed via a gre
tunnel, and route of gre encapsulated packets pointing at another (ipip)
tunnel.  The ipip encapsulation finds gre0 as next output device.

This results in the following pattern:

1). First packet is to be sent out via gre0.
Route lookup found an output device, ipip0.

2).
ip_tunnel_xmit for gre0 bumps gre0-&gt;needed_headroom based on the future
output device, rt.dev-&gt;needed_headroom (ipip0).

3).
ip output / start_xmit moves skb on to ipip0. which runs the same
code path again (xmit recursion).

4).
Routing step for the post-gre0-encap packet finds gre0 as output device
to use for ipip0 encapsulated packet.

tunl0-&gt;needed_headroom is then incremented based on the (already bumped)
gre0 device headroom.

This repeats for every future packet:

gre0-&gt;needed_headroom gets inflated because previous packets' ipip0 step
incremented rt-&gt;dev (gre0) headroom, and ipip0 incremented because gre0
needed_headroom was increased.

For each subsequent packet, gre/ipip0-&gt;needed_headroom grows until
post-expand-head reallocations result in a skb-&gt;head/data distance of
more than 64k.

Once that happens, skb-&gt;network_header (u16) wraps around when
pskb_expand_head tries to make sure that skb_network_offset() is unchanged
after the headroom expansion/reallocation.

After this skb_network_offset(skb) returns a different (and negative)
result post headroom expansion.

The next trip to neigh layer (or anything else that would __skb_pull the
network header) makes skb-&gt;data point to a memory location outside
skb-&gt;head area.

v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to
prevent perpetual increase instead of dropping the headroom increment
completely.</Note>
    </Notes>
    <CVE>CVE-2024-26804</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_chain_filter: handle NETDEV_UNREGISTER for inet/ingress basechain

Remove netdevice from inet/ingress basechain in case NETDEV_UNREGISTER
event is reported, otherwise a stale reference to netdevice remains in
the hook list.</Note>
    </Notes>
    <CVE>CVE-2024-26808</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

vfio/pci: Create persistent INTx handler

A vulnerability exists where the eventfd for INTx signaling can be
deconfigured, which unregisters the IRQ handler but still allows
eventfds to be signaled with a NULL context through the SET_IRQS ioctl
or through unmask irqfd if the device interrupt is pending.

Ideally this could be solved with some additional locking; the igate
mutex serializes the ioctl and config space accesses, and the interrupt
handler is unregistered relative to the trigger, but the irqfd path
runs asynchronous to those.  The igate mutex cannot be acquired from the
atomic context of the eventfd wake function.  Disabling the irqfd
relative to the eventfd registration is potentially incompatible with
existing userspace.

As a result, the solution implemented here moves configuration of the
INTx interrupt handler to track the lifetime of the INTx context object
and irq_type configuration, rather than registration of a particular
trigger eventfd.  Synchronization is added between the ioctl path and
eventfd_signal() wrapper such that the eventfd trigger can be
dynamically updated relative to in-flight interrupts or irqfd callbacks.</Note>
    </Notes>
    <CVE>CVE-2024-26812</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: set dormant flag on hook register failure

We need to set the dormant flag again if we fail to register
the hooks.

During memory pressure hook registration can fail and we end up
with a table marked as active but no registered hooks.

On table/base chain deletion, nf_tables will attempt to unregister
the hook again which yields a warn splat from the nftables core.</Note>
    </Notes>
    <CVE>CVE-2024-26835</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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: bridge: switchdev: Skip MDB replays of deferred events on offload

Before this change, generation of the list of MDB events to replay
would race against the creation of new group memberships, either from
the IGMP/MLD snooping logic or from user configuration.

While new memberships are immediately visible to walkers of
br-&gt;mdb_list, the notification of their existence to switchdev event
subscribers is deferred until a later point in time. So if a replay
list was generated during a time that overlapped with such a window,
it would also contain a replay of the not-yet-delivered event.

The driver would thus receive two copies of what the bridge internally
considered to be one single event. On destruction of the bridge, only
a single membership deletion event was therefore sent. As a
consequence of this, drivers which reference count memberships (at
least DSA), would be left with orphan groups in their hardware
database when the bridge was destroyed.

This is only an issue when replaying additions. While deletion events
may still be pending on the deferred queue, they will already have
been removed from br-&gt;mdb_list, so no duplicates can be generated in
that scenario.

To a user this meant that old group memberships, from a bridge in
which a port was previously attached, could be reanimated (in
hardware) when the port joined a new bridge, without the new bridge's
knowledge.

For example, on an mv88e6xxx system, create a snooping bridge and
immediately add a port to it:

    root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 &amp;&amp; \
    &gt; ip link set dev x3 up master br0

And then destroy the bridge:

    root@infix-06-0b-00:~$ ip link del dev br0
    root@infix-06-0b-00:~$ mvls atu
    ADDRESS             FID  STATE      Q  F  0  1  2  3  4  5  6  7  8  9  a
    DEV:0 Marvell 88E6393X
    33:33:00:00:00:6a     1  static     -  -  0  .  .  .  .  .  .  .  .  .  .
    33:33:ff:87:e4:3f     1  static     -  -  0  .  .  .  .  .  .  .  .  .  .
    ff:ff:ff:ff:ff:ff     1  static     -  -  0  1  2  3  4  5  6  7  8  9  a
    root@infix-06-0b-00:~$

The two IPv6 groups remain in the hardware database because the
port (x3) is notified of the host's membership twice: once via the
original event and once via a replay. Since only a single delete
notification is sent, the count remains at 1 when the bridge is
destroyed.

Then add the same port (or another port belonging to the same hardware
domain) to a new bridge, this time with snooping disabled:

    root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 &amp;&amp; \
    &gt; ip link set dev x3 up master br1

All multicast, including the two IPv6 groups from br0, should now be
flooded, according to the policy of br1. But instead the old
memberships are still active in the hardware database, causing the
switch to only forward traffic to those groups towards the CPU (port
0).

Eliminate the race in two steps:

1. Grab the write-side lock of the MDB while generating the replay
   list.

This prevents new memberships from showing up while we are generating
the replay list. But it leaves the scenario in which a deferred event
was already generated, but not delivered, before we grabbed the
lock. Therefore:

2. Make sure that no deferred version of a replay event is already
   enqueued to the switchdev deferred queue, before adding it to the
   replay list, when replaying additions.</Note>
    </Notes>
    <CVE>CVE-2024-26837</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

netfilter: nf_conntrack_h323: Add protection for bmp length out of range

UBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shifts
that are out of bounds for their data type.

vmlinux   get_bitmap(b=75) + 712
&lt;net/netfilter/nf_conntrack_h323_asn1.c:0&gt;
vmlinux   decode_seq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, level=134443100) + 1956
&lt;net/netfilter/nf_conntrack_h323_asn1.c:592&gt;
vmlinux   decode_choice(base=0xFFFFFFD0080370F0, level=23843636) + 1216
&lt;net/netfilter/nf_conntrack_h323_asn1.c:814&gt;
vmlinux   decode_seq(f=0xFFFFFFD0080371A8, level=134443500) + 812
&lt;net/netfilter/nf_conntrack_h323_asn1.c:576&gt;
vmlinux   decode_choice(base=0xFFFFFFD008037280, level=0) + 1216
&lt;net/netfilter/nf_conntrack_h323_asn1.c:814&gt;
vmlinux   DecodeRasMessage() + 304
&lt;net/netfilter/nf_conntrack_h323_asn1.c:833&gt;
vmlinux   ras_help() + 684
&lt;net/netfilter/nf_conntrack_h323_main.c:1728&gt;
vmlinux   nf_confirm() + 188
&lt;net/netfilter/nf_conntrack_proto.c:137&gt;

Due to abnormal data in skb-&gt;data, the extension bitmap length
exceeds 32 when decoding ras message then uses the length to make
a shift operation. It will change into negative after several loop.
UBSAN load could detect a negative shift as an undefined behaviour
and reports exception.
So we add the protection to avoid the length exceeding 32. Or else
it will return out of range error and stop decoding.</Note>
    </Notes>
    <CVE>CVE-2024-26851</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Disallow vsyscall page read for copy_from_kernel_nofault()

When trying to use copy_from_kernel_nofault() to read vsyscall page
through a bpf program, the following oops was reported:

  BUG: unable to handle page fault for address: ffffffffff600000
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 3231067 P4D 3231067 PUD 3233067 PMD 3235067 PTE 0
  Oops: 0000 [#1] PREEMPT SMP PTI
  CPU: 1 PID: 20390 Comm: test_progs ...... 6.7.0+ #58
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......
  RIP: 0010:copy_from_kernel_nofault+0x6f/0x110
  ......
  Call Trace:
   &lt;TASK&gt;
   ? copy_from_kernel_nofault+0x6f/0x110
   bpf_probe_read_kernel+0x1d/0x50
   bpf_prog_2061065e56845f08_do_probe_read+0x51/0x8d
   trace_call_bpf+0xc5/0x1c0
   perf_call_bpf_enter.isra.0+0x69/0xb0
   perf_syscall_enter+0x13e/0x200
   syscall_trace_enter+0x188/0x1c0
   do_syscall_64+0xb5/0xe0
   entry_SYSCALL_64_after_hwframe+0x6e/0x76
   &lt;/TASK&gt;
  ......
  ---[ end trace 0000000000000000 ]---

The oops is triggered when:

1) A bpf program uses bpf_probe_read_kernel() to read from the vsyscall
page and invokes copy_from_kernel_nofault() which in turn calls
__get_user_asm().

2) Because the vsyscall page address is not readable from kernel space,
a page fault exception is triggered accordingly.

3) handle_page_fault() considers the vsyscall page address as a user
space address instead of a kernel space address. This results in the
fix-up setup by bpf not being applied and a page_fault_oops() is invoked
due to SMAP.

Considering handle_page_fault() has already considered the vsyscall page
address as a userspace address, fix the problem by disallowing vsyscall
page read for copy_from_kernel_nofault().</Note>
    </Notes>
    <CVE>CVE-2024-26906</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 mirred deadlock on device recursion

When the mirred action is used on a classful egress qdisc and a packet is
mirrored or redirected to self we hit a qdisc lock deadlock.
See trace below.

[..... other info removed for brevity....]
[   82.890906]
[   82.890906] ============================================
[   82.890906] WARNING: possible recursive locking detected
[   82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G        W
[   82.890906] --------------------------------------------
[   82.890906] ping/418 is trying to acquire lock:
[   82.890906] ffff888006994110 (&amp;sch-&gt;q.lock){+.-.}-{3:3}, at:
__dev_queue_xmit+0x1778/0x3550
[   82.890906]
[   82.890906] but task is already holding lock:
[   82.890906] ffff888006994110 (&amp;sch-&gt;q.lock){+.-.}-{3:3}, at:
__dev_queue_xmit+0x1778/0x3550
[   82.890906]
[   82.890906] other info that might help us debug this:
[   82.890906]  Possible unsafe locking scenario:
[   82.890906]
[   82.890906]        CPU0
[   82.890906]        ----
[   82.890906]   lock(&amp;sch-&gt;q.lock);
[   82.890906]   lock(&amp;sch-&gt;q.lock);
[   82.890906]
[   82.890906]  *** DEADLOCK ***
[   82.890906]
[..... other info removed for brevity....]

Example setup (eth0-&gt;eth0) to recreate
tc qdisc add dev eth0 root handle 1: htb default 30
tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \
     action mirred egress redirect dev eth0

Another example(eth0-&gt;eth1-&gt;eth0) to recreate
tc qdisc add dev eth0 root handle 1: htb default 30
tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \
     action mirred egress redirect dev eth1

tc qdisc add dev eth1 root handle 1: htb default 30
tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \
     action mirred egress redirect dev eth0

We fix this by adding an owner field (CPU id) to struct Qdisc set after
root qdisc is entered. When the softirq enters it a second time, if the
qdisc owner is the same CPU, the packet is dropped to break the loop.</Note>
    </Notes>
    <CVE>CVE-2024-27010</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix memleak in map from abort path

The delete set command does not rely on the transaction object for
element removal, therefore, a combination of delete element + delete set
from the abort path could result in restoring twice the refcount of the
mapping.

Check for inactive element in the next generation for the delete element
command in the abort path, skip restoring state if next generation bit
has been already cleared. This is similar to the activate logic using
the set walk iterator.

[ 6170.286929] ------------[ cut here ]------------
[ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.287071] Modules linked in: [...]
[ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365
[ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 &lt;0f&gt; 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f
[ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202
[ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000
[ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750
[ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55
[ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10
[ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100
[ 6170.287940] FS:  0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000
[ 6170.287948] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0
[ 6170.287962] Call Trace:
[ 6170.287967]  &lt;TASK&gt;
[ 6170.287973]  ? __warn+0x9f/0x1a0
[ 6170.287986]  ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.288092]  ? report_bug+0x1b1/0x1e0
[ 6170.287986]  ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.288092]  ? report_bug+0x1b1/0x1e0
[ 6170.288104]  ? handle_bug+0x3c/0x70
[ 6170.288112]  ? exc_invalid_op+0x17/0x40
[ 6170.288120]  ? asm_exc_invalid_op+0x1a/0x20
[ 6170.288132]  ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]
[ 6170.288243]  ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.288366]  ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]
[ 6170.288483]  nf_tables_trans_destroy_work+0x588/0x590 [nf_tables]</Note>
    </Notes>
    <CVE>CVE-2024-27011</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: flowtable: validate pppoe header

Ensure there is sufficient room to access the protocol field of the
PPPoe header. Validate it once before the flowtable lookup, then use a
helper function to access protocol field.</Note>
    </Notes>
    <CVE>CVE-2024-27016</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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:

iommu/vt-d: Fix NULL domain on device release

In the kdump kernel, the IOMMU operates in deferred_attach mode. In this
mode, info-&gt;domain may not yet be assigned by the time the release_device
function is called. It leads to the following crash in the crash kernel:

    BUG: kernel NULL pointer dereference, address: 000000000000003c
    ...
    RIP: 0010:do_raw_spin_lock+0xa/0xa0
    ...
    _raw_spin_lock_irqsave+0x1b/0x30
    intel_iommu_release_device+0x96/0x170
    iommu_deinit_device+0x39/0xf0
    __iommu_group_remove_device+0xa0/0xd0
    iommu_bus_notifier+0x55/0xb0
    notifier_call_chain+0x5a/0xd0
    blocking_notifier_call_chain+0x41/0x60
    bus_notify+0x34/0x50
    device_del+0x269/0x3d0
    pci_remove_bus_device+0x77/0x100
    p2sb_bar+0xae/0x1d0
    ...
    i801_probe+0x423/0x740

Use the release_domain mechanism to fix it. The scalable mode context
entry which is not part of release domain should be cleared in
release_device().</Note>
    </Notes>
    <CVE>CVE-2024-27079</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_flow_offload: reset dst in route object after setting up flow

dst is transferred to the flow object, route object does not own it
anymore.  Reset dst in route object, otherwise if flow_offload_add()
fails, error path releases dst twice, leading to a refcount underflow.</Note>
    </Notes>
    <CVE>CVE-2024-27403</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline

The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of
interrupt affinity reconfiguration via procfs. Instead, the change is
deferred until the next instance of the interrupt being triggered on the
original CPU.

When the interrupt next triggers on the original CPU, the new affinity is
enforced within __irq_move_irq(). A vector is allocated from the new CPU,
but the old vector on the original CPU remains and is not immediately
reclaimed. Instead, apicd-&gt;move_in_progress is flagged, and the reclaiming
process is delayed until the next trigger of the interrupt on the new CPU.

Upon the subsequent triggering of the interrupt on the new CPU,
irq_complete_move() adds a task to the old CPU's vector_cleanup list if it
remains online. Subsequently, the timer on the old CPU iterates over its
vector_cleanup list, reclaiming old vectors.

However, a rare scenario arises if the old CPU is outgoing before the
interrupt triggers again on the new CPU.

In that case irq_force_complete_move() is not invoked on the outgoing CPU
to reclaim the old apicd-&gt;prev_vector because the interrupt isn't currently
affine to the outgoing CPU, and irq_needs_fixup() returns false. Even
though __vector_schedule_cleanup() is later called on the new CPU, it
doesn't reclaim apicd-&gt;prev_vector; instead, it simply resets both
apicd-&gt;move_in_progress and apicd-&gt;prev_vector to 0.

As a result, the vector remains unreclaimed in vector_matrix, leading to a
CPU vector leak.

To address this issue, move the invocation of irq_force_complete_move()
before the irq_needs_fixup() call to reclaim apicd-&gt;prev_vector, if the
interrupt is currently or used to be affine to the outgoing CPU.

Additionally, reclaim the vector in __vector_schedule_cleanup() as well,
following a warning message, although theoretically it should never see
apicd-&gt;move_in_progress with apicd-&gt;prev_cpu pointing to an offline CPU.</Note>
    </Notes>
    <CVE>CVE-2024-31076</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en"> REXML is an XML toolkit for Ruby. The REXML gem before 3.2.6 has a denial of service vulnerability when it parses an XML that has many `&lt;`s in an attribute value. Those who need to parse untrusted XMLs may be impacted to this vulnerability. The REXML gem 3.2.7 or later include the patch to fix this vulnerability. As a workaround, don't parse untrusted XMLs.</Note>
    </Notes>
    <CVE>CVE-2024-35176</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: discard table flag update with pending basechain deletion

Hook unregistration is deferred to the commit phase, same occurs with
hook updates triggered by the table dormant flag. When both commands are
combined, this results in deleting a basechain while leaving its hook
still registered in the core.</Note>
    </Notes>
    <CVE>CVE-2024-35897</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/rds: fix possible cp null dereference

cp might be null, calling cp-&gt;cp_conn would produce null dereference

[Simon Horman adds:]

Analysis:

* cp is a parameter of __rds_rdma_map and is not reassigned.

* The following call-sites pass a NULL cp argument to __rds_rdma_map()

  - rds_get_mr()
  - rds_get_mr_for_dest

* Prior to the code above, the following assumes that cp may be NULL
  (which is indicative, but could itself be unnecessary)

	trans_private = rs-&gt;rs_transport-&gt;get_mr(
		sg, nents, rs, &amp;mr-&gt;r_key, cp ? cp-&gt;cp_conn : NULL,
		args-&gt;vec.addr, args-&gt;vec.bytes,
		need_odp ? ODP_ZEROBASED : ODP_NOT_NEEDED);

* The code modified by this patch is guarded by IS_ERR(trans_private),
  where trans_private is assigned as per the previous point in this analysis.

  The only implementation of get_mr that I could locate is rds_ib_get_mr()
  which can return an ERR_PTR if the conn (4th) argument is NULL.

* ret is set to PTR_ERR(trans_private).
  rds_ib_get_mr can return ERR_PTR(-ENODEV) if the conn (4th) argument is NULL.
  Thus ret may be -ENODEV in which case the code in question will execute.

Conclusion:
* cp may be NULL at the point where this patch adds a check;
  this patch does seem to address a possible bug</Note>
    </Notes>
    <CVE>CVE-2024-35902</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: check A-MSDU format more carefully

If it looks like there's another subframe in the A-MSDU
but the header isn't fully there, we can end up reading
data out of bounds, only to discard later. Make this a
bit more careful and check if the subframe header can
even be present.</Note>
    </Notes>
    <CVE>CVE-2024-35937</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: phy_device: Prevent nullptr exceptions on ISR

If phydev-&gt;irq is set unconditionally, check
for valid interrupt handler or fall back to polling mode to prevent
nullptr exceptions in interrupt service routine.</Note>
    </Notes>
    <CVE>CVE-2024-35945</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ks8851: Handle softirqs at the end of IRQ thread to fix hang

The ks8851_irq() thread may call ks8851_rx_pkts() in case there are
any packets in the MAC FIFO, which calls netif_rx(). This netif_rx()
implementation is guarded by local_bh_disable() and local_bh_enable().
The local_bh_enable() may call do_softirq() to run softirqs in case
any are pending. One of the softirqs is net_rx_action, which ultimately
reaches the driver .start_xmit callback. If that happens, the system
hangs. The entire call chain is below:

ks8851_start_xmit_par from netdev_start_xmit
netdev_start_xmit from dev_hard_start_xmit
dev_hard_start_xmit from sch_direct_xmit
sch_direct_xmit from __dev_queue_xmit
__dev_queue_xmit from __neigh_update
__neigh_update from neigh_update
neigh_update from arp_process.constprop.0
arp_process.constprop.0 from __netif_receive_skb_one_core
__netif_receive_skb_one_core from process_backlog
process_backlog from __napi_poll.constprop.0
__napi_poll.constprop.0 from net_rx_action
net_rx_action from __do_softirq
__do_softirq from call_with_stack
call_with_stack from do_softirq
do_softirq from __local_bh_enable_ip
__local_bh_enable_ip from netif_rx
netif_rx from ks8851_irq
ks8851_irq from irq_thread_fn
irq_thread_fn from irq_thread
irq_thread from kthread
kthread from ret_from_fork

The hang happens because ks8851_irq() first locks a spinlock in
ks8851_par.c ks8851_lock_par() spin_lock_irqsave(&amp;ksp-&gt;lock, ...)
and with that spinlock locked, calls netif_rx(). Once the execution
reaches ks8851_start_xmit_par(), it calls ks8851_lock_par() again
which attempts to claim the already locked spinlock again, and the
hang happens.

Move the do_softirq() call outside of the spinlock protected section
of ks8851_irq() by disabling BHs around the entire spinlock protected
section of ks8851_irq() handler. Place local_bh_enable() outside of
the spinlock protected section, so that it can trigger do_softirq()
without the ks8851_par.c ks8851_lock_par() spinlock being held, and
safely call ks8851_start_xmit_par() without attempting to lock the
already locked spinlock.

Since ks8851_irq() is protected by local_bh_disable()/local_bh_enable()
now, replace netif_rx() with __netif_rx() which is not duplicating the
local_bh_disable()/local_bh_enable() calls.</Note>
    </Notes>
    <CVE>CVE-2024-35971</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 slab-use-after-free in l2cap_connect()

Extend a critical section to prevent chan from early freeing.
Also make the l2cap_connect() return type void. Nothing is using the
returned value but it is ugly to return a potentially freed pointer.
Making it void will help with backports because earlier kernels did use
the return value. Now the compile will break for kernels where this
patch is not a complete fix.

Call stack summary:

[use]
l2cap_bredr_sig_cmd
  l2cap_connect
    mutex_lock(&amp;conn-&gt;chan_lock);
  | chan = pchan-&gt;ops-&gt;new_connection(pchan); &lt;- alloc chan
  | __l2cap_chan_add(conn, chan);
  |   l2cap_chan_hold(chan);
  |   list_add(&amp;chan-&gt;list, &amp;conn-&gt;chan_l);   ... (1)
    mutex_unlock(&amp;conn-&gt;chan_lock);
    chan-&gt;conf_state              ... (4) &lt;- use after free

[free]
l2cap_conn_del
  mutex_lock(&amp;conn-&gt;chan_lock);
| foreach chan in conn-&gt;chan_l:            ... (2)
|   l2cap_chan_put(chan);
|     l2cap_chan_destroy
|       kfree(chan)               ... (3) &lt;- chan freed
  mutex_unlock(&amp;conn-&gt;chan_lock);

==================================================================
BUG: KASAN: slab-use-after-free in instrument_atomic_read
include/linux/instrumented.h:68 [inline]
BUG: KASAN: slab-use-after-free in _test_bit
include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
BUG: KASAN: slab-use-after-free in l2cap_connect+0xa67/0x11a0
net/bluetooth/l2cap_core.c:4260
Read of size 8 at addr ffff88810bf040a0 by task kworker/u3:1/311</Note>
    </Notes>
    <CVE>CVE-2024-36013</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: tproxy: bail out if IP has been disabled on the device

syzbot reports:
general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
[..]
RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62
Call Trace:
 nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline]
 nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168

__in_dev_get_rcu() can return NULL, so check for this.</Note>
    </Notes>
    <CVE>CVE-2024-36270</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()

syzbot reported that nf_reinject() could be called without rcu_read_lock() :

WARNING: suspicious RCU usage
6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted

net/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
2 locks held by syz-executor.4/13427:
  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline]
  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline]
  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471
  #1: ffff88801ca92958 (&amp;inst-&gt;lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
  #1: ffff88801ca92958 (&amp;inst-&gt;lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline]
  #1: ffff88801ca92958 (&amp;inst-&gt;lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172

stack backtrace:
CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
Call Trace:
 &lt;IRQ&gt;
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
  lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712
  nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline]
  nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397
  nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline]
  instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172
  rcu_do_batch kernel/rcu/tree.c:2196 [inline]
  rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471
  handle_softirqs+0x2d6/0x990 kernel/softirq.c:554
  __do_softirq kernel/softirq.c:588 [inline]
  invoke_softirq kernel/softirq.c:428 [inline]
  __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637
  irq_exit_rcu+0x9/0x30 kernel/softirq.c:649
  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]
  sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043
 &lt;/IRQ&gt;
 &lt;TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-36286</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tls: fix missing memory barrier in tls_init

In tls_init(), a write memory barrier is missing, and store-store
reordering may cause NULL dereference in tls_{setsockopt,getsockopt}.

CPU0                               CPU1
-----                              -----
// In tls_init()
// In tls_ctx_create()
ctx = kzalloc()
ctx-&gt;sk_proto = READ_ONCE(sk-&gt;sk_prot) -(1)

// In update_sk_prot()
WRITE_ONCE(sk-&gt;sk_prot, tls_prots)     -(2)

                                   // In sock_common_setsockopt()
                                   READ_ONCE(sk-&gt;sk_prot)-&gt;setsockopt()

                                   // In tls_{setsockopt,getsockopt}()
                                   ctx-&gt;sk_proto-&gt;setsockopt()    -(3)

In the above scenario, when (1) and (2) are reordered, (3) can observe
the NULL value of ctx-&gt;sk_proto, causing NULL dereference.

To fix it, we rely on rcu_assign_pointer() which implies the release
barrier semantic. By moving rcu_assign_pointer() after ctx-&gt;sk_proto is
initialized, we can ensure that ctx-&gt;sk_proto are visible when
changing sk-&gt;sk_prot.</Note>
    </Notes>
    <CVE>CVE-2024-36489</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nsh: Restore skb-&gt;{protocol,data,mac_header} for outer header in nsh_gso_segment().

syzbot triggered various splats (see [0] and links) by a crafted GSO
packet of VIRTIO_NET_HDR_GSO_UDP layering the following protocols:

  ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDP

NSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS.  As the inner
protocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), calls
skb_mac_gso_segment() to invoke inner protocol GSO handlers.

nsh_gso_segment() does the following for the original skb before
calling skb_mac_gso_segment()

  1. reset skb-&gt;network_header
  2. save the original skb-&gt;{mac_heaeder,mac_len} in a local variable
  3. pull the NSH header
  4. resets skb-&gt;mac_header
  5. set up skb-&gt;mac_len and skb-&gt;protocol for the inner protocol.

and does the following for the segmented skb

  6. set ntohs(ETH_P_NSH) to skb-&gt;protocol
  7. push the NSH header
  8. restore skb-&gt;mac_header
  9. set skb-&gt;mac_header + mac_len to skb-&gt;network_header
 10. restore skb-&gt;mac_len

There are two problems in 6-7 and 8-9.

  (a)
  After 6 &amp; 7, skb-&gt;data points to the NSH header, so the outer header
  (ETH_P_8021AD in this case) is stripped when skb is sent out of netdev.

  Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH),
  skb_pull() in the first nsh_gso_segment() will make skb-&gt;data point
  to the middle of the outer NSH or Ethernet header because the Ethernet
  header is not pulled by the second nsh_gso_segment().

  (b)
  While restoring skb-&gt;{mac_header,network_header} in 8 &amp; 9,
  nsh_gso_segment() does not assume that the data in the linear
  buffer is shifted.

  However, udp6_ufo_fragment() could shift the data and change
  skb-&gt;mac_header accordingly as demonstrated by syzbot.

  If this happens, even the restored skb-&gt;mac_header points to
  the middle of the outer header.

It seems nsh_gso_segment() has never worked with outer headers so far.

At the end of nsh_gso_segment(), the outer header must be restored for
the segmented skb, instead of the NSH header.

To do that, let's calculate the outer header position relatively from
the inner header and set skb-&gt;{data,mac_header,protocol} properly.

[0]:
BUG: KMSAN: uninit-value in ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]
BUG: KMSAN: uninit-value in ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]
BUG: KMSAN: uninit-value in ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668
 ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]
 ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]
 ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668
 ipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222
 __netdev_start_xmit include/linux/netdevice.h:4989 [inline]
 netdev_start_xmit include/linux/netdevice.h:5003 [inline]
 xmit_one net/core/dev.c:3547 [inline]
 dev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563
 __dev_queue_xmit+0x33ed/0x51c0 net/core/dev.c:4351
 dev_queue_xmit include/linux/netdevice.h:3171 [inline]
 packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276
 packet_snd net/packet/af_packet.c:3081 [inline]
 packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg net/socket.c:745 [inline]
 __sys_sendto+0x735/0xa10 net/socket.c:2191
 __do_sys_sendto net/socket.c:2203 [inline]
 __se_sys_sendto net/socket.c:2199 [inline]
 __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b

Uninit was created at:
 slab_post_alloc_hook mm/slub.c:3819 [inline]
 slab_alloc_node mm/slub.c:3860 [inline]
 __do_kmalloc_node mm/slub.c:3980 [inline]
 __kmalloc_node_track_caller+0x705/0x1000 mm/slub.c:4001
 kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582
 __
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-36933</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

efi/unaccepted: touch soft lockup during memory accept

Commit 50e782a86c98 ("efi/unaccepted: Fix soft lockups caused by
parallel memory acceptance") has released the spinlock so other CPUs can
do memory acceptance in parallel and not triggers softlockup on other
CPUs.

However the softlock up was intermittent shown up if the memory of the
TD guest is large, and the timeout of softlockup is set to 1 second:

 RIP: 0010:_raw_spin_unlock_irqrestore
 Call Trace:
 ? __hrtimer_run_queues
 &lt;IRQ&gt;
 ? hrtimer_interrupt
 ? watchdog_timer_fn
 ? __sysvec_apic_timer_interrupt
 ? __pfx_watchdog_timer_fn
 ? sysvec_apic_timer_interrupt
 &lt;/IRQ&gt;
 ? __hrtimer_run_queues
 &lt;TASK&gt;
 ? hrtimer_interrupt
 ? asm_sysvec_apic_timer_interrupt
 ? _raw_spin_unlock_irqrestore
 ? __sysvec_apic_timer_interrupt
 ? sysvec_apic_timer_interrupt
 accept_memory
 try_to_accept_memory
 do_huge_pmd_anonymous_page
 get_page_from_freelist
 __handle_mm_fault
 __alloc_pages
 __folio_alloc
 ? __tdx_hypercall
 handle_mm_fault
 vma_alloc_folio
 do_user_addr_fault
 do_huge_pmd_anonymous_page
 exc_page_fault
 ? __do_huge_pmd_anonymous_page
 asm_exc_page_fault
 __handle_mm_fault

When the local irq is enabled at the end of accept_memory(), the
softlockup detects that the watchdog on single CPU has not been fed for
a while. That is to say, even other CPUs will not be blocked by
spinlock, the current CPU might be stunk with local irq disabled for a
while, which hurts not only nmi watchdog but also softlockup.

Chao Gao pointed out that the memory accept could be time costly and
there was similar report before. Thus to avoid any softlocup detection
during this stage, give the softlockup a flag to skip the timeout check
at the end of accept_memory(), by invoking touch_softlockup_watchdog().</Note>
    </Notes>
    <CVE>CVE-2024-36936</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: vgic-v2: Check for non-NULL vCPU in vgic_v2_parse_attr()

vgic_v2_parse_attr() is responsible for finding the vCPU that matches
the user-provided CPUID, which (of course) may not be valid. If the ID
is invalid, kvm_get_vcpu_by_id() returns NULL, which isn't handled
gracefully.

Similar to the GICv3 uaccess flow, check that kvm_get_vcpu_by_id()
actually returns something and fail the ioctl if not.</Note>
    </Notes>
    <CVE>CVE-2024-36953</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

octeontx2-af: avoid off-by-one read from userspace

We try to access count + 1 byte from userspace with memdup_user(buffer,
count + 1). However, the userspace only provides buffer of count bytes and
only these count bytes are verified to be okay to access. To ensure the
copied buffer is NUL terminated, we use memdup_user_nul instead.</Note>
    </Notes>
    <CVE>CVE-2024-36957</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-37353</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: xmit: make sure we have at least eth header len bytes

syzbot triggered an uninit value[1] error in bridge device's xmit path
by sending a short (less than ETH_HLEN bytes) skb. To fix it check if
we can actually pull that amount instead of assuming.

Tested with dropwatch:
 drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3)
 origin: software
 timestamp: Mon May 13 11:31:53 2024 778214037 nsec
 protocol: 0x88a8
 length: 2
 original length: 2
 drop reason: PKT_TOO_SMALL

[1]
BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
 br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
 __netdev_start_xmit include/linux/netdevice.h:4903 [inline]
 netdev_start_xmit include/linux/netdevice.h:4917 [inline]
 xmit_one net/core/dev.c:3531 [inline]
 dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547
 __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341
 dev_queue_xmit include/linux/netdevice.h:3091 [inline]
 __bpf_tx_skb net/core/filter.c:2136 [inline]
 __bpf_redirect_common net/core/filter.c:2180 [inline]
 __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187
 ____bpf_clone_redirect net/core/filter.c:2460 [inline]
 bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432
 ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997
 __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238
 bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline]
 __bpf_prog_run include/linux/filter.h:657 [inline]
 bpf_prog_run include/linux/filter.h:664 [inline]
 bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425
 bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058
 bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269
 __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678
 __do_sys_bpf kernel/bpf/syscall.c:5767 [inline]
 __se_sys_bpf kernel/bpf/syscall.c:5765 [inline]
 __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765
 x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f</Note>
    </Notes>
    <CVE>CVE-2024-38538</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg

A data-race condition has been identified in af_unix. In one data path,
the write function unix_release_sock() atomically writes to
sk-&gt;sk_shutdown using WRITE_ONCE. However, on the reader side,
unix_stream_sendmsg() does not read it atomically. Consequently, this
issue is causing the following KCSAN splat to occur:

	BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg

	write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:
	unix_release_sock (net/unix/af_unix.c:640)
	unix_release (net/unix/af_unix.c:1050)
	sock_close (net/socket.c:659 net/socket.c:1421)
	__fput (fs/file_table.c:422)
	__fput_sync (fs/file_table.c:508)
	__se_sys_close (fs/open.c:1559 fs/open.c:1541)
	__x64_sys_close (fs/open.c:1541)
	x64_sys_call (arch/x86/entry/syscall_64.c:33)
	do_syscall_64 (arch/x86/entry/common.c:?)
	entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

	read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:
	unix_stream_sendmsg (net/unix/af_unix.c:2273)
	__sock_sendmsg (net/socket.c:730 net/socket.c:745)
	____sys_sendmsg (net/socket.c:2584)
	__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)
	__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)
	x64_sys_call (arch/x86/entry/syscall_64.c:33)
	do_syscall_64 (arch/x86/entry/common.c:?)
	entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

	value changed: 0x01 -&gt; 0x03

The line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7").

Commit e1d09c2c2f57 ("af_unix: Fix data races around sk-&gt;sk_shutdown.")
addressed a comparable issue in the past regarding sk-&gt;sk_shutdown.
However, it overlooked resolving this particular data path.
This patch only offending unix_stream_sendmsg() function, since the
other reads seem to be protected by unix_state_lock() as discussed in</Note>
    </Notes>
    <CVE>CVE-2024-38596</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: exit() callback is optional

The exit() callback is optional and shouldn't be called without checking
a valid pointer first.

Also, we must clear freq_table pointer even if the exit() callback isn't
present.</Note>
    </Notes>
    <CVE>CVE-2024-38615</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix potential memory leak in vfio_intx_enable()

If vfio_irq_ctx_alloc() failed will lead to 'name' memory leak.</Note>
    </Notes>
    <CVE>CVE-2024-38632</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Allow delete from sockmap/sockhash only if update is allowed

We have seen an influx of syzkaller reports where a BPF program attached to
a tracepoint triggers a locking rule violation by performing a map_delete
on a sockmap/sockhash.

We don't intend to support this artificial use scenario. Extend the
existing verifier allowed-program-type check for updating sockmap/sockhash
to also cover deleting from a map.

From now on only BPF programs which were previously allowed to update
sockmap/sockhash can delete from these map types.</Note>
    </Notes>
    <CVE>CVE-2024-38662</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING

Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with
small possibility, the root cause is exactly the same as commit
bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")

However, Dan reported another hang after that, and junxiao investigated
the problem and found out that this is caused by plugged bio can't issue
from raid5d().

Current implementation in raid5d() has a weird dependence:

1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear
   MD_SB_CHANGE_PENDING;
2) raid5d() handles IO in a deadloop, until all IO are issued;
3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;

This behaviour is introduce before v2.6, and for consequence, if other
context hold 'reconfig_mutex', and md_check_recovery() can't update
super_block, then raid5d() will waste one cpu 100% by the deadloop, until
'reconfig_mutex' is released.

Refer to the implementation from raid1 and raid10, fix this problem by
skipping issue IO if MD_SB_CHANGE_PENDING is still set after
md_check_recovery(), daemon thread will be woken up when 'reconfig_mutex'
is released. Meanwhile, the hang problem will be fixed as well.</Note>
    </Notes>
    <CVE>CVE-2024-39476</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sr: fix memleak in seg6_hmac_init_algo

seg6_hmac_init_algo returns without cleaning up the previous allocations
if one fails, so it's going to leak all that memory and the crypto tfms.

Update seg6_hmac_exit to only free the memory when allocated, so we can
reuse the code directly.</Note>
    </Notes>
    <CVE>CVE-2024-39489</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en"> REXML is an XML toolkit for Ruby. The REXML gem before 3.3.1 has some DoS vulnerabilities when it parses an XML that has many specific characters such as `&lt;`, `0` and `%&gt;`. If you need to parse untrusted XMLs, you many be impacted to these vulnerabilities. The REXML gem 3.3.2 or later include the patches to fix these vulnerabilities. Users are advised to upgrade. Users unable to upgrade should avoid parsing untrusted XML strings.</Note>
    </Notes>
    <CVE>CVE-2024-39908</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix possible race in __fib6_drop_pcpu_from()

syzbot found a race in __fib6_drop_pcpu_from() [1]

If compiler reads more than once (*ppcpu_rt),
second read could read NULL, if another cpu clears
the value in rt6_get_pcpu_route().

Add a READ_ONCE() to prevent this race.

Also add rcu_read_lock()/rcu_read_unlock() because
we rely on RCU protection while dereferencing pcpu_rt.

[1]

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]
CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
Workqueue: netns cleanup_net
 RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984
Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 &lt;80&gt; 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48
RSP: 0018:ffffc900040df070 EFLAGS: 00010206
RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16
RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091
RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007
R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8
R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001
FS:  0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
  __fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline]
  fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline]
  fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038
  fib6_del_route net/ipv6/ip6_fib.c:1998 [inline]
  fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043
  fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205
  fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127
  fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175
  fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255
  __fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271
  rt6_sync_down_dev net/ipv6/route.c:4906 [inline]
  rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911
  addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855
  addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778
  notifier_call_chain+0xb9/0x410 kernel/notifier.c:93
  call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992
  call_netdevice_notifiers_extack net/core/dev.c:2030 [inline]
  call_netdevice_notifiers net/core/dev.c:2044 [inline]
  dev_close_many+0x333/0x6a0 net/core/dev.c:1585
  unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193
  unregister_netdevice_many net/core/dev.c:11276 [inline]
  default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759
  ops_exit_list+0x128/0x180 net/core/net_namespace.c:178
  cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640
  process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231
  process_scheduled_works kernel/workqueue.c:3312 [inline]
  worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393
  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-40905</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ax25: Fix refcount imbalance on inbound connections

When releasing a socket in ax25_release(), we call netdev_put() to
decrease the refcount on the associated ax.25 device. However, the
execution path for accepting an incoming connection never calls
netdev_hold(). This imbalance leads to refcount errors, and ultimately
to kernel crashes.

A typical call trace for the above situation will start with one of the
following errors:

    refcount_t: decrement hit 0; leaking memory.
    refcount_t: underflow; use-after-free.

And will then have a trace like:

    Call Trace:
    &lt;TASK&gt;
    ? show_regs+0x64/0x70
    ? __warn+0x83/0x120
    ? refcount_warn_saturate+0xb2/0x100
    ? report_bug+0x158/0x190
    ? prb_read_valid+0x20/0x30
    ? handle_bug+0x3e/0x70
    ? exc_invalid_op+0x1c/0x70
    ? asm_exc_invalid_op+0x1f/0x30
    ? refcount_warn_saturate+0xb2/0x100
    ? refcount_warn_saturate+0xb2/0x100
    ax25_release+0x2ad/0x360
    __sock_release+0x35/0xa0
    sock_close+0x19/0x20
    [...]

On reboot (or any attempt to remove the interface), the kernel gets
stuck in an infinite loop:

    unregister_netdevice: waiting for ax0 to become free. Usage count = 0

This patch corrects these issues by ensuring that we call netdev_hold()
and ax25_dev_hold() for new connections in ax25_accept(). This makes the
logic leading to ax25_accept() match the logic for ax25_bind(): in both
cases we increment the refcount, which is ultimately decremented in
ax25_release().</Note>
    </Notes>
    <CVE>CVE-2024-40910</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

i2c: lpi2c: Avoid calling clk_get_rate during transfer

Instead of repeatedly calling clk_get_rate for each transfer, lock
the clock rate and cache the value.
A deadlock has been observed while adding tlv320aic32x4 audio codec to
the system. When this clock provider adds its clock, the clk mutex is
locked already, it needs to access i2c, which in return needs the mutex
for clk_get_rate as well.</Note>
    </Notes>
    <CVE>CVE-2024-40965</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mtk-vcodec: potential null pointer deference in SCP

The return value of devm_kzalloc() needs to be checked to avoid
NULL pointer deference. This is similar to CVE-2022-3113.</Note>
    </Notes>
    <CVE>CVE-2024-40973</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qedi: Fix crash while reading debugfs attribute

The qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly
on a __user pointer, which results into the crash.

To fix this issue, use a small local stack buffer for sprintf() and then
call simple_read_from_buffer(), which in turns make the copy_to_user()
call.

BUG: unable to handle page fault for address: 00007f4801111000
PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0
Oops: 0002 [#1] PREEMPT SMP PTI
Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023
RIP: 0010:memcpy_orig+0xcd/0x130
RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202
RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f
RDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000
RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572
R10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff
R13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af
FS:  00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 ? __die_body+0x1a/0x60
 ? page_fault_oops+0x183/0x510
 ? exc_page_fault+0x69/0x150
 ? asm_exc_page_fault+0x22/0x30
 ? memcpy_orig+0xcd/0x130
 vsnprintf+0x102/0x4c0
 sprintf+0x51/0x80
 qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324]
 full_proxy_read+0x50/0x80
 vfs_read+0xa5/0x2e0
 ? folio_add_new_anon_rmap+0x44/0xa0
 ? set_pte_at+0x15/0x30
 ? do_pte_missing+0x426/0x7f0
 ksys_read+0xa5/0xe0
 do_syscall_64+0x58/0x80
 ? __count_memcg_events+0x46/0x90
 ? count_memcg_event_mm+0x3d/0x60
 ? handle_mm_fault+0x196/0x2f0
 ? do_user_addr_fault+0x267/0x890
 ? exc_page_fault+0x69/0x150
 entry_SYSCALL_64_after_hwframe+0x72/0xdc
RIP: 0033:0x7f4800f20b4d</Note>
    </Notes>
    <CVE>CVE-2024-40978</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: force a dst refcount before doing decryption

As it says in commit 3bc07321ccc2 ("xfrm: Force a dst refcount before
entering the xfrm type handlers"):

"Crypto requests might return asynchronous. In this case we leave the
 rcu protected region, so force a refcount on the skb's destination
 entry before we enter the xfrm type input/output handlers."

On TIPC decryption path it has the same problem, and skb_dst_force()
should be called before doing decryption to avoid a possible crash.

Shuang reported this issue when this warning is triggered:

  [] WARNING: include/net/dst.h:337 tipc_sk_rcv+0x1055/0x1ea0 [tipc]
  [] Kdump: loaded Tainted: G W --------- - - 4.18.0-496.el8.x86_64+debug
  [] Workqueue: crypto cryptd_queue_worker
  [] RIP: 0010:tipc_sk_rcv+0x1055/0x1ea0 [tipc]
  [] Call Trace:
  [] tipc_sk_mcast_rcv+0x548/0xea0 [tipc]
  [] tipc_rcv+0xcf5/0x1060 [tipc]
  [] tipc_aead_decrypt_done+0x215/0x2e0 [tipc]
  [] cryptd_aead_crypt+0xdb/0x190
  [] cryptd_queue_worker+0xed/0x190
  [] process_one_work+0x93d/0x17e0</Note>
    </Notes>
    <CVE>CVE-2024-40983</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix memory leak on CPU EPP exit

The cpudata memory from kzalloc() in amd_pstate_epp_cpu_init() is
not freed in the analogous exit function, so fix that.

[ rjw: Subject and changelog edits ]</Note>
    </Notes>
    <CVE>CVE-2024-40997</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/ioctl: prefer different overflow check

Running syzkaller with the newly reintroduced signed integer overflow
sanitizer shows this report:

[   62.982337] ------------[ cut here ]------------
[   62.985692] cgroup: Invalid name
[   62.986211] UBSAN: signed-integer-overflow in ../block/ioctl.c:36:46
[   62.989370] 9pnet_fd: p9_fd_create_tcp (7343): problem connecting socket to 127.0.0.1
[   62.992992] 9223372036854775807 + 4095 cannot be represented in type 'long long'
[   62.997827] 9pnet_fd: p9_fd_create_tcp (7345): problem connecting socket to 127.0.0.1
[   62.999369] random: crng reseeded on system resumption
[   63.000634] GUP no longer grows the stack in syz-executor.2 (7353): 20002000-20003000 (20001000)
[   63.000668] CPU: 0 PID: 7353 Comm: syz-executor.2 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1
[   63.000677] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[   63.000682] Call Trace:
[   63.000686]  &lt;TASK&gt;
[   63.000731]  dump_stack_lvl+0x93/0xd0
[   63.000919]  __get_user_pages+0x903/0xd30
[   63.001030]  __gup_longterm_locked+0x153e/0x1ba0
[   63.001041]  ? _raw_read_unlock_irqrestore+0x17/0x50
[   63.001072]  ? try_get_folio+0x29c/0x2d0
[   63.001083]  internal_get_user_pages_fast+0x1119/0x1530
[   63.001109]  iov_iter_extract_pages+0x23b/0x580
[   63.001206]  bio_iov_iter_get_pages+0x4de/0x1220
[   63.001235]  iomap_dio_bio_iter+0x9b6/0x1410
[   63.001297]  __iomap_dio_rw+0xab4/0x1810
[   63.001316]  iomap_dio_rw+0x45/0xa0
[   63.001328]  ext4_file_write_iter+0xdde/0x1390
[   63.001372]  vfs_write+0x599/0xbd0
[   63.001394]  ksys_write+0xc8/0x190
[   63.001403]  do_syscall_64+0xd4/0x1b0
[   63.001421]  ? arch_exit_to_user_mode_prepare+0x3a/0x60
[   63.001479]  entry_SYSCALL_64_after_hwframe+0x6f/0x77
[   63.001535] RIP: 0033:0x7f7fd3ebf539
[   63.001551] Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 14 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
[   63.001562] RSP: 002b:00007f7fd32570c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[   63.001584] RAX: ffffffffffffffda RBX: 00007f7fd3ff3f80 RCX: 00007f7fd3ebf539
[   63.001590] RDX: 4db6d1e4f7e43360 RSI: 0000000020000000 RDI: 0000000000000004
[   63.001595] RBP: 00007f7fd3f1e496 R08: 0000000000000000 R09: 0000000000000000
[   63.001599] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[   63.001604] R13: 0000000000000006 R14: 00007f7fd3ff3f80 R15: 00007ffd415ad2b8
...
[   63.018142] ---[ end trace ]---

Historically, the signed integer overflow sanitizer did not work in the
kernel due to its interaction with `-fwrapv` but this has since been
changed [1] in the newest version of Clang; It was re-enabled in the
kernel with Commit 557f8c582a9ba8ab ("ubsan: Reintroduce signed overflow
sanitizer").

Let's rework this overflow checking logic to not actually perform an
overflow during the check itself, thus avoiding the UBSAN splat.

[1]: https://github.com/llvm/llvm-project/pull/82432</Note>
    </Notes>
    <CVE>CVE-2024-41000</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: avoid too many retransmit packets

If a TCP socket is using TCP_USER_TIMEOUT, and the other peer
retracted its window to zero, tcp_retransmit_timer() can
retransmit a packet every two jiffies (2 ms for HZ=1000),
for about 4 minutes after TCP_USER_TIMEOUT has 'expired'.

The fix is to make sure tcp_rtx_probe0_timed_out() takes
icsk-&gt;icsk_user_timeout into account.

Before blamed commit, the socket would not timeout after
icsk-&gt;icsk_user_timeout, but would use standard exponential
backoff for the retransmits.

Also worth noting that before commit e89688e3e978 ("net: tcp:
fix unexcepted socket die when snd_wnd is 0"), the issue
would last 2 minutes instead of 4.</Note>
    </Notes>
    <CVE>CVE-2024-41007</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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/amdkfd: don't allow mapping the MMIO HDP page with large pages

We don't get the right offset in that case.  The GPU has
an unused 4K area of the register BAR space into which you can
remap registers.  We remap the HDP flush registers into this
space to allow userspace (CPU or GPU) to flush the HDP when it
updates VRAM.  However, on systems with &gt;4K pages, we end up
exposing PAGE_SIZE of MMIO space.</Note>
    </Notes>
    <CVE>CVE-2024-41011</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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: 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

filelock: Fix fcntl/close race recovery compat path

When I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when
fcntl/close race is detected"), I missed that there are two copies of the
code I was patching: The normal version, and the version for 64-bit offsets
on 32-bit kernels.
Thanks to Greg KH for stumbling over this while doing the stable
backport...

Apply exactly the same fix to the compat path for 32-bit kernels.</Note>
    </Notes>
    <CVE>CVE-2024-41020</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 signedness bug in sdma_v4_0_process_trap_irq()

The "instance" variable needs to be signed for the error handling to work.</Note>
    </Notes>
    <CVE>CVE-2024-41022</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor

Syzbot has identified a bug in usbcore (see the Closes: tag below)
caused by our assumption that the reserved bits in an endpoint
descriptor's bEndpointAddress field will always be 0.  As a result of
the bug, the endpoint_is_duplicate() routine in config.c (and possibly
other routines as well) may believe that two descriptors are for
distinct endpoints, even though they have the same direction and
endpoint number.  This can lead to confusion, including the bug
identified by syzbot (two descriptors with matching endpoint numbers
and directions, where one was interrupt and the other was bulk).

To fix the bug, we will clear the reserved bits in bEndpointAddress
when we parse the descriptor.  (Note that both the USB-2.0 and USB-3.1
specs say these bits are "Reserved, reset to zero".)  This requires us
to make a copy of the descriptor earlier in usb_parse_endpoint() and
use the copy instead of the original when checking for duplicates.</Note>
    </Notes>
    <CVE>CVE-2024-41035</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ks8851: Fix deadlock with the SPI chip variant

When SMP is enabled and spinlocks are actually functional then there is
a deadlock with the 'statelock' spinlock between ks8851_start_xmit_spi
and ks8851_irq:

    watchdog: BUG: soft lockup - CPU#0 stuck for 27s!
    call trace:
      queued_spin_lock_slowpath+0x100/0x284
      do_raw_spin_lock+0x34/0x44
      ks8851_start_xmit_spi+0x30/0xb8
      ks8851_start_xmit+0x14/0x20
      netdev_start_xmit+0x40/0x6c
      dev_hard_start_xmit+0x6c/0xbc
      sch_direct_xmit+0xa4/0x22c
      __qdisc_run+0x138/0x3fc
      qdisc_run+0x24/0x3c
      net_tx_action+0xf8/0x130
      handle_softirqs+0x1ac/0x1f0
      __do_softirq+0x14/0x20
      ____do_softirq+0x10/0x1c
      call_on_irq_stack+0x3c/0x58
      do_softirq_own_stack+0x1c/0x28
      __irq_exit_rcu+0x54/0x9c
      irq_exit_rcu+0x10/0x1c
      el1_interrupt+0x38/0x50
      el1h_64_irq_handler+0x18/0x24
      el1h_64_irq+0x64/0x68
      __netif_schedule+0x6c/0x80
      netif_tx_wake_queue+0x38/0x48
      ks8851_irq+0xb8/0x2c8
      irq_thread_fn+0x2c/0x74
      irq_thread+0x10c/0x1b0
      kthread+0xc8/0xd8
      ret_from_fork+0x10/0x20

This issue has not been identified earlier because tests were done on
a device with SMP disabled and so spinlocks were actually NOPs.

Now use spin_(un)lock_bh for TX queue related locking to avoid execution
of softirq work synchronously that would lead to a deadlock.</Note>
    </Notes>
    <CVE>CVE-2024-41036</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: cs_dsp: Prevent buffer overrun when processing V2 alg headers

Check that all fields of a V2 algorithm header fit into the available
firmware data buffer.

The wmfw V2 format introduced variable-length strings in the algorithm
block header. This means the overall header length is variable, and the
position of most fields varies depending on the length of the string
fields. Each field must be checked to ensure that it does not overflow
the firmware data buffer.

As this ia bugfix patch, the fixes avoid making any significant change to
the existing code. This makes it easier to review and less likely to
introduce new bugs.</Note>
    </Notes>
    <CVE>CVE-2024-41038</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: cs_dsp: Fix overflow checking of wmfw header

Fix the checking that firmware file buffer is large enough for the
wmfw header, to prevent overrunning the buffer.

The original code tested that the firmware data buffer contained
enough bytes for the sums of the size of the structs

	wmfw_header + wmfw_adsp1_sizes + wmfw_footer

But wmfw_adsp1_sizes is only used on ADSP1 firmware. For ADSP2 and
Halo Core the equivalent struct is wmfw_adsp2_sizes, which is
4 bytes longer. So the length check didn't guarantee that there
are enough bytes in the firmware buffer for a header with
wmfw_adsp2_sizes.

This patch splits the length check into three separate parts. Each
of the wmfw_header, wmfw_adsp?_sizes and wmfw_footer are checked
separately before they are used.</Note>
    </Notes>
    <CVE>CVE-2024-41039</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Defer work in bpf_timer_cancel_and_free

Currently, the same case as previous patch (two timer callbacks trying
to cancel each other) can be invoked through bpf_map_update_elem as
well, or more precisely, freeing map elements containing timers. Since
this relies on hrtimer_cancel as well, it is prone to the same deadlock
situation as the previous patch.

It would be sufficient to use hrtimer_try_to_cancel to fix this problem,
as the timer cannot be enqueued after async_cancel_and_free. Once
async_cancel_and_free has been done, the timer must be reinitialized
before it can be armed again. The callback running in parallel trying to
arm the timer will fail, and freeing bpf_hrtimer without waiting is
sufficient (given kfree_rcu), and bpf_timer_cb will return
HRTIMER_NORESTART, preventing the timer from being rearmed again.

However, there exists a UAF scenario where the callback arms the timer
before entering this function, such that if cancellation fails (due to
timer callback invoking this routine, or the target timer callback
running concurrently). In such a case, if the timer expiration is
significantly far in the future, the RCU grace period expiration
happening before it will free the bpf_hrtimer state and along with it
the struct hrtimer, that is enqueued.

Hence, it is clear cancellation needs to occur after
async_cancel_and_free, and yet it cannot be done inline due to deadlock
issues. We thus modify bpf_timer_cancel_and_free to defer work to the
global workqueue, adding a work_struct alongside rcu_head (both used at
_different_ points of time, so can share space).

Update existing code comments to reflect the new state of affairs.</Note>
    </Notes>
    <CVE>CVE-2024-41045</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

filelock: fix potential use-after-free in posix_lock_inode

Light Hsieh reported a KASAN UAF warning in trace_posix_lock_inode().
The request pointer had been changed earlier to point to a lock entry
that was added to the inode's list. However, before the tracepoint could
fire, another task raced in and freed that lock.

Fix this by moving the tracepoint inside the spinlock, which should
ensure that this doesn't happen.</Note>
    </Notes>
    <CVE>CVE-2024-41049</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: cs_dsp: Use strnlen() on name fields in V1 wmfw files

Use strnlen() instead of strlen() on the algorithm and coefficient name
string arrays in V1 wmfw files.

In V1 wmfw files the name is a NUL-terminated string in a fixed-size
array. cs_dsp should protect against overrunning the array if the NUL
terminator is missing.</Note>
    </Notes>
    <CVE>CVE-2024-41056</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: check bo_va-&gt;bo is non-NULL before using it

The call to radeon_vm_clear_freed might clear bo_va-&gt;bo, so
we have to check it before dereferencing it.</Note>
    </Notes>
    <CVE>CVE-2024-41060</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sync sock recv cb and release

The problem occurs between the system call to close the sock and hci_rx_work,
where the former releases the sock and the latter accesses it without lock protection.

           CPU0                       CPU1
           ----                       ----
           sock_close                 hci_rx_work
	   l2cap_sock_release         hci_acldata_packet
	   l2cap_sock_kill            l2cap_recv_frame
	   sk_free                    l2cap_conless_channel
	                              l2cap_sock_recv_cb

If hci_rx_work processes the data that needs to be received before the sock is
closed, then everything is normal; Otherwise, the work thread may access the
released sock when receiving data.

Add a chan mutex in the rx callback of the sock to achieve synchronization between
the sock release and recv cb.

Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer.</Note>
    </Notes>
    <CVE>CVE-2024-41062</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

powerpc/pseries: Whitelist dtl slub object for copying to userspace

Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*
results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as
shown below.

    kernel BUG at mm/usercopy.c:102!
    Oops: Exception in kernel mode, sig: 5 [#1]
    LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
    Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc
    scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse
    CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85
    Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries
    NIP:  c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8
    REGS: c000000120c078c0 TRAP: 0700   Not tainted  (6.10.0-rc3)
    MSR:  8000000000029033 &lt;SF,EE,ME,IR,DR,RI,LE&gt;  CR: 2828220f  XER: 0000000e
    CFAR: c0000000001fdc80 IRQMASK: 0
    [ ... GPRs omitted ... ]
    NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0
    LR [c0000000005d23d0] usercopy_abort+0x74/0xb0
    Call Trace:
     usercopy_abort+0x74/0xb0 (unreliable)
     __check_heap_object+0xf8/0x120
     check_heap_object+0x218/0x240
     __check_object_size+0x84/0x1a4
     dtl_file_read+0x17c/0x2c4
     full_proxy_read+0x8c/0x110
     vfs_read+0xdc/0x3a0
     ksys_read+0x84/0x144
     system_call_exception+0x124/0x330
     system_call_vectored_common+0x15c/0x2ec
    --- interrupt: 3000 at 0x7fff81f3ab34

Commit 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0")
requires that only whitelisted areas in slab/slub objects can be copied to
userspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY.
Dtl contains hypervisor dispatch events which are expected to be read by
privileged users. Hence mark this safe for user access.
Specify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist the
entire object.</Note>
    </Notes>
    <CVE>CVE-2024-41065</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/sclp: Fix sclp_init() cleanup on failure

If sclp_init() fails it only partially cleans up: if there are multiple
failing calls to sclp_init() sclp_state_change_event will be added several
times to sclp_reg_list, which results in the following warning:

------------[ cut here ]------------
list_add double add: new=000003ffe1598c10, prev=000003ffe1598bf0, next=000003ffe1598c10.
WARNING: CPU: 0 PID: 1 at lib/list_debug.c:35 __list_add_valid_or_report+0xde/0xf8
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3
Krnl PSW : 0404c00180000000 000003ffe0d6076a (__list_add_valid_or_report+0xe2/0xf8)
           R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
...
Call Trace:
 [&lt;000003ffe0d6076a&gt;] __list_add_valid_or_report+0xe2/0xf8
([&lt;000003ffe0d60766&gt;] __list_add_valid_or_report+0xde/0xf8)
 [&lt;000003ffe0a8d37e&gt;] sclp_init+0x40e/0x450
 [&lt;000003ffe00009f2&gt;] do_one_initcall+0x42/0x1e0
 [&lt;000003ffe15b77a6&gt;] do_initcalls+0x126/0x150
 [&lt;000003ffe15b7a0a&gt;] kernel_init_freeable+0x1ba/0x1f8
 [&lt;000003ffe0d6650e&gt;] kernel_init+0x2e/0x180
 [&lt;000003ffe000301c&gt;] __ret_from_fork+0x3c/0x60
 [&lt;000003ffe0d759ca&gt;] ret_from_fork+0xa/0x30

Fix this by removing sclp_state_change_event from sclp_reg_list when
sclp_init() fails.</Note>
    </Notes>
    <CVE>CVE-2024-41068</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: avoid double free special payload

If a discard request needs to be retried, and that retry may fail before
a new special payload is added, a double free will result. Clear the
RQF_SPECIAL_LOAD when the request is cleaned.</Note>
    </Notes>
    <CVE>CVE-2024-41073</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: always initialize cqe.result

The spec doesn't mandate that the first two double words (aka results)
for the command queue entry need to be set to 0 when they are not
used (not specified). Though, the target implemention returns 0 for TCP
and FC but not for RDMA.

Let's make RDMA behave the same and thus explicitly initializing the
result field. This prevents leaking any data from the stack.</Note>
    </Notes>
    <CVE>CVE-2024-41079</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix possible deadlock in io_register_iowq_max_workers()

The io_register_iowq_max_workers() function calls io_put_sq_data(),
which acquires the sqd-&gt;lock without releasing the uring_lock.
Similar to the commit 009ad9f0c6ee ("io_uring: drop ctx-&gt;uring_lock
before acquiring sqd-&gt;lock"), this can lead to a potential deadlock
situation.

To resolve this issue, the uring_lock is released before calling
io_put_sq_data(), and then it is re-acquired after the function call.

This change ensures that the locks are acquired in the correct
order, preventing the possibility of a deadlock.</Note>
    </Notes>
    <CVE>CVE-2024-41080</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: use reserved tag for reg read/write command

In some scenarios, if too many commands are issued by nvme command in
the same time by user tasks, this may exhaust all tags of admin_q. If
a reset (nvme reset or IO timeout) occurs before these commands finish,
reconnect routine may fail to update nvme regs due to insufficient tags,
which will cause kernel hang forever. In order to workaround this issue,
maybe we can let reg_read32()/reg_read64()/reg_write32() use reserved
tags. This maybe safe for nvmf:

1. For the disable ctrl path,  we will not issue connect command
2. For the enable ctrl / fw activate path, since connect and reg_xx()
   are called serially.

So the reserved tags may still be enough while reg_xx() use reserved tags.</Note>
    </Notes>
    <CVE>CVE-2024-41082</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ata: libata-core: Fix double free on error

If e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump
to the err_out label, which will call devres_release_group().
devres_release_group() will trigger a call to ata_host_release().
ata_host_release() calls kfree(host), so executing the kfree(host) in
ata_host_alloc() will lead to a double free:

kernel BUG at mm/slub.c:553!
Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:kfree+0x2cf/0x2f0
Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da
RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246
RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320
RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0
RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000
R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780
R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006
FS:  00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 ? __die_body.cold+0x19/0x27
 ? die+0x2e/0x50
 ? do_trap+0xca/0x110
 ? do_error_trap+0x6a/0x90
 ? kfree+0x2cf/0x2f0
 ? exc_invalid_op+0x50/0x70
 ? kfree+0x2cf/0x2f0
 ? asm_exc_invalid_op+0x1a/0x20
 ? ata_host_alloc+0xf5/0x120 [libata]
 ? ata_host_alloc+0xf5/0x120 [libata]
 ? kfree+0x2cf/0x2f0
 ata_host_alloc+0xf5/0x120 [libata]
 ata_host_alloc_pinfo+0x14/0xa0 [libata]
 ahci_init_one+0x6c9/0xd20 [ahci]

Ensure that we will not call kfree(host) twice, by performing the kfree()
only if the devres_open_group() call failed.</Note>
    </Notes>
    <CVE>CVE-2024-41087</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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: mcp251xfd: fix infinite loop when xmit fails

When the mcp251xfd_start_xmit() function fails, the driver stops
processing messages, and the interrupt routine does not return,
running indefinitely even after killing the running application.

Error messages:
[  441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16
[  441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3).
... and repeat forever.

The issue can be triggered when multiple devices share the same SPI
interface. And there is concurrent access to the bus.

The problem occurs because tx_ring-&gt;head increments even if
mcp251xfd_start_xmit() fails. Consequently, the driver skips one TX
package while still expecting a response in
mcp251xfd_handle_tefif_one().

Resolve the issue by starting a workqueue to write the tx obj
synchronously if err = -EBUSY. In case of another error, decrement
tx_ring-&gt;head, remove skb from the echo stack, and drop the message.

[mkl: use more imperative wording in patch description]</Note>
    </Notes>
    <CVE>CVE-2024-41088</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes

In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is
assigned to mode, which will lead to a possible NULL pointer dereference
on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode().
Add a check to avoid null pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2024-41089</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/gt: Fix potential UAF by revoke of fence registers

CI has been sporadically reporting the following issue triggered by
igt@i915_selftest@live@hangcheck on ADL-P and similar machines:

&lt;6&gt; [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence
...
&lt;6&gt; [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled
&lt;6&gt; [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled
&lt;3&gt; [414.070354] Unable to pin Y-tiled fence; err:-4
&lt;3&gt; [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&amp;fence-&gt;active))
...
&lt;4&gt;[  609.603992] ------------[ cut here ]------------
&lt;2&gt;[  609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301!
&lt;4&gt;[  609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
&lt;4&gt;[  609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G     U  W          6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1
&lt;4&gt;[  609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023
&lt;4&gt;[  609.604010] Workqueue: i915 __i915_gem_free_work [i915]
&lt;4&gt;[  609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915]
...
&lt;4&gt;[  609.604271] Call Trace:
&lt;4&gt;[  609.604273]  &lt;TASK&gt;
...
&lt;4&gt;[  609.604716]  __i915_vma_evict+0x2e9/0x550 [i915]
&lt;4&gt;[  609.604852]  __i915_vma_unbind+0x7c/0x160 [i915]
&lt;4&gt;[  609.604977]  force_unbind+0x24/0xa0 [i915]
&lt;4&gt;[  609.605098]  i915_vma_destroy+0x2f/0xa0 [i915]
&lt;4&gt;[  609.605210]  __i915_gem_object_pages_fini+0x51/0x2f0 [i915]
&lt;4&gt;[  609.605330]  __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915]
&lt;4&gt;[  609.605440]  process_scheduled_works+0x351/0x690
...

In the past, there were similar failures reported by CI from other IGT
tests, observed on other platforms.

Before commit 63baf4f3d587 ("drm/i915/gt: Only wait for GPU activity
before unbinding a GGTT fence"), i915_vma_revoke_fence() was waiting for
idleness of vma-&gt;active via fence_update().   That commit introduced
vma-&gt;fence-&gt;active in order for the fence_update() to be able to wait
selectively on that one instead of vma-&gt;active since only idleness of
fence registers was needed.  But then, another commit 0d86ee35097a
("drm/i915/gt: Make fence revocation unequivocal") replaced the call to
fence_update() in i915_vma_revoke_fence() with only fence_write(), and
also added that GEM_BUG_ON(!i915_active_is_idle(&amp;fence-&gt;active)) in front.
No justification was provided on why we might then expect idleness of
vma-&gt;fence-&gt;active without first waiting on it.

The issue can be potentially caused by a race among revocation of fence
registers on one side and sequential execution of signal callbacks invoked
on completion of a request that was using them on the other, still
processed in parallel to revocation of those fence registers.  Fix it by
waiting for idleness of vma-&gt;fence-&gt;active in i915_vma_revoke_fence().

(cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)</Note>
    </Notes>
    <CVE>CVE-2024-41092</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: avoid using null object of framebuffer

Instead of using state-&gt;fb-&gt;obj[0] directly, get object from framebuffer
by calling drm_gem_fb_get_obj() and return error code when object is
null to avoid using null object of framebuffer.</Note>
    </Notes>
    <CVE>CVE-2024-41093</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes

In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is
assigned to mode, which will lead to a possible NULL pointer dereference
on failure of drm_mode_duplicate(). Add a check to avoid npd.</Note>
    </Notes>
    <CVE>CVE-2024-41095</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: atm: cxacru: fix endpoint checking in cxacru_bind()

Syzbot is still reporting quite an old issue [1] that occurs due to
incomplete checking of present usb endpoints. As such, wrong
endpoints types may be used at urb sumbitting stage which in turn
triggers a warning in usb_submit_urb().

Fix the issue by verifying that required endpoint types are present
for both in and out endpoints, taking into account cmd endpoint type.

Unfortunately, this patch has not been tested on real hardware.

[1] Syzbot report:
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
Modules linked in:
CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: usb_hub_wq hub_event
RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
...
Call Trace:
 cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649
 cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760
 cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209
 usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055
 cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363
 usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396
 call_driver_probe drivers/base/dd.c:517 [inline]
 really_probe+0x23c/0xcd0 drivers/base/dd.c:595
 __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747
 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777
 __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894
 bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427
 __device_attach+0x228/0x4a0 drivers/base/dd.c:965
 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487
 device_add+0xc2f/0x2180 drivers/base/core.c:3354
 usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170
 usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238
 usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293</Note>
    </Notes>
    <CVE>CVE-2024-41097</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ata: libata-core: Fix null pointer dereference on error

If the ata_port_alloc() call in ata_host_alloc() fails,
ata_host_release() will get called.

However, the code in ata_host_release() tries to free ata_port struct
members unconditionally, which can lead to the following:

BUG: unable to handle page fault for address: 0000000000003990
PGD 0 P4D 0
Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:ata_host_release.cold+0x2f/0x6e [libata]
Code: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41
RSP: 0018:ffffc90000ebb968 EFLAGS: 00010246
RAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0
RBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68
R10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004
R13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006
FS:  00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 ? __die_body.cold+0x19/0x27
 ? page_fault_oops+0x15a/0x2f0
 ? exc_page_fault+0x7e/0x180
 ? asm_exc_page_fault+0x26/0x30
 ? ata_host_release.cold+0x2f/0x6e [libata]
 ? ata_host_release.cold+0x2f/0x6e [libata]
 release_nodes+0x35/0xb0
 devres_release_group+0x113/0x140
 ata_host_alloc+0xed/0x120 [libata]
 ata_host_alloc_pinfo+0x14/0xa0 [libata]
 ahci_init_one+0x6c9/0xd20 [ahci]

Do not access ata_port struct members unconditionally.</Note>
    </Notes>
    <CVE>CVE-2024-41098</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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"/>
    </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">REXML is an XML toolkit for Ruby. The REXML gem before 3.3.2 has some DoS vulnerabilities when it parses an XML that has many specific characters such as whitespace character, `&gt;]` and `]&gt;`. The REXML gem 3.3.3 or later include the patches to fix these vulnerabilities.</Note>
    </Notes>
    <CVE>CVE-2024-41123</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">REXML is an XML toolkit for Ruby. The REXML gem 3.3.2 has a DoS vulnerability when it parses an XML that has many entity expansions with SAX2 or pull parser API. The REXML gem 3.3.3 or later include the patch to fix the vulnerability.</Note>
    </Notes>
    <CVE>CVE-2024-41946</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mana: Fix possible double free in error handling path

When auxiliary_device_add() returns error and then calls
auxiliary_device_uninit(), callback function adev_release
calls kfree(madev). We shouldn't call kfree(madev) again
in the error handling path. Set 'madev' to NULL.</Note>
    </Notes>
    <CVE>CVE-2024-42069</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: amd: acp: add a null check for chip_pdev structure

When acp platform device creation is skipped, chip-&gt;chip_pdev value will
remain NULL. Add NULL check for chip-&gt;chip_pdev structure in
snd_acp_resume() function to avoid null pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2024-42074</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: can: j1939: Initialize unused data in j1939_send_one()

syzbot reported kernel-infoleak in raw_recvmsg() [1]. j1939_send_one()
creates full frame including unused data, but it doesn't initialize
it. This causes the kernel-infoleak issue. Fix this by initializing
unused data.

[1]
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]
BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]
BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
 instrument_copy_to_user include/linux/instrumented.h:114 [inline]
 copy_to_user_iter lib/iov_iter.c:24 [inline]
 iterate_ubuf include/linux/iov_iter.h:29 [inline]
 iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
 iterate_and_advance include/linux/iov_iter.h:271 [inline]
 _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
 copy_to_iter include/linux/uio.h:196 [inline]
 memcpy_to_msg include/linux/skbuff.h:4113 [inline]
 raw_recvmsg+0x2b8/0x9e0 net/can/raw.c:1008
 sock_recvmsg_nosec net/socket.c:1046 [inline]
 sock_recvmsg+0x2c4/0x340 net/socket.c:1068
 ____sys_recvmsg+0x18a/0x620 net/socket.c:2803
 ___sys_recvmsg+0x223/0x840 net/socket.c:2845
 do_recvmmsg+0x4fc/0xfd0 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+0x397/0x490 net/socket.c:3034
 x64_sys_call+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:300
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xcf/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: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:1313 [inline]
 alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504
 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795
 sock_alloc_send_skb include/net/sock.h:1842 [inline]
 j1939_sk_alloc_skb net/can/j1939/socket.c:878 [inline]
 j1939_sk_send_loop net/can/j1939/socket.c:1142 [inline]
 j1939_sk_sendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg+0x30f/0x380 net/socket.c:745
 ____sys_sendmsg+0x877/0xb60 net/socket.c:2584
 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
 __sys_sendmsg net/socket.c:2667 [inline]
 __do_sys_sendmsg net/socket.c:2676 [inline]
 __se_sys_sendmsg net/socket.c:2674 [inline]
 __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674
 x64_sys_call+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:47
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Bytes 12-15 of 16 are uninitialized
Memory access of size 16 starts at ffff888120969690
Data copied to user address 00000000200017c0

CPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024</Note>
    </Notes>
    <CVE>CVE-2024-42076</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 DIO failure due to insufficient transaction credits

The code in ocfs2_dio_end_io_write() estimates number of necessary
transaction credits using ocfs2_calc_extend_credits().  This however does
not take into account that the IO could be arbitrarily large and can
contain arbitrary number of extents.

Extent tree manipulations do often extend the current transaction but not
in all of the cases.  For example if we have only single block extents in
the tree, ocfs2_mark_extent_written() will end up calling
ocfs2_replace_extent_rec() all the time and we will never extend the
current transaction and eventually exhaust all the transaction credits if
the IO contains many single block extents.  Once that happens a
WARN_ON(jbd2_handle_buffer_credits(handle) &lt;= 0) is triggered in
jbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to
this error.  This was actually triggered by one of our customers on a
heavily fragmented OCFS2 filesystem.

To fix the issue make sure the transaction always has enough credits for
one extent insert before each call of ocfs2_mark_extent_written().

Heming Zhao said:

------
PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error"

PID: xxx  TASK: xxxx  CPU: 5  COMMAND: "SubmitThread-CA"
  #0 machine_kexec at ffffffff8c069932
  #1 __crash_kexec at ffffffff8c1338fa
  #2 panic at ffffffff8c1d69b9
  #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2]
  #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2]
  #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2]
  #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2]
  #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2]
  #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2]
  #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2]
#10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2]
#11 dio_complete at ffffffff8c2b9fa7
#12 do_blockdev_direct_IO at ffffffff8c2bc09f
#13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2]
#14 generic_file_direct_write at ffffffff8c1dcf14
#15 __generic_file_write_iter at ffffffff8c1dd07b
#16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2]
#17 aio_write at ffffffff8c2cc72e
#18 kmem_cache_alloc at ffffffff8c248dde
#19 do_io_submit at ffffffff8c2ccada
#20 do_syscall_64 at ffffffff8c004984
#21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba</Note>
    </Notes>
    <CVE>CVE-2024-42077</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/restrack: Fix potential invalid address access

struct rdma_restrack_entry's kern_name was set to KBUILD_MODNAME
in ib_create_cq(), while if the module exited but forgot del this
rdma_restrack_entry, it would cause a invalid address access in
rdma_restrack_clean() when print the owner of this rdma_restrack_entry.

These code is used to help find one forgotten PD release in one of the
ULPs. But it is not needed anymore, so delete them.</Note>
    </Notes>
    <CVE>CVE-2024-42080</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xdp: Remove WARN() from __xdp_reg_mem_model()

syzkaller reports a warning in __xdp_reg_mem_model().

The warning occurs only if __mem_id_init_hash_table() returns an error. It
returns the error in two cases:

  1. memory allocation fails;
  2. rhashtable_init() fails when some fields of rhashtable_params
     struct are not initialized properly.

The second case cannot happen since there is a static const rhashtable_params
struct with valid fields. So, warning is only triggered when there is a
problem with memory allocation.

Thus, there is no sense in using WARN() to handle this error and it can be
safely removed.

WARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299

CPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
RIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299

Call Trace:
 xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344
 xdp_test_run_setup net/bpf/test_run.c:188 [inline]
 bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377
 bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267
 bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240
 __sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649
 __do_sys_bpf kernel/bpf/syscall.c:5738 [inline]
 __se_sys_bpf kernel/bpf/syscall.c:5736 [inline]
 __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736
 do_syscall_64+0xfb/0x240
 entry_SYSCALL_64_after_hwframe+0x6d/0x75

Found by Linux Verification Center (linuxtesting.org) with syzkaller.</Note>
    </Notes>
    <CVE>CVE-2024-42082</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: dwc3: core: remove lock of otg mode during gadget suspend/resume to avoid deadlock

When config CONFIG_USB_DWC3_DUAL_ROLE is selected, and trigger system
to enter suspend status with below command:
echo mem &gt; /sys/power/state
There will be a deadlock issue occurring. Detailed invoking path as
below:
dwc3_suspend_common()
    spin_lock_irqsave(&amp;dwc-&gt;lock, flags);              &lt;-- 1st
    dwc3_gadget_suspend(dwc);
        dwc3_gadget_soft_disconnect(dwc);
            spin_lock_irqsave(&amp;dwc-&gt;lock, flags);      &lt;-- 2nd
This issue is exposed by commit c7ebd8149ee5 ("usb: dwc3: gadget: Fix
NULL pointer dereference in dwc3_gadget_suspend") that removes the code
of checking whether dwc-&gt;gadget_driver is NULL or not. It causes the
following code is executed and deadlock occurs when trying to get the
spinlock. In fact, the root cause is the commit 5265397f9442("usb: dwc3:
Remove DWC3 locking during gadget suspend/resume") that forgot to remove
the lock of otg mode. So, remove the redundant lock of otg mode during
gadget suspend/resume.</Note>
    </Notes>
    <CVE>CVE-2024-42085</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: chemical: bme680: Fix overflows in compensate() functions

There are cases in the compensate functions of the driver that
there could be overflows of variables due to bit shifting ops.
These implications were initially discussed here [1] and they
were mentioned in log message of Commit 1b3bd8592780 ("iio:
chemical: Add support for Bosch BME680 sensor").

[1]: https://lore.kernel.org/linux-iio/20180728114028.3c1bbe81@archlinux/</Note>
    </Notes>
    <CVE>CVE-2024-42086</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep

The ilitek-ili9881c controls the reset GPIO using the non-sleeping
gpiod_set_value() function. This complains loudly when the GPIO
controller needs to sleep. As the caller can sleep, use
gpiod_set_value_cansleep() to fix the issue.</Note>
    </Notes>
    <CVE>CVE-2024-42087</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fsl-asoc-card: set priv-&gt;pdev before using it

priv-&gt;pdev pointer was set after being used in
fsl_asoc_card_audmux_init().
Move this assignment at the start of the probe function, so
sub-functions can correctly use pdev through priv.

fsl_asoc_card_audmux_init() dereferences priv-&gt;pdev to get access to the
dev struct, used with dev_err macros.
As priv is zero-initialised, there would be a NULL pointer dereference.
Note that if priv-&gt;dev is dereferenced before assignment but never used,
for example if there is no error to be printed, the driver won't crash
probably due to compiler optimisations.</Note>
    </Notes>
    <CVE>CVE-2024-42089</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER

In create_pinctrl(), pinctrl_maps_mutex is acquired before calling
add_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl()
calls pinctrl_free(). However, pinctrl_free() attempts to acquire
pinctrl_maps_mutex, which is already held by create_pinctrl(), leading to
a potential deadlock.

This patch resolves the issue by releasing pinctrl_maps_mutex before
calling pinctrl_free(), preventing the deadlock.

This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.</Note>
    </Notes>
    <CVE>CVE-2024-42090</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gpio: davinci: Validate the obtained number of IRQs

Value of pdata-&gt;gpio_unbanked is taken from Device Tree. In case of broken
DT due to any error this value can be any. Without this value validation
there can be out of chips-&gt;irqs array boundaries access in
davinci_gpio_probe().

Validate the obtained nirq value so that it won't exceed the maximum
number of IRQs per bank.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2024-42092</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: 8250_omap: Implementation of Errata i2310

As per Errata i2310[0], Erroneous timeout can be triggered,
if this Erroneous interrupt is not cleared then it may leads
to storm of interrupts, therefore apply Errata i2310 solution.

[0] https://www.ti.com/lit/pdf/sprz536 page 23</Note>
    </Notes>
    <CVE>CVE-2024-42095</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: emux: improve patch ioctl data validation

In load_data(), make the validation of and skipping over the main info
block match that in load_guspatch().

In load_guspatch(), add checking that the specified patch length matches
the actually supplied data, like load_data() already did.</Note>
    </Notes>
    <CVE>CVE-2024-42097</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ecdh - explicitly zeroize private_key

private_key is overwritten with the key parameter passed in by the
caller (if present), or alternatively a newly generated private key.
However, it is possible that the caller provides a key (or the newly
generated key) which is shorter than the previous key. In that
scenario, some key material from the previous key would not be
overwritten. The easiest solution is to explicitly zeroize the entire
private_key array first.

Note that this patch slightly changes the behavior of this function:
previously, if the ecc_gen_privkey failed, the old private_key would
remain. Now, the private_key is always zeroized. This behavior is
consistent with the case where params.key is set and ecc_is_key_valid
fails.</Note>
    </Notes>
    <CVE>CVE-2024-42098</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix null pointer dereference in nouveau_connector_get_modes

In nouveau_connector_get_modes(), the return value of drm_mode_duplicate()
is assigned to mode, which will lead to a possible NULL pointer
dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.</Note>
    </Notes>
    <CVE>CVE-2024-42101</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: add missing check for inode numbers on directory entries

Syzbot reported that mounting and unmounting a specific pattern of
corrupted nilfs2 filesystem images causes a use-after-free of metadata
file inodes, which triggers a kernel bug in lru_add_fn().

As Jan Kara pointed out, this is because the link count of a metadata file
gets corrupted to 0, and nilfs_evict_inode(), which is called from iput(),
tries to delete that inode (ifile inode in this case).

The inconsistency occurs because directories containing the inode numbers
of these metadata files that should not be visible in the namespace are
read without checking.

Fix this issue by treating the inode numbers of these internal files as
errors in the sanity check helper when reading directory folios/pages.

Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer
analysis.</Note>
    </Notes>
    <CVE>CVE-2024-42104</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

inet_diag: Initialize pad field in struct inet_diag_req_v2

KMSAN reported uninit-value access in raw_lookup() [1]. Diag for raw
sockets uses the pad field in struct inet_diag_req_v2 for the
underlying protocol. This field corresponds to the sdiag_raw_protocol
field in struct inet_diag_req_raw.

inet_diag_get_exact_compat() converts inet_diag_req to
inet_diag_req_v2, but leaves the pad field uninitialized. So the issue
occurs when raw_lookup() accesses the sdiag_raw_protocol field.

Fix this by initializing the pad field in
inet_diag_get_exact_compat(). Also, do the same fix in
inet_diag_dump_compat() to avoid the similar issue in the future.

[1]
BUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline]
BUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71
 raw_lookup net/ipv4/raw_diag.c:49 [inline]
 raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71
 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99
 inet_diag_cmd_exact+0x7d9/0x980
 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]
 inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426
 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282
 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564
 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297
 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
 netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361
 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg+0x332/0x3d0 net/socket.c:745
 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585
 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639
 __sys_sendmsg net/socket.c:2668 [inline]
 __do_sys_sendmsg net/socket.c:2677 [inline]
 __se_sys_sendmsg net/socket.c:2675 [inline]
 __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675
 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Uninit was stored to memory at:
 raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71
 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99
 inet_diag_cmd_exact+0x7d9/0x980
 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]
 inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426
 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282
 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564
 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297
 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
 netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361
 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg+0x332/0x3d0 net/socket.c:745
 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585
 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639
 __sys_sendmsg net/socket.c:2668 [inline]
 __do_sys_sendmsg net/socket.c:2677 [inline]
 __se_sys_sendmsg net/socket.c:2675 [inline]
 __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675
 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Local variable req.i created at:
 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline]
 inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426
 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282

CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014</Note>
    </Notes>
    <CVE>CVE-2024-42106</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Don't process extts if PTP is disabled

The ice_ptp_extts_event() function can race with ice_ptp_release() and
result in a NULL pointer dereference which leads to a kernel panic.

Panic occurs because the ice_ptp_extts_event() function calls
ptp_clock_event() with a NULL pointer. The ice driver has already
released the PTP clock by the time the interrupt for the next external
timestamp event occurs.

To fix this, modify the ice_ptp_extts_event() function to check the
PTP state and bail early if PTP is not ready.</Note>
    </Notes>
    <CVE>CVE-2024-42107</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ntb_netdev: Move ntb_netdev_rx_handler() to call netif_rx() from __netif_rx()

The following is emitted when using idxd (DSA) dmanegine as the data
mover for ntb_transport that ntb_netdev uses.

[74412.546922] BUG: using smp_processor_id() in preemptible [00000000] code: irq/52-idxd-por/14526
[74412.556784] caller is netif_rx_internal+0x42/0x130
[74412.562282] CPU: 6 PID: 14526 Comm: irq/52-idxd-por Not tainted 6.9.5 #5
[74412.569870] Hardware name: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.E9I.1752.P05.2402080856 02/08/2024
[74412.581699] Call Trace:
[74412.584514]  &lt;TASK&gt;
[74412.586933]  dump_stack_lvl+0x55/0x70
[74412.591129]  check_preemption_disabled+0xc8/0xf0
[74412.596374]  netif_rx_internal+0x42/0x130
[74412.600957]  __netif_rx+0x20/0xd0
[74412.604743]  ntb_netdev_rx_handler+0x66/0x150 [ntb_netdev]
[74412.610985]  ntb_complete_rxc+0xed/0x140 [ntb_transport]
[74412.617010]  ntb_rx_copy_callback+0x53/0x80 [ntb_transport]
[74412.623332]  idxd_dma_complete_txd+0xe3/0x160 [idxd]
[74412.628963]  idxd_wq_thread+0x1a6/0x2b0 [idxd]
[74412.634046]  irq_thread_fn+0x21/0x60
[74412.638134]  ? irq_thread+0xa8/0x290
[74412.642218]  irq_thread+0x1a0/0x290
[74412.646212]  ? __pfx_irq_thread_fn+0x10/0x10
[74412.651071]  ? __pfx_irq_thread_dtor+0x10/0x10
[74412.656117]  ? __pfx_irq_thread+0x10/0x10
[74412.660686]  kthread+0x100/0x130
[74412.664384]  ? __pfx_kthread+0x10/0x10
[74412.668639]  ret_from_fork+0x31/0x50
[74412.672716]  ? __pfx_kthread+0x10/0x10
[74412.676978]  ret_from_fork_asm+0x1a/0x30
[74412.681457]  &lt;/TASK&gt;

The cause is due to the idxd driver interrupt completion handler uses
threaded interrupt and the threaded handler is not hard or soft interrupt
context. However __netif_rx() can only be called from interrupt context.
Change the call to netif_rx() in order to allow completion via normal
context for dmaengine drivers that utilize threaded irq handling.

While the following commit changed from netif_rx() to __netif_rx(),
baebdf48c360 ("net: dev: Makes sure netif_rx() can be invoked in any context."),
the change should've been a noop instead. However, the code precedes this
fix should've been using netif_rx_ni() or netif_rx_any_context().</Note>
    </Notes>
    <CVE>CVE-2024-42110</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: restrict NL80211_ATTR_TXQ_QUANTUM values

syzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM
to 2^31.

We had a similar issue in sch_fq, fixed with commit
d9e15a273306 ("pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM")

watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]
Modules linked in:
irq event stamp: 131135
 hardirqs last  enabled at (131134): [&lt;ffff80008ae8778c&gt;] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline]
 hardirqs last  enabled at (131134): [&lt;ffff80008ae8778c&gt;] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95
 hardirqs last disabled at (131135): [&lt;ffff80008ae85378&gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
 hardirqs last disabled at (131135): [&lt;ffff80008ae85378&gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
 softirqs last  enabled at (125892): [&lt;ffff80008907e82c&gt;] neigh_hh_init net/core/neighbour.c:1538 [inline]
 softirqs last  enabled at (125892): [&lt;ffff80008907e82c&gt;] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553
 softirqs last disabled at (125896): [&lt;ffff80008904166c&gt;] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19
CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Workqueue: mld mld_ifc_work
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : __list_del include/linux/list.h:195 [inline]
 pc : __list_del_entry include/linux/list.h:218 [inline]
 pc : list_move_tail include/linux/list.h:310 [inline]
 pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline]
 pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854
 lr : __list_del_entry include/linux/list.h:218 [inline]
 lr : list_move_tail include/linux/list.h:310 [inline]
 lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline]
 lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854
sp : ffff800093d36700
x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000
x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0
x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0
x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0
x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8
x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff
x11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc
x2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470
Call trace:
  __list_del include/linux/list.h:195 [inline]
  __list_del_entry include/linux/list.h:218 [inline]
  list_move_tail include/linux/list.h:310 [inline]
  fq_tin_dequeue include/net/fq_impl.h:112 [inline]
  ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854
  wake_tx_push_queue net/mac80211/util.c:294 [inline]
  ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315
  drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline]
  schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline]
  ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664
  ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966
  ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062
  __ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338
  ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532
  __netdev_start_xmit include/linux/netdevice.h:4903 [inline]
  netdev_start_xmit include/linux/netdevice.h:4917 [inline]
  xmit_one net/core/dev.c:3531 [inline]
  dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547
  __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341
  dev_queue_xmit include/linux/netdevice.h:3091 [inline]
  neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563
  neigh_output include/net/neighbour.h:542 [inline]
  ip6_fini
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-42114</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix potential illegal address access in jffs2_free_inode

During the stress testing of the jffs2 file system,the following
abnormal printouts were found:
[ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948
[ 2430.649622] Mem abort info:
[ 2430.649829]   ESR = 0x96000004
[ 2430.650115]   EC = 0x25: DABT (current EL), IL = 32 bits
[ 2430.650564]   SET = 0, FnV = 0
[ 2430.650795]   EA = 0, S1PTW = 0
[ 2430.651032]   FSC = 0x04: level 0 translation fault
[ 2430.651446] Data abort info:
[ 2430.651683]   ISV = 0, ISS = 0x00000004
[ 2430.652001]   CM = 0, WnR = 0
[ 2430.652558] [0069696969696948] address between user and kernel address ranges
[ 2430.653265] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 2430.654512] CPU: 2 PID: 20919 Comm: cat Not tainted 5.15.25-g512f31242bf6 #33
[ 2430.655008] Hardware name: linux,dummy-virt (DT)
[ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 2430.656142] pc : kfree+0x78/0x348
[ 2430.656630] lr : jffs2_free_inode+0x24/0x48
[ 2430.657051] sp : ffff800009eebd10
[ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000
[ 2430.658327] x26: ffff000038f09d80 x25: 0080000000000000 x24: ffff800009d38000
[ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14
[ 2430.659434] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 0000000000000000
[ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000
[ 2430.660637] x14: 0000000000000000 x13: 00000001000820a1 x12: 00000000000d1b19
[ 2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9 : ffff8000084f0d14
[ 2430.662025] x8 : ffff0000bf9a6b40 x7 : ffff0000bf9a6b48 x6 : 0000000003470302
[ 2430.662695] x5 : ffff00002e41dcc0 x4 : ffff0000bf9aa3b0 x3 : 0000000003470342
[ 2430.663486] x2 : 0000000000000000 x1 : ffff8000084f0d14 x0 : fffffc0000000000
[ 2430.664217] Call trace:
[ 2430.664528]  kfree+0x78/0x348
[ 2430.664855]  jffs2_free_inode+0x24/0x48
[ 2430.665233]  i_callback+0x24/0x50
[ 2430.665528]  rcu_do_batch+0x1ac/0x448
[ 2430.665892]  rcu_core+0x28c/0x3c8
[ 2430.666151]  rcu_core_si+0x18/0x28
[ 2430.666473]  __do_softirq+0x138/0x3cc
[ 2430.666781]  irq_exit+0xf0/0x110
[ 2430.667065]  handle_domain_irq+0x6c/0x98
[ 2430.667447]  gic_handle_irq+0xac/0xe8
[ 2430.667739]  call_on_irq_stack+0x28/0x54
The parameter passed to kfree was 5a5a5a5a, which corresponds to the target field of
the jffs_inode_info structure. It was found that all variables in the jffs_inode_info
structure were 5a5a5a5a, except for the first member sem. It is suspected that these
variables are not initialized because they were set to 5a5a5a5a during memory testing,
which is meant to detect uninitialized memory.The sem variable is initialized in the
function jffs2_i_init_once, while other members are initialized in
the function jffs2_init_inode_info.

The function jffs2_init_inode_info is called after iget_locked,
but in the iget_locked function, the destroy_inode process is triggered,
which releases the inode and consequently, the target member of the inode
is not initialized.In concurrent high pressure scenarios, iget_locked
may enter the destroy_inode branch as described in the code.

Since the destroy_inode functionality of jffs2 only releases the target,
the fix method is to set target to NULL in jffs2_i_init_once.</Note>
    </Notes>
    <CVE>CVE-2024-42115</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 finding free audio for unknown engine_id

[WHY]
ENGINE_ID_UNKNOWN = -1 and can not be used as an array index. Plus, it
also means it is uninitialized and does not need free audio.

[HOW]
Skip and return NULL.

This fixes 2 OVERRUN issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-42119</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 pipe offset before setting vblank

pipe_ctx has a size of MAX_PIPES so checking its index before accessing
the array.

This fixes an OVERRUN issue reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-42120</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 index msg_id before read or write

[WHAT]
msg_id is used as an array index and it cannot be a negative value, and
therefore cannot be equal to MOD_HDCP_MESSAGE_ID_INVALID (-1).

[HOW]
Check whether msg_id is valid before reading and setting.

This fixes 4 OVERRUN issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-42121</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Avoid nmi_enter/nmi_exit in real mode interrupt.

nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel
crash when invoked during real mode interrupt handling (e.g. early HMI/MCE
interrupt handler) if percpu allocation comes from vmalloc area.

Early HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI()
wrapper which invokes nmi_enter/nmi_exit calls. We don't see any issue when
percpu allocation is from the embedded first chunk. However with
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK enabled there are chances where percpu
allocation can come from the vmalloc area.

With kernel command line "percpu_alloc=page" we can force percpu allocation
to come from vmalloc area and can see kernel crash in machine_check_early:

[    1.215714] NIP [c000000000e49eb4] rcu_nmi_enter+0x24/0x110
[    1.215717] LR [c0000000000461a0] machine_check_early+0xf0/0x2c0
[    1.215719] --- interrupt: 200
[    1.215720] [c000000fffd73180] [0000000000000000] 0x0 (unreliable)
[    1.215722] [c000000fffd731b0] [0000000000000000] 0x0
[    1.215724] [c000000fffd73210] [c000000000008364] machine_check_early_common+0x134/0x1f8

Fix this by avoiding use of nmi_enter()/nmi_exit() in real mode if percpu
first chunk is not embedded.</Note>
    </Notes>
    <CVE>CVE-2024-42126</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/lima: fix shared irq handling on driver remove

lima uses a shared interrupt, so the interrupt handlers must be prepared
to be called at any time. At driver removal time, the clocks are
disabled early and the interrupts stay registered until the very end of
the remove process due to the devm usage.
This is potentially a bug as the interrupts access device registers
which assumes clocks are enabled. A crash can be triggered by removing
the driver in a kernel with CONFIG_DEBUG_SHIRQ enabled.
This patch frees the interrupts at each lima device finishing callback
so that the handlers are already unregistered by the time we fully
disable clocks.</Note>
    </Notes>
    <CVE>CVE-2024-42127</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Add the inconsistency check between the input data length and count

write$nci(r0, &amp;(0x7f0000000740)=ANY=[@ANYBLOB="610501"], 0xf)

Syzbot constructed a write() call with a data length of 3 bytes but a count value
of 15, which passed too little data to meet the basic requirements of the function
nci_rf_intf_activated_ntf_packet().

Therefore, increasing the comparison between data length and count value to avoid
problems caused by inconsistent data length and count.</Note>
    </Notes>
    <CVE>CVE-2024-42130</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 overflows in dirty throttling logic

The dirty throttling logic is interspersed with assumptions that dirty
limits in PAGE_SIZE units fit into 32-bit (so that various multiplications
fit into 64-bits).  If limits end up being larger, we will hit overflows,
possible divisions by 0 etc.  Fix these problems by never allowing so
large dirty limits as they have dubious practical value anyway.  For
dirty_bytes / dirty_background_bytes interfaces we can just refuse to set
so large limits.  For dirty_ratio / dirty_background_ratio it isn't so
simple as the dirty limit is computed from the amount of available memory
which can change due to memory hotplug etc.  So when converting dirty
limits from ratios to numbers of pages, we just don't allow the result to
exceed UINT_MAX.

This is root-only triggerable problem which occurs when the operator
sets dirty limits to &gt;16 TB.</Note>
    </Notes>
    <CVE>CVE-2024-42131</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qca: Fix BT enable failure again for QCA6390 after warm reboot

Commit 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed
serdev") will cause below regression issue:

BT can't be enabled after below steps:
cold boot -&gt; enable BT -&gt; disable BT -&gt; warm reboot -&gt; BT enable failure
if property enable-gpios is not configured within DT|ACPI for QCA6390.

The commit is to fix a use-after-free issue within qca_serdev_shutdown()
by adding condition to avoid the serdev is flushed or wrote after closed
but also introduces this regression issue regarding above steps since the
VSC is not sent to reset controller during warm reboot.

Fixed by sending the VSC to reset controller within qca_serdev_shutdown()
once BT was ever enabled, and the use-after-free issue is also fixed by
this change since the serdev is still opened before it is flushed or wrote.

Verified by the reported machine Dell XPS 13 9310 laptop over below two
kernel commits:
commit e00fc2700a3f ("Bluetooth: btusb: Fix triggering coredump
implementation for QCA") of bluetooth-next tree.
commit b23d98d46d28 ("Bluetooth: btusb: Fix triggering coredump
implementation for QCA") of linus mainline tree.</Note>
    </Notes>
    <CVE>CVE-2024-42137</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 extts handling

Extts events are disabled and enabled by the application ts2phc.
However, in case where the driver is removed when the application is
running, a specific extts event remains enabled and can cause a kernel
crash.
As a side effect, when the driver is reloaded and application is started
again, remaining extts event for the channel from a previous run will
keep firing and the message "extts on unexpected channel" might be
printed to the user.

To avoid that, extts events shall be disabled when PTP is released.</Note>
    </Notes>
    <CVE>CVE-2024-42139</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: E-switch, Create ingress ACL when needed

Currently, ingress acl is used for three features. It is created only
when vport metadata match and prio tag are enabled. But active-backup
lag mode also uses it. It is independent of vport metadata match and
prio tag. And vport metadata match can be disabled using the
following devlink command:

 # devlink dev param set pci/0000:08:00.0 name esw_port_metadata \
	value false cmode runtime

If ingress acl is not created, will hit panic when creating drop rule
for active-backup lag mode. If always create it, there will be about
5% performance degradation.

Fix it by creating ingress acl when needed. If esw_port_metadata is
true, ingress acl exists, then create drop rule using existing
ingress acl. If esw_port_metadata is false, create ingress acl and
then create drop rule.</Note>
    </Notes>
    <CVE>CVE-2024-42142</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-42143</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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:

bnx2x: Fix multiple UBSAN array-index-out-of-bounds

Fix UBSAN warnings that occur when using a system with 32 physical
cpu cores or more, or when the user defines a number of Ethernet
queues greater than or equal to FP_SB_MAX_E1x using the num_queues
module parameter.

Currently there is a read/write out of bounds that occurs on the array
"struct stats_query_entry query" present inside the "bnx2x_fw_stats_req"
struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h".
Looking at the definition of the "struct stats_query_entry query" array:

struct stats_query_entry query[FP_SB_MAX_E1x+
         BNX2X_FIRST_QUEUE_QUERY_IDX];

FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and
has a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3
meaning the array has a total size of 19.
Since accesses to "struct stats_query_entry query" are offset-ted by
BNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet
queues should not exceed FP_SB_MAX_E1x (16). However one of these queues
is reserved for FCOE and thus the number of Ethernet queues should be set
to [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if
it is not.

This is also described in a comment in the source code in
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition
of FP_SB_MAX_E1x. Below is the part of this explanation that it important
for this patch

/*
  * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is
  * control by the number of fast-path status blocks supported by the
  * device (HW/FW). Each fast-path status block (FP-SB) aka non-default
  * status block represents an independent interrupts context that can
  * serve a regular L2 networking queue. However special L2 queues such
  * as the FCoE queue do not require a FP-SB and other components like
  * the CNIC may consume FP-SB reducing the number of possible L2 queues
  *
  * If the maximum number of FP-SB available is X then:
  * a. If CNIC is supported it consumes 1 FP-SB thus the max number of
  *    regular L2 queues is Y=X-1
  * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor)
  * c. If the FCoE L2 queue is supported the actual number of L2 queues
  *    is Y+1
  * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for
  *    slow-path interrupts) or Y+2 if CNIC is supported (one additional
  *    FP interrupt context for the CNIC).
  * e. The number of HW context (CID count) is always X or X+1 if FCoE
  *    L2 queue is supported. The cid for the FCoE L2 queue is always X.
  */

However this driver also supports NICs that use the E2 controller which can
handle more queues due to having more FP-SB represented by FP_SB_MAX_E2.
Looking at the commits when the E2 support was added, it was originally
using the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support").
Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver
was later updated to take full advantage of the E2 instead of having it be
limited to the capabilities of the E1x. But as far as we can tell, the
array "stats_query_entry query" was still limited to using the FP-SB
available to the E1x cards as part of an oversignt when the driver was
updated to take full advantage of the E2, and now with the driver being
aware of the greater queue size supported by E2 NICs, it causes the UBSAN
warnings seen in the stack traces below.

This patch increases the size of the "stats_query_entry query" array by
replacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle
both types of NICs.

Stack traces:

UBSAN: array-index-out-of-bounds in
       drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11
index 20 is out of range for type 'stats_query_entry [19]'
CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic
	     #202405052133
Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-42148</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix a possible leak when destroy a ctrl during qp establishment

In nvmet_sq_destroy we capture sq-&gt;ctrl early and if it is non-NULL we
know that a ctrl was allocated (in the admin connect request handler)
and we need to release pending AERs, clear ctrl-&gt;sqs and sq-&gt;ctrl
(for nvme-loop primarily), and drop the final reference on the ctrl.

However, a small window is possible where nvmet_sq_destroy starts (as
a result of the client giving up and disconnecting) concurrently with
the nvme admin connect cmd (which may be in an early stage). But *before*
kill_and_confirm of sq-&gt;ref (i.e. the admin connect managed to get an sq
live reference). In this case, sq-&gt;ctrl was allocated however after it was
captured in a local variable in nvmet_sq_destroy.
This prevented the final reference drop on the ctrl.

Solve this by re-capturing the sq-&gt;ctrl after all inflight request has
completed, where for sure sq-&gt;ctrl reference is final, and move forward
based on that.

This issue was observed in an environment with many hosts connecting
multiple ctrls simoutanuosly, creating a delay in allocating a ctrl
leading up to this race window.</Note>
    </Notes>
    <CVE>CVE-2024-42152</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_metrics: validate source addr length

I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4
is at least 4 bytes long, and the policy doesn't have an entry
for this attribute at all (neither does it for IPv6 but v6 is
manually validated).</Note>
    </Notes>
    <CVE>CVE-2024-42154</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/pkey: Wipe copies of protected- and secure-keys

Although the clear-key of neither protected- nor secure-keys is
accessible, this key material should only be visible to the calling
process. So wipe all copies of protected- or secure-keys from stack,
even in case of an error.</Note>
    </Notes>
    <CVE>CVE-2024-42155</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/pkey: Wipe copies of clear-key structures on failure

Wipe all sensitive data from stack for all IOCTLs, which convert a
clear-key into a protected- or secure-key.</Note>
    </Notes>
    <CVE>CVE-2024-42156</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/pkey: Wipe sensitive data on failure

Wipe sensitive data from stack also if the copy_to_user() fails.</Note>
    </Notes>
    <CVE>CVE-2024-42157</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/pkey: Use kfree_sensitive() to fix Coccinelle warnings

Replace memzero_explicit() and kfree() with kfree_sensitive() to fix
warnings reported by Coccinelle:

WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1506)
WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1643)
WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1770)</Note>
    </Notes>
    <CVE>CVE-2024-42158</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gve: Account for stopped queues when reading NIC stats

We now account for the fact that the NIC might send us stats for a
subset of queues. Without this change, gve_get_ethtool_stats might make
an invalid access on the priv-&gt;stats_report-&gt;stats array.</Note>
    </Notes>
    <CVE>CVE-2024-42162</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: dvb-frontends: tda10048: Fix integer overflow

state-&gt;xtal_hz can be up to 16M, so it can overflow a 32 bit integer
when multiplied by pll_mfactor.

Create a new 64 bit variable to hold the calculations.</Note>
    </Notes>
    <CVE>CVE-2024-42223</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: replace skb_put with skb_put_zero

Avoid potentially reusing uninitialized data</Note>
    </Notes>
    <CVE>CVE-2024-42225</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-42226</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Using uninitialized value *size when calling amdgpu_vce_cs_reloc

Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001.
V2: To really improve the handling we would actually
   need to have a separate value of 0xffffffff.(Christian)</Note>
    </Notes>
    <CVE>CVE-2024-42228</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: aead,cipher - zeroize key buffer after use

I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding
cryptographic information should be zeroized once they are no longer
needed. Accomplish this by using kfree_sensitive for buffers that
previously held the private key.</Note>
    </Notes>
    <CVE>CVE-2024-42229</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/pseries: Fix scv instruction crash with kexec

kexec on pseries disables AIL (reloc_on_exc), required for scv
instruction support, before other CPUs have been shut down. This means
they can execute scv instructions after AIL is disabled, which causes an
interrupt at an unexpected entry location that crashes the kernel.

Change the kexec sequence to disable AIL after other CPUs have been
brought down.

As a refresher, the real-mode scv interrupt vector is 0x17000, and the
fixed-location head code probably couldn't easily deal with implementing
such high addresses so it was just decided not to support that interrupt
at all.</Note>
    </Notes>
    <CVE>CVE-2024-42230</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

libceph: fix race between delayed_work() and ceph_monc_stop()

The way the delayed work is handled in ceph_monc_stop() is prone to
races with mon_fault() and possibly also finish_hunting().  Both of
these can requeue the delayed work which wouldn't be canceled by any of
the following code in case that happens after cancel_delayed_work_sync()
runs -- __close_session() doesn't mess with the delayed work in order
to avoid interfering with the hunting interval logic.  This part was
missed in commit b5d91704f53e ("libceph: behave in mon_fault() if
cur_mon &lt; 0") and use-after-free can still ensue on monc and objects
that hang off of it, with monc-&gt;auth and monc-&gt;monmap being
particularly susceptible to quickly being reused.

To fix this:

- clear monc-&gt;cur_mon and monc-&gt;hunting as part of closing the session
  in ceph_monc_stop()
- bail from delayed_work() if monc-&gt;cur_mon is cleared, similar to how
  it's done in mon_fault() and finish_hunting() (based on monc-&gt;hunting)
- call cancel_delayed_work_sync() after the session is closed</Note>
    </Notes>
    <CVE>CVE-2024-42232</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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: gadget: configfs: Prevent OOB read/write in usb_string_copy()

Userspace provided string 's' could trivially have the length zero. Left
unchecked this will firstly result in an OOB read in the form
`if (str[0 - 1] == '\n') followed closely by an OOB write in the form
`str[0 - 1] = '\0'`.

There is already a validating check to catch strings that are too long.
Let's supply an additional check for invalid strings that are too short.</Note>
    </Notes>
    <CVE>CVE-2024-42236</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: cs_dsp: Validate payload length before processing block

Move the payload length check in cs_dsp_load() and cs_dsp_coeff_load()
to be done before the block is processed.

The check that the length of a block payload does not exceed the number
of remaining bytes in the firwmware file buffer was being done near the
end of the loop iteration. However, some code before that check used the
length field without validating it.</Note>
    </Notes>
    <CVE>CVE-2024-42237</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: cs_dsp: Return error if block header overflows file

Return an error from cs_dsp_power_up() if a block header is longer
than the amount of data left in the file.

The previous code in cs_dsp_load() and cs_dsp_load_coeff() would loop
while there was enough data left in the file for a valid region. This
protected against overrunning the end of the file data, but it didn't
abort the file processing with an error.</Note>
    </Notes>
    <CVE>CVE-2024-42238</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/bhi: Avoid warning in #DB handler due to BHI mitigation

When BHI mitigation is enabled, if SYSENTER is invoked with the TF flag set
then entry_SYSENTER_compat() uses CLEAR_BRANCH_HISTORY and calls the
clear_bhb_loop() before the TF flag is cleared. This causes the #DB handler
(exc_debug_kernel()) to issue a warning because single-step is used outside the
entry_SYSENTER_compat() function.

To address this issue, entry_SYSENTER_compat() should use CLEAR_BRANCH_HISTORY
after making sure the TF flag is cleared.

The problem can be reproduced with the following sequence:

  $ cat sysenter_step.c
  int main()
  { asm("pushf; pop %ax; bts $8,%ax; push %ax; popf; sysenter"); }

  $ gcc -o sysenter_step sysenter_step.c

  $ ./sysenter_step
  Segmentation fault (core dumped)

The program is expected to crash, and the #DB handler will issue a warning.

Kernel log:

  WARNING: CPU: 27 PID: 7000 at arch/x86/kernel/traps.c:1009 exc_debug_kernel+0xd2/0x160
  ...
  RIP: 0010:exc_debug_kernel+0xd2/0x160
  ...
  Call Trace:
  &lt;#DB&gt;
   ? show_regs+0x68/0x80
   ? __warn+0x8c/0x140
   ? exc_debug_kernel+0xd2/0x160
   ? report_bug+0x175/0x1a0
   ? handle_bug+0x44/0x90
   ? exc_invalid_op+0x1c/0x70
   ? asm_exc_invalid_op+0x1f/0x30
   ? exc_debug_kernel+0xd2/0x160
   exc_debug+0x43/0x50
   asm_exc_debug+0x1e/0x40
  RIP: 0010:clear_bhb_loop+0x0/0xb0
  ...
  &lt;/#DB&gt;
  &lt;TASK&gt;
   ? entry_SYSENTER_compat_after_hwframe+0x6e/0x8d
  &lt;/TASK&gt;

  [ bp: Massage commit message. ]</Note>
    </Notes>
    <CVE>CVE-2024-42240</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mos7840: fix crash on resume

Since commit c49cfa917025 ("USB: serial: use generic method if no
alternative is provided in usb serial layer"), USB serial core calls the
generic resume implementation when the driver has not provided one.

This can trigger a crash on resume with mos7840 since support for
multiple read URBs was added back in 2011. Specifically, both port read
URBs are now submitted on resume for open ports, but the context pointer
of the second URB is left set to the core rather than mos7840 port
structure.

Fix this by implementing dedicated suspend and resume functions for
mos7840.

Tested with Delock 87414 USB 2.0 to 4x serial adapter.

[ johan: analyse crash and rewrite commit message; set busy flag on
         resume; drop bulk-in check; drop unnecessary usb_kill_urb() ]</Note>
    </Notes>
    <CVE>CVE-2024-42244</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket

When using a BPF program on kernel_connect(), the call can return -EPERM. This
causes xs_tcp_setup_socket() to loop forever, filling up the syslog and causing
the kernel to potentially freeze up.

Neil suggested:

  This will propagate -EPERM up into other layers which might not be ready
  to handle it. It might be safer to map EPERM to an error we would be more
  likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.

ECONNREFUSED as error seems reasonable. For programs setting a different error
can be out of reach (see handling in 4fbac77d2d09) in particular on kernels
which do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -err
instead of allow boolean"), thus given that it is better to simply remap for
consistent behavior. UDP does handle EPERM in xs_udp_send_request().</Note>
    </Notes>
    <CVE>CVE-2024-42246</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wireguard: allowedips: avoid unaligned 64-bit memory accesses

On the parisc platform, the kernel issues kernel warnings because
swap_endian() tries to load a 128-bit IPv6 address from an unaligned
memory location:

 Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df)
 Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc)

Avoid such unaligned memory accesses by instead using the
get_unaligned_be64() helper macro.

[Jason: replace src[8] in original patch with src+8]</Note>
    </Notes>
    <CVE>CVE-2024-42247</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gpio: pca953x: fix pca953x_irq_bus_sync_unlock race

Ensure that `i2c_lock' is held when setting interrupt latch and mask in
pca953x_irq_bus_sync_unlock() in order to avoid races.

The other (non-probe) call site pca953x_gpio_set_multiple() ensures the
lock is held before calling pca953x_write_regs().

The problem occurred when a request raced against irq_bus_sync_unlock()
approximately once per thousand reboots on an i.MX8MP based system.

 * Normal case

   0-0022: write register AI|3a {03,02,00,00,01} Input latch P0
   0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0
   0-0022: write register AI|08 {ff,00,00,00,00} Output P3
   0-0022: write register AI|12 {fc,00,00,00,00} Config P3

 * Race case

   0-0022: write register AI|08 {ff,00,00,00,00} Output P3
   0-0022: write register AI|08 {03,02,00,00,01} *** Wrong register ***
   0-0022: write register AI|12 {fc,00,00,00,00} Config P3
   0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0</Note>
    </Notes>
    <CVE>CVE-2024-42253</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/gem: Fix Virtual Memory mapping boundaries calculation

Calculating the size of the mapped area as the lesser value
between the requested size and the actual size does not consider
the partial mapping offset. This can cause page fault access.

Fix the calculation of the starting and ending addresses, the
total size is now deduced from the difference between the end and
start addresses.

Additionally, the calculations have been rewritten in a clearer
and more understandable form.

[Joonas: Add Requires: tag]
Requires: 60a2066c5005 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset")
(cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)</Note>
    </Notes>
    <CVE>CVE-2024-42259</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

protect the fetch of -&gt;fd[fd] in do_dup2() from mispredictions

both callers have verified that fd is not greater than -&gt;max_fds;
however, misprediction might end up with
        tofree = fdt-&gt;fd[fd];
being speculatively executed.  That's wrong for the same reasons
why it's wrong in close_fd()/file_close_fd_locked(); the same
solution applies - array_index_nospec(fd, fdt-&gt;max_fds) could differ
from fd only in case of speculative execution on mispredicted path.</Note>
    </Notes>
    <CVE>CVE-2024-42265</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 missing lock on sync reset reload

On sync reset reload work, when remote host updates devlink on reload
actions performed on that host, it misses taking devlink lock before
calling devlink_remote_reload_actions_performed() which results in
triggering lock assert like the following:

WARNING: CPU: 4 PID: 1164 at net/devlink/core.c:261 devl_assert_locked+0x3e/0x50
...
 CPU: 4 PID: 1164 Comm: kworker/u96:6 Tainted: G S      W          6.10.0-rc2+ #116
 Hardware name: Supermicro SYS-2028TP-DECTR/X10DRT-PT, BIOS 2.0 12/18/2015
 Workqueue: mlx5_fw_reset_events mlx5_sync_reset_reload_work [mlx5_core]
 RIP: 0010:devl_assert_locked+0x3e/0x50
...
 Call Trace:
  &lt;TASK&gt;
  ? __warn+0xa4/0x210
  ? devl_assert_locked+0x3e/0x50
  ? report_bug+0x160/0x280
  ? handle_bug+0x3f/0x80
  ? exc_invalid_op+0x17/0x40
  ? asm_exc_invalid_op+0x1a/0x20
  ? devl_assert_locked+0x3e/0x50
  devlink_notify+0x88/0x2b0
  ? mlx5_attach_device+0x20c/0x230 [mlx5_core]
  ? __pfx_devlink_notify+0x10/0x10
  ? process_one_work+0x4b6/0xbb0
  process_one_work+0x4b6/0xbb0
[...]</Note>
    </Notes>
    <CVE>CVE-2024-42268</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/iucv: fix use after free in iucv_sock_close()

iucv_sever_path() is called from process context and from bh context.
iucv-&gt;path is used as indicator whether somebody else is taking care of
severing the path (or it is already removed / never existed).
This needs to be done with atomic compare and swap, otherwise there is a
small window where iucv_sock_close() will try to work with a path that has
already been severed and freed by iucv_callback_connrej() called by
iucv_tasklet_fn().

Example:
[452744.123844] Call Trace:
[452744.123845] ([&lt;0000001e87f03880&gt;] 0x1e87f03880)
[452744.123966]  [&lt;00000000d593001e&gt;] iucv_path_sever+0x96/0x138
[452744.124330]  [&lt;000003ff801ddbca&gt;] iucv_sever_path+0xc2/0xd0 [af_iucv]
[452744.124336]  [&lt;000003ff801e01b6&gt;] iucv_sock_close+0xa6/0x310 [af_iucv]
[452744.124341]  [&lt;000003ff801e08cc&gt;] iucv_sock_release+0x3c/0xd0 [af_iucv]
[452744.124345]  [&lt;00000000d574794e&gt;] __sock_release+0x5e/0xe8
[452744.124815]  [&lt;00000000d5747a0c&gt;] sock_close+0x34/0x48
[452744.124820]  [&lt;00000000d5421642&gt;] __fput+0xba/0x268
[452744.124826]  [&lt;00000000d51b382c&gt;] task_work_run+0xbc/0xf0
[452744.124832]  [&lt;00000000d5145710&gt;] do_notify_resume+0x88/0x90
[452744.124841]  [&lt;00000000d5978096&gt;] system_call+0xe2/0x2c8
[452744.125319] Last Breaking-Event-Address:
[452744.125321]  [&lt;00000000d5930018&gt;] iucv_path_sever+0x90/0x138
[452744.125324]
[452744.125325] Kernel panic - not syncing: Fatal exception in interrupt

Note that bh_lock_sock() is not serializing the tasklet context against
process context, because the check for sock_owned_by_user() and
corresponding handling is missing.

Ideas for a future clean-up patch:
A) Correct usage of bh_lock_sock() in tasklet context, as described in
Re-enqueue, if needed. This may require adding return values to the
tasklet functions and thus changes to all users of iucv.

B) Change iucv tasklet into worker and use only lock_sock() in af_iucv.</Note>
    </Notes>
    <CVE>CVE-2024-42271</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

Revert "ALSA: firewire-lib: operate for period elapse event in process context"

Commit 7ba5ca32fe6e ("ALSA: firewire-lib: operate for period elapse event
in process context") removed the process context workqueue from
amdtp_domain_stream_pcm_pointer() and update_pcm_pointers() to remove
its overhead.

With RME Fireface 800, this lead to a regression since
Kernels 5.14.0, causing an AB/BA deadlock competition for the
substream lock with eventual system freeze under ALSA operation:

thread 0:
    * (lock A) acquire substream lock by
	snd_pcm_stream_lock_irq() in
	snd_pcm_status64()
    * (lock B) wait for tasklet to finish by calling
    	tasklet_unlock_spin_wait() in
	tasklet_disable_in_atomic() in
	ohci_flush_iso_completions() of ohci.c

thread 1:
    * (lock B) enter tasklet
    * (lock A) attempt to acquire substream lock,
    	waiting for it to be released:
	snd_pcm_stream_lock_irqsave() in
    	snd_pcm_period_elapsed() in
	update_pcm_pointers() in
	process_ctx_payloads() in
	process_rx_packets() of amdtp-stream.c

? tasklet_unlock_spin_wait
 &lt;/NMI&gt;
 &lt;TASK&gt;
ohci_flush_iso_completions firewire_ohci
amdtp_domain_stream_pcm_pointer snd_firewire_lib
snd_pcm_update_hw_ptr0 snd_pcm
snd_pcm_status64 snd_pcm

? native_queued_spin_lock_slowpath
 &lt;/NMI&gt;
 &lt;IRQ&gt;
_raw_spin_lock_irqsave
snd_pcm_period_elapsed snd_pcm
process_rx_packets snd_firewire_lib
irq_target_callback snd_firewire_lib
handle_it_packet firewire_ohci
context_tasklet firewire_ohci

Restore the process context work queue to prevent deadlock
AB/BA deadlock competition for ALSA substream lock of
snd_pcm_stream_lock_irq() in snd_pcm_status64()
and snd_pcm_stream_lock_irqsave() in snd_pcm_period_elapsed().

revert commit 7ba5ca32fe6e ("ALSA: firewire-lib: operate for period
elapse event in process context")

Replace inline description to prevent future deadlock.</Note>
    </Notes>
    <CVE>CVE-2024-42274</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: add missing condition check for existence of mapped data

nvme_map_data() is called when request has physical segments, hence
the nvme_unmap_data() should have same condition to avoid dereference.</Note>
    </Notes>
    <CVE>CVE-2024-42276</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sprd: Avoid NULL deref in sprd_iommu_hw_en

In sprd_iommu_cleanup() before calling function sprd_iommu_hw_en()
dom-&gt;sdev is equal to NULL, which leads to null dereference.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2024-42277</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mISDN: Fix a use after free in hfcmulti_tx()

Don't dereference *sp after calling dev_kfree_skb(*sp).</Note>
    </Notes>
    <CVE>CVE-2024-42280</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 segment issue when downgrading gso_size

Linearize the skb when downgrading gso_size because it may trigger a
BUG_ON() later when the skb is segmented as described in [1,2].</Note>
    </Notes>
    <CVE>CVE-2024-42281</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: nexthop: Initialize all fields in dumped nexthops

struct nexthop_grp contains two reserved fields that are not initialized by
nla_put_nh_group(), and carry garbage. This can be observed e.g. with
strace (edited for clarity):

    # ip nexthop add id 1 dev lo
    # ip nexthop add id 101 group 1
    # strace -e recvmsg ip nexthop get id 101
    ...
    recvmsg(... [{nla_len=12, nla_type=NHA_GROUP},
                 [{id=1, weight=0, resvd1=0x69, resvd2=0x67}]] ...) = 52

The fields are reserved and therefore not currently used. But as they are, they
leak kernel memory, and the fact they are not just zero complicates repurposing
of the fields for new ends. Initialize the full structure.</Note>
    </Notes>
    <CVE>CVE-2024-42283</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Return non-zero value from tipc_udp_addr2str() on error

tipc_udp_addr2str() should return non-zero value if the UDP media
address is invalid. Otherwise, a buffer overflow access can occur in
tipc_media_addr_printf(). Fix this by returning 1 on an invalid UDP
media address.</Note>
    </Notes>
    <CVE>CVE-2024-42284</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 a use-after-free related to destroying CM IDs

iw_conn_req_handler() associates a new struct rdma_id_private (conn_id) with
an existing struct iw_cm_id (cm_id) as follows:

        conn_id-&gt;cm_id.iw = cm_id;
        cm_id-&gt;context = conn_id;
        cm_id-&gt;cm_handler = cma_iw_handler;

rdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Make
sure that cm_work_handler() does not trigger a use-after-free by only
freeing of the struct rdma_id_private after all pending work has finished.</Note>
    </Notes>
    <CVE>CVE-2024-42285</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qla2xxx: validate nvme_local_port correctly

The driver load failed with error message,

qla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef

and with a kernel crash,

	BUG: unable to handle kernel NULL pointer dereference at 0000000000000070
	Workqueue: events_unbound qla_register_fcport_fn [qla2xxx]
	RIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc]
	RSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282
	RAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000
	RDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000
	RBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030
	R10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4
	R13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8
	FS:  0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000
	CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
	CR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0
	Call Trace:
	qla_nvme_register_remote+0xeb/0x1f0 [qla2xxx]
	? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx]
	qla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx]
	qla_register_fcport_fn+0x54/0xc0 [qla2xxx]

Exit the qla_nvme_register_remote() function when qla_nvme_register_hba()
fails and correctly validate nvme_local_port.</Note>
    </Notes>
    <CVE>CVE-2024-42286</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qla2xxx: Complete command early within lock

A crash was observed while performing NPIV and FW reset,

 BUG: kernel NULL pointer dereference, address: 000000000000001c
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: 0000 1 PREEMPT_RT SMP NOPTI
 RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0
 RSP: 0018:ffffc90026f47b88 EFLAGS: 00010246
 RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000002
 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8881041130d0
 RBP: ffff8881041130d0 R08: 0000000000000000 R09: 0000000000000034
 R10: ffffc90026f47c48 R11: 0000000000000031 R12: 0000000000000000
 R13: 0000000000000000 R14: ffff8881565e4a20 R15: 0000000000000000
 FS: 00007f4c69ed3d00(0000) GS:ffff889faac80000(0000) knlGS:0000000000000000
 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 000000000000001c CR3: 0000000288a50002 CR4: 00000000007706e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 PKRU: 55555554
 Call Trace:
 &lt;TASK&gt;
 ? __die_body+0x1a/0x60
 ? page_fault_oops+0x16f/0x4a0
 ? do_user_addr_fault+0x174/0x7f0
 ? exc_page_fault+0x69/0x1a0
 ? asm_exc_page_fault+0x22/0x30
 ? dma_direct_unmap_sg+0x51/0x1e0
 ? preempt_count_sub+0x96/0xe0
 qla2xxx_qpair_sp_free_dma+0x29f/0x3b0 [qla2xxx]
 qla2xxx_qpair_sp_compl+0x60/0x80 [qla2xxx]
 __qla2x00_abort_all_cmds+0xa2/0x450 [qla2xxx]

The command completion was done early while aborting the commands in driver
unload path but outside lock to avoid the WARN_ON condition of performing
dma_free_attr within the lock. However this caused race condition while
command completion via multiple paths causing system crash.

Hence complete the command early in unload path but within the lock to
avoid race condition.</Note>
    </Notes>
    <CVE>CVE-2024-42287</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qla2xxx: Fix for possible memory corruption

Init Control Block is dereferenced incorrectly.  Correctly dereference ICB</Note>
    </Notes>
    <CVE>CVE-2024-42288</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qla2xxx: During vport delete send async logout explicitly

During vport delete, it is observed that during unload we hit a crash
because of stale entries in outstanding command array.  For all these stale
I/O entries, eh_abort was issued and aborted (fast_fail_io = 2009h) but
I/Os could not complete while vport delete is in process of deleting.

  BUG: kernel NULL pointer dereference, address: 000000000000001c
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: 0000 [#1] PREEMPT SMP NOPTI
  Workqueue: qla2xxx_wq qla_do_work [qla2xxx]
  RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0
  RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046
  RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001
  RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0
  RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8
  R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000
  R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000
  FS:  0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0
  Call Trace:
  &lt;TASK&gt;
  qla2xxx_qpair_sp_free_dma+0x417/0x4e0
  ? qla2xxx_qpair_sp_compl+0x10d/0x1a0
  ? qla2x00_status_entry+0x768/0x2830
  ? newidle_balance+0x2f0/0x430
  ? dequeue_entity+0x100/0x3c0
  ? qla24xx_process_response_queue+0x6a1/0x19e0
  ? __schedule+0x2d5/0x1140
  ? qla_do_work+0x47/0x60
  ? process_one_work+0x267/0x440
  ? process_one_work+0x440/0x440
  ? worker_thread+0x2d/0x3d0
  ? process_one_work+0x440/0x440
  ? kthread+0x156/0x180
  ? set_kthread_struct+0x50/0x50
  ? ret_from_fork+0x22/0x30
  &lt;/TASK&gt;

Send out async logout explicitly for all the ports during vport delete.</Note>
    </Notes>
    <CVE>CVE-2024-42289</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 a per-VF limit on number of FDIR filters

While the iavf driver adds a s/w limit (128) on the number of FDIR
filters that the VF can request, a malicious VF driver can request more
than that and exhaust the resources for other VFs.

Add a similar limit in ice.</Note>
    </Notes>
    <CVE>CVE-2024-42291</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

kobject_uevent: Fix OOB access within zap_modalias_env()

zap_modalias_env() wrongly calculates size of memory block to move, so
will cause OOB memory access issue if variable MODALIAS is not the last
one within its @env parameter, fixed by correcting size to memmove.</Note>
    </Notes>
    <CVE>CVE-2024-42292</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: handle inconsistent state in nilfs_btnode_create_block()

Syzbot reported that a buffer state inconsistency was detected in
nilfs_btnode_create_block(), triggering a kernel bug.

It is not appropriate to treat this inconsistency as a bug; it can occur
if the argument block address (the buffer index of the newly created
block) is a virtual block number and has been reallocated due to
corruption of the bitmap used to manage its allocation state.

So, modify nilfs_btnode_create_block() and its callers to treat it as a
possible filesystem error, rather than triggering a kernel bug.</Note>
    </Notes>
    <CVE>CVE-2024-42295</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dev/parport: fix the array out-of-bounds risk

Fixed array out-of-bounds issues caused by sprintf
by replacing it with snprintf for safer data copying,
ensuring the destination buffer is not overflowed.

Below is the stack trace I encountered during the actual issue:

[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:
Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport]
[ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:
QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2
[ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp
[ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun
PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024
[ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:
[ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0
[ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20
[ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c
[ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc
[ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38
[ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport]</Note>
    </Notes>
    <CVE>CVE-2024-42301</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/DPC: Fix use-after-free on concurrent DPC and hot-removal

Keith reports a use-after-free when a DPC event occurs concurrently to
hot-removal of the same portion of the hierarchy:

The dpc_handler() awaits readiness of the secondary bus below the
Downstream Port where the DPC event occurred.  To do so, it polls the
config space of the first child device on the secondary bus.  If that
child device is concurrently removed, accesses to its struct pci_dev
cause the kernel to oops.

That's because pci_bridge_wait_for_secondary_bus() neglects to hold a
reference on the child device.  Before v6.3, the function was only
called on resume from system sleep or on runtime resume.  Holding a
reference wasn't necessary back then because the pciehp IRQ thread
could never run concurrently.  (On resume from system sleep, IRQs are
not enabled until after the resume_noirq phase.  And runtime resume is
always awaited before a PCI device is removed.)

However starting with v6.3, pci_bridge_wait_for_secondary_bus() is also
called on a DPC event.  Commit 53b54ad074de ("PCI/DPC: Await readiness
of secondary bus after reset"), which introduced that, failed to
appreciate that pci_bridge_wait_for_secondary_bus() now needs to hold a
reference on the child device because dpc_handler() and pciehp may
indeed run concurrently.  The commit was backported to v5.10+ stable
kernels, so that's the oldest one affected.

Add the missing reference acquisition.

Abridged stack trace:

  BUG: unable to handle page fault for address: 00000000091400c0
  CPU: 15 PID: 2464 Comm: irq/53-pcie-dpc 6.9.0
  RIP: pci_bus_read_config_dword+0x17/0x50
  pci_dev_wait()
  pci_bridge_wait_for_secondary_bus()
  dpc_reset_link()
  pcie_do_recovery()
  dpc_handler()</Note>
    </Notes>
    <CVE>CVE-2024-42302</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: make sure the first directory block is not a hole

The syzbot constructs a directory that has no dirblock but is non-inline,
i.e. the first directory block is a hole. And no errors are reported when
creating files in this directory in the following flow.

    ext4_mknod
     ...
      ext4_add_entry
        // Read block 0
        ext4_read_dirblock(dir, block, DIRENT)
          bh = ext4_bread(NULL, inode, block, 0)
          if (!bh &amp;&amp; (type == INDEX || type == DIRENT_HTREE))
          // The first directory block is a hole
          // But type == DIRENT, so no error is reported.

After that, we get a directory block without '.' and '..' but with a valid
dentry. This may cause some code that relies on dot or dotdot (such as
make_indexed_dir()) to crash.

Therefore when ext4_read_dirblock() finds that the first directory block
is a hole report that the filesystem is corrupted and return an error to
avoid loading corrupted data from disk causing something bad.</Note>
    </Notes>
    <CVE>CVE-2024-42304</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: check dot and dotdot of dx_root before making dir indexed

Syzbot reports a issue as follows:
============================================
BUG: unable to handle page fault for address: ffffed11022e24fe
PGD 23ffee067 P4D 23ffee067 PUD 0
Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0
Call Trace:
 &lt;TASK&gt;
 make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341
 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451
 ext4_rename fs/ext4/namei.c:3936 [inline]
 ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214
[...]
============================================

The immediate cause of this problem is that there is only one valid dentry
for the block to be split during do_split, so split==0 results in out of
bounds accesses to the map triggering the issue.

    do_split
      unsigned split
      dx_make_map
       count = 1
      split = count/2 = 0;
      continued = hash2 == map[split - 1].hash;
       ---&gt; map[4294967295]

The maximum length of a filename is 255 and the minimum block size is 1024,
so it is always guaranteed that the number of entries is greater than or
equal to 2 when do_split() is called.

But syzbot's crafted image has no dot and dotdot in dir, and the dentry
distribution in dirblock is as follows:

  bus     dentry1          hole           dentry2           free
|xx--|xx-------------|...............|xx-------------|...............|
0   12 (8+248)=256  268     256     524 (8+256)=264 788     236     1024

So when renaming dentry1 increases its name_len length by 1, neither hole
nor free is sufficient to hold the new dentry, and make_indexed_dir() is
called.

In make_indexed_dir() it is assumed that the first two entries of the
dirblock must be dot and dotdot, so bus and dentry1 are left in dx_root
because they are treated as dot and dotdot, and only dentry2 is moved
to the new leaf block. That's why count is equal to 1.

Therefore add the ext4_check_dx_root() helper function to add more sanity
checks to dot and dotdot before starting the conversion to avoid the above
issue.</Note>
    </Notes>
    <CVE>CVE-2024-42305</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 using corrupted block bitmap buffer

When the filesystem block bitmap is corrupted, we detect the corruption
while loading the bitmap and fail the allocation with error. However the
next allocation from the same bitmap will notice the bitmap buffer is
already loaded and tries to allocate from the bitmap with mixed results
(depending on the exact nature of the bitmap corruption). Fix the
problem by using BH_verified bit to indicate whether the bitmap is valid
or not.</Note>
    </Notes>
    <CVE>CVE-2024-42306</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-42308</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/gma500: fix null pointer dereference in psb_intel_lvds_get_modes

In psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is
assigned to mode, which will lead to a possible NULL pointer dereference
on failure of drm_mode_duplicate(). Add a check to avoid npd.</Note>
    </Notes>
    <CVE>CVE-2024-42309</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes

In cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate()
is assigned to mode, which will lead to a NULL pointer dereference on
failure of drm_mode_duplicate(). Add a check to avoid npd.</Note>
    </Notes>
    <CVE>CVE-2024-42310</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hfs: fix to initialize fields of hfs_inode_info after hfs_alloc_inode()

Syzbot reports uninitialized value access issue as below:

loop0: detected capacity change from 0 to 64
=====================================================
BUG: KMSAN: uninit-value in hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30
 hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30
 d_revalidate fs/namei.c:862 [inline]
 lookup_fast+0x89e/0x8e0 fs/namei.c:1649
 walk_component fs/namei.c:2001 [inline]
 link_path_walk+0x817/0x1480 fs/namei.c:2332
 path_lookupat+0xd9/0x6f0 fs/namei.c:2485
 filename_lookup+0x22e/0x740 fs/namei.c:2515
 user_path_at_empty+0x8b/0x390 fs/namei.c:2924
 user_path_at include/linux/namei.h:57 [inline]
 do_mount fs/namespace.c:3689 [inline]
 __do_sys_mount fs/namespace.c:3898 [inline]
 __se_sys_mount+0x66b/0x810 fs/namespace.c:3875
 __x64_sys_mount+0xe4/0x140 fs/namespace.c:3875
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b

BUG: KMSAN: uninit-value in hfs_ext_read_extent fs/hfs/extent.c:196 [inline]
BUG: KMSAN: uninit-value in hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366
 hfs_ext_read_extent fs/hfs/extent.c:196 [inline]
 hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366
 block_read_full_folio+0x4ff/0x11b0 fs/buffer.c:2271
 hfs_read_folio+0x55/0x60 fs/hfs/inode.c:39
 filemap_read_folio+0x148/0x4f0 mm/filemap.c:2426
 do_read_cache_folio+0x7c8/0xd90 mm/filemap.c:3553
 do_read_cache_page mm/filemap.c:3595 [inline]
 read_cache_page+0xfb/0x2f0 mm/filemap.c:3604
 read_mapping_page include/linux/pagemap.h:755 [inline]
 hfs_btree_open+0x928/0x1ae0 fs/hfs/btree.c:78
 hfs_mdb_get+0x260c/0x3000 fs/hfs/mdb.c:204
 hfs_fill_super+0x1fb1/0x2790 fs/hfs/super.c:406
 mount_bdev+0x628/0x920 fs/super.c:1359
 hfs_mount+0xcd/0xe0 fs/hfs/super.c:456
 legacy_get_tree+0x167/0x2e0 fs/fs_context.c:610
 vfs_get_tree+0xdc/0x5d0 fs/super.c:1489
 do_new_mount+0x7a9/0x16f0 fs/namespace.c:3145
 path_mount+0xf98/0x26a0 fs/namespace.c:3475
 do_mount fs/namespace.c:3488 [inline]
 __do_sys_mount fs/namespace.c:3697 [inline]
 __se_sys_mount+0x919/0x9e0 fs/namespace.c:3674
 __ia32_sys_mount+0x15b/0x1b0 fs/namespace.c:3674
 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
 __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178
 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203
 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246
 entry_SYSENTER_compat_after_hwframe+0x70/0x82

Uninit was created at:
 __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590
 __alloc_pages_node include/linux/gfp.h:238 [inline]
 alloc_pages_node include/linux/gfp.h:261 [inline]
 alloc_slab_page mm/slub.c:2190 [inline]
 allocate_slab mm/slub.c:2354 [inline]
 new_slab+0x2d7/0x1400 mm/slub.c:2407
 ___slab_alloc+0x16b5/0x3970 mm/slub.c:3540
 __slab_alloc mm/slub.c:3625 [inline]
 __slab_alloc_node mm/slub.c:3678 [inline]
 slab_alloc_node mm/slub.c:3850 [inline]
 kmem_cache_alloc_lru+0x64d/0xb30 mm/slub.c:3879
 alloc_inode_sb include/linux/fs.h:3018 [inline]
 hfs_alloc_inode+0x5a/0xc0 fs/hfs/super.c:165
 alloc_inode+0x83/0x440 fs/inode.c:260
 new_inode_pseudo fs/inode.c:1005 [inline]
 new_inode+0x38/0x4f0 fs/inode.c:1031
 hfs_new_inode+0x61/0x1010 fs/hfs/inode.c:186
 hfs_mkdir+0x54/0x250 fs/hfs/dir.c:228
 vfs_mkdir+0x49a/0x700 fs/namei.c:4126
 do_mkdirat+0x529/0x810 fs/namei.c:4149
 __do_sys_mkdirat fs/namei.c:4164 [inline]
 __se_sys_mkdirat fs/namei.c:4162 [inline]
 __x64_sys_mkdirat+0xc8/0x120 fs/namei.c:4162
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b

It missed to initialize .tz_secondswest, .cached_start and .cached_blocks
fields in struct hfs_inode_info after hfs_alloc_inode(), fix it.</Note>
    </Notes>
    <CVE>CVE-2024-42311</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sysctl: always initialize i_uid/i_gid

Always initialize i_uid/i_gid inside the sysfs core so set_ownership()
can safely skip setting them.

Commit 5ec27ec735ba ("fs/proc/proc_sysctl.c: fix the default values of
i_uid/i_gid on /proc/sys inodes.") added defaults for i_uid/i_gid when
set_ownership() was not implemented. It also missed adjusting
net_ctl_set_ownership() to use the same default values in case the
computation of a better value failed.</Note>
    </Notes>
    <CVE>CVE-2024-42312</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 in vdec_close

There appears to be a possible use after free with vdec_close().
The firmware will add buffer release work to the work queue through
HFI callbacks as a normal part of decoding. Randomly closing the
decoder device from userspace during normal decoding can incur
a read after free for inst.

Fix it by cancelling the work in vdec_close.</Note>
    </Notes>
    <CVE>CVE-2024-42313</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 potential deadlock on __exfat_get_dentry_set

When accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-array
is allocated in __exfat_get_entry_set. The problem is that the bh-array is
allocated with GFP_KERNEL. It does not make sense. In the following cases,
a deadlock for sbi-&gt;s_lock between the two processes may occur.

       CPU0                CPU1
       ----                ----
  kswapd
   balance_pgdat
    lock(fs_reclaim)
                      exfat_iterate
                       lock(&amp;sbi-&gt;s_lock)
                       exfat_readdir
                        exfat_get_uniname_from_ext_entry
                         exfat_get_dentry_set
                          __exfat_get_dentry_set
                           kmalloc_array
                            ...
                            lock(fs_reclaim)
    ...
    evict
     exfat_evict_inode
      lock(&amp;sbi-&gt;s_lock)

To fix this, let's allocate bh-array with GFP_NOFS.</Note>
    </Notes>
    <CVE>CVE-2024-42315</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

landlock: Don't lose track of restrictions on cred_transfer

When a process' cred struct is replaced, this _almost_ always invokes
the cred_prepare LSM hook; but in one special case (when
KEYCTL_SESSION_TO_PARENT updates the parent's credentials), the
cred_transfer LSM hook is used instead.  Landlock only implements the
cred_prepare hook, not cred_transfer, so KEYCTL_SESSION_TO_PARENT causes
all information on Landlock restrictions to be lost.

This basically means that a process with the ability to use the fork()
and keyctl() syscalls can get rid of all Landlock restrictions on
itself.

Fix it by adding a cred_transfer hook that does the same thing as the
existing cred_prepare hook. (Implemented by having hook_cred_prepare()
call hook_cred_transfer() so that the two functions are less likely to
accidentally diverge in the future.)</Note>
    </Notes>
    <CVE>CVE-2024-42318</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mtk-cmdq: Move devm_mbox_controller_register() after devm_pm_runtime_enable()

When mtk-cmdq unbinds, a WARN_ON message with condition
pm_runtime_get_sync() &lt; 0 occurs.

According to the call tracei below:
  cmdq_mbox_shutdown
  mbox_free_channel
  mbox_controller_unregister
  __devm_mbox_controller_unregister
  ...

The root cause can be deduced to be calling pm_runtime_get_sync() after
calling pm_runtime_disable() as observed below:
1. CMDQ driver uses devm_mbox_controller_register() in cmdq_probe()
   to bind the cmdq device to the mbox_controller, so
   devm_mbox_controller_unregister() will automatically unregister
   the device bound to the mailbox controller when the device-managed
   resource is removed. That means devm_mbox_controller_unregister()
   and cmdq_mbox_shoutdown() will be called after cmdq_remove().
2. CMDQ driver also uses devm_pm_runtime_enable() in cmdq_probe() after
   devm_mbox_controller_register(), so that devm_pm_runtime_disable()
   will be called after cmdq_remove(), but before
   devm_mbox_controller_unregister().

To fix this problem, cmdq_probe() needs to move
devm_mbox_controller_register() after devm_pm_runtime_enable() to make
devm_pm_runtime_disable() be called after
devm_mbox_controller_unregister().</Note>
    </Notes>
    <CVE>CVE-2024-42319</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/dasd: fix error checks in dasd_copy_pair_store()

dasd_add_busid() can return an error via ERR_PTR() if an allocation
fails. However, two callsites in dasd_copy_pair_store() do not check
the result, potentially resulting in a NULL pointer dereference. Fix
this by checking the result with IS_ERR() and returning the error up
the stack.</Note>
    </Notes>
    <CVE>CVE-2024-42320</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipvs: properly dereference pe in ip_vs_add_service

Use pe directly to resolve sparse warning:

  net/netfilter/ipvs/ip_vs_ctl.c:1471:27: warning: dereference of noderef expression</Note>
    </Notes>
    <CVE>CVE-2024-42322</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">REXML is an XML toolkit for Ruby. The REXML gem before 3.3.6 has a DoS vulnerability when it parses an XML that has many deep elements that have same local name attributes. If you need to parse untrusted XMLs with tree parser API like REXML::Document.new, you may be impacted to this vulnerability. If you use other parser APIs such as stream parser API and SAX2 parser API, this vulnerability is not affected. The REXML gem 3.3.6 or later include the patch to fix the vulnerability.</Note>
    </Notes>
    <CVE>CVE-2024-43398</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

scsi: lpfc: Revise lpfc_prep_embed_io routine with proper endian macro usages

On big endian architectures, it is possible to run into a memory out of
bounds pointer dereference when FCP targets are zoned.

In lpfc_prep_embed_io, the memcpy(ptr, fcp_cmnd, sgl-&gt;sge_len) is
referencing a little endian formatted sgl-&gt;sge_len value.  So, the memcpy
can cause big endian systems to crash.

Redefine the *sgl ptr as a struct sli4_sge_le to make it clear that we are
referring to a little endian formatted data structure.  And, update the
routine with proper le32_to_cpu macro usages.</Note>
    </Notes>
    <CVE>CVE-2024-43816</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: missing check virtio

Two missing check in virtio_net_hdr_to_skb() allowed syzbot
to crash kernels again

1. After the skb_segment function the buffer may become non-linear
(nr_frags != 0), but since the SKBTX_SHARED_FRAG flag is not set anywhere
the __skb_linearize function will not be executed, then the buffer will
remain non-linear. Then the condition (offset &gt;= skb_headlen(skb))
becomes true, which causes WARN_ON_ONCE in skb_checksum_help.

2. The struct sk_buff and struct virtio_net_hdr members must be
mathematically related.
(gso_size) must be greater than (needed) otherwise WARN_ON_ONCE.
(remainder) must be greater than (needed) otherwise WARN_ON_ONCE.
(remainder) may be 0 if division is without remainder.

offset+2 (4191) &gt; skb_headlen() (1116)
WARNING: CPU: 1 PID: 5084 at net/core/dev.c:3303 skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303
Modules linked in:
CPU: 1 PID: 5084 Comm: syz-executor336 Not tainted 6.7.0-rc3-syzkaller-00014-gdf60cee26a2e #0
Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
RIP: 0010:skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303
Code: 89 e8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 52 01 00 00 44 89 e2 2b 53 74 4c 89 ee 48 c7 c7 40 57 e9 8b e8 af 8f dd f8 90 &lt;0f&gt; 0b 90 90 e9 87 fe ff ff e8 40 0f 6e f9 e9 4b fa ff ff 48 89 ef
RSP: 0018:ffffc90003a9f338 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff888025125780 RCX: ffffffff814db209
RDX: ffff888015393b80 RSI: ffffffff814db216 RDI: 0000000000000001
RBP: ffff8880251257f4 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000045c
R13: 000000000000105f R14: ffff8880251257f0 R15: 000000000000105d
FS:  0000555555c24380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000002000f000 CR3: 0000000023151000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 ip_do_fragment+0xa1b/0x18b0 net/ipv4/ip_output.c:777
 ip_fragment.constprop.0+0x161/0x230 net/ipv4/ip_output.c:584
 ip_finish_output_gso net/ipv4/ip_output.c:286 [inline]
 __ip_finish_output net/ipv4/ip_output.c:308 [inline]
 __ip_finish_output+0x49c/0x650 net/ipv4/ip_output.c:295
 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323
 NF_HOOK_COND include/linux/netfilter.h:303 [inline]
 ip_output+0x13b/0x2a0 net/ipv4/ip_output.c:433
 dst_output include/net/dst.h:451 [inline]
 ip_local_out+0xaf/0x1a0 net/ipv4/ip_output.c:129
 iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82
 ipip6_tunnel_xmit net/ipv6/sit.c:1034 [inline]
 sit_tunnel_xmit+0xed2/0x28f0 net/ipv6/sit.c:1076
 __netdev_start_xmit include/linux/netdevice.h:4940 [inline]
 netdev_start_xmit include/linux/netdevice.h:4954 [inline]
 xmit_one net/core/dev.c:3545 [inline]
 dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3561
 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4346
 dev_queue_xmit include/linux/netdevice.h:3134 [inline]
 packet_xmit+0x257/0x380 net/packet/af_packet.c:276
 packet_snd net/packet/af_packet.c:3087 [inline]
 packet_sendmsg+0x24ca/0x5240 net/packet/af_packet.c:3119
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg+0xd5/0x180 net/socket.c:745
 __sys_sendto+0x255/0x340 net/socket.c:2190
 __do_sys_sendto net/socket.c:2202 [inline]
 __se_sys_sendto net/socket.c:2198 [inline]
 __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82
 entry_SYSCALL_64_after_hwframe+0x63/0x6b

Found by Linux Verification Center (linuxtesting.org) with Syzkaller</Note>
    </Notes>
    <CVE>CVE-2024-43817</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: amd: Adjust error handling in case of absent codec device

acpi_get_first_physical_node() can return NULL in several cases (no such
device, ACPI table error, reference count drop to 0, etc).
Existing check just emit error message, but doesn't perform return.
Then this NULL pointer is passed to devm_acpi_dev_add_driver_gpios()
where it is dereferenced.

Adjust this error handling by adding error code return.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2024-43818</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: s390: Reject memory region operations for ucontrol VMs

This change rejects the KVM_SET_USER_MEMORY_REGION and
KVM_SET_USER_MEMORY_REGION2 ioctls when called on a ucontrol VM.
This is necessary since ucontrol VMs have kvm-&gt;arch.gmap set to 0 and
would thus result in a null pointer dereference further in.
Memory management needs to be performed in userspace and using the
ioctls KVM_S390_UCAS_MAP and KVM_S390_UCAS_UNMAP.

Also improve s390 specific documentation for KVM_SET_USER_MEMORY_REGION
and KVM_SET_USER_MEMORY_REGION2.

[frankja@linux.ibm.com: commit message spelling fix, subject prefix fix]</Note>
    </Notes>
    <CVE>CVE-2024-43819</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix a possible null pointer dereference

In function lpfc_xcvr_data_show, the memory allocation with kmalloc might
fail, thereby making rdp_context a null pointer. In the following context
and functions that use this pointer, there are dereferencing operations,
leading to null pointer dereference.

To fix this issue, a null pointer check should be added. If it is null,
use scnprintf to notify the user and return len.</Note>
    </Notes>
    <CVE>CVE-2024-43821</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 NULL pointer dereference in case of DT error in ks_pcie_setup_rc_app_regs()

If IORESOURCE_MEM is not provided in Device Tree due to
any error, resource_list_first_type() will return NULL and
pci_parse_request_of_pci_ranges() will just emit a warning.

This will cause a NULL pointer dereference. Fix this bug by adding NULL
return check.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2024-43823</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 infinite loop when replaying fast_commit

When doing fast_commit replay an infinite loop may occur due to an
uninitialized extent_status struct.  ext4_ext_determine_insert_hole() does
not detect the replay and calls ext4_es_find_extent_range(), which will
return immediately without initializing the 'es' variable.

Because 'es' contains garbage, an integer overflow may happen causing an
infinite loop in this function, easily reproducible using fstest generic/039.

This commit fixes this issue by unconditionally initializing the structure
in function ext4_es_find_extent_range().

Thanks to Zhang Yi, for figuring out the real problem!</Note>
    </Notes>
    <CVE>CVE-2024-43828</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/qxl: Add check for drm_cvt_mode

Add check for the return value of drm_cvt_mode() and return the error if
it fails in order to avoid NULL pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2024-43829</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

leds: trigger: Unregister sysfs attributes before calling deactivate()

Triggers which have trigger specific sysfs attributes typically store
related data in trigger-data allocated by the activate() callback and
freed by the deactivate() callback.

Calling device_remove_groups() after calling deactivate() leaves a window
where the sysfs attributes show/store functions could be called after
deactivation and then operate on the just freed trigger-data.

Move the device_remove_groups() call to before deactivate() to close
this race window.

This also makes the deactivation path properly do things in reverse order
of the activation path which calls the activate() callback before calling
device_add_groups().</Note>
    </Notes>
    <CVE>CVE-2024-43830</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Handle invalid decoder vsi

Handle an invalid decoder vsi in vpu_dec_init to ensure the decoder vsi
is valid for future use.</Note>
    </Notes>
    <CVE>CVE-2024-43831</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xdp: fix invalid wait context of page_pool_destroy()

If the driver uses a page pool, it creates a page pool with
page_pool_create().
The reference count of page pool is 1 as default.
A page pool will be destroyed only when a reference count reaches 0.
page_pool_destroy() is used to destroy page pool, it decreases a
reference count.
When a page pool is destroyed, -&gt;disconnect() is called, which is
mem_allocator_disconnect().
This function internally acquires mutex_lock().

If the driver uses XDP, it registers a memory model with
xdp_rxq_info_reg_mem_model().
The xdp_rxq_info_reg_mem_model() internally increases a page pool
reference count if a memory model is a page pool.
Now the reference count is 2.

To destroy a page pool, the driver should call both page_pool_destroy()
and xdp_unreg_mem_model().
The xdp_unreg_mem_model() internally calls page_pool_destroy().
Only page_pool_destroy() decreases a reference count.

If a driver calls page_pool_destroy() then xdp_unreg_mem_model(), we
will face an invalid wait context warning.
Because xdp_unreg_mem_model() calls page_pool_destroy() with
rcu_read_lock().
The page_pool_destroy() internally acquires mutex_lock().

Splat looks like:
=============================
[ BUG: Invalid wait context ]
6.10.0-rc6+ #4 Tainted: G W
-----------------------------
ethtool/1806 is trying to lock:
ffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150
other info that might help us debug this:
context-{5:5}
3 locks held by ethtool/1806:
stack backtrace:
CPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fed
Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021
Call Trace:
&lt;TASK&gt;
dump_stack_lvl+0x7e/0xc0
__lock_acquire+0x1681/0x4de0
? _printk+0x64/0xe0
? __pfx_mark_lock.part.0+0x10/0x10
? __pfx___lock_acquire+0x10/0x10
lock_acquire+0x1b3/0x580
? mem_allocator_disconnect+0x73/0x150
? __wake_up_klogd.part.0+0x16/0xc0
? __pfx_lock_acquire+0x10/0x10
? dump_stack_lvl+0x91/0xc0
__mutex_lock+0x15c/0x1690
? mem_allocator_disconnect+0x73/0x150
? __pfx_prb_read_valid+0x10/0x10
? mem_allocator_disconnect+0x73/0x150
? __pfx_llist_add_batch+0x10/0x10
? console_unlock+0x193/0x1b0
? lockdep_hardirqs_on+0xbe/0x140
? __pfx___mutex_lock+0x10/0x10
? tick_nohz_tick_stopped+0x16/0x90
? __irq_work_queue_local+0x1e5/0x330
? irq_work_queue+0x39/0x50
? __wake_up_klogd.part.0+0x79/0xc0
? mem_allocator_disconnect+0x73/0x150
mem_allocator_disconnect+0x73/0x150
? __pfx_mem_allocator_disconnect+0x10/0x10
? mark_held_locks+0xa5/0xf0
? rcu_is_watching+0x11/0xb0
page_pool_release+0x36e/0x6d0
page_pool_destroy+0xd7/0x440
xdp_unreg_mem_model+0x1a7/0x2a0
? __pfx_xdp_unreg_mem_model+0x10/0x10
? kfree+0x125/0x370
? bnxt_free_ring.isra.0+0x2eb/0x500
? bnxt_free_mem+0x5ac/0x2500
xdp_rxq_info_unreg+0x4a/0xd0
bnxt_free_mem+0x1356/0x2500
bnxt_close_nic+0xf0/0x3b0
? __pfx_bnxt_close_nic+0x10/0x10
? ethnl_parse_bit+0x2c6/0x6d0
? __pfx___nla_validate_parse+0x10/0x10
? __pfx_ethnl_parse_bit+0x10/0x10
bnxt_set_features+0x2a8/0x3e0
__netdev_update_features+0x4dc/0x1370
? ethnl_parse_bitset+0x4ff/0x750
? __pfx_ethnl_parse_bitset+0x10/0x10
? __pfx___netdev_update_features+0x10/0x10
? mark_held_locks+0xa5/0xf0
? _raw_spin_unlock_irqrestore+0x42/0x70
? __pm_runtime_resume+0x7d/0x110
ethnl_set_features+0x32d/0xa20

To fix this problem, it uses rhashtable_lookup_fast() instead of
rhashtable_lookup() with rcu_read_lock().
Using xa without rcu_read_lock() here is safe.
xa is freed by __xdp_mem_allocator_rcu_free() and this is called by
call_rcu() of mem_xa_remove().
The mem_xa_remove() is called by page_pool_destroy() if a reference
count reaches 0.
The xa is already protected by the reference count mechanism well in the
control plane.
So removing rcu_read_lock() for page_pool_destroy() is safe.</Note>
    </Notes>
    <CVE>CVE-2024-43834</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 null pointer dereference in resolve_prog_type() for BPF_PROG_TYPE_EXT

When loading a EXT program without specifying `attr-&gt;attach_prog_fd`,
the `prog-&gt;aux-&gt;dst_prog` will be null. At this time, calling
resolve_prog_type() anywhere will result in a null pointer dereference.

Example stack trace:

[    8.107863] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004
[    8.108262] Mem abort info:
[    8.108384]   ESR = 0x0000000096000004
[    8.108547]   EC = 0x25: DABT (current EL), IL = 32 bits
[    8.108722]   SET = 0, FnV = 0
[    8.108827]   EA = 0, S1PTW = 0
[    8.108939]   FSC = 0x04: level 0 translation fault
[    8.109102] Data abort info:
[    8.109203]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[    8.109399]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[    8.109614]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[    8.109836] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101354000
[    8.110011] [0000000000000004] pgd=0000000000000000, p4d=0000000000000000
[    8.112624] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
[    8.112783] Modules linked in:
[    8.113120] CPU: 0 PID: 99 Comm: may_access_dire Not tainted 6.10.0-rc3-next-20240613-dirty #1
[    8.113230] Hardware name: linux,dummy-virt (DT)
[    8.113390] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    8.113429] pc : may_access_direct_pkt_data+0x24/0xa0
[    8.113746] lr : add_subprog_and_kfunc+0x634/0x8e8
[    8.113798] sp : ffff80008283b9f0
[    8.113813] x29: ffff80008283b9f0 x28: ffff800082795048 x27: 0000000000000001
[    8.113881] x26: ffff0000c0bb2600 x25: 0000000000000000 x24: 0000000000000000
[    8.113897] x23: ffff0000c1134000 x22: 000000000001864f x21: ffff0000c1138000
[    8.113912] x20: 0000000000000001 x19: ffff0000c12b8000 x18: ffffffffffffffff
[    8.113929] x17: 0000000000000000 x16: 0000000000000000 x15: 0720072007200720
[    8.113944] x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720
[    8.113958] x11: 0720072007200720 x10: 0000000000f9fca4 x9 : ffff80008021f4e4
[    8.113991] x8 : 0101010101010101 x7 : 746f72705f6d656d x6 : 000000001e0e0f5f
[    8.114006] x5 : 000000000001864f x4 : ffff0000c12b8000 x3 : 000000000000001c
[    8.114020] x2 : 0000000000000002 x1 : 0000000000000000 x0 : 0000000000000000
[    8.114126] Call trace:
[    8.114159]  may_access_direct_pkt_data+0x24/0xa0
[    8.114202]  bpf_check+0x3bc/0x28c0
[    8.114214]  bpf_prog_load+0x658/0xa58
[    8.114227]  __sys_bpf+0xc50/0x2250
[    8.114240]  __arm64_sys_bpf+0x28/0x40
[    8.114254]  invoke_syscall.constprop.0+0x54/0xf0
[    8.114273]  do_el0_svc+0x4c/0xd8
[    8.114289]  el0_svc+0x3c/0x140
[    8.114305]  el0t_64_sync_handler+0x134/0x150
[    8.114331]  el0t_64_sync+0x168/0x170
[    8.114477] Code: 7100707f 54000081 f9401c00 f9403800 (b9400403)
[    8.118672] ---[ end trace 0000000000000000 ]---

One way to fix it is by forcing `attach_prog_fd` non-empty when
bpf_prog_load(). But this will lead to `libbpf_probe_bpf_prog_type`
API broken which use verifier log to probe prog type and will log
nothing if we reject invalid EXT prog before bpf_check().

Another way is by adding null check in resolve_prog_type().

The issue was introduced by commit 4a9c7bbe2ed4 ("bpf: Resolve to
prog-&gt;aux-&gt;dst_prog-&gt;type only for BPF_PROG_TYPE_EXT") which wanted
to correct type resolution for BPF_PROG_TYPE_TRACING programs. Before
that, the type resolution of BPF_PROG_TYPE_EXT prog actually follows
the logic below:

  prog-&gt;aux-&gt;dst_prog ? prog-&gt;aux-&gt;dst_prog-&gt;type : prog-&gt;type;

It implies that when EXT program is not yet attached to `dst_prog`,
the prog type should be EXT itself. This code worked fine in the past.
So just keep using it.

Fix this by returning `prog-&gt;type` for BPF_PROG_TYPE_EXT if `dst_prog`
is not present in resolve_prog_type().</Note>
    </Notes>
    <CVE>CVE-2024-43837</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bna: adjust 'name' buf size of bna_tcb and bna_ccb structures

To have enough space to write all possible sprintf() args. Currently
'name' size is 16, but the first '%s' specifier may already need at
least 16 characters, since 'bnad-&gt;netdev-&gt;name' is used there.

For '%d' specifiers, assume that they require:
 * 1 char for 'tx_id + tx_info-&gt;tcb[i]-&gt;id' sum, BNAD_MAX_TXQ_PER_TX is 8
 * 2 chars for 'rx_id + rx_info-&gt;rx_ctrl[i].ccb-&gt;id', BNAD_MAX_RXP_PER_RX
   is 16

And replace sprintf with snprintf.

Detected using the static analysis tool - Svace.</Note>
    </Notes>
    <CVE>CVE-2024-43839</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: virt_wifi: avoid reporting connection success with wrong SSID

When user issues a connection with a different SSID than the one
virt_wifi has advertised, the __cfg80211_connect_result() will
trigger the warning: WARN_ON(bss_not_found).

The issue is because the connection code in virt_wifi does not
check the SSID from user space (it only checks the BSSID), and
virt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS
even if the SSID is different from the one virt_wifi has advertised.
Eventually cfg80211 won't be able to find the cfg80211_bss and generate
the warning.

Fixed it by checking the SSID (from user space) in the connection code.</Note>
    </Notes>
    <CVE>CVE-2024-43841</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix array index mistake in rtw89_sta_info_get_iter()

In rtw89_sta_info_get_iter() 'status-&gt;he_gi' is compared to array size.
But then 'rate-&gt;he_gi' is used as array index instead of 'status-&gt;he_gi'.
This can lead to go beyond array boundaries in case of 'rate-&gt;he_gi' is
not equal to 'status-&gt;he_gi' and is bigger than array size. Looks like
"copy-paste" mistake.

Fix this mistake by replacing 'rate-&gt;he_gi' with 'status-&gt;he_gi'.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2024-43842</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: objagg: Fix general protection fault

The library supports aggregation of objects into other objects only if
the parent object does not have a parent itself. That is, nesting is not
supported.

Aggregation happens in two cases: Without and with hints, where hints
are a pre-computed recommendation on how to aggregate the provided
objects.

Nesting is not possible in the first case due to a check that prevents
it, but in the second case there is no check because the assumption is
that nesting cannot happen when creating objects based on hints. The
violation of this assumption leads to various warnings and eventually to
a general protection fault [1].

Before fixing the root cause, error out when nesting happens and warn.

[1]
general protection fault, probably for non-canonical address 0xdead000000000d90: 0000 [#1] PREEMPT SMP PTI
CPU: 1 PID: 1083 Comm: kworker/1:9 Tainted: G        W          6.9.0-rc6-custom-gd9b4f1cca7fb #7
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
RIP: 0010:mlxsw_sp_acl_erp_bf_insert+0x25/0x80
[...]
Call Trace:
 &lt;TASK&gt;
 mlxsw_sp_acl_atcam_entry_add+0x256/0x3c0
 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0
 mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270
 mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510
 process_one_work+0x151/0x370
 worker_thread+0x2cb/0x3e0
 kthread+0xd0/0x100
 ret_from_fork+0x34/0x50
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-43846</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: pdr: protect locator_addr with the main mutex

If the service locator server is restarted fast enough, the PDR can
rewrite locator_addr fields concurrently. Protect them by placing
modification of those fields under the main pdr-&gt;lock.</Note>
    </Notes>
    <CVE>CVE-2024-43849</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cgroup/cpuset: Prevent UAF in proc_cpuset_show()

An UAF can happen when /proc/cpuset is read as reported in [1].

This can be reproduced by the following methods:
1.add an mdelay(1000) before acquiring the cgroup_lock In the
 cgroup_path_ns function.
2.$cat /proc/&lt;pid&gt;/cpuset   repeatly.
3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/
$umount /sys/fs/cgroup/cpuset/   repeatly.

The race that cause this bug can be shown as below:

(umount)		|	(cat /proc/&lt;pid&gt;/cpuset)
css_release		|	proc_cpuset_show
css_release_work_fn	|	css = task_get_css(tsk, cpuset_cgrp_id);
css_free_rwork_fn	|	cgroup_path_ns(css-&gt;cgroup, ...);
cgroup_destroy_root	|	mutex_lock(&amp;cgroup_mutex);
rebind_subsystems	|
cgroup_free_root 	|
			|	// cgrp was freed, UAF
			|	cgroup_path_ns_locked(cgrp,..);

When the cpuset is initialized, the root node top_cpuset.css.cgrp
will point to &amp;cgrp_dfl_root.cgrp. In cgroup v1, the mount operation will
allocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated
&amp;cgroup_root.cgrp. When the umount operation is executed,
top_cpuset.css.cgrp will be rebound to &amp;cgrp_dfl_root.cgrp.

The problem is that when rebinding to cgrp_dfl_root, there are cases
where the cgroup_root allocated by setting up the root for cgroup v1
is cached. This could lead to a Use-After-Free (UAF) if it is
subsequently freed. The descendant cgroups of cgroup v1 can only be
freed after the css is released. However, the css of the root will never
be released, yet the cgroup_root should be freed when it is unmounted.
This means that obtaining a reference to the css of the root does
not guarantee that css.cgrp-&gt;root will not be freed.

Fix this problem by using rcu_read_lock in proc_cpuset_show().
As cgroup_root is kfree_rcu after commit d23b5c577715
("cgroup: Make operations on the cgroup root_list RCU safe"),
css-&gt;cgroup won't be freed during the critical section.
To call cgroup_path_ns_locked, css_set_lock is needed, so it is safe to
replace task_get_css with task_css.

[1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd</Note>
    </Notes>
    <CVE>CVE-2024-43853</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: initialize integrity buffer to zero before writing it to media

Metadata added by bio_integrity_prep is using plain kmalloc, which leads
to random kernel memory being written media.  For PI metadata this is
limited to the app tag that isn't used by kernel generated metadata,
but for non-PI metadata the entire buffer leaks kernel memory.

Fix this by adding the __GFP_ZERO flag to allocations for writes.</Note>
    </Notes>
    <CVE>CVE-2024-43854</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix call order in dmam_free_coherent

dmam_free_coherent() frees a DMA allocation, which makes the
freed vaddr available for reuse, then calls devres_destroy()
to remove and free the data structure used to track the DMA
allocation. Between the two calls, it is possible for a
concurrent task to make an allocation with the same vaddr
and add it to the devres list.

If this happens, there will be two entries in the devres list
with the same vaddr and devres_destroy() can free the wrong
entry, triggering the WARN_ON() in dmam_match.

Fix by destroying the devres entry before freeing the DMA
allocation.

  kokonut //net/encryption
    http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03</Note>
    </Notes>
    <CVE>CVE-2024-43856</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 array-index-out-of-bounds in diFree</Note>
    </Notes>
    <CVE>CVE-2024-43858</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: imx_rproc: Skip over memory region when node value is NULL

In imx_rproc_addr_init() "nph = of_count_phandle_with_args()" just counts
number of phandles. But phandles may be empty. So of_parse_phandle() in
the parsing loop (0 &lt; a &lt; nph) may return NULL which is later dereferenced.
Adjust this issue by adding NULL-return check.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

[Fixed title to fit within the prescribed 70-75 charcters]</Note>
    </Notes>
    <CVE>CVE-2024-43860</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qmi_wwan: fix memory leak for not ip packets

Free the unused skb when not ip packets arrive.</Note>
    </Notes>
    <CVE>CVE-2024-43861</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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/vmwgfx: Fix a deadlock in dma buf fence polling

Introduce a version of the fence ops that on release doesn't remove
the fence from the pending list, and thus doesn't require a lock to
fix poll-&gt;fence wait-&gt;fence unref deadlocks.

vmwgfx overwrites the wait callback to iterate over the list of all
fences and update their status, to do that it holds a lock to prevent
the list modifcations from other threads. The fence destroy callback
both deletes the fence and removes it from the list of pending
fences, for which it holds a lock.

dma buf polling cb unrefs a fence after it's been signaled: so the poll
calls the wait, which signals the fences, which are being destroyed.
The destruction tries to acquire the lock on the pending fences list
which it can never get because it's held by the wait from which it
was called.

Old bug, but not a lot of userspace apps were using dma-buf polling
interfaces. Fix those, in particular this fixes KDE stalls/deadlock.</Note>
    </Notes>
    <CVE>CVE-2024-43863</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Always drain health in shutdown callback

There is no point in recovery during device shutdown. if health
work started need to wait for it to avoid races and NULL pointer
access.

Hence, drain health WQ on shutdown callback.</Note>
    </Notes>
    <CVE>CVE-2024-43866</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: prime: fix refcount underflow

Calling nouveau_bo_ref() on a nouveau_bo without initializing it (and
hence the backing ttm_bo) leads to a refcount underflow.

Instead of calling nouveau_bo_ref() in the unwind path of
drm_gem_object_init(), clean things up manually.

(cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)</Note>
    </Notes>
    <CVE>CVE-2024-43867</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

devres: Fix memory leakage caused by driver API devm_free_percpu()

It will cause memory leakage when use driver API devm_free_percpu()
to free memory allocated by devm_alloc_percpu(), fixed by using
devres_release() instead of devres_destroy() within devm_free_percpu().</Note>
    </Notes>
    <CVE>CVE-2024-43871</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 soft lockup under heavy CEQE load

CEQEs are handled in interrupt handler currently. This may cause the
CPU core staying in interrupt context too long and lead to soft lockup
under heavy load.

Handle CEQEs in BH workqueue and set an upper limit for the number of
CEQE handled by a single call of work handler.</Note>
    </Notes>
    <CVE>CVE-2024-43872</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/vsock: always initialize seqpacket_allow

There are two issues around seqpacket_allow:
1. seqpacket_allow is not initialized when socket is
   created. Thus if features are never set, it will be
   read uninitialized.
2. if VIRTIO_VSOCK_F_SEQPACKET is set and then cleared,
   then seqpacket_allow will not be cleared appropriately
   (existing apps I know about don't usually do this but
    it's legal and there's no way to be sure no one relies
    on this).

To fix:
	- initialize seqpacket_allow after allocation
	- set it unconditionally in set_features</Note>
    </Notes>
    <CVE>CVE-2024-43873</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()

Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in
cfg80211_calculate_bitrate_he(), leading to below warning:

kernel: invalid HE MCS: bw:6, ru:6
kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211]

Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.</Note>
    </Notes>
    <CVE>CVE-2024-43879</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_acl_erp: Fix object nesting warning

ACLs in Spectrum-2 and newer ASICs can reside in the algorithmic TCAM
(A-TCAM) or in the ordinary circuit TCAM (C-TCAM). The former can
contain more ACLs (i.e., tc filters), but the number of masks in each
region (i.e., tc chain) is limited.

In order to mitigate the effects of the above limitation, the device
allows filters to share a single mask if their masks only differ in up
to 8 consecutive bits. For example, dst_ip/25 can be represented using
dst_ip/24 with a delta of 1 bit. The C-TCAM does not have a limit on the
number of masks being used (and therefore does not support mask
aggregation), but can contain a limited number of filters.

The driver uses the "objagg" library to perform the mask aggregation by
passing it objects that consist of the filter's mask and whether the
filter is to be inserted into the A-TCAM or the C-TCAM since filters in
different TCAMs cannot share a mask.

The set of created objects is dependent on the insertion order of the
filters and is not necessarily optimal. Therefore, the driver will
periodically ask the library to compute a more optimal set ("hints") by
looking at all the existing objects.

When the library asks the driver whether two objects can be aggregated
the driver only compares the provided masks and ignores the A-TCAM /
C-TCAM indication. This is the right thing to do since the goal is to
move as many filters as possible to the A-TCAM. The driver also forbids
two identical masks from being aggregated since this can only happen if
one was intentionally put in the C-TCAM to avoid a conflict in the
A-TCAM.

The above can result in the following set of hints:

H1: {mask X, A-TCAM} -&gt; H2: {mask Y, A-TCAM} // X is Y + delta
H3: {mask Y, C-TCAM} -&gt; H4: {mask Z, A-TCAM} // Y is Z + delta

After getting the hints from the library the driver will start migrating
filters from one region to another while consulting the computed hints
and instructing the device to perform a lookup in both regions during
the transition.

Assuming a filter with mask X is being migrated into the A-TCAM in the
new region, the hints lookup will return H1. Since H2 is the parent of
H1, the library will try to find the object associated with it and
create it if necessary in which case another hints lookup (recursive)
will be performed. This hints lookup for {mask Y, A-TCAM} will either
return H2 or H3 since the driver passes the library an object comparison
function that ignores the A-TCAM / C-TCAM indication.

This can eventually lead to nested objects which are not supported by
the library [1].

Fix by removing the object comparison function from both the driver and
the library as the driver was the only user. That way the lookup will
only return exact matches.

I do not have a reliable reproducer that can reproduce the issue in a
timely manner, but before the fix the issue would reproduce in several
minutes and with the fix it does not reproduce in over an hour.

Note that the current usefulness of the hints is limited because they
include the C-TCAM indication and represent aggregation that cannot
actually happen. This will be addressed in net-next.

[1]
WARNING: CPU: 0 PID: 153 at lib/objagg.c:170 objagg_obj_parent_assign+0xb5/0xd0
Modules linked in:
CPU: 0 PID: 153 Comm: kworker/0:18 Not tainted 6.9.0-rc6-custom-g70fbc2c1c38b #42
Hardware name: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
RIP: 0010:objagg_obj_parent_assign+0xb5/0xd0
[...]
Call Trace:
 &lt;TASK&gt;
 __objagg_obj_get+0x2bb/0x580
 objagg_obj_get+0xe/0x80
 mlxsw_sp_acl_erp_mask_get+0xb5/0xf0
 mlxsw_sp_acl_atcam_entry_add+0xe8/0x3c0
 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0
 mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270
 mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510
 process_one_work+0x151/0x370</Note>
    </Notes>
    <CVE>CVE-2024-43880</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

exec: Fix ToCToU between perm check and set-uid/gid usage

When opening a file for exec via do_filp_open(), permission checking is
done against the file's metadata at that moment, and on success, a file
pointer is passed back. Much later in the execve() code path, the file
metadata (specifically mode, uid, and gid) is used to determine if/how
to set the uid and gid. However, those values may have changed since the
permissions check, meaning the execution may gain unintended privileges.

For example, if a file could change permissions from executable and not
set-id:

---------x 1 root root 16048 Aug  7 13:16 target

to set-id and non-executable:

---S------ 1 root root 16048 Aug  7 13:16 target

it is possible to gain root privileges when execution should have been
disallowed.

While this race condition is rare in real-world scenarios, it has been
observed (and proven exploitable) when package managers are updating
the setuid bits of installed programs. Such files start with being
world-executable but then are adjusted to be group-exec with a set-uid
bit. For example, "chmod o-x,u+s target" makes "target" executable only
by uid "root" and gid "cdrom", while also becoming setuid-root:

-rwxr-xr-x 1 root cdrom 16048 Aug  7 13:16 target

becomes:

-rwsr-xr-- 1 root cdrom 16048 Aug  7 13:16 target

But racing the chmod means users without group "cdrom" membership can
get the permission to execute "target" just before the chmod, and when
the chmod finishes, the exec reaches brpm_fill_uid(), and performs the
setuid to root, violating the expressed authorization of "only cdrom
group members can setuid to root".

Re-check that we still have execute permissions in case the metadata
has changed. It would be better to keep a copy from the perm-check time,
but until we can do that refactoring, the least-bad option is to do a
full inode_permission() call (under inode lock). It is understood that
this is safe against dead-locks, but hardly optimal.</Note>
    </Notes>
    <CVE>CVE-2024-43882</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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: vhci-hcd: Do not drop references before new references are gained

At a few places the driver carries stale pointers
to references that can still be used. Make sure that does not happen.
This strictly speaking closes ZDI-CAN-22273, though there may be
similar races in the driver.</Note>
    </Notes>
    <CVE>CVE-2024-43883</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Add error handling to pair_device()

hci_conn_params_add() never checks for a NULL value and could lead to a NULL
pointer dereference causing a crash.

Fixed by adding error handling in the function.</Note>
    </Notes>
    <CVE>CVE-2024-43884</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix possible divide-by-0 panic in padata_mt_helper()

We are hit with a not easily reproducible divide-by-0 panic in padata.c at
bootup time.

  [   10.017908] Oops: divide error: 0000 1 PREEMPT SMP NOPTI
  [   10.017908] CPU: 26 PID: 2627 Comm: kworker/u1666:1 Not tainted 6.10.0-15.el10.x86_64 #1
  [   10.017908] Hardware name: Lenovo ThinkSystem SR950 [7X12CTO1WW]/[7X12CTO1WW], BIOS [PSE140J-2.30] 07/20/2021
  [   10.017908] Workqueue: events_unbound padata_mt_helper
  [   10.017908] RIP: 0010:padata_mt_helper+0x39/0xb0
    :
  [   10.017963] Call Trace:
  [   10.017968]  &lt;TASK&gt;
  [   10.018004]  ? padata_mt_helper+0x39/0xb0
  [   10.018084]  process_one_work+0x174/0x330
  [   10.018093]  worker_thread+0x266/0x3a0
  [   10.018111]  kthread+0xcf/0x100
  [   10.018124]  ret_from_fork+0x31/0x50
  [   10.018138]  ret_from_fork_asm+0x1a/0x30
  [   10.018147]  &lt;/TASK&gt;

Looking at the padata_mt_helper() function, the only way a divide-by-0
panic can happen is when ps-&gt;chunk_size is 0.  The way that chunk_size is
initialized in padata_do_multithreaded(), chunk_size can be 0 when the
min_chunk in the passed-in padata_mt_job structure is 0.

Fix this divide-by-0 panic by making sure that chunk_size will be at least
1 no matter what the input parameters are.</Note>
    </Notes>
    <CVE>CVE-2024-43889</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix overflow in get_free_elt()

"tracing_map-&gt;next_elt" in get_free_elt() is at risk of overflowing.

Once it overflows, new elements can still be inserted into the tracing_map
even though the maximum number of elements (`max_elts`) has been reached.
Continuing to insert elements after the overflow could result in the
tracing_map containing "tracing_map-&gt;max_size" elements, leaving no empty
entries.
If any attempt is made to insert an element into a full tracing_map using
`__tracing_map_insert()`, it will cause an infinite loop with preemption
disabled, leading to a CPU hang problem.

Fix this by preventing any further increments to "tracing_map-&gt;next_elt"
once it reaches "tracing_map-&gt;max_elt".</Note>
    </Notes>
    <CVE>CVE-2024-43890</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

memcg: protect concurrent access to mem_cgroup_idr

Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after
many small jobs") decoupled the memcg IDs from the CSS ID space to fix the
cgroup creation failures.  It introduced IDR to maintain the memcg ID
space.  The IDR depends on external synchronization mechanisms for
modifications.  For the mem_cgroup_idr, the idr_alloc() and idr_replace()
happen within css callback and thus are protected through cgroup_mutex
from concurrent modifications.  However idr_remove() for mem_cgroup_idr
was not protected against concurrency and can be run concurrently for
different memcgs when they hit their refcnt to zero.  Fix that.

We have been seeing list_lru based kernel crashes at a low frequency in
our fleet for a long time.  These crashes were in different part of
list_lru code including list_lru_add(), list_lru_del() and reparenting
code.  Upon further inspection, it looked like for a given object (dentry
and inode), the super_block's list_lru didn't have list_lru_one for the
memcg of that object.  The initial suspicions were either the object is
not allocated through kmem_cache_alloc_lru() or somehow
memcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but
returned success.  No evidence were found for these cases.

Looking more deeply, we started seeing situations where valid memcg's id
is not present in mem_cgroup_idr and in some cases multiple valid memcgs
have same id and mem_cgroup_idr is pointing to one of them.  So, the most
reasonable explanation is that these situations can happen due to race
between multiple idr_remove() calls or race between
idr_alloc()/idr_replace() and idr_remove().  These races are causing
multiple memcgs to acquire the same ID and then offlining of one of them
would cleanup list_lrus on the system for all of them.  Later access from
other memcgs to the list_lru cause crashes due to missing list_lru_one.</Note>
    </Notes>
    <CVE>CVE-2024-43892</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: core: check uartclk for zero to avoid divide by zero

Calling ioctl TIOCSSERIAL with an invalid baud_base can
result in uartclk being zero, which will result in a
divide by zero error in uart_get_divisor(). The check for
uartclk being zero in uart_set_info() needs to be done
before other settings are made as subsequent calls to
ioctl TIOCSSERIAL for the same port would be impacted if
the uartclk check was done where uartclk gets set.

Oops: divide error: 0000  PREEMPT SMP KASAN PTI
RIP: 0010:uart_get_divisor (drivers/tty/serial/serial_core.c:580)
Call Trace:
 &lt;TASK&gt;
serial8250_get_divisor (drivers/tty/serial/8250/8250_port.c:2576
    drivers/tty/serial/8250/8250_port.c:2589)
serial8250_do_set_termios (drivers/tty/serial/8250/8250_port.c:502
    drivers/tty/serial/8250/8250_port.c:2741)
serial8250_set_termios (drivers/tty/serial/8250/8250_port.c:2862)
uart_change_line_settings (./include/linux/spinlock.h:376
    ./include/linux/serial_core.h:608 drivers/tty/serial/serial_core.c:222)
uart_port_startup (drivers/tty/serial/serial_core.c:342)
uart_startup (drivers/tty/serial/serial_core.c:368)
uart_set_info (drivers/tty/serial/serial_core.c:1034)
uart_set_info_user (drivers/tty/serial/serial_core.c:1059)
tty_set_serial (drivers/tty/tty_io.c:2637)
tty_ioctl (drivers/tty/tty_io.c:2647 drivers/tty/tty_io.c:2791)
__x64_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:907
    fs/ioctl.c:893 fs/ioctl.c:893)
do_syscall_64 (arch/x86/entry/common.c:52
    (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

Rule: add</Note>
    </Notes>
    <CVE>CVE-2024-43893</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/client: fix null pointer dereference in drm_client_modeset_probe

In drm_client_modeset_probe(), the return value of drm_mode_duplicate() is
assigned to modeset-&gt;mode, which will lead to a possible NULL pointer
dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.</Note>
    </Notes>
    <CVE>CVE-2024-43894</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 Recompute DSC Params if no Stream on Link

[why]
Encounter NULL pointer dereference uner mst + dsc setup.

BUG: kernel NULL pointer dereference, address: 0000000000000008
    PGD 0 P4D 0
    Oops: 0000 [#1] PREEMPT SMP NOPTI
    CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2
    Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022
    RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper]
    Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 &lt;48&gt; 8&gt;
    RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293
    RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224
    RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280
    RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850
    R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000
    R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224
    FS:  00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0
    Call Trace:
&lt;TASK&gt;
     ? __die+0x23/0x70
     ? page_fault_oops+0x171/0x4e0
     ? plist_add+0xbe/0x100
     ? exc_page_fault+0x7c/0x180
     ? asm_exc_page_fault+0x26/0x30
     ? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]
     ? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]
     compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
     ? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
     compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
     amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]
     drm_atomic_check_only+0x5c5/0xa40
     drm_mode_atomic_ioctl+0x76e/0xbc0

[how]
dsc recompute should be skipped if no mode change detected on the new
request. If detected, keep checking whether the stream is already on
current state or not.

(cherry picked from commit 8151a6c13111b465dbabe07c19f572f7cbd16fef)</Note>
    </Notes>
    <CVE>CVE-2024-43895</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: drop bad gso csum_start and offset in virtio_net_hdr

Tighten csum_start and csum_offset checks in virtio_net_hdr_to_skb
for GSO packets.

The function already checks that a checksum requested with
VIRTIO_NET_HDR_F_NEEDS_CSUM is in skb linear. But for GSO packets
this might not hold for segs after segmentation.

Syzkaller demonstrated to reach this warning in skb_checksum_help

	offset = skb_checksum_start_offset(skb);
	ret = -EINVAL;
	if (WARN_ON_ONCE(offset &gt;= skb_headlen(skb)))

By injecting a TSO packet:

WARNING: CPU: 1 PID: 3539 at net/core/dev.c:3284 skb_checksum_help+0x3d0/0x5b0
 ip_do_fragment+0x209/0x1b20 net/ipv4/ip_output.c:774
 ip_finish_output_gso net/ipv4/ip_output.c:279 [inline]
 __ip_finish_output+0x2bd/0x4b0 net/ipv4/ip_output.c:301
 iptunnel_xmit+0x50c/0x930 net/ipv4/ip_tunnel_core.c:82
 ip_tunnel_xmit+0x2296/0x2c70 net/ipv4/ip_tunnel.c:813
 __gre_xmit net/ipv4/ip_gre.c:469 [inline]
 ipgre_xmit+0x759/0xa60 net/ipv4/ip_gre.c:661
 __netdev_start_xmit include/linux/netdevice.h:4850 [inline]
 netdev_start_xmit include/linux/netdevice.h:4864 [inline]
 xmit_one net/core/dev.c:3595 [inline]
 dev_hard_start_xmit+0x261/0x8c0 net/core/dev.c:3611
 __dev_queue_xmit+0x1b97/0x3c90 net/core/dev.c:4261
 packet_snd net/packet/af_packet.c:3073 [inline]

The geometry of the bad input packet at tcp_gso_segment:

[   52.003050][ T8403] skb len=12202 headroom=244 headlen=12093 tailroom=0
[   52.003050][ T8403] mac=(168,24) mac_len=24 net=(192,52) trans=244
[   52.003050][ T8403] shinfo(txflags=0 nr_frags=1 gso(size=1552 type=3 segs=0))
[   52.003050][ T8403] csum(0x60000c7 start=199 offset=1536
ip_summed=3 complete_sw=0 valid=0 level=0)

Mitigate with stricter input validation.

csum_offset: for GSO packets, deduce the correct value from gso_type.
This is already done for USO. Extend it to TSO. Let UFO be:
udp[46]_ufo_fragment ignores these fields and always computes the
checksum in software.

csum_start: finding the real offset requires parsing to the transport
header. Do not add a parser, use existing segmentation parsing. Thanks
to SKB_GSO_DODGY, that also catches bad packets that are hw offloaded.
Again test both TSO and USO. Do not test UFO for the above reason, and
do not test UDP tunnel offload.

GSO packet are almost always CHECKSUM_PARTIAL. USO packets may be
CHECKSUM_NONE since commit 10154dbded6d6 ("udp: Allow GSO transmit
from devices with no checksum offload"), but then still these fields
are initialized correctly in udp4_hwcsum/udp6_hwcsum_outgoing. So no
need to test for ip_summed == CHECKSUM_PARTIAL first.

This revises an existing fix mentioned in the Fixes tag, which broke
small packets with GSO offload, as detected by kselftests.</Note>
    </Notes>
    <CVE>CVE-2024-43897</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-43898</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 pointer deref in dcn20_resource.c

Fixes a hang thats triggered when MPV is run on a DCN401 dGPU:

mpv --hwdec=vaapi --vo=gpu --hwdec-codecs=all

and then enabling fullscreen playback (double click on the video)

The following calltrace will be seen:

[  181.843989] BUG: kernel NULL pointer dereference, address: 0000000000000000
[  181.843997] #PF: supervisor instruction fetch in kernel mode
[  181.844003] #PF: error_code(0x0010) - not-present page
[  181.844009] PGD 0 P4D 0
[  181.844020] Oops: 0010 [#1] PREEMPT SMP NOPTI
[  181.844028] CPU: 6 PID: 1892 Comm: gnome-shell Tainted: G        W  OE      6.5.0-41-generic #41~22.04.2-Ubuntu
[  181.844038] Hardware name: System manufacturer System Product Name/CROSSHAIR VI HERO, BIOS 6302 10/23/2018
[  181.844044] RIP: 0010:0x0
[  181.844079] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
[  181.844084] RSP: 0018:ffffb593c2b8f7b0 EFLAGS: 00010246
[  181.844093] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004
[  181.844099] RDX: ffffb593c2b8f804 RSI: ffffb593c2b8f7e0 RDI: ffff9e3c8e758400
[  181.844105] RBP: ffffb593c2b8f7b8 R08: ffffb593c2b8f9c8 R09: ffffb593c2b8f96c
[  181.844110] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb593c2b8f9c8
[  181.844115] R13: 0000000000000001 R14: ffff9e3c88000000 R15: 0000000000000005
[  181.844121] FS:  00007c6e323bb5c0(0000) GS:ffff9e3f85f80000(0000) knlGS:0000000000000000
[  181.844128] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  181.844134] CR2: ffffffffffffffd6 CR3: 0000000140fbe000 CR4: 00000000003506e0
[  181.844141] Call Trace:
[  181.844146]  &lt;TASK&gt;
[  181.844153]  ? show_regs+0x6d/0x80
[  181.844167]  ? __die+0x24/0x80
[  181.844179]  ? page_fault_oops+0x99/0x1b0
[  181.844192]  ? do_user_addr_fault+0x31d/0x6b0
[  181.844204]  ? exc_page_fault+0x83/0x1b0
[  181.844216]  ? asm_exc_page_fault+0x27/0x30
[  181.844237]  dcn20_get_dcc_compression_cap+0x23/0x30 [amdgpu]
[  181.845115]  amdgpu_dm_plane_validate_dcc.constprop.0+0xe5/0x180 [amdgpu]
[  181.845985]  amdgpu_dm_plane_fill_plane_buffer_attributes+0x300/0x580 [amdgpu]
[  181.846848]  fill_dc_plane_info_and_addr+0x258/0x350 [amdgpu]
[  181.847734]  fill_dc_plane_attributes+0x162/0x350 [amdgpu]
[  181.848748]  dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu]
[  181.849791]  ? dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu]
[  181.850840]  amdgpu_dm_atomic_check+0xdfe/0x1760 [amdgpu]</Note>
    </Notes>
    <CVE>CVE-2024-43899</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: xc2028: avoid use-after-free in load_firmware_cb()

syzkaller reported use-after-free in load_firmware_cb() [1].
The reason is because the module allocated a struct tuner in tuner_probe(),
and then the module initialization failed, the struct tuner was released.
A worker which created during module initialization accesses this struct
tuner later, it caused use-after-free.

The process is as follows:

task-6504           worker_thread
tuner_probe                             &lt;= alloc dvb_frontend [2]
...
request_firmware_nowait                 &lt;= create a worker
...
tuner_remove                            &lt;= free dvb_frontend
...
                    request_firmware_work_func  &lt;= the firmware is ready
                    load_firmware_cb    &lt;= but now the dvb_frontend has been freed

To fix the issue, check the dvd_frontend in load_firmware_cb(), if it is
null, report a warning and just return.

[1]:
    ==================================================================
     BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0
     Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504

     Call trace:
      load_firmware_cb+0x1310/0x17a0
      request_firmware_work_func+0x128/0x220
      process_one_work+0x770/0x1824
      worker_thread+0x488/0xea0
      kthread+0x300/0x430
      ret_from_fork+0x10/0x20

     Allocated by task 6504:
      kzalloc
      tuner_probe+0xb0/0x1430
      i2c_device_probe+0x92c/0xaf0
      really_probe+0x678/0xcd0
      driver_probe_device+0x280/0x370
      __device_attach_driver+0x220/0x330
      bus_for_each_drv+0x134/0x1c0
      __device_attach+0x1f4/0x410
      device_initial_probe+0x20/0x30
      bus_probe_device+0x184/0x200
      device_add+0x924/0x12c0
      device_register+0x24/0x30
      i2c_new_device+0x4e0/0xc44
      v4l2_i2c_new_subdev_board+0xbc/0x290
      v4l2_i2c_new_subdev+0xc8/0x104
      em28xx_v4l2_init+0x1dd0/0x3770

     Freed by task 6504:
      kfree+0x238/0x4e4
      tuner_remove+0x144/0x1c0
      i2c_device_remove+0xc8/0x290
      __device_release_driver+0x314/0x5fc
      device_release_driver+0x30/0x44
      bus_remove_device+0x244/0x490
      device_del+0x350/0x900
      device_unregister+0x28/0xd0
      i2c_unregister_device+0x174/0x1d0
      v4l2_device_unregister+0x224/0x380
      em28xx_v4l2_init+0x1d90/0x3770

     The buggy address belongs to the object at ffff8000d7ca2000
      which belongs to the cache kmalloc-2k of size 2048
     The buggy address is located 776 bytes inside of
      2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800)
     The buggy address belongs to the page:
     page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0
     flags: 0x7ff800000000100(slab)
     raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000
     raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
     page dumped because: kasan: bad access detected

     Memory state around the buggy address:
      ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     &gt;ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                           ^
      ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ==================================================================

[2]
    Actually, it is allocated for struct tuner, and dvb_frontend is inside.</Note>
    </Notes>
    <CVE>CVE-2024-43900</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 checker before passing variables

Checks null pointer before passing variables to functions.

This fixes 3 NULL_RETURNS issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-43902</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-43903</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 checks for 'stream' and 'plane' before dereferencing

This commit adds null checks for the 'stream' and 'plane' variables in
the dcn30_apply_idle_power_optimizations function. These variables were
previously assumed to be null at line 922, but they were used later in
the code without checking if they were null. This could potentially lead
to a null pointer dereference, which would cause a crash.

The null checks ensure that 'stream' and 'plane' are not null before
they are used, preventing potential crashes.

Fixes the below static smatch checker:
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:938 dcn30_apply_idle_power_optimizations() error: we previously assumed 'stream' could be null (see line 922)
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:940 dcn30_apply_idle_power_optimizations() error: we previously assumed 'plane' could be null (see line 922)</Note>
    </Notes>
    <CVE>CVE-2024-43904</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 the null pointer dereference for vega10_hwmgr

Check return value and conduct null pointer handling to avoid null pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2024-43905</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/pm: Fix the null pointer dereference in apply_state_adjust_rules

Check the pointer value to fix potential null pointer
dereference</Note>
    </Notes>
    <CVE>CVE-2024-43907</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 null pointer dereference to ras_manager

Check ras_manager before using it</Note>
    </Notes>
    <CVE>CVE-2024-43908</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/pm: Fix the null pointer dereference for smu7

optimize the code to avoid pass a null pointer (hwmgr-&gt;backend)
to function smu7_update_edc_leakage_table.</Note>
    </Notes>
    <CVE>CVE-2024-43909</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: nl80211: disallow setting special AP channel widths

Setting the AP channel width is meant for use with the normal
20/40/... MHz channel width progression, and switching around
in S1G or narrow channels isn't supported. Disallow that.</Note>
    </Notes>
    <CVE>CVE-2024-43912</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/raid5: avoid BUG_ON() while continue reshape after reassembling

Currently, mdadm support --revert-reshape to abort the reshape while
reassembling, as the test 07revert-grow. However, following BUG_ON()
can be triggerred by the test:

kernel BUG at drivers/md/raid5.c:6278!
invalid opcode: 0000 [#1] PREEMPT SMP PTI
irq event stamp: 158985
CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94
RIP: 0010:reshape_request+0x3f1/0xe60
Call Trace:
 &lt;TASK&gt;
 raid5_sync_request+0x43d/0x550
 md_do_sync+0xb7a/0x2110
 md_thread+0x294/0x2b0
 kthread+0x147/0x1c0
 ret_from_fork+0x59/0x70
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;

Root cause is that --revert-reshape update the raid_disks from 5 to 4,
while reshape position is still set, and after reassembling the array,
reshape position will be read from super block, then during reshape the
checking of 'writepos' that is caculated by old reshape position will
fail.

Fix this panic the easy way first, by converting the BUG_ON() to
WARN_ON(), and stop the reshape if checkings fail.

Noted that mdadm must fix --revert-shape as well, and probably md/raid
should enhance metadata validation as well, however this means
reassemble will fail and there must be user tools to fix the wrong
metadata.</Note>
    </Notes>
    <CVE>CVE-2024-43914</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gpio: prevent potential speculation leaks in gpio_device_get_desc()

Userspace may trigger a speculative read of an address outside the gpio
descriptor array.
Users can do that by calling gpio_ioctl() with an offset out of range.
Offset is copied from user and then used as an array index to get
the gpio descriptor without sanitization in gpio_device_get_desc().

This change ensures that the offset is sanitized by using
array_index_nospec() to mitigate any possibility of speculative
information leaks.

This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.</Note>
    </Notes>
    <CVE>CVE-2024-44931</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix null-ptr-deref in reuseport_add_sock().

syzbot reported a null-ptr-deref while accessing sk2-&gt;sk_reuseport_cb in
reuseport_add_sock(). [0]

The repro first creates a listener with SO_REUSEPORT.  Then, it creates
another listener on the same port and concurrently closes the first
listener.

The second listen() calls reuseport_add_sock() with the first listener as
sk2, where sk2-&gt;sk_reuseport_cb is not expected to be cleared concurrently,
but the close() does clear it by reuseport_detach_sock().

The problem is SCTP does not properly synchronise reuseport_alloc(),
reuseport_add_sock(), and reuseport_detach_sock().

The caller of reuseport_alloc() and reuseport_{add,detach}_sock() must
provide synchronisation for sockets that are classified into the same
reuseport group.

Otherwise, such sockets form multiple identical reuseport groups, and
all groups except one would be silently dead.

  1. Two sockets call listen() concurrently
  2. No socket in the same group found in sctp_ep_hashtable[]
  3. Two sockets call reuseport_alloc() and form two reuseport groups
  4. Only one group hit first in __sctp_rcv_lookup_endpoint() receives
      incoming packets

Also, the reported null-ptr-deref could occur.

TCP/UDP guarantees that would not happen by holding the hash bucket lock.

Let's apply the locking strategy to __sctp_hash_endpoint() and
__sctp_unhash_endpoint().

[0]:
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: 1 UID: 0 PID: 10230 Comm: syz-executor119 Not tainted 6.10.0-syzkaller-12585-g301927d2d2eb #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024
RIP: 0010:reuseport_add_sock+0x27e/0x5e0 net/core/sock_reuseport.c:350
Code: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 03 &lt;42&gt; 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14
RSP: 0018:ffffc9000b947c98 EFLAGS: 00010202
RAX: 0000000000000002 RBX: ffff8880252ddf98 RCX: ffff888079478000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012
RBP: 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385
R10: dffffc0000000000 R11: fffffbfff1fef386 R12: ffff8880252ddac0
R13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 __sctp_hash_endpoint net/sctp/input.c:762 [inline]
 sctp_hash_endpoint+0x52a/0x600 net/sctp/input.c:790
 sctp_listen_start net/sctp/socket.c:8570 [inline]
 sctp_inet_listen+0x767/0xa20 net/sctp/socket.c:8625
 __sys_listen_socket net/socket.c:1883 [inline]
 __sys_listen+0x1b7/0x230 net/socket.c:1894
 __do_sys_listen net/socket.c:1902 [inline]
 __se_sys_listen net/socket.c:1900 [inline]
 __x64_sys_listen+0x5a/0x70 net/socket.c:1900
 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:0x7f24e46039b9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1a 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:00007f24e45b9228 EFLAGS: 00000246 ORIG_RAX: 0000000000000032
RAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: 00007f24e46039b9
RDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004
RBP: 00007f24e468e420 R08: 00007f24e45b96c0 R09: 00007f24e45b96c0
R10: 00007f24e45b96c0 R11: 0000000000000246 R12: 00007f24e468e42c
R13:
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-44935</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 shift-out-of-bounds in dbDiscardAG

When searching for the next smaller log2 block, BLKSTOL2() returned 0,
causing shift exponent -1 to be negative.

This patch fixes the issue by exiting the loop directly when negative
shift is found.</Note>
    </Notes>
    <CVE>CVE-2024-44938</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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 null ptr deref in dtInsertEntry

[syzbot reported]
general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 PID: 5061 Comm: syz-executor404 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
RIP: 0010:dtInsertEntry+0xd0c/0x1780 fs/jfs/jfs_dtree.c:3713
...
[Analyze]
In dtInsertEntry(), when the pointer h has the same value as p, after writing
name in UniStrncpy_to_le(), p-&gt;header.flag will be cleared. This will cause the
previously true judgment "p-&gt;header.flag &amp; BT-LEAF" to change to no after writing
the name operation, this leads to entering an incorrect branch and accessing the
uninitialized object ih when judging this condition for the second time.

[Fix]
After got the page, check freelist first, if freelist == 0 then exit dtInsert()
and return -EINVAL.</Note>
    </Notes>
    <CVE>CVE-2024-44939</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ctnetlink: use helper function to calculate expect ID

Delete expectation path is missing a call to the nf_expect_get_id()
helper function to calculate the expectation ID, otherwise LSB of the
expectation object address is leaked to userspace.</Note>
    </Notes>
    <CVE>CVE-2024-44944</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

kcm: Serialise kcm_sendmsg() for the same socket.

syzkaller reported UAF in kcm_release(). [0]

The scenario is

  1. Thread A builds a skb with MSG_MORE and sets kcm-&gt;seq_skb.

  2. Thread A resumes building skb from kcm-&gt;seq_skb but is blocked
     by sk_stream_wait_memory()

  3. Thread B calls sendmsg() concurrently, finishes building kcm-&gt;seq_skb
     and puts the skb to the write queue

  4. Thread A faces an error and finally frees skb that is already in the
     write queue

  5. kcm_release() does double-free the skb in the write queue

When a thread is building a MSG_MORE skb, another thread must not touch it.

Let's add a per-sk mutex and serialise kcm_sendmsg().

[0]:
BUG: KASAN: slab-use-after-free in __skb_unlink include/linux/skbuff.h:2366 [inline]
BUG: KASAN: slab-use-after-free in __skb_dequeue include/linux/skbuff.h:2385 [inline]
BUG: KASAN: slab-use-after-free in __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline]
BUG: KASAN: slab-use-after-free in __skb_queue_purge include/linux/skbuff.h:3181 [inline]
BUG: KASAN: slab-use-after-free in kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691
Read of size 8 at addr ffff0000ced0fc80 by task syz-executor329/6167

CPU: 1 PID: 6167 Comm: syz-executor329 Tainted: G    B              6.8.0-rc5-syzkaller-g9abbc24128bc #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Call trace:
 dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:291
 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:298
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0x178/0x518 mm/kasan/report.c:488
 kasan_report+0xd8/0x138 mm/kasan/report.c:601
 __asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381
 __skb_unlink include/linux/skbuff.h:2366 [inline]
 __skb_dequeue include/linux/skbuff.h:2385 [inline]
 __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline]
 __skb_queue_purge include/linux/skbuff.h:3181 [inline]
 kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691
 __sock_release net/socket.c:659 [inline]
 sock_close+0xa4/0x1e8 net/socket.c:1421
 __fput+0x30c/0x738 fs/file_table.c:376
 ____fput+0x20/0x30 fs/file_table.c:404
 task_work_run+0x230/0x2e0 kernel/task_work.c:180
 exit_task_work include/linux/task_work.h:38 [inline]
 do_exit+0x618/0x1f64 kernel/exit.c:871
 do_group_exit+0x194/0x22c kernel/exit.c:1020
 get_signal+0x1500/0x15ec kernel/signal.c:2893
 do_signal+0x23c/0x3b44 arch/arm64/kernel/signal.c:1249
 do_notify_resume+0x74/0x1f4 arch/arm64/kernel/entry-common.c:148
 exit_to_user_mode_prepare arch/arm64/kernel/entry-common.c:169 [inline]
 exit_to_user_mode arch/arm64/kernel/entry-common.c:178 [inline]
 el0_svc+0xac/0x168 arch/arm64/kernel/entry-common.c:713
 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730
 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598

Allocated by task 6166:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x40/0x78 mm/kasan/common.c:68
 kasan_save_alloc_info+0x70/0x84 mm/kasan/generic.c:626
 unpoison_slab_object mm/kasan/common.c:314 [inline]
 __kasan_slab_alloc+0x74/0x8c mm/kasan/common.c:340
 kasan_slab_alloc include/linux/kasan.h:201 [inline]
 slab_post_alloc_hook mm/slub.c:3813 [inline]
 slab_alloc_node mm/slub.c:3860 [inline]
 kmem_cache_alloc_node+0x204/0x4c0 mm/slub.c:3903
 __alloc_skb+0x19c/0x3d8 net/core/skbuff.c:641
 alloc_skb include/linux/skbuff.h:1296 [inline]
 kcm_sendmsg+0x1d3c/0x2124 net/kcm/kcmsock.c:783
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg net/socket.c:745 [inline]
 sock_sendmsg+0x220/0x2c0 net/socket.c:768
 splice_to_socket+0x7cc/0xd58 fs/splice.c:889
 do_splice_from fs/splice.c:941 [inline]
 direct_splice_actor+0xec/0x1d8 fs/splice.c:1164
 splice_direct_to_actor+0x438/0xa0c fs/splice.c:1108
 do_splice_direct_actor 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-44946</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

fuse: Initialize beyond-EOF page contents before setting uptodate

fuse_notify_store(), unlike fuse_do_readpage(), does not enable page
zeroing (because it can be used to change partial page contents).

So fuse_notify_store() must be more careful to fully initialize page
contents (including parts of the page that are beyond end-of-file)
before marking the page uptodate.

The current code can leave beyond-EOF page contents uninitialized, which
makes these uninitialized page contents visible to userspace via mmap().

This is an information leak, but only affects systems which do not
enable init-on-alloc (via CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y or the
corresponding kernel command line parameter).</Note>
    </Notes>
    <CVE>CVE-2024-44947</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/mtrr: Check if fixed MTRRs exist before saving them

MTRRs have an obsolete fixed variant for fine grained caching control
of the 640K-1MB region that uses separate MSRs. This fixed variant has
a separate capability bit in the MTRR capability MSR.

So far all x86 CPUs which support MTRR have this separate bit set, so it
went unnoticed that mtrr_save_state() does not check the capability bit
before accessing the fixed MTRR MSRs.

Though on a CPU that does not support the fixed MTRR capability this
results in a #GP.  The #GP itself is harmless because the RDMSR fault is
handled gracefully, but results in a WARN_ON().

Add the missing capability check to prevent this.</Note>
    </Notes>
    <CVE>CVE-2024-44948</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sc16is7xx: fix invalid FIFO access with special register set

When enabling access to the special register set, Receiver time-out and
RHR interrupts can happen. In this case, the IRQ handler will try to read
from the FIFO thru the RHR register at address 0x00, but address 0x00 is
mapped to DLL register, resulting in erroneous FIFO reading.

Call graph example:
    sc16is7xx_startup(): entry
    sc16is7xx_ms_proc(): entry
    sc16is7xx_set_termios(): entry
    sc16is7xx_set_baud(): DLH/DLL = $009C --&gt; access special register set
    sc16is7xx_port_irq() entry            --&gt; IIR is 0x0C
    sc16is7xx_handle_rx() entry
    sc16is7xx_fifo_read(): --&gt; unable to access FIFO (RHR) because it is
                               mapped to DLL (LCR=LCR_CONF_MODE_A)
    sc16is7xx_set_baud(): exit --&gt; Restore access to general register set

Fix the problem by claiming the efr_lock mutex when accessing the Special
register set.</Note>
    </Notes>
    <CVE>CVE-2024-44950</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-44952</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: line6: Fix racy access to midibuf

There can be concurrent accesses to line6 midibuf from both the URB
completion callback and the rawmidi API access.  This could be a cause
of KMSAN warning triggered by syzkaller below (so put as reported-by
here).

This patch protects the midibuf call of the former code path with a
spinlock for avoiding the possible races.</Note>
    </Notes>
    <CVE>CVE-2024-44954</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/mgag200: Bind I2C lifetime to DRM device

Managed cleanup with devm_add_action_or_reset() will release the I2C
adapter when the underlying Linux device goes away. But the connector
still refers to it, so this cleanup leaves behind a stale pointer
in struct drm_connector.ddc.

Bind the lifetime of the I2C adapter to the connector's lifetime by
using DRM's managed release. When the DRM device goes away (after
the Linux device) DRM will first clean up the connector and then
clean up the I2C adapter.</Note>
    </Notes>
    <CVE>CVE-2024-44967</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/sclp: Prevent release of buffer in I/O

When a task waiting for completion of a Store Data operation is
interrupted, an attempt is made to halt this operation. If this attempt
fails due to a hardware or firmware problem, there is a chance that the
SCLP facility might store data into buffers referenced by the original
operation at a later time.

Handle this situation by not releasing the referenced data buffers if
the halt attempt fails. For current use cases, this might result in a
leak of few pages of memory in case of a rare hardware/firmware
malfunction.</Note>
    </Notes>
    <CVE>CVE-2024-44969</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: SHAMPO, Fix invalid WQ linked list unlink

When all the strides in a WQE have been consumed, the WQE is unlinked
from the WQ linked list (mlx5_wq_ll_pop()). For SHAMPO, it is possible
to receive CQEs with 0 consumed strides for the same WQE even after the
WQE is fully consumed and unlinked. This triggers an additional unlink
for the same wqe which corrupts the linked list.

Fix this scenario by accepting 0 sized consumed strides without
unlinking the WQE again.</Note>
    </Notes>
    <CVE>CVE-2024-44970</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: bcm_sf2: Fix a possible memory leak in bcm_sf2_mdio_register()

bcm_sf2_mdio_register() calls of_phy_find_device() and then
phy_device_remove() in a loop to remove existing PHY devices.
of_phy_find_device() eventually calls bus_find_device(), which calls
get_device() on the returned struct device * to increment the refcount.
The current implementation does not decrement the refcount, which causes
memory leak.

This commit adds the missing phy_device_free() call to decrement the
refcount via put_device() to balance the refcount.</Note>
    </Notes>
    <CVE>CVE-2024-44971</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Validate TA binary size

Add TA binary size validation to avoid OOB write.

(cherry picked from commit c0a04e3570d72aaf090962156ad085e37c62e442)</Note>
    </Notes>
    <CVE>CVE-2024-44977</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/dpu: cleanup FB if dpu_format_populate_layout fails

If the dpu_format_populate_layout() fails, then FB is prepared, but not
cleaned up. This ends up leaking the pin_count on the GEM object and
causes a splat during DRM file closure:

msm_obj-&gt;pin_count
WARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc
[...]
Call trace:
 update_lru_locked+0xc4/0xcc
 put_pages+0xac/0x100
 msm_gem_free_object+0x138/0x180
 drm_gem_object_free+0x1c/0x30
 drm_gem_object_handle_put_unlocked+0x108/0x10c
 drm_gem_object_release_handle+0x58/0x70
 idr_for_each+0x68/0xec
 drm_gem_release+0x28/0x40
 drm_file_free+0x174/0x234
 drm_release+0xb0/0x160
 __fput+0xc0/0x2c8
 __fput_sync+0x50/0x5c
 __arm64_sys_close+0x38/0x7c
 invoke_syscall+0x48/0x118
 el0_svc_common.constprop.0+0x40/0xe0
 do_el0_svc+0x1c/0x28
 el0_svc+0x4c/0x120
 el0t_64_sync_handler+0x100/0x12c
 el0t_64_sync+0x190/0x194
irq event stamp: 129818
hardirqs last  enabled at (129817): [&lt;ffffa5f6d953fcc0&gt;] console_unlock+0x118/0x124
hardirqs last disabled at (129818): [&lt;ffffa5f6da7dcf04&gt;] el1_dbg+0x24/0x8c
softirqs last  enabled at (129808): [&lt;ffffa5f6d94afc18&gt;] handle_softirqs+0x4c8/0x4e8
softirqs last disabled at (129785): [&lt;ffffa5f6d94105e4&gt;] __do_softirq+0x14/0x20

Patchwork: https://patchwork.freedesktop.org/patch/600714/</Note>
    </Notes>
    <CVE>CVE-2024-44982</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix possible UAF in ip6_finish_output2()

If skb_expand_head() returns NULL, skb has been freed
and associated dst/idev could also have been freed.

We need to hold rcu_read_lock() to make sure the dst and
associated idev are alive.</Note>
    </Notes>
    <CVE>CVE-2024-44986</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: prevent UAF in ip6_send_skb()

syzbot reported an UAF in ip6_send_skb() [1]

After ip6_local_out() has returned, we no longer can safely
dereference rt, unless we hold rcu_read_lock().

A similar issue has been fixed in commit
a688caa34beb ("ipv6: take rcu lock in rawv6_send_hdrinc()")

Another potential issue in ip6_finish_output2() is handled in a
separate patch.

[1]
 BUG: KASAN: slab-use-after-free in ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964
Read of size 8 at addr ffff88806dde4858 by task syz.1.380/6530

CPU: 1 UID: 0 PID: 6530 Comm: syz.1.380 Not tainted 6.11.0-rc3-syzkaller-00306-gdf6cbc62cc9b #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
  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
  ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964
  rawv6_push_pending_frames+0x75c/0x9e0 net/ipv6/raw.c:588
  rawv6_sendmsg+0x19c7/0x23c0 net/ipv6/raw.c:926
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x1a6/0x270 net/socket.c:745
  sock_write_iter+0x2dd/0x400 net/socket.c:1160
 do_iter_readv_writev+0x60a/0x890
  vfs_writev+0x37c/0xbb0 fs/read_write.c:971
  do_writev+0x1b1/0x350 fs/read_write.c:1018
  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:0x7f936bf79e79
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:00007f936cd7f038 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 00007f936c115f80 RCX: 00007f936bf79e79
RDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000004
RBP: 00007f936bfe7916 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f936c115f80 R15: 00007fff2860a7a8
 &lt;/TASK&gt;

Allocated by task 6530:
  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:312 [inline]
  __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338
  kasan_slab_alloc include/linux/kasan.h:201 [inline]
  slab_post_alloc_hook mm/slub.c:3988 [inline]
  slab_alloc_node mm/slub.c:4037 [inline]
  kmem_cache_alloc_noprof+0x135/0x2a0 mm/slub.c:4044
  dst_alloc+0x12b/0x190 net/core/dst.c:89
  ip6_blackhole_route+0x59/0x340 net/ipv6/route.c:2670
  make_blackhole net/xfrm/xfrm_policy.c:3120 [inline]
  xfrm_lookup_route+0xd1/0x1c0 net/xfrm/xfrm_policy.c:3313
  ip6_dst_lookup_flow+0x13e/0x180 net/ipv6/ip6_output.c:1257
  rawv6_sendmsg+0x1283/0x23c0 net/ipv6/raw.c:898
  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_sendmsg+0x2b0/0x3a0 net/socket.c:2680
  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 45:
  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]
  kmem_cache_free+0x145/0x350 mm/slub.c:4548
  dst_destroy+0x2ac/0x460 net/core/dst.c:124
  rcu_do_batch kernel/rcu/tree.c:2569 [inline]
  rcu_core+0xafd/0x1830 kernel/rcu/tree.
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-44987</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mv88e6xxx: Fix out-of-bound access

If an ATU violation was caused by a CPU Load operation, the SPID could
be larger than DSA_MAX_PORTS (the size of mv88e6xxx_chip.ports[] array).</Note>
    </Notes>
    <CVE>CVE-2024-44988</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix xfrm real_dev null pointer dereference

We shouldn't set real_dev to NULL because packets can be in transit and
xfrm might call xdo_dev_offload_ok() in parallel. All callbacks assume
real_dev is set.

 Example trace:
 kernel: BUG: unable to handle page fault for address: 0000000000001030
 kernel: bond0: (slave eni0np1): making interface the new active one
 kernel: #PF: supervisor write access in kernel mode
 kernel: #PF: error_code(0x0002) - not-present page
 kernel: PGD 0 P4D 0
 kernel: Oops: 0002 [#1] PREEMPT SMP
 kernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12
 kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014
 kernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim]
 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA
 kernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 &lt;83&gt; 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f
 kernel: bond0: (slave eni0np1): making interface the new active one
 kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246
 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA
 kernel:
 kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60
 kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00
 kernel: RBP: ffff9eb3c0a42000 R08: 0000000000000010 R09: 0000000000000014
 kernel: R10: 7974203030303030 R11: 3030303030303030 R12: 0000000000000000
 kernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000
 kernel: FS:  00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000
 kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 kernel: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0
 kernel: bond0: (slave eni0np1): making interface the new active one
 kernel: Call Trace:
 kernel:  &lt;TASK&gt;
 kernel:  ? __die+0x1f/0x60
 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA
 kernel:  ? page_fault_oops+0x142/0x4c0
 kernel:  ? do_user_addr_fault+0x65/0x670
 kernel:  ? kvm_read_and_reset_apf_flags+0x3b/0x50
 kernel: bond0: (slave eni0np1): making interface the new active one
 kernel:  ? exc_page_fault+0x7b/0x180
 kernel:  ? asm_exc_page_fault+0x22/0x30
 kernel:  ? nsim_bpf_uninit+0x50/0x50 [netdevsim]
 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA
 kernel:  ? nsim_ipsec_offload_ok+0xc/0x20 [netdevsim]
 kernel: bond0: (slave eni0np1): making interface the new active one
 kernel:  bond_ipsec_offload_ok+0x7b/0x90 [bonding]
 kernel:  xfrm_output+0x61/0x3b0
 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA
 kernel:  ip_push_pending_frames+0x56/0x80</Note>
    </Notes>
    <CVE>CVE-2024-44989</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix null pointer deref in bond_ipsec_offload_ok

We must check if there is an active slave before dereferencing the pointer.</Note>
    </Notes>
    <CVE>CVE-2024-44990</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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
                                 |
                                 v
                              ......
setup tc                         |
    |                            v
    v                      DOWN: napi_disable()
napi_disable()(skip)             |
    |                            |
    v                            v
  ......                      ......
    |                            |
    v                            |
napi_enable()                    |
                                 v
                           UINIT: netif_napi_del()
                                 |
                                 v
                              ......
                                 |
                                 v
                           INIT: netif_napi_add()
                                 |
                                 v
                              ......                 global reset start
                                 |                      |
                                 v                      v
                           UP: napi_enable()(skip)    ......
                                 |                      |
                                 v                      v
                              ......                 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

atm: idt77252: prevent use after free in dequeue_rx()

We can't dereference "skb" after calling vcc-&gt;push() because the skb
is released.</Note>
    </Notes>
    <CVE>CVE-2024-44998</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gtp: pull network headers in gtp_dev_xmit()

syzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]

We must make sure the IPv4 or Ipv6 header is pulled in skb-&gt;head
before accessing fields in them.

Use pskb_inet_may_pull() to fix this issue.

[1]
BUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline]
 BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]
 BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281
  ipv6_pdp_find drivers/net/gtp.c:220 [inline]
  gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]
  gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281
  __netdev_start_xmit include/linux/netdevice.h:4913 [inline]
  netdev_start_xmit include/linux/netdevice.h:4922 [inline]
  xmit_one net/core/dev.c:3580 [inline]
  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596
  __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423
  dev_queue_xmit include/linux/netdevice.h:3105 [inline]
  packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276
  packet_snd net/packet/af_packet.c:3145 [inline]
  packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:745
  __sys_sendto+0x685/0x830 net/socket.c:2204
  __do_sys_sendto net/socket.c:2216 [inline]
  __se_sys_sendto net/socket.c:2212 [inline]
  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212
  x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Uninit was created at:
  slab_post_alloc_hook mm/slub.c:3994 [inline]
  slab_alloc_node mm/slub.c:4037 [inline]
  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080
  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583
  __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674
  alloc_skb include/linux/skbuff.h:1320 [inline]
  alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526
  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815
  packet_alloc_skb net/packet/af_packet.c:2994 [inline]
  packet_snd net/packet/af_packet.c:3088 [inline]
  packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:745
  __sys_sendto+0x685/0x830 net/socket.c:2204
  __do_sys_sendto net/socket.c:2216 [inline]
  __se_sys_sendto net/socket.c:2212 [inline]
  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212
  x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

CPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024</Note>
    </Notes>
    <CVE>CVE-2024-44999</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/netfs/fscache_cookie: add missing "n_accesses" check

This fixes a NULL pointer dereference bug due to a data race which
looks like this:

  BUG: kernel NULL pointer dereference, address: 0000000000000008
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: 0000 [#1] SMP PTI
  CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ #43
  Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018
  Workqueue: events_unbound netfs_rreq_write_to_cache_work
  RIP: 0010:cachefiles_prepare_write+0x30/0xa0
  Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 &lt;48&gt; 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10
  RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286
  RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000
  RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438
  RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001
  R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68
  R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00
  FS:  0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0
  Call Trace:
   &lt;TASK&gt;
   ? __die+0x1f/0x70
   ? page_fault_oops+0x15d/0x440
   ? search_module_extables+0xe/0x40
   ? fixup_exception+0x22/0x2f0
   ? exc_page_fault+0x5f/0x100
   ? asm_exc_page_fault+0x22/0x30
   ? cachefiles_prepare_write+0x30/0xa0
   netfs_rreq_write_to_cache_work+0x135/0x2e0
   process_one_work+0x137/0x2c0
   worker_thread+0x2e9/0x400
   ? __pfx_worker_thread+0x10/0x10
   kthread+0xcc/0x100
   ? __pfx_kthread+0x10/0x10
   ret_from_fork+0x30/0x50
   ? __pfx_kthread+0x10/0x10
   ret_from_fork_asm+0x1b/0x30
   &lt;/TASK&gt;
  Modules linked in:
  CR2: 0000000000000008
  ---[ end trace 0000000000000000 ]---

This happened because fscache_cookie_state_machine() was slow and was
still running while another process invoked fscache_unuse_cookie();
this led to a fscache_cookie_lru_do_one() call, setting the
FSCACHE_COOKIE_DO_LRU_DISCARD flag, which was picked up by
fscache_cookie_state_machine(), withdrawing the cookie via
cachefiles_withdraw_cookie(), clearing cookie-&gt;cache_priv.

At the same time, yet another process invoked
cachefiles_prepare_write(), which found a NULL pointer in this code
line:

  struct cachefiles_object *object = cachefiles_cres_object(cres);

The next line crashes, obviously:

  struct cachefiles_cache *cache = object-&gt;volume-&gt;cache;

During cachefiles_prepare_write(), the "n_accesses" counter is
non-zero (via fscache_begin_operation()).  The cookie must not be
withdrawn until it drops to zero.

The counter is checked by fscache_cookie_state_machine() before
switching to FSCACHE_COOKIE_STATE_RELINQUISHING and
FSCACHE_COOKIE_STATE_WITHDRAWING (in "case
FSCACHE_COOKIE_STATE_FAILED"), but not for
FSCACHE_COOKIE_STATE_LRU_DISCARDING ("case
FSCACHE_COOKIE_STATE_ACTIVE").

This patch adds the missing check.  With a non-zero access counter,
the function returns and the next fscache_end_cookie_access() call
will queue another fscache_cookie_state_machine() call to handle the
still-pending FSCACHE_COOKIE_DO_LRU_DISCARD.</Note>
    </Notes>
    <CVE>CVE-2024-45000</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mana: Fix RX buf alloc_size alignment and atomic op panic

The MANA driver's RX buffer alloc_size is passed into napi_build_skb() to
create SKB. skb_shinfo(skb) is located at the end of skb, and its alignment
is affected by the alloc_size passed into napi_build_skb(). The size needs
to be aligned properly for better performance and atomic operations.
Otherwise, on ARM64 CPU, for certain MTU settings like 4000, atomic
operations may panic on the skb_shinfo(skb)-&gt;dataref due to alignment fault.

To fix this bug, add proper alignment to the alloc_size calculation.

Sample panic info:
[  253.298819] Unable to handle kernel paging request at virtual address ffff000129ba5cce
[  253.300900] Mem abort info:
[  253.301760]   ESR = 0x0000000096000021
[  253.302825]   EC = 0x25: DABT (current EL), IL = 32 bits
[  253.304268]   SET = 0, FnV = 0
[  253.305172]   EA = 0, S1PTW = 0
[  253.306103]   FSC = 0x21: alignment fault
Call trace:
 __skb_clone+0xfc/0x198
 skb_clone+0x78/0xe0
 raw6_local_deliver+0xfc/0x228
 ip6_protocol_deliver_rcu+0x80/0x500
 ip6_input_finish+0x48/0x80
 ip6_input+0x48/0xc0
 ip6_sublist_rcv_finish+0x50/0x78
 ip6_sublist_rcv+0x1cc/0x2b8
 ipv6_list_rcv+0x100/0x150
 __netif_receive_skb_list_core+0x180/0x220
 netif_receive_skb_list_internal+0x198/0x2a8
 __napi_poll+0x138/0x250
 net_rx_action+0x148/0x330
 handle_softirqs+0x12c/0x3a0</Note>
    </Notes>
    <CVE>CVE-2024-45001</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Don't evict inode under the inode lru traversing context

The inode reclaiming process(See function prune_icache_sb) collects all
reclaimable inodes and mark them with I_FREEING flag at first, at that
time, other processes will be stuck if they try getting these inodes
(See function find_inode_fast), then the reclaiming process destroy the
inodes by function dispose_list(). Some filesystems(eg. ext4 with
ea_inode feature, ubifs with xattr) may do inode lookup in the inode
evicting callback function, if the inode lookup is operated under the
inode lru traversing context, deadlock problems may happen.

Case 1: In function ext4_evict_inode(), the ea inode lookup could happen
        if ea_inode feature is enabled, the lookup process will be stuck
	under the evicting context like this:

 1. File A has inode i_reg and an ea inode i_ea
 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru-&gt;i_ea
 3. Then, following three processes running like this:

    PA                              PB
 echo 2 &gt; /proc/sys/vm/drop_caches
  shrink_slab
   prune_dcache_sb
   // i_reg is added into lru, lru-&gt;i_ea-&gt;i_reg
   prune_icache_sb
    list_lru_walk_one
     inode_lru_isolate
      i_ea-&gt;i_state |= I_FREEING // set inode state
     inode_lru_isolate
      __iget(i_reg)
      spin_unlock(&amp;i_reg-&gt;i_lock)
      spin_unlock(lru_lock)
                                     rm file A
                                      i_reg-&gt;nlink = 0
      iput(i_reg) // i_reg-&gt;nlink is 0, do evict
       ext4_evict_inode
        ext4_xattr_delete_inode
         ext4_xattr_inode_dec_ref_all
          ext4_xattr_inode_iget
           ext4_iget(i_ea-&gt;i_ino)
            iget_locked
             find_inode_fast
              __wait_on_freeing_inode(i_ea) -----&gt; AA deadlock
    dispose_list // cannot be executed by prune_icache_sb
     wake_up_bit(&amp;i_ea-&gt;i_state)

Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file
        deleting process holds BASEHD's wbuf-&gt;io_mutex while getting the
	xattr inode, which could race with inode reclaiming process(The
        reclaiming process could try locking BASEHD's wbuf-&gt;io_mutex in
	inode evicting function), then an ABBA deadlock problem would
	happen as following:

 1. File A has inode ia and a xattr(with inode ixa), regular file B has
    inode ib and a xattr.
 2. getfattr(A, xattr_buf) // ixa is added into lru // lru-&gt;ixa
 3. Then, following three processes running like this:

        PA                PB                        PC
                echo 2 &gt; /proc/sys/vm/drop_caches
                 shrink_slab
                  prune_dcache_sb
                  // ib and ia are added into lru, lru-&gt;ixa-&gt;ib-&gt;ia
                  prune_icache_sb
                   list_lru_walk_one
                    inode_lru_isolate
                     ixa-&gt;i_state |= I_FREEING // set inode state
                    inode_lru_isolate
                     __iget(ib)
                     spin_unlock(&amp;ib-&gt;i_lock)
                     spin_unlock(lru_lock)
                                                   rm file B
                                                    ib-&gt;nlink = 0
 rm file A
  iput(ia)
   ubifs_evict_inode(ia)
    ubifs_jnl_delete_inode(ia)
     ubifs_jnl_write_inode(ia)
      make_reservation(BASEHD) // Lock wbuf-&gt;io_mutex
      ubifs_iget(ixa-&gt;i_ino)
       iget_locked
        find_inode_fast
         __wait_on_freeing_inode(ixa)
          |          iput(ib) // ib-&gt;nlink is 0, do evict
          |           ubifs_evict_inode
          |            ubifs_jnl_delete_inode(ib)
          ↓             ubifs_jnl_write_inode
     ABBA deadlock &lt;------make_reservation(BASEHD)
                   dispose_list // cannot be executed by prune_icache_sb
                    wake_up_bit(&amp;ixa-&gt;i_state)

Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING
to pin the inode in memory while inode_lru_isolate(
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-45003</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix Panther point NULL pointer deref at full-speed re-enumeration

re-enumerating full-speed devices after a failed address device command
can trigger a NULL pointer dereference.

Full-speed devices may need to reconfigure the endpoint 0 Max Packet Size
value during enumeration. Usb core calls usb_ep0_reinit() in this case,
which ends up calling xhci_configure_endpoint().

On Panther point xHC the xhci_configure_endpoint() function will
additionally check and reserve bandwidth in software. Other hosts do
this in hardware

If xHC address device command fails then a new xhci_virt_device structure
is allocated as part of re-enabling the slot, but the bandwidth table
pointers are not set up properly here.
This triggers the NULL pointer dereference the next time usb_ep0_reinit()
is called and xhci_configure_endpoint() tries to check and reserve
bandwidth

[46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd
[46710.713699] usb 3-1: Device not responding to setup address.
[46710.917684] usb 3-1: Device not responding to setup address.
[46711.125536] usb 3-1: device not accepting address 5, error -71
[46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008
[46711.125600] #PF: supervisor read access in kernel mode
[46711.125603] #PF: error_code(0x0000) - not-present page
[46711.125606] PGD 0 P4D 0
[46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI
[46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1
[46711.125620] Hardware name: Gigabyte Technology Co., Ltd.
[46711.125623] Workqueue: usb_hub_wq hub_event [usbcore]
[46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c

Fix this by making sure bandwidth table pointers are set up correctly
after a failed address device command, and additionally by avoiding
checking for bandwidth in cases like this where no actual endpoints are
added or removed, i.e. only context for default control endpoint 0 is
evaluated.</Note>
    </Notes>
    <CVE>CVE-2024-45006</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

char: xillybus: Don't destroy workqueue from work item running on it

Triggered by a kref decrement, destroy_workqueue() may be called from
within a work item for destroying its own workqueue. This illegal
situation is averted by adding a module-global workqueue for exclusive
use of the offending work item. Other work items continue to be queued
on per-device workqueues to ensure performance.</Note>
    </Notes>
    <CVE>CVE-2024-45007</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: MT - limit max slots

syzbot is reporting too large allocation at input_mt_init_slots(), for
num_slots is supplied from userspace using ioctl(UI_DEV_CREATE).

Since nobody knows possible max slots, this patch chose 1024.</Note>
    </Notes>
    <CVE>CVE-2024-45008</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

char: xillybus: Check USB endpoints when probing device

Ensure, as the driver probes the device, that all endpoints that the
driver may attempt to access exist and are of the correct type.

All XillyUSB devices must have a Bulk IN and Bulk OUT endpoint at
address 1. This is verified in xillyusb_setup_base_eps().

On top of that, a XillyUSB device may have additional Bulk OUT
endpoints. The information about these endpoints' addresses is deduced
from a data structure (the IDT) that the driver fetches from the device
while probing it. These endpoints are checked in setup_channels().

A XillyUSB device never has more than one IN endpoint, as all data
towards the host is multiplexed in this single Bulk IN endpoint. This is
why setup_channels() only checks OUT endpoints.</Note>
    </Notes>
    <CVE>CVE-2024-45011</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: move stopping keep-alive into nvme_uninit_ctrl()

Commit 4733b65d82bd ("nvme: start keep-alive after admin queue setup")
moves starting keep-alive from nvme_start_ctrl() into
nvme_init_ctrl_finish(), but don't move stopping keep-alive into
nvme_uninit_ctrl(), so keep-alive work can be started and keep pending
after failing to start controller, finally use-after-free is triggered if
nvme host driver is unloaded.

This patch fixes kernel panic when running nvme/004 in case that connection
failure is triggered, by moving stopping keep-alive into nvme_uninit_ctrl().

This way is reasonable because keep-alive is now started in
nvme_init_ctrl_finish().</Note>
    </Notes>
    <CVE>CVE-2024-45013</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/dpu: move dpu_encoder's connector assignment to atomic_enable()

For cases where the crtc's connectors_changed was set without enable/active
getting toggled , there is an atomic_enable() call followed by an
atomic_disable() but without an atomic_mode_set().

This results in a NULL ptr access for the dpu_encoder_get_drm_fmt() call in
the atomic_enable() as the dpu_encoder's connector was cleared in the
atomic_disable() but not re-assigned as there was no atomic_mode_set() call.

Fix the NULL ptr access by moving the assignment for atomic_enable() and also
use drm_atomic_get_new_connector_for_encoder() to get the connector from
the atomic_state.

Patchwork: https://patchwork.freedesktop.org/patch/606729/</Note>
    </Notes>
    <CVE>CVE-2024-45015</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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: flowtable: initialise extack before use

Fix missing initialisation of extack in flow offload.</Note>
    </Notes>
    <CVE>CVE-2024-45018</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 kernel verifier crash in stacksafe()

Daniel Hodges reported a kernel verifier crash when playing with sched-ext.
Further investigation shows that the crash is due to invalid memory access
in stacksafe(). More specifically, it is the following code:

    if (exact != NOT_EXACT &amp;&amp;
        old-&gt;stack[spi].slot_type[i % BPF_REG_SIZE] !=
        cur-&gt;stack[spi].slot_type[i % BPF_REG_SIZE])
            return false;

The 'i' iterates old-&gt;allocated_stack.
If cur-&gt;allocated_stack &lt; old-&gt;allocated_stack the out-of-bound
access will happen.

To fix the issue add 'i &gt;= cur-&gt;allocated_stack' check such that if
the condition is true, stacksafe() should fail. Otherwise,
cur-&gt;stack[spi].slot_type[i % BPF_REG_SIZE] memory access is legal.</Note>
    </Notes>
    <CVE>CVE-2024-45020</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

memcg_write_event_control(): fix a user-triggerable oops

we are *not* guaranteed that anything past the terminating NUL
is mapped (let alone initialized with anything sane).</Note>
    </Notes>
    <CVE>CVE-2024-45021</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/dasd: fix error recovery leading to data corruption on ESE devices

Extent Space Efficient (ESE) or thin provisioned volumes need to be
formatted on demand during usual IO processing.

The dasd_ese_needs_format function checks for error codes that signal
the non existence of a proper track format.

The check for incorrect length is to imprecise since other error cases
leading to transport of insufficient data also have this flag set.
This might lead to data corruption in certain error cases for example
during a storage server warmstart.

Fix by removing the check for incorrect length and replacing by
explicitly checking for invalid track format in transport mode.

Also remove the check for file protected since this is not a valid
ESE handling case.</Note>
    </Notes>
    <CVE>CVE-2024-45026</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mmc: mmc_test: Fix NULL dereference on allocation failure

If the "test-&gt;highmem = alloc_pages()" allocation fails then calling
__free_pages(test-&gt;highmem) will result in a NULL dereference.  Also
change the error code to -ENOMEM instead of returning success.</Note>
    </Notes>
    <CVE>CVE-2024-45028</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: tegra: Do not mark ACPI devices as irq safe

On ACPI machines, the tegra i2c module encounters an issue due to a
mutex being called inside a spinlock. This leads to the following bug:

	BUG: sleeping function called from invalid context at kernel/locking/mutex.c:585
	...

	Call trace:
	__might_sleep
	__mutex_lock_common
	mutex_lock_nested
	acpi_subsys_runtime_resume
	rpm_resume
	tegra_i2c_xfer

The problem arises because during __pm_runtime_resume(), the spinlock
&amp;dev-&gt;power.lock is acquired before rpm_resume() is called. Later,
rpm_resume() invokes acpi_subsys_runtime_resume(), which relies on
mutexes, triggering the error.

To address this issue, devices on ACPI are now marked as not IRQ-safe,
considering the dependency of acpi_subsys_runtime_resume() on mutexes.</Note>
    </Notes>
    <CVE>CVE-2024-45029</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: aacraid: Fix double-free on probe failure

aac_probe_one() calls hardware-specific init functions through the
aac_driver_ident::init pointer, all of which eventually call down to
aac_init_adapter().

If aac_init_adapter() fails after allocating memory for aac_dev::queues,
it frees the memory but does not clear that member.

After the hardware-specific init function returns an error,
aac_probe_one() goes down an error path that frees the memory pointed to
by aac_dev::queues, resulting.in a double-free.</Note>
    </Notes>
    <CVE>CVE-2024-46673</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: dwc3: st: fix probed platform device ref count on probe error path

The probe function never performs any paltform device allocation, thus
error path "undo_platform_dev_alloc" is entirely bogus.  It drops the
reference count from the platform device being probed.  If error path is
triggered, this will lead to unbalanced device reference counts and
premature release of device resources, thus possible use-after-free when
releasing remaining devm-managed resources.</Note>
    </Notes>
    <CVE>CVE-2024-46674</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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: dwc3: core: Prevent USB core invalid event buffer address access

This commit addresses an issue where the USB core could access an
invalid event buffer address during runtime suspend, potentially causing
SMMU faults and other memory issues in Exynos platforms. The problem
arises from the following sequence.
        1. In dwc3_gadget_suspend, there is a chance of a timeout when
        moving the USB core to the halt state after clearing the
        run/stop bit by software.
        2. In dwc3_core_exit, the event buffer is cleared regardless of
        the USB core's status, which may lead to an SMMU faults and
        other memory issues. if the USB core tries to access the event
        buffer address.

To prevent this hardware quirk on Exynos platforms, this commit ensures
that the event buffer address is not cleared by software  when the USB
core is active during runtime suspend by checking its status before
clearing the buffer address.</Note>
    </Notes>
    <CVE>CVE-2024-46675</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: pn533: Add poll mod list filling check

In case of im_protocols value is 1 and tm_protocols value is 0 this
combination successfully passes the check
'if (!im_protocols &amp;&amp; !tm_protocols)' in the nfc_start_poll().
But then after pn533_poll_create_mod_list() call in pn533_start_poll()
poll mod list will remain empty and dev-&gt;poll_mod_count will remain 0
which lead to division by zero.

Normally no im protocol has value 1 in the mask, so this combination is
not expected by driver. But these protocol values actually come from
userspace via Netlink interface (NFC_CMD_START_POLL operation). So a
broken or malicious program may pass a message containing a "bad"
combination of protocol parameter values so that dev-&gt;poll_mod_count
is not incremented inside pn533_poll_create_mod_list(), thus leading
to division by zero.
Call trace looks like:
nfc_genl_start_poll()
  nfc_start_poll()
    -&gt;start_poll()
    pn533_start_poll()

Add poll mod list filling check.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2024-46676</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gtp: fix a potential NULL pointer dereference

When sockfd_lookup() fails, gtp_encap_enable_socket() returns a
NULL pointer, but its callers only check for error pointers thus miss
the NULL pointer case.

Fix it by returning an error pointer with the error code carried from
sockfd_lookup().

(I found this bug during code inspection.)</Note>
    </Notes>
    <CVE>CVE-2024-46677</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: check device is present when getting link settings

A sysfs reader can race with a device reset or removal, attempting to
read device state when the device is not actually present. eg:

     [exception RIP: qed_get_current_link+17]
  #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]
  #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3
 #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4
 #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300
 #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c
 #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b
 #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3
 #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1
 #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f
 #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb

 crash&gt; struct net_device.state ffff9a9d21336000
    state = 5,

state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).
The device is not present, note lack of __LINK_STATE_PRESENT (0b10).

This is the same sort of panic as observed in commit 4224cfd7fb65
("net-sysfs: add check for netdevice being present to speed_show").

There are many other callers of __ethtool_get_link_ksettings() which
don't have a device presence check.

Move this check into ethtool to protect all callers.</Note>
    </Notes>
    <CVE>CVE-2024-46679</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: single: fix potential NULL dereference in pcs_get_function()

pinmux_generic_get_function() can return NULL and the pointer 'function'
was dereferenced without checking against NULL. Add checking of pointer
'function' in pcs_get_function().

Found by code review.</Note>
    </Notes>
    <CVE>CVE-2024-46685</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: avoid dereferencing rdata=NULL in smb2_new_read_req()

This happens when called from SMB2_read() while using rdma
and reaching the rdma_readwrite_threshold.</Note>
    </Notes>
    <CVE>CVE-2024-46686</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: cmd-db: Map shared memory as WC, not WB

Linux does not write into cmd-db region. This region of memory is write
protected by XPU. XPU may sometime falsely detect clean cache eviction
as "write" into the write protected region leading to secure interrupt
which causes an endless loop somewhere in Trust Zone.

The only reason it is working right now is because Qualcomm Hypervisor
maps the same region as Non-Cacheable memory in Stage 2 translation
tables. The issue manifests if we want to use another hypervisor (like
Xen or KVM), which does not know anything about those specific mappings.

Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC
removes dependency on correct mappings in Stage 2 tables. This patch
fixes the issue by updating the mapping to MEMREMAP_WC.

I tested this on SA8155P with Xen.</Note>
    </Notes>
    <CVE>CVE-2024-46689</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 using null object of framebuffer

Instead of using state-&gt;fb-&gt;obj[0] directly, get object from framebuffer
by calling drm_gem_fb_get_obj() and return error code when object is
null to avoid using null object of framebuffer.

(cherry picked from commit 73dd0ad9e5dad53766ea3e631303430116f834b3)</Note>
    </Notes>
    <CVE>CVE-2024-46694</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

thunderbolt: Mark XDomain as unplugged when router is removed

I noticed that when we do discrete host router NVM upgrade and it gets
hot-removed from the PCIe side as a result of NVM firmware authentication,
if there is another host connected with enabled paths we hang in tearing
them down. This is due to fact that the Thunderbolt networking driver
also tries to cleanup the paths and ends up blocking in
tb_disconnect_xdomain_paths() waiting for the domain lock.

However, at this point we already cleaned the paths in tb_stop() so
there is really no need for tb_disconnect_xdomain_paths() to do that
anymore. Furthermore it already checks if the XDomain is unplugged and
bails out early so take advantage of that and mark the XDomain as
unplugged when we remove the parent router.</Note>
    </Notes>
    <CVE>CVE-2024-46702</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3

On a system with a GICv3, if a guest hasn't been configured with
GICv3 and that the host is not capable of GICv2 emulation,
a write to any of the ICC_*SGI*_EL1 registers is trapped to EL2.

We therefore try to emulate the SGI access, only to hit a NULL
pointer as no private interrupt is allocated (no GIC, remember?).

The obvious fix is to give the guest what it deserves, in the
shape of a UNDEF exception.</Note>
    </Notes>
    <CVE>CVE-2024-46707</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 wbscl_set_scaler_filter if filter is null

Callers can pass null in filter (i.e. from returned from the function
wbscl_get_filter_coeffs_16p) and a null check is added to ensure that is
not the case.

This fixes 4 NULL_RETURNS issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-46714</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: iio: add missing checks on iio_info's callback access

Some callbacks from iio_info structure are accessed without any check, so
if a driver doesn't implement them trying to access the corresponding
sysfs entries produce a kernel oops such as:

[ 2203.527791] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute
[...]
[ 2203.783416] Call trace:
[ 2203.783429]  iio_read_channel_info_avail from dev_attr_show+0x18/0x48
[ 2203.789807]  dev_attr_show from sysfs_kf_seq_show+0x90/0x120
[ 2203.794181]  sysfs_kf_seq_show from seq_read_iter+0xd0/0x4e4
[ 2203.798555]  seq_read_iter from vfs_read+0x238/0x2a0
[ 2203.802236]  vfs_read from ksys_read+0xa4/0xd4
[ 2203.805385]  ksys_read from ret_fast_syscall+0x0/0x54
[ 2203.809135] Exception stack(0xe0badfa8 to 0xe0badff0)
[ 2203.812880] dfa0:                   00000003 b6f10f80 00000003 b6eab000 00020000 00000000
[ 2203.819746] dfc0: 00000003 b6f10f80 7ff00000 00000003 00000003 00000000 00020000 00000000
[ 2203.826619] dfe0: b6e1bc88 bed80958 b6e1bc94 b6e1bcb0
[ 2203.830363] Code: bad PC value
[ 2203.832695] ---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2024-46715</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dmaengine: altera-msgdma: properly free descriptor in msgdma_free_descriptor

Remove list_del call in msgdma_chan_desc_cleanup, this should be the role
of msgdma_free_descriptor. In consequence replace list_add_tail with
list_move_tail in msgdma_free_descriptor.

This fixes the path:
   msgdma_free_chan_resources -&gt; msgdma_free_descriptors -&gt;
   msgdma_free_desc_list -&gt; msgdma_free_descriptor

which does not correctly free the descriptors as first nodes were not
removed from the list.</Note>
    </Notes>
    <CVE>CVE-2024-46716</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: SHAMPO, Fix incorrect page release

Under the following conditions:
1) No skb created yet
2) header_size == 0 (no SHAMPO header)
3) header_index + 1 % MLX5E_SHAMPO_WQ_HEADER_PER_PAGE == 0 (this is the
   last page fragment of a SHAMPO header page)

a new skb is formed with a page that is NOT a SHAMPO header page (it
is a regular data page). Further down in the same function
(mlx5e_handle_rx_cqe_mpwrq_shampo()), a SHAMPO header page from
header_index is released. This is wrong and it leads to SHAMPO header
pages being released more than once.</Note>
    </Notes>
    <CVE>CVE-2024-46717</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ucsi: Fix null pointer dereference in trace

ucsi_register_altmode checks IS_ERR for the alt pointer and treats
NULL as valid. When CONFIG_TYPEC_DP_ALTMODE is not enabled,
ucsi_register_displayport returns NULL which causes a NULL pointer
dereference in trace. Rather than return NULL, call
typec_port_register_altmode to register DisplayPort alternate mode
as a non-controllable mode when CONFIG_TYPEC_DP_ALTMODE is not enabled.</Note>
    </Notes>
    <CVE>CVE-2024-46719</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 dereference after null check

check the pointer hive before use.</Note>
    </Notes>
    <CVE>CVE-2024-46720</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 mc_data out-of-bounds read warning

Clear warning that read mc_data[i-1] may out-of-bounds.</Note>
    </Notes>
    <CVE>CVE-2024-46722</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 ucode out-of-bounds read warning

Clear warning that read ucode[] may out-of-bounds.</Note>
    </Notes>
    <CVE>CVE-2024-46723</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 out-of-bounds read of df_v1_7_channel_number

Check the fb_channel_number range to avoid the array out-of-bounds
read error</Note>
    </Notes>
    <CVE>CVE-2024-46724</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 out-of-bounds write warning

Check the ring type value to fix the out-of-bounds
write warning</Note>
    </Notes>
    <CVE>CVE-2024-46725</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Ensure index calculation will not overflow

[WHY &amp; HOW]
Make sure vmid0p72_idx, vnom0p8_idx and vmax0p9_idx calculation will
never overflow and exceess array size.

This fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-46726</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 index for aux_rd_interval before using

aux_rd_interval has size of 7 and should be checked.

This fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-46728</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Ensure array index tg_inst won't be -1

[WHY &amp; HOW]
tg_inst will be a negative if timing_generator_count equals 0, which
should be checked before used.

This fixes 2 OVERRUN issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-46730</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 the Out-of-bounds read warning

using index i - 1U may beyond element index
for mc_data[] when i = 0.</Note>
    </Notes>
    <CVE>CVE-2024-46731</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Assign linear_pitch_alignment even for VM

[Description]
Assign linear_pitch_alignment so we don't cause a divide by 0
error in VM environments</Note>
    </Notes>
    <CVE>CVE-2024-46732</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-tcp: fix kernel crash if commands allocation fails

If the commands allocation fails in nvmet_tcp_alloc_cmds()
the kernel crashes in nvmet_tcp_release_queue_work() because of
a NULL pointer dereference.

  nvmet: failed to install queue 0 cntlid 1 ret 6
  Unable to handle kernel NULL pointer dereference at
         virtual address 0000000000000008

Fix the bug by setting queue-&gt;nr_cmds to zero in case
nvmet_tcp_alloc_cmd() fails.</Note>
    </Notes>
    <CVE>CVE-2024-46737</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

VMCI: Fix use-after-free when removing resource in vmci_resource_remove()

When removing a resource from vmci_resource_table in
vmci_resource_remove(), the search is performed using the resource
handle by comparing context and resource fields.

It is possible though to create two resources with different types
but same handle (same context and resource fields).

When trying to remove one of the resources, vmci_resource_remove()
may not remove the intended one, but the object will still be freed
as in the case of the datagram type in vmci_datagram_destroy_handle().
vmci_resource_table will still hold a pointer to this freed resource
leading to a use-after-free vulnerability.

BUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]
BUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147
Read of size 4 at addr ffff88801c16d800 by task syz-executor197/1592
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106
 print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239
 __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425
 kasan_report+0x38/0x51 mm/kasan/report.c:442
 vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]
 vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147
 vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182
 ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444
 kref_put include/linux/kref.h:65 [inline]
 vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline]
 vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195
 vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143
 __fput+0x261/0xa34 fs/file_table.c:282
 task_work_run+0xf0/0x194 kernel/task_work.c:164
 tracehook_notify_resume include/linux/tracehook.h:189 [inline]
 exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187
 exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220
 __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline]
 syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313
 do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86
 entry_SYSCALL_64_after_hwframe+0x6e/0x0

This change ensures the type is also checked when removing
the resource from vmci_resource_table in vmci_resource_remove().</Note>
    </Notes>
    <CVE>CVE-2024-46738</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

uio_hv_generic: Fix kernel NULL pointer dereference in hv_uio_rescind

For primary VM Bus channels, primary_channel pointer is always NULL. This
pointer is valid only for the secondary channels. Also, rescind callback
is meant for primary channels only.

Fix NULL pointer dereference by retrieving the device_obj from the parent
for the primary channel.</Note>
    </Notes>
    <CVE>CVE-2024-46739</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

of/irq: Prevent device address out-of-bounds read in interrupt map walk

When of_irq_parse_raw() is invoked with a device address smaller than
the interrupt parent node (from #address-cells property), KASAN detects
the following out-of-bounds read when populating the initial match table
(dyndbg="func of_irq_parse_* +p"):

  OF: of_irq_parse_one: dev=/soc@0/picasso/watchdog, index=0
  OF:  parent=/soc@0/pci@878000000000/gpio0@17,0, intsize=2
  OF:  intspec=4
  OF: of_irq_parse_raw: ipar=/soc@0/pci@878000000000/gpio0@17,0, size=2
  OF:  -&gt; addrsize=3
  ==================================================================
  BUG: KASAN: slab-out-of-bounds in of_irq_parse_raw+0x2b8/0x8d0
  Read of size 4 at addr ffffff81beca5608 by task bash/764

  CPU: 1 PID: 764 Comm: bash Tainted: G           O       6.1.67-484c613561-nokia_sm_arm64 #1
  Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.01-12.24.03-dirty 01/01/2023
  Call trace:
   dump_backtrace+0xdc/0x130
   show_stack+0x1c/0x30
   dump_stack_lvl+0x6c/0x84
   print_report+0x150/0x448
   kasan_report+0x98/0x140
   __asan_load4+0x78/0xa0
   of_irq_parse_raw+0x2b8/0x8d0
   of_irq_parse_one+0x24c/0x270
   parse_interrupts+0xc0/0x120
   of_fwnode_add_links+0x100/0x2d0
   fw_devlink_parse_fwtree+0x64/0xc0
   device_add+0xb38/0xc30
   of_device_add+0x64/0x90
   of_platform_device_create_pdata+0xd0/0x170
   of_platform_bus_create+0x244/0x600
   of_platform_notify+0x1b0/0x254
   blocking_notifier_call_chain+0x9c/0xd0
   __of_changeset_entry_notify+0x1b8/0x230
   __of_changeset_apply_notify+0x54/0xe4
   of_overlay_fdt_apply+0xc04/0xd94
   ...

  The buggy address belongs to the object at ffffff81beca5600
   which belongs to the cache kmalloc-128 of size 128
  The buggy address is located 8 bytes inside of
   128-byte region [ffffff81beca5600, ffffff81beca5680)

  The buggy address belongs to the physical page:
  page:00000000230d3d03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1beca4
  head:00000000230d3d03 order:1 compound_mapcount:0 compound_pincount:0
  flags: 0x8000000000010200(slab|head|zone=2)
  raw: 8000000000010200 0000000000000000 dead000000000122 ffffff810000c300
  raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000
  page dumped because: kasan: bad access detected

  Memory state around the buggy address:
   ffffff81beca5500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
   ffffff81beca5580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
  &gt;ffffff81beca5600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                        ^
   ffffff81beca5680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
   ffffff81beca5700: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc
  ==================================================================
  OF:  -&gt; got it !

Prevent the out-of-bounds read by copying the device address into a
buffer of sufficient size.</Note>
    </Notes>
    <CVE>CVE-2024-46743</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Squashfs: sanity check symbolic link size

Syzkiller reports a "KMSAN: uninit-value in pick_link" bug.

This is caused by an uninitialised page, which is ultimately caused
by a corrupted symbolic link size read from disk.

The reason why the corrupted symlink size causes an uninitialised
page is due to the following sequence of events:

1. squashfs_read_inode() is called to read the symbolic
   link from disk.  This assigns the corrupted value
   3875536935 to inode-&gt;i_size.

2. Later squashfs_symlink_read_folio() is called, which assigns
   this corrupted value to the length variable, which being a
   signed int, overflows producing a negative number.

3. The following loop that fills in the page contents checks that
   the copied bytes is less than length, which being negative means
   the loop is skipped, producing an uninitialised page.

This patch adds a sanity check which checks that the symbolic
link size is not larger than expected.

--

V2: fix spelling mistake.</Note>
    </Notes>
    <CVE>CVE-2024-46744</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: uinput - reject requests with unreasonable number of slots


When exercising uinput interface syzkaller may try setting up device
with a really large number of slots, which causes memory allocation
failure in input_mt_init_slots(). While this allocation failure is
handled properly and request is rejected, it results in syzkaller
reports. Additionally, such request may put undue burden on the
system which will try to free a lot of memory for a bogus request.

Fix it by limiting allowed number of slots to 100. This can easily
be extended if we see devices that can track more than 100 contacts.</Note>
    </Notes>
    <CVE>CVE-2024-46745</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: free driver_data after destroying hid device

HID driver callbacks aren't called anymore once hid_destroy_device() has
been called. Hence, hid driver_data should be freed only after the
hid_destroy_device() function returned as driver_data is used in several
callbacks.

I observed a crash with kernel 6.10.0 on my T14s Gen 3, after enabling
KASAN to debug memory allocation, I got this output:

  [   13.050438] ==================================================================
  [   13.054060] BUG: KASAN: slab-use-after-free in amd_sfh_get_report+0x3ec/0x530 [amd_sfh]
  [   13.054809] psmouse serio1: trackpoint: Synaptics TrackPoint firmware: 0x02, buttons: 3/3
  [   13.056432] Read of size 8 at addr ffff88813152f408 by task (udev-worker)/479

  [   13.060970] CPU: 5 PID: 479 Comm: (udev-worker) Not tainted 6.10.0-arch1-2 #1 893bb55d7f0073f25c46adbb49eb3785fefd74b0
  [   13.063978] Hardware name: LENOVO 21CQCTO1WW/21CQCTO1WW, BIOS R22ET70W (1.40 ) 03/21/2024
  [   13.067860] Call Trace:
  [   13.069383] input: TPPS/2 Synaptics TrackPoint as /devices/platform/i8042/serio1/input/input8
  [   13.071486]  &lt;TASK&gt;
  [   13.071492]  dump_stack_lvl+0x5d/0x80
  [   13.074870] snd_hda_intel 0000:33:00.6: enabling device (0000 -&gt; 0002)
  [   13.078296]  ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]
  [   13.082199]  print_report+0x174/0x505
  [   13.085776]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
  [   13.089367]  ? srso_alias_return_thunk+0x5/0xfbef5
  [   13.093255]  ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]
  [   13.097464]  kasan_report+0xc8/0x150
  [   13.101461]  ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]
  [   13.105802]  amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]
  [   13.110303]  amdtp_hid_request+0xb8/0x110 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]
  [   13.114879]  ? srso_alias_return_thunk+0x5/0xfbef5
  [   13.119450]  sensor_hub_get_feature+0x1d3/0x540 [hid_sensor_hub 3f13be3016ff415bea03008d45d99da837ee3082]
  [   13.124097]  hid_sensor_parse_common_attributes+0x4d0/0xad0 [hid_sensor_iio_common c3a5cbe93969c28b122609768bbe23efe52eb8f5]
  [   13.127404]  ? srso_alias_return_thunk+0x5/0xfbef5
  [   13.131925]  ? __pfx_hid_sensor_parse_common_attributes+0x10/0x10 [hid_sensor_iio_common c3a5cbe93969c28b122609768bbe23efe52eb8f5]
  [   13.136455]  ? _raw_spin_lock_irqsave+0x96/0xf0
  [   13.140197]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
  [   13.143602]  ? devm_iio_device_alloc+0x34/0x50 [industrialio 3d261d5e5765625d2b052be40e526d62b1d2123b]
  [   13.147234]  ? srso_alias_return_thunk+0x5/0xfbef5
  [   13.150446]  ? __devm_add_action+0x167/0x1d0
  [   13.155061]  hid_gyro_3d_probe+0x120/0x7f0 [hid_sensor_gyro_3d 63da36a143b775846ab2dbb86c343b401b5e3172]
  [   13.158581]  ? srso_alias_return_thunk+0x5/0xfbef5
  [   13.161814]  platform_probe+0xa2/0x150
  [   13.165029]  really_probe+0x1e3/0x8a0
  [   13.168243]  __driver_probe_device+0x18c/0x370
  [   13.171500]  driver_probe_device+0x4a/0x120
  [   13.175000]  __driver_attach+0x190/0x4a0
  [   13.178521]  ? __pfx___driver_attach+0x10/0x10
  [   13.181771]  bus_for_each_dev+0x106/0x180
  [   13.185033]  ? __pfx__raw_spin_lock+0x10/0x10
  [   13.188229]  ? __pfx_bus_for_each_dev+0x10/0x10
  [   13.191446]  ? srso_alias_return_thunk+0x5/0xfbef5
  [   13.194382]  bus_add_driver+0x29e/0x4d0
  [   13.197328]  driver_register+0x1a5/0x360
  [   13.200283]  ? __pfx_hid_gyro_3d_platform_driver_init+0x10/0x10 [hid_sensor_gyro_3d 63da36a143b775846ab2dbb86c343b401b5e3172]
  [   13.203362]  do_one_initcall+0xa7/0x380
  [   13.206432]  ? __pfx_do_one_initcall+0x10/0x10
  [   13.210175]  ? srso_alias_return_thunk+0x5/0xfbef5
  [   13.213211]  ? kasan_unpoison+0x44/0x70
  [   13.216688]  do_init_module+0x238/0x750
  [   13.2196
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-46746</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: cougar: fix slab-out-of-bounds Read in cougar_report_fixup

report_fixup for the Cougar 500k Gaming Keyboard was not verifying
that the report descriptor size was correct before accessing it</Note>
    </Notes>
    <CVE>CVE-2024-46747</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Add missing bridge lock to pci_bus_lock()

One of the true positives that the cfg_access_lock lockdep effort
identified is this sequence:

  WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70
  RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70
  Call Trace:
   &lt;TASK&gt;
   ? __warn+0x8c/0x190
   ? pci_bridge_secondary_bus_reset+0x5d/0x70
   ? report_bug+0x1f8/0x200
   ? handle_bug+0x3c/0x70
   ? exc_invalid_op+0x18/0x70
   ? asm_exc_invalid_op+0x1a/0x20
   ? pci_bridge_secondary_bus_reset+0x5d/0x70
   pci_reset_bus+0x1d8/0x270
   vmd_probe+0x778/0xa10
   pci_device_probe+0x95/0x120

Where pci_reset_bus() users are triggering unlocked secondary bus resets.
Ironically pci_bus_reset(), several calls down from pci_reset_bus(), uses
pci_bus_lock() before issuing the reset which locks everything *but* the
bridge itself.

For the same motivation as adding:

  bridge = pci_upstream_bridge(dev);
  if (bridge)
    pci_dev_lock(bridge);

to pci_reset_function() for the "bus" and "cxl_bus" reset cases, add
pci_dev_lock() for @bus-&gt;self to pci_bus_lock().

[bhelgaas: squash in recursive locking deadlock fix from Keith Busch:
https://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com]</Note>
    </Notes>
    <CVE>CVE-2024-46750</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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() when 0 reference count at btrfs_lookup_extent_info()

Instead of doing a BUG_ON() handle the error by returning -EUCLEAN,
aborting the transaction and logging an error message.</Note>
    </Notes>
    <CVE>CVE-2024-46751</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: replace BUG_ON() with error handling at update_ref_for_cow()

Instead of a BUG_ON() just return an error, log an error message and
abort the transaction in case we find an extent buffer belonging to the
relocation tree that doesn't have the full backref flag set. This is
unexpected and should never happen (save for bugs or a potential bad
memory).</Note>
    </Notes>
    <CVE>CVE-2024-46752</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: handle errors from btrfs_dec_ref() properly

In walk_up_proc() we BUG_ON(ret) from btrfs_dec_ref().  This is
incorrect, we have proper error handling here, return the error.</Note>
    </Notes>
    <CVE>CVE-2024-46753</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Do not return unused priv in mwifiex_get_priv_by_id()

mwifiex_get_priv_by_id() returns the priv pointer corresponding to
the bss_num and bss_type, but without checking if the priv is actually
currently in use.
Unused priv pointers do not have a wiphy attached to them which can
lead to NULL pointer dereferences further down the callstack.  Fix
this by returning only used priv pointers which have priv-&gt;bss_mode
set to something else than NL80211_IFTYPE_UNSPECIFIED.

Said NULL pointer dereference happened when an Accesspoint was started
with wpa_supplicant -i mlan0 with this config:

network={
        ssid="somessid"
        mode=2
        frequency=2412
        key_mgmt=WPA-PSK WPA-PSK-SHA256
        proto=RSN
        group=CCMP
        pairwise=CCMP
        psk="12345678"
}

When waiting for the AP to be established, interrupting wpa_supplicant
with &lt;ctrl-c&gt; and starting it again this happens:

| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140
| 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, ISS2 = 0x00000000
|   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
|   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000
| [0000000000000140] pgd=0000000000000000, p4d=0000000000000000
| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
| Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio
+mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs
+imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6
| CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18
| Hardware name: somemachine (DT)
| Workqueue: events sdio_irq_work
| pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
| pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex]
| lr : mwifiex_get_cfp+0x34/0x15c [mwifiex]
| sp : ffff8000818b3a70
| x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004
| x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9
| x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000
| x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000
| x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517
| x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1
| x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157
| x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124
| x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000
| x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000
| Call trace:
|  mwifiex_get_cfp+0xd8/0x15c [mwifiex]
|  mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex]
|  mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex]
|  mwifiex_process_sta_event+0x298/0xf0c [mwifiex]
|  mwifiex_process_event+0x110/0x238 [mwifiex]
|  mwifiex_main_process+0x428/0xa44 [mwifiex]
|  mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio]
|  process_sdio_pending_irqs+0x64/0x1b8
|  sdio_irq_work+0x4c/0x7c
|  process_one_work+0x148/0x2a0
|  worker_thread+0x2fc/0x40c
|  kthread+0x110/0x114
|  ret_from_fork+0x10/0x20
| Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000)
| ---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2024-46755</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-46756</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-46758</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hwmon: (adc128d818) Fix underflows seen when writing limit attributes

DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large
negative number such as -9223372036854775808 is provided by the user.
Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.</Note>
    </Notes>
    <CVE>CVE-2024-46759</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/hotplug/pnv_php: Fix hotplug driver crash on Powernv

The hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel
crash when we try to hot-unplug/disable the PCIe switch/bridge from
the PHB.

The crash occurs because although the MSI data structure has been
released during disable/hot-unplug path and it has been assigned
with NULL, still during unregistration the code was again trying to
explicitly disable the MSI which causes the NULL pointer dereference and
kernel crash.

The patch fixes the check during unregistration path to prevent invoking
pci_disable_msi/msix() since its data structure is already freed.</Note>
    </Notes>
    <CVE>CVE-2024-46761</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Remove proc entry when dev is unregistered.

syzkaller reported a warning in bcm_connect() below. [0]

The repro calls connect() to vxcan1, removes vxcan1, and calls
connect() with ifindex == 0.

Calling connect() for a BCM socket allocates a proc entry.
Then, bcm_sk(sk)-&gt;bound is set to 1 to prevent further connect().

However, removing the bound device resets bcm_sk(sk)-&gt;bound to 0
in bcm_notify().

The 2nd connect() tries to allocate a proc entry with the same
name and sets NULL to bcm_sk(sk)-&gt;bcm_proc_read, leaking the
original proc entry.

Since the proc entry is available only for connect()ed sockets,
let's clean up the entry when the bound netdev is unregistered.

[0]:
proc_dir_entry 'can-bcm/2456' already registered
WARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375
Modules linked in:
CPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
RIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375
Code: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 &lt;0f&gt; 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48
RSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246
RAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002
RBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0
R10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ec
FS:  00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220
 bcm_connect+0x472/0x840 net/can/bcm.c:1673
 __sys_connect_file net/socket.c:2049 [inline]
 __sys_connect+0x5d2/0x690 net/socket.c:2066
 __do_sys_connect net/socket.c:2076 [inline]
 __se_sys_connect net/socket.c:2073 [inline]
 __x64_sys_connect+0x8f/0x100 net/socket.c:2073
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x7fbd708b0e5d
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48
RSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5d
RDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040
R10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098
R13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000
 &lt;/TASK&gt;
remove_proc_entry: removing non-empty directory 'net/can-bcm', leaking at least '2456'</Note>
    </Notes>
    <CVE>CVE-2024-46771</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 denominator pbn_div before used

[WHAT &amp; HOW]
A denominator cannot be 0, and is checked before used.

This fixes 1 DIVIDE_BY_ZERO issue reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-46773</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/rtas: Prevent Spectre v1 gadget construction in sys_rtas()

Smatch warns:

  arch/powerpc/kernel/rtas.c:1932 __do_sys_rtas() warn: potential
  spectre issue 'args.args' [r] (local cap)

The 'nargs' and 'nret' locals come directly from a user-supplied
buffer and are used as indexes into a small stack-based array and as
inputs to copy_to_user() after they are subject to bounds checks.

Use array_index_nospec() after the bounds checks to clamp these values
for speculative execution.</Note>
    </Notes>
    <CVE>CVE-2024-46774</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: protect references to superblock parameters exposed in sysfs

The superblock buffers of nilfs2 can not only be overwritten at runtime
for modifications/repairs, but they are also regularly swapped, replaced
during resizing, and even abandoned when degrading to one side due to
backing device issues.  So, accessing them requires mutual exclusion using
the reader/writer semaphore "nilfs-&gt;ns_sem".

Some sysfs attribute show methods read this superblock buffer without the
necessary mutual exclusion, which can cause problems with pointer
dereferencing and memory access, so fix it.</Note>
    </Notes>
    <CVE>CVE-2024-46780</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 missing cleanup on rollforward recovery error

In an error injection test of a routine for mount-time recovery, KASAN
found a use-after-free bug.

It turned out that if data recovery was performed using partial logs
created by dsync writes, but an error occurred before starting the log
writer to create a recovered checkpoint, the inodes whose data had been
recovered were left in the ns_dirty_files list of the nilfs object and
were not freed.

Fix this issue by cleaning up inodes that have read the recovery data if
the recovery routine fails midway before the log writer starts.</Note>
    </Notes>
    <CVE>CVE-2024-46781</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_bpf: fix return value of tcp_bpf_sendmsg()

When we cork messages in psock-&gt;cork, the last message triggers the
flushing will result in sending a sk_msg larger than the current
message size. In this case, in tcp_bpf_send_verdict(), 'copied' becomes
negative at least in the following case:

468         case __SK_DROP:
469         default:
470                 sk_msg_free_partial(sk, msg, tosend);
471                 sk_msg_apply_bytes(psock, tosend);
472                 *copied -= (tosend + delta); // &lt;==== HERE
473                 return -EACCES;

Therefore, it could lead to the following BUG with a proper value of
'copied' (thanks to syzbot). We should not use negative 'copied' as a
return value here.

  ------------[ cut here ]------------
  kernel BUG at net/socket.c:733!
  Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
  Modules linked in:
  CPU: 0 UID: 0 PID: 3265 Comm: syz-executor510 Not tainted 6.11.0-rc3-syzkaller-00060-gd07b43284ab3 #0
  Hardware name: linux,dummy-virt (DT)
  pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
  pc : sock_sendmsg_nosec net/socket.c:733 [inline]
  pc : sock_sendmsg_nosec net/socket.c:728 [inline]
  pc : __sock_sendmsg+0x5c/0x60 net/socket.c:745
  lr : sock_sendmsg_nosec net/socket.c:730 [inline]
  lr : __sock_sendmsg+0x54/0x60 net/socket.c:745
  sp : ffff800088ea3b30
  x29: ffff800088ea3b30 x28: fbf00000062bc900 x27: 0000000000000000
  x26: ffff800088ea3bc0 x25: ffff800088ea3bc0 x24: 0000000000000000
  x23: f9f00000048dc000 x22: 0000000000000000 x21: ffff800088ea3d90
  x20: f9f00000048dc000 x19: ffff800088ea3d90 x18: 0000000000000001
  x17: 0000000000000000 x16: 0000000000000000 x15: 000000002002ffaf
  x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
  x11: 0000000000000000 x10: ffff8000815849c0 x9 : ffff8000815b49c0
  x8 : 0000000000000000 x7 : 000000000000003f x6 : 0000000000000000
  x5 : 00000000000007e0 x4 : fff07ffffd239000 x3 : fbf00000062bc900
  x2 : 0000000000000000 x1 : 0000000000000000 x0 : 00000000fffffdef
  Call trace:
   sock_sendmsg_nosec net/socket.c:733 [inline]
   __sock_sendmsg+0x5c/0x60 net/socket.c:745
   ____sys_sendmsg+0x274/0x2ac net/socket.c:2597
   ___sys_sendmsg+0xac/0x100 net/socket.c:2651
   __sys_sendmsg+0x84/0xe0 net/socket.c:2680
   __do_sys_sendmsg net/socket.c:2689 [inline]
   __se_sys_sendmsg net/socket.c:2687 [inline]
   __arm64_sys_sendmsg+0x24/0x30 net/socket.c:2687
   __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
   invoke_syscall+0x48/0x110 arch/arm64/kernel/syscall.c:49
   el0_svc_common.constprop.0+0x40/0xe0 arch/arm64/kernel/syscall.c:132
   do_el0_svc+0x1c/0x28 arch/arm64/kernel/syscall.c:151
   el0_svc+0x34/0xec arch/arm64/kernel/entry-common.c:712
   el0t_64_sync_handler+0x100/0x12c arch/arm64/kernel/entry-common.c:730
   el0t_64_sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:598
  Code: f9404463 d63f0060 3108441f 54fffe81 (d4210000)
  ---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2024-46783</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mana: Fix error handling in mana_create_txq/rxq's NAPI cleanup

Currently napi_disable() gets called during rxq and txq cleanup,
even before napi is enabled and hrtimer is initialized. It causes
kernel panic.

? page_fault_oops+0x136/0x2b0
  ? page_counter_cancel+0x2e/0x80
  ? do_user_addr_fault+0x2f2/0x640
  ? refill_obj_stock+0xc4/0x110
  ? exc_page_fault+0x71/0x160
  ? asm_exc_page_fault+0x27/0x30
  ? __mmdrop+0x10/0x180
  ? __mmdrop+0xec/0x180
  ? hrtimer_active+0xd/0x50
  hrtimer_try_to_cancel+0x2c/0xf0
  hrtimer_cancel+0x15/0x30
  napi_disable+0x65/0x90
  mana_destroy_rxq+0x4c/0x2f0
  mana_create_rxq.isra.0+0x56c/0x6d0
  ? mana_uncfg_vport+0x50/0x50
  mana_alloc_queues+0x21b/0x320
  ? skb_dequeue+0x5f/0x80</Note>
    </Notes>
    <CVE>CVE-2024-46784</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fscache: delete fscache_cookie_lru_timer when fscache exits to avoid UAF

The fscache_cookie_lru_timer is initialized when the fscache module
is inserted, but is not deleted when the fscache module is removed.
If timer_reduce() is called before removing the fscache module,
the fscache_cookie_lru_timer will be added to the timer list of
the current cpu. Afterwards, a use-after-free will be triggered
in the softIRQ after removing the fscache module, as follows:

==================================================================
BUG: unable to handle page fault for address: fffffbfff803c9e9
 PF: supervisor read access in kernel mode
 PF: error_code(0x0000) - not-present page
PGD 21ffea067 P4D 21ffea067 PUD 21ffe6067 PMD 110a7c067 PTE 0
Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G W 6.11.0-rc3 #855
Tainted: [W]=WARN
RIP: 0010:__run_timer_base.part.0+0x254/0x8a0
Call Trace:
 &lt;IRQ&gt;
 tmigr_handle_remote_up+0x627/0x810
 __walk_groups.isra.0+0x47/0x140
 tmigr_handle_remote+0x1fa/0x2f0
 handle_softirqs+0x180/0x590
 irq_exit_rcu+0x84/0xb0
 sysvec_apic_timer_interrupt+0x6e/0x90
 &lt;/IRQ&gt;
 &lt;TASK&gt;
 asm_sysvec_apic_timer_interrupt+0x1a/0x20
RIP: 0010:default_idle+0xf/0x20
 default_idle_call+0x38/0x60
 do_idle+0x2b5/0x300
 cpu_startup_entry+0x54/0x60
 start_secondary+0x20d/0x280
 common_startup_64+0x13e/0x148
 &lt;/TASK&gt;
Modules linked in: [last unloaded: netfs]
==================================================================

Therefore delete fscache_cookie_lru_timer when removing the fscahe module.</Note>
    </Notes>
    <CVE>CVE-2024-46786</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

userfaultfd: fix checks for huge PMDs

Patch series "userfaultfd: fix races around pmd_trans_huge() check", v2.

The pmd_trans_huge() code in mfill_atomic() is wrong in three different
ways depending on kernel version:

1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit
   the right two race windows) - I've tested this in a kernel build with
   some extra mdelay() calls. See the commit message for a description
   of the race scenario.
   On older kernels (before 6.5), I think the same bug can even
   theoretically lead to accessing transhuge page contents as a page table
   if you hit the right 5 narrow race windows (I haven't tested this case).
2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for
   detecting PMDs that don't point to page tables.
   On older kernels (before 6.5), you'd just have to win a single fairly
   wide race to hit this.
   I've tested this on 6.1 stable by racing migration (with a mdelay()
   patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86
   VM, that causes a kernel oops in ptlock_ptr().
3. On newer kernels (&gt;=6.5), for shmem mappings, khugepaged is allowed
   to yank page tables out from under us (though I haven't tested that),
   so I think the BUG_ON() checks in mfill_atomic() are just wrong.

I decided to write two separate fixes for these (one fix for bugs 1+2, one
fix for bug 3), so that the first fix can be backported to kernels
affected by bugs 1+2.


This patch (of 2):

This fixes two issues.

I discovered that the following race can occur:

  mfill_atomic                other thread
  ============                ============
                              &lt;zap PMD&gt;
  pmdp_get_lockless() [reads none pmd]
  &lt;bail if trans_huge&gt;
  &lt;if none:&gt;
                              &lt;pagefault creates transhuge zeropage&gt;
    __pte_alloc [no-op]
                              &lt;zap PMD&gt;
  &lt;bail if pmd_trans_huge(*dst_pmd)&gt;
  BUG_ON(pmd_none(*dst_pmd))

I have experimentally verified this in a kernel with extra mdelay() calls;
the BUG_ON(pmd_none(*dst_pmd)) triggers.

On kernels newer than commit 0d940a9b270b ("mm/pgtable: allow
pte_offset_map[_lock]() to fail"), this can't lead to anything worse than
a BUG_ON(), since the page table access helpers are actually designed to
deal with page tables concurrently disappearing; but on older kernels
(&lt;=6.4), I think we could probably theoretically race past the two
BUG_ON() checks and end up treating a hugepage as a page table.

The second issue is that, as Qi Zheng pointed out, there are other types
of huge PMDs that pmd_trans_huge() can't catch: devmap PMDs and swap PMDs
(in particular, migration PMDs).

On &lt;=6.4, this is worse than the first issue: If mfill_atomic() runs on a
PMD that contains a migration entry (which just requires winning a single,
fairly wide race), it will pass the PMD to pte_offset_map_lock(), which
assumes that the PMD points to a page table.

Breakage follows: First, the kernel tries to take the PTE lock (which will
crash or maybe worse if there is no "struct page" for the address bits in
the migration entry PMD - I think at least on X86 there usually is no
corresponding "struct page" thanks to the PTE inversion mitigation, amd64
looks different).

If that didn't crash, the kernel would next try to write a PTE into what
it wrongly thinks is a page table.

As part of fixing these issues, get rid of the check for pmd_trans_huge()
before __pte_alloc() - that's redundant, we're going to have to check for
that after the __pte_alloc() anyway.

Backport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels.</Note>
    </Notes>
    <CVE>CVE-2024-46787</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open

The mcp251x_hw_wake() function is called with the mpc_lock mutex held and
disables the interrupt handler so that no interrupts can be processed while
waking the device. If an interrupt has already occurred then waiting for
the interrupt handler to complete will deadlock because it will be trying
to acquire the same mutex.

CPU0                           CPU1
----                           ----
mcp251x_open()
 mutex_lock(&amp;priv-&gt;mcp_lock)
  request_threaded_irq()
                               &lt;interrupt&gt;
                               mcp251x_can_ist()
                                mutex_lock(&amp;priv-&gt;mcp_lock)
  mcp251x_hw_wake()
   disable_irq() &lt;-- deadlock

Use disable_irq_nosync() instead because the interrupt handler does
everything while holding the mutex so it doesn't matter if it's still
running.</Note>
    </Notes>
    <CVE>CVE-2024-46791</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 data leak in mmio_read()

The mmio_read() function makes a TDVMCALL to retrieve MMIO data for an
address from the VMM.

Sean noticed that mmio_read() unintentionally exposes the value of an
initialized variable (val) on the stack to the VMM.

This variable is only needed as an output value. It did not need to be
passed to the VMM in the first place.

Do not send the original value of *val to the VMM.

[ dhansen: clarify what 'val' is used for. ]</Note>
    </Notes>
    <CVE>CVE-2024-46794</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 UAF for snd_soc_pcm_runtime object

When using kernel with the following extra config,

  - CONFIG_KASAN=y
  - CONFIG_KASAN_GENERIC=y
  - CONFIG_KASAN_INLINE=y
  - CONFIG_KASAN_VMALLOC=y
  - CONFIG_FRAME_WARN=4096

kernel detects that snd_pcm_suspend_all() access a freed
'snd_soc_pcm_runtime' object when the system is suspended, which
leads to a use-after-free bug:

[   52.047746] BUG: KASAN: use-after-free in snd_pcm_suspend_all+0x1a8/0x270
[   52.047765] Read of size 1 at addr ffff0000b9434d50 by task systemd-sleep/2330

[   52.047785] Call trace:
[   52.047787]  dump_backtrace+0x0/0x3c0
[   52.047794]  show_stack+0x34/0x50
[   52.047797]  dump_stack_lvl+0x68/0x8c
[   52.047802]  print_address_description.constprop.0+0x74/0x2c0
[   52.047809]  kasan_report+0x210/0x230
[   52.047815]  __asan_report_load1_noabort+0x3c/0x50
[   52.047820]  snd_pcm_suspend_all+0x1a8/0x270
[   52.047824]  snd_soc_suspend+0x19c/0x4e0

The snd_pcm_sync_stop() has a NULL check on 'substream-&gt;runtime' before
making any access. So we need to always set 'substream-&gt;runtime' to NULL
everytime we kfree() it.</Note>
    </Notes>
    <CVE>CVE-2024-46798</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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"/>
    </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"/>
    </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"/>
    </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"/>
    </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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry

In a review discussion of the changes to support vCPU hotplug where
a check was added on the GICC being enabled if was online, it was
noted that there is need to map back to the cpu and use that to index
into a cpumask. As such, a valid ID is needed.

If an MPIDR check fails in acpi_map_gic_cpu_interface() it is possible
for the entry in cpu_madt_gicc[cpu] == NULL.  This function would
then cause a NULL pointer dereference.   Whilst a path to trigger
this has not been established, harden this caller against the
possibility.</Note>
    </Notes>
    <CVE>CVE-2024-46822</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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:

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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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:

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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: pxafb: Fix possible use after free in pxafb_task()

In the pxafb_probe function, it calls the pxafb_init_fbinfo function,
after which &amp;fbi-&gt;task is associated with pxafb_task. Moreover,
within this pxafb_init_fbinfo function, the pxafb_blank function
within the &amp;pxafb_ops struct is capable of scheduling work.

If we remove the module which will call pxafb_remove to make cleanup,
it will call unregister_framebuffer function which can call
do_unregister_framebuffer to free fbi-&gt;fb through
put_fb_info(fb_info), while the work mentioned above will be used.
The sequence of operations that may lead to a UAF bug is as follows:

CPU0                                                CPU1

                                   | pxafb_task
pxafb_remove                       |
unregister_framebuffer(info)       |
do_unregister_framebuffer(fb_info) |
put_fb_info(fb_info)               |
// free fbi-&gt;fb                    | set_ctrlr_state(fbi, state)
                                   | __pxafb_lcd_power(fbi, 0)
                                   | fbi-&gt;lcd_power(on, &amp;fbi-&gt;fb.var)
                                   | //use fbi-&gt;fb

Fix it by ensuring that the work is canceled before proceeding
with the cleanup in pxafb_remove.

Note that only root user can remove the driver at runtime.</Note>
    </Notes>
    <CVE>CVE-2024-49924</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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: 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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:

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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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:

uprobes: fix kernel info leak via "[uprobes]" vma

xol_add_vma() maps the uninitialized page allocated by __create_xol_area()
into userspace. On some architectures (x86) this memory is readable even
without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ,
although this doesn't really matter, debugger can read this memory anyway.</Note>
    </Notes>
    <CVE>CVE-2024-49975</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write()

This was found by a static analyzer.
We should not forget the trailing zero after copy_from_user()
if we will further do some string operations, sscanf() in this
case. Adding a trailing zero will ensure that the function
performs properly.</Note>
    </Notes>
    <CVE>CVE-2024-50259</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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:

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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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"/>
    </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:

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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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/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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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:

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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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"/>
    </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">CPython 3.9 and earlier doesn't disallow configuring an empty list ("[]") for SSLContext.set_npn_protocols() which is an invalid value for the underlying OpenSSL API. This results in a buffer over-read when NPN is used (see CVE-2024-5535 for OpenSSL). This vulnerability is of low severity due to NPN being not widely used and specifying an empty list likely being uncommon in-practice (typically a protocol name would be configured).</Note>
    </Notes>
    <CVE>CVE-2024-5642</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">There is a MEDIUM severity vulnerability affecting CPython.





Regular expressions that allowed excessive backtracking during tarfile.TarFile header parsing are vulnerable to ReDoS via specifically-crafted tar archives.</Note>
    </Notes>
    <CVE>CVE-2024-6232</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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">There is a MEDIUM severity vulnerability affecting CPython.

The 
email module didn't properly quote newlines for email headers when 
serializing an email message allowing for header injection when an email
 is serialized.</Note>
    </Notes>
    <CVE>CVE-2024-6923</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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">There is a LOW severity vulnerability affecting CPython, specifically the
'http.cookies' standard library module.


When parsing cookies that contained backslashes for quoted characters in
the cookie value, the parser would use an algorithm with quadratic
complexity, resulting in excess CPU resources being used while parsing the
value.</Note>
    </Notes>
    <CVE>CVE-2024-7592</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 vulnerability has been found in the CPython `venv` module and CLI where path names provided when creating a virtual environment were not quoted properly, allowing the creator to inject commands into virtual environment "activation" scripts (ie "source venv/bin/activate"). This means that attacker-controlled virtual environments are able to run commands when the virtual environment is activated. Virtual environments which are not created by an attacker or which aren't activated before being used (ie "./venv/bin/python") are not affected.</Note>
    </Notes>
    <CVE>CVE-2024-9287</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 curl is asked to use HSTS, the expiry time for a subdomain might
overwrite a parent domain's cache entry, making it end sooner or later than
otherwise intended.

This affects curl using applications that enable HSTS and use URLs with the
insecure `HTTP://` scheme and perform transfers with hosts like
`x.example.com` as well as `example.com` where the first host is a subdomain
of the second host.

(The HSTS cache either needs to have been populated manually or there needs to
have been previous HTTPS accesses done as the cache needs to have entries for
the domains involved to trigger this problem.)

When `x.example.com` responds with `Strict-Transport-Security:` headers, this
bug can make the subdomain's expiry timeout *bleed over* and get set for the
parent domain `example.com` in curl's HSTS cache.

The result of a triggered bug is that HTTP accesses to `example.com` get
converted to HTTPS for a different period of time than what was asked for by
the origin server. If `example.com` for example stops supporting HTTPS at its
expiry time, curl might then fail to access `http://example.com` until the
(wrongly set) timeout expires. This bug can also expire the parent's entry
*earlier*, thus making curl inadvertently switch back to insecure HTTP earlier
than otherwise intended.</Note>
    </Notes>
    <CVE>CVE-2024-9681</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
</cvrfdoc>
