<?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:328-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:328-1</ID>
    </Identification>
    <Status>Interim</Status>
    <Version>1</Version>
    <RevisionHistory>
      <Revision>
        <Number>1</Number>
        <Date>2025-01-26T22:27:41Z</Date>
        <Description>current</Description>
      </Revision>
    </RevisionHistory>
    <InitialReleaseDate>2024-04-26T01:00:00Z</InitialReleaseDate>
    <CurrentReleaseDate>2024-04-26T01: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:328-1 / google/sle-micro-5-4-byos-v20240426-arm64</Note>
    <Note Title="Details" Type="General" Ordinal="2" xml:lang="en">This image update for google/sle-micro-5-4-byos-v20240426-arm64 contains the following changes:
Package 000release-packages:SLE-Micro-release was updated:

Package aaa_base was updated:

- silence the output in the case of broken symlinks (bsc#1218232)
- fix git-47-04210f8df15da0ba4d741cfe1693af06f5978a1d.patch
  to actually apply

- replace git-47-04210f8df15da0ba4d741cfe1693af06f5978a1d.patch
  by git-47-056fc66c699a8544c7692a03c905fca568f5390b.patch
  * fix the issues from bsc#1107342 and bsc#1215434 and just
    use the settings from update-alternatives to set JAVA_HOME

Package audit-secondary was updated:

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

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

- Update to version 1.12 (bsc#1221202)
  + If token access succeeds using IPv4 do not use the IPv6 endpoint
    only use the IPv6 IMDS endpoint if IPv4 access fails.

- Add Provides/Obsoletes for dropped cloud-netconfig-nm
- Install dispatcher script into /etc/NetworkManager/dispatcher.d
  on older distributions
- Add BuildReqires: NetworkManager to avoid owning dispatcher.d
  parent directory

- Update to version 1.11:
  + Revert address metadata lookup in GCE to local lookup (bsc#1219454)
  + Fix hang on warning log messages
  + Check whether getting IPv4 addresses from metadata failed and abort
    if true
  + Only delete policy rules if they exist
  + Skip adding/removing IPv4 ranges if metdata lookup failed
  + Improve error handling and logging in Azure
  + Set SCRIPTDIR when installing netconfig wrapper

- Update to version 1.10:
  + Drop cloud-netconfig-nm sub package and include NM dispatcher
    script in main packages (bsc#1219007)
  + Spec file cleanup

- Update to version 1.9:
  + Drop package dependency on sysconfig-netconfig
  + Improve log level handling
  + Support IPv6 IMDS endpoint in EC2 (bsc#1218069)

Package cloud-regionsrv-client was updated:

- Update to version 10.1.7 (bsc#1220164, bsc#1220165)  + Fix the failover path to a new target update server. At present a new
    server is not found since credential validation fails. We targeted
    the server detected in down condition to verify the credentials instead
    of the replacement server.

- Update EC2 plugin to 1.0.4 (bsc#1219156, bsc#1219159)
  + Fix the algorithm to determine the region from the availability zone
    information retrieved from IMDS.
- Update to version 10.1.6
  + Support specifying an IPv6 address for a manually configured target
    update server.

Package containerd was updated:

- Add patch for bsc#1217952:  + 0002-shim-Create-pid-file-with-0644-permissions.patch

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

Package coreutils was updated:

- 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 cpio was updated:

- Fix cpio not working after the fix in bsc#1218571, fixes bsc#1219238  * fix-bsc1219238.patch

- Fix CVE-2023-7207, path traversal vulnerability (bsc#1218571)
  * fix-CVE-2023-7207.patch

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)

- Vendor latest buildkit v0.11:
  Add patch 0006-Vendor-in-latest-buildkit-v0.11-branch-including-CVE.patch that
  vendors in the latest v0.11 buildkit branch including bugfixes for the following:
  * bsc#1219438: CVE-2024-23653
  * bsc#1219268: CVE-2024-23652
  * bsc#1219267: CVE-2024-23651
- 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
- switch from %patchN to %patch -PN syntax
- remove unused rpmlint filters and add filters to silence pointless bash &amp;amp; zsh
  completion warnings

Package glibc was updated:

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

- qsort-invalid-cmp.patch: qsort: handle degenerated compare function
  (bsc#1218866)

- getaddrinfo-eai-memory.patch: getaddrinfo: translate ENOMEM to
  EAI_MEMORY (bsc#1217589, BZ #31163)

- aarch64-rawmemchr-unwind.patch: aarch64: correct CFI in rawmemchr
  (bsc#1217445, BZ #31113)

Package kernel-default was updated:

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

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

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

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

- 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

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

- 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

- aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts
  (bsc#1218562 CVE-2023-6270).
- commit 57a4cd4

- efivarfs: force RO when remounting if SetVariable is not
  supported (bsc#1220328 CVE-2023-52463).
- commit eed7fb0

- iommu/vt-d: Avoid memory allocation in iommu_suspend()
  (CVE-2023-52559 bsc#1220933).
- commit c9b01ef

- Refresh patches.suse/0001-powerpc-pseries-memhp-Fix-access-beyond-end-of-drmem.patch.
  - update to upstream version
  - rename to same name as SLE15 SP5
- commit 1d2def1

- KVM: x86: Export RFDS_NO and RFDS_CLEAR to guests (bsc#1213456 CVE-2023-28746).
- commit 4aebf4f

- x86/rfds: Mitigate Register File Data Sampling (RFDS)  (bsc#1213456 CVE-2023-28746).
- Update config files.
- commit 29c1c99

- Documentation/hw-vuln: Add documentation for RFDS (bsc#1213456 CVE-2023-28746).
- commit 81de603

- ravb: Fix use-after-free issue in ravb_tx_timeout_work()
  (bsc#1212514 CVE-2023-35827).
- team: fix null-ptr-deref when team device type is changed
  (bsc#1220870 CVE-2023-52574).
- commit 2cc53f5

- Update
  patches.suse/ice-xsk-return-xsk-buffers-back-to-pool-when-cleanin.patch
  (jsc#SLE-18375 bsc#1220961 CVE-2021-47105).
- Update patches.suse/net-mana-Fix-TX-CQE-error-handling.patch
  (bsc#1215986 bsc#1220932 CVE-2023-52532).
- Update
  patches.suse/net-mlx5e-Wrap-the-tx-reporter-dump-callback-to-extr.patch
  (jsc#SLE-19253 bsc#1220486 CVE-2021-46931).
  Added CVE references.
- commit 3e396c2

- Update patches.suse/i2c-validate-user-data-in-compat-ioctl.patch
  (git-fixes bsc#1220469 CVE-2021-46934).
  Add bug and CVE references.
- commit 3a04060

- wifi: mac80211: fix potential key use-after-free (CVE-2023-52530
  bsc#1220930).
- commit 3feca94

- Update patch reference for iwlwifi fix (CVE-2023-52531 bsc#1220931)
- commit bde87cf

- Update patch reference for pinctrl fix (CVE-2021-47083 bsc#1220917)
- commit b608623

- drm/bridge: sii902x: Fix probing race issue (bsc#1220736 CVE-2024-26607).
- commit 70198c4

- Update
  patches.suse/vt-fix-memory-overlapping-when-deleting-chars-in-the.patch
  (git-fixes bsc#1220845 CVE-2022-48627).
- Update
  patches.suse/x86-srso-add-srso-mitigation-for-hygon-processors.patch
  (git-fixes bsc#1220735 CVE-2023-52482).
  Add CVE references.
- commit dcdac38

- mfd: syscon: Fix null pointer dereference in
  of_syscon_register() (bsc#1220433 CVE-2023-52467).
- commit b0262b8

- bpf: Fix re-attachment branch in bpf_tracing_prog_attach
  (bsc#1220254 CVE-2024-26591).
- commit fc948d3

- selftests/bpf: Add test for alu on PTR_TO_FLOW_KEYS (bsc#1220255
  CVE-2024-26589).
- bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS (bsc#1220255
  CVE-2024-26589).
- commit 8a833ce

- iommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range (CVE-2023-52484 bsc#1220797).
- commit 2229de3

- tls: fix race between tx work scheduling and socket close
  (CVE-2024-26585 bsc#1220187).
- commit 1306bff

- kabi: restore return type of dst_ops::gc() callback
  (CVE-2023-52340 bsc#1219295).
- ipv6: remove max_size check inline with ipv4 (CVE-2023-52340
  bsc#1219295).
- commit b8eec42

- netfilter: nf_tables: fix 64-bit load issue in
  nft_byteorder_eval() (CVE-2024-0607 bsc#1218915).
- netfilter: nf_tables: fix pointer math issue in
  nft_byteorder_eval() (CVE-2024-0607 bsc#1218915).
- commit e095cd0

- netfilter: nft_set_pipapo: skip inactive elements during set
  walk (CVE-2023-6817 bsc#1218195).
- commit 4032aa7

- tomoyo: fix UAF write bug in tomoyo_write_control() (bsc#1220825
  CVE-2024-26622).
- commit c8e5b38

- doc/README.SUSE: Update information about module support status
  (jsc#PED-5759)
  Following the code change in SLE15-SP6 to have externally supported
  modules no longer taint the kernel, update the respective documentation
  in README.SUSE:
  * Describe that support status can be obtained at runtime for each
  module from /sys/module/$MODULE/supported and for the entire system
  from /sys/kernel/supported. This provides a way how to now check that
  the kernel has any externally supported modules loaded.
  * Remove a mention that externally supported modules taint the kernel,
  but keep the information about bit 16 (X) and add a note that it is
  still tracked per module and can be read from
  /sys/module/$MODULE/taint. This per-module information also appears in
  Oopses.
- commit 9ed8107

- btrfs: fix double free of anonymous device after snapshot
  creation failure (bsc#1219126 CVE-2024-23850).
- commit 257a534

- btrfs: do not ASSERT() if the newly created subvolume already
  got read (bsc#1219126 CVE-2024-23850).
- commit a2ac581

- bpf: Minor cleanup around stack bounds (bsc#1220257
  CVE-2023-52452).
- bpf: Fix accesses to uninit stack slots (bsc#1220257
  CVE-2023-52452).
- bpf: Guard stack limits against 32bit overflow (git-fixes).
- bpf: Fix verification of indirect var-off stack access
  (git-fixes).
- commit 7d03125

- serial: 8250: omap: Don't skip resource freeing if
  pm_runtime_resume_and_get() failed (bsc#1220350 CVE-2023-52457).
- commit c82f528

- serial: imx: fix tx statemachine deadlock (bsc#1220364
  CVE-2023-52456).
- commit cd9f92c

- powerpc/pseries/memhp: Fix access beyond end of drmem array
  (bsc#1220250,CVE-2023-52451).
- commit fdc7254

- Update patch reference for input fix (CVE-2021-46932 bsc#1220444)
- commit e44e0b1

- Update patches.suse/i2c-Fix-a-potential-use-after-free.patch
  (git-fixes bsc#1220409 CVE-2019-25162).
  Add bug and CVE references.
- commit 6df4ebd

- efivarfs: force RO when remounting if SetVariable is not
  supported (bsc#1220328 CVE-2023-52463).
- commit 3cfef52

- btrfs: fix double free of anonymous device after snapshot
  creation failure (bsc#1219126 CVE-2024-23850).
- commit f8ba729

- mtd: Fix gluebi NULL pointer dereference caused by ftl notifier
  (bsc#1220238 CVE-2023-52449).
- commit c132b67

- fs/mount_setattr: always cleanup mount_kattr (bsc#1220457
  CVE-2021-46923).
- commit 89afe2f

- kABI: bpf: map_fd_put_ptr() signature kABI workaround
  (bsc#1220251 CVE-2023-52447).
- kABI: bpf: struct bpf_map kABI workaround (bsc#1220251
  CVE-2023-52447).
- kABI: bpf: map_fd_put_ptr() signature kABI workaround
  (bsc#1220251 CVE-2023-52447).
- kABI: bpf: struct bpf_map kABI workaround (bsc#1220251
  CVE-2023-52447).
- commit bec1c61

- selftests/bpf: Test outer map update operations in syscall
  program (bsc#1220251 CVE-2023-52447).
- selftests/bpf: Add test cases for inner map (bsc#1220251
  CVE-2023-52447).
- bpf: Defer the free of inner map when necessary (bsc#1220251
  CVE-2023-52447).
- Refresh patches.suse/kABI-padding-for-bpf.patch
- bpf: Set need_defer as false when clearing fd array during
  map free (bsc#1220251 CVE-2023-52447).
- bpf: Add map and need_defer parameters to .map_fd_put_ptr()
  (bsc#1220251 CVE-2023-52447).
- bpf: Check rcu_read_lock_trace_held() before calling bpf map
  helpers (bsc#1220251 CVE-2023-52447).
- rcu-tasks: Provide rcu_trace_implies_rcu_gp() (bsc#1220251
  CVE-2023-52447).
- selftests/bpf: Test outer map update operations in syscall
  program (bsc#1220251 CVE-2023-52447).
- selftests/bpf: Add test cases for inner map (bsc#1220251
  CVE-2023-52447).
- bpf: Defer the free of inner map when necessary (bsc#1220251
  CVE-2023-52447).
- Refresh patches.suse/kABI-padding-for-bpf.patch
- bpf: Set need_defer as false when clearing fd array during
  map free (bsc#1220251 CVE-2023-52447).
- bpf: Add map and need_defer parameters to .map_fd_put_ptr()
  (bsc#1220251 CVE-2023-52447).
- bpf: Check rcu_read_lock_trace_held() before calling bpf map
  helpers (bsc#1220251 CVE-2023-52447).
- rcu-tasks: Provide rcu_trace_implies_rcu_gp() (bsc#1220251
  CVE-2023-52447).
- commit aa6db76

- Update patch reference for HID fix (CVE-2023-52478 bsc#1220796)
- commit 4aec836

- Update patch reference for input fix (CVE-2023-52475 bsc#1220649)
- commit 00a87c8

- KVM: arm64: vgic-its: Avoid potential UAF in LPI translation
  cache (bsc#1220326, CVE-2024-26598).
- commit 74fd0dd

- x86/fpu: Stop relying on userspace for info to fault in xsave buffer (bsc#1220335, CVE-2024-26603).
- commit 4cbbdbf

- Update patch reference for NFC fix (CVE-2021-46924 bsc#1220459)
- commit 8ac32a8

- media: pvrusb2: fix use after free on context disconnection
  (CVE-2023-52445 bsc#1220241).
- commit e4643a5

- uio: Fix use-after-free in uio_open (bsc#1220140
  CVE-2023-52439).
- commit fbf52b1

- apparmor: avoid crash when parsed profile name is empty
  (CVE-2023-52443 bsc#1220240).
- commit 732bc93

- btrfs: do not ASSERT() if the newly created subvolume already
  got read (bsc#1219126 CVE-2024-23850).
- commit 087f1fb

- sched/membarrier: reduce the ability to hammer on sys_membarrier
  (git-fixes, bsc#1220398, CVE-2024-26602).
- commit 6f61ce3

- i2c: i801: Fix block process call transactions (bsc#1220009
  CVE-2024-26593).
- commit 1b64da9

- mlxsw: spectrum_acl_tcam: Fix stack corruption (bsc#1220243
  CVE-2024-26586).
- mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in
  error path (bsc#1220344 CVE-2024-26595).
- commit 6e8b589

- EDAC/thunderx: Fix possible out-of-bounds string access (bsc#1220330, CVE-2023-52464)
- commit 369d1fd

- Drop 2 git-fixes patches which are suspicious to introduce regression
  reported in bsc#1219073,
  - patches.suse/md-Set-MD_BROKEN-for-RAID1-and-RAID10-9631.patch.
  - patches.suse/md-raid1-free-the-r1bio-before-waiting-for-blocked-r-992d.patch.
- Refresh patches.suse/md-display-timeout-error.patch for the above
  change.
- commit 4ecd26a

- gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump
  (bsc#1220253 CVE-2023-52448).
- commit 12cdab5

- rpm templates: Always define usrmerged
  usrmerged is now defined in kernel-spec-macros and not the distribution.
  Only check if it's defined in kernel-spec-macros, not everywhere where
  it's used.
- commit a6ad8af

- nvme: remove nvme_alloc_request and nvme_alloc_request_qid
  (bsc#1214064).
  Refresh:
  - patches.suse/nvme-tcp-delay-error-recovery-until-the-next-kato.patch
- commit 6fc2117

- rpm templates: Move macro definitions below buildrequires
  Many of the rpm macros defined in the kernel packages depend directly or
  indirectly on script execution. OBS cannot execute scripts which means
  values of these macros cannot be used in tags that are required for OBS
  to see such as package name, buildrequires or buildarch.
  Accumulate macro definitions that are not directly expanded by mkspec
  below buildrequires and buildarch to make this distinction clear.
- commit 89eaf4c

- rpm/check-for-config-changes: add GCC_ASM_GOTO_OUTPUT_WORKAROUND to IGNORED_CONFIGS_RE
  Introduced by commit 68fb3ca0e408 (&amp;quot;update workarounds for gcc &amp;quot;asm
  goto&amp;quot; issue&amp;quot;).
- commit be1bdab

- net: openvswitch: limit the number of recursions from action
  sets (bsc#1219835 CVE-2024-1151).
- commit ed2fd55

- README.BRANCH: use correct mail for Roy
- commit 6f3c32f

- compute-PATCHVERSION: Do not produce output when awk fails
  compute-PATCHVERSION uses awk to produce a shell script that is
  subsequently executed to update shell variables which are then printed
  as the patchversion.
  Some versions of awk, most notably bysybox-gawk do not understand the
  awk program and fail to run. This results in no script generated as
  output, and printing the initial values of the shell variables as
  the patchversion.
  When the awk program fails to run produce 'exit 1' as the shell script
  to run instead. That prevents printing the stale values, generates no
  output, and generates invalid rpm spec file down the line. Then the
  problem is flagged early and should be easier to diagnose.
- commit 8ef8383

- nvme: move nvme_stop_keep_alive() back to original position
  (bsc#1211515).
- commit b945fa0

- x86/asm: Add _ASM_RIP() macro for x86-64 (%rip) suffix (git-fixes).
- commit 636fc4c

- KVM: VMX: Move VERW closer to VMentry for MDS mitigation (git-fixes).
- KVM: VMX: Use BT+JNC, i.e. EFLAGS.CF to select VMRESUME vs. VMLAUNCH (git-fixes).
- x86/bugs: Use ALTERNATIVE() instead of mds_user_clear static key (git-fixes).
  Also add the removed mds_user_clear symbol to kABI severities as it is
  exposed just for KVM module and is generally a core kernel component so
  removing it is low risk.
- x86/entry_32: Add VERW just before userspace transition (git-fixes).
- x86/entry_64: Add VERW just before userspace transition (git-fixes).
- x86/bugs: Add asm helpers for executing VERW (git-fixes).
- commit 5b0be3c

- netfilter: nf_tables: disallow rule removal from chain binding
  (bsc#1218216 CVE-2023-5197).
- commit d7a1a4d

- netfilter: nf_tables: skip bound chain in netns release path
  (bsc#1218216 CVE-2023-5197).
- commit af879c8

- nvme: start keep-alive after admin queue setup (bsc#1211515).
- commit 13f904b

- net/rds: Fix UBSAN: array-index-out-of-bounds in rds_cmsg_recv
  (bsc#1219127 CVE-2024-23849).
- commit 43577c1

- kernel-binary: Move build script to the end
  All other spec templates have the build script at the end, only
  kernel-binary has it in the middle. Align with the other templates.
- commit 98cbdd0

- rpm templates: Aggregate subpackage descriptions
  While in some cases the package tags, description, scriptlets and
  filelist are located together in other cases they are all across the
  spec file. Aggregate the information related to a subpackage in one
  place.
- commit 8eeb08c

- rpm templates: sort rpm tags
  The rpm tags in kernel spec files are sorted at random.
  Make the order of rpm tags somewhat more consistent across rpm spec
  templates.
- commit 8875c35

- dm: limit the number of targets and parameter size area
  (bsc#1219827, bsc#1219146, CVE-2023-52429, CVE-2024-23851).
- commit 26dc83e

- Fix unresolved hunks in README.BRANCH
- commit 99bb861

- NFS: avoid infinite loop in pnfs_update_layout (bsc#1219633).
- commit b6a1f9a

- vhost: use kzalloc() instead of kmalloc() followed by memset()
  (CVE-2024-0340, bsc#1218689).
- commit 4c5a740

- README.BRANCH: Update cve/linux-5.14 maintainers
  Add myself to match SLE15-SP5 consumer + fix typo in branch name.
- commit da26653

- Refresh patches.suse/nfsd-fix-RELEASE_LOCKOWNER.patch.
  Accidentally removed nfs4_get_stateowner
- commit d77a474

- kernel-binary: certs: Avoid trailing space
- commit bc7dc31

- Bluetooth: Fix atomicity violation in {min,max}_key_size_set
  (git-fixes bsc#1219608 CVE-2024-24860).
- commit a1186fd

- README.BRANCH: update branch name to cve/linux-5.14, update maintainers
  as requested
- commit 8e34879

- rpm/kernel-binary.spec.in: install scripts/gdb when enabled in config
  (bsc#1219653)
  They are put into -devel subpackage. And a proper link to
  /usr/share/gdb/auto-load/ is created.
- commit 1dccf2a

- netfilter: nf_tables: check if catch-all set element is active
  in next generation (CVE-2024-1085 bsc#1219429).
- commit 7b3f4c4

- netfilter: nf_tables: reject QUEUE/DROP verdict parameters
  (CVE-2024-1086 bsc#1219434).
- commit 5f917ff

- Update
  patches.suse/drm-amdgpu-Fix-potential-fence-use-after-free-v2.patch
  (bsc#1219128 CVE-2023-51042 git-fixes).
- commit 4b937fc

- rpm/mkspec: sort entries in _multibuild
  Otherwise it creates unnecessary diffs when tar-up-ing. It's of course
  due to readdir() using &amp;quot;random&amp;quot; order as served by the underlying
  filesystem.
  See for example:
  https://build.opensuse.org/request/show/1144457/changes
- commit d1155de

- Revert &amp;quot;tracing: Increase trace array ref count on enable and
  filter files&amp;quot; (bsc#1219490).
  Deleted:
  patches.suse/tracing-Increase-trace-array-ref-count-on-enable-and-filter-files.patch
  patches.suse/tracing-Have-event-inject-files-inc-the-trace-array-ref-count.patch
  Backported commit f5ca233e2e66 (&amp;quot;tracing: Increase trace array ref count
  on enable and filter files&amp;quot;) causes a kernel panic and its upstream
  fix-up bb32500fb9b7 (&amp;quot;tracing: Have trace_event_file have ref counters&amp;quot;)
  cannot be easily backported because it affects kABI. Revert the commit
  and its one related + dependent patch, at least for now.
- commit 90d885a

- README.BRANCH: SLE15-SP4 became LTSS, update maintainers
- commit 94325df

- atm: Fix Use-After-Free in do_vcc_ioctl (CVE-2023-51780
  bsc#1218730).
- commit 658d424

- xen-netback: don't produce zero-size SKB frags (CVE-2023-46838,
  XSA-448, bsc#1218836).
- commit 9a897ff

- Update
  patches.suse/ext4-fix-kernel-BUG-in-ext4_write_inline_data_end.patch
  (CVE-2021-33631 bsc#1219412 bsc#1206894).
- commit 96c942c

- kabi, vmstat: skip periodic vmstat update for isolated CPUs
  (bsc#1217895).
- commit 8cb5798

- sched/isolation: add cpu_is_isolated() API (bsc#1217895).
- trace,smp: Add tracepoints around remotelly called functions
  (bsc#1217895).
- vmstat: skip periodic vmstat update for isolated CPUs
  (bsc#1217895).
- Refresh
  patches.suse/0002-kernel-smp-make-csdlock-timeout-depend-on-boot-param.patch.
- commit 668c0e0

- kernel-source: Fix description typo
- commit 8abff35

- nvmet-tcp: Fix the H2C expected PDU len calculation
  (bsc#1217987 bsc#1217988 bsc#1217989 CVE-2023-6535 CVE-2023-6536
  CVE-2023-6356).
- nvmet-tcp: remove boilerplate code (bsc#1217987 bsc#1217988
  bsc#1217989 CVE-2023-6535 CVE-2023-6536 CVE-2023-6356).
- nvmet-tcp: fix a crash in nvmet_req_complete() (bsc#1217987
  bsc#1217988 bsc#1217989 CVE-2023-6535 CVE-2023-6536
  CVE-2023-6356).
- nvmet-tcp: Fix a kernel panic when host sends an invalid H2C
  PDU length (bsc#1217987 bsc#1217988 bsc#1217989 CVE-2023-6535
  CVE-2023-6536 CVE-2023-6356).
- commit d968940

- clocksource: Skip watchdog check for large watchdog intervals
  (bsc#1217217).
- commit 63b1d6d

- clocksource: disable watchdog checks on TSC when TSC is watchdog
  (bsc#1215885).
- commit 2f92dd8

- nfsd4: add refcount for nfsd4_blocked_lock (bsc#1218968
  bsc#1219349).
- commit d38f35d

- wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach
  (CVE-2023-47233 bsc#1216702).
- commit 433859d

- rpm/constraints.in: set jobs for riscv to 8
  The same workers are used for x86 and riscv and the riscv builds take
  ages. So align the riscv jobs count to x86.
- commit b2c82b9

- net: sched: sch_qfq: Use non-work-conserving warning handler
  (CVE-2023-4921 bsc#1215275).
- commit b50ba0e

- mkspec: Use variant in constraints template
  Constraints are not applied consistently with kernel package variants.
  Add variant to the constraints template as appropriate, and expand it
  in mkspec.
- commit cc68ab9

- rpm/constraints.in: add static multibuild packages
  Commit 841012b049a5 (rpm/mkspec: use kernel-source: prefix for
  constraints on multibuild) added &amp;quot;kernel-source:&amp;quot; prefix to the
  dynamically generated kernels. But there are also static ones like
  kernel-docs. Those fail to build as the constraints are still not
  applied.
  So add the prefix also to the static ones.
  Note kernel-docs-rt is given kernel-source-rt prefix. I am not sure it
  will ever be multibuilt...
- commit c2e0681

- Update
  patches.suse/drm-atomic-Fix-potential-use-after-free-in-nonblocki.patch
  (bsc#1219120 CVE-2023-51043 git-fixes).
- commit d004027

- Revert &amp;quot;Limit kernel-source build to architectures for which the kernel binary&amp;quot;
  This reverts commit 08a9e44c00758b5f3f3b641830ab6affff041132.
  The fix for bsc#1108281 directly causes bsc#1218768, revert.
- commit 2943b8a

- mkspec: Include constraints for both multibuild and plain package always
  There is no need to check for multibuild flag, the constraints can be
  always generated for both cases.
- commit 308ea09

- rpm/mkspec: use kernel-source: prefix for constraints on multibuild
  Otherwise the constraints are not applied with multibuild enabled.
- commit 841012b

- rpm/kernel-source.rpmlintrc: add action-ebpf
  Upstream commit a79d8ba734bd (selftests: tc-testing: remove buildebpf
  plugin) added this precompiled binary blob. Adapt rpmlintrc for
  kernel-source.
- commit b5ccb33

- block: Fix kabi header include (bsc#1218929).
- commit 8f511ac

- scripts/tar-up.sh: don't add spurious entry from kernel-sources.changes.old
  The previous change added the manual entry from kernel-sources.change.old
  to old_changelog.txt unnecessarily.  Let's fix it.
- commit fb033e8

- Update
  patches.suse/ext4-improve-error-recovery-code-paths-in-__ext4_rem.patch
  (bsc#1213017 bsc#1219053 CVE-2024-0775).
- commit 97ea702

- block: free the extended dev_t minor later (bsc#1218930).
- commit 0972f94

- rpm/kernel-docs.spec.in: fix build with 6.8
  Since upstream commit f061c9f7d058 (Documentation: Document each netlink
  family), the build needs python yaml.
- commit 6a7ece3

- hv_netvsc: rndis_filter needs to select NLS (git-fixes).
- commit 6f3116b

- nfsd: fix RELEASE_LOCKOWNER (bsc#1218968).
- commit 605df5b

- netfilter: nf_tables: Reject tables of unsupported family
  (bsc#1218752 CVE-2023-6040).
- commit e03f1d3

- bcache: revert replacing IS_ERR_OR_NULL with IS_ERR (git-fixes).
- bcache: replace a mistaken IS_ERR() by IS_ERR_OR_NULL() in
  btree_gc_coalesce() (git-fixes).
- rbd: take header_rwsem in rbd_dev_refresh() only when updating
  (git-fixes).
- dm: don't lock fs when the map is NULL during suspend or resume
  (git-fixes).
- commit fe9ee72

- tipc: fix a potential deadlock on &amp;amp;tx-&amp;gt;lock (bsc#1218916
  CVE-2024-0641).
- commit c872674

- Update metadata
- commit d121b79

- tipc: fix a potential deadlock on &amp;amp;tx-&amp;gt;lock (bsc#1218916
  CVE-2024-0641).
- commit 7953be2

- Update metadata
- commit c015ae2

- smb: client: fix OOB in receive_encrypted_standard()
  (bsc#1218832 CVE-2024-0565).
- commit 3cac9c2

- ida: Fix crash in ida_free when the bitmap is empty (bsc#1218804
  CVE-2023-6915).
- commit 7caa324

- dm-integrity: don't modify bio's immutable bio_vec in
  integrity_metadata() (git-fixes).
- dm-verity: align struct dm_verity_fec_io properly (git-fixes).
- dm verity: don't perform FEC for failed readahead IO
  (git-fixes).
- bcache: avoid NULL checking to c-&amp;gt;root in run_cache_set()
  (git-fixes).
- bcache: add code comments for bch_btree_node_get() and
  __bch_btree_node_alloc() (git-fixes).
- bcache: fixup multi-threaded bch_sectors_dirty_init() wake-up
  race (git-fixes).
- bcache: fixup lock c-&amp;gt;root error (git-fixes).
- bcache: fixup init dirty data errors (git-fixes).
- bcache: prevent potential division by zero error (git-fixes).
- bcache: remove redundant assignment to variable cur_idx
  (git-fixes).
- bcache: check return value from btree_node_alloc_replacement()
  (git-fixes).
- bcache: avoid oversize memory allocation by small stripe_size
  (git-fixes).
- dm-delay: fix a race between delay_presuspend and delay_bio
  (git-fixes).
- dm zoned: free dmz-&amp;gt;ddev array in dmz_put_zoned_devices
  (git-fixes).
- rbd: decouple parent info read-in from updating rbd_dev
  (git-fixes).
- rbd: decouple header read-in from updating rbd_dev-&amp;gt;header
  (git-fixes).
- rbd: move rbd_dev_refresh() definition (git-fixes).
- rbd: prevent busy loop when requesting exclusive lock
  (git-fixes).
- rbd: retrieve and check lock owner twice before blocklisting
  (git-fixes).
- rbd: harden get_lock_owner_info() a bit (git-fixes).
- rbd: make get_lock_owner_info() return a single locker or NULL
  (git-fixes).
- dm cache policy smq: ensure IO doesn't prevent cleaner policy
  progress (git-fixes).
- dm raid: clean up four equivalent goto tags in raid_ctr()
  (git-fixes).
- dm raid: fix missing reconfig_mutex unlock in raid_ctr()
  error paths (git-fixes).
- dm integrity: reduce vmalloc space footprint on 32-bit
  architectures (git-fixes).
- dm thin metadata: Fix ABBA deadlock by resetting dm_bufio_client
  (git-fixes).
- bcache: fixup btree_cache_wait list damage (git-fixes).
- bcache: Fix __bch_btree_node_alloc to make the failure behavior
  consistent (git-fixes).
- bcache: Remove unnecessary NULL point check in node allocations
  (git-fixes).
- dm thin metadata: check fail_io before using data_sm
  (git-fixes).
- commit 7e800d7

- rbd: get snapshot context after exclusive lock is ensured to
  be held (git-fixes).
- Refresh for the above change,
  patches.suse/rbd-export-some-functions-used-by-lio-rbd-backend.patch.
  patches.suse/target_core_rbd-fix-rbd_img_request.snap_id-assignme.patch.
- commit dcd100d

- rbd: move RBD_OBJ_FLAG_COPYUP_ENABLED flag setting (git-fixes).
- Rebased for the above change,
  patches.suse/rbd-add-support-for-COMPARE_AND_WRITE-CMPEXT.patch.
- commit b5f85f8

- nbd: Fix debugfs_create_dir error checking (git-fixes).
- dm: don't lock fs when the map is NULL in process of resume
  (git-fixes).
- dm flakey: fix a crash with invalid table line (git-fixes).
- dm integrity: call kmem_cache_destroy() in dm_integrity_init()
  error path (git-fixes).
- dm clone: call kmem_cache_destroy() in dm_clone_init() error
  path (git-fixes).
- dm verity: fix error handling for check_at_most_once on FEC
  (git-fixes).
- nbd: fix incomplete validation of ioctl arg (git-fixes).
- null_blk: Always check queue mode setting from configfs
  (git-fixes).
- dm stats: check for and propagate alloc_percpu failure
  (git-fixes).
- dm crypt: avoid accessing uninitialized tasklet (git-fixes).
- dm crypt: add cond_resched() to dmcrypt_write() (git-fixes).
- commit ad93a37

- dm thin: fix deadlock when swapping to thin device
  (bsc#1177529).
- Delete the in-house patch by the above upstream patch,
  patches.suse/Avoid-deadlock-for-recursive-I-O-on-dm-thin-when-used-as-swap-4905.patch.
- commit 13bcec1

- rbd: avoid use-after-free in do_rbd_add() when rbd_dev_create()
  fails (git-fixes).
- dm cache: add cond_resched() to various workqueue loops
  (git-fixes).
- dm thin: add cond_resched() to various workqueue loops
  (git-fixes).
- dm: add cond_resched() to dm_wq_work() (git-fixes).
- dm: remove flush_scheduled_work() during local_exit()
  (git-fixes).
- dm: send just one event on resize, not two (git-fixes).
- dm flakey: fix logic when corrupting a bio (git-fixes).
- dm flakey: don't corrupt the zero page (git-fixes).
- dm init: add dm-mod.waitfor to wait for asynchronously probed
  block devices (git-fixes).
- loop: suppress uevents while reconfiguring the device
  (git-fixes).
- commit 2a9583d

- nbd: use the correct block_device in nbd_bdev_reset (git-fixes).
- Refresh for the above change,
  patches.suse/0019-nbd-fix-io-hung-while-disconnecting-device.patch.
  patches.suse/0031-nbd-Fix-hung-when-signal-interrupts-nbd_start_device_ioctl.patch.
- commit 2cb1a83

- blacklist.conf: add non-backport git-fixes commit
- commit ab480ce

- dm verity: skip redundant verity_handle_err() on I/O errors
  (git-fixes).
- commit 7d823a7

- Update
  patches.kabi/NFS-Fix-another-fsync-issue-after-a-server-reboot.patch
  (git-fixes, bsc#1217670).
- commit 69dfe32

- blacklist.conf: df1c357f25d8 netfs: Only call folio_start_fscache() one time for each folio
- commit 049ab09

- intel_idle: add Emerald Rapids Xeon support (bsc#1216016).
- commit 30bac4b

- Update patch reference for rose fix (CVE-2023-51782 bsc#1218757)
- commit da9f8e9

- blacklist.conf: c4d361f66ac9 fuse: share lookup state between submount and its parent
- commit 3180cfa

- powerpc/pseries/iommu: enable_ddw incorrectly returns direct
  mapping for SR-IOV device (bsc#1212091 ltc#199106 git-fixes).
- commit f20e9a0

- Store the old kernel changelog entries in kernel-docs package (bsc#1218713)
  The old entries are found in kernel-docs/old_changelog.txt in docdir.
  rpm/old_changelog.txt can be an optional file that stores the similar
  info like rpm/kernel-sources.changes.old.  It can specify the commit
  range that have been truncated.  scripts/tar-up.sh expands from the
  git log accordingly.
- commit c9a2566

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-2022-48624, LESSCLOSE handling in less does not quote shell  metacharacters, bsc#1219901
  * CVE-2022-48624.patch

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

- 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 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 mozilla-nss was updated:

- update to NSS 3.90.2  * bmo#1780432 - (CVE-2023-5388) Timing attack against RSA
    decryption in TLS. (bsc#1216198)
  * bmo#1867408 - add a defensive check for large ssl_DefSend
    return values.

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

- Security fix: [bsc#1218862, CVE-2024-0567]
  * gnutls: rejects certificate chain with distributed trust
  * Cockpit (which uses gnuTLS) rejects certificate chain with
    distributed trust.
  * Add gnutls-CVE-2024-0567.patch

- Security fix: [bsc#1218865, CVE-2024-0553]
  * Incomplete fix for CVE-2023-5981.
  * The response times to malformed ciphertexts in RSA-PSK
    ClientKeyExchange differ from response times of ciphertexts
    with correct PKCS#1 v1.5 padding.
  * Add gnutls-CVE-2024-0553.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#1219243, CVE-2024-0727]  * Add NULL checks where ContentInfo data can be NULL
  * Add openssl-CVE-2024-0727.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].

- (bsc#1219666, CVE-2023-6597) Add
  CVE-2023-6597-TempDir-cleaning-symlink.patch (patch from
  gh#python/cpython!99930) fixing symlink bug in cleanup of
  tempfile.TemporaryDirectory.
- Merge together bpo-36576-skip_tests_for_OpenSSL-111.patch into
  skip_SSL_tests.patch, and make them include all conditionals.

- Refresh CVE-2023-27043-email-parsing-errors.patch to
  gh#python/cpython!111116, fixing bsc#1210638 (CVE-2023-27043).

Package libsolv was updated:

- build for multiple python versions [jsc#PED-6218]- bump version to 0.7.28

Package libssh was updated:

- Fix regression parsing IPv6 addresses provided as hostname (bsc#1220385)  * Added libssh-fix-ipv6-hostname-regression.patch

Package libxml2 was updated:

- Security fix (CVE-2024-25062, bsc#1219576) use-after-free in XMLReader  * Added libxml2-CVE-2024-25062.patch

Package libzypp was updated:

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

- tui: allow to access the underlying ostream of out::Info.
- Add MLSep: Helper to produce not-NL-terminated multi line
  output.
- version 17.31.31 (22)

- applydeltaprm: Create target directory if it does not exist
  (bsc#1219442)
- Add ProblemSolution::skipsPatchesOnly (for openSUSE/zypper#514)
- Fix problems with EINTR in ExternalDataSource::getline (fixes
  bsc#1215698)
- version 17.31.30 (22)

- CheckAccessDeleted: fix running_in_container detection
  (bsc#1218782)
- Detect CURLOPT_REDIR_PROTOCOLS_STR availability at runtime
  (bsc#1218831)
- Make Wakeup class EINTR safe.
- Add a way to cancel media operations on shutdown
  (openSUSE/zypper#522)
  This patch adds a mechanism to signal libzypp that a shutdown was
  requested, usually when CTRL+C was pressed by the user. Currently
  only the media backend will utilize this, but can be extended to
  all code paths that use g_poll() to wait for events.
- Manually poll fds for curl in MediaCurl.
  Using curl_easy_perform does not give us the required control on
  when we want to cancel a download. Switching to the MultiCurl
  implementation with a external poll() event loop will give us
  much more freedom and helps us to improve our Ctrl+C handling.
- Move reusable curl poll code to curlhelper.h.
- version 17.31.29 (22)

- Fix to build with libxml 2.12.x (fixes #505)
- version 17.31.28 (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 netcfg was updated:

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

- Added openssh-cve-2023-51385.patch (bsc#1218215, CVE-2023-51385).
  This limits the use of shell metacharacters in host- and
  user names.

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 python-instance-billing-flavor-check was updated:

- Version 0.0.6 (bsc#1218561)  Support proxy setup on the client to access the update infrastructure
  API

- Version 0.0.5
  Add IPv6 support (bsc#1218739)

Package python3-M2Crypto was updated:

- Disable broken tests with openssl 3.2, bsc#1217782
- add timeout_300hz.patch to accept a small deviation from time
  in the testsuite (bsc#1212757)

- Adapt tests for OpenSSL v3.1.0
  * Add openssl-adapt-tests-for-3.1.0.patch

- add openssl-stop-parsing-header.patch (bsc#1205042)
- add m2crypto-0.38-ossl3-tests.patch

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 salt was updated:

- Prevent directory traversal when creating syndic cache directory  on the master (CVE-2024-22231, bsc#1219430)
- Prevent directory traversal attacks in the master's serve_file
  method (CVE-2024-22232, bsc#1219431)
- Added:
  * fix-cve-2024-22231-and-cve-2024-22232-bsc-1219430-bs.patch

- Ensure that pillar refresh loads beacons from pillar without restart
- Fix the aptpkg.py unit test failure
- Prefer unittest.mock to python-mock in test suite
- Enable &amp;quot;KeepAlive&amp;quot; probes for Salt SSH executions (bsc#1211649)
- Revert changes to set Salt configured user early in the stack (bsc#1216284)
- Align behavior of some modules when using salt-call via symlink (bsc#1215963)
- Fix gitfs &amp;quot;__env__&amp;quot; and improve cache cleaning (bsc#1193948)
- Remove python-boto dependency for the python3-salt-testsuite package for Tumbleweed
- Added:
  * fix-the-aptpkg.py-unit-test-failure.patch
  * enable-keepalive-probes-for-salt-ssh-executions-bsc-.patch
  * prefer-unittest.mock-for-python-versions-that-are-su.patch
  * update-__pillar__-during-pillar_refresh.patch
  * revert-make-sure-configured-user-is-properly-set-by-.patch
  * fix-gitfs-__env__-and-improve-cache-cleaning-bsc-119.patch
  * dereference-symlinks-to-set-proper-__cli-opt-bsc-121.patch

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

- Update to runc v1.1.12. Upstream changelog is available from
  &amp;lt;https://github.com/opencontainers/runc/releases/tag/v1.1.12&amp;gt;. bsc#1218894
  * This release fixes a container breakout vulnerability (CVE-2024-21626). For
    more details, see the upstream security advisory:
    &amp;lt;https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv&amp;gt;
  * Remove upstreamed patches:
  - CVE-2024-21626.patch
  * Update runc.keyring to match upstream changes.

[ This was only ever released for SLES. ]
- Add upstream patch to fix embargoed issue CVE-2024-21626. bsc#1218894
  &amp;lt;https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv&amp;gt;
  + CVE-2024-21626.patch

- Update to runc v1.1.11. Upstream changelog is available from
  &amp;lt;https://github.com/opencontainers/runc/releases/tag/v1.1.11&amp;gt;.

Package sed was updated:

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

Package selinux-policy was updated:

- Update to version 20230511+git16.5733e724:  * Dontaudit getty and plymouth the checkpoint_restore capability (bsc#1220361)

- Update to version 20230511+git14.93d944dd:
  * allow haveged to manage tmpfs directories (bsc#1213594)

Package sudo was updated:

- Fix NOPASSWD issue introduced by patches for CVE-2023-42465  [bsc#1221151, bsc#1221134]
  * Update sudo-CVE-2023-42465-1of2.patch sudo-CVE-2023-42465-2of2.patch
  * Enable running regression selftests during build time.

- Security fix: [bsc#1219026, bsc#1220389, CVE-2023-42465]
  * Try to make sudo less vulnerable to ROWHAMMER attacks.
  * Add sudo-CVE-2023-42465-1of2.patch sudo-CVE-2023-42465-2of2.patch

Package supportutils-plugin-suse-public-cloud was updated:

- Update to version 1.0.9 (bsc#1218762, bsc#1218763)  + Remove duplicate data collection for the plugin itself
  + Collect archive metering data when available
  + Query billing flavor status

Package supportutils was updated:

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

- Additional changes in version 3.1.28
  + ipset - List entries for all sets
  + ipvsadm - Inspect the virtual server table (pr#185)
  + Correctly detects Xen Dom0 (bsc#1218201)
  + Fixed smart disk error (bsc#1218282)

- Changes in version 3.1.28
  + Inhibit the conversion of port numbers to port names for network files (cherry picked from commit 55f5f716638fb15e3eb1315443949ed98723d250)
  + powerpc: collect rtas_errd.log and lp_diag.log files (pr#175)
  + Get list of pam.d file (cherry picked from commit eaf35c77fd4bc039fd7e3d779ec1c2c6521283e2)
  + Remove supportutils requires for util-linux-systemd and kmod (bsc#1193173)
  + Added missing klp information to kernel-livepatch.txt (bsc#1216390)
  + Fixed plugins creating empty files when using supportconfig.rc (bsc#1216388)
  + Provides long listing for /etc/sssd/sssd.conf (bsc#1211547)
  + Optimize lsof usage (bsc#1183663)
  + Added mokutil commands for secureboot (pr#179)
  + Collects chrony or ntp as needed (bsc#1196293)

- Changes in version 3.1.27
  + Fixed podman display issue (bsc#1217287)
  + Added nvme-stas configuration to nvme.txt (bsc#1216049)
  + Added timed command to fs-files.txt (bsc#1216827)
  + Collects zypp history file issue#166 (bsc#1216522)
  + Changed -x OPTION to really be exclude only (issue#146)
  + Collect HA related rpm package versions in ha.txt (pr#169)

Package suse-build-key was updated:

- Switch container key to be default RSA 4096bit. (jsc#PED-2777)
- run rpm commands in import script only when libzypp is not
  active. bsc#1219189 bsc#1219123

- run import script also in %posttrans section, but only when
  libzypp is not active. bsc#1219189 bsc#1219123

Package suse-module-tools was updated:

- Update to version 15.4.19:  * rpm-script: add symlink /boot/.vmlinuz.hmac (bsc#1217775)

Package suseconnect-ng was updated:

- Allow &amp;quot;--rollback&amp;quot; flag to run on readonly filesystem (bsc#1220679)
- Update to version 1.7.0
  * Allow SUSEConnect on read write transactional systems (bsc#1219425)

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-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 timezone was updated:

- update to 2024a:  * Kazakhstan unifies on UTC+5.  This affects Asia/Almaty and
    Asia/Qostanay which together represent the eastern portion of the
    country that will transition from UTC+6 on 2024-03-01 at 00:00 to
    join the western portion.  (Thanks to Zhanbolat Raimbekov.)
  * Palestine springs forward a week later than previously predicted
    in 2024 and 2025.  (Thanks to Heba Hamad.)  Change spring-forward
    predictions to the second Saturday after Ramadan, not the first;
    this also affects other predictions starting in 2039.
  * Asia/Ho_Chi_Minh's 1955-07-01 transition occurred at 01:00
    not 00:00.  (Thanks to ÄoÃ n Tráº§n CÃ´ng Danh.)
  * From 1947 through 1949, Toronto's transitions occurred at 02:00
    not 00:00.  (Thanks to Chris Walton.)
  * In 1911 Miquelon adopted standard time on June 15, not May 15.
  * The FROM and TO columns of Rule lines can no longer be &amp;quot;minimum&amp;quot;
    or an abbreviation of &amp;quot;minimum&amp;quot;, because TZif files do not support
    DST rules that extend into the indefinite past - although these
    rules were supported when TZif files had only 32-bit data, this
    stopped working when 64-bit TZif files were introduced in 1995.
    This should not be a problem for realistic data, since DST was
    first used in the 20th century.  As a transition aid, FROM columns
    like &amp;quot;minimum&amp;quot; are now diagnosed and then treated as if they were
    the year 1900; this should suffice for TZif files on old systems
    with only 32-bit time_t, and it is more compatible with bugs in
    2023c-and-earlier localtime.c.  (Problem reported by Yoshito
    Umaoka.)
  * localtime and related functions no longer mishandle some
    timestamps that occur about 400 years after a switch to a time
    zone with a DST schedule.  In 2023d data this problem was visible
    for some timestamps in November 2422, November 2822, etc. in
    America/Ciudad_Juarez.  (Problem reported by Gilmore Davidson.)
  * strftime %s now uses tm_gmtoff if available.  (Problem and draft
    patch reported by Dag-Erling SmÃ¸rgrav.)
  * The strftime man page documents which struct tm members affect
    which conversion specs, and that tzset is called.  (Problems
    reported by Robert Elz and Steve Summit.)

- update to 2023d:
  * Ittoqqortoormiit, Greenland changes time zones on
    2024-03-31.
  * Vostok, Antarctica changed time zones on 2023-12-18.
  * Casey, Antarctica changed time zones five times since
    2020.
  * Code and data fixes for Palestine timestamps starting in
    2072.
  * A new data file zonenow.tab for timestamps starting now.
  * Fix predictions for DST transitions in Palestine in
    2072-2075, correcting a typo introduced in 2023a.
  * Vostok, Antarctica changed to +05 on 2023-12-18.  It had
    been at +07 (not +06) for years.
  * Change data for Casey, Antarctica to agree with
    timeanddate.com, by adding five time zone changes since 2020.
    Casey is now at +08 instead of +11.
  * Much of Greenland, represented by America/Nuuk, changed
    its standard time from -03 to -02 on 2023-03-25, not on
    2023-10-28.
  * localtime.c no longer mishandles TZif files that contain
    a single transition into a DST regime.  Previously,
    it incorrectly assumed DST was in effect before the transition
    too.
  * tzselect no longer creates temporary files.
  * tzselect no longer mishandles the following:
  * Spaces and most other special characters in BUGEMAIL,
    PACKAGE, TZDIR, and VERSION.
  * TZ strings when using mawk 1.4.3, which mishandles
    regular expressions of the form /X{2,}/.
  * ISO 6709 coordinates when using an awk that lacks the
    GNU extension of newlines in -v option-arguments.
  * Non UTF-8 locales when using an iconv command that
    lacks the GNU //TRANSLIT extension.
  * zic no longer mishandles data for Palestine after the
    year 2075.
- Refresh tzdata-china.diff

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 0111, fixes the following security problems  * Fixing bsc#1217316 (CVE-2023-48231) - VUL-0: CVE-2023-48231: vim: Use-After-Free in win_close()
  * Fixing bsc#1217320 (CVE-2023-48232) - VUL-0: CVE-2023-48232: vim: Floating point Exception in adjust_plines_for_skipcol()
  * Fixing bsc#1217321 (CVE-2023-48233) - VUL-0: CVE-2023-48233: vim: overflow with count for :s command
  * Fixing bsc#1217324 (CVE-2023-48234) - VUL-0: CVE-2023-48234: vim: overflow in nv_z_get_count
  * Fixing bsc#1217326 (CVE-2023-48235) - VUL-0: CVE-2023-48235: vim: overflow in ex address parsing
  * Fixing bsc#1217329 (CVE-2023-48236) - VUL-0: CVE-2023-48236: vim: overflow in get_number
  * Fixing bsc#1217330 (CVE-2023-48237) - VUL-0: CVE-2023-48237: vim: overflow in shift_line
  * Fixing bsc#1217432 (CVE-2023-48706) - VUL-0: CVE-2023-48706: vim: heap-use-after-free in ex_substitute
  * Fixing bsc#1219581 (CVE-2024-22667) - VUL-0: CVE-2024-22667: vim: stack-based buffer overflow in did_set_langmap function in map.c
  * Fixing bsc#1215005 (CVE-2023-4750) - VUL-0: CVE-2023-4750: vim: Heap use-after-free in function bt_quickfix
- for the complete list of changes see
  https://github.com/vim/vim/compare/v9.0.2103...v9.1.0111

Package wpa_supplicant was updated:

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/sle-micro-5-4-byos-v20240426-arm64/</URL>
      <Description>Public Cloud Image Info</Description>
    </Reference>
    <Reference Type="Self">
      <URL>https://www.suse.com/support/security/rating/</URL>
      <Description>SUSE Security Ratings</Description>
    </Reference>
  </DocumentReferences>
  <ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
    <Branch Type="Product Family" Name="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <Branch Type="Product Name" Name="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
        <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
      </Branch>
    </Branch>
    <Branch Type="Product Version" Name="aaa_base-84.87+git20180409.04c9dae-150300.10.12.1">
      <FullProductName ProductID="aaa_base-84.87+git20180409.04c9dae-150300.10.12.1">aaa_base-84.87+git20180409.04c9dae-150300.10.12.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="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.1.7-150300.10.5.2">
      <FullProductName ProductID="catatonit-0.1.7-150300.10.5.2">catatonit-0.1.7-150300.10.5.2</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="cloud-regionsrv-client-10.1.7-150000.6.108.1">
      <FullProductName ProductID="cloud-regionsrv-client-10.1.7-150000.6.108.1">cloud-regionsrv-client-10.1.7-150000.6.108.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cloud-regionsrv-client-plugin-gce-1.0.0-150000.6.108.1">
      <FullProductName ProductID="cloud-regionsrv-client-plugin-gce-1.0.0-150000.6.108.1">cloud-regionsrv-client-plugin-gce-1.0.0-150000.6.108.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.3.1">
      <FullProductName ProductID="coreutils-8.32-150400.9.3.1">coreutils-8.32-150400.9.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cpio-2.13-150400.3.6.1">
      <FullProductName ProductID="cpio-2.13-150400.3.6.1">cpio-2.13-150400.3.6.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="glibc-2.31-150300.74.1">
      <FullProductName ProductID="glibc-2.31-150300.74.1">glibc-2.31-150300.74.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-locale-2.31-150300.74.1">
      <FullProductName ProductID="glibc-locale-2.31-150300.74.1">glibc-locale-2.31-150300.74.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-locale-base-2.31-150300.74.1">
      <FullProductName ProductID="glibc-locale-base-2.31-150300.74.1">glibc-locale-base-2.31-150300.74.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kernel-default-5.14.21-150400.24.116.1">
      <FullProductName ProductID="kernel-default-5.14.21-150400.24.116.1">kernel-default-5.14.21-150400.24.116.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="less-590-150400.3.6.2">
      <FullProductName ProductID="less-590-150400.3.6.2">less-590-150400.3.6.2</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="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="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="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="libfreebl3-3.90.2-150400.3.39.1">
      <FullProductName ProductID="libfreebl3-3.90.2-150400.3.39.1">libfreebl3-3.90.2-150400.3.39.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="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="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.63.1">
      <FullProductName ProductID="libopenssl1_1-1.1.1l-150400.7.63.1">libopenssl1_1-1.1.1l-150400.7.63.1</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="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="libsoftokn3-3.90.2-150400.3.39.1">
      <FullProductName ProductID="libsoftokn3-3.90.2-150400.3.39.1">libsoftokn3-3.90.2-150400.3.39.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsolv-tools-0.7.28-150400.3.16.2">
      <FullProductName ProductID="libsolv-tools-0.7.28-150400.3.16.2">libsolv-tools-0.7.28-150400.3.16.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libssh-config-0.9.8-150400.3.6.1">
      <FullProductName ProductID="libssh-config-0.9.8-150400.3.6.1">libssh-config-0.9.8-150400.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libssh4-0.9.8-150400.3.6.1">
      <FullProductName ProductID="libssh4-0.9.8-150400.3.6.1">libssh4-0.9.8-150400.3.6.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="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="libxml2-2-2.9.14-150400.5.28.1">
      <FullProductName ProductID="libxml2-2-2.9.14-150400.5.28.1">libxml2-2-2.9.14-150400.5.28.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libzypp-17.32.4-150400.3.61.1">
      <FullProductName ProductID="libzypp-17.32.4-150400.3.61.1">libzypp-17.32.4-150400.3.61.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="login_defs-4.8.1-150400.3.6.1">
      <FullProductName ProductID="login_defs-4.8.1-150400.3.6.1">login_defs-4.8.1-150400.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="mozilla-nss-3.90.2-150400.3.39.1">
      <FullProductName ProductID="mozilla-nss-3.90.2-150400.3.39.1">mozilla-nss-3.90.2-150400.3.39.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="mozilla-nss-certs-3.90.2-150400.3.39.1">
      <FullProductName ProductID="mozilla-nss-certs-3.90.2-150400.3.39.1">mozilla-nss-certs-3.90.2-150400.3.39.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="netcfg-11.6-150000.3.6.1">
      <FullProductName ProductID="netcfg-11.6-150000.3.6.1">netcfg-11.6-150000.3.6.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.63.1">
      <FullProductName ProductID="openssl-1_1-1.1.1l-150400.7.63.1">openssl-1_1-1.1.1l-150400.7.63.1</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-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="python-instance-billing-flavor-check-0.0.6-150000.1.9.1">
      <FullProductName ProductID="python-instance-billing-flavor-check-0.0.6-150000.1.9.1">python-instance-billing-flavor-check-0.0.6-150000.1.9.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-M2Crypto-0.38.0-150400.10.1">
      <FullProductName ProductID="python3-M2Crypto-0.38.0-150400.10.1">python3-M2Crypto-0.38.0-150400.10.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-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-rpm-4.14.3-150400.59.13.1">
      <FullProductName ProductID="python3-rpm-4.14.3-150400.59.13.1">python3-rpm-4.14.3-150400.59.13.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-salt-3006.0-150400.8.54.1">
      <FullProductName ProductID="python3-salt-3006.0-150400.8.54.1">python3-salt-3006.0-150400.8.54.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="rpm-ndb-4.14.3-150400.59.13.1">
      <FullProductName ProductID="rpm-ndb-4.14.3-150400.59.13.1">rpm-ndb-4.14.3-150400.59.13.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.54.1">
      <FullProductName ProductID="salt-3006.0-150400.8.54.1">salt-3006.0-150400.8.54.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="salt-minion-3006.0-150400.8.54.1">
      <FullProductName ProductID="salt-minion-3006.0-150400.8.54.1">salt-minion-3006.0-150400.8.54.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="salt-transactional-update-3006.0-150400.8.54.1">
      <FullProductName ProductID="salt-transactional-update-3006.0-150400.8.54.1">salt-transactional-update-3006.0-150400.8.54.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="selinux-policy-20230511+git16.5733e724-150400.4.30.1">
      <FullProductName ProductID="selinux-policy-20230511+git16.5733e724-150400.4.30.1">selinux-policy-20230511+git16.5733e724-150400.4.30.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="selinux-policy-targeted-20230511+git16.5733e724-150400.4.30.1">
      <FullProductName ProductID="selinux-policy-targeted-20230511+git16.5733e724-150400.4.30.1">selinux-policy-targeted-20230511+git16.5733e724-150400.4.30.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="shadow-4.8.1-150400.3.6.1">
      <FullProductName ProductID="shadow-4.8.1-150400.3.6.1">shadow-4.8.1-150400.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="sudo-1.9.9-150400.4.36.1">
      <FullProductName ProductID="sudo-1.9.9-150400.4.36.1">sudo-1.9.9-150400.4.36.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="supportutils-3.1.29-150300.7.35.27.1">
      <FullProductName ProductID="supportutils-3.1.29-150300.7.35.27.1">supportutils-3.1.29-150300.7.35.27.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="supportutils-plugin-suse-public-cloud-1.0.9-150000.3.20.1">
      <FullProductName ProductID="supportutils-plugin-suse-public-cloud-1.0.9-150000.3.20.1">supportutils-plugin-suse-public-cloud-1.0.9-150000.3.20.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suse-build-key-12.0-150000.8.43.1">
      <FullProductName ProductID="suse-build-key-12.0-150000.8.43.1">suse-build-key-12.0-150000.8.43.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suse-module-tools-15.4.19-150400.3.17.1">
      <FullProductName ProductID="suse-module-tools-15.4.19-150400.3.17.1">suse-module-tools-15.4.19-150400.3.17.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suseconnect-ng-1.8.0-150400.3.28.1">
      <FullProductName ProductID="suseconnect-ng-1.8.0-150400.3.28.1">suseconnect-ng-1.8.0-150400.3.28.1</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-Micro-0.10-150300.3.7.1">
      <FullProductName ProductID="systemd-default-settings-branding-SLE-Micro-0.10-150300.3.7.1">systemd-default-settings-branding-SLE-Micro-0.10-150300.3.7.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="timezone-2024a-150000.75.28.1">
      <FullProductName ProductID="timezone-2024a-150000.75.28.1">timezone-2024a-150000.75.28.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-data-common-9.1.0111-150000.5.60.1">
      <FullProductName ProductID="vim-data-common-9.1.0111-150000.5.60.1">vim-data-common-9.1.0111-150000.5.60.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="vim-small-9.1.0111-150000.5.60.1">
      <FullProductName ProductID="vim-small-9.1.0111-150000.5.60.1">vim-small-9.1.0111-150000.5.60.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="wpa_supplicant-2.9-150000.4.39.1">
      <FullProductName ProductID="wpa_supplicant-2.9-150000.4.39.1">wpa_supplicant-2.9-150000.4.39.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="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>
    <Branch Type="Product Version" Name="zypper-needs-restarting-1.14.71-150400.3.45.2">
      <FullProductName ProductID="zypper-needs-restarting-1.14.71-150400.3.45.2">zypper-needs-restarting-1.14.71-150400.3.45.2</FullProductName>
    </Branch>
    <Relationship ProductReference="aaa_base-84.87+git20180409.04c9dae-150300.10.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:aaa_base-84.87+git20180409.04c9dae-150300.10.12.1">aaa_base-84.87+git20180409.04c9dae-150300.10.12.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="audit-3.0.6-150400.4.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:audit-3.0.6-150400.4.16.1">audit-3.0.6-150400.4.16.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ca-certificates-2+git20240416.98ae794-150300.4.3.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64: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/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="catatonit-0.1.7-150300.10.5.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:catatonit-0.1.7-150300.10.5.2">catatonit-0.1.7-150300.10.5.2 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cloud-netconfig-gce-1.14-150000.25.23.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64: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/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cloud-regionsrv-client-10.1.7-150000.6.108.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:cloud-regionsrv-client-10.1.7-150000.6.108.1">cloud-regionsrv-client-10.1.7-150000.6.108.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cloud-regionsrv-client-plugin-gce-1.0.0-150000.6.108.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:cloud-regionsrv-client-plugin-gce-1.0.0-150000.6.108.1">cloud-regionsrv-client-plugin-gce-1.0.0-150000.6.108.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="containerd-1.7.10-150000.108.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:containerd-1.7.10-150000.108.1">containerd-1.7.10-150000.108.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="coreutils-8.32-150400.9.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:coreutils-8.32-150400.9.3.1">coreutils-8.32-150400.9.3.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cpio-2.13-150400.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:cpio-2.13-150400.3.6.1">cpio-2.13-150400.3.6.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="curl-8.0.1-150400.5.44.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:curl-8.0.1-150400.5.44.1">curl-8.0.1-150400.5.44.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="docker-24.0.7_ce-150000.198.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:docker-24.0.7_ce-150000.198.2">docker-24.0.7_ce-150000.198.2 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-2.31-150300.74.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:glibc-2.31-150300.74.1">glibc-2.31-150300.74.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-locale-2.31-150300.74.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:glibc-locale-2.31-150300.74.1">glibc-locale-2.31-150300.74.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-locale-base-2.31-150300.74.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:glibc-locale-base-2.31-150300.74.1">glibc-locale-base-2.31-150300.74.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kernel-default-5.14.21-150400.24.116.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:kernel-default-5.14.21-150400.24.116.1">kernel-default-5.14.21-150400.24.116.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="krb5-1.19.2-150400.3.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:krb5-1.19.2-150400.3.9.1">krb5-1.19.2-150400.3.9.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="less-590-150400.3.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:less-590-150400.3.6.2">less-590-150400.3.6.2 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libaudit1-3.0.6-150400.4.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:libaudit1-3.0.6-150400.4.16.1">libaudit1-3.0.6-150400.4.16.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libauparse0-3.0.6-150400.4.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:libauparse0-3.0.6-150400.4.16.1">libauparse0-3.0.6-150400.4.16.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libblkid1-2.37.2-150400.8.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:libblkid1-2.37.2-150400.8.29.1">libblkid1-2.37.2-150400.8.29.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libcurl4-8.0.1-150400.5.44.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:libcurl4-8.0.1-150400.5.44.1">libcurl4-8.0.1-150400.5.44.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libexpat1-2.4.4-150400.3.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:libexpat1-2.4.4-150400.3.17.1">libexpat1-2.4.4-150400.3.17.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libfdisk1-2.37.2-150400.8.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:libfdisk1-2.37.2-150400.8.29.1">libfdisk1-2.37.2-150400.8.29.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libfreebl3-3.90.2-150400.3.39.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:libfreebl3-3.90.2-150400.3.39.1">libfreebl3-3.90.2-150400.3.39.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgcc_s1-13.2.1+git8285-150000.1.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64: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/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgnutls30-3.7.3-150400.4.44.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:libgnutls30-3.7.3-150400.4.44.1">libgnutls30-3.7.3-150400.4.44.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libmount1-2.37.2-150400.8.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:libmount1-2.37.2-150400.8.29.1">libmount1-2.37.2-150400.8.29.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libncurses6-6.1-150000.5.24.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:libncurses6-6.1-150000.5.24.1">libncurses6-6.1-150000.5.24.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libnghttp2-14-1.40.0-150200.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:libnghttp2-14-1.40.0-150200.17.1">libnghttp2-14-1.40.0-150200.17.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libopenssl1_1-1.1.1l-150400.7.63.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:libopenssl1_1-1.1.1l-150400.7.63.1">libopenssl1_1-1.1.1l-150400.7.63.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpython3_6m1_0-3.6.15-150300.10.60.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64: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/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsmartcols1-2.37.2-150400.8.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:libsmartcols1-2.37.2-150400.8.29.1">libsmartcols1-2.37.2-150400.8.29.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsoftokn3-3.90.2-150400.3.39.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:libsoftokn3-3.90.2-150400.3.39.1">libsoftokn3-3.90.2-150400.3.39.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsolv-tools-0.7.28-150400.3.16.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:libsolv-tools-0.7.28-150400.3.16.2">libsolv-tools-0.7.28-150400.3.16.2 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libssh-config-0.9.8-150400.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:libssh-config-0.9.8-150400.3.6.1">libssh-config-0.9.8-150400.3.6.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libssh4-0.9.8-150400.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:libssh4-0.9.8-150400.3.6.1">libssh4-0.9.8-150400.3.6.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libstdc++6-13.2.1+git8285-150000.1.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64: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/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libuuid1-2.37.2-150400.8.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:libuuid1-2.37.2-150400.8.29.1">libuuid1-2.37.2-150400.8.29.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxml2-2-2.9.14-150400.5.28.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:libxml2-2-2.9.14-150400.5.28.1">libxml2-2-2.9.14-150400.5.28.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libzypp-17.32.4-150400.3.61.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:libzypp-17.32.4-150400.3.61.1">libzypp-17.32.4-150400.3.61.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="login_defs-4.8.1-150400.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:login_defs-4.8.1-150400.3.6.1">login_defs-4.8.1-150400.3.6.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="mozilla-nss-3.90.2-150400.3.39.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:mozilla-nss-3.90.2-150400.3.39.1">mozilla-nss-3.90.2-150400.3.39.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="mozilla-nss-certs-3.90.2-150400.3.39.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:mozilla-nss-certs-3.90.2-150400.3.39.1">mozilla-nss-certs-3.90.2-150400.3.39.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ncurses-utils-6.1-150000.5.24.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:ncurses-utils-6.1-150000.5.24.1">ncurses-utils-6.1-150000.5.24.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="netcfg-11.6-150000.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:netcfg-11.6-150000.3.6.1">netcfg-11.6-150000.3.6.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-8.4p1-150300.3.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:openssh-8.4p1-150300.3.37.1">openssh-8.4p1-150300.3.37.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-clients-8.4p1-150300.3.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:openssh-clients-8.4p1-150300.3.37.1">openssh-clients-8.4p1-150300.3.37.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-common-8.4p1-150300.3.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:openssh-common-8.4p1-150300.3.37.1">openssh-common-8.4p1-150300.3.37.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-server-8.4p1-150300.3.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:openssh-server-8.4p1-150300.3.37.1">openssh-server-8.4p1-150300.3.37.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssl-1_1-1.1.1l-150400.7.63.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:openssl-1_1-1.1.1l-150400.7.63.1">openssl-1_1-1.1.1l-150400.7.63.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="pam-config-1.1-150200.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:pam-config-1.1-150200.3.6.1">pam-config-1.1-150200.3.6.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="perl-Bootloader-0.947-150400.3.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:perl-Bootloader-0.947-150400.3.12.1">perl-Bootloader-0.947-150400.3.12.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python-instance-billing-flavor-check-0.0.6-150000.1.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:python-instance-billing-flavor-check-0.0.6-150000.1.9.1">python-instance-billing-flavor-check-0.0.6-150000.1.9.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-3.6.15-150300.10.60.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:python3-3.6.15-150300.10.60.1">python3-3.6.15-150300.10.60.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-M2Crypto-0.38.0-150400.10.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:python3-M2Crypto-0.38.0-150400.10.1">python3-M2Crypto-0.38.0-150400.10.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-base-3.6.15-150300.10.60.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64: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/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-idna-2.6-150000.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:python3-idna-2.6-150000.3.3.1">python3-idna-2.6-150000.3.3.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-rpm-4.14.3-150400.59.13.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:python3-rpm-4.14.3-150400.59.13.1">python3-rpm-4.14.3-150400.59.13.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-salt-3006.0-150400.8.54.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:python3-salt-3006.0-150400.8.54.1">python3-salt-3006.0-150400.8.54.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="rpm-ndb-4.14.3-150400.59.13.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:rpm-ndb-4.14.3-150400.59.13.1">rpm-ndb-4.14.3-150400.59.13.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="runc-1.1.12-150000.64.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:runc-1.1.12-150000.64.1">runc-1.1.12-150000.64.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="salt-3006.0-150400.8.54.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:salt-3006.0-150400.8.54.1">salt-3006.0-150400.8.54.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="salt-minion-3006.0-150400.8.54.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:salt-minion-3006.0-150400.8.54.1">salt-minion-3006.0-150400.8.54.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="salt-transactional-update-3006.0-150400.8.54.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:salt-transactional-update-3006.0-150400.8.54.1">salt-transactional-update-3006.0-150400.8.54.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="sed-4.4-150300.13.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:sed-4.4-150300.13.3.1">sed-4.4-150300.13.3.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="selinux-policy-20230511+git16.5733e724-150400.4.30.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:selinux-policy-20230511+git16.5733e724-150400.4.30.1">selinux-policy-20230511+git16.5733e724-150400.4.30.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="selinux-policy-targeted-20230511+git16.5733e724-150400.4.30.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:selinux-policy-targeted-20230511+git16.5733e724-150400.4.30.1">selinux-policy-targeted-20230511+git16.5733e724-150400.4.30.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="shadow-4.8.1-150400.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:shadow-4.8.1-150400.3.6.1">shadow-4.8.1-150400.3.6.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="sudo-1.9.9-150400.4.36.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:sudo-1.9.9-150400.4.36.1">sudo-1.9.9-150400.4.36.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="supportutils-3.1.29-150300.7.35.27.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:supportutils-3.1.29-150300.7.35.27.1">supportutils-3.1.29-150300.7.35.27.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="supportutils-plugin-suse-public-cloud-1.0.9-150000.3.20.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:supportutils-plugin-suse-public-cloud-1.0.9-150000.3.20.1">supportutils-plugin-suse-public-cloud-1.0.9-150000.3.20.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suse-build-key-12.0-150000.8.43.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:suse-build-key-12.0-150000.8.43.1">suse-build-key-12.0-150000.8.43.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suse-module-tools-15.4.19-150400.3.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:suse-module-tools-15.4.19-150400.3.17.1">suse-module-tools-15.4.19-150400.3.17.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suseconnect-ng-1.8.0-150400.3.28.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:suseconnect-ng-1.8.0-150400.3.28.1">suseconnect-ng-1.8.0-150400.3.28.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="system-group-audit-3.0.6-150400.4.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64: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/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-default-settings-0.10-150300.3.7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64: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/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-default-settings-branding-SLE-Micro-0.10-150300.3.7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:systemd-default-settings-branding-SLE-Micro-0.10-150300.3.7.1">systemd-default-settings-branding-SLE-Micro-0.10-150300.3.7.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-rpm-macros-15-150000.7.39.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:systemd-rpm-macros-15-150000.7.39.1">systemd-rpm-macros-15-150000.7.39.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="terminfo-6.1-150000.5.24.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:terminfo-6.1-150000.5.24.1">terminfo-6.1-150000.5.24.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="terminfo-base-6.1-150000.5.24.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:terminfo-base-6.1-150000.5.24.1">terminfo-base-6.1-150000.5.24.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="timezone-2024a-150000.75.28.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:timezone-2024a-150000.75.28.1">timezone-2024a-150000.75.28.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="util-linux-2.37.2-150400.8.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64: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/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="util-linux-systemd-2.37.2-150400.8.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64: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/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-data-common-9.1.0111-150000.5.60.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:vim-data-common-9.1.0111-150000.5.60.1">vim-data-common-9.1.0111-150000.5.60.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-small-9.1.0111-150000.5.60.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:vim-small-9.1.0111-150000.5.60.1">vim-small-9.1.0111-150000.5.60.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="wpa_supplicant-2.9-150000.4.39.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:wpa_supplicant-2.9-150000.4.39.1">wpa_supplicant-2.9-150000.4.39.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="xfsprogs-5.13.0-150400.3.7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:xfsprogs-5.13.0-150400.3.7.1">xfsprogs-5.13.0-150400.3.7.1 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="zypper-1.14.71-150400.3.45.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:zypper-1.14.71-150400.3.45.2">zypper-1.14.71-150400.3.45.2 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="zypper-needs-restarting-1.14.71-150400.3.45.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64:zypper-needs-restarting-1.14.71-150400.3.45.2">zypper-needs-restarting-1.14.71-150400.3.45.2 as a component of Public Cloud Image google/sle-micro-5-4-byos-v20240426-arm64</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">In the Linux kernel, the following vulnerability has been resolved:

i2c: Fix a potential use after free

Free the adap structure only after we are done using it.
This patch just moves the put_device() down a bit to avoid the
use after free.

[wsa: added comment to the code, added Fixes tag]</Note>
    </Notes>
    <CVE>CVE-2019-25162</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 openEuler kernel on Linux (filesystem modules) allows Forced Integer Overflow.This issue affects openEuler kernel: from 4.19.90 before 4.19.90-2401.3, from 5.10.0-60.18.0 before 5.10.0-183.0.0.

</Note>
    </Notes>
    <CVE>CVE-2021-33631</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/mount_setattr: always cleanup mount_kattr

Make sure that finish_mount_kattr() is called after mount_kattr was
succesfully built in both the success and failure case to prevent
leaking any references we took when we built it.  We returned early if
path lookup failed thereby risking to leak an additional reference we
took when building mount_kattr when an idmapped mount was requested.</Note>
    </Notes>
    <CVE>CVE-2021-46923</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:

NFC: st21nfca: Fix memory leak in device probe and remove

'phy-&gt;pending_skb' is alloced when device probe, but forgot to free
in the error handling path and remove path, this cause memory leak
as follows:

unreferenced object 0xffff88800bc06800 (size 512):
  comm "8", pid 11775, jiffies 4295159829 (age 9.032s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;00000000d66c09ce&gt;] __kmalloc_node_track_caller+0x1ed/0x450
    [&lt;00000000c93382b3&gt;] kmalloc_reserve+0x37/0xd0
    [&lt;000000005fea522c&gt;] __alloc_skb+0x124/0x380
    [&lt;0000000019f29f9a&gt;] st21nfca_hci_i2c_probe+0x170/0x8f2

Fix it by freeing 'pending_skb' in error and remove.</Note>
    </Notes>
    <CVE>CVE-2021-46924</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

net/mlx5e: Wrap the tx reporter dump callback to extract the sq

Function mlx5e_tx_reporter_dump_sq() casts its void * argument to struct
mlx5e_txqsq *, but in TX-timeout-recovery flow the argument is actually
of type struct mlx5e_tx_timeout_ctx *.

 mlx5_core 0000:08:00.1 enp8s0f1: TX timeout detected
 mlx5_core 0000:08:00.1 enp8s0f1: TX timeout on queue: 1, SQ: 0x11ec, CQ: 0x146d, SQ Cons: 0x0 SQ Prod: 0x1, usecs since last trans: 21565000
 BUG: stack guard page was hit at 0000000093f1a2de (stack is 00000000b66ea0dc..000000004d932dae)
 kernel stack overflow (page fault): 0000 [#1] SMP NOPTI
 CPU: 5 PID: 95 Comm: kworker/u20:1 Tainted: G W OE 5.13.0_mlnx #1
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
 Workqueue: mlx5e mlx5e_tx_timeout_work [mlx5_core]
 RIP: 0010:mlx5e_tx_reporter_dump_sq+0xd3/0x180
 [mlx5_core]
 Call Trace:
 mlx5e_tx_reporter_dump+0x43/0x1c0 [mlx5_core]
 devlink_health_do_dump.part.91+0x71/0xd0
 devlink_health_report+0x157/0x1b0
 mlx5e_reporter_tx_timeout+0xb9/0xf0 [mlx5_core]
 ? mlx5e_tx_reporter_err_cqe_recover+0x1d0/0x1d0
 [mlx5_core]
 ? mlx5e_health_queue_dump+0xd0/0xd0 [mlx5_core]
 ? update_load_avg+0x19b/0x550
 ? set_next_entity+0x72/0x80
 ? pick_next_task_fair+0x227/0x340
 ? finish_task_switch+0xa2/0x280
   mlx5e_tx_timeout_work+0x83/0xb0 [mlx5_core]
   process_one_work+0x1de/0x3a0
   worker_thread+0x2d/0x3c0
 ? process_one_work+0x3a0/0x3a0
   kthread+0x115/0x130
 ? kthread_park+0x90/0x90
   ret_from_fork+0x1f/0x30
 --[ end trace 51ccabea504edaff ]---
 RIP: 0010:mlx5e_tx_reporter_dump_sq+0xd3/0x180
 PKRU: 55555554
 Kernel panic - not syncing: Fatal exception
 Kernel Offset: disabled
 end Kernel panic - not syncing: Fatal exception

To fix this bug add a wrapper for mlx5e_tx_reporter_dump_sq() which
extracts the sq from struct mlx5e_tx_timeout_ctx and set it as the
TX-timeout-recovery flow dump callback.</Note>
    </Notes>
    <CVE>CVE-2021-46931</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: appletouch - initialize work before device registration

Syzbot has reported warning in __flush_work(). This warning is caused by
work-&gt;func == NULL, which means missing work initialization.

This may happen, since input_dev-&gt;close() calls
cancel_work_sync(&amp;dev-&gt;work), but dev-&gt;work initalization happens _after_
input_register_device() call.

So this patch moves dev-&gt;work initialization before registering input
device</Note>
    </Notes>
    <CVE>CVE-2021-46932</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:

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:

i2c: validate user data in compat ioctl

Wrong user data may cause warning in i2c_transfer(), ex: zero msgs.
Userspace should not be able to trigger warnings, so this patch adds
validation checks for user data in compact ioctl to prevent reported
warnings</Note>
    </Notes>
    <CVE>CVE-2021-46934</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

pinctrl: mediatek: fix global-out-of-bounds issue

When eint virtual eint number is greater than gpio number,
it maybe produce 'desc[eint_n]' size globle-out-of-bounds issue.</Note>
    </Notes>
    <CVE>CVE-2021-47083</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

ice: xsk: return xsk buffers back to pool when cleaning the ring

Currently we only NULL the xdp_buff pointer in the internal SW ring but
we never give it back to the xsk buffer pool. This means that buffers
can be leaked out of the buff pool and never be used again.

Add missing xsk_buff_free() call to the routine that is supposed to
clean the entries that are left in the ring so that these buffers in the
umem can be used by other sockets.

Also, only go through the space that is actually left to be cleaned
instead of a whole ring.</Note>
    </Notes>
    <CVE>CVE-2021-47105</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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">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>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vt: fix memory overlapping when deleting chars in the buffer

A memory overlapping copy occurs when deleting a long line. This memory
overlapping copy can cause data corruption when scr_memcpyw is optimized
to memcpy because memcpy does not ensure its behavior if the destination
buffer overlaps with the source buffer. The line buffer is not always
broken, because the memcpy utilizes the hardware acceleration, whose
result is not deterministic.

Fix this problem by using replacing the scr_memcpyw with scr_memmovew.</Note>
    </Notes>
    <CVE>CVE-2022-48627</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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">The email module of Python through 3.11.3 incorrectly parses e-mail addresses that contain a special character. The wrong portion of an RFC2822 header is identified as the value of the addr-spec. In some applications, an attacker can bypass a protection mechanism in which application access is granted only after verifying receipt of e-mail to a specific domain (e.g., only @company.example.com addresses may be used for signup). This occurs in email/_parseaddr.py in recent versions of Python.</Note>
    </Notes>
    <CVE>CVE-2023-27043</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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">Sudo before 1.9.15 might allow row hammer attacks (for authentication bypass or privilege escalation) because application logic sometimes is based on not equaling an error value (instead of equaling a success value), and because the values do not resist flips of a single bit.</Note>
    </Notes>
    <CVE>CVE-2023-42465</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Transmit requests in Xen's virtual network protocol can consist of
multiple parts.  While not really useful, except for the initial part
any of them may be of zero length, i.e. carry no data at all.  Besides a
certain initial portion of the to be transferred data, these parts are
directly translated into what Linux calls SKB fragments.  Such converted
request parts can, when for a particular SKB they are all of length
zero, lead to a de-reference of NULL in core networking code.
</Note>
    </Notes>
    <CVE>CVE-2023-46838</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 brcm80211 component in the Linux kernel through 6.5.10 has a brcmf_cfg80211_detach use-after-free in the device unplugging (disconnect the USB by hotplug) code. For physically proximate attackers with local access, this "could be exploited in a real world scenario." This is related to brcmf_cfg80211_escan_timeout_worker in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c.</Note>
    </Notes>
    <CVE>CVE-2023-47233</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Use After Free in GitHub repository vim/vim prior to 9.0.1857.</Note>
    </Notes>
    <CVE>CVE-2023-4750</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Vim is an open source command line text editor. When closing a window, vim may try to access already freed window structure. Exploitation beyond crashing the application has not been shown to be viable. This issue has been addressed in commit `25aabc2b` which has been included in release version 9.0.2106. Users are advised to upgrade. There are no known workarounds for this vulnerability.</Note>
    </Notes>
    <CVE>CVE-2023-48231</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Vim is an open source command line text editor. A floating point exception may occur when calculating the line offset for overlong lines and smooth scrolling is enabled and the cpo-settings include the 'n' flag. This may happen when a window border is present and when the wrapped line continues on the next physical line directly in the window border because the 'cpo' setting includes the 'n' flag. Only users with non-default settings are affected and the exception should only result in a crash. This issue has been addressed in commit `cb0b99f0` which has been included in release version 9.0.2107. Users are advised to upgrade. There are no known workarounds for this vulnerability.</Note>
    </Notes>
    <CVE>CVE-2023-48232</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Vim is an open source command line text editor. If the count after the :s command is larger than what fits into a (signed) long variable, abort with e_value_too_large. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `ac6378773` which has been included in release version 9.0.2108. Users are advised to upgrade. There are no known workarounds for this vulnerability.</Note>
    </Notes>
    <CVE>CVE-2023-48233</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Vim is an open source command line text editor. When getting the count for a normal mode z command, it may overflow for large counts given. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `58f9befca1` which has been included in release version 9.0.2109. Users are advised to upgrade. There are no known workarounds for this vulnerability.</Note>
    </Notes>
    <CVE>CVE-2023-48234</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Vim is an open source command line text editor. When parsing relative ex addresses one may unintentionally cause an
overflow. Ironically this happens in the existing overflow check, because the line number becomes negative and LONG_MAX - lnum will cause the overflow. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `060623e` which has been included in release version 9.0.2110. Users are advised to upgrade. There are no known workarounds for this vulnerability.</Note>
    </Notes>
    <CVE>CVE-2023-48235</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Vim is an open source command line text editor. When using the z= command, the user may overflow the count with values larger
than MAX_INT. Impact is low, user interaction is required and a crash may not even happen in all situations. This vulnerability has been addressed in commit `73b2d379` which has been included in release version 9.0.2111. Users are advised to upgrade. There are no known workarounds for this vulnerability.</Note>
    </Notes>
    <CVE>CVE-2023-48236</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Vim is an open source command line text editor. In affected versions when shifting lines in operator pending mode and using a very large value, it may be possible to overflow the size of integer. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `6bf131888` which has been included in version 9.0.2112. Users are advised to upgrade. There are no known workarounds for this vulnerability.</Note>
    </Notes>
    <CVE>CVE-2023-48237</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Vim is a UNIX editor that, prior to version 9.0.2121, has a heap-use-after-free vulnerability. When executing a `:s` command for the very first time and using a sub-replace-special atom inside the substitution part, it is possible that the recursive `:s` call causes free-ing of memory which may later then be accessed by the initial `:s` command. The user must intentionally execute the payload and the whole process is a bit tricky to do since it seems to work only reliably for the very first :s command. It may also cause a crash of Vim. Version 9.0.2121 contains a fix for this issue.</Note>
    </Notes>
    <CVE>CVE-2023-48706</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A use-after-free vulnerability in the Linux kernel's net/sched: sch_qfq component can be exploited to achieve local privilege escalation.

When the plug qdisc is used as a class of the qfq qdisc, sending network packets triggers use-after-free in qfq_dequeue() due to the incorrect .peek handler of sch_plug and lack of error checking in agg_dequeue().

We recommend upgrading past commit 8fc134fee27f2263988ae38920bc03da416b03d8.

</Note>
    </Notes>
    <CVE>CVE-2023-4921</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 before 6.4.12, amdgpu_cs_wait_all_fences in drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c has a fence use-after-free.</Note>
    </Notes>
    <CVE>CVE-2023-51042</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.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.4.5, drivers/gpu/drm/drm_atomic.c has a use-after-free during a race condition between a nonblocking atomic commit and a driver unload.</Note>
    </Notes>
    <CVE>CVE-2023-51043</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In ssh in OpenSSH before 9.6, OS command injection might occur if a user name or host name has shell metacharacters, and this name is referenced by an expansion token in certain situations. For example, an untrusted Git repository can have a submodule with shell metacharacters in a user name or host name.</Note>
    </Notes>
    <CVE>CVE-2023-51385</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 before 6.6.8. do_vcc_ioctl in net/atm/ioctl.c has a use-after-free because of a vcc_recvmsg race condition.</Note>
    </Notes>
    <CVE>CVE-2023-51780</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An issue was discovered in the Linux kernel before 6.6.8. rose_ioctl in net/rose/af_rose.c has a use-after-free because of a rose_accept race condition.</Note>
    </Notes>
    <CVE>CVE-2023-51782</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.

Addition and removal of rules from chain bindings within the same transaction causes leads to use-after-free.

We recommend upgrading past commit f15f29fd4779be8a418b66e9d52979bb6d6c2325.

</Note>
    </Notes>
    <CVE>CVE-2023-5197</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 implementation of PEAP in wpa_supplicant through 2.10 allows authentication bypass. For a successful attack, wpa_supplicant must be configured to not verify the network's TLS certificate during Phase 1 authentication, and an eap_peap_decrypt vulnerability can then be abused to skip Phase 2 authentication. The attack vector is sending an EAP-TLV Success packet instead of starting Phase 2. This allows an adversary to impersonate Enterprise Wi-Fi networks.</Note>
    </Notes>
    <CVE>CVE-2023-52160</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 IPv6 implementation in the Linux kernel before 6.3 has a net/ipv6/route.c max_size threshold that can be consumed easily, e.g., leading to a denial of service (network is unreachable errors) when IPv6 packets are sent in a loop via a raw socket.</Note>
    </Notes>
    <CVE>CVE-2023-52340</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.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">dm_table_create in drivers/md/dm-table.c in the Linux kernel through 6.7.4 can attempt to (in alloc_targets) allocate more than INT_MAX bytes, and crash, because of a missing check for struct dm_ioctl.target_count.</Note>
    </Notes>
    <CVE>CVE-2023-52429</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

uio: Fix use-after-free in uio_open

core-1				core-2
-------------------------------------------------------
uio_unregister_device		uio_open
				idev = idr_find()
device_unregister(&amp;idev-&gt;dev)
put_device(&amp;idev-&gt;dev)
uio_device_release
				get_device(&amp;idev-&gt;dev)
kfree(idev)
uio_free_minor(minor)
				uio_release
				put_device(&amp;idev-&gt;dev)
				kfree(idev)
-------------------------------------------------------

In the core-1 uio_unregister_device(), the device_unregister will kfree
idev when the idev-&gt;dev kobject ref is 1. But after core-1
device_unregister, put_device and before doing kfree, the core-2 may
get_device. Then:
1. After core-1 kfree idev, the core-2 will do use-after-free for idev.
2. When core-2 do uio_release and put_device, the idev will be double
   freed.

To address this issue, we can get idev atomic &amp; inc idev reference with
minor_lock.</Note>
    </Notes>
    <CVE>CVE-2023-52439</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

apparmor: avoid crash when parsed profile name is empty

When processing a packed profile in unpack_profile() described like

 "profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...}"

a string ":samba-dcerpcd" is unpacked as a fully-qualified name and then
passed to aa_splitn_fqname().

aa_splitn_fqname() treats ":samba-dcerpcd" as only containing a namespace.
Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later
aa_alloc_profile() crashes as the new profile name is NULL now.

general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty #16
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014
RIP: 0010:strlen+0x1e/0xa0
Call Trace:
 &lt;TASK&gt;
 ? strlen+0x1e/0xa0
 aa_policy_init+0x1bb/0x230
 aa_alloc_profile+0xb1/0x480
 unpack_profile+0x3bc/0x4960
 aa_unpack+0x309/0x15e0
 aa_replace_profiles+0x213/0x33c0
 policy_update+0x261/0x370
 profile_replace+0x20e/0x2a0
 vfs_write+0x2af/0xe00
 ksys_write+0x126/0x250
 do_syscall_64+0x46/0xf0
 entry_SYSCALL_64_after_hwframe+0x6e/0x76
 &lt;/TASK&gt;
---[ end trace 0000000000000000 ]---
RIP: 0010:strlen+0x1e/0xa0

It seems such behaviour of aa_splitn_fqname() is expected and checked in
other places where it is called (e.g. aa_remove_profiles). Well, there
is an explicit comment "a ns name without a following profile is allowed"
inside.

AFAICS, nothing can prevent unpacked "name" to be in form like
":samba-dcerpcd" - it is passed from userspace.

Deny the whole profile set replacement in such case and inform user with
EPROTO and an explaining message.

Found by Linux Verification Center (linuxtesting.org).</Note>
    </Notes>
    <CVE>CVE-2023-52443</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: pvrusb2: fix use after free on context disconnection

Upon module load, a kthread is created targeting the
pvr2_context_thread_func function, which may call pvr2_context_destroy
and thus call kfree() on the context object. However, that might happen
before the usb hub_event handler is able to notify the driver. This
patch adds a sanity check before the invalid read reported by syzbot,
within the context disconnection call stack.</Note>
    </Notes>
    <CVE>CVE-2023-52445</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump

Syzkaller has reported a NULL pointer dereference when accessing
rgd-&gt;rd_rgl in gfs2_rgrp_dump().  This can happen when creating
rgd-&gt;rd_gl fails in read_rindex_entry().  Add a NULL pointer check in
gfs2_rgrp_dump() to prevent that.</Note>
    </Notes>
    <CVE>CVE-2023-52448</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mtd: Fix gluebi NULL pointer dereference caused by ftl notifier

If both ftl.ko and gluebi.ko are loaded, the notifier of ftl
triggers NULL pointer dereference when trying to access
'gluebi-&gt;desc' in gluebi_read().

ubi_gluebi_init
  ubi_register_volume_notifier
    ubi_enumerate_volumes
      ubi_notify_all
        gluebi_notify    nb-&gt;notifier_call()
          gluebi_create
            mtd_device_register
              mtd_device_parse_register
                add_mtd_device
                  blktrans_notify_add   not-&gt;add()
                    ftl_add_mtd         tr-&gt;add_mtd()
                      scan_header
                        mtd_read
                          mtd_read_oob
                            mtd_read_oob_std
                              gluebi_read   mtd-&gt;read()
                                gluebi-&gt;desc - NULL

Detailed reproduction information available at the Link [1],

In the normal case, obtain gluebi-&gt;desc in the gluebi_get_device(),
and access gluebi-&gt;desc in the gluebi_read(). However,
gluebi_get_device() is not executed in advance in the
ftl_add_mtd() process, which leads to NULL pointer dereference.

The solution for the gluebi module is to run jffs2 on the UBI
volume without considering working with ftl or mtdblock [2].
Therefore, this problem can be avoided by preventing gluebi from
creating the mtdblock device after creating mtd partition of the
type MTD_UBIVOLUME.</Note>
    </Notes>
    <CVE>CVE-2023-52449</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

powerpc/pseries/memhp: Fix access beyond end of drmem array

dlpar_memory_remove_by_index() may access beyond the bounds of the
drmem lmb array when the LMB lookup fails to match an entry with the
given DRC index. When the search fails, the cursor is left pointing to
&amp;drmem_info-&gt;lmbs[drmem_info-&gt;n_lmbs], which is one element past the
last valid entry in the array. The debug message at the end of the
function then dereferences this pointer:

        pr_debug("Failed to hot-remove memory at %llx\n",
                 lmb-&gt;base_addr);

This was found by inspection and confirmed with KASAN:

  pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234
  ==================================================================
  BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658
  Read of size 8 at addr c000000364e97fd0 by task bash/949

  dump_stack_lvl+0xa4/0xfc (unreliable)
  print_report+0x214/0x63c
  kasan_report+0x140/0x2e0
  __asan_load8+0xa8/0xe0
  dlpar_memory+0x298/0x1658
  handle_dlpar_errorlog+0x130/0x1d0
  dlpar_store+0x18c/0x3e0
  kobj_attr_store+0x68/0xa0
  sysfs_kf_write+0xc4/0x110
  kernfs_fop_write_iter+0x26c/0x390
  vfs_write+0x2d4/0x4e0
  ksys_write+0xac/0x1a0
  system_call_exception+0x268/0x530
  system_call_vectored_common+0x15c/0x2ec

  Allocated by task 1:
   kasan_save_stack+0x48/0x80
   kasan_set_track+0x34/0x50
   kasan_save_alloc_info+0x34/0x50
   __kasan_kmalloc+0xd0/0x120
   __kmalloc+0x8c/0x320
   kmalloc_array.constprop.0+0x48/0x5c
   drmem_init+0x2a0/0x41c
   do_one_initcall+0xe0/0x5c0
   kernel_init_freeable+0x4ec/0x5a0
   kernel_init+0x30/0x1e0
   ret_from_kernel_user_thread+0x14/0x1c

  The buggy address belongs to the object at c000000364e80000
   which belongs to the cache kmalloc-128k of size 131072
  The buggy address is located 0 bytes to the right of
   allocated 98256-byte region [c000000364e80000, c000000364e97fd0)

  ==================================================================
  pseries-hotplug-mem: Failed to hot-remove memory at 0

Log failed lookups with a separate message and dereference the
cursor only when it points to a valid entry.</Note>
    </Notes>
    <CVE>CVE-2023-52451</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix accesses to uninit stack slots

Privileged programs are supposed to be able to read uninitialized stack
memory (ever since 6715df8d5) but, before this patch, these accesses
were permitted inconsistently. In particular, accesses were permitted
above state-&gt;allocated_stack, but not below it. In other words, if the
stack was already "large enough", the access was permitted, but
otherwise the access was rejected instead of being allowed to "grow the
stack". This undesired rejection was happening in two places:
- in check_stack_slot_within_bounds()
- in check_stack_range_initialized()
This patch arranges for these accesses to be permitted. A bunch of tests
that were relying on the old rejection had to change; all of them were
changed to add also run unprivileged, in which case the old behavior
persists. One tests couldn't be updated - global_func16 - because it
can't run unprivileged for other reasons.

This patch also fixes the tracking of the stack size for variable-offset
reads. This second fix is bundled in the same commit as the first one
because they're inter-related. Before this patch, writes to the stack
using registers containing a variable offset (as opposed to registers
with fixed, known values) were not properly contributing to the
function's needed stack size. As a result, it was possible for a program
to verify, but then to attempt to read out-of-bounds data at runtime
because a too small stack had been allocated for it.

Each function tracks the size of the stack it needs in
bpf_subprog_info.stack_depth, which is maintained by
update_stack_depth(). For regular memory accesses, check_mem_access()
was calling update_state_depth() but it was passing in only the fixed
part of the offset register, ignoring the variable offset. This was
incorrect; the minimum possible value of that register should be used
instead.

This tracking is now fixed by centralizing the tracking of stack size in
grow_stack_state(), and by lifting the calls to grow_stack_state() to
check_stack_access_within_bounds() as suggested by Andrii. The code is
now simpler and more convincingly tracks the correct maximum stack size.
check_stack_range_initialized() can now rely on enough stack having been
allocated for the access; this helps with the fix for the first issue.

A few tests were changed to also check the stack depth computation. The
one that fails without this patch is verifier_var_off:stack_write_priv_vs_unpriv.</Note>
    </Notes>
    <CVE>CVE-2023-52452</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: imx: fix tx statemachine deadlock

When using the serial port as RS485 port, the tx statemachine is used to
control the RTS pin to drive the RS485 transceiver TX_EN pin. When the
TTY port is closed in the middle of a transmission (for instance during
userland application crash), imx_uart_shutdown disables the interface
and disables the Transmission Complete interrupt. afer that,
imx_uart_stop_tx bails on an incomplete transmission, to be retriggered
by the TC interrupt. This interrupt is disabled and therefore the tx
statemachine never transitions out of SEND. The statemachine is in
deadlock now, and the TX_EN remains low, making the interface useless.

imx_uart_stop_tx now checks for incomplete transmission AND whether TC
interrupts are enabled before bailing to be retriggered. This makes sure
the state machine handling is reached, and is properly set to
WAIT_AFTER_SEND.</Note>
    </Notes>
    <CVE>CVE-2023-52456</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:

serial: 8250: omap: Don't skip resource freeing if pm_runtime_resume_and_get() failed

Returning an error code from .remove() makes the driver core emit the
little helpful error message:

	remove callback returned a non-zero value. This will be ignored.

and then remove the device anyhow. So all resources that were not freed
are leaked in this case. Skipping serial8250_unregister_port() has the
potential to keep enough of the UART around to trigger a use-after-free.

So replace the error return (and with it the little helpful error
message) by a more useful error message and continue to cleanup.</Note>
    </Notes>
    <CVE>CVE-2023-52457</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

efivarfs: force RO when remounting if SetVariable is not supported

If SetVariable at runtime is not supported by the firmware we never assign
a callback for that function. At the same time mount the efivarfs as
RO so no one can call that.  However, we never check the permission flags
when someone remounts the filesystem as RW. As a result this leads to a
crash looking like this:

$ mount -o remount,rw /sys/firmware/efi/efivars
$ efi-updatevar -f PK.auth PK

[  303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[  303.280482] Mem abort info:
[  303.280854]   ESR = 0x0000000086000004
[  303.281338]   EC = 0x21: IABT (current EL), IL = 32 bits
[  303.282016]   SET = 0, FnV = 0
[  303.282414]   EA = 0, S1PTW = 0
[  303.282821]   FSC = 0x04: level 0 translation fault
[  303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000
[  303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
[  303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP
[  303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6
[  303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1
[  303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023
[  303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  303.292123] pc : 0x0
[  303.292443] lr : efivar_set_variable_locked+0x74/0xec
[  303.293156] sp : ffff800008673c10
[  303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000
[  303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027
[  303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000
[  303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000
[  303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54
[  303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4
[  303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002
[  303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201
[  303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc
[  303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000
[  303.303341] Call trace:
[  303.303679]  0x0
[  303.303938]  efivar_entry_set_get_size+0x98/0x16c
[  303.304585]  efivarfs_file_write+0xd0/0x1a4
[  303.305148]  vfs_write+0xc4/0x2e4
[  303.305601]  ksys_write+0x70/0x104
[  303.306073]  __arm64_sys_write+0x1c/0x28
[  303.306622]  invoke_syscall+0x48/0x114
[  303.307156]  el0_svc_common.constprop.0+0x44/0xec
[  303.307803]  do_el0_svc+0x38/0x98
[  303.308268]  el0_svc+0x2c/0x84
[  303.308702]  el0t_64_sync_handler+0xf4/0x120
[  303.309293]  el0t_64_sync+0x190/0x194
[  303.309794] Code: ???????? ???????? ???????? ???????? (????????)
[  303.310612] ---[ end trace 0000000000000000 ]---

Fix this by adding a .reconfigure() function to the fs operations which
we can use to check the requested flags and deny anything that's not RO
if the firmware doesn't implement SetVariable at runtime.</Note>
    </Notes>
    <CVE>CVE-2023-52463</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

EDAC/thunderx: Fix possible out-of-bounds string access

Enabling -Wstringop-overflow globally exposes a warning for a common bug
in the usage of strncat():

  drivers/edac/thunderx_edac.c: In function 'thunderx_ocx_com_threaded_isr':
  drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' specified bound 1024 equals destination size [-Werror=stringop-overflow=]
   1136 |                 strncat(msg, other, OCX_MESSAGE_SIZE);
        |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   ...
   1145 |                                 strncat(msg, other, OCX_MESSAGE_SIZE);
   ...
   1150 |                                 strncat(msg, other, OCX_MESSAGE_SIZE);

   ...

Apparently the author of this driver expected strncat() to behave the
way that strlcat() does, which uses the size of the destination buffer
as its third argument rather than the length of the source buffer. The
result is that there is no check on the size of the allocated buffer.

Change it to strlcat().

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

mfd: syscon: Fix null pointer dereference in of_syscon_register()

kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure.</Note>
    </Notes>
    <CVE>CVE-2023-52467</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: powermate - fix use-after-free in powermate_config_complete

syzbot has found a use-after-free bug [1] in the powermate driver. This
happens when the device is disconnected, which leads to a memory free from
the powermate_device struct.  When an asynchronous control message
completes after the kfree and its callback is invoked, the lock does not
exist anymore and hence the bug.

Use usb_kill_urb() on pm-&gt;config to cancel any in-progress requests upon
device disconnection.

[1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e</Note>
    </Notes>
    <CVE>CVE-2023-52475</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect

hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU)
races when it races with itself.

hidpp_connect_event() primarily runs from a workqueue but it also runs
on probe() and if a "device-connected" packet is received by the hw
when the thread running hidpp_connect_event() from probe() is waiting on
the hw, then a second thread running hidpp_connect_event() will be
started from the workqueue.

This opens the following races (note the below code is simplified):

1. Retrieving + printing the protocol (harmless race):

	if (!hidpp-&gt;protocol_major) {
		hidpp_root_get_protocol_version()
		hidpp-&gt;protocol_major = response.rap.params[0];
	}

We can actually see this race hit in the dmesg in the abrt output
attached to rhbz#2227968:

[ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.
[ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.

Testing with extra logging added has shown that after this the 2 threads
take turn grabbing the hw access mutex (send_mutex) so they ping-pong
through all the other TOCTOU cases managing to hit all of them:

2. Updating the name to the HIDPP name (harmless race):

	if (hidpp-&gt;name == hdev-&gt;name) {
		...
		hidpp-&gt;name = new_name;
	}

3. Initializing the power_supply class for the battery (problematic!):

hidpp_initialize_battery()
{
        if (hidpp-&gt;battery.ps)
                return 0;

	probe_battery(); /* Blocks, threads take turns executing this */

	hidpp-&gt;battery.desc.properties =
		devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);

	hidpp-&gt;battery.ps =
		devm_power_supply_register(&amp;hidpp-&gt;hid_dev-&gt;dev,
					   &amp;hidpp-&gt;battery.desc, cfg);
}

4. Creating delayed input_device (potentially problematic):

	if (hidpp-&gt;delayed_input)
		return;

	hidpp-&gt;delayed_input = hidpp_allocate_input(hdev);

The really big problem here is 3. Hitting the race leads to the following
sequence:

	hidpp-&gt;battery.desc.properties =
		devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);

	hidpp-&gt;battery.ps =
		devm_power_supply_register(&amp;hidpp-&gt;hid_dev-&gt;dev,
					   &amp;hidpp-&gt;battery.desc, cfg);

	...

	hidpp-&gt;battery.desc.properties =
		devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);

	hidpp-&gt;battery.ps =
		devm_power_supply_register(&amp;hidpp-&gt;hid_dev-&gt;dev,
					   &amp;hidpp-&gt;battery.desc, cfg);

So now we have registered 2 power supplies for the same battery,
which looks a bit weird from userspace's pov but this is not even
the really big problem.

Notice how:

1. This is all devm-maganaged
2. The hidpp-&gt;battery.desc struct is shared between the 2 power supplies
3. hidpp-&gt;battery.desc.properties points to the result from the second
   devm_kmemdup()

This causes a use after free scenario on USB disconnect of the receiver:
1. The last registered power supply class device gets unregistered
2. The memory from the last devm_kmemdup() call gets freed,
   hidpp-&gt;battery.desc.properties now points to freed memory
3. The first registered power supply class device gets unregistered,
   this involves sending a remove uevent to userspace which invokes
   power_supply_uevent() to fill the uevent data
4. power_supply_uevent() uses hidpp-&gt;battery.desc.properties which
   now points to freed memory leading to backtraces like this one:

Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08
...
Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event
Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0
...
Sep 22 20:01:35 eric kernel:  ? asm_exc_page_fault+0x26/0x30
Sep 22 20:01:35 eric kernel:  ? power_supply_uevent+0xee/0x1d0
Sep 22 20:01:35 eric kernel:  ? power_supply_uevent+0x10d/0x1d0
Sep 22 20:01:35 eric kernel:  dev_uevent+0x10f/0x2d0
Sep 22 20:01:35 eric kernel:  kobject_uevent_env+0x291/0x680
Sep 22 20:01:35 eric kernel:  
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-52478</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/srso: Add SRSO mitigation for Hygon processors

Add mitigation for the speculative return stack overflow vulnerability
which exists on Hygon processors too.</Note>
    </Notes>
    <CVE>CVE-2023-52482</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range

When running an SVA case, the following soft lockup is triggered:
--------------------------------------------------------------------
watchdog: BUG: soft lockup - CPU#244 stuck for 26s!
pstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
pc : arm_smmu_cmdq_issue_cmdlist+0x178/0xa50
lr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50
sp : ffff8000d83ef290
x29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000
x26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000
x23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0
x20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0
x14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfa
x5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a
x2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001
Call trace:
 arm_smmu_cmdq_issue_cmdlist+0x178/0xa50
 __arm_smmu_tlb_inv_range+0x118/0x254
 arm_smmu_tlb_inv_range_asid+0x6c/0x130
 arm_smmu_mm_invalidate_range+0xa0/0xa4
 __mmu_notifier_invalidate_range_end+0x88/0x120
 unmap_vmas+0x194/0x1e0
 unmap_region+0xb4/0x144
 do_mas_align_munmap+0x290/0x490
 do_mas_munmap+0xbc/0x124
 __vm_munmap+0xa8/0x19c
 __arm64_sys_munmap+0x28/0x50
 invoke_syscall+0x78/0x11c
 el0_svc_common.constprop.0+0x58/0x1c0
 do_el0_svc+0x34/0x60
 el0_svc+0x2c/0xd4
 el0t_64_sync_handler+0x114/0x140
 el0t_64_sync+0x1a4/0x1a8
--------------------------------------------------------------------

Note that since 6.6-rc1 the arm_smmu_mm_invalidate_range above is renamed
to "arm_smmu_mm_arch_invalidate_secondary_tlbs", yet the problem remains.

The commit 06ff87bae8d3 ("arm64: mm: remove unused functions and variable
protoypes") fixed a similar lockup on the CPU MMU side. Yet, it can occur
to SMMU too, since arm_smmu_mm_arch_invalidate_secondary_tlbs() is called
typically next to MMU tlb flush function, e.g.
	tlb_flush_mmu_tlbonly {
		tlb_flush {
			__flush_tlb_range {
				// check MAX_TLBI_OPS
			}
		}
		mmu_notifier_arch_invalidate_secondary_tlbs {
			arm_smmu_mm_arch_invalidate_secondary_tlbs {
				// does not check MAX_TLBI_OPS
			}
		}
	}

Clone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in an
SVA case SMMU uses the CPU page table, so it makes sense to align with the
tlbflush code. Then, replace per-page TLBI commands with a single per-asid
TLBI command, if the request size hits this threshold.</Note>
    </Notes>
    <CVE>CVE-2023-52484</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

wifi: mac80211: fix potential key use-after-free

When ieee80211_key_link() is called by ieee80211_gtk_rekey_add()
but returns 0 due to KRACK protection (identical key reinstall),
ieee80211_gtk_rekey_add() will still return a pointer into the
key, in a potential use-after-free. This normally doesn't happen
since it's only called by iwlwifi in case of WoWLAN rekey offload
which has its own KRACK protection, but still better to fix, do
that by returning an error code and converting that to success on
the cfg80211 boundary only, leaving the error for bad callers of
ieee80211_gtk_rekey_add().</Note>
    </Notes>
    <CVE>CVE-2023-52530</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: Fix a memory corruption issue

A few lines above, space is kzalloc()'ed for:
	sizeof(struct iwl_nvm_data) +
	sizeof(struct ieee80211_channel) +
	sizeof(struct ieee80211_rate)

'mvm-&gt;nvm_data' is a 'struct iwl_nvm_data', so it is fine.

At the end of this structure, there is the 'channels' flex array.
Each element is of type 'struct ieee80211_channel'.
So only 1 element is allocated in this array.

When doing:
  mvm-&gt;nvm_data-&gt;bands[0].channels = mvm-&gt;nvm_data-&gt;channels;
We point at the first element of the 'channels' flex array.
So this is fine.

However, when doing:
  mvm-&gt;nvm_data-&gt;bands[0].bitrates =
			(void *)((u8 *)mvm-&gt;nvm_data-&gt;channels + 1);
because of the "(u8 *)" cast, we add only 1 to the address of the beginning
of the flex array.

It is likely that we want point at the 'struct ieee80211_rate' allocated
just after.

Remove the spurious casting so that the pointer arithmetic works as
expected.</Note>
    </Notes>
    <CVE>CVE-2023-52531</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: mana: Fix TX CQE error handling

For an unknown TX CQE error type (probably from a newer hardware),
still free the SKB, update the queue tail, etc., otherwise the
accounting will be wrong.

Also, TX errors can be triggered by injecting corrupted packets, so
replace the WARN_ONCE to ratelimited error logging.</Note>
    </Notes>
    <CVE>CVE-2023-52532</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iommu/vt-d: Avoid memory allocation in iommu_suspend()

The iommu_suspend() syscore suspend callback is invoked with IRQ disabled.
Allocating memory with the GFP_KERNEL flag may re-enable IRQs during
the suspend callback, which can cause intermittent suspend/hibernation
problems with the following kernel traces:

Calling iommu_suspend+0x0/0x1d0
------------[ cut here ]------------
WARNING: CPU: 0 PID: 15 at kernel/time/timekeeping.c:868 ktime_get+0x9b/0xb0
...
CPU: 0 PID: 15 Comm: rcu_preempt Tainted: G     U      E      6.3-intel #r1
RIP: 0010:ktime_get+0x9b/0xb0
...
Call Trace:
 &lt;IRQ&gt;
 tick_sched_timer+0x22/0x90
 ? __pfx_tick_sched_timer+0x10/0x10
 __hrtimer_run_queues+0x111/0x2b0
 hrtimer_interrupt+0xfa/0x230
 __sysvec_apic_timer_interrupt+0x63/0x140
 sysvec_apic_timer_interrupt+0x7b/0xa0
 &lt;/IRQ&gt;
 &lt;TASK&gt;
 asm_sysvec_apic_timer_interrupt+0x1f/0x30
...
------------[ cut here ]------------
Interrupts enabled after iommu_suspend+0x0/0x1d0
WARNING: CPU: 0 PID: 27420 at drivers/base/syscore.c:68 syscore_suspend+0x147/0x270
CPU: 0 PID: 27420 Comm: rtcwake Tainted: G     U  W   E      6.3-intel #r1
RIP: 0010:syscore_suspend+0x147/0x270
...
Call Trace:
 &lt;TASK&gt;
 hibernation_snapshot+0x25b/0x670
 hibernate+0xcd/0x390
 state_store+0xcf/0xe0
 kobj_attr_store+0x13/0x30
 sysfs_kf_write+0x3f/0x50
 kernfs_fop_write_iter+0x128/0x200
 vfs_write+0x1fd/0x3c0
 ksys_write+0x6f/0xf0
 __x64_sys_write+0x1d/0x30
 do_syscall_64+0x3b/0x90
 entry_SYSCALL_64_after_hwframe+0x72/0xdc

Given that only 4 words memory is needed, avoid the memory allocation in
iommu_suspend().</Note>
    </Notes>
    <CVE>CVE-2023-52559</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

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">NSS was susceptible to a timing side-channel attack when performing RSA decryption. This attack could potentially allow an attacker to recover the private data. This vulnerability affects Firefox &lt; 124, Firefox ESR &lt; 115.9, and Thunderbird &lt; 115.9.</Note>
    </Notes>
    <CVE>CVE-2023-5388</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 that the response times to malformed ciphertexts in RSA-PSK ClientKeyExchange differ from response times of ciphertexts with correct PKCS#1 v1.5 padding.</Note>
    </Notes>
    <CVE>CVE-2023-5981</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An out-of-bounds access vulnerability involving netfilter was reported and fixed as: f1082dd31fe4 (netfilter: nf_tables: Reject tables of unsupported family); While creating a new netfilter table, lack of a safeguard against invalid nf_tables family (pf) values within `nf_tables_newtable` function enables an attacker to achieve out-of-bounds access.</Note>
    </Notes>
    <CVE>CVE-2023-6040</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 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-6536</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 found in the CPython `tempfile.TemporaryDirectory` class affecting versions 3.12.1, 3.11.7, 3.10.13, 3.9.18, and 3.8.18 and prior.

The tempfile.TemporaryDirectory class would dereference symlinks during cleanup of permissions-related errors. This means users which can run privileged programs are potentially able to modify permissions of files referenced by symlinks in some circumstances.
</Note>
    </Notes>
    <CVE>CVE-2023-6597</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.

The function nft_pipapo_walk did not skip inactive elements during set walk which could lead double deactivations of PIPAPO (Pile Packet Policies) elements, leading to use-after-free.

We recommend upgrading past commit 317eb9685095678f2c9f5a8189de698c5354316a.

</Note>
    </Notes>
    <CVE>CVE-2023-6817</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 problem was found in ida_free in lib/idr.c in the Linux Kernel. This issue may allow an attacker using this library to cause a denial of service problem due to a missing check at a function return.</Note>
    </Notes>
    <CVE>CVE-2023-6915</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Debian's cpio contains a path traversal vulnerability. This issue was introduced by reverting CVE-2015-1197 patches which had caused a regression in --no-absolute-filenames. Upstream has since provided a proper fix to --no-absolute-filenames.</Note>
    </Notes>
    <CVE>CVE-2023-7207</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 vulnerability was found in vhost_new_msg in drivers/vhost/vhost.c in the Linux kernel, which does not properly initialize memory in messages passed between virtual guests and the host operating system in the vhost/vhost.c:vhost_new_msg() function. This issue can allow local privileged users to read some kernel memory contents when reading from the /dev/vhost-net device file.</Note>
    </Notes>
    <CVE>CVE-2024-0340</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 vulnerability was found in GnuTLS. The response times to malformed ciphertexts in RSA-PSK ClientKeyExchange differ from the response times of ciphertexts with correct PKCS#1 v1.5 padding. This issue may allow a remote attacker to perform a timing side-channel attack in the RSA-PSK key exchange, potentially leading to the leakage of sensitive data. CVE-2024-0553 is designated as an incomplete resolution for CVE-2023-5981.</Note>
    </Notes>
    <CVE>CVE-2024-0553</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An out-of-bounds memory read flaw was found in receive_encrypted_standard in fs/smb/client/smb2ops.c in the SMB Client sub-component in the Linux Kernel. This issue occurs due to integer underflow on the memcpy length, leading to a denial of service.</Note>
    </Notes>
    <CVE>CVE-2024-0565</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was found in GnuTLS, where a cockpit (which uses gnuTLS) rejects a certificate chain with distributed trust. This issue occurs when validating a certificate chain with cockpit-certificate-ensure. This flaw allows an unauthenticated, remote client or attacker to initiate a denial of service attack.</Note>
    </Notes>
    <CVE>CVE-2024-0567</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 Netfilter subsystem in the Linux kernel. The issue is in the nft_byteorder_eval() function, where the code iterates through a loop and writes to the `dst` array. On each iteration, 8 bytes are written, but `dst` is an array of u32, so each element only has space for 4 bytes. That means every iteration overwrites part of the previous element corrupting this array of u32. This flaw allows a local user to cause a denial of service or potentially break NetFilter functionality.</Note>
    </Notes>
    <CVE>CVE-2024-0607</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A denial of service vulnerability was found in tipc_crypto_key_revoke in net/tipc/crypto.c in the Linux kernel's TIPC subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.</Note>
    </Notes>
    <CVE>CVE-2024-0641</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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: Processing a maliciously formatted PKCS12 file may lead OpenSSL
to crash leading to a potential Denial of Service attack

Impact summary: Applications loading files in the PKCS12 format from untrusted
sources might terminate abruptly.

A file in PKCS12 format can contain certificates and keys and may come from an
untrusted source. The PKCS12 specification allows certain fields to be NULL, but
OpenSSL does not correctly check for this case. This can lead to a NULL pointer
dereference that results in OpenSSL crashing. If an application processes PKCS12
files from an untrusted source using the OpenSSL APIs then that application will
be vulnerable to this issue.

OpenSSL APIs that are vulnerable to this are: PKCS12_parse(),
PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes()
and PKCS12_newpass().

We have also fixed a similar issue in SMIME_write_PKCS7(). However since this
function is related to writing data we do not consider it security significant.

The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue.</Note>
    </Notes>
    <CVE>CVE-2024-0727</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 use-after-free flaw was found in the __ext4_remount in fs/ext4/super.c in ext4 in the Linux kernel. This flaw allows a local user to cause an information leak problem while freeing the old quota file names before a potential failure, leading to a use-after-free.</Note>
    </Notes>
    <CVE>CVE-2024-0775</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.

The nft_setelem_catchall_deactivate() function checks whether the catch-all set element is active in the current generation instead of the next generation before freeing it, but only flags it inactive in the next generation, making it possible to free the element multiple times, leading to a double free vulnerability.

We recommend upgrading past commit b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7.

</Note>
    </Notes>
    <CVE>CVE-2024-1085</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.

The nft_verdict_init() function allows positive values as drop error within the hook verdict, and hence the nf_hook_slow() function can cause a double free vulnerability when NF_DROP is issued with a drop error which resembles NF_ACCEPT.

We recommend upgrading past commit f342de4e2f33e0e39165d8639387aa6c19dff660.

</Note>
    </Notes>
    <CVE>CVE-2024-1086</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 reported in the Open vSwitch sub-component in the Linux Kernel. The flaw occurs when a recursive operation of code push recursively calls into the code block. The OVS module does not validate the stack depth, pushing too many frames and causing a stack overflow. As a result, this can lead to a crash or other related issues.</Note>
    </Notes>
    <CVE>CVE-2024-1151</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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">runc is a CLI tool for spawning and running containers on Linux according to the OCI specification. In runc 1.1.11 and earlier, due to an internal file descriptor leak, an attacker could cause a newly-spawned container process (from runc exec) to have a working directory in the host filesystem namespace, allowing for a container escape by giving access to the host filesystem ("attack 2"). The same attack could be used by a malicious image to allow a container process to gain access to the host filesystem through runc run ("attack 1"). Variants of attacks 1 and 2 could be also be used to overwrite semi-arbitrary host binaries, allowing for complete container escapes ("attack 3a" and "attack 3b"). runc 1.1.12 includes patches for this issue. </Note>
    </Notes>
    <CVE>CVE-2024-21626</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">Syndic cache directory creation is vulnerable to a directory traversal attack in salt project which can lead a malicious attacker to create an arbitrary directory on a Salt master.</Note>
    </Notes>
    <CVE>CVE-2024-22231</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 specially crafted url can be created which leads to a directory traversal in the salt file server.
A malicious user can read an arbitrary file from a Salt master's filesystem.</Note>
    </Notes>
    <CVE>CVE-2024-22232</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Vim before 9.0.2142 has a stack-based buffer overflow because did_set_langmap in map.c calls sprintf to write to the error buffer that is passed down to the option callback functions.</Note>
    </Notes>
    <CVE>CVE-2024-22667</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. Two malicious build steps running in parallel sharing the same cache mounts with subpaths could cause a race condition that can lead to files from the host system being accessible to the build container. The issue has been fixed in v0.12.5. Workarounds include, avoiding using BuildKit frontend from an untrusted source or building an untrusted Dockerfile containing cache mounts with --mount=type=cache,source=... options.
</Note>
    </Notes>
    <CVE>CVE-2024-23651</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">BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. A malicious BuildKit frontend or Dockerfile using RUN --mount could trick the feature that removes empty files created for the mountpoints into removing a file outside the container, from the host system. The issue has been fixed in v0.12.5. Workarounds include avoiding using BuildKit frontends from an untrusted source or building an untrusted Dockerfile containing RUN --mount feature.</Note>
    </Notes>
    <CVE>CVE-2024-23652</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. In addition to running containers as build steps, BuildKit also provides APIs for running interactive containers based on built images. It was possible to use these APIs to ask BuildKit to run a container with elevated privileges. Normally, running such containers is only allowed if special `security.insecure` entitlement is enabled both by buildkitd configuration and allowed by the user initializing the build request. The issue has been fixed in v0.12.5 . Avoid using BuildKit frontends from untrusted sources. 
</Note>
    </Notes>
    <CVE>CVE-2024-23653</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In rds_recv_track_latency in net/rds/af_rds.c in the Linux kernel through 6.7.1, there is an off-by-one error for an RDS_MSG_RX_DGRAM_TRACE_MAX comparison, resulting in out-of-bounds access.</Note>
    </Notes>
    <CVE>CVE-2024-23849</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="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">A race condition was found in the Linux kernel's bluetooth device driver in {min,max}_key_size_set() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.




</Note>
    </Notes>
    <CVE>CVE-2024-24860</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 libxml2 before 2.11.7 and 2.12.x before 2.12.5. When using the XML Reader interface with DTD validation and XInclude expansion enabled, processing crafted XML documents can lead to an xmlValidatePopElement use-after-free.</Note>
    </Notes>
    <CVE>CVE-2024-25062</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 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:

tls: fix race between tx work scheduling and socket close

Similarly to previous commit, the submitting thread (recvmsg/sendmsg)
may exit as soon as the async crypto handler calls complete().
Reorder scheduling the work before calling complete().
This seems more logical in the first place, as it's
the inverse order of what the submitting thread will do.</Note>
    </Notes>
    <CVE>CVE-2024-26585</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mlxsw: spectrum_acl_tcam: Fix stack corruption

When tc filters are first added to a net device, the corresponding local
port gets bound to an ACL group in the device. The group contains a list
of ACLs. In turn, each ACL points to a different TCAM region where the
filters are stored. During forwarding, the ACLs are sequentially
evaluated until a match is found.

One reason to place filters in different regions is when they are added
with decreasing priorities and in an alternating order so that two
consecutive filters can never fit in the same region because of their
key usage.

In Spectrum-2 and newer ASICs the firmware started to report that the
maximum number of ACLs in a group is more than 16, but the layout of the
register that configures ACL groups (PAGT) was not updated to account
for that. It is therefore possible to hit stack corruption [1] in the
rare case where more than 16 ACLs in a group are required.

Fix by limiting the maximum ACL group size to the minimum between what
the firmware reports and the maximum ACLs that fit in the PAGT register.

Add a test case to make sure the machine does not crash when this
condition is hit.

[1]
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120
[...]
 dump_stack_lvl+0x36/0x50
 panic+0x305/0x330
 __stack_chk_fail+0x15/0x20
 mlxsw_sp_acl_tcam_group_update+0x116/0x120
 mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110
 mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20
 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0
 mlxsw_sp_acl_rule_add+0x47/0x240
 mlxsw_sp_flower_replace+0x1a9/0x1d0
 tc_setup_cb_add+0xdc/0x1c0
 fl_hw_replace_filter+0x146/0x1f0
 fl_change+0xc17/0x1360
 tc_new_tfilter+0x472/0xb90
 rtnetlink_rcv_msg+0x313/0x3b0
 netlink_rcv_skb+0x58/0x100
 netlink_unicast+0x244/0x390
 netlink_sendmsg+0x1e4/0x440
 ____sys_sendmsg+0x164/0x260
 ___sys_sendmsg+0x9a/0xe0
 __sys_sendmsg+0x7a/0xc0
 do_syscall_64+0x40/0xe0
 entry_SYSCALL_64_after_hwframe+0x63/0x6b</Note>
    </Notes>
    <CVE>CVE-2024-26586</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Reject variable offset alu on PTR_TO_FLOW_KEYS

For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off
for validation. However, variable offset ptr alu is not prohibited
for this ptr kind. So the variable offset is not checked.

The following prog is accepted:

  func#0 @0
  0: R1=ctx() R10=fp0
  0: (bf) r6 = r1                       ; R1=ctx() R6_w=ctx()
  1: (79) r7 = *(u64 *)(r6 +144)        ; R6_w=ctx() R7_w=flow_keys()
  2: (b7) r8 = 1024                     ; R8_w=1024
  3: (37) r8 /= 1                       ; R8_w=scalar()
  4: (57) r8 &amp;= 1024                    ; R8_w=scalar(smin=smin32=0,
  smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400))
  5: (0f) r7 += r8
  mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1
  mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &amp;= 1024
  mark_precise: frame0: regs=r8 stack= before 3: (37) r8 /= 1
  mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 = 1024
  6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off
  =(0x0; 0x400)) R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024,
  var_off=(0x0; 0x400))
  6: (79) r0 = *(u64 *)(r7 +0)          ; R0_w=scalar()
  7: (95) exit

This prog loads flow_keys to r7, and adds the variable offset r8
to r7, and finally causes out-of-bounds access:

  BUG: unable to handle page fault for address: ffffc90014c80038
  [...]
  Call Trace:
   &lt;TASK&gt;
   bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline]
   __bpf_prog_run include/linux/filter.h:651 [inline]
   bpf_prog_run include/linux/filter.h:658 [inline]
   bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline]
   bpf_flow_dissect+0x15f/0x350 net/core/flow_dissector.c:991
   bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359
   bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline]
   __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475
   __do_sys_bpf kernel/bpf/syscall.c:5561 [inline]
   __se_sys_bpf kernel/bpf/syscall.c:5559 [inline]
   __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559
   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
   do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83
   entry_SYSCALL_64_after_hwframe+0x63/0x6b

Fix this by rejecting ptr alu with variable offset on flow_keys.
Applying the patch rejects the program with "R7 pointer arithmetic
on flow_keys prohibited".</Note>
    </Notes>
    <CVE>CVE-2024-26589</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix re-attachment branch in bpf_tracing_prog_attach

The following case can cause a crash due to missing attach_btf:

1) load rawtp program
2) load fentry program with rawtp as target_fd
3) create tracing link for fentry program with target_fd = 0
4) repeat 3

In the end we have:

- prog-&gt;aux-&gt;dst_trampoline == NULL
- tgt_prog == NULL (because we did not provide target_fd to link_create)
- prog-&gt;aux-&gt;attach_btf == NULL (the program was loaded with attach_prog_fd=X)
- the program was loaded for tgt_prog but we have no way to find out which one

    BUG: kernel NULL pointer dereference, address: 0000000000000058
    Call Trace:
     &lt;TASK&gt;
     ? __die+0x20/0x70
     ? page_fault_oops+0x15b/0x430
     ? fixup_exception+0x22/0x330
     ? exc_page_fault+0x6f/0x170
     ? asm_exc_page_fault+0x22/0x30
     ? bpf_tracing_prog_attach+0x279/0x560
     ? btf_obj_id+0x5/0x10
     bpf_tracing_prog_attach+0x439/0x560
     __sys_bpf+0x1cf4/0x2de0
     __x64_sys_bpf+0x1c/0x30
     do_syscall_64+0x41/0xf0
     entry_SYSCALL_64_after_hwframe+0x6e/0x76

Return -EINVAL in this situation.</Note>
    </Notes>
    <CVE>CVE-2024-26591</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i2c: i801: Fix block process call transactions

According to the Intel datasheets, software must reset the block
buffer index twice for block process call transactions: once before
writing the outgoing data to the buffer, and once again before
reading the incoming data from the buffer.

The driver is currently missing the second reset, causing the wrong
portion of the block buffer to be read.</Note>
    </Notes>
    <CVE>CVE-2024-26593</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in error path

When calling mlxsw_sp_acl_tcam_region_destroy() from an error path after
failing to attach the region to an ACL group, we hit a NULL pointer
dereference upon 'region-&gt;group-&gt;tcam' [1].

Fix by retrieving the 'tcam' pointer using mlxsw_sp_acl_to_tcam().

[1]
BUG: kernel NULL pointer dereference, address: 0000000000000000
[...]
RIP: 0010:mlxsw_sp_acl_tcam_region_destroy+0xa0/0xd0
[...]
Call Trace:
 mlxsw_sp_acl_tcam_vchunk_get+0x88b/0xa20
 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0
 mlxsw_sp_acl_rule_add+0x47/0x240
 mlxsw_sp_flower_replace+0x1a9/0x1d0
 tc_setup_cb_add+0xdc/0x1c0
 fl_hw_replace_filter+0x146/0x1f0
 fl_change+0xc17/0x1360
 tc_new_tfilter+0x472/0xb90
 rtnetlink_rcv_msg+0x313/0x3b0
 netlink_rcv_skb+0x58/0x100
 netlink_unicast+0x244/0x390
 netlink_sendmsg+0x1e4/0x440
 ____sys_sendmsg+0x164/0x260
 ___sys_sendmsg+0x9a/0xe0
 __sys_sendmsg+0x7a/0xc0
 do_syscall_64+0x40/0xe0
 entry_SYSCALL_64_after_hwframe+0x63/0x6b</Note>
    </Notes>
    <CVE>CVE-2024-26595</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache

There is a potential UAF scenario in the case of an LPI translation
cache hit racing with an operation that invalidates the cache, such
as a DISCARD ITS command. The root of the problem is that
vgic_its_check_cache() does not elevate the refcount on the vgic_irq
before dropping the lock that serializes refcount changes.

Have vgic_its_check_cache() raise the refcount on the returned vgic_irq
and add the corresponding decrement after queueing the interrupt.</Note>
    </Notes>
    <CVE>CVE-2024-26598</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:

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:

sched/membarrier: reduce the ability to hammer on sys_membarrier

On some systems, sys_membarrier can be very expensive, causing overall
slowdowns for everything.  So put a lock on the path in order to
serialize the accesses to prevent the ability for this to be called at
too high of a frequency and saturate the machine.</Note>
    </Notes>
    <CVE>CVE-2024-26602</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/fpu: Stop relying on userspace for info to fault in xsave buffer

Before this change, the expected size of the user space buffer was
taken from fx_sw-&gt;xstate_size. fx_sw-&gt;xstate_size can be changed
from user-space, so it is possible construct a sigreturn frame where:

 * fx_sw-&gt;xstate_size is smaller than the size required by valid bits in
   fx_sw-&gt;xfeatures.
 * user-space unmaps parts of the sigrame fpu buffer so that not all of
   the buffer required by xrstor is accessible.

In this case, xrstor tries to restore and accesses the unmapped area
which results in a fault. But fault_in_readable succeeds because buf +
fx_sw-&gt;xstate_size is within the still mapped area, so it goes back and
tries xrstor again. It will spin in this loop forever.

Instead, fault in the maximum size which can be touched by XRSTOR (taken
from fpstate-&gt;user_size).

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

drm/bridge: sii902x: Fix probing race issue

A null pointer dereference crash has been observed rarely on TI
platforms using sii9022 bridge:

[   53.271356]  sii902x_get_edid+0x34/0x70 [sii902x]
[   53.276066]  sii902x_bridge_get_edid+0x14/0x20 [sii902x]
[   53.281381]  drm_bridge_get_edid+0x20/0x34 [drm]
[   53.286305]  drm_bridge_connector_get_modes+0x8c/0xcc [drm_kms_helper]
[   53.292955]  drm_helper_probe_single_connector_modes+0x190/0x538 [drm_kms_helper]
[   53.300510]  drm_client_modeset_probe+0x1f0/0xbd4 [drm]
[   53.305958]  __drm_fb_helper_initial_config_and_unlock+0x50/0x510 [drm_kms_helper]
[   53.313611]  drm_fb_helper_initial_config+0x48/0x58 [drm_kms_helper]
[   53.320039]  drm_fbdev_dma_client_hotplug+0x84/0xd4 [drm_dma_helper]
[   53.326401]  drm_client_register+0x5c/0xa0 [drm]
[   53.331216]  drm_fbdev_dma_setup+0xc8/0x13c [drm_dma_helper]
[   53.336881]  tidss_probe+0x128/0x264 [tidss]
[   53.341174]  platform_probe+0x68/0xc4
[   53.344841]  really_probe+0x188/0x3c4
[   53.348501]  __driver_probe_device+0x7c/0x16c
[   53.352854]  driver_probe_device+0x3c/0x10c
[   53.357033]  __device_attach_driver+0xbc/0x158
[   53.361472]  bus_for_each_drv+0x88/0xe8
[   53.365303]  __device_attach+0xa0/0x1b4
[   53.369135]  device_initial_probe+0x14/0x20
[   53.373314]  bus_probe_device+0xb0/0xb4
[   53.377145]  deferred_probe_work_func+0xcc/0x124
[   53.381757]  process_one_work+0x1f0/0x518
[   53.385770]  worker_thread+0x1e8/0x3dc
[   53.389519]  kthread+0x11c/0x120
[   53.392750]  ret_from_fork+0x10/0x20

The issue here is as follows:

- tidss probes, but is deferred as sii902x is still missing.
- sii902x starts probing and enters sii902x_init().
- sii902x calls drm_bridge_add(). Now the sii902x bridge is ready from
  DRM's perspective.
- sii902x calls sii902x_audio_codec_init() and
  platform_device_register_data()
- The registration of the audio platform device causes probing of the
  deferred devices.
- tidss probes, which eventually causes sii902x_bridge_get_edid() to be
  called.
- sii902x_bridge_get_edid() tries to use the i2c to read the edid.
  However, the sii902x driver has not set up the i2c part yet, leading
  to the crash.

Fix this by moving the drm_bridge_add() to the end of the
sii902x_init(), which is also at the very end of sii902x_probe().</Note>
    </Notes>
    <CVE>CVE-2024-26607</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tomoyo: fix UAF write bug in tomoyo_write_control()

Since tomoyo_write_control() updates head-&gt;write_buf when write()
of long lines is requested, we need to fetch head-&gt;write_buf after
head-&gt;io_sem is held.  Otherwise, concurrent write() requests can
cause use-after-free-write and double-free problems.</Note>
    </Notes>
    <CVE>CVE-2024-26622</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">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">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>
