<?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-2024:540-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-2024:540-1</ID>
    </Identification>
    <Status>Interim</Status>
    <Version>1</Version>
    <RevisionHistory>
      <Revision>
        <Number>1</Number>
        <Date>2025-02-07T11:31:43Z</Date>
        <Description>current</Description>
      </Revision>
    </RevisionHistory>
    <InitialReleaseDate>2024-06-16T01:00:00Z</InitialReleaseDate>
    <CurrentReleaseDate>2024-06-16T01: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-2024:540-1 / google/suse-manager-proxy-4-3-byos-v20240616-x86-64</Note>
    <Note Title="Details" Type="General" Ordinal="2" xml:lang="en">This image update for google/suse-manager-proxy-4-3-byos-v20240616-x86-64 contains the following changes:
Package 000release-packages:SUSE-Manager-Proxy-release was updated:

Package aaa_base was updated:

- modify git-47-04210f8df15da0ba4d741cfe1693af06f5978a1d.patch  to also fix the typo to set JAVA_BINDIR in the csh variant
  of the alljava profile script (bsc#1221361)

- modify git-47-04210f8df15da0ba4d741cfe1693af06f5978a1d.patch
  drop the stderr redirection for csh (bsc#1221361)
- add git-49-3f8f26123d91f70c644677a323134fc79318c818.patch
  drop sysctl.d/50-default-s390.conf (bsc#1211721)
- add aaa_base-preinstall.patch
  make sure the script does not exit with 1 if a file
  with content is found (bsc#1222547)

- add patch git-48-477bc3c05fcdabf9319e84278a1cba2c12c9ed5a.patch
  home and end button not working from ssh client (bsc#1221407)
- use autosetup in prep stage of specfile

Package apache2 was updated:

- security update- added patches
  fix CVE-2023-38709 [bsc#1222330], HTTP response splitting
  + apache2-CVE-2023-38709.patch
  fix CVE-2024-24795 [bsc#1222332], HTTP Response Splitting in multiple modules
  + apache2-CVE-2024-24795.patch
  fix CVE-2024-27316 [bsc#1221401], HTTP/2 CONTINUATION frames can be utilized for DoS attacks
  + apache2-CVE-2024-27316.patch

Package audit-secondary was updated:

- Fix plugin termination when using systemd service units (bsc#1215377)  * add auditd.service-fix-plugin-termination.patch

Package autofs was updated:

- autofs-5.1.8-dont-use-initgroups-at-spawn.patch  Don't use initgroups at spawn (bsc#1214710, bsc#1221181)

Package ca-certificates was updated:

- Update to version 2+git20240416.98ae794 (bsc#1221184):  * Use flock to serialize calls (boo#1188500)
  * Make certbundle.run container friendly
  * Create /var/lib/ca-certificates if needed

Package catatonit was updated:

- Update to catatonit v0.2.0.  * Change license to GPL-2.0-or-later.
- Remove upstreamed patches:
  - 99bb9048f.patch

Package chrony was updated:

- Use make quickcheck instead of make check to avoid &amp;gt;1h build  times and failures due to timeouts. This was the default before
  3.2 but it changed to make tests more reliable. Here a seed is
  already set to get deterministic execution.

- Use shorter NTS-KE retry interval when network is down
  (bsc#1213551, chrony-burst_total_samples_to_go.patch,
  chrony-retry_interval_ke_start.patch).

Package cloud-netconfig was updated:

- Update to version 1.14  + Use '-s' instead of '--no-progress-meter' for curl (bsc#1221757)

- Add version settings to Provides/Obsoletes

Package coreutils was updated:

- ls: avoid triggering automounts (bsc#1221632)  - add coreutils-ls-avoid-triggering-automounts.patch

- tail: fix tailing sysfs files where PAGE_SIZE &amp;gt; BUFSIZ (bsc#1219321)
  - add coreutils-tail-fix-tailing-sysfs-files-where-PAGE_SIZE-BUFSIZ.patch

Package cups was updated:

- cups-2.2.7-CVE-2024-35235.patch is derived  from the upstream patch against master (CUPS 2.5)
  to behave backward compatible for CUPS 2.2.7
  in SLE15 and openSUSE Leap 15 to fix CVE-2024-35235
  &amp;quot;cupsd Listen port arbitrary chmod 0140777&amp;quot;
  without the more secure but backward-incompatible behaviour
  of the upstream patch for CUPS 2.5
  that ignores domain sockets specified in 'Listen' entries
  in /etc/cups/cupsd.conf when cupsd is lauched via systemd
  (in particular when launched on-demand by systemd)
  https://github.com/OpenPrinting/cups/security/advisories/GHSA-vvwp-mv6j-hw6f
  bsc#1225365

- cups-2.2.7-web-ui-kerberos-authentication.patch, update
  patch to handle local 'Negotiate' authentication response
  for cli clients. (bsc#1223179).

- Remove '--enable-debug-printfs' from configure options, see
  https://github.com/OpenPrinting/cups/issues/875
  (bsc#1217119).

Package curl was updated:

- Security fix: [bsc#1221665, CVE-2024-2004]  * Usage of disabled protocol
  * Add curl-CVE-2024-2004.patch

- Security fix: [bsc#1221667, CVE-2024-2398]
  * curl: HTTP/2 push headers memory-leak
  * Add curl-CVE-2024-2398.patch

Package docker was updated:

- Add patch to fix bsc#1220339  * 0007-daemon-overlay2-remove-world-writable-permission-fro.patch
- rebase patches:
  * 0001-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  * 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch
  * 0003-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  * 0004-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  * 0005-SLE12-revert-apparmor-remove-version-conditionals-fr.patch
  * 0006-Vendor-in-latest-buildkit-v0.11-branch-including-CVE.patch

- Allow to disable apparmor support (ALP supports only SELinux)

Package dwz was updated:

- Add dwz-0.12-clean-up-temporary-file-in-hardlink-mode.patch to  cleanup left-over temporary file (swo#24275, bsc#1221634).
- Replace &amp;quot;%doc COPYING&amp;quot; with &amp;quot;%license COPYING&amp;quot;.

Package e2fsprogs was updated:

EA Inode handling fixes:- ext2fs-avoid-re-reading-inode-multiple-times.patch: ext2fs: avoid re-reading
  inode multiple times (bsc#1223596)
- e2fsck-fix-potential-out-of-bounds-read-in-inc_ea_in.patch: e2fsck: fix
  potential out-of-bounds read in inc_ea_inode_refs() (bsc#1223596)
- e2fsck-add-more-checks-for-ea-inode-consistency.patch: e2fsck: add more
  checks for ea inode consistency (bsc#1223596)
- e2fsck-fix-golden-output-of-several-tests.patch: e2fsck: fix golden output of
  several tests (bsc#1223596)

Package fdupes was updated:

- Do not use sqlite, as this pulls sqlite into Ring0 at no real  benefit performance wise: the cache is not reused between runs.
  + Drop sqlite-devel BuildRequires
  + Pass --without-sqlite to configure

- Update to 2.3.0:
  * Add --cache option to speed up file comparisons.
  * Use nanosecond precision for file times, if available.
  * Fix compilation issue on OpenBSD.
  * Other changes like fixing typos, wording, etc.

- update to 2.2.1:
  * Fix bug in code meant to skip over the current log file when --log option is given.
  * Updates to copyright notices in source code.
  * Add --deferconfirmation option.
  * Check that files marked as duplicates haven't changed during program execution before deleting them.
  * Update documentation to indicate units for SIZE in command-line options.
  * Move some configuration settings to configure.ac file.

- Fixes for the new wrapper:
  * Order duplicates by name, to get a reproducible file set
    (boo#1197484).
  * Remove redundant order parameter from fdupes invocation.
  * Modernize code, significantly reduce allocations.
  * Exit immediately when mandatory parameters are missing.
  * Remove obsolete buildroot parameter
  * Add some tests for the wrapper

- A more correct approach to creating symlinks (old bug actually):
  Do not link the files as given by fdupes, but turn them into
  relative links (it works by chance if given a buildroot, but
  fails if running on a subdirectory)
- Support multiple directories given (as glob to the macro)

- Handle symlinks (-s argument) correctly

- Simplify macros.fdupes with a call to a C++ program that does
  the same within a fraction of a second what the shell loop did
  in many seconds (bsc#1195709)

Package glib2 was updated:

- Add patches to fix CVE-2024-34397 (boo#1224044):  glib2-CVE-2024-34397.patch (glgo#GNOME/glib#3268).
  glib2-fix-ibus-regression.patch (glgo#GNOME/glib#3353)

Package glibc was updated:

- nscd-netgroup-cache-timeout.patch: Use time_t for return type of  addgetnetgrentX (CVE-2024-33602, bsc#1223425)

- ulp-prologue-into-asm-functions.patch: Avoid creating ULP prologue
  for _start routine (bsc#1221940)

- glibc-CVE-2024-33599-nscd-Stack-based-buffer-overflow-in-n.patch:
  nscd: Stack-based buffer overflow in netgroup cache
  (CVE-2024-33599, bsc#1223423, BZ #31677)
- glibc-CVE-2024-33600-nscd-Avoid-null-pointer-crashes-after.patch:
  nscd: Avoid null pointer crashes after notfound response
  (CVE-2024-33600, bsc#1223424, BZ #31678)
- glibc-CVE-2024-33600-nscd-Do-not-send-missing-not-found-re.patch:
  nscd: Do not send missing not-found response in addgetnetgrentX
  (CVE-2024-33600, bsc#1223424, BZ #31678)
- glibc-CVE-2024-33601-CVE-2024-33602-nscd-netgroup-Use-two.patch:
  netgroup: Use two buffers in addgetnetgrentX (CVE-2024-33601,
  CVE-2024-33602, bsc#1223425, BZ #31680)

- iconv-iso-2022-cn-ext.patch: iconv: ISO-2022-CN-EXT: fix out-of-bound
  writes when writing escape sequence (CVE-2024-2961, bsc#1222992)

- duplocale-global-locale.patch: duplocale: protect use of global locale
  (bsc#1220441, BZ #23970)

Package google-guest-agent was updated:

- Update to version 20240314.00 (bsc#1221900, bsc#1221901)  * NetworkManager: only set secondary interfaces as up (#378)
  * address manager: make sure we check for oldMetadata (#375)
  * network: early setup network (#374)
  * NetworkManager: fix ipv6 and ipv4 mode attribute (#373)
  * Network Manager: make sure we clean up ifcfg files (#371)
  * metadata script runner: fix script download (#370)
  * oslogin: avoid adding extra empty line at the end of /etc/security/group.conf (#369)
  * Dynamic vlan (#361)
  * Check for nil response (#366)
  * Create NetworkManager implementation (#362)
  * Skip interface manager on Windows (#363)
  * network: remove ignore setup (#360)
  * Create wicked network service implementation and its respective unit (#356)
  * Update metadata script runner, add tests (#357)
  * Refactor guest-agent to use common retry util (#355)
  * Flush logs before exiting #358 (#359)
- Refresh patches for new version
  * dont_overwrite_ifcfg.patch

- No need for double %setup.

- Use %patch -P N instead of deprecated %patchN.

Package google-guest-configs was updated:

- Update to version 20240307.00 (bsc#1221146, bsc#1221900, bsc#1221901)  * Support dot in NVMe device ids (#68)
- from version 20240304.00
  * google_set_hostname: Extract rsyslog service name
    with a regexp for valid systemd unit names (#67)
- from version 20240228.00
  * Remove quintonamore from OWNERS (#64)
- from version 20240119.00
  * Setup smp affinity for IRQs and XPS on A3+ VMs (#63)

- Update to version 20231214.00
  * set multiqueue: A3 check set timeout the MDS call in 1s (#62)
- from version 20231103.00
  * Update owners (#61)
  * Update owners (#58)

- Update to version 20230929.00
  * Update multinic filter to pick only pci devices (#59)

Package google-guest-oslogin was updated:

- Fix file permissions for google_authorized_principals binary (bsc#1222171)
- Update to version 20240311.00 (bsc#1218548, bsc#1221900, bsc#1221901)
  * pam: Bring back pam's account management implementation (#133)
  * Change error messages when checking login policy (#129)
  * Remove quintonamore from OWNERS (#128)

Package google-osconfig-agent was updated:

- Update to version 20240320.00 (bsc#1221900, bsc#1221901)  * Enable OSConfig agent to read GPG keys files with multiple entities (#537)
- from version 20240314.00
  * Update OWNERS file to replace mahmoudn GitHub
    username by personal email GitHub username (#534)
- from version 20240313.01
  * Bump google.golang.org/protobuf from 1.30.0 to 1.33.0 in /e2e_tests (#535)
- from version 20240313.00
  * Adds a console and gcloud example policies (#533)
- from version 20240228.00
  * GuestPolicies e2e: Remove ed package if exist for zypper
    startup_script in recipe-steps tests (#532)
- from version 20240126.00
  * Fix Enterprise Linux Recipe-Steps tests to install
    info dependency package in the startup-script (#530)
- from version 20240125.01
  * Fix SUSE pkg-update and pkg-no-update e2e tests (#529)
- from version 20240125.00
  * Fix zypper patch info parser to consider conflicts-pkgs float versions (#528)
- from version 20240123.01
  * Fix SUSE package update e2e tests to use another existing package (#527)
- from version 20240123.00
  * Update cis-exclude-check-once-a-day.yaml (#526)

- Update to version 20231219.00
  * Bump golang.org/x/crypto from 0.14.0 to 0.17.0 (#524)
- from version 20231207.01
  * Some change to create an agent release (#523)
- from version 20231207.00
  * Some change to create an agent release (#522)
- from version 20231205.00
  * Some change to create an agent release (#521)
- from version 20231130.02
  * Merge pull request #519 from Gulio/just-release
  * Merge branch 'master' into just-release
  * Some change to create an agent release
  * Some change to create an agent release
- from version 20231130.00
  * Some change to create an agent release (#518)
- from version 20231129.00
  * Fix parse yum updates to consider the packages under
    installing-dependencies keyword (#502)
  * Update feature names in the README file (#517)
- from version 20231128.00
  * Updating owners (#508)
- from version 20231127.00
  * Move OS policy CIS examples under the console folder (#514)
- from version 20231123.01
  * Adds three more OS Policy examples to CIS folder (#509)
  * Added ekrementeskii and MahmoudNada0 to OWNERS (#505)
- from version 20231123.00
  * docs(osconfig):add OS policy examples for CIS scanning (#503)
- from version 20231121.02
  * Added SCODE to Windows error description (#504)
- from version 20231121.01
  * Update OWNERS (#501)
  * Update go version to 1.21 (#507)
- from version 20231121.00
  * Call fqdn (#481)
- from version 20231116.00
  * Removing obsolete MS Windows 2019 images (#500)
- from version 20231107.00
  * Update owners. (#498)
- from version 20231103.02
  * Increasing test timeouts (#499)
  * Update OWNERS (#497)
- from version 20231103.01
  * Bump google.golang.org/grpc from 1.53.0 to 1.56.3 in /e2e_tests (#493)
  * Bump google.golang.org/grpc from 1.53.0 to 1.56.3 (#494)
- from version 20231103.00
  * Removing deprecated Win for containers OSs (#496)
- from version 20231027.00
  * Shortening the reported image names (#495)
- from version 20231025.00
  * Merge pull request #492 from GoogleCloudPlatform/michaljankowiak-patch-1
  * Merge branch 'master' into michaljankowiak-patch-1
  * Fixing name changes
  * Fixing rename issue
  * Fixed formatting
  * Fixed formatting
  * Fixing formatting
  * Removing support for RHEL 6, adding RHEL 9
  * Removing support for RHEL 6, adding for RHEL 9
  * Removing support for RHEL 6 and adding for RHEL 9
  * Removing step needed for RHEL 6
  * Fixing build issues
  * Removing nonexistent images and adding new ones
- from version 20231024.00
  * Removing obsolete OS images and adding new ones (#491)
- from version 20231020.00
  * Change debug messages when parsing zypper patch output (#490)
- from version 20231013.00
  * Bump golang.org/x/net from 0.7.0 to 0.17.0 (#489)
- from version 20231010.00
  * Revert &amp;quot;Added [main] section with gpgcheck to
    the agent-managed repo file (#484)&amp;quot; (#488)
- from version 20231003.00
  * Bump google.golang.org/grpc from 1.42.0 to 1.53.0 in /e2e_tests (#478)
- from version 20230920.00
  * Update OWNERS (#485)
- from version 20230912.00
  * Added [main] section with gpgcheck to the agent-managed repo file (#484)
  * Migrate empty interface to any (#483)

- Bump the golang compiler version to 1.21 (bsc#1216546)

- Update to version 20230829.00
  * Added burov, dowgird, paulinakania and Gulio to OWNERS (#482)
  &amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; ./google-osconfig-agent.changes.new

Package growpart-rootgrow was updated:

- Update to version 1.0.7 (bsc#1219941)  + Support root to be in a btrfs snapshot
  + 1.0.6 had different implementation for btrfs in snapshot support

Package hwdata was updated:

- update to 0.380:  * Update pci, usb and vendor ids

- update to 0.379:
  * Update pci, usb and vendor ids

Package ipset was updated:

- Fix build with latest kernel, bsc#1223370  * bsc1223370.patch

Package iputils was updated:

- Update 0002-arping-Fix-unsolicited-ARP-regressions-on-c-1.patch  after upstream merged the fix, update git commit hashes.

- Backport proposed fix for regression in upstream commit 4db1de6 (bsc#1224877)
  0002-arping-Fix-unsolicited-ARP-regressions-on-c-1.patch

- Backport upstream fix for bsc#1224877
  4db1de6 (&amp;quot;arping: Fix 1s delay on exit for unsolicited arpings&amp;quot;)
  0001-arping-Fix-1s-delay-on-exit-for-unsolicited-arpings.patch

Package kernel-default was updated:

- pstore: inode: Only d_invalidate() is needed (bsc#1223705  CVE-2024-27389).
- commit bbe965a

- media: edia: dvbdev: fix a use-after-free (CVE-2024-27043
  bsc#1223824).
- commit e3d9ce5

- Update
  patches.suse/ext4-fix-bug-in-extents-parsing-when-eh_entries-0-an.patch
  (bsc#1206881 bsc#1223475 CVE-2022-48631).
- commit 718df1c

- md/raid5: fix atomicity violation in raid5_cache_count
  (bsc#1219169, CVE-2024-23307).
- commit d2d22f0

- kABI workaround for cec_adapter (CVE-2024-23848 bsc#1219104).
- media: cec: core: avoid confusing &amp;quot;transmit timed out&amp;quot; message
  (CVE-2024-23848 bsc#1219104).
- media: cec: core: avoid recursive cec_claim_log_addrs
  (CVE-2024-23848 bsc#1219104).
- media: cec: cec-api: add locking in cec_release()
  (CVE-2024-23848 bsc#1219104).
- media: cec: cec-adap: always cancel work in cec_transmit_msg_fh
  (CVE-2024-23848 bsc#1219104).
- commit 5f84bce

- media: cec: abort if the current transmit was canceled
  (CVE-2024-23848 bsc#1219104).
- commit f23b730

- Update
  patches.suse/gpio-mockup-fix-NULL-pointer-dereference-when-removi.patch
  (git-fixes CVE-2022-48663 bsc#1223523).
- commit fb50f4d

- Update
  patches.suse/cgroup-cgroup_get_from_id-must-check-the-looked-up-kn-is-a-directory.patch
  (bsc#1203906 CVE-2022-48638 bsc#1223522).
- commit 1b1d545

- Update
  patches.suse/sfc-fix-TX-channel-offset-when-using-legacy-interrup.patch
  (git-fixes CVE-2022-48647 bsc#1223519).
- commit 2df3009

- Update
  patches.suse/smb3-fix-temporary-data-corruption-in-insert-range.patch
  (bsc#1193629 CVE-2022-48667 bsc#1223518).
- commit 2544640

- Update
  patches.suse/bnxt-prevent-skb-UAF-after-handing-over-to-PTP-worke.patch
  (jsc#SLE-18978 CVE-2022-48637 bsc#1223517).
- commit 8af9f52

- Update
  patches.suse/smb3-fix-temporary-data-corruption-in-collapse-range.patch
  (bsc#1193629 CVE-2022-48668 bsc#1223516).
- commit ea57df6

- drm/i915/gem: Really move i915_gem_context.link under ref
  protection (CVE-2022-48662 bsc#1223505).
- commit 1ea0422

- Update
  patches.suse/scsi-qla2xxx-Fix-memory-leak-in-__qlt_24xx_handle_ab.patch
  (bsc#1203935 CVE-2022-48650 bsc#1223509).
- commit ecd523c

- Update
  patches.suse/sfc-fix-null-pointer-dereference-in-efx_hard_start_x.patch
  (git-fixes CVE-2022-48648 bsc#1223503).
- commit 2cd307a

- Update
  patches.suse/gpiolib-cdev-Set-lineevent_state-irq-after-IRQ-regis.patch
  (git-fixes CVE-2022-48660 bsc#1223487).
- commit 30d7811

- Update
  patches.suse/arm64-topology-fix-possible-overflow-in-amu_fie_setu.patch
  (git-fixes CVE-2022-48657 bsc#1223484).
- commit d7e1659

- Update
  patches.suse/netfilter-nfnetlink_osf-fix-possible-bogus-match-in-.patch
  (bsc#1204614 CVE-2022-48654 bsc#1223482).
- commit a8a2952

- Update
  patches.suse/dmaengine-ti-k3-udma-private-Fix-refcount-leak-bug-i.patch
  (git-fixes CVE-2022-48656 bsc#1223479).
- commit 90546f3

- Update
  patches.suse/ice-Don-t-double-unplug-aux-on-peer-initiated-reset.patch
  (git-fixes CVE-2022-48653 bsc#1223474).
- commit dba84ad

- ipvlan: Fix out-of-bound bugs caused by unset skb-&amp;gt;mac_header
  (bsc#1223513 CVE-2022-48651).
- commit c96a663

- Update patches.suse/firmware-arm_scmi-Harden-accesses-to-the-reset-domai.patch (git-fixes CVE-2022-48655 bsc#1223477)
- commit 2dabafb

- Call flush_delayed_fput() from nfsd main-loop (bsc#1223380).
- commit 18e662b

- Update
  patches.suse/spi-spi-zynqmp-gqspi-Handle-error-for-dma_set_mask.patch
  (git-fixes CVE-2021-47047 bsc#1220761).
- commit 1f6461d

- crypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init
  (CVE-2023-52616 bsc#1221612).
- commit 6fa74bc

- x86/boot: Ignore relocations in .notes sections in walk_relocs() too (bsc#1222624 CVE-2024-26816).
- commit 9c9dbbd

- x86, relocs: Ignore relocations in .notes section (bsc#1222624 CVE-2024-26816).
- commit 9bcfc48

- Update
  patches.suse/aoe-fix-the-potential-use-after-free-problem-in-aoec.patch
  (bsc#1218562 CVE-2023-6270 CVE-2024-26898 bsc#1223016).
- commit 5a56f33

- Update
  patches.suse/Bluetooth-rfcomm-Fix-null-ptr-deref-in-rfcomm_check_.patch
  (bsc#1219170 CVE-2024-22099 CVE-2024-26903 bsc#1223187).
- commit 1a4ee0a

- Update
  patches.suse/0001-fs-hugetlb-fix-NULL-pointer-dereference-in-hugetlbs_.patch
  (bsc#1219264 CVE-2024-0841 CVE-2024-26688 bsc#1222482).
- Update
  patches.suse/btrfs-fix-double-free-of-anonymous-device-after-snap.patch
  (bsc#1219126 CVE-2024-23850 CVE-2024-26792 bsc#1222430).
- Update
  patches.suse/net-sched-act_mirred-don-t-override-retval-if-we-alr.patch
  (CVE-2024-26733 bsc#1222585 CVE-2024-26739 bsc#1222559).
- commit ac0df3e

- Update
  patches.suse/ALSA-gus-fix-null-pointer-dereference-on-pointer-blo.patch
  (git-fixes CVE-2021-47207 bsc#1222790).
- Update
  patches.suse/ALSA-usb-audio-fix-null-pointer-dereference-on-point.patch
  (bsc#1192354 CVE-2021-47211 bsc#1222869).
- Update
  patches.suse/RDMA-core-Set-send-and-receive-CQ-before-forwarding-.patch
  (jsc#SLE-19249 CVE-2021-47196 bsc#1222773).
- Update
  patches.suse/arm64-dts-qcom-msm8998-Fix-CPU-L2-idle-state-latency.patch
  (git-fixes CVE-2021-47187 bsc#1222703).
- Update
  patches.suse/cfg80211-call-cfg80211_stop_ap-when-switch-from-P2P_.patch
  (git-fixes CVE-2021-47194 bsc#1222829).
- Update
  patches.suse/clk-sunxi-ng-Unregister-clocks-resets-when-unbinding.patch
  (git-fixes CVE-2021-47205 bsc#1222888).
- Update
  patches.suse/drm-prime-Fix-use-after-free-in-mmap-with-drm_gem_tt.patch
  (git-fixes CVE-2021-47200 bsc#1222838).
- Update
  patches.suse/i40e-Fix-NULL-ptr-dereference-on-VSI-filter-sync.patch
  (jsc#SLE-18378 CVE-2021-47184 bsc#1222666).
- Update
  patches.suse/iavf-free-q_vectors-before-queues-in-iavf_disable_vf.patch
  (jsc#SLE-18385 CVE-2021-47201 bsc#1222792).
- Update
  patches.suse/msft-hv-2480-x86-hyperv-Fix-NULL-deref-in-set_hv_tscchange_cb-if-.patch
  (git-fixes CVE-2021-47217 bsc#1222836).
- Update
  patches.suse/net-dpaa2-eth-fix-use-after-free-in-dpaa2_eth_remove.patch
  (git-fixes CVE-2021-47204 bsc#1222787).
- Update
  patches.suse/net-mlx5-Update-error-handler-for-UCTX-and-UMEM.patch
  (jsc#SLE-19253 CVE-2021-47212 bsc#1222709).
- Update
  patches.suse/net-mlx5e-CT-Fix-multiple-allocations-and-memleak-of.patch
  (jsc#SLE-19253 CVE-2021-47199 bsc#1222785).
- Update
  patches.suse/net-mlx5e-kTLS-Fix-crash-in-RX-resync-flow.patch
  (jsc#SLE-19253 CVE-2021-47215 bsc#1222704).
- Update
  patches.suse/net-mlx5e-nullify-cq-dbg-pointer-in-mlx5_debug_cq_re.patch
  (jsc#SLE-19253 CVE-2021-47197 bsc#1222776).
- Update
  patches.suse/sched-fair-Prevent-dead-task-groups-from-regaining-cfs_rq-s.patch
  (bsc#1192837 CVE-2021-47209 bsc#1222796).
- Update patches.suse/scsi-advansys-Fix-kernel-pointer-leak.patch
  (git-fixes CVE-2021-47216 bsc#1222876).
- Update
  patches.suse/scsi-core-sysfs-Fix-hang-when-device-state-is-set-via-sysfs
  (git-fixes CVE-2021-47192 bsc#1222867).
- Update
  patches.suse/scsi-lpfc-Fix-list_add-corruption-in-lpfc_drain_txq.patch
  (bsc#1190576 CVE-2021-47203 bsc#1222881).
- Update
  patches.suse/scsi-lpfc-Fix-use-after-free-in-lpfc_unreg_rpi-routi.patch
  (bsc#1192145 CVE-2021-47198 bsc#1222883).
- Update
  patches.suse/scsi-pm80xx-Fix-memory-leak-during-rmmod.patch
  (git-fixes CVE-2021-47193 bsc#1222879).
- Update
  patches.suse/scsi-scsi_debug-Fix-out-of-bound-read-in-resp_readcap16.patch
  (git-fixes CVE-2021-47191 bsc#1222866).
- Update
  patches.suse/scsi-scsi_debug-Fix-out-of-bound-read-in-resp_report_tgtpgs.patch
  (git-fixes CVE-2021-47219 bsc#1222824).
- Update patches.suse/scsi-ufs-core-Improve-SCSI-abort-handling
  (git-fixes CVE-2021-47188 bsc#1222671).
- Update
  patches.suse/selinux-fix-NULL-pointer-dereference-when-hashtab-al.patch
  (git-fixes CVE-2021-47218 bsc#1222791).
- Update
  patches.suse/thermal-Fix-NULL-pointer-dereferences-in-of_thermal_.patch
  (stable-5.14.21 CVE-2021-47202 bsc#1222878).
- Update
  patches.suse/tty-tty_buffer-Fix-the-softlockup-issue-in-flush_to_.patch
  (git-fixes CVE-2021-47185 bsc#1222669).
- Update
  patches.suse/usb-host-ohci-tmio-check-return-value-after-calling-.patch
  (git-fixes CVE-2021-47206 bsc#1222894).
- Update
  patches.suse/usb-typec-tipd-Remove-WARN_ON-in-tps6598x_block_read.patch
  (git-fixes CVE-2021-47210 bsc#1222901).
- commit 48b69db

- wifi: iwlwifi: fix a memory corruption (CVE-2024-26610
  bsc#1221299).
- commit e7967c5

- xen/events: close evtchn after mapping cleanup (CVE-2024-26687,
  bsc#1222435).
- commit eb41ab9

- Update patches.suse/arp-Prevent-overflow-in-arp_req_get.patch
- fix build warning
- commit b98055d

- ext4: regenerate buddy after block freeing failed if under fc
  replay (bsc#1220342 CVE-2024-26601).
- commit c12e20f

- blacklist.conf: Blacklist 83e80a6e3543f3
- commit 62a580e

- fs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion
  (bsc#1222721 CVE-2024-26764).
- commit b81d662

- fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via
  libaio (bsc#1222721 CVE-2024-26764).
- commit 6f0ed6e

- ext4: avoid allocating blocks from corrupted group in
  ext4_mb_try_best_found() (bsc#1222618 CVE-2024-26773).
- commit 821043d

- Update patches.suse/thermal-Fix-NULL-pointer-dereferences-in-of_thermal_.patch (stable-5.14.21 CVE-2021-47202 bsc#1222878)
- commit 9b2ed28

- Update references in
  patches.suse/ocfs2-Avoid-touching-renamed-directory-if-parent-doe.patch
  (bsc#1221044 bsc#1221088 CVE-2023-52591 CVE-2023-52590).
- commit 6a6852e

- Update patches.suse/spi-fix-use-after-free-of-the-add_lock-mutex.patch (git-fixes CVE-2021-47195 bsc#1222832)
- commit e8d48f1

- IB/hfi1: Fix sdma.h tx-&amp;gt;num_descs off-by-one error (bsc#1222726 CVE-2024-26766)
- commit dc4bba0

- scsi: Update max_hw_sectors on rescan (bsc#1216223).
- ibmvfc: make 'max_sectors' a module option (bsc#1216223).
- commit af79c3f

- md/raid5: fix atomicity violation in raid5_cache_count
  (bsc#1219169, CVE-2024-23307).
- commit 7709383

- Update
  patches.suse/btrfs-fix-memory-ordering-between-normal-and-ordered-work-functions.patch
  (git-fixes CVE-2021-47189 bsc#1222706).
- commit 95bc72d

- Update
  patches.suse/tty-tty_buffer-Fix-the-softlockup-issue-in-flush_to_.patch
  (git-fixes CVE-2021-47185).
- commit de9e1db

- Update
  patches.suse/scsi-lpfc-Fix-link-down-processing-to-address-NULL-p.patch
  (bsc#1192145 CVE-2021-47183 bsc#1222664).
- commit 720685d

- Update
  patches.suse/scsi-core-Fix-scsi_mode_sense-buffer-length-handling.patch
  (git-fixes CVE-2021-47182 bsc#1222662).
- commit 641c737

- Update
  patches.suse/usb-musb-tusb6010-check-return-value-after-calling-p.patch
  (git-fixes CVE-2021-47181 bsc#1222660).
- commit 27da195

- ceph: prevent use-after-free in encode_cap_msg() (CVE-2024-26689
  bsc#1222503).
- commit c307f9b

- tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc
  (bsc#1222619).
- commit 900d642

- arp: Prevent overflow in arp_req_get() (CVE-2024-26733
  bsc#1222585).
- commit aed9764

- net/sched: act_mirred: don't override retval if we already
  lost the skb (CVE-2024-26733 bsc#1222585).
- commit 57213f3

- Update
  patches.suse/btrfs-do-not-ASSERT-if-the-newly-created-subvolume-a.patch
  (bsc#1219126 CVE-2024-23850 CVE-2024-26727 bsc#1222536).
- commit 9619dfe

- ext4: fix double-free of blocks due to wrong extents moved_len
  (bsc#1222422 CVE-2024-26704).
- commit 4e96ad3

- fs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super
  (bsc#1219264 CVE-2024-0841).
- commit aa8204a

- nfsd: Fix error cleanup path in nfsd_rename() (bsc#1221044
  CVE-2023-52591).
- commit a849be1

- scsi: pm80xx: Avoid leaking tags when processing
  OPC_INB_SET_CONTROLLER_CONFIG command (bsc#1220883
  cve-2023-52500).
- commit fc88013

- Update
  patches.suse/netfilter-nftables-exthdr-fix-4-byte-stack-OOB-write.patch
  (CVE-2023-4881 bsc#1215221 CVE-2023-52628 bsc#1222117).
- commit fd3aabc

- selinux: saner handling of policy reloads (bsc#1222230 bsc#1221044
  CVE-2023-52591).
- commit 66a189d

- bpf, sockmap: Prevent lock inversion deadlock in map delete elem
  (bsc#1209657 CVE-2023-0160).
- commit 989b8c6

- blacklist.conf: omit reverted sockmap deadlock fix
- commit 397323e

- x86/sev: Harden #VC instruction emulation somewhat (CVE-2024-25742 bsc#1221725).
- commit 2e3eba1

- netfilter: nf_tables: disallow anonymous set with timeout flag
  (CVE-2024-26642 bsc#1221830).
- commit 02a907f

- netfilter: ctnetlink: fix possible refcount leak in
  ctnetlink_create_conntrack() (CVE-2023-7192 bsc#1218479).
- commit 0b47032

- README.BRANCH: Remove copy of branch name
- commit 4834fba

- README.BRANCH: Remove copy of branch name
- commit 704bda3

- ipv6: init the accept_queue's spinlocks in inet6_create
  (bsc#1221293 CVE-2024-26614).
- commit 0ab8c0f

- tcp: make sure init the accept_queue's spinlocks once
  (bsc#1221293 CVE-2024-26614).
- commit 943f002

- powerpc/mm: Fix null-pointer dereference in pgtable_cache_add
  (CVE-2023-52607 bsc#1221061).
- commit 36feafa

- Update
  patches.suse/HID-intel-ish-hid-ipc-Disable-and-reenable-ACPI-GPE-.patch
  (git-fixes CVE-2023-52519 bsc#1220920).
- Update
  patches.suse/HID-sony-Fix-a-potential-memory-leak-in-sony_probe.patch
  (git-fixes CVE-2023-52529 bsc#1220929).
- Update
  patches.suse/IB-hfi1-Fix-bugs-with-non-PAGE_SIZE-end-multi-iovec-.patch
  (git-fixes CVE-2023-52474 bsc#1220445).
- Update
  patches.suse/RDMA-siw-Fix-connection-failure-handling.patch
  (git-fixes CVE-2023-52513 bsc#1221022).
- Update
  patches.suse/RDMA-srp-Do-not-call-scsi_done-from-srp_abort.patch
  (git-fixes CVE-2023-52515 bsc#1221048).
- Update
  patches.suse/Revert-tty-n_gsm-fix-UAF-in-gsm_cleanup_mux.patch
  (git-fixes CVE-2023-52564 bsc#1220938).
- Update
  patches.suse/bpf-Check-rcu_read_lock_trace_held-before-calling-bp.patch
  (bsc#1220251 CVE-2023-52447 CVE-2023-52621 bsc#1222073).
- Update
  patches.suse/ieee802154-ca8210-Fix-a-potential-UAF-in-ca8210_prob.patch
  (git-fixes CVE-2023-52510 bsc#1220898).
- Update
  patches.suse/net-nfc-llcp-Add-lock-when-modifying-device-list.patch
  (git-fixes CVE-2023-52524 bsc#1220927).
- Update
  patches.suse/net-usb-smsc75xx-Fix-uninit-value-access-in-__smsc75.patch
  (git-fixes CVE-2023-52528 bsc#1220843).
- Update
  patches.suse/nfc-nci-assert-requested-protocol-is-valid.patch
  (git-fixes CVE-2023-52507 bsc#1220833).
- Update
  patches.suse/nilfs2-fix-potential-use-after-free-in-nilfs_gccache.patch
  (git-fixes CVE-2023-52566 bsc#1220940).
- Update
  patches.suse/nvme-fc-Prevent-null-pointer-dereference-in-nvme_fc_.patch
  (bsc#1214842 CVE-2023-52508 bsc#1221015).
- Update
  patches.suse/nvmet-tcp-Fix-a-kernel-panic-when-host-sends-an-inva.patch
  (bsc#1217987 bsc#1217988 bsc#1217989 CVE-2023-6535 CVE-2023-6536
  CVE-2023-6356 CVE-2023-52454 bsc#1220320).
- Update
  patches.suse/platform-x86-think-lmi-Fix-reference-leak.patch
  (git-fixes CVE-2023-52520 bsc#1220921).
- Update
  patches.suse/ravb-Fix-use-after-free-issue-in-ravb_tx_timeout_wor.patch
  (bsc#1212514 CVE-2023-35827 CVE-2023-52509 bsc#1220836).
- Update
  patches.suse/ring-buffer-Do-not-attempt-to-read-past-commit.patch
  (git-fixes CVE-2023-52501 bsc#1220885).
- Update
  patches.suse/serial-8250_port-Check-IRQ-data-before-use.patch
  (git-fixes CVE-2023-52567 bsc#1220839).
- Update
  patches.suse/spi-sun6i-fix-race-between-DMA-RX-transfer-completio.patch
  (git-fixes CVE-2023-52517 bsc#1221055).
- Update
  patches.suse/spi-sun6i-reduce-DMA-RX-transfer-width-to-single-byt.patch
  (git-fixes CVE-2023-52511 bsc#1221012).
- Update
  patches.suse/wifi-mwifiex-Fix-oob-check-condition-in-mwifiex_proc.patch
  (git-fixes CVE-2023-52525 bsc#1220840).
- Update
  patches.suse/x86-alternatives-disable-kasan-in-apply_alternatives.patch
  (git-fixes CVE-2023-52504 bsc#1221553).
- Update
  patches.suse/x86-srso-fix-sbpb-enablement-for-spec_rstack_overflow-off.patch
  (git-fixes CVE-2023-52575 bsc#1220871).
- commit 5f353b0

- Update patches.suse/0001-mmc-moxart_remove-Fix-UAF.patch
  (bsc#1194516 CVE-2022-0487 CVE-2022-48626 bsc#1220366).
- Update
  patches.suse/crypto-qcom-rng-ensure-buffer-for-generate-is-comple.patch
  (git-fixes CVE-2022-48629 bsc#1220989).
- Update
  patches.suse/crypto-qcom-rng-fix-infinite-loop-on-requests-not-mu.patch
  (git-fixes CVE-2022-48630 bsc#1220990).
- commit f8cf886

- Update
  patches.suse/ALSA-hda-intel-sdw-acpi-harden-detection-of-controll.patch
  (git-fixes CVE-2021-46926 bsc#1220478).
- Update
  patches.suse/ALSA-rawmidi-fix-the-uninitalized-user_pversion.patch
  (git-fixes CVE-2021-47096 bsc#1220981).
- Update
  patches.suse/IB-qib-Fix-memory-leak-in-qib_user_sdma_queue_pkts.patch
  (git-fixes CVE-2021-47104 bsc#1220960).
- Update
  patches.suse/Input-elantech-fix-stack-out-of-bound-access-in-elan.patch
  (git-fixes CVE-2021-47097 bsc#1220982).
- Update
  patches.suse/KVM-x86-mmu-Don-t-advance-iterator-after-restart-due.patch
  (git-fixes CVE-2021-47094 bsc#1221551).
- Update patches.suse/NFSD-Fix-READDIR-buffer-overflow.patch
  (git-fixes bsc#1196346 CVE-2021-47107 bsc#1220965).
- Update
  patches.suse/asix-fix-uninit-value-in-asix_mdio_read.patch
  (git-fixes CVE-2021-47101 bsc#1220987).
- Update
  patches.suse/drm-mediatek-hdmi-Perform-NULL-pointer-check-for-mtk.patch
  (git-fixes CVE-2021-47108 bsc#1220986).
- Update
  patches.suse/hwmon-lm90-Prevent-integer-overflow-underflow-in-hys.patch
  (git-fixes CVE-2021-47098 bsc#1220983).
- Update
  patches.suse/ipmi-Fix-UAF-when-uninstall-ipmi_si-and-ipmi_msghand.patch
  (git-fixes CVE-2021-47100 bsc#1220985).
- Update
  patches.suse/ipmi-ssif-initialize-ssif_info-client-early.patch
  (bsc#1193490 CVE-2021-47095 bsc#1220979).
- Update
  patches.suse/mac80211-fix-locking-in-ieee80211_start_ap-error-pat.patch
  (git-fixes CVE-2021-47091 bsc#1220959).
- Update
  patches.suse/net-fix-use-after-free-in-tw_timer_handler.patch
  (bsc#1217195 CVE-2021-46936 bsc#1220439).
- Update
  patches.suse/net-marvell-prestera-fix-incorrect-structure-access.patch
  (git-fixes CVE-2021-47102 bsc#1221009).
- Update
  patches.suse/net-smc-fix-kernel-panic-caused-by-race-of-smc_sock
  (git-fixes CVE-2021-46925 bsc#1220466).
- Update
  patches.suse/nitro_enclaves-Use-get_user_pages_unlocked-call-to-handle-mmap-assert.patch
  (git fixes (mm/gup) CVE-2021-46927 bsc#1220443).
- Update
  patches.suse/platform-x86-intel_pmc_core-fix-memleak-on-registrat.patch
  (git-fixes CVE-2021-47093 bsc#1220978).
- Update patches.suse/sctp-use-call_rcu-to-free-endpoint.patch
  (CVE-2022-20154 bsc#1200599 CVE-2021-46929 bsc#1220482).
- Update patches.suse/tee-optee-Fix-incorrect-page-free-bug.patch
  (jsc#SLE-21844 CVE-2021-47087 bsc#1220954).
- Update
  patches.suse/tun-avoid-double-free-in-tun_free_netdev.patch
  (bsc#1209635 CVE-2022-4744 git-fixes CVE-2021-47082
  bsc#1220969).
- Update
  patches.suse/usb-gadget-f_fs-Clear-ffs_eventfd-in-ffs_data_clear.patch
  (git-fixes CVE-2021-46933 bsc#1220487).
- Update patches.suse/usb-mtu3-fix-list_head-check-warning.patch
  (git-fixes CVE-2021-46930 bsc#1220484).
- Update
  patches.suse/veth-ensure-skb-entering-GRO-are-not-cloned.patch
  (git-fixes CVE-2021-47099 bsc#1220955).
- commit b15f74e

- wifi: ath10k: fix NULL pointer dereference in
  ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev() (bsc#1218336
  CVE-2023-7042).
- commit 1784f9f

- x86/sev: Harden #VC instruction emulation somewhat (CVE-2024-25742 bsc#1221725).
- commit 02ed75a

- dmaengine: fix NULL pointer in channel unregistration function (bsc#1221276 CVE-2023-52492)
- commit f21c2ab

- Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security
  (bsc#1219170 CVE-2024-22099).
- commit ece27a6

- perf/x86/lbr: Filter vsyscall addresses (bsc#1220703,
  CVE-2023-52476).
- commit c52b506

- fs: introduce lock_rename_child() helper (bsc#1221044
  CVE-2023-52591).
  Refresh patches.suse/fs-Establish-locking-order-for-unrelated-directories.patch
- commit 86376e0

- rename(): avoid a deadlock in the case of parents having no
  common ancestor (bsc#1221044 CVE-2023-52591).
- commit 16e3098

- kill lock_two_inodes() (bsc#1221044 CVE-2023-52591).
- commit 8b8deef

- rename(): fix the locking of subdirectories (bsc#1221044
  CVE-2023-52591).
- commit 146d81f

- f2fs: Avoid reading renamed directory if parent does not change
  (bsc#1221044 CVE-2023-52591).
- commit 5344280

- ext4: don't access the source subdirectory content on
  same-directory rename (bsc#1221044 CVE-2023-52591).
- commit b2b6374

- ext2: Avoid reading renamed directory if parent does not change
  (bsc#1221044 CVE-2023-52591).
- commit 2edcc11

- udf_rename(): only access the child content on cross-directory
  rename (bsc#1221044 CVE-2023-52591).
- commit 0257614

- ocfs2: Avoid touching renamed directory if parent does not
  change (bsc#1221044 CVE-2023-52591).
- commit e786f3a

- reiserfs: Avoid touching renamed directory if parent does not
  change (git-fixes bsc#1221044 CVE-2023-52591).
  Refresh patches.suse/reiserfs-add-check-to-detect-corrupted-directory-entry.patch
  Refresh patches.suse/reiserfs-don-t-panic-on-bad-directory-entries.patch
- commit 523ddca

- fs: don't assume arguments are non-NULL (bsc#1221044
  CVE-2023-52591).
- commit 2177893

- fs: Restrict lock_two_nondirectories() to non-directory inodes
  (bsc#1221044 CVE-2023-52591).
- commit a59a7cb

- fs: ocfs2: check status values (bsc#1221044 CVE-2023-52591).
- commit 8c6576f

- perf/x86/intel/uncore: Fix NULL pointer dereference issue in
  upi_fill_topology() (bsc#1220237, CVE-2023-52450).
- commit 246b58a

- x86/mmio: Disable KVM mitigation when X86_FEATURE_CLEAR_CPU_BUF is  set (bsc#1213456 CVE-2023-28746).
- commit 4fed4e6

- Sort upstream patches
- Refresh
  patches.suse/Documentation-hw-vuln-Add-documentation-for-RFDS.patch.
- Refresh
  patches.suse/KVM-x86-Export-RFDS_NO-and-RFDS_CLEAR-to-guests.patch.
- Refresh
  patches.suse/x86-entry-ia32-Ensure-s32-is-sign-extended-to-s64.patch.
- Refresh
  patches.suse/x86-rfds-Mitigate-Register-File-Data-Sampling-RFDS.patch.
- commit f172e12

- Refresh patches.kabi/team-Hide-new-member-header-ops.patch.
  Fix for kABI workaround.
- commit 6ba2f5d

- ceph: fix deadlock or deadcode of misusing dget() (bsc#1221058
  CVE-2023-52583).
- commit 1a81018

- netfs: Only call folio_start_fscache() one time for each folio
  (CVE-2023-52582 bsc#1220878).
- commit dfd082b

- Refresh
  patches.suse/mm-ima-kexec-of-use-memblock_free_late-from-ima_free.patch.
  Fix:
  * Section mismatch (function ima_free_kexec_buffer()) in modpost: vmlinux.o in ima_free_kexec_buffer()
  WARNING: modpost: vmlinux.o(.text+0xac1250): Section mismatch in reference from the function ima_free_kexec_buffer() to the function .init.text:__memblock_free_late()
- commit 5522f01

- Update
  patches.suse/usb-hub-Guard-against-accesses-to-uninitialized-BOS-.patch
  (bsc#1220790 CVE-2023-52477).
- commit d33bab7

- drm/radeon: check the alloc_workqueue return value in radeon_crtc_init() (bsc#1220413 CVE-2023-52470).
- commit 9d7d799

- drivers/amd/pm: fix a use-after-free in kv_parse_power_table (bsc#1220411 CVE-2023-52469).
- commit f4f0cf4

- group-source-files.pl: Quote filenames (boo#1221077).
  The kernel source now contains a file with a space in the name.
  Add quotes in group-source-files.pl to avoid splitting the filename.
  Also use -print0 / -0 when updating timestamps.
- commit a005e42

- mm,ima,kexec,of: use memblock_free_late from
  ima_free_kexec_buffer (bsc#1220872 CVE-2023-52576).
- commit b1b1c9a

- phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP (bsc#1220340,CVE-2024-26600)
- commit 78e2b4a

- erofs: fix lz4 inplace decompression (CVE-2023-52497
  bsc#1220879).
- commit ddeedf9

- ACPI: extlog: fix NULL pointer dereference check (bsc#1221039
  CVE-2023-52605).
- commit 635c481

- kernel-binary: Fix i386 build
  Fixes: 89eaf4cdce05 (&amp;quot;rpm templates: Move macro definitions below buildrequires&amp;quot;)
- commit f7c6351

- btrfs: remove BUG() after failure to insert delayed dir index
  item (bsc#1220918 CVE-2023-52569).
- btrfs: improve error message after failure to add delayed dir
  index item (bsc#1220918 CVE-2023-52569).
- commit 53e1d2d

- net: nfc: fix races in nfc_llcp_sock_get() and
  nfc_llcp_sock_get_sn() (CVE-2023-52502 bsc#1220831).
- commit 8c33586

- kabi: team: Hide new member header_ops (bsc#1220870
  CVE-2023-52574).
- commit 9f49992

- KVM: s390: fix setting of fpc register (git-fixes bsc#1220392
  bsc#1221040 CVE-2023-52597).
- commit a90b87c

- kernel-binary: vdso: fix filelist for non-usrmerged kernel
  Fixes: a6ad8af207e6 (&amp;quot;rpm templates: Always define usrmerged&amp;quot;)
- commit fb3f221

- bpf, sockmap: Reject sk_msg egress redirects to non-TCP sockets
  (bsc#1220926 CVE-2023-52523).
- commit 90d9f50

Package krb5 was updated:

- Fix memory leaks, add patch 0012-Fix-two-unlikely-memory-leaks.patch  * CVE-2024-26458, bsc#1220770
  * CVE-2024-26461, bsc#1220771

Package less was updated:

- Fix CVE-2024-32487, mishandling of \n character in paths when  LESSOPEN is set leads to OS command execution
  (CVE-2024-32487, bsc#1222849)
  * CVE-2024-32487.patch

- Fix CVE-2022-48624, LESSCLOSE handling in less does not quote shell
  metacharacters, bsc#1219901
  * CVE-2022-48624.patch

Package gcc13 was updated:

- Add gcc13-pr111731.patch to fix unwinding for JIT code.  [bsc#1221239]

- Revert libgccjit dependency change.  [boo#1220724]

- Fix libgccjit-devel dependency, a newer shared library is OK.
- Fix libgccjit dependency, the corresponding compiler isn't required.

- Use %patch -P N instead of %patchN.

- Add gcc13-sanitizer-remove-crypt-interception.patch to remove
  crypt and crypt_r interceptors.  The crypt API change in SLE15 SP3
  breaks them.  [bsc#1219520]

- Update to gcc-13 branch head, 67ac78caf31f7cb3202177e642, git8285
- Add gcc13-pr88345-min-func-alignment.diff to add support for
  - fmin-function-alignment.  [bsc#1214934]

- Use %{_target_cpu} to determine host and build.

- Update to gcc-13 branch head, fc7d87e0ffadca49bec29b2107, git8250
  * Includes fix for building TVM.  [boo#1218492]

- Add cross-X-newlib-devel requires to newlib cross compilers.
  [boo#1219031]

- Package m2rte.so plugin in the gcc13-m2 sub-package rather than
  in gcc13-devel.  [boo#1210959]
- Require libstdc++6-devel-gcc13 from gcc13-m2 as m2 programs
  are linked against libstdc++6.

- Update to gcc-13 branch head, 36ddb5230f56a30317630a928, git8205

- Update to gcc-13 branch head, 741743c028dc00f27b9c8b1d5, git8109
  * Includes fix for building mariadb on i686.  [bsc#1217667]
  * Remove pr111411.patch contained in the update.

- Avoid update-alternatives dependency for accelerator crosses.
- Package tool links to llvm in cross-amdgcn-gcc13 rather than in
  cross-amdgcn-newlib13-devel since that also has the dependence.
- Depend on llvmVER instead of llvm with VER equal to
  %product_libs_llvm_ver where available and adjust tool discovery
  accordingly.  This should also properly trigger re-builds when
  the patchlevel version of llvmVER changes, possibly changing
  the binary names we link to.  [bsc#1217450]

Package avahi was updated:

- Add avahi-CVE-2023-38471.patch: Extract host name using  avahi_unescape_label (bsc#1216594, CVE-2023-38471).
- Add avahi-CVE-2023-38469.patch: Reject overly long TXT resource
  records (bsc#1216598, CVE-2023-38469).

Package util-linux was updated:

- Properly neutralize escape sequences in wall  (util-linux-CVE-2024-28085.patch, bsc#1221831, CVE-2024-28085,
  and its prerequisites: util-linux-fputs_careful1.patch,
  util-linux-wall-migrate-to-memstream.patch
  util-linux-fputs_careful2.patch).

Package c-ares was updated:

- CVE-2024-25629.patch: fix out of bounds read in ares__read_line()  (bsc#1220279, CVE-2024-25629)

Package expat was updated:

- Security fix (boo#1221289, CVE-2024-28757): XML Entity Expansion  attack when there is isolated use of external parsers.
  * Added expat-CVE-2024-28757.patch

- Security fix:
  * (CVE-2023-52425, bsc#1219559) denial of service (resource
    consumption) caused by processing large tokens.
  - Added patch expat-CVE-2023-52425-1.patch
  - Added patch expat-CVE-2023-52425-2.patch
  - Added patch expat-CVE-2023-52425-backport-parser-changes.patch
  - Added patch expat-CVE-2023-52425-fix-tests.patch

Package gnutls was updated:

- Security fix: [bsc#1221747, CVE-2024-28835]  * gnutls: certtool crash when verifying a certificate chain
  * Add gnutls-CVE-2024-28835.patch

- Security fix: [bsc#1221746, CVE-2024-28834]
  * gnutls: side-channel in the deterministic ECDSA
  * Add gnutls-CVE-2024-28834.patch

- jitterentropy: Release the memory of the entropy collector when
  using jitterentropy with phtreads as there is also a
  pre-intitization done in the main thread. [bsc#1221242]
  * Add gnutls-FIPS-jitterentropy-deinit-threads.patch

Package jitterentropy was updated:

- Fix a stack corruption on s390x: [bsc#1209627]  * Output size of the STCKE command on s390x is 16 bytes, compared
    to 8 bytes of the STCK command. Fix a stack corruption in the
    s390x version of jent_get_nstime(). Add some more detailed
    information on the STCKE command.
  * github.com/smuellerDD/jitterentropy-library/commit/7bf9f85
  * Add jitterentropy-fix-a-stack-corruption-on-s390x.patch

Package ncurses was updated:

- Add patch ncurses-6.1-bsc1220061.patch (bsc#1220061, CVE-2023-45918)  * Backport from ncurses-6.4-20230615.patch
    improve checks in convert_string() for corrupt terminfo entry

Package nghttp2 was updated:

- security update- added patches
  fix CVE-2024-28182 [bsc#1221399], HTTP/2 CONTINUATION frames can be utilized for DoS attacks
  + nghttp2-CVE-2024-28182-1.patch
  fix CVE-2024-28182-2 [bsc#1221399], HTTP/2 CONTINUATION frames can be utilized for DoS attacks
  + nghttp2-CVE-2024-28182-2.patch

Package openssl-1_1 was updated:

- Security fix: [bsc#1222548, CVE-2024-2511]  * Fix unconstrained session cache growth in TLSv1.3
  * Add openssl-CVE-2024-2511.patch

Package protobuf was updated:

- update to 25.1:  * Raise warnings for deprecated python syntax usages
  * Add support for extensions in CRuby, JRuby, and FFI Ruby
  * Add support for options in CRuby, JRuby and FFI (#14594)
- update to 25.0:
  * Implement proto2/proto3 with editions
  * Defines Protobuf compiler version strings as macros and
    separates out suffix string definition.
  * Add utf8_validation feature back to the global feature set.
  * Setting up version updater to prepare for poison pills and
    embedding version info into C++, Python and Java gencode.
  * Merge the protobuf and upb Bazel repos
  * Editions: Introduce functionality to protoc for generating
    edition feature set defaults.
  * Editions: Migrate edition strings to enum in C++ code.
  * Create a reflection helper for ExtensionIdentifier.
  * Editions: Provide an API for C++ generators to specify their
    features.
  * Editions: Refactor feature resolution to use an intermediate
    message.
  * Publish extension declarations with declaration
    verifications.
  * Editions: Stop propagating partially resolved feature sets to
    plugins.
  * Editions: Migrate string_field_validation to a C++ feature
  * Editions: Include defaults for any features in the generated
    pool.
  * Protoc: parser rejects explicit use of map_entry option
  * Protoc: validate that reserved range start is before end
  * Protoc: support identifiers as reserved names in addition to
    string literals (only in editions)
  * Drop support for Bazel 5.
  * Allow code generators to specify whether or not they support
    editions.
  [#] C++
  * Set `PROTOBUF_EXPORT` on
    `InternalOutOfLineDeleteMessageLite()`
  * Update stale checked-in files
  * Apply PROTOBUF_NOINLINE to declarations of some functions
    that want it.
  * Implement proto2/proto3 with editions
  * Make JSON UTF-8 boundary check inclusive of the largest
    possible UTF-8 character.
  * Reduce `Map::size_type` to 32-bits. Protobuf containers can't
    have more than that
  * Defines Protobuf compiler version strings as macros and
    separates out suffix string definition.
  * Add `ABSL_ATTRIBUTE_LIFETIME_BOUND` attribute on generated
    oneof accessors.
  * Fix bug in reflection based Swap of map fields.
  * Add utf8_validation feature back to the global feature set.
  * Setting up version updater to prepare for poison pills and
    embedding version info into C++, Python and Java gencode.
  * Add prefetching to arena allocations.
  * Add `ABSL_ATTRIBUTE_LIFETIME_BOUND` attribute on generated
    repeated and map field accessors.
  * Editions: Migrate edition strings to enum in C++ code.
  * Create a reflection helper for ExtensionIdentifier.
  * Editions: Provide an API for C++ generators to specify their
    features.
  * Add `ABSL_ATTRIBUTE_LIFETIME_BOUND` attribute on generated
    string field accessors.
  * Editions: Refactor feature resolution to use an intermediate
    message.
  * Fixes for 32-bit MSVC.
  * Publish extension declarations with declaration
    verifications.
  * Export the constants in protobuf's any.h to support DLL
    builds.
  * Implement AbslStringify for the Descriptor family of types.
  * Add `ABSL_ATTRIBUTE_LIFETIME_BOUND` attribute on generated
    message field accessors.
  * Editions: Stop propagating partially resolved feature sets to
    plugins.
  * Editions: Migrate string_field_validation to a C++ feature
  * Editions: Include defaults for any features in the generated
    pool.
  * Introduce C++ feature for UTF8 validation.
  * Protoc: validate that reserved range start is before end
  * Remove option to disable the table-driven parser in protoc.
  * Lock down ctype=CORD in proto file.
  * Support split repeated fields.
  * In OSS mode omit some extern template specializations.
  * Allow code generators to specify whether or not they support
    editions.
  [#] Java
  * Implement proto2/proto3 with editions
  * Remove synthetic oneofs from Java gencode field accessor
    tables.
  * Timestamps.parse: Add error handling for invalid
    hours/minutes in the timezone offset.
  * Defines Protobuf compiler version strings as macros and
    separates out suffix string definition.
  * Add `ABSL_ATTRIBUTE_LIFETIME_BOUND` attribute on generated
    oneof accessors.
  * Add missing debugging version info to Protobuf Java gencode
    when multiple files are generated.
  * Fix a bad cast in putBuilderIfAbsent when already present due
    to using the result of put() directly (which is null if it
    currently has no value)
  * Setting up version updater to prepare for poison pills and
    embedding version info into C++, Python and Java gencode.
  * Fix a NPE in putBuilderIfAbsent due to using the result of
    put() directly (which is null if it currently has no value)
  * Update Kotlin compiler to escape package names
  * Add MapFieldBuilder and change codegen to generate it and the
    put{field}BuilderIfAbsent method.
  * Introduce recursion limit in Java text format parsing
  * Consider the protobuf.Any invalid if typeUrl.split(&amp;quot;/&amp;quot;)
    returns an empty array.
  * Mark `FieldDescriptor.hasOptionalKeyword()` as deprecated.
  * Fixed Python memory leak in map lookup.
  * Loosen upb for json name conflict check in proto2 between
    json name and field
  * Defines Protobuf compiler version strings as macros and
    separates out suffix string definition.
  * Add `ABSL_ATTRIBUTE_LIFETIME_BOUND` attribute on generated
    oneof accessors.
  * Ensure Timestamp.ToDatetime(tz) has correct offset
  * Do not check required field for upb python MergeFrom
  * Setting up version updater to prepare for poison pills and
    embedding version info into C++, Python and Java gencode.
  * Merge the protobuf and upb Bazel repos
  * Comparing a proto message with an object of unknown returns
    NotImplemented
  * Emit __slots__ in pyi output as a tuple rather than a list
    for --pyi_out.
  * Fix a bug that strips options from descriptor.proto in
    Python.
  * Raise warings for message.UnknownFields() usages and navigate
    to the new add
  * Add protobuf python keyword support in path for stub
    generator.
  * Add tuple support to set Struct
  * ### Python C-Extension (Default)
  * Comparing a proto message with an object of unknown returns
    NotImplemented
  * Check that ffi-compiler loads before using it to define
    tasks.
  [#] UPB (Python/PHP/Ruby C-Extension)
  * Include .inc files directly instead of through a filegroup
  * Loosen upb for json name conflict check in proto2 between
    json name and field
  * Add utf8_validation feature back to the global feature set.
  * Do not check required field for upb python MergeFrom
  * Merge the protobuf and upb Bazel repos
  * Added malloc_trim() calls to Python allocator so RSS will
    decrease when memory is freed
  * Upb: fix a Python memory leak in ByteSize()
  * Support ASAN detection on clang
  * Upb: bugfix for importing a proto3 enum from within a proto2
    file
  * Expose methods needed by Ruby FFI using UPB_API
  * Fix `PyUpb_Message_MergeInternal` segfault

- build against modern python on sle15

- Build with source and target levels 8
  * fixes build with JDK21
- Install the pom file with the new %%mvn_install_pom macro
- Do not install the pom-only artifacts, since the %%mvn_install_pom
  macro resolves the variables at the install time

- update to 23.4:
  * Add dllexport_decl for generated default instance.
  * Deps: Update Guava to 32.0.1

- update to 23.3:
  C++
  * Regenerate stale files
  * Use the same ABI for static and shared libraries on non-
    Windows platforms
  * Add a workaround for GCC constexpr bug
  Objective-C
  * Regenerate stale files
  UPB (Python/PHP/Ruby C-Extension)
  * Fixed a bug in `upb_Map_Delete()` that caused crashes in
    map.delete(k) for Ruby when string-keyed maps were in use.
  Compiler
  * Add missing header to Objective-c generator
  * Add a workaround for GCC constexpr bug
  Java
  * Rollback of: Simplify protobuf Java message builder by
    removing methods that calls the super class only.
  Csharp
  * [C#] Replace regex that validates descriptor names
- drop 0001-Use-the-same-ABI-for-static-and-shared-libraries-on-.patch (upstream)

- Add patch to fix linking ThreadSafeArena:
  * 0001-Use-the-same-ABI-for-static-and-shared-libraries-on-.patch
- Drop the protobuf-source package, no longer used

- update to 22.5:
  C++
  * Add missing cstdint header
  * Fix: missing -DPROTOBUF_USE_DLLS in pkg-config (#12700)
  * Avoid using string(JOIN..., which requires cmake 3.12
  * Explicitly include GTest package in examples
  * Bump Abseil submodule to 20230125.3 (#12660)
- update to 22.4:
  C++
  * Fix libprotoc: export useful symbols from .so
  * Fix btree issue in map tests.
  Python
  * Fix bug in _internal_copy_files where the rule would fail in
    downstream repositories.
  Other
  * Bump utf8_range to version with working pkg-config (#12584)
  * Fix declared dependencies for pkg-config
  * Update abseil dependency and reorder dependencies to ensure
    we use the version specified in protobuf_deps.
  * Turn off clang::musttail on i386

- drop python2 handling
- fix version handling and package the private libs again

- Fix confusion in versions

- Mention the rpmlintrc file in the spec.

- Make possible to build on older systems, like SLE12 that miss
  some of the used macros.

- update to v22.3
  UPB (Python/PHP/Ruby C-Extension)
  * Remove src prefix from proto import
  * Fix .gitmodules to use the correct absl branch
  * Remove erroneous dependency on googletest
- update to 22.2:
  Java
  * Add version to intra proto dependencies and add kotlin stdlib
    dependency
  * Add $ back for osgi header
  * Remove $ in pom files
- update to 22.1:
  * Add visibility of plugin.proto to python directory
  * Strip &amp;quot;src&amp;quot; from file name of plugin.proto
  * Add OSGi headers to pom files.
  * Remove errorprone dependency from kotlin protos.
  * Version protoc according to the compiler version number.
- update to 22.0:
  * This version includes breaking changes to: Cpp.
    Please refer to the migration guide for information:
    https://protobuf.dev/support/migration/#compiler-22
  * [Cpp] Migrate to Abseil's logging library.
  * [Cpp] `proto2::Map::value_type` changes to `std::pair`.
  * [Cpp] Mark final ZeroCopyInputStream, ZeroCopyOutputStream,
    and DefaultFieldComparator classes.
  * [Cpp] Add a dependency on Abseil (#10416)
  * [Cpp] Remove all autotools usage (#10132)
  * [Cpp] Add C++20 reserved keywords
  * [Cpp] Dropped C++11 Support
  * [Cpp] Delete Arena::Init
  * [Cpp] Replace JSON parser with new implementation
  * [Cpp] Make RepeatedField::GetArena non-const in order to
    support split RepeatedFields.
  * long list of bindings specific fixes see
    https://github.com/protocolbuffers/protobuf/releases/tag/v22.0
- python sub packages version is set 4.22.3 as defined in
  python/google/protobuf/__init__.py to stay compatible
- skip python2 builds by default
- drop patches:
  * 10355.patch,
  * gcc12-disable-__constinit-with-c++-11.patch (merged upstream)
- added patches:
  * add-missing-stdint-header.patch   added for compile fixes

- Enable LTO (boo#1133277).

- update to v21.12:
  * Python
  * Fix broken enum ranges (#11171)
  * Stop requiring extension fields to have a sythetic oneof (#11091)
  * Python runtime 4.21.10 not works generated code can not load valid
    proto.

- update to 21.11:
  * Python
  * Add license file to pypi wheels (#10936)
  * Fix round-trip bug (#10158)

- update to 21.10:
  * Java
  * Use bit-field int values in buildPartial to skip work on unset groups of
    fields. (#10960)
  * Mark nested builder as clean after clear is called (#10984)

- update to 21.9:
  * Ruby
  * Replace libc strdup usage with internal impl to restore musl compat (#10818)
  * Auto capitalize enums name in Ruby (#10454) (#10763)
  * Other
  * Fix for grpc.tools #17995 &amp;amp; protobuf #7474 (handle UTF-8 paths in argumentfile) (#10721)
  * C++
  * 21.x No longer define no_threadlocal on OpenBSD (#10743)
  * Java
  * Mark default instance as immutable first to avoid race during static initialization of default instances (#10771)
  * Refactoring java full runtime to reuse sub-message builders and prepare to
    migrate parsing logic from parse constructor to builder.
  * Move proto wireformat parsing functionality from the private &amp;quot;parsing
    constructor&amp;quot; to the Builder class.
  * Change the Lite runtime to prefer merging from the wireformat into mutable
    messages rather than building up a new immutable object before merging. This
    way results in fewer allocations and copy operations.
  * Make message-type extensions merge from wire-format instead of building up
    instances and merging afterwards. This has much better performance.
  * Fix TextFormat parser to build up recurring (but supposedly not repeated)
    sub-messages directly from text rather than building a new sub-message and
    merging the fully formed message into the existing field.

- update to 21.6:
  C++:
  * Reduce memory consumption of MessageSet parsing

- update to 21.5:
  PHP
  * Added getContainingOneof and getRealContainingOneof to descriptor.
  * fix PHP readonly legacy files for nested messages
  Python
  * Fixed comparison of maps in Python.

- add 10355.patch to fix soversioning

- update to 21.4:
  * Reduce the required alignment of ArenaString from 8 to 4

- update to 21.3:
  * C++
  * Add header search paths to Protobuf-C++.podspec (#10024)
  * Fixed Visual Studio constinit errors (#10232)
  * Fix #9947: make the ABI compatible between debug and non-debug builds (#10271)
  * UPB
  * Allow empty package names (fixes behavior regression in 4.21.0)
  * Fix a SEGV bug when comparing a non-materialized sub-message (#10208)
  * Fix several bugs in descriptor mapping containers (eg. descriptor.services_by_name)
  * for x in mapping now yields keys rather than values, to match Python
    conventions and the behavior of the old library.
  * Lookup operations now correctly reject unhashable types as map keys.
  * We implement repr() to use the same format as dict.
  * Fix maps to use the ScalarMapContainer class when appropriate
  * Fix bug when parsing an unknown value in a proto2 enum extension (protocolbuffers/upb#717)
  * PHP
  * Add &amp;quot;readonly&amp;quot; as a keyword for PHP and add previous classnames to descriptor pool (#10041)
  * Python
  * Make //:protobuf_python and //:well_known_types_py_pb2 public (#10118)
  * Bazel
  * Add back a filegroup for :well_known_protos (#10061)

- Update to 21.2:
- C++
  - cmake: Call get_filename_component() with DIRECTORY mode instead of PATH mode (#9614)
  - Escape GetObject macro inside protoc-generated code (#9739)
  - Update CMake configuration to add a dependency on Abseil (#9793)
  - Fix cmake install targets (#9822)
  - Use __constinit only in GCC 12.2 and up (#9936)
- Java
  - Update protobuf_version.bzl to separate protoc and per-language java â¦ (#9900)
- Python
  - Increment python major version to 4 in version.json for python upb (#9926)
  - The C extension module for Python has been rewritten to use the upb library.
  - This is expected to deliver significant performance benefits, especially when
    parsing large payloads. There are some minor breaking changes, but these
    should not impact most users. For more information see:
    https://developers.google.com/protocol-buffers/docs/news/2022-05-06#python-updates
- PHP
  - [PHP] fix PHP build system (#9571)
  - Fix building packaged PHP extension (#9727)
  - fix: reserve &amp;quot;ReadOnly&amp;quot; keyword for PHP 8.1 and add compatibility (#9633)
  - fix: phpdoc syntax for repeatedfield parameters (#9784)
  - fix: phpdoc for repeatedfield (#9783)
  - Change enum string name for reserved words (#9780)
  - chore: [PHP] fix phpdoc for MapField keys (#9536)
  - Fixed PHP SEGV by not writing to shared memory for zend_class_entry. (#9996)
- Ruby
  - Allow pre-compiled binaries for ruby 3.1.0 (#9566)
  - Implement respond_to? in RubyMessage (#9677)
  - [Ruby] Fix RepeatedField#last, #first inconsistencies (#9722)
  - Do not use range based UTF-8 validation in truffleruby (#9769)
  - Improve range handling logic of RepeatedField (#9799)
- Other
  - Fix invalid dependency manifest when using descriptor_set_out (#9647)
  - Remove duplicate java generated code (#9909)

- Do not use %%autosetup, but %%setup and %%patch on other line
  * Allows building on SLE-12-SP5

- Add temporary patch gcc12-disable-__constinit-with-c++-11.patch
  that addresses gh#protocolbuffers/protobuf#9916.

Package python3 was updated:

- Add bpo38361-syslog-no-slash-ident.patch (bsc#1222109,  gh#python/cpython!16557) fixes syslog making default &amp;quot;ident&amp;quot;
  from sys.argv[0].

Package suseconnect-ng was updated:

- Update to version 1.9.0  * Fix certificate import for Yast when using a registration proxy with
    self-signed SSL certificate (bsc#1223107)

- Update to version 1.8.0
  * Allow &amp;quot;--rollback&amp;quot; flag to run on readonly filesystem (bsc#1220679)

Package libzypp was updated:

- Don't try to refresh volatile media as long as raw metadata are  present (bsc#1223094)
- version 17.32.5 (32)

- Fix creation of sibling cache dirs with too restrictive mode
  (bsc#1222398)
  Some install workflows in YAST may lead to too restrictive (0700)
  raw cache directories in case of newly created repos. Later
  commands running with user privileges may not be able to access
  these repos.
- version 17.32.4 (32)

- Update RepoStatus fromCookieFile according to the files mtime
  (bsc#1222086)
- TmpFile: Don't call chmod if makeSibling failed.
- version 17.32.3 (32)

- Fixup New VendorSupportOption flag VendorSupportSuperseded
  (jsc#OBS-301, jsc#PED-8014)
  Fixed the name of the keyword to &amp;quot;support_superseded&amp;quot; as it was
  agreed on in jsc#OBS-301.
- version 17.32.2 (32)

- Add resolver option 'removeUnneeded' to file weak remove jobs
  for unneeded packages (bsc#1175678)
- version 17.32.1 (32)

- Add resolver option 'removeOrphaned' for distupgrade
  (bsc#1221525)
- New VendorSupportOption flag VendorSupportSuperseded
  (jsc#OBS-301, jsc#PED-8014)
- Tests: fix vsftpd.conf where SUSE and Fedora use different
  defaults (fixes #522)
- Add default stripe minimum (#529)
- Don't expose std::optional where YAST/PK explicitly use c++11.
- Digest: Avoid using the deprecated OPENSSL_config.
- version 17.32.0 (32)

- ProblemSolution::skipsPatchesOnly overload to handout the
  patches.
- Remove https-&amp;gt;http redirection exceptions for
  download.opensuse.org.
- version 17.31.32 (22)

Package shadow was updated:

- bsc#1176006: Fix chage date miscalculation  Add shadow-bsc1176006-chage-date.patch
- bsc#1188307: Fix passwd segfault
  Add shadow-bsc1188307-passwd-segfault.patch
- bsc#1203823: Remove pam_keyinit from PAM config files
  Remove pam_keyinit from PAM configuration.
  This was introduced for bsc#1144060.

Package openssh was updated:

- Add patches from upstream to change the default value of  UpdateHostKeys to Yes (unless VerifyHostKeyDNS is enabled).
  This makes ssh update the known_hosts stored keys with all
  published versions by the server (after it's authenticated
  with an existing key), which will allow to identify the
  server with a different key if the existing key is considered
  insecure at some point in the future (bsc#1222831).
  * 0001-upstream-enable-UpdateHostkeys-by-default-when-the.patch
  * 0002-upstream-disable-UpdateHostkeys-by-default-if.patch

- Add patches openssh-7.7p1-seccomp_getuid.patch and
  openssh-bsc1216474-s390-leave-fds-open.patch
  (bsc#1216474, bsc#1218871)

- Fix hostbased ssh login failing occasionally with &amp;quot;signature
  unverified: incorrect signature&amp;quot; by fixing a typo in patch
  (bsc#1221123):
  * openssh-7.8p1-role-mls.patch

Package pam-config was updated:

- Fix pam_gnome_keyring module for AUTH.  [pam-config-fix-pam_gnome_keyring.patch, bsc#1219767]

Package perl-Bootloader was updated:

- merge gh#openSUSE/perl-bootloader#166- log grub2-install errors correctly (bsc#1221470)
- 0.947

- merge gh#openSUSE/perl-bootloader#161
- support old grub versions (&amp;lt;= 2.02) that used /usr/lib
  (bsc#1218842)
- create EFI boot fallback directory if necessary
- 0.946

Package perl was updated:

- fix space calculation issues in pp_pack.c [bnc#1082216]  [CVE-2018-6913]
  * new patch: perl-pack-overflow.diff
- fix heap buffer overflow in regexec.c [bnc#1082233]
  [CVE-2018-6798]
  new patch: perl-regexec-heap-overflow.diff
- make Net::FTP work with TLS 1.3 [bnc#1213638]
  new patch: perl-net-ftp-tls13.diff

Package python-Jinja2 was updated:

- Add CVE-2024-34064.patch upstream patch  (CVE-2024-34064, bsc#1223980, gh#pallets/jinja@0668239dc6b4)
  Also fixes (CVE-2024-22195, bsc#1218722)

Package python-idna was updated:

- Add CVE-2024-3651.patch, backported from upstream commit  gh#kjd/idna#172/commits/5beb28b9dd77912c0dd656d8b0fdba3eb80222e7
  (bsc#1222842, CVE-2024-3651)

Package python-requests was updated:

- Add CVE-2024-35195.patch (CVE-2024-35195, bsc#1224788)- Add httpbin.patch to fix a test failure caused by the previous patch.

Package salt was updated:

- Make &amp;quot;man&amp;quot; a recommended package instead of required
- Convert oscap output to UTF-8
- Make Salt compatible with Python 3.11
- Ignore non-ascii chars in oscap output (bsc#1219001)
- Fix detected issues in Salt tests when running on VMs
- Make importing seco.range thread safe (bsc#1211649)
- Fix problematic tests and allow smooth tests executions
  on containers
- Discover Ansible playbook files as &amp;quot;*.yml&amp;quot; or &amp;quot;*.yaml&amp;quot;
  files (bsc#1211888)
- Provide user(salt)/group(salt) capabilities for RPM 4.19
- Extend dependencies for python3-salt-testsuite
  and python3-salt packages
- Improve Salt and testsuite packages multibuild
- Enable multibuilld and create test flavor
- Prevent exceptions with fileserver.update when called
  via state (bsc#1218482)
- Improve pip target override condition with VENV_PIP_TARGET
  environment variable (bsc#1216850)
- Fixed KeyError in logs when running a state that fails
- Added:
  * fixed-keyerror-in-logs-when-running-a-state-that-fai.patch
  * decode-oscap-byte-stream-to-string-bsc-1219001.patch
  * fix-salt-warnings-and-testuite-for-python-3.11-635.patch
  * make-importing-seco.range-thread-safe-bsc-1211649.patch
  * improve-pip-target-override-condition-with-venv_pip_.patch
  * allow-kwargs-for-fileserver-roots-update-bsc-1218482.patch
  * fix-problematic-tests-and-allow-smooth-tests-executi.patch
  * discover-both-.yml-and-.yaml-playbooks-bsc-1211888.patch
  * fix-tests-failures-and-errors-when-detected-on-vm-ex.patch
  * switch-oscap-encoding-to-utf-8-639.patch

Package spacewalk-certs-tools was updated:

- version 4.3.23-0  * Fix liberty bootstrapping when zypper is installed (bsc#1222347)
  * Apply reboot method changes for transactional systems in the bootstrap script

Package spacewalk-client-tools was updated:

- version 4.3.19-0  * Update translation strings

Package uyuni-common-libs was updated:

- version 4.3.10-0  * Add support for package signature type V4 RSA/SHA384
  * Add support for package signature type V4 RSA/SHA512 (bsc#1221465)

Package release-notes-susemanager-proxy was updated:

- Update to SUSE Manager 4.3.12  * Bugs mentioned:
    bsc#1208572, bsc#1214387, bsc#1217204, bsc#1220980, bsc#1221465
    bsc#1222347, bsc#1220001

Package rpm was updated:

- implement subkey binding signature checking [bsc#1191175]  * new patch: verifybindingsig.diff

- accept more signature subpackets marked as critical [bsc#1218686]
  * new patch: accept-crit-subpkt.diff
- backport limit support for the autopatch macro [bsc#1189495]
  * new patch: autopatch.diff

- backport signature reserved space handling from upstream
  * new patch: sigreserved.diff

- turn on imaevm file signature support and move the imaevm code
  that needs the libimaevm library into a plugin. Put this
  plugin into a new &amp;quot;rpm-imaevmsign&amp;quot; subpackage. [jsc#PED-7246]
  * new patch: imaevmsignplugin.diff

Package rpm-ndb was updated:

Package runc was updated:

- Add upstream patch &amp;lt;https://github.com/opencontainers/runc/pull/4219&amp;gt; to  properly fix -ENOSYS stub on ppc64le. bsc#1192051 bsc#1221050
  + 0001-bsc1221050-libct-seccomp-patchbpf-rm-duplicated-code.patch
  + 0002-bsc1221050-seccomp-patchbpf-rename-nativeArch-linuxA.patch
  + 0003-bsc1221050-seccomp-patchbpf-always-include-native-ar.patch

Package sed was updated:

- 0001-sed-set-correct-umask-on-temporary-files.patch  Fix for bsc#1221218

Package 000release-packages:sle-module-basesystem-release was updated:

Package 000release-packages:sle-module-containers-release was updated:

Package 000release-packages:sle-module-public-cloud-release was updated:

Package 000release-packages:sle-module-server-applications-release was updated:

Package 000product:sle-module-suse-manager-proxy-release was updated:

Package spacewalk-backend was updated:

- version 4.3.28-0  * Strip whitespace from .deb package metadata (bsc#1214387)
  * Fix inserting NULL into some columns during ISSv1 sync (bsc#1220980)
  * Add support for package signature type V4 RSA/SHA512 (bsc#1221465)
  * Unquote HTML-encoded credentials before synchronizing repositories (bsc#1217204)

Package spacewalk-web was updated:

- version 4.3.38-0  * Upgrade json5 to 2.2.3
  * Upgrade semver to 7.6.0
  * Add one-shot action execution to recurring custom state
    create/edit
  * Add two filters for rpmlint in package spacewalk-web:
    explicit-lib-dependency and filename-too-long-for-joliet
  * Added: spacewalk-web-rpmlintrc
  * Fix virtual systems filters (bsc#1208572)
  * Improve CLM Create New Filter button
  * Bump the WebUI version to 4.3.12

Package squid was updated:

- CVE-2024-33427.patch: fixes possible buffer overread leading to  denial of service (bsc#1225417, CVE-2024-33427)

- SQUID-2024_2.patch: Fixes denial of service in HTTP header parser
  (bsc#1219960, CVE-2024-25617)

- SQUID-2024_1.patch: Fixes Chunked Encoding Stack Overflow
  (bsc#1216715, CVE-2024-25111)

Package supportutils was updated:

- Changes in version 3.1.30  + Added -V key:value pair option (bsc#1222021, PED-8211)
  + Avoid getting duplicate kernel verifications in boot.text (pr#193)
  + Suppress file descriptor leak warnings from lvm commands (pr#192, bsc#1220082)
  + Includes container log timestamps (pr#197)

- Changes to version 3.1.29
  + Extended scaling for performance (bsc#1214713)
  + Fixed kdumptool output error (bsc#1218632)
  + Corrected podman ID errors (bsc#1218812)
  + Duplicate non root podman entries removed (bsc#1218814)
  + Corrected get_sles_ver for SLE Micro (bsc#1219241)
  + Check nvidida-persistenced state (bsc#1219639)

Package systemd-default-settings was updated:

- Import 0.10  5088997 SLE: Disable pids controller limit under user instances (jsc#SLE-10123)

- Import 0.9
  bb859bf user@.service: Disable controllers by default (jsc#PED-2276)

- The usage of drop-ins is now the official way for configuring systemd and its
  various daemons on Factory/ALP. Hence the early drop-ins SUSE specific
  &amp;quot;feature&amp;quot; has been abandoned.

- Import 0.8
  f34372f User priority '26' for SLE-Micro
  c8b6f0a Revert &amp;quot;Convert more drop-ins into early ones&amp;quot;

- Import commit 6b8dde1d4f867aff713af6d6830510a84fad58d2
  6b8dde1 Convert more drop-ins into early ones

Package systemd-presets-branding-SLE was updated:

Package systemd-presets-common-SUSE was updated:

- Split hcn-init.service to hcn-init-NetworkManager and hcn-init-wicked  (bsc#1200731 ltc#198485 https://github.com/ibm-power-utilities/powerpc-utils/pull/84)
  Support both the old and new service to avoid complex version interdependency.

Package systemd-rpm-macros was updated:

- Bump version to 15
- Order packages that requires systemd after systemd-sysvcompat when this part
  of the transaction (bsc#1217964)
  systemd-sysvcompat has been introduced recently and contains the compatibility
  scripts used to support SysV init scripts. Make sure that the packages ordered
  after systemd are also ordered after systemd-sysvcompat so theirs rpm
  scriptlets can still rely on the compat scripts.
  On distributions where systemd-sysvcompat doesn't exist, the new ordering
  constraint should be a nop.

Package util-linux-systemd was updated:

- Properly neutralize escape sequences in wall  (util-linux-CVE-2024-28085.patch, bsc#1221831, CVE-2024-28085,
  and its prerequisites: util-linux-fputs_careful1.patch,
  util-linux-wall-migrate-to-memstream.patch
  util-linux-fputs_careful2.patch).

- Add upstream patch
  more-exit-if-POLLERR-and-POLLHUP-on-stdin-is-received.patch
  bsc#1220117 - L3-Question: Processes not cleaned up after failed SSH session are using up 100% CPU

- Add upstream patch
  util-linux-libuuid-avoid-truncate-clocks.txt-to-improve-perform.patch
  bsc#1207987 gh#util-linux/util-linux@1d98827edde4

Package vim was updated:

- Updated to version 9.1 with patch level 0330, fixes the following problems  * Fixing bsc#1220763 - vim gets Segmentation fault after updating to version 9.1.0111-150500.20.9.1
- refreshed vim-7.3-filetype_spec.patch
- refreshed vim-7.3-filetype_ftl.patch
- Update spec.skeleton to use autosetup in place of setup macro.
- for the complete list of changes see
  https://github.com/vim/vim/compare/v9.1.0111...v9.1.0330

Package wicked was updated:

- client: fix ifreload to pull UP ports/links again when the config  of their master/lower changed (bsc#1224100,gh#openSUSE/wicked#1014).
  [+ 0001-ifreload-pull-UP-again-on-master-lower-changes-bsc1224100.patch]

- Update to version 0.6.75:
  - cleanup: fix ni_fsm_state_t enum-int-mismatch warnings
  - cleanup: fix overflow warnings in a socket testcase on i586
  - ifcheck: report new and deleted configs as changed (bsc#1218926)
  - man: improve ARP configuration options in the wicked-config.5
  - bond: add ports when master is UP to avoid port MTU revert (bsc#1219108)
  - cleanup: fix interface dependencies and shutdown order (bsc#1205604)
  - Remove port arrays from bond,team,bridge,ovs-bridge (redundant)
    and consistently use config and state info attached to the port
    interface as in rtnetlink(7).
  - Cleanup ifcfg parsing, schema configuration and service properties
  - Migrate ports in xml config and policies already applied in nanny
  - Remove &amp;quot;missed config&amp;quot; generation from finite state machine, which
    is completed while parsing the config or while xml config migration.
  - Issue a warning when &amp;quot;lower&amp;quot; interface (e.g. eth0) config is missed
    while parsing config depending on it (e.g. eth0.42 vlan).
  - Resolve ovs master to the effective bridge in config and wickedd
  - Implement netif-check-state require checks using system relations
    from wickedd/kernel instead of config relations for ifdown and add
    linkDown and deleteDevice checks to all master and lower references.
  - Add a `wicked &amp;lt;ifup|ifdown|ifreload&amp;gt; --dry-run â¦` option to show the
    system/config interface hierarchies as notice with +/- marked
    interfaces to setup and/or shutdown.
- Removed patches included in the source archive:
  [- 0001-addrconf-fix-fallback-lease-drop-bsc-1220996.patch]
  [- 0002-extensions-nbft-replace-nvme-show-nbft-with-nvme-nbf.patch]
  [- 0003-move-all-attribute-definitions-to-compiler-h.patch]
  [- 0004-hide-secrets-in-debug-log-bsc-1221194.patch]
  [- 0005-client-do-to-not-convert-sec-to-msec-twice-bsc-1222105.patch]

- client: do not convert sec to msec twice (bsc#1222105)
  [+ 0005-client-do-to-not-convert-sec-to-msec-twice-bsc-1222105.patch]

- addrconf: fix fallback-lease drop (bsc#1220996)
  [+ 0001-addrconf-fix-fallback-lease-drop-bsc-1220996.patch]
- extensions/nbft: use upstream `nvme nbft show` (bsc#1221358)
  [+ 0002-extensions-nbft-replace-nvme-show-nbft-with-nvme-nbf.patch]
- hide secrets in debug log (bsc#1221194)
  [+ 0003-move-all-attribute-definitions-to-compiler-h.patch]
  [+ 0004-hide-secrets-in-debug-log-bsc-1221194.patch]

Package xen was updated:

- Update to Xen 4.16.6 security bug fix release (bsc#1027519)  xen-4.16.6-testing-src.tar.bz2
  * No upstream changelog found in sources or webpage
- bsc#1221984 - VUL-0: CVE-2023-46842: xen: x86 HVM hypercalls may
  trigger Xen bug check (XSA-454)
- bsc#1222302 - VUL-0: CVE-2024-31142: xen: x86: Incorrect logic
  for BTC/SRSO mitigations (XSA-455)
- bsc#1222453 - VUL-0: CVE-2024-2201: xen: x86: Native Branch
  History Injection (XSA-456)
- Dropped patches contained in new tarball
  64e5b4ac-x86-AMD-extend-Zenbleed-check.patch
  64e6459b-revert-VMX-sanitize-rIP-before-reentering.patch
  64eef7e9-x86-reporting-spurious-i8259-interrupts.patch
  64f71f50-Arm-handle-cache-flush-at-top.patch
  65087000-x86-spec-ctrl-SPEC_CTRL_EXIT_TO_XEN-confusion.patch
  65087001-x86-spec-ctrl-fold-DO_SPEC_CTRL_EXIT_TO_XEN.patch
  65087002-x86-spec-ctrl-SPEC_CTRL-ENTRY-EXIT-asm-macros.patch
  65087003-x86-spec-ctrl-SPEC_CTRL-ENTER-EXIT-comments.patch
  65087004-x86-entry-restore_all_xen-stack_end.patch
  65087005-x86-entry-track-IST-ness-of-entry.patch
  65087006-x86-spec-ctrl-VERW-on-IST-exit-to-Xen.patch
  65087007-x86-AMD-Zen-1-2-predicates.patch
  65087008-x86-spec-ctrl-Zen1-DIV-leakage.patch
  650abbfe-x86-shadow-defer-PV-top-level-release.patch
  65263470-AMD-IOMMU-flush-TLB-when-flushing-DTE.patch
  65263471-libfsimage-xfs-remove-dead-code.patch
  65263472-libfsimage-xfs-amend-mask32lo.patch
  65263473-libfsimage-xfs-sanity-check-superblock.patch
  65263474-libfsimage-xfs-compile-time-check.patch
  65263475-pygrub-remove-unnecessary-hypercall.patch
  65263476-pygrub-small-refactors.patch
  65263477-pygrub-open-output-files-earlier.patch
  65263478-libfsimage-function-to-preload-plugins.patch
  65263479-pygrub-deprivilege.patch
  6526347a-libxl-allow-bootloader-restricted-mode.patch
  6526347b-libxl-limit-bootloader-when-restricted.patch
  6526347c-SVM-fix-AMD-DR-MASK-context-switch-asymmetry.patch
  6526347d-x86-PV-auditing-of-guest-breakpoints.patch
  65536847-AMD-IOMMU-correct-level-for-quarantine-pt.patch
  65536848-x86-spec-ctrl-remove-conditional-IRQs-on-ness.patch
  xsa440.patch
  xsa449.patch
  xsa451.patch
  xsa452-1.patch
  xsa452-2.patch
  xsa452-3.patch
  xsa452-4.patch
  xsa452-5.patch
  xsa452-6.patch
  xsa452-7.patch
  xsa453-1.patch
  xsa453-2.patch
  xsa453-3.patch
  xsa453-4.patch
  xsa453-5.patch
  xsa453-6.patch
  xsa453-7.patch
  xsa453-8.patch
  xsa454-1.patch
  xsa454-2.patch

- bsc#1221332 - VUL-0: CVE-2023-28746: xen: x86: Register File Data
  Sampling (XSA-452)
  xsa452-1.patch
  xsa452-2.patch
  xsa452-3.patch
  xsa452-4.patch
  xsa452-5.patch
  xsa452-6.patch
  xsa452-7.patch
- bsc#1221334 - VUL-0: CVE-2024-2193: xen: GhostRace: Speculative
  Race Conditions (XSA-453)
  xsa453-1.patch
  xsa453-2.patch
  xsa453-3.patch
  xsa453-4.patch
  xsa453-5.patch
  xsa453-6.patch
  xsa453-7.patch
  xsa453-8.patch

- bsc#1219885 - VUL-0: CVE-2023-46841: xen: x86: shadow stack vs
  exceptions from emulation stubs (XSA-451)
  xsa451.patch

Package yast2-network was updated:

- Guard secret attributes against leaking to the log (bsc#1221194)- 4.4.60

Package yast2-packager was updated:

- Reimplemented the hardcoded product mapping to support also the  migration from SLE_HPC to SLES SP6+ (with the HPC module)
  (bsc#1220567)
- 4.4.35

- Do not fail when the installation URL contains a space
  (bsc#1201816)
- 4.4.34

Package yast2-registration was updated:

- Set the new product mapping when upgrading SLE_HPC to SLES SP6+  (with the HPC module), use the old product mapping when upgrading
  from SLE_HPC-SP3 to SLE_HPC-SP4 (bsc#1220567)
- 4.4.24

Package yast2-users was updated:

- Add a missing require in the auto client (bsc#1219422).- 4.4.16

Package zypper was updated:

- Do not try to refresh repo metadata as non-root user  (bsc#1222086)
  Instead show refresh stats and hint how to update them.
- man: Explain how to protect orphaned packages by collecting
  them in a plaindir repo.
- packages: Add --autoinstalled and --userinstalled options to
  list them.
- Don't print 'reboot required' message if download-only or
  dry-run (fixes #529)
  Instead point out that a reboot would be required if the option
  was not used.
- Resepect zypper.conf option `showAlias` search commands
  (bsc#1221963)
  Repository::asUserString (or Repository::label) respects the
  zypper.conf option, while name/alias return the property.
- version 1.14.71

- dup: New option --remove-orphaned to remove all orphaned
  packages in dup (bsc#1221525)
- version 1.14.70

- info,summary: Support VendorSupportOption flag
  VendorSupportSuperseded (jsc#OBS-301, jsc#PED-8014)
- BuildRequires:  libzypp-devel &amp;gt;= 17.32.0.
  API cleanup and changes for VendorSupportSuperseded.
- Show active dry-run/download-only at the commit propmpt.
- patch: Add --skip-not-applicable-patches option (closes #514)
- Fix printing detailed solver problem description.
  The problem description() is one rule out possibly many in
  completeProblemInfo() the solver has chosen to represent the
  problem. So either description or completeProblemInfo should be
  printed, but not both.
- Fix bash-completion to work with right adjusted numbers in the
  1st column too (closes #505)
- Set libzypp shutdown request signal on Ctrl+C (fixes #522)
- lr REPO: In the detailed view show all baseurls not just the
  first one (bsc#1218171)
- version 1.14.69

</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/suse-manager-proxy-4-3-byos-v20240616-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/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <Branch Type="Product Name" Name="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
        <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
      </Branch>
    </Branch>
    <Branch Type="Product Version" Name="aaa_base-84.87+git20180409.04c9dae-150300.10.20.1">
      <FullProductName ProductID="aaa_base-84.87+git20180409.04c9dae-150300.10.20.1">aaa_base-84.87+git20180409.04c9dae-150300.10.20.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="aaa_base-extras-84.87+git20180409.04c9dae-150300.10.20.1">
      <FullProductName ProductID="aaa_base-extras-84.87+git20180409.04c9dae-150300.10.20.1">aaa_base-extras-84.87+git20180409.04c9dae-150300.10.20.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="apache2-2.4.51-150400.6.17.1">
      <FullProductName ProductID="apache2-2.4.51-150400.6.17.1">apache2-2.4.51-150400.6.17.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="apache2-prefork-2.4.51-150400.6.17.1">
      <FullProductName ProductID="apache2-prefork-2.4.51-150400.6.17.1">apache2-prefork-2.4.51-150400.6.17.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="apache2-utils-2.4.51-150400.6.17.1">
      <FullProductName ProductID="apache2-utils-2.4.51-150400.6.17.1">apache2-utils-2.4.51-150400.6.17.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="audit-3.0.6-150400.4.16.1">
      <FullProductName ProductID="audit-3.0.6-150400.4.16.1">audit-3.0.6-150400.4.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="autofs-5.1.3-150000.7.17.2">
      <FullProductName ProductID="autofs-5.1.3-150000.7.17.2">autofs-5.1.3-150000.7.17.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ca-certificates-2+git20240416.98ae794-150300.4.3.3">
      <FullProductName ProductID="ca-certificates-2+git20240416.98ae794-150300.4.3.3">ca-certificates-2+git20240416.98ae794-150300.4.3.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="catatonit-0.2.0-150300.10.8.1">
      <FullProductName ProductID="catatonit-0.2.0-150300.10.8.1">catatonit-0.2.0-150300.10.8.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="chrony-4.1-150400.21.5.7">
      <FullProductName ProductID="chrony-4.1-150400.21.5.7">chrony-4.1-150400.21.5.7</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="chrony-pool-suse-4.1-150400.21.5.7">
      <FullProductName ProductID="chrony-pool-suse-4.1-150400.21.5.7">chrony-pool-suse-4.1-150400.21.5.7</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cloud-netconfig-gce-1.14-150000.25.23.1">
      <FullProductName ProductID="cloud-netconfig-gce-1.14-150000.25.23.1">cloud-netconfig-gce-1.14-150000.25.23.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="containerd-1.7.10-150000.108.1">
      <FullProductName ProductID="containerd-1.7.10-150000.108.1">containerd-1.7.10-150000.108.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="coreutils-8.32-150400.9.6.1">
      <FullProductName ProductID="coreutils-8.32-150400.9.6.1">coreutils-8.32-150400.9.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cups-config-2.2.7-150000.3.59.1">
      <FullProductName ProductID="cups-config-2.2.7-150000.3.59.1">cups-config-2.2.7-150000.3.59.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="curl-8.0.1-150400.5.44.1">
      <FullProductName ProductID="curl-8.0.1-150400.5.44.1">curl-8.0.1-150400.5.44.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="docker-24.0.7_ce-150000.198.2">
      <FullProductName ProductID="docker-24.0.7_ce-150000.198.2">docker-24.0.7_ce-150000.198.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="dwz-0.12-150000.3.8.1">
      <FullProductName ProductID="dwz-0.12-150000.3.8.1">dwz-0.12-150000.3.8.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="e2fsprogs-1.46.4-150400.3.6.2">
      <FullProductName ProductID="e2fsprogs-1.46.4-150400.3.6.2">e2fsprogs-1.46.4-150400.3.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="fdupes-2.3.0-150400.3.3.1">
      <FullProductName ProductID="fdupes-2.3.0-150400.3.3.1">fdupes-2.3.0-150400.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glib2-tools-2.70.5-150400.3.11.1">
      <FullProductName ProductID="glib2-tools-2.70.5-150400.3.11.1">glib2-tools-2.70.5-150400.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-2.31-150300.83.1">
      <FullProductName ProductID="glibc-2.31-150300.83.1">glibc-2.31-150300.83.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-devel-2.31-150300.83.1">
      <FullProductName ProductID="glibc-devel-2.31-150300.83.1">glibc-devel-2.31-150300.83.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-i18ndata-2.31-150300.83.1">
      <FullProductName ProductID="glibc-i18ndata-2.31-150300.83.1">glibc-i18ndata-2.31-150300.83.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-locale-2.31-150300.83.1">
      <FullProductName ProductID="glibc-locale-2.31-150300.83.1">glibc-locale-2.31-150300.83.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-locale-base-2.31-150300.83.1">
      <FullProductName ProductID="glibc-locale-base-2.31-150300.83.1">glibc-locale-base-2.31-150300.83.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-guest-agent-20240314.00-150000.1.46.2">
      <FullProductName ProductID="google-guest-agent-20240314.00-150000.1.46.2">google-guest-agent-20240314.00-150000.1.46.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-guest-configs-20240307.00-150400.13.9.1">
      <FullProductName ProductID="google-guest-configs-20240307.00-150400.13.9.1">google-guest-configs-20240307.00-150400.13.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-guest-oslogin-20240311.00-150000.1.43.1">
      <FullProductName ProductID="google-guest-oslogin-20240311.00-150000.1.43.1">google-guest-oslogin-20240311.00-150000.1.43.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-osconfig-agent-20240320.00-150000.1.33.5">
      <FullProductName ProductID="google-osconfig-agent-20240320.00-150000.1.33.5">google-osconfig-agent-20240320.00-150000.1.33.5</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="growpart-rootgrow-1.0.7-150000.1.12.1">
      <FullProductName ProductID="growpart-rootgrow-1.0.7-150000.1.12.1">growpart-rootgrow-1.0.7-150000.1.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="hwdata-0.380-150000.3.68.1">
      <FullProductName ProductID="hwdata-0.380-150000.3.68.1">hwdata-0.380-150000.3.68.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ipset-7.15-150400.12.6.4">
      <FullProductName ProductID="ipset-7.15-150400.12.6.4">ipset-7.15-150400.12.6.4</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="iputils-20211215-150400.3.11.1">
      <FullProductName ProductID="iputils-20211215-150400.3.11.1">iputils-20211215-150400.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kernel-default-5.14.21-150400.24.119.1">
      <FullProductName ProductID="kernel-default-5.14.21-150400.24.119.1">kernel-default-5.14.21-150400.24.119.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="krb5-1.19.2-150400.3.9.1">
      <FullProductName ProductID="krb5-1.19.2-150400.3.9.1">krb5-1.19.2-150400.3.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="krb5-client-1.19.2-150400.3.9.1">
      <FullProductName ProductID="krb5-client-1.19.2-150400.3.9.1">krb5-client-1.19.2-150400.3.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="less-590-150400.3.9.1">
      <FullProductName ProductID="less-590-150400.3.9.1">less-590-150400.3.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libatomic1-13.2.1+git8285-150000.1.9.1">
      <FullProductName ProductID="libatomic1-13.2.1+git8285-150000.1.9.1">libatomic1-13.2.1+git8285-150000.1.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libaudit1-3.0.6-150400.4.16.1">
      <FullProductName ProductID="libaudit1-3.0.6-150400.4.16.1">libaudit1-3.0.6-150400.4.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libauparse0-3.0.6-150400.4.16.1">
      <FullProductName ProductID="libauparse0-3.0.6-150400.4.16.1">libauparse0-3.0.6-150400.4.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libavahi-client3-0.8-150400.7.16.1">
      <FullProductName ProductID="libavahi-client3-0.8-150400.7.16.1">libavahi-client3-0.8-150400.7.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libavahi-common3-0.8-150400.7.16.1">
      <FullProductName ProductID="libavahi-common3-0.8-150400.7.16.1">libavahi-common3-0.8-150400.7.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libblkid1-2.37.2-150400.8.29.1">
      <FullProductName ProductID="libblkid1-2.37.2-150400.8.29.1">libblkid1-2.37.2-150400.8.29.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libcares2-1.19.1-150000.3.26.1">
      <FullProductName ProductID="libcares2-1.19.1-150000.3.26.1">libcares2-1.19.1-150000.3.26.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libcom_err2-1.46.4-150400.3.6.2">
      <FullProductName ProductID="libcom_err2-1.46.4-150400.3.6.2">libcom_err2-1.46.4-150400.3.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libcups2-2.2.7-150000.3.59.1">
      <FullProductName ProductID="libcups2-2.2.7-150000.3.59.1">libcups2-2.2.7-150000.3.59.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libcurl4-8.0.1-150400.5.44.1">
      <FullProductName ProductID="libcurl4-8.0.1-150400.5.44.1">libcurl4-8.0.1-150400.5.44.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libexpat1-2.4.4-150400.3.17.1">
      <FullProductName ProductID="libexpat1-2.4.4-150400.3.17.1">libexpat1-2.4.4-150400.3.17.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libext2fs2-1.46.4-150400.3.6.2">
      <FullProductName ProductID="libext2fs2-1.46.4-150400.3.6.2">libext2fs2-1.46.4-150400.3.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libfdisk1-2.37.2-150400.8.29.1">
      <FullProductName ProductID="libfdisk1-2.37.2-150400.8.29.1">libfdisk1-2.37.2-150400.8.29.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgcc_s1-13.2.1+git8285-150000.1.9.1">
      <FullProductName ProductID="libgcc_s1-13.2.1+git8285-150000.1.9.1">libgcc_s1-13.2.1+git8285-150000.1.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgio-2_0-0-2.70.5-150400.3.11.1">
      <FullProductName ProductID="libgio-2_0-0-2.70.5-150400.3.11.1">libgio-2_0-0-2.70.5-150400.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libglib-2_0-0-2.70.5-150400.3.11.1">
      <FullProductName ProductID="libglib-2_0-0-2.70.5-150400.3.11.1">libglib-2_0-0-2.70.5-150400.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgmodule-2_0-0-2.70.5-150400.3.11.1">
      <FullProductName ProductID="libgmodule-2_0-0-2.70.5-150400.3.11.1">libgmodule-2_0-0-2.70.5-150400.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgnutls30-3.7.3-150400.4.44.1">
      <FullProductName ProductID="libgnutls30-3.7.3-150400.4.44.1">libgnutls30-3.7.3-150400.4.44.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgobject-2_0-0-2.70.5-150400.3.11.1">
      <FullProductName ProductID="libgobject-2_0-0-2.70.5-150400.3.11.1">libgobject-2_0-0-2.70.5-150400.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgomp1-13.2.1+git8285-150000.1.9.1">
      <FullProductName ProductID="libgomp1-13.2.1+git8285-150000.1.9.1">libgomp1-13.2.1+git8285-150000.1.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libipset13-7.15-150400.12.6.4">
      <FullProductName ProductID="libipset13-7.15-150400.12.6.4">libipset13-7.15-150400.12.6.4</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libitm1-13.2.1+git8285-150000.1.9.1">
      <FullProductName ProductID="libitm1-13.2.1+git8285-150000.1.9.1">libitm1-13.2.1+git8285-150000.1.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libjitterentropy3-3.4.1-150000.1.12.1">
      <FullProductName ProductID="libjitterentropy3-3.4.1-150000.1.12.1">libjitterentropy3-3.4.1-150000.1.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="liblsan0-13.2.1+git8285-150000.1.9.1">
      <FullProductName ProductID="liblsan0-13.2.1+git8285-150000.1.9.1">liblsan0-13.2.1+git8285-150000.1.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libltdl7-2.4.6-150000.3.6.2">
      <FullProductName ProductID="libltdl7-2.4.6-150000.3.6.2">libltdl7-2.4.6-150000.3.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libmount1-2.37.2-150400.8.29.1">
      <FullProductName ProductID="libmount1-2.37.2-150400.8.29.1">libmount1-2.37.2-150400.8.29.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libncurses6-6.1-150000.5.24.1">
      <FullProductName ProductID="libncurses6-6.1-150000.5.24.1">libncurses6-6.1-150000.5.24.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libnghttp2-14-1.40.0-150200.17.1">
      <FullProductName ProductID="libnghttp2-14-1.40.0-150200.17.1">libnghttp2-14-1.40.0-150200.17.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libopenssl1_1-1.1.1l-150400.7.66.2">
      <FullProductName ProductID="libopenssl1_1-1.1.1l-150400.7.66.2">libopenssl1_1-1.1.1l-150400.7.66.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpython3_6m1_0-3.6.15-150300.10.60.1">
      <FullProductName ProductID="libpython3_6m1_0-3.6.15-150300.10.60.1">libpython3_6m1_0-3.6.15-150300.10.60.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsemanage1-3.1-150400.3.4.2">
      <FullProductName ProductID="libsemanage1-3.1-150400.3.4.2">libsemanage1-3.1-150400.3.4.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsmartcols1-2.37.2-150400.8.29.1">
      <FullProductName ProductID="libsmartcols1-2.37.2-150400.8.29.1">libsmartcols1-2.37.2-150400.8.29.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libstdc++6-13.2.1+git8285-150000.1.9.1">
      <FullProductName ProductID="libstdc++6-13.2.1+git8285-150000.1.9.1">libstdc++6-13.2.1+git8285-150000.1.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsuseconnect-1.9.0-150400.3.31.2">
      <FullProductName ProductID="libsuseconnect-1.9.0-150400.3.31.2">libsuseconnect-1.9.0-150400.3.31.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libuuid1-2.37.2-150400.8.29.1">
      <FullProductName ProductID="libuuid1-2.37.2-150400.8.29.1">libuuid1-2.37.2-150400.8.29.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libyui-ncurses-pkg16-4.3.7-150400.3.7.1">
      <FullProductName ProductID="libyui-ncurses-pkg16-4.3.7-150400.3.7.1">libyui-ncurses-pkg16-4.3.7-150400.3.7.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libyui-ncurses16-4.3.7-150400.3.7.1">
      <FullProductName ProductID="libyui-ncurses16-4.3.7-150400.3.7.1">libyui-ncurses16-4.3.7-150400.3.7.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libyui16-4.3.7-150400.3.7.1">
      <FullProductName ProductID="libyui16-4.3.7-150400.3.7.1">libyui16-4.3.7-150400.3.7.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libzypp-17.32.5-150400.3.64.1">
      <FullProductName ProductID="libzypp-17.32.5-150400.3.64.1">libzypp-17.32.5-150400.3.64.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="login_defs-4.8.1-150400.10.15.1">
      <FullProductName ProductID="login_defs-4.8.1-150400.10.15.1">login_defs-4.8.1-150400.10.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ncurses-utils-6.1-150000.5.24.1">
      <FullProductName ProductID="ncurses-utils-6.1-150000.5.24.1">ncurses-utils-6.1-150000.5.24.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="nscd-2.31-150300.83.1">
      <FullProductName ProductID="nscd-2.31-150300.83.1">nscd-2.31-150300.83.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-8.4p1-150300.3.37.1">
      <FullProductName ProductID="openssh-8.4p1-150300.3.37.1">openssh-8.4p1-150300.3.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-clients-8.4p1-150300.3.37.1">
      <FullProductName ProductID="openssh-clients-8.4p1-150300.3.37.1">openssh-clients-8.4p1-150300.3.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-common-8.4p1-150300.3.37.1">
      <FullProductName ProductID="openssh-common-8.4p1-150300.3.37.1">openssh-common-8.4p1-150300.3.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-server-8.4p1-150300.3.37.1">
      <FullProductName ProductID="openssh-server-8.4p1-150300.3.37.1">openssh-server-8.4p1-150300.3.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssl-1_1-1.1.1l-150400.7.66.2">
      <FullProductName ProductID="openssl-1_1-1.1.1l-150400.7.66.2">openssl-1_1-1.1.1l-150400.7.66.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="pam-config-1.1-150200.3.6.1">
      <FullProductName ProductID="pam-config-1.1-150200.3.6.1">pam-config-1.1-150200.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="perl-5.26.1-150300.17.17.1">
      <FullProductName ProductID="perl-5.26.1-150300.17.17.1">perl-5.26.1-150300.17.17.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="perl-Bootloader-0.947-150400.3.12.1">
      <FullProductName ProductID="perl-Bootloader-0.947-150400.3.12.1">perl-Bootloader-0.947-150400.3.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="perl-base-5.26.1-150300.17.17.1">
      <FullProductName ProductID="perl-base-5.26.1-150300.17.17.1">perl-base-5.26.1-150300.17.17.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-3.6.15-150300.10.60.1">
      <FullProductName ProductID="python3-3.6.15-150300.10.60.1">python3-3.6.15-150300.10.60.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-Jinja2-2.10.1-150000.3.13.1">
      <FullProductName ProductID="python3-Jinja2-2.10.1-150000.3.13.1">python3-Jinja2-2.10.1-150000.3.13.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-base-3.6.15-150300.10.60.1">
      <FullProductName ProductID="python3-base-3.6.15-150300.10.60.1">python3-base-3.6.15-150300.10.60.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-curses-3.6.15-150300.10.60.1">
      <FullProductName ProductID="python3-curses-3.6.15-150300.10.60.1">python3-curses-3.6.15-150300.10.60.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-idna-2.6-150000.3.3.1">
      <FullProductName ProductID="python3-idna-2.6-150000.3.3.1">python3-idna-2.6-150000.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-requests-2.25.1-150300.3.9.1">
      <FullProductName ProductID="python3-requests-2.25.1-150300.3.9.1">python3-requests-2.25.1-150300.3.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-rpm-4.14.3-150400.59.16.1">
      <FullProductName ProductID="python3-rpm-4.14.3-150400.59.16.1">python3-rpm-4.14.3-150400.59.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-salt-3006.0-150400.8.60.1">
      <FullProductName ProductID="python3-salt-3006.0-150400.8.60.1">python3-salt-3006.0-150400.8.60.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-spacewalk-certs-tools-4.3.23-150400.3.28.5">
      <FullProductName ProductID="python3-spacewalk-certs-tools-4.3.23-150400.3.28.5">python3-spacewalk-certs-tools-4.3.23-150400.3.28.5</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-spacewalk-client-tools-4.3.19-150400.3.27.5">
      <FullProductName ProductID="python3-spacewalk-client-tools-4.3.19-150400.3.27.5">python3-spacewalk-client-tools-4.3.19-150400.3.27.5</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-uyuni-common-libs-4.3.10-150400.3.18.4">
      <FullProductName ProductID="python3-uyuni-common-libs-4.3.10-150400.3.18.4">python3-uyuni-common-libs-4.3.10-150400.3.18.4</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="release-notes-susemanager-proxy-4.3.12-150400.3.82.3">
      <FullProductName ProductID="release-notes-susemanager-proxy-4.3.12-150400.3.82.3">release-notes-susemanager-proxy-4.3.12-150400.3.82.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="rpm-build-4.14.3-150400.59.16.1">
      <FullProductName ProductID="rpm-build-4.14.3-150400.59.16.1">rpm-build-4.14.3-150400.59.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="rpm-ndb-4.14.3-150400.59.16.1">
      <FullProductName ProductID="rpm-ndb-4.14.3-150400.59.16.1">rpm-ndb-4.14.3-150400.59.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="runc-1.1.12-150000.64.1">
      <FullProductName ProductID="runc-1.1.12-150000.64.1">runc-1.1.12-150000.64.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="salt-3006.0-150400.8.60.1">
      <FullProductName ProductID="salt-3006.0-150400.8.60.1">salt-3006.0-150400.8.60.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="salt-minion-3006.0-150400.8.60.1">
      <FullProductName ProductID="salt-minion-3006.0-150400.8.60.1">salt-minion-3006.0-150400.8.60.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="sed-4.4-150300.13.3.1">
      <FullProductName ProductID="sed-4.4-150300.13.3.1">sed-4.4-150300.13.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="shadow-4.8.1-150400.10.15.1">
      <FullProductName ProductID="shadow-4.8.1-150400.10.15.1">shadow-4.8.1-150400.10.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="shim-15.8-150300.4.20.2">
      <FullProductName ProductID="shim-15.8-150300.4.20.2">shim-15.8-150300.4.20.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="spacewalk-backend-4.3.28-150400.3.41.7">
      <FullProductName ProductID="spacewalk-backend-4.3.28-150400.3.41.7">spacewalk-backend-4.3.28-150400.3.41.7</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="spacewalk-base-minimal-4.3.38-150400.3.42.6">
      <FullProductName ProductID="spacewalk-base-minimal-4.3.38-150400.3.42.6">spacewalk-base-minimal-4.3.38-150400.3.42.6</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="spacewalk-base-minimal-config-4.3.38-150400.3.42.6">
      <FullProductName ProductID="spacewalk-base-minimal-config-4.3.38-150400.3.42.6">spacewalk-base-minimal-config-4.3.38-150400.3.42.6</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="spacewalk-certs-tools-4.3.23-150400.3.28.5">
      <FullProductName ProductID="spacewalk-certs-tools-4.3.23-150400.3.28.5">spacewalk-certs-tools-4.3.23-150400.3.28.5</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="spacewalk-client-tools-4.3.19-150400.3.27.5">
      <FullProductName ProductID="spacewalk-client-tools-4.3.19-150400.3.27.5">spacewalk-client-tools-4.3.19-150400.3.27.5</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="squid-5.7-150400.3.29.2">
      <FullProductName ProductID="squid-5.7-150400.3.29.2">squid-5.7-150400.3.29.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="supportutils-3.1.30-150300.7.35.30.1">
      <FullProductName ProductID="supportutils-3.1.30-150300.7.35.30.1">supportutils-3.1.30-150300.7.35.30.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suseconnect-ng-1.9.0-150400.3.31.2">
      <FullProductName ProductID="suseconnect-ng-1.9.0-150400.3.31.2">suseconnect-ng-1.9.0-150400.3.31.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suseconnect-ruby-bindings-1.9.0-150400.3.31.2">
      <FullProductName ProductID="suseconnect-ruby-bindings-1.9.0-150400.3.31.2">suseconnect-ruby-bindings-1.9.0-150400.3.31.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="system-group-audit-3.0.6-150400.4.16.1">
      <FullProductName ProductID="system-group-audit-3.0.6-150400.4.16.1">system-group-audit-3.0.6-150400.4.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-default-settings-0.10-150300.3.7.1">
      <FullProductName ProductID="systemd-default-settings-0.10-150300.3.7.1">systemd-default-settings-0.10-150300.3.7.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-default-settings-branding-SLE-0.10-150300.3.7.1">
      <FullProductName ProductID="systemd-default-settings-branding-SLE-0.10-150300.3.7.1">systemd-default-settings-branding-SLE-0.10-150300.3.7.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-presets-branding-SLE-15.1-150100.20.14.1">
      <FullProductName ProductID="systemd-presets-branding-SLE-15.1-150100.20.14.1">systemd-presets-branding-SLE-15.1-150100.20.14.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-presets-common-SUSE-15-150100.8.23.1">
      <FullProductName ProductID="systemd-presets-common-SUSE-15-150100.8.23.1">systemd-presets-common-SUSE-15-150100.8.23.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-rpm-macros-15-150000.7.39.1">
      <FullProductName ProductID="systemd-rpm-macros-15-150000.7.39.1">systemd-rpm-macros-15-150000.7.39.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="terminfo-6.1-150000.5.24.1">
      <FullProductName ProductID="terminfo-6.1-150000.5.24.1">terminfo-6.1-150000.5.24.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="terminfo-base-6.1-150000.5.24.1">
      <FullProductName ProductID="terminfo-base-6.1-150000.5.24.1">terminfo-base-6.1-150000.5.24.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="util-linux-2.37.2-150400.8.29.1">
      <FullProductName ProductID="util-linux-2.37.2-150400.8.29.1">util-linux-2.37.2-150400.8.29.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="util-linux-systemd-2.37.2-150400.8.29.1">
      <FullProductName ProductID="util-linux-systemd-2.37.2-150400.8.29.1">util-linux-systemd-2.37.2-150400.8.29.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="vim-9.1.0330-150000.5.63.1">
      <FullProductName ProductID="vim-9.1.0330-150000.5.63.1">vim-9.1.0330-150000.5.63.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="vim-data-common-9.1.0330-150000.5.63.1">
      <FullProductName ProductID="vim-data-common-9.1.0330-150000.5.63.1">vim-data-common-9.1.0330-150000.5.63.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="wicked-0.6.75-150400.3.24.1">
      <FullProductName ProductID="wicked-0.6.75-150400.3.24.1">wicked-0.6.75-150400.3.24.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="wicked-service-0.6.75-150400.3.24.1">
      <FullProductName ProductID="wicked-service-0.6.75-150400.3.24.1">wicked-service-0.6.75-150400.3.24.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="xen-libs-4.16.6_02-150400.4.55.1">
      <FullProductName ProductID="xen-libs-4.16.6_02-150400.4.55.1">xen-libs-4.16.6_02-150400.4.55.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="xfsprogs-5.13.0-150400.3.7.1">
      <FullProductName ProductID="xfsprogs-5.13.0-150400.3.7.1">xfsprogs-5.13.0-150400.3.7.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-network-4.4.60-150400.3.30.1">
      <FullProductName ProductID="yast2-network-4.4.60-150400.3.30.1">yast2-network-4.4.60-150400.3.30.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-packager-4.4.35-150400.3.11.1">
      <FullProductName ProductID="yast2-packager-4.4.35-150400.3.11.1">yast2-packager-4.4.35-150400.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-pkg-bindings-4.4.7-150400.3.11.4">
      <FullProductName ProductID="yast2-pkg-bindings-4.4.7-150400.3.11.4">yast2-pkg-bindings-4.4.7-150400.3.11.4</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-registration-4.4.24-150400.3.9.2">
      <FullProductName ProductID="yast2-registration-4.4.24-150400.3.9.2">yast2-registration-4.4.24-150400.3.9.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-users-4.4.16-150400.3.18.2">
      <FullProductName ProductID="yast2-users-4.4.16-150400.3.18.2">yast2-users-4.4.16-150400.3.18.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="zypper-1.14.71-150400.3.45.2">
      <FullProductName ProductID="zypper-1.14.71-150400.3.45.2">zypper-1.14.71-150400.3.45.2</FullProductName>
    </Branch>
    <Relationship ProductReference="aaa_base-84.87+git20180409.04c9dae-150300.10.20.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:aaa_base-84.87+git20180409.04c9dae-150300.10.20.1">aaa_base-84.87+git20180409.04c9dae-150300.10.20.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="aaa_base-extras-84.87+git20180409.04c9dae-150300.10.20.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:aaa_base-extras-84.87+git20180409.04c9dae-150300.10.20.1">aaa_base-extras-84.87+git20180409.04c9dae-150300.10.20.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="apache2-2.4.51-150400.6.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:apache2-2.4.51-150400.6.17.1">apache2-2.4.51-150400.6.17.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="apache2-prefork-2.4.51-150400.6.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:apache2-prefork-2.4.51-150400.6.17.1">apache2-prefork-2.4.51-150400.6.17.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="apache2-utils-2.4.51-150400.6.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:apache2-utils-2.4.51-150400.6.17.1">apache2-utils-2.4.51-150400.6.17.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="audit-3.0.6-150400.4.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:audit-3.0.6-150400.4.16.1">audit-3.0.6-150400.4.16.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="autofs-5.1.3-150000.7.17.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:autofs-5.1.3-150000.7.17.2">autofs-5.1.3-150000.7.17.2 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ca-certificates-2+git20240416.98ae794-150300.4.3.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:ca-certificates-2+git20240416.98ae794-150300.4.3.3">ca-certificates-2+git20240416.98ae794-150300.4.3.3 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="catatonit-0.2.0-150300.10.8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:catatonit-0.2.0-150300.10.8.1">catatonit-0.2.0-150300.10.8.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="chrony-4.1-150400.21.5.7" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:chrony-4.1-150400.21.5.7">chrony-4.1-150400.21.5.7 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="chrony-pool-suse-4.1-150400.21.5.7" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:chrony-pool-suse-4.1-150400.21.5.7">chrony-pool-suse-4.1-150400.21.5.7 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cloud-netconfig-gce-1.14-150000.25.23.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:cloud-netconfig-gce-1.14-150000.25.23.1">cloud-netconfig-gce-1.14-150000.25.23.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="containerd-1.7.10-150000.108.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:containerd-1.7.10-150000.108.1">containerd-1.7.10-150000.108.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="coreutils-8.32-150400.9.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:coreutils-8.32-150400.9.6.1">coreutils-8.32-150400.9.6.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cups-config-2.2.7-150000.3.59.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:cups-config-2.2.7-150000.3.59.1">cups-config-2.2.7-150000.3.59.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="curl-8.0.1-150400.5.44.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:curl-8.0.1-150400.5.44.1">curl-8.0.1-150400.5.44.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="docker-24.0.7_ce-150000.198.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:docker-24.0.7_ce-150000.198.2">docker-24.0.7_ce-150000.198.2 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="dwz-0.12-150000.3.8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:dwz-0.12-150000.3.8.1">dwz-0.12-150000.3.8.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="e2fsprogs-1.46.4-150400.3.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:e2fsprogs-1.46.4-150400.3.6.2">e2fsprogs-1.46.4-150400.3.6.2 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="fdupes-2.3.0-150400.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:fdupes-2.3.0-150400.3.3.1">fdupes-2.3.0-150400.3.3.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glib2-tools-2.70.5-150400.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:glib2-tools-2.70.5-150400.3.11.1">glib2-tools-2.70.5-150400.3.11.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-2.31-150300.83.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:glibc-2.31-150300.83.1">glibc-2.31-150300.83.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-devel-2.31-150300.83.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:glibc-devel-2.31-150300.83.1">glibc-devel-2.31-150300.83.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-i18ndata-2.31-150300.83.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:glibc-i18ndata-2.31-150300.83.1">glibc-i18ndata-2.31-150300.83.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-locale-2.31-150300.83.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:glibc-locale-2.31-150300.83.1">glibc-locale-2.31-150300.83.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-locale-base-2.31-150300.83.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:glibc-locale-base-2.31-150300.83.1">glibc-locale-base-2.31-150300.83.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-guest-agent-20240314.00-150000.1.46.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:google-guest-agent-20240314.00-150000.1.46.2">google-guest-agent-20240314.00-150000.1.46.2 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-guest-configs-20240307.00-150400.13.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:google-guest-configs-20240307.00-150400.13.9.1">google-guest-configs-20240307.00-150400.13.9.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-guest-oslogin-20240311.00-150000.1.43.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:google-guest-oslogin-20240311.00-150000.1.43.1">google-guest-oslogin-20240311.00-150000.1.43.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-osconfig-agent-20240320.00-150000.1.33.5" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:google-osconfig-agent-20240320.00-150000.1.33.5">google-osconfig-agent-20240320.00-150000.1.33.5 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="growpart-rootgrow-1.0.7-150000.1.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:growpart-rootgrow-1.0.7-150000.1.12.1">growpart-rootgrow-1.0.7-150000.1.12.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="hwdata-0.380-150000.3.68.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:hwdata-0.380-150000.3.68.1">hwdata-0.380-150000.3.68.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ipset-7.15-150400.12.6.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:ipset-7.15-150400.12.6.4">ipset-7.15-150400.12.6.4 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="iputils-20211215-150400.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:iputils-20211215-150400.3.11.1">iputils-20211215-150400.3.11.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kernel-default-5.14.21-150400.24.119.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:kernel-default-5.14.21-150400.24.119.1">kernel-default-5.14.21-150400.24.119.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="krb5-1.19.2-150400.3.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:krb5-1.19.2-150400.3.9.1">krb5-1.19.2-150400.3.9.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="krb5-client-1.19.2-150400.3.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:krb5-client-1.19.2-150400.3.9.1">krb5-client-1.19.2-150400.3.9.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="less-590-150400.3.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:less-590-150400.3.9.1">less-590-150400.3.9.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libatomic1-13.2.1+git8285-150000.1.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libatomic1-13.2.1+git8285-150000.1.9.1">libatomic1-13.2.1+git8285-150000.1.9.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libaudit1-3.0.6-150400.4.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libaudit1-3.0.6-150400.4.16.1">libaudit1-3.0.6-150400.4.16.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libauparse0-3.0.6-150400.4.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libauparse0-3.0.6-150400.4.16.1">libauparse0-3.0.6-150400.4.16.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libavahi-client3-0.8-150400.7.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libavahi-client3-0.8-150400.7.16.1">libavahi-client3-0.8-150400.7.16.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libavahi-common3-0.8-150400.7.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libavahi-common3-0.8-150400.7.16.1">libavahi-common3-0.8-150400.7.16.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libblkid1-2.37.2-150400.8.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libblkid1-2.37.2-150400.8.29.1">libblkid1-2.37.2-150400.8.29.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libcares2-1.19.1-150000.3.26.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libcares2-1.19.1-150000.3.26.1">libcares2-1.19.1-150000.3.26.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libcom_err2-1.46.4-150400.3.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libcom_err2-1.46.4-150400.3.6.2">libcom_err2-1.46.4-150400.3.6.2 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libcups2-2.2.7-150000.3.59.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libcups2-2.2.7-150000.3.59.1">libcups2-2.2.7-150000.3.59.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libcurl4-8.0.1-150400.5.44.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libcurl4-8.0.1-150400.5.44.1">libcurl4-8.0.1-150400.5.44.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libexpat1-2.4.4-150400.3.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libexpat1-2.4.4-150400.3.17.1">libexpat1-2.4.4-150400.3.17.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libext2fs2-1.46.4-150400.3.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libext2fs2-1.46.4-150400.3.6.2">libext2fs2-1.46.4-150400.3.6.2 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libfdisk1-2.37.2-150400.8.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libfdisk1-2.37.2-150400.8.29.1">libfdisk1-2.37.2-150400.8.29.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgcc_s1-13.2.1+git8285-150000.1.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libgcc_s1-13.2.1+git8285-150000.1.9.1">libgcc_s1-13.2.1+git8285-150000.1.9.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgio-2_0-0-2.70.5-150400.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libgio-2_0-0-2.70.5-150400.3.11.1">libgio-2_0-0-2.70.5-150400.3.11.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libglib-2_0-0-2.70.5-150400.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libglib-2_0-0-2.70.5-150400.3.11.1">libglib-2_0-0-2.70.5-150400.3.11.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgmodule-2_0-0-2.70.5-150400.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libgmodule-2_0-0-2.70.5-150400.3.11.1">libgmodule-2_0-0-2.70.5-150400.3.11.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgnutls30-3.7.3-150400.4.44.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libgnutls30-3.7.3-150400.4.44.1">libgnutls30-3.7.3-150400.4.44.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgobject-2_0-0-2.70.5-150400.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libgobject-2_0-0-2.70.5-150400.3.11.1">libgobject-2_0-0-2.70.5-150400.3.11.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgomp1-13.2.1+git8285-150000.1.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libgomp1-13.2.1+git8285-150000.1.9.1">libgomp1-13.2.1+git8285-150000.1.9.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libipset13-7.15-150400.12.6.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libipset13-7.15-150400.12.6.4">libipset13-7.15-150400.12.6.4 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libitm1-13.2.1+git8285-150000.1.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libitm1-13.2.1+git8285-150000.1.9.1">libitm1-13.2.1+git8285-150000.1.9.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libjitterentropy3-3.4.1-150000.1.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libjitterentropy3-3.4.1-150000.1.12.1">libjitterentropy3-3.4.1-150000.1.12.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="liblsan0-13.2.1+git8285-150000.1.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:liblsan0-13.2.1+git8285-150000.1.9.1">liblsan0-13.2.1+git8285-150000.1.9.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libltdl7-2.4.6-150000.3.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libltdl7-2.4.6-150000.3.6.2">libltdl7-2.4.6-150000.3.6.2 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libmount1-2.37.2-150400.8.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libmount1-2.37.2-150400.8.29.1">libmount1-2.37.2-150400.8.29.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libncurses6-6.1-150000.5.24.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libncurses6-6.1-150000.5.24.1">libncurses6-6.1-150000.5.24.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libnghttp2-14-1.40.0-150200.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libnghttp2-14-1.40.0-150200.17.1">libnghttp2-14-1.40.0-150200.17.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libopenssl1_1-1.1.1l-150400.7.66.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libopenssl1_1-1.1.1l-150400.7.66.2">libopenssl1_1-1.1.1l-150400.7.66.2 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpython3_6m1_0-3.6.15-150300.10.60.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libpython3_6m1_0-3.6.15-150300.10.60.1">libpython3_6m1_0-3.6.15-150300.10.60.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsemanage1-3.1-150400.3.4.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libsemanage1-3.1-150400.3.4.2">libsemanage1-3.1-150400.3.4.2 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsmartcols1-2.37.2-150400.8.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libsmartcols1-2.37.2-150400.8.29.1">libsmartcols1-2.37.2-150400.8.29.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libstdc++6-13.2.1+git8285-150000.1.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libstdc++6-13.2.1+git8285-150000.1.9.1">libstdc++6-13.2.1+git8285-150000.1.9.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsuseconnect-1.9.0-150400.3.31.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libsuseconnect-1.9.0-150400.3.31.2">libsuseconnect-1.9.0-150400.3.31.2 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libuuid1-2.37.2-150400.8.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libuuid1-2.37.2-150400.8.29.1">libuuid1-2.37.2-150400.8.29.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libyui-ncurses-pkg16-4.3.7-150400.3.7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libyui-ncurses-pkg16-4.3.7-150400.3.7.1">libyui-ncurses-pkg16-4.3.7-150400.3.7.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libyui-ncurses16-4.3.7-150400.3.7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libyui-ncurses16-4.3.7-150400.3.7.1">libyui-ncurses16-4.3.7-150400.3.7.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libyui16-4.3.7-150400.3.7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libyui16-4.3.7-150400.3.7.1">libyui16-4.3.7-150400.3.7.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libzypp-17.32.5-150400.3.64.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:libzypp-17.32.5-150400.3.64.1">libzypp-17.32.5-150400.3.64.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="login_defs-4.8.1-150400.10.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:login_defs-4.8.1-150400.10.15.1">login_defs-4.8.1-150400.10.15.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ncurses-utils-6.1-150000.5.24.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:ncurses-utils-6.1-150000.5.24.1">ncurses-utils-6.1-150000.5.24.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="nscd-2.31-150300.83.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:nscd-2.31-150300.83.1">nscd-2.31-150300.83.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-8.4p1-150300.3.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:openssh-8.4p1-150300.3.37.1">openssh-8.4p1-150300.3.37.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-clients-8.4p1-150300.3.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:openssh-clients-8.4p1-150300.3.37.1">openssh-clients-8.4p1-150300.3.37.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-common-8.4p1-150300.3.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:openssh-common-8.4p1-150300.3.37.1">openssh-common-8.4p1-150300.3.37.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-server-8.4p1-150300.3.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:openssh-server-8.4p1-150300.3.37.1">openssh-server-8.4p1-150300.3.37.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssl-1_1-1.1.1l-150400.7.66.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:openssl-1_1-1.1.1l-150400.7.66.2">openssl-1_1-1.1.1l-150400.7.66.2 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="pam-config-1.1-150200.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:pam-config-1.1-150200.3.6.1">pam-config-1.1-150200.3.6.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="perl-5.26.1-150300.17.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:perl-5.26.1-150300.17.17.1">perl-5.26.1-150300.17.17.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="perl-Bootloader-0.947-150400.3.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:perl-Bootloader-0.947-150400.3.12.1">perl-Bootloader-0.947-150400.3.12.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="perl-base-5.26.1-150300.17.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:perl-base-5.26.1-150300.17.17.1">perl-base-5.26.1-150300.17.17.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-3.6.15-150300.10.60.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:python3-3.6.15-150300.10.60.1">python3-3.6.15-150300.10.60.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-Jinja2-2.10.1-150000.3.13.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:python3-Jinja2-2.10.1-150000.3.13.1">python3-Jinja2-2.10.1-150000.3.13.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-base-3.6.15-150300.10.60.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:python3-base-3.6.15-150300.10.60.1">python3-base-3.6.15-150300.10.60.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-curses-3.6.15-150300.10.60.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:python3-curses-3.6.15-150300.10.60.1">python3-curses-3.6.15-150300.10.60.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-idna-2.6-150000.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:python3-idna-2.6-150000.3.3.1">python3-idna-2.6-150000.3.3.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-requests-2.25.1-150300.3.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:python3-requests-2.25.1-150300.3.9.1">python3-requests-2.25.1-150300.3.9.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-rpm-4.14.3-150400.59.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:python3-rpm-4.14.3-150400.59.16.1">python3-rpm-4.14.3-150400.59.16.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-salt-3006.0-150400.8.60.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:python3-salt-3006.0-150400.8.60.1">python3-salt-3006.0-150400.8.60.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-spacewalk-certs-tools-4.3.23-150400.3.28.5" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:python3-spacewalk-certs-tools-4.3.23-150400.3.28.5">python3-spacewalk-certs-tools-4.3.23-150400.3.28.5 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-spacewalk-client-tools-4.3.19-150400.3.27.5" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:python3-spacewalk-client-tools-4.3.19-150400.3.27.5">python3-spacewalk-client-tools-4.3.19-150400.3.27.5 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-uyuni-common-libs-4.3.10-150400.3.18.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:python3-uyuni-common-libs-4.3.10-150400.3.18.4">python3-uyuni-common-libs-4.3.10-150400.3.18.4 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="release-notes-susemanager-proxy-4.3.12-150400.3.82.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:release-notes-susemanager-proxy-4.3.12-150400.3.82.3">release-notes-susemanager-proxy-4.3.12-150400.3.82.3 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="rpm-build-4.14.3-150400.59.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:rpm-build-4.14.3-150400.59.16.1">rpm-build-4.14.3-150400.59.16.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="rpm-ndb-4.14.3-150400.59.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:rpm-ndb-4.14.3-150400.59.16.1">rpm-ndb-4.14.3-150400.59.16.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="runc-1.1.12-150000.64.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:runc-1.1.12-150000.64.1">runc-1.1.12-150000.64.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="salt-3006.0-150400.8.60.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:salt-3006.0-150400.8.60.1">salt-3006.0-150400.8.60.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="salt-minion-3006.0-150400.8.60.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:salt-minion-3006.0-150400.8.60.1">salt-minion-3006.0-150400.8.60.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="sed-4.4-150300.13.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:sed-4.4-150300.13.3.1">sed-4.4-150300.13.3.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="shadow-4.8.1-150400.10.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:shadow-4.8.1-150400.10.15.1">shadow-4.8.1-150400.10.15.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="shim-15.8-150300.4.20.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:shim-15.8-150300.4.20.2">shim-15.8-150300.4.20.2 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="spacewalk-backend-4.3.28-150400.3.41.7" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:spacewalk-backend-4.3.28-150400.3.41.7">spacewalk-backend-4.3.28-150400.3.41.7 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="spacewalk-base-minimal-4.3.38-150400.3.42.6" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:spacewalk-base-minimal-4.3.38-150400.3.42.6">spacewalk-base-minimal-4.3.38-150400.3.42.6 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="spacewalk-base-minimal-config-4.3.38-150400.3.42.6" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:spacewalk-base-minimal-config-4.3.38-150400.3.42.6">spacewalk-base-minimal-config-4.3.38-150400.3.42.6 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="spacewalk-certs-tools-4.3.23-150400.3.28.5" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:spacewalk-certs-tools-4.3.23-150400.3.28.5">spacewalk-certs-tools-4.3.23-150400.3.28.5 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="spacewalk-client-tools-4.3.19-150400.3.27.5" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:spacewalk-client-tools-4.3.19-150400.3.27.5">spacewalk-client-tools-4.3.19-150400.3.27.5 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="squid-5.7-150400.3.29.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:squid-5.7-150400.3.29.2">squid-5.7-150400.3.29.2 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="supportutils-3.1.30-150300.7.35.30.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:supportutils-3.1.30-150300.7.35.30.1">supportutils-3.1.30-150300.7.35.30.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suseconnect-ng-1.9.0-150400.3.31.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:suseconnect-ng-1.9.0-150400.3.31.2">suseconnect-ng-1.9.0-150400.3.31.2 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suseconnect-ruby-bindings-1.9.0-150400.3.31.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:suseconnect-ruby-bindings-1.9.0-150400.3.31.2">suseconnect-ruby-bindings-1.9.0-150400.3.31.2 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="system-group-audit-3.0.6-150400.4.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:system-group-audit-3.0.6-150400.4.16.1">system-group-audit-3.0.6-150400.4.16.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-default-settings-0.10-150300.3.7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:systemd-default-settings-0.10-150300.3.7.1">systemd-default-settings-0.10-150300.3.7.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-default-settings-branding-SLE-0.10-150300.3.7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:systemd-default-settings-branding-SLE-0.10-150300.3.7.1">systemd-default-settings-branding-SLE-0.10-150300.3.7.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-presets-branding-SLE-15.1-150100.20.14.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:systemd-presets-branding-SLE-15.1-150100.20.14.1">systemd-presets-branding-SLE-15.1-150100.20.14.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-presets-common-SUSE-15-150100.8.23.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:systemd-presets-common-SUSE-15-150100.8.23.1">systemd-presets-common-SUSE-15-150100.8.23.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-rpm-macros-15-150000.7.39.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:systemd-rpm-macros-15-150000.7.39.1">systemd-rpm-macros-15-150000.7.39.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="terminfo-6.1-150000.5.24.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:terminfo-6.1-150000.5.24.1">terminfo-6.1-150000.5.24.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="terminfo-base-6.1-150000.5.24.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:terminfo-base-6.1-150000.5.24.1">terminfo-base-6.1-150000.5.24.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="util-linux-2.37.2-150400.8.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:util-linux-2.37.2-150400.8.29.1">util-linux-2.37.2-150400.8.29.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="util-linux-systemd-2.37.2-150400.8.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:util-linux-systemd-2.37.2-150400.8.29.1">util-linux-systemd-2.37.2-150400.8.29.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-9.1.0330-150000.5.63.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:vim-9.1.0330-150000.5.63.1">vim-9.1.0330-150000.5.63.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-data-common-9.1.0330-150000.5.63.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:vim-data-common-9.1.0330-150000.5.63.1">vim-data-common-9.1.0330-150000.5.63.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="wicked-0.6.75-150400.3.24.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:wicked-0.6.75-150400.3.24.1">wicked-0.6.75-150400.3.24.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="wicked-service-0.6.75-150400.3.24.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:wicked-service-0.6.75-150400.3.24.1">wicked-service-0.6.75-150400.3.24.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="xen-libs-4.16.6_02-150400.4.55.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:xen-libs-4.16.6_02-150400.4.55.1">xen-libs-4.16.6_02-150400.4.55.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="xfsprogs-5.13.0-150400.3.7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:xfsprogs-5.13.0-150400.3.7.1">xfsprogs-5.13.0-150400.3.7.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-network-4.4.60-150400.3.30.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:yast2-network-4.4.60-150400.3.30.1">yast2-network-4.4.60-150400.3.30.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-packager-4.4.35-150400.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:yast2-packager-4.4.35-150400.3.11.1">yast2-packager-4.4.35-150400.3.11.1 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-pkg-bindings-4.4.7-150400.3.11.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:yast2-pkg-bindings-4.4.7-150400.3.11.4">yast2-pkg-bindings-4.4.7-150400.3.11.4 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-registration-4.4.24-150400.3.9.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:yast2-registration-4.4.24-150400.3.9.2">yast2-registration-4.4.24-150400.3.9.2 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-users-4.4.16-150400.3.18.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:yast2-users-4.4.16-150400.3.18.2">yast2-users-4.4.16-150400.3.18.2 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="zypper-1.14.71-150400.3.45.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64">
      <FullProductName ProductID="Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64:zypper-1.14.71-150400.3.45.2">zypper-1.14.71-150400.3.45.2 as a component of Public Cloud Image google/suse-manager-proxy-4-3-byos-v20240616-x86-64</FullProductName>
    </Relationship>
  </ProductTree>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An issue was discovered in Perl 5.22 through 5.26. Matching a crafted locale dependent regular expression can cause a heap-based buffer over-read and potentially information disclosure.</Note>
    </Notes>
    <CVE>CVE-2018-6798</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: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">Heap-based buffer overflow in the pack function in Perl before 5.26.2 allows context-dependent attackers to execute arbitrary code via a large item count.</Note>
    </Notes>
    <CVE>CVE-2018-6913</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>7.5</BaseScore>
        <Vector>AV:N/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">In the Linux kernel, the following vulnerability has been resolved:

net/smc: fix kernel panic caused by race of smc_sock

A crash occurs when smc_cdc_tx_handler() tries to access smc_sock
but smc_release() has already freed it.

[ 4570.695099] BUG: unable to handle page fault for address: 000000002eae9e88
[ 4570.696048] #PF: supervisor write access in kernel mode
[ 4570.696728] #PF: error_code(0x0002) - not-present page
[ 4570.697401] PGD 0 P4D 0
[ 4570.697716] Oops: 0002 [#1] PREEMPT SMP NOPTI
[ 4570.698228] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.16.0-rc4+ #111
[ 4570.699013] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 8c24b4c 04/0
[ 4570.699933] RIP: 0010:_raw_spin_lock+0x1a/0x30
&lt;...&gt;
[ 4570.711446] Call Trace:
[ 4570.711746]  &lt;IRQ&gt;
[ 4570.711992]  smc_cdc_tx_handler+0x41/0xc0
[ 4570.712470]  smc_wr_tx_tasklet_fn+0x213/0x560
[ 4570.712981]  ? smc_cdc_tx_dismisser+0x10/0x10
[ 4570.713489]  tasklet_action_common.isra.17+0x66/0x140
[ 4570.714083]  __do_softirq+0x123/0x2f4
[ 4570.714521]  irq_exit_rcu+0xc4/0xf0
[ 4570.714934]  common_interrupt+0xba/0xe0

Though smc_cdc_tx_handler() checked the existence of smc connection,
smc_release() may have already dismissed and released the smc socket
before smc_cdc_tx_handler() further visits it.

smc_cdc_tx_handler()           |smc_release()
if (!conn)                     |
                               |
                               |smc_cdc_tx_dismiss_slots()
                               |      smc_cdc_tx_dismisser()
                               |
                               |sock_put(&amp;smc-&gt;sk) &lt;- last sock_put,
                               |                      smc_sock freed
bh_lock_sock(&amp;smc-&gt;sk) (panic) |

To make sure we won't receive any CDC messages after we free the
smc_sock, add a refcount on the smc_connection for inflight CDC
message(posted to the QP but haven't received related CQE), and
don't release the smc_connection until all the inflight CDC messages
haven been done, for both success or failed ones.

Using refcount on CDC messages brings another problem: when the link
is going to be destroyed, smcr_link_clear() will reset the QP, which
then remove all the pending CQEs related to the QP in the CQ. To make
sure all the CQEs will always come back so the refcount on the
smc_connection can always reach 0, smc_ib_modify_qp_reset() was replaced
by smc_ib_modify_qp_error().
And remove the timeout in smc_wr_tx_wait_no_pending_sends() since we
need to wait for all pending WQEs done, or we may encounter use-after-
free when handling CQEs.

For IB device removal routine, we need to wait for all the QPs on that
device been destroyed before we can destroy CQs on the device, or
the refcount on smc_connection won't reach 0 and smc_sock cannot be
released.</Note>
    </Notes>
    <CVE>CVE-2021-46925</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: hda: intel-sdw-acpi: harden detection of controller

The existing code currently sets a pointer to an ACPI handle before
checking that it's actually a SoundWire controller. This can lead to
issues where the graph walk continues and eventually fails, but the
pointer was set already.

This patch changes the logic so that the information provided to
the caller is set when a controller is found.</Note>
    </Notes>
    <CVE>CVE-2021-46926</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nitro_enclaves: Use get_user_pages_unlocked() call to handle mmap assert

After commit 5b78ed24e8ec ("mm/pagemap: add mmap_assert_locked()
annotations to find_vma*()"), the call to get_user_pages() will trigger
the mmap assert.

static inline void mmap_assert_locked(struct mm_struct *mm)
{
	lockdep_assert_held(&amp;mm-&gt;mmap_lock);
	VM_BUG_ON_MM(!rwsem_is_locked(&amp;mm-&gt;mmap_lock), mm);
}

[   62.521410] kernel BUG at include/linux/mmap_lock.h:156!
...........................................................
[   62.538938] RIP: 0010:find_vma+0x32/0x80
...........................................................
[   62.605889] Call Trace:
[   62.608502]  &lt;TASK&gt;
[   62.610956]  ? lock_timer_base+0x61/0x80
[   62.614106]  find_extend_vma+0x19/0x80
[   62.617195]  __get_user_pages+0x9b/0x6a0
[   62.620356]  __gup_longterm_locked+0x42d/0x450
[   62.623721]  ? finish_wait+0x41/0x80
[   62.626748]  ? __kmalloc+0x178/0x2f0
[   62.629768]  ne_set_user_memory_region_ioctl.isra.0+0x225/0x6a0 [nitro_enclaves]
[   62.635776]  ne_enclave_ioctl+0x1cf/0x6d7 [nitro_enclaves]
[   62.639541]  __x64_sys_ioctl+0x82/0xb0
[   62.642620]  do_syscall_64+0x3b/0x90
[   62.645642]  entry_SYSCALL_64_after_hwframe+0x44/0xae

Use get_user_pages_unlocked() when setting the enclave memory regions.
That's a similar pattern as mmap_read_lock() used together with
get_user_pages().</Note>
    </Notes>
    <CVE>CVE-2021-46927</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mtu3: fix list_head check warning

This is caused by uninitialization of list_head.

BUG: KASAN: use-after-free in __list_del_entry_valid+0x34/0xe4

Call trace:
dump_backtrace+0x0/0x298
show_stack+0x24/0x34
dump_stack+0x130/0x1a8
print_address_description+0x88/0x56c
__kasan_report+0x1b8/0x2a0
kasan_report+0x14/0x20
__asan_load8+0x9c/0xa0
__list_del_entry_valid+0x34/0xe4
mtu3_req_complete+0x4c/0x300 [mtu3]
mtu3_gadget_stop+0x168/0x448 [mtu3]
usb_gadget_unregister_driver+0x204/0x3a0
unregister_gadget_item+0x44/0xa4</Note>
    </Notes>
    <CVE>CVE-2021-46930</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: f_fs: Clear ffs_eventfd in ffs_data_clear.

ffs_data_clear is indirectly called from both ffs_fs_kill_sb and
ffs_ep0_release, so it ends up being called twice when userland closes ep0
and then unmounts f_fs.
If userland provided an eventfd along with function's USB descriptors, it
ends up calling eventfd_ctx_put as many times, causing a refcount
underflow.
NULL-ify ffs_eventfd to prevent these extraneous eventfd_ctx_put calls.

Also, set epfiles to NULL right after de-allocating it, for readability.

For completeness, ffs_data_clear actually ends up being called thrice, the
last call being before the whole ffs structure gets freed, so when this
specific sequence happens there is a second underflow happening (but not
being reported):

/sys/kernel/debug/tracing# modprobe usb_f_fs
/sys/kernel/debug/tracing# echo ffs_data_clear &gt; set_ftrace_filter
/sys/kernel/debug/tracing# echo function &gt; current_tracer
/sys/kernel/debug/tracing# echo 1 &gt; tracing_on
(setup gadget, run and kill function userland process, teardown gadget)
/sys/kernel/debug/tracing# echo 0 &gt; tracing_on
/sys/kernel/debug/tracing# cat trace
 smartcard-openp-436     [000] .....  1946.208786: ffs_data_clear &lt;-ffs_data_closed
 smartcard-openp-431     [000] .....  1946.279147: ffs_data_clear &lt;-ffs_data_closed
 smartcard-openp-431     [000] .n...  1946.905512: ffs_data_clear &lt;-ffs_data_put

Warning output corresponding to above trace:
[ 1946.284139] WARNING: CPU: 0 PID: 431 at lib/refcount.c:28 refcount_warn_saturate+0x110/0x15c
[ 1946.293094] refcount_t: underflow; use-after-free.
[ 1946.298164] Modules linked in: usb_f_ncm(E) u_ether(E) usb_f_fs(E) hci_uart(E) btqca(E) btrtl(E) btbcm(E) btintel(E) bluetooth(E) nls_ascii(E) nls_cp437(E) vfat(E) fat(E) bcm2835_v4l2(CE) bcm2835_mmal_vchiq(CE) videobuf2_vmalloc(E) videobuf2_memops(E) sha512_generic(E) videobuf2_v4l2(E) sha512_arm(E) videobuf2_common(E) videodev(E) cpufreq_dt(E) snd_bcm2835(CE) brcmfmac(E) mc(E) vc4(E) ctr(E) brcmutil(E) snd_soc_core(E) snd_pcm_dmaengine(E) drbg(E) snd_pcm(E) snd_timer(E) snd(E) soundcore(E) drm_kms_helper(E) cec(E) ansi_cprng(E) rc_core(E) syscopyarea(E) raspberrypi_cpufreq(E) sysfillrect(E) sysimgblt(E) cfg80211(E) max17040_battery(OE) raspberrypi_hwmon(E) fb_sys_fops(E) regmap_i2c(E) ecdh_generic(E) rfkill(E) ecc(E) bcm2835_rng(E) rng_core(E) vchiq(CE) leds_gpio(E) libcomposite(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sdhci_iproc(E) sdhci_pltfm(E) sdhci(E)
[ 1946.399633] CPU: 0 PID: 431 Comm: smartcard-openp Tainted: G         C OE     5.15.0-1-rpi #1  Debian 5.15.3-1
[ 1946.417950] Hardware name: BCM2835
[ 1946.425442] Backtrace:
[ 1946.432048] [&lt;c08d60a0&gt;] (dump_backtrace) from [&lt;c08d62ec&gt;] (show_stack+0x20/0x24)
[ 1946.448226]  r7:00000009 r6:0000001c r5:c04a948c r4:c0a64e2c
[ 1946.458412] [&lt;c08d62cc&gt;] (show_stack) from [&lt;c08d9ae0&gt;] (dump_stack+0x28/0x30)
[ 1946.470380] [&lt;c08d9ab8&gt;] (dump_stack) from [&lt;c0123500&gt;] (__warn+0xe8/0x154)
[ 1946.482067]  r5:c04a948c r4:c0a71dc8
[ 1946.490184] [&lt;c0123418&gt;] (__warn) from [&lt;c08d6948&gt;] (warn_slowpath_fmt+0xa0/0xe4)
[ 1946.506758]  r7:00000009 r6:0000001c r5:c0a71dc8 r4:c0a71e04
[ 1946.517070] [&lt;c08d68ac&gt;] (warn_slowpath_fmt) from [&lt;c04a948c&gt;] (refcount_warn_saturate+0x110/0x15c)
[ 1946.535309]  r8:c0100224 r7:c0dfcb84 r6:ffffffff r5:c3b84c00 r4:c24a17c0
[ 1946.546708] [&lt;c04a937c&gt;] (refcount_warn_saturate) from [&lt;c0380134&gt;] (eventfd_ctx_put+0x48/0x74)
[ 1946.564476] [&lt;c03800ec&gt;] (eventfd_ctx_put) from [&lt;bf5464e8&gt;] (ffs_data_clear+0xd0/0x118 [usb_f_fs])
[ 1946.582664]  r5:c3b84c00 r4:c2695b00
[ 1946.590668] [&lt;bf546418&gt;] (ffs_data_clear [usb_f_fs]) from [&lt;bf547cc0&gt;] (ffs_data_closed+0x9c/0x150 [usb_f_fs])
[ 1946.609608]  r5:bf54d014 r4:c2695b00
[ 1946.617522] [&lt;bf547c24&gt;] (ffs_data_closed [usb_f_fs]) from [&lt;bf547da0&gt;] (ffs_fs_kill_sb+0x2c/0x30 [usb_f_fs])
[ 1946.636217]  r7:c0dfcb
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-46933</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: fix use-after-free in tw_timer_handler

A real world panic issue was found as follow in Linux 5.4.

    BUG: unable to handle page fault for address: ffffde49a863de28
    PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0
    RIP: 0010:tw_timer_handler+0x20/0x40
    Call Trace:
     &lt;IRQ&gt;
     call_timer_fn+0x2b/0x120
     run_timer_softirq+0x1ef/0x450
     __do_softirq+0x10d/0x2b8
     irq_exit+0xc7/0xd0
     smp_apic_timer_interrupt+0x68/0x120
     apic_timer_interrupt+0xf/0x20

This issue was also reported since 2017 in the thread [1],
unfortunately, the issue was still can be reproduced after fixing
DCCP.

The ipv4_mib_exit_net is called before tcp_sk_exit_batch when a net
namespace is destroyed since tcp_sk_ops is registered befrore
ipv4_mib_ops, which means tcp_sk_ops is in the front of ipv4_mib_ops
in the list of pernet_list. There will be a use-after-free on
net-&gt;mib.net_statistics in tw_timer_handler after ipv4_mib_exit_net
if there are some inflight time-wait timers.

This bug is not introduced by commit f2bf415cfed7 ("mib: add net to
NET_ADD_STATS_BH") since the net_statistics is a global variable
instead of dynamic allocation and freeing. Actually, commit
61a7e26028b9 ("mib: put net statistics on struct net") introduces
the bug since it put net statistics on struct net and free it when
net namespace is destroyed.

Moving init_ipv4_mibs() to the front of tcp_init() to fix this bug
and replace pr_crit() with panic() since continuing is meaningless
when init_ipv4_mibs() fails.

[1] https://groups.google.com/g/syzkaller/c/p1tn-_Kc6l4/m/smuL_FMAAgAJ?pli=1</Note>
    </Notes>
    <CVE>CVE-2021-46936</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

spi: spi-zynqmp-gqspi: return -ENOMEM if dma_map_single fails

The spi controller supports 44-bit address space on AXI in DMA mode,
so set dma_addr_t width to 44-bit to avoid using a swiotlb mapping.
In addition, if dma_map_single fails, it should return immediately
instead of continuing doing the DMA operation which bases on invalid
address.

This fixes the following crash which occurs in reading a big block
from flash:

[  123.633577] zynqmp-qspi ff0f0000.spi: swiotlb buffer is full (sz: 4194304 bytes), total 32768 (slots), used 0 (slots)
[  123.644230] zynqmp-qspi ff0f0000.spi: ERR:rxdma:memory not mapped
[  123.784625] Unable to handle kernel paging request at virtual address 00000000003fffc0
[  123.792536] Mem abort info:
[  123.795313]   ESR = 0x96000145
[  123.798351]   EC = 0x25: DABT (current EL), IL = 32 bits
[  123.803655]   SET = 0, FnV = 0
[  123.806693]   EA = 0, S1PTW = 0
[  123.809818] Data abort info:
[  123.812683]   ISV = 0, ISS = 0x00000145
[  123.816503]   CM = 1, WnR = 1
[  123.819455] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000805047000
[  123.825887] [00000000003fffc0] pgd=0000000803b45003, p4d=0000000803b45003, pud=0000000000000000
[  123.834586] Internal error: Oops: 96000145 [#1] PREEMPT SMP</Note>
    </Notes>
    <CVE>CVE-2021-47047</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tee: optee: Fix incorrect page free bug

Pointer to the allocated pages (struct page *page) has already
progressed towards the end of allocation. It is incorrect to perform
__free_pages(page, order) using this pointer as we would free any
arbitrary pages. Fix this by stop modifying the page pointer.</Note>
    </Notes>
    <CVE>CVE-2021-47087</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mac80211: fix locking in ieee80211_start_ap error path

We need to hold the local-&gt;mtx to release the channel context,
as even encoded by the lockdep_assert_held() there. Fix it.</Note>
    </Notes>
    <CVE>CVE-2021-47091</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

platform/x86: intel_pmc_core: fix memleak on registration failure

In case device registration fails during module initialisation, the
platform device structure needs to be freed using platform_device_put()
to properly free all resources (e.g. the device name).</Note>
    </Notes>
    <CVE>CVE-2021-47093</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

KVM: x86/mmu: Don't advance iterator after restart due to yielding

After dropping mmu_lock in the TDP MMU, restart the iterator during
tdp_iter_next() and do not advance the iterator.  Advancing the iterator
results in skipping the top-level SPTE and all its children, which is
fatal if any of the skipped SPTEs were not visited before yielding.

When zapping all SPTEs, i.e. when min_level == root_level, restarting the
iter and then invoking tdp_iter_next() is always fatal if the current gfn
has as a valid SPTE, as advancing the iterator results in try_step_side()
skipping the current gfn, which wasn't visited before yielding.

Sprinkle WARNs on iter-&gt;yielded being true in various helpers that are
often used in conjunction with yielding, and tag the helper with
__must_check to reduce the probabily of improper usage.

Failing to zap a top-level SPTE manifests in one of two ways.  If a valid
SPTE is skipped by both kvm_tdp_mmu_zap_all() and kvm_tdp_mmu_put_root(),
the shadow page will be leaked and KVM will WARN accordingly.

  WARNING: CPU: 1 PID: 3509 at arch/x86/kvm/mmu/tdp_mmu.c:46 [kvm]
  RIP: 0010:kvm_mmu_uninit_tdp_mmu+0x3e/0x50 [kvm]
  Call Trace:
   &lt;TASK&gt;
   kvm_arch_destroy_vm+0x130/0x1b0 [kvm]
   kvm_destroy_vm+0x162/0x2a0 [kvm]
   kvm_vcpu_release+0x34/0x60 [kvm]
   __fput+0x82/0x240
   task_work_run+0x5c/0x90
   do_exit+0x364/0xa10
   ? futex_unqueue+0x38/0x60
   do_group_exit+0x33/0xa0
   get_signal+0x155/0x850
   arch_do_signal_or_restart+0xed/0x750
   exit_to_user_mode_prepare+0xc5/0x120
   syscall_exit_to_user_mode+0x1d/0x40
   do_syscall_64+0x48/0xc0
   entry_SYSCALL_64_after_hwframe+0x44/0xae

If kvm_tdp_mmu_zap_all() skips a gfn/SPTE but that SPTE is then zapped by
kvm_tdp_mmu_put_root(), KVM triggers a use-after-free in the form of
marking a struct page as dirty/accessed after it has been put back on the
free list.  This directly triggers a WARN due to encountering a page with
page_count() == 0, but it can also lead to data corruption and additional
errors in the kernel.

  WARNING: CPU: 7 PID: 1995658 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:171
  RIP: 0010:kvm_is_zone_device_pfn.part.0+0x9e/0xd0 [kvm]
  Call Trace:
   &lt;TASK&gt;
   kvm_set_pfn_dirty+0x120/0x1d0 [kvm]
   __handle_changed_spte+0x92e/0xca0 [kvm]
   __handle_changed_spte+0x63c/0xca0 [kvm]
   __handle_changed_spte+0x63c/0xca0 [kvm]
   __handle_changed_spte+0x63c/0xca0 [kvm]
   zap_gfn_range+0x549/0x620 [kvm]
   kvm_tdp_mmu_put_root+0x1b6/0x270 [kvm]
   mmu_free_root_page+0x219/0x2c0 [kvm]
   kvm_mmu_free_roots+0x1b4/0x4e0 [kvm]
   kvm_mmu_unload+0x1c/0xa0 [kvm]
   kvm_arch_destroy_vm+0x1f2/0x5c0 [kvm]
   kvm_put_kvm+0x3b1/0x8b0 [kvm]
   kvm_vcpu_release+0x4e/0x70 [kvm]
   __fput+0x1f7/0x8c0
   task_work_run+0xf8/0x1a0
   do_exit+0x97b/0x2230
   do_group_exit+0xda/0x2a0
   get_signal+0x3be/0x1e50
   arch_do_signal_or_restart+0x244/0x17f0
   exit_to_user_mode_prepare+0xcb/0x120
   syscall_exit_to_user_mode+0x1d/0x40
   do_syscall_64+0x4d/0x90
   entry_SYSCALL_64_after_hwframe+0x44/0xae

Note, the underlying bug existed even before commit 1af4a96025b3 ("KVM:
x86/mmu: Yield in TDU MMU iter even if no SPTES changed") moved calls to
tdp_mmu_iter_cond_resched() to the beginning of loops, as KVM could still
incorrectly advance past a top-level entry when yielding on a lower-level
entry.  But with respect to leaking shadow pages, the bug was introduced
by yielding before processing the current gfn.

Alternatively, tdp_mmu_iter_cond_resched() could simply fall through, or
callers could jump to their "retry" label.  The downside of that approach
is that tdp_mmu_iter_cond_resched() _must_ be called before anything else
in the loop, and there's no easy way to enfornce that requirement.

Ideally, KVM would handling the cond_resched() fully within the iterator
macro (the code is actually quite clean) and avoid this entire class of
bugs, but that is extremely difficult do wh
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47094</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:

ipmi: ssif: initialize ssif_info-&gt;client early

During probe ssif_info-&gt;client is dereferenced in error path. However,
it is set when some of the error checking has already been done. This
causes following kernel crash if an error path is taken:

[   30.645593][  T674] ipmi_ssif 0-000e: ipmi_ssif: Not probing, Interface already present
[   30.657616][  T674] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000088
...
[   30.657723][  T674] pc : __dev_printk+0x28/0xa0
[   30.657732][  T674] lr : _dev_err+0x7c/0xa0
...
[   30.657772][  T674] Call trace:
[   30.657775][  T674]  __dev_printk+0x28/0xa0
[   30.657778][  T674]  _dev_err+0x7c/0xa0
[   30.657781][  T674]  ssif_probe+0x548/0x900 [ipmi_ssif 62ce4b08badc1458fd896206d9ef69a3c31f3d3e]
[   30.657791][  T674]  i2c_device_probe+0x37c/0x3c0
...

Initialize ssif_info-&gt;client before any error path can be taken. Clear
i2c_client data in the error path to prevent the dangling pointer from
leaking.</Note>
    </Notes>
    <CVE>CVE-2021-47095</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: rawmidi - fix the uninitalized user_pversion

The user_pversion was uninitialized for the user space file structure
in the open function, because the file private structure use
kmalloc for the allocation.

The kernel ALSA sequencer code clears the file structure, so no additional
fixes are required.

BugLink: https://github.com/alsa-project/alsa-lib/issues/178</Note>
    </Notes>
    <CVE>CVE-2021-47096</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Input: elantech - fix stack out of bound access in elantech_change_report_id()

The array param[] in elantech_change_report_id() must be at least 3
bytes, because elantech_read_reg_params() is calling ps2_command() with
PSMOUSE_CMD_GETINFO, that is going to access 3 bytes from param[], but
it's defined in the stack as an array of 2 bytes, therefore we have a
potential stack out-of-bounds access here, also confirmed by KASAN:

[    6.512374] BUG: KASAN: stack-out-of-bounds in __ps2_command+0x372/0x7e0
[    6.512397] Read of size 1 at addr ffff8881024d77c2 by task kworker/2:1/118

[    6.512416] CPU: 2 PID: 118 Comm: kworker/2:1 Not tainted 5.13.0-22-generic #22+arighi20211110
[    6.512428] Hardware name: LENOVO 20T8000QGE/20T8000QGE, BIOS R1AET32W (1.08 ) 08/14/2020
[    6.512436] Workqueue: events_long serio_handle_event
[    6.512453] Call Trace:
[    6.512462]  show_stack+0x52/0x58
[    6.512474]  dump_stack+0xa1/0xd3
[    6.512487]  print_address_description.constprop.0+0x1d/0x140
[    6.512502]  ? __ps2_command+0x372/0x7e0
[    6.512516]  __kasan_report.cold+0x7d/0x112
[    6.512527]  ? _raw_write_lock_irq+0x20/0xd0
[    6.512539]  ? __ps2_command+0x372/0x7e0
[    6.512552]  kasan_report+0x3c/0x50
[    6.512564]  __asan_load1+0x6a/0x70
[    6.512575]  __ps2_command+0x372/0x7e0
[    6.512589]  ? ps2_drain+0x240/0x240
[    6.512601]  ? dev_printk_emit+0xa2/0xd3
[    6.512612]  ? dev_vprintk_emit+0xc5/0xc5
[    6.512621]  ? __kasan_check_write+0x14/0x20
[    6.512634]  ? mutex_lock+0x8f/0xe0
[    6.512643]  ? __mutex_lock_slowpath+0x20/0x20
[    6.512655]  ps2_command+0x52/0x90
[    6.512670]  elantech_ps2_command+0x4f/0xc0 [psmouse]
[    6.512734]  elantech_change_report_id+0x1e6/0x256 [psmouse]
[    6.512799]  ? elantech_report_trackpoint.constprop.0.cold+0xd/0xd [psmouse]
[    6.512863]  ? ps2_command+0x7f/0x90
[    6.512877]  elantech_query_info.cold+0x6bd/0x9ed [psmouse]
[    6.512943]  ? elantech_setup_ps2+0x460/0x460 [psmouse]
[    6.513005]  ? psmouse_reset+0x69/0xb0 [psmouse]
[    6.513064]  ? psmouse_attr_set_helper+0x2a0/0x2a0 [psmouse]
[    6.513122]  ? phys_pmd_init+0x30e/0x521
[    6.513137]  elantech_init+0x8a/0x200 [psmouse]
[    6.513200]  ? elantech_init_ps2+0xf0/0xf0 [psmouse]
[    6.513249]  ? elantech_query_info+0x440/0x440 [psmouse]
[    6.513296]  ? synaptics_send_cmd+0x60/0x60 [psmouse]
[    6.513342]  ? elantech_query_info+0x440/0x440 [psmouse]
[    6.513388]  ? psmouse_try_protocol+0x11e/0x170 [psmouse]
[    6.513432]  psmouse_extensions+0x65d/0x6e0 [psmouse]
[    6.513476]  ? psmouse_try_protocol+0x170/0x170 [psmouse]
[    6.513519]  ? mutex_unlock+0x22/0x40
[    6.513526]  ? ps2_command+0x7f/0x90
[    6.513536]  ? psmouse_probe+0xa3/0xf0 [psmouse]
[    6.513580]  psmouse_switch_protocol+0x27d/0x2e0 [psmouse]
[    6.513624]  psmouse_connect+0x272/0x530 [psmouse]
[    6.513669]  serio_driver_probe+0x55/0x70
[    6.513679]  really_probe+0x190/0x720
[    6.513689]  driver_probe_device+0x160/0x1f0
[    6.513697]  device_driver_attach+0x119/0x130
[    6.513705]  ? device_driver_attach+0x130/0x130
[    6.513713]  __driver_attach+0xe7/0x1a0
[    6.513720]  ? device_driver_attach+0x130/0x130
[    6.513728]  bus_for_each_dev+0xfb/0x150
[    6.513738]  ? subsys_dev_iter_exit+0x10/0x10
[    6.513748]  ? _raw_write_unlock_bh+0x30/0x30
[    6.513757]  driver_attach+0x2d/0x40
[    6.513764]  serio_handle_event+0x199/0x3d0
[    6.513775]  process_one_work+0x471/0x740
[    6.513785]  worker_thread+0x2d2/0x790
[    6.513794]  ? process_one_work+0x740/0x740
[    6.513802]  kthread+0x1b4/0x1e0
[    6.513809]  ? set_kthread_struct+0x80/0x80
[    6.513816]  ret_from_fork+0x22/0x30

[    6.513832] The buggy address belongs to the page:
[    6.513838] page:00000000bc35e189 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1024d7
[    6.513847] flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)
[    6.513860] raw: 0
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47097</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hwmon: (lm90) Prevent integer overflow/underflow in hysteresis calculations

Commit b50aa49638c7 ("hwmon: (lm90) Prevent integer underflows of
temperature calculations") addressed a number of underflow situations
when writing temperature limits. However, it missed one situation, seen
when an attempt is made to set the hysteresis value to MAX_LONG and the
critical temperature limit is negative.

Use clamp_val() when setting the hysteresis temperature to ensure that
the provided value can never overflow or underflow.</Note>
    </Notes>
    <CVE>CVE-2021-47098</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

veth: ensure skb entering GRO are not cloned.

After commit d3256efd8e8b ("veth: allow enabling NAPI even without XDP"),
if GRO is enabled on a veth device and TSO is disabled on the peer
device, TCP skbs will go through the NAPI callback. If there is no XDP
program attached, the veth code does not perform any share check, and
shared/cloned skbs could enter the GRO engine.

Ignat reported a BUG triggered later-on due to the above condition:

[   53.970529][    C1] kernel BUG at net/core/skbuff.c:3574!
[   53.981755][    C1] invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
[   53.982634][    C1] CPU: 1 PID: 19 Comm: ksoftirqd/1 Not tainted 5.16.0-rc5+ #25
[   53.982634][    C1] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
[   53.982634][    C1] RIP: 0010:skb_shift+0x13ef/0x23b0
[   53.982634][    C1] Code: ea 03 0f b6 04 02 48 89 fa 83 e2 07 38 d0
7f 08 84 c0 0f 85 41 0c 00 00 41 80 7f 02 00 4d 8d b5 d0 00 00 00 0f
85 74 f5 ff ff &lt;0f&gt; 0b 4d 8d 77 20 be 04 00 00 00 4c 89 44 24 78 4c 89
f7 4c 89 8c
[   53.982634][    C1] RSP: 0018:ffff8881008f7008 EFLAGS: 00010246
[   53.982634][    C1] RAX: 0000000000000000 RBX: ffff8881180b4c80 RCX: 0000000000000000
[   53.982634][    C1] RDX: 0000000000000002 RSI: ffff8881180b4d3c RDI: ffff88810bc9cac2
[   53.982634][    C1] RBP: ffff8881008f70b8 R08: ffff8881180b4cf4 R09: ffff8881180b4cf0
[   53.982634][    C1] R10: ffffed1022999e5c R11: 0000000000000002 R12: 0000000000000590
[   53.982634][    C1] R13: ffff88810f940c80 R14: ffff88810f940d50 R15: ffff88810bc9cac0
[   53.982634][    C1] FS:  0000000000000000(0000) GS:ffff888235880000(0000) knlGS:0000000000000000
[   53.982634][    C1] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   53.982634][    C1] CR2: 00007ff5f9b86680 CR3: 0000000108ce8004 CR4: 0000000000170ee0
[   53.982634][    C1] Call Trace:
[   53.982634][    C1]  &lt;TASK&gt;
[   53.982634][    C1]  tcp_sacktag_walk+0xaba/0x18e0
[   53.982634][    C1]  tcp_sacktag_write_queue+0xe7b/0x3460
[   53.982634][    C1]  tcp_ack+0x2666/0x54b0
[   53.982634][    C1]  tcp_rcv_established+0x4d9/0x20f0
[   53.982634][    C1]  tcp_v4_do_rcv+0x551/0x810
[   53.982634][    C1]  tcp_v4_rcv+0x22ed/0x2ed0
[   53.982634][    C1]  ip_protocol_deliver_rcu+0x96/0xaf0
[   53.982634][    C1]  ip_local_deliver_finish+0x1e0/0x2f0
[   53.982634][    C1]  ip_sublist_rcv_finish+0x211/0x440
[   53.982634][    C1]  ip_list_rcv_finish.constprop.0+0x424/0x660
[   53.982634][    C1]  ip_list_rcv+0x2c8/0x410
[   53.982634][    C1]  __netif_receive_skb_list_core+0x65c/0x910
[   53.982634][    C1]  netif_receive_skb_list_internal+0x5f9/0xcb0
[   53.982634][    C1]  napi_complete_done+0x188/0x6e0
[   53.982634][    C1]  gro_cell_poll+0x10c/0x1d0
[   53.982634][    C1]  __napi_poll+0xa1/0x530
[   53.982634][    C1]  net_rx_action+0x567/0x1270
[   53.982634][    C1]  __do_softirq+0x28a/0x9ba
[   53.982634][    C1]  run_ksoftirqd+0x32/0x60
[   53.982634][    C1]  smpboot_thread_fn+0x559/0x8c0
[   53.982634][    C1]  kthread+0x3b9/0x490
[   53.982634][    C1]  ret_from_fork+0x22/0x30
[   53.982634][    C1]  &lt;/TASK&gt;

Address the issue by skipping the GRO stage for shared or cloned skbs.
To reduce the chance of OoO, try to unclone the skbs before giving up.

v1 -&gt; v2:
 - use avoid skb_copy and fallback to netif_receive_skb  - Eric</Note>
    </Notes>
    <CVE>CVE-2021-47099</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipmi: Fix UAF when uninstall ipmi_si and ipmi_msghandler module

Hi,

When testing install and uninstall of ipmi_si.ko and ipmi_msghandler.ko,
the system crashed.

The log as follows:
[  141.087026] BUG: unable to handle kernel paging request at ffffffffc09b3a5a
[  141.087241] PGD 8fe4c0d067 P4D 8fe4c0d067 PUD 8fe4c0f067 PMD 103ad89067 PTE 0
[  141.087464] Oops: 0010 [#1] SMP NOPTI
[  141.087580] CPU: 67 PID: 668 Comm: kworker/67:1 Kdump: loaded Not tainted 4.18.0.x86_64 #47
[  141.088009] Workqueue: events 0xffffffffc09b3a40
[  141.088009] RIP: 0010:0xffffffffc09b3a5a
[  141.088009] Code: Bad RIP value.
[  141.088009] RSP: 0018:ffffb9094e2c3e88 EFLAGS: 00010246
[  141.088009] RAX: 0000000000000000 RBX: ffff9abfdb1f04a0 RCX: 0000000000000000
[  141.088009] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
[  141.088009] RBP: 0000000000000000 R08: ffff9abfffee3cb8 R09: 00000000000002e1
[  141.088009] R10: ffffb9094cb73d90 R11: 00000000000f4240 R12: ffff9abfffee8700
[  141.088009] R13: 0000000000000000 R14: ffff9abfdb1f04a0 R15: ffff9abfdb1f04a8
[  141.088009] FS:  0000000000000000(0000) GS:ffff9abfffec0000(0000) knlGS:0000000000000000
[  141.088009] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  141.088009] CR2: ffffffffc09b3a30 CR3: 0000008fe4c0a001 CR4: 00000000007606e0
[  141.088009] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  141.088009] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  141.088009] PKRU: 55555554
[  141.088009] Call Trace:
[  141.088009]  ? process_one_work+0x195/0x390
[  141.088009]  ? worker_thread+0x30/0x390
[  141.088009]  ? process_one_work+0x390/0x390
[  141.088009]  ? kthread+0x10d/0x130
[  141.088009]  ? kthread_flush_work_fn+0x10/0x10
[  141.088009]  ? ret_from_fork+0x35/0x40] BUG: unable to handle kernel paging request at ffffffffc0b28a5a
[  200.223240] PGD 97fe00d067 P4D 97fe00d067 PUD 97fe00f067 PMD a580cbf067 PTE 0
[  200.223464] Oops: 0010 [#1] SMP NOPTI
[  200.223579] CPU: 63 PID: 664 Comm: kworker/63:1 Kdump: loaded Not tainted 4.18.0.x86_64 #46
[  200.224008] Workqueue: events 0xffffffffc0b28a40
[  200.224008] RIP: 0010:0xffffffffc0b28a5a
[  200.224008] Code: Bad RIP value.
[  200.224008] RSP: 0018:ffffbf3c8e2a3e88 EFLAGS: 00010246
[  200.224008] RAX: 0000000000000000 RBX: ffffa0799ad6bca0 RCX: 0000000000000000
[  200.224008] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
[  200.224008] RBP: 0000000000000000 R08: ffff9fe43fde3cb8 R09: 00000000000000d5
[  200.224008] R10: ffffbf3c8cb53d90 R11: 00000000000f4240 R12: ffff9fe43fde8700
[  200.224008] R13: 0000000000000000 R14: ffffa0799ad6bca0 R15: ffffa0799ad6bca8
[  200.224008] FS:  0000000000000000(0000) GS:ffff9fe43fdc0000(0000) knlGS:0000000000000000
[  200.224008] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  200.224008] CR2: ffffffffc0b28a30 CR3: 00000097fe00a002 CR4: 00000000007606e0
[  200.224008] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  200.224008] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  200.224008] PKRU: 55555554
[  200.224008] Call Trace:
[  200.224008]  ? process_one_work+0x195/0x390
[  200.224008]  ? worker_thread+0x30/0x390
[  200.224008]  ? process_one_work+0x390/0x390
[  200.224008]  ? kthread+0x10d/0x130
[  200.224008]  ? kthread_flush_work_fn+0x10/0x10
[  200.224008]  ? ret_from_fork+0x35/0x40
[  200.224008] kernel fault(0x1) notification starting on CPU 63
[  200.224008] kernel fault(0x1) notification finished on CPU 63
[  200.224008] CR2: ffffffffc0b28a5a
[  200.224008] ---[ end trace c82a412d93f57412 ]---

The reason is as follows:
T1: rmmod ipmi_si.
    -&gt;ipmi_unregister_smi()
        -&gt; ipmi_bmc_unregister()
            -&gt; __ipmi_bmc_unregister()
                -&gt; kref_put(&amp;bmc-&gt;usecount, cleanup_bmc_device);
                    -&gt; schedule_work(&amp;bmc-&gt;remove_work);

T2: rmmod ipmi_msghandl
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47100</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

asix: fix uninit-value in asix_mdio_read()

asix_read_cmd() may read less than sizeof(smsr) bytes and in this case
smsr will be uninitialized.

Fail log:
BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline]
BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497
BUG: KMSAN: uninit-value in asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497
 asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline]
 asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497
 asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497</Note>
    </Notes>
    <CVE>CVE-2021-47101</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: marvell: prestera: fix incorrect structure access

In line:
	upper = info-&gt;upper_dev;
We access upper_dev field, which is related only for particular events
(e.g. event == NETDEV_CHANGEUPPER). So, this line cause invalid memory
access for another events,
when ptr is not netdev_notifier_changeupper_info.

The KASAN logs are as follows:

[   30.123165] BUG: KASAN: stack-out-of-bounds in prestera_netdev_port_event.constprop.0+0x68/0x538 [prestera]
[   30.133336] Read of size 8 at addr ffff80000cf772b0 by task udevd/778
[   30.139866]
[   30.141398] CPU: 0 PID: 778 Comm: udevd Not tainted 5.16.0-rc3 #6
[   30.147588] Hardware name: DNI AmazonGo1 A7040 board (DT)
[   30.153056] Call trace:
[   30.155547]  dump_backtrace+0x0/0x2c0
[   30.159320]  show_stack+0x18/0x30
[   30.162729]  dump_stack_lvl+0x68/0x84
[   30.166491]  print_address_description.constprop.0+0x74/0x2b8
[   30.172346]  kasan_report+0x1e8/0x250
[   30.176102]  __asan_load8+0x98/0xe0
[   30.179682]  prestera_netdev_port_event.constprop.0+0x68/0x538 [prestera]
[   30.186847]  prestera_netdev_event_handler+0x1b4/0x1c0 [prestera]
[   30.193313]  raw_notifier_call_chain+0x74/0xa0
[   30.197860]  call_netdevice_notifiers_info+0x68/0xc0
[   30.202924]  register_netdevice+0x3cc/0x760
[   30.207190]  register_netdev+0x24/0x50
[   30.211015]  prestera_device_register+0x8a0/0xba0 [prestera]</Note>
    </Notes>
    <CVE>CVE-2021-47102</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

IB/qib: Fix memory leak in qib_user_sdma_queue_pkts()

The wrong goto label was used for the error case and missed cleanup of the
pkt allocation.

Addresses-Coverity-ID: 1493352 ("Resource leak")</Note>
    </Notes>
    <CVE>CVE-2021-47104</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

NFSD: Fix READDIR buffer overflow

If a client sends a READDIR count argument that is too small (say,
zero), then the buffer size calculation in the new init_dirlist
helper functions results in an underflow, allowing the XDR stream
functions to write beyond the actual buffer.

This calculation has always been suspect. NFSD has never sanity-
checked the READDIR count argument, but the old entry encoders
managed the problem correctly.

With the commits below, entry encoding changed, exposing the
underflow to the pointer arithmetic in xdr_reserve_space().

Modern NFS clients attempt to retrieve as much data as possible
for each READDIR request. Also, we have no unit tests that
exercise the behavior of READDIR at the lower bound of @count
values. Thus this case was missed during testing.</Note>
    </Notes>
    <CVE>CVE-2021-47107</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/mediatek: hdmi: Perform NULL pointer check for mtk_hdmi_conf

In commit 41ca9caaae0b
("drm/mediatek: hdmi: Add check for CEA modes only") a check
for CEA modes was added to function mtk_hdmi_bridge_mode_valid()
in order to address possible issues on MT8167;
moreover, with commit c91026a938c2
("drm/mediatek: hdmi: Add optional limit on maximal HDMI mode clock")
another similar check was introduced.

Unfortunately though, at the time of writing, MT8173 does not provide
any mtk_hdmi_conf structure and this is crashing the kernel with NULL
pointer upon entering mtk_hdmi_bridge_mode_valid(), which happens as
soon as a HDMI cable gets plugged in.

To fix this regression, add a NULL pointer check for hdmi-&gt;conf in the
said function, restoring HDMI functionality and avoiding NULL pointer
kernel panics.</Note>
    </Notes>
    <CVE>CVE-2021-47108</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: musb: tusb6010: check return value after calling platform_get_resource()

It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value.</Note>
    </Notes>
    <CVE>CVE-2021-47181</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: core: Fix scsi_mode_sense() buffer length handling

Several problems exist with scsi_mode_sense() buffer length handling:

 1) The allocation length field of the MODE SENSE(10) command is 16-bits,
    occupying bytes 7 and 8 of the CDB. With this command, access to mode
    pages larger than 255 bytes is thus possible. However, the CDB
    allocation length field is set by assigning len to byte 8 only, thus
    truncating buffer length larger than 255.

 2) If scsi_mode_sense() is called with len smaller than 8 with
    sdev-&gt;use_10_for_ms set, or smaller than 4 otherwise, the buffer length
    is increased to 8 and 4 respectively, and the buffer is zero filled
    with these increased values, thus corrupting the memory following the
    buffer.

Fix these 2 problems by using put_unaligned_be16() to set the allocation
length field of MODE SENSE(10) CDB and by returning an error when len is
too small.

Furthermore, if len is larger than 255B, always try MODE SENSE(10) first,
even if the device driver did not set sdev-&gt;use_10_for_ms. In case of
invalid opcode error for MODE SENSE(10), access to mode pages larger than
255 bytes are not retried using MODE SENSE(6). To avoid buffer length
overflows for the MODE_SENSE(10) case, check that len is smaller than 65535
bytes.

While at it, also fix the folowing:

 * Use get_unaligned_be16() to retrieve the mode data length and block
   descriptor length fields of the mode sense reply header instead of using
   an open coded calculation.

 * Fix the kdoc dbd argument explanation: the DBD bit stands for Disable
   Block Descriptor, which is the opposite of what the dbd argument
   description was.</Note>
    </Notes>
    <CVE>CVE-2021-47182</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 link down processing to address NULL pointer dereference

If an FC link down transition while PLOGIs are outstanding to fabric well
known addresses, outstanding ABTS requests may result in a NULL pointer
dereference. Driver unload requests may hang with repeated "2878" log
messages.

The Link down processing results in ABTS requests for outstanding ELS
requests. The Abort WQEs are sent for the ELSs before the driver had set
the link state to down. Thus the driver is sending the Abort with the
expectation that an ABTS will be sent on the wire. The Abort request is
stalled waiting for the link to come up. In some conditions the driver may
auto-complete the ELSs thus if the link does come up, the Abort completions
may reference an invalid structure.

Fix by ensuring that Abort set the flag to avoid link traffic if issued due
to conditions where the link failed.</Note>
    </Notes>
    <CVE>CVE-2021-47183</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 NULL ptr dereference on VSI filter sync

Remove the reason of null pointer dereference in sync VSI filters.
Added new I40E_VSI_RELEASING flag to signalize deleting and releasing
of VSI resources to sync this thread with sync filters subtask.
Without this patch it is possible to start update the VSI filter list
after VSI is removed, that's causing a kernel oops.</Note>
    </Notes>
    <CVE>CVE-2021-47184</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: tty_buffer: Fix the softlockup issue in flush_to_ldisc

When running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup,
which look like this one:

  Workqueue: events_unbound flush_to_ldisc
  Call trace:
   dump_backtrace+0x0/0x1ec
   show_stack+0x24/0x30
   dump_stack+0xd0/0x128
   panic+0x15c/0x374
   watchdog_timer_fn+0x2b8/0x304
   __run_hrtimer+0x88/0x2c0
   __hrtimer_run_queues+0xa4/0x120
   hrtimer_interrupt+0xfc/0x270
   arch_timer_handler_phys+0x40/0x50
   handle_percpu_devid_irq+0x94/0x220
   __handle_domain_irq+0x88/0xf0
   gic_handle_irq+0x84/0xfc
   el1_irq+0xc8/0x180
   slip_unesc+0x80/0x214 [slip]
   tty_ldisc_receive_buf+0x64/0x80
   tty_port_default_receive_buf+0x50/0x90
   flush_to_ldisc+0xbc/0x110
   process_one_work+0x1d4/0x4b0
   worker_thread+0x180/0x430
   kthread+0x11c/0x120

In the testcase pty04, The first process call the write syscall to send
data to the pty master. At the same time, the workqueue will do the
flush_to_ldisc to pop data in a loop until there is no more data left.
When the sender and workqueue running in different core, the sender sends
data fastly in full time which will result in workqueue doing work in loop
for a long time and occuring softlockup in flush_to_ldisc with kernel
configured without preempt. So I add need_resched check and cond_resched
in the flush_to_ldisc loop to avoid it.</Note>
    </Notes>
    <CVE>CVE-2021-47185</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

arm64: dts: qcom: msm8998: Fix CPU/L2 idle state latency and residency

The entry/exit latency and minimum residency in state for the idle
states of MSM8998 were ..bad: first of all, for all of them the
timings were written for CPU sleep but the min-residency-us param
was miscalculated (supposedly, while porting this from downstream);
Then, the power collapse states are setting PC on both the CPU
cluster *and* the L2 cache, which have different timings: in the
specific case of L2 the times are higher so these ones should be
taken into account instead of the CPU ones.

This parameter misconfiguration was not giving particular issues
because on MSM8998 there was no CPU scaling at all, so cluster/L2
power collapse was rarely (if ever) hit.
When CPU scaling is enabled, though, the wrong timings will produce
SoC unstability shown to the user as random, apparently error-less,
sudden reboots and/or lockups.

This set of parameters are stabilizing the SoC when CPU scaling is
ON and when power collapse is frequently hit.</Note>
    </Notes>
    <CVE>CVE-2021-47187</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: ufs: core: Improve SCSI abort handling

The following has been observed on a test setup:

WARNING: CPU: 4 PID: 250 at drivers/scsi/ufs/ufshcd.c:2737 ufshcd_queuecommand+0x468/0x65c
Call trace:
 ufshcd_queuecommand+0x468/0x65c
 scsi_send_eh_cmnd+0x224/0x6a0
 scsi_eh_test_devices+0x248/0x418
 scsi_eh_ready_devs+0xc34/0xe58
 scsi_error_handler+0x204/0x80c
 kthread+0x150/0x1b4
 ret_from_fork+0x10/0x30

That warning is triggered by the following statement:

	WARN_ON(lrbp-&gt;cmd);

Fix this warning by clearing lrbp-&gt;cmd from the abort handler.</Note>
    </Notes>
    <CVE>CVE-2021-47188</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix memory ordering between normal and ordered work functions

Ordered work functions aren't guaranteed to be handled by the same thread
which executed the normal work functions. The only way execution between
normal/ordered functions is synchronized is via the WORK_DONE_BIT,
unfortunately the used bitops don't guarantee any ordering whatsoever.

This manifested as seemingly inexplicable crashes on ARM64, where
async_chunk::inode is seen as non-null in async_cow_submit which causes
submit_compressed_extents to be called and crash occurs because
async_chunk::inode suddenly became NULL. The call trace was similar to:

    pc : submit_compressed_extents+0x38/0x3d0
    lr : async_cow_submit+0x50/0xd0
    sp : ffff800015d4bc20

    &lt;registers omitted for brevity&gt;

    Call trace:
     submit_compressed_extents+0x38/0x3d0
     async_cow_submit+0x50/0xd0
     run_ordered_work+0xc8/0x280
     btrfs_work_helper+0x98/0x250
     process_one_work+0x1f0/0x4ac
     worker_thread+0x188/0x504
     kthread+0x110/0x114
     ret_from_fork+0x10/0x18

Fix this by adding respective barrier calls which ensure that all
accesses preceding setting of WORK_DONE_BIT are strictly ordered before
setting the flag. At the same time add a read barrier after reading of
WORK_DONE_BIT in run_ordered_work which ensures all subsequent loads
would be strictly ordered after reading the bit. This in turn ensures
are all accesses before WORK_DONE_BIT are going to be strictly ordered
before any access that can occur in ordered_func.</Note>
    </Notes>
    <CVE>CVE-2021-47189</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: scsi_debug: Fix out-of-bound read in resp_readcap16()

The following warning was observed running syzkaller:

[ 3813.830724] sg_write: data in/out 65466/242 bytes for SCSI command 0x9e-- guessing data in;
[ 3813.830724]    program syz-executor not setting count and/or reply_len properly
[ 3813.836956] ==================================================================
[ 3813.839465] BUG: KASAN: stack-out-of-bounds in sg_copy_buffer+0x157/0x1e0
[ 3813.841773] Read of size 4096 at addr ffff8883cf80f540 by task syz-executor/1549
[ 3813.846612] Call Trace:
[ 3813.846995]  dump_stack+0x108/0x15f
[ 3813.847524]  print_address_description+0xa5/0x372
[ 3813.848243]  kasan_report.cold+0x236/0x2a8
[ 3813.849439]  check_memory_region+0x240/0x270
[ 3813.850094]  memcpy+0x30/0x80
[ 3813.850553]  sg_copy_buffer+0x157/0x1e0
[ 3813.853032]  sg_copy_from_buffer+0x13/0x20
[ 3813.853660]  fill_from_dev_buffer+0x135/0x370
[ 3813.854329]  resp_readcap16+0x1ac/0x280
[ 3813.856917]  schedule_resp+0x41f/0x1630
[ 3813.858203]  scsi_debug_queuecommand+0xb32/0x17e0
[ 3813.862699]  scsi_dispatch_cmd+0x330/0x950
[ 3813.863329]  scsi_request_fn+0xd8e/0x1710
[ 3813.863946]  __blk_run_queue+0x10b/0x230
[ 3813.864544]  blk_execute_rq_nowait+0x1d8/0x400
[ 3813.865220]  sg_common_write.isra.0+0xe61/0x2420
[ 3813.871637]  sg_write+0x6c8/0xef0
[ 3813.878853]  __vfs_write+0xe4/0x800
[ 3813.883487]  vfs_write+0x17b/0x530
[ 3813.884008]  ksys_write+0x103/0x270
[ 3813.886268]  __x64_sys_write+0x77/0xc0
[ 3813.886841]  do_syscall_64+0x106/0x360
[ 3813.887415]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

This issue can be reproduced with the following syzkaller log:

r0 = openat(0xffffffffffffff9c, &amp;(0x7f0000000040)='./file0\x00', 0x26e1, 0x0)
r1 = syz_open_procfs(0xffffffffffffffff, &amp;(0x7f0000000000)='fd/3\x00')
open_by_handle_at(r1, &amp;(0x7f00000003c0)=ANY=[@ANYRESHEX], 0x602000)
r2 = syz_open_dev$sg(&amp;(0x7f0000000000), 0x0, 0x40782)
write$binfmt_aout(r2, &amp;(0x7f0000000340)=ANY=[@ANYBLOB="00000000deff000000000000000000000000000000000000000000000000000047f007af9e107a41ec395f1bded7be24277a1501ff6196a83366f4e6362bc0ff2b247f68a972989b094b2da4fb3607fcf611a22dd04310d28c75039d"], 0x126)

In resp_readcap16() we get "int alloc_len" value -1104926854, and then pass
the huge arr_len to fill_from_dev_buffer(), but arr is only 32 bytes. This
leads to OOB in sg_copy_buffer().

To solve this issue, define alloc_len as u32.</Note>
    </Notes>
    <CVE>CVE-2021-47191</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: core: sysfs: Fix hang when device state is set via sysfs

This fixes a regression added with:

commit f0f82e2476f6 ("scsi: core: Fix capacity set to zero after
offlinining device")

The problem is that after iSCSI recovery, iscsid will call into the kernel
to set the dev's state to running, and with that patch we now call
scsi_rescan_device() with the state_mutex held. If the SCSI error handler
thread is just starting to test the device in scsi_send_eh_cmnd() then it's
going to try to grab the state_mutex.

We are then stuck, because when scsi_rescan_device() tries to send its I/O
scsi_queue_rq() calls -&gt; scsi_host_queue_ready() -&gt; scsi_host_in_recovery()
which will return true (the host state is still in recovery) and I/O will
just be requeued. scsi_send_eh_cmnd() will then never be able to grab the
state_mutex to finish error handling.

To prevent the deadlock move the rescan-related code to after we drop the
state_mutex.

This also adds a check for if we are already in the running state. This
prevents extra scans and helps the iscsid case where if the transport class
has already onlined the device during its recovery process then we don't
need userspace to do it again plus possibly block that daemon.</Note>
    </Notes>
    <CVE>CVE-2021-47192</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: pm80xx: Fix memory leak during rmmod

Driver failed to release all memory allocated. This would lead to memory
leak during driver removal.

Properly free memory when the module is removed.</Note>
    </Notes>
    <CVE>CVE-2021-47193</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cfg80211: call cfg80211_stop_ap when switch from P2P_GO type

If the userspace tools switch from NL80211_IFTYPE_P2P_GO to
NL80211_IFTYPE_ADHOC via send_msg(NL80211_CMD_SET_INTERFACE), it
does not call the cleanup cfg80211_stop_ap(), this leads to the
initialization of in-use data. For example, this path re-init the
sdata-&gt;assigned_chanctx_list while it is still an element of
assigned_vifs list, and makes that linked list corrupt.</Note>
    </Notes>
    <CVE>CVE-2021-47194</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

spi: fix use-after-free of the add_lock mutex

Commit 6098475d4cb4 ("spi: Fix deadlock when adding SPI controllers on
SPI buses") introduced a per-controller mutex. But mutex_unlock() of
said lock is called after the controller is already freed:

  spi_unregister_controller(ctlr)
  -&gt; put_device(&amp;ctlr-&gt;dev)
    -&gt; spi_controller_release(dev)
  -&gt; mutex_unlock(&amp;ctrl-&gt;add_lock)

Move the put_device() after the mutex_unlock().</Note>
    </Notes>
    <CVE>CVE-2021-47195</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/core: Set send and receive CQ before forwarding to the driver

Preset both receive and send CQ pointers prior to call to the drivers and
overwrite it later again till the mlx4 is going to be changed do not
overwrite ibqp properties.

This change is needed for mlx5, because in case of QP creation failure, it
will go to the path of QP destroy which relies on proper CQ pointers.

 BUG: KASAN: use-after-free in create_qp.cold+0x164/0x16e [mlx5_ib]
 Write of size 8 at addr ffff8880064c55c0 by task a.out/246

 CPU: 0 PID: 246 Comm: a.out Not tainted 5.15.0+ #291
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
 Call Trace:
  dump_stack_lvl+0x45/0x59
  print_address_description.constprop.0+0x1f/0x140
  kasan_report.cold+0x83/0xdf
  create_qp.cold+0x164/0x16e [mlx5_ib]
  mlx5_ib_create_qp+0x358/0x28a0 [mlx5_ib]
  create_qp.part.0+0x45b/0x6a0 [ib_core]
  ib_create_qp_user+0x97/0x150 [ib_core]
  ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs]
  ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs]
  ib_uverbs_ioctl+0x169/0x260 [ib_uverbs]
  __x64_sys_ioctl+0x866/0x14d0
  do_syscall_64+0x3d/0x90
  entry_SYSCALL_64_after_hwframe+0x44/0xae

 Allocated by task 246:
  kasan_save_stack+0x1b/0x40
  __kasan_kmalloc+0xa4/0xd0
  create_qp.part.0+0x92/0x6a0 [ib_core]
  ib_create_qp_user+0x97/0x150 [ib_core]
  ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs]
  ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs]
  ib_uverbs_ioctl+0x169/0x260 [ib_uverbs]
  __x64_sys_ioctl+0x866/0x14d0
  do_syscall_64+0x3d/0x90
  entry_SYSCALL_64_after_hwframe+0x44/0xae

 Freed by task 246:
  kasan_save_stack+0x1b/0x40
  kasan_set_track+0x1c/0x30
  kasan_set_free_info+0x20/0x30
  __kasan_slab_free+0x10c/0x150
  slab_free_freelist_hook+0xb4/0x1b0
  kfree+0xe7/0x2a0
  create_qp.part.0+0x52b/0x6a0 [ib_core]
  ib_create_qp_user+0x97/0x150 [ib_core]
  ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs]
  ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs]
  ib_uverbs_ioctl+0x169/0x260 [ib_uverbs]
  __x64_sys_ioctl+0x866/0x14d0
  do_syscall_64+0x3d/0x90
  entry_SYSCALL_64_after_hwframe+0x44/0xae</Note>
    </Notes>
    <CVE>CVE-2021-47196</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: nullify cq-&gt;dbg pointer in mlx5_debug_cq_remove()

Prior to this patch in case mlx5_core_destroy_cq() failed it proceeds
to rest of destroy operations. mlx5_core_destroy_cq() could be called again
by user and cause additional call of mlx5_debug_cq_remove().
cq-&gt;dbg was not nullify in previous call and cause the crash.

Fix it by nullify cq-&gt;dbg pointer after removal.

Also proceed to destroy operations only if FW return 0
for MLX5_CMD_OP_DESTROY_CQ command.

general protection fault, probably for non-canonical address 0x2000300004058: 0000 [#1] SMP PTI
CPU: 5 PID: 1228 Comm: python Not tainted 5.15.0-rc5_for_upstream_min_debug_2021_10_14_11_06 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:lockref_get+0x1/0x60
Code: 5d e9 53 ff ff ff 48 8d 7f 70 e8 0a 2e 48 00 c7 85 d0 00 00 00 02
00 00 00 c6 45 70 00 fb 5d c3 c3 cc cc cc cc cc cc cc cc 53 &lt;48&gt; 8b 17
48 89 fb 85 d2 75 3d 48 89 d0 bf 64 00 00 00 48 89 c1 48
RSP: 0018:ffff888137dd7a38 EFLAGS: 00010206
RAX: 0000000000000000 RBX: ffff888107d5f458 RCX: 00000000fffffffe
RDX: 000000000002c2b0 RSI: ffffffff8155e2e0 RDI: 0002000300004058
RBP: ffff888137dd7a88 R08: 0002000300004058 R09: ffff8881144a9f88
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881141d4000
R13: ffff888137dd7c68 R14: ffff888137dd7d58 R15: ffff888137dd7cc0
FS:  00007f4644f2a4c0(0000) GS:ffff8887a2d40000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055b4500f4380 CR3: 0000000114f7a003 CR4: 0000000000170ea0
Call Trace:
  simple_recursive_removal+0x33/0x2e0
  ? debugfs_remove+0x60/0x60
  debugfs_remove+0x40/0x60
  mlx5_debug_cq_remove+0x32/0x70 [mlx5_core]
  mlx5_core_destroy_cq+0x41/0x1d0 [mlx5_core]
  devx_obj_cleanup+0x151/0x330 [mlx5_ib]
  ? __pollwait+0xd0/0xd0
  ? xas_load+0x5/0x70
  ? xa_load+0x62/0xa0
  destroy_hw_idr_uobject+0x20/0x80 [ib_uverbs]
  uverbs_destroy_uobject+0x3b/0x360 [ib_uverbs]
  uobj_destroy+0x54/0xa0 [ib_uverbs]
  ib_uverbs_cmd_verbs+0xaf2/0x1160 [ib_uverbs]
  ? uverbs_finalize_object+0xd0/0xd0 [ib_uverbs]
  ib_uverbs_ioctl+0xc4/0x1b0 [ib_uverbs]
  __x64_sys_ioctl+0x3e4/0x8e0</Note>
    </Notes>
    <CVE>CVE-2021-47197</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 use-after-free in lpfc_unreg_rpi() routine

An error is detected with the following report when unloading the driver:
  "KASAN: use-after-free in lpfc_unreg_rpi+0x1b1b"

The NLP_REG_LOGIN_SEND nlp_flag is set in lpfc_reg_fab_ctrl_node(), but the
flag is not cleared upon completion of the login.

This allows a second call to lpfc_unreg_rpi() to proceed with nlp_rpi set
to LPFC_RPI_ALLOW_ERROR.  This results in a use after free access when used
as an rpi_ids array index.

Fix by clearing the NLP_REG_LOGIN_SEND nlp_flag in
lpfc_mbx_cmpl_fc_reg_login().</Note>
    </Notes>
    <CVE>CVE-2021-47198</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: CT, Fix multiple allocations and memleak of mod acts

CT clear action offload adds additional mod hdr actions to the
flow's original mod actions in order to clear the registers which
hold ct_state.
When such flow also includes encap action, a neigh update event
can cause the driver to unoffload the flow and then reoffload it.

Each time this happens, the ct clear handling adds that same set
of mod hdr actions to reset ct_state until the max of mod hdr
actions is reached.

Also the driver never releases the allocated mod hdr actions and
causing a memleak.

Fix above two issues by moving CT clear mod acts allocation
into the parsing actions phase and only use it when offloading the rule.
The release of mod acts will be done in the normal flow_put().

 backtrace:
    [&lt;000000007316e2f3&gt;] krealloc+0x83/0xd0
    [&lt;00000000ef157de1&gt;] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core]
    [&lt;00000000970ce4ae&gt;] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core]
    [&lt;0000000067c5fa17&gt;] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core]
    [&lt;00000000d032eb98&gt;] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core]
    [&lt;00000000fd23b869&gt;] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core]
    [&lt;000000004fc24acc&gt;] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core]
    [&lt;00000000dc741c17&gt;] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core]
    [&lt;00000000e92e49d7&gt;] mlx5e_rep_update_flows+0x6e4/0x9b0 [mlx5_core]
    [&lt;00000000f60f5602&gt;] mlx5e_rep_neigh_update+0x39a/0x5d0 [mlx5_core]</Note>
    </Notes>
    <CVE>CVE-2021-47199</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/prime: Fix use after free in mmap with drm_gem_ttm_mmap

drm_gem_ttm_mmap() drops a reference to the gem object on success. If
the gem object's refcount == 1 on entry to drm_gem_prime_mmap(), that
drop will free the gem object, and the subsequent drm_gem_object_get()
will be a UAF. Fix by grabbing a reference before calling the mmap
helper.

This issue was forseen when the reference dropping was adding in
commit 9786b65bc61ac ("drm/ttm: fix mmap refcounting"):
  "For that to work properly the drm_gem_object_get() call in
  drm_gem_ttm_mmap() must be moved so it happens before calling
  obj-&gt;funcs-&gt;mmap(), otherwise the gem refcount would go down
  to zero."</Note>
    </Notes>
    <CVE>CVE-2021-47200</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iavf: free q_vectors before queues in iavf_disable_vf

iavf_free_queues() clears adapter-&gt;num_active_queues, which
iavf_free_q_vectors() relies on, so swap the order of these two function
calls in iavf_disable_vf(). This resolves a panic encountered when the
interface is disabled and then later brought up again after PF
communication is restored.</Note>
    </Notes>
    <CVE>CVE-2021-47201</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

thermal: Fix NULL pointer dereferences in of_thermal_ functions

of_parse_thermal_zones() parses the thermal-zones node and registers a
thermal_zone device for each subnode. However, if a thermal zone is
consuming a thermal sensor and that thermal sensor device hasn't probed
yet, an attempt to set trip_point_*_temp for that thermal zone device
can cause a NULL pointer dereference. Fix it.

 console:/sys/class/thermal/thermal_zone87 # echo 120000 &gt; trip_point_0_temp
 ...
 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
 ...
 Call trace:
  of_thermal_set_trip_temp+0x40/0xc4
  trip_point_temp_store+0xc0/0x1dc
  dev_attr_store+0x38/0x88
  sysfs_kf_write+0x64/0xc0
  kernfs_fop_write_iter+0x108/0x1d0
  vfs_write+0x2f4/0x368
  ksys_write+0x7c/0xec
  __arm64_sys_write+0x20/0x30
  el0_svc_common.llvm.7279915941325364641+0xbc/0x1bc
  do_el0_svc+0x28/0xa0
  el0_svc+0x14/0x24
  el0_sync_handler+0x88/0xec
  el0_sync+0x1c0/0x200

While at it, fix the possible NULL pointer dereference in other
functions as well: of_thermal_get_temp(), of_thermal_set_emul_temp(),
of_thermal_get_trend().</Note>
    </Notes>
    <CVE>CVE-2021-47202</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 list_add() corruption in lpfc_drain_txq()

When parsing the txq list in lpfc_drain_txq(), the driver attempts to pass
the requests to the adapter. If such an attempt fails, a local "fail_msg"
string is set and a log message output.  The job is then added to a
completions list for cancellation.

Processing of any further jobs from the txq list continues, but since
"fail_msg" remains set, jobs are added to the completions list regardless
of whether a wqe was passed to the adapter.  If successfully added to
txcmplq, jobs are added to both lists resulting in list corruption.

Fix by clearing the fail_msg string after adding a job to the completions
list. This stops the subsequent jobs from being added to the completions
list unless they had an appropriate failure.</Note>
    </Notes>
    <CVE>CVE-2021-47203</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: dpaa2-eth: fix use-after-free in dpaa2_eth_remove

Access to netdev after free_netdev() will cause use-after-free bug.
Move debug log before free_netdev() call to avoid it.</Note>
    </Notes>
    <CVE>CVE-2021-47204</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sunxi-ng: Unregister clocks/resets when unbinding

Currently, unbinding a CCU driver unmaps the device's MMIO region, while
leaving its clocks/resets and their providers registered. This can cause
a page fault later when some clock operation tries to perform MMIO. Fix
this by separating the CCU initialization from the memory allocation,
and then using a devres callback to unregister the clocks and resets.

This also fixes a memory leak of the `struct ccu_reset`, and uses the
correct owner (the specific platform driver) for the clocks and resets.

Early OF clock providers are never unregistered, and limited error
handling is possible, so they are mostly unchanged. The error reporting
is made more consistent by moving the message inside of_sunxi_ccu_probe.</Note>
    </Notes>
    <CVE>CVE-2021-47205</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-tmio: check return value after calling platform_get_resource()

It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value.</Note>
    </Notes>
    <CVE>CVE-2021-47206</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: gus: fix null pointer dereference on pointer block

The pointer block return from snd_gf1_dma_next_block could be
null, so there is a potential null pointer dereference issue.
Fix this by adding a null check before dereference.</Note>
    </Notes>
    <CVE>CVE-2021-47207</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sched/fair: Prevent dead task groups from regaining cfs_rq's

Kevin is reporting crashes which point to a use-after-free of a cfs_rq
in update_blocked_averages(). Initial debugging revealed that we've
live cfs_rq's (on_list=1) in an about to be kfree()'d task group in
free_fair_sched_group(). However, it was unclear how that can happen.

His kernel config happened to lead to a layout of struct sched_entity
that put the 'my_q' member directly into the middle of the object
which makes it incidentally overlap with SLUB's freelist pointer.
That, in combination with SLAB_FREELIST_HARDENED's freelist pointer
mangling, leads to a reliable access violation in form of a #GP which
made the UAF fail fast.

Michal seems to have run into the same issue[1]. He already correctly
diagnosed that commit a7b359fc6a37 ("sched/fair: Correctly insert
cfs_rq's to list on unthrottle") is causing the preconditions for the
UAF to happen by re-adding cfs_rq's also to task groups that have no
more running tasks, i.e. also to dead ones. His analysis, however,
misses the real root cause and it cannot be seen from the crash
backtrace only, as the real offender is tg_unthrottle_up() getting
called via sched_cfs_period_timer() via the timer interrupt at an
inconvenient time.

When unregister_fair_sched_group() unlinks all cfs_rq's from the dying
task group, it doesn't protect itself from getting interrupted. If the
timer interrupt triggers while we iterate over all CPUs or after
unregister_fair_sched_group() has finished but prior to unlinking the
task group, sched_cfs_period_timer() will execute and walk the list of
task groups, trying to unthrottle cfs_rq's, i.e. re-add them to the
dying task group. These will later -- in free_fair_sched_group() -- be
kfree()'ed while still being linked, leading to the fireworks Kevin
and Michal are seeing.

To fix this race, ensure the dying task group gets unlinked first.
However, simply switching the order of unregistering and unlinking the
task group isn't sufficient, as concurrent RCU walkers might still see
it, as can be seen below:

    CPU1:                                      CPU2:
      :                                        timer IRQ:
      :                                          do_sched_cfs_period_timer():
      :                                            :
      :                                            distribute_cfs_runtime():
      :                                              rcu_read_lock();
      :                                              :
      :                                              unthrottle_cfs_rq():
    sched_offline_group():                             :
      :                                                walk_tg_tree_from(…,tg_unthrottle_up,…):
      list_del_rcu(&amp;tg-&gt;list);                           :
 (1)  :                                                  list_for_each_entry_rcu(child, &amp;parent-&gt;children, siblings)
      :                                                    :
 (2)  list_del_rcu(&amp;tg-&gt;siblings);                         :
      :                                                    tg_unthrottle_up():
      unregister_fair_sched_group():                         struct cfs_rq *cfs_rq = tg-&gt;cfs_rq[cpu_of(rq)];
        :                                                    :
        list_del_leaf_cfs_rq(tg-&gt;cfs_rq[cpu]);               :
        :                                                    :
        :                                                    if (!cfs_rq_is_decayed(cfs_rq) || cfs_rq-&gt;nr_running)
 (3)    :                                                        list_add_leaf_cfs_rq(cfs_rq);
      :                                                      :
      :                                                    :
      :                                                  :
      :                                                :
      :                           
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47209</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: typec: tipd: Remove WARN_ON in tps6598x_block_read

Calling tps6598x_block_read with a higher than allowed len can be
handled by just returning an error. There's no need to crash systems
with panic-on-warn enabled.</Note>
    </Notes>
    <CVE>CVE-2021-47210</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb-audio: fix null pointer dereference on pointer cs_desc

The pointer cs_desc return from snd_usb_find_clock_source could
be null, so there is a potential null pointer dereference issue.
Fix this by adding a null check before dereference.</Note>
    </Notes>
    <CVE>CVE-2021-47211</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: Update error handler for UCTX and UMEM

In the fast unload flow, the device state is set to internal error,
which indicates that the driver started the destroy process.
In this case, when a destroy command is being executed, it should return
MLX5_CMD_STAT_OK.
Fix MLX5_CMD_OP_DESTROY_UCTX and MLX5_CMD_OP_DESTROY_UMEM to return OK
instead of EIO.

This fixes a call trace in the umem release process -
[ 2633.536695] Call Trace:
[ 2633.537518]  ib_uverbs_remove_one+0xc3/0x140 [ib_uverbs]
[ 2633.538596]  remove_client_context+0x8b/0xd0 [ib_core]
[ 2633.539641]  disable_device+0x8c/0x130 [ib_core]
[ 2633.540615]  __ib_unregister_device+0x35/0xa0 [ib_core]
[ 2633.541640]  ib_unregister_device+0x21/0x30 [ib_core]
[ 2633.542663]  __mlx5_ib_remove+0x38/0x90 [mlx5_ib]
[ 2633.543640]  auxiliary_bus_remove+0x1e/0x30 [auxiliary]
[ 2633.544661]  device_release_driver_internal+0x103/0x1f0
[ 2633.545679]  bus_remove_device+0xf7/0x170
[ 2633.546640]  device_del+0x181/0x410
[ 2633.547606]  mlx5_rescan_drivers_locked.part.10+0x63/0x160 [mlx5_core]
[ 2633.548777]  mlx5_unregister_device+0x27/0x40 [mlx5_core]
[ 2633.549841]  mlx5_uninit_one+0x21/0xc0 [mlx5_core]
[ 2633.550864]  remove_one+0x69/0xe0 [mlx5_core]
[ 2633.551819]  pci_device_remove+0x3b/0xc0
[ 2633.552731]  device_release_driver_internal+0x103/0x1f0
[ 2633.553746]  unbind_store+0xf6/0x130
[ 2633.554657]  kernfs_fop_write+0x116/0x190
[ 2633.555567]  vfs_write+0xa5/0x1a0
[ 2633.556407]  ksys_write+0x4f/0xb0
[ 2633.557233]  do_syscall_64+0x5b/0x1a0
[ 2633.558071]  entry_SYSCALL_64_after_hwframe+0x65/0xca
[ 2633.559018] RIP: 0033:0x7f9977132648
[ 2633.559821] Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 55 6f 2d 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55
[ 2633.562332] RSP: 002b:00007fffb1a83888 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 2633.563472] RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007f9977132648
[ 2633.564541] RDX: 000000000000000c RSI: 000055b90546e230 RDI: 0000000000000001
[ 2633.565596] RBP: 000055b90546e230 R08: 00007f9977406860 R09: 00007f9977a54740
[ 2633.566653] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f99774056e0
[ 2633.567692] R13: 000000000000000c R14: 00007f9977400880 R15: 000000000000000c
[ 2633.568725] ---[ end trace 10b4fe52945e544d ]---</Note>
    </Notes>
    <CVE>CVE-2021-47212</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: kTLS, Fix crash in RX resync flow

For the TLS RX resync flow, we maintain a list of TLS contexts
that require some attention, to communicate their resync information
to the HW.
Here we fix list corruptions, by protecting the entries against
movements coming from resync_handle_seq_match(), until their resync
handling in napi is fully completed.</Note>
    </Notes>
    <CVE>CVE-2021-47215</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: advansys: Fix kernel pointer leak

Pointers should be printed with %p or %px rather than cast to 'unsigned
long' and printed with %lx.

Change %lx to %p to print the hashed pointer.</Note>
    </Notes>
    <CVE>CVE-2021-47216</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

x86/hyperv: Fix NULL deref in set_hv_tscchange_cb() if Hyper-V setup fails

Check for a valid hv_vp_index array prior to derefencing hv_vp_index when
setting Hyper-V's TSC change callback.  If Hyper-V setup failed in
hyperv_init(), the kernel will still report that it's running under
Hyper-V, but will have silently disabled nearly all functionality.

  BUG: kernel NULL pointer dereference, address: 0000000000000010
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: 0000 [#1] SMP
  CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.15.0-rc2+ #75
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
  RIP: 0010:set_hv_tscchange_cb+0x15/0xa0
  Code: &lt;8b&gt; 04 82 8b 15 12 17 85 01 48 c1 e0 20 48 0d ee 00 01 00 f6 c6 08
  ...
  Call Trace:
   kvm_arch_init+0x17c/0x280
   kvm_init+0x31/0x330
   vmx_init+0xba/0x13a
   do_one_initcall+0x41/0x1c0
   kernel_init_freeable+0x1f2/0x23b
   kernel_init+0x16/0x120
   ret_from_fork+0x22/0x30</Note>
    </Notes>
    <CVE>CVE-2021-47217</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix NULL-pointer dereference when hashtab allocation fails

When the hash table slot array allocation fails in hashtab_init(),
h-&gt;size is left initialized with a non-zero value, but the h-&gt;htable
pointer is NULL. This may then cause a NULL pointer dereference, since
the policydb code relies on the assumption that even after a failed
hashtab_init(), hashtab_map() and hashtab_destroy() can be safely called
on it. Yet, these detect an empty hashtab only by looking at the size.

Fix this by making sure that hashtab_init() always leaves behind a valid
empty hashtab when the allocation fails.</Note>
    </Notes>
    <CVE>CVE-2021-47218</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: scsi_debug: Fix out-of-bound read in resp_report_tgtpgs()

The following issue was observed running syzkaller:

BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:377 [inline]
BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831
Read of size 2132 at addr ffff8880aea95dc8 by task syz-executor.0/9815

CPU: 0 PID: 9815 Comm: syz-executor.0 Not tainted 4.19.202-00874-gfc0fe04215a9 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0xe4/0x14a lib/dump_stack.c:118
 print_address_description+0x73/0x280 mm/kasan/report.c:253
 kasan_report_error mm/kasan/report.c:352 [inline]
 kasan_report+0x272/0x370 mm/kasan/report.c:410
 memcpy+0x1f/0x50 mm/kasan/kasan.c:302
 memcpy include/linux/string.h:377 [inline]
 sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831
 fill_from_dev_buffer+0x14f/0x340 drivers/scsi/scsi_debug.c:1021
 resp_report_tgtpgs+0x5aa/0x770 drivers/scsi/scsi_debug.c:1772
 schedule_resp+0x464/0x12f0 drivers/scsi/scsi_debug.c:4429
 scsi_debug_queuecommand+0x467/0x1390 drivers/scsi/scsi_debug.c:5835
 scsi_dispatch_cmd+0x3fc/0x9b0 drivers/scsi/scsi_lib.c:1896
 scsi_request_fn+0x1042/0x1810 drivers/scsi/scsi_lib.c:2034
 __blk_run_queue_uncond block/blk-core.c:464 [inline]
 __blk_run_queue+0x1a4/0x380 block/blk-core.c:484
 blk_execute_rq_nowait+0x1c2/0x2d0 block/blk-exec.c:78
 sg_common_write.isra.19+0xd74/0x1dc0 drivers/scsi/sg.c:847
 sg_write.part.23+0x6e0/0xd00 drivers/scsi/sg.c:716
 sg_write+0x64/0xa0 drivers/scsi/sg.c:622
 __vfs_write+0xed/0x690 fs/read_write.c:485
kill_bdev:block_device:00000000e138492c
 vfs_write+0x184/0x4c0 fs/read_write.c:549
 ksys_write+0x107/0x240 fs/read_write.c:599
 do_syscall_64+0xc2/0x560 arch/x86/entry/common.c:293
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

We get 'alen' from command its type is int. If userspace passes a large
length we will get a negative 'alen'.

Switch n, alen, and rlen to u32.</Note>
    </Notes>
    <CVE>CVE-2021-47219</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 rtsx_usb_ms_drv_remove in drivers/memstick/host/rtsx_usb_ms.c in memstick in the Linux kernel. In this flaw, a local attacker with a user privilege may impact system Confidentiality. This flaw affects kernel versions prior to 5.14 rc1.</Note>
    </Notes>
    <CVE>CVE-2022-0487</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>2.1</BaseScore>
        <Vector>AV:L/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">In lock_sock_nested of sock.c, there is a possible use after free due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-174846563References: Upstream kernel</Note>
    </Notes>
    <CVE>CVE-2022-20154</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>4.4</BaseScore>
        <Vector>AV:L/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">A double-free flaw was found in the Linux kernel's TUN/TAP device driver functionality in how a user registers the device when the register_netdevice function fails (NETDEV_REGISTER notifier). This flaw allows a local user to crash or potentially escalate their privileges on the system.</Note>
    </Notes>
    <CVE>CVE-2022-4744</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">close_altfile in filename.c in less before 606 omits shell_quote calls for LESSCLOSE.</Note>
    </Notes>
    <CVE>CVE-2022-48624</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: qcom-rng - ensure buffer for generate is completely filled

The generate function in struct rng_alg expects that the destination
buffer is completely filled if the function returns 0. qcom_rng_read()
can run into a situation where the buffer is partially filled with
randomness and the remaining part of the buffer is zeroed since
qcom_rng_generate() doesn't check the return value. This issue can
be reproduced by running the following from libkcapi:

    kcapi-rng -b 9000000 &gt; OUTFILE

The generated OUTFILE will have three huge sections that contain all
zeros, and this is caused by the code where the test
'val &amp; PRNG_STATUS_DATA_AVAIL' fails.

Let's fix this issue by ensuring that qcom_rng_read() always returns
with a full buffer if the function returns success. Let's also have
qcom_rng_generate() return the correct value.

Here's some statistics from the ent project
(https://www.fourmilab.ch/random/) that shows information about the
quality of the generated numbers:

    $ ent -c qcom-random-before
    Value Char Occurrences Fraction
      0           606748   0.067416
      1            33104   0.003678
      2            33001   0.003667
    ...
    253   �        32883   0.003654
    254   �        33035   0.003671
    255   �        33239   0.003693

    Total:       9000000   1.000000

    Entropy = 7.811590 bits per byte.

    Optimum compression would reduce the size
    of this 9000000 byte file by 2 percent.

    Chi square distribution for 9000000 samples is 9329962.81, and
    randomly would exceed this value less than 0.01 percent of the
    times.

    Arithmetic mean value of data bytes is 119.3731 (127.5 = random).
    Monte Carlo value for Pi is 3.197293333 (error 1.77 percent).
    Serial correlation coefficient is 0.159130 (totally uncorrelated =
    0.0).

Without this patch, the results of the chi-square test is 0.01%, and
the numbers are certainly not random according to ent's project page.
The results improve with this patch:

    $ ent -c qcom-random-after
    Value Char Occurrences Fraction
      0            35432   0.003937
      1            35127   0.003903
      2            35424   0.003936
    ...
    253   �        35201   0.003911
    254   �        34835   0.003871
    255   �        35368   0.003930

    Total:       9000000   1.000000

    Entropy = 7.999979 bits per byte.

    Optimum compression would reduce the size
    of this 9000000 byte file by 0 percent.

    Chi square distribution for 9000000 samples is 258.77, and randomly
    would exceed this value 42.24 percent of the times.

    Arithmetic mean value of data bytes is 127.5006 (127.5 = random).
    Monte Carlo value for Pi is 3.141277333 (error 0.01 percent).
    Serial correlation coefficient is 0.000468 (totally uncorrelated =
    0.0).

This change was tested on a Nexus 5 phone (msm8974 SoC).</Note>
    </Notes>
    <CVE>CVE-2022-48629</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qcom-rng - fix infinite loop on requests not multiple of WORD_SZ

The commit referenced in the Fixes tag removed the 'break' from the else
branch in qcom_rng_read(), causing an infinite loop whenever 'max' is
not a multiple of WORD_SZ. This can be reproduced e.g. by running:

    kcapi-rng -b 67 &gt;/dev/null

There are many ways to fix this without adding back the 'break', but
they all seem more awkward than simply adding it back, so do just that.

Tested on a machine with Qualcomm Amberwing processor.</Note>
    </Notes>
    <CVE>CVE-2022-48630</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: fix bug in extents parsing when eh_entries == 0 and eh_depth &gt; 0

When walking through an inode extents, the ext4_ext_binsearch_idx() function
assumes that the extent header has been previously validated.  However, there
are no checks that verify that the number of entries (eh-&gt;eh_entries) is
non-zero when depth is &gt; 0.  And this will lead to problems because the
EXT_FIRST_INDEX() and EXT_LAST_INDEX() will return garbage and result in this:

[  135.245946] ------------[ cut here ]------------
[  135.247579] kernel BUG at fs/ext4/extents.c:2258!
[  135.249045] invalid opcode: 0000 [#1] PREEMPT SMP
[  135.250320] CPU: 2 PID: 238 Comm: tmp118 Not tainted 5.19.0-rc8+ #4
[  135.252067] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014
[  135.255065] RIP: 0010:ext4_ext_map_blocks+0xc20/0xcb0
[  135.256475] Code:
[  135.261433] RSP: 0018:ffffc900005939f8 EFLAGS: 00010246
[  135.262847] RAX: 0000000000000024 RBX: ffffc90000593b70 RCX: 0000000000000023
[  135.264765] RDX: ffff8880038e5f10 RSI: 0000000000000003 RDI: ffff8880046e922c
[  135.266670] RBP: ffff8880046e9348 R08: 0000000000000001 R09: ffff888002ca580c
[  135.268576] R10: 0000000000002602 R11: 0000000000000000 R12: 0000000000000024
[  135.270477] R13: 0000000000000000 R14: 0000000000000024 R15: 0000000000000000
[  135.272394] FS:  00007fdabdc56740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000
[  135.274510] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  135.276075] CR2: 00007ffc26bd4f00 CR3: 0000000006261004 CR4: 0000000000170ea0
[  135.277952] Call Trace:
[  135.278635]  &lt;TASK&gt;
[  135.279247]  ? preempt_count_add+0x6d/0xa0
[  135.280358]  ? percpu_counter_add_batch+0x55/0xb0
[  135.281612]  ? _raw_read_unlock+0x18/0x30
[  135.282704]  ext4_map_blocks+0x294/0x5a0
[  135.283745]  ? xa_load+0x6f/0xa0
[  135.284562]  ext4_mpage_readpages+0x3d6/0x770
[  135.285646]  read_pages+0x67/0x1d0
[  135.286492]  ? folio_add_lru+0x51/0x80
[  135.287441]  page_cache_ra_unbounded+0x124/0x170
[  135.288510]  filemap_get_pages+0x23d/0x5a0
[  135.289457]  ? path_openat+0xa72/0xdd0
[  135.290332]  filemap_read+0xbf/0x300
[  135.291158]  ? _raw_spin_lock_irqsave+0x17/0x40
[  135.292192]  new_sync_read+0x103/0x170
[  135.293014]  vfs_read+0x15d/0x180
[  135.293745]  ksys_read+0xa1/0xe0
[  135.294461]  do_syscall_64+0x3c/0x80
[  135.295284]  entry_SYSCALL_64_after_hwframe+0x46/0xb0

This patch simply adds an extra check in __ext4_ext_check(), verifying that
eh_entries is not 0 when eh_depth is &gt; 0.</Note>
    </Notes>
    <CVE>CVE-2022-48631</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bnxt: prevent skb UAF after handing over to PTP worker

When reading the timestamp is required bnxt_tx_int() hands
over the ownership of the completed skb to the PTP worker.
The skb should not be used afterwards, as the worker may
run before the rest of our code and free the skb, leading
to a use-after-free.

Since dev_kfree_skb_any() accepts NULL make the loss of
ownership more obvious and set skb to NULL.</Note>
    </Notes>
    <CVE>CVE-2022-48637</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cgroup: cgroup_get_from_id() must check the looked-up kn is a directory

cgroup has to be one kernfs dir, otherwise kernel panic is caused,
especially cgroup id is provide from userspace.</Note>
    </Notes>
    <CVE>CVE-2022-48638</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sfc: fix TX channel offset when using legacy interrupts

In legacy interrupt mode the tx_channel_offset was hardcoded to 1, but
that's not correct if efx_sepparate_tx_channels is false. In that case,
the offset is 0 because the tx queues are in the single existing channel
at index 0, together with the rx queue.

Without this fix, as soon as you try to send any traffic, it tries to
get the tx queues from an uninitialized channel getting these errors:
  WARNING: CPU: 1 PID: 0 at drivers/net/ethernet/sfc/tx.c:540 efx_hard_start_xmit+0x12e/0x170 [sfc]
  [...]
  RIP: 0010:efx_hard_start_xmit+0x12e/0x170 [sfc]
  [...]
  Call Trace:
   &lt;IRQ&gt;
   dev_hard_start_xmit+0xd7/0x230
   sch_direct_xmit+0x9f/0x360
   __dev_queue_xmit+0x890/0xa40
  [...]
  BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
  [...]
  RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc]
  [...]
  Call Trace:
   &lt;IRQ&gt;
   dev_hard_start_xmit+0xd7/0x230
   sch_direct_xmit+0x9f/0x360
   __dev_queue_xmit+0x890/0xa40
  [...]</Note>
    </Notes>
    <CVE>CVE-2022-48647</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sfc: fix null pointer dereference in efx_hard_start_xmit

Trying to get the channel from the tx_queue variable here is wrong
because we can only be here if tx_queue is NULL, so we shouldn't
dereference it. As the above comment in the code says, this is very
unlikely to happen, but it's wrong anyway so let's fix it.

I hit this issue because of a different bug that caused tx_queue to be
NULL. If that happens, this is the error message that we get here:
  BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
  [...]
  RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc]</Note>
    </Notes>
    <CVE>CVE-2022-48648</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 memory leak in __qlt_24xx_handle_abts()

Commit 8f394da36a36 ("scsi: qla2xxx: Drop TARGET_SCF_LOOKUP_LUN_FROM_TAG")
made the __qlt_24xx_handle_abts() function return early if
tcm_qla2xxx_find_cmd_by_tag() didn't find a command, but it missed to clean
up the allocated memory for the management command.</Note>
    </Notes>
    <CVE>CVE-2022-48650</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipvlan: Fix out-of-bound bugs caused by unset skb-&gt;mac_header

If an AF_PACKET socket is used to send packets through ipvlan and the
default xmit function of the AF_PACKET socket is changed from
dev_queue_xmit() to packet_direct_xmit() via setsockopt() with the option
name of PACKET_QDISC_BYPASS, the skb-&gt;mac_header may not be reset and
remains as the initial value of 65535, this may trigger slab-out-of-bounds
bugs as following:

=================================================================
UG: KASAN: slab-out-of-bounds in ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan]
PU: 2 PID: 1768 Comm: raw_send Kdump: loaded Not tainted 6.0.0-rc4+ #6
ardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33
all Trace:
print_address_description.constprop.0+0x1d/0x160
print_report.cold+0x4f/0x112
kasan_report+0xa3/0x130
ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan]
ipvlan_start_xmit+0x29/0xa0 [ipvlan]
__dev_direct_xmit+0x2e2/0x380
packet_direct_xmit+0x22/0x60
packet_snd+0x7c9/0xc40
sock_sendmsg+0x9a/0xa0
__sys_sendto+0x18a/0x230
__x64_sys_sendto+0x74/0x90
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd

The root cause is:
  1. packet_snd() only reset skb-&gt;mac_header when sock-&gt;type is SOCK_RAW
     and skb-&gt;protocol is not specified as in packet_parse_headers()

  2. packet_direct_xmit() doesn't reset skb-&gt;mac_header as dev_queue_xmit()

In this case, skb-&gt;mac_header is 65535 when ipvlan_xmit_mode_l2() is
called. So when ipvlan_xmit_mode_l2() gets mac header with eth_hdr() which
use "skb-&gt;head + skb-&gt;mac_header", out-of-bound access occurs.

This patch replaces eth_hdr() with skb_eth_hdr() in ipvlan_xmit_mode_l2()
and reset mac header in multicast to solve this out-of-bound bug.</Note>
    </Notes>
    <CVE>CVE-2022-48651</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:

ice: Don't double unplug aux on peer initiated reset

In the IDC callback that is accessed when the aux drivers request a reset,
the function to unplug the aux devices is called.  This function is also
called in the ice_prepare_for_reset function. This double call is causing
a "scheduling while atomic" BUG.

[  662.676430] ice 0000:4c:00.0 rocep76s0: cqp opcode = 0x1 maj_err_code = 0xffff min_err_code = 0x8003

[  662.676609] ice 0000:4c:00.0 rocep76s0: [Modify QP Cmd Error][op_code=8] status=-29 waiting=1 completion_err=1 maj=0xffff min=0x8003

[  662.815006] ice 0000:4c:00.0 rocep76s0: ICE OICR event notification: oicr = 0x10000003

[  662.815014] ice 0000:4c:00.0 rocep76s0: critical PE Error, GLPE_CRITERR=0x00011424

[  662.815017] ice 0000:4c:00.0 rocep76s0: Requesting a reset

[  662.815475] BUG: scheduling while atomic: swapper/37/0/0x00010002

[  662.815475] BUG: scheduling while atomic: swapper/37/0/0x00010002
[  662.815477] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs rfkill 8021q garp mrp stp llc vfat fat rpcrdma intel_rapl_msr intel_rapl_common sunrpc i10nm_edac rdma_ucm nfit ib_srpt libnvdimm ib_isert iscsi_target_mod x86_pkg_temp_thermal intel_powerclamp coretemp target_core_mod snd_hda_intel ib_iser snd_intel_dspcfg libiscsi snd_intel_sdw_acpi scsi_transport_iscsi kvm_intel iTCO_wdt rdma_cm snd_hda_codec kvm iw_cm ipmi_ssif iTCO_vendor_support snd_hda_core irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hwdep snd_seq snd_seq_device rapl snd_pcm snd_timer isst_if_mbox_pci pcspkr isst_if_mmio irdma intel_uncore idxd acpi_ipmi joydev isst_if_common snd mei_me idxd_bus ipmi_si soundcore i2c_i801 mei ipmi_devintf i2c_smbus i2c_ismt ipmi_msghandler acpi_power_meter acpi_pad rv(OE) ib_uverbs ib_cm ib_core xfs libcrc32c ast i2c_algo_bit drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm_ttm_helpe
 r ttm
[  662.815546]  nvme nvme_core ice drm crc32c_intel i40e t10_pi wmi pinctrl_emmitsburg dm_mirror dm_region_hash dm_log dm_mod fuse
[  662.815557] Preemption disabled at:
[  662.815558] [&lt;0000000000000000&gt;] 0x0
[  662.815563] CPU: 37 PID: 0 Comm: swapper/37 Kdump: loaded Tainted: G S         OE     5.17.1 #2
[  662.815566] Hardware name: Intel Corporation D50DNP/D50DNP, BIOS SE5C6301.86B.6624.D18.2111021741 11/02/2021
[  662.815568] Call Trace:
[  662.815572]  &lt;IRQ&gt;
[  662.815574]  dump_stack_lvl+0x33/0x42
[  662.815581]  __schedule_bug.cold.147+0x7d/0x8a
[  662.815588]  __schedule+0x798/0x990
[  662.815595]  schedule+0x44/0xc0
[  662.815597]  schedule_preempt_disabled+0x14/0x20
[  662.815600]  __mutex_lock.isra.11+0x46c/0x490
[  662.815603]  ? __ibdev_printk+0x76/0xc0 [ib_core]
[  662.815633]  device_del+0x37/0x3d0
[  662.815639]  ice_unplug_aux_dev+0x1a/0x40 [ice]
[  662.815674]  ice_schedule_reset+0x3c/0xd0 [ice]
[  662.815693]  irdma_iidc_event_handler.cold.7+0xb6/0xd3 [irdma]
[  662.815712]  ? bitmap_find_next_zero_area_off+0x45/0xa0
[  662.815719]  ice_send_event_to_aux+0x54/0x70 [ice]
[  662.815741]  ice_misc_intr+0x21d/0x2d0 [ice]
[  662.815756]  __handle_irq_event_percpu+0x4c/0x180
[  662.815762]  handle_irq_event_percpu+0xf/0x40
[  662.815764]  handle_irq_event+0x34/0x60
[  662.815766]  handle_edge_irq+0x9a/0x1c0
[  662.815770]  __common_interrupt+0x62/0x100
[  662.815774]  common_interrupt+0xb4/0xd0
[  662.815779]  &lt;/IRQ&gt;
[  662.815780]  &lt;TASK&gt;
[  662.815780]  asm_common_interrupt+0x1e/0x40
[  662.815785] RIP: 0010:cpuidle_enter_state+0xd6/0x380
[  662.815789] Code: 49 89 c4 0f 1f 44 00 00 31 ff e8 65 d7 95 ff 45 84 ff 74 12 9c 58 f6 c4 02 0f 85 64 02 00 00 31 ff e8 ae c5 9c ff fb 45 85 f6 &lt;0f&gt; 88 12 01 00 00 49 63 d6 4c 2b 24 24 48 8d 04 52 48 8d 04 82 49
[  662.815791] RSP: 0018:ff2c2c4f18edbe80 EFLAGS: 00000202
[  662.815793] RAX: ff280805df140000 RBX: 0000000000000002 RCX: 000000000000001f
[  662.815795] RDX: 0000009a52da2d08 R
---truncated---</Note>
    </Notes>
    <CVE>CVE-2022-48653</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nfnetlink_osf: fix possible bogus match in nf_osf_find()

nf_osf_find() incorrectly returns true on mismatch, this leads to
copying uninitialized memory area in nft_osf which can be used to leak
stale kernel stack data to userspace.</Note>
    </Notes>
    <CVE>CVE-2022-48654</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

firmware: arm_scmi: Harden accesses to the reset domains

Accessing reset domains descriptors by the index upon the SCMI drivers
requests through the SCMI reset operations interface can potentially
lead to out-of-bound violations if the SCMI driver misbehave.

Add an internal consistency check before any such domains descriptors
accesses.</Note>
    </Notes>
    <CVE>CVE-2022-48655</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dmaengine: ti: k3-udma-private: Fix refcount leak bug in of_xudma_dev_get()

We should call of_node_put() for the reference returned by
of_parse_phandle() in fail path or when it is not used anymore.
Here we only need to move the of_node_put() before the check.</Note>
    </Notes>
    <CVE>CVE-2022-48656</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

arm64: topology: fix possible overflow in amu_fie_setup()

cpufreq_get_hw_max_freq() returns max frequency in kHz as *unsigned int*,
while freq_inv_set_max_ratio() gets passed this frequency in Hz as 'u64'.
Multiplying max frequency by 1000 can potentially result in overflow --
multiplying by 1000ULL instead should avoid that...

Found by Linux Verification Center (linuxtesting.org) with the SVACE static
analysis tool.</Note>
    </Notes>
    <CVE>CVE-2022-48657</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gpiolib: cdev: Set lineevent_state::irq after IRQ register successfully

When running gpio test on nxp-ls1028 platform with below command
gpiomon --num-events=3 --rising-edge gpiochip1 25
There will be a warning trace as below:
Call trace:
free_irq+0x204/0x360
lineevent_free+0x64/0x70
gpio_ioctl+0x598/0x6a0
__arm64_sys_ioctl+0xb4/0x100
invoke_syscall+0x5c/0x130
......
el0t_64_sync+0x1a0/0x1a4
The reason of this issue is that calling request_threaded_irq()
function failed, and then lineevent_free() is invoked to release
the resource. Since the lineevent_state::irq was already set, so
the subsequent invocation of free_irq() would trigger the above
warning call trace. To fix this issue, set the lineevent_state::irq
after the IRQ register successfully.</Note>
    </Notes>
    <CVE>CVE-2022-48660</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/i915/gem: Really move i915_gem_context.link under ref protection

i915_perf assumes that it can use the i915_gem_context reference to
protect its i915-&gt;gem.contexts.list iteration. However, this requires
that we do not remove the context from the list until after we drop the
final reference and release the struct. If, as currently, we remove the
context from the list during context_close(), the link.next pointer may
be poisoned while we are holding the context reference and cause a GPF:

[ 4070.573157] i915 0000:00:02.0: [drm:i915_perf_open_ioctl [i915]] filtering on ctx_id=0x1fffff ctx_id_mask=0x1fffff
[ 4070.574881] general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP
[ 4070.574897] CPU: 1 PID: 284392 Comm: amd_performance Tainted: G            E     5.17.9 #180
[ 4070.574903] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017
[ 4070.574907] RIP: 0010:oa_configure_all_contexts.isra.0+0x222/0x350 [i915]
[ 4070.574982] Code: 08 e8 32 6e 10 e1 4d 8b 6d 50 b8 ff ff ff ff 49 83 ed 50 f0 41 0f c1 04 24 83 f8 01 0f 84 e3 00 00 00 85 c0 0f 8e fa 00 00 00 &lt;49&gt; 8b 45 50 48 8d 70 b0 49 8d 45 50 48 39 44 24 10 0f 85 34 fe ff
[ 4070.574990] RSP: 0018:ffffc90002077b78 EFLAGS: 00010202
[ 4070.574995] RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000000
[ 4070.575000] RDX: 0000000000000001 RSI: ffffc90002077b20 RDI: ffff88810ddc7c68
[ 4070.575004] RBP: 0000000000000001 R08: ffff888103242648 R09: fffffffffffffffc
[ 4070.575008] R10: ffffffff82c50bc0 R11: 0000000000025c80 R12: ffff888101bf1860
[ 4070.575012] R13: dead0000000000b0 R14: ffffc90002077c04 R15: ffff88810be5cabc
[ 4070.575016] FS:  00007f1ed50c0780(0000) GS:ffff88885ec80000(0000) knlGS:0000000000000000
[ 4070.575021] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4070.575025] CR2: 00007f1ed5590280 CR3: 000000010ef6f005 CR4: 00000000003706e0
[ 4070.575029] Call Trace:
[ 4070.575033]  &lt;TASK&gt;
[ 4070.575037]  lrc_configure_all_contexts+0x13e/0x150 [i915]
[ 4070.575103]  gen8_enable_metric_set+0x4d/0x90 [i915]
[ 4070.575164]  i915_perf_open_ioctl+0xbc0/0x1500 [i915]
[ 4070.575224]  ? asm_common_interrupt+0x1e/0x40
[ 4070.575232]  ? i915_oa_init_reg_state+0x110/0x110 [i915]
[ 4070.575290]  drm_ioctl_kernel+0x85/0x110
[ 4070.575296]  ? update_load_avg+0x5f/0x5e0
[ 4070.575302]  drm_ioctl+0x1d3/0x370
[ 4070.575307]  ? i915_oa_init_reg_state+0x110/0x110 [i915]
[ 4070.575382]  ? gen8_gt_irq_handler+0x46/0x130 [i915]
[ 4070.575445]  __x64_sys_ioctl+0x3c4/0x8d0
[ 4070.575451]  ? __do_softirq+0xaa/0x1d2
[ 4070.575456]  do_syscall_64+0x35/0x80
[ 4070.575461]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 4070.575467] RIP: 0033:0x7f1ed5c10397
[ 4070.575471] Code: 3c 1c e8 1c ff ff ff 85 c0 79 87 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d a9 da 0d 00 f7 d8 64 89 01 48
[ 4070.575478] RSP: 002b:00007ffd65c8d7a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 4070.575484] RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 00007f1ed5c10397
[ 4070.575488] RDX: 00007ffd65c8d7c0 RSI: 0000000040106476 RDI: 0000000000000006
[ 4070.575492] RBP: 00005620972f9c60 R08: 000000000000000a R09: 0000000000000005
[ 4070.575496] R10: 000000000000000d R11: 0000000000000246 R12: 000000000000000a
[ 4070.575500] R13: 000000000000000d R14: 0000000000000000 R15: 00007ffd65c8d7c0
[ 4070.575505]  &lt;/TASK&gt;
[ 4070.575507] Modules linked in: nls_ascii(E) nls_cp437(E) vfat(E) fat(E) i915(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) aesni_intel(E) crypto_simd(E) intel_gtt(E) cryptd(E) ttm(E) rapl(E) intel_cstate(E) drm_kms_helper(E) cfbfillrect(E) syscopyarea(E) cfbimgblt(E) intel_uncore(E) sysfillrect(E) mei_me(E) sysimgblt(E) i2c_i801(E) fb_sys_fops(E) mei(E) intel_pch_thermal(E) i2c_smbus
---truncated---</Note>
    </Notes>
    <CVE>CVE-2022-48662</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:

gpio: mockup: fix NULL pointer dereference when removing debugfs

We now remove the device's debugfs entries when unbinding the driver.
This now causes a NULL-pointer dereference on module exit because the
platform devices are unregistered *after* the global debugfs directory
has been recursively removed. Fix it by unregistering the devices first.</Note>
    </Notes>
    <CVE>CVE-2022-48663</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

smb3: fix temporary data corruption in insert range

insert range doesn't discard the affected cached region
so can risk temporarily corrupting file data.

Also includes some minor cleanup (avoiding rereading
inode size repeatedly unnecessarily) to make it clearer.</Note>
    </Notes>
    <CVE>CVE-2022-48667</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

smb3: fix temporary data corruption in collapse range

collapse range doesn't discard the affected cached region
so can risk temporarily corrupting the file data. This
fixes xfstest generic/031

I also decided to merge a minor cleanup to this into the same patch
(avoiding rereading inode size repeatedly unnecessarily) to make it
clearer.</Note>
    </Notes>
    <CVE>CVE-2022-48668</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 deadlock flaw was found in the Linux kernel's BPF subsystem. This flaw allows a local user to potentially crash the system.</Note>
    </Notes>
    <CVE>CVE-2023-0160</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Information exposure through microarchitectural state after transient execution from some register files for some Intel(R) Atom(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.</Note>
    </Notes>
    <CVE>CVE-2023-28746</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An issue was discovered in the Linux kernel through 6.3.8. A use-after-free was found in ravb_remove in drivers/net/ethernet/renesas/ravb_main.c.</Note>
    </Notes>
    <CVE>CVE-2023-35827</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 Avahi, where a reachable assertion exists in avahi_dns_packet_append_record.</Note>
    </Notes>
    <CVE>CVE-2023-38469</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 Avahi. A reachable assertion exists in the dbus_set_host_name function.</Note>
    </Notes>
    <CVE>CVE-2023-38471</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Faulty input validation in the core of Apache allows malicious or exploitable backend/content generators to split HTTP responses.

This issue affects Apache HTTP Server: through 2.4.58.
</Note>
    </Notes>
    <CVE>CVE-2023-38709</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.</Note>
    </Notes>
    <CVE>CVE-2023-45918</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">Recent x86 CPUs offer functionality named Control-flow Enforcement
Technology (CET).  A sub-feature of this are Shadow Stacks (CET-SS).
CET-SS is a hardware feature designed to protect against Return Oriented
Programming attacks. When enabled, traditional stacks holding both data
and return addresses are accompanied by so called "shadow stacks",
holding little more than return addresses.  Shadow stacks aren't
writable by normal instructions, and upon function returns their
contents are used to check for possible manipulation of a return address
coming from the traditional stack.

In particular certain memory accesses need intercepting by Xen.  In
various cases the necessary emulation involves kind of replaying of
the instruction.  Such replaying typically involves filling and then
invoking of a stub.  Such a replayed instruction may raise an
exceptions, which is expected and dealt with accordingly.

Unfortunately the interaction of both of the above wasn't right:
Recovery involves removal of a call frame from the (traditional) stack.
The counterpart of this operation for the shadow stack was missing.
</Note>
    </Notes>
    <CVE>CVE-2023-46841</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Unlike 32-bit PV guests, HVM guests may switch freely between 64-bit and
other modes.  This in particular means that they may set registers used
to pass 32-bit-mode hypercall arguments to values outside of the range
32-bit code would be able to set them to.

When processing of hypercalls takes a considerable amount of time,
the hypervisor may choose to invoke a hypercall continuation.  Doing so
involves putting (perhaps updated) hypercall arguments in respective
registers.  For guests not running in 64-bit mode this further involves
a certain amount of translation of the values.

Unfortunately internal sanity checking of these translated values
assumes high halves of registers to always be clear when invoking a
hypercall.  When this is found not to be the case, it triggers a
consistency check in the hypervisor and causes a crash.
</Note>
    </Notes>
    <CVE>CVE-2023-46842</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">** REJECT ** CVE-2023-4881 was wrongly assigned to a bug that was deemed to be a non-security issue by the Linux kernel security team.</Note>
    </Notes>
    <CVE>CVE-2023-4881</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">libexpat through 2.5.0 allows a denial of service (resource consumption) because many full reparsings are required in the case of a large token for which multiple buffer fills are needed.</Note>
    </Notes>
    <CVE>CVE-2023-52425</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Defer the free of inner map when necessary

When updating or deleting an inner map in map array or map htab, the map
may still be accessed by non-sleepable program or sleepable program.
However bpf_map_fd_put_ptr() decreases the ref-counter of the inner map
directly through bpf_map_put(), if the ref-counter is the last one
(which is true for most cases), the inner map will be freed by
ops-&gt;map_free() in a kworker. But for now, most .map_free() callbacks
don't use synchronize_rcu() or its variants to wait for the elapse of a
RCU grace period, so after the invocation of ops-&gt;map_free completes,
the bpf program which is accessing the inner map may incur
use-after-free problem.

Fix the free of inner map by invoking bpf_map_free_deferred() after both
one RCU grace period and one tasks trace RCU grace period if the inner
map has been removed from the outer map before. The deferment is
accomplished by using call_rcu() or call_rcu_tasks_trace() when
releasing the last ref-counter of bpf map. The newly-added rcu_head
field in bpf_map shares the same storage space with work field to
reduce the size of bpf_map.</Note>
    </Notes>
    <CVE>CVE-2023-52447</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

perf/x86/intel/uncore: Fix NULL pointer dereference issue in upi_fill_topology()

Get logical socket id instead of physical id in discover_upi_topology()
to avoid out-of-bound access on 'upi = &amp;type-&gt;topology[nid][idx];' line
that leads to NULL pointer dereference in upi_fill_topology()</Note>
    </Notes>
    <CVE>CVE-2023-52450</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/amd/pm: fix a use-after-free in kv_parse_power_table

When ps allocated by kzalloc equals to NULL, kv_parse_power_table
frees adev-&gt;pm.dpm.ps that allocated before. However, after the control
flow goes through the following call chains:

kv_parse_power_table
  |-&gt; kv_dpm_init
        |-&gt; kv_dpm_sw_init
	      |-&gt; kv_dpm_fini

The adev-&gt;pm.dpm.ps is used in the for loop of kv_dpm_fini after its
first free in kv_parse_power_table and causes a use-after-free bug.</Note>
    </Notes>
    <CVE>CVE-2023-52469</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/radeon: check the alloc_workqueue return value in radeon_crtc_init()

check the alloc_workqueue return value in radeon_crtc_init()
to avoid null-ptr-deref.</Note>
    </Notes>
    <CVE>CVE-2023-52470</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

IB/hfi1: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requests

hfi1 user SDMA request processing has two bugs that can cause data
corruption for user SDMA requests that have multiple payload iovecs
where an iovec other than the tail iovec does not run up to the page
boundary for the buffer pointed to by that iovec.a

Here are the specific bugs:
1. user_sdma_txadd() does not use struct user_sdma_iovec-&gt;iov.iov_len.
   Rather, user_sdma_txadd() will add up to PAGE_SIZE bytes from iovec
   to the packet, even if some of those bytes are past
   iovec-&gt;iov.iov_len and are thus not intended to be in the packet.
2. user_sdma_txadd() and user_sdma_send_pkts() fail to advance to the
   next iovec in user_sdma_request-&gt;iovs when the current iovec
   is not PAGE_SIZE and does not contain enough data to complete the
   packet. The transmitted packet will contain the wrong data from the
   iovec pages.

This has not been an issue with SDMA packets from hfi1 Verbs or PSM2
because they only produce iovecs that end short of PAGE_SIZE as the tail
iovec of an SDMA request.

Fixing these bugs exposes other bugs with the SDMA pin cache
(struct mmu_rb_handler) that get in way of supporting user SDMA requests
with multiple payload iovecs whose buffers do not end at PAGE_SIZE. So
this commit fixes those issues as well.

Here are the mmu_rb_handler bugs that non-PAGE_SIZE-end multi-iovec
payload user SDMA requests can hit:
1. Overlapping memory ranges in mmu_rb_handler will result in duplicate
   pinnings.
2. When extending an existing mmu_rb_handler entry (struct mmu_rb_node),
   the mmu_rb code (1) removes the existing entry under a lock, (2)
   releases that lock, pins the new pages, (3) then reacquires the lock
   to insert the extended mmu_rb_node.

   If someone else comes in and inserts an overlapping entry between (2)
   and (3), insert in (3) will fail.

   The failure path code in this case unpins _all_ pages in either the
   original mmu_rb_node or the new mmu_rb_node that was inserted between
   (2) and (3).
3. In hfi1_mmu_rb_remove_unless_exact(), mmu_rb_node-&gt;refcount is
   incremented outside of mmu_rb_handler-&gt;lock. As a result, mmu_rb_node
   could be evicted by another thread that gets mmu_rb_handler-&gt;lock and
   checks mmu_rb_node-&gt;refcount before mmu_rb_node-&gt;refcount is
   incremented.
4. Related to #2 above, SDMA request submission failure path does not
   check mmu_rb_node-&gt;refcount before freeing mmu_rb_node object.

   If there are other SDMA requests in progress whose iovecs have
   pointers to the now-freed mmu_rb_node(s), those pointers to the
   now-freed mmu_rb nodes will be dereferenced when those SDMA requests
   complete.</Note>
    </Notes>
    <CVE>CVE-2023-52474</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

perf/x86/lbr: Filter vsyscall addresses

We found that a panic can occur when a vsyscall is made while LBR sampling
is active. If the vsyscall is interrupted (NMI) for perf sampling, this
call sequence can occur (most recent at top):

    __insn_get_emulate_prefix()
    insn_get_emulate_prefix()
    insn_get_prefixes()
    insn_get_opcode()
    decode_branch_type()
    get_branch_type()
    intel_pmu_lbr_filter()
    intel_pmu_handle_irq()
    perf_event_nmi_handler()

Within __insn_get_emulate_prefix() at frame 0, a macro is called:

    peek_nbyte_next(insn_byte_t, insn, i)

Within this macro, this dereference occurs:

    (insn)-&gt;next_byte

Inspecting registers at this point, the value of the next_byte field is the
address of the vsyscall made, for example the location of the vsyscall
version of gettimeofday() at 0xffffffffff600000. The access to an address
in the vsyscall region will trigger an oops due to an unhandled page fault.

To fix the bug, filtering for vsyscalls can be done when
determining the branch type. This patch will return
a "none" branch if a kernel address if found to lie in the
vsyscall region.</Note>
    </Notes>
    <CVE>CVE-2023-52476</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: hub: Guard against accesses to uninitialized BOS descriptors

Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h
access fields inside udev-&gt;bos without checking if it was allocated and
initialized. If usb_get_bos_descriptor() fails for whatever
reason, udev-&gt;bos will be NULL and those accesses will result in a
crash:

BUG: kernel NULL pointer dereference, address: 0000000000000018
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 &lt;HASH:1f9e 1&gt;
Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021
Workqueue: usb_hub_wq hub_event
RIP: 0010:hub_port_reset+0x193/0x788
Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 &lt;48&gt; 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9
RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310
RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840
RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0
Call Trace:
hub_event+0x73f/0x156e
? hub_activate+0x5b7/0x68f
process_one_work+0x1a2/0x487
worker_thread+0x11a/0x288
kthread+0x13a/0x152
? process_one_work+0x487/0x487
? kthread_associate_blkcg+0x70/0x70
ret_from_fork+0x1f/0x30

Fall back to a default behavior if the BOS descriptor isn't accessible
and skip all the functionalities that depend on it: LPM support checks,
Super Speed capabilitiy checks, U1/U2 states setup.</Note>
    </Notes>
    <CVE>CVE-2023-52477</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dmaengine: fix NULL pointer in channel unregistration function

__dma_async_device_channel_register() can fail. In case of failure,
chan-&gt;local is freed (with free_percpu()), and chan-&gt;local is nullified.
When dma_async_device_unregister() is called (because of managed API or
intentionally by DMA controller driver), channels are unconditionally
unregistered, leading to this NULL pointer:
[    1.318693] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0
[...]
[    1.484499] Call trace:
[    1.486930]  device_del+0x40/0x394
[    1.490314]  device_unregister+0x20/0x7c
[    1.494220]  __dma_async_device_channel_unregister+0x68/0xc0

Look at dma_async_device_register() function error path, channel device
unregistration is done only if chan-&gt;local is not NULL.

Then add the same condition at the beginning of
__dma_async_device_channel_unregister() function, to avoid NULL pointer
issue whatever the API used to reach this function.</Note>
    </Notes>
    <CVE>CVE-2023-52492</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

erofs: fix lz4 inplace decompression

Currently EROFS can map another compressed buffer for inplace
decompression, that was used to handle the cases that some pages of
compressed data are actually not in-place I/O.

However, like most simple LZ77 algorithms, LZ4 expects the compressed
data is arranged at the end of the decompressed buffer and it
explicitly uses memmove() to handle overlapping:
  __________________________________________________________
 |_ direction of decompression --&gt; ____ |_ compressed data _|

Although EROFS arranges compressed data like this, it typically maps two
individual virtual buffers so the relative order is uncertain.
Previously, it was hardly observed since LZ4 only uses memmove() for
short overlapped literals and x86/arm64 memmove implementations seem to
completely cover it up and they don't have this issue.  Juhyung reported
that EROFS data corruption can be found on a new Intel x86 processor.
After some analysis, it seems that recent x86 processors with the new
FSRM feature expose this issue with "rep movsb".

Let's strictly use the decompressed buffer for lz4 inplace
decompression for now.  Later, as an useful improvement, we could try
to tie up these two buffers together in the correct order.</Note>
    </Notes>
    <CVE>CVE-2023-52497</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ring-buffer: Do not attempt to read past "commit"

When iterating over the ring buffer while the ring buffer is active, the
writer can corrupt the reader. There's barriers to help detect this and
handle it, but that code missed the case where the last event was at the
very end of the page and has only 4 bytes left.

The checks to detect the corruption by the writer to reads needs to see the
length of the event. If the length in the first 4 bytes is zero then the
length is stored in the second 4 bytes. But if the writer is in the process
of updating that code, there's a small window where the length in the first
4 bytes could be zero even though the length is only 4 bytes. That will
cause rb_event_length() to read the next 4 bytes which could happen to be off the
allocated page.

To protect against this, fail immediately if the next event pointer is
less than 8 bytes from the end of the commit (last byte of data), as all
events must be a minimum of 8 bytes anyway.</Note>
    </Notes>
    <CVE>CVE-2023-52501</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn()

Sili Luo reported a race in nfc_llcp_sock_get(), leading to UAF.

Getting a reference on the socket found in a lookup while
holding a lock should happen before releasing the lock.

nfc_llcp_sock_get_sn() has a similar problem.

Finally nfc_llcp_recv_snl() needs to make sure the socket
found by nfc_llcp_sock_from_sn() does not disappear.</Note>
    </Notes>
    <CVE>CVE-2023-52502</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

x86/alternatives: Disable KASAN in apply_alternatives()

Fei has reported that KASAN triggers during apply_alternatives() on
a 5-level paging machine:

	BUG: KASAN: out-of-bounds in rcu_is_watching()
	Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0
	...
	__asan_load4()
	rcu_is_watching()
	trace_hardirqs_on()
	text_poke_early()
	apply_alternatives()
	...

On machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57)
gets patched. It includes KASAN code, where KASAN_SHADOW_START depends on
__VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled().

KASAN gets confused when apply_alternatives() patches the
KASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START
static, by replacing __VIRTUAL_MASK_SHIFT with 56, works around the issue.

Fix it for real by disabling KASAN while the kernel is patching alternatives.

[ mingo: updated the changelog ]</Note>
    </Notes>
    <CVE>CVE-2023-52504</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfc: nci: assert requested protocol is valid

The protocol is used in a bit mask to determine if the protocol is
supported. Assert the provided protocol is less than the maximum
defined so it doesn't potentially perform a shift-out-of-bounds and
provide a clearer error for undefined protocols vs unsupported ones.</Note>
    </Notes>
    <CVE>CVE-2023-52507</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nvme-fc: Prevent null pointer dereference in nvme_fc_io_getuuid()

The nvme_fc_fcp_op structure describing an AEN operation is initialized with a
null request structure pointer. An FC LLDD may make a call to
nvme_fc_io_getuuid passing a pointer to an nvmefc_fcp_req for an AEN operation.

Add validation of the request structure pointer before dereference.</Note>
    </Notes>
    <CVE>CVE-2023-52508</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ca8210: Fix a potential UAF in ca8210_probe

If of_clk_add_provider() fails in ca8210_register_ext_clock(),
it calls clk_unregister() to release priv-&gt;clk and returns an
error. However, the caller ca8210_probe() then calls ca8210_remove(),
where priv-&gt;clk is freed again in ca8210_unregister_ext_clock(). In
this case, a use-after-free may happen in the second time we call
clk_unregister().

Fix this by removing the first clk_unregister(). Also, priv-&gt;clk could
be an error code on failure of clk_register_fixed_rate(). Use
IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock().</Note>
    </Notes>
    <CVE>CVE-2023-52510</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

spi: sun6i: reduce DMA RX transfer width to single byte

Through empirical testing it has been determined that sometimes RX SPI
transfers with DMA enabled return corrupted data. This is down to single
or even multiple bytes lost during DMA transfer from SPI peripheral to
memory. It seems the RX FIFO within the SPI peripheral can become
confused when performing bus read accesses wider than a single byte to it
during an active SPI transfer.

This patch reduces the width of individual DMA read accesses to the
RX FIFO to a single byte to mitigate that issue.</Note>
    </Notes>
    <CVE>CVE-2023-52511</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 connection failure handling

In case immediate MPA request processing fails, the newly
created endpoint unlinks the listening endpoint and is
ready to be dropped. This special case was not handled
correctly by the code handling the later TCP socket close,
causing a NULL dereference crash in siw_cm_work_handler()
when dereferencing a NULL listener. We now also cancel
the useless MPA timeout, if immediate MPA request
processing fails.

This patch furthermore simplifies MPA processing in general:
Scheduling a useless TCP socket read in sk_data_ready() upcall
is now surpressed, if the socket is already moved out of
TCP_ESTABLISHED state.</Note>
    </Notes>
    <CVE>CVE-2023-52513</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/srp: Do not call scsi_done() from srp_abort()

After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler
callback, it performs one of the following actions:
* Call scsi_queue_insert().
* Call scsi_finish_command().
* Call scsi_eh_scmd_add().
Hence, SCSI abort handlers must not call scsi_done(). Otherwise all
the above actions would trigger a use-after-free. Hence remove the
scsi_done() call from srp_abort(). Keep the srp_free_req() call
before returning SUCCESS because we may not see the command again if
SUCCESS is returned.</Note>
    </Notes>
    <CVE>CVE-2023-52515</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

spi: sun6i: fix race between DMA RX transfer completion and RX FIFO drain

Previously the transfer complete IRQ immediately drained to RX FIFO to
read any data remaining in FIFO to the RX buffer. This behaviour is
correct when dealing with SPI in interrupt mode. However in DMA mode the
transfer complete interrupt still fires as soon as all bytes to be
transferred have been stored in the FIFO. At that point data in the FIFO
still needs to be picked up by the DMA engine. Thus the drain procedure
and DMA engine end up racing to read from RX FIFO, corrupting any data
read. Additionally the RX buffer pointer is never adjusted according to
DMA progress in DMA mode, thus calling the RX FIFO drain procedure in DMA
mode is a bug.
Fix corruptions in DMA RX mode by draining RX FIFO only in interrupt mode.
Also wait for completion of RX DMA when in DMA mode before returning to
ensure all data has been copied to the supplied memory buffer.</Note>
    </Notes>
    <CVE>CVE-2023-52517</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: intel-ish-hid: ipc: Disable and reenable ACPI GPE bit

The EHL (Elkhart Lake) based platforms provide a OOB (Out of band)
service, which allows to wakup device when the system is in S5 (Soft-Off
state). This OOB service can be enabled/disabled from BIOS settings. When
enabled, the ISH device gets PME wake capability. To enable PME wakeup,
driver also needs to enable ACPI GPE bit.

On resume, BIOS will clear the wakeup bit. So driver need to re-enable it
in resume function to keep the next wakeup capability. But this BIOS
clearing of wakeup bit doesn't decrement internal OS GPE reference count,
so this reenabling on every resume will cause reference count to overflow.

So first disable and reenable ACPI GPE bit using acpi_disable_gpe().</Note>
    </Notes>
    <CVE>CVE-2023-52519</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

platform/x86: think-lmi: Fix reference leak

If a duplicate attribute is found using kset_find_obj(), a reference
to that attribute is returned which needs to be disposed accordingly
using kobject_put(). Move the setting name validation into a separate
function to allow for this change without having to duplicate the
cleanup code for this setting.
As a side note, a very similar bug was fixed in
commit 7295a996fdab ("platform/x86: dell-sysman: Fix reference leak"),
so it seems that the bug was copied from that driver.

Compile-tested only.</Note>
    </Notes>
    <CVE>CVE-2023-52520</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf, sockmap: Reject sk_msg egress redirects to non-TCP sockets

With a SOCKMAP/SOCKHASH map and an sk_msg program user can steer messages
sent from one TCP socket (s1) to actually egress from another TCP
socket (s2):

tcp_bpf_sendmsg(s1)		// = sk_prot-&gt;sendmsg
  tcp_bpf_send_verdict(s1)	// __SK_REDIRECT case
    tcp_bpf_sendmsg_redir(s2)
      tcp_bpf_push_locked(s2)
	tcp_bpf_push(s2)
	  tcp_rate_check_app_limited(s2) // expects tcp_sock
	  tcp_sendmsg_locked(s2)	 // ditto

There is a hard-coded assumption in the call-chain, that the egress
socket (s2) is a TCP socket.

However in commit 122e6c79efe1 ("sock_map: Update sock type checks for
UDP") we have enabled redirects to non-TCP sockets. This was done for the
sake of BPF sk_skb programs. There was no indention to support sk_msg
send-to-egress use case.

As a result, attempts to send-to-egress through a non-TCP socket lead to a
crash due to invalid downcast from sock to tcp_sock:

 BUG: kernel NULL pointer dereference, address: 000000000000002f
 ...
 Call Trace:
  &lt;TASK&gt;
  ? show_regs+0x60/0x70
  ? __die+0x1f/0x70
  ? page_fault_oops+0x80/0x160
  ? do_user_addr_fault+0x2d7/0x800
  ? rcu_is_watching+0x11/0x50
  ? exc_page_fault+0x70/0x1c0
  ? asm_exc_page_fault+0x27/0x30
  ? tcp_tso_segs+0x14/0xa0
  tcp_write_xmit+0x67/0xce0
  __tcp_push_pending_frames+0x32/0xf0
  tcp_push+0x107/0x140
  tcp_sendmsg_locked+0x99f/0xbb0
  tcp_bpf_push+0x19d/0x3a0
  tcp_bpf_sendmsg_redir+0x55/0xd0
  tcp_bpf_send_verdict+0x407/0x550
  tcp_bpf_sendmsg+0x1a1/0x390
  inet_sendmsg+0x6a/0x70
  sock_sendmsg+0x9d/0xc0
  ? sockfd_lookup_light+0x12/0x80
  __sys_sendto+0x10e/0x160
  ? syscall_enter_from_user_mode+0x20/0x60
  ? __this_cpu_preempt_check+0x13/0x20
  ? lockdep_hardirqs_on+0x82/0x110
  __x64_sys_sendto+0x1f/0x30
  do_syscall_64+0x38/0x90
  entry_SYSCALL_64_after_hwframe+0x63/0xcd

Reject selecting a non-TCP sockets as redirect target from a BPF sk_msg
program to prevent the crash. When attempted, user will receive an EACCES
error from send/sendto/sendmsg() syscall.</Note>
    </Notes>
    <CVE>CVE-2023-52523</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: nfc: llcp: Add lock when modifying device list

The device list needs its associated lock held when modifying it, or the
list could become corrupted, as syzbot discovered.</Note>
    </Notes>
    <CVE>CVE-2023-52524</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mwifiex: Fix oob check condition in mwifiex_process_rx_packet

Only skip the code path trying to access the rfc1042 headers when the
buffer is too small, so the driver can still process packets without
rfc1042 headers.</Note>
    </Notes>
    <CVE>CVE-2023-52525</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg

syzbot reported the following uninit-value access issue:

=====================================================
BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]
BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482
CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x21c/0x280 lib/dump_stack.c:118
 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121
 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]
 smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482
 usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737
 usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374
 really_probe+0xf20/0x20b0 drivers/base/dd.c:529
 driver_probe_device+0x293/0x390 drivers/base/dd.c:701
 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807
 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431
 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873
 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920
 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491
 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680
 usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032
 usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241
 usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272
 really_probe+0xf20/0x20b0 drivers/base/dd.c:529
 driver_probe_device+0x293/0x390 drivers/base/dd.c:701
 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807
 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431
 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873
 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920
 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491
 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680
 usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554
 hub_port_connect drivers/usb/core/hub.c:5208 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:5348 [inline]
 port_event drivers/usb/core/hub.c:5494 [inline]
 hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576
 process_one_work+0x1688/0x2140 kernel/workqueue.c:2269
 worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415
 kthread+0x551/0x590 kernel/kthread.c:292
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293

Local variable ----buf.i87@smsc75xx_bind created at:
 __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]
 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]
 smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482
 __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]
 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]
 smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482

This issue is caused because usbnet_read_cmd() reads less bytes than requested
(zero byte in the reproducer). In this case, 'buf' is not properly filled.

This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads
less bytes than requested.</Note>
    </Notes>
    <CVE>CVE-2023-52528</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

HID: sony: Fix a potential memory leak in sony_probe()

If an error occurs after a successful usb_alloc_urb() call, usb_free_urb()
should be called.</Note>
    </Notes>
    <CVE>CVE-2023-52529</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Revert "tty: n_gsm: fix UAF in gsm_cleanup_mux"

This reverts commit 9b9c8195f3f0d74a826077fc1c01b9ee74907239.

The commit above is reverted as it did not solve the original issue.

gsm_cleanup_mux() tries to free up the virtual ttys by calling
gsm_dlci_release() for each available DLCI. There, dlci_put() is called to
decrease the reference counter for the DLCI via tty_port_put() which
finally calls gsm_dlci_free(). This already clears the pointer which is
being checked in gsm_cleanup_mux() before calling gsm_dlci_release().
Therefore, it is not necessary to clear this pointer in gsm_cleanup_mux()
as done in the reverted commit. The commit introduces a null pointer
dereference:
 &lt;TASK&gt;
 ? __die+0x1f/0x70
 ? page_fault_oops+0x156/0x420
 ? search_exception_tables+0x37/0x50
 ? fixup_exception+0x21/0x310
 ? exc_page_fault+0x69/0x150
 ? asm_exc_page_fault+0x26/0x30
 ? tty_port_put+0x19/0xa0
 gsmtty_cleanup+0x29/0x80 [n_gsm]
 release_one_tty+0x37/0xe0
 process_one_work+0x1e6/0x3e0
 worker_thread+0x4c/0x3d0
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xe1/0x110
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x2f/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1b/0x30
 &lt;/TASK&gt;

The actual issue is that nothing guards dlci_put() from being called
multiple times while the tty driver was triggered but did not yet finished
calling gsm_dlci_free().</Note>
    </Notes>
    <CVE>CVE-2023-52564</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix potential use after free in nilfs_gccache_submit_read_data()

In nilfs_gccache_submit_read_data(), brelse(bh) is called to drop the
reference count of bh when the call to nilfs_dat_translate() fails.  If
the reference count hits 0 and its owner page gets unlocked, bh may be
freed.  However, bh-&gt;b_page is dereferenced to put the page after that,
which may result in a use-after-free bug.  This patch moves the release
operation after unlocking and putting the page.

NOTE: The function in question is only called in GC, and in combination
with current userland tools, address translation using DAT does not occur
in that function, so the code path that causes this issue will not be
executed.  However, it is possible to run that code path by intentionally
modifying the userland GC library or by calling the GC ioctl directly.

[konishi.ryusuke@gmail.com: NOTE added to the commit log]</Note>
    </Notes>
    <CVE>CVE-2023-52566</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

serial: 8250_port: Check IRQ data before use

In case the leaf driver wants to use IRQ polling (irq = 0) and
IIR register shows that an interrupt happened in the 8250 hardware
the IRQ data can be NULL. In such a case we need to skip the wake
event as we came to this path from the timer interrupt and quite
likely system is already awake.

Without this fix we have got an Oops:

    serial8250: ttyS0 at I/O 0x3f8 (irq = 0, base_baud = 115200) is a 16550A
    ...
    BUG: kernel NULL pointer dereference, address: 0000000000000010
    RIP: 0010:serial8250_handle_irq+0x7c/0x240
    Call Trace:
     ? serial8250_handle_irq+0x7c/0x240
     ? __pfx_serial8250_timeout+0x10/0x10</Note>
    </Notes>
    <CVE>CVE-2023-52567</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: remove BUG() after failure to insert delayed dir index item

Instead of calling BUG() when we fail to insert a delayed dir index item
into the delayed node's tree, we can just release all the resources we
have allocated/acquired before and return the error to the caller. This is
fine because all existing call chains undo anything they have done before
calling btrfs_insert_delayed_dir_index() or BUG_ON (when creating pending
snapshots in the transaction commit path).

So remove the BUG() call and do proper error handling.

This relates to a syzbot report linked below, but does not fix it because
it only prevents hitting a BUG(), it does not fix the issue where somehow
we attempt to use twice the same index number for different index items.</Note>
    </Notes>
    <CVE>CVE-2023-52569</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

team: fix null-ptr-deref when team device type is changed

Get a null-ptr-deref bug as follows with reproducer [1].

BUG: kernel NULL pointer dereference, address: 0000000000000228
...
RIP: 0010:vlan_dev_hard_header+0x35/0x140 [8021q]
...
Call Trace:
 &lt;TASK&gt;
 ? __die+0x24/0x70
 ? page_fault_oops+0x82/0x150
 ? exc_page_fault+0x69/0x150
 ? asm_exc_page_fault+0x26/0x30
 ? vlan_dev_hard_header+0x35/0x140 [8021q]
 ? vlan_dev_hard_header+0x8e/0x140 [8021q]
 neigh_connected_output+0xb2/0x100
 ip6_finish_output2+0x1cb/0x520
 ? nf_hook_slow+0x43/0xc0
 ? ip6_mtu+0x46/0x80
 ip6_finish_output+0x2a/0xb0
 mld_sendpack+0x18f/0x250
 mld_ifc_work+0x39/0x160
 process_one_work+0x1e6/0x3f0
 worker_thread+0x4d/0x2f0
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xe5/0x120
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x34/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1b/0x30

[1]
$ teamd -t team0 -d -c '{"runner": {"name": "loadbalance"}}'
$ ip link add name t-dummy type dummy
$ ip link add link t-dummy name t-dummy.100 type vlan id 100
$ ip link add name t-nlmon type nlmon
$ ip link set t-nlmon master team0
$ ip link set t-nlmon nomaster
$ ip link set t-dummy up
$ ip link set team0 up
$ ip link set t-dummy.100 down
$ ip link set t-dummy.100 master team0

When enslave a vlan device to team device and team device type is changed
from non-ether to ether, header_ops of team device is changed to
vlan_header_ops. That is incorrect and will trigger null-ptr-deref
for vlan-&gt;real_dev in vlan_dev_hard_header() because team device is not
a vlan device.

Cache eth_header_ops in team_setup(), then assign cached header_ops to
header_ops of team net device when its type is changed from non-ether
to ether to fix the bug.</Note>
    </Notes>
    <CVE>CVE-2023-52574</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">** REJECT ** This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2023-52575</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

x86/mm, kexec, ima: Use memblock_free_late() from ima_free_kexec_buffer()

The code calling ima_free_kexec_buffer() runs long after the memblock
allocator has already been torn down, potentially resulting in a use
after free in memblock_isolate_range().

With KASAN or KFENCE, this use after free will result in a BUG
from the idle task, and a subsequent kernel panic.

Switch ima_free_kexec_buffer() over to memblock_free_late() to avoid
that bug.</Note>
    </Notes>
    <CVE>CVE-2023-52576</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfs: Only call folio_start_fscache() one time for each folio

If a network filesystem using netfs implements a clamp_length()
function, it can set subrequest lengths smaller than a page size.

When we loop through the folios in netfs_rreq_unlock_folios() to
set any folios to be written back, we need to make sure we only
call folio_start_fscache() once for each folio.

Otherwise, this simple testcase:

  mount -o fsc,rsize=1024,wsize=1024 127.0.0.1:/export /mnt/nfs
  dd if=/dev/zero of=/mnt/nfs/file.bin bs=4096 count=1
  1+0 records in
  1+0 records out
  4096 bytes (4.1 kB, 4.0 KiB) copied, 0.0126359 s, 324 kB/s
  echo 3 &gt; /proc/sys/vm/drop_caches
  cat /mnt/nfs/file.bin &gt; /dev/null

will trigger an oops similar to the following:

  page dumped because: VM_BUG_ON_FOLIO(folio_test_private_2(folio))
  ------------[ cut here ]------------
  kernel BUG at include/linux/netfs.h:44!
  ...
  CPU: 5 PID: 134 Comm: kworker/u16:5 Kdump: loaded Not tainted 6.4.0-rc5
  ...
  RIP: 0010:netfs_rreq_unlock_folios+0x68e/0x730 [netfs]
  ...
  Call Trace:
    netfs_rreq_assess+0x497/0x660 [netfs]
    netfs_subreq_terminated+0x32b/0x610 [netfs]
    nfs_netfs_read_completion+0x14e/0x1a0 [nfs]
    nfs_read_completion+0x2f9/0x330 [nfs]
    rpc_free_task+0x72/0xa0 [sunrpc]
    rpc_async_release+0x46/0x70 [sunrpc]
    process_one_work+0x3bd/0x710
    worker_thread+0x89/0x610
    kthread+0x181/0x1c0
    ret_from_fork+0x29/0x50</Note>
    </Notes>
    <CVE>CVE-2023-52582</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix deadlock or deadcode of misusing dget()

The lock order is incorrect between denty and its parent, we should
always make sure that the parent get the lock first.

But since this deadcode is never used and the parent dir will always
be set from the callers, let's just remove it.</Note>
    </Notes>
    <CVE>CVE-2023-52583</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

reiserfs: Avoid touching renamed directory if parent does not change

The VFS will not be locking moved directory if its parent does not
change. Change reiserfs rename code to avoid touching renamed directory
if its parent does not change as without locking that can corrupt the
filesystem.</Note>
    </Notes>
    <CVE>CVE-2023-52591</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:

KVM: s390: fix setting of fpc register

kvm_arch_vcpu_ioctl_set_fpu() allows to set the floating point control
(fpc) register of a guest cpu. The new value is tested for validity by
temporarily loading it into the fpc register.

This may lead to corruption of the fpc register of the host process:
if an interrupt happens while the value is temporarily loaded into the fpc
register, and within interrupt context floating point or vector registers
are used, the current fp/vx registers are saved with save_fpu_regs()
assuming they belong to user space and will be loaded into fp/vx registers
when returning to user space.

test_fp_ctl() restores the original user space / host process fpc register
value, however it will be discarded, when returning to user space.

In result the host process will incorrectly continue to run with the value
that was supposed to be used for a guest cpu.

Fix this by simply removing the test. There is another test right before
the SIE context is entered which will handles invalid values.

This results in a change of behaviour: invalid values will now be accepted
instead of that the ioctl fails with -EINVAL. This seems to be acceptable,
given that this interface is most likely not used anymore, and this is in
addition the same behaviour implemented with the memory mapped interface
(replace invalid values with zero) - see sync_regs() in kvm-s390.c.</Note>
    </Notes>
    <CVE>CVE-2023-52597</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">** REJECT ** This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2023-52605</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/mm: Fix null-pointer dereference in pgtable_cache_add

kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.</Note>
    </Notes>
    <CVE>CVE-2023-52607</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: lib/mpi - Fix unexpected pointer access in mpi_ec_init

When the mpi_ec_ctx structure is initialized, some fields are not
cleared, causing a crash when referencing the field when the
structure was released. Initially, this issue was ignored because
memory for mpi_ec_ctx is allocated with the __GFP_ZERO flag.
For example, this error will be triggered when calculating the
Za value for SM2 separately.</Note>
    </Notes>
    <CVE>CVE-2023-52616</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of service condition or potential code execution.</Note>
    </Notes>
    <CVE>CVE-2023-6270</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver and causing kernel panic and a denial of service.</Note>
    </Notes>
    <CVE>CVE-2023-6356</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver, causing kernel panic and a denial of service.</Note>
    </Notes>
    <CVE>CVE-2023-6535</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 vulnerability was found in ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev() in drivers/net/wireless/ath/ath10k/wmi-tlv.c in the Linux kernel. This issue could be exploited to trigger a denial of service.</Note>
    </Notes>
    <CVE>CVE-2023-7042</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 memory leak problem was found in ctnetlink_create_conntrack in net/netfilter/nf_conntrack_netlink.c in the Linux Kernel. This issue may allow a local attacker with CAP_NET_ADMIN privileges to cause a denial of service (DoS) attack due to a refcount overflow.</Note>
    </Notes>
    <CVE>CVE-2023-7192</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 hugetlbfs_fill_super function in the Linux kernel hugetlbfs (HugeTLB pages) functionality. This issue may allow a local user to crash the system or potentially escalate their privileges on the system.</Note>
    </Notes>
    <CVE>CVE-2024-0841</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 a protocol selection parameter option disables all protocols without adding any then the default set of protocols would remain in the allowed set due to an error in the logic for removing protocols. The below command would perform a request to curl.se with a plaintext protocol which has been explicitly disabled.      curl --proto -all,-http http://curl.se  The flaw is only present if the set of selected protocols disables the entire set of available protocols, in itself a command with no practical use and therefore unlikely to be encountered in real situations. The curl security team has thus assessed this to be low severity bug.</Note>
    </Notes>
    <CVE>CVE-2024-2004</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">A Speculative Race Condition (SRC) vulnerability that impacts modern CPU architectures supporting speculative execution (related to Spectre V1) has been disclosed. An unauthenticated attacker can exploit this vulnerability to disclose arbitrary data from the CPU using race conditions to access the speculative executable code paths.</Note>
    </Notes>
    <CVE>CVE-2024-2193</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 cross-privilege Spectre v2 vulnerability allows attackers to bypass all deployed mitigations, including the recent Fine(IBT), and to leak arbitrary Linux kernel memory on Intel systems.</Note>
    </Notes>
    <CVE>CVE-2024-2201</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">NULL Pointer Dereference vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (net, bluetooth modules) allows Overflow Buffers. This vulnerability is associated with program files /net/bluetooth/rfcomm/core.C.

This issue affects Linux kernel: v2.6.12-rc2.

</Note>
    </Notes>
    <CVE>CVE-2024-22099</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Jinja is an extensible templating engine. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template, potentially leading to Cross-Site Scripting (XSS). The Jinja `xmlattr` filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.
</Note>
    </Notes>
    <CVE>CVE-2024-22195</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Integer Overflow or Wraparound vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (md, raid, raid5 modules) allows Forced Integer Overflow.</Note>
    </Notes>
    <CVE>CVE-2024-23307</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 through 6.7.1, there is a use-after-free in cec_queue_msg_fh, related to drivers/media/cec/core/cec-adap.c and drivers/media/cec/core/cec-api.c.</Note>
    </Notes>
    <CVE>CVE-2024-23848</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In btrfs_get_root_ref in fs/btrfs/disk-io.c in the Linux kernel through 6.7.1, there can be an assertion failure and crash because a subvolume can be read out too soon after its root item is inserted upon subvolume creation.</Note>
    </Notes>
    <CVE>CVE-2024-23850</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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">HTTP Response splitting in multiple modules in Apache HTTP Server allows an attacker that can inject malicious response headers into backend applications to cause an HTTP desynchronization attack.

Users are recommended to upgrade to version 2.4.59, which fixes this issue.</Note>
    </Notes>
    <CVE>CVE-2024-24795</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Issue summary: Some non-default TLS server configurations can cause unbounded
memory growth when processing TLSv1.3 sessions

Impact summary: An attacker may exploit certain server configurations to trigger
unbounded memory growth that would lead to a Denial of Service

This problem can occur in TLSv1.3 if the non-default SSL_OP_NO_TICKET option is
being used (but not if early_data support is also configured and the default
anti-replay protection is in use). In this case, under certain conditions, the
session cache can get into an incorrect state and it will fail to flush properly
as it fills. The session cache will continue to grow in an unbounded manner. A
malicious client could deliberately create the scenario for this failure to
force a Denial of Service. It may also happen by accident in normal operation.

This issue only affects TLS servers supporting TLSv1.3. It does not affect TLS
clients.

The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL
1.0.2 is also not affected by this issue.</Note>
    </Notes>
    <CVE>CVE-2024-2511</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Squid is a web proxy cache. Starting in version 3.5.27 and prior to version 6.8, Squid may be vulnerable to a Denial of Service attack against HTTP Chunked decoder due to an uncontrolled recursion bug. This problem allows a remote attacker to cause Denial of Service when sending a crafted, chunked, encoded HTTP Message. This bug is fixed in Squid version 6.8. In addition, patches addressing this problem for the stable releases can be found in Squid's patch archives. There is no workaround for this issue.</Note>
    </Notes>
    <CVE>CVE-2024-25111</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Squid is an open source caching proxy for the Web supporting HTTP, HTTPS, FTP, and more. Due to a Collapse of Data into Unsafe Value bug ,Squid may be vulnerable to a Denial of Service attack against HTTP header parsing. This problem allows a remote client or a remote server to perform Denial of Service when sending oversized headers in HTTP messages. In versions of Squid prior to 6.5 this can be achieved if the request_header_max_size or reply_header_max_size settings are unchanged from the default. In Squid version 6.5 and later, the default setting of these parameters is safe. Squid will emit a critical warning in cache.log if the administrator is setting these parameters to unsafe values. Squid will not at this time prevent these settings from being changed to unsafe values. Users are advised to upgrade to version 6.5. There are no known workarounds for this vulnerability. This issue is also tracked as SQUID-2024:2 </Note>
    </Notes>
    <CVE>CVE-2024-25617</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">c-ares is a C library for asynchronous DNS requests. `ares__read_line()` is used to parse local configuration files such as `/etc/resolv.conf`, `/etc/nsswitch.conf`, the `HOSTALIASES` file, and if using a c-ares version prior to 1.27.0, the `/etc/hosts` file. If any of these configuration files has an embedded `NULL` character as the first character in a new line, it can lead to attempting to read memory prior to the start of the given buffer which may result in a crash. This issue is fixed in c-ares 1.27.0. No known workarounds exist.</Note>
    </Notes>
    <CVE>CVE-2024-25629</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel before 6.9, an untrusted hypervisor can inject virtual interrupt 29 (#VC) at any point in time and can trigger its handler. This affects AMD SEV-SNP and AMD SEV-ES.</Note>
    </Notes>
    <CVE>CVE-2024-25742</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Kerberos 5 (aka krb5) 1.21.2 contains a memory leak in /krb5/src/lib/rpc/pmap_rmt.c.</Note>
    </Notes>
    <CVE>CVE-2024-26458</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">Kerberos 5 (aka krb5) 1.21.2 contains a memory leak vulnerability in /krb5/src/lib/gssapi/krb5/k5sealv3.c.</Note>
    </Notes>
    <CVE>CVE-2024-26461</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP

If the external phy working together with phy-omap-usb2 does not implement
send_srp(), we may still attempt to call it. This can happen on an idle
Ethernet gadget triggering a wakeup for example:

configfs-gadget.g1 gadget.0: ECM Suspend
configfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup
...
Unable to handle kernel NULL pointer dereference at virtual address
00000000 when execute
...
PC is at 0x0
LR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc]
...
musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core]
usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether]
eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c
dev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4
sch_direct_xmit from __dev_queue_xmit+0x334/0xd88
__dev_queue_xmit from arp_solicit+0xf0/0x268
arp_solicit from neigh_probe+0x54/0x7c
neigh_probe from __neigh_event_send+0x22c/0x47c
__neigh_event_send from neigh_resolve_output+0x14c/0x1c0
neigh_resolve_output from ip_finish_output2+0x1c8/0x628
ip_finish_output2 from ip_send_skb+0x40/0xd8
ip_send_skb from udp_send_skb+0x124/0x340
udp_send_skb from udp_sendmsg+0x780/0x984
udp_sendmsg from __sys_sendto+0xd8/0x158
__sys_sendto from ret_fast_syscall+0x0/0x58

Let's fix the issue by checking for send_srp() and set_vbus() before
calling them. For USB peripheral only cases these both could be NULL.</Note>
    </Notes>
    <CVE>CVE-2024-26600</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: regenerate buddy after block freeing failed if under fc replay

This mostly reverts commit 6bd97bf273bd ("ext4: remove redundant
mb_regenerate_buddy()") and reintroduces mb_regenerate_buddy(). Based on
code in mb_free_blocks(), fast commit replay can end up marking as free
blocks that are already marked as such. This causes corruption of the
buddy bitmap so we need to regenerate it in that case.</Note>
    </Notes>
    <CVE>CVE-2024-26601</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix a memory corruption

iwl_fw_ini_trigger_tlv::data is a pointer to a __le32, which means that
if we copy to iwl_fw_ini_trigger_tlv::data + offset while offset is in
bytes, we'll write past the buffer.</Note>
    </Notes>
    <CVE>CVE-2024-26610</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:

tcp: make sure init the accept_queue's spinlocks once

When I run syz's reproduction C program locally, it causes the following
issue:
pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0!
WARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7
30 20 ce 8f e8 ad 56 42 ff &lt;0f&gt; 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90
RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908
RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900
RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff
R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000
R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000
FS:  00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0
Call Trace:
&lt;IRQ&gt;
  _raw_spin_unlock (kernel/locking/spinlock.c:186)
  inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321)
  inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358)
  tcp_check_req (net/ipv4/tcp_minisocks.c:868)
  tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260)
  ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205)
  ip_local_deliver_finish (net/ipv4/ip_input.c:234)
  __netif_receive_skb_one_core (net/core/dev.c:5529)
  process_backlog (./include/linux/rcupdate.h:779)
  __napi_poll (net/core/dev.c:6533)
  net_rx_action (net/core/dev.c:6604)
  __do_softirq (./arch/x86/include/asm/jump_label.h:27)
  do_softirq (kernel/softirq.c:454 kernel/softirq.c:441)
&lt;/IRQ&gt;
&lt;TASK&gt;
  __local_bh_enable_ip (kernel/softirq.c:381)
  __dev_queue_xmit (net/core/dev.c:4374)
  ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235)
  __ip_queue_xmit (net/ipv4/ip_output.c:535)
  __tcp_transmit_skb (net/ipv4/tcp_output.c:1462)
  tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469)
  tcp_rcv_state_process (net/ipv4/tcp_input.c:6657)
  tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929)
  __release_sock (./include/net/sock.h:1121 net/core/sock.c:2968)
  release_sock (net/core/sock.c:3536)
  inet_wait_for_connect (net/ipv4/af_inet.c:609)
  __inet_stream_connect (net/ipv4/af_inet.c:702)
  inet_stream_connect (net/ipv4/af_inet.c:748)
  __sys_connect (./include/linux/file.h:45 net/socket.c:2064)
  __x64_sys_connect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070)
  do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82)
  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
  RIP: 0033:0x7fa10ff05a3d
  Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89
  c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab a3 0e 00 f7 d8 64 89 01 48
  RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a
  RAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d
  RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003
  RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000202 R12: 00007fa110184640
  R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20
&lt;/TASK&gt;

The issue triggering process is analyzed as follows:
Thread A                                       Thread B
tcp_v4_rcv	//receive ack TCP packet       inet_shutdown
  tcp_check_req                                  tcp_disconnect //disconnect sock
  ...                                              tcp_set_state(sk, TCP_CLOSE)
    inet_csk_complete_hashdance                ...
      inet_csk_reqsk_queue_add         
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-26614</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: disallow anonymous set with timeout flag

Anonymous sets are never used with timeout from userspace, reject this.
Exception to this rule is NFT_SET_EVAL to ensure legacy meters still work.</Note>
    </Notes>
    <CVE>CVE-2024-26642</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/events: close evtchn after mapping cleanup

shutdown_pirq and startup_pirq are not taking the
irq_mapping_update_lock because they can't due to lock inversion. Both
are called with the irq_desc-&gt;lock being taking. The lock order,
however, is first irq_mapping_update_lock and then irq_desc-&gt;lock.

This opens multiple races:
- shutdown_pirq can be interrupted by a function that allocates an event
  channel:

  CPU0                        CPU1
  shutdown_pirq {
    xen_evtchn_close(e)
                              __startup_pirq {
                                EVTCHNOP_bind_pirq
                                  -&gt; returns just freed evtchn e
                                set_evtchn_to_irq(e, irq)
                              }
    xen_irq_info_cleanup() {
      set_evtchn_to_irq(e, -1)
    }
  }

  Assume here event channel e refers here to the same event channel
  number.
  After this race the evtchn_to_irq mapping for e is invalid (-1).

- __startup_pirq races with __unbind_from_irq in a similar way. Because
  __startup_pirq doesn't take irq_mapping_update_lock it can grab the
  evtchn that __unbind_from_irq is currently freeing and cleaning up. In
  this case even though the event channel is allocated, its mapping can
  be unset in evtchn_to_irq.

The fix is to first cleanup the mappings and then close the event
channel. In this way, when an event channel gets allocated it's
potential previous evtchn_to_irq mappings are guaranteed to be unset already.
This is also the reverse order of the allocation where first the event
channel is allocated and then the mappings are setup.

On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal
[un]bind interfaces"), we hit a BUG like the following during probing of NVMe
devices. The issue is that during nvme_setup_io_queues, pci_free_irq
is called for every device which results in a call to shutdown_pirq.
With many nvme devices it's therefore likely to hit this race during
boot because there will be multiple calls to shutdown_pirq and
startup_pirq are running potentially in parallel.

  ------------[ cut here ]------------
  blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled
  kernel BUG at drivers/xen/events/events_base.c:499!
  invalid opcode: 0000 [#1] SMP PTI
  CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1
  Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006
  Workqueue: nvme-reset-wq nvme_reset_work
  RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0
  Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff &lt;0f&gt; 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00
  RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046
  RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006
  RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff
  RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00
  R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed
  R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002
  FS:  0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  Call Trace:
   ? show_trace_log_lvl+0x1c1/0x2d9
   ? show_trace_log_lvl+0x1c1/0x2d9
   ? set_affinity_irq+0xdc/0x1c0
   ? __die_body.cold+0x8/0xd
   ? die+0x2b/0x50
   ? do_trap+0x90/0x110
   ? bind_evtchn_to_cpu+0xdf/0xf0
   ? do_error_trap+0x65/0x80
   ? bind_evtchn_to_cpu+0xdf/0xf0
   ? exc_invalid_op+0x4e/0x70
   ? bind_evtchn_to_cpu+0xdf/0xf0
   ? asm_exc_invalid_op+0x12/0x20
   ? bind_evtchn_to_cpu+0xdf/0x
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-26687</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: prevent use-after-free in encode_cap_msg()

In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error was
caught by KASAN at this line - 'ceph_buffer_get(arg-&gt;xattr_buf);'. This
implies before the refcount could be increment here, it was freed.

In same file, in "handle_cap_grant()" refcount is decremented by this
line - 'ceph_buffer_put(ci-&gt;i_xattrs.blob);'. It appears that a race
occurred and resource was freed by the latter line before the former
line could increment it.

encode_cap_msg() is called by __send_cap() and __send_cap() is called by
ceph_check_caps() after calling __prep_cap(). __prep_cap() is where
arg-&gt;xattr_buf is assigned to ci-&gt;i_xattrs.blob. This is the spot where
the refcount must be increased to prevent "use after free" error.</Note>
    </Notes>
    <CVE>CVE-2024-26689</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: fix double-free of blocks due to wrong extents moved_len

In ext4_move_extents(), moved_len is only updated when all moves are
successfully executed, and only discards orig_inode and donor_inode
preallocations when moved_len is not zero. When the loop fails to exit
after successfully moving some extents, moved_len is not updated and
remains at 0, so it does not discard the preallocations.

If the moved extents overlap with the preallocated extents, the
overlapped extents are freed twice in ext4_mb_release_inode_pa() and
ext4_process_freed_data() (as described in commit 94d7c16cbbbd ("ext4:
Fix double-free of blocks with EXT4_IOC_MOVE_EXT")), and bb_free is
incremented twice. Hence when trim is executed, a zero-division bug is
triggered in mb_update_avg_fragment_size() because bb_free is not zero
and bb_fragments is zero.

Therefore, update move_len after each extent move to avoid the issue.</Note>
    </Notes>
    <CVE>CVE-2024-26704</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

arp: Prevent overflow in arp_req_get().

syzkaller reported an overflown write in arp_req_get(). [0]

When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour
entry and copies neigh-&gt;ha to struct arpreq.arp_ha.sa_data.

The arp_ha here is struct sockaddr, not struct sockaddr_storage, so
the sa_data buffer is just 14 bytes.

In the splat below, 2 bytes are overflown to the next int field,
arp_flags.  We initialise the field just after the memcpy(), so it's
not a problem.

However, when dev-&gt;addr_len is greater than 22 (e.g. MAX_ADDR_LEN),
arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL)
in arp_ioctl() before calling arp_req_get().

To avoid the overflow, let's limit the max length of memcpy().

Note that commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible
array in struct sockaddr") just silenced syzkaller.

[0]:
memcpy: detected field-spanning write (size 16) of single field "r-&gt;arp_ha.sa_data" at net/ipv4/arp.c:1128 (size 14)
WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
Modules linked in:
CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014
RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb &lt;0f&gt; 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6
RSP: 0018:ffffc900050b7998 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001
RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000
R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010
FS:  00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261
 inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981
 sock_do_ioctl+0xdf/0x260 net/socket.c:1204
 sock_ioctl+0x3ef/0x650 net/socket.c:1321
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:870 [inline]
 __se_sys_ioctl fs/ioctl.c:856 [inline]
 __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81
 entry_SYSCALL_64_after_hwframe+0x64/0xce
RIP: 0033:0x7f172b262b8d
Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d
RDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003
RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-26733</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio

If kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the
following kernel warning appears:

WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8
Call trace:
 kiocb_set_cancel_fn+0x9c/0xa8
 ffs_epfile_read_iter+0x144/0x1d0
 io_read+0x19c/0x498
 io_issue_sqe+0x118/0x27c
 io_submit_sqes+0x25c/0x5fc
 __arm64_sys_io_uring_enter+0x104/0xab0
 invoke_syscall+0x58/0x11c
 el0_svc_common+0xb4/0xf4
 do_el0_svc+0x2c/0xb0
 el0_svc+0x2c/0xa4
 el0t_64_sync_handler+0x68/0xb4
 el0t_64_sync+0x1a4/0x1a8

Fix this by setting the IOCB_AIO_RW flag for read and write I/O that is
submitted by libaio.</Note>
    </Notes>
    <CVE>CVE-2024-26764</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

IB/hfi1: Fix sdma.h tx-&gt;num_descs off-by-one error

Unfortunately the commit `fd8958efe877` introduced another error
causing the `descs` array to overflow. This reults in further crashes
easily reproducible by `sendmsg` system call.

[ 1080.836473] general protection fault, probably for non-canonical address 0x400300015528b00a: 0000 [#1] PREEMPT SMP PTI
[ 1080.869326] RIP: 0010:hfi1_ipoib_build_ib_tx_headers.constprop.0+0xe1/0x2b0 [hfi1]
--
[ 1080.974535] Call Trace:
[ 1080.976990]  &lt;TASK&gt;
[ 1081.021929]  hfi1_ipoib_send_dma_common+0x7a/0x2e0 [hfi1]
[ 1081.027364]  hfi1_ipoib_send_dma_list+0x62/0x270 [hfi1]
[ 1081.032633]  hfi1_ipoib_send+0x112/0x300 [hfi1]
[ 1081.042001]  ipoib_start_xmit+0x2a9/0x2d0 [ib_ipoib]
[ 1081.046978]  dev_hard_start_xmit+0xc4/0x210
--
[ 1081.148347]  __sys_sendmsg+0x59/0xa0

crash&gt; ipoib_txreq 0xffff9cfeba229f00
struct ipoib_txreq {
  txreq = {
    list = {
      next = 0xffff9cfeba229f00,
      prev = 0xffff9cfeba229f00
    },
    descp = 0xffff9cfeba229f40,
    coalesce_buf = 0x0,
    wait = 0xffff9cfea4e69a48,
    complete = 0xffffffffc0fe0760 &lt;hfi1_ipoib_sdma_complete&gt;,
    packet_len = 0x46d,
    tlen = 0x0,
    num_desc = 0x0,
    desc_limit = 0x6,
    next_descq_idx = 0x45c,
    coalesce_idx = 0x0,
    flags = 0x0,
    descs = {{
        qw = {0x8024000120dffb00, 0x4}  # SDMA_DESC0_FIRST_DESC_FLAG (bit 63)
      }, {
        qw = {  0x3800014231b108, 0x4}
      }, {
        qw = { 0x310000e4ee0fcf0, 0x8}
      }, {
        qw = {  0x3000012e9f8000, 0x8}
      }, {
        qw = {  0x59000dfb9d0000, 0x8}
      }, {
        qw = {  0x78000e02e40000, 0x8}
      }}
  },
  sdma_hdr =  0x400300015528b000,  &lt;&lt;&lt; invalid pointer in the tx request structure
  sdma_status = 0x0,                   SDMA_DESC0_LAST_DESC_FLAG (bit 62)
  complete = 0x0,
  priv = 0x0,
  txq = 0xffff9cfea4e69880,
  skb = 0xffff9d099809f400
}

If an SDMA send consists of exactly 6 descriptors and requires dword
padding (in the 7th descriptor), the sdma_txreq descriptor array is not
properly expanded and the packet will overflow into the container
structure. This results in a panic when the send completion runs. The
exact panic varies depending on what elements of the container structure
get corrupted. The fix is to use the correct expression in
_pad_sdma_tx_descs() to test the need to expand the descriptor array.

With this patch the crashes are no longer reproducible and the machine is
stable.</Note>
    </Notes>
    <CVE>CVE-2024-26766</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:

ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found()

Determine if the group block bitmap is corrupted before using ac_b_ex in
ext4_mb_try_best_found() to avoid allocating blocks from a group with a
corrupted block bitmap in the following concurrency and making the
situation worse.

ext4_mb_regular_allocator
  ext4_lock_group(sb, group)
  ext4_mb_good_group
   // check if the group bbitmap is corrupted
  ext4_mb_complex_scan_group
   // Scan group gets ac_b_ex but doesn't use it
  ext4_unlock_group(sb, group)
                           ext4_mark_group_bitmap_corrupted(group)
                           // The block bitmap was corrupted during
                           // the group unlock gap.
  ext4_mb_try_best_found
    ext4_lock_group(ac-&gt;ac_sb, group)
    ext4_mb_use_best_found
      mb_mark_used
      // Allocating blocks in block bitmap corrupted group</Note>
    </Notes>
    <CVE>CVE-2024-26773</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

x86, relocs: Ignore relocations in .notes section

When building with CONFIG_XEN_PV=y, .text symbols are emitted into
the .notes section so that Xen can find the "startup_xen" entry point.
This information is used prior to booting the kernel, so relocations
are not useful. In fact, performing relocations against the .notes
section means that the KASLR base is exposed since /sys/kernel/notes
is world-readable.

To avoid leaking the KASLR base without breaking unprivileged tools that
are expecting to read /sys/kernel/notes, skip performing relocations in
the .notes section. The values readable in .notes are then identical to
those found in System.map.</Note>
    </Notes>
    <CVE>CVE-2024-26816</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: edia: dvbdev: fix a use-after-free

In dvb_register_device, *pdvbdev is set equal to dvbdev, which is freed
in several error-handling paths. However, *pdvbdev is not set to NULL
after dvbdev's deallocation, causing use-after-frees in many places,
for example, in the following call chain:

budget_register
  |-&gt; dvb_dmxdev_init
        |-&gt; dvb_register_device
  |-&gt; dvb_dmxdev_release
        |-&gt; dvb_unregister_device
              |-&gt; dvb_remove_device
                    |-&gt; dvb_device_put
                          |-&gt; kref_put

When calling dvb_unregister_device, dmxdev-&gt;dvbdev (i.e. *pdvbdev in
dvb_register_device) could point to memory that had been freed in
dvb_register_device. Thereafter, this pointer is transferred to
kref_put and triggering a use-after-free.</Note>
    </Notes>
    <CVE>CVE-2024-27043</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">HTTP/2 incoming headers exceeding the limit are temporarily buffered in nghttp2 in order to generate an informative HTTP 413 response. If a client does not stop sending headers, this leads to memory exhaustion.</Note>
    </Notes>
    <CVE>CVE-2024-27316</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:

pstore: inode: Only d_invalidate() is needed

Unloading a modular pstore backend with records in pstorefs would
trigger the dput() double-drop warning:

  WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410

Using the combo of d_drop()/dput() (as mentioned in
Documentation/filesystems/vfs.rst) isn't the right approach here, and
leads to the reference counting problem seen above. Use d_invalidate()
and update the code to not bother checking for error codes that can
never happen.

---</Note>
    </Notes>
    <CVE>CVE-2024-27389</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">wall in util-linux through 2.40, often installed with setgid tty permissions, allows escape sequences to be sent to other users' terminals through argv. (Specifically, escape sequences received from stdin are blocked, but escape sequences received from argv are not blocked.) There may be plausible scenarios where this leads to account takeover.</Note>
    </Notes>
    <CVE>CVE-2024-28085</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">nghttp2 is an implementation of the Hypertext Transfer Protocol version 2 in C. The nghttp2 library prior to version 1.61.0 keeps reading the unbounded number of HTTP/2 CONTINUATION frames even after a stream is reset to keep HPACK context in sync.  This causes excessive CPU usage to decode HPACK stream. nghttp2 v1.61.0 mitigates this vulnerability by limiting the number of CONTINUATION frames it accepts per stream. There is no workaround for this vulnerability.</Note>
    </Notes>
    <CVE>CVE-2024-28182</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">libexpat through 2.6.1 allows an XML Entity Expansion attack when there is isolated use of external parsers (created via XML_ExternalEntityParserCreate).</Note>
    </Notes>
    <CVE>CVE-2024-28757</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. The Minerva attack is a cryptographic vulnerability that exploits deterministic behavior in systems like GnuTLS, leading to side-channel leaks. In specific scenarios, such as when using the GNUTLS_PRIVKEY_FLAG_REPRODUCIBLE flag, it can result in a noticeable step in nonce size from 513 to 512 bits, exposing a potential timing side-channel.</Note>
    </Notes>
    <CVE>CVE-2024-28834</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 has been discovered in GnuTLS where an application crash can be induced when attempting to verify a specially crafted .pem bundle using the "certtool --verify-chain" command.</Note>
    </Notes>
    <CVE>CVE-2024-28835</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 iconv() function in the GNU C Library versions 2.39 and older may overflow the output buffer passed to it by up to 4 bytes when converting strings to the ISO-2022-CN-EXT character set, which may be used to crash an application or overwrite a neighbouring variable.
</Note>
    </Notes>
    <CVE>CVE-2024-2961</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">Because of a logical error in XSA-407 (Branch Type Confusion), the
mitigation is not applied properly when it is intended to be used.
XSA-434 (Speculative Return Stack Overflow) uses the same
infrastructure, so is equally impacted.

For more details, see:
  https://xenbits.xen.org/xsa/advisory-407.html
  https://xenbits.xen.org/xsa/advisory-434.html
</Note>
    </Notes>
    <CVE>CVE-2024-31142</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">less through 653 allows OS command execution via a newline character in the name of a file, because quoting is mishandled in filename.c. Exploitation typically requires use with attacker-controlled file names, such as the files extracted from an untrusted archive. Exploitation also requires the LESSOPEN environment variable, but this is set by default in many common cases.</Note>
    </Notes>
    <CVE>CVE-2024-32487</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">** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.</Note>
    </Notes>
    <CVE>CVE-2024-33427</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">nscd: Stack-based buffer overflow in netgroup cache

If the Name Service Cache Daemon's (nscd) fixed size cache is exhausted
by client requests then a subsequent client request for netgroup data
may result in a stack-based buffer overflow.  This flaw was introduced
in glibc 2.15 when the cache was added to nscd.

This vulnerability is only present in the nscd binary.
</Note>
    </Notes>
    <CVE>CVE-2024-33599</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">nscd: Null pointer crashes after notfound response

If the Name Service Cache Daemon's (nscd) cache fails to add a not-found
netgroup response to the cache, the client request can result in a null
pointer dereference.  This flaw was introduced in glibc 2.15 when the
cache was added to nscd.

This vulnerability is only present in the nscd binary.

</Note>
    </Notes>
    <CVE>CVE-2024-33600</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">nscd: netgroup cache may terminate daemon on memory allocation failure

The Name Service Cache Daemon's (nscd) netgroup cache uses xmalloc or
xrealloc and these functions may terminate the process due to a memory
allocation failure resulting in a denial of service to the clients.  The
flaw was introduced in glibc 2.15 when the cache was added to nscd.

This vulnerability is only present in the nscd binary.

</Note>
    </Notes>
    <CVE>CVE-2024-33601</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">nscd: netgroup cache assumes NSS callback uses in-buffer strings

The Name Service Cache Daemon's (nscd) netgroup cache can corrupt memory
when the NSS callback does not store all strings in the provided buffer.
The flaw was introduced in glibc 2.15 when the cache was added to nscd.

This vulnerability is only present in the nscd binary.

</Note>
    </Notes>
    <CVE>CVE-2024-33602</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">Jinja is an extensible templating engine. The `xmlattr` filter in affected versions of Jinja accepts keys containing non-attribute characters. XML/HTML attributes cannot contain spaces, `/`, `&gt;`, or `=`, as each would then be interpreted as starting a separate attribute. If an application accepts keys (as opposed to only values) as user input, and renders these in pages that other users see as well, an attacker could use this to inject other attributes and perform XSS. The fix for CVE-2024-22195 only addressed spaces but not other characters. Accepting keys as user input is now explicitly considered an unintended use case of the `xmlattr` filter, and code that does so without otherwise validating the input should be flagged as insecure, regardless of Jinja version. Accepting _values_ as user input continues to be safe. This vulnerability is fixed in 3.1.4.</Note>
    </Notes>
    <CVE>CVE-2024-34064</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An issue was discovered in GNOME GLib before 2.78.5, and 2.79.x and 2.80.x before 2.80.1. When a GDBus-based client subscribes to signals from a trusted system service such as NetworkManager on a shared computer, other users of the same computer can send spoofed D-Bus signals that the GDBus-based client will wrongly interpret as having been sent by the trusted system service. This could lead to the GDBus-based client behaving incorrectly, with an application-dependent impact.</Note>
    </Notes>
    <CVE>CVE-2024-34397</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">Requests is a HTTP library. Prior to 2.32.0, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. This vulnerability is fixed in 2.32.0.</Note>
    </Notes>
    <CVE>CVE-2024-35195</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.8 and earlier, when starting the cupsd server with a Listen configuration item pointing to a symbolic link, the cupsd process can be caused to perform an arbitrary chmod of the provided argument, providing world-writable access to the target. Given that cupsd is often running as root, this can result in the change of permission of any user or system files to be world writable. Given the aforementioned Ubuntu AppArmor context, on such systems this vulnerability is limited to those files modifiable by the cupsd process. In that specific case it was found to be possible to turn the configuration of the Listen argument into full control over the cupsd.conf and cups-files.conf configuration files. By later setting the User and Group arguments in cups-files.conf, and printing with a printer configured by PPD with a `FoomaticRIPCommandLine` argument, arbitrary user and group (not root) command execution could be achieved, which can further be used on Ubuntu systems to achieve full root command execution. Commit ff1f8a623e090dee8a8aadf12a6a4b25efac143d contains a patch for the issue.
</Note>
    </Notes>
    <CVE>CVE-2024-35235</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 identified in the kjd/idna library, specifically within the `idna.encode()` function, affecting version 3.6. The issue arises from the function's handling of crafted input strings, which can lead to quadratic complexity and consequently, a denial of service condition. This vulnerability is triggered by a crafted input that causes the `idna.encode()` function to process the input with considerable computational load, significantly increasing the processing time in a quadratic manner relative to the input size.</Note>
    </Notes>
    <CVE>CVE-2024-3651</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
</cvrfdoc>
