<?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:1448-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:1448-1</ID>
    </Identification>
    <Status>Interim</Status>
    <Version>1</Version>
    <RevisionHistory>
      <Revision>
        <Number>1</Number>
        <Date>2025-12-07T16:01:18Z</Date>
        <Description>current</Description>
      </Revision>
    </RevisionHistory>
    <InitialReleaseDate>2025-05-28T01:00:00Z</InitialReleaseDate>
    <CurrentReleaseDate>2025-05-28T01: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:1448-1 / google/sles-15-sp6-byos-v20250528-arm64</Note>
    <Note Title="Details" Type="General" Ordinal="2" xml:lang="en">This image update for google/sles-15-sp6-byos-v20250528-arm64 contains the following changes:
Package aaa_base was updated:

- Add patch git-51-fbf7ee9dc9cd970532a54eed6472d7f3b0e7f431.patch  * If a user switches the login shell respect the already set
    PATH environment (bsc#1235481)

- add patch aaa_base-rc.status.patch (bsc#1236033)
  (no git, file is gone in factory/tumbleweed)
  update detection for systemd in rc.status, mountpoint for
  cgroup changed with cgroup2, so just check if pid 1 is systemd

Package apparmor was updated:

- Add dac_read_search capability for unix_chkpwd to allow it to read the shadow  file even if it has 000 permissions. This is needed after the CVE-2024-10041
  fix in PAM.
  * unix-chkpwd-add-read-capability.path, bsc#1241678

- Allow pam_unix to execute unix_chkpwd with abi/3.0
  - remove dovecot-unix_chkpwd.diff
  - Add allow-pam_unix-to-execute-unix_chkpwd.patch
  - Add revert-abi-change-for-unix_chkpwd.patch
  (bsc#1234452, bsc#1232234)

Package augeas was updated:

- Add patch, fix for bsc#1239909 / CVE-2025-2588:  * CVE-2025-2588.patch

Package ca-certificates-mozilla was updated:

- revert the distrusted certs for now. originally these only  distrust &amp;quot;new issued&amp;quot; certs starting after a certain date,
  while old certs should still work. (bsc#1240343)
- remove-distrusted.patch: removed

Package cifs-utils was updated:

- CVE-2025-2312: cifs-utils: cifs.upcall makes an upcall to the wrong  namespace in containerized environments while trying to get Kerberos
  credentials (bsc#1239680)
  * add New-mount-option-for-cifs.upcall-namespace-reso.patch

Package cloud-regionsrv-client was updated:

- Update version to 10.4.0  + Remove repositories when the package is being removed
    We do not want to leave repositories behind refering to the plugin that
    is being removed when the package gets removed (bsc#1240310, bsc#1240311)
  + Turn docker into an optional setup (jsc#PCT-560)
    Change the Requires into a Recommends and adapt the code accordingly
  + Support flexible licenses in GCE (jsc#PCT-531)
  + Drop the azure-addon package it is geting replaced by the
    license-watcher package which has a generic implementation of the
    same functionality.
  + Handle cache inconsistencies (bsc#1218345)
  + Properly handle the zypper root target argument (bsc#1240997)

Package containerd was updated:

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

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

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

Package lvm2 was updated:

- LVM filter behaves unexpectedly for MPIO devices in SLES15SP5 (bsc#1216938)  * set lvm.conf devices.multipath_wwids_file=&amp;quot;&amp;quot;

Package glib2 was updated:

- Add glib2-CVE-2025-3360.patch:  Backport 8d60d7dc from upstream, Fix integer overflow when
  parsing very long ISO8601 inputs. This will only happen with
  invalid (or maliciously invalid) potential ISO8601 strings,
  but `g_date_time_new_from_iso8601()` needs to be robust against
  that.
  (CVE-2025-3360, bsc#1240897)

Package glibc was updated:

- static-setuid-ld-library-path.patch: elf: Ignore LD_LIBRARY_PATH and  debug env var for setuid for static (CVE-2025-4802, bsc#1243317)

- Add support for userspace livepatching for ppc64le (jsc#PED-11850)

- pthread-wakeup.patch: pthreads NPTL: lost wakeup fix 2 (bsc#1234128, BZ
  [#25847])

- Mark functions in libc_nonshared.a as hidden (bsc#1239883)

- Bump minimal kernel version to 4.3 to enable use of direct socketcalls
  on x86-32 and s390x (bsc#1234713)

Package grub2 was updated:

- Fix CVE-2025-4382: TPM auto-decryption data exposure (bsc#1242971)  * 0001-kern-rescue_reader-Block-the-rescue-mode-until-the-C.patch
  * 0002-commands-search-Introduce-the-cryptodisk-only-argume.patch
  * 0003-disk-diskfilter-Introduce-the-cryptocheck-command.patch
  * 0004-commands-search-Add-the-diskfilter-support.patch
  * 0005-docs-Document-available-crypto-disks-checks.patch
  * 0006-disk-cryptodisk-Add-the-erase-secrets-function.patch
  * 0007-disk-cryptodisk-Wipe-the-passphrase-from-memory.patch
  * 0008-cryptocheck-Add-quiet-option.patch
- patch rebased
  * 0001-Improve-TPM-key-protection-on-boot-interruptions.patch
  * 0004-Key-revocation-on-out-of-bound-file-access.patch
- patch refrehed
  * 0002-Requiring-authentication-after-tpm-unlock-for-CLI-ac.patch

- Refresh PPC NVMEoF ofpath related patches to newer revision
  * 0002-ieee1275-ofpath-enable-NVMeoF-logical-device-transla.patch
- Patch refreshed
  * 0001-grub2-Set-multiple-device-path-for-a-nvmf-boot-devic.patch
- Patch obsoleted
  * 0004-ofpath-controller-name-update.patch
  * 0001-squash-ieee1275-ofpath-enable-NVMeoF-logical-device-.patch
- Fix segmentation fault error in grub2-probe with target=hints_string
  (bsc#1235971) (bsc#1235958) (bsc#1239651)
  * 0001-ofpath-Add-error-check-in-NVMEoF-device-translation.patch

Package hwinfo was updated:

- merge gh#openSUSE/hwinfo#156- fix network card detection on aarch64 (bsc#1240648)
- 21.88

Package iproute2 was updated:

- avoid spurious cgroup warning (bsc#1234383):  - ss-Tone-down-cgroup-path-resolution.patch

Package kbd was updated:

- Don't search for resources in the current directory. It can cause  unwanted side effects or even infinite loop (bsc#1237230,
  kbd-ignore-working-directory-1.patch,
  kbd-ignore-working-directory-2.patch,
  kbd-ignore-working-directory-3.patch).

Package kernel-default was updated:

- dm: fix copying after src array boundaries (git-fixes).- commit 10c16a9

- dm: add missing unlock on in dm_keyslot_evict() (git-fixes).
- commit a94a8c2

- codel: remove sch-&amp;gt;q.qlen check before
  qdisc_tree_reduce_backlog() (CVE-2025-37798 bsc#1242414).
- commit 8fb5816

- Update
  patches.suse/net-smc-initialize-close_work-early-to-avoid-warning.patch
  (CVE-2024-56641 bsc#1235526 bsc#1242985).
- commit d393a0f

- mptcp: fix NULL pointer in can_accept_new_subflow
  (CVE-2025-23145 bsc#1242596).
- mptcp: relax check on MPC passive fallback (git-fixes).
- mptcp: refine opt_mp_capable determination (git-fixes).
- mptcp: use OPTION_MPTCP_MPJ_SYN in subflow_check_req()
  (git-fixes).
- mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()
  (git-fixes CVE-2024-35840 bsc#1224597).
- mptcp: strict validation before using mp_opt-&amp;gt;hmac (git-fixes).
- commit b0b581d

- mptcp: mptcp_parse_option() fix for MPTCPOPT_MP_JOIN
  (git-fixes).
- blacklist.conf:
  - remove the entry for commit be1d9d9d38da which was blacklisted as not
    needed because of absence of this backport
- commit 07c39d4

- ax25: Remove broken autobind (CVE-2025-22109 bsc#1241573).
- commit 9a9abc7

- udp: Fix memory accounting leak (CVE-2025-22058 bsc#1241332).
- commit 6a0c03a

- perf: arm_cspmu: nvidia: monitor all ports by default (bsc#1242172)
- commit bf5ce56

- perf: arm_cspmu: nvidia: enable NVLINK-C2C port filtering (bsc#1242172)
- commit d976f98

- perf: arm_cspmu: nvidia: fix sysfs path in the kernel doc (bsc#1242172)
- commit bcf5e61

- perf: arm_cspmu: nvidia: remove unsupported SCF events (bsc#1242172)
- commit 4647012

- x86/ibt: Keep IBT disabled during alternative patching (bsc#1242006 CVE-2024-28956).
- commit fac02ba

- x86/its: Align RETs in BHB clear sequence to avoid thunking (bsc#1242006 CVE-2024-28956).
- commit 909407f

- x86/its: Add support for RSB stuffing mitigation (bsc#1242006 CVE-2024-28956).
- commit 42d05af

- x86/its: Add &amp;quot;vmexit&amp;quot; option to skip mitigation on some CPUs (bsc#1242006 CVE-2024-28956).
- commit cefce67

- x86/its: Enable Indirect Target Selection mitigation (bsc#1242006 CVE-2024-28956).
- commit 6720dce

- x86/its: Add support for ITS-safe return thunk (bsc#1242006 CVE-2024-28956).
- commit b904ebb

- watch_queue: fix pipe accounting mismatch (CVE-2025-23138 bsc#1241648).
- commit 53d2fbb

- x86/its: Add support for ITS-safe indirect thunk (bsc#1242006 CVE-2024-28956).
- commit 73d0713

- x86/its: Enumerate Indirect Target Selection (ITS) bug (bsc#1242006 CVE-2024-28956).
- commit 0ceddfb

- Documentation: x86/bugs/its: Add ITS documentation (bsc#1242006 CVE-2024-28956).
- commit 8fd974a

- vmxnet3: Fix malformed packet sizing in vmxnet3_process_xdp
  (CVE-2025-37799 bsc#1242283).
- commit f53c65a

- btrfs: always fallback to buffered write if the inode  requires
  checksum (bsc#1242831 bsc#1242710).
- commit fd92bec

- x86/bhi: Do not set BHI_DIS_S in 32-bit mode (bsc#1242778).
- x86/bpf: Add IBHF call at end of classic BPF (bsc#1242778).
- x86/bpf: Call branch history clearing sequence on exit
  (bsc#1242778).
- commit 7613146

- jbd2: increase IO priority for writing revoke records
  (bsc#1242332).
- commit a27757f

- Bluetooth: btnxpuart: Fix kernel panic during FW release
  (bsc#1241456 CVE-2025-22102).
- commit 9e6b312

- Bluetooth: btnxpuart: Remove check for CTS low after FW download
  (bsc#1241456 CVE-2025-22102).
- commit 43b7feb

- firmware: arm_ffa: Skip Rx buffer ownership release if not
  acquired (git-fixes).
- firmware: arm_scmi: Balance device refcount when destroying
  devices (git-fixes).
- commit e6126fe

- ext4: goto right label 'out_mmap_sem' in ext4_setattr()
  (bsc#1242556).
- commit f73dc04

- mm: fix filemap_get_folios_contig returning batches of identical
  folios (bsc#1242327).
- commit ab60c72

- mm: fix error handling in __filemap_get_folio() with FGP_NOWAIT
  (bsc#1242326).
- commit eefd306

- mm/readahead: fix large folio support in async readahead
  (bsc#1242321).
- commit ca8ae9b

- mm: fix oops when filemap_map_pmd() without prealloc_pte
  (bsc#1242546).
- commit d84ed9f

- udf: Fix inode_getblk() return value (bsc#1242313).
- commit 083cf55

- udf: Verify inode link counts before performing rename
  (bsc#1242314).
- commit 8e7cda1

- udf: Skip parent dir link count update if corrupted
  (bsc#1242315).
- commit 94318f0

- ext4: fix FS_IOC_GETFSMAP handling (bsc#1240557).
- commit 531b964

- ext4: make block validity check resistent to sb bh corruption
  (bsc#1242348).
- commit 12e4947

- ext4: don't treat fhandle lookup of ea_inode as FS corruption
  (bsc#1242347).
- commit 3337bde

- jbd2: add a missing data flush during file and fs
  synchronization (bsc#1242346).
- commit 0ebdf6c

- ext4: don't over-report free space or inodes in statvfs
  (bsc#1242345).
- commit c197ee4

- jbd2: fix off-by-one while erasing journal (bsc#1242344).
- commit 362ca97

- jbd2: remove wrong sb-&amp;gt;s_sequence check (bsc#1242343).
- commit b288b9a

- ext4: add missing brelse() for bh2 in ext4_dx_add_entry()
  (bsc#1242342).
- commit 8643d9f

- ext4: protect ext4_release_dquot against freezing (bsc#1242335).
- commit 532c985

- jbd2: flush filesystem device before updating tail sequence
  (bsc#1242333).
- commit 79495ff

- ext4: partial zero eof block on unaligned inode size extension
  (bsc#1242336).
- commit 992adfb

- ext4: correct encrypted dentry name hash when not casefolded
  (bsc#1242540).
- commit 71bfc00

- ext4: treat end of range as exclusive in ext4_zero_range()
  (bsc#1242539).
- commit 8950964

- ext4: unify the type of flexbg_size to unsigned int
  (bsc#1242538).
  Refresh: patches.suse/ext4-avoid-online-resizing-failures-due-to-oversized.patch
- commit 9b599f9

- jbd2: increase the journal IO's priority (bsc#1242537).
- commit 65fd6c7

- ext4: replace the traditional ternary conditional operator
  with with max()/min() (bsc#1242536).
  Refresh patches.suse/ext4-move-setting-of-trimmed-bit-into-ext4_try_to_tr.patch
  Refresh patches.suse/ext4-fix-inconsistent-between-segment-fstrim-and-ful.patch
- commit 9de0d03

- splice: remove duplicate noinline from pipe_clear_nowait
  (bsc#1242328).
- commit 8a9c110

- fs: consistently deref the files table with
  rcu_dereference_raw() (bsc#1242535).
- commit 0f7e4fb

- fs: support relative paths with FSCONFIG_SET_STRING (git-fixes).
- commit 51930da

- vfs: don't mod negative dentry count when on shrinker list
  (bsc#1242534).
- commit 25c9c4a

- fs: better handle deep ancestor chains in is_subdir()
  (bsc#1242528).
  Refresh patches.suse/dcache-keep-dentry_hashtable-or-d_hash_shift-even-when-not.patch
- commit 42bc37f

- fs: don't allow non-init s_user_ns for filesystems without
  FS_USERNS_MOUNT (bsc#1242526).
- commit 08659e8

- isofs: fix KMSAN uninit-value bug in do_isofs_readdir()
  (bsc#1242307).
- commit 08eabe6

- Update
  patches.suse/OPP-add-index-check-to-assert-to-avoid-buffer-overfl.patch
  (bsc#1238961 CVE-2024-57998 bsc#1238527).
- Update
  patches.suse/PCI-ASPM-Fix-link-state-exit-during-switch-upstream-.patch
  (git-fixes CVE-2024-58093 bsc#1241347).
- Update
  patches.suse/RDMA-erdma-Prevent-use-after-free-in-erdma_accept_ne.patch
  (git-fixes CVE-2025-22088 bsc#1241528).
- Update
  patches.suse/RDMA-mlx5-Fix-mlx5_poll_one-cur_qp-update-flow.patch
  (git-fixes CVE-2025-22086 bsc#1241458).
- Update
  patches.suse/acpi-nfit-fix-narrowing-conversion-in-acpi_nfit_ctl.patch
  (git-fixes CVE-2025-22044 bsc#1241424).
- Update
  patches.suse/arm64-Don-t-call-NULL-in-do_compat_alignment_fixup.patch
  (git-fixes CVE-2025-22033 bsc#1241436).
- Update
  patches.suse/bnxt_en-Mask-the-bd_cnt-field-in-the-TX-BD-properly.patch
  (git-fixes CVE-2025-22108 bsc#1241574).
- Update
  patches.suse/bpf-avoid-holding-freeze_mutex-during-mmap-operation.patch
  (git-fixes CVE-2025-21853 bsc#1239476).
- Update
  patches.suse/dlm-prevent-NPD-when-writing-a-positive-value-to-event_done.patch
  (git-fixes CVE-2025-23131 bsc#1241601).
- Update
  patches.suse/drm-amd-display-avoid-NPD-when-ASIC-does-not-support.patch
  (git-fixes CVE-2025-22093 bsc#1241545).
- Update
  patches.suse/drm-vkms-Fix-use-after-free-and-double-free-on-init-.patch
  (git-fixes CVE-2025-22097 bsc#1241541).
- Update patches.suse/fou-fix-initialization-of-grc.patch
  (CVE-2024-46763 bsc#1230764 CVE-2024-46865 bsc#1231103).
- Update
  patches.suse/idpf-check-error-for-register_netdev-on-init.patch
  (git-fixes CVE-2025-22116 bsc#1241459).
- Update
  patches.suse/idpf-fix-adapter-NULL-pointer-dereference-on-reboot.patch
  (git-fixes CVE-2025-22065 bsc#1241333).
- Update
  patches.suse/jfs-add-check-read-only-before-truncation-in-jfs_truncate_nolock.patch
  (git-fixes CVE-2024-58094 bsc#1241443).
- Update
  patches.suse/jfs-add-check-read-only-before-txBeginAnon-call.patch
  (git-fixes CVE-2024-58095 bsc#1241442).
- Update
  patches.suse/media-streamzap-fix-race-between-device-disconnectio.patch
  (git-fixes CVE-2025-22027 bsc#1241369).
- Update
  patches.suse/net-Add-rx_skb-of-kfree_skb-to-raw_tp_null_args.patch
  (bsc#1235501 CVE-2024-56702 CVE-2025-21852 bsc#1239487).
- Update
  patches.suse/netfilter-br_netfilter-skip-conntrack-input-hook-for.patch
  (CVE-2024-27415 bsc#1224757 CVE-2024-27018 bsc#1223809).
- Update
  patches.suse/nfsd-put-dl_stid-if-fail-to-queue-dl_recall.patch
  (git-fixes CVE-2025-22025 bsc#1241361).
- Update
  patches.suse/ntb_hw_switchtec-Fix-shift-out-of-bounds-in-switchte.patch
  (git-fixes CVE-2023-53034 bsc#1241341).
- Update
  patches.suse/ocfs2-handle-a-symlink-read-error-correctly.patch
  (git-fixes CVE-2024-58001 bsc#1239079).
- Update
  patches.suse/rtnetlink-Allocate-vfinfo-size-for-VF-GUIDs-when-sup.patch
  (bsc#1224013 CVE-2025-22075 bsc#1241402).
- Update
  patches.suse/sctp-add-mutual-exclusion-in-proc_sctp_do_udp_port.patch
  (git-fixes CVE-2025-22062 bsc#1241412).
- Update
  patches.suse/tcp-fix-mptcp-DSS-corruption-due-to-large-pmtu-xmit.patch
  (git-fixes CVE-2024-50083 bsc#1232493).
- Update
  patches.suse/thermal-int340x-Add-NULL-check-for-adev.patch
  (git-fixes CVE-2025-23136 bsc#1241357).
- Update patches.suse/usbnet-fix-NPE-during-rx_complete.patch
  (git-fixes CVE-2025-22050 bsc#1241441).
- Update
  patches.suse/wifi-ath11k-Clear-affinity-hint-before-calling-ath11.patch
  (git-fixes CVE-2025-23129 bsc#1241599).
- Update
  patches.suse/wifi-ath11k-add-srng-lock-for-ath11k_hal_srng_-in-mo.patch
  (git-fixes CVE-2024-58096 bsc#1241344).
- Update
  patches.suse/wifi-ath11k-fix-RCU-stall-while-reaping-monitor-dest.patch
  (git-fixes CVE-2024-58097 bsc#1241343).
- Update
  patches.suse/wifi-ath12k-Clear-affinity-hint-before-calling-ath12.patch
  (git-fixes CVE-2025-22128 bsc#1241598).
- commit a961a1a

- cifs: Fix integer overflow while processing actimeo mount option
  (git-fixes).
- commit 747d942

- iommu: Fix two issues in iommu_copy_struct_from_user()
  (git-fixes).
- commit 7b79fa9

- cifs: Fix integer overflow while processing acdirmax mount
  option (CVE-2025-21963 bsc#1240717).
- commit 5907e46

- cifs: Fix integer overflow while processing acregmax mount
  option (CVE-2025-21964 bsc#1240740).
- commit a723b7b

- cifs: Fix integer overflow while processing closetimeo mount
  option (CVE-2025-21962 bsc#1240655).
- commit 03a43b4

- mptcp: consolidate suboption status (CVE-2025-21707
  bsc#1238862).
- commit 18d9efe

- powerpc: Don't use --- in kernel logs (git-fixes).
- commit df3b280

- tools/hv: update route parsing in kvp daemon (git-fixes).
- commit 2e81126

- bpf: Fix bpf_sk_select_reuseport() memory leak (bsc#1236704
  CVE-2025-21683).
- commit e163503

- i2c: imx-lpi2c: Fix clock count when probe defers (git-fixes).
- ASoC: soc-pcm: Fix hw_params() and DAPM widget sequence
  (git-fixes).
- ALSA: hda/realtek: Fix built-mic regression on other ASUS models
  (git-fixes).
- ALSA: hda/realtek - Enable speaker for HP platform (git-fixes).
- commit 5b6152a

- spi: tegra114: Don't fail set_cs_timing when delays are zero
  (git-fixes).
- drm/i915/pxp: fix undefined reference to
  `intel_pxp_gsccs_is_ready_for_sessions' (git-fixes).
- drm: Select DRM_KMS_HELPER from DRM_DEBUG_DP_MST_TOPOLOGY_REFS
  (git-fixes).
- drm/fdinfo: Protect against driver unbind (git-fixes).
- drm/nouveau: Fix WARN_ON in nouveau_fence_context_kill()
  (git-fixes).
- drm/amd/display: Force full update in gpu reset (stable-fixes).
- ata: libata-scsi: Improve CDL control (git-fixes).
- ata: libata-scsi: Fix ata_msense_control_ata_feature()
  (git-fixes).
- ata: libata-scsi: Fix ata_mselect_control_ata_feature() return
  type (git-fixes).
- USB: serial: simple: add OWON HDS200 series oscilloscope support
  (stable-fixes).
- USB: serial: ftdi_sio: add support for Abacus Electrics Optical
  Probe (stable-fixes).
- USB: serial: option: add Sierra Wireless EM9291 (stable-fixes).
- usb: quirks: Add delay init quirk for SanDisk 3.2Gen1 Flash
  Drive (stable-fixes).
- USB: VLI disk crashes if LPM is used (stable-fixes).
- USB: storage: quirk for ADATA Portable HDD CH94 (stable-fixes).
- usb: quirks: add DELAY_INIT quirk for Silicon Motion Flash Drive
  (stable-fixes).
- USB: OHCI: Add quirk for LS7A OHCI controller (rev 0x02)
  (stable-fixes).
- mei: me: add panther lake H DID (stable-fixes).
- spi: tegra210-quad: add rate limiting and simplify timeout
  error message (stable-fixes).
- spi: tegra210-quad: use WARN_ON_ONCE instead of WARN_ON for
  timeouts (stable-fixes).
- ACPI: EC: Set ec_no_wakeup for Lenovo Go S (stable-fixes).
- ACPI PPTT: Fix coding mistakes in a couple of sizeof() calls
  (stable-fixes).
- ntb_hw_amd: Add NTB PCI ID for new gen CPU (stable-fixes).
- ntb: reduce stack usage in idt_scan_mws (stable-fixes).
- rtc: pcf85063: do a SW reset if POR failed (stable-fixes).
- thunderbolt: Scan retimers after device router has been
  enumerated (stable-fixes).
- usb: host: xhci-plat: mvebu: use -&amp;gt;quirks instead of
  - &amp;gt;init_quirk() func (stable-fixes).
- usb: gadget: aspeed: Add NULL pointer check in
  ast_vhub_init_dev() (stable-fixes).
- usb: dwc3: gadget: Avoid using reserved endpoints on Intel
  Merrifield (stable-fixes).
- usb: dwc3: gadget: Refactor loop to avoid NULL endpoints
  (stable-fixes).
- usb: host: max3421-hcd: Add missing spi_device_id table
  (stable-fixes).
- sound/virtio: Fix cancel_sync warnings on uninitialized
  work_structs (stable-fixes).
- dmaengine: dmatest: Fix dmatest waiting less when interrupted
  (stable-fixes).
- iio: adc: ad7768-1: Fix conversion result sign (git-fixes).
- iio: adc: ad7768-1: Move setting of val a bit later to avoid
  unnecessary return value check (stable-fixes).
- pinctrl: renesas: rza2: Fix potential NULL pointer dereference
  (stable-fixes).
- crypto: ccp - Add support for PCI device 0x1134 (stable-fixes).
- auxdisplay: hd44780: Fix an API misuse in hd44780.c (git-fixes).
- auxdisplay: hd44780: Convert to platform remove callback
  returning void (stable-fixes).
- commit fe3cf03

- net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry() (CVE-2025-22107 bsc#1241575)
- commit 673084b

- ibmvnic: Use kernel helpers for hex dumps (CVE-2025-22104 bsc#1241550)
- commit 44ef4eb

- dm: always update the array size in realloc_argv on success
  (git-fixes).
- commit 80e573b

- dm-bufio: don't schedule in atomic context (git-fixes).
- commit 59b9988

- dm-ebs: fix prefetch-vs-suspend race (git-fixes).
- commit 89effad

- dm-verity: fix prefetch-vs-suspend race (git-fixes).
- commit 6899d31

- dm-integrity: set ti-&amp;gt;error on memory allocation failure
  (git-fixes).
- commit 3c1b2c7

- netfilter: nf_tables: don't unregister hook when table is
  dormant (CVE-2025-22064 bsc#1241413).
- commit 3c82332

- net: ipv6: fix UDPv6 GSO segmentation with NAT (git-fixes).
- commit a110462

- net_sched: qfq: Fix double list add in class with netem as
  child qdisc (git-fixes).
- commit 8e1bbd0

- net_sched: ets: Fix double list add in class with netem as
  child qdisc (git-fixes).
- commit 2e9fa99

- net_sched: hfsc: Fix a UAF vulnerability in class with netem
  as child qdisc (git-fixes).
- commit 3f5a489

- net_sched: drr: Fix double list add in class with netem as
  child qdisc (git-fixes).
- commit 4947830

- ax25: Fix refcount leak caused by setting SO_BINDTODEVICE
  sockopt (CVE-2025-21792 bsc#1238745).
- commit 2ffce83

- ipv6: mcast: add RCU protection to mld_newpack() (CVE-2025-21758
  bsc#1238737).
- commit 4b8b3e5

- Bluetooth: btusb: avoid NULL pointer dereference in
  skb_dequeue() (git-fixes).
- wifi: brcm80211: fmac: Add error handling for
  brcmf_usb_dl_writeimage() (git-fixes).
- wifi: plfxlc: Remove erroneous assert in plfxlc_mac_release
  (git-fixes).
- commit 470cfc0

- net: ipv6: fix dst ref loops in rpl, seg6 and ioam6 lwtunnels
  (CVE-2025-21768 bsc#1238714).
- commit ed713b9

- kABI workaround struct rcu_head and ax25_ptr (CVE-2025-21812
  bsc#1238471).
- commit 714a2d7

- btrfs: fix block group refcount race in
  btrfs_create_pending_block_groups() (bsc#1241578
  CVE-2025-22115).
- commit 1f7a10d

- Refresh
  patches.kabi/kabi-fix-for-bpf-Prevent-tailcall-infinite-loop-caus.patch.
  Piggyback kABI workaround for &amp;quot;struct bpf_subprog_info&amp;quot; for upstream
  commit 51081a3f25c7 &amp;quot;bpf: track changes_pkt_data property for global
  functions&amp;quot;.
- commit bf7c4bc

- Add missing bugzilla references (CVE-2025-22105 bsc#1241548 CVE-2025-37860 bsc#1241452)
- commit 00ec2e2

- atm: Fix NULL pointer dereference (CVE-2025-22018 bsc#1241266)
- commit 8ef48c7

- bpf: bpf_local_storage: Always use bpf_mem_alloc in PREEMPT_RT (CVE-2024-58070 bsc#1238983)
- commit 335e132

- iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE (CVE-2025-21833, bsc#1239108).
- commit 069abee

- sfc: fix NULL dereferences in ef100_process_design_param()
  (CVE-2025-37860).
- net: mvpp2: Prevent parser TCAM memory corruption
  (CVE-2025-22060 bsc#1241526).
- bonding: check xdp prog when set bond mode (CVE-2025-22105).
- bonding: return detailed error when loading native XDP fails
  (CVE-2025-22105).
- commit 1110c2d

- ALSA: ump: Fix buffer overflow at UMP SysEx message conversion
  (bsc#1242044).
- commit 43160c9

- Correct the upsteram version numbers in the previous patches
- commit 6f72baf

- mmc: renesas_sdhi: Fix error handling in renesas_sdhi_probe
  (git-fixes).
- platform/x86/intel-uncore-freq: Fix missing uncore sysfs during
  CPU hotplug (git-fixes).
- commit f912ebf

- Require zstd in kernel-default-devel when module compression is zstd
  To use ksym-provides tool modules need to be uncompressed.
  Without zstd at least kernel-default-base does not have provides.
  Link: https://github.com/openSUSE/rpm-config-SUSE/pull/82
- commit a3262dd

- net: ibmveth: make veth_pool_store stop hanging (CVE-2025-22053
  bsc#1241373).
- commit 509c07e

- powerpc/boot: Fix dash warning (bsc#1215199).
- commit aeb4455

- exec: fix the racy usage of fs_struct-&amp;gt;in_exec (CVE-2025-22029
  bsc#1241378).
- commit f780e88

- x86/mm: Fix flush_tlb_range() when used for zapping normal PMDs
  (CVE-2025-22045 bsc#1241433).
- commit 1e24dab

- powerpc/boot: Check for ld-option support (bsc#1215199).
- commit 333e1e5

- selftests/bpf: extend changes_pkt_data with cases w/o
  subprograms (bsc#1241590).
- bpf: fix null dereference when computing changes_pkt_data of
  prog w/o subprogs (bsc#1241590).
- selftests/bpf: validate that tail call invalidates packet
  pointers (bsc#1241590).
- bpf: consider that tail calls invalidate packet pointers
  (bsc#1241590).
- selftests/bpf: freplace tests for tracking of
  changes_packet_data (bsc#1241590).
- bpf: check changes_pkt_data property for extension programs
  (bsc#1241590).
- Refresh patches.kabi/kabi-fix-for-bpf-Prevent-tailcall-infinite-loop-caus.patch
- selftests/bpf: test for changing packet data from global
  functions (bsc#1241590).
- bpf: track changes_pkt_data property for global functions
  (bsc#1241590).
- bpf: refactor bpf_helper_changes_pkt_data to use helper number
  (bsc#1241590).
- bpf: add find_containing_subprog() utility function
  (bsc#1241590).
- commit e531d2b

- Update
  patches.suse/memstick-rtsx_usb_ms-Fix-slab-use-after-free-in-rtsx.patch
  (bsc#1241280 CVE-2025-22020).
  Added CVE reference
- commit 80d99d3

- Fixup breakage in ext2 introduced by backporting in:
  patches.suse/ext2-Avoid-reading-renamed-directory-if-parent-does-.patch.
- commit b7c808a

- cxgb4: fix memory leak in cxgb4_init_ethtool_filters() error
  path (git-fixes).
- eth: bnxt: fix missing ring index trim on error path
  (git-fixes).
- igc: add lock preventing multiple simultaneous PTM transactions
  (git-fixes).
- igc: cleanup PTP module if probe fails (git-fixes).
- igc: handle the IGC_PTP_ENABLED flag correctly (git-fixes).
- igc: move ktime snapshot into PTM retry loop (git-fixes).
- igc: increase wait time before retrying PTM (git-fixes).
- igc: fix PTM cycle trigger logic (git-fixes).
- idpf: fix adapter NULL pointer dereference on reboot
  (git-fixes).
- e1000e: change k1 configuration on MTP and later platforms
  (git-fixes).
- gve: handle overflow when reporting TX consumed descriptors
  (git-fixes).
- net/mlx5e: SHAMPO, Make reserved size independent of page size
  (git-fixes).
- vdpa/mlx5: Fix oversized null mkey longer than 32bit
  (git-fixes).
- idpf: check error for register_netdev() on init (git-fixes).
- ice: stop truncating queue ids when checking (git-fixes).
- virtchnl: make proto and filter action count unsigned
  (git-fixes).
- ice: fix reservation of resources for RDMA when disabled
  (git-fixes).
- net/mlx5: Start health poll after enable hca (git-fixes).
- bnxt_en: Linearize TX SKB if the fragments exceed the max
  (git-fixes).
- bnxt_en: Mask the bd_cnt field in the TX BD properly
  (git-fixes).
- net/mlx5e: Fix ethtool -N flow-type ip4 to RSS context
  (git-fixes).
- igb: reject invalid external timestamp requests for 82580-based
  HW (git-fixes).
- net/mlx5e: Prevent bridge link show failure for
  non-eswitch-allowed devices (git-fixes).
- net/mlx5: Lag, Check shared fdb before creating MultiPort
  E-Switch (git-fixes).
- net/mlx5: Fill out devlink dev info only for PFs (git-fixes).
- net/mlx5: IRQ, Fix null string in debug print (git-fixes).
- gve: set xdp redirect target only when it is available
  (git-fixes).
- ice: Add check for devm_kzalloc() (git-fixes).
- commit 8b3f5c6

- ext4: fix OOB read when checking dotdot dir (bsc#1241640
  CVE-2025-37785).
- ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all()
  (bsc#1241593 CVE-2025-22121).
- proc: fix UAF in proc_get_inode() (bsc#1240802 CVE-2025-21999).
- fs: relax assertions on failure to encode file handles
  (bsc#1236086 CVE-2024-57924).
- commit 0e972d0

- net: gso: fix ownership in __udp_gso_segment (CVE-2025-21926
  bsc#1240712).
- commit a0db76b

- jfs: add sanity check for agwidth in dbMount (git-fixes).
- commit 8faa28a

- jfs: Prevent copying of nlink with value 0 from disk inode
  (git-fixes).
- commit eea1d40

- fs/jfs: Prevent integer overflow in AG size calculation
  (git-fixes).
- commit fce66a4

- fs/jfs: cast inactags to s64 to prevent potential overflow
  (git-fixes).
- commit 8b1cc16

- jfs: Fix uninit-value access of imap allocated in the diMount()
  function (git-fixes).
- commit 5b527ae

- irqchip/gic-v2m: Prevent use after free of gicv2m_get_fwnode()
  (git-fixes).
- drm/amd/display: Fix gpu reset in multidisplay config
  (git-fixes).
- Revert &amp;quot;drm/meson: vclk: fix calculation of 59.94 fractional
  rates&amp;quot; (git-fixes).
- commit 9f8b470

- block: integrity: Do not call set_page_dirty_lock() (git-fixes).
- loop: stop using vfs_iter_{read,write} for buffered I/O
  (git-fixes).
- loop: LOOP_SET_FD: send uevents for partitions (git-fixes).
- loop: properly send KOBJ_CHANGED uevent for disk device
  (git-fixes).
- block: fix resource leak in blk_register_queue() error path
  (git-fixes).
- block: make sure -&amp;gt;nr_integrity_segments is cloned in
  blk_rq_prep_clone (git-fixes).
- badblocks: fix missing bad blocks on retry in _badblocks_check()
  (git-fixes).
- badblocks: fix merge issue when new badblocks align with pre+1
  (git-fixes).
- badblocks: fix the using of MAX_BADBLOCKS (git-fixes).
- badblocks: return error if any badblock set fails (git-fixes).
- badblocks: return error directly when setting badblocks exceeds
  512 (git-fixes).
- badblocks: Fix error shitf ops (git-fixes).
- blk-throttle: fix lower bps rate by throtl_trim_slice()
  (git-fixes).
- block: change blk_mq_add_to_batch() third argument type to bool
  (git-fixes).
- block: fix conversion of GPT partition name to 7-bit
  (git-fixes).
- ublk: set_params: properly check if parameters can be applied
  (git-fixes).
- block: fix 'kmem_cache of name 'bio-108' already exists'
  (git-fixes).
- commit 607aa83

- drm/tests: Build KMS helpers when DRM_KUNIT_TEST_HELPERS is
  enabled (git-fixes).
- commit 03063eb

- USB: wdm: add annotation (git-fixes).
- USB: wdm: wdm_wwan_port_tx_complete mutex in atomic context
  (git-fixes).
- USB: wdm: close race between wdm_open and wdm_wwan_port_stop
  (git-fixes).
- USB: wdm: handle IO errors in wdm_wwan_port_start (git-fixes).
- usb: dwc3: gadget: check that event count does not exceed
  event buffer length (git-fixes).
- usb: dwc3: xilinx: Prevent spike in reset signal (git-fixes).
- usb: cdns3: Fix deadlock when using NCM gadget (git-fixes).
- usb: chipidea: ci_hdrc_imx: implement usb_phy_init() error
  handling (git-fixes).
- usb: chipidea: ci_hdrc_imx: fix call balance of regulator
  routines (git-fixes).
- serial: sifive: lock port in startup()/shutdown() callbacks
  (git-fixes).
- serial: msm: Configure correct working mode before starting
  earlycon (git-fixes).
- misc: microchip: pci1xxxx: Fix incorrect IRQ status handling
  during ack (git-fixes).
- misc: microchip: pci1xxxx: Fix Kernel panic during IRQ handler
  registration (git-fixes).
- string: Add load_unaligned_zeropad() code path to
  sized_strscpy() (git-fixes).
- kunit: qemu_configs: SH: Respect kunit cmdline (git-fixes).
- Revert &amp;quot;wifi: mac80211: Update skb's control block key in
  ieee80211_tx_dequeue()&amp;quot; (git-fixes).
- wifi: mac80211: Update skb's control block key in
  ieee80211_tx_dequeue() (git-fixes).
- selftests/mm: generate a temporary mountpoint for cgroup
  filesystem (git-fixes).
- selftests/futex: futex_waitv wouldblock test should fail
  (git-fixes).
- phy: freescale: imx8m-pcie: assert phy reset and perst in
  power off (git-fixes).
- PCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t type
  (stable-fixes).
- ktest: Fix Test Failures Due to Missing LOG_FILE Directories
  (stable-fixes).
- wifi: mt76: mt76x2u: add TP-Link TL-WDN6200 ID to device table
  (stable-fixes).
- wifi: ath12k: Fix invalid data access in
  ath12k_dp_rx_h_undecap_nwifi (stable-fixes).
- wifi: ath12k: Fix invalid entry fetch in
  ath12k_dp_mon_srng_process (stable-fixes).
- net: usb: asix_devices: add FiberGecko DeviceID (stable-fixes).
- media: uvcvideo: Add quirk for Actions UVC05 (stable-fixes).
- mmc: dw_mmc: add a quirk for accessing 64-bit FIFOs in two
  halves (stable-fixes).
- pm: cpupower: bench: Prevent NULL dereference on malloc failure
  (stable-fixes).
- commit b154b2c

- drm/tests: probe-helper: Fix drm_display_mode memory leak
  (git-fixes).
- drm/tests: modes: Fix drm_display_mode memory leak (git-fixes).
- drm/tests: cmdline: Fix drm_display_mode memory leak
  (git-fixes).
- drm/tests: helpers: Create kunit helper to destroy a
  drm_display_mode (stable-fixes).
- drm/i915/gvt: fix unterminated-string-initialization warning
  (stable-fixes).
- drm/i915: Disable RPG during live selftest (git-fixes).
- gpio: zynq: Fix wakeup source leaks on device unbind
  (stable-fixes).
- drm/amd: Handle being compiled without SI or CIK support better
  (stable-fixes).
- drm/mediatek: mtk_dpi: Explicitly manage TVD clock in power
  on/off (stable-fixes).
- drm/mediatek: mtk_dpi: Move the input_2p_en bit to platform data
  (stable-fixes).
- drm/amdgpu: handle amdgpu_cgs_create_device() errors in
  amd_powerplay_create() (stable-fixes).
- drm/amdkfd: debugfs hang_hws skip GPU with MES (stable-fixes).
- drm/amdkfd: Fix pqm_destroy_queue race with GPU reset
  (stable-fixes).
- drm/amdkfd: Fix mode1 reset crash issue (stable-fixes).
- drm/amdkfd: clamp queue size to minimum (stable-fixes).
- drm/amd/display: add workaround flag to link to force FFE preset
  (stable-fixes).
- drm/bridge: panel: forbid initializing a panel with unknown
  connector type (stable-fixes).
- drm: panel-orientation-quirks: Add quirk for OneXPlayer Mini
  (Intel) (stable-fixes).
- drm: panel-orientation-quirks: Add new quirk for GPD Win 2
  (stable-fixes).
- drm: panel-orientation-quirks: Add quirk for AYA NEO Slide
  (stable-fixes).
- drm: panel-orientation-quirks: Add quirks for AYA NEO Flip DS
  and KB (stable-fixes).
- drm: panel-orientation-quirks: Add support for AYANEO 2S
  (stable-fixes).
- drm: allow encoder mode_set even when connectors change for crtc
  (stable-fixes).
- fbdev: omapfb: Add 'plane' value check (stable-fixes).
- drm/tests: helpers: Fix compiler warning (git-fixes).
- drm/tests: helpers: Add helper for
  drm_display_mode_from_cea_vic() (stable-fixes).
- drm/i915/dg2: wait for HuC load completion before running
  selftests (stable-fixes).
- drm/tests: Add helper to create mock crtc (stable-fixes).
- commit a0a41da

- char: misc: register chrdev region with all possible minors
  (git-fixes).
- Revert &amp;quot;drivers: core: synchronize really_probe() and
  dev_uevent()&amp;quot; (stable-fixes).
- Bluetooth: l2cap: Process valid commands in too long frame
  (stable-fixes).
- drivers: base: devres: Allow to release group on device release
  (stable-fixes).
- Bluetooth: hci_uart: Fix another race during initialization
  (git-fixes).
- Bluetooth: hci_uart: fix race during initialization
  (stable-fixes).
- cdc_ether|r8152: ThinkPad Hybrid USB-C/A Dock quirk
  (stable-fixes).
- ahci: add PCI ID for Marvell 88SE9215 SATA Controller
  (stable-fixes).
- ASoC: amd: yc: update quirk data for new Lenovo model
  (stable-fixes).
- ASoC: fsl_audmix: register card device depends on 'dais'
  property (stable-fixes).
- ASoC: SOF: topology: Use krealloc_array() to replace krealloc()
  (stable-fixes).
- ASoC: amd: Add DMI quirk for ACP6X mic support (stable-fixes).
- ALSA: usb-audio: Fix CME quirk for UF series keyboards
  (stable-fixes).
- ALSA: hda: intel: Add Lenovo IdeaPad Z570 to probe denylist
  (stable-fixes).
- ALSA: hda: intel: Fix Optimus when GPU has no sound
  (stable-fixes).
- drm/tests: Add helper to create mock plane (stable-fixes).
- drm/tests: helpers: Add atomic helpers (stable-fixes).
- drm/i915/xelpg: Extend driver code of Xe_LPG to Xe_LPG+
  (stable-fixes).
- commit 58c19a1

- Update
  patches.suse/vmxnet3-unregister-xdp-rxq-info-in-the-reset-path.patch
  (bsc#1241394 CVE-2025-22106 bsc#1241547).
- commit a998629

- mm: (un)track_pfn_copy() fix + doc improvements (CVE-2025-22090
  bsc#1241537).
- commit 1ccdfdd

- x86/mm/pat: Fix VM_PAT handling when fork() fails in
  copy_page_range() (CVE-2025-22090 bsc#1241537).
- commit f0ac623

- exfat: fix random stack corruption after get_block (bsc#1241426
  CVE-2025-22036).
- commit 1f685c3

- exfat: do not fallback to buffered write (git-fixes).
- commit f7d2bc8

- exfat: drop -&amp;gt;i_size_ondisk (git-fixes).
- commit 9420be9

- fs/ntfs3: Prevent integer overflow in hdr_first_de()
  (bsc#1241416 CVE-2025-22080).
- commit 401237e

- clk: samsung: Fix UBSAN panic in samsung_clk_init()
  (CVE-2025-39728 bsc#1241626).
- commit 146debe

- net: phy: leds: fix memory leak (git-fixes).
- net: phy: microchip: force IRQ polling mode for lan88xx
  (git-fixes).
- crypto: atmel-sha204a - Set hwrng quality to lowest possible
  (git-fixes).
- commit 007e98d

- net: ethtool: Don't call .cleanup_data when prepare_data fails
  (git-fixes).
- ethtool: Fix set RXNFC command with symmetric RSS hash
  (git-fixes).
- ethtool: Fix wrong mod state in case of verbose and no_mask
  bitset (git-fixes).
- ethtool: Fix context creation with no parameters (git-fixes).
- ethtool: fix setting key and resetting indir at once
  (git-fixes).
- ethtool: rss: echo the context number back (git-fixes).
- net: ethtool: Fix RSS setting (git-fixes).
- ethtool: netlink: do not return SQI value if link is down
  (git-fixes).
- ethtool: netlink: Add missing ethnl_ops_begin/complete
  (git-fixes).
- ethtool: don't propagate EOPNOTSUPP from dumps (git-fixes).
- ethtool: plca: fix plca enable data type while parsing the value
  (git-fixes).
- commit 6a09a48

- OPP: add index check to assert to avoid buffer overflow in _read_freq() (bsc#1238961)
- commit 2e43a01

- Test the correct macro to detect RT kernel build
  Fixes: 470cd1a41502 (&amp;quot;kernel-binary: Support livepatch_rt with merged RT branch&amp;quot;)
- commit 50e863e

- mm: clear uffd-wp PTE/PMD state on mremap() (bsc#1237111
  CVE-2025-21696).
  Refreshed:
  patches.suse/mm-hugetlb-Add-huge-page-size-param-to-huge_ptep_get_and_clear.patch
- commit e18d57e

- bpf: Make sure internal and UAPI bpf_redirect flags don't
  overlap (bsc#1233098 CVE-2024-50163).
- commit f73adfb

- bpf: selftests: send packet to devmap redirect XDP (bsc#1233075
  CVE-2024-50162).
- bpf: devmap: provide rxq after redirect (bsc#1233075
  CVE-2024-50162).
- commit efb272f

- mm: clear uffd-wp PTE/PMD state on mremap() (bsc#1237111
  CVE-2025-21696).
  Refreshed:
  patches.suse/mm-hugetlb-Add-huge-page-size-param-to-huge_ptep_get_and_clear.patch
- commit 559ab65

- mm/migrate: fix shmem xarray update during migration
  (CVE-2025-22015 bsc#1240944).
- commit 18f748b

- fou: fix initialization of grc (CVE-2024-46763 bsc#1230764).
- commit c144530

- kernel-source: Also update the search to match bin/env
  Fixes: dc2037cd8f94 (&amp;quot;kernel-source: Also replace bin/env&amp;quot;
- commit bae6b69

- rpm/check-for-config-changes: Add GCC_ASM_FLAG_OUTPUT_BROKEN
- commit 816118c

- fou: Fix null-ptr-deref in GRO (CVE-2024-46763 bsc#1230764).
- commit 759f2a9

- hwpoison, memory_hotplug: lock folio before unmap hwpoisoned
  folio (CVE-2025-21931 bsc#1240709).
- commit 1ece281

- net: fix geneve_opt length integer overflow (CVE-2025-22055
  bsc#1241371).
- commit 45017c8

- PCI/MSI: Add an option to write MSIX ENTRY_DATA before any reads
  (git-fixes).
- irqchip/davinci: Remove leftover header (git-fixes).
- tty: n_tty: use uint for space returned by tty_write_room()
  (git-fixes).
- commit 2e047cb

- kABI fix for sctp: detect and prevent references to a freed
  transport in sendmsg (git-fixes).
- commit ce43999

- wifi: ath11k: update channel list in reg notifier instead reg
  worker (CVE-2025-23133 bsc#1241451).
- commit dfc599a

- exfat: short-circuit zero-byte writes in exfat_file_write_iter
  (git-fixes).
- commit c31ee51

- exfat: fix soft lockup in exfat_clear_bitmap (git-fixes).
- commit 527ed08

- nfsd: decrease sc_count directly if fail to queue dl_recall
  (git-fixes).
- commit 91b68ee

- nfs: add missing selections of CONFIG_CRC32 (git-fixes).
- commit f409d6e

- nvmet-fcloop: swap list_add_tail arguments (git-fixes).
- nvme-pci: skip nvme_write_sq_db on empty rqlist (git-fixes).
- nvme/ioctl: don't warn on vectorized uring_cmd with fixed buffer
  (git-fixes).
- nvme-pci: fix stuck reset on concurrent DPC and HP (git-fixes).
- nvme-pci: skip CMB blocks incompatible with PCI P2P DMA
  (git-fixes).
- nvme-pci: clean up CMBMSC when registering CMB fails
  (git-fixes).
- nvme-tcp: fix possible UAF in nvme_tcp_poll (git-fixes).
- commit bf9d0e5

- Move upstreamed smb patch into sorted section
  Also move other out-of-tree patches into the proper section
- commit ba77adc

- rpm/kernel-binary.spec.in: revert the revert change with OrderWithRequires
  The recent change using OrderWithRequires addresses the known issues,
  but also caused regressions for the existing image or package builds.
  For SLE15-SPx, better to be conservative and stick with the older way.
- commit bbe05e4

- Refresh
  patches.suse/kernel-add-product-identifying-information-to-kernel-build.patch.
  scripts/gen-suse_version_h.sh requires bash, yet in Makefile
  CONFIG_SHELL is defined to 'sh'. In openSUSE and SUSE products 'sh' is a
  symbolic link to 'bash', hence this isn't a problem. However
  distributions like Debian and Ubuntu 'sh' is symbolically linked to
  'dash' instead, and gen-suse_version_h.sh will fail to run with
  ./scripts/gen-suse_version_h.sh: 3: Syntax error: &amp;quot;(&amp;quot; unexpected
  make[1]: *** [/home/runner/work/libbpf/libbpf/.kernel/Makefile:1135: include/generated/uapi/linux/suse_version.h] Error 2
  make: *** [Makefile:224: __sub-make] Error 2
  Explicitly use bash to run scripts/gen-suse_version_h.sh to make sure
  it will always work.
- commit 2be3c0f

- scsi: iscsi: Fix missing scsi_host_put() in error path
  (git-fixes).
- scsi: hisi_sas: Enable force phy when SATA disk directly
  connected (git-fixes).
- scsi: lpfc: Restore clearing of NLP_UNREG_INP in ndlp-&amp;gt;nlp_flag
  (git-fixes).
- scsi: scsi_debug: Remove a reference to in_use_bm (git-fixes).
- scsi: mpt3sas: Fix a locking bug in an error path (git-fixes).
- scsi: mpi3mr: Fix locking in an error path (git-fixes).
- scsi: mpt3sas: Reduce log level of ignore_delay_remove message
  to KERN_INFO (git-fixes).
- scsi: core: Use GFP_NOIO to avoid circular locking dependency
  (git-fixes).
- commit c9f2a96

- net: annotate data-races around sk-&amp;gt;sk_tx_queue_mapping
  (git-fixes).
- commit 39ebbf2

- sctp: detect and prevent references to a freed transport in
  sendmsg (git-fixes).
- commit 1334236

- sctp: add mutual exclusion in proc_sctp_do_udp_port()
  (git-fixes).
- commit 711cff2

- sctp: Fix undefined behavior in left shift operation
  (git-fixes).
- commit a1edf61

- netpoll: Use rcu_access_pointer() in netpoll_poll_lock
  (git-fixes).
- commit 4965a27

- tcp: fix mptcp DSS corruption due to large pmtu xmit
  (git-fixes).
- commit ba5be47

- sctp: ensure sk_state is set to CLOSED if hashing fails in
  sctp_listen_start (git-fixes).
- commit a7b311d

- sctp: fix association labeling in the duplicate COOKIE-ECHO case
  (git-fixes).
- commit f2ab0aa

- sctp: prefer struct_size over open coded arithmetic (git-fixes).
- commit e26aab9

- net: blackhole_dev: fix build warning for ethh set but not used
  (git-fixes).
- commit 9f9bf2f

- net: sctp: fix skb leak in sctp_inq_free() (git-fixes).
- commit ef140e3

- sctp: fix busy polling (git-fixes).
- commit 533e122

- sctp: support MSG_ERRQUEUE flag in recvmsg() (git-fixes).
- commit 1e9a8f7

- i2c: cros-ec-tunnel: defer probe if parent EC is not present
  (git-fixes).
- commit 68f8146

- vmxnet3: unregister xdp rxq info in the reset path
  (bsc#1241394).
- vmxnet3: Fix tx queue race condition with XDP (bsc#1241394).
- commit d09ed0e

- ALSA: hda/realtek - Fixed ASUS platform headset Mic issue
  (git-fixes).
- commit 53f07fb

- Refresh patches.suse/ALSA-hda-realtek-Workaround-for-resume-on-Dell-Venue.patch
  The patch was applied incorrectly to a wrong device
- commit cf41ba6

- Bluetooth: vhci: Avoid needless snprintf() calls (git-fixes).
- wifi: wl1251: fix memory leak in wl1251_tx_work (git-fixes).
- wifi: mac80211: Purge vif txq in ieee80211_do_stop()
  (git-fixes).
- wifi: at76c50x: fix use after free access in at76_disconnect
  (git-fixes).
- Bluetooth: l2cap: Check encryption key size on incoming
  connection (git-fixes).
- Bluetooth: btrtl: Prevent potential NULL dereference
  (git-fixes).
- Bluetooth: hci_event: Fix sending MGMT_EV_DEVICE_FOUND for
  invalid address (git-fixes).
- ASoC: codecs:lpass-wsa-macro: Fix logic of enabling vi channels
  (git-fixes).
- ASoC: codecs:lpass-wsa-macro: Fix vi feedback rate (git-fixes).
- ASoC: Intel: avs: Fix null-ptr-deref in avs_component_probe()
  (git-fixes).
- ASoC: qcom: Fix sc7280 lpass potential buffer overflow
  (git-fixes).
- asus-laptop: Fix an uninitialized variable (git-fixes).
- ata: libata-sata: Save all fields from sense data descriptor
  (git-fixes).
- commit b064ee6

- smb: client: fix folio leaks and perf improvements (bsc#1239997,
  bsc1241265).
- commit 3640faf

- net: mark racy access on sk-&amp;gt;sk_rcvbuf (git-fixes).
- commit c7df85a

- net: set SOCK_RCU_FREE before inserting socket into hashtable
  (git-fixes).
- commit 469342f

- net: annotate data-races around sk-&amp;gt;sk_dst_pending_confirm
  (git-fixes).
- commit ddac370

- Refresh patches.suse/x86-paravirt-Move-halt-paravirt-calls-under-CONFIG_PARAVIR.patch.
  This fixes a build error
- commit 885e121

- ipv4: fib: annotate races around nh-&amp;gt;nh_saddr_genid and
  nh-&amp;gt;nh_saddr (git-fixes).
- commit 42e44b7

- rpm/kernel-binary.spec.in: Also order against update-bootloader
  (boo#1228659, boo#1240785, boo#1241038).
- commit fe0a8c9

- crypto: caam/qi - Fix drv_ctx refcount bug (git-fixes).
- commit 004010d

- selftests/bpf: Add a few tests to cover (git-fixes).
- bpf: Add missed var_off setting in coerce_subreg_to_size_sx()
  (git-fixes).
- bpf: Add missed var_off setting in set_sext32_default_val()
  (git-fixes).
- commit 07fae33

- Drop PCI patch that caused a regression (bsc#1241123)
  The patch patches.suse/PCI-Avoid-reset-when-disabled-via-sysfs.patch
  seems causing a regression about missing device passthrough on VM.
  Drop it to address the regression.
- commit 5845d87

- bpf, test_run: Fix use-after-free issue in eth_skb_pkt_type()
  (bsc#1240181 CVE-2025-21867).
- commit 82a6d4f

- Revert commit (bsc#1241051)
  Delete
  patches.suse/mm-various-give-up-if-pte_offset_map-_lock-fails.patch.
- commit c63b737

- rpm/package-descriptions: Add rt and rt_debug descriptions
- commit 09573c0

- fs/ntfs3: add prefix to bitmap_size() and use BITS_TO_U64()
  (bsc#1241250).
- commit a11e79b

- x86/microcode/AMD: Split load_microcode_amd() (git-fixes).
- Refresh
  patches.suse/x86-microcode-AMD-Fix-out-of-bounds-on-systems-with-.patch.
- commit e4a11da

- x86/microcode/AMD: Pay attention to the stepping dynamically (git-fixes).
- commit 581b74c

- x86/microcode/intel: Set new revision only after a successful update (git-fixes).
- commit 7ef0614

- x86/microcode/AMD: Fix a -Wsometimes-uninitialized clang false positive (git-fixes).
- commit 0584d8b

- btrfs: fix hole expansion when writing at an offset beyond EOF
  (bsc#1241151).
- btrfs: fix swap file activation failure due to extents that
  used to be shared (bsc#1241204).
- btrfs: fix race with memory mapped writes when activating swap
  file (bsc#1241204).
- btrfs: fix missing snapshot drew unlock when root is dead
  during swap activation (bsc#1241204).
- btrfs: add and use helper to verify the calling task has locked
  the inode (bsc#1241204).
- commit d9b6443

- sched: address a potential NULL pointer dereference in the
  GRED scheduler (CVE-2025-21980 bsc#1240809).
- commit ce44194

- net: atm: fix use after free in lec_send() (CVE-2025-22004
  bsc#1240835).
- commit 0623761

- llc: do not use skb_get() before dev_queue_xmit()
  (CVE-2025-21925 bsc#1240713).
- commit 79eced9

- tools/power turbostat: report CoreThr per measurement interval
  (git-fixes).
- commit d3776d1

- x86/microcode/AMD: Use the family,model,stepping encoded in the patch  ID (git-fixes).
- Refresh
  patches.suse/x86-microcode-AMD-Flush-patch-buffer-mapping-after-applica.patch.
- commit 88521da

- x86/microcode: Rework early revisions reporting (git-fixes).
- Refresh
  patches.suse/x86-microcode-AMD-Flush-patch-buffer-mapping-after-applica.patch.
- commit 4d17d9e

- ax25: rcu protect dev-&amp;gt;ax25_ptr (CVE-2025-21812 bsc#1238471).
- commit 5fd1fff

- x86/microcode: Remove the driver announcement and version (git-fixes).
- commit 46995b1

- x86/tdx: Emit warning if IRQs are enabled during HLT #VE handling (git-fixes).
- commit d56cfaf

- x86/tdx: Fix arch_safe_halt() execution for TDX VMs (git-fixes).
- commit d95d976

- Refresh
  patches.suse/ipv6-remove-hard-coded-limitation-on-ipv6_pinfo.patch.
- commit 0200f55

- hfs/hfsplus: fix slab-out-of-bounds in hfs_bnode_read_key
  (git-fixes).
- commit 6eab8d6

- x86/paravirt: Move halt paravirt calls under CONFIG_PARAVIRT (git-fixes).
- commit df4a06f

- x86/microcode/AMD: Flush patch buffer mapping after application (git-fixes).
- commit 3abf82a

- x86/dumpstack: Fix inaccurate unwinding from exception stacks due to  misplaced assignment (git-fixes).
- commit 9a5f9b4

- x86/entry: Fix ORC unwinder for PUSH_REGS with save_ret=1 (git-fixes).
- commit a987e8f

- x86/uaccess: Improve performance by aligning writes to 8 bytes in  copy_user_generic(), on non-FSRM/ERMS CPUs (git-fixes).
- commit b668be3

- x86/bugs: Add RSB mitigation document (git-fixes).
- commit b8dad0f

- x86/bugs: Don't fill RSB on context switch with eIBRS (git-fixes).
- commit 187dbce

- x86/bugs: Don't fill RSB on VMEXIT with eIBRS+retpoline (git-fixes).
- commit 4f16d88

- x86/bugs: Fix RSB clearing in indirect_branch_prediction_barrier() (git-fixes).
- commit fb3ed54

- x86/bugs: Use SBPB in write_ibpb() if applicable (git-fixes).
- commit 4702713

- x86/bugs: Rename entry_ibpb() to write_ibpb() (git-fixes).
- commit 05f7f50

- selftest/bpf: Add vsock test for sockmap rejecting unconnected
  (bsc#1239470 CVE-2025-21854).
- selftest/bpf: Adapt vsock_delete_on_close to sockmap rejecting
  unconnected (bsc#1239470 CVE-2025-21854).
- vsock/bpf: Warn on socket without transport (bsc#1239470
  CVE-2025-21854).
- commit 9aa107b

- tools/power turbostat: Increase CPU_SUBSET_MAXCPUS to 8192
  (bsc#1241175).
- commit b06e876

- sockmap, vsock: For connectible sockets allow only connected
  (bsc#1239470 CVE-2025-21854).
- bpf: sockmap, test for unconnected af_unix sock (bsc#1239470
  CVE-2025-21854).
- Refresh patches.suse/selftest-bpf-Add-test-for-af_vsock-poll.patch
- bpf: syzkaller found null ptr deref in unix_bpf proto add
  (bsc#1239470 CVE-2025-21854).
- Refresh patches.suse/udp-fix-busy-polling.patch
- Refresh
  patches.suse/bpf-sockmap-SK_DROP-on-attempted-redirects-of-unsupported-.patch
- commit 62e8475

- bpf, vsock: Invoke proto::close on close() (bsc#1239470 CVE-2025-21854).
- Refresh
  patches.suse/vsock-Keep-the-binding-until-socket-destruction.patch.
- Refresh patches.suse/vsock-Orphan-socket-after-transport-release.patch
- commit a88600e

- selftest/bpf: Add test for vsock removal from sockmap on close()
  (bsc#1239470 CVE-2025-21854).
- selftest/bpf: Add test for af_vsock poll() (bsc#1239470
  CVE-2025-21854).
- bpf, vsock: Fix poll() missing a queue (bsc#1239470
  CVE-2025-21854).
- commit 43f792d

- RDMA/core: Silence oversized kvmalloc() warning (git-fixes)
- commit 0801938

- RDMA/cma: Fix workqueue crash in cma_netevent_work_handler (git-fixes)
- commit 8be4a6f

- RDMA/hns: Fix wrong maximum DMA segment size (git-fixes)
- commit 9a0c549

- RDMA/usnic: Fix passing zero to PTR_ERR in usnic_ib_pci_probe() (git-fixes)
- commit 7bf895d

- net: xdp: Disallow attaching device-bound programs in generic
  mode (bsc#1238742 CVE-2025-21808).
- commit c2feb9e

- md/md-bitmap: fix wrong bitmap_limit for clustermd when write sb (bsc#1238212)
  Also reenable patches.suse/md-md-bitmap-fix-writing-non-bitmap-pages-ab99.patch
- commit 22ce219

- bpf: Fix deadlock when freeing cgroup storage (CVE-2024-58088 bsc#1239510)
- commit a5b985f

- dpll: fix xa_alloc_cyclic() error handling (CVE-2025-22016 bsc#1240934)
- commit 2521b46

- devlink: fix xa_alloc_cyclic() error handling (CVE-2025-22017 bsc#1240936)
- commit 6e391e8

- zap_pid_ns_processes: clear TIF_NOTIFY_SIGNAL along with
  TIF_SIGPENDING (bsc#1241167).
- commit 2fe69fb

- caif_virtio: fix wrong pointer check in cfv_probe()
  (CVE-2025-21904 bsc#1240576).
- commit 9a83e3e

- Refresh
  patches.kabi/kABI-fix-for-ipv6-remove-hard-coded-limitation-on-ip.patch.
- commit 81847b0

- xfs: flush inodegc before swapon (git-fixes).
- commit c599968

- net: mana: Switch to page pool for jumbo frames (git-fixes).
- RDMA/mana_ib: Ensure variable err is initialized (git-fixes).
- x86/hyperv: Fix check of return value from snp_set_vmsa()
  (git-fixes).
- commit 2b709c0

- pwm: fsl-ftm: Handle clk_get_rate() returning 0 (git-fixes).
- pwm: rcar: Improve register calculation (git-fixes).
- pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()
  (git-fixes).
- commit 9d83cd0

- ata: sata_sx4: Add error handling in pdc20621_i2c_read()
  (git-fixes).
- ata: pata_pxa: Fix potential NULL pointer dereference in
  pxa_ata_probe() (git-fixes).
- commit dcc1d06

- kABI workaround for powercap update (bsc#1241010).
- commit 6da4ad4

- drm/amd/display: Fix out-of-bound accesses (bsc#1240811 CVE-2025-21985)
- commit f9ae89c

- Revert &amp;quot;tcp: Fix bind() regression for v6-only wildcard and&amp;quot;
  This reverts commit 10a8fd3005bd56ac305a4a4e9bf53cfc50aad28f.
  This patch is part of a bigger series [0] and AFAIU can't be applied
  individually. Applying the entire series would result in kABI breakage.
  [0]
  https://lore.kernel.org/all/20231213082029.35149-1-kuniyu@amazon.com/
- commit 9692530

- Update
  patches.suse/Bluetooth-Add-check-for-mgmt_alloc_skb-in-mgmt_devic.patch
  (git-fixes CVE-2025-21936 bsc#1240716).
- Update
  patches.suse/Bluetooth-Add-check-for-mgmt_alloc_skb-in-mgmt_remot.patch
  (git-fixes CVE-2025-21937 bsc#1240643).
- Update
  patches.suse/Bluetooth-Fix-error-code-in-chan_alloc_skb_cb.patch
  (git-fixes CVE-2025-22007 bsc#1240829).
- Update
  patches.suse/HID-appleir-Fix-potential-NULL-dereference-at-raw-ev.patch
  (git-fixes CVE-2025-21948 bsc#1240703).
- Update
  patches.suse/HID-hid-steam-Fix-use-after-free-when-detaching-devi.patch
  (git-fixes CVE-2025-21923 bsc#1240691).
- Update
  patches.suse/HID-ignore-non-functional-sensor-in-HP-5MP-Camera.patch
  (stable-fixes CVE-2025-21992 bsc#1240796).
- Update
  patches.suse/HID-intel-ish-hid-Fix-use-after-free-issue-in-ishtp_.patch
  (git-fixes CVE-2025-21928 bsc#1240722).
- Update
  patches.suse/KVM-arm64-Unconditionally-save-flush-host-FPSIMD-SVE-SME-state.patch
  (git-fixes CVE-2025-22013 bsc#1240938).
- Update
  patches.suse/RDMA-hns-Fix-soft-lockup-during-bt-pages-loop.patch
  (git-fixes CVE-2025-22010 bsc#1240943).
- Update
  patches.suse/accel-qaic-Fix-integer-overflow-in-qaic_validate_req.patch
  (git-fixes CVE-2025-22001 bsc#1240873).
- Update
  patches.suse/bus-mhi-host-pci_generic-Use-pci_try_reset_function-.patch
  (git-fixes CVE-2025-21951 bsc#1240718).
- Update
  patches.suse/can-ucan-fix-out-of-bound-read-in-strscpy-source.patch
  (git-fixes CVE-2025-22003 bsc#1240825).
- Update
  patches.suse/cdx-Fix-possible-UAF-error-in-driver_override_show.patch
  (git-fixes CVE-2025-21915 bsc#1240594).
- Update
  patches.suse/dm-flakey-Fix-memory-corruption-in-optional-corrupt_.patch
  (git-fixes CVE-2025-21966 bsc#1240779).
- Update
  patches.suse/drivers-virt-acrn-hsm-Use-kzalloc-to-avoid-info-leak.patch
  (git-fixes CVE-2025-21950 bsc#1240719).
- Update
  patches.suse/drm-amd-display-Assign-normalized_pix_clk-when-color.patch
  (stable-fixes CVE-2025-21956 bsc#1240739).
- Update
  patches.suse/drm-amd-display-Fix-null-check-for-pipe_ctx-plane_st-374c9fa.patch
  (git-fixes CVE-2025-21941 bsc#1240701).
- Update
  patches.suse/drm-amd-display-Fix-slab-use-after-free-on-hdcp_work.patch
  (git-fixes CVE-2025-21968 bsc#1240783).
- Update
  patches.suse/drm-hyperv-Fix-address-space-leak-when-Hyper-V-DRM-d.patch
  (git-fixes CVE-2025-21978 bsc#1240806).
- Update
  patches.suse/drm-radeon-fix-uninitialized-size-issue-in-radeon_vc.patch
  (git-fixes CVE-2025-21996 bsc#1240801).
- Update
  patches.suse/drm-sched-Fix-fence-reference-count-leak.patch
  (git-fixes CVE-2025-21995 bsc#1240821).
- Update
  patches.suse/gpio-aggregator-protect-driver-attr-handlers-against.patch
  (git-fixes CVE-2025-21943 bsc#1240647).
- Update
  patches.suse/gpio-rcar-Use-raw_spinlock-to-protect-register-acces.patch
  (stable-fixes CVE-2025-21912 bsc#1240584).
- Update
  patches.suse/msft-hv-3170-net-mana-cleanup-mana-struct-after-debugfs_remove.patch
  (git-fixes CVE-2025-21953 bsc#1240727).
- Update
  patches.suse/net_sched-Prevent-creation-of-classes-with-TC_H_ROOT.patch
  (git-fixes CVE-2025-21971 bsc#1240799).
- Update
  patches.suse/nvme-tcp-fix-potential-memory-corruption-in-nvme_tcp.patch
  (git-fixes CVE-2025-21927 bsc#1240714).
- Update
  patches.suse/rapidio-add-check-for-rio_add_net-in-rio_scan_alloc_.patch
  (git-fixes CVE-2025-21935 bsc#1240700).
- Update
  patches.suse/rapidio-fix-an-API-misues-when-rio_add_net-fails.patch
  (git-fixes CVE-2025-21934 bsc#1240708).
- Update
  patches.suse/regulator-check-that-dummy-regulator-has-been-probed.patch
  (stable-fixes CVE-2025-22008 bsc#1240942).
- Update
  patches.suse/regulator-dummy-force-synchronous-probing.patch
  (git-fixes CVE-2025-22009 bsc#1240940).
- Update
  patches.suse/slimbus-messaging-Free-transaction-ID-in-delayed-int.patch
  (git-fixes CVE-2025-21914 bsc#1240595).
- Update
  patches.suse/soc-qcom-pdr-Fix-the-potential-deadlock.patch
  (git-fixes CVE-2025-22014 bsc#1240937).
- Update
  patches.suse/usb-atm-cxacru-fix-a-flaw-in-existing-endpoint-check.patch
  (git-fixes CVE-2025-21916 bsc#1240582).
- Update
  patches.suse/usb-renesas_usbhs-Flush-the-notify_hotplug_work.patch
  (git-fixes CVE-2025-21917 bsc#1240596).
- Update patches.suse/usb-typec-ucsi-Fix-NULL-pointer-access.patch
  (git-fixes CVE-2025-21918 bsc#1240592).
- Update
  patches.suse/wifi-cfg80211-cancel-wiphy_work-before-freeing-wiphy.patch
  (git-fixes CVE-2025-21979 bsc#1240808).
- Update
  patches.suse/wifi-cfg80211-regulatory-improve-invalid-hints-check.patch
  (git-fixes CVE-2025-21910 bsc#1240583).
- Update
  patches.suse/wifi-iwlwifi-limit-printed-string-from-FW-file.patch
  (git-fixes CVE-2025-21905 bsc#1240575).
- Update
  patches.suse/wifi-iwlwifi-mvm-don-t-try-to-talk-to-a-dead-firmwar.patch
  (git-fixes CVE-2025-21930 bsc#1240715).
- Update
  patches.suse/wifi-nl80211-reject-cooked-mode-if-it-is-set-along-w.patch
  (git-fixes CVE-2025-21909 bsc#1240590).
- commit a467018

- affs: don't write overlarge OFS data block size fields
  (git-fixes).
- commit 334bc15

- affs: generate OFS sequence numbers starting at 1 (git-fixes).
- commit f93c833

- nfsd: put dl_stid if fail to queue dl_recall (git-fixes).
- commit 4b6b673

- security, lsm: Introduce security_mptcp_add_subflow()
  (bsc#1240375).
- Refresh
  patches.suse/net-better-track-kernel-sockets-lifetime.patch.
- commit bd8699b

- selinux: Implement mptcp_add_subflow hook (bsc#1240375).
- commit c784a67

- powercap: intel_rapl_tpmi: Enable PMU support (bsc#1241010).
- commit 2a705e9

- powercap: intel_rapl: Introduce APIs for PMU support
  (bsc#1241010).
- commit b0e2847

- drm/amd: Keep display off while going into S4 (stable-fixes).
- Refresh
  patches.suse/drm-amd-display-Restore-correct-backlight-brightness.patch.
- commit e9996bf

- drm/sti: remove duplicate object names (git-fixes).
- drm/nouveau: prime: fix ttm_bo_delayed_delete oops (git-fixes).
- drm/amd/pm/smu11: Prevent division by zero (git-fixes).
- drm/amdgpu/dma_buf: fix page_link check (git-fixes).
- drm/i915/huc: Fix fence not released on early probe errors
  (git-fixes).
- gpio: tegra186: fix resource handling in ACPI probe path
  (git-fixes).
- mtd: rawnand: Add status chack in r852_ready() (git-fixes).
- mtd: inftlcore: Add error check for inftl_read_oob()
  (git-fixes).
- ntb: use 64-bit arithmetic for the MSI doorbell mask
  (git-fixes).
- ntb_hw_switchtec: Fix shift-out-of-bounds in
  switchtec_ntb_mw_set_trans (git-fixes).
- ACPI: resource: Skip IRQ override on ASUS Vivobook 14 X1404VAP
  (stable-fixes).
- mmc: sdhci-pxav3: set NEED_RSP_BUSY capability (stable-fixes).
- hwmon: (nct6775-core) Fix out of bounds access for NCT679{8,9}
  (stable-fixes).
- wifi: mac80211: flush the station before moving it to
  UN-AUTHORIZED state (stable-fixes).
- platform/x86/intel/vsec: Add Diamond Rapids support
  (stable-fixes).
- platform/x86: intel-hid: fix volume buttons on Microsoft
  Surface Go 4 tablet (stable-fixes).
- wifi: brcmfmac: keep power during suspend if board requires it
  (stable-fixes).
- wifi: iwlwifi: mvm: use the right version of the rate API
  (stable-fixes).
- wifi: iwlwifi: fw: allocate chained SG tables for dump
  (stable-fixes).
- HID: i2c-hid: improve i2c_hid_get_report error message
  (stable-fixes).
- ntb: Force physically contiguous allocation of rx ring buffers
  (git-fixes).
- ntb_perf: Fix printk format (git-fixes).
- commit a733ec5

- netfilter: br_netfilter: skip conntrack input hook for promisc
  packets (CVE-2024-27415 bsc#1224757).
- commit 01cefc0

- kabi: restore layout of struct nf_ct_hook after backport of
  commit 62e7151ae3eb (CVE-2024-27415 bsc#1224757).
- netfilter: bridge: confirm multicast packets before passing
  them up the stack (CVE-2024-27415 bsc#1224757).
- commit 69425e5

- netfilter: xtables: fix typo causing some targets not to load
  on IPv6 (CVE-2024-50038 bsc#1231910).
- netfilter: xtables: avoid NFPROTO_UNSPEC where needed
  (CVE-2024-50038 bsc#1231910).
- commit 9ec5161

- net: mctp: unshare packets when reassembling (CVE-2025-21972
  bsc#1240813).
- commit 5878b19

- Reapply &amp;quot;Merge remote-tracking branch 'origin/users/sjaeckel/SLE15-SP6/for-next' into SLE15-SP6&amp;quot;
  This reverts commit 9b78ca60e10c64a737b9db2b85fdd944daac6ae6.
- commit 157dbaf

- net/tcp: refactor tcp_inet6_sk() (git-fixes).
- commit 459f538

- ntb_perf: Delete duplicate dmaengine_unmap_put() call in
  perf_copy_chunk() (git-fixes).
- commit eeb7f74

- ntb: intel: Fix using link status DB's (git-fixes).
- commit a988a90

- s390/cio: Fix CHPID &amp;quot;configure&amp;quot; attribute caching (git-fixes
  bsc#1240979).
- commit a947a32

- s390/pci: Fix zpci_bus_is_isolated_vf() for non-VFs (git-fixes
  bsc#1240978).
- commit 610fa90

- wifi: ath11k: fix memory leak in ath11k_xxx_remove()
  (git-fixes).
- Refresh
  patches.suse/wifi-ath11k-choose-default-PM-policy-for-hibernation.patch.
- Refresh
  patches.suse/wifi-ath11k-support-non-WoWLAN-mode-suspend-as-well.patch.
- commit 5ef71a9

- Update upstream status for ath11k patches
- commit 42fd2e8

- rpm/check-for-config-changes: add LD_CAN_ to IGNORED_CONFIGS_RE
  We now have LD_CAN_USE_KEEP_IN_OVERLAY since commit:
  e7607f7d6d81 ARM: 9443/1: Require linker to support KEEP within OVERLAY for DCE
- commit 7b55ff2

- perf tools: annotate asm_pure_loop.S (bsc#1239906).
- commit a3afe13

- perf/core: Order the PMU list to fix warning about unordered
  pmu_ctx_list (bsc#1240585 CVE-2025-21895).
- commit c393384

- io_uring/kbuf: reallocate buf lists on upgrade (CVE-2025-21836
  bsc#1239066).
- commit 1c3b3b4

- rpm/kernel-binary.spec.in: Use OrderWithRequires (boo#1228659 boo#1241038).
  OrderWithRequires was introduced in rpm 4.9 (ie. SLE12+) to allow
  a package to inform the order of installation of other package without
  hard requiring that package. This means our kernel-binary packages no
  longer need to hard require perl-Bootloader or dracut, resolving the
  long-commented issue there. This is also needed for udev &amp;amp; systemd-boot
  to ensure those packages are installed before being called by dracut
  (boo#1228659)
- commit 634be2c

- usb: dwc3: Set SUSPENDENABLE soon after phy init (git-fixes).
- commit 88d79df

- bpf: avoid holding freeze_mutex during mmap operation
  (git-fixes).
- bpf: unify VM_WRITE vs VM_MAYWRITE use in BPF map mmaping logic
  (git-fixes).
- selftests/bpf: Add test for narrow ctx load for pointer args
  (git-fixes).
- bpf: Check size for BTF-based ctx access of pointer members
  (git-fixes).
- bpf: Fix theoretical prog_array UAF in __uprobe_perf_func()
  (git-fixes).
- bpf: fix potential error return (git-fixes).
- commit 59fa8cd

- tty: serial: 8250: Add Brainboxes XC devices (stable-fixes).
- tty: serial: 8250: Add some more device IDs (stable-fixes).
- net: usb: qmi_wwan: add Telit Cinterion FE990B composition
  (stable-fixes).
- net: usb: qmi_wwan: add Telit Cinterion FN990B composition
  (stable-fixes).
- HID: hid-plantronics: Add mic mute mapping and generalize quirks
  (stable-fixes).
- drm/dp_mst: Add a helper to queue a topology probe
  (stable-fixes).
- drm/dp_mst: Factor out function to queue a topology probe work
  (stable-fixes).
- commit dcc0903

- scsi: qla1280: Fix kernel oops when debug level &amp;gt; 2 (CVE-2025-21957 bsc#1240742)
- commit bd3922a

- io_uring: prevent opcode speculation (CVE-2025-21863
  bsc#1239475).
- commit cf2b4a4

- wifi: rtw89: fix race between cancel_hw_scan and hw_scan completion (CVE-2025-21729 bsc#1237874)
- commit dfb7d10

- OPP: fix dev_pm_opp_find_bw_*() when bandwidth table not initialized (CVE-2024-58068 bsc#1238961)
- commit b424f57

- net: let net.core.dev_weight always be non-zero (CVE-2025-21806 bsc#1238746)
- commit c6ce075

- Refresh patches.suse/Bluetooth-L2CAP-Fix-corrupted-list-in-hci_chan_del.patch
  Drop redundant mutex lock that was forgotten
- commit 8253168

- net/mlx5: Bridge, fix the crash caused by LAG state check
  (CVE-2025-21970 bsc#1240819).
- eth: bnxt: do not update checksum in bnxt_xdp_build_skb()
  (CVE-2025-21960 bsc#1240815).
- eth: bnxt: fix truesize for mb-xdp-pass case (CVE-2025-21961
  bsc#1240816).
- net/mlx5: handle errors in mlx5_chains_create_table()
  (CVE-2025-21975 bsc#1240812).
- commit 5bfb0f9

- x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less
  NUMA nodes (CVE-2025-21991 bsc#1240795).
- x86/amd_nb: Use rdmsr_safe() in amd_get_mmconfig_range()
  (CVE-2025-21913 bsc#1240591).
- commit 718ae0d

- NFS: fix nfs_release_folio() to not deadlock via kcompactd
  writeback (CVE-2025-21908 bsc#1240600).
- commit a2db92f

- kABI workaround for l2cap_conn changes (CVE-2025-21969
  bsc#1240784).
- commit 0c8af58

- Bluetooth: L2CAP: Fix corrupted list in hci_chan_del
  (CVE-2025-21969 bsc#1240784).
- commit 730e49a

- Bluetooth: L2CAP: Fix slab-use-after-free Read in l2cap_send_cmd
  (CVE-2025-21969 bsc#1240784).
- iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in
  ibft_attr_show_nic() (CVE-2025-21993 bsc#1240797).
- commit 80da9db

- drm/amdgpu/gfx11: fix num_mec (git-fixes).
- drm/amd/pm: Prevent division by zero (git-fixes).
- Input: pm8941-pwrkey - fix dev_dbg() output in
  pm8941_pwrkey_irq() (git-fixes).
- Input: synaptics - hide unused smbus_pnp_ids[] array
  (git-fixes).
- commit d5f05d8

- powercap: intel_rapl_tpmi: Fix bogus register reading
  (git-fixes).
- commit 4482ca3

- powercap: intel_rapl_tpmi: Ignore minor version change
  (git-fixes).
- commit 8f97ff8

- powercap: dtpm_devfreq: Fix error check against
  dev_pm_qos_add_request() (git-fixes).
- commit 5af8777

- powercap: intel_rapl_tpmi: Fix System Domain probing
  (git-fixes).
- commit cb855f9

- usbnet:fix NPE during rx_complete (git-fixes).
- platform/x86: ISST: Correct command storage data length
  (git-fixes).
- ASoC: imx-card: Add NULL check in imx_card_probe() (git-fixes).
- ASoC: qdsp6: q6apm-dai: fix capture pipeline overruns
  (git-fixes).
- ASoC: qdsp6: q6apm-dai: set 10 ms period and buffer alignment
  (git-fixes).
- ASoC: qdsp6: q6asm-dai: fix q6asm_dai_compr_set_params error
  path (git-fixes).
- firmware: cs_dsp: Ensure cs_dsp_load[_coeff]() returns 0 on
  success (git-fixes).
- ALSA: hda/realtek: Fix built-in mic on another ASUS VivoBook
  model (git-fixes).
- ALSA: hda/realtek: Fix built-in mic breakage on ASUS VivoBook
  X515JA (git-fixes).
- commit e1c84cd

- vsock: Orphan socket after transport release (CVE-2025-21755 bsc#1237882)
- commit 6317d55

- tpm_tis: Use responseRetry to recover from data transfer errors
  (bsc#1235870).
- commit 6e4dc96

- tpm_tis: Move CRC check to generic send routine (bsc#1235870).
- Refresh patches.suse/tpm_tis-Resend-command-to-recover-from-data-transfer.patch
- commit 66fe063

- Delete patches.suse/tpm-send_data-Wait-longer-for-the-TPM-to-become-read.patch.
  To be replaced with upstream fix.
- commit d0fcf25

- rtnetlink: Allocate vfinfo size for VF GUIDs when supported
  (bsc#1224013).
- commit 34e3f46

- kernel-binary: Support livepatch_rt with merged RT branch
- commit 470cd1a

- arm64: Don't call NULL in do_compat_alignment_fixup() (git-fixes)
- commit 249080a

- arm64: mm: Correct the update of max_pfn (git-fixes)
- commit b6d4b51

- tpm: tis: Double the timeout B to 4s (bsc#1235870).
- commit 2ecc734

- tpm, tpm_tis: Workaround failed command reception on Infineon
  devices (bsc#1235870).
- commit cc21438

- ice: fix memory leak in aRFS after reset (CVE-2025-21981
  bsc#1240612).
- ppp: Fix KMSAN uninit-value warning with bpf (CVE-2025-21922
  bsc#1240639).
- net: hns3: make sure ptp clock is unregister and freed
  if hclge_ptp_get_cycle returns an error (CVE-2025-21924
  bsc#1240720).
- net: enetc: VFs do not support HWTSTAMP_TX_ONESTEP_SYNC
  (CVE-2025-21894 bsc#1240581).
- net: enetc: Replace ifdef with IS_ENABLED (CVE-2025-21894
  bsc#1240581).
- commit e9dce38

- wifi: iwlwifi: mvm: clean up ROC on failure (CVE-2025-21906
  bsc#1240587).
- commit 887f91d

- lib: scatterlist: fix sg_split_phys to preserve original
  scatterlist offsets (git-fixes).
- acpi: nfit: fix narrowing conversion in acpi_nfit_ctl
  (git-fixes).
- commit ea68f49

- smb: client: fix open_cached_dir retries with 'hard' mount
  option (bsc#1240616).
- commit 504723c

- exfat: fix the infinite loop in exfat_find_last_cluster()
  (git-fixes).
- commit 8b30c73

- rpm/check-for-config-changes: ignore DRM_MSM_VALIDATE_XML
  This option is dynamically enabled to build-test different configurations.
  This makes run_oldconfig.sh complain sporadically for arm64.
- commit 8fbe8b1

- net: fix data-races around sk-&amp;gt;sk_forward_alloc (CVE-2024-53124
  bsc#1234074).
- commit ea48905

- sctp: fix possible UAF in sctp_v6_available() (CVE-2024-53139
  bsc#1234157).
- commit 779dfcf

- usb: xhci: correct debug message page size calculation
  (git-fixes).
- ucsi_ccg: Don't show failed to get FW build information error
  (git-fixes).
- serial: 8250_dma: terminate correct DMA in tx_dma_flush()
  (git-fixes).
- tty: serial: fsl_lpuart: disable transmitter before changing
  RS485 related registers (git-fixes).
- staging: rtl8723bs: select CONFIG_CRYPTO_LIB_AES (git-fixes).
- counter: microchip-tcb-capture: Fix undefined counter channel
  state on probe (git-fixes).
- counter: stm32-lptimer-cnt: fix error handling when enabling
  (git-fixes).
- ACPI: x86: Extend Lenovo Yoga Tab 3 quirk with skip GPIO
  event-handlers (git-fixes).
- objtool: Fix segfault in ignore_unreachable_insn() (git-fixes).
- objtool, media: dib8000: Prevent divide-by-zero in
  dib8000_set_dds() (git-fixes).
- objtool, spi: amd: Fix out-of-bounds stack access in
  amd_set_spi_freq() (git-fixes).
- counter: fix privdata alignment (git-fixes).
- commit 8ea2563

- Move upstreamed ACPI patch into sorted section
- commit 871d0d6

- tty: serial: lpuart: only disable CTS instead of overwriting
  the whole UARTMODIR register (git-fixes).
- PCI: histb: Fix an error handling path in histb_pcie_probe()
  (git-fixes).
- PCI: Fix BAR resizing when VF BARs are assigned (git-fixes).
- PCI: Fix reference leak in pci_register_host_bridge()
  (git-fixes).
- commit 808a9df

- net: better track kernel sockets lifetime (CVE-2025-21884
  bsc#1240171).
- net: Add net_passive_inc() and net_passive_dec() (CVE-2025-21884
  bsc#1240171).
- commit 741fa11

- Update
  patches.suse/RDMA-core-Don-t-expose-hw_counters-outside-of-init-n.patch
  (git-fixes bsc#1239925).
- Update
  patches.suse/kABI-fix-for-RDMA-core-Don-t-expose-hw_counters-outs.patch
  (git-fixes bsc#1239925).
  Add bug reference.
- commit 8eef29b

- Revert &amp;quot;Merge remote-tracking branch 'origin/users/sjaeckel/SLE15-SP6/for-next' into SLE15-SP6&amp;quot;
  This reverts commit bb7a7b2a95aa93ef5db11cca2317b7fe59e19e38, reversing
  changes made to ac2aed10902386a981d430e6af9b7946722682ea.
- commit 9b78ca6

- arm64: Utilize for_each_cpu_wrap for reference lookup (bsc#1238052)
- commit ff26688

- Refresh
  patches.suse/net-usb-usbnet-restore-usb-d-name-exception-for-loca.patch.
  Moved into place as merged upstream
- commit 098c735

- arch_topology: init capacity_freq_ref to 0 (bsc#1238052)
- commit c70af66

- cpufreq: Introduce an optional cpuinfo_avg_freq sysfs entry (bsc#1238052)
  Keep the feature disabled by default on x86_64
- commit 0ffcad3

- cpufreq: Allow arch_freq_get_on_cpu to return an error (bsc#1238052)
- commit 7e63d78

- arm64: Update AMU-based freq scale factor on entering idle (bsc#1238052)
- commit eb90de6

- arm64: Provide an AMU-based version of arch_freq_get_on_cpu (bsc#1238052)
- commit 1d57e2b

- arm64: amu: Delay allocating cpumask for AMU FIE support (bsc#1238052)
- commit 3eb3994

- topology: Set capacity_freq_ref in all cases (bsc#1238052)
- commit d357c02

- arch_topology: Make register_cpu_capacity_sysctl() tolerant to late (bsc#1238052)
- commit c2cc745

- arm64/amu: Use capacity_ref_freq() to set AMU ratio (bsc#1238052)
- commit 679001e

- cpufreq/cppc: Set the frequency used for computing the capacity (bsc#1238052)
- commit bad5fb8

- sched/topology: Add a new arch_scale_freq_ref() method (bsc#1238052)
- commit be4a850

- selftests: mptcp: close fd_in before returning in main_loop
  (git-fixes).
- selftests: mptcp: fix incorrect fd checks in main_loop
  (git-fixes).
- rndis_host: Flag RNDIS modems as WWAN devices (git-fixes).
- thermal/drivers/rockchip: Add missing rk3328 mapping entry
  (git-fixes).
- i3c: Add NULL pointer check in i3c_master_queue_ibi()
  (git-fixes).
- i3c: master: svc: Use readsb helper for reading MDB (git-fixes).
- i3c: master: svc: Fix missing the IBI rules (git-fixes).
- soundwire: slave: fix an OF node reference leak in soundwire
  slave device (git-fixes).
- bus: mhi: host: Fix race between unprepare and queue_buf
  (git-fixes).
- iio: adc: ad7124: Fix comparison of channel configs (git-fixes).
- iio: adc: ad4130: Fix comparison of channel setups (git-fixes).
- iio: accel: msa311: Fix failure to release runtime pm if direct
  mode claim fails (git-fixes).
- iio: accel: mma8452: Ensure error return on failure to matching
  oversampling ratio (git-fixes).
- driver core: Remove needless return in void API
  device_remove_group() (git-fixes).
- selftests/mm/cow: fix the incorrect error handling (git-fixes).
- commit 0fbd190

- uprobes: Reject the shared zeropage in uprobe_write_opcode() (CVE-2025-21881 bsc#1240185)
- commit 8483377

- scsi: ufs: core: bsg: Fix crash when arpmb command fails (CVE-2025-21873 bsc#1240184)
- commit 8b26b99

- xhci: Fix null pointer dereference during S4 resume when
  resetting ep0 (bsc#1235550).
- commit 647e59a

- RAS: Avoid build errors when CONFIG_DEBUG_FS=n (jsc#PED-7619).
  Replace our patch with the upstream version.
- Delete
  patches.suse/RAS-AMD-FMPM-Fix-build-when-debugfs-is-not-enabled.patch.
- commit 9580b87

- kABI fix for RDMA/core: Don't expose hw_counters outside (git-fixes)
- commit 6079f81

- RDMA/core: Don't expose hw_counters outside of init net namespace (git-fixes)
- commit f134527

- xhci: fix possible null pointer deref during xhci urb enqueue
  (bsc#1235550).
- commit e4d47e4

- xhci: Reconfigure endpoint 0 max packet size only during
  endpoint reset (bsc#1235550).
- commit fe44e60

- rpm/release-projects: Update the ALP projects again (bsc#1231293).
- commit a2f9145

- nvme: move passthrough logging attribute to head (git-fixes).
- nvme: introduce nvme_disk_is_ns_head helper (git-fixes).
- commit e2a4340

- bpf: Add tracepoints with null-able arguments (bsc#1235501
  CVE-2024-56702).
- commit 60ddcfa

- net: Add rx_skb of kfree_skb to raw_tp_null_args (bsc#1235501
  CVE-2024-56702).
- commit 2f246d2

- bpf: Augment raw_tp arguments with PTR_MAYBE_NULL (bsc#1235501
  CVE-2024-56702).
- commit bd84127

- CIFS: New mount option for cifs.upcall namespace resolution
  (CVE-2025-2312 bsc#1239684).
- commit b749482

- ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up (CVE-2025-21887 bsc#1240176)
- commit d9e7d31

- mptcp: always handle address removal under msk socket lock (CVE-2025-21875 bsc#1240168)
- commit ae417d1

- perf/core: Add RCU read lock protection to perf_iterate_ctx() (CVE-2025-21889 bsc#1240167)
- commit 6d49490

- nvkm: correctly calculate the available space of the GSP cmdq buffer (CVE-2024-58018 bsc#1238990)
- commit 3fbbd2b

- team: prevent adding a device which is already a team device lower (CVE-2024-58071 bsc#1238970)
- commit 0e6515d

- mm/page_alloc: fix memory accept before watermarks gets
  initialized (bsc#1239600).
- commit 10a4fc6

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

- nvme-tcp: Fix a C2HTermReq error message (git-fixes).
- commit c4c365f

- nvme: move error logging from nvme_end_req() to __nvme_end_req()
  (git-fixes).
- commit c939fa2

- nvme-fc: rely on state transitions to handle connectivity loss
  (git-fixes bsc#1222649).
- commit 0e1fcfd

- nvme: allow passthru cmd error logging (git-fixes).
  Refresh:
  - patches.suse/nvme-fix-multipath-batched-completion-accounting.patch
  - patches.suse/nvme-use-srcu-for-iterating-namespace-list.patch
  - patches.suse/nvme-split-off-tls-sysfs-attributes-into-a-separate-group.patch
- commit ca344c0

- arm64: cputype: Add MIDR_CORTEX_A76AE (git-fixes)
- commit aad868b

- nvmet-fc: Remove unused functions (git-fixes).
- nvme-pci: remove stale comment (git-fixes).
- nvme-tcp: fix signedness bug in nvme_tcp_init_connection()
  (git-fixes).
- nvmet-tcp: Fix a possible sporadic response drops in weakly
  ordered arch (git-fixes).
- nvme-tcp: fix potential memory corruption in nvme_tcp_recv_pdu()
  (git-fixes).
- nvmet: remove old function prototype (git-fixes).
- nvme-ioctl: fix leaked requests on mapping error (git-fixes).
- nvme: only allow entering LIVE from CONNECTING state
  (git-fixes bsc#1222649).
- nvmet-rdma: recheck queue state is LIVE in state lock in recv
  done (git-fixes).
- nvme-tcp: add basic support for the C2HTermReq PDU (git-fixes).
- nvme-pci: quirk Acer FA100 for non-uniqueue identifiers
  (git-fixes).
- nvme-fc: do not ignore connectivity loss during connecting
  (git-fixes bsc#1222649).
  Refresh:
  - patches.suse/nvme-fc-use-ctrl-state-getter.patch
- nvme-fc: go straight to connecting state when initializing
  (git-fixes bsc#1222649).
- commit 22d62a2

- arm64: dts: rockchip: Fix PWM pinctrl names (git-fixes)
- commit bea89fa

- arm64: dts: rockchip: Remove bluetooth node from rock-3a (git-fixes)
- commit 3224bb8

- arm64: tegra: Remove the Orin NX/Nano suspend key (git-fixes)
- commit bcfde59

- arm64: errata: Add newer ARM cores to the spectre_bhb_loop_affected() (git-fixes)
- commit 4d30cdc

- arm64: errata: Add KRYO 2XX/3XX/4XX silver cores to Spectre BHB safe (git-fixes)
- commit 49aa8a8

- arm64: errata: Assume that unknown CPUs _are_ vulnerable to Spectre (git-fixes)
- commit eb80776

- arm64: errata: Add QCOM_KRYO_4XX_GOLD to the spectre_bhb_k24_list (git-fixes)
- commit b4f3b31

- idpf: fix checksums set in idpf_rx_rsc() (CVE-2025-21890
  bsc#1240173).
- ice: Fix deinitializing VF in error path (CVE-2025-21883
  bsc#1240189).
- ipvlan: ensure network headers are in skb linear part
  (CVE-2025-21891 bsc#1240186).
- commit ac7a561

- Update
  patches.suse/RDMA-bnxt_re-Fix-the-page-details-for-the-srq-create.patch
  (git-fixes CVE-2025-21885 bsc#1240169).
- Update
  patches.suse/RDMA-mlx5-Fix-a-WARN-during-dereg_mr-for-DM-type.patch
  (git-fixes CVE-2025-21888 bsc#1240177).
- Update
  patches.suse/RDMA-mlx5-Fix-implicit-ODP-hang-on-parent-deregistra.patch
  (git-fixes CVE-2025-21886 bsc#1240188).
- Update
  patches.suse/RDMA-mlx5-Fix-the-recovery-flow-of-the-UMR-QP.patch
  (git-fixes CVE-2025-21892 bsc#1240175).
- Update
  patches.suse/i2c-npcm-disable-interrupt-enable-bit-before-devm_re.patch
  (git-fixes CVE-2025-21878 bsc#1240192).
- Update
  patches.suse/ibmvnic-Don-t-reference-skb-after-sending-to-VIOS.patch
  (CVE-2025-21858 bsc#1239468 CVE-2025-21855 bsc#1239484).
- Update patches.suse/iommu-vt-d-Fix-suspicious-RCU-usage.patch
  (git-fixes CVE-2025-21876 bsc#1240179).
- Update
  patches.suse/ndisc-use-RCU-protection-in-ndisc_alloc_skb.patch
  (bsc#1239994 CVE-2025-21764 bsc#1237885).
- Update
  patches.suse/powerpc-code-patching-Disable-KASAN-report-during-pa.patch
  (bsc#1215199 CVE-2025-21869 bsc#1240182).
- Update
  patches.suse/usbnet-gl620a-fix-endpoint-checking-in-genelink_bind.patch
  (git-fixes CVE-2025-21877 bsc#1240172).
- commit 9c6e710

- Update
  patches.suse/block-fix-integer-overflow-in-BLKSECDISCARD.patch
  (git-fixes CVE-2024-49994 bsc#1225770 bsc#1237757).
- Update
  patches.suse/crypto-qat-qat_420xx-fix-off-by-one-in-uof_get_name.patch
  (jsc#PED-12416 CVE-2024-53163 bsc#1234828).
- Update
  patches.suse/crypto-qat-validate-slices-count-returned-by-FW.patch
  (jsc#PED-12416 CVE-2024-38606 bsc#1226871).
- Update
  patches.suse/dm-raid-Fix-WARN_ON_ONCE-check-for-sync_thread-in-ra.patch
  (git-fixes CVE-2024-43820 bsc#1229311).
- Update
  patches.suse/fbdev-pxafb-Fix-possible-use-after-free-in-pxafb_tas.patch
  (stable-fixes CVE-2024-49924 bsc#1232364).
- Update
  patches.suse/media-cx24116-prevent-overflows-on-SNR-calculus.patch
  (git-fixes CVE-2024-50290 bsc#1233479 bsc#1225742).
- Update
  patches.suse/media-dvbdev-prevent-the-risk-of-out-of-memory-acces.patch
  (git-fixes CVE-2024-53063 bsc#1233557 bsc#1225742).
- commit e0b966a

- IB/mad: Check available slots before posting receive WRs (git-fixes)
- commit 34587d0

- RDMA/mlx5: Fix calculation of total invalidated pages (git-fixes)
- commit 2fa0f31

- RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow (git-fixes)
- commit b249c41

- RDMA/mlx5: Fix cache entry update on dereg error (git-fixes)
- commit 0fe5ca5

- RDMA/mlx5: Fix MR cache initialization error flow (git-fixes)
- commit e5c2137

- RDMA/erdma: Prevent use-after-free in erdma_accept_newconn() (git-fixes)
- commit 3634652

- power: supply: max77693: Fix wrong conversion of charge input
  threshold value (git-fixes).
- pinctrl: qcom: Clear latched interrupt status when changing
  IRQ type (git-fixes).
- pinctrl: tegra: Set SFIO mode to Mux Register (git-fixes).
- pinctrl: intel: Fix wrong bypass assignment in
  intel_pinctrl_probe_pwm() (git-fixes).
- pinctrl: renesas: rza2: Fix missing of_node_put() call
  (git-fixes).
- pinctrl: renesas: rzv2m: Fix missing of_node_put() call
  (git-fixes).
- backlight: led_bl: Hold led_access lock when calling
  led_sysfs_disable() (git-fixes).
- leds: rgb: leds-qcom-lpg: Fix calculation of best period Hi-Res
  PWMs (git-fixes).
- leds: rgb: leds-qcom-lpg: Fix pwm resolution max for Hi-Res PWMs
  (git-fixes).
- Revert &amp;quot;leds-pca955x: Remove the unused function
  pca95xx_num_led_regs()&amp;quot; (stable-fixes).
- crypto: nx - Fix uninitialised hv_nxc on error (git-fixes).
- crypto: qat - remove access to parity register for QAT GEN4
  (git-fixes).
- crypto: qat - set parity error mask for qat_420xx (git-fixes).
- crypto: ccp - Fix uAPI definitions of PSP errors (git-fixes).
- crypto: iaa - Test the correct request flag (git-fixes).
- crypto: hisilicon/sec2 - fix for sec spec check (git-fixes).
- crypto: hisilicon/sec2 - fix for aead authsize alignment
  (git-fixes).
- crypto: hisilicon/sec2 - fix for aead auth key length
  (git-fixes).
- crypto: ccp - Fix check for the primary ASP device (git-fixes).
- lib: 842: Improve error handling in sw842_compress()
  (git-fixes).
- commit 8ad02d4

- mfd: ene-kb3930: Fix a potential NULL pointer dereference
  (git-fixes).
- mfd: sm501: Switch to BIT() to mitigate integer overflows
  (git-fixes).
- mfd: syscon: Fix race in device_node_get_regmap() (git-fixes).
- mfd: syscon: Use scoped variables with memory allocators to
  simplify error paths (stable-fixes).
- mfd: syscon: Add of_syscon_register_regmap() API (stable-fixes).
- mfd: syscon: Remove extern from function prototypes
  (stable-fixes).
- commit 87db269

- ocfs2: mark dquot as inactive if failed to start trans while
  releasing dquot (git-fixes).
- commit 54dc104

- ocfs2: fix deadlock in ocfs2_get_system_file_inode (git-fixes).
- commit 73be6ce

- ocfs2: update seq_file index in ocfs2_dlm_seq_next (git-fixes).
- commit ef7689a

- ocfs2: check dir i_size in ocfs2_find_entry (git-fixes).
- commit cc4c3a7

- ocfs2: handle a symlink read error correctly (git-fixes).
- commit 79c2998

- dlm: prevent NPD when writing a positive value to event_done
  (git-fixes).
- commit 8f717c8

- jfs: add index corruption check to DT_GETPAGE() (git-fixes).
- commit bb32126

- jfs: fix slab-out-of-bounds read in ea_get() (git-fixes).
- commit 45fdfe2

- jfs: add check read-only before truncation in
  jfs_truncate_nolock() (git-fixes).
- commit 88c1bf9

- jfs: add check read-only before txBeginAnon() call (git-fixes).
- commit 7ae1e64

- jfs: reject on-disk inodes of an unsupported type (git-fixes).
- commit fd3fbef

- Move upstreamed nfsd and sunrpc patches into sorted section
- commit 8ca9bbb

- Move upstreamed PCI and initramfs patches into sorted section
- commit 66970bb

- Move upstreamed powerpc and SCSI patches into sorted section
- commit 21807c4

- PCI: xilinx-cpm: Fix IRQ domain leak in error path of probe
  (git-fixes).
- PCI: dwc: ep: Return -ENOMEM for allocation failures
  (git-fixes).
- PCI: cadence-ep: Fix the driver to send MSG TLP for INTx
  without data payload (git-fixes).
- PCI: brcmstb: Fix potential premature regulator disabling
  (git-fixes).
- PCI: brcmstb: Fix error path after a call to
  regulator_bulk_get() (git-fixes).
- PCI: brcmstb: Use internal register to change link capability
  (git-fixes).
- PCI: brcmstb: Set generation limit before PCIe link up
  (git-fixes).
- PCI: brcmstb: Fix missing of_node_put() in brcm_pcie_probe()
  (git-fixes).
- PCI: Avoid reset when disabled via sysfs (git-fixes).
- PCI: pciehp: Don't enable HPIE when resuming in poll mode
  (git-fixes).
- PCI/portdrv: Only disable pciehp interrupts early when needed
  (git-fixes).
- PCI: Remove stray put_device() in pci_register_host_bridge()
  (git-fixes).
- PCI: Fix reference leak in pci_alloc_child_bus() (git-fixes).
- PCI/ASPM: Fix link state exit during switch upstream function
  removal (git-fixes).
- PCI/ACS: Fix 'pci=config_acs=' parameter (git-fixes).
- drm/amd/display: avoid NPD when ASIC does not support DMUB
  (git-fixes).
- drm/mediatek: dsi: fix error codes in mtk_dsi_host_transfer()
  (git-fixes).
- drm/mediatek: dp: drm_err =&amp;gt; dev_err in HPD path to avoid NULL
  ptr (git-fixes).
- drm/mediatek: mtk_hdmi: Fix typo for aud_sampe_size member
  (git-fixes).
- drm/mediatek: mtk_hdmi: Unregister audio platform device on
  failure (git-fixes).
- drm/msm/a6xx: Fix a6xx indexed-regs in devcoreduump (git-fixes).
- drm/msm/a6xx: Fix stale rpmh votes from GPU (git-fixes).
- drm/msm/dsi: Set PHY usescase (and mode) before registering
  DSI host (git-fixes).
- drm/msm/dsi: Use existing per-interface slice count in DSC
  timing (git-fixes).
- drm/msm/dpu: don't use active in atomic_check() (git-fixes).
- drm/amd/display: fix type mismatch in
  CalculateDynamicMetadataParameters() (git-fixes).
- drm/amdkfd: Fix Circular Locking Dependency in
  'svm_range_cpu_invalidate_pagetables' (git-fixes).
- drm/bridge: Fix spelling mistake &amp;quot;gettin&amp;quot; -&amp;gt; &amp;quot;getting&amp;quot;
  (git-fixes).
- drm/repaper: fix integer overflows in repeat functions
  (git-fixes).
- drm/panel: ilitek-ili9882t: fix GPIO name in error message
  (git-fixes).
- drm/i915/dsi: Use TRANS_DDI_FUNC_CTL's own port width macro
  (git-fixes).
- drm/amdgpu: Replace Mutex with Spinlock for RLCG register
  access to avoid Priority Inversion in SRIOV (git-fixes).
- drm/amdgpu/umsch: declare umsch firmware (git-fixes).
- drm/radeon/ci_dpm: Remove needless NULL checks of dpm tables
  (git-fixes).
- drm/vkms: Fix use after free and double free on init error
  (git-fixes).
- drm: xlnx: zynqmp: Fix max dma segment size (git-fixes).
- drm/bridge: it6505: fix HDCP V match check is not performed
  correctly (git-fixes).
- drm/dp_mst: Fix drm RAD print (git-fixes).
- drm/ssd130x: ensure ssd132x pitch is correct (git-fixes).
- drm/ssd130x: fix ssd132x encoding (git-fixes).
- drm/ssd130x: Set SPI .id_table to prevent an SPI core warning
  (git-fixes).
- drm/bridge: ti-sn65dsi86: Fix multiple instances (git-fixes).
- fbdev: sm501fb: Add some geometry checks (git-fixes).
- mdacon: rework dependency list (git-fixes).
- dummycon: fix default rows/cols (git-fixes).
- fbdev: au1100fb: Move a variable assignment behind a null
  pointer check (git-fixes).
- tpm, tpm_tis: Fix timeout handling when waiting for TPM status
  (git-fixes).
- tpm: do not start chip while suspended (git-fixes).
- regulator: check that dummy regulator has been probed before
  using it (stable-fixes).
- drm/amd/display: Use HW lock mgr for PSR1 when only one eDP
  (git-fixes).
- drm/amdgpu: Fix JPEG video caps max size for navi1x and raven
  (stable-fixes).
- drm/amdgpu: Fix MPEG2, MPEG4 and VC1 video caps max size
  (stable-fixes).
- soc: imx8m: Unregister cpufreq and soc dev in cleanup path
  (git-fixes).
- soc: imx8m: Use devm_* to simplify probe failure handling
  (stable-fixes).
- soc: imx8m: Remove global soc_uid (stable-fixes).
- fbdev: pxafb: Fix possible use after free in pxafb_task()
  (stable-fixes).
- commit 0b221d1

- mptcp: pm: only set fullmesh for subflow endp (CVE-2025-21706 bsc#1238528)
- commit 1499b76

- net: ipv6: fix dst refleaks in rpl, seg6 and ioam6 lwtunnels
  (git-fixes).
- net: ipv6: ioam6_iptunnel: mitigate 2-realloc issue (git-fixes).
- ioam6: improve checks on user data (git-fixes).
- net: ipv6: ioam6: new feature tunsrc (git-fixes).
- net: ipv6: ioam6: code alignment (git-fixes).
- ipv6: ioam: block BH from ioam6_output() (git-fixes).
- commit 2678976

- af_unix: Remove put_pid()/put_cred() in copy_peercred()
  (bsc#1240334).
- commit 3c2ac6a

- splice: do not checksum AF_UNIX sockets (bsc#1240333).
- commit 73d1c92

- Reapply &amp;quot;wifi: ath11k: restore country code during resume&amp;quot;
  (bsc#1207948).
- wifi: ath11k: choose default PM policy for hibernation
  (bsc#1207948).
- wifi: ath11k: support non-WoWLAN mode suspend as well
  (bsc#1207948).
- wifi: ath11k: refactor ath11k_core_suspend/_resume()
  (bsc#1207948).
- wifi: ath11k: introduce ath11k_core_continue_suspend_resume()
  (bsc#1207948).
- wifi: ath11k: determine PM policy based on machine model
  (bsc#1207948).
- commit 776bdcc

- tee: optee: Fix supplicant wait loop (CVE-2025-21871
  bsc#1240183).
- ASoC: SOF: ipc4-topology: Harden loops for looking up ALH
  copiers (CVE-2025-21870 bsc#1240191).
- commit d4df66d

- kunit: qemu_configs: sparc: use Zilog console (git-fixes).
- bus: qcom-ssc-block-bus: Fix the error handling path of
  qcom_ssc_block_bus_probe() (git-fixes).
- bus: qcom-ssc-block-bus: Remove some duplicated iounmap()
  calls (git-fixes).
- memory: mtk-smi: Add ostd setting for mt8192 (git-fixes).
- soc: samsung: exynos-chipid: Add NULL pointer check in
  exynos_chipid_probe() (git-fixes).
- soc: mediatek: mt8365-mmsys: Fix routing table masks and values
  (git-fixes).
- soc: mediatek: mt8167-mmsys: Fix missing regval in all entries
  (git-fixes).
- firmware: arm_scmi: use ioread64() instead of ioread64_hi_lo()
  (git-fixes).
- firmware: arm_ffa: Explicitly cast return value from FFA_VERSION
  before comparison (git-fixes).
- Bluetooth: HCI: Add definition of hci_rp_remote_name_req_cancel
  (git-fixes).
- wifi: mt76: mt7925: remove unused acpi function for clc
  (git-fixes).
- wifi: mt76: Add check for devm_kstrdup() (git-fixes).
- wifi: mt76: mt7925: fix country count limitation for CLC
  (git-fixes).
- wifi: mt76: mt7925: ensure wow pattern command align fw format
  (git-fixes).
- wifi: mt76: mt7915: fix possible integer overflows in
  mt7915_muru_stats_show() (git-fixes).
- wifi: rtw89: pci: correct ISR RDU bit for 8922AE (git-fixes).
- wifi: rtw89: fw: correct debug message format in
  rtw89_build_txpwr_trk_tbl_from_elm() (git-fixes).
- wifi: mwifiex: Fix premature release of RF calibration data
  (git-fixes).
- wifi: cfg80211: init wiphy_work before allocating rfkill fails
  (git-fixes).
- wifi: ath12k: Clear affinity hint before calling
  ath12k_pci_free_irq() in error path (git-fixes).
- wifi: ath11k: Clear affinity hint before calling
  ath11k_pcic_free_irq() in error path (git-fixes).
- wifi: ath11k: add srng-&amp;gt;lock for ath11k_hal_srng_* in monitor
  mode (git-fixes).
- wifi: ath11k: fix RCU stall while reaping monitor destination
  ring (git-fixes).
- wifi: ath11k: fix wrong overriding for VHT Beamformee STS
  Capability (git-fixes).
- wifi: ath9k: do not submit zero bytes to the entropy pool
  (git-fixes).
- wifi: ath12k: encode max Tx power in scan channel list command
  (git-fixes).
- broadcom: fix supported flag check in periodic output function
  (git-fixes).
- wifi: mac80211: fix integer overflow in hwmp_route_info_get()
  (git-fixes).
- commit 62d1ca7

- drop_monitor: fix incorrect initialization order (CVE-2025-21862
  bsc#1239474).
- rds: sysctl: rds_tcp_{rcv,snd}buf: avoid using current-&amp;gt;nsproxy
  (CVE-2025-21635 bsc#1236111).
- net/smc: protect link down work from execute after lgr freed
  (CVE-2024-56718 bsc#1235589).
- netfilter: IDLETIMER: Fix for possible ABBA deadlock
  (CVE-2024-54683 bsc#1235729).
- net/smc: fix LGR and link use-after-free issue (CVE-2024-56640
  bsc#1235436).
- ipv6: Fix soft lockups in fib6_select_path under high next
  hop churn (CVE-2024-56703 bsc#1235455).
- commit 32a040d

- kABI fix for net: ipv6: support reporting otherwise unknown
  prefix flags in RTM_NEWPREFIX (git-fixes).
- commit 3656735

- net: avoid race between device unregistration and ethnl ops
  (CVE-2025-21701 bsc#1237164).
- commit adae27d

- net: usb: usbnet: restore usb%d name exception for local mac
  addresses (bsc#1234480).
- commit 0605bcc

- x86/entry: Add __init to ia32_emulation_override_cmdline()
  (git-fixes).
- commit 98c0019

- ALSA: hda: Fix speakers on ASUS EXPERTBOOK P5405CSA 1.0
  (stable-fixes).
- Refresh
  patches.suse/ALSA-hda-realtek-Add-support-for-various-ASUS-Laptop.patch.
- commit a9e9dbb

- ALSA: hda/realtek: Add support for various HP Laptops using
  CS35L41 HDA (stable-fixes).
- ALSA: hda/realtek: Add support for ASUS B5405 and B5605 Laptops
  using CS35L41 HDA (stable-fixes).
- ALSA: hda/realtek: Add support for ASUS B3405 and B3605 Laptops
  using CS35L41 HDA (stable-fixes).
- commit 249008f

- ALSA: usb-audio: Add quirk for Plantronics headsets to fix
  control names (stable-fixes).
- ALSA: hda/realtek: Support mute LED on HP Laptop 15s-du3xxx
  (stable-fixes).
- commit 401355a

- coredump: Fixes core_pipe_limit sysctl proc_handler (git-fixes).
- ata: libata: Fix NCQ Non-Data log not supported print
  (git-fixes).
- mtd: nand: Fix a kdoc comment (git-fixes).
- mtd: rawnand: brcmnand: fix PM resume warning (git-fixes).
- mtd: Add check for devm_kcalloc() (git-fixes).
- mtd: Replace kcalloc() with devm_kcalloc() (git-fixes).
- HID: Enable playstation driver independently of sony driver
  (git-fixes).
- HID: remove superfluous (and wrong) Makefile entry for
  CONFIG_INTEL_ISH_FIRMWARE_DOWNLOADER (git-fixes).
- platform/x86: dell-ddv: Fix temperature calculation (git-fixes).
- ALSA: hda/realtek: Fix built-in mic assignment on ASUS VivoBook
  X515UA (git-fixes).
- ASoC: cs35l41: check the return value from spi_setup()
  (git-fixes).
- ASoC: ti: j721e-evm: Fix clock configuration for
  ti,j7200-cpb-audio compatible (git-fixes).
- ALSA: usb-audio: separate DJM-A9 cap lvl options (git-fixes).
- ALSA: hda/realtek: Always honor no_shutup_pins (git-fixes).
- ALSA: pcm: Drop superfluous NULL check in
  snd_pcm_format_set_silence() (git-fixes).
- commit 52d0d3b

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

- include: net: add static inline dst_dev_overhead() to dst.h
  (git-fixes).
- commit 38a62b9

- Refresh patches.suse/tpm-send_data-Wait-longer-for-the-TPM-to-become-read.patch.
  Also extend the remaining tpm_tis_send_data timeout (bsc#1235870).
- commit 4b3d91d

- x86/microcode/intel: Add a minimum required revision for late loading (git-fixes).
- commit 5da2185

- x86/microcode: Prepare for minimal revision check (git-fixes).
- commit c420631

- x86/microcode: Handle &amp;quot;offline&amp;quot; CPUs correctly (git-fixes).
- commit 392e00e

- x86/apic: Provide apic_force_nmi_on_cpu() (git-fixes).
- commit b3900fd

- cpufreq/amd-pstate: Fix max_perf updation with schedutil
  (bsc#1239707).
- commit fefd3ab

- kABI fix for ipv6: remove hard coded limitation on ipv6_pinfo
  (git-fixes).
- commit 2b5c9da

- x86/microcode: Protect against instrumentation (git-fixes).
- commit c6912a2

- x86/microcode: Rendezvous and load in NMI (git-fixes).
- commit 62c98c3

- x86/microcode: Replace the all-in-one rendevous handler (git-fixes).
- commit 918f8ee

- x86/microcode: Provide new control functions (git-fixes).
- commit 8430c04

- x86/microcode: Add per CPU control field (git-fixes).
- commit 866b0a5

- x86/microcode: Add per CPU result state (git-fixes).
- commit 579033e

- net/smc: check smcd_v2_ext_offset when receiving proposal msg
  (CVE-2024-47408 bsc#1235711).
- commit 2f01046

- x86/microcode: Clarify the late load logic (git-fixes).
- commit 6230ee4

- x86/microcode: Handle &amp;quot;nosmt&amp;quot; correctly (git-fixes).
- Refresh
  patches.suse/x86-microcode-Sanitize-__wait_for_cpus.patch.
- commit dc94359

- x86/microcode: Clean up mc_cpu_down_prep() (git-fixes).
- commit bdacddf

- x86/microcode: Get rid of the schedule work indirection (git-fixes).
- commit 6a00f9e

- x86/microcode: Mop up early loading leftovers (git-fixes).
- commit 9018df4

- kABI fix for &amp;quot;netfilter: nft_inner: incorrect percpu area
  handling under softirq&amp;quot; (CVE-2024-56638 bsc#1235524).
- commit 3acf757

- ipv6: introduce dst_rt6_info() helper (git-fixes).
- Refresh patches.suse/ipv6-prevent-UAF-in-ip6_send_skb.patch.
- Refresh patches.suse/net-fix-__dst_negative_advice-race.patch.
- commit a265247

- ipv6: sr: add missing seg6_local_exit (git-fixes).
- Refresh
  patches.suse/ipv6-sr-fix-incorrect-unregister-order.patch.
- commit ef06a22

- ipv6: annotate data-races around cnf.disable_ipv6 (git-fixes).
- Refresh
  patches.suse/ipv6-prevent-NULL-dereference-in-ip6_output.patch.
- commit 97af13b

- x86/microcode/amd: Use cached microcode for AP load (git-fixes).
- commit 916bc1a

- x86/microcode/amd: Cache builtin/initrd microcode early (git-fixes).
- commit 6cd5382

- x86/microcode/amd: Cache builtin microcode too (git-fixes).
- commit d0a37ed

- x86/microcode/amd: Use correct per CPU ucode_cpu_info (git-fixes).
- commit 834a488

- x86/microcode: Remove pointless apply() invocation (git-fixes).
- commit a5ea134

- ipv6: Set errno after ip_fib_metrics_init() in
  ip6_route_info_create() (git-fixes).
- ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw()
  (git-fixes).
- net: ipv6: fix missing dst ref drop in ila lwtunnel (git-fixes).
- net: ipv6: fix dst ref loop in ila lwtunnel (git-fixes).
- net: ipv6: fix dst ref loop on input in rpl lwt (git-fixes).
- net: ipv6: fix dst ref loop on input in seg6 lwt (git-fixes).
- net: ipv6: rpl_iptunnel: mitigate 2-realloc issue (git-fixes).
- net: ipv6: seg6_iptunnel: mitigate 2-realloc issue (git-fixes).
- ipv6: release nexthop on device removal (CVE-2024-56751
  bsc#1234936).
- net: ipv6: select DST_CACHE from IPV6_RPL_LWTUNNEL (git-fixes).
- net: ipv6: rpl_iptunnel: Fix memory leak in rpl_input
  (git-fixes).
- ipv6: fix ndisc_is_useropt() handling for PIO (git-fixes).
- ipv6: take care of scope when choosing the src addr (git-fixes).
- net: use unrcu_pointer() helper (git-fixes).
- ipv6: sr: block BH in seg6_output_core() and seg6_input_core()
  (git-fixes).
- net: ipv6: rpl_iptunnel: block BH in rpl_output() and
  rpl_input() (git-fixes).
- net: ipv6: fix wrong start position when receive hop-by-hop
  fragment (git-fixes).
- ipv6: fib: hide unused 'pn' variable (git-fixes).
- ipv6: fib6_rules: flush route cache when rule is changed
  (git-fixes).
- commit ae4c044

- ipv6: properly combine dev_base_seq and ipv6.dev_addr_genid
  (git-fixes).
- ipv6: Ensure natural alignment of const ipv6 loopback and
  router addresses (git-fixes).
- commit 3e6f7bb

- net: ipv6: support reporting otherwise unknown prefix flags
  in RTM_NEWPREFIX (git-fixes).
- ipv6: fix potential NULL deref in fib6_add() (git-fixes).
- ipv6: avoid atomic fragment on GSO packets (git-fixes).
- ipv6: remove hard coded limitation on ipv6_pinfo (git-fixes).
- commit aab80f1

- x86/microcode/intel: Rework intel_find_matching_signature() (git-fixes).
- commit a8e1ba8

- x86/microcode/intel: Reuse intel_cpu_collect_info() git-fixes).
- commit 12d10b3

- x86/microcode/intel: Rework intel_cpu_collect_info() (git-fixes).
- commit 44d31ee

- x86/microcode/intel: Unify microcode apply() functions (git-fixes).
- Refresh
  patches.suse/x86-microcode-intel-Remove-unnecessary-cache-writeback-and.patch.
- commit fd684d8

- x86/microcode/intel: Switch to kvmalloc() (git-fixes).
- commit deae801

- x86/microcode/intel: Save the microcode only after a successful late-load (git-fixes).
- commit c89162d

- x86/microcode/intel: Simplify early loading (git-fixes).
- commit 571e4fe

- x86/microcode/intel: Cleanup code further (git-fixes).
- commit 53a643e

- x86/microcode/32: Move early loading after paging enable (git-fixes).
- commit f3beb78

- x86/boot/32: Temporarily map initrd for microcode loading (git-fixes).
- commit f25c748

- x86/microcode: Provide CONFIG_MICROCODE_INITRD32 (git-fixes).
- commit 040895c

- x86/boot/32: Restructure mk_early_pgtbl_32() (git-fixes).
- commit bf7e36d

- x86/boot/32: De-uglify the 2/3 level paging difference in mk_early_pgtbl_32() (git-fixes).
- commit cb4b02a

- x86/boot: Use __pa_nodebug() in mk_early_pgtbl_32() (git-fixes).
- commit 1ec4661

- x86/boot/32: Disable stackprotector and tracing for mk_early_pgtbl_32() (git-fixes).
- commit 1bef486

- x86/microcode/intel: Simplify and rename generic_load_microcode() (git-fixes).
- commit 7d2da5d

- x86/microcode/intel: Simplify scan_microcode() (git-fixes).
- commit 4164fad

- x86/microcode/intel: Rip out mixed stepping support for Intel CPUs (git-fixes).
- commit 842e778

- x86/microcode/intel: Remove pointless mutex (git-fixes).
- commit d92edaf

- x86/microcode/intel: Remove debug code (git-fixes).
- commit f06da57

- x86/microcode: Move core specific defines to local header (git-fixes).
- Delete
  patches.suse/x86-cpu-Fix-amd_check_microcode-declaration.patch.
- commit 68e5a18

- x86/hyperv: Fix output argument to hypercall that changes page
  visibility (git-fixes).
- x86/hyperv/vtl: Stop kernel from probing VTL0 low memory
  (git-fixes).
- commit d929456

- x86/microcode/intel: Rename get_datasize() since its used externally (git-fixes).
- commit cd4315f

- x86/microcode: Make reload_early_microcode() static (git-fixes).
- commit adc4f73

- x86/microcode: Include vendor headers into microcode.h  (git-fixes).
- Refresh
  patches.suse/platform-x86-intel-ifs-Gen2-scan-image-loading.patch.
- commit 9b8d381

- x86/microcode/intel: Move microcode functions out of cpu/intel.c (git-fixes).
- Refresh
  patches.suse/x86-cpu-intel-Detect-TME-keyid-bits-before-setting-MTRR-ma.patch.
- commit 4e2f346

- x86/microcode: Hide the config knob (git-fixes).
- commit d6f3245

- x86/mm: Remove unused microcode.h include (git-fixes).
- commit 88b351c

- x86/microcode: Remove microcode_mutex (git-fixes).
- commit 9723346

- Revert &amp;quot;wifi: ath11k: support hibernation&amp;quot; (bsc#1207948).
- commit 36caa36

- Revert &amp;quot;wifi: ath11k: restore country code during resume&amp;quot;
  (bsc#1207948).
- commit 18bdb23

- x86/microcode: Sanitize __wait_for_cpus() (git-fixes).
- commit 4a52b36

- x86/platform/olpc: Remove unused variable 'len' in olpc_dt_compatible_match() (git-fixes).
- commit a5f84ff

- x86/entry: Add __init to ia32_emulation_override_cmdline() (git-fixes).
- commit e6ba4df

- x86/coco: Replace 'static const cc_mask' with the newly introduced  cc_get_mask() function (git-fixes).
- commit c13c7b0

- x86/usercopy: Fix kernel-doc func param name in clean_cache_range()'s  description (git-fixes).
- commit 8e4bd72

- x86/fpu: Fix guest FPU state buffer allocation size (git-fixes).
- commit 0180053

- media: vim2m: print device name after registering device
  (git-fixes).
- media: platform: stm32: Add check for clk_enable() (git-fixes).
- media: siano: Fix error handling in smsdvb_module_init()
  (git-fixes).
- media: v4l2-dv-timings: prevent possible overflow in
  v4l2_detect_gtf() (git-fixes).
- media: venus: hfi: add a check to handle OOB in sfr region
  (git-fixes).
- media: venus: hfi: add check to handle incorrect queue size
  (git-fixes).
- media: venus: hfi_parser: refactor hfi packet parsing logic
  (git-fixes).
- media: venus: hfi_parser: add check to avoid out of bound access
  (git-fixes).
- media: visl: Fix ERANGE error when setting enum controls
  (git-fixes).
- media: platform: allgro-dvt: unregister v4l2_device on the
  error path (git-fixes).
- media: verisilicon: HEVC: Initialize start_bit field
  (git-fixes).
- media: i2c: adv748x: Fix test pattern selection mask
  (git-fixes).
- media: i2c: ov7251: Introduce 1 ms delay between regulators
  and en GPIO (git-fixes).
- media: i2c: ov7251: Set enable GPIO low in probe (git-fixes).
- media: i2c: ccs: Set the device's runtime PM status correctly
  in remove (git-fixes).
- media: streamzap: prevent processing IR data on URB failure
  (git-fixes).
- media: streamzap: fix race between device disconnection and
  urb callback (git-fixes).
- auxdisplay: panel: Fix an API misuse in panel.c (git-fixes).
- mmc: omap: Fix memory leak in mmc_omap_new_slot (git-fixes).
- memstick: rtsx_usb_ms: Fix slab-use-after-free in
  rtsx_usb_ms_drv_remove (git-fixes).
- mmc: sdhci-omap: Disable MMC_CAP_AGGRESSIVE_PM for eMMC/SD
  (git-fixes).
- spi: cadence-qspi: Fix probe on AM62A LP SK (git-fixes).
- thermal: int340x: Add NULL check for adev (git-fixes).
- PM: sleep: Fix handling devices with direct_complete set on
  errors (git-fixes).
- PM: sleep: Adjust check before setting power.must_resume
  (git-fixes).
- selftests/x86/syscall: Fix coccinelle WARNING recommending
  the use of ARRAY_SIZE() (git-fixes).
- commit d741ce2

- smb: client: Add check for next_buffer in receive_encrypted_standard() (CVE-2025-21844 bsc#1239512)
- commit 5413aee

- smb: client: destroy cfid_put_wq on module exit (git-fixes).
- commit c180144

- ipv6: mcast: extend RCU protection in igmp6_send()
  (CVE-2025-21759 bsc#1238738).
- commit 400a352

- ndisc: extend RCU protection in ndisc_send_skb() (CVE-2025-21760
  bsc#1238763).
- commit 156bf64

- vrf: use RCU protection in l3mdev_l3_out() (CVE-2025-21791
  bsc#1238512).
- commit f01aefb

- openvswitch: use RCU protection in ovs_vport_cmd_fill_info()
  (CVE-2025-21761 bsc#1238775).
- commit 742de46

- arp: use RCU protection in arp_xmit() (CVE-2025-21762
  bsc#1238780).
- commit 816de2a

- neighbour: use RCU protection in __neigh_notify()
  (CVE-2025-21763 bsc#1237897).
- commit f8fc7e4

- ndisc: use RCU protection in ndisc_alloc_skb() (bsc#1239994).
- commit d3f8de7

- ndisc: ndisc_send_redirect() must use dev_get_by_index_rcu()
  (bsc#1239994).
- commit 60e0c13

- x86/cpu/intel: Detect TME keyid bits before setting MTRR mask registers (git-fixes).
- commit 8abe0aa

- x86/cpu: Allow reducing x86_phys_bits during early_identify_cpu() (git-fixes).
- commit 095440f

- intel_idle: Add ibrs_off module parameter to force-disable IBRS (git-fixes).
- commit c35924e

- intel_idle: Use __update_spec_ctrl() in intel_idle_ibrs() (git-fixes).
- Refresh
  patches.suse/x86-Fix-CPUIDLE_FLAG_IRQ_ENABLE-leaking-timer-reprogram.patch.
- commit d3998f0

- x86/idle: Disable IBRS when CPU is offline to improve single-threaded  performance (git-fixes).
- commit 317b615

- x86/speculation: Add __update_spec_ctrl() helper (git-fixes).
- commit 3276cd3

- lockdep: Don't disable interrupts on RT in
  disable_irq_nosync_lockdep.*() (git-fixes).
- kbuild: hdrcheck: fix cross build with clang (git-fixes).
- commit 77968cd

- ipv6: Use RCU in ip6_input() (bsc#1239994).
- commit 29ec493

- ipv6: icmp: convert to dev_net_rcu() (bsc#1239994).
- commit 4c35517

- flow_dissector: use RCU protection to fetch dev_net()
  (bsc#1239994).
- commit a0e50a6

- ipv6: use RCU protection in ip6_default_advmss() (CVE-2025-21765
  bsc#1237906).
- commit c531d1f

- ipv4: use RCU protection in rt_is_expired() (bsc#1239994).
- commit 48756fc

- ipv4: use RCU protection in ipv4_default_advmss() (bsc#1239994).
- commit 81b29a5

- ipv4: use RCU protection in inet_select_addr() (bsc#1239994).
- commit 5eecff1

- ipv4: use RCU protection in ip_dst_mtu_maybe_forward()
  (bsc#1239994).
- commit 6188164

- ipv4: use RCU protection in __ip_rt_update_pmtu()
  (CVE-2025-21766 bsc#1238754).
- commit 03eaa8b

- ipv4: add RCU protection to ip4_dst_hoplimit() (bsc#1239994).
- commit 95bdee3

- net: add dev_net_rcu() helper (bsc#1239994).
- commit 63dac1b

- net: mana: Support holes in device list reply msg (git-fixes).
- net: mana: cleanup mana struct after debugfs_remove()
  (git-fixes).
- Drivers: hv: vmbus: Don't release fb_mmio resource in
  vmbus_free_mmio() (git-fixes).
- clockevents/drivers/i8253: Fix stop sequence for timer 0
  (git-fixes).
- commit a640830

- rpm/kernel-binary.spec.in: Fix missing 20-kernel-default-extra.conf (bsc#1239986)
  sle_version was obsoleted for SLE16.  It has to be combined with
  suse_version check.
- commit cbd5de3

- kABI workaround for intel-ish-hid (git-fixes).
- commit c1e0e59

- HID: intel-ish-hid: Send clock sync message immediately after
  reset (stable-fixes).
- commit bb56845

- kABI workaround for soc_mixer_control changes (git-fixes).
- commit 41b23df

- i2c: amd-mp2: drop free_irq() of devm_request_irq() allocated
  irq (git-fixes).
- USB: serial: ftdi_sio: add support for Altera USB Blaster 3
  (stable-fixes).
- USB: serial: option: fix Telit Cinterion FE990A name
  (stable-fixes).
- USB: serial: option: add Telit Cinterion FE990B compositions
  (stable-fixes).
- USB: serial: option: match on interface class for Telit FN990B
  (stable-fixes).
- Input: i8042 - swap old quirk combination with new quirk for
  more devices (stable-fixes).
- Input: i8042 - swap old quirk combination with new quirk for
  several devices (stable-fixes).
- Input: i8042 - add required quirks for missing old boardnames
  (stable-fixes).
- Input: i8042 - swap old quirk combination with new quirk for
  NHxxRZQ (stable-fixes).
- Input: xpad - rename QH controller to Legion Go S
  (stable-fixes).
- Input: xpad - add support for TECNO Pocket Go (stable-fixes).
- Input: xpad - add support for ZOTAC Gaming Zone (stable-fixes).
- Input: xpad - add multiple supported devices (stable-fixes).
- Input: xpad - add 8BitDo SN30 Pro, Hyperkin X91 and Gamesir
  G7 SE controllers (stable-fixes).
- ASoC: ops: Consistently treat platform_max as control value
  (git-fixes).
- drm/i915/cdclk: Do cdclk post plane programming later
  (stable-fixes).
- drm/atomic: Filter out redundant DPMS calls (stable-fixes).
- drm/amd/display: Assign normalized_pix_clk when color depth =
  14 (stable-fixes).
- drm/amd/display: Restore correct backlight brightness after
  a GPU reset (stable-fixes).
- drm/amd/display: Disable unneeded hpd interrupts during dm_init
  (stable-fixes).
- drm/hyperv: Fix address space leak when Hyper-V DRM device is
  removed (git-fixes).
- HID: apple: disable Fn key handling on the Omoton KB066
  (git-fixes).
- drm/nouveau: Do not override forced connector status
  (stable-fixes).
- drm/vkms: Round fixp2int conversion in lerp_u16 (stable-fixes).
- ASoC: tas2764: Set the SDOUT polarity correctly (stable-fixes).
- ASoC: tas2764: Fix power control mask (stable-fixes).
- ASoC: tas2770: Fix volume scale (stable-fixes).
- net: wwan: mhi_wwan_mbim: Silence sequence number glitch errors
  (stable-fixes).
- ASoC: SOF: amd: Handle IPC replies before FW_BOOT_COMPLETE
  (stable-fixes).
- ASoC: SOF: Intel: hda: add softdep pre to snd-hda-codec-hdmi
  module (stable-fixes).
- ASoC: arizona/madera: use fsleep() in up/down DAPM event delays
  (stable-fixes).
- usb: phy: generic: Use proper helper for property detection
  (stable-fixes).
- platform/x86: thinkpad_acpi: Support for V9 DYTC platform
  profiles (stable-fixes).
- platform/x86: thinkpad_acpi: Fix invalid fan speed on ThinkPad
  X120e (stable-fixes).
- HID: apple: fix up the F6 key on the Omoton KB066 keyboard
  (stable-fixes).
- HID: hid-apple: Apple Magic Keyboard a3203 USB-C support
  (stable-fixes).
- HID: topre: Fix n-key rollover on Realforce R3S TKL boards
  (stable-fixes).
- HID: ignore non-functional sensor in HP 5MP Camera
  (stable-fixes).
- HID: intel-ish-hid: fix the length of MNG_SYNC_FW_CLOCK in
  doorbell (stable-fixes).
- ACPI: resource: IRQ override for Eluktronics MECH-17
  (stable-fixes).
- vboxsf: fix building with GCC 15 (stable-fixes).
- platform/x86/intel: pmc: fix ltr decode in pmc_core_ltr_show()
  (stable-fixes).
- commit 3767537

- regulator: dummy: force synchronous probing (git-fixes).
- regulator: core: Fix deadlock in create_regulator() (git-fixes).
- commit 74ce27f

- libperf cpumap: Grow array of read CPUs in smaller increments
  (bsc#1234698 jsc#PED-12309).
- libperf cpumap: Remove use of perf_cpu_map__read() (bsc#1234698
  jsc#PED-12309).
- perf pmu: Remove use of perf_cpu_map__read() (bsc#1234698
  jsc#PED-12309).
- libperf cpumap: Be tolerant of newline at the end of a cpumask
  (bsc#1234698 jsc#PED-12309).
- libperf cpumap: Hide/reduce scope of MAX_NR_CPUS (bsc#1234698
  jsc#PED-12309).
- perf cpumap: Reduce transitive dependencies on libperf
  MAX_NR_CPUS (bsc#1234698 jsc#PED-12309).
- perf: Increase MAX_NR_CPUS to 4096 (bsc#1234698 jsc#PED-12309).
- libperf cpumap: Ensure empty cpumap is NULL from alloc
  (bsc#1234698 jsc#PED-12309).
- libperf cpumap: Rename perf_cpu_map__empty() to
  perf_cpu_map__has_any_cpu_or_is_empty() (bsc#1234698
  jsc#PED-12309).
- libperf cpumap: Rename perf_cpu_map__default_new() to
  perf_cpu_map__new_online_cpus() and prefer sysfs (bsc#1234698
  jsc#PED-12309).
- libperf cpumap: Rename perf_cpu_map__dummy_new() to
  perf_cpu_map__new_any_cpu() (bsc#1234698 jsc#PED-12309).
- commit b89838c

- Refresh
  patches.suse/udp-Deal-with-race-between-UDP-socket-address-change-and-r.patch.
- commit 4648743

- tools: move alignment-related macros to new &amp;lt;linux/align.h&amp;gt; (git-fixes).
  Fix tools/ build breakage introduced by suse commit 3d6cb93162fd
  &amp;quot;bitmap: introduce generic optimized bitmap_size() (git-fixes)&amp;quot;
- commit a17c3c2

- memblock tests: fix warning: &amp;quot;__ALIGN_KERNEL&amp;quot; redefined (git-fixes).
  Fix tools/ build breakage introduced by suse commit 3d6cb93162fd
  &amp;quot;bitmap: introduce generic optimized bitmap_size() (git-fixes)&amp;quot;
- commit 2860902

- kABI: ufshcd: add ufshcd_dealloc_host back (CVE-2025-21739
  bsc#1238506).
- commit 722da19

- KVM: Explicitly verify target vCPU is online in  kvm_get_vcpu()
  (CVE-2024-58083 bsc#1239036).
- commit bbd863b

- nfp: bpf: Add check for nfp_app_ctrl_msg_alloc() (CVE-2025-21848
  bsc#1239479).
- commit bd498df

- ACPI: processor: idle: Return an error if both P_LVL{2,3}
  idle states are invalid (bsc#1237530).
- commit f46ae1f

- udp: Deal with race between UDP socket address change and rehash
  (CVE-2024-57974 bsc#1238532).
- commit d248d8d

- drm/radeon: fix uninitialized size issue in
  radeon_vce_cs_parse() (git-fixes).
- gpu: host1x: Do not assume that a NULL domain means no DMA IOMMU
  (git-fixes).
- accel/qaic: Fix integer overflow in qaic_validate_req()
  (git-fixes).
- accel/qaic: Fix possible data corruption in BOs &amp;gt; 2G
  (git-fixes).
- drm/v3d: Don't run jobs that have errors flagged in its fence
  (git-fixes).
- drm/sched: Fix fence reference count leak (git-fixes).
- batman-adv: Ignore own maximum aggregation size during RX
  (git-fixes).
- Bluetooth: hci_event: Fix connection regression between LE
  and non-LE adapters (git-fixes).
- Bluetooth: Fix error code in chan_alloc_skb_cb() (git-fixes).
- can: flexcan: disable transceiver during system PM (git-fixes).
- can: flexcan: only change CAN state when link up in system PM
  (git-fixes).
- can: rcar_canfd: Fix page entries in the AFL list (git-fixes).
- can: ucan: fix out of bound read in strscpy() source
  (git-fixes).
- mmc: sdhci-brcmstb: add cqhci suspend/resume to PM ops
  (git-fixes).
- mmc: atmel-mci: Add missing clk_disable_unprepare() (git-fixes).
- commit fa047d8

- RDMA/hns: Fix wrong value of max_sge_rd (git-fixes)
- commit be0fccb

- RDMA/hns: Fix missing xa_destroy() (git-fixes)
- commit 7560f3b

- RDMA/hns: Fix a missing rollback in error path of hns_roce_create_qp_common() (git-fixes)
- commit fae22e5

- RDMA/hns: Fix unmatched condition in error path of alloc_user_qp_db() (git-fixes)
- commit 4a61cfc

- RDMA/hns: Fix soft lockup during bt pages loop (git-fixes)
- commit d7a5712

- RDMA/bnxt_re: Avoid clearing VLAN_ID mask in modify qp path (git-fixes)
- commit 1c0ffc5

- RDMA/mlx5: Handle errors returned from mlx5r_ib_rate() (git-fixes)
- commit fb56cee

- RDMA/bnxt_re: Add missing paranthesis in map_qp_id_to_tbl_indx (git-fixes)
- commit d9ad94d

- RDMA/rxe: Fix the failure of ibv_query_device() and ibv_query_device_ex() tests (git-fixes)
- commit 3a68d14

- scsi: ufs: core: Fix use-after free in init error and remove
  paths (CVE-2025-21739 bsc#1238506).
- commit f971898

- btrfs: use a separate end_io handler for extent_buffer writing
  (bsc#1239045).
- btrfs: don't use btrfs_bio_ctrl for extent buffer writing
  (bsc#1239045).
- btrfs: remove the mirror_num argument to
  btrfs_submit_compressed_read (bsc#1239045).
- btrfs: subpage: fix error handling in
  end_bio_subpage_eb_writepage (bsc#1239045).
- commit 5ca42b7

- ata: sata_highbank: fix OF node reference leak in
  highbank_initialize_phys() (git-fixes).
- commit a7b4ac3

- ata: sata_sil: Rename sil_blacklist to sil_quirks (git-fixes).
- commit c17a6ef

- ata: pata_serverworks: Do not use the term blacklist
  (git-fixes).
- commit cdc9008

- ata: libata-scsi: Check ATA_QCFLAG_RTF_FILLED before using
  result_tf (git-fixes).
- commit cf84546

- ata: libata-scsi: Remove redundant sense_buffer memsets
  (git-fixes).
- commit 3ff83f7

- ata: ahci: Add mask_port_map module parameter (git-fixes).
- commit f3d1fc7

- ata: pata_parport: fit3: implement IDE command set registers
  (git-fixes).
- commit b753758

- arm64: dts: rockchip: fix pinmux of UART5 for PX30 Ringneck on Haikou (git-fixes)
- commit e6786aa

- ata: pata_parport: add custom version of wait_after_reset
  (git-fixes).
- commit 92ba445

- arm64: dts: rockchip: Add missing PCIe supplies to RockPro64 board (git-fixes)
- commit d1b0425

- arm64: dts: rockchip: Add avdd HDMI supplies to RockPro64 board dtsi (git-fixes)
- commit b541e7c

- arm64: dts: rockchip: Remove undocumented sdmmc property from (git-fixes)
- commit 4d05cf3

- arm64: dts: rockchip: fix pinmux of UART0 for PX30 Ringneck on Haikou (git-fixes)
- commit cfcc878

- arm64: dts: freescale: imx8mm-verdin-dahlia: add Microphone Jack to (git-fixes)
- commit e1ac37c

- arm64: dts: freescale: tqma8mpql: Fix vqmmc-supply (git-fixes)
- commit 86fe977

- arm64: mm: Populate vmemmap at the page level if not section aligned (git-fixes)
- commit 9a15b23

- arm64: dts: rockchip: add rs485 support on uart5 of (git-fixes)
- commit 674715a

- mm: zswap: move allocations during CPU init outside the lock
  (git-fixes).
- commit 4a03990

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

- iommu/vt-d: Fix suspicious RCU usage (git-fixes).
- commit 57c0aea

- net_sched: sch_sfq: handle bigger packets (git-fixes).
- Refresh
  patches.suse/net_sched-sch_sfq-don-t-allow-1-packet-limit.patch.
- commit e8a43b7

- net/sched: act_api: rely on rcu in tcf_idr_check_alloc
  (git-fixes).
- Refresh
  patches.suse/net-sched-act_api-fix-possible-infinite-loop-in-tcf_.patch.
- commit b0f7ecb

- net_sched: Prevent creation of classes with TC_H_ROOT
  (git-fixes).
- net/sched: cls_api: fix error handling causing NULL dereference
  (git-fixes CVE-2025-21857 bsc#1239478).
- net/sched: netem: account for backlog updates from child qdisc
  (git-fixes CVE-2024-56770 bsc#1235637).
- net/sched: tbf: correct backlog statistic for GSO packets
  (git-fixes).
- net/sched: cbs: Fix integer overflow in cbs_set_port_rate()
  (git-fixes).
- net/sched: act_api: deny mismatched skip_sw/skip_hw flags for
  actions created by classifiers (git-fixes).
- net/sched: taprio: make q-&amp;gt;picos_per_byte available to
  fill_sched_entry() (git-fixes).
- net/sched: adjust device watchdog timer to detect stopped
  queue at right time (git-fixes).
- net_sched: sch_sfq: annotate data-races around q-&amp;gt;perturb_period
  (git-fixes).
- net/sched: flower: Add lock protection when remove filter handle
  (git-fixes).
- net/sched: cls_u32: replace int refcounts with proper refcounts
  (git-fixes).
- commit a5cca5e

- powerpc/pseries/eeh: move pseries_eeh_err_inject() outside
  CONFIG_DEBUG_FS block (bsc#1239573).
- powerpc/pseries/eeh: Fix pseries_eeh_err_inject (bsc#1239573).
- powerpc: Stop using no_llseek (bsc#1239573).
- commit 5b9a0f5

- wifi: rtl8xxxu: Perform update_beacon_work when beaconing is
  enabled (git-fixes).
- commit 39d5ea8

- kABI fix for netlink: terminate outstanding dump on socket close
  (git-fixes).
- commit b2fd571

- usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c
  (bsc#1232389 CVE-2024-50056).
- commit e07e4ef

- netlink: terminate outstanding dump on socket close
  (CVE-2024-53140 bsc#1234222).
- net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT
  (CVE-2024-53057 bsc#1233551).
- commit b824575

- usb: gadget: uvc: fix try format returns on uncompressed formats
  (bsc#1232389 CVE-2024-50056).
- commit d2b161f

- mm: zswap: properly synchronize freeing resources during CPU
  hotunplug (bsc#1237029 CVE-2025-21693).
- commit 215e0dc

- series.conf: temporarily disable patches.suse/md-md-bitmap-fix-writing-non-bitmap-pages-ab99.patch (bsc#1238212)
- commit bc1d649

- initramfs: fix hardlink hash leak without TRAILER (bsc#1232848).
- initramfs: allocate heap buffers together (bsc#1232848).
- init: add initramfs_internal.h (bsc#1232848).
- commit f42c132

- net: stmmac: fix TSO DMA API usage causing oops (CVE-2024-56719 bsc#1235591)
- commit 66963e5

- Documentation: qat: fix auto_reset attribute details (git-fixes).
- Documentation: qat: fix auto_reset section (git-fixes).
- commit f832e33

- supported.conf: add now-included qat_420xx (external, intel)
- commit 85940df

- net: constify sk_dst_get() and __sk_dst_get() argument
  (git-fixes).
- commit a24981b

- crypto: qat - Fix missing destroy_workqueue in adf_init_aer() (jsc#PED-12416).
- crypto: qat - Fix typo &amp;quot;accelaration&amp;quot; (jsc#PED-12416).
- crypto: qat - Constify struct pm_status_row (jsc#PED-12416).
- crypto: qat - remove unused adf_devmgr_get_first (jsc#PED-12416).
- crypto: qat/qat_420xx - fix off by one in uof_get_name() (jsc#PED-12416).
- crypto: iaa - Remove potential infinite loop in check_completion() (jsc#PED-12416).
- crypto: qat - Remove trailing space after \n newline (jsc#PED-12416).
- crypto: qat - fix &amp;quot;Full Going True&amp;quot; macro definition (jsc#PED-12416).
- crypto: qat - Use static_assert() to check struct sizes (jsc#PED-12416).
- crypto: qat - allow disabling SR-IOV VFs (jsc#PED-12416).
- crypto: qat - ensure correct order in VF restarting handler (jsc#PED-12416).
- crypto: qat - fix recovery flow for VFs (jsc#PED-12416).
- crypto: qat - preserve ADF_GENERAL_SEC (jsc#PED-12416).
- crypto: qat - initialize user_input.lock for rate_limiting (jsc#PED-12416).
- crypto: qat - make adf_ctl_class constant (jsc#PED-12416).
- crypto: qat - Fix typo (jsc#PED-12416).
- crypto: qat - fix linking errors when PCI_IOV is disabled (jsc#PED-12416).
- crypto: iaa - Use kmemdup() instead of kzalloc() and memcpy() (jsc#PED-12416).
- crypto: qat - validate slices count returned by FW (jsc#PED-12416).
- crypto: qat - improve error message in adf_get_arbiter_mapping() (jsc#PED-12416).
- crypto: qat - implement dh fallback for primes &amp;gt; 4K (jsc#PED-12416).
- crypto: iaa - Use cpumask_weight() when rebalancing (jsc#PED-12416).
- crypto: qat - Fix spelling mistake &amp;quot;Invalide&amp;quot; -&amp;gt; &amp;quot;Invalid&amp;quot; (jsc#PED-12416).
- crypto: qat - Avoid -Wflex-array-member-not-at-end warnings (jsc#PED-12416).
- crypto: iaa - Change iaa statistics to atomic64_t (jsc#PED-12416).
- crypto: iaa - Add global_stats file and remove individual stat files (jsc#PED-12416).
- crypto: iaa - Remove comp/decomp delay statistics (jsc#PED-12416).
- crypto: iaa - fix decomp_bytes_in stats (jsc#PED-12416).
- crypto: qat - implement interface for live migration (jsc#PED-12416).
- crypto: qat - add interface for live migration (jsc#PED-12416).
- crypto: qat - add bank save and restore flows (jsc#PED-12416).
- crypto: qat - expand CSR operations for QAT GEN4 devices (jsc#PED-12416).
- crypto: qat - rename get_sla_arr_of_type() (jsc#PED-12416).
- crypto: qat - relocate CSR access code (jsc#PED-12416).
- crypto: qat - move PFVF compat checker to a function (jsc#PED-12416).
- crypto: qat - relocate and rename 4xxx PF2VM definitions (jsc#PED-12416).
- crypto: qat - adf_get_etr_base() helper (jsc#PED-12416).
- crypto: iaa - fix the missing CRYPTO_ALG_ASYNC in cra_flags (jsc#PED-12416).
- crypto: iaa - Fix comp/decomp delay statistics (jsc#PED-12416).
- crypto: qat - make ring to service map common for QAT GEN4 (jsc#PED-12416).
- crypto: qat - fix ring to service map for dcc in 420xx (jsc#PED-12416).
- crypto: qat - fix comment structure (jsc#PED-12416).
- crypto: qat - remove unnecessary description from comment (jsc#PED-12416).
- crypto: qat - uninitialized variable in adf_hb_error_inject_write() (jsc#PED-12416).
- crypto: qat - improve aer error reset handling (jsc#PED-12416).
- crypto: qat - limit heartbeat notifications (jsc#PED-12416).
- crypto: qat - add auto reset on error (jsc#PED-12416).
- crypto: qat - add fatal error notification (jsc#PED-12416).
- crypto: qat - re-enable sriov after pf reset (jsc#PED-12416).
- crypto: qat - update PFVF protocol for recovery (jsc#PED-12416).
- crypto: qat - disable arbitration before reset (jsc#PED-12416).
- crypto: qat - add fatal error notify method (jsc#PED-12416).
- crypto: qat - add heartbeat error simulator (jsc#PED-12416).
- crypto: qat - use kcalloc_node() instead of kzalloc_node() (jsc#PED-12416).
- crypto: iaa - Remove unnecessary debugfs_create_dir() error check in iaa_crypto_debugfs_init() (jsc#PED-12416).
- crypto: iaa - Remove header table code (jsc#PED-12416).
- crypto: qat - avoid memcpy() overflow warning (jsc#PED-12416).
- crypto: qat - fix arbiter mapping generation algorithm for QAT 402xx (jsc#PED-12416).
- crypto: qat - generate dynamically arbiter mappings (jsc#PED-12416).
- crypto: qat - add support for ring pair level telemetry (jsc#PED-12416).
- commit 5d1d9ed

- crypto: qat - add support for device telemetry (jsc#PED-12416). - Refresh patches.suse/crypto-qat-disable-IOV-in-adf_dev_stop.patch. - Refresh patches.suse/crypto-qat-remove-check-after-debugfs_create_dir.patch.
- commit 3d131da

- crypto: qat - add admin msgs for telemetry (jsc#PED-12416).
- crypto: qat - include pci.h for GET_DEV() (jsc#PED-12416).
- crypto: iaa - remove unneeded semicolon (jsc#PED-12416).
- crypto: iaa - Remove unneeded newline in update_max_adecomp_delay_ns() (jsc#PED-12416).
- crypto: iaa - Change desc-&amp;gt;priv to 0 (jsc#PED-12416).
- crypto: qat - add support for 420xx devices (jsc#PED-12416).
- crypto: qat - move fw config related structures (jsc#PED-12416).
- crypto: qat - relocate portions of qat_4xxx code (jsc#PED-12416).
- crypto: qat - change signature of uof_get_num_objs() (jsc#PED-12416).
- seq_file: add helper macro to define attribute for rw file (jsc#PED-12416).
- commit 8fbb076

- Update config files for PED-12416: QAT_420XX=m on x86, disable error injection.
- commit bbce3cc

- mm/zswap: change per-cpu mutex and buffer to per-acomp_ctx
  (bsc#1237029 CVE-2025-21693).
- commit 0b762e3

- usb: gadget: uvc: Fix use-after-free for inflight usb_requests
  (bsc#1232389 CVE-2024-50056).
- commit 2525765

- usb: gadget: uvc: move video disable logic to its own function
  (bsc#1232389 CVE-2024-50056).
- commit 2ceecdc

- usb: gadget: uvc: Allocate uvc_requests one at a time
  (bsc#1232389 CVE-2024-50056).
- commit 4e4b74d

- usb: gadget: uvc: prevent use of disabled endpoint (bsc#1232389
  CVE-2024-50056).
- commit fe7e829

- usb: gadget: uvc: clean up comments and styling in video_pump
  (bsc#1232389 CVE-2024-50056).
- commit c00889e

- Bluetooth: Improve setsockopt() handling of malformed user input
  (git-fixes).
- commit b7abeef

- btrfs: drop the backref cache during relocation if we commit
  (bsc#1239605).
- btrfs: check delayed refs when we're checking if a ref exists
  (bsc#1239605).
- commit cfc9247

- xhci: dbc: Fix STALL transfer event handling (git-fixes).
- commit cae0f76

- Update
  patches.suse/net-sched-use-RCU-read-side-critical-section-in-taprio_dump.patch
  (CVE-2024-50126 bsc#1232895).
- commit 4fbfb83

- xhci: dbc: Replace custom return value with proper Linux error
  code (git-fixes).
- commit 8f2f3fe

- xhci: dbc: Check for errors first in xhci_dbc_stop()
  (git-fixes).
- commit 393eaad

- xhci: dbc: Use ATTRIBUTE_GROUPS() (git-fixes).
- commit c847619

- xhci: dbc: Use sysfs_emit() to instead of scnprintf()
  (git-fixes).
- commit fdc638e

- xhci: dbc: Convert to use sysfs_streq() (git-fixes).
- commit de56eef

- xhci: dbc: Drop duplicate checks for dma_free_coherent()
  (git-fixes).
- commit b4ff421

- Update
  patches.suse/xhci-Combine-two-if-statements-for-Etron-xHCI-host.patch
  (git-fixes).
- Update
  patches.suse/xhci-Don-t-issue-Reset-Device-command-to-Etron-xHCI-.patch
  (git-fixes).
  Fix false references introduced by reusing patches for SP7 needed
  for a feature
- commit f1a52b1

- ila: serialize calls to nf_register_net_hooks() (CVE-2024-57900
  bsc#1235973).
- commit a940895

- efi/libstub: Bump up EFI_MMAP_NR_SLACK_SLOTS to 32
  (bsc#1239349).
- commit 4c2eac0

- kABI fix for tcp: replace tcp_time_stamp_raw() (git-fixes).
- kABI fix for tcp: fix cookie_init_timestamp() overflows
  (git-fixes).
- commit e3c259b

- ubi: Add a check for ubi_num (git-fixes).
- ubi: fastmap: wl: Schedule fm_work if wear-leveling pool is
  empty (git-fixes).
- ubi: wl: Put source PEB into correct list if trying locking
  LEB failed (git-fixes).
- ubi: block: fix null-pointer-dereference in ubiblock_create()
  (git-fixes).
- ubi: eba: properly rollback inside self_check_eba (git-fixes).
- ubi: correct the calculation of fastmap size (stable-fixes).
- ubi: block: Fix use-after-free in ubiblock_cleanup (git-fixes).
- ubi: fastmap: may_reserve_for_fm: Don't reserve PEB if fm_anchor
  exists (git-fixes).
- ubi: fastmap: Fix missed ec updating after erasing old fastmap
  data block (git-fixes).
- commit 123f0f1

- soc: qcom: pdr: Fix the potential deadlock (git-fixes).
- firmware: imx-scu: fix OF node leak in .probe() (git-fixes).
- commit cbadc13

- tcp: introduce tcp_clock_ms() (git-fixes).
- commit ef89ad4

- include/linux/mmzone.h: clean up watermark accessors
  (bsc#1239600).
- commit 9cc8558

- mm: create promo_wmark_pages and clean up open-coded sites
  (bsc#1239600).
- commit 9684a94

- tcp: process the 3rd ACK with sk_socket for TFO/MPTCP
  (git-fixes).
- tcp: reduce accepted window in NEW_SYN_RECV state (git-fixes).
- tcp: replace tcp_time_stamp_raw() (git-fixes).
- commit 3bc54d8

- mm: accept to promo watermark (bsc#1239600).
- commit 1ee3b42

- mm: fix endless reclaim on machines with unaccepted memory
  (bsc#1239600).
- commit 2f9ff68

- dm-flakey: Fix memory corruption in optional corrupt_bio_byte
  feature (git-fixes).
- commit a688092

- kABI fix for tcp: drop secpath at the same time as we currently
  drop (CVE-2025-21864 bsc#1239482).
- commit 79a237f

- usb: xhci: Enable the TRB overfetch quirk on VIA VL805
  (git-fixes).
- commit f5ad85e

- xhci: pci: Use standard pattern for device IDs (git-fixes).
- Refresh
  patches.suse/xhci-pci-Fix-indentation-in-the-PCI-device-ID-defini.patch.
- commit 6e83d36

- xhci: Don't perform Soft Retry for Etron xHCI host (git-fixes).
- commit 9beb310

- xhci: Don't issue Reset Device command to Etron xHCI host
  (jsc#PED-10701).
- commit 5ad7a28

- xhci: Combine two if statements for Etron xHCI host
  (jsc#PED-10701).
- commit 68c16e1

- xhci: Cleanup Candence controller PCI device and vendor ID usage
  (git-fixes).
- commit df43775

- usb: xHCI: add XHCI_RESET_ON_RESUME quirk for Phytium xHCI host
  (git-fixes).
- commit 1479d30

- usb: xhci: remove 'retval' from xhci_pci_resume() (git-fixes).
- commit 6f73c8c

- xhci: Apply XHCI_RESET_TO_DEFAULT quirk to TGL (git-fixes).
- commit 32a2ce7

- xhci: pci: Use PCI_VENDOR_ID_RENESAS (git-fixes).
- commit 02e0809

- xhci: pci: Group out Thunderbolt xHCI IDs (git-fixes).
- commit 3ebb63d

- xhci: pci: Use full names in PCI IDs for Intel platforms
  (git-fixes).
- commit 38d020d

- ila: call nf_unregister_net_hooks() sooner (CVE-2024-46782
  bsc#1230769).
- commit e9d9715

- Input: iqs7222 - preserve system status register (git-fixes).
- commit 1f2a9a2

- Input: iqs7222 - add support for IQS7222D v1.1 and v1.2
  (git-fixes).
- commit 9ee6aed

- Input: iqs7222 - add support for Azoteq IQS7222D (git-fixes).
- commit 6fedbfd

- Update
  patches.suse/ASoC-SOF-stream-ipc-Check-for-cstream-nullity-in-sof.patch
  (git-fixes CVE-2025-21847 bsc#1239471).
- Update
  patches.suse/HID-multitouch-Add-NULL-check-in-mt_input_configured.patch
  (git-fixes CVE-2024-58020 bsc#1239346).
- Update
  patches.suse/USB-gadget-f_midi-f_midi_complete-to-call-queue_work.patch
  (git-fixes CVE-2025-21859 bsc#1239467).
- Update patches.suse/acct-perform-last-write-from-workqueue.patch
  (git-fixes CVE-2025-21846 bsc#1239508).
- Update
  patches.suse/block-don-t-revert-iter-for-EIOCBQUEUED.patch
  (git-fixes CVE-2025-21832 bsc#1239105).
- Update
  patches.suse/fbdev-omap-use-threaded-IRQ-for-LCD-DMA.patch
  (stable-fixes CVE-2025-21821 bsc#1239174).
- Update
  patches.suse/nfsd-clear-acl_access-acl_default-after-releasing-them.patch
  (git-fixes CVE-2025-21796 bsc#1238716).
- Update
  patches.suse/nvmet-Fix-crash-when-a-namespace-is-disabled.patch
  (git-fixes CVE-2025-21850 bsc#1239477).
- Update
  patches.suse/orangefs-fix-a-oob-in-orangefs_debug_write.patch
  (git-fixes CVE-2025-21782 bsc#1239117).
- Update
  patches.suse/partitions-mac-fix-handling-of-bogus-partition-table.patch
  (git-fixes CVE-2025-21772 bsc#1238911).
- Update
  patches.suse/powerpc-code-patching-Fix-KASAN-hit-by-not-flagging-.patch
  (bsc#1215199 CVE-2025-21866 bsc#1239473).
- commit d74c347

- nvkm/gsp: correctly advance the read pointer of GSP message queue (bsc#1238997 CVE-2024-58019)
- commit 73aa11f

- i2c: sis630: Fix an error handling path in sis630_probe()
  (git-fixes).
- i2c: ali15x3: Fix an error handling path in ali15x3_probe()
  (git-fixes).
- i2c: ali1535: Fix an error handling path in ali1535_probe()
  (git-fixes).
- i2c: omap: fix IRQ storms (git-fixes).
- commit a2963cf

- Input: ads7846 - fix gpiod allocation (git-fixes).
- commit 829ae40

- ASoC: amd: yc: Support mic on another Lenovo ThinkPad E16 Gen
  2 model (stable-fixes).
- ALSA: hda/realtek: Add mute LED quirk for HP Pavilion x360
  14-dy1xxx (stable-fixes).
- commit 10b7907

- ASoC: codecs: wm0010: Fix error handling path in
  wm0010_spi_probe() (git-fixes).
- ASoC: rt722-sdca: add missing readable registers (git-fixes).
- drm/dp_mst: Fix locking when skipping CSN before topology
  probing (git-fixes).
- drm/gma500: Add NULL check for pci_gfx_root in
  mid_get_vbt_data() (git-fixes).
- drm/amd/display: Fix slab-use-after-free on hdcp_work
  (git-fixes).
- commit 866bbeb

- Refresh patches.suse/mptcp-fix-rcv-buffer-auto-tuning.patch.
- Refresh
  patches.suse/mptcp-move-__mptcp_error_report-in-protocol.c.patch.
- Refresh
  patches.suse/tcp-define-initial-scaling-factor-value-as-a-macro.patch.
- Refresh
  patches.suse/tcp-increase-the-default-TCP-scaling-ratio.patch.
  After discussing with @jwiesner: re-introduce b8dc6d6ce (&amp;quot;mptcp: fix rcv
  buffer auto-tuning&amp;quot;)
- commit 2c38df3

- mm/migrate_device: don't add folio to be freed to LRU in
  migrate_device_finalize() (CVE-2025-21861 bsc#1239483).
- commit 2aaf230

- mm: migrate_device: use more folio in migrate_device_finalize()
  (CVE-2025-21861 bsc#1239483 dependency).
- commit 6c15dfd

- geneve: Suppress list corruption splat in
  geneve_destroy_tunnels() (CVE-2025-21858 bsc#1239468).
- gtp: Suppress list corruption splat in gtp_net_exit_batch_rtnl()
  (CVE-2025-21865 bsc#1239481).
- ibmvnic: Don't reference skb after sending to VIOS
  (CVE-2025-21858 bsc#1239468).
- geneve: Fix use-after-free in geneve_find_dev() (CVE-2025-21858
  bsc#1239468).
- commit 37714b5

- drm/amdgpu: Check extended configuration space register when
  system uses large bar (stable-fixes).
- Refresh
  patches.suse/drm-amdgpu-disable-BAR-resize-on-Dell-G5-SE.patch.
- commit 3119f0d

- wifi: cfg80211: cancel wiphy_work before freeing wiphy
  (git-fixes).
- wifi: iwlwifi: mvm: fix PNVM timeout for non-MSI-X platforms
  (git-fixes).
- Bluetooth: hci_event: Fix enabling passive scanning (git-fixes).
- usb: quirks: Add DELAY_INIT and NO_LPM for Prolific Mass
  Storage Card Reader (stable-fixes).
- intel_th: pci: Add Panther Lake-P/U support (stable-fixes).
- intel_th: pci: Add Panther Lake-H support (stable-fixes).
- intel_th: pci: Add Arrow Lake support (stable-fixes).
- mei: me: add panther lake P DID (stable-fixes).
- gpio: rcar: Use raw_spinlock to protect register access
  (stable-fixes).
- platform/x86: thinkpad_acpi: Add battery quirk for ThinkPad
  X131e (stable-fixes).
- drm/radeon: Fix rs400_gpu_init for ATI mobility radeon Xpress
  200M (stable-fixes).
- drm/i915/ddi: Fix HDMI port width programming in DDI_BUF_CTL
  (git-fixes).
- xhci: pci: Fix indentation in the PCI device ID definitions
  (stable-fixes).
- drm/i915/xe2lpd: Move D2D enable/disable (stable-fixes).
- commit afdffc3

- Delete patches.suse/APEI-GHES-Have-GHES-honor-the-panic-setting.patch (bsc#1239615)
  The panic-on-reboot behavior change is too surprsing as an update,
  better to be reverted during SP
- commit 38b0ca3

- nfs: ignore SB_RDONLY when remounting nfs (bsc#1238565).
- commit dbe8ca2

- nfs: clear SB_RDONLY before getting superblock (bsc#1238565).
- commit 41b72ba

- dm-crypt: track tag_offset in convert_context (git-fixes).
- commit e418c3f

- dm-crypt: don't update io-&amp;gt;sector after
  kcryptd_crypt_write_io_submit() (git-fixes).
- commit 4e42a0d

- dm-ebs: don't set the flag DM_TARGET_PASSES_INTEGRITY
  (git-fixes).
- commit d656a3c

- dm-verity FEC: Fix RS FEC repair for roots unaligned to block
  size (take 2) (git-fixes).
  mwilck: some hand editing because d95e2c34a3ca (&amp;quot;dm verity: Fix IO
  priority lost when reading FEC and hash&amp;quot;) is missing
- commit 952c7af

- dm array: fix cursor index when skipping across block boundaries
  (git-fixes).
- commit 9559a70

- dm array: fix unreleased btree blocks on closing a faulty
  array cursor (git-fixes).
- commit 3401ff8

- dm thin: Add missing destroy_work_on_stack() (git-fixes).
- commit b8c64af

- dm: Fix typo in error message (git-fixes).
- commit 085bad2

- dm-unstriped: cast an operand to sector_t to prevent potential
  uint32_t overflow (git-fixes).
- commit 9289690

- Revert &amp;quot;dm: requeue IO if mapping table not yet available&amp;quot;
  (git-fixes).
- commit 5102f1f

- dm-integrity: fix a race condition when accessing recalc_sector
  (git-fixes).
- commit f9223d3

- dm persistent data: fix memory allocation failure (git-fixes).
- commit 6ad0a55

- dm resume: don't return EINVAL when signalled (git-fixes).
- commit b83910f

- dm suspend: return -ERESTARTSYS instead of -EINTR (git-fixes).
- commit d18f8de

- dm-raid: Fix WARN_ON_ONCE check for sync_thread in raid_resume
  (git-fixes).
- commit 6d3fcd8

- dm init: Handle minors larger than 255 (git-fixes).
- commit 73dcd27

- bitmap: introduce generic optimized bitmap_size() (git-fixes).
- commit 3d6cb93

- dm-delay: fix max_delay calculations (git-fixes).
- commit 9bd5588

- dm-delay: fix hung task introduced by kthread mode (git-fixes).
- commit c232aae

- dm-delay: fix workqueue delay_timer race (git-fixes).
- commit d3bc4cb

- dm integrity: fix out-of-range warning (git-fixes).
- commit 94146a8

- dm-integrity: align the outgoing bio in integrity_recheck
  (git-fixes).
- commit 8ef7f34

- tcp: Defer ts_recent changes until req is owned (git-fixes).
- tcp: adjust rcvq_space after updating scaling ratio (git-fixes).
- tcp: Annotate data-race around sk-&amp;gt;sk_mark in tcp_v4_send_reset
  (git-fixes).
- tcp: check space before adding MPTCP SYN options (git-fixes).
- commit 3e8333c

- tcp: fix TFO SYN_RECV to not zero retrans_stamp with retransmits
  out (git-fixes).
- tcp: fix tcp_enter_recovery() to zero retrans_stamp when it's
  safe (git-fixes).
- tcp: fix to allow timestamp undo if no retransmits were sent
  (git-fixes).
- commit 057626d

- tcp: avoid reusing FIN_WAIT2 when trying to find port in
  connect() process (git-fixes).
- commit b709352

- tcp: fix forever orphan socket caused by tcp_abort (git-fixes).
- commit ee5bb6a

- tcp: Update window clamping condition (git-fixes).
- commit 21c2df7

- tcp: Adjust clamping window for applications specifying
  SO_RCVBUF (git-fixes).
- commit 45a6b13

- tcp: Don't drop SYN+ACK for simultaneous connect() (git-fixes).
- commit d347622

- tcp: fix races in tcp_v_err() (git-fixes).
- commit 7d8961a

- tcp: fix races in tcp_abort() (git-fixes).
- commit 57c21f2

- tcp: fix race in tcp_write_err() (git-fixes).
- commit f7c5a0b

- tcp: add tcp_done_with_error() helper (git-fixes).
- commit 67b079b

- tcp: fix incorrect undo caused by DSACK of TLP retransmit
  (git-fixes).
- commit 7fc3dc6

- UPSTREAM: tcp: fix DSACK undo in fast recovery to call
  tcp_try_to_open() (git-fixes).
- commit 481ef49

- tcp: fix tcp_rcv_fastopen_synack() to enter TCP_CA_Loss for
  failed TFO (git-fixes).
- commit e0d6e17

- tcp: clear tp-&amp;gt;retrans_stamp in tcp_rcv_fastopen_synack()
  (git-fixes).
- commit 2f9ac53

- tcp: fix race in tcp_v6_syn_recv_sock() (git-fixes).
- commit debc800

- tcp: count CLOSE-WAIT sockets for TCP_MIB_CURRESTAB (git-fixes).
- commit e578c32

- tcp: remove 64 KByte limit for initial tp-&amp;gt;rcv_wnd value
  (git-fixes).
- commit a0f87a0

- tcp: avoid premature drops in tcp_add_backlog() (git-fixes).
- commit 9d8f16e

- tcp: increase the default TCP scaling ratio (git-fixes).
- commit 37d2a56

- tcp: annotate data-races around tp-&amp;gt;window_clamp (git-fixes).
- Refresh
  patches.suse/mptcp-cope-racing-subflow-creation-in-mptcp_rcv_spac.patch.
- commit baccd3e

- tcp: Fix bind() regression for v6-only wildcard and
  v4(-mapped-v6) non-wildcard addresses (git-fixes).
- commit 10a8fd3

- tcp: Fix NEW_SYN_RECV handling in inet_twsk_purge() (git-fixes).
- commit 2c65748

- tcp: fix incorrect parameter validation in the
  do_tcp_getsockopt() function (git-fixes).
- commit 1b71f1e

- tcp: Add memory barrier to tcp_push() (git-fixes).
- commit 9e18439

- tcp: fix mid stream window clamp (git-fixes).
- commit 1da9c62

- tcp: define initial scaling factor value as a macro (git-fixes).
- Refresh
  patches.suse/tcp-get-rid-of-sysctl_tcp_adv_win_scale.patch.
- Refresh
  patches.suse/tcp-reorganize-tcp_sock-fast-path-variables.patch.
- commit 5d65891

- tcp: fix cookie_init_timestamp() overflows (git-fixes).
- commit 35f4bde

- tcp: derive delack_max from rto_min (git-fixes).
- commit 681cef6

- tcp: check mptcp-level constraints for backlog coalescing
  (git-fixes).
- commit f47afe8

- s390/traps: Fix test_monitor_call() inline assembly (git-fixes
  bsc#1239595).
- commit e1c229c

- s390/stackleak: Use exrl instead of ex in __stackleak_poison()
  (git-fixes bsc#1239594).
- commit bf5ac4c

- s390/ism: add release function for struct device (git-fixes
  CVE-2025-21856 bsc#1239486).
- commit ae9aecd

- tcp: drop secpath at the same time as we currently drop dst
  (CVE-2025-21864 bsc#1239482).
- commit 068f76d

- tcp: properly terminate timers for kernel sockets
  (CVE-2024-35910 bsc#1224489).
- commit cd84ccc

- net: sched: use RCU read-side critical section in taprio_dump()
  (CVE-2024-50140 bsc#1233060).
- commit 481b06f

- spi: microchip-core: Use helper function devm_clk_get_enabled()
  (git-fixes).
- commit ba5bb35

- spi: microchip-core: Clean up redundant dev_err_probe()
  (git-fixes).
- Refresh
  patches.suse/spi-microchip-core-switch-to-use-modern-name.patch.
- commit e92f46c

- net/smc: check iparea_offset and ipv6_prefixes_cnt when
  receiving proposal msg (CVE-2024-49571 bsc#1235733).
- commit d49e720

- kABI: bpf: Prevent tailcall infinite loop caused by freplace
  kABI workaround (bsc#1235712 CVE-2024-47794).
- commit b659789

- bpf: Prevent tailcall infinite loop caused by freplace
  (bsc#1235712 CVE-2024-47794).
- commit 594a2b0

- netdev: prevent accessing NAPI instances from another namespace
  (CVE-2025-21659 bsc#1236206).
- commit 4814e4a

- ice: Remove and readd netdev during devlink reload (bsc#1230497
  bsc#1239518).
- Refresh
  patches.suse/ice-add-ice_adapter-for-shared-data-across-PFs-on-th.patch.
- commit fac3f79

- HID: hid-steam: Fix use-after-free when detaching device
  (git-fixes).
- HID: appleir: Fix potential NULL dereference at raw event handle
  (git-fixes).
- HID: intel-ish-hid: Fix use-after-free issue in
  ishtp_hid_remove() (git-fixes).
- HID: google: fix unused variable warning under !CONFIG_ACPI
  (git-fixes).
- HID: i2c-hid: Skip SET_POWER SLEEP for Cirque touchpad on
  system suspend (stable-fixes).
- commit 66671e7

- pinctrl: bcm281xx: Fix incorrect regmap max_registers value
  (git-fixes).
- commit e9a08e4

- net: mana: Allow variable size indirection table (bsc#1239016).
- Refresh
  patches.suse/net-mana-Enable-debugfs-files-for-MANA-device.patch.
- commit 987aac3

- net: mana: Fix irq_contexts memory leak in mana_gd_setup_irqs
  (bsc#1239015).
- net: mana: Fix memory leak in mana_gd_setup_irqs (bsc#1239015).
- net: mana: Avoid open coded arithmetic (bsc#1239016).
- RDMA/mana_ib: Prefer struct_size over open coded arithmetic
  (bsc#1239016).
- net: mana: Add flex array to struct mana_cfg_rx_steer_req_v2
  (bsc#1239016).
- net: mana: Assigning IRQ affinity on HT cores (bsc#1239015).
- net: mana: add a function to spread IRQs per CPUs (bsc#1239015).
- cpumask: define cleanup function for cpumasks (bsc#1239015).
- cpumask: add cpumask_weight_andnot() (bsc#1239015).
- commit 99e576d

- af_unix: Disable MSG_OOB handling for sockets in
  sockmap/sockhash (bsc#1239435).
- af_unix: Annotate data-race of sk-&amp;gt;sk_state in
  unix_stream_read_skb() (bsc#1239435).
- commit 53fc06a

- padata: fix sysfs store callback check (git-fixes).
- commit 9e53996

- netpoll: Fix race condition in netpoll_owner_active
  (CVE-2024-41005 bsc#1227858).
- commit edbf839

- sched/membarrier: Fix redundant load of membarrier_state
  (bsc#1232743).
- commit 4b4693f

- tools/testing/selftests/bpf/test_tc_tunnel.sh: Fix wait for
  server bind (git-fixes).
- commit acac4ee

- selftests/bpf: Add test case for the freeing of bpf_timer
  (bsc#1238971 CVE-2025-21825).
- bpf: Cancel the running bpf_timer through kworker for PREEMPT_RT
  (bsc#1238971 CVE-2025-21825).
- commit d0cb4f3

- kABI fix for l2tp: prevent possible tunnel refcount underflow
  (CVE-2024-49940 bsc#1232812).
- commit d6225ab

- powerpc/pseries/iommu: memory notifier incorrectly adds TCEs
  for pmemory (bsc#1239167 ltc#211055).
- commit 1543fff

- l2tp: fix lockdep splat (git-fixes).
- commit 1b614a9

- l2tp: fix ICMP error handling for UDP-encap sockets (git-fixes).
- commit 9f93194

- net l2tp: drop flow hash on forward (git-fixes).
- commit c98f745

- l2tp: fix incorrect parameter validation in the
  pppol2tp_getsockopt() function (git-fixes).
- commit 33af351

- net_sched: sch_sfq: don't allow 1 packet limit (CVE-2024-57996
  bsc#1239076).
- commit 8f719fe

- ASoC: SOF: Intel: hda-dai: Ensure DAI widget is valid during
  params (CVE-2024-58012 bsc#1239104).
- commit 3d2e163

- usb: gadget: Check bmAttributes only if configuration is valid
  (git-fixes).
- usb: gadget: Fix setting self-powered state on suspend
  (git-fixes).
- commit 1151d65

- usb: typec: ucsi: Fix NULL pointer access (git-fixes).
- usb: hub: lack of clearing xHC resources (git-fixes).
- usb: renesas_usbhs: Flush the notify_hotplug_work (git-fixes).
- usb: renesas_usbhs: Use devm_usb_get_phy() (git-fixes).
- usb: renesas_usbhs: Call clk_put() (git-fixes).
- usb: dwc3: gadget: Prevent irq storm when TH re-executes
  (git-fixes).
- usb: typec: ucsi: increase timeout for PPM reset operations
  (git-fixes).
- usb: typec: tcpci_rt1711h: Unmask alert interrupts to fix
  functionality (git-fixes).
- usb: gadget: Set self-powered based on MaxPower and bmAttributes
  (git-fixes).
- usb: gadget: u_ether: Set is_suspend flag if remote wakeup fails
  (git-fixes).
- usb: atm: cxacru: fix a flaw in existing endpoint checks
  (git-fixes).
- drivers: core: fix device leak in __fw_devlink_relax_cycles()
  (git-fixes).
- Revert &amp;quot;drivers/card_reader/rtsx_usb: Restore interrupt based
  detection&amp;quot; (git-fixes).
- bus: simple-pm-bus: fix forced runtime PM use (git-fixes).
- char: misc: deallocate static minor in error path (git-fixes).
- eeprom: digsy_mtc: Make GPIO lookup table match the device
  (git-fixes).
- drivers: virt: acrn: hsm: Use kzalloc to avoid info leak in
  pmcmd_ioctl (git-fixes).
- slimbus: messaging: Free transaction ID in delayed interrupt
  scenario (git-fixes).
- cdx: Fix possible UAF error in driver_override_show()
  (git-fixes).
- bus: mhi: host: pci_generic: Use pci_try_reset_function()
  to avoid deadlock (git-fixes).
- iio: filter: admv8818: Force initialization of SDO (git-fixes).
- iio: dac: ad3552r: clear reset status flag (git-fixes).
- iio: adc: at91-sama5d2_adc: fix sama7g5 realbits value
  (git-fixes).
- commit 481095d

- Update
  patches.suse/HID-hid-thrustmaster-fix-stack-out-of-bounds-read-in.patch
  (git-fixes CVE-2025-21794 bsc#1238502).
- Update
  patches.suse/NFC-nci-Add-bounds-checking-in-nci_hci_create_pipe.patch
  (git-fixes CVE-2025-21735 bsc#1238497).
- Update
  patches.suse/PCI-Avoid-putting-some-root-ports-into-D3-on-TUXEDO-.patch
  (git-fixes CVE-2025-21831 bsc#1239039).
- Update
  patches.suse/PCI-rcar-ep-Fix-incorrect-variable-used-when-calling.patch
  (git-fixes CVE-2025-21804 bsc#1238736).
- Update
  patches.suse/RDMA-mlx5-Fix-a-race-for-an-ODP-MR-which-leads-to-CQ.patch
  (git-fixes CVE-2025-21732 bsc#1237877).
- Update
  patches.suse/RDMA-mlx5-Fix-implicit-ODP-use-after-free.patch
  (git-fixes CVE-2025-21714 bsc#1237890).
- Update
  patches.suse/RDMA-rxe-Fix-the-warning-__rxe_cleanup-0x12c-0x170-r.patch
  (git-fixes CVE-2025-21829 bsc#1239030).
- Update
  patches.suse/Revert-drm-amd-display-Use-HW-lock-mgr-for-PSR1.patch
  (stable-fixes CVE-2025-21819 bsc#1238994).
- Update
  patches.suse/USB-hub-Ignore-non-compliant-devices-with-too-many-c.patch
  (stable-fixes CVE-2025-21776 bsc#1238909).
- Update
  patches.suse/arm64-cacheinfo-Avoid-out-of-bounds-write-to-cacheinfo-array.patch
  (git-fixes CVE-2025-21785 bsc#1238747).
- Update
  patches.suse/ata-libata-sff-Ensure-that-we-cannot-write-outside-t.patch
  (stable-fixes CVE-2025-21738 bsc#1238917).
- Update
  patches.suse/batman-adv-Drop-unmanaged-ELP-metric-worker.patch
  (git-fixes CVE-2025-21823 bsc#1238475).
- Update
  patches.suse/batman-adv-fix-panic-during-interface-removal.patch
  (git-fixes CVE-2025-21781 bsc#1238735).
- Update
  patches.suse/blk-cgroup-Fix-class-block_class-s-subsystem-refcount-leakage.patch
  (bsc#1237558 CVE-2025-21745 bsc#1238785).
- Update
  patches.suse/block-bfq-fix-waker_bfqq-UAF-after-bfq_split_bfqq.patch
  (git-fixes CVE-2025-21631 bsc#1236099).
- Update
  patches.suse/can-ctucanfd-handle-skb-allocation-failure.patch
  (git-fixes CVE-2025-21775 bsc#1238501).
- Update
  patches.suse/can-etas_es58x-fix-potential-NULL-pointer-dereferenc.patch
  (git-fixes CVE-2025-21773 bsc#1238762).
- Update
  patches.suse/driver-core-class-Fix-wild-pointer-dereferences-in-A.patch
  (git-fixes CVE-2025-21810 bsc#1238757).
- Update
  patches.suse/drm-amdgpu-avoid-buffer-overflow-attach-in-smu_sys_s.patch
  (stable-fixes CVE-2025-21780 bsc#1239115).
- Update
  patches.suse/drm-amdgpu-bail-out-when-failed-to-load-fw-in-psp_in.patch
  (git-fixes CVE-2025-21784 bsc#1238510).
- Update patches.suse/landlock-Handle-weird-files.patch (git-fixes
  CVE-2025-21830 bsc#1239033).
- Update patches.suse/misc-fastrpc-Fix-copy-buffer-page-size.patch
  (git-fixes CVE-2025-21734 bsc#1238734).
- Update
  patches.suse/mm-compaction-fix-UBSAN-shift-out-of-bounds-warning.patch
  (git fixes (mm/compaction) CVE-2025-21815 bsc#1238474).
- Update
  patches.suse/msft-hv-3160-KVM-x86-Reject-Hyper-V-s-SEND_IPI-hypercalls-if-loca.patch
  (git-fixes CVE-2025-21779 bsc#1238768).
- Update
  patches.suse/nbd-don-t-allow-reconnect-after-disconnect.patch
  (git-fixes CVE-2025-21731 bsc#1237881).
- Update
  patches.suse/net-rose-fix-timer-races-against-user-threads.patch
  (git-fixes CVE-2025-21718 bsc#1239073).
- Update patches.suse/net-rose-lock-the-socket-in-rose_bind.patch
  (git-fixes CVE-2025-21749 bsc#1238904).
- Update
  patches.suse/net-rose-prevent-integer-overflows-in-rose_setsockop.patch
  (git-fixes CVE-2025-21711 bsc#1239114).
- Update
  patches.suse/net-usb-rtl8150-enable-basic-endpoint-checking.patch
  (git-fixes CVE-2025-21708 bsc#1239087).
- Update
  patches.suse/nilfs2-fix-possible-int-overflows-in-nilfs_fiemap.patch
  (git-fixes CVE-2025-21736 bsc#1238715).
- Update patches.suse/padata-avoid-UAF-for-reorder_work.patch
  (git-fixes CVE-2025-21726 bsc#1238865).
- Update patches.suse/padata-fix-UAF-in-padata_reorder.patch
  (git-fixes CVE-2025-21727 bsc#1237876).
- Update
  patches.suse/scsi-mpi3mr-Fix-possible-crash-when-setting-up-bsg-f.patch
  (git-fixes CVE-2025-21723 bsc#1238864).
- Update patches.suse/spi-sn-f-ospi-Fix-division-by-zero.patch
  (git-fixes CVE-2025-21793 bsc#1238500).
- Update patches.suse/tty-xilinx_uartps-split-sysrq-handling.patch
  (git-fixes CVE-2025-21820 bsc#1238479).
- Update
  patches.suse/usb-cdc-acm-Check-control-transfer-buffer-size-befor.patch
  (git-fixes CVE-2025-21704 bsc#1237571).
- Update
  patches.suse/usb-gadget-core-flush-gadget-workqueue-after-device-.patch
  (git-fixes CVE-2025-21838 bsc#1239065).
- Update
  patches.suse/usb-gadget-f_midi-fix-MIDI-Streaming-descriptor-leng.patch
  (git-fixes CVE-2025-21835 bsc#1239068).
- Update patches.suse/usbnet-ipheth-fix-DPE-OoB-read.patch
  (git-fixes CVE-2025-21741 bsc#1238767).
- Update
  patches.suse/usbnet-ipheth-fix-possible-overflow-in-DPE-length-ch.patch
  (git-fixes CVE-2025-21743 bsc#1238781).
- Update
  patches.suse/usbnet-ipheth-use-static-NDP16-location-in-URB.patch
  (git-fixes CVE-2025-21742 bsc#1238771).
- Update
  patches.suse/vsock-Keep-the-binding-until-socket-destruction.patch
  (git-fixes CVE-2025-21756 bsc#1238876).
- Update
  patches.suse/wifi-brcmfmac-Check-the-return-value-of-of_property_.patch
  (stable-fixes CVE-2025-21750 bsc#1238905).
- Update
  patches.suse/wifi-brcmfmac-fix-NULL-pointer-dereference-in-brcmf_.patch
  (stable-fixes CVE-2025-21744 bsc#1238903).
- Update
  patches.suse/wifi-mac80211-don-t-flush-non-uploaded-STAs.patch
  (git-fixes CVE-2025-21828 bsc#1238958).
- Update patches.suse/zram-fix-potential-UAF-of-zram-table.patch
  (git-fixes CVE-2025-21671 bsc#1236692).
- commit 0d7f015

- Update
  patches.suse/Bluetooth-L2CAP-handle-NULL-sock-pointer-in-l2cap_so.patch
  (git-fixes CVE-2024-58009 bsc#1238760).
- Update
  patches.suse/Bluetooth-MGMT-Fix-slab-use-after-free-Read-in-mgmt_.patch
  (stable-fixes CVE-2024-58013 bsc#1239095).
- Update
  patches.suse/HID-core-Fix-assumption-that-Resolution-Multipliers-.patch
  (git-fixes CVE-2024-57986 bsc#1237907).
- Update
  patches.suse/HID-hid-thrustmaster-Fix-warning-in-thrustmaster_pro.patch
  (git-fixes CVE-2024-57993 bsc#1237894).
- Update
  patches.suse/PCI-dwc-ep-Prevent-changing-BAR-size-flags-in-pci_ep.patch
  (git-fixes CVE-2024-58006 bsc#1238772).
- Update
  patches.suse/block-Fix-page-refcounts-for-unaligned-buffers-in-__bio_release_pages.patch
  (git-fixes CVE-2024-35826 bsc#1224610).
- Update
  patches.suse/block-avoid-to-reuse-hctx-not-removed-from-cpuhp-callback-list.patch
  (git-fixes CVE-2024-41149 bsc#1235698).
- Update
  patches.suse/block-fix-integer-overflow-in-BLKSECDISCARD.patch
  (git-fixes CVE-2024-49994 bsc#1225770).
- Update
  patches.suse/cifs-fix-potential-null-pointer-use-in-destroy_workqueue-in-init_ci.patch
  (bsc#1231432 CVE-2024-42307 bsc#1229361).
- Update
  patches.suse/clk-qcom-dispcc-sm6350-Add-missing-parent_map-for-a-.patch
  (git-fixes CVE-2024-58080 bsc#1239027).
- Update
  patches.suse/clk-qcom-gcc-sm6350-Add-missing-parent_map-for-two-c.patch
  (git-fixes CVE-2024-58076 bsc#1239037).
- Update
  patches.suse/drm-amdgpu-Fix-potential-NULL-pointer-dereference-in.patch
  (git-fixes CVE-2024-58052 bsc#1238986).
- Update
  patches.suse/drm-msm-gem-prevent-integer-overflow-in-msm_ioctl_ge.patch
  (git-fixes CVE-2024-52559 bsc#1238507).
- Update
  patches.suse/drm-v3d-Stop-active-perfmon-if-it-is-being-destroyed.patch
  (git-fixes CVE-2024-58086 bsc#1239038).
- Update patches.suse/idpf-convert-workqueues-to-unbound.patch
  (git-fixes CVE-2024-58057 bsc#1238969).
- Update
  patches.suse/ipmi-ipmb-Add-check-devm_kasprintf-returned-value.patch
  (git-fixes CVE-2024-58051 bsc#1238963).
- Update
  patches.suse/media-imx-jpeg-Fix-potential-error-pointer-dereferen.patch
  (git-fixes CVE-2024-57978 bsc#1238523).
- Update
  patches.suse/media-uvcvideo-Fix-crash-during-unbind-if-gpio-unit-.patch
  (git-fixes CVE-2024-58079 bsc#1239029).
- Update
  patches.suse/media-uvcvideo-Fix-double-free-in-error-path.patch
  (git-fixes CVE-2024-57980 bsc#1237911).
- Update
  patches.suse/media-uvcvideo-Remove-dangling-pointers.patch
  (git-fixes CVE-2024-58002 bsc#1238503).
- Update
  patches.suse/media-vidtv-Fix-a-null-ptr-deref-in-vidtv_mux_stop_t.patch
  (stable-fixes CVE-2024-57834 bsc#1238993).
- Update
  patches.suse/memory-tegra20-emc-fix-an-OF-node-reference-bug-in-t.patch
  (git-fixes CVE-2024-58034 bsc#1238773).
- Update
  patches.suse/misc-misc_minor_alloc-to-use-ida-for-all-dynamic-mis.patch
  (git-fixes CVE-2024-58078 bsc#1239034).
- Update
  patches.suse/net-fix-removing-a-namespace-with-conflicting-altnam.patch
  (bsc#1233749 CVE-2024-26634 bsc#1221651).
- Update patches.suse/null_blk-fix-validation-of-block-size.patch
  (git-fixes CVE-2024-41077 bsc#1228653).
- Update
  patches.suse/platform-x86-int3472-Check-for-adev-NULL.patch
  (stable-fixes CVE-2024-58011 bsc#1239080).
- Update
  patches.suse/powerpc-pseries-iommu-IOMMU-incorrectly-marks-MMIO-r.patch
  (bsc#1218470 ltc#204531 CVE-2024-57999 bsc#1238526).
- Update
  patches.suse/printk-Fix-signed-integer-overflow-when-defining-LOG_BUF_LEN_MAX.patch
  (bsc#1237950 CVE-2024-58017 bsc#1239112).
- Update
  patches.suse/rdma-cxgb4-Prevent-potential-integer-overflow-on-32b.patch
  (git-fixes CVE-2024-57973 bsc#1238531).
- Update
  patches.suse/remoteproc-core-Fix-ida_free-call-while-not-allocate.patch
  (git-fixes CVE-2024-58056 bsc#1238981).
- Update
  patches.suse/rtc-pcf85063-fix-potential-OOB-write-in-PCF85063-NVM.patch
  (git-fixes CVE-2024-58069 bsc#1238978).
- Update
  patches.suse/scsi-hisi_sas-Fix-a-deadlock-issue-related-to-automa-3c4f53b2.patch
  (git-fixes CVE-2024-26873 bsc#1223047).
- Update
  patches.suse/scsi-megaraid_sas-Fix-for-a-potential-deadlock.patch
  (git-fixes CVE-2024-57807 bsc#1235761).
- Update
  patches.suse/smb-client-fix-double-put-of-cfile-in-smb2_rename_path-.patch
  (git-fixes CVE-2024-46736 bsc#1230728).
- Update
  patches.suse/smb-client-fix-double-put-of-cfile-in-smb2_set_path_size-.patch
  (git-fixes CVE-2024-46796 bsc#1230832).
- Update
  patches.suse/smb-client-fix-possible-double-free-in-smb2_set_ea-.patch
  (git-fixes CVE-2024-50152 bsc#1233033).
- Update
  patches.suse/soc-qcom-socinfo-Avoid-out-of-bounds-read-of-serial-.patch
  (git-fixes CVE-2024-58007 bsc#1238511).
- Update
  patches.suse/staging-media-max96712-fix-kernel-oops-when-removing.patch
  (git-fixes CVE-2024-58054 bsc#1238975).
- Update
  patches.suse/tomoyo-don-t-emit-warning-in-tomoyo_write_control.patch
  (stable-fixes CVE-2024-58085 bsc#1239085).
- Update
  patches.suse/tpm-Change-to-kvalloc-in-eventlog-acpi.c.patch
  (bsc#1233260 bsc#1233259 bsc#1232421 CVE-2024-58005
  bsc#1237873).
- Update
  patches.suse/ubifs-skip-dumping-tnc-tree-when-zroot-is-null.patch
  (git-fixes CVE-2024-58058 bsc#1238979).
- Update
  patches.suse/usb-gadget-f_tcm-Don-t-free-command-immediately.patch
  (git-fixes CVE-2024-58055 bsc#1238959).
- Update
  patches.suse/usb-xhci-Fix-NULL-pointer-dereference-on-certain-com.patch
  (git-fixes CVE-2024-57981 bsc#1237912).
- Update
  patches.suse/wifi-brcmsmac-add-gain-range-check-to-wlc_phy_iqcal_.patch
  (stable-fixes CVE-2024-58014 bsc#1239109).
- Update
  patches.suse/wifi-mac80211-prohibit-deactivating-all-links.patch
  (git-fixes CVE-2024-58061 bsc#1238973).
- Update
  patches.suse/wifi-mt76-mt7925-fix-off-by-one-in-mt7925_load_clc.patch
  (git-fixes CVE-2024-57990 bsc#1237900).
- Update
  patches.suse/wifi-rtlwifi-fix-memory-leaks-and-invalid-access-at-.patch
  (git-fixes CVE-2024-58063 bsc#1238984).
- Update
  patches.suse/wifi-rtlwifi-remove-unused-check_buddy_priv.patch
  (git-fixes CVE-2024-58072 bsc#1238964).
- Update
  patches.suse/wifi-wcn36xx-fix-channel-survey-memory-allocation-si.patch
  (git-fixes CVE-2024-57997 bsc#1238529).
- commit fb231d1

- Update
  patches.suse/cpu-hotplug-Don-t-offline-the-last-non-isolated-CPU.patch
  (bsc#1237562 CVE-2023-52831 bsc#1225533).
- Update
  patches.suse/io_uring-rw-split-io_read-into-a-helper.patch
  (bsc#1215211 CVE-2023-52926 bsc#1237565).
- commit a1ecaa9

- partitions: mac: fix handling of bogus partition table
  (git-fixes).
- block: cleanup and fix batch completion adding conditions
  (git-fixes).
- block: don't revert iter for -EIOCBQUEUED (git-fixes).
- commit 9b6ced4

- rapidio: add check for rio_add_net() in rio_scan_alloc_net()
  (git-fixes).
- rapidio: fix an API misues when rio_add_net() fails (git-fixes).
- dma: kmsan: export kmsan_handle_dma() for modules (git-fixes).
- commit 6203500

- orangefs: fix a oob in orangefs_debug_write (git-fixes).
- commit d83f55b

- sunrpc: suppress warnings for unused procfs functions
  (git-fixes).
- commit cd678ab

- SUNRPC: Handle -ETIMEDOUT return from tlshd (git-fixes).
- commit 55bec3b

- SUNRPC: Prevent looping due to rpc_signal_task() races
  (git-fixes).
- commit 033fbe6

- SUNRPC: convert RPC_TASK_* constants to enum (git-fixes).
- commit 444dbb7

- nfsd: clear acl_access/acl_default after releasing them
  (git-fixes).
- commit 44261ed

- pnfs/flexfiles: retry getting layout segment for reads
  (git-fixes).
- commit 76f556a

- ALSA: hda/realtek: Fix Asus Z13 2025 audio (stable-fixes).
- Refresh
  patches.suse/ALSA-hda-realtek-Add-support-for-various-ASUS-Laptop.patch.
- commit 9363cb2

- ALSA: hda/realtek: Add support for ASUS ROG Strix GA603 Laptops
  using CS35L41 HDA (stable-fixes).
- ALSA: hda/realtek: Add support for ASUS ROG Strix G814 Laptop
  using CS35L41 HDA (stable-fixes).
- commit aea7c4e

- Refresh patches.suse/ALSA-hda-realtek-Workaround-for-resume-on-Dell-Venue.patch
  A patch chunk was dropped mistakenly
- commit 0e9ac09

- ALSA: hda/realtek: Add support for ASUS Zenbook UM3406KA
  Laptops using CS35L41 HDA (stable-fixes).
- ALSA: hda/realtek: Add support for ASUS ROG Strix G614 Laptops
  using CS35L41 HDA (stable-fixes).
- commit 4ef6d55

- ALSA: hda: realtek: fix incorrect IS_REACHABLE() usage
  (git-fixes).
- commit 844da8a

- ALSA: hda/realtek: Add support for various ASUS Laptops using
  CS35L41 HDA (stable-fixes).
- ALSA: hda/realtek: Limit mic boost on Positivo ARN50
  (stable-fixes).
- commit 2ee2163

- ALSA: hda: intel: Add Dell ALC3271 to power_save denylist
  (stable-fixes).
- ALSA: hda/realtek: update ALC222 depop optimize (stable-fixes).
- ALSA: hda/realtek - add supported Mic Mute LED for Lenovo
  platform (stable-fixes).
- ALSA: seq: Avoid module auto-load handling at event delivery
  (stable-fixes).
- commit 10a77af

- hwmon: fix a NULL vs IS_ERR_OR_NULL() check in
  xgene_hwmon_probe() (git-fixes).
- hwmon: (ad7314) Validate leading zero bits and return error
  (git-fixes).
- hwmon: (ntc_thermistor) Fix the ncpXXxh103 sensor table
  (git-fixes).
- hwmon: (pmbus) Initialise page count in pmbus_identify()
  (git-fixes).
- gpio: rcar: Fix missing of_node_put() call (git-fixes).
- gpio: aggregator: protect driver attr handlers against module
  unload (git-fixes).
- ALSA: usx2y: validate nrpacks module parameter on probe
  (git-fixes).
- ALSA: hda/realtek: Remove (revert) duplicate Ally X config
  (git-fixes).
- drm/amd/display: Fix HPD after gpu reset (stable-fixes).
- drm/amd/display: Disable PSR-SU on eDP panels (stable-fixes).
- firmware: cs_dsp: Remove async regmap writes (git-fixes).
- commit c757c56

- packaging: Patch Makefile to pre-select gcc version (jsc#PED-12251).
  When compiler different from the one which was used to configure the
  kernel is used to build modules a warning is issued and the build
  continues. This could be turned into an error but that would be too
  restrictive.
  The generated kernel-devel makefile could set the compiler but then the
  main Makefile as to be patched to assign CC with ?=
  This causes run_oldconfig failure on SUSE-2024 and kbuild config check
  failure on SUSE-2025.
  This cannot be hardcoded to one version in a regular patch because the
  value is expected to be configurable at mkspec time. Patch the Makefile
  after aplyin patches in rpm prep step instead. A check is added to
  verify that the sed command did indeed apply the change.
- commit 6031391

- tracing/osnoise: Fix resetting of tracepoints (CVE-2025-21733
  bsc#1238494).
- commit 27d6e3b

- btrfs: fix assertion failure when splitting ordered extent
  after transaction abort (CVE-2025-21754 bsc#1238496).
- commit 2050c25

- kABI workaround for pps changes (CVE-2024-57979 bsc#1238521).
- commit b151154

- pps: Fix a use-after-free (CVE-2024-57979 bsc#1238521).
- commit c19b588

Package expat was updated:

- version update to 2.7.1    Bug fixes:
    [#980] #989  Restore event pointer behavior from Expat 2.6.4
    (that the fix to CVE-2024-8176 changed in 2.7.0);
    affected API functions are:
  - XML_GetCurrentByteCount
  - XML_GetCurrentByteIndex
  - XML_GetCurrentColumnNumber
  - XML_GetCurrentLineNumber
  - XML_GetInputContext
    Other changes:
    [#976] #977  Autotools: Integrate files &amp;quot;fuzz/xml_lpm_fuzzer.{cpp,proto}&amp;quot;
    with Automake that were missing from 2.7.0 release tarballs
    [#983] #984  Fix printf format specifiers for 32bit Emscripten
    [#992]  docs: Promote OpenSSF Best Practices self-certification
    [#978]  tests/benchmark: Resolve mistaken double close
    [#986]  Address compiler warnings
    [#990] #993  Version info bumped from 11:1:10 (libexpat*.so.1.10.1)
    to 11:2:10 (libexpat*.so.1.10.2); see https://verbump.de/
    for what these numbers do
    Infrastructure:
    [#982]  CI: Start running Perl XML::Parser integration tests
    [#987]  CI: Enforce Clang Static Analyzer clean code
    [#991]  CI: Re-enable warning clang-analyzer-valist.Uninitialized
    for clang-tidy
    [#981]  CI: Cover compilation with musl
    [#983] #984  CI: Cover compilation with 32bit Emscripten
    [#976] #977  CI: Protect against fuzzer files missing from future
    release archives

- version update to 2.7.0 for SLE-15-SP4
- deleted patches
  - expat-CVE-2022-25235.patch (upstreamed)
  - expat-CVE-2022-25236-relax-fix.patch (upstreamed)
  - expat-CVE-2022-25236.patch (upstreamed)
  - expat-CVE-2022-25313-fix-regression.patch (upstreamed)
  - expat-CVE-2022-25313.patch (upstreamed)
  - expat-CVE-2022-25314.patch (upstreamed)
  - expat-CVE-2022-25315.patch (upstreamed)
  - expat-CVE-2022-40674.patch (upstreamed)
  - expat-CVE-2022-43680.patch (upstreamed)
  - expat-CVE-2023-52425-1.patch (upstreamed)
  - expat-CVE-2023-52425-2.patch (upstreamed)
  - expat-CVE-2023-52425-backport-parser-changes.patch (upstreamed)
  - expat-CVE-2023-52425-fix-tests.patch (upstreamed)
  - expat-CVE-2024-28757.patch (upstreamed)
  - expat-CVE-2024-45490.patch (upstreamed)
  - expat-CVE-2024-45491.patch (upstreamed)
  - expat-CVE-2024-45492.patch (upstreamed)
  - expat-CVE-2024-50602.patch (upstreamed)

- version update to 2.7.0 (CVE-2024-8176 [bsc#1239618])
  * Security fixes:
    [#893] #973  CVE-2024-8176 -- Fix crash from chaining a large number
    of entities caused by stack overflow by resolving use of
    recursion, for all three uses of entities:
  - general entities in character data (&amp;quot;&amp;lt;e&amp;gt;&amp;amp;g1;&amp;lt;/e&amp;gt;&amp;quot;)
  - general entities in attribute values (&amp;quot;&amp;lt;e k1='&amp;amp;g1;'/&amp;gt;&amp;quot;)
  - parameter entities (&amp;quot;%p1;&amp;quot;)
    Known impact is (reliable and easy) denial of service:
    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:H/RL:O/RC:C
    (Base Score: 7.5, Temporal Score: 7.2)
    Please note that a layer of compression around XML can
    significantly reduce the minimum attack payload size.
  * Other changes:
    [#935] #937  Autotools: Make generated CMake files look for
    libexpat.@SO_MAJOR@.dylib on macOS
    [#925]  Autotools: Sync CMake templates with CMake 3.29
  [#945] #962 #966  CMake: Drop support for CMake &amp;lt;3.13
    [#942]  CMake: Small fuzzing related improvements
    [#921]  docs: Add missing documentation of error code
    XML_ERROR_NOT_STARTED that was introduced with 2.6.4
    [#941]  docs: Document need for C++11 compiler for use from C++
    [#959]  tests/benchmark: Fix a (harmless) TOCTTOU
    [#944]  Windows: Fix installer target location of file xmlwf.xml
    for CMake
    [#953]  Windows: Address warning -Wunknown-warning-option
    about -Wno-pedantic-ms-format from LLVM MinGW
    [#971]  Address Cppcheck warnings
    [#969] #970  Mass-migrate links from http:// to https://
    [#947] #958 ..
    [#974] #975  Document changes since the previous release
    [#974] #975  Version info bumped from 11:0:10 (libexpat*.so.1.10.0)
    to 11:1:10 (libexpat*.so.1.10.1); see https://verbump.de/
    for what these numbers do

- no source changes, just adding jira reference: jsc#SLE-21253

Package freetype2 was updated:

Package libgcrypt was updated:

- FIPS: Pad PKCS1.5 signatures with SHA3 correctly [bsc#1241605]  * Add libgcrypt-FIPS-sha3-asn.patch

Package ncurses was updated:

- Modify patch ncurses-5.9-ibm327x.dif  * Backport sclp terminfo description entry if for s390 sclp terminal lines
  * Add a further sclp entry for qemu s390 based systems
  * Make use of dumb

Package openssl-3 was updated:

- Security fix: [bsc#1240366]  * Minerva side channel vulnerability in P-384 on PPC arch
  * Add openssl-3-p384-minerva-ppc.patch
  * Add openssl-3-p384-minerva-ppc-p9.patch

- Security fix: [bsc#1240607]
  * Check ssl/ssl3_read_internal null pointer [from commit 38b051a]
  * Add openssl-check-ssl_read_internal-nullptr.patch

- FIPS: Fix EMS in crypto-policies FIPS:NO-ENFORCE-EMS
  * [bsc#1230959, bsc#1232326, bsc#1231748]
  * Add patch openssl-FIPS-fix-EMS-support.patch

Package librdkafka was updated:

- 0001-Fix-timespec-conversion-to-avoid-infinite-loop-2108-.patch:  avoid endless loops (bsc#1242842)

Package ruby2.5 was updated:

- update suse.patch to 736ea75f25d52fdebb88ed6583468bd7c21190f6  - fix ReDoS in CGI::Util#escapeElement
    bsc#1237806 CVE-2025-27220
  - fix denial of service in CGI::Cookie.parse
    bsc#1237804 CVE-2025-27219

- update suse.patch to 6bf78da1fc4048a11a8612741216ebc47d9ebb41
  - move the request smuggling patch to the correct place
    actually fixes bsc#1230930 CVE-2024-47220 and now boo#1235773

Package libsolv was updated:

- build both static and dynamic libraries on new suse distros- support the apk package and repository format (both v2 and v3)
- new dataiterator_final_{repo,solvable} functions
- bump version to 0.7.32

- Provide a symbol specific for the ruby-version
  so yast does not break across updates (boo#1235598)

Package sqlite3 was updated:

- Sync version 3.49.1 from Factory (jsc#SLE-16032):  * CVE-2025-29087, bsc#1241020: Fix a bug in the concat_ws()
    function, introduced in version 3.44.0, that could lead to a
    memory error if the separator string is very large (hundreds
    of megabytes).
  * CVE-2025-29088, bsc#1241078: Enhanced the
    SQLITE_DBCONFIG_LOOKASIDE interface to make it  more robust
    against misuse.
  * Obsoletes sqlite3-rtree-i686.patch

Package libxml2 was updated:

- security update- added patches
  CVE-2025-32414 [bsc#1241551], out-of-bounds read when parsing text via the Python API
  + libxml2-CVE-2025-32414.patch
  CVE-2025-32415 [bsc#1241453], a crafted XML document may lead to a heap-based buffer under-read
  + libxml2-CVE-2025-32415.patch

Package libzypp was updated:

- fixed build with boost 1.88.- XmlReader: Fix detection of bad input streams (fixes #635)
  libxml2 2.14 potentially reads the complete stream, so it may
  have the 'eof' bit set. Which is not 'good' but also not 'bad'.
- rpm: Fix detection of %triggerscript starts (bsc#1222044)
- RepoindexFileReader: add more &amp;lt;repo&amp;gt; related attributes a
  service may set.
  Add optional attributes gpgcheck, repo_gpgcheck, pkg_gpgcheck,
  keeppackages, gpgkey, mirrorlist, and metalink with the same
  semantic as in a .repo file.
- version 17.36.7 (35)

- Drop workaround for broken rpm-4.18 in Code16 (bsc#1237172)
- BuildRequires:  %{libsolv_devel_package} &amp;gt;= 0.7.32.
  Code16 moved static libs to libsolv-devel-static.
- Drop usage of SHA1 hash algorithm because it will become
  unavailable in FIPS mode (bsc#1240529)
- Fix zypp.conf dupAllowVendorChange to reflect the correct
  default (false).
  The default was true in Code12 (libzypp-16.x) and changed to
  false with Code15 (libzypp-17.x). Unfortunately this was done by
  shipping a modified zypp.conf file rather than fixing the code.
- zypp.conf: Add `lock_timeout` ($ZYPP_LOCK_TIMEOUT) (bsc#1239809)
- version 17.36.6 (35)

- Fix computation of RepStatus if Repo URLs change.
- Fix lost double slash when appending to an absolute FTP url
  (bsc#1238315)
  Ftp actually differs between absolute and relative URL paths.
  Absolute path names begin with a double slash encoded as '/%2F'.
  This must be preserved when manipulating the path.
- version 17.36.5 (35)

- Add a transaction package preloader (fixes openSUSE/zypper#104)
  This patch adds a preloader that concurrently downloads files
  during a transaction commit. It's not yet enabled per default.
  To enable the preview set ZYPP_CURL2=1 and ZYPP_PCK_PRELOAD=1
  in the environment.
- RpmPkgSigCheck_test: Exchange the test package signingkey
  (fixes #622)
- Exclude MediaCurl tests if DISABLE_MEDIABACKEND_TESTS (fixes #626)
- Strip a mediahandler tag from baseUrl querystrings.
- version 17.36.4 (35)

Package nvme-cli was updated:

- Update to version 2.8+88.g21612f53:  * sed: perform a tper revert after lsp revert (bsc#1240656)

Package openssh was updated:

- Enable --with-logind to call the SetTTY dbus method in systemd.  This allows &amp;quot;wall&amp;quot; to print messages in ssh ttys (bsc#1239671)
- Small fixes to unref the dbus session when any error occurs:
  * logind_set_tty.patch

- Added openssh-cve-2025-32728.patch (bsc#1241012, CVE-2025-32728).
  This fixes an upstream logic error handling the DisableForwarding
  option.

Package pam was updated:

- pam_unix/passverify: (get_account_info) [!HELPER_COMPILE]: Always return  PAM_UNIX_RUN_HELPER instead of trying to obtain the shadow password file
  entry.
  [passverify-always-run-the-helper-to-obtain-shadow_pwd.patch, bsc#1232234,
  CVE-2024-10041]
- Do not reject the user with a hash assuming it's non-empty.
  [pam_unix-allow-empty-passwords-with-non-empty-hashes.patch]

Package patterns-base was updated:

Package salt was updated:

- Fix aptpkg 'NoneType object has no attribute split' error- Detect openEuler as RedHat family OS
- Ensure the correct crypt module is loaded
- Implement multiple inventory for ansible.targets
- Make x509 module compatible with M2Crypto 0.44.0
- Remove deprecated code from x509.certificate_managed test mode
- Move logrotate config to /usr/etc/logrotate.d where possible
- Add DEB822 apt repository format support
- Make Salt-SSH work with all SSH passwords (bsc#1215484)
- Fix issue of using update-alternatives with alts (#105)
- Fix virt_query outputter and add support for block devices
- Make _auth calls visible with master stats
- Repair mount.fstab_present always returning pending changes
- Set virtual grain in Podman systemd container
- Fix crash due wrong client reference on `SaltMakoTemplateLookup`
- Enhace batch async and fix some detected issues
- Enhacement of Salt packaging
  * Use update-alternatives for all salt scripts
  * Use flexible dependencies for the subpackages
  * Make salt-minion to require flavored zypp-plugin
  * Make zyppnotify to use update-alternatives
  * Drop unused yumnotify plugin
  * Add dependency to python3-dnf-plugins-core for RHEL based
- Fix tests failures after &amp;quot;repo.saltproject.io&amp;quot; deprecation
- Fix error to stat '/root/.gitconfig' on gitfs
  (bsc#1230944) (bsc#1234881) (bsc#1220905)
- Adapt to removal of hex attribute in pygit2 v1.15.0 (bsc#1230642)
- Enhance smart JSON parsing when garbage is present (bsc#1231605)
- Fix virtual grains for VMs running on Nutanix AHV (bsc#1234022)
- Fix issues running on Python 3.12 and 3.13
- Added:
  * fix-deb822-nonetype-object-has-no-attribute-split-71.patch
  * detect-openeuler-as-redhat-family-os.patch
  * ensure-the-correct-crypt-module-is-loaded.patch
  * implement-multiple-inventory-for-ansible.targets.patch
  * make-x509-module-compatible-with-m2crypto-0.44.0.patch
  * remove-deprecated-code-from-x509.certificate_managed.patch
  * add-deb822-apt-source-format-support-692.patch
  * remove-password-from-shell-after-functional-text-mat.patch
  * repair-virt_query-outputter-655.patch
  * make-_auth-calls-visible-with-master-stats-696.patch
  * repair-fstab_present-test-mode-702.patch
  * set-virtual-grain-in-podman-systemd-container-703.patch
  * fixed-file-client-private-attribute-reference-on-sal.patch
  * backport-batch-async-fixes-and-improvements-701.patch
  * fix-tests-failures-after-repo.saltproject.io-depreca.patch
  * fix-failed-to-stat-root-.gitconfig-issue-on-gitfs-bs.patch
  * update-for-deprecation-of-hex-in-pygit2-1.15.0-and-a.patch
  * enhance-find_json-garbage-filtering-bsc-1231605-688.patch
  * fix-virtual-grains-for-vms-running-on-nutanix-ahv-bs.patch
  * fix-issues-that-break-salt-in-python-3.12-and-3.13-6.patch

Package samba was updated:

- Fix Samba printers reporting invalid sid during print jobs;  (bsc#1234210); (bso#15792).

Package supportutils was updated:

- Changes to version 3.2.10  + network.txt collect all firewalld zones (pr#233)
  + Collects gfs2 info (PED-11853, pr#235, pr#236)
  + Ignore tasks/threads to prevent collecting duplicate fd data in open_files (bsc#1230371, pr#237)
  + Added openldap2_5 support for SLES (pr#238)
  + Collects additional hawk details (pr#239)
  + Optimized filtering D/Z processes (pr#241)
  + Collect firewalld permanent configuration (pr#243)
  + ldap_info: support for multiple DBs and sanitize olcRootPW (bsc#1231838, pr#247)
  + Added dbus_info for dbus.txt (bsc#1222650, pr#248)

- Changes to version 3.2.9
  + Map running PIDs to RPM package owner aiding BPF program detection (bsc#1222896, bsc#1213291, PED-8221)
  + Supportconfig available in current distro (PED-7131)
  + Corrected display issues (bsc#1231396)
  + NFS takes too long, showmount times out (bsc#1231423)
  + Merged sle15 and master branches (bsc#1233726, PED-11669)

Package timezone was updated:

- Update to 2025b:  * New zone for AysÃ©n Region in Chile (America/Coyhaique) which
    moves from -04/-03 to -03
- Refresh patches
  * revert-philippines-historical-data.patch
  * tzdata-china.diff

Package zypper was updated:

- Updated translations (bsc#1230267)- version 1.14.89

- Do not double encode URL strings passed on the commandline
  (bsc#1237587)
  URLs passed on the commandline must have their special chars
  encoded already. We just want to check and encode forgotten
  unsafe chars like a blank. A '%' however must not be encoded
  again.
- version 1.14.88

- Package preloader that concurrently downloads files. It's not yet
  enabled per default. To enable the preview set ZYPP_CURL2=1 and
  ZYPP_PCK_PRELOAD=1 in the environment. (#104)
- BuildRequires:  libzypp-devel &amp;gt;= 17.36.4.
- version 1.14.87

- refresh: add --include-all-archs (fixes #598)
  Future multi-arch repos may allow to download only those metadata
  which refer to packages actually compatible with the systems
  architecture. Some tools however want zypp to provide the full
  metadata of a repository without filtering incompatible
  architectures.
- info,search: add option to search and list Enhances
  (bsc#1237949)
- version 1.14.86

</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-byos-v20250528-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-byos-v20250528-arm64">
      <Branch Type="Product Name" Name="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
        <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
      </Branch>
    </Branch>
    <Branch Type="Product Version" Name="aaa_base-84.87+git20180409.04c9dae-150300.10.28.2">
      <FullProductName ProductID="aaa_base-84.87+git20180409.04c9dae-150300.10.28.2">aaa_base-84.87+git20180409.04c9dae-150300.10.28.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="aaa_base-extras-84.87+git20180409.04c9dae-150300.10.28.2">
      <FullProductName ProductID="aaa_base-extras-84.87+git20180409.04c9dae-150300.10.28.2">aaa_base-extras-84.87+git20180409.04c9dae-150300.10.28.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="apparmor-parser-3.1.7-150600.5.9.1">
      <FullProductName ProductID="apparmor-parser-3.1.7-150600.5.9.1">apparmor-parser-3.1.7-150600.5.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="augeas-1.14.1-150600.3.3.1">
      <FullProductName ProductID="augeas-1.14.1-150600.3.3.1">augeas-1.14.1-150600.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="augeas-lenses-1.14.1-150600.3.3.1">
      <FullProductName ProductID="augeas-lenses-1.14.1-150600.3.3.1">augeas-lenses-1.14.1-150600.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ca-certificates-mozilla-2.74-150200.41.1">
      <FullProductName ProductID="ca-certificates-mozilla-2.74-150200.41.1">ca-certificates-mozilla-2.74-150200.41.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cifs-utils-6.15-150400.3.12.1">
      <FullProductName ProductID="cifs-utils-6.15-150400.3.12.1">cifs-utils-6.15-150400.3.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cloud-regionsrv-client-10.4.0-150300.13.22.2">
      <FullProductName ProductID="cloud-regionsrv-client-10.4.0-150300.13.22.2">cloud-regionsrv-client-10.4.0-150300.13.22.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.22.2">
      <FullProductName ProductID="cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.22.2">cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.22.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="containerd-1.7.27-150000.123.1">
      <FullProductName ProductID="containerd-1.7.27-150000.123.1">containerd-1.7.27-150000.123.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="device-mapper-2.03.22_1.02.196-150600.3.6.1">
      <FullProductName ProductID="device-mapper-2.03.22_1.02.196-150600.3.6.1">device-mapper-2.03.22_1.02.196-150600.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glib2-tools-2.78.6-150600.4.11.1">
      <FullProductName ProductID="glib2-tools-2.78.6-150600.4.11.1">glib2-tools-2.78.6-150600.4.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-2.38-150600.14.32.1">
      <FullProductName ProductID="glibc-2.38-150600.14.32.1">glibc-2.38-150600.14.32.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-i18ndata-2.38-150600.14.32.1">
      <FullProductName ProductID="glibc-i18ndata-2.38-150600.14.32.1">glibc-i18ndata-2.38-150600.14.32.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-locale-2.38-150600.14.32.1">
      <FullProductName ProductID="glibc-locale-2.38-150600.14.32.1">glibc-locale-2.38-150600.14.32.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-locale-base-2.38-150600.14.32.1">
      <FullProductName ProductID="glibc-locale-base-2.38-150600.14.32.1">glibc-locale-base-2.38-150600.14.32.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-guest-oslogin-20240311.00-150000.1.50.1">
      <FullProductName ProductID="google-guest-oslogin-20240311.00-150000.1.50.1">google-guest-oslogin-20240311.00-150000.1.50.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grub2-2.12-150600.8.27.1">
      <FullProductName ProductID="grub2-2.12-150600.8.27.1">grub2-2.12-150600.8.27.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grub2-arm64-efi-2.12-150600.8.27.1">
      <FullProductName ProductID="grub2-arm64-efi-2.12-150600.8.27.1">grub2-arm64-efi-2.12-150600.8.27.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="hwinfo-21.88-150500.3.9.2">
      <FullProductName ProductID="hwinfo-21.88-150500.3.9.2">hwinfo-21.88-150500.3.9.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="iproute2-6.4-150600.7.6.1">
      <FullProductName ProductID="iproute2-6.4-150600.7.6.1">iproute2-6.4-150600.7.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kbd-2.4.0-150400.5.9.1">
      <FullProductName ProductID="kbd-2.4.0-150400.5.9.1">kbd-2.4.0-150400.5.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kbd-legacy-2.4.0-150400.5.9.1">
      <FullProductName ProductID="kbd-legacy-2.4.0-150400.5.9.1">kbd-legacy-2.4.0-150400.5.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kernel-default-6.4.0-150600.23.50.1">
      <FullProductName ProductID="kernel-default-6.4.0-150600.23.50.1">kernel-default-6.4.0-150600.23.50.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libapparmor1-3.1.7-150600.5.9.1">
      <FullProductName ProductID="libapparmor1-3.1.7-150600.5.9.1">libapparmor1-3.1.7-150600.5.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libaugeas0-1.14.1-150600.3.3.1">
      <FullProductName ProductID="libaugeas0-1.14.1-150600.3.3.1">libaugeas0-1.14.1-150600.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libdevmapper-event1_03-2.03.22_1.02.196-150600.3.6.1">
      <FullProductName ProductID="libdevmapper-event1_03-2.03.22_1.02.196-150600.3.6.1">libdevmapper-event1_03-2.03.22_1.02.196-150600.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libdevmapper1_03-2.03.22_1.02.196-150600.3.6.1">
      <FullProductName ProductID="libdevmapper1_03-2.03.22_1.02.196-150600.3.6.1">libdevmapper1_03-2.03.22_1.02.196-150600.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libexpat1-2.7.1-150400.3.28.1">
      <FullProductName ProductID="libexpat1-2.7.1-150400.3.28.1">libexpat1-2.7.1-150400.3.28.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libfa1-1.14.1-150600.3.3.1">
      <FullProductName ProductID="libfa1-1.14.1-150600.3.3.1">libfa1-1.14.1-150600.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libfreetype6-2.10.4-150000.4.22.1">
      <FullProductName ProductID="libfreetype6-2.10.4-150000.4.22.1">libfreetype6-2.10.4-150000.4.22.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgcrypt20-1.10.3-150600.3.6.1">
      <FullProductName ProductID="libgcrypt20-1.10.3-150600.3.6.1">libgcrypt20-1.10.3-150600.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgio-2_0-0-2.78.6-150600.4.11.1">
      <FullProductName ProductID="libgio-2_0-0-2.78.6-150600.4.11.1">libgio-2_0-0-2.78.6-150600.4.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libglib-2_0-0-2.78.6-150600.4.11.1">
      <FullProductName ProductID="libglib-2_0-0-2.78.6-150600.4.11.1">libglib-2_0-0-2.78.6-150600.4.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgmodule-2_0-0-2.78.6-150600.4.11.1">
      <FullProductName ProductID="libgmodule-2_0-0-2.78.6-150600.4.11.1">libgmodule-2_0-0-2.78.6-150600.4.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgobject-2_0-0-2.78.6-150600.4.11.1">
      <FullProductName ProductID="libgobject-2_0-0-2.78.6-150600.4.11.1">libgobject-2_0-0-2.78.6-150600.4.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="liblvm2cmd2_03-2.03.22-150600.3.6.1">
      <FullProductName ProductID="liblvm2cmd2_03-2.03.22-150600.3.6.1">liblvm2cmd2_03-2.03.22-150600.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libncurses6-6.1-150000.5.30.1">
      <FullProductName ProductID="libncurses6-6.1-150000.5.30.1">libncurses6-6.1-150000.5.30.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libopenssl3-3.1.4-150600.5.27.1">
      <FullProductName ProductID="libopenssl3-3.1.4-150600.5.27.1">libopenssl3-3.1.4-150600.5.27.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="librdkafka1-0.11.6-150600.16.3.1">
      <FullProductName ProductID="librdkafka1-0.11.6-150600.16.3.1">librdkafka1-0.11.6-150600.16.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libruby2_5-2_5-2.5.9-150000.4.41.1">
      <FullProductName ProductID="libruby2_5-2_5-2.5.9-150000.4.41.1">libruby2_5-2_5-2.5.9-150000.4.41.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsolv-tools-base-0.7.32-150600.8.10.1">
      <FullProductName ProductID="libsolv-tools-base-0.7.32-150600.8.10.1">libsolv-tools-base-0.7.32-150600.8.10.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsqlite3-0-3.49.1-150000.3.27.1">
      <FullProductName ProductID="libsqlite3-0-3.49.1-150000.3.27.1">libsqlite3-0-3.49.1-150000.3.27.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxml2-2-2.10.3-150500.5.26.1">
      <FullProductName ProductID="libxml2-2-2.10.3-150500.5.26.1">libxml2-2-2.10.3-150500.5.26.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libzypp-17.36.7-150600.3.53.1">
      <FullProductName ProductID="libzypp-17.36.7-150600.3.53.1">libzypp-17.36.7-150600.3.53.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="lvm2-2.03.22-150600.3.6.1">
      <FullProductName ProductID="lvm2-2.03.22-150600.3.6.1">lvm2-2.03.22-150600.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ncurses-utils-6.1-150000.5.30.1">
      <FullProductName ProductID="ncurses-utils-6.1-150000.5.30.1">ncurses-utils-6.1-150000.5.30.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="nscd-2.38-150600.14.32.1">
      <FullProductName ProductID="nscd-2.38-150600.14.32.1">nscd-2.38-150600.14.32.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="nvme-cli-2.8+88.g21612f53-150600.3.15.1">
      <FullProductName ProductID="nvme-cli-2.8+88.g21612f53-150600.3.15.1">nvme-cli-2.8+88.g21612f53-150600.3.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-9.6p1-150600.6.26.1">
      <FullProductName ProductID="openssh-9.6p1-150600.6.26.1">openssh-9.6p1-150600.6.26.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-clients-9.6p1-150600.6.26.1">
      <FullProductName ProductID="openssh-clients-9.6p1-150600.6.26.1">openssh-clients-9.6p1-150600.6.26.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-common-9.6p1-150600.6.26.1">
      <FullProductName ProductID="openssh-common-9.6p1-150600.6.26.1">openssh-common-9.6p1-150600.6.26.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-server-9.6p1-150600.6.26.1">
      <FullProductName ProductID="openssh-server-9.6p1-150600.6.26.1">openssh-server-9.6p1-150600.6.26.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssl-3-3.1.4-150600.5.27.1">
      <FullProductName ProductID="openssl-3-3.1.4-150600.5.27.1">openssl-3-3.1.4-150600.5.27.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="pam-1.3.0-150000.6.76.1">
      <FullProductName ProductID="pam-1.3.0-150000.6.76.1">pam-1.3.0-150000.6.76.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="patterns-base-minimal_base-20200124-150600.32.6.1">
      <FullProductName ProductID="patterns-base-minimal_base-20200124-150600.32.6.1">patterns-base-minimal_base-20200124-150600.32.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="pkg-config-0.29.2-150600.15.6.3">
      <FullProductName ProductID="pkg-config-0.29.2-150600.15.6.3">pkg-config-0.29.2-150600.15.6.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-salt-3006.0-150500.4.50.3">
      <FullProductName ProductID="python3-salt-3006.0-150500.4.50.3">python3-salt-3006.0-150500.4.50.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-solv-0.7.32-150600.8.10.1">
      <FullProductName ProductID="python3-solv-0.7.32-150600.8.10.1">python3-solv-0.7.32-150600.8.10.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ruby-solv-0.7.32-150600.8.10.1">
      <FullProductName ProductID="ruby-solv-0.7.32-150600.8.10.1">ruby-solv-0.7.32-150600.8.10.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ruby2.5-2.5.9-150000.4.41.1">
      <FullProductName ProductID="ruby2.5-2.5.9-150000.4.41.1">ruby2.5-2.5.9-150000.4.41.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ruby2.5-stdlib-2.5.9-150000.4.41.1">
      <FullProductName ProductID="ruby2.5-stdlib-2.5.9-150000.4.41.1">ruby2.5-stdlib-2.5.9-150000.4.41.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="salt-3006.0-150500.4.50.3">
      <FullProductName ProductID="salt-3006.0-150500.4.50.3">salt-3006.0-150500.4.50.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="salt-minion-3006.0-150500.4.50.3">
      <FullProductName ProductID="salt-minion-3006.0-150500.4.50.3">salt-minion-3006.0-150500.4.50.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="samba-client-libs-4.19.8+git.422.34307c5a3aa-150600.3.15.1">
      <FullProductName ProductID="samba-client-libs-4.19.8+git.422.34307c5a3aa-150600.3.15.1">samba-client-libs-4.19.8+git.422.34307c5a3aa-150600.3.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="sqlite3-tcl-3.49.1-150000.3.27.1">
      <FullProductName ProductID="sqlite3-tcl-3.49.1-150000.3.27.1">sqlite3-tcl-3.49.1-150000.3.27.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="supportutils-3.2.10-150600.3.6.5">
      <FullProductName ProductID="supportutils-3.2.10-150600.3.6.5">supportutils-3.2.10-150600.3.6.5</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="terminfo-6.1-150000.5.30.1">
      <FullProductName ProductID="terminfo-6.1-150000.5.30.1">terminfo-6.1-150000.5.30.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="terminfo-base-6.1-150000.5.30.1">
      <FullProductName ProductID="terminfo-base-6.1-150000.5.30.1">terminfo-base-6.1-150000.5.30.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="timezone-2025b-150600.91.6.2">
      <FullProductName ProductID="timezone-2025b-150600.91.6.2">timezone-2025b-150600.91.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="zypper-1.14.89-150600.10.31.1">
      <FullProductName ProductID="zypper-1.14.89-150600.10.31.1">zypper-1.14.89-150600.10.31.1</FullProductName>
    </Branch>
    <Relationship ProductReference="aaa_base-84.87+git20180409.04c9dae-150300.10.28.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:aaa_base-84.87+git20180409.04c9dae-150300.10.28.2">aaa_base-84.87+git20180409.04c9dae-150300.10.28.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="aaa_base-extras-84.87+git20180409.04c9dae-150300.10.28.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:aaa_base-extras-84.87+git20180409.04c9dae-150300.10.28.2">aaa_base-extras-84.87+git20180409.04c9dae-150300.10.28.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="apparmor-parser-3.1.7-150600.5.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:apparmor-parser-3.1.7-150600.5.9.1">apparmor-parser-3.1.7-150600.5.9.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="augeas-1.14.1-150600.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:augeas-1.14.1-150600.3.3.1">augeas-1.14.1-150600.3.3.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="augeas-lenses-1.14.1-150600.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:augeas-lenses-1.14.1-150600.3.3.1">augeas-lenses-1.14.1-150600.3.3.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ca-certificates-mozilla-2.74-150200.41.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:ca-certificates-mozilla-2.74-150200.41.1">ca-certificates-mozilla-2.74-150200.41.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cifs-utils-6.15-150400.3.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:cifs-utils-6.15-150400.3.12.1">cifs-utils-6.15-150400.3.12.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cloud-regionsrv-client-10.4.0-150300.13.22.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:cloud-regionsrv-client-10.4.0-150300.13.22.2">cloud-regionsrv-client-10.4.0-150300.13.22.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.22.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.22.2">cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.22.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="containerd-1.7.27-150000.123.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:containerd-1.7.27-150000.123.1">containerd-1.7.27-150000.123.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="device-mapper-2.03.22_1.02.196-150600.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:device-mapper-2.03.22_1.02.196-150600.3.6.1">device-mapper-2.03.22_1.02.196-150600.3.6.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glib2-tools-2.78.6-150600.4.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:glib2-tools-2.78.6-150600.4.11.1">glib2-tools-2.78.6-150600.4.11.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-2.38-150600.14.32.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:glibc-2.38-150600.14.32.1">glibc-2.38-150600.14.32.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-i18ndata-2.38-150600.14.32.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:glibc-i18ndata-2.38-150600.14.32.1">glibc-i18ndata-2.38-150600.14.32.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-locale-2.38-150600.14.32.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:glibc-locale-2.38-150600.14.32.1">glibc-locale-2.38-150600.14.32.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-locale-base-2.38-150600.14.32.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:glibc-locale-base-2.38-150600.14.32.1">glibc-locale-base-2.38-150600.14.32.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-guest-oslogin-20240311.00-150000.1.50.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:google-guest-oslogin-20240311.00-150000.1.50.1">google-guest-oslogin-20240311.00-150000.1.50.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-2.12-150600.8.27.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:grub2-2.12-150600.8.27.1">grub2-2.12-150600.8.27.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-arm64-efi-2.12-150600.8.27.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:grub2-arm64-efi-2.12-150600.8.27.1">grub2-arm64-efi-2.12-150600.8.27.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="hwinfo-21.88-150500.3.9.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:hwinfo-21.88-150500.3.9.2">hwinfo-21.88-150500.3.9.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="iproute2-6.4-150600.7.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:iproute2-6.4-150600.7.6.1">iproute2-6.4-150600.7.6.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kbd-2.4.0-150400.5.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kbd-2.4.0-150400.5.9.1">kbd-2.4.0-150400.5.9.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kbd-legacy-2.4.0-150400.5.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kbd-legacy-2.4.0-150400.5.9.1">kbd-legacy-2.4.0-150400.5.9.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kernel-default-6.4.0-150600.23.50.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.1">kernel-default-6.4.0-150600.23.50.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libapparmor1-3.1.7-150600.5.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libapparmor1-3.1.7-150600.5.9.1">libapparmor1-3.1.7-150600.5.9.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libaugeas0-1.14.1-150600.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libaugeas0-1.14.1-150600.3.3.1">libaugeas0-1.14.1-150600.3.3.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libdevmapper-event1_03-2.03.22_1.02.196-150600.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libdevmapper-event1_03-2.03.22_1.02.196-150600.3.6.1">libdevmapper-event1_03-2.03.22_1.02.196-150600.3.6.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libdevmapper1_03-2.03.22_1.02.196-150600.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libdevmapper1_03-2.03.22_1.02.196-150600.3.6.1">libdevmapper1_03-2.03.22_1.02.196-150600.3.6.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libexpat1-2.7.1-150400.3.28.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libexpat1-2.7.1-150400.3.28.1">libexpat1-2.7.1-150400.3.28.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libfa1-1.14.1-150600.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libfa1-1.14.1-150600.3.3.1">libfa1-1.14.1-150600.3.3.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libfreetype6-2.10.4-150000.4.22.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libfreetype6-2.10.4-150000.4.22.1">libfreetype6-2.10.4-150000.4.22.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgcrypt20-1.10.3-150600.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libgcrypt20-1.10.3-150600.3.6.1">libgcrypt20-1.10.3-150600.3.6.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgio-2_0-0-2.78.6-150600.4.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libgio-2_0-0-2.78.6-150600.4.11.1">libgio-2_0-0-2.78.6-150600.4.11.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libglib-2_0-0-2.78.6-150600.4.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libglib-2_0-0-2.78.6-150600.4.11.1">libglib-2_0-0-2.78.6-150600.4.11.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgmodule-2_0-0-2.78.6-150600.4.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libgmodule-2_0-0-2.78.6-150600.4.11.1">libgmodule-2_0-0-2.78.6-150600.4.11.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgobject-2_0-0-2.78.6-150600.4.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libgobject-2_0-0-2.78.6-150600.4.11.1">libgobject-2_0-0-2.78.6-150600.4.11.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="liblvm2cmd2_03-2.03.22-150600.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:liblvm2cmd2_03-2.03.22-150600.3.6.1">liblvm2cmd2_03-2.03.22-150600.3.6.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libncurses6-6.1-150000.5.30.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libncurses6-6.1-150000.5.30.1">libncurses6-6.1-150000.5.30.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libopenssl3-3.1.4-150600.5.27.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libopenssl3-3.1.4-150600.5.27.1">libopenssl3-3.1.4-150600.5.27.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="librdkafka1-0.11.6-150600.16.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:librdkafka1-0.11.6-150600.16.3.1">librdkafka1-0.11.6-150600.16.3.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libruby2_5-2_5-2.5.9-150000.4.41.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libruby2_5-2_5-2.5.9-150000.4.41.1">libruby2_5-2_5-2.5.9-150000.4.41.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsolv-tools-base-0.7.32-150600.8.10.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libsolv-tools-base-0.7.32-150600.8.10.1">libsolv-tools-base-0.7.32-150600.8.10.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsqlite3-0-3.49.1-150000.3.27.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libsqlite3-0-3.49.1-150000.3.27.1">libsqlite3-0-3.49.1-150000.3.27.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxml2-2-2.10.3-150500.5.26.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libxml2-2-2.10.3-150500.5.26.1">libxml2-2-2.10.3-150500.5.26.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libzypp-17.36.7-150600.3.53.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libzypp-17.36.7-150600.3.53.1">libzypp-17.36.7-150600.3.53.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="lvm2-2.03.22-150600.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:lvm2-2.03.22-150600.3.6.1">lvm2-2.03.22-150600.3.6.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ncurses-utils-6.1-150000.5.30.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:ncurses-utils-6.1-150000.5.30.1">ncurses-utils-6.1-150000.5.30.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="nscd-2.38-150600.14.32.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:nscd-2.38-150600.14.32.1">nscd-2.38-150600.14.32.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="nvme-cli-2.8+88.g21612f53-150600.3.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:nvme-cli-2.8+88.g21612f53-150600.3.15.1">nvme-cli-2.8+88.g21612f53-150600.3.15.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-9.6p1-150600.6.26.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:openssh-9.6p1-150600.6.26.1">openssh-9.6p1-150600.6.26.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-clients-9.6p1-150600.6.26.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:openssh-clients-9.6p1-150600.6.26.1">openssh-clients-9.6p1-150600.6.26.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-common-9.6p1-150600.6.26.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:openssh-common-9.6p1-150600.6.26.1">openssh-common-9.6p1-150600.6.26.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-server-9.6p1-150600.6.26.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:openssh-server-9.6p1-150600.6.26.1">openssh-server-9.6p1-150600.6.26.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssl-3-3.1.4-150600.5.27.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:openssl-3-3.1.4-150600.5.27.1">openssl-3-3.1.4-150600.5.27.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="pam-1.3.0-150000.6.76.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:pam-1.3.0-150000.6.76.1">pam-1.3.0-150000.6.76.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="patterns-base-minimal_base-20200124-150600.32.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:patterns-base-minimal_base-20200124-150600.32.6.1">patterns-base-minimal_base-20200124-150600.32.6.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="pkg-config-0.29.2-150600.15.6.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:pkg-config-0.29.2-150600.15.6.3">pkg-config-0.29.2-150600.15.6.3 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-salt-3006.0-150500.4.50.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:python3-salt-3006.0-150500.4.50.3">python3-salt-3006.0-150500.4.50.3 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-solv-0.7.32-150600.8.10.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:python3-solv-0.7.32-150600.8.10.1">python3-solv-0.7.32-150600.8.10.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ruby-solv-0.7.32-150600.8.10.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:ruby-solv-0.7.32-150600.8.10.1">ruby-solv-0.7.32-150600.8.10.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ruby2.5-2.5.9-150000.4.41.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:ruby2.5-2.5.9-150000.4.41.1">ruby2.5-2.5.9-150000.4.41.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ruby2.5-stdlib-2.5.9-150000.4.41.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:ruby2.5-stdlib-2.5.9-150000.4.41.1">ruby2.5-stdlib-2.5.9-150000.4.41.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="salt-3006.0-150500.4.50.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:salt-3006.0-150500.4.50.3">salt-3006.0-150500.4.50.3 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="salt-minion-3006.0-150500.4.50.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:salt-minion-3006.0-150500.4.50.3">salt-minion-3006.0-150500.4.50.3 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="samba-client-libs-4.19.8+git.422.34307c5a3aa-150600.3.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:samba-client-libs-4.19.8+git.422.34307c5a3aa-150600.3.15.1">samba-client-libs-4.19.8+git.422.34307c5a3aa-150600.3.15.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="sqlite3-tcl-3.49.1-150000.3.27.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:sqlite3-tcl-3.49.1-150000.3.27.1">sqlite3-tcl-3.49.1-150000.3.27.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="supportutils-3.2.10-150600.3.6.5" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:supportutils-3.2.10-150600.3.6.5">supportutils-3.2.10-150600.3.6.5 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="terminfo-6.1-150000.5.30.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:terminfo-6.1-150000.5.30.1">terminfo-6.1-150000.5.30.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="terminfo-base-6.1-150000.5.30.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:terminfo-base-6.1-150000.5.30.1">terminfo-base-6.1-150000.5.30.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="timezone-2025b-150600.91.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:timezone-2025b-150600.91.6.2">timezone-2025b-150600.91.6.2 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="zypper-1.14.89-150600.10.31.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:zypper-1.14.89-150600.10.31.1">zypper-1.14.89-150600.10.31.1 as a component of Public Cloud Image google/sles-15-sp6-byos-v20250528-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">xmltok_impl.c in Expat (aka libexpat) before 2.4.5 lacks certain validation of encoding, such as checks for whether a UTF-8 character is valid in a certain context.</Note>
    </Notes>
    <CVE>CVE-2022-25235</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libexpat1-2.7.1-150400.3.28.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>7.5</BaseScore>
        <Vector>AV:N/AC:L/Au:N/C:P/I:P/A:P</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">xmlparse.c in Expat (aka libexpat) before 2.4.5 allows attackers to insert namespace-separator characters into namespace URIs.</Note>
    </Notes>
    <CVE>CVE-2022-25236</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libexpat1-2.7.1-150400.3.28.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>7.5</BaseScore>
        <Vector>AV:N/AC:L/Au:N/C:P/I:P/A:P</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In Expat (aka libexpat) before 2.4.5, an attacker can trigger stack exhaustion in build_model via a large nesting depth in the DTD element.</Note>
    </Notes>
    <CVE>CVE-2022-25313</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libexpat1-2.7.1-150400.3.28.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>4.3</BaseScore>
        <Vector>AV:N/AC:M/Au:N/C:N/I:N/A:P</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In Expat (aka libexpat) before 2.4.5, there is an integer overflow in copyString.</Note>
    </Notes>
    <CVE>CVE-2022-25314</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libexpat1-2.7.1-150400.3.28.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>5</BaseScore>
        <Vector>AV:N/AC:L/Au:N/C:N/I:N/A:P</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In Expat (aka libexpat) before 2.4.5, there is an integer overflow in storeRawNames.</Note>
    </Notes>
    <CVE>CVE-2022-25315</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libexpat1-2.7.1-150400.3.28.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>7.5</BaseScore>
        <Vector>AV:N/AC:L/Au:N/C:P/I:P/A:P</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">libexpat before 2.4.9 has a use-after-free in the doContent function in xmlparse.c.</Note>
    </Notes>
    <CVE>CVE-2022-40674</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libexpat1-2.7.1-150400.3.28.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 libexpat through 2.4.9, there is a use-after free caused by overeager destruction of a shared DTD in XML_ExternalEntityParserCreate in out-of-memory situations.</Note>
    </Notes>
    <CVE>CVE-2022-43680</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libexpat1-2.7.1-150400.3.28.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">libexpat through 2.5.0 allows a denial of service (resource consumption) because many full reparsings are required in the case of a large token for which multiple buffer fills are needed.</Note>
    </Notes>
    <CVE>CVE-2023-52425</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libexpat1-2.7.1-150400.3.28.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:

cpu/hotplug: Don't offline the last non-isolated CPU

If a system has isolated CPUs via the "isolcpus=" command line parameter,
then an attempt to offline the last housekeeping CPU will result in a
WARN_ON() when rebuilding the scheduler domains and a subsequent panic due
to and unhandled empty CPU mas in partition_sched_domains_locked().

cpuset_hotplug_workfn()
  rebuild_sched_domains_locked()
    ndoms = generate_sched_domains(&amp;doms, &amp;attr);
      cpumask_and(doms[0], top_cpuset.effective_cpus, housekeeping_cpumask(HK_FLAG_DOMAIN));

Thus results in an empty CPU mask which triggers the warning and then the
subsequent crash:

WARNING: CPU: 4 PID: 80 at kernel/sched/topology.c:2366 build_sched_domains+0x120c/0x1408
Call trace:
 build_sched_domains+0x120c/0x1408
 partition_sched_domains_locked+0x234/0x880
 rebuild_sched_domains_locked+0x37c/0x798
 rebuild_sched_domains+0x30/0x58
 cpuset_hotplug_workfn+0x2a8/0x930

Unable to handle kernel paging request at virtual address fffe80027ab37080
 partition_sched_domains_locked+0x318/0x880
 rebuild_sched_domains_locked+0x37c/0x798

Aside of the resulting crash, it does not make any sense to offline the last
last housekeeping CPU.

Prevent this by masking out the non-housekeeping CPUs when selecting a
target CPU for initiating the CPU unplug operation via the work queue.</Note>
    </Notes>
    <CVE>CVE-2023-52831</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

IORING_OP_READ did not correctly consume the provided buffer list when
read i/o returned &lt; 0 (except for -EAGAIN and -EIOCBQUEUED return).
This can lead to a potential use-after-free when the completion via
io_rw_done runs at separate context.</Note>
    </Notes>
    <CVE>CVE-2023-52926</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

netfilter: allow exp not to be removed in nf_ct_find_expectation

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

This patch allows exp not to be removed by setting IPS_CONFIRMED
in the status of the tmpl.</Note>
    </Notes>
    <CVE>CVE-2023-52927</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ntb_hw_switchtec: Fix shift-out-of-bounds in switchtec_ntb_mw_set_trans

There is a kernel API ntb_mw_clear_trans() would pass 0 to both addr and
size. This would make xlate_pos negative.

[   23.734156] switchtec switchtec0: MW 0: part 0 addr 0x0000000000000000 size 0x0000000000000000
[   23.734158] ================================================================================
[   23.734172] UBSAN: shift-out-of-bounds in drivers/ntb/hw/mscc/ntb_hw_switchtec.c:293:7
[   23.734418] shift exponent -1 is negative

Ensuring xlate_pos is a positive or zero before BIT.</Note>
    </Notes>
    <CVE>CVE-2023-53034</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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 PAM. The secret information is stored in memory, where the attacker can trigger the victim program to execute by sending characters to its standard input (stdin). As this occurs, the attacker can train the branch predictor to execute an ROP chain speculatively. This flaw could result in leaked passwords, such as those found in /etc/shadow while performing authentications.</Note>
    </Notes>
    <CVE>CVE-2024-10041</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:apparmor-parser-3.1.7-150600.5.9.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:pam-1.3.0-150000.6.76.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:

net: fix removing a namespace with conflicting altnames

Mark reports a BUG() when a net namespace is removed.

    kernel BUG at net/core/dev.c:11520!

Physical interfaces moved outside of init_net get "refunded"
to init_net when that namespace disappears. The main interface
name may get overwritten in the process if it would have
conflicted. We need to also discard all conflicting altnames.
Recent fixes addressed ensuring that altnames get moved
with the main interface, which surfaced this problem.</Note>
    </Notes>
    <CVE>CVE-2024-26634</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

scsi: hisi_sas: Fix a deadlock issue related to automatic dump

If we issue a disabling PHY command, the device attached with it will go
offline, if a 2 bit ECC error occurs at the same time, a hung task may be
found:

[ 4613.652388] INFO: task kworker/u256:0:165233 blocked for more than 120 seconds.
[ 4613.666297] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 4613.674809] task:kworker/u256:0  state:D stack:    0 pid:165233 ppid:     2 flags:0x00000208
[ 4613.683959] Workqueue: 0000:74:02.0_disco_q sas_revalidate_domain [libsas]
[ 4613.691518] Call trace:
[ 4613.694678]  __switch_to+0xf8/0x17c
[ 4613.698872]  __schedule+0x660/0xee0
[ 4613.703063]  schedule+0xac/0x240
[ 4613.706994]  schedule_timeout+0x500/0x610
[ 4613.711705]  __down+0x128/0x36c
[ 4613.715548]  down+0x240/0x2d0
[ 4613.719221]  hisi_sas_internal_abort_timeout+0x1bc/0x260 [hisi_sas_main]
[ 4613.726618]  sas_execute_internal_abort+0x144/0x310 [libsas]
[ 4613.732976]  sas_execute_internal_abort_dev+0x44/0x60 [libsas]
[ 4613.739504]  hisi_sas_internal_task_abort_dev.isra.0+0xbc/0x1b0 [hisi_sas_main]
[ 4613.747499]  hisi_sas_dev_gone+0x174/0x250 [hisi_sas_main]
[ 4613.753682]  sas_notify_lldd_dev_gone+0xec/0x2e0 [libsas]
[ 4613.759781]  sas_unregister_common_dev+0x4c/0x7a0 [libsas]
[ 4613.765962]  sas_destruct_devices+0xb8/0x120 [libsas]
[ 4613.771709]  sas_do_revalidate_domain.constprop.0+0x1b8/0x31c [libsas]
[ 4613.778930]  sas_revalidate_domain+0x60/0xa4 [libsas]
[ 4613.784716]  process_one_work+0x248/0x950
[ 4613.789424]  worker_thread+0x318/0x934
[ 4613.793878]  kthread+0x190/0x200
[ 4613.797810]  ret_from_fork+0x10/0x18
[ 4613.802121] INFO: task kworker/u256:4:316722 blocked for more than 120 seconds.
[ 4613.816026] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 4613.824538] task:kworker/u256:4  state:D stack:    0 pid:316722 ppid:     2 flags:0x00000208
[ 4613.833670] Workqueue: 0000:74:02.0 hisi_sas_rst_work_handler [hisi_sas_main]
[ 4613.841491] Call trace:
[ 4613.844647]  __switch_to+0xf8/0x17c
[ 4613.848852]  __schedule+0x660/0xee0
[ 4613.853052]  schedule+0xac/0x240
[ 4613.856984]  schedule_timeout+0x500/0x610
[ 4613.861695]  __down+0x128/0x36c
[ 4613.865542]  down+0x240/0x2d0
[ 4613.869216]  hisi_sas_controller_prereset+0x58/0x1fc [hisi_sas_main]
[ 4613.876324]  hisi_sas_rst_work_handler+0x40/0x8c [hisi_sas_main]
[ 4613.883019]  process_one_work+0x248/0x950
[ 4613.887732]  worker_thread+0x318/0x934
[ 4613.892204]  kthread+0x190/0x200
[ 4613.896118]  ret_from_fork+0x10/0x18
[ 4613.900423] INFO: task kworker/u256:1:348985 blocked for more than 121 seconds.
[ 4613.914341] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 4613.922852] task:kworker/u256:1  state:D stack:    0 pid:348985 ppid:     2 flags:0x00000208
[ 4613.931984] Workqueue: 0000:74:02.0_event_q sas_port_event_worker [libsas]
[ 4613.939549] Call trace:
[ 4613.942702]  __switch_to+0xf8/0x17c
[ 4613.946892]  __schedule+0x660/0xee0
[ 4613.951083]  schedule+0xac/0x240
[ 4613.955015]  schedule_timeout+0x500/0x610
[ 4613.959725]  wait_for_common+0x200/0x610
[ 4613.964349]  wait_for_completion+0x3c/0x5c
[ 4613.969146]  flush_workqueue+0x198/0x790
[ 4613.973776]  sas_porte_broadcast_rcvd+0x1e8/0x320 [libsas]
[ 4613.979960]  sas_port_event_worker+0x54/0xa0 [libsas]
[ 4613.985708]  process_one_work+0x248/0x950
[ 4613.990420]  worker_thread+0x318/0x934
[ 4613.994868]  kthread+0x190/0x200
[ 4613.998800]  ret_from_fork+0x10/0x18

This is because when the device goes offline, we obtain the hisi_hba
semaphore and send the ABORT_DEV command to the device. However, the
internal abort timed out due to the 2 bit ECC error and triggers automatic
dump. In addition, since the hisi_hba semaphore has been obtained, the dump
cannot be executed and the controller cannot be reset.

Therefore, the deadlocks occur on the following circular dependencies
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-26873</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

netfilter: bridge: confirm multicast packets before passing them up the stack

conntrack nf_confirm logic cannot handle cloned skbs referencing
the same nf_conn entry, which will happen for multicast (broadcast)
frames on bridges.

 Example:
    macvlan0
       |
      br0
     /  \
  ethX    ethY

 ethX (or Y) receives a L2 multicast or broadcast packet containing
 an IP packet, flow is not yet in conntrack table.

 1. skb passes through bridge and fake-ip (br_netfilter)Prerouting.
    -&gt; skb-&gt;_nfct now references a unconfirmed entry
 2. skb is broad/mcast packet. bridge now passes clones out on each bridge
    interface.
 3. skb gets passed up the stack.
 4. In macvlan case, macvlan driver retains clone(s) of the mcast skb
    and schedules a work queue to send them out on the lower devices.

    The clone skb-&gt;_nfct is not a copy, it is the same entry as the
    original skb.  The macvlan rx handler then returns RX_HANDLER_PASS.
 5. Normal conntrack hooks (in NF_INET_LOCAL_IN) confirm the orig skb.

The Macvlan broadcast worker and normal confirm path will race.

This race will not happen if step 2 already confirmed a clone. In that
case later steps perform skb_clone() with skb-&gt;_nfct already confirmed (in
hash table).  This works fine.

But such confirmation won't happen when eb/ip/nftables rules dropped the
packets before they reached the nf_confirm step in postrouting.

Pablo points out that nf_conntrack_bridge doesn't allow use of stateful
nat, so we can safely discard the nf_conn entry and let inet call
conntrack again.

This doesn't work for bridge netfilter: skb could have a nat
transformation. Also bridge nf prevents re-invocation of inet prerouting
via 'sabotage_in' hook.

Work around this problem by explicit confirmation of the entry at LOCAL_IN
time, before upper layer has a chance to clone the unconfirmed entry.

The downside is that this disables NAT and conntrack helpers.

Alternative fix would be to add locking to all code parts that deal with
unconfirmed packets, but even if that could be done in a sane way this
opens up other problems, for example:

-m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4
-m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5

For multicast case, only one of such conflicting mappings will be
created, conntrack only handles 1:1 NAT mappings.

Users should set create a setup that explicitly marks such traffic
NOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypass
them, ruleset might have accept rules for untracked traffic already,
so user-visible behaviour would change.</Note>
    </Notes>
    <CVE>CVE-2024-27415</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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">libexpat through 2.6.1 allows an XML Entity Expansion attack when there is isolated use of external parsers (created via XML_ExternalEntityParserCreate).</Note>
    </Notes>
    <CVE>CVE-2024-28757</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libexpat1-2.7.1-150400.3.28.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">Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.</Note>
    </Notes>
    <CVE>CVE-2024-28956</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

block: Fix page refcounts for unaligned buffers in __bio_release_pages()

Fix an incorrect number of pages being released for buffers that do not
start at the beginning of a page.</Note>
    </Notes>
    <CVE>CVE-2024-35826</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()

subflow_finish_connect() uses four fields (backup, join_id, thmac, none)
that may contain garbage unless OPTION_MPTCP_MPJ_SYNACK has been set
in mptcp_parse_option()</Note>
    </Notes>
    <CVE>CVE-2024-35840</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

tcp: properly terminate timers for kernel sockets

We had various syzbot reports about tcp timers firing after
the corresponding netns has been dismantled.

Fortunately Josef Bacik could trigger the issue more often,
and could test a patch I wrote two years ago.

When TCP sockets are closed, we call inet_csk_clear_xmit_timers()
to 'stop' the timers.

inet_csk_clear_xmit_timers() can be called from any context,
including when socket lock is held.
This is the reason it uses sk_stop_timer(), aka del_timer().
This means that ongoing timers might finish much later.

For user sockets, this is fine because each running timer
holds a reference on the socket, and the user socket holds
a reference on the netns.

For kernel sockets, we risk that the netns is freed before
timer can complete, because kernel sockets do not hold
reference on the netns.

This patch adds inet_csk_clear_xmit_timers_sync() function
that using sk_stop_timer_sync() to make sure all timers
are terminated before the kernel socket is released.
Modules using kernel sockets close them in their netns exit()
handler.

Also add sock_not_owned_by_me() helper to get LOCKDEP
support : inet_csk_clear_xmit_timers_sync() must not be called
while socket lock is held.

It is very possible we can revert in the future commit
3a58f13a881e ("net: rds: acquire refcount on TCP sockets")
which attempted to solve the issue in rds only.
(net/smc/af_smc.c and net/mptcp/subflow.c have similar code)

We probably can remove the check_net() tests from
tcp_out_of_resources() and __tcp_close() in the future.</Note>
    </Notes>
    <CVE>CVE-2024-35910</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

crypto: qat - validate slices count returned by FW

The function adf_send_admin_tl_start() enables the telemetry (TL)
feature on a QAT device by sending the ICP_QAT_FW_TL_START message to
the firmware. This triggers the FW to start writing TL data to a DMA
buffer in memory and returns an array containing the number of
accelerators of each type (slices) supported by this HW.
The pointer to this array is stored in the adf_tl_hw_data data
structure called slice_cnt.

The array slice_cnt is then used in the function tl_print_dev_data()
to report in debugfs only statistics about the supported accelerators.
An incorrect value of the elements in slice_cnt might lead to an out
of bounds memory read.
At the moment, there isn't an implementation of FW that returns a wrong
value, but for robustness validate the slice count array returned by FW.</Note>
    </Notes>
    <CVE>CVE-2024-38606</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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">containerd is an open-source container runtime. A bug was found in containerd prior to versions 1.6.38, 1.7.27, and 2.0.4 where containers launched with a User set as a `UID:GID` larger than the maximum 32-bit signed integer can cause an overflow condition where the container ultimately runs as root (UID 0). This could cause unexpected behavior for environments that require containers to run as a non-root user. This bug has been fixed in containerd 1.6.38, 1.7.27, and 2.04. As a workaround, ensure that only trusted images are used and that only trusted users have permissions to import images.</Note>
    </Notes>
    <CVE>CVE-2024-40635</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:containerd-1.7.27-150000.123.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:

netpoll: Fix race condition in netpoll_owner_active

KCSAN detected a race condition in netpoll:

	BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb
	write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10:
	net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822)
&lt;snip&gt;
	read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2:
	netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393)
	netpoll_send_udp (net/core/netpoll.c:?)
&lt;snip&gt;
	value changed: 0x0000000a -&gt; 0xffffffff

This happens because netpoll_owner_active() needs to check if the
current CPU is the owner of the lock, touching napi-&gt;poll_owner
non atomically. The -&gt;poll_owner field contains the current CPU holding
the lock.

Use an atomic read to check if the poll owner is the current CPU.</Note>
    </Notes>
    <CVE>CVE-2024-41005</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

null_blk: fix validation of block size

Block size should be between 512 and PAGE_SIZE and be a power of 2. The current
check does not validate this, so update the check.

Without this patch, null_blk would Oops due to a null pointer deref when
loaded with bs=1536 [1].


[axboe: remove unnecessary braces and != 0 check]</Note>
    </Notes>
    <CVE>CVE-2024-41077</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

block: avoid to reuse `hctx` not removed from cpuhp callback list

If the 'hctx' isn't removed from cpuhp callback list, we can't reuse it,
otherwise use-after-free may be triggered.</Note>
    </Notes>
    <CVE>CVE-2024-41149</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

cifs: fix potential null pointer use in destroy_workqueue in init_cifs error path

Dan Carpenter reported a Smack static checker warning:
   fs/smb/client/cifsfs.c:1981 init_cifs()
   error: we previously assumed 'serverclose_wq' could be null (see line 1895)

The patch which introduced the serverclose workqueue used the wrong
oredering in error paths in init_cifs() for freeing it on errors.</Note>
    </Notes>
    <CVE>CVE-2024-42307</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

dm-raid: Fix WARN_ON_ONCE check for sync_thread in raid_resume

rm-raid devices will occasionally trigger the following warning when
being resumed after a table load because DM_RECOVERY_RUNNING is set:

WARNING: CPU: 7 PID: 5660 at drivers/md/dm-raid.c:4105 raid_resume+0xee/0x100 [dm_raid]

The failing check is:
WARN_ON_ONCE(test_bit(MD_RECOVERY_RUNNING, &amp;mddev-&gt;recovery));

This check is designed to make sure that the sync thread isn't
registered, but md_check_recovery can set MD_RECOVERY_RUNNING without
the sync_thread ever getting registered. Instead of checking if
MD_RECOVERY_RUNNING is set, check if sync_thread is non-NULL.</Note>
    </Notes>
    <CVE>CVE-2024-43820</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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">An issue was discovered in libexpat before 2.6.3. xmlparse.c does not reject a negative length for XML_ParseBuffer.</Note>
    </Notes>
    <CVE>CVE-2024-45490</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libexpat1-2.7.1-150400.3.28.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">An issue was discovered in libexpat before 2.6.3. dtdCopy in xmlparse.c can have an integer overflow for nDefaultAtts on 32-bit platforms (where UINT_MAX equals SIZE_MAX).</Note>
    </Notes>
    <CVE>CVE-2024-45491</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libexpat1-2.7.1-150400.3.28.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">An issue was discovered in libexpat before 2.6.3. nextScaffoldPart in xmlparse.c can have an integer overflow for m_groupSize on 32-bit platforms (where UINT_MAX equals SIZE_MAX).</Note>
    </Notes>
    <CVE>CVE-2024-45492</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libexpat1-2.7.1-150400.3.28.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:

smb: client: fix double put of @cfile in smb2_rename_path()

If smb2_set_path_attr() is called with a valid @cfile and returned
-EINVAL, we need to call cifs_get_writable_path() again as the
reference of @cfile was already dropped by previous smb2_compound_op()
call.</Note>
    </Notes>
    <CVE>CVE-2024-46736</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

fou: Fix null-ptr-deref in GRO.

We observed a null-ptr-deref in fou_gro_receive() while shutting down
a host.  [0]

The NULL pointer is sk-&gt;sk_user_data, and the offset 8 is of protocol
in struct fou.

When fou_release() is called due to netns dismantle or explicit tunnel
teardown, udp_tunnel_sock_release() sets NULL to sk-&gt;sk_user_data.
Then, the tunnel socket is destroyed after a single RCU grace period.

So, in-flight udp4_gro_receive() could find the socket and execute the
FOU GRO handler, where sk-&gt;sk_user_data could be NULL.

Let's use rcu_dereference_sk_user_data() in fou_from_sock() and add NULL
checks in FOU GRO handlers.

[0]:
BUG: kernel NULL pointer dereference, address: 0000000000000008
 PF: supervisor read access in kernel mode
 PF: error_code(0x0000) - not-present page
PGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0
SMP PTI
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1
Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017
RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou]
Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 &lt;0f&gt; b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42
RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297
RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010
RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08
RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002
R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400
R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0
FS:  0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 &lt;IRQ&gt;
 ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259)
 ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420)
 ? no_context (arch/x86/mm/fault.c:752)
 ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483)
 ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571)
 ? fou_gro_receive (net/ipv4/fou.c:233) [fou]
 udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559)
 udp4_gro_receive (net/ipv4/udp_offload.c:604)
 inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7))
 dev_gro_receive (net/core/dev.c:6035 (discriminator 4))
 napi_gro_receive (net/core/dev.c:6170)
 ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena]
 ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena]
 napi_poll (net/core/dev.c:6847)
 net_rx_action (net/core/dev.c:6917)
 __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299)
 asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809)
&lt;/IRQ&gt;
 do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77)
 irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435)
 common_interrupt (arch/x86/kernel/irq.c:239)
 asm_common_interrupt (arch/x86/include/asm/idtentry.h:626)
RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575)
Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 &lt;fa&gt; c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00
RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246
RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900
RDX: ffff93daee800000 RSI: ffff93d
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-46763</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ila: call nf_unregister_net_hooks() sooner

syzbot found an use-after-free Read in ila_nf_input [1]

Issue here is that ila_xlat_exit_net() frees the rhashtable,
then call nf_unregister_net_hooks().

It should be done in the reverse way, with a synchronize_rcu().

This is a good match for a pre_exit() method.

[1]
 BUG: KASAN: use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline]
 BUG: KASAN: use-after-free in __rhashtable_lookup include/linux/rhashtable.h:604 [inline]
 BUG: KASAN: use-after-free in rhashtable_lookup include/linux/rhashtable.h:646 [inline]
 BUG: KASAN: use-after-free in rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672
Read of size 4 at addr ffff888064620008 by task ksoftirqd/0/16

CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.11.0-rc4-syzkaller-00238-g2ad6d23f465a #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
Call Trace:
 &lt;TASK&gt;
  __dump_stack lib/dump_stack.c:93 [inline]
  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
  print_address_description mm/kasan/report.c:377 [inline]
  print_report+0x169/0x550 mm/kasan/report.c:488
  kasan_report+0x143/0x180 mm/kasan/report.c:601
  rht_key_hashfn include/linux/rhashtable.h:159 [inline]
  __rhashtable_lookup include/linux/rhashtable.h:604 [inline]
  rhashtable_lookup include/linux/rhashtable.h:646 [inline]
  rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672
  ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:132 [inline]
  ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline]
  ila_nf_input+0x1fe/0x3c0 net/ipv6/ila/ila_xlat.c:190
  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
  nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626
  nf_hook include/linux/netfilter.h:269 [inline]
  NF_HOOK+0x29e/0x450 include/linux/netfilter.h:312
  __netif_receive_skb_one_core net/core/dev.c:5661 [inline]
  __netif_receive_skb+0x1ea/0x650 net/core/dev.c:5775
  process_backlog+0x662/0x15b0 net/core/dev.c:6108
  __napi_poll+0xcb/0x490 net/core/dev.c:6772
  napi_poll net/core/dev.c:6841 [inline]
  net_rx_action+0x89b/0x1240 net/core/dev.c:6963
  handle_softirqs+0x2c4/0x970 kernel/softirq.c:554
  run_ksoftirqd+0xca/0x130 kernel/softirq.c:928
  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;

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x64620
flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
page_type: 0xbfffffff(buddy)
raw: 00fff00000000000 ffffea0000959608 ffffea00019d9408 0000000000000000
raw: 0000000000000000 0000000000000003 00000000bfffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as freed
page last allocated via order 3, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 5242, tgid 5242 (syz-executor), ts 73611328570, free_ts 618981657187
  set_page_owner include/linux/page_owner.h:32 [inline]
  post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493
  prep_new_page mm/page_alloc.c:1501 [inline]
  get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3439
  __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695
  __alloc_pages_node_noprof include/linux/gfp.h:269 [inline]
  alloc_pages_node_noprof include/linux/gfp.h:296 [inline]
  ___kmalloc_large_node+0x8b/0x1d0 mm/slub.c:4103
  __kmalloc_large_node_noprof+0x1a/0x80 mm/slub.c:4130
  __do_kmalloc_node mm/slub.c:4146 [inline]
  __kmalloc_node_noprof+0x2d2/0x440 mm/slub.c:4164
  __kvmalloc_node_noprof+0x72/0x190 mm/util.c:650
  bucket_table_alloc lib/rhashtable.c:186 [inline]
  rhashtable_init_noprof+0x534/0xa60 lib/rhashtable.c:1071
  ila_xlat_init_net+0xa0/0x110 net/ipv6/ila/ila_xlat.c:613
  ops_ini
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-46782</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

smb: client: fix double put of @cfile in smb2_set_path_size()

If smb2_compound_op() is called with a valid @cfile and returned
-EINVAL, we need to call cifs_get_writable_path() before retrying it
as the reference of @cfile was already dropped by previous call.

This fixes the following KASAN splat when running fstests generic/013
against Windows Server 2022:

  CIFS: Attempting to mount //w22-fs0/scratch
  run fstests generic/013 at 2024-09-02 19:48:59
  ==================================================================
  BUG: KASAN: slab-use-after-free in detach_if_pending+0xab/0x200
  Write of size 8 at addr ffff88811f1a3730 by task kworker/3:2/176

  CPU: 3 UID: 0 PID: 176 Comm: kworker/3:2 Not tainted 6.11.0-rc6 #2
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40
  04/01/2014
  Workqueue: cifsoplockd cifs_oplock_break [cifs]
  Call Trace:
   &lt;TASK&gt;
   dump_stack_lvl+0x5d/0x80
   ? detach_if_pending+0xab/0x200
   print_report+0x156/0x4d9
   ? detach_if_pending+0xab/0x200
   ? __virt_addr_valid+0x145/0x300
   ? __phys_addr+0x46/0x90
   ? detach_if_pending+0xab/0x200
   kasan_report+0xda/0x110
   ? detach_if_pending+0xab/0x200
   detach_if_pending+0xab/0x200
   timer_delete+0x96/0xe0
   ? __pfx_timer_delete+0x10/0x10
   ? rcu_is_watching+0x20/0x50
   try_to_grab_pending+0x46/0x3b0
   __cancel_work+0x89/0x1b0
   ? __pfx___cancel_work+0x10/0x10
   ? kasan_save_track+0x14/0x30
   cifs_close_deferred_file+0x110/0x2c0 [cifs]
   ? __pfx_cifs_close_deferred_file+0x10/0x10 [cifs]
   ? __pfx_down_read+0x10/0x10
   cifs_oplock_break+0x4c1/0xa50 [cifs]
   ? __pfx_cifs_oplock_break+0x10/0x10 [cifs]
   ? lock_is_held_type+0x85/0xf0
   ? mark_held_locks+0x1a/0x90
   process_one_work+0x4c6/0x9f0
   ? find_held_lock+0x8a/0xa0
   ? __pfx_process_one_work+0x10/0x10
   ? lock_acquired+0x220/0x550
   ? __list_add_valid_or_report+0x37/0x100
   worker_thread+0x2e4/0x570
   ? __kthread_parkme+0xd1/0xf0
   ? __pfx_worker_thread+0x10/0x10
   kthread+0x17f/0x1c0
   ? kthread+0xda/0x1c0
   ? __pfx_kthread+0x10/0x10
   ret_from_fork+0x31/0x60
   ? __pfx_kthread+0x10/0x10
   ret_from_fork_asm+0x1a/0x30
   &lt;/TASK&gt;

  Allocated by task 1118:
   kasan_save_stack+0x30/0x50
   kasan_save_track+0x14/0x30
   __kasan_kmalloc+0xaa/0xb0
   cifs_new_fileinfo+0xc8/0x9d0 [cifs]
   cifs_atomic_open+0x467/0x770 [cifs]
   lookup_open.isra.0+0x665/0x8b0
   path_openat+0x4c3/0x1380
   do_filp_open+0x167/0x270
   do_sys_openat2+0x129/0x160
   __x64_sys_creat+0xad/0xe0
   do_syscall_64+0xbb/0x1d0
   entry_SYSCALL_64_after_hwframe+0x77/0x7f

  Freed by task 83:
   kasan_save_stack+0x30/0x50
   kasan_save_track+0x14/0x30
   kasan_save_free_info+0x3b/0x70
   poison_slab_object+0xe9/0x160
   __kasan_slab_free+0x32/0x50
   kfree+0xf2/0x300
   process_one_work+0x4c6/0x9f0
   worker_thread+0x2e4/0x570
   kthread+0x17f/0x1c0
   ret_from_fork+0x31/0x60
   ret_from_fork_asm+0x1a/0x30

  Last potentially related work creation:
   kasan_save_stack+0x30/0x50
   __kasan_record_aux_stack+0xad/0xc0
   insert_work+0x29/0xe0
   __queue_work+0x5ea/0x760
   queue_work_on+0x6d/0x90
   _cifsFileInfo_put+0x3f6/0x770 [cifs]
   smb2_compound_op+0x911/0x3940 [cifs]
   smb2_set_path_size+0x228/0x270 [cifs]
   cifs_set_file_size+0x197/0x460 [cifs]
   cifs_setattr+0xd9c/0x14b0 [cifs]
   notify_change+0x4e3/0x740
   do_truncate+0xfa/0x180
   vfs_truncate+0x195/0x200
   __x64_sys_truncate+0x109/0x150
   do_syscall_64+0xbb/0x1d0
   entry_SYSCALL_64_after_hwframe+0x77/0x7f</Note>
    </Notes>
    <CVE>CVE-2024-46796</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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">An issue was discovered in the WEBrick toolkit through 1.8.1 for Ruby. It allows HTTP request smuggling by providing both a Content-Length header and a Transfer-Encoding header, e.g., "GET /admin HTTP/1.1\r\n" inside of a "POST /user HTTP/1.1\r\n" request. NOTE: the supplier's position is "Webrick should not be used in production."</Note>
    </Notes>
    <CVE>CVE-2024-47220</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libruby2_5-2_5-2.5.9-150000.4.41.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:ruby2.5-2.5.9-150000.4.41.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:ruby2.5-stdlib-2.5.9-150000.4.41.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:

net/smc: check smcd_v2_ext_offset when receiving proposal msg

When receiving proposal msg in server, the field smcd_v2_ext_offset in
proposal msg is from the remote client and can not be fully trusted.
Once the value of smcd_v2_ext_offset exceed the max value, there has
the chance to access wrong address, and crash may happen.

This patch checks the value of smcd_v2_ext_offset before using it.</Note>
    </Notes>
    <CVE>CVE-2024-47408</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

bpf: Prevent tailcall infinite loop caused by freplace

There is a potential infinite loop issue that can occur when using a
combination of tail calls and freplace.

In an upcoming selftest, the attach target for entry_freplace of
tailcall_freplace.c is subprog_tc of tc_bpf2bpf.c, while the tail call in
entry_freplace leads to entry_tc. This results in an infinite loop:

entry_tc -&gt; subprog_tc -&gt; entry_freplace --tailcall-&gt; entry_tc.

The problem arises because the tail_call_cnt in entry_freplace resets to
zero each time entry_freplace is executed, causing the tail call mechanism
to never terminate, eventually leading to a kernel panic.

To fix this issue, the solution is twofold:

1. Prevent updating a program extended by an freplace program to a
   prog_array map.
2. Prevent extending a program that is already part of a prog_array map
   with an freplace program.

This ensures that:

* If a program or its subprogram has been extended by an freplace program,
  it can no longer be updated to a prog_array map.
* If a program has been added to a prog_array map, neither it nor its
  subprograms can be extended by an freplace program.

Moreover, an extension program should not be tailcalled. As such, return
-EINVAL if the program has a type of BPF_PROG_TYPE_EXT when adding it to a
prog_array map.

Additionally, fix a minor code style issue by replacing eight spaces with a
tab for proper formatting.</Note>
    </Notes>
    <CVE>CVE-2024-47794</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net/smc: check iparea_offset and ipv6_prefixes_cnt when receiving proposal msg

When receiving proposal msg in server, the field iparea_offset
and the field ipv6_prefixes_cnt in proposal msg are from the
remote client and can not be fully trusted. Especially the
field iparea_offset, once exceed the max value, there has the
chance to access wrong address, and crash may happen.

This patch checks iparea_offset and ipv6_prefixes_cnt before using them.</Note>
    </Notes>
    <CVE>CVE-2024-49571</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

fbdev: pxafb: Fix possible use after free in pxafb_task()

In the pxafb_probe function, it calls the pxafb_init_fbinfo function,
after which &amp;fbi-&gt;task is associated with pxafb_task. Moreover,
within this pxafb_init_fbinfo function, the pxafb_blank function
within the &amp;pxafb_ops struct is capable of scheduling work.

If we remove the module which will call pxafb_remove to make cleanup,
it will call unregister_framebuffer function which can call
do_unregister_framebuffer to free fbi-&gt;fb through
put_fb_info(fb_info), while the work mentioned above will be used.
The sequence of operations that may lead to a UAF bug is as follows:

CPU0                                                CPU1

                                   | pxafb_task
pxafb_remove                       |
unregister_framebuffer(info)       |
do_unregister_framebuffer(fb_info) |
put_fb_info(fb_info)               |
// free fbi-&gt;fb                    | set_ctrlr_state(fbi, state)
                                   | __pxafb_lcd_power(fbi, 0)
                                   | fbi-&gt;lcd_power(on, &amp;fbi-&gt;fb.var)
                                   | //use fbi-&gt;fb

Fix it by ensuring that the work is canceled before proceeding
with the cleanup in pxafb_remove.

Note that only root user can remove the driver at runtime.</Note>
    </Notes>
    <CVE>CVE-2024-49924</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

l2tp: prevent possible tunnel refcount underflow

When a session is created, it sets a backpointer to its tunnel. When
the session refcount drops to 0, l2tp_session_free drops the tunnel
refcount if session-&gt;tunnel is non-NULL. However, session-&gt;tunnel is
set in l2tp_session_create, before the tunnel refcount is incremented
by l2tp_session_register, which leaves a small window where
session-&gt;tunnel is non-NULL when the tunnel refcount hasn't been
bumped.

Moving the assignment to l2tp_session_register is trivial but
l2tp_session_create calls l2tp_session_set_header_len which uses
session-&gt;tunnel to get the tunnel's encap. Add an encap arg to
l2tp_session_set_header_len to avoid using session-&gt;tunnel.

If l2tpv3 sessions have colliding IDs, it is possible for
l2tp_v3_session_get to race with l2tp_session_register and fetch a
session which doesn't yet have session-&gt;tunnel set. Add a check for
this case.</Note>
    </Notes>
    <CVE>CVE-2024-49940</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

block: fix integer overflow in BLKSECDISCARD

I independently rediscovered

	commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155
	block: fix overflow in blk_ioctl_discard()

but for secure erase.

Same problem:

	uint64_t r[2] = {512, 18446744073709551104ULL};
	ioctl(fd, BLKSECDISCARD, r);

will enter near infinite loop inside blkdev_issue_secure_erase():

	a.out: attempt to access beyond end of device
	loop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048
	bio_check_eod: 3286214 callbacks suppressed</Note>
    </Notes>
    <CVE>CVE-2024-49994</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

netfilter: xtables: avoid NFPROTO_UNSPEC where needed

syzbot managed to call xt_cluster match via ebtables:

 WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780
 [..]
 ebt_do_table+0x174b/0x2a40

Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet
processing.  As this is only useful to restrict locally terminating
TCP/UDP traffic, register this for ipv4 and ipv6 family only.

Pablo points out that this is a general issue, direct users of the
set/getsockopt interface can call into targets/matches that were only
intended for use with ip(6)tables.

Check all UNSPEC matches and targets for similar issues:

- matches and targets are fine except if they assume skb_network_header()
  is valid -- this is only true when called from inet layer: ip(6) stack
  pulls the ip/ipv6 header into linear data area.
- targets that return XT_CONTINUE or other xtables verdicts must be
  restricted too, they are incompatbile with the ebtables traverser, e.g.
  EBT_CONTINUE is a completely different value than XT_CONTINUE.

Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as
they are provided for use by ip(6)tables.

The MARK target is also used by arptables, so register for NFPROTO_ARP too.

While at it, bail out if connbytes fails to enable the corresponding
conntrack family.

This change passes the selftests in iptables.git.</Note>
    </Notes>
    <CVE>CVE-2024-50038</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c

Fix potential dereferencing of ERR_PTR() in find_format_by_pix()
and uvc_v4l2_enum_format().

Fix the following smatch errors:

drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix()
error: 'fmtdesc' dereferencing possible ERR_PTR()

drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format()
error: 'fmtdesc' dereferencing possible ERR_PTR()

Also, fix similar issue in uvc_v4l2_try_format() for potential
dereferencing of ERR_PTR().</Note>
    </Notes>
    <CVE>CVE-2024-50056</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

tcp: fix mptcp DSS corruption due to large pmtu xmit

Syzkaller was able to trigger a DSS corruption:

  TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies.
  ------------[ cut here ]------------
  WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695
  Modules linked in:
  CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0
  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
  RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695
  Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 &lt;0f&gt; 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff
  RSP: 0018:ffffc90000006db8 EFLAGS: 00010246
  RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00
  RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0
  RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8
  R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000
  R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5
  FS:  000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  Call Trace:
   &lt;IRQ&gt;
   move_skbs_to_msk net/mptcp/protocol.c:811 [inline]
   mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854
   subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490
   tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283
   tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237
   tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915
   tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350
   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:5662 [inline]
   __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775
   process_backlog+0x662/0x15b0 net/core/dev.c:6107
   __napi_poll+0xcb/0x490 net/core/dev.c:6771
   napi_poll net/core/dev.c:6840 [inline]
   net_rx_action+0x89b/0x1240 net/core/dev.c:6962
   handle_softirqs+0x2c5/0x980 kernel/softirq.c:554
   do_softirq+0x11b/0x1e0 kernel/softirq.c:455
   &lt;/IRQ&gt;
   &lt;TASK&gt;
   __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382
   local_bh_enable include/linux/bottom_half.h:33 [inline]
   rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]
   __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451
   dev_queue_xmit include/linux/netdevice.h:3094 [inline]
   neigh_hh_output include/net/neighbour.h:526 [inline]
   neigh_output include/net/neighbour.h:540 [inline]
   ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236
   ip_local_out net/ipv4/ip_output.c:130 [inline]
   __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536
   __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466
   tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]
   tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline]
   tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752
   __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015
   tcp_push_pending_frames include/net/tcp.h:2107 [inline]
   tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline]
   tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239
   tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915
   sk_backlog_rcv include/net/sock.h:1113 [inline]
   __release_sock+0x214/0x350 net/core/sock.c:3072
   release_sock+0x61/0x1f0 net/core/sock.c:3626
   mptcp_push_
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-50083</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net: sched: use RCU read-side critical section in taprio_dump()

Fix possible use-after-free in 'taprio_dump()' by adding RCU
read-side critical section there. Never seen on x86 but
found on a KASAN-enabled arm64 system when investigating
https://syzkaller.appspot.com/bug?extid=b65e0af58423fc8a73aa:

[T15862] BUG: KASAN: slab-use-after-free in taprio_dump+0xa0c/0xbb0
[T15862] Read of size 4 at addr ffff0000d4bb88f8 by task repro/15862
[T15862]
[T15862] CPU: 0 UID: 0 PID: 15862 Comm: repro Not tainted 6.11.0-rc1-00293-gdefaf1a2113a-dirty #2
[T15862] Hardware name: QEMU QEMU Virtual Machine, BIOS edk2-20240524-5.fc40 05/24/2024
[T15862] Call trace:
[T15862]  dump_backtrace+0x20c/0x220
[T15862]  show_stack+0x2c/0x40
[T15862]  dump_stack_lvl+0xf8/0x174
[T15862]  print_report+0x170/0x4d8
[T15862]  kasan_report+0xb8/0x1d4
[T15862]  __asan_report_load4_noabort+0x20/0x2c
[T15862]  taprio_dump+0xa0c/0xbb0
[T15862]  tc_fill_qdisc+0x540/0x1020
[T15862]  qdisc_notify.isra.0+0x330/0x3a0
[T15862]  tc_modify_qdisc+0x7b8/0x1838
[T15862]  rtnetlink_rcv_msg+0x3c8/0xc20
[T15862]  netlink_rcv_skb+0x1f8/0x3d4
[T15862]  rtnetlink_rcv+0x28/0x40
[T15862]  netlink_unicast+0x51c/0x790
[T15862]  netlink_sendmsg+0x79c/0xc20
[T15862]  __sock_sendmsg+0xe0/0x1a0
[T15862]  ____sys_sendmsg+0x6c0/0x840
[T15862]  ___sys_sendmsg+0x1ac/0x1f0
[T15862]  __sys_sendmsg+0x110/0x1d0
[T15862]  __arm64_sys_sendmsg+0x74/0xb0
[T15862]  invoke_syscall+0x88/0x2e0
[T15862]  el0_svc_common.constprop.0+0xe4/0x2a0
[T15862]  do_el0_svc+0x44/0x60
[T15862]  el0_svc+0x50/0x184
[T15862]  el0t_64_sync_handler+0x120/0x12c
[T15862]  el0t_64_sync+0x190/0x194
[T15862]
[T15862] Allocated by task 15857:
[T15862]  kasan_save_stack+0x3c/0x70
[T15862]  kasan_save_track+0x20/0x3c
[T15862]  kasan_save_alloc_info+0x40/0x60
[T15862]  __kasan_kmalloc+0xd4/0xe0
[T15862]  __kmalloc_cache_noprof+0x194/0x334
[T15862]  taprio_change+0x45c/0x2fe0
[T15862]  tc_modify_qdisc+0x6a8/0x1838
[T15862]  rtnetlink_rcv_msg+0x3c8/0xc20
[T15862]  netlink_rcv_skb+0x1f8/0x3d4
[T15862]  rtnetlink_rcv+0x28/0x40
[T15862]  netlink_unicast+0x51c/0x790
[T15862]  netlink_sendmsg+0x79c/0xc20
[T15862]  __sock_sendmsg+0xe0/0x1a0
[T15862]  ____sys_sendmsg+0x6c0/0x840
[T15862]  ___sys_sendmsg+0x1ac/0x1f0
[T15862]  __sys_sendmsg+0x110/0x1d0
[T15862]  __arm64_sys_sendmsg+0x74/0xb0
[T15862]  invoke_syscall+0x88/0x2e0
[T15862]  el0_svc_common.constprop.0+0xe4/0x2a0
[T15862]  do_el0_svc+0x44/0x60
[T15862]  el0_svc+0x50/0x184
[T15862]  el0t_64_sync_handler+0x120/0x12c
[T15862]  el0t_64_sync+0x190/0x194
[T15862]
[T15862] Freed by task 6192:
[T15862]  kasan_save_stack+0x3c/0x70
[T15862]  kasan_save_track+0x20/0x3c
[T15862]  kasan_save_free_info+0x4c/0x80
[T15862]  poison_slab_object+0x110/0x160
[T15862]  __kasan_slab_free+0x3c/0x74
[T15862]  kfree+0x134/0x3c0
[T15862]  taprio_free_sched_cb+0x18c/0x220
[T15862]  rcu_core+0x920/0x1b7c
[T15862]  rcu_core_si+0x10/0x1c
[T15862]  handle_softirqs+0x2e8/0xd64
[T15862]  __do_softirq+0x14/0x20</Note>
    </Notes>
    <CVE>CVE-2024-50126</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

sched/core: Disable page allocation in task_tick_mm_cid()

With KASAN and PREEMPT_RT enabled, calling task_work_add() in
task_tick_mm_cid() may cause the following splat.

[   63.696416] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
[   63.696416] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 610, name: modprobe
[   63.696416] preempt_count: 10001, expected: 0
[   63.696416] RCU nest depth: 1, expected: 1

This problem is caused by the following call trace.

  sched_tick() [ acquire rq-&gt;__lock ]
   -&gt; task_tick_mm_cid()
    -&gt; task_work_add()
     -&gt; __kasan_record_aux_stack()
      -&gt; kasan_save_stack()
       -&gt; stack_depot_save_flags()
        -&gt; alloc_pages_mpol_noprof()
         -&gt; __alloc_pages_noprof()
	  -&gt; get_page_from_freelist()
	   -&gt; rmqueue()
	    -&gt; rmqueue_pcplist()
	     -&gt; __rmqueue_pcplist()
	      -&gt; rmqueue_bulk()
	       -&gt; rt_spin_lock()

The rq lock is a raw_spinlock_t. We can't sleep while holding
it. IOW, we can't call alloc_pages() in stack_depot_save_flags().

The task_tick_mm_cid() function with its task_work_add() call was
introduced by commit 223baf9d17f2 ("sched: Fix performance regression
introduced by mm_cid") in v6.4 kernel.

Fortunately, there is a kasan_record_aux_stack_noalloc() variant that
calls stack_depot_save_flags() while not allowing it to allocate
new pages.  To allow task_tick_mm_cid() to use task_work without
page allocation, a new TWAF_NO_ALLOC flag is added to enable calling
kasan_record_aux_stack_noalloc() instead of kasan_record_aux_stack()
if set. The task_tick_mm_cid() function is modified to add this new flag.

The possible downside is the missing stack trace in a KASAN report due
to new page allocation required when task_work_add_noallloc() is called
which should be rare.</Note>
    </Notes>
    <CVE>CVE-2024-50140</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

smb: client: fix possible double free in smb2_set_ea()

Clang static checker(scan-build) warning:
fs/smb/client/smb2ops.c:1304:2: Attempt to free released memory.
 1304 |         kfree(ea);
      |         ^~~~~~~~~

There is a double free in such case:
'ea is initialized to NULL' -&gt; 'first successful memory allocation for
ea' -&gt; 'something failed, goto sea_exit' -&gt; 'first memory release for ea'
-&gt; 'goto replay_again' -&gt; 'second goto sea_exit before allocate memory
for ea' -&gt; 'second memory release for ea resulted in double free'.

Re-initialie 'ea' to NULL near to the replay_again label, it can fix this
double free problem.</Note>
    </Notes>
    <CVE>CVE-2024-50152</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

bpf: devmap: provide rxq after redirect

rxq contains a pointer to the device from where
the redirect happened. Currently, the BPF program
that was executed after a redirect via BPF_MAP_TYPE_DEVMAP*
does not have it set.

This is particularly bad since accessing ingress_ifindex, e.g.

SEC("xdp")
int prog(struct xdp_md *pkt)
{
        return bpf_redirect_map(&amp;dev_redirect_map, 0, 0);
}

SEC("xdp/devmap")
int prog_after_redirect(struct xdp_md *pkt)
{
        bpf_printk("ifindex %i", pkt-&gt;ingress_ifindex);
        return XDP_PASS;
}

depends on access to rxq, so a NULL pointer gets dereferenced:

&lt;1&gt;[  574.475170] BUG: kernel NULL pointer dereference, address: 0000000000000000
&lt;1&gt;[  574.475188] #PF: supervisor read access in kernel mode
&lt;1&gt;[  574.475194] #PF: error_code(0x0000) - not-present page
&lt;6&gt;[  574.475199] PGD 0 P4D 0
&lt;4&gt;[  574.475207] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
&lt;4&gt;[  574.475217] CPU: 4 UID: 0 PID: 217 Comm: kworker/4:1 Not tainted 6.11.0-rc5-reduced-00859-g780801200300 #23
&lt;4&gt;[  574.475226] Hardware name: Intel(R) Client Systems NUC13ANHi7/NUC13ANBi7, BIOS ANRPL357.0026.2023.0314.1458 03/14/2023
&lt;4&gt;[  574.475231] Workqueue: mld mld_ifc_work
&lt;4&gt;[  574.475247] RIP: 0010:bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c
&lt;4&gt;[  574.475257] Code: cc cc cc cc cc cc cc 80 00 00 00 cc cc cc cc cc cc cc cc f3 0f 1e fa 0f 1f 44 00 00 66 90 55 48 89 e5 f3 0f 1e fa 48 8b 57 20 &lt;48&gt; 8b 52 00 8b 92 e0 00 00 00 48 bf f8 a6 d5 c4 5d a0 ff ff be 0b
&lt;4&gt;[  574.475263] RSP: 0018:ffffa62440280c98 EFLAGS: 00010206
&lt;4&gt;[  574.475269] RAX: ffffa62440280cd8 RBX: 0000000000000001 RCX: 0000000000000000
&lt;4&gt;[  574.475274] RDX: 0000000000000000 RSI: ffffa62440549048 RDI: ffffa62440280ce0
&lt;4&gt;[  574.475278] RBP: ffffa62440280c98 R08: 0000000000000002 R09: 0000000000000001
&lt;4&gt;[  574.475281] R10: ffffa05dc8b98000 R11: ffffa05f577fca40 R12: ffffa05dcab24000
&lt;4&gt;[  574.475285] R13: ffffa62440280ce0 R14: ffffa62440549048 R15: ffffa62440549000
&lt;4&gt;[  574.475289] FS:  0000000000000000(0000) GS:ffffa05f4f700000(0000) knlGS:0000000000000000
&lt;4&gt;[  574.475294] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
&lt;4&gt;[  574.475298] CR2: 0000000000000000 CR3: 000000025522e000 CR4: 0000000000f50ef0
&lt;4&gt;[  574.475303] PKRU: 55555554
&lt;4&gt;[  574.475306] Call Trace:
&lt;4&gt;[  574.475313]  &lt;IRQ&gt;
&lt;4&gt;[  574.475318]  ? __die+0x23/0x70
&lt;4&gt;[  574.475329]  ? page_fault_oops+0x180/0x4c0
&lt;4&gt;[  574.475339]  ? skb_pp_cow_data+0x34c/0x490
&lt;4&gt;[  574.475346]  ? kmem_cache_free+0x257/0x280
&lt;4&gt;[  574.475357]  ? exc_page_fault+0x67/0x150
&lt;4&gt;[  574.475368]  ? asm_exc_page_fault+0x26/0x30
&lt;4&gt;[  574.475381]  ? bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c
&lt;4&gt;[  574.475386]  bq_xmit_all+0x158/0x420
&lt;4&gt;[  574.475397]  __dev_flush+0x30/0x90
&lt;4&gt;[  574.475407]  veth_poll+0x216/0x250 [veth]
&lt;4&gt;[  574.475421]  __napi_poll+0x28/0x1c0
&lt;4&gt;[  574.475430]  net_rx_action+0x32d/0x3a0
&lt;4&gt;[  574.475441]  handle_softirqs+0xcb/0x2c0
&lt;4&gt;[  574.475451]  do_softirq+0x40/0x60
&lt;4&gt;[  574.475458]  &lt;/IRQ&gt;
&lt;4&gt;[  574.475461]  &lt;TASK&gt;
&lt;4&gt;[  574.475464]  __local_bh_enable_ip+0x66/0x70
&lt;4&gt;[  574.475471]  __dev_queue_xmit+0x268/0xe40
&lt;4&gt;[  574.475480]  ? selinux_ip_postroute+0x213/0x420
&lt;4&gt;[  574.475491]  ? alloc_skb_with_frags+0x4a/0x1d0
&lt;4&gt;[  574.475502]  ip6_finish_output2+0x2be/0x640
&lt;4&gt;[  574.475512]  ? nf_hook_slow+0x42/0xf0
&lt;4&gt;[  574.475521]  ip6_finish_output+0x194/0x300
&lt;4&gt;[  574.475529]  ? __pfx_ip6_finish_output+0x10/0x10
&lt;4&gt;[  574.475538]  mld_sendpack+0x17c/0x240
&lt;4&gt;[  574.475548]  mld_ifc_work+0x192/0x410
&lt;4&gt;[  574.475557]  process_one_work+0x15d/0x380
&lt;4&gt;[  574.475566]  worker_thread+0x29d/0x3a0
&lt;4&gt;[  574.475573]  ? __pfx_worker_thread+0x10/0x10
&lt;4&gt;[  574.475580]  ? __pfx_worker_thread+0x10/0x10
&lt;4&gt;[  574.475587]  kthread+0xcd/0x100
&lt;4&gt;[  574.475597]  ? __pfx_kthread+0x10/0x10
&lt;4&gt;[  574.475606]  ret_from_fork+0x31/0x50
&lt;4&gt;[  574.475615]  ? __pfx_kthread+0x10/0x10
&lt;4&gt;[  574.475623]  ret_from_fork_asm+0x1a/0x
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-50162</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

bpf: Make sure internal and UAPI bpf_redirect flags don't overlap

The bpf_redirect_info is shared between the SKB and XDP redirect paths,
and the two paths use the same numeric flag values in the ri-&gt;flags
field (specifically, BPF_F_BROADCAST == BPF_F_NEXTHOP). This means that
if skb bpf_redirect_neigh() is used with a non-NULL params argument and,
subsequently, an XDP redirect is performed using the same
bpf_redirect_info struct, the XDP path will get confused and end up
crashing, which syzbot managed to trigger.

With the stack-allocated bpf_redirect_info, the structure is no longer
shared between the SKB and XDP paths, so the crash doesn't happen
anymore. However, different code paths using identically-numbered flag
values in the same struct field still seems like a bit of a mess, so
this patch cleans that up by moving the flag definitions together and
redefining the three flags in BPF_F_REDIRECT_INTERNAL to not overlap
with the flags used for XDP. It also adds a BUILD_BUG_ON() check to make
sure the overlap is not re-introduced by mistake.</Note>
    </Notes>
    <CVE>CVE-2024-50163</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

media: cx24116: prevent overflows on SNR calculus

as reported by Coverity, if reading SNR registers fail, a negative
number will be returned, causing an underflow when reading SNR
registers.

Prevent that.</Note>
    </Notes>
    <CVE>CVE-2024-50290</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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">An issue was discovered in libexpat before 2.6.4. There is a crash within the XML_ResumeParser function because XML_StopParser can stop/suspend an unstarted parser.</Note>
    </Notes>
    <CVE>CVE-2024-50602</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libexpat1-2.7.1-150400.3.28.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:

drm/msm/gem: prevent integer overflow in msm_ioctl_gem_submit()

The "submit-&gt;cmd[i].size" and "submit-&gt;cmd[i].offset" variables are u32
values that come from the user via the submit_lookup_cmds() function.
This addition could lead to an integer wrapping bug so use size_add()
to prevent that.

Patchwork: https://patchwork.freedesktop.org/patch/624696/</Note>
    </Notes>
    <CVE>CVE-2024-52559</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT

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

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

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


 net/sched/sch_api.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)</Note>
    </Notes>
    <CVE>CVE-2024-53057</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

media: dvbdev: prevent the risk of out of memory access

The dvbdev contains a static variable used to store dvb minors.

The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set
or not. When not set, dvb_register_device() won't check for
boundaries, as it will rely that a previous call to
dvb_register_adapter() would already be enforcing it.

On a similar way, dvb_device_open() uses the assumption
that the register functions already did the needed checks.

This can be fragile if some device ends using different
calls. This also generate warnings on static check analysers
like Coverity.

So, add explicit guards to prevent potential risk of OOM issues.</Note>
    </Notes>
    <CVE>CVE-2024-53063</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net: fix data-races around sk-&gt;sk_forward_alloc

Syzkaller reported this warning:
 ------------[ cut here ]------------
 WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0
 Modules linked in:
 CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0
 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 &lt;0f&gt; 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00
 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206
 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007
 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00
 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007
 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00
 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78
 FS:  0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 Call Trace:
  &lt;TASK&gt;
  ? __warn+0x88/0x130
  ? inet_sock_destruct+0x1c5/0x1e0
  ? report_bug+0x18e/0x1a0
  ? handle_bug+0x53/0x90
  ? exc_invalid_op+0x18/0x70
  ? asm_exc_invalid_op+0x1a/0x20
  ? inet_sock_destruct+0x1c5/0x1e0
  __sk_destruct+0x2a/0x200
  rcu_do_batch+0x1aa/0x530
  ? rcu_do_batch+0x13b/0x530
  rcu_core+0x159/0x2f0
  handle_softirqs+0xd3/0x2b0
  ? __pfx_smpboot_thread_fn+0x10/0x10
  run_ksoftirqd+0x25/0x30
  smpboot_thread_fn+0xdd/0x1d0
  kthread+0xd3/0x100
  ? __pfx_kthread+0x10/0x10
  ret_from_fork+0x34/0x50
  ? __pfx_kthread+0x10/0x10
  ret_from_fork_asm+0x1a/0x30
  &lt;/TASK&gt;
 ---[ end trace 0000000000000000 ]---

Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add()
concurrently when sk-&gt;sk_state == TCP_LISTEN with sk-&gt;sk_lock unlocked,
which triggers a data-race around sk-&gt;sk_forward_alloc:
tcp_v6_rcv
    tcp_v6_do_rcv
        skb_clone_and_charge_r
            sk_rmem_schedule
                __sk_mem_schedule
                    sk_forward_alloc_add()
            skb_set_owner_r
                sk_mem_charge
                    sk_forward_alloc_add()
        __kfree_skb
            skb_release_all
                skb_release_head_state
                    sock_rfree
                        sk_mem_uncharge
                            sk_forward_alloc_add()
                            sk_mem_reclaim
                                // set local var reclaimable
                                __sk_mem_reclaim
                                    sk_forward_alloc_add()

In this syzkaller testcase, two threads call
tcp_v6_do_rcv() with skb-&gt;truesize=768, the sk_forward_alloc changes like
this:
 (cpu 1)             | (cpu 2)             | sk_forward_alloc
 ...                 | ...                 | 0
 __sk_mem_schedule() |                     | +4096 = 4096
                     | __sk_mem_schedule() | +4096 = 8192
 sk_mem_charge()     |                     | -768  = 7424
                     | sk_mem_charge()     | -768  = 6656
 ...                 |    ...              |
 sk_mem_uncharge()   |                     | +768  = 7424
 reclaimable=7424    |                     |
                     | sk_mem_uncharge()   | +768  = 8192
                     | reclaimable=8192    |
 __sk_mem_reclaim()  |                     | -4096 = 4096
                     | __sk_mem_reclaim()  | -8192 = -4096 != 0

The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when
sk-&gt;sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock().
Fix the same issue in dccp_v6_do_rcv().</Note>
    </Notes>
    <CVE>CVE-2024-53124</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

sctp: fix possible UAF in sctp_v6_available()

A lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints
that sctp_v6_available() is calling dev_get_by_index_rcu()
and ipv6_chk_addr() without holding rcu.

[1]
 =============================
 WARNING: suspicious RCU usage
 6.12.0-rc5-virtme #1216 Tainted: G        W
 -----------------------------
 net/core/dev.c:876 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 sctp_hello/31495:
 #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp

stack backtrace:
 CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G        W          6.12.0-rc5-virtme #1216
 Tainted: [W]=WARN
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
 Call Trace:
  &lt;TASK&gt;
 dump_stack_lvl (lib/dump_stack.c:123)
 lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822)
 dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7))
 sctp_v6_available (net/sctp/ipv6.c:701) sctp
 sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp
 sctp_bind (net/sctp/socket.c:320) sctp
 inet6_bind_sk (net/ipv6/af_inet6.c:465)
 ? security_socket_bind (security/security.c:4581 (discriminator 1))
 __sys_bind (net/socket.c:1848 net/socket.c:1869)
 ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340)
 ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13))
 __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1))
 do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))
 entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
 RIP: 0033:0x7f59b934a1e7
 Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48
All code
========
   0:	44 00 00             	add    %r8b,(%rax)
   3:	48 8b 15 39 8c 0c 00 	mov    0xc8c39(%rip),%rdx        # 0xc8c43
   a:	f7 d8                	neg    %eax
   c:	64 89 02             	mov    %eax,%fs:(%rdx)
   f:	b8 ff ff ff ff       	mov    $0xffffffff,%eax
  14:	eb bd                	jmp    0xffffffffffffffd3
  16:	66 2e 0f 1f 84 00 00 	cs nopw 0x0(%rax,%rax,1)
  1d:	00 00 00
  20:	0f 1f 00             	nopl   (%rax)
  23:	b8 31 00 00 00       	mov    $0x31,%eax
  28:	0f 05                	syscall
  2a:*	48 3d 01 f0 ff ff    	cmp    $0xfffffffffffff001,%rax		&lt;-- trapping instruction
  30:	73 01                	jae    0x33
  32:	c3                   	ret
  33:	48 8b 0d 09 8c 0c 00 	mov    0xc8c09(%rip),%rcx        # 0xc8c43
  3a:	f7 d8                	neg    %eax
  3c:	64 89 01             	mov    %eax,%fs:(%rcx)
  3f:	48                   	rex.W

Code starting with the faulting instruction
===========================================
   0:	48 3d 01 f0 ff ff    	cmp    $0xfffffffffffff001,%rax
   6:	73 01                	jae    0x9
   8:	c3                   	ret
   9:	48 8b 0d 09 8c 0c 00 	mov    0xc8c09(%rip),%rcx        # 0xc8c19
  10:	f7 d8                	neg    %eax
  12:	64 89 01             	mov    %eax,%fs:(%rcx)
  15:	48                   	rex.W
 RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031
 RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7
 RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005
 RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000
 R10: 00007f59b9253298 R11: 000000000000
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-53139</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

netlink: terminate outstanding dump on socket close

Netlink supports iterative dumping of data. It provides the families
the following ops:
 - start - (optional) kicks off the dumping process
 - dump  - actual dump helper, keeps getting called until it returns 0
 - done  - (optional) pairs with .start, can be used for cleanup
The whole process is asynchronous and the repeated calls to .dump
don't actually happen in a tight loop, but rather are triggered
in response to recvmsg() on the socket.

This gives the user full control over the dump, but also means that
the user can close the socket without getting to the end of the dump.
To make sure .start is always paired with .done we check if there
is an ongoing dump before freeing the socket, and if so call .done.

The complication is that sockets can get freed from BH and .done
is allowed to sleep. So we use a workqueue to defer the call, when
needed.

Unfortunately this does not work correctly. What we defer is not
the cleanup but rather releasing a reference on the socket.
We have no guarantee that we own the last reference, if someone
else holds the socket they may release it in BH and we're back
to square one.

The whole dance, however, appears to be unnecessary. Only the user
can interact with dumps, so we can clean up when socket is closed.
And close always happens in process context. Some async code may
still access the socket after close, queue notification skbs to it etc.
but no dumps can start, end or otherwise make progress.

Delete the workqueue and flush the dump state directly from the release
handler. Note that further cleanup is possible in -next, for instance
we now always call .done before releasing the main module reference,
so dump doesn't have to take a reference of its own.</Note>
    </Notes>
    <CVE>CVE-2024-53140</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

crypto: qat/qat_420xx - fix off by one in uof_get_name()

This is called from uof_get_name_420xx() where "num_objs" is the
ARRAY_SIZE() of fw_objs[].  The &gt; needs to be &gt;= to prevent an out of
bounds access.</Note>
    </Notes>
    <CVE>CVE-2024-53163</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

netfilter: IDLETIMER: Fix for possible ABBA deadlock

Deletion of the last rule referencing a given idletimer may happen at
the same time as a read of its file in sysfs:

| ======================================================
| WARNING: possible circular locking dependency detected
| 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted
| ------------------------------------------------------
| iptables/3303 is trying to acquire lock:
| ffff8881057e04b8 (kn-&gt;active#48){++++}-{0:0}, at: __kernfs_remove+0x20
|
| but task is already holding lock:
| ffffffffa0249068 (list_mutex){+.+.}-{3:3}, at: idletimer_tg_destroy_v]
|
| which lock already depends on the new lock.

A simple reproducer is:

| #!/bin/bash
|
| while true; do
|         iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label "testme"
|         iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label "testme"
| done &amp;
| while true; do
|         cat /sys/class/xt_idletimer/timers/testme &gt;/dev/null
| done

Avoid this by freeing list_mutex right after deleting the element from
the list, then continuing with the teardown.</Note>
    </Notes>
    <CVE>CVE-2024-54683</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

netfilter: nft_inner: incorrect percpu area handling under softirq

Softirq can interrupt ongoing packet from process context that is
walking over the percpu area that contains inner header offsets.

Disable bh and perform three checks before restoring the percpu inner
header offsets to validate that the percpu area is valid for this
skbuff:

1) If the NFT_PKTINFO_INNER_FULL flag is set on, then this skbuff
   has already been parsed before for inner header fetching to
   register.

2) Validate that the percpu area refers to this skbuff using the
   skbuff pointer as a cookie. If there is a cookie mismatch, then
   this skbuff needs to be parsed again.

3) Finally, validate if the percpu area refers to this tunnel type.

Only after these three checks the percpu area is restored to a on-stack
copy and bh is enabled again.

After inner header fetching, the on-stack copy is stored back to the
percpu area.</Note>
    </Notes>
    <CVE>CVE-2024-56638</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net/smc: fix LGR and link use-after-free issue

We encountered a LGR/link use-after-free issue, which manifested as
the LGR/link refcnt reaching 0 early and entering the clear process,
making resource access unsafe.

 refcount_t: addition on 0; use-after-free.
 WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcount_warn_saturate+0x9c/0x140
 Workqueue: events smc_lgr_terminate_work [smc]
 Call trace:
  refcount_warn_saturate+0x9c/0x140
  __smc_lgr_terminate.part.45+0x2a8/0x370 [smc]
  smc_lgr_terminate_work+0x28/0x30 [smc]
  process_one_work+0x1b8/0x420
  worker_thread+0x158/0x510
  kthread+0x114/0x118

or

 refcount_t: underflow; use-after-free.
 WARNING: CPU: 6 PID: 93140 at lib/refcount.c:28 refcount_warn_saturate+0xf0/0x140
 Workqueue: smc_hs_wq smc_listen_work [smc]
 Call trace:
  refcount_warn_saturate+0xf0/0x140
  smcr_link_put+0x1cc/0x1d8 [smc]
  smc_conn_free+0x110/0x1b0 [smc]
  smc_conn_abort+0x50/0x60 [smc]
  smc_listen_find_device+0x75c/0x790 [smc]
  smc_listen_work+0x368/0x8a0 [smc]
  process_one_work+0x1b8/0x420
  worker_thread+0x158/0x510
  kthread+0x114/0x118

It is caused by repeated release of LGR/link refcnt. One suspect is that
smc_conn_free() is called repeatedly because some smc_conn_free() from
server listening path are not protected by sock lock.

e.g.

Calls under socklock        | smc_listen_work
-------------------------------------------------------
lock_sock(sk)               | smc_conn_abort
smc_conn_free               | \- smc_conn_free
\- smcr_link_put            |    \- smcr_link_put (duplicated)
release_sock(sk)

So here add sock lock protection in smc_listen_work() path, making it
exclusive with other connection operations.</Note>
    </Notes>
    <CVE>CVE-2024-56640</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

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-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

bpf: Mark raw_tp arguments with PTR_MAYBE_NULL

Arguments to a raw tracepoint are tagged as trusted, which carries the
semantics that the pointer will be non-NULL.  However, in certain cases,
a raw tracepoint argument may end up being NULL. More context about this
issue is available in [0].

Thus, there is a discrepancy between the reality, that raw_tp arguments
can actually be NULL, and the verifier's knowledge, that they are never
NULL, causing explicit NULL checks to be deleted, and accesses to such
pointers potentially crashing the kernel.

To fix this, mark raw_tp arguments as PTR_MAYBE_NULL, and then special
case the dereference and pointer arithmetic to permit it, and allow
passing them into helpers/kfuncs; these exceptions are made for raw_tp
programs only. Ensure that we don't do this when ref_obj_id &gt; 0, as in
that case this is an acquired object and doesn't need such adjustment.

The reason we do mask_raw_tp_trusted_reg logic is because other will
recheck in places whether the register is a trusted_reg, and then
consider our register as untrusted when detecting the presence of the
PTR_MAYBE_NULL flag.

To allow safe dereference, we enable PROBE_MEM marking when we see loads
into trusted pointers with PTR_MAYBE_NULL.

While trusted raw_tp arguments can also be passed into helpers or kfuncs
where such broken assumption may cause issues, a future patch set will
tackle their case separately, as PTR_TO_BTF_ID (without PTR_TRUSTED) can
already be passed into helpers and causes similar problems. Thus, they
are left alone for now.

It is possible that these checks also permit passing non-raw_tp args
that are trusted PTR_TO_BTF_ID with null marking. In such a case,
allowing dereference when pointer is NULL expands allowed behavior, so
won't regress existing programs, and the case of passing these into
helpers is the same as above and will be dealt with later.

Also update the failure case in tp_btf_nullable selftest to capture the
new behavior, as the verifier will no longer cause an error when
directly dereference a raw tracepoint argument marked as __nullable.

  [0]: https://lore.kernel.org/bpf/ZrCZS6nisraEqehw@jlelli-thinkpadt14gen4.remote.csb</Note>
    </Notes>
    <CVE>CVE-2024-56702</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ipv6: Fix soft lockups in fib6_select_path under high next hop churn

Soft lockups have been observed on a cluster of Linux-based edge routers
located in a highly dynamic environment. Using the `bird` service, these
routers continuously update BGP-advertised routes due to frequently
changing nexthop destinations, while also managing significant IPv6
traffic. The lockups occur during the traversal of the multipath
circular linked-list in the `fib6_select_path` function, particularly
while iterating through the siblings in the list. The issue typically
arises when the nodes of the linked list are unexpectedly deleted
concurrently on a different core-indicated by their 'next' and
'previous' elements pointing back to the node itself and their reference
count dropping to zero. This results in an infinite loop, leading to a
soft lockup that triggers a system panic via the watchdog timer.

Apply RCU primitives in the problematic code sections to resolve the
issue. Where necessary, update the references to fib6_siblings to
annotate or use the RCU APIs.

Include a test script that reproduces the issue. The script
periodically updates the routing table while generating a heavy load
of outgoing IPv6 traffic through multiple iperf3 clients. It
consistently induces infinite soft lockups within a couple of minutes.

Kernel log:

 0 [ffffbd13003e8d30] machine_kexec at ffffffff8ceaf3eb
 1 [ffffbd13003e8d90] __crash_kexec at ffffffff8d0120e3
 2 [ffffbd13003e8e58] panic at ffffffff8cef65d4
 3 [ffffbd13003e8ed8] watchdog_timer_fn at ffffffff8d05cb03
 4 [ffffbd13003e8f08] __hrtimer_run_queues at ffffffff8cfec62f
 5 [ffffbd13003e8f70] hrtimer_interrupt at ffffffff8cfed756
 6 [ffffbd13003e8fd0] __sysvec_apic_timer_interrupt at ffffffff8cea01af
 7 [ffffbd13003e8ff0] sysvec_apic_timer_interrupt at ffffffff8df1b83d
-- &lt;IRQ stack&gt; --
 8 [ffffbd13003d3708] asm_sysvec_apic_timer_interrupt at ffffffff8e000ecb
    [exception RIP: fib6_select_path+299]
    RIP: ffffffff8ddafe7b  RSP: ffffbd13003d37b8  RFLAGS: 00000287
    RAX: ffff975850b43600  RBX: ffff975850b40200  RCX: 0000000000000000
    RDX: 000000003fffffff  RSI: 0000000051d383e4  RDI: ffff975850b43618
    RBP: ffffbd13003d3800   R8: 0000000000000000   R9: ffff975850b40200
    R10: 0000000000000000  R11: 0000000000000000  R12: ffffbd13003d3830
    R13: ffff975850b436a8  R14: ffff975850b43600  R15: 0000000000000007
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 9 [ffffbd13003d3808] ip6_pol_route at ffffffff8ddb030c
10 [ffffbd13003d3888] ip6_pol_route_input at ffffffff8ddb068c
11 [ffffbd13003d3898] fib6_rule_lookup at ffffffff8ddf02b5
12 [ffffbd13003d3928] ip6_route_input at ffffffff8ddb0f47
13 [ffffbd13003d3a18] ip6_rcv_finish_core.constprop.0 at ffffffff8dd950d0
14 [ffffbd13003d3a30] ip6_list_rcv_finish.constprop.0 at ffffffff8dd96274
15 [ffffbd13003d3a98] ip6_sublist_rcv at ffffffff8dd96474
16 [ffffbd13003d3af8] ipv6_list_rcv at ffffffff8dd96615
17 [ffffbd13003d3b60] __netif_receive_skb_list_core at ffffffff8dc16fec
18 [ffffbd13003d3be0] netif_receive_skb_list_internal at ffffffff8dc176b3
19 [ffffbd13003d3c50] napi_gro_receive at ffffffff8dc565b9
20 [ffffbd13003d3c80] ice_receive_skb at ffffffffc087e4f5 [ice]
21 [ffffbd13003d3c90] ice_clean_rx_irq at ffffffffc0881b80 [ice]
22 [ffffbd13003d3d20] ice_napi_poll at ffffffffc088232f [ice]
23 [ffffbd13003d3d80] __napi_poll at ffffffff8dc18000
24 [ffffbd13003d3db8] net_rx_action at ffffffff8dc18581
25 [ffffbd13003d3e40] __do_softirq at ffffffff8df352e9
26 [ffffbd13003d3eb0] run_ksoftirqd at ffffffff8ceffe47
27 [ffffbd13003d3ec0] smpboot_thread_fn at ffffffff8cf36a30
28 [ffffbd13003d3ee8] kthread at ffffffff8cf2b39f
29 [ffffbd13003d3f28] ret_from_fork at ffffffff8ce5fa64
30 [ffffbd13003d3f50] ret_from_fork_asm at ffffffff8ce03cbb</Note>
    </Notes>
    <CVE>CVE-2024-56703</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net/smc: protect link down work from execute after lgr freed

link down work may be scheduled before lgr freed but execute
after lgr freed, which may result in crash. So it is need to
hold a reference before shedule link down work, and put the
reference after work executed or canceled.

The relevant crash call stack as follows:
 list_del corruption. prev-&gt;next should be ffffb638c9c0fe20,
    but was 0000000000000000
 ------------[ cut here ]------------
 kernel BUG at lib/list_debug.c:51!
 invalid opcode: 0000 [#1] SMP NOPTI
 CPU: 6 PID: 978112 Comm: kworker/6:119 Kdump: loaded Tainted: G #1
 Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 2221b89 04/01/2014
 Workqueue: events smc_link_down_work [smc]
 RIP: 0010:__list_del_entry_valid.cold+0x31/0x47
 RSP: 0018:ffffb638c9c0fdd8 EFLAGS: 00010086
 RAX: 0000000000000054 RBX: ffff942fb75e5128 RCX: 0000000000000000
 RDX: ffff943520930aa0 RSI: ffff94352091fc80 RDI: ffff94352091fc80
 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb638c9c0fc38
 R10: ffffb638c9c0fc30 R11: ffffffffa015eb28 R12: 0000000000000002
 R13: ffffb638c9c0fe20 R14: 0000000000000001 R15: ffff942f9cd051c0
 FS:  0000000000000000(0000) GS:ffff943520900000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 00007f4f25214000 CR3: 000000025fbae004 CR4: 00000000007706e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 PKRU: 55555554
 Call Trace:
  rwsem_down_write_slowpath+0x17e/0x470
  smc_link_down_work+0x3c/0x60 [smc]
  process_one_work+0x1ac/0x350
  worker_thread+0x49/0x2f0
  ? rescuer_thread+0x360/0x360
  kthread+0x118/0x140
  ? __kthread_bind_mask+0x60/0x60
  ret_from_fork+0x1f/0x30</Note>
    </Notes>
    <CVE>CVE-2024-56718</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net: stmmac: fix TSO DMA API usage causing oops

Commit 66600fac7a98 ("net: stmmac: TSO: Fix unbalanced DMA map/unmap
for non-paged SKB data") moved the assignment of tx_skbuff_dma[]'s
members to be later in stmmac_tso_xmit().

The buf (dma cookie) and len stored in this structure are passed to
dma_unmap_single() by stmmac_tx_clean(). The DMA API requires that
the dma cookie passed to dma_unmap_single() is the same as the value
returned from dma_map_single(). However, by moving the assignment
later, this is not the case when priv-&gt;dma_cap.addr64 &gt; 32 as "des"
is offset by proto_hdr_len.

This causes problems such as:

  dwc-eth-dwmac 2490000.ethernet eth0: Tx DMA map failed

and with DMA_API_DEBUG enabled:

  DMA-API: dwc-eth-dwmac 2490000.ethernet: device driver tries to +free DMA memory it has not allocated [device address=0x000000ffffcf65c0] [size=66 bytes]

Fix this by maintaining "des" as the original DMA cookie, and use
tso_des to pass the offset DMA cookie to stmmac_tso_allocator().

Full details of the crashes can be found at:
https://lore.kernel.org/all/d8112193-0386-4e14-b516-37c2d838171a@nvidia.com/
https://lore.kernel.org/all/klkzp5yn5kq5efgtrow6wbvnc46bcqfxs65nz3qy77ujr5turc@bwwhelz2l4dw/</Note>
    </Notes>
    <CVE>CVE-2024-56719</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ipv6: release nexthop on device removal

The CI is hitting some aperiodic hangup at device removal time in the
pmtu.sh self-test:

unregister_netdevice: waiting for veth_A-R1 to become free. Usage count = 6
ref_tracker: veth_A-R1@ffff888013df15d8 has 1/5 users at
	dst_init+0x84/0x4a0
	dst_alloc+0x97/0x150
	ip6_dst_alloc+0x23/0x90
	ip6_rt_pcpu_alloc+0x1e6/0x520
	ip6_pol_route+0x56f/0x840
	fib6_rule_lookup+0x334/0x630
	ip6_route_output_flags+0x259/0x480
	ip6_dst_lookup_tail.constprop.0+0x5c2/0x940
	ip6_dst_lookup_flow+0x88/0x190
	udp_tunnel6_dst_lookup+0x2a7/0x4c0
	vxlan_xmit_one+0xbde/0x4a50 [vxlan]
	vxlan_xmit+0x9ad/0xf20 [vxlan]
	dev_hard_start_xmit+0x10e/0x360
	__dev_queue_xmit+0xf95/0x18c0
	arp_solicit+0x4a2/0xe00
	neigh_probe+0xaa/0xf0

While the first suspect is the dst_cache, explicitly tracking the dst
owing the last device reference via probes proved such dst is held by
the nexthop in the originating fib6_info.

Similar to commit f5b51fe804ec ("ipv6: route: purge exception on
removal"), we need to explicitly release the originating fib info when
disconnecting a to-be-removed device from a live ipv6 dst: move the
fib6_info cleanup into ip6_dst_ifdown().

Tested running:

./pmtu.sh cleanup_ipv6_exception

in a tight loop for more than 400 iterations with no spat, running an
unpatched kernel  I observed a splat every ~10 iterations.</Note>
    </Notes>
    <CVE>CVE-2024-56751</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net/sched: netem: account for backlog updates from child qdisc

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

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

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

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

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

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

This patch adds a counter for the entries in the tfifo. Netem's 'qlen' is
only decreased when a packet is returned by its dequeue function, and not
during enqueuing into the child qdisc. External updates to 'qlen' are thus
accounted for and only the behavior of the backlog statistics changes. As
in other qdiscs, 'qlen' then keeps track of  how many packets are held in
netem and all of its children. As before, sch-&gt;limit remains as the
maximum number of packets in the tfifo. The same applies to netem's
backlog statistics.</Note>
    </Notes>
    <CVE>CVE-2024-56770</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

scsi: megaraid_sas: Fix for a potential deadlock

This fixes a 'possible circular locking dependency detected' warning
      CPU0                    CPU1
      ----                    ----
 lock(&amp;instance-&gt;reset_mutex);
                              lock(&amp;shost-&gt;scan_mutex);
                              lock(&amp;instance-&gt;reset_mutex);
 lock(&amp;shost-&gt;scan_mutex);

Fix this by temporarily releasing the reset_mutex.</Note>
    </Notes>
    <CVE>CVE-2024-57807</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread

syzbot report a null-ptr-deref in vidtv_mux_stop_thread. [1]

If dvb-&gt;mux is not initialized successfully by vidtv_mux_init() in the
vidtv_start_streaming(), it will trigger null pointer dereference about mux
in vidtv_mux_stop_thread().

Adjust the timing of streaming initialization and check it before
stopping it.

[1]
KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f]
CPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
RIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471
Code: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 &lt;0f&gt; b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8
RSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125
RDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128
RBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188
R13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710
FS:  00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline]
 vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252
 dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000
 dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486
 dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559
 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline]
 dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246
 __fput+0x3f8/0xb60 fs/file_table.c:450
 task_work_run+0x14e/0x250 kernel/task_work.c:239
 get_signal+0x1d3/0x2610 kernel/signal.c:2790
 arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337
 exit_to_user_mode_loop kernel/entry/common.c:111 [inline]
 exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]
 __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]
 syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218
 do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89
 entry_SYSCALL_64_after_hwframe+0x77/0x7f</Note>
    </Notes>
    <CVE>CVE-2024-57834</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ila: serialize calls to nf_register_net_hooks()

syzbot found a race in ila_add_mapping() [1]

commit 031ae72825ce ("ila: call nf_unregister_net_hooks() sooner")
attempted to fix a similar issue.

Looking at the syzbot repro, we have concurrent ILA_CMD_ADD commands.

Add a mutex to make sure at most one thread is calling nf_register_net_hooks().

[1]
 BUG: KASAN: slab-use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline]
 BUG: KASAN: slab-use-after-free in __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604
Read of size 4 at addr ffff888028f40008 by task dhcpcd/5501

CPU: 1 UID: 0 PID: 5501 Comm: dhcpcd Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Call Trace:
 &lt;IRQ&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:378 [inline]
  print_report+0xc3/0x620 mm/kasan/report.c:489
  kasan_report+0xd9/0x110 mm/kasan/report.c:602
  rht_key_hashfn include/linux/rhashtable.h:159 [inline]
  __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604
  rhashtable_lookup include/linux/rhashtable.h:646 [inline]
  rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline]
  ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:127 [inline]
  ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline]
  ila_nf_input+0x1ee/0x620 net/ipv6/ila/ila_xlat.c:185
  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
  nf_hook_slow+0xbb/0x200 net/netfilter/core.c:626
  nf_hook.constprop.0+0x42e/0x750 include/linux/netfilter.h:269
  NF_HOOK include/linux/netfilter.h:312 [inline]
  ipv6_rcv+0xa4/0x680 net/ipv6/ip6_input.c:309
  __netif_receive_skb_one_core+0x12e/0x1e0 net/core/dev.c:5672
  __netif_receive_skb+0x1d/0x160 net/core/dev.c:5785
  process_backlog+0x443/0x15f0 net/core/dev.c:6117
  __napi_poll.constprop.0+0xb7/0x550 net/core/dev.c:6883
  napi_poll net/core/dev.c:6952 [inline]
  net_rx_action+0xa94/0x1010 net/core/dev.c:7074
  handle_softirqs+0x213/0x8f0 kernel/softirq.c:561
  __do_softirq kernel/softirq.c:595 [inline]
  invoke_softirq kernel/softirq.c:435 [inline]
  __irq_exit_rcu+0x109/0x170 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+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049</Note>
    </Notes>
    <CVE>CVE-2024-57900</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

fs: relax assertions on failure to encode file handles

Encoding file handles is usually performed by a filesystem &gt;encode_fh()
method that may fail for various reasons.

The legacy users of exportfs_encode_fh(), namely, nfsd and
name_to_handle_at(2) syscall are ready to cope with the possibility
of failure to encode a file handle.

There are a few other users of exportfs_encode_{fh,fid}() that
currently have a WARN_ON() assertion when -&gt;encode_fh() fails.
Relax those assertions because they are wrong.

The second linked bug report states commit 16aac5ad1fa9 ("ovl: support
encoding non-decodable file handles") in v6.6 as the regressing commit,
but this is not accurate.

The aforementioned commit only increases the chances of the assertion
and allows triggering the assertion with the reproducer using overlayfs,
inotify and drop_caches.

Triggering this assertion was always possible with other filesystems and
other reasons of -&gt;encode_fh() failures and more particularly, it was
also possible with the exact same reproducer using overlayfs that is
mounted with options index=on,nfs_export=on also on kernels &lt; v6.6.
Therefore, I am not listing the aforementioned commit as a Fixes commit.

Backport hint: this patch will have a trivial conflict applying to
v6.6.y, and other trivial conflicts applying to stable kernels &lt; v6.6.</Note>
    </Notes>
    <CVE>CVE-2024-57924</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

netfilter: nf_set_pipapo: fix initial map fill

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

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

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

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

Thanks to Stefano Brivio for pointing out that we need to zero out
the remainder explicitly, only correcting memset() argument isn't enough.</Note>
    </Notes>
    <CVE>CVE-2024-57947</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

rdma/cxgb4: Prevent potential integer overflow on 32bit

The "gl-&gt;tot_len" variable is controlled by the user.  It comes from
process_responses().  On 32bit systems, the "gl-&gt;tot_len + sizeof(struct
cpl_pass_accept_req) + sizeof(struct rss_header)" addition could have an
integer wrapping bug.  Use size_add() to prevent this.</Note>
    </Notes>
    <CVE>CVE-2024-57973</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

udp: Deal with race between UDP socket address change and rehash

If a UDP socket changes its local address while it's receiving
datagrams, as a result of connect(), there is a period during which
a lookup operation might fail to find it, after the address is changed
but before the secondary hash (port and address) and the four-tuple
hash (local and remote ports and addresses) are updated.

Secondary hash chains were introduced by commit 30fff9231fad ("udp:
bind() optimisation") and, as a result, a rehash operation became
needed to make a bound socket reachable again after a connect().

This operation was introduced by commit 719f835853a9 ("udp: add
rehash on connect()") which isn't however a complete fix: the
socket will be found once the rehashing completes, but not while
it's pending.

This is noticeable with a socat(1) server in UDP4-LISTEN mode, and a
client sending datagrams to it. After the server receives the first
datagram (cf. _xioopen_ipdgram_listen()), it issues a connect() to
the address of the sender, in order to set up a directed flow.

Now, if the client, running on a different CPU thread, happens to
send a (subsequent) datagram while the server's socket changes its
address, but is not rehashed yet, this will result in a failed
lookup and a port unreachable error delivered to the client, as
apparent from the following reproducer:

  LEN=$(($(cat /proc/sys/net/core/wmem_default) / 4))
  dd if=/dev/urandom bs=1 count=${LEN} of=tmp.in

  while :; do
  	taskset -c 1 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc &amp;
  	sleep 0.1 || sleep 1
  	taskset -c 2 socat OPEN:tmp.in UDP4:localhost:1337,shut-null
  	wait
  done

where the client will eventually get ECONNREFUSED on a write()
(typically the second or third one of a given iteration):

  2024/11/13 21:28:23 socat[46901] E write(6, 0x556db2e3c000, 8192): Connection refused

This issue was first observed as a seldom failure in Podman's tests
checking UDP functionality while using pasta(1) to connect the
container's network namespace, which leads us to a reproducer with
the lookup error resulting in an ICMP packet on a tap device:

  LOCAL_ADDR="$(ip -j -4 addr show|jq -rM '.[] | .addr_info[0] | select(.scope == "global").local')"

  while :; do
  	./pasta --config-net -p pasta.pcap -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc &amp;
  	sleep 0.2 || sleep 1
  	socat OPEN:tmp.in UDP4:${LOCAL_ADDR}:1337,shut-null
  	wait
  	cmp tmp.in tmp.out
  done

Once this fails:

  tmp.in tmp.out differ: char 8193, line 29

we can finally have a look at what's going on:

  $ tshark -r pasta.pcap
      1   0.000000           :: ? ff02::16     ICMPv6 110 Multicast Listener Report Message v2
      2   0.168690 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192
      3   0.168767 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192
      4   0.168806 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192
      5   0.168827 c6:47:05:8d:dc:04 ? Broadcast    ARP 42 Who has 88.198.0.161? Tell 88.198.0.164
      6   0.168851 9a:55:9a:55:9a:55 ? c6:47:05:8d:dc:04 ARP 42 88.198.0.161 is at 9a:55:9a:55:9a:55
      7   0.168875 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192
      8   0.168896 88.198.0.164 ? 88.198.0.161 ICMP 590 Destination unreachable (Port unreachable)
      9   0.168926 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192
     10   0.168959 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192
     11   0.168989 88.198.0.161 ? 88.198.0.164 UDP 4138 60260 ? 1337 Len=4096
     12   0.169010 88.198.0.161 ? 88.198.0.164 UDP 42 60260 ? 1337 Len=0

On the third datagram received, the network namespace of the container
initiates an ARP lookup to deliver the ICMP message.

In another variant of this reproducer, starting the client with:

  strace -f pasta --config-net -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,tru
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-57974</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

media: imx-jpeg: Fix potential error pointer dereference in detach_pm()

The proble is on the first line:

	if (jpeg-&gt;pd_dev[i] &amp;&amp; !pm_runtime_suspended(jpeg-&gt;pd_dev[i]))

If jpeg-&gt;pd_dev[i] is an error pointer, then passing it to
pm_runtime_suspended() will lead to an Oops.  The other conditions
check for both error pointers and NULL, but it would be more clear to
use the IS_ERR_OR_NULL() check for that.</Note>
    </Notes>
    <CVE>CVE-2024-57978</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

pps: Fix a use-after-free

On a board running ntpd and gpsd, I'm seeing a consistent use-after-free
in sys_exit() from gpsd when rebooting:

    pps pps1: removed
    ------------[ cut here ]------------
    kobject: '(null)' (00000000db4bec24): is not initialized, yet kobject_put() is being called.
    WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150
    CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1
    Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)
    pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : kobject_put+0x120/0x150
    lr : kobject_put+0x120/0x150
    sp : ffffffc0803d3ae0
    x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001
    x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440
    x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600
    x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000
    x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20
    x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000
    x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
    x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
    x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
    x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
    Call trace:
     kobject_put+0x120/0x150
     cdev_put+0x20/0x3c
     __fput+0x2c4/0x2d8
     ____fput+0x1c/0x38
     task_work_run+0x70/0xfc
     do_exit+0x2a0/0x924
     do_group_exit+0x34/0x90
     get_signal+0x7fc/0x8c0
     do_signal+0x128/0x13b4
     do_notify_resume+0xdc/0x160
     el0_svc+0xd4/0xf8
     el0t_64_sync_handler+0x140/0x14c
     el0t_64_sync+0x190/0x194
    ---[ end trace 0000000000000000 ]---

...followed by more symptoms of corruption, with similar stacks:

    refcount_t: underflow; use-after-free.
    kernel BUG at lib/list_debug.c:62!
    Kernel panic - not syncing: Oops - BUG: Fatal exception

This happens because pps_device_destruct() frees the pps_device with the
embedded cdev immediately after calling cdev_del(), but, as the comment
above cdev_del() notes, fops for previously opened cdevs are still
callable even after cdev_del() returns. I think this bug has always
been there: I can't explain why it suddenly started happening every time
I reboot this particular board.

In commit d953e0e837e6 ("pps: Fix a use-after free bug when
unregistering a source."), George Spelvin suggested removing the
embedded cdev. That seems like the simplest way to fix this, so I've
implemented his suggestion, using __register_chrdev() with pps_idr
becoming the source of truth for which minor corresponds to which
device.

But now that pps_idr defines userspace visibility instead of cdev_add(),
we need to be sure the pps-&gt;dev refcount can't reach zero while
userspace can still find it again. So, the idr_remove() call moves to
pps_unregister_cdev(), and pps_idr now holds a reference to pps-&gt;dev.

    pps_core: source serial1 got cdev (251:1)
    &lt;...&gt;
    pps pps1: removed
    pps_core: unregistering pps1
    pps_core: deallocating pps1</Note>
    </Notes>
    <CVE>CVE-2024-57979</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

media: uvcvideo: Fix double free in error path

If the uvc_status_init() function fails to allocate the int_urb, it will
free the dev-&gt;status pointer but doesn't reset the pointer to NULL. This
results in the kfree() call in uvc_status_cleanup() trying to
double-free the memory. Fix it by resetting the dev-&gt;status pointer to
NULL after freeing it.

Reviewed by: Ricardo Ribalda &lt;ribalda@chromium.org&gt;</Note>
    </Notes>
    <CVE>CVE-2024-57980</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

usb: xhci: Fix NULL pointer dereference on certain command aborts

If a command is queued to the final usable TRB of a ring segment, the
enqueue pointer is advanced to the subsequent link TRB and no further.
If the command is later aborted, when the abort completion is handled
the dequeue pointer is advanced to the first TRB of the next segment.

If no further commands are queued, xhci_handle_stopped_cmd_ring() sees
the ring pointers unequal and assumes that there is a pending command,
so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL.

Don't attempt timer setup if cur_cmd is NULL. The subsequent doorbell
ring likely is unnecessary too, but it's harmless. Leave it alone.

This is probably Bug 219532, but no confirmation has been received.

The issue has been independently reproduced and confirmed fixed using
a USB MCU programmed to NAK the Status stage of SET_ADDRESS forever.
Everything continued working normally after several prevented crashes.</Note>
    </Notes>
    <CVE>CVE-2024-57981</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

HID: core: Fix assumption that Resolution Multipliers must be in Logical Collections

A report in 2019 by the syzbot fuzzer was found to be connected to two
errors in the HID core associated with Resolution Multipliers.  One of
the errors was fixed by commit ea427a222d8b ("HID: core: Fix deadloop
in hid_apply_multiplier."), but the other has not been fixed.

This error arises because hid_apply_multipler() assumes that every
Resolution Multiplier control is contained in a Logical Collection,
i.e., there's no way the routine can ever set multiplier_collection to
NULL.  This is in spite of the fact that the function starts with a
big comment saying:

	 * "The Resolution Multiplier control must be contained in the same
	 * Logical Collection as the control(s) to which it is to be applied.
	   ...
	 *  If no Logical Collection is
	 * defined, the Resolution Multiplier is associated with all
	 * controls in the report."
	 * HID Usage Table, v1.12, Section 4.3.1, p30
	 *
	 * Thus, search from the current collection upwards until we find a
	 * logical collection...

The comment and the code overlook the possibility that none of the
collections found may be a Logical Collection.

The fix is to set the multiplier_collection pointer to NULL if the
collection found isn't a Logical Collection.</Note>
    </Notes>
    <CVE>CVE-2024-57986</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

wifi: mt76: mt7925: fix off by one in mt7925_load_clc()

This comparison should be &gt;= instead of &gt; to prevent an out of bounds
read and write.</Note>
    </Notes>
    <CVE>CVE-2024-57990</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

HID: hid-thrustmaster: Fix warning in thrustmaster_probe by adding endpoint check

syzbot has found a type mismatch between a USB pipe and the transfer
endpoint, which is triggered by the hid-thrustmaster driver[1].
There is a number of similar, already fixed issues [2].
In this case as in others, implementing check for endpoint type fixes the issue.

[1] https://syzkaller.appspot.com/bug?extid=040e8b3db6a96908d470
[2] https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622</Note>
    </Notes>
    <CVE>CVE-2024-57993</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net_sched: sch_sfq: don't allow 1 packet limit

The current implementation does not work correctly with a limit of
1. iproute2 actually checks for this and this patch adds the check in
kernel as well.

This fixes the following syzkaller reported crash:

UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:210:6
index 65535 is out of range for type 'struct sfq_head[128]'
CPU: 0 PID: 2569 Comm: syz-executor101 Not tainted 5.10.0-smp-DEV #1
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Call Trace:
  __dump_stack lib/dump_stack.c:79 [inline]
  dump_stack+0x125/0x19f lib/dump_stack.c:120
  ubsan_epilogue lib/ubsan.c:148 [inline]
  __ubsan_handle_out_of_bounds+0xed/0x120 lib/ubsan.c:347
  sfq_link net/sched/sch_sfq.c:210 [inline]
  sfq_dec+0x528/0x600 net/sched/sch_sfq.c:238
  sfq_dequeue+0x39b/0x9d0 net/sched/sch_sfq.c:500
  sfq_reset+0x13/0x50 net/sched/sch_sfq.c:525
  qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026
  tbf_reset+0x3d/0x100 net/sched/sch_tbf.c:319
  qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026
  dev_reset_queue+0x8c/0x140 net/sched/sch_generic.c:1296
  netdev_for_each_tx_queue include/linux/netdevice.h:2350 [inline]
  dev_deactivate_many+0x6dc/0xc20 net/sched/sch_generic.c:1362
  __dev_close_many+0x214/0x350 net/core/dev.c:1468
  dev_close_many+0x207/0x510 net/core/dev.c:1506
  unregister_netdevice_many+0x40f/0x16b0 net/core/dev.c:10738
  unregister_netdevice_queue+0x2be/0x310 net/core/dev.c:10695
  unregister_netdevice include/linux/netdevice.h:2893 [inline]
  __tun_detach+0x6b6/0x1600 drivers/net/tun.c:689
  tun_detach drivers/net/tun.c:705 [inline]
  tun_chr_close+0x104/0x1b0 drivers/net/tun.c:3640
  __fput+0x203/0x840 fs/file_table.c:280
  task_work_run+0x129/0x1b0 kernel/task_work.c:185
  exit_task_work include/linux/task_work.h:33 [inline]
  do_exit+0x5ce/0x2200 kernel/exit.c:931
  do_group_exit+0x144/0x310 kernel/exit.c:1046
  __do_sys_exit_group kernel/exit.c:1057 [inline]
  __se_sys_exit_group kernel/exit.c:1055 [inline]
  __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1055
 do_syscall_64+0x6c/0xd0
 entry_SYSCALL_64_after_hwframe+0x61/0xcb
RIP: 0033:0x7fe5e7b52479
Code: Unable to access opcode bytes at RIP 0x7fe5e7b5244f.
RSP: 002b:00007ffd3c800398 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe5e7b52479
RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000
RBP: 00007fe5e7bcd2d0 R08: ffffffffffffffb8 R09: 0000000000000014
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe5e7bcd2d0
R13: 0000000000000000 R14: 00007fe5e7bcdd20 R15: 00007fe5e7b24270

The crash can be also be reproduced with the following (with a tc
recompiled to allow for sfq limits of 1):

tc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s
../iproute2-6.9.0/tc/tc qdisc add dev dummy0 handle 2: parent 1:10 sfq limit 1
ifconfig dummy0 up
ping -I dummy0 -f -c2 -W0.1 8.8.8.8
sleep 1

Scenario that triggers the crash:

* the first packet is sent and queued in TBF and SFQ; qdisc qlen is 1

* TBF dequeues: it peeks from SFQ which moves the packet to the
  gso_skb list and keeps qdisc qlen set to 1. TBF is out of tokens so
  it schedules itself for later.

* the second packet is sent and TBF tries to queues it to SFQ. qdisc
  qlen is now 2 and because the SFQ limit is 1 the packet is dropped
  by SFQ. At this point qlen is 1, and all of the SFQ slots are empty,
  however q-&gt;tail is not NULL.

At this point, assuming no more packets are queued, when sch_dequeue
runs again it will decrement the qlen for the current empty slot
causing an underflow and the subsequent out of bounds access.</Note>
    </Notes>
    <CVE>CVE-2024-57996</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

wifi: wcn36xx: fix channel survey memory allocation size

KASAN reported a memory allocation issue in wcn-&gt;chan_survey
due to incorrect size calculation.
This commit uses kcalloc to allocate memory for wcn-&gt;chan_survey,
ensuring proper initialization and preventing the use of uninitialized
values when there are no frames on the channel.</Note>
    </Notes>
    <CVE>CVE-2024-57997</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

OPP: add index check to assert to avoid buffer overflow in _read_freq()

Pass the freq index to the assert function to make sure
we do not read a freq out of the opp-&gt;rates[] table when called
from the indexed variants:
dev_pm_opp_find_freq_exact_indexed() or
dev_pm_opp_find_freq_ceil/floor_indexed().

Add a secondary parameter to the assert function, unused
for assert_single_clk() then add assert_clk_index() which
will check for the clock index when called from the _indexed()
find functions.</Note>
    </Notes>
    <CVE>CVE-2024-57998</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

powerpc/pseries/iommu: IOMMU incorrectly marks MMIO range in DDW

Power Hypervisor can possibily allocate MMIO window intersecting with
Dynamic DMA Window (DDW) range, which is over 32-bit addressing.

These MMIO pages needs to be marked as reserved so that IOMMU doesn't map
DMA buffers in this range.

The current code is not marking these pages correctly which is resulting
in LPAR to OOPS while booting. The stack is at below

BUG: Unable to handle kernel data access on read at 0xc00800005cd40000
Faulting instruction address: 0xc00000000005cdac
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: af_packet rfkill ibmveth(X) lpfc(+) nvmet_fc nvmet nvme_keyring crct10dif_vpmsum nvme_fc nvme_fabrics nvme_core be2net(+) nvme_auth rtc_generic nfsd auth_rpcgss nfs_acl lockd grace sunrpc fuse configfs ip_tables x_tables xfs libcrc32c dm_service_time ibmvfc(X) scsi_transport_fc vmx_crypto gf128mul crc32c_vpmsum dm_mirror dm_region_hash dm_log dm_multipath dm_mod sd_mod scsi_dh_emc scsi_dh_rdac scsi_dh_alua t10_pi crc64_rocksoft_generic crc64_rocksoft sg crc64 scsi_mod
Supported: Yes, External
CPU: 8 PID: 241 Comm: kworker/8:1 Kdump: loaded Not tainted 6.4.0-150600.23.14-default #1 SLE15-SP6 b44ee71c81261b9e4bab5e0cde1f2ed891d5359b
Hardware name: IBM,9080-M9S POWER9 (raw) 0x4e2103 0xf000005 of:IBM,FW950.B0 (VH950_149) hv:phyp pSeries
Workqueue: events work_for_cpu_fn
NIP:  c00000000005cdac LR: c00000000005e830 CTR: 0000000000000000
REGS: c00001400c9ff770 TRAP: 0300   Not tainted  (6.4.0-150600.23.14-default)
MSR:  800000000280b033 &lt;SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE&gt;  CR: 24228448  XER: 00000001
CFAR: c00000000005cdd4 DAR: c00800005cd40000 DSISR: 40000000 IRQMASK: 0
GPR00: c00000000005e830 c00001400c9ffa10 c000000001987d00 c00001400c4fe800
GPR04: 0000080000000000 0000000000000001 0000000004000000 0000000000800000
GPR08: 0000000004000000 0000000000000001 c00800005cd40000 ffffffffffffffff
GPR12: 0000000084228882 c00000000a4c4f00 0000000000000010 0000080000000000
GPR16: c00001400c4fe800 0000000004000000 0800000000000000 c00000006088b800
GPR20: c00001401a7be980 c00001400eff3800 c000000002a2da68 000000000000002b
GPR24: c0000000026793a8 c000000002679368 000000000000002a c0000000026793c8
GPR28: 000008007effffff 0000080000000000 0000000000800000 c00001400c4fe800
NIP [c00000000005cdac] iommu_table_reserve_pages+0xac/0x100
LR [c00000000005e830] iommu_init_table+0x80/0x1e0
Call Trace:
[c00001400c9ffa10] [c00000000005e810] iommu_init_table+0x60/0x1e0 (unreliable)
[c00001400c9ffa90] [c00000000010356c] iommu_bypass_supported_pSeriesLP+0x9cc/0xe40
[c00001400c9ffc30] [c00000000005c300] dma_iommu_dma_supported+0xf0/0x230
[c00001400c9ffcb0] [c00000000024b0c4] dma_supported+0x44/0x90
[c00001400c9ffcd0] [c00000000024b14c] dma_set_mask+0x3c/0x80
[c00001400c9ffd00] [c0080000555b715c] be_probe+0xc4/0xb90 [be2net]
[c00001400c9ffdc0] [c000000000986f3c] local_pci_probe+0x6c/0x110
[c00001400c9ffe40] [c000000000188f28] work_for_cpu_fn+0x38/0x60
[c00001400c9ffe70] [c00000000018e454] process_one_work+0x314/0x620
[c00001400c9fff10] [c00000000018f280] worker_thread+0x2b0/0x620
[c00001400c9fff90] [c00000000019bb18] kthread+0x148/0x150
[c00001400c9fffe0] [c00000000000ded8] start_kernel_thread+0x14/0x18

There are 2 issues in the code

1. The index is "int" while the address is "unsigned long". This results in
   negative value when setting the bitmap.

2. The DMA offset is page shifted but the MMIO range is used as-is (64-bit
   address). MMIO address needs to be page shifted as well.</Note>
    </Notes>
    <CVE>CVE-2024-57999</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ocfs2: handle a symlink read error correctly

Patch series "Convert ocfs2 to use folios".

Mark did a conversion of ocfs2 to use folios and sent it to me as a
giant patch for review ;-)

So I've redone it as individual patches, and credited Mark for the patches
where his code is substantially the same.  It's not a bad way to do it;
his patch had some bugs and my patches had some bugs.  Hopefully all our
bugs were different from each other.  And hopefully Mark likes all the
changes I made to his code!


This patch (of 23):

If we can't read the buffer, be sure to unlock the page before returning.</Note>
    </Notes>
    <CVE>CVE-2024-58001</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

media: uvcvideo: Remove dangling pointers

When an async control is written, we copy a pointer to the file handle
that started the operation. That pointer will be used when the device is
done. Which could be anytime in the future.

If the user closes that file descriptor, its structure will be freed,
and there will be one dangling pointer per pending async control, that
the driver will try to use.

Clean all the dangling pointers during release().

To avoid adding a performance penalty in the most common case (no async
operation), a counter has been introduced with some logic to make sure
that it is properly handled.</Note>
    </Notes>
    <CVE>CVE-2024-58002</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

tpm: Change to kvalloc() in eventlog/acpi.c

The following failure was reported on HPE ProLiant D320:

[   10.693310][    T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0)
[   10.848132][    T1] ------------[ cut here ]------------
[   10.853559][    T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330
[   10.862827][    T1] Modules linked in:
[   10.866671][    T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375
[   10.882741][    T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024
[   10.892170][    T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330
[   10.898103][    T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 &lt;0f&gt; 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1
[   10.917750][    T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246
[   10.923777][    T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000
[   10.931727][    T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0

The above transcript shows that ACPI pointed a 16 MiB buffer for the log
events because RSI maps to the 'order' parameter of __alloc_pages_noprof().
Address the bug by moving from devm_kmalloc() to devm_add_action() and
kvmalloc() and devm_add_action().</Note>
    </Notes>
    <CVE>CVE-2024-58005</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

PCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar()

In commit 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update
inbound map address") set_bar() was modified to support dynamically
changing the backing physical address of a BAR that was already configured.

This means that set_bar() can be called twice, without ever calling
clear_bar() (as calling clear_bar() would clear the BAR's PCI address
assigned by the host).

This can only be done if the new BAR size/flags does not differ from the
existing BAR configuration. Add these missing checks.

If we allow set_bar() to set e.g. a new BAR size that differs from the
existing BAR size, the new address translation range will be smaller than
the BAR size already determined by the host, which would mean that a read
past the new BAR size would pass the iATU untranslated, which could allow
the host to read memory not belonging to the new struct pci_epf_bar.

While at it, add comments which clarifies the support for dynamically
changing the physical address of a BAR. (Which was also missing.)</Note>
    </Notes>
    <CVE>CVE-2024-58006</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

soc: qcom: socinfo: Avoid out of bounds read of serial number

On MSM8916 devices, the serial number exposed in sysfs is constant and does
not change across individual devices. It's always:

  db410c:/sys/devices/soc0$ cat serial_number
  2644893864

The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does not
have support for the serial_num field in the socinfo struct. There is an
existing check to avoid exposing the serial number in that case, but it's
not correct: When checking the item_size returned by SMEM, we need to make
sure the *end* of the serial_num is within bounds, instead of comparing
with the *start* offset. The serial_number currently exposed on MSM8916
devices is just an out of bounds read of whatever comes after the socinfo
struct in SMEM.

Fix this by changing offsetof() to offsetofend(), so that the size of the
field is also taken into account.</Note>
    </Notes>
    <CVE>CVE-2024-58007</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc

A NULL sock pointer is passed into l2cap_sock_alloc() when it is called
from l2cap_sock_new_connection_cb() and the error handling paths should
also be aware of it.

Seemingly a more elegant solution would be to swap bt_sock_alloc() and
l2cap_chan_create() calls since they are not interdependent to that moment
but then l2cap_chan_create() adds the soon to be deallocated and still
dummy-initialized channel to the global list accessible by many L2CAP
paths. The channel would be removed from the list in short period of time
but be a bit more straight-forward here and just check for NULL instead of
changing the order of function calls.

Found by Linux Verification Center (linuxtesting.org) with SVACE static
analysis tool.</Note>
    </Notes>
    <CVE>CVE-2024-58009</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

platform/x86: int3472: Check for adev == NULL

Not all devices have an ACPI companion fwnode, so adev might be NULL. This
can e.g. (theoretically) happen when a user manually binds one of
the int3472 drivers to another i2c/platform device through sysfs.

Add a check for adev not being set and return -ENODEV in that case to
avoid a possible NULL pointer deref in skl_int3472_get_acpi_buffer().</Note>
    </Notes>
    <CVE>CVE-2024-58011</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ASoC: SOF: Intel: hda-dai: Ensure DAI widget is valid during params

Each cpu DAI should associate with a widget. However, the topology might
not create the right number of DAI widgets for aggregated amps. And it
will cause NULL pointer deference.
Check that the DAI widget associated with the CPU DAI is valid to prevent
NULL pointer deference due to missing DAI widgets in topologies with
aggregated amps.</Note>
    </Notes>
    <CVE>CVE-2024-58012</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

Bluetooth: MGMT: Fix slab-use-after-free Read in mgmt_remove_adv_monitor_sync

This fixes the following crash:

==================================================================
BUG: KASAN: slab-use-after-free in mgmt_remove_adv_monitor_sync+0x3a/0xd0 net/bluetooth/mgmt.c:5543
Read of size 8 at addr ffff88814128f898 by task kworker/u9:4/5961

CPU: 1 UID: 0 PID: 5961 Comm: kworker/u9:4 Not tainted 6.12.0-syzkaller-10684-gf1cd565ce577 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Workqueue: hci0 hci_cmd_sync_work
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
 mgmt_remove_adv_monitor_sync+0x3a/0xd0 net/bluetooth/mgmt.c:5543
 hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:332
 process_one_work kernel/workqueue.c:3229 [inline]
 process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310
 worker_thread+0x870/0xd30 kernel/workqueue.c:3391
 kthread+0x2f0/0x390 kernel/kthread.c:389
 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
 &lt;/TASK&gt;

Allocated by task 16026:
 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]
 kzalloc_noprof include/linux/slab.h:1037 [inline]
 mgmt_pending_new+0x65/0x250 net/bluetooth/mgmt_util.c:269
 mgmt_pending_add+0x36/0x120 net/bluetooth/mgmt_util.c:296
 remove_adv_monitor+0x102/0x1b0 net/bluetooth/mgmt.c:5568
 hci_mgmt_cmd+0xc47/0x11d0 net/bluetooth/hci_sock.c:1712
 hci_sock_sendmsg+0x7b8/0x11c0 net/bluetooth/hci_sock.c:1832
 sock_sendmsg_nosec net/socket.c:711 [inline]
 __sock_sendmsg+0x221/0x270 net/socket.c:726
 sock_write_iter+0x2d7/0x3f0 net/socket.c:1147
 new_sync_write fs/read_write.c:586 [inline]
 vfs_write+0xaeb/0xd30 fs/read_write.c:679
 ksys_write+0x18f/0x2b0 fs/read_write.c:731
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 16022:
 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]
 kfree+0x196/0x420 mm/slub.c:4746
 mgmt_pending_foreach+0xd1/0x130 net/bluetooth/mgmt_util.c:259
 __mgmt_power_off+0x183/0x430 net/bluetooth/mgmt.c:9550
 hci_dev_close_sync+0x6c4/0x11c0 net/bluetooth/hci_sync.c:5208
 hci_dev_do_close net/bluetooth/hci_core.c:483 [inline]
 hci_dev_close+0x112/0x210 net/bluetooth/hci_core.c:508
 sock_do_ioctl+0x158/0x460 net/socket.c:1209
 sock_ioctl+0x626/0x8e0 net/socket.c:1328
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:906 [inline]
 __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892
 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-58013</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy()

In 'wlc_phy_iqcal_gainparams_nphy()', add gain range check to WARN()
instead of possible out-of-bounds 'tbl_iqcal_gainparams_nphy' access.
Compile tested only.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2024-58014</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

printk: Fix signed integer overflow when defining LOG_BUF_LEN_MAX

Shifting 1 &lt;&lt; 31 on a 32-bit int causes signed integer overflow, which
leads to undefined behavior. To prevent this, cast 1 to u32 before
performing the shift, ensuring well-defined behavior.

This change explicitly avoids any potential overflow by ensuring that
the shift occurs on an unsigned 32-bit integer.</Note>
    </Notes>
    <CVE>CVE-2024-58017</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

nvkm: correctly calculate the available space of the GSP cmdq buffer

r535_gsp_cmdq_push() waits for the available page in the GSP cmdq
buffer when handling a large RPC request. When it sees at least one
available page in the cmdq, it quits the waiting with the amount of
free buffer pages in the queue.

Unfortunately, it always takes the [write pointer, buf_size) as
available buffer pages before rolling back and wrongly calculates the
size of the data should be copied. Thus, it can overwrite the RPC
request that GSP is currently reading, which causes GSP hang due
to corrupted RPC request:

[  549.209389] ------------[ cut here ]------------
[  549.214010] WARNING: CPU: 8 PID: 6314 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:116 r535_gsp_msgq_wait+0xd0/0x190 [nvkm]
[  549.225678] Modules linked in: nvkm(E+) gsp_log(E) snd_seq_dummy(E) snd_hrtimer(E) snd_seq(E) snd_timer(E) snd_seq_device(E) snd(E) soundcore(E) rfkill(E) qrtr(E) vfat(E) fat(E) ipmi_ssif(E) amd_atl(E) intel_rapl_msr(E) intel_rapl_common(E) mlx5_ib(E) amd64_edac(E) edac_mce_amd(E) kvm_amd(E) ib_uverbs(E) kvm(E) ib_core(E) acpi_ipmi(E) ipmi_si(E) mxm_wmi(E) ipmi_devintf(E) rapl(E) i2c_piix4(E) wmi_bmof(E) joydev(E) ptdma(E) acpi_cpufreq(E) k10temp(E) pcspkr(E) ipmi_msghandler(E) xfs(E) libcrc32c(E) ast(E) i2c_algo_bit(E) crct10dif_pclmul(E) drm_shmem_helper(E) nvme_tcp(E) crc32_pclmul(E) ahci(E) drm_kms_helper(E) libahci(E) nvme_fabrics(E) crc32c_intel(E) nvme(E) cdc_ether(E) mlx5_core(E) nvme_core(E) usbnet(E) drm(E) libata(E) ccp(E) ghash_clmulni_intel(E) mii(E) t10_pi(E) mlxfw(E) sp5100_tco(E) psample(E) pci_hyperv_intf(E) wmi(E) dm_multipath(E) sunrpc(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E) be2iscsi(E) bnx2i(E) cnic(E) uio(E) cxgb4i(E) cxgb4(E) tls(E) libcxgbi(E) libcxgb(E) qla4xxx(E)
[  549.225752]  iscsi_boot_sysfs(E) iscsi_tcp(E) libiscsi_tcp(E) libiscsi(E) scsi_transport_iscsi(E) fuse(E) [last unloaded: gsp_log(E)]
[  549.326293] CPU: 8 PID: 6314 Comm: insmod Tainted: G            E      6.9.0-rc6+ #1
[  549.334039] Hardware name: ASRockRack 1U1G-MILAN/N/ROMED8-NL, BIOS L3.12E 09/06/2022
[  549.341781] RIP: 0010:r535_gsp_msgq_wait+0xd0/0x190 [nvkm]
[  549.347343] Code: 08 00 00 89 da c1 e2 0c 48 8d ac 11 00 10 00 00 48 8b 0c 24 48 85 c9 74 1f c1 e0 0c 4c 8d 6d 30 83 e8 30 89 01 e9 68 ff ff ff &lt;0f&gt; 0b 49 c7 c5 92 ff ff ff e9 5a ff ff ff ba ff ff ff ff be c0 0c
[  549.366090] RSP: 0018:ffffacbccaaeb7d0 EFLAGS: 00010246
[  549.371315] RAX: 0000000000000000 RBX: 0000000000000012 RCX: 0000000000923e28
[  549.378451] RDX: 0000000000000000 RSI: 0000000055555554 RDI: ffffacbccaaeb730
[  549.385590] RBP: 0000000000000001 R08: ffff8bd14d235f70 R09: ffff8bd14d235f70
[  549.392721] R10: 0000000000000002 R11: ffff8bd14d233864 R12: 0000000000000020
[  549.399854] R13: ffffacbccaaeb818 R14: 0000000000000020 R15: ffff8bb298c67000
[  549.406988] FS:  00007f5179244740(0000) GS:ffff8bd14d200000(0000) knlGS:0000000000000000
[  549.415076] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  549.420829] CR2: 00007fa844000010 CR3: 00000001567dc005 CR4: 0000000000770ef0
[  549.427963] PKRU: 55555554
[  549.430672] Call Trace:
[  549.433126]  &lt;TASK&gt;
[  549.435233]  ? __warn+0x7f/0x130
[  549.438473]  ? r535_gsp_msgq_wait+0xd0/0x190 [nvkm]
[  549.443426]  ? report_bug+0x18a/0x1a0
[  549.447098]  ? handle_bug+0x3c/0x70
[  549.450589]  ? exc_invalid_op+0x14/0x70
[  549.454430]  ? asm_exc_invalid_op+0x16/0x20
[  549.458619]  ? r535_gsp_msgq_wait+0xd0/0x190 [nvkm]
[  549.463565]  r535_gsp_msg_recv+0x46/0x230 [nvkm]
[  549.468257]  r535_gsp_rpc_push+0x106/0x160 [nvkm]
[  549.473033]  r535_gsp_rpc_rm_ctrl_push+0x40/0x130 [nvkm]
[  549.478422]  nvidia_grid_init_vgpu_types+0xbc/0xe0 [nvkm]
[  549.483899]  nvidia_grid_init+0xb1/0xd0 [nvkm]
[  549.488420]  ? srso_alias_return_thunk+0x5/0xfbef5
[  549.493213]  nvkm_device_pci_probe+0x305/0x420 [nvkm]
[  549.498338]  local_pci_probe+0x46/
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-58018</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

nvkm/gsp: correctly advance the read pointer of GSP message queue

A GSP event message consists three parts: message header, RPC header,
message body. GSP calculates the number of pages to write from the
total size of a GSP message. This behavior can be observed from the
movement of the write pointer.

However, nvkm takes only the size of RPC header and message body as
the message size when advancing the read pointer. When handling a
two-page GSP message in the non rollback case, It wrongly takes the
message body of the previous message as the message header of the next
message. As the "message length" tends to be zero, in the calculation of
size needs to be copied (0 - size of (message header)), the size needs to
be copied will be "0xffffffxx". It also triggers a kernel panic due to a
NULL pointer error.

[  547.614102] msg: 00000f90: ff ff ff ff ff ff ff ff 40 d7 18 fb 8b 00 00 00  ........@.......
[  547.622533] msg: 00000fa0: 00 00 00 00 ff ff ff ff ff ff ff ff 00 00 00 00  ................
[  547.630965] msg: 00000fb0: ff ff ff ff ff ff ff ff 00 00 00 00 ff ff ff ff  ................
[  547.639397] msg: 00000fc0: ff ff ff ff 00 00 00 00 ff ff ff ff ff ff ff ff  ................
[  547.647832] nvkm 0000:c1:00.0: gsp: peek msg rpc fn:0 len:0x0/0xffffffffffffffe0
[  547.655225] nvkm 0000:c1:00.0: gsp: get msg rpc fn:0 len:0x0/0xffffffffffffffe0
[  547.662532] BUG: kernel NULL pointer dereference, address: 0000000000000020
[  547.669485] #PF: supervisor read access in kernel mode
[  547.674624] #PF: error_code(0x0000) - not-present page
[  547.679755] PGD 0 P4D 0
[  547.682294] Oops: 0000 [#1] PREEMPT SMP NOPTI
[  547.686643] CPU: 22 PID: 322 Comm: kworker/22:1 Tainted: G            E      6.9.0-rc6+ #1
[  547.694893] Hardware name: ASRockRack 1U1G-MILAN/N/ROMED8-NL, BIOS L3.12E 09/06/2022
[  547.702626] Workqueue: events r535_gsp_msgq_work [nvkm]
[  547.707921] RIP: 0010:r535_gsp_msg_recv+0x87/0x230 [nvkm]
[  547.713375] Code: 00 8b 70 08 48 89 e1 31 d2 4c 89 f7 e8 12 f5 ff ff 48 89 c5 48 85 c0 0f 84 cf 00 00 00 48 81 fd 00 f0 ff ff 0f 87 c4 00 00 00 &lt;8b&gt; 55 10 41 8b 46 30 85 d2 0f 85 f6 00 00 00 83 f8 04 76 10 ba 05
[  547.732119] RSP: 0018:ffffabe440f87e10 EFLAGS: 00010203
[  547.737335] RAX: 0000000000000010 RBX: 0000000000000008 RCX: 000000000000003f
[  547.744461] RDX: 0000000000000000 RSI: ffffabe4480a8030 RDI: 0000000000000010
[  547.751585] RBP: 0000000000000010 R08: 0000000000000000 R09: ffffabe440f87bb0
[  547.758707] R10: ffffabe440f87dc8 R11: 0000000000000010 R12: 0000000000000000
[  547.765834] R13: 0000000000000000 R14: ffff9351df1e5000 R15: 0000000000000000
[  547.772958] FS:  0000000000000000(0000) GS:ffff93708eb00000(0000) knlGS:0000000000000000
[  547.781035] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  547.786771] CR2: 0000000000000020 CR3: 00000003cc220002 CR4: 0000000000770ef0
[  547.793896] PKRU: 55555554
[  547.796600] Call Trace:
[  547.799046]  &lt;TASK&gt;
[  547.801152]  ? __die+0x20/0x70
[  547.804211]  ? page_fault_oops+0x75/0x170
[  547.808221]  ? print_hex_dump+0x100/0x160
[  547.812226]  ? exc_page_fault+0x64/0x150
[  547.816152]  ? asm_exc_page_fault+0x22/0x30
[  547.820341]  ? r535_gsp_msg_recv+0x87/0x230 [nvkm]
[  547.825184]  r535_gsp_msgq_work+0x42/0x50 [nvkm]
[  547.829845]  process_one_work+0x196/0x3d0
[  547.833861]  worker_thread+0x2fc/0x410
[  547.837613]  ? __pfx_worker_thread+0x10/0x10
[  547.841885]  kthread+0xdf/0x110
[  547.845031]  ? __pfx_kthread+0x10/0x10
[  547.848775]  ret_from_fork+0x30/0x50
[  547.852354]  ? __pfx_kthread+0x10/0x10
[  547.856097]  ret_from_fork_asm+0x1a/0x30
[  547.860019]  &lt;/TASK&gt;
[  547.862208] Modules linked in: nvkm(E) gsp_log(E) snd_seq_dummy(E) snd_hrtimer(E) snd_seq(E) snd_timer(E) snd_seq_device(E) snd(E) soundcore(E) rfkill(E) qrtr(E) vfat(E) fat(E) ipmi_ssif(E) amd_atl(E) intel_rapl_msr(E) intel_rapl_common(E) amd64_edac(E) mlx5_ib(E) edac_mce_amd(E) kvm_amd
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-58019</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

HID: multitouch: Add NULL check in mt_input_configured

devm_kasprintf() can return a NULL pointer on failure,but this
returned value in mt_input_configured() is not checked.
Add NULL check in mt_input_configured(), to handle kernel NULL
pointer dereference error.</Note>
    </Notes>
    <CVE>CVE-2024-58020</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()

As of_find_node_by_name() release the reference of the argument device
node, tegra_emc_find_node_by_ram_code() releases some device nodes while
still in use, resulting in possible UAFs. According to the bindings and
the in-tree DTS files, the "emc-tables" node is always device's child
node with the property "nvidia,use-ram-code", and the "lpddr2" node is a
child of the "emc-tables" node. Thus utilize the
for_each_child_of_node() macro and of_get_child_by_name() instead of
of_find_node_by_name() to simplify the code.

This bug was found by an experimental verification tool that I am
developing.

[krzysztof: applied v1, adjust the commit msg to incorporate v2 parts]</Note>
    </Notes>
    <CVE>CVE-2024-58034</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ipmi: ipmb: Add check devm_kasprintf() returned value

devm_kasprintf() can return a NULL pointer on failure but this
returned value is not checked.</Note>
    </Notes>
    <CVE>CVE-2024-58051</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_table

The function atomctrl_get_smc_sclk_range_table() does not check the return
value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to
retrieve SMU_Info table, it returns NULL which is later dereferenced.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

In practice this should never happen as this code only gets called
on polaris chips and the vbios data table will always be present on
those chips.</Note>
    </Notes>
    <CVE>CVE-2024-58052</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

staging: media: max96712: fix kernel oops when removing module

The following kernel oops is thrown when trying to remove the max96712
module:

Unable to handle kernel paging request at virtual address 00007375746174db
Mem abort info:
  ESR = 0x0000000096000004
  EC = 0x25: DABT (current EL), IL = 32 bits
  SET = 0, FnV = 0
  EA = 0, S1PTW = 0
  FSC = 0x04: level 0 translation fault
Data abort info:
  ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
  CM = 0, WnR = 0, TnD = 0, TagAccess = 0
  GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af89000
[00007375746174db] pgd=0000000000000000, p4d=0000000000000000
Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
Modules linked in: crct10dif_ce polyval_ce mxc_jpeg_encdec flexcan
    snd_soc_fsl_sai snd_soc_fsl_asoc_card snd_soc_fsl_micfil dwc_mipi_csi2
    imx_csi_formatter polyval_generic v4l2_jpeg imx_pcm_dma can_dev
    snd_soc_imx_audmux snd_soc_wm8962 snd_soc_imx_card snd_soc_fsl_utils
    max96712(C-) rpmsg_ctrl rpmsg_char pwm_fan fuse
    [last unloaded: imx8_isi]
CPU: 0 UID: 0 PID: 754 Comm: rmmod
	    Tainted: G         C    6.12.0-rc6-06364-g327fec852c31 #17
Tainted: [C]=CRAP
Hardware name: NXP i.MX95 19X19 board (DT)
pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : led_put+0x1c/0x40
lr : v4l2_subdev_put_privacy_led+0x48/0x58
sp : ffff80008699bbb0
x29: ffff80008699bbb0 x28: ffff00008ac233c0 x27: 0000000000000000
x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
x23: ffff000080cf1170 x22: ffff00008b53bd00 x21: ffff8000822ad1c8
x20: ffff000080ff5c00 x19: ffff00008b53be40 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
x14: 0000000000000004 x13: ffff0000800f8010 x12: 0000000000000000
x11: ffff000082acf5c0 x10: ffff000082acf478 x9 : ffff0000800f8010
x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d
x5 : 8080808000000000 x4 : 0000000000000020 x3 : 00000000553a3dc1
x2 : ffff00008ac233c0 x1 : ffff00008ac233c0 x0 : ff00737574617473
Call trace:
 led_put+0x1c/0x40
 v4l2_subdev_put_privacy_led+0x48/0x58
 v4l2_async_unregister_subdev+0x2c/0x1a4
 max96712_remove+0x1c/0x38 [max96712]
 i2c_device_remove+0x2c/0x9c
 device_remove+0x4c/0x80
 device_release_driver_internal+0x1cc/0x228
 driver_detach+0x4c/0x98
 bus_remove_driver+0x6c/0xbc
 driver_unregister+0x30/0x60
 i2c_del_driver+0x54/0x64
 max96712_i2c_driver_exit+0x18/0x1d0 [max96712]
 __arm64_sys_delete_module+0x1a4/0x290
 invoke_syscall+0x48/0x10c
 el0_svc_common.constprop.0+0xc0/0xe0
 do_el0_svc+0x1c/0x28
 el0_svc+0x34/0xd8
 el0t_64_sync_handler+0x120/0x12c
 el0t_64_sync+0x190/0x194
Code: f9000bf3 aa0003f3 f9402800 f9402000 (f9403400)
---[ end trace 0000000000000000 ]---

This happens because in v4l2_i2c_subdev_init(), the i2c_set_cliendata()
is called again and the data is overwritten to point to sd, instead of
priv. So, in remove(), the wrong pointer is passed to
v4l2_async_unregister_subdev(), leading to a crash.</Note>
    </Notes>
    <CVE>CVE-2024-58054</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

usb: gadget: f_tcm: Don't free command immediately

Don't prematurely free the command. Wait for the status completion of
the sense status. It can be freed then. Otherwise we will double-free
the command.</Note>
    </Notes>
    <CVE>CVE-2024-58055</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

remoteproc: core: Fix ida_free call while not allocated

In the rproc_alloc() function, on error, put_device(&amp;rproc-&gt;dev) is
called, leading to the call of the rproc_type_release() function.
An error can occurs before ida_alloc is called.

In such case in rproc_type_release(), the condition (rproc-&gt;index &gt;= 0) is
true as rproc-&gt;index has been  initialized to 0.
ida_free() is called reporting a warning:
[    4.181906] WARNING: CPU: 1 PID: 24 at lib/idr.c:525 ida_free+0x100/0x164
[    4.186378] stm32-display-dsi 5a000000.dsi: Fixed dependency cycle(s) with /soc/dsi@5a000000/panel@0
[    4.188854] ida_free called for id=0 which is not allocated.
[    4.198256] mipi-dsi 5a000000.dsi.0: Fixed dependency cycle(s) with /soc/dsi@5a000000
[    4.203556] Modules linked in: panel_orisetech_otm8009a dw_mipi_dsi_stm(+) gpu_sched dw_mipi_dsi stm32_rproc stm32_crc32 stm32_ipcc(+) optee(+)
[    4.224307] CPU: 1 UID: 0 PID: 24 Comm: kworker/u10:0 Not tainted 6.12.0 #442
[    4.231481] Hardware name: STM32 (Device Tree Support)
[    4.236627] Workqueue: events_unbound deferred_probe_work_func
[    4.242504] Call trace:
[    4.242522]  unwind_backtrace from show_stack+0x10/0x14
[    4.250218]  show_stack from dump_stack_lvl+0x50/0x64
[    4.255274]  dump_stack_lvl from __warn+0x80/0x12c
[    4.260134]  __warn from warn_slowpath_fmt+0x114/0x188
[    4.265199]  warn_slowpath_fmt from ida_free+0x100/0x164
[    4.270565]  ida_free from rproc_type_release+0x38/0x60
[    4.275832]  rproc_type_release from device_release+0x30/0xa0
[    4.281601]  device_release from kobject_put+0xc4/0x294
[    4.286762]  kobject_put from rproc_alloc.part.0+0x208/0x28c
[    4.292430]  rproc_alloc.part.0 from devm_rproc_alloc+0x80/0xc4
[    4.298393]  devm_rproc_alloc from stm32_rproc_probe+0xd0/0x844 [stm32_rproc]
[    4.305575]  stm32_rproc_probe [stm32_rproc] from platform_probe+0x5c/0xbc

Calling ida_alloc earlier in rproc_alloc ensures that the rproc-&gt;index is
properly set.</Note>
    </Notes>
    <CVE>CVE-2024-58056</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

idpf: convert workqueues to unbound

When a workqueue is created with `WQ_UNBOUND`, its work items are
served by special worker-pools, whose host workers are not bound to
any specific CPU. In the default configuration (i.e. when
`queue_delayed_work` and friends do not specify which CPU to run the
work item on), `WQ_UNBOUND` allows the work item to be executed on any
CPU in the same node of the CPU it was enqueued on. While this
solution potentially sacrifices locality, it avoids contention with
other processes that might dominate the CPU time of the processor the
work item was scheduled on.

This is not just a theoretical problem: in a particular scenario
misconfigured process was hogging most of the time from CPU0, leaving
less than 0.5% of its CPU time to the kworker. The IDPF workqueues
that were using the kworker on CPU0 suffered large completion delays
as a result, causing performance degradation, timeouts and eventual
system crash.


* I have also run a manual test to gauge the performance
  improvement. The test consists of an antagonist process
  (`./stress --cpu 2`) consuming as much of CPU 0 as possible. This
  process is run under `taskset 01` to bind it to CPU0, and its
  priority is changed with `chrt -pQ 9900 10000 ${pid}` and
  `renice -n -20 ${pid}` after start.

  Then, the IDPF driver is forced to prefer CPU0 by editing all calls
  to `queue_delayed_work`, `mod_delayed_work`, etc... to use CPU 0.

  Finally, `ktraces` for the workqueue events are collected.

  Without the current patch, the antagonist process can force
  arbitrary delays between `workqueue_queue_work` and
  `workqueue_execute_start`, that in my tests were as high as
  `30ms`. With the current patch applied, the workqueue can be
  migrated to another unloaded CPU in the same node, and, keeping
  everything else equal, the maximum delay I could see was `6us`.</Note>
    </Notes>
    <CVE>CVE-2024-58057</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ubifs: skip dumping tnc tree when zroot is null

Clearing slab cache will free all znode in memory and make
c-&gt;zroot.znode = NULL, then dumping tnc tree will access
c-&gt;zroot.znode which cause null pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2024-58058</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

wifi: mac80211: prohibit deactivating all links

In the internal API this calls this is a WARN_ON, but that
should remain since internally we want to know about bugs
that may cause this. Prevent deactivating all links in the
debugfs write directly.</Note>
    </Notes>
    <CVE>CVE-2024-58061</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

wifi: rtlwifi: fix memory leaks and invalid access at probe error path

Deinitialize at reverse order when probe fails.

When init_sw_vars fails, rtl_deinit_core should not be called, specially
now that it destroys the rtl_wq workqueue.

And call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will be
leaked.

Remove pci_set_drvdata call as it will already be cleaned up by the core
driver code and could lead to memory leaks too. cf. commit 8d450935ae7f
("wireless: rtlwifi: remove unnecessary pci_set_drvdata()") and
commit 3d86b93064c7 ("rtlwifi: Fix PCI probe error path orphaned memory").</Note>
    </Notes>
    <CVE>CVE-2024-58063</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

OPP: fix dev_pm_opp_find_bw_*() when bandwidth table not initialized

If a driver calls dev_pm_opp_find_bw_ceil/floor() the retrieve bandwidth
from the OPP table but the bandwidth table was not created because the
interconnect properties were missing in the OPP consumer node, the
kernel will crash with:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004
...
pc : _read_bw+0x8/0x10
lr : _opp_table_find_key+0x9c/0x174
...
Call trace:
  _read_bw+0x8/0x10 (P)
  _opp_table_find_key+0x9c/0x174 (L)
  _find_key+0x98/0x168
  dev_pm_opp_find_bw_ceil+0x50/0x88
...

In order to fix the crash, create an assert function to check
if the bandwidth table was created before trying to get a
bandwidth with _read_bw().</Note>
    </Notes>
    <CVE>CVE-2024-58068</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read

The nvmem interface supports variable buffer sizes, while the regmap
interface operates with fixed-size storage. If an nvmem client uses a
buffer size less than 4 bytes, regmap_read will write out of bounds
as it expects the buffer to point at an unsigned int.

Fix this by using an intermediary unsigned int to hold the value.</Note>
    </Notes>
    <CVE>CVE-2024-58069</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

bpf: bpf_local_storage: Always use bpf_mem_alloc in PREEMPT_RT

In PREEMPT_RT, kmalloc(GFP_ATOMIC) is still not safe in non preemptible
context. bpf_mem_alloc must be used in PREEMPT_RT. This patch is
to enforce bpf_mem_alloc in the bpf_local_storage when CONFIG_PREEMPT_RT
is enabled.

[   35.118559] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
[   35.118566] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1832, name: test_progs
[   35.118569] preempt_count: 1, expected: 0
[   35.118571] RCU nest depth: 1, expected: 1
[   35.118577] INFO: lockdep is turned off.
    ...
[   35.118647]  __might_resched+0x433/0x5b0
[   35.118677]  rt_spin_lock+0xc3/0x290
[   35.118700]  ___slab_alloc+0x72/0xc40
[   35.118723]  __kmalloc_noprof+0x13f/0x4e0
[   35.118732]  bpf_map_kzalloc+0xe5/0x220
[   35.118740]  bpf_selem_alloc+0x1d2/0x7b0
[   35.118755]  bpf_local_storage_update+0x2fa/0x8b0
[   35.118784]  bpf_sk_storage_get_tracing+0x15a/0x1d0
[   35.118791]  bpf_prog_9a118d86fca78ebb_trace_inet_sock_set_state+0x44/0x66
[   35.118795]  bpf_trace_run3+0x222/0x400
[   35.118820]  __bpf_trace_inet_sock_set_state+0x11/0x20
[   35.118824]  trace_inet_sock_set_state+0x112/0x130
[   35.118830]  inet_sk_state_store+0x41/0x90
[   35.118836]  tcp_set_state+0x3b3/0x640

There is no need to adjust the gfp_flags passing to the
bpf_mem_cache_alloc_flags() which only honors the GFP_KERNEL.
The verifier has ensured GFP_KERNEL is passed only in sleepable context.

It has been an old issue since the first introduction of the
bpf_local_storage ~5 years ago, so this patch targets the bpf-next.

bpf_mem_alloc is needed to solve it, so the Fixes tag is set
to the commit when bpf_mem_alloc was first used in the bpf_local_storage.</Note>
    </Notes>
    <CVE>CVE-2024-58070</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

team: prevent adding a device which is already a team device lower

Prevent adding a device which is already a team device lower,
e.g. adding veth0 if vlan1 was already added and veth0 is a lower of
vlan1.

This is not useful in practice and can lead to recursive locking:

$ ip link add veth0 type veth peer name veth1
$ ip link set veth0 up
$ ip link set veth1 up
$ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1
$ ip link add team0 type team
$ ip link set veth0.1 down
$ ip link set veth0.1 master team0
team0: Port device veth0.1 added
$ ip link set veth0 down
$ ip link set veth0 master team0

============================================
WARNING: possible recursive locking detected
6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted
--------------------------------------------
ip/7684 is trying to acquire lock:
ffff888016848e00 (team-&gt;team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)

but task is already holding lock:
ffff888016848e00 (team-&gt;team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977)

other info that might help us debug this:
Possible unsafe locking scenario:

CPU0
----
lock(team-&gt;team_lock_key);
lock(team-&gt;team_lock_key);

*** DEADLOCK ***

May be due to missing lock nesting notation

2 locks held by ip/7684:

stack backtrace:
CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
&lt;TASK&gt;
dump_stack_lvl (lib/dump_stack.c:122)
print_deadlock_bug.cold (kernel/locking/lockdep.c:3040)
__lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226)
? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548)
lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851)
? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2))
? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
? lock_acquire (kernel/locking/lockdep.c:5822)
? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
__mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735)
? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
? fib_sync_up (net/ipv4/fib_semantics.c:2167)
? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)
notifier_call_chain (kernel/notifier.c:85)
call_netdevice_notifiers_info (net/core/dev.c:1996)
__dev_notify_flags (net/core/dev.c:8993)
? __dev_change_flags (net/core/dev.c:8975)
dev_change_flags (net/core/dev.c:9027)
vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470)
? br_device_event (net/bridge/br.c:143)
notifier_call_chain (kernel/notifier.c:85)
call_netdevice_notifiers_info (net/core/dev.c:1996)
dev_open (net/core/dev.c:1519 net/core/dev.c:1505)
team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977)
? __pfx_team_add_slave (drivers/net/team/team_core.c:1972)
do_set_master (net/core/rtnetlink.c:2917)
do_setlink.isra.0 (net/core/rtnetlink.c:3117)</Note>
    </Notes>
    <CVE>CVE-2024-58071</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

wifi: rtlwifi: remove unused check_buddy_priv

Commit 2461c7d60f9f ("rtlwifi: Update header file") introduced a global
list of private data structures.

Later on, commit 26634c4b1868 ("rtlwifi Modify existing bits to match
vendor version 2013.02.07") started adding the private data to that list at
probe time and added a hook, check_buddy_priv to find the private data from
a similar device.

However, that function was never used.

Besides, though there is a lock for that list, it is never used. And when
the probe fails, the private data is never removed from the list. This
would cause a second probe to access freed memory.

Remove the unused hook, structures and members, which will prevent the
potential race condition on the list and its corruption during a second
probe when probe fails.</Note>
    </Notes>
    <CVE>CVE-2024-58072</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

clk: qcom: gcc-sm6350: Add missing parent_map for two clocks

If a clk_rcg2 has a parent, it should also have parent_map defined,
otherwise we'll get a NULL pointer dereference when calling clk_set_rate
like the following:

  [    3.388105] Call trace:
  [    3.390664]  qcom_find_src_index+0x3c/0x70 (P)
  [    3.395301]  qcom_find_src_index+0x1c/0x70 (L)
  [    3.399934]  _freq_tbl_determine_rate+0x48/0x100
  [    3.404753]  clk_rcg2_determine_rate+0x1c/0x28
  [    3.409387]  clk_core_determine_round_nolock+0x58/0xe4
  [    3.421414]  clk_core_round_rate_nolock+0x48/0xfc
  [    3.432974]  clk_core_round_rate_nolock+0xd0/0xfc
  [    3.444483]  clk_core_set_rate_nolock+0x8c/0x300
  [    3.455886]  clk_set_rate+0x38/0x14c

Add the parent_map property for two clocks where it's missing and also
un-inline the parent_data as well to keep the matching parent_map and
parent_data together.</Note>
    </Notes>
    <CVE>CVE-2024-58076</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

misc: misc_minor_alloc to use ida for all dynamic/misc dynamic minors

misc_minor_alloc was allocating id using ida for minor only in case of
MISC_DYNAMIC_MINOR but misc_minor_free was always freeing ids
using ida_free causing a mismatch and following warn:
&gt; &gt; WARNING: CPU: 0 PID: 159 at lib/idr.c:525 ida_free+0x3e0/0x41f
&gt; &gt; ida_free called for id=127 which is not allocated.
&gt; &gt; &lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;
...
&gt; &gt; [&lt;60941eb4&gt;] ida_free+0x3e0/0x41f
&gt; &gt; [&lt;605ac993&gt;] misc_minor_free+0x3e/0xbc
&gt; &gt; [&lt;605acb82&gt;] misc_deregister+0x171/0x1b3

misc_minor_alloc is changed to allocate id from ida for all minors
falling in the range of dynamic/ misc dynamic minors</Note>
    </Notes>
    <CVE>CVE-2024-58078</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

media: uvcvideo: Fix crash during unbind if gpio unit is in use

We used the wrong device for the device managed functions. We used the
usb device, when we should be using the interface device.

If we unbind the driver from the usb interface, the cleanup functions
are never called. In our case, the IRQ is never disabled.

If an IRQ is triggered, it will try to access memory sections that are
already free, causing an OOPS.

We cannot use the function devm_request_threaded_irq here. The devm_*
clean functions may be called after the main structure is released by
uvc_delete.

Luckily this bug has small impact, as it is only affected by devices
with gpio units and the user has to unbind the device, a disconnect will
not trigger this error.</Note>
    </Notes>
    <CVE>CVE-2024-58079</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

clk: qcom: dispcc-sm6350: Add missing parent_map for a clock

If a clk_rcg2 has a parent, it should also have parent_map defined,
otherwise we'll get a NULL pointer dereference when calling clk_set_rate
like the following:

  [    3.388105] Call trace:
  [    3.390664]  qcom_find_src_index+0x3c/0x70 (P)
  [    3.395301]  qcom_find_src_index+0x1c/0x70 (L)
  [    3.399934]  _freq_tbl_determine_rate+0x48/0x100
  [    3.404753]  clk_rcg2_determine_rate+0x1c/0x28
  [    3.409387]  clk_core_determine_round_nolock+0x58/0xe4
  [    3.421414]  clk_core_round_rate_nolock+0x48/0xfc
  [    3.432974]  clk_core_round_rate_nolock+0xd0/0xfc
  [    3.444483]  clk_core_set_rate_nolock+0x8c/0x300
  [    3.455886]  clk_set_rate+0x38/0x14c

Add the parent_map property for the clock where it's missing and also
un-inline the parent_data as well to keep the matching parent_map and
parent_data together.</Note>
    </Notes>
    <CVE>CVE-2024-58080</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

KVM: Explicitly verify target vCPU is online in kvm_get_vcpu()

Explicitly verify the target vCPU is fully online _prior_ to clamping the
index in kvm_get_vcpu().  If the index is "bad", the nospec clamping will
generate '0', i.e. KVM will return vCPU0 instead of NULL.

In practice, the bug is unlikely to cause problems, as it will only come
into play if userspace or the guest is buggy or misbehaving, e.g. KVM may
send interrupts to vCPU0 instead of dropping them on the floor.

However, returning vCPU0 when it shouldn't exist per online_vcpus is
problematic now that KVM uses an xarray for the vCPUs array, as KVM needs
to insert into the xarray before publishing the vCPU to userspace (see
commit c5b077549136 ("KVM: Convert the kvm-&gt;vcpus array to a xarray")),
i.e. before vCPU creation is guaranteed to succeed.

As a result, incorrectly providing access to vCPU0 will trigger a
use-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu()
bails out of vCPU creation due to an error and frees vCPU0.  Commit
afb2acb2e3a3 ("KVM: Fix vcpu_array[0] races") papered over that issue, but
in doing so introduced an unsolvable teardown conundrum.  Preventing
accesses to vCPU0 before it's fully online will allow reverting commit
afb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race.</Note>
    </Notes>
    <CVE>CVE-2024-58083</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

tomoyo: don't emit warning in tomoyo_write_control()

syzbot is reporting too large allocation warning at tomoyo_write_control(),
for one can write a very very long line without new line character. To fix
this warning, I use __GFP_NOWARN rather than checking for KMALLOC_MAX_SIZE,
for practically a valid line should be always shorter than 32KB where the
"too small to fail" memory-allocation rule applies.

One might try to write a valid line that is longer than 32KB, but such
request will likely fail with -ENOMEM. Therefore, I feel that separately
returning -EINVAL when a line is longer than KMALLOC_MAX_SIZE is redundant.
There is no need to distinguish over-32KB and over-KMALLOC_MAX_SIZE.</Note>
    </Notes>
    <CVE>CVE-2024-58085</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

drm/v3d: Stop active perfmon if it is being destroyed

If the active performance monitor (`v3d-&gt;active_perfmon`) is being
destroyed, stop it first. Currently, the active perfmon is not
stopped during destruction, leaving the `v3d-&gt;active_perfmon` pointer
stale. This can lead to undefined behavior and instability.

This patch ensures that the active perfmon is stopped before being
destroyed, aligning with the behavior introduced in commit
7d1fd3638ee3 ("drm/v3d: Stop the active perfmon before being destroyed").</Note>
    </Notes>
    <CVE>CVE-2024-58086</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

bpf: Fix deadlock when freeing cgroup storage

The following commit
bc235cdb423a ("bpf: Prevent deadlock from recursive bpf_task_storage_[get|delete]")
first introduced deadlock prevention for fentry/fexit programs attaching
on bpf_task_storage helpers. That commit also employed the logic in map
free path in its v6 version.

Later bpf_cgrp_storage was first introduced in
c4bcfb38a95e ("bpf: Implement cgroup storage available to non-cgroup-attached bpf progs")
which faces the same issue as bpf_task_storage, instead of its busy
counter, NULL was passed to bpf_local_storage_map_free() which opened
a window to cause deadlock:

	&lt;TASK&gt;
		(acquiring local_storage-&gt;lock)
	_raw_spin_lock_irqsave+0x3d/0x50
	bpf_local_storage_update+0xd1/0x460
	bpf_cgrp_storage_get+0x109/0x130
	bpf_prog_a4d4a370ba857314_cgrp_ptr+0x139/0x170
	? __bpf_prog_enter_recur+0x16/0x80
	bpf_trampoline_6442485186+0x43/0xa4
	cgroup_storage_ptr+0x9/0x20
		(holding local_storage-&gt;lock)
	bpf_selem_unlink_storage_nolock.constprop.0+0x135/0x160
	bpf_selem_unlink_storage+0x6f/0x110
	bpf_local_storage_map_free+0xa2/0x110
	bpf_map_free_deferred+0x5b/0x90
	process_one_work+0x17c/0x390
	worker_thread+0x251/0x360
	kthread+0xd2/0x100
	ret_from_fork+0x34/0x50
	ret_from_fork_asm+0x1a/0x30
	&lt;/TASK&gt;

Progs:
 - A: SEC("fentry/cgroup_storage_ptr")
   - cgid (BPF_MAP_TYPE_HASH)
	Record the id of the cgroup the current task belonging
	to in this hash map, using the address of the cgroup
	as the map key.
   - cgrpa (BPF_MAP_TYPE_CGRP_STORAGE)
	If current task is a kworker, lookup the above hash
	map using function parameter @owner as the key to get
	its corresponding cgroup id which is then used to get
	a trusted pointer to the cgroup through
	bpf_cgroup_from_id(). This trusted pointer can then
	be passed to bpf_cgrp_storage_get() to finally trigger
	the deadlock issue.
 - B: SEC("tp_btf/sys_enter")
   - cgrpb (BPF_MAP_TYPE_CGRP_STORAGE)
	The only purpose of this prog is to fill Prog A's
	hash map by calling bpf_cgrp_storage_get() for as
	many userspace tasks as possible.

Steps to reproduce:
 - Run A;
 - while (true) { Run B; Destroy B; }

Fix this issue by passing its busy counter to the free procedure so
it can be properly incremented before storage/smap locking.</Note>
    </Notes>
    <CVE>CVE-2024-58088</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

PCI/ASPM: Fix link state exit during switch upstream function removal

Before 456d8aa37d0f ("PCI/ASPM: Disable ASPM on MFD function removal to
avoid use-after-free"), we would free the ASPM link only after the last
function on the bus pertaining to the given link was removed.

That was too late. If function 0 is removed before sibling function,
link-&gt;downstream would point to free'd memory after.

After above change, we freed the ASPM parent link state upon any function
removal on the bus pertaining to a given link.

That is too early. If the link is to a PCIe switch with MFD on the upstream
port, then removing functions other than 0 first would free a link which
still remains parent_link to the remaining downstream ports.

The resulting GPFs are especially frequent during hot-unplug, because
pciehp removes devices on the link bus in reverse order.

On that switch, function 0 is the virtual P2P bridge to the internal bus.
Free exactly when function 0 is removed -- before the parent link is
obsolete, but after all subordinate links are gone.

[kwilczynski: commit log]</Note>
    </Notes>
    <CVE>CVE-2024-58093</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

jfs: add check read-only before truncation in jfs_truncate_nolock()

Added a check for "read-only" mode in the `jfs_truncate_nolock`
function to avoid errors related to writing to a read-only
filesystem.

Call stack:

block_write_begin() {
  jfs_write_failed() {
    jfs_truncate() {
      jfs_truncate_nolock() {
        txEnd() {
          ...
          log = JFS_SBI(tblk-&gt;sb)-&gt;log;
          // (log == NULL)

If the `isReadOnly(ip)` condition is triggered in
`jfs_truncate_nolock`, the function execution will stop, and no
further data modification will occur. Instead, the `xtTruncate`
function will be called with the "COMMIT_WMAP" flag, preventing
modifications in "read-only" mode.</Note>
    </Notes>
    <CVE>CVE-2024-58094</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

jfs: add check read-only before txBeginAnon() call

Added a read-only check before calling `txBeginAnon` in `extAlloc`
and `extRecord`. This prevents modification attempts on a read-only
mounted filesystem, avoiding potential errors or crashes.

Call trace:
 txBeginAnon+0xac/0x154
 extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78
 jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248
 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128
 __block_write_begin fs/buffer.c:2177 [inline]
 block_write_begin+0x98/0x11c fs/buffer.c:2236
 jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299</Note>
    </Notes>
    <CVE>CVE-2024-58095</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

wifi: ath11k: add srng-&gt;lock for ath11k_hal_srng_* in monitor mode

ath11k_hal_srng_* should be used with srng-&gt;lock to protect srng data.

For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(),
they use ath11k_hal_srng_* for many times but never call srng-&gt;lock.

So when running (full) monitor mode, warning will occur:
RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]
Call Trace:
 ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]
 ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k]
 ? idr_alloc_u32+0x97/0xd0
 ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k]
 ath11k_dp_service_srng+0x289/0x5a0 [ath11k]
 ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k]
 __napi_poll+0x30/0x1f0
 net_rx_action+0x198/0x320
 __do_softirq+0xdd/0x319

So add srng-&gt;lock for them to avoid such warnings.

Inorder to fetch the srng-&gt;lock, should change srng's definition from
'void' to 'struct hal_srng'. And initialize them elsewhere to prevent
one line of code from being too long. This is consistent with other ring
process functions, such as ath11k_dp_process_rx().

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1</Note>
    </Notes>
    <CVE>CVE-2024-58096</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

wifi: ath11k: fix RCU stall while reaping monitor destination ring

While processing the monitor destination ring, MSDUs are reaped from the
link descriptor based on the corresponding buf_id.

However, sometimes the driver cannot obtain a valid buffer corresponding
to the buf_id received from the hardware. This causes an infinite loop
in the destination processing, resulting in a kernel crash.

kernel log:
ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309
ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed
ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309
ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed

Fix this by skipping the problematic buf_id and reaping the next entry,
replacing the break with the next MSDU processing.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1</Note>
    </Notes>
    <CVE>CVE-2024-58097</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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 stack overflow vulnerability exists in the libexpat library due to the way it handles recursive entity expansion in XML documents. When parsing an XML document with deeply nested entity references, libexpat can be forced to recurse indefinitely, exhausting the stack space and causing a crash. This issue could lead to denial of service (DoS) or, in some cases, exploitable memory corruption, depending on the environment and library usage.</Note>
    </Notes>
    <CVE>CVE-2024-8176</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libexpat1-2.7.1-150400.3.28.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:

block, bfq: fix waker_bfqq UAF after bfq_split_bfqq()

Our syzkaller report a following UAF for v6.6:

BUG: KASAN: slab-use-after-free in bfq_init_rq+0x175d/0x17a0 block/bfq-iosched.c:6958
Read of size 8 at addr ffff8881b57147d8 by task fsstress/232726

CPU: 2 PID: 232726 Comm: fsstress Not tainted 6.6.0-g3629d1885222 #39
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106
 print_address_description.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
 hlist_add_head include/linux/list.h:1023 [inline]
 bfq_init_rq+0x175d/0x17a0 block/bfq-iosched.c:6958
 bfq_insert_request.isra.0+0xe8/0xa20 block/bfq-iosched.c:6271
 bfq_insert_requests+0x27f/0x390 block/bfq-iosched.c:6323
 blk_mq_insert_request+0x290/0x8f0 block/blk-mq.c:2660
 blk_mq_submit_bio+0x1021/0x15e0 block/blk-mq.c:3143
 __submit_bio+0xa0/0x6b0 block/blk-core.c:639
 __submit_bio_noacct_mq block/blk-core.c:718 [inline]
 submit_bio_noacct_nocheck+0x5b7/0x810 block/blk-core.c:747
 submit_bio_noacct+0xca0/0x1990 block/blk-core.c:847
 __ext4_read_bh fs/ext4/super.c:205 [inline]
 ext4_read_bh+0x15e/0x2e0 fs/ext4/super.c:230
 __read_extent_tree_block+0x304/0x6f0 fs/ext4/extents.c:567
 ext4_find_extent+0x479/0xd20 fs/ext4/extents.c:947
 ext4_ext_map_blocks+0x1a3/0x2680 fs/ext4/extents.c:4182
 ext4_map_blocks+0x929/0x15a0 fs/ext4/inode.c:660
 ext4_iomap_begin_report+0x298/0x480 fs/ext4/inode.c:3569
 iomap_iter+0x3dd/0x1010 fs/iomap/iter.c:91
 iomap_fiemap+0x1f4/0x360 fs/iomap/fiemap.c:80
 ext4_fiemap+0x181/0x210 fs/ext4/extents.c:5051
 ioctl_fiemap.isra.0+0x1b4/0x290 fs/ioctl.c:220
 do_vfs_ioctl+0x31c/0x11a0 fs/ioctl.c:811
 __do_sys_ioctl fs/ioctl.c:869 [inline]
 __se_sys_ioctl+0xae/0x190 fs/ioctl.c:857
 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

Allocated by task 232719:
 kasan_save_stack+0x22/0x50 mm/kasan/common.c:45
 kasan_set_track+0x25/0x30 mm/kasan/common.c:52
 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328
 kasan_slab_alloc include/linux/kasan.h:188 [inline]
 slab_post_alloc_hook mm/slab.h:768 [inline]
 slab_alloc_node mm/slub.c:3492 [inline]
 kmem_cache_alloc_node+0x1b8/0x6f0 mm/slub.c:3537
 bfq_get_queue+0x215/0x1f00 block/bfq-iosched.c:5869
 bfq_get_bfqq_handle_split+0x167/0x5f0 block/bfq-iosched.c:6776
 bfq_init_rq+0x13a4/0x17a0 block/bfq-iosched.c:6938
 bfq_insert_request.isra.0+0xe8/0xa20 block/bfq-iosched.c:6271
 bfq_insert_requests+0x27f/0x390 block/bfq-iosched.c:6323
 blk_mq_insert_request+0x290/0x8f0 block/blk-mq.c:2660
 blk_mq_submit_bio+0x1021/0x15e0 block/blk-mq.c:3143
 __submit_bio+0xa0/0x6b0 block/blk-core.c:639
 __submit_bio_noacct_mq block/blk-core.c:718 [inline]
 submit_bio_noacct_nocheck+0x5b7/0x810 block/blk-core.c:747
 submit_bio_noacct+0xca0/0x1990 block/blk-core.c:847
 __ext4_read_bh fs/ext4/super.c:205 [inline]
 ext4_read_bh_nowait+0x15a/0x240 fs/ext4/super.c:217
 ext4_read_bh_lock+0xac/0xd0 fs/ext4/super.c:242
 ext4_bread_batch+0x268/0x500 fs/ext4/inode.c:958
 __ext4_find_entry+0x448/0x10f0 fs/ext4/namei.c:1671
 ext4_lookup_entry fs/ext4/namei.c:1774 [inline]
 ext4_lookup.part.0+0x359/0x6f0 fs/ext4/namei.c:1842
 ext4_lookup+0x72/0x90 fs/ext4/namei.c:1839
 __lookup_slow+0x257/0x480 fs/namei.c:1696
 lookup_slow fs/namei.c:1713 [inline]
 walk_component+0x454/0x5c0 fs/namei.c:2004
 link_path_walk.part.0+0x773/0xda0 fs/namei.c:2331
 link_path_walk fs/namei.c:3826 [inline]
 path_openat+0x1b9/0x520 fs/namei.c:3826
 do_filp_open+0x1b7/0x400 fs/namei.c:3857
 do_sys_openat2+0x5dc/0x6e0 fs/open.c:1428
 do_sys_open fs/open.c:1443 [inline]
 __do_sys_openat fs/open.c:1459 [inline]
 __se_sys_openat fs/open.c:1454 [inline]
 __x64_sys_openat+0x148/0x200 fs/open.c:1454
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_6
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-21631</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

rds: sysctl: rds_tcp_{rcv,snd}buf: 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 per-netns structure can be obtained from the table-&gt;data using
container_of(), then the 'net' one can be retrieved from the listen
socket (if available).</Note>
    </Notes>
    <CVE>CVE-2025-21635</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

netdev: prevent accessing NAPI instances from another namespace

The NAPI IDs were not fully exposed to user space prior to the netlink
API, so they were never namespaced. The netlink API must ensure that
at the very least NAPI instance belongs to the same netns as the owner
of the genl sock.

napi_by_id() can become static now, but it needs to move because of
dev_get_by_napi_id().</Note>
    </Notes>
    <CVE>CVE-2025-21659</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

zram: fix potential UAF of zram table

If zram_meta_alloc failed early, it frees allocated zram-&gt;table without
setting it NULL.  Which will potentially cause zram_meta_free to access
the table if user reset an failed and uninitialized device.</Note>
    </Notes>
    <CVE>CVE-2025-21671</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

bpf: Fix bpf_sk_select_reuseport() memory leak

As pointed out in the original comment, lookup in sockmap can return a TCP
ESTABLISHED socket. Such TCP socket may have had SO_ATTACH_REUSEPORT_EBPF
set before it was ESTABLISHED. In other words, a non-NULL sk_reuseport_cb
does not imply a non-refcounted socket.

Drop sk's reference in both error paths.

unreferenced object 0xffff888101911800 (size 2048):
  comm "test_progs", pid 44109, jiffies 4297131437
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    80 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc 9336483b):
    __kmalloc_noprof+0x3bf/0x560
    __reuseport_alloc+0x1d/0x40
    reuseport_alloc+0xca/0x150
    reuseport_attach_prog+0x87/0x140
    sk_reuseport_attach_bpf+0xc8/0x100
    sk_setsockopt+0x1181/0x1990
    do_sock_setsockopt+0x12b/0x160
    __sys_setsockopt+0x7b/0xc0
    __x64_sys_setsockopt+0x1b/0x30
    do_syscall_64+0x93/0x180
    entry_SYSCALL_64_after_hwframe+0x76/0x7e</Note>
    </Notes>
    <CVE>CVE-2025-21683</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

mm: zswap: properly synchronize freeing resources during CPU hotunplug

In zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx of the
current CPU at the beginning of the operation is retrieved and used
throughout.  However, since neither preemption nor migration are disabled,
it is possible that the operation continues on a different CPU.

If the original CPU is hotunplugged while the acomp_ctx is still in use,
we run into a UAF bug as some of the resources attached to the acomp_ctx
are freed during hotunplug in zswap_cpu_comp_dead() (i.e. 
acomp_ctx.buffer, acomp_ctx.req, or acomp_ctx.acomp).

The problem was introduced in commit 1ec3b5fe6eec ("mm/zswap: move to use
crypto_acomp API for hardware acceleration") when the switch to the
crypto_acomp API was made.  Prior to that, the per-CPU crypto_comp was
retrieved using get_cpu_ptr() which disables preemption and makes sure the
CPU cannot go away from under us.  Preemption cannot be disabled with the
crypto_acomp API as a sleepable context is needed.

Use the acomp_ctx.mutex to synchronize CPU hotplug callbacks allocating
and freeing resources with compression/decompression paths.  Make sure
that acomp_ctx.req is NULL when the resources are freed.  In the
compression/decompression paths, check if acomp_ctx.req is NULL after
acquiring the mutex (meaning the CPU was offlined) and retry on the new
CPU.

The initialization of acomp_ctx.mutex is moved from the CPU hotplug
callback to the pool initialization where it belongs (where the mutex is
allocated).  In addition to adding clarity, this makes sure that CPU
hotplug cannot reinitialize a mutex that is already locked by
compression/decompression.

Previously a fix was attempted by holding cpus_read_lock() [1].  This
would have caused a potential deadlock as it is possible for code already
holding the lock to fall into reclaim and enter zswap (causing a
deadlock).  A fix was also attempted using SRCU for synchronization, but
Johannes pointed out that synchronize_srcu() cannot be used in CPU hotplug
notifiers [2].

Alternative fixes that were considered/attempted and could have worked:
- Refcounting the per-CPU acomp_ctx. This involves complexity in
  handling the race between the refcount dropping to zero in
  zswap_[de]compress() and the refcount being re-initialized when the
  CPU is onlined.
- Disabling migration before getting the per-CPU acomp_ctx [3], but
  that's discouraged and is a much bigger hammer than needed, and could
  result in subtle performance issues.

[1]https://lkml.kernel.org/20241219212437.2714151-1-yosryahmed@google.com/
[2]https://lkml.kernel.org/20250107074724.1756696-2-yosryahmed@google.com/
[3]https://lkml.kernel.org/20250107222236.2715883-2-yosryahmed@google.com/

[yosryahmed@google.com: remove comment]</Note>
    </Notes>
    <CVE>CVE-2025-21693</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

mm: clear uffd-wp PTE/PMD state on mremap()

When mremap()ing a memory region previously registered with userfaultfd as
write-protected but without UFFD_FEATURE_EVENT_REMAP, an inconsistency in
flag clearing leads to a mismatch between the vma flags (which have
uffd-wp cleared) and the pte/pmd flags (which do not have uffd-wp
cleared).  This mismatch causes a subsequent mprotect(PROT_WRITE) to
trigger a warning in page_table_check_pte_flags() due to setting the pte
to writable while uffd-wp is still set.

Fix this by always explicitly clearing the uffd-wp pte/pmd flags on any
such mremap() so that the values are consistent with the existing clearing
of VM_UFFD_WP.  Be careful to clear the logical flag regardless of its
physical form; a PTE bit, a swap PTE bit, or a PTE marker.  Cover PTE,
huge PMD and hugetlb paths.</Note>
    </Notes>
    <CVE>CVE-2025-21696</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net: avoid race between device unregistration and ethnl ops

The following trace can be seen if a device is being unregistered while
its number of channels are being modified.

  DEBUG_LOCKS_WARN_ON(lock-&gt;magic != lock)
  WARNING: CPU: 3 PID: 3754 at kernel/locking/mutex.c:564 __mutex_lock+0xc8a/0x1120
  CPU: 3 UID: 0 PID: 3754 Comm: ethtool Not tainted 6.13.0-rc6+ #771
  RIP: 0010:__mutex_lock+0xc8a/0x1120
  Call Trace:
   &lt;TASK&gt;
   ethtool_check_max_channel+0x1ea/0x880
   ethnl_set_channels+0x3c3/0xb10
   ethnl_default_set_doit+0x306/0x650
   genl_family_rcv_msg_doit+0x1e3/0x2c0
   genl_rcv_msg+0x432/0x6f0
   netlink_rcv_skb+0x13d/0x3b0
   genl_rcv+0x28/0x40
   netlink_unicast+0x42e/0x720
   netlink_sendmsg+0x765/0xc20
   __sys_sendto+0x3ac/0x420
   __x64_sys_sendto+0xe0/0x1c0
   do_syscall_64+0x95/0x180
   entry_SYSCALL_64_after_hwframe+0x76/0x7e

This is because unregister_netdevice_many_notify might run before the
rtnl lock section of ethnl operations, eg. set_channels in the above
example. In this example the rss lock would be destroyed by the device
unregistration path before being used again, but in general running
ethnl operations while dismantle has started is not a good idea.

Fix this by denying any operation on devices being unregistered. A check
was already there in ethnl_ops_begin, but not wide enough.

Note that the same issue cannot be seen on the ioctl version
(__dev_ethtool) because the device reference is retrieved from within
the rtnl lock section there. Once dismantle started, the net device is
unlisted and no reference will be found.</Note>
    </Notes>
    <CVE>CVE-2025-21701</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

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

qdisc_tree_reduce_backlog() notifies parent qdisc only if child
qdisc becomes empty, therefore we need to reduce the backlog of the
child qdisc before calling it. Otherwise it would miss the opportunity
to call cops-&gt;qlen_notify(), in the case of DRR, it resulted in UAF
since DRR uses -&gt;qlen_notify() to maintain its active list.</Note>
    </Notes>
    <CVE>CVE-2025-21703</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

usb: cdc-acm: Check control transfer buffer size before access

If the first fragment is shorter than struct usb_cdc_notification, we can't
calculate an expected_size. Log an error and discard the notification
instead of reading lengths from memory outside the received data, which can
lead to memory corruption when the expected_size decreases between
fragments, causing `expected_size - acm-&gt;nb_index` to wrap.

This issue has been present since the beginning of git history; however,
it only leads to memory corruption since commit ea2583529cd1
("cdc-acm: reassemble fragmented notifications").

A mitigating factor is that acm_ctrl_irq() can only execute after userspace
has opened /dev/ttyACM*; but if ModemManager is running, ModemManager will
do that automatically depending on the USB device's vendor/product IDs and
its other interfaces.</Note>
    </Notes>
    <CVE>CVE-2025-21704</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

mptcp: pm: only set fullmesh for subflow endp

With the in-kernel path-manager, it is possible to change the 'fullmesh'
flag. The code in mptcp_pm_nl_fullmesh() expects to change it only on
'subflow' endpoints, to recreate more or less subflows using the linked
address.

Unfortunately, the set_flags() hook was a bit more permissive, and
allowed 'implicit' endpoints to get the 'fullmesh' flag while it is not
allowed before.

That's what syzbot found, triggering the following warning:

  WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 __mark_subflow_endp_available net/mptcp/pm_netlink.c:1496 [inline]
  WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 mptcp_pm_nl_fullmesh net/mptcp/pm_netlink.c:1980 [inline]
  WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 mptcp_nl_set_flags net/mptcp/pm_netlink.c:2003 [inline]
  WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 mptcp_pm_nl_set_flags+0x974/0xdc0 net/mptcp/pm_netlink.c:2064
  Modules linked in:
  CPU: 0 UID: 0 PID: 6499 Comm: syz.1.413 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0
  Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
  RIP: 0010:__mark_subflow_endp_available net/mptcp/pm_netlink.c:1496 [inline]
  RIP: 0010:mptcp_pm_nl_fullmesh net/mptcp/pm_netlink.c:1980 [inline]
  RIP: 0010:mptcp_nl_set_flags net/mptcp/pm_netlink.c:2003 [inline]
  RIP: 0010:mptcp_pm_nl_set_flags+0x974/0xdc0 net/mptcp/pm_netlink.c:2064
  Code: 01 00 00 49 89 c5 e8 fb 45 e8 f5 e9 b8 fc ff ff e8 f1 45 e8 f5 4c 89 f7 be 03 00 00 00 e8 44 1d 0b f9 eb a0 e8 dd 45 e8 f5 90 &lt;0f&gt; 0b 90 e9 17 ff ff ff 89 d9 80 e1 07 38 c1 0f 8c c9 fc ff ff 48
  RSP: 0018:ffffc9000d307240 EFLAGS: 00010293
  RAX: ffffffff8bb72e03 RBX: 0000000000000000 RCX: ffff88807da88000
  RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
  RBP: ffffc9000d307430 R08: ffffffff8bb72cf0 R09: 1ffff1100b842a5e
  R10: dffffc0000000000 R11: ffffed100b842a5f R12: ffff88801e2e5ac0
  R13: ffff88805c214800 R14: ffff88805c2152e8 R15: 1ffff1100b842a5d
  FS:  00005555619f6500(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000020002840 CR3: 00000000247e6000 CR4: 00000000003526f0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  Call Trace:
   &lt;TASK&gt;
   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:2542
   genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219
   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:0x7f5fe8785d29
  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:00007fff571f5558 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
  RAX: ffffffffffffffda RBX: 00007f5fe8975fa0 RCX: 00007f5fe8785d29
  RDX: 0000000000000000 RSI: 0000000020000480 RDI: 0000000000000007
  RBP: 00007f5fe8801b08 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
  R13: 00007f5fe8975fa0 R14: 00007f5fe8975fa0 R15: 000000
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-21706</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

mptcp: consolidate suboption status

MPTCP maintains the received sub-options status is the bitmask carrying
the received suboptions and in several bitfields carrying per suboption
additional info.

Zeroing the bitmask before parsing is not enough to ensure a consistent
status, and the MPTCP code has to additionally clear some bitfiled
depending on the actually parsed suboption.

The above schema is fragile, and syzbot managed to trigger a path where
a relevant bitfield is not cleared/initialized:

  BUG: KMSAN: uninit-value in __mptcp_expand_seq net/mptcp/options.c:1030 [inline]
  BUG: KMSAN: uninit-value in mptcp_expand_seq net/mptcp/protocol.h:864 [inline]
  BUG: KMSAN: uninit-value in ack_update_msk net/mptcp/options.c:1060 [inline]
  BUG: KMSAN: uninit-value in mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209
   __mptcp_expand_seq net/mptcp/options.c:1030 [inline]
   mptcp_expand_seq net/mptcp/protocol.h:864 [inline]
   ack_update_msk net/mptcp/options.c:1060 [inline]
   mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209
   tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233
   tcp_rcv_established+0x1061/0x2510 net/ipv4/tcp_input.c:6264
   tcp_v4_do_rcv+0x7f3/0x11a0 net/ipv4/tcp_ipv4.c:1916
   tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351
   ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205
   ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233
   NF_HOOK include/linux/netfilter.h:314 [inline]
   ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254
   dst_input include/net/dst.h:460 [inline]
   ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447
   NF_HOOK include/linux/netfilter.h:314 [inline]
   ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567
   __netif_receive_skb_one_core net/core/dev.c:5704 [inline]
   __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817
   process_backlog+0x4ad/0xa50 net/core/dev.c:6149
   __napi_poll+0xe7/0x980 net/core/dev.c:6902
   napi_poll net/core/dev.c:6971 [inline]
   net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093
   handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561
   __do_softirq+0x14/0x1a kernel/softirq.c:595
   do_softirq+0x9a/0x100 kernel/softirq.c:462
   __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389
   local_bh_enable include/linux/bottom_half.h:33 [inline]
   rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]
   __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4493
   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+0x187c/0x1b70 net/ipv4/ip_output.c:236
   __ip_finish_output+0x287/0x810
   ip_finish_output+0x4b/0x600 net/ipv4/ip_output.c:324
   NF_HOOK_COND include/linux/netfilter.h:303 [inline]
   ip_output+0x15f/0x3f0 net/ipv4/ip_output.c:434
   dst_output include/net/dst.h:450 [inline]
   ip_local_out net/ipv4/ip_output.c:130 [inline]
   __ip_queue_xmit+0x1f2a/0x20d0 net/ipv4/ip_output.c:536
   ip_queue_xmit+0x60/0x80 net/ipv4/ip_output.c:550
   __tcp_transmit_skb+0x3cea/0x4900 net/ipv4/tcp_output.c:1468
   tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline]
   tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829
   __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012
   tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618
   __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130
   __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496
   mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550
   mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889
   mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline]
   mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline]
   mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline]
   mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750
   genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]
 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-21707</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net: usb: rtl8150: enable basic endpoint checking

Syzkaller reports [1] encountering a common issue of utilizing a wrong
usb endpoint type during URB submitting stage. This, in turn, triggers
a warning shown below.

For now, enable simple endpoint checking (specifically, bulk and
interrupt eps, testing control one is not essential) to mitigate
the issue with a view to do other related cosmetic changes later,
if they are necessary.

[1] Syzkaller report:
usb 1-1: BOGUS urb xfer, pipe 3 != type 1
WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv&gt;
Modules linked in:
CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617&gt;
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503
Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8&gt;
RSP: 0018:ffffc9000441f740 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9
RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001
RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001
R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c
FS:  00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733
 __dev_open+0x2d4/0x4e0 net/core/dev.c:1474
 __dev_change_flags+0x561/0x720 net/core/dev.c:8838
 dev_change_flags+0x8f/0x160 net/core/dev.c:8910
 devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177
 inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003
 sock_do_ioctl+0x116/0x280 net/socket.c:1222
 sock_ioctl+0x22e/0x6c0 net/socket.c:1341
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:907 [inline]
 __se_sys_ioctl fs/ioctl.c:893 [inline]
 __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893
 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:0x7fc04ef73d49
...

This change has not been tested on real hardware.</Note>
    </Notes>
    <CVE>CVE-2025-21708</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net/rose: prevent integer overflows in rose_setsockopt()

In case of possible unpredictably large arguments passed to
rose_setsockopt() and multiplied by extra values on top of that,
integer overflows may occur.

Do the safest minimum and fix these issues by checking the
contents of 'opt' and returning -EINVAL if they are too large. Also,
switch to unsigned int and remove useless check for negative 'opt'
in ROSE_IDLE case.</Note>
    </Notes>
    <CVE>CVE-2025-21711</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

RDMA/mlx5: Fix implicit ODP use after free

Prevent double queueing of implicit ODP mr destroy work by using
__xa_cmpxchg() to make sure this is the only time we are destroying this
specific mr.

Without this change, we could try to invalidate this mr twice, which in
turn could result in queuing a MR work destroy twice, and eventually the
second work could execute after the MR was freed due to the first work,
causing a user after free and trace below.

   refcount_t: underflow; use-after-free.
   WARNING: CPU: 2 PID: 12178 at lib/refcount.c:28 refcount_warn_saturate+0x12b/0x130
   Modules linked in: bonding ib_ipoib vfio_pci ip_gre geneve nf_tables ip6_gre gre ip6_tunnel tunnel6 ipip tunnel4 ib_umad rdma_ucm mlx5_vfio_pci vfio_pci_core vfio_iommu_type1 mlx5_ib vfio ib_uverbs mlx5_core iptable_raw openvswitch nsh rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay zram zsmalloc fuse [last unloaded: ib_uverbs]
   CPU: 2 PID: 12178 Comm: kworker/u20:5 Not tainted 6.5.0-rc1_net_next_mlx5_58c644e #1
   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
   Workqueue: events_unbound free_implicit_child_mr_work [mlx5_ib]
   RIP: 0010:refcount_warn_saturate+0x12b/0x130
   Code: 48 c7 c7 38 95 2a 82 c6 05 bc c6 fe 00 01 e8 0c 66 aa ff 0f 0b 5b c3 48 c7 c7 e0 94 2a 82 c6 05 a7 c6 fe 00 01 e8 f5 65 aa ff &lt;0f&gt; 0b 5b c3 90 8b 07 3d 00 00 00 c0 74 12 83 f8 01 74 13 8d 50 ff
   RSP: 0018:ffff8881008e3e40 EFLAGS: 00010286
   RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000027
   RDX: ffff88852c91b5c8 RSI: 0000000000000001 RDI: ffff88852c91b5c0
   RBP: ffff8881dacd4e00 R08: 00000000ffffffff R09: 0000000000000019
   R10: 000000000000072e R11: 0000000063666572 R12: ffff88812bfd9e00
   R13: ffff8881c792d200 R14: ffff88810011c005 R15: ffff8881002099c0
   FS:  0000000000000000(0000) GS:ffff88852c900000(0000) knlGS:0000000000000000
   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
   CR2: 00007f5694b5e000 CR3: 00000001153f6003 CR4: 0000000000370ea0
   DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
   DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
   Call Trace:
    &lt;TASK&gt;
    ? refcount_warn_saturate+0x12b/0x130
    free_implicit_child_mr_work+0x180/0x1b0 [mlx5_ib]
    process_one_work+0x1cc/0x3c0
    worker_thread+0x218/0x3c0
    kthread+0xc6/0xf0
    ret_from_fork+0x1f/0x30
    &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2025-21714</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net: rose: fix timer races against user threads

Rose timers only acquire the socket spinlock, without
checking if the socket is owned by one user thread.

Add a check and rearm the timers if needed.

BUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174
Read of size 2 at addr ffff88802f09b82a by task swapper/0/0

CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Call Trace:
 &lt;IRQ&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
  rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174
  call_timer_fn+0x187/0x650 kernel/time/timer.c:1793
  expire_timers kernel/time/timer.c:1844 [inline]
  __run_timers kernel/time/timer.c:2418 [inline]
  __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430
  run_timer_base kernel/time/timer.c:2439 [inline]
  run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449
  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+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049
 &lt;/IRQ&gt;</Note>
    </Notes>
    <CVE>CVE-2025-21718</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

scsi: mpi3mr: Fix possible crash when setting up bsg fails

If bsg_setup_queue() fails, the bsg_queue is assigned a non-NULL value.
Consequently, in mpi3mr_bsg_exit(), the condition "if(!mrioc-&gt;bsg_queue)"
will not be satisfied, preventing execution from entering
bsg_remove_queue(), which could lead to the following crash:

BUG: kernel NULL pointer dereference, address: 000000000000041c
Call Trace:
  &lt;TASK&gt;
  mpi3mr_bsg_exit+0x1f/0x50 [mpi3mr]
  mpi3mr_remove+0x6f/0x340 [mpi3mr]
  pci_device_remove+0x3f/0xb0
  device_release_driver_internal+0x19d/0x220
  unbind_store+0xa4/0xb0
  kernfs_fop_write_iter+0x11f/0x200
  vfs_write+0x1fc/0x3e0
  ksys_write+0x67/0xe0
  do_syscall_64+0x38/0x80
  entry_SYSCALL_64_after_hwframe+0x78/0xe2</Note>
    </Notes>
    <CVE>CVE-2025-21723</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

padata: avoid UAF for reorder_work

Although the previous patch can avoid ps and ps UAF for _do_serial, it
can not avoid potential UAF issue for reorder_work. This issue can
happen just as below:

crypto_request			crypto_request		crypto_del_alg
padata_do_serial
  ...
  padata_reorder
    // processes all remaining
    // requests then breaks
    while (1) {
      if (!padata)
        break;
      ...
    }

				padata_do_serial
				  // new request added
				  list_add
    // sees the new request
    queue_work(reorder_work)
				  padata_reorder
				    queue_work_on(squeue-&gt;work)
...

				&lt;kworker context&gt;
				padata_serial_worker
				// completes new request,
				// no more outstanding
				// requests

							crypto_del_alg
							  // free pd

&lt;kworker context&gt;
invoke_padata_reorder
  // UAF of pd

To avoid UAF for 'reorder_work', get 'pd' ref before put 'reorder_work'
into the 'serial_wq' and put 'pd' ref until the 'serial_wq' finish.</Note>
    </Notes>
    <CVE>CVE-2025-21726</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

padata: fix UAF in padata_reorder

A bug was found when run ltp test:

BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0
Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206

CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+
Workqueue: pdecrypt_parallel padata_parallel_worker
Call Trace:
&lt;TASK&gt;
dump_stack_lvl+0x32/0x50
print_address_description.constprop.0+0x6b/0x3d0
print_report+0xdd/0x2c0
kasan_report+0xa5/0xd0
padata_find_next+0x29/0x1a0
padata_reorder+0x131/0x220
padata_parallel_worker+0x3d/0xc0
process_one_work+0x2ec/0x5a0

If 'mdelay(10)' is added before calling 'padata_find_next' in the
'padata_reorder' function, this issue could be reproduced easily with
ltp test (pcrypt_aead01).

This can be explained as bellow:

pcrypt_aead_encrypt
...
padata_do_parallel
refcount_inc(&amp;pd-&gt;refcnt); // add refcnt
...
padata_do_serial
padata_reorder // pd
while (1) {
padata_find_next(pd, true); // using pd
queue_work_on
...
padata_serial_worker				crypto_del_alg
padata_put_pd_cnt // sub refcnt
						padata_free_shell
						padata_put_pd(ps-&gt;pd);
						// pd is freed
// loop again, but pd is freed
// call padata_find_next, UAF
}

In the padata_reorder function, when it loops in 'while', if the alg is
deleted, the refcnt may be decreased to 0 before entering
'padata_find_next', which leads to UAF.

As mentioned in [1], do_serial is supposed to be called with BHs disabled
and always happen under RCU protection, to address this issue, add
synchronize_rcu() in 'padata_free_shell' wait for all _do_serial calls
to finish.

[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/
[2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/</Note>
    </Notes>
    <CVE>CVE-2025-21727</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

wifi: rtw89: fix race between cancel_hw_scan and hw_scan completion

The rtwdev-&gt;scanning flag isn't protected by mutex originally, so
cancel_hw_scan can pass the condition, but suddenly hw_scan completion
unset the flag and calls ieee80211_scan_completed() that will free
local-&gt;hw_scan_req. Then, cancel_hw_scan raises null-ptr-deref and
use-after-free. Fix it by moving the check condition to where
protected by mutex.

 KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f]
 CPU: 2 PID: 6922 Comm: kworker/2:2 Tainted: G           OE
 Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB6WW (2.76 ) 09/10/2019
 Workqueue: events cfg80211_conn_work [cfg80211]
 RIP: 0010:rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core]
 Code: 00 45 89 6c 24 1c 0f 85 23 01 00 00 48 8b 85 20 ff ff ff 48 8d
 RSP: 0018:ffff88811fd9f068 EFLAGS: 00010206
 RAX: dffffc0000000000 RBX: ffff88811fd9f258 RCX: 0000000000000001
 RDX: 0000000000000011 RSI: 0000000000000001 RDI: 0000000000000089
 RBP: ffff88811fd9f170 R08: 0000000000000000 R09: 0000000000000000
 R10: ffff88811fd9f108 R11: 0000000000000000 R12: ffff88810e47f960
 R13: 0000000000000000 R14: 000000000000ffff R15: 0000000000000000
 FS:  0000000000000000(0000) GS:ffff8881d6f00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 00007531dfca55b0 CR3: 00000001be296004 CR4: 00000000001706e0
 Call Trace:
  &lt;TASK&gt;
  ? show_regs+0x61/0x73
  ? __die_body+0x20/0x73
  ? die_addr+0x4f/0x7b
  ? exc_general_protection+0x191/0x1db
  ? asm_exc_general_protection+0x27/0x30
  ? rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core]
  ? rtw89_fw_h2c_scan_offload_be+0x458/0x13c3 [rtw89_core]
  ? __pfx_rtw89_fw_h2c_scan_offload_be+0x10/0x10 [rtw89_core]
  ? do_raw_spin_lock+0x75/0xdb
  ? __pfx_do_raw_spin_lock+0x10/0x10
  rtw89_hw_scan_offload+0xb5e/0xbf7 [rtw89_core]
  ? _raw_spin_unlock+0xe/0x24
  ? __mutex_lock.constprop.0+0x40c/0x471
  ? __pfx_rtw89_hw_scan_offload+0x10/0x10 [rtw89_core]
  ? __mutex_lock_slowpath+0x13/0x1f
  ? mutex_lock+0xa2/0xdc
  ? __pfx_mutex_lock+0x10/0x10
  rtw89_hw_scan_abort+0x58/0xb7 [rtw89_core]
  rtw89_ops_cancel_hw_scan+0x120/0x13b [rtw89_core]
  ieee80211_scan_cancel+0x468/0x4d0 [mac80211]
  ieee80211_prep_connection+0x858/0x899 [mac80211]
  ieee80211_mgd_auth+0xbea/0xdde [mac80211]
  ? __pfx_ieee80211_mgd_auth+0x10/0x10 [mac80211]
  ? cfg80211_find_elem+0x15/0x29 [cfg80211]
  ? is_bss+0x1b7/0x1d7 [cfg80211]
  ieee80211_auth+0x18/0x27 [mac80211]
  cfg80211_mlme_auth+0x3bb/0x3e7 [cfg80211]
  cfg80211_conn_do_work+0x410/0xb81 [cfg80211]
  ? __pfx_cfg80211_conn_do_work+0x10/0x10 [cfg80211]
  ? __kasan_check_read+0x11/0x1f
  ? psi_group_change+0x8bc/0x944
  ? __kasan_check_write+0x14/0x22
  ? mutex_lock+0x8e/0xdc
  ? __pfx_mutex_lock+0x10/0x10
  ? __pfx___radix_tree_lookup+0x10/0x10
  cfg80211_conn_work+0x245/0x34d [cfg80211]
  ? __pfx_cfg80211_conn_work+0x10/0x10 [cfg80211]
  ? update_cfs_rq_load_avg+0x3bc/0x3d7
  ? sched_clock_noinstr+0x9/0x1a
  ? sched_clock+0x10/0x24
  ? sched_clock_cpu+0x7e/0x42e
  ? newidle_balance+0x796/0x937
  ? __pfx_sched_clock_cpu+0x10/0x10
  ? __pfx_newidle_balance+0x10/0x10
  ? __kasan_check_read+0x11/0x1f
  ? psi_group_change+0x8bc/0x944
  ? _raw_spin_unlock+0xe/0x24
  ? raw_spin_rq_unlock+0x47/0x54
  ? raw_spin_rq_unlock_irq+0x9/0x1f
  ? finish_task_switch.isra.0+0x347/0x586
  ? __schedule+0x27bf/0x2892
  ? mutex_unlock+0x80/0xd0
  ? do_raw_spin_lock+0x75/0xdb
  ? __pfx___schedule+0x10/0x10
  process_scheduled_works+0x58c/0x821
  worker_thread+0x4c7/0x586
  ? __kasan_check_read+0x11/0x1f
  kthread+0x285/0x294
  ? __pfx_worker_thread+0x10/0x10
  ? __pfx_kthread+0x10/0x10
  ret_from_fork+0x29/0x6f
  ? __pfx_kthread+0x10/0x10
  ret_from_fork_asm+0x1b/0x30
  &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2025-21729</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

nbd: don't allow reconnect after disconnect

Following process can cause nbd_config UAF:

1) grab nbd_config temporarily;

2) nbd_genl_disconnect() flush all recv_work() and release the
initial reference:

  nbd_genl_disconnect
   nbd_disconnect_and_put
    nbd_disconnect
     flush_workqueue(nbd-&gt;recv_workq)
    if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...))
     nbd_config_put
     -&gt; due to step 1), reference is still not zero

3) nbd_genl_reconfigure() queue recv_work() again;

  nbd_genl_reconfigure
   config = nbd_get_config_unlocked(nbd)
   if (!config)
   -&gt; succeed
   if (!test_bit(NBD_RT_BOUND, ...))
   -&gt; succeed
   nbd_reconnect_socket
    queue_work(nbd-&gt;recv_workq, &amp;args-&gt;work)

4) step 1) release the reference;

5) Finially, recv_work() will trigger UAF:

  recv_work
   nbd_config_put(nbd)
   -&gt; nbd_config is freed
   atomic_dec(&amp;config-&gt;recv_threads)
   -&gt; UAF

Fix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), so
that nbd_genl_reconfigure() will fail.</Note>
    </Notes>
    <CVE>CVE-2025-21731</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

RDMA/mlx5: Fix a race for an ODP MR which leads to CQE with error

This patch addresses a race condition for an ODP MR that can result in a
CQE with an error on the UMR QP.

During the __mlx5_ib_dereg_mr() flow, the following sequence of calls
occurs:

mlx5_revoke_mr()
 mlx5r_umr_revoke_mr()
 mlx5r_umr_post_send_wait()

At this point, the lkey is freed from the hardware's perspective.

However, concurrently, mlx5_ib_invalidate_range() might be triggered by
another task attempting to invalidate a range for the same freed lkey.

This task will:
 - Acquire the umem_odp-&gt;umem_mutex lock.
 - Call mlx5r_umr_update_xlt() on the UMR QP.
 - Since the lkey has already been freed, this can lead to a CQE error,
   causing the UMR QP to enter an error state [1].

To resolve this race condition, the umem_odp-&gt;umem_mutex lock is now also
acquired as part of the mlx5_revoke_mr() scope.  Upon successful revoke,
we set umem_odp-&gt;private which points to that MR to NULL, preventing any
further invalidation attempts on its lkey.

[1] From dmesg:

   infiniband rocep8s0f0: dump_cqe:277:(pid 0): WC error: 6, Message: memory bind operation error
   cqe_dump: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   cqe_dump: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   cqe_dump: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   cqe_dump: 00000030: 00 00 00 00 08 00 78 06 25 00 11 b9 00 0e dd d2

   WARNING: CPU: 15 PID: 1506 at drivers/infiniband/hw/mlx5/umr.c:394 mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib]
   Modules linked in: ip6table_mangle ip6table_natip6table_filter ip6_tables iptable_mangle xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm mlx5_ib ib_uverbs ib_core fuse mlx5_core
   CPU: 15 UID: 0 PID: 1506 Comm: ibv_rc_pingpong Not tainted 6.12.0-rc7+ #1626
   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
   RIP: 0010:mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib]
   [..]
   Call Trace:
   &lt;TASK&gt;
   mlx5r_umr_update_xlt+0x23c/0x3e0 [mlx5_ib]
   mlx5_ib_invalidate_range+0x2e1/0x330 [mlx5_ib]
   __mmu_notifier_invalidate_range_start+0x1e1/0x240
   zap_page_range_single+0xf1/0x1a0
   madvise_vma_behavior+0x677/0x6e0
   do_madvise+0x1a2/0x4b0
   __x64_sys_madvise+0x25/0x30
   do_syscall_64+0x6b/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e</Note>
    </Notes>
    <CVE>CVE-2025-21732</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

tracing/osnoise: Fix resetting of tracepoints

If a timerlat tracer is started with the osnoise option OSNOISE_WORKLOAD
disabled, but then that option is enabled and timerlat is removed, the
tracepoints that were enabled on timerlat registration do not get
disabled. If the option is disabled again and timelat is started, then it
triggers a warning in the tracepoint code due to registering the
tracepoint again without ever disabling it.

Do not use the same user space defined options to know to disable the
tracepoints when timerlat is removed. Instead, set a global flag when it
is enabled and use that flag to know to disable the events.

 ~# echo NO_OSNOISE_WORKLOAD &gt; /sys/kernel/tracing/osnoise/options
 ~# echo timerlat &gt; /sys/kernel/tracing/current_tracer
 ~# echo OSNOISE_WORKLOAD &gt; /sys/kernel/tracing/osnoise/options
 ~# echo nop &gt; /sys/kernel/tracing/current_tracer
 ~# echo NO_OSNOISE_WORKLOAD &gt; /sys/kernel/tracing/osnoise/options
 ~# echo timerlat &gt; /sys/kernel/tracing/current_tracer

Triggers:

 ------------[ cut here ]------------
 WARNING: CPU: 6 PID: 1337 at kernel/tracepoint.c:294 tracepoint_add_func+0x3b6/0x3f0
 Modules linked in:
 CPU: 6 UID: 0 PID: 1337 Comm: rtla Not tainted 6.13.0-rc4-test-00018-ga867c441128e-dirty #73
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
 RIP: 0010:tracepoint_add_func+0x3b6/0x3f0
 Code: 48 8b 53 28 48 8b 73 20 4c 89 04 24 e8 23 59 11 00 4c 8b 04 24 e9 36 fe ff ff 0f 0b b8 ea ff ff ff 45 84 e4 0f 84 68 fe ff ff &lt;0f&gt; 0b e9 61 fe ff ff 48 8b 7b 18 48 85 ff 0f 84 4f ff ff ff 49 8b
 RSP: 0018:ffffb9b003a87ca0 EFLAGS: 00010202
 RAX: 00000000ffffffef RBX: ffffffff92f30860 RCX: 0000000000000000
 RDX: 0000000000000000 RSI: ffff9bf59e91ccd0 RDI: ffffffff913b6410
 RBP: 000000000000000a R08: 00000000000005c7 R09: 0000000000000002
 R10: ffffb9b003a87ce0 R11: 0000000000000002 R12: 0000000000000001
 R13: ffffb9b003a87ce0 R14: ffffffffffffffef R15: 0000000000000008
 FS:  00007fce81209240(0000) GS:ffff9bf6fdd00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 000055e99b728000 CR3: 00000001277c0002 CR4: 0000000000172ef0
 Call Trace:
  &lt;TASK&gt;
  ? __warn.cold+0xb7/0x14d
  ? tracepoint_add_func+0x3b6/0x3f0
  ? report_bug+0xea/0x170
  ? handle_bug+0x58/0x90
  ? exc_invalid_op+0x17/0x70
  ? asm_exc_invalid_op+0x1a/0x20
  ? __pfx_trace_sched_migrate_callback+0x10/0x10
  ? tracepoint_add_func+0x3b6/0x3f0
  ? __pfx_trace_sched_migrate_callback+0x10/0x10
  ? __pfx_trace_sched_migrate_callback+0x10/0x10
  tracepoint_probe_register+0x78/0xb0
  ? __pfx_trace_sched_migrate_callback+0x10/0x10
  osnoise_workload_start+0x2b5/0x370
  timerlat_tracer_init+0x76/0x1b0
  tracing_set_tracer+0x244/0x400
  tracing_set_trace_write+0xa0/0xe0
  vfs_write+0xfc/0x570
  ? do_sys_openat2+0x9c/0xe0
  ksys_write+0x72/0xf0
  do_syscall_64+0x79/0x1c0
  entry_SYSCALL_64_after_hwframe+0x76/0x7e</Note>
    </Notes>
    <CVE>CVE-2025-21733</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

misc: fastrpc: Fix copy buffer page size

For non-registered buffer, fastrpc driver copies the buffer and
pass it to the remote subsystem. There is a problem with current
implementation of page size calculation which is not considering
the offset in the calculation. This might lead to passing of
improper and out-of-bounds page size which could result in
memory issue. Calculate page start and page end using the offset
adjusted address instead of absolute address.</Note>
    </Notes>
    <CVE>CVE-2025-21734</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

NFC: nci: Add bounds checking in nci_hci_create_pipe()

The "pipe" variable is a u8 which comes from the network.  If it's more
than 127, then it results in memory corruption in the caller,
nci_hci_connect_gate().</Note>
    </Notes>
    <CVE>CVE-2025-21735</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

nilfs2: fix possible int overflows in nilfs_fiemap()

Since nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its result
by being prepared to go through potentially maxblocks == INT_MAX blocks,
the value in n may experience an overflow caused by left shift of blkbits.

While it is extremely unlikely to occur, play it safe and cast right hand
expression to wider type to mitigate the issue.

Found by Linux Verification Center (linuxtesting.org) with static analysis
tool SVACE.</Note>
    </Notes>
    <CVE>CVE-2025-21736</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ata: libata-sff: Ensure that we cannot write outside the allocated buffer

reveliofuzzing reported that a SCSI_IOCTL_SEND_COMMAND ioctl with out_len
set to 0xd42, SCSI command set to ATA_16 PASS-THROUGH, ATA command set to
ATA_NOP, and protocol set to ATA_PROT_PIO, can cause ata_pio_sector() to
write outside the allocated buffer, overwriting random memory.

While a ATA device is supposed to abort a ATA_NOP command, there does seem
to be a bug either in libata-sff or QEMU, where either this status is not
set, or the status is cleared before read by ata_sff_hsm_move().
Anyway, that is most likely a separate bug.

Looking at __atapi_pio_bytes(), it already has a safety check to ensure
that __atapi_pio_bytes() cannot write outside the allocated buffer.

Add a similar check to ata_pio_sector(), such that also ata_pio_sector()
cannot write outside the allocated buffer.</Note>
    </Notes>
    <CVE>CVE-2025-21738</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

scsi: ufs: core: Fix use-after free in init error and remove paths

devm_blk_crypto_profile_init() registers a cleanup handler to run when
the associated (platform-) device is being released. For UFS, the
crypto private data and pointers are stored as part of the ufs_hba's
data structure 'struct ufs_hba::crypto_profile'. This structure is
allocated as part of the underlying ufshcd and therefore Scsi_host
allocation.

During driver release or during error handling in ufshcd_pltfrm_init(),
this structure is released as part of ufshcd_dealloc_host() before the
(platform-) device associated with the crypto call above is released.
Once this device is released, the crypto cleanup code will run, using
the just-released 'struct ufs_hba::crypto_profile'. This causes a
use-after-free situation:

  Call trace:
   kfree+0x60/0x2d8 (P)
   kvfree+0x44/0x60
   blk_crypto_profile_destroy_callback+0x28/0x70
   devm_action_release+0x1c/0x30
   release_nodes+0x6c/0x108
   devres_release_all+0x98/0x100
   device_unbind_cleanup+0x20/0x70
   really_probe+0x218/0x2d0

In other words, the initialisation code flow is:

  platform-device probe
    ufshcd_pltfrm_init()
      ufshcd_alloc_host()
        scsi_host_alloc()
          allocation of struct ufs_hba
          creation of scsi-host devices
    devm_blk_crypto_profile_init()
      devm registration of cleanup handler using platform-device

and during error handling of ufshcd_pltfrm_init() or during driver
removal:

  ufshcd_dealloc_host()
    scsi_host_put()
      put_device(scsi-host)
        release of struct ufs_hba
  put_device(platform-device)
    crypto cleanup handler

To fix this use-after free, change ufshcd_alloc_host() to register a
devres action to automatically cleanup the underlying SCSI device on
ufshcd destruction, without requiring explicit calls to
ufshcd_dealloc_host(). This way:

    * the crypto profile and all other ufs_hba-owned resources are
      destroyed before SCSI (as they've been registered after)
    * a memleak is plugged in tc-dwc-g210-pci.c remove() as a
      side-effect
    * EXPORT_SYMBOL_GPL(ufshcd_dealloc_host) can be removed fully as
      it's not needed anymore
    * no future drivers using ufshcd_alloc_host() could ever forget
      adding the cleanup</Note>
    </Notes>
    <CVE>CVE-2025-21739</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

usbnet: ipheth: fix DPE OoB read

Fix an out-of-bounds DPE read, limit the number of processed DPEs to
the amount that fits into the fixed-size NDP16 header.</Note>
    </Notes>
    <CVE>CVE-2025-21741</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

usbnet: ipheth: use static NDP16 location in URB

Original code allowed for the start of NDP16 to be anywhere within the
URB based on the `wNdpIndex` value in NTH16. Only the start position of
NDP16 was checked, so it was possible for even the fixed-length part
of NDP16 to extend past the end of URB, leading to an out-of-bounds
read.

On iOS devices, the NDP16 header always directly follows NTH16. Rely on
and check for this specific format.

This, along with NCM-specific minimal URB length check that already
exists, will ensure that the fixed-length part of NDP16 plus a set
amount of DPEs fit within the URB.

Note that this commit alone does not fully address the OoB read.
The limit on the amount of DPEs needs to be enforced separately.</Note>
    </Notes>
    <CVE>CVE-2025-21742</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

usbnet: ipheth: fix possible overflow in DPE length check

Originally, it was possible for the DPE length check to overflow if
wDatagramIndex + wDatagramLength &gt; U16_MAX. This could lead to an OoB
read.

Move the wDatagramIndex term to the other side of the inequality.

An existing condition ensures that wDatagramIndex &lt; urb-&gt;actual_length.</Note>
    </Notes>
    <CVE>CVE-2025-21743</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()

On removal of the device or unloading of the kernel module a potential NULL
pointer dereference occurs.

The following sequence deletes the interface:

  brcmf_detach()
    brcmf_remove_interface()
      brcmf_del_if()

Inside the brcmf_del_if() function the drvr-&gt;if2bss[ifidx] is updated to
BRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches.

After brcmf_remove_interface() call the brcmf_proto_detach() function is
called providing the following sequence:

  brcmf_detach()
    brcmf_proto_detach()
      brcmf_proto_msgbuf_detach()
        brcmf_flowring_detach()
          brcmf_msgbuf_delete_flowring()
            brcmf_msgbuf_remove_flowring()
              brcmf_flowring_delete()
                brcmf_get_ifp()
                brcmf_txfinalize()

Since brcmf_get_ip() can and actually will return NULL in this case the
call to brcmf_txfinalize() will result in a NULL pointer dereference inside
brcmf_txfinalize() when trying to update ifp-&gt;ndev-&gt;stats.tx_errors.

This will only happen if a flowring still has an skb.

Although the NULL pointer dereference has only been seen when trying to
update the tx statistic, all other uses of the ifp pointer have been
guarded as well with an early return if ifp is NULL.</Note>
    </Notes>
    <CVE>CVE-2025-21744</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

blk-cgroup: Fix class @block_class's subsystem refcount leakage

blkcg_fill_root_iostats() iterates over @block_class's devices by
class_dev_iter_(init|next)(), but does not end iterating with
class_dev_iter_exit(), so causes the class's subsystem refcount leakage.

Fix by ending the iterating with class_dev_iter_exit().</Note>
    </Notes>
    <CVE>CVE-2025-21745</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net: rose: lock the socket in rose_bind()

syzbot reported a soft lockup in rose_loopback_timer(),
with a repro calling bind() from multiple threads.

rose_bind() must lock the socket to avoid this issue.</Note>
    </Notes>
    <CVE>CVE-2025-21749</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

wifi: brcmfmac: Check the return value of of_property_read_string_index()

Somewhen between 6.10 and 6.11 the driver started to crash on my
MacBookPro14,3. The property doesn't exist and 'tmp' remains
uninitialized, so we pass a random pointer to devm_kstrdup().

The crash I am getting looks like this:

BUG: unable to handle page fault for address: 00007f033c669379
PF: supervisor read access in kernel mode
PF: error_code(0x0001) - permissions violation
PGD 8000000101341067 P4D 8000000101341067 PUD 101340067 PMD 1013bb067 PTE 800000010aee9025
Oops: Oops: 0001 [#1] SMP PTI
CPU: 4 UID: 0 PID: 827 Comm: (udev-worker) Not tainted 6.11.8-gentoo #1
Hardware name: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 06/23/2024
RIP: 0010:strlen+0x4/0x30
Code: f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa &lt;80&gt; 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 cc
RSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202
RAX: 00000000ffffffea RBX: 00007f033c669379 RCX: 0000000000000001
RDX: 0000000000000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379
RBP: 00000000ffffffea R08: 0000000000000000 R09: 00000000c0ba916a
R10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8
R13: 0000000000000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30
FS:  00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f033c669379 CR3: 0000000107b1e004 CR4: 00000000003706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 ? __die+0x23/0x70
 ? page_fault_oops+0x149/0x4c0
 ? raw_spin_rq_lock_nested+0xe/0x20
 ? sched_balance_newidle+0x22b/0x3c0
 ? update_load_avg+0x78/0x770
 ? exc_page_fault+0x6f/0x150
 ? asm_exc_page_fault+0x26/0x30
 ? __pfx_pci_conf1_write+0x10/0x10
 ? strlen+0x4/0x30
 devm_kstrdup+0x25/0x70
 brcmf_of_probe+0x273/0x350 [brcmfmac]</Note>
    </Notes>
    <CVE>CVE-2025-21750</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

btrfs: fix assertion failure when splitting ordered extent after transaction abort

If while we are doing a direct IO write a transaction abort happens, we
mark all existing ordered extents with the BTRFS_ORDERED_IOERR flag (done
at btrfs_destroy_ordered_extents()), and then after that if we enter
btrfs_split_ordered_extent() and the ordered extent has bytes left
(meaning we have a bio that doesn't cover the whole ordered extent, see
details at btrfs_extract_ordered_extent()), we will fail on the following
assertion at btrfs_split_ordered_extent():

   ASSERT(!(flags &amp; ~BTRFS_ORDERED_TYPE_FLAGS));

because the BTRFS_ORDERED_IOERR flag is set and the definition of
BTRFS_ORDERED_TYPE_FLAGS is just the union of all flags that identify the
type of write (regular, nocow, prealloc, compressed, direct IO, encoded).

Fix this by returning an error from btrfs_extract_ordered_extent() if we
find the BTRFS_ORDERED_IOERR flag in the ordered extent. The error will
be the error that resulted in the transaction abort or -EIO if no
transaction abort happened.

This was recently reported by syzbot with the following trace:

   FAULT_INJECTION: forcing a failure.
   name failslab, interval 1, probability 0, space 0, times 1
   CPU: 0 UID: 0 PID: 5321 Comm: syz.0.0 Not tainted 6.13.0-rc5-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:94 [inline]
    dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
    fail_dump lib/fault-inject.c:53 [inline]
    should_fail_ex+0x3b0/0x4e0 lib/fault-inject.c:154
    should_failslab+0xac/0x100 mm/failslab.c:46
    slab_pre_alloc_hook mm/slub.c:4072 [inline]
    slab_alloc_node mm/slub.c:4148 [inline]
    __do_kmalloc_node mm/slub.c:4297 [inline]
    __kmalloc_noprof+0xdd/0x4c0 mm/slub.c:4310
    kmalloc_noprof include/linux/slab.h:905 [inline]
    kzalloc_noprof include/linux/slab.h:1037 [inline]
    btrfs_chunk_alloc_add_chunk_item+0x244/0x1100 fs/btrfs/volumes.c:5742
    reserve_chunk_space+0x1ca/0x2c0 fs/btrfs/block-group.c:4292
    check_system_chunk fs/btrfs/block-group.c:4319 [inline]
    do_chunk_alloc fs/btrfs/block-group.c:3891 [inline]
    btrfs_chunk_alloc+0x77b/0xf80 fs/btrfs/block-group.c:4187
    find_free_extent_update_loop fs/btrfs/extent-tree.c:4166 [inline]
    find_free_extent+0x42d1/0x5810 fs/btrfs/extent-tree.c:4579
    btrfs_reserve_extent+0x422/0x810 fs/btrfs/extent-tree.c:4672
    btrfs_new_extent_direct fs/btrfs/direct-io.c:186 [inline]
    btrfs_get_blocks_direct_write+0x706/0xfa0 fs/btrfs/direct-io.c:321
    btrfs_dio_iomap_begin+0xbb7/0x1180 fs/btrfs/direct-io.c:525
    iomap_iter+0x697/0xf60 fs/iomap/iter.c:90
    __iomap_dio_rw+0xeb9/0x25b0 fs/iomap/direct-io.c:702
    btrfs_dio_write fs/btrfs/direct-io.c:775 [inline]
    btrfs_direct_write+0x610/0xa30 fs/btrfs/direct-io.c:880
    btrfs_do_write_iter+0x2a0/0x760 fs/btrfs/file.c:1397
    do_iter_readv_writev+0x600/0x880
    vfs_writev+0x376/0xba0 fs/read_write.c:1050
    do_pwritev fs/read_write.c:1146 [inline]
    __do_sys_pwritev2 fs/read_write.c:1204 [inline]
    __se_sys_pwritev2+0x196/0x2b0 fs/read_write.c:1195
    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:0x7f1281f85d29
   RSP: 002b:00007f12819fe038 EFLAGS: 00000246 ORIG_RAX: 0000000000000148
   RAX: ffffffffffffffda RBX: 00007f1282176080 RCX: 00007f1281f85d29
   RDX: 0000000000000001 RSI: 0000000020000240 RDI: 0000000000000005
   RBP: 00007f12819fe090 R08: 0000000000000000 R09: 0000000000000003
   R10: 0000000000007000 R11: 0000000000000246 R12: 0000000000000002
   R13: 0000000000000000 R14: 00007f1282176080 R15: 00007ffcb9e23328
    &lt;/TASK&gt;
   BTRFS error (device loop0 state A): Transaction aborted (error -12)
   BTRFS: error (device loop0 state A
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-21754</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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">This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2025-21755</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

vsock: Keep the binding until socket destruction

Preserve sockets bindings; this includes both resulting from an explicit
bind() and those implicitly bound through autobind during connect().

Prevents socket unbinding during a transport reassignment, which fixes a
use-after-free:

    1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2)
    2. transport-&gt;release() calls vsock_remove_bound() without checking if
       sk was bound and moved to bound list (refcnt=1)
    3. vsock_bind() assumes sk is in unbound list and before
       __vsock_insert_bound(vsock_bound_sockets()) calls
       __vsock_remove_bound() which does:
           list_del_init(&amp;vsk-&gt;bound_table); // nop
           sock_put(&amp;vsk-&gt;sk);               // refcnt=0

BUG: KASAN: slab-use-after-free in __vsock_bind+0x62e/0x730
Read of size 4 at addr ffff88816b46a74c by task a.out/2057
 dump_stack_lvl+0x68/0x90
 print_report+0x174/0x4f6
 kasan_report+0xb9/0x190
 __vsock_bind+0x62e/0x730
 vsock_bind+0x97/0xe0
 __sys_bind+0x154/0x1f0
 __x64_sys_bind+0x6e/0xb0
 do_syscall_64+0x93/0x1b0
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Allocated by task 2057:
 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
 __vsock_create.constprop.0+0x2e/0xb60
 vsock_create+0xe4/0x420
 __sock_create+0x241/0x650
 __sys_socket+0xf2/0x1a0
 __x64_sys_socket+0x6e/0xb0
 do_syscall_64+0x93/0x1b0
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Freed by task 2057:
 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
 __vsock_bind+0x5e1/0x730
 vsock_bind+0x97/0xe0
 __sys_bind+0x154/0x1f0
 __x64_sys_bind+0x6e/0xb0
 do_syscall_64+0x93/0x1b0
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

refcount_t: addition on 0; use-after-free.
WARNING: CPU: 7 PID: 2057 at lib/refcount.c:25 refcount_warn_saturate+0xce/0x150
RIP: 0010:refcount_warn_saturate+0xce/0x150
 __vsock_bind+0x66d/0x730
 vsock_bind+0x97/0xe0
 __sys_bind+0x154/0x1f0
 __x64_sys_bind+0x6e/0xb0
 do_syscall_64+0x93/0x1b0
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

refcount_t: underflow; use-after-free.
WARNING: CPU: 7 PID: 2057 at lib/refcount.c:28 refcount_warn_saturate+0xee/0x150
RIP: 0010:refcount_warn_saturate+0xee/0x150
 vsock_remove_bound+0x187/0x1e0
 __vsock_release+0x383/0x4a0
 vsock_release+0x90/0x120
 __sock_release+0xa3/0x250
 sock_close+0x14/0x20
 __fput+0x359/0xa80
 task_work_run+0x107/0x1d0
 do_exit+0x847/0x2560
 do_group_exit+0xb8/0x250
 __x64_sys_exit_group+0x3a/0x50
 x64_sys_call+0xfec/0x14f0
 do_syscall_64+0x93/0x1b0
 entry_SYSCALL_64_after_hwframe+0x76/0x7e</Note>
    </Notes>
    <CVE>CVE-2025-21756</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ipv6: mcast: add RCU protection to mld_newpack()

mld_newpack() can be called without RTNL or RCU being held.

Note that we no longer can use sock_alloc_send_skb() because
ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.

Instead use alloc_skb() and charge the net-&gt;ipv6.igmp_sk
socket under RCU protection.</Note>
    </Notes>
    <CVE>CVE-2025-21758</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ipv6: mcast: extend RCU protection in igmp6_send()

igmp6_send() can be called without RTNL or RCU being held.

Extend RCU protection so that we can safely fetch the net pointer
and avoid a potential UAF.

Note that we no longer can use sock_alloc_send_skb() because
ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.

Instead use alloc_skb() and charge the net-&gt;ipv6.igmp_sk
socket under RCU protection.</Note>
    </Notes>
    <CVE>CVE-2025-21759</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ndisc: extend RCU protection in ndisc_send_skb()

ndisc_send_skb() can be called without RTNL or RCU held.

Acquire rcu_read_lock() earlier, so that we can use dev_net_rcu()
and avoid a potential UAF.</Note>
    </Notes>
    <CVE>CVE-2025-21760</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

openvswitch: use RCU protection in ovs_vport_cmd_fill_info()

ovs_vport_cmd_fill_info() can be called without RTNL or RCU.

Use RCU protection and dev_net_rcu() to avoid potential UAF.</Note>
    </Notes>
    <CVE>CVE-2025-21761</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

arp: use RCU protection in arp_xmit()

arp_xmit() can be called without RTNL or RCU protection.

Use RCU protection to avoid potential UAF.</Note>
    </Notes>
    <CVE>CVE-2025-21762</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

neighbour: use RCU protection in __neigh_notify()

__neigh_notify() can be called without RTNL or RCU protection.

Use RCU protection to avoid potential UAF.</Note>
    </Notes>
    <CVE>CVE-2025-21763</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ndisc: use RCU protection in ndisc_alloc_skb()

ndisc_alloc_skb() can be called without RTNL or RCU being held.

Add RCU protection to avoid possible UAF.</Note>
    </Notes>
    <CVE>CVE-2025-21764</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ipv6: use RCU protection in ip6_default_advmss()

ip6_default_advmss() needs rcu protection to make
sure the net structure it reads does not disappear.</Note>
    </Notes>
    <CVE>CVE-2025-21765</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ipv4: use RCU protection in __ip_rt_update_pmtu()

__ip_rt_update_pmtu() must use RCU protection to make
sure the net structure it reads does not disappear.</Note>
    </Notes>
    <CVE>CVE-2025-21766</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net: ipv6: fix dst ref loops in rpl, seg6 and ioam6 lwtunnels

Some lwtunnels have a dst cache for post-transformation dst.
If the packet destination did not change we may end up recording
a reference to the lwtunnel in its own cache, and the lwtunnel
state will never be freed.

Discovered by the ioam6.sh test, kmemleak was recently fixed
to catch per-cpu memory leaks. I'm not sure if rpl and seg6
can actually hit this, but in principle I don't see why not.</Note>
    </Notes>
    <CVE>CVE-2025-21768</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

partitions: mac: fix handling of bogus partition table

Fix several issues in partition probing:

 - The bailout for a bad partoffset must use put_dev_sector(), since the
   preceding read_part_sector() succeeded.
 - If the partition table claims a silly sector size like 0xfff bytes
   (which results in partition table entries straddling sector boundaries),
   bail out instead of accessing out-of-bounds memory.
 - We must not assume that the partition table contains proper NUL
   termination - use strnlen() and strncmp() instead of strlen() and
   strcmp().</Note>
    </Notes>
    <CVE>CVE-2025-21772</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

can: etas_es58x: fix potential NULL pointer dereference on udev-&gt;serial

The driver assumed that es58x_dev-&gt;udev-&gt;serial could never be NULL.
While this is true on commercially available devices, an attacker
could spoof the device identity providing a NULL USB serial number.
That would trigger a NULL pointer dereference.

Add a check on es58x_dev-&gt;udev-&gt;serial before accessing it.</Note>
    </Notes>
    <CVE>CVE-2025-21773</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

can: ctucanfd: handle skb allocation failure

If skb allocation fails, the pointer to struct can_frame is NULL. This
is actually handled everywhere inside ctucan_err_interrupt() except for
the only place.

Add the missed NULL check.

Found by Linux Verification Center (linuxtesting.org) with SVACE static
analysis tool.</Note>
    </Notes>
    <CVE>CVE-2025-21775</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

USB: hub: Ignore non-compliant devices with too many configs or interfaces

Robert Morris created a test program which can cause
usb_hub_to_struct_hub() to dereference a NULL or inappropriate
pointer:

Oops: general protection fault, probably for non-canonical address
0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTI
CPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14
Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021
Workqueue: usb_hub_wq hub_event
RIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110
...
Call Trace:
 &lt;TASK&gt;
 ? die_addr+0x31/0x80
 ? exc_general_protection+0x1b4/0x3c0
 ? asm_exc_general_protection+0x26/0x30
 ? usb_hub_adjust_deviceremovable+0x78/0x110
 hub_probe+0x7c7/0xab0
 usb_probe_interface+0x14b/0x350
 really_probe+0xd0/0x2d0
 ? __pfx___device_attach_driver+0x10/0x10
 __driver_probe_device+0x6e/0x110
 driver_probe_device+0x1a/0x90
 __device_attach_driver+0x7e/0xc0
 bus_for_each_drv+0x7f/0xd0
 __device_attach+0xaa/0x1a0
 bus_probe_device+0x8b/0xa0
 device_add+0x62e/0x810
 usb_set_configuration+0x65d/0x990
 usb_generic_driver_probe+0x4b/0x70
 usb_probe_device+0x36/0xd0

The cause of this error is that the device has two interfaces, and the
hub driver binds to interface 1 instead of interface 0, which is where
usb_hub_to_struct_hub() looks.

We can prevent the problem from occurring by refusing to accept hub
devices that violate the USB spec by having more than one
configuration or interface.</Note>
    </Notes>
    <CVE>CVE-2025-21776</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernel

Advertise support for Hyper-V's SEND_IPI and SEND_IPI_EX hypercalls if and
only if the local API is emulated/virtualized by KVM, and explicitly reject
said hypercalls if the local APIC is emulated in userspace, i.e. don't rely
on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID.

Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if
Hyper-V enlightenments are exposed to the guest without an in-kernel local
APIC:

  dump_stack+0xbe/0xfd
  __kasan_report.cold+0x34/0x84
  kasan_report+0x3a/0x50
  __apic_accept_irq+0x3a/0x5c0
  kvm_hv_send_ipi.isra.0+0x34e/0x820
  kvm_hv_hypercall+0x8d9/0x9d0
  kvm_emulate_hypercall+0x506/0x7e0
  __vmx_handle_exit+0x283/0xb60
  vmx_handle_exit+0x1d/0xd0
  vcpu_enter_guest+0x16b0/0x24c0
  vcpu_run+0xc0/0x550
  kvm_arch_vcpu_ioctl_run+0x170/0x6d0
  kvm_vcpu_ioctl+0x413/0xb20
  __se_sys_ioctl+0x111/0x160
  do_syscal1_64+0x30/0x40
  entry_SYSCALL_64_after_hwframe+0x67/0xd1

Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode
can't be modified after vCPUs are created, i.e. if one vCPU has an
in-kernel local APIC, then all vCPUs have an in-kernel local APIC.</Note>
    </Notes>
    <CVE>CVE-2025-21779</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

drm/amdgpu: avoid buffer overflow attach in smu_sys_set_pp_table()

It malicious user provides a small pptable through sysfs and then
a bigger pptable, it may cause buffer overflow attack in function
smu_sys_set_pp_table().</Note>
    </Notes>
    <CVE>CVE-2025-21780</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

batman-adv: fix panic during interface removal

Reference counting is used to ensure that
batadv_hardif_neigh_node and batadv_hard_iface
are not freed before/during
batadv_v_elp_throughput_metric_update work is
finished.

But there isn't a guarantee that the hard if will
remain associated with a soft interface up until
the work is finished.

This fixes a crash triggered by reboot that looks
like this:

Call trace:
 batadv_v_mesh_free+0xd0/0x4dc [batman_adv]
 batadv_v_elp_throughput_metric_update+0x1c/0xa4
 process_one_work+0x178/0x398
 worker_thread+0x2e8/0x4d0
 kthread+0xd8/0xdc
 ret_from_fork+0x10/0x20

(the batadv_v_mesh_free call is misleading,
and does not actually happen)

I was able to make the issue happen more reliably
by changing hardif_neigh-&gt;bat_v.metric_work work
to be delayed work. This allowed me to track down
and confirm the fix.

[sven@narfation.org: prevent entering batadv_v_elp_get_throughput without
 soft_iface]</Note>
    </Notes>
    <CVE>CVE-2025-21781</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

orangefs: fix a oob in orangefs_debug_write

I got a syzbot report: slab-out-of-bounds Read in
orangefs_debug_write... several people suggested fixes,
I tested Al Viro's suggestion and made this patch.</Note>
    </Notes>
    <CVE>CVE-2025-21782</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

drm/amdgpu: bail out when failed to load fw in psp_init_cap_microcode()

In function psp_init_cap_microcode(), it should bail out when failed to
load firmware, otherwise it may cause invalid memory access.</Note>
    </Notes>
    <CVE>CVE-2025-21784</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array

The loop that detects/populates cache information already has a bounds
check on the array size but does not account for cache levels with
separate data/instructions cache. Fix this by incrementing the index
for any populated leaf (instead of any populated level).</Note>
    </Notes>
    <CVE>CVE-2025-21785</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

vrf: use RCU protection in l3mdev_l3_out()

l3mdev_l3_out() can be called without RCU being held:

raw_sendmsg()
 ip_push_pending_frames()
  ip_send_skb()
   ip_local_out()
    __ip_local_out()
     l3mdev_ip_out()

Add rcu_read_lock() / rcu_read_unlock() pair to avoid
a potential UAF.</Note>
    </Notes>
    <CVE>CVE-2025-21791</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ax25: Fix refcount leak caused by setting SO_BINDTODEVICE sockopt

If an AX25 device is bound to a socket by setting the SO_BINDTODEVICE
socket option, a refcount leak will occur in ax25_release().

Commit 9fd75b66b8f6 ("ax25: Fix refcount leaks caused by ax25_cb_del()")
added decrement of device refcounts in ax25_release(). In order for that
to work correctly the refcounts must already be incremented when the
device is bound to the socket. An AX25 device can be bound to a socket
by either calling ax25_bind() or setting SO_BINDTODEVICE socket option.
In both cases the refcounts should be incremented, but in fact it is done
only in ax25_bind().

This bug leads to the following issue reported by Syzkaller:

================================================================
refcount_t: decrement hit 0; leaking memory.
WARNING: CPU: 1 PID: 5932 at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210 lib/refcount.c:31
Modules linked in:
CPU: 1 UID: 0 PID: 5932 Comm: syz-executor424 Not tainted 6.13.0-rc4-syzkaller-00110-g4099a71718b0 #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:refcount_warn_saturate+0x1ed/0x210 lib/refcount.c:31
Call Trace:
 &lt;TASK&gt;
 __refcount_dec include/linux/refcount.h:336 [inline]
 refcount_dec include/linux/refcount.h:351 [inline]
 ref_tracker_free+0x710/0x820 lib/ref_tracker.c:236
 netdev_tracker_free include/linux/netdevice.h:4156 [inline]
 netdev_put include/linux/netdevice.h:4173 [inline]
 netdev_put include/linux/netdevice.h:4169 [inline]
 ax25_release+0x33f/0xa10 net/ax25/af_ax25.c:1069
 __sock_release+0xb0/0x270 net/socket.c:640
 sock_close+0x1c/0x30 net/socket.c:1408
 ...
 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
 ...
 &lt;/TASK&gt;
================================================================

Fix the implementation of ax25_setsockopt() by adding increment of
refcounts for the new device bound, and decrement of refcounts for
the old unbound device.</Note>
    </Notes>
    <CVE>CVE-2025-21792</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

spi: sn-f-ospi: Fix division by zero

When there is no dummy cycle in the spi-nor commands, both dummy bus cycle
bytes and width are zero. Because of the cpu's warning when divided by
zero, the warning should be avoided. Return just zero to avoid such
calculations.</Note>
    </Notes>
    <CVE>CVE-2025-21793</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

HID: hid-thrustmaster: fix stack-out-of-bounds read in usb_check_int_endpoints()

Syzbot[1] has detected a stack-out-of-bounds read of the ep_addr array from
hid-thrustmaster driver. This array is passed to usb_check_int_endpoints
function from usb.c core driver, which executes a for loop that iterates
over the elements of the passed array. Not finding a null element at the end of
the array, it tries to read the next, non-existent element, crashing the kernel.

To fix this, a 0 element was added at the end of the array to break the for
loop.

[1] https://syzkaller.appspot.com/bug?extid=9c9179ac46169c56c1ad</Note>
    </Notes>
    <CVE>CVE-2025-21794</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

nfsd: clear acl_access/acl_default after releasing them

If getting acl_default fails, acl_access and acl_default will be released
simultaneously. However, acl_access will still retain a pointer pointing
to the released posix_acl, which will trigger a WARNING in
nfs3svc_release_getacl like this:

------------[ cut here ]------------
refcount_t: underflow; use-after-free.
WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28
refcount_warn_saturate+0xb5/0x170
Modules linked in:
CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted
6.12.0-rc6-00079-g04ae226af01f-dirty #8
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.1-2.fc37 04/01/2014
RIP: 0010:refcount_warn_saturate+0xb5/0x170
Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75
e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff &lt;0f&gt; 0b eb
cd 0f b6 1d 8a3
RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde
RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380
RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56
R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001
R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0
FS:  0000000000000000(0000) GS:ffff88871ed00000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 ? refcount_warn_saturate+0xb5/0x170
 ? __warn+0xa5/0x140
 ? refcount_warn_saturate+0xb5/0x170
 ? report_bug+0x1b1/0x1e0
 ? handle_bug+0x53/0xa0
 ? exc_invalid_op+0x17/0x40
 ? asm_exc_invalid_op+0x1a/0x20
 ? tick_nohz_tick_stopped+0x1e/0x40
 ? refcount_warn_saturate+0xb5/0x170
 ? refcount_warn_saturate+0xb5/0x170
 nfs3svc_release_getacl+0xc9/0xe0
 svc_process_common+0x5db/0xb60
 ? __pfx_svc_process_common+0x10/0x10
 ? __rcu_read_unlock+0x69/0xa0
 ? __pfx_nfsd_dispatch+0x10/0x10
 ? svc_xprt_received+0xa1/0x120
 ? xdr_init_decode+0x11d/0x190
 svc_process+0x2a7/0x330
 svc_handle_xprt+0x69d/0x940
 svc_recv+0x180/0x2d0
 nfsd+0x168/0x200
 ? __pfx_nfsd+0x10/0x10
 kthread+0x1a2/0x1e0
 ? kthread+0xf4/0x1e0
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x34/0x60
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;
Kernel panic - not syncing: kernel: panic_on_warn set ...

Clear acl_access/acl_default after posix_acl_release is called to prevent
UAF from being triggered.</Note>
    </Notes>
    <CVE>CVE-2025-21796</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()

The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region()
macro to request a needed resource. A string variable that lives on the
stack is then used to store a dynamically computed resource name, which
is then passed on as one of the macro arguments. This can lead to
undefined behavior.

Depending on the current contents of the memory, the manifestations of
errors may vary. One possible output may be as follows:

  $ cat /proc/iomem
  30000000-37ffffff :
  38000000-3fffffff :

Sometimes, garbage may appear after the colon.

In very rare cases, if no NULL-terminator is found in memory, the system
might crash because the string iterator will overrun which can lead to
access of unmapped memory above the stack.

Thus, fix this by replacing outbound_name with the name of the previously
requested resource. With the changes applied, the output will be as
follows:

  $ cat /proc/iomem
  30000000-37ffffff : memory2
  38000000-3fffffff : memory3

[kwilczynski: commit log]</Note>
    </Notes>
    <CVE>CVE-2025-21804</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net: let net.core.dev_weight always be non-zero

The following problem was encountered during stability test:

(NULL net_device): NAPI poll function process_backlog+0x0/0x530 \
	returned 1, exceeding its budget of 0.
------------[ cut here ]------------
list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \
	next=ffff88905f746e40.
WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \
	__list_add_valid_or_report+0xf3/0x130
CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+
RIP: 0010:__list_add_valid_or_report+0xf3/0x130
Call Trace:
? __warn+0xcd/0x250
? __list_add_valid_or_report+0xf3/0x130
enqueue_to_backlog+0x923/0x1070
netif_rx_internal+0x92/0x2b0
__netif_rx+0x15/0x170
loopback_xmit+0x2ef/0x450
dev_hard_start_xmit+0x103/0x490
__dev_queue_xmit+0xeac/0x1950
ip_finish_output2+0x6cc/0x1620
ip_output+0x161/0x270
ip_push_pending_frames+0x155/0x1a0
raw_sendmsg+0xe13/0x1550
__sys_sendto+0x3bf/0x4e0
__x64_sys_sendto+0xdc/0x1b0
do_syscall_64+0x5b/0x170
entry_SYSCALL_64_after_hwframe+0x76/0x7e

The reproduction command is as follows:
  sysctl -w net.core.dev_weight=0
  ping 127.0.0.1

This is because when the napi's weight is set to 0, process_backlog() may
return 0 and clear the NAPI_STATE_SCHED bit of napi-&gt;state, causing this
napi to be re-polled in net_rx_action() until __do_softirq() times out.
Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() can
be retriggered in enqueue_to_backlog(), causing this issue.

Making the napi's weight always non-zero solves this problem.

Triggering this issue requires system-wide admin (setting is
not namespaced).</Note>
    </Notes>
    <CVE>CVE-2025-21806</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net: xdp: Disallow attaching device-bound programs in generic mode

Device-bound programs are used to support RX metadata kfuncs. These
kfuncs are driver-specific and rely on the driver context to read the
metadata. This means they can't work in generic XDP mode. However, there
is no check to disallow such programs from being attached in generic
mode, in which case the metadata kfuncs will be called in an invalid
context, leading to crashes.

Fix this by adding a check to disallow attaching device-bound programs
in generic mode.</Note>
    </Notes>
    <CVE>CVE-2025-21808</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

driver core: class: Fix wild pointer dereferences in API class_dev_iter_next()

There are a potential wild pointer dereferences issue regarding APIs
class_dev_iter_(init|next|exit)(), as explained by below typical usage:

// All members of @iter are wild pointers.
struct class_dev_iter iter;

// class_dev_iter_init(@iter, @class, ...) checks parameter @class for
// potential class_to_subsys() error, and it returns void type and does
// not initialize its output parameter @iter, so caller can not detect
// the error and continues to invoke class_dev_iter_next(@iter) even if
// @iter still contains wild pointers.
class_dev_iter_init(&amp;iter, ...);

// Dereference these wild pointers in @iter here once suffer the error.
while (dev = class_dev_iter_next(&amp;iter)) { ... };

// Also dereference these wild pointers here.
class_dev_iter_exit(&amp;iter);

Actually, all callers of these APIs have such usage pattern in kernel tree.
Fix by:
- Initialize output parameter @iter by memset() in class_dev_iter_init()
  and give callers prompt by pr_crit() for the error.
- Check if @iter is valid in class_dev_iter_next().</Note>
    </Notes>
    <CVE>CVE-2025-21810</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ax25: rcu protect dev-&gt;ax25_ptr

syzbot found a lockdep issue [1].

We should remove ax25 RTNL dependency in ax25_setsockopt()

This should also fix a variety of possible UAF in ax25.

[1]

WARNING: possible circular locking dependency detected
6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted
------------------------------------------------------
syz.5.1818/12806 is trying to acquire lock:
 ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680

but task is already holding lock:
 ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline]
 ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-&gt; #1 (sk_lock-AF_AX25){+.+.}-{0:0}:
        lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849
        lock_sock_nested+0x48/0x100 net/core/sock.c:3642
        lock_sock include/net/sock.h:1618 [inline]
        ax25_kill_by_device net/ax25/af_ax25.c:101 [inline]
        ax25_device_event+0x24d/0x580 net/ax25/af_ax25.c:146
        notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85
       __dev_notify_flags+0x207/0x400
        dev_change_flags+0xf0/0x1a0 net/core/dev.c:9026
        dev_ifsioc+0x7c8/0xe70 net/core/dev_ioctl.c:563
        dev_ioctl+0x719/0x1340 net/core/dev_ioctl.c:820
        sock_do_ioctl+0x240/0x460 net/socket.c:1234
        sock_ioctl+0x626/0x8e0 net/socket.c:1339
        vfs_ioctl fs/ioctl.c:51 [inline]
        __do_sys_ioctl fs/ioctl.c:906 [inline]
        __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892
        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

-&gt; #0 (rtnl_mutex){+.+.}-{4:4}:
        check_prev_add kernel/locking/lockdep.c:3161 [inline]
        check_prevs_add kernel/locking/lockdep.c:3280 [inline]
        validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904
        __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226
        lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849
        __mutex_lock_common kernel/locking/mutex.c:585 [inline]
        __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735
        ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680
        do_sock_setsockopt+0x3af/0x720 net/socket.c:2324
        __sys_setsockopt net/socket.c:2349 [inline]
        __do_sys_setsockopt net/socket.c:2355 [inline]
        __se_sys_setsockopt net/socket.c:2352 [inline]
        __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352
        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

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(sk_lock-AF_AX25);
                               lock(rtnl_mutex);
                               lock(sk_lock-AF_AX25);
  lock(rtnl_mutex);

 *** DEADLOCK ***

1 lock held by syz.5.1818/12806:
  #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline]
  #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574

stack backtrace:
CPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #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
  print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074
  check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206
  check_prev_add kernel/locking/lockdep.c:3161 [inline]
  check_prevs_add kernel/lockin
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-21812</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

mm/compaction: fix UBSAN shift-out-of-bounds warning

syzkaller reported a UBSAN shift-out-of-bounds warning of (1UL &lt;&lt; order)
in isolate_freepages_block().  The bogus compound_order can be any value
because it is union with flags.  Add back the MAX_PAGE_ORDER check to fix
the warning.</Note>
    </Notes>
    <CVE>CVE-2025-21815</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

Revert "drm/amd/display: Use HW lock mgr for PSR1"

This reverts commit
a2b5a9956269 ("drm/amd/display: Use HW lock mgr for PSR1")

Because it may cause system hang while connect with two edp panel.</Note>
    </Notes>
    <CVE>CVE-2025-21819</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

tty: xilinx_uartps: split sysrq handling

lockdep detects the following circular locking dependency:

CPU 0                      CPU 1
========================== ============================
cdns_uart_isr()            printk()
  uart_port_lock(port)       console_lock()
			     cdns_uart_console_write()
                               if (!port-&gt;sysrq)
                                 uart_port_lock(port)
  uart_handle_break()
    port-&gt;sysrq = ...
  uart_handle_sysrq_char()
    printk()
      console_lock()

The fixed commit attempts to avoid this situation by only taking the
port lock in cdns_uart_console_write if port-&gt;sysrq unset. However, if
(as shown above) cdns_uart_console_write runs before port-&gt;sysrq is set,
then it will try to take the port lock anyway. This may result in a
deadlock.

Fix this by splitting sysrq handling into two parts. We use the prepare
helper under the port lock and defer handling until we release the lock.</Note>
    </Notes>
    <CVE>CVE-2025-21820</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

fbdev: omap: use threaded IRQ for LCD DMA

When using touchscreen and framebuffer, Nokia 770 crashes easily with:

    BUG: scheduling while atomic: irq/144-ads7846/82/0x00010000
    Modules linked in: usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs omap_udc ohci_omap ohci_hcd
    CPU: 0 UID: 0 PID: 82 Comm: irq/144-ads7846 Not tainted 6.12.7-770 #2
    Hardware name: Nokia 770
    Call trace:
     unwind_backtrace from show_stack+0x10/0x14
     show_stack from dump_stack_lvl+0x54/0x5c
     dump_stack_lvl from __schedule_bug+0x50/0x70
     __schedule_bug from __schedule+0x4d4/0x5bc
     __schedule from schedule+0x34/0xa0
     schedule from schedule_preempt_disabled+0xc/0x10
     schedule_preempt_disabled from __mutex_lock.constprop.0+0x218/0x3b4
     __mutex_lock.constprop.0 from clk_prepare_lock+0x38/0xe4
     clk_prepare_lock from clk_set_rate+0x18/0x154
     clk_set_rate from sossi_read_data+0x4c/0x168
     sossi_read_data from hwa742_read_reg+0x5c/0x8c
     hwa742_read_reg from send_frame_handler+0xfc/0x300
     send_frame_handler from process_pending_requests+0x74/0xd0
     process_pending_requests from lcd_dma_irq_handler+0x50/0x74
     lcd_dma_irq_handler from __handle_irq_event_percpu+0x44/0x130
     __handle_irq_event_percpu from handle_irq_event+0x28/0x68
     handle_irq_event from handle_level_irq+0x9c/0x170
     handle_level_irq from generic_handle_domain_irq+0x2c/0x3c
     generic_handle_domain_irq from omap1_handle_irq+0x40/0x8c
     omap1_handle_irq from generic_handle_arch_irq+0x28/0x3c
     generic_handle_arch_irq from call_with_stack+0x1c/0x24
     call_with_stack from __irq_svc+0x94/0xa8
    Exception stack(0xc5255da0 to 0xc5255de8)
    5da0: 00000001 c22fc620 00000000 00000000 c08384a8 c106fc00 00000000 c240c248
    5dc0: c113a600 c3f6ec30 00000001 00000000 c22fc620 c5255df0 c22fc620 c0279a94
    5de0: 60000013 ffffffff
     __irq_svc from clk_prepare_lock+0x4c/0xe4
     clk_prepare_lock from clk_get_rate+0x10/0x74
     clk_get_rate from uwire_setup_transfer+0x40/0x180
     uwire_setup_transfer from spi_bitbang_transfer_one+0x2c/0x9c
     spi_bitbang_transfer_one from spi_transfer_one_message+0x2d0/0x664
     spi_transfer_one_message from __spi_pump_transfer_message+0x29c/0x498
     __spi_pump_transfer_message from __spi_sync+0x1f8/0x2e8
     __spi_sync from spi_sync+0x24/0x40
     spi_sync from ads7846_halfd_read_state+0x5c/0x1c0
     ads7846_halfd_read_state from ads7846_irq+0x58/0x348
     ads7846_irq from irq_thread_fn+0x1c/0x78
     irq_thread_fn from irq_thread+0x120/0x228
     irq_thread from kthread+0xc8/0xe8
     kthread from ret_from_fork+0x14/0x28

As a quick fix, switch to a threaded IRQ which provides a stable system.</Note>
    </Notes>
    <CVE>CVE-2025-21821</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

batman-adv: Drop unmanaged ELP metric worker

The ELP worker needs to calculate new metric values for all neighbors
"reachable" over an interface. Some of the used metric sources require
locks which might need to sleep. This sleep is incompatible with the RCU
list iterator used for the recorded neighbors. The initial approach to work
around of this problem was to queue another work item per neighbor and then
run this in a new context.

Even when this solved the RCU vs might_sleep() conflict, it has a major
problems: Nothing was stopping the work item in case it is not needed
anymore - for example because one of the related interfaces was removed or
the batman-adv module was unloaded - resulting in potential invalid memory
accesses.

Directly canceling the metric worker also has various problems:

* cancel_work_sync for a to-be-deactivated interface is called with
  rtnl_lock held. But the code in the ELP metric worker also tries to use
  rtnl_lock() - which will never return in this case. This also means that
  cancel_work_sync would never return because it is waiting for the worker
  to finish.
* iterating over the neighbor list for the to-be-deactivated interface is
  currently done using the RCU specific methods. Which means that it is
  possible to miss items when iterating over it without the associated
  spinlock - a behaviour which is acceptable for a periodic metric check
  but not for a cleanup routine (which must "stop" all still running
  workers)

The better approch is to get rid of the per interface neighbor metric
worker and handle everything in the interface worker. The original problems
are solved by:

* creating a list of neighbors which require new metric information inside
  the RCU protected context, gathering the metric according to the new list
  outside the RCU protected context
* only use rcu_trylock inside metric gathering code to avoid a deadlock
  when the cancel_delayed_work_sync is called in the interface removal code
  (which is called with the rtnl_lock held)</Note>
    </Notes>
    <CVE>CVE-2025-21823</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

bpf: Cancel the running bpf_timer through kworker for PREEMPT_RT

During the update procedure, when overwrite element in a pre-allocated
htab, the freeing of old_element is protected by the bucket lock. The
reason why the bucket lock is necessary is that the old_element has
already been stashed in htab-&gt;extra_elems after alloc_htab_elem()
returns. If freeing the old_element after the bucket lock is unlocked,
the stashed element may be reused by concurrent update procedure and the
freeing of old_element will run concurrently with the reuse of the
old_element. However, the invocation of check_and_free_fields() may
acquire a spin-lock which violates the lockdep rule because its caller
has already held a raw-spin-lock (bucket lock). The following warning
will be reported when such race happens:

  BUG: scheduling while atomic: test_progs/676/0x00000003
  3 locks held by test_progs/676:
  #0: ffffffff864b0240 (rcu_read_lock_trace){....}-{0:0}, at: bpf_prog_test_run_syscall+0x2c0/0x830
  #1: ffff88810e961188 (&amp;htab-&gt;lockdep_key){....}-{2:2}, at: htab_map_update_elem+0x306/0x1500
  #2: ffff8881f4eac1b8 (&amp;base-&gt;softirq_expiry_lock){....}-{2:2}, at: hrtimer_cancel_wait_running+0xe9/0x1b0
  Modules linked in: bpf_testmod(O)
  Preemption disabled at:
  [&lt;ffffffff817837a3&gt;] htab_map_update_elem+0x293/0x1500
  CPU: 0 UID: 0 PID: 676 Comm: test_progs Tainted: G ... 6.12.0+ #11
  Tainted: [W]=WARN, [O]=OOT_MODULE
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)...
  Call Trace:
  &lt;TASK&gt;
  dump_stack_lvl+0x57/0x70
  dump_stack+0x10/0x20
  __schedule_bug+0x120/0x170
  __schedule+0x300c/0x4800
  schedule_rtlock+0x37/0x60
  rtlock_slowlock_locked+0x6d9/0x54c0
  rt_spin_lock+0x168/0x230
  hrtimer_cancel_wait_running+0xe9/0x1b0
  hrtimer_cancel+0x24/0x30
  bpf_timer_delete_work+0x1d/0x40
  bpf_timer_cancel_and_free+0x5e/0x80
  bpf_obj_free_fields+0x262/0x4a0
  check_and_free_fields+0x1d0/0x280
  htab_map_update_elem+0x7fc/0x1500
  bpf_prog_9f90bc20768e0cb9_overwrite_cb+0x3f/0x43
  bpf_prog_ea601c4649694dbd_overwrite_timer+0x5d/0x7e
  bpf_prog_test_run_syscall+0x322/0x830
  __sys_bpf+0x135d/0x3ca0
  __x64_sys_bpf+0x75/0xb0
  x64_sys_call+0x1b5/0xa10
  do_syscall_64+0x3b/0xc0
  entry_SYSCALL_64_after_hwframe+0x4b/0x53
  ...
  &lt;/TASK&gt;

It seems feasible to break the reuse and refill of per-cpu extra_elems
into two independent parts: reuse the per-cpu extra_elems with bucket
lock being held and refill the old_element as per-cpu extra_elems after
the bucket lock is unlocked. However, it will make the concurrent
overwrite procedures on the same CPU return unexpected -E2BIG error when
the map is full.

Therefore, the patch fixes the lock problem by breaking the cancelling
of bpf_timer into two steps for PREEMPT_RT:
1) use hrtimer_try_to_cancel() and check its return value
2) if the timer is running, use hrtimer_cancel() through a kworker to
   cancel it again
Considering that the current implementation of hrtimer_cancel() will try
to acquire a being held softirq_expiry_lock when the current timer is
running, these steps above are reasonable. However, it also has
downside. When the timer is running, the cancelling of the timer is
delayed when releasing the last map uref. The delay is also fixable
(e.g., break the cancelling of bpf timer into two parts: one part in
locked scope, another one in unlocked scope), it can be revised later if
necessary.

It is a bit hard to decide the right fix tag. One reason is that the
problem depends on PREEMPT_RT which is enabled in v6.12. Considering the
softirq_expiry_lock lock exists since v5.4 and bpf_timer is introduced
in v5.15, the bpf_timer commit is used in the fixes tag and an extra
depends-on tag is added to state the dependency on PREEMPT_RT.

Depends-on: v6.12+ with PREEMPT_RT enabled</Note>
    </Notes>
    <CVE>CVE-2025-21825</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

wifi: mac80211: don't flush non-uploaded STAs

If STA state is pre-moved to AUTHORIZED (such as in IBSS
scenarios) and insertion fails, the station is freed.
In this case, the driver never knew about the station,
so trying to flush it is unexpected and may crash.

Check if the sta was uploaded to the driver before and
fix this.</Note>
    </Notes>
    <CVE>CVE-2025-21828</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

RDMA/rxe: Fix the warning "__rxe_cleanup+0x12c/0x170 [rdma_rxe]"

The Call Trace is as below:
"
  &lt;TASK&gt;
  ? show_regs.cold+0x1a/0x1f
  ? __rxe_cleanup+0x12c/0x170 [rdma_rxe]
  ? __warn+0x84/0xd0
  ? __rxe_cleanup+0x12c/0x170 [rdma_rxe]
  ? report_bug+0x105/0x180
  ? handle_bug+0x46/0x80
  ? exc_invalid_op+0x19/0x70
  ? asm_exc_invalid_op+0x1b/0x20
  ? __rxe_cleanup+0x12c/0x170 [rdma_rxe]
  ? __rxe_cleanup+0x124/0x170 [rdma_rxe]
  rxe_destroy_qp.cold+0x24/0x29 [rdma_rxe]
  ib_destroy_qp_user+0x118/0x190 [ib_core]
  rdma_destroy_qp.cold+0x43/0x5e [rdma_cm]
  rtrs_cq_qp_destroy.cold+0x1d/0x2b [rtrs_core]
  rtrs_srv_close_work.cold+0x1b/0x31 [rtrs_server]
  process_one_work+0x21d/0x3f0
  worker_thread+0x4a/0x3c0
  ? process_one_work+0x3f0/0x3f0
  kthread+0xf0/0x120
  ? kthread_complete_and_exit+0x20/0x20
  ret_from_fork+0x22/0x30
  &lt;/TASK&gt;
"
When too many rdma resources are allocated, rxe needs more time to
handle these rdma resources. Sometimes with the current timeout, rxe
can not release the rdma resources correctly.

Compared with other rdma drivers, a bigger timeout is used.</Note>
    </Notes>
    <CVE>CVE-2025-21829</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

landlock: Handle weird files

A corrupted filesystem (e.g. bcachefs) might return weird files.
Instead of throwing a warning and allowing access to such file, treat
them as regular files.</Note>
    </Notes>
    <CVE>CVE-2025-21830</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

PCI: Avoid putting some root ports into D3 on TUXEDO Sirius Gen1

commit 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend") sets the
policy that all PCIe ports are allowed to use D3.  When the system is
suspended if the port is not power manageable by the platform and won't be
used for wakeup via a PME this sets up the policy for these ports to go
into D3hot.

This policy generally makes sense from an OSPM perspective but it leads to
problems with wakeup from suspend on the TUXEDO Sirius 16 Gen 1 with a
specific old BIOS. This manifests as a system hang.

On the affected Device + BIOS combination, add a quirk for the root port of
the problematic controller to ensure that these root ports are not put into
D3hot at suspend.

This patch is based on

  https://lore.kernel.org/linux-pci/20230708214457.1229-2-mario.limonciello@amd.com

but with the added condition both in the documentation and in the code to
apply only to the TUXEDO Sirius 16 Gen 1 with a specific old BIOS and only
the affected root ports.</Note>
    </Notes>
    <CVE>CVE-2025-21831</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

block: don't revert iter for -EIOCBQUEUED

blkdev_read_iter() has a few odd checks, like gating the position and
count adjustment on whether or not the result is bigger-than-or-equal to
zero (where bigger than makes more sense), and not checking the return
value of blkdev_direct_IO() before doing an iov_iter_revert(). The
latter can lead to attempting to revert with a negative value, which
when passed to iov_iter_revert() as an unsigned value will lead to
throwing a WARN_ON() because unroll is bigger than MAX_RW_COUNT.

Be sane and don't revert for -EIOCBQUEUED, like what is done in other
spots.</Note>
    </Notes>
    <CVE>CVE-2025-21832</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE

There is a WARN_ON_ONCE to catch an unlikely situation when
domain_remove_dev_pasid can't find the `pasid`. In case it nevertheless
happens we must avoid using a NULL pointer.</Note>
    </Notes>
    <CVE>CVE-2025-21833</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

usb: gadget: f_midi: fix MIDI Streaming descriptor lengths

While the MIDI jacks are configured correctly, and the MIDIStreaming
endpoint descriptors are filled with the correct information,
bNumEmbMIDIJack and bLength are set incorrectly in these descriptors.

This does not matter when the numbers of in and out ports are equal, but
when they differ the host will receive broken descriptors with
uninitialized stack memory leaking into the descriptor for whichever
value is smaller.

The precise meaning of "in" and "out" in the port counts is not clearly
defined and can be confusing.  But elsewhere the driver consistently
uses this to match the USB meaning of IN and OUT viewed from the host,
so that "in" ports send data to the host and "out" ports receive data
from it.</Note>
    </Notes>
    <CVE>CVE-2025-21835</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

io_uring/kbuf: reallocate buf lists on upgrade

IORING_REGISTER_PBUF_RING can reuse an old struct io_buffer_list if it
was created for legacy selected buffer and has been emptied. It violates
the requirement that most of the field should stay stable after publish.
Always reallocate it instead.</Note>
    </Notes>
    <CVE>CVE-2025-21836</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

usb: gadget: core: flush gadget workqueue after device removal

device_del() can lead to new work being scheduled in gadget-&gt;work
workqueue. This is observed, for example, with the dwc3 driver with the
following call stack:
  device_del()
    gadget_unbind_driver()
      usb_gadget_disconnect_locked()
        dwc3_gadget_pullup()
	  dwc3_gadget_soft_disconnect()
	    usb_gadget_set_state()
	      schedule_work(&amp;gadget-&gt;work)

Move flush_work() after device_del() to ensure the workqueue is cleaned
up.</Note>
    </Notes>
    <CVE>CVE-2025-21838</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

smb: client: Add check for next_buffer in receive_encrypted_standard()

Add check for the return value of cifs_buf_get() and cifs_small_buf_get()
in receive_encrypted_standard() to prevent null pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2025-21844</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

acct: perform last write from workqueue

In [1] it was reported that the acct(2) system call can be used to
trigger NULL deref in cases where it is set to write to a file that
triggers an internal lookup. This can e.g., happen when pointing acc(2)
to /sys/power/resume. At the point the where the write to this file
happens the calling task has already exited and called exit_fs(). A
lookup will thus trigger a NULL-deref when accessing current-&gt;fs.

Reorganize the code so that the the final write happens from the
workqueue but with the caller's credentials. This preserves the
(strange) permission model and has almost no regression risk.

This api should stop to exist though.</Note>
    </Notes>
    <CVE>CVE-2025-21846</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ASoC: SOF: stream-ipc: Check for cstream nullity in sof_ipc_msg_data()

The nullity of sps-&gt;cstream should be checked similarly as it is done in
sof_set_stream_data_offset() function.
Assuming that it is not NULL if sps-&gt;stream is NULL is incorrect and can
lead to NULL pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2025-21847</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

nfp: bpf: Add check for nfp_app_ctrl_msg_alloc()

Add check for the return value of nfp_app_ctrl_msg_alloc() in
nfp_bpf_cmsg_alloc() to prevent null pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2025-21848</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

nvmet: Fix crash when a namespace is disabled

The namespace percpu counter protects pending I/O, and we can
only safely diable the namespace once the counter drop to zero.
Otherwise we end up with a crash when running blktests/nvme/058
(eg for loop transport):

[ 2352.930426] [  T53909] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI
[ 2352.930431] [  T53909] KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
[ 2352.930434] [  T53909] CPU: 3 UID: 0 PID: 53909 Comm: kworker/u16:5 Tainted: G        W          6.13.0-rc6 #232
[ 2352.930438] [  T53909] Tainted: [W]=WARN
[ 2352.930440] [  T53909] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
[ 2352.930443] [  T53909] Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop]
[ 2352.930449] [  T53909] RIP: 0010:blkcg_set_ioprio+0x44/0x180

as the queue is already torn down when calling submit_bio();

So we need to init the percpu counter in nvmet_ns_enable(), and
wait for it to drop to zero in nvmet_ns_disable() to avoid having
I/O pending after the namespace has been disabled.</Note>
    </Notes>
    <CVE>CVE-2025-21850</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

bpf: avoid holding freeze_mutex during mmap operation

We use map-&gt;freeze_mutex to prevent races between map_freeze() and
memory mapping BPF map contents with writable permissions. The way we
naively do this means we'll hold freeze_mutex for entire duration of all
the mm and VMA manipulations, which is completely unnecessary. This can
potentially also lead to deadlocks, as reported by syzbot in [0].

So, instead, hold freeze_mutex only during writeability checks, bump
(proactively) "write active" count for the map, unlock the mutex and
proceed with mmap logic. And only if something went wrong during mmap
logic, then undo that "write active" counter increment.

  [0] https://lore.kernel.org/bpf/678dcbc9.050a0220.303755.0066.GAE@google.com/</Note>
    </Notes>
    <CVE>CVE-2025-21853</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

sockmap, vsock: For connectible sockets allow only connected

sockmap expects all vsocks to have a transport assigned, which is expressed
in vsock_proto::psock_update_sk_prot(). However, there is an edge case
where an unconnected (connectible) socket may lose its previously assigned
transport. This is handled with a NULL check in the vsock/BPF recv path.

Another design detail is that listening vsocks are not supposed to have any
transport assigned at all. Which implies they are not supported by the
sockmap. But this is complicated by the fact that a socket, before
switching to TCP_LISTEN, may have had some transport assigned during a
failed connect() attempt. Hence, we may end up with a listening vsock in a
sockmap, which blows up quickly:

KASAN: null-ptr-deref in range [0x0000000000000120-0x0000000000000127]
CPU: 7 UID: 0 PID: 56 Comm: kworker/7:0 Not tainted 6.14.0-rc1+
Workqueue: vsock-loopback vsock_loopback_work
RIP: 0010:vsock_read_skb+0x4b/0x90
Call Trace:
 sk_psock_verdict_data_ready+0xa4/0x2e0
 virtio_transport_recv_pkt+0x1ca8/0x2acc
 vsock_loopback_work+0x27d/0x3f0
 process_one_work+0x846/0x1420
 worker_thread+0x5b3/0xf80
 kthread+0x35a/0x700
 ret_from_fork+0x2d/0x70
 ret_from_fork_asm+0x1a/0x30

For connectible sockets, instead of relying solely on the state of
vsk-&gt;transport, tell sockmap to only allow those representing established
connections. This aligns with the behaviour for AF_INET and AF_UNIX.</Note>
    </Notes>
    <CVE>CVE-2025-21854</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

s390/ism: add release function for struct device

According to device_release() in /drivers/base/core.c,
a device without a release function is a broken device
and must be fixed.

The current code directly frees the device after calling device_add()
without waiting for other kernel parts to release their references.
Thus, a reference could still be held to a struct device,
e.g., by sysfs, leading to potential use-after-free
issues if a proper release function is not set.</Note>
    </Notes>
    <CVE>CVE-2025-21856</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net/sched: cls_api: fix error handling causing NULL dereference

tcf_exts_miss_cookie_base_alloc() calls xa_alloc_cyclic() which can
return 1 if the allocation succeeded after wrapping. This was treated as
an error, with value 1 returned to caller tcf_exts_init_ex() which sets
exts-&gt;actions to NULL and returns 1 to caller fl_change().

fl_change() treats err == 1 as success, calling tcf_exts_validate_ex()
which calls tcf_action_init() with exts-&gt;actions as argument, where it
is dereferenced.

Example trace:

BUG: kernel NULL pointer dereference, address: 0000000000000000
CPU: 114 PID: 16151 Comm: handler114 Kdump: loaded Not tainted 5.14.0-503.16.1.el9_5.x86_64 #1
RIP: 0010:tcf_action_init+0x1f8/0x2c0
Call Trace:
 tcf_action_init+0x1f8/0x2c0
 tcf_exts_validate_ex+0x175/0x190
 fl_change+0x537/0x1120 [cls_flower]</Note>
    </Notes>
    <CVE>CVE-2025-21857</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

geneve: Fix use-after-free in geneve_find_dev().

syzkaller reported a use-after-free in geneve_find_dev() [0]
without repro.

geneve_configure() links struct geneve_dev.next to
net_generic(net, geneve_net_id)-&gt;geneve_list.

The net here could differ from dev_net(dev) if IFLA_NET_NS_PID,
IFLA_NET_NS_FD, or IFLA_TARGET_NETNSID is set.

When dev_net(dev) is dismantled, geneve_exit_batch_rtnl() finally
calls unregister_netdevice_queue() for each dev in the netns,
and later the dev is freed.

However, its geneve_dev.next is still linked to the backend UDP
socket netns.

Then, use-after-free will occur when another geneve dev is created
in the netns.

Let's call geneve_dellink() instead in geneve_destroy_tunnels().

[0]:
BUG: KASAN: slab-use-after-free in geneve_find_dev drivers/net/geneve.c:1295 [inline]
BUG: KASAN: slab-use-after-free in geneve_configure+0x234/0x858 drivers/net/geneve.c:1343
Read of size 2 at addr ffff000054d6ee24 by task syz.1.4029/13441

CPU: 1 UID: 0 PID: 13441 Comm: syz.1.4029 Not tainted 6.13.0-g0ad9617c78ac #24 dc35ca22c79fb82e8e7bc5c9c9adafea898b1e3d
Hardware name: linux,dummy-virt (DT)
Call trace:
 show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:466 (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_load2_noabort+0x20/0x30 mm/kasan/report_generic.c:379
 geneve_find_dev drivers/net/geneve.c:1295 [inline]
 geneve_configure+0x234/0x858 drivers/net/geneve.c:1343
 geneve_newlink+0xb8/0x128 drivers/net/geneve.c:1634
 rtnl_newlink_create+0x23c/0x868 net/core/rtnetlink.c:3795
 __rtnl_newlink net/core/rtnetlink.c:3906 [inline]
 rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021
 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911
 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543
 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938
 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline]
 netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1348
 netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1892
 sock_sendmsg_nosec net/socket.c:713 [inline]
 __sock_sendmsg net/socket.c:728 [inline]
 ____sys_sendmsg+0x410/0x6f8 net/socket.c:2568
 ___sys_sendmsg+0x178/0x1d8 net/socket.c:2622
 __sys_sendmsg net/socket.c:2654 [inline]
 __do_sys_sendmsg net/socket.c:2659 [inline]
 __se_sys_sendmsg net/socket.c:2657 [inline]
 __arm64_sys_sendmsg+0x12c/0x1c8 net/socket.c:2657
 __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
 el0_svc+0x4c/0xa8 arch/arm64/kernel/entry-common.c:744
 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:762
 el0t_64_sync+0x198/0x1a0 arch/arm64/kernel/entry.S:600

Allocated by task 13247:
 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:4298 [inline]
 __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4304
 __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:645
 alloc_netdev_mqs+0xb8/0x11a0 net/core/dev.c:11470
 rtnl_create_link+0x2b8/0xb50 net/core/rtnetlink.c:3604
 rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3780
 __rtnl_newlink net/core/rtnetlink.c:3906 [inline]
 rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021
 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911
 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543
 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938
 netlink_unicast_kernel net/netlink/af_n
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-21858</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

USB: gadget: f_midi: f_midi_complete to call queue_work

When using USB MIDI, a lock is attempted to be acquired twice through a
re-entrant call to f_midi_transmit, causing a deadlock.

Fix it by using queue_work() to schedule the inner f_midi_transmit() via
a high priority work queue from the completion handler.</Note>
    </Notes>
    <CVE>CVE-2025-21859</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

mm/migrate_device: don't add folio to be freed to LRU in migrate_device_finalize()

If migration succeeded, we called
folio_migrate_flags()-&gt;mem_cgroup_migrate() to migrate the memcg from the
old to the new folio.  This will set memcg_data of the old folio to 0.

Similarly, if migration failed, memcg_data of the dst folio is left unset.

If we call folio_putback_lru() on such folios (memcg_data == 0), we will
add the folio to be freed to the LRU, making memcg code unhappy.  Running
the hmm selftests:

  # ./hmm-tests
  ...
  #  RUN           hmm.hmm_device_private.migrate ...
  [  102.078007][T14893] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff27d200 pfn:0x13cc00
  [  102.079974][T14893] anon flags: 0x17ff00000020018(uptodate|dirty|swapbacked|node=0|zone=2|lastcpupid=0x7ff)
  [  102.082037][T14893] raw: 017ff00000020018 dead000000000100 dead000000000122 ffff8881353896c9
  [  102.083687][T14893] raw: 00000007ff27d200 0000000000000000 00000001ffffffff 0000000000000000
  [  102.085331][T14893] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg &amp;&amp; !mem_cgroup_disabled())
  [  102.087230][T14893] ------------[ cut here ]------------
  [  102.088279][T14893] WARNING: CPU: 0 PID: 14893 at ./include/linux/memcontrol.h:726 folio_lruvec_lock_irqsave+0x10e/0x170
  [  102.090478][T14893] Modules linked in:
  [  102.091244][T14893] CPU: 0 UID: 0 PID: 14893 Comm: hmm-tests Not tainted 6.13.0-09623-g6c216bc522fd #151
  [  102.093089][T14893] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014
  [  102.094848][T14893] RIP: 0010:folio_lruvec_lock_irqsave+0x10e/0x170
  [  102.096104][T14893] Code: ...
  [  102.099908][T14893] RSP: 0018:ffffc900236c37b0 EFLAGS: 00010293
  [  102.101152][T14893] RAX: 0000000000000000 RBX: ffffea0004f30000 RCX: ffffffff8183f426
  [  102.102684][T14893] RDX: ffff8881063cb880 RSI: ffffffff81b8117f RDI: ffff8881063cb880
  [  102.104227][T14893] RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000
  [  102.105757][T14893] R10: 0000000000000001 R11: 0000000000000002 R12: ffffc900236c37d8
  [  102.107296][T14893] R13: ffff888277a2bcb0 R14: 000000000000001f R15: 0000000000000000
  [  102.108830][T14893] FS:  00007ff27dbdd740(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000
  [  102.110643][T14893] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [  102.111924][T14893] CR2: 00007ff27d400000 CR3: 000000010866e000 CR4: 0000000000750ef0
  [  102.113478][T14893] PKRU: 55555554
  [  102.114172][T14893] Call Trace:
  [  102.114805][T14893]  &lt;TASK&gt;
  [  102.115397][T14893]  ? folio_lruvec_lock_irqsave+0x10e/0x170
  [  102.116547][T14893]  ? __warn.cold+0x110/0x210
  [  102.117461][T14893]  ? folio_lruvec_lock_irqsave+0x10e/0x170
  [  102.118667][T14893]  ? report_bug+0x1b9/0x320
  [  102.119571][T14893]  ? handle_bug+0x54/0x90
  [  102.120494][T14893]  ? exc_invalid_op+0x17/0x50
  [  102.121433][T14893]  ? asm_exc_invalid_op+0x1a/0x20
  [  102.122435][T14893]  ? __wake_up_klogd.part.0+0x76/0xd0
  [  102.123506][T14893]  ? dump_page+0x4f/0x60
  [  102.124352][T14893]  ? folio_lruvec_lock_irqsave+0x10e/0x170
  [  102.125500][T14893]  folio_batch_move_lru+0xd4/0x200
  [  102.126577][T14893]  ? __pfx_lru_add+0x10/0x10
  [  102.127505][T14893]  __folio_batch_add_and_move+0x391/0x720
  [  102.128633][T14893]  ? __pfx_lru_add+0x10/0x10
  [  102.129550][T14893]  folio_putback_lru+0x16/0x80
  [  102.130564][T14893]  migrate_device_finalize+0x9b/0x530
  [  102.131640][T14893]  dmirror_migrate_to_device.constprop.0+0x7c5/0xad0
  [  102.133047][T14893]  dmirror_fops_unlocked_ioctl+0x89b/0xc80

Likely, nothing else goes wrong: putting the last folio reference will
remove the folio from the LRU again.  So besides memcg complaining, adding
the folio to be freed to the LRU is just an unnecessary step.

The new flow resembles what we have in migrate_folio_move(): add the dst
to the lru, rem
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-21861</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

drop_monitor: fix incorrect initialization order

Syzkaller reports the following bug:

BUG: spinlock bad magic on CPU#1, syz-executor.0/7995
 lock: 0xffff88805303f3e0, .magic: 00000000, .owner: &lt;none&gt;/-1, .owner_cpu: 0
CPU: 1 PID: 7995 Comm: syz-executor.0 Tainted: G            E     5.10.209+ #1
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x119/0x179 lib/dump_stack.c:118
 debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]
 do_raw_spin_lock+0x1f6/0x270 kernel/locking/spinlock_debug.c:112
 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:117 [inline]
 _raw_spin_lock_irqsave+0x50/0x70 kernel/locking/spinlock.c:159
 reset_per_cpu_data+0xe6/0x240 [drop_monitor]
 net_dm_cmd_trace+0x43d/0x17a0 [drop_monitor]
 genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739
 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]
 genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800
 netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2497
 genl_rcv+0x29/0x40 net/netlink/genetlink.c:811
 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline]
 netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1348
 netlink_sendmsg+0x914/0xe00 net/netlink/af_netlink.c:1916
 sock_sendmsg_nosec net/socket.c:651 [inline]
 __sock_sendmsg+0x157/0x190 net/socket.c:663
 ____sys_sendmsg+0x712/0x870 net/socket.c:2378
 ___sys_sendmsg+0xf8/0x170 net/socket.c:2432
 __sys_sendmsg+0xea/0x1b0 net/socket.c:2461
 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x62/0xc7
RIP: 0033:0x7f3f9815aee9
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 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f3f972bf0c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f3f9826d050 RCX: 00007f3f9815aee9
RDX: 0000000020000000 RSI: 0000000020001300 RDI: 0000000000000007
RBP: 00007f3f981b63bd R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000006e R14: 00007f3f9826d050 R15: 00007ffe01ee6768

If drop_monitor is built as a kernel module, syzkaller may have time
to send a netlink NET_DM_CMD_START message during the module loading.
This will call the net_dm_monitor_start() function that uses
a spinlock that has not yet been initialized.

To fix this, let's place resource initialization above the registration
of a generic netlink family.

Found by InfoTeCS on behalf of Linux Verification Center
(linuxtesting.org) with Syzkaller.</Note>
    </Notes>
    <CVE>CVE-2025-21862</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

io_uring: prevent opcode speculation

sqe-&gt;opcode is used for different tables, make sure we santitise it
against speculations.</Note>
    </Notes>
    <CVE>CVE-2025-21863</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

tcp: drop secpath at the same time as we currently drop dst

Xiumei reported hitting the WARN in xfrm6_tunnel_net_exit while
running tests that boil down to:
 - create a pair of netns
 - run a basic TCP test over ipcomp6
 - delete the pair of netns

The xfrm_state found on spi_byaddr was not deleted at the time we
delete the netns, because we still have a reference on it. This
lingering reference comes from a secpath (which holds a ref on the
xfrm_state), which is still attached to an skb. This skb is not
leaked, it ends up on sk_receive_queue and then gets defer-free'd by
skb_attempt_defer_free.

The problem happens when we defer freeing an skb (push it on one CPU's
defer_list), and don't flush that list before the netns is deleted. In
that case, we still have a reference on the xfrm_state that we don't
expect at this point.

We already drop the skb's dst in the TCP receive path when it's no
longer needed, so let's also drop the secpath. At this point,
tcp_filter has already called into the LSM hooks that may require the
secpath, so it should not be needed anymore. However, in some of those
places, the MPTCP extension has just been attached to the skb, so we
cannot simply drop all extensions.</Note>
    </Notes>
    <CVE>CVE-2025-21864</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

gtp: Suppress list corruption splat in gtp_net_exit_batch_rtnl().

Brad Spengler reported the list_del() corruption splat in
gtp_net_exit_batch_rtnl(). [0]

Commit eb28fd76c0a0 ("gtp: Destroy device along with udp socket's netns
dismantle.") added the for_each_netdev() loop in gtp_net_exit_batch_rtnl()
to destroy devices in each netns as done in geneve and ip tunnels.

However, this could trigger -&gt;dellink() twice for the same device during
-&gt;exit_batch_rtnl().

Say we have two netns A &amp; B and gtp device B that resides in netns B but
whose UDP socket is in netns A.

  1. cleanup_net() processes netns A and then B.

  2. gtp_net_exit_batch_rtnl() finds the device B while iterating
     netns A's gn-&gt;gtp_dev_list and calls -&gt;dellink().

  [ device B is not yet unlinked from netns B
    as unregister_netdevice_many() has not been called. ]

  3. gtp_net_exit_batch_rtnl() finds the device B while iterating
     netns B's for_each_netdev() and calls -&gt;dellink().

gtp_dellink() cleans up the device's hash table, unlinks the dev from
gn-&gt;gtp_dev_list, and calls unregister_netdevice_queue().

Basically, calling gtp_dellink() multiple times is fine unless
CONFIG_DEBUG_LIST is enabled.

Let's remove for_each_netdev() in gtp_net_exit_batch_rtnl() and
delegate the destruction to default_device_exit_batch() as done
in bareudp.

[0]:
list_del corruption, ffff8880aaa62c00-&gt;next (autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object]) is LIST_POISON1 (ffffffffffffff02) (prev is 0xffffffffffffff04)
kernel BUG at lib/list_debug.c:58!
Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 UID: 0 PID: 1804 Comm: kworker/u8:7 Tainted: G                T   6.12.13-grsec-full-20250211091339 #1
Tainted: [T]=RANDSTRUCT
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Workqueue: netns cleanup_net
RIP: 0010:[&lt;ffffffff84947381&gt;] __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58
Code: c2 76 91 31 c0 e8 9f b1 f7 fc 0f 0b 4d 89 f0 48 c7 c1 02 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 e0 c2 76 91 31 c0 e8 7f b1 f7 fc &lt;0f&gt; 0b 4d 89 e8 48 c7 c1 04 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 60
RSP: 0018:fffffe8040b4fbd0 EFLAGS: 00010283
RAX: 00000000000000cc RBX: dffffc0000000000 RCX: ffffffff818c4054
RDX: ffffffff84947381 RSI: ffffffff818d1512 RDI: 0000000000000000
RBP: ffff8880aaa62c00 R08: 0000000000000001 R09: fffffbd008169f32
R10: fffffe8040b4f997 R11: 0000000000000001 R12: a1988d84f24943e4
R13: ffffffffffffff02 R14: ffffffffffffff04 R15: ffff8880aaa62c08
RBX: kasan shadow of 0x0
RCX: __wake_up_klogd.part.0+0x74/0xe0 kernel/printk/printk.c:4554
RDX: __list_del_entry_valid_or_report+0x141/0x200 lib/list_debug.c:58
RSI: vprintk+0x72/0x100 kernel/printk/printk_safe.c:71
RBP: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc00/0x1000 [slab object]
RSP: process kstack fffffe8040b4fbd0+0x7bd0/0x8000 [kworker/u8:7+netns 1804 ]
R09: kasan shadow of process kstack fffffe8040b4f990+0x7990/0x8000 [kworker/u8:7+netns 1804 ]
R10: process kstack fffffe8040b4f997+0x7997/0x8000 [kworker/u8:7+netns 1804 ]
R15: autoslab_size_M_dev_P_net_core_dev_11127_8_1328_8_S_4096_A_64_n_139+0xc08/0x1000 [slab object]
FS:  0000000000000000(0000) GS:ffff888116000000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000748f5372c000 CR3: 0000000015408000 CR4: 00000000003406f0 shadow CR4: 00000000003406f0
Stack:
 0000000000000000 ffffffff8a0c35e7 ffffffff8a0c3603 ffff8880aaa62c00
 ffff8880aaa62c00 0000000000000004 ffff88811145311c 0000000000000005
 0000000000000001 ffff8880aaa62000 fffffe8040b4fd40 ffffffff8a0c360d
Call Trace:
 &lt;TASK&gt;
 [&lt;ffffffff8a0c360d&gt;] __list_del_entry_valid include/linux/list.h:131 [inline] fffffe8040b4fc28
 [&lt;ffffffff8a0c360d&gt;] __list_del_entry include/linux/list.h:248 [inline] fffffe8040b4fc28
 [&lt;ffffffff8a0c360d&gt;] list_del include/linux/list.h:262 [inl
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-21865</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

powerpc/code-patching: Fix KASAN hit by not flagging text patching area as VM_ALLOC

Erhard reported the following KASAN hit while booting his PowerMac G4
with a KASAN-enabled kernel 6.13-rc6:

  BUG: KASAN: vmalloc-out-of-bounds in copy_to_kernel_nofault+0xd8/0x1c8
  Write of size 8 at addr f1000000 by task chronyd/1293

  CPU: 0 UID: 123 PID: 1293 Comm: chronyd Tainted: G        W          6.13.0-rc6-PMacG4 #2
  Tainted: [W]=WARN
  Hardware name: PowerMac3,6 7455 0x80010303 PowerMac
  Call Trace:
  [c2437590] [c1631a84] dump_stack_lvl+0x70/0x8c (unreliable)
  [c24375b0] [c0504998] print_report+0xdc/0x504
  [c2437610] [c050475c] kasan_report+0xf8/0x108
  [c2437690] [c0505a3c] kasan_check_range+0x24/0x18c
  [c24376a0] [c03fb5e4] copy_to_kernel_nofault+0xd8/0x1c8
  [c24376c0] [c004c014] patch_instructions+0x15c/0x16c
  [c2437710] [c00731a8] bpf_arch_text_copy+0x60/0x7c
  [c2437730] [c0281168] bpf_jit_binary_pack_finalize+0x50/0xac
  [c2437750] [c0073cf4] bpf_int_jit_compile+0xb30/0xdec
  [c2437880] [c0280394] bpf_prog_select_runtime+0x15c/0x478
  [c24378d0] [c1263428] bpf_prepare_filter+0xbf8/0xc14
  [c2437990] [c12677ec] bpf_prog_create_from_user+0x258/0x2b4
  [c24379d0] [c027111c] do_seccomp+0x3dc/0x1890
  [c2437ac0] [c001d8e0] system_call_exception+0x2dc/0x420
  [c2437f30] [c00281ac] ret_from_syscall+0x0/0x2c
  --- interrupt: c00 at 0x5a1274
  NIP:  005a1274 LR: 006a3b3c CTR: 005296c8
  REGS: c2437f40 TRAP: 0c00   Tainted: G        W           (6.13.0-rc6-PMacG4)
  MSR:  0200f932 &lt;VEC,EE,PR,FP,ME,IR,DR,RI&gt;  CR: 24004422  XER: 00000000

  GPR00: 00000166 af8f3fa0 a7ee3540 00000001 00000000 013b6500 005a5858 0200f932
  GPR08: 00000000 00001fe9 013d5fc8 005296c8 2822244c 00b2fcd8 00000000 af8f4b57
  GPR16: 00000000 00000001 00000000 00000000 00000000 00000001 00000000 00000002
  GPR24: 00afdbb0 00000000 00000000 00000000 006e0004 013ce060 006e7c1c 00000001
  NIP [005a1274] 0x5a1274
  LR [006a3b3c] 0x6a3b3c
  --- interrupt: c00

  The buggy address belongs to the virtual mapping at
   [f1000000, f1002000) created by:
   text_area_cpu_up+0x20/0x190

  The buggy address belongs to the physical page:
  page: refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x76e30
  flags: 0x80000000(zone=2)
  raw: 80000000 00000000 00000122 00000000 00000000 00000000 ffffffff 00000001
  raw: 00000000
  page dumped because: kasan: bad access detected

  Memory state around the buggy address:
   f0ffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   f0ffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  &gt;f1000000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
             ^
   f1000080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
   f1000100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
  ==================================================================

f8 corresponds to KASAN_VMALLOC_INVALID which means the area is not
initialised hence not supposed to be used yet.

Powerpc text patching infrastructure allocates a virtual memory area
using get_vm_area() and flags it as VM_ALLOC. But that flag is meant
to be used for vmalloc() and vmalloc() allocated memory is not
supposed to be used before a call to __vmalloc_node_range() which is
never called for that area.

That went undetected until commit e4137f08816b ("mm, kasan, kmsan:
instrument copy_from/to_kernel_nofault")

The area allocated by text_area_cpu_up() is not vmalloc memory, it is
mapped directly on demand when needed by map_kernel_page(). There is
no VM flag corresponding to such usage, so just pass no flag. That way
the area will be unpoisonned and usable immediately.</Note>
    </Notes>
    <CVE>CVE-2025-21866</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

bpf, test_run: Fix use-after-free issue in eth_skb_pkt_type()

KMSAN reported a use-after-free issue in eth_skb_pkt_type()[1]. The
cause of the issue was that eth_skb_pkt_type() accessed skb's data
that didn't contain an Ethernet header. This occurs when
bpf_prog_test_run_xdp() passes an invalid value as the user_data
argument to bpf_test_init().

Fix this by returning an error when user_data is less than ETH_HLEN in
bpf_test_init(). Additionally, remove the check for "if (user_size &gt;
size)" as it is unnecessary.

[1]
BUG: KMSAN: use-after-free in eth_skb_pkt_type include/linux/etherdevice.h:627 [inline]
BUG: KMSAN: use-after-free in eth_type_trans+0x4ee/0x980 net/ethernet/eth.c:165
 eth_skb_pkt_type include/linux/etherdevice.h:627 [inline]
 eth_type_trans+0x4ee/0x980 net/ethernet/eth.c:165
 __xdp_build_skb_from_frame+0x5a8/0xa50 net/core/xdp.c:635
 xdp_recv_frames net/bpf/test_run.c:272 [inline]
 xdp_test_run_batch net/bpf/test_run.c:361 [inline]
 bpf_test_run_xdp_live+0x2954/0x3330 net/bpf/test_run.c:390
 bpf_prog_test_run_xdp+0x148e/0x1b10 net/bpf/test_run.c:1318
 bpf_prog_test_run+0x5b7/0xa30 kernel/bpf/syscall.c:4371
 __sys_bpf+0x6a6/0xe20 kernel/bpf/syscall.c:5777
 __do_sys_bpf kernel/bpf/syscall.c:5866 [inline]
 __se_sys_bpf kernel/bpf/syscall.c:5864 [inline]
 __x64_sys_bpf+0xa4/0xf0 kernel/bpf/syscall.c:5864
 x64_sys_call+0x2ea0/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:322
 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:
 free_pages_prepare mm/page_alloc.c:1056 [inline]
 free_unref_page+0x156/0x1320 mm/page_alloc.c:2657
 __free_pages+0xa3/0x1b0 mm/page_alloc.c:4838
 bpf_ringbuf_free kernel/bpf/ringbuf.c:226 [inline]
 ringbuf_map_free+0xff/0x1e0 kernel/bpf/ringbuf.c:235
 bpf_map_free kernel/bpf/syscall.c:838 [inline]
 bpf_map_free_deferred+0x17c/0x310 kernel/bpf/syscall.c:862
 process_one_work kernel/workqueue.c:3229 [inline]
 process_scheduled_works+0xa2b/0x1b60 kernel/workqueue.c:3310
 worker_thread+0xedf/0x1550 kernel/workqueue.c:3391
 kthread+0x535/0x6b0 kernel/kthread.c:389
 ret_from_fork+0x6e/0x90 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

CPU: 1 UID: 0 PID: 17276 Comm: syz.1.16450 Not tainted 6.12.0-05490-g9bb88c659673 #8
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014</Note>
    </Notes>
    <CVE>CVE-2025-21867</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

powerpc/code-patching: Disable KASAN report during patching via temporary mm

Erhard reports the following KASAN hit on Talos II (power9) with kernel 6.13:

[   12.028126] ==================================================================
[   12.028198] BUG: KASAN: user-memory-access in copy_to_kernel_nofault+0x8c/0x1a0
[   12.028260] Write of size 8 at addr 0000187e458f2000 by task systemd/1

[   12.028346] CPU: 87 UID: 0 PID: 1 Comm: systemd Tainted: G                T  6.13.0-P9-dirty #3
[   12.028408] Tainted: [T]=RANDSTRUCT
[   12.028446] Hardware name: T2P9D01 REV 1.01 POWER9 0x4e1202 opal:skiboot-bc106a0 PowerNV
[   12.028500] Call Trace:
[   12.028536] [c000000008dbf3b0] [c000000001656a48] dump_stack_lvl+0xbc/0x110 (unreliable)
[   12.028609] [c000000008dbf3f0] [c0000000006e2fc8] print_report+0x6b0/0x708
[   12.028666] [c000000008dbf4e0] [c0000000006e2454] kasan_report+0x164/0x300
[   12.028725] [c000000008dbf600] [c0000000006e54d4] kasan_check_range+0x314/0x370
[   12.028784] [c000000008dbf640] [c0000000006e6310] __kasan_check_write+0x20/0x40
[   12.028842] [c000000008dbf660] [c000000000578e8c] copy_to_kernel_nofault+0x8c/0x1a0
[   12.028902] [c000000008dbf6a0] [c0000000000acfe4] __patch_instructions+0x194/0x210
[   12.028965] [c000000008dbf6e0] [c0000000000ade80] patch_instructions+0x150/0x590
[   12.029026] [c000000008dbf7c0] [c0000000001159bc] bpf_arch_text_copy+0x6c/0xe0
[   12.029085] [c000000008dbf800] [c000000000424250] bpf_jit_binary_pack_finalize+0x40/0xc0
[   12.029147] [c000000008dbf830] [c000000000115dec] bpf_int_jit_compile+0x3bc/0x930
[   12.029206] [c000000008dbf990] [c000000000423720] bpf_prog_select_runtime+0x1f0/0x280
[   12.029266] [c000000008dbfa00] [c000000000434b18] bpf_prog_load+0xbb8/0x1370
[   12.029324] [c000000008dbfb70] [c000000000436ebc] __sys_bpf+0x5ac/0x2e00
[   12.029379] [c000000008dbfd00] [c00000000043a228] sys_bpf+0x28/0x40
[   12.029435] [c000000008dbfd20] [c000000000038eb4] system_call_exception+0x334/0x610
[   12.029497] [c000000008dbfe50] [c00000000000c270] system_call_vectored_common+0xf0/0x280
[   12.029561] --- interrupt: 3000 at 0x3fff82f5cfa8
[   12.029608] NIP:  00003fff82f5cfa8 LR: 00003fff82f5cfa8 CTR: 0000000000000000
[   12.029660] REGS: c000000008dbfe80 TRAP: 3000   Tainted: G                T   (6.13.0-P9-dirty)
[   12.029735] MSR:  900000000280f032 &lt;SF,HV,VEC,VSX,EE,PR,FP,ME,IR,DR,RI&gt;  CR: 42004848  XER: 00000000
[   12.029855] IRQMASK: 0
               GPR00: 0000000000000169 00003fffdcf789a0 00003fff83067100 0000000000000005
               GPR04: 00003fffdcf78a98 0000000000000090 0000000000000000 0000000000000008
               GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
               GPR12: 0000000000000000 00003fff836ff7e0 c000000000010678 0000000000000000
               GPR16: 0000000000000000 0000000000000000 00003fffdcf78f28 00003fffdcf78f90
               GPR20: 0000000000000000 0000000000000000 0000000000000000 00003fffdcf78f80
               GPR24: 00003fffdcf78f70 00003fffdcf78d10 00003fff835c7239 00003fffdcf78bd8
               GPR28: 00003fffdcf78a98 0000000000000000 0000000000000000 000000011f547580
[   12.030316] NIP [00003fff82f5cfa8] 0x3fff82f5cfa8
[   12.030361] LR [00003fff82f5cfa8] 0x3fff82f5cfa8
[   12.030405] --- interrupt: 3000
[   12.030444] ==================================================================

Commit c28c15b6d28a ("powerpc/code-patching: Use temporary mm for
Radix MMU") is inspired from x86 but unlike x86 is doesn't disable
KASAN reports during patching. This wasn't a problem at the begining
because __patch_mem() is not instrumented.

Commit 465cabc97b42 ("powerpc/code-patching: introduce
patch_instructions()") use copy_to_kernel_nofault() to copy several
instructions at once. But when using temporary mm the destination is
not regular kernel memory but a kind of kernel-like memory located
in user address space. 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-21869</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ASoC: SOF: ipc4-topology: Harden loops for looking up ALH copiers

Other, non DAI copier widgets could have the same  stream name (sname) as
the ALH copier and in that case the copier-&gt;data is NULL, no alh_data is
attached, which could lead to NULL pointer dereference.
We could check for this NULL pointer in sof_ipc4_prepare_copier_module()
and avoid the crash, but a similar loop in sof_ipc4_widget_setup_comp_dai()
will miscalculate the ALH device count, causing broken audio.

The correct fix is to harden the matching logic by making sure that the
1. widget is a DAI widget - so dai = w-&gt;private is valid
2. the dai (and thus the copier) is ALH copier</Note>
    </Notes>
    <CVE>CVE-2025-21870</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

tee: optee: Fix supplicant wait loop

OP-TEE supplicant is a user-space daemon and it's possible for it
be hung or crashed or killed in the middle of processing an OP-TEE
RPC call. It becomes more complicated when there is incorrect shutdown
ordering of the supplicant process vs the OP-TEE client application which
can eventually lead to system hang-up waiting for the closure of the
client application.

Allow the client process waiting in kernel for supplicant response to
be killed rather than indefinitely waiting in an unkillable state. Also,
a normal uninterruptible wait should not have resulted in the hung-task
watchdog getting triggered, but the endless loop would.

This fixes issues observed during system reboot/shutdown when supplicant
got hung for some reason or gets crashed/killed which lead to client
getting hung in an unkillable state. It in turn lead to system being in
hung up state requiring hard power off/on to recover.</Note>
    </Notes>
    <CVE>CVE-2025-21871</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

scsi: ufs: core: bsg: Fix crash when arpmb command fails

If the device doesn't support arpmb we'll crash due to copying user data in
bsg_transport_sg_io_fn().

In the case where ufs_bsg_exec_advanced_rpmb_req() returns an error, do not
set the job's reply_len.

Memory crash backtrace:
3,1290,531166405,-;ufshcd 0000:00:12.5: ARPMB OP failed: error code -22

4,1308,531166555,-;Call Trace:

4,1309,531166559,-; &lt;TASK&gt;

4,1310,531166565,-; ? show_regs+0x6d/0x80

4,1311,531166575,-; ? die+0x37/0xa0

4,1312,531166583,-; ? do_trap+0xd4/0xf0

4,1313,531166593,-; ? do_error_trap+0x71/0xb0

4,1314,531166601,-; ? usercopy_abort+0x6c/0x80

4,1315,531166610,-; ? exc_invalid_op+0x52/0x80

4,1316,531166622,-; ? usercopy_abort+0x6c/0x80

4,1317,531166630,-; ? asm_exc_invalid_op+0x1b/0x20

4,1318,531166643,-; ? usercopy_abort+0x6c/0x80

4,1319,531166652,-; __check_heap_object+0xe3/0x120

4,1320,531166661,-; check_heap_object+0x185/0x1d0

4,1321,531166670,-; __check_object_size.part.0+0x72/0x150

4,1322,531166679,-; __check_object_size+0x23/0x30

4,1323,531166688,-; bsg_transport_sg_io_fn+0x314/0x3b0</Note>
    </Notes>
    <CVE>CVE-2025-21873</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

mptcp: always handle address removal under msk socket lock

Syzkaller reported a lockdep splat in the PM control path:

  WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 sock_owned_by_me include/net/sock.h:1711 [inline]
  WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 msk_owned_by_me net/mptcp/protocol.h:363 [inline]
  WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788
  Modules linked in:
  CPU: 0 UID: 0 PID: 6693 Comm: syz.0.205 Not tainted 6.14.0-rc2-syzkaller-00303-gad1b832bf1cf #0
  Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024
  RIP: 0010:sock_owned_by_me include/net/sock.h:1711 [inline]
  RIP: 0010:msk_owned_by_me net/mptcp/protocol.h:363 [inline]
  RIP: 0010:mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788
  Code: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ca 7b d3 f5 eb b9 e8 c3 7b d3 f5 90 0f 0b 90 e9 dd fb ff ff e8 b5 7b d3 f5 90 &lt;0f&gt; 0b 90 e9 3e fb ff ff 44 89 f1 80 e1 07 38 c1 0f 8c eb fb ff ff
  RSP: 0000:ffffc900034f6f60 EFLAGS: 00010283
  RAX: ffffffff8bee3c2b RBX: 0000000000000001 RCX: 0000000000080000
  RDX: ffffc90004d42000 RSI: 000000000000a407 RDI: 000000000000a408
  RBP: ffffc900034f7030 R08: ffffffff8bee37f6 R09: 0100000000000000
  R10: dffffc0000000000 R11: ffffed100bcc62e4 R12: ffff88805e6316e0
  R13: ffff88805e630c00 R14: dffffc0000000000 R15: ffff88805e630c00
  FS:  00007f7e9a7e96c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000001b2fd18ff8 CR3: 0000000032c24000 CR4: 00000000003526f0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  Call Trace:
   &lt;TASK&gt;
   mptcp_pm_remove_addr+0x103/0x1d0 net/mptcp/pm.c:59
   mptcp_pm_remove_anno_addr+0x1f4/0x2f0 net/mptcp/pm_netlink.c:1486
   mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_netlink.c:1518 [inline]
   mptcp_pm_nl_del_addr_doit+0x118d/0x1af0 net/mptcp/pm_netlink.c:1629
   genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]
   genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]
   genl_rcv_msg+0xb1f/0xec0 net/netlink/genetlink.c:1210
   netlink_rcv_skb+0x206/0x480 net/netlink/af_netlink.c:2543
   genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219
   netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline]
   netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1348
   netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1892
   sock_sendmsg_nosec net/socket.c:718 [inline]
   __sock_sendmsg+0x221/0x270 net/socket.c:733
   ____sys_sendmsg+0x53a/0x860 net/socket.c:2573
   ___sys_sendmsg net/socket.c:2627 [inline]
   __sys_sendmsg+0x269/0x350 net/socket.c:2659
   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:0x7f7e9998cde9
  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:00007f7e9a7e9038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
  RAX: ffffffffffffffda RBX: 00007f7e99ba5fa0 RCX: 00007f7e9998cde9
  RDX: 000000002000c094 RSI: 0000400000000000 RDI: 0000000000000007
  RBP: 00007f7e99a0e2a0 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
  R13: 0000000000000000 R14: 00007f7e99ba5fa0 R15: 00007fff49231088

Indeed the PM can try to send a RM_ADDR over a msk without acquiring
first the msk socket lock.

The bugged code-path comes from an early optimization: when there
are no subflows, the PM should (usually) not send RM_ADDR
notifications.

The above statement is incorrect, as without locks another process
could concur
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-21875</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

iommu/vt-d: Fix suspicious RCU usage

Commit &lt;d74169ceb0d2&gt; ("iommu/vt-d: Allocate DMAR fault interrupts
locally") moved the call to enable_drhd_fault_handling() to a code
path that does not hold any lock while traversing the drhd list. Fix
it by ensuring the dmar_global_lock lock is held when traversing the
drhd list.

Without this fix, the following warning is triggered:
 =============================
 WARNING: suspicious RCU usage
 6.14.0-rc3 #55 Not tainted
 -----------------------------
 drivers/iommu/intel/dmar.c:2046 RCU-list traversed in non-reader section!!
               other info that might help us debug this:
               rcu_scheduler_active = 1, debug_locks = 1
 2 locks held by cpuhp/1/23:
 #0: ffffffff84a67c50 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0
 #1: ffffffff84a6a380 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0
 stack backtrace:
 CPU: 1 UID: 0 PID: 23 Comm: cpuhp/1 Not tainted 6.14.0-rc3 #55
 Call Trace:
  &lt;TASK&gt;
  dump_stack_lvl+0xb7/0xd0
  lockdep_rcu_suspicious+0x159/0x1f0
  ? __pfx_enable_drhd_fault_handling+0x10/0x10
  enable_drhd_fault_handling+0x151/0x180
  cpuhp_invoke_callback+0x1df/0x990
  cpuhp_thread_fun+0x1ea/0x2c0
  smpboot_thread_fn+0x1f5/0x2e0
  ? __pfx_smpboot_thread_fn+0x10/0x10
  kthread+0x12a/0x2d0
  ? __pfx_kthread+0x10/0x10
  ret_from_fork+0x4a/0x60
  ? __pfx_kthread+0x10/0x10
  ret_from_fork_asm+0x1a/0x30
  &lt;/TASK&gt;

Holding the lock in enable_drhd_fault_handling() triggers a lockdep splat
about a possible deadlock between dmar_global_lock and cpu_hotplug_lock.
This is avoided by not holding dmar_global_lock when calling
iommu_device_register(), which initiates the device probe process.</Note>
    </Notes>
    <CVE>CVE-2025-21876</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

usbnet: gl620a: fix endpoint checking in genelink_bind()

Syzbot reports [1] a warning in usb_submit_urb() triggered by
inconsistencies between expected and actually present endpoints
in gl620a driver. Since genelink_bind() does not properly
verify whether specified eps are in fact provided by the device,
in this case, an artificially manufactured one, one may get a
mismatch.

Fix the issue by resorting to a usbnet utility function
usbnet_get_endpoints(), usually reserved for this very problem.
Check for endpoints and return early before proceeding further if
any are missing.

[1] Syzbot report:
usb 5-1: Manufacturer: syz
usb 5-1: SerialNumber: syz
usb 5-1: config 0 descriptor??
gl620a 5-1:0.23 usb0: register 'gl620a' at usb-dummy_hcd.0-1, ...
------------[ cut here ]------------
usb 5-1: BOGUS urb xfer, pipe 3 != type 1
WARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503
Modules linked in:
CPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Workqueue: mld mld_ifc_work
RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503
...
Call Trace:
 &lt;TASK&gt;
 usbnet_start_xmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467
 __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+0x9a/0x7b0 net/core/dev.c:3606
 sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343
 __dev_xmit_skb net/core/dev.c:3827 [inline]
 __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4400
 dev_queue_xmit include/linux/netdevice.h:3168 [inline]
 neigh_resolve_output net/core/neighbour.c:1514 [inline]
 neigh_resolve_output+0x5bc/0x950 net/core/neighbour.c:1494
 neigh_output include/net/neighbour.h:539 [inline]
 ip6_finish_output2+0xb1b/0x2070 net/ipv6/ip6_output.c:141
 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline]
 ip6_finish_output+0x3f9/0x1360 net/ipv6/ip6_output.c:226
 NF_HOOK_COND include/linux/netfilter.h:303 [inline]
 ip6_output+0x1f8/0x540 net/ipv6/ip6_output.c:247
 dst_output include/net/dst.h:450 [inline]
 NF_HOOK include/linux/netfilter.h:314 [inline]
 NF_HOOK include/linux/netfilter.h:308 [inline]
 mld_sendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819
 mld_send_cr net/ipv6/mcast.c:2120 [inline]
 mld_ifc_work+0x740/0xca0 net/ipv6/mcast.c:2651
 process_one_work+0x9c5/0x1ba0 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/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2025-21877</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

i2c: npcm: disable interrupt enable bit before devm_request_irq

The customer reports that there is a soft lockup issue related to
the i2c driver. After checking, the i2c module was doing a tx transfer
and the bmc machine reboots in the middle of the i2c transaction, the i2c
module keeps the status without being reset.

Due to such an i2c module status, the i2c irq handler keeps getting
triggered since the i2c irq handler is registered in the kernel booting
process after the bmc machine is doing a warm rebooting.
The continuous triggering is stopped by the soft lockup watchdog timer.

Disable the interrupt enable bit in the i2c module before calling
devm_request_irq to fix this issue since the i2c relative status bit
is read-only.

Here is the soft lockup log.
[   28.176395] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:1]
[   28.183351] Modules linked in:
[   28.186407] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.120-yocto-s-dirty-bbebc78 #1
[   28.201174] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   28.208128] pc : __do_softirq+0xb0/0x368
[   28.212055] lr : __do_softirq+0x70/0x368
[   28.215972] sp : ffffff8035ebca00
[   28.219278] x29: ffffff8035ebca00 x28: 0000000000000002 x27: ffffff80071a3780
[   28.226412] x26: ffffffc008bdc000 x25: ffffffc008bcc640 x24: ffffffc008be50c0
[   28.233546] x23: ffffffc00800200c x22: 0000000000000000 x21: 000000000000001b
[   28.240679] x20: 0000000000000000 x19: ffffff80001c3200 x18: ffffffffffffffff
[   28.247812] x17: ffffffc02d2e0000 x16: ffffff8035eb8b40 x15: 00001e8480000000
[   28.254945] x14: 02c3647e37dbfcb6 x13: 02c364f2ab14200c x12: 0000000002c364f2
[   28.262078] x11: 00000000fa83b2da x10: 000000000000b67e x9 : ffffffc008010250
[   28.269211] x8 : 000000009d983d00 x7 : 7fffffffffffffff x6 : 0000036d74732434
[   28.276344] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : 0000000000000198
[   28.283476] x2 : ffffffc02d2e0000 x1 : 00000000000000e0 x0 : ffffffc008bdcb40
[   28.290611] Call trace:
[   28.293052]  __do_softirq+0xb0/0x368
[   28.296625]  __irq_exit_rcu+0xe0/0x100
[   28.300374]  irq_exit+0x14/0x20
[   28.303513]  handle_domain_irq+0x68/0x90
[   28.307440]  gic_handle_irq+0x78/0xb0
[   28.311098]  call_on_irq_stack+0x20/0x38
[   28.315019]  do_interrupt_handler+0x54/0x5c
[   28.319199]  el1_interrupt+0x2c/0x4c
[   28.322777]  el1h_64_irq_handler+0x14/0x20
[   28.326872]  el1h_64_irq+0x74/0x78
[   28.330269]  __setup_irq+0x454/0x780
[   28.333841]  request_threaded_irq+0xd0/0x1b4
[   28.338107]  devm_request_threaded_irq+0x84/0x100
[   28.342809]  npcm_i2c_probe_bus+0x188/0x3d0
[   28.346990]  platform_probe+0x6c/0xc4
[   28.350653]  really_probe+0xcc/0x45c
[   28.354227]  __driver_probe_device+0x8c/0x160
[   28.358578]  driver_probe_device+0x44/0xe0
[   28.362670]  __driver_attach+0x124/0x1d0
[   28.366589]  bus_for_each_dev+0x7c/0xe0
[   28.370426]  driver_attach+0x28/0x30
[   28.373997]  bus_add_driver+0x124/0x240
[   28.377830]  driver_register+0x7c/0x124
[   28.381662]  __platform_driver_register+0x2c/0x34
[   28.386362]  npcm_i2c_init+0x3c/0x5c
[   28.389937]  do_one_initcall+0x74/0x230
[   28.393768]  kernel_init_freeable+0x24c/0x2b4
[   28.398126]  kernel_init+0x28/0x130
[   28.401614]  ret_from_fork+0x10/0x20
[   28.405189] Kernel panic - not syncing: softlockup: hung tasks
[   28.411011] SMP: stopping secondary CPUs
[   28.414933] Kernel Offset: disabled
[   28.418412] CPU features: 0x00000000,00000802
[   28.427644] Rebooting in 20 seconds..</Note>
    </Notes>
    <CVE>CVE-2025-21878</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

uprobes: Reject the shared zeropage in uprobe_write_opcode()

We triggered the following crash in syzkaller tests:

  BUG: Bad page state in process syz.7.38  pfn:1eff3
  page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eff3
  flags: 0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff)
  raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 0000000000000000
  raw: 0000000000000000 0000000000000000 00000000fffffffe 0000000000000000
  page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
  Call Trace:
   &lt;TASK&gt;
   dump_stack_lvl+0x32/0x50
   bad_page+0x69/0xf0
   free_unref_page_prepare+0x401/0x500
   free_unref_page+0x6d/0x1b0
   uprobe_write_opcode+0x460/0x8e0
   install_breakpoint.part.0+0x51/0x80
   register_for_each_vma+0x1d9/0x2b0
   __uprobe_register+0x245/0x300
   bpf_uprobe_multi_link_attach+0x29b/0x4f0
   link_create+0x1e2/0x280
   __sys_bpf+0x75f/0xac0
   __x64_sys_bpf+0x1a/0x30
   do_syscall_64+0x56/0x100
   entry_SYSCALL_64_after_hwframe+0x78/0xe2

   BUG: Bad rss-counter state mm:00000000452453e0 type:MM_FILEPAGES val:-1

The following syzkaller test case can be used to reproduce:

  r2 = creat(&amp;(0x7f0000000000)='./file0\x00', 0x8)
  write$nbd(r2, &amp;(0x7f0000000580)=ANY=[], 0x10)
  r4 = openat(0xffffffffffffff9c, &amp;(0x7f0000000040)='./file0\x00', 0x42, 0x0)
  mmap$IORING_OFF_SQ_RING(&amp;(0x7f0000ffd000/0x3000)=nil, 0x3000, 0x0, 0x12, r4, 0x0)
  r5 = userfaultfd(0x80801)
  ioctl$UFFDIO_API(r5, 0xc018aa3f, &amp;(0x7f0000000040)={0xaa, 0x20})
  r6 = userfaultfd(0x80801)
  ioctl$UFFDIO_API(r6, 0xc018aa3f, &amp;(0x7f0000000140))
  ioctl$UFFDIO_REGISTER(r6, 0xc020aa00, &amp;(0x7f0000000100)={{&amp;(0x7f0000ffc000/0x4000)=nil, 0x4000}, 0x2})
  ioctl$UFFDIO_ZEROPAGE(r5, 0xc020aa04, &amp;(0x7f0000000000)={{&amp;(0x7f0000ffd000/0x1000)=nil, 0x1000}})
  r7 = bpf$PROG_LOAD(0x5, &amp;(0x7f0000000140)={0x2, 0x3, &amp;(0x7f0000000200)=ANY=[@ANYBLOB="1800000000120000000000000000000095"], &amp;(0x7f0000000000)='GPL\x00', 0x7, 0x0, 0x0, 0x0, 0x0, '\x00', 0x0, @fallback=0x30, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, @void, @value}, 0x94)
  bpf$BPF_LINK_CREATE_XDP(0x1c, &amp;(0x7f0000000040)={r7, 0x0, 0x30, 0x1e, @val=@uprobe_multi={&amp;(0x7f0000000080)='./file0\x00', &amp;(0x7f0000000100)=[0x2], 0x0, 0x0, 0x1}}, 0x40)

The cause is that zero pfn is set to the PTE without increasing the RSS
count in mfill_atomic_pte_zeropage() and the refcount of zero folio does
not increase accordingly. Then, the operation on the same pfn is performed
in uprobe_write_opcode()-&gt;__replace_page() to unconditional decrease the
RSS count and old_folio's refcount.

Therefore, two bugs are introduced:

 1. The RSS count is incorrect, when process exit, the check_mm() report
    error "Bad rss-count".

 2. The reserved folio (zero folio) is freed when folio-&gt;refcount is zero,
    then free_pages_prepare-&gt;free_page_is_bad() report error
    "Bad page state".

There is more, the following warning could also theoretically be triggered:

  __replace_page()
    -&gt; ...
      -&gt; folio_remove_rmap_pte()
        -&gt; VM_WARN_ON_FOLIO(is_zero_folio(folio), folio)

Considering that uprobe hit on the zero folio is a very rare case, just
reject zero old folio immediately after get_user_page_vma_remote().

[ mingo: Cleaned up the changelog ]</Note>
    </Notes>
    <CVE>CVE-2025-21881</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ice: Fix deinitializing VF in error path

If ice_ena_vfs() fails after calling ice_create_vf_entries(), it frees
all VFs without removing them from snapshot PF-VF mailbox list, leading
to list corruption.

Reproducer:
  devlink dev eswitch set $PF1_PCI mode switchdev
  ip l s $PF1 up
  ip l s $PF1 promisc on
  sleep 1
  echo 1 &gt; /sys/class/net/$PF1/device/sriov_numvfs
  sleep 1
  echo 1 &gt; /sys/class/net/$PF1/device/sriov_numvfs

Trace (minimized):
  list_add corruption. next-&gt;prev should be prev (ffff8882e241c6f0), but was 0000000000000000. (next=ffff888455da1330).
  kernel BUG at lib/list_debug.c:29!
  RIP: 0010:__list_add_valid_or_report+0xa6/0x100
   ice_mbx_init_vf_info+0xa7/0x180 [ice]
   ice_initialize_vf_entry+0x1fa/0x250 [ice]
   ice_sriov_configure+0x8d7/0x1520 [ice]
   ? __percpu_ref_switch_mode+0x1b1/0x5d0
   ? __pfx_ice_sriov_configure+0x10/0x10 [ice]

Sometimes a KASAN report can be seen instead with a similar stack trace:
  BUG: KASAN: use-after-free in __list_add_valid_or_report+0xf1/0x100

VFs are added to this list in ice_mbx_init_vf_info(), but only removed
in ice_free_vfs(). Move the removing to ice_free_vf_entries(), which is
also being called in other places where VFs are being removed (including
ice_free_vfs() itself).</Note>
    </Notes>
    <CVE>CVE-2025-21883</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net: better track kernel sockets lifetime

While kernel sockets are dismantled during pernet_operations-&gt;exit(),
their freeing can be delayed by any tx packets still held in qdisc
or device queues, due to skb_set_owner_w() prior calls.

This then trigger the following warning from ref_tracker_dir_exit() [1]

To fix this, make sure that kernel sockets own a reference on net-&gt;passive.

Add sk_net_refcnt_upgrade() helper, used whenever a kernel socket
is converted to a refcounted one.

[1]

[  136.263918][   T35] ref_tracker: net notrefcnt@ffff8880638f01e0 has 1/2 users at
[  136.263918][   T35]      sk_alloc+0x2b3/0x370
[  136.263918][   T35]      inet6_create+0x6ce/0x10f0
[  136.263918][   T35]      __sock_create+0x4c0/0xa30
[  136.263918][   T35]      inet_ctl_sock_create+0xc2/0x250
[  136.263918][   T35]      igmp6_net_init+0x39/0x390
[  136.263918][   T35]      ops_init+0x31e/0x590
[  136.263918][   T35]      setup_net+0x287/0x9e0
[  136.263918][   T35]      copy_net_ns+0x33f/0x570
[  136.263918][   T35]      create_new_namespaces+0x425/0x7b0
[  136.263918][   T35]      unshare_nsproxy_namespaces+0x124/0x180
[  136.263918][   T35]      ksys_unshare+0x57d/0xa70
[  136.263918][   T35]      __x64_sys_unshare+0x38/0x40
[  136.263918][   T35]      do_syscall_64+0xf3/0x230
[  136.263918][   T35]      entry_SYSCALL_64_after_hwframe+0x77/0x7f
[  136.263918][   T35]
[  136.343488][   T35] ref_tracker: net notrefcnt@ffff8880638f01e0 has 1/2 users at
[  136.343488][   T35]      sk_alloc+0x2b3/0x370
[  136.343488][   T35]      inet6_create+0x6ce/0x10f0
[  136.343488][   T35]      __sock_create+0x4c0/0xa30
[  136.343488][   T35]      inet_ctl_sock_create+0xc2/0x250
[  136.343488][   T35]      ndisc_net_init+0xa7/0x2b0
[  136.343488][   T35]      ops_init+0x31e/0x590
[  136.343488][   T35]      setup_net+0x287/0x9e0
[  136.343488][   T35]      copy_net_ns+0x33f/0x570
[  136.343488][   T35]      create_new_namespaces+0x425/0x7b0
[  136.343488][   T35]      unshare_nsproxy_namespaces+0x124/0x180
[  136.343488][   T35]      ksys_unshare+0x57d/0xa70
[  136.343488][   T35]      __x64_sys_unshare+0x38/0x40
[  136.343488][   T35]      do_syscall_64+0xf3/0x230
[  136.343488][   T35]      entry_SYSCALL_64_after_hwframe+0x77/0x7f</Note>
    </Notes>
    <CVE>CVE-2025-21884</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

RDMA/bnxt_re: Fix the page details for the srq created by kernel consumers

While using nvme target with use_srq on, below kernel panic is noticed.

[  549.698111] bnxt_en 0000:41:00.0 enp65s0np0: FEC autoneg off encoding: Clause 91 RS(544,514)
[  566.393619] Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI
..
[  566.393799]  &lt;TASK&gt;
[  566.393807]  ? __die_body+0x1a/0x60
[  566.393823]  ? die+0x38/0x60
[  566.393835]  ? do_trap+0xe4/0x110
[  566.393847]  ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re]
[  566.393867]  ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re]
[  566.393881]  ? do_error_trap+0x7c/0x120
[  566.393890]  ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re]
[  566.393911]  ? exc_divide_error+0x34/0x50
[  566.393923]  ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re]
[  566.393939]  ? asm_exc_divide_error+0x16/0x20
[  566.393966]  ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re]
[  566.393997]  bnxt_qplib_create_srq+0xc9/0x340 [bnxt_re]
[  566.394040]  bnxt_re_create_srq+0x335/0x3b0 [bnxt_re]
[  566.394057]  ? srso_return_thunk+0x5/0x5f
[  566.394068]  ? __init_swait_queue_head+0x4a/0x60
[  566.394090]  ib_create_srq_user+0xa7/0x150 [ib_core]
[  566.394147]  nvmet_rdma_queue_connect+0x7d0/0xbe0 [nvmet_rdma]
[  566.394174]  ? lock_release+0x22c/0x3f0
[  566.394187]  ? srso_return_thunk+0x5/0x5f

Page size and shift info is set only for the user space SRQs.
Set page size and page shift for kernel space SRQs also.</Note>
    </Notes>
    <CVE>CVE-2025-21885</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

RDMA/mlx5: Fix implicit ODP hang on parent deregistration

Fix the destroy_unused_implicit_child_mr() to prevent hanging during
parent deregistration as of below [1].

Upon entering destroy_unused_implicit_child_mr(), the reference count
for the implicit MR parent is incremented using:
refcount_inc_not_zero().

A corresponding decrement must be performed if
free_implicit_child_mr_work() is not called.

The code has been updated to properly manage the reference count that
was incremented.

[1]
INFO: task python3:2157 blocked for more than 120 seconds.
Not tainted 6.12.0-rc7+ #1633
"echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:python3         state:D stack:0     pid:2157 tgid:2157  ppid:1685   flags:0x00000000
Call Trace:
&lt;TASK&gt;
__schedule+0x420/0xd30
schedule+0x47/0x130
__mlx5_ib_dereg_mr+0x379/0x5d0 [mlx5_ib]
? __pfx_autoremove_wake_function+0x10/0x10
ib_dereg_mr_user+0x5f/0x120 [ib_core]
? lock_release+0xc6/0x280
destroy_hw_idr_uobject+0x1d/0x60 [ib_uverbs]
uverbs_destroy_uobject+0x58/0x1d0 [ib_uverbs]
uobj_destroy+0x3f/0x70 [ib_uverbs]
ib_uverbs_cmd_verbs+0x3e4/0xbb0 [ib_uverbs]
? __pfx_uverbs_destroy_def_handler+0x10/0x10 [ib_uverbs]
? lock_acquire+0xc1/0x2f0
? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]
? ib_uverbs_ioctl+0x116/0x170 [ib_uverbs]
? lock_release+0xc6/0x280
ib_uverbs_ioctl+0xe7/0x170 [ib_uverbs]
? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]
 __x64_sys_ioctl+0x1b0/0xa70
? kmem_cache_free+0x221/0x400
do_syscall_64+0x6b/0x140
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7f20f21f017b
RSP: 002b:00007ffcfc4a77c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007ffcfc4a78d8 RCX: 00007f20f21f017b
RDX: 00007ffcfc4a78c0 RSI: 00000000c0181b01 RDI: 0000000000000003
RBP: 00007ffcfc4a78a0 R08: 000056147d125190 R09: 00007f20f1f14c60
R10: 0000000000000001 R11: 0000000000000246 R12: 00007ffcfc4a7890
R13: 000000000000001c R14: 000056147d100fc0 R15: 00007f20e365c9d0
&lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2025-21886</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up

The issue was caused by dput(upper) being called before
ovl_dentry_update_reval(), while upper-&gt;d_flags was still
accessed in ovl_dentry_remote().

Move dput(upper) after its last use to prevent use-after-free.

BUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline]
BUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167

Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114
 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
 ovl_dentry_remote fs/overlayfs/util.c:162 [inline]
 ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167
 ovl_link_up fs/overlayfs/copy_up.c:610 [inline]
 ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170
 ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223
 ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136
 vfs_rename+0xf84/0x20a0 fs/namei.c:4893
...
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2025-21887</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

RDMA/mlx5: Fix a WARN during dereg_mr for DM type

Memory regions (MR) of type DM (device memory) do not have an associated
umem.

In the __mlx5_ib_dereg_mr() -&gt; mlx5_free_priv_descs() flow, the code
incorrectly takes the wrong branch, attempting to call
dma_unmap_single() on a DMA address that is not mapped.

This results in a WARN [1], as shown below.

The issue is resolved by properly accounting for the DM type and
ensuring the correct branch is selected in mlx5_free_priv_descs().

[1]
WARNING: CPU: 12 PID: 1346 at drivers/iommu/dma-iommu.c:1230 iommu_dma_unmap_page+0x79/0x90
Modules linked in: ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry ovelay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core fuse mlx5_core
CPU: 12 UID: 0 PID: 1346 Comm: ibv_rc_pingpong Not tainted 6.12.0-rc7+ #1631
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:iommu_dma_unmap_page+0x79/0x90
Code: 2b 49 3b 29 72 26 49 3b 69 08 73 20 4d 89 f0 44 89 e9 4c 89 e2 48 89 ee 48 89 df 5b 5d 41 5c 41 5d 41 5e 41 5f e9 07 b8 88 ff &lt;0f&gt; 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 66 0f 1f 44 00
RSP: 0018:ffffc90001913a10 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff88810194b0a8 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001
RBP: ffff88810194b0a8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
FS:  00007f537abdd740(0000) GS:ffff88885fb00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f537aeb8000 CR3: 000000010c248001 CR4: 0000000000372eb0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
&lt;TASK&gt;
? __warn+0x84/0x190
? iommu_dma_unmap_page+0x79/0x90
? report_bug+0xf8/0x1c0
? handle_bug+0x55/0x90
? exc_invalid_op+0x13/0x60
? asm_exc_invalid_op+0x16/0x20
? iommu_dma_unmap_page+0x79/0x90
dma_unmap_page_attrs+0xe6/0x290
mlx5_free_priv_descs+0xb0/0xe0 [mlx5_ib]
__mlx5_ib_dereg_mr+0x37e/0x520 [mlx5_ib]
? _raw_spin_unlock_irq+0x24/0x40
? wait_for_completion+0xfe/0x130
? rdma_restrack_put+0x63/0xe0 [ib_core]
ib_dereg_mr_user+0x5f/0x120 [ib_core]
? lock_release+0xc6/0x280
destroy_hw_idr_uobject+0x1d/0x60 [ib_uverbs]
uverbs_destroy_uobject+0x58/0x1d0 [ib_uverbs]
uobj_destroy+0x3f/0x70 [ib_uverbs]
ib_uverbs_cmd_verbs+0x3e4/0xbb0 [ib_uverbs]
? __pfx_uverbs_destroy_def_handler+0x10/0x10 [ib_uverbs]
? lock_acquire+0xc1/0x2f0
? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]
? ib_uverbs_ioctl+0x116/0x170 [ib_uverbs]
? lock_release+0xc6/0x280
ib_uverbs_ioctl+0xe7/0x170 [ib_uverbs]
? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]
__x64_sys_ioctl+0x1b0/0xa70
do_syscall_64+0x6b/0x140
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7f537adaf17b
Code: 0f 1e fa 48 8b 05 1d ad 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d ed ac 0c 00 f7 d8 64 89 01 48
RSP: 002b:00007ffff218f0b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007ffff218f1d8 RCX: 00007f537adaf17b
RDX: 00007ffff218f1c0 RSI: 00000000c0181b01 RDI: 0000000000000003
RBP: 00007ffff218f1a0 R08: 00007f537aa8d010 R09: 0000561ee2e4f270
R10: 00007f537aace3a8 R11: 0000000000000246 R12: 00007ffff218f190
R13: 000000000000001c R14: 0000561ee2e4d7c0 R15: 00007ffff218f450
&lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2025-21888</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

perf/core: Add RCU read lock protection to perf_iterate_ctx()

The perf_iterate_ctx() function performs RCU list traversal but
currently lacks RCU read lock protection. This causes lockdep warnings
when running perf probe with unshare(1) under CONFIG_PROVE_RCU_LIST=y:

	WARNING: suspicious RCU usage
	kernel/events/core.c:8168 RCU-list traversed in non-reader section!!

	 Call Trace:
	  lockdep_rcu_suspicious
	  ? perf_event_addr_filters_apply
	  perf_iterate_ctx
	  perf_event_exec
	  begin_new_exec
	  ? load_elf_phdrs
	  load_elf_binary
	  ? lock_acquire
	  ? find_held_lock
	  ? bprm_execve
	  bprm_execve
	  do_execveat_common.isra.0
	  __x64_sys_execve
	  do_syscall_64
	  entry_SYSCALL_64_after_hwframe

This protection was previously present but was removed in commit
bd2756811766 ("perf: Rewrite core context handling"). Add back the
necessary rcu_read_lock()/rcu_read_unlock() pair around
perf_iterate_ctx() call in perf_event_exec().

[ mingo: Use scoped_guard() as suggested by Peter ]</Note>
    </Notes>
    <CVE>CVE-2025-21889</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

idpf: fix checksums set in idpf_rx_rsc()

idpf_rx_rsc() uses skb_transport_offset(skb) while the transport header
is not set yet.

This triggers the following warning for CONFIG_DEBUG_NET=y builds.

DEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb))

[   69.261620] WARNING: CPU: 7 PID: 0 at ./include/linux/skbuff.h:3020 idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf
[   69.261629] Modules linked in: vfat fat dummy bridge intel_uncore_frequency_tpmi intel_uncore_frequency_common intel_vsec_tpmi idpf intel_vsec cdc_ncm cdc_eem cdc_ether usbnet mii xhci_pci xhci_hcd ehci_pci ehci_hcd libeth
[   69.261644] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Tainted: G S      W          6.14.0-smp-DEV #1697
[   69.261648] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN
[   69.261650] RIP: 0010:idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf
[   69.261677] ? __warn (kernel/panic.c:242 kernel/panic.c:748)
[   69.261682] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf
[   69.261687] ? report_bug (lib/bug.c:?)
[   69.261690] ? handle_bug (arch/x86/kernel/traps.c:285)
[   69.261694] ? exc_invalid_op (arch/x86/kernel/traps.c:309)
[   69.261697] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621)
[   69.261700] ? __pfx_idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:4011) idpf
[   69.261704] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf
[   69.261708] ? idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:3072) idpf
[   69.261712] __napi_poll (net/core/dev.c:7194)
[   69.261716] net_rx_action (net/core/dev.c:7265)
[   69.261718] ? __qdisc_run (net/sched/sch_generic.c:293)
[   69.261721] ? sched_clock (arch/x86/include/asm/preempt.h:84 arch/x86/kernel/tsc.c:288)
[   69.261726] handle_softirqs (kernel/softirq.c:561)</Note>
    </Notes>
    <CVE>CVE-2025-21890</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ipvlan: ensure network headers are in skb linear part

syzbot found that ipvlan_process_v6_outbound() was assuming
the IPv6 network header isis present in skb-&gt;head [1]

Add the needed pskb_network_may_pull() calls for both
IPv4 and IPv6 handlers.

[1]
BUG: KMSAN: uninit-value in __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47
  __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47
  ipv6_addr_type include/net/ipv6.h:555 [inline]
  ip6_route_output_flags_noref net/ipv6/route.c:2616 [inline]
  ip6_route_output_flags+0x51/0x720 net/ipv6/route.c:2651
  ip6_route_output include/net/ip6_route.h:93 [inline]
  ipvlan_route_v6_outbound+0x24e/0x520 drivers/net/ipvlan/ipvlan_core.c:476
  ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:491 [inline]
  ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:541 [inline]
  ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:605 [inline]
  ipvlan_queue_xmit+0xd72/0x1780 drivers/net/ipvlan/ipvlan_core.c:671
  ipvlan_start_xmit+0x5b/0x210 drivers/net/ipvlan/ipvlan_main.c:223
  __netdev_start_xmit include/linux/netdevice.h:5150 [inline]
  netdev_start_xmit include/linux/netdevice.h:5159 [inline]
  xmit_one net/core/dev.c:3735 [inline]
  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3751
  sch_direct_xmit+0x399/0xd40 net/sched/sch_generic.c:343
  qdisc_restart net/sched/sch_generic.c:408 [inline]
  __qdisc_run+0x14da/0x35d0 net/sched/sch_generic.c:416
  qdisc_run+0x141/0x4d0 include/net/pkt_sched.h:127
  net_tx_action+0x78b/0x940 net/core/dev.c:5484
  handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561
  __do_softirq+0x14/0x1a kernel/softirq.c:595
  do_softirq+0x9a/0x100 kernel/softirq.c:462
  __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389
  local_bh_enable include/linux/bottom_half.h:33 [inline]
  rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]
  __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4611
  dev_queue_xmit include/linux/netdevice.h:3311 [inline]
  packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276
  packet_snd net/packet/af_packet.c:3132 [inline]
  packet_sendmsg+0x93e0/0xa7e0 net/packet/af_packet.c:3164
  sock_sendmsg_nosec net/socket.c:718 [inline]</Note>
    </Notes>
    <CVE>CVE-2025-21891</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

RDMA/mlx5: Fix the recovery flow of the UMR QP

This patch addresses an issue in the recovery flow of the UMR QP,
ensuring tasks do not get stuck, as highlighted by the call trace [1].

During recovery, before transitioning the QP to the RESET state, the
software must wait for all outstanding WRs to complete.

Failing to do so can cause the firmware to skip sending some flushed
CQEs with errors and simply discard them upon the RESET, as per the IB
specification.

This race condition can result in lost CQEs and tasks becoming stuck.

To resolve this, the patch sends a final WR which serves only as a
barrier before moving the QP state to RESET.

Once a CQE is received for that final WR, it guarantees that no
outstanding WRs remain, making it safe to transition the QP to RESET and
subsequently back to RTS, restoring proper functionality.

Note:
For the barrier WR, we simply reuse the failed and ready WR.
Since the QP is in an error state, it will only receive
IB_WC_WR_FLUSH_ERR. However, as it serves only as a barrier we don't
care about its status.

[1]
INFO: task rdma_resource_l:1922 blocked for more than 120 seconds.
Tainted: G        W          6.12.0-rc7+ #1626
"echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:rdma_resource_l state:D stack:0  pid:1922 tgid:1922  ppid:1369
     flags:0x00004004
Call Trace:
&lt;TASK&gt;
__schedule+0x420/0xd30
schedule+0x47/0x130
schedule_timeout+0x280/0x300
? mark_held_locks+0x48/0x80
? lockdep_hardirqs_on_prepare+0xe5/0x1a0
wait_for_completion+0x75/0x130
mlx5r_umr_post_send_wait+0x3c2/0x5b0 [mlx5_ib]
? __pfx_mlx5r_umr_done+0x10/0x10 [mlx5_ib]
mlx5r_umr_revoke_mr+0x93/0xc0 [mlx5_ib]
__mlx5_ib_dereg_mr+0x299/0x520 [mlx5_ib]
? _raw_spin_unlock_irq+0x24/0x40
? wait_for_completion+0xfe/0x130
? rdma_restrack_put+0x63/0xe0 [ib_core]
ib_dereg_mr_user+0x5f/0x120 [ib_core]
? lock_release+0xc6/0x280
destroy_hw_idr_uobject+0x1d/0x60 [ib_uverbs]
uverbs_destroy_uobject+0x58/0x1d0 [ib_uverbs]
uobj_destroy+0x3f/0x70 [ib_uverbs]
ib_uverbs_cmd_verbs+0x3e4/0xbb0 [ib_uverbs]
? __pfx_uverbs_destroy_def_handler+0x10/0x10 [ib_uverbs]
? __lock_acquire+0x64e/0x2080
? mark_held_locks+0x48/0x80
? find_held_lock+0x2d/0xa0
? lock_acquire+0xc1/0x2f0
? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]
? __fget_files+0xc3/0x1b0
ib_uverbs_ioctl+0xe7/0x170 [ib_uverbs]
? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]
__x64_sys_ioctl+0x1b0/0xa70
do_syscall_64+0x6b/0x140
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7f99c918b17b
RSP: 002b:00007ffc766d0468 EFLAGS: 00000246 ORIG_RAX:
     0000000000000010
RAX: ffffffffffffffda RBX: 00007ffc766d0578 RCX:
     00007f99c918b17b
RDX: 00007ffc766d0560 RSI: 00000000c0181b01 RDI:
     0000000000000003
RBP: 00007ffc766d0540 R08: 00007f99c8f99010 R09:
     000000000000bd7e
R10: 00007f99c94c1c70 R11: 0000000000000246 R12:
     00007ffc766d0530
R13: 000000000000001c R14: 0000000040246a80 R15:
     0000000000000000
&lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2025-21892</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net: enetc: VFs do not support HWTSTAMP_TX_ONESTEP_SYNC

Actually ENETC VFs do not support HWTSTAMP_TX_ONESTEP_SYNC because only
ENETC PF can access PMa_SINGLE_STEP registers. And there will be a crash
if VFs are used to test one-step timestamp, the crash log as follows.

[  129.110909] Unable to handle kernel paging request at virtual address 00000000000080c0
[  129.287769] Call trace:
[  129.290219]  enetc_port_mac_wr+0x30/0xec (P)
[  129.294504]  enetc_start_xmit+0xda4/0xe74
[  129.298525]  enetc_xmit+0x70/0xec
[  129.301848]  dev_hard_start_xmit+0x98/0x118</Note>
    </Notes>
    <CVE>CVE-2025-21894</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

perf/core: Order the PMU list to fix warning about unordered pmu_ctx_list

Syskaller triggers a warning due to prev_epc-&gt;pmu != next_epc-&gt;pmu in
perf_event_swap_task_ctx_data(). vmcore shows that two lists have the same
perf_event_pmu_context, but not in the same order.

The problem is that the order of pmu_ctx_list for the parent is impacted by
the time when an event/PMU is added. While the order for a child is
impacted by the event order in the pinned_groups and flexible_groups. So
the order of pmu_ctx_list in the parent and child may be different.

To fix this problem, insert the perf_event_pmu_context to its proper place
after iteration of the pmu_ctx_list.

The follow testcase can trigger above warning:

 # perf record -e cycles --call-graph lbr -- taskset -c 3 ./a.out &amp;
 # perf stat -e cpu-clock,cs -p xxx // xxx is the pid of a.out

 test.c

 void main() {
        int count = 0;
        pid_t pid;

        printf("%d running\n", getpid());
        sleep(30);
        printf("running\n");

        pid = fork();
        if (pid == -1) {
                printf("fork error\n");
                return;
        }
        if (pid == 0) {
                while (1) {
                        count++;
                }
        } else {
                while (1) {
                        count++;
                }
        }
 }

The testcase first opens an LBR event, so it will allocate task_ctx_data,
and then open tracepoint and software events, so the parent context will
have 3 different perf_event_pmu_contexts. On inheritance, child ctx will
insert the perf_event_pmu_context in another order and the warning will
trigger.

[ mingo: Tidied up the changelog. ]</Note>
    </Notes>
    <CVE>CVE-2025-21895</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

caif_virtio: fix wrong pointer check in cfv_probe()

del_vqs() frees virtqueues, therefore cfv-&gt;vq_tx pointer should be checked
for NULL before calling it, not cfv-&gt;vdev. Also the current implementation
is redundant because the pointer cfv-&gt;vdev is dereferenced before it is
checked for NULL.

Fix this by checking cfv-&gt;vq_tx for NULL instead of cfv-&gt;vdev before
calling del_vqs().</Note>
    </Notes>
    <CVE>CVE-2025-21904</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

wifi: iwlwifi: limit printed string from FW file

There's no guarantee here that the file is always with a
NUL-termination, so reading the string may read beyond the
end of the TLV. If that's the last TLV in the file, it can
perhaps even read beyond the end of the file buffer.

Fix that by limiting the print format to the size of the
buffer we have.</Note>
    </Notes>
    <CVE>CVE-2025-21905</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

wifi: iwlwifi: mvm: clean up ROC on failure

If the firmware fails to start the session protection, then we
do call iwl_mvm_roc_finished() here, but that won't do anything
at all because IWL_MVM_STATUS_ROC_P2P_RUNNING was never set.
Set IWL_MVM_STATUS_ROC_P2P_RUNNING in the failure/stop path.
If it started successfully before, it's already set, so that
doesn't matter, and if it didn't start it needs to be set to
clean up.

Not doing so will lead to a WARN_ON() later on a fresh remain-
on-channel, since the link is already active when activated as
it was never deactivated.</Note>
    </Notes>
    <CVE>CVE-2025-21906</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

NFS: fix nfs_release_folio() to not deadlock via kcompactd writeback

Add PF_KCOMPACTD flag and current_is_kcompactd() helper to check for it so
nfs_release_folio() can skip calling nfs_wb_folio() from kcompactd.

Otherwise NFS can deadlock waiting for kcompactd enduced writeback which
recurses back to NFS (which triggers writeback to NFSD via NFS loopback
mount on the same host, NFSD blocks waiting for XFS's call to
__filemap_get_folio):

6070.550357] INFO: task kcompactd0:58 blocked for more than 4435 seconds.

{---
[58] "kcompactd0"
[&lt;0&gt;] folio_wait_bit+0xe8/0x200
[&lt;0&gt;] folio_wait_writeback+0x2b/0x80
[&lt;0&gt;] nfs_wb_folio+0x80/0x1b0 [nfs]
[&lt;0&gt;] nfs_release_folio+0x68/0x130 [nfs]
[&lt;0&gt;] split_huge_page_to_list_to_order+0x362/0x840
[&lt;0&gt;] migrate_pages_batch+0x43d/0xb90
[&lt;0&gt;] migrate_pages_sync+0x9a/0x240
[&lt;0&gt;] migrate_pages+0x93c/0x9f0
[&lt;0&gt;] compact_zone+0x8e2/0x1030
[&lt;0&gt;] compact_node+0xdb/0x120
[&lt;0&gt;] kcompactd+0x121/0x2e0
[&lt;0&gt;] kthread+0xcf/0x100
[&lt;0&gt;] ret_from_fork+0x31/0x40
[&lt;0&gt;] ret_from_fork_asm+0x1a/0x30
---}

[akpm@linux-foundation.org: fix build]</Note>
    </Notes>
    <CVE>CVE-2025-21908</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

wifi: nl80211: reject cooked mode if it is set along with other flags

It is possible to set both MONITOR_FLAG_COOK_FRAMES and MONITOR_FLAG_ACTIVE
flags simultaneously on the same monitor interface from the userspace. This
causes a sub-interface to be created with no IEEE80211_SDATA_IN_DRIVER bit
set because the monitor interface is in the cooked state and it takes
precedence over all other states. When the interface is then being deleted
the kernel calls WARN_ONCE() from check_sdata_in_driver() because of missing
that bit.

Fix this by rejecting MONITOR_FLAG_COOK_FRAMES if it is set along with
other flags.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.</Note>
    </Notes>
    <CVE>CVE-2025-21909</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

wifi: cfg80211: regulatory: improve invalid hints checking

Syzbot keeps reporting an issue [1] that occurs when erroneous symbols
sent from userspace get through into user_alpha2[] via
regulatory_hint_user() call. Such invalid regulatory hints should be
rejected.

While a sanity check from commit 47caf685a685 ("cfg80211: regulatory:
reject invalid hints") looks to be enough to deter these very cases,
there is a way to get around it due to 2 reasons.

1) The way isalpha() works, symbols other than latin lower and
upper letters may be used to determine a country/domain.
For instance, greek letters will also be considered upper/lower
letters and for such characters isalpha() will return true as well.
However, ISO-3166-1 alpha2 codes should only hold latin
characters.

2) While processing a user regulatory request, between
reg_process_hint_user() and regulatory_hint_user() there happens to
be a call to queue_regulatory_request() which modifies letters in
request-&gt;alpha2[] with toupper(). This works fine for latin symbols,
less so for weird letter characters from the second part of _ctype[].

Syzbot triggers a warning in is_user_regdom_saved() by first sending
over an unexpected non-latin letter that gets malformed by toupper()
into a character that ends up failing isalpha() check.

Prevent this by enhancing is_an_alpha2() to ensure that incoming
symbols are latin letters and nothing else.

[1] Syzbot report:
------------[ cut here ]------------
Unexpected user alpha2: A�
WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 is_user_regdom_saved net/wireless/reg.c:440 [inline]
WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_alpha2 net/wireless/reg.c:3424 [inline]
WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516
Modules linked in:
CPU: 1 UID: 0 PID: 964 Comm: kworker/1:2 Not tainted 6.12.0-rc5-syzkaller-00044-gc1e939a21eb1 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Workqueue: events_power_efficient crda_timeout_work
RIP: 0010:is_user_regdom_saved net/wireless/reg.c:440 [inline]
RIP: 0010:restore_alpha2 net/wireless/reg.c:3424 [inline]
RIP: 0010:restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516
...
Call Trace:
 &lt;TASK&gt;
 crda_timeout_work+0x27/0x50 net/wireless/reg.c:542
 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;</Note>
    </Notes>
    <CVE>CVE-2025-21910</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

gpio: rcar: Use raw_spinlock to protect register access

Use raw_spinlock in order to fix spurious messages about invalid context
when spinlock debugging is enabled. The lock is only used to serialize
register access.

    [    4.239592] =============================
    [    4.239595] [ BUG: Invalid wait context ]
    [    4.239599] 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35 Not tainted
    [    4.239603] -----------------------------
    [    4.239606] kworker/u8:5/76 is trying to lock:
    [    4.239609] ffff0000091898a0 (&amp;p-&gt;lock){....}-{3:3}, at: gpio_rcar_config_interrupt_input_mode+0x34/0x164
    [    4.239641] other info that might help us debug this:
    [    4.239643] context-{5:5}
    [    4.239646] 5 locks held by kworker/u8:5/76:
    [    4.239651]  #0: ffff0000080fb148 ((wq_completion)async){+.+.}-{0:0}, at: process_one_work+0x190/0x62c
    [    4.250180] OF: /soc/sound@ec500000/ports/port@0/endpoint: Read of boolean property 'frame-master' with a value.
    [    4.254094]  #1: ffff80008299bd80 ((work_completion)(&amp;entry-&gt;work)){+.+.}-{0:0}, at: process_one_work+0x1b8/0x62c
    [    4.254109]  #2: ffff00000920c8f8
    [    4.258345] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property 'bitclock-master' with a value.
    [    4.264803]  (&amp;dev-&gt;mutex){....}-{4:4}, at: __device_attach_async_helper+0x3c/0xdc
    [    4.264820]  #3: ffff00000a50ca40 (request_class#2){+.+.}-{4:4}, at: __setup_irq+0xa0/0x690
    [    4.264840]  #4:
    [    4.268872] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property 'frame-master' with a value.
    [    4.273275] ffff00000a50c8c8 (lock_class){....}-{2:2}, at: __setup_irq+0xc4/0x690
    [    4.296130] renesas_sdhi_internal_dmac ee100000.mmc: mmc1 base at 0x00000000ee100000, max clock rate 200 MHz
    [    4.304082] stack backtrace:
    [    4.304086] CPU: 1 UID: 0 PID: 76 Comm: kworker/u8:5 Not tainted 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35
    [    4.304092] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT)
    [    4.304097] Workqueue: async async_run_entry_fn
    [    4.304106] Call trace:
    [    4.304110]  show_stack+0x14/0x20 (C)
    [    4.304122]  dump_stack_lvl+0x6c/0x90
    [    4.304131]  dump_stack+0x14/0x1c
    [    4.304138]  __lock_acquire+0xdfc/0x1584
    [    4.426274]  lock_acquire+0x1c4/0x33c
    [    4.429942]  _raw_spin_lock_irqsave+0x5c/0x80
    [    4.434307]  gpio_rcar_config_interrupt_input_mode+0x34/0x164
    [    4.440061]  gpio_rcar_irq_set_type+0xd4/0xd8
    [    4.444422]  __irq_set_trigger+0x5c/0x178
    [    4.448435]  __setup_irq+0x2e4/0x690
    [    4.452012]  request_threaded_irq+0xc4/0x190
    [    4.456285]  devm_request_threaded_irq+0x7c/0xf4
    [    4.459398] ata1: link resume succeeded after 1 retries
    [    4.460902]  mmc_gpiod_request_cd_irq+0x68/0xe0
    [    4.470660]  mmc_start_host+0x50/0xac
    [    4.474327]  mmc_add_host+0x80/0xe4
    [    4.477817]  tmio_mmc_host_probe+0x2b0/0x440
    [    4.482094]  renesas_sdhi_probe+0x488/0x6f4
    [    4.486281]  renesas_sdhi_internal_dmac_probe+0x60/0x78
    [    4.491509]  platform_probe+0x64/0xd8
    [    4.495178]  really_probe+0xb8/0x2a8
    [    4.498756]  __driver_probe_device+0x74/0x118
    [    4.503116]  driver_probe_device+0x3c/0x154
    [    4.507303]  __device_attach_driver+0xd4/0x160
    [    4.511750]  bus_for_each_drv+0x84/0xe0
    [    4.515588]  __device_attach_async_helper+0xb0/0xdc
    [    4.520470]  async_run_entry_fn+0x30/0xd8
    [    4.524481]  process_one_work+0x210/0x62c
    [    4.528494]  worker_thread+0x1ac/0x340
    [    4.532245]  kthread+0x10c/0x110
    [    4.535476]  ret_from_fork+0x10/0x20</Note>
    </Notes>
    <CVE>CVE-2025-21912</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

x86/amd_nb: Use rdmsr_safe() in amd_get_mmconfig_range()

Xen doesn't offer MSR_FAM10H_MMIO_CONF_BASE to all guests.  This results
in the following warning:

  unchecked MSR access error: RDMSR from 0xc0010058 at rIP: 0xffffffff8101d19f (xen_do_read_msr+0x7f/0xa0)
  Call Trace:
   xen_read_msr+0x1e/0x30
   amd_get_mmconfig_range+0x2b/0x80
   quirk_amd_mmconfig_area+0x28/0x100
   pnp_fixup_device+0x39/0x50
   __pnp_add_device+0xf/0x150
   pnp_add_device+0x3d/0x100
   pnpacpi_add_device_handler+0x1f9/0x280
   acpi_ns_get_device_callback+0x104/0x1c0
   acpi_ns_walk_namespace+0x1d0/0x260
   acpi_get_devices+0x8a/0xb0
   pnpacpi_init+0x50/0x80
   do_one_initcall+0x46/0x2e0
   kernel_init_freeable+0x1da/0x2f0
   kernel_init+0x16/0x1b0
   ret_from_fork+0x30/0x50
   ret_from_fork_asm+0x1b/0x30

based on quirks for a "PNP0c01" device.  Treating MMCFG as disabled is the
right course of action, so no change is needed there.

This was most likely exposed by fixing the Xen MSR accessors to not be
silently-safe.</Note>
    </Notes>
    <CVE>CVE-2025-21913</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

slimbus: messaging: Free transaction ID in delayed interrupt scenario

In case of interrupt delay for any reason, slim_do_transfer()
returns timeout error but the transaction ID (TID) is not freed.
This results into invalid memory access inside
qcom_slim_ngd_rx_msgq_cb() due to invalid TID.

Fix the issue by freeing the TID in slim_do_transfer() before
returning timeout error to avoid invalid memory access.

Call trace:
__memcpy_fromio+0x20/0x190
qcom_slim_ngd_rx_msgq_cb+0x130/0x290 [slim_qcom_ngd_ctrl]
vchan_complete+0x2a0/0x4a0
tasklet_action_common+0x274/0x700
tasklet_action+0x28/0x3c
_stext+0x188/0x620
run_ksoftirqd+0x34/0x74
smpboot_thread_fn+0x1d8/0x464
kthread+0x178/0x238
ret_from_fork+0x10/0x20
Code: aa0003e8 91000429 f100044a 3940002b (3800150b)
---[ end trace 0fe00bec2b975c99 ]---
Kernel panic - not syncing: Oops: Fatal exception in interrupt.</Note>
    </Notes>
    <CVE>CVE-2025-21914</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

cdx: Fix possible UAF error in driver_override_show()

Fixed a possible UAF problem in driver_override_show() in drivers/cdx/cdx.c

This function driver_override_show() is part of DEVICE_ATTR_RW, which
includes both driver_override_show() and driver_override_store().
These functions can be executed concurrently in sysfs.

The driver_override_store() function uses driver_set_override() to
update the driver_override value, and driver_set_override() internally
locks the device (device_lock(dev)). If driver_override_show() reads
cdx_dev-&gt;driver_override without locking, it could potentially access
a freed pointer if driver_override_store() frees the string
concurrently. This could lead to printing a kernel address, which is a
security risk since DEVICE_ATTR can be read by all users.

Additionally, a similar pattern is used in drivers/amba/bus.c, as well
as many other bus drivers, where device_lock() is taken in the show
function, and it has been working without issues.

This potential bug was detected by our experimental static analysis
tool, which analyzes locking APIs and paired functions to identify
data races and atomicity violations.</Note>
    </Notes>
    <CVE>CVE-2025-21915</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

usb: atm: cxacru: fix a flaw in existing endpoint checks

Syzbot once again identified a flaw in usb endpoint checking, see [1].
This time the issue stems from a commit authored by me (2eabb655a968
("usb: atm: cxacru: fix endpoint checking in cxacru_bind()")).

While using usb_find_common_endpoints() may usually be enough to
discard devices with wrong endpoints, in this case one needs more
than just finding and identifying the sufficient number of endpoints
of correct types - one needs to check the endpoint's address as well.

Since cxacru_bind() fills URBs with CXACRU_EP_CMD address in mind,
switch the endpoint verification approach to usb_check_XXX_endpoints()
instead to fix incomplete ep testing.

[1] Syzbot report:
usb 5-1: BOGUS urb xfer, pipe 3 != type 1
WARNING: CPU: 0 PID: 1378 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503
...
RIP: 0010:usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503
...
Call Trace:
 &lt;TASK&gt;
 cxacru_cm+0x3c8/0xe50 drivers/usb/atm/cxacru.c:649
 cxacru_card_status drivers/usb/atm/cxacru.c:760 [inline]
 cxacru_bind+0xcf9/0x1150 drivers/usb/atm/cxacru.c:1223
 usbatm_usb_probe+0x314/0x1d30 drivers/usb/atm/usbatm.c:1058
 cxacru_usb_probe+0x184/0x220 drivers/usb/atm/cxacru.c:1377
 usb_probe_interface+0x641/0xbb0 drivers/usb/core/driver.c:396
 really_probe+0x2b9/0xad0 drivers/base/dd.c:658
 __driver_probe_device+0x1a2/0x390 drivers/base/dd.c:800
 driver_probe_device+0x50/0x430 drivers/base/dd.c:830
...</Note>
    </Notes>
    <CVE>CVE-2025-21916</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

usb: renesas_usbhs: Flush the notify_hotplug_work

When performing continuous unbind/bind operations on the USB drivers
available on the Renesas RZ/G2L SoC, a kernel crash with the message
"Unable to handle kernel NULL pointer dereference at virtual address"
may occur. This issue points to the usbhsc_notify_hotplug() function.

Flush the delayed work to avoid its execution when driver resources are
unavailable.</Note>
    </Notes>
    <CVE>CVE-2025-21917</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

usb: typec: ucsi: Fix NULL pointer access

Resources should be released only after all threads that utilize them
have been destroyed.
This commit ensures that resources are not released prematurely by waiting
for the associated workqueue to complete before deallocating them.</Note>
    </Notes>
    <CVE>CVE-2025-21918</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ppp: Fix KMSAN uninit-value warning with bpf

Syzbot caught an "KMSAN: uninit-value" warning [1], which is caused by the
ppp driver not initializing a 2-byte header when using socket filter.

The following code can generate a PPP filter BPF program:
'''
struct bpf_program fp;
pcap_t *handle;
handle = pcap_open_dead(DLT_PPP_PPPD, 65535);
pcap_compile(handle, &amp;fp, "ip and outbound", 0, 0);
bpf_dump(&amp;fp, 1);
'''
Its output is:
'''
(000) ldh [2]
(001) jeq #0x21 jt 2 jf 5
(002) ldb [0]
(003) jeq #0x1 jt 4 jf 5
(004) ret #65535
(005) ret #0
'''
Wen can find similar code at the following link:
https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680
The maintainer of this code repository is also the original maintainer
of the ppp driver.

As you can see the BPF program skips 2 bytes of data and then reads the
'Protocol' field to determine if it's an IP packet. Then it read the first
byte of the first 2 bytes to determine the direction.

The issue is that only the first byte indicating direction is initialized
in current ppp driver code while the second byte is not initialized.

For normal BPF programs generated by libpcap, uninitialized data won't be
used, so it's not a problem. However, for carefully crafted BPF programs,
such as those generated by syzkaller [2], which start reading from offset
0, the uninitialized data will be used and caught by KMSAN.

[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791
[2] https://syzkaller.appspot.com/text?tag=ReproC&amp;x=11994913980000</Note>
    </Notes>
    <CVE>CVE-2025-21922</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

HID: hid-steam: Fix use-after-free when detaching device

When a hid-steam device is removed it must clean up the client_hdev used for
intercepting hidraw access. This can lead to scheduling deferred work to
reattach the input device. Though the cleanup cancels the deferred work, this
was done before the client_hdev itself is cleaned up, so it gets rescheduled.
This patch fixes the ordering to make sure the deferred work is properly
canceled.</Note>
    </Notes>
    <CVE>CVE-2025-21923</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net: hns3: make sure ptp clock is unregister and freed if hclge_ptp_get_cycle returns an error

During the initialization of ptp, hclge_ptp_get_cycle might return an error
and returned directly without unregister clock and free it. To avoid that,
call hclge_ptp_destroy_clock to unregist and free clock if
hclge_ptp_get_cycle failed.</Note>
    </Notes>
    <CVE>CVE-2025-21924</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

llc: do not use skb_get() before dev_queue_xmit()

syzbot is able to crash hosts [1], using llc and devices
not supporting IFF_TX_SKB_SHARING.

In this case, e1000 driver calls eth_skb_pad(), while
the skb is shared.

Simply replace skb_get() by skb_clone() in net/llc/llc_s_ac.c

Note that e1000 driver might have an issue with pktgen,
because it does not clear IFF_TX_SKB_SHARING, this is an
orthogonal change.

We need to audit other skb_get() uses in net/llc.

[1]

kernel BUG at net/core/skbuff.c:2178 !
Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI
CPU: 0 UID: 0 PID: 16371 Comm: syz.2.2764 Not tainted 6.14.0-rc4-syzkaller-00052-gac9c34d1e45a #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:pskb_expand_head+0x6ce/0x1240 net/core/skbuff.c:2178
Call Trace:
 &lt;TASK&gt;
  __skb_pad+0x18a/0x610 net/core/skbuff.c:2466
  __skb_put_padto include/linux/skbuff.h:3843 [inline]
  skb_put_padto include/linux/skbuff.h:3862 [inline]
  eth_skb_pad include/linux/etherdevice.h:656 [inline]
  e1000_xmit_frame+0x2d99/0x5800 drivers/net/ethernet/intel/e1000/e1000_main.c:3128
  __netdev_start_xmit include/linux/netdevice.h:5151 [inline]
  netdev_start_xmit include/linux/netdevice.h:5160 [inline]
  xmit_one net/core/dev.c:3806 [inline]
  dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3822
  sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343
  __dev_xmit_skb net/core/dev.c:4045 [inline]
  __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4621
  dev_queue_xmit include/linux/netdevice.h:3313 [inline]
  llc_sap_action_send_test_c+0x268/0x320 net/llc/llc_s_ac.c:144
  llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]
  llc_sap_next_state net/llc/llc_sap.c:182 [inline]
  llc_sap_state_process+0x239/0x510 net/llc/llc_sap.c:209
  llc_ui_sendmsg+0xd0d/0x14e0 net/llc/af_llc.c:993
  sock_sendmsg_nosec net/socket.c:718 [inline]</Note>
    </Notes>
    <CVE>CVE-2025-21925</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net: gso: fix ownership in __udp_gso_segment

In __udp_gso_segment the skb destructor is removed before segmenting the
skb but the socket reference is kept as-is. This is an issue if the
original skb is later orphaned as we can hit the following bug:

  kernel BUG at ./include/linux/skbuff.h:3312!  (skb_orphan)
  RIP: 0010:ip_rcv_core+0x8b2/0xca0
  Call Trace:
   ip_rcv+0xab/0x6e0
   __netif_receive_skb_one_core+0x168/0x1b0
   process_backlog+0x384/0x1100
   __napi_poll.constprop.0+0xa1/0x370
   net_rx_action+0x925/0xe50

The above can happen following a sequence of events when using
OpenVSwitch, when an OVS_ACTION_ATTR_USERSPACE action precedes an
OVS_ACTION_ATTR_OUTPUT action:

1. OVS_ACTION_ATTR_USERSPACE is handled (in do_execute_actions): the skb
   goes through queue_gso_packets and then __udp_gso_segment, where its
   destructor is removed.
2. The segments' data are copied and sent to userspace.
3. OVS_ACTION_ATTR_OUTPUT is handled (in do_execute_actions) and the
   same original skb is sent to its path.
4. If it later hits skb_orphan, we hit the bug.

Fix this by also removing the reference to the socket in
__udp_gso_segment.</Note>
    </Notes>
    <CVE>CVE-2025-21926</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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-tcp: fix potential memory corruption in nvme_tcp_recv_pdu()

nvme_tcp_recv_pdu() doesn't check the validity of the header length.
When header digests are enabled, a target might send a packet with an
invalid header length (e.g. 255), causing nvme_tcp_verify_hdgst()
to access memory outside the allocated area and cause memory corruptions
by overwriting it with the calculated digest.

Fix this by rejecting packets with an unexpected header length.</Note>
    </Notes>
    <CVE>CVE-2025-21927</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove()

The system can experience a random crash a few minutes after the driver is
removed. This issue occurs due to improper handling of memory freeing in
the ishtp_hid_remove() function.

The function currently frees the `driver_data` directly within the loop
that destroys the HID devices, which can lead to accessing freed memory.
Specifically, `hid_destroy_device()` uses `driver_data` when it calls
`hid_ishtp_set_feature()` to power off the sensor, so freeing
`driver_data` beforehand can result in accessing invalid memory.

This patch resolves the issue by storing the `driver_data` in a temporary
variable before calling `hid_destroy_device()`, and then freeing the
`driver_data` after the device is destroyed.</Note>
    </Notes>
    <CVE>CVE-2025-21928</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

wifi: iwlwifi: mvm: don't try to talk to a dead firmware

This fixes:

 bad state = 0
 WARNING: CPU: 10 PID: 702 at drivers/net/wireless/inel/iwlwifi/iwl-trans.c:178 iwl_trans_send_cmd+0xba/0xe0 [iwlwifi]
 Call Trace:
  &lt;TASK&gt;
  ? __warn+0xca/0x1c0
  ? iwl_trans_send_cmd+0xba/0xe0 [iwlwifi 64fa9ad799a0e0d2ba53d4af93a53ad9a531f8d4]
  iwl_fw_dbg_clear_monitor_buf+0xd7/0x110 [iwlwifi 64fa9ad799a0e0d2ba53d4af93a53ad9a531f8d4]
  _iwl_dbgfs_fw_dbg_clear_write+0xe2/0x120 [iwlmvm 0e8adb18cea92d2c341766bcc10b18699290068a]

Ask whether the firmware is alive before sending a command.</Note>
    </Notes>
    <CVE>CVE-2025-21930</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

hwpoison, memory_hotplug: lock folio before unmap hwpoisoned folio

Commit b15c87263a69 ("hwpoison, memory_hotplug: allow hwpoisoned pages to
be offlined) add page poison checks in do_migrate_range in order to make
offline hwpoisoned page possible by introducing isolate_lru_page and
try_to_unmap for hwpoisoned page.  However folio lock must be held before
calling try_to_unmap.  Add it to fix this problem.

Warning will be produced if folio is not locked during unmap:

  ------------[ cut here ]------------
  kernel BUG at ./include/linux/swapops.h:400!
  Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
  Modules linked in:
  CPU: 4 UID: 0 PID: 411 Comm: bash Tainted: G        W          6.13.0-rc1-00016-g3c434c7ee82a-dirty #41
  Tainted: [W]=WARN
  Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
  pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
  pc : try_to_unmap_one+0xb08/0xd3c
  lr : try_to_unmap_one+0x3dc/0xd3c
  Call trace:
   try_to_unmap_one+0xb08/0xd3c (P)
   try_to_unmap_one+0x3dc/0xd3c (L)
   rmap_walk_anon+0xdc/0x1f8
   rmap_walk+0x3c/0x58
   try_to_unmap+0x88/0x90
   unmap_poisoned_folio+0x30/0xa8
   do_migrate_range+0x4a0/0x568
   offline_pages+0x5a4/0x670
   memory_block_action+0x17c/0x374
   memory_subsys_offline+0x3c/0x78
   device_offline+0xa4/0xd0
   state_store+0x8c/0xf0
   dev_attr_store+0x18/0x2c
   sysfs_kf_write+0x44/0x54
   kernfs_fop_write_iter+0x118/0x1a8
   vfs_write+0x3a8/0x4bc
   ksys_write+0x6c/0xf8
   __arm64_sys_write+0x1c/0x28
   invoke_syscall+0x44/0x100
   el0_svc_common.constprop.0+0x40/0xe0
   do_el0_svc+0x1c/0x28
   el0_svc+0x30/0xd0
   el0t_64_sync_handler+0xc8/0xcc
   el0t_64_sync+0x198/0x19c
  Code: f9407be0 b5fff320 d4210000 17ffff97 (d4210000)
  ---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2025-21931</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

rapidio: fix an API misues when rio_add_net() fails

rio_add_net() calls device_register() and fails when device_register()
fails.  Thus, put_device() should be used rather than kfree().  Add
"mport-&gt;net = NULL;" to avoid a use after free issue.</Note>
    </Notes>
    <CVE>CVE-2025-21934</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

rapidio: add check for rio_add_net() in rio_scan_alloc_net()

The return value of rio_add_net() should be checked.  If it fails,
put_device() should be called to free the memory and give up the reference
initialized in rio_add_net().</Note>
    </Notes>
    <CVE>CVE-2025-21935</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

Bluetooth: Add check for mgmt_alloc_skb() in mgmt_device_connected()

Add check for the return value of mgmt_alloc_skb() in
mgmt_device_connected() to prevent null pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2025-21936</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

Bluetooth: Add check for mgmt_alloc_skb() in mgmt_remote_name()

Add check for the return value of mgmt_alloc_skb() in
mgmt_remote_name() to prevent null pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2025-21937</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

drm/amd/display: Fix null check for pipe_ctx-&gt;plane_state in resource_build_scaling_params

Null pointer dereference issue could occur when pipe_ctx-&gt;plane_state
is null. The fix adds a check to ensure 'pipe_ctx-&gt;plane_state' is not
null before accessing. This prevents a null pointer dereference.

Found by code review.

(cherry picked from commit 63e6a77ccf239337baa9b1e7787cde9fa0462092)</Note>
    </Notes>
    <CVE>CVE-2025-21941</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

gpio: aggregator: protect driver attr handlers against module unload

Both new_device_store and delete_device_store touch module global
resources (e.g. gpio_aggregator_lock). To prevent race conditions with
module unload, a reference needs to be held.

Add try_module_get() in these handlers.

For new_device_store, this eliminates what appears to be the most dangerous
scenario: if an id is allocated from gpio_aggregator_idr but
platform_device_register has not yet been called or completed, a concurrent
module unload could fail to unregister/delete the device, leaving behind a
dangling platform device/GPIO forwarder. This can result in various issues.
The following simple reproducer demonstrates these problems:

  #!/bin/bash
  while :; do
    # note: whether 'gpiochip0 0' exists or not does not matter.
    echo 'gpiochip0 0' &gt; /sys/bus/platform/drivers/gpio-aggregator/new_device
  done &amp;
  while :; do
    modprobe gpio-aggregator
    modprobe -r gpio-aggregator
  done &amp;
  wait

  Starting with the following warning, several kinds of warnings will appear
  and the system may become unstable:

  ------------[ cut here ]------------
  list_del corruption, ffff888103e2e980-&gt;next is LIST_POISON1 (dead000000000100)
  WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120
  [...]
  RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120
  [...]
  Call Trace:
   &lt;TASK&gt;
   ? __list_del_entry_valid_or_report+0xa3/0x120
   ? __warn.cold+0x93/0xf2
   ? __list_del_entry_valid_or_report+0xa3/0x120
   ? report_bug+0xe6/0x170
   ? __irq_work_queue_local+0x39/0xe0
   ? handle_bug+0x58/0x90
   ? exc_invalid_op+0x13/0x60
   ? asm_exc_invalid_op+0x16/0x20
   ? __list_del_entry_valid_or_report+0xa3/0x120
   gpiod_remove_lookup_table+0x22/0x60
   new_device_store+0x315/0x350 [gpio_aggregator]
   kernfs_fop_write_iter+0x137/0x1f0
   vfs_write+0x262/0x430
   ksys_write+0x60/0xd0
   do_syscall_64+0x6c/0x180
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
   [...]
   &lt;/TASK&gt;
  ---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2025-21943</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

HID: appleir: Fix potential NULL dereference at raw event handle

Syzkaller reports a NULL pointer dereference issue in input_event().

BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:68 [inline]
BUG: KASAN: null-ptr-deref in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
BUG: KASAN: null-ptr-deref in is_event_supported drivers/input/input.c:67 [inline]
BUG: KASAN: null-ptr-deref in input_event+0x42/0xa0 drivers/input/input.c:395
Read of size 8 at addr 0000000000000028 by task syz-executor199/2949

CPU: 0 UID: 0 PID: 2949 Comm: syz-executor199 Not tainted 6.13.0-rc4-syzkaller-00076-gf097a36ef88d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Call Trace:
 &lt;IRQ&gt;
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
 kasan_report+0xd9/0x110 mm/kasan/report.c:602
 check_region_inline mm/kasan/generic.c:183 [inline]
 kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189
 instrument_atomic_read include/linux/instrumented.h:68 [inline]
 _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
 is_event_supported drivers/input/input.c:67 [inline]
 input_event+0x42/0xa0 drivers/input/input.c:395
 input_report_key include/linux/input.h:439 [inline]
 key_down drivers/hid/hid-appleir.c:159 [inline]
 appleir_raw_event+0x3e5/0x5e0 drivers/hid/hid-appleir.c:232
 __hid_input_report.constprop.0+0x312/0x440 drivers/hid/hid-core.c:2111
 hid_ctrl+0x49f/0x550 drivers/hid/usbhid/hid-core.c:484
 __usb_hcd_giveback_urb+0x389/0x6e0 drivers/usb/core/hcd.c:1650
 usb_hcd_giveback_urb+0x396/0x450 drivers/usb/core/hcd.c:1734
 dummy_timer+0x17f7/0x3960 drivers/usb/gadget/udc/dummy_hcd.c:1993
 __run_hrtimer kernel/time/hrtimer.c:1739 [inline]
 __hrtimer_run_queues+0x20a/0xae0 kernel/time/hrtimer.c:1803
 hrtimer_run_softirq+0x17d/0x350 kernel/time/hrtimer.c:1820
 handle_softirqs+0x206/0x8d0 kernel/softirq.c:561
 __do_softirq kernel/softirq.c:595 [inline]
 invoke_softirq kernel/softirq.c:435 [inline]
 __irq_exit_rcu+0xfa/0x160 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+0x90/0xb0 arch/x86/kernel/apic/apic.c:1049
 &lt;/IRQ&gt;
 &lt;TASK&gt;
 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702
 __mod_timer+0x8f6/0xdc0 kernel/time/timer.c:1185
 add_timer+0x62/0x90 kernel/time/timer.c:1295
 schedule_timeout+0x11f/0x280 kernel/time/sleep_timeout.c:98
 usbhid_wait_io+0x1c7/0x380 drivers/hid/usbhid/hid-core.c:645
 usbhid_init_reports+0x19f/0x390 drivers/hid/usbhid/hid-core.c:784
 hiddev_ioctl+0x1133/0x15b0 drivers/hid/usbhid/hiddev.c:794
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:906 [inline]
 __se_sys_ioctl fs/ioctl.c:892 [inline]
 __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892
 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
 &lt;/TASK&gt;

This happens due to the malformed report items sent by the emulated device
which results in a report, that has no fields, being added to the report list.
Due to this appleir_input_configured() is never called, hidinput_connect()
fails which results in the HID_CLAIMED_INPUT flag is not being set. However,
it  does not make appleir_probe() fail and lets the event callback to be
called without the associated input device.

Thus, add a check for the HID_CLAIMED_INPUT flag and leave the event hook
early if the driver didn't claim any input_dev for some reason. Moreover,
some other hid drivers accessing input_dev in their event callbacks do have
similar checks, too.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.</Note>
    </Notes>
    <CVE>CVE-2025-21948</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

drivers: virt: acrn: hsm: Use kzalloc to avoid info leak in pmcmd_ioctl

In the "pmcmd_ioctl" function, three memory objects allocated by
kmalloc are initialized by "hcall_get_cpu_state", which are then
copied to user space. The initializer is indeed implemented in
"acrn_hypercall2" (arch/x86/include/asm/acrn.h). There is a risk of
information leakage due to uninitialized bytes.</Note>
    </Notes>
    <CVE>CVE-2025-21950</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlock

There are multiple places from where the recovery work gets scheduled
asynchronously. Also, there are multiple places where the caller waits
synchronously for the recovery to be completed. One such place is during
the PM shutdown() callback.

If the device is not alive during recovery_work, it will try to reset the
device using pci_reset_function(). This function internally will take the
device_lock() first before resetting the device. By this time, if the lock
has already been acquired, then recovery_work will get stalled while
waiting for the lock. And if the lock was already acquired by the caller
which waits for the recovery_work to be completed, it will lead to
deadlock.

This is what happened on the X1E80100 CRD device when the device died
before shutdown() callback. Driver core calls the driver's shutdown()
callback while holding the device_lock() leading to deadlock.

And this deadlock scenario can occur on other paths as well, like during
the PM suspend() callback, where the driver core would hold the
device_lock() before calling driver's suspend() callback. And if the
recovery_work was already started, it could lead to deadlock. This is also
observed on the X1E80100 CRD.

So to fix both issues, use pci_try_reset_function() in recovery_work. This
function first checks for the availability of the device_lock() before
trying to reset the device. If the lock is available, it will acquire it
and reset the device. Otherwise, it will return -EAGAIN. If that happens,
recovery_work will fail with the error message "Recovery failed" as not
much could be done.</Note>
    </Notes>
    <CVE>CVE-2025-21951</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net: mana: cleanup mana struct after debugfs_remove()

When on a MANA VM hibernation is triggered, as part of hibernate_snapshot(),
mana_gd_suspend() and mana_gd_resume() are called. If during this
mana_gd_resume(), a failure occurs with HWC creation, mana_port_debugfs
pointer does not get reinitialized and ends up pointing to older,
cleaned-up dentry.
Further in the hibernation path, as part of power_down(), mana_gd_shutdown()
is triggered. This call, unaware of the failures in resume, tries to cleanup
the already cleaned up  mana_port_debugfs value and hits the following bug:

[  191.359296] mana 7870:00:00.0: Shutdown was called
[  191.359918] BUG: kernel NULL pointer dereference, address: 0000000000000098
[  191.360584] #PF: supervisor write access in kernel mode
[  191.361125] #PF: error_code(0x0002) - not-present page
[  191.361727] PGD 1080ea067 P4D 0
[  191.362172] Oops: Oops: 0002 [#1] SMP NOPTI
[  191.362606] CPU: 11 UID: 0 PID: 1674 Comm: bash Not tainted 6.14.0-rc5+ #2
[  191.363292] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/21/2024
[  191.364124] RIP: 0010:down_write+0x19/0x50
[  191.364537] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb e8 de cd ff ff 31 c0 ba 01 00 00 00 &lt;f0&gt; 48 0f b1 13 75 16 65 48 8b 05 88 24 4c 6a 48 89 43 08 48 8b 5d
[  191.365867] RSP: 0000:ff45fbe0c1c037b8 EFLAGS: 00010246
[  191.366350] RAX: 0000000000000000 RBX: 0000000000000098 RCX: ffffff8100000000
[  191.366951] RDX: 0000000000000001 RSI: 0000000000000064 RDI: 0000000000000098
[  191.367600] RBP: ff45fbe0c1c037c0 R08: 0000000000000000 R09: 0000000000000001
[  191.368225] R10: ff45fbe0d2b01000 R11: 0000000000000008 R12: 0000000000000000
[  191.368874] R13: 000000000000000b R14: ff43dc27509d67c0 R15: 0000000000000020
[  191.369549] FS:  00007dbc5001e740(0000) GS:ff43dc663f380000(0000) knlGS:0000000000000000
[  191.370213] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  191.370830] CR2: 0000000000000098 CR3: 0000000168e8e002 CR4: 0000000000b73ef0
[  191.371557] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  191.372192] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
[  191.372906] Call Trace:
[  191.373262]  &lt;TASK&gt;
[  191.373621]  ? show_regs+0x64/0x70
[  191.374040]  ? __die+0x24/0x70
[  191.374468]  ? page_fault_oops+0x290/0x5b0
[  191.374875]  ? do_user_addr_fault+0x448/0x800
[  191.375357]  ? exc_page_fault+0x7a/0x160
[  191.375971]  ? asm_exc_page_fault+0x27/0x30
[  191.376416]  ? down_write+0x19/0x50
[  191.376832]  ? down_write+0x12/0x50
[  191.377232]  simple_recursive_removal+0x4a/0x2a0
[  191.377679]  ? __pfx_remove_one+0x10/0x10
[  191.378088]  debugfs_remove+0x44/0x70
[  191.378530]  mana_detach+0x17c/0x4f0
[  191.378950]  ? __flush_work+0x1e2/0x3b0
[  191.379362]  ? __cond_resched+0x1a/0x50
[  191.379787]  mana_remove+0xf2/0x1a0
[  191.380193]  mana_gd_shutdown+0x3b/0x70
[  191.380642]  pci_device_shutdown+0x3a/0x80
[  191.381063]  device_shutdown+0x13e/0x230
[  191.381480]  kernel_power_off+0x35/0x80
[  191.381890]  hibernate+0x3c6/0x470
[  191.382312]  state_store+0xcb/0xd0
[  191.382734]  kobj_attr_store+0x12/0x30
[  191.383211]  sysfs_kf_write+0x3e/0x50
[  191.383640]  kernfs_fop_write_iter+0x140/0x1d0
[  191.384106]  vfs_write+0x271/0x440
[  191.384521]  ksys_write+0x72/0xf0
[  191.384924]  __x64_sys_write+0x19/0x20
[  191.385313]  x64_sys_call+0x2b0/0x20b0
[  191.385736]  do_syscall_64+0x79/0x150
[  191.386146]  ? __mod_memcg_lruvec_state+0xe7/0x240
[  191.386676]  ? __lruvec_stat_mod_folio+0x79/0xb0
[  191.387124]  ? __pfx_lru_add+0x10/0x10
[  191.387515]  ? queued_spin_unlock+0x9/0x10
[  191.387937]  ? do_anonymous_page+0x33c/0xa00
[  191.388374]  ? __handle_mm_fault+0xcf3/0x1210
[  191.388805]  ? __count_memcg_events+0xbe/0x180
[  191.389235]  ? handle_mm_fault+0xae/0x300
[  19
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-21953</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

drm/amd/display: Assign normalized_pix_clk when color depth = 14

[WHY &amp; HOW]
A warning message "WARNING: CPU: 4 PID: 459 at ... /dc_resource.c:3397
calculate_phy_pix_clks+0xef/0x100 [amdgpu]" occurs because the
display_color_depth == COLOR_DEPTH_141414 is not handled. This is
observed in Radeon RX 6600 XT.

It is fixed by assigning pix_clk * (14 * 3) / 24 - same as the rests.

Also fixes the indentation in get_norm_pix_clk.

(cherry picked from commit 274a87eb389f58eddcbc5659ab0b180b37e92775)</Note>
    </Notes>
    <CVE>CVE-2025-21956</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

scsi: qla1280: Fix kernel oops when debug level &gt; 2

A null dereference or oops exception will eventually occur when qla1280.c
driver is compiled with DEBUG_QLA1280 enabled and ql_debug_level &gt; 2.  I
think its clear from the code that the intention here is sg_dma_len(s) not
length of sg_next(s) when printing the debug info.</Note>
    </Notes>
    <CVE>CVE-2025-21957</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

eth: bnxt: do not update checksum in bnxt_xdp_build_skb()

The bnxt_rx_pkt() updates ip_summed value at the end if checksum offload
is enabled.
When the XDP-MB program is attached and it returns XDP_PASS, the
bnxt_xdp_build_skb() is called to update skb_shared_info.
The main purpose of bnxt_xdp_build_skb() is to update skb_shared_info,
but it updates ip_summed value too if checksum offload is enabled.
This is actually duplicate work.

When the bnxt_rx_pkt() updates ip_summed value, it checks if ip_summed
is CHECKSUM_NONE or not.
It means that ip_summed should be CHECKSUM_NONE at this moment.
But ip_summed may already be updated to CHECKSUM_UNNECESSARY in the
XDP-MB-PASS path.
So the by skb_checksum_none_assert() WARNS about it.

This is duplicate work and updating ip_summed in the
bnxt_xdp_build_skb() is not needed.

Splat looks like:
WARNING: CPU: 3 PID: 5782 at ./include/linux/skbuff.h:5155 bnxt_rx_pkt+0x479b/0x7610 [bnxt_en]
Modules linked in: bnxt_re bnxt_en rdma_ucm rdma_cm iw_cm ib_cm ib_uverbs veth xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_]
CPU: 3 UID: 0 PID: 5782 Comm: socat Tainted: G        W          6.14.0-rc4+ #27
Tainted: [W]=WARN
Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021
RIP: 0010:bnxt_rx_pkt+0x479b/0x7610 [bnxt_en]
Code: 54 24 0c 4c 89 f1 4c 89 ff c1 ea 1f ff d3 0f 1f 00 49 89 c6 48 85 c0 0f 84 4c e5 ff ff 48 89 c7 e8 ca 3d a0 c8 e9 8f f4 ff ff &lt;0f&gt; 0b f
RSP: 0018:ffff88881ba09928 EFLAGS: 00010202
RAX: 0000000000000000 RBX: 00000000c7590303 RCX: 0000000000000000
RDX: 1ffff1104e7d1610 RSI: 0000000000000001 RDI: ffff8881c91300b8
RBP: ffff88881ba09b28 R08: ffff888273e8b0d0 R09: ffff888273e8b070
R10: ffff888273e8b010 R11: ffff888278b0f000 R12: ffff888273e8b080
R13: ffff8881c9130e00 R14: ffff8881505d3800 R15: ffff888273e8b000
FS:  00007f5a2e7be080(0000) GS:ffff88881ba00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fff2e708ff8 CR3: 000000013e3b0000 CR4: 00000000007506f0
PKRU: 55555554
Call Trace:
 &lt;IRQ&gt;
 ? __warn+0xcd/0x2f0
 ? bnxt_rx_pkt+0x479b/0x7610
 ? report_bug+0x326/0x3c0
 ? handle_bug+0x53/0xa0
 ? exc_invalid_op+0x14/0x50
 ? asm_exc_invalid_op+0x16/0x20
 ? bnxt_rx_pkt+0x479b/0x7610
 ? bnxt_rx_pkt+0x3e41/0x7610
 ? __pfx_bnxt_rx_pkt+0x10/0x10
 ? napi_complete_done+0x2cf/0x7d0
 __bnxt_poll_work+0x4e8/0x1220
 ? __pfx___bnxt_poll_work+0x10/0x10
 ? __pfx_mark_lock.part.0+0x10/0x10
 bnxt_poll_p5+0x36a/0xfa0
 ? __pfx_bnxt_poll_p5+0x10/0x10
 __napi_poll.constprop.0+0xa0/0x440
 net_rx_action+0x899/0xd00
...

Following ping.py patch adds xdp-mb-pass case. so ping.py is going
to be able to reproduce this issue.</Note>
    </Notes>
    <CVE>CVE-2025-21960</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

eth: bnxt: fix truesize for mb-xdp-pass case

When mb-xdp is set and return is XDP_PASS, packet is converted from
xdp_buff to sk_buff with xdp_update_skb_shared_info() in
bnxt_xdp_build_skb().
bnxt_xdp_build_skb() passes incorrect truesize argument to
xdp_update_skb_shared_info().
The truesize is calculated as BNXT_RX_PAGE_SIZE * sinfo-&gt;nr_frags but
the skb_shared_info was wiped by napi_build_skb() before.
So it stores sinfo-&gt;nr_frags before bnxt_xdp_build_skb() and use it
instead of getting skb_shared_info from xdp_get_shared_info_from_buff().

Splat looks like:
 ------------[ cut here ]------------
 WARNING: CPU: 2 PID: 0 at net/core/skbuff.c:6072 skb_try_coalesce+0x504/0x590
 Modules linked in: xt_nat xt_tcpudp veth af_packet xt_conntrack nft_chain_nat xt_MASQUERADE nf_conntrack_netlink xfrm_user xt_addrtype nft_coms
 CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.14.0-rc2+ #3
 RIP: 0010:skb_try_coalesce+0x504/0x590
 Code: 4b fd ff ff 49 8b 34 24 40 80 e6 40 0f 84 3d fd ff ff 49 8b 74 24 48 40 f6 c6 01 0f 84 2e fd ff ff 48 8d 4e ff e9 25 fd ff ff &lt;0f&gt; 0b e99
 RSP: 0018:ffffb62c4120caa8 EFLAGS: 00010287
 RAX: 0000000000000003 RBX: ffffb62c4120cb14 RCX: 0000000000000ec0
 RDX: 0000000000001000 RSI: ffffa06e5d7dc000 RDI: 0000000000000003
 RBP: ffffa06e5d7ddec0 R08: ffffa06e6120a800 R09: ffffa06e7a119900
 R10: 0000000000002310 R11: ffffa06e5d7dcec0 R12: ffffe4360575f740
 R13: ffffe43600000000 R14: 0000000000000002 R15: 0000000000000002
 FS:  0000000000000000(0000) GS:ffffa0755f700000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 00007f147b76b0f8 CR3: 00000001615d4000 CR4: 00000000007506f0
 PKRU: 55555554
 Call Trace:
  &lt;IRQ&gt;
  ? __warn+0x84/0x130
  ? skb_try_coalesce+0x504/0x590
  ? report_bug+0x18a/0x1a0
  ? handle_bug+0x53/0x90
  ? exc_invalid_op+0x14/0x70
  ? asm_exc_invalid_op+0x16/0x20
  ? skb_try_coalesce+0x504/0x590
  inet_frag_reasm_finish+0x11f/0x2e0
  ip_defrag+0x37a/0x900
  ip_local_deliver+0x51/0x120
  ip_sublist_rcv_finish+0x64/0x70
  ip_sublist_rcv+0x179/0x210
  ip_list_rcv+0xf9/0x130

How to reproduce:
&lt;Node A&gt;
ip link set $interface1 xdp obj xdp_pass.o
ip link set $interface1 mtu 9000 up
ip a a 10.0.0.1/24 dev $interface1
&lt;Node B&gt;
ip link set $interfac2 mtu 9000 up
ip a a 10.0.0.2/24 dev $interface2
ping 10.0.0.1 -s 65000

Following ping.py patch adds xdp-mb-pass case. so ping.py is going to be
able to reproduce this issue.</Note>
    </Notes>
    <CVE>CVE-2025-21961</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

cifs: Fix integer overflow while processing closetimeo mount option

User-provided mount parameter closetimeo of type u32 is intended to have
an upper limit, but before it is validated, the value is converted from
seconds to jiffies which can lead to an integer overflow.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2025-21962</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

cifs: Fix integer overflow while processing acdirmax mount option

User-provided mount parameter acdirmax of type u32 is intended to have
an upper limit, but before it is validated, the value is converted from
seconds to jiffies which can lead to an integer overflow.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2025-21963</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

cifs: Fix integer overflow while processing acregmax mount option

User-provided mount parameter acregmax of type u32 is intended to have
an upper limit, but before it is validated, the value is converted from
seconds to jiffies which can lead to an integer overflow.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2025-21964</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

dm-flakey: Fix memory corruption in optional corrupt_bio_byte feature

Fix memory corruption due to incorrect parameter being passed to bio_init</Note>
    </Notes>
    <CVE>CVE-2025-21966</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

drm/amd/display: Fix slab-use-after-free on hdcp_work

[Why]
A slab-use-after-free is reported when HDCP is destroyed but the
property_validate_dwork queue is still running.

[How]
Cancel the delayed work when destroying workqueue.

(cherry picked from commit 725a04ba5a95e89c89633d4322430cfbca7ce128)</Note>
    </Notes>
    <CVE>CVE-2025-21968</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

Bluetooth: L2CAP: Fix slab-use-after-free Read in l2cap_send_cmd

After the hci sync command releases l2cap_conn, the hci receive data work
queue references the released l2cap_conn when sending to the upper layer.
Add hci dev lock to the hci receive data work queue to synchronize the two.

[1]
BUG: KASAN: slab-use-after-free in l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954
Read of size 8 at addr ffff8880271a4000 by task kworker/u9:2/5837

CPU: 0 UID: 0 PID: 5837 Comm: kworker/u9:2 Not tainted 6.13.0-rc5-syzkaller-00163-gab75170520d4 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Workqueue: hci1 hci_rx_work
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
 l2cap_build_cmd net/bluetooth/l2cap_core.c:2964 [inline]
 l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954
 l2cap_sig_send_rej net/bluetooth/l2cap_core.c:5502 [inline]
 l2cap_sig_channel net/bluetooth/l2cap_core.c:5538 [inline]
 l2cap_recv_frame+0x221f/0x10db0 net/bluetooth/l2cap_core.c:6817
 hci_acldata_packet net/bluetooth/hci_core.c:3797 [inline]
 hci_rx_work+0x508/0xdb0 net/bluetooth/hci_core.c:4040
 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 5837:
 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:4329
 kmalloc_noprof include/linux/slab.h:901 [inline]
 kzalloc_noprof include/linux/slab.h:1037 [inline]
 l2cap_conn_add+0xa9/0x8e0 net/bluetooth/l2cap_core.c:6860
 l2cap_connect_cfm+0x115/0x1090 net/bluetooth/l2cap_core.c:7239
 hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline]
 hci_remote_features_evt+0x68e/0xac0 net/bluetooth/hci_event.c:3726
 hci_event_func net/bluetooth/hci_event.c:7473 [inline]
 hci_event_packet+0xac2/0x1540 net/bluetooth/hci_event.c:7525
 hci_rx_work+0x3f3/0xdb0 net/bluetooth/hci_core.c:4035
 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

Freed by task 54:
 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:2353 [inline]
 slab_free mm/slub.c:4613 [inline]
 kfree+0x196/0x430 mm/slub.c:4761
 l2cap_connect_cfm+0xcc/0x1090 net/bluetooth/l2cap_core.c:7235
 hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline]
 hci_conn_failed+0x287/0x400 net/bluetooth/hci_conn.c:1266
 hci_abort_conn_sync+0x56c/0x11f0 net/bluetooth/hci_sync.c:5603
 hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:332
 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/entr
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-21969</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net/mlx5: Bridge, fix the crash caused by LAG state check

When removing LAG device from bridge, NETDEV_CHANGEUPPER event is
triggered. Driver finds the lower devices (PFs) to flush all the
offloaded entries. And mlx5_lag_is_shared_fdb is checked, it returns
false if one of PF is unloaded. In such case,
mlx5_esw_bridge_lag_rep_get() and its caller return NULL, instead of
the alive PF, and the flush is skipped.

Besides, the bridge fdb entry's lastuse is updated in mlx5 bridge
event handler. But this SWITCHDEV_FDB_ADD_TO_BRIDGE event can be
ignored in this case because the upper interface for bond is deleted,
and the entry will never be aged because lastuse is never updated.

To make things worse, as the entry is alive, mlx5 bridge workqueue
keeps sending that event, which is then handled by kernel bridge
notifier. It causes the following crash when accessing the passed bond
netdev which is already destroyed.

To fix this issue, remove such checks. LAG state is already checked in
commit 15f8f168952f ("net/mlx5: Bridge, verify LAG state when adding
bond to bridge"), driver still need to skip offload if LAG becomes
invalid state after initialization.

 Oops: stack segment: 0000 [#1] SMP
 CPU: 3 UID: 0 PID: 23695 Comm: kworker/u40:3 Tainted: G           OE      6.11.0_mlnx #1
 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
 Workqueue: mlx5_bridge_wq mlx5_esw_bridge_update_work [mlx5_core]
 RIP: 0010:br_switchdev_event+0x2c/0x110 [bridge]
 Code: 44 00 00 48 8b 02 48 f7 00 00 02 00 00 74 69 41 54 55 53 48 83 ec 08 48 8b a8 08 01 00 00 48 85 ed 74 4a 48 83 fe 02 48 89 d3 &lt;4c&gt; 8b 65 00 74 23 76 49 48 83 fe 05 74 7e 48 83 fe 06 75 2f 0f b7
 RSP: 0018:ffffc900092cfda0 EFLAGS: 00010297
 RAX: ffff888123bfe000 RBX: ffffc900092cfe08 RCX: 00000000ffffffff
 RDX: ffffc900092cfe08 RSI: 0000000000000001 RDI: ffffffffa0c585f0
 RBP: 6669746f6e690a30 R08: 0000000000000000 R09: ffff888123ae92c8
 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888123ae9c60
 R13: 0000000000000001 R14: ffffc900092cfe08 R15: 0000000000000000
 FS:  0000000000000000(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 00007f15914c8734 CR3: 0000000002830005 CR4: 0000000000770ef0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 PKRU: 55555554
 Call Trace:
  &lt;TASK&gt;
  ? __die_body+0x1a/0x60
  ? die+0x38/0x60
  ? do_trap+0x10b/0x120
  ? do_error_trap+0x64/0xa0
  ? exc_stack_segment+0x33/0x50
  ? asm_exc_stack_segment+0x22/0x30
  ? br_switchdev_event+0x2c/0x110 [bridge]
  ? sched_balance_newidle.isra.149+0x248/0x390
  notifier_call_chain+0x4b/0xa0
  atomic_notifier_call_chain+0x16/0x20
  mlx5_esw_bridge_update+0xec/0x170 [mlx5_core]
  mlx5_esw_bridge_update_work+0x19/0x40 [mlx5_core]
  process_scheduled_works+0x81/0x390
  worker_thread+0x106/0x250
  ? bh_worker+0x110/0x110
  kthread+0xb7/0xe0
  ? kthread_park+0x80/0x80
  ret_from_fork+0x2d/0x50
  ? kthread_park+0x80/0x80
  ret_from_fork_asm+0x11/0x20
  &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2025-21970</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net_sched: Prevent creation of classes with TC_H_ROOT

The function qdisc_tree_reduce_backlog() uses TC_H_ROOT as a termination
condition when traversing up the qdisc tree to update parent backlog
counters. However, if a class is created with classid TC_H_ROOT, the
traversal terminates prematurely at this class instead of reaching the
actual root qdisc, causing parent statistics to be incorrectly maintained.
In case of DRR, this could lead to a crash as reported by Mingi Cho.

Prevent the creation of any Qdisc class with classid TC_H_ROOT
(0xFFFFFFFF) across all qdisc types, as suggested by Jamal.</Note>
    </Notes>
    <CVE>CVE-2025-21971</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net: mctp: unshare packets when reassembling

Ensure that the frag_list used for reassembly isn't shared with other
packets. This avoids incorrect reassembly when packets are cloned, and
prevents a memory leak due to circular references between fragments and
their skb_shared_info.

The upcoming MCTP-over-USB driver uses skb_clone which can trigger the
problem - other MCTP drivers don't share SKBs.

A kunit test is added to reproduce the issue.</Note>
    </Notes>
    <CVE>CVE-2025-21972</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net/mlx5: handle errors in mlx5_chains_create_table()

In mlx5_chains_create_table(), the return value of  mlx5_get_fdb_sub_ns()
and mlx5_get_flow_namespace() must be checked to prevent NULL pointer
dereferences. If either function fails, the function should log error
message with mlx5_core_warn() and return error pointer.</Note>
    </Notes>
    <CVE>CVE-2025-21975</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

drm/hyperv: Fix address space leak when Hyper-V DRM device is removed

When a Hyper-V DRM device is probed, the driver allocates MMIO space for
the vram, and maps it cacheable. If the device removed, or in the error
path for device probing, the MMIO space is released but no unmap is done.
Consequently the kernel address space for the mapping is leaked.

Fix this by adding iounmap() calls in the device removal path, and in the
error path during device probing.</Note>
    </Notes>
    <CVE>CVE-2025-21978</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

wifi: cfg80211: cancel wiphy_work before freeing wiphy

A wiphy_work can be queued from the moment the wiphy is allocated and
initialized (i.e. wiphy_new_nm). When a wiphy_work is queued, the
rdev::wiphy_work is getting queued.

If wiphy_free is called before the rdev::wiphy_work had a chance to run,
the wiphy memory will be freed, and then when it eventally gets to run
it'll use invalid memory.

Fix this by canceling the work before freeing the wiphy.</Note>
    </Notes>
    <CVE>CVE-2025-21979</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

sched: address a potential NULL pointer dereference in the GRED scheduler.

If kzalloc in gred_init returns a NULL pointer, the code follows the
error handling path, invoking gred_destroy. This, in turn, calls
gred_offload, where memset could receive a NULL pointer as input,
potentially leading to a kernel crash.

When table-&gt;opt is NULL in gred_init(), gred_change_table_def()
is not called yet, so it is not necessary to call -&gt;ndo_setup_tc()
in gred_offload().</Note>
    </Notes>
    <CVE>CVE-2025-21980</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ice: fix memory leak in aRFS after reset

Fix aRFS (accelerated Receive Flow Steering) structures memory leak by
adding a checker to verify if aRFS memory is already allocated while
configuring VSI. aRFS objects are allocated in two cases:
- as part of VSI initialization (at probe), and
- as part of reset handling

However, VSI reconfiguration executed during reset involves memory
allocation one more time, without prior releasing already allocated
resources. This led to the memory leak with the following signature:

[root@os-delivery ~]# cat /sys/kernel/debug/kmemleak
unreferenced object 0xff3c1ca7252e6000 (size 8192):
  comm "kworker/0:0", pid 8, jiffies 4296833052
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc 0):
    [&lt;ffffffff991ec485&gt;] __kmalloc_cache_noprof+0x275/0x340
    [&lt;ffffffffc0a6e06a&gt;] ice_init_arfs+0x3a/0xe0 [ice]
    [&lt;ffffffffc09f1027&gt;] ice_vsi_cfg_def+0x607/0x850 [ice]
    [&lt;ffffffffc09f244b&gt;] ice_vsi_setup+0x5b/0x130 [ice]
    [&lt;ffffffffc09c2131&gt;] ice_init+0x1c1/0x460 [ice]
    [&lt;ffffffffc09c64af&gt;] ice_probe+0x2af/0x520 [ice]
    [&lt;ffffffff994fbcd3&gt;] local_pci_probe+0x43/0xa0
    [&lt;ffffffff98f07103&gt;] work_for_cpu_fn+0x13/0x20
    [&lt;ffffffff98f0b6d9&gt;] process_one_work+0x179/0x390
    [&lt;ffffffff98f0c1e9&gt;] worker_thread+0x239/0x340
    [&lt;ffffffff98f14abc&gt;] kthread+0xcc/0x100
    [&lt;ffffffff98e45a6d&gt;] ret_from_fork+0x2d/0x50
    [&lt;ffffffff98e083ba&gt;] ret_from_fork_asm+0x1a/0x30
    ...</Note>
    </Notes>
    <CVE>CVE-2025-21981</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

drm/amd/display: Fix out-of-bound accesses

[WHAT &amp; HOW]
hpo_stream_to_link_encoder_mapping has size MAX_HPO_DP2_ENCODERS(=4),
but location can have size up to 6. As a result, it is necessary to
check location against MAX_HPO_DP2_ENCODERS.

Similiarly, disp_cfg_stream_location can be used as an array index which
should be 0..5, so the ASSERT's conditions should be less without equal.</Note>
    </Notes>
    <CVE>CVE-2025-21985</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodes

Currently, load_microcode_amd() iterates over all NUMA nodes, retrieves their
CPU masks and unconditionally accesses per-CPU data for the first CPU of each
mask.

According to Documentation/admin-guide/mm/numaperf.rst:

  "Some memory may share the same node as a CPU, and others are provided as
  memory only nodes."

Therefore, some node CPU masks may be empty and wouldn't have a "first CPU".

On a machine with far memory (and therefore CPU-less NUMA nodes):
- cpumask_of_node(nid) is 0
- cpumask_first(0) is CONFIG_NR_CPUS
- cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an
  index that is 1 out of bounds

This does not have any security implications since flashing microcode is
a privileged operation but I believe this has reliability implications by
potentially corrupting memory while flashing a microcode update.

When booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashes
a microcode update. I get the following splat:

  UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y
  index 512 is out of range for type 'unsigned long[512]'
  [...]
  Call Trace:
   dump_stack
   __ubsan_handle_out_of_bounds
   load_microcode_amd
   request_microcode_amd
   reload_store
   kernfs_fop_write_iter
   vfs_write
   ksys_write
   do_syscall_64
   entry_SYSCALL_64_after_hwframe

Change the loop to go over only NUMA nodes which have CPUs before determining
whether the first CPU on the respective node needs microcode update.

  [ bp: Massage commit message, fix typo. ]</Note>
    </Notes>
    <CVE>CVE-2025-21991</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

HID: ignore non-functional sensor in HP 5MP Camera

The HP 5MP Camera (USB ID 0408:5473) reports a HID sensor interface that
is not actually implemented. Attempting to access this non-functional
sensor via iio_info causes system hangs as runtime PM tries to wake up
an unresponsive sensor.

  [453] hid-sensor-hub 0003:0408:5473.0003: Report latency attributes: ffffffff:ffffffff
  [453] hid-sensor-hub 0003:0408:5473.0003: common attributes: 5:1, 2:1, 3:1 ffffffff:ffffffff

Add this device to the HID ignore list since the sensor interface is
non-functional by design and should not be exposed to userspace.</Note>
    </Notes>
    <CVE>CVE-2025-21992</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic()

When performing an iSCSI boot using IPv6, iscsistart still reads the
/sys/firmware/ibft/ethernetX/subnet-mask entry. Since the IPv6 prefix
length is 64, this causes the shift exponent to become negative,
triggering a UBSAN warning. As the concept of a subnet mask does not
apply to IPv6, the value is set to ~0 to suppress the warning message.</Note>
    </Notes>
    <CVE>CVE-2025-21993</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

drm/sched: Fix fence reference count leak

The last_scheduled fence leaks when an entity is being killed and adding
the cleanup callback fails.

Decrement the reference count of prev when dma_fence_add_callback()
fails, ensuring proper balance.

[phasta: add git tag info for stable kernel]</Note>
    </Notes>
    <CVE>CVE-2025-21995</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

drm/radeon: fix uninitialized size issue in radeon_vce_cs_parse()

On the off chance that command stream passed from userspace via
ioctl() call to radeon_vce_cs_parse() is weirdly crafted and
first command to execute is to encode (case 0x03000001), the function
in question will attempt to call radeon_vce_cs_reloc() with size
argument that has not been properly initialized. Specifically, 'size'
will point to 'tmp' variable before the latter had a chance to be
assigned any value.

Play it safe and init 'tmp' with 0, thus ensuring that
radeon_vce_cs_reloc() will catch an early error in cases like these.

Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.

(cherry picked from commit 2d52de55f9ee7aaee0e09ac443f77855989c6b68)</Note>
    </Notes>
    <CVE>CVE-2025-21996</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

proc: fix UAF in proc_get_inode()

Fix race between rmmod and /proc/XXX's inode instantiation.

The bug is that pde-&gt;proc_ops don't belong to /proc, it belongs to a
module, therefore dereferencing it after /proc entry has been registered
is a bug unless use_pde/unuse_pde() pair has been used.

use_pde/unuse_pde can be avoided (2 atomic ops!) because pde-&gt;proc_ops
never changes so information necessary for inode instantiation can be
saved _before_ proc_register() in PDE itself and used later, avoiding
pde-&gt;proc_ops-&gt;...  dereference.

      rmmod                         lookup
sys_delete_module
                         proc_lookup_de
			   pde_get(de);
			   proc_get_inode(dir-&gt;i_sb, de);
  mod-&gt;exit()
    proc_remove
      remove_proc_subtree
       proc_entry_rundown(de);
  free_module(mod);

                               if (S_ISREG(inode-&gt;i_mode))
	                         if (de-&gt;proc_ops-&gt;proc_read_iter)
                           --&gt; As module is already freed, will trigger UAF

BUG: unable to handle page fault for address: fffffbfff80a702b
PGD 817fc4067 P4D 817fc4067 PUD 817fc0067 PMD 102ef4067 PTE 0
Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 26 UID: 0 PID: 2667 Comm: ls Tainted: G
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:proc_get_inode+0x302/0x6e0
RSP: 0018:ffff88811c837998 EFLAGS: 00010a06
RAX: dffffc0000000000 RBX: ffffffffc0538140 RCX: 0000000000000007
RDX: 1ffffffff80a702b RSI: 0000000000000001 RDI: ffffffffc0538158
RBP: ffff8881299a6000 R08: 0000000067bbe1e5 R09: 1ffff11023906f20
R10: ffffffffb560ca07 R11: ffffffffb2b43a58 R12: ffff888105bb78f0
R13: ffff888100518048 R14: ffff8881299a6004 R15: 0000000000000001
FS:  00007f95b9686840(0000) GS:ffff8883af100000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffbfff80a702b CR3: 0000000117dd2000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 proc_lookup_de+0x11f/0x2e0
 __lookup_slow+0x188/0x350
 walk_component+0x2ab/0x4f0
 path_lookupat+0x120/0x660
 filename_lookup+0x1ce/0x560
 vfs_statx+0xac/0x150
 __do_sys_newstat+0x96/0x110
 do_syscall_64+0x5f/0x170
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

[adobriyan@gmail.com: don't do 2 atomic ops on the common path]</Note>
    </Notes>
    <CVE>CVE-2025-21999</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

accel/qaic: Fix integer overflow in qaic_validate_req()

These are u64 variables that come from the user via
qaic_attach_slice_bo_ioctl().  Use check_add_overflow() to ensure that
the math doesn't have an integer wrapping bug.</Note>
    </Notes>
    <CVE>CVE-2025-22001</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

can: ucan: fix out of bound read in strscpy() source

Commit 7fdaf8966aae ("can: ucan: use strscpy() to instead of strncpy()")
unintentionally introduced a one byte out of bound read on strscpy()'s
source argument (which is kind of ironic knowing that strscpy() is meant
to be a more secure alternative :)).

Let's consider below buffers:

  dest[len + 1]; /* will be NUL terminated */
  src[len]; /* may not be NUL terminated */

When doing:

  strncpy(dest, src, len);
  dest[len] = '\0';

strncpy() will read up to len bytes from src.

On the other hand:

  strscpy(dest, src, len + 1);

will read up to len + 1 bytes from src, that is to say, an out of bound
read of one byte will occur on src if it is not NUL terminated. Note
that the src[len] byte is never copied, but strscpy() still needs to
read it to check whether a truncation occurred or not.

This exact pattern happened in ucan.

The root cause is that the source is not NUL terminated. Instead of
doing a copy in a local buffer, directly NUL terminate it as soon as
usb_control_msg() returns. With this, the local firmware_str[] variable
can be removed.

On top of this do a couple refactors:

  - ucan_ctl_payload-&gt;raw is only used for the firmware string, so
    rename it to ucan_ctl_payload-&gt;fw_str and change its type from u8 to
    char.

  - ucan_device_request_in() is only used to retrieve the firmware
    string, so rename it to ucan_get_fw_str() and refactor it to make it
    directly handle all the string termination logic.</Note>
    </Notes>
    <CVE>CVE-2025-22003</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net: atm: fix use after free in lec_send()

The -&gt;send() operation frees skb so save the length before calling
-&gt;send() to avoid a use after free.</Note>
    </Notes>
    <CVE>CVE-2025-22004</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

Bluetooth: Fix error code in chan_alloc_skb_cb()

The chan_alloc_skb_cb() function is supposed to return error pointers on
error.  Returning NULL will lead to a NULL dereference.</Note>
    </Notes>
    <CVE>CVE-2025-22007</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

regulator: check that dummy regulator has been probed before using it

Due to asynchronous driver probing there is a chance that the dummy
regulator hasn't already been probed when first accessing it.</Note>
    </Notes>
    <CVE>CVE-2025-22008</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

regulator: dummy: force synchronous probing

Sometimes I get a NULL pointer dereference at boot time in kobject_get()
with the following call stack:

anatop_regulator_probe()
 devm_regulator_register()
  regulator_register()
   regulator_resolve_supply()
    kobject_get()

By placing some extra BUG_ON() statements I could verify that this is
raised because probing of the 'dummy' regulator driver is not completed
('dummy_regulator_rdev' is still NULL).

In the JTAG debugger I can see that dummy_regulator_probe() and
anatop_regulator_probe() can be run by different kernel threads
(kworker/u4:*).  I haven't further investigated whether this can be
changed or if there are other possibilities to force synchronization
between these two probe routines.  On the other hand I don't expect much
boot time penalty by probing the 'dummy' regulator synchronously.</Note>
    </Notes>
    <CVE>CVE-2025-22009</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

RDMA/hns: Fix soft lockup during bt pages loop

Driver runs a for-loop when allocating bt pages and mapping them with
buffer pages. When a large buffer (e.g. MR over 100GB) is being allocated,
it may require a considerable loop count. This will lead to soft lockup:

        watchdog: BUG: soft lockup - CPU#27 stuck for 22s!
        ...
        Call trace:
         hem_list_alloc_mid_bt+0x124/0x394 [hns_roce_hw_v2]
         hns_roce_hem_list_request+0xf8/0x160 [hns_roce_hw_v2]
         hns_roce_mtr_create+0x2e4/0x360 [hns_roce_hw_v2]
         alloc_mr_pbl+0xd4/0x17c [hns_roce_hw_v2]
         hns_roce_reg_user_mr+0xf8/0x190 [hns_roce_hw_v2]
         ib_uverbs_reg_mr+0x118/0x290

        watchdog: BUG: soft lockup - CPU#35 stuck for 23s!
        ...
        Call trace:
         hns_roce_hem_list_find_mtt+0x7c/0xb0 [hns_roce_hw_v2]
         mtr_map_bufs+0xc4/0x204 [hns_roce_hw_v2]
         hns_roce_mtr_create+0x31c/0x3c4 [hns_roce_hw_v2]
         alloc_mr_pbl+0xb0/0x160 [hns_roce_hw_v2]
         hns_roce_reg_user_mr+0x108/0x1c0 [hns_roce_hw_v2]
         ib_uverbs_reg_mr+0x120/0x2bc

Add a cond_resched() to fix soft lockup during these loops. In order not
to affect the allocation performance of normal-size buffer, set the loop
count of a 100GB MR as the threshold to call cond_resched().</Note>
    </Notes>
    <CVE>CVE-2025-22010</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

KVM: arm64: Unconditionally save+flush host FPSIMD/SVE/SME state

There are several problems with the way hyp code lazily saves the host's
FPSIMD/SVE state, including:

* Host SVE being discarded unexpectedly due to inconsistent
  configuration of TIF_SVE and CPACR_ELx.ZEN. This has been seen to
  result in QEMU crashes where SVE is used by memmove(), as reported by
  Eric Auger:

  https://issues.redhat.com/browse/RHEL-68997

* Host SVE state is discarded *after* modification by ptrace, which was an
  unintentional ptrace ABI change introduced with lazy discarding of SVE state.

* The host FPMR value can be discarded when running a non-protected VM,
  where FPMR support is not exposed to a VM, and that VM uses
  FPSIMD/SVE. In these cases the hyp code does not save the host's FPMR
  before unbinding the host's FPSIMD/SVE/SME state, leaving a stale
  value in memory.

Avoid these by eagerly saving and "flushing" the host's FPSIMD/SVE/SME
state when loading a vCPU such that KVM does not need to save any of the
host's FPSIMD/SVE/SME state. For clarity, fpsimd_kvm_prepare() is
removed and the necessary call to fpsimd_save_and_flush_cpu_state() is
placed in kvm_arch_vcpu_load_fp(). As 'fpsimd_state' and 'fpmr_ptr'
should not be used, they are set to NULL; all uses of these will be
removed in subsequent patches.

Historical problems go back at least as far as v5.17, e.g. erroneous
assumptions about TIF_SVE being clear in commit:

  8383741ab2e773a9 ("KVM: arm64: Get rid of host SVE tracking/saving")

... and so this eager save+flush probably needs to be backported to ALL
stable trees.</Note>
    </Notes>
    <CVE>CVE-2025-22013</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

soc: qcom: pdr: Fix the potential deadlock

When some client process A call pdr_add_lookup() to add the look up for
the service and does schedule locator work, later a process B got a new
server packet indicating locator is up and call pdr_locator_new_server()
which eventually sets pdr-&gt;locator_init_complete to true which process A
sees and takes list lock and queries domain list but it will timeout due
to deadlock as the response will queued to the same qmi-&gt;wq and it is
ordered workqueue and process B is not able to complete new server
request work due to deadlock on list lock.

Fix it by removing the unnecessary list iteration as the list iteration
is already being done inside locator work, so avoid it here and just
call schedule_work() here.

       Process A                        Process B

                                     process_scheduled_works()
pdr_add_lookup()                      qmi_data_ready_work()
 process_scheduled_works()             pdr_locator_new_server()
                                         pdr-&gt;locator_init_complete=true;
   pdr_locator_work()
    mutex_lock(&amp;pdr-&gt;list_lock);

     pdr_locate_service()                  mutex_lock(&amp;pdr-&gt;list_lock);

      pdr_get_domain_list()
       pr_err("PDR: %s get domain list
               txn wait failed: %d\n",
               req-&gt;service_name,
               ret);

Timeout error log due to deadlock:

"
 PDR: tms/servreg get domain list txn wait failed: -110
 PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110
"

Thanks to Bjorn and Johan for letting me know that this commit also fixes
an audio regression when using the in-kernel pd-mapper as that makes it
easier to hit this race. [1]</Note>
    </Notes>
    <CVE>CVE-2025-22014</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

mm/migrate: fix shmem xarray update during migration

A shmem folio can be either in page cache or in swap cache, but not at the
same time.  Namely, once it is in swap cache, folio-&gt;mapping should be
NULL, and the folio is no longer in a shmem mapping.

In __folio_migrate_mapping(), to determine the number of xarray entries to
update, folio_test_swapbacked() is used, but that conflates shmem in page
cache case and shmem in swap cache case.  It leads to xarray multi-index
entry corruption, since it turns a sibling entry to a normal entry during
xas_store() (see [1] for a userspace reproduction).  Fix it by only using
folio_test_swapcache() to determine whether xarray is storing swap cache
entries or not to choose the right number of xarray entries to update.

[1] https://lore.kernel.org/linux-mm/Z8idPCkaJW1IChjT@casper.infradead.org/

Note:
In __split_huge_page(), folio_test_anon() &amp;&amp; folio_test_swapcache() is
used to get swap_cache address space, but that ignores the shmem folio in
swap cache case.  It could lead to NULL pointer dereferencing when a
in-swap-cache shmem folio is split at __xa_store(), since
!folio_test_anon() is true and folio-&gt;mapping is NULL.  But fortunately,
its caller split_huge_page_to_list_to_order() bails out early with EBUSY
when folio-&gt;mapping is NULL.  So no need to take care of it here.</Note>
    </Notes>
    <CVE>CVE-2025-22015</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

dpll: fix xa_alloc_cyclic() error handling

In case of returning 1 from xa_alloc_cyclic() (wrapping) ERR_PTR(1) will
be returned, which will cause IS_ERR() to be false. Which can lead to
dereference not allocated pointer (pin).

Fix it by checking if err is lower than zero.

This wasn't found in real usecase, only noticed. Credit to Pierre.</Note>
    </Notes>
    <CVE>CVE-2025-22016</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

devlink: fix xa_alloc_cyclic() error handling

In case of returning 1 from xa_alloc_cyclic() (wrapping) ERR_PTR(1) will
be returned, which will cause IS_ERR() to be false. Which can lead to
dereference not allocated pointer (rel).

Fix it by checking if err is lower than zero.

This wasn't found in real usecase, only noticed. Credit to Pierre.</Note>
    </Notes>
    <CVE>CVE-2025-22017</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

atm: Fix NULL pointer dereference

When MPOA_cache_impos_rcvd() receives the msg, it can trigger
Null Pointer Dereference Vulnerability if both entry and
holding_time are NULL. Because there is only for the situation
where entry is NULL and holding_time exists, it can be passed
when both entry and holding_time are NULL. If these are NULL,
the entry will be passd to eg_cache_put() as parameter and
it is referenced by entry-&gt;use code in it.

kasan log:

[    3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I
[    3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
[    3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102
[    3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[    3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470
[    3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80
[    3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006
[    3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e
[    3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030
[    3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88
[    3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15
[    3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068
[    3.324185] FS:  000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000
[    3.325042] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0
[    3.326430] Call Trace:
[    3.326725]  &lt;TASK&gt;
[    3.326927]  ? die_addr+0x3c/0xa0
[    3.327330]  ? exc_general_protection+0x161/0x2a0
[    3.327662]  ? asm_exc_general_protection+0x26/0x30
[    3.328214]  ? vprintk_emit+0x15e/0x420
[    3.328543]  ? eg_cache_remove_entry+0xa5/0x470
[    3.328910]  ? eg_cache_remove_entry+0x9a/0x470
[    3.329294]  ? __pfx_eg_cache_remove_entry+0x10/0x10
[    3.329664]  ? console_unlock+0x107/0x1d0
[    3.329946]  ? __pfx_console_unlock+0x10/0x10
[    3.330283]  ? do_syscall_64+0xa6/0x1a0
[    3.330584]  ? entry_SYSCALL_64_after_hwframe+0x47/0x7f
[    3.331090]  ? __pfx_prb_read_valid+0x10/0x10
[    3.331395]  ? down_trylock+0x52/0x80
[    3.331703]  ? vprintk_emit+0x15e/0x420
[    3.331986]  ? __pfx_vprintk_emit+0x10/0x10
[    3.332279]  ? down_trylock+0x52/0x80
[    3.332527]  ? _printk+0xbf/0x100
[    3.332762]  ? __pfx__printk+0x10/0x10
[    3.333007]  ? _raw_write_lock_irq+0x81/0xe0
[    3.333284]  ? __pfx__raw_write_lock_irq+0x10/0x10
[    3.333614]  msg_from_mpoad+0x1185/0x2750
[    3.333893]  ? __build_skb_around+0x27b/0x3a0
[    3.334183]  ? __pfx_msg_from_mpoad+0x10/0x10
[    3.334501]  ? __alloc_skb+0x1c0/0x310
[    3.334809]  ? __pfx___alloc_skb+0x10/0x10
[    3.335283]  ? _raw_spin_lock+0xe0/0xe0
[    3.335632]  ? finish_wait+0x8d/0x1e0
[    3.335975]  vcc_sendmsg+0x684/0xba0
[    3.336250]  ? __pfx_vcc_sendmsg+0x10/0x10
[    3.336587]  ? __pfx_autoremove_wake_function+0x10/0x10
[    3.337056]  ? fdget+0x176/0x3e0
[    3.337348]  __sys_sendto+0x4a2/0x510
[    3.337663]  ? __pfx___sys_sendto+0x10/0x10
[    3.337969]  ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400
[    3.338364]  ? sock_ioctl+0x1bb/0x5a0
[    3.338653]  ? __rseq_handle_notify_resume+0x825/0xd20
[    3.339017]  ? __pfx_sock_ioctl+0x10/0x10
[    3.339316]  ? __pfx___rseq_handle_notify_resume+0x10/0x10
[    3.339727]  ? selinux_file_ioctl+0xa4/0x260
[    3.340166]  __x64_sys_sendto+0xe0/0x1c0
[    3.340526]  ? syscall_exit_to_user_mode+0x123/0x140
[    3.340898]  do_syscall_64+0xa6/0x1a0
[    3.341170]  entry_SYSCALL_64_after_hwframe+0x77/0x7f
[    3.341533] RIP: 0033:0x44a380
[    3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00
[    
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-22018</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

memstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove

This fixes the following crash:

==================================================================
BUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]
Read of size 8 at addr ffff888136335380 by task kworker/6:0/140241

CPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G            E      6.14.0-rc6+ #1
Tainted: [E]=UNSIGNED_MODULE
Hardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024
Workqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms]
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x51/0x70
 print_address_description.constprop.0+0x27/0x320
 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]
 print_report+0x3e/0x70
 kasan_report+0xab/0xe0
 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]
 rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]
 ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms]
 ? __pfx___schedule+0x10/0x10
 ? kick_pool+0x3b/0x270
 process_one_work+0x357/0x660
 worker_thread+0x390/0x4c0
 ? __pfx_worker_thread+0x10/0x10
 kthread+0x190/0x1d0
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x2d/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;

Allocated by task 161446:
 kasan_save_stack+0x20/0x40
 kasan_save_track+0x10/0x30
 __kasan_kmalloc+0x7b/0x90
 __kmalloc_noprof+0x1a7/0x470
 memstick_alloc_host+0x1f/0xe0 [memstick]
 rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms]
 platform_probe+0x60/0xe0
 call_driver_probe+0x35/0x120
 really_probe+0x123/0x410
 __driver_probe_device+0xc7/0x1e0
 driver_probe_device+0x49/0xf0
 __device_attach_driver+0xc6/0x160
 bus_for_each_drv+0xe4/0x160
 __device_attach+0x13a/0x2b0
 bus_probe_device+0xbd/0xd0
 device_add+0x4a5/0x760
 platform_device_add+0x189/0x370
 mfd_add_device+0x587/0x5e0
 mfd_add_devices+0xb1/0x130
 rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb]
 usb_probe_interface+0x15c/0x460
 call_driver_probe+0x35/0x120
 really_probe+0x123/0x410
 __driver_probe_device+0xc7/0x1e0
 driver_probe_device+0x49/0xf0
 __device_attach_driver+0xc6/0x160
 bus_for_each_drv+0xe4/0x160
 __device_attach+0x13a/0x2b0
 rebind_marked_interfaces.isra.0+0xcc/0x110
 usb_reset_device+0x352/0x410
 usbdev_do_ioctl+0xe5c/0x1860
 usbdev_ioctl+0xa/0x20
 __x64_sys_ioctl+0xc5/0xf0
 do_syscall_64+0x59/0x170
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Freed by task 161506:
 kasan_save_stack+0x20/0x40
 kasan_save_track+0x10/0x30
 kasan_save_free_info+0x36/0x60
 __kasan_slab_free+0x34/0x50
 kfree+0x1fd/0x3b0
 device_release+0x56/0xf0
 kobject_cleanup+0x73/0x1c0
 rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms]
 platform_remove+0x2f/0x50
 device_release_driver_internal+0x24b/0x2e0
 bus_remove_device+0x124/0x1d0
 device_del+0x239/0x530
 platform_device_del.part.0+0x19/0xe0
 platform_device_unregister+0x1c/0x40
 mfd_remove_devices_fn+0x167/0x170
 device_for_each_child_reverse+0xc9/0x130
 mfd_remove_devices+0x6e/0xa0
 rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb]
 usb_unbind_interface+0xf3/0x3f0
 device_release_driver_internal+0x24b/0x2e0
 proc_disconnect_claim+0x13d/0x220
 usbdev_do_ioctl+0xb5e/0x1860
 usbdev_ioctl+0xa/0x20
 __x64_sys_ioctl+0xc5/0xf0
 do_syscall_64+0x59/0x170
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Last potentially related work creation:
 kasan_save_stack+0x20/0x40
 kasan_record_aux_stack+0x85/0x90
 insert_work+0x29/0x100
 __queue_work+0x34a/0x540
 call_timer_fn+0x2a/0x160
 expire_timers+0x5f/0x1f0
 __run_timer_base.part.0+0x1b6/0x1e0
 run_timer_softirq+0x8b/0xe0
 handle_softirqs+0xf9/0x360
 __irq_exit_rcu+0x114/0x130
 sysvec_apic_timer_interrupt+0x72/0x90
 asm_sysvec_apic_timer_interrupt+0x16/0x20

Second to last potentially related work creation:
 kasan_save_stack+0x20/0x40
 kasan_record_aux_stack+0x85/0x90
 insert_work+0x29/0x100
 __queue_work+0x34a/0x540
 call_timer_fn+0x2a/0x160
 expire_timers+0x5f/0x1f0
 __run_timer_base.part.0+0x1b6/0x1e0
 run_timer_softirq+0x8b/0xe0
 handle_softirqs+0xf9/0x
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-22020</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

nfsd: put dl_stid if fail to queue dl_recall

Before calling nfsd4_run_cb to queue dl_recall to the callback_wq, we
increment the reference count of dl_stid.
We expect that after the corresponding work_struct is processed, the
reference count of dl_stid will be decremented through the callback
function nfsd4_cb_recall_release.
However, if the call to nfsd4_run_cb fails, the incremented reference
count of dl_stid will not be decremented correspondingly, leading to the
following nfs4_stid leak:
unreferenced object 0xffff88812067b578 (size 344):
  comm "nfsd", pid 2761, jiffies 4295044002 (age 5541.241s)
  hex dump (first 32 bytes):
    01 00 00 00 6b 6b 6b 6b b8 02 c0 e2 81 88 ff ff  ....kkkk........
    00 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 ad 4e ad de  .kkkkkkk.....N..
  backtrace:
    kmem_cache_alloc+0x4b9/0x700
    nfsd4_process_open1+0x34/0x300
    nfsd4_open+0x2d1/0x9d0
    nfsd4_proc_compound+0x7a2/0xe30
    nfsd_dispatch+0x241/0x3e0
    svc_process_common+0x5d3/0xcc0
    svc_process+0x2a3/0x320
    nfsd+0x180/0x2e0
    kthread+0x199/0x1d0
    ret_from_fork+0x30/0x50
    ret_from_fork_asm+0x1b/0x30
unreferenced object 0xffff8881499f4d28 (size 368):
  comm "nfsd", pid 2761, jiffies 4295044005 (age 5541.239s)
  hex dump (first 32 bytes):
    01 00 00 00 00 00 00 00 30 4d 9f 49 81 88 ff ff  ........0M.I....
    30 4d 9f 49 81 88 ff ff 20 00 00 00 01 00 00 00  0M.I.... .......
  backtrace:
    kmem_cache_alloc+0x4b9/0x700
    nfs4_alloc_stid+0x29/0x210
    alloc_init_deleg+0x92/0x2e0
    nfs4_set_delegation+0x284/0xc00
    nfs4_open_delegation+0x216/0x3f0
    nfsd4_process_open2+0x2b3/0xee0
    nfsd4_open+0x770/0x9d0
    nfsd4_proc_compound+0x7a2/0xe30
    nfsd_dispatch+0x241/0x3e0
    svc_process_common+0x5d3/0xcc0
    svc_process+0x2a3/0x320
    nfsd+0x180/0x2e0
    kthread+0x199/0x1d0
    ret_from_fork+0x30/0x50
    ret_from_fork_asm+0x1b/0x30
Fix it by checking the result of nfsd4_run_cb and call nfs4_put_stid if
fail to queue dl_recall.</Note>
    </Notes>
    <CVE>CVE-2025-22025</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

media: streamzap: fix race between device disconnection and urb callback

Syzkaller has reported a general protection fault at function
ir_raw_event_store_with_filter(). This crash is caused by a NULL pointer
dereference of dev-&gt;raw pointer, even though it is checked for NULL in
the same function, which means there is a race condition. It occurs due
to the incorrect order of actions in the streamzap_disconnect() function:
rc_unregister_device() is called before usb_kill_urb(). The dev-&gt;raw
pointer is freed and set to NULL in rc_unregister_device(), and only
after that usb_kill_urb() waits for in-progress requests to finish.

If rc_unregister_device() is called while streamzap_callback() handler is
not finished, this can lead to accessing freed resources. Thus
rc_unregister_device() should be called after usb_kill_urb().

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.</Note>
    </Notes>
    <CVE>CVE-2025-22027</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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">This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2025-22029</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

arm64: Don't call NULL in do_compat_alignment_fixup()

do_alignment_t32_to_handler() only fixes up alignment faults for
specific instructions; it returns NULL otherwise (e.g. LDREX). When
that's the case, signal to the caller that it needs to proceed with the
regular alignment fault handling (i.e. SIGBUS). Without this patch, the
kernel panics:

  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
  Mem abort info:
    ESR = 0x0000000086000006
    EC = 0x21: IABT (current EL), IL = 32 bits
    SET = 0, FnV = 0
    EA = 0, S1PTW = 0
    FSC = 0x06: level 2 translation fault
  user pgtable: 4k pages, 48-bit VAs, pgdp=00000800164aa000
  [0000000000000000] pgd=0800081fdbd22003, p4d=0800081fdbd22003, pud=08000815d51c6003, pmd=0000000000000000
  Internal error: Oops: 0000000086000006 [#1] SMP
  Modules linked in: cfg80211 rfkill xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat br_netfilter veth nvme_fa&gt;
   libcrc32c crc32c_generic raid0 multipath linear dm_mod dax raid1 md_mod xhci_pci nvme xhci_hcd nvme_core t10_pi usbcore igb crc64_rocksoft crc64 crc_t10dif crct10dif_generic crct10dif_ce crct10dif_common usb_common i2c_algo_bit i2c&gt;
  CPU: 2 PID: 3932954 Comm: WPEWebProcess Not tainted 6.1.0-31-arm64 #1  Debian 6.1.128-1
  Hardware name: GIGABYTE MP32-AR1-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021
  pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
  pc : 0x0
  lr : do_compat_alignment_fixup+0xd8/0x3dc
  sp : ffff80000f973dd0
  x29: ffff80000f973dd0 x28: ffff081b42526180 x27: 0000000000000000
  x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
  x23: 0000000000000004 x22: 0000000000000000 x21: 0000000000000001
  x20: 00000000e8551f00 x19: ffff80000f973eb0 x18: 0000000000000000
  x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
  x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
  x11: 0000000000000000 x10: 0000000000000000 x9 : ffffaebc949bc488
  x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
  x5 : 0000000000400000 x4 : 0000fffffffffffe x3 : 0000000000000000
  x2 : ffff80000f973eb0 x1 : 00000000e8551f00 x0 : 0000000000000001
  Call trace:
   0x0
   do_alignment_fault+0x40/0x50
   do_mem_abort+0x4c/0xa0
   el0_da+0x48/0xf0
   el0t_32_sync_handler+0x110/0x140
   el0t_32_sync+0x190/0x194
  Code: bad PC value
  ---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2025-22033</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

exfat: fix random stack corruption after get_block

When get_block is called with a buffer_head allocated on the stack, such
as do_mpage_readpage, stack corruption due to buffer_head UAF may occur in
the following race condition situation.

     &lt;CPU 0&gt;                      &lt;CPU 1&gt;
mpage_read_folio
  &lt;&lt;bh on stack&gt;&gt;
  do_mpage_readpage
    exfat_get_block
      bh_read
        __bh_read
	  get_bh(bh)
          submit_bh
          wait_on_buffer
                              ...
                              end_buffer_read_sync
                                __end_buffer_read_notouch
                                   unlock_buffer
          &lt;&lt;keep going&gt;&gt;
        ...
      ...
    ...
  ...
&lt;&lt;bh is not valid out of mpage_read_folio&gt;&gt;
   .
   .
another_function
  &lt;&lt;variable A on stack&gt;&gt;
                                   put_bh(bh)
                                     atomic_dec(bh-&gt;b_count)
  * stack corruption here *

This patch returns -EAGAIN if a folio does not have buffers when bh_read
needs to be called. By doing this, the caller can fallback to functions
like block_read_full_folio(), create a buffer_head in the folio, and then
call get_block again.

Let's do not call bh_read() with on-stack buffer_head.</Note>
    </Notes>
    <CVE>CVE-2025-22036</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

acpi: nfit: fix narrowing conversion in acpi_nfit_ctl

Syzkaller has reported a warning in to_nfit_bus_uuid(): "only secondary
bus families can be translated". This warning is emited if the argument
is equal to NVDIMM_BUS_FAMILY_NFIT == 0. Function acpi_nfit_ctl() first
verifies that a user-provided value call_pkg-&gt;nd_family of type u64 is
not equal to 0. Then the value is converted to int, and only after that
is compared to NVDIMM_BUS_FAMILY_MAX. This can lead to passing an invalid
argument to acpi_nfit_ctl(), if call_pkg-&gt;nd_family is non-zero, while
the lower 32 bits are zero.

Furthermore, it is best to return EINVAL immediately upon seeing the
invalid user input.  The WARNING is insufficient to prevent further
undefined behavior based on other invalid user input.

All checks of the input value should be applied to the original variable
call_pkg-&gt;nd_family.

[iweiny: update commit message]</Note>
    </Notes>
    <CVE>CVE-2025-22044</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

x86/mm: Fix flush_tlb_range() when used for zapping normal PMDs

On the following path, flush_tlb_range() can be used for zapping normal
PMD entries (PMD entries that point to page tables) together with the PTE
entries in the pointed-to page table:

    collapse_pte_mapped_thp
      pmdp_collapse_flush
        flush_tlb_range

The arm64 version of flush_tlb_range() has a comment describing that it can
be used for page table removal, and does not use any last-level
invalidation optimizations. Fix the X86 version by making it behave the
same way.

Currently, X86 only uses this information for the following two purposes,
which I think means the issue doesn't have much impact:

 - In native_flush_tlb_multi() for checking if lazy TLB CPUs need to be
   IPI'd to avoid issues with speculative page table walks.
 - In Hyper-V TLB paravirtualization, again for lazy TLB stuff.

The patch "x86/mm: only invalidate final translations with INVLPGB" which
is currently under review (see
&lt;https://lore.kernel.org/all/20241230175550.4046587-13-riel@surriel.com/&gt;)
would probably be making the impact of this a lot worse.</Note>
    </Notes>
    <CVE>CVE-2025-22045</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

usbnet:fix NPE during rx_complete

Missing usbnet_going_away Check in Critical Path.
The usb_submit_urb function lacks a usbnet_going_away
validation, whereas __usbnet_queue_skb includes this check.

This inconsistency creates a race condition where:
A URB request may succeed, but the corresponding SKB data
fails to be queued.

Subsequent processes:
(e.g., rx_complete -&gt; defer_bh -&gt; __skb_unlink(skb, list))
attempt to access skb-&gt;next, triggering a NULL pointer
dereference (Kernel Panic).</Note>
    </Notes>
    <CVE>CVE-2025-22050</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net: ibmveth: make veth_pool_store stop hanging

v2:
- Created a single error handling unlock and exit in veth_pool_store
- Greatly expanded commit message with previous explanatory-only text

Summary: Use rtnl_mutex to synchronize veth_pool_store with itself,
ibmveth_close and ibmveth_open, preventing multiple calls in a row to
napi_disable.

Background: Two (or more) threads could call veth_pool_store through
writing to /sys/devices/vio/30000002/pool*/*. You can do this easily
with a little shell script. This causes a hang.

I configured LOCKDEP, compiled ibmveth.c with DEBUG, and built a new
kernel. I ran this test again and saw:

    Setting pool0/active to 0
    Setting pool1/active to 1
    [   73.911067][ T4365] ibmveth 30000002 eth0: close starting
    Setting pool1/active to 1
    Setting pool1/active to 0
    [   73.911367][ T4366] ibmveth 30000002 eth0: close starting
    [   73.916056][ T4365] ibmveth 30000002 eth0: close complete
    [   73.916064][ T4365] ibmveth 30000002 eth0: open starting
    [  110.808564][  T712] systemd-journald[712]: Sent WATCHDOG=1 notification.
    [  230.808495][  T712] systemd-journald[712]: Sent WATCHDOG=1 notification.
    [  243.683786][  T123] INFO: task stress.sh:4365 blocked for more than 122 seconds.
    [  243.683827][  T123]       Not tainted 6.14.0-01103-g2df0c02dab82-dirty #8
    [  243.683833][  T123] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [  243.683838][  T123] task:stress.sh       state:D stack:28096 pid:4365  tgid:4365  ppid:4364   task_flags:0x400040 flags:0x00042000
    [  243.683852][  T123] Call Trace:
    [  243.683857][  T123] [c00000000c38f690] [0000000000000001] 0x1 (unreliable)
    [  243.683868][  T123] [c00000000c38f840] [c00000000001f908] __switch_to+0x318/0x4e0
    [  243.683878][  T123] [c00000000c38f8a0] [c000000001549a70] __schedule+0x500/0x12a0
    [  243.683888][  T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210
    [  243.683896][  T123] [c00000000c38f9d0] [c00000000154ac80] schedule_preempt_disabled+0x30/0x50
    [  243.683904][  T123] [c00000000c38fa00] [c00000000154dbb0] __mutex_lock+0x730/0x10f0
    [  243.683913][  T123] [c00000000c38fb10] [c000000001154d40] napi_enable+0x30/0x60
    [  243.683921][  T123] [c00000000c38fb40] [c000000000f4ae94] ibmveth_open+0x68/0x5dc
    [  243.683928][  T123] [c00000000c38fbe0] [c000000000f4aa20] veth_pool_store+0x220/0x270
    [  243.683936][  T123] [c00000000c38fc70] [c000000000826278] sysfs_kf_write+0x68/0xb0
    [  243.683944][  T123] [c00000000c38fcb0] [c0000000008240b8] kernfs_fop_write_iter+0x198/0x2d0
    [  243.683951][  T123] [c00000000c38fd00] [c00000000071b9ac] vfs_write+0x34c/0x650
    [  243.683958][  T123] [c00000000c38fdc0] [c00000000071bea8] ksys_write+0x88/0x150
    [  243.683966][  T123] [c00000000c38fe10] [c0000000000317f4] system_call_exception+0x124/0x340
    [  243.683973][  T123] [c00000000c38fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec
    ...
    [  243.684087][  T123] Showing all locks held in the system:
    [  243.684095][  T123] 1 lock held by khungtaskd/123:
    [  243.684099][  T123]  #0: c00000000278e370 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x50/0x248
    [  243.684114][  T123] 4 locks held by stress.sh/4365:
    [  243.684119][  T123]  #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150
    [  243.684132][  T123]  #1: c000000041aea888 (&amp;of-&gt;mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x154/0x2d0
    [  243.684143][  T123]  #2: c0000000366fb9a8 (kn-&gt;active#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x160/0x2d0
    [  243.684155][  T123]  #3: c000000035ff4cb8 (&amp;dev-&gt;lock){+.+.}-{3:3}, at: napi_enable+0x30/0x60
    [  243.684166][  T123] 5 locks held by stress.sh/4366:
    [  243.684170][  T123]  #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150
    [  243.
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-22053</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net: fix geneve_opt length integer overflow

struct geneve_opt uses 5 bit length for each single option, which
means every vary size option should be smaller than 128 bytes.

However, all current related Netlink policies cannot promise this
length condition and the attacker can exploit a exact 128-byte size
option to *fake* a zero length option and confuse the parsing logic,
further achieve heap out-of-bounds read.

One example crash log is like below:

[    3.905425] ==================================================================
[    3.905925] BUG: KASAN: slab-out-of-bounds in nla_put+0xa9/0xe0
[    3.906255] Read of size 124 at addr ffff888005f291cc by task poc/177
[    3.906646]
[    3.906775] CPU: 0 PID: 177 Comm: poc-oob-read Not tainted 6.1.132 #1
[    3.907131] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
[    3.907784] Call Trace:
[    3.907925]  &lt;TASK&gt;
[    3.908048]  dump_stack_lvl+0x44/0x5c
[    3.908258]  print_report+0x184/0x4be
[    3.909151]  kasan_report+0xc5/0x100
[    3.909539]  kasan_check_range+0xf3/0x1a0
[    3.909794]  memcpy+0x1f/0x60
[    3.909968]  nla_put+0xa9/0xe0
[    3.910147]  tunnel_key_dump+0x945/0xba0
[    3.911536]  tcf_action_dump_1+0x1c1/0x340
[    3.912436]  tcf_action_dump+0x101/0x180
[    3.912689]  tcf_exts_dump+0x164/0x1e0
[    3.912905]  fw_dump+0x18b/0x2d0
[    3.913483]  tcf_fill_node+0x2ee/0x460
[    3.914778]  tfilter_notify+0xf4/0x180
[    3.915208]  tc_new_tfilter+0xd51/0x10d0
[    3.918615]  rtnetlink_rcv_msg+0x4a2/0x560
[    3.919118]  netlink_rcv_skb+0xcd/0x200
[    3.919787]  netlink_unicast+0x395/0x530
[    3.921032]  netlink_sendmsg+0x3d0/0x6d0
[    3.921987]  __sock_sendmsg+0x99/0xa0
[    3.922220]  __sys_sendto+0x1b7/0x240
[    3.922682]  __x64_sys_sendto+0x72/0x90
[    3.922906]  do_syscall_64+0x5e/0x90
[    3.923814]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[    3.924122] RIP: 0033:0x7e83eab84407
[    3.924331] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 &lt;5b&gt; c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf
[    3.925330] RSP: 002b:00007ffff505e370 EFLAGS: 00000202 ORIG_RAX: 000000000000002c
[    3.925752] RAX: ffffffffffffffda RBX: 00007e83eaafa740 RCX: 00007e83eab84407
[    3.926173] RDX: 00000000000001a8 RSI: 00007ffff505e3c0 RDI: 0000000000000003
[    3.926587] RBP: 00007ffff505f460 R08: 00007e83eace1000 R09: 000000000000000c
[    3.926977] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffff505f3c0
[    3.927367] R13: 00007ffff505f5c8 R14: 00007e83ead1b000 R15: 00005d4fbbe6dcb8

Fix these issues by enforing correct length condition in related
policies.</Note>
    </Notes>
    <CVE>CVE-2025-22055</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

udp: Fix memory accounting leak.

Matt Dowling reported a weird UDP memory usage issue.

Under normal operation, the UDP memory usage reported in /proc/net/sockstat
remains close to zero.  However, it occasionally spiked to 524,288 pages
and never dropped.  Moreover, the value doubled when the application was
terminated.  Finally, it caused intermittent packet drops.

We can reproduce the issue with the script below [0]:

  1. /proc/net/sockstat reports 0 pages

    # cat /proc/net/sockstat | grep UDP:
    UDP: inuse 1 mem 0

  2. Run the script till the report reaches 524,288

    # python3 test.py &amp; sleep 5
    # cat /proc/net/sockstat | grep UDP:
    UDP: inuse 3 mem 524288  &lt;-- (INT_MAX + 1) &gt;&gt; PAGE_SHIFT

  3. Kill the socket and confirm the number never drops

    # pkill python3 &amp;&amp; sleep 5
    # cat /proc/net/sockstat | grep UDP:
    UDP: inuse 1 mem 524288

  4. (necessary since v6.0) Trigger proto_memory_pcpu_drain()

    # python3 test.py &amp; sleep 1 &amp;&amp; pkill python3

  5. The number doubles

    # cat /proc/net/sockstat | grep UDP:
    UDP: inuse 1 mem 1048577

The application set INT_MAX to SO_RCVBUF, which triggered an integer
overflow in udp_rmem_release().

When a socket is close()d, udp_destruct_common() purges its receive
queue and sums up skb-&gt;truesize in the queue.  This total is calculated
and stored in a local unsigned integer variable.

The total size is then passed to udp_rmem_release() to adjust memory
accounting.  However, because the function takes a signed integer
argument, the total size can wrap around, causing an overflow.

Then, the released amount is calculated as follows:

  1) Add size to sk-&gt;sk_forward_alloc.
  2) Round down sk-&gt;sk_forward_alloc to the nearest lower multiple of
      PAGE_SIZE and assign it to amount.
  3) Subtract amount from sk-&gt;sk_forward_alloc.
  4) Pass amount &gt;&gt; PAGE_SHIFT to __sk_mem_reduce_allocated().

When the issue occurred, the total in udp_destruct_common() was 2147484480
(INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release().

At 1) sk-&gt;sk_forward_alloc is changed from 3264 to -2147479552, and
2) sets -2147479552 to amount.  3) reverts the wraparound, so we don't
see a warning in inet_sock_destruct().  However, udp_memory_allocated
ends up doubling at 4).

Since commit 3cd3399dd7a8 ("net: implement per-cpu reserves for
memory_allocated"), memory usage no longer doubles immediately after
a socket is close()d because __sk_mem_reduce_allocated() caches the
amount in udp_memory_per_cpu_fw_alloc.  However, the next time a UDP
socket receives a packet, the subtraction takes effect, causing UDP
memory usage to double.

This issue makes further memory allocation fail once the socket's
sk-&gt;sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packet
drops.

To prevent this issue, let's use unsigned int for the calculation and
call sk_forward_alloc_add() only once for the small delta.

Note that first_packet_length() also potentially has the same problem.

[0]:
from socket import *

SO_RCVBUFFORCE = 33
INT_MAX = (2 ** 31) - 1

s = socket(AF_INET, SOCK_DGRAM)
s.bind(('', 0))
s.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX)

c = socket(AF_INET, SOCK_DGRAM)
c.connect(s.getsockname())

data = b'a' * 100

while True:
    c.send(data)</Note>
    </Notes>
    <CVE>CVE-2025-22058</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net: mvpp2: Prevent parser TCAM memory corruption

Protect the parser TCAM/SRAM memory, and the cached (shadow) SRAM
information, from concurrent modifications.

Both the TCAM and SRAM tables are indirectly accessed by configuring
an index register that selects the row to read or write to. This means
that operations must be atomic in order to, e.g., avoid spreading
writes across multiple rows. Since the shadow SRAM array is used to
find free rows in the hardware table, it must also be protected in
order to avoid TOCTOU errors where multiple cores allocate the same
row.

This issue was detected in a situation where `mvpp2_set_rx_mode()` ran
concurrently on two CPUs. In this particular case the
MVPP2_PE_MAC_UC_PROMISCUOUS entry was corrupted, causing the
classifier unit to drop all incoming unicast - indicated by the
`rx_classifier_drops` counter.</Note>
    </Notes>
    <CVE>CVE-2025-22060</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

sctp: add mutual exclusion in proc_sctp_do_udp_port()

We must serialize calls to sctp_udp_sock_stop() and sctp_udp_sock_start()
or risk a crash as syzbot reported:

Oops: general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]
CPU: 1 UID: 0 PID: 6551 Comm: syz.1.44 Not tainted 6.14.0-syzkaller-g7f2ff7b62617 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
 RIP: 0010:kernel_sock_shutdown+0x47/0x70 net/socket.c:3653
Call Trace:
 &lt;TASK&gt;
  udp_tunnel_sock_release+0x68/0x80 net/ipv4/udp_tunnel_core.c:181
  sctp_udp_sock_stop+0x71/0x160 net/sctp/protocol.c:930
  proc_sctp_do_udp_port+0x264/0x450 net/sctp/sysctl.c:553
  proc_sys_call_handler+0x3d0/0x5b0 fs/proc/proc_sysctl.c:601
  iter_file_splice_write+0x91c/0x1150 fs/splice.c:738
  do_splice_from fs/splice.c:935 [inline]
  direct_splice_actor+0x18f/0x6c0 fs/splice.c:1158
  splice_direct_to_actor+0x342/0xa30 fs/splice.c:1102
  do_splice_direct_actor fs/splice.c:1201 [inline]
  do_splice_direct+0x174/0x240 fs/splice.c:1227
  do_sendfile+0xafd/0xe50 fs/read_write.c:1368
  __do_sys_sendfile64 fs/read_write.c:1429 [inline]
  __se_sys_sendfile64 fs/read_write.c:1415 [inline]
  __x64_sys_sendfile64+0x1d8/0x220 fs/read_write.c:1415
  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]</Note>
    </Notes>
    <CVE>CVE-2025-22062</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

netfilter: nf_tables: don't unregister hook when table is dormant

When nf_tables_updchain encounters an error, hook registration needs to
be rolled back.

This should only be done if the hook has been registered, which won't
happen when the table is flagged as dormant (inactive).

Just move the assignment into the registration block.</Note>
    </Notes>
    <CVE>CVE-2025-22064</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

idpf: fix adapter NULL pointer dereference on reboot

With SRIOV enabled, idpf ends up calling into idpf_remove() twice.
First via idpf_shutdown() and then again when idpf_remove() calls into
sriov_disable(), because the VF devices use the idpf driver, hence the
same remove routine. When that happens, it is possible for the adapter
to be NULL from the first call to idpf_remove(), leading to a NULL
pointer dereference.

echo 1 &gt; /sys/class/net/&lt;netif&gt;/device/sriov_numvfs
reboot

BUG: kernel NULL pointer dereference, address: 0000000000000020
...
RIP: 0010:idpf_remove+0x22/0x1f0 [idpf]
...
? idpf_remove+0x22/0x1f0 [idpf]
? idpf_remove+0x1e4/0x1f0 [idpf]
pci_device_remove+0x3f/0xb0
device_release_driver_internal+0x19f/0x200
pci_stop_bus_device+0x6d/0x90
pci_stop_and_remove_bus_device+0x12/0x20
pci_iov_remove_virtfn+0xbe/0x120
sriov_disable+0x34/0xe0
idpf_sriov_configure+0x58/0x140 [idpf]
idpf_remove+0x1b9/0x1f0 [idpf]
idpf_shutdown+0x12/0x30 [idpf]
pci_device_shutdown+0x35/0x60
device_shutdown+0x156/0x200
...

Replace the direct idpf_remove() call in idpf_shutdown() with
idpf_vc_core_deinit() and idpf_deinit_dflt_mbx(), which perform
the bulk of the cleanup, such as stopping the init task, freeing IRQs,
destroying the vports and freeing the mailbox. This avoids the calls to
sriov_disable() in addition to a small netdev cleanup, and destroying
workqueues, which don't seem to be required on shutdown.</Note>
    </Notes>
    <CVE>CVE-2025-22065</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

rtnetlink: Allocate vfinfo size for VF GUIDs when supported

Commit 30aad41721e0 ("net/core: Add support for getting VF GUIDs")
added support for getting VF port and node GUIDs in netlink ifinfo
messages, but their size was not taken into consideration in the
function that allocates the netlink message, causing the following
warning when a netlink message is filled with many VF port and node
GUIDs:
 # echo 64 &gt; /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs
 # ip link show dev ib0
 RTNETLINK answers: Message too long
 Cannot send link get request: Message too long

Kernel warning:

 ------------[ cut here ]------------
 WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0
 Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core
 CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
 RIP: 0010:rtnl_getlink+0x586/0x5a0
 Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff &lt;0f&gt; 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00
 RSP: 0018:ffff888113557348 EFLAGS: 00010246
 RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000
 RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8
 RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000
 R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00
 R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff
 FS:  00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 PKRU: 55555554
 Call Trace:
  &lt;TASK&gt;
  ? __warn+0xa5/0x230
  ? rtnl_getlink+0x586/0x5a0
  ? report_bug+0x22d/0x240
  ? handle_bug+0x53/0xa0
  ? exc_invalid_op+0x14/0x50
  ? asm_exc_invalid_op+0x16/0x20
  ? skb_trim+0x6a/0x80
  ? rtnl_getlink+0x586/0x5a0
  ? __pfx_rtnl_getlink+0x10/0x10
  ? rtnetlink_rcv_msg+0x1e5/0x860
  ? __pfx___mutex_lock+0x10/0x10
  ? rcu_is_watching+0x34/0x60
  ? __pfx_lock_acquire+0x10/0x10
  ? stack_trace_save+0x90/0xd0
  ? filter_irq_stacks+0x1d/0x70
  ? kasan_save_stack+0x30/0x40
  ? kasan_save_stack+0x20/0x40
  ? kasan_save_track+0x10/0x30
  rtnetlink_rcv_msg+0x21c/0x860
  ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
  ? __pfx_rtnetlink_rcv_msg+0x10/0x10
  ? arch_stack_walk+0x9e/0xf0
  ? rcu_is_watching+0x34/0x60
  ? lock_acquire+0xd5/0x410
  ? rcu_is_watching+0x34/0x60
  netlink_rcv_skb+0xe0/0x210
  ? __pfx_rtnetlink_rcv_msg+0x10/0x10
  ? __pfx_netlink_rcv_skb+0x10/0x10
  ? rcu_is_watching+0x34/0x60
  ? __pfx___netlink_lookup+0x10/0x10
  ? lock_release+0x62/0x200
  ? netlink_deliver_tap+0xfd/0x290
  ? rcu_is_watching+0x34/0x60
  ? lock_release+0x62/0x200
  ? netlink_deliver_tap+0x95/0x290
  netlink_unicast+0x31f/0x480
  ? __pfx_netlink_unicast+0x10/0x10
  ? rcu_is_watching+0x34/0x60
  ? lock_acquire+0xd5/0x410
  netlink_sendmsg+0x369/0x660
  ? lock_release+0x62/0x200
  ? __pfx_netlink_sendmsg+0x10/0x10
  ? import_ubuf+0xb9/0xf0
  ? __import_iovec+0x254/0x2b0
  ? lock_release+0x62/0x200
  ? __pfx_netlink_sendmsg+0x10/0x10
  ____sys_sendmsg+0x559/0x5a0
  ? __pfx_____sys_sendmsg+0x10/0x10
  ? __pfx_copy_msghdr_from_user+0x10/0x10
  ? rcu_is_watching+0x34/0x60
  ? do_read_fault+0x213/0x4a0
  ? rcu_is_watching+0x34/0x60
  ___sys_sendmsg+0xe4/0x150
  ? __pfx____sys_sendmsg+0x10/0x10
  ? do_fault+0x2cc/0x6f0
  ? handle_pte_fault+0x2e3/0x3d0
  ? __pfx_handle_pte_fault+0x10/0x10
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-22075</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

fs/ntfs3: Prevent integer overflow in hdr_first_de()

The "de_off" and "used" variables come from the disk so they both need to
check.  The problem is that on 32bit systems if they're both greater than
UINT_MAX - 16 then the check does work as intended because of an integer
overflow.</Note>
    </Notes>
    <CVE>CVE-2025-22080</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow

When cur_qp isn't NULL, in order to avoid fetching the QP from
the radix tree again we check if the next cqe QP is identical to
the one we already have.

The bug however is that we are checking if the QP is identical by
checking the QP number inside the CQE against the QP number inside the
mlx5_ib_qp, but that's wrong since the QP number from the CQE is from
FW so it should be matched against mlx5_core_qp which is our FW QP
number.

Otherwise we could use the wrong QP when handling a CQE which could
cause the kernel trace below.

This issue is mainly noticeable over QPs 0 &amp; 1, since for now they are
the only QPs in our driver whereas the QP number inside mlx5_ib_qp
doesn't match the QP number inside mlx5_core_qp.

BUG: kernel NULL pointer dereference, address: 0000000000000012
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: Oops: 0000 [#1] SMP
 CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]
 RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib]
 Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 &lt;0f&gt; b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21
 RSP: 0018:ffff88810511bd60 EFLAGS: 00010046
 RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a
 RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10
 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000
 R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0
 FS:  0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0
 Call Trace:
  &lt;TASK&gt;
  ? __die+0x20/0x60
  ? page_fault_oops+0x150/0x3e0
  ? exc_page_fault+0x74/0x130
  ? asm_exc_page_fault+0x22/0x30
  ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib]
  __ib_process_cq+0x5a/0x150 [ib_core]
  ib_cq_poll_work+0x31/0x90 [ib_core]
  process_one_work+0x169/0x320
  worker_thread+0x288/0x3a0
  ? work_busy+0xb0/0xb0
  kthread+0xd7/0x1f0
  ? kthreads_online_cpu+0x130/0x130
  ? kthreads_online_cpu+0x130/0x130
  ret_from_fork+0x2d/0x50
  ? kthreads_online_cpu+0x130/0x130
  ret_from_fork_asm+0x11/0x20
  &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2025-22086</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

RDMA/erdma: Prevent use-after-free in erdma_accept_newconn()

After the erdma_cep_put(new_cep) being called, new_cep will be freed,
and the following dereference will cause a UAF problem. Fix this issue.</Note>
    </Notes>
    <CVE>CVE-2025-22088</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range()

If track_pfn_copy() fails, we already added the dst VMA to the maple
tree. As fork() fails, we'll cleanup the maple tree, and stumble over
the dst VMA for which we neither performed any reservation nor copied
any page tables.

Consequently untrack_pfn() will see VM_PAT and try obtaining the
PAT information from the page table -- which fails because the page
table was not copied.

The easiest fix would be to simply clear the VM_PAT flag of the dst VMA
if track_pfn_copy() fails. However, the whole thing is about "simply"
clearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy()
and performed a reservation, but copying the page tables fails, we'll
simply clear the VM_PAT flag, not properly undoing the reservation ...
which is also wrong.

So let's fix it properly: set the VM_PAT flag only if the reservation
succeeded (leaving it clear initially), and undo the reservation if
anything goes wrong while copying the page tables: clearing the VM_PAT
flag after undoing the reservation.

Note that any copied page table entries will get zapped when the VMA will
get removed later, after copy_page_range() succeeded; as VM_PAT is not set
then, we won't try cleaning VM_PAT up once more and untrack_pfn() will be
happy. Note that leaving these page tables in place without a reservation
is not a problem, as we are aborting fork(); this process will never run.

A reproducer can trigger this usually at the first try:

  https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c

  WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110
  Modules linked in: ...
  CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ #92
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014
  RIP: 0010:get_pat_info+0xf6/0x110
  ...
  Call Trace:
   &lt;TASK&gt;
   ...
   untrack_pfn+0x52/0x110
   unmap_single_vma+0xa6/0xe0
   unmap_vmas+0x105/0x1f0
   exit_mmap+0xf6/0x460
   __mmput+0x4b/0x120
   copy_process+0x1bf6/0x2aa0
   kernel_clone+0xab/0x440
   __do_sys_clone+0x66/0x90
   do_syscall_64+0x95/0x180

Likely this case was missed in:

  d155df53f310 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed")

... and instead of undoing the reservation we simply cleared the VM_PAT flag.

Keep the documentation of these functions in include/linux/pgtable.h,
one place is more than sufficient -- we should clean that up for the other
functions like track_pfn_remap/untrack_pfn separately.</Note>
    </Notes>
    <CVE>CVE-2025-22090</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

drm/amd/display: avoid NPD when ASIC does not support DMUB

ctx-&gt;dmub_srv will de NULL if the ASIC does not support DMUB, which is
tested in dm_dmub_sw_init.

However, it will be dereferenced in dmub_hw_lock_mgr_cmd if
should_use_dmub_lock returns true.

This has been the case since dmub support has been added for PSR1.

Fix this by checking for dmub_srv in should_use_dmub_lock.

[   37.440832] BUG: kernel NULL pointer dereference, address: 0000000000000058
[   37.447808] #PF: supervisor read access in kernel mode
[   37.452959] #PF: error_code(0x0000) - not-present page
[   37.458112] PGD 0 P4D 0
[   37.460662] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
[   37.465553] CPU: 2 UID: 1000 PID: 1745 Comm: DrmThread Not tainted 6.14.0-rc1-00003-gd62e938120f0 #23 99720e1cb1e0fc4773b8513150932a07de3c6e88
[   37.478324] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023
[   37.487103] RIP: 0010:dmub_hw_lock_mgr_cmd+0x77/0xb0
[   37.492074] Code: 44 24 0e 00 00 00 00 48 c7 04 24 45 00 00 0c 40 88 74 24 0d 0f b6 02 88 44 24 0c 8b 01 89 44 24 08 85 f6 75 05 c6 44 24 0e 01 &lt;48&gt; 8b 7f 58 48 89 e6 ba 01 00 00 00 e8 08 3c 2a 00 65 48 8b 04 5
[   37.510822] RSP: 0018:ffff969442853300 EFLAGS: 00010202
[   37.516052] RAX: 0000000000000000 RBX: ffff92db03000000 RCX: ffff969442853358
[   37.523185] RDX: ffff969442853368 RSI: 0000000000000001 RDI: 0000000000000000
[   37.530322] RBP: 0000000000000001 R08: 00000000000004a7 R09: 00000000000004a5
[   37.537453] R10: 0000000000000476 R11: 0000000000000062 R12: ffff92db0ade8000
[   37.544589] R13: ffff92da01180ae0 R14: ffff92da011802a8 R15: ffff92db03000000
[   37.551725] FS:  0000784a9cdfc6c0(0000) GS:ffff92db2af00000(0000) knlGS:0000000000000000
[   37.559814] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   37.565562] CR2: 0000000000000058 CR3: 0000000112b1c000 CR4: 00000000003506f0
[   37.572697] Call Trace:
[   37.575152]  &lt;TASK&gt;
[   37.577258]  ? __die_body+0x66/0xb0
[   37.580756]  ? page_fault_oops+0x3e7/0x4a0
[   37.584861]  ? exc_page_fault+0x3e/0xe0
[   37.588706]  ? exc_page_fault+0x5c/0xe0
[   37.592550]  ? asm_exc_page_fault+0x22/0x30
[   37.596742]  ? dmub_hw_lock_mgr_cmd+0x77/0xb0
[   37.601107]  dcn10_cursor_lock+0x1e1/0x240
[   37.605211]  program_cursor_attributes+0x81/0x190
[   37.609923]  commit_planes_for_stream+0x998/0x1ef0
[   37.614722]  update_planes_and_stream_v2+0x41e/0x5c0
[   37.619703]  dc_update_planes_and_stream+0x78/0x140
[   37.624588]  amdgpu_dm_atomic_commit_tail+0x4362/0x49f0
[   37.629832]  ? srso_return_thunk+0x5/0x5f
[   37.633847]  ? mark_held_locks+0x6d/0xd0
[   37.637774]  ? _raw_spin_unlock_irq+0x24/0x50
[   37.642135]  ? srso_return_thunk+0x5/0x5f
[   37.646148]  ? lockdep_hardirqs_on+0x95/0x150
[   37.650510]  ? srso_return_thunk+0x5/0x5f
[   37.654522]  ? _raw_spin_unlock_irq+0x2f/0x50
[   37.658883]  ? srso_return_thunk+0x5/0x5f
[   37.662897]  ? wait_for_common+0x186/0x1c0
[   37.666998]  ? srso_return_thunk+0x5/0x5f
[   37.671009]  ? drm_crtc_next_vblank_start+0xc3/0x170
[   37.675983]  commit_tail+0xf5/0x1c0
[   37.679478]  drm_atomic_helper_commit+0x2a2/0x2b0
[   37.684186]  drm_atomic_commit+0xd6/0x100
[   37.688199]  ? __cfi___drm_printfn_info+0x10/0x10
[   37.692911]  drm_atomic_helper_update_plane+0xe5/0x130
[   37.698054]  drm_mode_cursor_common+0x501/0x670
[   37.702600]  ? __cfi_drm_mode_cursor_ioctl+0x10/0x10
[   37.707572]  drm_mode_cursor_ioctl+0x48/0x70
[   37.711851]  drm_ioctl_kernel+0xf2/0x150
[   37.715781]  drm_ioctl+0x363/0x590
[   37.719189]  ? __cfi_drm_mode_cursor_ioctl+0x10/0x10
[   37.724165]  amdgpu_drm_ioctl+0x41/0x80
[   37.728013]  __se_sys_ioctl+0x7f/0xd0
[   37.731685]  do_syscall_64+0x87/0x100
[   37.735355]  ? vma_end_read+0x12/0xe0
[   37.739024]  ? srso_return_thunk+0x5/0x5f
[   37.743041]  ? find_held_lock+0x47/0xf0
[   37.746884]  ? vma_end_read+0x12/0xe0
[   37.750552]  ? srso_return_thunk+0x5/0
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-22093</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

drm/vkms: Fix use after free and double free on init error

If the driver initialization fails, the vkms_exit() function might
access an uninitialized or freed default_config pointer and it might
double free it.

Fix both possible errors by initializing default_config only when the
driver initialization succeeded.</Note>
    </Notes>
    <CVE>CVE-2025-22097</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

Bluetooth: btnxpuart: Fix kernel panic during FW release

This fixes a kernel panic seen during release FW in a stress test
scenario where WLAN and BT FW download occurs simultaneously, and due to
a HW bug, chip sends out only 1 bootloader signatures.

When driver receives the bootloader signature, it enters FW download
mode, but since no consequtive bootloader signatures seen, FW file is
not requested.

After 60 seconds, when FW download times out, release_firmware causes a
kernel panic.

[ 2601.949184] Unable to handle kernel paging request at virtual address 0000312e6f006573
[ 2601.992076] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000111802000
[ 2601.992080] [0000312e6f006573] pgd=0000000000000000, p4d=0000000000000000
[ 2601.992087] Internal error: Oops: 0000000096000021 [#1] PREEMPT SMP
[ 2601.992091] Modules linked in: algif_hash algif_skcipher af_alg btnxpuart(O) pciexxx(O) mlan(O) overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce snd_soc_fsl_easrc snd_soc_fsl_asoc_card imx8_media_dev(C) snd_soc_fsl_micfil polyval_generic snd_soc_fsl_xcvr snd_soc_fsl_sai snd_soc_imx_audmux snd_soc_fsl_asrc snd_soc_imx_card snd_soc_imx_hdmi snd_soc_fsl_aud2htx snd_soc_fsl_utils imx_pcm_dma dw_hdmi_cec flexcan can_dev
[ 2602.001825] CPU: 2 PID: 20060 Comm: hciconfig Tainted: G         C O       6.6.23-lts-next-06236-gb586a521770e #1
[ 2602.010182] Hardware name: NXP i.MX8MPlus EVK board (DT)
[ 2602.010185] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 2602.010191] pc : _raw_spin_lock+0x34/0x68
[ 2602.010201] lr : free_fw_priv+0x20/0xfc
[ 2602.020561] sp : ffff800089363b30
[ 2602.020563] x29: ffff800089363b30 x28: ffff0000d0eb5880 x27: 0000000000000000
[ 2602.020570] x26: 0000000000000000 x25: ffff0000d728b330 x24: 0000000000000000
[ 2602.020577] x23: ffff0000dc856f38
[ 2602.033797] x22: ffff800089363b70 x21: ffff0000dc856000
[ 2602.033802] x20: ff00312e6f006573 x19: ffff0000d0d9ea80 x18: 0000000000000000
[ 2602.033809] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaad80dd480
[ 2602.083320] x14: 0000000000000000 x13: 00000000000001b9 x12: 0000000000000002
[ 2602.083326] x11: 0000000000000000 x10: 0000000000000a60 x9 : ffff800089363a30
[ 2602.083333] x8 : ffff0001793d75c0 x7 : ffff0000d6dbc400 x6 : 0000000000000000
[ 2602.083339] x5 : 00000000410fd030 x4 : 0000000000000000 x3 : 0000000000000001
[ 2602.083346] x2 : 0000000000000000 x1 : 0000000000000001 x0 : ff00312e6f006573
[ 2602.083354] Call trace:
[ 2602.083356]  _raw_spin_lock+0x34/0x68
[ 2602.083364]  release_firmware+0x48/0x6c
[ 2602.083370]  nxp_setup+0x3c4/0x540 [btnxpuart]
[ 2602.083383]  hci_dev_open_sync+0xf0/0xa34
[ 2602.083391]  hci_dev_open+0xd8/0x178
[ 2602.083399]  hci_sock_ioctl+0x3b0/0x590
[ 2602.083405]  sock_do_ioctl+0x60/0x118
[ 2602.083413]  sock_ioctl+0x2f4/0x374
[ 2602.091430]  __arm64_sys_ioctl+0xac/0xf0
[ 2602.091437]  invoke_syscall+0x48/0x110
[ 2602.091445]  el0_svc_common.constprop.0+0xc0/0xe0
[ 2602.091452]  do_el0_svc+0x1c/0x28
[ 2602.091457]  el0_svc+0x40/0xe4
[ 2602.091465]  el0t_64_sync_handler+0x120/0x12c
[ 2602.091470]  el0t_64_sync+0x190/0x194</Note>
    </Notes>
    <CVE>CVE-2025-22102</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ibmvnic: Use kernel helpers for hex dumps

Previously, when the driver was printing hex dumps, the buffer was cast
to an 8 byte long and printed using string formatters. If the buffer
size was not a multiple of 8 then a read buffer overflow was possible.

Therefore, create a new ibmvnic function that loops over a buffer and
calls hex_dump_to_buffer instead.

This patch address KASAN reports like the one below:
  ibmvnic 30000003 env3: Login Buffer:
  ibmvnic 30000003 env3: 01000000af000000
  &lt;...&gt;
  ibmvnic 30000003 env3: 2e6d62692e736261
  ibmvnic 30000003 env3: 65050003006d6f63
  ==================================================================
  BUG: KASAN: slab-out-of-bounds in ibmvnic_login+0xacc/0xffc [ibmvnic]
  Read of size 8 at addr c0000001331a9aa8 by task ip/17681
  &lt;...&gt;
  Allocated by task 17681:
  &lt;...&gt;
  ibmvnic_login+0x2f0/0xffc [ibmvnic]
  ibmvnic_open+0x148/0x308 [ibmvnic]
  __dev_open+0x1ac/0x304
  &lt;...&gt;
  The buggy address is located 168 bytes inside of
                allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf)
  &lt;...&gt;
  =================================================================
  ibmvnic 30000003 env3: 000000000033766e</Note>
    </Notes>
    <CVE>CVE-2025-22104</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

bonding: check xdp prog when set bond mode

Following operations can trigger a warning[1]:

    ip netns add ns1
    ip netns exec ns1 ip link add bond0 type bond mode balance-rr
    ip netns exec ns1 ip link set dev bond0 xdp obj af_xdp_kern.o sec xdp
    ip netns exec ns1 ip link set bond0 type bond mode broadcast
    ip netns del ns1

When delete the namespace, dev_xdp_uninstall() is called to remove xdp
program on bond dev, and bond_xdp_set() will check the bond mode. If bond
mode is changed after attaching xdp program, the warning may occur.

Some bond modes (broadcast, etc.) do not support native xdp. Set bond mode
with xdp program attached is not good. Add check for xdp program when set
bond mode.

    [1]
    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 11 at net/core/dev.c:9912 unregister_netdevice_many_notify+0x8d9/0x930
    Modules linked in:
    CPU: 0 UID: 0 PID: 11 Comm: kworker/u4:0 Not tainted 6.14.0-rc4 #107
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
    Workqueue: netns cleanup_net
    RIP: 0010:unregister_netdevice_many_notify+0x8d9/0x930
    Code: 00 00 48 c7 c6 6f e3 a2 82 48 c7 c7 d0 b3 96 82 e8 9c 10 3e ...
    RSP: 0018:ffffc90000063d80 EFLAGS: 00000282
    RAX: 00000000ffffffa1 RBX: ffff888004959000 RCX: 00000000ffffdfff
    RDX: 0000000000000000 RSI: 00000000ffffffea RDI: ffffc90000063b48
    RBP: ffffc90000063e28 R08: ffffffff82d39b28 R09: 0000000000009ffb
    R10: 0000000000000175 R11: ffffffff82d09b40 R12: ffff8880049598e8
    R13: 0000000000000001 R14: dead000000000100 R15: ffffc90000045000
    FS:  0000000000000000(0000) GS:ffff888007a00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000000000d406b60 CR3: 000000000483e000 CR4: 00000000000006f0
    Call Trace:
     &lt;TASK&gt;
     ? __warn+0x83/0x130
     ? unregister_netdevice_many_notify+0x8d9/0x930
     ? report_bug+0x18e/0x1a0
     ? handle_bug+0x54/0x90
     ? exc_invalid_op+0x18/0x70
     ? asm_exc_invalid_op+0x1a/0x20
     ? unregister_netdevice_many_notify+0x8d9/0x930
     ? bond_net_exit_batch_rtnl+0x5c/0x90
     cleanup_net+0x237/0x3d0
     process_one_work+0x163/0x390
     worker_thread+0x293/0x3b0
     ? __pfx_worker_thread+0x10/0x10
     kthread+0xec/0x1e0
     ? __pfx_kthread+0x10/0x10
     ? __pfx_kthread+0x10/0x10
     ret_from_fork+0x2f/0x50
     ? __pfx_kthread+0x10/0x10
     ret_from_fork_asm+0x1a/0x30
     &lt;/TASK&gt;
    ---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2025-22105</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

vmxnet3: unregister xdp rxq info in the reset path

vmxnet3 does not unregister xdp rxq info in the
vmxnet3_reset_work() code path as vmxnet3_rq_destroy()
is not invoked in this code path. So, we get below message with a
backtrace.

Missing unregister, handled but fix driver
WARNING: CPU:48 PID: 500 at net/core/xdp.c:182
__xdp_rxq_info_reg+0x93/0xf0

This patch fixes the problem by moving the unregister
code of XDP from vmxnet3_rq_destroy() to vmxnet3_rq_cleanup().</Note>
    </Notes>
    <CVE>CVE-2025-22106</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry()

There are actually 2 problems:
- deleting the last element doesn't require the memmove of elements
  [i + 1, end) over it. Actually, element i+1 is out of bounds.
- The memmove itself should move size - i - 1 elements, because the last
  element is out of bounds.

The out-of-bounds element still remains out of bounds after being
accessed, so the problem is only that we touch it, not that it becomes
in active use. But I suppose it can lead to issues if the out-of-bounds
element is part of an unmapped page.</Note>
    </Notes>
    <CVE>CVE-2025-22107</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

bnxt_en: Mask the bd_cnt field in the TX BD properly

The bd_cnt field in the TX BD specifies the total number of BDs for
the TX packet.  The bd_cnt field has 5 bits and the maximum number
supported is 32 with the value 0.

CONFIG_MAX_SKB_FRAGS can be modified and the total number of SKB
fragments can approach or exceed the maximum supported by the chip.
Add a macro to properly mask the bd_cnt field so that the value 32
will be properly masked and set to 0 in the bd_cnd field.

Without this patch, the out-of-range bd_cnt value will corrupt the
TX BD and may cause TX timeout.

The next patch will check for values exceeding 32.</Note>
    </Notes>
    <CVE>CVE-2025-22108</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ax25: Remove broken autobind

Binding AX25 socket by using the autobind feature leads to memory leaks
in ax25_connect() and also refcount leaks in ax25_release(). Memory
leak was detected with kmemleak:

================================================================
unreferenced object 0xffff8880253cd680 (size 96):
backtrace:
__kmalloc_node_track_caller_noprof (./include/linux/kmemleak.h:43)
kmemdup_noprof (mm/util.c:136)
ax25_rt_autobind (net/ax25/ax25_route.c:428)
ax25_connect (net/ax25/af_ax25.c:1282)
__sys_connect_file (net/socket.c:2045)
__sys_connect (net/socket.c:2064)
__x64_sys_connect (net/socket.c:2067)
do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
================================================================

When socket is bound, refcounts must be incremented the way it is done
in ax25_bind() and ax25_setsockopt() (SO_BINDTODEVICE). In case of
autobind, the refcounts are not incremented.

This bug leads to the following issue reported by Syzkaller:

================================================================
ax25_connect(): syz-executor318 uses autobind, please contact jreuter@yaina.de
------------[ cut here ]------------
refcount_t: decrement hit 0; leaking memory.
WARNING: CPU: 0 PID: 5317 at lib/refcount.c:31 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:31
Modules linked in:
CPU: 0 UID: 0 PID: 5317 Comm: syz-executor318 Not tainted 6.14.0-rc4-syzkaller-00278-gece144f151ac #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:refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:31
...
Call Trace:
 &lt;TASK&gt;
 __refcount_dec include/linux/refcount.h:336 [inline]
 refcount_dec include/linux/refcount.h:351 [inline]
 ref_tracker_free+0x6af/0x7e0 lib/ref_tracker.c:236
 netdev_tracker_free include/linux/netdevice.h:4302 [inline]
 netdev_put include/linux/netdevice.h:4319 [inline]
 ax25_release+0x368/0x960 net/ax25/af_ax25.c:1080
 __sock_release net/socket.c:647 [inline]
 sock_close+0xbc/0x240 net/socket.c:1398
 __fput+0x3e9/0x9f0 fs/file_table.c:464
 __do_sys_close fs/open.c:1580 [inline]
 __se_sys_close fs/open.c:1565 [inline]
 __x64_sys_close+0x7f/0x110 fs/open.c:1565
 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
 ...
 &lt;/TASK&gt;
================================================================

Considering the issues above and the comments left in the code that say:
"check if we can remove this feature. It is broken."; "autobinding in this
may or may not work"; - it is better to completely remove this feature than
to fix it because it is broken and leads to various kinds of memory bugs.

Now calling connect() without first binding socket will result in an
error (-EINVAL). Userspace software that relies on the autobind feature
might get broken. However, this feature does not seem widely used with
this specific driver as it was not reliable at any point of time, and it
is already broken anyway. E.g. ax25-tools and ax25-apps packages for
popular distributions do not use the autobind feature for AF_AX25.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.</Note>
    </Notes>
    <CVE>CVE-2025-22109</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

btrfs: fix block group refcount race in btrfs_create_pending_block_groups()

Block group creation is done in two phases, which results in a slightly
unintuitive property: a block group can be allocated/deallocated from
after btrfs_make_block_group() adds it to the space_info with
btrfs_add_bg_to_space_info(), but before creation is completely completed
in btrfs_create_pending_block_groups(). As a result, it is possible for a
block group to go unused and have 'btrfs_mark_bg_unused' called on it
concurrently with 'btrfs_create_pending_block_groups'. This causes a
number of issues, which were fixed with the block group flag
'BLOCK_GROUP_FLAG_NEW'.

However, this fix is not quite complete. Since it does not use the
unused_bg_lock, it is possible for the following race to occur:

btrfs_create_pending_block_groups            btrfs_mark_bg_unused
                                           if list_empty // false
        list_del_init
        clear_bit
                                           else if (test_bit) // true
                                                list_move_tail

And we get into the exact same broken ref count and invalid new_bgs
state for transaction cleanup that BLOCK_GROUP_FLAG_NEW was designed to
prevent.

The broken refcount aspect will result in a warning like:

  [1272.943527] refcount_t: underflow; use-after-free.
  [1272.943967] WARNING: CPU: 1 PID: 61 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110
  [1272.944731] Modules linked in: btrfs virtio_net xor zstd_compress raid6_pq null_blk [last unloaded: btrfs]
  [1272.945550] CPU: 1 UID: 0 PID: 61 Comm: kworker/u32:1 Kdump: loaded Tainted: G        W          6.14.0-rc5+ #108
  [1272.946368] Tainted: [W]=WARN
  [1272.946585] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014
  [1272.947273] Workqueue: btrfs_discard btrfs_discard_workfn [btrfs]
  [1272.947788] RIP: 0010:refcount_warn_saturate+0xba/0x110
  [1272.949532] RSP: 0018:ffffbf1200247df0 EFLAGS: 00010282
  [1272.949901] RAX: 0000000000000000 RBX: ffffa14b00e3f800 RCX: 0000000000000000
  [1272.950437] RDX: 0000000000000000 RSI: ffffbf1200247c78 RDI: 00000000ffffdfff
  [1272.950986] RBP: ffffa14b00dc2860 R08: 00000000ffffdfff R09: ffffffff90526268
  [1272.951512] R10: ffffffff904762c0 R11: 0000000063666572 R12: ffffa14b00dc28c0
  [1272.952024] R13: 0000000000000000 R14: ffffa14b00dc2868 R15: 000001285dcd12c0
  [1272.952850] FS:  0000000000000000(0000) GS:ffffa14d33c40000(0000) knlGS:0000000000000000
  [1272.953458] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [1272.953931] CR2: 00007f838cbda000 CR3: 000000010104e000 CR4: 00000000000006f0
  [1272.954474] Call Trace:
  [1272.954655]  &lt;TASK&gt;
  [1272.954812]  ? refcount_warn_saturate+0xba/0x110
  [1272.955173]  ? __warn.cold+0x93/0xd7
  [1272.955487]  ? refcount_warn_saturate+0xba/0x110
  [1272.955816]  ? report_bug+0xe7/0x120
  [1272.956103]  ? handle_bug+0x53/0x90
  [1272.956424]  ? exc_invalid_op+0x13/0x60
  [1272.956700]  ? asm_exc_invalid_op+0x16/0x20
  [1272.957011]  ? refcount_warn_saturate+0xba/0x110
  [1272.957399]  btrfs_discard_cancel_work.cold+0x26/0x2b [btrfs]
  [1272.957853]  btrfs_put_block_group.cold+0x5d/0x8e [btrfs]
  [1272.958289]  btrfs_discard_workfn+0x194/0x380 [btrfs]
  [1272.958729]  process_one_work+0x130/0x290
  [1272.959026]  worker_thread+0x2ea/0x420
  [1272.959335]  ? __pfx_worker_thread+0x10/0x10
  [1272.959644]  kthread+0xd7/0x1c0
  [1272.959872]  ? __pfx_kthread+0x10/0x10
  [1272.960172]  ret_from_fork+0x30/0x50
  [1272.960474]  ? __pfx_kthread+0x10/0x10
  [1272.960745]  ret_from_fork_asm+0x1a/0x30
  [1272.961035]  &lt;/TASK&gt;
  [1272.961238] ---[ end trace 0000000000000000 ]---

Though we have seen them in the async discard workfn as well. It is
most likely to happen after a relocation finishes which cancels discard,
tears down the block group, etc.

Fix this fully by taking the lock arou
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-22115</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

idpf: check error for register_netdev() on init

Current init logic ignores the error code from register_netdev(),
which will cause WARN_ON() on attempt to unregister it, if there was one,
and there is no info for the user that the creation of the netdev failed.

WARNING: CPU: 89 PID: 6902 at net/core/dev.c:11512 unregister_netdevice_many_notify+0x211/0x1a10
...
[ 3707.563641]  unregister_netdev+0x1c/0x30
[ 3707.563656]  idpf_vport_dealloc+0x5cf/0xce0 [idpf]
[ 3707.563684]  idpf_deinit_task+0xef/0x160 [idpf]
[ 3707.563712]  idpf_vc_core_deinit+0x84/0x320 [idpf]
[ 3707.563739]  idpf_remove+0xbf/0x780 [idpf]
[ 3707.563769]  pci_device_remove+0xab/0x1e0
[ 3707.563786]  device_release_driver_internal+0x371/0x530
[ 3707.563803]  driver_detach+0xbf/0x180
[ 3707.563816]  bus_remove_driver+0x11b/0x2a0
[ 3707.563829]  pci_unregister_driver+0x2a/0x250

Introduce an error check and log the vport number and error code.
On removal make sure to check VPORT_REG_NETDEV flag prior to calling
unregister and free on the netdev.

Add local variables for idx, vport_config and netdev for readability.</Note>
    </Notes>
    <CVE>CVE-2025-22116</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all()

There's issue as follows:
BUG: KASAN: use-after-free in ext4_xattr_inode_dec_ref_all+0x6ff/0x790
Read of size 4 at addr ffff88807b003000 by task syz-executor.0/15172

CPU: 3 PID: 15172 Comm: syz-executor.0
Call Trace:
 __dump_stack lib/dump_stack.c:82 [inline]
 dump_stack+0xbe/0xfd lib/dump_stack.c:123
 print_address_description.constprop.0+0x1e/0x280 mm/kasan/report.c:400
 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560
 kasan_report+0x3a/0x50 mm/kasan/report.c:585
 ext4_xattr_inode_dec_ref_all+0x6ff/0x790 fs/ext4/xattr.c:1137
 ext4_xattr_delete_inode+0x4c7/0xda0 fs/ext4/xattr.c:2896
 ext4_evict_inode+0xb3b/0x1670 fs/ext4/inode.c:323
 evict+0x39f/0x880 fs/inode.c:622
 iput_final fs/inode.c:1746 [inline]
 iput fs/inode.c:1772 [inline]
 iput+0x525/0x6c0 fs/inode.c:1758
 ext4_orphan_cleanup fs/ext4/super.c:3298 [inline]
 ext4_fill_super+0x8c57/0xba40 fs/ext4/super.c:5300
 mount_bdev+0x355/0x410 fs/super.c:1446
 legacy_get_tree+0xfe/0x220 fs/fs_context.c:611
 vfs_get_tree+0x8d/0x2f0 fs/super.c:1576
 do_new_mount fs/namespace.c:2983 [inline]
 path_mount+0x119a/0x1ad0 fs/namespace.c:3316
 do_mount+0xfc/0x110 fs/namespace.c:3329
 __do_sys_mount fs/namespace.c:3540 [inline]
 __se_sys_mount+0x219/0x2e0 fs/namespace.c:3514
 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x67/0xd1

Memory state around the buggy address:
 ffff88807b002f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff88807b002f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
&gt;ffff88807b003000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                   ^
 ffff88807b003080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 ffff88807b003100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Above issue happens as ext4_xattr_delete_inode() isn't check xattr
is valid if xattr is in inode.
To solve above issue call xattr_check_inode() check if xattr if valid
in inode. In fact, we can directly verify in ext4_iget_extra_inode(),
so that there is no divergent verification.</Note>
    </Notes>
    <CVE>CVE-2025-22121</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

wifi: ath12k: Clear affinity hint before calling ath12k_pci_free_irq() in error path

If a shared IRQ is used by the driver due to platform limitation, then the
IRQ affinity hint is set right after the allocation of IRQ vectors in
ath12k_pci_msi_alloc(). This does no harm unless one of the functions
requesting the IRQ fails and attempt to free the IRQ.

This may end up with a warning from the IRQ core that is expecting the
affinity hint to be cleared before freeing the IRQ:

kernel/irq/manage.c:

	/* make sure affinity_hint is cleaned up */
	if (WARN_ON_ONCE(desc-&gt;affinity_hint))
		desc-&gt;affinity_hint = NULL;

So to fix this issue, clear the IRQ affinity hint before calling
ath12k_pci_free_irq() in the error path. The affinity will be cleared once
again further down the error path due to code organization, but that does
no harm.</Note>
    </Notes>
    <CVE>CVE-2025-22128</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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 flaw was found in cifs-utils. When trying to obtain Kerberos credentials, the cifs.upcall program from the cifs-utils package makes an upcall to the wrong namespace in containerized environments. This issue may lead to disclosing sensitive data from the host's Kerberos credentials cache.</Note>
    </Notes>
    <CVE>CVE-2025-2312</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:cifs-utils-6.15-150400.3.12.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

wifi: ath11k: Clear affinity hint before calling ath11k_pcic_free_irq() in error path

If a shared IRQ is used by the driver due to platform limitation, then the
IRQ affinity hint is set right after the allocation of IRQ vectors in
ath11k_pci_alloc_msi(). This does no harm unless one of the functions
requesting the IRQ fails and attempt to free the IRQ. This results in the
below warning:

WARNING: CPU: 7 PID: 349 at kernel/irq/manage.c:1929 free_irq+0x278/0x29c
Call trace:
 free_irq+0x278/0x29c
 ath11k_pcic_free_irq+0x70/0x10c [ath11k]
 ath11k_pci_probe+0x800/0x820 [ath11k_pci]
 local_pci_probe+0x40/0xbc

The warning is due to not clearing the affinity hint before freeing the
IRQs.

So to fix this issue, clear the IRQ affinity hint before calling
ath11k_pcic_free_irq() in the error path. The affinity will be cleared once
again further down the error path due to code organization, but that does
no harm.

Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-05266-QCAHSTSWPLZ_V2_TO_X86-1</Note>
    </Notes>
    <CVE>CVE-2025-23129</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

dlm: prevent NPD when writing a positive value to event_done

do_uevent returns the value written to event_done. In case it is a
positive value, new_lockspace would undo all the work, and lockspace
would not be set. __dlm_new_lockspace, however, would treat that
positive value as a success due to commit 8511a2728ab8 ("dlm: fix use
count with multiple joins").

Down the line, device_create_lockspace would pass that NULL lockspace to
dlm_find_lockspace_local, leading to a NULL pointer dereference.

Treating such positive values as successes prevents the problem. Given
this has been broken for so long, this is unlikely to break userspace
expectations.</Note>
    </Notes>
    <CVE>CVE-2025-23131</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

wifi: ath11k: update channel list in reg notifier instead reg worker

Currently when ath11k gets a new channel list, it will be processed
according to the following steps:
1. update new channel list to cfg80211 and queue reg_work.
2. cfg80211 handles new channel list during reg_work.
3. update cfg80211's handled channel list to firmware by
ath11k_reg_update_chan_list().

But ath11k will immediately execute step 3 after reg_work is just
queued. Since step 2 is asynchronous, cfg80211 may not have completed
handling the new channel list, which may leading to an out-of-bounds
write error:
BUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_list
Call Trace:
    ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k]
    kfree+0x109/0x3a0
    ath11k_regd_update+0x1cf/0x350 [ath11k]
    ath11k_regd_update_work+0x14/0x20 [ath11k]
    process_one_work+0xe35/0x14c0

Should ensure step 2 is completely done before executing step 3. Thus
Wen raised patch[1]. When flag NL80211_REGDOM_SET_BY_DRIVER is set,
cfg80211 will notify ath11k after step 2 is done.

So enable the flag NL80211_REGDOM_SET_BY_DRIVER then cfg80211 will
notify ath11k after step 2 is done. At this time, there will be no
KASAN bug during the execution of the step 3.

[1] https://patchwork.kernel.org/project/linux-wireless/patch/20230201065313.27203-1-quic_wgong@quicinc.com/

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3</Note>
    </Notes>
    <CVE>CVE-2025-23133</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

thermal: int340x: Add NULL check for adev

Not all devices have an ACPI companion fwnode, so adev might be NULL.
This is similar to the commit cd2fd6eab480
("platform/x86: int3472: Check for adev == NULL").

Add a check for adev not being set and return -ENODEV in that case to
avoid a possible NULL pointer deref in int3402_thermal_probe().

Note, under the same directory, int3400_thermal_probe() has such a
check.

[ rjw: Subject edit, added Fixes: ]</Note>
    </Notes>
    <CVE>CVE-2025-23136</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

watch_queue: fix pipe accounting mismatch

Currently, watch_queue_set_size() modifies the pipe buffers charged to
user-&gt;pipe_bufs without updating the pipe-&gt;nr_accounted on the pipe
itself, due to the if (!pipe_has_watch_queue()) test in
pipe_resize_ring(). This means that when the pipe is ultimately freed,
we decrement user-&gt;pipe_bufs by something other than what than we had
charged to it, potentially leading to an underflow. This in turn can
cause subsequent too_many_pipe_buffers_soft() tests to fail with -EPERM.

To remedy this, explicitly account for the pipe usage in
watch_queue_set_size() to match the number set via account_pipe_buffers()

(It's unclear why watch_queue_set_size() does not update nr_accounted;
it may be due to intentional overprovisioning in watch_queue_set_size()?)</Note>
    </Notes>
    <CVE>CVE-2025-23138</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

mptcp: fix NULL pointer in can_accept_new_subflow

When testing valkey benchmark tool with MPTCP, the kernel panics in
'mptcp_can_accept_new_subflow' because subflow_req-&gt;msk is NULL.

Call trace:

  mptcp_can_accept_new_subflow (./net/mptcp/subflow.c:63 (discriminator 4)) (P)
  subflow_syn_recv_sock (./net/mptcp/subflow.c:854)
  tcp_check_req (./net/ipv4/tcp_minisocks.c:863)
  tcp_v4_rcv (./net/ipv4/tcp_ipv4.c:2268)
  ip_protocol_deliver_rcu (./net/ipv4/ip_input.c:207)
  ip_local_deliver_finish (./net/ipv4/ip_input.c:234)
  ip_local_deliver (./net/ipv4/ip_input.c:254)
  ip_rcv_finish (./net/ipv4/ip_input.c:449)
  ...

According to the debug log, the same req received two SYN-ACK in a very
short time, very likely because the client retransmits the syn ack due
to multiple reasons.

Even if the packets are transmitted with a relevant time interval, they
can be processed by the server on different CPUs concurrently). The
'subflow_req-&gt;msk' ownership is transferred to the subflow the first,
and there will be a risk of a null pointer dereference here.

This patch fixes this issue by moving the 'subflow_req-&gt;msk' under the
`own_req == true` conditional.

Note that the !msk check in subflow_hmac_valid() can be dropped, because
the same check already exists under the own_req mpj branch where the
code has been moved to.</Note>
    </Notes>
    <CVE>CVE-2025-23145</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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 has been found in Hercules Augeas 1.14.1 and classified as problematic. This vulnerability affects the function re_case_expand of the file src/fa.c. The manipulation of the argument re leads to null pointer dereference. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used.</Note>
    </Notes>
    <CVE>CVE-2025-2588</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:augeas-1.14.1-150600.3.3.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:augeas-lenses-1.14.1-150600.3.3.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libaugeas0-1.14.1-150600.3.3.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libfa1-1.14.1-150600.3.3.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 CGI gem before 0.4.2 for Ruby, the CGI::Cookie.parse method in the CGI library contains a potential Denial of Service (DoS) vulnerability. The method does not impose any limit on the length of the raw cookie value it processes. This oversight can lead to excessive resource consumption when parsing extremely large cookies.</Note>
    </Notes>
    <CVE>CVE-2025-27219</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libruby2_5-2_5-2.5.9-150000.4.41.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:ruby2.5-2.5.9-150000.4.41.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:ruby2.5-stdlib-2.5.9-150000.4.41.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 CGI gem before 0.4.2 for Ruby, a Regular Expression Denial of Service (ReDoS) vulnerability exists in the Util#escapeElement method.</Note>
    </Notes>
    <CVE>CVE-2025-27220</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libruby2_5-2_5-2.5.9-150000.4.41.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:ruby2.5-2.5.9-150000.4.41.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:ruby2.5-stdlib-2.5.9-150000.4.41.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 SQLite 3.44.0 through 3.49.0 before 3.49.1, the concat_ws() SQL function can cause memory to be written beyond the end of a malloc-allocated buffer. If the separator argument is attacker-controlled and has a large string (e.g., 2MB or more), an integer overflow occurs in calculating the size of the result buffer, and thus malloc may not allocate enough memory.</Note>
    </Notes>
    <CVE>CVE-2025-29087</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libsqlite3-0-3.49.1-150000.3.27.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:sqlite3-tcl-3.49.1-150000.3.27.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 SQLite 3.49.0 before 3.49.1, certain argument values to sqlite3_db_config (in the C-language API) can cause a denial of service (application crash). An sz*nBig multiplication is not cast to a 64-bit integer, and consequently some memory allocations may be incorrect.</Note>
    </Notes>
    <CVE>CVE-2025-29088</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libsqlite3-0-3.49.1-150000.3.27.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:sqlite3-tcl-3.49.1-150000.3.27.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 libxml2 before 2.13.8 and 2.14.x before 2.14.2, out-of-bounds memory access can occur in the Python API (Python bindings) because of an incorrect return value. This occurs in xmlPythonFileRead and xmlPythonFileReadRaw because of a difference between bytes and characters.</Note>
    </Notes>
    <CVE>CVE-2025-32414</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libxml2-2-2.10.3-150500.5.26.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 libxml2 before 2.13.8 and 2.14.x before 2.14.2, xmlSchemaIDCFillNodeTables in xmlschemas.c has a heap-based buffer under-read. 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-2025-32415</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libxml2-2-2.10.3-150500.5.26.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 sshd in OpenSSH before 10.0, the DisableForwarding directive does not adhere to the documentation stating that it disables X11 and agent forwarding.</Note>
    </Notes>
    <CVE>CVE-2025-32728</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:openssh-9.6p1-150600.6.26.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:openssh-clients-9.6p1-150600.6.26.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:openssh-common-9.6p1-150600.6.26.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:openssh-server-9.6p1-150600.6.26.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 flaw was found in GLib. An integer overflow and buffer under-read occur when parsing a long invalid ISO 8601 timestamp with the g_date_time_new_from_iso8601() function.</Note>
    </Notes>
    <CVE>CVE-2025-3360</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:glib2-tools-2.78.6-150600.4.11.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libgio-2_0-0-2.78.6-150600.4.11.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libglib-2_0-0-2.78.6-150600.4.11.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libgmodule-2_0-0-2.78.6-150600.4.11.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:libgobject-2_0-0-2.78.6-150600.4.11.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:

ext4: fix OOB read when checking dotdot dir

Mounting a corrupted filesystem with directory which contains '.' dir
entry with rec_len == block size results in out-of-bounds read (later
on, when the corrupted directory is removed).

ext4_empty_dir() assumes every ext4 directory contains at least '.'
and '..' as directory entries in the first data block. It first loads
the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry()
and then uses its rec_len member to compute the location of '..' dir
entry (in ext4_next_entry). It assumes the '..' dir entry fits into the
same data block.

If the rec_len of '.' is precisely one block (4KB), it slips through the
sanity checks (it is considered the last directory entry in the data
block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the
memory slot allocated to the data block. The following call to
ext4_check_dir_entry() on new value of de then dereferences this pointer
which results in out-of-bounds mem access.

Fix this by extending __ext4_check_dir_entry() to check for '.' dir
entries that reach the end of data block. Make sure to ignore the phony
dir entries for checksum (by checking name_len for non-zero).

Note: This is reported by KASAN as use-after-free in case another
structure was recently freed from the slot past the bound, but it is
really an OOB read.

This issue was found by syzkaller tool.

Call Trace:
[   38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710
[   38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375
[   38.595158]
[   38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1
[   38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
[   38.595304] Call Trace:
[   38.595308]  &lt;TASK&gt;
[   38.595311]  dump_stack_lvl+0xa7/0xd0
[   38.595325]  print_address_description.constprop.0+0x2c/0x3f0
[   38.595339]  ? __ext4_check_dir_entry+0x67e/0x710
[   38.595349]  print_report+0xaa/0x250
[   38.595359]  ? __ext4_check_dir_entry+0x67e/0x710
[   38.595368]  ? kasan_addr_to_slab+0x9/0x90
[   38.595378]  kasan_report+0xab/0xe0
[   38.595389]  ? __ext4_check_dir_entry+0x67e/0x710
[   38.595400]  __ext4_check_dir_entry+0x67e/0x710
[   38.595410]  ext4_empty_dir+0x465/0x990
[   38.595421]  ? __pfx_ext4_empty_dir+0x10/0x10
[   38.595432]  ext4_rmdir.part.0+0x29a/0xd10
[   38.595441]  ? __dquot_initialize+0x2a7/0xbf0
[   38.595455]  ? __pfx_ext4_rmdir.part.0+0x10/0x10
[   38.595464]  ? __pfx___dquot_initialize+0x10/0x10
[   38.595478]  ? down_write+0xdb/0x140
[   38.595487]  ? __pfx_down_write+0x10/0x10
[   38.595497]  ext4_rmdir+0xee/0x140
[   38.595506]  vfs_rmdir+0x209/0x670
[   38.595517]  ? lookup_one_qstr_excl+0x3b/0x190
[   38.595529]  do_rmdir+0x363/0x3c0
[   38.595537]  ? __pfx_do_rmdir+0x10/0x10
[   38.595544]  ? strncpy_from_user+0x1ff/0x2e0
[   38.595561]  __x64_sys_unlinkat+0xf0/0x130
[   38.595570]  do_syscall_64+0x5b/0x180
[   38.595583]  entry_SYSCALL_64_after_hwframe+0x76/0x7e</Note>
    </Notes>
    <CVE>CVE-2025-37785</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

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

After making all -&gt;qlen_notify() callbacks idempotent, now it is safe to
remove the check of qlen!=0 from both fq_codel_dequeue() and
codel_qdisc_dequeue().</Note>
    </Notes>
    <CVE>CVE-2025-37798</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

vmxnet3: Fix malformed packet sizing in vmxnet3_process_xdp

vmxnet3 driver's XDP handling is buggy for packet sizes using ring0 (that
is, packet sizes between 128 - 3k bytes).

We noticed MTU-related connectivity issues with Cilium's service load-
balancing in case of vmxnet3 as NIC underneath. A simple curl to a HTTP
backend service where the XDP LB was doing IPIP encap led to overly large
packet sizes but only for *some* of the packets (e.g. HTTP GET request)
while others (e.g. the prior TCP 3WHS) looked completely fine on the wire.

In fact, the pcap recording on the backend node actually revealed that the
node with the XDP LB was leaking uninitialized kernel data onto the wire
for the affected packets, for example, while the packets should have been
152 bytes their actual size was 1482 bytes, so the remainder after 152 bytes
was padded with whatever other data was in that page at the time (e.g. we
saw user/payload data from prior processed packets).

We only noticed this through an MTU issue, e.g. when the XDP LB node and
the backend node both had the same MTU (e.g. 1500) then the curl request
got dropped on the backend node's NIC given the packet was too large even
though the IPIP-encapped packet normally would never even come close to
the MTU limit. Lowering the MTU on the XDP LB (e.g. 1480) allowed to let
the curl request succeed (which also indicates that the kernel ignored the
padding, and thus the issue wasn't very user-visible).

Commit e127ce7699c1 ("vmxnet3: Fix missing reserved tailroom") was too eager
to also switch xdp_prepare_buff() from rcd-&gt;len to rbi-&gt;len. It really needs
to stick to rcd-&gt;len which is the actual packet length from the descriptor.
The latter we also feed into vmxnet3_process_xdp_small(), by the way, and
it indicates the correct length needed to initialize the xdp-&gt;{data,data_end}
parts. For e127ce7699c1 ("vmxnet3: Fix missing reserved tailroom") the
relevant part was adapting xdp_init_buff() to address the warning given the
xdp_data_hard_end() depends on xdp-&gt;frame_sz. With that fixed, traffic on
the wire looks good again.</Note>
    </Notes>
    <CVE>CVE-2025-37799</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

sfc: fix NULL dereferences in ef100_process_design_param()

Since cited commit, ef100_probe_main() and hence also
 ef100_check_design_params() run before efx-&gt;net_dev is created;
 consequently, we cannot netif_set_tso_max_size() or _segs() at this
 point.
Move those netif calls to ef100_probe_netdev(), and also replace
 netif_err within the design params code with pci_err.</Note>
    </Notes>
    <CVE>CVE-2025-37860</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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:

clk: samsung: Fix UBSAN panic in samsung_clk_init()

With UBSAN_ARRAY_BOUNDS=y, I'm hitting the below panic due to
dereferencing `ctx-&gt;clk_data.hws` before setting
`ctx-&gt;clk_data.num = nr_clks`. Move that up to fix the crash.

  UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP
  &lt;snip&gt;
  Call trace:
   samsung_clk_init+0x110/0x124 (P)
   samsung_clk_init+0x48/0x124 (L)
   samsung_cmu_register_one+0x3c/0xa0
   exynos_arm64_register_cmu+0x54/0x64
   __gs101_cmu_top_of_clk_init_declare+0x28/0x60
   ...</Note>
    </Notes>
    <CVE>CVE-2025-39728</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:kernel-default-6.4.0-150600.23.50.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 flaw was found in systems utilizing LUKS-encrypted disks with GRUB configured for TPM-based auto-decryption. When GRUB is set to automatically decrypt disks using keys stored in the TPM, it reads the decryption key into system memory. If an attacker with physical access can corrupt the underlying filesystem superblock, GRUB will fail to locate a valid filesystem and enter rescue mode. At this point, the disk is already decrypted, and the decryption key remains loaded in system memory. This scenario may allow an attacker with physical access to access the unencrypted data without any further authentication, thereby compromising data confidentiality. Furthermore, the ability to force this state through filesystem corruption also presents a data integrity concern.</Note>
    </Notes>
    <CVE>CVE-2025-4382</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:grub2-2.12-150600.8.27.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:grub2-arm64-efi-2.12-150600.8.27.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">Untrusted LD_LIBRARY_PATH environment variable vulnerability in the GNU C Library version 2.27 to 2.38 allows attacker controlled loading of dynamically shared library in statically compiled setuid binaries that call dlopen (including internal dlopen calls after setlocale or calls to NSS functions such as getaddrinfo).</Note>
    </Notes>
    <CVE>CVE-2025-4802</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:glibc-2.38-150600.14.32.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:glibc-i18ndata-2.38-150600.14.32.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:glibc-locale-2.38-150600.14.32.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:glibc-locale-base-2.38-150600.14.32.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp6-byos-v20250528-arm64:nscd-2.38-150600.14.32.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
</cvrfdoc>
