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

- Fix fips-mode-setup in EFI or Secure Boot mode. [bsc#1227637]  * Rebase crypto-policies-FIPS.patch

- fips-mode-setup: tolerate fips dracut module presence w/o FIPS
  * Fixes the &amp;quot;Inconsistent state detected&amp;quot; warning when disabling
    the FIPS mode [bsc#1236165]
  * Upstream commit [gl#redhat-crypto/fedora-crypto-policies#78773542]
  * Add crypto-policies-fips-mode-setup-dracut.patch

- Remove dangling symlink for the libreswan config [bsc#1236858]

Package docker was updated:

- Update to Docker 27.5.1-ce. See upstream changelog online at  &amp;lt;https://docs.docker.com/engine/release-notes/27/#2741&amp;gt; bsc#1237335
- 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
  * cli-0001-docs-include-required-tools-in-source-tree.patch
- Update to docker-buildx 0.20.1. See upstream changelog online at
  &amp;lt;https://github.com/docker/buildx/releases/tag/v0.20.1&amp;gt;

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

- Update to docker-buildx 0.19.3. See upstream changelog online at
  &amp;lt;https://github.com/docker/buildx/releases/tag/v0.19.3&amp;gt;

- Update to Docker 27.4.0-ce. See upstream changelog online at
  &amp;lt;https://docs.docker.com/engine/release-notes/27/#274&amp;gt;
- Rebase patches:
  * 0001-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  * 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch
  * 0003-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  * 0004-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  * 0005-SLE12-revert-apparmor-remove-version-conditionals-fr.patch
  * cli-0001-docs-include-required-tools-in-source-tree.patch
- Remove upstreamed patches:
  - 0006-bsc1221916-update-to-patched-buildkit-version-to-fix.patch
  - 0007-bsc1214855-volume-use-AtomicWriteFile-to-save-volume.patch

Package dracut was updated:

- Update to version 059+suse.552.g232957b4:  Fixes related to getting live image size (bsc#1235912):
  * fix(livenet): split `imgsize` calculation to avoid misleading error message
  * fix(livenet): check also `content-length` from live image header
  * fix(livenet): propagate error code
  Fixes for booting from iSCSI offload with bnx2i (bsc#1228086):
  * fix(iscsi): attempt iSCSI login before all interfaces are up
  * fix(iscsi): don't require network setup for bnx2i
  Other:
  * fix(dracut): rework timeout for devices added via --mount and --add-device (bsc#1231792)

Package findutils was updated:

- do not crash when file system loop was encountered [bsc#1231472]- added patches
  fix https://git.savannah.gnu.org/cgit/findutils.git/commit/?id=e5d6eb919b9
  + findutils-avoid-crash-system-loop.patch
- modified patches
  % findutils-xautofs.patch (p1)

Package glibc was updated:

- assert-message-allocation.patch: Fix underallocation of abort_msg_s  struct (CVE-2025-0395, bsc#1236282, BZ #32582))

Package google-guest-agent was updated:

- Update to version 20250116.00: (bsc#1236403)  * networkd(vlan): remove the interface in addition to config (#468)
  * Implement support for vlan dynamic removal, update dhclient to remove
    only if configured (#465)
  * Update logging library (#479)
  * Remove Pat from owners file. (#478)

- Update to version 20241209.01: (bsc#1235664)
  * readme: add notes about plugin manager (#476)
  * Update metadata script runner to honor cloud logging config flag (#475)
  * Fixing fallback from systemd-networkd to dhclient (#471)
  * network: fix nmcli check pattern (#472)
  * Update readme with guest agent manager (#469)
  * Add missing packaging spec (#466)
  * Bring back side-by-side packaging (#464)
  * Avoid changing permissions of directory if parent is / (#463)
  * network: force NetworkManager to connect to primary nic (#461)
  * Revert plugin manager packaging (#460)
  * Add GOPATH to PATH in debian build (#459)
  * Add plugin manager to debian build (#457)
  * rpm packaging: fix plugin manager assumptions (#458)
  * packaging: add plugin manager to rhel packaging (#454)

Package google-guest-oslogin was updated:

- Rework SELinux support (bsc#1232553)  * Add pkgconfig(systemd) to BuildRequires for SELinux builds
  * Add policycoreutils to BuildRequires
  * Build and install SELinux module on older distributions as well
    to allow users to use the module with their own SELinux policies
  * Make checkpolicy build dependency unconditional
  * Move oslogin.pp SELinux module into %{selinuxtype} subdirectory
  * Own %{_datadir}/selinux{,/packages} on older distributions
  * Split SELinux support into separate -selinux package
  * Use SELinux RPM macros to install and uninstall SELinux module
  * Use RPM conditional builds to enable SELinux on newer distributions

- Build and install SELinux module (bsc#1232553)

Package google-osconfig-agent was updated:

- Add patch to fix vulnerability when creating log files  * CVE-2024-45339.patch (bsc#1236560, CVE-2024-45339)

Package grub2 was updated:

- Fix zfs.mo not found message when booting on legacy BIOS (bsc#1237865)  * 0001-autofs-Ignore-zfs-not-found.patch

- Cherry-pick upstream XFS fixes
  * 0001-fs-xfs-Add-new-superblock-features-added-in-Linux-6..patch
  * 0002-fs-xfs-Fix-grub_xfs_iterate_dir-return-value-in-case.patch
- Fix &amp;quot;attempt to read of write outside of partition&amp;quot; error message (bsc#1237844)
  * 0003-fs-xfs-fix-large-extent-counters-incompat-feature-su.patch

- Security fixes for 2024
  * 0001-misc-Implement-grub_strlcpy.patch
- Fix CVE-2024-45781 (bsc#1233617)
  * 0002-fs-ufs-Fix-a-heap-OOB-write.patch
- Fix CVE-2024-56737 (bsc#1234958)
- Fix CVE-2024-45782 (bsc#1233615)
  * 0003-fs-hfs-Fix-stack-OOB-write-with-grub_strcpy.patch
- Fix CVE-2024-45780 (bsc#1233614)
  * 0004-fs-tar-Integer-overflow-leads-to-heap-OOB-write.patch
- Fix CVE-2024-45783 (bsc#1233616)
  * 0005-fs-hfsplus-Set-a-grub_errno-if-mount-fails.patch
  * 0006-kern-file-Ensure-file-data-is-set.patch
  * 0007-kern-file-Implement-filesystem-reference-counting.patch
- Fix CVE-2025-0624 (bsc#1236316)
  * 0008-net-Fix-OOB-write-in-grub_net_search_config_file.patch
- Fix CVE-2024-45774 (bsc#1233609)
  * 0009-video-readers-jpeg-Do-not-permit-duplicate-SOF0-mark.patch
- Fix CVE-2024-45775 (bsc#1233610)
  * 0010-commands-extcmd-Missing-check-for-failed-allocation.patch
- Fix CVE-2025-0622 (bsc#1236317)
  * 0011-commands-pgp-Unregister-the-check_signatures-hooks-o.patch
- Fix CVE-2025-0622 (bsc#1236317)
  * 0012-normal-Remove-variables-hooks-on-module-unload.patch
- Fix CVE-2025-0622 (bsc#1236317)
  * 0013-gettext-Remove-variables-hooks-on-module-unload.patch
- Fix CVE-2024-45776 (bsc#1233612)
  * 0014-gettext-Integer-overflow-leads-to-heap-OOB-write-or-.patch
- Fix CVE-2024-45777 (bsc#1233613)
  * 0015-gettext-Integer-overflow-leads-to-heap-OOB-write.patch
- Fix CVE-2025-0690 (bsc#1237012)
  * 0016-commands-read-Fix-an-integer-overflow-when-supplying.patch
- Fix CVE-2025-1118 (bsc#1237013)
  * 0017-commands-minicmd-Block-the-dump-command-in-lockdown-.patch
- Fix CVE-2024-45778 (bsc#1233606)
- Fix CVE-2024-45779 (bsc#1233608)
  * 0018-fs-bfs-Disable-under-lockdown.patch
- Fix CVE-2025-0677 (bsc#1237002)
- Fix CVE-2025-0684 (bsc#1237008)
- Fix CVE-2025-0685 (bsc#1237009)
- Fix CVE-2025-0686 (bsc#1237010)
- Fix CVE-2025-0689 (bsc#1237011)
  * 0019-fs-Disable-many-filesystems-under-lockdown.patch
- Fix CVE-2025-1125 (bsc#1237014)
- Fix CVE-2025-0678 (bsc#1237006)
  * 0020-fs-Prevent-overflows-when-allocating-memory-for-arra.patch
- Bump upstream SBAT generation to 5

- Fix CVE-2024-49504 (bsc#1229163) (bsc#1229164)
- Restrict CLI access if the encrypted root device is automatically unlocked by
  the TPM. LUKS password authentication is required for access to be granted
  * 0001-cli_lock-Add-build-option-to-block-command-line-inte.patch
  * 0002-Requiring-authentication-after-tpm-unlock-for-CLI-ac.patch
- Obsolete, as CLI access is now locked and granted access no longer requires
  the previous restrictions
  * 0002-Restrict-file-access-on-cryptodisk-print.patch
  * 0003-Restrict-ls-and-auto-file-completion-on-cryptodisk-p.patch
- Rediff
  * 0004-Key-revocation-on-out-of-bound-file-access.patch

Package kdump was updated:

- upgrade to version kdump-2.0.6+git25.g1dbf786  * fix bonding options (bsc#1235933)
  * don't use wicked to read bond and bridge config (bsc#1235933)
  * prevent KDUMP_NET_TIMEOUT busy loop when DNS fails
  * limit dump file permissions (bsc#1237497, bsc#1237529)

- upgrade to version kdump-2.0.6+git20.gf8ecc01:
  * fix KDUMP_AUTO_RESIZE (bsc#1236921)

- upgrade to version kdump-2.0.6+git20.gf8ecc01:
  * dracut: fix filtering ro keys in kdump_bond_config (bsc#1233137)

Package kernel-default was updated:

- initcall_blacklist: Does not allow kernel_lockdown be  blacklisted (bsc#1237521).
- commit c830a3e

- drm/amd/display: Fix null check for pipe_ctx-&amp;gt;plane_state in
  resource_build_scaling_params (git-fixes).
- drm/sched: Fix preprocessor guard (git-fixes).
- wifi: cfg80211: regulatory: improve invalid hints checking
  (git-fixes).
- wifi: iwlwifi: limit printed string from FW file (git-fixes).
- wifi: iwlwifi: mvm: don't try to talk to a dead firmware
  (git-fixes).
- wifi: nl80211: reject cooked mode if it is set along with
  other flags (git-fixes).
- Bluetooth: Add check for mgmt_alloc_skb() in
  mgmt_device_connected() (git-fixes).
- Bluetooth: Add check for mgmt_alloc_skb() in mgmt_remote_name()
  (git-fixes).
- bluetooth: btusb: Initialize .owner field of
  force_poll_sync_fops (git-fixes).
- commit ba6baa3

- net: hns3: fix oops when unload drivers paralleling
  (CVE-2025-21802 bsc#1238751).
- commit 1e9156e

- NFSD: fix hang in nfsd4_shutdown_callback (CVE-2025-21795
  bsc#1238759).
- commit b38b339

- vxlan: check vxlan_vnigroup_init() return value (CVE-2025-21790
  bsc#1238753).
- commit f088d3b

- clocksource: Use migrate_disable() to avoid calling
  get_random_u32() in atomic context (CVE-2025-21767 bsc#1238509).
- commit 63a12d3

- vxlan: Fix uninit-value in vxlan_vnifilter_dump()
  (CVE-2025-21716 bsc#1237891).
- commit dd55756

- mptcp: handle fastopen disconnect correctly (CVE-2025-21705
  bsc#1238525).
- commit fd8b648

- exfat: fix timing of synchronizing bitmap and inode
  (bsc#1237356).
- exfat: fix appending discontinuous clusters to empty file
  (bsc#1237356).
- commit 7d766d0

- smb: client: fix oops due to unset link speed (CVE-2025-21725
  bsc#1238877).
- commit b5023ae

- exfat: do not zero the extended part (bsc#1237356).
- commit 156857e

- ipmr: do not call mr_mfc_uses_dev() for unres entries
  (CVE-2025-21719 bsc#1238860).
- commit d4d6c1b

- net: davicom: fix UAF in dm9000_drv_remove (CVE-2025-21715
  bsc#1237889).
- commit 0308747

- iommufd/iova_bitmap: Fix shift-out-of-bounds in
  iova_bitmap_offset_to_index() (CVE-2025-21724 bsc#1238863).
- commit fa2cf3e

- net: ethernet: ti: am65-cpsw: fix freeing IRQ in
  am65_cpsw_nuss_remove_tx_chns() (CVE-2025-21799 bsc#1238739).
- commit b9602c4

- rpm/split-modules: Fix optional splitting with usrmerge (bsc#1238570)
- commit 8be63c4

- scsi: hisi_sas: Remove redundant checks for automatic debugfs
  dump (git-fixes).
- scsi: hisi_sas: Fix a deadlock issue related to automatic dump
  (git-fixes).
- commit 2531f6e

- scsi: core: Do not retry I/Os during depopulation (git-fixes).
- commit 4c3f2b6

- scsi: mpi3mr: Fix possible crash when setting up bsg fails
  (git-fixes).
- commit f1f6d56

- scsi: myrb: Remove dead code (git-fixes).
- commit 11c2ac0

- scsi: iscsi: Fix redundant response for
  ISCSI_UEVENT_GET_HOST_STATS request (git-fixes).
- commit 3d258a5

- scsi: scsi_debug: Fix hrtimer support for ndelay (git-fixes).
- commit 6998b85

- scsi: mpi3mr: Start controller indexing from 0 (git-fixes).
- commit 13d0e59

- scsi: megaraid_sas: Fix for a potential deadlock (git-fixes).
- commit 330c415

- scsi: qla1280: Fix hw revision numbering for ISP1020/1040
  (git-fixes).
- commit f2ba519

- scsi: st: Add MTIOCGET and MTLOAD to ioctls allowed after
  device reset (git-fixes).
- commit 1ead6e0

- scsi: st: Don't modify unknown block number in MTIOCGET
  (git-fixes).
- commit fb5d2a0

- scsi: sg: Enable runtime power management (git-fixes).
- Refresh
  patches.suse/scsi-sg-Fix-slab-use-after-free-read-in-sg_release.patch.
- commit 89afcac

- scsi: hisi_sas: Enable all PHYs that are not disabled by user
  during controller reset (git-fixes).
- commit 27a4afa

- scsi: mpi3mr: Use ida to manage mrioc ID (git-fixes).
- commit 782dd6e

- scsi: hisi_sas: Allocate DFX memory during dump trigger
  (git-fixes).
- Refresh patches.suse/scsi-hisi_sas-Create-all-dump-files-during-debugfs-initialization.patch
- commit 9b4cb76

- scsi: hisi_sas: Directly call register snapshot instead of
  using workqueue (git-fixes).
- commit 1286dd4

- scsi: qedi: Fix potential deadlock on &amp;amp;qedi_percpu-&amp;gt;p_work_lock
  (git-fixes).
- commit 7c8c098

- ice: pass VSI pointer into ice_vc_isvalid_q_id (bsc#1237848
  bsc#1230497).
- commit df06d93

- packaging: Turn gcc version into config.sh variable
  Fixes: 51dacec21eb1 (&amp;quot;Use gcc-13 for build on SLE16 (jsc#PED-10028).&amp;quot;)
- commit 011d54b

- arm64: hugetlb: Fix flush_hugetlb_tlb_range() invalidation level (git-fixes)
- commit 1ccb01b

- arm64: hugetlb: enable __HAVE_ARCH_FLUSH_HUGETLB_TLB_RANGE (git-fixes)
- commit a9f56ff

- arm64: hugetlb: Fix huge_ptep_get_and_clear() for non-present ptes (git-fixes)
- commit 85cc91e

- mm: hugetlb: Add huge page size param to huge_ptep_get_and_clear() (git-fixes)
- commit 67ea9f3

- mm: hugetlb: add huge page size param to set_huge_pte_at() (git-fixes).
  Refresh patches.suse/s390-mm-Fix-clearing-storage-keys-for-huge-pages.patch.
- commit f491ee9

- RDMA/mana_ib: Allocate PAGE aligned doorbell index (git-fixes).
- KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC
  isn't in-kernel (git-fixes).
- commit 82bdecd

- rpm/kernel-docs.spec.in: Workaround for reproducible builds (bsc#1238303)
- commit 1f1e842

- Update
  patches.suse/s390-pci-Fix-SR-IOV-for-PFs-initially-in-standby.patch
  (git-fixes bsc#1236752 bsc#1238368).
- commit bf69596

- s390/pci: Fix handling of isolated VFs (git-fixes bsc#1238368).
- s390/pci: Pull search for parent PF out of
  zpci_iov_setup_virtfn() (git-fixes bsc#1238368).
- commit 0745d9f

- bpf: Send signals asynchronously if !preemptible (git-fixes
  bsc#1237879 CVE-2025-21728).
- commit 180a0da

- rxrpc: Fix missing locking causing hanging calls (git-fixes
  bsc#1233483 CVE-2024-50294).
- commit d2475e0

- scsi: lpfc: Copyright updates for 14.4.0.8 patches
  (bsc#1238347).
- scsi: lpfc: Update lpfc version to 14.4.0.8 (bsc#1238347).
- scsi: lpfc: Handle duplicate D_IDs in ndlp search-by D_ID
  routine (bsc#1238347).
- scsi: lpfc: Ignore ndlp rport mismatch in dev_loss_tmo callbk
  (bsc#1238347).
- scsi: lpfc: Free phba irq in lpfc_sli4_enable_msi() when
  pci_irq_vector() fails (bsc#1238347).
- scsi: lpfc: Reduce log message generation during ELS ring
  clean up (bsc#1238347).
- commit 0a7ad68

- nvme/ioctl: add missing space in err message (git-fixes).
- nvme-tcp: fix connect failure on receiving partial ICResp PDU
  (git-fixes).
- nvme: tcp: Fix compilation warning with W=1 (git-fixes).
- nvmet: Fix crash when a namespace is disabled (git-fixes).
- nvme-fc: use ctrl state getter (git-fixes).
- nvme: make nvme_tls_attrs_group static (git-fixes).
- nvme: handle connectivity loss in nvme_set_queue_count
  (git-fixes).
- nvme-pci: Add TUXEDO IBP Gen9 to Samsung sleep quirk
  (git-fixes).
- nvme-pci: Add TUXEDO InfinityFlex to Samsung sleep quirk
  (git-fixes).
- commit 7d2a8bd

- Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync
  (CVE-2024-50029 bsc#1231949).
- commit 64f3840

- gup: make the stack expansion warning a bit more targeted
  (bsc#1238214).
- commit feae374

- phy: tegra: xusb: reset VBUS &amp;amp; ID OVERRIDE (git-fixes).
- phy: exynos5-usbdrd: fix MPLL_MULTIPLIER and SSC_REFCLKSEL
  masks in refclk (git-fixes).
- phy: rockchip: naneng-combphy: compatible reset with old DT
  (git-fixes).
- commit 92e733c

- i2c: ls2x: Fix frequency division register access (git-fixes).
- i2c: npcm: disable interrupt enable bit before devm_request_irq
  (git-fixes).
- commit 6c35b3b

- drm/amdgpu: disable BAR resize on Dell G5 SE (git-fixes).
- amdgpu/pm/legacy: fix suspend/resume issues (git-fixes).
- commit d778b71

- soc/mediatek: mtk-devapc: Convert to platform remove callback
  returning void (stable-fixes).
- Refresh
  patches.suse/soc-mediatek-mtk-devapc-Fix-leaking-IO-map-on-error-.patch.
- commit b320307

- smb: client: Fix netns refcount imbalance causing leaks and
  use-after-free (git-fixes).
- commit 7fb2f0e

- scsi: core: Clear driver private data when retrying request
  (git-fixes).
- md/md-bitmap: add 'sync_size' into struct md_bitmap_stats
  (git-fixes).
- md/md-cluster: fix spares warnings for __le64 (git-fixes).
- md/md-bitmap: replace md_bitmap_status() with a new helper
  md_bitmap_get_stats() (git-fixes).
- scsi: core: Handle depopulation and restoration in progress
  (git-fixes).
- commit 72dfeb6

- cifs: Fix parsing reparse point with native symlink in SMB1
  non-UNICODE session (git-fixes).
- commit 37da1d3

- ALSA: usb-audio: Re-add sample rate quirk for Pioneer
  DJM-900NXS2 (stable-fixes).
- commit 1b4de08

- usbnet: gl620a: fix endpoint checking in genelink_bind()
  (git-fixes).
- Bluetooth: L2CAP: Fix L2CAP_ECRED_CONN_RSP response (git-fixes).
- ASoC: es8328: fix route from DAC to output (git-fixes).
- ALSA: hda/realtek: Fix microphone regression on ASUS N705UD
  (git-fixes).
- ALSA: hda/realtek: Fix wrong mic setup for ASUS VivoBook 15
  (git-fixes).
- ALSA: usb-audio: Avoid dropping MIDI events at closing multiple
  ports (git-fixes).
- soc: loongson: loongson2_guts: Add check for devm_kstrdup()
  (git-fixes).
- drm/i915/dp: Fix error handling during 128b/132b link training
  (stable-fixes).
- drm/i915: Make sure all planes in use by the joiner have their
  crtc included (stable-fixes).
- soc: mediatek: mtk-devapc: Fix leaking IO map on driver remove
  (git-fixes).
- drm/msm/gem: prevent integer overflow in msm_ioctl_gem_submit()
  (git-fixes).
- drm/msm/gem: Demote userspace errors to DRM_UT_DRIVER
  (stable-fixes).
- commit 73ebe5d

- md/raid5: Wait sync io to finish before changing group cnt
  (git-fixes).
- md/md-bitmap: Add missing destroy_work_on_stack() (git-fixes).
- md: Don't flush sync_work in md_write_start() (git-fixes).
- md: convert comma to semicolon (git-fixes).
- md/raid1: don't free conf on raid0_run failure (git-fixes).
- md/raid0: don't free conf on raid0_run failure (git-fixes).
- commit b66645f

- kabi: hide adding RCU head into struct netdev_name_node
  (bsc#1233749).
- net: free altname using an RCU callback (bsc#1233749).
- net: fix removing a namespace with conflicting altnames
  (bsc#1233749).
- net: do not send a MOVE event when netdev changes netns
  (bsc#1233749).
- net: Fix undefined behavior in netdev name allocation
  (bsc#1233749).
- net: remove else after return in dev_prep_valid_name()
  (bsc#1233749).
- net: remove dev_valid_name() check from __dev_alloc_name()
  (bsc#1233749).
- net: trust the bitmap in __dev_alloc_name() (bsc#1233749).
- net: reduce indentation of __dev_alloc_name() (bsc#1233749).
- net: make dev_alloc_name() call dev_prep_valid_name()
  (bsc#1233749).
- net: don't use input buffer of __dev_alloc_name() as a scratch
  space (bsc#1233749).
- net: move altnames together with the netdevice (bsc#1233749).
- net: avoid UAF on deleted altname (bsc#1233749).
- net: check for altname conflicts when changing netdev's netns
  (bsc#1233749).
- net: fix ifname in netlink ntf during netns move (bsc#1233749).
- net: core: Use the bitmap API to allocate bitmaps (bsc#1233749).
- commit ff5990f

- smb: client: handle STATUS_IO_REPARSE_TAG_NOT_HANDLED
  (git-fixes).
- commit 23d3ebd

- smb: client: handle path separator of created SMB symlinks
  (git-fixes).
- Refresh
  patches.suse/smb-client-move-most-of-reparse-point-handling-code-to-common-file.patch.
- commit c241ea6

- smb: client: ignore unhandled reparse tags (git-fixes).
- commit f2d26a5

- smb: client: fix double put of @cfile in smb2_rename_path()
  (git-fixes).
- commit 4ac349c

- smb: client: fix double put of @cfile in smb2_set_path_size()
  (git-fixes).
- commit 647e9ab

- cifs: Remove intermediate object of failed create reparse call
  (git-fixes).
- commit fa14b80

- ptr_ring: do not block hard interrupts in
  ptr_ring_resize_multiple() (CVE-2024-57994 bsc#1237901).
- commit e5a0226

- printk: Fix signed integer overflow when defining
  LOG_BUF_LEN_MAX (bsc#1237950).
- commit 1ff6bc3

- add nf_tables for iptables non-legacy network handling
  This is needed for example by docker on the Alpine Linux distribution,
  but can also be used on openSUSE.
- commit f9b0903

- af_packet: do not call packet_read_pending() from
  tpacket_destruct_skb() (bsc#1237849).
- commit 4ff6762

- zram: fix potential UAF of zram table (git-fixes).
- commit b9770a4

- Fix memory-hotplug regression (bsc#1237504)
  Refreshed
  patches.suse/mm-memory_hotplug-add-missing-mem_hotplug_lock.patch
- commit 248260f

- kernel-source: Also replace bin/env
- commit dc2037c

- net: do not delay dst_entries_add() in dst_release()
  (CVE-2024-50036 bsc#1231912).
- commit 1203cd1

- RDMA/bnxt_re: Fix the page details for the srq created by kernel consumers (git-fixes)
- commit 72d0292

- RDMA/mlx5: Fix bind QP error cleanup flow (git-fixes)
- commit a50daa9

- RDMA/mlx5: Fix AH static rate parsing (git-fixes)
- commit d0d2370

- RDMA/mlx5: Fix implicit ODP hang on parent deregistration (git-fixes)
- commit c4c267b

- RDMA/bnxt_re: Fix the statistics for Gen P7 VF (git-fixes)
- commit 2106458

- RDMA/hns: Fix mbox timing out by adding retry mechanism (git-fixes)
- commit a795049

- RDMA/mlx5: Fix a WARN during dereg_mr for DM type (git-fixes)
- commit 8f2604e

- RDMA/mlx5: Fix a race for DMABUF MR which can lead to CQE with error (git-fixes)
- commit d076f6b

- IB/mlx5: Set and get correct qp_num for a DCT QP (git-fixes)
- commit 92c60dc

- RDMA/mlx5: Fix the recovery flow of the UMR QP (git-fixes)
- commit 06e0da5

- zram: fix uninitialized ZRAM not releasing backing device
  (git-fixes).
- zram: refuse to use zero sized block device as backing device
  (git-fixes).
- zram: clear IDLE flag in mark_idle() (git-fixes).
- zram: clear IDLE flag after recompression (git-fixes).
- zram: do not mark idle slots that cannot be idle (git-fixes).
- commit ef8009a

- blk-cgroup: Properly propagate the iostat update up the
  hierarchy (bsc#1225606).
- commit fb4fada

- Refresh
  patches.suse/btrfs-fix-extent-map-merging-not-happening-for-adjacent-ex.patch.
  Fix the `-Wparentheses` build warning.
  ../fs/btrfs/extent_map.c: In function 'mergable_maps':
  ../fs/btrfs/extent_map.c:219:48: warning: suggest parentheses around comparison in operand of '&amp;amp;' [-Wparentheses]
- commit a88d495

- smb: client: fix corruption in cifs_extend_writeback
  (bsc#1235609).
- commit 7111675

- Move upstreamed ACPI patch into sorted section
- commit 34b98f4

- btrfs: fix defrag not merging contiguous extents due to merged
  extent  maps (bsc#1237232).
- btrfs: fix extent map merging not happening for adjacent extents
  (bsc#1237232).
- commit a57c147

- zram: split memory-tracking and ac-time tracking (git-fixes).
- Update config files.
- commit d2eb9a9

- KVM: arm64: Fix alignment of kvm_hyp_memcache allocations
  (git-fixes).
- commit 0b597f1

- KVM: arm64: Flush hyp bss section after initialization of
  variables in bss (git-fixes).
- commit 7a0da9b

- KVM: arm64: vgic-v3: Sanitise guest writes to GICR_INVLPIR
  (git-fixes).
- commit 361bd1c

- KVM: arm64: Ensure vgic_ready() is ordered against MMIO
  registration (git-fixes).
- commit eb69c06

- KVM: arm64: Don't eagerly teardown the vgic on init error
  (git-fixes).
- commit 09d2069

- KVM: nSVM: Enter guest mode before initializing nested NPT MMU
  (git-fixes).
- commit b54256b

- KVM: x86: Avoid double RDPKRU when loading host/guest PKRU
  (git-fixes).
- commit 497fc9a

- KVM: x86: Zero out PV features cache when the CPUID leaf is
  not present (git-fixes).
- commit b3e323a

- KVM: x86: Account for KVM-reserved CR4 bits when passing
  through CR4 on VMX (git-fixes).
- commit fe0be3a

- padata: Clean up in padata_do_multithreaded() (bsc#1237563).
- padata: Honor the caller's alignment in case of chunk_size 0
  (bsc#1237563).
- cpu/hotplug: Don't offline the last non-isolated CPU
  (bsc#1237562).
- cpu/hotplug: Prevent self deadlock on CPU hot-unplug
  (bsc#1237562).
- commit 285ec7d

- KVM: VMX: Fix comment of handle_vmx_instruction() (git-fixes).
- commit 986c213

- KVM: VMX: Allow toggling bits in MSR_IA32_RTIT_CTL when enable
  bit is cleared (git-fixes).
- commit 19b003b

- KVM: x86: Cache CPUID.0xD XSTATE offsets+sizes during module
  init (git-fixes).
- commit c214d6b

- KVM: x86: AMD's IBPB is not equivalent to Intel's IBPB
  (git-fixes).
- commit 08a45f2

- KVM: x86: Fix a comment inside
  __kvm_set_or_clear_apicv_inhibit() (git-fixes).
- commit dc6e2e8

- blk-cgroup: Fix class @block_class's subsystem refcount leakage
  (bsc#1237558).
- commit 908404a

- KVM: x86/mmu: Skip the &amp;quot;try unsync&amp;quot; path iff the old SPTE was
  a leaf SPTE (git-fixes).
- commit d7ef6bb

- KVM: x86: Unconditionally set irr_pending when updating APICv
  state (jsc#PED-348).
- commit 7089ba6

- KVM: nVMX: Treat vpid01 as current if L2 is active, but with
  VPID disabled (jsc#PED-348 git-fixes).
- commit ce778dd

- KVM: VMX: reset the segment cache after segment init in
  vmx_vcpu_reset() (jsc#PED-348 git-fixes).
- commit 57ae6ea

- vhost/net: Set num_buffers for virtio 1.0 (git-fixes).
- commit 3cc9281

- virtio_blk: reverse request order in virtio_queue_rqs
  (git-fixes).
- commit 08ef4d5

- x86/xen: allow larger contiguous memory regions in PV guests
  (git-fixes).
- commit cbf742d

- xen/swiotlb: relax alignment requirements (git-fixes).
- commit 85ac962

- x86/xen: add FRAME_END to xen_hypercall_hvm() (git-fixes).
- commit 23eecda

- x86/xen: fix xen_hypercall_hvm() to not clobber %rbx
  (git-fixes).
- commit e343881

- Grab mm lock before grabbing pt lock (git-fixes).
- commit ae619e6

- platform/x86/intel-uncore-freq: Increase minor number support
  (bsc#1237452).
- commit 43ac95b

- platform/x86/intel-uncore-freq: Ignore minor version change
  (bsc#1237452).
- commit 6b5df6d

- x86/cpu/kvm: SRSO: Fix possible missing IBPB on VM-Exit (git-fixes).
- commit 904b0d7

- platform/x86: ISST: Ignore minor version change (bsc#1237452).
- commit 17cda63

- platform/x86/intel/tpmi: Add defines to get version information
  (bsc#1237452).
- commit 1c56c6e

- KVM: x86: Advertise SRSO_USER_KERNEL_NO to userspace (git-fixes).
- commit 129191d

- x86/bugs: Add SRSO_USER_KERNEL_NO support (git-fixes).
- commit 1052c36

- RDMA/efa: Reset device on probe failure (git-fixes)
- commit c120211

- selftest: hugetlb_dio: fix test naming (git-fixes).
- commit 303d120

- selftests: hugetlb_dio: fixup check for initial conditions to
  skip in the start (git-fixes).
- commit 35f33c3

- selftests: hugetlb_dio: check for initial conditions to skip
  in the start (git-fixes).
- commit 89353b1

- selftest: mm: Test if hugepage does not get leaked during
  __bio_release_pages() (git-fixes).
- commit 56d43b6

- mtd: rawnand: cadence: fix unchecked dereference (git-fixes).
- commit f3e10b9

- drm/msm/dpu: Don't leak bits_per_component into random DSC_ENC
  fields (git-fixes).
- drm/msm/dpu: Disable dither in phys encoder cleanup (git-fixes).
- drm/msm: Avoid rounding up to one jiffy (git-fixes).
- drm/nouveau/pmu: Fix gp10b firmware guard (git-fixes).
- nouveau/svm: fix missing folio unlock + put after
  make_device_exclusive_range() (git-fixes).
- mtd: rawnand: cadence: fix incorrect device in dma_unmap_single
  (git-fixes).
- mtd: rawnand: cadence: use dma_map_resource for sdma address
  (git-fixes).
- mtd: rawnand: cadence: fix error code in cadence_nand_init()
  (git-fixes).
- USB: quirks: add USB_QUIRK_NO_LPM quirk for Teclast dist
  (stable-fixes).
- USB: Add USB_QUIRK_NO_LPM quirk for sony xperia xz1 smartphone
  (stable-fixes).
- USB: pci-quirks: Fix HCCPARAMS register error for LS7A EHCI
  (stable-fixes).
- USB: serial: option: drop MeiG Smart defines (stable-fixes).
- USB: serial: option: fix Telit Cinterion FN990A name
  (stable-fixes).
- USB: serial: option: add Telit Cinterion FN990B compositions
  (stable-fixes).
- USB: serial: option: add MeiG Smart SLM828 (stable-fixes).
- USB: hub: Ignore non-compliant devices with too many configs
  or interfaces (stable-fixes).
- usb: gadget: f_midi: Fixing wMaxPacketSize exceeded issue
  during MIDI bind retries (git-fixes).
- gpiolib: acpi: Add a quirk for Acer Nitro ANV14 (stable-fixes).
- efi: Avoid cold plugged memory for placing the kernel
  (stable-fixes).
- drm/amdgpu: avoid buffer overflow attach in
  smu_sys_set_pp_table() (stable-fixes).
- batman-adv: Drop unmanaged ELP metric worker (git-fixes).
- batman-adv: Ignore neighbor throughput metrics in error case
  (stable-fixes).
- HID: hid-steam: Don't use cancel_delayed_work_sync in IRQ
  context (git-fixes).
- HID: hid-steam: Move hidraw input (un)registering to work
  (git-fixes).
- ASoC: Intel: bytcr_rt5640: Add DMI quirk for Vexia Edu Atla
  10 tablet 5V (stable-fixes).
- ACPI: x86: Add skip i2c clients quirk for Vexia EDU ATLA 10
  tablet 5V (stable-fixes).
- selftests: gpio: gpio-sim: Fix missing chip disablements
  (stable-fixes).
- PCI: switchtec: Add Microchip PCI100X device IDs (stable-fixes).
- PCI/DPC: Quirk PIO log size for Intel Raptor Lake-P
  (stable-fixes).
- media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread
  (stable-fixes).
- media: uvcvideo: Add Kurokesu C1 PRO camera (stable-fixes).
- media: uvcvideo: Add new quirk definition for the Sonix
  Technology Co. 292a camera (stable-fixes).
- media: uvcvideo: Implement dual stream quirk to fix loss of
  usb packets (stable-fixes).
- media: cxd2841er: fix 64-bit division on gcc-9 (stable-fixes).
- soc/tegra: fuse: Update Tegra234 nvmem keepout list
  (stable-fixes).
- fbdev: omap: use threaded IRQ for LCD DMA (stable-fixes).
- HID: hid-steam: Make sure rumble work is canceled on removal
  (stable-fixes).
- selftests: rtnetlink: update netdevsim ipsec output format
  (stable-fixes).
- HID: hid-steam: Add Deck IMU support (stable-fixes).
- HID: hid-steam: Fix cleanup in probe() (git-fixes).
- HID: hid-steam: remove pointless error message (stable-fixes).
- HID: hid-steam: Add gamepad-only mode switched to by holding
  options (stable-fixes).
- HID: hid-steam: Update list of identifiers from SDL
  (stable-fixes).
- HID: hid-steam: Clean up locking (stable-fixes).
- HID: hid-steam: Disable watchdog instead of using a heartbeat
  (stable-fixes).
- HID: hid-steam: Avoid overwriting smoothing parameter
  (stable-fixes).
- commit df6a4bb

- block: avoid to reuse `hctx` not removed from cpuhp callback
  list (git-fixes).
- block: use the right type for stub rq_integrity_vec()
  (git-fixes).
- block: Fix page refcounts for unaligned buffers in
  __bio_release_pages() (git-fixes).
- commit 27674be

- devlink: avoid potential loop in
  devlink_rel_nested_in_notify_work() (bsc#1237234).
- commit 3a39566

- power: supply: da9150-fg: fix potential overflow (git-fixes).
- commit 859fe45

- ocfs2: fix incorrect CPU endianness conversion causing mount
  failure (bsc#1236138).
  re-enable patch ocfs2-fix-UBSAN-warning-in-ocfs2_verify_volume.patch
  (bsc#1236138).
- commit 1f4d40a

- iommu/arm-smmu-v3: Clean up more on probe failure
  (stable-fixes).
- commit f5873b7

- ice: fold ice_ptp_read_time into ice_ptp_gettimex64
  (bsc#1237415).
- ice: avoid the PTP hardware semaphore in gettimex64 path
  (bsc#1237415).
- ice: add ice_adapter for shared data across PFs on the same NIC
  (bsc#1237415).
- commit 9bb3389

- Fix conditional for selecting gcc-13
  Fixes: 51dacec21eb1 (&amp;quot;Use gcc-13 for build on SLE16 (jsc#PED-10028).&amp;quot;)
- commit 07542ae

- kasan: don't call find_vm_area() in a PREEMPT_RT kernel
  (git-fixes).
- lib/iov_iter: fix import_iovec_ubuf iovec management
  (git-fixes).
- lib: stackinit: hide never-taken branch from compiler
  (stable-fixes).
- commit 08ac036

- KVM: arm64: Unconditionally save+flush host FPSIMD/SVE/SME state (git-fixes)
- commit 484a6fb

- arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array (git-fixes)
- commit d8f1799

- arm64: Handle .ARM.attributes section in linker scripts (git-fixes)
- commit 44f383d

- arm64/mm: Ensure adequate HUGE_MAX_HSTATE (git-fixes)
- commit 13bd685

- block: copy back bounce buffer to user-space correctly in case
  of split (git-fixes).
- partitions: ldm: remove the initial kernel-doc notation
  (git-fixes).
- nbd: don't allow reconnect after disconnect (git-fixes).
- block: retry call probe after request_module in
  blk_request_module (git-fixes).
- block, bfq: fix waker_bfqq UAF after bfq_split_bfqq()
  (git-fixes).
- blk-iocost: Avoid using clamp() on inuse in
  __propagate_weights() (git-fixes).
- blk-mq: move cpuhp callback registering out of q-&amp;gt;sysfs_lock
  (git-fixes).
- blk-mq: register cpuhp callback after hctx is added to xarray
  table (git-fixes).
- ublk: fix error code for unsupported command (git-fixes).
- block: return unsigned int from bdev_io_min (git-fixes).
- block: fix bio_split_rw_at to take zone_write_granularity into
  account (git-fixes).
- ublk: fix ublk_ch_mmap() for 64K page size (git-fixes).
- blk-mq: Make blk_mq_quiesce_tagset() hold the tag list mutex
  less long (git-fixes).
- block: fix ordering between checking BLK_MQ_S_STOPPED request
  adding (git-fixes).
- block: fix ordering between checking QUEUE_FLAG_QUIESCED
  request adding (git-fixes).
- block: fix missing dispatching request when queue is started
  or unquiesced (git-fixes).
- Revert &amp;quot;blk-throttle: Fix IO hang for a corner case&amp;quot;
  (git-fixes).
- block: fix sanity checks in blk_rq_map_user_bvec (git-fixes).
- block: Fix elevator_get_default() checking for NULL q-&amp;gt;tag_set
  (git-fixes).
- blk_iocost: remove some duplicate irq disable/enables
  (git-fixes).
- block: fix integer overflow in BLKSECDISCARD (git-fixes).
- ublk: move zone report data out of request pdu (git-fixes).
- bio-integrity: don't restrict the size of integrity metadata
  (git-fixes).
- block: Fix lockdep warning in blk_mq_mark_tag_wait (git-fixes).
- rbd: don't assume rbd_is_lock_owner() for exclusive mappings
  (git-fixes).
- rbd: don't assume RBD_LOCK_STATE_LOCKED for exclusive mappings
  (git-fixes).
- rbd: rename RBD_LOCK_STATE_RELEASING and releasing_wait
  (git-fixes).
- loop: don't set QUEUE_FLAG_NOMERGES (git-fixes).
- block: change rq_integrity_vec to respect the iterator
  (git-fixes).
- block: remove the blk_flush_integrity call in
  blk_integrity_unregister (git-fixes).
- block: sed-opal: avoid possible wrong address reference in
  read_sed_opal_key() (git-fixes).
- null_blk: fix validation of block size (git-fixes).
- null_blk: Do not allow runt zone with zone capacity smaller
  then zone size (git-fixes).
- null_blk: Print correct max open zones limit in
  null_init_zoned_dev() (git-fixes).
- nbd: Fix signal handling (git-fixes).
- nbd: Improve the documentation of the locking assumptions
  (git-fixes).
- block: support to account io_ticks precisely (git-fixes).
- null_blk: Fix the WARNING: modpost: missing MODULE_DESCRIPTION()
  (git-fixes).
- block: fix and simplify blkdevparts= cmdline parsing
  (git-fixes).
- block: add a partscan sysfs attribute for disks (git-fixes).
- block: add a disk_has_partscan helper (git-fixes).
- null_blk: Fix missing mutex_destroy() at module removal
  (git-fixes).
- block: propagate partition scanning errors to the BLKRRPART
  ioctl (git-fixes).
- block: Clear zone limits for a non-zoned stacked queue
  (git-fixes).
- rbd: don't move requests to the running list on errors
  (git-fixes).
- commit 267ddd1

- null_blk: Remove usage of the deprecated ida_simple_xx() API
  (git-fixes).
- Refresh
  patches.suse/null_blk-fix-null-ptr-dereference-while-configuring-.patch.
- commit cea38e9

- kabi: fix group_cpus_evenly (bsc#1236897).
- kabi: fix bus type (bsc#1236896).
- commit 175404f

- PCI: imx6: Simplify clock handling by using clk_bulk*() function
  (git-fixes).
- Refresh
  patches.suse/PCI-imx6-Fix-suspend-resume-support-on-i.MX6QDL.patch.
- Refresh
  patches.suse/PCI-imx6-Skip-controller_id-generation-logic-for-i.M.patch.
- commit f03d03e

- PCI: Use downstream bridges for distributing resources
  (bsc#1237325).
- commit 7c0294f

- usb: quirks: Add NO_LPM quirk for TOSHIBA TransMemory-Mx device
  (git-fixes).
- commit bbb24b0

- ALSA: hda/conexant: Add quirk for HP ProBook 450 G4 mute LED
  (stable-fixes).
- commit 5d15622

- ALSA: seq: Drop UMP events when no UMP-conversion is set
  (git-fixes).
- ALSA: hda/cirrus: Correct the full scale volume set logic
  (git-fixes).
- ALSA: hda: Add error check for snd_ctl_rename_id() in
  snd_hda_create_dig_out_ctls() (git-fixes).
- ASoC: SOF: pcm: Clear the susbstream pointer to NULL on close
  (git-fixes).
- ASoC: SOF: stream-ipc: Check for cstream nullity in
  sof_ipc_msg_data() (git-fixes).
- ASoC: rockchip: i2s-tdm: fix shift config for
  SND_SOC_DAIFMT_DSP_[AB] (git-fixes).
- ASoC: fsl_micfil: Enable default case in micfil_set_quality()
  (git-fixes).
- ALSA: hda/realtek: Fixup ALC225 depop procedure (git-fixes).
- commit 6fb0aa0

- block: ensure we hold a queue reference when using queue limits
  (git-fixes).
- Refresh
  patches.suse/block-Fix-where-bio-IO-priority-gets-set.patch.
- commit 36d897c

- null_blk: don't cap max_hw_sectors to BLK_DEF_MAX_SECTORS
  (git-fixes).
- block: add check of 'minors' and 'first_minor' in
  device_add_disk() (git-fixes).
- block: Set memalloc_noio to false on device_add_disk() error
  path (git-fixes).
- block: Remove special-casing of compound pages (git-fixes).
- blk-mq: don't count completed flush data request as inflight
  in case of quiesce (git-fixes).
- ublk: move ublk_cancel_dev() out of ub-&amp;gt;mutex (git-fixes).
- block: Provide bdev_open_* functions (git-fixes).
- commit 3e547cf

- doc: update managed_irq documentation (bsc#1236897).
- blk-mq: issue warning when offlining hctx with online isolcpus
  (bsc#1236897).
- blk-mq: use hk cpus only when isolcpus=managed_irq is enabled
  (bsc#1236897).
- lib/group_cpus: honor housekeeping config when grouping CPUs
  (bsc#1236897).
- virtio: blk/scsi: use block layer helpers to calculate num of
  queues (bsc#1236897).
- scsi: use block layer helpers to calculate num of queues
  (bsc#1236897).
- nvme-pci: use block layer helpers to calculate num of queues
  (bsc#1236897).
- blk-mq: add number of queue calc helper (bsc#1236897).
- lib/group_cpus: let group_cpu_evenly return number initialized
  masks (bsc#1236897).
- commit 3a935fa

- blk-mq: create correct map for fallback case (bsc#1236896).
- virtio: blk/scsi: replace blk_mq_virtio_map_queues with
  blk_mq_map_hw_queues (bsc#1236896).
- nvme: replace blk_mq_pci_map_queues with blk_mq_map_hw_queues
  (bsc#1236896).
- scsi: replace blk_mq_pci_map_queues with blk_mq_map_hw_queues
  (bsc#1236896).
- blk-mq: introduce blk_mq_map_hw_queues (bsc#1236896).
- virtio: hookup irq_get_affinity callback (bsc#1236896).
- PCI: hookup irq_get_affinity callback (bsc#1236896).
- driver core: bus: add irq_get_affinity callback to bus_type
  (bsc#1236896).
- commit 1f8d7a5

- Update
  patches.suse/USB-serial-quatech2-fix-null-ptr-deref-in-qt2_proces.patch (CVE-2025-21689 bsc#1237017).
- Update
  patches.suse/drm-v3d-Assign-job-pointer-to-NULL-before-signaling-.patch (CVE-2025-21688 bsc#1237007
- Update
  patches.suse/drm-v3d-Ensure-job-pointer-is-set-to-NULL-after-job-.patch (CVE-2025-21697 bsc#1237132)
- Update
  patches.suse/gfs2-Truncate-address-space-when-flipping-GFS2_DIF_JDATA-flag.patch (CVE-2025-21699 bsc#1237139)
- Update
  patches.suse/gpio-xilinx-Convert-gpio_lock-to-raw-spinlock.patch (CVE-2025-21684 bsc#1236952)
- Update
  patches.suse/msft-hv-3155-scsi-storvsc-Ratelimit-warning-logs-to-prevent-VM-de.patch (CVE-2025-21690 bsc#1237025)
- commit a20ee68

- kABI fix for mptcp: fix inconsistent state on fastopen race
  (CVE-2024-26708 bsc#1222672).
  Upstream commit 4fd19a307016 (&amp;quot;mptcp: fix inconsistent state
  on fastopen race&amp;quot;) introduced three breaking changes, which are handled in
  this patch.
  * a new variable `pending_state` was added to `struct mptcp_sock`, which
  is now moved into a hole.
  * a new define replaces an old one, so renumber the new one and re-add
  the old one.
  * an API function was removed, so re-add it again.
  ```
    u8                         in_accept_queue:1;    /*  1562: 4  1 */
    /* XXX 3 bits hole, try to pack */
    /* XXX 5 bytes hole, try to pack */
    struct work_struct         work;                 /*  1568    32 */
  ```
- commit a4771c0

- bpf, sockmap: Several fixes to bpf_msg_pop_data (CVE-2024-56720
  bsc#1235592).
- commit a218d9d

- net: Fix icmp host relookup triggering ip_rt_bug (CVE-2024-56647
  bsc#1235435).
- commit 713c9c9

- USB: Fix the issue of task recovery failure caused by USB
  status when S4 wakes up (git-fixes).
- commit 686e836

- powerpc/64s/mm: Move __real_pte stubs into hash-4k.h
  (bsc#1215199).
- commit 73fb25c

- powerpc/code-patching: Fix KASAN hit by not flagging text
  patching area as VM_ALLOC (bsc#1215199).
- powerpc/64s: Rewrite __real_pte() and __rpte_to_hidx() as
  static inline (bsc#1215199).
- powerpc/code-patching: Disable KASAN report during patching
  via temporary mm (bsc#1215199).
- commit cb15126

- usbnet: ipheth: document scope of NCM implementation
  (stable-fixes).
- wifi: brcmfmac: fix NULL pointer dereference in
  brcmf_txfinalize() (stable-fixes).
- wifi: mt76: mt7921u: Add VID/PID for TP-Link TXE50UH
  (stable-fixes).
- wifi: rtw88: sdio: Fix disconnection after beacon loss
  (stable-fixes).
- wifi: iwlwifi: avoid memory leak (stable-fixes).
- wifi: brcmfmac: Check the return value of
  of_property_read_string_index() (stable-fixes).
- wifi: rtw89: add crystal_cap check to avoid setting as overflow
  value (stable-fixes).
- wifi: brcmsmac: add gain range check to
  wlc_phy_iqcal_gainparams_nphy() (stable-fixes).
- commit b67568f

- acct: block access to kernel internal filesystems (git-fixes).
- acct: perform last write from workqueue (git-fixes).
- drm/i915: Drop 64bpp YUV formats from ICL+ SDR planes
  (stable-fixes).
- drm/i915: Fix page cleanup on DMA remap failure (git-fixes).
- Revert &amp;quot;drm/amd/display: Use HW lock mgr for PSR1&amp;quot;
  (stable-fixes).
- selftests: mptcp: connect: -f: no reconnect (git-fixes).
- net: rose: lock the socket in rose_bind() (git-fixes).
- scripts/gdb: fix aarch64 userspace detection in get_current_task
  (stable-fixes).
- drm/amdkfd: only flush the validate MES contex (stable-fixes).
- drm/amd/pm: Mark MM activity as unsupported (stable-fixes).
- ata: libata-sff: Ensure that we cannot write outside the
  allocated buffer (stable-fixes).
- cpufreq: s3c64xx: Fix compilation warning (stable-fixes).
- drm/modeset: Handle tiled displays in pan_display_atomic
  (stable-fixes).
- efi: libstub: Use '-std=gnu11' to fix build with GCC 15
  (stable-fixes).
- ASoC: amd: Add ACPI dependency to fix build error
  (stable-fixes).
- platform/x86: acer-wmi: Ignore AC events (stable-fixes).
- Input: allocate keycode for phone linking (stable-fixes).
- platform/x86: int3472: Check for adev == NULL (stable-fixes).
- tomoyo: don't emit warning in tomoyo_write_control()
  (stable-fixes).
- HID: Wacom: Add PCI Wacom device support (stable-fixes).
- APEI: GHES: Have GHES honor the panic= setting (stable-fixes).
- clk: sunxi-ng: a100: enable MMC clock reparenting (git-fixes).
- clk: qcom: gcc-mdm9607: Fix cmd_rcgr offset for blsp1_uart6 rcg
  (git-fixes).
- clk: qcom: clk-alpha-pll: fix alpha mode configuration
  (git-fixes).
- clk: qcom: dispcc-sm6350: Add missing parent_map for a clock
  (git-fixes).
- clk: qcom: gcc-sm6350: Add missing parent_map for two clocks
  (git-fixes).
- clk: qcom: clk-rpmh: prevent integer overflow in recalc_rate
  (git-fixes).
- clk: qcom: gcc-sm8550: Do not turn off PCIe GDSCs during
  gdsc_disable() (git-fixes).
- clk: mediatek: mt2701-img: add missing dummy clk (git-fixes).
- clk: mediatek: mt2701-mm: add missing dummy clk (git-fixes).
- clk: mediatek: mt2701-bdp: add missing dummy clk (git-fixes).
- clk: mediatek: mt2701-aud: fix conversion to
  mtk_clk_simple_probe (git-fixes).
- clk: mediatek: mt2701-vdec: fix conversion to
  mtk_clk_simple_probe (git-fixes).
- i2c: Force ELAN06FA touchpad I2C bus freq to 100KHz
  (stable-fixes).
- mmc: sdhci-msm: Correctly set the load for the regulator
  (stable-fixes).
- mmc: core: Respect quirk_max_rate for non-UHS SDIO card
  (stable-fixes).
- mfd: lpc_ich: Add another Gemini Lake ISA bridge PCI device-id
  (stable-fixes).
- spi: atmel-qspi: Memory barriers after memory-mapped I/O
  (git-fixes).
- spi: atmel-quadspi: Create `atmel_qspi_ops` to support newer
  SoC families (stable-fixes).
- selftests/net/ipsec: Fix Null pointer dereference in
  rtattr_pack() (stable-fixes).
- Bluetooth: MGMT: Fix slab-use-after-free Read in
  mgmt_remove_adv_monitor_sync (stable-fixes).
- net: wwan: iosm: Fix hibernation by re-binding the driver
  around it (stable-fixes).
- drm/amd/display: Fix Mode Cutoff in DSC Passthrough to DP2.1
  Monitor (stable-fixes).
- drm/bridge: it6505: fix HDCP CTS KSV list wait timer
  (stable-fixes).
- drm/bridge: it6505: fix HDCP CTS compare V matching
  (stable-fixes).
- drm/bridge: it6505: fix HDCP encryption when R0 ready
  (stable-fixes).
- drm/bridge: it6505: fix HDCP Bstatus check (stable-fixes).
- drm/bridge: it6505: Change definition MAX_HDCP_DOWN_STREAM_COUNT
  (stable-fixes).
- drm/virtio: New fence for every plane update (stable-fixes).
- lockdep: Fix upper limit for LOCKDEP_*_BITS configs
  (stable-fixes).
- commit 32eeef9

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

- sctp: sysctl: cookie_hmac_alg: avoid using current-&amp;gt;nsproxy (CVE-2025-21640 bsc#1236123)
- commit 7a3b711

- sctp: sysctl: rto_min/max: avoid using current-&amp;gt;nsproxy (CVE-2025-21639 bsc#1236122)
- commit e818833

- pktgen: Avoid out-of-bounds access in get_imix_entries
  (CVE-2025-21680 bsc#1236700).
- commit 8cb9ad2

- sctp: sysctl: auth_enable: avoid using current-&amp;gt;nsproxy (CVE-2025-21638 bsc#1236115)
- commit e4e9666

- sctp: sysctl: udp_port: avoid using current-&amp;gt;nsproxy (CVE-2025-21637 bsc#1236114)
- commit b35279d

- sctp: sysctl: plpmtud_probe_interval: avoid using current-&amp;gt;nsproxy (CVE-2025-21636 bsc#1236113)
- commit 3f71e7d

- add bug reference to hv_storvsc change (bsc#1237025 CVE-2025-21690).
- commit 45e9861

-  kABI fix for mptcp: handle consistently DSS corruption (CVE-2024-50185 bsc#1233109)
- commit d478aac

- idpf: fix VF dynamic interrupt ctl register initialization
  (git-fixes).
- Refresh
  patches.suse/idpf-add-support-for-SW-triggered-interrupts.patch.
- commit da462e1

- igc: Set buffer type for empty frames in igc_init_empty_frame
  (git-fixes).
- igc: Fix HW RX timestamp when passed by ZC XDP (git-fixes).
- idpf: call set_real_num_queues in idpf_open (bsc#1236661).
- idpf: fix handling rsc packet with a single segment (git-fixes).
- ice: stop storing XDP verdict within ice_rx_buf (git-fixes).
- ice: gather page_count()'s of each frag right before XDP prog
  call (git-fixes).
- ice: put Rx buffers after being done with current frame
  (git-fixes).
- iavf: allow changing VLAN state without calling PF (git-fixes).
- idpf: convert workqueues to unbound (git-fixes).
- idpf: add read memory barrier when checking descriptor done bit
  (git-fixes).
- net/mlx5e: Always start IPsec sequence number from 1
  (git-fixes).
- net/mlx5e: Rely on reqid in IPsec tunnel mode (git-fixes).
- net/mlx5: SF, Fix add port error handling (git-fixes).
- net/mlx5: Fix RDMA TX steering prio (git-fixes).
- igc: return early when failing to read EECD register
  (git-fixes).
- ice: fix incorrect PHY settings for 100 GB/s (git-fixes).
- ice: fix max values for dpll pin phase adjust (git-fixes).
- eth: gve: use appropriate helper to set xdp_features
  (git-fixes).
- cxgb4: Avoid removal of uninserted tid (git-fixes).
- bnxt_en: Fix possible memory leak when hwrm_req_replace fails
  (git-fixes).
- net: sfc: Correct key_len for efx_tc_ct_zone_ht_params
  (git-fixes).
- net/mlx5e: macsec: Maintain TX SA from encoding_sa (git-fixes).
- chelsio/chtls: prevent potential integer overflow on 32bit
  (git-fixes).
- cxgb4: use port number to set mac addr (git-fixes).
- bnxt_en: Unregister PTP during PCI shutdown and suspend
  (git-fixes).
- bnxt_en: Refactor bnxt_ptp_init() (git-fixes).
- net/mlx5: Verify support for scheduling element and TSAR type
  (git-fixes).
- ice: check ICE_VSI_DOWN under rtnl_lock when preparing for reset
  (git-fixes).
- ice: use internal pf id instead of function number (git-fixes).
- ice: Skip PTP HW writes during PTP reset procedure (git-fixes).
- net/mlx5: Correct TASR typo into TSAR (git-fixes).
- commit a2c0ed6

- Use gcc-13 for build on SLE16 (jsc#PED-10028).
- commit 51dacec

- kbuild: userprogs: fix bitsize and target detection on clang
  (git-fixes).
- tools: fix annoying &amp;quot;mkdir -p ...&amp;quot; logs when building tools
  in parallel (git-fixes).
- serial: 8250: Fix fifo underflow on flush (git-fixes).
- usb: roles: set switch registered flag early on (git-fixes).
- usb: gadget: core: flush gadget workqueue after device removal
  (git-fixes).
- USB: gadget: f_midi: f_midi_complete to call queue_work
  (git-fixes).
- usb: core: fix pipe creation for get_bMaxPacketSize0
  (git-fixes).
- usb: dwc3: Fix timeout issue during controller enter/exit from
  halt state (git-fixes).
- USB: cdc-acm: Fill in Renesas R-Car D3 USB Download mode quirk
  (git-fixes).
- usb: cdc-acm: Fix handling of oversized fragments (git-fixes).
- usb: cdc-acm: Check control transfer buffer size before access
  (git-fixes).
- usb: gadget: f_midi: fix MIDI Streaming descriptor lengths
  (git-fixes).
- usb: dwc2: gadget: remove of_node reference upon udc_stop
  (git-fixes).
- usb: gadget: udc: renesas_usb3: Fix compiler warning
  (git-fixes).
- commit f681ca5

- gpio: stmpe: Check return value of stmpe_reg_read in
  stmpe_gpio_irq_sync_unlock (git-fixes).
- gpio: bcm-kona: Add missing newline to dev_err format string
  (git-fixes).
- gpio: bcm-kona: Make sure GPIO bits are unlocked when requesting
  IRQ (git-fixes).
- gpio: bcm-kona: Fix GPIO lock/unlock for banks above bank 0
  (git-fixes).
- commit 72e2a5f

- exfat: fix file being changed by unaligned direct write
  (git-fixes).
- commit c5a2490

- exfat: fix zero the unwritten part for dio read (git-fixes).
- commit ab0ec4f

- hfs: Sanity check the root record (git-fixes).
- commit 6977b91

- dlm: fix srcu_read_lock() return type to int (git-fixes).
- commit 3303370

- exfat: fix out-of-bounds access of directory entries
  (bsc#1234857 CVE-2024-53147).
- commit 8127e11

- exfat: change to get file size from DataLength (bsc#1234857
  CVE-2024-53147).
- commit 34f63a5

- exfat: convert to ctime accessor functions (git-fixes).
- commit 430eb66

- mmc: mtk-sd: Fix register settings for hs400(es) mode
  (git-fixes).
- commit 0e84651

- smb: client: instantiate when creating SFU files (git-fixes).
- commit 1658f01

- smb: client: handle lack of FSCTL_GET_REPARSE_POINT support
  (git-fixes).
- commit eacadae

- smb: client: return reparse type in /proc/mounts (git-fixes).
- commit 5c949e8

- smb: client: set correct d_type for reparse DFS/DFSR and mount
  point (git-fixes).
- commit 99477ce

- smb: client: Fix a NULL vs IS_ERR() check in wsl_set_xattrs()
  (git-fixes).
- commit dcd4483

- smb: client: parse uid, gid, mode and dev from WSL reparse
  points (git-fixes).
- commit 86b1707

- smb: client: introduce SMB2_OP_QUERY_WSL_EA (git-fixes).
- Refresh
  patches.suse/smb-client-fix-potential-UAF-in-cifs_debug_files_proc_show-.patch.
- commit 6f30059

- smb: client: get rid of smb311_posix_query_path_info()
  (git-fixes).
- commit 08f4b23

- smb: client: add support for WSL reparse points (git-fixes).
- commit 4773bbe

- smb: client: reduce number of parameters in smb2_compound_op()
  (git-fixes).
- commit 5bf06b7

- smb: client: retry compound request without reusing lease
  (git-fixes).
- commit 44ecf42

- smb: client: reuse file lease key in compound operations
  (git-fixes).
- commit e1d39cc

- smb: client: parse owner/group when creating reparse points
  (git-fixes).
- commit 2b1f34d

- cifs: open_cached_dir(): add FILE_READ_EA to desired access
  (git-fixes).
- commit f59c050

- cifs: update the same create_guid on replay (git-fixes).
- commit 651496d

- smb: client: reduce stack usage in smb2_query_reparse_point()
  (git-fixes).
- commit a2f52a1

- cifs: update desired access while requesting for directory lease
  (git-fixes).
- commit 3577933

- smb: client: move most of reparse point handling code to common
  file (git-fixes).
- commit 90c5825

- smb: client: handle special files and symlinks in SMB3 POSIX
  (git-fixes).
- commit 7ddb775

- smb: client: cleanup smb2_query_reparse_point() (git-fixes).
- commit 56a04ed

- smb: client: fix OOB in smb2_query_reparse_point() (git-fixes).
- commit a9edfbd

- smb: client: allow creating symlinks via reparse points
  (git-fixes).
- commit 93e7dee

- smb: client: fix hardlinking of reparse points (git-fixes).
- commit 6805b33

- drm/i915/selftests: avoid using uninitialized context
  (git-fixes).
- drm/amdgpu: bail out when failed to load fw in
  psp_init_cap_microcode() (git-fixes).
- spi: sn-f-ospi: Fix division by zero (git-fixes).
- regmap-irq: Add missing kfree() (git-fixes).
- batman-adv: fix panic during interface removal (git-fixes).
- can: etas_es58x: fix potential NULL pointer dereference on
  udev-&amp;gt;serial (git-fixes).
- can: c_can: fix unbalanced runtime PM disable in error path
  (git-fixes).
- can: ctucanfd: handle skb allocation failure (git-fixes).
- can: j1939: j1939_sk_send_loop(): fix unable to send messages
  with data length zero (git-fixes).
- wifi: ath12k: fix handling of 6 GHz rules (git-fixes).
- commit 30daf36

- smb: client: fix missing mode bits for SMB symlinks (git-fixes).
- commit 8fa207f

- smb: client: stop revalidating reparse points unnecessarily
  (git-fixes).
- commit ce08be7

- smb: client: fix potential broken compound request (git-fixes).
- commit a4415de

- smb: client: fix renaming of reparse points (git-fixes).
- commit 32e853e

- smb: client: optimise reparse point querying (git-fixes).
- commit a53eec6

- smb: client: allow creating special files via reparse points
  (git-fixes).
- commit 74e26d4

- smb: client: introduce cifs_sfu_make_node() (git-fixes).
- commit 39b0787

- smb: client: set correct file type from NFS reparse points
  (git-fixes).
- Delete
  patches.suse/cifs-Fix-buffer-overflow-when-parsing-NFS-reparse-points.patch.
  (deleted patch will be added later)
- commit 7b28133

- smb: client: introduce -&amp;gt;parse_reparse_point() (git-fixes).
- commit 5e66e50

- smb3: fix creating FIFOs when mounting with &amp;quot;sfu&amp;quot; mount option
  (git-fixes).
- commit 82c7e6d

- mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow (CVE-2024-50085 bsc#1232508)
- commit 25971ed

- smb: client: Fix minor whitespace errors and warnings
  (git-fixes).
- commit 1eedc39

- smb: use kernel_connect() and kernel_bind() (git-fixes).
- commit 6936009

- smb: client: introduce reparse mount option (git-fixes).
- commit e5a8c1e

- smb: client: implement -&amp;gt;query_reparse_point() for SMB1
  (git-fixes).
- commit 2615bfd

- smb: cilent: set reparse mount points as automounts (git-fixes).
- commit da6e3c8

- smb: client: do not query reparse points twice on symlinks
  (git-fixes).
- commit b7e62c9

- s390/futex: Fix FUTEX_OP_ANDN implementation (git-fixes
  bsc#1237158).
- commit 3e00897

- KVM: s390: vsie: fix some corner-cases when grabbing vsie pages
  (git-fixes bsc#1237155).
- commit 6d87f47

- net/smc: support ipv4 mapped ipv6 addr client for smc-r v2
  (bsc#1236994).
- net: smc: fix spurious error message from __sock_release()
  (bsc#1237126).
- commit 2c0a5e1

- mptcp: fix data races on local_id (git-fixes)
- Refresh patches.suse/mptcp-fix-data-races-on-remote_id.patch
- commit 661ea6e

- mptcp: pm: fullmesh: select the right ID later (git-fixes)
- commit 1d30f2b

- mptcp: pm: only in-kernel cannot have entries with ID 0 (git-fixes)
- commit 8638b2c

- mptcp: unify pm set_flags interfaces (git-fixes)
- commit 493b268

- mptcp: unify pm get_flags_and_ifindex_by_id (git-fixes)
- commit 57ae267

- mptcp: unify pm get_local_id interfaces (git-fixes)
- commit f1f0e12

- mptcp: export local_address (git-fixes)
- commit 2e22243

- mptcp: pm: check add_addr_accept_max before accepting new ADD_ADDR (git-fixes)
- commit 9c72df8

- mptcp: pm: only decrement add_addr_accepted for MPJ req (CVE-2024-45009 bsc#1230438)
- commit 9337031

- mptcp: pm: only mark 'subflow' endp as available (CVE-2024-45010 bsc#1230439)
- commit 9e1f869

- mptcp: pm: remove mptcp_pm_remove_subflow (git-fixes)
- commit 0d1e602

- Update config files.
  Use the upstream default for TSX_MODE.
- commit 55bbd12

- mptcp: pm: re-using ID of unused flushed subflows (git-fixes)
- commit 2798558

- mptcp: pm: re-using ID of unused removed subflows (git-fixes)
- commit 405e62f

- mptcp: pm: re-using ID of unused removed ADD_ADDR (git-fixes)
- commit 42e63a4

- mptcp: fix NL PM announced address accounting (git-fixes)
- commit 28d5efa

- mptcp: pm: inc RmAddr MIB counter once per RM_ADDR ID (git-fixes)
- commit adfc1dd

- mptcp: pm: avoid possible UaF when selecting endp (CVE-2024-44974 bsc#1230235)
- commit e827535

- mptcp: pm: do not ignore 'subflow' if 'signal' flag is also set (git-fixes)
- commit 262fe7b

- mptcp: pm: deny endp with signal + subflow + port (git-fixes)
- commit 20e7fdf

- mptcp: fully established after ADD_ADDR echo on MPJ (git-fixes)
- commit 54ad8c1

- mptcp: pm: don't try to create sf if alloc failed (git-fixes)
- commit 9185902

- mptcp: pm: reduce indentation blocks (git-fixes)
- commit a393115

- mptcp: pass addr to mptcp_pm_alloc_anno_list (git-fixes)
- commit 71a0164

- mptcp: handle consistently DSS corruption (CVE-2024-50185 bsc#1233109)
- commit 01e9763

- powerpc/pseries/iommu: Split Dynamic DMA Window to be used in Hybrid
  mode (ltc#210895 bsc#1235933 ltc#210896 bsc#1235932).
- Refresh patches.suse/powerpc-pseries-iommu-IOMMU-incorrectly-marks-MMIO-r.patch
- commit d8f69df

- usb: dwc3: core: Defer the probe until USB power supply ready
  (git-fixes).
- commit f3ecf26

- vfio/platform: check the bounds of read/write syscalls
  (bsc#1237045 CVE-2025-21687).
- commit e52d676

- xhci: dbgtty: remove kfifo_out() wrapper (git-fixes).
- commit 806156f

- net: sched: fix ets qdisc OOB Indexing (bsc#1237028
  CVE-2025-21692).
- commit 1b093fe

- RDMA/rxe: Improve newline in printing messages (git-fixes)
- Refresh patches.suse/RDMA-rxe-Fix-mismatched-max_msg_sz.patch
- Pickup RXE code change introduced by upstream merge: af96134dc856 (&amp;quot;Merge tag 'rcu.2023.06.22a' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu&amp;quot;)
- commit 1492681

- smb: client: fix possible double free in smb2_set_ea()
  (git-fixes).
- commit b6cd961

- powerpc/trace: Add support for HAVE_FUNCTION_ARG_ACCESS_API
  (bsc#1236967 ltc#210988).
- Update config files.
- commit 83bff51

- Update &amp;quot;drm/mgag200: Added support for the new device G200eH5&amp;quot; (jsc#PED-12094)
  Update to match upstream commit 6636c58b946c (&amp;quot;drm/mgag200: Added
  support for the new device G200eH5&amp;quot;).
- commit 7ba9f89

- usb: xhci: Fix NULL pointer dereference on certain command
  aborts (git-fixes).
- commit 8628513

- util_macros.h: fix/rework find_closest() macros (git-fixes).
- commit 01b2939

- s390/topology: Improve topology detection (bsc#1236591).
- commit 101e515

- HID: hid-thrustmaster: fix stack-out-of-bounds read in
  usb_check_int_endpoints() (git-fixes).
- HID: multitouch: Add NULL check in mt_input_configured
  (git-fixes).
- pinctrl: cy8c95x0: Respect IRQ trigger settings from firmware
  (git-fixes).
- commit 1dbe333

- scsi: storvsc: Set correct data length for sending SCSI command
  without payload (git-fixes).
- commit 93c01ea

- net/mlx5: Fix msix vectors to respect platform limit
  (bsc#1225981).
- commit b7a2367

- s390/pci: Fix SR-IOV for PFs initially in standby
  (git-fixes bsc#1236752).
- commit dcf85a0

- s390/pci: Fix leak of struct zpci_dev when zpci_add_device()
  fails (bsc#1236752).
- s390/pci: Ignore RID for isolated VFs (bsc#1236752).
- s390/pci: Use topology ID for multi-function devices
  (bsc#1236752).
- s390/pci: Sort PCI functions prior to creating virtual busses
  (bsc#1236752).
- commit 004cfd2

- iommu/arm-smmu: Make instance lookup robust (bsc#1235032, CVE-2024-56568).
- commit 8f1b23e

- Update
  patches.suse/ALSA-6fire-Release-resources-at-card-release.patch
  (git-fixes CVE-2024-53239 bsc#1235054 bsc#1234853).
- Update
  patches.suse/Bluetooth-L2CAP-Fix-uaf-in-l2cap_connect.patch
  (CVE-2024-49950 bsc#1232159 bsc#1225742).
- Update
  patches.suse/Bluetooth-L2CAP-do-not-leave-dangling-sk-pointer-on-.patch
  (stable-fixes CVE-2024-56605 bsc#1235061 bsc#1234853).
- Update
  patches.suse/KVM-nSVM-Ignore-nCR3-4-0-when-loading-PDPTEs-from-me.patch
  (CVE-2024-50115 bsc#1232919 bsc#1225742).
- Update
  patches.suse/NFSv4.0-Fix-a-use-after-free-problem-in-the-asynchronous-open.patch
  (git-fixes CVE-2024-53173 bsc#1234891 bsc#1234853).
- Update
  patches.suse/RDMA-hns-Fix-NULL-pointer-derefernce-in-hns_roce_map.patch
  (git-fixes CVE-2024-53226 bsc#1236576).
- Update
  patches.suse/ext4-avoid-OOB-when-system.data-xattr-changes-undern.patch
  (bsc#1231920 CVE-2024-47701 bsc#1225742).
- Update
  patches.suse/ext4-fix-slab-use-after-free-in-ext4_split_extent_at.patch
  (bsc#1232201 CVE-2024-49884 bsc#1232198 bsc#1225742).
- Update
  patches.suse/hfsplus-don-t-query-the-device-logical-block-size-multiple-times.patch
  (git-fixes CVE-2024-56548 bsc#1235073 bsc#1234853).
- Update
  patches.suse/mac802154-check-local-interfaces-before-deleting-sda.patch
  (stable-fixes CVE-2024-57948 bsc#1236677).
- Update
  patches.suse/media-amphion-Set-video-drvdata-before-register-vide.patch
  (git-fixes CVE-2024-56579 bsc#1236575).
- Update
  patches.suse/mm-prevent-derefencing-NULL-ptr-in-pfn_section_valid.patch
  (git-fixes CVE-2024-41055 bsc#1228521).
- Update
  patches.suse/pinctrl-mcp23s08-Fix-sleeping-in-atomic-context-due-.patch
  (git-fixes CVE-2024-57889 bsc#1236573).
- Update
  patches.suse/tty-n_gsm-Fix-use-after-free-in-gsm_cleanup_mux.patch
  (stable-fixes CVE-2024-50073 bsc#1232520 bsc#1225742).
- Update
  patches.suse/vfio-pci-Lock-external-INTx-masking-ops.patch
  (bsc#1222803 CVE-2024-26810).
- Update
  patches.suse/wifi-mwifiex-Fix-memcpy-field-spanning-write-warning-d241a13.patch
  (git-fixes CVE-2024-56539 bsc#1234963 bsc#1234853).
- commit 2e394be

- Update
  patches.suse/netfilter-nf_tables-don-t-fail-inserts-if-dupl.patch
  (bsc#1012628 CVE-2023-52925 bsc#1236822).
- Update
  patches.suse/netfilter-nf_tables-don-t-skip-expired-element.patch
  (bsc#1012628 CVE-2023-52924 bsc#1236821).
- commit 6257a48

- tg3: Disable tg3 PCIe AER on system reboot (bsc#1219367).
- commit 43ff004

- wifi: mt76: mt7915: improve hardware restart reliability
  (stable-fixes).
- commit 8478fb6

- ASoC: Intel: avs: Prefix SKL/APL-specific members
  (stable-fixes).
- Refresh
  patches.suse/ASoC-Intel-avs-Fix-theoretical-infinite-loop.patch.
- commit 01a2134

- serial: sc16is7xx: use device_property APIs when configuring
  irda mode (stable-fixes).
- Refresh
  patches.suse/serial-sc16is7xx-remove-global-regmap-from-struct-sc.patch.
- commit 5b3248c

- ASoC: Intel: avs: Do not readq() u32 registers (git-fixes).
- ALSA: seq: Make dependency on UMP clearer (git-fixes).
- crypto: hisilicon/sec2 - fix for aead invalid authsize
  (git-fixes).
- crypto: hisilicon/sec2 - fix for aead icv error (git-fixes).
- wifi: mt76: mt7915: fix omac index assignment after hardware
  reset (git-fixes).
- drm/rockchip: vop2: include rockchip_drm_drv.h (git-fixes).
- drm/rockchip: vop2: Fix the windows switch between different
  layers (git-fixes).
- wifi: mt76: connac: move mt7615_mcu_del_wtbl_all to connac
  (stable-fixes).
- ASoC: Intel: avs: Abstract IPC handling (stable-fixes).
- ALSA: seq: remove redundant 'tristate' for SND_SEQ_UMP_CLIENT
  (stable-fixes).
- drm/rockchip: vop2: set bg dly and prescan dly at
  vop2_post_config (stable-fixes).
- drm/rockchip: vop2: Set YUV/RGB overlay mode (stable-fixes).
- drm/rockchip: move output interface related definition to
  rockchip_drm_drv.h (stable-fixes).
- crypto: hisilicon/sec2 - optimize the error return process
  (stable-fixes).
- commit 21fab4a

- drm/i915/dp: Iterate DSC BPP from high to low on all platforms
  (git-fixes).
- drm/i915/guc: Debug print LRC state entries only if the context
  is pinned (git-fixes).
- drm/i915/pmu: Fix zero delta busyness issue (git-fixes).
- gpu: drm_dp_cec: fix broken CEC adapter properties check
  (git-fixes).
- drm/komeda: Add check for komeda_get_layer_fourcc_list()
  (git-fixes).
- firmware: iscsi_ibft: fix ISCSI_IBFT Kconfig entry (git-fixes).
- ACPI: property: Fix return value for nval == 0 in
  acpi_data_prop_read() (git-fixes).
- ACPI: PRM: Remove unnecessary strict handler address checks
  (git-fixes).
- gpio: pca953x: Improve interrupt support (git-fixes).
- commit e018ad6

- mptcp: fix recvbuffer adjust on sleeping rcvmsg (git-fixes)
- commit 4ce1907

- filemap: avoid truncating 64-bit offset to 32 bits
  (CVE-2025-21665 bsc#1236684).
- commit 597c6a3

- smb: client: fix double free of TCP_Server_Info::hostname
  (CVE-2025-21673 bsc#1236689).
- commit 3139e94

- openvswitch: fix lockup on tx to unregistering netdev with
  carrier (CVE-2025-21681 bsc#1236702).
- commit b85304e

- pmdomain: imx8mp-blk-ctrl: add missing loop break condition
  (CVE-2025-21668 bsc#1236682).
- commit 99dbd95

- iomap: avoid avoid truncating 64-bit offset to 32 bits
  (CVE-2025-21667 bsc#1236681).
- commit e233a3c

- cpufreq: qcom-nvmem: add support for IPQ8064 (git-fixes).
- Refresh
  patches.suse/cpufreq-qcom-nvmem-Enable-virtual-power-domain-devices.patch.
- commit f530449

- drm/amdgpu: fix UVD contiguous CS mapping problem (bsc#1236759).
- commit 785700c

- cpufreq: mediatek-hw: Don't error out if supply is not found
  (git-fixes).
- commit 8cc17c1

- mptcp: error out earlier on disconnect (CVE-2024-53123 bsc#1234070)
- commit b7c16f4

- drop_monitor: replace spin_lock by raw_spin_lock (CVE-2024-40980 bsc#1227937)
- commit 72b4850

- xfrm: validate new SA's prefixlen using SA family when sel.family is unset (CVE-2024-50142 bsc#1233028)
- commit 821a08b

- selftests/bpf: Add apply_bytes test to
  test_txmsg_redir_wait_sndmem in test_sockmap (bsc#1235485
  CVE-2024-56633).
- tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsg
  (bsc#1235485 CVE-2024-56633).
- commit 92f3cb7

- smb: During unmount, ensure all cached dir instances drop
  their dentry (bsc#1231432, bsc#1234894, CVE-2024-53176).
- commit c66b2d4

- smb: client: reduce stack usage in smb2_set_ea() (bsc#1231432).
- Refresh
  patches.suse/smb-client-fix-potential-UAF-in-cifs_debug_files_proc_show-.patch.
- commit b56ad4e

- smb: client: properly close cfids on umount (bsc#1231432,
  bsc#1232299, bsc#1235599, bsc#1234896).
- commit 189365b

- drm/mgag200: Added support for the new device G200eH5 (jsc#PED-12094)
- commit 5e11827

- cpufreq: qcom-nvmem: drop pvs_ver for format a fuses
  (git-fixes).
- commit 60005f6

- cpufreq: qcom: Implement clk_ops::determine_rate() for
  qcom_cpufreq* clocks (git-fixes).
- cpufreq: qcom: Fix qcom_cpufreq_hw_recalc_rate() to query LUT
  if LMh IRQ is not available (git-fixes).
- commit 3e10296

- cpufreq: mediatek-hw: Wait for CPU supplies before probing
  (git-fixes).
- commit b08f9e8

- sched: sch_cake: add bounds checks to host bulk flow fairness
  counts (CVE-2025-21647 bsc#1236133).
- commit 1f1bc5f

- locking/lockdep: Avoid creating new name string literals in
  lockdep_set_subclass() (git-fixes).
- commit c137ed9

- lockdep: fix deadlock issue between lockdep and rcu (git-fixes).
- commit d6daab7

- locking/rwsem: Add __always_inline annotation to
  __down_write_common() and inlined callers (git-fixes).
- commit 1366984

- selftests/futex: pass _GNU_SOURCE without a value to the
  compiler (git-fixes).
- commit 6c47425

- futex: Don't include process MM in futex key on no-MMU
  (git-fixes).
- commit 925398b

- cpufreq: qcom-nvmem: use helper to get SMEM SoC ID (git-fixes).
- cpufreq: qcom-nvmem: use SoC ID-s from bindings (git-fixes).
- soc: qcom: smem: introduce qcom_smem_get_soc_id() (git-fixes).
- soc: qcom: socinfo: move SMEM item struct and defines to a
  header (git-fixes).
- commit 870636f

- selftests/bpf: Test the update operations for htab of maps
  (bsc#1235244 CVE-2024-56592).
- selftests/bpf: Move ENOTSUPP from bpf_util.h (bsc#1235244
  CVE-2024-56592).
- bpf: Call free_htab_elem() after htab_unlock_bucket()
  (bsc#1235244 CVE-2024-56592).
- selftests/bpf: Clean up open-coded gettid syscall invocations
  (bsc#1235244 CVE-2024-56592).
- commit 1ed8f4f

- usb: chipidea: ci_hdrc_imx: decrement device's refcount in
  .remove() and in the error path of .probe() (git-fixes).
- commit 243c2cb

- vsock: Keep the binding until socket destruction (git-fixes)
- commit 545191e

- vsock: prevent null-ptr-deref in vsock_*[has_data|has_space] (CVE-2025-21666 bsc#1236680)
- commit 5667481

- vsock: reset socket state when de-assigning the transport (git-fixes)
- commit 70de10a

- vsock/virtio: cancel close work in the destructor (git-fixes)
- commit b47a8e2

- vsock/bpf: return early if transport is not assigned (CVE-2025-21670 bsc#1236685)
- commit 938e02d

- vsock/virtio: discard packets if the transport changes (CVE-2025-21669 bsc#1236683)
- commit 01b1ae3

- net/mlx5: Clear port select structure when fail to create (bsc#1236694 CVE-2025-21675)
- commit 97050c4

- mptcp: fix TCP options overflow. (bsc#1235914 CVE-2024-57882)
- commit bfacfe0

- mptcp: pm: Fix uaf in __timer_delete_sync (bsc#1231088 CVE-2024-46858)
- commit 2b80245

- kABI fix for net: defer final 'struct net' free in netns
  dismantle (CVE-2024-56658 bsc#1235441)
- commit fd18f29

- net: defer final 'struct net' free in netns dismantle
  (CVE-2024-56658 bsc#1235441).
- commit 5df7b43

- net: mana: Add get_link and get_link_ksettings in ethtool
  (bsc#1236761).
- commit 037abed

- virtio-mem: check if the config changed before fake offlining memory
  (git-fixes).
- commit 7c5b67f

- virtio-mem: keep retrying on offline_and_remove_memory() errors in Sub Block Mode (SBM)
  (git-fixes).
- commit 50036f1

- virtio-mem: convert most offline_and_remove_memory() errors to -EBUSY
  (git-fixes).
- commit cf4a9ad

- virtio-mem: remove unsafe unplug in Big Block Mode (BBM)
  (git-fixes).
- commit 7506a2e

- media: ov08x40: Fix hblank out of range issue (git-fixes).
- commit 6e44a14

- media: firewire: firedtv-avc.c: replace BUG with proper,
  error return (git-fixes).
- commit 658942c

- media: dvb: mb86a16: check the return value of mb86a16_read()
  (git-fixes).
- commit fc29200

- tty: xilinx_uartps: split sysrq handling (git-fixes).
- commit 1d9d1fd

- cifs: fix potential null pointer use in destroy_workqueue in
  init_cifs error path (bsc#1231432).
- commit 21eeced

- smb: cached directories can be more than root file handle
  (bsc#1231432).
- commit 2629c95

- smb3: retrying on failed server close (bsc#1231432).
- commit f1f31c8

- smb: prevent use-after-free due to open_cached_dir error paths
  (bsc#1231432, bsc#1234896, CVE-2024-53177).
- commit 741a327

- smb: Don't leak cfid when reconnect races with open_cached_dir
  (bsc#1231432, bsc#1234895, CVE-2024-53178).
- commit e22906f

- smb3: request handle caching when caching directories
  (bsc#1231432).
- commit 186ab6d

- cifs: new mount option called retrans (bsc#1231432).
- commit 000ea56

- cifs: open_cached_dir should not rely on primary channel
  (bsc#1231432).
- commit 056e43b

- cifs: commands that are retried should have replay flag set
  (bsc#1231432).
- commit d12c685

- cifs: helper function to check replayable error codes
  (bsc#1231432).
- commit 4a4d52e

- smb: client: extend smb2_compound_op() to accept more commands
  (bsc#1231432).
- commit e198fe7

- smb: client: reduce stack usage in smb2_query_info_compound()
  (bsc#1231432).
- commit 267f6c8

- smb: client: parse reparse point flag in create response
  (bsc#1231432).
- commit 1f48f01

- smb: client: make smb2_compound_op() return resp buffer on
  success (bsc#1231432).
- commit 14ca1d2

- smb: client: move some params to cifs_open_info_data
  (bsc#1231432).
- commit e3cf607

- smb: client: fix OOB in SMB2_query_info_init() (bsc#1231432).
- commit 1ebc808

- mm/compaction: fix UBSAN shift-out-of-bounds warning (git fixes
  (mm/compaction)).
- commit 6473a2a

- vfio/pci: Lock external INTx masking ops (bsc#1222803).
- commit 8c537c0

- gtp: Destroy device along with udp socket's netns dismantle
  (CVE-2025-21678 bsc#1236698).
- gtp: Use for_each_netdev_rcu() in gtp_genl_dump_pdp()
  (git-fixes).
- net: mana: Cleanup &amp;quot;mana&amp;quot; debugfs dir after cleanup of all
  children (bsc#1236760).
- r8169: enable SG/TSO on selected chip versions per default
  (bsc#1235874).
- net: mana: Enable debugfs files for MANA device (bsc#1236758).
- net: netvsc: Update default VMBus channels (bsc#1236757).
- commit 2caa23f

- cpufreq: imx6q: Don't disable 792 Mhz OPP unnecessarily
  (git-fixes).
- cpufreq: imx6q: don't warn for disabling a non-existing
  frequency (git-fixes).
- commit 42b12da

- Update
  patches.suse/nvme-tcp-Fix-I-O-queue-cpu-spreading-for-multiple-co.patch
  (git-fixes bsc#1224049).
- commit 6783feb

- cpufreq: qcom-nvmem: fix memory leaks in probe error paths
  (git-fixes).
- commit 3d6407c

- cpufreq: qcom-nvmem: Enable virtual power domain devices
  (git-fixes).
- commit b63737d

- xfs: Add error handling for xfs_reflink_cancel_cow_range
  (git-fixes).
- commit 1aaaa62

- xfs: Propagate errors from xfs_reflink_cancel_cow_range in
  xfs_dax_write_iomap_end (git-fixes).
- commit f8ad9a2

- net/mlx5e: Fix inversion dependency warning while enabling
  IPsec tunnel (CVE-2025-21674 bsc#1236688).
- net: fec: handle page_pool_dev_alloc_pages error (CVE-2025-21676
  bsc#1236696).
- eth: bnxt: always recalculate features after XDP clearing,
  fix null-deref (CVE-2025-21682 bsc#1236703).
- commit a806d7c

- cpufreq: qcom-nvmem: Simplify driver data allocation
  (stable-fixes).
- commit dc928a8

- NFSv4.2: mark OFFLOAD_CANCEL MOVEABLE (git-fixes).
- commit 151b149

- NFSv4.2: fix COPY_NOTIFY xdr buf size calculation (git-fixes).
- commit b286575

- ubifs: skip dumping tnc tree when zroot is null (git-fixes).
- commit f58c1e4

- afs: Fix the fallback handling for the YFS.RemoveFile2 RPC call
  (git-fixes).
- commit a1514a4

- afs: Fix cleanup of immediately failed async calls (git-fixes).
- commit addff98

- afs: Fix directory format encoding struct (git-fixes).
- commit 595632c

- afs: Fix EEXIST error returned from afs_rmdir() to be ENOTEMPTY
  (git-fixes).
- commit 39c4f67

- gfs2: Truncate address space when flipping GFS2_DIF_JDATA flag
  (git-fixes).
- commit e9c67fd

- nilfs2: fix possible int overflows in nilfs_fiemap()
  (git-fixes).
- commit 2d81bbb

- ipv4: ip_tunnel: Fix suspicious RCU usage warning in
  ip_tunnel_find() (CVE-2024-50304 bsc#1233522).
- commit 0aac3e1

- arm64: dts: rockchip: increase gmac rx_delay on rk3399-puma (git-fixes)
- commit 6bedda5

- arm64: tegra: Fix Tegra234 PCIe interrupt-map (git-fixes)
- commit 5678238

- arm64: tegra: Disable Tegra234 sce-fabric node (git-fixes)
- commit 3ba529a

- arm64: tegra: Fix typo in Tegra234 dce-fabric compatible (git-fixes)
- commit fe1f6b4

- arm64: Filter out SVE hwcaps when FEAT_SVE isn't implemented (git-fixes)
- commit 79b2b46

- netfilter: nft_payload: sanitize offset and length before
  calling skb_checksum() (CVE-2024-50251 bsc#1233248).
- commit d7e2f51

- net: fix crash when config small gso_max_size/gso_ipv4_max_size
  (CVE-2024-50258 bsc#1233221 CVE-2024-50258 bsc#1233221).
- commit a93195b

- arm64/sme: Move storage of reg_smidr to __cpuinfo_store_cpu() (git-fixes)
- commit 43c09a7

- arm64: Kconfig: Make SME depend on BROKEN for now (git-fixes bsc#1236245)
  Update arm64 default configuration file
- commit 1003b05

- arm64: dts: rockchip: Add sdmmc/sdio/emmc reset controls for RK3328 (git-fixes)
- commit cbbcd61

- net: inet6: do not leave a dangling sk pointer in inet6_create()
  (CVE-2024-56600 bsc#1235217).
- commit d23e8d7

- printk: Defer legacy printing when holding printk_cpu_sync
  (bsc#1236733).
- commit 8ea5df4

- printk: Add is_printk_legacy_deferred() (bsc#1236733).
- commit 15926fc

- nvme: fix bogus kzalloc() return check in
  nvme_init_effects_log() (git-fixes).
- commit ab15bce

- scsi: storvsc: Ratelimit warning logs to prevent VM denial of
  service (git-fixes).
- hyperv: Do not overlap the hvcall IO areas in get_vtl()
  (git-fixes).
- commit 20e731b

- nvme: Add error path for xa_store in nvme_init_effects
  (git-fixes).
- nvme: Add error check for xa_store in nvme_get_effects_log
  (git-fixes).
- nvme-tcp: Fix I/O queue cpu spreading for multiple controllers
  (git-fixes).
- nvmet: propagate npwg topology (git-fixes).
- commit f7cc3e5

- usbnet: ipheth: fix DPE OoB read (git-fixes).
- commit 9d2e9a7

- usbnet: ipheth: break up NCM header size computation
  (git-fixes).
- commit 2cdc4a6

- usbnet: ipheth: refactor NCM datagram loop (git-fixes).
- commit aade1ad

- workqueue: Add rcu lock check at the end of work item execution
  (bsc#1236732).
- commit 4c72d5a

- Move upstreamed sound patch into sorted section
- commit ca47985

- Input: atkbd - map F23 key to support default copilot shortcut
  (stable-fixes).
- Input: xpad - add unofficial Xbox 360 wireless receiver clone
  (stable-fixes).
- Input: xpad - add support for wooting two he (arm)
  (stable-fixes).
- Input: xpad - improve name of 8BitDo controller 2dc8:3106
  (stable-fixes).
- Input: xpad - add QH Electronics VID/PID (stable-fixes).
- Input: xpad - add support for Nacon Evol-X Xbox One Controller
  (stable-fixes).
- Input: xpad - add support for Nacon Pro Compact (stable-fixes).
- hwmon: (drivetemp) Set scsi command timeout to 10s
  (stable-fixes).
- drm/amd/display: Use HW lock mgr for PSR1 (stable-fixes).
- seccomp: Stub for !CONFIG_SECCOMP (stable-fixes).
- ASoC: samsung: Add missing depends on I2C (git-fixes).
- ASoC: samsung: Add missing selects for MFD_WM8994
  (stable-fixes).
- ASoC: wm8994: Add depends on MFD core (stable-fixes).
- ata: libata-core: Set ATA_QCFLAG_RTF_FILLED in fill_result_tf()
  (stable-fixes).
- commit c243755

- ASoC: acp: Support microphone from Lenovo Go S (stable-fixes).
- ALSA: usb-audio: Add delay quirk for iBasso DC07 Pro
  (stable-fixes).
- commit 7bec8fa

- kconfig: fix file name in warnings when loading
  KCONFIG_DEFCONFIG_LIST (git-fixes).
- genksyms: fix memory leak when the same symbol is read from
  * .symref file (git-fixes).
- genksyms: fix memory leak when the same symbol is added from
  source (git-fixes).
- ASoC: rockchip: i2s_tdm: Re-add the set_sysclk callback
  (git-fixes).
- commit 472aca3

- kABI workaround for struct auto_pin_cfg_item change (git-fixes).
- commit 43b97fb

- ALSA: hda: Fix headset detection failure due to unstable sort
  (git-fixes).
- commit 6dcca9b

- blacklist.conf: Not affected by CVE-2024-44932 and CVE-2024-44964
- Delete
  patches.suse/idpf-fix-UAFs-when-destroying-the-queues.patch.
- Delete
  patches.suse/idpf-fix-memory-leaks-and-crashes-while-performing-a.patch.
  This fixes bsc#1236628
- commit 3ac3069

- kcsan: Turn report_filterlist_lock into a raw_spinlock
  (CVE-2024-56610 bsc#1235390).
- commit d41073a

- io_uring/eventfd: ensure io_eventfd_signal() defers another
  RCU period (CVE-2025-21655 bsc#1236163).
- commit 4487b43

- Refresh
  patches.suse/io_uring-check-for-overflows-in-io_pin_pages.patch.
  There was an error on my backport of this patch that caused an Oops as
  soon as a pbuf is registered.
- commit 83010fb

- cpuidle: Avoid potential overflow in integer multiplication
  (git-fixes).
- commit 0568366

- cpufreq: intel_pstate: Make hwp_notify_lock a raw spinlock
  (git-fixes).
- commit ade7f79

- cpufreq: amd-pstate: remove global header file (git-fixes).
- commit be74a4f

- mm/rodata_test: use READ_ONCE() to read const variable
  (git-fixes).
- commit 915b6ed

- cpufreq: intel_pstate: Use HWP to initialize ITMT if CPPC is
  missing (git-fixes).
- commit 1e10ad3

- cpufreq: intel_pstate: fix pstate limits enforcement for
  adjust_perf call back (git-fixes).
- commit dd83446

- cpufreq: ACPI: Fix max-frequency computation (git-fixes).
- commit 54e5cf5

- cpufreq: Don't unregister cpufreq cooling on CPU hotplug
  (git-fixes).
- commit d893e3e

- rtc: zynqmp: Fix optional clock name property (git-fixes).
- rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read
  (git-fixes).
- PM: hibernate: Add error handling for syscore_suspend()
  (git-fixes).
- Bluetooth: L2CAP: accept zero as a special value for MTU
  auto-selection (git-fixes).
- Bluetooth: btnxpuart: Fix glitches seen in dual A2DP streaming
  (git-fixes).
- usbnet: ipheth: use static NDP16 location in URB (git-fixes).
- usbnet: ipheth: check that DPE points past NCM header
  (git-fixes).
- usbnet: ipheth: fix possible overflow in DPE length check
  (git-fixes).
- net: usb: rtl8150: enable basic endpoint checking (git-fixes).
- net: phy: c45-tjaxx: add delay between MDIO write and read in
  soft_reset (git-fixes).
- net: rose: fix timer races against user threads (git-fixes).
- NFC: nci: Add bounds checking in nci_hci_create_pipe()
  (git-fixes).
- docs: power: Fix footnote reference for Toshiba Satellite
  P10-554 (git-fixes).
- gpio: mxc: remove dead code after switch to DT-only (git-fixes).
- pm:cpupower: Add missing powercap_set_enabled() stub function
  (git-fixes).
- commit d7c0bf6

- io_uring: check for overflows in io_pin_pages (CVE-2024-53187
  bsc#1234947).
- commit 5155778

- brd: defer automatic disk creation until module initialization
  succeeds (CVE-2024-56693 bsc#1235418).
- commit b6cdeb6

- powerpc/pseries/eeh: Fix get PE state translation (bsc#1215199).
- commit b41af30

- ALSA: hda/realtek: Workaround for resume on Dell Venue 11 Pro
  7130 (bsc#1235686).
- commit 63a2d06

- Correct typos in patch-mainline versions in previous patches
- commit 9e305bb

- dmaengine: ti: edma: fix OF node reference leaks in edma_driver
  (git-fixes).
- regulator: core: Add missing newline character (git-fixes).
- commit a55a5c7

- Delete patches.suse/iommu-arm-smmu-Defer-probe-of-clients-after-smmu-dev.patch
  Reverted upstream by 97cb1fa02726 iommu/arm-smmu: Retire probe deferral
  workaround.
- commit 2dda00e

- virtio-blk: don't keep queue frozen during system suspend
  (CVE-2024-57946 bsc#1236247).
- commit bc49326

- netfilter: x_tables: fix LED ID check in led_tg_check()
  (CVE-2024-56650 bsc#1235430).
- commit e2ba4f9

- netfilter: nf_tables: validate family when identifying table
  via handle (bsc#1233778 ZDI-24-1454).
- commit 8a5e7e8

- driver core: class: Fix wild pointer dereferences in API
  class_dev_iter_next() (git-fixes).
- devcoredump: cleanup some comments (git-fixes).
- serial: sh-sci: Do not probe the serial port if its slot in
  sci_ports[] is in use (git-fixes).
- serial: sh-sci: Drop __initdata macro for port_cfg (git-fixes).
- serial: 8250: Adjust the timeout for FIFO mode (git-fixes).
- commit 3ee6c35

- VFS: use system_unbound_wq for delayed_mntput (bsc#1234683).
- commit 8e0a712

- RDMA/mlx5: Fix implicit ODP use after free (git-fixes)
- commit 45ca433

- RDMA/mlx5: Fix a race for an ODP MR which leads to CQE with error (git-fixes)
- commit 2c0d67d

- RDMA/rxe: Fix the warning &amp;quot;__rxe_cleanup+0x12c/0x170 [rdma_rxe]&amp;quot; (git-fixes)
- commit d370cc3

- RDMA/mlx5: Fix indirect mkey ODP page count (git-fixes)
- commit fffca3b

- RDMA/bnxt_re: Fix to drop reference to the mmap entry in case of error (git-fixes)
- commit 95b5d71

- RDMA/srp: Fix error handling in srp_add_port (git-fixes)
- commit d17536e

- RDMA/rxe: Fix mismatched max_msg_sz (git-fixes)
- commit 0c1e11b

- rdma/cxgb4: Prevent potential integer overflow on 32bit (git-fixes)
- commit c001bb0

- RDMA/mlx4: Avoid false error about access to uninitialized gids array (git-fixes)
- commit 61636fb

- RDMA/bnxt_re: Fix to export port num to ib_query_qp (git-fixes)
- commit 14d9179

- rcu/tree: Defer setting of jiffies during stall reset (git-fixes)
- commit 97d4114

- rcu-tasks: Pull sampling of -&amp;gt;percpu_dequeue_lim out of loop (git-fixes)
- commit 46965f9

- srcu: Only accelerate on enqueue time (git-fixes)
- commit 61de5d1

- srcu: Fix srcu_struct node grpmask overflow on 64-bit systems (git-fixes)
- commit 2ff5969

- rcu: Eliminate rcu_gp_slow_unregister() false positive (git-fixes)
- commit 0aacfbc

- rcu: Dump memory object info if callback function is invalid (git-fixes)
- commit a054e16

- rcuscale: Move rcu_scale_writer() (git-fixes)
- commit f5a8f5c

- PCI: microchip: Set inbound address translation for coherent
  or non-coherent mode (git-fixes).
- PCI: imx6: Deassert apps_reset in imx_pcie_deassert_core_reset()
  (git-fixes).
- PCI: imx6: Skip controller_id generation logic for i.MX7D
  (git-fixes).
- PCI: endpoint: pci-epf-test: Fix check for DMA MEMCPY test
  (git-fixes).
- PCI: dwc: ep: Prevent changing BAR size/flags in
  pci_epc_set_bar() (git-fixes).
- PCI: dwc: ep: Write BAR_MASK before iATU registers in
  pci_epc_set_bar() (git-fixes).
- genirq: Make handle_enforce_irqctx() unconditionally available
  (git-fixes).
- commit 9d69135

- x86/mm: Carve out INVLPG inline asm for use by others (git-fixes).
- commit af61fc0

- x86/amd_nb: Fix compile-testing without CONFIG_AMD_NB (git-fixes).
- commit 1b67735

- x86/cpu: Add Lunar Lake to list of CPUs with a broken MONITOR implementation (git-fixes).
- commit a22f80f

- x86/asm: Make serialize() always_inline (git-fixes).
- commit 7e805b9

- ibmvnic: Free any outstanding tx skbs during scrq reset
  (bsc#1226980).
- commit 82833f0

- drm/v3d: Assign job pointer to NULL before signaling the fence
  (git-fixes).
- iio: light: as73211: fix channel handling in only-color
  triggered buffer (git-fixes).
- intel_th: core: fix kernel-doc warnings (git-fixes).
- bus: mhi: host: Free mhi_buf vector inside
  mhi_alloc_bhie_table() (git-fixes).
- iio: iio-mux: kzalloc instead of devm_kzalloc to ensure page
  alignment (git-fixes).
- iio: adc: ad_sigma_delta: Handle CS assertion as intended in
  ad_sd_read_reg_raw() (git-fixes).
- misc: fastrpc: Fix copy buffer page size (git-fixes).
- misc: fastrpc: Fix registered buffer page address (git-fixes).
- misc: fastrpc: Deregister device nodes properly in error
  scenarios (git-fixes).
- VMCI: fix reference to ioctl-number.rst (git-fixes).
- drivers/card_reader/rtsx_usb: Restore interrupt based detection
  (git-fixes).
- uio: uio_dmem_genirq: check the return value of devm_kasprintf()
  (git-fixes).
- uio: Fix return value of poll (git-fixes).
- misc: misc_minor_alloc to use ida for all dynamic/misc dynamic
  minors (git-fixes).
- Revert &amp;quot;usb: gadget: u_serial: Disable ep before setting port to
  null to fix the crash caused by port being null&amp;quot; (stable-fixes).
- USB: serial: quatech2: fix null-ptr-deref in
  qt2_process_read_urb() (git-fixes).
- usb: typec: tcpm: set SRC_SEND_CAPABILITIES timeout to
  PD_T_SENDER_RESPONSE (git-fixes).
- usb: host: xhci-plat: Assign shared_hcd-&amp;gt;rsrc_start (git-fixes).
- usb: dwc3-am62: Fix an OF node leak in phy_syscon_pll_refclk()
  (git-fixes).
- usb: gadget: f_tcm: Don't prepare BOT write request twice
  (git-fixes).
- usb: gadget: f_tcm: ep_autoconfig with fullspeed endpoint
  (git-fixes).
- usb: gadget: f_tcm: Fix Get/SetInterface return value
  (git-fixes).
- usb: gadget: f_tcm: Decrement command ref count on cleanup
  (git-fixes).
- usb: gadget: f_tcm: Translate error to sense (git-fixes).
- usb: gadget: f_tcm: Don't free command immediately (git-fixes).
- power: ip5xxx_power: Fix return value on ADC read errors
  (git-fixes).
- pps: add an error check in parport_attach (git-fixes).
- pps: remove usage of the deprecated ida_simple_xx() API
  (stable-fixes).
- commit 15d6406

- Move upstreamed lpfc patches into sorted section
- commit c33f2a8

- Revert 0dd78566990 (&amp;quot;Disable ceph (jsc#PED-7242)&amp;quot;)
  Apparently, jsc#PED-7242 is only deprecate ceph for 15-SP6 and
  disable for 15-SP7.
  Revert the disabling.
- commit 4573861

- padata: add pd get/put refcnt helper (git-fixes).
- commit c209bf7

- padata: avoid UAF for reorder_work (git-fixes).
- padata: fix UAF in padata_reorder (git-fixes).
- commit 9cec1e0

- net: stmmac: dwmac-tegra: Read iommu stream id from device tree
  (CVE-2025-21663 bsc#1236260).
- commit fc91755

- selftests/mm/cow: modify the incorrect checking parameters
  (git-fixes).
- maple_tree: simplify split calculation (git-fixes).
- latencytop: use correct kernel-doc format for func params
  (git-fixes).
- lib/inflate.c: remove dead code (git-fixes).
- commit 2970302

- remoteproc: core: Fix ida_free call while not allocated
  (git-fixes).
- mtd: spinand: Remove write_enable_op() in markbad() (git-fixes).
- mtd: onenand: Fix uninitialized retlen in do_otp_read()
  (git-fixes).
- PCI: rcar-ep: Fix incorrect variable used when calling
  devm_request_mem_region() (git-fixes).
- PCI: dwc: Always stop link in the dw_pcie_suspend_noirq
  (git-fixes).
- PCI: endpoint: pci-epf-test: Set dma_chan_rx pointer to NULL
  on error (git-fixes).
- PCI: endpoint: Finish virtual EP removal in
  pci_epf_remove_vepf() (git-fixes).
- PCI: endpoint: Destroy the EPC device in devm_pci_epc_destroy()
  (git-fixes).
- PCI: Avoid putting some root ports into D3 on TUXEDO Sirius Gen1
  (git-fixes).
- media: dvb-usb-v2: af9035: fix ISO C90 compilation error on
  af9035_i2c_master_xfer (git-fixes).
- staging: media: imx: fix OF node leak in
  imx_media_add_of_subdevs() (git-fixes).
- media: nxp: imx8-isi: fix v4l2-compliance test errors
  (git-fixes).
- media: uvcvideo: Propagate buf-&amp;gt;error to userspace (git-fixes).
- media: uvcvideo: Remove dangling pointers (git-fixes).
- media: uvcvideo: Remove redundant NULL assignment (git-fixes).
- media: uvcvideo: Only save async fh if success (git-fixes).
- media: uvcvideo: Support partial control reads (git-fixes).
- media: uvcvideo: Fix event flags in uvc_ctrl_send_events
  (git-fixes).
- media: uvcvideo: Fix double free in error path (git-fixes).
- media: uvcvideo: Fix crash during unbind if gpio unit is in use
  (git-fixes).
- staging: media: max96712: fix kernel oops when removing module
  (git-fixes).
- media: camif-core: Add check for clk_enable() (git-fixes).
- media: mipi-csis: Add check for clk_enable() (git-fixes).
- media: ov5640: fix get_light_freq on auto (git-fixes).
- media: mc: fix endpoint iteration (git-fixes).
- media: i2c: ov9282: Correct the exposure offset (git-fixes).
- media: ccs: Fix cleanup order in ccs_probe() (git-fixes).
- media: imx296: Add standby delay during probe (git-fixes).
- media: i2c: imx412: Add missing newline to prints (git-fixes).
- media: ccs: Clean up parsed CCS static data on parse failure
  (git-fixes).
- media: ccs: Fix CCS static data parsing for large block sizes
  (git-fixes).
- media: marvell: Add check for clk_enable() (git-fixes).
- media: lmedm04: Handle errors for lme2510_int_read (git-fixes).
- media: rc: iguanair: handle timeouts (git-fixes).
- media: rkisp1: Fix unused value issue (git-fixes).
- media: imx-jpeg: Fix potential error pointer dereference in
  detach_pm() (git-fixes).
- commit 059dbb0

- ALSA: hda/realtek: Enable Mute LED on HP Laptop 14s-fq1xxx
  (stable-fixes).
- ALSA: usb-audio: Add delay quirk for USB Audio Device
  (stable-fixes).
- ALSA: hda/realtek: Enable headset mic on Positivo C6400
  (stable-fixes).
- commit 744cb45

- mailbox: tegra-hsp: Clear mailbox before using message
  (git-fixes).
- soc: qcom: socinfo: Avoid out of bounds read of serial number
  (git-fixes).
- soc: qcom: smem_state: fix missing of_node_put in error path
  (git-fixes).
- soc: mediatek: mtk-devapc: Fix leaking IO map on error paths
  (git-fixes).
- memory: tegra20-emc: fix an OF node reference bug in
  tegra_emc_find_node_by_ram_code() (git-fixes).
- soc: atmel: fix device_node release in atmel_soc_device_init()
  (git-fixes).
- fbdev: omapfb: Fix an OF node leak in
  dss_of_port_get_parent_device() (git-fixes).
- ASoC: Intel: avs: Fix theoretical infinite loop (git-fixes).
- ASoC: sun4i-spdif: Add clock multiplier settings (git-fixes).
- ALSA: hda/realtek - Fixed headphone distorted sound on Acer
  Aspire A115-31 laptop (git-fixes).
- crypto: iaa - Fix IAA disabling that occurs when sync_mode is
  set to 'async' (git-fixes).
- crypto: ixp4xx - fix OF node reference leaks in
  init_ixp_crypto() (git-fixes).
- crypto: qce - fix priority to be less than ARMv8 CE (git-fixes).
- crypto: qce - unregister previously registered algos in error
  path (git-fixes).
- crypto: qce - fix goto jump in error path (git-fixes).
- crypto: caam - use JobR's space to access page 0 regs
  (git-fixes).
- pinctrl: amd: Take suspend type into consideration which pins
  are non-wake (git-fixes).
- pinctrl: samsung: fix fwnode refcount cleanup if
  platform_get_irq_optional() fails (git-fixes).
- commit b034543

- Move upstreamed ppc patch into sorted section
- commit d058975

- Move upstreamed TPM patch into sorted section
- commit ccb7b48

- octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c (CVE-2024-56728 bsc#1235656)
- commit acc444a

- octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c (CVE-2024-56727 bsc#1235583)
- commit b6e61cf

- octeontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.c (CVE-2024-56726 bsc#1235582)
- commit ac2994c

- octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dcbnl.c (CVE-2024-56725 bsc#1235578)
- commit 4f995f2

- octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.c (CVE-2024-56707 bsc#1235545)
- commit 67e8754

- octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.c (CVE-2024-56679 bsc#1235498)
- commit becbeeb

- drm/amd/display: Fix out-of-bounds access in 'dcn21_link_encoder_create' (CVE-2024-56608 bsc#1235487)
- commit df4e9dd

- dm thin: make get_first_thin use rcu-safe list first function (CVE-2025-21664 bsc#1236262)
- commit 83d356e

- selinux: ignore unknown extended permissions (CVE-2024-57931 bsc#1236192)
- commit 4334198

- net_sched: cls_flow: validate TCA_FLOW_RSHIFT attribute (CVE-2025-21653 bsc#1236161)
- commit 9089d3b

- ipvlan: Fix use-after-free in ipvlan_get_iflink() (CVE-2025-21652 bsc#1236160)
- commit 8201e7e

- net/sctp: Prevent autoclose integer overflow in sctp_association_init() (CVE-2024-57938 bsc#1236182)
- commit 338cf1f

- topology: Keep the cpumask unchanged when printing cpumap (CVE-2024-57917 bsc#1236127)
- commit 1d17273

- mm: vmscan: account for free pages to prevent infinite Loop in throttle_direct_reclaim() (CVE-2024-57884 bsc#1235948)
- commit abc82c3

- netrom: check buffer length before accessing it (CVE-2024-57802 bsc#1235941)
- commit 606eed5

- ionic: Fix netdev notifier unregister on failure (CVE-2024-56715 bsc#1235612)
- commit 28b55e0

- sched/fair: Fix value reported by hot tasks pulled in
  /proc/schedstat -kabi (bsc#1235865).
- commit a0069bc

- wifi: ath12k: fix tx power, max reg power update to firmware
  (git-fixes).
- wifi: mt76: mt7996: fix ldpc setting (git-fixes).
- wifi: mt76: mt7996: fix definition of tx descriptor (git-fixes).
- wifi: mt76: mt7996: fix incorrect indexing of MIB FW event
  (git-fixes).
- wifi: mt76: mt7996: fix HE Phy capability (git-fixes).
- wifi: mt76: mt7996: fix the capability of reception of EHT MU
  PPDU (git-fixes).
- wifi: mt76: mt7996: add max mpdu len capability (git-fixes).
- wifi: mt76: mt7996: fix register mapping (git-fixes).
- wifi: mt76: mt7915: fix register mapping (git-fixes).
- wifi: mt76: mt7915: firmware restart on devices with a second
  pcie link (git-fixes).
- wifi: mt76: mt7996: fix rx filter setting for bfee functionality
  (git-fixes).
- wifi: mt76: mt7915: fix overflows seen when writing limit
  attributes (git-fixes).
- wifi: mt76: mt7996: fix overflows seen when writing limit
  attributes (git-fixes).
- wifi: mt76: mt7915: add module param to select 5 GHz or 6 GHz
  on MT7916 (git-fixes).
- wifi: mt76: mt7921: fix using incorrect group cipher after
  disconnection (git-fixes).
- wifi: mt76: mt76u_vendor_request: Do not print error messages
  when -EPROTO (git-fixes).
- commit f15e8b4

- tools: Sync if_xdp.h uapi tooling header (git-fixes).
- selftests/landlock: Fix error message (git-fixes).
- selftests: harness: fix printing of mismatch values in
  __EXPECT() (git-fixes).
- spi: zynq-qspi: Add check for clk_enable() (git-fixes).
- wifi: mt76: mt7915: Fix mesh scan on MT7916 DBDC (git-fixes).
- wifi: mt76: mt7925: fix off by one in mt7925_load_clc()
  (git-fixes).
- wifi: rtw89: mcc: consider time limits not divisible by 1024
  (git-fixes).
- wifi: rtlwifi: rtl8821ae: Fix media status report (git-fixes).
- wifi: cfg80211: adjust allocation of colocated AP data
  (git-fixes).
- wifi: mac80211: don't flush non-uploaded STAs (git-fixes).
- wifi: mac80211: Fix common size calculation for ML element
  (git-fixes).
- wifi: mac80211: fix tid removal during mesh forwarding
  (git-fixes).
- wifi: mac80211: prohibit deactivating all links (git-fixes).
- wifi: iwlwifi: fw: read STEP table from correct UEFI var
  (git-fixes).
- wifi: wlcore: fix unbalanced pm_runtime calls (git-fixes).
- wifi: rtlwifi: pci: wait for firmware loading before releasing
  memory (git-fixes).
- wifi: rtlwifi: fix memory leaks and invalid access at probe
  error path (git-fixes).
- wifi: rtlwifi: destroy workqueue at rtl_deinit_core (git-fixes).
- wifi: rtlwifi: remove unused check_buddy_priv (git-fixes).
- wifi: rtlwifi: usb: fix workqueue leak when probe fails
  (git-fixes).
- wifi: rtlwifi: fix init_sw_vars leak when probe fails
  (git-fixes).
- wifi: rtlwifi: wait for firmware loading before releasing memory
  (git-fixes).
- wifi: rtlwifi: rtl8192se: rise completion of firmware loading
  as last step (git-fixes).
- wifi: rtlwifi: do not complete firmware loading needlessly
  (git-fixes).
- wifi: rtlwifi: rtl8821ae: phy: restore removed code to fix
  infinite loop (git-fixes).
- wifi: brcmfmac: add missing header include for brcmf_dbg
  (git-fixes).
- wifi: ath11k: cleanup struct ath11k_mon_data (git-fixes).
- wifi: wcn36xx: fix channel survey memory allocation size
  (git-fixes).
- wifi: ath11k: Fix unexpected return buffer manager error for
  WCN6750/WCN6855 (git-fixes).
- selinux: Fix SCTP error inconsistency in selinux_socket_bind()
  (git-fixes).
- commit 40f350b

- ktest.pl: Fix typo &amp;quot;accesing&amp;quot; (git-fixes).
- ktest.pl: Fix typo in comment (git-fixes).
- ktest.pl: Remove unused declarations in run_bisect_test function
  (git-fixes).
- ktest.pl: Check kernelrelease return in get_version (git-fixes).
- landlock: Handle weird files (git-fixes).
- samples/landlock: Fix possible NULL dereference in parse_path()
  (git-fixes).
- selftests: timers: clocksource-switch: Adapt progress to
  kselftest framework (git-fixes).
- selftest: media_tests: fix trivial UAF typo (git-fixes).
- Input: davinci-keyscan - remove leftover header (git-fixes).
- HID: core: Fix assumption that Resolution Multipliers must be
  in Logical Collections (git-fixes).
- HID: fix generic desktop D-Pad controls (git-fixes).
- HID: hid-thrustmaster: Fix warning in thrustmaster_probe by
  adding endpoint check (git-fixes).
- HID: multitouch: fix support for Goodix PID 0x01e9 (git-fixes).
- Revert &amp;quot;HID: multitouch: Add support for lenovo Y9000P Touchpad&amp;quot;
  (stable-fixes).
- ipmi: ssif_bmc: Fix new request loss when bmc ready for a
  response (git-fixes).
- ipmi: ipmb: Add check devm_kasprintf() returned value
  (git-fixes).
- pwm: stm32: Add check for clk_enable() (git-fixes).
- pwm: stm32-lp: Add check for clk_enable() (git-fixes).
- leds: netxbig: Fix an OF node reference leak in
  netxbig_leds_get_of_pdata() (git-fixes).
- leds: lp8860: Write full EEPROM, not only half of it
  (git-fixes).
- HID: hid-sensor-hub: don't use stale platform-data on remove
  (git-fixes).
- regulator: of: Implement the unwind path of of_regulator_match()
  (git-fixes).
- net/rose: prevent integer overflows in rose_setsockopt()
  (git-fixes).
- drm/msm: don't clean up priv-&amp;gt;kms prematurely (git-fixes).
- selftests/powerpc: Fix argument order to timer_sub()
  (git-fixes).
- selftests/alsa: Fix circular dependency involving global-timer
  (stable-fixes).
- ktest.pl: Avoid false positives with grub2 skip regex
  (stable-fixes).
- ktest: force $buildonly = 1 for 'make_warnings_file' test type
  (stable-fixes).
- commit 3e5bf1b

- drm/msm: Check return value of of_dma_configure() (git-fixes).
- drm/msm/dpu: link DSPP_2/_3 blocks on SM8550 (git-fixes).
- drm/msm/dpu: link DSPP_2/_3 blocks on SM8350 (git-fixes).
- drm/msm/dpu: link DSPP_2/_3 blocks on SM8250 (git-fixes).
- drm/msm/dpu: link DSPP_2/_3 blocks on SC8180X (git-fixes).
- drm/msm/dpu: link DSPP_2/_3 blocks on SM8150 (git-fixes).
- drm/msm/dp: set safe_to_exit_level before printing it
  (git-fixes).
- drm/amdgpu: tear down ttm range manager for doorbell in
  amdgpu_ttm_fini() (git-fixes).
- drm/etnaviv: Fix page property being used for non writecombine
  buffers (git-fixes).
- Revert &amp;quot;drm/i915/dpt: Make DPT object unshrinkable&amp;quot;
  (stable-fixes).
- drm/amdgpu: simplify return statement in amdgpu_ras_eeprom_init
  (git-fixes).
- drm/amdgpu/vcn: reset fw_shared under SRIOV (git-fixes).
- drm/amdgpu: Fix potential NULL pointer dereference in
  atomctrl_get_smc_sclk_range_table (git-fixes).
- drm/amd/pm: Fix an error handling path in
  vega10_enable_se_edc_force_stall_config() (git-fixes).
- drm/bridge: it6505: Change definition of AUX_FIFO_MAX_SIZE
  (git-fixes).
- drm/rockchip: vop2: Check linear format for Cluster windows
  on rk3566/8 (git-fixes).
- drm/rcar-du: dsi: Fix PHY lock bit check (git-fixes).
- drm/rockchip: vop2: Fix the mixer alpha setup for layer 0
  (git-fixes).
- drm/rockchip: vop2: Fix cluster windows alpha ctrl regsiters
  offset (git-fixes).
- commit 2f1e321

- ACPI: fan: cleanup resources in the error path of .probe()
  (git-fixes).
- cpupower: fix TSC MHz calculation (git-fixes).
- Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc
  (git-fixes).
- Align git commit ID abbreviation guidelines and checks
  (git-fixes).
- drm/tidss: Clear the interrupt status for interrupts being
  disabled (git-fixes).
- drm/tidss: Fix issue in irq handling causing irq-flood issue
  (git-fixes).
- drm/v3d: Stop active perfmon if it is being destroyed
  (git-fixes).
- drm/rockchip: cdn-dp: Use drm_connector_helper_hpd_irq_event()
  (git-fixes).
- commit 737a47e

- Input: bbnsm_pwrkey - add remove hook (git-fixes).
- drm/i915/fb: Relax clear color alignment to 64 bytes
  (stable-fixes).
- drm/amdgpu: always sync the GFX pipe on ctx switch
  (stable-fixes).
- ACPI: resource: acpi_dev_irq_override(): Check DMI match last
  (stable-fixes).
- mac802154: check local interfaces before deleting sdata list
  (stable-fixes).
- selftests: tc-testing: reduce rshift value (stable-fixes).
- kheaders: Ignore silly-rename files (stable-fixes).
- commit cbbd806

- Drop PCI patch that caused a regression
  Deleted:
  patches.suse/PCI-Use-preserve_config-in-place-of-pci_flags.patch
- commit 30fb9e7

- sched/fair: Fix value reported by hot tasks pulled in
  /proc/schedstat (bsc#1235865).
- commit 9837653

- Update
  patches.suse/ALSA-seq-oss-Fix-races-at-processing-SysEx-messages.patch
  (stable-fixes CVE-2024-57893 bsc#1235920).
- Update
  patches.suse/RDMA-bnxt_re-Fix-max-SGEs-for-the-Work-Request.patch
  (git-fixes CVE-2024-57936 bsc#1236181).
- Update
  patches.suse/RDMA-hns-Fix-accessing-invalid-dip_ctx-during-destro.patch
  (git-fixes CVE-2024-57935 bsc#1236180).
- Update
  patches.suse/RDMA-rtrs-Ensure-ib_sge-list-is-accessible.patch
  (git-fixes CVE-2024-36476 bsc#1235902).
- Update
  patches.suse/RDMA-uverbs-Prevent-integer-overflow-issue.patch
  (git-fixes CVE-2024-57890 bsc#1235919).
- Update patches.suse/afs-Fix-the-maximum-cell-name-length.patch
  (git-fixes CVE-2025-21646 bsc#1236168).
- Update
  patches.suse/arm64-ptrace-fix-partial-SETREGSET-for-NT_ARM_TAGGED_ADDR_CTRL.patch
  (git-fixes CVE-2024-57874 bsc#1235808).
- Update
  patches.suse/cpufreq-CPPC-Fix-possible-null-ptr-deref-for-cppc_ge.patch
  (git-fixes CVE-2024-53230 bsc#1235976).
- Update
  patches.suse/cpufreq-CPPC-Fix-possible-null-ptr-deref-for-cpufreq.patch
  (git-fixes CVE-2024-53231 bsc#1235977).
- Update
  patches.suse/drm-adv7511-Fix-use-after-free-in-adv7533_attach_dsi.patch
  (git-fixes CVE-2024-57887 bsc#1235952).
- Update
  patches.suse/drm-amd-display-Add-check-for-granularity-in-dml-cei.patch
  (stable-fixes CVE-2024-57922 bsc#1236080).
- Update
  patches.suse/drm-amdkfd-Correct-the-migration-DMA-map-direction.patch
  (stable-fixes CVE-2024-57897 bsc#1235969).
- Update
  patches.suse/drm-dp_mst-Ensure-mst_primary-pointer-is-valid-in-dr.patch
  (stable-fixes CVE-2024-57798 bsc#1235818).
- Update
  patches.suse/drm-dp_mst-Fix-resetting-msg-rx-state-after-topology.patch
  (git-fixes CVE-2024-57876 bsc#1235806).
- Update
  patches.suse/drm-mediatek-Set-private-all_drm_private-i-drm-to-NU.patch
  (git-fixes CVE-2024-57926 bsc#1236082).
- Update
  patches.suse/exfat-fix-the-infinite-loop-in-exfat_readdir.patch
  (git-fixes CVE-2024-57940 bsc#1236227).
- Update
  patches.suse/hwmon-drivetemp-Fix-driver-producing-garbage-data-wh.patch
  (git-fixes CVE-2025-21656 bsc#1236248).
- Update
  patches.suse/iio-adc-at91-call-input_free_device-on-allocated-iio.patch
  (git-fixes CVE-2024-57904 bsc#1236078).
- Update
  patches.suse/iio-adc-rockchip_saradc-fix-information-leak-in-trig.patch
  (git-fixes CVE-2024-57907 bsc#1236090).
- Update
  patches.suse/iio-adc-ti-ads8688-fix-information-leak-in-triggered.patch
  (git-fixes CVE-2024-57906 bsc#1236088).
- Update
  patches.suse/iio-dummy-iio_simply_dummy_buffer-fix-information-le.patch
  (git-fixes CVE-2024-57911 bsc#1236098).
- Update
  patches.suse/iio-imu-kmx61-fix-information-leak-in-triggered-buff.patch
  (git-fixes CVE-2024-57908 bsc#1236091).
- Update
  patches.suse/iio-light-vcnl4035-fix-information-leak-in-triggered.patch
  (git-fixes CVE-2024-57910 bsc#1236097).
- Update
  patches.suse/iio-pressure-zpa2326-fix-information-leak-in-trigger.patch
  (git-fixes CVE-2024-57912 bsc#1236101).
- Update
  patches.suse/jffs2-Prevent-rtime-decompress-memory-corruption.patch
  (git-fixes CVE-2024-57850 bsc#1235812).
- Update
  patches.suse/misc-microchip-pci1xxxx-Resolve-kernel-panic-during-.patch
  (git-fixes CVE-2024-57916 bsc#1236125).
- Update
  patches.suse/net-wwan-t7xx-Fix-FSM-command-timeout-issue.patch
  (git-fixes CVE-2024-39282 bsc#1235903).
- Update
  patches.suse/netfilter-nf_tables-adapt-set-backend-to-use-G.patch
  (bsc#1012628 CVE-2023-52923 bsc#1236104).
- Update patches.suse/nilfs2-prevent-use-of-deleted-inode.patch
  (git-fixes CVE-2024-53690 bsc#1235842).
- Update
  patches.suse/platform-x86-amd-pmc-Only-disable-IRQ1-wakeup-where-.patch
  (git-fixes CVE-2025-21645 bsc#1236131).
- Update
  patches.suse/powerpc-pseries-vas-Add-close-callback-in-vas_vm_ops.patch
  (bsc#1234825 CVE-2024-56765 bsc#1235643).
- Update
  patches.suse/s390-cpum_sf-Handle-CPU-hotplug-remove-during-sampling.patch
  (git-fixes CVE-2024-57849 bsc#1235814).
- Update
  patches.suse/usb-gadget-f_fs-Remove-WARN_ON-in-functionfs_bind.patch
  (git-fixes CVE-2024-57913 bsc#1236102).
- Update
  patches.suse/usb-gadget-u_serial-Disable-ep-before-setting-port-t.patch
  (git-fixes CVE-2024-57915 bsc#1236120).
- Update
  patches.suse/wifi-mac80211-fix-mbss-changed-flags-corruption-on-3.patch
  (stable-fixes CVE-2024-57899 bsc#1235924).
- Update
  patches.suse/workqueue-Do-not-warn-when-cancelling-WQ_MEM_RECLAIM-work-from-WQ_MEM_RECLAIM-worker.patch
  (bsc#1235416 CVE-2024-57888 bsc#1235918).
- commit 56e243f

- net: inet: do not leave a dangling sk pointer in inet_create()
  (CVE-2024-56601 bsc#1235230).
- commit 959586f

- usb: typec: fix pm usage counter imbalance in ucsi_ccg_sync_control() (bsc#1235001)
- commit 8b4d1ad

- usb: typec: fix potential array underflow in ucsi_ccg_sync_control() (CVE-2024-53203 bsc#1235001)
- commit 601cb11

- net: add more sanity checks to qdisc_pkt_len_init()
  (CVE-2024-49948 bsc#1232161).
- commit 940829f

- bpf,perf: Fix invalid prog_array access in perf_event_detach_bpf_prog (CVE-2024-56665 bsc#1235489)
- commit b2f97f8

- gso: fix udp gso fraglist segmentation after pull from frag_list
  (CVE-2024-49978 bsc#1232101).
- commit 8453570

- powerpc/powernv/pci: Remove last IODA1 defines (bsc#1220711
  ltc#205755).
- powerpc/powernv/pci: Remove MVE code (bsc#1220711 ltc#205755).
- powerpc/powernv/pci: Remove ioda1 support (bsc#1220711
  ltc#205755).
- commit 5733e6d

- powerpc/iommu: Move pSeries specific functions to
  pseries/iommu.c (bsc#1220711 ltc#205755).
- powerpc/iommu: Only build sPAPR access functions on pSeries
  (bsc#1220711 ltc#205755).
- commit 1165a9d

- ceph: improve error handling and short/overflow-read logic in
  __ceph_sync_read() (bsc#1228592).
- commit b40380c

- doc/README.SUSE: Point to the updated version of LKMPG
- commit 624b259

- Input: bbnsm_pwrkey - fix missed key press after suspend
  (git-fixes).
- commit 51a70b3

- x86/fpu: Ensure shadow stack is active before &amp;quot;getting&amp;quot;
  registers (CVE-2025-21632 bsc#1236106).
- commit 6ea3a8f

- net: restrict SO_REUSEPORT to inet sockets (bsc#1235967 CVE-2024-57903)
- commit 0b70e79

- net: hns3: fix kernel crash when 1588 is sent on HIP08 devices (bsc#1236143 CVE-2025-21649)
- commit ab51b8f

- net/mlx5: Fix variable not being completed when function returns (bsc#1236198 CVE-2025-21662)
- commit 766ce3e

- net: hns3: fixed hclge_fetch_pf_reg accesses bar space out of
  bounds issue (CVE-2025-21650 bsc#1236144).
- net: hns3: Support tlv in regs data for HNS3 VF driver
  (CVE-2025-21650 bsc#1236144).
- commit d07cfee

- tracing: Prevent bad count for tracing_cpumask_write (CVE-2024-56763 bsc#1235638)
- commit b7a1a0d

- dccp: Fix memory leak in dccp_feat_change_recv (CVE-2024-56643 bsc#1235132)
- commit 13d2c8a

- iommu/arm-smmu: Defer probe of clients after smmu device bound (CVE-2024-56568 bsc#1235032)
- commit cd5e85b

- EDAC/igen6: Avoid segmentation fault on module unload (CVE-2024-56708 bsc#1235564)
- commit cbccd47

- net/smc: initialize close_work early to avoid warning (CVE-2024-56641 bsc#1235526)
- commit 075f0f7

- EDAC/{i10nm,skx,skx_common}: Support UV systems (bsc#1234693).
- commit 6767706

- net: hns3: don't auto enable misc vector (CVE-2025-21651
  bsc#1236145).
- gve: guard XSK operations on the existence of queues
  (CVE-2024-57933 bsc#1236178).
- gve: guard XDP xmit NDO on existence of xdp queues
  (CVE-2024-57932 bsc#1236190).
- commit 4cf5801

- mm: memory-failure: remove unneeded PageHuge() check
  (git-fixes).
- commit 7ff9700

- powerpc/pseries/iommu: IOMMU incorrectly marks MMIO range in DDW
  (bsc#1218470 ltc#204531).
- commit 7a7f1e1

- mm/memory-failure: use raw_spinlock_t in struct
  memory_failure_cpu (git-fixes).
- commit 25daa9d

- mm/memory-failure: fix crash in split_huge_page_to_list from
  soft_offline_page (git-fixes).
- commit 044809f

- memory-failure: use a folio in me_huge_page() (git-fixes).
- commit a51c830

- mm/memory-failure: cast index to loff_t before shifting it
  (git-fixes).
- commit 4552d04

- mm/memory-failure: check the mapcount of the precise page
  (git-fixes).
- commit 08d463b

- mm/memory-failure: pass the folio and the page to
  collect_procs() (git-fixes).
- commit e29780e

- mm: convert DAX lock/unlock page to lock/unlock folio
  (git-fixes).
- commit 4b2c66d

- mm: memory-failure: fix potential page refcnt leak in
  memory_failure() (git-fixes).
- commit 2df790d

- mm: memory-failure: fix race window when trying to get hugetlb
  folio (git-fixes).
- commit fdf1377

- mm: memory-failure: fetch compound head after extra page refcnt
  is held (git-fixes).
- commit dea0e54

- mm: memory-failure: ensure moving HWPoison flag to the raw
  error pages (git-fixes).
- commit 8250e5e

- mm/migrate: make migrate_pages_batch() stats consistent
  (git-fixes).
  Refreshed:
  patches.suse/mm-migrate-fix-deadlock-in-migrate_pages_batch-on-la.patch
- commit 69ecdc4

- s390/cio: rename bitmap_size() -&amp;gt; idset_bitmap_size()
  (git-fixes bsc#1236205).
- commit 07eeeda

- s390/vfio-ap: Remove gmap_convert_to_secure() from vfio_ap_ops
  (git-fixes bsc#1236203).
- commit 950d01b

- s390/iucv: fix receive buffer virtual vs physical address
  confusion (git-fixes bsc#1236200).
- commit 976f377

- s390/smp,mcck: fix early IPI handling (git-fixes bsc#1236199).
- commit 686f749

- KVM: x86: Play nice with protected guests in
  complete_hypercall_exit() (CVE-2024-55881 bsc#1235745).
- commit 4bd067f

- netfilter: ipset: Hold module reference while requesting a module (CVE-2024-56637 bsc#1235523)
- commit 53ff17c

- btrfs: fix use-after-free when COWing tree bock and tracing
  is enabled (bsc#1235645 CVE-2024-56759).
- btrfs: flush delalloc workers queue before stopping cleaner
  kthread during unmount (bsc#1235965 CVE-2024-57896).
- btrfs: rename and export __btrfs_cow_block() (bsc#1235645
  CVE-2024-56759).
- btrfs: use round_down() to align block offset at
  btrfs_cow_block() (bsc#1235645 CVE-2024-56759).
- btrfs: remove noinline attribute from btrfs_cow_block()
  (bsc#1235645 CVE-2024-56759).
- commit 503809f

- geneve: do not assume mac header is set in geneve_xmit_skb() (CVE-2024-56636 bsc#1235520)
- commit 3073d9c

- net: avoid potential UAF in default_operstate() (CVE-2024-56635 bsc#1235519)
- commit 37cf286

- dm array: fix releasing a faulty array block twice in
  dm_array_cursor_end (bsc#1236096, CVE-2024-57929).
- commit 38c0041

- net: lapb: increase LAPB_HEADER_LEN (CVE-2024-56659 bsc#1235439)
- commit e4681a0

- net: enetc: Do not configure preemptible TCs if SIs do not support (CVE-2024-56649 bsc#1235449)
- commit 4181889

- smb: Initialize cfid-&amp;gt;tcon before performing network ops (CVE-2024-56729 bsc#1235503)
- commit fd558fd

- mm/migrate: fix kernel BUG at mm/compaction.c:2761! (git-fixes).
  Refreshed: patches.suse/mm-migrate-fix-deadlock-in-migrate_pages_batch-on-la.patch
- commit 7d17ae8

- series.conf: temporarily disable upstream patch
  patches.suse/ocfs2-fix-UBSAN-warning-in-ocfs2_verify_volume.patch
  (bsc#1236138)
- commit 9179570

- mm/migrate: putback split folios when numa hint migration fails
  (git-fixes).
- commit 0acef71

- vmscan,migrate: fix page count imbalance on node stats when
  demoting pages (git-fixes).
- commit 4d259d3

- memory tiering: count PGPROMOTE_SUCCESS when mem tiering is
  enabled (git-fixes).
- commit 86638ef

- mm/migrate: fix deadlock in migrate_pages_batch() on large
  folios (git-fixes).
- commit a0d118b

- mm/migrate: split source folio if it is on deferred split list
  (git-fixes).
- commit 0fa5f5f

- mm/migrate: correct nr_failed in migrate_pages_sync()
  (git-fixes).
- commit 3743659

- mm,page_owner: don't remove __GFP_NOLOCKDEP in
  add_stack_record_to_list (git-fixes).
- commit 26a8c23

- mm/page_owner: remove free_ts from page_owner output
  (git-fixes).
- commit dfa6a27

- stackdepot: respect __GFP_NOLOCKDEP allocation flag (git-fixes).
- commit a04bd5d

- stackdepot: rename pool_index to pool_index_plus_1 (git-fixes).
- commit ff2e445

- lib/stackdepot: print disabled message only if truly disabled
  (git-fixes).
- commit cfe7741

- RDMA/bnxt_re: Fix max SGEs for the Work Request (git-fixes)
- commit 7879380

- RDMA/bnxt_re: Fix MSN table size for variable wqe mode (git-fixes)
- commit fe21e4e

- RDMA/bnxt_re: Add send queue size check for variable wqe (git-fixes)
- commit 3178b0e

- RDMA/bnxt_re: Fix the max WQEs used in Static WQE mode (git-fixes)
- commit eeedd44

- RDMA/bnxt_re: Fix the max WQE size for static WQE support (git-fixes)
- commit a1e1198

- mm/memory_hotplug: use pfn math in place of direct struct page
  manipulation (git-fixes).
- commit 120d675

- mm/memory_hotplug: add missing mem_hotplug_lock (git-fixes).
- commit 86cb612

- mm/memory_hotplug: fix error handling in add_memory_resource()
  (git-fixes).
- commit 3ebdf6a

- mm/memory_hotplug: prevent accessing by index=-1 (git-fixes).
- commit c68beb1

- RDMA/bnxt_re: Add support for Variable WQE in Genp7 adapters (git-fixes)
  Refresh patches:
  - patches.suse/RDMA-bnxt_re-Disable-use-of-reserved-wqes.patch
  - patches.suse/RDMA-bnxt_re-Fix-the-max-CQ-WQEs-for-older-adapters.patch
- commit c3e9f58

- RDMA/bnxt_re: Allow MSN table capability check (git-fixes)
  Refresh patches:
  - patches.suse/RDMA-bnxt_re-Fix-the-GID-table-length.patch
  - patches.suse/RDMA-bnxt_re-Remove-always-true-dattr-validity-check.patch
- commit 1ac774c

- RDMA/hns: Remove unused parameters and variables (git-fixes)
  Refresh patches.suse/RDMA-hns-Fix-mapping-error-of-zero-hop-WQE-buffer.patch
- commit ad435f0

- RDMA/hns: Refactor mtr find (git-fixes)
  Refresh patches.suse/RDMA-hns-Use-macro-instead-of-magic-number.patch
- commit de53bbe

- bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx
  (CVE-2024-53091 bsc#1233638).
- commit 313e9b6

- ocfs2: fix slab-use-after-free due to dangling pointer dqi_priv
  (bsc#1235964 CVE-2024-57892).
- ocfs2: correct return value of ocfs2_local_free_info()
  (bsc#1235964 CVE-2024-57892).
- commit d27bf4b

- Revert &amp;quot;mtd: spi-nor: core: replace dummy buswidth from addr
  to data&amp;quot; (git-fixes).
- hwmon: (tmp513) Fix division of negative numbers (git-fixes).
- gpio: xilinx: Convert gpio_lock to raw spinlock (git-fixes).
- i2c: rcar: fix NACK handling when being a target (git-fixes).
- i2c: mux: demux-pinctrl: check initial mux selection, too
  (git-fixes).
- i2c: core: fix reference leak in i2c_register_adapter()
  (git-fixes).
- USB: serial: option: add Neoway N723-EA support (stable-fixes).
- USB: serial: option: add MeiG Smart SRM815 (stable-fixes).
- USB: serial: cp210x: add Phoenix Contact UPS Device
  (stable-fixes).
- usb-storage: Add max sectors quirk for Nokia 208 (stable-fixes).
- ACPI: resource: Add TongFang GM5HG0A to
  irq1_edge_low_force_override[] (stable-fixes).
- ACPI: resource: Add Asus Vivobook X1504VAP to
  irq1_level_low_skip_override[] (stable-fixes).
- drm/amd/display: Add check for granularity in dml ceil/floor
  helpers (stable-fixes).
- drm/amd/display: increase MAX_SURFACES to the value supported
  by hw (stable-fixes).
- ASoC: mediatek: disable buffer pre-allocation (stable-fixes).
- ASoC: rt722: add delay time to wait for the calibration
  procedure (stable-fixes).
- commit 356d535

- KVM: arm64: Get rid of userspace_irqchip_in_use (CVE-2024-53195
  bsc#1234957).
- commit 9fc6672

- cacheinfo: Allocate memory during CPU hotplug if not done from the  primary CPU (bsc#1235429 CVE-2024-56617).
- commit 9e688fc

- s390/entry: Mark IRQ entries to fix stack depot warnings
  (CVE-2024-57838 bsc#1235798).
- commit 17604ac

- KVM: arm64: Don't retire aborted MMIO instruction
  (CVE-2024-53196 bsc#1234906).
- commit 8dbc3ed

- xen: Fix the issue of resource not being properly released in
  xenbus_dev_probe() (CVE-2024-53198 bsc#1234923).
- commit aeb4569

- Refresh
  patches.suse/x86-xen-don-t-do-PV-iret-hypercall-through-hypercall.patch.
- commit 745fddd

- x86/static-call: Remove early_boot_irqs_disabled check to fix
  Xen PVH dom0 (git-fixes).
- commit cbe946f

- drm/v3d: Ensure job pointer is set to NULL after job completion
  (git-fixes).
- drm/vmwgfx: Add new keep_resv BO param (git-fixes).
- selftests: mptcp: avoid spurious errors on disconnect
  (git-fixes).
- commit 5e7e8a8

- ftrace: Fix regression with module command in stack_trace_filter
  (CVE-2024-56569 bsc#1235031).
- commit fe237c2

- Move upstreamed DRM patch into sorted section
- commit 9ec91cd

- scsi: mpi3mr: Fix corrupt config pages PHY state is switched
  in sysfs (CVE-2024-57804 bsc#1235779).
- block: fix uaf for flush rq while iterating tags (CVE-2024-53170
  bsc#1234888).
- scsi: qedi: Fix a possible memory leak in
  qedi_alloc_and_init_sb() (CVE-2024-56747 bsc#1234934).
- scsi: bfa: Fix use-after-free in bfad_im_module_exit()
  (CVE-2024-53227 bsc#1235011).
- scsi: hisi_sas: Create all dump files during debugfs
  initialization (CVE-2024-56588 bsc#1235123).
- commit 2865882

- RDMA/siw: Remove direct link to net_device (bsc#1235946 CVE-2024-57857)
- commit c33e2ed

- RDMA/rxe: Remove the direct link to net_device (bsc#1235906 CVE-2024-57795)
- commit 03de29b

- net/mlx5e: Skip restore TC rules for vport rep without loaded
  flag (CVE-2024-57801 bsc#1235940).
- commit 2c1c8f0

- tpm: Map the ACPI provided event log (bsc#1233260 bsc#1233259
  bsc#1232421).
- commit dfc801e

- Drop downstream TPM fix patch (bsc#1233260 bsc#1233259 bsc#1232421)
  Deleted (to be replaced with the newer upstream fix):
  patches.suse/tpm-eventlog-Limit-memory-allocations-for-event-logs.patch
- commit 39b3b52

- ALSA: hda/realtek: Add support for Galaxy Book2 Pro (NP950XEE)
  (stable-fixes).
- Refresh
  patches.suse/ALSA-hda-realtek-Add-support-for-Samsung-Galaxy-Book.patch.
- commit 231fb10

- ALSA: hda/realtek: Add support for Ayaneo System using CS35L41
  HDA (stable-fixes).
- ALSA: hda/realtek - Add support for ASUS Zen AIO 27
  Z272SD_A272SD audio (stable-fixes).
- commit 4039f17

- bpf: fix recursive lock when verdict program return SK_PASS (CVE-2024-56694 bsc#1235412)
- commit 19cb085

- bpf: fix OOB devmap writes when deleting elements (CVE-2024-56615 bsc#1235426)
- commit 2f8d474

- xsk: fix OOB map writes when deleting elements (CVE-2024-56614 bsc#1235424)
- commit 5188b69

- mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM (CVE-2024-56611 bsc#1235391)
- commit 2731a92

- netdevsim: prevent bad user input in
  nsim_dev_health_break_write() (bsc#1235587 CVE-2024-56716).
- commit 28d54d6

- bpf: Fix UAF via mismatching bpf_prog/attachment RCU flavors
  (bsc#1235555 CVE-2024-56675).
- commit 403c5dd

- xsk: Free skb when TX metadata options are invalid (bsc#1235000
  CVE-2024-53236).
- commit 7d68164

- ipc: fix memleak if msg_init_ns failed in create_ipc_ns
  (bsc#1234893 CVE-2024-53175).
- commit 5f77971

- i3c: mipi-i3c-hci: Mask ring interrupts before ring stop request (CVE-2024-45828 bsc#1235705)
- commit 6a03a5a

- ceph: give up on paths longer than PATH_MAX (CVE-2024-53685 bsc#1235720)
- commit cd5b8ed

- btrfs: add a sanity check for btrfs root in btrfs_search_slot()
  (CVE-2024-56774 bsc#1235653).
- commit cd76b1a

- bcache: revert replacing IS_ERR_OR_NULL with IS_ERR again (CVE-2024-48881 bsc#1235727)
- commit 5c5ddcb

- net/smc: check return value of sock_recvmsg when draining clc
  data (CVE-2024-57791 bsc#1235759).
- commit a343ecd

- scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb() (CVE-2024-56748 bsc#1235627)
- commit 75f84ca

- scsi: ufs: core: sysfs: Prevent div by zero (CVE-2024-56622 bsc#1235251)
- commit 8bc4baa

- cpufreq: intel_pstate: Check turbo_is_disabled() in
  store_no_turbo() (bsc#1234619).
- commit f5b59a5

- cpufreq: intel_pstate: Fix unchecked HWP MSR access
  (bsc#1234619).
- commit df6b669

- cpufreq: intel_pstate: Update the maximum CPU frequency
  consistently (bsc#1234619).
- commit 110e6ef

- cpufreq: intel_pstate: Replace three global.turbo_disabled
  checks (bsc#1234619).
- commit 0ad4ebe

- cpufreq: intel_pstate: Read global.no_turbo under READ_ONCE()
  (bsc#1234619).
- Refresh
  patches.suse/cpufreq-intel_pstate-Ramp-up-frequency-faster-when-u.patch.
- Refresh
  patches.suse/cpufreq-intel_pstate-Temporarily-boost-P-state-when-.patch.
- commit 1c8960e

- cpufreq: intel_pstate: Rearrange show_no_turbo() and
  store_no_turbo() (bsc#1234619).
- commit 9383d66

- scsi: ufs: qcom: Only free platform MSIs when ESI is enabled (CVE-2024-56620 bsc#1235227)
- commit 00c6f8f

- cpufreq: intel_pstate: Do not update global.turbo_disabled
  after initialization (bsc#1234619).
- Refresh
  patches.suse/cpufreq-intel_pstate-Ramp-up-frequency-faster-when-u.patch.
- commit 536c9fc

- cpufreq: intel_pstate: Refine computation of P-state for given
  frequency (bsc#1234619).
- commit 8135bb3

- cpufreq: intel_pstate: Revise global turbo disable check
  (bsc#1234619).
- commit 4089ec6

- Drop uvcvideo fix due to regression (bsc#1235894)
- Delete
  patches.suse/media-uvcvideo-Require-entities-to-have-a-non-zero-u.patch.
- blacklist.conf update
- commit 90c0ac7

- virt: tdx-guest: Just leak decrypted memory on unrecoverable
  errors (CVE-2024-57793 bsc#1235768).
- commit 0fbd2e1

- cpufreq: intel_pstate: Fold intel_pstate_max_within_limits()
  into caller (bsc#1234619).
- commit 430dfdb

- cpufreq: intel_pstate: Use __ro_after_init for three variables
  (bsc#1234619).
- commit e421ce1

- cpufreq: intel_pstate: Get rid of unnecessary READ_ONCE()
  annotations (bsc#1234619).
- commit 682d75a

- cpufreq: intel_pstate: Wait for canceled delayed work to
  complete (bsc#1234619).
- commit a725954

- cpufreq: intel_pstate: Simplify spinlock locking (bsc#1234619).
- commit 6583c13

- cpufreq: intel_pstate: Drop redundant locking from
  intel_pstate_driver_cleanup() (bsc#1234619).
- commit e58d8d7

- Revert 'arm64: Kconfig: Make SME depend on BROKEN for now'
  This reverts commit 2ccfee6be929dd4ea49ef59a7ae686473aae40b6
  CONFIG_ARM64_SME is enabled by default so some customers may
  rely on SME. We need further analysis to evaluate to what
  extent we are impacted and in case we'll disable SME support
  later.
- commit f83551c

- PCI: imx6: Fix suspend/resume support on i.MX6QDL
  (CVE-2024-57809 bsc#1235793).
- commit 11fd956

- net: tun: fix tun_napi_alloc_frags() (CVE-2024-56372
  bsc#1235753).
- net: renesas: rswitch: avoid use-after-put for a device tree
  node (CVE-2024-55639 bsc#1235737).
- commit 0d5db72

- mm: prevent derefencing NULL ptr in pfn_section_valid()
  (git-fixes).
- commit 6f62e94

- mm, kmsan: fix infinite recursion due to RCU critical section
  (git-fixes).
- commit 509127e

- mm/sparsemem: fix race in accessing memory_section-&amp;gt;usage
  (bsc#1221326 CVE-2023-52489).
- commit 13000fd

- scsi: hisi_sas: Add cond_resched() for no forced preemption model (CVE-2024-56589 bsc#1235241)
- commit a1ef870

- arm64: Kconfig: Make SME depend on BROKEN for now (git-fixes).
- commit 2ccfee6

- arm64: ptrace: fix partial SETREGSET for NT_ARM_TAGGED_ADDR_CTRL
  (git-fixes).
- commit 834d2d0

- arm64: dts: rockchip: add hevc power domain clock to rk3328
  (git-fixes).
- commit 7aa2931

- Update
  patches.suse/ALSA-6fire-Release-resources-at-card-release.patch
  (git-fixes CVE-2024-53239 bsc#1235054).
- Update
  patches.suse/ALSA-caiaq-Use-snd_card_free_when_closed-at-disconne.patch
  (git-fixes CVE-2024-56531 bsc#1235057).
- Update
  patches.suse/ALSA-us122l-Use-snd_card_free_when_closed-at-disconn.patch
  (git-fixes CVE-2024-56532 bsc#1235059).
- Update
  patches.suse/ALSA-usb-audio-Fix-potential-out-of-bound-accesses-f.patch
  (git-fixes CVE-2024-53197 bsc#1235464).
- Update
  patches.suse/ALSA-usx2y-Use-snd_card_free_when_closed-at-disconne.patch
  (git-fixes CVE-2024-56533 bsc#1235053).
- Update
  patches.suse/Bluetooth-hci_core-Fix-not-checking-skb-length-on-hc.patch
  (stable-fixes CVE-2024-56590 bsc#1235038).
- Update
  patches.suse/Bluetooth-hci_event-Fix-using-rcu_read_-un-lock-whil.patch
  (git-fixes CVE-2024-56654 bsc#1235532).
- Update
  patches.suse/HID-wacom-fix-when-get-product-name-maybe-null-point.patch
  (git-fixes CVE-2024-56629 bsc#1235473).
- Update
  patches.suse/NFSv3-only-use-NFS-timeout-for-MOUNT-when-protocols-.patch
  (bsc#1231016 CVE-2024-50106 bsc#1232882).
- Update patches.suse/PCI-Fix-reset_method_store-memory-leak.patch
  (git-fixes CVE-2024-56745 bsc#1235563).
- Update
  patches.suse/PCI-Fix-use-after-free-of-slot-bus-on-hot-remove.patch
  (stable-fixes CVE-2024-53194 bsc#1235459).
- Update
  patches.suse/PCI-MSI-Handle-lack-of-irqdomain-gracefully.patch
  (git-fixes CVE-2024-56760 bsc#1235616).
- Update
  patches.suse/RDMA-hns-Fix-cpu-stuck-caused-by-printings-during-re.patch
  (git-fixes CVE-2024-56722 bsc#1235570).
- Update
  patches.suse/acpi-nfit-vmalloc-out-of-bounds-Read-in-acpi_nfit_ct.patch
  (git-fixes CVE-2024-56662 bsc#1235533).
- Update
  patches.suse/af_packet-avoid-erroring-out-after-sock_init_data-in.patch
  (CVE-2024-56606 bsc#123541 bsc#1235417).
- Update
  patches.suse/apparmor-test-Fix-memory-leak-for-aa_unpack_strdup.patch
  (git-fixes CVE-2024-56741 bsc#1235502).
- Update
  patches.suse/blk-cgroup-Fix-UAF-in-blkcg_unpin_online.patch
  (bsc#1234726 CVE-2024-56672 bsc#1235534).
- Update
  patches.suse/can-dev-can_set_termination-allow-sleeping-GPIOs.patch
  (git-fixes CVE-2024-56625 bsc#1235223).
- Update
  patches.suse/can-hi311x-hi3110_can_ist-fix-potential-use-after-fr.patch
  (git-fixes CVE-2024-56651 bsc#1235528).
- Update
  patches.suse/crypto-bcm-add-error-check-in-the-ahash_hmac_init-fu.patch
  (git-fixes CVE-2024-56681 bsc#1235557).
- Update
  patches.suse/crypto-pcrypt-Call-crypto-layer-directly-when-padata.patch
  (git-fixes CVE-2024-56690 bsc#1235428).
- Update
  patches.suse/dlm-fix-possible-lkb_resource-null-dereference.patch
  (git-fixes CVE-2024-47809 bsc#1235714).
- Update
  patches.suse/dma-debug-fix-a-possible-deadlock-on-radix_lock.patch
  (stable-fixes CVE-2024-47143 bsc#1235710).
- Update
  patches.suse/dmaengine-at_xdmac-avoid-null_prt_deref-in-at_xdmac_.patch
  (git-fixes CVE-2024-56767 bsc#1235160).
- Update
  patches.suse/drivers-soc-xilinx-add-the-missing-kfree-in-xlnx_add.patch
  (git-fixes CVE-2024-56546 bsc#1235070).
- Update patches.suse/drm-amdgpu-don-t-access-invalid-sched.patch
  (git-fixes CVE-2024-46896 bsc#1235707).
- Update
  patches.suse/drm-amdgpu-set-the-right-AMDGPU-sg-segment-limitatio.patch
  (stable-fixes CVE-2024-56594 bsc#1235413).
- Update
  patches.suse/drm-dp_mst-Fix-MST-sideband-message-body-length-chec.patch
  (stable-fixes CVE-2024-56616 bsc#1235427).
- Update
  patches.suse/drm-modes-Avoid-divide-by-zero-harder-in-drm_mode_vr.patch
  (stable-fixes CVE-2024-56369 bsc#1235750).
- Update
  patches.suse/drm-sti-avoid-potential-dereference-of-error-pointer-831214f.patch
  (git-fixes CVE-2024-56776 bsc#1235647).
- Update
  patches.suse/drm-sti-avoid-potential-dereference-of-error-pointer-e965e77.patch
  (git-fixes CVE-2024-56777 bsc#1235641).
- Update
  patches.suse/drm-sti-avoid-potential-dereference-of-error-pointer.patch
  (git-fixes CVE-2024-56778 bsc#1235635).
- Update
  patches.suse/drm-vc4-hdmi-Avoid-hang-with-debug-registers-when-su.patch
  (git-fixes CVE-2024-56683 bsc#1235497).
- Update
  patches.suse/drm-zynqmp_kms-Unplug-DRM-device-before-removal.patch
  (git-fixes CVE-2024-56538 bsc#1235051).
- Update
  patches.suse/efi-libstub-Free-correct-pointer-on-failure.patch
  (git-fixes CVE-2024-56573 bsc#1235042).
- Update
  patches.suse/fbdev-sh7760fb-Fix-a-possible-memory-leak-in-sh7760f.patch
  (git-fixes CVE-2024-56746 bsc#1235622).
- Update
  patches.suse/gpio-grgpio-Add-NULL-check-in-grgpio_probe.patch
  (git-fixes CVE-2024-56634 bsc#1235486).
- Update
  patches.suse/hfsplus-don-t-query-the-device-logical-block-size-multiple-times.patch
  (git-fixes CVE-2024-56548 bsc#1235073).
- Update
  patches.suse/igb-Fix-potential-invalid-memory-access-in-igb_init_.patch
  (git-fixes CVE-2024-52332 bsc#1235700).
- Update
  patches.suse/iio-adc-ad7923-Fix-buffer-overflow-for-tx_buf-and-ri.patch
  (git-fixes CVE-2024-56557 bsc#1235122).
- Update
  patches.suse/io_uring-check-if-iowq-is-killed-before-queuing.patch
  (git-fixes CVE-2024-56709 bsc#1235552).
- Update
  patches.suse/io_uring-tctx-work-around-xa_store-allocation-error-.patch
  (git-fixes CVE-2024-56584 bsc#1235117).
- Update
  patches.suse/jfs-add-a-check-to-prevent-array-index-out-of-bounds-in-dbAdjTree.patch
  (git-fixes CVE-2024-56595 bsc#1235410).
- Update
  patches.suse/jfs-array-index-out-of-bounds-fix-in-dtReadFirst.patch
  (git-fixes CVE-2024-56598 bsc#1235220).
- Update
  patches.suse/jfs-fix-array-index-out-of-bounds-in-jfs_readdir.patch
  (git-fixes CVE-2024-56596 bsc#1235458).
- Update patches.suse/jfs-fix-shift-out-of-bounds-in-dbSplit.patch
  (git-fixes CVE-2024-56597 bsc#1235222).
- Update
  patches.suse/leds-class-Protect-brightness_show-with-led_cdev-led.patch
  (stable-fixes CVE-2024-56587 bsc#1235125).
- Update
  patches.suse/media-atomisp-Add-check-for-rgby_data-memory-allocat.patch
  (git-fixes CVE-2024-56705 bsc#1235568).
- Update
  patches.suse/media-dvb-frontends-dib3000mb-fix-uninit-value-in-di.patch
  (git-fixes CVE-2024-56769 bsc#1235155).
- Update
  patches.suse/media-imx-jpeg-Ensure-power-suppliers-be-suspended-b.patch
  (git-fixes CVE-2024-56575 bsc#1235039).
- Update
  patches.suse/media-imx-jpeg-Set-video-drvdata-before-register-vid.patch
  (git-fixes CVE-2024-56578 bsc#1235115).
- Update
  patches.suse/media-mtk-jpeg-Fix-null-ptr-deref-during-unload-modu.patch
  (git-fixes CVE-2024-56577 bsc#1235112).
- Update
  patches.suse/media-platform-allegro-dvt-Fix-possible-memory-leak-.patch
  (git-fixes CVE-2024-56572 bsc#1235043).
- Update
  patches.suse/media-ts2020-fix-null-ptr-deref-in-ts2020_probe.patch
  (git-fixes CVE-2024-56574 bsc#1235040).
- Update
  patches.suse/media-uvcvideo-Require-entities-to-have-a-non-zero-u.patch
  (git-fixes CVE-2024-56571 bsc#1235037).
- Update
  patches.suse/media-wl128x-Fix-atomicity-violation-in-fmc_send_cmd.patch
  (git-fixes CVE-2024-56700 bsc#1235500).
- Update
  patches.suse/mfd-intel_soc_pmic_bxtwc-Use-IRQ-domain-for-PMIC-dev.patch
  (git-fixes CVE-2024-56723 bsc#1235571).
- Update
  patches.suse/mfd-intel_soc_pmic_bxtwc-Use-IRQ-domain-for-TMU-devi.patch
  (git-fixes CVE-2024-56724 bsc#1235577).
- Update
  patches.suse/mfd-intel_soc_pmic_bxtwc-Use-IRQ-domain-for-USB-Type.patch
  (git-fixes CVE-2024-56691 bsc#1235425).
- Update
  patches.suse/msft-hv-3095-Drivers-hv-util-Avoid-accessing-a-ringbuffer-not-ini.patch
  (git-fixes CVE-2024-55916 bsc#1235747).
- Update
  patches.suse/mtd-rawnand-fix-double-free-in-atmel_pmecc_create_us.patch
  (git-fixes CVE-2024-56766 bsc#1235219).
- Update
  patches.suse/net-ipv6-release-expired-exception-dst-cached-in-soc.patch
  (bsc#1216813 CVE-2024-56644 bsc#1235133).
- Update
  patches.suse/nfsd-fix-nfs4_openowner-leak-when-concurrent-nfsd4_open-occur.patch
  (git-fixes CVE-2024-56779 bsc#1235632).
- Update
  patches.suse/nfsd-make-sure-exp-active-before-svc_export_show.patch
  (git-fixes CVE-2024-56558 bsc#1235100).
- Update
  patches.suse/nilfs2-fix-potential-out-of-bounds-memory-access-in-nilfs_find_entry.patch
  (git-fixes CVE-2024-56619 bsc#1235224).
- Update
  patches.suse/nvme-apple-fix-device-reference-counting.patch
  (git-fixes CVE-2024-43913 bsc#1229833).
- Update
  patches.suse/nvme-rdma-unquiesce-admin_q-before-destroy-it.patch
  (git-fixes CVE-2024-49569 bsc#1235730).
- Update
  patches.suse/nvme-tcp-fix-the-memleak-while-create-new-ctrl-faile.patch
  (git-fixes CVE-2024-56632 bsc#1235483).
- Update
  patches.suse/ocfs2-free-inode-when-ocfs2_get_init_inode-fails.patch
  (git-fixes CVE-2024-56630 bsc#1235479).
- Update
  patches.suse/pinmux-Use-sequential-access-to-access-desc-pinmux-d.patch
  (stable-fixes CVE-2024-47141 bsc#1235708).
- Update
  patches.suse/power-supply-gpio-charger-Fix-set-charge-current-lim.patch
  (git-fixes CVE-2024-57792 bsc#1235764).
- Update
  patches.suse/powerpc-fadump-Move-fadump_cma_init-to-setup_arch-af.patch
  (bsc#1215199 CVE-2024-56677 bsc#1235494).
- Update
  patches.suse/powerpc-mm-fault-Fix-kfence-page-fault-reporting.patch
  (bsc#1194869 CVE-2024-56678 bsc#1235495).
- Update
  patches.suse/powerpc-pseries-Fix-dtl_access_lock-to-be-a-rw_semap.patch
  (bsc#1194869 CVE-2024-56701 bsc#1235496).
- Update
  patches.suse/quota-flush-quota_release_work-upon-quota-writeback.patch
  (bsc#1234195 CVE-2024-56780 bsc#1235650).
- Update
  patches.suse/rtc-check-if-__rtc_read_time-was-successful-in-rtc_t.patch
  (git-fixes CVE-2024-56739 bsc#1235611).
- Update
  patches.suse/scsi-qla2xxx-Fix-use-after-free-on-unload.patch
  (bsc#1235406 CVE-2024-56623 bsc#1235466).
- Update
  patches.suse/smb-client-fix-TCP-timers-deadlock-after-rmmod.patch
  (CVE-2024-53095 bsc#1233642 CVE-2024-54680 bsc#1235723).
- Update
  patches.suse/soc-imx8m-Probe-the-SoC-driver-as-platform-driver.patch
  (stable-fixes CVE-2024-56787 bsc#1235663).
- Update
  patches.suse/spi-mpc52xx-Add-cancel_work_sync-before-module-remov.patch
  (git-fixes CVE-2024-50051 bsc#1235739).
- Update
  patches.suse/sunrpc-clear-XPRT_SOCK_UPD_TIMEOUT-when-reset-transport.patch
  (git-fixes CVE-2024-56688 bsc#1235538).
- Update
  patches.suse/sunrpc-fix-one-UAF-issue-caused-by-sunrpc-kernel-tcp.patch
  (git-fixes CVE-2024-53168 bsc#1234887).
- Update patches.suse/tipc-fix-NULL-deref-in-cleanup_bearer.patch
  (CVE-2024-56642 bsc#1235433 CVE-2024-56661 bsc#1234931).
- Update patches.suse/unicode-Fix-utf8_load-error-path.patch
  (git-fixes CVE-2024-53233 bsc#1235046).
- Update
  patches.suse/usb-dwc3-gadget-Fix-looping-of-queued-SG-entries.patch
  (git-fixes CVE-2024-56698 bsc#1235491).
- Update
  patches.suse/usb-gadget-u_serial-Fix-the-issue-that-gs_start_io-c.patch
  (git-fixes CVE-2024-56670 bsc#1235488).
- Update
  patches.suse/usb-musb-Fix-hardware-lockup-on-first-Rx-endpoint-re.patch
  (git-fixes CVE-2024-56687 bsc#1235537).
- Update
  patches.suse/wifi-ath12k-Skip-Rx-TID-cleanup-for-self-peer.patch
  (git-fixes CVE-2024-56543 bsc#1235065).
- Update
  patches.suse/wifi-ath12k-fix-atomic-calls-in-ath12k_mac_op_set_bi.patch
  (stable-fixes CVE-2024-56607 bsc#1235423).
- Update
  patches.suse/wifi-brcmfmac-Fix-oops-due-to-NULL-pointer-dereferen.patch
  (stable-fixes CVE-2024-56593 bsc#1235252).
- Update
  patches.suse/wifi-nl80211-fix-NL80211_ATTR_MLO_LINK_ID-off-by-one.patch
  (git-fixes CVE-2024-56663 bsc#1235454).
- Update
  patches.suse/wifi-rtw88-use-ieee80211_purge_tx_queue-to-purge-TX-.patch
  (stable-fixes CVE-2024-56609 bsc#1235389).
- Update
  patches.suse/wifi-rtw89-check-return-value-of-ieee80211_probereq_.patch
  (stable-fixes CVE-2024-48873 bsc#1235716).
- commit 8258b9d

- Move upstreamed NFS patch into sorted section
- commit b16f043

- net: dsa: improve shutdown sequence (CVE-2024-49998 bsc#1232087).
- commit 4c71ee1

- smb: client: fix OOBs when building SMB2_IOCTL request
  (bsc#1233055, CVE-2024-50151).
- commit 6434503

- KVM: SVM: Allow guest writes to set MSR_AMD64_DE_CFG bits
  (bsc#1234635).
- commit e5c720c

- KVM: s390: Reject KVM_SET_GSI_ROUTING on ucontrol VMs (git-fixes
  bsc#1235776).
- KVM: s390: Reject setting flic pfault attributes on ucontrol
  VMs (git-fixes bsc#1235777).
- KVM: s390: vsie: fix virtual/physical address in unpin_scb()
  (git-fixes bsc#1235778).
- iommu/s390: Implement blocking domain (CVE-2024-53232
  bsc#1235050).
- commit aa0d65c

- mm/swapfile: skip HugeTLB pages for unuse_vma (CVE-2024-50199
  bsc#1233112).
- commit 57bc3bb

- exfat: fix the infinite loop in __exfat_free_cluster()
  (git-fixes).
- commit f091e41

- exfat: fix the infinite loop in exfat_readdir() (git-fixes).
- commit 3298782

- dlm: fix possible lkb_resource null dereference (git-fixes).
- commit f2b8780

- Bluetooth: MGMT: Fix possible crash on mgmt_index_removed
  (CVE-2024-49951 bsc#1232158).
- commit 8b8b4db

- afs: Fix the maximum cell name length (git-fixes).
- commit 77a0ae0

- drm/amd/display: Fix handling of plane refcount (bsc#1235657 CVE-2024-56775)
- commit b028260

- misc: microchip: pci1xxxx: Resolve return code mismatch during
  GPIO set config (git-fixes).
- misc: microchip: pci1xxxx: Resolve kernel panic during GPIO
  IRQ handling (git-fixes).
- commit 5eb3001

- iio: inkern: call iio_device_put() only on mapped devices
  (git-fixes).
- iio: adc: at91: call input_free_device() on allocated iio_dev
  (git-fixes).
- iio: adc: ti-ads124s08: Use gpiod_set_value_cansleep()
  (git-fixes).
- iio: pressure: zpa2326: fix information leak in triggered buffer
  (git-fixes).
- iio: adc: rockchip_saradc: fix information leak in triggered
  buffer (git-fixes).
- iio: imu: kmx61: fix information leak in triggered buffer
  (git-fixes).
- iio: light: vcnl4035: fix information leak in triggered buffer
  (git-fixes).
- iio: adc: ti-ads8688: fix information leak in triggered buffer
  (git-fixes).
- iio: dummy: iio_simply_dummy_buffer: fix information leak in
  triggered buffer (git-fixes).
- iio: gyro: fxas21002c: Fix missing data update in trigger
  handler (git-fixes).
- iio: test : check null return of kunit_kmalloc in
  iio_rescale_test_scale (git-fixes).
- iio: adc: ad7124: Disable all channels at probe time
  (git-fixes).
- staging: iio: ad9832: Correct phase range check (git-fixes).
- staging: iio: ad9834: Correct phase range check (git-fixes).
- usb: gadget: f_fs: Remove WARN_ON in functionfs_bind
  (git-fixes).
- USB: core: Disable LPM only for non-suspended ports (git-fixes).
- usb: fix reference leak in usb_new_device() (git-fixes).
- usb: gadget: u_serial: Disable ep before setting port to null
  to fix the crash caused by port being null (git-fixes).
- usb: gadget: configfs: Ignore trailing LF for user strings to
  cdev (git-fixes).
- USB: usblp: return error when setting unsupported protocol
  (git-fixes).
- usb: gadget: f_uac2: Fix incorrect setting of bNumEndpoints
  (git-fixes).
- usb: typec: tcpm/tcpci_maxim: fix error code in
  max_contaminant_read_resistance_kohm() (git-fixes).
- usb: dwc3-am62: Disable autosuspend during remove (git-fixes).
- usb: dwc3: gadget: fix writing NYET threshold (git-fixes).
- commit 04c952e

- tty: serial: 8250: Fix another runtime PM usage counter
  underflow (git-fixes).
- commit 1e248c9

- hwmon: (drivetemp) Fix driver producing garbage data when SCSI
  errors occur (git-fixes).
- commit b04cc0b

- thermal: of: fix OF node leak in of_thermal_zone_find()
  (git-fixes).
- drm/mediatek: Add return value check when reading DPCD
  (git-fixes).
- drm/mediatek: mtk_dsi: Add registers to pdata to fix
  MT8186/MT8188 (git-fixes).
- drm/mediatek: Fix mode valid issue for dp (git-fixes).
- drm/mediatek: Fix YCbCr422 color format issue for DP
  (git-fixes).
- drm/mediatek: stop selecting foreign drivers (git-fixes).
- drm/mediatek: Add support for 180-degree rotation in the
  display driver (git-fixes).
- drm/mediatek: Set private-&amp;gt;all_drm_private[i]-&amp;gt;drm to NULL if
  mtk_drm_bind returns err (git-fixes).
- drm/amdkfd: fixed page fault when enable MES shader debugger
  (git-fixes).
- platform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042
  actually enabled it (git-fixes).
- commit 4e3d452

- Update patches.suse/tipc-fix-NULL-deref-in-cleanup_bearer.patch
  (CVE-2024-56642 bsc#1235433).
- commit 6f4f559

- Disable ceph (jsc#PED-7242)
- commit 0dd7856

- bpf, sockmap: Fix race between element replace and close()
  (CVE-2024-56664 bsc#1235249).
- commit 81511fb

- platform/x86/intel/tpmi: Add defines to get version information
  (bsc#1225897).
- commit 00f1af2

- s390x config: IOMMU_DEFAULT_DMA_LAZY=y (bsc#1235646)
- commit 4e210b3

- tipc: fix NULL deref in cleanup_bearer() (bsc#1235433).
- commit e9be640

- platform/x86/intel-uncore-freq: Ignore minor version change
  (bsc#1225897).
- commit 33349ec

- udmabuf: fix memory leak on last export_udmabuf() error path
  (CVE-2024-56712 bsc#1235565).
- commit bbc81b4

- modpost: fix the missed iteration for the max bit in do_input()
  (git-fixes).
- net: wwan: iosm: Properly check for valid exec stage in
  ipc_mmio_init() (git-fixes).
- net: wwan: t7xx: Fix FSM command timeout issue (git-fixes).
- thunderbolt: Add support for Intel Panther Lake-M/P
  (stable-fixes).
- sound: usb: format: don't warn that raw DSD is unsupported
  (stable-fixes).
- sound: usb: enable DSD output for ddHiFi TC44C (stable-fixes).
- net: usb: qmi_wwan: add Telit FE910C04 compositions
  (stable-fixes).
- wifi: mac80211: wake the queues in case of failure in resume
  (stable-fixes).
- wifi: mac80211: fix mbss changed flags corruption on 32 bit
  systems (stable-fixes).
- watchdog: rzg2l_wdt: Power on the watchdog domain in the
  restart handler (stable-fixes).
- wifi: ath12k: fix atomic calls in
  ath12k_mac_op_set_bitrate_mask() (stable-fixes).
- wifi: rtw88: use ieee80211_purge_tx_queue() to purge TX skb
  (stable-fixes).
- wifi: mac80211: export ieee80211_purge_tx_queue() for drivers
  (stable-fixes).
- wifi: mac80211: Add non-atomic station iterator (stable-fixes).
- watchdog: rzg2l_wdt: Rely on the reset driver for doing proper
  reset (stable-fixes).
- watchdog: rzg2l_wdt: Remove reset de-assert from probe
  (stable-fixes).
- media: uvcvideo: Force UVC version to 1.0a for 0408:4035
  (stable-fixes).
- thunderbolt: Add support for Intel Lunar Lake (stable-fixes).
- usb: chipidea: add CI_HDRC_FORCE_VBUS_ACTIVE_ALWAYS flag
  (stable-fixes).
- commit c96ed05

- Bluetooth: btnxpuart: Fix driver sending truncated data
  (git-fixes).
- Bluetooth: MGMT: Fix Add Device to responding before completing
  (git-fixes).
- Bluetooth: hci_sync: Fix not setting Random Address when
  required (git-fixes).
- ieee802154: ca8210: Add missing check for kfifo_alloc() in
  ca8210_probe() (git-fixes).
- irqchip/gic: Correct declaration of *percpu_base pointer in
  union gic_base (stable-fixes).
- drm/amdkfd: Correct the migration DMA map direction
  (stable-fixes).
- ALSA: hda/realtek: Add new alc2xx-fixup-headset-mic model
  (stable-fixes).
- ACPI/IORT: Add PMCG platform information for HiSilicon HIP09A
  (stable-fixes).
- drm/amd/display: Fix incorrect DSC recompute trigger
  (stable-fixes).
- i2c: i801: Add support for Intel Panther Lake (stable-fixes).
- Bluetooth: btusb: Add new VID/PID 0489/e111 for MT7925
  (stable-fixes).
- Bluetooth: btusb: mediatek: add callback function in
  btusb_disconnect (stable-fixes).
- docs: media: update location of the media patches
  (stable-fixes).
- cleanup: Adjust scoped_guard() macros to avoid potential warning
  (stable-fixes).
- cleanup: Remove address space of returned pointer (git-fixes).
- crypto: ecdsa - Avoid signed integer overflow on signature
  decoding (stable-fixes).
- irqchip/gic-v3: Force propagation of the active state with a
  read-back (stable-fixes).
- ACPI/IORT: Add PMCG platform information for HiSilicon HIP10/11
  (stable-fixes).
- i2c: i801: Add support for Intel Arrow Lake-H (stable-fixes).
- crypto: ecdsa - Use ecc_digits_from_bytes to convert signature
  (stable-fixes).
- drm/amd/display: Fix DSC-re-computing (stable-fixes).
- Bluetooth: btusb: add callback function in btusb suspend/resume
  (stable-fixes).
- crypto: ecc - Prevent ecc_digits_from_bytes from reading too
  many bytes (git-fixes).
- Bluetooth: btusb: Add USB HW IDs for MT7921/MT7922/MT7925
  (stable-fixes).
- crypto: ecdsa - Rename keylen to bufsize where necessary
  (stable-fixes).
- crypto: ecdsa - Convert byte arrays with key coordinates to
  digits (stable-fixes).
- ALSA: ump: Use guard() for locking (stable-fixes).
- Bluetooth: btusb: Add new VID/PID 13d3/3602 for MT7925
  (stable-fixes).
- cleanup: Add conditional guard support (stable-fixes).
- i2c: xgene-slimpro: Migrate to use generic PCC shmem related
  macros (stable-fixes).
- ACPI: PCC: Add PCC shared memory region command and status
  bitfields (stable-fixes).
- mailbox: pcc: Support shared interrupt for multiple subspaces
  (stable-fixes).
- mailbox: pcc: Add support for platform notification handling
  (stable-fixes).
- Bluetooth: Add support ITTIM PE50-M75C (stable-fixes).
- commit 964672e

- scsi: sg: Fix slab-use-after-free read in sg_release()
  (CVE-2024-56631 bsc#1235480).
- commit cb70e79

- Fix CVE reference for patches.suse/af_packet-avoid-erroring-out-after-sock_init_data-in.patch (CVE-2024-56606)
- commit f8ce5de

- 9p/xen: fix release of IRQ (CVE-2024-56704 bsc#1235584).
- commit f0916d2

- net: ieee802154: do not leave a dangling sk pointer in
  ieee802154_create() (CVE-2024-56602 bsc#1235521).
- commit 2d367ac

- net: hsr: avoid potential out-of-bound access in
  fill_frame_info() (CVE-2024-56648 bsc#1235451).
- commit 79ce319

- net/mlx5: DR, prevent potential error pointer dereference (CVE-2024-56660 bsc#1235437)
- commit 0e2235c

- bnxt_en: Fix GSO type for HW GRO packets on 5750X chips (git-fixes)
- commit 8448fe4

- bnxt_en: Fix aggregation ID mask to prevent oops on 5760X chips (CVE-2024-56656  bsc#1235444)
- commit a44ef4d

- af_packet: avoid erroring out after sock_init_data() in packet_create() (CVE-2024-5660 bsc#123541)
- commit c21a9e5

- smb: client: fix NULL ptr deref in crypto_aead_setkey() (CVE-2024-53185 bsc#1234901)
- commit 77b5b00

- net: af_can: do not leave a dangling sk pointer in can_create() (CVE-2024-56603 bsc#1235415)
- commit 53bb420

- btrfs: fix use-after-free waiting for encoded read endios
  (bsc#1235445).
- btrfs: fix use-after-free in btrfs_encoded_read_endio()
  (bsc#1235445).
- commit ae44992

- ovl: Filter invalid inodes with missing lookup function
  (bsc#1235035 CVE-2024-56570).
- commit 0cddc7c

- ubi: fastmap: Fix duplicate slab cache names while attaching (CVE-2024-53172 bsc#1234898)
- commit f996297

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

- tipc: Fix use-after-free of kernel socket in cleanup_bearer()
  (CVE-2024-56642 bsc#1235433).
- commit 644f840

- sctp: properly validate chunk size in sctp_sf_ootb() (CVE-2024-50299 bsc#1233488)
- commit 9038d7f

Package libgcrypt was updated:

- FIPS: Differentiate non-compliant flags in the SLI [bsc#1225939]  * Add libgcrypt-FIPS-SLI-Differentiate-non-compliant-flags-in-the-SLI.patch

- FIPS: Implement KAT for non-deterministic ECDSA [bsc#1225939]
  * Add libgcrypt-FIPS-SLI-cipher-Add-KAT-for-non-rfc6979-ECDSA-with-fixed-k.patch

- FIPS: Disable setting the library in non-FIPS mode [bsc#1220893]
  * Add libgcrypt-FIPS-disable-GCRYCTL_NO_FIPS_MODE.patch

- FIPS: Disallow rsa &amp;lt; 2048 [bsc#1225941]
  * Mark RSA operations with keysize &amp;lt; 2048 as non-approved in the SLI
  * Add libgcrypt-FIPS-SLI-Disallow-RSA-keys-with-size-lt-2048.patch

- FIPS: Service level indicator for libgcrypt [bsc#1225939]
  * Factor out `prepare_datasexp_to_be_signed` for FIPS SLI
  * Add libgcrypt-FIPS-SLI-Factor-out-data-SEXP-preparation.patch
  * Include missing checks for EdDSA and ECDSA for FIPS SLI
  * Add libgcrypt-FIPS-SLI-Only-allow-defined-digest-algo-for-EdDSA.patch
  * Add libgcrypt-FIPS-SLI-Reject-use-of-SHAKE-when-its-ECDSA-with-RFC6979.patch
  * Include upstream patches for FIPS SLI for libgcrypt
  * Add libgcrypt-FIPS-SLI-Introduce-an-internal-API-for-FIPS-service-indicator.patch
  * Add libgcrypt-FIPS-SLI-Introduce-GCRYCTL_FIPS_SERVICE_INDICATOR-and-the-macro.patch
  * Add libgcrypt-FIPS-SLI-Implement-new-FIPS-service-indicator-for-gcry_kdf_derive.patch
  * Add libgcrypt-FIPS-SLI-Implement-new-FIPS-service-indicator-for-gcry_md_hash_*.patch
  * Add libgcrypt-FIPS-SLI-Add-t-digest.patch
  * Add libgcrypt-FIPS-SLI-Fix-t-digest-for-a-minimal-configuration.patch
  * Add libgcrypt-FIPS-SLI-Extend-tests-t-digest-to-test-hmac-too.patch
  * Add libgcrypt-FIPS-SLI-Fix-comment-in-t-thread-local.patch
  * Add libgcrypt-FIPS-SLI-Change-the-internal-API-for-new-FIPS-service-indicator.patch
  * Add libgcrypt-FIPS-SLI-Implement-new-FIPS-service-indicator-for-gcry_md_open-API.patch
  * Add libgcrypt-FIPS-SLI-Add-tests-for-md_open-write-read-close-for-t-digest.patch
  * Add libgcrypt-FIPS-SLI-Implement-new-FIPS-service-indicator-for-gcry_mac_open.patch
  * Add libgcrypt-FIPS-SLI-Implement-new-FIPS-service-indicator-for-cipher_open.patch
  * Add libgcrypt-FIPS-SLI-Add-gcry_mac_open-tests.patch
  * Add libgcrypt-FIPS-SLI-Rename-t-fips-service-ind.patch
  * Add libgcrypt-FIPS-SLI-Move-KDF-tests-to-t-fips-service-ind.patch
  * Add libgcrypt-FIPS-SLI-Add-gcry_cipher_open-tests.patch
  * Add libgcrypt-FIPS-SLI-gcry_md_copy-should-care-about-FIPS-service-indicator.patch
  * Add libgcrypt-FIPS-SLI-Implement-FIPS-service-indicator-for-gcry_pk_hash_API.patch
  * Add libgcrypt-FIPS-SLI-Introduce-GCRYCTL_FIPS_REJECT_NON_FIPS.patch
  * Add libgcrypt-FIPS-SLI-Fix-the-previous-change.patch
  * Add libgcrypt-FIPS-SLI-Rejection-by-GCRYCTL_FIPS_REJECT_NON_FIPS-not-by-open-flags.patch
  * Add libgcrypt-FIPS-SLI-Add-behavior-not-to-reject-but-mark-non-compliant.patch
  * Add libgcrypt-FIPS-SLI-Add-rejecting-or-marking-for-gcry_pk_get_curve.patch
  * Add libgcrypt-FIPS-SLI-Add-more-tests-to-tests-t-fips-service-ind.patch
  * Add libgcrypt-FIPS-SLI-Check-DATA-in-gcry_pk_sign-verify-in-FIPS-mode.patch
  * Add libgcrypt-FIPS-SLI-Fix-memory-leak-for-gcry_pk_hash_sign.patch
  * Add libgcrypt-FIPS-SLI-Improve-__thread-specifier-check.patch
  * Add libgcrypt-FIPS-SLI-mark-non-compliant-cipher-modes-as-non-approved-in-the-SLI.patch
  * Add libgcrypt-FIPS-SLI-cipher-Don-t-differentiate-GCRY_CIPHER_MODE_CMAC-in-.patch
  * Add libgcrypt-FIPS-SLI-cipher-Rename-_gcry_cipher_is_mode_fips_compliant.patch
  * Implement `hex2buffer` in tests/t-common.h for FIPS SLI testing
  * Add hex2buffer-Factor-from-existing-uses.patch
  * Remove redundant/reworked patches now in FIPS SLI
  * Remove libgcrypt-FIPS-SLI-pk.patch
  * Remove libgcrypt-FIPS-SLI-hash-mac.patch
  * Remove libgcrypt-FIPS-SLI-kdf-leylength.patch
  * Rebased patches:
  * libgcrypt-1.10.0-allow_FSM_same_state.patch
  * libgcrypt-no-deprecated-grep-alias.patch
  * libgcrypt-FIPS-rndjent_poll.patch
  * libgcrypt-Chacha20-poly1305-Optimized-chacha20-poly1305.patch

- FIPS: Consider deprecate sha1 [bsc#1225942]
  * In FIPS 180-5 revision, NIST announced EOL for SHA-1 and will
    transition at the end of 2030. Mark SHA1 as non-approved in SLI.
  * Add libgcrypt-FIPS-SLI-md-Make-SHA1-non-FIPS-and-differentiate-in-the-SLI.patch
  * Add libgcrypt-FIPS-SLI-cipher-Differentiate-SHA1-with-GCRY_FIPS_FLAG_REJECT_MD_SHA1.patch

- FIPS: Unnecessary RSA KAT Encryption/Decryption [bsc#1225936]
  * cipher: Do not run RSA encryption selftest by default
  * Add libgcrypt-FIPS-SLI-Do-not-run-RSA-encryption-selftest-by-default.patch

- FIPS: Make sure that Libgcrypt makes use of the built-in Jitter RNG
  for the whole length entropy buffer in FIPS mode. [bsc#1220893]
  * Add libgcrypt-FIPS-jitter-whole-entropy.patch

- FIPS: Set the FSM into error state if Jitter RNG is returning an
  error code to the caller when an health test error occurs when
  random bytes are requested through the jent_read_entropy_safe()
  function. [bsc#1220895]
  * Add libgcrypt-FIPS-jitter-errorcodes.patch

- FIPS: Replace the built-in jitter rng with standalone version
  * Remove the internal jitterentropy copy [bsc#1220896]
  * Add libgcrypt-FIPS-jitter-standalone.patch
  * Remove not needed libgcrypt-jitterentropy-3.4.0.patch

Package gnutls was updated:

- Security fix [bsc#1236974, CVE-2024-12243]  * gnutls: inefficient DER Decoding in libtasn1 could lead to remote DoS
  * Add gnutls-CVE-2024-12243.patch

Package nfs-utils was updated:

- rpc.idmapd: nfsopen() failures should not be fatal (bsc#1239165)  - add 0007-rpc.idmapd-nfsopen-failures-should-not-be-fatal.patch

- enable ldap support for nfsidmap (bsc#1226533)

Package openssl-1_1 was updated:

- Fix bsc#1236771 - Non approved PBKDF parameters wrongly resulting as approved  * Add openssl-FIPS-PBKDF-params.patch

- Security fix: [bsc#1236136, CVE-2024-13176]
  * timing side-channel in the ECDSA signature computation
  * Add openssl-CVE-2024-13176.patch

Package procps was updated:

- Add patch CVE-2023-4016-part2.patch  * Fix the ps command segfaults when pid argument has a leading space (bsc#1236842)

Package python3 was updated:

- Add CVE-2025-0938-sq-brackets-domain-names.patch which  disallows square brackets ([ and ]) in domain names for parsed
  URLs (bsc#1236705, CVE-2025-0938, gh#python/cpython#105704)

Package systemd was updated:

- Add 1020-core-create-the-credential-directory-even-if-it-s-em.patch (bsc#1229228)- Rename 5012-Revert-macro-terminate-the-temporary-VA_ARGS_FOREACH.patch into
  1021-Revert-macro-terminate-the-temporary-VA_ARGS_FOREACH.patch
  Commit dc571cccd75db7be49b2aada64baf92e3a498c39 was backported and included in
  v254.9 bumping the version requirement on gcc from 4.7 to 8. Unfortunately
  this breakage won't be fixed by upstream therefore there's no longer a need to
  keep the patch that reverts the offending commit in quarantine.

- Import commit 127e162c9cc0beb5058a718b3a9a1fec6942a927 (merge of v254.23)
  eab1d9753b stdio-bridge: fix polled fds
  f028f2298e hwdb: comment out the entry for Logitech MX Keys for Mac
  e808cbdd6d test: answer 2nd mdadm --create question for compat with new version
  bf01f3d692 core/unit-serialize: fix serialization of markers
  f043ab6f34 locale-setup: do not load locale from environemnt when /etc/locale.conf is unchanged
  71efbe69b6 core: fix assert when AddDependencyUnitFiles is called with invalid parameter

- Fix systemd-network recommending libidn2-devel (boo#1234765)

- Import commit 127e162c9cc0beb5058a718b3a9a1fec6942a927
  679c57667d tpm2-util: Also retry unsealing after policy_pcr returns PCR_CHANGED (boo#1233752 bsc#1234313)

- Import commit eb5a78f50e64a39a2a509fd5141e68ff216a4273 (merge of v254.22)
  For a complete list of changes, visit:
  https://github.com/openSUSE/systemd/compare/600986ba4d9c562390d99513416f49a5be5559f3...eb5a78f50e64a39a2a509fd5141e68ff216a4273

Package libtasn1 was updated:

- Security fix: [bsc#1236878, CVE-2024-12133]  * Potential DoS in handling of numerous SEQUENCE OF or SET OF elements
  * Add libtasn1-CVE-2024-12133.patch

Package libxml2 was updated:

- security update- added patches
  fix CVE-2024-56171 [bsc#1237363], use-after-free in xmlSchemaIDCFillNodeTables and xmlSchemaBubbleIDCNodeTables in xmlschemas.c
  + libxml2-CVE-2024-56171.patch
  fix CVE-2025-24928 [bsc#1237370], stack-based buffer overflow in xmlSnprintfElements in valid.c
  + libxml2-CVE-2025-24928.patch
  fix CVE-2025-27113 [bsc#1237418], NULL Pointer Dereference in libxml2 xmlPatMatch
  + libxml2-CVE-2025-27113.patch

Package libzypp was updated:

- Disable zypp.conf:download.use_deltarpm by default (fixes #620)  Measurements show that you don't benefit from using deltarpms
  unless your network connection is very slow. That's why most
  distributions even stop offering deltarpms. The default remains
  unchanged on SUSE-15.6 and older.
- Make sure repo variables are evaluated in the right context
  (bsc#1237044)
- Introducing MediaCurl2 a alternative HTTP backend.
  This patch adds MediaCurl2 as a testbed for experimenting with a
  more simple way to download files. Set ZYPP_CURL2=1 in the
  environment to use it.
- version 17.36.3 (35)

- Filesystem usrmerge must not be done in singletrans mode
  (bsc#1236481, bsc#1189788)
  Commit will amend the backend in case the transaction would
  perform a filesystem usrmerge.
- Workaround bsc#1216091 on Code16.
- version 17.36.2 (35)

- Don't issue deprecated warnings if -DNDEBUG is set (bsc#1236983)
  Released libyui packages compile with -Werror=deprecated-declarations
  so we can't add deprecated warnings without breaking them.
- make gcc15 happy (fixes #613)
- version 17.36.1 (35)

- Drop zypp-CheckAccessDeleted in favor of 'zypper ps'.
- Fix Repoverification plugin not being executed (fixes #614)
- Refresh: Fetch the master index file before key and signature
  (bsc#1236820)
- Allow libzypp to compile with C++20.
- Deprecate RepoReports we do not trigger.
- version 17.36.0 (35)

Package openssh was updated:

- Fix a MitM attack against OpenSSH's VerifyHostKeyDNS-enabled  client and a DoS attack against OpenSSH's client and server
  (bsc#1237040, CVE-2025-26465, bsc#1237041, CVE-2025-26466):
  * fix-CVE-2025-26465-and-CVE-2025-26466.patch

Package permissions was updated:

- Update to version 20240826:  * permissions: reintroduce nscd socket, which acts as a whitelisting for glibc (bsc#1236960)

Package pkg-config was updated:

Package samba was updated:

- Fix crossing automounter mount points; (bsc#1215212);  (bsc#1236803);

- Update shipped /etc/samba/smb.conf to point to smb.conf
  man page;(bsc#1233880).

Package timezone was updated:

- Update to 2025a:  * Paraguay adopts permanent -03 starting spring 2024
  * Improve pre-1991 data for the Philippines
  * Etc/Unknown is now reserved
- Update to 2024b:
  * Improve historical data for Mexico, Mongolia, and Portugal.
  * System V names are now obsolescent.
  * The main data form now uses %z.
  * The code now conforms to RFC 8536 for early timestamps.
  * Support POSIX.1-2024, which removes asctime_r and ctime_r.
  * Assume POSIX.2-1992 or later for shell scripts.
  * SUPPORT_C89 now defaults to 1.
- Add revert-philippines-historical-data.patch, revert-systemv-deprecation.patch
  * Fixes testsuite failures for other packages

Package vim was updated:

- 9.1.1101 is a fix for:  bsc#1229685 (CVE-2024-43790)
  bsc#1229822 (CVE-2024-43802)
  bsc#1230078 (CVE-2024-45306)
  bsc#1235695 (CVE-2025-22134)
  bsc#1236151 (CVE-2025-24014)
  bsc#1237137 (CVE-2025-1215)
- Remove obsoleted patch:
  * vim-7.3-mktemp_tutor.patch
- update to 9.1.1101
  * insexpand.c hard to read
  * tests: Test_log_nonexistent only works on Linux
  * Update base-syntax, improve variable matching
  * Vim9: import with extends may crash
  * leaking memory with completing multi lines
  * --log with non-existent path causes a crash
  * if_perl: Perl 5.38 adds new symbols causing link failure
  * tests: matchparen plugin test wrongly named
  * Vim9: problem finding implemented method in type hierarchy
  * runtime(qf): Update syntax file, match second delimiter
  * tests: output of test ...win32_ctrl_z depends on python version
  * tests: fix expected return code for python 3.13 on Windows
  * tests: timeout might be a bit too small
  * tests: test_terminwscroll_topline2 unreliable
  * tests: No check when tests are run under Github actions
  * tests: plugin tests are named inconsistently
  * Vim9: import with extends may crash
  * completion doesn't work with multi lines
  * filetype: cmmt files are not recognized
  * Unable to persistently ignore events in a window and its buffers
  * improve syntax highlighting
  * setreg() doesn't correctly handle mbyte chars in blockwise mode
  * unexpected DCS responses may cause out of bounds reads
  * has('bsd') is true for GNU/Hurd
  * filetype: Mill files are not recognized
  * GUI late startup leads to uninitialized scrollbars
  * Add support for lz4 to tar &amp;amp; gzip plugin
  * Terminal ansi colors off by one after tgc reset
  * included syntax items do not understand contains=TOP
  * vim_strnchr() is strange and unnecessary
  * Vim9: len variable not used in compile_load()
  * runtime(vim): Update base-syntax, match :debuggreedy count prefix
  * Strange error when heredoc marker starts with &amp;quot;trim&amp;quot;
  * tests: test_compiler fails on Windows without Maven
  * 'diffopt' &amp;quot;linematch&amp;quot; cannot be used with {n} less than 10
  * args missing after failing to redefine a function
  * Cannot control cursor positioning of getchar()
  * preinsert text completions not deleted with &amp;lt;C-W&amp;gt;/&amp;lt;C-U&amp;gt;
  * getchar() can't distinguish between C-I and Tab
  * tests: Test_termwinscroll_topline2 fails on MacOS
  * heap-use-after-free and stack-use-after-scope with :14verbose
  * no digraph for &amp;quot;Approaches the limit&amp;quot;
  * not possible to use plural forms with gettext()
  * too many strlen() calls in userfunc.c
  * terminal: E315 when dragging the terminal with the mouse
  * runtime(openPlugin): fix unclosed parenthesis in GetWordUnderCursor()
  * runtime(doc): Tweak documentation style a bit
  * tests: test_glvs fails when unarchiver not available
  * Vim always enables 'termguicolors' in a terminal
  * completion: input text deleted with preinsert when adding leader
  * translation(sr): Missing Serbian translation for the tutor
  * Superfluous cleanup steps in test_ins_complete.vim
  * runtime(netrw): correct wrong version check
  * Vim doesn't highlight to be inserted text when completing
  * runtime(netrw): upstream snapshot of v176
  * runtime(dist/vim9): fix regressions in dist#vim9#Open
  * runtime(hyprlang): fix string recognition
  * make install fails because of a missing dependency
  * runtime(asm): add byte directives to syntax script
  * Vim doesn't work well with TERM=xterm-direct
  * runtime(filetype): commit 99181205c5f8284a3 breaks V lang detection
  * runtime: decouple Open and Launch commands and gx mapping from netrw
  * &amp;quot;nosort&amp;quot; enables fuzzy filtering even if &amp;quot;fuzzy&amp;quot; isn't in 'completeopt'
  * runtime(just): fix typo in syntax file
  * runtime(filetype): Improve Verilog detection by checking for modules definition
  * tests: off-by-one error in CheckCWD in test_debugger.vim
  * tests: no support for env variables when running Vim in terminal
  * too many strlen() calls in os_unix.c
  * insert-completed items are always sorted
  * crash after scrolling and pasting in silent Ex mode
  * Makefiles uses non-portable syntax
  * fuzzymatching doesn't prefer matching camelcase
  * filetype: N-Tripels and TriG files are not recognized
  * Vim9: Patch 9.1.1014 causes regressions
  * translation(sr): Update Serbian messages translation
- updade to 9.1.1043
  * [security]: segfault in win_line()
  * update helptags
  * filetype: just files are not recognized
  * Update base-syntax, match ternary and falsy operators
  * Vim9: out-of-bound access when echoing an enum
  * Vim9: imported type cannot be used as func return type
  * runtime(kconfig): updated ftplugin and syntax script
  * runtime(doc): rename last t_BG reference to t_RB
  * Vim9: comments are outdated
  * tests: test_channel.py fails with IPv6
  * runtime(vim): Update base-syntax, fix is/isnot operator matching
  * Vim9: confusing error when using abstract method via super
  * make install fails when using shadowdir
  * Vim9: memory leak with blob2str()
  * runtime(tex): add texEmphStyle to texMatchGroup in syntax script
  * runtime(netrw): upstream snapshot of v175
  * Vim9: compiling abstract method fails without return
  * runtime(c): add new constexpr keyword to syntax file (C23)
  * tests: shaderslang was removed from test_filetype erroneously
  * link error when FEAT_SPELL not defined
  * Coverity complains about insecure data handling
  * runtime(sh): update syntax script
  * runtime(c): Add missing syntax test files
  * filetype: setting bash filetype is backwards incompatible
  * runtime(c): Update syntax and ftplugin files
  * the installer can be improved
  * too many strlen() calls in screen.c
  * no sanitize check when running linematch
  * filetype: swc configuration files are not recognized
  * runtime(netrw): change netrw maintainer
  * wrong return type of blob2str()
  * blob2str/str2blob() do not support list of strings
  * runtime(doc): fix typo in usr_02.txt
  * Coverity complains about dereferencing NULL pointer
  * linematch option value not completed
  * string might be used without a trailing NUL
  * no way to get current selected item in a async context
  * filetype: fd ignore files are not recognized
  * v9.1.0743 causes regression with diff mode
  * runtime(doc): fix base64 encode/decode examples
  * Vim9: Patch 9.1.1013 causes a few problems
  * Not possible to convert string2blob and blob2string
  * Coverity complains about dereferencing NULL value
  * Vim9: variable not found in transitive import
  * runtime(colors): Update colorschemes, include new unokai colorscheme
  * Vim9: Regression caused by patch v9.1.0646
  * runtime(lyrics): support milliseconds in syntax script
  * runtime(vim): Split Vim legacy and Vim9 script indent tests
  * Vim9: class interface inheritance not correctly working
  * popupmenu internal error with some abbr in completion item
  * filetype: VisualCode setting file not recognized
  * diff feature can be improved
  * tests: test for patch 9.1.1006 doesn't fail without the patch
  * filetype: various ignore are not recognized
  * tests: Load screendump files with &amp;quot;git vimdumps&amp;quot;
  * PmenuMatch completion highlight can be combined
  * completion text is highlighted even with no pattern found
  * tests: a few termdebug tests are flaky
  * [security]: heap-buffer-overflow with visual mode
  * runtime(doc): add package-&amp;lt;name&amp;gt; helptags for included packages
  * Vim9: unknown func error with interface declaring func var
  * runtime(filetype): don't detect string interpolation as angular
  * ComplMatchIns highlight hard to read on light background
  * runtime(vim): Update base-syntax, highlight literal string quote escape
  * runtime(editorconfig): set omnifunc to syntaxcomplete func
  * tests: ruby tests fail with Ruby 3.4
  * Vim9: leaking finished exception
  * runtime(tiasm):  use correct syntax name tiasm in syntax script
  * filetype: TI assembly files are not recognized
  * too many strlen() calls in drawscreen.c
  * runtime(xf86conf): add section name OutputClass to syntax script
  * ComplMatchIns may highlight wrong text
  * runtime(vim): Update base-syntax, improve ex-bang matching
  * runtime(doc): clarify buffer deletion on popup_close()
  * filetype: shaderslang files are not detected
  * Vim9: not able to use comment after opening curly brace
- update to 9.1.0993
  * 9.1.0993: New 'cmdheight' behavior may be surprising
  * runtime(sh): fix typo in Last Change header
  * 9.1.0992: Vim9: double-free after v9.1.0988
  * 9.1.0991: v:stacktrace has wrong type in Vim9 script
  * runtime(sh): add PS0 to bashSpecialVariables in syntax script
  * runtime(vim): Remove trailing comma from match_words
  * runtime(zsh): sync syntax script with upstream repo
  * runtime(doc): Capitalise the mnemonic &amp;quot;Zero&amp;quot; for the 'z' flag of search()
  * 9.1.0990: Inconsistent behavior when changing cmdheight
  * 9.1.0989: Vim9: Whitespace after the final enum value causes a syntax error
  * runtime(java): Quietly opt out for unsupported markdown.vim versions
  * runtime(vim): fix failing vim syntax test
  * 9.1.0988: Vim9: no error when using uninitialized var in new()
  * runtime(doc): update index.txt
  * 9.1.0987: filetype: cake files are not recognized
  * 9.1.0986: filetype: 'jj' filetype is a bit imprecise
  * runtime(jj): Support diffs in jj syntax
  * runtime(vim): Update matchit pattern, no Vim9 short names
  * 9.1.0985: Vim9: some ex commands can be shortened
  * 9.1.0984: exception handling can be improved
  * runtime(doc): update doc for :horizontal
  * runtime(doc): update index.txt, windows.txt and version9.txt
  * runtime(doc): Tweak documentation about base64 function
  * runtime(chordpro): update syntax script
  * 9.1.0983: not able to get the displayed items in complete_info()
  * runtime(doc): use standard SGR format at :h xterm-true-color
  * 9.1.0982: TI linker files are not recognized
  * runtime(vim): update vim generator syntax script
  * 9.1.0981: tests: typo in test_filetype.vim
  * 9.1.0980: no support for base64 en-/decoding functions in Vim Script
  * syntax(sh): Improve the recognition of bracket expressions
  * runtime(doc): mention how NUL bytes are handled
  * 9.1.0979: VMS: type warning with $XDG_VIMRC_FILE
  * 9.1.0978: GUI tests sometimes fail when setting 'scroll' options
  * 9.1.0977: filetype: msbuild filetypes are not recognized
  * 9.1.0976: Vim9: missing return statement with throw
  * 9.1.0975: Vim9: interpolated string expr not working in object methods
  * 9.1.0974: typo in change of commit v9.1.0873
  * 9.1.0973: too many strlen() calls in fileio.c
  * runtime(sh): set shellcheck as the compiler for supported shells
  * runtime(doc): Fix enum example syntax
  * 9.1.0972: filetype: TI linker map files are not recognized
  * runtime(vim): Improve syntax script generator for Vim Script
  * 9.1.0971: filetype: SLNX files are not recognized
  * 9.1.0970: VMS: build errors on VMS architecture
  * runtime(doc): Fix documentation typos
  * runtime(doc): update for new keyprotocol option value (after v9.1.0969)
  * 9.1.0969: ghostty not using kitty protocol by default
  * 9.1.0968: tests: GetFileNameChecks() isn't fully sorted by filetype name
  * runtime(doc): update version9.txt for bash filetype
  * runtime(netrw): update last change header for #16265
  * runtime(doc): fix doc error in :r behaviour
  * 9.1.0967: SpotBugs compiler setup can be further improved
  * 9.1.0966: Vim9: :enum command can be shortened
  * runtime(compiler): include a basic bash syntax checker compiler
  * 9.1.0965: filetype: sh filetype set when detecting the use of bash
  * runtime(doc): clarify ARCH value for 32-bit in INSTALLpc.txt
  * 9.1.0963: fuzzy-matching does not prefer full match
  * 9.1.0962: filetype: bun.lock file is not recognized
  * runtime(vim): update indentation plugin for Vim script
  * runtime(doc): tweak documentation style in helphelp.txt
  * runtime(vim): Update base-syntax, allow parens in default arguments
  * runtime(doc): mention auto-format using clang-format for sound.c/sign.c
  * runtime(help): fix typo s/additional/arbitrary/
  * runtime(help): Add better support for language annotation highlighting
  * 9.1.0961: filetype: TI gel files are not recognized
  * 9.1.0960: filetype: hy history files are not recognized
  * translation(fi): Fix typoes in Finish menu translation
  * 9.1.0959: Coverity complains about type conversion
  * runtime(vim): Use supported syntax in indent tests
  * 9.1.0958: filetype: supertux2 config files detected as lisp
  * 9.1.0956: completion may crash, completion highlight wrong with preview window
  * 9.1.0955: Vim9: vim9compile.c can be further improved
  * runtime(doc): move help tag E1182
  * runtime(graphql): contribute vim-graphql to Vim core
  * 9.1.0954: popupmenu.c can be improved
  * 9.1.0953: filetype: APKBUILD files not correctly detected
  * 9.1.0952: Vim9: missing type checking for any type assignment
  * 9.1.0951: filetype: jshell files are not recognized
  * runtime(dockerfile): do not set commentstring in syntax script
  * 9.1.0950: filetype: fennelrc files are not recognized
  * runtime(netrw): do not double escape Vim special characters
  * git: ignore reformatting change of netrw plugin
  * runtime(netrw): more reformating #16248
  * runtime(doc): Add a note about handling symbolic links in starting.txt
  * 9.1.0949: popups inconsistently shifted to the left
  * git: ignore reformatting change of netrw plugin
  * runtime(netrw): change indent size from 1 to 2
  * 9.1.0948: Missing cmdline completion for :pbuffer
  * runtime(tutor): Reformat tutor1
  * 9.1.0947: short-description
  * 9.1.0946: cross-compiling fails on osx-arm64
  * 9.1.0945: ComplMatchIns highlight doesn't end after inserted text
  * translation(sv): re-include the change from #16240
  * 9.1.0944: tests: test_registers fails when not run under X11
  * 9.1.0943: Vim9: vim9compile.c can be further improved
  * runtime(doc): Update README and mention make check to verify
  * translation(sv): partly revert commit 98874dca6d0b60ccd6fc3a140b3ec
  * runtime(vim): update base-syntax after v9.1.0936
  * 9.1.0942: a few typos were found
  * 9.1.0941: ComplMatchIns doesn't work after multibyte chars
  * runtime(doc): Fix style in fold.txt
  * translation(sv): Fix typo in Swedish translation
  * 9.1.0940: Wrong cursor shape with &amp;quot;gq&amp;quot; and 'indentexpr' executes :normal
  * runtime(doc): fix some small errors
  * 9.1.0939: make installtutor fails
  * 9.1.0938: exclusive selection not respected when re-selecting block mode
  * 9.1.0937: test_undolist() is flaky
  * 9.1.0936: cannot highlight completed text
  * 9.1.0935: SpotBugs compiler can be improved
  * 9.1.0934: hard to view an existing buffer in the preview window
  * runtime(doc): document how to minimize fold computation costs
  * 9.1.0933: Vim9: vim9compile.c can be further improved
  * 9.1.0932: new Italian tutor not installed
  * runtime(doc): fix a few minor errors from the last doc updates
  * translation(it): add Italian translation for the interactive tutor
  * runtime(doc): update the change.txt help file
  * runtime(help): Add Vim lang annotation support for codeblocks
  * 9.1.0931: ml_get error in terminal buffer
  * 9.1.0930: tests: test_terminal2 may hang in GUI mode
  * 9.1.0929: filetype: lalrpop files are not recognized
  * 9.1.0928: tests: test_popupwin fails because the filter command fails
  * editorconfig: set trim_trailing_whitespace = false for src/testdir/test*.vim
  * 9.1.0927: style issues in insexpand.c
  * 9.1.0926: filetype: Pixi lock files are not recognized
  * runtime(doc): Add a reference to |++opt| and |+cmd| at `:h :pedit`
  * runtime(doc): add a note about inclusive motions and exclusive selection
  * 9.1.0925: Vim9: expression compiled when not necessary
  * 9.1.0924: patch 9.1.0923 causes issues
  * 9.1.0923: too many strlen() calls in filepath.c
  * 9.1.0923: wrong MIN macro in popupmenu.c
  * 9.1.0921: popupmenu logic is a bit convoluted
  * 9.1.0920: Vim9: compile_assignment() too long
  * 9.1.0919: filetype: some assembler files are not recognized
  * runtime(netrw): do not pollute search history with symlinks
  * 9.1.0918: tiny Vim crashes with fuzzy buffer completion
  * 9.1.0917: various vartabstop and shiftround bugs when shifting lines
  * runtime(typst): add definition lists to formatlistpat, update maintainer
  * 9.1.0916: messages.c is exceeding 80 columns
  * runtime(proto): include filetype plugin for protobuf
  * 9.1.0915: GVim: default font size a bit too small
  * 9.1.0914: Vim9: compile_assignment() is too long
  * 9.1.0913: no error check for neg values for 'messagesopt'
  * runtime(netrw): only check first arg of netrw_browsex_viewer for being executable
  * 9.1.0912: xxd: integer overflow with sparse files and -autoskip
  * 9.1.0911: Variable name for 'messagesopt' doesn't match short name
  * 9.1.0910: 'messagesopt' does not check max wait time
  * runtime(doc): update wrong Vietnamese localization tag
  * 9.1.0909: Vim9: crash when calling instance method
- update to 9.1.0908
  * refresh vim-7.3-mktemp_tutor.patch
  * 9.1.0908: not possible to configure :messages
  * 9.1.0907: printoptions:portrait does not change postscript Orientation
  * runtime(doc): Add vietnamese.txt to helps main TOC
  * 9.1.0906: filetype: Nvidia PTX files are not recognized
  * runtime(doc): updated version9.txt with changes from v9.1.0905
  * 9.1.0905: Missing information in CompleteDone event
  * 9.1.0904: Vim9: copy-paste error in class_defining_member()
  * 9.1.0903: potential overflow in spell_soundfold_wsal()
  * runtime(netrw): do not detach when launching external programs in gvim
  * runtime(doc): make tag alignment more consistent in filetype.txt
  * runtime(doc): fix wrong syntax and style of vietnamese.txt
  * translation(it): update Italian manpage for vimtutor
  * runtime(lua): add optional lua function folding
  * Filelist: include translations for Chapter 2 tutor
  * translation(vi): Update Vietnamese translation
  * runtime(doc): include vietnamese.txt
  * runtime(tutor): fix another typo in tutor2
  * runtime(doc): fix typo in vimtutor manpage
  * translation(it): update Italian manpage for vimtutor
  * translation(it): include Italian version of tutor chapter 2
  * runtime(tutor): regenerated some translated tutor1 files
  * runtime(tutor): fix typo in Chapter 2
  * 9.1.0902: filetype: Conda configuration files are not recognized
  * runtime(doc): Tweak documentation style a bit
  * runtime(tutor): update the tutor files and re-number the chapters
  * runtime(tutor): Update the makefiles for tutor1 and tutor2 files
  * 9.1.0901: MS-Windows: vimtutor batch script can be improved
  * runtime(doc): remove buffer-local completeopt todo item
  * 9.1.0900: Vim9: digraph_getlist() does not accept bool arg
  * runtime(typst): provide a formatlistpat in ftplugin
  * runtime(doc): Update documentation for &amp;quot;noselect&amp;quot; in 'completeopt'
  * 9.1.0899: default for 'backspace' can be set in C code
  * runtime(helptoc): reload cached g:helptoc.shell_prompt when starting toc
  * translation(ru): Updated messages translation
  * 9.1.0898: runtime(compiler): pytest compiler not included
  * 9.1.0897: filetype: pyrex files are not detected
  * runtime(compiler): update eslint compiler
  * 9.1.0896: completion list wrong after v9.1.0891
  * runtime(doc): document changed default value for 'history'
  * 9.1.0895: default history value is too small
  * 9.1.0894: No test for what the spotbug compiler parses
  * 9.1.0893: No test that undofile format does not regress
  * translation(de): update German manpages
  * runtime(compiler): include spotbugs Java linter
  * 9.1.0892: the max value of 'tabheight' is limited by other tabpages
  * runtime(po): remove poDiffOld/New, add po-format flags to syntax file
  * 9.1.0891: building the completion list array is inefficient
  * patch 9.1.0890: %! item not allowed for 'rulerformat'
  * runtime(gzip): load undofile if there exists one
  * 9.1.0889: Possible unnecessary redraw after adding/deleting lines
  * 9.1.0888: leftcol property not available in getwininfo()
  * 9.1.0887: Wrong expression in sign.c
  * 9.1.0886: filetype: debian control file not detected
  * runtime(c3): include c3 filetype plugin
  * 9.1.0885: style of sign.c can be improved
  * 9.1.0884: gcc warns about uninitialized variable
  * runtime(apache): Update syntax directives for apache server 2.4.62
  * translation(ru): updated vimtutor translation, update MAINTAINERS file
  * 9.1.0883: message history cleanup is missing some tests
  * runtime(doc): Expand docs on :! vs. :term
  * runtime(netrw): Fixing powershell execution issues on Windows
  * 9.1.0882: too many strlen() calls in insexpand.c
  * 9.1.0881: GUI: message dialog may not get focus
  * runtime(netrw): update netrw's decompress logic
  * runtime(apache): Update syntax keyword definition
  * runtime(misc): add Italian LICENSE and (top-level) README file
  * 9.1.0880: filetype: C3 files are not recognized
  * runtime(doc): add helptag for :HelpToc command
  * 9.1.0879: source is not consistently formatted
  * Add clang-format config file
  * runtime(compiler): fix escaping of arguments passed to :CompilerSet
  * 9.1.0878: termdebug: cannot enable DEBUG mode
  * 9.1.0877: tests: missing test for termdebug + decimal signs
  * 9.1.0876: filetype: openCL files are not recognized
  * 9.1.0875: filetype: hyprlang detection can be improved
  * 9.1.0874: filetype: karel files are not detected
  * 9.1.0873: filetype: Vivado files are not recognized
  * 9.1.0872: No test for W23 message
  * 9.1.0871: getcellpixels() can be further improved
  * 9.1.0870: too many strlen() calls in eval.c
  * 9.1.0869: Problem: curswant not set on gm in folded line
  * 9.1.0868: the warning about missing clipboard can be improved
  * runtime(doc): Makefile does not clean up all temporary files
  * 9.1.0867: ins_compl_add() has too many args
  * editorconfig: don't trim trailing whitespaces in runtime/doc
  * translation(am): Remove duplicate keys in desktop files
  * runtime(doc): update helptags
  * runtime(filetype): remove duplicated *.org file pattern
  * runtime(cfg): only consider leading // as starting a comment
  * 9.1.0866: filetype: LLVM IR files are not recognized
  * 9.1.0865: filetype: org files are not recognized
  * 9.1.0864: message history is fixed to 200
  * 9.1.0863: getcellpixels() can be further improved
  * runtime(sh): better function support for bash/zsh in indent script
  * runtime(netrw): small fixes to netrw#BrowseX
  * 9.1.0862: 'wildmenu' not enabled by default in nocp mode
  * runtime(doc): update how to report issues for mac Vim
  * runtime(doc): mention option-backslash at :h CompilerSet
  * runtime(compiler): include a Java Maven compiler plugin
  * runtime(racket): update Racket runtime files
  * runtime(doc): improve indentation in examples for netrw-handler
  * runtime(doc): improve examples for netrw-handler functions
  * runtime(idris2): include filetype,indent+syntax plugins for (L)Idris2 + ipkg
  * runtime(doc): clarify the use of filters and external commands
  * 9.1.0861: Vim9: no runtime check for object member access of any var
  * runtime(compiler): update pylint linter
  * 9.1.0860: tests: mouse_shape tests use hard code sleep value
  * 9.1.0859: several problems with the GLVS plugin
  * 9.1.0858: Coverity complains about dead code
  * runtime(tar): Update tar.vim to support permissions
  * 9.1.0857: xxd: --- is incorrectly recognized as end-of-options
  * 9.1.0851: too many strlen() calls in getchar.c
  * 9.1.0850: Vim9: cannot access nested object inside objects
  * runtime(tex): extra Number highlighting causes issues
  * runtime(vim): Fix indent after :silent! function
  * 9.1.0849: there are a few typos in the source
  * runtime(netrw): directory symlink not resolved in tree view
  * runtime(doc): add a table of supported Operating Systems
  * runtime(tex): update Last Change header in syntax script
  * runtime(doc): fix typo in g:termdebug_config
  * runtime(vim): Update base-syntax, improve :normal highlighting
  * runtime(tex): add Number highlighting to syntax file
  * runtime(doc): Tweak documentation style a bit
  * 9.1.0848: if_lua: v:false/v:true are not evaluated to boolean
  * runtime(dune): use :setl instead of :set in ftplugin
  * runtime(termdebug): allow to use decimal signs
  * translation(it): Updated Italian vimtutor
  * runtime(compiler): improve cppcheck
  * git: git-blame-ignore-revs shown as an error on Github
  * 9.1.0847: tests: test_popupwin fails because of updated help file
  * 9.1.0846: debug symbols for xxd are not cleaned in Makefile
  * runtime(structurizr): Update structurizr syntax
  * runtime(8th): updated 8th syntax
  * runtime(doc): Add pi_tutor.txt to help TOC
  * runtime(compiler): add mypy and ruff compiler; update pylint linter
  * runtime(netrw): fix several bugs in netrw tree listing
  * runtime(netrw): prevent polluting the search history
  * 9.1.0845: vimtutor shell script can be improved
  * 9.1.0844: if_python: no way to pass local vars to python
  * 9.1.0843: too many strlen() calls in undo.c
  * runtime(doc): update default value for fillchars option
  * runtime(compiler): fix typo in cppcheck compiler plugin
  * runtime(doc): simplify vimtutor manpage a bit more
  * runtime(matchparen): Add matchparen_disable_cursor_hl config option
  * 9.1.0842: not checking for the sync() systemcall
  * 9.1.0841: tests: still preferring python2 over python3
  * 9.1.0840: filetype: idris2 files are not recognized
  * 9.1.0839: filetype: leo files are not recognized
  * runtime(cook): include cook filetype plugin
  * runtime(debversions): Update Debian versions
  * patch 9.1.0838: vimtutor is bash-specific
  * runtime(doc): add help specific modeline to pi_tutor.txt
  * Filelist: vimtutor chapter 2 is missing in Filelist
  * 9.1.0837: cross-compiling has some issues
  * runtime(vimtutor): Add a second chapter

Package zypper was updated:

- Annonunce --root in commands not launching a Target  (bsc#1237044)
- BuildRequires:  libzypp-devel &amp;gt;= 17.36.3.
- version 1.14.85

- Let zypper dup fail in case of (temporarily) unaccessible repos
  (bsc#1228434, bsc#1236939, fixes #446)
- version 1.14.84

- New system-architecture command (bsc#1236384)
  Prints the detected system architecture.
- version 1.14.83

- requires: libzypp &amp;gt;= 17.36.0.
- Change versioncmp command to return exit code according to the
  comparison result (#593)
- version 1.14.82

</Note>
    <Note Title="Terms of Use" Type="Legal Disclaimer" Ordinal="3" xml:lang="en">The CVRF data is provided by SUSE under the Creative Commons License 4.0 with Attribution (CC-BY-4.0).</Note>
  </DocumentNotes>
  <DocumentReferences>
    <Reference Type="Self">
      <URL>https://publiccloudimagechangeinfo.suse.com/google/sles-15-sp6-chost-byos-v20250320-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/sles-15-sp6-chost-byos-v20250320-arm64">
      <Branch Type="Product Name" Name="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
        <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
      </Branch>
    </Branch>
    <Branch Type="Product Version" Name="crypto-policies-20230920.570ea89-150600.3.9.2">
      <FullProductName ProductID="crypto-policies-20230920.570ea89-150600.3.9.2">crypto-policies-20230920.570ea89-150600.3.9.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="docker-27.5.1_ce-150000.215.3">
      <FullProductName ProductID="docker-27.5.1_ce-150000.215.3">docker-27.5.1_ce-150000.215.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="dracut-059+suse.552.g232957b4-150600.3.17.2">
      <FullProductName ProductID="dracut-059+suse.552.g232957b4-150600.3.17.2">dracut-059+suse.552.g232957b4-150600.3.17.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="findutils-4.8.0-150300.3.3.2">
      <FullProductName ProductID="findutils-4.8.0-150300.3.3.2">findutils-4.8.0-150300.3.3.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-2.38-150600.14.23.1">
      <FullProductName ProductID="glibc-2.38-150600.14.23.1">glibc-2.38-150600.14.23.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-locale-2.38-150600.14.23.1">
      <FullProductName ProductID="glibc-locale-2.38-150600.14.23.1">glibc-locale-2.38-150600.14.23.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-locale-base-2.38-150600.14.23.1">
      <FullProductName ProductID="glibc-locale-base-2.38-150600.14.23.1">glibc-locale-base-2.38-150600.14.23.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-guest-agent-20250116.00-150000.1.54.1">
      <FullProductName ProductID="google-guest-agent-20250116.00-150000.1.54.1">google-guest-agent-20250116.00-150000.1.54.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-guest-oslogin-20240311.00-150000.1.48.1">
      <FullProductName ProductID="google-guest-oslogin-20240311.00-150000.1.48.1">google-guest-oslogin-20240311.00-150000.1.48.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-osconfig-agent-20250115.01-150000.1.44.1">
      <FullProductName ProductID="google-osconfig-agent-20250115.01-150000.1.44.1">google-osconfig-agent-20250115.01-150000.1.44.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grub2-2.12-150600.8.21.2">
      <FullProductName ProductID="grub2-2.12-150600.8.21.2">grub2-2.12-150600.8.21.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grub2-arm64-efi-2.12-150600.8.21.2">
      <FullProductName ProductID="grub2-arm64-efi-2.12-150600.8.21.2">grub2-arm64-efi-2.12-150600.8.21.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kdump-2.0.6+git25.g1dbf786-150600.3.14.1">
      <FullProductName ProductID="kdump-2.0.6+git25.g1dbf786-150600.3.14.1">kdump-2.0.6+git25.g1dbf786-150600.3.14.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kernel-default-6.4.0-150600.23.42.2">
      <FullProductName ProductID="kernel-default-6.4.0-150600.23.42.2">kernel-default-6.4.0-150600.23.42.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgcrypt20-1.10.3-150600.3.3.1">
      <FullProductName ProductID="libgcrypt20-1.10.3-150600.3.3.1">libgcrypt20-1.10.3-150600.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgnutls30-3.8.3-150600.4.6.2">
      <FullProductName ProductID="libgnutls30-3.8.3-150600.4.6.2">libgnutls30-3.8.3-150600.4.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libnfsidmap1-1.0-150600.28.9.2">
      <FullProductName ProductID="libnfsidmap1-1.0-150600.28.9.2">libnfsidmap1-1.0-150600.28.9.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libopenssl1_1-1.1.1w-150600.5.12.2">
      <FullProductName ProductID="libopenssl1_1-1.1.1w-150600.5.12.2">libopenssl1_1-1.1.1w-150600.5.12.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libprocps8-3.3.17-150000.7.42.1">
      <FullProductName ProductID="libprocps8-3.3.17-150000.7.42.1">libprocps8-3.3.17-150000.7.42.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpython3_6m1_0-3.6.15-150300.10.81.1">
      <FullProductName ProductID="libpython3_6m1_0-3.6.15-150300.10.81.1">libpython3_6m1_0-3.6.15-150300.10.81.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsystemd0-254.23-150600.4.25.1">
      <FullProductName ProductID="libsystemd0-254.23-150600.4.25.1">libsystemd0-254.23-150600.4.25.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libtasn1-4.13-150000.4.11.1">
      <FullProductName ProductID="libtasn1-4.13-150000.4.11.1">libtasn1-4.13-150000.4.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libtasn1-6-4.13-150000.4.11.1">
      <FullProductName ProductID="libtasn1-6-4.13-150000.4.11.1">libtasn1-6-4.13-150000.4.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libudev1-254.23-150600.4.25.1">
      <FullProductName ProductID="libudev1-254.23-150600.4.25.1">libudev1-254.23-150600.4.25.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxml2-2-2.10.3-150500.5.23.1">
      <FullProductName ProductID="libxml2-2-2.10.3-150500.5.23.1">libxml2-2-2.10.3-150500.5.23.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libzypp-17.36.3-150600.3.50.1">
      <FullProductName ProductID="libzypp-17.36.3-150600.3.50.1">libzypp-17.36.3-150600.3.50.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="nfs-client-2.6.4-150600.28.9.2">
      <FullProductName ProductID="nfs-client-2.6.4-150600.28.9.2">nfs-client-2.6.4-150600.28.9.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-9.6p1-150600.6.15.2">
      <FullProductName ProductID="openssh-9.6p1-150600.6.15.2">openssh-9.6p1-150600.6.15.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-clients-9.6p1-150600.6.15.2">
      <FullProductName ProductID="openssh-clients-9.6p1-150600.6.15.2">openssh-clients-9.6p1-150600.6.15.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-common-9.6p1-150600.6.15.2">
      <FullProductName ProductID="openssh-common-9.6p1-150600.6.15.2">openssh-common-9.6p1-150600.6.15.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-server-9.6p1-150600.6.15.2">
      <FullProductName ProductID="openssh-server-9.6p1-150600.6.15.2">openssh-server-9.6p1-150600.6.15.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="permissions-20240826-150600.10.18.2">
      <FullProductName ProductID="permissions-20240826-150600.10.18.2">permissions-20240826-150600.10.18.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="pkg-config-0.29.2-150600.15.3.1">
      <FullProductName ProductID="pkg-config-0.29.2-150600.15.3.1">pkg-config-0.29.2-150600.15.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="procps-3.3.17-150000.7.42.1">
      <FullProductName ProductID="procps-3.3.17-150000.7.42.1">procps-3.3.17-150000.7.42.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-base-3.6.15-150300.10.81.1">
      <FullProductName ProductID="python3-base-3.6.15-150300.10.81.1">python3-base-3.6.15-150300.10.81.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="samba-client-libs-4.19.8+git.404.38b26805d4-150600.3.12.2">
      <FullProductName ProductID="samba-client-libs-4.19.8+git.404.38b26805d4-150600.3.12.2">samba-client-libs-4.19.8+git.404.38b26805d4-150600.3.12.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-254.23-150600.4.25.1">
      <FullProductName ProductID="systemd-254.23-150600.4.25.1">systemd-254.23-150600.4.25.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="timezone-2025a-150600.91.3.1">
      <FullProductName ProductID="timezone-2025a-150600.91.3.1">timezone-2025a-150600.91.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="udev-254.23-150600.4.25.1">
      <FullProductName ProductID="udev-254.23-150600.4.25.1">udev-254.23-150600.4.25.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="vim-9.1.1101-150500.20.21.1">
      <FullProductName ProductID="vim-9.1.1101-150500.20.21.1">vim-9.1.1101-150500.20.21.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="vim-data-common-9.1.1101-150500.20.21.1">
      <FullProductName ProductID="vim-data-common-9.1.1101-150500.20.21.1">vim-data-common-9.1.1101-150500.20.21.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="zypper-1.14.85-150600.10.28.1">
      <FullProductName ProductID="zypper-1.14.85-150600.10.28.1">zypper-1.14.85-150600.10.28.1</FullProductName>
    </Branch>
    <Relationship ProductReference="crypto-policies-20230920.570ea89-150600.3.9.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:crypto-policies-20230920.570ea89-150600.3.9.2">crypto-policies-20230920.570ea89-150600.3.9.2 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="docker-27.5.1_ce-150000.215.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:docker-27.5.1_ce-150000.215.3">docker-27.5.1_ce-150000.215.3 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="dracut-059+suse.552.g232957b4-150600.3.17.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:dracut-059+suse.552.g232957b4-150600.3.17.2">dracut-059+suse.552.g232957b4-150600.3.17.2 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="findutils-4.8.0-150300.3.3.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:findutils-4.8.0-150300.3.3.2">findutils-4.8.0-150300.3.3.2 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-2.38-150600.14.23.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:glibc-2.38-150600.14.23.1">glibc-2.38-150600.14.23.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-locale-2.38-150600.14.23.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:glibc-locale-2.38-150600.14.23.1">glibc-locale-2.38-150600.14.23.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-locale-base-2.38-150600.14.23.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:glibc-locale-base-2.38-150600.14.23.1">glibc-locale-base-2.38-150600.14.23.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-guest-agent-20250116.00-150000.1.54.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:google-guest-agent-20250116.00-150000.1.54.1">google-guest-agent-20250116.00-150000.1.54.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-guest-oslogin-20240311.00-150000.1.48.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:google-guest-oslogin-20240311.00-150000.1.48.1">google-guest-oslogin-20240311.00-150000.1.48.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-osconfig-agent-20250115.01-150000.1.44.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:google-osconfig-agent-20250115.01-150000.1.44.1">google-osconfig-agent-20250115.01-150000.1.44.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-2.12-150600.8.21.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-2.12-150600.8.21.2">grub2-2.12-150600.8.21.2 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-arm64-efi-2.12-150600.8.21.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-arm64-efi-2.12-150600.8.21.2">grub2-arm64-efi-2.12-150600.8.21.2 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kdump-2.0.6+git25.g1dbf786-150600.3.14.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kdump-2.0.6+git25.g1dbf786-150600.3.14.1">kdump-2.0.6+git25.g1dbf786-150600.3.14.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kernel-default-6.4.0-150600.23.42.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2">kernel-default-6.4.0-150600.23.42.2 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgcrypt20-1.10.3-150600.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:libgcrypt20-1.10.3-150600.3.3.1">libgcrypt20-1.10.3-150600.3.3.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgnutls30-3.8.3-150600.4.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:libgnutls30-3.8.3-150600.4.6.2">libgnutls30-3.8.3-150600.4.6.2 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libnfsidmap1-1.0-150600.28.9.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:libnfsidmap1-1.0-150600.28.9.2">libnfsidmap1-1.0-150600.28.9.2 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libopenssl1_1-1.1.1w-150600.5.12.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:libopenssl1_1-1.1.1w-150600.5.12.2">libopenssl1_1-1.1.1w-150600.5.12.2 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libprocps8-3.3.17-150000.7.42.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:libprocps8-3.3.17-150000.7.42.1">libprocps8-3.3.17-150000.7.42.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpython3_6m1_0-3.6.15-150300.10.81.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:libpython3_6m1_0-3.6.15-150300.10.81.1">libpython3_6m1_0-3.6.15-150300.10.81.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsystemd0-254.23-150600.4.25.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:libsystemd0-254.23-150600.4.25.1">libsystemd0-254.23-150600.4.25.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libtasn1-4.13-150000.4.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:libtasn1-4.13-150000.4.11.1">libtasn1-4.13-150000.4.11.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libtasn1-6-4.13-150000.4.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:libtasn1-6-4.13-150000.4.11.1">libtasn1-6-4.13-150000.4.11.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libudev1-254.23-150600.4.25.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:libudev1-254.23-150600.4.25.1">libudev1-254.23-150600.4.25.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxml2-2-2.10.3-150500.5.23.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:libxml2-2-2.10.3-150500.5.23.1">libxml2-2-2.10.3-150500.5.23.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libzypp-17.36.3-150600.3.50.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:libzypp-17.36.3-150600.3.50.1">libzypp-17.36.3-150600.3.50.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="nfs-client-2.6.4-150600.28.9.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:nfs-client-2.6.4-150600.28.9.2">nfs-client-2.6.4-150600.28.9.2 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-9.6p1-150600.6.15.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:openssh-9.6p1-150600.6.15.2">openssh-9.6p1-150600.6.15.2 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-clients-9.6p1-150600.6.15.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:openssh-clients-9.6p1-150600.6.15.2">openssh-clients-9.6p1-150600.6.15.2 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-common-9.6p1-150600.6.15.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:openssh-common-9.6p1-150600.6.15.2">openssh-common-9.6p1-150600.6.15.2 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-server-9.6p1-150600.6.15.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:openssh-server-9.6p1-150600.6.15.2">openssh-server-9.6p1-150600.6.15.2 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="permissions-20240826-150600.10.18.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:permissions-20240826-150600.10.18.2">permissions-20240826-150600.10.18.2 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="pkg-config-0.29.2-150600.15.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:pkg-config-0.29.2-150600.15.3.1">pkg-config-0.29.2-150600.15.3.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="procps-3.3.17-150000.7.42.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:procps-3.3.17-150000.7.42.1">procps-3.3.17-150000.7.42.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-base-3.6.15-150300.10.81.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:python3-base-3.6.15-150300.10.81.1">python3-base-3.6.15-150300.10.81.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="samba-client-libs-4.19.8+git.404.38b26805d4-150600.3.12.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:samba-client-libs-4.19.8+git.404.38b26805d4-150600.3.12.2">samba-client-libs-4.19.8+git.404.38b26805d4-150600.3.12.2 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-254.23-150600.4.25.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:systemd-254.23-150600.4.25.1">systemd-254.23-150600.4.25.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="timezone-2025a-150600.91.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:timezone-2025a-150600.91.3.1">timezone-2025a-150600.91.3.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="udev-254.23-150600.4.25.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:udev-254.23-150600.4.25.1">udev-254.23-150600.4.25.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-9.1.1101-150500.20.21.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:vim-9.1.1101-150500.20.21.1">vim-9.1.1101-150500.20.21.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-data-common-9.1.1101-150500.20.21.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:vim-data-common-9.1.1101-150500.20.21.1">vim-data-common-9.1.1101-150500.20.21.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="zypper-1.14.85-150600.10.28.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:zypper-1.14.85-150600.10.28.1">zypper-1.14.85-150600.10.28.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-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">Under some circumstances, this weakness allows a user who has access to run the "ps" utility on a machine, the ability to write almost unlimited amounts of unfiltered data into the process heap.</Note>
    </Notes>
    <CVE>CVE-2023-4016</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:libprocps8-3.3.17-150000.7.42.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:procps-3.3.17-150000.7.42.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm/sparsemem: fix race in accessing memory_section-&gt;usage

The below race is observed on a PFN which falls into the device memory
region with the system memory configuration where PFN's are such that
[ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL].  Since normal zone start and end
pfn contains the device memory PFN's as well, the compaction triggered
will try on the device memory PFN's too though they end up in NOP(because
pfn_to_online_page() returns NULL for ZONE_DEVICE memory sections).  When
from other core, the section mappings are being removed for the
ZONE_DEVICE region, that the PFN in question belongs to, on which
compaction is currently being operated is resulting into the kernel crash
with CONFIG_SPASEMEM_VMEMAP enabled.  The crash logs can be seen at [1].

compact_zone()			memunmap_pages
-------------			---------------
__pageblock_pfn_to_page
   ......
 (a)pfn_valid():
     valid_section()//return true
			      (b)__remove_pages()-&gt;
				  sparse_remove_section()-&gt;
				    section_deactivate():
				    [Free the array ms-&gt;usage and set
				     ms-&gt;usage = NULL]
     pfn_section_valid()
     [Access ms-&gt;usage which
     is NULL]

NOTE: From the above it can be said that the race is reduced to between
the pfn_valid()/pfn_section_valid() and the section deactivate with
SPASEMEM_VMEMAP enabled.

The commit b943f045a9af("mm/sparse: fix kernel crash with
pfn_section_valid check") tried to address the same problem by clearing
the SECTION_HAS_MEM_MAP with the expectation of valid_section() returns
false thus ms-&gt;usage is not accessed.

Fix this issue by the below steps:

a) Clear SECTION_HAS_MEM_MAP before freeing the -&gt;usage.

b) RCU protected read side critical section will either return NULL
   when SECTION_HAS_MEM_MAP is cleared or can successfully access -&gt;usage.

c) Free the -&gt;usage with kfree_rcu() and set ms-&gt;usage = NULL.  No
   attempt will be made to access -&gt;usage after this as the
   SECTION_HAS_MEM_MAP is cleared thus valid_section() return false.

Thanks to David/Pavan for their inputs on this patch.

[1] https://lore.kernel.org/linux-mm/994410bb-89aa-d987-1f50-f514903c55aa@quicinc.com/

On Snapdragon SoC, with the mentioned memory configuration of PFN's as
[ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL], we are able to see bunch of
issues daily while testing on a device farm.

For this particular issue below is the log.  Though the below log is
not directly pointing to the pfn_section_valid(){ ms-&gt;usage;}, when we
loaded this dump on T32 lauterbach tool, it is pointing.

[  540.578056] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000000
[  540.578068] Mem abort info:
[  540.578070]   ESR = 0x0000000096000005
[  540.578073]   EC = 0x25: DABT (current EL), IL = 32 bits
[  540.578077]   SET = 0, FnV = 0
[  540.578080]   EA = 0, S1PTW = 0
[  540.578082]   FSC = 0x05: level 1 translation fault
[  540.578085] Data abort info:
[  540.578086]   ISV = 0, ISS = 0x00000005
[  540.578088]   CM = 0, WnR = 0
[  540.579431] pstate: 82400005 (Nzcv daif +PAN -UAO +TCO -DIT -SSBSBTYPE=--)
[  540.579436] pc : __pageblock_pfn_to_page+0x6c/0x14c
[  540.579454] lr : compact_zone+0x994/0x1058
[  540.579460] sp : ffffffc03579b510
[  540.579463] x29: ffffffc03579b510 x28: 0000000000235800 x27:000000000000000c
[  540.579470] x26: 0000000000235c00 x25: 0000000000000068 x24:ffffffc03579b640
[  540.579477] x23: 0000000000000001 x22: ffffffc03579b660 x21:0000000000000000
[  540.579483] x20: 0000000000235bff x19: ffffffdebf7e3940 x18:ffffffdebf66d140
[  540.579489] x17: 00000000739ba063 x16: 00000000739ba063 x15:00000000009f4bff
[  540.579495] x14: 0000008000000000 x13: 0000000000000000 x12:0000000000000001
[  540.579501] x11: 0000000000000000 x10: 0000000000000000 x9 :ffffff897d2cd440
[  540.579507] x8 : 0000000000000000 x7 : 0000000000000000 x6 :ffffffc03579b5b4
[  540.579512] x5 : 0000000000027f25 x4 : ffffffc03579b5b8 x3 :0000000000000
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-52489</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: adapt set backend to use GC transaction API

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

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

rbtree and pipapo set backends does not set on the _DEAD bit from the
sync GC path since this runs in control plane path where mutex is held.
In this case, set elements are deactivated, removed and then released
via RCU callback, sync GC never fails.</Note>
    </Notes>
    <CVE>CVE-2023-52923</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: don't skip expired elements during walk

There is an asymmetry between commit/abort and preparation phase if the
following conditions are met:

1. set is a verdict map ("1.2.3.4 : jump foo")
2. timeouts are enabled

In this case, following sequence is problematic:

1. element E in set S refers to chain C
2. userspace requests removal of set S
3. kernel does a set walk to decrement chain-&gt;use count for all elements
   from preparation phase
4. kernel does another set walk to remove elements from the commit phase
   (or another walk to do a chain-&gt;use increment for all elements from
    abort phase)

If E has already expired in 1), it will be ignored during list walk, so its use count
won't have been changed.

Then, when set is culled, -&gt;destroy callback will zap the element via
nf_tables_set_elem_destroy(), but this function is only safe for
elements that have been deactivated earlier from the preparation phase:
lack of earlier deactivate removes the element but leaks the chain use
count, which results in a WARN splat when the chain gets removed later,
plus a leak of the nft_chain structure.

Update pipapo_get() not to skip expired elements, otherwise flush
command reports bogus ENOENT errors.</Note>
    </Notes>
    <CVE>CVE-2023-52924</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: don't fail inserts if duplicate has expired

nftables selftests fail:
run-tests.sh testcases/sets/0044interval_overlap_0
Expected: 0-2 . 0-3, got:
W: [FAILED]     ./testcases/sets/0044interval_overlap_0: got 1

Insertion must ignore duplicate but expired entries.

Moreover, there is a strange asymmetry in nft_pipapo_activate:

It refetches the current element, whereas the other -&gt;activate callbacks
(bitmap, hash, rhash, rbtree) use elem-&gt;priv.
Same for .remove: other set implementations take elem-&gt;priv,
nft_pipapo_remove fetches elem-&gt;priv, then does a relookup,
remove this.

I suspect this was the reason for the change that prompted the
removal of the expired check in pipapo_get() in the first place,
but skipping exired elements there makes no sense to me, this helper
is used for normal get requests, insertions (duplicate check)
and deactivate callback.

In first two cases expired elements must be skipped.

For -&gt;deactivate(), this gets called for DELSETELEM, so it
seems to me that expired elements should be skipped as well, i.e.
delete request should fail with -ENOENT error.</Note>
    </Notes>
    <CVE>CVE-2023-52925</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw in libtasn1 causes inefficient handling of specific certificate data. When processing a large number of elements in a certificate, libtasn1 takes much longer than expected, which can slow down or even crash the system. This flaw allows an attacker to send a specially crafted certificate, causing a denial of service attack.</Note>
    </Notes>
    <CVE>CVE-2024-12133</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:libtasn1-4.13-150000.4.11.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:libtasn1-6-4.13-150000.4.11.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in GnuTLS, which relies on libtasn1 for ASN.1 data processing. Due to an inefficient algorithm in libtasn1, decoding certain DER-encoded certificate data can take excessive time, leading to increased resource consumption. This flaw allows a remote attacker to send a specially crafted certificate, causing GnuTLS to become unresponsive or slow, resulting in a denial-of-service condition.</Note>
    </Notes>
    <CVE>CVE-2024-12243</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:libgnutls30-3.8.3-150600.4.6.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Issue summary: A timing side-channel which could potentially allow recovering
the private key exists in the ECDSA signature computation.

Impact summary: A timing side-channel in ECDSA signature computations
could allow recovering the private key by an attacker. However, measuring
the timing would require either local access to the signing application or
a very fast network connection with low latency.

There is a timing signal of around 300 nanoseconds when the top word of
the inverted ECDSA nonce value is zero. This can happen with significant
probability only for some of the supported elliptic curves. In particular
the NIST P-521 curve is affected. To be able to measure this leak, the attacker
process must either be located in the same physical computer or must
have a very fast network connection with low latency. For that reason
the severity of this vulnerability is Low.

The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are affected by this issue.</Note>
    </Notes>
    <CVE>CVE-2024-13176</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:libopenssl1_1-1.1.1w-150600.5.12.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mptcp: really cope with fastopen race

Fastopen and PM-trigger subflow shutdown can race, as reported by
syzkaller.

In my first attempt to close such race, I missed the fact that
the subflow status can change again before the subflow_state_change
callback is invoked.

Address the issue additionally copying with all the states directly
reachable from TCP_FIN_WAIT1.</Note>
    </Notes>
    <CVE>CVE-2024-26708</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vfio/pci: Lock external INTx masking ops

Mask operations through config space changes to DisINTx may race INTx
configuration changes via ioctl.  Create wrappers that add locking for
paths outside of the core interrupt code.

In particular, irq_type is updated holding igate, therefore testing
is_intx() requires holding igate.  For example clearing DisINTx from
config space can otherwise race changes of the interrupt configuration.

This aligns interfaces which may trigger the INTx eventfd into two
camps, one side serialized by igate and the other only enabled while
INTx is configured.  A subsequent patch introduces synchronization for
the latter flows.</Note>
    </Notes>
    <CVE>CVE-2024-26810</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/rtrs: Ensure 'ib_sge list' is accessible

Move the declaration of the 'ib_sge list' variable outside the
'always_invalidate' block to ensure it remains accessible for use
throughout the function.

Previously, 'ib_sge list' was declared within the 'always_invalidate'
block, limiting its accessibility, then caused a
'BUG: kernel NULL pointer dereference'[1].
 ? __die_body.cold+0x19/0x27
 ? page_fault_oops+0x15a/0x2d0
 ? search_module_extables+0x19/0x60
 ? search_bpf_extables+0x5f/0x80
 ? exc_page_fault+0x7e/0x180
 ? asm_exc_page_fault+0x26/0x30
 ? memcpy_orig+0xd5/0x140
 rxe_mr_copy+0x1c3/0x200 [rdma_rxe]
 ? rxe_pool_get_index+0x4b/0x80 [rdma_rxe]
 copy_data+0xa5/0x230 [rdma_rxe]
 rxe_requester+0xd9b/0xf70 [rdma_rxe]
 ? finish_task_switch.isra.0+0x99/0x2e0
 rxe_sender+0x13/0x40 [rdma_rxe]
 do_task+0x68/0x1e0 [rdma_rxe]
 process_one_work+0x177/0x330
 worker_thread+0x252/0x390
 ? __pfx_worker_thread+0x10/0x10

This change ensures the variable is available for subsequent operations
that require it.

[1] https://lore.kernel.org/linux-rdma/6a1f3e8f-deb0-49f9-bc69-a9b03ecfcda7@fujitsu.com/</Note>
    </Notes>
    <CVE>CVE-2024-36476</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: wwan: t7xx: Fix FSM command timeout issue

When driver processes the internal state change command, it use an
asynchronous thread to process the command operation. If the main
thread detects that the task has timed out, the asynchronous thread
will panic when executing the completion notification because the
main thread completion object has been released.

BUG: unable to handle page fault for address: fffffffffffffff8
PGD 1f283a067 P4D 1f283a067 PUD 1f283c067 PMD 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:complete_all+0x3e/0xa0
[...]
Call Trace:
 &lt;TASK&gt;
 ? __die_body+0x68/0xb0
 ? page_fault_oops+0x379/0x3e0
 ? exc_page_fault+0x69/0xa0
 ? asm_exc_page_fault+0x22/0x30
 ? complete_all+0x3e/0xa0
 fsm_main_thread+0xa3/0x9c0 [mtk_t7xx (HASH:1400 5)]
 ? __pfx_autoremove_wake_function+0x10/0x10
 kthread+0xd8/0x110
 ? __pfx_fsm_main_thread+0x10/0x10 [mtk_t7xx (HASH:1400 5)]
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x38/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1b/0x30
 &lt;/TASK&gt;
[...]
CR2: fffffffffffffff8
---[ end trace 0000000000000000 ]---

Use the reference counter to ensure safe release as Sergey suggests:
https://lore.kernel.org/all/da90f64c-260a-4329-87bf-1f9ff20a5951@gmail.com/</Note>
    </Notes>
    <CVE>CVE-2024-39282</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drop_monitor: replace spin_lock by raw_spin_lock

trace_drop_common() is called with preemption disabled, and it acquires
a spin_lock. This is problematic for RT kernels because spin_locks are
sleeping locks in this configuration, which causes the following splat:

BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47
preempt_count: 1, expected: 0
RCU nest depth: 2, expected: 2
5 locks held by rcuc/47/449:
 #0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210
 #1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130
 #2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210
 #3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70
 #4: ff1100086ee07520 (&amp;data-&gt;lock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290
irq event stamp: 139909
hardirqs last  enabled at (139908): [&lt;ffffffffb1df2b33&gt;] _raw_spin_unlock_irqrestore+0x63/0x80
hardirqs last disabled at (139909): [&lt;ffffffffb19bd03d&gt;] trace_drop_common.constprop.0+0x26d/0x290
softirqs last  enabled at (139892): [&lt;ffffffffb07a1083&gt;] __local_bh_enable_ip+0x103/0x170
softirqs last disabled at (139898): [&lt;ffffffffb0909b33&gt;] rcu_cpu_kthread+0x93/0x1f0
Preemption disabled at:
[&lt;ffffffffb1de786b&gt;] rt_mutex_slowunlock+0xab/0x2e0
CPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7
Hardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x8c/0xd0
 dump_stack+0x14/0x20
 __might_resched+0x21e/0x2f0
 rt_spin_lock+0x5e/0x130
 ? trace_drop_common.constprop.0+0xb5/0x290
 ? skb_queue_purge_reason.part.0+0x1bf/0x230
 trace_drop_common.constprop.0+0xb5/0x290
 ? preempt_count_sub+0x1c/0xd0
 ? _raw_spin_unlock_irqrestore+0x4a/0x80
 ? __pfx_trace_drop_common.constprop.0+0x10/0x10
 ? rt_mutex_slowunlock+0x26a/0x2e0
 ? skb_queue_purge_reason.part.0+0x1bf/0x230
 ? __pfx_rt_mutex_slowunlock+0x10/0x10
 ? skb_queue_purge_reason.part.0+0x1bf/0x230
 trace_kfree_skb_hit+0x15/0x20
 trace_kfree_skb+0xe9/0x150
 kfree_skb_reason+0x7b/0x110
 skb_queue_purge_reason.part.0+0x1bf/0x230
 ? __pfx_skb_queue_purge_reason.part.0+0x10/0x10
 ? mark_lock.part.0+0x8a/0x520
...

trace_drop_common() also disables interrupts, but this is a minor issue
because we could easily replace it with a local_lock.

Replace the spin_lock with raw_spin_lock to avoid sleeping in atomic
context.</Note>
    </Notes>
    <CVE>CVE-2024-40980</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm: prevent derefencing NULL ptr in pfn_section_valid()

Commit 5ec8e8ea8b77 ("mm/sparsemem: fix race in accessing
memory_section-&gt;usage") changed pfn_section_valid() to add a READ_ONCE()
call around "ms-&gt;usage" to fix a race with section_deactivate() where
ms-&gt;usage can be cleared.  The READ_ONCE() call, by itself, is not enough
to prevent NULL pointer dereference.  We need to check its value before
dereferencing it.</Note>
    </Notes>
    <CVE>CVE-2024-41055</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Vim is an open source command line text editor. When performing a search and displaying the search-count message is disabled (:set shm+=S), the search pattern is displayed at the bottom of the screen in a buffer (msgbuf). When right-left mode (:set rl) is enabled, the search pattern is reversed. This happens by allocating a new buffer. If the search pattern contains some ASCII NUL characters, the buffer allocated will be smaller than the original allocated buffer (because for allocating the reversed buffer, the strlen() function is called, which only counts until it notices an ASCII NUL byte ) and thus the original length indicator is wrong. This causes an overflow when accessing characters inside the msgbuf by the previously (now wrong) length of the msgbuf. The issue has been fixed as of Vim patch v9.1.0689.</Note>
    </Notes>
    <CVE>CVE-2024-43790</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:vim-9.1.1101-150500.20.21.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:vim-data-common-9.1.1101-150500.20.21.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 improved version of the unix vi text editor. When flushing the typeahead buffer, Vim moves the current position in the typeahead buffer but does not check whether there is enough space left in the buffer to handle the next characters.  So this may lead to the tb_off position within the typebuf variable to point outside of the valid buffer size, which can then later lead to a heap-buffer overflow in e.g. ins_typebuf(). Therefore, when flushing the typeahead buffer, check if there is enough space left before advancing the off position. If not, fall back to flush current typebuf contents. It's not quite clear yet, what can lead to this situation. It seems to happen when error messages occur (which will cause Vim to flush the typeahead buffer) in comnination with several long mappgins and so it may eventually move the off position out of a valid buffer size. Impact is low since it is not easily reproducible and requires to have several mappings active and run into some error condition. But when this happens, this will cause a crash. The issue has been fixed as of Vim patch v9.1.0697. Users are advised to upgrade. There are no known workarounds for this issue.</Note>
    </Notes>
    <CVE>CVE-2024-43802</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:vim-9.1.1101-150500.20.21.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:vim-data-common-9.1.1101-150500.20.21.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: apple: fix device reference counting

Drivers must call nvme_uninit_ctrl after a successful nvme_init_ctrl.
Split the allocation side out to make the error handling boundary easier
to navigate. The apple driver had been doing this wrong, leaking the
controller device memory on a tagset failure.</Note>
    </Notes>
    <CVE>CVE-2024-43913</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

idpf: fix UAFs when destroying the queues

The second tagged commit started sometimes (very rarely, but possible)
throwing WARNs from
net/core/page_pool.c:page_pool_disable_direct_recycling().
Turned out idpf frees interrupt vectors with embedded NAPIs *before*
freeing the queues making page_pools' NAPI pointers lead to freed
memory before these pools are destroyed by libeth.
It's not clear whether there are other accesses to the freed vectors
when destroying the queues, but anyway, we usually free queue/interrupt
vectors only when the queues are destroyed and the NAPIs are guaranteed
to not be referenced anywhere.

Invert the allocation and freeing logic making queue/interrupt vectors
be allocated first and freed last. Vectors don't require queues to be
present, so this is safe. Additionally, this change allows to remove
that useless queue-&gt;q_vector pointer cleanup, as vectors are still
valid when freeing the queues (+ both are freed within one function,
so it's not clear why nullify the pointers at all).</Note>
    </Notes>
    <CVE>CVE-2024-44932</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mptcp: pm: avoid possible UaF when selecting endp

select_local_address() and select_signal_address() both select an
endpoint entry from the list inside an RCU protected section, but return
a reference to it, to be read later on. If the entry is dereferenced
after the RCU unlock, reading info could cause a Use-after-Free.

A simple solution is to copy the required info while inside the RCU
protected section to avoid any risk of UaF later. The address ID might
need to be modified later to handle the ID0 case later, so a copy seems
OK to deal with.</Note>
    </Notes>
    <CVE>CVE-2024-44974</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mptcp: pm: only decrement add_addr_accepted for MPJ req

Adding the following warning ...

  WARN_ON_ONCE(msk-&gt;pm.add_addr_accepted == 0)

... before decrementing the add_addr_accepted counter helped to find a
bug when running the "remove single subflow" subtest from the
mptcp_join.sh selftest.

Removing a 'subflow' endpoint will first trigger a RM_ADDR, then the
subflow closure. Before this patch, and upon the reception of the
RM_ADDR, the other peer will then try to decrement this
add_addr_accepted. That's not correct because the attached subflows have
not been created upon the reception of an ADD_ADDR.

A way to solve that is to decrement the counter only if the attached
subflow was an MP_JOIN to a remote id that was not 0, and initiated by
the host receiving the RM_ADDR.</Note>
    </Notes>
    <CVE>CVE-2024-45009</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mptcp: pm: only mark 'subflow' endp as available

Adding the following warning ...

  WARN_ON_ONCE(msk-&gt;pm.local_addr_used == 0)

... before decrementing the local_addr_used counter helped to find a bug
when running the "remove single address" subtest from the mptcp_join.sh
selftests.

Removing a 'signal' endpoint will trigger the removal of all subflows
linked to this endpoint via mptcp_pm_nl_rm_addr_or_subflow() with
rm_type == MPTCP_MIB_RMSUBFLOW. This will decrement the local_addr_used
counter, which is wrong in this case because this counter is linked to
'subflow' endpoints, and here it is a 'signal' endpoint that is being
removed.

Now, the counter is decremented, only if the ID is being used outside
of mptcp_pm_nl_rm_addr_or_subflow(), only for 'subflow' endpoints, and
if the ID is not 0 -- local_addr_used is not taking into account these
ones. This marking of the ID as being available, and the decrement is
done no matter if a subflow using this ID is currently available,
because the subflow could have been closed before.</Note>
    </Notes>
    <CVE>CVE-2024-45010</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Vim is an open source, command line text editor. Patch v9.1.0038 optimized how the cursor position is calculated and removed a loop, that verified that the cursor position always points inside a line and does not become invalid by pointing beyond the end of
a line. Back then we assumed this loop is unnecessary. However, this change made it possible that the cursor position stays invalid and points beyond the end of a line, which would eventually cause a heap-buffer-overflow when trying to access the line pointer at
the specified cursor position. It's not quite clear yet, what can lead to this situation that the cursor points to an invalid position. That's why patch v9.1.0707 does not include a test case. The only observed impact has been a program crash. This issue has been addressed in with the patch v9.1.0707. All users are advised to upgrade.</Note>
    </Notes>
    <CVE>CVE-2024-45306</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:vim-9.1.1101-150500.20.21.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:vim-data-common-9.1.1101-150500.20.21.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 logs are written to a widely-writable directory (the default), an unprivileged attacker may predict a privileged process's log file path and pre-create a symbolic link to a sensitive file in its place. When that privileged process runs, it will follow the planted symlink and overwrite that sensitive file. To fix that, glog now causes the program to exit (with status code 2) when it finds that the configured log file already exists.</Note>
    </Notes>
    <CVE>CVE-2024-45339</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:google-osconfig-agent-20250115.01-150000.1.44.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in grub2. A specially crafted JPEG file can cause the JPEG parser of grub2 to incorrectly check the bounds of its internal buffers, resulting in an out-of-bounds write. The possibility of overwriting sensitive information to bypass secure boot protections is not discarded.</Note>
    </Notes>
    <CVE>CVE-2024-45774</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-2.12-150600.8.21.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-arm64-efi-2.12-150600.8.21.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in grub2 where the grub_extcmd_dispatcher() function calls grub_arg_list_alloc() to allocate memory for the grub's argument list. However, it fails to check in case the memory allocation fails. Once the allocation fails, a NULL point will be processed by the parse_option() function, leading grub to crash or, in some rare scenarios, corrupt the IVT data.</Note>
    </Notes>
    <CVE>CVE-2024-45775</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-2.12-150600.8.21.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-arm64-efi-2.12-150600.8.21.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When reading the language .mo file in grub_mofile_open(), grub2 fails to verify an integer overflow when allocating its internal buffer. A crafted .mo file may lead the buffer size calculation to overflow, leading to out-of-bound reads and writes. This flaw allows an attacker to leak sensitive data or overwrite critical data, possibly circumventing secure boot protections.</Note>
    </Notes>
    <CVE>CVE-2024-45776</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-2.12-150600.8.21.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-arm64-efi-2.12-150600.8.21.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in grub2. The calculation of the translation buffer when reading a language .mo file in grub_gettext_getstr_from_position() may overflow, leading to a Out-of-bound write. This issue can be leveraged by an attacker to overwrite grub2's sensitive heap data, eventually leading to the circumvention of secure boot protections.</Note>
    </Notes>
    <CVE>CVE-2024-45777</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-2.12-150600.8.21.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-arm64-efi-2.12-150600.8.21.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A stack overflow flaw was found when reading a BFS file system. A crafted BFS filesystem may lead to an uncontrolled loop, causing grub2 to crash.</Note>
    </Notes>
    <CVE>CVE-2024-45778</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-2.12-150600.8.21.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-arm64-efi-2.12-150600.8.21.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An integer overflow flaw was found in the BFS file system driver in grub2. When reading a file with an indirect extent map, grub2 fails to validate the number of extent entries to be read. A crafted or corrupted BFS filesystem may cause an integer overflow during the file reading, leading to a heap of bounds read. As a consequence, sensitive data may be leaked, or grub2 will crash.</Note>
    </Notes>
    <CVE>CVE-2024-45779</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-2.12-150600.8.21.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-arm64-efi-2.12-150600.8.21.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in grub2. When reading tar files, grub2 allocates an internal buffer for the file name. However, it fails to properly verify the allocation against possible integer overflows. It's possible to cause the allocation length to overflow with a crafted tar file, leading to a heap out-of-bounds write. This flaw eventually allows an attacker to circumvent secure boot protections.</Note>
    </Notes>
    <CVE>CVE-2024-45780</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-2.12-150600.8.21.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-arm64-efi-2.12-150600.8.21.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in grub2. When reading a symbolic link's name from a UFS filesystem, grub2 fails to validate the string length taken as an input. The lack of validation may lead to a heap out-of-bounds write, causing data integrity issues and eventually allowing an attacker to circumvent secure boot protections.</Note>
    </Notes>
    <CVE>CVE-2024-45781</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-2.12-150600.8.21.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-arm64-efi-2.12-150600.8.21.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in the HFS filesystem. When reading an HFS volume's name at grub_fs_mount(), the HFS filesystem driver performs a strcpy() using the user-provided volume name as input without properly validating the volume name's length. This issue may read to a heap-based out-of-bounds writer, impacting grub's sensitive data integrity and eventually leading to a secure boot protection bypass.</Note>
    </Notes>
    <CVE>CVE-2024-45782</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-2.12-150600.8.21.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-arm64-efi-2.12-150600.8.21.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in grub2. When failing to mount an HFS+ grub, the hfsplus filesystem driver doesn't properly set an ERRNO value. This issue may lead to a NULL pointer access.</Note>
    </Notes>
    <CVE>CVE-2024-45783</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-2.12-150600.8.21.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-arm64-efi-2.12-150600.8.21.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i3c: mipi-i3c-hci: Mask ring interrupts before ring stop request

Bus cleanup path in DMA mode may trigger a RING_OP_STAT interrupt when
the ring is being stopped. Depending on timing between ring stop request
completion, interrupt handler removal and code execution this may lead
to a NULL pointer dereference in hci_dma_irq_handler() if it gets to run
after the io_data pointer is set to NULL in hci_dma_cleanup().

Prevent this my masking the ring interrupts before ring stop request.</Note>
    </Notes>
    <CVE>CVE-2024-45828</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mptcp: pm: Fix uaf in __timer_delete_sync

There are two paths to access mptcp_pm_del_add_timer, result in a race
condition:

     CPU1				CPU2
     ====                               ====
     net_rx_action
     napi_poll                          netlink_sendmsg
     __napi_poll                        netlink_unicast
     process_backlog                    netlink_unicast_kernel
     __netif_receive_skb                genl_rcv
     __netif_receive_skb_one_core       netlink_rcv_skb
     NF_HOOK                            genl_rcv_msg
     ip_local_deliver_finish            genl_family_rcv_msg
     ip_protocol_deliver_rcu            genl_family_rcv_msg_doit
     tcp_v4_rcv                         mptcp_pm_nl_flush_addrs_doit
     tcp_v4_do_rcv                      mptcp_nl_remove_addrs_list
     tcp_rcv_established                mptcp_pm_remove_addrs_and_subflows
     tcp_data_queue                     remove_anno_list_by_saddr
     mptcp_incoming_options             mptcp_pm_del_add_timer
     mptcp_pm_del_add_timer             kfree(entry)

In remove_anno_list_by_saddr(running on CPU2), after leaving the critical
zone protected by "pm.lock", the entry will be released, which leads to the
occurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1).

Keeping a reference to add_timer inside the lock, and calling
sk_stop_timer_sync() with this reference, instead of "entry-&gt;add_timer".

Move list_del(&amp;entry-&gt;list) to mptcp_pm_del_add_timer and inside the pm lock,
do not directly access any members of the entry outside the pm lock, which
can avoid similar "entry-&gt;x" uaf.</Note>
    </Notes>
    <CVE>CVE-2024-46858</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: don't access invalid sched

Since 2320c9e6a768 ("drm/sched: memset() 'job' in drm_sched_job_init()")
accessing job-&gt;base.sched can produce unexpected results as the initialisation
of (*job)-&gt;base.sched done in amdgpu_job_alloc is overwritten by the
memset.

This commit fixes an issue when a CS would fail validation and would
be rejected after job-&gt;num_ibs is incremented. In this case,
amdgpu_ib_free(ring-&gt;adev, ...) will be called, which would crash the
machine because the ring value is bogus.

To fix this, pass a NULL pointer to amdgpu_ib_free(): we can do this
because the device is actually not used in this function.

The next commit will remove the ring argument completely.

(cherry picked from commit 2ae520cb12831d264ceb97c61f72c59d33c0dbd7)</Note>
    </Notes>
    <CVE>CVE-2024-46896</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pinmux: Use sequential access to access desc-&gt;pinmux data

When two client of the same gpio call pinctrl_select_state() for the
same functionality, we are seeing NULL pointer issue while accessing
desc-&gt;mux_owner.

Let's say two processes A, B executing in pin_request() for the same pin
and process A updates the desc-&gt;mux_usecount but not yet updated the
desc-&gt;mux_owner while process B see the desc-&gt;mux_usecount which got
updated by A path and further executes strcmp and while accessing
desc-&gt;mux_owner it crashes with NULL pointer.

Serialize the access to mux related setting with a mutex lock.

	cpu0 (process A)			cpu1(process B)

pinctrl_select_state() {		  pinctrl_select_state() {
  pin_request() {				pin_request() {
  ...
						 ....
    } else {
         desc-&gt;mux_usecount++;
    						desc-&gt;mux_usecount &amp;&amp; strcmp(desc-&gt;mux_owner, owner)) {

         if (desc-&gt;mux_usecount &gt; 1)
               return 0;
         desc-&gt;mux_owner = owner;

  }						}</Note>
    </Notes>
    <CVE>CVE-2024-47141</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dma-debug: fix a possible deadlock on radix_lock

radix_lock() shouldn't be held while holding dma_hash_entry[idx].lock
otherwise, there's a possible deadlock scenario when
dma debug API is called holding rq_lock():

CPU0                   CPU1                       CPU2
dma_free_attrs()
check_unmap()          add_dma_entry()            __schedule() //out
                                                  (A) rq_lock()
get_hash_bucket()
(A) dma_entry_hash
                                                  check_sync()
                       (A) radix_lock()           (W) dma_entry_hash
dma_entry_free()
(W) radix_lock()
                       // CPU2's one
                       (W) rq_lock()

CPU1 situation can happen when it extending radix tree and
it tries to wake up kswapd via wake_all_kswapd().

CPU2 situation can happen while perf_event_task_sched_out()
(i.e. dma sync operation is called while deleting perf_event using
 etm and etr tmc which are Arm Coresight hwtracing driver backends).

To remove this possible situation, call dma_entry_free() after
put_hash_bucket() in check_unmap().</Note>
    </Notes>
    <CVE>CVE-2024-47143</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: avoid OOB when system.data xattr changes underneath the filesystem

When looking up for an entry in an inlined directory, if e_value_offs is
changed underneath the filesystem by some change in the block device, it
will lead to an out-of-bounds access that KASAN detects as an UAF.

EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none.
loop0: detected capacity change from 2048 to 2047
==================================================================
BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500
Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103

CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:93 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0x169/0x550 mm/kasan/report.c:488
 kasan_report+0x143/0x180 mm/kasan/report.c:601
 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500
 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697
 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573
 ext4_lookup_entry fs/ext4/namei.c:1727 [inline]
 ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795
 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633
 filename_create+0x297/0x540 fs/namei.c:3980
 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587
 __do_sys_symlinkat fs/namei.c:4610 [inline]
 __se_sys_symlinkat fs/namei.c:4607 [inline]
 __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f3e73ced469
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a
RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469
RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0
RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290
R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c
R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0
 &lt;/TASK&gt;

Calling ext4_xattr_ibody_find right after reading the inode with
ext4_get_inode_loc will lead to a check of the validity of the xattrs,
avoiding this problem.</Note>
    </Notes>
    <CVE>CVE-2024-47701</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dlm: fix possible lkb_resource null dereference

This patch fixes a possible null pointer dereference when this function is
called from request_lock() as lkb-&gt;lkb_resource is not assigned yet,
only after validate_lock_args() by calling attach_lkb(). Another issue
is that a resource name could be a non printable bytearray and we cannot
assume to be ASCII coded.

The log functionality is probably never being hit when DLM is used in
normal way and no debug logging is enabled. The null pointer dereference
can only occur on a new created lkb that does not have the resource
assigned yet, it probably never hits the null pointer dereference but we
should be sure that other changes might not change this behaviour and we
actually can hit the mentioned null pointer dereference.

In this patch we just drop the printout of the resource name, the lkb id
is enough to make a possible connection to a resource name if this
exists.</Note>
    </Notes>
    <CVE>CVE-2024-47809</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: rtw89: check return value of ieee80211_probereq_get() for RNR

The return value of ieee80211_probereq_get() might be NULL, so check it
before using to avoid NULL pointer access.

Addresses-Coverity-ID: 1529805 ("Dereference null return value")</Note>
    </Notes>
    <CVE>CVE-2024-48873</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bcache: revert replacing IS_ERR_OR_NULL with IS_ERR again

Commit 028ddcac477b ("bcache: Remove unnecessary NULL point check in
node allocations") leads a NULL pointer deference in cache_set_flush().

1721         if (!IS_ERR_OR_NULL(c-&gt;root))
1722                 list_add(&amp;c-&gt;root-&gt;list, &amp;c-&gt;btree_cache);

&gt;From the above code in cache_set_flush(), if previous registration code
fails before allocating c-&gt;root, it is possible c-&gt;root is NULL as what
it is initialized. __bch_btree_node_alloc() never returns NULL but
c-&gt;root is possible to be NULL at above line 1721.

This patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this.</Note>
    </Notes>
    <CVE>CVE-2024-48881</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">grub2 allowed attackers with access to the grub shell to access files on the encrypted disks.</Note>
    </Notes>
    <CVE>CVE-2024-49504</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-2.12-150600.8.21.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-arm64-efi-2.12-150600.8.21.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nvme-rdma: unquiesce admin_q before destroy it

Kernel will hang on destroy admin_q while we create ctrl failed, such
as following calltrace:

PID: 23644    TASK: ff2d52b40f439fc0  CPU: 2    COMMAND: "nvme"
 #0 [ff61d23de260fb78] __schedule at ffffffff8323bc15
 #1 [ff61d23de260fc08] schedule at ffffffff8323c014
 #2 [ff61d23de260fc28] blk_mq_freeze_queue_wait at ffffffff82a3dba1
 #3 [ff61d23de260fc78] blk_freeze_queue at ffffffff82a4113a
 #4 [ff61d23de260fc90] blk_cleanup_queue at ffffffff82a33006
 #5 [ff61d23de260fcb0] nvme_rdma_destroy_admin_queue at ffffffffc12686ce
 #6 [ff61d23de260fcc8] nvme_rdma_setup_ctrl at ffffffffc1268ced
 #7 [ff61d23de260fd28] nvme_rdma_create_ctrl at ffffffffc126919b
 #8 [ff61d23de260fd68] nvmf_dev_write at ffffffffc024f362
 #9 [ff61d23de260fe38] vfs_write at ffffffff827d5f25
    RIP: 00007fda7891d574  RSP: 00007ffe2ef06958  RFLAGS: 00000202
    RAX: ffffffffffffffda  RBX: 000055e8122a4d90  RCX: 00007fda7891d574
    RDX: 000000000000012b  RSI: 000055e8122a4d90  RDI: 0000000000000004
    RBP: 00007ffe2ef079c0   R8: 000000000000012b   R9: 000055e8122a4d90
    R10: 0000000000000000  R11: 0000000000000202  R12: 0000000000000004
    R13: 000055e8122923c0  R14: 000000000000012b  R15: 00007fda78a54500
    ORIG_RAX: 0000000000000001  CS: 0033  SS: 002b

This due to we have quiesced admi_q before cancel requests, but forgot
to unquiesce before destroy it, as a result we fail to drain the
pending requests, and hang on blk_mq_freeze_queue_wait() forever. Here
try to reuse nvme_rdma_teardown_admin_queue() to fix this issue and
simplify the code.</Note>
    </Notes>
    <CVE>CVE-2024-49569</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: fix slab-use-after-free in ext4_split_extent_at()

We hit the following use-after-free:

==================================================================
BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0
Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40
CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724
Call Trace:
 &lt;TASK&gt;
 kasan_report+0x93/0xc0
 ext4_split_extent_at+0xba8/0xcc0
 ext4_split_extent.isra.0+0x18f/0x500
 ext4_split_convert_extents+0x275/0x750
 ext4_ext_handle_unwritten_extents+0x73e/0x1580
 ext4_ext_map_blocks+0xe20/0x2dc0
 ext4_map_blocks+0x724/0x1700
 ext4_do_writepages+0x12d6/0x2a70
[...]

Allocated by task 40:
 __kmalloc_noprof+0x1ac/0x480
 ext4_find_extent+0xf3b/0x1e70
 ext4_ext_map_blocks+0x188/0x2dc0
 ext4_map_blocks+0x724/0x1700
 ext4_do_writepages+0x12d6/0x2a70
[...]

Freed by task 40:
 kfree+0xf1/0x2b0
 ext4_find_extent+0xa71/0x1e70
 ext4_ext_insert_extent+0xa22/0x3260
 ext4_split_extent_at+0x3ef/0xcc0
 ext4_split_extent.isra.0+0x18f/0x500
 ext4_split_convert_extents+0x275/0x750
 ext4_ext_handle_unwritten_extents+0x73e/0x1580
 ext4_ext_map_blocks+0xe20/0x2dc0
 ext4_map_blocks+0x724/0x1700
 ext4_do_writepages+0x12d6/0x2a70
[...]
==================================================================

The flow of issue triggering is as follows:

ext4_split_extent_at
  path = *ppath
  ext4_ext_insert_extent(ppath)
    ext4_ext_create_new_leaf(ppath)
      ext4_find_extent(orig_path)
        path = *orig_path
        read_extent_tree_block
          // return -ENOMEM or -EIO
        ext4_free_ext_path(path)
          kfree(path)
        *orig_path = NULL
  a. If err is -ENOMEM:
  ext4_ext_dirty(path + path-&gt;p_depth)
  // path use-after-free !!!
  b. If err is -EIO and we have EXT_DEBUG defined:
  ext4_ext_show_leaf(path)
    eh = path[depth].p_hdr
    // path also use-after-free !!!

So when trying to zeroout or fix the extent length, call ext4_find_extent()
to update the path.

In addition we use *ppath directly as an ext4_ext_show_leaf() input to
avoid possible use-after-free when EXT_DEBUG is defined, and to avoid
unnecessary path updates.</Note>
    </Notes>
    <CVE>CVE-2024-49884</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: add more sanity checks to qdisc_pkt_len_init()

One path takes care of SKB_GSO_DODGY, assuming
skb-&gt;len is bigger than hdr_len.

virtio_net_hdr_to_skb() does not fully dissect TCP headers,
it only make sure it is at least 20 bytes.

It is possible for an user to provide a malicious 'GSO' packet,
total length of 80 bytes.

- 20 bytes of IPv4 header
- 60 bytes TCP header
- a small gso_size like 8

virtio_net_hdr_to_skb() would declare this packet as a normal
GSO packet, because it would see 40 bytes of payload,
bigger than gso_size.

We need to make detect this case to not underflow
qdisc_skb_cb(skb)-&gt;pkt_len.</Note>
    </Notes>
    <CVE>CVE-2024-49948</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: Fix uaf in l2cap_connect

[Syzbot reported]
BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949
Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54

CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
Workqueue: hci2 hci_rx_work
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:93 [inline]
 dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0xc3/0x620 mm/kasan/report.c:488
 kasan_report+0xd9/0x110 mm/kasan/report.c:601
 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949
 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline]
 l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline]
 l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline]
 l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825
 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514
 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline]
 hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028
 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231
 process_scheduled_works kernel/workqueue.c:3312 [inline]
 worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389
 kthread+0x2c1/0x3a0 kernel/kthread.c:389
 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
...

Freed by task 5245:
 kasan_save_stack+0x33/0x60 mm/kasan/common.c:47
 kasan_save_track+0x14/0x30 mm/kasan/common.c:68
 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579
 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240
 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256
 kasan_slab_free include/linux/kasan.h:184 [inline]
 slab_free_hook mm/slub.c:2256 [inline]
 slab_free mm/slub.c:4477 [inline]
 kfree+0x12a/0x3b0 mm/slub.c:4598
 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline]
 kref_put include/linux/kref.h:65 [inline]
 l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline]
 l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802
 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241
 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline]
 hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265
 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583
 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917
 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328
 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231
 process_scheduled_works kernel/workqueue.c:3312 [inline]
 worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389
 kthread+0x2c1/0x3a0 kernel/kthread.c:389
 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244</Note>
    </Notes>
    <CVE>CVE-2024-49950</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: MGMT: Fix possible crash on mgmt_index_removed

If mgmt_index_removed is called while there are commands queued on
cmd_sync it could lead to crashes like the bellow trace:

0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc
0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth]
0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth]
0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth]

So while handling mgmt_index_removed this attempts to dequeue
commands passed as user_data to cmd_sync.</Note>
    </Notes>
    <CVE>CVE-2024-49951</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gso: fix udp gso fraglist segmentation after pull from frag_list

Detect gso fraglist skbs with corrupted geometry (see below) and
pass these to skb_segment instead of skb_segment_list, as the first
can segment them correctly.

Valid SKB_GSO_FRAGLIST skbs
- consist of two or more segments
- the head_skb holds the protocol headers plus first gso_size
- one or more frag_list skbs hold exactly one segment
- all but the last must be gso_size

Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can
modify these skbs, breaking these invariants.

In extreme cases they pull all data into skb linear. For UDP, this
causes a NULL ptr deref in __udpv4_gso_segment_list_csum at
udp_hdr(seg-&gt;next)-&gt;dest.

Detect invalid geometry due to pull, by checking head_skb size.
Don't just drop, as this may blackhole a destination. Convert to be
able to pass to regular skb_segment.</Note>
    </Notes>
    <CVE>CVE-2024-49978</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: dsa: improve shutdown sequence

Alexander Sverdlin presents 2 problems during shutdown with the
lan9303 driver. One is specific to lan9303 and the other just happens
to reproduce there.

The first problem is that lan9303 is unique among DSA drivers in that it
calls dev_get_drvdata() at "arbitrary runtime" (not probe, not shutdown,
not remove):

phy_state_machine()
-&gt; ...
   -&gt; dsa_user_phy_read()
      -&gt; ds-&gt;ops-&gt;phy_read()
         -&gt; lan9303_phy_read()
            -&gt; chip-&gt;ops-&gt;phy_read()
               -&gt; lan9303_mdio_phy_read()
                  -&gt; dev_get_drvdata()

But we never stop the phy_state_machine(), so it may continue to run
after dsa_switch_shutdown(). Our common pattern in all DSA drivers is
to set drvdata to NULL to suppress the remove() method that may come
afterwards. But in this case it will result in an NPD.

The second problem is that the way in which we set
dp-&gt;conduit-&gt;dsa_ptr = NULL; is concurrent with receive packet
processing. dsa_switch_rcv() checks once whether dev-&gt;dsa_ptr is NULL,
but afterwards, rather than continuing to use that non-NULL value,
dev-&gt;dsa_ptr is dereferenced again and again without NULL checks:
dsa_conduit_find_user() and many other places. In between dereferences,
there is no locking to ensure that what was valid once continues to be
valid.

Both problems have the common aspect that closing the conduit interface
solves them.

In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN
event in dsa_user_netdevice_event() which closes user ports as well.
dsa_port_disable_rt() calls phylink_stop(), which synchronously stops
the phylink state machine, and ds-&gt;ops-&gt;phy_read() will thus no longer
call into the driver after this point.

In the second case, dev_close(conduit) should do this, as per
Documentation/networking/driver.rst:

| Quiescence
| ----------
|
| After the ndo_stop routine has been called, the hardware must
| not receive or transmit any data.  All in flight packets must
| be aborted. If necessary, poll or wait for completion of
| any reset commands.

So it should be sufficient to ensure that later, when we zeroize
conduit-&gt;dsa_ptr, there will be no concurrent dsa_switch_rcv() call
on this conduit.

The addition of the netif_device_detach() function is to ensure that
ioctls, rtnetlinks and ethtool requests on the user ports no longer
propagate down to the driver - we're no longer prepared to handle them.

The race condition actually did not exist when commit 0650bf52b31f
("net: dsa: be compatible with masters which unregister on shutdown")
first introduced dsa_switch_shutdown(). It was created later, when we
stopped unregistering the user interfaces from a bad spot, and we just
replaced that sequence with a racy zeroization of conduit-&gt;dsa_ptr
(one which doesn't ensure that the interfaces aren't up).</Note>
    </Notes>
    <CVE>CVE-2024-49998</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync

This checks if the ACL connection remains valid as it could be destroyed
while hci_enhanced_setup_sync is pending on cmd_sync leading to the
following trace:

BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0x91b/0xa60
Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37

CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014
Workqueue: hci0 hci_cmd_sync_work
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x5d/0x80
 ? hci_enhanced_setup_sync+0x91b/0xa60
 print_report+0x152/0x4c0
 ? hci_enhanced_setup_sync+0x91b/0xa60
 ? __virt_addr_valid+0x1fa/0x420
 ? hci_enhanced_setup_sync+0x91b/0xa60
 kasan_report+0xda/0x1b0
 ? hci_enhanced_setup_sync+0x91b/0xa60
 hci_enhanced_setup_sync+0x91b/0xa60
 ? __pfx_hci_enhanced_setup_sync+0x10/0x10
 ? __pfx___mutex_lock+0x10/0x10
 hci_cmd_sync_work+0x1c2/0x330
 process_one_work+0x7d9/0x1360
 ? __pfx_lock_acquire+0x10/0x10
 ? __pfx_process_one_work+0x10/0x10
 ? assign_work+0x167/0x240
 worker_thread+0x5b7/0xf60
 ? __kthread_parkme+0xac/0x1c0
 ? __pfx_worker_thread+0x10/0x10
 ? __pfx_worker_thread+0x10/0x10
 kthread+0x293/0x360
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x2f/0x70
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;

Allocated by task 34:
 kasan_save_stack+0x30/0x50
 kasan_save_track+0x14/0x30
 __kasan_kmalloc+0x8f/0xa0
 __hci_conn_add+0x187/0x17d0
 hci_connect_sco+0x2e1/0xb90
 sco_sock_connect+0x2a2/0xb80
 __sys_connect+0x227/0x2a0
 __x64_sys_connect+0x6d/0xb0
 do_syscall_64+0x71/0x140
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Freed by task 37:
 kasan_save_stack+0x30/0x50
 kasan_save_track+0x14/0x30
 kasan_save_free_info+0x3b/0x60
 __kasan_slab_free+0x101/0x160
 kfree+0xd0/0x250
 device_release+0x9a/0x210
 kobject_put+0x151/0x280
 hci_conn_del+0x448/0xbf0
 hci_abort_conn_sync+0x46f/0x980
 hci_cmd_sync_work+0x1c2/0x330
 process_one_work+0x7d9/0x1360
 worker_thread+0x5b7/0xf60
 kthread+0x293/0x360
 ret_from_fork+0x2f/0x70
 ret_from_fork_asm+0x1a/0x30</Note>
    </Notes>
    <CVE>CVE-2024-50029</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: do not delay dst_entries_add() in dst_release()

dst_entries_add() uses per-cpu data that might be freed at netns
dismantle from ip6_route_net_exit() calling dst_entries_destroy()

Before ip6_route_net_exit() can be called, we release all
the dsts associated with this netns, via calls to dst_release(),
which waits an rcu grace period before calling dst_destroy()

dst_entries_add() use in dst_destroy() is racy, because
dst_entries_destroy() could have been called already.

Decrementing the number of dsts must happen sooner.

Notes:

1) in CONFIG_XFRM case, dst_destroy() can call
   dst_release_immediate(child), this might also cause UAF
   if the child does not have DST_NOCOUNT set.
   IPSEC maintainers might take a look and see how to address this.

2) There is also discussion about removing this count of dst,
   which might happen in future kernels.</Note>
    </Notes>
    <CVE>CVE-2024-50036</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

spi: mpc52xx: Add cancel_work_sync before module remove

If we remove the module which will call mpc52xx_spi_remove
it will free 'ms' through spi_unregister_controller.
while the work ms-&gt;work will be used. The sequence of operations
that may lead to a UAF bug.

Fix it by ensuring that the work is canceled before proceeding with
the cleanup in mpc52xx_spi_remove.</Note>
    </Notes>
    <CVE>CVE-2024-50051</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tty: n_gsm: Fix use-after-free in gsm_cleanup_mux

BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0
drivers/tty/n_gsm.c:3160 [n_gsm]
Read of size 8 at addr ffff88815fe99c00 by task poc/3379
CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56
Hardware name: VMware, Inc. VMware Virtual Platform/440BX
Desktop Reference Platform, BIOS 6.00 11/12/2020
Call Trace:
 &lt;TASK&gt;
 gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm]
 __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm]
 __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389
 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500
 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846
 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161
 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm]
 _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107
 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm]
 ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195
 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79
 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338
 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805
 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818

Allocated by task 65:
 gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm]
 gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm]
 gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm]
 gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm]
 tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391
 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39
 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445
 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229
 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391
 kthread+0x2a3/0x370 kernel/kthread.c:389
 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257

Freed by task 3367:
 kfree+0x126/0x420 mm/slub.c:4580
 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm]
 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm]
 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818

[Analysis]
gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux
can be freed by multi threads through ioctl,which leads
to the occurrence of uaf. Protect it by gsm tx lock.</Note>
    </Notes>
    <CVE>CVE-2024-50073</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow

Syzkaller reported this splat:

  ==================================================================
  BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881
  Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662

  CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #0
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
  Call Trace:
   &lt;TASK&gt;
   __dump_stack lib/dump_stack.c:94 [inline]
   dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
   print_address_description mm/kasan/report.c:377 [inline]
   print_report+0xc3/0x620 mm/kasan/report.c:488
   kasan_report+0xd9/0x110 mm/kasan/report.c:601
   mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881
   mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline]
   mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572
   mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603
   genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115
   genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]
   genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210
   netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551
   genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219
   netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline]
   netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357
   netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901
   sock_sendmsg_nosec net/socket.c:729 [inline]
   __sock_sendmsg net/socket.c:744 [inline]
   ____sys_sendmsg+0x9ae/0xb40 net/socket.c:2607
   ___sys_sendmsg+0x135/0x1e0 net/socket.c:2661
   __sys_sendmsg+0x117/0x1f0 net/socket.c:2690
   do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline]
   __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386
   do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411
   entry_SYSENTER_compat_after_hwframe+0x84/0x8e
  RIP: 0023:0xf7fe4579
  Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 &lt;5d&gt; 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00
  RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172
  RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140
  RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
  RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000
  R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
   &lt;/TASK&gt;

  Allocated by task 5387:
   kasan_save_stack+0x33/0x60 mm/kasan/common.c:47
   kasan_save_track+0x14/0x30 mm/kasan/common.c:68
   poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
   __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394
   kmalloc_noprof include/linux/slab.h:878 [inline]
   kzalloc_noprof include/linux/slab.h:1014 [inline]
   subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803
   subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956
   __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline]
   tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167
   mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764
   __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592
   mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642
   mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline]
   mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943
   mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777
   process_one_work+0x958/0x1b30 kernel/workqueue.c:3229
   process_scheduled_works kernel/workqueue.c:3310 [inline]
   worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391
   kthread+0x2c1/0x3a0 kernel/kthread.c:389
   ret_from_fork+0x45/0x80 arch/x86/ke
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-50085</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfsd: fix race between laundromat and free_stateid

There is a race between laundromat handling of revoked delegations
and a client sending free_stateid operation. Laundromat thread
finds that delegation has expired and needs to be revoked so it
marks the delegation stid revoked and it puts it on a reaper list
but then it unlock the state lock and the actual delegation revocation
happens without the lock. Once the stid is marked revoked a racing
free_stateid processing thread does the following (1) it calls
list_del_init() which removes it from the reaper list and (2) frees
the delegation stid structure. The laundromat thread ends up not
calling the revoke_delegation() function for this particular delegation
but that means it will no release the lock lease that exists on
the file.

Now, a new open for this file comes in and ends up finding that
lease list isn't empty and calls nfsd_breaker_owns_lease() which ends
up trying to derefence a freed delegation stateid. Leading to the
followint use-after-free KASAN warning:

kernel: ==================================================================
kernel: BUG: KASAN: slab-use-after-free in nfsd_breaker_owns_lease+0x140/0x160 [nfsd]
kernel: Read of size 8 at addr ffff0000e73cd0c8 by task nfsd/6205
kernel:
kernel: CPU: 2 UID: 0 PID: 6205 Comm: nfsd Kdump: loaded Not tainted 6.11.0-rc7+ #9
kernel: Hardware name: Apple Inc. Apple Virtualization Generic Platform, BIOS 2069.0.0.0.0 08/03/2024
kernel: Call trace:
kernel: dump_backtrace+0x98/0x120
kernel: show_stack+0x1c/0x30
kernel: dump_stack_lvl+0x80/0xe8
kernel: print_address_description.constprop.0+0x84/0x390
kernel: print_report+0xa4/0x268
kernel: kasan_report+0xb4/0xf8
kernel: __asan_report_load8_noabort+0x1c/0x28
kernel: nfsd_breaker_owns_lease+0x140/0x160 [nfsd]
kernel: nfsd_file_do_acquire+0xb3c/0x11d0 [nfsd]
kernel: nfsd_file_acquire_opened+0x84/0x110 [nfsd]
kernel: nfs4_get_vfs_file+0x634/0x958 [nfsd]
kernel: nfsd4_process_open2+0xa40/0x1a40 [nfsd]
kernel: nfsd4_open+0xa08/0xe80 [nfsd]
kernel: nfsd4_proc_compound+0xb8c/0x2130 [nfsd]
kernel: nfsd_dispatch+0x22c/0x718 [nfsd]
kernel: svc_process_common+0x8e8/0x1960 [sunrpc]
kernel: svc_process+0x3d4/0x7e0 [sunrpc]
kernel: svc_handle_xprt+0x828/0xe10 [sunrpc]
kernel: svc_recv+0x2cc/0x6a8 [sunrpc]
kernel: nfsd+0x270/0x400 [nfsd]
kernel: kthread+0x288/0x310
kernel: ret_from_fork+0x10/0x20

This patch proposes a fixed that's based on adding 2 new additional
stid's sc_status values that help coordinate between the laundromat
and other operations (nfsd4_free_stateid() and nfsd4_delegreturn()).

First to make sure, that once the stid is marked revoked, it is not
removed by the nfsd4_free_stateid(), the laundromat take a reference
on the stateid. Then, coordinating whether the stid has been put
on the cl_revoked list or we are processing FREE_STATEID and need to
make sure to remove it from the list, each check that state and act
accordingly. If laundromat has added to the cl_revoke list before
the arrival of FREE_STATEID, then nfsd4_free_stateid() knows to remove
it from the list. If nfsd4_free_stateid() finds that operations arrived
before laundromat has placed it on cl_revoke list, it marks the state
freed and then laundromat will no longer add it to the list.

Also, for nfsd4_delegreturn() when looking for the specified stid,
we need to access stid that are marked removed or freeable, it means
the laundromat has started processing it but hasn't finished and this
delegreturn needs to return nfserr_deleg_revoked and not
nfserr_bad_stateid. The latter will not trigger a FREE_STATEID and the
lack of it will leave this stid on the cl_revoked list indefinitely.</Note>
    </Notes>
    <CVE>CVE-2024-50106</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory

Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits
4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't
enforce 32-byte alignment of nCR3.

In the absolute worst case scenario, failure to ignore bits 4:0 can result
in an out-of-bounds read, e.g. if the target page is at the end of a
memslot, and the VMM isn't using guard pages.

Per the APM:

  The CR3 register points to the base address of the page-directory-pointer
  table. The page-directory-pointer table is aligned on a 32-byte boundary,
  with the low 5 address bits 4:0 assumed to be 0.

And the SDM's much more explicit:

  4:0    Ignored

Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow
that is broken.</Note>
    </Notes>
    <CVE>CVE-2024-50115</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xfrm: validate new SA's prefixlen using SA family when sel.family is unset

This expands the validation introduced in commit 07bf7908950a ("xfrm:
Validate address prefix lengths in the xfrm selector.")

syzbot created an SA with
    usersa.sel.family = AF_UNSPEC
    usersa.sel.prefixlen_s = 128
    usersa.family = AF_INET

Because of the AF_UNSPEC selector, verify_newsa_info doesn't put
limits on prefixlen_{s,d}. But then copy_from_user_state sets
x-&gt;sel.family to usersa.family (AF_INET). Do the same conversion in
verify_newsa_info before validating prefixlen_{s,d}, since that's how
prefixlen is going to be used later on.</Note>
    </Notes>
    <CVE>CVE-2024-50142</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix OOBs when building SMB2_IOCTL request

When using encryption, either enforced by the server or when using
'seal' mount option, the client will squash all compound request buffers
down for encryption into a single iov in smb2_set_next_command().

SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold the
SMB2_IOCTL request in the first iov, and if the user passes an input
buffer that is greater than 328 bytes, smb2_set_next_command() will
end up writing off the end of @rqst-&gt;iov[0].iov_base as shown below:

  mount.cifs //srv/share /mnt -o ...,seal
  ln -s $(perl -e "print('a')for 1..1024") /mnt/link

  BUG: KASAN: slab-out-of-bounds in
  smb2_set_next_command.cold+0x1d6/0x24c [cifs]
  Write of size 4116 at addr ffff8881148fcab8 by task ln/859

  CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
  1.16.3-2.fc40 04/01/2014
  Call Trace:
   &lt;TASK&gt;
   dump_stack_lvl+0x5d/0x80
   ? smb2_set_next_command.cold+0x1d6/0x24c [cifs]
   print_report+0x156/0x4d9
   ? smb2_set_next_command.cold+0x1d6/0x24c [cifs]
   ? __virt_addr_valid+0x145/0x310
   ? __phys_addr+0x46/0x90
   ? smb2_set_next_command.cold+0x1d6/0x24c [cifs]
   kasan_report+0xda/0x110
   ? smb2_set_next_command.cold+0x1d6/0x24c [cifs]
   kasan_check_range+0x10f/0x1f0
   __asan_memcpy+0x3c/0x60
   smb2_set_next_command.cold+0x1d6/0x24c [cifs]
   smb2_compound_op+0x238c/0x3840 [cifs]
   ? kasan_save_track+0x14/0x30
   ? kasan_save_free_info+0x3b/0x70
   ? vfs_symlink+0x1a1/0x2c0
   ? do_symlinkat+0x108/0x1c0
   ? __pfx_smb2_compound_op+0x10/0x10 [cifs]
   ? kmem_cache_free+0x118/0x3e0
   ? cifs_get_writable_path+0xeb/0x1a0 [cifs]
   smb2_get_reparse_inode+0x423/0x540 [cifs]
   ? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs]
   ? rcu_is_watching+0x20/0x50
   ? __kmalloc_noprof+0x37c/0x480
   ? smb2_create_reparse_symlink+0x257/0x490 [cifs]
   ? smb2_create_reparse_symlink+0x38f/0x490 [cifs]
   smb2_create_reparse_symlink+0x38f/0x490 [cifs]
   ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs]
   ? find_held_lock+0x8a/0xa0
   ? hlock_class+0x32/0xb0
   ? __build_path_from_dentry_optional_prefix+0x19d/0x2e0 [cifs]
   cifs_symlink+0x24f/0x960 [cifs]
   ? __pfx_make_vfsuid+0x10/0x10
   ? __pfx_cifs_symlink+0x10/0x10 [cifs]
   ? make_vfsgid+0x6b/0xc0
   ? generic_permission+0x96/0x2d0
   vfs_symlink+0x1a1/0x2c0
   do_symlinkat+0x108/0x1c0
   ? __pfx_do_symlinkat+0x10/0x10
   ? strncpy_from_user+0xaa/0x160
   __x64_sys_symlinkat+0xb9/0xf0
   do_syscall_64+0xbb/0x1d0
   entry_SYSCALL_64_after_hwframe+0x77/0x7f
  RIP: 0033:0x7f08d75c13bb</Note>
    </Notes>
    <CVE>CVE-2024-50151</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mptcp: handle consistently DSS corruption

Bugged peer implementation can send corrupted DSS options, consistently
hitting a few warning in the data path. Use DEBUG_NET assertions, to
avoid the splat on some builds and handle consistently the error, dumping
related MIBs and performing fallback and/or reset according to the
subflow type.</Note>
    </Notes>
    <CVE>CVE-2024-50185</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm/swapfile: skip HugeTLB pages for unuse_vma

I got a bad pud error and lost a 1GB HugeTLB when calling swapoff.  The
problem can be reproduced by the following steps:

 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory.
 2. Swapout the above anonymous memory.
 3. run swapoff and we will get a bad pud error in kernel message:

  mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7)

We can tell that pud_clear_bad is called by pud_none_or_clear_bad in
unuse_pud_range() by ftrace.  And therefore the HugeTLB pages will never
be freed because we lost it from page table.  We can skip HugeTLB pages
for unuse_vma to fix it.</Note>
    </Notes>
    <CVE>CVE-2024-50199</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nft_payload: sanitize offset and length before calling skb_checksum()

If access to offset + length is larger than the skbuff length, then
skb_checksum() triggers BUG_ON().

skb_checksum() internally subtracts the length parameter while iterating
over skbuff, BUG_ON(len) at the end of it checks that the expected
length to be included in the checksum calculation is fully consumed.</Note>
    </Notes>
    <CVE>CVE-2024-50251</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: fix crash when config small gso_max_size/gso_ipv4_max_size

Config a small gso_max_size/gso_ipv4_max_size will lead to an underflow
in sk_dst_gso_max_size(), which may trigger a BUG_ON crash,
because sk-&gt;sk_gso_max_size would be much bigger than device limits.
Call Trace:
tcp_write_xmit
    tso_segs = tcp_init_tso_segs(skb, mss_now);
        tcp_set_skb_tso_segs
            tcp_skb_pcount_set
                // skb-&gt;len = 524288, mss_now = 8
                // u16 tso_segs = 524288/8 = 65535 -&gt; 0
                tso_segs = DIV_ROUND_UP(skb-&gt;len, mss_now)
    BUG_ON(!tso_segs)
Add check for the minimum value of gso_max_size and gso_ipv4_max_size.</Note>
    </Notes>
    <CVE>CVE-2024-50258</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

rxrpc: Fix missing locking causing hanging calls

If a call gets aborted (e.g. because kafs saw a signal) between it being
queued for connection and the I/O thread picking up the call, the abort
will be prioritised over the connection and it will be removed from
local-&gt;new_client_calls by rxrpc_disconnect_client_call() without a lock
being held.  This may cause other calls on the list to disappear if a race
occurs.

Fix this by taking the client_call_lock when removing a call from whatever
list its -&gt;wait_link happens to be on.</Note>
    </Notes>
    <CVE>CVE-2024-50294</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sctp: properly validate chunk size in sctp_sf_ootb()

A size validation fix similar to that in Commit 50619dbf8db7 ("sctp: add
size validation when walking chunks") is also required in sctp_sf_ootb()
to address a crash reported by syzbot:

  BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712
  sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712
  sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166
  sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407
  sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88
  sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243
  sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159
  ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205
  ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233</Note>
    </Notes>
    <CVE>CVE-2024-50299</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()

The per-netns IP tunnel hash table is protected by the RTNL mutex and
ip_tunnel_find() is only called from the control path where the mutex is
taken.

Add a lockdep expression to hlist_for_each_entry_rcu() in
ip_tunnel_find() in order to validate that the mutex is held and to
silence the suspicious RCU usage warning [1].

[1]
WARNING: suspicious RCU usage
6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted
-----------------------------
net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
1 lock held by ip/362:
 #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60

stack backtrace:
CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0xba/0x110
 lockdep_rcu_suspicious.cold+0x4f/0xd6
 ip_tunnel_find+0x435/0x4d0
 ip_tunnel_newlink+0x517/0x7a0
 ipgre_newlink+0x14c/0x170
 __rtnl_newlink+0x1173/0x19c0
 rtnl_newlink+0x6c/0xa0
 rtnetlink_rcv_msg+0x3cc/0xf60
 netlink_rcv_skb+0x171/0x450
 netlink_unicast+0x539/0x7f0
 netlink_sendmsg+0x8c1/0xd80
 ____sys_sendmsg+0x8f9/0xc20
 ___sys_sendmsg+0x197/0x1e0
 __sys_sendmsg+0x122/0x1f0
 do_syscall_64+0xbb/0x1d0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f</Note>
    </Notes>
    <CVE>CVE-2024-50304</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

igb: Fix potential invalid memory access in igb_init_module()

The pci_register_driver() can fail and when this happened, the dca_notifier
needs to be unregistered, otherwise the dca_notifier can be called when
igb fails to install, resulting to invalid memory access.</Note>
    </Notes>
    <CVE>CVE-2024-52332</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx

As the introduction of the support for vsock and unix sockets in sockmap,
tls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK.
vsock and af_unix sockets have vsock_sock and unix_sock instead of
inet_connection_sock. For these sockets, tls_get_ctx may return an invalid
pointer and cause page fault in function tls_sw_ctx_rx.

BUG: unable to handle page fault for address: 0000000000040030
Workqueue: vsock-loopback vsock_loopback_work
RIP: 0010:sk_psock_strp_data_ready+0x23/0x60
Call Trace:
 ? __die+0x81/0xc3
 ? no_context+0x194/0x350
 ? do_page_fault+0x30/0x110
 ? async_page_fault+0x3e/0x50
 ? sk_psock_strp_data_ready+0x23/0x60
 virtio_transport_recv_pkt+0x750/0x800
 ? update_load_avg+0x7e/0x620
 vsock_loopback_work+0xd0/0x100
 process_one_work+0x1a7/0x360
 worker_thread+0x30/0x390
 ? create_worker+0x1a0/0x1a0
 kthread+0x112/0x130
 ? __kthread_cancel_work+0x40/0x40
 ret_from_fork+0x1f/0x40

v2:
  - Add IS_ICSK check
v3:
  - Update the commits in Fixes</Note>
    </Notes>
    <CVE>CVE-2024-53091</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

smb: client: Fix use-after-free of network namespace.

Recently, we got a customer report that CIFS triggers oops while
reconnecting to a server.  [0]

The workload runs on Kubernetes, and some pods mount CIFS servers
in non-root network namespaces.  The problem rarely happened, but
it was always while the pod was dying.

The root cause is wrong reference counting for network namespace.

CIFS uses kernel sockets, which do not hold refcnt of the netns that
the socket belongs to.  That means CIFS must ensure the socket is
always freed before its netns; otherwise, use-after-free happens.

The repro steps are roughly:

  1. mount CIFS in a non-root netns
  2. drop packets from the netns
  3. destroy the netns
  4. unmount CIFS

We can reproduce the issue quickly with the script [1] below and see
the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled.

When the socket is TCP, it is hard to guarantee the netns lifetime
without holding refcnt due to async timers.

Let's hold netns refcnt for each socket as done for SMC in commit
9744d2bf1976 ("smc: Fix use-after-free in tcp_write_timer_handler().").

Note that we need to move put_net() from cifs_put_tcp_session() to
clean_demultiplex_info(); otherwise, __sock_create() still could touch a
freed netns while cifsd tries to reconnect from cifs_demultiplex_thread().

Also, maybe_get_net() cannot be put just before __sock_create() because
the code is not under RCU and there is a small chance that the same
address happened to be reallocated to another netns.

[0]:
CIFS: VFS: \\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting...
CIFS: Serverclose failed 4 times, giving up
Unable to handle kernel paging request at virtual address 14de99e461f84a07
Mem abort info:
  ESR = 0x0000000096000004
  EC = 0x25: DABT (current EL), IL = 32 bits
  SET = 0, FnV = 0
  EA = 0, S1PTW = 0
  FSC = 0x04: level 0 translation fault
Data abort info:
  ISV = 0, ISS = 0x00000004
  CM = 0, WnR = 0
[14de99e461f84a07] address between user and kernel address ranges
Internal error: Oops: 0000000096000004 [#1] SMP
Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs
CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1
Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018
pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : fib_rules_lookup+0x44/0x238
lr : __fib_lookup+0x64/0xbc
sp : ffff8000265db790
x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01
x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580
x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500
x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002
x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294
x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000
x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0
x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500
Call trace:
 fib_rules_lookup+0x44/0x238
 __fib_lookup+0x64/0xbc
 ip_route_output_key_hash_rcu+0x2c4/0x398
 ip_route_output_key_hash+0x60/0x8c
 tcp_v4_connect+0x290/0x488
 __inet_stream_connect+0x108/0x3d0
 inet_stream_connect+0x50/0x78
 kernel_connect+0x6c/0xac
 generic_ip_conne
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-53095</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mptcp: error out earlier on disconnect

Eric reported a division by zero splat in the MPTCP protocol:

Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted
6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 09/13/2024
RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163
Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8
0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 &lt;f7&gt; 7c
24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89
RSP: 0018:ffffc900041f7930 EFLAGS: 00010293
RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b
RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004
RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67
R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80
R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000
FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
&lt;TASK&gt;
__tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493
mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline]
mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289
inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885
sock_recvmsg_nosec net/socket.c:1051 [inline]
sock_recvmsg+0x1b2/0x250 net/socket.c:1073
__sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265
__do_sys_recvfrom net/socket.c:2283 [inline]
__se_sys_recvfrom net/socket.c:2279 [inline]
__x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7feb5d857559
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48
89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d
01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d
RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559
RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003
RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000
R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c
R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef

and provided a nice reproducer.

The root cause is the current bad handling of racing disconnect.
After the blamed commit below, sk_wait_data() can return (with
error) with the underlying socket disconnected and a zero rcv_mss.

Catch the error and return without performing any additional
operations on the current socket.</Note>
    </Notes>
    <CVE>CVE-2024-53123</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

exfat: fix out-of-bounds access of directory entries

In the case of the directory size is greater than or equal to
the cluster size, if start_clu becomes an EOF cluster(an invalid
cluster) due to file system corruption, then the directory entry
where ei-&gt;hint_femp.eidx hint is outside the directory, resulting
in an out-of-bounds access, which may cause further file system
corruption.

This commit adds a check for start_clu, if it is an invalid cluster,
the file or directory will be treated as empty.</Note>
    </Notes>
    <CVE>CVE-2024-53147</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: sched: fix ordering of qlen adjustment

Changes to sch-&gt;q.qlen around qdisc_tree_reduce_backlog() need to happen
_before_ a call to said function because otherwise it may fail to notify
parent qdiscs when the child is about to become empty.</Note>
    </Notes>
    <CVE>CVE-2024-53164</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket

BUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0
Read of size 1 at addr ffff888111f322cd by task swapper/0/0

CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1
Call Trace:
 &lt;IRQ&gt;
 dump_stack_lvl+0x68/0xa0
 print_address_description.constprop.0+0x2c/0x3d0
 print_report+0xb4/0x270
 kasan_report+0xbd/0xf0
 tcp_write_timer_handler+0x156/0x3e0
 tcp_write_timer+0x66/0x170
 call_timer_fn+0xfb/0x1d0
 __run_timers+0x3f8/0x480
 run_timer_softirq+0x9b/0x100
 handle_softirqs+0x153/0x390
 __irq_exit_rcu+0x103/0x120
 irq_exit_rcu+0xe/0x20
 sysvec_apic_timer_interrupt+0x76/0x90
 &lt;/IRQ&gt;
 &lt;TASK&gt;
 asm_sysvec_apic_timer_interrupt+0x1a/0x20
RIP: 0010:default_idle+0xf/0x20
Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90
 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 &lt;fa&gt; c3 cc cc cc
 cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90
RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242
RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590f
RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835d
R10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000
R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0
 default_idle_call+0x6b/0xa0
 cpuidle_idle_call+0x1af/0x1f0
 do_idle+0xbc/0x130
 cpu_startup_entry+0x33/0x40
 rest_init+0x11f/0x210
 start_kernel+0x39a/0x420
 x86_64_start_reservations+0x18/0x30
 x86_64_start_kernel+0x97/0xa0
 common_startup_64+0x13e/0x141
 &lt;/TASK&gt;

Allocated by task 595:
 kasan_save_stack+0x24/0x50
 kasan_save_track+0x14/0x30
 __kasan_slab_alloc+0x87/0x90
 kmem_cache_alloc_noprof+0x12b/0x3f0
 copy_net_ns+0x94/0x380
 create_new_namespaces+0x24c/0x500
 unshare_nsproxy_namespaces+0x75/0xf0
 ksys_unshare+0x24e/0x4f0
 __x64_sys_unshare+0x1f/0x30
 do_syscall_64+0x70/0x180
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Freed by task 100:
 kasan_save_stack+0x24/0x50
 kasan_save_track+0x14/0x30
 kasan_save_free_info+0x3b/0x60
 __kasan_slab_free+0x54/0x70
 kmem_cache_free+0x156/0x5d0
 cleanup_net+0x5d3/0x670
 process_one_work+0x776/0xa90
 worker_thread+0x2e2/0x560
 kthread+0x1a8/0x1f0
 ret_from_fork+0x34/0x60
 ret_from_fork_asm+0x1a/0x30

Reproduction script:

mkdir -p /mnt/nfsshare
mkdir -p /mnt/nfs/netns_1
mkfs.ext4 /dev/sdb
mount /dev/sdb /mnt/nfsshare
systemctl restart nfs-server
chmod 777 /mnt/nfsshare
exportfs -i -o rw,no_root_squash *:/mnt/nfsshare

ip netns add netns_1
ip link add name veth_1_peer type veth peer veth_1
ifconfig veth_1_peer 11.11.0.254 up
ip link set veth_1 netns netns_1
ip netns exec netns_1 ifconfig veth_1 11.11.0.1

ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp \
	--tcp-flags FIN FIN  -j DROP

(note: In my environment, a DESTROY_CLIENTID operation is always sent
 immediately, breaking the nfs tcp connection.)
ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 \
	11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1

ip netns del netns_1

The reason here is that the tcp socket in netns_1 (nfs side) has been
shutdown and closed (done in xs_destroy), but the FIN message (with ack)
is discarded, and the nfsd side keeps sending retransmission messages.
As a result, when the tcp sock in netns_1 processes the received message,
it sends the message (FIN message) in the sending queue, and the tcp timer
is re-established. When the network namespace is deleted, the net structure
accessed by tcp's timer handler function causes problems.

To fix this problem, let's hold netns refcnt for the tcp kernel socket as
done in other modules. This is an ugly hack which can easily be backported
to earlier kernels. A proper fix which cleans up the interfaces will
follow, but may not be so easy to backport.</Note>
    </Notes>
    <CVE>CVE-2024-53168</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

block: fix uaf for flush rq while iterating tags

blk_mq_clear_flush_rq_mapping() is not called during scsi probe, by
checking blk_queue_init_done(). However, QUEUE_FLAG_INIT_DONE is cleared
in del_gendisk by commit aec89dc5d421 ("block: keep q_usage_counter in
atomic mode after del_gendisk"), hence for disk like scsi, following
blk_mq_destroy_queue() will not clear flush rq from tags-&gt;rqs[] as well,
cause following uaf that is found by our syzkaller for v6.6:

==================================================================
BUG: KASAN: slab-use-after-free in blk_mq_find_and_get_req+0x16e/0x1a0 block/blk-mq-tag.c:261
Read of size 4 at addr ffff88811c969c20 by task kworker/1:2H/224909

CPU: 1 PID: 224909 Comm: kworker/1:2H Not tainted 6.6.0-ga836a5060850 #32
Workqueue: kblockd blk_mq_timeout_work
Call Trace:

__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106
print_address_description.constprop.0+0x66/0x300 mm/kasan/report.c:364
print_report+0x3e/0x70 mm/kasan/report.c:475
kasan_report+0xb8/0xf0 mm/kasan/report.c:588
blk_mq_find_and_get_req+0x16e/0x1a0 block/blk-mq-tag.c:261
bt_iter block/blk-mq-tag.c:288 [inline]
__sbitmap_for_each_set include/linux/sbitmap.h:295 [inline]
sbitmap_for_each_set include/linux/sbitmap.h:316 [inline]
bt_for_each+0x455/0x790 block/blk-mq-tag.c:325
blk_mq_queue_tag_busy_iter+0x320/0x740 block/blk-mq-tag.c:534
blk_mq_timeout_work+0x1a3/0x7b0 block/blk-mq.c:1673
process_one_work+0x7c4/0x1450 kernel/workqueue.c:2631
process_scheduled_works kernel/workqueue.c:2704 [inline]
worker_thread+0x804/0xe40 kernel/workqueue.c:2785
kthread+0x346/0x450 kernel/kthread.c:388
ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:293

Allocated by task 942:
kasan_save_stack+0x22/0x50 mm/kasan/common.c:45
kasan_set_track+0x25/0x30 mm/kasan/common.c:52
____kasan_kmalloc mm/kasan/common.c:374 [inline]
__kasan_kmalloc mm/kasan/common.c:383 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:380
kasan_kmalloc include/linux/kasan.h:198 [inline]
__do_kmalloc_node mm/slab_common.c:1007 [inline]
__kmalloc_node+0x69/0x170 mm/slab_common.c:1014
kmalloc_node include/linux/slab.h:620 [inline]
kzalloc_node include/linux/slab.h:732 [inline]
blk_alloc_flush_queue+0x144/0x2f0 block/blk-flush.c:499
blk_mq_alloc_hctx+0x601/0x940 block/blk-mq.c:3788
blk_mq_alloc_and_init_hctx+0x27f/0x330 block/blk-mq.c:4261
blk_mq_realloc_hw_ctxs+0x488/0x5e0 block/blk-mq.c:4294
blk_mq_init_allocated_queue+0x188/0x860 block/blk-mq.c:4350
blk_mq_init_queue_data block/blk-mq.c:4166 [inline]
blk_mq_init_queue+0x8d/0x100 block/blk-mq.c:4176
scsi_alloc_sdev+0x843/0xd50 drivers/scsi/scsi_scan.c:335
scsi_probe_and_add_lun+0x77c/0xde0 drivers/scsi/scsi_scan.c:1189
__scsi_scan_target+0x1fc/0x5a0 drivers/scsi/scsi_scan.c:1727
scsi_scan_channel drivers/scsi/scsi_scan.c:1815 [inline]
scsi_scan_channel+0x14b/0x1e0 drivers/scsi/scsi_scan.c:1791
scsi_scan_host_selected+0x2fe/0x400 drivers/scsi/scsi_scan.c:1844
scsi_scan+0x3a0/0x3f0 drivers/scsi/scsi_sysfs.c:151
store_scan+0x2a/0x60 drivers/scsi/scsi_sysfs.c:191
dev_attr_store+0x5c/0x90 drivers/base/core.c:2388
sysfs_kf_write+0x11c/0x170 fs/sysfs/file.c:136
kernfs_fop_write_iter+0x3fc/0x610 fs/kernfs/file.c:338
call_write_iter include/linux/fs.h:2083 [inline]
new_sync_write+0x1b4/0x2d0 fs/read_write.c:493
vfs_write+0x76c/0xb00 fs/read_write.c:586
ksys_write+0x127/0x250 fs/read_write.c:639
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x70/0x120 arch/x86/entry/common.c:81
entry_SYSCALL_64_after_hwframe+0x78/0xe2

Freed by task 244687:
kasan_save_stack+0x22/0x50 mm/kasan/common.c:45
kasan_set_track+0x25/0x30 mm/kasan/common.c:52
kasan_save_free_info+0x2b/0x50 mm/kasan/generic.c:522
____kasan_slab_free mm/kasan/common.c:236 [inline]
__kasan_slab_free+0x12a/0x1b0 mm/kasan/common.c:244
kasan_slab_free include/linux/kasan.h:164 [in
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-53170</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ubi: fastmap: Fix duplicate slab cache names while attaching

Since commit 4c39529663b9 ("slab: Warn on duplicate cache names when
DEBUG_VM=y"), the duplicate slab cache names can be detected and a
kernel WARNING is thrown out.
In UBI fast attaching process, alloc_ai() could be invoked twice
with the same slab cache name 'ubi_aeb_slab_cache', which will trigger
following warning messages:
 kmem_cache of name 'ubi_aeb_slab_cache' already exists
 WARNING: CPU: 0 PID: 7519 at mm/slab_common.c:107
          __kmem_cache_create_args+0x100/0x5f0
 Modules linked in: ubi(+) nandsim [last unloaded: nandsim]
 CPU: 0 UID: 0 PID: 7519 Comm: modprobe Tainted: G 6.12.0-rc2
 RIP: 0010:__kmem_cache_create_args+0x100/0x5f0
 Call Trace:
   __kmem_cache_create_args+0x100/0x5f0
   alloc_ai+0x295/0x3f0 [ubi]
   ubi_attach+0x3c3/0xcc0 [ubi]
   ubi_attach_mtd_dev+0x17cf/0x3fa0 [ubi]
   ubi_init+0x3fb/0x800 [ubi]
   do_init_module+0x265/0x7d0
   __x64_sys_finit_module+0x7a/0xc0

The problem could be easily reproduced by loading UBI device by fastmap
with CONFIG_DEBUG_VM=y.
Fix it by using different slab names for alloc_ai() callers.</Note>
    </Notes>
    <CVE>CVE-2024-53172</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

NFSv4.0: Fix a use-after-free problem in the asynchronous open()

Yang Erkun reports that when two threads are opening files at the same
time, and are forced to abort before a reply is seen, then the call to
nfs_release_seqid() in nfs4_opendata_free() can result in a
use-after-free of the pointer to the defunct rpc task of the other
thread.
The fix is to ensure that if the RPC call is aborted before the call to
nfs_wait_on_sequence() is complete, then we must call nfs_release_seqid()
in nfs4_open_release() before the rpc_task is freed.</Note>
    </Notes>
    <CVE>CVE-2024-53173</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipc: fix memleak if msg_init_ns failed in create_ipc_ns

Percpu memory allocation may failed during create_ipc_ns however this
fail is not handled properly since ipc sysctls and mq sysctls is not
released properly. Fix this by release these two resource when failure.

Here is the kmemleak stack when percpu failed:

unreferenced object 0xffff88819de2a600 (size 512):
  comm "shmem_2nstest", pid 120711, jiffies 4300542254
  hex dump (first 32 bytes):
    60 aa 9d 84 ff ff ff ff fc 18 48 b2 84 88 ff ff  `.........H.....
    04 00 00 00 a4 01 00 00 20 e4 56 81 ff ff ff ff  ........ .V.....
  backtrace (crc be7cba35):
    [&lt;ffffffff81b43f83&gt;] __kmalloc_node_track_caller_noprof+0x333/0x420
    [&lt;ffffffff81a52e56&gt;] kmemdup_noprof+0x26/0x50
    [&lt;ffffffff821b2f37&gt;] setup_mq_sysctls+0x57/0x1d0
    [&lt;ffffffff821b29cc&gt;] copy_ipcs+0x29c/0x3b0
    [&lt;ffffffff815d6a10&gt;] create_new_namespaces+0x1d0/0x920
    [&lt;ffffffff815d7449&gt;] copy_namespaces+0x2e9/0x3e0
    [&lt;ffffffff815458f3&gt;] copy_process+0x29f3/0x7ff0
    [&lt;ffffffff8154b080&gt;] kernel_clone+0xc0/0x650
    [&lt;ffffffff8154b6b1&gt;] __do_sys_clone+0xa1/0xe0
    [&lt;ffffffff843df8ff&gt;] do_syscall_64+0xbf/0x1c0
    [&lt;ffffffff846000b0&gt;] entry_SYSCALL_64_after_hwframe+0x4b/0x53</Note>
    </Notes>
    <CVE>CVE-2024-53175</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

smb: During unmount, ensure all cached dir instances drop their dentry

The unmount process (cifs_kill_sb() calling close_all_cached_dirs()) can
race with various cached directory operations, which ultimately results
in dentries not being dropped and these kernel BUGs:

BUG: Dentry ffff88814f37e358{i=1000000000080,n=/}  still in use (2) [unmount of cifs cifs]
VFS: Busy inodes after unmount of cifs (cifs)
------------[ cut here ]------------
kernel BUG at fs/super.c:661!

This happens when a cfid is in the process of being cleaned up when, and
has been removed from the cfids-&gt;entries list, including:

- Receiving a lease break from the server
- Server reconnection triggers invalidate_all_cached_dirs(), which
  removes all the cfids from the list
- The laundromat thread decides to expire an old cfid.

To solve these problems, dropping the dentry is done in queued work done
in a newly-added cfid_put_wq workqueue, and close_all_cached_dirs()
flushes that workqueue after it drops all the dentries of which it's
aware. This is a global workqueue (rather than scoped to a mount), but
the queued work is minimal.

The final cleanup work for cleaning up a cfid is performed via work
queued in the serverclose_wq workqueue; this is done separate from
dropping the dentries so that close_all_cached_dirs() doesn't block on
any server operations.

Both of these queued works expect to invoked with a cfid reference and
a tcon reference to avoid those objects from being freed while the work
is ongoing.

While we're here, add proper locking to close_all_cached_dirs(), and
locking around the freeing of cfid-&gt;dentry.</Note>
    </Notes>
    <CVE>CVE-2024-53176</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

smb: prevent use-after-free due to open_cached_dir error paths

If open_cached_dir() encounters an error parsing the lease from the
server, the error handling may race with receiving a lease break,
resulting in open_cached_dir() freeing the cfid while the queued work is
pending.

Update open_cached_dir() to drop refs rather than directly freeing the
cfid.

Have cached_dir_lease_break(), cfids_laundromat_worker(), and
invalidate_all_cached_dirs() clear has_lease immediately while still
holding cfids-&gt;cfid_list_lock, and then use this to also simplify the
reference counting in cfids_laundromat_worker() and
invalidate_all_cached_dirs().

Fixes this KASAN splat (which manually injects an error and lease break
in open_cached_dir()):

==================================================================
BUG: KASAN: slab-use-after-free in smb2_cached_lease_break+0x27/0xb0
Read of size 8 at addr ffff88811cc24c10 by task kworker/3:1/65

CPU: 3 UID: 0 PID: 65 Comm: kworker/3:1 Not tainted 6.12.0-rc6-g255cf264e6e5-dirty #87
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
Workqueue: cifsiod smb2_cached_lease_break
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x77/0xb0
 print_report+0xce/0x660
 kasan_report+0xd3/0x110
 smb2_cached_lease_break+0x27/0xb0
 process_one_work+0x50a/0xc50
 worker_thread+0x2ba/0x530
 kthread+0x17c/0x1c0
 ret_from_fork+0x34/0x60
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;

Allocated by task 2464:
 kasan_save_stack+0x33/0x60
 kasan_save_track+0x14/0x30
 __kasan_kmalloc+0xaa/0xb0
 open_cached_dir+0xa7d/0x1fb0
 smb2_query_path_info+0x43c/0x6e0
 cifs_get_fattr+0x346/0xf10
 cifs_get_inode_info+0x157/0x210
 cifs_revalidate_dentry_attr+0x2d1/0x460
 cifs_getattr+0x173/0x470
 vfs_statx_path+0x10f/0x160
 vfs_statx+0xe9/0x150
 vfs_fstatat+0x5e/0xc0
 __do_sys_newfstatat+0x91/0xf0
 do_syscall_64+0x95/0x1a0
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Freed by task 2464:
 kasan_save_stack+0x33/0x60
 kasan_save_track+0x14/0x30
 kasan_save_free_info+0x3b/0x60
 __kasan_slab_free+0x51/0x70
 kfree+0x174/0x520
 open_cached_dir+0x97f/0x1fb0
 smb2_query_path_info+0x43c/0x6e0
 cifs_get_fattr+0x346/0xf10
 cifs_get_inode_info+0x157/0x210
 cifs_revalidate_dentry_attr+0x2d1/0x460
 cifs_getattr+0x173/0x470
 vfs_statx_path+0x10f/0x160
 vfs_statx+0xe9/0x150
 vfs_fstatat+0x5e/0xc0
 __do_sys_newfstatat+0x91/0xf0
 do_syscall_64+0x95/0x1a0
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Last potentially related work creation:
 kasan_save_stack+0x33/0x60
 __kasan_record_aux_stack+0xad/0xc0
 insert_work+0x32/0x100
 __queue_work+0x5c9/0x870
 queue_work_on+0x82/0x90
 open_cached_dir+0x1369/0x1fb0
 smb2_query_path_info+0x43c/0x6e0
 cifs_get_fattr+0x346/0xf10
 cifs_get_inode_info+0x157/0x210
 cifs_revalidate_dentry_attr+0x2d1/0x460
 cifs_getattr+0x173/0x470
 vfs_statx_path+0x10f/0x160
 vfs_statx+0xe9/0x150
 vfs_fstatat+0x5e/0xc0
 __do_sys_newfstatat+0x91/0xf0
 do_syscall_64+0x95/0x1a0
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

The buggy address belongs to the object at ffff88811cc24c00
 which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 16 bytes inside of
 freed 1024-byte region [ffff88811cc24c00, ffff88811cc25000)</Note>
    </Notes>
    <CVE>CVE-2024-53177</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

smb: Don't leak cfid when reconnect races with open_cached_dir

open_cached_dir() may either race with the tcon reconnection even before
compound_send_recv() or directly trigger a reconnection via
SMB2_open_init() or SMB_query_info_init().

The reconnection process invokes invalidate_all_cached_dirs() via
cifs_mark_open_files_invalid(), which removes all cfids from the
cfids-&gt;entries list but doesn't drop a ref if has_lease isn't true. This
results in the currently-being-constructed cfid not being on the list,
but still having a refcount of 2. It leaks if returned from
open_cached_dir().

Fix this by setting cfid-&gt;has_lease when the ref is actually taken; the
cfid will not be used by other threads until it has a valid time.

Addresses these kmemleaks:

unreferenced object 0xffff8881090c4000 (size 1024):
  comm "bash", pid 1860, jiffies 4295126592
  hex dump (first 32 bytes):
    00 01 00 00 00 00 ad de 22 01 00 00 00 00 ad de  ........".......
    00 ca 45 22 81 88 ff ff f8 dc 4f 04 81 88 ff ff  ..E"......O.....
  backtrace (crc 6f58c20f):
    [&lt;ffffffff8b895a1e&gt;] __kmalloc_cache_noprof+0x2be/0x350
    [&lt;ffffffff8bda06e3&gt;] open_cached_dir+0x993/0x1fb0
    [&lt;ffffffff8bdaa750&gt;] cifs_readdir+0x15a0/0x1d50
    [&lt;ffffffff8b9a853f&gt;] iterate_dir+0x28f/0x4b0
    [&lt;ffffffff8b9a9aed&gt;] __x64_sys_getdents64+0xfd/0x200
    [&lt;ffffffff8cf6da05&gt;] do_syscall_64+0x95/0x1a0
    [&lt;ffffffff8d00012f&gt;] entry_SYSCALL_64_after_hwframe+0x76/0x7e
unreferenced object 0xffff8881044fdcf8 (size 8):
  comm "bash", pid 1860, jiffies 4295126592
  hex dump (first 8 bytes):
    00 cc cc cc cc cc cc cc                          ........
  backtrace (crc 10c106a9):
    [&lt;ffffffff8b89a3d3&gt;] __kmalloc_node_track_caller_noprof+0x363/0x480
    [&lt;ffffffff8b7d7256&gt;] kstrdup+0x36/0x60
    [&lt;ffffffff8bda0700&gt;] open_cached_dir+0x9b0/0x1fb0
    [&lt;ffffffff8bdaa750&gt;] cifs_readdir+0x15a0/0x1d50
    [&lt;ffffffff8b9a853f&gt;] iterate_dir+0x28f/0x4b0
    [&lt;ffffffff8b9a9aed&gt;] __x64_sys_getdents64+0xfd/0x200
    [&lt;ffffffff8cf6da05&gt;] do_syscall_64+0x95/0x1a0
    [&lt;ffffffff8d00012f&gt;] entry_SYSCALL_64_after_hwframe+0x76/0x7e

And addresses these BUG splats when unmounting the SMB filesystem:

BUG: Dentry ffff888140590ba0{i=1000000000080,n=/}  still in use (2) [unmount of cifs cifs]
WARNING: CPU: 3 PID: 3433 at fs/dcache.c:1536 umount_check+0xd0/0x100
Modules linked in:
CPU: 3 UID: 0 PID: 3433 Comm: bash Not tainted 6.12.0-rc4-g850925a8133c-dirty #49
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
RIP: 0010:umount_check+0xd0/0x100
Code: 8d 7c 24 40 e8 31 5a f4 ff 49 8b 54 24 40 41 56 49 89 e9 45 89 e8 48 89 d9 41 57 48 89 de 48 c7 c7 80 e7 db ac e8 f0 72 9a ff &lt;0f&gt; 0b 58 31 c0 5a 5b 5d 41 5c 41 5d 41 5e 41 5f e9 2b e5 5d 01 41
RSP: 0018:ffff88811cc27978 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff888140590ba0 RCX: ffffffffaaf20bae
RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881f6fb6f40
RBP: ffff8881462ec000 R08: 0000000000000001 R09: ffffed1023984ee3
R10: ffff88811cc2771f R11: 00000000016cfcc0 R12: ffff888134383e08
R13: 0000000000000002 R14: ffff8881462ec668 R15: ffffffffaceab4c0
FS:  00007f23bfa98740(0000) GS:ffff8881f6f80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000556de4a6f808 CR3: 0000000123c80000 CR4: 0000000000350ef0
Call Trace:
 &lt;TASK&gt;
 d_walk+0x6a/0x530
 shrink_dcache_for_umount+0x6a/0x200
 generic_shutdown_super+0x52/0x2a0
 kill_anon_super+0x22/0x40
 cifs_kill_sb+0x159/0x1e0
 deactivate_locked_super+0x66/0xe0
 cleanup_mnt+0x140/0x210
 task_work_run+0xfb/0x170
 syscall_exit_to_user_mode+0x29f/0x2b0
 do_syscall_64+0xa1/0x1a0
 entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7f23bfb93ae7
Code: ff ff ff ff c3 66 0f 1f 44 00 00 48 8b 0d 11 93 0d 00 f7 d8 64 89 01 b8 ff ff ff ff eb bf 0f 1f 44 00 00 b8 50 00 00 00 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d e9 92 0d 00 f7 d8 64 89 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-53178</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix NULL ptr deref in crypto_aead_setkey()

Neither SMB3.0 or SMB3.02 supports encryption negotiate context, so
when SMB2_GLOBAL_CAP_ENCRYPTION flag is set in the negotiate response,
the client uses AES-128-CCM as the default cipher.  See MS-SMB2
3.3.5.4.

Commit b0abcd65ec54 ("smb: client: fix UAF in async decryption") added
a @server-&gt;cipher_type check to conditionally call
smb3_crypto_aead_allocate(), but that check would always be false as
@server-&gt;cipher_type is unset for SMB3.02.

Fix the following KASAN splat by setting @server-&gt;cipher_type for
SMB3.02 as well.

mount.cifs //srv/share /mnt -o vers=3.02,seal,...

BUG: KASAN: null-ptr-deref in crypto_aead_setkey+0x2c/0x130
Read of size 8 at addr 0000000000000020 by task mount.cifs/1095
CPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41
04/01/2014
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x5d/0x80
 ? crypto_aead_setkey+0x2c/0x130
 kasan_report+0xda/0x110
 ? crypto_aead_setkey+0x2c/0x130
 crypto_aead_setkey+0x2c/0x130
 crypt_message+0x258/0xec0 [cifs]
 ? __asan_memset+0x23/0x50
 ? __pfx_crypt_message+0x10/0x10 [cifs]
 ? mark_lock+0xb0/0x6a0
 ? hlock_class+0x32/0xb0
 ? mark_lock+0xb0/0x6a0
 smb3_init_transform_rq+0x352/0x3f0 [cifs]
 ? lock_acquire.part.0+0xf4/0x2a0
 smb_send_rqst+0x144/0x230 [cifs]
 ? __pfx_smb_send_rqst+0x10/0x10 [cifs]
 ? hlock_class+0x32/0xb0
 ? smb2_setup_request+0x225/0x3a0 [cifs]
 ? __pfx_cifs_compound_last_callback+0x10/0x10 [cifs]
 compound_send_recv+0x59b/0x1140 [cifs]
 ? __pfx_compound_send_recv+0x10/0x10 [cifs]
 ? __create_object+0x5e/0x90
 ? hlock_class+0x32/0xb0
 ? do_raw_spin_unlock+0x9a/0xf0
 cifs_send_recv+0x23/0x30 [cifs]
 SMB2_tcon+0x3ec/0xb30 [cifs]
 ? __pfx_SMB2_tcon+0x10/0x10 [cifs]
 ? lock_acquire.part.0+0xf4/0x2a0
 ? __pfx_lock_release+0x10/0x10
 ? do_raw_spin_trylock+0xc6/0x120
 ? lock_acquire+0x3f/0x90
 ? _get_xid+0x16/0xd0 [cifs]
 ? __pfx_SMB2_tcon+0x10/0x10 [cifs]
 ? cifs_get_smb_ses+0xcdd/0x10a0 [cifs]
 cifs_get_smb_ses+0xcdd/0x10a0 [cifs]
 ? __pfx_cifs_get_smb_ses+0x10/0x10 [cifs]
 ? cifs_get_tcp_session+0xaa0/0xca0 [cifs]
 cifs_mount_get_session+0x8a/0x210 [cifs]
 dfs_mount_share+0x1b0/0x11d0 [cifs]
 ? __pfx___lock_acquire+0x10/0x10
 ? __pfx_dfs_mount_share+0x10/0x10 [cifs]
 ? lock_acquire.part.0+0xf4/0x2a0
 ? find_held_lock+0x8a/0xa0
 ? hlock_class+0x32/0xb0
 ? lock_release+0x203/0x5d0
 cifs_mount+0xb3/0x3d0 [cifs]
 ? do_raw_spin_trylock+0xc6/0x120
 ? __pfx_cifs_mount+0x10/0x10 [cifs]
 ? lock_acquire+0x3f/0x90
 ? find_nls+0x16/0xa0
 ? smb3_update_mnt_flags+0x372/0x3b0 [cifs]
 cifs_smb3_do_mount+0x1e2/0xc80 [cifs]
 ? __pfx_vfs_parse_fs_string+0x10/0x10
 ? __pfx_cifs_smb3_do_mount+0x10/0x10 [cifs]
 smb3_get_tree+0x1bf/0x330 [cifs]
 vfs_get_tree+0x4a/0x160
 path_mount+0x3c1/0xfb0
 ? kasan_quarantine_put+0xc7/0x1d0
 ? __pfx_path_mount+0x10/0x10
 ? kmem_cache_free+0x118/0x3e0
 ? user_path_at+0x74/0xa0
 __x64_sys_mount+0x1a6/0x1e0
 ? __pfx___x64_sys_mount+0x10/0x10
 ? mark_held_locks+0x1a/0x90
 do_syscall_64+0xbb/0x1d0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f</Note>
    </Notes>
    <CVE>CVE-2024-53185</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

io_uring: check for overflows in io_pin_pages

WARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144
CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0
Call Trace:
 &lt;TASK&gt;
 __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183
 io_rings_map io_uring/io_uring.c:2611 [inline]
 io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470
 io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692
 io_uring_setup io_uring/io_uring.c:3781 [inline]
 ...
 &lt;/TASK&gt;

io_pin_pages()'s uaddr parameter came directly from the user and can be
garbage. Don't just add size to it as it can overflow.</Note>
    </Notes>
    <CVE>CVE-2024-53187</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

PCI: Fix use-after-free of slot-&gt;bus on hot remove

Dennis reports a boot crash on recent Lenovo laptops with a USB4 dock.

Since commit 0fc70886569c ("thunderbolt: Reset USB4 v2 host router") and
commit 59a54c5f3dbd ("thunderbolt: Reset topology created by the boot
firmware"), USB4 v2 and v1 Host Routers are reset on probe of the
thunderbolt driver.

The reset clears the Presence Detect State and Data Link Layer Link Active
bits at the USB4 Host Router's Root Port and thus causes hot removal of the
dock.

The crash occurs when pciehp is unbound from one of the dock's Downstream
Ports:  pciehp creates a pci_slot on bind and destroys it on unbind.  The
pci_slot contains a pointer to the pci_bus below the Downstream Port, but
a reference on that pci_bus is never acquired.  The pci_bus is destroyed
before the pci_slot, so a use-after-free ensues when pci_slot_release()
accesses slot-&gt;bus.

In principle this should not happen because pci_stop_bus_device() unbinds
pciehp (and therefore destroys the pci_slot) before the pci_bus is
destroyed by pci_remove_bus_device().

However the stacktrace provided by Dennis shows that pciehp is unbound from
pci_remove_bus_device() instead of pci_stop_bus_device().  To understand
the significance of this, one needs to know that the PCI core uses a two
step process to remove a portion of the hierarchy:  It first unbinds all
drivers in the sub-hierarchy in pci_stop_bus_device() and then actually
removes the devices in pci_remove_bus_device().  There is no precaution to
prevent driver binding in-between pci_stop_bus_device() and
pci_remove_bus_device().

In Dennis' case, it seems removal of the hierarchy by pciehp races with
driver binding by pci_bus_add_devices().  pciehp is bound to the
Downstream Port after pci_stop_bus_device() has run, so it is unbound by
pci_remove_bus_device() instead of pci_stop_bus_device().  Because the
pci_bus has already been destroyed at that point, accesses to it result in
a use-after-free.

One might conclude that driver binding needs to be prevented after
pci_stop_bus_device() has run.  However it seems risky that pci_slot points
to pci_bus without holding a reference.  Solely relying on correct ordering
of driver unbind versus pci_bus destruction is certainly not defensive
programming.

If pci_slot has a need to access data in pci_bus, it ought to acquire a
reference.  Amend pci_create_slot() accordingly.  Dennis reports that the
crash is not reproducible with this change.

Abridged stacktrace:

  pcieport 0000:00:07.0: PME: Signaling with IRQ 156
  pcieport 0000:00:07.0: pciehp: Slot #12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+
  pci_bus 0000:20: dev 00, created physical slot 12
  pcieport 0000:00:07.0: pciehp: Slot(12): Card not present
  ...
  pcieport 0000:21:02.0: pciehp: pcie_disable_notification: SLOTCTRL d8 write cmd 0
  Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI
  CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp Not tainted 6.11.0-devel+ #1
  RIP: 0010:dev_driver_string+0x12/0x40
  pci_destroy_slot
  pciehp_remove
  pcie_port_remove_service
  device_release_driver_internal
  bus_remove_device
  device_del
  device_unregister
  remove_iter
  device_for_each_child
  pcie_portdrv_remove
  pci_device_remove
  device_release_driver_internal
  bus_remove_device
  device_del
  pci_remove_bus_device (recursive invocation)
  pci_remove_bus_device
  pciehp_unconfigure_device
  pciehp_disable_slot
  pciehp_handle_presence_or_link_change
  pciehp_ist</Note>
    </Notes>
    <CVE>CVE-2024-53194</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

KVM: arm64: Get rid of userspace_irqchip_in_use

Improper use of userspace_irqchip_in_use led to syzbot hitting the
following WARN_ON() in kvm_timer_update_irq():

WARNING: CPU: 0 PID: 3281 at arch/arm64/kvm/arch_timer.c:459
kvm_timer_update_irq+0x21c/0x394
Call trace:
  kvm_timer_update_irq+0x21c/0x394 arch/arm64/kvm/arch_timer.c:459
  kvm_timer_vcpu_reset+0x158/0x684 arch/arm64/kvm/arch_timer.c:968
  kvm_reset_vcpu+0x3b4/0x560 arch/arm64/kvm/reset.c:264
  kvm_vcpu_set_target arch/arm64/kvm/arm.c:1553 [inline]
  kvm_arch_vcpu_ioctl_vcpu_init arch/arm64/kvm/arm.c:1573 [inline]
  kvm_arch_vcpu_ioctl+0x112c/0x1b3c arch/arm64/kvm/arm.c:1695
  kvm_vcpu_ioctl+0x4ec/0xf74 virt/kvm/kvm_main.c:4658
  vfs_ioctl fs/ioctl.c:51 [inline]
  __do_sys_ioctl fs/ioctl.c:907 [inline]
  __se_sys_ioctl fs/ioctl.c:893 [inline]
  __arm64_sys_ioctl+0x108/0x184 fs/ioctl.c:893
  __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
  invoke_syscall+0x78/0x1b8 arch/arm64/kernel/syscall.c:49
  el0_svc_common+0xe8/0x1b0 arch/arm64/kernel/syscall.c:132
  do_el0_svc+0x40/0x50 arch/arm64/kernel/syscall.c:151
  el0_svc+0x54/0x14c arch/arm64/kernel/entry-common.c:712
  el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730
  el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598

The following sequence led to the scenario:
 - Userspace creates a VM and a vCPU.
 - The vCPU is initialized with KVM_ARM_VCPU_PMU_V3 during
   KVM_ARM_VCPU_INIT.
 - Without any other setup, such as vGIC or vPMU, userspace issues
   KVM_RUN on the vCPU. Since the vPMU is requested, but not setup,
   kvm_arm_pmu_v3_enable() fails in kvm_arch_vcpu_run_pid_change().
   As a result, KVM_RUN returns after enabling the timer, but before
   incrementing 'userspace_irqchip_in_use':
   kvm_arch_vcpu_run_pid_change()
       ret = kvm_arm_pmu_v3_enable()
           if (!vcpu-&gt;arch.pmu.created)
               return -EINVAL;
       if (ret)
           return ret;
       [...]
       if (!irqchip_in_kernel(kvm))
           static_branch_inc(&amp;userspace_irqchip_in_use);
 - Userspace ignores the error and issues KVM_ARM_VCPU_INIT again.
   Since the timer is already enabled, control moves through the
   following flow, ultimately hitting the WARN_ON():
   kvm_timer_vcpu_reset()
       if (timer-&gt;enabled)
          kvm_timer_update_irq()
              if (!userspace_irqchip())
                  ret = kvm_vgic_inject_irq()
                      ret = vgic_lazy_init()
                          if (unlikely(!vgic_initialized(kvm)))
                              if (kvm-&gt;arch.vgic.vgic_model !=
                                  KVM_DEV_TYPE_ARM_VGIC_V2)
                                      return -EBUSY;
                  WARN_ON(ret);

Theoretically, since userspace_irqchip_in_use's functionality can be
simply replaced by '!irqchip_in_kernel()', get rid of the static key
to avoid the mismanagement, which also helps with the syzbot issue.</Note>
    </Notes>
    <CVE>CVE-2024-53195</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

KVM: arm64: Don't retire aborted MMIO instruction

Returning an abort to the guest for an unsupported MMIO access is a
documented feature of the KVM UAPI. Nevertheless, it's clear that this
plumbing has seen limited testing, since userspace can trivially cause a
WARN in the MMIO return:

  WARNING: CPU: 0 PID: 30558 at arch/arm64/include/asm/kvm_emulate.h:536 kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536
  Call trace:
   kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536
   kvm_arch_vcpu_ioctl_run+0x98/0x15b4 arch/arm64/kvm/arm.c:1133
   kvm_vcpu_ioctl+0x75c/0xa78 virt/kvm/kvm_main.c:4487
   __do_sys_ioctl fs/ioctl.c:51 [inline]
   __se_sys_ioctl fs/ioctl.c:893 [inline]
   __arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:893
   __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
   invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49
   el0_svc_common+0x1e0/0x23c arch/arm64/kernel/syscall.c:132
   do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151
   el0_svc+0x38/0x68 arch/arm64/kernel/entry-common.c:712
   el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730
   el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598

The splat is complaining that KVM is advancing PC while an exception is
pending, i.e. that KVM is retiring the MMIO instruction despite a
pending synchronous external abort. Womp womp.

Fix the glaring UAPI bug by skipping over all the MMIO emulation in
case there is a pending synchronous exception. Note that while userspace
is capable of pending an asynchronous exception (SError, IRQ, or FIQ),
it is still safe to retire the MMIO instruction in this case as (1) they
are by definition asynchronous, and (2) KVM relies on hardware support
for pending/delivering these exceptions instead of the software state
machine for advancing PC.</Note>
    </Notes>
    <CVE>CVE-2024-53196</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices

A bogus device can provide a bNumConfigurations value that exceeds the
initial value used in usb_get_configuration for allocating dev-&gt;config.

This can lead to out-of-bounds accesses later, e.g. in
usb_destroy_configuration.</Note>
    </Notes>
    <CVE>CVE-2024-53197</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xen: Fix the issue of resource not being properly released in xenbus_dev_probe()

This patch fixes an issue in the function xenbus_dev_probe(). In the
xenbus_dev_probe() function, within the if (err) branch at line 313, the
program incorrectly returns err directly without releasing the resources
allocated by err = drv-&gt;probe(dev, id). As the return value is non-zero,
the upper layers assume the processing logic has failed. However, the probe
operation was performed earlier without a corresponding remove operation.
Since the probe actually allocates resources, failing to perform the remove
operation could lead to problems.

To fix this issue, we followed the resource release logic of the
xenbus_dev_remove() function by adding a new block fail_remove before the
fail_put block. After entering the branch if (err) at line 313, the
function will use a goto statement to jump to the fail_remove block,
ensuring that the previously acquired resources are correctly released,
thus preventing the reference count leak.

This bug was identified by an experimental static analysis tool developed
by our team. The tool specializes in analyzing reference count operations
and detecting potential issues where resources are not properly managed.
In this case, the tool flagged the missing release operation as a
potential problem, which led to the development of this patch.</Note>
    </Notes>
    <CVE>CVE-2024-53198</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: typec: fix potential array underflow in ucsi_ccg_sync_control()

The "command" variable can be controlled by the user via debugfs.  The
worry is that if con_index is zero then "&amp;uc-&gt;ucsi-&gt;connector[con_index
- 1]" would be an array underflow.</Note>
    </Notes>
    <CVE>CVE-2024-53203</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg()

ib_map_mr_sg() allows ULPs to specify NULL as the sg_offset argument.
The driver needs to check whether it is a NULL pointer before
dereferencing it.</Note>
    </Notes>
    <CVE>CVE-2024-53226</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: bfa: Fix use-after-free in bfad_im_module_exit()

BUG: KASAN: slab-use-after-free in __lock_acquire+0x2aca/0x3a20
Read of size 8 at addr ffff8881082d80c8 by task modprobe/25303

Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x95/0xe0
 print_report+0xcb/0x620
 kasan_report+0xbd/0xf0
 __lock_acquire+0x2aca/0x3a20
 lock_acquire+0x19b/0x520
 _raw_spin_lock+0x2b/0x40
 attribute_container_unregister+0x30/0x160
 fc_release_transport+0x19/0x90 [scsi_transport_fc]
 bfad_im_module_exit+0x23/0x60 [bfa]
 bfad_init+0xdb/0xff0 [bfa]
 do_one_initcall+0xdc/0x550
 do_init_module+0x22d/0x6b0
 load_module+0x4e96/0x5ff0
 init_module_from_file+0xcd/0x130
 idempotent_init_module+0x330/0x620
 __x64_sys_finit_module+0xb3/0x110
 do_syscall_64+0xc1/0x1d0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
 &lt;/TASK&gt;

Allocated by task 25303:
 kasan_save_stack+0x24/0x50
 kasan_save_track+0x14/0x30
 __kasan_kmalloc+0x7f/0x90
 fc_attach_transport+0x4f/0x4740 [scsi_transport_fc]
 bfad_im_module_init+0x17/0x80 [bfa]
 bfad_init+0x23/0xff0 [bfa]
 do_one_initcall+0xdc/0x550
 do_init_module+0x22d/0x6b0
 load_module+0x4e96/0x5ff0
 init_module_from_file+0xcd/0x130
 idempotent_init_module+0x330/0x620
 __x64_sys_finit_module+0xb3/0x110
 do_syscall_64+0xc1/0x1d0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 25303:
 kasan_save_stack+0x24/0x50
 kasan_save_track+0x14/0x30
 kasan_save_free_info+0x3b/0x60
 __kasan_slab_free+0x38/0x50
 kfree+0x212/0x480
 bfad_im_module_init+0x7e/0x80 [bfa]
 bfad_init+0x23/0xff0 [bfa]
 do_one_initcall+0xdc/0x550
 do_init_module+0x22d/0x6b0
 load_module+0x4e96/0x5ff0
 init_module_from_file+0xcd/0x130
 idempotent_init_module+0x330/0x620
 __x64_sys_finit_module+0xb3/0x110
 do_syscall_64+0xc1/0x1d0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Above issue happens as follows:

bfad_init
  error = bfad_im_module_init()
    fc_release_transport(bfad_im_scsi_transport_template);
  if (error)
    goto ext;

ext:
  bfad_im_module_exit();
    fc_release_transport(bfad_im_scsi_transport_template);
    --&gt; Trigger double release

Don't call bfad_im_module_exit() if bfad_im_module_init() failed.</Note>
    </Notes>
    <CVE>CVE-2024-53227</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cpufreq: CPPC: Fix possible null-ptr-deref for cppc_get_cpu_cost()

cpufreq_cpu_get_raw() may return NULL if the cpu is not in
policy-&gt;cpus cpu mask and it will cause null pointer dereference,
so check NULL for cppc_get_cpu_cost().</Note>
    </Notes>
    <CVE>CVE-2024-53230</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cpufreq: CPPC: Fix possible null-ptr-deref for cpufreq_cpu_get_raw()

cpufreq_cpu_get_raw() may return NULL if the cpu is not in
policy-&gt;cpus cpu mask and it will cause null pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2024-53231</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iommu/s390: Implement blocking domain

This fixes a crash when surprise hot-unplugging a PCI device. This crash
happens because during hot-unplug __iommu_group_set_domain_nofail()
attaching the default domain fails when the platform no longer
recognizes the device as it has already been removed and we end up with
a NULL domain pointer and UAF. This is exactly the case referred to in
the second comment in __iommu_device_set_domain() and just as stated
there if we can instead attach the blocking domain the UAF is prevented
as this can handle the already removed device. Implement the blocking
domain to use this handling.  With this change, the crash is fixed but
we still hit a warning attempting to change DMA ownership on a blocked
device.</Note>
    </Notes>
    <CVE>CVE-2024-53232</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

unicode: Fix utf8_load() error path

utf8_load() requests the symbol "utf8_data_table" and then checks if the
requested UTF-8 version is supported. If it's unsupported, it tries to
put the data table using symbol_put(). If an unsupported version is
requested, symbol_put() fails like this:

 kernel BUG at kernel/module/main.c:786!
 RIP: 0010:__symbol_put+0x93/0xb0
 Call Trace:
  &lt;TASK&gt;
  ? __die_body.cold+0x19/0x27
  ? die+0x2e/0x50
  ? do_trap+0xca/0x110
  ? do_error_trap+0x65/0x80
  ? __symbol_put+0x93/0xb0
  ? exc_invalid_op+0x51/0x70
  ? __symbol_put+0x93/0xb0
  ? asm_exc_invalid_op+0x1a/0x20
  ? __pfx_cmp_name+0x10/0x10
  ? __symbol_put+0x93/0xb0
  ? __symbol_put+0x62/0xb0
  utf8_load+0xf8/0x150

That happens because symbol_put() expects the unique string that
identify the symbol, instead of a pointer to the loaded symbol. Fix that
by using such string.</Note>
    </Notes>
    <CVE>CVE-2024-53233</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xsk: Free skb when TX metadata options are invalid

When a new skb is allocated for transmitting an xsk descriptor, i.e., for
every non-multibuf descriptor or the first frag of a multibuf descriptor,
but the descriptor is later found to have invalid options set for the TX
metadata, the new skb is never freed. This can leak skbs until the send
buffer is full which makes sending more packets impossible.

Fix this by freeing the skb in the error path if we are currently dealing
with the first frag, i.e., an skb allocated in this iteration of
xsk_build_skb.</Note>
    </Notes>
    <CVE>CVE-2024-53236</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: 6fire: Release resources at card release

The current 6fire code tries to release the resources right after the
call of usb6fire_chip_abort().  But at this moment, the card object
might be still in use (as we're calling snd_card_free_when_closed()).

For avoid potential UAFs, move the release of resources to the card's
private_free instead of the manual call of usb6fire_chip_destroy() at
the USB disconnect callback.</Note>
    </Notes>
    <CVE>CVE-2024-53239</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ceph: give up on paths longer than PATH_MAX

If the full path to be built by ceph_mdsc_build_path() happens to be
longer than PATH_MAX, then this function will enter an endless (retry)
loop, effectively blocking the whole task.  Most of the machine
becomes unusable, making this a very simple and effective DoS
vulnerability.

I cannot imagine why this retry was ever implemented, but it seems
rather useless and harmful to me.  Let's remove it and fail with
ENAMETOOLONG instead.</Note>
    </Notes>
    <CVE>CVE-2024-53685</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nilfs2: prevent use of deleted inode

syzbot reported a WARNING in nilfs_rmdir. [1]

Because the inode bitmap is corrupted, an inode with an inode number that
should exist as a ".nilfs" file was reassigned by nilfs_mkdir for "file0",
causing an inode duplication during execution.  And this causes an
underflow of i_nlink in rmdir operations.

The inode is used twice by the same task to unmount and remove directories
".nilfs" and "file0", it trigger warning in nilfs_rmdir.

Avoid to this issue, check i_nlink in nilfs_iget(), if it is 0, it means
that this inode has been deleted, and iput is executed to reclaim it.

[1]
WARNING: CPU: 1 PID: 5824 at fs/inode.c:407 drop_nlink+0xc4/0x110 fs/inode.c:407
...
Call Trace:
 &lt;TASK&gt;
 nilfs_rmdir+0x1b0/0x250 fs/nilfs2/namei.c:342
 vfs_rmdir+0x3a3/0x510 fs/namei.c:4394
 do_rmdir+0x3b5/0x580 fs/namei.c:4453
 __do_sys_rmdir fs/namei.c:4472 [inline]
 __se_sys_rmdir fs/namei.c:4470 [inline]
 __x64_sys_rmdir+0x47/0x50 fs/namei.c:4470
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f</Note>
    </Notes>
    <CVE>CVE-2024-53690</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: renesas: rswitch: avoid use-after-put for a device tree node

The device tree node saved in the rswitch_device structure is used at
several driver locations. So passing this node to of_node_put() after
the first use is wrong.

Move of_node_put() for this node to exit paths.</Note>
    </Notes>
    <CVE>CVE-2024-55639</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: Play nice with protected guests in complete_hypercall_exit()

Use is_64_bit_hypercall() instead of is_64_bit_mode() to detect a 64-bit
hypercall when completing said hypercall.  For guests with protected state,
e.g. SEV-ES and SEV-SNP, KVM must assume the hypercall was made in 64-bit
mode as the vCPU state needed to detect 64-bit mode is unavailable.

Hacking the sev_smoke_test selftest to generate a KVM_HC_MAP_GPA_RANGE
hypercall via VMGEXIT trips the WARN:

  ------------[ cut here ]------------
  WARNING: CPU: 273 PID: 326626 at arch/x86/kvm/x86.h:180 complete_hypercall_exit+0x44/0xe0 [kvm]
  Modules linked in: kvm_amd kvm ... [last unloaded: kvm]
  CPU: 273 UID: 0 PID: 326626 Comm: sev_smoke_test Not tainted 6.12.0-smp--392e932fa0f3-feat #470
  Hardware name: Google Astoria/astoria, BIOS 0.20240617.0-0 06/17/2024
  RIP: 0010:complete_hypercall_exit+0x44/0xe0 [kvm]
  Call Trace:
   &lt;TASK&gt;
   kvm_arch_vcpu_ioctl_run+0x2400/0x2720 [kvm]
   kvm_vcpu_ioctl+0x54f/0x630 [kvm]
   __se_sys_ioctl+0x6b/0xc0
   do_syscall_64+0x83/0x160
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
   &lt;/TASK&gt;
  ---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2024-55881</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Drivers: hv: util: Avoid accessing a ringbuffer not initialized yet

If the KVP (or VSS) daemon starts before the VMBus channel's ringbuffer is
fully initialized, we can hit the panic below:

hv_utils: Registering HyperV Utility Driver
hv_vmbus: registering driver hv_utils
...
BUG: kernel NULL pointer dereference, address: 0000000000000000
CPU: 44 UID: 0 PID: 2552 Comm: hv_kvp_daemon Tainted: G E 6.11.0-rc3+ #1
RIP: 0010:hv_pkt_iter_first+0x12/0xd0
Call Trace:
...
 vmbus_recvpacket
 hv_kvp_onchannelcallback
 vmbus_on_event
 tasklet_action_common
 tasklet_action
 handle_softirqs
 irq_exit_rcu
 sysvec_hyperv_stimer0
 &lt;/IRQ&gt;
 &lt;TASK&gt;
 asm_sysvec_hyperv_stimer0
...
 kvp_register_done
 hvt_op_read
 vfs_read
 ksys_read
 __x64_sys_read

This can happen because the KVP/VSS channel callback can be invoked
even before the channel is fully opened:
1) as soon as hv_kvp_init() -&gt; hvutil_transport_init() creates
/dev/vmbus/hv_kvp, the kvp daemon can open the device file immediately and
register itself to the driver by writing a message KVP_OP_REGISTER1 to the
file (which is handled by kvp_on_msg() -&gt;kvp_handle_handshake()) and
reading the file for the driver's response, which is handled by
hvt_op_read(), which calls hvt-&gt;on_read(), i.e. kvp_register_done().

2) the problem with kvp_register_done() is that it can cause the
channel callback to be called even before the channel is fully opened,
and when the channel callback is starting to run, util_probe()-&gt;
vmbus_open() may have not initialized the ringbuffer yet, so the
callback can hit the panic of NULL pointer dereference.

To reproduce the panic consistently, we can add a "ssleep(10)" for KVP in
__vmbus_open(), just before the first hv_ringbuffer_init(), and then we
unload and reload the driver hv_utils, and run the daemon manually within
the 10 seconds.

Fix the panic by reordering the steps in util_probe() so the char dev
entry used by the KVP or VSS daemon is not created until after
vmbus_open() has completed. This reordering prevents the race condition
from happening.</Note>
    </Notes>
    <CVE>CVE-2024-55916</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">libxml2 before 2.12.10 and 2.13.x before 2.13.6 has a use-after-free in xmlSchemaIDCFillNodeTables and xmlSchemaBubbleIDCNodeTables in xmlschemas.c. To exploit this, a crafted XML document must be validated against an XML schema with certain identity constraints, or a crafted XML schema must be used.</Note>
    </Notes>
    <CVE>CVE-2024-56171</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:libxml2-2-2.10.3-150500.5.23.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/modes: Avoid divide by zero harder in drm_mode_vrefresh()

drm_mode_vrefresh() is trying to avoid divide by zero
by checking whether htotal or vtotal are zero. But we may
still end up with a div-by-zero of vtotal*htotal*...</Note>
    </Notes>
    <CVE>CVE-2024-56369</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: tun: fix tun_napi_alloc_frags()

syzbot reported the following crash [1]

Issue came with the blamed commit. Instead of going through
all the iov components, we keep using the first one
and end up with a malformed skb.

[1]

kernel BUG at net/core/skbuff.c:2849 !
Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 0 UID: 0 PID: 6230 Comm: syz-executor132 Not tainted 6.13.0-rc1-syzkaller-00407-g96b6fcc0ee41 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024
 RIP: 0010:__pskb_pull_tail+0x1568/0x1570 net/core/skbuff.c:2848
Code: 38 c1 0f 8c 32 f1 ff ff 4c 89 f7 e8 92 96 74 f8 e9 25 f1 ff ff e8 e8 ae 09 f8 48 8b 5c 24 08 e9 eb fb ff ff e8 d9 ae 09 f8 90 &lt;0f&gt; 0b 66 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90
RSP: 0018:ffffc90004cbef30 EFLAGS: 00010293
RAX: ffffffff8995c347 RBX: 00000000fffffff2 RCX: ffff88802cf45a00
RDX: 0000000000000000 RSI: 00000000fffffff2 RDI: 0000000000000000
RBP: ffff88807df0c06a R08: ffffffff8995b084 R09: 1ffff1100fbe185c
R10: dffffc0000000000 R11: ffffed100fbe185d R12: ffff888076e85d50
R13: ffff888076e85c80 R14: ffff888076e85cf4 R15: ffff888076e85c80
FS:  00007f0dca6ea6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0dca6ead58 CR3: 00000000119da000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
  skb_cow_data+0x2da/0xcb0 net/core/skbuff.c:5284
  tipc_aead_decrypt net/tipc/crypto.c:894 [inline]
  tipc_crypto_rcv+0x402/0x24e0 net/tipc/crypto.c:1844
  tipc_rcv+0x57e/0x12a0 net/tipc/node.c:2109
  tipc_l2_rcv_msg+0x2bd/0x450 net/tipc/bearer.c:668
  __netif_receive_skb_list_ptype net/core/dev.c:5720 [inline]
  __netif_receive_skb_list_core+0x8b7/0x980 net/core/dev.c:5762
  __netif_receive_skb_list net/core/dev.c:5814 [inline]
  netif_receive_skb_list_internal+0xa51/0xe30 net/core/dev.c:5905
  gro_normal_list include/net/gro.h:515 [inline]
  napi_complete_done+0x2b5/0x870 net/core/dev.c:6256
  napi_complete include/linux/netdevice.h:567 [inline]
  tun_get_user+0x2ea0/0x4890 drivers/net/tun.c:1982
  tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2057
 do_iter_readv_writev+0x600/0x880
  vfs_writev+0x376/0xba0 fs/read_write.c:1050
  do_writev+0x1b6/0x360 fs/read_write.c:1096
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f</Note>
    </Notes>
    <CVE>CVE-2024-56372</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: caiaq: Use snd_card_free_when_closed() at disconnection

The USB disconnect callback is supposed to be short and not too-long
waiting.  OTOH, the current code uses snd_card_free() at
disconnection, but this waits for the close of all used fds, hence it
can take long.  It eventually blocks the upper layer USB ioctls, which
may trigger a soft lockup.

An easy workaround is to replace snd_card_free() with
snd_card_free_when_closed().  This variant returns immediately while
the release of resources is done asynchronously by the card device
release at the last close.

This patch also splits the code to the disconnect and the free phases;
the former is called immediately at the USB disconnect callback while
the latter is called from the card destructor.</Note>
    </Notes>
    <CVE>CVE-2024-56531</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: us122l: Use snd_card_free_when_closed() at disconnection

The USB disconnect callback is supposed to be short and not too-long
waiting.  OTOH, the current code uses snd_card_free() at
disconnection, but this waits for the close of all used fds, hence it
can take long.  It eventually blocks the upper layer USB ioctls, which
may trigger a soft lockup.

An easy workaround is to replace snd_card_free() with
snd_card_free_when_closed().  This variant returns immediately while
the release of resources is done asynchronously by the card device
release at the last close.

The loop of us122l-&gt;mmap_count check is dropped as well.  The check is
useless for the asynchronous operation with *_when_closed().</Note>
    </Notes>
    <CVE>CVE-2024-56532</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: usx2y: Use snd_card_free_when_closed() at disconnection

The USB disconnect callback is supposed to be short and not too-long
waiting.  OTOH, the current code uses snd_card_free() at
disconnection, but this waits for the close of all used fds, hence it
can take long.  It eventually blocks the upper layer USB ioctls, which
may trigger a soft lockup.

An easy workaround is to replace snd_card_free() with
snd_card_free_when_closed().  This variant returns immediately while
the release of resources is done asynchronously by the card device
release at the last close.</Note>
    </Notes>
    <CVE>CVE-2024-56533</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm: zynqmp_kms: Unplug DRM device before removal

Prevent userspace accesses to the DRM device from causing
use-after-frees by unplugging the device before we remove it. This
causes any further userspace accesses to result in an error without
further calls into this driver's internals.</Note>
    </Notes>
    <CVE>CVE-2024-56538</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()

Replace one-element array with a flexible-array member in `struct
mwifiex_ie_types_wildcard_ssid_params` to fix the following warning
on a MT8173 Chromebook (mt8173-elm-hana):

[  356.775250] ------------[ cut here ]------------
[  356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcard_ssid_tlv-&gt;ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1)
[  356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]

The "(size 6)" above is exactly the length of the SSID of the network
this device was connected to. The source of the warning looks like:

    ssid_len = user_scan_in-&gt;ssid_list[i].ssid_len;
    [...]
    memcpy(wildcard_ssid_tlv-&gt;ssid,
           user_scan_in-&gt;ssid_list[i].ssid, ssid_len);

There is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this
struct, but it already didn't account for the size of the one-element
array, so it doesn't need to be changed.</Note>
    </Notes>
    <CVE>CVE-2024-56539</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: Skip Rx TID cleanup for self peer

During peer create, dp setup for the peer is done where Rx TID is
updated for all the TIDs. Peer object for self peer will not go through
dp setup.

When core halts, dp cleanup is done for all the peers. While cleanup,
rx_tid::ab is accessed which causes below stack trace for self peer.

WARNING: CPU: 6 PID: 12297 at drivers/net/wireless/ath/ath12k/dp_rx.c:851
Call Trace:
__warn+0x7b/0x1a0
ath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k]
report_bug+0x10b/0x200
handle_bug+0x3f/0x70
exc_invalid_op+0x13/0x60
asm_exc_invalid_op+0x16/0x20
ath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k]
ath12k_dp_rx_frags_cleanup+0xca/0xe0 [ath12k]
ath12k_dp_rx_peer_tid_cleanup+0x39/0xa0 [ath12k]
ath12k_mac_peer_cleanup_all+0x61/0x100 [ath12k]
ath12k_core_halt+0x3b/0x100 [ath12k]
ath12k_core_reset+0x494/0x4c0 [ath12k]

sta object in peer will be updated when remote peer is created. Hence
use peer::sta to detect the self peer and skip the cleanup.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3</Note>
    </Notes>
    <CVE>CVE-2024-56543</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drivers: soc: xilinx: add the missing kfree in xlnx_add_cb_for_suspend()

If we fail to allocate memory for cb_data by kmalloc, the memory
allocation for eve_data is never freed, add the missing kfree()
in the error handling path.</Note>
    </Notes>
    <CVE>CVE-2024-56546</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hfsplus: don't query the device logical block size multiple times

Devices block sizes may change. One of these cases is a loop device by
using ioctl LOOP_SET_BLOCK_SIZE.

While this may cause other issues like IO being rejected, in the case of
hfsplus, it will allocate a block by using that size and potentially write
out-of-bounds when hfsplus_read_wrapper calls hfsplus_submit_bio and the
latter function reads a different io_size.

Using a new min_io_size initally set to sb_min_blocksize works for the
purposes of the original fix, since it will be set to the max between
HFSPLUS_SECTOR_SIZE and the first seen logical block size. We still use the
max between HFSPLUS_SECTOR_SIZE and min_io_size in case the latter is not
initialized.

Tested by mounting an hfsplus filesystem with loop block sizes 512, 1024
and 4096.

The produced KASAN report before the fix looks like this:

[  419.944641] ==================================================================
[  419.945655] BUG: KASAN: slab-use-after-free in hfsplus_read_wrapper+0x659/0xa0a
[  419.946703] Read of size 2 at addr ffff88800721fc00 by task repro/10678
[  419.947612]
[  419.947846] CPU: 0 UID: 0 PID: 10678 Comm: repro Not tainted 6.12.0-rc5-00008-gdf56e0f2f3ca #84
[  419.949007] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
[  419.950035] Call Trace:
[  419.950384]  &lt;TASK&gt;
[  419.950676]  dump_stack_lvl+0x57/0x78
[  419.951212]  ? hfsplus_read_wrapper+0x659/0xa0a
[  419.951830]  print_report+0x14c/0x49e
[  419.952361]  ? __virt_addr_valid+0x267/0x278
[  419.952979]  ? kmem_cache_debug_flags+0xc/0x1d
[  419.953561]  ? hfsplus_read_wrapper+0x659/0xa0a
[  419.954231]  kasan_report+0x89/0xb0
[  419.954748]  ? hfsplus_read_wrapper+0x659/0xa0a
[  419.955367]  hfsplus_read_wrapper+0x659/0xa0a
[  419.955948]  ? __pfx_hfsplus_read_wrapper+0x10/0x10
[  419.956618]  ? do_raw_spin_unlock+0x59/0x1a9
[  419.957214]  ? _raw_spin_unlock+0x1a/0x2e
[  419.957772]  hfsplus_fill_super+0x348/0x1590
[  419.958355]  ? hlock_class+0x4c/0x109
[  419.958867]  ? __pfx_hfsplus_fill_super+0x10/0x10
[  419.959499]  ? __pfx_string+0x10/0x10
[  419.960006]  ? lock_acquire+0x3e2/0x454
[  419.960532]  ? bdev_name.constprop.0+0xce/0x243
[  419.961129]  ? __pfx_bdev_name.constprop.0+0x10/0x10
[  419.961799]  ? pointer+0x3f0/0x62f
[  419.962277]  ? __pfx_pointer+0x10/0x10
[  419.962761]  ? vsnprintf+0x6c4/0xfba
[  419.963178]  ? __pfx_vsnprintf+0x10/0x10
[  419.963621]  ? setup_bdev_super+0x376/0x3b3
[  419.964029]  ? snprintf+0x9d/0xd2
[  419.964344]  ? __pfx_snprintf+0x10/0x10
[  419.964675]  ? lock_acquired+0x45c/0x5e9
[  419.965016]  ? set_blocksize+0x139/0x1c1
[  419.965381]  ? sb_set_blocksize+0x6d/0xae
[  419.965742]  ? __pfx_hfsplus_fill_super+0x10/0x10
[  419.966179]  mount_bdev+0x12f/0x1bf
[  419.966512]  ? __pfx_mount_bdev+0x10/0x10
[  419.966886]  ? vfs_parse_fs_string+0xce/0x111
[  419.967293]  ? __pfx_vfs_parse_fs_string+0x10/0x10
[  419.967702]  ? __pfx_hfsplus_mount+0x10/0x10
[  419.968073]  legacy_get_tree+0x104/0x178
[  419.968414]  vfs_get_tree+0x86/0x296
[  419.968751]  path_mount+0xba3/0xd0b
[  419.969157]  ? __pfx_path_mount+0x10/0x10
[  419.969594]  ? kmem_cache_free+0x1e2/0x260
[  419.970311]  do_mount+0x99/0xe0
[  419.970630]  ? __pfx_do_mount+0x10/0x10
[  419.971008]  __do_sys_mount+0x199/0x1c9
[  419.971397]  do_syscall_64+0xd0/0x135
[  419.971761]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[  419.972233] RIP: 0033:0x7c3cb812972e
[  419.972564] Code: 48 8b 0d f5 46 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d c2 46 0d 00 f7 d8 64 89 01 48
[  419.974371] RSP: 002b:00007ffe30632548 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5
[  419.975048] RAX: ffffffffffffffda RBX: 00007ffe306328d8 RCX: 00007c3cb812972e
[  419.975701] RDX: 0000000020000000 RSI: 0000000020000c80 RDI:
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-56548</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iio: adc: ad7923: Fix buffer overflow for tx_buf and ring_xfer

The AD7923 was updated to support devices with 8 channels, but the size
of tx_buf and ring_xfer was not increased accordingly, leading to a
potential buffer overflow in ad7923_update_scan_mode().</Note>
    </Notes>
    <CVE>CVE-2024-56557</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfsd: make sure exp active before svc_export_show

The function `e_show` was called with protection from RCU. This only
ensures that `exp` will not be freed. Therefore, the reference count for
`exp` can drop to zero, which will trigger a refcount use-after-free
warning when `exp_get` is called. To resolve this issue, use
`cache_get_rcu` to ensure that `exp` remains active.

------------[ cut here ]------------
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 3 PID: 819 at lib/refcount.c:25
refcount_warn_saturate+0xb1/0x120
CPU: 3 UID: 0 PID: 819 Comm: cat Not tainted 6.12.0-rc3+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.1-2.fc37 04/01/2014
RIP: 0010:refcount_warn_saturate+0xb1/0x120
...
Call Trace:
 &lt;TASK&gt;
 e_show+0x20b/0x230 [nfsd]
 seq_read_iter+0x589/0x770
 seq_read+0x1e5/0x270
 vfs_read+0x125/0x530
 ksys_read+0xc1/0x160
 do_syscall_64+0x5f/0x170
 entry_SYSCALL_64_after_hwframe+0x76/0x7e</Note>
    </Notes>
    <CVE>CVE-2024-56558</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iommu/arm-smmu: Defer probe of clients after smmu device bound

Null pointer dereference occurs due to a race between smmu
driver probe and client driver probe, when of_dma_configure()
for client is called after the iommu_device_register() for smmu driver
probe has executed but before the driver_bound() for smmu driver
has been called.

Following is how the race occurs:

T1:Smmu device probe		T2: Client device probe

really_probe()
arm_smmu_device_probe()
iommu_device_register()
					really_probe()
					platform_dma_configure()
					of_dma_configure()
					of_dma_configure_id()
					of_iommu_configure()
					iommu_probe_device()
					iommu_init_device()
					arm_smmu_probe_device()
					arm_smmu_get_by_fwnode()
						driver_find_device_by_fwnode()
						driver_find_device()
						next_device()
						klist_next()
						    /* null ptr
						       assigned to smmu */
					/* null ptr dereference
					   while smmu-&gt;streamid_mask */
driver_bound()
	klist_add_tail()

When this null smmu pointer is dereferenced later in
arm_smmu_probe_device, the device crashes.

Fix this by deferring the probe of the client device
until the smmu device has bound to the arm smmu driver.

[will: Add comment]</Note>
    </Notes>
    <CVE>CVE-2024-56568</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ftrace: Fix regression with module command in stack_trace_filter

When executing the following command:

    # echo "write*:mod:ext3" &gt; /sys/kernel/tracing/stack_trace_filter

The current mod command causes a null pointer dereference. While commit
0f17976568b3f ("ftrace: Fix regression with module command in stack_trace_filter")
has addressed part of the issue, it left a corner case unhandled, which still
results in a kernel crash.</Note>
    </Notes>
    <CVE>CVE-2024-56569</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ovl: Filter invalid inodes with missing lookup function

Add a check to the ovl_dentry_weird() function to prevent the
processing of directory inodes that lack the lookup function.
This is important because such inodes can cause errors in overlayfs
when passed to the lowerstack.</Note>
    </Notes>
    <CVE>CVE-2024-56570</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2024-56571</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: platform: allegro-dvt: Fix possible memory leak in allocate_buffers_internal()

The buffer in the loop should be released under the exception path,
otherwise there may be a memory leak here.

To mitigate this, free the buffer when allegro_alloc_buffer fails.</Note>
    </Notes>
    <CVE>CVE-2024-56572</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

efi/libstub: Free correct pointer on failure

cmdline_ptr is an out parameter, which is not allocated by the function
itself, and likely points into the caller's stack.

cmdline refers to the pool allocation that should be freed when cleaning
up after a failure, so pass this instead to free_pool().</Note>
    </Notes>
    <CVE>CVE-2024-56573</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: ts2020: fix null-ptr-deref in ts2020_probe()

KASAN reported a null-ptr-deref issue when executing the following
command:

  # echo ts2020 0x20 &gt; /sys/bus/i2c/devices/i2c-0/new_device
    KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
    CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)
    RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020]
    RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202
    RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809
    RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010
    RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6
    R10: 0000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790
    R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001
    FS:  00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 00000000000006f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     &lt;TASK&gt;
     ts2020_probe+0xad/0xe10 [ts2020]
     i2c_device_probe+0x421/0xb40
     really_probe+0x266/0x850
    ...

The cause of the problem is that when using sysfs to dynamically register
an i2c device, there is no platform data, but the probe process of ts2020
needs to use platform data, resulting in a null pointer being accessed.

Solve this problem by adding checks to platform data.</Note>
    </Notes>
    <CVE>CVE-2024-56574</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: imx-jpeg: Ensure power suppliers be suspended before detach them

The power suppliers are always requested to suspend asynchronously,
dev_pm_domain_detach() requires the caller to ensure proper
synchronization of this function with power management callbacks.
otherwise the detach may led to kernel panic, like below:

[ 1457.107934] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000040
[ 1457.116777] Mem abort info:
[ 1457.119589]   ESR = 0x0000000096000004
[ 1457.123358]   EC = 0x25: DABT (current EL), IL = 32 bits
[ 1457.128692]   SET = 0, FnV = 0
[ 1457.131764]   EA = 0, S1PTW = 0
[ 1457.134920]   FSC = 0x04: level 0 translation fault
[ 1457.139812] Data abort info:
[ 1457.142707]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 1457.148196]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 1457.153256]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 1457.158563] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001138b6000
[ 1457.165000] [0000000000000040] pgd=0000000000000000, p4d=0000000000000000
[ 1457.171792] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
[ 1457.178045] Modules linked in: v4l2_jpeg wave6_vpu_ctrl(-) [last unloaded: mxc_jpeg_encdec]
[ 1457.186383] CPU: 0 PID: 51938 Comm: kworker/0:3 Not tainted 6.6.36-gd23d64eea511 #66
[ 1457.194112] Hardware name: NXP i.MX95 19X19 board (DT)
[ 1457.199236] Workqueue: pm pm_runtime_work
[ 1457.203247] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1457.210188] pc : genpd_runtime_suspend+0x20/0x290
[ 1457.214886] lr : __rpm_callback+0x48/0x1d8
[ 1457.218968] sp : ffff80008250bc50
[ 1457.222270] x29: ffff80008250bc50 x28: 0000000000000000 x27: 0000000000000000
[ 1457.229394] x26: 0000000000000000 x25: 0000000000000008 x24: 00000000000f4240
[ 1457.236518] x23: 0000000000000000 x22: ffff00008590f0e4 x21: 0000000000000008
[ 1457.243642] x20: ffff80008099c434 x19: ffff00008590f000 x18: ffffffffffffffff
[ 1457.250766] x17: 5300326563697665 x16: 645f676e696c6f6f x15: 63343a6d726f6674
[ 1457.257890] x14: 0000000000000004 x13: 00000000000003a4 x12: 0000000000000002
[ 1457.265014] x11: 0000000000000000 x10: 0000000000000a60 x9 : ffff80008250bbb0
[ 1457.272138] x8 : ffff000092937200 x7 : ffff0003fdf6af80 x6 : 0000000000000000
[ 1457.279262] x5 : 00000000410fd050 x4 : 0000000000200000 x3 : 0000000000000000
[ 1457.286386] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00008590f000
[ 1457.293510] Call trace:
[ 1457.295946]  genpd_runtime_suspend+0x20/0x290
[ 1457.300296]  __rpm_callback+0x48/0x1d8
[ 1457.304038]  rpm_callback+0x6c/0x78
[ 1457.307515]  rpm_suspend+0x10c/0x570
[ 1457.311077]  pm_runtime_work+0xc4/0xc8
[ 1457.314813]  process_one_work+0x138/0x248
[ 1457.318816]  worker_thread+0x320/0x438
[ 1457.322552]  kthread+0x110/0x114
[ 1457.325767]  ret_from_fork+0x10/0x20</Note>
    </Notes>
    <CVE>CVE-2024-56575</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: mtk-jpeg: Fix null-ptr-deref during unload module

The workqueue should be destroyed in mtk_jpeg_core.c since commit
09aea13ecf6f ("media: mtk-jpeg: refactor some variables"), otherwise
the below calltrace can be easily triggered.

[  677.862514] Unable to handle kernel paging request at virtual address dfff800000000023
[  677.863633] KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]
...
[  677.879654] CPU: 6 PID: 1071 Comm: modprobe Tainted: G           O       6.8.12-mtk+gfa1a78e5d24b+ #17
...
[  677.882838] pc : destroy_workqueue+0x3c/0x770
[  677.883413] lr : mtk_jpegdec_destroy_workqueue+0x70/0x88 [mtk_jpeg_dec_hw]
[  677.884314] sp : ffff80008ad974f0
[  677.884744] x29: ffff80008ad974f0 x28: ffff0000d7115580 x27: ffff0000dd691070
[  677.885669] x26: ffff0000dd691408 x25: ffff8000844af3e0 x24: ffff80008ad97690
[  677.886592] x23: ffff0000e051d400 x22: ffff0000dd691010 x21: dfff800000000000
[  677.887515] x20: 0000000000000000 x19: 0000000000000000 x18: ffff800085397ac0
[  677.888438] x17: 0000000000000000 x16: ffff8000801b87c8 x15: 1ffff000115b2e10
[  677.889361] x14: 00000000f1f1f1f1 x13: 0000000000000000 x12: ffff7000115b2e4d
[  677.890285] x11: 1ffff000115b2e4c x10: ffff7000115b2e4c x9 : ffff80000aa43e90
[  677.891208] x8 : 00008fffeea4d1b4 x7 : ffff80008ad97267 x6 : 0000000000000001
[  677.892131] x5 : ffff80008ad97260 x4 : ffff7000115b2e4d x3 : 0000000000000000
[  677.893054] x2 : 0000000000000023 x1 : dfff800000000000 x0 : 0000000000000118
[  677.893977] Call trace:
[  677.894297]  destroy_workqueue+0x3c/0x770
[  677.894826]  mtk_jpegdec_destroy_workqueue+0x70/0x88 [mtk_jpeg_dec_hw]
[  677.895677]  devm_action_release+0x50/0x90
[  677.896211]  release_nodes+0xe8/0x170
[  677.896688]  devres_release_all+0xf8/0x178
[  677.897219]  device_unbind_cleanup+0x24/0x170
[  677.897785]  device_release_driver_internal+0x35c/0x480
[  677.898461]  device_release_driver+0x20/0x38
...
[  677.912665] ---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2024-56577</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: imx-jpeg: Set video drvdata before register video device

The video drvdata should be set before the video device is registered,
otherwise video_drvdata() may return NULL in the open() file ops, and led
to oops.</Note>
    </Notes>
    <CVE>CVE-2024-56578</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: amphion: Set video drvdata before register video device

The video drvdata should be set before the video device is registered,
otherwise video_drvdata() may return NULL in the open() file ops, and led
to oops.</Note>
    </Notes>
    <CVE>CVE-2024-56579</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

io_uring/tctx: work around xa_store() allocation error issue

syzbot triggered the following WARN_ON:

WARNING: CPU: 0 PID: 16 at io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51

which is the

WARN_ON_ONCE(!xa_empty(&amp;tctx-&gt;xa));

sanity check in __io_uring_free() when a io_uring_task is going through
its final put. The syzbot test case includes injecting memory allocation
failures, and it very much looks like xa_store() can fail one of its
memory allocations and end up with -&gt;head being non-NULL even though no
entries exist in the xarray.

Until this issue gets sorted out, work around it by attempting to
iterate entries in our xarray, and WARN_ON_ONCE() if one is found.</Note>
    </Notes>
    <CVE>CVE-2024-56584</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

leds: class: Protect brightness_show() with led_cdev-&gt;led_access mutex

There is NULL pointer issue observed if from Process A where hid device
being added which results in adding a led_cdev addition and later a
another call to access of led_cdev attribute from Process B can result
in NULL pointer issue.

Use mutex led_cdev-&gt;led_access to protect access to led-&gt;cdev and its
attribute inside brightness_show() and max_brightness_show() and also
update the comment for mutex that it should be used to protect the led
class device fields.

	Process A 				Process B

 kthread+0x114
 worker_thread+0x244
 process_scheduled_works+0x248
 uhid_device_add_worker+0x24
 hid_add_device+0x120
 device_add+0x268
 bus_probe_device+0x94
 device_initial_probe+0x14
 __device_attach+0xfc
 bus_for_each_drv+0x10c
 __device_attach_driver+0x14c
 driver_probe_device+0x3c
 __driver_probe_device+0xa0
 really_probe+0x190
 hid_device_probe+0x130
 ps_probe+0x990
 ps_led_register+0x94
 devm_led_classdev_register_ext+0x58
 led_classdev_register_ext+0x1f8
 device_create_with_groups+0x48
 device_create_groups_vargs+0xc8
 device_add+0x244
 kobject_uevent+0x14
 kobject_uevent_env[jt]+0x224
 mutex_unlock[jt]+0xc4
 __mutex_unlock_slowpath+0xd4
 wake_up_q+0x70
 try_to_wake_up[jt]+0x48c
 preempt_schedule_common+0x28
 __schedule+0x628
 __switch_to+0x174
						el0t_64_sync+0x1a8/0x1ac
						el0t_64_sync_handler+0x68/0xbc
						el0_svc+0x38/0x68
						do_el0_svc+0x1c/0x28
						el0_svc_common+0x80/0xe0
						invoke_syscall+0x58/0x114
						__arm64_sys_read+0x1c/0x2c
						ksys_read+0x78/0xe8
						vfs_read+0x1e0/0x2c8
						kernfs_fop_read_iter+0x68/0x1b4
						seq_read_iter+0x158/0x4ec
						kernfs_seq_show+0x44/0x54
						sysfs_kf_seq_show+0xb4/0x130
						dev_attr_show+0x38/0x74
						brightness_show+0x20/0x4c
						dualshock4_led_get_brightness+0xc/0x74

[ 3313.874295][ T4013] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060
[ 3313.874301][ T4013] Mem abort info:
[ 3313.874303][ T4013]   ESR = 0x0000000096000006
[ 3313.874305][ T4013]   EC = 0x25: DABT (current EL), IL = 32 bits
[ 3313.874307][ T4013]   SET = 0, FnV = 0
[ 3313.874309][ T4013]   EA = 0, S1PTW = 0
[ 3313.874311][ T4013]   FSC = 0x06: level 2 translation fault
[ 3313.874313][ T4013] Data abort info:
[ 3313.874314][ T4013]   ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
[ 3313.874316][ T4013]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 3313.874318][ T4013]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 3313.874320][ T4013] user pgtable: 4k pages, 39-bit VAs, pgdp=00000008f2b0a000
..

[ 3313.874332][ T4013] Dumping ftrace buffer:
[ 3313.874334][ T4013]    (ftrace buffer empty)
..
..
[ dd3313.874639][ T4013] CPU: 6 PID: 4013 Comm: InputReader
[ 3313.874648][ T4013] pc : dualshock4_led_get_brightness+0xc/0x74
[ 3313.874653][ T4013] lr : led_update_brightness+0x38/0x60
[ 3313.874656][ T4013] sp : ffffffc0b910bbd0
..
..
[ 3313.874685][ T4013] Call trace:
[ 3313.874687][ T4013]  dualshock4_led_get_brightness+0xc/0x74
[ 3313.874690][ T4013]  brightness_show+0x20/0x4c
[ 3313.874692][ T4013]  dev_attr_show+0x38/0x74
[ 3313.874696][ T4013]  sysfs_kf_seq_show+0xb4/0x130
[ 3313.874700][ T4013]  kernfs_seq_show+0x44/0x54
[ 3313.874703][ T4013]  seq_read_iter+0x158/0x4ec
[ 3313.874705][ T4013]  kernfs_fop_read_iter+0x68/0x1b4
[ 3313.874708][ T4013]  vfs_read+0x1e0/0x2c8
[ 3313.874711][ T4013]  ksys_read+0x78/0xe8
[ 3313.874714][ T4013]  __arm64_sys_read+0x1c/0x2c
[ 3313.874718][ T4013]  invoke_syscall+0x58/0x114
[ 3313.874721][ T4013]  el0_svc_common+0x80/0xe0
[ 3313.874724][ T4013]  do_el0_svc+0x1c/0x28
[ 3313.874727][ T4013]  el0_svc+0x38/0x68
[ 3313.874730][ T4013]  el0t_64_sync_handler+0x68/0xbc
[ 3313.874732][ T4013]  el0t_64_sync+0x1a8/0x1ac</Note>
    </Notes>
    <CVE>CVE-2024-56587</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: hisi_sas: Create all dump files during debugfs initialization

For the current debugfs of hisi_sas, after user triggers dump, the
driver allocate memory space to save the register information and create
debugfs files to display the saved information. In this process, the
debugfs files created after each dump.

Therefore, when the dump is triggered while the driver is unbind, the
following hang occurs:

[67840.853907] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0
[67840.862947] Mem abort info:
[67840.865855]   ESR = 0x0000000096000004
[67840.869713]   EC = 0x25: DABT (current EL), IL = 32 bits
[67840.875125]   SET = 0, FnV = 0
[67840.878291]   EA = 0, S1PTW = 0
[67840.881545]   FSC = 0x04: level 0 translation fault
[67840.886528] Data abort info:
[67840.889524]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[67840.895117]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[67840.900284]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[67840.905709] user pgtable: 4k pages, 48-bit VAs, pgdp=0000002803a1f000
[67840.912263] [00000000000000a0] pgd=0000000000000000, p4d=0000000000000000
[67840.919177] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
[67840.996435] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[67841.003628] pc : down_write+0x30/0x98
[67841.007546] lr : start_creating.part.0+0x60/0x198
[67841.012495] sp : ffff8000b979ba20
[67841.016046] x29: ffff8000b979ba20 x28: 0000000000000010 x27: 0000000000024b40
[67841.023412] x26: 0000000000000012 x25: ffff20202b355ae8 x24: ffff20202b35a8c8
[67841.030779] x23: ffffa36877928208 x22: ffffa368b4972240 x21: ffff8000b979bb18
[67841.038147] x20: ffff00281dc1e3c0 x19: fffffffffffffffe x18: 0000000000000020
[67841.045515] x17: 0000000000000000 x16: ffffa368b128a530 x15: ffffffffffffffff
[67841.052888] x14: ffff8000b979bc18 x13: ffffffffffffffff x12: ffff8000b979bb18
[67841.060263] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa368b1289b18
[67841.067640] x8 : 0000000000000012 x7 : 0000000000000000 x6 : 00000000000003a9
[67841.075014] x5 : 0000000000000000 x4 : ffff002818c5cb00 x3 : 0000000000000001
[67841.082388] x2 : 0000000000000000 x1 : ffff002818c5cb00 x0 : 00000000000000a0
[67841.089759] Call trace:
[67841.092456]  down_write+0x30/0x98
[67841.096017]  start_creating.part.0+0x60/0x198
[67841.100613]  debugfs_create_dir+0x48/0x1f8
[67841.104950]  debugfs_create_files_v3_hw+0x88/0x348 [hisi_sas_v3_hw]
[67841.111447]  debugfs_snapshot_regs_v3_hw+0x708/0x798 [hisi_sas_v3_hw]
[67841.118111]  debugfs_trigger_dump_v3_hw_write+0x9c/0x120 [hisi_sas_v3_hw]
[67841.125115]  full_proxy_write+0x68/0xc8
[67841.129175]  vfs_write+0xd8/0x3f0
[67841.132708]  ksys_write+0x70/0x108
[67841.136317]  __arm64_sys_write+0x24/0x38
[67841.140440]  invoke_syscall+0x50/0x128
[67841.144385]  el0_svc_common.constprop.0+0xc8/0xf0
[67841.149273]  do_el0_svc+0x24/0x38
[67841.152773]  el0_svc+0x38/0xd8
[67841.156009]  el0t_64_sync_handler+0xc0/0xc8
[67841.160361]  el0t_64_sync+0x1a4/0x1a8
[67841.164189] Code: b9000882 d2800002 d2800023 f9800011 (c85ffc05)
[67841.170443] ---[ end trace 0000000000000000 ]---

To fix this issue, create all directories and files during debugfs
initialization. In this way, the driver only needs to allocate memory
space to save information each time the user triggers dumping.</Note>
    </Notes>
    <CVE>CVE-2024-56588</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: hisi_sas: Add cond_resched() for no forced preemption model

For no forced preemption model kernel, in the scenario where the
expander is connected to 12 high performance SAS SSDs, the following
call trace may occur:

[  214.409199][  C240] watchdog: BUG: soft lockup - CPU#240 stuck for 22s! [irq/149-hisi_sa:3211]
[  214.568533][  C240] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--)
[  214.575224][  C240] pc : fput_many+0x8c/0xdc
[  214.579480][  C240] lr : fput+0x1c/0xf0
[  214.583302][  C240] sp : ffff80002de2b900
[  214.587298][  C240] x29: ffff80002de2b900 x28: ffff1082aa412000
[  214.593291][  C240] x27: ffff3062a0348c08 x26: ffff80003a9f6000
[  214.599284][  C240] x25: ffff1062bbac5c40 x24: 0000000000001000
[  214.605277][  C240] x23: 000000000000000a x22: 0000000000000001
[  214.611270][  C240] x21: 0000000000001000 x20: 0000000000000000
[  214.617262][  C240] x19: ffff3062a41ae580 x18: 0000000000010000
[  214.623255][  C240] x17: 0000000000000001 x16: ffffdb3a6efe5fc0
[  214.629248][  C240] x15: ffffffffffffffff x14: 0000000003ffffff
[  214.635241][  C240] x13: 000000000000ffff x12: 000000000000029c
[  214.641234][  C240] x11: 0000000000000006 x10: ffff80003a9f7fd0
[  214.647226][  C240] x9 : ffffdb3a6f0482fc x8 : 0000000000000001
[  214.653219][  C240] x7 : 0000000000000002 x6 : 0000000000000080
[  214.659212][  C240] x5 : ffff55480ee9b000 x4 : fffffde7f94c6554
[  214.665205][  C240] x3 : 0000000000000002 x2 : 0000000000000020
[  214.671198][  C240] x1 : 0000000000000021 x0 : ffff3062a41ae5b8
[  214.677191][  C240] Call trace:
[  214.680320][  C240]  fput_many+0x8c/0xdc
[  214.684230][  C240]  fput+0x1c/0xf0
[  214.687707][  C240]  aio_complete_rw+0xd8/0x1fc
[  214.692225][  C240]  blkdev_bio_end_io+0x98/0x140
[  214.696917][  C240]  bio_endio+0x160/0x1bc
[  214.701001][  C240]  blk_update_request+0x1c8/0x3bc
[  214.705867][  C240]  scsi_end_request+0x3c/0x1f0
[  214.710471][  C240]  scsi_io_completion+0x7c/0x1a0
[  214.715249][  C240]  scsi_finish_command+0x104/0x140
[  214.720200][  C240]  scsi_softirq_done+0x90/0x180
[  214.724892][  C240]  blk_mq_complete_request+0x5c/0x70
[  214.730016][  C240]  scsi_mq_done+0x48/0xac
[  214.734194][  C240]  sas_scsi_task_done+0xbc/0x16c [libsas]
[  214.739758][  C240]  slot_complete_v3_hw+0x260/0x760 [hisi_sas_v3_hw]
[  214.746185][  C240]  cq_thread_v3_hw+0xbc/0x190 [hisi_sas_v3_hw]
[  214.752179][  C240]  irq_thread_fn+0x34/0xa4
[  214.756435][  C240]  irq_thread+0xc4/0x130
[  214.760520][  C240]  kthread+0x108/0x13c
[  214.764430][  C240]  ret_from_fork+0x10/0x18

This is because in the hisi_sas driver, both the hardware interrupt
handler and the interrupt thread are executed on the same CPU. In the
performance test scenario, function irq_wait_for_interrupt() will always
return 0 if lots of interrupts occurs and the CPU will be continuously
consumed. As a result, the CPU cannot run the watchdog thread. When the
watchdog time exceeds the specified time, call trace occurs.

To fix it, add cond_resched() to execute the watchdog thread.</Note>
    </Notes>
    <CVE>CVE-2024-56589</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_core: Fix not checking skb length on hci_acldata_packet

This fixes not checking if skb really contains an ACL header otherwise
the code may attempt to access some uninitilized/invalid memory past the
valid skb-&gt;data.</Note>
    </Notes>
    <CVE>CVE-2024-56590</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Call free_htab_elem() after htab_unlock_bucket()

For htab of maps, when the map is removed from the htab, it may hold the
last reference of the map. bpf_map_fd_put_ptr() will invoke
bpf_map_free_id() to free the id of the removed map element. However,
bpf_map_fd_put_ptr() is invoked while holding a bucket lock
(raw_spin_lock_t), and bpf_map_free_id() attempts to acquire map_idr_lock
(spinlock_t), triggering the following lockdep warning:

  =============================
  [ BUG: Invalid wait context ]
  6.11.0-rc4+ #49 Not tainted
  -----------------------------
  test_maps/4881 is trying to lock:
  ffffffff84884578 (map_idr_lock){+...}-{3:3}, at: bpf_map_free_id.part.0+0x21/0x70
  other info that might help us debug this:
  context-{5:5}
  2 locks held by test_maps/4881:
   #0: ffffffff846caf60 (rcu_read_lock){....}-{1:3}, at: bpf_fd_htab_map_update_elem+0xf9/0x270
   #1: ffff888149ced148 (&amp;htab-&gt;lockdep_key#2){....}-{2:2}, at: htab_map_update_elem+0x178/0xa80
  stack backtrace:
  CPU: 0 UID: 0 PID: 4881 Comm: test_maps Not tainted 6.11.0-rc4+ #49
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ...
  Call Trace:
   &lt;TASK&gt;
   dump_stack_lvl+0x6e/0xb0
   dump_stack+0x10/0x20
   __lock_acquire+0x73e/0x36c0
   lock_acquire+0x182/0x450
   _raw_spin_lock_irqsave+0x43/0x70
   bpf_map_free_id.part.0+0x21/0x70
   bpf_map_put+0xcf/0x110
   bpf_map_fd_put_ptr+0x9a/0xb0
   free_htab_elem+0x69/0xe0
   htab_map_update_elem+0x50f/0xa80
   bpf_fd_htab_map_update_elem+0x131/0x270
   htab_map_update_elem+0x50f/0xa80
   bpf_fd_htab_map_update_elem+0x131/0x270
   bpf_map_update_value+0x266/0x380
   __sys_bpf+0x21bb/0x36b0
   __x64_sys_bpf+0x45/0x60
   x64_sys_call+0x1b2a/0x20d0
   do_syscall_64+0x5d/0x100
   entry_SYSCALL_64_after_hwframe+0x76/0x7e

One way to fix the lockdep warning is using raw_spinlock_t for
map_idr_lock as well. However, bpf_map_alloc_id() invokes
idr_alloc_cyclic() after acquiring map_idr_lock, it will trigger a
similar lockdep warning because the slab's lock (s-&gt;cpu_slab-&gt;lock) is
still a spinlock.

Instead of changing map_idr_lock's type, fix the issue by invoking
htab_put_fd_value() after htab_unlock_bucket(). However, only deferring
the invocation of htab_put_fd_value() is not enough, because the old map
pointers in htab of maps can not be saved during batched deletion.
Therefore, also defer the invocation of free_htab_elem(), so these
to-be-freed elements could be linked together similar to lru map.

There are four callers for -&gt;map_fd_put_ptr:

(1) alloc_htab_elem() (through htab_put_fd_value())
It invokes -&gt;map_fd_put_ptr() under a raw_spinlock_t. The invocation of
htab_put_fd_value() can not simply move after htab_unlock_bucket(),
because the old element has already been stashed in htab-&gt;extra_elems.
It may be reused immediately after htab_unlock_bucket() and the
invocation of htab_put_fd_value() after htab_unlock_bucket() may release
the newly-added element incorrectly. Therefore, saving the map pointer
of the old element for htab of maps before unlocking the bucket and
releasing the map_ptr after unlock. Beside the map pointer in the old
element, should do the same thing for the special fields in the old
element as well.

(2) free_htab_elem() (through htab_put_fd_value())
Its caller includes __htab_map_lookup_and_delete_elem(),
htab_map_delete_elem() and __htab_map_lookup_and_delete_batch().

For htab_map_delete_elem(), simply invoke free_htab_elem() after
htab_unlock_bucket(). For __htab_map_lookup_and_delete_batch(), just
like lru map, linking the to-be-freed element into node_to_free list
and invoking free_htab_elem() for these element after unlock. It is safe
to reuse batch_flink as the link for node_to_free, because these
elements have been removed from the hash llist.

Because htab of maps doesn't support lookup_and_delete operation,
__htab_map_lookup_and_delete_elem() doesn't have the problem, so kept
it as
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-56592</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw()

This patch fixes a NULL pointer dereference bug in brcmfmac that occurs
when a high 'sd_sgentry_align' value applies (e.g. 512) and a lot of queued SKBs
are sent from the pkt queue.

The problem is the number of entries in the pre-allocated sgtable, it is
nents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) &gt;&gt; 4 + 1.
Given the default [rt]xglom_size=32 it's actually 35 which is too small.
Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKB
is added for each original SKB if tailroom isn't enough to hold tail_pad.
At least one sg entry is needed for each SKB. So, eventually the "skb_queue_walk loop"
in brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next return
NULL and this causes the oops.

The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handle
the worst-case.
Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464
additional bytes of memory.</Note>
    </Notes>
    <CVE>CVE-2024-56593</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: set the right AMDGPU sg segment limitation

The driver needs to set the correct max_segment_size;
otherwise debug_dma_map_sg() will complain about the
over-mapping of the AMDGPU sg length as following:

WARNING: CPU: 6 PID: 1964 at kernel/dma/debug.c:1178 debug_dma_map_sg+0x2dc/0x370
[  364.049444] Modules linked in: veth amdgpu(OE) amdxcp drm_exec gpu_sched drm_buddy drm_ttm_helper ttm(OE) drm_suballoc_helper drm_display_helper drm_kms_helper i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc amd_atl intel_rapl_msr intel_rapl_common sunrpc sch_fq_codel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd binfmt_misc snd_hda_codec snd_pci_acp6x snd_hda_core snd_acp_config snd_hwdep snd_soc_acpi kvm_amd snd_pcm kvm snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 snd_rawmidi sha256_ssse3 sha1_ssse3 aesni_intel snd_seq nls_iso8859_1 crypto_simd snd_seq_device cryptd snd_timer rapl input_leds snd
[  364.049532]  ipmi_devintf wmi_bmof ccp serio_raw k10temp sp5100_tco soundcore ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii
[  364.049576] CPU: 6 PID: 1964 Comm: rocminfo Tainted: G           OE      6.10.0-custom #492
[  364.049579] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021
[  364.049582] RIP: 0010:debug_dma_map_sg+0x2dc/0x370
[  364.049585] Code: 89 4d b8 e8 36 b1 86 00 8b 4d b8 48 8b 55 b0 44 8b 45 a8 4c 8b 4d a0 48 89 c6 48 c7 c7 00 4b 74 bc 4c 89 4d b8 e8 b4 73 f3 ff &lt;0f&gt; 0b 4c 8b 4d b8 8b 15 c8 2c b8 01 85 d2 0f 85 ee fd ff ff 8b 05
[  364.049588] RSP: 0018:ffff9ca600b57ac0 EFLAGS: 00010286
[  364.049590] RAX: 0000000000000000 RBX: ffff88b7c132b0c8 RCX: 0000000000000027
[  364.049592] RDX: ffff88bb0f521688 RSI: 0000000000000001 RDI: ffff88bb0f521680
[  364.049594] RBP: ffff9ca600b57b20 R08: 000000000000006f R09: ffff9ca600b57930
[  364.049596] R10: ffff9ca600b57928 R11: ffffffffbcb46328 R12: 0000000000000000
[  364.049597] R13: 0000000000000001 R14: ffff88b7c19c0700 R15: ffff88b7c9059800
[  364.049599] FS:  00007fb2d3516e80(0000) GS:ffff88bb0f500000(0000) knlGS:0000000000000000
[  364.049601] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  364.049603] CR2: 000055610bd03598 CR3: 00000001049f6000 CR4: 0000000000350ef0
[  364.049605] Call Trace:
[  364.049607]  &lt;TASK&gt;
[  364.049609]  ? show_regs+0x6d/0x80
[  364.049614]  ? __warn+0x8c/0x140
[  364.049618]  ? debug_dma_map_sg+0x2dc/0x370
[  364.049621]  ? report_bug+0x193/0x1a0
[  364.049627]  ? handle_bug+0x46/0x80
[  364.049631]  ? exc_invalid_op+0x1d/0x80
[  364.049635]  ? asm_exc_invalid_op+0x1f/0x30
[  364.049642]  ? debug_dma_map_sg+0x2dc/0x370
[  364.049647]  __dma_map_sg_attrs+0x90/0xe0
[  364.049651]  dma_map_sgtable+0x25/0x40
[  364.049654]  amdgpu_bo_move+0x59a/0x850 [amdgpu]
[  364.049935]  ? srso_return_thunk+0x5/0x5f
[  364.049939]  ? amdgpu_ttm_tt_populate+0x5d/0xc0 [amdgpu]
[  364.050095]  ttm_bo_handle_move_mem+0xc3/0x180 [ttm]
[  364.050103]  ttm_bo_validate+0xc1/0x160 [ttm]
[  364.050108]  ? amdgpu_ttm_tt_get_user_pages+0xe5/0x1b0 [amdgpu]
[  364.050263]  amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0xa12/0xc90 [amdgpu]
[  364.050473]  kfd_ioctl_alloc_memory_of_gpu+0x16b/0x3b0 [amdgpu]
[  364.050680]  kfd_ioctl+0x3c2/0x530 [amdgpu]
[  364.050866]  ? __pfx_kfd_ioctl_alloc_memory_of_gpu+0x10/0x10 [amdgpu]
[  364.05105
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-56594</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

jfs: add a check to prevent array-index-out-of-bounds in dbAdjTree

When the value of lp is 0 at the beginning of the for loop, it will
become negative in the next assignment and we should bail out.</Note>
    </Notes>
    <CVE>CVE-2024-56595</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

jfs: fix array-index-out-of-bounds in jfs_readdir

The stbl might contain some invalid values. Added a check to
return error code in that case.</Note>
    </Notes>
    <CVE>CVE-2024-56596</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

jfs: fix shift-out-of-bounds in dbSplit

When dmt_budmin is less than zero, it causes errors
in the later stages. Added a check to return an error beforehand
in dbAllocCtl itself.</Note>
    </Notes>
    <CVE>CVE-2024-56597</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

jfs: array-index-out-of-bounds fix in dtReadFirst

The value of stbl can be sometimes out of bounds due
to a bad filesystem. Added a check with appopriate return
of error code in that case.</Note>
    </Notes>
    <CVE>CVE-2024-56598</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Use of Hardware Page Aggregation (HPA) and Stage-1 and/or Stage-2 translation on Cortex-A77, Cortex-A78, Cortex-A78C, Cortex-A78AE, Cortex-A710, Cortex-X1, Cortex-X1C, Cortex-X2, Cortex-X3, Cortex-X4, Cortex-X925, Neoverse V1, Neoverse V2, Neoverse V3, Neoverse V3AE, Neoverse N2 may permit bypass of Stage-2 translation and/or GPT protection.</Note>
    </Notes>
    <CVE>CVE-2024-5660</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>critical</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: inet6: do not leave a dangling sk pointer in inet6_create()

sock_init_data() attaches the allocated sk pointer to the provided sock
object. If inet6_create() fails later, the sk object is released, but the
sock object retains the dangling sk pointer, which may cause use-after-free
later.

Clear the sock sk pointer on error.</Note>
    </Notes>
    <CVE>CVE-2024-56600</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: inet: do not leave a dangling sk pointer in inet_create()

sock_init_data() attaches the allocated sk object to the provided sock
object. If inet_create() fails later, the sk object is freed, but the
sock object retains the dangling pointer, which may create use-after-free
later.

Clear the sk pointer in the sock object on error.</Note>
    </Notes>
    <CVE>CVE-2024-56601</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: ieee802154: do not leave a dangling sk pointer in ieee802154_create()

sock_init_data() attaches the allocated sk object to the provided sock
object. If ieee802154_create() fails later, the allocated sk object is
freed, but the dangling pointer remains in the provided sock object, which
may allow use-after-free.

Clear the sk pointer in the sock object on error.</Note>
    </Notes>
    <CVE>CVE-2024-56602</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: af_can: do not leave a dangling sk pointer in can_create()

On error can_create() frees the allocated sk object, but sock_init_data()
has already attached it to the provided sock object. This will leave a
dangling sk pointer in the sock object and may cause use-after-free later.</Note>
    </Notes>
    <CVE>CVE-2024-56603</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()

bt_sock_alloc() allocates the sk object and attaches it to the provided
sock object. On error l2cap_sock_alloc() frees the sk object, but the
dangling pointer is still attached to the sock object, which may create
use-after-free in other code.</Note>
    </Notes>
    <CVE>CVE-2024-56605</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

af_packet: avoid erroring out after sock_init_data() in packet_create()

After sock_init_data() the allocated sk object is attached to the provided
sock object. On error, packet_create() frees the sk object leaving the
dangling pointer in the sock object on return. Some other code may try
to use this pointer and cause use-after-free.</Note>
    </Notes>
    <CVE>CVE-2024-56606</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: fix atomic calls in ath12k_mac_op_set_bitrate_mask()

When I try to manually set bitrates:

iw wlan0 set bitrates legacy-2.4 1

I get sleeping from invalid context error, see below. Fix that by switching to
use recently introduced ieee80211_iterate_stations_mtx().

Do note that WCN6855 firmware is still crashing, I'm not sure if that firmware
even supports bitrate WMI commands and should we consider disabling
ath12k_mac_op_set_bitrate_mask() for WCN6855? But that's for another patch.

BUG: sleeping function called from invalid context at drivers/net/wireless/ath/ath12k/wmi.c:420
in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 2236, name: iw
preempt_count: 0, expected: 0
RCU nest depth: 1, expected: 0
3 locks held by iw/2236:
 #0: ffffffffabc6f1d8 (cb_lock){++++}-{3:3}, at: genl_rcv+0x14/0x40
 #1: ffff888138410810 (&amp;rdev-&gt;wiphy.mtx){+.+.}-{3:3}, at: nl80211_pre_doit+0x54d/0x800 [cfg80211]
 #2: ffffffffab2cfaa0 (rcu_read_lock){....}-{1:2}, at: ieee80211_iterate_stations_atomic+0x2f/0x200 [mac80211]
CPU: 3 UID: 0 PID: 2236 Comm: iw Not tainted 6.11.0-rc7-wt-ath+ #1772
Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0xa4/0xe0
 dump_stack+0x10/0x20
 __might_resched+0x363/0x5a0
 ? __alloc_skb+0x165/0x340
 __might_sleep+0xad/0x160
 ath12k_wmi_cmd_send+0xb1/0x3d0 [ath12k]
 ? ath12k_wmi_init_wcn7850+0xa40/0xa40 [ath12k]
 ? __netdev_alloc_skb+0x45/0x7b0
 ? __asan_memset+0x39/0x40
 ? ath12k_wmi_alloc_skb+0xf0/0x150 [ath12k]
 ? reacquire_held_locks+0x4d0/0x4d0
 ath12k_wmi_set_peer_param+0x340/0x5b0 [ath12k]
 ath12k_mac_disable_peer_fixed_rate+0xa3/0x110 [ath12k]
 ? ath12k_mac_vdev_stop+0x4f0/0x4f0 [ath12k]
 ieee80211_iterate_stations_atomic+0xd4/0x200 [mac80211]
 ath12k_mac_op_set_bitrate_mask+0x5d2/0x1080 [ath12k]
 ? ath12k_mac_vif_chan+0x320/0x320 [ath12k]
 drv_set_bitrate_mask+0x267/0x470 [mac80211]
 ieee80211_set_bitrate_mask+0x4cc/0x8a0 [mac80211]
 ? __this_cpu_preempt_check+0x13/0x20
 nl80211_set_tx_bitrate_mask+0x2bc/0x530 [cfg80211]
 ? nl80211_parse_tx_bitrate_mask+0x2320/0x2320 [cfg80211]
 ? trace_contention_end+0xef/0x140
 ? rtnl_unlock+0x9/0x10
 ? nl80211_pre_doit+0x557/0x800 [cfg80211]
 genl_family_rcv_msg_doit+0x1f0/0x2e0
 ? genl_family_rcv_msg_attrs_parse.isra.0+0x250/0x250
 ? ns_capable+0x57/0xd0
 genl_family_rcv_msg+0x34c/0x600
 ? genl_family_rcv_msg_dumpit+0x310/0x310
 ? __lock_acquire+0xc62/0x1de0
 ? he_set_mcs_mask.isra.0+0x8d0/0x8d0 [cfg80211]
 ? nl80211_parse_tx_bitrate_mask+0x2320/0x2320 [cfg80211]
 ? cfg80211_external_auth_request+0x690/0x690 [cfg80211]
 genl_rcv_msg+0xa0/0x130
 netlink_rcv_skb+0x14c/0x400
 ? genl_family_rcv_msg+0x600/0x600
 ? netlink_ack+0xd70/0xd70
 ? rwsem_optimistic_spin+0x4f0/0x4f0
 ? genl_rcv+0x14/0x40
 ? down_read_killable+0x580/0x580
 ? netlink_deliver_tap+0x13e/0x350
 ? __this_cpu_preempt_check+0x13/0x20
 genl_rcv+0x23/0x40
 netlink_unicast+0x45e/0x790
 ? netlink_attachskb+0x7f0/0x7f0
 netlink_sendmsg+0x7eb/0xdb0
 ? netlink_unicast+0x790/0x790
 ? __this_cpu_preempt_check+0x13/0x20
 ? selinux_socket_sendmsg+0x31/0x40
 ? netlink_unicast+0x790/0x790
 __sock_sendmsg+0xc9/0x160
 ____sys_sendmsg+0x620/0x990
 ? kernel_sendmsg+0x30/0x30
 ? __copy_msghdr+0x410/0x410
 ? __kasan_check_read+0x11/0x20
 ? mark_lock+0xe6/0x1470
 ___sys_sendmsg+0xe9/0x170
 ? copy_msghdr_from_user+0x120/0x120
 ? __lock_acquire+0xc62/0x1de0
 ? do_fault_around+0x2c6/0x4e0
 ? do_user_addr_fault+0x8c1/0xde0
 ? reacquire_held_locks+0x220/0x4d0
 ? do_user_addr_fault+0x8c1/0xde0
 ? __kasan_check_read+0x11/0x20
 ? __fdget+0x4e/0x1d0
 ? sockfd_lookup_light+0x1a/0x170
 __sys_sendmsg+0xd2/0x180
 ? __sys_sendmsg_sock+0x20/0x20
 ? reacquire_held_locks+0x4d0/0x4d0
 ? debug_smp_processor_id+0x17/0x20
 __x64_sys_sendmsg+0x72/0xb0
 ? lockdep_hardirqs_on+0x7d/0x100
 x64_sys_call+0x894/0x9f0
 do_syscall_64+0x64/0x130
 entry_SYSCALL_64_after_
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-56607</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix out-of-bounds access in 'dcn21_link_encoder_create'

An issue was identified in the dcn21_link_encoder_create function where
an out-of-bounds access could occur when the hpd_source index was used
to reference the link_enc_hpd_regs array. This array has a fixed size
and the index was not being checked against the array's bounds before
accessing it.

This fix adds a conditional check to ensure that the hpd_source index is
within the valid range of the link_enc_hpd_regs array. If the index is
out of bounds, the function now returns NULL to prevent undefined
behavior.

References:

[   65.920507] ------------[ cut here ]------------
[   65.920510] UBSAN: array-index-out-of-bounds in drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn21/dcn21_resource.c:1312:29
[   65.920519] index 7 is out of range for type 'dcn10_link_enc_hpd_registers [5]'
[   65.920523] CPU: 3 PID: 1178 Comm: modprobe Tainted: G           OE      6.8.0-cleanershaderfeatureresetasdntipmi200nv2132 #13
[   65.920525] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS WMJ0429N_Weekly_20_04_2 04/29/2020
[   65.920527] Call Trace:
[   65.920529]  &lt;TASK&gt;
[   65.920532]  dump_stack_lvl+0x48/0x70
[   65.920541]  dump_stack+0x10/0x20
[   65.920543]  __ubsan_handle_out_of_bounds+0xa2/0xe0
[   65.920549]  dcn21_link_encoder_create+0xd9/0x140 [amdgpu]
[   65.921009]  link_create+0x6d3/0xed0 [amdgpu]
[   65.921355]  create_links+0x18a/0x4e0 [amdgpu]
[   65.921679]  dc_create+0x360/0x720 [amdgpu]
[   65.921999]  ? dmi_matches+0xa0/0x220
[   65.922004]  amdgpu_dm_init+0x2b6/0x2c90 [amdgpu]
[   65.922342]  ? console_unlock+0x77/0x120
[   65.922348]  ? dev_printk_emit+0x86/0xb0
[   65.922354]  dm_hw_init+0x15/0x40 [amdgpu]
[   65.922686]  amdgpu_device_init+0x26a8/0x33a0 [amdgpu]
[   65.922921]  amdgpu_driver_load_kms+0x1b/0xa0 [amdgpu]
[   65.923087]  amdgpu_pci_probe+0x1b7/0x630 [amdgpu]
[   65.923087]  local_pci_probe+0x4b/0xb0
[   65.923087]  pci_device_probe+0xc8/0x280
[   65.923087]  really_probe+0x187/0x300
[   65.923087]  __driver_probe_device+0x85/0x130
[   65.923087]  driver_probe_device+0x24/0x110
[   65.923087]  __driver_attach+0xac/0x1d0
[   65.923087]  ? __pfx___driver_attach+0x10/0x10
[   65.923087]  bus_for_each_dev+0x7d/0xd0
[   65.923087]  driver_attach+0x1e/0x30
[   65.923087]  bus_add_driver+0xf2/0x200
[   65.923087]  driver_register+0x64/0x130
[   65.923087]  ? __pfx_amdgpu_init+0x10/0x10 [amdgpu]
[   65.923087]  __pci_register_driver+0x61/0x70
[   65.923087]  amdgpu_init+0x7d/0xff0 [amdgpu]
[   65.923087]  do_one_initcall+0x49/0x310
[   65.923087]  ? kmalloc_trace+0x136/0x360
[   65.923087]  do_init_module+0x6a/0x270
[   65.923087]  load_module+0x1fce/0x23a0
[   65.923087]  init_module_from_file+0x9c/0xe0
[   65.923087]  ? init_module_from_file+0x9c/0xe0
[   65.923087]  idempotent_init_module+0x179/0x230
[   65.923087]  __x64_sys_finit_module+0x5d/0xa0
[   65.923087]  do_syscall_64+0x76/0x120
[   65.923087]  entry_SYSCALL_64_after_hwframe+0x6e/0x76
[   65.923087] RIP: 0033:0x7f2d80f1e88d
[   65.923087] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48
[   65.923087] RSP: 002b:00007ffc7bc1aa78 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[   65.923087] RAX: ffffffffffffffda RBX: 0000564c9c1db130 RCX: 00007f2d80f1e88d
[   65.923087] RDX: 0000000000000000 RSI: 0000564c9c1e5480 RDI: 000000000000000f
[   65.923087] RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000002
[   65.923087] R10: 000000000000000f R11: 0000000000000246 R12: 0000564c9c1e5480
[   65.923087] R13: 0000564c9c1db260 R14: 0000000000000000 R15: 0000564c9c1e54b0
[   65.923087]  &lt;/TASK&gt;
[   65.923927] ---[ end trace ]---</Note>
    </Notes>
    <CVE>CVE-2024-56608</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: rtw88: use ieee80211_purge_tx_queue() to purge TX skb

When removing kernel modules by:
   rmmod rtw88_8723cs rtw88_8703b rtw88_8723x rtw88_sdio rtw88_core

Driver uses skb_queue_purge() to purge TX skb, but not report tx status
causing "Have pending ack frames!" warning. Use ieee80211_purge_tx_queue()
to correct this.

Since ieee80211_purge_tx_queue() doesn't take locks, to prevent racing
between TX work and purge TX queue, flush and destroy TX work in advance.

   wlan0: deauthenticating from aa:f5:fd:60:4c:a8 by local
     choice (Reason: 3=DEAUTH_LEAVING)
   ------------[ cut here ]------------
   Have pending ack frames!
   WARNING: CPU: 3 PID: 9232 at net/mac80211/main.c:1691
       ieee80211_free_ack_frame+0x5c/0x90 [mac80211]
   CPU: 3 PID: 9232 Comm: rmmod Tainted: G         C
       6.10.1-200.fc40.aarch64 #1
   Hardware name: pine64 Pine64 PinePhone Braveheart
      (1.1)/Pine64 PinePhone Braveheart (1.1), BIOS 2024.01 01/01/2024
   pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
   pc : ieee80211_free_ack_frame+0x5c/0x90 [mac80211]
   lr : ieee80211_free_ack_frame+0x5c/0x90 [mac80211]
   sp : ffff80008c1b37b0
   x29: ffff80008c1b37b0 x28: ffff000003be8000 x27: 0000000000000000
   x26: 0000000000000000 x25: ffff000003dc14b8 x24: ffff80008c1b37d0
   x23: ffff000000ff9f80 x22: 0000000000000000 x21: 000000007fffffff
   x20: ffff80007c7e93d8 x19: ffff00006e66f400 x18: 0000000000000000
   x17: ffff7ffffd2b3000 x16: ffff800083fc0000 x15: 0000000000000000
   x14: 0000000000000000 x13: 2173656d61726620 x12: 6b636120676e6964
   x11: 0000000000000000 x10: 000000000000005d x9 : ffff8000802af2b0
   x8 : ffff80008c1b3430 x7 : 0000000000000001 x6 : 0000000000000001
   x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
   x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000003be8000
   Call trace:
    ieee80211_free_ack_frame+0x5c/0x90 [mac80211]
    idr_for_each+0x74/0x110
    ieee80211_free_hw+0x44/0xe8 [mac80211]
    rtw_sdio_remove+0x9c/0xc0 [rtw88_sdio]
    sdio_bus_remove+0x44/0x180
    device_remove+0x54/0x90
    device_release_driver_internal+0x1d4/0x238
    driver_detach+0x54/0xc0
    bus_remove_driver+0x78/0x108
    driver_unregister+0x38/0x78
    sdio_unregister_driver+0x2c/0x40
    rtw_8723cs_driver_exit+0x18/0x1000 [rtw88_8723cs]
    __do_sys_delete_module.isra.0+0x190/0x338
    __arm64_sys_delete_module+0x1c/0x30
    invoke_syscall+0x74/0x100
    el0_svc_common.constprop.0+0x48/0xf0
    do_el0_svc+0x24/0x38
    el0_svc+0x3c/0x158
    el0t_64_sync_handler+0x120/0x138
    el0t_64_sync+0x194/0x198
   ---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2024-56609</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

kcsan: Turn report_filterlist_lock into a raw_spinlock

Ran Xiaokai reports that with a KCSAN-enabled PREEMPT_RT kernel, we can see
splats like:

| BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
| in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1
| preempt_count: 10002, expected: 0
| RCU nest depth: 0, expected: 0
| no locks held by swapper/1/0.
| irq event stamp: 156674
| hardirqs last  enabled at (156673): [&lt;ffffffff81130bd9&gt;] do_idle+0x1f9/0x240
| hardirqs last disabled at (156674): [&lt;ffffffff82254f84&gt;] sysvec_apic_timer_interrupt+0x14/0xc0
| softirqs last  enabled at (0): [&lt;ffffffff81099f47&gt;] copy_process+0xfc7/0x4b60
| softirqs last disabled at (0): [&lt;0000000000000000&gt;] 0x0
| Preemption disabled at:
| [&lt;ffffffff814a3e2a&gt;] paint_ptr+0x2a/0x90
| CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0+ #3
| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014
| Call Trace:
|  &lt;IRQ&gt;
|  dump_stack_lvl+0x7e/0xc0
|  dump_stack+0x1d/0x30
|  __might_resched+0x1a2/0x270
|  rt_spin_lock+0x68/0x170
|  kcsan_skip_report_debugfs+0x43/0xe0
|  print_report+0xb5/0x590
|  kcsan_report_known_origin+0x1b1/0x1d0
|  kcsan_setup_watchpoint+0x348/0x650
|  __tsan_unaligned_write1+0x16d/0x1d0
|  hrtimer_interrupt+0x3d6/0x430
|  __sysvec_apic_timer_interrupt+0xe8/0x3a0
|  sysvec_apic_timer_interrupt+0x97/0xc0
|  &lt;/IRQ&gt;

On a detected data race, KCSAN's reporting logic checks if it should
filter the report. That list is protected by the report_filterlist_lock
*non-raw* spinlock which may sleep on RT kernels.

Since KCSAN may report data races in any context, convert it to a
raw_spinlock.

This requires being careful about when to allocate memory for the filter
list itself which can be done via KCSAN's debugfs interface. Concurrent
modification of the filter list via debugfs should be rare: the chosen
strategy is to optimistically pre-allocate memory before the critical
section and discard if unused.</Note>
    </Notes>
    <CVE>CVE-2024-56610</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM

We currently assume that there is at least one VMA in a MM, which isn't
true.

So we might end up having find_vma() return NULL, to then de-reference
NULL.  So properly handle find_vma() returning NULL.

This fixes the report:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024
RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline]
RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194
Code: ...
RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000
RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044
RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1
R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003
R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8
FS:  00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709
 __do_sys_migrate_pages mm/mempolicy.c:1727 [inline]
 __se_sys_migrate_pages mm/mempolicy.c:1723 [inline]
 __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

[akpm@linux-foundation.org: add unlikely()]</Note>
    </Notes>
    <CVE>CVE-2024-56611</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xsk: fix OOB map writes when deleting elements

Jordy says:

"
In the xsk_map_delete_elem function an unsigned integer
(map-&gt;max_entries) is compared with a user-controlled signed integer
(k). Due to implicit type conversion, a large unsigned value for
map-&gt;max_entries can bypass the intended bounds check:

	if (k &gt;= map-&gt;max_entries)
		return -EINVAL;

This allows k to hold a negative value (between -2147483648 and -2),
which is then used as an array index in m-&gt;xsk_map[k], which results
in an out-of-bounds access.

	spin_lock_bh(&amp;m-&gt;lock);
	map_entry = &amp;m-&gt;xsk_map[k]; // Out-of-bounds map_entry
	old_xs = unrcu_pointer(xchg(map_entry, NULL));  // Oob write
	if (old_xs)
		xsk_map_sock_delete(old_xs, map_entry);
	spin_unlock_bh(&amp;m-&gt;lock);

The xchg operation can then be used to cause an out-of-bounds write.
Moreover, the invalid map_entry passed to xsk_map_sock_delete can lead
to further memory corruption.
"

It indeed results in following splat:

[76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108
[76612.904330] #PF: supervisor write access in kernel mode
[76612.909639] #PF: error_code(0x0002) - not-present page
[76612.914855] PGD 0 P4D 0
[76612.917431] Oops: Oops: 0002 [#1] PREEMPT SMP
[76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out Not tainted 6.12.0-rc1+ #470
[76612.929189] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019
[76612.939781] RIP: 0010:xsk_map_delete_elem+0x2d/0x60
[76612.944738] Code: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 ff &lt;48&gt; 87 3e 48 85 ff 74 05 e8 16 ff ff ff 4c 89 e7 e8 3e bc 05 00 31
[76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246
[76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000
[76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 0000000000000000
[76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007
[76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8
[76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0
[76613.005303] FS:  00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000
[76613.013517] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0
[76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[76613.041086] PKRU: 55555554
[76613.043842] Call Trace:
[76613.046331]  &lt;TASK&gt;
[76613.048468]  ? __die+0x20/0x60
[76613.051581]  ? page_fault_oops+0x15a/0x450
[76613.055747]  ? search_extable+0x22/0x30
[76613.059649]  ? search_bpf_extables+0x5f/0x80
[76613.063988]  ? exc_page_fault+0xa9/0x140
[76613.067975]  ? asm_exc_page_fault+0x22/0x30
[76613.072229]  ? xsk_map_delete_elem+0x2d/0x60
[76613.076573]  ? xsk_map_delete_elem+0x23/0x60
[76613.080914]  __sys_bpf+0x19b7/0x23c0
[76613.084555]  __x64_sys_bpf+0x1a/0x20
[76613.088194]  do_syscall_64+0x37/0xb0
[76613.091832]  entry_SYSCALL_64_after_hwframe+0x4b/0x53
[76613.096962] RIP: 0033:0x7f80b6d1e88d
[76613.100592] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48
[76613.119631] RSP: 002b:00007ffd1ae0ac68 EFLAGS: 00000206 ORIG_RAX: 0000000000000141
[76613.131330] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f80b6d1e88d
[76613.142632] RDX: 0000000000000098 RSI: 00007ffd1ae0ad20 RDI: 0000000000000003
[76613.153967] RBP: 00007ffd1ae0adc0 R08: 0000000000000000 R09: 0000000000000000
[76613.166030] R10: 00007f80b6f77040 R11: 0000000000000206 R12: 00007ffd1ae0aed8
[76613.177130] R13: 000055ddf42ce1e9 R14: 000055ddf42d0d98 R15: 00
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-56614</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: fix OOB devmap writes when deleting elements

Jordy reported issue against XSKMAP which also applies to DEVMAP - the
index used for accessing map entry, due to being a signed integer,
causes the OOB writes. Fix is simple as changing the type from int to
u32, however, when compared to XSKMAP case, one more thing needs to be
addressed.

When map is released from system via dev_map_free(), we iterate through
all of the entries and an iterator variable is also an int, which
implies OOB accesses. Again, change it to be u32.

Example splat below:

[  160.724676] BUG: unable to handle page fault for address: ffffc8fc2c001000
[  160.731662] #PF: supervisor read access in kernel mode
[  160.736876] #PF: error_code(0x0000) - not-present page
[  160.742095] PGD 0 P4D 0
[  160.744678] Oops: Oops: 0000 [#1] PREEMPT SMP
[  160.749106] CPU: 1 UID: 0 PID: 520 Comm: kworker/u145:12 Not tainted 6.12.0-rc1+ #487
[  160.757050] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019
[  160.767642] Workqueue: events_unbound bpf_map_free_deferred
[  160.773308] RIP: 0010:dev_map_free+0x77/0x170
[  160.777735] Code: 00 e8 fd 91 ed ff e8 b8 73 ed ff 41 83 7d 18 19 74 6e 41 8b 45 24 49 8b bd f8 00 00 00 31 db 85 c0 74 48 48 63 c3 48 8d 04 c7 &lt;48&gt; 8b 28 48 85 ed 74 30 48 8b 7d 18 48 85 ff 74 05 e8 b3 52 fa ff
[  160.796777] RSP: 0018:ffffc9000ee1fe38 EFLAGS: 00010202
[  160.802086] RAX: ffffc8fc2c001000 RBX: 0000000080000000 RCX: 0000000000000024
[  160.809331] RDX: 0000000000000000 RSI: 0000000000000024 RDI: ffffc9002c001000
[  160.816576] RBP: 0000000000000000 R08: 0000000000000023 R09: 0000000000000001
[  160.823823] R10: 0000000000000001 R11: 00000000000ee6b2 R12: dead000000000122
[  160.831066] R13: ffff88810c928e00 R14: ffff8881002df405 R15: 0000000000000000
[  160.838310] FS:  0000000000000000(0000) GS:ffff8897e0c40000(0000) knlGS:0000000000000000
[  160.846528] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  160.852357] CR2: ffffc8fc2c001000 CR3: 0000000005c32006 CR4: 00000000007726f0
[  160.859604] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  160.866847] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  160.874092] PKRU: 55555554
[  160.876847] Call Trace:
[  160.879338]  &lt;TASK&gt;
[  160.881477]  ? __die+0x20/0x60
[  160.884586]  ? page_fault_oops+0x15a/0x450
[  160.888746]  ? search_extable+0x22/0x30
[  160.892647]  ? search_bpf_extables+0x5f/0x80
[  160.896988]  ? exc_page_fault+0xa9/0x140
[  160.900973]  ? asm_exc_page_fault+0x22/0x30
[  160.905232]  ? dev_map_free+0x77/0x170
[  160.909043]  ? dev_map_free+0x58/0x170
[  160.912857]  bpf_map_free_deferred+0x51/0x90
[  160.917196]  process_one_work+0x142/0x370
[  160.921272]  worker_thread+0x29e/0x3b0
[  160.925082]  ? rescuer_thread+0x4b0/0x4b0
[  160.929157]  kthread+0xd4/0x110
[  160.932355]  ? kthread_park+0x80/0x80
[  160.936079]  ret_from_fork+0x2d/0x50
[  160.943396]  ? kthread_park+0x80/0x80
[  160.950803]  ret_from_fork_asm+0x11/0x20
[  160.958482]  &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-56615</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/dp_mst: Fix MST sideband message body length check

Fix the MST sideband message body length check, which must be at least 1
byte accounting for the message body CRC (aka message data CRC) at the
end of the message.

This fixes a case where an MST branch device returns a header with a
correct header CRC (indicating a correctly received body length), with
the body length being incorrectly set to 0. This will later lead to a
memory corruption in drm_dp_sideband_append_payload() and the following
errors in dmesg:

   UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25
   index -1 is out of range for type 'u8 [48]'
   Call Trace:
    drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper]
    drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper]
    drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper]

   memcpy: detected field-spanning write (size 18446744073709551615) of single field "&amp;msg-&gt;msg[msg-&gt;curlen]" at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256)
   Call Trace:
    drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper]
    drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper]
    drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper]</Note>
    </Notes>
    <CVE>CVE-2024-56616</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cacheinfo: Allocate memory during CPU hotplug if not done from the primary CPU

Commit

  5944ce092b97 ("arch_topology: Build cacheinfo from primary CPU")

adds functionality that architectures can use to optionally allocate and
build cacheinfo early during boot. Commit

  6539cffa9495 ("cacheinfo: Add arch specific early level initializer")

lets secondary CPUs correct (and reallocate memory) cacheinfo data if
needed.

If the early build functionality is not used and cacheinfo does not need
correction, memory for cacheinfo is never allocated. x86 does not use
the early build functionality. Consequently, during the cacheinfo CPU
hotplug callback, last_level_cache_is_valid() attempts to dereference
a NULL pointer:

  BUG: kernel NULL pointer dereference, address: 0000000000000100
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not present page
  PGD 0 P4D 0
  Oops: 0000 [#1] PREEPMT SMP NOPTI
  CPU: 0 PID 19 Comm: cpuhp/0 Not tainted 6.4.0-rc2 #1
  RIP: 0010: last_level_cache_is_valid+0x95/0xe0a

Allocate memory for cacheinfo during the cacheinfo CPU hotplug callback
if not done earlier.

Moreover, before determining the validity of the last-level cache info,
ensure that it has been allocated. Simply checking for non-zero
cache_leaves() is not sufficient, as some architectures (e.g., Intel
processors) have non-zero cache_leaves() before allocation.

Dereferencing NULL cacheinfo can occur in update_per_cpu_data_slice_size().
This function iterates over all online CPUs. However, a CPU may have come
online recently, but its cacheinfo may not have been allocated yet.

While here, remove an unnecessary indentation in allocate_cache_info().

  [ bp: Massage. ]</Note>
    </Notes>
    <CVE>CVE-2024-56617</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix potential out-of-bounds memory access in nilfs_find_entry()

Syzbot reported that when searching for records in a directory where the
inode's i_size is corrupted and has a large value, memory access outside
the folio/page range may occur, or a use-after-free bug may be detected if
KASAN is enabled.

This is because nilfs_last_byte(), which is called by nilfs_find_entry()
and others to calculate the number of valid bytes of directory data in a
page from i_size and the page index, loses the upper 32 bits of the 64-bit
size information due to an inappropriate type of local variable to which
the i_size value is assigned.

This caused a large byte offset value due to underflow in the end address
calculation in the calling nilfs_find_entry(), resulting in memory access
that exceeds the folio/page size.

Fix this issue by changing the type of the local variable causing the bit
loss from "unsigned int" to "u64".  The return value of nilfs_last_byte()
is also of type "unsigned int", but it is truncated so as not to exceed
PAGE_SIZE and no bit loss occurs, so no change is required.</Note>
    </Notes>
    <CVE>CVE-2024-56619</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: ufs: qcom: Only free platform MSIs when ESI is enabled

Otherwise, it will result in a NULL pointer dereference as below:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
Call trace:
 mutex_lock+0xc/0x54
 platform_device_msi_free_irqs_all+0x14/0x20
 ufs_qcom_remove+0x34/0x48 [ufs_qcom]
 platform_remove+0x28/0x44
 device_remove+0x4c/0x80
 device_release_driver_internal+0xd8/0x178
 driver_detach+0x50/0x9c
 bus_remove_driver+0x6c/0xbc
 driver_unregister+0x30/0x60
 platform_driver_unregister+0x14/0x20
 ufs_qcom_pltform_exit+0x18/0xb94 [ufs_qcom]
 __arm64_sys_delete_module+0x180/0x260
 invoke_syscall+0x44/0x100
 el0_svc_common.constprop.0+0xc0/0xe0
 do_el0_svc+0x1c/0x28
 el0_svc+0x34/0xdc
 el0t_64_sync_handler+0xc0/0xc4
 el0t_64_sync+0x190/0x194</Note>
    </Notes>
    <CVE>CVE-2024-56620</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: ufs: core: sysfs: Prevent div by zero

Prevent a division by 0 when monitoring is not enabled.</Note>
    </Notes>
    <CVE>CVE-2024-56622</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: qla2xxx: Fix use after free on unload

System crash is observed with stack trace warning of use after
free. There are 2 signals to tell dpc_thread to terminate (UNLOADING
flag and kthread_stop).

On setting the UNLOADING flag when dpc_thread happens to run at the time
and sees the flag, this causes dpc_thread to exit and clean up
itself. When kthread_stop is called for final cleanup, this causes use
after free.

Remove UNLOADING signal to terminate dpc_thread.  Use the kthread_stop
as the main signal to exit dpc_thread.

[596663.812935] kernel BUG at mm/slub.c:294!
[596663.812950] invalid opcode: 0000 [#1] SMP PTI
[596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G          IOE    --------- -  - 4.18.0-240.el8.x86_64 #1
[596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012
[596663.812974] RIP: 0010:__slab_free+0x17d/0x360

...
[596663.813008] Call Trace:
[596663.813022]  ? __dentry_kill+0x121/0x170
[596663.813030]  ? _cond_resched+0x15/0x30
[596663.813034]  ? _cond_resched+0x15/0x30
[596663.813039]  ? wait_for_completion+0x35/0x190
[596663.813048]  ? try_to_wake_up+0x63/0x540
[596663.813055]  free_task+0x5a/0x60
[596663.813061]  kthread_stop+0xf3/0x100
[596663.813103]  qla2x00_remove_one+0x284/0x440 [qla2xxx]</Note>
    </Notes>
    <CVE>CVE-2024-56623</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

can: dev: can_set_termination(): allow sleeping GPIOs

In commit 6e86a1543c37 ("can: dev: provide optional GPIO based
termination support") GPIO based termination support was added.

For no particular reason that patch uses gpiod_set_value() to set the
GPIO. This leads to the following warning, if the systems uses a
sleeping GPIO, i.e. behind an I2C port expander:

| WARNING: CPU: 0 PID: 379 at /drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x50/0x6c
| CPU: 0 UID: 0 PID: 379 Comm: ip Not tainted 6.11.0-20241016-1 #1 823affae360cc91126e4d316d7a614a8bf86236c

Replace gpiod_set_value() by gpiod_set_value_cansleep() to allow the
use of sleeping GPIOs.</Note>
    </Notes>
    <CVE>CVE-2024-56625</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

HID: wacom: fix when get product name maybe null pointer

Due to incorrect dev-&gt;product reporting by certain devices, null
pointer dereferences occur when dev-&gt;product is empty, leading to
potential system crashes.

This issue was found on EXCELSIOR DL37-D05 device with
Loongson-LS3A6000-7A2000-DL37 motherboard.

Kernel logs:
[   56.470885] usb 4-3: new full-speed USB device number 4 using ohci-pci
[   56.671638] usb 4-3: string descriptor 0 read error: -22
[   56.671644] usb 4-3: New USB device found, idVendor=056a, idProduct=0374, bcdDevice= 1.07
[   56.671647] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   56.678839] hid-generic 0003:056A:0374.0004: hiddev0,hidraw3: USB HID v1.10 Device [HID 056a:0374] on usb-0000:00:05.0-3/input0
[   56.697719] CPU 2 Unable to handle kernel paging request at virtual address 0000000000000000, era == 90000000066e35c8, ra == ffff800004f98a80
[   56.697732] Oops[#1]:
[   56.697734] CPU: 2 PID: 2742 Comm: (udev-worker) Tainted: G           OE      6.6.0-loong64-desktop #25.00.2000.015
[   56.697737] Hardware name: Inspur CE520L2/C09901N000000000, BIOS 2.09.00 10/11/2024
[   56.697739] pc 90000000066e35c8 ra ffff800004f98a80 tp 9000000125478000 sp 900000012547b8a0
[   56.697741] a0 0000000000000000 a1 ffff800004818b28 a2 0000000000000000 a3 0000000000000000
[   56.697743] a4 900000012547b8f0 a5 0000000000000000 a6 0000000000000000 a7 0000000000000000
[   56.697745] t0 ffff800004818b2d t1 0000000000000000 t2 0000000000000003 t3 0000000000000005
[   56.697747] t4 0000000000000000 t5 0000000000000000 t6 0000000000000000 t7 0000000000000000
[   56.697748] t8 0000000000000000 u0 0000000000000000 s9 0000000000000000 s0 900000011aa48028
[   56.697750] s1 0000000000000000 s2 0000000000000000 s3 ffff800004818e80 s4 ffff800004810000
[   56.697751] s5 90000001000b98d0 s6 ffff800004811f88 s7 ffff800005470440 s8 0000000000000000
[   56.697753]    ra: ffff800004f98a80 wacom_update_name+0xe0/0x300 [wacom]
[   56.697802]   ERA: 90000000066e35c8 strstr+0x28/0x120
[   56.697806]  CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
[   56.697816]  PRMD: 0000000c (PPLV0 +PIE +PWE)
[   56.697821]  EUEN: 00000000 (-FPE -SXE -ASXE -BTE)
[   56.697827]  ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
[   56.697831] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
[   56.697835]  BADV: 0000000000000000
[   56.697836]  PRID: 0014d000 (Loongson-64bit, Loongson-3A6000)
[   56.697838] Modules linked in: wacom(+) bnep bluetooth rfkill qrtr nls_iso8859_1 nls_cp437 snd_hda_codec_conexant snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore input_leds mousedev led_class joydev deepin_netmonitor(OE) fuse nfnetlink dmi_sysfs ip_tables x_tables overlay amdgpu amdxcp drm_exec gpu_sched drm_buddy radeon drm_suballoc_helper i2c_algo_bit drm_ttm_helper r8169 ttm drm_display_helper spi_loongson_pci xhci_pci cec xhci_pci_renesas spi_loongson_core hid_generic realtek gpio_loongson_64bit
[   56.697887] Process (udev-worker) (pid: 2742, threadinfo=00000000aee0d8b4, task=00000000a9eff1f3)
[   56.697890] Stack : 0000000000000000 ffff800004817e00 0000000000000000 0000251c00000000
[   56.697896]         0000000000000000 00000011fffffffd 0000000000000000 0000000000000000
[   56.697901]         0000000000000000 1b67a968695184b9 0000000000000000 90000001000b98d0
[   56.697906]         90000001000bb8d0 900000011aa48028 0000000000000000 ffff800004f9d74c
[   56.697911]         90000001000ba000 ffff800004f9ce58 0000000000000000 ffff800005470440
[   56.697916]         ffff800004811f88 90000001000b98d0 9000000100da2aa8 90000001000bb8d0
[   56.697921]         0000000000000000 90000001000ba000 900000011aa48028 ffff800004f9d74c
[   56.697926]         ffff8000054704e8 90000001000bb8b8 90000001000ba000 0000000000000000
[   56.697931]         90000001000bb8d0 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-56629</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: free inode when ocfs2_get_init_inode() fails

syzbot is reporting busy inodes after unmount, for commit 9c89fe0af826
("ocfs2: Handle error from dquot_initialize()") forgot to call iput() when
new_inode() succeeded and dquot_initialize() failed.</Note>
    </Notes>
    <CVE>CVE-2024-56630</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: sg: Fix slab-use-after-free read in sg_release()

Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN:

BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30
kernel/locking/lockdep.c:5838
__mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912
sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407

In sg_release(), the function kref_put(&amp;sfp-&gt;f_ref, sg_remove_sfp) is
called before releasing the open_rel_lock mutex. The kref_put() call may
decrement the reference count of sfp to zero, triggering its cleanup
through sg_remove_sfp(). This cleanup includes scheduling deferred work
via sg_remove_sfp_usercontext(), which ultimately frees sfp.

After kref_put(), sg_release() continues to unlock open_rel_lock and may
reference sfp or sdp. If sfp has already been freed, this results in a
slab-use-after-free error.

Move the kref_put(&amp;sfp-&gt;f_ref, sg_remove_sfp) call after unlocking the
open_rel_lock mutex. This ensures:

 - No references to sfp or sdp occur after the reference count is
   decremented.

 - Cleanup functions such as sg_remove_sfp() and
   sg_remove_sfp_usercontext() can safely execute without impacting the
   mutex handling in sg_release().

The fix has been tested and validated by syzbot. This patch closes the
bug reported at the following syzkaller link and ensures proper
sequencing of resource cleanup and mutex operations, eliminating the
risk of use-after-free errors in sg_release().</Note>
    </Notes>
    <CVE>CVE-2024-56631</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nvme-tcp: fix the memleak while create new ctrl failed

Now while we create new ctrl failed, we have not free the
tagset occupied by admin_q, here try to fix it.</Note>
    </Notes>
    <CVE>CVE-2024-56632</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsg

The current sk memory accounting logic in __SK_REDIRECT is pre-uncharging
tosend bytes, which is either msg-&gt;sg.size or a smaller value apply_bytes.

Potential problems with this strategy are as follows:

- If the actual sent bytes are smaller than tosend, we need to charge some
  bytes back, as in line 487, which is okay but seems not clean.

- When tosend is set to apply_bytes, as in line 417, and (ret &lt; 0), we may
  miss uncharging (msg-&gt;sg.size - apply_bytes) bytes.

[...]
415 tosend = msg-&gt;sg.size;
416 if (psock-&gt;apply_bytes &amp;&amp; psock-&gt;apply_bytes &lt; tosend)
417   tosend = psock-&gt;apply_bytes;
[...]
443 sk_msg_return(sk, msg, tosend);
444 release_sock(sk);
446 origsize = msg-&gt;sg.size;
447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress,
448                             msg, tosend, flags);
449 sent = origsize - msg-&gt;sg.size;
[...]
454 lock_sock(sk);
455 if (unlikely(ret &lt; 0)) {
456   int free = sk_msg_free_nocharge(sk, msg);
458   if (!cork)
459     *copied -= free;
460 }
[...]
487 if (eval == __SK_REDIRECT)
488   sk_mem_charge(sk, tosend - sent);
[...]

When running the selftest test_txmsg_redir_wait_sndmem with txmsg_apply,
the following warning will be reported:

------------[ cut here ]------------
WARNING: CPU: 6 PID: 57 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x190/0x1a0
Modules linked in:
CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ #43
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
Workqueue: events sk_psock_destroy
RIP: 0010:inet_sock_destruct+0x190/0x1a0
RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206
RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800
RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900
RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0
R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400
R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100
FS:  0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
&lt;TASK&gt;
? __warn+0x89/0x130
? inet_sock_destruct+0x190/0x1a0
? report_bug+0xfc/0x1e0
? handle_bug+0x5c/0xa0
? exc_invalid_op+0x17/0x70
? asm_exc_invalid_op+0x1a/0x20
? inet_sock_destruct+0x190/0x1a0
__sk_destruct+0x25/0x220
sk_psock_destroy+0x2b2/0x310
process_scheduled_works+0xa3/0x3e0
worker_thread+0x117/0x240
? __pfx_worker_thread+0x10/0x10
kthread+0xcf/0x100
? __pfx_kthread+0x10/0x10
ret_from_fork+0x31/0x40
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
&lt;/TASK&gt;
---[ end trace 0000000000000000 ]---

In __SK_REDIRECT, a more concise way is delaying the uncharging after sent
bytes are finalized, and uncharge this value. When (ret &lt; 0), we shall
invoke sk_msg_free.

Same thing happens in case __SK_DROP, when tosend is set to apply_bytes,
we may miss uncharging (msg-&gt;sg.size - apply_bytes) bytes. The same
warning will be reported in selftest.

[...]
468 case __SK_DROP:
469 default:
470 sk_msg_free_partial(sk, msg, tosend);
471 sk_msg_apply_bytes(psock, tosend);
472 *copied -= (tosend + delta);
473 return -EACCES;
[...]

So instead of sk_msg_free_partial we can do sk_msg_free here.</Note>
    </Notes>
    <CVE>CVE-2024-56633</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gpio: grgpio: Add NULL check in grgpio_probe

devm_kasprintf() can return a NULL pointer on failure,but this
returned value in grgpio_probe is not checked.
Add NULL check in grgpio_probe, to handle kernel NULL
pointer dereference error.</Note>
    </Notes>
    <CVE>CVE-2024-56634</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: avoid potential UAF in default_operstate()

syzbot reported an UAF in default_operstate() [1]

Issue is a race between device and netns dismantles.

After calling __rtnl_unlock() from netdev_run_todo(),
we can not assume the netns of each device is still alive.

Make sure the device is not in NETREG_UNREGISTERED state,
and add an ASSERT_RTNL() before the call to
__dev_get_by_index().

We might move this ASSERT_RTNL() in __dev_get_by_index()
in the future.

[1]

BUG: KASAN: slab-use-after-free in __dev_get_by_index+0x5d/0x110 net/core/dev.c:852
Read of size 8 at addr ffff888043eba1b0 by task syz.0.0/5339

CPU: 0 UID: 0 PID: 5339 Comm: syz.0.0 Not tainted 6.12.0-syzkaller-10296-gaaf20f870da0 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Call Trace:
 &lt;TASK&gt;
  __dump_stack lib/dump_stack.c:94 [inline]
  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
  print_address_description mm/kasan/report.c:378 [inline]
  print_report+0x169/0x550 mm/kasan/report.c:489
  kasan_report+0x143/0x180 mm/kasan/report.c:602
  __dev_get_by_index+0x5d/0x110 net/core/dev.c:852
  default_operstate net/core/link_watch.c:51 [inline]
  rfc2863_policy+0x224/0x300 net/core/link_watch.c:67
  linkwatch_do_dev+0x3e/0x170 net/core/link_watch.c:170
  netdev_run_todo+0x461/0x1000 net/core/dev.c:10894
  rtnl_unlock net/core/rtnetlink.c:152 [inline]
  rtnl_net_unlock include/linux/rtnetlink.h:133 [inline]
  rtnl_dellink+0x760/0x8d0 net/core/rtnetlink.c:3520
  rtnetlink_rcv_msg+0x791/0xcf0 net/core/rtnetlink.c:6911
  netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2541
  netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline]
  netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1347
  netlink_sendmsg+0x8e4/0xcb0 net/netlink/af_netlink.c:1891
  sock_sendmsg_nosec net/socket.c:711 [inline]
  __sock_sendmsg+0x221/0x270 net/socket.c:726
  ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2583
  ___sys_sendmsg net/socket.c:2637 [inline]
  __sys_sendmsg+0x269/0x350 net/socket.c:2669
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f2a3cb80809
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f2a3d9cd058 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f2a3cd45fa0 RCX: 00007f2a3cb80809
RDX: 0000000000000000 RSI: 0000000020000000 RDI: 0000000000000008
RBP: 00007f2a3cbf393e R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f2a3cd45fa0 R15: 00007ffd03bc65c8
 &lt;/TASK&gt;

Allocated by task 5339:
  kasan_save_stack mm/kasan/common.c:47 [inline]
  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
  poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
  __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394
  kasan_kmalloc include/linux/kasan.h:260 [inline]
  __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4314
  kmalloc_noprof include/linux/slab.h:901 [inline]
  kmalloc_array_noprof include/linux/slab.h:945 [inline]
  netdev_create_hash net/core/dev.c:11870 [inline]
  netdev_init+0x10c/0x250 net/core/dev.c:11890
  ops_init+0x31e/0x590 net/core/net_namespace.c:138
  setup_net+0x287/0x9e0 net/core/net_namespace.c:362
  copy_net_ns+0x33f/0x570 net/core/net_namespace.c:500
  create_new_namespaces+0x425/0x7b0 kernel/nsproxy.c:110
  unshare_nsproxy_namespaces+0x124/0x180 kernel/nsproxy.c:228
  ksys_unshare+0x57d/0xa70 kernel/fork.c:3314
  __do_sys_unshare kernel/fork.c:3385 [inline]
  __se_sys_unshare kernel/fork.c:3383 [inline]
  __x64_sys_unshare+0x38/0x40 kernel/fork.c:3383
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xf3/0x230 arch/x8
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-56635</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

geneve: do not assume mac header is set in geneve_xmit_skb()

We should not assume mac header is set in output path.

Use skb_eth_hdr() instead of eth_hdr() to fix the issue.

sysbot reported the following :

 WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 skb_mac_header include/linux/skbuff.h:3052 [inline]
 WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 eth_hdr include/linux/if_ether.h:24 [inline]
 WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit_skb drivers/net/geneve.c:898 [inline]
 WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039
Modules linked in:
CPU: 0 UID: 0 PID: 11635 Comm: syz.4.1423 Not tainted 6.12.0-syzkaller-10296-gaaf20f870da0 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
 RIP: 0010:skb_mac_header include/linux/skbuff.h:3052 [inline]
 RIP: 0010:eth_hdr include/linux/if_ether.h:24 [inline]
 RIP: 0010:geneve_xmit_skb drivers/net/geneve.c:898 [inline]
 RIP: 0010:geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039
Code: 21 c6 02 e9 35 d4 ff ff e8 a5 48 4c fb 90 0f 0b 90 e9 fd f5 ff ff e8 97 48 4c fb 90 0f 0b 90 e9 d8 f5 ff ff e8 89 48 4c fb 90 &lt;0f&gt; 0b 90 e9 41 e4 ff ff e8 7b 48 4c fb 90 0f 0b 90 e9 cd e7 ff ff
RSP: 0018:ffffc90003b2f870 EFLAGS: 00010283
RAX: 000000000000037a RBX: 000000000000ffff RCX: ffffc9000dc3d000
RDX: 0000000000080000 RSI: ffffffff86428417 RDI: 0000000000000003
RBP: ffffc90003b2f9f0 R08: 0000000000000003 R09: 000000000000ffff
R10: 000000000000ffff R11: 0000000000000002 R12: ffff88806603c000
R13: 0000000000000000 R14: ffff8880685b2780 R15: 0000000000000e23
FS:  00007fdc2deed6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b30a1dff8 CR3: 0000000056b8c000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
  __netdev_start_xmit include/linux/netdevice.h:5002 [inline]
  netdev_start_xmit include/linux/netdevice.h:5011 [inline]
  __dev_direct_xmit+0x58a/0x720 net/core/dev.c:4490
  dev_direct_xmit include/linux/netdevice.h:3181 [inline]
  packet_xmit+0x1e4/0x360 net/packet/af_packet.c:285
  packet_snd net/packet/af_packet.c:3146 [inline]
  packet_sendmsg+0x2700/0x5660 net/packet/af_packet.c:3178
  sock_sendmsg_nosec net/socket.c:711 [inline]
  __sock_sendmsg net/socket.c:726 [inline]
  __sys_sendto+0x488/0x4f0 net/socket.c:2197
  __do_sys_sendto net/socket.c:2204 [inline]
  __se_sys_sendto net/socket.c:2200 [inline]
  __x64_sys_sendto+0xe0/0x1c0 net/socket.c:2200
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f</Note>
    </Notes>
    <CVE>CVE-2024-56636</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: ipset: Hold module reference while requesting a module

User space may unload ip_set.ko while it is itself requesting a set type
backend module, leading to a kernel crash. The race condition may be
provoked by inserting an mdelay() right after the nfnl_unlock() call.</Note>
    </Notes>
    <CVE>CVE-2024-56637</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/smc: initialize close_work early to avoid warning

We encountered a warning that close_work was canceled before
initialization.

  WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 __flush_work+0x19e/0x1b0
  Workqueue: events smc_lgr_terminate_work [smc]
  RIP: 0010:__flush_work+0x19e/0x1b0
  Call Trace:
   ? __wake_up_common+0x7a/0x190
   ? work_busy+0x80/0x80
   __cancel_work_timer+0xe3/0x160
   smc_close_cancel_work+0x1a/0x70 [smc]
   smc_close_active_abort+0x207/0x360 [smc]
   __smc_lgr_terminate.part.38+0xc8/0x180 [smc]
   process_one_work+0x19e/0x340
   worker_thread+0x30/0x370
   ? process_one_work+0x340/0x340
   kthread+0x117/0x130
   ? __kthread_cancel_work+0x50/0x50
   ret_from_fork+0x22/0x30

This is because when smc_close_cancel_work is triggered, e.g. the RDMA
driver is rmmod and the LGR is terminated, the conn-&gt;close_work is
flushed before initialization, resulting in WARN_ON(!work-&gt;func).

__smc_lgr_terminate             | smc_connect_{rdma|ism}
-------------------------------------------------------------
                                | smc_conn_create
				| \- smc_lgr_register_conn
for conn in lgr-&gt;conns_all      |
\- smc_conn_kill                |
   \- smc_close_active_abort    |
      \- smc_close_cancel_work  |
         \- cancel_work_sync    |
            \- __flush_work     |
	         (close_work)   |
	                        | smc_close_init
	                        | \- INIT_WORK(&amp;close_work)

So fix this by initializing close_work before establishing the
connection.</Note>
    </Notes>
    <CVE>CVE-2024-56641</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tipc: Fix use-after-free of kernel socket in cleanup_bearer().

syzkaller reported a use-after-free of UDP kernel socket
in cleanup_bearer() without repro. [0][1]

When bearer_disable() calls tipc_udp_disable(), cleanup
of the UDP kernel socket is deferred by work calling
cleanup_bearer().

tipc_exit_net() waits for such works to finish by checking
tipc_net(net)-&gt;wq_count.  However, the work decrements the
count too early before releasing the kernel socket,
unblocking cleanup_net() and resulting in use-after-free.

Let's move the decrement after releasing the socket in
cleanup_bearer().

[0]:
ref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at
     sk_alloc+0x438/0x608
     inet_create+0x4c8/0xcb0
     __sock_create+0x350/0x6b8
     sock_create_kern+0x58/0x78
     udp_sock_create4+0x68/0x398
     udp_sock_create+0x88/0xc8
     tipc_udp_enable+0x5e8/0x848
     __tipc_nl_bearer_enable+0x84c/0xed8
     tipc_nl_bearer_enable+0x38/0x60
     genl_family_rcv_msg_doit+0x170/0x248
     genl_rcv_msg+0x400/0x5b0
     netlink_rcv_skb+0x1dc/0x398
     genl_rcv+0x44/0x68
     netlink_unicast+0x678/0x8b0
     netlink_sendmsg+0x5e4/0x898
     ____sys_sendmsg+0x500/0x830

[1]:
BUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline]
BUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979
 udp_hashslot include/net/udp.h:85 [inline]
 udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979
 sk_common_release+0xaf/0x3f0 net/core/sock.c:3820
 inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437
 inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489
 __sock_release net/socket.c:658 [inline]
 sock_release+0xa0/0x210 net/socket.c:686
 cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819
 process_one_work kernel/workqueue.c:3229 [inline]
 process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310
 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391
 kthread+0x531/0x6b0 kernel/kthread.c:389
 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244

Uninit was created at:
 slab_free_hook mm/slub.c:2269 [inline]
 slab_free mm/slub.c:4580 [inline]
 kmem_cache_free+0x207/0xc40 mm/slub.c:4682
 net_free net/core/net_namespace.c:454 [inline]
 cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647
 process_one_work kernel/workqueue.c:3229 [inline]
 process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310
 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391
 kthread+0x531/0x6b0 kernel/kthread.c:389
 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244

CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
Workqueue: events cleanup_bearer</Note>
    </Notes>
    <CVE>CVE-2024-56642</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dccp: Fix memory leak in dccp_feat_change_recv

If dccp_feat_push_confirm() fails after new value for SP feature was accepted
without reconciliation ('entry == NULL' branch), memory allocated for that value
with dccp_feat_clone_sp_val() is never freed.

Here is the kmemleak stack for this:

unreferenced object 0xffff88801d4ab488 (size 8):
  comm "syz-executor310", pid 1127, jiffies 4295085598 (age 41.666s)
  hex dump (first 8 bytes):
    01 b4 4a 1d 80 88 ff ff                          ..J.....
  backtrace:
    [&lt;00000000db7cabfe&gt;] kmemdup+0x23/0x50 mm/util.c:128
    [&lt;0000000019b38405&gt;] kmemdup include/linux/string.h:465 [inline]
    [&lt;0000000019b38405&gt;] dccp_feat_clone_sp_val net/dccp/feat.c:371 [inline]
    [&lt;0000000019b38405&gt;] dccp_feat_clone_sp_val net/dccp/feat.c:367 [inline]
    [&lt;0000000019b38405&gt;] dccp_feat_change_recv net/dccp/feat.c:1145 [inline]
    [&lt;0000000019b38405&gt;] dccp_feat_parse_options+0x1196/0x2180 net/dccp/feat.c:1416
    [&lt;00000000b1f6d94a&gt;] dccp_parse_options+0xa2a/0x1260 net/dccp/options.c:125
    [&lt;0000000030d7b621&gt;] dccp_rcv_state_process+0x197/0x13d0 net/dccp/input.c:650
    [&lt;000000001f74c72e&gt;] dccp_v4_do_rcv+0xf9/0x1a0 net/dccp/ipv4.c:688
    [&lt;00000000a6c24128&gt;] sk_backlog_rcv include/net/sock.h:1041 [inline]
    [&lt;00000000a6c24128&gt;] __release_sock+0x139/0x3b0 net/core/sock.c:2570
    [&lt;00000000cf1f3a53&gt;] release_sock+0x54/0x1b0 net/core/sock.c:3111
    [&lt;000000008422fa23&gt;] inet_wait_for_connect net/ipv4/af_inet.c:603 [inline]
    [&lt;000000008422fa23&gt;] __inet_stream_connect+0x5d0/0xf70 net/ipv4/af_inet.c:696
    [&lt;0000000015b6f64d&gt;] inet_stream_connect+0x53/0xa0 net/ipv4/af_inet.c:735
    [&lt;0000000010122488&gt;] __sys_connect_file+0x15c/0x1a0 net/socket.c:1865
    [&lt;00000000b4b70023&gt;] __sys_connect+0x165/0x1a0 net/socket.c:1882
    [&lt;00000000f4cb3815&gt;] __do_sys_connect net/socket.c:1892 [inline]
    [&lt;00000000f4cb3815&gt;] __se_sys_connect net/socket.c:1889 [inline]
    [&lt;00000000f4cb3815&gt;] __x64_sys_connect+0x6e/0xb0 net/socket.c:1889
    [&lt;00000000e7b1e839&gt;] do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
    [&lt;0000000055e91434&gt;] entry_SYSCALL_64_after_hwframe+0x67/0xd1

Clean up the allocated memory in case of dccp_feat_push_confirm() failure
and bail out with an error reset code.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.</Note>
    </Notes>
    <CVE>CVE-2024-56643</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/ipv6: release expired exception dst cached in socket

Dst objects get leaked in ip6_negative_advice() when this function is
executed for an expired IPv6 route located in the exception table. There
are several conditions that must be fulfilled for the leak to occur:
* an ICMPv6 packet indicating a change of the MTU for the path is received,
  resulting in an exception dst being created
* a TCP connection that uses the exception dst for routing packets must
  start timing out so that TCP begins retransmissions
* after the exception dst expires, the FIB6 garbage collector must not run
  before TCP executes ip6_negative_advice() for the expired exception dst

When TCP executes ip6_negative_advice() for an exception dst that has
expired and if no other socket holds a reference to the exception dst, the
refcount of the exception dst is 2, which corresponds to the increment
made by dst_init() and the increment made by the TCP socket for which the
connection is timing out. The refcount made by the socket is never
released. The refcount of the dst is decremented in sk_dst_reset() but
that decrement is counteracted by a dst_hold() intentionally placed just
before the sk_dst_reset() in ip6_negative_advice(). After
ip6_negative_advice() has finished, there is no other object tied to the
dst. The socket lost its reference stored in sk_dst_cache and the dst is
no longer in the exception table. The exception dst becomes a leaked
object.

As a result of this dst leak, an unbalanced refcount is reported for the
loopback device of a net namespace being destroyed under kernels that do
not contain e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"):
unregister_netdevice: waiting for lo to become free. Usage count = 2

Fix the dst leak by removing the dst_hold() in ip6_negative_advice(). The
patch that introduced the dst_hold() in ip6_negative_advice() was
92f1655aa2b22 ("net: fix __dst_negative_advice() race"). But 92f1655aa2b22
merely refactored the code with regards to the dst refcount so the issue
was present even before 92f1655aa2b22. The bug was introduced in
54c1a859efd9f ("ipv6: Don't drop cache route entry unless timer actually
expired.") where the expired cached route is deleted and the sk_dst_cache
member of the socket is set to NULL by calling dst_negative_advice() but
the refcount belonging to the socket is left unbalanced.

The IPv4 version - ipv4_negative_advice() - is not affected by this bug.
When the TCP connection times out ipv4_negative_advice() merely resets the
sk_dst_cache of the socket while decrementing the refcount of the
exception dst.</Note>
    </Notes>
    <CVE>CVE-2024-56644</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: Fix icmp host relookup triggering ip_rt_bug

arp link failure may trigger ip_rt_bug while xfrm enabled, call trace is:

WARNING: CPU: 0 PID: 0 at net/ipv4/route.c:1241 ip_rt_bug+0x14/0x20
Modules linked in:
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc6-00077-g2e1b3cc9d7f7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:ip_rt_bug+0x14/0x20
Call Trace:
 &lt;IRQ&gt;
 ip_send_skb+0x14/0x40
 __icmp_send+0x42d/0x6a0
 ipv4_link_failure+0xe2/0x1d0
 arp_error_report+0x3c/0x50
 neigh_invalidate+0x8d/0x100
 neigh_timer_handler+0x2e1/0x330
 call_timer_fn+0x21/0x120
 __run_timer_base.part.0+0x1c9/0x270
 run_timer_softirq+0x4c/0x80
 handle_softirqs+0xac/0x280
 irq_exit_rcu+0x62/0x80
 sysvec_apic_timer_interrupt+0x77/0x90

The script below reproduces this scenario:
ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 \
	dir out priority 0 ptype main flag localok icmp
ip l a veth1 type veth
ip a a 192.168.141.111/24 dev veth0
ip l s veth0 up
ping 192.168.141.155 -c 1

icmp_route_lookup() create input routes for locally generated packets
while xfrm relookup ICMP traffic.Then it will set input route
(dst-&gt;out = ip_rt_bug) to skb for DESTUNREACH.

For ICMP err triggered by locally generated packets, dst-&gt;dev of output
route is loopback. Generally, xfrm relookup verification is not required
on loopback interfaces (net.ipv4.conf.lo.disable_xfrm = 1).

Skip icmp relookup for locally generated packets to fix it.</Note>
    </Notes>
    <CVE>CVE-2024-56647</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: hsr: avoid potential out-of-bound access in fill_frame_info()

syzbot is able to feed a packet with 14 bytes, pretending
it is a vlan one.

Since fill_frame_info() is relying on skb-&gt;mac_len already,
extend the check to cover this case.

BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline]
 BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724
  fill_frame_info net/hsr/hsr_forward.c:709 [inline]
  hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724
  hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235
  __netdev_start_xmit include/linux/netdevice.h:5002 [inline]
  netdev_start_xmit include/linux/netdevice.h:5011 [inline]
  xmit_one net/core/dev.c:3590 [inline]
  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606
  __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434
  dev_queue_xmit include/linux/netdevice.h:3168 [inline]
  packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276
  packet_snd net/packet/af_packet.c:3146 [inline]
  packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178
  sock_sendmsg_nosec net/socket.c:711 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:726
  __sys_sendto+0x594/0x750 net/socket.c:2197
  __do_sys_sendto net/socket.c:2204 [inline]
  __se_sys_sendto net/socket.c:2200 [inline]
  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200
  x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Uninit was created at:
  slab_post_alloc_hook mm/slub.c:4091 [inline]
  slab_alloc_node mm/slub.c:4134 [inline]
  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186
  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587
  __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678
  alloc_skb include/linux/skbuff.h:1323 [inline]
  alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612
  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881
  packet_alloc_skb net/packet/af_packet.c:2995 [inline]
  packet_snd net/packet/af_packet.c:3089 [inline]
  packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178
  sock_sendmsg_nosec net/socket.c:711 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:726
  __sys_sendto+0x594/0x750 net/socket.c:2197
  __do_sys_sendto net/socket.c:2204 [inline]
  __se_sys_sendto net/socket.c:2200 [inline]
  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200
  x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f</Note>
    </Notes>
    <CVE>CVE-2024-56648</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: enetc: Do not configure preemptible TCs if SIs do not support

Both ENETC PF and VF drivers share enetc_setup_tc_mqprio() to configure
MQPRIO. And enetc_setup_tc_mqprio() calls enetc_change_preemptible_tcs()
to configure preemptible TCs. However, only PF is able to configure
preemptible TCs. Because only PF has related registers, while VF does not
have these registers. So for VF, its hw-&gt;port pointer is NULL. Therefore,
VF will access an invalid pointer when accessing a non-existent register,
which will cause a crash issue. The simplified log is as follows.

root@ls1028ardb:~# tc qdisc add dev eno0vf0 parent root handle 100: \
mqprio num_tc 4 map 0 0 1 1 2 2 3 3 queues 1@0 1@1 1@2 1@3 hw 1
[  187.290775] Unable to handle kernel paging request at virtual address 0000000000001f00
[  187.424831] pc : enetc_mm_commit_preemptible_tcs+0x1c4/0x400
[  187.430518] lr : enetc_mm_commit_preemptible_tcs+0x30c/0x400
[  187.511140] Call trace:
[  187.513588]  enetc_mm_commit_preemptible_tcs+0x1c4/0x400
[  187.518918]  enetc_setup_tc_mqprio+0x180/0x214
[  187.523374]  enetc_vf_setup_tc+0x1c/0x30
[  187.527306]  mqprio_enable_offload+0x144/0x178
[  187.531766]  mqprio_init+0x3ec/0x668
[  187.535351]  qdisc_create+0x15c/0x488
[  187.539023]  tc_modify_qdisc+0x398/0x73c
[  187.542958]  rtnetlink_rcv_msg+0x128/0x378
[  187.547064]  netlink_rcv_skb+0x60/0x130
[  187.550910]  rtnetlink_rcv+0x18/0x24
[  187.554492]  netlink_unicast+0x300/0x36c
[  187.558425]  netlink_sendmsg+0x1a8/0x420
[  187.606759] ---[ end trace 0000000000000000 ]---

In addition, some PFs also do not support configuring preemptible TCs,
such as eno1 and eno3 on LS1028A. It won't crash like it does for VFs,
but we should prevent these PFs from accessing these unimplemented
registers.</Note>
    </Notes>
    <CVE>CVE-2024-56649</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: x_tables: fix LED ID check in led_tg_check()

Syzbot has reported the following BUG detected by KASAN:

BUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70
Read of size 1 at addr ffff8881022da0c8 by task repro/5879
...
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x241/0x360
 ? __pfx_dump_stack_lvl+0x10/0x10
 ? __pfx__printk+0x10/0x10
 ? _printk+0xd5/0x120
 ? __virt_addr_valid+0x183/0x530
 ? __virt_addr_valid+0x183/0x530
 print_report+0x169/0x550
 ? __virt_addr_valid+0x183/0x530
 ? __virt_addr_valid+0x183/0x530
 ? __virt_addr_valid+0x45f/0x530
 ? __phys_addr+0xba/0x170
 ? strlen+0x58/0x70
 kasan_report+0x143/0x180
 ? strlen+0x58/0x70
 strlen+0x58/0x70
 kstrdup+0x20/0x80
 led_tg_check+0x18b/0x3c0
 xt_check_target+0x3bb/0xa40
 ? __pfx_xt_check_target+0x10/0x10
 ? stack_depot_save_flags+0x6e4/0x830
 ? nft_target_init+0x174/0xc30
 nft_target_init+0x82d/0xc30
 ? __pfx_nft_target_init+0x10/0x10
 ? nf_tables_newrule+0x1609/0x2980
 ? nf_tables_newrule+0x1609/0x2980
 ? rcu_is_watching+0x15/0xb0
 ? nf_tables_newrule+0x1609/0x2980
 ? nf_tables_newrule+0x1609/0x2980
 ? __kmalloc_noprof+0x21a/0x400
 nf_tables_newrule+0x1860/0x2980
 ? __pfx_nf_tables_newrule+0x10/0x10
 ? __nla_parse+0x40/0x60
 nfnetlink_rcv+0x14e5/0x2ab0
 ? __pfx_validate_chain+0x10/0x10
 ? __pfx_nfnetlink_rcv+0x10/0x10
 ? __lock_acquire+0x1384/0x2050
 ? netlink_deliver_tap+0x2e/0x1b0
 ? __pfx_lock_release+0x10/0x10
 ? netlink_deliver_tap+0x2e/0x1b0
 netlink_unicast+0x7f8/0x990
 ? __pfx_netlink_unicast+0x10/0x10
 ? __virt_addr_valid+0x183/0x530
 ? __check_object_size+0x48e/0x900
 netlink_sendmsg+0x8e4/0xcb0
 ? __pfx_netlink_sendmsg+0x10/0x10
 ? aa_sock_msg_perm+0x91/0x160
 ? __pfx_netlink_sendmsg+0x10/0x10
 __sock_sendmsg+0x223/0x270
 ____sys_sendmsg+0x52a/0x7e0
 ? __pfx_____sys_sendmsg+0x10/0x10
 __sys_sendmsg+0x292/0x380
 ? __pfx___sys_sendmsg+0x10/0x10
 ? lockdep_hardirqs_on_prepare+0x43d/0x780
 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10
 ? exc_page_fault+0x590/0x8c0
 ? do_syscall_64+0xb6/0x230
 do_syscall_64+0xf3/0x230
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
...
 &lt;/TASK&gt;

Since an invalid (without '\0' byte at all) byte sequence may be passed
from userspace, add an extra check to ensure that such a sequence is
rejected as possible ID and so never passed to 'kstrdup()' and further.</Note>
    </Notes>
    <CVE>CVE-2024-56650</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

can: hi311x: hi3110_can_ist(): fix potential use-after-free

The commit a22bd630cfff ("can: hi311x: do not report txerr and rxerr
during bus-off") removed the reporting of rxerr and txerr even in case
of correct operation (i. e. not bus-off).

The error count information added to the CAN frame after netif_rx() is
a potential use after free, since there is no guarantee that the skb
is in the same state. It might be freed or reused.

Fix the issue by postponing the netif_rx() call in case of txerr and
rxerr reporting.</Note>
    </Notes>
    <CVE>CVE-2024-56651</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_event: Fix using rcu_read_(un)lock while iterating

The usage of rcu_read_(un)lock while inside list_for_each_entry_rcu is
not safe since for the most part entries fetched this way shall be
treated as rcu_dereference:

	Note that the value returned by rcu_dereference() is valid
	only within the enclosing RCU read-side critical section [1]_.
	For example, the following is **not** legal::

		rcu_read_lock();
		p = rcu_dereference(head.next);
		rcu_read_unlock();
		x = p-&gt;address;	/* BUG!!! */
		rcu_read_lock();
		y = p-&gt;data;	/* BUG!!! */
		rcu_read_unlock();</Note>
    </Notes>
    <CVE>CVE-2024-56654</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bnxt_en: Fix aggregation ID mask to prevent oops on 5760X chips

The 5760X (P7) chip's HW GRO/LRO interface is very similar to that of
the previous generation (5750X or P5).  However, the aggregation ID
fields in the completion structures on P7 have been redefined from
16 bits to 12 bits.  The freed up 4 bits are redefined for part of the
metadata such as the VLAN ID.  The aggregation ID mask was not modified
when adding support for P7 chips.  Including the extra 4 bits for the
aggregation ID can potentially cause the driver to store or fetch the
packet header of GRO/LRO packets in the wrong TPA buffer.  It may hit
the BUG() condition in __skb_pull() because the SKB contains no valid
packet header:

kernel BUG at include/linux/skbuff.h:2766!
Oops: invalid opcode: 0000 1 PREEMPT SMP NOPTI
CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Kdump: loaded Tainted: G           OE      6.12.0-rc2+ #7
Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Hardware name: Dell Inc. PowerEdge R760/0VRV9X, BIOS 1.0.1 12/27/2022
RIP: 0010:eth_type_trans+0xda/0x140
Code: 80 00 00 00 eb c1 8b 47 70 2b 47 74 48 8b 97 d0 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb a5 &lt;0f&gt; 0b b8 00 01 00 00 eb 9c 48 85 ff 74 eb 31 f6 b9 02 00 00 00 48
RSP: 0018:ff615003803fcc28 EFLAGS: 00010283
RAX: 00000000000022d2 RBX: 0000000000000003 RCX: ff2e8c25da334040
RDX: 0000000000000040 RSI: ff2e8c25c1ce8000 RDI: ff2e8c25869f9000
RBP: ff2e8c258c31c000 R08: ff2e8c25da334000 R09: 0000000000000001
R10: ff2e8c25da3342c0 R11: ff2e8c25c1ce89c0 R12: ff2e8c258e0990b0
R13: ff2e8c25bb120000 R14: ff2e8c25c1ce89c0 R15: ff2e8c25869f9000
FS:  0000000000000000(0000) GS:ff2e8c34be300000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055f05317e4c8 CR3: 000000108bac6006 CR4: 0000000000773ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 &lt;IRQ&gt;
 ? die+0x33/0x90
 ? do_trap+0xd9/0x100
 ? eth_type_trans+0xda/0x140
 ? do_error_trap+0x65/0x80
 ? eth_type_trans+0xda/0x140
 ? exc_invalid_op+0x4e/0x70
 ? eth_type_trans+0xda/0x140
 ? asm_exc_invalid_op+0x16/0x20
 ? eth_type_trans+0xda/0x140
 bnxt_tpa_end+0x10b/0x6b0 [bnxt_en]
 ? bnxt_tpa_start+0x195/0x320 [bnxt_en]
 bnxt_rx_pkt+0x902/0xd90 [bnxt_en]
 ? __bnxt_tx_int.constprop.0+0x89/0x300 [bnxt_en]
 ? kmem_cache_free+0x343/0x440
 ? __bnxt_tx_int.constprop.0+0x24f/0x300 [bnxt_en]
 __bnxt_poll_work+0x193/0x370 [bnxt_en]
 bnxt_poll_p5+0x9a/0x300 [bnxt_en]
 ? try_to_wake_up+0x209/0x670
 __napi_poll+0x29/0x1b0

Fix it by redefining the aggregation ID mask for P5_PLUS chips to be
12 bits.  This will work because the maximum aggregation ID is less
than 4096 on all P5_PLUS chips.</Note>
    </Notes>
    <CVE>CVE-2024-56656</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: defer final 'struct net' free in netns dismantle

Ilya reported a slab-use-after-free in dst_destroy [1]

Issue is in xfrm6_net_init() and xfrm4_net_init() :

They copy xfrm[46]_dst_ops_template into net-&gt;xfrm.xfrm[46]_dst_ops.

But net structure might be freed before all the dst callbacks are
called. So when dst_destroy() calls later :

if (dst-&gt;ops-&gt;destroy)
    dst-&gt;ops-&gt;destroy(dst);

dst-&gt;ops points to the old net-&gt;xfrm.xfrm[46]_dst_ops, which has been freed.

See a relevant issue fixed in :

ac888d58869b ("net: do not delay dst_entries_add() in dst_release()")

A fix is to queue the 'struct net' to be freed after one
another cleanup_net() round (and existing rcu_barrier())

[1]

BUG: KASAN: slab-use-after-free in dst_destroy (net/core/dst.c:112)
Read of size 8 at addr ffff8882137ccab0 by task swapper/37/0
Dec 03 05:46:18 kernel:
CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: loaded Not tainted 6.12.0 #67
Hardware name: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 04/01/2014
Call Trace:
 &lt;IRQ&gt;
dump_stack_lvl (lib/dump_stack.c:124)
print_address_description.constprop.0 (mm/kasan/report.c:378)
? dst_destroy (net/core/dst.c:112)
print_report (mm/kasan/report.c:489)
? dst_destroy (net/core/dst.c:112)
? kasan_addr_to_slab (mm/kasan/common.c:37)
kasan_report (mm/kasan/report.c:603)
? dst_destroy (net/core/dst.c:112)
? rcu_do_batch (kernel/rcu/tree.c:2567)
dst_destroy (net/core/dst.c:112)
rcu_do_batch (kernel/rcu/tree.c:2567)
? __pfx_rcu_do_batch (kernel/rcu/tree.c:2491)
? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4339 kernel/locking/lockdep.c:4406)
rcu_core (kernel/rcu/tree.c:2825)
handle_softirqs (kernel/softirq.c:554)
__irq_exit_rcu (kernel/softirq.c:589 kernel/softirq.c:428 kernel/softirq.c:637)
irq_exit_rcu (kernel/softirq.c:651)
sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049 arch/x86/kernel/apic/apic.c:1049)
 &lt;/IRQ&gt;
 &lt;TASK&gt;
asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:702)
RIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:743)
Code: 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 6e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 0f 00 2d c7 c9 27 00 fb f4 &lt;fa&gt; c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90
RSP: 0018:ffff888100d2fe00 EFLAGS: 00000246
RAX: 00000000001870ed RBX: 1ffff110201a5fc2 RCX: ffffffffb61a3e46
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb3d4d123
RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed11c7e1835d
R10: ffff888e3f0c1aeb R11: 0000000000000000 R12: 0000000000000000
R13: ffff888100d20000 R14: dffffc0000000000 R15: 0000000000000000
? ct_kernel_exit.constprop.0 (kernel/context_tracking.c:148)
? cpuidle_idle_call (kernel/sched/idle.c:186)
default_idle_call (./include/linux/cpuidle.h:143 kernel/sched/idle.c:118)
cpuidle_idle_call (kernel/sched/idle.c:186)
? __pfx_cpuidle_idle_call (kernel/sched/idle.c:168)
? lock_release (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5848)
? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4347 kernel/locking/lockdep.c:4406)
? tsc_verify_tsc_adjust (arch/x86/kernel/tsc_sync.c:59)
do_idle (kernel/sched/idle.c:326)
cpu_startup_entry (kernel/sched/idle.c:423 (discriminator 1))
start_secondary (arch/x86/kernel/smpboot.c:202 arch/x86/kernel/smpboot.c:282)
? __pfx_start_secondary (arch/x86/kernel/smpboot.c:232)
? soft_restart_cpu (arch/x86/kernel/head_64.S:452)
common_startup_64 (arch/x86/kernel/head_64.S:414)
 &lt;/TASK&gt;
Dec 03 05:46:18 kernel:
Allocated by task 12184:
kasan_save_stack (mm/kasan/common.c:48)
kasan_save_track (./arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69)
__kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345)
kmem_cache_alloc_noprof (mm/slub.c:4085 mm/slub.c:4134 mm/slub.c:4141)
copy_net_ns (net/core/net_namespace.c:421 net/core/net_namespace.c:480)
create_new_namespaces
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-56658</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: lapb: increase LAPB_HEADER_LEN

It is unclear if net/lapb code is supposed to be ready for 8021q.

We can at least avoid crashes like the following :

skbuff: skb_under_panic: text:ffffffff8aabe1f6 len:24 put:20 head:ffff88802824a400 data:ffff88802824a3fe tail:0x16 end:0x140 dev:nr0.2
------------[ cut here ]------------
 kernel BUG at net/core/skbuff.c:206 !
Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 1 UID: 0 PID: 5508 Comm: dhcpcd Not tainted 6.12.0-rc7-syzkaller-00144-g66418447d27b #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024
 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]
 RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216
Code: 0d 8d 48 c7 c6 2e 9e 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 1a 6f 37 02 48 83 c4 20 90 &lt;0f&gt; 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3
RSP: 0018:ffffc90002ddf638 EFLAGS: 00010282
RAX: 0000000000000086 RBX: dffffc0000000000 RCX: 7a24750e538ff600
RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000
RBP: ffff888034a86650 R08: ffffffff8174b13c R09: 1ffff920005bbe60
R10: dffffc0000000000 R11: fffff520005bbe61 R12: 0000000000000140
R13: ffff88802824a400 R14: ffff88802824a3fe R15: 0000000000000016
FS:  00007f2a5990d740(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000110c2631fd CR3: 0000000029504000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
  skb_push+0xe5/0x100 net/core/skbuff.c:2636
  nr_header+0x36/0x320 net/netrom/nr_dev.c:69
  dev_hard_header include/linux/netdevice.h:3148 [inline]
  vlan_dev_hard_header+0x359/0x480 net/8021q/vlan_dev.c:83
  dev_hard_header include/linux/netdevice.h:3148 [inline]
  lapbeth_data_transmit+0x1f6/0x2a0 drivers/net/wan/lapbether.c:257
  lapb_data_transmit+0x91/0xb0 net/lapb/lapb_iface.c:447
  lapb_transmit_buffer+0x168/0x1f0 net/lapb/lapb_out.c:149
 lapb_establish_data_link+0x84/0xd0
 lapb_device_event+0x4e0/0x670
  notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93
 __dev_notify_flags+0x207/0x400
  dev_change_flags+0xf0/0x1a0 net/core/dev.c:8922
  devinet_ioctl+0xa4e/0x1aa0 net/ipv4/devinet.c:1188
  inet_ioctl+0x3d7/0x4f0 net/ipv4/af_inet.c:1003
  sock_do_ioctl+0x158/0x460 net/socket.c:1227
  sock_ioctl+0x626/0x8e0 net/socket.c:1346
  vfs_ioctl fs/ioctl.c:51 [inline]
  __do_sys_ioctl fs/ioctl.c:907 [inline]
  __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83</Note>
    </Notes>
    <CVE>CVE-2024-56659</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: DR, prevent potential error pointer dereference

The dr_domain_add_vport_cap() function generally returns NULL on error
but sometimes we want it to return ERR_PTR(-EBUSY) so the caller can
retry.  The problem here is that "ret" can be either -EBUSY or -ENOMEM
and if it's and -ENOMEM then the error pointer is propogated back and
eventually dereferenced in dr_ste_v0_build_src_gvmi_qpn_tag().</Note>
    </Notes>
    <CVE>CVE-2024-56660</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl

Fix an issue detected by syzbot with KASAN:

BUG: KASAN: vmalloc-out-of-bounds in cmd_to_func drivers/acpi/nfit/
core.c:416 [inline]
BUG: KASAN: vmalloc-out-of-bounds in acpi_nfit_ctl+0x20e8/0x24a0
drivers/acpi/nfit/core.c:459

The issue occurs in cmd_to_func when the call_pkg-&gt;nd_reserved2
array is accessed without verifying that call_pkg points to a buffer
that is appropriately sized as a struct nd_cmd_pkg. This can lead
to out-of-bounds access and undefined behavior if the buffer does not
have sufficient space.

To address this, a check was added in acpi_nfit_ctl() to ensure that
buf is not NULL and that buf_len is less than sizeof(*call_pkg)
before accessing it. This ensures safe access to the members of
call_pkg, including the nd_reserved2 array.</Note>
    </Notes>
    <CVE>CVE-2024-56662</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: nl80211: fix NL80211_ATTR_MLO_LINK_ID off-by-one

Since the netlink attribute range validation provides inclusive
checking, the *max* of attribute NL80211_ATTR_MLO_LINK_ID should be
IEEE80211_MLD_MAX_NUM_LINKS - 1 otherwise causing an off-by-one.

One crash stack for demonstration:
==================================================================
BUG: KASAN: wild-memory-access in ieee80211_tx_control_port+0x3b6/0xca0 net/mac80211/tx.c:5939
Read of size 6 at addr 001102080000000c by task fuzzer.386/9508

CPU: 1 PID: 9508 Comm: syz.1.386 Not tainted 6.1.70 #2
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x177/0x231 lib/dump_stack.c:106
 print_report+0xe0/0x750 mm/kasan/report.c:398
 kasan_report+0x139/0x170 mm/kasan/report.c:495
 kasan_check_range+0x287/0x290 mm/kasan/generic.c:189
 memcpy+0x25/0x60 mm/kasan/shadow.c:65
 ieee80211_tx_control_port+0x3b6/0xca0 net/mac80211/tx.c:5939
 rdev_tx_control_port net/wireless/rdev-ops.h:761 [inline]
 nl80211_tx_control_port+0x7b3/0xc40 net/wireless/nl80211.c:15453
 genl_family_rcv_msg_doit+0x22e/0x320 net/netlink/genetlink.c:756
 genl_family_rcv_msg net/netlink/genetlink.c:833 [inline]
 genl_rcv_msg+0x539/0x740 net/netlink/genetlink.c:850
 netlink_rcv_skb+0x1de/0x420 net/netlink/af_netlink.c:2508
 genl_rcv+0x24/0x40 net/netlink/genetlink.c:861
 netlink_unicast_kernel net/netlink/af_netlink.c:1326 [inline]
 netlink_unicast+0x74b/0x8c0 net/netlink/af_netlink.c:1352
 netlink_sendmsg+0x882/0xb90 net/netlink/af_netlink.c:1874
 sock_sendmsg_nosec net/socket.c:716 [inline]
 __sock_sendmsg net/socket.c:728 [inline]
 ____sys_sendmsg+0x5cc/0x8f0 net/socket.c:2499
 ___sys_sendmsg+0x21c/0x290 net/socket.c:2553
 __sys_sendmsg net/socket.c:2582 [inline]
 __do_sys_sendmsg net/socket.c:2591 [inline]
 __se_sys_sendmsg+0x19e/0x270 net/socket.c:2589
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x45/0x90 arch/x86/entry/common.c:81
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Update the policy to ensure correct validation.</Note>
    </Notes>
    <CVE>CVE-2024-56663</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf, sockmap: Fix race between element replace and close()

Element replace (with a socket different from the one stored) may race
with socket's close() link popping &amp; unlinking. __sock_map_delete()
unconditionally unrefs the (wrong) element:

// set map[0] = s0
map_update_elem(map, 0, s0)

// drop fd of s0
close(s0)
  sock_map_close()
    lock_sock(sk)               (s0!)
    sock_map_remove_links(sk)
      link = sk_psock_link_pop()
      sock_map_unlink(sk, link)
        sock_map_delete_from_link
                                        // replace map[0] with s1
                                        map_update_elem(map, 0, s1)
                                          sock_map_update_elem
                                (s1!)       lock_sock(sk)
                                            sock_map_update_common
                                              psock = sk_psock(sk)
                                              spin_lock(&amp;stab-&gt;lock)
                                              osk = stab-&gt;sks[idx]
                                              sock_map_add_link(..., &amp;stab-&gt;sks[idx])
                                              sock_map_unref(osk, &amp;stab-&gt;sks[idx])
                                                psock = sk_psock(osk)
                                                sk_psock_put(sk, psock)
                                                  if (refcount_dec_and_test(&amp;psock))
                                                    sk_psock_drop(sk, psock)
                                              spin_unlock(&amp;stab-&gt;lock)
                                            unlock_sock(sk)
          __sock_map_delete
            spin_lock(&amp;stab-&gt;lock)
            sk = *psk                        // s1 replaced s0; sk == s1
            if (!sk_test || sk_test == sk)   // sk_test (s0) != sk (s1); no branch
              sk = xchg(psk, NULL)
            if (sk)
              sock_map_unref(sk, psk)        // unref s1; sks[idx] will dangle
                psock = sk_psock(sk)
                sk_psock_put(sk, psock)
                  if (refcount_dec_and_test())
                    sk_psock_drop(sk, psock)
            spin_unlock(&amp;stab-&gt;lock)
    release_sock(sk)

Then close(map) enqueues bpf_map_free_deferred, which finally calls
sock_map_free(). This results in some refcount_t warnings along with
a KASAN splat [1].

Fix __sock_map_delete(), do not allow sock_map_unref() on elements that
may have been replaced.

[1]:
BUG: KASAN: slab-use-after-free in sock_map_free+0x10e/0x330
Write of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063

CPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ #125
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014
Workqueue: events_unbound bpf_map_free_deferred
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x68/0x90
 print_report+0x174/0x4f6
 kasan_report+0xb9/0x190
 kasan_check_range+0x10f/0x1e0
 sock_map_free+0x10e/0x330
 bpf_map_free_deferred+0x173/0x320
 process_one_work+0x846/0x1420
 worker_thread+0x5b3/0xf80
 kthread+0x29e/0x360
 ret_from_fork+0x2d/0x70
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;

Allocated by task 1202:
 kasan_save_stack+0x1e/0x40
 kasan_save_track+0x10/0x30
 __kasan_slab_alloc+0x85/0x90
 kmem_cache_alloc_noprof+0x131/0x450
 sk_prot_alloc+0x5b/0x220
 sk_alloc+0x2c/0x870
 unix_create1+0x88/0x8a0
 unix_create+0xc5/0x180
 __sock_create+0x241/0x650
 __sys_socketpair+0x1ce/0x420
 __x64_sys_socketpair+0x92/0x100
 do_syscall_64+0x93/0x180
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Freed by task 46:
 kasan_save_stack+0x1e/0x40
 kasan_save_track+0x10/0x30
 kasan_save_free_info+0x37/0x60
 __kasan_slab_free+0x4b/0x70
 kmem_cache_free+0x1a1/0x590
 __sk_destruct+0x388/0x5a0
 sk_psock_destroy+0x73e/0xa50
 process_one_work+0x846/0x1420
 worker_thread+0x5b3/0xf80
 kthread+0x29e/0x360
 ret_from_fork+0x2d/0x70
 ret_from_fork_asm+0x1a/0x30

The bu
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-56664</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf,perf: Fix invalid prog_array access in perf_event_detach_bpf_prog

Syzbot reported [1] crash that happens for following tracing scenario:

  - create tracepoint perf event with attr.inherit=1, attach it to the
    process and set bpf program to it
  - attached process forks -&gt; chid creates inherited event

    the new child event shares the parent's bpf program and tp_event
    (hence prog_array) which is global for tracepoint

  - exit both process and its child -&gt; release both events
  - first perf_event_detach_bpf_prog call will release tp_event-&gt;prog_array
    and second perf_event_detach_bpf_prog will crash, because
    tp_event-&gt;prog_array is NULL

The fix makes sure the perf_event_detach_bpf_prog checks prog_array
is valid before it tries to remove the bpf program from it.

[1] https://lore.kernel.org/bpf/Z1MR6dCIKajNS6nU@krava/T/#m91dbf0688221ec7a7fc95e896a7ef9ff93b0b8ad</Note>
    </Notes>
    <CVE>CVE-2024-56665</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointer

Considering that in some extreme cases,
when u_serial driver is accessed by multiple threads,
Thread A is executing the open operation and calling the gs_open,
Thread B is executing the disconnect operation and calling the
gserial_disconnect function,The port-&gt;port_usb pointer will be set to NULL.

E.g.
    Thread A                                 Thread B
    gs_open()                                gadget_unbind_driver()
    gs_start_io()                            composite_disconnect()
    gs_start_rx()                            gserial_disconnect()
    ...                                      ...
    spin_unlock(&amp;port-&gt;port_lock)
    status = usb_ep_queue()                  spin_lock(&amp;port-&gt;port_lock)
    spin_lock(&amp;port-&gt;port_lock)              port-&gt;port_usb = NULL
    gs_free_requests(port-&gt;port_usb-&gt;in)     spin_unlock(&amp;port-&gt;port_lock)
    Crash

This causes thread A to access a null pointer (port-&gt;port_usb is null)
when calling the gs_free_requests function, causing a crash.

If port_usb is NULL, the release request will be skipped as it
will be done by gserial_disconnect.

So add a null pointer check to gs_start_io before attempting
to access the value of the pointer port-&gt;port_usb.

Call trace:
 gs_start_io+0x164/0x25c
 gs_open+0x108/0x13c
 tty_open+0x314/0x638
 chrdev_open+0x1b8/0x258
 do_dentry_open+0x2c4/0x700
 vfs_open+0x2c/0x3c
 path_openat+0xa64/0xc60
 do_filp_open+0xb8/0x164
 do_sys_openat2+0x84/0xf0
 __arm64_sys_openat+0x70/0x9c
 invoke_syscall+0x58/0x114
 el0_svc_common+0x80/0xe0
 do_el0_svc+0x1c/0x28
 el0_svc+0x38/0x68</Note>
    </Notes>
    <CVE>CVE-2024-56670</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

blk-cgroup: Fix UAF in blkcg_unpin_online()

blkcg_unpin_online() walks up the blkcg hierarchy putting the online pin. To
walk up, it uses blkcg_parent(blkcg) but it was calling that after
blkcg_destroy_blkgs(blkcg) which could free the blkcg, leading to the
following UAF:

  ==================================================================
  BUG: KASAN: slab-use-after-free in blkcg_unpin_online+0x15a/0x270
  Read of size 8 at addr ffff8881057678c0 by task kworker/9:1/117

  CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty #48
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022
  Workqueue: cgwb_release cgwb_release_workfn
  Call Trace:
   &lt;TASK&gt;
   dump_stack_lvl+0x27/0x80
   print_report+0x151/0x710
   kasan_report+0xc0/0x100
   blkcg_unpin_online+0x15a/0x270
   cgwb_release_workfn+0x194/0x480
   process_scheduled_works+0x71b/0xe20
   worker_thread+0x82a/0xbd0
   kthread+0x242/0x2c0
   ret_from_fork+0x33/0x70
   ret_from_fork_asm+0x1a/0x30
   &lt;/TASK&gt;
  ...
  Freed by task 1944:
   kasan_save_track+0x2b/0x70
   kasan_save_free_info+0x3c/0x50
   __kasan_slab_free+0x33/0x50
   kfree+0x10c/0x330
   css_free_rwork_fn+0xe6/0xb30
   process_scheduled_works+0x71b/0xe20
   worker_thread+0x82a/0xbd0
   kthread+0x242/0x2c0
   ret_from_fork+0x33/0x70
   ret_from_fork_asm+0x1a/0x30

Note that the UAF is not easy to trigger as the free path is indirected
behind a couple RCU grace periods and a work item execution. I could only
trigger it with artifical msleep() injected in blkcg_unpin_online().

Fix it by reading the parent pointer before destroying the blkcg's blkg's.</Note>
    </Notes>
    <CVE>CVE-2024-56672</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix UAF via mismatching bpf_prog/attachment RCU flavors

Uprobes always use bpf_prog_run_array_uprobe() under tasks-trace-RCU
protection. But it is possible to attach a non-sleepable BPF program to a
uprobe, and non-sleepable BPF programs are freed via normal RCU (see
__bpf_prog_put_noref()). This leads to UAF of the bpf_prog because a normal
RCU grace period does not imply a tasks-trace-RCU grace period.

Fix it by explicitly waiting for a tasks-trace-RCU grace period after
removing the attachment of a bpf_prog to a perf_event.</Note>
    </Notes>
    <CVE>CVE-2024-56675</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

powerpc/fadump: Move fadump_cma_init to setup_arch() after initmem_init()

During early init CMA_MIN_ALIGNMENT_BYTES can be PAGE_SIZE,
since pageblock_order is still zero and it gets initialized
later during initmem_init() e.g.
setup_arch() -&gt; initmem_init() -&gt; sparse_init() -&gt; set_pageblock_order()

One such use case where this causes issue is -
early_setup() -&gt; early_init_devtree() -&gt; fadump_reserve_mem() -&gt; fadump_cma_init()

This causes CMA memory alignment check to be bypassed in
cma_init_reserved_mem(). Then later cma_activate_area() can hit
a VM_BUG_ON_PAGE(pfn &amp; ((1 &lt;&lt; order) - 1)) if the reserved memory
area was not pageblock_order aligned.

Fix it by moving the fadump_cma_init() after initmem_init(),
where other such cma reservations also gets called.

&lt;stack trace&gt;
==============
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10010
flags: 0x13ffff800000000(node=1|zone=0|lastcpupid=0x7ffff) CMA
raw: 013ffff800000000 5deadbeef0000100 5deadbeef0000122 0000000000000000
raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: VM_BUG_ON_PAGE(pfn &amp; ((1 &lt;&lt; order) - 1))
------------[ cut here ]------------
kernel BUG at mm/page_alloc.c:778!

Call Trace:
__free_one_page+0x57c/0x7b0 (unreliable)
free_pcppages_bulk+0x1a8/0x2c8
free_unref_page_commit+0x3d4/0x4e4
free_unref_page+0x458/0x6d0
init_cma_reserved_pageblock+0x114/0x198
cma_init_reserved_areas+0x270/0x3e0
do_one_initcall+0x80/0x2f8
kernel_init_freeable+0x33c/0x530
kernel_init+0x34/0x26c
ret_from_kernel_user_thread+0x14/0x1c</Note>
    </Notes>
    <CVE>CVE-2024-56677</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

powerpc/mm/fault: Fix kfence page fault reporting

copy_from_kernel_nofault() can be called when doing read of /proc/kcore.
/proc/kcore can have some unmapped kfence objects which when read via
copy_from_kernel_nofault() can cause page faults. Since *_nofault()
functions define their own fixup table for handling fault, use that
instead of asking kfence to handle such faults.

Hence we search the exception tables for the nip which generated the
fault. If there is an entry then we let the fixup table handler handle the
page fault by returning an error from within ___do_page_fault().

This can be easily triggered if someone tries to do dd from /proc/kcore.
eg. dd if=/proc/kcore of=/dev/null bs=1M

Some example false negatives:

  ===============================
  BUG: KFENCE: invalid read in copy_from_kernel_nofault+0x9c/0x1a0
  Invalid read at 0xc0000000fdff0000:
   copy_from_kernel_nofault+0x9c/0x1a0
   0xc00000000665f950
   read_kcore_iter+0x57c/0xa04
   proc_reg_read_iter+0xe4/0x16c
   vfs_read+0x320/0x3ec
   ksys_read+0x90/0x154
   system_call_exception+0x120/0x310
   system_call_vectored_common+0x15c/0x2ec

  BUG: KFENCE: use-after-free read in copy_from_kernel_nofault+0x9c/0x1a0
  Use-after-free read at 0xc0000000fe050000 (in kfence-#2):
   copy_from_kernel_nofault+0x9c/0x1a0
   0xc00000000665f950
   read_kcore_iter+0x57c/0xa04
   proc_reg_read_iter+0xe4/0x16c
   vfs_read+0x320/0x3ec
   ksys_read+0x90/0x154
   system_call_exception+0x120/0x310
   system_call_vectored_common+0x15c/0x2ec</Note>
    </Notes>
    <CVE>CVE-2024-56678</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.c

Add error pointer check after calling otx2_mbox_get_rsp().</Note>
    </Notes>
    <CVE>CVE-2024-56679</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

crypto: bcm - add error check in the ahash_hmac_init function

The ahash_init functions may return fails. The ahash_hmac_init should
not return ok when ahash_init returns error. For an example, ahash_init
will return -ENOMEM when allocation memory is error.</Note>
    </Notes>
    <CVE>CVE-2024-56681</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/vc4: hdmi: Avoid hang with debug registers when suspended

Trying to read /sys/kernel/debug/dri/1/hdmi1_regs
when the hdmi is disconnected results in a fatal system hang.

This is due to the pm suspend code disabling the dvp clock.
That is just a gate of the 108MHz clock in DVP_HT_RPI_MISC_CONFIG,
which results in accesses hanging AXI bus.

Protect against this.</Note>
    </Notes>
    <CVE>CVE-2024-56683</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: musb: Fix hardware lockup on first Rx endpoint request

There is a possibility that a request's callback could be invoked from
usb_ep_queue() (call trace below, supplemented with missing calls):

req-&gt;complete from usb_gadget_giveback_request
	(drivers/usb/gadget/udc/core.c:999)
usb_gadget_giveback_request from musb_g_giveback
	(drivers/usb/musb/musb_gadget.c:147)
musb_g_giveback from rxstate
	(drivers/usb/musb/musb_gadget.c:784)
rxstate from musb_ep_restart
	(drivers/usb/musb/musb_gadget.c:1169)
musb_ep_restart from musb_ep_restart_resume_work
	(drivers/usb/musb/musb_gadget.c:1176)
musb_ep_restart_resume_work from musb_queue_resume_work
	(drivers/usb/musb/musb_core.c:2279)
musb_queue_resume_work from musb_gadget_queue
	(drivers/usb/musb/musb_gadget.c:1241)
musb_gadget_queue from usb_ep_queue
	(drivers/usb/gadget/udc/core.c:300)

According to the docstring of usb_ep_queue(), this should not happen:

"Note that @req's -&gt;complete() callback must never be called from within
usb_ep_queue() as that can create deadlock situations."

In fact, a hardware lockup might occur in the following sequence:

1. The gadget is initialized using musb_gadget_enable().
2. Meanwhile, a packet arrives, and the RXPKTRDY flag is set, raising an
   interrupt.
3. If IRQs are enabled, the interrupt is handled, but musb_g_rx() finds an
   empty queue (next_request() returns NULL). The interrupt flag has
   already been cleared by the glue layer handler, but the RXPKTRDY flag
   remains set.
4. The first request is enqueued using usb_ep_queue(), leading to the call
   of req-&gt;complete(), as shown in the call trace above.
5. If the callback enables IRQs and another packet is waiting, step (3)
   repeats. The request queue is empty because usb_g_giveback() removes the
   request before invoking the callback.
6. The endpoint remains locked up, as the interrupt triggered by hardware
   setting the RXPKTRDY flag has been handled, but the flag itself remains
   set.

For this scenario to occur, it is only necessary for IRQs to be enabled at
some point during the complete callback. This happens with the USB Ethernet
gadget, whose rx_complete() callback calls netif_rx(). If called in the
task context, netif_rx() disables the bottom halves (BHs). When the BHs are
re-enabled, IRQs are also enabled to allow soft IRQs to be processed. The
gadget itself is initialized at module load (or at boot if built-in), but
the first request is enqueued when the network interface is brought up,
triggering rx_complete() in the task context via ioctl(). If a packet
arrives while the interface is down, it can prevent the interface from
receiving any further packets from the USB host.

The situation is quite complicated with many parties involved. This
particular issue can be resolved in several possible ways:

1. Ensure that callbacks never enable IRQs. This would be difficult to
   enforce, as discovering how netif_rx() interacts with interrupts was
   already quite challenging and u_ether is not the only function driver.
   Similar "bugs" could be hidden in other drivers as well.
2. Disable MUSB interrupts in musb_g_giveback() before calling the callback
   and re-enable them afterwars (by calling musb_{dis,en}able_interrupts(),
   for example). This would ensure that MUSB interrupts are not handled
   during the callback, even if IRQs are enabled. In fact, it would allow
   IRQs to be enabled when releasing the lock. However, this feels like an
   inelegant hack.
3. Modify the interrupt handler to clear the RXPKTRDY flag if the request
   queue is empty. While this approach also feels like a hack, it wastes
   CPU time by attempting to handle incoming packets when the software is
   not ready to process them.
4. Flush the Rx FIFO instead of calling rxstate() in musb_ep_restart().
   This ensures that the hardware can receive packets when there is at
   least one request in the queue. Once I
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-56687</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport

Since transport-&gt;sock has been set to NULL during reset transport,
XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the
xs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request()
to dereference the transport-&gt;sock that has been set to NULL.</Note>
    </Notes>
    <CVE>CVE-2024-56688</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY

Since commit 8f4f68e788c3 ("crypto: pcrypt - Fix hungtask for
PADATA_RESET"), the pcrypt encryption and decryption operations return
-EAGAIN when the CPU goes online or offline. In alg_test(), a WARN is
generated when pcrypt_aead_decrypt() or pcrypt_aead_encrypt() returns
-EAGAIN, the unnecessary panic will occur when panic_on_warn set 1.
Fix this issue by calling crypto layer directly without parallelization
in that case.</Note>
    </Notes>
    <CVE>CVE-2024-56690</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device

While design wise the idea of converting the driver to use
the hierarchy of the IRQ chips is correct, the implementation
has (inherited) flaws. This was unveiled when platform_get_irq()
had started WARN() on IRQ 0 that is supposed to be a Linux
IRQ number (also known as vIRQ).

Rework the driver to respect IRQ domain when creating each MFD
device separately, as the domain is not the same for all of them.</Note>
    </Notes>
    <CVE>CVE-2024-56691</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

brd: defer automatic disk creation until module initialization succeeds

My colleague Wupeng found the following problems during fault injection:

BUG: unable to handle page fault for address: fffffbfff809d073
PGD 6e648067 P4D 123ec8067 PUD 123ec4067 PMD 100e38067 PTE 0
Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI
CPU: 5 UID: 0 PID: 755 Comm: modprobe Not tainted 6.12.0-rc3+ #17
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.1-2.fc37 04/01/2014
RIP: 0010:__asan_load8+0x4c/0xa0
...
Call Trace:
 &lt;TASK&gt;
 blkdev_put_whole+0x41/0x70
 bdev_release+0x1a3/0x250
 blkdev_release+0x11/0x20
 __fput+0x1d7/0x4a0
 task_work_run+0xfc/0x180
 syscall_exit_to_user_mode+0x1de/0x1f0
 do_syscall_64+0x6b/0x170
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

loop_init() is calling loop_add() after __register_blkdev() succeeds and
is ignoring disk_add() failure from loop_add(), for loop_add() failure
is not fatal and successfully created disks are already visible to
bdev_open().

brd_init() is currently calling brd_alloc() before __register_blkdev()
succeeds and is releasing successfully created disks when brd_init()
returns an error. This can cause UAF for the latter two case:

case 1:
    T1:
modprobe brd
  brd_init
    brd_alloc(0) // success
      add_disk
        disk_scan_partitions
          bdev_file_open_by_dev // alloc file
          fput // won't free until back to userspace
    brd_alloc(1) // failed since mem alloc error inject
  // error path for modprobe will release code segment
  // back to userspace
  __fput
    blkdev_release
      bdev_release
        blkdev_put_whole
          bdev-&gt;bd_disk-&gt;fops-&gt;release // fops is freed now, UAF!

case 2:
    T1:                            T2:
modprobe brd
  brd_init
    brd_alloc(0) // success
                                   open(/dev/ram0)
    brd_alloc(1) // fail
  // error path for modprobe

                                   close(/dev/ram0)
                                   ...
                                   /* UAF! */
                                   bdev-&gt;bd_disk-&gt;fops-&gt;release

Fix this problem by following what loop_init() does. Besides,
reintroduce brd_devices_mutex to help serialize modifications to
brd_list.</Note>
    </Notes>
    <CVE>CVE-2024-56693</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: fix recursive lock when verdict program return SK_PASS

When the stream_verdict program returns SK_PASS, it places the received skb
into its own receive queue, but a recursive lock eventually occurs, leading
to an operating system deadlock. This issue has been present since v6.9.

'''
sk_psock_strp_data_ready
    write_lock_bh(&amp;sk-&gt;sk_callback_lock)
    strp_data_ready
      strp_read_sock
        read_sock -&gt; tcp_read_sock
          strp_recv
            cb.rcv_msg -&gt; sk_psock_strp_read
              # now stream_verdict return SK_PASS without peer sock assign
              __SK_PASS = sk_psock_map_verd(SK_PASS, NULL)
              sk_psock_verdict_apply
                sk_psock_skb_ingress_self
                  sk_psock_skb_ingress_enqueue
                    sk_psock_data_ready
                      read_lock_bh(&amp;sk-&gt;sk_callback_lock) &lt;= dead lock

'''

This topic has been discussed before, but it has not been fixed.
Previous discussion:
https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch</Note>
    </Notes>
    <CVE>CVE-2024-56694</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: dwc3: gadget: Fix looping of queued SG entries

The dwc3_request-&gt;num_queued_sgs is decremented on completion. If a
partially completed request is handled, then the
dwc3_request-&gt;num_queued_sgs no longer reflects the total number of
num_queued_sgs (it would be cleared).

Correctly check the number of request SG entries remained to be prepare
and queued. Failure to do this may cause null pointer dereference when
accessing non-existent SG entry.</Note>
    </Notes>
    <CVE>CVE-2024-56698</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: wl128x: Fix atomicity violation in fmc_send_cmd()

Atomicity violation occurs when the fmc_send_cmd() function is executed
simultaneously with the modification of the fmdev-&gt;resp_skb value.
Consider a scenario where, after passing the validity check within the
function, a non-null fmdev-&gt;resp_skb variable is assigned a null value.
This results in an invalid fmdev-&gt;resp_skb variable passing the validity
check. As seen in the later part of the function, skb = fmdev-&gt;resp_skb;
when the invalid fmdev-&gt;resp_skb passes the check, a null pointer
dereference error may occur at line 478, evt_hdr = (void *)skb-&gt;data;

To address this issue, it is recommended to include the validity check of
fmdev-&gt;resp_skb within the locked section of the function. This
modification ensures that the value of fmdev-&gt;resp_skb does not change
during the validation process, thereby maintaining its validity.

This possible bug is found by an experimental static analysis tool
developed by our team. This tool analyzes the locking APIs
to extract function pairs that can be concurrently executed, and then
analyzes the instructions in the paired functions to identify possible
concurrency bugs including data races and atomicity violations.</Note>
    </Notes>
    <CVE>CVE-2024-56700</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

powerpc/pseries: Fix dtl_access_lock to be a rw_semaphore

The dtl_access_lock needs to be a rw_sempahore, a sleeping lock, because
the code calls kmalloc() while holding it, which can sleep:

  # echo 1 &gt; /proc/powerpc/vcpudispatch_stats
  BUG: sleeping function called from invalid context at include/linux/sched/mm.h:337
  in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 199, name: sh
  preempt_count: 1, expected: 0
  3 locks held by sh/199:
   #0: c00000000a0743f8 (sb_writers#3){.+.+}-{0:0}, at: vfs_write+0x324/0x438
   #1: c0000000028c7058 (dtl_enable_mutex){+.+.}-{3:3}, at: vcpudispatch_stats_write+0xd4/0x5f4
   #2: c0000000028c70b8 (dtl_access_lock){+.+.}-{2:2}, at: vcpudispatch_stats_write+0x220/0x5f4
  CPU: 0 PID: 199 Comm: sh Not tainted 6.10.0-rc4 #152
  Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries
  Call Trace:
    dump_stack_lvl+0x130/0x148 (unreliable)
    __might_resched+0x174/0x410
    kmem_cache_alloc_noprof+0x340/0x3d0
    alloc_dtl_buffers+0x124/0x1ac
    vcpudispatch_stats_write+0x2a8/0x5f4
    proc_reg_write+0xf4/0x150
    vfs_write+0xfc/0x438
    ksys_write+0x88/0x148
    system_call_exception+0x1c4/0x5a0
    system_call_common+0xf4/0x258</Note>
    </Notes>
    <CVE>CVE-2024-56701</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

9p/xen: fix release of IRQ

Kernel logs indicate an IRQ was double-freed.

Pass correct device ID during IRQ release.

[Dominique: remove confusing variable reset to 0]</Note>
    </Notes>
    <CVE>CVE-2024-56704</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: atomisp: Add check for rgby_data memory allocation failure

In ia_css_3a_statistics_allocate(), there is no check on the allocation
result of the rgby_data memory. If rgby_data is not successfully
allocated, it may trigger the assert(host_stats-&gt;rgby_data) assertion in
ia_css_s3a_hmem_decode(). Adding a check to fix this potential issue.</Note>
    </Notes>
    <CVE>CVE-2024-56705</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.c

Add error pointer checks after calling otx2_mbox_get_rsp().</Note>
    </Notes>
    <CVE>CVE-2024-56707</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

EDAC/igen6: Avoid segmentation fault on module unload

The segmentation fault happens because:

During modprobe:
1. In igen6_probe(), igen6_pvt will be allocated with kzalloc()
2. In igen6_register_mci(), mci-&gt;pvt_info will point to
   &amp;igen6_pvt-&gt;imc[mc]

During rmmod:
1. In mci_release() in edac_mc.c, it will kfree(mci-&gt;pvt_info)
2. In igen6_remove(), it will kfree(igen6_pvt);

Fix this issue by setting mci-&gt;pvt_info to NULL to avoid the double
kfree.</Note>
    </Notes>
    <CVE>CVE-2024-56708</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

io_uring: check if iowq is killed before queuing

task work can be executed after the task has gone through io_uring
termination, whether it's the final task_work run or the fallback path.
In this case, task work will find -&gt;io_wq being already killed and
null'ed, which is a problem if it then tries to forward the request to
io_queue_iowq(). Make io_queue_iowq() fail requests in this case.

Note that it also checks PF_KTHREAD, because the user can first close
a DEFER_TASKRUN ring and shortly after kill the task, in which case
-&gt;iowq check would race.</Note>
    </Notes>
    <CVE>CVE-2024-56709</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

udmabuf: fix memory leak on last export_udmabuf() error path

In export_udmabuf(), if dma_buf_fd() fails because the FD table is full, a
dma_buf owning the udmabuf has already been created; but the error handling
in udmabuf_create() will tear down the udmabuf without doing anything about
the containing dma_buf.

This leaves a dma_buf in memory that contains a dangling pointer; though
that doesn't seem to lead to anything bad except a memory leak.

Fix it by moving the dma_buf_fd() call out of export_udmabuf() so that we
can give it different error handling.

Note that the shape of this code changed a lot in commit 5e72b2b41a21
("udmabuf: convert udmabuf driver to use folios"); but the memory leak
seems to have existed since the introduction of udmabuf.</Note>
    </Notes>
    <CVE>CVE-2024-56712</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ionic: Fix netdev notifier unregister on failure

If register_netdev() fails, then the driver leaks the netdev notifier.
Fix this by calling ionic_lif_unregister() on register_netdev()
failure. This will also call ionic_lif_unregister_phc() if it has
already been registered.</Note>
    </Notes>
    <CVE>CVE-2024-56715</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netdevsim: prevent bad user input in nsim_dev_health_break_write()

If either a zero count or a large one is provided, kernel can crash.</Note>
    </Notes>
    <CVE>CVE-2024-56716</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf, sockmap: Several fixes to bpf_msg_pop_data

Several fixes to bpf_msg_pop_data,
1. In sk_msg_shift_left, we should put_page
2. if (len == 0), return early is better
3. pop the entire sk_msg (last == msg-&gt;sg.size) should be supported
4. Fix for the value of variable "a"
5. In sk_msg_shift_left, after shifting, i has already pointed to the next
element. Addtional sk_msg_iter_var_next may result in BUG.</Note>
    </Notes>
    <CVE>CVE-2024-56720</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/hns: Fix cpu stuck caused by printings during reset

During reset, cmd to destroy resources such as qp, cq, and mr may fail,
and error logs will be printed. When a large number of resources are
destroyed, there will be lots of printings, and it may lead to a cpu
stuck.

Delete some unnecessary printings and replace other printing functions
in these paths with the ratelimited version.</Note>
    </Notes>
    <CVE>CVE-2024-56722</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices

While design wise the idea of converting the driver to use
the hierarchy of the IRQ chips is correct, the implementation
has (inherited) flaws. This was unveiled when platform_get_irq()
had started WARN() on IRQ 0 that is supposed to be a Linux
IRQ number (also known as vIRQ).

Rework the driver to respect IRQ domain when creating each MFD
device separately, as the domain is not the same for all of them.</Note>
    </Notes>
    <CVE>CVE-2024-56723</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device

While design wise the idea of converting the driver to use
the hierarchy of the IRQ chips is correct, the implementation
has (inherited) flaws. This was unveiled when platform_get_irq()
had started WARN() on IRQ 0 that is supposed to be a Linux
IRQ number (also known as vIRQ).

Rework the driver to respect IRQ domain when creating each MFD
device separately, as the domain is not the same for all of them.</Note>
    </Notes>
    <CVE>CVE-2024-56724</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dcbnl.c

Add error pointer check after calling otx2_mbox_get_rsp().</Note>
    </Notes>
    <CVE>CVE-2024-56725</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

octeontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.c

Add error pointer check after calling otx2_mbox_get_rsp().</Note>
    </Notes>
    <CVE>CVE-2024-56726</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c

Adding error pointer check after calling otx2_mbox_get_rsp().</Note>
    </Notes>
    <CVE>CVE-2024-56727</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c

Add error pointer check after calling otx2_mbox_get_rsp().</Note>
    </Notes>
    <CVE>CVE-2024-56728</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

smb: Initialize cfid-&gt;tcon before performing network ops

Avoid leaking a tcon ref when a lease break races with opening the
cached directory. Processing the leak break might take a reference to
the tcon in cached_dir_lease_break() and then fail to release the ref in
cached_dir_offload_close, since cfid-&gt;tcon is still NULL.</Note>
    </Notes>
    <CVE>CVE-2024-56729</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">GNU GRUB (aka GRUB2) through 2.12 has a heap-based buffer overflow in fs/hfs.c via crafted sblock data in an HFS filesystem.</Note>
    </Notes>
    <CVE>CVE-2024-56737</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-2.12-150600.8.21.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-arm64-efi-2.12-150600.8.21.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

rtc: check if __rtc_read_time was successful in rtc_timer_do_work()

If the __rtc_read_time call fails,, the struct rtc_time tm; may contain
uninitialized data, or an illegal date/time read from the RTC hardware.

When calling rtc_tm_to_ktime later, the result may be a very large value
(possibly KTIME_MAX). If there are periodic timers in rtc-&gt;timerqueue,
they will continually expire, may causing kernel softlockup.</Note>
    </Notes>
    <CVE>CVE-2024-56739</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2024-56741</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

PCI: Fix reset_method_store() memory leak

In reset_method_store(), a string is allocated via kstrndup() and assigned
to the local "options". options is then used in with strsep() to find
spaces:

  while ((name = strsep(&amp;options, " ")) != NULL) {

If there are no remaining spaces, then options is set to NULL by strsep(),
so the subsequent kfree(options) doesn't free the memory allocated via
kstrndup().

Fix by using a separate tmp_options to iterate with strsep() so options is
preserved.</Note>
    </Notes>
    <CVE>CVE-2024-56745</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()

When information such as info-&gt;screen_base is not ready, calling
sh7760fb_free_mem() does not release memory correctly. Call
dma_free_coherent() instead.</Note>
    </Notes>
    <CVE>CVE-2024-56746</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()

Hook "qedi_ops-&gt;common-&gt;sb_init = qed_sb_init" does not release the DMA
memory sb_virt when it fails. Add dma_free_coherent() to free it. This
is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().</Note>
    </Notes>
    <CVE>CVE-2024-56747</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb()

Hook "qed_ops-&gt;common-&gt;sb_init = qed_sb_init" does not release the DMA
memory sb_virt when it fails. Add dma_free_coherent() to free it. This
is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().</Note>
    </Notes>
    <CVE>CVE-2024-56748</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix use-after-free when COWing tree bock and tracing is enabled

When a COWing a tree block, at btrfs_cow_block(), and we have the
tracepoint trace_btrfs_cow_block() enabled and preemption is also enabled
(CONFIG_PREEMPT=y), we can trigger a use-after-free in the COWed extent
buffer while inside the tracepoint code. This is because in some paths
that call btrfs_cow_block(), such as btrfs_search_slot(), we are holding
the last reference on the extent buffer @buf so btrfs_force_cow_block()
drops the last reference on the @buf extent buffer when it calls
free_extent_buffer_stale(buf), which schedules the release of the extent
buffer with RCU. This means that if we are on a kernel with preemption,
the current task may be preempted before calling trace_btrfs_cow_block()
and the extent buffer already released by the time trace_btrfs_cow_block()
is called, resulting in a use-after-free.

Fix this by moving the trace_btrfs_cow_block() from btrfs_cow_block() to
btrfs_force_cow_block() before the COWed extent buffer is freed.
This also has a side effect of invoking the tracepoint in the tree defrag
code, at defrag.c:btrfs_realloc_node(), since btrfs_force_cow_block() is
called there, but this is fine and it was actually missing there.</Note>
    </Notes>
    <CVE>CVE-2024-56759</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

PCI/MSI: Handle lack of irqdomain gracefully

Alexandre observed a warning emitted from pci_msi_setup_msi_irqs() on a
RISCV platform which does not provide PCI/MSI support:

 WARNING: CPU: 1 PID: 1 at drivers/pci/msi/msi.h:121 pci_msi_setup_msi_irqs+0x2c/0x32
 __pci_enable_msix_range+0x30c/0x596
 pci_msi_setup_msi_irqs+0x2c/0x32
 pci_alloc_irq_vectors_affinity+0xb8/0xe2

RISCV uses hierarchical interrupt domains and correctly does not implement
the legacy fallback. The warning triggers from the legacy fallback stub.

That warning is bogus as the PCI/MSI layer knows whether a PCI/MSI parent
domain is associated with the device or not. There is a check for MSI-X,
which has a legacy assumption. But that legacy fallback assumption is only
valid when legacy support is enabled, but otherwise the check should simply
return -ENOTSUPP.

Loongarch tripped over the same problem and blindly enabled legacy support
without implementing the legacy fallbacks. There are weak implementations
which return an error, so the problem was papered over.

Correct pci_msi_domain_supports() to evaluate the legacy mode and add
the missing supported check into the MSI enable path to complete it.</Note>
    </Notes>
    <CVE>CVE-2024-56760</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tracing: Prevent bad count for tracing_cpumask_write

If a large count is provided, it will trigger a warning in bitmap_parse_user.
Also check zero for it.</Note>
    </Notes>
    <CVE>CVE-2024-56763</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

powerpc/pseries/vas: Add close() callback in vas_vm_ops struct

The mapping VMA address is saved in VAS window struct when the
paste address is mapped. This VMA address is used during migration
to unmap the paste address if the window is active. The paste
address mapping will be removed when the window is closed or with
the munmap(). But the VMA address in the VAS window is not updated
with munmap() which is causing invalid access during migration.

The KASAN report shows:
[16386.254991] BUG: KASAN: slab-use-after-free in reconfig_close_windows+0x1a0/0x4e8
[16386.255043] Read of size 8 at addr c00000014a819670 by task drmgr/696928

[16386.255096] CPU: 29 UID: 0 PID: 696928 Comm: drmgr Kdump: loaded Tainted: G    B              6.11.0-rc5-nxgzip #2
[16386.255128] Tainted: [B]=BAD_PAGE
[16386.255148] Hardware name: IBM,9080-HEX Power11 (architected) 0x820200 0xf000007 of:IBM,FW1110.00 (NH1110_016) hv:phyp pSeries
[16386.255181] Call Trace:
[16386.255202] [c00000016b297660] [c0000000018ad0ac] dump_stack_lvl+0x84/0xe8 (unreliable)
[16386.255246] [c00000016b297690] [c0000000006e8a90] print_report+0x19c/0x764
[16386.255285] [c00000016b297760] [c0000000006e9490] kasan_report+0x128/0x1f8
[16386.255309] [c00000016b297880] [c0000000006eb5c8] __asan_load8+0xac/0xe0
[16386.255326] [c00000016b2978a0] [c00000000013f898] reconfig_close_windows+0x1a0/0x4e8
[16386.255343] [c00000016b297990] [c000000000140e58] vas_migration_handler+0x3a4/0x3fc
[16386.255368] [c00000016b297a90] [c000000000128848] pseries_migrate_partition+0x4c/0x4c4
...

[16386.256136] Allocated by task 696554 on cpu 31 at 16377.277618s:
[16386.256149]  kasan_save_stack+0x34/0x68
[16386.256163]  kasan_save_track+0x34/0x80
[16386.256175]  kasan_save_alloc_info+0x58/0x74
[16386.256196]  __kasan_slab_alloc+0xb8/0xdc
[16386.256209]  kmem_cache_alloc_noprof+0x200/0x3d0
[16386.256225]  vm_area_alloc+0x44/0x150
[16386.256245]  mmap_region+0x214/0x10c4
[16386.256265]  do_mmap+0x5fc/0x750
[16386.256277]  vm_mmap_pgoff+0x14c/0x24c
[16386.256292]  ksys_mmap_pgoff+0x20c/0x348
[16386.256303]  sys_mmap+0xd0/0x160
...

[16386.256350] Freed by task 0 on cpu 31 at 16386.204848s:
[16386.256363]  kasan_save_stack+0x34/0x68
[16386.256374]  kasan_save_track+0x34/0x80
[16386.256384]  kasan_save_free_info+0x64/0x10c
[16386.256396]  __kasan_slab_free+0x120/0x204
[16386.256415]  kmem_cache_free+0x128/0x450
[16386.256428]  vm_area_free_rcu_cb+0xa8/0xd8
[16386.256441]  rcu_do_batch+0x2c8/0xcf0
[16386.256458]  rcu_core+0x378/0x3c4
[16386.256473]  handle_softirqs+0x20c/0x60c
[16386.256495]  do_softirq_own_stack+0x6c/0x88
[16386.256509]  do_softirq_own_stack+0x58/0x88
[16386.256521]  __irq_exit_rcu+0x1a4/0x20c
[16386.256533]  irq_exit+0x20/0x38
[16386.256544]  interrupt_async_exit_prepare.constprop.0+0x18/0x2c
...

[16386.256717] Last potentially related work creation:
[16386.256729]  kasan_save_stack+0x34/0x68
[16386.256741]  __kasan_record_aux_stack+0xcc/0x12c
[16386.256753]  __call_rcu_common.constprop.0+0x94/0xd04
[16386.256766]  vm_area_free+0x28/0x3c
[16386.256778]  remove_vma+0xf4/0x114
[16386.256797]  do_vmi_align_munmap.constprop.0+0x684/0x870
[16386.256811]  __vm_munmap+0xe0/0x1f8
[16386.256821]  sys_munmap+0x54/0x6c
[16386.256830]  system_call_exception+0x1a0/0x4a0
[16386.256841]  system_call_vectored_common+0x15c/0x2ec

[16386.256868] The buggy address belongs to the object at c00000014a819670
                which belongs to the cache vm_area_struct of size 168
[16386.256887] The buggy address is located 0 bytes inside of
                freed 168-byte region [c00000014a819670, c00000014a819718)

[16386.256915] The buggy address belongs to the physical page:
[16386.256928] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14a81
[16386.256950] memcg:c0000000ba430001
[16386.256961] anon flags: 0x43ffff800000000(node=4|zone=0|lastcpupid=0x7ffff)
[16386.256975] page_type: 0xfdffffff(slab)
[16386
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-56765</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mtd: rawnand: fix double free in atmel_pmecc_create_user()

The "user" pointer was converted from being allocated with kzalloc() to
being allocated by devm_kzalloc().  Calling kfree(user) will lead to a
double free.</Note>
    </Notes>
    <CVE>CVE-2024-56766</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dmaengine: at_xdmac: avoid null_prt_deref in at_xdmac_prep_dma_memset

The at_xdmac_memset_create_desc may return NULL, which will lead to a
null pointer dereference. For example, the len input is error, or the
atchan-&gt;free_descs_list is empty and memory is exhausted. Therefore, add
check to avoid this.</Note>
    </Notes>
    <CVE>CVE-2024-56767</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: dvb-frontends: dib3000mb: fix uninit-value in dib3000_write_reg

Syzbot reports [1] an uninitialized value issue found by KMSAN in
dib3000_read_reg().

Local u8 rb[2] is used in i2c_transfer() as a read buffer; in case
that call fails, the buffer may end up with some undefined values.

Since no elaborate error handling is expected in dib3000_write_reg(),
simply zero out rb buffer to mitigate the problem.

[1] Syzkaller report
dvb-usb: bulk message failed: -22 (6/0)
=====================================================
BUG: KMSAN: uninit-value in dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758
 dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758
 dibusb_dib3000mb_frontend_attach+0x155/0x2f0 drivers/media/usb/dvb-usb/dibusb-mb.c:31
 dvb_usb_adapter_frontend_init+0xed/0x9a0 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:290
 dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:90 [inline]
 dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:186 [inline]
 dvb_usb_device_init+0x25a8/0x3760 drivers/media/usb/dvb-usb/dvb-usb-init.c:310
 dibusb_probe+0x46/0x250 drivers/media/usb/dvb-usb/dibusb-mb.c:110
...
Local variable rb created at:
 dib3000_read_reg+0x86/0x4e0 drivers/media/dvb-frontends/dib3000mb.c:54
 dib3000mb_attach+0x123/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758
...</Note>
    </Notes>
    <CVE>CVE-2024-56769</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: add a sanity check for btrfs root in btrfs_search_slot()

Syzbot reports a null-ptr-deref in btrfs_search_slot().

The reproducer is using rescue=ibadroots, and the extent tree root is
corrupted thus the extent tree is NULL.

When scrub tries to search the extent tree to gather the needed extent
info, btrfs_search_slot() doesn't check if the target root is NULL or
not, resulting the null-ptr-deref.

Add sanity check for btrfs root before using it in btrfs_search_slot().</Note>
    </Notes>
    <CVE>CVE-2024-56774</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix handling of plane refcount

[Why]
The mechanism to backup and restore plane states doesn't maintain
refcount, which can cause issues if the refcount of the plane changes
in between backup and restore operations, such as memory leaks if the
refcount was supposed to go down, or double frees / invalid memory
accesses if the refcount was supposed to go up.

[How]
Cache and re-apply current refcount when restoring plane states.</Note>
    </Notes>
    <CVE>CVE-2024-56775</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/sti: avoid potential dereference of error pointers

The return value of drm_atomic_get_crtc_state() needs to be
checked. To avoid use of error pointer 'crtc_state' in case
of the failure.</Note>
    </Notes>
    <CVE>CVE-2024-56776</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/sti: avoid potential dereference of error pointers in sti_gdp_atomic_check

The return value of drm_atomic_get_crtc_state() needs to be
checked. To avoid use of error pointer 'crtc_state' in case
of the failure.</Note>
    </Notes>
    <CVE>CVE-2024-56777</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/sti: avoid potential dereference of error pointers in sti_hqvdp_atomic_check

The return value of drm_atomic_get_crtc_state() needs to be
checked. To avoid use of error pointer 'crtc_state' in case
of the failure.</Note>
    </Notes>
    <CVE>CVE-2024-56778</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur

The action force umount(umount -f) will attempt to kill all rpc_task even
umount operation may ultimately fail if some files remain open.
Consequently, if an action attempts to open a file, it can potentially
send two rpc_task to nfs server.

                   NFS CLIENT
thread1                             thread2
open("file")
...
nfs4_do_open
 _nfs4_do_open
  _nfs4_open_and_get_state
   _nfs4_proc_open
    nfs4_run_open_task
     /* rpc_task1 */
     rpc_run_task
     rpc_wait_for_completion_task

                                    umount -f
                                    nfs_umount_begin
                                     rpc_killall_tasks
                                      rpc_signal_task
     rpc_task1 been wakeup
     and return -512
 _nfs4_do_open // while loop
    ...
    nfs4_run_open_task
     /* rpc_task2 */
     rpc_run_task
     rpc_wait_for_completion_task

While processing an open request, nfsd will first attempt to find or
allocate an nfs4_openowner. If it finds an nfs4_openowner that is not
marked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Since
two rpc_task can attempt to open the same file simultaneously from the
client to server, and because two instances of nfsd can run
concurrently, this situation can lead to lots of memory leak.
Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be
triggered.

                    NFS SERVER
nfsd1                  nfsd2       echo 0 &gt; /proc/fs/nfsd/threads

nfsd4_open
 nfsd4_process_open1
  find_or_alloc_open_stateowner
   // alloc oo1, stateid1
                       nfsd4_open
                        nfsd4_process_open1
                        find_or_alloc_open_stateowner
                        // find oo1, without NFS4_OO_CONFIRMED
                         release_openowner
                          unhash_openowner_locked
                          list_del_init(&amp;oo-&gt;oo_perclient)
                          // cannot find this oo
                          // from client, LEAK!!!
                         alloc_stateowner // alloc oo2

 nfsd4_process_open2
  init_open_stateid
  // associate oo1
  // with stateid1, stateid1 LEAK!!!
  nfs4_get_vfs_file
  // alloc nfsd_file1 and nfsd_file_mark1
  // all LEAK!!!

                         nfsd4_process_open2
                         ...

                                    write_threads
                                     ...
                                     nfsd_destroy_serv
                                      nfsd_shutdown_net
                                       nfs4_state_shutdown_net
                                        nfs4_state_destroy_net
                                         destroy_client
                                          __destroy_client
                                          // won't find oo1!!!
                                     nfsd_shutdown_generic
                                      nfsd_file_cache_shutdown
                                       kmem_cache_destroy
                                       for nfsd_file_slab
                                       and nfsd_file_mark_slab
                                       // bark since nfsd_file1
                                       // and nfsd_file_mark1
                                       // still alive

=======================================================================
BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on
__kmem_cache_shutdown()
-----------------------------------------------------------------------

Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28
flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff)
CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.1-2.fc37 04/01/2014
Call Trace:
 &lt;TASK&gt;
 dum
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-56779</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

quota: flush quota_release_work upon quota writeback

One of the paths quota writeback is called from is:

freeze_super()
  sync_filesystem()
    ext4_sync_fs()
      dquot_writeback_dquots()

Since we currently don't always flush the quota_release_work queue in
this path, we can end up with the following race:

 1. dquot are added to releasing_dquots list during regular operations.
 2. FS Freeze starts, however, this does not flush the quota_release_work queue.
 3. Freeze completes.
 4. Kernel eventually tries to flush the workqueue while FS is frozen which
    hits a WARN_ON since transaction gets started during frozen state:

  ext4_journal_check_start+0x28/0x110 [ext4] (unreliable)
  __ext4_journal_start_sb+0x64/0x1c0 [ext4]
  ext4_release_dquot+0x90/0x1d0 [ext4]
  quota_release_workfn+0x43c/0x4d0

Which is the following line:

  WARN_ON(sb-&gt;s_writers.frozen == SB_FREEZE_COMPLETE);

Which ultimately results in generic/390 failing due to dmesg
noise. This was detected on powerpc machine 15 cores.

To avoid this, make sure to flush the workqueue during
dquot_writeback_dquots() so we dont have any pending workitems after
freeze.</Note>
    </Notes>
    <CVE>CVE-2024-56780</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

soc: imx8m: Probe the SoC driver as platform driver

With driver_async_probe=* on kernel command line, the following trace is
produced because on i.MX8M Plus hardware because the soc-imx8m.c driver
calls of_clk_get_by_name() which returns -EPROBE_DEFER because the clock
driver is not yet probed. This was not detected during regular testing
without driver_async_probe.

Convert the SoC code to platform driver and instantiate a platform device
in its current device_initcall() to probe the platform driver. Rework
.soc_revision callback to always return valid error code and return SoC
revision via parameter. This way, if anything in the .soc_revision callback
return -EPROBE_DEFER, it gets propagated to .probe and the .probe will get
retried later.

"
------------[ cut here ]------------
WARNING: CPU: 1 PID: 1 at drivers/soc/imx/soc-imx8m.c:115 imx8mm_soc_revision+0xdc/0x180
CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-next-20240924-00002-g2062bb554dea #603
Hardware name: DH electronics i.MX8M Plus DHCOM Premium Developer Kit (3) (DT)
pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : imx8mm_soc_revision+0xdc/0x180
lr : imx8mm_soc_revision+0xd0/0x180
sp : ffff8000821fbcc0
x29: ffff8000821fbce0 x28: 0000000000000000 x27: ffff800081810120
x26: ffff8000818a9970 x25: 0000000000000006 x24: 0000000000824311
x23: ffff8000817f42c8 x22: ffff0000df8be210 x21: fffffffffffffdfb
x20: ffff800082780000 x19: 0000000000000001 x18: ffffffffffffffff
x17: ffff800081fff418 x16: ffff8000823e1000 x15: ffff0000c03b65e8
x14: ffff0000c00051b0 x13: ffff800082790000 x12: 0000000000000801
x11: ffff80008278ffff x10: ffff80008209d3a6 x9 : ffff80008062e95c
x8 : ffff8000821fb9a0 x7 : 0000000000000000 x6 : 00000000000080e3
x5 : ffff0000df8c03d8 x4 : 0000000000000000 x3 : 0000000000000000
x2 : 0000000000000000 x1 : fffffffffffffdfb x0 : fffffffffffffdfb
Call trace:
 imx8mm_soc_revision+0xdc/0x180
 imx8_soc_init+0xb0/0x1e0
 do_one_initcall+0x94/0x1a8
 kernel_init_freeable+0x240/0x2a8
 kernel_init+0x28/0x140
 ret_from_fork+0x10/0x20
---[ end trace 0000000000000000 ]---
SoC: i.MX8MP revision 1.1
"</Note>
    </Notes>
    <CVE>CVE-2024-56787</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/smc: check return value of sock_recvmsg when draining clc data

When receiving clc msg, the field length in smc_clc_msg_hdr indicates the
length of msg should be received from network and the value should not be
fully trusted as it is from the network. Once the value of length exceeds
the value of buflen in function smc_clc_wait_msg it may run into deadloop
when trying to drain the remaining data exceeding buflen.

This patch checks the return value of sock_recvmsg when draining data in
case of deadloop in draining.</Note>
    </Notes>
    <CVE>CVE-2024-57791</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

power: supply: gpio-charger: Fix set charge current limits

Fix set charge current limits for devices which allow to set the lowest
charge current limit to be greater zero. If requested charge current limit
is below lowest limit, the index equals current_limit_map_size which leads
to accessing memory beyond allocated memory.</Note>
    </Notes>
    <CVE>CVE-2024-57792</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

virt: tdx-guest: Just leak decrypted memory on unrecoverable errors

In CoCo VMs it is possible for the untrusted host to cause
set_memory_decrypted() to fail such that an error is returned
and the resulting memory is shared. Callers need to take care
to handle these errors to avoid returning decrypted (shared)
memory to the page allocator, which could lead to functional
or security issues.

Leak the decrypted memory when set_memory_decrypted() fails,
and don't need to print an error since set_memory_decrypted()
will call WARN_ONCE().</Note>
    </Notes>
    <CVE>CVE-2024-57793</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/rxe: Remove the direct link to net_device

The similar patch in siw is in the link:
https://git.kernel.org/rdma/rdma/c/16b87037b48889

This problem also occurred in RXE. The following analyze this problem.
In the following Call Traces:
"
BUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0 net/core/dev.c:8782
Read of size 4 at addr ffff8880554640b0 by task kworker/1:4/5295

CPU: 1 UID: 0 PID: 5295 Comm: kworker/1:4 Not tainted
6.12.0-rc3-syzkaller-00399-g9197b73fd7bb #0
Hardware name: Google Compute Engine/Google Compute Engine,
BIOS Google 09/13/2024
Workqueue: infiniband ib_cache_event_task
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0x169/0x550 mm/kasan/report.c:488
 kasan_report+0x143/0x180 mm/kasan/report.c:601
 dev_get_flags+0x188/0x1d0 net/core/dev.c:8782
 rxe_query_port+0x12d/0x260 drivers/infiniband/sw/rxe/rxe_verbs.c:60
 __ib_query_port drivers/infiniband/core/device.c:2111 [inline]
 ib_query_port+0x168/0x7d0 drivers/infiniband/core/device.c:2143
 ib_cache_update+0x1a9/0xb80 drivers/infiniband/core/cache.c:1494
 ib_cache_event_task+0xf3/0x1e0 drivers/infiniband/core/cache.c:1568
 process_one_work kernel/workqueue.c:3229 [inline]
 process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310
 worker_thread+0x870/0xd30 kernel/workqueue.c:3391
 kthread+0x2f2/0x390 kernel/kthread.c:389
 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
 &lt;/TASK&gt;
"

1). In the link [1],

"
 infiniband syz2: set down
"

This means that on 839.350575, the event ib_cache_event_task was sent andi
queued in ib_wq.

2). In the link [1],

"
 team0 (unregistering): Port device team_slave_0 removed
"

It indicates that before 843.251853, the net device should be freed.

3). In the link [1],

"
 BUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0
"

This means that on 850.559070, this slab-use-after-free problem occurred.

In all, on 839.350575, the event ib_cache_event_task was sent and queued
in ib_wq,

before 843.251853, the net device veth was freed.

on 850.559070, this event was executed, and the mentioned freed net device
was called. Thus, the above call trace occurred.

[1] https://syzkaller.appspot.com/x/log.txt?x=12e7025f980000</Note>
    </Notes>
    <CVE>CVE-2024-57795</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/dp_mst: Ensure mst_primary pointer is valid in drm_dp_mst_handle_up_req()

While receiving an MST up request message from one thread in
drm_dp_mst_handle_up_req(), the MST topology could be removed from
another thread via drm_dp_mst_topology_mgr_set_mst(false), freeing
mst_primary and setting drm_dp_mst_topology_mgr::mst_primary to NULL.
This could lead to a NULL deref/use-after-free of mst_primary in
drm_dp_mst_handle_up_req().

Avoid the above by holding a reference for mst_primary in
drm_dp_mst_handle_up_req() while it's used.

v2: Fix kfreeing the request if getting an mst_primary reference fails.</Note>
    </Notes>
    <CVE>CVE-2024-57798</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Skip restore TC rules for vport rep without loaded flag

During driver unload, unregister_netdev is called after unloading
vport rep. So, the mlx5e_rep_priv is already freed while trying to get
rpriv-&gt;netdev, or walk rpriv-&gt;tc_ht, which results in use-after-free.
So add the checking to make sure access the data of vport rep which is
still loaded.</Note>
    </Notes>
    <CVE>CVE-2024-57801</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netrom: check buffer length before accessing it

Syzkaller reports an uninit value read from ax25cmp when sending raw message
through ieee802154 implementation.

=====================================================
BUG: KMSAN: uninit-value in ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119
 ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119
 nr_dev_get+0x20e/0x450 net/netrom/nr_route.c:601
 nr_route_frame+0x1a2/0xfc0 net/netrom/nr_route.c:774
 nr_xmit+0x5a/0x1c0 net/netrom/nr_dev.c:144
 __netdev_start_xmit include/linux/netdevice.h:4940 [inline]
 netdev_start_xmit include/linux/netdevice.h:4954 [inline]
 xmit_one net/core/dev.c:3548 [inline]
 dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
 dev_queue_xmit include/linux/netdevice.h:3134 [inline]
 raw_sendmsg+0x654/0xc10 net/ieee802154/socket.c:299
 ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg net/socket.c:745 [inline]
 ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
 __sys_sendmsg net/socket.c:2667 [inline]
 __do_sys_sendmsg net/socket.c:2676 [inline]
 __se_sys_sendmsg net/socket.c:2674 [inline]
 __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b

Uninit was created at:
 slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
 slab_alloc_node mm/slub.c:3478 [inline]
 kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523
 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
 __alloc_skb+0x318/0x740 net/core/skbuff.c:651
 alloc_skb include/linux/skbuff.h:1286 [inline]
 alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334
 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2780
 sock_alloc_send_skb include/net/sock.h:1884 [inline]
 raw_sendmsg+0x36d/0xc10 net/ieee802154/socket.c:282
 ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg net/socket.c:745 [inline]
 ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
 __sys_sendmsg net/socket.c:2667 [inline]
 __do_sys_sendmsg net/socket.c:2676 [inline]
 __se_sys_sendmsg net/socket.c:2674 [inline]
 __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b

CPU: 0 PID: 5037 Comm: syz-executor166 Not tainted 6.7.0-rc7-syzkaller-00003-gfbafc3e621c3 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
=====================================================

This issue occurs because the skb buffer is too small, and it's actual
allocation is aligned. This hides an actual issue, which is that nr_route_frame
does not validate the buffer size before using it.

Fix this issue by checking skb-&gt;len before accessing any fields in skb-&gt;data.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.</Note>
    </Notes>
    <CVE>CVE-2024-57802</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: mpi3mr: Fix corrupt config pages PHY state is switched in sysfs

The driver, through the SAS transport, exposes a sysfs interface to
enable/disable PHYs in a controller/expander setup.  When multiple PHYs
are disabled and enabled in rapid succession, the persistent and current
config pages related to SAS IO unit/SAS Expander pages could get
corrupted.

Use separate memory for each config request.</Note>
    </Notes>
    <CVE>CVE-2024-57804</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

PCI: imx6: Fix suspend/resume support on i.MX6QDL

The suspend/resume functionality is currently broken on the i.MX6QDL
platform, as documented in the NXP errata (ERR005723):

  https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf

This patch addresses the issue by sharing most of the suspend/resume
sequences used by other i.MX devices, while avoiding modifications to
critical registers that disrupt the PCIe functionality. It targets the
same problem as the following downstream commit:

  https://github.com/nxp-imx/linux-imx/commit/4e92355e1f79d225ea842511fcfd42b343b32995

Unlike the downstream commit, this patch also resets the connected PCIe
device if possible. Without this reset, certain drivers, such as ath10k
or iwlwifi, will crash on resume. The device reset is also done by the
driver on other i.MX platforms, making this patch consistent with
existing practices.

Upon resuming, the kernel will hang and display an error. Here's an
example of the error encountered with the ath10k driver:

  ath10k_pci 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible
  Unhandled fault: imprecise external abort (0x1406) at 0x0106f944

Without this patch, suspend/resume will fail on i.MX6QDL devices if a
PCIe device is connected.

[kwilczynski: commit log, added tag for stable releases]</Note>
    </Notes>
    <CVE>CVE-2024-57809</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

s390/entry: Mark IRQ entries to fix stack depot warnings

The stack depot filters out everything outside of the top interrupt
context as an uninteresting or irrelevant part of the stack traces. This
helps with stack trace de-duplication, avoiding an explosion of saved
stack traces that share the same IRQ context code path but originate
from different randomly interrupted points, eventually exhausting the
stack depot.

Filtering uses in_irqentry_text() to identify functions within the
.irqentry.text and .softirqentry.text sections, which then become the
last stack trace entries being saved.

While __do_softirq() is placed into the .softirqentry.text section by
common code, populating .irqentry.text is architecture-specific.

Currently, the .irqentry.text section on s390 is empty, which prevents
stack depot filtering and de-duplication and could result in warnings
like:

Stack depot reached limit capacity
WARNING: CPU: 0 PID: 286113 at lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8

with PREEMPT and KASAN enabled.

Fix this by moving the IO/EXT interrupt handlers from .kprobes.text into
the .irqentry.text section and updating the kprobes blacklist to include
the .irqentry.text section.

This is done only for asynchronous interrupts and explicitly not for
program checks, which are synchronous and where the context beyond the
program check is important to preserve. Despite machine checks being
somewhat in between, they are extremely rare, and preserving context
when possible is also of value.

SVCs and Restart Interrupts are not relevant, one being always at the
boundary to user space and the other being a one-time thing.

IRQ entries filtering is also optionally used in ftrace function graph,
where the same logic applies.</Note>
    </Notes>
    <CVE>CVE-2024-57838</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

s390/cpum_sf: Handle CPU hotplug remove during sampling

CPU hotplug remove handling triggers the following function
call sequence:

   CPUHP_AP_PERF_S390_SF_ONLINE  --&gt; s390_pmu_sf_offline_cpu()
   ...
   CPUHP_AP_PERF_ONLINE          --&gt; perf_event_exit_cpu()

The s390 CPUMF sampling CPU hotplug handler invokes:

 s390_pmu_sf_offline_cpu()
 +--&gt;  cpusf_pmu_setup()
       +--&gt; setup_pmc_cpu()
            +--&gt; deallocate_buffers()

This function de-allocates all sampling data buffers (SDBs) allocated
for that CPU at event initialization. It also clears the
PMU_F_RESERVED bit. The CPU is gone and can not be sampled.

With the event still being active on the removed CPU, the CPU event
hotplug support in kernel performance subsystem triggers the
following function calls on the removed CPU:

  perf_event_exit_cpu()
  +--&gt; perf_event_exit_cpu_context()
       +--&gt; __perf_event_exit_context()
	    +--&gt; __perf_remove_from_context()
	         +--&gt; event_sched_out()
	              +--&gt; cpumsf_pmu_del()
	                   +--&gt; cpumsf_pmu_stop()
                                +--&gt; hw_perf_event_update()

to stop and remove the event. During removal of the event, the
sampling device driver tries to read out the remaining samples from
the sample data buffers (SDBs). But they have already been freed
(and may have been re-assigned). This may lead to a use after free
situation in which case the samples are most likely invalid. In the
best case the memory has not been reassigned and still contains
valid data.

Remedy this situation and check if the CPU is still in reserved
state (bit PMU_F_RESERVED set). In this case the SDBs have not been
released an contain valid data. This is always the case when
the event is removed (and no CPU hotplug off occured).
If the PMU_F_RESERVED bit is not set, the SDB buffers are gone.</Note>
    </Notes>
    <CVE>CVE-2024-57849</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

jffs2: Prevent rtime decompress memory corruption

The rtime decompression routine does not fully check bounds during the
entirety of the decompression pass and can corrupt memory outside the
decompression buffer if the compressed data is corrupted. This adds the
required check to prevent this failure mode.</Note>
    </Notes>
    <CVE>CVE-2024-57850</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/siw: Remove direct link to net_device

Do not manage a per device direct link to net_device. Rely
on associated ib_devices net_device management, not doubling
the effort locally. A badly managed local link to net_device
was causing a 'KASAN: slab-use-after-free' exception during
siw_query_port() call.</Note>
    </Notes>
    <CVE>CVE-2024-57857</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

arm64: ptrace: fix partial SETREGSET for NT_ARM_TAGGED_ADDR_CTRL

Currently tagged_addr_ctrl_set() doesn't initialize the temporary 'ctrl'
variable, and a SETREGSET call with a length of zero will leave this
uninitialized. Consequently tagged_addr_ctrl_set() will consume an
arbitrary value, potentially leaking up to 64 bits of memory from the
kernel stack. The read is limited to a specific slot on the stack, and
the issue does not provide a write mechanism.

As set_tagged_addr_ctrl() only accepts values where bits [63:4] zero and
rejects other values, a partial SETREGSET attempt will randomly succeed
or fail depending on the value of the uninitialized value, and the
exposure is significantly limited.

Fix this by initializing the temporary value before copying the regset
from userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG,
NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing
value of the tagged address ctrl will be retained.

The NT_ARM_TAGGED_ADDR_CTRL regset is only visible in the
user_aarch64_view used by a native AArch64 task to manipulate another
native AArch64 task. As get_tagged_addr_ctrl() only returns an error
value when called for a compat task, tagged_addr_ctrl_get() and
tagged_addr_ctrl_set() should never observe an error value from
get_tagged_addr_ctrl(). Add a WARN_ON_ONCE() to both to indicate that
such an error would be unexpected, and error handlnig is not missing in
either case.</Note>
    </Notes>
    <CVE>CVE-2024-57874</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/dp_mst: Fix resetting msg rx state after topology removal

If the MST topology is removed during the reception of an MST down reply
or MST up request sideband message, the
drm_dp_mst_topology_mgr::up_req_recv/down_rep_recv states could be reset
from one thread via drm_dp_mst_topology_mgr_set_mst(false), racing with
the reading/parsing of the message from another thread via
drm_dp_mst_handle_down_rep() or drm_dp_mst_handle_up_req(). The race is
possible since the reader/parser doesn't hold any lock while accessing
the reception state. This in turn can lead to a memory corruption in the
reader/parser as described by commit bd2fccac61b4 ("drm/dp_mst: Fix MST
sideband message body length check").

Fix the above by resetting the message reception state if needed before
reading/parsing a message. Another solution would be to hold the
drm_dp_mst_topology_mgr::lock for the whole duration of the message
reception/parsing in drm_dp_mst_handle_down_rep() and
drm_dp_mst_handle_up_req(), however this would require a bigger change.
Since the fix is also needed for stable, opting for the simpler solution
in this patch.</Note>
    </Notes>
    <CVE>CVE-2024-57876</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mptcp: fix TCP options overflow.

Syzbot reported the following splat:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 1 UID: 0 PID: 5836 Comm: sshd Not tainted 6.13.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024
RIP: 0010:_compound_head include/linux/page-flags.h:242 [inline]
RIP: 0010:put_page+0x23/0x260 include/linux/mm.h:1552
Code: 90 90 90 90 90 90 90 55 41 57 41 56 53 49 89 fe 48 bd 00 00 00 00 00 fc ff df e8 f8 5e 12 f8 49 8d 5e 08 48 89 d8 48 c1 e8 03 &lt;80&gt; 3c 28 00 74 08 48 89 df e8 8f c7 78 f8 48 8b 1b 48 89 de 48 83
RSP: 0000:ffffc90003916c90 EFLAGS: 00010202
RAX: 0000000000000001 RBX: 0000000000000008 RCX: ffff888030458000
RDX: 0000000000000100 RSI: 0000000000000000 RDI: 0000000000000000
RBP: dffffc0000000000 R08: ffffffff898ca81d R09: 1ffff110054414ac
R10: dffffc0000000000 R11: ffffed10054414ad R12: 0000000000000007
R13: ffff88802a20a542 R14: 0000000000000000 R15: 0000000000000000
FS:  00007f34f496e800(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f9d6ec9ec28 CR3: 000000004d260000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 skb_page_unref include/linux/skbuff_ref.h:43 [inline]
 __skb_frag_unref include/linux/skbuff_ref.h:56 [inline]
 skb_release_data+0x483/0x8a0 net/core/skbuff.c:1119
 skb_release_all net/core/skbuff.c:1190 [inline]
 __kfree_skb+0x55/0x70 net/core/skbuff.c:1204
 tcp_clean_rtx_queue net/ipv4/tcp_input.c:3436 [inline]
 tcp_ack+0x2442/0x6bc0 net/ipv4/tcp_input.c:4032
 tcp_rcv_state_process+0x8eb/0x44e0 net/ipv4/tcp_input.c:6805
 tcp_v4_do_rcv+0x77d/0xc70 net/ipv4/tcp_ipv4.c:1939
 tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2351
 ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205
 ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233
 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314
 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314
 __netif_receive_skb_one_core net/core/dev.c:5672 [inline]
 __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5785
 process_backlog+0x662/0x15b0 net/core/dev.c:6117
 __napi_poll+0xcb/0x490 net/core/dev.c:6883
 napi_poll net/core/dev.c:6952 [inline]
 net_rx_action+0x89b/0x1240 net/core/dev.c:7074
 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561
 __do_softirq kernel/softirq.c:595 [inline]
 invoke_softirq kernel/softirq.c:435 [inline]
 __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662
 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678
 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]
 sysvec_apic_timer_interrupt+0x57/0xc0 arch/x86/kernel/apic/apic.c:1049
 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702
RIP: 0033:0x7f34f4519ad5
Code: 85 d2 74 0d 0f 10 02 48 8d 54 24 20 0f 11 44 24 20 64 8b 04 25 18 00 00 00 85 c0 75 27 41 b8 08 00 00 00 b8 0f 01 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 76 75 48 8b 15 24 73 0d 00 f7 d8 64 89 02 48 83
RSP: 002b:00007ffec5b32ce0 EFLAGS: 00000246
RAX: 0000000000000001 RBX: 00000000000668a0 RCX: 00007f34f4519ad5
RDX: 00007ffec5b32d00 RSI: 0000000000000004 RDI: 0000564f4bc6cae0
RBP: 0000564f4bc6b5a0 R08: 0000000000000008 R09: 0000000000000000
R10: 00007ffec5b32de8 R11: 0000000000000246 R12: 0000564f48ea8aa4
R13: 0000000000000001 R14: 0000564f48ea93e8 R15: 00007ffec5b32d68
 &lt;/TASK&gt;

Eric noted a probable shinfo-&gt;nr_frags corruption, which indeed
occurs.

The root cause is a buggy MPTCP option len computation in some
circumstances: the ADD_ADDR option should be mutually exclusive
with DSS since the blamed commit.

Still, mptcp_established_options_add_addr() tries to set the
relevant info in mptcp_out_options, if 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-57882</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm: vmscan: account for free pages to prevent infinite Loop in throttle_direct_reclaim()

The task sometimes continues looping in throttle_direct_reclaim() because
allow_direct_reclaim(pgdat) keeps returning false.  

 #0 [ffff80002cb6f8d0] __switch_to at ffff8000080095ac
 #1 [ffff80002cb6f900] __schedule at ffff800008abbd1c
 #2 [ffff80002cb6f990] schedule at ffff800008abc50c
 #3 [ffff80002cb6f9b0] throttle_direct_reclaim at ffff800008273550
 #4 [ffff80002cb6fa20] try_to_free_pages at ffff800008277b68
 #5 [ffff80002cb6fae0] __alloc_pages_nodemask at ffff8000082c4660
 #6 [ffff80002cb6fc50] alloc_pages_vma at ffff8000082e4a98
 #7 [ffff80002cb6fca0] do_anonymous_page at ffff80000829f5a8
 #8 [ffff80002cb6fce0] __handle_mm_fault at ffff8000082a5974
 #9 [ffff80002cb6fd90] handle_mm_fault at ffff8000082a5bd4

At this point, the pgdat contains the following two zones:

        NODE: 4  ZONE: 0  ADDR: ffff00817fffe540  NAME: "DMA32"
          SIZE: 20480  MIN/LOW/HIGH: 11/28/45
          VM_STAT:
                NR_FREE_PAGES: 359
        NR_ZONE_INACTIVE_ANON: 18813
          NR_ZONE_ACTIVE_ANON: 0
        NR_ZONE_INACTIVE_FILE: 50
          NR_ZONE_ACTIVE_FILE: 0
          NR_ZONE_UNEVICTABLE: 0
        NR_ZONE_WRITE_PENDING: 0
                     NR_MLOCK: 0
                    NR_BOUNCE: 0
                   NR_ZSPAGES: 0
            NR_FREE_CMA_PAGES: 0

        NODE: 4  ZONE: 1  ADDR: ffff00817fffec00  NAME: "Normal"
          SIZE: 8454144  PRESENT: 98304  MIN/LOW/HIGH: 68/166/264
          VM_STAT:
                NR_FREE_PAGES: 146
        NR_ZONE_INACTIVE_ANON: 94668
          NR_ZONE_ACTIVE_ANON: 3
        NR_ZONE_INACTIVE_FILE: 735
          NR_ZONE_ACTIVE_FILE: 78
          NR_ZONE_UNEVICTABLE: 0
        NR_ZONE_WRITE_PENDING: 0
                     NR_MLOCK: 0
                    NR_BOUNCE: 0
                   NR_ZSPAGES: 0
            NR_FREE_CMA_PAGES: 0

In allow_direct_reclaim(), while processing ZONE_DMA32, the sum of
inactive/active file-backed pages calculated in zone_reclaimable_pages()
based on the result of zone_page_state_snapshot() is zero.  

Additionally, since this system lacks swap, the calculation of inactive/
active anonymous pages is skipped.

        crash&gt; p nr_swap_pages
        nr_swap_pages = $1937 = {
          counter = 0
        }

As a result, ZONE_DMA32 is deemed unreclaimable and skipped, moving on to
the processing of the next zone, ZONE_NORMAL, despite ZONE_DMA32 having
free pages significantly exceeding the high watermark.

The problem is that the pgdat-&gt;kswapd_failures hasn't been incremented.

        crash&gt; px ((struct pglist_data *) 0xffff00817fffe540)-&gt;kswapd_failures
        $1935 = 0x0

This is because the node deemed balanced.  The node balancing logic in
balance_pgdat() evaluates all zones collectively.  If one or more zones
(e.g., ZONE_DMA32) have enough free pages to meet their watermarks, the
entire node is deemed balanced.  This causes balance_pgdat() to exit early
before incrementing the kswapd_failures, as it considers the overall
memory state acceptable, even though some zones (like ZONE_NORMAL) remain
under significant pressure.


The patch ensures that zone_reclaimable_pages() includes free pages
(NR_FREE_PAGES) in its calculation when no other reclaimable pages are
available (e.g., file-backed or anonymous pages).  This change prevents
zones like ZONE_DMA32, which have sufficient free pages, from being
mistakenly deemed unreclaimable.  By doing so, the patch ensures proper
node balancing, avoids masking pressure on other zones like ZONE_NORMAL,
and prevents infinite loops in throttle_direct_reclaim() caused by
allow_direct_reclaim(pgdat) repeatedly returning false.


The kernel hangs due to a task stuck in throttle_direct_reclaim(), caused
by a node being incorrectly deemed balanced despite pressure in certain
zones, such as ZONE_NORMAL.  This issue arises from
zone_reclaimable_pages
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-57884</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm: adv7511: Fix use-after-free in adv7533_attach_dsi()

The host_node pointer was assigned and freed in adv7533_parse_dt(), and
later, adv7533_attach_dsi() uses the same. Fix this use-after-free issue
by  dropping of_node_put() in adv7533_parse_dt() and calling of_node_put()
in error path of probe() and also in the remove().</Note>
    </Notes>
    <CVE>CVE-2024-57887</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

workqueue: Do not warn when cancelling WQ_MEM_RECLAIM work from !WQ_MEM_RECLAIM worker

After commit
746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM")
amdgpu started seeing the following warning:

 [ ] workqueue: WQ_MEM_RECLAIM sdma0:drm_sched_run_job_work [gpu_sched] is flushing !WQ_MEM_RECLAIM events:amdgpu_device_delay_enable_gfx_off [amdgpu]
...
 [ ] Workqueue: sdma0 drm_sched_run_job_work [gpu_sched]
...
 [ ] Call Trace:
 [ ]  &lt;TASK&gt;
...
 [ ]  ? check_flush_dependency+0xf5/0x110
...
 [ ]  cancel_delayed_work_sync+0x6e/0x80
 [ ]  amdgpu_gfx_off_ctrl+0xab/0x140 [amdgpu]
 [ ]  amdgpu_ring_alloc+0x40/0x50 [amdgpu]
 [ ]  amdgpu_ib_schedule+0xf4/0x810 [amdgpu]
 [ ]  ? drm_sched_run_job_work+0x22c/0x430 [gpu_sched]
 [ ]  amdgpu_job_run+0xaa/0x1f0 [amdgpu]
 [ ]  drm_sched_run_job_work+0x257/0x430 [gpu_sched]
 [ ]  process_one_work+0x217/0x720
...
 [ ]  &lt;/TASK&gt;

The intent of the verifcation done in check_flush_depedency is to ensure
forward progress during memory reclaim, by flagging cases when either a
memory reclaim process, or a memory reclaim work item is flushed from a
context not marked as memory reclaim safe.

This is correct when flushing, but when called from the
cancel(_delayed)_work_sync() paths it is a false positive because work is
either already running, or will not be running at all. Therefore
cancelling it is safe and we can relax the warning criteria by letting the
helper know of the calling context.

References: 746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM")</Note>
    </Notes>
    <CVE>CVE-2024-57888</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pinctrl: mcp23s08: Fix sleeping in atomic context due to regmap locking

If a device uses MCP23xxx IO expander to receive IRQs, the following
bug can happen:

  BUG: sleeping function called from invalid context
    at kernel/locking/mutex.c:283
  in_atomic(): 1, irqs_disabled(): 1, non_block: 0, ...
  preempt_count: 1, expected: 0
  ...
  Call Trace:
  ...
  __might_resched+0x104/0x10e
  __might_sleep+0x3e/0x62
  mutex_lock+0x20/0x4c
  regmap_lock_mutex+0x10/0x18
  regmap_update_bits_base+0x2c/0x66
  mcp23s08_irq_set_type+0x1ae/0x1d6
  __irq_set_trigger+0x56/0x172
  __setup_irq+0x1e6/0x646
  request_threaded_irq+0xb6/0x160
  ...

We observed the problem while experimenting with a touchscreen driver which
used MCP23017 IO expander (I2C).

The regmap in the pinctrl-mcp23s08 driver uses a mutex for protection from
concurrent accesses, which is the default for regmaps without .fast_io,
.disable_locking, etc.

mcp23s08_irq_set_type() calls regmap_update_bits_base(), and the latter
locks the mutex.

However, __setup_irq() locks desc-&gt;lock spinlock before calling these
functions. As a result, the system tries to lock the mutex whole holding
the spinlock.

It seems, the internal regmap locks are not needed in this driver at all.
mcp-&gt;lock seems to protect the regmap from concurrent accesses already,
except, probably, in mcp_pinconf_get/set.

mcp23s08_irq_set_type() and mcp23s08_irq_mask/unmask() are called under
chip_bus_lock(), which calls mcp23s08_irq_bus_lock(). The latter takes
mcp-&gt;lock and enables regmap caching, so that the potentially slow I2C
accesses are deferred until chip_bus_unlock().

The accesses to the regmap from mcp23s08_probe_one() do not need additional
locking.

In all remaining places where the regmap is accessed, except
mcp_pinconf_get/set(), the driver already takes mcp-&gt;lock.

This patch adds locking in mcp_pinconf_get/set() and disables internal
locking in the regmap config. Among other things, it fixes the sleeping
in atomic context described above.</Note>
    </Notes>
    <CVE>CVE-2024-57889</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/uverbs: Prevent integer overflow issue

In the expression "cmd.wqe_size * cmd.wr_count", both variables are u32
values that come from the user so the multiplication can lead to integer
wrapping.  Then we pass the result to uverbs_request_next_ptr() which also
could potentially wrap.  The "cmd.sge_count * sizeof(struct ib_uverbs_sge)"
multiplication can also overflow on 32bit systems although it's fine on
64bit systems.

This patch does two things.  First, I've re-arranged the condition in
uverbs_request_next_ptr() so that the use controlled variable "len" is on
one side of the comparison by itself without any math.  Then I've modified
all the callers to use size_mul() for the multiplications.</Note>
    </Notes>
    <CVE>CVE-2024-57890</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix slab-use-after-free due to dangling pointer dqi_priv

When mounting ocfs2 and then remounting it as read-only, a
slab-use-after-free occurs after the user uses a syscall to
quota_getnextquota.  Specifically, sb_dqinfo(sb, type)-&gt;dqi_priv is the
dangling pointer.

During the remounting process, the pointer dqi_priv is freed but is never
set as null leaving it to be accessed.  Additionally, the read-only option
for remounting sets the DQUOT_SUSPENDED flag instead of setting the
DQUOT_USAGE_ENABLED flags.  Moreover, later in the process of getting the
next quota, the function ocfs2_get_next_id is called and only checks the
quota usage flags and not the quota suspended flags.

To fix this, I set dqi_priv to null when it is freed after remounting with
read-only and put a check for DQUOT_SUSPENDED in ocfs2_get_next_id.

[akpm@linux-foundation.org: coding-style cleanups]</Note>
    </Notes>
    <CVE>CVE-2024-57892</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: seq: oss: Fix races at processing SysEx messages

OSS sequencer handles the SysEx messages split in 6 bytes packets, and
ALSA sequencer OSS layer tries to combine those.  It stores the data
in the internal buffer and this access is racy as of now, which may
lead to the out-of-bounds access.

As a temporary band-aid fix, introduce a mutex for serializing the
process of the SysEx message packets.</Note>
    </Notes>
    <CVE>CVE-2024-57893</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: flush delalloc workers queue before stopping cleaner kthread during unmount

During the unmount path, at close_ctree(), we first stop the cleaner
kthread, using kthread_stop() which frees the associated task_struct, and
then stop and destroy all the work queues. However after we stopped the
cleaner we may still have a worker from the delalloc_workers queue running
inode.c:submit_compressed_extents(), which calls btrfs_add_delayed_iput(),
which in turn tries to wake up the cleaner kthread - which was already
destroyed before, resulting in a use-after-free on the task_struct.

Syzbot reported this with the following stack traces:

  BUG: KASAN: slab-use-after-free in __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089
  Read of size 8 at addr ffff8880259d2818 by task kworker/u8:3/52

  CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.13.0-rc1-syzkaller-00002-gcdd30ebb1b9f #0
  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
  Workqueue: btrfs-delalloc btrfs_work_helper
  Call Trace:
   &lt;TASK&gt;
   __dump_stack lib/dump_stack.c:94 [inline]
   dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
   print_address_description mm/kasan/report.c:378 [inline]
   print_report+0x169/0x550 mm/kasan/report.c:489
   kasan_report+0x143/0x180 mm/kasan/report.c:602
   __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089
   lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849
   __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
   _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162
   class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline]
   try_to_wake_up+0xc2/0x1470 kernel/sched/core.c:4205
   submit_compressed_extents+0xdf/0x16e0 fs/btrfs/inode.c:1615
   run_ordered_work fs/btrfs/async-thread.c:288 [inline]
   btrfs_work_helper+0x96f/0xc40 fs/btrfs/async-thread.c:324
   process_one_work kernel/workqueue.c:3229 [inline]
   process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310
   worker_thread+0x870/0xd30 kernel/workqueue.c:3391
   kthread+0x2f0/0x390 kernel/kthread.c:389
   ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
   &lt;/TASK&gt;

  Allocated by task 2:
   kasan_save_stack mm/kasan/common.c:47 [inline]
   kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
   unpoison_slab_object mm/kasan/common.c:319 [inline]
   __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345
   kasan_slab_alloc include/linux/kasan.h:250 [inline]
   slab_post_alloc_hook mm/slub.c:4104 [inline]
   slab_alloc_node mm/slub.c:4153 [inline]
   kmem_cache_alloc_node_noprof+0x1d9/0x380 mm/slub.c:4205
   alloc_task_struct_node kernel/fork.c:180 [inline]
   dup_task_struct+0x57/0x8c0 kernel/fork.c:1113
   copy_process+0x5d1/0x3d50 kernel/fork.c:2225
   kernel_clone+0x223/0x870 kernel/fork.c:2807
   kernel_thread+0x1bc/0x240 kernel/fork.c:2869
   create_kthread kernel/kthread.c:412 [inline]
   kthreadd+0x60d/0x810 kernel/kthread.c:767
   ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

  Freed by task 24:
   kasan_save_stack mm/kasan/common.c:47 [inline]
   kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
   kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582
   poison_slab_object mm/kasan/common.c:247 [inline]
   __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264
   kasan_slab_free include/linux/kasan.h:233 [inline]
   slab_free_hook mm/slub.c:2338 [inline]
   slab_free mm/slub.c:4598 [inline]
   kmem_cache_free+0x195/0x410 mm/slub.c:4700
   put_task_struct include/linux/sched/task.h:144 [inline]
   delayed_put_task_struct+0x125/0x300 kernel/exit.c:227
   rcu_do_batch kernel/rcu/tree.c:2567 [inline]
   rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823
   handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:554
   run_ksoftirqd+0xca/0x130 kernel/softirq.c:943
  
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-57896</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Correct the migration DMA map direction

The SVM DMA device map direction should be set the same as
the DMA unmap setting, otherwise the DMA core will report
the following warning.

Before finialize this solution, there're some discussion on
the DMA mapping type(stream-based or coherent) in this KFD
migration case, followed by https://lore.kernel.org/all/04d4ab32
-45a1-4b88-86ee-fb0f35a0ca40@amd.com/T/.

As there's no dma_sync_single_for_*() in the DMA buffer accessed
that because this migration operation should be sync properly and
automatically. Give that there's might not be a performance problem
in various cache sync policy of DMA sync. Therefore, in order to
simplify the DMA direction setting alignment, let's set the DMA map
direction as BIDIRECTIONAL.

[  150.834218] WARNING: CPU: 8 PID: 1812 at kernel/dma/debug.c:1028 check_unmap+0x1cc/0x930
[  150.834225] Modules linked in: amdgpu(OE) amdxcp drm_exec(OE) gpu_sched drm_buddy(OE) drm_ttm_helper(OE) ttm(OE) drm_suballoc_helper(OE) drm_display_helper(OE) drm_kms_helper(OE) i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc sch_fq_codel intel_rapl_msr amd_atl intel_rapl_common snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd snd_pci_acp6x snd_hda_codec snd_acp_config snd_hda_core snd_hwdep snd_soc_acpi kvm_amd sunrpc snd_pcm kvm binfmt_misc snd_seq_midi crct10dif_pclmul snd_seq_midi_event ghash_clmulni_intel sha512_ssse3 snd_rawmidi nls_iso8859_1 sha256_ssse3 sha1_ssse3 snd_seq aesni_intel snd_seq_device crypto_simd snd_timer cryptd input_leds
[  150.834310]  wmi_bmof serio_raw k10temp rapl snd sp5100_tco ipmi_devintf soundcore ccp ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport efi_pstore drm(OE) ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii
[  150.834354] CPU: 8 PID: 1812 Comm: rocrtst64 Tainted: G           OE      6.10.0-custom #492
[  150.834358] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021
[  150.834360] RIP: 0010:check_unmap+0x1cc/0x930
[  150.834363] Code: c0 4c 89 4d c8 e8 34 bf 86 00 4c 8b 4d c8 4c 8b 45 c0 48 8b 4d b8 48 89 c6 41 57 4c 89 ea 48 c7 c7 80 49 b4 84 e8 b4 81 f3 ff &lt;0f&gt; 0b 48 c7 c7 04 83 ac 84 e8 76 ba fc ff 41 8b 76 4c 49 8d 7e 50
[  150.834365] RSP: 0018:ffffaac5023739e0 EFLAGS: 00010086
[  150.834368] RAX: 0000000000000000 RBX: ffffffff8566a2e0 RCX: 0000000000000027
[  150.834370] RDX: ffff8f6a8f621688 RSI: 0000000000000001 RDI: ffff8f6a8f621680
[  150.834372] RBP: ffffaac502373a30 R08: 00000000000000c9 R09: ffffaac502373850
[  150.834373] R10: ffffaac502373848 R11: ffffffff84f46328 R12: ffffaac502373a40
[  150.834375] R13: ffff8f6741045330 R14: ffff8f6741a77700 R15: ffffffff84ac831b
[  150.834377] FS:  00007faf0fc94c00(0000) GS:ffff8f6a8f600000(0000) knlGS:0000000000000000
[  150.834379] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  150.834381] CR2: 00007faf0b600020 CR3: 000000010a52e000 CR4: 0000000000350ef0
[  150.834383] Call Trace:
[  150.834385]  &lt;TASK&gt;
[  150.834387]  ? show_regs+0x6d/0x80
[  150.834393]  ? __warn+0x8c/0x140
[  150.834397]  ? check_unmap+0x1cc/0x930
[  150.834400]  ? report_bug+0x193/0x1a0
[  150.834406]  ? handle_bug+0x46/0x80
[  150.834410]  ? exc_invalid_op+0x1d/0x80
[  150.834413]  ? asm_exc_invalid_op+0x1f/0x30
[  150.834420]  ? check_unmap+0x1cc/0x930
[  150.834425]  debug_dma_unmap_page+0x86/0x90
[  150.834431]  ? srso_return_thunk+0x5/0x5f
[  150.834435] 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-57897</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: fix mbss changed flags corruption on 32 bit systems

On 32-bit systems, the size of an unsigned long is 4 bytes,
while a u64 is 8 bytes. Therefore, when using
or_each_set_bit(bit, &amp;bits, sizeof(changed) * BITS_PER_BYTE),
the code is incorrectly searching for a bit in a 32-bit
variable that is expected to be 64 bits in size,
leading to incorrect bit finding.

Solution: Ensure that the size of the bits variable is correctly
adjusted for each architecture.

 Call Trace:
  ? show_regs+0x54/0x58
  ? __warn+0x6b/0xd4
  ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211]
  ? report_bug+0x113/0x150
  ? exc_overflow+0x30/0x30
  ? handle_bug+0x27/0x44
  ? exc_invalid_op+0x18/0x50
  ? handle_exception+0xf6/0xf6
  ? exc_overflow+0x30/0x30
  ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211]
  ? exc_overflow+0x30/0x30
  ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211]
  ? ieee80211_mesh_work+0xff/0x260 [mac80211]
  ? cfg80211_wiphy_work+0x72/0x98 [cfg80211]
  ? process_one_work+0xf1/0x1fc
  ? worker_thread+0x2c0/0x3b4
  ? kthread+0xc7/0xf0
  ? mod_delayed_work_on+0x4c/0x4c
  ? kthread_complete_and_exit+0x14/0x14
  ? ret_from_fork+0x24/0x38
  ? kthread_complete_and_exit+0x14/0x14
  ? ret_from_fork_asm+0xf/0x14
  ? entry_INT80_32+0xf0/0xf0

[restore no-op path for no changes]</Note>
    </Notes>
    <CVE>CVE-2024-57899</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: restrict SO_REUSEPORT to inet sockets

After blamed commit, crypto sockets could accidentally be destroyed
from RCU call back, as spotted by zyzbot [1].

Trying to acquire a mutex in RCU callback is not allowed.

Restrict SO_REUSEPORT socket option to inet sockets.

v1 of this patch supported TCP, UDP and SCTP sockets,
but fcnal-test.sh test needed RAW and ICMP support.

[1]
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:562
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 24, name: ksoftirqd/1
preempt_count: 100, expected: 0
RCU nest depth: 0, expected: 0
1 lock held by ksoftirqd/1/24:
  #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:337 [inline]
  #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2561 [inline]
  #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_core+0xa37/0x17a0 kernel/rcu/tree.c:2823
Preemption disabled at:
 [&lt;ffffffff8161c8c8&gt;] softirq_handle_begin kernel/softirq.c:402 [inline]
 [&lt;ffffffff8161c8c8&gt;] handle_softirqs+0x128/0x9b0 kernel/softirq.c:537
CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.13.0-rc3-syzkaller-00174-ga024e377efed #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Call Trace:
 &lt;TASK&gt;
  __dump_stack lib/dump_stack.c:94 [inline]
  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
  __might_resched+0x5d4/0x780 kernel/sched/core.c:8758
  __mutex_lock_common kernel/locking/mutex.c:562 [inline]
  __mutex_lock+0x131/0xee0 kernel/locking/mutex.c:735
  crypto_put_default_null_skcipher+0x18/0x70 crypto/crypto_null.c:179
  aead_release+0x3d/0x50 crypto/algif_aead.c:489
  alg_do_release crypto/af_alg.c:118 [inline]
  alg_sock_destruct+0x86/0xc0 crypto/af_alg.c:502
  __sk_destruct+0x58/0x5f0 net/core/sock.c:2260
  rcu_do_batch kernel/rcu/tree.c:2567 [inline]
  rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823
  handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561
  run_ksoftirqd+0xca/0x130 kernel/softirq.c:950
  smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164
  kthread+0x2f0/0x390 kernel/kthread.c:389
  ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-57903</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iio: adc: at91: call input_free_device() on allocated iio_dev

Current implementation of at91_ts_register() calls input_free_deivce()
on st-&gt;ts_input, however, the err label can be reached before the
allocated iio_dev is stored to st-&gt;ts_input. Thus call
input_free_device() on input instead of st-&gt;ts_input.</Note>
    </Notes>
    <CVE>CVE-2024-57904</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iio: adc: ti-ads8688: fix information leak in triggered buffer

The 'buffer' local array is used to push data to user space from a
triggered buffer, but it does not set values for inactive channels, as
it only uses iio_for_each_active_channel() to assign new values.

Initialize the array to zero before using it to avoid pushing
uninitialized information to userspace.</Note>
    </Notes>
    <CVE>CVE-2024-57906</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iio: adc: rockchip_saradc: fix information leak in triggered buffer

The 'data' local struct is used to push data to user space from a
triggered buffer, but it does not set values for inactive channels, as
it only uses iio_for_each_active_channel() to assign new values.

Initialize the struct to zero before using it to avoid pushing
uninitialized information to userspace.</Note>
    </Notes>
    <CVE>CVE-2024-57907</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iio: imu: kmx61: fix information leak in triggered buffer

The 'buffer' local array is used to push data to user space from a
triggered buffer, but it does not set values for inactive channels, as
it only uses iio_for_each_active_channel() to assign new values.

Initialize the array to zero before using it to avoid pushing
uninitialized information to userspace.</Note>
    </Notes>
    <CVE>CVE-2024-57908</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iio: light: vcnl4035: fix information leak in triggered buffer

The 'buffer' local array is used to push data to userspace from a
triggered buffer, but it does not set an initial value for the single
data element, which is an u16 aligned to 8 bytes. That leaves at least
4 bytes uninitialized even after writing an integer value with
regmap_read().

Initialize the array to zero before using it to avoid pushing
uninitialized information to userspace.</Note>
    </Notes>
    <CVE>CVE-2024-57910</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iio: dummy: iio_simply_dummy_buffer: fix information leak in triggered buffer

The 'data' array is allocated via kmalloc() and it is used to push data
to user space from a triggered buffer, but it does not set values for
inactive channels, as it only uses iio_for_each_active_channel()
to assign new values.

Use kzalloc for the memory allocation to avoid pushing uninitialized
information to userspace.</Note>
    </Notes>
    <CVE>CVE-2024-57911</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iio: pressure: zpa2326: fix information leak in triggered buffer

The 'sample' local struct is used to push data to user space from a
triggered buffer, but it has a hole between the temperature and the
timestamp (u32 pressure, u16 temperature, GAP, u64 timestamp).
This hole is never initialized.

Initialize the struct to zero before using it to avoid pushing
uninitialized information to userspace.</Note>
    </Notes>
    <CVE>CVE-2024-57912</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: f_fs: Remove WARN_ON in functionfs_bind

This commit addresses an issue related to below kernel panic where
panic_on_warn is enabled. It is caused by the unnecessary use of WARN_ON
in functionsfs_bind, which easily leads to the following scenarios.

1.adb_write in adbd               2. UDC write via configfs
  =================	             =====================

-&gt;usb_ffs_open_thread()           -&gt;UDC write
 -&gt;open_functionfs()               -&gt;configfs_write_iter()
  -&gt;adb_open()                      -&gt;gadget_dev_desc_UDC_store()
   -&gt;adb_write()                     -&gt;usb_gadget_register_driver_owner
                                      -&gt;driver_register()
-&gt;StartMonitor()                       -&gt;bus_add_driver()
 -&gt;adb_read()                           -&gt;gadget_bind_driver()
&lt;times-out without BIND event&gt;           -&gt;configfs_composite_bind()
                                          -&gt;usb_add_function()
-&gt;open_functionfs()                        -&gt;ffs_func_bind()
 -&gt;adb_open()                               -&gt;functionfs_bind()
                                       &lt;ffs-&gt;state !=FFS_ACTIVE&gt;

The adb_open, adb_read, and adb_write operations are invoked from the
daemon, but trying to bind the function is a process that is invoked by
UDC write through configfs, which opens up the possibility of a race
condition between the two paths. In this race scenario, the kernel panic
occurs due to the WARN_ON from functionfs_bind when panic_on_warn is
enabled. This commit fixes the kernel panic by removing the unnecessary
WARN_ON.

Kernel panic - not syncing: kernel: panic_on_warn set ...
[   14.542395] Call trace:
[   14.542464]  ffs_func_bind+0x1c8/0x14a8
[   14.542468]  usb_add_function+0xcc/0x1f0
[   14.542473]  configfs_composite_bind+0x468/0x588
[   14.542478]  gadget_bind_driver+0x108/0x27c
[   14.542483]  really_probe+0x190/0x374
[   14.542488]  __driver_probe_device+0xa0/0x12c
[   14.542492]  driver_probe_device+0x3c/0x220
[   14.542498]  __driver_attach+0x11c/0x1fc
[   14.542502]  bus_for_each_dev+0x104/0x160
[   14.542506]  driver_attach+0x24/0x34
[   14.542510]  bus_add_driver+0x154/0x270
[   14.542514]  driver_register+0x68/0x104
[   14.542518]  usb_gadget_register_driver_owner+0x48/0xf4
[   14.542523]  gadget_dev_desc_UDC_store+0xf8/0x144
[   14.542526]  configfs_write_iter+0xf0/0x138</Note>
    </Notes>
    <CVE>CVE-2024-57913</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2024-57915</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

misc: microchip: pci1xxxx: Resolve kernel panic during GPIO IRQ handling

Resolve kernel panic caused by improper handling of IRQs while
accessing GPIO values. This is done by replacing generic_handle_irq with
handle_nested_irq.</Note>
    </Notes>
    <CVE>CVE-2024-57916</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

topology: Keep the cpumask unchanged when printing cpumap

During fuzz testing, the following warning was discovered:

 different return values (15 and 11) from vsnprintf("%*pbl
 ", ...)

 test:keyward is WARNING in kvasprintf
 WARNING: CPU: 55 PID: 1168477 at lib/kasprintf.c:30 kvasprintf+0x121/0x130
 Call Trace:
  kvasprintf+0x121/0x130
  kasprintf+0xa6/0xe0
  bitmap_print_to_buf+0x89/0x100
  core_siblings_list_read+0x7e/0xb0
  kernfs_file_read_iter+0x15b/0x270
  new_sync_read+0x153/0x260
  vfs_read+0x215/0x290
  ksys_read+0xb9/0x160
  do_syscall_64+0x56/0x100
  entry_SYSCALL_64_after_hwframe+0x78/0xe2

The call trace shows that kvasprintf() reported this warning during the
printing of core_siblings_list. kvasprintf() has several steps:

 (1) First, calculate the length of the resulting formatted string.

 (2) Allocate a buffer based on the returned length.

 (3) Then, perform the actual string formatting.

 (4) Check whether the lengths of the formatted strings returned in
     steps (1) and (2) are consistent.

If the core_cpumask is modified between steps (1) and (3), the lengths
obtained in these two steps may not match. Indeed our test includes cpu
hotplugging, which should modify core_cpumask while printing.

To fix this issue, cache the cpumask into a temporary variable before
calling cpumap_print_{list, cpumask}_to_buf(), to keep it unchanged
during the printing process.</Note>
    </Notes>
    <CVE>CVE-2024-57917</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add check for granularity in dml ceil/floor helpers

[Why]
Wrapper functions for dcn_bw_ceil2() and dcn_bw_floor2()
should check for granularity is non zero to avoid assert and
divide-by-zero error in dcn_bw_ functions.

[How]
Add check for granularity 0.

(cherry picked from commit f6e09701c3eb2ccb8cb0518e0b67f1c69742a4ec)</Note>
    </Notes>
    <CVE>CVE-2024-57922</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/mediatek: Set private-&gt;all_drm_private[i]-&gt;drm to NULL if mtk_drm_bind returns err

The pointer need to be set to NULL, otherwise KASAN complains about
use-after-free. Because in mtk_drm_bind, all private's drm are set
as follows.

private-&gt;all_drm_private[i]-&gt;drm = drm;

And drm will be released by drm_dev_put in case mtk_drm_kms_init returns
failure. However, the shutdown path still accesses the previous allocated
memory in drm_atomic_helper_shutdown.

[   84.874820] watchdog: watchdog0: watchdog did not stop!
[   86.512054] ==================================================================
[   86.513162] BUG: KASAN: use-after-free in drm_atomic_helper_shutdown+0x33c/0x378
[   86.514258] Read of size 8 at addr ffff0000d46fc068 by task shutdown/1
[   86.515213]
[   86.515455] CPU: 1 UID: 0 PID: 1 Comm: shutdown Not tainted 6.13.0-rc1-mtk+gfa1a78e5d24b-dirty #55
[   86.516752] Hardware name: Unknown Product/Unknown Product, BIOS 2022.10 10/01/2022
[   86.517960] Call trace:
[   86.518333]  show_stack+0x20/0x38 (C)
[   86.518891]  dump_stack_lvl+0x90/0xd0
[   86.519443]  print_report+0xf8/0x5b0
[   86.519985]  kasan_report+0xb4/0x100
[   86.520526]  __asan_report_load8_noabort+0x20/0x30
[   86.521240]  drm_atomic_helper_shutdown+0x33c/0x378
[   86.521966]  mtk_drm_shutdown+0x54/0x80
[   86.522546]  platform_shutdown+0x64/0x90
[   86.523137]  device_shutdown+0x260/0x5b8
[   86.523728]  kernel_restart+0x78/0xf0
[   86.524282]  __do_sys_reboot+0x258/0x2f0
[   86.524871]  __arm64_sys_reboot+0x90/0xd8
[   86.525473]  invoke_syscall+0x74/0x268
[   86.526041]  el0_svc_common.constprop.0+0xb0/0x240
[   86.526751]  do_el0_svc+0x4c/0x70
[   86.527251]  el0_svc+0x4c/0xc0
[   86.527719]  el0t_64_sync_handler+0x144/0x168
[   86.528367]  el0t_64_sync+0x198/0x1a0
[   86.528920]
[   86.529157] The buggy address belongs to the physical page:
[   86.529972] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff0000d46fd4d0 pfn:0x1146fc
[   86.531319] flags: 0xbfffc0000000000(node=0|zone=2|lastcpupid=0xffff)
[   86.532267] raw: 0bfffc0000000000 0000000000000000 dead000000000122 0000000000000000
[   86.533390] raw: ffff0000d46fd4d0 0000000000000000 00000000ffffffff 0000000000000000
[   86.534511] page dumped because: kasan: bad access detected
[   86.535323]
[   86.535559] Memory state around the buggy address:
[   86.536265]  ffff0000d46fbf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[   86.537314]  ffff0000d46fbf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[   86.538363] &gt;ffff0000d46fc000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[   86.544733]                                                           ^
[   86.551057]  ffff0000d46fc080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[   86.557510]  ffff0000d46fc100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[   86.563928] ==================================================================
[   86.571093] Disabling lock debugging due to kernel taint
[   86.577642] Unable to handle kernel paging request at virtual address e0e9c0920000000b
[   86.581834] KASAN: maybe wild-memory-access in range [0x0752049000000058-0x075204900000005f]
...</Note>
    </Notes>
    <CVE>CVE-2024-57926</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dm array: fix releasing a faulty array block twice in dm_array_cursor_end

When dm_bm_read_lock() fails due to locking or checksum errors, it
releases the faulty block implicitly while leaving an invalid output
pointer behind. The caller of dm_bm_read_lock() should not operate on
this invalid dm_block pointer, or it will lead to undefined result.
For example, the dm_array_cursor incorrectly caches the invalid pointer
on reading a faulty array block, causing a double release in
dm_array_cursor_end(), then hitting the BUG_ON in dm-bufio cache_put().

Reproduce steps:

1. initialize a cache device

dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"
dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"
dmsetup create corig --table "0 524288 linear /dev/sdc $262144"
dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1
dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \
/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"

2. wipe the second array block offline

dmsteup remove cache cmeta cdata corig
mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \
2&gt;/dev/null | hexdump -e '1/8 "%u\n"')
ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \
2&gt;/dev/null | hexdump -e '1/8 "%u\n"')
dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock

3. try reopen the cache device

dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"
dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"
dmsetup create corig --table "0 524288 linear /dev/sdc $262144"
dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \
/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"

Kernel logs:

(snip)
device-mapper: array: array_block_check failed: blocknr 0 != wanted 10
device-mapper: block manager: array validator check failed for block 10
device-mapper: array: get_ablock failed
device-mapper: cache metadata: dm_array_cursor_next for mapping failed
------------[ cut here ]------------
kernel BUG at drivers/md/dm-bufio.c:638!

Fix by setting the cached block pointer to NULL on errors.

In addition to the reproducer described above, this fix can be
verified using the "array_cursor/damaged" test in dm-unit:
  dm-unit run /pdata/array_cursor/damaged --kernel-dir &lt;KERNEL_DIR&gt;</Note>
    </Notes>
    <CVE>CVE-2024-57929</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

selinux: ignore unknown extended permissions

When evaluating extended permissions, ignore unknown permissions instead
of calling BUG(). This commit ensures that future permissions can be
added without interfering with older kernels.</Note>
    </Notes>
    <CVE>CVE-2024-57931</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gve: guard XDP xmit NDO on existence of xdp queues

In GVE, dedicated XDP queues only exist when an XDP program is installed
and the interface is up. As such, the NDO XDP XMIT callback should
return early if either of these conditions are false.

In the case of no loaded XDP program, priv-&gt;num_xdp_queues=0 which can
cause a divide-by-zero error, and in the case of interface down,
num_xdp_queues remains untouched to persist XDP queue count for the next
interface up, but the TX pointer itself would be NULL.

The XDP xmit callback also needs to synchronize with a device
transitioning from open to close. This synchronization will happen via
the GVE_PRIV_FLAGS_NAPI_ENABLED bit along with a synchronize_net() call,
which waits for any RCU critical sections at call-time to complete.</Note>
    </Notes>
    <CVE>CVE-2024-57932</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gve: guard XSK operations on the existence of queues

This patch predicates the enabling and disabling of XSK pools on the
existence of queues. As it stands, if the interface is down, disabling
or enabling XSK pools would result in a crash, as the RX queue pointer
would be NULL. XSK pool registration will occur as part of the next
interface up.

Similarly, xsk_wakeup needs be guarded against queues disappearing
while the function is executing, so a check against the
GVE_PRIV_FLAGS_NAPI_ENABLED flag is added to synchronize with the
disabling of the bit and the synchronize_net() in gve_turndown.</Note>
    </Notes>
    <CVE>CVE-2024-57933</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/hns: Fix accessing invalid dip_ctx during destroying QP

If it fails to modify QP to RTR, dip_ctx will not be attached. And
during detroying QP, the invalid dip_ctx pointer will be accessed.</Note>
    </Notes>
    <CVE>CVE-2024-57935</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/bnxt_re: Fix max SGEs for the Work Request

Gen P7 supports up to 13 SGEs for now. WQE software structure
can hold only 6 now. Since the max send sge is reported as
13, the stack can give requests up to 13 SGEs. This is causing
traffic failures and system crashes.

Use the define for max SGE supported for variable size. This
will work for both static and variable WQEs.</Note>
    </Notes>
    <CVE>CVE-2024-57936</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/sctp: Prevent autoclose integer overflow in sctp_association_init()

While by default max_autoclose equals to INT_MAX / HZ, one may set
net.sctp.max_autoclose to UINT_MAX. There is code in
sctp_association_init() that can consequently trigger overflow.</Note>
    </Notes>
    <CVE>CVE-2024-57938</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

exfat: fix the infinite loop in exfat_readdir()

If the file system is corrupted so that a cluster is linked to
itself in the cluster chain, and there is an unused directory
entry in the cluster, 'dentry' will not be incremented, causing
condition 'dentry &lt; max_dentries' unable to prevent an infinite
loop.

This infinite loop causes s_lock not to be released, and other
tasks will hang, such as exfat_sync_fs().

This commit stops traversing the cluster chain when there is unused
directory entry in the cluster to avoid this infinite loop.</Note>
    </Notes>
    <CVE>CVE-2024-57940</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

virtio-blk: don't keep queue frozen during system suspend

Commit 4ce6e2db00de ("virtio-blk: Ensure no requests in virtqueues before
deleting vqs.") replaces queue quiesce with queue freeze in virtio-blk's
PM callbacks. And the motivation is to drain inflight IOs before suspending.

block layer's queue freeze looks very handy, but it is also easy to cause
deadlock, such as, any attempt to call into bio_queue_enter() may run into
deadlock if the queue is frozen in current context. There are all kinds
of -&gt;suspend() called in suspend context, so keeping queue frozen in the
whole suspend context isn't one good idea. And Marek reported lockdep
warning[1] caused by virtio-blk's freeze queue in virtblk_freeze().

[1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@samsung.com/

Given the motivation is to drain in-flight IOs, it can be done by calling
freeze &amp; unfreeze, meantime restore to previous behavior by keeping queue
quiesced during suspend.</Note>
    </Notes>
    <CVE>CVE-2024-57946</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mac802154: check local interfaces before deleting sdata list

syzkaller reported a corrupted list in ieee802154_if_remove. [1]

Remove an IEEE 802.15.4 network interface after unregister an IEEE 802.15.4
hardware device from the system.

CPU0					CPU1
====					====
genl_family_rcv_msg_doit		ieee802154_unregister_hw
ieee802154_del_iface			ieee802154_remove_interfaces
rdev_del_virtual_intf_deprecated	list_del(&amp;sdata-&gt;list)
ieee802154_if_remove
list_del_rcu

The net device has been unregistered, since the rcu grace period,
unregistration must be run before ieee802154_if_remove.

To avoid this issue, add a check for local-&gt;interfaces before deleting
sdata list.

[1]
kernel BUG at lib/list_debug.c:58!
Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 0 UID: 0 PID: 6277 Comm: syz-executor157 Not tainted 6.12.0-rc6-syzkaller-00005-g557329bcecc2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
RIP: 0010:__list_del_entry_valid_or_report+0xf4/0x140 lib/list_debug.c:56
Code: e8 a1 7e 00 07 90 0f 0b 48 c7 c7 e0 37 60 8c 4c 89 fe e8 8f 7e 00 07 90 0f 0b 48 c7 c7 40 38 60 8c 4c 89 fe e8 7d 7e 00 07 90 &lt;0f&gt; 0b 48 c7 c7 a0 38 60 8c 4c 89 fe e8 6b 7e 00 07 90 0f 0b 48 c7
RSP: 0018:ffffc9000490f3d0 EFLAGS: 00010246
RAX: 000000000000004e RBX: dead000000000122 RCX: d211eee56bb28d00
RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
RBP: ffff88805b278dd8 R08: ffffffff8174a12c R09: 1ffffffff2852f0d
R10: dffffc0000000000 R11: fffffbfff2852f0e R12: dffffc0000000000
R13: dffffc0000000000 R14: dead000000000100 R15: ffff88805b278cc0
FS:  0000555572f94380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000056262e4a3000 CR3: 0000000078496000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 __list_del_entry_valid include/linux/list.h:124 [inline]
 __list_del_entry include/linux/list.h:215 [inline]
 list_del_rcu include/linux/rculist.h:157 [inline]
 ieee802154_if_remove+0x86/0x1e0 net/mac802154/iface.c:687
 rdev_del_virtual_intf_deprecated net/ieee802154/rdev-ops.h:24 [inline]
 ieee802154_del_iface+0x2c0/0x5c0 net/ieee802154/nl-phy.c:323
 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]
 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]
 genl_rcv_msg+0xb14/0xec0 net/netlink/genetlink.c:1210
 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2551
 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219
 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline]
 netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1357
 netlink_sendmsg+0x8e4/0xcb0 net/netlink/af_netlink.c:1901
 sock_sendmsg_nosec net/socket.c:729 [inline]
 __sock_sendmsg+0x221/0x270 net/socket.c:744
 ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2607
 ___sys_sendmsg net/socket.c:2661 [inline]
 __sys_sendmsg+0x292/0x380 net/socket.c:2690
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f</Note>
    </Notes>
    <CVE>CVE-2024-57948</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ptr_ring: do not block hard interrupts in ptr_ring_resize_multiple()

Jakub added a lockdep_assert_no_hardirq() check in __page_pool_put_page()
to increase test coverage.

syzbot found a splat caused by hard irq blocking in
ptr_ring_resize_multiple() [1]

As current users of ptr_ring_resize_multiple() do not require
hard irqs being masked, replace it to only block BH.

Rename helpers to better reflect they are safe against BH only.

- ptr_ring_resize_multiple() to ptr_ring_resize_multiple_bh()
- skb_array_resize_multiple() to skb_array_resize_multiple_bh()

[1]

WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 __page_pool_put_page net/core/page_pool.c:709 [inline]
WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780
Modules linked in:
CPU: 1 UID: 0 PID: 9150 Comm: syz.1.1052 Not tainted 6.11.0-rc3-syzkaller-00202-gf8669d7b5f5d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
RIP: 0010:__page_pool_put_page net/core/page_pool.c:709 [inline]
RIP: 0010:page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780
Code: 74 0e e8 7c aa fb f7 eb 43 e8 75 aa fb f7 eb 3c 65 8b 1d 38 a8 6a 76 31 ff 89 de e8 a3 ae fb f7 85 db 74 0b e8 5a aa fb f7 90 &lt;0f&gt; 0b 90 eb 1d 65 8b 1d 15 a8 6a 76 31 ff 89 de e8 84 ae fb f7 85
RSP: 0018:ffffc9000bda6b58 EFLAGS: 00010083
RAX: ffffffff8997e523 RBX: 0000000000000000 RCX: 0000000000040000
RDX: ffffc9000fbd0000 RSI: 0000000000001842 RDI: 0000000000001843
RBP: 0000000000000000 R08: ffffffff8997df2c R09: 1ffffd40003a000d
R10: dffffc0000000000 R11: fffff940003a000e R12: ffffea0001d00040
R13: ffff88802e8a4000 R14: dffffc0000000000 R15: 00000000ffffffff
FS:  00007fb7aaf716c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fa15a0d4b72 CR3: 00000000561b0000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 tun_ptr_free drivers/net/tun.c:617 [inline]
 __ptr_ring_swap_queue include/linux/ptr_ring.h:571 [inline]
 ptr_ring_resize_multiple_noprof include/linux/ptr_ring.h:643 [inline]
 tun_queue_resize drivers/net/tun.c:3694 [inline]
 tun_device_event+0xaaf/0x1080 drivers/net/tun.c:3714
 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93
 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline]
 call_netdevice_notifiers net/core/dev.c:2046 [inline]
 dev_change_tx_queue_len+0x158/0x2a0 net/core/dev.c:9024
 do_setlink+0xff6/0x41f0 net/core/rtnetlink.c:2923
 rtnl_setlink+0x40d/0x5a0 net/core/rtnetlink.c:3201
 rtnetlink_rcv_msg+0x73f/0xcf0 net/core/rtnetlink.c:6647
 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2550</Note>
    </Notes>
    <CVE>CVE-2024-57994</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When the assert() function in the GNU C Library versions 2.13 to 2.40 fails, it does not allocate enough space for the assertion failure message string and size information, which may lead to a buffer overflow if the message string size aligns to page size.</Note>
    </Notes>
    <CVE>CVE-2025-0395</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:glibc-2.38-150600.14.23.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:glibc-locale-2.38-150600.14.23.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:glibc-locale-base-2.38-150600.14.23.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in command/gpg. In some scenarios, hooks created by loaded modules are not removed when the related module is unloaded. This flaw allows an attacker to force grub2 to call the hooks once the module that registered it was unloaded, leading to a use-after-free vulnerability. If correctly exploited, this vulnerability may result in arbitrary code execution, eventually allowing the attacker to bypass secure boot protections.</Note>
    </Notes>
    <CVE>CVE-2025-0622</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-2.12-150600.8.21.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-arm64-efi-2.12-150600.8.21.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in grub2. During the network boot process, when trying to search for the configuration file, grub copies data from a user controlled environment variable into an internal buffer using the grub_strcpy() function. During this step, it fails to consider the environment variable length when allocating the internal buffer, resulting in an out-of-bounds write. If correctly exploited, this issue may result in remote code execution through the same network segment grub is searching for the boot information, which can be used to by-pass secure boot protections.</Note>
    </Notes>
    <CVE>CVE-2025-0624</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-2.12-150600.8.21.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-arm64-efi-2.12-150600.8.21.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in grub2. When performing a symlink lookup, the grub's UFS module checks the inode's data size to allocate the internal buffer to read the file content, however, it fails to check if the symlink data size has overflown. When this occurs, grub_malloc() may be called with a smaller value than needed. When further reading the data from the disk into the buffer, the grub_ufs_lookup_symlink() function will write past the end of the allocated size. An attack can leverage this by crafting a malicious filesystem, and as a result, it will corrupt data stored in the heap, allowing for arbitrary code execution used to by-pass secure boot mechanisms.</Note>
    </Notes>
    <CVE>CVE-2025-0677</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-2.12-150600.8.21.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-arm64-efi-2.12-150600.8.21.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in grub2. When reading data from a squash4 filesystem, grub's squash4 fs module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciously crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the direct_read() will perform a heap based out-of-bounds write during data reading. This flaw may be leveraged to corrupt grub's internal critical data and may result in arbitrary code execution, by-passing secure boot protections.</Note>
    </Notes>
    <CVE>CVE-2025-0678</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-2.12-150600.8.21.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-arm64-efi-2.12-150600.8.21.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in grub2. When performing a symlink lookup from a reiserfs filesystem, grub's reiserfs fs module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciouly crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the grub_reiserfs_read_symlink() will call grub_reiserfs_read_real() with a overflown length parameter, leading to a heap based out-of-bounds write during data reading. This flaw may be leveraged to corrupt grub's internal critical data and can result in arbitrary code execution, by-passing secure boot protections.</Note>
    </Notes>
    <CVE>CVE-2025-0684</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-2.12-150600.8.21.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-arm64-efi-2.12-150600.8.21.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in grub2. When reading data from a jfs filesystem, grub's jfs filesystem module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciouly crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the grub_jfs_lookup_symlink() function will write past the internal buffer length during grub_jfs_read_file(). This issue can be leveraged to corrupt grub's internal critical data and may result in arbitrary code execution, by-passing secure boot protections.</Note>
    </Notes>
    <CVE>CVE-2025-0685</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-2.12-150600.8.21.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-arm64-efi-2.12-150600.8.21.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in grub2. When performing a symlink lookup from a romfs filesystem, grub's romfs filesystem module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciously crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the grub_romfs_read_symlink() may cause out-of-bounds writes when the calling grub_disk_read() function. This issue may be leveraged to corrupt grub's internal critical data and can result in arbitrary code execution by-passing secure boot protections.</Note>
    </Notes>
    <CVE>CVE-2025-0686</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-2.12-150600.8.21.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-arm64-efi-2.12-150600.8.21.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When reading data from disk, the grub's UDF filesystem module utilizes the user controlled data length metadata to allocate its internal buffers. In certain scenarios, while iterating through disk sectors, it assumes the read size from the disk is always smaller than the allocated buffer size which is not guaranteed. A crafted filesystem image may lead to a heap-based buffer overflow resulting in critical data to be corrupted, resulting in the risk of arbitrary code execution by-passing secure boot protections.</Note>
    </Notes>
    <CVE>CVE-2025-0689</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-2.12-150600.8.21.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-arm64-efi-2.12-150600.8.21.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">The read command is used to read the keyboard input from the user, while reads it keeps the input length in a 32-bit integer value which is further used to reallocate the line buffer to accept the next character. During this process, with a line big enough it's possible to make this variable to overflow leading to a out-of-bounds write in the heap based buffer. This flaw may be leveraged to corrupt grub's internal critical data and secure boot bypass is not discarded as consequence.</Note>
    </Notes>
    <CVE>CVE-2025-0690</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-2.12-150600.8.21.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-arm64-efi-2.12-150600.8.21.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn't valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers.</Note>
    </Notes>
    <CVE>CVE-2025-0938</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 grub2. Grub's dump command is not blocked when grub is in lockdown mode, which allows the user to read any memory information, and an attacker may leverage this in order to extract signatures, salts, and other sensitive information from the memory.</Note>
    </Notes>
    <CVE>CVE-2025-1118</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-2.12-150600.8.21.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-arm64-efi-2.12-150600.8.21.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When reading data from a hfs filesystem, grub's hfs filesystem module uses user-controlled parameters from the filesystem metadata to calculate the internal buffers size, however it misses to properly check for integer overflows. A maliciouly crafted filesystem may lead some of those buffer size calculation to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result the hfsplus_open_compressed_real() function will write past of the internal buffer length. This flaw may be leveraged to corrupt grub's internal critical data and may result in arbitrary code execution by-passing secure boot protections.</Note>
    </Notes>
    <CVE>CVE-2025-1125</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-2.12-150600.8.21.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:grub2-arm64-efi-2.12-150600.8.21.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability classified as problematic was found in vim up to 9.1.1096. This vulnerability affects unknown code of the file src/main.c. The manipulation of the argument --log leads to memory corruption. It is possible to launch the attack on the local host. Upgrading to version 9.1.1097 is able to address this issue. The patch is identified as c5654b84480822817bb7b69ebc97c174c91185e9. It is recommended to upgrade the affected component.</Note>
    </Notes>
    <CVE>CVE-2025-1215</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:vim-9.1.1101-150500.20.21.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:vim-data-common-9.1.1101-150500.20.21.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

x86/fpu: Ensure shadow stack is active before "getting" registers

The x86 shadow stack support has its own set of registers. Those registers
are XSAVE-managed, but they are "supervisor state components" which means
that userspace can not touch them with XSAVE/XRSTOR.  It also means that
they are not accessible from the existing ptrace ABI for XSAVE state.
Thus, there is a new ptrace get/set interface for it.

The regset code that ptrace uses provides an -&gt;active() handler in
addition to the get/set ones. For shadow stack this -&gt;active() handler
verifies that shadow stack is enabled via the ARCH_SHSTK_SHSTK bit in the
thread struct. The -&gt;active() handler is checked from some call sites of
the regset get/set handlers, but not the ptrace ones. This was not
understood when shadow stack support was put in place.

As a result, both the set/get handlers can be called with
XFEATURE_CET_USER in its init state, which would cause get_xsave_addr() to
return NULL and trigger a WARN_ON(). The ssp_set() handler luckily has an
ssp_active() check to avoid surprising the kernel with shadow stack
behavior when the kernel is not ready for it (ARCH_SHSTK_SHSTK==0). That
check just happened to avoid the warning.

But the -&gt;get() side wasn't so lucky. It can be called with shadow stacks
disabled, triggering the warning in practice, as reported by Christina
Schimpe:

WARNING: CPU: 5 PID: 1773 at arch/x86/kernel/fpu/regset.c:198 ssp_get+0x89/0xa0
[...]
Call Trace:
&lt;TASK&gt;
? show_regs+0x6e/0x80
? ssp_get+0x89/0xa0
? __warn+0x91/0x150
? ssp_get+0x89/0xa0
? report_bug+0x19d/0x1b0
? handle_bug+0x46/0x80
? exc_invalid_op+0x1d/0x80
? asm_exc_invalid_op+0x1f/0x30
? __pfx_ssp_get+0x10/0x10
? ssp_get+0x89/0xa0
? ssp_get+0x52/0xa0
__regset_get+0xad/0xf0
copy_regset_to_user+0x52/0xc0
ptrace_regset+0x119/0x140
ptrace_request+0x13c/0x850
? wait_task_inactive+0x142/0x1d0
? do_syscall_64+0x6d/0x90
arch_ptrace+0x102/0x300
[...]

Ensure that shadow stacks are active in a thread before looking them up
in the XSAVE buffer. Since ARCH_SHSTK_SHSTK and user_ssp[SHSTK_EN] are
set at the same time, the active check ensures that there will be
something to find in the XSAVE buffer.

[ dhansen: changelog/subject tweaks ]</Note>
    </Notes>
    <CVE>CVE-2025-21632</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sctp: sysctl: plpmtud_probe_interval: avoid using current-&gt;nsproxy

As mentioned in a previous commit of this series, using the 'net'
structure via 'current' is not recommended for different reasons:

- Inconsistency: getting info from the reader's/writer's netns vs only
  from the opener's netns.

- current-&gt;nsproxy can be NULL in some cases, resulting in an 'Oops'
  (null-ptr-deref), e.g. when the current task is exiting, as spotted by
  syzbot [1] using acct(2).

The 'net' structure can be obtained from the table-&gt;data using
container_of().

Note that table-&gt;data could also be used directly, as this is the only
member needed from the 'net' structure, but that would increase the size
of this fix, to use '*data' everywhere 'net-&gt;sctp.probe_interval' is
used.</Note>
    </Notes>
    <CVE>CVE-2025-21636</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sctp: sysctl: udp_port: avoid using current-&gt;nsproxy

As mentioned in a previous commit of this series, using the 'net'
structure via 'current' is not recommended for different reasons:

- Inconsistency: getting info from the reader's/writer's netns vs only
  from the opener's netns.

- current-&gt;nsproxy can be NULL in some cases, resulting in an 'Oops'
  (null-ptr-deref), e.g. when the current task is exiting, as spotted by
  syzbot [1] using acct(2).

The 'net' structure can be obtained from the table-&gt;data using
container_of().

Note that table-&gt;data could also be used directly, but that would
increase the size of this fix, while 'sctp.ctl_sock' still needs to be
retrieved from 'net' structure.</Note>
    </Notes>
    <CVE>CVE-2025-21637</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sctp: sysctl: auth_enable: avoid using current-&gt;nsproxy

As mentioned in a previous commit of this series, using the 'net'
structure via 'current' is not recommended for different reasons:

- Inconsistency: getting info from the reader's/writer's netns vs only
  from the opener's netns.

- current-&gt;nsproxy can be NULL in some cases, resulting in an 'Oops'
  (null-ptr-deref), e.g. when the current task is exiting, as spotted by
  syzbot [1] using acct(2).

The 'net' structure can be obtained from the table-&gt;data using
container_of().

Note that table-&gt;data could also be used directly, but that would
increase the size of this fix, while 'sctp.ctl_sock' still needs to be
retrieved from 'net' structure.</Note>
    </Notes>
    <CVE>CVE-2025-21638</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sctp: sysctl: rto_min/max: avoid using current-&gt;nsproxy

As mentioned in a previous commit of this series, using the 'net'
structure via 'current' is not recommended for different reasons:

- Inconsistency: getting info from the reader's/writer's netns vs only
  from the opener's netns.

- current-&gt;nsproxy can be NULL in some cases, resulting in an 'Oops'
  (null-ptr-deref), e.g. when the current task is exiting, as spotted by
  syzbot [1] using acct(2).

The 'net' structure can be obtained from the table-&gt;data using
container_of().

Note that table-&gt;data could also be used directly, as this is the only
member needed from the 'net' structure, but that would increase the size
of this fix, to use '*data' everywhere 'net-&gt;sctp.rto_min/max' is used.</Note>
    </Notes>
    <CVE>CVE-2025-21639</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sctp: sysctl: cookie_hmac_alg: avoid using current-&gt;nsproxy

As mentioned in a previous commit of this series, using the 'net'
structure via 'current' is not recommended for different reasons:

- Inconsistency: getting info from the reader's/writer's netns vs only
  from the opener's netns.

- current-&gt;nsproxy can be NULL in some cases, resulting in an 'Oops'
  (null-ptr-deref), e.g. when the current task is exiting, as spotted by
  syzbot [1] using acct(2).

The 'net' structure can be obtained from the table-&gt;data using
container_of().

Note that table-&gt;data could also be used directly, as this is the only
member needed from the 'net' structure, but that would increase the size
of this fix, to use '*data' everywhere 'net-&gt;sctp.sctp_hmac_alg' is
used.</Note>
    </Notes>
    <CVE>CVE-2025-21640</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

platform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually enabled it

Wakeup for IRQ1 should be disabled only in cases where i8042 had
actually enabled it, otherwise "wake_depth" for this IRQ will try to
drop below zero and there will be an unpleasant WARN() logged:

kernel: atkbd serio0: Disabling IRQ1 wakeup source to avoid platform firmware bug
kernel: ------------[ cut here ]------------
kernel: Unbalanced IRQ 1 wake disable
kernel: WARNING: CPU: 10 PID: 6431 at kernel/irq/manage.c:920 irq_set_irq_wake+0x147/0x1a0

The PMC driver uses DEFINE_SIMPLE_DEV_PM_OPS() to define its dev_pm_ops
which sets amd_pmc_suspend_handler() to the .suspend, .freeze, and
.poweroff handlers. i8042_pm_suspend(), however, is only set as
the .suspend handler.

Fix the issue by call PMC suspend handler only from the same set of
dev_pm_ops handlers as i8042_pm_suspend(), which currently means just
the .suspend handler.

To reproduce this issue try hibernating (S4) the machine after a fresh boot
without putting it into s2idle first.

[ij: edited the commit message.]</Note>
    </Notes>
    <CVE>CVE-2025-21645</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

afs: Fix the maximum cell name length

The kafs filesystem limits the maximum length of a cell to 256 bytes, but a
problem occurs if someone actually does that: kafs tries to create a
directory under /proc/net/afs/ with the name of the cell, but that fails
with a warning:

        WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:405

because procfs limits the maximum filename length to 255.

However, the DNS limits the maximum lookup length and, by extension, the
maximum cell name, to 255 less two (length count and trailing NUL).

Fix this by limiting the maximum acceptable cellname length to 253.  This
also allows us to be sure we can create the "/afs/.&lt;cell&gt;/" mountpoint too.

Further, split the YFS VL record cell name maximum to be the 256 allowed by
the protocol and ignore the record retrieved by YFSVL.GetCellName if it
exceeds 253.</Note>
    </Notes>
    <CVE>CVE-2025-21646</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sched: sch_cake: add bounds checks to host bulk flow fairness counts

Even though we fixed a logic error in the commit cited below, syzbot
still managed to trigger an underflow of the per-host bulk flow
counters, leading to an out of bounds memory access.

To avoid any such logic errors causing out of bounds memory accesses,
this commit factors out all accesses to the per-host bulk flow counters
to a series of helpers that perform bounds-checking before any
increments and decrements. This also has the benefit of improving
readability by moving the conditional checks for the flow mode into
these helpers, instead of having them spread out throughout the
code (which was the cause of the original logic error).

As part of this change, the flow quantum calculation is consolidated
into a helper function, which means that the dithering applied to the
ost load scaling is now applied both in the DRR rotation and when a
sparse flow's quantum is first initiated. The only user-visible effect
of this is that the maximum packet size that can be sent while a flow
stays sparse will now vary with +/- one byte in some cases. This should
not make a noticeable difference in practice, and thus it's not worth
complicating the code to preserve the old behaviour.</Note>
    </Notes>
    <CVE>CVE-2025-21647</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: hns3: fix kernel crash when 1588 is sent on HIP08 devices

Currently, HIP08 devices does not register the ptp devices, so the
hdev-&gt;ptp is NULL. But the tx process would still try to set hardware time
stamp info with SKBTX_HW_TSTAMP flag and cause a kernel crash.

[  128.087798] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018
...
[  128.280251] pc : hclge_ptp_set_tx_info+0x2c/0x140 [hclge]
[  128.286600] lr : hclge_ptp_set_tx_info+0x20/0x140 [hclge]
[  128.292938] sp : ffff800059b93140
[  128.297200] x29: ffff800059b93140 x28: 0000000000003280
[  128.303455] x27: ffff800020d48280 x26: ffff0cb9dc814080
[  128.309715] x25: ffff0cb9cde93fa0 x24: 0000000000000001
[  128.315969] x23: 0000000000000000 x22: 0000000000000194
[  128.322219] x21: ffff0cd94f986000 x20: 0000000000000000
[  128.328462] x19: ffff0cb9d2a166c0 x18: 0000000000000000
[  128.334698] x17: 0000000000000000 x16: ffffcf1fc523ed24
[  128.340934] x15: 0000ffffd530a518 x14: 0000000000000000
[  128.347162] x13: ffff0cd6bdb31310 x12: 0000000000000368
[  128.353388] x11: ffff0cb9cfbc7070 x10: ffff2cf55dd11e02
[  128.359606] x9 : ffffcf1f85a212b4 x8 : ffff0cd7cf27dab0
[  128.365831] x7 : 0000000000000a20 x6 : ffff0cd7cf27d000
[  128.372040] x5 : 0000000000000000 x4 : 000000000000ffff
[  128.378243] x3 : 0000000000000400 x2 : ffffcf1f85a21294
[  128.384437] x1 : ffff0cb9db520080 x0 : ffff0cb9db500080
[  128.390626] Call trace:
[  128.393964]  hclge_ptp_set_tx_info+0x2c/0x140 [hclge]
[  128.399893]  hns3_nic_net_xmit+0x39c/0x4c4 [hns3]
[  128.405468]  xmit_one.constprop.0+0xc4/0x200
[  128.410600]  dev_hard_start_xmit+0x54/0xf0
[  128.415556]  sch_direct_xmit+0xe8/0x634
[  128.420246]  __dev_queue_xmit+0x224/0xc70
[  128.425101]  dev_queue_xmit+0x1c/0x40
[  128.429608]  ovs_vport_send+0xac/0x1a0 [openvswitch]
[  128.435409]  do_output+0x60/0x17c [openvswitch]
[  128.440770]  do_execute_actions+0x898/0x8c4 [openvswitch]
[  128.446993]  ovs_execute_actions+0x64/0xf0 [openvswitch]
[  128.453129]  ovs_dp_process_packet+0xa0/0x224 [openvswitch]
[  128.459530]  ovs_vport_receive+0x7c/0xfc [openvswitch]
[  128.465497]  internal_dev_xmit+0x34/0xb0 [openvswitch]
[  128.471460]  xmit_one.constprop.0+0xc4/0x200
[  128.476561]  dev_hard_start_xmit+0x54/0xf0
[  128.481489]  __dev_queue_xmit+0x968/0xc70
[  128.486330]  dev_queue_xmit+0x1c/0x40
[  128.490856]  ip_finish_output2+0x250/0x570
[  128.495810]  __ip_finish_output+0x170/0x1e0
[  128.500832]  ip_finish_output+0x3c/0xf0
[  128.505504]  ip_output+0xbc/0x160
[  128.509654]  ip_send_skb+0x58/0xd4
[  128.513892]  udp_send_skb+0x12c/0x354
[  128.518387]  udp_sendmsg+0x7a8/0x9c0
[  128.522793]  inet_sendmsg+0x4c/0x8c
[  128.527116]  __sock_sendmsg+0x48/0x80
[  128.531609]  __sys_sendto+0x124/0x164
[  128.536099]  __arm64_sys_sendto+0x30/0x5c
[  128.540935]  invoke_syscall+0x50/0x130
[  128.545508]  el0_svc_common.constprop.0+0x10c/0x124
[  128.551205]  do_el0_svc+0x34/0xdc
[  128.555347]  el0_svc+0x20/0x30
[  128.559227]  el0_sync_handler+0xb8/0xc0
[  128.563883]  el0_sync+0x160/0x180</Note>
    </Notes>
    <CVE>CVE-2025-21649</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: hns3: fixed hclge_fetch_pf_reg accesses bar space out of bounds issue

The TQP BAR space is divided into two segments. TQPs 0-1023 and TQPs
1024-1279 are in different BAR space addresses. However,
hclge_fetch_pf_reg does not distinguish the tqp space information when
reading the tqp space information. When the number of TQPs is greater
than 1024, access bar space overwriting occurs.
The problem of different segments has been considered during the
initialization of tqp.io_base. Therefore, tqp.io_base is directly used
when the queue is read in hclge_fetch_pf_reg.

The error message:

Unable to handle kernel paging request at virtual address ffff800037200000
pc : hclge_fetch_pf_reg+0x138/0x250 [hclge]
lr : hclge_get_regs+0x84/0x1d0 [hclge]
Call trace:
 hclge_fetch_pf_reg+0x138/0x250 [hclge]
 hclge_get_regs+0x84/0x1d0 [hclge]
 hns3_get_regs+0x2c/0x50 [hns3]
 ethtool_get_regs+0xf4/0x270
 dev_ethtool+0x674/0x8a0
 dev_ioctl+0x270/0x36c
 sock_do_ioctl+0x110/0x2a0
 sock_ioctl+0x2ac/0x530
 __arm64_sys_ioctl+0xa8/0x100
 invoke_syscall+0x4c/0x124
 el0_svc_common.constprop.0+0x140/0x15c
 do_el0_svc+0x30/0xd0
 el0_svc+0x1c/0x2c
 el0_sync_handler+0xb0/0xb4
 el0_sync+0x168/0x180</Note>
    </Notes>
    <CVE>CVE-2025-21650</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: hns3: don't auto enable misc vector

Currently, there is a time window between misc irq enabled
and service task inited. If an interrupte is reported at
this time, it will cause warning like below:

[   16.324639] Call trace:
[   16.324641]  __queue_delayed_work+0xb8/0xe0
[   16.324643]  mod_delayed_work_on+0x78/0xd0
[   16.324655]  hclge_errhand_task_schedule+0x58/0x90 [hclge]
[   16.324662]  hclge_misc_irq_handle+0x168/0x240 [hclge]
[   16.324666]  __handle_irq_event_percpu+0x64/0x1e0
[   16.324667]  handle_irq_event+0x80/0x170
[   16.324670]  handle_fasteoi_edge_irq+0x110/0x2bc
[   16.324671]  __handle_domain_irq+0x84/0xfc
[   16.324673]  gic_handle_irq+0x88/0x2c0
[   16.324674]  el1_irq+0xb8/0x140
[   16.324677]  arch_cpu_idle+0x18/0x40
[   16.324679]  default_idle_call+0x5c/0x1bc
[   16.324682]  cpuidle_idle_call+0x18c/0x1c4
[   16.324684]  do_idle+0x174/0x17c
[   16.324685]  cpu_startup_entry+0x30/0x6c
[   16.324687]  secondary_start_kernel+0x1a4/0x280
[   16.324688] ---[ end trace 6aa0bff672a964aa ]---

So don't auto enable misc vector when request irq..</Note>
    </Notes>
    <CVE>CVE-2025-21651</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipvlan: Fix use-after-free in ipvlan_get_iflink().

syzbot presented an use-after-free report [0] regarding ipvlan and
linkwatch.

ipvlan does not hold a refcnt of the lower device unlike vlan and
macvlan.

If the linkwatch work is triggered for the ipvlan dev, the lower dev
might have already been freed, resulting in UAF of ipvlan-&gt;phy_dev in
ipvlan_get_iflink().

We can delay the lower dev unregistration like vlan and macvlan by
holding the lower dev's refcnt in dev-&gt;netdev_ops-&gt;ndo_init() and
releasing it in dev-&gt;priv_destructor().

Jakub pointed out calling .ndo_XXX after unregister_netdevice() has
returned is error prone and suggested [1] addressing this UAF in the
core by taking commit 750e51603395 ("net: avoid potential UAF in
default_operstate()") further.

Let's assume unregistering devices DOWN and use RCU protection in
default_operstate() not to race with the device unregistration.

[0]:
BUG: KASAN: slab-use-after-free in ipvlan_get_iflink+0x84/0x88 drivers/net/ipvlan/ipvlan_main.c:353
Read of size 4 at addr ffff0000d768c0e0 by task kworker/u8:35/6944

CPU: 0 UID: 0 PID: 6944 Comm: kworker/u8:35 Not tainted 6.13.0-rc2-g9bc5c9515b48 #12 4c3cb9e8b4565456f6a355f312ff91f4f29b3c47
Hardware name: linux,dummy-virt (DT)
Workqueue: events_unbound linkwatch_event
Call trace:
 show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:484 (C)
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0x16c/0x6f0 mm/kasan/report.c:489
 kasan_report+0xc0/0x120 mm/kasan/report.c:602
 __asan_report_load4_noabort+0x20/0x30 mm/kasan/report_generic.c:380
 ipvlan_get_iflink+0x84/0x88 drivers/net/ipvlan/ipvlan_main.c:353
 dev_get_iflink+0x7c/0xd8 net/core/dev.c:674
 default_operstate net/core/link_watch.c:45 [inline]
 rfc2863_policy+0x144/0x360 net/core/link_watch.c:72
 linkwatch_do_dev+0x60/0x228 net/core/link_watch.c:175
 __linkwatch_run_queue+0x2f4/0x5b8 net/core/link_watch.c:239
 linkwatch_event+0x64/0xa8 net/core/link_watch.c:282
 process_one_work+0x700/0x1398 kernel/workqueue.c:3229
 process_scheduled_works kernel/workqueue.c:3310 [inline]
 worker_thread+0x8c4/0xe10 kernel/workqueue.c:3391
 kthread+0x2b0/0x360 kernel/kthread.c:389
 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:862

Allocated by task 9303:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x30/0x68 mm/kasan/common.c:68
 kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568
 poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
 __kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394
 kasan_kmalloc include/linux/kasan.h:260 [inline]
 __do_kmalloc_node mm/slub.c:4283 [inline]
 __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4289
 __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:650
 alloc_netdev_mqs+0xb4/0x1118 net/core/dev.c:11209
 rtnl_create_link+0x2b8/0xb60 net/core/rtnetlink.c:3595
 rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3771
 __rtnl_newlink net/core/rtnetlink.c:3896 [inline]
 rtnl_newlink+0x122c/0x15c0 net/core/rtnetlink.c:4011
 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6901
 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2542
 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6928
 netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline]
 netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1347
 netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1891
 sock_sendmsg_nosec net/socket.c:711 [inline]
 __sock_sendmsg net/socket.c:726 [inline]
 __sys_sendto+0x2ec/0x438 net/socket.c:2197
 __do_sys_sendto net/socket.c:2204 [inline]
 __se_sys_sendto net/socket.c:2200 [inline]
 __arm64_sys_sendto+0xe4/0x110 net/socket.c:2200
 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
 invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49
 el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132
 do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151
 el
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-21652</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net_sched: cls_flow: validate TCA_FLOW_RSHIFT attribute

syzbot found that TCA_FLOW_RSHIFT attribute was not validated.
Right shitfing a 32bit integer is undefined for large shift values.

UBSAN: shift-out-of-bounds in net/sched/cls_flow.c:329:23
shift exponent 9445 is too large for 32-bit type 'u32' (aka 'unsigned int')
CPU: 1 UID: 0 PID: 54 Comm: kworker/u8:3 Not tainted 6.13.0-rc3-syzkaller-00180-g4f619d518db9 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Workqueue: ipv6_addrconf addrconf_dad_work
Call Trace:
 &lt;TASK&gt;
  __dump_stack lib/dump_stack.c:94 [inline]
  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
  ubsan_epilogue lib/ubsan.c:231 [inline]
  __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468
  flow_classify+0x24d5/0x25b0 net/sched/cls_flow.c:329
  tc_classify include/net/tc_wrapper.h:197 [inline]
  __tcf_classify net/sched/cls_api.c:1771 [inline]
  tcf_classify+0x420/0x1160 net/sched/cls_api.c:1867
  sfb_classify net/sched/sch_sfb.c:260 [inline]
  sfb_enqueue+0x3ad/0x18b0 net/sched/sch_sfb.c:318
  dev_qdisc_enqueue+0x4b/0x290 net/core/dev.c:3793
  __dev_xmit_skb net/core/dev.c:3889 [inline]
  __dev_queue_xmit+0xf0e/0x3f50 net/core/dev.c:4400
  dev_queue_xmit include/linux/netdevice.h:3168 [inline]
  neigh_hh_output include/net/neighbour.h:523 [inline]
  neigh_output include/net/neighbour.h:537 [inline]
  ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236
  iptunnel_xmit+0x55d/0x9b0 net/ipv4/ip_tunnel_core.c:82
  udp_tunnel_xmit_skb+0x262/0x3b0 net/ipv4/udp_tunnel_core.c:173
  geneve_xmit_skb drivers/net/geneve.c:916 [inline]
  geneve_xmit+0x21dc/0x2d00 drivers/net/geneve.c:1039
  __netdev_start_xmit include/linux/netdevice.h:5002 [inline]
  netdev_start_xmit include/linux/netdevice.h:5011 [inline]
  xmit_one net/core/dev.c:3590 [inline]
  dev_hard_start_xmit+0x27a/0x7d0 net/core/dev.c:3606
  __dev_queue_xmit+0x1b73/0x3f50 net/core/dev.c:4434</Note>
    </Notes>
    <CVE>CVE-2025-21653</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

io_uring/eventfd: ensure io_eventfd_signal() defers another RCU period

io_eventfd_do_signal() is invoked from an RCU callback, but when
dropping the reference to the io_ev_fd, it calls io_eventfd_free()
directly if the refcount drops to zero. This isn't correct, as any
potential freeing of the io_ev_fd should be deferred another RCU grace
period.

Just call io_eventfd_put() rather than open-code the dec-and-test and
free, which will correctly defer it another RCU grace period.</Note>
    </Notes>
    <CVE>CVE-2025-21655</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hwmon: (drivetemp) Fix driver producing garbage data when SCSI errors occur

scsi_execute_cmd() function can return both negative (linux codes) and
positive (scsi_cmnd result field) error codes.

Currently the driver just passes error codes of scsi_execute_cmd() to
hwmon core, which is incorrect because hwmon only checks for negative
error codes. This leads to hwmon reporting uninitialized data to
userspace in case of SCSI errors (for example if the disk drive was
disconnected).

This patch checks scsi_execute_cmd() output and returns -EIO if it's
error code is positive.

[groeck: Avoid inline variable declaration for portability]</Note>
    </Notes>
    <CVE>CVE-2025-21656</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: Fix variable not being completed when function returns

When cmd_alloc_index(), fails cmd_work_handler() needs
to complete ent-&gt;slotted before returning early.
Otherwise the task which issued the command may hang:

   mlx5_core 0000:01:00.0: cmd_work_handler:877:(pid 3880418): failed to allocate command entry
   INFO: task kworker/13:2:4055883 blocked for more than 120 seconds.
         Not tainted 4.19.90-25.44.v2101.ky10.aarch64 #1
   "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
   kworker/13:2    D    0 4055883      2 0x00000228
   Workqueue: events mlx5e_tx_dim_work [mlx5_core]
   Call trace:
      __switch_to+0xe8/0x150
      __schedule+0x2a8/0x9b8
      schedule+0x2c/0x88
      schedule_timeout+0x204/0x478
      wait_for_common+0x154/0x250
      wait_for_completion+0x28/0x38
      cmd_exec+0x7a0/0xa00 [mlx5_core]
      mlx5_cmd_exec+0x54/0x80 [mlx5_core]
      mlx5_core_modify_cq+0x6c/0x80 [mlx5_core]
      mlx5_core_modify_cq_moderation+0xa0/0xb8 [mlx5_core]
      mlx5e_tx_dim_work+0x54/0x68 [mlx5_core]
      process_one_work+0x1b0/0x448
      worker_thread+0x54/0x468
      kthread+0x134/0x138
      ret_from_fork+0x10/0x18</Note>
    </Notes>
    <CVE>CVE-2025-21662</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: stmmac: dwmac-tegra: Read iommu stream id from device tree

Nvidia's Tegra MGBE controllers require the IOMMU "Stream ID" (SID) to be
written to the MGBE_WRAP_AXI_ASID0_CTRL register.

The current driver is hard coded to use MGBE0's SID for all controllers.
This causes softirq time outs and kernel panics when using controllers
other than MGBE0.

Example dmesg errors when an ethernet cable is connected to MGBE1:

[  116.133290] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx
[  121.851283] tegra-mgbe 6910000.ethernet eth1: NETDEV WATCHDOG: CPU: 5: transmit queue 0 timed out 5690 ms
[  121.851782] tegra-mgbe 6910000.ethernet eth1: Reset adapter.
[  121.892464] tegra-mgbe 6910000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0
[  121.905920] tegra-mgbe 6910000.ethernet eth1: PHY [stmmac-1:00] driver [Aquantia AQR113] (irq=171)
[  121.907356] tegra-mgbe 6910000.ethernet eth1: Enabling Safety Features
[  121.907578] tegra-mgbe 6910000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported
[  121.908399] tegra-mgbe 6910000.ethernet eth1: registered PTP clock
[  121.908582] tegra-mgbe 6910000.ethernet eth1: configuring for phy/10gbase-r link mode
[  125.961292] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx
[  181.921198] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[  181.921404] rcu: 	7-....: (1 GPs behind) idle=540c/1/0x4000000000000002 softirq=1748/1749 fqs=2337
[  181.921684] rcu: 	(detected by 4, t=6002 jiffies, g=1357, q=1254 ncpus=8)
[  181.921878] Sending NMI from CPU 4 to CPUs 7:
[  181.921886] NMI backtrace for cpu 7
[  181.922131] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Kdump: loaded Not tainted 6.13.0-rc3+ #6
[  181.922390] Hardware name: NVIDIA CTI Forge + Orin AGX/Jetson, BIOS 202402.1-Unknown 10/28/2024
[  181.922658] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  181.922847] pc : handle_softirqs+0x98/0x368
[  181.922978] lr : __do_softirq+0x18/0x20
[  181.923095] sp : ffff80008003bf50
[  181.923189] x29: ffff80008003bf50 x28: 0000000000000008 x27: 0000000000000000
[  181.923379] x26: ffffce78ea277000 x25: 0000000000000000 x24: 0000001c61befda0
[  181.924486] x23: 0000000060400009 x22: ffffce78e99918bc x21: ffff80008018bd70
[  181.925568] x20: ffffce78e8bb00d8 x19: ffff80008018bc20 x18: 0000000000000000
[  181.926655] x17: ffff318ebe7d3000 x16: ffff800080038000 x15: 0000000000000000
[  181.931455] x14: ffff000080816680 x13: ffff318ebe7d3000 x12: 000000003464d91d
[  181.938628] x11: 0000000000000040 x10: ffff000080165a70 x9 : ffffce78e8bb0160
[  181.945804] x8 : ffff8000827b3160 x7 : f9157b241586f343 x6 : eeb6502a01c81c74
[  181.953068] x5 : a4acfcdd2e8096bb x4 : ffffce78ea277340 x3 : 00000000ffffd1e1
[  181.960329] x2 : 0000000000000101 x1 : ffffce78ea277340 x0 : ffff318ebe7d3000
[  181.967591] Call trace:
[  181.970043]  handle_softirqs+0x98/0x368 (P)
[  181.974240]  __do_softirq+0x18/0x20
[  181.977743]  ____do_softirq+0x14/0x28
[  181.981415]  call_on_irq_stack+0x24/0x30
[  181.985180]  do_softirq_own_stack+0x20/0x30
[  181.989379]  __irq_exit_rcu+0x114/0x140
[  181.993142]  irq_exit_rcu+0x14/0x28
[  181.996816]  el1_interrupt+0x44/0xb8
[  182.000316]  el1h_64_irq_handler+0x14/0x20
[  182.004343]  el1h_64_irq+0x80/0x88
[  182.007755]  cpuidle_enter_state+0xc4/0x4a8 (P)
[  182.012305]  cpuidle_enter+0x3c/0x58
[  182.015980]  cpuidle_idle_call+0x128/0x1c0
[  182.020005]  do_idle+0xe0/0xf0
[  182.023155]  cpu_startup_entry+0x3c/0x48
[  182.026917]  secondary_start_kernel+0xdc/0x120
[  182.031379]  __secondary_switched+0x74/0x78
[  212.971162] rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 7-.... } 6103 jiffies s: 417 root: 0x80/.
[  212.985935] rcu: blocking rcu_node structures (internal RCU debug):
[  212.992758] Sending NMI from CPU 0 to CPUs 7:
[  212.998539] NMI backtrace for cpu 7
[  213.004304] CPU: 7 UID: 0 PI
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-21663</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dm thin: make get_first_thin use rcu-safe list first function

The documentation in rculist.h explains the absence of list_empty_rcu()
and cautions programmers against relying on a list_empty() -&gt;
list_first() sequence in RCU safe code.  This is because each of these
functions performs its own READ_ONCE() of the list head.  This can lead
to a situation where the list_empty() sees a valid list entry, but the
subsequent list_first() sees a different view of list head state after a
modification.

In the case of dm-thin, this author had a production box crash from a GP
fault in the process_deferred_bios path.  This function saw a valid list
head in get_first_thin() but when it subsequently dereferenced that and
turned it into a thin_c, it got the inside of the struct pool, since the
list was now empty and referring to itself.  The kernel on which this
occurred printed both a warning about a refcount_t being saturated, and
a UBSAN error for an out-of-bounds cpuid access in the queued spinlock,
prior to the fault itself.  When the resulting kdump was examined, it
was possible to see another thread patiently waiting in thin_dtr's
synchronize_rcu.

The thin_dtr call managed to pull the thin_c out of the active thins
list (and have it be the last entry in the active_thins list) at just
the wrong moment which lead to this crash.

Fortunately, the fix here is straight forward.  Switch get_first_thin()
function to use list_first_or_null_rcu() which performs just a single
READ_ONCE() and returns NULL if the list is already empty.

This was run against the devicemapper test suite's thin-provisioning
suites for delete and suspend and no regressions were observed.</Note>
    </Notes>
    <CVE>CVE-2025-21664</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

filemap: avoid truncating 64-bit offset to 32 bits

On 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a
64-bit value to 32 bits, leading to a possible infinite loop when writing
to an xfs filesystem.</Note>
    </Notes>
    <CVE>CVE-2025-21665</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vsock: prevent null-ptr-deref in vsock_*[has_data|has_space]

Recent reports have shown how we sometimes call vsock_*_has_data()
when a vsock socket has been de-assigned from a transport (see attached
links), but we shouldn't.

Previous commits should have solved the real problems, but we may have
more in the future, so to avoid null-ptr-deref, we can return 0
(no space, no data available) but with a warning.

This way the code should continue to run in a nearly consistent state
and have a warning that allows us to debug future problems.</Note>
    </Notes>
    <CVE>CVE-2025-21666</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iomap: avoid avoid truncating 64-bit offset to 32 bits

on 32-bit kernels, iomap_write_delalloc_scan() was inadvertently using a
32-bit position due to folio_next_index() returning an unsigned long.
This could lead to an infinite loop when writing to an xfs filesystem.</Note>
    </Notes>
    <CVE>CVE-2025-21667</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pmdomain: imx8mp-blk-ctrl: add missing loop break condition

Currently imx8mp_blk_ctrl_remove() will continue the for loop
until an out-of-bounds exception occurs.

pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : dev_pm_domain_detach+0x8/0x48
lr : imx8mp_blk_ctrl_shutdown+0x58/0x90
sp : ffffffc084f8bbf0
x29: ffffffc084f8bbf0 x28: ffffff80daf32ac0 x27: 0000000000000000
x26: ffffffc081658d78 x25: 0000000000000001 x24: ffffffc08201b028
x23: ffffff80d0db9490 x22: ffffffc082340a78 x21: 00000000000005b0
x20: ffffff80d19bc180 x19: 000000000000000a x18: ffffffffffffffff
x17: ffffffc080a39e08 x16: ffffffc080a39c98 x15: 4f435f464f006c72
x14: 0000000000000004 x13: ffffff80d0172110 x12: 0000000000000000
x11: ffffff80d0537740 x10: ffffff80d05376c0 x9 : ffffffc0808ed2d8
x8 : ffffffc084f8bab0 x7 : 0000000000000000 x6 : 0000000000000000
x5 : ffffff80d19b9420 x4 : fffffffe03466e60 x3 : 0000000080800077
x2 : 0000000000000000 x1 : 0000000000000001 x0 : 0000000000000000
Call trace:
 dev_pm_domain_detach+0x8/0x48
 platform_shutdown+0x2c/0x48
 device_shutdown+0x158/0x268
 kernel_restart_prepare+0x40/0x58
 kernel_kexec+0x58/0xe8
 __do_sys_reboot+0x198/0x258
 __arm64_sys_reboot+0x2c/0x40
 invoke_syscall+0x5c/0x138
 el0_svc_common.constprop.0+0x48/0xf0
 do_el0_svc+0x24/0x38
 el0_svc+0x38/0xc8
 el0t_64_sync_handler+0x120/0x130
 el0t_64_sync+0x190/0x198
Code: 8128c2d0 ffffffc0 aa1e03e9 d503201f</Note>
    </Notes>
    <CVE>CVE-2025-21668</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vsock/virtio: discard packets if the transport changes

If the socket has been de-assigned or assigned to another transport,
we must discard any packets received because they are not expected
and would cause issues when we access vsk-&gt;transport.

A possible scenario is described by Hyunwoo Kim in the attached link,
where after a first connect() interrupted by a signal, and a second
connect() failed, we can find `vsk-&gt;transport` at NULL, leading to a
NULL pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2025-21669</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vsock/bpf: return early if transport is not assigned

Some of the core functions can only be called if the transport
has been assigned.

As Michal reported, a socket might have the transport at NULL,
for example after a failed connect(), causing the following trace:

    BUG: kernel NULL pointer dereference, address: 00000000000000a0
    #PF: supervisor read access in kernel mode
    #PF: error_code(0x0000) - not-present page
    PGD 12faf8067 P4D 12faf8067 PUD 113670067 PMD 0
    Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
    CPU: 15 UID: 0 PID: 1198 Comm: a.out Not tainted 6.13.0-rc2+
    RIP: 0010:vsock_connectible_has_data+0x1f/0x40
    Call Trace:
     vsock_bpf_recvmsg+0xca/0x5e0
     sock_recvmsg+0xb9/0xc0
     __sys_recvfrom+0xb3/0x130
     __x64_sys_recvfrom+0x20/0x30
     do_syscall_64+0x93/0x180
     entry_SYSCALL_64_after_hwframe+0x76/0x7e

So we need to check the `vsk-&gt;transport` in vsock_bpf_recvmsg(),
especially for connected sockets (stream/seqpacket) as we already
do in __vsock_connectible_recvmsg().</Note>
    </Notes>
    <CVE>CVE-2025-21670</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix double free of TCP_Server_Info::hostname

When shutting down the server in cifs_put_tcp_session(), cifsd thread
might be reconnecting to multiple DFS targets before it realizes it
should exit the loop, so @server-&gt;hostname can't be freed as long as
cifsd thread isn't done.  Otherwise the following can happen:

  RIP: 0010:__slab_free+0x223/0x3c0
  Code: 5e 41 5f c3 cc cc cc cc 4c 89 de 4c 89 cf 44 89 44 24 08 4c 89
  1c 24 e8 fb cf 8e 00 44 8b 44 24 08 4c 8b 1c 24 e9 5f fe ff ff &lt;0f&gt;
  0b 41 f7 45 08 00 0d 21 00 0f 85 2d ff ff ff e9 1f ff ff ff 80
  RSP: 0018:ffffb26180dbfd08 EFLAGS: 00010246
  RAX: ffff8ea34728e510 RBX: ffff8ea34728e500 RCX: 0000000000800068
  RDX: 0000000000800068 RSI: 0000000000000000 RDI: ffff8ea340042400
  RBP: ffffe112041ca380 R08: 0000000000000001 R09: 0000000000000000
  R10: 6170732e31303000 R11: 70726f632e786563 R12: ffff8ea34728e500
  R13: ffff8ea340042400 R14: ffff8ea34728e500 R15: 0000000000800068
  FS: 0000000000000000(0000) GS:ffff8ea66fd80000(0000)
  000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007ffc25376080 CR3: 000000012a2ba001 CR4:
  PKRU: 55555554
  Call Trace:
   &lt;TASK&gt;
   ? show_trace_log_lvl+0x1c4/0x2df
   ? show_trace_log_lvl+0x1c4/0x2df
   ? __reconnect_target_unlocked+0x3e/0x160 [cifs]
   ? __die_body.cold+0x8/0xd
   ? die+0x2b/0x50
   ? do_trap+0xce/0x120
   ? __slab_free+0x223/0x3c0
   ? do_error_trap+0x65/0x80
   ? __slab_free+0x223/0x3c0
   ? exc_invalid_op+0x4e/0x70
   ? __slab_free+0x223/0x3c0
   ? asm_exc_invalid_op+0x16/0x20
   ? __slab_free+0x223/0x3c0
   ? extract_hostname+0x5c/0xa0 [cifs]
   ? extract_hostname+0x5c/0xa0 [cifs]
   ? __kmalloc+0x4b/0x140
   __reconnect_target_unlocked+0x3e/0x160 [cifs]
   reconnect_dfs_server+0x145/0x430 [cifs]
   cifs_handle_standard+0x1ad/0x1d0 [cifs]
   cifs_demultiplex_thread+0x592/0x730 [cifs]
   ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs]
   kthread+0xdd/0x100
   ? __pfx_kthread+0x10/0x10
   ret_from_fork+0x29/0x50
   &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2025-21673</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Fix inversion dependency warning while enabling IPsec tunnel

Attempt to enable IPsec packet offload in tunnel mode in debug kernel
generates the following kernel panic, which is happening due to two
issues:
1. In SA add section, the should be _bh() variant when marking SA mode.
2. There is not needed flush_workqueue in SA delete routine. It is not
needed as at this stage as it is removed from SADB and the running work
will be canceled later in SA free.

 =====================================================
 WARNING: SOFTIRQ-safe -&gt; SOFTIRQ-unsafe lock order detected
 6.12.0+ #4 Not tainted
 -----------------------------------------------------
 charon/1337 [HC0[0]:SC0[4]:HE1:SE0] is trying to acquire:
 ffff88810f365020 (&amp;xa-&gt;xa_lock#24){+.+.}-{3:3}, at: mlx5e_xfrm_del_state+0xca/0x1e0 [mlx5_core]

 and this task is already holding:
 ffff88813e0f0d48 (&amp;x-&gt;lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30
 which would create a new lock dependency:
  (&amp;x-&gt;lock){+.-.}-{3:3} -&gt; (&amp;xa-&gt;xa_lock#24){+.+.}-{3:3}

 but this new dependency connects a SOFTIRQ-irq-safe lock:
  (&amp;x-&gt;lock){+.-.}-{3:3}

 ... which became SOFTIRQ-irq-safe at:
   lock_acquire+0x1be/0x520
   _raw_spin_lock_bh+0x34/0x40
   xfrm_timer_handler+0x91/0xd70
   __hrtimer_run_queues+0x1dd/0xa60
   hrtimer_run_softirq+0x146/0x2e0
   handle_softirqs+0x266/0x860
   irq_exit_rcu+0x115/0x1a0
   sysvec_apic_timer_interrupt+0x6e/0x90
   asm_sysvec_apic_timer_interrupt+0x16/0x20
   default_idle+0x13/0x20
   default_idle_call+0x67/0xa0
   do_idle+0x2da/0x320
   cpu_startup_entry+0x50/0x60
   start_secondary+0x213/0x2a0
   common_startup_64+0x129/0x138

 to a SOFTIRQ-irq-unsafe lock:
  (&amp;xa-&gt;xa_lock#24){+.+.}-{3:3}

 ... which became SOFTIRQ-irq-unsafe at:
 ...
   lock_acquire+0x1be/0x520
   _raw_spin_lock+0x2c/0x40
   xa_set_mark+0x70/0x110
   mlx5e_xfrm_add_state+0xe48/0x2290 [mlx5_core]
   xfrm_dev_state_add+0x3bb/0xd70
   xfrm_add_sa+0x2451/0x4a90
   xfrm_user_rcv_msg+0x493/0x880
   netlink_rcv_skb+0x12e/0x380
   xfrm_netlink_rcv+0x6d/0x90
   netlink_unicast+0x42f/0x740
   netlink_sendmsg+0x745/0xbe0
   __sock_sendmsg+0xc5/0x190
   __sys_sendto+0x1fe/0x2c0
   __x64_sys_sendto+0xdc/0x1b0
   do_syscall_64+0x6d/0x140
   entry_SYSCALL_64_after_hwframe+0x4b/0x53

 other info that might help us debug this:

  Possible interrupt unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(&amp;xa-&gt;xa_lock#24);
                                local_irq_disable();
                                lock(&amp;x-&gt;lock);
                                lock(&amp;xa-&gt;xa_lock#24);
   &lt;Interrupt&gt;
     lock(&amp;x-&gt;lock);

  *** DEADLOCK ***

 2 locks held by charon/1337:
  #0: ffffffff87f8f858 (&amp;net-&gt;xfrm.xfrm_cfg_mutex){+.+.}-{4:4}, at: xfrm_netlink_rcv+0x5e/0x90
  #1: ffff88813e0f0d48 (&amp;x-&gt;lock){+.-.}-{3:3}, at: xfrm_state_delete+0x16/0x30

 the dependencies between SOFTIRQ-irq-safe lock and the holding lock:
 -&gt; (&amp;x-&gt;lock){+.-.}-{3:3} ops: 29 {
    HARDIRQ-ON-W at:
                     lock_acquire+0x1be/0x520
                     _raw_spin_lock_bh+0x34/0x40
                     xfrm_alloc_spi+0xc0/0xe60
                     xfrm_alloc_userspi+0x5f6/0xbc0
                     xfrm_user_rcv_msg+0x493/0x880
                     netlink_rcv_skb+0x12e/0x380
                     xfrm_netlink_rcv+0x6d/0x90
                     netlink_unicast+0x42f/0x740
                     netlink_sendmsg+0x745/0xbe0
                     __sock_sendmsg+0xc5/0x190
                     __sys_sendto+0x1fe/0x2c0
                     __x64_sys_sendto+0xdc/0x1b0
                     do_syscall_64+0x6d/0x140
                     entry_SYSCALL_64_after_hwframe+0x4b/0x53
    IN-SOFTIRQ-W at:
                     lock_acquire+0x1be/0x520
                     _raw_spin_lock_bh+0x34/0x40
                     xfrm_timer_handler+0x91/0xd70
                     __hrtimer_run_queues+0x1dd/0xa60
   
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-21674</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: Clear port select structure when fail to create

Clear the port select structure on error so no stale values left after
definers are destroyed. That's because the mlx5_lag_destroy_definers()
always try to destroy all lag definers in the tt_map, so in the flow
below lag definers get double-destroyed and cause kernel crash:

  mlx5_lag_port_sel_create()
    mlx5_lag_create_definers()
      mlx5_lag_create_definer()     &lt;- Failed on tt 1
        mlx5_lag_destroy_definers() &lt;- definers[tt=0] gets destroyed
  mlx5_lag_port_sel_create()
    mlx5_lag_create_definers()
      mlx5_lag_create_definer()     &lt;- Failed on tt 0
        mlx5_lag_destroy_definers() &lt;- definers[tt=0] gets double-destroyed

 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
 Mem abort info:
   ESR = 0x0000000096000005
   EC = 0x25: DABT (current EL), IL = 32 bits
   SET = 0, FnV = 0
   EA = 0, S1PTW = 0
   FSC = 0x05: level 1 translation fault
 Data abort info:
   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
 user pgtable: 64k pages, 48-bit VAs, pgdp=0000000112ce2e00
 [0000000000000008] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
 Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
 Modules linked in: iptable_raw bonding ip_gre ip6_gre gre ip6_tunnel tunnel6 geneve ip6_udp_tunnel udp_tunnel ipip tunnel4 ip_tunnel rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) mlx5_fwctl(OE) fwctl(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlxfw(OE) memtrack(OE) mlx_compat(OE) openvswitch nsh nf_conncount psample xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc netconsole overlay efi_pstore sch_fq_codel zram ip_tables crct10dif_ce qemu_fw_cfg fuse ipv6 crc_ccitt [last unloaded: mlx_compat(OE)]
  CPU: 3 UID: 0 PID: 217 Comm: kworker/u53:2 Tainted: G           OE      6.11.0+ #2
  Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
  Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
  Workqueue: mlx5_lag mlx5_do_bond_work [mlx5_core]
  pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
  pc : mlx5_del_flow_rules+0x24/0x2c0 [mlx5_core]
  lr : mlx5_lag_destroy_definer+0x54/0x100 [mlx5_core]
  sp : ffff800085fafb00
  x29: ffff800085fafb00 x28: ffff0000da0c8000 x27: 0000000000000000
  x26: ffff0000da0c8000 x25: ffff0000da0c8000 x24: ffff0000da0c8000
  x23: ffff0000c31f81a0 x22: 0400000000000000 x21: ffff0000da0c8000
  x20: 0000000000000000 x19: 0000000000000001 x18: 0000000000000000
  x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffff8b0c9350
  x14: 0000000000000000 x13: ffff800081390d18 x12: ffff800081dc3cc0
  x11: 0000000000000001 x10: 0000000000000b10 x9 : ffff80007ab7304c
  x8 : ffff0000d00711f0 x7 : 0000000000000004 x6 : 0000000000000190
  x5 : ffff00027edb3010 x4 : 0000000000000000 x3 : 0000000000000000
  x2 : ffff0000d39b8000 x1 : ffff0000d39b8000 x0 : 0400000000000000
  Call trace:
   mlx5_del_flow_rules+0x24/0x2c0 [mlx5_core]
   mlx5_lag_destroy_definer+0x54/0x100 [mlx5_core]
   mlx5_lag_destroy_definers+0xa0/0x108 [mlx5_core]
   mlx5_lag_port_sel_create+0x2d4/0x6f8 [mlx5_core]
   mlx5_activate_lag+0x60c/0x6f8 [mlx5_core]
   mlx5_do_bond_work+0x284/0x5c8 [mlx5_core]
   process_one_work+0x170/0x3e0
   worker_thread+0x2d8/0x3e0
   kthread+0x11c/0x128
   ret_from_fork+0x10/0x20
  Code: a9025bf5 aa0003f6 a90363f7 f90023f9 (f9400400)
  ---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2025-21675</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: fec: handle page_pool_dev_alloc_pages error

The fec_enet_update_cbd function calls page_pool_dev_alloc_pages but did
not handle the case when it returned NULL. There was a WARN_ON(!new_page)
but it would still proceed to use the NULL pointer and then crash.

This case does seem somewhat rare but when the system is under memory
pressure it can happen. One case where I can duplicate this with some
frequency is when writing over a smbd share to a SATA HDD attached to an
imx6q.

Setting /proc/sys/vm/min_free_kbytes to higher values also seems to solve
the problem for my test case. But it still seems wrong that the fec driver
ignores the memory allocation error and can crash.

This commit handles the allocation error by dropping the current packet.</Note>
    </Notes>
    <CVE>CVE-2025-21676</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gtp: Destroy device along with udp socket's netns dismantle.

gtp_newlink() links the device to a list in dev_net(dev) instead of
src_net, where a udp tunnel socket is created.

Even when src_net is removed, the device stays alive on dev_net(dev).
Then, removing src_net triggers the splat below. [0]

In this example, gtp0 is created in ns2, and the udp socket is created
in ns1.

  ip netns add ns1
  ip netns add ns2
  ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn
  ip netns del ns1

Let's link the device to the socket's netns instead.

Now, gtp_net_exit_batch_rtnl() needs another netdev iteration to remove
all gtp devices in the netns.

[0]:
ref_tracker: net notrefcnt@000000003d6e7d05 has 1/2 users at
     sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236)
     inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252)
     __sock_create (net/socket.c:1558)
     udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18)
     gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423)
     gtp_create_sockets (drivers/net/gtp.c:1447)
     gtp_newlink (drivers/net/gtp.c:1507)
     rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012)
     rtnetlink_rcv_msg (net/core/rtnetlink.c:6922)
     netlink_rcv_skb (net/netlink/af_netlink.c:2542)
     netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347)
     netlink_sendmsg (net/netlink/af_netlink.c:1891)
     ____sys_sendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583)
     ___sys_sendmsg (net/socket.c:2639)
     __sys_sendmsg (net/socket.c:2669)
     do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)

WARNING: CPU: 1 PID: 60 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)
Modules linked in:
CPU: 1 UID: 0 PID: 60 Comm: kworker/u16:2 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Workqueue: netns cleanup_net
RIP: 0010:ref_tracker_dir_exit (lib/ref_tracker.c:179)
Code: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 &lt;0f&gt; 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89
RSP: 0018:ff11000009a07b60 EFLAGS: 00010286
RAX: 0000000000002bd3 RBX: ff1100000f4e1aa0 RCX: 1ffffffff0e40ac6
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3c
RBP: ff1100000f4e1af0 R08: 0000000000000001 R09: fffffbfff0e395ae
R10: 0000000000000001 R11: 0000000000036001 R12: ff1100000f4e1af0
R13: dead000000000100 R14: ff1100000f4e1af0 R15: dffffc0000000000
FS:  0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f9b2464bd98 CR3: 0000000005286005 CR4: 0000000000771ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 ? __warn (kernel/panic.c:748)
 ? ref_tracker_dir_exit (lib/ref_tracker.c:179)
 ? report_bug (lib/bug.c:201 lib/bug.c:219)
 ? handle_bug (arch/x86/kernel/traps.c:285)
 ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1))
 ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)
 ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194)
 ? ref_tracker_dir_exit (lib/ref_tracker.c:179)
 ? __pfx_ref_tracker_dir_exit (lib/ref_tracker.c:158)
 ? kfree (mm/slub.c:4613 mm/slub.c:4761)
 net_free (net/core/net_namespace.c:476 net/core/net_namespace.c:467)
 cleanup_net (net/core/net_namespace.c:664 (discriminator 3))
 process_one_work (kernel/workqueue.c:3229)
 worker_thread (kernel/workqueue.c:3304 kernel/workqueue.c:3391
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-21678</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pktgen: Avoid out-of-bounds access in get_imix_entries

Passing a sufficient amount of imix entries leads to invalid access to the
pkt_dev-&gt;imix_entries array because of the incorrect boundary check.

UBSAN: array-index-out-of-bounds in net/core/pktgen.c:874:24
index 20 is out of range for type 'imix_pkt [20]'
CPU: 2 PID: 1210 Comm: bash Not tainted 6.10.0-rc1 #121
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Call Trace:
&lt;TASK&gt;
dump_stack_lvl lib/dump_stack.c:117
__ubsan_handle_out_of_bounds lib/ubsan.c:429
get_imix_entries net/core/pktgen.c:874
pktgen_if_write net/core/pktgen.c:1063
pde_write fs/proc/inode.c:334
proc_reg_write fs/proc/inode.c:346
vfs_write fs/read_write.c:593
ksys_write fs/read_write.c:644
do_syscall_64 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:130

Found by Linux Verification Center (linuxtesting.org) with SVACE.

[ fp: allow to fill the array completely; minor changelog cleanup ]</Note>
    </Notes>
    <CVE>CVE-2025-21680</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

openvswitch: fix lockup on tx to unregistering netdev with carrier

Commit in a fixes tag attempted to fix the issue in the following
sequence of calls:

    do_output
    -&gt; ovs_vport_send
       -&gt; dev_queue_xmit
          -&gt; __dev_queue_xmit
             -&gt; netdev_core_pick_tx
                -&gt; skb_tx_hash

When device is unregistering, the 'dev-&gt;real_num_tx_queues' goes to
zero and the 'while (unlikely(hash &gt;= qcount))' loop inside the
'skb_tx_hash' becomes infinite, locking up the core forever.

But unfortunately, checking just the carrier status is not enough to
fix the issue, because some devices may still be in unregistering
state while reporting carrier status OK.

One example of such device is a net/dummy.  It sets carrier ON
on start, but it doesn't implement .ndo_stop to set the carrier off.
And it makes sense, because dummy doesn't really have a carrier.
Therefore, while this device is unregistering, it's still easy to hit
the infinite loop in the skb_tx_hash() from the OVS datapath.  There
might be other drivers that do the same, but dummy by itself is
important for the OVS ecosystem, because it is frequently used as a
packet sink for tcpdump while debugging OVS deployments.  And when the
issue is hit, the only way to recover is to reboot.

Fix that by also checking if the device is running.  The running
state is handled by the net core during unregistering, so it covers
unregistering case better, and we don't really need to send packets
to devices that are not running anyway.

While only checking the running state might be enough, the carrier
check is preserved.  The running and the carrier states seem disjoined
throughout the code and different drivers.  And other core functions
like __dev_direct_xmit() check both before attempting to transmit
a packet.  So, it seems safer to check both flags in OVS as well.</Note>
    </Notes>
    <CVE>CVE-2025-21681</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

eth: bnxt: always recalculate features after XDP clearing, fix null-deref

Recalculate features when XDP is detached.

Before:
  # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp
  # ip li set dev eth0 xdp off
  # ethtool -k eth0 | grep gro
  rx-gro-hw: off [requested on]

After:
  # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp
  # ip li set dev eth0 xdp off
  # ethtool -k eth0 | grep gro
  rx-gro-hw: on

The fact that HW-GRO doesn't get re-enabled automatically is just
a minor annoyance. The real issue is that the features will randomly
come back during another reconfiguration which just happens to invoke
netdev_update_features(). The driver doesn't handle reconfiguring
two things at a time very robustly.

Starting with commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in
__bnxt_reserve_rings()") we only reconfigure the RSS hash table
if the "effective" number of Rx rings has changed. If HW-GRO is
enabled "effective" number of rings is 2x what user sees.
So if we are in the bad state, with HW-GRO re-enablement "pending"
after XDP off, and we lower the rings by / 2 - the HW-GRO rings
doing 2x and the ethtool -L doing / 2 may cancel each other out,
and the:

  if (old_rx_rings != bp-&gt;hw_resc.resv_rx_rings &amp;&amp;

condition in __bnxt_reserve_rings() will be false.
The RSS map won't get updated, and we'll crash with:

  BUG: kernel NULL pointer dereference, address: 0000000000000168
  RIP: 0010:__bnxt_hwrm_vnic_set_rss+0x13a/0x1a0
    bnxt_hwrm_vnic_rss_cfg_p5+0x47/0x180
    __bnxt_setup_vnic_p5+0x58/0x110
    bnxt_init_nic+0xb72/0xf50
    __bnxt_open_nic+0x40d/0xab0
    bnxt_open_nic+0x2b/0x60
    ethtool_set_channels+0x18c/0x1d0

As we try to access a freed ring.

The issue is present since XDP support was added, really, but
prior to commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in
__bnxt_reserve_rings()") it wasn't causing major issues.</Note>
    </Notes>
    <CVE>CVE-2025-21682</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gpio: xilinx: Convert gpio_lock to raw spinlock

irq_chip functions may be called in raw spinlock context. Therefore, we
must also use a raw spinlock for our own internal locking.

This fixes the following lockdep splat:

[    5.349336] =============================
[    5.353349] [ BUG: Invalid wait context ]
[    5.357361] 6.13.0-rc5+ #69 Tainted: G        W
[    5.363031] -----------------------------
[    5.367045] kworker/u17:1/44 is trying to lock:
[    5.371587] ffffff88018b02c0 (&amp;chip-&gt;gpio_lock){....}-{3:3}, at: xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8))
[    5.380079] other info that might help us debug this:
[    5.385138] context-{5:5}
[    5.387762] 5 locks held by kworker/u17:1/44:
[    5.392123] #0: ffffff8800014958 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3204)
[    5.402260] #1: ffffffc082fcbdd8 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3205)
[    5.411528] #2: ffffff880172c900 (&amp;dev-&gt;mutex){....}-{4:4}, at: __device_attach (drivers/base/dd.c:1006)
[    5.419929] #3: ffffff88039c8268 (request_class#2){+.+.}-{4:4}, at: __setup_irq (kernel/irq/internals.h:156 kernel/irq/manage.c:1596)
[    5.428331] #4: ffffff88039c80c8 (lock_class#2){....}-{2:2}, at: __setup_irq (kernel/irq/manage.c:1614)
[    5.436472] stack backtrace:
[    5.439359] CPU: 2 UID: 0 PID: 44 Comm: kworker/u17:1 Tainted: G        W          6.13.0-rc5+ #69
[    5.448690] Tainted: [W]=WARN
[    5.451656] Hardware name: xlnx,zynqmp (DT)
[    5.455845] Workqueue: events_unbound deferred_probe_work_func
[    5.461699] Call trace:
[    5.464147] show_stack+0x18/0x24 C
[    5.467821] dump_stack_lvl (lib/dump_stack.c:123)
[    5.471501] dump_stack (lib/dump_stack.c:130)
[    5.474824] __lock_acquire (kernel/locking/lockdep.c:4828 kernel/locking/lockdep.c:4898 kernel/locking/lockdep.c:5176)
[    5.478758] lock_acquire (arch/arm64/include/asm/percpu.h:40 kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851 kernel/locking/lockdep.c:5814)
[    5.482429] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)
[    5.486797] xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8))
[    5.490737] irq_enable (kernel/irq/internals.h:236 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345)
[    5.494060] __irq_startup (kernel/irq/internals.h:241 kernel/irq/chip.c:180 kernel/irq/chip.c:250)
[    5.497645] irq_startup (kernel/irq/chip.c:270)
[    5.501143] __setup_irq (kernel/irq/manage.c:1807)
[    5.504728] request_threaded_irq (kernel/irq/manage.c:2208)</Note>
    </Notes>
    <CVE>CVE-2025-21684</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vfio/platform: check the bounds of read/write syscalls

count and offset are passed from user space and not checked, only
offset is capped to 40 bits, which can be used to read/write out of
bounds of the device.</Note>
    </Notes>
    <CVE>CVE-2025-21687</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/v3d: Assign job pointer to NULL before signaling the fence

In commit e4b5ccd392b9 ("drm/v3d: Ensure job pointer is set to NULL
after job completion"), we introduced a change to assign the job pointer
to NULL after completing a job, indicating job completion.

However, this approach created a race condition between the DRM
scheduler workqueue and the IRQ execution thread. As soon as the fence is
signaled in the IRQ execution thread, a new job starts to be executed.
This results in a race condition where the IRQ execution thread sets the
job pointer to NULL simultaneously as the `run_job()` function assigns
a new job to the pointer.

This race condition can lead to a NULL pointer dereference if the IRQ
execution thread sets the job pointer to NULL after `run_job()` assigns
it to the new job. When the new job completes and the GPU emits an
interrupt, `v3d_irq()` is triggered, potentially causing a crash.

[  466.310099] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c0
[  466.318928] Mem abort info:
[  466.321723]   ESR = 0x0000000096000005
[  466.325479]   EC = 0x25: DABT (current EL), IL = 32 bits
[  466.330807]   SET = 0, FnV = 0
[  466.333864]   EA = 0, S1PTW = 0
[  466.337010]   FSC = 0x05: level 1 translation fault
[  466.341900] Data abort info:
[  466.344783]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
[  466.350285]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[  466.355350]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[  466.360677] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000089772000
[  466.367140] [00000000000000c0] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
[  466.375875] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
[  466.382163] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device algif_hash algif_skcipher af_alg bnep binfmt_misc vc4 snd_soc_hdmi_codec drm_display_helper cec brcmfmac_wcc spidev rpivid_hevc(C) drm_client_lib brcmfmac hci_uart drm_dma_helper pisp_be btbcm brcmutil snd_soc_core aes_ce_blk v4l2_mem2mem bluetooth aes_ce_cipher snd_compress videobuf2_dma_contig ghash_ce cfg80211 gf128mul snd_pcm_dmaengine videobuf2_memops ecdh_generic sha2_ce ecc videobuf2_v4l2 snd_pcm v3d sha256_arm64 rfkill videodev snd_timer sha1_ce libaes gpu_sched snd videobuf2_common sha1_generic drm_shmem_helper mc rp1_pio drm_kms_helper raspberrypi_hwmon spi_bcm2835 gpio_keys i2c_brcmstb rp1 raspberrypi_gpiomem rp1_mailbox rp1_adc nvmem_rmem uio_pdrv_genirq uio i2c_dev drm ledtrig_pattern drm_panel_orientation_quirks backlight fuse dm_mod ip_tables x_tables ipv6
[  466.458429] CPU: 0 UID: 1000 PID: 2008 Comm: chromium Tainted: G         C         6.13.0-v8+ #18
[  466.467336] Tainted: [C]=CRAP
[  466.470306] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT)
[  466.476157] pstate: 404000c9 (nZcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  466.483143] pc : v3d_irq+0x118/0x2e0 [v3d]
[  466.487258] lr : __handle_irq_event_percpu+0x60/0x228
[  466.492327] sp : ffffffc080003ea0
[  466.495646] x29: ffffffc080003ea0 x28: ffffff80c0c94200 x27: 0000000000000000
[  466.502807] x26: ffffffd08dd81d7b x25: ffffff80c0c94200 x24: ffffff8003bdc200
[  466.509969] x23: 0000000000000001 x22: 00000000000000a7 x21: 0000000000000000
[  466.517130] x20: ffffff8041bb0000 x19: 0000000000000001 x18: 0000000000000000
[  466.524291] x17: ffffffafadfb0000 x16: ffffffc080000000 x15: 0000000000000000
[  466.531452] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
[  466.538613] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffffd08c527eb0
[  466.545777] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
[  466.552941] x5 : ffffffd08c4100d0 x4 : ffffffafadfb0000 x3 : ffffffc080003f70
[  466.560102] x2 : ffffffc0829e8058 x1 : 0000000000000001 x0 : 0000000000000000
[  466.567263] Call trace:
[  466.569711]  v3d_irq+0x118/0x2e0 [v3d] (P)
[  466.
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-21688</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

USB: serial: quatech2: fix null-ptr-deref in qt2_process_read_urb()

This patch addresses a null-ptr-deref in qt2_process_read_urb() due to
an incorrect bounds check in the following:

       if (newport &gt; serial-&gt;num_ports) {
               dev_err(&amp;port-&gt;dev,
                       "%s - port change to invalid port: %i\n",
                       __func__, newport);
               break;
       }

The condition doesn't account for the valid range of the serial-&gt;port
buffer, which is from 0 to serial-&gt;num_ports - 1. When newport is equal
to serial-&gt;num_ports, the assignment of "port" in the
following code is out-of-bounds and NULL:

       serial_priv-&gt;current_port = newport;
       port = serial-&gt;port[serial_priv-&gt;current_port];

The fix checks if newport is greater than or equal to serial-&gt;num_ports
indicating it is out-of-bounds.</Note>
    </Notes>
    <CVE>CVE-2025-21689</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: storvsc: Ratelimit warning logs to prevent VM denial of service

If there's a persistent error in the hypervisor, the SCSI warning for
failed I/O can flood the kernel log and max out CPU utilization,
preventing troubleshooting from the VM side. Ratelimit the warning so
it doesn't DoS the VM.</Note>
    </Notes>
    <CVE>CVE-2025-21690</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: sched: fix ets qdisc OOB Indexing

Haowei Yan &lt;g1042620637@gmail.com&gt; found that ets_class_from_arg() can
index an Out-Of-Bound class in ets_class_from_arg() when passed clid of
0. The overflow may cause local privilege escalation.

 [   18.852298] ------------[ cut here ]------------
 [   18.853271] UBSAN: array-index-out-of-bounds in net/sched/sch_ets.c:93:20
 [   18.853743] index 18446744073709551615 is out of range for type 'ets_class [16]'
 [   18.854254] CPU: 0 UID: 0 PID: 1275 Comm: poc Not tainted 6.12.6-dirty #17
 [   18.854821] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
 [   18.856532] Call Trace:
 [   18.857441]  &lt;TASK&gt;
 [   18.858227]  dump_stack_lvl+0xc2/0xf0
 [   18.859607]  dump_stack+0x10/0x20
 [   18.860908]  __ubsan_handle_out_of_bounds+0xa7/0xf0
 [   18.864022]  ets_class_change+0x3d6/0x3f0
 [   18.864322]  tc_ctl_tclass+0x251/0x910
 [   18.864587]  ? lock_acquire+0x5e/0x140
 [   18.865113]  ? __mutex_lock+0x9c/0xe70
 [   18.866009]  ? __mutex_lock+0xa34/0xe70
 [   18.866401]  rtnetlink_rcv_msg+0x170/0x6f0
 [   18.866806]  ? __lock_acquire+0x578/0xc10
 [   18.867184]  ? __pfx_rtnetlink_rcv_msg+0x10/0x10
 [   18.867503]  netlink_rcv_skb+0x59/0x110
 [   18.867776]  rtnetlink_rcv+0x15/0x30
 [   18.868159]  netlink_unicast+0x1c3/0x2b0
 [   18.868440]  netlink_sendmsg+0x239/0x4b0
 [   18.868721]  ____sys_sendmsg+0x3e2/0x410
 [   18.869012]  ___sys_sendmsg+0x88/0xe0
 [   18.869276]  ? rseq_ip_fixup+0x198/0x260
 [   18.869563]  ? rseq_update_cpu_node_id+0x10a/0x190
 [   18.869900]  ? trace_hardirqs_off+0x5a/0xd0
 [   18.870196]  ? syscall_exit_to_user_mode+0xcc/0x220
 [   18.870547]  ? do_syscall_64+0x93/0x150
 [   18.870821]  ? __memcg_slab_free_hook+0x69/0x290
 [   18.871157]  __sys_sendmsg+0x69/0xd0
 [   18.871416]  __x64_sys_sendmsg+0x1d/0x30
 [   18.871699]  x64_sys_call+0x9e2/0x2670
 [   18.871979]  do_syscall_64+0x87/0x150
 [   18.873280]  ? do_syscall_64+0x93/0x150
 [   18.874742]  ? lock_release+0x7b/0x160
 [   18.876157]  ? do_user_addr_fault+0x5ce/0x8f0
 [   18.877833]  ? irqentry_exit_to_user_mode+0xc2/0x210
 [   18.879608]  ? irqentry_exit+0x77/0xb0
 [   18.879808]  ? clear_bhb_loop+0x15/0x70
 [   18.880023]  ? clear_bhb_loop+0x15/0x70
 [   18.880223]  ? clear_bhb_loop+0x15/0x70
 [   18.880426]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
 [   18.880683] RIP: 0033:0x44a957
 [   18.880851] Code: ff ff e8 fc 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 8974 24 10
 [   18.881766] RSP: 002b:00007ffcdd00fad8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
 [   18.882149] RAX: ffffffffffffffda RBX: 00007ffcdd010db8 RCX: 000000000044a957
 [   18.882507] RDX: 0000000000000000 RSI: 00007ffcdd00fb70 RDI: 0000000000000003
 [   18.885037] RBP: 00007ffcdd010bc0 R08: 000000000703c770 R09: 000000000703c7c0
 [   18.887203] R10: 0000000000000080 R11: 0000000000000246 R12: 0000000000000001
 [   18.888026] R13: 00007ffcdd010da8 R14: 00000000004ca7d0 R15: 0000000000000001
 [   18.888395]  &lt;/TASK&gt;
 [   18.888610] ---[ end trace ]---</Note>
    </Notes>
    <CVE>CVE-2025-21692</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/v3d: Ensure job pointer is set to NULL after job completion

After a job completes, the corresponding pointer in the device must
be set to NULL. Failing to do so triggers a warning when unloading
the driver, as it appears the job is still active. To prevent this,
assign the job pointer to NULL after completing the job, indicating
the job has finished.</Note>
    </Notes>
    <CVE>CVE-2025-21697</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gfs2: Truncate address space when flipping GFS2_DIF_JDATA flag

Truncate an inode's address space when flipping the GFS2_DIF_JDATA flag:
depending on that flag, the pages in the address space will either use
buffer heads or iomap_folio_state structs, and we cannot mix the two.</Note>
    </Notes>
    <CVE>CVE-2025-21699</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: sched: Disallow replacing of child qdisc from one parent to another

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

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

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

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

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

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

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

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

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

step 9. Display the class/qdisc layout

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

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

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

step 11. Redisplay again the qdiscs/classes

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

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

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

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

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

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

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

mptcp: handle fastopen disconnect correctly

Syzbot was able to trigger a data stream corruption:

  WARNING: CPU: 0 PID: 9846 at net/mptcp/protocol.c:1024 __mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024
  Modules linked in:
  CPU: 0 UID: 0 PID: 9846 Comm: syz-executor351 Not tainted 6.13.0-rc2-syzkaller-00059-g00a5acdbf398 #0
  Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024
  RIP: 0010:__mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024
  Code: fa ff ff 48 8b 4c 24 18 80 e1 07 fe c1 38 c1 0f 8c 8e fa ff ff 48 8b 7c 24 18 e8 e0 db 54 f6 e9 7f fa ff ff e8 e6 80 ee f5 90 &lt;0f&gt; 0b 90 4c 8b 6c 24 40 4d 89 f4 e9 04 f5 ff ff 44 89 f1 80 e1 07
  RSP: 0018:ffffc9000c0cf400 EFLAGS: 00010293
  RAX: ffffffff8bb0dd5a RBX: ffff888033f5d230 RCX: ffff888059ce8000
  RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
  RBP: ffffc9000c0cf518 R08: ffffffff8bb0d1dd R09: 1ffff110170c8928
  R10: dffffc0000000000 R11: ffffed10170c8929 R12: 0000000000000000
  R13: ffff888033f5d220 R14: dffffc0000000000 R15: ffff8880592b8000
  FS:  00007f6e866496c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f6e86f491a0 CR3: 00000000310e6000 CR4: 00000000003526f0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  Call Trace:
   &lt;TASK&gt;
   __mptcp_clean_una_wakeup+0x7f/0x2d0 net/mptcp/protocol.c:1074
   mptcp_release_cb+0x7cb/0xb30 net/mptcp/protocol.c:3493
   release_sock+0x1aa/0x1f0 net/core/sock.c:3640
   inet_wait_for_connect net/ipv4/af_inet.c:609 [inline]
   __inet_stream_connect+0x8bd/0xf30 net/ipv4/af_inet.c:703
   mptcp_sendmsg_fastopen+0x2a2/0x530 net/mptcp/protocol.c:1755
   mptcp_sendmsg+0x1884/0x1b10 net/mptcp/protocol.c:1830
   sock_sendmsg_nosec net/socket.c:711 [inline]
   __sock_sendmsg+0x1a6/0x270 net/socket.c:726
   ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2583
   ___sys_sendmsg net/socket.c:2637 [inline]
   __sys_sendmsg+0x269/0x350 net/socket.c:2669
   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
   entry_SYSCALL_64_after_hwframe+0x77/0x7f
  RIP: 0033:0x7f6e86ebfe69
  Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 1f 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
  RSP: 002b:00007f6e86649168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
  RAX: ffffffffffffffda RBX: 00007f6e86f491b8 RCX: 00007f6e86ebfe69
  RDX: 0000000030004001 RSI: 0000000020000080 RDI: 0000000000000003
  RBP: 00007f6e86f491b0 R08: 00007f6e866496c0 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6e86f491bc
  R13: 000000000000006e R14: 00007ffe445d9420 R15: 00007ffe445d9508
   &lt;/TASK&gt;

The root cause is the bad handling of disconnect() generated internally
by the MPTCP protocol in case of connect FASTOPEN errors.

Address the issue increasing the socket disconnect counter even on such
a case, to allow other threads waiting on the same socket lock to
properly error out.</Note>
    </Notes>
    <CVE>CVE-2025-21705</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: davicom: fix UAF in dm9000_drv_remove

dm is netdev private data and it cannot be
used after free_netdev() call. Using dm after free_netdev()
can cause UAF bug. Fix it by moving free_netdev() at the end of the
function.

This is similar to the issue fixed in commit
ad297cd2db89 ("net: qcom/emac: fix UAF in emac_remove").

This bug is detected by our static analysis tool.</Note>
    </Notes>
    <CVE>CVE-2025-21715</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vxlan: Fix uninit-value in vxlan_vnifilter_dump()

KMSAN reported an uninit-value access in vxlan_vnifilter_dump() [1].

If the length of the netlink message payload is less than
sizeof(struct tunnel_msg), vxlan_vnifilter_dump() accesses bytes
beyond the message. This can lead to uninit-value access. Fix this by
returning an error in such situations.

[1]
BUG: KMSAN: uninit-value in vxlan_vnifilter_dump+0x328/0x920 drivers/net/vxlan/vxlan_vnifilter.c:422
 vxlan_vnifilter_dump+0x328/0x920 drivers/net/vxlan/vxlan_vnifilter.c:422
 rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6786
 netlink_dump+0x93e/0x15f0 net/netlink/af_netlink.c:2317
 __netlink_dump_start+0x716/0xd60 net/netlink/af_netlink.c:2432
 netlink_dump_start include/linux/netlink.h:340 [inline]
 rtnetlink_dump_start net/core/rtnetlink.c:6815 [inline]
 rtnetlink_rcv_msg+0x1256/0x14a0 net/core/rtnetlink.c:6882
 netlink_rcv_skb+0x467/0x660 net/netlink/af_netlink.c:2542
 rtnetlink_rcv+0x35/0x40 net/core/rtnetlink.c:6944
 netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline]
 netlink_unicast+0xed6/0x1290 net/netlink/af_netlink.c:1347
 netlink_sendmsg+0x1092/0x1230 net/netlink/af_netlink.c:1891
 sock_sendmsg_nosec net/socket.c:711 [inline]
 __sock_sendmsg+0x330/0x3d0 net/socket.c:726
 ____sys_sendmsg+0x7f4/0xb50 net/socket.c:2583
 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2637
 __sys_sendmsg net/socket.c:2669 [inline]
 __do_sys_sendmsg net/socket.c:2674 [inline]
 __se_sys_sendmsg net/socket.c:2672 [inline]
 __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2672
 x64_sys_call+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:47
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Uninit was created at:
 slab_post_alloc_hook mm/slub.c:4110 [inline]
 slab_alloc_node mm/slub.c:4153 [inline]
 kmem_cache_alloc_node_noprof+0x800/0xe80 mm/slub.c:4205
 kmalloc_reserve+0x13b/0x4b0 net/core/skbuff.c:587
 __alloc_skb+0x347/0x7d0 net/core/skbuff.c:678
 alloc_skb include/linux/skbuff.h:1323 [inline]
 netlink_alloc_large_skb+0xa5/0x280 net/netlink/af_netlink.c:1196
 netlink_sendmsg+0xac9/0x1230 net/netlink/af_netlink.c:1866
 sock_sendmsg_nosec net/socket.c:711 [inline]
 __sock_sendmsg+0x330/0x3d0 net/socket.c:726
 ____sys_sendmsg+0x7f4/0xb50 net/socket.c:2583
 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2637
 __sys_sendmsg net/socket.c:2669 [inline]
 __do_sys_sendmsg net/socket.c:2674 [inline]
 __se_sys_sendmsg net/socket.c:2672 [inline]
 __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2672
 x64_sys_call+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:47
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

CPU: 0 UID: 0 PID: 30991 Comm: syz.4.10630 Not tainted 6.12.0-10694-gc44daa7e3c73 #29
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014</Note>
    </Notes>
    <CVE>CVE-2025-21716</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipmr: do not call mr_mfc_uses_dev() for unres entries

syzbot found that calling mr_mfc_uses_dev() for unres entries
would crash [1], because c-&gt;mfc_un.res.minvif / c-&gt;mfc_un.res.maxvif
alias to "struct sk_buff_head unresolved", which contain two pointers.

This code never worked, lets remove it.

[1]
Unable to handle kernel paging request at virtual address ffff5fff2d536613
KASAN: maybe wild-memory-access in range [0xfffefff96a9b3098-0xfffefff96a9b309f]
Modules linked in:
CPU: 1 UID: 0 PID: 7321 Comm: syz.0.16 Not tainted 6.13.0-rc7-syzkaller-g1950a0af2d55 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline]
 pc : mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334
 lr : mr_mfc_uses_dev net/ipv4/ipmr_base.c:289 [inline]
 lr : mr_table_dump+0x694/0x8b0 net/ipv4/ipmr_base.c:334
Call trace:
  mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] (P)
  mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 (P)
  mr_rtm_dumproute+0x254/0x454 net/ipv4/ipmr_base.c:382
  ipmr_rtm_dumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648
  rtnl_dump_all+0x2e4/0x4e8 net/core/rtnetlink.c:4327
  rtnl_dumpit+0x98/0x1d0 net/core/rtnetlink.c:6791
  netlink_dump+0x4f0/0xbc0 net/netlink/af_netlink.c:2317
  netlink_recvmsg+0x56c/0xe64 net/netlink/af_netlink.c:1973
  sock_recvmsg_nosec net/socket.c:1033 [inline]
  sock_recvmsg net/socket.c:1055 [inline]
  sock_read_iter+0x2d8/0x40c net/socket.c:1125
  new_sync_read fs/read_write.c:484 [inline]
  vfs_read+0x740/0x970 fs/read_write.c:565
  ksys_read+0x15c/0x26c fs/read_write.c:708</Note>
    </Notes>
    <CVE>CVE-2025-21719</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iommufd/iova_bitmap: Fix shift-out-of-bounds in iova_bitmap_offset_to_index()

Resolve a UBSAN shift-out-of-bounds issue in iova_bitmap_offset_to_index()
where shifting the constant "1" (of type int) by bitmap-&gt;mapped.pgshift
(an unsigned long value) could result in undefined behavior.

The constant "1" defaults to a 32-bit "int", and when "pgshift" exceeds
31 (e.g., pgshift = 63) the shift operation overflows, as the result
cannot be represented in a 32-bit type.

To resolve this, the constant is updated to "1UL", promoting it to an
unsigned long type to match the operand's type.</Note>
    </Notes>
    <CVE>CVE-2025-21724</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix oops due to unset link speed

It isn't guaranteed that NETWORK_INTERFACE_INFO::LinkSpeed will always
be set by the server, so the client must handle any values and then
prevent oopses like below from happening:

Oops: divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
CPU: 0 UID: 0 PID: 1323 Comm: cat Not tainted 6.13.0-rc7 #2
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41
04/01/2014
RIP: 0010:cifs_debug_data_proc_show+0xa45/0x1460 [cifs] Code: 00 00 48
89 df e8 3b cd 1b c1 41 f6 44 24 2c 04 0f 84 50 01 00 00 48 89 ef e8
e7 d0 1b c1 49 8b 44 24 18 31 d2 49 8d 7c 24 28 &lt;48&gt; f7 74 24 18 48 89
c3 e8 6e cf 1b c1 41 8b 6c 24 28 49 8d 7c 24
RSP: 0018:ffffc90001817be0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff88811230022c RCX: ffffffffc041bd99
RDX: 0000000000000000 RSI: 0000000000000567 RDI: ffff888112300228
RBP: ffff888112300218 R08: fffff52000302f5f R09: ffffed1022fa58ac
R10: ffff888117d2c566 R11: 00000000fffffffe R12: ffff888112300200
R13: 000000012a15343f R14: 0000000000000001 R15: ffff888113f2db58
FS: 00007fe27119e740(0000) GS:ffff888148600000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe2633c5000 CR3: 0000000124da0000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 ? __die_body.cold+0x19/0x27
 ? die+0x2e/0x50
 ? do_trap+0x159/0x1b0
 ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]
 ? do_error_trap+0x90/0x130
 ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]
 ? exc_divide_error+0x39/0x50
 ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]
 ? asm_exc_divide_error+0x1a/0x20
 ? cifs_debug_data_proc_show+0xa39/0x1460 [cifs]
 ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs]
 ? seq_read_iter+0x42e/0x790
 seq_read_iter+0x19a/0x790
 proc_reg_read_iter+0xbe/0x110
 ? __pfx_proc_reg_read_iter+0x10/0x10
 vfs_read+0x469/0x570
 ? do_user_addr_fault+0x398/0x760
 ? __pfx_vfs_read+0x10/0x10
 ? find_held_lock+0x8a/0xa0
 ? __pfx_lock_release+0x10/0x10
 ksys_read+0xd3/0x170
 ? __pfx_ksys_read+0x10/0x10
 ? __rcu_read_unlock+0x50/0x270
 ? mark_held_locks+0x1a/0x90
 do_syscall_64+0xbb/0x1d0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fe271288911
Code: 00 48 8b 15 01 25 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8
20 ad 01 00 f3 0f 1e fa 80 3d b5 a7 10 00 00 74 13 31 c0 0f 05 &lt;48&gt; 3d
00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec
RSP: 002b:00007ffe87c079d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
RAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007fe271288911
RDX: 0000000000040000 RSI: 00007fe2633c6000 RDI: 0000000000000003
RBP: 00007ffe87c07a00 R08: 0000000000000000 R09: 00007fe2713e6380
R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000
R13: 00007fe2633c6000 R14: 0000000000000003 R15: 0000000000000000
 &lt;/TASK&gt;

Fix this by setting cifs_server_iface::speed to a sane value (1Gbps)
by default when link speed is unset.</Note>
    </Notes>
    <CVE>CVE-2025-21725</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Send signals asynchronously if !preemptible

BPF programs can execute in all kinds of contexts and when a program
running in a non-preemptible context uses the bpf_send_signal() kfunc,
it will cause issues because this kfunc can sleep.
Change `irqs_disabled()` to `!preemptible()`.</Note>
    </Notes>
    <CVE>CVE-2025-21728</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

clocksource: Use migrate_disable() to avoid calling get_random_u32() in atomic context

The following bug report happened with a PREEMPT_RT kernel:

  BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
  in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2012, name: kwatchdog
  preempt_count: 1, expected: 0
  RCU nest depth: 0, expected: 0
  get_random_u32+0x4f/0x110
  clocksource_verify_choose_cpus+0xab/0x1a0
  clocksource_verify_percpu.part.0+0x6b/0x330
  clocksource_watchdog_kthread+0x193/0x1a0

It is due to the fact that clocksource_verify_choose_cpus() is invoked with
preemption disabled.  This function invokes get_random_u32() to obtain
random numbers for choosing CPUs.  The batched_entropy_32 local lock and/or
the base_crng.lock spinlock in driver/char/random.c will be acquired during
the call. In PREEMPT_RT kernel, they are both sleeping locks and so cannot
be acquired in atomic context.

Fix this problem by using migrate_disable() to allow smp_processor_id() to
be reliably used without introducing atomic context. preempt_disable() is
then called after clocksource_verify_choose_cpus() but before the
clocksource measurement is being run to avoid introducing unexpected
latency.</Note>
    </Notes>
    <CVE>CVE-2025-21767</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vxlan: check vxlan_vnigroup_init() return value

vxlan_init() must check vxlan_vnigroup_init() success
otherwise a crash happens later, spotted by syzbot.

Oops: general protection fault, probably for non-canonical address 0xdffffc000000002c: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000160-0x0000000000000167]
CPU: 0 UID: 0 PID: 7313 Comm: syz-executor147 Not tainted 6.14.0-rc1-syzkaller-00276-g69b54314c975 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
 RIP: 0010:vxlan_vnigroup_uninit+0x89/0x500 drivers/net/vxlan/vxlan_vnifilter.c:912
Code: 00 48 8b 44 24 08 4c 8b b0 98 41 00 00 49 8d 86 60 01 00 00 48 89 c2 48 89 44 24 10 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 &lt;80&gt; 3c 02 00 0f 85 4d 04 00 00 49 8b 86 60 01 00 00 48 ba 00 00 00
RSP: 0018:ffffc9000cc1eea8 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000001 RCX: ffffffff8672effb
RDX: 000000000000002c RSI: ffffffff8672ecb9 RDI: ffff8880461b4f18
RBP: ffff8880461b4ef4 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000020000
R13: ffff8880461b0d80 R14: 0000000000000000 R15: dffffc0000000000
FS:  00007fecfa95d6c0(0000) GS:ffff88806a600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fecfa95cfb8 CR3: 000000004472c000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
  vxlan_uninit+0x1ab/0x200 drivers/net/vxlan/vxlan_core.c:2942
  unregister_netdevice_many_notify+0x12d6/0x1f30 net/core/dev.c:11824
  unregister_netdevice_many net/core/dev.c:11866 [inline]
  unregister_netdevice_queue+0x307/0x3f0 net/core/dev.c:11736
  register_netdevice+0x1829/0x1eb0 net/core/dev.c:10901
  __vxlan_dev_create+0x7c6/0xa30 drivers/net/vxlan/vxlan_core.c:3981
  vxlan_newlink+0xd1/0x130 drivers/net/vxlan/vxlan_core.c:4407
  rtnl_newlink_create net/core/rtnetlink.c:3795 [inline]
  __rtnl_newlink net/core/rtnetlink.c:3906 [inline]</Note>
    </Notes>
    <CVE>CVE-2025-21790</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

NFSD: fix hang in nfsd4_shutdown_callback

If nfs4_client is in courtesy state then there is no point to send
the callback. This causes nfsd4_shutdown_callback to hang since
cl_cb_inflight is not 0. This hang lasts about 15 minutes until TCP
notifies NFSD that the connection was dropped.

This patch modifies nfsd4_run_cb_work to skip the RPC call if
nfs4_client is in courtesy state.</Note>
    </Notes>
    <CVE>CVE-2025-21795</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: ethernet: ti: am65-cpsw: fix freeing IRQ in am65_cpsw_nuss_remove_tx_chns()

When getting the IRQ we use k3_udma_glue_tx_get_irq() which returns
negative error value on error. So not NULL check is not sufficient
to deteremine if IRQ is valid. Check that IRQ is greater then zero
to ensure it is valid.

There is no issue at probe time but at runtime user can invoke
.set_channels which results in the following call chain.
am65_cpsw_set_channels()
 am65_cpsw_nuss_update_tx_rx_chns()
  am65_cpsw_nuss_remove_tx_chns()
  am65_cpsw_nuss_init_tx_chns()

At this point if am65_cpsw_nuss_init_tx_chns() fails due to
k3_udma_glue_tx_get_irq() then tx_chn-&gt;irq will be set to a
negative value.

Then, at subsequent .set_channels with higher channel count we
will attempt to free an invalid IRQ in am65_cpsw_nuss_remove_tx_chns()
leading to a kernel warning.

The issue is present in the original commit that introduced this driver,
although there, am65_cpsw_nuss_update_tx_rx_chns() existed as
am65_cpsw_nuss_update_tx_chns().</Note>
    </Notes>
    <CVE>CVE-2025-21799</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: hns3: fix oops when unload drivers paralleling

When unload hclge driver, it tries to disable sriov first for each
ae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at
the time, because it removes all the ae_dev nodes, and it may cause
oops.

But we can't simply use hnae3_common_lock for this. Because in the
process flow of pci_disable_sriov(), it will trigger the remove flow
of VF, which will also take hnae3_common_lock.

To fixes it, introduce a new mutex to protect the unload process.</Note>
    </Notes>
    <CVE>CVE-2025-21802</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:kernel-default-6.4.0-150600.23.42.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When switching to other buffers using the :all command and visual mode still being active, this may cause a heap-buffer overflow, because Vim does not properly end visual mode and therefore may try to access beyond the end of a line in a buffer. In Patch 9.1.1003 Vim will correctly reset the visual mode before opening other windows and buffers and therefore fix this bug. In addition it does verify that it won't try to access a position if the position is greater than the corresponding buffer line. Impact is medium since the user must have switched on visual mode when executing the :all ex command. The Vim project would like to thank github user gandalf4a for reporting this issue. The issue has been fixed as of Vim patch v9.1.1003</Note>
    </Notes>
    <CVE>CVE-2025-22134</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:vim-9.1.1101-150500.20.21.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:vim-data-common-9.1.1101-150500.20.21.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 segmentation fault was found in Vim before 9.1.1043. In silent Ex mode (-s -e), Vim typically doesn't show a screen and just operates silently in batch mode. However, it is still possible to trigger the function that handles the scrolling of a gui version of Vim by feeding some binary characters to Vim. The function that handles the scrolling however may be triggering a redraw, which will access the ScreenLines pointer, even so this variable hasn't been allocated (since there is no screen). This vulnerability is fixed in 9.1.1043.</Note>
    </Notes>
    <CVE>CVE-2025-24014</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:vim-9.1.1101-150500.20.21.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:vim-data-common-9.1.1101-150500.20.21.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">libxml2 before 2.12.10 and 2.13.x before 2.13.6 has a stack-based buffer overflow in xmlSnprintfElements in valid.c. To exploit this, DTD validation must occur for an untrusted document or untrusted DTD. NOTE: this is similar to CVE-2017-9047.</Note>
    </Notes>
    <CVE>CVE-2025-24928</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:libxml2-2-2.10.3-150500.5.23.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 OpenSSH when the VerifyHostKeyDNS option is enabled. A machine-in-the-middle attack can be performed by a malicious machine impersonating a legit server. This issue occurs due to how OpenSSH mishandles error codes in specific conditions when verifying the host key. For an attack to be considered successful, the attacker needs to manage to exhaust the client's memory resource first, turning the attack complexity high.</Note>
    </Notes>
    <CVE>CVE-2025-26465</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:openssh-9.6p1-150600.6.15.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:openssh-clients-9.6p1-150600.6.15.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:openssh-common-9.6p1-150600.6.15.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:openssh-server-9.6p1-150600.6.15.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">libxml2 before 2.12.10 and 2.13.x before 2.13.6 has a NULL pointer dereference in xmlPatMatch in pattern.c.</Note>
    </Notes>
    <CVE>CVE-2025-27113</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-chost-byos-v20250320-arm64:libxml2-2-2.10.3-150500.5.23.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
</cvrfdoc>
