<?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:2551-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:2551-1</ID>
    </Identification>
    <Status>Interim</Status>
    <Version>1</Version>
    <RevisionHistory>
      <Revision>
        <Number>1</Number>
        <Date>2026-03-19T08:57:24Z</Date>
        <Description>current</Description>
      </Revision>
    </RevisionHistory>
    <InitialReleaseDate>2025-09-23T01:00:00Z</InitialReleaseDate>
    <CurrentReleaseDate>2025-09-23T01: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:2551-1 / google/sle-micro-5-2-byos-v20250923-x86-64</Note>
    <Note Title="Details" Type="General" Ordinal="2" xml:lang="en">This image update for google/sle-micro-5-2-byos-v20250923-x86-64 contains the following changes:
Package 000release-packages:SUSE-MicroOS-release was updated:

Package boost was updated:

- CVE-2016-9840: fixed out-of-bounds pointer arithmetic in zlib in beast  (bsc#1245936)
  - adds patch boost-zlib.patch

Package coreutils was updated:

- coreutils-9.7-sort-CVE-2025-5278.patch: Add upstream patch:  sort with key character offsets of SIZE_MAX, could induce
  a read of 1 byte before an allocated heap buffer.
  (CVE-2025-5278, bsc#1243767)

Package curl was updated:

- tool_operate: fix return code when --retry is used but not  triggered [bsc#1249367]
  * Add curl-tool_operate-fix-return-code-when-retry-is-used.patch

- Security fixes:
  * [bsc#1249191, CVE-2025-9086] Out of bounds read for cookie path
  * [bsc#1249348, CVE-2025-10148] Predictable WebSocket mask
  * Add patches:
  - curl-CVE-2025-9086.patch
  - curl-CVE-2025-10148.patch

- Fix the --ftp-pasv option in curl v8.14.1 [bsc#1246197]
  * tool_getparam: fix --ftp-pasv [5f805ee]
  * Add curl-fix--ftp-pasv.patch

- Update to 8.14.1: [jsc#PED-13055, jsc#PED-13056]
  * Remove pre_checkin.sh and add _multibuild
  * Rename patch from dont-mess-with-rpmoptflags.diff to
    dont-mess-with-rpmoptflags.patch
  * Rebase patches:
  - curl-disabled-redirect-protocol-message.patch
  - curl-secure-getenv.patch
  - libcurl-ocloexec.patch
  * Remove patches fixed in the update:
  - curl-CVE-2020-8169.patch
  - curl-CVE-2020-8177.patch
  - curl-CVE-2020-8231.patch
  - curl-CVE-2020-8284.patch
  - curl-CVE-2020-8285.patch
  - curl-CVE-2020-8286.patch
  - curl-CVE-2021-22876.patch
  - curl-CVE-2021-22890.patch
  - curl-CVE-2021-22898.patch
  - curl-CVE-2021-22924.patch
  - curl-CVE-2021-22925.patch
  - curl-CVE-2021-22946.patch
  - curl-CVE-2021-22947.patch
  - curl-CVE-2022-22576.patch
  - curl-CVE-2022-27775.patch
  - curl-CVE-2022-27776.patch
  - curl-CVE-2022-27781.patch
  - curl-CVE-2022-27782.patch
  - curl-CVE-2022-32206.patch
  - curl-CVE-2022-32208.patch
  - curl-CVE-2022-32221.patch
  - curl-CVE-2022-35252.patch
  - curl-CVE-2022-43552.patch
  - curl-CVE-2023-23916.patch
  - curl-CVE-2023-27533-no-sscanf.patch
  - curl-CVE-2023-27533.patch
  - curl-CVE-2023-27534-dynbuf.patch
  - curl-CVE-2023-27534-tilde-back.patch
  - curl-CVE-2023-27534.patch
  - curl-CVE-2023-27535.patch
  - curl-CVE-2023-27536.patch
  - curl-CVE-2023-27538.patch
  - curl-CVE-2023-28320.patch
  - curl-CVE-2023-28321.patch
  - curl-CVE-2023-28322.patch
  - curl-CVE-2023-38546.patch
  - curl-CVE-2023-46218.patch
  - curl-CVE-2024-11053.patch
  - curl-CVE-2024-2398.patch
  - curl-CVE-2024-7264.patch
  - curl-CVE-2024-8096.patch
  - curl-CVE-2025-0167.patch
  - curl-CVE-2025-0725.patch
  - curl-X509_V_FLAG_PARTIAL_CHAIN.patch
  - curl-check-content-type.patch
  - curl-expire-clear.patch
  - curl-http-lowercase-headernames-for-HTTP-2-and-HTTP-3.patch
  - curl-libssh_Implement_SFTP_packet_size_limit.patch
  - curl-use_OPENSSL_config.patch
  - ignore_runtests_failure.patch

- Sync spec file with SLE codestreams: [jsc#PED-13055, jsc#PED-13056]
  * Add curl-mini.rpmlintrc to avoid rpmlint shlib-policy-name-error
    when building the curl-mini package in SLE.
  * Add libssh minimum version requirements.
  * Use ldconfig_scriptlets when available.
  * Remove unused option --disable-ntlm-wb.

Package docker was updated:

- Update to Docker 28.3.3-ce. See upstream changelog online at  &amp;lt;https://docs.docker.com/engine/release-notes/28/#2833&amp;gt;
  CVE-2025-54388 bsc#1247367

- Update to docker-buildx v0.26.1. Upstream changelog:
  &amp;lt;https://github.com/docker/buildx/releases/tag/v0.26.1&amp;gt;

- Update to docker-buildx v0.26.0. Upstream changelog:
  &amp;lt;https://github.com/docker/buildx/releases/tag/v0.26.0&amp;gt;

- Update to Go 1.24 for builds, to match upstream.

- Update to Docker 28.3.2-ce. See upstream changelog online at
  &amp;lt;https://docs.docker.com/engine/release-notes/28/#2832&amp;gt;

- Update to Docker 28.3.1-ce. See upstream changelog online at
  &amp;lt;https://docs.docker.com/engine/release-notes/28/#2831&amp;gt;

- Update to Docker 28.3.0-ce. See upstream changelog online at
  &amp;lt;https://docs.docker.com/engine/release-notes/28/#2830&amp;gt;
  bsc#1246556
- Rebase patches:
  * 0001-SECRETS-SUSE-always-clear-our-internal-secrets.patch
  * 0002-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  * 0003-SECRETS-SUSE-implement-SUSE-container-secrets.patch
  * 0004-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  * 0005-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  * 0006-SLE12-revert-apparmor-remove-version-conditionals-fr.patch

[ This update is a no-op, only needed to work around unfortunate automated
  packaging script behaviour on SLES. ]
- The following patches were removed in openSUSE in the Docker 28.1.1-ce
  update, but the patch names were later renamed in a SLES-only update before
  Docker 28.1.1-ce was submitted to SLES.
  This causes the SLES build scripts to refuse the update because the patches
  are not referenced in the changelog. There is no obvious place to put the
  patch removals (the 28.1.1-ce update removing the patches chronologically
  predates their renaming in SLES), so they are included here a dummy changelog
  entry to work around the issue.
  - 0007-CVE-2025-22868-vendor-jws-split-token-into-fixed-num.patch
  - 0008-CVE-2025-22869-vendor-ssh-limit-the-size-of-the-inte.patch

- Update to docker-buildx v0.25.0. Upstream changelog:
  &amp;lt;https://github.com/docker/buildx/releases/tag/v0.25.0&amp;gt;

- Do not try to inject SUSEConnect secrets when in Rootless Docker mode, as
  Docker does not have permission to access the host zypper credentials in this
  mode (and unprivileged users cannot disable the feature using
  /etc/docker/suse-secrets-enable.) bsc#1240150
  * 0003-SECRETS-SUSE-implement-SUSE-container-secrets.patch
- Rebase patches:
  * 0001-SECRETS-SUSE-always-clear-our-internal-secrets.patch
  * 0002-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  * 0004-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  * 0005-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  * 0006-SLE12-revert-apparmor-remove-version-conditionals-fr.patch

- Always clear SUSEConnect suse_* secrets when starting containers regardless
  of whether the daemon was built with SUSEConnect support. Not doing this
  causes containers from SUSEConnect-enabled daemons to fail to start when
  running with SUSEConnect-disabled (i.e. upstream) daemons.
  This was a long-standing issue with our secrets support but until recently
  this would've required migrating from SLE packages to openSUSE packages
  (which wasn't supported). However, as SLE Micro 6.x and SLES 16 will move
  away from in-built SUSEConnect support, this is now a practical issue users
  will run into. bsc#1244035
  + 0001-SECRETS-SUSE-always-clear-our-internal-secrets.patch
- Rearrange patches:
  - 0001-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  + 0002-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  - 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch
  + 0003-SECRETS-SUSE-implement-SUSE-container-secrets.patch
  - 0003-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  + 0004-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  - 0004-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  + 0005-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  - 0005-SLE12-revert-apparmor-remove-version-conditionals-fr.patch
  + 0006-SLE12-revert-apparmor-remove-version-conditionals-fr.patch

[NOTE: This update was only ever released in SLES and Leap.]
- Always clear SUSEConnect suse_* secrets when starting containers regardless
  of whether the daemon was built with SUSEConnect support. Not doing this
  causes containers from SUSEConnect-enabled daemons to fail to start when
  running with SUSEConnect-disabled (i.e. upstream) daemons.
  This was a long-standing issue with our secrets support but until recently
  this would've required migrating from SLE packages to openSUSE packages
  (which wasn't supported). However, as SLE Micro 6.x and SLES 16 will move
  away from in-built SUSEConnect support, this is now a practical issue users
  will run into. bsc#1244035
  + 0001-SECRETS-SUSE-always-clear-our-internal-secrets.patch
- Rearrange patches:
  - 0001-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  + 0002-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  - 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch
  + 0003-SECRETS-SUSE-implement-SUSE-container-secrets.patch
  - 0003-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  + 0004-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  - 0004-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  + 0005-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  - 0005-SLE12-revert-apparmor-remove-version-conditionals-fr.patch
  + 0006-SLE12-revert-apparmor-remove-version-conditionals-fr.patch
  - 0006-CVE-2025-22868-vendor-jws-split-token-into-fixed-num.patch
  + 0007-CVE-2025-22868-vendor-jws-split-token-into-fixed-num.patch
  - 0007-CVE-2025-22869-vendor-ssh-limit-the-size-of-the-inte.patch
  + 0008-CVE-2025-22869-vendor-ssh-limit-the-size-of-the-inte.patch

- Update to Docker 28.2.2-ce. See upstream changelog online at
  &amp;lt;https://docs.docker.com/engine/release-notes/28/#2822&amp;gt;
- Rebase patches:
  * 0001-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  * 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch
  * 0003-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  * 0004-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  * 0005-SLE12-revert-apparmor-remove-version-conditionals-fr.patch

- Update to Docker 28.2.1-ce. See upstream changelog online at
  &amp;lt;https://docs.docker.com/engine/release-notes/28/#2820&amp;gt; bsc#1243833
  &amp;lt;https://github.com/moby/moby/releases/tag/v28.2.1&amp;gt;
- Rebase patches:
  * 0001-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  * 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch
  * 0003-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  * 0004-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  * 0005-SLE12-revert-apparmor-remove-version-conditionals-fr.patch

- Update to docker-buildx v0.24.0. Upstream changelog:
  &amp;lt;https://github.com/docker/buildx/releases/tag/v0.24.0&amp;gt;

- Update to Docker 28.1.1-ce. See upstream changelog online at
  &amp;lt;https://docs.docker.com/engine/release-notes/28/#2811&amp;gt; bsc#1242114
  Includes upstream fixes:
  - CVE-2025-22872 bsc#1241830
- Remove long-outdated build handling for deprecated and unsupported
  devicemapper and AUFS storage drivers. AUFS was removed in v24, and
  devicemapper was removed in v25.
  &amp;lt;https://docs.docker.com/engine/deprecated/#aufs-storage-driver&amp;gt;
- Rebase patches:
  * 0001-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  * 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch
  * 0003-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  * 0004-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  * 0005-SLE12-revert-apparmor-remove-version-conditionals-fr.patch
- Remove upstreamed patches:
  - 0006-CVE-2025-22868-vendor-jws-split-token-into-fixed-num.patch
  - 0007-CVE-2025-22869-vendor-ssh-limit-the-size-of-the-inte.patch
  - cli-0001-docs-include-required-tools-in-source-tree.patch

- Update to docker-buildx v0.23.0. Upstream changelog:
  &amp;lt;https://github.com/docker/buildx/releases/tag/v0.23.0&amp;gt;

- Update to docker-buildx v0.22.0. Upstream changelog:
  &amp;lt;https://github.com/docker/buildx/releases/tag/v0.22.0&amp;gt;
  * Includes fixes for CVE-2025-0495. bsc#1239765

- Disable transparent SUSEConnect support for SLE-16. PED-12534
  When this patchset was first added in 2013 (and rewritten over the years),
  there was no upstream way to easily provide SLE customers with a way to build
  container images based on SLE using the host subscription. However, with
  docker-buildx you can now define secrets for builds (this is not entirely
  transparent, but we can easily document this new requirement for SLE-16).
  Users should use
    RUN --mount=type=secret,id=SCCcredentials zypper -n ...
  in their Dockerfiles, and
    docker buildx build --secret id=SCCcredentials,src=/etc/zypp/credentials.d/SCCcredentials,type=file .
  when doing their builds.
- Now that the only blocker for docker-buildx support was removed for SLE-16,
  enable docker-buildx for SLE-16 as well. PED-8905

Package transactional-update was updated:

Package google-dracut-config was updated:

Package grub2 was updated:

- Fix CVE-2024-56738: side-channel attack due to not constant-time  algorithm in grub_crypto_memcmp (bsc#1234959)
  * grub2-constant-time-grub_crypto_memcmp.patch

Package hwinfo was updated:

- merge gh#openSUSE/hwinfo#168- fix usb network card detection (bsc#1245950)
- 21.89

Package ignition was updated:

- Add CVE-2022-28948.patch  * Fixes [bsc#1248548]

Package iputils was updated:

- Security fix [bsc#1243772, CVE-2025-48964]  * Fix  integer overflow in ping statistics via zero timestamp
  * Add iputils-CVE-2025-48964_01.patch
  * Add iputils-CVE-2025-48964_02.patch

- Fix bsc#1243284 - ping on s390x prints invalid ttl
  * Add iputils-invalid-ttl-s390x.patch
  * Fix ipv4 ttl value when using SOCK_DGRAM on big endian systems

Package kernel-default was updated:

- md-raid10: fix KASAN warning (CVE-2022-50211 bsc#1245140).- commit 31bcd4f

- Update
  patches.suse/netfilter-nf_set_pipapo_avx2-fix-initial-map-fill.patch
  (git-fixes CVE-2024-57947 bsc#1236333 CVE-2025-38120
  bsc#1245711).
- commit 7d06dc1

- Refresh
  patches.suse/RDMA-core-Always-release-restrack-object.patch.
- Refresh
  patches.suse/RDMA-core-Don-t-access-cm_id-after-its-destruction.patch.
  Add one missing hunk in each patch. This is a no-op because the missing
  hunks were compensating each other, but this makes each backport more
  obviously correct.
- commit d3f88e2

- Update
  patches.suse/sch_hfsc-make-hfsc_qlen_notify-idempotent.patch
  (CVE-2025-37798 bsc#1242414 CVE-2025-38177 bsc#1245986).
- commit d9ba7e8

- HID: core: do not bypass hid_hw_raw_request (CVE-2025-38494
  bsc#1247349).
- HID: core: ensure the allocated report buffer can contain the
  reserved report ID (CVE-2025-38495 bsc#1247348).
- commit a678d3e

- usb: gadget: configfs: Fix OOB read on empty string write
  (CVE-2025-38497 bsc#1247347).
- commit e1f48cd

- RDMA/core: Update CMA destination address on rdma_resolve_addr (bsc#1210629 CVE-2023-2176)
- commit 7ed89f3

- s390/pkey: Prevent overflow in size calculation for
  memdup_user() (1246186 CVE-2025-38257).
- commit 8e1774a

- netfilter: allow exp not to be removed in nf_ct_find_expectation
  (CVE-2023-52927 bsc#1239644).
- commit 880fc41

- Revert those fixes for bsc#1238160 because the CVSS less than 7.0
  Revert those fixes for bsc#1238160 because the CVSS less than 7.0, and
  they cause merge conflicts on SLE15-SP3-LTSS which are not easy to resolve.
- Delete
  patches.suse/Bluetooth-hci_event-Fix-checking-conn-for-le_conn_co.patch.
- Delete
  patches.suse/Bluetooth-hci_event-Fix-checking-for-invalid-handle-.patch.
- Delete
  patches.suse/Bluetooth-hci_event-Ignore-multiple-conn-complete-ev.patch.
  (bsc#1238160 CVE-2022-49138)
- commit 6d6e523

- netfilter: nft_set_hash: unaligned atomic read on struct
  nft_set_ext (CVE-2023-52923 bsc#1236104).
- commit c227a9f

- netfilter: nft_set_hash: skip duplicated elements pending gc
  run (CVE-2023-52923 bsc#1236104).
- commit 51924b8

- net: sched: fix ordering of qlen adjustment (CVE-2024-53164 bsc#1234863)
- commit ea64d33

- Refresh patches.suse/Bluetooth-hci_event-Fix-checking-conn-for-le_conn_co.patch
  Remove the duplicate upstream commit ID from blacklist.conf and add it
  as Alt-commit to the patch instead.
- commit fa5a3c4

- ipc: fix to protect IPCS lookups using RCU (CVE-2025-38212
  bsc#1246029).
- commit 30fc041

- i40e: fix MMIO write access to an invalid page in i40e_clear_hw
  (CVE-2025-38200 bsc#1246045).
- commit 5b1ce89

- calipso: Fix null-ptr-deref in calipso_req_{set,del}attr()
  (CVE-2025-38181 bsc#1246000).
- commit f693286

- vgacon: Add check for vc_origin address range in vgacon_scroll()
  (CVE-2025-38213 bsc#1246037).
- commit a806d03

- Bluetooth: hci_event: Fix checking conn for le_conn_complete_evt
  (bsc#1238160 CVE-2022-49138).
- commit 9fb4996

- Bluetooth: hci_event: Fix checking for invalid handle on error
  status (bsc#1238160 CVE-2022-49138).
- commit 33a7a6d

- Bluetooth: hci_event: Ignore multiple conn complete events
  (bsc#1238160 CVE-2022-49138).
- commit 86d3f6a

- crypto: algif_hash - fix double free in hash_accept
  (CVE-2025-38079 bsc#1245217).
- commit 7f960ba

- net_sched: hfsc: Fix a UAF vulnerability in class handling
  (CVE-2025-37797 bsc#1242417).
- commit a414920

- net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT
  (CVE-2024-53057 bsc#1233551).
- commit b56116d

- netfilter: nf_set_pipapo_avx2: fix initial map fill (git-fixes
  CVE-2024-57947 bsc#1236333).
- commit e92eecd

- netfilter: nf_set_pipapo: fix initial map fill (CVE-2024-57947
  bsc#1236333).
- commit bff7b74

- scsi: storvsc: Increase the timeouts to storvsc_timeout
  (bsc#1245455).
- scsi: storvsc: Don't report the host packet status as the hv
  status (git-fixes).
- commit a5f8a2c

- firmware: arm_scpi: Ensure scpi_info is not assigned if the
  probe fails (CVE-2022-50087 bsc#1245119).
- commit ed98a38

- Update
  patches.suse/0012-dm-thin-fix-use-after-free-crash-in-dm_sm_register_t.patch
  (git-fixes CVE-2022-50092 bsc#1244848).
- Update
  patches.suse/0014-dm-raid-fix-address-sanitizer-warning-in-raid_status.patch
  (git-fixes CVE-2022-50084 bsc#1245117).
- Update
  patches.suse/0023-loop-Check-for-overflow-while-configuring-loop.patch
  (git-fixes CVE-2022-49993 bsc#1245121).
- Update
  patches.suse/0025-drivers-md-fix-a-potential-use-after-free-bug.patch
  (git-fixes CVE-2022-50022 bsc#1245131).
- Update
  patches.suse/ALSA-bcd2000-Fix-a-UAF-bug-on-the-error-path-of-prob.patch
  (git-fixes CVE-2022-50229 bsc#1244856).
- Update
  patches.suse/ASoC-SOF-debug-Fix-potential-buffer-overflow-by-snpr.patch
  (git-fixes CVE-2022-50051 bsc#1245041).
- Update
  patches.suse/ASoC-mt6797-mt6351-Fix-refcount-leak-in-mt6797_mt635.patch
  (git-fixes CVE-2022-50124 bsc#1244816).
- Update
  patches.suse/HID-cp2112-prevent-a-buffer-overflow-in-cp2112_xfer.patch
  (git-fixes CVE-2022-50156 bsc#1244782).
- Update
  patches.suse/HID-hidraw-fix-memory-leak-in-hidraw_release.patch
  (git-fixes CVE-2022-49981 bsc#1245072).
- Update
  patches.suse/HID-steam-Prevent-NULL-pointer-dereference-in-steam_.patch
  (git-fixes CVE-2022-49984 bsc#1244950).
- Update
  patches.suse/Input-iforce-wake-up-after-clearing-IFORCE_XMIT_RUNN.patch
  (git-fixes CVE-2022-49954 bsc#1244976).
- Update
  patches.suse/NFSv4-pnfs-Fix-a-use-after-free-bug-in-open.patch
  (git-fixes CVE-2022-50072 bsc#1244979).
- Update
  patches.suse/PCI-dwc-Deallocate-EPC-memory-on-dw_pcie_ep_init-err.patch
  (git-fixes CVE-2022-50146 bsc#1244788).
- Update
  patches.suse/RDMA-qedr-Fix-potential-memory-leak-in-__qedr_alloc_.patch
  (git-fixes CVE-2022-50138 bsc#1244797).
- Update
  patches.suse/RDMA-rxe-Fix-error-unwind-in-rxe_create_qp.patch
  (git-fixes CVE-2022-50127 bsc#1244815).
- Update
  patches.suse/RDMA-siw-Fix-duplicated-reported-IW_CM_EVENT_CONNECT.patch
  (git-fixes CVE-2022-50136 bsc#1244804).
- Update
  patches.suse/ceph-don-t-leak-snap_rwsem-in-handle_cap_grant.patch
  (bsc#1202810 CVE-2022-50059 bsc#1245031).
- Update
  patches.suse/clk-qcom-ipq8074-dont-disable-gcc_sleep_clk_src.patch
  (git-fixes CVE-2022-50029 bsc#1245146).
- Update
  patches.suse/crypto-arm64-poly1305-fix-a-read-out-of-bound.patch
  (git-fixes CVE-2022-50231 bsc#1244853).
- Update
  patches.suse/driver-core-fix-potential-deadlock-in-__driver_attac.patch
  (git-fixes CVE-2022-50149 bsc#1244883).
- Update
  patches.suse/drm-mcde-Fix-refcount-leak-in-mcde_dsi_bind.patch
  (git-fixes CVE-2022-50176 bsc#1244902).
- Update
  patches.suse/drm-meson-Fix-refcount-bugs-in-meson_vpu_has_availab.patch
  (git-fixes CVE-2022-50038 bsc#1244943).
- Update
  patches.suse/drm-msm-mdp5-Fix-global-state-lock-backoff.patch
  (git-fixes CVE-2022-50173 bsc#1244992).
- Update
  patches.suse/drm-radeon-fix-potential-buffer-overflow-in-ni_set_m.patch
  (git-fixes CVE-2022-50185 bsc#1244887).
- Update
  patches.suse/drm-sun4i-dsi-Prevent-underflow-when-computing-packe.patch
  (git-fixes CVE-2022-50036 bsc#1244941).
- Update
  patches.suse/ext4-avoid-resizing-to-a-partial-cluster-size.patch
  (bsc#1206880 CVE-2022-50020 bsc#1245129).
- Update
  patches.suse/fbdev-fb_pm2fb-Avoid-potential-divide-by-zero-error.patch
  (git-fixes CVE-2022-49978 bsc#1245195).
- Update
  patches.suse/ftrace-Fix-NULL-pointer-dereference-in-is_ftrace_trampoline-when-ftrace-is-dead.patch
  (git-fixes CVE-2022-49977 bsc#1244936).
- Update patches.suse/gadgetfs-ep_io-wait-until-IRQ-finishes.patch
  (git-fixes CVE-2022-50028 bsc#1245135).
- Update
  patches.suse/hwmon-gpio-fan-Fix-array-out-of-bounds-access.patch
  (git-fixes CVE-2022-49945 bsc#1244908).
- Update
  patches.suse/ieee802154-adf7242-defer-destroy_workqueue-call.patch
  (git-fixes CVE-2022-49968 bsc#1244959).
- Update
  patches.suse/iio-light-isl29028-Fix-the-warning-in-isl29028_remov.patch
  (git-fixes CVE-2022-50218 bsc#1244861).
- Update
  patches.suse/intel_th-Fix-a-resource-leak-in-an-error-handling-pa.patch
  (git-fixes CVE-2022-50143 bsc#1244790).
- Update patches.suse/intel_th-msu-Fix-vmalloced-buffers.patch
  (git-fixes CVE-2022-50142 bsc#1244796).
- Update
  patches.suse/iommu-vt-d-avoid-invalid-memory-access-via-node_online-NUMA_NO_N
  (git-fixes CVE-2022-50093 bsc#1244849).
- Update
  patches.suse/jbd2-fix-assertion-jh-b_frozen_data-NULL-failure-whe.patch
  (bsc#1202716 CVE-2022-50126 bsc#1244813).
- Update
  patches.suse/locking-csd_lock-Change-csdlock_debug-from-early_par.patch
  (git-fixes CVE-2022-50091 bsc#1244885).
- Update patches.suse/md-call-__md_stop_writes-in-md_stop.patch
  (git-fixes CVE-2022-49987 bsc#1245024).
- Update patches.suse/md-raid10-fix-KASAN-warning.patch (git-fixes
  CVE-2022-50211 bsc#1245140).
- Update patches.suse/memstick-ms_block-Fix-a-memory-leak.patch
  (git-fixes CVE-2022-50140 bsc#1244793).
- Update
  patches.suse/meson-mx-socinfo-Fix-refcount-leak-in-meson_mx_socin.patch
  (git-fixes CVE-2022-50209 bsc#1244868).
- Update
  patches.suse/mfd-max77620-Fix-refcount-leak-in-max77620_initialis.patch
  (git-fixes CVE-2022-50108 bsc#1244834).
- Update
  patches.suse/misc-fastrpc-fix-memory-corruption-on-open.patch
  (git-fixes CVE-2022-49950 bsc#1244958).
- Update
  patches.suse/misc-fastrpc-fix-memory-corruption-on-probe.patch
  (git-fixes CVE-2022-49952 bsc#1244945).
- Update
  patches.suse/mmc-sdhci-of-esdhc-Fix-refcount-leak-in-esdhc_signal.patch
  (git-fixes CVE-2022-50141 bsc#1244794).
- Update
  patches.suse/msft-hv-2639-scsi-storvsc-Remove-WQ_MEM_RECLAIM-from-storvsc_erro.patch
  (git-fixes CVE-2022-49986 bsc#1244948).
- Update
  patches.suse/mt76-mt76x02u-fix-possible-memory-leak-in-__mt76x02u.patch
  (git-fixes CVE-2022-50172 bsc#1244764).
- Update
  patches.suse/mtd-maps-Fix-refcount-leak-in-ap_flash_init.patch
  (git-fixes CVE-2022-50160 bsc#1244776).
- Update
  patches.suse/mtd-maps-Fix-refcount-leak-in-of_flash_probe_versati.patch
  (git-fixes CVE-2022-50161 bsc#1244774).
- Update
  patches.suse/mtd-partitions-Fix-refcount-leak-in-parse_redboot_of.patch
  (git-fixes CVE-2022-50158 bsc#1244779).
- Update
  patches.suse/netfilter-nf_tables-do-not-allow-CHAIN_ID-to-refer-t.patch
  (CVE-2022-2586 bsc#1202095 CVE-2022-50212 bsc#1244869).
- Update
  patches.suse/pinctrl-nomadik-Fix-refcount-leak-in-nmk_pinctrl_dt_.patch
  (git-fixes CVE-2022-50061 bsc#1245033).
- Update
  patches.suse/powerpc-64-Init-jump-labels-before-parse_early_param.patch
  (bsc#1065729 CVE-2022-50012 bsc#1245125).
- Update patches.suse/powerpc-pci-Fix-get_phb_number-locking.patch
  (bsc#1065729 CVE-2022-50045 bsc#1244967).
- Update
  patches.suse/powerpc-perf-Optimize-clearing-the-pending-PMI-and-r.patch
  (bsc#1156395 CVE-2022-50118 bsc#1244825).
- Update
  patches.suse/powerpc-xive-Fix-refcount-leak-in-xive_get_max_prio.patch
  (fate#322438 git-fixess CVE-2022-50104 bsc#1244836).
- Update
  patches.suse/regulator-of-Fix-refcount-leak-bug-in-of_get_regulat.patch
  (git-fixes CVE-2022-50191 bsc#1244899).
- Update
  patches.suse/s390-fix-double-free-of-GS-and-RI-CBs-on-fork-failure
  (git-fixes CVE-2022-49990 bsc#1245006).
- Update
  patches.suse/scsi-lpfc-Fix-possible-memory-leak-when-failing-to-i.patch
  (bsc#1201956 CVE-2022-50027 bsc#1245073).
- Update
  patches.suse/scsi-lpfc-Prevent-buffer-overflow-crashes-in-debugfs.patch
  (bsc#1201956 CVE-2022-50030 bsc#1245265).
- Update
  patches.suse/scsi-qla2xxx-fix-crash-due-to-stale-srb-access-around-i-o-timeouts.patch
  (bsc#1201160 CVE-2022-50098 bsc#1244841).
- Update
  patches.suse/scsi-sg-Allow-waiting-for-commands-to-complete-on-removed-device.patch
  (git-fixes CVE-2022-50215 bsc#1245138).
- Update
  patches.suse/spmi-trace-fix-stack-out-of-bound-access-in-SPMI-tracing-functions.patch
  (git-fixes CVE-2022-50094 bsc#1244851).
- Update
  patches.suse/tty-serial-Fix-refcount-leak-bug-in-ucc_uart.c.patch
  (git-fixes CVE-2022-50019 bsc#1245098).
- Update
  patches.suse/tty-vt-initialize-unicode-screen-buffer.patch
  (git-fixes CVE-2022-50222 bsc#1245136).
- Update
  patches.suse/usb-host-Fix-refcount-leak-in-ehci_hcd_ppc_of_probe.patch
  (git-fixes CVE-2022-50153 bsc#1244786).
- Update
  patches.suse/usb-host-ohci-ppc-of-Fix-refcount-leak-bug.patch
  (git-fixes CVE-2022-50033 bsc#1245139).
- Update
  patches.suse/usb-ohci-nxp-Fix-refcount-leak-in-ohci_hcd_nxp_probe.patch
  (git-fixes CVE-2022-50152 bsc#1244783).
- Update patches.suse/usb-renesas-Fix-refcount-leak-bug.patch
  (git-fixes CVE-2022-50032 bsc#1245103).
- Update
  patches.suse/usbnet-Fix-linkwatch-use-after-free-on-disconnect.patch
  (git-fixes CVE-2022-50220 bsc#1245348).
- Update
  patches.suse/video-fbdev-amba-clcd-Fix-refcount-leak-bugs.patch
  (git-fixes CVE-2022-50109 bsc#1244884).
- Update
  patches.suse/video-fbdev-arkfb-Check-the-size-of-screen-before-me.patch
  (git-fixes CVE-2022-50099 bsc#1244842).
- Update
  patches.suse/video-fbdev-arkfb-Fix-a-divide-by-zero-bug-in-ark_se.patch
  (git-fixes CVE-2022-50102 bsc#1244838).
- Update
  patches.suse/video-fbdev-i740fb-Check-the-argument-of-i740_calc_v.patch
  (git-fixes CVE-2022-50010 bsc#1245122).
- Update
  patches.suse/video-fbdev-s3fb-Check-the-size-of-screen-before-mem.patch
  (git-fixes CVE-2022-50097 bsc#1244845).
- Update
  patches.suse/video-fbdev-vt8623fb-Check-the-size-of-screen-before.patch
  (git-fixes CVE-2022-50101 bsc#1244839).
- Update
  patches.suse/virtio-gpu-fix-a-missing-check-to-avoid-NULL-derefer.patch
  (git-fixes CVE-2022-50181 bsc#1244901).
- Update
  patches.suse/virtio_net-fix-memory-leak-inside-XPD_TX-with-mergea.patch
  (git-fixes CVE-2022-50065 bsc#1244986).
- Update
  patches.suse/vt-Clear-selection-before-changing-the-font.patch
  (git-fixes CVE-2022-49948 bsc#1245058).
- Update
  patches.suse/wifi-iwlwifi-mvm-fix-double-list_add-at-iwl_mvm_mac_.patch
  (git-fixes CVE-2022-50164 bsc#1244770).
- Update
  patches.suse/wifi-libertas-Fix-possible-refcount-leak-in-if_usb_p.patch
  (git-fixes CVE-2022-50162 bsc#1244773).
- Update
  patches.suse/wifi-mac80211-Don-t-finalize-CSA-in-IBSS-mode-if-sta.patch
  (git-fixes CVE-2022-49942 bsc#1244881).
- Update
  patches.suse/wifi-mac80211-Fix-UAF-in-ieee80211_scan_rx.patch
  (git-fixes CVE-2022-49934 bsc#1245051).
- Update
  patches.suse/wifi-wil6210-debugfs-fix-info-leak-in-wil_write_file.patch
  (git-fixes CVE-2022-50169 bsc#1244767).
- Update
  patches.suse/wifi-wil6210-debugfs-fix-uninitialized-variable-use-.patch
  (git-fixes CVE-2022-50165 bsc#1244771).
- Update
  patches.suse/xen-privcmd-fix-error-exit-of-privcmd_ioctl_dm_op.patch
  (git-fixes CVE-2022-49989 bsc#1245007).
- commit 138997d

- Update
  patches.suse/USB-core-Prevent-nested-device-reset-calls.patch
  (bsc#1206664 CVE-2022-4662 CVE-2022-49936 bsc#1244984).
- Update
  patches.suse/ath9k-fix-use-after-free-in-ath9k_hif_usb_rx_cb.patch
  (CVE-2022-1679 bsc#1199487 CVE-2022-50179 bsc#1244886).
- Update
  patches.suse/bpf-Don-t-use-tnum_range-on-array-range-checking-for.patch
  (bsc#1202564 bsc#1202860 CVE-2022-2905 CVE-2022-49985
  bsc#1244956).
- Update
  patches.suse/btrfs-unset-reloc-control-if-transaction-commit-fail.patch
  (bsc#1212051 CVE-2023-3111 CVE-2022-50067 bsc#1245047).
- Update
  patches.suse/ext4-add-EXT4_INODE_HAS_XATTR_SPACE-macro-in-xattr.h.patch
  (bsc#1206878 CVE-2022-50083 bsc#1244968).
- Update
  patches.suse/media-mceusb-Use-new-usb_control_msg_-routines.patch
  (CVE-2022-3903 bsc#1205220 CVE-2022-49937 bsc#1245057).
- Update
  patches.suse/netfilter-nf_tables-do-not-allow-SET_ID-to-refer-to-.patch
  (CVE-2022-2586 bsc#1202095 CVE-2022-50213 bsc#1244867).
- Update patches.suse/sch_htb-make-htb_deactivate-idempotent.patch
  (CVE-2025-37798 bsc#1242414 CVE-2025-37953 bsc#1243543).
- Update
  patches.suse/sch_htb-make-htb_qlen_notify-idempotent.patch
  (CVE-2025-37798 bsc#1242414 CVE-2025-37932 bsc#1243627).
- Update
  patches.suse/staging-rtl8712-fix-use-after-free-bugs.patch
  (CVE-2022-4095 bsc#1205514 CVE-2022-49956 bsc#1244969).
- commit cfda5f9

- selinux: Add boundary check in put_entry() (CVE-2022-50200
  bsc#1245149).
- commit 66f4090

- net_sched: prio: fix a race in prio_tune() (CVE-2025-38083
  bsc#1245183).
- commit 23a5ba6

- dm raid: fix address sanitizer warning in raid_resume
  (CVE-2022-50085 bsc#1245147).
- commit 014ae24

- kabi: place tstamp needed for nftables set in a hole
  (CVE-2024-27397 bsc#1224095).
- commit 77b63ae

- netfilter: nf_tables: use timestamp to check for set element
  timeout (CVE-2024-27397 bsc#1224095).
- commit 9049387

- netfilter: nft_set_rbtree: .deactivate fails if element has
  expired (CVE-2024-27397 bsc#1224095).
- commit 1e980c4

- net_sched: hfsc: Address reentrant enqueue adding class to
  eltree twice (CVE-2025-38001 bsc#1244234).
- commit f66f8f9

- sch_ets: make est_qlen_notify() idempotent (CVE-2025-37798
  bsc#1242414).
  Note: this patch is only needed SLE15-SP3-LTSS as sch_ets was not
  backported into other 5.3 based branches.
- commit 6c457bf

- sch_htb: make htb_deactivate() idempotent (CVE-2025-37798
  bsc#1242414).
- codel: remove sch-&amp;gt;q.qlen check before
  qdisc_tree_reduce_backlog() (CVE-2025-37798 bsc#1242414).
- sch_qfq: make qfq_qlen_notify() idempotent (CVE-2025-37798
  bsc#1242414).
- sch_hfsc: make hfsc_qlen_notify() idempotent (CVE-2025-37798
  bsc#1242414).
- sch_drr: make drr_qlen_notify() idempotent (CVE-2025-37798
  bsc#1242414).
- sch_htb: make htb_qlen_notify() idempotent (CVE-2025-37798
  bsc#1242414).
- commit 76ca52d

- packaging: Add support for suse-kabi-tools
  The current workflow to check kABI stability during the RPM build of SUSE
  kernels consists of the following steps:
  * The downstream script rpm/modversions unpacks the consolidated kABI
  symtypes reference data from kabi/&amp;lt;arch&amp;gt;/symtypes-&amp;lt;flavor&amp;gt; and creates
  individual symref files.
  * The build performs a regular kernel make. During this operation, genksyms
  is invoked for each source file. The tool determines type signatures of
  all exports within the file, reports any differences compared to the
  associated symref reference, calculates symbol CRCs from the signatures
  and writes new type data into a symtypes file.
  * The script rpm/modversions is invoked again, this time it packs all new
  symtypes files to a consolidated kABI file.
  * The downstream script rpm/kabi.pl checks symbol CRCs in the new build and
  compares them to a reference from kabi/&amp;lt;arch&amp;gt;/symvers-&amp;lt;flavor&amp;gt;, taking
  kabi/severities into account.
  suse-kabi-tools is a new set of tools to improve the kABI checking process.
  The suite includes two tools, ksymtypes and ksymvers, which replace the
  existing scripts rpm/modversions and rpm/kabi.pl, as well as the comparison
  functionality previously provided by genksyms. The tools have their own
  source repository and package.
  The tools provide faster operation and more detailed, unified output. In
  addition, they allow the use of the new upstream tool gendwarfksyms, which
  lacks any built-in comparison functionality.
  The updated workflow is as follows:
  * The build performs a regular kernel make. During this operation, genksyms
  (gendwarfksyms) is invoked as usual, determinining signatures and CRCs of
  all exports and writing the type data to symtypes files. However,
  genksyms no longer performs any comparison.
  * 'ksymtypes consolidate' packs all new symtypes files to a consolidated
  kABI file.
  * 'ksymvers compare' checks symbol CRCs in the new build and compares them
  to a reference from kabi/&amp;lt;arch&amp;gt;/symvers-&amp;lt;flavor&amp;gt;, taking kabi/severities
  into account. The tool writes its result in a human-readable form on
  standard output and also writes a list of all changed exports (not
  ignored by kabi/severities) to the changed-exports file.
  * 'ksymtypes compare' takes the changed-exports file, the consolidated kABI
  symtypes reference data from kabi/&amp;lt;arch&amp;gt;/symtypes-&amp;lt;flavor&amp;gt; and the new
  consolidated data. Based on this data, it produces a detailed report
  explaining why the symbols changed.
  The patch enables the use of suse-kabi-tools via rpm/config.sh, providing
  explicit control to each branch. To enable the support, set
  USE_SUSE_KABI_TOOLS=Yes in the config file.
- commit a2c6f89

- kernel-source: Remove log.sh from sources
- commit 96bd779

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

- net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too
  (CVE-2025-37823 bsc#1242924).
- commit dca98b0

- sch_hfsc: Fix qlen accounting bug when using peek in
  hfsc_enqueue() (CVE-2025-38000 bsc#1244277).
- net_sched: hfsc: Fix a UAF vulnerability in class with netem
  as child qdisc (CVE-2025-37890 bsc#1243330).
- net: sched: sch_multiq: fix possible OOB write in multiq_tune()
  (CVE-2024-36978 bsc#1226514).
- commit 8d2bb29

- netfilter: ipset: fix region locking in hash types
  (CVE-2025-37997 bsc#1243832).
- commit d102bab

- net: sched: Disallow replacing of child qdisc from one parent
  to another (CVE-2025-21700 bsc#1237159).
- commit bde17d3

- netem: Update sch-&amp;gt;q.qlen before qdisc_tree_reduce_backlog()
  (git-fixes CVE-2025-21703 bsc#1237313).
- commit 982a71f

- pfifo_tail_enqueue: Drop new packet when sch-&amp;gt;limit == 0 (CVE-2025-21702 bsc#1237312)
- commit f34470d

- net_sched: sch_fifo: implement lockless __fifo_dump() (bsc#1237312)
- commit a87a922

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

- net/sched: netem: account for backlog updates from child qdisc
  (CVE-2024-56770 bsc#1235637).
- sch/netem: fix use after free in netem_dequeue (CVE-2024-56770
  bsc#1235637 CVE-2024-46800 bsc#1230827).
- commit 3360a1a

- mkspec: Exclude rt flavor from kernel-syms dependencies (bsc#1244337).
- commit 7c95ae0

- MyBS: Do not build kernel-obs-qa with limit_packages
  Fixes: 58e3f8c34b2b (&amp;quot;bs-upload-kernel: Pass limit_packages also on multibuild&amp;quot;)
- commit f4c6047

- MyBS: Simplify qa_expr generation
  Start with a 0 which makes the expression valid even if there are no QA
  repositories (currently does not happen). Then separator is always
  needed.
- commit e4c2851

- MyBS: Correctly generate build flags for non-multibuild package limit
  (bsc# 1244241)
  Fixes: 0999112774fc (&amp;quot;MyBS: Use buildflags to set which package to build&amp;quot;)
- commit 27588c9

- bs-upload-kernel: Pass limit_packages also on multibuild
  Fixes: 0999112774fc (&amp;quot;MyBS: Use buildflags to set which package to build&amp;quot;)
  Fixes: 747f601d4156 (&amp;quot;bs-upload-kernel, MyBS, Buildresults: Support multibuild (JSC-SLE#5501, boo#1211226, bsc#1218184)&amp;quot;)
- commit 8ef486c

- wifi: cfg80211: fix certs build to not depend on file order
  (bsc#1243001).
- wifi: cfg80211: Add my certificate (bsc#1243001).
- commit eda1fcf

- kernel-source: Do not use multiple -r in sed parameters
  This usage is enabled in commit b18d64d
  (sed: allow multiple (non-conflicting) -E/-r parameters, 2016-07-31)
  only available since sed 4.3
  Fixes: dc2037cd8f94 (&amp;quot;kernel-source: Also replace bin/env&amp;quot;
- commit 91ad98e

- kabi/severities: workaround kABI checker complains after AX25 and HAMRADIO removals
  KABI: symbol asc2ax(mod:net/ax25/ax25) lost
  KABI: symbol ax25_bcast(mod:net/ax25/ax25) lost
  KABI: symbol ax25_defaddr(mod:net/ax25/ax25) lost
  KABI: symbol ax25_display_timer(mod:net/ax25/ax25) lost
  KABI: symbol ax25_find_cb(mod:net/ax25/ax25) lost
  KABI: symbol ax25_findbyuid(mod:net/ax25/ax25) lost
  KABI: symbol ax25_header_ops(mod:net/ax25/ax25) lost
  KABI: symbol ax25_ip_xmit(mod:net/ax25/ax25) lost
  KABI: symbol ax25_linkfail_register(mod:net/ax25/ax25) lost
  KABI: symbol ax25_linkfail_release(mod:net/ax25/ax25) lost
  KABI: symbol ax25_listen_register(mod:net/ax25/ax25) lost
  KABI: symbol ax25_listen_release(mod:net/ax25/ax25) lost
  KABI: symbol ax25_protocol_release(mod:net/ax25/ax25) lost
  KABI: symbol ax25_register_pid(mod:net/ax25/ax25) lost
  KABI: symbol ax25_send_frame(mod:net/ax25/ax25) lost
  KABI: symbol ax25_uid_policy(mod:net/ax25/ax25) lost
  KABI: symbol ax25cmp(mod:net/ax25/ax25) lost
  KABI: symbol ax2asc(mod:net/ax25/ax25) lost
  KABI: symbol hdlcdrv_arbitrate(mod:drivers/net/hamradio/hdlcdrv) lost
  KABI: symbol hdlcdrv_receiver(mod:drivers/net/hamradio/hdlcdrv) lost
  KABI: symbol hdlcdrv_register(mod:drivers/net/hamradio/hdlcdrv) lost
  KABI: symbol hdlcdrv_transmitter(mod:drivers/net/hamradio/hdlcdrv) lost
  KABI: symbol hdlcdrv_unregister(mod:drivers/net/hamradio/hdlcdrv) lost
  KABI: symbol null_ax25_address(mod:net/ax25/ax25) lost
- commit fc0b9ba

- drop rose drivers (bsc#1238471).
- drop netrom drivers (bsc#1238471).
- drop hamradio drivers (bsc#1238471).
- drop ax25 drivers (bsc#1238471).
- commit bde35e8

Package krb5 was updated:

- Remove des3-cbc-sha1 and arcfour-hmac-md5 from permitted  enctypes unless new special options &amp;quot;allow_des3&amp;quot; or &amp;quot;allow_rc4&amp;quot;
  are set; (CVE-2025-3576); (bsc#1241219).
- Add patch 0015-CVE-2025-3576.patch

Package gcc14 was updated:

- Exclude shared objects present for link editing in the GCC specific  subdirectory from provides processing via __provides_exclude_from.
  [bsc#1244050][bsc#1243991]

- Make cross-*-gcc14-bootstrap package conflict with the non-bootstrap
  variant conflict with the unversioned cross-*-gcc package.

- Disable build of glibc cross to loongarch64 and hppa in SLFO
  and SLE15.

- Update to GCC 14.3 release, bb24b4c804f3d95b0ba95b7496, git11799
- Remove gcc14-pr120061.patch which is now included upstream.

- Add gcc14-pr120061.patch to fix the PR108900 fix instead of
  reverting it.
- Remove gcc14-pr108900.patch

- Add gcc14-pr108900.patch to revert it, fixing libqt6webengine build.

- Update to gcc-14 branch head, 3418d740b344e0ba38022f3be, git11702
  * Remove gcc14-pr118780.patch now on the upstream branch
- Fix build on s390x [bsc#1241549]

- Make sure link editing is done against our own shared library
  copy rather than the installed system runtime.  [bsc#1240788]
- Add gcc14-pr119680.patch to fix cross-compiler builds with
  - -enable-host-pie.

Package libgcrypt was updated:

- Security fix [bsc#1221107, CVE-2024-2236]  * Add --enable-marvin-workaround to spec to enable workaround
  * Fix  timing based side-channel in RSA implementation ( Marvin attack )
  * Add libgcrypt-CVE-2024-2236_01.patch
  * Add libgcrypt-CVE-2024-2236_01_s390x.patch
  * Add libgcrypt-CVE-2024-2236_02.patch
  * Add libgcrypt-CVE-2024-2236_03.patch

Package gnutls was updated:

- Fix 1-byte heap buffer overflow when parsing templates with certtool  [bsc#1246267, CVE-2025-32990]
  * Add patch gnutls-CVE-2025-32990.patch
- Fix double-free due to incorrect ownership handling in the export logic of
  SAN entries containing an otherName [bsc#1246232, CVE-2025-32988]
  * Add patch gnutls-CVE-2025-32988.patch
- Fix NULL pointer dereference when 2nd Client Hello omits PSK
  [bsc#1246299, CVE-2025-6395]
  * Add patch gnutls-CVE-2025-6395.patch

Package polkit was updated:

- CVE-2025-7519: Fixed that a XML policy file with a large number of  nested elements may lead to out-of-bounds write (bsc#1246472)
  added 0001-Nested-.policy-files-cause-xml-parsing-overflow-lead.patch

Package python3 was updated:

- Add CVE-2025-8194-tarfile-no-neg-offsets.patch which now  validates archives to ensure member offsets are non-negative
  (gh#python/cpython#130577, CVE-2025-8194, bsc#1247249).

- Add CVE-2025-4435-normalize-lnk-trgts-tarfile.patch
  Security fixes for CVE-2025-4517, CVE-2025-4330, CVE-2025-4138,
  CVE-2024-12718, CVE-2025-4435 on tarfile (bsc#1244032,
  bsc#1244061, bsc#1244059, bsc#1244060, bsc#1244056).
  The backported fixes do not contain changes for ntpath.py and
  related tests, because the support for symlinks and junctions
  were added later in Python 3.9, and it does not make sense to
  backport them to 3.6 here.
  The patch is contains the following changes:
  - python@42deeab fixes symlink handling for tarfile.data_filter
  - python@9d2c2a8 fixes handling of existing files/symlinks in tarfile
  - python@00af979 adds a new &amp;quot;strict&amp;quot; argument to realpath()
  - python@dd8f187 fixes mulriple CVE fixes in the tarfile module
  - downstream only fixes that makes the changes work and
    compatible with Python 3.6
- Add CVE-2025-6069-quad-complex-HTMLParser.patch to avoid worst
  case quadratic complexity when processing certain crafted
  malformed inputs with HTMLParser (CVE-2025-6069, bsc#1244705).

- Add python36-* provides/obsoletes to enable SLE-12 -&amp;gt; SLE-15
  migration, bsc#1233012

- Add ipaddress-update-pr60.patch from gh#phihag/ipaddress!60 to
  update vendored ipaddress module to 3.8 equivalent
- Add gh-128840_parse-IPv6-with-emb-IPv4.patch to limit buffer
  size for IPv6 address parsing (gh#python/cpython#128840,
  bsc#1244401).
- Update CVE-2025-4516-DecodeError-handler.patch not to break
  _PyBytes_DecodeEscape signature.

- Add CVE-2025-4516-DecodeError-handler.patch fixing
  CVE-2025-4516 (bsc#1243273) blocking DecodeError handling
  vulnerability, which could lead to DoS.

Package ruby2.5 was updated:

- update suse.patch to 3f3682bf07fcd4f2fa875958853d3843ee7dcdb9  - fix remote DoS via YAML manifest
    bsc#1225905 CVE-2024-35221

- update suse.patch to c76fb820676cfded16c697a62281a3bfeb8e4bb1
  - fix webrick: Ruby WEBrick read_header HTTP Request Smuggling Vulnerability
    bsc#1245254 CVE-2025-6442

- update suse.patch to 5d79fc609c5761864aec47e1ae4796b93db99104
  - fix ruby: userinfo leakage in URI#join, URI#merge and URI#+
    bsc#1237805 CVE-2025-27221

Package libsolv was updated:

- add support for product-obsoletes() provides in the product  autopackage generation code
- bump version to 0.7.34

- improve transaction ordering by allowing more uninst-&amp;gt;uninst
  edges [bsc#1243457]
- implement color filtering when adding update targets
- support orderwithrequires dependencies in susedata.xml
- bump version to 0.7.33

Package sqlite3 was updated:

- Backpatch the URLs in sqlite3.n from https to http to avoid a  file conflict with the tcl package on SLE-15-GA up to SP2. In
  SP3 and onwards the Tcl package does not contain the sqlite
  extension anymore.

- Sync version 3.50.2 from Factory:
  * CVE-2025-6965, bsc#1246597:
    Raise an error early if the number of aggregate terms in a
    query exceeds the maximum number of columns, to avoid
    downstream assertion faults.
  * Add subpackage for the lemon parser generator.
    + sqlite-3.49.0-fix-lemon-missing-cflags.patch
    + sqlite-3.6.23-lemon-system-template.patch

Package libssh was updated:

- Fix CVE-2025-5318: Likely read beyond bounds in sftp server handle management (bsc#1245311)  * Add patch libssh-CVE-2025-5318.patch
- Fix CVE-2025-4877: Write beyond bounds in binary to base64 conversion functions (bsc#1245309)
  * Add patch libssh-CVE-2025-4877.patch
- Fix CVE-2025-4878: Use of uninitialized variable in privatekey_from_file() (bsc#1245310)
  * Add patches:
  - libssh-CVE-2025-4878-1.patch
  - libssh-CVE-2025-4878-2.patch
- Fix CVE-2025-5372: ssh_kdf() returns a success code on certain failures (bsc#1245314)
  * Add patch libssh-CVE-2025-5372.patch

Package libxml2 was updated:

- security update- added patches
  CVE-2025-7425 [bsc#1246296], Heap Use-After-Free in libxslt caused by atype corruption in xmlAttrPtr
  + libxml2-CVE-2025-7425.patch

- security update
- added patches
  CVE-2025-49794 [bsc#1244554], heap use after free (UAF) can lead to Denial of service (DoS)
  CVE-2025-49796 [bsc#1244557], type confusion may lead to Denial of service (DoS)
  + libxml2-CVE-2025-49794,49796.patch

- security update
- added patches
  CVE-2025-6170 [bsc#1244700], stack buffer overflow may lead to a crash
  CVE-2025-6021 [bsc#1244580], Integer Overflow in xmlBuildQName() Leads to Stack Buffer Overflow in libxml2
  + libxml2-CVE-2025-6170,6021.patch

Package libzypp was updated:

- Fix evaluation of libproxy results (bsc#1247690)- Replace URL variables inside mirrorlist/metalink files
  (fixes #667)
- version 17.37.16 (35)

- Append RepoInfo::path() to the mirror URLs in Preloader
  (bsc#1247054)
- version 17.37.15 (35)

- During installation indicate the backend being used (bsc#1246038)
  If some package actually needs to know, it should test for
  ZYPP_CLASSIC_RPMTRANS being set in the environment.
  Otherwise the transaction is driven by librpm.
- version 17.37.14 (35)

- Workaround 'rpm -vv' leaving scriptlets /var/tmp (bsc#1218459)
- Verbose log libproxy results if PX_DEBUG=1 is set.
- BuildRequires:  cmake &amp;gt;= 3.17.
- version 17.37.13 (35)

- Allow explicit request to probe an added repo's URL
  (bsc#1246466)
- Fix tests with -DISABLE_MEDIABACKEND_TESTS=1 (fixes #661)
- version 17.37.12 (35)

- Add runtime check for a broken rpm-4.18.0 --runpostrans
  (bsc#1246149)
- Add regression test for bsc#1245220 and some other filesize
  related tests.
- version 17.37.11 (35)

- BuildRequires: %{libsolv_devel_package} &amp;gt;= 0.7.34 (bsc#1243486)
  Newer rpm versions no longer allow a ':' in rpm package names or
  obsoletes. So injecting an
    Obsoletes: product:oldproductname &amp;lt; oldproductversion
  into the -release package to indicate a product rename is no longer
  possible.
  Since libsolv-0.7.34 you can and should use:
    Provides: product-obsoletes(oldproductname) &amp;lt; oldproductversion
  in the -release package. libsolv will then inject the appropriate
  Obsoletes into the Product.
- version 17.37.10 (35)

- Ignore DeltaRpm download errors (bsc#1245672)
  DeltaRpms are in fact optional resources. In case of a failure
  the full rpm is downloaded.
- Improve fix for incorrect filesize handling (bsc#1245220)
- version 17.37.9 (35)

- Do not trigger download data exceeded errors on HTTP non data
  responses (bsc#1245220)
  In some cases a HTTP 401 or 407 did trigger a &amp;quot;filesize exceeded&amp;quot;
  error, because the response payload size was compared against the
  expected filesize. This patch adds some checks if the response
  code is in the success range and only then takes expected
  filesize into account. Otherwise the response content-length is
  used or a fallback of 2Mb if no content-length is known.
- version 17.37.8 (35)

- Fix SEGV in MediaDISK handler (bsc#1245452)
- Explicitly selecting DownloadAsNeeded also selects the
  classic_rpmtrans backend.
  DownloadAsNeeded can not be combined with the rpm singletrans
  installer backend because a rpm transaction requires all package
  headers to be available the the beginning of the transaction. So
  explicitly selecting this mode also turns on the classic_rpmtrans
  backend.
- Fix evaluation of libproxy results (bsc#1244710)
- version 17.37.7 (35)

- Enhancements regarding mirror handling during repo refresh.
  Added  means to disable the use of mirrors when downloading
  security relevant files. Requires updaing zypper to 1.14.91.
- Fix autotestcase writer if ZYPP_FULLLOG=1 (bsc#1244042)
  If ZYPP_FULLLOG=1 a solver testcase to
  &amp;quot;/var/log/YaST2/autoTestcase&amp;quot; should be written for each solver
  run. There was no testcase written for the very first solver run.
  This is now fixed.
- Pass $1==2 to %posttrans script if it's an update (bsc#1243279)
- version 17.37.6 (35)

Package net-tools was updated:

- Drop 0002-Do-not-warn-about-interface-socket-not-binded.patch. It  worked around a net-tools-1.60 specific problem, that does not
  happen in net-tools-2.10. It is more harmful than useful, as it
  can hide real problems. (bsc#430864#c15,
  https://github.com/ecki/net-tools/issues/32#issuecomment-3265471116).

- Drop 0004-By-default-do-not-fopen-anything-in-netrom_gr.patch. It
  was net-tools-1.60 specific leak fix and breaks netrom in
  net-tools-2.10 (bnc#544339#c2).

- Drop old Fedora patch 0006-Allow-interface-stacking.patch. It
  provided a fix for CVE-2025-46836 (bsc#142461), but it was fixes
  by the upstream in 2025 in a different way. Revert interferring
  net-tools-CVE-2025-46836.patch back to the upstream version.
- Fix stack buffer overflow in parse_hex (bsc#1248687,
  GHSA-h667-qrp8-gj58, net-tools-parse_hex-stack-overflow.patch).
- Fix stack-based buffer overflow in proc_gen_fmt (bsc#1248687,
  GHSA-w7jq-cmw2-cq59,
  net-tools-proc_gen_fmt-buffer-overflow.patch).
- Avoid unsafe memcpy in ifconfig (bsc#1248687,
  net-tools-ifconfig-avoid-unsafe-memcpy.patch).
- Prevent overflow in ax25 and netrom (bsc#1248687,
  net-tools-ax25+netrom-overflow-1.patch,
  net-tools-ax25+netrom-overflow-2.patch).
- Keep possibility to enter long interface names, even if they are
  not accepted by the kernel, because it was always possible up to
  CVE-2025-46836 fix. But issue a warning about an interface name
  concatenation (bsc#1248410,
  net-tools-ifconfig-long-name-warning.patch).

- Provide more readable error for interface name size checking
  introduced by net-tools-CVE-2025-46836.patch
  (bsc#1243581, net-tools-CVE-2025-46836-error-reporting.patch).

- Fix a regression in net-tools-CVE-2025-46836.patch (bsc#1246608).

- Perform bound checks when parsing interface labels in
  /proc/net/dev (bsc#1243581, CVE-2025-46836, GHSA-pfwf-h6m3-63wf,
  net-tools-CVE-2025-46836.patch,
  net-tools-CVE-2025-46836-regression.patch).

Package pam was updated:

- Make sure that the buffer containing encrypted passwords get's erased  bedore free.
- Replace to previous CVE fix which led to CPU performance issues.
  [bsc#1246221, CVE-2024-10041,
  + libpam-introduce-secure-memory-erasure-helpers.patch
  + pam_modutil_get-overwrite-password-at-free.patch
  - passverify-always-run-the-helper-to-obtain-shadow_pwd.patch]

Package python-PyYAML was updated:

- Add python36-PyYAML provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-appdirs was updated:

- Add python36-appdirs provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-asn1crypto was updated:

- Add python36-asn1crypto provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-certifi was updated:

- Add python36-certifi provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-cffi was updated:

- Add python36-cffi provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-chardet was updated:

- Add python36-chardet provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-idna was updated:

- Add python36-idna provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-packaging was updated:

- Add python36-packaging provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-pyasn1 was updated:

- Add python36-pyasn1 provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-pycparser was updated:

- Add python36-pycparser provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-pyparsing was updated:

- Add python36-pyparsing provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-pytz was updated:

- Add python36-pytz provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-py was updated:

- Add python36-py provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-requests was updated:

- Add python36- provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package salt was updated:

- Prevent tests failures when pygit2 is not present- Several fixes for security issues
  (bsc#1244561, CVE-2024-38822)
  (bsc#1244564, CVE-2024-38823)
  (bsc#1244565, CVE-2024-38824)
  (bsc#1244566, CVE-2024-38825)
  (bsc#1244567, CVE-2025-22240)
  (bsc#1244568, CVE-2025-22236)
  (bsc#1244570, CVE-2025-22241)
  (bsc#1244571, CVE-2025-22237)
  (bsc#1244572, CVE-2025-22238)
  (bsc#1244574, CVE-2025-22239)
  (bsc#1244575, CVE-2025-22242)
  * Request server hardening
  * Prevent traversal in local_cache::save_minions
  * Add test and fix for file_recv cve
  * Fix traversal in gitfs find_file
  * Fix traversal in salt.utils.virt
  * Fix traversal in pub_ret
  * Reasonable failures when pillars timeout
  * Make send_req_async wait longer
  * Remove token to prevent decoding errors
  * Fix checking of non-url style git remotes
  * Allow subdirs in GitFS find_file check
- Add subsystem filter to udev.exportdb (bsc#1236621)
- tornado.httputil: raise errors instead of logging in
  multipart/form-data parsing (CVE-2025-47287, bsc#1243268)
- Fix Ubuntu 24.04 edge-case test failures
- Fix broken tests for Ubuntu 24.04
- Fix refresh of osrelease and related grains on Python 3.10+
- Make &amp;quot;salt&amp;quot; package to obsolete &amp;quot;python3-salt&amp;quot; package on SLE15SP7+
- Fix issue requiring proper Python flavor for dependencies and recommended package
- Added:
  * fix-tests-issues-in-salt-shaker-environments-721.patch
  * several-fixes-for-security-issues.patch
  * fix-of-cve-2025-47287-bsc-1243268-718.patch
  * add-subsystem-filter-to-udev.exportdb-bsc-1236621-71.patch
  * fix-ubuntu-24.04-specific-failures-716.patch
  * fix-debian-tests-715.patch
  * fix-refresh-of-osrelease-and-related-grains-on-pytho.patch

Package python-six was updated:

- Add python36-six provides/obsoletes to enable SLE-12 -&amp;gt;  SLE-15 migration, bsc#1233012

Package python-urllib3 was updated:

- Add patch CVE-2025-50181-poolmanager-redirects.patch:  * Pool managers now properly control redirects when retries is passed
    (CVE-2025-50181, GHSA-pq67-6m6q-mj2v, bsc#1244925)

- Add python36-urllib3 provides/obsoletes to enable SLE-12 -&amp;gt;
  SLE-15 migration, bsc#1233012

Package suse-build-key was updated:

- adjust UID (name + email) of SLES16 signing key with official  names. (bsc#1245223)

Package suse-module-tools was updated:

- Update to version 15.3.19:  * add blacklist entry for reiserfs (jsc#PED-6167)
  * Add more modules to file system blacklist (jsc#PED-6167)
  * Add hfsplus to file system blacklist (bsc#1240950, jsc#PED-12632)
  * Enable f2fs (bsc#1184415)

Package systemd-presets-branding-SMO was updated:

- Enable sysstat_collect.timer and sysstat_summary.timer.  Bugs: bsc#1244553 / bsc#1246835
- Modified sources:
  * 50-default-SUSE_MicroOS.preset

Package vim was updated:

- Refresh patch:  * vim-8.2.2411-globalvimrc.patch
- Add patch:
  * reorder-exit-raw-mode.patch
- Fix the following CVEs and bugs:
  * bsc#1246602 (CVE-2025-53906)
  * bsc#1246604 (CVE-2025-53905)
  * bsc#1247939 (CVE-2025-55158)
  * bsc#1247938 (CVE-2025-55157)
- Update to 9.1.1629:
  9.1.1629: Vim9: Not able to use more than 10 type arguments in a generic function
  9.1.1628: fuzzy.c has a few issues
  9.1.1627: fuzzy matching can be improved
  9.1.1626: cindent: does not handle compound literals
  9.1.1625: Autocompletion slow with include- and tag-completion
  9.1.1624: Cscope not enabled on MacOS
  9.1.1623: Buffer menu does not handle unicode names correctly
  9.1.1622: Patch v9.1.1432 causes performance regressions
  9.1.1621: flicker in popup menu during cmdline autocompletion
  9.1.1620: filetype: composer.lock and symfony.lock files not recognized
  9.1.1619: Incorrect E535 error message
  9.1.1618: completion: incorrect selected index returned from complete_info()
  9.1.1617: Vim9: some error messages can be improved
  9.1.1616: xxd: possible buffer overflow with bitwise output
  9.1.1615: diff format erroneously detected
  9.1.1614: Vim9: possible variable type change
  9.1.1613: tests: test_search leaves a few swapfiles behind
  9.1.1612: Ctrl-G/Ctrl-T do not ignore the end search delimiter
  9.1.1611: possible undefined behaviour in mb_decompose()
  9.1.1610: completion: hang or E684 when 'tagfunc' calls complete()
  9.1.1609: complete: Heap-buffer overflow with complete function
  9.1.1608: No command-line completion for :unsilent {command}
  9.1.1607: :apple command detected as :append
  9.1.1606: filetype: a few more files are not recognized
  9.1.1605: cannot specify scope for chdir()
  9.1.1604: completion: incsearch highlight might be lost
  9.1.1603: completion: cannot use autoloaded funcs in 'complete' F{func}
  9.1.1602: filetype: requirements-*.txt files are not recognized
  9.1.1601: Patch v8.1.0425 was wrong
  9.1.1600: using diff anchors with hidden buffers fails silently
  9.1.1599: :bnext doesn't go to unlisted help buffers
  9.1.1598: filetype: waybar config file is not recognized
  9.1.1597: CI reports leaks in libgtk3 library
  9.1.1596: tests: Test_search_wildmenu_iminsert() depends on help file
  9.1.1595: Wayland: non-portable use of select()
  9.1.1594: completion: search completion throws errors
  9.1.1593: Confusing error when compiling incomplete try block
  9.1.1592: Vim9: crash with classes and garbage collection
  9.1.1591: VMS support can be improved
  9.1.1590: cannot perform autocompletion
  9.1.1589: Cannot disable cscope interface using configure
  9.1.1588: Vim9: cannot split dict inside command block
  9.1.1587: Wayland: timeout not updated before select()
  9.1.1586: Vim9: can define an enum/interface in a function
  9.1.1585: Wayland: gvim still needs GVIM_ENABLE_WAYLAND
  9.1.1584: using ints as boolean type
  9.1.1583: gvim window lost its icons
  9.1.1582: style issue in vim9type.c and vim9generics.c
  9.1.1581: possible memory leak in vim9generics.c
  9.1.1580: possible memory leak in vim9type.c
  9.1.1579: Coverity complains about unchecked return value
  9.1.1578: configure: comment still mentions autoconf 2.71
  9.1.1577: Vim9: no generic support yet
  9.1.1576: cannot easily trigger wildcard expansion
  9.1.1575: tabpanel not drawn correctly with wrapped lines
  9.1.1574: Dead code in mbyte.c
  9.1.1573: Memory leak when pressing Ctrl-D in cmdline mode
  9.1.1572: expanding $var does not escape whitespace for 'path'
  9.1.1571: CmdlineChanged triggered to often
  9.1.1570: Copilot suggested some improvements in cmdexpand.c
  9.1.1569: tests: Vim9 tests can be improved
  9.1.1568: need a few more default highlight groups
  9.1.1567: crash when using inline diff mode
  9.1.1566: self-referenced enum may not get freed
  9.1.1565: configure: does not consider tiny version for wayland
  9.1.1564: crash when opening popup to closing buffer
  9.1.1563: completion: ruler may disappear
  9.1.1562: close button always visible in the 'tabline'
  9.1.1561: configure: wayland test can be improved
  9.1.1560: configure: uses $PKG_CONFIG before it is defined
  9.1.1559: tests: Test_popup_complete_info_01() fails when run alone
  9.1.1558: str2blob() treats NULL string and empty string differently
  9.1.1557: not possible to anchor specific lines in difff mode
  9.1.1556: string handling in cmdexpand.c can be improved
  9.1.1555: completion: repeated insertion of leader
  9.1.1554: crash when omni-completion opens command-line window
  9.1.1553: Vim9: crash when accessing a variable in if condition
  9.1.1552: [security]: path traversal issue in tar.vim
  9.1.1551: [security]: path traversal issue in zip.vim
  9.1.1550: defaults: 'showcmd' is not enabled in non-compatible mode on Unix
  9.1.1549: filetype: pkl files are not recognized
  9.1.1548: filetype: OpenFGA files are not recognized
  9.1.1547: Wayland: missing ifdef
  9.1.1546: Vim9: error with has() and short circuit evaluation
  9.1.1545: typo in os_unix.c
  9.1.1544: :retab cannot be limited to indentation only
  9.1.1543: Wayland: clipboard appears to not be working
  9.1.1542: Coverity complains about uninitialized variable
  9.1.1541: Vim9: error when last enum value ends with a comma
  9.1.1540: completion: menu state wrong on interruption
  9.1.1539: completion: messages don't respect 'shm' setting
  9.1.1537: helptoc: still some issues when markdown code blocks
  9.1.1536: tests: test_plugin_comment uses wrong :Check command
  9.1.1535: the maximum search count uses hard-coded value 99
  9.1.1534: unnecessary code in tabpanel.c
  9.1.1533: helptoc: does not handle code sections in markdown well
  9.1.1532: termdebug: not enough ways to configure breakpoints
  9.1.1531: confusing error with nested legacy function
  9.1.1530: Missing version change in v9.1.1529
  9.1.1529: Win32: the toolbar in the GUI is old and dated
  9.1.1528: completion: crash with getcompletion()
  9.1.1527: Vim9: Crash with string compound assignment
  9.1.1526: completion: search completion match may differ in case
  9.1.1525: tests: testdir/ is a bit messy
  9.1.1524: tests: too many imports in the test suite
  9.1.1523: tests: test_clipmethod fails in non X11 environment
  9.1.1522: tests: still some ANSI escape sequences in test output
  9.1.1521: completion: pum does not reset scroll pos on reopen with 'noselect'
  9.1.1520: completion: search completion doesn't handle 'smartcase' well
  9.1.1519: tests: Test_termdebug_decimal_breakpoints() may fail
  9.1.1518: getcompletiontype() may crash
  9.1.1517: filetype: autopkgtest files are not recognized
  9.1.1516: tests: no test that 'incsearch' is updated after search completion
  9.1.1515: Coverity complains about potential unterminated strings
  9.1.1514: Coverity complains about the use of tmpfile()
  9.1.1513: resizing Vim window causes unexpected internal window width
  9.1.1512: completion: can only complete from keyword characters
  9.1.1511: tests: two edit tests change v:testing from 1 to 0
  9.1.1510: Search completion may use invalid memory
  9.1.1509: patch 9.1.1505 was not good
  9.1.1508: string manipulation can be improved in cmdexpand.c
  9.1.1507: symlinks are resolved on :cd commands
  9.1.1506: tests: missing cleanup in Test_search_cmdline_incsearch_highlight()
  9.1.1505: not possible to return completion type for :ex command
  9.1.1504: filetype: numbat files are not recognized
  9.1.1503: filetype: haxe files are not recognized
  9.1.1502: filetype: quickbms files are not recognized
  9.1.1501: filetype: flix files are not recognized
  9.1.1500: if_python: typo in python error variable
  9.1.1499: MS-Windows: no indication of ARM64 architecture
  9.1.1498: completion: 'complete' funcs behave different to 'omnifunc'
  9.1.1497: Link error with shm_open()
  9.1.1496: terminal: still not highlighting empty cells correctly
  9.1.1495: Wayland: uses $XDG_SEAT to determine seat
  9.1.1494: runtime(tutor): no French translation for Chapter 2
  9.1.1493: manually comparing positions on buffer
  9.1.1492: tests: failure when Wayland compositor fails to start
  9.1.1491: missing out-of-memory checks in cmdexpand.c
  9.1.1490: 'wildchar' does not work in search contexts
  9.1.1489: terminal: no visual highlight of empty cols with empty 'listchars'
  9.1.1488: configure: using obsolete macro AC_PROG_GCC_TRADITIONAL
  9.1.1487: :cl doesn't invoke :clist
  9.1.1486: documentation issues with Wayland
  9.1.1485: missing Wayland clipboard support
  9.1.1484: tests: Turkish locale tests fails on Mac
  9.1.1483: not possible to translation position in buffer
  9.1.1482: scrolling with 'splitkeep' and line()
  9.1.1481: gcc complains about uninitialized variable
  9.1.1480: Turkish translation outdated
  9.1.1479: regression when displaying localized percentage position
  9.1.1478: Unused assignment in ex_uniq()
  9.1.1476: no easy way to deduplicate text
  9.1.1476: missing out-of-memory checks in cmdexpand.c
  9.1.1475: completion: regression when &amp;quot;nearest&amp;quot; in 'completeopt'
  9.1.1474: missing out-of-memory check in mark.c
  9.1.1473: inconsistent range arg for :diffget/diffput
  9.1.1472: if_python: PySequence_Fast_{GET_SIZE,GET_ITEM} removed
  9.1.1471: completion: inconsistent ordering with CTRL-P
  9.1.1470: use-after-free with popup callback on error
  9.1.1469: potential buffer-underflow with invalid hl_id
  9.1.1468: filetype: bright(er)script files are not recognized
  9.1.1467: too many strlen() calls
  9.1.1466: filetype: not all lex files are recognized
  9.1.1465: tabpanel: not correctly drawn with 'equalalways'
  9.1.1464: gv does not work in operator-pending mode
  9.1.1463: Integer overflow in getmarklist() after linewise operation
  9.1.1462: missing change from patch v9.1.1461
  9.1.1461: tabpanel: tabpanel vanishes with popup menu
  9.1.1460: MS-Windows: too many strlen() calls in os_win32.c
  9.1.1459: xxd: coloring output is inefficient
  9.1.1458: tabpanel: tabs not properly updated with 'stpl'
  9.1.1457: compile warning with tabpanelopt
  9.1.1456: comment plugin fails toggling if 'cms' contains \
  9.1.1455: Haiku: dailog objects created with no reference
  9.1.1454: tests: no test for pum at line break position
  9.1.1453: tests: Test_geometry() may fail
  9.1.1452: completion: redundant check for completion flags
  9.1.1451: tabpanel rendering artifacts when scrolling
  9.1.1450: Session has wrong arglist with :tcd and :arglocal
  9.1.1449: typo in pum_display()
  9.1.1448: tabpanel is not displayed correctly when msg_scrolled
  9.1.1447: completion: crash when backspacing with fuzzy completion
  9.1.1446: filetype: cuda-gdb config files are not recognized
  9.1.1445: negative matchfuzzy scores although there is a match
  9.1.1444: Unused assignment in set_fuzzy_score()
  9.1.1443: potential buffer underflow in insertchar()
  9.1.1442: tests: Test_diff_fold_redraw() is insufficient
  9.1.1441: completion: code can be improved
  9.1.1440: too many strlen() calls in os_win32.c
  9.1.1439: Last diff folds not merged
  9.1.1438: tests: Test_breakindent_list_split() fails
  9.1.1437: MS-Windows: internal compile error in uc_list()
  9.1.1436: GUI control code is displayed on the console on startup
  9.1.1435: completion: various flaws in fuzzy completion
  9.1.1434: MS-Windows: missing out-of-memory checks in os_win32.c
  9.1.1433: Unnecessary :if when writing session
  9.1.1432: GTK GUI: Buffer menu does not handle unicode correctly
  9.1.1431: Hit-Enter Prompt when loading session files
  9.1.1430: tabpanel may flicker in the GUI
  9.1.1429: dragging outside the tabpanel changes tabpagenr
  9.1.1428: completion: register completion needs cleanup
  9.1.1427: rendering artifacts with the tabpanel
  9.1.1426: completion: register contents not completed
  9.1.1425: tabpanel: there are still some problems with the tabpanel
  9.1.1424: PMenu selection broken with multi-line selection and limits
  9.1.1423: :tag command not working correctly using Vim9 Script
  9.1.1422: scheduling of complete function can be improved
  9.1.1421: tests: need a test for the new-style tutor.tutor
  9.1.1420: tests: could need some more tests for shebang lines
  9.1.1419: It is difficult to ignore all but some events
  9.1.1418: configures GUI auto detection favors GTK2
  9.1.1417: missing info about register completion in complete_info()
  9.1.1416: completion limits not respected for fuzzy completions
  9.1.1415: potential use-after free when there is an error in 'tabpanel'
  9.1.1414: MS-Windows: compile warnings in os_win32.c
  9.1.1413: spurious CursorHold triggered in GUI on startup
  9.1.1412: tests: Test_tabpanel_tabonly() fails on larger screens
  9.1.1411: crash when calling non-existing function for tabpanel
  9.1.1410: out-of-bounds access with 'completefunc'
  9.1.1409: using f-flag in 'complete' conflicts with Neovim
  9.1.1408: not easily possible to complete from register content
  9.1.1407: Can't use getpos('v') in OptionSet when using setbufvar()

Package xen was updated:

- bsc#1246112, bsc#1238896 - VUL-0: xen: More AMD transient  execution attack (XSA-471)
  xsa471-01.patch
  xsa471-02.patch
  xsa471-03.patch
  xsa471-04.patch
  xsa471-05.patch
  xsa471-06.patch
  xsa471-07.patch
  xsa471-08.patch
  xsa471-09.patch
  xsa471-10.patch
  xsa471-11.patch
  xsa471-12.patch
  xsa471-13.patch
  xsa471-14.patch
  xsa471-15.patch
  xsa471-16.patch
  xsa471-17.patch
  xsa471-18.patch
  xsa471-19.patch
  xsa471-20.patch

- bsc#1244644 - VUL-0: CVE-2025-27465: xen: x86: Incorrect stubs
  exception handling for flags recovery (XSA-470)
  xsa470.patch

Package zypper was updated:

- Fix addrepo to handle explicit --check and --no-check requests  (bsc#1246466)
- Accept &amp;quot;show&amp;quot; as alias for &amp;quot;info&amp;quot; (bsc#1245985)
- version 1.14.93

- sh: Reset solver options after command (bsc#1245496)
- Explicitly selecting DownloadAsNeeded also selects the
  classic_rpmtrans backend.
- version 1.14.92

- BuildRequires:  libzypp-devel &amp;gt;= 17.37.6.
  Enhancements regarding mirror handling during repo refresh. Adapt
  to libzypp API changes. (bsc#1230267)
- version 1.14.91

</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-micro-5-2-byos-v20250923-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-micro-5-2-byos-v20250923-x86-64">
      <Branch Type="Product Name" Name="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
        <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
      </Branch>
    </Branch>
    <Branch Type="Product Version" Name="boost-license1_66_0-1.66.0-150200.12.7.1">
      <FullProductName ProductID="boost-license1_66_0-1.66.0-150200.12.7.1">boost-license1_66_0-1.66.0-150200.12.7.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="coreutils-8.32-150300.3.11.1">
      <FullProductName ProductID="coreutils-8.32-150300.3.11.1">coreutils-8.32-150300.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="curl-8.14.1-150200.4.91.1">
      <FullProductName ProductID="curl-8.14.1-150200.4.91.1">curl-8.14.1-150200.4.91.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="docker-28.3.3_ce-150000.230.1">
      <FullProductName ProductID="docker-28.3.3_ce-150000.230.1">docker-28.3.3_ce-150000.230.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="dracut-transactional-update-4.0.1-150300.3.14.4">
      <FullProductName ProductID="dracut-transactional-update-4.0.1-150300.3.14.4">dracut-transactional-update-4.0.1-150300.3.14.4</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-dracut-config-0.0.4-150300.7.12.1">
      <FullProductName ProductID="google-dracut-config-0.0.4-150300.7.12.1">google-dracut-config-0.0.4-150300.7.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grub2-2.04-150300.22.58.1">
      <FullProductName ProductID="grub2-2.04-150300.22.58.1">grub2-2.04-150300.22.58.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grub2-i386-pc-2.04-150300.22.58.1">
      <FullProductName ProductID="grub2-i386-pc-2.04-150300.22.58.1">grub2-i386-pc-2.04-150300.22.58.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grub2-x86_64-efi-2.04-150300.22.58.1">
      <FullProductName ProductID="grub2-x86_64-efi-2.04-150300.22.58.1">grub2-x86_64-efi-2.04-150300.22.58.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="hwinfo-21.89-150300.3.16.1">
      <FullProductName ProductID="hwinfo-21.89-150300.3.16.1">hwinfo-21.89-150300.3.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ignition-2.14.0-150300.6.16.1">
      <FullProductName ProductID="ignition-2.14.0-150300.6.16.1">ignition-2.14.0-150300.6.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ignition-dracut-grub2-2.14.0-150300.6.16.1">
      <FullProductName ProductID="ignition-dracut-grub2-2.14.0-150300.6.16.1">ignition-dracut-grub2-2.14.0-150300.6.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="iputils-s20161105-150000.8.14.1">
      <FullProductName ProductID="iputils-s20161105-150000.8.14.1">iputils-s20161105-150000.8.14.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kernel-default-5.3.18-150300.59.215.1">
      <FullProductName ProductID="kernel-default-5.3.18-150300.59.215.1">kernel-default-5.3.18-150300.59.215.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="krb5-1.19.2-150300.25.1">
      <FullProductName ProductID="krb5-1.19.2-150300.25.1">krb5-1.19.2-150300.25.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libboost_system1_66_0-1.66.0-150200.12.7.1">
      <FullProductName ProductID="libboost_system1_66_0-1.66.0-150200.12.7.1">libboost_system1_66_0-1.66.0-150200.12.7.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libboost_thread1_66_0-1.66.0-150200.12.7.1">
      <FullProductName ProductID="libboost_thread1_66_0-1.66.0-150200.12.7.1">libboost_thread1_66_0-1.66.0-150200.12.7.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libbrotlicommon1-1.0.7-150200.3.5.1">
      <FullProductName ProductID="libbrotlicommon1-1.0.7-150200.3.5.1">libbrotlicommon1-1.0.7-150200.3.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libbrotlidec1-1.0.7-150200.3.5.1">
      <FullProductName ProductID="libbrotlidec1-1.0.7-150200.3.5.1">libbrotlidec1-1.0.7-150200.3.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libcurl4-8.14.1-150200.4.91.1">
      <FullProductName ProductID="libcurl4-8.14.1-150200.4.91.1">libcurl4-8.14.1-150200.4.91.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgcc_s1-14.3.0+git11799-150000.1.11.1">
      <FullProductName ProductID="libgcc_s1-14.3.0+git11799-150000.1.11.1">libgcc_s1-14.3.0+git11799-150000.1.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgcrypt20-1.8.2-150100.8.45.1">
      <FullProductName ProductID="libgcrypt20-1.8.2-150100.8.45.1">libgcrypt20-1.8.2-150100.8.45.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgnutls30-3.6.7-150200.14.37.1">
      <FullProductName ProductID="libgnutls30-3.6.7-150200.14.37.1">libgnutls30-3.6.7-150200.14.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpolkit0-0.116-150200.3.15.1">
      <FullProductName ProductID="libpolkit0-0.116-150200.3.15.1">libpolkit0-0.116-150200.3.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpython3_6m1_0-3.6.15-150300.10.97.1">
      <FullProductName ProductID="libpython3_6m1_0-3.6.15-150300.10.97.1">libpython3_6m1_0-3.6.15-150300.10.97.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libruby2_5-2_5-2.5.9-150000.4.49.1">
      <FullProductName ProductID="libruby2_5-2_5-2.5.9-150000.4.49.1">libruby2_5-2_5-2.5.9-150000.4.49.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsolv-tools-0.7.34-150200.48.2">
      <FullProductName ProductID="libsolv-tools-0.7.34-150200.48.2">libsolv-tools-0.7.34-150200.48.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsolv-tools-base-0.7.34-150200.48.2">
      <FullProductName ProductID="libsolv-tools-base-0.7.34-150200.48.2">libsolv-tools-base-0.7.34-150200.48.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsqlite3-0-3.50.2-150000.3.33.1">
      <FullProductName ProductID="libsqlite3-0-3.50.2-150000.3.33.1">libsqlite3-0-3.50.2-150000.3.33.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libssh-config-0.9.8-150200.13.9.1">
      <FullProductName ProductID="libssh-config-0.9.8-150200.13.9.1">libssh-config-0.9.8-150200.13.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libssh4-0.9.8-150200.13.9.1">
      <FullProductName ProductID="libssh4-0.9.8-150200.13.9.1">libssh4-0.9.8-150200.13.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libstdc++6-14.3.0+git11799-150000.1.11.1">
      <FullProductName ProductID="libstdc++6-14.3.0+git11799-150000.1.11.1">libstdc++6-14.3.0+git11799-150000.1.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libtukit4-4.0.1-150300.3.14.4">
      <FullProductName ProductID="libtukit4-4.0.1-150300.3.14.4">libtukit4-4.0.1-150300.3.14.4</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxml2-2-2.9.7-150000.3.85.1">
      <FullProductName ProductID="libxml2-2-2.9.7-150000.3.85.1">libxml2-2-2.9.7-150000.3.85.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libyaml-0-2-0.1.7-150000.3.4.1">
      <FullProductName ProductID="libyaml-0-2-0.1.7-150000.3.4.1">libyaml-0-2-0.1.7-150000.3.4.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libzypp-17.37.16-150200.171.1">
      <FullProductName ProductID="libzypp-17.37.16-150200.171.1">libzypp-17.37.16-150200.171.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="net-tools-2.0+git20170221.479bb4a-150000.5.13.1">
      <FullProductName ProductID="net-tools-2.0+git20170221.479bb4a-150000.5.13.1">net-tools-2.0+git20170221.479bb4a-150000.5.13.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="pam-1.3.0-150000.6.86.1">
      <FullProductName ProductID="pam-1.3.0-150000.6.86.1">pam-1.3.0-150000.6.86.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="polkit-0.116-150200.3.15.1">
      <FullProductName ProductID="polkit-0.116-150200.3.15.1">polkit-0.116-150200.3.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-3.6.15-150300.10.97.2">
      <FullProductName ProductID="python3-3.6.15-150300.10.97.2">python3-3.6.15-150300.10.97.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-PyYAML-5.4.1-150300.3.6.1">
      <FullProductName ProductID="python3-PyYAML-5.4.1-150300.3.6.1">python3-PyYAML-5.4.1-150300.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-apipkg-1.4-150000.3.8.1">
      <FullProductName ProductID="python3-apipkg-1.4-150000.3.8.1">python3-apipkg-1.4-150000.3.8.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-appdirs-1.4.3-150000.3.3.1">
      <FullProductName ProductID="python3-appdirs-1.4.3-150000.3.3.1">python3-appdirs-1.4.3-150000.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-asn1crypto-0.24.0-150000.3.5.1">
      <FullProductName ProductID="python3-asn1crypto-0.24.0-150000.3.5.1">python3-asn1crypto-0.24.0-150000.3.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-base-3.6.15-150300.10.97.1">
      <FullProductName ProductID="python3-base-3.6.15-150300.10.97.1">python3-base-3.6.15-150300.10.97.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-certifi-2018.1.18-150000.3.6.1">
      <FullProductName ProductID="python3-certifi-2018.1.18-150000.3.6.1">python3-certifi-2018.1.18-150000.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-cffi-1.13.2-150200.3.5.1">
      <FullProductName ProductID="python3-cffi-1.13.2-150200.3.5.1">python3-cffi-1.13.2-150200.3.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-chardet-3.0.4-150000.5.6.1">
      <FullProductName ProductID="python3-chardet-3.0.4-150000.5.6.1">python3-chardet-3.0.4-150000.5.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-idna-2.6-150000.3.6.1">
      <FullProductName ProductID="python3-idna-2.6-150000.3.6.1">python3-idna-2.6-150000.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-iniconfig-1.1.1-150000.1.13.1">
      <FullProductName ProductID="python3-iniconfig-1.1.1-150000.1.13.1">python3-iniconfig-1.1.1-150000.1.13.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-packaging-21.3-150200.3.6.1">
      <FullProductName ProductID="python3-packaging-21.3-150200.3.6.1">python3-packaging-21.3-150200.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-py-1.10.0-150100.5.15.1">
      <FullProductName ProductID="python3-py-1.10.0-150100.5.15.1">python3-py-1.10.0-150100.5.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-pyasn1-0.4.2-150000.3.8.1">
      <FullProductName ProductID="python3-pyasn1-0.4.2-150000.3.8.1">python3-pyasn1-0.4.2-150000.3.8.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-pycparser-2.17-150000.3.5.1">
      <FullProductName ProductID="python3-pycparser-2.17-150000.3.5.1">python3-pycparser-2.17-150000.3.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-pyparsing-2.4.7-150300.3.3.1">
      <FullProductName ProductID="python3-pyparsing-2.4.7-150300.3.3.1">python3-pyparsing-2.4.7-150300.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-pytz-2022.1-150300.3.9.1">
      <FullProductName ProductID="python3-pytz-2022.1-150300.3.9.1">python3-pytz-2022.1-150300.3.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-requests-2.25.1-150300.3.18.1">
      <FullProductName ProductID="python3-requests-2.25.1-150300.3.18.1">python3-requests-2.25.1-150300.3.18.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-salt-3006.0-150300.53.94.1">
      <FullProductName ProductID="python3-salt-3006.0-150300.53.94.1">python3-salt-3006.0-150300.53.94.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-six-1.14.0-150200.15.1">
      <FullProductName ProductID="python3-six-1.14.0-150200.15.1">python3-six-1.14.0-150200.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-urllib3-1.25.10-150300.4.18.1">
      <FullProductName ProductID="python3-urllib3-1.25.10-150300.4.18.1">python3-urllib3-1.25.10-150300.4.18.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ruby2.5-2.5.9-150000.4.49.1">
      <FullProductName ProductID="ruby2.5-2.5.9-150000.4.49.1">ruby2.5-2.5.9-150000.4.49.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ruby2.5-stdlib-2.5.9-150000.4.49.1">
      <FullProductName ProductID="ruby2.5-stdlib-2.5.9-150000.4.49.1">ruby2.5-stdlib-2.5.9-150000.4.49.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="salt-3006.0-150300.53.94.1">
      <FullProductName ProductID="salt-3006.0-150300.53.94.1">salt-3006.0-150300.53.94.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="salt-minion-3006.0-150300.53.94.1">
      <FullProductName ProductID="salt-minion-3006.0-150300.53.94.1">salt-minion-3006.0-150300.53.94.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="salt-transactional-update-3006.0-150300.53.94.1">
      <FullProductName ProductID="salt-transactional-update-3006.0-150300.53.94.1">salt-transactional-update-3006.0-150300.53.94.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suse-build-key-12.0-150000.8.61.2">
      <FullProductName ProductID="suse-build-key-12.0-150000.8.61.2">suse-build-key-12.0-150000.8.61.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suse-module-tools-15.3.19-150300.3.28.3">
      <FullProductName ProductID="suse-module-tools-15.3.19-150300.3.28.3">suse-module-tools-15.3.19-150300.3.28.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-presets-branding-SMO-20220103-150300.5.3.2">
      <FullProductName ProductID="systemd-presets-branding-SMO-20220103-150300.5.3.2">systemd-presets-branding-SMO-20220103-150300.5.3.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="transactional-update-4.0.1-150300.3.14.4">
      <FullProductName ProductID="transactional-update-4.0.1-150300.3.14.4">transactional-update-4.0.1-150300.3.14.4</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="transactional-update-zypp-config-4.0.1-150300.3.14.4">
      <FullProductName ProductID="transactional-update-zypp-config-4.0.1-150300.3.14.4">transactional-update-zypp-config-4.0.1-150300.3.14.4</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="tukit-4.0.1-150300.3.14.4">
      <FullProductName ProductID="tukit-4.0.1-150300.3.14.4">tukit-4.0.1-150300.3.14.4</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="update-alternatives-1.19.0.4-150000.4.7.1">
      <FullProductName ProductID="update-alternatives-1.19.0.4-150000.4.7.1">update-alternatives-1.19.0.4-150000.4.7.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="vim-data-common-9.1.1629-150000.5.78.1">
      <FullProductName ProductID="vim-data-common-9.1.1629-150000.5.78.1">vim-data-common-9.1.1629-150000.5.78.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="vim-small-9.1.1629-150000.5.78.1">
      <FullProductName ProductID="vim-small-9.1.1629-150000.5.78.1">vim-small-9.1.1629-150000.5.78.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="xen-libs-4.14.6_26-150300.3.91.1">
      <FullProductName ProductID="xen-libs-4.14.6_26-150300.3.91.1">xen-libs-4.14.6_26-150300.3.91.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="zypper-1.14.93-150200.123.2">
      <FullProductName ProductID="zypper-1.14.93-150200.123.2">zypper-1.14.93-150200.123.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="zypper-needs-restarting-1.14.93-150200.123.2">
      <FullProductName ProductID="zypper-needs-restarting-1.14.93-150200.123.2">zypper-needs-restarting-1.14.93-150200.123.2</FullProductName>
    </Branch>
    <Relationship ProductReference="boost-license1_66_0-1.66.0-150200.12.7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:boost-license1_66_0-1.66.0-150200.12.7.1">boost-license1_66_0-1.66.0-150200.12.7.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="coreutils-8.32-150300.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:coreutils-8.32-150300.3.11.1">coreutils-8.32-150300.3.11.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="curl-8.14.1-150200.4.91.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:curl-8.14.1-150200.4.91.1">curl-8.14.1-150200.4.91.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="docker-28.3.3_ce-150000.230.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:docker-28.3.3_ce-150000.230.1">docker-28.3.3_ce-150000.230.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="dracut-transactional-update-4.0.1-150300.3.14.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:dracut-transactional-update-4.0.1-150300.3.14.4">dracut-transactional-update-4.0.1-150300.3.14.4 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-dracut-config-0.0.4-150300.7.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:google-dracut-config-0.0.4-150300.7.12.1">google-dracut-config-0.0.4-150300.7.12.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-2.04-150300.22.58.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:grub2-2.04-150300.22.58.1">grub2-2.04-150300.22.58.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-i386-pc-2.04-150300.22.58.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:grub2-i386-pc-2.04-150300.22.58.1">grub2-i386-pc-2.04-150300.22.58.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-x86_64-efi-2.04-150300.22.58.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:grub2-x86_64-efi-2.04-150300.22.58.1">grub2-x86_64-efi-2.04-150300.22.58.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="hwinfo-21.89-150300.3.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:hwinfo-21.89-150300.3.16.1">hwinfo-21.89-150300.3.16.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ignition-2.14.0-150300.6.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:ignition-2.14.0-150300.6.16.1">ignition-2.14.0-150300.6.16.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ignition-dracut-grub2-2.14.0-150300.6.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:ignition-dracut-grub2-2.14.0-150300.6.16.1">ignition-dracut-grub2-2.14.0-150300.6.16.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="iputils-s20161105-150000.8.14.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:iputils-s20161105-150000.8.14.1">iputils-s20161105-150000.8.14.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kernel-default-5.3.18-150300.59.215.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:kernel-default-5.3.18-150300.59.215.1">kernel-default-5.3.18-150300.59.215.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="krb5-1.19.2-150300.25.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:krb5-1.19.2-150300.25.1">krb5-1.19.2-150300.25.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libboost_system1_66_0-1.66.0-150200.12.7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:libboost_system1_66_0-1.66.0-150200.12.7.1">libboost_system1_66_0-1.66.0-150200.12.7.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libboost_thread1_66_0-1.66.0-150200.12.7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:libboost_thread1_66_0-1.66.0-150200.12.7.1">libboost_thread1_66_0-1.66.0-150200.12.7.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libbrotlicommon1-1.0.7-150200.3.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:libbrotlicommon1-1.0.7-150200.3.5.1">libbrotlicommon1-1.0.7-150200.3.5.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libbrotlidec1-1.0.7-150200.3.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:libbrotlidec1-1.0.7-150200.3.5.1">libbrotlidec1-1.0.7-150200.3.5.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libcurl4-8.14.1-150200.4.91.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:libcurl4-8.14.1-150200.4.91.1">libcurl4-8.14.1-150200.4.91.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgcc_s1-14.3.0+git11799-150000.1.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:libgcc_s1-14.3.0+git11799-150000.1.11.1">libgcc_s1-14.3.0+git11799-150000.1.11.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgcrypt20-1.8.2-150100.8.45.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:libgcrypt20-1.8.2-150100.8.45.1">libgcrypt20-1.8.2-150100.8.45.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgnutls30-3.6.7-150200.14.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:libgnutls30-3.6.7-150200.14.37.1">libgnutls30-3.6.7-150200.14.37.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpolkit0-0.116-150200.3.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:libpolkit0-0.116-150200.3.15.1">libpolkit0-0.116-150200.3.15.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpython3_6m1_0-3.6.15-150300.10.97.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:libpython3_6m1_0-3.6.15-150300.10.97.1">libpython3_6m1_0-3.6.15-150300.10.97.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libruby2_5-2_5-2.5.9-150000.4.49.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:libruby2_5-2_5-2.5.9-150000.4.49.1">libruby2_5-2_5-2.5.9-150000.4.49.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsolv-tools-0.7.34-150200.48.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:libsolv-tools-0.7.34-150200.48.2">libsolv-tools-0.7.34-150200.48.2 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsolv-tools-base-0.7.34-150200.48.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:libsolv-tools-base-0.7.34-150200.48.2">libsolv-tools-base-0.7.34-150200.48.2 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsqlite3-0-3.50.2-150000.3.33.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:libsqlite3-0-3.50.2-150000.3.33.1">libsqlite3-0-3.50.2-150000.3.33.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libssh-config-0.9.8-150200.13.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:libssh-config-0.9.8-150200.13.9.1">libssh-config-0.9.8-150200.13.9.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libssh4-0.9.8-150200.13.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:libssh4-0.9.8-150200.13.9.1">libssh4-0.9.8-150200.13.9.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libstdc++6-14.3.0+git11799-150000.1.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:libstdc++6-14.3.0+git11799-150000.1.11.1">libstdc++6-14.3.0+git11799-150000.1.11.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libtukit4-4.0.1-150300.3.14.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:libtukit4-4.0.1-150300.3.14.4">libtukit4-4.0.1-150300.3.14.4 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxml2-2-2.9.7-150000.3.85.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:libxml2-2-2.9.7-150000.3.85.1">libxml2-2-2.9.7-150000.3.85.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libyaml-0-2-0.1.7-150000.3.4.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:libyaml-0-2-0.1.7-150000.3.4.1">libyaml-0-2-0.1.7-150000.3.4.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libzypp-17.37.16-150200.171.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:libzypp-17.37.16-150200.171.1">libzypp-17.37.16-150200.171.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="net-tools-2.0+git20170221.479bb4a-150000.5.13.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:net-tools-2.0+git20170221.479bb4a-150000.5.13.1">net-tools-2.0+git20170221.479bb4a-150000.5.13.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="pam-1.3.0-150000.6.86.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:pam-1.3.0-150000.6.86.1">pam-1.3.0-150000.6.86.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="polkit-0.116-150200.3.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:polkit-0.116-150200.3.15.1">polkit-0.116-150200.3.15.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-3.6.15-150300.10.97.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:python3-3.6.15-150300.10.97.2">python3-3.6.15-150300.10.97.2 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-PyYAML-5.4.1-150300.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:python3-PyYAML-5.4.1-150300.3.6.1">python3-PyYAML-5.4.1-150300.3.6.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-apipkg-1.4-150000.3.8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:python3-apipkg-1.4-150000.3.8.1">python3-apipkg-1.4-150000.3.8.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-appdirs-1.4.3-150000.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:python3-appdirs-1.4.3-150000.3.3.1">python3-appdirs-1.4.3-150000.3.3.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-asn1crypto-0.24.0-150000.3.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:python3-asn1crypto-0.24.0-150000.3.5.1">python3-asn1crypto-0.24.0-150000.3.5.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-base-3.6.15-150300.10.97.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:python3-base-3.6.15-150300.10.97.1">python3-base-3.6.15-150300.10.97.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-certifi-2018.1.18-150000.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:python3-certifi-2018.1.18-150000.3.6.1">python3-certifi-2018.1.18-150000.3.6.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-cffi-1.13.2-150200.3.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:python3-cffi-1.13.2-150200.3.5.1">python3-cffi-1.13.2-150200.3.5.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-chardet-3.0.4-150000.5.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:python3-chardet-3.0.4-150000.5.6.1">python3-chardet-3.0.4-150000.5.6.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-idna-2.6-150000.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:python3-idna-2.6-150000.3.6.1">python3-idna-2.6-150000.3.6.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-iniconfig-1.1.1-150000.1.13.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:python3-iniconfig-1.1.1-150000.1.13.1">python3-iniconfig-1.1.1-150000.1.13.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-packaging-21.3-150200.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:python3-packaging-21.3-150200.3.6.1">python3-packaging-21.3-150200.3.6.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-py-1.10.0-150100.5.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:python3-py-1.10.0-150100.5.15.1">python3-py-1.10.0-150100.5.15.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-pyasn1-0.4.2-150000.3.8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:python3-pyasn1-0.4.2-150000.3.8.1">python3-pyasn1-0.4.2-150000.3.8.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-pycparser-2.17-150000.3.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:python3-pycparser-2.17-150000.3.5.1">python3-pycparser-2.17-150000.3.5.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-pyparsing-2.4.7-150300.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:python3-pyparsing-2.4.7-150300.3.3.1">python3-pyparsing-2.4.7-150300.3.3.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-pytz-2022.1-150300.3.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:python3-pytz-2022.1-150300.3.9.1">python3-pytz-2022.1-150300.3.9.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-requests-2.25.1-150300.3.18.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:python3-requests-2.25.1-150300.3.18.1">python3-requests-2.25.1-150300.3.18.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-salt-3006.0-150300.53.94.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:python3-salt-3006.0-150300.53.94.1">python3-salt-3006.0-150300.53.94.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-six-1.14.0-150200.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:python3-six-1.14.0-150200.15.1">python3-six-1.14.0-150200.15.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-urllib3-1.25.10-150300.4.18.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:python3-urllib3-1.25.10-150300.4.18.1">python3-urllib3-1.25.10-150300.4.18.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ruby2.5-2.5.9-150000.4.49.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:ruby2.5-2.5.9-150000.4.49.1">ruby2.5-2.5.9-150000.4.49.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ruby2.5-stdlib-2.5.9-150000.4.49.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:ruby2.5-stdlib-2.5.9-150000.4.49.1">ruby2.5-stdlib-2.5.9-150000.4.49.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="salt-3006.0-150300.53.94.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:salt-3006.0-150300.53.94.1">salt-3006.0-150300.53.94.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="salt-minion-3006.0-150300.53.94.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:salt-minion-3006.0-150300.53.94.1">salt-minion-3006.0-150300.53.94.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="salt-transactional-update-3006.0-150300.53.94.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:salt-transactional-update-3006.0-150300.53.94.1">salt-transactional-update-3006.0-150300.53.94.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suse-build-key-12.0-150000.8.61.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:suse-build-key-12.0-150000.8.61.2">suse-build-key-12.0-150000.8.61.2 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suse-module-tools-15.3.19-150300.3.28.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:suse-module-tools-15.3.19-150300.3.28.3">suse-module-tools-15.3.19-150300.3.28.3 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-presets-branding-SMO-20220103-150300.5.3.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:systemd-presets-branding-SMO-20220103-150300.5.3.2">systemd-presets-branding-SMO-20220103-150300.5.3.2 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="transactional-update-4.0.1-150300.3.14.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:transactional-update-4.0.1-150300.3.14.4">transactional-update-4.0.1-150300.3.14.4 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="transactional-update-zypp-config-4.0.1-150300.3.14.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:transactional-update-zypp-config-4.0.1-150300.3.14.4">transactional-update-zypp-config-4.0.1-150300.3.14.4 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="tukit-4.0.1-150300.3.14.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:tukit-4.0.1-150300.3.14.4">tukit-4.0.1-150300.3.14.4 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="update-alternatives-1.19.0.4-150000.4.7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:update-alternatives-1.19.0.4-150000.4.7.1">update-alternatives-1.19.0.4-150000.4.7.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-data-common-9.1.1629-150000.5.78.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:vim-data-common-9.1.1629-150000.5.78.1">vim-data-common-9.1.1629-150000.5.78.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-small-9.1.1629-150000.5.78.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:vim-small-9.1.1629-150000.5.78.1">vim-small-9.1.1629-150000.5.78.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="xen-libs-4.14.6_26-150300.3.91.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:xen-libs-4.14.6_26-150300.3.91.1">xen-libs-4.14.6_26-150300.3.91.1 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="zypper-1.14.93-150200.123.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:zypper-1.14.93-150200.123.2">zypper-1.14.93-150200.123.2 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="zypper-needs-restarting-1.14.93-150200.123.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-2-byos-v20250923-x86-64:zypper-needs-restarting-1.14.93-150200.123.2">zypper-needs-restarting-1.14.93-150200.123.2 as a component of Public Cloud Image google/sle-micro-5-2-byos-v20250923-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">inftrees.c in zlib 1.2.8 might allow context-dependent attackers to have unspecified impact by leveraging improper pointer arithmetic.</Note>
    </Notes>
    <CVE>CVE-2016-9840</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>critical</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>6.8</BaseScore>
        <Vector>AV:N/AC:M/Au:N/C:P/I:P/A:P</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">curl 7.62.0 through 7.70.0 is vulnerable to an information disclosure vulnerability that can lead to a partial password being leaked over the network and to the DNS server(s).</Note>
    </Notes>
    <CVE>CVE-2020-8169</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>5</BaseScore>
        <Vector>AV:N/AC:L/Au:N/C:P/I:N/A:N</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">curl 7.20.0 through 7.70.0 is vulnerable to improper restriction of names for files and other resources that can lead too overwriting a local file when the -J flag is used.</Note>
    </Notes>
    <CVE>CVE-2020-8177</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>4.6</BaseScore>
        <Vector>AV:L/AC:L/Au:N/C:P/I:P/A:P</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">Due to use of a dangling pointer, libcurl 7.29.0 through 7.71.1 can use the wrong connection when sending data.</Note>
    </Notes>
    <CVE>CVE-2020-8231</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>5</BaseScore>
        <Vector>AV:N/AC:L/Au:N/C:P/I:N/A:N</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 malicious server can use the FTP PASV response to trick curl 7.73.0 and earlier into connecting back to a given IP address and port, and this way potentially make curl extract information about services that are otherwise private and not disclosed, for example doing port scanning and service banner extractions.</Note>
    </Notes>
    <CVE>CVE-2020-8284</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>4.3</BaseScore>
        <Vector>AV:N/AC:M/Au:N/C:P/I:N/A:N</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">curl 7.21.0 to and including 7.73.0 is vulnerable to uncontrolled recursion due to a stack overflow issue in FTP wildcard match parsing.</Note>
    </Notes>
    <CVE>CVE-2020-8285</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>5</BaseScore>
        <Vector>AV:N/AC:L/Au:N/C:N/I:N/A:P</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">curl 7.41.0 through 7.73.0 is vulnerable to an improper check for certificate revocation due to insufficient verification of the OCSP response.</Note>
    </Notes>
    <CVE>CVE-2020-8286</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>5</BaseScore>
        <Vector>AV:N/AC:L/Au:N/C:N/I:P/A:N</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">curl 7.1.1 to and including 7.75.0 is vulnerable to an "Exposure of Private Personal Information to an Unauthorized Actor" by leaking credentials in the HTTP Referer: header. libcurl does not strip off user credentials from the URL when automatically populating the Referer: HTTP request header field in outgoing HTTP requests, and therefore risks leaking sensitive data to the server that is the target of the second HTTP request.</Note>
    </Notes>
    <CVE>CVE-2021-22876</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>5</BaseScore>
        <Vector>AV:N/AC:L/Au:N/C:P/I:N/A:N</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">curl 7.63.0 to and including 7.75.0 includes vulnerability that allows a malicious HTTPS proxy to MITM a connection due to bad handling of TLS 1.3 session tickets. When using a HTTPS proxy and TLS 1.3, libcurl can confuse session tickets arriving from the HTTPS proxy but work as if they arrived from the remote server and then wrongly "short-cut" the host handshake. When confusing the tickets, a HTTPS proxy can trick libcurl to use the wrong session ticket resume for the host and thereby circumvent the server TLS certificate check and make a MITM attack to be possible to perform unnoticed. Note that such a malicious HTTPS proxy needs to provide a certificate that curl will accept for the MITMed server for an attack to work - unless curl has been told to ignore the server certificate check.</Note>
    </Notes>
    <CVE>CVE-2021-22890</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>4.3</BaseScore>
        <Vector>AV:N/AC:M/Au:N/C:N/I:P/A:N</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">curl 7.7 through 7.76.1 suffers from an information disclosure when the `-t` command line option, known as `CURLOPT_TELNETOPTIONS` in libcurl, is used to send variable=content pairs to TELNET servers. Due to a flaw in the option parser for sending NEW_ENV variables, libcurl could be made to pass on uninitialized data from a stack based buffer to the server, resulting in potentially revealing sensitive internal information to the server using a clear-text network protocol.</Note>
    </Notes>
    <CVE>CVE-2021-22898</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>2.6</BaseScore>
        <Vector>AV:N/AC:H/Au:N/C:P/I:N/A:N</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">libcurl keeps previously used connections in a connection pool for subsequenttransfers to reuse, if one of them matches the setup.Due to errors in the logic, the config matching function did not take 'issuercert' into account and it compared the involved paths *case insensitively*,which could lead to libcurl reusing wrong connections.File paths are, or can be, case sensitive on many systems but not all, and caneven vary depending on used file systems.The comparison also didn't include the 'issuer cert' which a transfer can setto qualify how to verify the server certificate.</Note>
    </Notes>
    <CVE>CVE-2021-22924</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>4.3</BaseScore>
        <Vector>AV:N/AC:M/Au:N/C:P/I:N/A:N</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">curl supports the `-t` command line option, known as `CURLOPT_TELNETOPTIONS`in libcurl. This rarely used option is used to send variable=content pairs toTELNET servers.Due to flaw in the option parser for sending `NEW_ENV` variables, libcurlcould be made to pass on uninitialized data from a stack based buffer to theserver. Therefore potentially revealing sensitive internal information to theserver using a clear-text network protocol.This could happen because curl did not call and use sscanf() correctly whenparsing the string provided by the application.</Note>
    </Notes>
    <CVE>CVE-2021-22925</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>5</BaseScore>
        <Vector>AV:N/AC:L/Au:N/C:P/I:N/A:N</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 user can tell curl &gt;= 7.20.0 and &lt;= 7.78.0 to require a successful upgrade to TLS when speaking to an IMAP, POP3 or FTP server (`--ssl-reqd` on the command line or`CURLOPT_USE_SSL` set to `CURLUSESSL_CONTROL` or `CURLUSESSL_ALL` withlibcurl). This requirement could be bypassed if the server would return a properly crafted but perfectly legitimate response.This flaw would then make curl silently continue its operations **withoutTLS** contrary to the instructions and expectations, exposing possibly sensitive data in clear text over the network.</Note>
    </Notes>
    <CVE>CVE-2021-22946</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>5</BaseScore>
        <Vector>AV:N/AC:L/Au:N/C:P/I:N/A:N</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">When curl &gt;= 7.20.0 and &lt;= 7.78.0 connects to an IMAP or POP3 server to retrieve data using STARTTLS to upgrade to TLS security, the server can respond and send back multiple responses at once that curl caches. curl would then upgrade to TLS but not flush the in-queue of cached responses but instead continue using and trustingthe responses it got *before* the TLS handshake as if they were authenticated.Using this flaw, it allows a Man-In-The-Middle attacker to first inject the fake responses, then pass-through the TLS traffic from the legitimate server and trick curl into sending data back to the user thinking the attacker's injected data comes from the TLS-protected server.</Note>
    </Notes>
    <CVE>CVE-2021-22947</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>4.3</BaseScore>
        <Vector>AV:N/AC:M/Au:N/C:N/I:P/A:N</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 use-after-free flaw was found in the Linux kernel's Atheros wireless adapter driver in the way a user forces the ath9k_htc_wait_for_target function to fail with some input messages. This flaw allows a local user to crash or potentially escalate their privileges on the system.</Note>
    </Notes>
    <CVE>CVE-2022-1679</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">An improper authentication vulnerability exists in curl 7.33.0 to and including 7.82.0 which might allow reuse OAUTH2-authenticated connections without properly making sure that the connection was authenticated with the same credentials as set for this transfer. This affects SASL-enabled protocols: SMPTP(S), IMAP(S), POP3(S) and LDAP(S) (openldap only).</Note>
    </Notes>
    <CVE>CVE-2022-22576</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>5.5</BaseScore>
        <Vector>AV:N/AC:L/Au:S/C:P/I:P/A:N</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">It was discovered that a nft object or expression could reference a nft set on a different nft table, leading to a use-after-free once that table was deleted.</Note>
    </Notes>
    <CVE>CVE-2022-2586</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 information disclosure vulnerability exists in curl 7.65.0 to 7.82.0 are vulnerable that by using an IPv6 address that was in the connection pool but with a different zone id it could reuse a connection instead.</Note>
    </Notes>
    <CVE>CVE-2022-27775</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>5</BaseScore>
        <Vector>AV:N/AC:L/Au:N/C:P/I:N/A:N</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 insufficiently protected credentials vulnerability in fixed in curl 7.83.0 might leak authentication or cookie header data on HTTP redirects to the same host but another port number.</Note>
    </Notes>
    <CVE>CVE-2022-27776</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>4.3</BaseScore>
        <Vector>AV:N/AC:M/Au:N/C:P/I:N/A:N</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">libcurl provides the `CURLOPT_CERTINFO` option to allow applications torequest details to be returned about a server's certificate chain.Due to an erroneous function, a malicious server could make libcurl built withNSS get stuck in a never-ending busy-loop when trying to retrieve thatinformation.</Note>
    </Notes>
    <CVE>CVE-2022-27781</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>5</BaseScore>
        <Vector>AV:N/AC:L/Au:N/C:N/I:N/A:P</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">libcurl would reuse a previously created connection even when a TLS or SSHrelated option had been changed that should have prohibited reuse.libcurl keeps previously used connections in a connection pool for subsequenttransfers to reuse if one of them matches the setup. However, several TLS andSSH settings were left out from the configuration match checks, making themmatch too easily.</Note>
    </Notes>
    <CVE>CVE-2022-27782</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>5</BaseScore>
        <Vector>AV:N/AC:L/Au:N/C:N/I:P/A:N</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">An issue in the Unmarshal function in Go-Yaml v3 causes the program to crash when attempting to deserialize invalid input.</Note>
    </Notes>
    <CVE>CVE-2022-28948</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>5</BaseScore>
        <Vector>AV:N/AC:L/Au:N/C:N/I:N/A:P</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">An out-of-bounds memory read flaw was found in the Linux kernel's BPF subsystem in how a user calls the bpf_tail_call function with a key larger than the max_entries of the map. This flaw allows a local user to gain unauthorized access to data.</Note>
    </Notes>
    <CVE>CVE-2022-2905</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">curl &lt; 7.84.0 supports "chained" HTTP compression algorithms, meaning that a serverresponse can be compressed multiple times and potentially with different algorithms. The number of acceptable "links" in this "decompression chain" was unbounded, allowing a malicious server to insert a virtually unlimited number of compression steps.The use of such a decompression chain could result in a "malloc bomb", makingcurl end up spending enormous amounts of allocated heap memory, or trying toand returning out of memory errors.</Note>
    </Notes>
    <CVE>CVE-2022-32206</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>4.3</BaseScore>
        <Vector>AV:N/AC:M/Au:N/C:N/I:N/A:P</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">When curl &lt; 7.84.0 does FTP transfers secured by krb5, it handles message verification failures wrongly. This flaw makes it possible for a Man-In-The-Middle attack to go unnoticed and even allows it to inject data to the client.</Note>
    </Notes>
    <CVE>CVE-2022-32208</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>4.3</BaseScore>
        <Vector>AV:N/AC:M/Au:N/C:P/I:N/A:N</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">When doing HTTP(S) transfers, libcurl might erroneously use the read callback (`CURLOPT_READFUNCTION`) to ask for data to send, even when the `CURLOPT_POSTFIELDS` option has been set, if the same handle previously was used to issue a `PUT` request which used that callback. This flaw may surprise the application and cause it to misbehave and either send off the wrong data or use memory after free or similar in the subsequent `POST` request. The problem exists in the logic for a reused handle when it is changed from a PUT to a POST.</Note>
    </Notes>
    <CVE>CVE-2022-32221</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">When curl is used to retrieve and parse cookies from a HTTP(S) server, itaccepts cookies using control codes that when later are sent back to a HTTPserver might make the server return 400 responses. Effectively allowing a"sister site" to deny service to all siblings.</Note>
    </Notes>
    <CVE>CVE-2022-35252</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 incorrect read request flaw was found in the Infrared Transceiver USB driver in the Linux kernel. This issue occurs when a user attaches a malicious USB device. A local user could use this flaw to starve the resources, causing denial of service or potentially crashing the system.</Note>
    </Notes>
    <CVE>CVE-2022-3903</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 was found in Linux kernel before 5.19.2. This issue occurs in cmd_hdl_filter in drivers/staging/rtl8712/rtl8712_cmd.c, allowing an attacker to launch a local denial of service attack and gain escalation of privileges.</Note>
    </Notes>
    <CVE>CVE-2022-4095</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 use after free vulnerability exists in curl &lt;7.87.0. Curl can be asked to *tunnel* virtually all protocols it supports through an HTTP proxy. HTTP proxies can (and often do) deny such tunnel operations. When getting denied to tunnel the specific protocols SMB or TELNET, curl would use a heap-allocated struct after it had been freed, in its transfer shutdown code path.</Note>
    </Notes>
    <CVE>CVE-2022-43552</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 incorrect access control in the Linux kernel USB core subsystem was found in the way user attaches usb device. A local user could use this flaw to crash the system.</Note>
    </Notes>
    <CVE>CVE-2022-4662</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_event: Ignore multiple conn complete events

When one of the three connection complete events is received multiple
times for the same handle, the device is registered multiple times which
leads to memory corruptions. Therefore, consequent events for a single
connection are ignored.

The conn-&gt;state can hold different values, therefore HCI_CONN_HANDLE_UNSET
is introduced to identify new connections. To make sure the events do not
contain this or another invalid handle HCI_CONN_HANDLE_MAX and checks
are introduced.

Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=215497</Note>
    </Notes>
    <CVE>CVE-2022-49138</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix UAF in ieee80211_scan_rx()

ieee80211_scan_rx() tries to access scan_req-&gt;flags after a
null check, but a UAF is observed when the scan is completed
and __ieee80211_scan_completed() executes, which then calls
cfg80211_scan_done() leading to the freeing of scan_req.

Since scan_req is rcu_dereference()'d, prevent the racing in
__ieee80211_scan_completed() by ensuring that from mac80211's
POV it is no longer accessed from an RCU read critical section
before we call cfg80211_scan_done().</Note>
    </Notes>
    <CVE>CVE-2022-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:

wifi: mac80211: Don't finalize CSA in IBSS mode if state is disconnected

When we are not connected to a channel, sending channel "switch"
announcement doesn't make any sense.

The BSS list is empty in that case. This causes the for loop in
cfg80211_get_bss() to be bypassed, so the function returns NULL
(check line 1424 of net/wireless/scan.c), causing the WARN_ON()
in ieee80211_ibss_csa_beacon() to get triggered (check line 500
of net/mac80211/ibss.c), which was consequently reported on the
syzkaller dashboard.

Thus, check if we have an existing connection before generating
the CSA beacon in ieee80211_ibss_finish_csa().</Note>
    </Notes>
    <CVE>CVE-2022-49942</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: (gpio-fan) Fix array out of bounds access

The driver does not check if the cooling state passed to
gpio_fan_set_cur_state() exceeds the maximum cooling state as
stored in fan_data-&gt;num_speeds. Since the cooling state is later
used as an array index in set_fan_speed(), an array out of bounds
access can occur.
This can be exploited by setting the state of the thermal cooling device
to arbitrary values, causing for example a kernel oops when unavailable
memory is accessed this way.

Example kernel oops:
[  807.987276] Unable to handle kernel paging request at virtual address ffffff80d0588064
[  807.987369] Mem abort info:
[  807.987398]   ESR = 0x96000005
[  807.987428]   EC = 0x25: DABT (current EL), IL = 32 bits
[  807.987477]   SET = 0, FnV = 0
[  807.987507]   EA = 0, S1PTW = 0
[  807.987536]   FSC = 0x05: level 1 translation fault
[  807.987570] Data abort info:
[  807.987763]   ISV = 0, ISS = 0x00000005
[  807.987801]   CM = 0, WnR = 0
[  807.987832] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000001165000
[  807.987872] [ffffff80d0588064] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
[  807.987961] Internal error: Oops: 96000005 [#1] PREEMPT SMP
[  807.987992] Modules linked in: cmac algif_hash aes_arm64 algif_skcipher af_alg bnep hci_uart btbcm bluetooth ecdh_generic ecc 8021q garp stp llc snd_soc_hdmi_codec brcmfmac vc4 brcmutil cec drm_kms_helper snd_soc_core cfg80211 snd_compress bcm2835_codec(C) snd_pcm_dmaengine syscopyarea bcm2835_isp(C) bcm2835_v4l2(C) sysfillrect v4l2_mem2mem bcm2835_mmal_vchiq(C) raspberrypi_hwmon sysimgblt videobuf2_dma_contig videobuf2_vmalloc fb_sys_fops videobuf2_memops rfkill videobuf2_v4l2 videobuf2_common i2c_bcm2835 snd_bcm2835(C) videodev snd_pcm snd_timer snd mc vc_sm_cma(C) gpio_fan uio_pdrv_genirq uio drm fuse drm_panel_orientation_quirks backlight ip_tables x_tables ipv6
[  807.988508] CPU: 0 PID: 1321 Comm: bash Tainted: G         C        5.15.56-v8+ #1575
[  807.988548] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
[  807.988574] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  807.988608] pc : set_fan_speed.part.5+0x34/0x80 [gpio_fan]
[  807.988654] lr : gpio_fan_set_cur_state+0x34/0x50 [gpio_fan]
[  807.988691] sp : ffffffc008cf3bd0
[  807.988710] x29: ffffffc008cf3bd0 x28: ffffff80019edac0 x27: 0000000000000000
[  807.988762] x26: 0000000000000000 x25: 0000000000000000 x24: ffffff800747c920
[  807.988787] x23: 000000000000000a x22: ffffff800369f000 x21: 000000001999997c
[  807.988854] x20: ffffff800369f2e8 x19: ffffff8002ae8080 x18: 0000000000000000
[  807.988877] x17: 0000000000000000 x16: 0000000000000000 x15: 000000559e271b70
[  807.988938] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
[  807.988960] x11: 0000000000000000 x10: ffffffc008cf3c20 x9 : ffffffcfb60c741c
[  807.989018] x8 : 000000000000000a x7 : 00000000ffffffc9 x6 : 0000000000000009
[  807.989040] x5 : 000000000000002a x4 : 0000000000000000 x3 : ffffff800369f2e8
[  807.989062] x2 : 000000000000e780 x1 : 0000000000000001 x0 : ffffff80d0588060
[  807.989084] Call trace:
[  807.989091]  set_fan_speed.part.5+0x34/0x80 [gpio_fan]
[  807.989113]  gpio_fan_set_cur_state+0x34/0x50 [gpio_fan]
[  807.989199]  cur_state_store+0x84/0xd0
[  807.989221]  dev_attr_store+0x20/0x38
[  807.989262]  sysfs_kf_write+0x4c/0x60
[  807.989282]  kernfs_fop_write_iter+0x130/0x1c0
[  807.989298]  new_sync_write+0x10c/0x190
[  807.989315]  vfs_write+0x254/0x378
[  807.989362]  ksys_write+0x70/0xf8
[  807.989379]  __arm64_sys_write+0x24/0x30
[  807.989424]  invoke_syscall+0x4c/0x110
[  807.989442]  el0_svc_common.constprop.3+0xfc/0x120
[  807.989458]  do_el0_svc+0x2c/0x90
[  807.989473]  el0_svc+0x24/0x60
[  807.989544]  el0t_64_sync_handler+0x90/0xb8
[  807.989558]  el0t_64_sync+0x1a0/0x1a4
[  807.989579] Code: b9403801 f9402800 7100003f 8b35cc00 (b9400416)
[  807.989627] ---[ end t
---truncated---</Note>
    </Notes>
    <CVE>CVE-2022-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:

vt: Clear selection before changing the font

When changing the console font with ioctl(KDFONTOP) the new font size
can be bigger than the previous font. A previous selection may thus now
be outside of the new screen size and thus trigger out-of-bounds
accesses to graphics memory if the selection is removed in
vc_do_resize().

Prevent such out-of-memory accesses by dropping the selection before the
various con_font_set() console handlers are called.</Note>
    </Notes>
    <CVE>CVE-2022-49948</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 memory corruption on open

The probe session-duplication overflow check incremented the session
count also when there were no more available sessions so that memory
beyond the fixed-size slab-allocated session array could be corrupted in
fastrpc_session_alloc() on open().</Note>
    </Notes>
    <CVE>CVE-2022-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:

misc: fastrpc: fix memory corruption on probe

Add the missing sanity check on the probed-session count to avoid
corrupting memory beyond the fixed-size slab-allocated session array
when there are more than FASTRPC_MAX_SESSIONS sessions defined in the
devicetree.</Note>
    </Notes>
    <CVE>CVE-2022-49952</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: iforce - wake up after clearing IFORCE_XMIT_RUNNING flag

syzbot is reporting hung task at __input_unregister_device() [1], for
iforce_close() waiting at wait_event_interruptible() with dev-&gt;mutex held
is blocking input_disconnect_device() from __input_unregister_device().

It seems that the cause is simply that commit c2b27ef672992a20 ("Input:
iforce - wait for command completion when closing the device") forgot to
call wake_up() after clear_bit().

Fix this problem by introducing a helper that calls clear_bit() followed
by wake_up_all().</Note>
    </Notes>
    <CVE>CVE-2022-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:

ieee802154/adf7242: defer destroy_workqueue call

There is a possible race condition (use-after-free) like below

  (FREE)                     |  (USE)
  adf7242_remove             |  adf7242_channel
   cancel_delayed_work_sync  |
    destroy_workqueue (1)    |   adf7242_cmd_rx
                             |    mod_delayed_work (2)
                             |

The root cause for this race is that the upper layer (ieee802154) is
unaware of this detaching event and the function adf7242_channel can
be called without any checks.

To fix this, we can add a flag write at the beginning of adf7242_remove
and add flag check in adf7242_channel. Or we can just defer the
destructive operation like other commit 3e0588c291d6 ("hamradio: defer
ax25 kfree after unregister_netdev") which let the
ieee802154_unregister_hw() to handle the synchronization. This patch
takes the second option.

runs")</Note>
    </Notes>
    <CVE>CVE-2022-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:

ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead

ftrace_startup does not remove ops from ftrace_ops_list when
ftrace_startup_enable fails:

register_ftrace_function
  ftrace_startup
    __register_ftrace_function
      ...
      add_ftrace_ops(&amp;ftrace_ops_list, ops)
      ...
    ...
    ftrace_startup_enable // if ftrace failed to modify, ftrace_disabled is set to 1
    ...
  return 0 // ops is in the ftrace_ops_list.

When ftrace_disabled = 1, unregister_ftrace_function simply returns without doing anything:
unregister_ftrace_function
  ftrace_shutdown
    if (unlikely(ftrace_disabled))
            return -ENODEV;  // return here, __unregister_ftrace_function is not executed,
                             // as a result, ops is still in the ftrace_ops_list
    __unregister_ftrace_function
    ...

If ops is dynamically allocated, it will be free later, in this case,
is_ftrace_trampoline accesses NULL pointer:

is_ftrace_trampoline
  ftrace_ops_trampoline
    do_for_each_ftrace_op(op, ftrace_ops_list) // OOPS! op may be NULL!

Syzkaller reports as follows:
[ 1203.506103] BUG: kernel NULL pointer dereference, address: 000000000000010b
[ 1203.508039] #PF: supervisor read access in kernel mode
[ 1203.508798] #PF: error_code(0x0000) - not-present page
[ 1203.509558] PGD 800000011660b067 P4D 800000011660b067 PUD 130fb8067 PMD 0
[ 1203.510560] Oops: 0000 [#1] SMP KASAN PTI
[ 1203.511189] CPU: 6 PID: 29532 Comm: syz-executor.2 Tainted: G    B   W         5.10.0 #8
[ 1203.512324] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 1203.513895] RIP: 0010:is_ftrace_trampoline+0x26/0xb0
[ 1203.514644] Code: ff eb d3 90 41 55 41 54 49 89 fc 55 53 e8 f2 00 fd ff 48 8b 1d 3b 35 5d 03 e8 e6 00 fd ff 48 8d bb 90 00 00 00 e8 2a 81 26 00 &lt;48&gt; 8b ab 90 00 00 00 48 85 ed 74 1d e8 c9 00 fd ff 48 8d bb 98 00
[ 1203.518838] RSP: 0018:ffffc900012cf960 EFLAGS: 00010246
[ 1203.520092] RAX: 0000000000000000 RBX: 000000000000007b RCX: ffffffff8a331866
[ 1203.521469] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 000000000000010b
[ 1203.522583] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff8df18b07
[ 1203.523550] R10: fffffbfff1be3160 R11: 0000000000000001 R12: 0000000000478399
[ 1203.524596] R13: 0000000000000000 R14: ffff888145088000 R15: 0000000000000008
[ 1203.525634] FS:  00007f429f5f4700(0000) GS:ffff8881daf00000(0000) knlGS:0000000000000000
[ 1203.526801] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1203.527626] CR2: 000000000000010b CR3: 0000000170e1e001 CR4: 00000000003706e0
[ 1203.528611] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1203.529605] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

Therefore, when ftrace_startup_enable fails, we need to rollback registration
process and remove ops from ftrace_ops_list.</Note>
    </Notes>
    <CVE>CVE-2022-49977</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fb_pm2fb: Avoid potential divide by zero error

In `do_fb_ioctl()` of fbmem.c, if cmd is FBIOPUT_VSCREENINFO, var will be
copied from user, then go through `fb_set_var()` and
`info-&gt;fbops-&gt;fb_check_var()` which could may be `pm2fb_check_var()`.
Along the path, `var-&gt;pixclock` won't be modified. This function checks
whether reciprocal of `var-&gt;pixclock` is too high. If `var-&gt;pixclock` is
zero, there will be a divide by zero error. So, it is necessary to check
whether denominator is zero to avoid crash. As this bug is found by
Syzkaller, logs are listed below.

divide error in pm2fb_check_var
Call Trace:
 &lt;TASK&gt;
 fb_set_var+0x367/0xeb0 drivers/video/fbdev/core/fbmem.c:1015
 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110
 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189</Note>
    </Notes>
    <CVE>CVE-2022-49978</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: hidraw: fix memory leak in hidraw_release()

Free the buffered reports before deleting the list entry.

BUG: memory leak
unreferenced object 0xffff88810e72f180 (size 32):
  comm "softirq", pid 0, jiffies 4294945143 (age 16.080s)
  hex dump (first 32 bytes):
    64 f3 c6 6a d1 88 07 04 00 00 00 00 00 00 00 00  d..j............
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;ffffffff814ac6c3&gt;] kmemdup+0x23/0x50 mm/util.c:128
    [&lt;ffffffff8357c1d2&gt;] kmemdup include/linux/fortify-string.h:440 [inline]
    [&lt;ffffffff8357c1d2&gt;] hidraw_report_event+0xa2/0x150 drivers/hid/hidraw.c:521
    [&lt;ffffffff8356ddad&gt;] hid_report_raw_event+0x27d/0x740 drivers/hid/hid-core.c:1992
    [&lt;ffffffff8356e41e&gt;] hid_input_report+0x1ae/0x270 drivers/hid/hid-core.c:2065
    [&lt;ffffffff835f0d3f&gt;] hid_irq_in+0x1ff/0x250 drivers/hid/usbhid/hid-core.c:284
    [&lt;ffffffff82d3c7f9&gt;] __usb_hcd_giveback_urb+0xf9/0x230 drivers/usb/core/hcd.c:1670
    [&lt;ffffffff82d3cc26&gt;] usb_hcd_giveback_urb+0x1b6/0x1d0 drivers/usb/core/hcd.c:1747
    [&lt;ffffffff82ef1e14&gt;] dummy_timer+0x8e4/0x14c0 drivers/usb/gadget/udc/dummy_hcd.c:1988
    [&lt;ffffffff812f50a8&gt;] call_timer_fn+0x38/0x200 kernel/time/timer.c:1474
    [&lt;ffffffff812f5586&gt;] expire_timers kernel/time/timer.c:1519 [inline]
    [&lt;ffffffff812f5586&gt;] __run_timers.part.0+0x316/0x430 kernel/time/timer.c:1790
    [&lt;ffffffff812f56e4&gt;] __run_timers kernel/time/timer.c:1768 [inline]
    [&lt;ffffffff812f56e4&gt;] run_timer_softirq+0x44/0x90 kernel/time/timer.c:1803
    [&lt;ffffffff848000e6&gt;] __do_softirq+0xe6/0x2ea kernel/softirq.c:571
    [&lt;ffffffff81246db0&gt;] invoke_softirq kernel/softirq.c:445 [inline]
    [&lt;ffffffff81246db0&gt;] __irq_exit_rcu kernel/softirq.c:650 [inline]
    [&lt;ffffffff81246db0&gt;] irq_exit_rcu+0xc0/0x110 kernel/softirq.c:662
    [&lt;ffffffff84574f02&gt;] sysvec_apic_timer_interrupt+0xa2/0xd0 arch/x86/kernel/apic/apic.c:1106
    [&lt;ffffffff84600c8b&gt;] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:649
    [&lt;ffffffff8458a070&gt;] native_safe_halt arch/x86/include/asm/irqflags.h:51 [inline]
    [&lt;ffffffff8458a070&gt;] arch_safe_halt arch/x86/include/asm/irqflags.h:89 [inline]
    [&lt;ffffffff8458a070&gt;] acpi_safe_halt drivers/acpi/processor_idle.c:111 [inline]
    [&lt;ffffffff8458a070&gt;] acpi_idle_do_entry+0xc0/0xd0 drivers/acpi/processor_idle.c:554</Note>
    </Notes>
    <CVE>CVE-2022-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:

HID: steam: Prevent NULL pointer dereference in steam_{recv,send}_report

It is possible for a malicious device to forgo submitting a Feature
Report.  The HID Steam driver presently makes no prevision for this
and de-references the 'struct hid_report' pointer obtained from the
HID devices without first checking its validity.  Let's change that.</Note>
    </Notes>
    <CVE>CVE-2022-49984</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Remove WQ_MEM_RECLAIM from storvsc_error_wq

storvsc_error_wq workqueue should not be marked as WQ_MEM_RECLAIM as it
doesn't need to make forward progress under memory pressure.  Marking this
workqueue as WQ_MEM_RECLAIM may cause deadlock while flushing a
non-WQ_MEM_RECLAIM workqueue.  In the current state it causes the following
warning:

[   14.506347] ------------[ cut here ]------------
[   14.506354] workqueue: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun is flushing !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn
[   14.506360] WARNING: CPU: 0 PID: 8 at &lt;-snip-&gt;kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130
[   14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 Not tainted 5.4.0-1086-azure #91~18.04.1-Ubuntu
[   14.506391] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022
[   14.506393] Workqueue: storvsc_error_wq_0 storvsc_remove_lun
[   14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130
		&lt;-snip-&gt;
[   14.506408] Call Trace:
[   14.506412]  __flush_work+0xf1/0x1c0
[   14.506414]  __cancel_work_timer+0x12f/0x1b0
[   14.506417]  ? kernfs_put+0xf0/0x190
[   14.506418]  cancel_delayed_work_sync+0x13/0x20
[   14.506420]  disk_block_events+0x78/0x80
[   14.506421]  del_gendisk+0x3d/0x2f0
[   14.506423]  sr_remove+0x28/0x70
[   14.506427]  device_release_driver_internal+0xef/0x1c0
[   14.506428]  device_release_driver+0x12/0x20
[   14.506429]  bus_remove_device+0xe1/0x150
[   14.506431]  device_del+0x167/0x380
[   14.506432]  __scsi_remove_device+0x11d/0x150
[   14.506433]  scsi_remove_device+0x26/0x40
[   14.506434]  storvsc_remove_lun+0x40/0x60
[   14.506436]  process_one_work+0x209/0x400
[   14.506437]  worker_thread+0x34/0x400
[   14.506439]  kthread+0x121/0x140
[   14.506440]  ? process_one_work+0x400/0x400
[   14.506441]  ? kthread_park+0x90/0x90
[   14.506443]  ret_from_fork+0x35/0x40
[   14.506445] ---[ end trace 2d9633159fdc6ee7 ]---</Note>
    </Notes>
    <CVE>CVE-2022-49986</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: call __md_stop_writes in md_stop

From the link [1], we can see raid1d was running even after the path
raid_dtr -&gt; md_stop -&gt; __md_stop.

Let's stop write first in destructor to align with normal md-raid to
fix the KASAN issue.

[1]. https://lore.kernel.org/linux-raid/CAPhsuW5gc4AakdGNdF8ubpezAuDLFOYUO_sfMZcec6hQFm8nhg@mail.gmail.com/T/#m7f12bf90481c02c6d2da68c64aeed4779b7df74a</Note>
    </Notes>
    <CVE>CVE-2022-49987</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/privcmd: fix error exit of privcmd_ioctl_dm_op()

The error exit of privcmd_ioctl_dm_op() is calling unlock_pages()
potentially with pages being NULL, leading to a NULL dereference.

Additionally lock_pages() doesn't check for pin_user_pages_fast()
having been completely successful, resulting in potentially not
locking all pages into memory. This could result in sporadic failures
when using the related memory in user mode.

Fix all of that by calling unlock_pages() always with the real number
of pinned pages, which will be zero in case pages being NULL, and by
checking the number of pages pinned by pin_user_pages_fast() matching
the expected number of pages.</Note>
    </Notes>
    <CVE>CVE-2022-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:

s390: fix double free of GS and RI CBs on fork() failure

The pointers for guarded storage and runtime instrumentation control
blocks are stored in the thread_struct of the associated task. These
pointers are initially copied on fork() via arch_dup_task_struct()
and then cleared via copy_thread() before fork() returns. If fork()
happens to fail after the initial task dup and before copy_thread(),
the newly allocated task and associated thread_struct memory are
freed via free_task() -&gt; arch_release_task_struct(). This results in
a double free of the guarded storage and runtime info structs
because the fields in the failed task still refer to memory
associated with the source task.

This problem can manifest as a BUG_ON() in set_freepointer() (with
CONFIG_SLAB_FREELIST_HARDENED enabled) or KASAN splat (if enabled)
when running trinity syscall fuzz tests on s390x. To avoid this
problem, clear the associated pointer fields in
arch_dup_task_struct() immediately after the new task is copied.
Note that the RI flag is still cleared in copy_thread() because it
resides in thread stack memory and that is where stack info is
copied.</Note>
    </Notes>
    <CVE>CVE-2022-49990</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

loop: Check for overflow while configuring loop

The userspace can configure a loop using an ioctl call, wherein
a configuration of type loop_config is passed (see lo_ioctl()'s
case on line 1550 of drivers/block/loop.c). This proceeds to call
loop_configure() which in turn calls loop_set_status_from_info()
(see line 1050 of loop.c), passing &amp;config-&gt;info which is of type
loop_info64*. This function then sets the appropriate values, like
the offset.

loop_device has lo_offset of type loff_t (see line 52 of loop.c),
which is typdef-chained to long long, whereas loop_info64 has
lo_offset of type __u64 (see line 56 of include/uapi/linux/loop.h).

The function directly copies offset from info to the device as
follows (See line 980 of loop.c):
	lo-&gt;lo_offset = info-&gt;lo_offset;

This results in an overflow, which triggers a warning in iomap_iter()
due to a call to iomap_iter_done() which has:
	WARN_ON_ONCE(iter-&gt;iomap.offset &gt; iter-&gt;pos);

Thus, check for negative value during loop_set_status_from_info().

Bug report: https://syzkaller.appspot.com/bug?id=c620fe14aac810396d3c3edc9ad73848bf69a29e</Note>
    </Notes>
    <CVE>CVE-2022-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">In the Linux kernel, the following vulnerability has been resolved:

video: fbdev: i740fb: Check the argument of i740_calc_vclk()

Since the user can control the arguments of the ioctl() from the user
space, under special arguments that may result in a divide-by-zero bug.

If the user provides an improper 'pixclock' value that makes the argumet
of i740_calc_vclk() less than 'I740_RFREQ_FIX', it will cause a
divide-by-zero bug in:
    drivers/video/fbdev/i740fb.c:353 p_best = min(15, ilog2(I740_MAX_VCO_FREQ / (freq / I740_RFREQ_FIX)));

The following log can reveal it:

divide error: 0000 [#1] PREEMPT SMP KASAN PTI
RIP: 0010:i740_calc_vclk drivers/video/fbdev/i740fb.c:353 [inline]
RIP: 0010:i740fb_decode_var drivers/video/fbdev/i740fb.c:646 [inline]
RIP: 0010:i740fb_set_par+0x163f/0x3b70 drivers/video/fbdev/i740fb.c:742
Call Trace:
 fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1034
 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110
 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189

Fix this by checking the argument of i740_calc_vclk() first.</Note>
    </Notes>
    <CVE>CVE-2022-50010</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/64: Init jump labels before parse_early_param()

On 64-bit, calling jump_label_init() in setup_feature_keys() is too
late because static keys may be used in subroutines of
parse_early_param() which is again subroutine of early_init_devtree().

For example booting with "threadirqs":

  static_key_enable_cpuslocked(): static key '0xc000000002953260' used before call to jump_label_init()
  WARNING: CPU: 0 PID: 0 at kernel/jump_label.c:166 static_key_enable_cpuslocked+0xfc/0x120
  ...
  NIP static_key_enable_cpuslocked+0xfc/0x120
  LR  static_key_enable_cpuslocked+0xf8/0x120
  Call Trace:
    static_key_enable_cpuslocked+0xf8/0x120 (unreliable)
    static_key_enable+0x30/0x50
    setup_forced_irqthreads+0x28/0x40
    do_early_param+0xa0/0x108
    parse_args+0x290/0x4e0
    parse_early_options+0x48/0x5c
    parse_early_param+0x58/0x84
    early_init_devtree+0xd4/0x518
    early_setup+0xb4/0x214

So call jump_label_init() just before parse_early_param() in
early_init_devtree().

[mpe: Add call trace to change log and minor wording edits.]</Note>
    </Notes>
    <CVE>CVE-2022-50012</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix refcount leak bug in ucc_uart.c

In soc_info(), of_find_node_by_type() will return a node pointer
with refcount incremented. We should use of_node_put() when it is
not used anymore.</Note>
    </Notes>
    <CVE>CVE-2022-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:

ext4: avoid resizing to a partial cluster size

This patch avoids an attempt to resize the filesystem to an
unaligned cluster boundary.  An online resize to a size that is not
integral to cluster size results in the last iteration attempting to
grow the fs by a negative amount, which trips a BUG_ON and leaves the fs
with a corrupted in-memory superblock.</Note>
    </Notes>
    <CVE>CVE-2022-50020</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:md:fix a potential use-after-free bug

In line 2884, "raid5_release_stripe(sh);" drops the reference to sh and
may cause sh to be released. However, sh is subsequently used in lines
2886 "if (sh-&gt;batch_head &amp;&amp; sh != sh-&gt;batch_head)". This may result in an
use-after-free bug.

It can be fixed by moving "raid5_release_stripe(sh);" to the bottom of
the function.</Note>
    </Notes>
    <CVE>CVE-2022-50022</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 possible memory leak when failing to issue CMF WQE

There is no corresponding free routine if lpfc_sli4_issue_wqe fails to
issue the CMF WQE in lpfc_issue_cmf_sync_wqe.

If ret_val is non-zero, then free the iocbq request structure.</Note>
    </Notes>
    <CVE>CVE-2022-50027</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gadgetfs: ep_io - wait until IRQ finishes

after usb_ep_queue() if wait_for_completion_interruptible() is
interrupted we need to wait until IRQ gets finished.

Otherwise complete() from epio_complete() can corrupt stack.</Note>
    </Notes>
    <CVE>CVE-2022-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:

clk: qcom: ipq8074: dont disable gcc_sleep_clk_src

Once the usb sleep clocks are disabled, clock framework is trying to
disable the sleep clock source also.

However, it seems that it cannot be disabled and trying to do so produces:
[  245.436390] ------------[ cut here ]------------
[  245.441233] gcc_sleep_clk_src status stuck at 'on'
[  245.441254] WARNING: CPU: 2 PID: 223 at clk_branch_wait+0x130/0x140
[  245.450435] Modules linked in: xhci_plat_hcd xhci_hcd dwc3 dwc3_qcom leds_gpio
[  245.456601] CPU: 2 PID: 223 Comm: sh Not tainted 5.18.0-rc4 #215
[  245.463889] Hardware name: Xiaomi AX9000 (DT)
[  245.470050] pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  245.474307] pc : clk_branch_wait+0x130/0x140
[  245.481073] lr : clk_branch_wait+0x130/0x140
[  245.485588] sp : ffffffc009f2bad0
[  245.489838] x29: ffffffc009f2bad0 x28: ffffff8003e6c800 x27: 0000000000000000
[  245.493057] x26: 0000000000000000 x25: 0000000000000000 x24: ffffff800226ef20
[  245.500175] x23: ffffffc0089ff550 x22: 0000000000000000 x21: ffffffc008476ad0
[  245.507294] x20: 0000000000000000 x19: ffffffc00965ac70 x18: fffffffffffc51a7
[  245.514413] x17: 68702e3030303837 x16: 3a6d726f6674616c x15: ffffffc089f2b777
[  245.521531] x14: ffffffc0095c9d18 x13: 0000000000000129 x12: 0000000000000129
[  245.528649] x11: 00000000ffffffea x10: ffffffc009621d18 x9 : 0000000000000001
[  245.535767] x8 : 0000000000000001 x7 : 0000000000017fe8 x6 : 0000000000000001
[  245.542885] x5 : ffffff803fdca6d8 x4 : 0000000000000000 x3 : 0000000000000027
[  245.550002] x2 : 0000000000000027 x1 : 0000000000000023 x0 : 0000000000000026
[  245.557122] Call trace:
[  245.564229]  clk_branch_wait+0x130/0x140
[  245.566490]  clk_branch2_disable+0x2c/0x40
[  245.570656]  clk_core_disable+0x60/0xb0
[  245.574561]  clk_core_disable+0x68/0xb0
[  245.578293]  clk_disable+0x30/0x50
[  245.582113]  dwc3_qcom_remove+0x60/0xc0 [dwc3_qcom]
[  245.585588]  platform_remove+0x28/0x60
[  245.590361]  device_remove+0x4c/0x80
[  245.594179]  device_release_driver_internal+0x1dc/0x230
[  245.597914]  device_driver_detach+0x18/0x30
[  245.602861]  unbind_store+0xec/0x110
[  245.607027]  drv_attr_store+0x24/0x40
[  245.610847]  sysfs_kf_write+0x44/0x60
[  245.614405]  kernfs_fop_write_iter+0x128/0x1c0
[  245.618052]  new_sync_write+0xc0/0x130
[  245.622391]  vfs_write+0x1d4/0x2a0
[  245.626123]  ksys_write+0x58/0xe0
[  245.629508]  __arm64_sys_write+0x1c/0x30
[  245.632895]  invoke_syscall.constprop.0+0x5c/0x110
[  245.636890]  do_el0_svc+0xa0/0x150
[  245.641488]  el0_svc+0x18/0x60
[  245.644872]  el0t_64_sync_handler+0xa4/0x130
[  245.647914]  el0t_64_sync+0x174/0x178
[  245.652340] ---[ end trace 0000000000000000 ]---

So, add CLK_IS_CRITICAL flag to the clock so that the kernel won't try
to disable the sleep clock.</Note>
    </Notes>
    <CVE>CVE-2022-50029</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Prevent buffer overflow crashes in debugfs with malformed user input

Malformed user input to debugfs results in buffer overflow crashes.  Adapt
input string lengths to fit within internal buffers, leaving space for NULL
terminators.</Note>
    </Notes>
    <CVE>CVE-2022-50030</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: renesas: Fix refcount leak bug

In usbhs_rza1_hardware_init(), of_find_node_by_name() will return
a node pointer with refcount incremented. We should use of_node_put()
when it is not used anymore.</Note>
    </Notes>
    <CVE>CVE-2022-50032</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: host: ohci-ppc-of: Fix refcount leak bug

In ohci_hcd_ppc_of_probe(), of_find_compatible_node() will return
a node pointer with refcount incremented. We should use of_node_put()
when it is not used anymore.</Note>
    </Notes>
    <CVE>CVE-2022-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:

drm/sun4i: dsi: Prevent underflow when computing packet sizes

Currently, the packet overhead is subtracted using unsigned arithmetic.
With a short sync pulse, this could underflow and wrap around to near
the maximal u16 value. Fix this by using signed subtraction. The call to
max() will correctly handle any negative numbers that are produced.

Apply the same fix to the other timings, even though those subtractions
are less likely to underflow.</Note>
    </Notes>
    <CVE>CVE-2022-50036</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/meson: Fix refcount bugs in meson_vpu_has_available_connectors()

In this function, there are two refcount leak bugs:
(1) when breaking out of for_each_endpoint_of_node(), we need call
the of_node_put() for the 'ep';
(2) we should call of_node_put() for the reference returned by
of_graph_get_remote_port() when it is not used anymore.</Note>
    </Notes>
    <CVE>CVE-2022-50038</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/pci: Fix get_phb_number() locking

The recent change to get_phb_number() causes a DEBUG_ATOMIC_SLEEP
warning on some systems:

  BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580
  in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper
  preempt_count: 1, expected: 0
  RCU nest depth: 0, expected: 0
  1 lock held by swapper/1:
   #0: c157efb0 (hose_spinlock){+.+.}-{2:2}, at: pcibios_alloc_controller+0x64/0x220
  Preemption disabled at:
  [&lt;00000000&gt;] 0x0
  CPU: 0 PID: 1 Comm: swapper Not tainted 5.19.0-yocto-standard+ #1
  Call Trace:
  [d101dc90] [c073b264] dump_stack_lvl+0x50/0x8c (unreliable)
  [d101dcb0] [c0093b70] __might_resched+0x258/0x2a8
  [d101dcd0] [c0d3e634] __mutex_lock+0x6c/0x6ec
  [d101dd50] [c0a84174] of_alias_get_id+0x50/0xf4
  [d101dd80] [c002ec78] pcibios_alloc_controller+0x1b8/0x220
  [d101ddd0] [c140c9dc] pmac_pci_init+0x198/0x784
  [d101de50] [c140852c] discover_phbs+0x30/0x4c
  [d101de60] [c0007fd4] do_one_initcall+0x94/0x344
  [d101ded0] [c1403b40] kernel_init_freeable+0x1a8/0x22c
  [d101df10] [c00086e0] kernel_init+0x34/0x160
  [d101df30] [c001b334] ret_from_kernel_thread+0x5c/0x64

This is because pcibios_alloc_controller() holds hose_spinlock but
of_alias_get_id() takes of_mutex which can sleep.

The hose_spinlock protects the phb_bitmap, and also the hose_list, but
it doesn't need to be held while get_phb_number() calls the OF routines,
because those are only looking up information in the device tree.

So fix it by having get_phb_number() take the hose_spinlock itself, only
where required, and then dropping the lock before returning.
pcibios_alloc_controller() then needs to take the lock again before the
list_add() but that's safe, the order of the list is not important.</Note>
    </Notes>
    <CVE>CVE-2022-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:

ASoC: SOF: debug: Fix potential buffer overflow by snprintf()

snprintf() returns the would-be-filled size when the string overflows
the given buffer size, hence using this value may result in the buffer
overflow (although it's unrealistic).

This patch replaces with a safer version, scnprintf() for papering
over such a potential issue.</Note>
    </Notes>
    <CVE>CVE-2022-50051</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: don't leak snap_rwsem in handle_cap_grant

When handle_cap_grant is called on an IMPORT op, then the snap_rwsem is
held and the function is expected to release it before returning. It
currently fails to do that in all cases which could lead to a deadlock.</Note>
    </Notes>
    <CVE>CVE-2022-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:

pinctrl: nomadik: Fix refcount leak in nmk_pinctrl_dt_subnode_to_map

of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak."</Note>
    </Notes>
    <CVE>CVE-2022-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:

virtio_net: fix memory leak inside XPD_TX with mergeable

When we call xdp_convert_buff_to_frame() to get xdpf, if it returns
NULL, we should check if xdp_page was allocated by xdp_linearize_page().
If it is newly allocated, it should be freed here alone. Just like any
other "goto err_xdp".</Note>
    </Notes>
    <CVE>CVE-2022-50065</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/pnfs: Fix a use-after-free bug in open

If someone cancels the open RPC call, then we must not try to free
either the open slot or the layoutget operation arguments, since they
are likely still in use by the hung RPC call.</Note>
    </Notes>
    <CVE>CVE-2022-50072</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-50083</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 raid: fix address sanitizer warning in raid_status

There is this warning when using a kernel with the address sanitizer
and running this testsuite:
https://gitlab.com/cki-project/kernel-tests/-/tree/main/storage/swraid/scsi_raid

==================================================================
BUG: KASAN: slab-out-of-bounds in raid_status+0x1747/0x2820 [dm_raid]
Read of size 4 at addr ffff888079d2c7e8 by task lvcreate/13319
CPU: 0 PID: 13319 Comm: lvcreate Not tainted 5.18.0-0.rc3.&lt;snip&gt; #1
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x6a/0x9c
 print_address_description.constprop.0+0x1f/0x1e0
 print_report.cold+0x55/0x244
 kasan_report+0xc9/0x100
 raid_status+0x1747/0x2820 [dm_raid]
 dm_ima_measure_on_table_load+0x4b8/0xca0 [dm_mod]
 table_load+0x35c/0x630 [dm_mod]
 ctl_ioctl+0x411/0x630 [dm_mod]
 dm_ctl_ioctl+0xa/0x10 [dm_mod]
 __x64_sys_ioctl+0x12a/0x1a0
 do_syscall_64+0x5b/0x80

The warning is caused by reading conf-&gt;max_nr_stripes in raid_status. The
code in raid_status reads mddev-&gt;private, casts it to struct r5conf and
reads the entry max_nr_stripes.

However, if we have different raid type than 4/5/6, mddev-&gt;private
doesn't point to struct r5conf; it may point to struct r0conf, struct
r1conf, struct r10conf or struct mpconf. If we cast a pointer to one
of these structs to struct r5conf, we will be reading invalid memory
and KASAN warns about it.

Fix this bug by reading struct r5conf only if raid type is 4, 5 or 6.</Note>
    </Notes>
    <CVE>CVE-2022-50084</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 raid: fix address sanitizer warning in raid_resume

There is a KASAN warning in raid_resume when running the lvm test
lvconvert-raid.sh. The reason for the warning is that mddev-&gt;raid_disks
is greater than rs-&gt;raid_disks, so the loop touches one entry beyond
the allocated length.</Note>
    </Notes>
    <CVE>CVE-2022-50085</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

firmware: arm_scpi: Ensure scpi_info is not assigned if the probe fails

When scpi probe fails, at any point, we need to ensure that the scpi_info
is not set and will remain NULL until the probe succeeds. If it is not
taken care, then it could result use-after-free as the value is exported
via get_scpi_ops() and could refer to a memory allocated via devm_kzalloc()
but freed when the probe fails.</Note>
    </Notes>
    <CVE>CVE-2022-50087</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:

locking/csd_lock: Change csdlock_debug from early_param to __setup

The csdlock_debug kernel-boot parameter is parsed by the
early_param() function csdlock_debug().  If set, csdlock_debug()
invokes static_branch_enable() to enable csd_lock_wait feature, which
triggers a panic on arm64 for kernels built with CONFIG_SPARSEMEM=y and
CONFIG_SPARSEMEM_VMEMMAP=n.

With CONFIG_SPARSEMEM_VMEMMAP=n, __nr_to_section is called in
static_key_enable() and returns NULL, resulting in a NULL dereference
because mem_section is initialized only later in sparse_init().

This is also a problem for powerpc because early_param() functions
are invoked earlier than jump_label_init(), also resulting in
static_key_enable() failures.  These failures cause the warning "static
key 'xxx' used before call to jump_label_init()".

Thus, early_param is too early for csd_lock_wait to run
static_branch_enable(), so changes it to __setup to fix these.</Note>
    </Notes>
    <CVE>CVE-2022-50091</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 thin: fix use-after-free crash in dm_sm_register_threshold_callback

Fault inject on pool metadata device reports:
  BUG: KASAN: use-after-free in dm_pool_register_metadata_threshold+0x40/0x80
  Read of size 8 at addr ffff8881b9d50068 by task dmsetup/950

  CPU: 7 PID: 950 Comm: dmsetup Tainted: G        W         5.19.0-rc6 #1
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014
  Call Trace:
   &lt;TASK&gt;
   dump_stack_lvl+0x34/0x44
   print_address_description.constprop.0.cold+0xeb/0x3f4
   kasan_report.cold+0xe6/0x147
   dm_pool_register_metadata_threshold+0x40/0x80
   pool_ctr+0xa0a/0x1150
   dm_table_add_target+0x2c8/0x640
   table_load+0x1fd/0x430
   ctl_ioctl+0x2c4/0x5a0
   dm_ctl_ioctl+0xa/0x10
   __x64_sys_ioctl+0xb3/0xd0
   do_syscall_64+0x35/0x80
   entry_SYSCALL_64_after_hwframe+0x46/0xb0

This can be easily reproduced using:
  echo offline &gt; /sys/block/sda/device/state
  dd if=/dev/zero of=/dev/mapper/thin bs=4k count=10
  dmsetup load pool --table "0 20971520 thin-pool /dev/sda /dev/sdb 128 0 0"

If a metadata commit fails, the transaction will be aborted and the
metadata space maps will be destroyed. If a DM table reload then
happens for this failed thin-pool, a use-after-free will occur in
dm_sm_register_threshold_callback (called from
dm_pool_register_metadata_threshold).

Fix this by in dm_pool_register_metadata_threshold() by returning the
-EINVAL error if the thin-pool is in fail mode. Also fail pool_ctr()
with a new error message: "Error registering metadata threshold".</Note>
    </Notes>
    <CVE>CVE-2022-50092</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: avoid invalid memory access via node_online(NUMA_NO_NODE)

KASAN reports:

[ 4.668325][ T0] BUG: KASAN: wild-memory-access in dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497)
[    4.676149][    T0] Read of size 8 at addr 1fffffff85115558 by task swapper/0/0
[    4.683454][    T0]
[    4.685638][    T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc3-00004-g0e862838f290 #1
[    4.694331][    T0] Hardware name: Supermicro SYS-5018D-FN4T/X10SDV-8C-TLN4F, BIOS 1.1 03/02/2016
[    4.703196][    T0] Call Trace:
[    4.706334][    T0]  &lt;TASK&gt;
[ 4.709133][ T0] ? dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497)

after converting the type of the first argument (@nr, bit number)
of arch_test_bit() from `long` to `unsigned long`[0].

Under certain conditions (for example, when ACPI NUMA is disabled
via command line), pxm_to_node() can return %NUMA_NO_NODE (-1).
It is valid 'magic' number of NUMA node, but not valid bit number
to use in bitops.
node_online() eventually descends to test_bit() without checking
for the input, assuming it's on caller side (which might be good
for perf-critical tasks). There, -1 becomes %ULONG_MAX which leads
to an insane array index when calculating bit position in memory.

For now, add an explicit check for @node being not %NUMA_NO_NODE
before calling test_bit(). The actual logics didn't change here
at all.

[0] https://github.com/norov/linux/commit/0e862838f290147ea9c16db852d8d494b552d38d</Note>
    </Notes>
    <CVE>CVE-2022-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:

spmi: trace: fix stack-out-of-bound access in SPMI tracing functions

trace_spmi_write_begin() and trace_spmi_read_end() both call
memcpy() with a length of "len + 1".  This leads to one extra
byte being read beyond the end of the specified buffer.  Fix
this out-of-bound memory access by using a length of "len"
instead.

Here is a KASAN log showing the issue:

BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_spmi_read_end+0x1d0/0x234
Read of size 2 at addr ffffffc0265b7540 by task thermal@2.0-ser/1314
...
Call trace:
 dump_backtrace+0x0/0x3e8
 show_stack+0x2c/0x3c
 dump_stack_lvl+0xdc/0x11c
 print_address_description+0x74/0x384
 kasan_report+0x188/0x268
 kasan_check_range+0x270/0x2b0
 memcpy+0x90/0xe8
 trace_event_raw_event_spmi_read_end+0x1d0/0x234
 spmi_read_cmd+0x294/0x3ac
 spmi_ext_register_readl+0x84/0x9c
 regmap_spmi_ext_read+0x144/0x1b0 [regmap_spmi]
 _regmap_raw_read+0x40c/0x754
 regmap_raw_read+0x3a0/0x514
 regmap_bulk_read+0x418/0x494
 adc5_gen3_poll_wait_hs+0xe8/0x1e0 [qcom_spmi_adc5_gen3]
 ...
 __arm64_sys_read+0x4c/0x60
 invoke_syscall+0x80/0x218
 el0_svc_common+0xec/0x1c8
 ...

addr ffffffc0265b7540 is located in stack of task thermal@2.0-ser/1314 at offset 32 in frame:
 adc5_gen3_poll_wait_hs+0x0/0x1e0 [qcom_spmi_adc5_gen3]

this frame has 1 object:
 [32, 33) 'status'

Memory state around the buggy address:
 ffffffc0265b7400: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
 ffffffc0265b7480: 04 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
&gt;ffffffc0265b7500: 00 00 00 00 f1 f1 f1 f1 01 f3 f3 f3 00 00 00 00
                                           ^
 ffffffc0265b7580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffffffc0265b7600: f1 f1 f1 f1 01 f2 07 f2 f2 f2 01 f3 00 00 00 00
==================================================================</Note>
    </Notes>
    <CVE>CVE-2022-50094</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

video: fbdev: s3fb: Check the size of screen before memset_io()

In the function s3fb_set_par(), the value of 'screen_size' is
calculated by the user input. If the user provides the improper value,
the value of 'screen_size' may larger than 'info-&gt;screen_size', which
may cause the following bug:

[   54.083733] BUG: unable to handle page fault for address: ffffc90003000000
[   54.083742] #PF: supervisor write access in kernel mode
[   54.083744] #PF: error_code(0x0002) - not-present page
[   54.083760] RIP: 0010:memset_orig+0x33/0xb0
[   54.083782] Call Trace:
[   54.083788]  s3fb_set_par+0x1ec6/0x4040
[   54.083806]  fb_set_var+0x604/0xeb0
[   54.083836]  do_fb_ioctl+0x234/0x670

Fix the this by checking the value of 'screen_size' before memset_io().</Note>
    </Notes>
    <CVE>CVE-2022-50097</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 crash due to stale SRB access around I/O timeouts

Ensure SRB is returned during I/O timeout error escalation. If that is not
possible fail the escalation path.

Following crash stack was seen:

BUG: unable to handle kernel paging request at 0000002f56aa90f8
IP: qla_chk_edif_rx_sa_delete_pending+0x14/0x30 [qla2xxx]
Call Trace:
 ? qla2x00_status_entry+0x19f/0x1c50 [qla2xxx]
 ? qla2x00_start_sp+0x116/0x1170 [qla2xxx]
 ? dma_pool_alloc+0x1d6/0x210
 ? mempool_alloc+0x54/0x130
 ? qla24xx_process_response_queue+0x548/0x12b0 [qla2xxx]
 ? qla_do_work+0x2d/0x40 [qla2xxx]
 ? process_one_work+0x14c/0x390</Note>
    </Notes>
    <CVE>CVE-2022-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:

video: fbdev: arkfb: Check the size of screen before memset_io()

In the function arkfb_set_par(), the value of 'screen_size' is
calculated by the user input. If the user provides the improper value,
the value of 'screen_size' may larger than 'info-&gt;screen_size', which
may cause the following bug:

[  659.399066] BUG: unable to handle page fault for address: ffffc90003000000
[  659.399077] #PF: supervisor write access in kernel mode
[  659.399079] #PF: error_code(0x0002) - not-present page
[  659.399094] RIP: 0010:memset_orig+0x33/0xb0
[  659.399116] Call Trace:
[  659.399122]  arkfb_set_par+0x143f/0x24c0
[  659.399130]  fb_set_var+0x604/0xeb0
[  659.399161]  do_fb_ioctl+0x234/0x670
[  659.399189]  fb_ioctl+0xdd/0x130

Fix the this by checking the value of 'screen_size' before memset_io().</Note>
    </Notes>
    <CVE>CVE-2022-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:

video: fbdev: vt8623fb: Check the size of screen before memset_io()

In the function vt8623fb_set_par(), the value of 'screen_size' is
calculated by the user input. If the user provides the improper value,
the value of 'screen_size' may larger than 'info-&gt;screen_size', which
may cause the following bug:

[  583.339036] BUG: unable to handle page fault for address: ffffc90005000000
[  583.339049] #PF: supervisor write access in kernel mode
[  583.339052] #PF: error_code(0x0002) - not-present page
[  583.339074] RIP: 0010:memset_orig+0x33/0xb0
[  583.339110] Call Trace:
[  583.339118]  vt8623fb_set_par+0x11cd/0x21e0
[  583.339146]  fb_set_var+0x604/0xeb0
[  583.339181]  do_fb_ioctl+0x234/0x670
[  583.339209]  fb_ioctl+0xdd/0x130

Fix the this by checking the value of 'screen_size' before memset_io().</Note>
    </Notes>
    <CVE>CVE-2022-50101</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

video: fbdev: arkfb: Fix a divide-by-zero bug in ark_set_pixclock()

Since the user can control the arguments of the ioctl() from the user
space, under special arguments that may result in a divide-by-zero bug
in:
  drivers/video/fbdev/arkfb.c:784: ark_set_pixclock(info, (hdiv * info-&gt;var.pixclock) / hmul);
with hdiv=1, pixclock=1 and hmul=2 you end up with (1*1)/2 = (int) 0.
and then in:
  drivers/video/fbdev/arkfb.c:504: rv = dac_set_freq(par-&gt;dac, 0, 1000000000 / pixclock);
we'll get a division-by-zero.

The following log can reveal it:

divide error: 0000 [#1] PREEMPT SMP KASAN PTI
RIP: 0010:ark_set_pixclock drivers/video/fbdev/arkfb.c:504 [inline]
RIP: 0010:arkfb_set_par+0x10fc/0x24c0 drivers/video/fbdev/arkfb.c:784
Call Trace:
 fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1034
 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110
 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189

Fix this by checking the argument of ark_set_pixclock() first.</Note>
    </Notes>
    <CVE>CVE-2022-50102</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/xive: Fix refcount leak in xive_get_max_prio

of_find_node_by_path() returns a node pointer with
refcount incremented, we should use of_node_put() on it when done.
Add missing of_node_put() to avoid refcount leak.</Note>
    </Notes>
    <CVE>CVE-2022-50104</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mfd: max77620: Fix refcount leak in max77620_initialise_fps

of_get_child_by_name() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak.</Note>
    </Notes>
    <CVE>CVE-2022-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:

video: fbdev: amba-clcd: Fix refcount leak bugs

In clcdfb_of_init_display(), we should call of_node_put() for the
references returned by of_graph_get_next_endpoint() and
of_graph_get_remote_port_parent() which have increased the refcount.

Besides, we should call of_node_put() both in fail path or when
the references are not used anymore.</Note>
    </Notes>
    <CVE>CVE-2022-50109</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/perf: Optimize clearing the pending PMI and remove WARN_ON for PMI check in power_pmu_disable

commit 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear
pending PMI before resetting an overflown PMC") added a new
function "pmi_irq_pending" in hw_irq.h. This function is to check
if there is a PMI marked as pending in Paca (PACA_IRQ_PMI).This is
used in power_pmu_disable in a WARN_ON. The intention here is to
provide a warning if there is PMI pending, but no counter is found
overflown.

During some of the perf runs, below warning is hit:

WARNING: CPU: 36 PID: 0 at arch/powerpc/perf/core-book3s.c:1332 power_pmu_disable+0x25c/0x2c0
 Modules linked in:
 -----

 NIP [c000000000141c3c] power_pmu_disable+0x25c/0x2c0
 LR [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0
 Call Trace:
 [c000000baffcfb90] [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 (unreliable)
 [c000000baffcfc10] [c0000000003e2f8c] perf_pmu_disable+0x4c/0x60
 [c000000baffcfc30] [c0000000003e3344] group_sched_out.part.124+0x44/0x100
 [c000000baffcfc80] [c0000000003e353c] __perf_event_disable+0x13c/0x240
 [c000000baffcfcd0] [c0000000003dd334] event_function+0xc4/0x140
 [c000000baffcfd20] [c0000000003d855c] remote_function+0x7c/0xa0
 [c000000baffcfd50] [c00000000026c394] flush_smp_call_function_queue+0xd4/0x300
 [c000000baffcfde0] [c000000000065b24] smp_ipi_demux_relaxed+0xa4/0x100
 [c000000baffcfe20] [c0000000000cb2b0] xive_muxed_ipi_action+0x20/0x40
 [c000000baffcfe40] [c000000000207c3c] __handle_irq_event_percpu+0x8c/0x250
 [c000000baffcfee0] [c000000000207e2c] handle_irq_event_percpu+0x2c/0xa0
 [c000000baffcff10] [c000000000210a04] handle_percpu_irq+0x84/0xc0
 [c000000baffcff40] [c000000000205f14] generic_handle_irq+0x54/0x80
 [c000000baffcff60] [c000000000015740] __do_irq+0x90/0x1d0
 [c000000baffcff90] [c000000000016990] __do_IRQ+0xc0/0x140
 [c0000009732f3940] [c000000bafceaca8] 0xc000000bafceaca8
 [c0000009732f39d0] [c000000000016b78] do_IRQ+0x168/0x1c0
 [c0000009732f3a00] [c0000000000090c8] hardware_interrupt_common_virt+0x218/0x220

This means that there is no PMC overflown among the active events
in the PMU, but there is a PMU pending in Paca. The function
"any_pmc_overflown" checks the PMCs on active events in
cpuhw-&gt;n_events. Code snippet:

&lt;&lt;&gt;&gt;
if (any_pmc_overflown(cpuhw))
 	clear_pmi_irq_pending();
 else
 	WARN_ON(pmi_irq_pending());
&lt;&lt;&gt;&gt;

Here the PMC overflown is not from active event. Example: When we do
perf record, default cycles and instructions will be running on PMC6
and PMC5 respectively. It could happen that overflowed event is currently
not active and pending PMI is for the inactive event. Debug logs from
trace_printk:

&lt;&lt;&gt;&gt;
any_pmc_overflown: idx is 5: pmc value is 0xd9a
power_pmu_disable: PMC1: 0x0, PMC2: 0x0, PMC3: 0x0, PMC4: 0x0, PMC5: 0xd9a, PMC6: 0x80002011
&lt;&lt;&gt;&gt;

Here active PMC (from idx) is PMC5 , but overflown PMC is PMC6(0x80002011).
When we handle PMI interrupt for such cases, if the PMC overflown is
from inactive event, it will be ignored. Reference commit:
commit bc09c219b2e6 ("powerpc/perf: Fix finding overflowed PMC in interrupt")

Patch addresses two changes:
1) Fix 1 : Removal of warning ( WARN_ON(pmi_irq_pending()); )
   We were printing warning if no PMC is found overflown among active PMU
   events, but PMI pending in PACA. But this could happen in cases where
   PMC overflown is not in active PMC. An inactive event could have caused
   the overflow. Hence the warning is not needed. To know pending PMI is
   from an inactive event, we need to loop through all PMC's which will
   cause more SPR reads via mfspr and increase in context switch. Also in
   existing function: perf_event_interrupt, already we ignore PMI's
   overflown when it is from an inactive PMC.

2) Fix 2: optimization in clearing pending PMI.
   Currently we check for any active PMC overflown before clearing PMI
   pending in Paca. This is causing additional SP
---truncated---</Note>
    </Notes>
    <CVE>CVE-2022-50118</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mt6797-mt6351: Fix refcount leak in mt6797_mt6351_dev_probe

of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak.</Note>
    </Notes>
    <CVE>CVE-2022-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:

jbd2: fix assertion 'jh-&gt;b_frozen_data == NULL' failure when journal aborted

Following process will fail assertion 'jh-&gt;b_frozen_data == NULL' in
jbd2_journal_dirty_metadata():

                   jbd2_journal_commit_transaction
unlink(dir/a)
 jh-&gt;b_transaction = trans1
 jh-&gt;b_jlist = BJ_Metadata
                    journal-&gt;j_running_transaction = NULL
                    trans1-&gt;t_state = T_COMMIT
unlink(dir/b)
 handle-&gt;h_trans = trans2
 do_get_write_access
  jh-&gt;b_modified = 0
  jh-&gt;b_frozen_data = frozen_buffer
  jh-&gt;b_next_transaction = trans2
 jbd2_journal_dirty_metadata
  is_handle_aborted
   is_journal_aborted // return false

           --&gt; jbd2 abort &lt;--

                     while (commit_transaction-&gt;t_buffers)
                      if (is_journal_aborted)
                       jbd2_journal_refile_buffer
                        __jbd2_journal_refile_buffer
                         WRITE_ONCE(jh-&gt;b_transaction,
						jh-&gt;b_next_transaction)
                         WRITE_ONCE(jh-&gt;b_next_transaction, NULL)
                         __jbd2_journal_file_buffer(jh, BJ_Reserved)
        J_ASSERT_JH(jh, jh-&gt;b_frozen_data == NULL) // assertion failure !

The reproducer (See detail in [Link]) reports:
 ------------[ cut here ]------------
 kernel BUG at fs/jbd2/transaction.c:1629!
 invalid opcode: 0000 [#1] PREEMPT SMP
 CPU: 2 PID: 584 Comm: unlink Tainted: G        W
 5.19.0-rc6-00115-g4a57a8400075-dirty #697
 RIP: 0010:jbd2_journal_dirty_metadata+0x3c5/0x470
 RSP: 0018:ffffc90000be7ce0 EFLAGS: 00010202
 Call Trace:
  &lt;TASK&gt;
  __ext4_handle_dirty_metadata+0xa0/0x290
  ext4_handle_dirty_dirblock+0x10c/0x1d0
  ext4_delete_entry+0x104/0x200
  __ext4_unlink+0x22b/0x360
  ext4_unlink+0x275/0x390
  vfs_unlink+0x20b/0x4c0
  do_unlinkat+0x42f/0x4c0
  __x64_sys_unlink+0x37/0x50
  do_syscall_64+0x35/0x80

After journal aborting, __jbd2_journal_refile_buffer() is executed with
holding @jh-&gt;b_state_lock, we can fix it by moving 'is_handle_aborted()'
into the area protected by @jh-&gt;b_state_lock.</Note>
    </Notes>
    <CVE>CVE-2022-50126</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/rxe: Fix error unwind in rxe_create_qp()

In the function rxe_create_qp(), rxe_qp_from_init() is called to
initialize qp, internally things like the spin locks are not setup until
rxe_qp_init_req().

If an error occures before this point then the unwind will call
rxe_cleanup() and eventually to rxe_qp_do_cleanup()/rxe_cleanup_task()
which will oops when trying to access the uninitialized spinlock.

Move the spinlock initializations earlier before any failures.</Note>
    </Notes>
    <CVE>CVE-2022-50127</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/siw: Fix duplicated reported IW_CM_EVENT_CONNECT_REPLY event

If siw_recv_mpa_rr returns -EAGAIN, it means that the MPA reply hasn't
been received completely, and should not report IW_CM_EVENT_CONNECT_REPLY
in this case. This may trigger a call trace in iw_cm. A simple way to
trigger this:
 server: ib_send_lat
 client: ib_send_lat -R &lt;server_ip&gt;

The call trace looks like this:

 kernel BUG at drivers/infiniband/core/iwcm.c:894!
 invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
 &lt;...&gt;
 Workqueue: iw_cm_wq cm_work_handler [iw_cm]
 Call Trace:
  &lt;TASK&gt;
  cm_work_handler+0x1dd/0x370 [iw_cm]
  process_one_work+0x1e2/0x3b0
  worker_thread+0x49/0x2e0
  ? rescuer_thread+0x370/0x370
  kthread+0xe5/0x110
  ? kthread_complete_and_exit+0x20/0x20
  ret_from_fork+0x1f/0x30
  &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2022-50136</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/qedr: Fix potential memory leak in __qedr_alloc_mr()

__qedr_alloc_mr() allocates a memory chunk for "mr-&gt;info.pbl_table" with
init_mr_info(). When rdma_alloc_tid() and rdma_register_tid() fail, "mr"
is released while "mr-&gt;info.pbl_table" is not released, which will lead
to a memory leak.

We should release the "mr-&gt;info.pbl_table" with qedr_free_pbl() when error
occurs to fix the memory leak.</Note>
    </Notes>
    <CVE>CVE-2022-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:

memstick/ms_block: Fix a memory leak

'erased_blocks_bitmap' is never freed. As it is allocated at the same time
as 'used_blocks_bitmap', it is likely that it should be freed also at the
same time.

Add the corresponding bitmap_free() in msb_data_clear().</Note>
    </Notes>
    <CVE>CVE-2022-50140</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sdhci-of-esdhc: Fix refcount leak in esdhc_signal_voltage_switch

of_find_matching_node() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak.
of_node_put() checks null pointer.</Note>
    </Notes>
    <CVE>CVE-2022-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:

intel_th: msu: Fix vmalloced buffers

After commit f5ff79fddf0e ("dma-mapping: remove CONFIG_DMA_REMAP") there's
a chance of DMA buffer getting allocated via vmalloc(), which messes up
the mmapping code:

&gt; RIP: msc_mmap_fault [intel_th_msu]
&gt; Call Trace:
&gt;  &lt;TASK&gt;
&gt;  __do_fault
&gt;  do_fault
...

Fix this by accounting for vmalloc possibility.</Note>
    </Notes>
    <CVE>CVE-2022-50142</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

intel_th: Fix a resource leak in an error handling path

If an error occurs after calling 'pci_alloc_irq_vectors()',
'pci_free_irq_vectors()' must be called as already done in the remove
function.</Note>
    </Notes>
    <CVE>CVE-2022-50143</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: dwc: Deallocate EPC memory on dw_pcie_ep_init() errors

If dw_pcie_ep_init() fails to perform any action after the EPC memory is
initialized and the MSI memory region is allocated, the latter parts won't
be undone thus causing a memory leak.  Add a cleanup-on-error path to fix
these leaks.

[bhelgaas: commit log]</Note>
    </Notes>
    <CVE>CVE-2022-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:

driver core: fix potential deadlock in __driver_attach

In __driver_attach function, There are also AA deadlock problem,
like the commit b232b02bf3c2 ("driver core: fix deadlock in
__device_attach").

stack like commit b232b02bf3c2 ("driver core: fix deadlock in
__device_attach").
list below:
    In __driver_attach function, The lock holding logic is as follows:
    ...
    __driver_attach
    if (driver_allows_async_probing(drv))
      device_lock(dev)      // get lock dev
        async_schedule_dev(__driver_attach_async_helper, dev); // func
          async_schedule_node
            async_schedule_node_domain(func)
              entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);
              /* when fail or work limit, sync to execute func, but
                 __driver_attach_async_helper will get lock dev as
                 will, which will lead to A-A deadlock.  */
              if (!entry || atomic_read(&amp;entry_count) &gt; MAX_WORK) {
                func;
              else
                queue_work_node(node, system_unbound_wq, &amp;entry-&gt;work)
      device_unlock(dev)

    As above show, when it is allowed to do async probes, because of
    out of memory or work limit, async work is not be allowed, to do
    sync execute instead. it will lead to A-A deadlock because of
    __driver_attach_async_helper getting lock dev.

Reproduce:
and it can be reproduce by make the condition
(if (!entry || atomic_read(&amp;entry_count) &gt; MAX_WORK)) untenable, like
below:

[  370.785650] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[  370.787154] task:swapper/0       state:D stack:    0 pid:    1 ppid:
0 flags:0x00004000
[  370.788865] Call Trace:
[  370.789374]  &lt;TASK&gt;
[  370.789841]  __schedule+0x482/0x1050
[  370.790613]  schedule+0x92/0x1a0
[  370.791290]  schedule_preempt_disabled+0x2c/0x50
[  370.792256]  __mutex_lock.isra.0+0x757/0xec0
[  370.793158]  __mutex_lock_slowpath+0x1f/0x30
[  370.794079]  mutex_lock+0x50/0x60
[  370.794795]  __device_driver_lock+0x2f/0x70
[  370.795677]  ? driver_probe_device+0xd0/0xd0
[  370.796576]  __driver_attach_async_helper+0x1d/0xd0
[  370.797318]  ? driver_probe_device+0xd0/0xd0
[  370.797957]  async_schedule_node_domain+0xa5/0xc0
[  370.798652]  async_schedule_node+0x19/0x30
[  370.799243]  __driver_attach+0x246/0x290
[  370.799828]  ? driver_allows_async_probing+0xa0/0xa0
[  370.800548]  bus_for_each_dev+0x9d/0x130
[  370.801132]  driver_attach+0x22/0x30
[  370.801666]  bus_add_driver+0x290/0x340
[  370.802246]  driver_register+0x88/0x140
[  370.802817]  ? virtio_scsi_init+0x116/0x116
[  370.803425]  scsi_register_driver+0x1a/0x30
[  370.804057]  init_sd+0x184/0x226
[  370.804533]  do_one_initcall+0x71/0x3a0
[  370.805107]  kernel_init_freeable+0x39a/0x43a
[  370.805759]  ? rest_init+0x150/0x150
[  370.806283]  kernel_init+0x26/0x230
[  370.806799]  ret_from_fork+0x1f/0x30

To fix the deadlock, move the async_schedule_dev outside device_lock,
as we can see, in async_schedule_node_domain, the parameter of
queue_work_node is system_unbound_wq, so it can accept concurrent
operations. which will also not change the code logic, and will
not lead to deadlock.</Note>
    </Notes>
    <CVE>CVE-2022-50149</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ohci-nxp: Fix refcount leak in ohci_hcd_nxp_probe

of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak.</Note>
    </Notes>
    <CVE>CVE-2022-50152</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: host: Fix refcount leak in ehci_hcd_ppc_of_probe

of_find_compatible_node() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
Add missing of_node_put() to avoid refcount leak.</Note>
    </Notes>
    <CVE>CVE-2022-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:

HID: cp2112: prevent a buffer overflow in cp2112_xfer()

Smatch warnings:
drivers/hid/hid-cp2112.c:793 cp2112_xfer() error: __memcpy()
'data-&gt;block[1]' too small (33 vs 255)
drivers/hid/hid-cp2112.c:793 cp2112_xfer() error: __memcpy() 'buf' too
small (64 vs 255)

The 'read_length' variable is provided by 'data-&gt;block[0]' which comes
from user and it(read_length) can take a value between 0-255. Add an
upper bound to 'read_length' variable to prevent a buffer overflow in
memcpy().</Note>
    </Notes>
    <CVE>CVE-2022-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:

mtd: partitions: Fix refcount leak in parse_redboot_of

of_get_child_by_name() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak.</Note>
    </Notes>
    <CVE>CVE-2022-50158</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mtd: maps: Fix refcount leak in ap_flash_init

of_find_matching_node() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak.</Note>
    </Notes>
    <CVE>CVE-2022-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:

mtd: maps: Fix refcount leak in of_flash_probe_versatile

of_find_matching_node_and_match() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak.</Note>
    </Notes>
    <CVE>CVE-2022-50161</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: libertas: Fix possible refcount leak in if_usb_probe()

usb_get_dev will be called before lbs_get_firmware_async which means that
usb_put_dev need to be called when lbs_get_firmware_async fails.</Note>
    </Notes>
    <CVE>CVE-2022-50162</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 double list_add at iwl_mvm_mac_wake_tx_queue

After successfull station association, if station queues are disabled for
some reason, the related lists are not emptied. So if some new element is
added to the list in iwl_mvm_mac_wake_tx_queue, it can match with the old
one and produce a BUG like this:

[   46.535263] list_add corruption. prev-&gt;next should be next (ffff94c1c318a360), but was 0000000000000000. (prev=ffff94c1d02d3388).
[   46.535283] ------------[ cut here ]------------
[   46.535284] kernel BUG at lib/list_debug.c:26!
[   46.535290] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[   46.585304] CPU: 0 PID: 623 Comm: wpa_supplicant Not tainted 5.19.0-rc3+ #1
[   46.592380] Hardware name: Dell Inc. Inspiron 660s/0478VN       , BIOS A07 08/24/2012
[   46.600336] RIP: 0010:__list_add_valid.cold+0x3d/0x3f
[   46.605475] Code: f2 4c 89 c1 48 89 fe 48 c7 c7 c8 40 67 93 e8 20 cc fd ff 0f 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 70 40 67 93 e8 09 cc fd ff &lt;0f&gt; 0b 48 89 fe 48 c7 c7 00 41 67 93 e8 f8 cb fd ff 0f 0b 48 89 d1
[   46.624469] RSP: 0018:ffffb20800ab76d8 EFLAGS: 00010286
[   46.629854] RAX: 0000000000000075 RBX: ffff94c1c318a0e0 RCX: 0000000000000000
[   46.637105] RDX: 0000000000000201 RSI: ffffffff9365e100 RDI: 00000000ffffffff
[   46.644356] RBP: ffff94c1c5f43370 R08: 0000000000000075 R09: 3064316334396666
[   46.651607] R10: 3364323064316334 R11: 39666666663d7665 R12: ffff94c1c5f43388
[   46.658857] R13: ffff94c1d02d3388 R14: ffff94c1c318a360 R15: ffff94c1cf2289c0
[   46.666108] FS:  00007f65634ff7c0(0000) GS:ffff94c1da200000(0000) knlGS:0000000000000000
[   46.674331] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   46.680170] CR2: 00007f7dfe984460 CR3: 000000010e894003 CR4: 00000000000606f0
[   46.687422] Call Trace:
[   46.689906]  &lt;TASK&gt;
[   46.691950]  iwl_mvm_mac_wake_tx_queue+0xec/0x15c [iwlmvm]
[   46.697601]  ieee80211_queue_skb+0x4b3/0x720 [mac80211]
[   46.702973]  ? sta_info_get+0x46/0x60 [mac80211]
[   46.707703]  ieee80211_tx+0xad/0x110 [mac80211]
[   46.712355]  __ieee80211_tx_skb_tid_band+0x71/0x90 [mac80211]
...

In order to avoid this problem, we must also remove the related lists when
station queues are disabled.</Note>
    </Notes>
    <CVE>CVE-2022-50164</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: wil6210: debugfs: fix uninitialized variable use in `wil_write_file_wmi()`

Commit 7a4836560a61 changes simple_write_to_buffer() with memdup_user()
but it forgets to change the value to be returned that came from
simple_write_to_buffer() call. It results in the following warning:

  warning: variable 'rc' is uninitialized when used here [-Wuninitialized]
           return rc;
                  ^~

Remove rc variable and just return the passed in length if the
memdup_user() succeeds.</Note>
    </Notes>
    <CVE>CVE-2022-50165</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: wil6210: debugfs: fix info leak in wil_write_file_wmi()

The simple_write_to_buffer() function will succeed if even a single
byte is initialized.  However, we need to initialize the whole buffer
to prevent information leaks.  Just use memdup_user().</Note>
    </Notes>
    <CVE>CVE-2022-50169</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mt76: mt76x02u: fix possible memory leak in __mt76x02u_mcu_send_msg

Free the skb if mt76u_bulk_msg fails in __mt76x02u_mcu_send_msg routine.</Note>
    </Notes>
    <CVE>CVE-2022-50172</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/mdp5: Fix global state lock backoff

We need to grab the lock after the early return for !hwpipe case.
Otherwise, we could have hit contention yet still returned 0.

Fixes an issue that the new CONFIG_DRM_DEBUG_MODESET_LOCK stuff flagged
in CI:

   WARNING: CPU: 0 PID: 282 at drivers/gpu/drm/drm_modeset_lock.c:296 drm_modeset_lock+0xf8/0x154
   Modules linked in:
   CPU: 0 PID: 282 Comm: kms_cursor_lega Tainted: G        W         5.19.0-rc2-15930-g875cc8bc536a #1
   Hardware name: Qualcomm Technologies, Inc. DB820c (DT)
   pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
   pc : drm_modeset_lock+0xf8/0x154
   lr : drm_atomic_get_private_obj_state+0x84/0x170
   sp : ffff80000cfab6a0
   x29: ffff80000cfab6a0 x28: 0000000000000000 x27: ffff000083bc4d00
   x26: 0000000000000038 x25: 0000000000000000 x24: ffff80000957ca58
   x23: 0000000000000000 x22: ffff000081ace080 x21: 0000000000000001
   x20: ffff000081acec18 x19: ffff80000cfabb80 x18: 0000000000000038
   x17: 0000000000000000 x16: 0000000000000000 x15: fffffffffffea0d0
   x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 5f534b434f4c5f47
   x11: ffff80000a386aa8 x10: 0000000000000029 x9 : ffff80000cfab610
   x8 : 0000000000000029 x7 : 0000000000000014 x6 : 0000000000000000
   x5 : 0000000000000001 x4 : ffff8000081ad904 x3 : 0000000000000029
   x2 : ffff0000801db4c0 x1 : ffff80000cfabb80 x0 : ffff000081aceb58
   Call trace:
    drm_modeset_lock+0xf8/0x154
    drm_atomic_get_private_obj_state+0x84/0x170
    mdp5_get_global_state+0x54/0x6c
    mdp5_pipe_release+0x2c/0xd4
    mdp5_plane_atomic_check+0x2ec/0x414
    drm_atomic_helper_check_planes+0xd8/0x210
    drm_atomic_helper_check+0x54/0xb0
    ...
   ---[ end trace 0000000000000000 ]---
   drm_modeset_lock attempting to lock a contended lock without backoff:
      drm_modeset_lock+0x148/0x154
      mdp5_get_global_state+0x30/0x6c
      mdp5_pipe_release+0x2c/0xd4
      mdp5_plane_atomic_check+0x290/0x414
      drm_atomic_helper_check_planes+0xd8/0x210
      drm_atomic_helper_check+0x54/0xb0
      drm_atomic_check_only+0x4b0/0x8f4
      drm_atomic_commit+0x68/0xe0

Patchwork: https://patchwork.freedesktop.org/patch/492701/</Note>
    </Notes>
    <CVE>CVE-2022-50173</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/mcde: Fix refcount leak in mcde_dsi_bind

Every iteration of for_each_available_child_of_node() decrements
the reference counter of the previous node. There is no decrement
when break out from the loop and results in refcount leak.
Add missing of_node_put() to fix this.</Note>
    </Notes>
    <CVE>CVE-2022-50176</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-gpu: fix a missing check to avoid NULL dereference

'cache_ent' could be set NULL inside virtio_gpu_cmd_get_capset()
and it will lead to a NULL dereference by a lately use of it
(i.e., ptr = cache_ent-&gt;caps_cache). Fix it with a NULL check.


[ kraxel: minor codestyle fixup ]</Note>
    </Notes>
    <CVE>CVE-2022-50181</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 potential buffer overflow in ni_set_mc_special_registers()

The last case label can write two buffers 'mc_reg_address[j]' and
'mc_data[j]' with 'j' offset equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE
since there are no checks for this value in both case labels after the
last 'j++'.

Instead of changing '&gt;' to '&gt;=' there, add the bounds check at the start
of the second 'case' (the first one already has it).

Also, remove redundant last checks for 'j' index bigger than array size.
The expression is always false. Moreover, before or after the patch
'table-&gt;last' can be equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE and it
seems it can be a valid value.

Detected using the static analysis tool - Svace.</Note>
    </Notes>
    <CVE>CVE-2022-50185</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: of: Fix refcount leak bug in of_get_regulation_constraints()

We should call the of_node_put() for the reference returned by
of_get_child_by_name() which has increased the refcount.</Note>
    </Notes>
    <CVE>CVE-2022-50191</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

selinux: Add boundary check in put_entry()

Just like next_entry(), boundary check is necessary to prevent memory
out-of-bound access.</Note>
    </Notes>
    <CVE>CVE-2022-50200</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:

meson-mx-socinfo: Fix refcount leak in meson_mx_socinfo_init

of_find_matching_node() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak.</Note>
    </Notes>
    <CVE>CVE-2022-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:

md-raid10: fix KASAN warning

There's a KASAN warning in raid10_remove_disk when running the lvm
test lvconvert-raid-reshape.sh. We fix this warning by verifying that the
value "number" is valid.

BUG: KASAN: slab-out-of-bounds in raid10_remove_disk+0x61/0x2a0 [raid10]
Read of size 8 at addr ffff889108f3d300 by task mdX_raid10/124682

CPU: 3 PID: 124682 Comm: mdX_raid10 Not tainted 5.19.0-rc6 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x34/0x44
 print_report.cold+0x45/0x57a
 ? __lock_text_start+0x18/0x18
 ? raid10_remove_disk+0x61/0x2a0 [raid10]
 kasan_report+0xa8/0xe0
 ? raid10_remove_disk+0x61/0x2a0 [raid10]
 raid10_remove_disk+0x61/0x2a0 [raid10]
Buffer I/O error on dev dm-76, logical block 15344, async page read
 ? __mutex_unlock_slowpath.constprop.0+0x1e0/0x1e0
 remove_and_add_spares+0x367/0x8a0 [md_mod]
 ? super_written+0x1c0/0x1c0 [md_mod]
 ? mutex_trylock+0xac/0x120
 ? _raw_spin_lock+0x72/0xc0
 ? _raw_spin_lock_bh+0xc0/0xc0
 md_check_recovery+0x848/0x960 [md_mod]
 raid10d+0xcf/0x3360 [raid10]
 ? sched_clock_cpu+0x185/0x1a0
 ? rb_erase+0x4d4/0x620
 ? var_wake_function+0xe0/0xe0
 ? psi_group_change+0x411/0x500
 ? preempt_count_sub+0xf/0xc0
 ? _raw_spin_lock_irqsave+0x78/0xc0
 ? __lock_text_start+0x18/0x18
 ? raid10_sync_request+0x36c0/0x36c0 [raid10]
 ? preempt_count_sub+0xf/0xc0
 ? _raw_spin_unlock_irqrestore+0x19/0x40
 ? del_timer_sync+0xa9/0x100
 ? try_to_del_timer_sync+0xc0/0xc0
 ? _raw_spin_lock_irqsave+0x78/0xc0
 ? __lock_text_start+0x18/0x18
 ? _raw_spin_unlock_irq+0x11/0x24
 ? __list_del_entry_valid+0x68/0xa0
 ? finish_wait+0xa3/0x100
 md_thread+0x161/0x260 [md_mod]
 ? unregister_md_personality+0xa0/0xa0 [md_mod]
 ? _raw_spin_lock_irqsave+0x78/0xc0
 ? prepare_to_wait_event+0x2c0/0x2c0
 ? unregister_md_personality+0xa0/0xa0 [md_mod]
 kthread+0x148/0x180
 ? kthread_complete_and_exit+0x20/0x20
 ret_from_fork+0x1f/0x30
 &lt;/TASK&gt;

Allocated by task 124495:
 kasan_save_stack+0x1e/0x40
 __kasan_kmalloc+0x80/0xa0
 setup_conf+0x140/0x5c0 [raid10]
 raid10_run+0x4cd/0x740 [raid10]
 md_run+0x6f9/0x1300 [md_mod]
 raid_ctr+0x2531/0x4ac0 [dm_raid]
 dm_table_add_target+0x2b0/0x620 [dm_mod]
 table_load+0x1c8/0x400 [dm_mod]
 ctl_ioctl+0x29e/0x560 [dm_mod]
 dm_compat_ctl_ioctl+0x7/0x20 [dm_mod]
 __do_compat_sys_ioctl+0xfa/0x160
 do_syscall_64+0x90/0xc0
 entry_SYSCALL_64_after_hwframe+0x46/0xb0

Last potentially related work creation:
 kasan_save_stack+0x1e/0x40
 __kasan_record_aux_stack+0x9e/0xc0
 kvfree_call_rcu+0x84/0x480
 timerfd_release+0x82/0x140
L __fput+0xfa/0x400
 task_work_run+0x80/0xc0
 exit_to_user_mode_prepare+0x155/0x160
 syscall_exit_to_user_mode+0x12/0x40
 do_syscall_64+0x42/0xc0
 entry_SYSCALL_64_after_hwframe+0x46/0xb0

Second to last potentially related work creation:
 kasan_save_stack+0x1e/0x40
 __kasan_record_aux_stack+0x9e/0xc0
 kvfree_call_rcu+0x84/0x480
 timerfd_release+0x82/0x140
 __fput+0xfa/0x400
 task_work_run+0x80/0xc0
 exit_to_user_mode_prepare+0x155/0x160
 syscall_exit_to_user_mode+0x12/0x40
 do_syscall_64+0x42/0xc0
 entry_SYSCALL_64_after_hwframe+0x46/0xb0

The buggy address belongs to the object at ffff889108f3d200
 which belongs to the cache kmalloc-256 of size 256
The buggy address is located 0 bytes to the right of
 256-byte region [ffff889108f3d200, ffff889108f3d300)

The buggy address belongs to the physical page:
page:000000007ef2a34c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1108f3c
head:000000007ef2a34c order:2 compound_mapcount:0 compound_pincount:0
flags: 0x4000000000010200(slab|head|zone=2)
raw: 4000000000010200 0000000000000000 dead000000000001 ffff889100042b40
raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff889108f3d200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff889108f3d280: 00 00
---truncated---</Note>
    </Notes>
    <CVE>CVE-2022-50211</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sg: Allow waiting for commands to complete on removed device

When a SCSI device is removed while in active use, currently sg will
immediately return -ENODEV on any attempt to wait for active commands that
were sent before the removal.  This is problematic for commands that use
SG_FLAG_DIRECT_IO since the data buffer may still be in use by the kernel
when userspace frees or reuses it after getting ENODEV, leading to
corrupted userspace memory (in the case of READ-type commands) or corrupted
data being sent to the device (in the case of WRITE-type commands).  This
has been seen in practice when logging out of a iscsi_tcp session, where
the iSCSI driver may still be processing commands after the device has been
marked for removal.

Change the policy to allow userspace to wait for active sg commands even
when the device is being removed.  Return -ENODEV only when there are no
more responses to read.</Note>
    </Notes>
    <CVE>CVE-2022-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:

iio: light: isl29028: Fix the warning in isl29028_remove()

The driver use the non-managed form of the register function in
isl29028_remove(). To keep the release order as mirroring the ordering
in probe, the driver should use non-managed form in probe, too.

The following log reveals it:

[   32.374955] isl29028 0-0010: remove
[   32.376861] general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN PTI
[   32.377676] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
[   32.379432] RIP: 0010:kernfs_find_and_get_ns+0x28/0xe0
[   32.385461] Call Trace:
[   32.385807]  sysfs_unmerge_group+0x59/0x110
[   32.386110]  dpm_sysfs_remove+0x58/0xc0
[   32.386391]  device_del+0x296/0xe50
[   32.386959]  cdev_device_del+0x1d/0xd0
[   32.387231]  devm_iio_device_unreg+0x27/0xb0
[   32.387542]  devres_release_group+0x319/0x3d0
[   32.388162]  i2c_device_remove+0x93/0x1f0</Note>
    </Notes>
    <CVE>CVE-2022-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:

usbnet: Fix linkwatch use-after-free on disconnect

usbnet uses the work usbnet_deferred_kevent() to perform tasks which may
sleep.  On disconnect, completion of the work was originally awaited in
-&gt;ndo_stop().  But in 2003, that was moved to -&gt;disconnect() by historic
commit "[PATCH] USB: usbnet, prevent exotic rtnl deadlock":

  https://git.kernel.org/tglx/history/c/0f138bbfd83c

The change was made because back then, the kernel's workqueue
implementation did not allow waiting for a single work.  One had to wait
for completion of *all* work by calling flush_scheduled_work(), and that
could deadlock when waiting for usbnet_deferred_kevent() with rtnl_mutex
held in -&gt;ndo_stop().

The commit solved one problem but created another:  It causes a
use-after-free in USB Ethernet drivers aqc111.c, asix_devices.c,
ax88179_178a.c, ch9200.c and smsc75xx.c:

* If the drivers receive a link change interrupt immediately before
  disconnect, they raise EVENT_LINK_RESET in their (non-sleepable)
  -&gt;status() callback and schedule usbnet_deferred_kevent().
* usbnet_deferred_kevent() invokes the driver's -&gt;link_reset() callback,
  which calls netif_carrier_{on,off}().
* That in turn schedules the work linkwatch_event().

Because usbnet_deferred_kevent() is awaited after unregister_netdev(),
netif_carrier_{on,off}() may operate on an unregistered netdev and
linkwatch_event() may run after free_netdev(), causing a use-after-free.

In 2010, usbnet was changed to only wait for a single instance of
usbnet_deferred_kevent() instead of *all* work by commit 23f333a2bfaf
("drivers/net: don't use flush_scheduled_work()").

Unfortunately the commit neglected to move the wait back to
-&gt;ndo_stop().  Rectify that omission at long last.</Note>
    </Notes>
    <CVE>CVE-2022-50220</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: vt: initialize unicode screen buffer

syzbot reports kernel infoleak at vcs_read() [1], for buffer can be read
immediately after resize operation. Initialize buffer using kzalloc().

  ----------
  #include &lt;fcntl.h&gt;
  #include &lt;unistd.h&gt;
  #include &lt;sys/ioctl.h&gt;
  #include &lt;linux/fb.h&gt;

  int main(int argc, char *argv[])
  {
    struct fb_var_screeninfo var = { };
    const int fb_fd = open("/dev/fb0", 3);
    ioctl(fb_fd, FBIOGET_VSCREENINFO, &amp;var);
    var.yres = 0x21;
    ioctl(fb_fd, FBIOPUT_VSCREENINFO, &amp;var);
    return read(open("/dev/vcsu", O_RDONLY), &amp;var, sizeof(var)) == -1;
  }
  ----------</Note>
    </Notes>
    <CVE>CVE-2022-50222</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: bcd2000: Fix a UAF bug on the error path of probing

When the driver fails in snd_card_register() at probe time, it will free
the 'bcd2k-&gt;midi_out_urb' before killing it, which may cause a UAF bug.

The following log can reveal it:

[   50.727020] BUG: KASAN: use-after-free in bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000]
[   50.727623] Read of size 8 at addr ffff88810fab0e88 by task swapper/4/0
[   50.729530] Call Trace:
[   50.732899]  bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000]

Fix this by adding usb_kill_urb() before usb_free_urb().</Note>
    </Notes>
    <CVE>CVE-2022-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:

crypto: arm64/poly1305 - fix a read out-of-bound

A kasan error was reported during fuzzing:

BUG: KASAN: slab-out-of-bounds in neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon]
Read of size 4 at addr ffff0010e293f010 by task syz-executor.5/1646715
CPU: 4 PID: 1646715 Comm: syz-executor.5 Kdump: loaded Not tainted 5.10.0.aarch64 #1
Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.59 01/31/2019
Call trace:
 dump_backtrace+0x0/0x394
 show_stack+0x34/0x4c arch/arm64/kernel/stacktrace.c:196
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x158/0x1e4 lib/dump_stack.c:118
 print_address_description.constprop.0+0x68/0x204 mm/kasan/report.c:387
 __kasan_report+0xe0/0x140 mm/kasan/report.c:547
 kasan_report+0x44/0xe0 mm/kasan/report.c:564
 check_memory_region_inline mm/kasan/generic.c:187 [inline]
 __asan_load4+0x94/0xd0 mm/kasan/generic.c:252
 neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon]
 neon_poly1305_do_update+0x6c/0x15c [poly1305_neon]
 neon_poly1305_update+0x9c/0x1c4 [poly1305_neon]
 crypto_shash_update crypto/shash.c:131 [inline]
 shash_finup_unaligned+0x84/0x15c crypto/shash.c:179
 crypto_shash_finup+0x8c/0x140 crypto/shash.c:193
 shash_digest_unaligned+0xb8/0xe4 crypto/shash.c:201
 crypto_shash_digest+0xa4/0xfc crypto/shash.c:217
 crypto_shash_tfm_digest+0xb4/0x150 crypto/shash.c:229
 essiv_skcipher_setkey+0x164/0x200 [essiv]
 crypto_skcipher_setkey+0xb0/0x160 crypto/skcipher.c:612
 skcipher_setkey+0x3c/0x50 crypto/algif_skcipher.c:305
 alg_setkey+0x114/0x2a0 crypto/af_alg.c:220
 alg_setsockopt+0x19c/0x210 crypto/af_alg.c:253
 __sys_setsockopt+0x190/0x2e0 net/socket.c:2123
 __do_sys_setsockopt net/socket.c:2134 [inline]
 __se_sys_setsockopt net/socket.c:2131 [inline]
 __arm64_sys_setsockopt+0x78/0x94 net/socket.c:2131
 __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]
 invoke_syscall+0x64/0x100 arch/arm64/kernel/syscall.c:48
 el0_svc_common.constprop.0+0x220/0x230 arch/arm64/kernel/syscall.c:155
 do_el0_svc+0xb4/0xd4 arch/arm64/kernel/syscall.c:217
 el0_svc+0x24/0x3c arch/arm64/kernel/entry-common.c:353
 el0_sync_handler+0x160/0x164 arch/arm64/kernel/entry-common.c:369
 el0_sync+0x160/0x180 arch/arm64/kernel/entry.S:683

This error can be reproduced by the following code compiled as ko on a
system with kasan enabled:

#include &lt;linux/module.h&gt;
#include &lt;linux/crypto.h&gt;
#include &lt;crypto/hash.h&gt;
#include &lt;crypto/poly1305.h&gt;

char test_data[] = "\x00\x01\x02\x03\x04\x05\x06\x07"
                   "\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f"
                   "\x10\x11\x12\x13\x14\x15\x16\x17"
                   "\x18\x19\x1a\x1b\x1c\x1d\x1e";

int init(void)
{
        struct crypto_shash *tfm = NULL;
        char *data = NULL, *out = NULL;

        tfm = crypto_alloc_shash("poly1305", 0, 0);
        data = kmalloc(POLY1305_KEY_SIZE - 1, GFP_KERNEL);
        out = kmalloc(POLY1305_DIGEST_SIZE, GFP_KERNEL);
        memcpy(data, test_data, POLY1305_KEY_SIZE - 1);
        crypto_shash_tfm_digest(tfm, data, POLY1305_KEY_SIZE - 1, out);

        kfree(data);
        kfree(out);
        return 0;
}

void deinit(void)
{
}

module_init(init)
module_exit(deinit)
MODULE_LICENSE("GPL");

The root cause of the bug sits in neon_poly1305_blocks. The logic
neon_poly1305_blocks() performed is that if it was called with both s[]
and r[] uninitialized, it will first try to initialize them with the
data from the first "block" that it believed to be 32 bytes in length.
First 16 bytes are used as the key and the next 16 bytes for s[]. This
would lead to the aforementioned read out-of-bound. However, after
calling poly1305_init_arch(), only 16 bytes were deducted from the input
and s[] is initialized yet again with the following 16 bytes. The second
initialization of s[] is certainly redundent which indicates that the
first initialization should be for r[] only.

This patch fixes the issue by calling poly1305_init_arm64() instead o
---truncated---</Note>
    </Notes>
    <CVE>CVE-2022-50231</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 was found in compare_netdev_and_ip in drivers/infiniband/core/cma.c in RDMA in the Linux Kernel. The improper cleanup results in out-of-boundary read, where a local user can utilize this problem to crash the system or escalation of privilege.</Note>
    </Notes>
    <CVE>CVE-2023-2176</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 allocation of resources without limits or throttling vulnerability exists in curl &lt;v7.88.0 based on the "chained" HTTP compression algorithms, meaning that a server response can be compressed multiple times and potentially with differentalgorithms. The number of acceptable "links" in this "decompression chain" wascapped, but the cap was implemented on a per-header basis allowing a maliciousserver to insert a virtually unlimited number of compression steps simply byusing many headers. The use of such a decompression chain could result in a "malloc bomb", making curl end up spending enormous amounts of allocated heap memory, or trying to and returning out of memory errors.</Note>
    </Notes>
    <CVE>CVE-2023-23916</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 in input validation exists in curl &lt;8.0 during communication using the TELNET protocol may allow an attacker to pass on maliciously crafted user name and "telnet options" during server negotiation. The lack of proper input scrubbing allows an attacker to send content or perform option negotiation without the application's intent. This vulnerability could be exploited if an application allows user input, thereby enabling attackers to execute arbitrary code on the system.</Note>
    </Notes>
    <CVE>CVE-2023-27533</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A path traversal vulnerability exists in curl &lt;8.0.0 SFTP implementation causes the tilde (~) character to be wrongly replaced when used as a prefix in the first path element, in addition to its intended use as the first element to indicate a path relative to the user's home directory. Attackers can exploit this flaw to bypass filtering or execute arbitrary code by crafting a path like /~2/foo while accessing a server with a specific user.</Note>
    </Notes>
    <CVE>CVE-2023-27534</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 authentication bypass vulnerability exists in libcurl &lt;8.0.0 in the FTP connection reuse feature that can result in wrong credentials being used during subsequent transfers. Previously created connections are kept in a connection pool for reuse if they match the current setup. However, certain FTP settings such as CURLOPT_FTP_ACCOUNT, CURLOPT_FTP_ALTERNATIVE_TO_USER, CURLOPT_FTP_SSL_CCC, and CURLOPT_USE_SSL were not included in the configuration match checks, causing them to match too easily. This could lead to libcurl using the wrong credentials when performing a transfer, potentially allowing unauthorized access to sensitive information.</Note>
    </Notes>
    <CVE>CVE-2023-27535</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 authentication bypass vulnerability exists libcurl &lt;8.0.0 in the connection reuse feature which can reuse previously established connections with incorrect user permissions due to a failure to check for changes in the CURLOPT_GSSAPI_DELEGATION option. This vulnerability affects krb5/kerberos/negotiate/GSSAPI transfers and could potentially result in unauthorized access to sensitive information. The safest option is to not reuse connections if the CURLOPT_GSSAPI_DELEGATION option has been changed.</Note>
    </Notes>
    <CVE>CVE-2023-27536</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 authentication bypass vulnerability exists in libcurl prior to v8.0.0 where it reuses a previously established SSH connection despite the fact that an SSH option was modified, which should have prevented reuse. libcurl maintains a pool of previously used connections to reuse them for subsequent transfers if the configurations match. However, two SSH settings were omitted from the configuration check, allowing them to match easily, potentially leading to the reuse of an inappropriate connection.</Note>
    </Notes>
    <CVE>CVE-2023-27538</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 denial of service vulnerability exists in curl &lt;v8.1.0 in the way libcurl provides several different backends for resolving host names, selected at build time. If it is built to use the synchronous resolver, it allows name resolves to time-out slow operations using `alarm()` and `siglongjmp()`. When doing this, libcurl used a global buffer that was not mutex protected and a multi-threaded application might therefore crash or otherwise misbehave.</Note>
    </Notes>
    <CVE>CVE-2023-28320</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 improper certificate validation vulnerability exists in curl &lt;v8.1.0 in the way it supports matching of wildcard patterns when listed as "Subject Alternative Name" in TLS server certificates. curl can be built to use its own name matching function for TLS rather than one provided by a TLS library. This private wildcard matching function would match IDN (International Domain Name) hosts incorrectly and could as a result accept patterns that otherwise should mismatch. IDN hostnames are converted to puny code before used for certificate checks. Puny coded names always start with `xn--` and should not be allowed to pattern match, but the wildcard check in curl could still check for `x*`, which would match even though the IDN name most likely contained nothing even resembling an `x`.</Note>
    </Notes>
    <CVE>CVE-2023-28321</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 information disclosure vulnerability exists in curl &lt;v8.1.0 when doing HTTP(S) transfers, libcurl might erroneously use the read callback (`CURLOPT_READFUNCTION`) to ask for data to send, even when the `CURLOPT_POSTFIELDS` option has been set, if the same handle previously wasused to issue a `PUT` request which used that callback. This flaw may surprise the application and cause it to misbehave and either send off the wrong data or use memory after free or similar in the second transfer. The problem exists in the logic for a reused handle when it is (expected to be) changed from a PUT to a POST.</Note>
    </Notes>
    <CVE>CVE-2023-28322</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 was found in prepare_to_relocate in fs/btrfs/relocation.c in btrfs in the Linux Kernel. This possible flaw can be triggered by calling btrfs_ioctl_balance() before calling btrfs_ioctl_defrag().</Note>
    </Notes>
    <CVE>CVE-2023-3111</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 flaw allows an attacker to insert cookies at will into a running program
using libcurl, if the specific series of conditions are met.

libcurl performs transfers. In its API, an application creates "easy handles"
that are the individual handles for single transfers.

libcurl provides a function call that duplicates en easy handle called
[curl_easy_duphandle](https://curl.se/libcurl/c/curl_easy_duphandle.html).

If a transfer has cookies enabled when the handle is duplicated, the
cookie-enable state is also cloned - but without cloning the actual
cookies. If the source handle did not read any cookies from a specific file on
disk, the cloned version of the handle would instead store the file name as
`none` (using the four ASCII letters, no quotes).

Subsequent use of the cloned handle that does not explicitly set a source to
load cookies from would then inadvertently load cookies from a file named
`none` - if such a file exists and is readable in the current directory of the
program using libcurl. And if using the correct file format of course.</Note>
    </Notes>
    <CVE>CVE-2023-38546</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 flaw allows a malicious HTTP server to set "super cookies" in curl that
are then passed back to more origins than what is otherwise allowed or
possible. This allows a site to set cookies that then would get sent to
different and unrelated sites and domains.

It could do this by exploiting a mixed case flaw in curl's function that
verifies a given cookie domain against the Public Suffix List (PSL). For
example a cookie could be set with `domain=co.UK` when the URL used a lower
case hostname `curl.co.uk`, even though `co.uk` is listed as a PSL domain.</Note>
    </Notes>
    <CVE>CVE-2023-46218</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: adapt set backend to use GC transaction API

Use the GC transaction API to replace the old and buggy gc API and the
busy mark approach.

No set elements are removed from async garbage collection anymore,
instead the _DEAD bit is set on so the set element is not visible from
lookup path anymore. Async GC enqueues transaction work that might be
aborted and retried later.

rbtree and pipapo set backends does not set on the _DEAD bit from the
sync GC path since this runs in control plane path where mutex is held.
In this case, set elements are deactivated, removed and then released
via RCU callback, sync GC never fails.</Note>
    </Notes>
    <CVE>CVE-2023-52923</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: allow exp not to be removed in nf_ct_find_expectation

Currently nf_conntrack_in() calling nf_ct_find_expectation() will
remove the exp from the hash table. However, in some scenario, we
expect the exp not to be removed when the created ct will not be
confirmed, like in OVS and TC conntrack in the following patches.

This patch allows exp not to be removed by setting IPS_CONFIRMED
in the status of the tmpl.</Note>
    </Notes>
    <CVE>CVE-2023-52927</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 vulnerability was found in PAM. The secret information is stored in memory, where the attacker can trigger the victim program to execute by sending characters to its standard input (stdin). As this occurs, the attacker can train the branch predictor to execute an ROP chain speculatively. This flaw could result in leaked passwords, such as those found in /etc/shadow while performing authentications.</Note>
    </Notes>
    <CVE>CVE-2024-10041</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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">Allows modifying some file metadata (e.g. last modified) with filter="data"  or file permissions (chmod) with filter="tar"  of files outside the extraction directory.
You are affected by this vulnerability if using the tarfile  module to extract untrusted tar archives using TarFile.extractall()  or TarFile.extract()  using the filter=  parameter with a value of "data"  or "tar". See the tarfile  extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter   for more information. Only Python versions 3.12 or later are affected by these vulnerabilities, earlier versions don't include the extraction filter feature.

Note that for Python 3.14 or later the default value of filter=  changed from "no filtering" to `"data", so if you are relying on this new default behavior then your usage is also affected.

Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it's important to avoid installing source distributions with suspicious links.</Note>
    </Notes>
    <CVE>CVE-2024-12718</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 timing-based side-channel flaw was found in libgcrypt's RSA implementation. This issue may allow a remote attacker to initiate a Bleichenbacher-style attack, which can lead to the decryption of RSA ciphertexts.</Note>
    </Notes>
    <CVE>CVE-2024-2236</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 an application tells libcurl it wants to allow HTTP/2 server push, and the amount of received headers for the push surpasses the maximum allowed limit (1000), libcurl aborts the server push. When aborting, libcurl inadvertently does not free all the previously allocated headers and instead leaks the memory.  Further, this error condition fails silently and is therefore not easily detected by an application.</Note>
    </Notes>
    <CVE>CVE-2024-2398</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nft_set_pipapo: do not free live element

Pablo reports a crash with large batches of elements with a
back-to-back add/remove pattern.  Quoting Pablo:

  add_elem("00000000") timeout 100 ms
  ...
  add_elem("0000000X") timeout 100 ms
  del_elem("0000000X") &lt;---------------- delete one that was just added
  ...
  add_elem("00005000") timeout 100 ms

  1) nft_pipapo_remove() removes element 0000000X
  Then, KASAN shows a splat.

Looking at the remove function there is a chance that we will drop a
rule that maps to a non-deactivated element.

Removal happens in two steps, first we do a lookup for key k and return the
to-be-removed element and mark it as inactive in the next generation.
Then, in a second step, the element gets removed from the set/map.

The _remove function does not work correctly if we have more than one
element that share the same key.

This can happen if we insert an element into a set when the set already
holds an element with same key, but the element mapping to the existing
key has timed out or is not active in the next generation.

In such case its possible that removal will unmap the wrong element.
If this happens, we will leak the non-deactivated element, it becomes
unreachable.

The element that got deactivated (and will be freed later) will
remain reachable in the set data structure, this can result in
a crash when such an element is retrieved during lookup (stale
pointer).

Add a check that the fully matching key does in fact map to the element
that we have marked as inactive in the deactivation step.
If not, we need to continue searching.

Add a bug/warn trap at the end of the function as well, the remove
function must not ever be called with an invisible/unreachable/non-existent
element.

v2: avoid uneeded temporary variable (Stefano)</Note>
    </Notes>
    <CVE>CVE-2024-26924</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: use timestamp to check for set element timeout

Add a timestamp field at the beginning of the transaction, store it
in the nftables per-netns area.

Update set backend .insert, .deactivate and sync gc path to use the
timestamp, this avoids that an element expires while control plane
transaction is still unfinished.

.lookup and .update, which are used from packet path, still use the
current time to check if the element has expired. And .get path and dump
also since this runs lockless under rcu read size lock. Then, there is
async gc which also needs to check the current time since it runs
asynchronously from a workqueue.</Note>
    </Notes>
    <CVE>CVE-2024-27397</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Rubygems.org is the Ruby community's gem hosting service. A Gem publisher can cause a Remote DoS when publishing a Gem. This is due to how Ruby reads the Manifest of Gem files when using Gem::Specification.from_yaml. from_yaml makes use of SafeYAML.load which allows YAML aliases inside the YAML-based metadata of a gem. YAML aliases allow for Denial of Service attacks with so-called `YAML-bombs` (comparable to Billion laughs attacks). This was patched. There is is no action required by users. This issue is also tracked as GHSL-2024-001 and was discovered by the GitHub security lab.</Note>
    </Notes>
    <CVE>CVE-2024-35221</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sch_multiq: fix possible OOB write in multiq_tune()

q-&gt;bands will be assigned to qopt-&gt;bands to execute subsequent code logic
after kmalloc. So the old q-&gt;bands should not be used in kmalloc.
Otherwise, an out-of-bounds write will occur.</Note>
    </Notes>
    <CVE>CVE-2024-36978</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">Multiple methods in the salt master skip minion token validation. Therefore a misbehaving minion can impersonate another minion.</Note>
    </Notes>
    <CVE>CVE-2024-38822</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">Salt's request server is vulnerable to replay attacks when not using a TLS encrypted transport.</Note>
    </Notes>
    <CVE>CVE-2024-38823</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Directory traversal vulnerability in recv_file method allows arbitrary files to be written to the master cache directory.</Note>
    </Notes>
    <CVE>CVE-2024-38824</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">The salt.auth.pki module does not properly authenticate callers. The "password" field contains a public certificate which is validated against a CA certificate by the module. This is not pki authentication, as the caller does not need access to the corresponding private key for the authentication attempt to be accepted.</Note>
    </Notes>
    <CVE>CVE-2024-38825</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT

In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed
to be either root or ingress. This assumption is bogus since it's valid
to create egress qdiscs with major handle ffff:
Budimir Markovic found that for qdiscs like DRR that maintain an active
class list, it will cause a UAF with a dangling class pointer.

In 066a3b5b2346, the concern was to avoid iterating over the ingress
qdisc since its parent is itself. The proper fix is to stop when parent
TC_H_ROOT is reached because the only way to retrieve ingress is when a
hierarchy which does not contain a ffff: major handle call into
qdisc_lookup with TC_H_MAJ(TC_H_ROOT).

In the scenario where major ffff: is an egress qdisc in any of the tree
levels, the updates will also propagate to TC_H_ROOT, which then the
iteration must stop.


 net/sched/sch_api.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)</Note>
    </Notes>
    <CVE>CVE-2024-53057</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: ipset: add missing range check in bitmap_ip_uadt

When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists,
the values of ip and ip_to are slightly swapped. Therefore, the range check
for ip should be done later, but this part is missing and it seems that the
vulnerability occurs.

So we should add missing range checks and remove unnecessary range checks.</Note>
    </Notes>
    <CVE>CVE-2024-53141</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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 ordering of qlen adjustment

Changes to sch-&gt;q.qlen around qdisc_tree_reduce_backlog() need to happen
_before_ a call to said function because otherwise it may fail to notify
parent qdiscs when the child is about to become empty.</Note>
    </Notes>
    <CVE>CVE-2024-53164</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">GNU GRUB (aka GRUB2) through 2.12 does not use a constant-time algorithm for grub_crypto_memcmp and thus allows side-channel attacks.</Note>
    </Notes>
    <CVE>CVE-2024-56738</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: netem: account for backlog updates from child qdisc

In general, 'qlen' of any classful qdisc should keep track of the
number of packets that the qdisc itself and all of its children holds.
In case of netem, 'qlen' only accounts for the packets in its internal
tfifo. When netem is used with a child qdisc, the child qdisc can use
'qdisc_tree_reduce_backlog' to inform its parent, netem, about created
or dropped SKBs. This function updates 'qlen' and the backlog statistics
of netem, but netem does not account for changes made by a child qdisc.
'qlen' then indicates the wrong number of packets in the tfifo.
If a child qdisc creates new SKBs during enqueue and informs its parent
about this, netem's 'qlen' value is increased. When netem dequeues the
newly created SKBs from the child, the 'qlen' in netem is not updated.
If 'qlen' reaches the configured sch-&gt;limit, the enqueue function stops
working, even though the tfifo is not full.

Reproduce the bug:
Ensure that the sender machine has GSO enabled. Configure netem as root
qdisc and tbf as its child on the outgoing interface of the machine
as follows:
$ tc qdisc add dev &lt;oif&gt; root handle 1: netem delay 100ms limit 100
$ tc qdisc add dev &lt;oif&gt; parent 1:0 tbf rate 50Mbit burst 1542 latency 50ms

Send bulk TCP traffic out via this interface, e.g., by running an iPerf3
client on the machine. Check the qdisc statistics:
$ tc -s qdisc show dev &lt;oif&gt;

Statistics after 10s of iPerf3 TCP test before the fix (note that
netem's backlog &gt; limit, netem stopped accepting packets):
qdisc netem 1: root refcnt 2 limit 1000 delay 100ms
 Sent 2767766 bytes 1848 pkt (dropped 652, overlimits 0 requeues 0)
 backlog 4294528236b 1155p requeues 0
qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms
 Sent 2767766 bytes 1848 pkt (dropped 327, overlimits 7601 requeues 0)
 backlog 0b 0p requeues 0

Statistics after the fix:
qdisc netem 1: root refcnt 2 limit 1000 delay 100ms
 Sent 37766372 bytes 24974 pkt (dropped 9, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms
 Sent 37766372 bytes 24974 pkt (dropped 327, overlimits 96017 requeues 0)
 backlog 0b 0p requeues 0

tbf segments the GSO SKBs (tbf_segment) and updates the netem's 'qlen'.
The interface fully stops transferring packets and "locks". In this case,
the child qdisc and tfifo are empty, but 'qlen' indicates the tfifo is at
its limit and no more packets are accepted.

This patch adds a counter for the entries in the tfifo. Netem's 'qlen' is
only decreased when a packet is returned by its dequeue function, and not
during enqueuing into the child qdisc. External updates to 'qlen' are thus
accounted for and only the behavior of the backlog statistics changes. As
in other qdiscs, 'qlen' then keeps track of  how many packets are held in
netem and all of its children. As before, sch-&gt;limit remains as the
maximum number of packets in the tfifo. The same applies to netem's
backlog statistics.</Note>
    </Notes>
    <CVE>CVE-2024-56770</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_set_pipapo: fix initial map fill

The initial buffer has to be inited to all-ones, but it must restrict
it to the size of the first field, not the total field size.

After each round in the map search step, the result and the fill map
are swapped, so if we have a set where f-&gt;bsize of the first element
is smaller than m-&gt;bsize_max, those one-bits are leaked into future
rounds result map.

This makes pipapo find an incorrect matching results for sets where
first field size is not the largest.

Followup patch adds a test case to nft_concat_range.sh selftest script.

Thanks to Stefano Brivio for pointing out that we need to zero out
the remainder explicitly, only correcting memset() argument isn't enough.</Note>
    </Notes>
    <CVE>CVE-2024-57947</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">libcurl's ASN1 parser code has the `GTime2str()` function, used for parsing an
ASN.1 Generalized Time field. If given an syntactically incorrect field, the
parser might end up using -1 for the length of the *time fraction*, leading to
a `strlen()` getting performed on a pointer to a heap buffer area that is not
(purposely) null terminated.

This flaw most likely leads to a crash, but can also lead to heap contents
getting returned to the application when
[CURLINFO_CERTINFO](https://curl.se/libcurl/c/CURLINFO_CERTINFO.html) is used.</Note>
    </Notes>
    <CVE>CVE-2024-7264</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 told to use the Certificate Status Request TLS extension, often referred to as OCSP stapling, to verify that the server certificate is valid, it might fail to detect some OCSP problems and instead wrongly consider the response as fine.  If the returned status reports another error than 'revoked' (like for example 'unauthorized') it is not treated as a bad certficate.</Note>
    </Notes>
    <CVE>CVE-2024-8096</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 use a `.netrc` file for credentials **and** to follow HTTP
redirects, curl could leak the password used for the first host to the
followed-to host under certain circumstances.

This flaw only manifests itself if the netrc file has a `default` entry that
omits both login and password. A rare circumstance.</Note>
    </Notes>
    <CVE>CVE-2025-0167</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Buildx is a Docker CLI plugin that extends build capabilities using BuildKit.

Cache backends support credentials by setting secrets directly as attribute values in cache-to/cache-from  configuration. When supplied as user input, these secure values may be inadvertently captured in OpenTelemetry traces as part of the arguments and flags for the traced CLI command.  OpenTelemetry traces are also saved in BuildKit daemon's history records.


This vulnerability does not impact secrets passed to the Github cache backend  via environment variables or registry authentication.</Note>
    </Notes>
    <CVE>CVE-2025-0495</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 libcurl is asked to perform automatic gzip decompression of
content-encoded HTTP responses with the `CURLOPT_ACCEPT_ENCODING` option,
**using zlib 1.2.0.3 or older**, an attacker-controlled integer overflow would
make libcurl perform a buffer overflow.</Note>
    </Notes>
    <CVE>CVE-2025-0725</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">curl's websocket code did not update the 32 bit mask pattern for each new
 outgoing frame as the specification says. Instead it used a fixed mask that
persisted and was used throughout the entire connection.

A predictable mask pattern allows for a malicious server to induce traffic
between the two communicating parties that could be interpreted by an involved
proxy (configured or transparent) as genuine, real, HTTP traffic with content
and thereby poison its cache. That cached poisoned content could then be
served to all users of that proxy.</Note>
    </Notes>
    <CVE>CVE-2025-10148</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Disallow replacing of child qdisc from one parent to another

Lion Ackermann was able to create a UAF which can be abused for privilege
escalation with the following script

Step 1. create root qdisc
tc qdisc add dev lo root handle 1:0 drr

step2. a class for packet aggregation do demonstrate uaf
tc class add dev lo classid 1:1 drr

step3. a class for nesting
tc class add dev lo classid 1:2 drr

step4. a class to graft qdisc to
tc class add dev lo classid 1:3 drr

step5.
tc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024

step6.
tc qdisc add dev lo parent 1:2 handle 3:0 drr

step7.
tc class add dev lo classid 3:1 drr

step 8.
tc qdisc add dev lo parent 3:1 handle 4:0 pfifo

step 9. Display the class/qdisc layout

tc class ls dev lo
 class drr 1:1 root leaf 2: quantum 64Kb
 class drr 1:2 root leaf 3: quantum 64Kb
 class drr 3:1 root leaf 4: quantum 64Kb

tc qdisc ls
 qdisc drr 1: dev lo root refcnt 2
 qdisc plug 2: dev lo parent 1:1
 qdisc pfifo 4: dev lo parent 3:1 limit 1000p
 qdisc drr 3: dev lo parent 1:2

step10. trigger the bug &lt;=== prevented by this patch
tc qdisc replace dev lo parent 1:3 handle 4:0

step 11. Redisplay again the qdiscs/classes

tc class ls dev lo
 class drr 1:1 root leaf 2: quantum 64Kb
 class drr 1:2 root leaf 3: quantum 64Kb
 class drr 1:3 root leaf 4: quantum 64Kb
 class drr 3:1 root leaf 4: quantum 64Kb

tc qdisc ls
 qdisc drr 1: dev lo root refcnt 2
 qdisc plug 2: dev lo parent 1:1
 qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p
 qdisc drr 3: dev lo parent 1:2

Observe that a) parent for 4:0 does not change despite the replace request.
There can only be one parent.  b) refcount has gone up by two for 4:0 and
c) both class 1:3 and 3:1 are pointing to it.

Step 12.  send one packet to plug
echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001))
step13.  send one packet to the grafted fifo
echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003))

step14. lets trigger the uaf
tc class delete dev lo classid 1:3
tc class delete dev lo classid 1:1

The semantics of "replace" is for a del/add _on the same node_ and not
a delete from one node(3:1) and add to another node (1:3) as in step10.
While we could "fix" with a more complex approach there could be
consequences to expectations so the patch takes the preventive approach of
"disallow such config".

Joint work with Lion Ackermann &lt;nnamrec@gmail.com&gt;</Note>
    </Notes>
    <CVE>CVE-2025-21700</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pfifo_tail_enqueue: Drop new packet when sch-&gt;limit == 0

Expected behaviour:
In case we reach scheduler's limit, pfifo_tail_enqueue() will drop a
packet in scheduler's queue and decrease scheduler's qlen by one.
Then, pfifo_tail_enqueue() enqueue new packet and increase
scheduler's qlen by one. Finally, pfifo_tail_enqueue() return
`NET_XMIT_CN` status code.

Weird behaviour:
In case we set `sch-&gt;limit == 0` and trigger pfifo_tail_enqueue() on a
scheduler that has no packet, the 'drop a packet' step will do nothing.
This means the scheduler's qlen still has value equal 0.
Then, we continue to enqueue new packet and increase scheduler's qlen by
one. In summary, we can leverage pfifo_tail_enqueue() to increase qlen by
one and return `NET_XMIT_CN` status code.

The problem is:
Let's say we have two qdiscs: Qdisc_A and Qdisc_B.
 - Qdisc_A's type must have '-&gt;graft()' function to create parent/child relationship.
   Let's say Qdisc_A's type is `hfsc`. Enqueue packet to this qdisc will trigger `hfsc_enqueue`.
 - Qdisc_B's type is pfifo_head_drop. Enqueue packet to this qdisc will trigger `pfifo_tail_enqueue`.
 - Qdisc_B is configured to have `sch-&gt;limit == 0`.
 - Qdisc_A is configured to route the enqueued's packet to Qdisc_B.

Enqueue packet through Qdisc_A will lead to:
 - hfsc_enqueue(Qdisc_A) -&gt; pfifo_tail_enqueue(Qdisc_B)
 - Qdisc_B-&gt;q.qlen += 1
 - pfifo_tail_enqueue() return `NET_XMIT_CN`
 - hfsc_enqueue() check for `NET_XMIT_SUCCESS` and see `NET_XMIT_CN` =&gt; hfsc_enqueue() don't increase qlen of Qdisc_A.

The whole process lead to a situation where Qdisc_A-&gt;q.qlen == 0 and Qdisc_B-&gt;q.qlen == 1.
Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem.
This violate the design where parent's qlen should equal to the sum of its childrens'qlen.

Bug impact: This issue can be used for user-&gt;kernel privilege escalation when it is reachable.</Note>
    </Notes>
    <CVE>CVE-2025-21702</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:

netem: Update sch-&gt;q.qlen before qdisc_tree_reduce_backlog()

qdisc_tree_reduce_backlog() notifies parent qdisc only if child
qdisc becomes empty, therefore we need to reduce the backlog of the
child qdisc before calling it. Otherwise it would miss the opportunity
to call cops-&gt;qlen_notify(), in the case of DRR, it resulted in UAF
since DRR uses -&gt;qlen_notify() to maintain its active list.</Note>
    </Notes>
    <CVE>CVE-2025-21703</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">Minion event bus authorization bypass. An attacker with access to a minion key can craft a message which may be able to execute a job on other minions (&gt;= 3007.0).</Note>
    </Notes>
    <CVE>CVE-2025-22236</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 attacker with access to a minion key can exploit the 'on demand' pillar functionality with a specially crafted git url which could cause and arbitrary command to be run on the master with the same privileges as the master process.</Note>
    </Notes>
    <CVE>CVE-2025-22237</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Directory traversal attack in minion file cache creation. The master's default cache is vulnerable to a directory traversal attack. Which could be leveraged to write or overwrite 'cache' files outside of the cache directory.</Note>
    </Notes>
    <CVE>CVE-2025-22238</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Arbitrary event injection on Salt Master. The master's "_minion_event" method can be used by and authorized minion to send arbitrary events onto the master's event bus.</Note>
    </Notes>
    <CVE>CVE-2025-22239</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">Arbitrary directory creation or file deletion. In the find_file method of the GitFS class, a path is created using os.path.join using unvalidated input from the “tgt_env” variable. This can be exploited by an attacker to delete any file on the Master's process has permissions to.</Note>
    </Notes>
    <CVE>CVE-2025-22240</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">File contents overwrite the VirtKey class is called when “on-demand pillar” data is requested and uses un-validated input to create paths to the “pki directory”. The functionality is used to auto-accept Minion authentication keys based on a pre-placed “authorization file” at a specific location and is present in the default configuration.</Note>
    </Notes>
    <CVE>CVE-2025-22241</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Worker process denial of service through file read operation. .A vulnerability exists in the Master's “pub_ret” method which is exposed to all minions. The un-sanitized input value “jid” is used to construct a path which is then opened for reading. An attacker could exploit this vulnerabilities by attempting to read from a filename that will not return any data, e.g. by targeting a pipe node on the proc file system.</Note>
    </Notes>
    <CVE>CVE-2025-22242</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 attacker can pass a malicious malformed token which causes unexpected memory to be consumed during parsing.</Note>
    </Notes>
    <CVE>CVE-2025-22868</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">SSH servers which implement file transfer protocols are vulnerable to a denial of service attack from clients which complete the key exchange slowly, or not at all, causing pending content to be read into memory, but never transmitted.</Note>
    </Notes>
    <CVE>CVE-2025-22869</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">The tokenizer incorrectly interprets tags with unquoted attribute values that end with a solidus character (/) as self-closing. When directly using Tokenizer, this can result in such tags incorrectly being marked as self-closing, and when using the Parse functions, this can result in content following such tags as being placed in the wrong scope during DOM construction, but only when tags are in foreign content (e.g. &lt;math&gt;, &lt;svg&gt;, etc contexts).</Note>
    </Notes>
    <CVE>CVE-2025-22872</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the URI gem before 1.0.3 for Ruby, the URI handling methods (URI.join, URI#merge, URI#+) have an inadvertent leakage of authentication credentials because userinfo is retained even after changing the host.</Note>
    </Notes>
    <CVE>CVE-2025-27221</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Certain instructions need intercepting and emulating by Xen.  In some
cases Xen emulates the instruction by replaying it, using an executable
stub.  Some instructions may raise an exception, which is supposed to be
handled gracefully.  Certain replayed instructions have additional logic
to set up and recover the changes to the arithmetic flags.

For replayed instructions where the flags recovery logic is used, the
metadata for exception handling was incorrect, preventing Xen from
handling the the exception gracefully, treating it as fatal instead.</Note>
    </Notes>
    <CVE>CVE-2025-27465</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 GnuTLS. A double-free vulnerability exists in GnuTLS due to incorrect ownership handling in the export logic of Subject Alternative Name (SAN) entries containing an otherName. If the type-id OID is invalid or malformed, GnuTLS will call asn1_delete_structure() on an ASN.1 node it does not own, leading to a double-free condition when the parent function or caller later attempts to free the same structure.

This vulnerability can be triggered using only public GnuTLS APIs and may result in denial of service or memory corruption, depending on allocator behavior.</Note>
    </Notes>
    <CVE>CVE-2025-32988</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 heap-buffer-overflow (off-by-one) flaw was found in the GnuTLS software in the template parsing logic within the certtool utility. When it reads certain settings from a template file, it allows an attacker to cause an out-of-bounds (OOB) NULL pointer write, resulting in memory corruption and a denial-of-service (DoS) that could potentially crash the system.</Note>
    </Notes>
    <CVE>CVE-2025-32990</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 in the MIT Kerberos implementation allows GSSAPI-protected messages using RC4-HMAC-MD5 to be spoofed due to weaknesses in the MD5 checksum design. If RC4 is preferred over stronger encryption types, an attacker could exploit MD5 collisions to forge message integrity codes. This may lead to unauthorized message tampering.</Note>
    </Notes>
    <CVE>CVE-2025-3576</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: hfsc: Fix a UAF vulnerability in class handling

This patch fixes a Use-After-Free vulnerability in the HFSC qdisc class
handling. The issue occurs due to a time-of-check/time-of-use condition
in hfsc_change_class() when working with certain child qdiscs like netem
or codel.

The vulnerability works as follows:
1. hfsc_change_class() checks if a class has packets (q.qlen != 0)
2. It then calls qdisc_peek_len(), which for certain qdiscs (e.g.,
   codel, netem) might drop packets and empty the queue
3. The code continues assuming the queue is still non-empty, adding
   the class to vttree
4. This breaks HFSC scheduler assumptions that only non-empty classes
   are in vttree
5. Later, when the class is destroyed, this can lead to a Use-After-Free

The fix adds a second queue length check after qdisc_peek_len() to verify
the queue wasn't emptied.</Note>
    </Notes>
    <CVE>CVE-2025-37797</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:

codel: remove sch-&gt;q.qlen check before qdisc_tree_reduce_backlog()

After making all -&gt;qlen_notify() callbacks idempotent, now it is safe to
remove the check of qlen!=0 from both fq_codel_dequeue() and
codel_qdisc_dequeue().</Note>
    </Notes>
    <CVE>CVE-2025-37798</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: hfsc: Fix a potential UAF in hfsc_dequeue() too

Similarly to the previous patch, we need to safe guard hfsc_dequeue()
too. But for this one, we don't have a reliable reproducer.</Note>
    </Notes>
    <CVE>CVE-2025-37823</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: hfsc: Fix a UAF vulnerability in class with netem as child qdisc

As described in Gerrard's report [1], we have a UAF case when an hfsc class
has a netem child qdisc. The crux of the issue is that hfsc is assuming
that checking for cl-&gt;qdisc-&gt;q.qlen == 0 guarantees that it hasn't inserted
the class in the vttree or eltree (which is not true for the netem
duplicate case).

This patch checks the n_active class variable to make sure that the code
won't insert the class in the vttree or eltree twice, catering for the
reentrant case.

[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/</Note>
    </Notes>
    <CVE>CVE-2025-37890</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: ipset: fix region locking in hash types

Region locking introduced in v5.6-rc4 contained three macros to handle
the region locks: ahash_bucket_start(), ahash_bucket_end() which gave
back the start and end hash bucket values belonging to a given region
lock and ahash_region() which should give back the region lock belonging
to a given hash bucket. The latter was incorrect which can lead to a
race condition between the garbage collector and adding new elements
when a hash type of set is defined with timeouts.</Note>
    </Notes>
    <CVE>CVE-2025-37997</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:

sch_hfsc: Fix qlen accounting bug when using peek in hfsc_enqueue()

When enqueuing the first packet to an HFSC class, hfsc_enqueue() calls the
child qdisc's peek() operation before incrementing sch-&gt;q.qlen and
sch-&gt;qstats.backlog. If the child qdisc uses qdisc_peek_dequeued(), this may
trigger an immediate dequeue and potential packet drop. In such cases,
qdisc_tree_reduce_backlog() is called, but the HFSC qdisc's qlen and backlog
have not yet been updated, leading to inconsistent queue accounting. This
can leave an empty HFSC class in the active list, causing further
consequences like use-after-free.

This patch fixes the bug by moving the increment of sch-&gt;q.qlen and
sch-&gt;qstats.backlog before the call to the child qdisc's peek() operation.
This ensures that queue length and backlog are always accurate when packet
drops or dequeues are triggered during the peek.</Note>
    </Notes>
    <CVE>CVE-2025-38000</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: hfsc: Address reentrant enqueue adding class to eltree twice

Savino says:
    "We are writing to report that this recent patch
    (141d34391abbb315d68556b7c67ad97885407547) [1]
    can be bypassed, and a UAF can still occur when HFSC is utilized with
    NETEM.

    The patch only checks the cl-&gt;cl_nactive field to determine whether
    it is the first insertion or not [2], but this field is only
    incremented by init_vf [3].

    By using HFSC_RSC (which uses init_ed) [4], it is possible to bypass the
    check and insert the class twice in the eltree.
    Under normal conditions, this would lead to an infinite loop in
    hfsc_dequeue for the reasons we already explained in this report [5].

    However, if TBF is added as root qdisc and it is configured with a
    very low rate,
    it can be utilized to prevent packets from being dequeued.
    This behavior can be exploited to perform subsequent insertions in the
    HFSC eltree and cause a UAF."

To fix both the UAF and the infinite loop, with netem as an hfsc child,
check explicitly in hfsc_enqueue whether the class is already in the eltree
whenever the HFSC_RSC flag is set.

[1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547
[2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1572
[3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677
[4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574
[5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u</Note>
    </Notes>
    <CVE>CVE-2025-38001</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:

crypto: algif_hash - fix double free in hash_accept

If accept(2) is called on socket type algif_hash with
MSG_MORE flag set and crypto_ahash_import fails,
sk2 is freed. However, it is also freed in af_alg_release,
leading to slab-use-after-free error.</Note>
    </Notes>
    <CVE>CVE-2025-38079</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: prio: fix a race in prio_tune()

Gerrard Tai reported a race condition in PRIO, whenever SFQ perturb timer
fires at the wrong time.

The race is as follows:

CPU 0                                 CPU 1
[1]: lock root
[2]: qdisc_tree_flush_backlog()
[3]: unlock root
 |
 |                                    [5]: lock root
 |                                    [6]: rehash
 |                                    [7]: qdisc_tree_reduce_backlog()
 |
[4]: qdisc_put()

This can be abused to underflow a parent's qlen.

Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()
should fix the race, because all packets will be purged from the qdisc
before releasing the lock.</Note>
    </Notes>
    <CVE>CVE-2025-38083</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:

calipso: Fix null-ptr-deref in calipso_req_{set,del}attr().

syzkaller reported a null-ptr-deref in sock_omalloc() while allocating
a CALIPSO option.  [0]

The NULL is of struct sock, which was fetched by sk_to_full_sk() in
calipso_req_setattr().

Since commit a1a5344ddbe8 ("tcp: avoid two atomic ops for syncookies"),
reqsk-&gt;rsk_listener could be NULL when SYN Cookie is returned to its
client, as hinted by the leading SYN Cookie log.

Here are 3 options to fix the bug:

  1) Return 0 in calipso_req_setattr()
  2) Return an error in calipso_req_setattr()
  3) Alaways set rsk_listener

1) is no go as it bypasses LSM, but 2) effectively disables SYN Cookie
for CALIPSO.  3) is also no go as there have been many efforts to reduce
atomic ops and make TCP robust against DDoS.  See also commit 3b24d854cb35
("tcp/dccp: do not touch listener sk_refcnt under synflood").

As of the blamed commit, SYN Cookie already did not need refcounting,
and no one has stumbled on the bug for 9 years, so no CALIPSO user will
care about SYN Cookie.

Let's return an error in calipso_req_setattr() and calipso_req_delattr()
in the SYN Cookie case.

This can be reproduced by [1] on Fedora and now connect() of nc times out.

[0]:
TCP: request_sock_TCPv6: Possible SYN flooding on port [::]:20002. Sending cookies.
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
CPU: 3 UID: 0 PID: 12262 Comm: syz.1.2611 Not tainted 6.14.0 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
RIP: 0010:read_pnet include/net/net_namespace.h:406 [inline]
RIP: 0010:sock_net include/net/sock.h:655 [inline]
RIP: 0010:sock_kmalloc+0x35/0x170 net/core/sock.c:2806
Code: 89 d5 41 54 55 89 f5 53 48 89 fb e8 25 e3 c6 fd e8 f0 91 e3 00 48 8d 7b 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 &lt;80&gt; 3c 02 00 0f 85 26 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b
RSP: 0018:ffff88811af89038 EFLAGS: 00010216
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff888105266400
RDX: 0000000000000006 RSI: ffff88800c890000 RDI: 0000000000000030
RBP: 0000000000000050 R08: 0000000000000000 R09: ffff88810526640e
R10: ffffed1020a4cc81 R11: ffff88810526640f R12: 0000000000000000
R13: 0000000000000820 R14: ffff888105266400 R15: 0000000000000050
FS:  00007f0653a07640(0000) GS:ffff88811af80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f863ba096f4 CR3: 00000000163c0005 CR4: 0000000000770ef0
PKRU: 80000000
Call Trace:
 &lt;IRQ&gt;
 ipv6_renew_options+0x279/0x950 net/ipv6/exthdrs.c:1288
 calipso_req_setattr+0x181/0x340 net/ipv6/calipso.c:1204
 calipso_req_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:597
 netlbl_req_setattr+0x18a/0x440 net/netlabel/netlabel_kapi.c:1249
 selinux_netlbl_inet_conn_request+0x1fb/0x320 security/selinux/netlabel.c:342
 selinux_inet_conn_request+0x1eb/0x2c0 security/selinux/hooks.c:5551
 security_inet_conn_request+0x50/0xa0 security/security.c:4945
 tcp_v6_route_req+0x22c/0x550 net/ipv6/tcp_ipv6.c:825
 tcp_conn_request+0xec8/0x2b70 net/ipv4/tcp_input.c:7275
 tcp_v6_conn_request+0x1e3/0x440 net/ipv6/tcp_ipv6.c:1328
 tcp_rcv_state_process+0xafa/0x52b0 net/ipv4/tcp_input.c:6781
 tcp_v6_do_rcv+0x8a6/0x1a40 net/ipv6/tcp_ipv6.c:1667
 tcp_v6_rcv+0x505e/0x5b50 net/ipv6/tcp_ipv6.c:1904
 ip6_protocol_deliver_rcu+0x17c/0x1da0 net/ipv6/ip6_input.c:436
 ip6_input_finish+0x103/0x180 net/ipv6/ip6_input.c:480
 NF_HOOK include/linux/netfilter.h:314 [inline]
 NF_HOOK include/linux/netfilter.h:308 [inline]
 ip6_input+0x13c/0x6b0 net/ipv6/ip6_input.c:491
 dst_input include/net/dst.h:469 [inline]
 ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline]
 ip6_rcv_finish+0xb6/0x490 net/ipv6/ip6_input.c:69
 NF_HOOK include/linux/netfilter.h:314 [inline]
 NF_HOOK include/linux/netf
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-38181</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:

i40e: fix MMIO write access to an invalid page in i40e_clear_hw

When the device sends a specific input, an integer underflow can occur, leading
to MMIO write access to an invalid page.

Prevent the integer underflow by changing the type of related variables.</Note>
    </Notes>
    <CVE>CVE-2025-38200</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipc: fix to protect IPCS lookups using RCU

syzbot reported that it discovered a use-after-free vulnerability, [0]

[0]: https://lore.kernel.org/all/67af13f8.050a0220.21dd3.0038.GAE@google.com/

idr_for_each() is protected by rwsem, but this is not enough.  If it is
not protected by RCU read-critical region, when idr_for_each() calls
radix_tree_node_free() through call_rcu() to free the radix_tree_node
structure, the node will be freed immediately, and when reading the next
node in radix_tree_for_each_slot(), the already freed memory may be read.

Therefore, we need to add code to make sure that idr_for_each() is
protected within the RCU read-critical region when we call it in
shm_destroy_orphaned().</Note>
    </Notes>
    <CVE>CVE-2025-38212</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-2025-38213</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Prevent overflow in size calculation for memdup_user()

Number of apqn target list entries contained in 'nr_apqns' variable is
determined by userspace via an ioctl call so the result of the product in
calculation of size passed to memdup_user() may overflow.

In this case the actual size of the allocated area and the value
describing it won't be in sync leading to various types of unpredictable
behaviour later.

Use a proper memdup_array_user() helper which returns an error if an
overflow is detected. Note that it is different from when nr_apqns is
initially zero - that case is considered valid and should be handled in
subsequent pkey_handler implementations.

Found by Linux Verification Center (linuxtesting.org).</Note>
    </Notes>
    <CVE>CVE-2025-38257</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: do not bypass hid_hw_raw_request

hid_hw_raw_request() is actually useful to ensure the provided buffer
and length are valid. Directly calling in the low level transport driver
function bypassed those checks and allowed invalid paramto be used.</Note>
    </Notes>
    <CVE>CVE-2025-38494</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: ensure the allocated report buffer can contain the reserved report ID

When the report ID is not used, the low level transport drivers expect
the first byte to be 0. However, currently the allocated buffer not
account for that extra byte, meaning that instead of having 8 guaranteed
bytes for implement to be working, we only have 7.</Note>
    </Notes>
    <CVE>CVE-2025-38495</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: Fix OOB read on empty string write

When writing an empty string to either 'qw_sign' or 'landingPage'
sysfs attributes, the store functions attempt to access page[l - 1]
before validating that the length 'l' is greater than zero.

This patch fixes the vulnerability by adding a check at the beginning
of os_desc_qw_sign_store() and webusb_landingPage_store() to handle
the zero-length input case gracefully by returning immediately.</Note>
    </Notes>
    <CVE>CVE-2025-38497</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 using a TarFile.errorlevel = 0  and extracting with a filter the documented behavior is that any filtered members would be skipped and not extracted. However the actual behavior of TarFile.errorlevel = 0  in affected versions is that the member would still be extracted and not skipped.</Note>
    </Notes>
    <CVE>CVE-2025-4435</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 an issue in CPython when using `bytes.decode("unicode_escape", error="ignore|replace")`. If you are not using the "unicode_escape" encoding or an error handler your usage is not affected. To work-around this issue you may stop using the error= handler and instead wrap the bytes.decode() call in a try-except catching the DecodeError.</Note>
    </Notes>
    <CVE>CVE-2025-4516</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Allows arbitrary filesystem writes outside the extraction directory during extraction with filter="data".


You are affected by this vulnerability if using the tarfile  module to extract untrusted tar archives using TarFile.extractall()  or TarFile.extract()  using the filter=  parameter with a value of "data"  or "tar". See the tarfile  extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter   for more information.

Note that for Python 3.14 or later the default value of filter=  changed from "no filtering" to `"data", so if you are relying on this new default behavior then your usage is also affected.

Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it's important to avoid installing source distributions with suspicious links.</Note>
    </Notes>
    <CVE>CVE-2025-4517</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">net-tools is a collection of programs that form the base set of the NET-3 networking distribution for the Linux operating system. Inn versions up to and including 2.10, the Linux network utilities (like ifconfig) from the net-tools package do not properly validate the structure of /proc files when showing interfaces. `get_name()` in `interface.c` copies interface labels from `/proc/net/dev` into a fixed 16-byte stack buffer without bounds checking, leading to possible arbitrary code execution or crash. The known attack path does not require privilege but also does not provide privilege escalation in this scenario. A patch is available and expected to be part of version 2.20.</Note>
    </Notes>
    <CVE>CVE-2025-46836</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Tornado is a Python web framework and asynchronous networking library. When Tornado's ``multipart/form-data`` parser encounters certain errors, it logs a warning but continues trying to parse the remainder of the data. This allows remote attackers to generate an extremely high volume of logs, constituting a DoS attack. This DoS is compounded by the fact that the logging subsystem is synchronous. All versions of Tornado prior to 6.5.0 are affected. The vulnerable parser is enabled by default. Upgrade to Tornado version 6.50 to receive a patch. As a workaround, risk can be mitigated by blocking `Content-Type: multipart/form-data` in a proxy.</Note>
    </Notes>
    <CVE>CVE-2025-47287</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's a vulnerability in the libssh package where when a libssh consumer passes in an unexpectedly large input buffer to ssh_get_fingerprint_hash() function. In such cases the bin_to_base64() function can experience an integer overflow leading to a memory under allocation, when that happens it's possible that the program perform out of bounds write leading to a heap corruption.
This issue affects only 32-bits builds of libssh.</Note>
    </Notes>
    <CVE>CVE-2025-4877</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 was found in libssh, where an uninitialized variable exists under certain conditions in the privatekey_from_file() function. This flaw can be triggered if the file specified by the filename doesn't exist and may lead to possible signing failures or heap corruption.</Note>
    </Notes>
    <CVE>CVE-2025-4878</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">ping in iputils before 20250602 allows a denial of service (application error in adaptive ping mode or incorrect data collection) via a crafted ICMP Echo Reply packet, because a zero timestamp can lead to large intermediate values that have an integer overflow when squared during statistics calculations. NOTE: this issue exists because of an incomplete fix for CVE-2025-47268 (that fix was only about timestamp calculations, and it did not account for a specific scenario where the original timestamp in the ICMP payload is zero).</Note>
    </Notes>
    <CVE>CVE-2025-48964</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 was found in libxml2. This issue occurs when parsing XPath elements under certain circumstances when the XML schematron has the &lt;sch:name path="..."/&gt; schema elements. This flaw allows a malicious actor to craft a malicious XML document used as input for libxml, resulting in the program's crash using libxml or other possible undefined behaviors.</Note>
    </Notes>
    <CVE>CVE-2025-49794</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 vulnerability was found in libxml2. Processing certain sch:name elements from the input XML file can trigger a memory corruption issue. This flaw allows an attacker to craft a malicious XML input file that can lead libxml to crash, resulting in a denial of service or other possible undefined behavior due to sensitive data being corrupted in memory.</Note>
    </Notes>
    <CVE>CVE-2025-49796</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">urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.</Note>
    </Notes>
    <CVE>CVE-2025-50181</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 GNU Coreutils. The sort utility's begfield() function is vulnerable to a heap buffer under-read. The program may access memory outside the allocated buffer if a user runs a crafted command using the traditional key format. A malicious input could lead to a crash or leak sensitive data.</Note>
    </Notes>
    <CVE>CVE-2025-5278</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 libssh library in versions less than 0.11.2. An out-of-bounds read can be triggered in the sftp_handle function due to an incorrect comparison check that permits the function to access memory beyond the valid handle list and to return an invalid pointer, which is used in further processing. This vulnerability allows an authenticated remote attacker to potentially read unintended memory regions, exposing sensitive information or affect service behavior.</Note>
    </Notes>
    <CVE>CVE-2025-5318</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 libssh versions built with OpenSSL versions older than 3.0, specifically in the ssh_kdf() function responsible for key derivation. Due to inconsistent interpretation of return values where OpenSSL uses 0 to indicate failure and libssh uses 0 for success-the function may mistakenly return a success status even when key derivation fails. This results in uninitialized cryptographic key buffers being used in subsequent communication, potentially compromising SSH sessions' confidentiality, integrity, and availability.</Note>
    </Notes>
    <CVE>CVE-2025-5372</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. Prior to version 9.1.1552, a path traversal issue in Vim's tar.vim plugin can allow overwriting of arbitrary files when opening specially crafted tar archives. Impact is low because this exploit requires direct user interaction. However, successfully exploitation can lead to overwriting sensitive files or placing executable code in privileged locations, depending on the permissions of the process editing the archive. The victim must edit such a file using Vim which will reveal the filename and the file content, a careful user may suspect some strange things going on. Successful exploitation could results in the ability to execute arbitrary commands on the underlying operating system. Version 9.1.1552 contains a patch for the vulnerability.</Note>
    </Notes>
    <CVE>CVE-2025-53905</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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. Prior to version 9.1.1551, a path traversal issue in Vim's zip.vim plugin can allow overwriting of arbitrary files when opening specially crafted zip archives. Impact is low because this exploit requires direct user interaction. However, successfully exploitation can lead to overwriting sensitive files or placing executable code in privileged locations, depending on the permissions of the process editing the archive. The victim must edit such a file using Vim which will reveal the filename and the file content, a careful user may suspect some strange things going on. Successful exploitation could results in the ability to execute arbitrary commands on the underlying operating system. Version 9.1.1551 contains a patch for the vulnerability.</Note>
    </Notes>
    <CVE>CVE-2025-53906</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 container framework developed by Docker Inc. that is distributed as Docker Engine, Mirantis Container Runtime, and various other downstream projects/products. In versions 28.2.0 through 28.3.2, when the firewalld service is reloaded it removes all iptables rules including those created by Docker. While Docker should automatically recreate these rules, versions before 28.3.3 fail to recreate the specific rules that block external access to containers. This means that after a firewalld reload, containers with ports published to localhost (like 127.0.0.1:8080) become accessible from remote machines that have network routing to the Docker bridge, even though they should only be accessible from the host itself. The vulnerability only affects explicitly published ports - unpublished ports remain protected. This issue is fixed in version 28.3.3.</Note>
    </Notes>
    <CVE>CVE-2025-54388</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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. In versions from 9.1.1231 to before 9.1.1400, When processing nested tuples in Vim script, an error during evaluation can trigger a use-after-free in Vim's internal tuple reference management. Specifically, the tuple_unref() function may access already freed memory due to improper lifetime handling, leading to memory corruption. The exploit requires direct user interaction, as the script must be explicitly executed within Vim. This issue has been patched in version 9.1.1400.</Note>
    </Notes>
    <CVE>CVE-2025-55157</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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. In versions from 9.1.1231 to before 9.1.1406, when processing nested tuples during Vim9 script import operations, an error during evaluation can trigger a double-free in Vim's internal typed value (typval_T) management. Specifically, the clear_tv() function may attempt to free memory that has already been deallocated, due to improper lifetime handling in the handle_import / ex_import code paths. The vulnerability can only be triggered if a user explicitly opens and executes a specially crafted Vim script. This issue has been patched in version 9.1.1406.</Note>
    </Notes>
    <CVE>CVE-2025-55158</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 libxml2's xmlBuildQName function, where integer overflows in buffer size calculations can lead to a stack-based buffer overflow. This issue can result in memory corruption or a denial of service when processing crafted input.</Note>
    </Notes>
    <CVE>CVE-2025-6021</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">The html.parser.HTMLParser class had worse-case quadratic complexity when processing certain crafted malformed inputs potentially leading to amplified denial-of-service.</Note>
    </Notes>
    <CVE>CVE-2025-6069</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 interactive shell of the xmllint command-line tool, used for parsing XML files. When a user inputs an overly long command, the program does not check the input size properly, which can cause it to crash. This issue might allow attackers to run harmful code in rare configurations without modern protections.</Note>
    </Notes>
    <CVE>CVE-2025-6170</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 GnuTLS software in _gnutls_figure_common_ciphersuite().</Note>
    </Notes>
    <CVE>CVE-2025-6395</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Ruby WEBrick read_header HTTP Request Smuggling Vulnerability. This vulnerability allows remote attackers to smuggle arbitrary HTTP requests on affected installations of Ruby WEBrick. This issue is exploitable when the product is deployed behind an HTTP proxy that fulfills specific conditions.

The specific flaw exists within the read_headers method. The issue results from the inconsistent parsing of terminators of HTTP headers. An attacker can leverage this vulnerability to smuggle arbitrary HTTP requests. Was ZDI-CAN-21876.</Note>
    </Notes>
    <CVE>CVE-2025-6442</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 exists a vulnerability in SQLite versions before 3.50.2 where the number of aggregate terms could exceed the number of columns available. This could lead to a memory corruption issue. We recommend upgrading to version 3.50.2 or above.</Note>
    </Notes>
    <CVE>CVE-2025-6965</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 libxslt where the attribute type, atype, flags are modified in a way that corrupts internal memory management. When XSLT functions, such as the key() process, result in tree fragments, this corruption prevents the proper cleanup of ID attributes. As a result, the system may access freed memory, causing crashes or enabling attackers to trigger heap corruption.</Note>
    </Notes>
    <CVE>CVE-2025-7425</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 polkit. When processing an XML policy with 32 or more nested elements in depth, an out-of-bounds write can be triggered. This issue can lead to a crash or other unexpected behavior, and arbitrary code execution is not discarded. To exploit this flaw, a high-privilege account is needed as it's required to place the malicious policy file properly.</Note>
    </Notes>
    <CVE>CVE-2025-7519</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 defect in the CPython “tarfile” module affecting the “TarFile” extraction and entry enumeration APIs. The tar implementation would process tar archives with negative offsets without error, resulting in an infinite loop and deadlock during the parsing of maliciously crafted tar archives. 

This vulnerability can be mitigated by including the following patch after importing the “tarfile” module:   https://gist.github.com/sethmlarson/1716ac5b82b73dbcbf23ad2eff8b33e1</Note>
    </Notes>
    <CVE>CVE-2025-8194</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">1. A cookie is set using the `secure` keyword for `https://target` 
 2. curl is redirected to or otherwise made to speak with `http://target` (same 
   hostname, but using clear text HTTP) using the same cookie set 
 3. The same cookie name is set - but with just a slash as path (`path=\"/\",`).
   Since this site is not secure, the cookie *should* just be ignored.
4. A bug in the path comparison logic makes curl read outside a heap buffer
   boundary

The bug either causes a crash or it potentially makes the comparison come to
the wrong conclusion and lets the clear-text site override the contents of the
secure cookie, contrary to expectations and depending on the memory contents
immediately following the single-byte allocation that holds the path.

The presumed and correct behavior would be to plainly ignore the second set of
the cookie since it was already set as secure on a secure host so overriding
it on an insecure host should not be okay.</Note>
    </Notes>
    <CVE>CVE-2025-9086</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
</cvrfdoc>
