<?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-2026:610-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-2026:610-1</ID>
    </Identification>
    <Status>Interim</Status>
    <Version>1</Version>
    <RevisionHistory>
      <Revision>
        <Number>1</Number>
        <Date>2026-03-19T09:01:57Z</Date>
        <Description>current</Description>
      </Revision>
    </RevisionHistory>
    <InitialReleaseDate>2026-01-30T01:00:00Z</InitialReleaseDate>
    <CurrentReleaseDate>2026-01-30T01: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-2026:610-1 / google/sle-micro-6-0-byos-v20260130-arm64</Note>
    <Note Title="Details" Type="General" Ordinal="2" xml:lang="en">This image update for google/sle-micro-6-0-byos-v20260130-arm64 contains the following changes:
Package 000release-packages:SL-Micro-release was updated:

Package cloud-netconfig:gce was updated:

- Update to version 1.16  + Fix query of default CLOUD_NETCONFIG_MANAGE (bsc#1253223
  + Fix variable names in the README

Package containerd was updated:

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

- Update to containerd v1.7.28. Upstream release notes:
  &amp;lt;https://github.com/containerd/containerd/releases/tag/v1.7.28&amp;gt;

Package curl was updated:

- Security fixes:  * [bsc#1255731, CVE-2025-14524] if redirected, require permission to use bearer
  * [bsc#1255734, CVE-2025-15224] require private key or user-agent for public key auth
  * [bsc#1255732, CVE-2025-14819] toggling CURLSSLOPT_NO_PARTIALCHAIN makes a different CA cache
  * [bsc#1255733, CVE-2025-15079] set both knownhosts options to the same file
  * Add patches:
  - curl-CVE-2025-14524.patch
  - curl-CVE-2025-15224.patch
  - curl-CVE-2025-14819.patch
  - curl-CVE-2025-15079.patch

- Security fix: [bsc#1253757, CVE-2025-11563]
  * curl: wcurl path traversal with percent-encoded slashes
  * Add curl-CVE-2025-11563.patch

Package docker was updated:

- Enable SELinux in default daemon.json config (--selinux-enabled). This has no  practical impact on non-SELinux systems. bsc#1252290

- Update to Docker 28.5.1-ce. See upstream changelog online at
  &amp;lt;https://docs.docker.com/engine/release-notes/28/#2851&amp;gt;
- Rebased patches:
  * 0001-SECRETS-SUSE-always-clear-our-internal-secrets.patch
  * 0002-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  * 0003-SECRETS-SUSE-implement-SUSE-container-secrets.patch
  * 0004-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  * 0005-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  * 0006-SLE12-revert-apparmor-remove-version-conditionals-fr.patch
  * cli-0001-openSUSE-point-users-to-docker-buildx-package.patch
  * cli-0002-SECRETS-SUSE-default-to-DOCKER_BUILDKIT-0-for-docker.patch
- Remove upstreamed patch:
  - 0007-Add-back-vendor.sum.patch

- Update to Docker 28.5.0-ce. See upstream changelog online at
  &amp;lt;https://docs.docker.com/engine/release-notes/28/#2850&amp;gt;
- Backport &amp;lt;https://github.com/moby/moby/pull/51091&amp;gt; to re-add vendor.sum,
  fixing our builds.
  + 0007-Add-back-vendor.sum.patch
- Rebased patches:
  * 0001-SECRETS-SUSE-always-clear-our-internal-secrets.patch
  * 0002-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  * 0003-SECRETS-SUSE-implement-SUSE-container-secrets.patch
  * 0004-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  * 0005-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  * 0006-SLE12-revert-apparmor-remove-version-conditionals-fr.patch
  * cli-0001-openSUSE-point-users-to-docker-buildx-package.patch
  * cli-0002-SECRETS-SUSE-default-to-DOCKER_BUILDKIT-0-for-docker.patch

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

- Remove git-core recommends also on openSUSE: the below argument
  is valid for those users too.

- Remove git-core recommends on SLE. Most SLE systems have
  installRecommends=yes by default and thus end up installing git with Docker.
  bsc#1250508
  This feature is mostly intended for developers (&amp;quot;docker build git://&amp;quot;) so
  most users already have the dependency installed, and the error when git is
  missing is fairly straightforward (so they can easily figure out what they
  need to install).

Package dracut was updated:

- Update to version 059+suse.607.g05002594:  * fix(kernel-modules-extra): remove stray \ before / (bsc#1253029)

Package glib2 was updated:

- Add CVE fixes:  + glib2-CVE-2025-13601-1.patch, glib2-CVE-2025-13601-2.patch
    (bsc#1254297 CVE-2025-13601 glgo#GNOME/glib#3827).
  + glib2-CVE-2025-14087-1.patch, glib2-CVE-2025-14087-2.patch,
    glib2-CVE-2025-14087-3.patch (bsc#1254662 CVE-2025-14087
    glgo#GNOME/glib#3834).
  + glib2-CVE-2025-14512.patch (bsc#1254878 CVE-2025-14512
    glgo#GNOME/glib#3845).

- Add glib2-CVE-2025-7039.patch: fix computation of temporary file
  name (bsc#1249055 CVE-2025-7039 glgo#GNOME/glib#3716).

Package gpg2 was updated:

- Security fix: [bsc#1255715, CVE-2025-68973] (gpg.fail/memcpy)  * gpg: Fix possible memory corruption in the armor parser [T7906]
  * Add gnupg-CVE-2025-68973.patch

- Security fix: [bsc#1256246] (gpg.fail/sha1)
  * gpg: Avoid potential downgrade to SHA1 in 3rd party key signatures [T7904]
  * Add gnupg-gpg-Avoid-potential-downgrade-to-SHA1-in-3rd-party-keysig.patch

- Security fix: [bsc#1256244] (gpg.fail/detached)
  * gpg: Error out on unverified output for non-detached signatures [T7903]
  * Add gnupg-gpg-Error-out-on-unverified-output-for-non-detached-signatures.patch

- Security fix: [bsc#1256243]
  * gpg2 agent: Fix a memory leak
  * Add patch gnupg-agent-memleak.patch

- Security fix: [bsc#1256390] (gpg.fail/notdash)
  * gpg2:  Cleartext Signature Forgery in the NotDashEscaped header
    implementation in GnuPG
  * Add patch gnupg-CVE-2025-68972.patch

Package kernel-source:kernel-default was updated:

- nbd: restrict sockets to TCP and UDP (bsc#1252774  CVE-2025-40080).
- commit a7c3e39

- kernel-subpackage-spec: Do not doubly-sign modules (bsc#1251930).
- commit 0f034b6

- Delete
  patches.kabi/KVM-x86-pmu-Allow-programming-events-that-match-unsu.patch.
  This avoids a kbuild error in check-patchrv. This patch is not needed
  anyway since 4f5efb71e1f4.
- commit 624b1b2

- vhost: vringh: Modify the return value check (CVE-2025-40051
  bsc#1252858).
- commit 80d9f20

- btrfs: fix the incorrect max_bytes value for
  find_lock_delalloc_range() (git-fixes).
- commit 91a9728

- KVM: x86: Introduce kvm_x86_call() to simplify static calls
  of kvm_x86_ops (git-fixes).
- Refresh
  patches.suse/KVM-x86-Don-t-inject-PV-async-PF-if-SEND_ALWAYS-0-an.patch.
- Refresh
  patches.suse/KVM-x86-Exit-to-userspace-if-fastpath-triggers-one-o.patch.
- Refresh patches.suse/KVM-x86-Introduce-kvm_set_mp_state.patch.
- Refresh
  patches.suse/KVM-x86-Route-non-canonical-checks-in-emulator-throu.patch.
- Refresh
  patches.suse/KVM-x86-model-canonical-checks-more-precisely.patch.
- commit 3454959

- KVM: x86: Replace static_call_cond() with static_call()
  (git-fixes).
- commit 6bb685c

- Update
  patches.suse/ACPI-x86-s2idle-Catch-multiple-ACPI_TYPE_PACKAGE-obj.patch
  (git-fixes CVE-2023-53708 bsc#1252537).
- Update
  patches.suse/ALSA-usb-audio-Fix-NULL-pointer-deference-in-try_to_.patch
  (git-fixes CVE-2025-40085 bsc#1252873).
- Update
  patches.suse/ALSA-usb-audio-fix-race-condition-to-UAF-in-snd_usbm.patch
  (git-fixes CVE-2025-39997 bsc#1252056).
- Update
  patches.suse/ASoC-qcom-audioreach-fix-potential-null-pointer-dere.patch
  (git-fixes CVE-2025-40013 bsc#1252348).
- Update patches.suse/Bluetooth-MGMT-Fix-possible-UAFs.patch
  (git-fixes CVE-2025-39981 bsc#1252060).
- Update
  patches.suse/Bluetooth-hci_event-Fix-UAF-in-hci_acl_create_conn_s.patch
  (git-fixes CVE-2025-39982 bsc#1252083).
- Update
  patches.suse/HID-amd_sfh-Fix-for-shift-out-of-bounds.patch
  (bsc#1012628 CVE-2023-53703 bsc#1252553).
- Update
  patches.suse/Input-uinput-zero-initialize-uinput_ff_upload_compat.patch
  (git-fixes CVE-2025-40035 bsc#1252866).
- Update patches.suse/NFS-Fix-a-potential-data-corruption.patch
  (git-fixes CVE-2023-53711 bsc#1252536).
- Update
  patches.suse/NFSD-Define-a-proc_layoutcommit-for-the-FlexFiles-layout-type.patch
  (git-fixes CVE-2025-40087 bsc#1252909).
- Update
  patches.suse/PCI-endpoint-pci-epf-test-Add-NULL-check-for-DMA-cha.patch
  (git-fixes CVE-2025-40032 bsc#1252841).
- Update
  patches.suse/RDMA-rxe-Fix-race-in-do_task-when-draining.patch
  (git-fixes CVE-2025-40061 bsc#1252849).
- Update
  patches.suse/Squashfs-fix-uninit-value-in-squashfs_get_parent.patch
  (git-fixes CVE-2025-40049 bsc#1252822).
- Update
  patches.suse/USB-gadget-Fix-the-memory-leak-in-raw_gadget-dr.patch
  (bsc#1012628 CVE-2023-53693 bsc#1252489).
- Update
  patches.suse/afs-Fix-potential-null-pointer-dereference-in-afs_put_server.patch
  (git-fixes CVE-2025-40010 bsc#1252332).
- Update
  patches.suse/arm64-csum-Fix-OoB-access-in-IP-checksum-code-for-ne.patch
  (git-fixes CVE-2023-53726 bsc#1252565).
- Update
  patches.suse/arm64-sme-Use-STR-P-to-clear-FFR-context-field-.patch
  (bsc#1012628 CVE-2023-53713 bsc#1252559).
- Update
  patches.suse/blk-iocost-use-spin_lock_irqsave-in-adjust_inus.patch
  (bsc#1012628 CVE-2023-53730 bsc#1252495).
- Update
  patches.suse/bus-fsl-mc-Check-return-value-of-platform_get_resour.patch
  (git-fixes CVE-2025-40029 bsc#1252772).
- Update
  patches.suse/can-etas_es58x-populate-ndo_change_mtu-to-prevent-bu.patch
  (git-fixes CVE-2025-39988 bsc#1252074).
- Update
  patches.suse/can-hi311x-populate-ndo_change_mtu-to-prevent-buffer.patch
  (git-fixes CVE-2025-39987 bsc#1252079).
- Update
  patches.suse/can-mcba_usb-populate-ndo_change_mtu-to-prevent-buff.patch
  (git-fixes CVE-2025-39985 bsc#1252082).
- Update
  patches.suse/can-peak_usb-fix-shift-out-of-bounds-issue.patch
  (git-fixes CVE-2025-40020 bsc#1252679).
- Update
  patches.suse/can-sun4i_can-populate-ndo_change_mtu-to-prevent-buf.patch
  (git-fixes CVE-2025-39986 bsc#1252078).
- Update
  patches.suse/clk-imx-clk-imx8mp-improve-error-handling-in-im.patch
  (bsc#1012628 CVE-2023-53704 bsc#1252490).
- Update
  patches.suse/clocksource-drivers-cadence-ttc-Fix-memory-leak.patch
  (bsc#1012628 CVE-2023-53725 bsc#1252492).
- Update
  patches.suse/crypto-essiv-Check-ssize-for-decryption-and-in-place.patch
  (git-fixes CVE-2025-40019 bsc#1252678).
- Update
  patches.suse/crypto-hisilicon-qm-set-NULL-to-qm-debug.qm_diff_reg.patch
  (git-fixes CVE-2025-40062 bsc#1252850).
- Update
  patches.suse/drm-amdgpu-Fix-integer-overflow-in-amdgpu_cs_p.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-53707
  bsc#1252632).
- Update
  patches.suse/drm-gma500-Fix-null-dereference-in-hdmi-teardown.patch
  (git-fixes CVE-2025-40011 bsc#1252336).
- Update
  patches.suse/drm-sched-Fix-potential-double-free-in-drm_sched_job.patch
  (git-fixes CVE-2025-40096 bsc#1252902).
- Update
  patches.suse/fbcon-fix-integer-overflow-in-fbcon_do_set_font.patch
  (git-fixes CVE-2025-39967 bsc#1252033).
- Update
  patches.suse/fs-udf-fix-OOB-read-in-lengthAllocDescs-handling.patch
  (git-fixes CVE-2025-40044 bsc#1252785).
- Update
  patches.suse/hfsplus-fix-slab-out-of-bounds-read-in-hfsplus_strcasecmp.patch
  (git-fixes CVE-2025-40088 bsc#1252904).
- Update
  patches.suse/hfsplus-fix-slab-out-of-bounds-read-in-hfsplus_uni2asc_followup.patch
  (git-fixes CVE-2025-40082 bsc#1252775).
- Update
  patches.suse/iommu-vt-d-Disallow-dirty-tracking-if-incoherent-pag.patch
  (git-fixes CVE-2025-40058 bsc#1252854).
- Update
  patches.suse/md-raid1-fix-potential-OOB-in-raid1_remove_disk-8b04.patch
  (jsc#PED-7542 CVE-2023-53722 bsc#1252499).
- Update
  patches.suse/media-b2c2-Fix-use-after-free-causing-by-irq_check_w.patch
  (git-fixes CVE-2025-39996 bsc#1252065).
- Update
  patches.suse/media-i2c-tc358743-Fix-use-after-free-bugs-caused-by.patch
  (git-fixes CVE-2025-39995 bsc#1252064).
- Update
  patches.suse/media-rc-fix-races-with-imon_disconnect.patch
  (git-fixes CVE-2025-39993 bsc#1252070).
- Update
  patches.suse/media-tuner-xc5000-Fix-use-after-free-in-xc5000_rele.patch
  (git-fixes CVE-2025-39994 bsc#1252072).
- Update
  patches.suse/media-uvcvideo-Mark-invalid-entities-with-id-UVC_INV.patch
  (git-fixes CVE-2025-40016 bsc#1252346).
- Update
  patches.suse/misc-fastrpc-fix-possible-map-leak-in-fastrpc_put_ar.patch
  (git-fixes CVE-2025-40036 bsc#1252865).
- Update
  patches.suse/net-nfc-nci-Add-parameter-validation-for-packet-data.patch
  (git-fixes CVE-2025-40043 bsc#1252787).
- Update
  patches.suse/net-sched-cls_u32-Undo-tcf_bind_filter-if-u32_r.patch
  (bsc#1012628 CVE-2023-53733 bsc#1252685).
- Update
  patches.suse/net-sched-fq_pie-avoid-stalls-in-fq_pie_timer.patch
  (bsc#1220419 CVE-2023-53727 bsc#1252566).
- Update
  patches.suse/netlink-fix-potential-deadlock-in-netlink_set_e.patch
  (bsc#1012628 CVE-2023-53731 bsc#1252481).
- Update
  patches.suse/nvdimm-Fix-memleak-of-pmu-attr_groups-in-unregister_-85ae.patch
  (jsc#PED-5853 CVE-2023-53697 bsc#1252534).
- Update
  patches.suse/posix-timers-Ensure-timer-ID-search-loop-limit-.patch
  (bsc#1012628 CVE-2023-53728 bsc#1252668).
- Update
  patches.suse/ring-buffer-Do-not-swap-cpu_buffer-during-resi.patch
  (bsc#1012628 CVE-2023-53718 bsc#1252564).
- Update
  patches.suse/riscv-move-memblock_allow_resize-after-linear-m.patch
  (bsc#1012628 CVE-2023-53699 bsc#1252550).
- Update
  patches.suse/smb-client-fix-crypto-buffers-in-non-linear-memory.patch
  (bsc#1250491 boo#1239206 CVE-2025-40052 bsc#1252851).
- Update
  patches.suse/soc-qcom-qmi_encdec-Restrict-string-length-in-decode.patch
  (git-fixes CVE-2023-53729 bsc#1252496).
- Update
  patches.suse/tty-n_gsm-Don-t-block-input-queue-by-waiting-MSC.patch
  (git-fixes CVE-2025-40071 bsc#1252797).
- Update
  patches.suse/wifi-ath11k-fix-NULL-dereference-in-ath11k_qmi_m3_lo.patch
  (git-fixes CVE-2025-39991 bsc#1252075).
- Update
  patches.suse/wifi-ath12k-Fix-a-NULL-pointer-dereference-in-ath12k.patch
  (git-fixes CVE-2023-53721 bsc#1252561).
- Update
  patches.suse/xfrm-xfrm_alloc_spi-shouldn-t-use-0-as-SPI.patch
  (CVE-2025-39797 bsc#1249608 CVE-2025-39965 bsc#1251967).
- Update
  patches.suse/xsk-fix-refcount-underflow-in-error-path.patch
  (bsc#1012628 CVE-2023-53698 bsc#1252479).
- commit 9042362

- coresight: trbe: Return NULL pointer for allocation failures
  (CVE-2025-40060 bsc#1252848).
- commit 4543e34

- regulator: bd718x7: Fix voltages scaled by resistor divider
  (git-fixes).
- regmap: slimbus: fix bus_context pointer in regmap init calls
  (git-fixes).
- commit 20abe4b

- drm/panel: kingdisplay-kd097d04: Disable EoTp (git-fixes).
- drm/panel: sitronix-st7789v: fix sync flags for t28cp45tn89
  (git-fixes).
- drm/etnaviv: fix flush sequence logic (git-fixes).
- drm/msm/dpu: Fix pixel extension sub-sampling (git-fixes).
- drm/msm/a6xx: Fix GMU firmware parser (git-fixes).
- drm/amd/pm/powerplay/smumgr: Fix PCIeBootLinkLevel value on
  Iceland (git-fixes).
- drm/amd/pm/powerplay/smumgr: Fix PCIeBootLinkLevel value on Fiji
  (git-fixes).
- drm/amd/pm: fix smu table id bound check issue in
  smu_cmn_update_table() (git-fixes).
- drm/mediatek: Fix device use-after-free on unbind (git-fixes).
- ASoC: fsl_sai: fix bit order for DSD format (git-fixes).
- ASoC: Intel: avs: Unprepare a stream when XRUN occurs
  (git-fixes).
- ASoC: qdsp6: q6asm: do not sleep while atomic (git-fixes).
- ALSA: usb-audio: fix control pipe direction (git-fixes).
- commit acb4ea2

- smb: client: fix potential cfid UAF in smb2_query_info_compound
  (bsc#1248886).
- commit 5e5239d

- vhost: vringh: Fix copy_to_iter return value check (CVE-2025-40056 bsc#1252826)
- commit 4efa16a

- btrfs: do not assert we found block group item when creating
  free space tree (bsc#1252918 CVE-2025-40100).
- commit 327502f

- btrfs: fix clearing of BTRFS_FS_RELOC_RUNNING if relocation
  already running (git-fixes).
- commit f5ef369

- btrfs: avoid potential out-of-bounds in btrfs_encode_fh()
  (git-fixes).
- commit 8cb68fe

- KVM: x86/mmu: Prevent installing hugepages when mem attributes
  are changing (git-fixes).
- commit 37d594a

- selftests/bpf: Fix a fd leak in error paths in open_netns
  (git-fixes).
- commit 51d3745

- selftests/bpf: Fix umount cgroup2 error in test_sockmap
  (git-fixes).
- commit 24ba5aa

- selftests/bpf: Use bpf_link__destroy in fill_link_info tests
  (git-fixes).
- commit 9809b14

- ACPI: video: Fix use-after-free in
  acpi_video_switch_brightness() (git-fixes).
- ACPI: button: Call input_free_device() on failing input device
  registration (git-fixes).
- fbdev: atyfb: Check if pll_ops-&amp;gt;init_pll failed (git-fixes).
- fbdev: valkyriefb: Fix reference count leak in valkyriefb_init
  (git-fixes).
- net: phy: dp83869: fix STRAP_OPMODE bitmask (git-fixes).
- net: usb: asix_devices: Check return value of
  usbnet_get_endpoints (git-fixes).
- Bluetooth: btmtksdio: Add pmctrl handling for BT closed state
  during reset (git-fixes).
- Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once
  (git-fixes).
- usbnet: Prevents free active kevent (git-fixes).
- wifi: brcmfmac: fix crash while sending Action Frames in
  standalone AP Mode (git-fixes).
- wifi: ath12k: free skb during idr cleanup callback (git-fixes).
- wifi: ath11k: Add missing platform IDs for quirk table
  (git-fixes).
- wifi: ath10k: Fix memory leak on unsupported WMI command
  (git-fixes).
- wifi: mac80211: reset FILS discovery and unsol probe resp
  intervals (git-fixes).
- commit cc1ca5e

- bpf: Explicitly check accesses to bpf_sock_addr (CVE-2025-40078
  bsc#1252789).
- commit 6edd4b3

- KVM: x86: Take irqfds.lock when adding/deleting IRQ bypass
  producer (git-fixes).
- commit fdfcdff

- KVM: x86: Plumb in the vCPU to kvm_x86_ops.hwapic_isr_update()
  (git-fixes).
- commit cb2e3ab

- kdb: Replace deprecated strcpy() with memmove() in vkdb_printf()
  (bsc#1252939).
- commit 7cb788c

- Revert &amp;quot;KVM: VMX: Move LOAD_IA32_PERF_GLOBAL_CTRL errata
  handling out of setup_vmcs_config()&amp;quot; (git-fixes).
- commit 769724a

- hfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat()
  (git-fixes).
- commit 40898e0

- hfsplus: fix KMSAN uninit-value issue in
  __hfsplus_ext_cache_extent() (git-fixes).
- commit a2e4db9

- hfs: validate record offset in hfsplus_bmap_alloc (git-fixes).
- commit 693ef92

- hfsplus: return EIO when type of hidden directory mismatch in
  hfsplus_fill_super() (git-fixes).
- commit 6aec9cc

- ARM: tegra: Use I/O memcpy to write to IRAM (CVE-2025-39794 bsc#1249595)
- commit ad8d355

- ipvs: Defer ip_vs_ftp unregister during netns cleanup
  (CVE-2025-40018 bsc#1252688).
- commit d48a123

- NFSD: Fix crash in nfsd4_read_release() (git-fixes).
- commit 1a326b8

- Fix Git-commit for patches.suse/cxl-downgrade-a-warning-message-to-debug-level-in-cxl.patch.
- commit 31a5035

- bpf: Allow helper bpf_get_[ns_]current_pid_tgid() for all prog
  types (bsc#1252364).
- commit 82fd58d

- tcp: Don't call reqsk_fastopen_remove() in tcp_conn_request()
  (git-fixes).
- commit fceae30

- octeontx2-pf: Fix potential use after free in otx2_tc_add_flow()
  (CVE-2025-39978 bsc#1252069).
- tcp: Clear tcp_sk(sk)-&amp;gt;fastopen_rsk in tcp_disconnect()
  (CVE-2025-39955 bsc#1251804).
- commit 0468786

- Revert &amp;quot;e1000e: fix heap overflow in e1000_set_eeprom (CVE-2025-39898&amp;quot;
  This reverts commit df2ae2c1bd0dd998b7e23e3d49e90e95ada467f0.
- commit 79fa523

- i40e: add max boundary check for VF filters (CVE-2025-39968
  bsc#1252047).
- i40e: fix validation of VF state in get resources
  (CVE-2025-39969 bsc#1252044).
- i40e: fix idx validation in i40e_validate_queue_map
  (CVE-2025-39972 bsc#1252039).
- i40e: add validation for ring_len param (CVE-2025-39973
  bsc#1252035).
- ice: fix Rx page leak on multi-buffer frames (CVE-2025-39948
  bsc#1251233).
- qed: Don't collect too many protection override GRC elements
  (CVE-2025-39949 bsc#1251177).
- commit 2c4293d

- Delete
  patches.suse/cpuidle-menu-Avoid-discarding-useful-information.patch.
- commit c2e3ac6

- Delete
  patches.suse/cpuidle-governors-menu-Avoid-using-invalid-recent-intervals-data.patch.
- commit b1a47b7

- nvme/tcp: handle tls partially sent records in write_space()
  (git-fixes).
- nvme-multipath: Skip nr_active increments in RETRY disposition
  (git-fixes).
- nvme-pci: Add TUXEDO IBS Gen8 to Samsung sleep quirk
  (git-fixes).
- commit 4b35633

- ACPI: battery: Add synchronization between interface updates
  (git-fixes).
- locking/mutex: Mark devm_mutex_init() as __must_check
  (stable-fixes).
- ACPI: battery: Check for error code from devm_mutex_init()
  call (git-fixes).
- ACPI: battery: initialize mutexes through devm_ APIs
  (stable-fixes).
- accel/ivpu: Add missing MODULE_FIRMWARE metadata (git-fixes).
- locking/mutex: Introduce devm_mutex_init() (stable-fixes).
- commit 7bacc8f

- wifi: rtw89: fix use-after-free in
  rtw89_core_tx_kick_off_and_wait() (CVE-2025-40000 bsc#1252062).
- commit b7a479d

- sched/fair: set_load_weight() must also call reweight_task() (git-fixes)
- commit b185921

- misc: fastrpc: Save actual DMA size in fastrpc_map structure
  (git-fixes).
- Refresh
  patches.suse/misc-fastrpc-Skip-reference-for-DMA-handles.patch.
- commit b472422

- most: usb: hdm_probe: Fix calling put_device() before device
  initialization (git-fixes).
- most: usb: Fix use-after-free in hdm_disconnect (git-fixes).
- misc: fastrpc: Fix dma_buf object leak in fastrpc_map_lookup
  (git-fixes).
- serial: 8250_dw: handle reset control deassert error
  (git-fixes).
- xhci: dbc: enable back DbC in resume if it was enabled before
  suspend (git-fixes).
- spi: spi-nxp-fspi: add extra delay after dll locked (git-fixes).
- net: usb: rtl8150: Fix frame padding (git-fixes).
- HID: multitouch: fix name of Stylus input devices (git-fixes).
- HID: hid-input: only ignore 0 battery events for digitizers
  (git-fixes).
- r8169: fix packet truncation after S4 resume on
  RTL8168H/RTL8111H (git-fixes).
- rtc: interface: Ensure alarm irq is enabled when UIE is enabled
  (stable-fixes).
- rtc: interface: Fix long-standing race when setting alarm
  (stable-fixes).
- PCI: j721e: Fix programming sequence of &amp;quot;strap&amp;quot; settings
  (git-fixes).
- PCI: endpoint: pci-epf-test: Add NULL check for DMA channels
  before release (git-fixes).
- PCI/AER: Support errors introduced by PCIe r6.0 (stable-fixes).
- phy: cadence: cdns-dphy: Update calibration wait time for
  startup state machine (git-fixes).
- phy: cadence: cdns-dphy: Fix PLL lock and O_CMN_READY polling
  (git-fixes).
- phy: cdns-dphy: Store hs_clk_rate and return it (stable-fixes).
- mtd: rawnand: fsmc: Default to autodetect buswidth
  (stable-fixes).
- wifi: mt76: mt7921u: Add VID/PID for Netgear A7500
  (stable-fixes).
- media: nxp: imx8-isi: Drop unused argument to
  mxc_isi_channel_chain() (stable-fixes).
- mfd: intel_soc_pmic_chtdc_ti: Set use_single_read regmap_config
  flag (git-fixes).
- mmc: core: SPI mode remove cmd7 (stable-fixes).
- lib/crypto/curve25519-hacl64: Disable KASAN with clang-17 and
  older (stable-fixes).
- PM: runtime: Add new devm functions (stable-fixes).
- mfd: intel_soc_pmic_chtdc_ti: Drop unneeded assignment for
  cache_type (stable-fixes).
- mfd: intel_soc_pmic_chtdc_ti: Fix invalid regmap-config
  max_register value (stable-fixes).
- PCI: Add PCI_VDEVICE_SUB helper macro (stable-fixes).
- PCI: endpoint: Remove surplus return statement from
  pci_epf_test_clean_dma_chan() (stable-fixes).
- PCI: j721e: Enable ACSPCIE Refclk if
  &amp;quot;ti,syscon-acspcie-proxy-ctrl&amp;quot; exists (stable-fixes).
- misc: fastrpc: Add missing dev_err newlines (stable-fixes).
- commit 9f99f4e

- firmware: arm_scmi: Fix premature SCMI_XFER_FLAG_IS_RAW clearing
  in raw mode (git-fixes).
- drm/sched: Fix potential double free in
  drm_sched_job_add_resv_dependencies (git-fixes).
- drm/rockchip: vop2: use correct destination rectangle height
  check (git-fixes).
- drm/bridge: lt9211: Drop check for last nibble of version
  register (git-fixes).
- drm/amd/powerplay: Fix CIK shutdown temperature (git-fixes).
- drm/amdgpu: use atomic functions with memory barriers for vm
  fault info (git-fixes).
- drm/i915/guc: Skip communication warning on reset in progress
  (git-fixes).
- drm/amd: Check whether secure display TA loaded successfully
  (stable-fixes).
- drm/exynos: exynos7_drm_decon: properly clear channels during
  bind (stable-fixes).
- drm/exynos: exynos7_drm_decon: fix uninitialized crtc reference
  in functions (stable-fixes).
- commit 110d102

- can: netlink: can_changelink(): allow disabling of automatic
  restart (git-fixes).
- can: bxcan: bxcan_start_xmit(): use can_dev_dropped_skb()
  instead of can_dropped_invalid_skb() (git-fixes).
- ASoC: nau8821: Add DMI quirk to bypass jack debounce circuit
  (git-fixes).
- ASoC: nau8821: Generalize helper to clear IRQ status
  (git-fixes).
- ASoC: nau8821: Cancel jdet_work before handling jack ejection
  (git-fixes).
- ASoC: codecs: Fix gain setting ranges for Renesas IDT821034
  codec (git-fixes).
- ALSA: usb-audio: Fix NULL pointer deference in
  try_to_register_card (git-fixes).
- ALSA: firewire: amdtp-stream: fix enum kernel-doc warnings
  (git-fixes).
- accel/qaic: Treat remaining == 0 as error in
  find_and_map_user_pages() (git-fixes).
- Bluetooth: btusb: Add USB ID 2001:332a for D-Link AX9U rev. A1
  (stable-fixes).
- ACPI: property: Add code comments explaining what is going on
  (stable-fixes).
- ACPI: property: Disregard references in data-only subnode lists
  (stable-fixes).
- ACPICA: Allow to skip Global Lock initialization (stable-fixes).
- ACPI: battery: allocate driver data through devm_ APIs
  (stable-fixes).
- drm/msm/adreno: De-spaghettify the use of memory barriers
  (stable-fixes).
- commit e53e617

- spi: cadence-quadspi: Implement refcount to handle unbind
  during busy (CVE-2025-40005 bsc#1252349).
- commit 7406f70

- i40e: fix idx validation in config queues msg (CVE-2025-39971 bsc#1252052)
- commit 70699a8

- i40e: fix input validation logic for action_meta (CVE-2025-39970 bsc#1252051)
- commit 57401e3

- arm64, mm: avoid always making PTE dirty in pte_mkwrite() (git-fixes)
- commit 59db3fb

- arm64: errata: Apply workarounds for Neoverse-V3AE (git-fixes)
- commit da235eb

- arm64: cputype: Add Neoverse-V3AE definitions (git-fixes)
- commit 5587842

- NFSD: Minor cleanup in layoutcommit processing (git-fixes).
- commit baef4e7

- NFSD: Rework encoding and decoding of nfsd4_deviceid
  (git-fixes).
- commit 72f1d28

- hfsplus: fix slab-out-of-bounds read in hfsplus_strcasecmp()
  (git-fixes).
- commit a6f88ab

- xfs: rename the old_crc variable in xlog_recover_process
  (git-fixes).
- commit 677fb8c

- net: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable() (CVE-2025-39876 bsc#1250400)
- commit 137f367

- proc: fix type confusion in pde_set_flags() (bsc#1248630)
- commit c6a1bb4

- proc: fix missing pde_set_flags() for net proc files (bsc#1248630)
- commit 539da61

- proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al (CVE-2025-38653 bsc#1248630)
- commit bcff9b5

- ovl: fix file reference leak when submitting aio (stable-fixes).
- commit 57db5b5

- KVM: x86: Set PVCLOCK_GUEST_STOPPED only for kvmclock, not
  for Xen PV clock (git-fixes).
- commit 85e57cf

- KVM: x86: Don't bleed PVCLOCK_GUEST_STOPPED across PV clocks
  (git-fixes).
- commit cd63f69

- KVM: x86: Process &amp;quot;guest stopped request&amp;quot; once per guest time
  update (git-fixes).
- commit 29a55cf

- add bug reference to existing hv_netvsc change (bsc#1252265)
- commit 95261dd

- KVM: SVM: Inject #GP if memory operand for INVPCID is
  non-canonical (git-fixes).
- commit ed9dfb1

- KVM: x86: Clear pv_unhalted on all transitions to
  KVM_MP_STATE_RUNNABLE (git-fixes).
- commit f4d45de

- KVM: x86: Introduce kvm_set_mp_state() (git-fixes).
- commit 4b1f2ec

- NFS: Fix a race when updating an existing write (bsc#1249319
  bsc#1252236 CVE-2025-39697).
- commit 40cab0c

- nfs: Add missing release on error in
  nfs_lock_and_join_requests() (bsc#1249319 bsc#1252236
  CVE-2025-39697).
- commit b903556

- nfs: fold nfs_page_group_lock_subrequests into
  nfs_lock_and_join_requests (bsc#1249319 bsc#1252236
  CVE-2025-39697).
- commit 13ceff1

- nfs: fold nfs_folio_find_and_lock_request into
  nfs_lock_and_join_requests (bsc#1249319 bsc#1252236
  CVE-2025-39697).
- commit 14874ac

- nfs: simplify nfs_folio_find_and_lock_request (bsc#1249319
  bsc#1252236 CVE-2025-39697).
- commit 1b25c26

- nfs: remove nfs_folio_private_request (bsc#1249319 bsc#1252236
  CVE-2025-39697).
- commit c28ea5d

- nfs: remove dead code for the old swap over NFS implementation
  (bsc#1249319 bsc#1252236 CVE-2025-39697).
- Refresh
  patches.suse/NFS-fix-nfs_release_folio-to-not-deadlock-via-kcompa.patch.
- commit e7a5c52

- kABI fix for KVM: x86: Snapshot the host's DEBUGCTL in common
  x86 (git-fixes).
- commit 0bb2570

- overlayfs: set ctime when setting mtime and atime
  (stable-fixes).
- ovl: fix incorrect fdput() on aio completion (stable-fixes).
- ovl: Always reevaluate the file signature for IMA
  (stable-fixes).
- commit 4cfc4ed

- i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path (CVE-2025-39911 bsc#1250704)
- commit 627f938

- sched: Fix sched_numa_find_nth_cpu() if mask offline (CVE-2025-39895 bsc#1250721)
- commit 581de7a

- sctp: initialize more fields in sctp_v6_from_sk() (CVE-2025-39812 bsc#1250202)
- commit 56a7db3

- ipv6: sr: Fix MAC comparison to be constant-time (CVE-2025-39702 bsc#1249317)
- commit 3d85c5c

- sctp: linearize cloned gso packets in sctp_rcv (CVE-2025-38718 bsc#1249161)
- commit 0083867

- scsi: qla4xxx: Prevent a potential error pointer dereference (CVE-2025-39676 bsc#1249302)
- commit a3b8686

- net: usb: lan78xx: Add error handling to
  lan78xx_init_mac_address (git-fixes).
- commit f1ec116

- net/mlx5e: Harden uplink netdev access against device unbind
  (CVE-2025-39947 bsc#1251232).
- commit d4278a0

- KVM: x86: Snapshot the host's DEBUGCTL after disabling IRQs
  (git-fixes).
- commit 09e399f

- KVM: x86: Bypass register cache when querying CPL from
  kvm_sched_out() (git-fixes).
- commit 27a06fc

- net: usb: lan78xx: fix use of improperly initialized dev-&amp;gt;chipid
  in lan78xx_reset (git-fixes).
- commit ad26239

- r8152: add error handling in rtl8152_driver_init (git-fixes).
- commit db73d98

- usbnet: Fix using smp_processor_id() in preemptible code
  warnings (git-fixes).
- commit b2c518b

- config.sh: Update IBS project
- commit f8ef735

- cpufreq: scmi: Account for malformed DT in
  scmi_dev_used_by_cpus() (git-fixes).
- commit 149500a

- cpuidle: governors: menu: Avoid using invalid recent intervals
  data (git-fixes).
- commit a4ef664

- hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()
  (git-fixes).
- commit baddd40

- selftests/bpf: Fix backtrace printing for selftests crashes
  (git-fixes).
- commit 63e24c4

- tools/resolve_btfids: Fix build when cross compiling kernel
  with clang (git-fixes).
- commit f4f0a36

- samples/bpf: Fix compilation failure for samples/bpf on
  LoongArch Fedora (git-fixes).
- commit fa036e9

- selftests/bpf: Fix cross-compiling urandom_read (git-fixes).
- commit d19eec5

- selftests/bpf: Fix compile if backtrace support missing in libc
  (git-fixes).
- commit 3353a4b

- selftests/bpf: Fix redefinition errors compiling lwt_reroute.c
  (git-fixes).
- commit b5270ce

- selftests/bpf: Fix C++ compile error from missing _Bool type
  (git-fixes).
- commit 736692a

- selftests/bpf: Fix error compiling test_lru_map.c (git-fixes).
- commit 8aa3099

- selftests/bpf: Fix compile error from rlim_t in sk_storage_map.c
  (git-fixes).
- commit 35f5a49

- perf/core: Fix the WARN_ON_ONCE is out of lock protected region
  (git-fixes).
- perf/x86/intel: Fix crash in icl_update_topdown_event()
  (git-fixes).
- perf/x86: Fix non-sampling (counting) events on certain x86
  platforms (git-fixes).
- commit 814983a

- doc/README.SUSE: Correct the character used for TAINT_NO_SUPPORT
  The character was previously 'N', but upstream used it for TAINT_TEST,
  which prompted the change of TAINT_NO_SUPPORT to 'n'. This occurred in
  commit c35dc3823d08 (&amp;quot;Update to 6.0-rc1&amp;quot;) on master and in d016c04d731d
  (&amp;quot;Bump to 6.4 kernel (jsc#PED-4593)&amp;quot;) for SLE15-SP6 (and onwards).
  Update the documentation to reflect this change.
- commit f42ecf5

- ACPI: property: Do not pass NULL handles to acpi_attach_data()
  (stable-fixes git-fixes).
- commit 19fb175

- ACPI: APEI: GHES: add TAINT_MACHINE_CHECK on GHES panic path
  (stable-fixes).
- commit d0f4111

- cpufreq: CPPC: fix perf_to_khz/khz_to_perf conversion exception
  (git-fixes).
- commit 59c2171

- ACPI: x86: Move acpi_quirk_skip_serdev_enumeration() out of
  CONFIG_X86_ANDROID_TABLETS (stable-fixes).
- commit 793bb70

- cpuidle: qcom-spm: fix device and OF node leaks at probe
  (git-fixes).
- commit 39be628

- cpuidle: menu: Avoid discarding useful information
  (stable-fixes).
- commit b136410

- cpufreq: tegra186: Set target frequency for all cpus in policy
  (git-fixes).
- commit e1cfca8

- cpufreq: intel_pstate: Fix object lifecycle issue in
  update_qos_request() (stable-fixes git-fixes).
- commit 8b10f36

- cpufreq: armada-8k: Fix off by one in
  armada_8k_cpufreq_free_table() (stable-fixes git-fixes).
- commit 3e7dc0b

- cpufreq: scmi: Skip SCMI devices that aren't used by the CPUs
  (stable-fixes).
- commit 2dde40f

- tcp_bpf: Fix copied value in tcp_bpf_sendmsg (bsc#1250650).
- skmsg: Return copied bytes in sk_msg_memcopy_from_iter
  (bsc#1250650).
- commit 5925a0e

- sched/idle: Conditionally handle tick broadcast in
  default_idle_call() (bsc#1248517).
- Update config files.
- commit 1a58311

- x86/idle: Sanitize X86_BUG_AMD_E400 handling (bsc#1248517).
- Refresh
  patches.suse/x86-tdx-Fix-arch_safe_halt-execution-for-TDX-VMs.patch.
- commit be42a2d

- perf/aux: Fix pending disable flow when the AUX ring buffer
  overruns (git-fixes).
- perf/core: Fix WARN in perf_cgroup_switch() (git-fixes).
- perf: Fix cgroup state vs ERROR (git-fixes).
- perf/core: Fix broken throttling when max_samples_per_tick=1
  (git-fixes).
- perf: Ensure bpf_perf_link path is properly serialized
  (git-fixes).
- perf/x86/intel: Only check the group flag for X86 leader
  (git-fixes).
- perf/x86/intel: Allow to update user space GPRs from PEBS
  records (git-fixes).
- perf/x86/intel/uncore: Fix the scale of IIO free running
  counters on SPR (git-fixes).
- perf/x86/intel/uncore: Fix the scale of IIO free running
  counters on ICX (git-fixes).
- perf/x86/intel/uncore: Fix the scale of IIO free running
  counters on SNR (git-fixes).
- perf/core: Fix child_total_time_enabled accounting bug at task
  exit (git-fixes).
- perf/ring_buffer: Allow the EPOLLRDNORM flag for poll
  (git-fixes).
- perf/bpf: Robustify perf_event_free_bpf_prog() (git-fixes).
- perf/hw_breakpoint: Return EOPNOTSUPP for unsupported breakpoint
  type (git-fixes).
- perf/x86/intel: Avoid disable PMU if !cpuc-&amp;gt;enabled in sample
  read (git-fixes).
- perf/x86/intel: Apply static call for drain_pebs (git-fixes).
- perf/amd/ibs: Fix perf_ibs_op.cnt_mask for CurCnt (git-fixes).
- perf/amd/ibs: Fix -&amp;gt;config to sample period calculation for
  OP PMU (git-fixes).
- perf/core: Fix pmus_lock vs. pmus_srcu ordering (git-fixes).
- perf/x86/intel: Use better start period for frequency mode
  (git-fixes).
- perf/core: Fix low freq setting via IOC_PERIOD (git-fixes).
- perf/x86: Fix low freqency setting issue (git-fixes).
- perf/x86/intel/ds: Unconditionally drain PEBS DS when changing
  PEBS_DATA_CFG (git-fixes).
- perf/x86/amd: Warn only on new bits set (git-fixes).
- s390: Initialize psw mask in perf_arch_fetch_caller_regs()
  (git-fixes).
- perf/core: Fix small negative period being ignored (git-fixes).
- perf: Extract a few helpers (git-fixes).
- perf/x86/intel/pt: Fix sampling synchronization (git-fixes).
- perf/x86/intel: Allow to setup LBR for counting event for BPF
  (git-fixes).
- drivers/perf: arm_spe: Use perf_allow_kernel() for permissions
  (git-fixes).
- perf/amd: Prevent grouping of IBS events (git-fixes).
- commit 76eb280

- tls: make sure to abort the stream if headers are bogus
  (CVE-2025-39946 bsc#1251114).
- commit d62deaa

- selftests/bpf: Fix error compiling tc_redirect.c with musl libc
  (git-fixes).
- commit b2a359c

- selftests/bpf: Fix errors compiling cg_storage_multi.h with
  musl libc (git-fixes).
- commit 799529b

- selftests/bpf: Fix errors compiling decap_sanity.c with musl
  libc (git-fixes).
- commit f14b275

- selftests/bpf: Fix errors compiling lwt_redirect.c with musl
  libc (git-fixes).
- commit 498999e

- selftests/bpf: Fix compiling core_reloc.c with musl-libc
  (git-fixes).
- commit eb3a7bd

- selftests/bpf: Fix compiling tcp_rtt.c with musl-libc
  (git-fixes).
- commit 109e7cc

- selftests/bpf: Fix compiling flow_dissector.c with musl-libc
  (git-fixes).
- commit 9b43d04

- selftests/bpf: Fix compiling kfree_skb.c with musl-libc
  (git-fixes).
- commit 442e8bf

- selftests/bpf: Fix compiling parse_tcp_hdr_opt.c with musl-libc
  (git-fixes).
- commit 1f65169

- selftests/bpf: Fix error compiling bpf_iter_setsockopt.c with
  musl libc (git-fixes).
- commit 7613608

- selftests/bpf: Add test for unpinning htab with internal timer
  struct (git-fixes).
- commit 8a1df26

- bpf: Avoid RCU context warning when unpinning htab with internal
  structs (git-fixes).
- commit 73d4d2d

- bpf: Fix metadata_dst leak __bpf_redirect_neigh_v{4,6}
  (git-fixes).
- commit 1a82fe5

- kabi: hide new member allow_subflows in struct mptcp_sock
  (CVE-2025-38552 bsc#1248230).
- commit f51a25e

- mptcp: plug races between subflow fail and subflow creation
  (CVE-2025-38552 bsc#1248230).
- Refresh
  patches.kabi/kabi-hide-new-member-fallback_lock-in-struct-mptcp_s.patch.
  (also delete outdated part of a comment)
- commit fdbbed8

- Update
  patches.suse/ALSA-ac97-Fix-possible-NULL-dereference-in-snd_.patch
  (bsc#1012628 CVE-2023-53648 bsc#1251750).
- Update
  patches.suse/ASoC-codecs-wcd938x-fix-missing-mbhc-init-error.patch
  (bsc#1012628 CVE-2023-53666 bsc#1251760).
- Update
  patches.suse/ASoC-qcom-q6apm-lpass-dais-Fix-NULL-pointer-derefere.patch
  (git-fixes CVE-2025-39938 bsc#1251134).
- Update
  patches.suse/Bluetooth-hci_event-call-disconnect-callback-be.patch
  (bsc#1012628 CVE-2023-53673 bsc#1251763).
- Update
  patches.suse/HID-hyperv-avoid-struct-memcpy-overrun-warning.patch
  (bsc#1012628 CVE-2023-53553 bsc#1251068).
- Update
  patches.suse/KVM-nSVM-Check-instead-of-asserting-on-nested-TSC-sc.patch
  (git-fixes CVE-2023-53663 bsc#1251290).
- Update
  patches.suse/RDMA-rxe-Fix-incomplete-state-save-in-rxe_requester.patch
  (git-fixes CVE-2023-53539 bsc#1251060).
- Update
  patches.suse/USB-Gadget-core-Help-prevent-panic-during-UVC-.patch
  (bsc#1012628 CVE-2023-53580 bsc#1251105).
- Update
  patches.suse/accel-qaic-Fix-a-leak-in-map_user_pages.patch
  (bsc#1012628 CVE-2023-53633 bsc#1251746).
- Update
  patches.suse/bcache-Fix-__bch_btree_node_alloc-to-make-the-f.patch
  (bsc#1012628 CVE-2023-53681 bsc#1251769).
- Update
  patches.suse/bonding-do-not-assume-skb-mac_header-is-set.patch
  (bsc#1012628 CVE-2023-53601 bsc#1251153).
- Update
  patches.suse/bpf-Make-bpf_refcount_acquire-fallible-for-non-.patch
  (bsc#1012628 CVE-2023-53645 bsc#1251321).
- Update
  patches.suse/bpf-cpumap-Handle-skb-as-well-when-clean-up-pt.patch
  (bsc#1012628 CVE-2023-53660 bsc#1251721).
- Update
  patches.suse/bpf-cpumap-Make-sure-kthread-is-running-before.patch
  (bsc#1012628 CVE-2023-53577 bsc#1251028).
- Update
  patches.suse/bpf-reject-unhashed-sockets-in-bpf_sk_assign.patch
  (jsc#PED-6811 CVE-2023-53585 bsc#1251126).
- Update
  patches.suse/btrfs-insert-tree-mod-log-move-in-push_node_lef.patch
  (bsc#1012628 CVE-2023-53538 bsc#1251024).
- Update
  patches.suse/btrfs-output-extra-debug-info-if-we-failed-to-find-a.patch
  (git-fixes CVE-2023-53672 bsc#1251780).
- Update
  patches.suse/btrfs-reject-invalid-reloc-tree-root-keys-with.patch
  (bsc#1012628 CVE-2023-53618 bsc#1251748).
- Update
  patches.suse/cifs-Release-folio-lock-on-fscache-read-hit.patch
  (bsc#1012628 CVE-2023-53593 bsc#1251132).
- Update
  patches.suse/cifs-fix-mid-leak-during-reconnection-after-tim.patch
  (bsc#1012628 CVE-2023-53597 bsc#1251159).
- Update
  patches.suse/clk-Fix-memory-leak-in-devm_clk_notifier_regist.patch
  (bsc#1012628 CVE-2023-53674 bsc#1251764).
- Update
  patches.suse/clk-imx-scu-use-_safe-list-iterator-to-avoid-a-.patch
  (bsc#1012628 CVE-2023-53572 bsc#1251027).
- Update
  patches.suse/cpufreq-amd-pstate-fix-global-sysfs-attribute-.patch
  (bsc#1012628 CVE-2023-53550 bsc#1251071).
- Update
  patches.suse/cpufreq-amd-pstate-ut-Fix-kernel-panic-when-loading-.patch
  (git-fixes CVE-2023-53563 bsc#1251038).
- Update
  patches.suse/crypto-af_alg-Fix-missing-initialisation-affecting-g.patch
  (bsc#1216396 CVE-2023-53599 bsc#1251150).
- Update
  patches.suse/crypto-af_alg-Set-merge-to-zero-early-in-af_alg_send.patch
  (git-fixes CVE-2025-39931 bsc#1251100).
- Update
  patches.suse/dax-Fix-dax_mapping_release-use-after-free.patch
  (bsc#1012628 CVE-2023-53613 bsc#1251119).
- Update
  patches.suse/drivers-base-Free-devm-resources-when-unregistering-.patch
  (jsc#PED-6054 CVE-2023-53596 bsc#1251161).
- Update
  patches.suse/drivers-perf-hisi-Don-t-migrate-perf-to-the-CPU.patch
  (bsc#1012628 CVE-2023-53656 bsc#1251758).
- Update
  patches.suse/drm-amdgpu-unmap-and-remove-csa_va-properly.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-53545
  bsc#1251084).
- Update
  patches.suse/drm-bridge-anx7625-Fix-NULL-pointer-dereference-with.patch
  (git-fixes CVE-2025-39934 bsc#1251146).
- Update
  patches.suse/drm-i915-mark-requests-for-GuC-virtual-engines-to-av.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-53552
  bsc#1251065).
- Update
  patches.suse/drm-i915-perf-add-sentinel-to-xehp_oa_b_counter.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-53646
  bsc#1251742).
- Update
  patches.suse/ext4-fix-memory-leaks-in-ext4_fname_-setup_filename-.patch
  (bsc#1214954 CVE-2023-53662 bsc#1251282).
- Update
  patches.suse/fbdev-omapfb-lcd_mipid-Fix-an-error-handling-pa.patch
  (jsc#PED-3527 jsc#PED-5475 jsc#PED-6068 jsc#PED-6070
  jsc#PED-6116 jsc#PED-6120 jsc#PED-5065 jsc#PED-5477 jsc#PED-5511
  jsc#PED-6041 jsc#PED-6069 jsc#PED-6071 CVE-2023-53650
  bsc#1251283).
- Update
  patches.suse/fprobe-Release-rethook-after-the-ftrace_ops-is-.patch
  (bsc#1012628 CVE-2023-53557 bsc#1251054).
- Update
  patches.suse/gfs2-Fix-possible-data-races-in-gfs2_show_opti.patch
  (bsc#1012628 CVE-2023-53622 bsc#1251777).
- Update patches.suse/gpio-mvebu-fix-irq-domain-leak.patch
  (bsc#1012628 CVE-2023-53579 bsc#1251170).
- Update
  patches.suse/iavf-Fix-out-of-bounds-when-setting-channels-on.patch
  (bsc#1012628 CVE-2023-53659 bsc#1251247).
- Update patches.suse/iavf-Fix-use-after-free-in-free_netdev.patch
  (bsc#1012628 CVE-2023-53556 bsc#1251059).
- Update
  patches.suse/ice-Don-t-tx-before-switchdev-is-fully-configured.patch
  (jsc#PED-4876 CVE-2023-53657 bsc#1251319).
- Update
  patches.suse/ip_vti-fix-potential-slab-use-after-free-in-de.patch
  (bsc#1012628 CVE-2023-53559 bsc#1251052).
- Update patches.suse/ipmi_si-fix-a-memleak-in-try_smi_init.patch
  (git-fixes CVE-2023-53611 bsc#1251123).
- Update
  patches.suse/jfs-fix-invalid-free-of-JFS_IP-ipimap-i_imap-in-diUnmount.patch
  (git-fixes CVE-2023-53616 bsc#1251215).
- Update
  patches.suse/md-don-t-dereference-mddev-after-export_rdev-7dea.patch
  (jsc#PED-7542 CVE-2023-53665 bsc#1251270).
- Update
  patches.suse/media-amphion-fix-REVERSE_INULL-issues-reported-by-c.patch
  (git-fixes CVE-2023-53653 bsc#1251755).
- Update
  patches.suse/memcontrol-ensure-memcg-acquired-by-id-is-properly-s.patch
  (git-fixes CVE-2023-53621 bsc#1251323).
- Update
  patches.suse/mm-damon-core-initialize-damo_filter-list-from.patch
  (bsc#1012628 CVE-2023-53555 bsc#1251056).
- Update
  patches.suse/msft-hv-2870-Drivers-hv-vmbus-Don-t-dereference-ACPI-root-object-.patch
  (git-fixes CVE-2023-53647 bsc#1251732).
- Update
  patches.suse/mtd-rawnand-brcmnand-Fix-potential-out-of-bounds-acc.patch
  (git-fixes CVE-2023-53541 bsc#1251043).
- Update
  patches.suse/net-handshake-fix-null-ptr-deref-in-handshake_nl_don.patch
  (bsc#1220419 CVE-2023-53686 bsc#1251771).
- Update
  patches.suse/net-mlx5-DR-fix-memory-leak-in-mlx5dr_cmd_crea.patch
  (bsc#1012628 CVE-2023-53546 bsc#1251079).
- Update
  patches.suse/net-mlx5e-Check-for-NOT_READY-flag-state-after-.patch
  (bsc#1012628 CVE-2023-53581 bsc#1251106).
- Update
  patches.suse/net-mlx5e-Take-RTNL-lock-when-needed-before-ca.patch
  (bsc#1012628 CVE-2023-53632 bsc#1251269).
- Update
  patches.suse/net-rfkill-gpio-Fix-crash-due-to-dereferencering-uni.patch
  (git-fixes CVE-2025-39937 bsc#1251143).
- Update
  patches.suse/net-usbnet-Fix-WARNING-in-usbnet_start_xmit-us.patch
  (bsc#1012628 CVE-2023-53548 bsc#1251066).
- Update
  patches.suse/netfilter-conntrack-Avoid-nf_ct_helper_hash-use.patch
  (bsc#1012628 CVE-2023-53619 bsc#1251743).
- Update patches.suse/nvme-core-fix-dev_pm_qos-memleak.patch
  (bsc#1012628 CVE-2023-53670 bsc#1251762).
- Update
  patches.suse/octeon_ep-cancel-queued-works-in-probe-error-p.patch
  (bsc#1012628 CVE-2023-53638 bsc#1251328).
- Update
  patches.suse/octeontx2-af-Add-validation-before-accessing-cg.patch
  (bsc#1012628 CVE-2023-53654 bsc#1251756).
- Update
  patches.suse/perf-RISC-V-Remove-PERF_HES_STOPPED-flag-checki.patch
  (bsc#1012628 CVE-2023-53583 bsc#1251108).
- Update
  patches.suse/perf-trace-Really-free-the-evsel-priv-area.patch
  (perf-v6.7 (jsc#PED-6012 jsc#PED-6121) CVE-2023-53649
  bsc#1251749).
- Update
  patches.suse/platform-x86-dell-sysman-Fix-reference-leak.patch
  (git-fixes CVE-2023-53631 bsc#1251529).
- Update
  patches.suse/rcu-tasks-Avoid-pr_info-with-spin-lock-in-cblis.patch
  (bsc#1012628 CVE-2023-53558 bsc#1251081).
- Update
  patches.suse/ring-buffer-Fix-deadloop-issue-on-reading-trace.patch
  (bsc#1012628 CVE-2023-53668 bsc#1251286).
- Update
  patches.suse/s390-zcrypt-don-t-leak-memory-if-dev_set_name-fails.patch
  (git-fixes bsc#1215143 CVE-2023-53568 bsc#1251035).
- Update
  patches.suse/scsi-qla2xxx-Avoid-fcport-pointer-dereference.patch
  (bsc#1012628 CVE-2023-53603 bsc#1251180).
- Update
  patches.suse/scsi-qla2xxx-Fix-deletion-race-condition.patch
  (git-fixes CVE-2023-53615 bsc#1251113).
- Update
  patches.suse/soc-aspeed-socinfo-Add-kfree-for-kstrdup.patch
  (bsc#1012628 CVE-2023-53617 bsc#1251268).
- Update
  patches.suse/spi-bcm-qspi-return-error-if-neither-hif_mspi-n.patch
  (bsc#1012628 CVE-2023-53658 bsc#1251759).
- Update
  patches.suse/staging-ks7010-potential-buffer-overflow-in-ks_.patch
  (bsc#1012628 CVE-2023-53554 bsc#1251057).
- Update
  patches.suse/tracing-histograms-Add-histograms-to-hist_vars-.patch
  (bsc#1012628 CVE-2023-53560 bsc#1251045).
- Update
  patches.suse/tty-serial-samsung_tty-Fix-a-memory-leak-in-s3c-832e231.patch
  (bsc#1012628 CVE-2023-53687 bsc#1251772).
- Update
  patches.suse/tunnels-fix-kasan-splat-when-generating-ipv4-p.patch
  (bsc#1012628 CVE-2023-53600 bsc#1251152).
- Update
  patches.suse/vdpa-Add-features-attr-to-vdpa_nl_policy-for-n.patch
  (bsc#1012628 CVE-2023-53652 bsc#1251754).
- Update
  patches.suse/vdpa-Add-max-vqp-attr-to-vdpa_nl_policy-for-nl.patch
  (bsc#1012628 CVE-2023-53543 bsc#1251083).
- Update
  patches.suse/wifi-ath11k-fix-memory-leak-in-WMI-firmware-sta.patch
  (bsc#1012628 CVE-2023-53602 bsc#1251076).
- Update
  patches.suse/wifi-cfg80211-reject-auth-assoc-to-AP-with-our-addre.patch
  (git-fixes CVE-2023-53540 bsc#1251053).
- Update
  patches.suse/wifi-iwlwifi-mvm-fix-potential-array-out-of-bou.patch
  (bsc#1012628 CVE-2023-53575 bsc#1251067).
- Update
  patches.suse/wifi-mac80211-check-for-station-first-in-client-prob.patch
  (git-fixes CVE-2023-53588 bsc#1251206).
- Update
  patches.suse/wifi-mac80211-increase-scan_ies_len-for-S1G.patch
  (stable-fixes CVE-2025-39957 bsc#1251810).
- Update
  patches.suse/wifi-nl80211-fix-integer-overflow-in-nl80211_p.patch
  (bsc#1012628 CVE-2023-53570 bsc#1251031).
- Update
  patches.suse/wifi-rtw88-delete-timer-and-free-skb-queue-when-unlo.patch
  (git-fixes CVE-2023-53574 bsc#1251222).
- Update
  patches.suse/wifi-wilc1000-avoid-buffer-overflow-in-WID-string-co.patch
  (stable-fixes CVE-2025-39952 bsc#1251216).
- commit 56ea93d

- iommu/vt-d: Disallow dirty tracking if incoherent page walk
  (git-fixes).
- iommu/vt-d: PRS isn't usable if PDS isn't supported (git-fixes).
- commit 9da1184

- mm/page_alloc: fix race condition in unaccepted memory handling
  (CVE-2025-38008 bsc#1244939).
- commit b445cb1

- mm/slub: avoid accessing metadata when pointer is invalid in
  object_err() (CVE-2025-39902 bsc#1250702).
- commit 46c39b3

- NFSD: Define a proc_layoutcommit for the FlexFiles layout type
  (git-fixes).
- commit b115f79

- tracing: Fix filter string testing (git-fixes).
- commit 864d37b

- selftests/tracing: Fix event filter test to retry up to 10 times
  (git-fixes).
- commit a9de969

- tracing/selftests: Fix kprobe event name test for
  .isra. functions (git-fixes).
- commit 6a094d4

- bpf: Check link_create.flags parameter for multi_kprobe
  (git-fixes).
- commit 0e75825

- bpf: Check link_create.flags parameter for multi_uprobe
  (git-fixes).
- commit 10550c7

- ftrace: fix incorrect hash size in register_ftrace_direct()
  (git-fixes).
- commit 9288055

- bpf: Use preempt_count() directly in bpf_send_signal_common()
  (git-fixes).
- commit 9258f2a

- tracing: Correct the refcount if the hist/hist_debug file
  fails to open (git-fixes).
- commit 6e8ac35

- module: Prevent silent truncation of module name in
  delete_module(2) (git-fixes).
- commit 44dc7b7

- tracing: Add down_write(trace_event_sem) when adding trace event
  (bsc#1248211 CVE-2025-38539).
- commit b1816b0

- tracing: Limit access to parser-&amp;gt;buffer when trace_get_user
  failed (bsc#1249286 CVE-2025-39683).
- tracing: Remove unneeded goto out logic (bsc#1249286).
- commit 8eaad3a

- ftrace: Also allocate and copy hash for reading of filter files
  (bsc#1250032 CVE-2025-39813).
- commit 69f706b

- media: i2c: tc358743: Fix use-after-free bugs caused by orphan
  timer in probe (git-fixes).
- commit 4cb2ef2

- media: solo6x10: replace max(a, min(b, c)) by clamp(b, a, c)
  (git-fixes).
- commit eb03975

- ftrace: Fix potential warning in trace_printk_seq during
  ftrace_dump (bsc#1250032 CVE-2025-39813).
- commit 287d6f8

- net: sysfs: Fix /sys/class/net/&amp;lt;iface&amp;gt; path (git-fixes).
- commit 753f6d8

- trace/fgraph: Fix the warning caused by missing unregister
  notifier (bsc#1248211 CVE-2025-38539).
- commit 739d6c6

- i2c: ocores: use devm_ managed clks (git-fixes).
- commit bc09888

- USB: serial: option: add SIMCom 8230C compositions (git-fixes).
- commit fbae6a0

- usb: phy: twl6030: Fix incorrect type for ret (git-fixes).
- commit 2464609

- net: mana: Use page pool fragments for RX buffers instead of
  full pages to improve memory efficiency (bsc#1248754).
- cnic: Fix use-after-free bugs in cnic_delete_task
  (CVE-2025-39945 bsc#1251230).
- commit 8a42c4d

- selinux: fix selinux_xfrm_alloc_user() to set correct ctx_len (git-fixes).
- commit 8628058

- powerpc/powernv/pci: Fix underflow and leak issue (bsc#1215199).
- powerpc/pseries/msi: Fix potential underflow and leak issue
  (bsc#1215199).
- powerpc/kvm: Fix ifdef to remove build warning (bsc#1215199).
- KVM: PPC: Fix misleading interrupts comment in
  kvmppc_prepare_to_enter() (bsc#1215199).
- powerpc: floppy: Add missing checks after DMA map (bsc#1215199).
- powerpc/boot: Fix build with gcc 15 (bsc#1215199).
- commit c79aae4

- crypto: rng - Ensure set_ent is always present (git-fixes).
- USB: serial: option: add SIMCom 8230C compositions
  (stable-fixes).
- wifi: rtlwifi: rtl8192cu: Don't claim USB ID 07b8:8188
  (stable-fixes).
- media: tuner: xc5000: Fix use-after-free in xc5000_release
  (git-fixes).
- driver core/PM: Set power.no_callbacks along with power.no_pm
  (stable-fixes).
- platform/x86/amd/pmc: Add Stellaris Slim Gen6 AMD to spurious
  8042 quirks list (stable-fixes).
- can: rcar_canfd: Fix controller mode setting (stable-fixes).
- can: hi311x: fix null pointer dereference when resuming from
  sleep before interface was enabled (stable-fixes).
- ASoC: rt5682s: Adjust SAR ADC button mode to fix noise issue
  (stable-fixes).
- ASoC: amd: acp: Adjust pdm gain value (stable-fixes).
- platform/x86/amd/pmc: Add MECHREVO Yilong15Pro to spurious_8042
  list (stable-fixes).
- hid: fix I2C read buffer overflow in raw_event() for mcp2221
  (stable-fixes).
- media: tunner: xc5000: Refactor firmware load (stable-fixes).
- commit 6771085

- rtc: optee: fix memory leak on driver removal (git-fixes).
- rtc: x1205: Fix Xicor X1205 vendor prefix (git-fixes).
- commit 3f4b7b9

- drm/amd/display: Disable scaling on DCE6 for now (git-fixes).
- drm/amd/display: Properly disable scaling on DCE6 (git-fixes).
- drm/amd/display: Properly clear SCL_*_FILTER_CONTROL on DCE6
  (git-fixes).
- drm/amd/display: Add missing DCE6 SCL_HORZ_FILTER_INIT* SRIs
  (git-fixes).
- drm/amdgpu: Add additional DCE6 SCL registers (git-fixes).
- drm/nouveau: fix bad ret code in nouveau_bo_move_prep
  (git-fixes).
- drm/vmwgfx: Fix copy-paste typo in validation (git-fixes).
- drm/vmwgfx: Fix Use-after-free in validation (git-fixes).
- drm/vmwgfx: Fix a null-ptr access in the cursor snooper
  (git-fixes).
- ASoC: SOF: ipc4-topology: Correct the minimum host DMA buffer
  size (git-fixes).
- ASoC: SOF: ipc3-topology: Fix multi-core and static pipelines
  tear down (git-fixes).
- fbdev: Fix logic error in &amp;quot;offb&amp;quot; name match (git-fixes).
- gpio: wcd934x: mark the GPIO controller as sleeping (git-fixes).
- crypto: essiv - Check ssize for decryption and in-place
  encryption (git-fixes).
- tpm_tis: Fix incorrect arguments in tpm_tis_probe_irq_single
  (git-fixes).
- commit a90f502

- scsi: libiscsi: Initialize iscsi_conn-&amp;gt;dd_data only if memory
  is allocated (CVE-2025-38700 bsc#1249182).
- scsi: bfa: Double-free fix (CVE-2025-38699 bsc#1249224).
- commit d981d82

- Update
  patches.suse/scsi-lpfc-Fix-buffer-free-clear-order-in-deferred-re.patch
  (bsc#1250519 CVE-2025-39841 bsc#1250274).
  added CVE number and associated bsc
- commit 11a7724

- KVM: x86: Snapshot the host's DEBUGCTL in common x86
  (git-fixes).
- commit 090e1cd

- KVM: SVM: Set RFLAGS.IF=1 in C code, to get VMRUN out of the
  STI shadow (git-fixes).
- Refresh
  patches.suse/x86-bugs-Add-a-Transient-Scheduler-Attacks-mitigation.patch.
- commit ab98159

- KVM: SEV: Validate XCR0 provided by guest in GHCB (git-fixes).
- commit 3926356

- KVM: SVM: Pass through GHCB MSR if and only if VM is an SEV-ES
  guest (git-fixes).
- commit 1163dde

- KVM: SEV: Read save fields from GHCB exactly once (git-fixes).
- commit 0fe255d

- KVM: SEV: Rename kvm_ghcb_get_sw_exit_code() to
  kvm_get_cached_sw_exit_code() (git-fixes).
- commit 16f8d6e

- net: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL
  deadlock (git-fixes).
- commit 4ae0d43

- fs: writeback: fix use-after-free in __mark_inode_dirty()
  (bsc#1250455 CVE-2025-39866).
- commit 5efc627

- kernfs: Fix UAF in polling when open file is released
  (bsc#1250379 CVE-2025-39881).
- commit 278aed0

- fs: Prevent file descriptor table allocations exceeding INT_MAX
  (bsc#1249512 CVE-2025-39756).
- commit eec00db

- ext4: avoid potential buffer over-read in
  parse_apply_sb_mount_options() (git-fixes).
- commit b98ec86

- ext4: fix checks for orphan inodes (bsc#1250119).
- commit 63ca2b0

- ext4: fix hole length calculation overflow in non-extent inodes
  (git-fixes).
- commit 61cf4bb

- ext4: don't try to clear the orphan_present feature block
  device is r/o (git-fixes).
- commit f4163bf

- ext4: fix reserved gdt blocks handling in fsmap (git-fixes).
- commit 97b5bdf

- ext4: fix fsmap end of range reporting with bigalloc
  (git-fixes).
- commit 91e12c8

- ext4: check fast symlink for ea_inode correctly (git-fixes).
- commit 42b6930

- ext4: preserve SB_I_VERSION on remount (git-fixes).
- commit 4260078

- ext4: fix largest free orders lists corruption on
  mb_optimize_scan switch (git-fixes).
- commit 17d92cc

- ext4: fix zombie groups in average fragment size lists
  (git-fixes).
- commit 321e541

- ext4: ensure i_size is smaller than maxbytes (git-fixes).
- commit 83487b1

- ext4: factor out ext4_get_maxbytes() (git-fixes).
- commit e58bd69

- netfilter: nft_objref: validate objref and objrefmap expressions
  (bsc#1250237).
  No CVE available yet, please see the bugzilla ticket referenced.
- commit 71d77ae

- ext4: fix calculation of credits for extent tree modification
  (git-fixes).
- commit 9ee5795

- ext4: reorder capability check last (git-fixes).
- commit ed8a5ff

- jbd2: do not try to recover wiped journal (git-fixes).
- commit 71d37b6

- ext4: do not convert the unwritten extents if data writeback
  fails (git-fixes).
- commit 9294482

- iomap: handle a post-direct I/O invalidate race in
  iomap_write_delalloc_release (git-fixes).
- commit 1023af1

- iomap: Fix iomap_adjust_read_range for plen calculation
  (git-fixes).
- commit dab9a8e

- fs: udf: fix OOB read in lengthAllocDescs handling (git-fixes).
- commit ab7fa65

- udf: Verify partition map count (git-fixes).
- commit acb53b7

- udf: Make sure i_lenExtents is uptodate on inode eviction
  (git-fixes).
- commit 1f76b28

- isofs: Verify inode mode when loading from disk (git-fixes).
- commit 96bc3c7

- mailbox: zynqmp-ipi: Fix out-of-bounds access in mailbox
  cleanup loop (git-fixes).
- mailbox: zynqmp-ipi: Remove dev.parent check in
  zynqmp_ipi_free_mboxes (git-fixes).
- mailbox: zynqmp-ipi: Remove redundant
  mbox_controller_unregister() call (git-fixes).
- Input: uinput - zero-initialize uinput_ff_upload_compat to
  avoid info leak (git-fixes).
- commit c2e0f2f

- arm64: mte: Do not flag the zero page as PG_mte_tagged (git-fixes)
- commit cf556af

- KVM: x86: Don't inject PV async #PF if SEND_ALWAYS=0 and guest
  state is protected (git-fixes).
- commit fa670d1

- misc: fastrpc: Skip reference for DMA handles (git-fixes).
- misc: fastrpc: fix possible map leak in fastrpc_put_args
  (git-fixes).
- misc: fastrpc: Fix fastrpc_map_lookup operation (git-fixes).
- staging: axis-fifo: flush RX FIFO on read errors (git-fixes).
- staging: axis-fifo: fix TX handling on copy_from_user() failure
  (git-fixes).
- staging: axis-fifo: fix maximum TX packet length check
  (git-fixes).
- clk: at91: peripheral: fix return value (git-fixes).
- clk: mediatek: clk-mux: Do not pass flags to
  clk_mux_determine_rate_flags() (git-fixes).
- clk: mediatek: mt8195-infra_ao: Fix parent for infra_ao_hdmi_26m
  (git-fixes).
- clk: tegra: do not overallocate memory for bpmp clocks
  (git-fixes).
- commit ecaf254

- smb: client: fix crypto buffers in non-linear memory
  (bsc#1250491, boo#1239206).
- commit b5fc334

- usb: xhci: Limit Stop Endpoint retries (git-fixes).
  kABI fixup for 474538b8dd1cd9c666e56cfe8ef60fbb0fb513f4
- commit 6d76064

- kABI workaround for struct atmdev_ops extension (CVE-2025-39828
  bsc#1250205).
- commit ece3f96

- Refresh
  patches.suse/Bluetooth-L2CAP-Fix-not-checking-l2cap_chan-security.patch.
- commit 85c9004

- Refresh
  patches.suse/Bluetooth-hci_core-Fix-calling-mgmt_device_connected.patch.
- commit 9720dbb

- nfsd: nfserr_jukebox in nlm_fopen should lead to a retry
  (git-fixes).
- commit c2be588

- NFSD: Fix destination buffer size in nfsd4_ssc_setup_dul()
  (git-fixes).
- commit 7b5a68a

- sunrpc: fix null pointer dereference on zero-length checksum
  (git-fixes).
- commit c4c654a

- atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control()
  (CVE-2025-39828 bsc#1250205).
- commit a2ac627

- e1000e: fix heap overflow in e1000_set_eeprom (CVE-2025-39898
  bsc#1250742).
- vxlan: Fix NPD when refreshing an FDB entry with a nexthop
  object (CVE-2025-39851 bsc#1250296).
- commit df2ae2c

Package kmod was updated:

- man: modprobe.d: document the config file order handling (bsc#1253741)  * man-modprobe.d-document-the-config-file-order-handling.patch

Package curl:mini was updated:

- Security fixes:  * [bsc#1255731, CVE-2025-14524] if redirected, require permission to use bearer
  * [bsc#1255734, CVE-2025-15224] require private key or user-agent for public key auth
  * [bsc#1255732, CVE-2025-14819] toggling CURLSSLOPT_NO_PARTIALCHAIN makes a different CA cache
  * [bsc#1255733, CVE-2025-15079] set both knownhosts options to the same file
  * Add patches:
  - curl-CVE-2025-14524.patch
  - curl-CVE-2025-15224.patch
  - curl-CVE-2025-14819.patch
  - curl-CVE-2025-15079.patch

- Security fix: [bsc#1253757, CVE-2025-11563]
  * curl: wcurl path traversal with percent-encoded slashes
  * Add curl-CVE-2025-11563.patch

Package mozilla-nss was updated:

- Add bmo1990242.patch to move NSS DB password hash away from SHA-1
- update to NSS 3.112.2
  * bmo#1970079 - Prevent leaks during pkcs12 decoding.
  * bmo#1988046 - SEC_ASN1Decode* should ensure it has read as many bytes as each length field indicates
- Adding patch bmo1980465.patch to fix bug on s390x (bmo#1980465)
- Adding patch bmo1956754.patch to fix possible undefined behaviour (bmo#1956754)

- update to NSS 3.112.1
  * bmo#1982742 - restore support for finding certificates by decoded serial number.

- update to NSS 3.112
  * bmo#1963792 - Fix alias for mac workers on try
  * bmo#1966786 - ensure all options can be configured with SSL_OptionSet and SSL_OptionSetDefault
  * bmo#1931930 - ABI/API break in ssl certificate processing
  * bmo#1955971 - remove unnecessary assertion in sec_asn1d_init_state_based_on_template
  * bmo#1965754 - update taskgraph to v14.2.1
  * bmo#1964358 - Workflow for automation of the release on GitHub when pushing a tag
  * bmo#1952860 - fix faulty assertions in SEC_ASN1DecoderUpdate
  * bmo#1934877 - Renegotiations should use a fresh ECH GREASE buffer
  * bmo#1951396 - update taskgraph to v14.1.1
  * bmo#1962503 - Partial fix for ACVP build CI job
  * bmo#1961827 - Initialize find in sftk_searchDatabase
  * bmo#1963121 - Add clang-18 to extra builds
  * bmo#1963044 - Fault tolerant git fetch for fuzzing
  * bmo#1962556 - Tolerate intermittent failures in ssl_policy_pkix_ocsp
  * bmo#1962770 - fix compiler warnings when DEBUG_ASN1D_STATES or CMSDEBUG are set
  * bmo#1961835 - fix content type tag check in NSS_CMSMessage_ContainsCertsOrCrls
  * bmo#1963102 - Remove Cryptofuzz CI version check

- update to NSS 3.111
  * bmo#1930806 - FIPS changes need to be upstreamed: force ems policy
  * bmo#1957685 - Turn off Websites Trust Bit from CAs
  * bmo#1937338 - Update nssckbi version following April 2025 Batch of Changes
  * bmo#1943135 - Disable SMIME âtrust bitâ for GoDaddy CAs
  * bmo#1874383 - Replaced deprecated sprintf function with snprintf in dbtool.c
  * bmo#1954612 - Need up update NSS for PKCS 3.1
  * bmo#1773374 - avoid leaking localCert if it is already set in ssl3_FillInCachedSID
  * bmo#1953097 - Decrease ASAN quarantine size for Cryptofuzz in CI
  * bmo#1943962 - selfserv: Add support for zlib certificate compression

- update to NSS 3.110
  * bmo#1930806 - FIPS changes need to be upstreamed: force ems policy
  * bmo#1954724 - Prevent excess allocations in sslBuffer_Grow
  * bmo#1953429 - Remove Crl templates from ASN1 fuzz target
  * bmo#1953429 - Remove CERT_CrlTemplate from ASN1 fuzz target
  * bmo#1952855 - Fix memory leak in NSS_CMSMessage_IsSigned
  * bmo#1930807 - NSS policy updates
  * bmo#1951161 - Improve locking in nssPKIObject_GetInstances
  * bmo#1951394 - Fix race in sdb_GetMetaData
  * bmo#1951800 - Fix member access within null pointer
  * bmo#1950077 - Increase smime fuzzer memory limit
  * bmo#1949677 - Enable resumption when using custom extensions
  * bmo#1952568 - change CN of server12 test certificate
  * bmo#1949118 - Part 2: Add missing check in
    NSS_CMSDigestContext_FinishSingle
  * bmo#1949118 - Part 1: Fix smime UBSan errors
  * bmo#1930806 - FIPS changes need to be upstreamed: updated key checks
  * bmo#1951491 - Don't build libpkix in static builds
  * bmo#1951395 - handle `-p all` in try syntax
  * bmo#1951346 - fix opt-make builds to actually be opt
  * bmo#1951346 - fix opt-static builds to actually be opt
  * bmo#1916439 - Remove extraneous assert
- Removed upstreamed nss-fips-stricter-dh.patch
- Removed upstreamed nss-reproducible-chksums.patch
- Added bmo1962556.patch to fix test failures
- Rebased nss-fips-approved-crypto-non-ec.patch nss-fips-combined-hash-sign-dsa-ecdsa.patch
- update to NSS 3.109
  * bmo#1939512 - Call BL_Init before RNG_RNGInit() so that special
    SHA instructions can be used if available
  * bmo#1930807 - NSS policy updates - fix inaccurate key policy issues
  * bmo#1945883 - SMIME fuzz target
  * bmo#1914256 - ASN1 decoder fuzz target
  * bmo#1936001 - Part 2: Revert âExtract testcases from ssl gtests
    for fuzzingâ
  * bmo#1915155 - Add fuzz/README.md
  * bmo#1936001 - Part 4: Fix tstclnt arguments script
  * bmo#1944545 - Extend pkcs7 fuzz target
  * bmo#1912320 - Extend certDN fuzz target
  * bmo#1944300 - revert changes to HACL* files from bug 1866841
  * bmo#1936001 - Part 3: Package frida corpus script
- update to NSS 3.108
  * bmo#1923285 - libclang-16 -&amp;gt; libclang-19
  * bmo#1939086 - Turn off Secure Email Trust Bit for Security
    Communication ECC RootCA1
  * bmo#1937332 - Turn off Secure Email Trust Bit for BJCA Global Root
    CA1 and BJCA Global Root CA2
  * bmo#1915902 - Remove SwissSign Silver CA â G2
  * bmo#1938245 - Add D-Trust 2023 TLS Roots to NSS
  * bmo#1942301 - fix fips test failure on windows
  * bmo#1935925 - change default sensitivity of KEM keys
  * bmo#1936001 - Part 1: Introduce frida hooks and script
  * bmo#1942350 - add missing arm_neon.h include to gcm.c
  * bmo#1831552 - ci: update windows workers to win2022
  * bmo#1831552 - strip trailing carriage returns in tools tests
  * bmo#1880256 - work around unix/windows path translation issues
    in cert test script
  * bmo#1831552 - ci: let the windows setup script work without $m
  * bmo#1880255 - detect msys
  * bmo#1936680 - add a specialized CTR_Update variant for AES-GCM
  * bmo#1930807 - NSS policy updates
  * bmo#1930806 - FIPS changes need to be upstreamed: FIPS 140-3 RNG
  * bmo#1930806 - FIPS changes need to be upstreamed: Add SafeZero
  * bmo#1930806 - FIPS changes need to be upstreamed - updated POST
  * bmo#1933031 - Segmentation fault in SECITEM_Hash during pkcs12 processing
  * bmo#1929922 - Extending NSS with LoadModuleFromFunction functionality
  * bmo#1935984 - Ensure zero-initialization of collectArgs.cert
  * bmo#1934526 - pkcs7 fuzz target use CERT_DestroyCertificate
  * bmo#1915898 - Fix actual underlying ODR violations issue
  * bmo#1184059 - mozilla::pkix: allow reference ID labels to begin
    and/or end with hyphens
  * bmo#1927953 - don't look for secmod.db in nssutil_ReadSecmodDB if
    NSS_DISABLE_DBM is set
  * bmo#1934526 - Fix memory leak in pkcs7 fuzz target
  * bmo#1934529 - Set -O2 for ASan builds in CI
  * bmo#1934543 - Change branch of tlsfuzzer dependency
  * bmo#1915898 - Run tests in CI for ASan builds with detect_odr_violation=1
  * bmo#1934241 - Fix coverage failure in CI
  * bmo#1934213 - Add fuzzing for delegated credentials, DTLS short
    header and Tls13BackendEch
  * bmo#1927142 - Add fuzzing for SSL_EnableTls13GreaseEch and
    SSL_SetDtls13VersionWorkaround
  * bmo#1913677 - Part 3: Restructure fuzz/
  * bmo#1931925 - Extract testcases from ssl gtests for fuzzing
  * bmo#1923037 - Force Cryptofuzz to use NSS in CI
  * bmo#1923037 - Fix Cryptofuzz on 32 bit in CI
  * bmo#1933154 - Update Cryptofuzz repository link
  * bmo#1926256 - fix build error from 9505f79d
  * bmo#1926256 - simplify error handling in get_token_objects_for_cache
  * bmo#1931973 - nss doc: fix a warning
  * bmo#1930797 - pkcs12 fixes from RHEL need to be picked up
- remove obsolete patches
  * nss-fips-safe-memset.patch
  * nss-bmo1930797.patch
- update to NSS 3.107
  * bmo#1923038 - Remove MPI fuzz targets.
  * bmo#1925512 - Remove globals `lockStatus` and `locksEverDisabled`.
  * bmo#1919015 - Enable PKCS8 fuzz target.
  * bmo#1923037 - Integrate Cryptofuzz in CI.
  * bmo#1913677 - Part 2: Set tls server target socket options in config class
  * bmo#1913677 - Part 1: Set tls client target socket options in config class
  * bmo#1913680 - Support building with thread sanitizer.
  * bmo#1922392 - set nssckbi version number to 2.72.
  * bmo#1919913 - remove Websites Trust Bit from Entrust Root
    Certification Authority - G4.
  * bmo#1920641 - remove Security Communication RootCA3 root cert.
  * bmo#1918559 - remove SecureSign RootCA11 root cert.
  * bmo#1922387 - Add distrust-after for TLS to Entrust Roots.
  * bmo#1927096 - update expected error code in pk12util pbmac1 tests.
  * bmo#1929041 - Use random tstclnt args with handshake collection script
  * bmo#1920466 - Remove extraneous assert in ssl3gthr.c.
  * bmo#1928402 - Adding missing release notes for NSS_3_105.
  * bmo#1874451 - Enable the disabled mlkem tests for dtls.
  * bmo#1874451 - NSS gtests filter cleans up the constucted buffer
    before the use.
  * bmo#1925505 - Make ssl_SetDefaultsFromEnvironment thread-safe.
  * bmo#1925503 - Remove short circuit test from ssl_Init.
- fix build on loongarch64 (setting it as 64bit arch)
- Remove upstreamed bmo-1400603.patch
- Added nss-bmo1930797.patch to fix failing tests in testsuite
- update to NSS 3.106
  * bmo#1925975 - NSS 3.106 should be distributed with NSPR 4.36.
  * bmo#1923767 - pk12util: improve error handling in p12U_ReadPKCS12File.
  * bmo#1899402 - Correctly destroy bulkkey in error scenario.
  * bmo#1919997 - PKCS7 fuzz target, r=djackson,nss-reviewers.
  * bmo#1923002 - Extract certificates with handshake collection script.
  * bmo#1923006 - Specify len_control for fuzz targets.
  * bmo#1923280 - Fix memory leak in dumpCertificatePEM.
  * bmo#1102981 - Fix UBSan errors for SECU_PrintCertificate and
    SECU_PrintCertificateBasicInfo.
  * bmo#1921528 - add new error codes to mozilla::pkix for Firefox to use.
  * bmo#1921768 - allow null phKey in NSC_DeriveKey.
  * bmo#1921801 - Only create seed corpus zip from existing corpus.
  * bmo#1826035 - Use explicit allowlist for for KDF PRFS.
  * bmo#1920138 - Increase optimization level for fuzz builds.
  * bmo#1920470 - Remove incorrect assert.
  * bmo#1914870 - Use libFuzzer options from fuzz/options/\*.options in CI.
  * bmo#1920945 - Polish corpus collection for automation.
  * bmo#1917572 - Detect new and unfuzzed SSL options.
  * bmo#1804646 - PKCS12 fuzzing target.
- requires NSPR 4.36
- update to NSS 3.105
  * bmo#1915792 - Allow importing PKCS#8 private EC keys missing public key
  * bmo#1909768 - UBSAN fix: applying zero offset to null pointer in sslsnce.c
  * bmo#1919577 - set KRML_MUSTINLINE=inline in makefile builds
  * bmo#1918965 - Don't set CKA_SIGN for CKK_EC_MONTGOMERY private keys
  * bmo#1918767 - override default definition of KRML_MUSTINLINE
  * bmo#1916525 - libssl support for mlkem768x25519
  * bmo#1916524 - support for ML-KEM-768 in softoken and pk11wrap
  * bmo#1866841 - Add Libcrux implementation of ML-KEM 768 to FreeBL
  * bmo#1911912 - Avoid misuse of ctype(3) functions
  * bmo#1917311 - part 2: run clang-format
  * bmo#1917311 - part 1: upgrade to clang-format 13
  * bmo#1916953 - clang-format fuzz
  * bmo#1910370 - DTLS client message buffer may not empty be on retransmit
  * bmo#1916413 - Optionally print config for TLS client and server
    fuzz target
  * bmo#1916059 - Fix some simple documentation issues in NSS.
  * bmo#1915439 - improve performance of NSC_FindObjectsInit when
    template has CKA_TOKEN attr
  * bmo#1912828 - define CKM_NSS_ECDHE_NO_PAIRWISE_CHECK_KEY_PAIR_GEN
- Fix build error under Leap by rebasing nss-fips-safe-memset.patch.
- update to NSS 3.104
  * bmo#1910071 - Copy original corpus to heap-allocated buffer
  * bmo#1910079 - Fix min ssl version for DTLS client fuzzer
  * bmo#1908990 - Remove OS2 support just like we did on NSPR
  * bmo#1910605 - clang-format NSS improvements
  * bmo#1902078 - Adding basicutil.h to use HexString2SECItem function
  * bmo#1908990 - removing dirent.c from build
  * bmo#1902078 - Allow handing in keymaterial to shlibsign to make
    the output reproducible
  * bmo#1908990 - remove nec4.3, sunos4, riscos and SNI references
  * bmo#1908990 - remove other old OS (BSDI, old HP UX, NCR,
    openunix, sco, unixware or reliantUnix
  * bmo#1908990 - remove mentions of WIN95
  * bmo#1908990 - remove mentions of WIN16
  * bmo#1913750 - More explicit directory naming
  * bmo#1913755 - Add more options to TLS server fuzz target
  * bmo#1913675 - Add more options to TLS client fuzz target
  * bmo#1835240 - Use OSS-Fuzz corpus in NSS CI
  * bmo#1908012 - set nssckbi version number to 2.70.
  * bmo#1914499 - Remove Email Trust bit from ACCVRAIZ1 root cert.
  * bmo#1908009 - Remove Email Trust bit from certSIGN ROOT CA.
  * bmo#1908006 - Add Cybertrust Japan Roots to NSS.
  * bmo#1908004 - Add Taiwan CA Roots to NSS.
  * bmo#1911354 - remove search by decoded serial in
    nssToken_FindCertificateByIssuerAndSerialNumber
  * bmo#1913132 - Fix tstclnt CI build failure
  * bmo#1913047 - vfyserv: ensure peer cert chain is in db for
    CERT_VerifyCertificateNow
  * bmo#1912427 - Enable all supported protocol versions for UDP
  * bmo#1910361 - Actually use random PSK hash type
  * bmo#1911576 - Initialize NSS DB once
  * bmo#1910361 - Additional ECH cipher suites and PSK hash types
  * bmo#1903604 - Automate corpus file generation for TLS client Fuzzer
  * bmo#1910364 - Fix crash with UNSAFE_FUZZER_MODE
  * bmo#1910605 - clang-format shlibsign.c
- remove obsolete nss-reproducible-builds.patch
- update to NSS 3.103
  * bmo#1908623 - move list size check after lock acquisition in sftk_PutObjectToList.
  * bmo#1899542 - Add fuzzing support for SSL_ENABLE_POST_HANDSHAKE_AUTH,
  * bmo#1909638 - Follow-up to fix test for presence of file nspr.patch.
  * bmo#1903783 - Adjust libFuzzer size limits
  * bmo#1899542 - Add fuzzing support for SSL_SetCertificateCompressionAlgorithm,
    SSL_SetClientEchConfigs, SSL_VersionRangeSet and SSL_AddExternalPsk
  * bmo#1899542 - Add fuzzing support for SSL_ENABLE_GREASE and
    SSL_ENABLE_CH_EXTENSION_PERMUTATION
- Add nss-reproducible-builds.patch to make the rpms reproducible,
  by using a hardcoded, static key to generate the checksums (*.chk-files)
- Updated nss-fips-approved-crypto-non-ec.patch to enforce
  approved curves with the CKK_EC_MONTGOMERY key type (bsc#1224113).
- update to NSS 3.102.1
  * bmo#1905691 - ChaChaXor to return after the function
- update to NSS 3.102
  * bmo#1880351 - Add Valgrind annotations to freebl Chacha20-Poly1305.
  * bmo#1901932 - missing sqlite header.
  * bmo#1901080 - GLOBALTRUST 2020: Set Distrust After for TLS and S/MIME.
  * bmo#1615298 - improve certutil keyUsage, extKeyUsage, and nsCertType keyword handling.
  * bmo#1660676 - correct length of raw SPKI data before printing in pp utility.

- Add nss-reproducible-chksums.patch to make NSS-build reproducible
  Use key from openssl (bsc#1081723)

- Updated nss-fips-approved-crypto-non-ec.patch to exclude the
  SHA-1 hash from SLI approval.

Package libgcrypt was updated:

- Fix running the test suite in FIPS mode [bsc#1246934]  * Add libgcrypt-fix-pkcs12-test-in-FIPS-mode.patch
  * Rebase libgcrypt-FIPS-SLI-kdf-leylength.patch

Package gnutls was updated:

- Security fix bsc#1254132 CVE-2025-9820  * Fix buffer overflow in gnutls_pkcs11_token_init
  * Added gnutls-CVE-2025-9820.patch

Package gpgme was updated:

- Treat empty DISPLAY variable as unset. [bsc#1252425, bsc#1231055]  * To avoid gpgme constructing an invalid gpg command line when
    the DISPLAY variable is empty it can be treated as unset.
  * Add gpgme-Treat-empty-DISPLAY-variable-as-unset.patch
  * Reported upstream: dev.gnupg.org/T7919

Package libpng16 was updated:

- security update- added patches
  CVE-2025-66293 [bsc#1254480], LIBPNG out-of-bounds read in png_image_read_composite
  * libpng16-CVE-2025-66293-1.patch
  * libpng16-CVE-2025-66293-2.patch

- security update
- added patches
  CVE-2025-64505 [bsc#1254157], heap buffer over-read in `png_do_quantize` via malformed palette index
  * libpng16-CVE-2025-64505.patch
  CVE-2025-64506 [bsc#1254158], heap buffer over-read in `png_write_image_8bit` with 8-bit input and `convert_to_8bit` enabled
  * libpng16-CVE-2025-64506.patch
  CVE-2025-64720 [bsc#1254159], buffer overflow in `png_image_read_composite` via incorrect palette premultiplication
  * libpng16-CVE-2025-64720.patch
  CVE-2025-65018 [bsc#1254160], heap buffer overflow in `png_combine_row` triggered via `png_image_finish_read`
  * libpng16-CVE-2025-65018.patch

Package python311:base was updated:

- Add CVE-2025-13836-http-resp-cont-len.patch (bsc#1254400,  CVE-2025-13836) to prevent reading an HTTP response from
  a server, if no read amount is specified, with using
  Content-Length per default as the length.
- Add CVE-2025-12084-minidom-quad-search.patch prevent quadratic
  behavior in node ID cache clearing (CVE-2025-12084,
  bsc#1254997).
- Add CVE-2025-13837-plistlib-mailicious-length.patch protect
  against OOM when loading malicious content (CVE-2025-13837,
  bsc#1254401).

- Add CVE-2025-6075-expandvars-perf-degrad.patch avoid simple
  quadratic complexity vulnerabilities of os.path.expandvars()
  (CVE-2025-6075, bsc#1252974).
- Readjusted patches:
  - CVE-2023-52425-libexpat-2.6.0-backport.patch
  - CVE-2023-52425-remove-reparse_deferral-tests.patch
  - fix_configure_rst.patch
  - skip_if_buildbot-extend.patch

- Update to 3.11.14:
  - Security
  - gh-139700: Check consistency of the zip64 end of central
    directory record. Support records with âzip64 extensible dataâ
    if there are no bytes prepended to the ZIP file
    (CVE-2025-8291, bsc#1251305).
  - gh-139400: xml.parsers.expat: Make sure that parent Expat
    parsers are only garbage-collected once they are no longer
    referenced by subparsers created by
    ExternalEntityParserCreate(). Patch by Sebastian Pipping.
  - gh-135661: Fix parsing start and end tags in
    html.parser.HTMLParser according to the HTML5 standard.
  * Whitespaces no longer accepted between &amp;lt;/ and the tag name. E.g.
    &amp;lt;/ script&amp;gt; does not end the script section.
  * Vertical tabulation (\v) and non-ASCII whitespaces no longer
    recognized as whitespaces. The only whitespaces are \t\n\r\f and
    space.
  * Null character (U+0000) no longer ends the tag name.
  * Attributes and slashes after the tag name in end tags are now
    ignored, instead of terminating after the first &amp;gt; in quoted
    attribute value. E.g. &amp;lt;/script/foo=&amp;quot;&amp;gt;&amp;quot;/&amp;gt;.
  * Multiple slashes and whitespaces between the last attribute and
    closing &amp;gt; are now ignored in both start and end tags. E.g. &amp;lt;a
    foo=bar/ //&amp;gt;.
  * Multiple = between attribute name and value are no longer
    collapsed. E.g. &amp;lt;a foo==bar&amp;gt; produces attribute âfooâ with value
    â=barâ.
  - gh-135661: Fix CDATA section parsing in html.parser.HTMLParser
    according to the HTML5 standard: ] ]&amp;gt; and ]] &amp;gt; no longer end the
    CDATA section. Add private method _set_support_cdata() which can
    be used to specify how to parse &amp;lt;[CDATA[ â as a CDATA section in
    foreign content (SVG or MathML) or as a bogus comment in the
    HTML namespace.
  - gh-102555: Fix comment parsing in html.parser.HTMLParser
    according to the HTML5 standard. --!&amp;gt; now ends the comment. -- &amp;gt;
    no longer ends the comment. Support abnormally ended empty
    comments &amp;lt;--&amp;gt; and &amp;lt;---&amp;gt;.
  - gh-135462: Fix quadratic complexity in processing specially
    crafted input in html.parser.HTMLParser. End-of-file errors are
    now handled according to the HTML5 specs â comments and
    declarations are automatically closed, tags are ignored.
  - gh-118350: Fix support of escapable raw text mode (elements
    âtextareaâ and âtitleâ) in html.parser.HTMLParser.
  - gh-86155: html.parser.HTMLParser.close() no longer loses data
    when the &amp;lt;script&amp;gt; tag is not closed. Patch by Waylan Limberg.
  - Library
  - gh-139312: Upgrade bundled libexpat to 2.7.3
  - gh-138998: Update bundled libexpat to 2.7.2
  - gh-130577: tarfile now validates archives to ensure member
    offsets are non-negative. (Contributed by Alexander Enrique
    Urieles Nieto in gh-130577.)
  - gh-135374: Update the bundled copy of setuptools to 79.0.1.
- Drop upstreamed patches:
  - CVE-2025-8194-tarfile-no-neg-offsets.patch
  - CVE-2025-6069-quad-complex-HTMLParser.patch

- Add gh139257-Support-docutils-0.22.patch to fix build with latest
  docutils (&amp;gt;=0.22) gh#python/cpython#139257

- Drop AppStream buildrequires and don't run appstreamcli validate
  as part of the build process: the appdata.xml is not updated by
  source directly, so we have more contol. Having Appstream or the
  deprecated appstream-glib result in a build cycle.

- Require AppStream to validate appdata file instead of deprecated
  appstream-glib.
- Update idle3.appdata.xml to pass the more pedantic appstreamcli.

Package sqlite3 was updated:

- bsc#1252217: Add a %license file.
- bsc#1248586: Fix icu-enabled build.

- Update to version 3.50.4:
  * Fix two long-standings cases of the use of uninitialized
    variables in obscure circumstances.

- Update to version 3.50.3:
  * Fix a possible memory error that can occur if a query is made
    against against FTS5 index that has been deliberately corrupted
    in a very specific way.
  * Fix the parser so that it ignored SQL comments in all places of
    a CREATE TRIGGER statement. This resolves a problem that was
    introduced by the introduction of the
    SQLITE_DBCONFIG_ENABLE_COMMENTS feature in version 3.49.0.
  * Fix an incorrect answer due to over-optimization of an AND
    operator.

Package systemd was updated:

- Import commit 9ecd16228492f44212e2771bec11ec78245b4094  9ecd162284 timer: rebase last_trigger timestamp if needed
  cd4a9103ef timer: rebase the next elapse timestamp only if timer didn't already run
  c3f4407e97 timer: don't run service immediately after restart of a timer (bsc#1254563)
  05bcfe3295 test: check the next elapse timer timestamp after deserialization
  fe8f656975 test: restarting elapsed timer shouldn't trigger the corresponding service
  e4dd315b6c units: don't force the loading of the loop and dm_mod modules in systemd-repart.service (bsc#1248356)
  b58e72215a units: add dep on systemd-logind.service by user@.service
  97ceca445c detect-virt: add bare-metal support for GCE (bsc#1244449

- Sync systemd-update-helper with the version shipped in Base:System
  This includes the following changes:
  - systemd-update-helper: do not stop or disable services when they are migrated
    to other packages. This can occur during package renaming or splitting.
  - systemd-update-helper: Fix invalid use of &amp;quot;break&amp;quot; in case statement
  - systemd-update-helper: fix regression introduced when support for package
    renaming/splitting was added (bsc#1245551)

- systemd-update-helper: backport commit 2d0af8bc354f4a1429ce
  Since user@.service has `Type=notify-reload` (making the reloading process
  synchronous) and reloading implies reexecuting with `ReloadSignal=RTMIN+25`,
  reexecuting user managers synchronously can be achieved with `systemctl reload
  user@*.service&amp;quot; now.

- systemd.spec: use %sysusers_generate_pre so that some systemd users are
  already available in %pre. This is important because D-Bus automatically
  reloads its configuration whenever new configuration files are installed,
  i.e. between %pre and %post. (bsc#1248501)
  No needs for systemd and udev packages as they are always installed during
  the initial installation.

- Split systemd-network into two new sub-packages: systemd-networkd and
  systemd-resolved (bsc#1224386 jsc#PED-12669)

Package libtasn1 was updated:

- Security fix: [bsc#1256341, CVE-2025-13151]  * Stack-based buffer overflow. The function asn1_expend_octet_string()
    fails to validate the size of input data resulting in a buffer overflow.
  * Add libtasn1-CVE-2025-13151.patch

Package mozilla-nspr was updated:

- update to version 4.36  * remove support for OS/2
  * remove support for Unixware, Bsdi, old AIX, old HPUX9 &amp;amp; scoos
  * remove support for Windows 16 bit
  * renamed the prwin16.h header to prwin.h
  * configure was updated from 2.69 to 2.71
  * various build, test and automation script fixes
  * major parts of the source code were reformatted

Package openssh was updated:

- Add openssh-cve-2025-61984-username-validation.patch  (bsc#1251198, CVE-2025-61984).
- Add openssh-cve-2025-61985-nul-url-encode.patch
  (bsc#1251199, CVE-2025-61985).

Package podman was updated:

- Add patch for CVE-2025-47914 (bsc#1253993), CVE-2025-47913 (bsc#1253542):  * 0012-CVE-2025-47913-CVE-2025-47914-ssh-agent-fixes.patch
- Rebase patches:
  * 0001-vendor-update-c-buildah-to-1.33.12.patch
  * 0002-Backport-fix-for-CVE-2024-6104.patch
  * 0003-Switch-hashicorp-go-retryablehttp-to-the-SUSE-fork.patch
  * 0004-http2-close-connections-when-receiving-too-many-head.patch
  * 0005-CVE-2025-27144-vendor-don-t-allow-unbounded-amounts-.patch
  * 0006-CVE-2025-22869-ssh-limit-the-size-of-the-internal-pa.patch
  * 0007-Fix-Remove-appending-rw-as-the-default-mount-option.patch
  * 0008-CVE-2025-6032-machine-init-fix-tls-check.patch
  * 0009-CVE-2025-9566-kube-play-don-t-follow-volume-symlinks.patch
  * 0010-vendor-buildah-Don-t-set-ambient-capabilities.patch
  * 0011-CVE-2025-52881-backport-subset-of-patch-from-runc.patch

- Add patch for CVE-2025-31133,CVE-2025-52565,CVE-2025-52881 (bsc#1252376):
  * 0011-CVE-2025-52881-backport-subset-of-patch-from-runc.patch
- Add patch for bsc#1252543:
  * 0010-vendor-buildah-Don-t-set-ambient-capabilities.patch
- Rebase patches:
  * 0001-vendor-update-c-buildah-to-1.33.12.patch
  * 0002-Backport-fix-for-CVE-2024-6104.patch
  * 0003-Switch-hashicorp-go-retryablehttp-to-the-SUSE-fork.patch
  * 0004-http2-close-connections-when-receiving-too-many-head.patch
  * 0005-CVE-2025-27144-vendor-don-t-allow-unbounded-amounts-.patch
  * 0006-CVE-2025-22869-ssh-limit-the-size-of-the-internal-pa.patch
  * 0007-Fix-Remove-appending-rw-as-the-default-mount-option.patch
  * 0008-CVE-2025-6032-machine-init-fix-tls-check.patch
  * 0009-CVE-2025-9566-kube-play-don-t-follow-volume-symlinks.patch

Package python-urllib3 was updated:

- Add CVE-2026-21441.patch to fix excessive resource consumption  during decompression of data in HTTP redirect responses
  (bsc#1256331, CVE-2026-21441)

Package python311 was updated:

- Add CVE-2025-13836-http-resp-cont-len.patch (bsc#1254400,  CVE-2025-13836) to prevent reading an HTTP response from
  a server, if no read amount is specified, with using
  Content-Length per default as the length.
- Add CVE-2025-12084-minidom-quad-search.patch prevent quadratic
  behavior in node ID cache clearing (CVE-2025-12084,
  bsc#1254997).
- Add CVE-2025-13837-plistlib-mailicious-length.patch protect
  against OOM when loading malicious content (CVE-2025-13837,
  bsc#1254401).

- Add CVE-2025-6075-expandvars-perf-degrad.patch avoid simple
  quadratic complexity vulnerabilities of os.path.expandvars()
  (CVE-2025-6075, bsc#1252974).
- Readjusted patches:
  - CVE-2023-52425-libexpat-2.6.0-backport.patch
  - CVE-2023-52425-remove-reparse_deferral-tests.patch
  - fix_configure_rst.patch
  - skip_if_buildbot-extend.patch

- Update to 3.11.14:
  - Security
  - gh-139700: Check consistency of the zip64 end of central
    directory record. Support records with âzip64 extensible dataâ
    if there are no bytes prepended to the ZIP file
    (CVE-2025-8291, bsc#1251305).
  - gh-139400: xml.parsers.expat: Make sure that parent Expat
    parsers are only garbage-collected once they are no longer
    referenced by subparsers created by
    ExternalEntityParserCreate(). Patch by Sebastian Pipping.
  - gh-135661: Fix parsing start and end tags in
    html.parser.HTMLParser according to the HTML5 standard.
  * Whitespaces no longer accepted between &amp;lt;/ and the tag name. E.g.
    &amp;lt;/ script&amp;gt; does not end the script section.
  * Vertical tabulation (\v) and non-ASCII whitespaces no longer
    recognized as whitespaces. The only whitespaces are \t\n\r\f and
    space.
  * Null character (U+0000) no longer ends the tag name.
  * Attributes and slashes after the tag name in end tags are now
    ignored, instead of terminating after the first &amp;gt; in quoted
    attribute value. E.g. &amp;lt;/script/foo=&amp;quot;&amp;gt;&amp;quot;/&amp;gt;.
  * Multiple slashes and whitespaces between the last attribute and
    closing &amp;gt; are now ignored in both start and end tags. E.g. &amp;lt;a
    foo=bar/ //&amp;gt;.
  * Multiple = between attribute name and value are no longer
    collapsed. E.g. &amp;lt;a foo==bar&amp;gt; produces attribute âfooâ with value
    â=barâ.
  - gh-135661: Fix CDATA section parsing in html.parser.HTMLParser
    according to the HTML5 standard: ] ]&amp;gt; and ]] &amp;gt; no longer end the
    CDATA section. Add private method _set_support_cdata() which can
    be used to specify how to parse &amp;lt;[CDATA[ â as a CDATA section in
    foreign content (SVG or MathML) or as a bogus comment in the
    HTML namespace.
  - gh-102555: Fix comment parsing in html.parser.HTMLParser
    according to the HTML5 standard. --!&amp;gt; now ends the comment. -- &amp;gt;
    no longer ends the comment. Support abnormally ended empty
    comments &amp;lt;--&amp;gt; and &amp;lt;---&amp;gt;.
  - gh-135462: Fix quadratic complexity in processing specially
    crafted input in html.parser.HTMLParser. End-of-file errors are
    now handled according to the HTML5 specs â comments and
    declarations are automatically closed, tags are ignored.
  - gh-118350: Fix support of escapable raw text mode (elements
    âtextareaâ and âtitleâ) in html.parser.HTMLParser.
  - gh-86155: html.parser.HTMLParser.close() no longer loses data
    when the &amp;lt;script&amp;gt; tag is not closed. Patch by Waylan Limberg.
  - Library
  - gh-139312: Upgrade bundled libexpat to 2.7.3
  - gh-138998: Update bundled libexpat to 2.7.2
  - gh-130577: tarfile now validates archives to ensure member
    offsets are non-negative. (Contributed by Alexander Enrique
    Urieles Nieto in gh-130577.)
  - gh-135374: Update the bundled copy of setuptools to 79.0.1.
- Drop upstreamed patches:
  - CVE-2025-8194-tarfile-no-neg-offsets.patch
  - CVE-2025-6069-quad-complex-HTMLParser.patch

- Add gh139257-Support-docutils-0.22.patch to fix build with latest
  docutils (&amp;gt;=0.22) gh#python/cpython#139257

- Drop AppStream buildrequires and don't run appstreamcli validate
  as part of the build process: the appdata.xml is not updated by
  source directly, so we have more contol. Having Appstream or the
  deprecated appstream-glib result in a build cycle.

- Require AppStream to validate appdata file instead of deprecated
  appstream-glib.
- Update idle3.appdata.xml to pass the more pedantic appstreamcli.

Package rsync was updated:

- Security update (CVE-2025-10158, bsc#1254441): rsync: Out of  bounds array access via negative index
  - Add rsync-CVE-2025-10158.patch

Package runc was updated:

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

- Update to runc v1.3.3. Upstream changelog is available from
  &amp;lt;https://github.com/opencontainers/runc/releases/tag/v1.3.3&amp;gt;. bsc#1252232
  * CVE-2025-31133
  * CVE-2025-52565
  * CVE-2025-52881
- Remove upstreamed patches for bsc#1252232:
  - 2025-11-05-CVEs.patch

[ This update was only released for SLE 12 and 15. ]
- Backport patches for three CVEs. All three vulnerabilities ultimately allow
  (through different methods) for full container breakouts by bypassing runc's
  restrictions for writing to arbitrary /proc files. bsc#1252232
  * CVE-2025-31133
  * CVE-2025-52565
  * CVE-2025-52881
  + 2025-11-05-CVEs.patch

[ This update was only released for SLE 12 and 15. ]
- Update to runc v1.2.7. Upstream changelog is available from
  &amp;lt;https://github.com/opencontainers/runc/releases/tag/v1.2.7&amp;gt;.

- Update to runc v1.3.2. Upstream changelog is available from
  &amp;lt;https://github.com/opencontainers/runc/releases/tag/v1.3.2&amp;gt; bsc#1252110
  - Includes an important fix for the CPUSet translation for cgroupv2.

Package selinux-policy was updated:

- Update to version 20230523+git34.7b0eea050:  * rsync: add rsync_exec_commands boolean and enable it by default (bsc#1231494, bsc#1255372)

- Fix systemd generator.early and generator.late file contexts (bsc#1255027)

Package shim was updated:

- shim-install: Add ca_string for SL Micro to update fallback loader  The fallback loader, /boot/efi/EFI/BOOT/bootaa64.efi or bootx64.efi,
  cannot be upgraded by shim-install on SL Micro. The issue case is
  SL Micro 6.0. It causes that system gets regression bug because it's
  fallback to a old shim. So this patch adds ca_string to SL Micro.
  (bsc#1254336)

- Add DER format certificate files for the pretrans script to verify
  that the necessary certificate is in the UEFI db
  - openSUSE Secure Boot CA, 2013-2035
    openSUSE_Secure_Boot_CA_2013.crt
  - SUSE Linux Enterprise Secure Boot CA, 2013-2035
    SUSE_Linux_Enterprise_Secure_Boot_CA_2013.crt
  - Microsoft Corporation UEFI CA 2011, 2011-2026
    Microsoft_Corporation_UEFI_CA_2011.crt
  - Microsoft UEFI CA 2023, 2023-2038
    Microsoft_UEFI_CA_2023.crt
- shim.spec: Add a pretrans script to verify that the necessary certificate
  is in the UEFI db.
- Always put SUSE Linux Enterprise Secure Boot CA to target array.
  (bsc#1254679)

- Update to 16.1
  - RPMs
    shim-16.1-150300.4.31.1.x86_64.rpm
    shim-debuginfo-16.1-150300.4.31.1.x86_64.rpm
    shim-debugsource-16.1-150300.4.31.1.x86_64.rpm
    shim-16.1-150300.4.31.1.aarch64.rpm
    shim-debuginfo-16.1-150300.4.31.1.aarch64.rpm
    shim-debugsource-16.1-150300.4.31.1.aarch64.rpm
  - submitreq: https://build.suse.de/request/show/395247
  - repo: https://build.suse.de/package/show/SUSE:Maintenance:39913/shim.SUSE_SLE-15-SP3_Update
  - Patches (git log --oneline --reverse 16.0..16.1)
    4040ec4 shim_start_image(): fix guid/handle pairing when uninstalling protocols
    39c0aa1 str2ip6(): parsing of &amp;quot;uncompressed&amp;quot; ipv6 addresses
    3133d19 test-mock-variables: make our filter list entries safer.
    d44405e mock-variables: remove unused variable
    0e8459f Update CI to use ubuntu-24.04 instead of ubuntu-20.04
    d16a5a6 SbatLevel_Variable.txt: minor typo fix.
    32804cf Realloc() needs one more byte for sprintf()
    431d370 IPv6: Add more check to avoid multiple double colon and illegal char
    5e4d93c Loader Proto: make freeing of bprop.buffer conditional.
    33deac2 Prepare to move things from shim.c to verify.c
    030e7df Move a bunch of stuff from shim.c to verify.c
    f3ddda7 handle_image(): make verification conditional
    774f226 Cache sections of a loaded image and sub-images from them.
    eb0d20b loader-protocol: handle sub-section loading for UKIs
    2f64bb9 loader-protocol: add workaround for EDK2 2025.02 page fault on FreePages
    1abc7ca loader-protocol: NULL output variable in load_image on failure
    fb77b44 Generate Authenticode for the entire PE file
    b86b909 README: mention new loader protocol and interaction with UKIs
    8522612 ci: add mkosi configuration and CI
    9ebab84 mkosi workflow: fix the branch name for main.
    72a4c41 shim: change automatically enable MOK_POLICY_REQUIRE_NX
    a2f0dfa This is an organizational patch to move some things around in mok.c
    54b9946 Update to the shim-16.1 branch of gnu-efi to get AsciiSPrint()
    a5a6922 get_max_var_sz(): add more debugging for apple platforms
    77a2922 Add a &amp;quot;VariableInfo&amp;quot; variable to mok-variables.
    efc71c9 build: Avoid passing *FLAGS to sub-make
    7670932 Fixes for 'make TOPDIR=... clean'
    13ab598 add SbatLevel entry 2025051000 for PSA-2025-00012-1
    617aed5 Update version to 16.1~rc1
    d316ba8 format_variable_info(): fix wrong size test.
    f5fad0e _do_sha256_sum(): Fix missing error check.
    3a9734d doc: add howto for running mkosi locally
    ced5f71 mkosi: remove spurious slashes from script
    0076155 ci: update mkosi commit
    5481105 fix http boot
    121cddf loader-protocol: Handle UnloadImage after StartImage properly
    6a1d1a9 loader-protocol: Fix memory leaks
    27a5d22 gitignore: add more mkosi dirs and vscode dir
    346ed15 mkosi: disable repository key check on Fedora
    afc4955 Update version to 16.1
  - 16.1 release note https://github.com/rhboot/shim/releases
    shim_start_image(): fix guid/handle pairing when uninstalling protocols by @vathpela in #738
    Fix uncompressed ipv6 netboot by @hrvach in #742
    fix test segfaults caused by uninitialized memory by @Fabian-Gruenbichler in #739
    Update CI to use ubuntu-24.04 instead of ubuntu-20.04 by @vathpela in #749
    SbatLevel_Variable.txt: minor typo fix. by @vathpela in #751
    Realloc() needs to allocate one more byte for sprintf() by @dennis-tseng99 in #746
    IPv6: Add more check to avoid multiple double colon and illegal char by @dennis-tseng99 in #753
    Loader proto v2 by @vathpela in #748
    loader-protocol: add workaround for EDK2 2025.02 page fault on FreePages by @bluca in #750
    Generate Authenticode for the entire PE file by @esnowberg in #604
    README: mention new loader protocol and interaction with UKIs by @bluca in #755
    ci: add mkosi configuration and CI by @bluca in #764
    shim: change automatically enable MOK_POLICY_REQUIRE_NX by @vathpela in #761
    Save var info by @vathpela in #763
    build: Avoid passing *FLAGS to sub-make by @rosslagerwall in #758
    Fixes for 'make TOPDIR=... clean' by @bluca in #762
    add SbatLevel entry 2025051000 for PSA-2025-00012-1 by @Fabian-Gruenbichler in #766
    Coverity fixes 20250804 by @vathpela in #767
    ci: fixlets and docs for mkosi workflow by @bluca in #768
    fix http boot by @jsetje in #770
    Fix double free and leak in the loader protocol by @rosslagerwall in #769
    gitignore: add more mkosi dirs and vscode dir by @bluca in #771
  - Drop upstreamed patch:
    The following patches are merged to 16.1
  - shim-alloc-one-more-byte-for-sprintf.patch
  - 32804cf5d9 Realloc() needs one more byte for sprintf()    [16.1]
  - shim-change-automatically-enable-MOK_POLICY_REQUIRE_NX.patch (bsc#1205588)
  - 72a4c41877 shim: change automatically enable MOK_POLICY_REQUIRE_NX [16.1]
- Building MokManager.efi and fallback.efi with POST_PROCESS_PE_FLAGS=-n (bsc#1205588)
- Building with the latest version of gcc in the codebase:
  - The gcc13 can workaround dxe_get_mem_attrs() hsi_status problem
  - We prefer that building shim with the latest version of gcc in codebase.
  - Set the minimum version is gcc-13.
  (bsc#1247432)
- SLE shim should includes vendor-dbx-sles.esl instead of
  vendor-dbx-opensuse.esl. Fixed it in shim.spec.

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

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

Package supportutils was updated:

- Changes to version 3.2.12  + Optimized lsof usage and honors OPTION_OFILES (bsc#1232351, PR#274)
  + Run in containers without errors (bsc#1245667, PR#272)
  + Removed pmap PID from memory.txt (bsc#1246011, PR#263)
  + Added missing /proc/pagetypeinfo to memory.txt (bsc#1246025, PR#264)
  + Improved database perforce with kGraft patching (bsc#1249657, PR#273)
  + Using last boot for journalctl for optimization (bsc#1250224, PR#287)
  + Fixed extraction failures (bsc#1252318, PR#275)
  + Update supportconfig.conf path in docs (bsc#1254425, PR#281)
  + drm_sub_info: Catch error when dir doesn't exist (PR#265)
  + Replace remaining `egrep` with `grep -E` (PR#261, PR#266)
  + Add process affinity to slert logs (PR#269)
  + Reintroduce cgroup statistics (and v2) (PR#270)
  + Minor changes to basic-health-check: improve information level (PR#271)
  + Collect important machine health counters (PR#276)
  + powerpc: collect hot-pluggable PCI and PHB slots (PR#278)
  + podman: collect podman disk usage (PR#279)
  + Exclude binary files in crondir (PR#282)
  + kexec/kdump: collect everything under /sys/kernel/kexec dir (PR#284)
  + Use short-iso for journalctl (PR#288)

- Changes to version 3.2.11
  + Collect rsyslog frule files (bsc#1244003, pr#257)
  + Remove proxy passwords (bsc#1244011, pr#257)
  + Missing NetworkManager information (bsc#1241284, pr#257)
  + Include agama logs bsc#1244937, pr#256)
  + Additional NFS conf files (pr#253)
  + New fadump sysfs files (pr#252)
  + Fixed change log dates

</Note>
    <Note Title="Terms of Use" Type="Legal Disclaimer" Ordinal="3" xml:lang="en">The CVRF data is provided by SUSE under the Creative Commons License 4.0 with Attribution (CC-BY-4.0).</Note>
  </DocumentNotes>
  <DocumentReferences>
    <Reference Type="Self">
      <URL>https://publiccloudimagechangeinfo.suse.com/google/sle-micro-6-0-byos-v20260130-arm64/</URL>
      <Description>Public Cloud Image Info</Description>
    </Reference>
    <Reference Type="Self">
      <URL>https://www.suse.com/support/security/rating/</URL>
      <Description>SUSE Security Ratings</Description>
    </Reference>
  </DocumentReferences>
  <ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
    <Branch Type="Product Family" Name="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <Branch Type="Product Name" Name="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
        <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
      </Branch>
    </Branch>
    <Branch Type="Product Version" Name="SL-Micro-release-6.0-25.64">
      <FullProductName ProductID="SL-Micro-release-6.0-25.64">SL-Micro-release-6.0-25.64</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cloud-netconfig-gce-1.16-1.1">
      <FullProductName ProductID="cloud-netconfig-gce-1.16-1.1">cloud-netconfig-gce-1.16-1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="containerd-1.7.29-1.1">
      <FullProductName ProductID="containerd-1.7.29-1.1">containerd-1.7.29-1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="curl-8.14.1-3.1">
      <FullProductName ProductID="curl-8.14.1-3.1">curl-8.14.1-3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="docker-28.5.1_ce-8.1">
      <FullProductName ProductID="docker-28.5.1_ce-8.1">docker-28.5.1_ce-8.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="docker-buildx-0.29.0-8.1">
      <FullProductName ProductID="docker-buildx-0.29.0-8.1">docker-buildx-0.29.0-8.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="dracut-059+suse.607.g05002594-1.1">
      <FullProductName ProductID="dracut-059+suse.607.g05002594-1.1">dracut-059+suse.607.g05002594-1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glib2-tools-2.76.2-11.1">
      <FullProductName ProductID="glib2-tools-2.76.2-11.1">glib2-tools-2.76.2-11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="gpg2-2.4.4-6.1">
      <FullProductName ProductID="gpg2-2.4.4-6.1">gpg2-2.4.4-6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kernel-default-6.4.0-36.1">
      <FullProductName ProductID="kernel-default-6.4.0-36.1">kernel-default-6.4.0-36.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kmod-30-11.1">
      <FullProductName ProductID="kmod-30-11.1">kmod-30-11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libcurl-mini4-8.14.1-3.1">
      <FullProductName ProductID="libcurl-mini4-8.14.1-3.1">libcurl-mini4-8.14.1-3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libfreebl3-3.112.2-1.1">
      <FullProductName ProductID="libfreebl3-3.112.2-1.1">libfreebl3-3.112.2-1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgcrypt20-1.10.3-3.1">
      <FullProductName ProductID="libgcrypt20-1.10.3-3.1">libgcrypt20-1.10.3-3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgio-2_0-0-2.76.2-11.1">
      <FullProductName ProductID="libgio-2_0-0-2.76.2-11.1">libgio-2_0-0-2.76.2-11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libglib-2_0-0-2.76.2-11.1">
      <FullProductName ProductID="libglib-2_0-0-2.76.2-11.1">libglib-2_0-0-2.76.2-11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgmodule-2_0-0-2.76.2-11.1">
      <FullProductName ProductID="libgmodule-2_0-0-2.76.2-11.1">libgmodule-2_0-0-2.76.2-11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgnutls30-3.8.3-5.1">
      <FullProductName ProductID="libgnutls30-3.8.3-5.1">libgnutls30-3.8.3-5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgobject-2_0-0-2.76.2-11.1">
      <FullProductName ProductID="libgobject-2_0-0-2.76.2-11.1">libgobject-2_0-0-2.76.2-11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgpgme11-1.23.0-2.1">
      <FullProductName ProductID="libgpgme11-1.23.0-2.1">libgpgme11-1.23.0-2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libkmod2-30-11.1">
      <FullProductName ProductID="libkmod2-30-11.1">libkmod2-30-11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpng16-16-1.6.43-2.1">
      <FullProductName ProductID="libpng16-16-1.6.43-2.1">libpng16-16-1.6.43-2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpython3_11-1_0-3.11.14-2.1">
      <FullProductName ProductID="libpython3_11-1_0-3.11.14-2.1">libpython3_11-1_0-3.11.14-2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsoftokn3-3.112.2-1.1">
      <FullProductName ProductID="libsoftokn3-3.112.2-1.1">libsoftokn3-3.112.2-1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsqlite3-0-3.50.4-1.1">
      <FullProductName ProductID="libsqlite3-0-3.50.4-1.1">libsqlite3-0-3.50.4-1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsystemd0-254.27-2.1">
      <FullProductName ProductID="libsystemd0-254.27-2.1">libsystemd0-254.27-2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libtasn1-6-4.19.0-5.1">
      <FullProductName ProductID="libtasn1-6-4.19.0-5.1">libtasn1-6-4.19.0-5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libudev1-254.27-2.1">
      <FullProductName ProductID="libudev1-254.27-2.1">libudev1-254.27-2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="mozilla-nspr-4.36-1.1">
      <FullProductName ProductID="mozilla-nspr-4.36-1.1">mozilla-nspr-4.36-1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="mozilla-nss-3.112.2-1.1">
      <FullProductName ProductID="mozilla-nss-3.112.2-1.1">mozilla-nss-3.112.2-1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="mozilla-nss-certs-3.112.2-1.1">
      <FullProductName ProductID="mozilla-nss-certs-3.112.2-1.1">mozilla-nss-certs-3.112.2-1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-9.6p1-4.1">
      <FullProductName ProductID="openssh-9.6p1-4.1">openssh-9.6p1-4.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-clients-9.6p1-4.1">
      <FullProductName ProductID="openssh-clients-9.6p1-4.1">openssh-clients-9.6p1-4.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-common-9.6p1-4.1">
      <FullProductName ProductID="openssh-common-9.6p1-4.1">openssh-common-9.6p1-4.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-server-9.6p1-4.1">
      <FullProductName ProductID="openssh-server-9.6p1-4.1">openssh-server-9.6p1-4.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="podman-4.9.5-10.1">
      <FullProductName ProductID="podman-4.9.5-10.1">podman-4.9.5-10.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python311-3.11.14-2.1">
      <FullProductName ProductID="python311-3.11.14-2.1">python311-3.11.14-2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python311-base-3.11.14-2.1">
      <FullProductName ProductID="python311-base-3.11.14-2.1">python311-base-3.11.14-2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python311-urllib3-2.1.0-4.1">
      <FullProductName ProductID="python311-urllib3-2.1.0-4.1">python311-urllib3-2.1.0-4.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="rsync-3.2.7-5.1">
      <FullProductName ProductID="rsync-3.2.7-5.1">rsync-3.2.7-5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="runc-1.3.4-1.1">
      <FullProductName ProductID="runc-1.3.4-1.1">runc-1.3.4-1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="selinux-policy-20230523+git34.7b0eea050-1.1">
      <FullProductName ProductID="selinux-policy-20230523+git34.7b0eea050-1.1">selinux-policy-20230523+git34.7b0eea050-1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="selinux-policy-targeted-20230523+git34.7b0eea050-1.1">
      <FullProductName ProductID="selinux-policy-targeted-20230523+git34.7b0eea050-1.1">selinux-policy-targeted-20230523+git34.7b0eea050-1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="shim-16.1-1.1">
      <FullProductName ProductID="shim-16.1-1.1">shim-16.1-1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="supportutils-3.2.12.2-1.1">
      <FullProductName ProductID="supportutils-3.2.12.2-1.1">supportutils-3.2.12.2-1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="supportutils-plugin-suse-public-cloud-1.0.9-1.1">
      <FullProductName ProductID="supportutils-plugin-suse-public-cloud-1.0.9-1.1">supportutils-plugin-suse-public-cloud-1.0.9-1.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-254.27-2.1">
      <FullProductName ProductID="systemd-254.27-2.1">systemd-254.27-2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-coredump-254.27-2.1">
      <FullProductName ProductID="systemd-coredump-254.27-2.1">systemd-coredump-254.27-2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="udev-254.27-2.1">
      <FullProductName ProductID="udev-254.27-2.1">udev-254.27-2.1</FullProductName>
    </Branch>
    <Relationship ProductReference="SL-Micro-release-6.0-25.64" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:SL-Micro-release-6.0-25.64">SL-Micro-release-6.0-25.64 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cloud-netconfig-gce-1.16-1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:cloud-netconfig-gce-1.16-1.1">cloud-netconfig-gce-1.16-1.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="containerd-1.7.29-1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:containerd-1.7.29-1.1">containerd-1.7.29-1.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="curl-8.14.1-3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:curl-8.14.1-3.1">curl-8.14.1-3.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="docker-28.5.1_ce-8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:docker-28.5.1_ce-8.1">docker-28.5.1_ce-8.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="docker-buildx-0.29.0-8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:docker-buildx-0.29.0-8.1">docker-buildx-0.29.0-8.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="dracut-059+suse.607.g05002594-1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:dracut-059+suse.607.g05002594-1.1">dracut-059+suse.607.g05002594-1.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glib2-tools-2.76.2-11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:glib2-tools-2.76.2-11.1">glib2-tools-2.76.2-11.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="gpg2-2.4.4-6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:gpg2-2.4.4-6.1">gpg2-2.4.4-6.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kernel-default-6.4.0-36.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:kernel-default-6.4.0-36.1">kernel-default-6.4.0-36.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kmod-30-11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:kmod-30-11.1">kmod-30-11.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libcurl-mini4-8.14.1-3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:libcurl-mini4-8.14.1-3.1">libcurl-mini4-8.14.1-3.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libfreebl3-3.112.2-1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:libfreebl3-3.112.2-1.1">libfreebl3-3.112.2-1.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgcrypt20-1.10.3-3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:libgcrypt20-1.10.3-3.1">libgcrypt20-1.10.3-3.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgio-2_0-0-2.76.2-11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:libgio-2_0-0-2.76.2-11.1">libgio-2_0-0-2.76.2-11.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libglib-2_0-0-2.76.2-11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:libglib-2_0-0-2.76.2-11.1">libglib-2_0-0-2.76.2-11.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgmodule-2_0-0-2.76.2-11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:libgmodule-2_0-0-2.76.2-11.1">libgmodule-2_0-0-2.76.2-11.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgnutls30-3.8.3-5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:libgnutls30-3.8.3-5.1">libgnutls30-3.8.3-5.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgobject-2_0-0-2.76.2-11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:libgobject-2_0-0-2.76.2-11.1">libgobject-2_0-0-2.76.2-11.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgpgme11-1.23.0-2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:libgpgme11-1.23.0-2.1">libgpgme11-1.23.0-2.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libkmod2-30-11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:libkmod2-30-11.1">libkmod2-30-11.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpng16-16-1.6.43-2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:libpng16-16-1.6.43-2.1">libpng16-16-1.6.43-2.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpython3_11-1_0-3.11.14-2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:libpython3_11-1_0-3.11.14-2.1">libpython3_11-1_0-3.11.14-2.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsoftokn3-3.112.2-1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:libsoftokn3-3.112.2-1.1">libsoftokn3-3.112.2-1.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsqlite3-0-3.50.4-1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:libsqlite3-0-3.50.4-1.1">libsqlite3-0-3.50.4-1.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsystemd0-254.27-2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:libsystemd0-254.27-2.1">libsystemd0-254.27-2.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libtasn1-6-4.19.0-5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:libtasn1-6-4.19.0-5.1">libtasn1-6-4.19.0-5.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libudev1-254.27-2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:libudev1-254.27-2.1">libudev1-254.27-2.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="mozilla-nspr-4.36-1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:mozilla-nspr-4.36-1.1">mozilla-nspr-4.36-1.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="mozilla-nss-3.112.2-1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:mozilla-nss-3.112.2-1.1">mozilla-nss-3.112.2-1.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="mozilla-nss-certs-3.112.2-1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:mozilla-nss-certs-3.112.2-1.1">mozilla-nss-certs-3.112.2-1.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-9.6p1-4.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:openssh-9.6p1-4.1">openssh-9.6p1-4.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-clients-9.6p1-4.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:openssh-clients-9.6p1-4.1">openssh-clients-9.6p1-4.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-common-9.6p1-4.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:openssh-common-9.6p1-4.1">openssh-common-9.6p1-4.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-server-9.6p1-4.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:openssh-server-9.6p1-4.1">openssh-server-9.6p1-4.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="podman-4.9.5-10.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:podman-4.9.5-10.1">podman-4.9.5-10.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python311-3.11.14-2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:python311-3.11.14-2.1">python311-3.11.14-2.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python311-base-3.11.14-2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:python311-base-3.11.14-2.1">python311-base-3.11.14-2.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python311-urllib3-2.1.0-4.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:python311-urllib3-2.1.0-4.1">python311-urllib3-2.1.0-4.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="rsync-3.2.7-5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:rsync-3.2.7-5.1">rsync-3.2.7-5.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="runc-1.3.4-1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:runc-1.3.4-1.1">runc-1.3.4-1.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="selinux-policy-20230523+git34.7b0eea050-1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:selinux-policy-20230523+git34.7b0eea050-1.1">selinux-policy-20230523+git34.7b0eea050-1.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="selinux-policy-targeted-20230523+git34.7b0eea050-1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:selinux-policy-targeted-20230523+git34.7b0eea050-1.1">selinux-policy-targeted-20230523+git34.7b0eea050-1.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="shim-16.1-1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:shim-16.1-1.1">shim-16.1-1.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="supportutils-3.2.12.2-1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:supportutils-3.2.12.2-1.1">supportutils-3.2.12.2-1.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="supportutils-plugin-suse-public-cloud-1.0.9-1.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:supportutils-plugin-suse-public-cloud-1.0.9-1.1">supportutils-plugin-suse-public-cloud-1.0.9-1.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-254.27-2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:systemd-254.27-2.1">systemd-254.27-2.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-coredump-254.27-2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:systemd-coredump-254.27-2.1">systemd-coredump-254.27-2.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64</FullProductName>
    </Relationship>
    <Relationship ProductReference="udev-254.27-2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64">
      <FullProductName ProductID="Public Cloud Image google/sle-micro-6-0-byos-v20260130-arm64:udev-254.27-2.1">udev-254.27-2.1 as a component of Public Cloud Image google/sle-micro-6-0-byos-v20260130-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">libexpat through 2.5.0 allows a denial of service (resource consumption) because many full reparsings are required in the case of a large token for which multiple buffer fills are needed.</Note>
    </Notes>
    <CVE>CVE-2023-52425</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: insert tree mod log move in push_node_left

There is a fairly unlikely race condition in tree mod log rewind that
can result in a kernel panic which has the following trace:

  [530.569] BTRFS critical (device sda3): unable to find logical 0 length 4096
  [530.585] BTRFS critical (device sda3): unable to find logical 0 length 4096
  [530.602] BUG: kernel NULL pointer dereference, address: 0000000000000002
  [530.618] #PF: supervisor read access in kernel mode
  [530.629] #PF: error_code(0x0000) - not-present page
  [530.641] PGD 0 P4D 0
  [530.647] Oops: 0000 [#1] SMP
  [530.654] CPU: 30 PID: 398973 Comm: below Kdump: loaded Tainted: G S         O  K   5.12.0-0_fbk13_clang_7455_gb24de3bdb045 #1
  [530.680] Hardware name: Quanta Mono Lake-M.2 SATA 1HY9U9Z001G/Mono Lake-M.2 SATA, BIOS F20_3A15 08/16/2017
  [530.703] RIP: 0010:__btrfs_map_block+0xaa/0xd00
  [530.755] RSP: 0018:ffffc9002c2f7600 EFLAGS: 00010246
  [530.767] RAX: ffffffffffffffea RBX: ffff888292e41000 RCX: f2702d8b8be15100
  [530.784] RDX: ffff88885fda6fb8 RSI: ffff88885fd973c8 RDI: ffff88885fd973c8
  [530.800] RBP: ffff888292e410d0 R08: ffffffff82fd7fd0 R09: 00000000fffeffff
  [530.816] R10: ffffffff82e57fd0 R11: ffffffff82e57d70 R12: 0000000000000000
  [530.832] R13: 0000000000001000 R14: 0000000000001000 R15: ffffc9002c2f76f0
  [530.848] FS:  00007f38d64af000(0000) GS:ffff88885fd80000(0000) knlGS:0000000000000000
  [530.866] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [530.880] CR2: 0000000000000002 CR3: 00000002b6770004 CR4: 00000000003706e0
  [530.896] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  [530.912] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  [530.928] Call Trace:
  [530.934]  ? btrfs_printk+0x13b/0x18c
  [530.943]  ? btrfs_bio_counter_inc_blocked+0x3d/0x130
  [530.955]  btrfs_map_bio+0x75/0x330
  [530.963]  ? kmem_cache_alloc+0x12a/0x2d0
  [530.973]  ? btrfs_submit_metadata_bio+0x63/0x100
  [530.984]  btrfs_submit_metadata_bio+0xa4/0x100
  [530.995]  submit_extent_page+0x30f/0x360
  [531.004]  read_extent_buffer_pages+0x49e/0x6d0
  [531.015]  ? submit_extent_page+0x360/0x360
  [531.025]  btree_read_extent_buffer_pages+0x5f/0x150
  [531.037]  read_tree_block+0x37/0x60
  [531.046]  read_block_for_search+0x18b/0x410
  [531.056]  btrfs_search_old_slot+0x198/0x2f0
  [531.066]  resolve_indirect_ref+0xfe/0x6f0
  [531.076]  ? ulist_alloc+0x31/0x60
  [531.084]  ? kmem_cache_alloc_trace+0x12e/0x2b0
  [531.095]  find_parent_nodes+0x720/0x1830
  [531.105]  ? ulist_alloc+0x10/0x60
  [531.113]  iterate_extent_inodes+0xea/0x370
  [531.123]  ? btrfs_previous_extent_item+0x8f/0x110
  [531.134]  ? btrfs_search_path_in_tree+0x240/0x240
  [531.146]  iterate_inodes_from_logical+0x98/0xd0
  [531.157]  ? btrfs_search_path_in_tree+0x240/0x240
  [531.168]  btrfs_ioctl_logical_to_ino+0xd9/0x180
  [531.179]  btrfs_ioctl+0xe2/0x2eb0

This occurs when logical inode resolution takes a tree mod log sequence
number, and then while backref walking hits a rewind on a busy node
which has the following sequence of tree mod log operations (numbers
filled in from a specific example, but they are somewhat arbitrary)

  REMOVE_WHILE_FREEING slot 532
  REMOVE_WHILE_FREEING slot 531
  REMOVE_WHILE_FREEING slot 530
  ...
  REMOVE_WHILE_FREEING slot 0
  REMOVE slot 455
  REMOVE slot 454
  REMOVE slot 453
  ...
  REMOVE slot 0
  ADD slot 455
  ADD slot 454
  ADD slot 453
  ...
  ADD slot 0
  MOVE src slot 0 -&gt; dst slot 456 nritems 533
  REMOVE slot 455
  REMOVE slot 454
  REMOVE slot 453
  ...
  REMOVE slot 0

When this sequence gets applied via btrfs_tree_mod_log_rewind, it
allocates a fresh rewind eb, and first inserts the correct key info for
the 533 elements, then overwrites the first 456 of them, then decrements
the count by 456 via the add ops, then rewinds the move by doing a
memmove from 456:988-&gt;0:532. We have never written anything past 532,
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53538</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 incomplete state save in rxe_requester

If a send packet is dropped by the IP layer in rxe_requester()
the call to rxe_xmit_packet() can fail with err == -EAGAIN.
To recover, the state of the wqe is restored to the state before
the packet was sent so it can be resent. However, the routines
that save and restore the state miss a significnt part of the
variable state in the wqe, the dma struct which is used to process
through the sge table. And, the state is not saved before the packet
is built which modifies the dma struct.

Under heavy stress testing with many QPs on a fast node sending
large messages to a slow node dropped packets are observed and
the resent packets are corrupted because the dma struct was not
restored. This patch fixes this behavior and allows the test cases
to succeed.</Note>
    </Notes>
    <CVE>CVE-2023-53539</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: reject auth/assoc to AP with our address

If the AP uses our own address as its MLD address or BSSID, then
clearly something's wrong. Reject such connections so we don't
try and fail later.</Note>
    </Notes>
    <CVE>CVE-2023-53540</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mtd: rawnand: brcmnand: Fix potential out-of-bounds access in oob write

When the oob buffer length is not in multiple of words, the oob write
function does out-of-bounds read on the oob source buffer at the last
iteration. Fix that by always checking length limit on the oob buffer
read and fill with 0xff when reaching the end of the buffer to the oob
registers.</Note>
    </Notes>
    <CVE>CVE-2023-53541</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vdpa: Add max vqp attr to vdpa_nl_policy for nlattr length check

The vdpa_nl_policy structure is used to validate the nlattr when parsing
the incoming nlmsg. It will ensure the attribute being described produces
a valid nlattr pointer in info-&gt;attrs before entering into each handler
in vdpa_nl_ops.

That is to say, the missing part in vdpa_nl_policy may lead to illegal
nlattr after parsing, which could lead to OOB read just like CVE-2023-3773.

This patch adds the missing nla_policy for vdpa max vqp attr to avoid
such bugs.</Note>
    </Notes>
    <CVE>CVE-2023-53543</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: unmap and remove csa_va properly

Root PD BO should be reserved before unmap and remove
a bo_va from VM otherwise lockdep will complain.

v2: check fpriv-&gt;csa_va is not NULL instead of amdgpu_mcbp (christian)

[14616.936827] WARNING: CPU: 6 PID: 1711 at drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1762 amdgpu_vm_bo_del+0x399/0x3f0 [amdgpu]
[14616.937096] Call Trace:
[14616.937097]  &lt;TASK&gt;
[14616.937102]  amdgpu_driver_postclose_kms+0x249/0x2f0 [amdgpu]
[14616.937187]  drm_file_free+0x1d6/0x300 [drm]
[14616.937207]  drm_close_helper.isra.0+0x62/0x70 [drm]
[14616.937220]  drm_release+0x5e/0x100 [drm]
[14616.937234]  __fput+0x9f/0x280
[14616.937239]  ____fput+0xe/0x20
[14616.937241]  task_work_run+0x61/0x90
[14616.937246]  exit_to_user_mode_prepare+0x215/0x220
[14616.937251]  syscall_exit_to_user_mode+0x2a/0x60
[14616.937254]  do_syscall_64+0x48/0x90
[14616.937257]  entry_SYSCALL_64_after_hwframe+0x63/0xcd</Note>
    </Notes>
    <CVE>CVE-2023-53545</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: DR, fix memory leak in mlx5dr_cmd_create_reformat_ctx

when mlx5_cmd_exec failed in mlx5dr_cmd_create_reformat_ctx, the memory
pointed by 'in' is not released, which will cause memory leak. Move memory
release after mlx5_cmd_exec.</Note>
    </Notes>
    <CVE>CVE-2023-53546</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: usbnet: Fix WARNING in usbnet_start_xmit/usb_submit_urb

The syzbot fuzzer identified a problem in the usbnet driver:

usb 1-1: BOGUS urb xfer, pipe 3 != type 1
WARNING: CPU: 0 PID: 754 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
Modules linked in:
CPU: 0 PID: 754 Comm: kworker/0:2 Not tainted 6.4.0-rc7-syzkaller-00014-g692b7dc87ca6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Workqueue: mld mld_ifc_work
RIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
Code: 7c 24 18 e8 2c b4 5b fb 48 8b 7c 24 18 e8 42 07 f0 fe 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 c9 fc 8a e8 5a 6f 23 fb &lt;0f&gt; 0b e9 58 f8 ff ff e8 fe b3 5b fb 48 81 c5 c0 05 00 00 e9 84 f7
RSP: 0018:ffffc9000463f568 EFLAGS: 00010086
RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
RDX: ffff88801eb28000 RSI: ffffffff814c03b7 RDI: 0000000000000001
RBP: ffff8881443b7190 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000003
R13: ffff88802a77cb18 R14: 0000000000000003 R15: ffff888018262500
FS:  0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000556a99c15a18 CR3: 0000000028c71000 CR4: 0000000000350ef0
Call Trace:
 &lt;TASK&gt;
 usbnet_start_xmit+0xfe5/0x2190 drivers/net/usb/usbnet.c:1453
 __netdev_start_xmit include/linux/netdevice.h:4918 [inline]
 netdev_start_xmit include/linux/netdevice.h:4932 [inline]
 xmit_one net/core/dev.c:3578 [inline]
 dev_hard_start_xmit+0x187/0x700 net/core/dev.c:3594
...

This bug is caused by the fact that usbnet trusts the bulk endpoint
addresses its probe routine receives in the driver_info structure, and
it does not check to see that these endpoints actually exist and have
the expected type and directions.

The fix is simply to add such a check.</Note>
    </Notes>
    <CVE>CVE-2023-53548</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cpufreq: amd-pstate: fix global sysfs attribute type

In commit 3666062b87ec ("cpufreq: amd-pstate: move to use bus_get_dev_root()")
the "amd_pstate" attributes where moved from a dedicated kobject to the
cpu root kobject.

While the dedicated kobject expects to contain kobj_attributes the root
kobject needs device_attributes.

As the changed arguments are not used by the callbacks it works most of
the time.
However CFI will detect this issue:

[ 4947.849350] CFI failure at dev_attr_show+0x24/0x60 (target: show_status+0x0/0x70; expected type: 0x8651b1de)
...
[ 4947.849409] Call Trace:
[ 4947.849410]  &lt;TASK&gt;
[ 4947.849411]  ? __warn+0xcf/0x1c0
[ 4947.849414]  ? dev_attr_show+0x24/0x60
[ 4947.849415]  ? report_cfi_failure+0x4e/0x60
[ 4947.849417]  ? handle_cfi_failure+0x14c/0x1d0
[ 4947.849419]  ? __cfi_show_status+0x10/0x10
[ 4947.849420]  ? handle_bug+0x4f/0x90
[ 4947.849421]  ? exc_invalid_op+0x1a/0x60
[ 4947.849422]  ? asm_exc_invalid_op+0x1a/0x20
[ 4947.849424]  ? __cfi_show_status+0x10/0x10
[ 4947.849425]  ? dev_attr_show+0x24/0x60
[ 4947.849426]  sysfs_kf_seq_show+0xa6/0x110
[ 4947.849433]  seq_read_iter+0x16c/0x4b0
[ 4947.849436]  vfs_read+0x272/0x2d0
[ 4947.849438]  ksys_read+0x72/0xe0
[ 4947.849439]  do_syscall_64+0x76/0xb0
[ 4947.849440]  ? do_user_addr_fault+0x252/0x650
[ 4947.849442]  ? exc_page_fault+0x7a/0x1b0
[ 4947.849443]  entry_SYSCALL_64_after_hwframe+0x72/0xdc</Note>
    </Notes>
    <CVE>CVE-2023-53550</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/i915: mark requests for GuC virtual engines to avoid use-after-free

References to i915_requests may be trapped by userspace inside a
sync_file or dmabuf (dma-resv) and held indefinitely across different
proceses. To counter-act the memory leaks, we try to not to keep
references from the request past their completion.
On the other side on fence release we need to know if rq-&gt;engine
is valid and points to hw engine (true for non-virtual requests).
To make it possible extra bit has been added to rq-&gt;execution_mask,
for marking virtual engines.

(cherry picked from commit 280410677af763f3871b93e794a199cfcf6fb580)</Note>
    </Notes>
    <CVE>CVE-2023-53552</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: hyperv: avoid struct memcpy overrun warning

A previous patch addressed the fortified memcpy warning for most
builds, but I still see this one with gcc-9:

In file included from include/linux/string.h:254,
                 from drivers/hid/hid-hyperv.c:8:
In function 'fortify_memcpy_chk',
    inlined from 'mousevsc_on_receive' at drivers/hid/hid-hyperv.c:272:3:
include/linux/fortify-string.h:583:4: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
  583 |    __write_overflow_field(p_size_field, size);
      |    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

My guess is that the WARN_ON() itself is what confuses gcc, so it no
longer sees that there is a correct range check. Rework the code in a
way that helps readability and avoids the warning.</Note>
    </Notes>
    <CVE>CVE-2023-53553</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ks7010: potential buffer overflow in ks_wlan_set_encode_ext()

The "exc-&gt;key_len" is a u16 that comes from the user.  If it's over
IW_ENCODING_TOKEN_MAX (64) that could lead to memory corruption.</Note>
    </Notes>
    <CVE>CVE-2023-53554</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/damon/core: initialize damo_filter-&gt;list from damos_new_filter()

damos_new_filter() is not initializing the list field of newly allocated
filter object.  However, DAMON sysfs interface and DAMON_RECLAIM are not
initializing it after calling damos_new_filter().  As a result, accessing
uninitialized memory is possible.  Actually, adding multiple DAMOS filters
via DAMON sysfs interface caused NULL pointer dereferencing.  Initialize
the field just after the allocation from damos_new_filter().</Note>
    </Notes>
    <CVE>CVE-2023-53555</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iavf: Fix use-after-free in free_netdev

We do netif_napi_add() for all allocated q_vectors[], but potentially
do netif_napi_del() for part of them, then kfree q_vectors and leave
invalid pointers at dev-&gt;napi_list.

Reproducer:

  [root@host ~]# cat repro.sh
  #!/bin/bash

  pf_dbsf="0000:41:00.0"
  vf0_dbsf="0000:41:02.0"
  g_pids=()

  function do_set_numvf()
  {
      echo 2 &gt;/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs
      sleep $((RANDOM%3+1))
      echo 0 &gt;/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs
      sleep $((RANDOM%3+1))
  }

  function do_set_channel()
  {
      local nic=$(ls -1 --indicator-style=none /sys/bus/pci/devices/${vf0_dbsf}/net/)
      [ -z "$nic" ] &amp;&amp; { sleep $((RANDOM%3)) ; return 1; }
      ifconfig $nic 192.168.18.5 netmask 255.255.255.0
      ifconfig $nic up
      ethtool -L $nic combined 1
      ethtool -L $nic combined 4
      sleep $((RANDOM%3))
  }

  function on_exit()
  {
      local pid
      for pid in "${g_pids[@]}"; do
          kill -0 "$pid" &amp;&gt;/dev/null &amp;&amp; kill "$pid" &amp;&gt;/dev/null
      done
      g_pids=()
  }

  trap "on_exit; exit" EXIT

  while :; do do_set_numvf ; done &amp;
  g_pids+=($!)
  while :; do do_set_channel ; done &amp;
  g_pids+=($!)

  wait

Result:

[ 4093.900222] ==================================================================
[ 4093.900230] BUG: KASAN: use-after-free in free_netdev+0x308/0x390
[ 4093.900232] Read of size 8 at addr ffff88b4dc145640 by task repro.sh/6699
[ 4093.900233]
[ 4093.900236] CPU: 10 PID: 6699 Comm: repro.sh Kdump: loaded Tainted: G           O     --------- -t - 4.18.0 #1
[ 4093.900238] Hardware name: Powerleader PR2008AL/H12DSi-N6, BIOS 2.0 04/09/2021
[ 4093.900239] Call Trace:
[ 4093.900244]  dump_stack+0x71/0xab
[ 4093.900249]  print_address_description+0x6b/0x290
[ 4093.900251]  ? free_netdev+0x308/0x390
[ 4093.900252]  kasan_report+0x14a/0x2b0
[ 4093.900254]  free_netdev+0x308/0x390
[ 4093.900261]  iavf_remove+0x825/0xd20 [iavf]
[ 4093.900265]  pci_device_remove+0xa8/0x1f0
[ 4093.900268]  device_release_driver_internal+0x1c6/0x460
[ 4093.900271]  pci_stop_bus_device+0x101/0x150
[ 4093.900273]  pci_stop_and_remove_bus_device+0xe/0x20
[ 4093.900275]  pci_iov_remove_virtfn+0x187/0x420
[ 4093.900277]  ? pci_iov_add_virtfn+0xe10/0xe10
[ 4093.900278]  ? pci_get_subsys+0x90/0x90
[ 4093.900280]  sriov_disable+0xed/0x3e0
[ 4093.900282]  ? bus_find_device+0x12d/0x1a0
[ 4093.900290]  i40e_free_vfs+0x754/0x1210 [i40e]
[ 4093.900298]  ? i40e_reset_all_vfs+0x880/0x880 [i40e]
[ 4093.900299]  ? pci_get_device+0x7c/0x90
[ 4093.900300]  ? pci_get_subsys+0x90/0x90
[ 4093.900306]  ? pci_vfs_assigned.part.7+0x144/0x210
[ 4093.900309]  ? __mutex_lock_slowpath+0x10/0x10
[ 4093.900315]  i40e_pci_sriov_configure+0x1fa/0x2e0 [i40e]
[ 4093.900318]  sriov_numvfs_store+0x214/0x290
[ 4093.900320]  ? sriov_totalvfs_show+0x30/0x30
[ 4093.900321]  ? __mutex_lock_slowpath+0x10/0x10
[ 4093.900323]  ? __check_object_size+0x15a/0x350
[ 4093.900326]  kernfs_fop_write+0x280/0x3f0
[ 4093.900329]  vfs_write+0x145/0x440
[ 4093.900330]  ksys_write+0xab/0x160
[ 4093.900332]  ? __ia32_sys_read+0xb0/0xb0
[ 4093.900334]  ? fput_many+0x1a/0x120
[ 4093.900335]  ? filp_close+0xf0/0x130
[ 4093.900338]  do_syscall_64+0xa0/0x370
[ 4093.900339]  ? page_fault+0x8/0x30
[ 4093.900341]  entry_SYSCALL_64_after_hwframe+0x65/0xca
[ 4093.900357] RIP: 0033:0x7f16ad4d22c0
[ 4093.900359] Code: 73 01 c3 48 8b 0d d8 cb 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 89 24 2d 00 00 75 10 b8 01 00 00 00 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 fe dd 01 00 48 89 04 24
[ 4093.900360] RSP: 002b:00007ffd6491b7f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 4093.900362] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f16ad4d22c0
[ 4093.900363] RDX: 0000000000000002 RSI: 0000000001a41408 RDI: 0000000000000001
[ 4093.900364] RBP: 0000000001a41408 R08: 00007f16ad7a1780 R09: 00007f16ae1f2700
[ 4093.9003
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53556</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fprobe: Release rethook after the ftrace_ops is unregistered

While running bpf selftests it's possible to get following fault:

  general protection fault, probably for non-canonical address \
  0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI
  ...
  Call Trace:
   &lt;TASK&gt;
   fprobe_handler+0xc1/0x270
   ? __pfx_bpf_testmod_init+0x10/0x10
   ? __pfx_bpf_testmod_init+0x10/0x10
   ? bpf_fentry_test1+0x5/0x10
   ? bpf_fentry_test1+0x5/0x10
   ? bpf_testmod_init+0x22/0x80
   ? do_one_initcall+0x63/0x2e0
   ? rcu_is_watching+0xd/0x40
   ? kmalloc_trace+0xaf/0xc0
   ? do_init_module+0x60/0x250
   ? __do_sys_finit_module+0xac/0x120
   ? do_syscall_64+0x37/0x90
   ? entry_SYSCALL_64_after_hwframe+0x72/0xdc
   &lt;/TASK&gt;

In unregister_fprobe function we can't release fp-&gt;rethook while it's
possible there are some of its users still running on another cpu.

Moving rethook_free call after fp-&gt;ops is unregistered with
unregister_ftrace_function call.</Note>
    </Notes>
    <CVE>CVE-2023-53557</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

rcu-tasks: Avoid pr_info() with spin lock in cblist_init_generic()

pr_info() is called with rtp-&gt;cbs_gbl_lock spin lock locked.  Because
pr_info() calls printk() that might sleep, this will result in BUG
like below:

[    0.206455] cblist_init_generic: Setting adjustable number of callback queues.
[    0.206463]
[    0.206464] =============================
[    0.206464] [ BUG: Invalid wait context ]
[    0.206465] 5.19.0-00428-g9de1f9c8ca51 #5 Not tainted
[    0.206466] -----------------------------
[    0.206466] swapper/0/1 is trying to lock:
[    0.206467] ffffffffa0167a58 (&amp;port_lock_key){....}-{3:3}, at: serial8250_console_write+0x327/0x4a0
[    0.206473] other info that might help us debug this:
[    0.206473] context-{5:5}
[    0.206474] 3 locks held by swapper/0/1:
[    0.206474]  #0: ffffffff9eb597e0 (rcu_tasks.cbs_gbl_lock){....}-{2:2}, at: cblist_init_generic.constprop.0+0x14/0x1f0
[    0.206478]  #1: ffffffff9eb579c0 (console_lock){+.+.}-{0:0}, at: _printk+0x63/0x7e
[    0.206482]  #2: ffffffff9ea77780 (console_owner){....}-{0:0}, at: console_emit_next_record.constprop.0+0x111/0x330
[    0.206485] stack backtrace:
[    0.206486] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-00428-g9de1f9c8ca51 #5
[    0.206488] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014
[    0.206489] Call Trace:
[    0.206490]  &lt;TASK&gt;
[    0.206491]  dump_stack_lvl+0x6a/0x9f
[    0.206493]  __lock_acquire.cold+0x2d7/0x2fe
[    0.206496]  ? stack_trace_save+0x46/0x70
[    0.206497]  lock_acquire+0xd1/0x2f0
[    0.206499]  ? serial8250_console_write+0x327/0x4a0
[    0.206500]  ? __lock_acquire+0x5c7/0x2720
[    0.206502]  _raw_spin_lock_irqsave+0x3d/0x90
[    0.206504]  ? serial8250_console_write+0x327/0x4a0
[    0.206506]  serial8250_console_write+0x327/0x4a0
[    0.206508]  console_emit_next_record.constprop.0+0x180/0x330
[    0.206511]  console_unlock+0xf7/0x1f0
[    0.206512]  vprintk_emit+0xf7/0x330
[    0.206514]  _printk+0x63/0x7e
[    0.206516]  cblist_init_generic.constprop.0.cold+0x24/0x32
[    0.206518]  rcu_init_tasks_generic+0x5/0xd9
[    0.206522]  kernel_init_freeable+0x15b/0x2a2
[    0.206523]  ? rest_init+0x160/0x160
[    0.206526]  kernel_init+0x11/0x120
[    0.206527]  ret_from_fork+0x1f/0x30
[    0.206530]  &lt;/TASK&gt;
[    0.207018] cblist_init_generic: Setting shift to 1 and lim to 1.

This patch moves pr_info() so that it is called without
rtp-&gt;cbs_gbl_lock locked.</Note>
    </Notes>
    <CVE>CVE-2023-53558</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ip_vti: fix potential slab-use-after-free in decode_session6

When ip_vti device is set to the qdisc of the sfb type, the cb field
of the sent skb may be modified during enqueuing. Then,
slab-use-after-free may occur when ip_vti device sends IPv6 packets.
As commit f855691975bb ("xfrm6: Fix the nexthdr offset in
_decode_session6.") showed, xfrm_decode_session was originally intended
only for the receive path. IP6CB(skb)-&gt;nhoff is not set during
transmission. Therefore, set the cb field in the skb to 0 before
sending packets.</Note>
    </Notes>
    <CVE>CVE-2023-53559</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/histograms: Add histograms to hist_vars if they have referenced variables

Hist triggers can have referenced variables without having direct
variables fields. This can be the case if referenced variables are added
for trigger actions. In this case the newly added references will not
have field variables. Not taking such referenced variables into
consideration can result in a bug where it would be possible to remove
hist trigger with variables being refenced. This will result in a bug
that is easily reproducable like so

$ cd /sys/kernel/tracing
$ echo 'synthetic_sys_enter char[] comm; long id' &gt;&gt; synthetic_events
$ echo 'hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname' &gt;&gt; events/raw_syscalls/sys_enter/trigger
$ echo 'hist:keys=common_pid.execname,id.syscall:onmatch(raw_syscalls.sys_enter).synthetic_sys_enter($comm, id)' &gt;&gt; events/raw_syscalls/sys_enter/trigger
$ echo '!hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname' &gt;&gt; events/raw_syscalls/sys_enter/trigger

[  100.263533] ==================================================================
[  100.264634] BUG: KASAN: slab-use-after-free in resolve_var_refs+0xc7/0x180
[  100.265520] Read of size 8 at addr ffff88810375d0f0 by task bash/439
[  100.266320]
[  100.266533] CPU: 2 PID: 439 Comm: bash Not tainted 6.5.0-rc1 #4
[  100.267277] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-20220807_005459-localhost 04/01/2014
[  100.268561] Call Trace:
[  100.268902]  &lt;TASK&gt;
[  100.269189]  dump_stack_lvl+0x4c/0x70
[  100.269680]  print_report+0xc5/0x600
[  100.270165]  ? resolve_var_refs+0xc7/0x180
[  100.270697]  ? kasan_complete_mode_report_info+0x80/0x1f0
[  100.271389]  ? resolve_var_refs+0xc7/0x180
[  100.271913]  kasan_report+0xbd/0x100
[  100.272380]  ? resolve_var_refs+0xc7/0x180
[  100.272920]  __asan_load8+0x71/0xa0
[  100.273377]  resolve_var_refs+0xc7/0x180
[  100.273888]  event_hist_trigger+0x749/0x860
[  100.274505]  ? kasan_save_stack+0x2a/0x50
[  100.275024]  ? kasan_set_track+0x29/0x40
[  100.275536]  ? __pfx_event_hist_trigger+0x10/0x10
[  100.276138]  ? ksys_write+0xd1/0x170
[  100.276607]  ? do_syscall_64+0x3c/0x90
[  100.277099]  ? entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[  100.277771]  ? destroy_hist_data+0x446/0x470
[  100.278324]  ? event_hist_trigger_parse+0xa6c/0x3860
[  100.278962]  ? __pfx_event_hist_trigger_parse+0x10/0x10
[  100.279627]  ? __kasan_check_write+0x18/0x20
[  100.280177]  ? mutex_unlock+0x85/0xd0
[  100.280660]  ? __pfx_mutex_unlock+0x10/0x10
[  100.281200]  ? kfree+0x7b/0x120
[  100.281619]  ? ____kasan_slab_free+0x15d/0x1d0
[  100.282197]  ? event_trigger_write+0xac/0x100
[  100.282764]  ? __kasan_slab_free+0x16/0x20
[  100.283293]  ? __kmem_cache_free+0x153/0x2f0
[  100.283844]  ? sched_mm_cid_remote_clear+0xb1/0x250
[  100.284550]  ? __pfx_sched_mm_cid_remote_clear+0x10/0x10
[  100.285221]  ? event_trigger_write+0xbc/0x100
[  100.285781]  ? __kasan_check_read+0x15/0x20
[  100.286321]  ? __bitmap_weight+0x66/0xa0
[  100.286833]  ? _find_next_bit+0x46/0xe0
[  100.287334]  ? task_mm_cid_work+0x37f/0x450
[  100.287872]  event_triggers_call+0x84/0x150
[  100.288408]  trace_event_buffer_commit+0x339/0x430
[  100.289073]  ? ring_buffer_event_data+0x3f/0x60
[  100.292189]  trace_event_raw_event_sys_enter+0x8b/0xe0
[  100.295434]  syscall_trace_enter.constprop.0+0x18f/0x1b0
[  100.298653]  syscall_enter_from_user_mode+0x32/0x40
[  100.301808]  do_syscall_64+0x1a/0x90
[  100.304748]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[  100.307775] RIP: 0033:0x7f686c75c1cb
[  100.310617] Code: 73 01 c3 48 8b 0d 65 3c 10 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 21 00 00 00 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 35 3c 10 00 f7 d8 64 89 01 48
[  100.317847] RSP: 002b:00007ffc60137a38 EFLAGS: 00000246 ORIG_RAX: 0000000000000021
[  100.321200] RA
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53560</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cpufreq: amd-pstate-ut: Fix kernel panic when loading the driver

After loading the amd-pstate-ut driver, amd_pstate_ut_check_perf()
and amd_pstate_ut_check_freq() use cpufreq_cpu_get() to get the policy
of the CPU and mark it as busy.

In these functions, cpufreq_cpu_put() should be used to release the
policy, but it is not, so any other entity trying to access the policy
is blocked indefinitely.

One such scenario is when amd_pstate mode is changed, leading to the
following splat:

[ 1332.103727] INFO: task bash:2929 blocked for more than 120 seconds.
[ 1332.110001]       Not tainted 6.5.0-rc2-amd-pstate-ut #5
[ 1332.115315] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1332.123140] task:bash            state:D stack:0     pid:2929  ppid:2873   flags:0x00004006
[ 1332.123143] Call Trace:
[ 1332.123145]  &lt;TASK&gt;
[ 1332.123148]  __schedule+0x3c1/0x16a0
[ 1332.123154]  ? _raw_read_lock_irqsave+0x2d/0x70
[ 1332.123157]  schedule+0x6f/0x110
[ 1332.123160]  schedule_timeout+0x14f/0x160
[ 1332.123162]  ? preempt_count_add+0x86/0xd0
[ 1332.123165]  __wait_for_common+0x92/0x190
[ 1332.123168]  ? __pfx_schedule_timeout+0x10/0x10
[ 1332.123170]  wait_for_completion+0x28/0x30
[ 1332.123173]  cpufreq_policy_put_kobj+0x4d/0x90
[ 1332.123177]  cpufreq_policy_free+0x157/0x1d0
[ 1332.123178]  ? preempt_count_add+0x58/0xd0
[ 1332.123180]  cpufreq_remove_dev+0xb6/0x100
[ 1332.123182]  subsys_interface_unregister+0x114/0x120
[ 1332.123185]  ? preempt_count_add+0x58/0xd0
[ 1332.123187]  ? __pfx_amd_pstate_change_driver_mode+0x10/0x10
[ 1332.123190]  cpufreq_unregister_driver+0x3b/0xd0
[ 1332.123192]  amd_pstate_change_driver_mode+0x1e/0x50
[ 1332.123194]  store_status+0xe9/0x180
[ 1332.123197]  dev_attr_store+0x1b/0x30
[ 1332.123199]  sysfs_kf_write+0x42/0x50
[ 1332.123202]  kernfs_fop_write_iter+0x143/0x1d0
[ 1332.123204]  vfs_write+0x2df/0x400
[ 1332.123208]  ksys_write+0x6b/0xf0
[ 1332.123210]  __x64_sys_write+0x1d/0x30
[ 1332.123213]  do_syscall_64+0x60/0x90
[ 1332.123216]  ? fpregs_assert_state_consistent+0x2e/0x50
[ 1332.123219]  ? exit_to_user_mode_prepare+0x49/0x1a0
[ 1332.123223]  ? irqentry_exit_to_user_mode+0xd/0x20
[ 1332.123225]  ? irqentry_exit+0x3f/0x50
[ 1332.123226]  ? exc_page_fault+0x8e/0x190
[ 1332.123228]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[ 1332.123232] RIP: 0033:0x7fa74c514a37
[ 1332.123234] RSP: 002b:00007ffe31dd0788 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 1332.123238] RAX: ffffffffffffffda RBX: 0000000000000008 RCX: 00007fa74c514a37
[ 1332.123239] RDX: 0000000000000008 RSI: 000055e27c447aa0 RDI: 0000000000000001
[ 1332.123241] RBP: 000055e27c447aa0 R08: 00007fa74c5d1460 R09: 000000007fffffff
[ 1332.123242] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000008
[ 1332.123244] R13: 00007fa74c61a780 R14: 00007fa74c616600 R15: 00007fa74c615a00
[ 1332.123247]  &lt;/TASK&gt;

Fix this by calling cpufreq_cpu_put() wherever necessary.

[ rjw: Subject and changelog edits ]</Note>
    </Notes>
    <CVE>CVE-2023-53563</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/zcrypt: don't leak memory if dev_set_name() fails

When dev_set_name() fails, zcdn_create() doesn't free the newly
allocated resources. Do it.</Note>
    </Notes>
    <CVE>CVE-2023-53568</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: nl80211: fix integer overflow in nl80211_parse_mbssid_elems()

nl80211_parse_mbssid_elems() uses a u8 variable num_elems to count the
number of MBSSID elements in the nested netlink attribute attrs, which can
lead to an integer overflow if a user of the nl80211 interface specifies
256 or more elements in the corresponding attribute in userspace. The
integer overflow can lead to a heap buffer overflow as num_elems determines
the size of the trailing array in elems, and this array is thereafter
written to for each element in attrs.

Note that this vulnerability only affects devices with the
wiphy-&gt;mbssid_max_interfaces member set for the wireless physical device
struct in the device driver, and can only be triggered by a process with
CAP_NET_ADMIN capabilities.

Fix this by checking for a maximum of 255 elements in attrs.</Note>
    </Notes>
    <CVE>CVE-2023-53570</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: imx: scu: use _safe list iterator to avoid a use after free

This loop is freeing "clk" so it needs to use list_for_each_entry_safe().
Otherwise it dereferences a freed variable to get the next item on the
loop.</Note>
    </Notes>
    <CVE>CVE-2023-53572</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: rtw88: delete timer and free skb queue when unloading

Fix possible crash and memory leak on driver unload by deleting
TX purge timer and freeing C2H queue in 'rtw_core_deinit()',
shrink critical section in the latter by freeing COEX queue
out of TX report lock scope.</Note>
    </Notes>
    <CVE>CVE-2023-53574</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: fix potential array out of bounds access

Account for IWL_SEC_WEP_KEY_OFFSET when needed while verifying
key_len size in iwl_mvm_sec_key_add().</Note>
    </Notes>
    <CVE>CVE-2023-53575</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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, cpumap: Make sure kthread is running before map update returns

The following warning was reported when running stress-mode enabled
xdp_redirect_cpu with some RT threads:

  ------------[ cut here ]------------
  WARNING: CPU: 4 PID: 65 at kernel/bpf/cpumap.c:135
  CPU: 4 PID: 65 Comm: kworker/4:1 Not tainted 6.5.0-rc2+ #1
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
  Workqueue: events cpu_map_kthread_stop
  RIP: 0010:put_cpu_map_entry+0xda/0x220
  ......
  Call Trace:
   &lt;TASK&gt;
   ? show_regs+0x65/0x70
   ? __warn+0xa5/0x240
   ......
   ? put_cpu_map_entry+0xda/0x220
   cpu_map_kthread_stop+0x41/0x60
   process_one_work+0x6b0/0xb80
   worker_thread+0x96/0x720
   kthread+0x1a5/0x1f0
   ret_from_fork+0x3a/0x70
   ret_from_fork_asm+0x1b/0x30
   &lt;/TASK&gt;

The root cause is the same as commit 436901649731 ("bpf: cpumap: Fix memory
leak in cpu_map_update_elem"). The kthread is stopped prematurely by
kthread_stop() in cpu_map_kthread_stop(), and kthread() doesn't call
cpu_map_kthread_run() at all but XDP program has already queued some
frames or skbs into ptr_ring. So when __cpu_map_ring_cleanup() checks
the ptr_ring, it will find it was not emptied and report a warning.

An alternative fix is to use __cpu_map_ring_cleanup() to drop these
pending frames or skbs when kthread_stop() returns -EINTR, but it may
confuse the user, because these frames or skbs have been handled
correctly by XDP program. So instead of dropping these frames or skbs,
just make sure the per-cpu kthread is running before
__cpu_map_entry_alloc() returns.

After apply the fix, the error handle for kthread_stop() will be
unnecessary because it will always return 0, so just remove it.</Note>
    </Notes>
    <CVE>CVE-2023-53577</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mvebu: fix irq domain leak

Uwe Kleine-König pointed out we still have one resource leak in the mvebu
driver triggered on driver detach. Let's address it with a custom devm
action.</Note>
    </Notes>
    <CVE>CVE-2023-53579</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Help prevent panic during UVC unconfigure

Avichal Rakesh reported a kernel panic that occurred when the UVC
gadget driver was removed from a gadget's configuration.  The panic
involves a somewhat complicated interaction between the kernel driver
and a userspace component (as described in the Link tag below), but
the analysis did make one thing clear: The Gadget core should
accomodate gadget drivers calling usb_gadget_deactivate() as part of
their unbind procedure.

Currently this doesn't work.  gadget_unbind_driver() calls
driver-&gt;unbind() while holding the udc-&gt;connect_lock mutex, and
usb_gadget_deactivate() attempts to acquire that mutex, which will
result in a deadlock.

The simple fix is for gadget_unbind_driver() to release the mutex when
invoking the -&gt;unbind() callback.  There is no particular reason for
it to be holding the mutex at that time, and the mutex isn't held
while the -&gt;bind() callback is invoked.  So we'll drop the mutex
before performing the unbind callback and reacquire it afterward.

We'll also add a couple of comments to usb_gadget_activate() and
usb_gadget_deactivate().  Because they run in process context they
must not be called from a gadget driver's -&gt;disconnect() callback,
which (according to the kerneldoc for struct usb_gadget_driver in
include/linux/usb/gadget.h) may run in interrupt context.  This may
help prevent similar bugs from arising in the future.</Note>
    </Notes>
    <CVE>CVE-2023-53580</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Check for NOT_READY flag state after locking

Currently the check for NOT_READY flag is performed before obtaining the
necessary lock. This opens a possibility for race condition when the flow
is concurrently removed from unready_flows list by the workqueue task,
which causes a double-removal from the list and a crash[0]. Fix the issue
by moving the flag check inside the section protected by
uplink_priv-&gt;unready_flows_lock mutex.

[0]:
[44376.389654] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP
[44376.391665] CPU: 7 PID: 59123 Comm: tc Not tainted 6.4.0-rc4+ #1
[44376.392984] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
[44376.395342] RIP: 0010:mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core]
[44376.396857] Code: 00 48 8b b8 68 ce 02 00 e8 8a 4d 02 00 4c 8d a8 a8 01 00 00 4c 89 ef e8 8b 79 88 e1 48 8b 83 98 06 00 00 48 8b 93 90 06 00 00 &lt;48&gt; 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 90 06
[44376.399167] RSP: 0018:ffff88812cc97570 EFLAGS: 00010246
[44376.399680] RAX: dead000000000122 RBX: ffff8881088e3800 RCX: ffff8881881bac00
[44376.400337] RDX: dead000000000100 RSI: ffff88812cc97500 RDI: ffff8881242f71b0
[44376.401001] RBP: ffff88811cbb0940 R08: 0000000000000400 R09: 0000000000000001
[44376.401663] R10: 0000000000000001 R11: 0000000000000000 R12: ffff88812c944000
[44376.402342] R13: ffff8881242f71a8 R14: ffff8881222b4000 R15: 0000000000000000
[44376.402999] FS:  00007f0451104800(0000) GS:ffff88852cb80000(0000) knlGS:0000000000000000
[44376.403787] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[44376.404343] CR2: 0000000000489108 CR3: 0000000123a79003 CR4: 0000000000370ea0
[44376.405004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[44376.405665] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[44376.406339] Call Trace:
[44376.406651]  &lt;TASK&gt;
[44376.406939]  ? die_addr+0x33/0x90
[44376.407311]  ? exc_general_protection+0x192/0x390
[44376.407795]  ? asm_exc_general_protection+0x22/0x30
[44376.408292]  ? mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core]
[44376.408876]  __mlx5e_tc_del_fdb_peer_flow+0xbc/0xe0 [mlx5_core]
[44376.409482]  mlx5e_tc_del_flow+0x42/0x210 [mlx5_core]
[44376.410055]  mlx5e_flow_put+0x25/0x50 [mlx5_core]
[44376.410529]  mlx5e_delete_flower+0x24b/0x350 [mlx5_core]
[44376.411043]  tc_setup_cb_reoffload+0x22/0x80
[44376.411462]  fl_reoffload+0x261/0x2f0 [cls_flower]
[44376.411907]  ? mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core]
[44376.412481]  ? mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core]
[44376.413044]  tcf_block_playback_offloads+0x76/0x170
[44376.413497]  tcf_block_unbind+0x7b/0xd0
[44376.413881]  tcf_block_setup+0x17d/0x1c0
[44376.414269]  tcf_block_offload_cmd.isra.0+0xf1/0x130
[44376.414725]  tcf_block_offload_unbind+0x43/0x70
[44376.415153]  __tcf_block_put+0x82/0x150
[44376.415532]  ingress_destroy+0x22/0x30 [sch_ingress]
[44376.415986]  qdisc_destroy+0x3b/0xd0
[44376.416343]  qdisc_graft+0x4d0/0x620
[44376.416706]  tc_get_qdisc+0x1c9/0x3b0
[44376.417074]  rtnetlink_rcv_msg+0x29c/0x390
[44376.419978]  ? rep_movs_alternative+0x3a/0xa0
[44376.420399]  ? rtnl_calcit.isra.0+0x120/0x120
[44376.420813]  netlink_rcv_skb+0x54/0x100
[44376.421192]  netlink_unicast+0x1f6/0x2c0
[44376.421573]  netlink_sendmsg+0x232/0x4a0
[44376.421980]  sock_sendmsg+0x38/0x60
[44376.422328]  ____sys_sendmsg+0x1d0/0x1e0
[44376.422709]  ? copy_msghdr_from_user+0x6d/0xa0
[44376.423127]  ___sys_sendmsg+0x80/0xc0
[44376.423495]  ? ___sys_recvmsg+0x8b/0xc0
[44376.423869]  __sys_sendmsg+0x51/0x90
[44376.424226]  do_syscall_64+0x3d/0x90
[44376.424587]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
[44376.425046] RIP: 0033:0x7f045134f887
[44376.425403] Code: 0a 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53581</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: RISC-V: Remove PERF_HES_STOPPED flag checking in riscv_pmu_start()

Since commit 096b52fd2bb4 ("perf: RISC-V: throttle perf events") the
perf_sample_event_took() function was added to report time spent in
overflow interrupts. If the interrupt takes too long, the perf framework
will lower the sysctl_perf_event_sample_rate and max_samples_per_tick.
When hwc-&gt;interrupts is larger than max_samples_per_tick, the
hwc-&gt;interrupts will be set to MAX_INTERRUPTS, and events will be
throttled within the __perf_event_account_interrupt() function.

However, the RISC-V PMU driver doesn't call riscv_pmu_stop() to update the
PERF_HES_STOPPED flag after perf_event_overflow() in pmu_sbi_ovf_handler()
function to avoid throttling. When the perf framework unthrottled the event
in the timer interrupt handler, it triggers riscv_pmu_start() function
and causes a WARN_ON_ONCE() warning, as shown below:

 ------------[ cut here ]------------
 WARNING: CPU: 0 PID: 240 at drivers/perf/riscv_pmu.c:184 riscv_pmu_start+0x7c/0x8e
 Modules linked in:
 CPU: 0 PID: 240 Comm: ls Not tainted 6.4-rc4-g19d0788e9ef2 #1
 Hardware name: SiFive (DT)
 epc : riscv_pmu_start+0x7c/0x8e
  ra : riscv_pmu_start+0x28/0x8e
 epc : ffffffff80aef864 ra : ffffffff80aef810 sp : ffff8f80004db6f0
  gp : ffffffff81c83750 tp : ffffaf80069f9bc0 t0 : ffff8f80004db6c0
  t1 : 0000000000000000 t2 : 000000000000001f s0 : ffff8f80004db720
  s1 : ffffaf8008ca1068 a0 : 0000ffffffffffff a1 : 0000000000000000
  a2 : 0000000000000001 a3 : 0000000000000870 a4 : 0000000000000000
  a5 : 0000000000000000 a6 : 0000000000000840 a7 : 0000000000000030
  s2 : 0000000000000000 s3 : ffffaf8005165800 s4 : ffffaf800424da00
  s5 : ffffffffffffffff s6 : ffffffff81cc7590 s7 : 0000000000000000
  s8 : 0000000000000006 s9 : 0000000000000001 s10: ffffaf807efbc340
  s11: ffffaf807efbbf00 t3 : ffffaf8006a16028 t4 : 00000000dbfbb796
  t5 : 0000000700000000 t6 : ffffaf8005269870
 status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003
 [&lt;ffffffff80aef864&gt;] riscv_pmu_start+0x7c/0x8e
 [&lt;ffffffff80185b56&gt;] perf_adjust_freq_unthr_context+0x15e/0x174
 [&lt;ffffffff80188642&gt;] perf_event_task_tick+0x88/0x9c
 [&lt;ffffffff800626a8&gt;] scheduler_tick+0xfe/0x27c
 [&lt;ffffffff800b5640&gt;] update_process_times+0x9a/0xba
 [&lt;ffffffff800c5bd4&gt;] tick_sched_handle+0x32/0x66
 [&lt;ffffffff800c5e0c&gt;] tick_sched_timer+0x64/0xb0
 [&lt;ffffffff800b5e50&gt;] __hrtimer_run_queues+0x156/0x2f4
 [&lt;ffffffff800b6bdc&gt;] hrtimer_interrupt+0xe2/0x1fe
 [&lt;ffffffff80acc9e8&gt;] riscv_timer_interrupt+0x38/0x42
 [&lt;ffffffff80090a16&gt;] handle_percpu_devid_irq+0x90/0x1d2
 [&lt;ffffffff8008a9f4&gt;] generic_handle_domain_irq+0x28/0x36

After referring other PMU drivers like Arm, Loongarch, Csky, and Mips,
they don't call *_pmu_stop() to update with PERF_HES_STOPPED flag
after perf_event_overflow() function nor do they add PERF_HES_STOPPED
flag checking in *_pmu_start() which don't cause this warning.

Thus, it's recommended to remove this unnecessary check in
riscv_pmu_start() function to prevent this warning.</Note>
    </Notes>
    <CVE>CVE-2023-53583</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: reject unhashed sockets in bpf_sk_assign

The semantics for bpf_sk_assign are as follows:

    sk = some_lookup_func()
    bpf_sk_assign(skb, sk)
    bpf_sk_release(sk)

That is, the sk is not consumed by bpf_sk_assign. The function
therefore needs to make sure that sk lives long enough to be
consumed from __inet_lookup_skb. The path through the stack for a
TCPv4 packet is roughly:

  netif_receive_skb_core: takes RCU read lock
    __netif_receive_skb_core:
      sch_handle_ingress:
        tcf_classify:
          bpf_sk_assign()
      deliver_ptype_list_skb:
        deliver_skb:
          ip_packet_type-&gt;func == ip_rcv:
            ip_rcv_core:
            ip_rcv_finish_core:
              dst_input:
                ip_local_deliver:
                  ip_local_deliver_finish:
                    ip_protocol_deliver_rcu:
                      tcp_v4_rcv:
                        __inet_lookup_skb:
                          skb_steal_sock

The existing helper takes advantage of the fact that everything
happens in the same RCU critical section: for sockets with
SOCK_RCU_FREE set bpf_sk_assign never takes a reference.
skb_steal_sock then checks SOCK_RCU_FREE again and does sock_put
if necessary.

This approach assumes that SOCK_RCU_FREE is never set on a sk
between bpf_sk_assign and skb_steal_sock, but this invariant is
violated by unhashed UDP sockets. A new UDP socket is created
in TCP_CLOSE state but without SOCK_RCU_FREE set. That flag is only
added in udp_lib_get_port() which happens when a socket is bound.

When bpf_sk_assign was added it wasn't possible to access unhashed
UDP sockets from BPF, so this wasn't a problem. This changed
in commit 0c48eefae712 ("sock_map: Lift socket state restriction
for datagram sockets"), but the helper wasn't adjusted accordingly.
The following sequence of events will therefore lead to a refcount
leak:

1. Add socket(AF_INET, SOCK_DGRAM) to a sockmap.
2. Pull socket out of sockmap and bpf_sk_assign it. Since
   SOCK_RCU_FREE is not set we increment the refcount.
3. bind() or connect() the socket, setting SOCK_RCU_FREE.
4. skb_steal_sock will now set refcounted = false due to
   SOCK_RCU_FREE.
5. tcp_v4_rcv() skips sock_put().

Fix the problem by rejecting unhashed sockets in bpf_sk_assign().
This matches the behaviour of __inet_lookup_skb which is ultimately
the goal of bpf_sk_assign().</Note>
    </Notes>
    <CVE>CVE-2023-53585</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: check for station first in client probe

When probing a client, first check if we have it, and then
check for the channel context, otherwise you can trigger
the warning there easily by probing when the AP isn't even
started yet. Since a client existing means the AP is also
operating, we can then keep the warning.

Also simplify the moved code a bit.</Note>
    </Notes>
    <CVE>CVE-2023-53588</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Release folio lock on fscache read hit.

Under the current code, when cifs_readpage_worker is called, the call
contract is that the callee should unlock the page. This is documented
in the read_folio section of Documentation/filesystems/vfs.rst as:

&gt; The filesystem should unlock the folio once the read has completed,
&gt; whether it was successful or not.

Without this change, when fscache is in use and cache hit occurs during
a read, the page lock is leaked, producing the following stack on
subsequent reads (via mmap) to the page:

$ cat /proc/3890/task/12864/stack
[&lt;0&gt;] folio_wait_bit_common+0x124/0x350
[&lt;0&gt;] filemap_read_folio+0xad/0xf0
[&lt;0&gt;] filemap_fault+0x8b1/0xab0
[&lt;0&gt;] __do_fault+0x39/0x150
[&lt;0&gt;] do_fault+0x25c/0x3e0
[&lt;0&gt;] __handle_mm_fault+0x6ca/0xc70
[&lt;0&gt;] handle_mm_fault+0xe9/0x350
[&lt;0&gt;] do_user_addr_fault+0x225/0x6c0
[&lt;0&gt;] exc_page_fault+0x84/0x1b0
[&lt;0&gt;] asm_exc_page_fault+0x27/0x30

This requires a reboot to resolve; it is a deadlock.

Note however that the call to cifs_readpage_from_fscache does mark the
page clean, but does not free the folio lock. This happens in
__cifs_readpage_from_fscache on success. Releasing the lock at that
point however is not appropriate as cifs_readahead also calls
cifs_readpage_from_fscache and *does* unconditionally release the lock
after its return. This change therefore effectively makes
cifs_readpage_worker work like cifs_readahead.</Note>
    </Notes>
    <CVE>CVE-2023-53593</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: base: Free devm resources when unregistering a device

In the current code, devres_release_all() only gets called if the device
has a bus and has been probed.

This leads to issues when using bus-less or driver-less devices where
the device might never get freed if a managed resource holds a reference
to the device. This is happening in the DRM framework for example.

We should thus call devres_release_all() in the device_del() function to
make sure that the device-managed actions are properly executed when the
device is unregistered, even if it has neither a bus nor a driver.

This is effectively the same change than commit 2f8d16a996da ("devres:
release resources on device_del()") that got reverted by commit
a525a3ddeaca ("driver core: free devres in device_release") over
memory leaks concerns.

This patch effectively combines the two commits mentioned above to
release the resources both on device_del() and device_release() and get
the best of both worlds.</Note>
    </Notes>
    <CVE>CVE-2023-53596</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 mid leak during reconnection after timeout threshold

When the number of responses with status of STATUS_IO_TIMEOUT
exceeds a specified threshold (NUM_STATUS_IO_TIMEOUT), we reconnect
the connection. But we do not return the mid, or the credits
returned for the mid, or reduce the number of in-flight requests.

This bug could result in the server-&gt;in_flight count to go bad,
and also cause a leak in the mids.

This change moves the check to a few lines below where the
response is decrypted, even of the response is read from the
transform header. This way, the code for returning the mids
can be reused.

Also, the cifs_reconnect was reconnecting just the transport
connection before. In case of multi-channel, this may not be
what we want to do after several timeouts. Changed that to
reconnect the session and the tree too.

Also renamed NUM_STATUS_IO_TIMEOUT to a more appropriate name
MAX_STATUS_IO_TIMEOUT.</Note>
    </Notes>
    <CVE>CVE-2023-53597</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: af_alg - Fix missing initialisation affecting gcm-aes-s390

Fix af_alg_alloc_areq() to initialise areq-&gt;first_rsgl.sgl.sgt.sgl to point
to the scatterlist array in areq-&gt;first_rsgl.sgl.sgl.

Without this, the gcm-aes-s390 driver will oops when it tries to do
gcm_walk_start() on req-&gt;dst because req-&gt;dst is set to the value of
areq-&gt;first_rsgl.sgl.sgl by _aead_recvmsg() calling
aead_request_set_crypt().

The problem comes if an empty ciphertext is passed: the loop in
af_alg_get_rsgl() just passes straight out and doesn't set areq-&gt;first_rsgl
up.

This isn't a problem on x86_64 using gcmaes_crypt_by_sg() because, as far
as I can tell, that ignores req-&gt;dst and only uses req-&gt;src[*].

[*] Is this a bug in aesni-intel_glue.c?

The s390x oops looks something like:

 Unable to handle kernel pointer dereference in virtual kernel address space
 Failing address: 0000000a00000000 TEID: 0000000a00000803
 Fault in home space mode while using kernel ASCE.
 AS:00000000a43a0007 R3:0000000000000024
 Oops: 003b ilc:2 [#1] SMP
 ...
 Call Trace:
  [&lt;000003ff7fc3d47e&gt;] gcm_walk_start+0x16/0x28 [aes_s390]
  [&lt;00000000a2a342f2&gt;] crypto_aead_decrypt+0x9a/0xb8
  [&lt;00000000a2a60888&gt;] aead_recvmsg+0x478/0x698
  [&lt;00000000a2e519a0&gt;] sock_recvmsg+0x70/0xb0
  [&lt;00000000a2e51a56&gt;] sock_read_iter+0x76/0xa0
  [&lt;00000000a273e066&gt;] vfs_read+0x26e/0x2a8
  [&lt;00000000a273e8c4&gt;] ksys_read+0xbc/0x100
  [&lt;00000000a311d808&gt;] __do_syscall+0x1d0/0x1f8
  [&lt;00000000a312ff30&gt;] system_call+0x70/0x98
 Last Breaking-Event-Address:
  [&lt;000003ff7fc3e6b4&gt;] gcm_aes_crypt+0x104/0xa68 [aes_s390]</Note>
    </Notes>
    <CVE>CVE-2023-53599</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tunnels: fix kasan splat when generating ipv4 pmtu error

If we try to emit an icmp error in response to a nonliner skb, we get

BUG: KASAN: slab-out-of-bounds in ip_compute_csum+0x134/0x220
Read of size 4 at addr ffff88811c50db00 by task iperf3/1691
CPU: 2 PID: 1691 Comm: iperf3 Not tainted 6.5.0-rc3+ #309
[..]
 kasan_report+0x105/0x140
 ip_compute_csum+0x134/0x220
 iptunnel_pmtud_build_icmp+0x554/0x1020
 skb_tunnel_check_pmtu+0x513/0xb80
 vxlan_xmit_one+0x139e/0x2ef0
 vxlan_xmit+0x1867/0x2760
 dev_hard_start_xmit+0x1ee/0x4f0
 br_dev_queue_push_xmit+0x4d1/0x660
 [..]

ip_compute_csum() cannot deal with nonlinear skbs, so avoid it.
After this change, splat is gone and iperf3 is no longer stuck.</Note>
    </Notes>
    <CVE>CVE-2023-53600</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: do not assume skb mac_header is set

Drivers must not assume in their ndo_start_xmit() that
skbs have their mac_header set. skb-&gt;data is all what is needed.

bonding seems to be one of the last offender as caught by syzbot:

WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 skb_mac_offset include/linux/skbuff.h:2913 [inline]
WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_xmit_hash drivers/net/bonding/bond_main.c:4170 [inline]
WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5149 [inline]
WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_3ad_xor_xmit drivers/net/bonding/bond_main.c:5186 [inline]
WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 __bond_start_xmit drivers/net/bonding/bond_main.c:5442 [inline]
WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_start_xmit+0x14ab/0x19d0 drivers/net/bonding/bond_main.c:5470
Modules linked in:
CPU: 1 PID: 12155 Comm: syz-executor.3 Not tainted 6.1.30-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023
RIP: 0010:skb_mac_header include/linux/skbuff.h:2907 [inline]
RIP: 0010:skb_mac_offset include/linux/skbuff.h:2913 [inline]
RIP: 0010:bond_xmit_hash drivers/net/bonding/bond_main.c:4170 [inline]
RIP: 0010:bond_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5149 [inline]
RIP: 0010:bond_3ad_xor_xmit drivers/net/bonding/bond_main.c:5186 [inline]
RIP: 0010:__bond_start_xmit drivers/net/bonding/bond_main.c:5442 [inline]
RIP: 0010:bond_start_xmit+0x14ab/0x19d0 drivers/net/bonding/bond_main.c:5470
Code: 8b 7c 24 30 e8 76 dd 1a 01 48 85 c0 74 0d 48 89 c3 e8 29 67 2e fe e9 15 ef ff ff e8 1f 67 2e fe e9 10 ef ff ff e8 15 67 2e fe &lt;0f&gt; 0b e9 45 f8 ff ff e8 09 67 2e fe e9 dc fa ff ff e8 ff 66 2e fe
RSP: 0018:ffffc90002fff6e0 EFLAGS: 00010283
RAX: ffffffff835874db RBX: 000000000000ffff RCX: 0000000000040000
RDX: ffffc90004dcf000 RSI: 00000000000000b5 RDI: 00000000000000b6
RBP: ffffc90002fff8b8 R08: ffffffff83586d16 R09: ffffffff83586584
R10: 0000000000000007 R11: ffff8881599fc780 R12: ffff88811b6a7b7e
R13: 1ffff110236d4f6f R14: ffff88811b6a7ac0 R15: 1ffff110236d4f76
FS: 00007f2e9eb47700(0000) GS:ffff8881f6b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2e421000 CR3: 000000010e6d4000 CR4: 00000000003526e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
&lt;TASK&gt;
[&lt;ffffffff8471a49f&gt;] netdev_start_xmit include/linux/netdevice.h:4925 [inline]
[&lt;ffffffff8471a49f&gt;] __dev_direct_xmit+0x4ef/0x850 net/core/dev.c:4380
[&lt;ffffffff851d845b&gt;] dev_direct_xmit include/linux/netdevice.h:3043 [inline]
[&lt;ffffffff851d845b&gt;] packet_direct_xmit+0x18b/0x300 net/packet/af_packet.c:284
[&lt;ffffffff851c7472&gt;] packet_snd net/packet/af_packet.c:3112 [inline]
[&lt;ffffffff851c7472&gt;] packet_sendmsg+0x4a22/0x64d0 net/packet/af_packet.c:3143
[&lt;ffffffff8467a4b2&gt;] sock_sendmsg_nosec net/socket.c:716 [inline]
[&lt;ffffffff8467a4b2&gt;] sock_sendmsg net/socket.c:736 [inline]
[&lt;ffffffff8467a4b2&gt;] __sys_sendto+0x472/0x5f0 net/socket.c:2139
[&lt;ffffffff8467a715&gt;] __do_sys_sendto net/socket.c:2151 [inline]
[&lt;ffffffff8467a715&gt;] __se_sys_sendto net/socket.c:2147 [inline]
[&lt;ffffffff8467a715&gt;] __x64_sys_sendto+0xe5/0x100 net/socket.c:2147
[&lt;ffffffff8553071f&gt;] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[&lt;ffffffff8553071f&gt;] do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80
[&lt;ffffffff85600087&gt;] entry_SYSCALL_64_after_hwframe+0x63/0xcd</Note>
    </Notes>
    <CVE>CVE-2023-53601</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 memory leak in WMI firmware stats

Memory allocated for firmware pdev, vdev and beacon statistics
are not released during rmmod.

Fix it by calling ath11k_fw_stats_free() function before hardware
unregister.

While at it, avoid calling ath11k_fw_stats_free() while processing
the firmware stats received in the WMI event because the local list
is getting spliced and reinitialised and hence there are no elements
in the list after splicing.

Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1</Note>
    </Notes>
    <CVE>CVE-2023-53602</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: qla2xxx: Avoid fcport pointer dereference

Klocwork reported warning of NULL pointer may be dereferenced.  The routine
exits when sa_ctl is NULL and fcport is allocated after the exit call thus
causing NULL fcport pointer to dereference at the time of exit.

To avoid fcport pointer dereference, exit the routine when sa_ctl is NULL.</Note>
    </Notes>
    <CVE>CVE-2023-53603</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_si: fix a memleak in try_smi_init()

Kmemleak reported the following leak info in try_smi_init():

unreferenced object 0xffff00018ecf9400 (size 1024):
  comm "modprobe", pid 2707763, jiffies 4300851415 (age 773.308s)
  backtrace:
    [&lt;000000004ca5b312&gt;] __kmalloc+0x4b8/0x7b0
    [&lt;00000000953b1072&gt;] try_smi_init+0x148/0x5dc [ipmi_si]
    [&lt;000000006460d325&gt;] 0xffff800081b10148
    [&lt;0000000039206ea5&gt;] do_one_initcall+0x64/0x2a4
    [&lt;00000000601399ce&gt;] do_init_module+0x50/0x300
    [&lt;000000003c12ba3c&gt;] load_module+0x7a8/0x9e0
    [&lt;00000000c246fffe&gt;] __se_sys_init_module+0x104/0x180
    [&lt;00000000eea99093&gt;] __arm64_sys_init_module+0x24/0x30
    [&lt;0000000021b1ef87&gt;] el0_svc_common.constprop.0+0x94/0x250
    [&lt;0000000070f4f8b7&gt;] do_el0_svc+0x48/0xe0
    [&lt;000000005a05337f&gt;] el0_svc+0x24/0x3c
    [&lt;000000005eb248d6&gt;] el0_sync_handler+0x160/0x164
    [&lt;0000000030a59039&gt;] el0_sync+0x160/0x180

The problem was that when an error occurred before handlers registration
and after allocating `new_smi-&gt;si_sm`, the variable wouldn't be freed in
the error handling afterwards since `shutdown_smi()` hadn't been
registered yet. Fix it by adding a `kfree()` in the error handling path
in `try_smi_init()`.</Note>
    </Notes>
    <CVE>CVE-2023-53611</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dax: Fix dax_mapping_release() use after free

A CONFIG_DEBUG_KOBJECT_RELEASE test of removing a device-dax region
provider (like modprobe -r dax_hmem) yields:

 kobject: 'mapping0' (ffff93eb460e8800): kobject_release, parent 0000000000000000 (delayed 2000)
 [..]
 DEBUG_LOCKS_WARN_ON(1)
 WARNING: CPU: 23 PID: 282 at kernel/locking/lockdep.c:232 __lock_acquire+0x9fc/0x2260
 [..]
 RIP: 0010:__lock_acquire+0x9fc/0x2260
 [..]
 Call Trace:
  &lt;TASK&gt;
 [..]
  lock_acquire+0xd4/0x2c0
  ? ida_free+0x62/0x130
  _raw_spin_lock_irqsave+0x47/0x70
  ? ida_free+0x62/0x130
  ida_free+0x62/0x130
  dax_mapping_release+0x1f/0x30
  device_release+0x36/0x90
  kobject_delayed_cleanup+0x46/0x150

Due to attempting ida_free() on an ida object that has already been
freed. Devices typically only hold a reference on their parent while
registered. If a child needs a parent object to complete its release it
needs to hold a reference that it drops from its release callback.
Arrange for a dax_mapping to pin its parent dev_dax instance until
dax_mapping_release().</Note>
    </Notes>
    <CVE>CVE-2023-53613</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: qla2xxx: Fix deletion race condition

System crash when using debug kernel due to link list corruption. The cause
of the link list corruption is due to session deletion was allowed to queue
up twice.  Here's the internal trace that show the same port was allowed to
double queue for deletion on different cpu.

20808683956 015 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1
20808683957 027 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1

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

jfs: fix invalid free of JFS_IP(ipimap)-&gt;i_imap in diUnmount

syzbot found an invalid-free in diUnmount:

BUG: KASAN: double-free in slab_free mm/slub.c:3661 [inline]
BUG: KASAN: double-free in __kmem_cache_free+0x71/0x110 mm/slub.c:3674
Free of addr ffff88806f410000 by task syz-executor131/3632

 CPU: 0 PID: 3632 Comm: syz-executor131 Not tainted 6.1.0-rc7-syzkaller-00012-gca57f02295f1 #0
 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
 Call Trace:
  &lt;TASK&gt;
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106
  print_address_description+0x74/0x340 mm/kasan/report.c:284
  print_report+0x107/0x1f0 mm/kasan/report.c:395
  kasan_report_invalid_free+0xac/0xd0 mm/kasan/report.c:460
  ____kasan_slab_free+0xfb/0x120
  kasan_slab_free include/linux/kasan.h:177 [inline]
  slab_free_hook mm/slub.c:1724 [inline]
  slab_free_freelist_hook+0x12e/0x1a0 mm/slub.c:1750
  slab_free mm/slub.c:3661 [inline]
  __kmem_cache_free+0x71/0x110 mm/slub.c:3674
  diUnmount+0xef/0x100 fs/jfs/jfs_imap.c:195
  jfs_umount+0x108/0x370 fs/jfs/jfs_umount.c:63
  jfs_put_super+0x86/0x190 fs/jfs/super.c:194
  generic_shutdown_super+0x130/0x310 fs/super.c:492
  kill_block_super+0x79/0xd0 fs/super.c:1428
  deactivate_locked_super+0xa7/0xf0 fs/super.c:332
  cleanup_mnt+0x494/0x520 fs/namespace.c:1186
  task_work_run+0x243/0x300 kernel/task_work.c:179
  exit_task_work include/linux/task_work.h:38 [inline]
  do_exit+0x664/0x2070 kernel/exit.c:820
  do_group_exit+0x1fd/0x2b0 kernel/exit.c:950
  __do_sys_exit_group kernel/exit.c:961 [inline]
  __se_sys_exit_group kernel/exit.c:959 [inline]
  __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:959
  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
  do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
  entry_SYSCALL_64_after_hwframe+0x63/0xcd
[...]

JFS_IP(ipimap)-&gt;i_imap is not setting to NULL after free in diUnmount.
If jfs_remount() free JFS_IP(ipimap)-&gt;i_imap but then failed at diMount().
JFS_IP(ipimap)-&gt;i_imap will be freed once again.
Fix this problem by setting JFS_IP(ipimap)-&gt;i_imap to NULL after free.</Note>
    </Notes>
    <CVE>CVE-2023-53616</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: aspeed: socinfo: Add kfree for kstrdup

Add kfree() in the later error handling in order to avoid memory leak.</Note>
    </Notes>
    <CVE>CVE-2023-53617</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: reject invalid reloc tree root keys with stack dump

[BUG]
Syzbot reported a crash that an ASSERT() got triggered inside
prepare_to_merge().

That ASSERT() makes sure the reloc tree is properly pointed back by its
subvolume tree.

[CAUSE]
After more debugging output, it turns out we had an invalid reloc tree:

  BTRFS error (device loop1): reloc tree mismatch, root 8 has no reloc root, expect reloc root key (-8, 132, 8) gen 17

Note the above root key is (TREE_RELOC_OBJECTID, ROOT_ITEM,
QUOTA_TREE_OBJECTID), meaning it's a reloc tree for quota tree.

But reloc trees can only exist for subvolumes, as for non-subvolume
trees, we just COW the involved tree block, no need to create a reloc
tree since those tree blocks won't be shared with other trees.

Only subvolumes tree can share tree blocks with other trees (thus they
have BTRFS_ROOT_SHAREABLE flag).

Thus this new debug output proves my previous assumption that corrupted
on-disk data can trigger that ASSERT().

[FIX]
Besides the dedicated fix and the graceful exit, also let tree-checker to
check such root keys, to make sure reloc trees can only exist for subvolumes.</Note>
    </Notes>
    <CVE>CVE-2023-53618</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: conntrack: Avoid nf_ct_helper_hash uses after free

If nf_conntrack_init_start() fails (for example due to a
register_nf_conntrack_bpf() failure), the nf_conntrack_helper_fini()
clean-up path frees the nf_ct_helper_hash map.

When built with NF_CONNTRACK=y, further netfilter modules (e.g:
netfilter_conntrack_ftp) can still be loaded and call
nf_conntrack_helpers_register(), independently of whether nf_conntrack
initialized correctly. This accesses the nf_ct_helper_hash dangling
pointer and causes a uaf, possibly leading to random memory corruption.

This patch guards nf_conntrack_helper_register() from accessing a freed
or uninitialized nf_ct_helper_hash pointer and fixes possible
uses-after-free when loading a conntrack module.</Note>
    </Notes>
    <CVE>CVE-2023-53619</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

memcontrol: ensure memcg acquired by id is properly set up

In the eviction recency check, we attempt to retrieve the memcg to which
the folio belonged when it was evicted, by the memcg id stored in the
shadow entry.  However, there is a chance that the retrieved memcg is not
the original memcg that has been killed, but a new one which happens to
have the same id.

This is a somewhat unfortunate, but acceptable and rare inaccuracy in the
heuristics.  However, if we retrieve this new memcg between its allocation
and when it is properly attached to the memcg hierarchy, we could run into
the following NULL pointer exception during the memcg hierarchy traversal
done in mem_cgroup_get_nr_swap_pages():

[ 155757.793456] BUG: kernel NULL pointer dereference, address: 00000000000000c0
[ 155757.807568] #PF: supervisor read access in kernel mode
[ 155757.818024] #PF: error_code(0x0000) - not-present page
[ 155757.828482] PGD 401f77067 P4D 401f77067 PUD 401f76067 PMD 0
[ 155757.839985] Oops: 0000 [#1] SMP
[ 155757.887870] RIP: 0010:mem_cgroup_get_nr_swap_pages+0x3d/0xb0
[ 155757.899377] Code: 29 19 4a 02 48 39 f9 74 63 48 8b 97 c0 00 00 00 48 8b b7 58 02 00 00 48 2b b7 c0 01 00 00 48 39 f0 48 0f 4d c6 48 39 d1 74 42 &lt;48&gt; 8b b2 c0 00 00 00 48 8b ba 58 02 00 00 48 2b ba c0 01 00 00 48
[ 155757.937125] RSP: 0018:ffffc9002ecdfbc8 EFLAGS: 00010286
[ 155757.947755] RAX: 00000000003a3b1c RBX: 000007ffffffffff RCX: ffff888280183000
[ 155757.962202] RDX: 0000000000000000 RSI: 0007ffffffffffff RDI: ffff888bbc2d1000
[ 155757.976648] RBP: 0000000000000001 R08: 000000000000000b R09: ffff888ad9cedba0
[ 155757.991094] R10: ffffea0039c07900 R11: 0000000000000010 R12: ffff888b23a7b000
[ 155758.005540] R13: 0000000000000000 R14: ffff888bbc2d1000 R15: 000007ffffc71354
[ 155758.019991] FS:  00007f6234c68640(0000) GS:ffff88903f9c0000(0000) knlGS:0000000000000000
[ 155758.036356] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 155758.048023] CR2: 00000000000000c0 CR3: 0000000a83eb8004 CR4: 00000000007706e0
[ 155758.062473] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 155758.076924] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 155758.091376] PKRU: 55555554
[ 155758.096957] Call Trace:
[ 155758.102016]  &lt;TASK&gt;
[ 155758.106502]  ? __die+0x78/0xc0
[ 155758.112793]  ? page_fault_oops+0x286/0x380
[ 155758.121175]  ? exc_page_fault+0x5d/0x110
[ 155758.129209]  ? asm_exc_page_fault+0x22/0x30
[ 155758.137763]  ? mem_cgroup_get_nr_swap_pages+0x3d/0xb0
[ 155758.148060]  workingset_test_recent+0xda/0x1b0
[ 155758.157133]  workingset_refault+0xca/0x1e0
[ 155758.165508]  filemap_add_folio+0x4d/0x70
[ 155758.173538]  page_cache_ra_unbounded+0xed/0x190
[ 155758.182919]  page_cache_sync_ra+0xd6/0x1e0
[ 155758.191738]  filemap_read+0x68d/0xdf0
[ 155758.199495]  ? mlx5e_napi_poll+0x123/0x940
[ 155758.207981]  ? __napi_schedule+0x55/0x90
[ 155758.216095]  __x64_sys_pread64+0x1d6/0x2c0
[ 155758.224601]  do_syscall_64+0x3d/0x80
[ 155758.232058]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
[ 155758.242473] RIP: 0033:0x7f62c29153b5
[ 155758.249938] Code: e8 48 89 75 f0 89 7d f8 48 89 4d e0 e8 b4 e6 f7 ff 41 89 c0 4c 8b 55 e0 48 8b 55 e8 48 8b 75 f0 8b 7d f8 b8 11 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 33 44 89 c7 48 89 45 f8 e8 e7 e6 f7 ff 48 8b
[ 155758.288005] RSP: 002b:00007f6234c5ffd0 EFLAGS: 00000293 ORIG_RAX: 0000000000000011
[ 155758.303474] RAX: ffffffffffffffda RBX: 00007f628c4e70c0 RCX: 00007f62c29153b5
[ 155758.318075] RDX: 000000000003c041 RSI: 00007f61d2986000 RDI: 0000000000000076
[ 155758.332678] RBP: 00007f6234c5fff0 R08: 0000000000000000 R09: 0000000064d5230c
[ 155758.347452] R10: 000000000027d450 R11: 0000000000000293 R12: 000000000003c041
[ 155758.362044] R13: 00007f61d2986000 R14: 00007f629e11b060 R15: 000000000027d450
[ 155758.376661]  &lt;/TASK&gt;

This patch fixes the issue by moving the memcg's id publication from the
alloc stage to 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53621</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gfs2: Fix possible data races in gfs2_show_options()

Some fields such as gt_logd_secs of the struct gfs2_tune are accessed
without holding the lock gt_spin in gfs2_show_options():

  val = sdp-&gt;sd_tune.gt_logd_secs;
  if (val != 30)
    seq_printf(s, ",commit=%d", val);

And thus can cause data races when gfs2_show_options() and other functions
such as gfs2_reconfigure() are concurrently executed:

  spin_lock(&amp;gt-&gt;gt_spin);
  gt-&gt;gt_logd_secs = newargs-&gt;ar_commit;

To fix these possible data races, the lock sdp-&gt;sd_tune.gt_spin is
acquired before accessing the fields of gfs2_tune and released after these
accesses.

Further changes by Andreas:

- Don't hold the spin lock over the seq_printf operations.</Note>
    </Notes>
    <CVE>CVE-2023-53622</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: dell-sysman: Fix reference leak

If a duplicate attribute is found using kset_find_obj(),
a reference to that attribute is returned. This means
that we need to dispose it accordingly. Use kobject_put()
to dispose the duplicate attribute in such a case.

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

net/mlx5e: Take RTNL lock when needed before calling xdp_set_features()

Hold RTNL lock when calling xdp_set_features() with a registered netdev,
as the call triggers the netdev notifiers. This could happen when
switching from uplink rep to nic profile for example.

This resolves the following call trace:

RTNL: assertion failed at net/core/dev.c (1953)
WARNING: CPU: 6 PID: 112670 at net/core/dev.c:1953 call_netdevice_notifiers_info+0x7c/0x80
Modules linked in: sch_mqprio sch_mqprio_lib act_tunnel_key act_mirred act_skbedit cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress bonding ib_umad ip_gre rdma_ucm mlx5_vfio_pci ipip tunnel4 ip6_gre gre mlx5_ib vfio_pci vfio_pci_core vfio_iommu_type1 ib_uverbs vfio mlx5_core ib_ipoib geneve nf_tables ip6_tunnel tunnel6 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: 6 PID: 112670 Comm: devlink Not tainted 6.4.0-rc7_for_upstream_min_debug_2023_06_28_17_02 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:call_netdevice_notifiers_info+0x7c/0x80
Code: 90 ff 80 3d 2d 6b f7 00 00 75 c5 ba a1 07 00 00 48 c7 c6 e4 ce 0b 82 48 c7 c7 c8 f4 04 82 c6 05 11 6b f7 00 01 e8 a4 7c 8e ff &lt;0f&gt; 0b eb a2 0f 1f 44 00 00 55 48 89 e5 41 54 48 83 e4 f0 48 83 ec
RSP: 0018:ffff8882a21c3948 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffffffff82e6f880 RCX: 0000000000000027
RDX: ffff88885f99b5c8 RSI: 0000000000000001 RDI: ffff88885f99b5c0
RBP: 0000000000000028 R08: ffff88887ffabaa8 R09: 0000000000000003
R10: ffff88887fecbac0 R11: ffff88887ff7bac0 R12: ffff8882a21c3968
R13: ffff88811c018940 R14: 0000000000000000 R15: ffff8881274401a0
FS:  00007fe141c81800(0000) GS:ffff88885f980000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f787c28b948 CR3: 000000014bcf3005 CR4: 0000000000370ea0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 ? __warn+0x79/0x120
 ? call_netdevice_notifiers_info+0x7c/0x80
 ? report_bug+0x17c/0x190
 ? handle_bug+0x3c/0x60
 ? exc_invalid_op+0x14/0x70
 ? asm_exc_invalid_op+0x16/0x20
 ? call_netdevice_notifiers_info+0x7c/0x80
 ? call_netdevice_notifiers_info+0x7c/0x80
 call_netdevice_notifiers+0x2e/0x50
 mlx5e_set_xdp_feature+0x21/0x50 [mlx5_core]
 mlx5e_nic_init+0xf1/0x1a0 [mlx5_core]
 mlx5e_netdev_init_profile+0x76/0x110 [mlx5_core]
 mlx5e_netdev_attach_profile+0x1f/0x90 [mlx5_core]
 mlx5e_netdev_change_profile+0x92/0x160 [mlx5_core]
 mlx5e_netdev_attach_nic_profile+0x1b/0x30 [mlx5_core]
 mlx5e_vport_rep_unload+0xaa/0xc0 [mlx5_core]
 __esw_offloads_unload_rep+0x52/0x60 [mlx5_core]
 mlx5_esw_offloads_rep_unload+0x52/0x70 [mlx5_core]
 esw_offloads_unload_rep+0x34/0x70 [mlx5_core]
 esw_offloads_disable+0x2b/0x90 [mlx5_core]
 mlx5_eswitch_disable_locked+0x1b9/0x210 [mlx5_core]
 mlx5_devlink_eswitch_mode_set+0xf5/0x630 [mlx5_core]
 ? devlink_get_from_attrs_lock+0x9e/0x110
 devlink_nl_cmd_eswitch_set_doit+0x60/0xe0
 genl_family_rcv_msg_doit.isra.0+0xc2/0x110
 genl_rcv_msg+0x17d/0x2b0
 ? devlink_get_from_attrs_lock+0x110/0x110
 ? devlink_nl_cmd_eswitch_get_doit+0x290/0x290
 ? devlink_pernet_pre_exit+0xf0/0xf0
 ? genl_family_rcv_msg_doit.isra.0+0x110/0x110
 netlink_rcv_skb+0x54/0x100
 genl_rcv+0x24/0x40
 netlink_unicast+0x1f6/0x2c0
 netlink_sendmsg+0x232/0x4a0
 sock_sendmsg+0x38/0x60
 ? _copy_from_user+0x2a/0x60
 __sys_sendto+0x110/0x160
 ? __count_memcg_events+0x48/0x90
 ? handle_mm_fault+0x161/0x260
 ? do_user_addr_fault+0x278/0x6e0
 __x64_sys_sendto+0x20/0x30
 do_syscall_64+0x3d/0x90
 entry_SYSCALL_64_after_hwframe+0x46/0xb0
RIP: 0033
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53632</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 a leak in map_user_pages()

If get_user_pages_fast() allocates some pages but not as many as we
wanted, then the current code leaks those pages.  Call put_page() on
the pages before returning.</Note>
    </Notes>
    <CVE>CVE-2023-53633</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

octeon_ep: cancel queued works in probe error path

If it fails to get the devices's MAC address, octep_probe exits while
leaving the delayed work intr_poll_task queued. When the work later
runs, it's a use after free.

Move the cancelation of intr_poll_task from octep_remove into
octep_device_cleanup. This does not change anything in the octep_remove
flow, but octep_device_cleanup is called also in the octep_probe error
path, where the cancelation is needed.

Note that the cancelation of ctrl_mbox_task has to follow
intr_poll_task's, because the ctrl_mbox_task may be queued by
intr_poll_task.</Note>
    </Notes>
    <CVE>CVE-2023-53638</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 bpf_refcount_acquire fallible for non-owning refs

This patch fixes an incorrect assumption made in the original
bpf_refcount series [0], specifically that the BPF program calling
bpf_refcount_acquire on some node can always guarantee that the node is
alive. In that series, the patch adding failure behavior to rbtree_add
and list_push_{front, back} breaks this assumption for non-owning
references.

Consider the following program:

  n = bpf_kptr_xchg(&amp;mapval, NULL);
  /* skip error checking */

  bpf_spin_lock(&amp;l);
  if(bpf_rbtree_add(&amp;t, &amp;n-&gt;rb, less)) {
    bpf_refcount_acquire(n);
    /* Failed to add, do something else with the node */
  }
  bpf_spin_unlock(&amp;l);

It's incorrect to assume that bpf_refcount_acquire will always succeed in this
scenario. bpf_refcount_acquire is being called in a critical section
here, but the lock being held is associated with rbtree t, which isn't
necessarily the lock associated with the tree that the node is already
in. So after bpf_rbtree_add fails to add the node and calls bpf_obj_drop
in it, the program has no ownership of the node's lifetime. Therefore
the node's refcount can be decr'd to 0 at any time after the failing
rbtree_add. If this happens before the refcount_acquire above, the node
might be free'd, and regardless refcount_acquire will be incrementing a
0 refcount.

Later patches in the series exercise this scenario, resulting in the
expected complaint from the kernel (without this patch's changes):

  refcount_t: addition on 0; use-after-free.
  WARNING: CPU: 1 PID: 207 at lib/refcount.c:25 refcount_warn_saturate+0xbc/0x110
  Modules linked in: bpf_testmod(O)
  CPU: 1 PID: 207 Comm: test_progs Tainted: G           O       6.3.0-rc7-02231-g723de1a718a2-dirty #371
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
  RIP: 0010:refcount_warn_saturate+0xbc/0x110
  Code: 6f 64 f6 02 01 e8 84 a3 5c ff 0f 0b eb 9d 80 3d 5e 64 f6 02 00 75 94 48 c7 c7 e0 13 d2 82 c6 05 4e 64 f6 02 01 e8 64 a3 5c ff &lt;0f&gt; 0b e9 7a ff ff ff 80 3d 38 64 f6 02 00 0f 85 6d ff ff ff 48 c7
  RSP: 0018:ffff88810b9179b0 EFLAGS: 00010082
  RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000
  RDX: 0000000000000202 RSI: 0000000000000008 RDI: ffffffff857c3680
  RBP: ffff88810027d3c0 R08: ffffffff8125f2a4 R09: ffff88810b9176e7
  R10: ffffed1021722edc R11: 746e756f63666572 R12: ffff88810027d388
  R13: ffff88810027d3c0 R14: ffffc900005fe030 R15: ffffc900005fe048
  FS:  00007fee0584a700(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00005634a96f6c58 CR3: 0000000108ce9002 CR4: 0000000000770ee0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  PKRU: 55555554
  Call Trace:
   &lt;TASK&gt;
   bpf_refcount_acquire_impl+0xb5/0xc0

  (rest of output snipped)

The patch addresses this by changing bpf_refcount_acquire_impl to use
refcount_inc_not_zero instead of refcount_inc and marking
bpf_refcount_acquire KF_RET_NULL.

For owning references, though, we know the above scenario is not possible
and thus that bpf_refcount_acquire will always succeed. Some verifier
bookkeeping is added to track "is input owning ref?" for bpf_refcount_acquire
calls and return false from is_kfunc_ret_null for bpf_refcount_acquire on
owning refs despite it being marked KF_RET_NULL.

Existing selftests using bpf_refcount_acquire are modified where
necessary to NULL-check its return value.

  [0]: https://lore.kernel.org/bpf/20230415201811.343116-1-davemarchevsky@fb.com/</Note>
    </Notes>
    <CVE>CVE-2023-53645</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/i915/perf: add sentinel to xehp_oa_b_counters

Arrays passed to reg_in_range_table should end with empty record.

The patch solves KASAN detected bug with signature:
BUG: KASAN: global-out-of-bounds in xehp_is_valid_b_counter_addr+0x2c7/0x350 [i915]
Read of size 4 at addr ffffffffa1555d90 by task perf/1518

CPU: 4 PID: 1518 Comm: perf Tainted: G U 6.4.0-kasan_438-g3303d06107f3+ #1
Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P DDR5 SODIMM SBS RVP, BIOS MTLPFWI1.R00.3223.D80.2305311348 05/31/2023
Call Trace:
&lt;TASK&gt;
...
xehp_is_valid_b_counter_addr+0x2c7/0x350 [i915]

(cherry picked from commit 2f42c5afb34b5696cf5fe79e744f99be9b218798)</Note>
    </Notes>
    <CVE>CVE-2023-53646</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Drivers: hv: vmbus: Don't dereference ACPI root object handle

Since the commit referenced in the Fixes: tag below the VMBus client driver
is walking the ACPI namespace up from the VMBus ACPI device to the ACPI
namespace root object trying to find Hyper-V MMIO ranges.

However, if it is not able to find them it ends trying to walk resources of
the ACPI namespace root object itself.
This object has all-ones handle, which causes a NULL pointer dereference
in the ACPI code (from dereferencing this pointer with an offset).

This in turn causes an oops on boot with VMBus host implementations that do
not provide Hyper-V MMIO ranges in their VMBus ACPI device or its
ancestors.
The QEMU VMBus implementation is an example of such implementation.

I guess providing these ranges is optional, since all tested Windows
versions seem to be able to use VMBus devices without them.

Fix this by explicitly terminating the lookup at the ACPI namespace root
object.

Note that Linux guests under KVM/QEMU do not use the Hyper-V PV interface
by default - they only do so if the KVM PV interface is missing or
disabled.

Example stack trace of such oops:
[ 3.710827] ? __die+0x1f/0x60
[ 3.715030] ? page_fault_oops+0x159/0x460
[ 3.716008] ? exc_page_fault+0x73/0x170
[ 3.716959] ? asm_exc_page_fault+0x22/0x30
[ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0
[ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0
[ 3.720018] acpi_ns_get_node_unlocked+0xb5/0xe0
[ 3.721120] ? acpi_ns_check_object_type+0xfe/0x200
[ 3.722285] ? acpi_rs_convert_aml_to_resource+0x37/0x6e0
[ 3.723559] ? down_timeout+0x3a/0x60
[ 3.724455] ? acpi_ns_get_node+0x3a/0x60
[ 3.725412] acpi_ns_get_node+0x3a/0x60
[ 3.726335] acpi_ns_evaluate+0x1c3/0x2c0
[ 3.727295] acpi_ut_evaluate_object+0x64/0x1b0
[ 3.728400] acpi_rs_get_method_data+0x2b/0x70
[ 3.729476] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus]
[ 3.730940] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus]
[ 3.732411] acpi_walk_resources+0x78/0xd0
[ 3.733398] vmbus_platform_driver_probe+0x9f/0x1d0 [hv_vmbus]
[ 3.734802] platform_probe+0x3d/0x90
[ 3.735684] really_probe+0x19b/0x400
[ 3.736570] ? __device_attach_driver+0x100/0x100
[ 3.737697] __driver_probe_device+0x78/0x160
[ 3.738746] driver_probe_device+0x1f/0x90
[ 3.739743] __driver_attach+0xc2/0x1b0
[ 3.740671] bus_for_each_dev+0x70/0xc0
[ 3.741601] bus_add_driver+0x10e/0x210
[ 3.742527] driver_register+0x55/0xf0
[ 3.744412] ? 0xffffffffc039a000
[ 3.745207] hv_acpi_init+0x3c/0x1000 [hv_vmbus]</Note>
    </Notes>
    <CVE>CVE-2023-53647</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: ac97: Fix possible NULL dereference in snd_ac97_mixer

smatch error:
sound/pci/ac97/ac97_codec.c:2354 snd_ac97_mixer() error:
we previously assumed 'rac97' could be null (see line 2072)

remove redundant assignment, return error if rac97 is NULL.</Note>
    </Notes>
    <CVE>CVE-2023-53648</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 trace: Really free the evsel-&gt;priv area

In 3cb4d5e00e037c70 ("perf trace: Free syscall tp fields in
evsel-&gt;priv") it only was freeing if strcmp(evsel-&gt;tp_format-&gt;system,
"syscalls") returned zero, while the corresponding initialization of
evsel-&gt;priv was being performed if it was _not_ zero, i.e. if the tp
system wasn't 'syscalls'.

Just stop looking for that and free it if evsel-&gt;priv was set, which
should be equivalent.

Also use the pre-existing evsel_trace__delete() function.

This resolves these leaks, detected with:

  $ make EXTRA_CFLAGS="-fsanitize=address" BUILD_BPF_SKEL=1 CORESIGHT=1 O=/tmp/build/perf-tools-next -C tools/perf install-bin

  =================================================================
  ==481565==ERROR: LeakSanitizer: detected memory leaks

  Direct leak of 40 byte(s) in 1 object(s) allocated from:
      #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097)
      #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966)
      #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307
      #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333
      #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458
      #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480
      #6 0x540e8b in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3212
      #7 0x540e8b in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891
      #8 0x540e8b in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156
      #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323
      #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377
      #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421
      #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537
      #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)

  Direct leak of 40 byte(s) in 1 object(s) allocated from:
      #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097)
      #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966)
      #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307
      #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333
      #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458
      #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480
      #6 0x540dd1 in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3205
      #7 0x540dd1 in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891
      #8 0x540dd1 in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156
      #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323
      #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377
      #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421
      #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537
      #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)

  SUMMARY: AddressSanitizer: 80 byte(s) leaked in 2 allocation(s).
  [root@quaco ~]#

With this we plug all leaks with "perf trace sleep 1".</Note>
    </Notes>
    <CVE>CVE-2023-53649</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: omapfb: lcd_mipid: Fix an error handling path in mipid_spi_probe()

If 'mipid_detect()' fails, we must free 'md' to avoid a memory leak.</Note>
    </Notes>
    <CVE>CVE-2023-53650</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vdpa: Add features attr to vdpa_nl_policy for nlattr length check

The vdpa_nl_policy structure is used to validate the nlattr when parsing
the incoming nlmsg. It will ensure the attribute being described produces
a valid nlattr pointer in info-&gt;attrs before entering into each handler
in vdpa_nl_ops.

That is to say, the missing part in vdpa_nl_policy may lead to illegal
nlattr after parsing, which could lead to OOB read just like CVE-2023-3773.

This patch adds the missing nla_policy for vdpa features attr to avoid
such bugs.</Note>
    </Notes>
    <CVE>CVE-2023-53652</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: amphion: fix REVERSE_INULL issues reported by coverity

null-checking of a pointor is suggested before dereferencing it</Note>
    </Notes>
    <CVE>CVE-2023-53653</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

octeontx2-af: Add validation before accessing cgx and lmac

with the addition of new MAC blocks like CN10K RPM and CN10KB
RPM_USX, LMACs are noncontiguous and CGX blocks are also
noncontiguous. But during RVU driver initialization, the driver
is assuming they are contiguous and trying to access
cgx or lmac with their id which is resulting in kernel panic.

This patch fixes the issue by adding proper checks.

[   23.219150] pc : cgx_lmac_read+0x38/0x70
[   23.219154] lr : rvu_program_channels+0x3f0/0x498
[   23.223852] sp : ffff000100d6fc80
[   23.227158] x29: ffff000100d6fc80 x28: ffff00010009f880 x27:
000000000000005a
[   23.234288] x26: ffff000102586768 x25: 0000000000002500 x24:
fffffffffff0f000</Note>
    </Notes>
    <CVE>CVE-2023-53654</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/perf: hisi: Don't migrate perf to the CPU going to teardown

The driver needs to migrate the perf context if the current using CPU going
to teardown. By the time calling the cpuhp::teardown() callback the
cpu_online_mask() hasn't updated yet and still includes the CPU going to
teardown. In current driver's implementation we may migrate the context
to the teardown CPU and leads to the below calltrace:

...
[  368.104662][  T932] task:cpuhp/0         state:D stack:    0 pid:   15 ppid:     2 flags:0x00000008
[  368.113699][  T932] Call trace:
[  368.116834][  T932]  __switch_to+0x7c/0xbc
[  368.120924][  T932]  __schedule+0x338/0x6f0
[  368.125098][  T932]  schedule+0x50/0xe0
[  368.128926][  T932]  schedule_preempt_disabled+0x18/0x24
[  368.134229][  T932]  __mutex_lock.constprop.0+0x1d4/0x5dc
[  368.139617][  T932]  __mutex_lock_slowpath+0x1c/0x30
[  368.144573][  T932]  mutex_lock+0x50/0x60
[  368.148579][  T932]  perf_pmu_migrate_context+0x84/0x2b0
[  368.153884][  T932]  hisi_pcie_pmu_offline_cpu+0x90/0xe0 [hisi_pcie_pmu]
[  368.160579][  T932]  cpuhp_invoke_callback+0x2a0/0x650
[  368.165707][  T932]  cpuhp_thread_fun+0xe4/0x190
[  368.170316][  T932]  smpboot_thread_fn+0x15c/0x1a0
[  368.175099][  T932]  kthread+0x108/0x13c
[  368.179012][  T932]  ret_from_fork+0x10/0x18
...

Use function cpumask_any_but() to find one correct active cpu to fixes
this issue.</Note>
    </Notes>
    <CVE>CVE-2023-53656</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ice: Don't tx before switchdev is fully configured

There is possibility that ice_eswitch_port_start_xmit might be
called while some resources are still not allocated which might
cause NULL pointer dereference. Fix this by checking if switchdev
configuration was finished.</Note>
    </Notes>
    <CVE>CVE-2023-53657</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: bcm-qspi: return error if neither hif_mspi nor mspi is available

If neither a "hif_mspi" nor "mspi" resource is present, the driver will
just early exit in probe but still return success. Apart from not doing
anything meaningful, this would then also lead to a null pointer access
on removal, as platform_get_drvdata() would return NULL, which it would
then try to dereference when trying to unregister the spi master.

Fix this by unconditionally calling devm_ioremap_resource(), as it can
handle a NULL res and will then return a viable ERR_PTR() if we get one.

The "return 0;" was previously a "goto qspi_resource_err;" where then
ret was returned, but since ret was still initialized to 0 at this place
this was a valid conversion in 63c5395bb7a9 ("spi: bcm-qspi: Fix
use-after-free on unbind"). The issue was not introduced by this commit,
only made more obvious.</Note>
    </Notes>
    <CVE>CVE-2023-53658</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iavf: Fix out-of-bounds when setting channels on remove

If we set channels greater during iavf_remove(), and waiting reset done
would be timeout, then returned with error but changed num_active_queues
directly, that will lead to OOB like the following logs. Because the
num_active_queues is greater than tx/rx_rings[] allocated actually.

Reproducer:

  [root@host ~]# cat repro.sh
  #!/bin/bash

  pf_dbsf="0000:41:00.0"
  vf0_dbsf="0000:41:02.0"
  g_pids=()

  function do_set_numvf()
  {
      echo 2 &gt;/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs
      sleep $((RANDOM%3+1))
      echo 0 &gt;/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs
      sleep $((RANDOM%3+1))
  }

  function do_set_channel()
  {
      local nic=$(ls -1 --indicator-style=none /sys/bus/pci/devices/${vf0_dbsf}/net/)
      [ -z "$nic" ] &amp;&amp; { sleep $((RANDOM%3)) ; return 1; }
      ifconfig $nic 192.168.18.5 netmask 255.255.255.0
      ifconfig $nic up
      ethtool -L $nic combined 1
      ethtool -L $nic combined 4
      sleep $((RANDOM%3))
  }

  function on_exit()
  {
      local pid
      for pid in "${g_pids[@]}"; do
          kill -0 "$pid" &amp;&gt;/dev/null &amp;&amp; kill "$pid" &amp;&gt;/dev/null
      done
      g_pids=()
  }

  trap "on_exit; exit" EXIT

  while :; do do_set_numvf ; done &amp;
  g_pids+=($!)
  while :; do do_set_channel ; done &amp;
  g_pids+=($!)

  wait

Result:

[ 3506.152887] iavf 0000:41:02.0: Removing device
[ 3510.400799] ==================================================================
[ 3510.400820] BUG: KASAN: slab-out-of-bounds in iavf_free_all_tx_resources+0x156/0x160 [iavf]
[ 3510.400823] Read of size 8 at addr ffff88b6f9311008 by task repro.sh/55536
[ 3510.400823]
[ 3510.400830] CPU: 101 PID: 55536 Comm: repro.sh Kdump: loaded Tainted: G           O     --------- -t - 4.18.0 #1
[ 3510.400832] Hardware name: Powerleader PR2008AL/H12DSi-N6, BIOS 2.0 04/09/2021
[ 3510.400835] Call Trace:
[ 3510.400851]  dump_stack+0x71/0xab
[ 3510.400860]  print_address_description+0x6b/0x290
[ 3510.400865]  ? iavf_free_all_tx_resources+0x156/0x160 [iavf]
[ 3510.400868]  kasan_report+0x14a/0x2b0
[ 3510.400873]  iavf_free_all_tx_resources+0x156/0x160 [iavf]
[ 3510.400880]  iavf_remove+0x2b6/0xc70 [iavf]
[ 3510.400884]  ? iavf_free_all_rx_resources+0x160/0x160 [iavf]
[ 3510.400891]  ? wait_woken+0x1d0/0x1d0
[ 3510.400895]  ? notifier_call_chain+0xc1/0x130
[ 3510.400903]  pci_device_remove+0xa8/0x1f0
[ 3510.400910]  device_release_driver_internal+0x1c6/0x460
[ 3510.400916]  pci_stop_bus_device+0x101/0x150
[ 3510.400919]  pci_stop_and_remove_bus_device+0xe/0x20
[ 3510.400924]  pci_iov_remove_virtfn+0x187/0x420
[ 3510.400927]  ? pci_iov_add_virtfn+0xe10/0xe10
[ 3510.400929]  ? pci_get_subsys+0x90/0x90
[ 3510.400932]  sriov_disable+0xed/0x3e0
[ 3510.400936]  ? bus_find_device+0x12d/0x1a0
[ 3510.400953]  i40e_free_vfs+0x754/0x1210 [i40e]
[ 3510.400966]  ? i40e_reset_all_vfs+0x880/0x880 [i40e]
[ 3510.400968]  ? pci_get_device+0x7c/0x90
[ 3510.400970]  ? pci_get_subsys+0x90/0x90
[ 3510.400982]  ? pci_vfs_assigned.part.7+0x144/0x210
[ 3510.400987]  ? __mutex_lock_slowpath+0x10/0x10
[ 3510.400996]  i40e_pci_sriov_configure+0x1fa/0x2e0 [i40e]
[ 3510.401001]  sriov_numvfs_store+0x214/0x290
[ 3510.401005]  ? sriov_totalvfs_show+0x30/0x30
[ 3510.401007]  ? __mutex_lock_slowpath+0x10/0x10
[ 3510.401011]  ? __check_object_size+0x15a/0x350
[ 3510.401018]  kernfs_fop_write+0x280/0x3f0
[ 3510.401022]  vfs_write+0x145/0x440
[ 3510.401025]  ksys_write+0xab/0x160
[ 3510.401028]  ? __ia32_sys_read+0xb0/0xb0
[ 3510.401031]  ? fput_many+0x1a/0x120
[ 3510.401032]  ? filp_close+0xf0/0x130
[ 3510.401038]  do_syscall_64+0xa0/0x370
[ 3510.401041]  ? page_fault+0x8/0x30
[ 3510.401043]  entry_SYSCALL_64_after_hwframe+0x65/0xca
[ 3510.401073] RIP: 0033:0x7f3a9bb842c0
[ 3510.401079] Code: 73 01 c3 48 8b 0d d8 cb 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 89 24 2d 00 00 75 10 b8 01 00 00 00 0f 05 &lt;48&gt; 3d 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53659</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf, cpumap: Handle skb as well when clean up ptr_ring

The following warning was reported when running xdp_redirect_cpu with
both skb-mode and stress-mode enabled:

  ------------[ cut here ]------------
  Incorrect XDP memory type (-2128176192) usage
  WARNING: CPU: 7 PID: 1442 at net/core/xdp.c:405
  Modules linked in:
  CPU: 7 PID: 1442 Comm: kworker/7:0 Tainted: G  6.5.0-rc2+ #1
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
  Workqueue: events __cpu_map_entry_free
  RIP: 0010:__xdp_return+0x1e4/0x4a0
  ......
  Call Trace:
   &lt;TASK&gt;
   ? show_regs+0x65/0x70
   ? __warn+0xa5/0x240
   ? __xdp_return+0x1e4/0x4a0
   ......
   xdp_return_frame+0x4d/0x150
   __cpu_map_entry_free+0xf9/0x230
   process_one_work+0x6b0/0xb80
   worker_thread+0x96/0x720
   kthread+0x1a5/0x1f0
   ret_from_fork+0x3a/0x70
   ret_from_fork_asm+0x1b/0x30
   &lt;/TASK&gt;

The reason for the warning is twofold. One is due to the kthread
cpu_map_kthread_run() is stopped prematurely. Another one is
__cpu_map_ring_cleanup() doesn't handle skb mode and treats skbs in
ptr_ring as XDP frames.

Prematurely-stopped kthread will be fixed by the preceding patch and
ptr_ring will be empty when __cpu_map_ring_cleanup() is called. But
as the comments in __cpu_map_ring_cleanup() said, handling and freeing
skbs in ptr_ring as well to "catch any broken behaviour gracefully".</Note>
    </Notes>
    <CVE>CVE-2023-53660</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 memory leaks in ext4_fname_{setup_filename,prepare_lookup}

If the filename casefolding fails, we'll be leaking memory from the
fscrypt_name struct, namely from the 'crypto_buf.name' member.

Make sure we free it in the error path on both ext4_fname_setup_filename()
and ext4_fname_prepare_lookup() functions.</Note>
    </Notes>
    <CVE>CVE-2023-53662</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

KVM: nSVM: Check instead of asserting on nested TSC scaling support

Check for nested TSC scaling support on nested SVM VMRUN instead of
asserting that TSC scaling is exposed to L1 if L1's MSR_AMD64_TSC_RATIO
has diverged from KVM's default.  Userspace can trigger the WARN at will
by writing the MSR and then updating guest CPUID to hide the feature
(modifying guest CPUID is allowed anytime before KVM_RUN).  E.g. hacking
KVM's state_test selftest to do

		vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0);
		vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR);

after restoring state in a new VM+vCPU yields an endless supply of:

  ------------[ cut here ]------------
  WARNING: CPU: 164 PID: 62565 at arch/x86/kvm/svm/nested.c:699
           nested_vmcb02_prepare_control+0x3d6/0x3f0 [kvm_amd]
  Call Trace:
   &lt;TASK&gt;
   enter_svm_guest_mode+0x114/0x560 [kvm_amd]
   nested_svm_vmrun+0x260/0x330 [kvm_amd]
   vmrun_interception+0x29/0x30 [kvm_amd]
   svm_invoke_exit_handler+0x35/0x100 [kvm_amd]
   svm_handle_exit+0xe7/0x180 [kvm_amd]
   kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm]
   kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm]
   __se_sys_ioctl+0x7a/0xc0
   __x64_sys_ioctl+0x21/0x30
   do_syscall_64+0x41/0x90
   entry_SYSCALL_64_after_hwframe+0x63/0xcd
  RIP: 0033:0x45ca1b

Note, the nested #VMEXIT path has the same flaw, but needs a different
fix and will be handled separately.</Note>
    </Notes>
    <CVE>CVE-2023-53663</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

md: don't dereference mddev after export_rdev()

Except for initial reference, mddev-&gt;kobject is referenced by
rdev-&gt;kobject, and if the last rdev is freed, there is no guarantee that
mddev is still valid. Hence mddev should not be used anymore after
export_rdev().

This problem can be triggered by following test for mdadm at very
low rate:

New file: mdadm/tests/23rdev-lifetime

devname=${dev0##*/}
devt=`cat /sys/block/$devname/dev`
pid=""
runtime=2

clean_up_test() {
        pill -9 $pid
        echo clear &gt; /sys/block/md0/md/array_state
}

trap 'clean_up_test' EXIT

add_by_sysfs() {
        while true; do
                echo $devt &gt; /sys/block/md0/md/new_dev
        done
}

remove_by_sysfs(){
        while true; do
                echo remove &gt; /sys/block/md0/md/dev-${devname}/state
        done
}

echo md0 &gt; /sys/module/md_mod/parameters/new_array || die "create md0 failed"

add_by_sysfs &amp;
pid="$pid $!"

remove_by_sysfs &amp;
pid="$pid $!"

sleep $runtime
exit 0

Test cmd:

./test --save-logs --logdir=/tmp/ --keep-going --dev=loop --tests=23rdev-lifetime

Test result:

general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bcb: 0000 [#4] PREEMPT SMP
CPU: 0 PID: 1292 Comm: test Tainted: G      D W          6.5.0-rc2-00121-g01e55c376936 #562
RIP: 0010:md_wakeup_thread+0x9e/0x320 [md_mod]
Call Trace:
 &lt;TASK&gt;
 mddev_unlock+0x1b6/0x310 [md_mod]
 rdev_attr_store+0xec/0x190 [md_mod]
 sysfs_kf_write+0x52/0x70
 kernfs_fop_write_iter+0x19a/0x2a0
 vfs_write+0x3b5/0x770
 ksys_write+0x74/0x150
 __x64_sys_write+0x22/0x30
 do_syscall_64+0x40/0x90
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Fix this problem by don't dereference mddev after export_rdev().</Note>
    </Notes>
    <CVE>CVE-2023-53665</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: codecs: wcd938x: fix missing mbhc init error handling

MBHC initialisation can fail so add the missing error handling to avoid
dereferencing an error pointer when later configuring the jack:

    Unable to handle kernel paging request at virtual address fffffffffffffff8

    pc : wcd_mbhc_start+0x28/0x380 [snd_soc_wcd_mbhc]
    lr : wcd938x_codec_set_jack+0x28/0x48 [snd_soc_wcd938x]

    Call trace:
     wcd_mbhc_start+0x28/0x380 [snd_soc_wcd_mbhc]
     wcd938x_codec_set_jack+0x28/0x48 [snd_soc_wcd938x]
     snd_soc_component_set_jack+0x28/0x8c [snd_soc_core]
     qcom_snd_wcd_jack_setup+0x7c/0x19c [snd_soc_qcom_common]
     sc8280xp_snd_init+0x20/0x2c [snd_soc_sc8280xp]
     snd_soc_link_init+0x28/0x90 [snd_soc_core]
     snd_soc_bind_card+0x628/0xbfc [snd_soc_core]
     snd_soc_register_card+0xec/0x104 [snd_soc_core]
     devm_snd_soc_register_card+0x4c/0xa4 [snd_soc_core]
     sc8280xp_platform_probe+0xf0/0x108 [snd_soc_sc8280xp]</Note>
    </Notes>
    <CVE>CVE-2023-53666</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ring-buffer: Fix deadloop issue on reading trace_pipe

Soft lockup occurs when reading file 'trace_pipe':

  watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [cat:4488]
  [...]
  RIP: 0010:ring_buffer_empty_cpu+0xed/0x170
  RSP: 0018:ffff88810dd6fc48 EFLAGS: 00000246
  RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff93d1aaeb
  RDX: ffff88810a280040 RSI: 0000000000000008 RDI: ffff88811164b218
  RBP: ffff88811164b218 R08: 0000000000000000 R09: ffff88815156600f
  R10: ffffed102a2acc01 R11: 0000000000000001 R12: 0000000051651901
  R13: 0000000000000000 R14: ffff888115e49500 R15: 0000000000000000
  [...]
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f8d853c2000 CR3: 000000010dcd8000 CR4: 00000000000006e0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  Call Trace:
   __find_next_entry+0x1a8/0x4b0
   ? peek_next_entry+0x250/0x250
   ? down_write+0xa5/0x120
   ? down_write_killable+0x130/0x130
   trace_find_next_entry_inc+0x3b/0x1d0
   tracing_read_pipe+0x423/0xae0
   ? tracing_splice_read_pipe+0xcb0/0xcb0
   vfs_read+0x16b/0x490
   ksys_read+0x105/0x210
   ? __ia32_sys_pwrite64+0x200/0x200
   ? switch_fpu_return+0x108/0x220
   do_syscall_64+0x33/0x40
   entry_SYSCALL_64_after_hwframe+0x61/0xc6

Through the vmcore, I found it's because in tracing_read_pipe(),
ring_buffer_empty_cpu() found some buffer is not empty but then it
cannot read anything due to "rb_num_of_entries() == 0" always true,
Then it infinitely loop the procedure due to user buffer not been
filled, see following code path:

  tracing_read_pipe() {
    ... ...
    waitagain:
      tracing_wait_pipe() // 1. find non-empty buffer here
      trace_find_next_entry_inc()  // 2. loop here try to find an entry
        __find_next_entry()
          ring_buffer_empty_cpu();  // 3. find non-empty buffer
          peek_next_entry()  // 4. but peek always return NULL
            ring_buffer_peek()
              rb_buffer_peek()
                rb_get_reader_page()
                  // 5. because rb_num_of_entries() == 0 always true here
                  //    then return NULL
      // 6. user buffer not been filled so goto 'waitgain'
      //    and eventually leads to an deadloop in kernel!!!
  }

By some analyzing, I found that when resetting ringbuffer, the 'entries'
of its pages are not all cleared (see rb_reset_cpu()). Then when reducing
the ringbuffer, and if some reduced pages exist dirty 'entries' data, they
will be added into 'cpu_buffer-&gt;overrun' (see rb_remove_pages()), which
cause wrong 'overrun' count and eventually cause the deadloop issue.

To fix it, we need to clear every pages in rb_reset_cpu().</Note>
    </Notes>
    <CVE>CVE-2023-53668</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-core: fix dev_pm_qos memleak

Call dev_pm_qos_hide_latency_tolerance() in the error unwind patch to
avoid following kmemleak:-

blktests (master) # kmemleak-clear; ./check nvme/044;
blktests (master) # kmemleak-scan ; kmemleak-show
nvme/044 (Test bi-directional authentication)                [passed]
    runtime  2.111s  ...  2.124s
unreferenced object 0xffff888110c46240 (size 96):
  comm "nvme", pid 33461, jiffies 4345365353 (age 75.586s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;0000000069ac2cec&gt;] kmalloc_trace+0x25/0x90
    [&lt;000000006acc66d5&gt;] dev_pm_qos_update_user_latency_tolerance+0x6f/0x100
    [&lt;00000000cc376ea7&gt;] nvme_init_ctrl+0x38e/0x410 [nvme_core]
    [&lt;000000007df61b4b&gt;] 0xffffffffc05e88b3
    [&lt;00000000d152b985&gt;] 0xffffffffc05744cb
    [&lt;00000000f04a4041&gt;] vfs_write+0xc5/0x3c0
    [&lt;00000000f9491baf&gt;] ksys_write+0x5f/0xe0
    [&lt;000000001c46513d&gt;] do_syscall_64+0x3b/0x90
    [&lt;00000000ecf348fe&gt;] entry_SYSCALL_64_after_hwframe+0x72/0xdc</Note>
    </Notes>
    <CVE>CVE-2023-53670</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: output extra debug info if we failed to find an inline backref

[BUG]
Syzbot reported several warning triggered inside
lookup_inline_extent_backref().

[CAUSE]
As usual, the reproducer doesn't reliably trigger locally here, but at
least we know the WARN_ON() is triggered when an inline backref can not
be found, and it can only be triggered when @insert is true. (I.e.
inserting a new inline backref, which means the backref should already
exist)

[ENHANCEMENT]
After the WARN_ON(), dump all the parameters and the extent tree
leaf to help debug.</Note>
    </Notes>
    <CVE>CVE-2023-53672</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_event: call disconnect callback before deleting conn

In hci_cs_disconnect, we do hci_conn_del even if disconnection failed.

ISO, L2CAP and SCO connections refer to the hci_conn without
hci_conn_get, so disconn_cfm must be called so they can clean up their
conn, otherwise use-after-free occurs.

ISO:
==========================================================
iso_sock_connect:880: sk 00000000eabd6557
iso_connect_cis:356: 70:1a:b8:98:ff:a2 -&gt; 28:3d:c2:4a:7e:da
...
iso_conn_add:140: hcon 000000001696f1fd conn 00000000b6251073
hci_dev_put:1487: hci0 orig refcnt 17
__iso_chan_add:214: conn 00000000b6251073
iso_sock_clear_timer:117: sock 00000000eabd6557 state 3
...
hci_rx_work:4085: hci0 Event packet
hci_event_packet:7601: hci0: event 0x0f
hci_cmd_status_evt:4346: hci0: opcode 0x0406
hci_cs_disconnect:2760: hci0: status 0x0c
hci_sent_cmd_data:3107: hci0 opcode 0x0406
hci_conn_del:1151: hci0 hcon 000000001696f1fd handle 2560
hci_conn_unlink:1102: hci0: hcon 000000001696f1fd
hci_conn_drop:1451: hcon 00000000d8521aaf orig refcnt 2
hci_chan_list_flush:2780: hcon 000000001696f1fd
hci_dev_put:1487: hci0 orig refcnt 21
hci_dev_put:1487: hci0 orig refcnt 20
hci_req_cmd_complete:3978: opcode 0x0406 status 0x0c
... &lt;no iso_* activity on sk/conn&gt; ...
iso_sock_sendmsg:1098: sock 00000000dea5e2e0, sk 00000000eabd6557
BUG: kernel NULL pointer dereference, address: 0000000000000668
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014
RIP: 0010:iso_sock_sendmsg (net/bluetooth/iso.c:1112) bluetooth
==========================================================

L2CAP:
==================================================================
hci_cmd_status_evt:4359: hci0: opcode 0x0406
hci_cs_disconnect:2760: hci0: status 0x0c
hci_sent_cmd_data:3085: hci0 opcode 0x0406
hci_conn_del:1151: hci0 hcon ffff88800c999000 handle 3585
hci_conn_unlink:1102: hci0: hcon ffff88800c999000
hci_chan_list_flush:2780: hcon ffff88800c999000
hci_chan_del:2761: hci0 hcon ffff88800c999000 chan ffff888018ddd280
...
BUG: KASAN: slab-use-after-free in hci_send_acl+0x2d/0x540 [bluetooth]
Read of size 8 at addr ffff888018ddd298 by task bluetoothd/1175

CPU: 0 PID: 1175 Comm: bluetoothd Tainted: G            E      6.4.0-rc4+ #2
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x5b/0x90
 print_report+0xcf/0x670
 ? __virt_addr_valid+0xf8/0x180
 ? hci_send_acl+0x2d/0x540 [bluetooth]
 kasan_report+0xa8/0xe0
 ? hci_send_acl+0x2d/0x540 [bluetooth]
 hci_send_acl+0x2d/0x540 [bluetooth]
 ? __pfx___lock_acquire+0x10/0x10
 l2cap_chan_send+0x1fd/0x1300 [bluetooth]
 ? l2cap_sock_sendmsg+0xf2/0x170 [bluetooth]
 ? __pfx_l2cap_chan_send+0x10/0x10 [bluetooth]
 ? lock_release+0x1d5/0x3c0
 ? mark_held_locks+0x1a/0x90
 l2cap_sock_sendmsg+0x100/0x170 [bluetooth]
 sock_write_iter+0x275/0x280
 ? __pfx_sock_write_iter+0x10/0x10
 ? __pfx___lock_acquire+0x10/0x10
 do_iter_readv_writev+0x176/0x220
 ? __pfx_do_iter_readv_writev+0x10/0x10
 ? find_held_lock+0x83/0xa0
 ? selinux_file_permission+0x13e/0x210
 do_iter_write+0xda/0x340
 vfs_writev+0x1b4/0x400
 ? __pfx_vfs_writev+0x10/0x10
 ? __seccomp_filter+0x112/0x750
 ? populate_seccomp_data+0x182/0x220
 ? __fget_light+0xdf/0x100
 ? do_writev+0x19d/0x210
 do_writev+0x19d/0x210
 ? __pfx_do_writev+0x10/0x10
 ? mark_held_locks+0x1a/0x90
 do_syscall_64+0x60/0x90
 ? lockdep_hardirqs_on_prepare+0x149/0x210
 ? do_syscall_64+0x6c/0x90
 ? lockdep_hardirqs_on_prepare+0x149/0x210
 entry_SYSCALL_64_after_hwframe+0x72/0xdc
RIP: 0033:0x7ff45cb23e64
Code: 15 d1 1f 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 9d a7 0d 00 00 74 13 b8 14 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89
RSP: 002b:00007fff21ae09b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53673</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

clk: Fix memory leak in devm_clk_notifier_register()

devm_clk_notifier_register() allocates a devres resource for clk
notifier but didn't register that to the device, so the notifier didn't
get unregistered on device detach and the allocated resource was leaked.

Fix the issue by registering the resource through devres_add().

This issue was found with kmemleak on a Chromebook.</Note>
    </Notes>
    <CVE>CVE-2023-53674</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bcache: Fix __bch_btree_node_alloc to make the failure behavior consistent

In some specific situations, the return value of __bch_btree_node_alloc
may be NULL. This may lead to a potential NULL pointer dereference in
caller function like a calling chain :
btree_split-&gt;bch_btree_node_alloc-&gt;__bch_btree_node_alloc.

Fix it by initializing the return value in __bch_btree_node_alloc.</Note>
    </Notes>
    <CVE>CVE-2023-53681</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/handshake: fix null-ptr-deref in handshake_nl_done_doit()

We should not call trace_handshake_cmd_done_err() if socket lookup has failed.

Also we should call trace_handshake_cmd_done_err() before releasing the file,
otherwise dereferencing sock-&gt;sk can return garbage.

This also reverts 7afc6d0a107f ("net/handshake: Fix uninitialized local variable")

Unable to handle kernel paging request at virtual address dfff800000000003
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
Mem abort info:
ESR = 0x0000000096000005
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x05: level 1 translation fault
Data abort info:
ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
CM = 0, WnR = 0, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[dfff800000000003] address between user and kernel address ranges
Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 5986 Comm: syz-executor292 Not tainted 6.5.0-rc7-syzkaller-gfe4469582053 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : handshake_nl_done_doit+0x198/0x9c8 net/handshake/netlink.c:193
lr : handshake_nl_done_doit+0x180/0x9c8
sp : ffff800096e37180
x29: ffff800096e37200 x28: 1ffff00012dc6e34 x27: dfff800000000000
x26: ffff800096e373d0 x25: 0000000000000000 x24: 00000000ffffffa8
x23: ffff800096e373f0 x22: 1ffff00012dc6e38 x21: 0000000000000000
x20: ffff800096e371c0 x19: 0000000000000018 x18: 0000000000000000
x17: 0000000000000000 x16: ffff800080516cc4 x15: 0000000000000001
x14: 1fffe0001b14aa3b x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000003
x8 : 0000000000000003 x7 : ffff800080afe47c x6 : 0000000000000000
x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff800080a88078
x2 : 0000000000000001 x1 : 00000000ffffffa8 x0 : 0000000000000000
Call trace:
handshake_nl_done_doit+0x198/0x9c8 net/handshake/netlink.c:193
genl_family_rcv_msg_doit net/netlink/genetlink.c:970 [inline]
genl_family_rcv_msg net/netlink/genetlink.c:1050 [inline]
genl_rcv_msg+0x96c/0xc50 net/netlink/genetlink.c:1067
netlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2549
genl_rcv+0x38/0x50 net/netlink/genetlink.c:1078
netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
netlink_unicast+0x660/0x8d4 net/netlink/af_netlink.c:1365
netlink_sendmsg+0x834/0xb18 net/netlink/af_netlink.c:1914
sock_sendmsg_nosec net/socket.c:725 [inline]
sock_sendmsg net/socket.c:748 [inline]
____sys_sendmsg+0x56c/0x840 net/socket.c:2494
___sys_sendmsg net/socket.c:2548 [inline]
__sys_sendmsg+0x26c/0x33c net/socket.c:2577
__do_sys_sendmsg net/socket.c:2586 [inline]
__se_sys_sendmsg net/socket.c:2584 [inline]
__arm64_sys_sendmsg+0x80/0x94 net/socket.c:2584
__invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]
invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155
el0_svc+0x58/0x16c arch/arm64/kernel/entry-common.c:678
el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591
Code: 12800108 b90043e8 910062b3 d343fe68 (387b6908)</Note>
    </Notes>
    <CVE>CVE-2023-53686</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() when iterating clk

When the best clk is searched, we iterate over all possible clk.

If we find a better match, the previous one, if any, needs to be freed.
If a better match has already been found, we still need to free the new
one, otherwise it leaks.</Note>
    </Notes>
    <CVE>CVE-2023-53687</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

USB: gadget: Fix the memory leak in raw_gadget driver

Currently, increasing raw_dev-&gt;count happens before invoke the
raw_queue_event(), if the raw_queue_event() return error, invoke
raw_release() will not trigger the dev_free() to be called.

[  268.905865][ T5067] raw-gadget.0 gadget.0: failed to queue event
[  268.912053][ T5067] udc dummy_udc.0: failed to start USB Raw Gadget: -12
[  268.918885][ T5067] raw-gadget.0: probe of gadget.0 failed with error -12
[  268.925956][ T5067] UDC core: USB Raw Gadget: couldn't find an available UDC or it's busy
[  268.934657][ T5067] misc raw-gadget: fail, usb_gadget_register_driver returned -16

BUG: memory leak

[&lt;ffffffff8154bf94&gt;] kmalloc_trace+0x24/0x90 mm/slab_common.c:1076
[&lt;ffffffff8347eb55&gt;] kmalloc include/linux/slab.h:582 [inline]
[&lt;ffffffff8347eb55&gt;] kzalloc include/linux/slab.h:703 [inline]
[&lt;ffffffff8347eb55&gt;] dev_new drivers/usb/gadget/legacy/raw_gadget.c:191 [inline]
[&lt;ffffffff8347eb55&gt;] raw_open+0x45/0x110 drivers/usb/gadget/legacy/raw_gadget.c:385
[&lt;ffffffff827d1d09&gt;] misc_open+0x1a9/0x1f0 drivers/char/misc.c:165

[&lt;ffffffff8154bf94&gt;] kmalloc_trace+0x24/0x90 mm/slab_common.c:1076
[&lt;ffffffff8347cd2f&gt;] kmalloc include/linux/slab.h:582 [inline]
[&lt;ffffffff8347cd2f&gt;] raw_ioctl_init+0xdf/0x410 drivers/usb/gadget/legacy/raw_gadget.c:460
[&lt;ffffffff8347dfe9&gt;] raw_ioctl+0x5f9/0x1120 drivers/usb/gadget/legacy/raw_gadget.c:1250
[&lt;ffffffff81685173&gt;] vfs_ioctl fs/ioctl.c:51 [inline]

[&lt;ffffffff8154bf94&gt;] kmalloc_trace+0x24/0x90 mm/slab_common.c:1076
[&lt;ffffffff833ecc6a&gt;] kmalloc include/linux/slab.h:582 [inline]
[&lt;ffffffff833ecc6a&gt;] kzalloc include/linux/slab.h:703 [inline]
[&lt;ffffffff833ecc6a&gt;] dummy_alloc_request+0x5a/0xe0 drivers/usb/gadget/udc/dummy_hcd.c:665
[&lt;ffffffff833e9132&gt;] usb_ep_alloc_request+0x22/0xd0 drivers/usb/gadget/udc/core.c:196
[&lt;ffffffff8347f13d&gt;] gadget_bind+0x6d/0x370 drivers/usb/gadget/legacy/raw_gadget.c:292

This commit therefore invoke kref_get() under the condition that
raw_queue_event() return success.</Note>
    </Notes>
    <CVE>CVE-2023-53693</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nvdimm: Fix memleak of pmu attr_groups in unregister_nvdimm_pmu()

Memory pointed by 'nd_pmu-&gt;pmu.attr_groups' is allocated in function
'register_nvdimm_pmu' and is lost after 'kfree(nd_pmu)' call in function
'unregister_nvdimm_pmu'.</Note>
    </Notes>
    <CVE>CVE-2023-53697</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xsk: fix refcount underflow in error path

Fix a refcount underflow problem reported by syzbot that can happen
when a system is running out of memory. If xp_alloc_tx_descs() fails,
and it can only fail due to not having enough memory, then the error
path is triggered. In this error path, the refcount of the pool is
decremented as it has incremented before. However, the reference to
the pool in the socket was not nulled. This means that when the socket
is closed later, the socket teardown logic will think that there is a
pool attached to the socket and try to decrease the refcount again,
leading to a refcount underflow.

I chose this fix as it involved adding just a single line. Another
option would have been to move xp_get_pool() and the assignment of
xs-&gt;pool to after the if-statement and using xs_umem-&gt;pool instead of
xs-&gt;pool in the whole if-statement resulting in somewhat simpler code,
but this would have led to much more churn in the code base perhaps
making it harder to backport.</Note>
    </Notes>
    <CVE>CVE-2023-53698</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

riscv: move memblock_allow_resize() after linear mapping is ready

The initial memblock metadata is accessed from kernel image mapping. The
regions arrays need to "reallocated" from memblock and accessed through
linear mapping to cover more memblock regions. So the resizing should
not be allowed until linear mapping is ready. Note that there are
memblock allocations when building linear mapping.

This patch is similar to 24cc61d8cb5a ("arm64: memblock: don't permit
memblock resizing until linear mapping is up").

In following log, many memblock regions are reserved before
create_linear_mapping_page_table(). And then it triggered reallocation
of memblock.reserved.regions and memcpy the old array in kernel image
mapping to the new array in linear mapping which caused a page fault.

[    0.000000] memblock_reserve: [0x00000000bf01f000-0x00000000bf01ffff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6
[    0.000000] memblock_reserve: [0x00000000bf021000-0x00000000bf021fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6
[    0.000000] memblock_reserve: [0x00000000bf023000-0x00000000bf023fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6
[    0.000000] memblock_reserve: [0x00000000bf025000-0x00000000bf025fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6
[    0.000000] memblock_reserve: [0x00000000bf027000-0x00000000bf027fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6
[    0.000000] memblock_reserve: [0x00000000bf029000-0x00000000bf029fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6
[    0.000000] memblock_reserve: [0x00000000bf02b000-0x00000000bf02bfff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6
[    0.000000] memblock_reserve: [0x00000000bf02d000-0x00000000bf02dfff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6
[    0.000000] memblock_reserve: [0x00000000bf02f000-0x00000000bf02ffff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6
[    0.000000] memblock_reserve: [0x00000000bf030000-0x00000000bf030fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6
[    0.000000] OF: reserved mem: 0x0000000080000000..0x000000008007ffff (512 KiB) map non-reusable mmode_resv0@80000000
[    0.000000] memblock_reserve: [0x00000000bf000000-0x00000000bf001fed] paging_init+0x19a/0x5ae
[    0.000000] memblock_phys_alloc_range: 4096 bytes align=0x1000 from=0x0000000000000000 max_addr=0x0000000000000000 alloc_pmd_fixmap+0x14/0x1c
[    0.000000] memblock_reserve: [0x000000017ffff000-0x000000017fffffff] memblock_alloc_range_nid+0xb8/0x128
[    0.000000] memblock: reserved is doubled to 256 at [0x000000017fffd000-0x000000017fffe7ff]
[    0.000000] Unable to handle kernel paging request at virtual address ff600000ffffd000
[    0.000000] Oops [#1]
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.4.0-rc1-00011-g99a670b2069c #66
[    0.000000] Hardware name: riscv-virtio,qemu (DT)
[    0.000000] epc : __memcpy+0x60/0xf8
[    0.000000]  ra : memblock_double_array+0x192/0x248
[    0.000000] epc : ffffffff8081d214 ra : ffffffff80a3dfc0 sp : ffffffff81403bd0
[    0.000000]  gp : ffffffff814fbb38 tp : ffffffff8140dac0 t0 : 0000000001600000
[    0.000000]  t1 : 0000000000000000 t2 : 000000008f001000 s0 : ffffffff81403c60
[    0.000000]  s1 : ffffffff80c0bc98 a0 : ff600000ffffd000 a1 : ffffffff80c0bcd8
[    0.000000]  a2 : 0000000000000c00 a3 : ffffffff80c0c8d8 a4 : 0000000080000000
[    0.000000]  a5 : 0000000000080000 a6 : 0000000000000000 a7 : 0000000080200000
[    0.000000]  s2 : ff600000ffffd000 s3 : 0000000000002000 s4 : 0000000000000c00
[    0.000000]  s5 : ffffffff80c0bc60 s6 : ffffffff80c0bcc8 s7 : 0000000000000000
[    0.000000]  s8 : ffffffff814fd0a8 s9 : 000000017fffe7ff s10: 0000000000000000
[    0.000000]  s11: 0000000000001000 t3 : 0000000000001000 t4 : 0000000000000000
[    0.000000]  t5 : 000000008f003000 t6 : ff600000ffffd000
[    0.000000] status: 0000000200000100 badaddr: ff600000ffffd000 cause: 000000000000000f
[    0.000000] [&lt;fff
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53699</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: amd_sfh: Fix for shift-out-of-bounds

Shift operation of 'exp' and 'shift' variables exceeds the maximum number
of shift values in the u32 range leading to UBSAN shift-out-of-bounds.

...
[    6.120512] UBSAN: shift-out-of-bounds in drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c:149:50
[    6.120598] shift exponent 104 is too large for 64-bit type 'long unsigned int'
[    6.120659] CPU: 4 PID: 96 Comm: kworker/4:1 Not tainted 6.4.0amd_1-next-20230519-dirty #10
[    6.120665] Hardware name: AMD Birman-PHX/Birman-PHX, BIOS SFH_with_HPD_SEN.FD 04/05/2023
[    6.120667] Workqueue: events amd_sfh_work_buffer [amd_sfh]
[    6.120687] Call Trace:
[    6.120690]  &lt;TASK&gt;
[    6.120694]  dump_stack_lvl+0x48/0x70
[    6.120704]  dump_stack+0x10/0x20
[    6.120707]  ubsan_epilogue+0x9/0x40
[    6.120716]  __ubsan_handle_shift_out_of_bounds+0x10f/0x170
[    6.120720]  ? psi_group_change+0x25f/0x4b0
[    6.120729]  float_to_int.cold+0x18/0xba [amd_sfh]
[    6.120739]  get_input_rep+0x57/0x340 [amd_sfh]
[    6.120748]  ? __schedule+0xba7/0x1b60
[    6.120756]  ? __pfx_get_input_rep+0x10/0x10 [amd_sfh]
[    6.120764]  amd_sfh_work_buffer+0x91/0x180 [amd_sfh]
[    6.120772]  process_one_work+0x229/0x430
[    6.120780]  worker_thread+0x4a/0x3c0
[    6.120784]  ? __pfx_worker_thread+0x10/0x10
[    6.120788]  kthread+0xf7/0x130
[    6.120792]  ? __pfx_kthread+0x10/0x10
[    6.120795]  ret_from_fork+0x29/0x50
[    6.120804]  &lt;/TASK&gt;
...

Fix this by adding the condition to validate shift ranges.</Note>
    </Notes>
    <CVE>CVE-2023-53703</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: imx: clk-imx8mp: improve error handling in imx8mp_clocks_probe()

Replace of_iomap() and kzalloc() with devm_of_iomap() and devm_kzalloc()
which can automatically release the related memory when the device
or driver is removed or unloaded to avoid potential memory leak.

In this case, iounmap(anatop_base) in line 427,433 are removed
as manual release is not required.

Besides, referring to clk-imx8mq.c, check the return code of
of_clk_add_hw_provider, if it returns negtive, print error info
and unregister hws, which makes the program more robust.</Note>
    </Notes>
    <CVE>CVE-2023-53704</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1

The type of size is unsigned int, if size is 0x40000000, there will
be an integer overflow, size will be zero after size *= sizeof(uint32_t),
will cause uninitialized memory to be referenced later.</Note>
    </Notes>
    <CVE>CVE-2023-53707</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: x86: s2idle: Catch multiple ACPI_TYPE_PACKAGE objects

If a badly constructed firmware includes multiple `ACPI_TYPE_PACKAGE`
objects while evaluating the AMD LPS0 _DSM, there will be a memory
leak.  Explicitly guard against this.</Note>
    </Notes>
    <CVE>CVE-2023-53708</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

NFS: Fix a potential data corruption

We must ensure that the subrequests are joined back into the head before
we can retransmit a request. If the head was not on the commit lists,
because the server wrote it synchronously, we still need to add it back
to the retransmission list.
Add a call that mirrors the effect of nfs_cancel_remove_inode() for
O_DIRECT.</Note>
    </Notes>
    <CVE>CVE-2023-53711</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sme: Use STR P to clear FFR context field in streaming SVE mode

The FFR is a predicate register which can vary between 16 and 256 bits
in size depending upon the configured vector length. When saving the
SVE state in streaming SVE mode, the FFR register is inaccessible and
so commit 9f5848665788 ("arm64/sve: Make access to FFR optional") simply
clears the FFR field of the in-memory context structure. Unfortunately,
it achieves this using an unconditional 8-byte store and so if the SME
vector length is anything other than 64 bytes in size we will either
fail to clear the entire field or, worse, we will corrupt memory
immediately following the structure. This has led to intermittent kfence
splats in CI [1] and can trigger kmalloc Redzone corruption messages
when running the 'fp-stress' kselftest:

 | =============================================================================
 | BUG kmalloc-1k (Not tainted): kmalloc Redzone overwritten
 | -----------------------------------------------------------------------------
 |
 | 0xffff000809bf1e22-0xffff000809bf1e27 @offset=7714. First byte 0x0 instead of 0xcc
 | Allocated in do_sme_acc+0x9c/0x220 age=2613 cpu=1 pid=531
 |  __kmalloc+0x8c/0xcc
 |  do_sme_acc+0x9c/0x220
 |  ...

Replace the 8-byte store with a store of a predicate register which has
been zero-initialised with PFALSE, ensuring that the entire field is
cleared in memory.

[1] https://lore.kernel.org/r/CA+G9fYtU7HsV0R0dp4XEH5xXHSJFw8KyDf5VQrLLfMxWfxQkag@mail.gmail.com</Note>
    </Notes>
    <CVE>CVE-2023-53713</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ring-buffer: Do not swap cpu_buffer during resize process

When ring_buffer_swap_cpu was called during resize process,
the cpu buffer was swapped in the middle, resulting in incorrect state.
Continuing to run in the wrong state will result in oops.

This issue can be easily reproduced using the following two scripts:
/tmp # cat test1.sh
//#! /bin/sh
for i in `seq 0 100000`
do
         echo 2000 &gt; /sys/kernel/debug/tracing/buffer_size_kb
         sleep 0.5
         echo 5000 &gt; /sys/kernel/debug/tracing/buffer_size_kb
         sleep 0.5
done
/tmp # cat test2.sh
//#! /bin/sh
for i in `seq 0 100000`
do
        echo irqsoff &gt; /sys/kernel/debug/tracing/current_tracer
        sleep 1
        echo nop &gt; /sys/kernel/debug/tracing/current_tracer
        sleep 1
done
/tmp # ./test1.sh &amp;
/tmp # ./test2.sh &amp;

A typical oops log is as follows, sometimes with other different oops logs.

[  231.711293] WARNING: CPU: 0 PID: 9 at kernel/trace/ring_buffer.c:2026 rb_update_pages+0x378/0x3f8
[  231.713375] Modules linked in:
[  231.714735] CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G        W          6.5.0-rc1-00276-g20edcec23f92 #15
[  231.716750] Hardware name: linux,dummy-virt (DT)
[  231.718152] Workqueue: events update_pages_handler
[  231.719714] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  231.721171] pc : rb_update_pages+0x378/0x3f8
[  231.722212] lr : rb_update_pages+0x25c/0x3f8
[  231.723248] sp : ffff800082b9bd50
[  231.724169] x29: ffff800082b9bd50 x28: ffff8000825f7000 x27: 0000000000000000
[  231.726102] x26: 0000000000000001 x25: fffffffffffff010 x24: 0000000000000ff0
[  231.728122] x23: ffff0000c3a0b600 x22: ffff0000c3a0b5c0 x21: fffffffffffffe0a
[  231.730203] x20: ffff0000c3a0b600 x19: ffff0000c0102400 x18: 0000000000000000
[  231.732329] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffe7aa8510
[  231.734212] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000002
[  231.736291] x11: ffff8000826998a8 x10: ffff800082b9baf0 x9 : ffff800081137558
[  231.738195] x8 : fffffc00030e82c8 x7 : 0000000000000000 x6 : 0000000000000001
[  231.740192] x5 : ffff0000ffbafe00 x4 : 0000000000000000 x3 : 0000000000000000
[  231.742118] x2 : 00000000000006aa x1 : 0000000000000001 x0 : ffff0000c0007208
[  231.744196] Call trace:
[  231.744892]  rb_update_pages+0x378/0x3f8
[  231.745893]  update_pages_handler+0x1c/0x38
[  231.746893]  process_one_work+0x1f0/0x468
[  231.747852]  worker_thread+0x54/0x410
[  231.748737]  kthread+0x124/0x138
[  231.749549]  ret_from_fork+0x10/0x20
[  231.750434] ---[ end trace 0000000000000000 ]---
[  233.720486] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[  233.721696] Mem abort info:
[  233.721935]   ESR = 0x0000000096000004
[  233.722283]   EC = 0x25: DABT (current EL), IL = 32 bits
[  233.722596]   SET = 0, FnV = 0
[  233.722805]   EA = 0, S1PTW = 0
[  233.723026]   FSC = 0x04: level 0 translation fault
[  233.723458] Data abort info:
[  233.723734]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[  233.724176]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[  233.724589]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[  233.725075] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000104943000
[  233.725592] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
[  233.726231] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
[  233.726720] Modules linked in:
[  233.727007] CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G        W          6.5.0-rc1-00276-g20edcec23f92 #15
[  233.727777] Hardware name: linux,dummy-virt (DT)
[  233.728225] Workqueue: events update_pages_handler
[  233.728655] pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  233.729054] pc : rb_update_pages+0x1a8/0x3f8
[  233.729334] lr : rb_update_pages+0x154/0x3f8
[  233.729592] sp : ffff800082b9bd50
[  233.729792] x29: ffff800082b9bd50 x28: ffff8000825f7000 x27: 00000000
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-53718</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: Fix a NULL pointer dereference in ath12k_mac_op_hw_scan()

In ath12k_mac_op_hw_scan(), the return value of kzalloc() is directly
used in memcpy(), which may lead to a NULL pointer dereference on
failure of kzalloc().

Fix this bug by adding a check of arg.extraie.ptr.

Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4</Note>
    </Notes>
    <CVE>CVE-2023-53721</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

md: raid1: fix potential OOB in raid1_remove_disk()

If rddev-&gt;raid_disk is greater than mddev-&gt;raid_disks, there will be
an out-of-bounds in raid1_remove_disk(). We have already found
similar reports as follows:

1) commit d17f744e883b ("md-raid10: fix KASAN warning")
2) commit 1ebc2cec0b7d ("dm raid: fix KASAN warning in raid5_remove_disk")

Fix this bug by checking whether the "number" variable is
valid.</Note>
    </Notes>
    <CVE>CVE-2023-53722</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

clocksource/drivers/cadence-ttc: Fix memory leak in ttc_timer_probe

Smatch reports:
drivers/clocksource/timer-cadence-ttc.c:529 ttc_timer_probe()
warn: 'timer_baseaddr' from of_iomap() not released on lines: 498,508,516.

timer_baseaddr may have the problem of not being released after use,
I replaced it with the devm_of_iomap() function and added the clk_put()
function to cleanup the "clk_ce" and "clk_cs".</Note>
    </Notes>
    <CVE>CVE-2023-53725</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

arm64: csum: Fix OoB access in IP checksum code for negative lengths

Although commit c2c24edb1d9c ("arm64: csum: Fix pathological zero-length
calls") added an early return for zero-length input, syzkaller has
popped up with an example of a _negative_ length which causes an
undefined shift and an out-of-bounds read:

 | BUG: KASAN: slab-out-of-bounds in do_csum+0x44/0x254 arch/arm64/lib/csum.c:39
 | Read of size 4294966928 at addr ffff0000d7ac0170 by task syz-executor412/5975
 |
 | CPU: 0 PID: 5975 Comm: syz-executor412 Not tainted 6.4.0-rc4-syzkaller-g908f31f2a05b #0
 | Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023
 | Call trace:
 |  dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:233
 |  show_stack+0x2c/0x44 arch/arm64/kernel/stacktrace.c:240
 |  __dump_stack lib/dump_stack.c:88 [inline]
 |  dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106
 |  print_address_description mm/kasan/report.c:351 [inline]
 |  print_report+0x174/0x514 mm/kasan/report.c:462
 |  kasan_report+0xd4/0x130 mm/kasan/report.c:572
 |  kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:187
 |  __kasan_check_read+0x20/0x30 mm/kasan/shadow.c:31
 |  do_csum+0x44/0x254 arch/arm64/lib/csum.c:39
 |  csum_partial+0x30/0x58 lib/checksum.c:128
 |  gso_make_checksum include/linux/skbuff.h:4928 [inline]
 |  __udp_gso_segment+0xaf4/0x1bc4 net/ipv4/udp_offload.c:332
 |  udp6_ufo_fragment+0x540/0xca0 net/ipv6/udp_offload.c:47
 |  ipv6_gso_segment+0x5cc/0x1760 net/ipv6/ip6_offload.c:119
 |  skb_mac_gso_segment+0x2b4/0x5b0 net/core/gro.c:141
 |  __skb_gso_segment+0x250/0x3d0 net/core/dev.c:3401
 |  skb_gso_segment include/linux/netdevice.h:4859 [inline]
 |  validate_xmit_skb+0x364/0xdbc net/core/dev.c:3659
 |  validate_xmit_skb_list+0x94/0x130 net/core/dev.c:3709
 |  sch_direct_xmit+0xe8/0x548 net/sched/sch_generic.c:327
 |  __dev_xmit_skb net/core/dev.c:3805 [inline]
 |  __dev_queue_xmit+0x147c/0x3318 net/core/dev.c:4210
 |  dev_queue_xmit include/linux/netdevice.h:3085 [inline]
 |  packet_xmit+0x6c/0x318 net/packet/af_packet.c:276
 |  packet_snd net/packet/af_packet.c:3081 [inline]
 |  packet_sendmsg+0x376c/0x4c98 net/packet/af_packet.c:3113
 |  sock_sendmsg_nosec net/socket.c:724 [inline]
 |  sock_sendmsg net/socket.c:747 [inline]
 |  __sys_sendto+0x3b4/0x538 net/socket.c:2144

Extend the early return to reject negative lengths as well, aligning our
implementation with the generic code in lib/checksum.c</Note>
    </Notes>
    <CVE>CVE-2023-53726</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fq_pie: avoid stalls in fq_pie_timer()

When setting a high number of flows (limit being 65536),
fq_pie_timer() is currently using too much time as syzbot reported.

Add logic to yield the cpu every 2048 flows (less than 150 usec
on debug kernels).
It should also help by not blocking qdisc fast paths for too long.
Worst case (65536 flows) would need 31 jiffies for a complete scan.

Relevant extract from syzbot report:

rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 0-.... } 2663 jiffies s: 873 root: 0x1/.
rcu: blocking rcu_node structures (internal RCU debug):
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0
CPU: 0 PID: 5177 Comm: syz-executor273 Not tainted 6.5.0-syzkaller-00453-g727dbda16b83 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023
RIP: 0010:check_kcov_mode kernel/kcov.c:173 [inline]
RIP: 0010:write_comp_data+0x21/0x90 kernel/kcov.c:236
Code: 2e 0f 1f 84 00 00 00 00 00 65 8b 05 01 b2 7d 7e 49 89 f1 89 c6 49 89 d2 81 e6 00 01 00 00 49 89 f8 65 48 8b 14 25 80 b9 03 00 &lt;a9&gt; 00 01 ff 00 74 0e 85 f6 74 59 8b 82 04 16 00 00 85 c0 74 4f 8b
RSP: 0018:ffffc90000007bb8 EFLAGS: 00000206
RAX: 0000000000000101 RBX: ffffc9000dc0d140 RCX: ffffffff885893b0
RDX: ffff88807c075940 RSI: 0000000000000100 RDI: 0000000000000001
RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffc9000dc0d178
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  0000555555d54380(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f6b442f6130 CR3: 000000006fe1c000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;NMI&gt;
 &lt;/NMI&gt;
 &lt;IRQ&gt;
 pie_calculate_probability+0x480/0x850 net/sched/sch_pie.c:415
 fq_pie_timer+0x1da/0x4f0 net/sched/sch_fq_pie.c:387
 call_timer_fn+0x1a0/0x580 kernel/time/timer.c:1700</Note>
    </Notes>
    <CVE>CVE-2023-53727</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

posix-timers: Ensure timer ID search-loop limit is valid

posix_timer_add() tries to allocate a posix timer ID by starting from the
cached ID which was stored by the last successful allocation.

This is done in a loop searching the ID space for a free slot one by
one. The loop has to terminate when the search wrapped around to the
starting point.

But that's racy vs. establishing the starting point. That is read out
lockless, which leads to the following problem:

CPU0	  	      	     	   CPU1
posix_timer_add()
  start = sig-&gt;posix_timer_id;
  lock(hash_lock);
  ...				   posix_timer_add()
  if (++sig-&gt;posix_timer_id &lt; 0)
      			             start = sig-&gt;posix_timer_id;
     sig-&gt;posix_timer_id = 0;

So CPU1 can observe a negative start value, i.e. -1, and the loop break
never happens because the condition can never be true:

  if (sig-&gt;posix_timer_id == start)
     break;

While this is unlikely to ever turn into an endless loop as the ID space is
huge (INT_MAX), the racy read of the start value caught the attention of
KCSAN and Dmitry unearthed that incorrectness.

Rewrite it so that all id operations are under the hash lock.</Note>
    </Notes>
    <CVE>CVE-2023-53728</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qmi_encdec: Restrict string length in decode

The QMI TLV value for strings in a lot of qmi element info structures
account for null terminated strings with MAX_LEN + 1. If a string is
actually MAX_LEN + 1 length, this will cause an out of bounds access
when the NULL character is appended in decoding.</Note>
    </Notes>
    <CVE>CVE-2023-53729</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-iocost: use spin_lock_irqsave in adjust_inuse_and_calc_cost

adjust_inuse_and_calc_cost() use spin_lock_irq() and IRQ will be enabled
when unlock. DEADLOCK might happen if we have held other locks and disabled
IRQ before invoking it.

Fix it by using spin_lock_irqsave() instead, which can keep IRQ state
consistent with before when unlock.

  ================================
  WARNING: inconsistent lock state
  5.10.0-02758-g8e5f91fd772f #26 Not tainted
  --------------------------------
  inconsistent {IN-HARDIRQ-W} -&gt; {HARDIRQ-ON-W} usage.
  kworker/2:3/388 [HC0[0]:SC0[0]:HE0:SE1] takes:
  ffff888118c00c28 (&amp;bfqd-&gt;lock){?.-.}-{2:2}, at: spin_lock_irq
  ffff888118c00c28 (&amp;bfqd-&gt;lock){?.-.}-{2:2}, at: bfq_bio_merge+0x141/0x390
  {IN-HARDIRQ-W} state was registered at:
    __lock_acquire+0x3d7/0x1070
    lock_acquire+0x197/0x4a0
    __raw_spin_lock_irqsave
    _raw_spin_lock_irqsave+0x3b/0x60
    bfq_idle_slice_timer_body
    bfq_idle_slice_timer+0x53/0x1d0
    __run_hrtimer+0x477/0xa70
    __hrtimer_run_queues+0x1c6/0x2d0
    hrtimer_interrupt+0x302/0x9e0
    local_apic_timer_interrupt
    __sysvec_apic_timer_interrupt+0xfd/0x420
    run_sysvec_on_irqstack_cond
    sysvec_apic_timer_interrupt+0x46/0xa0
    asm_sysvec_apic_timer_interrupt+0x12/0x20
  irq event stamp: 837522
  hardirqs last  enabled at (837521): [&lt;ffffffff84b9419d&gt;] __raw_spin_unlock_irqrestore
  hardirqs last  enabled at (837521): [&lt;ffffffff84b9419d&gt;] _raw_spin_unlock_irqrestore+0x3d/0x40
  hardirqs last disabled at (837522): [&lt;ffffffff84b93fa3&gt;] __raw_spin_lock_irq
  hardirqs last disabled at (837522): [&lt;ffffffff84b93fa3&gt;] _raw_spin_lock_irq+0x43/0x50
  softirqs last  enabled at (835852): [&lt;ffffffff84e00558&gt;] __do_softirq+0x558/0x8ec
  softirqs last disabled at (835845): [&lt;ffffffff84c010ff&gt;] asm_call_irq_on_stack+0xf/0x20

  other info that might help us debug this:
   Possible unsafe locking scenario:

         CPU0
         ----
    lock(&amp;bfqd-&gt;lock);
    &lt;Interrupt&gt;
      lock(&amp;bfqd-&gt;lock);

   *** DEADLOCK ***

  3 locks held by kworker/2:3/388:
   #0: ffff888107af0f38 ((wq_completion)kthrotld){+.+.}-{0:0}, at: process_one_work+0x742/0x13f0
   #1: ffff8881176bfdd8 ((work_completion)(&amp;td-&gt;dispatch_work)){+.+.}-{0:0}, at: process_one_work+0x777/0x13f0
   #2: ffff888118c00c28 (&amp;bfqd-&gt;lock){?.-.}-{2:2}, at: spin_lock_irq
   #2: ffff888118c00c28 (&amp;bfqd-&gt;lock){?.-.}-{2:2}, at: bfq_bio_merge+0x141/0x390

  stack backtrace:
  CPU: 2 PID: 388 Comm: kworker/2:3 Not tainted 5.10.0-02758-g8e5f91fd772f #26
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
  Workqueue: kthrotld blk_throtl_dispatch_work_fn
  Call Trace:
   __dump_stack lib/dump_stack.c:77 [inline]
   dump_stack+0x107/0x167
   print_usage_bug
   valid_state
   mark_lock_irq.cold+0x32/0x3a
   mark_lock+0x693/0xbc0
   mark_held_locks+0x9e/0xe0
   __trace_hardirqs_on_caller
   lockdep_hardirqs_on_prepare.part.0+0x151/0x360
   trace_hardirqs_on+0x5b/0x180
   __raw_spin_unlock_irq
   _raw_spin_unlock_irq+0x24/0x40
   spin_unlock_irq
   adjust_inuse_and_calc_cost+0x4fb/0x970
   ioc_rqos_merge+0x277/0x740
   __rq_qos_merge+0x62/0xb0
   rq_qos_merge
   bio_attempt_back_merge+0x12c/0x4a0
   blk_mq_sched_try_merge+0x1b6/0x4d0
   bfq_bio_merge+0x24a/0x390
   __blk_mq_sched_bio_merge+0xa6/0x460
   blk_mq_sched_bio_merge
   blk_mq_submit_bio+0x2e7/0x1ee0
   __submit_bio_noacct_mq+0x175/0x3b0
   submit_bio_noacct+0x1fb/0x270
   blk_throtl_dispatch_work_fn+0x1ef/0x2b0
   process_one_work+0x83e/0x13f0
   process_scheduled_works
   worker_thread+0x7e3/0xd80
   kthread+0x353/0x470
   ret_from_fork+0x1f/0x30</Note>
    </Notes>
    <CVE>CVE-2023-53730</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix potential deadlock in netlink_set_err()

syzbot reported a possible deadlock in netlink_set_err() [1]

A similar issue was fixed in commit 1d482e666b8e ("netlink: disable IRQs
for netlink_lock_table()") in netlink_lock_table()

This patch adds IRQ safety to netlink_set_err() and __netlink_diag_dump()
which were not covered by cited commit.

[1]

WARNING: possible irq lock inversion dependency detected
6.4.0-rc6-syzkaller-00240-g4e9f0ec38852 #0 Not tainted

syz-executor.2/23011 just changed the state of lock:
ffffffff8e1a7a58 (nl_table_lock){.+.?}-{2:2}, at: netlink_set_err+0x2e/0x3a0 net/netlink/af_netlink.c:1612
but this lock was taken by another, SOFTIRQ-safe lock in the past:
 (&amp;local-&gt;queue_stop_reason_lock){..-.}-{2:2}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:
 Possible interrupt unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(nl_table_lock);
                               local_irq_disable();
                               lock(&amp;local-&gt;queue_stop_reason_lock);
                               lock(nl_table_lock);
  &lt;Interrupt&gt;
    lock(&amp;local-&gt;queue_stop_reason_lock);

 *** DEADLOCK ***</Note>
    </Notes>
    <CVE>CVE-2023-53731</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_u32: Undo tcf_bind_filter if u32_replace_hw_knode

When u32_replace_hw_knode fails, we need to undo the tcf_bind_filter
operation done at u32_set_parms.</Note>
    </Notes>
    <CVE>CVE-2023-53733</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">containerd is an open-source container runtime. Versions 0.1.0 through 1.7.28, 2.0.0-beta.0 through 2.0.6, 2.1.0-beta.0 through 2.1.4 and 2.2.0-beta.0 through 2.2.0-rc.1 have an overly broad default permission vulnerability. Directory paths `/var/lib/containerd`, `/run/containerd/io.containerd.grpc.v1.cri` and `/run/containerd/io.containerd.sandbox.controller.v1.shim` were all created with incorrect permissions. This issue is fixed in versions 1.7.29, 2.0.7, 2.1.5 and 2.2.0. Workarounds include updating system administrator permissions so the host can manually chmod the directories to not have group or world accessible permissions, or to run containerd in rootless mode.</Note>
    </Notes>
    <CVE>CVE-2024-25621</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">go-retryablehttp prior to 0.7.7 did not sanitize urls when writing them to its log file. This could lead to go-retryablehttp writing sensitive HTTP basic auth credentials to its log file. This vulnerability, CVE-2024-6104, was fixed in go-retryablehttp 0.7.7.</Note>
    </Notes>
    <CVE>CVE-2024-6104</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A malicious client acting as the receiver of an rsync file transfer can trigger an out of bounds read of a heap based buffer, via a negative array index. The 

malicious 

rsync client requires at least read access to the remote rsync module in order to trigger the issue.</Note>
    </Notes>
    <CVE>CVE-2025-10158</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">URLs containing percent-encoded slashes (`/` or `\`) can trick wcurl into
saving the output file outside of the current directory without the user
explicitly asking for it.

This flaw only affects the wcurl command line tool.</Note>
    </Notes>
    <CVE>CVE-2025-11563</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When building nested elements using xml.dom.minidom methods such as appendChild() that have a dependency on _clear_id_cache() the algorithm is quadratic. Availability can be impacted when building excessively nested documents.</Note>
    </Notes>
    <CVE>CVE-2025-12084</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Stack-based buffer overflow in libtasn1 version: v4.20.0. The function fails to validate the size of input data resulting in a buffer overflow in asn1_expend_octet_string.</Note>
    </Notes>
    <CVE>CVE-2025-13151</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A heap-based buffer overflow problem was found in glib through an incorrect calculation of buffer size in the g_escape_uri_string() function. If the string to escape contains a very large number of unacceptable characters (which would need escaping), the calculation of the length of the escaped string could overflow, leading to a potential write off the end of the newly allocated string.</Note>
    </Notes>
    <CVE>CVE-2025-13601</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When reading an HTTP response from a server, if no read amount is specified, the default behavior will be to use Content-Length. This allows a malicious server to cause the client to read large amounts of data into memory, potentially causing OOM or other DoS.</Note>
    </Notes>
    <CVE>CVE-2025-13836</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When loading a plist file, the plistlib module reads data in size specified by the file itself, meaning a malicious file can cause OOM and DoS issues</Note>
    </Notes>
    <CVE>CVE-2025-13837</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 (Gnome Lib). This vulnerability allows a remote attacker to cause heap corruption, leading to a denial of service or potential code execution via a buffer-underflow in the GVariant parser when processing maliciously crafted input strings.</Note>
    </Notes>
    <CVE>CVE-2025-14087</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in glib. This vulnerability allows a heap buffer overflow and denial-of-service (DoS) via an integer overflow in GLib's GIO (GLib Input/Output) escape_byte_string() function when processing malicious file or remote filesystem attribute values.</Note>
    </Notes>
    <CVE>CVE-2025-14512</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer
performs a cross-protocol redirect to a second URL that uses an IMAP, LDAP,
POP3 or SMTP scheme, curl might wrongly pass on the bearer token to the new
target host.</Note>
    </Notes>
    <CVE>CVE-2025-14524</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When doing TLS related transfers with reused easy or multi handles and
altering the  `CURLSSLOPT_NO_PARTIALCHAIN` option, libcurl could accidentally
reuse a CA store cached in memory for which the partial chain option was
reversed. Contrary to the user's wishes and expectations. This could make
libcurl find and accept a trust chain that it otherwise would not.</Note>
    </Notes>
    <CVE>CVE-2025-14819</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When doing SSH-based transfers using either SCP or SFTP, and setting the
known_hosts file, libcurl could still mistakenly accept connecting to hosts
*not present* in the specified file if they were added as recognized in the
libssh *global* known_hosts file.</Note>
    </Notes>
    <CVE>CVE-2025-15079</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When doing SSH-based transfers using either SCP or SFTP, and asked to do
public key authentication, curl would wrongly still ask and authenticate using
a locally running SSH agent.</Note>
    </Notes>
    <CVE>CVE-2025-15224</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">SSH servers which implement file transfer protocols are vulnerable to a denial of service attack from clients which complete the key exchange slowly, or not at all, causing pending content to be read into memory, but never transmitted.</Note>
    </Notes>
    <CVE>CVE-2025-22869</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. In versions on the 4.x branch prior to version 4.0.5, when parsing compact JWS or JWE input, Go JOSE could use excessive memory. The code used strings.Split(token, ".") to split JWT tokens, which is vulnerable to excessive memory consumption when processing maliciously crafted tokens with a large number of `.` characters.  An attacker could exploit this by sending numerous malformed tokens, leading to memory exhaustion and a Denial of Service. Version 4.0.5 fixes this issue. As a workaround, applications could pre-validate that payloads passed to Go JOSE do not contain an excessive number of `.` characters.</Note>
    </Notes>
    <CVE>CVE-2025-27144</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">runc is a CLI tool for spawning and running containers according to the OCI specification. In versions 1.2.7 and below, 1.3.0-rc.1 through 1.3.1, 1.4.0-rc.1 and 1.4.0-rc.2 files, runc would not perform sufficient verification that the source of the bind-mount (i.e., the container's /dev/null) was actually a real /dev/null inode when using the container's /dev/null to mask. This exposes two methods of attack:  an arbitrary mount gadget, leading to host information disclosure, host denial of service, container escape, or a bypassing of maskedPaths. This issue is fixed in versions 1.2.8, 1.3.3 and 1.4.0-rc.3.</Note>
    </Notes>
    <CVE>CVE-2025-31133</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm/page_alloc: fix race condition in unaccepted memory handling

The page allocator tracks the number of zones that have unaccepted memory
using static_branch_enc/dec() and uses that static branch in hot paths to
determine if it needs to deal with unaccepted memory.

Borislav and Thomas pointed out that the tracking is racy: operations on
static_branch are not serialized against adding/removing unaccepted pages
to/from the zone.

Sanity checks inside static_branch machinery detects it:

WARNING: CPU: 0 PID: 10 at kernel/jump_label.c:276 __static_key_slow_dec_cpuslocked+0x8e/0xa0

The comment around the WARN() explains the problem:

	/*
	 * Warn about the '-1' case though; since that means a
	 * decrement is concurrent with a first (0-&gt;1) increment. IOW
	 * people are trying to disable something that wasn't yet fully
	 * enabled. This suggests an ordering problem on the user side.
	 */

The effect of this static_branch optimization is only visible on
microbenchmark.

Instead of adding more complexity around it, remove it altogether.</Note>
    </Notes>
    <CVE>CVE-2025-38008</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Add down_write(trace_event_sem) when adding trace event

When a module is loaded, it adds trace events defined by the module. It
may also need to modify the modules trace printk formats to replace enum
names with their values.

If two modules are loaded at the same time, the adding of the event to the
ftrace_events list can corrupt the walking of the list in the code that is
modifying the printk format strings and crash the kernel.

The addition of the event should take the trace_event_sem for write while
it adds the new event.

Also add a lockdep_assert_held() on that semaphore in
__trace_add_event_dirs() as it iterates the list.</Note>
    </Notes>
    <CVE>CVE-2025-38539</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: plug races between subflow fail and subflow creation

We have races similar to the one addressed by the previous patch between
subflow failing and additional subflow creation. They are just harder to
trigger.

The solution is similar. Use a separate flag to track the condition
'socket state prevent any additional subflow creation' protected by the
fallback lock.

The socket fallback makes such flag true, and also receiving or sending
an MP_FAIL option.

The field 'allow_infinite_fallback' is now always touched under the
relevant lock, we can drop the ONCE annotation on write.</Note>
    </Notes>
    <CVE>CVE-2025-38552</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: use the same treatment to check proc_lseek as ones for proc_read_iter et.al

Check pde-&gt;proc_ops-&gt;proc_lseek directly may cause UAF in rmmod scenario. 
It's a gap in proc_reg_open() after commit 654b33ada4ab("proc: fix UAF in
proc_get_inode()").  Followed by AI Viro's suggestion, fix it in same
manner.</Note>
    </Notes>
    <CVE>CVE-2025-38653</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: bfa: Double-free fix

When the bfad_im_probe() function fails during initialization, the memory
pointed to by bfad-&gt;im is freed without setting bfad-&gt;im to NULL.

Subsequently, during driver uninstallation, when the state machine enters
the bfad_sm_stopping state and calls the bfad_im_probe_undo() function,
it attempts to free the memory pointed to by bfad-&gt;im again, thereby
triggering a double-free vulnerability.

Set bfad-&gt;im to NULL if probing fails.</Note>
    </Notes>
    <CVE>CVE-2025-38699</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: libiscsi: Initialize iscsi_conn-&gt;dd_data only if memory is allocated

In case of an ib_fast_reg_mr allocation failure during iSER setup, the
machine hits a panic because iscsi_conn-&gt;dd_data is initialized
unconditionally, even when no memory is allocated (dd_size == 0).  This
leads invalid pointer dereference during connection teardown.

Fix by setting iscsi_conn-&gt;dd_data only if memory is actually allocated.

Panic trace:
------------
 iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12
 iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers
 BUG: unable to handle page fault for address: fffffffffffffff8
 RIP: 0010:swake_up_locked.part.5+0xa/0x40
 Call Trace:
  complete+0x31/0x40
  iscsi_iser_conn_stop+0x88/0xb0 [ib_iser]
  iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi]
  iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi]
  iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi]
  ? netlink_lookup+0x12f/0x1b0
  ? netlink_deliver_tap+0x2c/0x200
  netlink_unicast+0x1ab/0x280
  netlink_sendmsg+0x257/0x4f0
  ? _copy_from_user+0x29/0x60
  sock_sendmsg+0x5f/0x70</Note>
    </Notes>
    <CVE>CVE-2025-38700</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: linearize cloned gso packets in sctp_rcv

A cloned head skb still shares these frag skbs in fraglist with the
original head skb. It's not safe to access these frag skbs.

syzbot reported two use-of-uninitialized-memory bugs caused by this:

  BUG: KMSAN: uninit-value in sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211
   sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211
   sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:998
   sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88
   sctp_backlog_rcv+0x397/0xdb0 net/sctp/input.c:331
   sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1122
   __release_sock+0x1da/0x330 net/core/sock.c:3106
   release_sock+0x6b/0x250 net/core/sock.c:3660
   sctp_wait_for_connect+0x487/0x820 net/sctp/socket.c:9360
   sctp_sendmsg_to_asoc+0x1ec1/0x1f00 net/sctp/socket.c:1885
   sctp_sendmsg+0x32b9/0x4a80 net/sctp/socket.c:2031
   inet_sendmsg+0x25a/0x280 net/ipv4/af_inet.c:851
   sock_sendmsg_nosec net/socket.c:718 [inline]

and

  BUG: KMSAN: uninit-value in sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987
   sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987
   sctp_inq_push+0x2a3/0x350 net/sctp/inqueue.c:88
   sctp_backlog_rcv+0x3c7/0xda0 net/sctp/input.c:331
   sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148
   __release_sock+0x1d3/0x330 net/core/sock.c:3213
   release_sock+0x6b/0x270 net/core/sock.c:3767
   sctp_wait_for_connect+0x458/0x820 net/sctp/socket.c:9367
   sctp_sendmsg_to_asoc+0x223a/0x2260 net/sctp/socket.c:1886
   sctp_sendmsg+0x3910/0x49f0 net/sctp/socket.c:2032
   inet_sendmsg+0x269/0x2a0 net/ipv4/af_inet.c:851
   sock_sendmsg_nosec net/socket.c:712 [inline]

This patch fixes it by linearizing cloned gso packets in sctp_rcv().</Note>
    </Notes>
    <CVE>CVE-2025-38718</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qla4xxx: Prevent a potential error pointer dereference

The qla4xxx_get_ep_fwdb() function is supposed to return NULL on error,
but qla4xxx_ep_connect() returns error pointers.  Propagating the error
pointers will lead to an Oops in the caller, so change the error pointers
to NULL.</Note>
    </Notes>
    <CVE>CVE-2025-39676</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Limit access to parser-&gt;buffer when trace_get_user failed

When the length of the string written to set_ftrace_filter exceeds
FTRACE_BUFF_MAX, the following KASAN alarm will be triggered:

BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0
Read of size 1 at addr ffff0000d00bd5ba by task ash/165

CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty
Hardware name: linux,dummy-virt (DT)
Call trace:
 show_stack+0x34/0x50 (C)
 dump_stack_lvl+0xa0/0x158
 print_address_description.constprop.0+0x88/0x398
 print_report+0xb0/0x280
 kasan_report+0xa4/0xf0
 __asan_report_load1_noabort+0x20/0x30
 strsep+0x18c/0x1b0
 ftrace_process_regex.isra.0+0x100/0x2d8
 ftrace_regex_release+0x484/0x618
 __fput+0x364/0xa58
 ____fput+0x28/0x40
 task_work_run+0x154/0x278
 do_notify_resume+0x1f0/0x220
 el0_svc+0xec/0xf0
 el0t_64_sync_handler+0xa0/0xe8
 el0t_64_sync+0x1ac/0x1b0

The reason is that trace_get_user will fail when processing a string
longer than FTRACE_BUFF_MAX, but not set the end of parser-&gt;buffer to 0.
Then an OOB access will be triggered in ftrace_regex_release-&gt;
ftrace_process_regex-&gt;strsep-&gt;strpbrk. We can solve this problem by
limiting access to parser-&gt;buffer when trace_get_user failed.</Note>
    </Notes>
    <CVE>CVE-2025-39683</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 a race when updating an existing write

After nfs_lock_and_join_requests() tests for whether the request is
still attached to the mapping, nothing prevents a call to
nfs_inode_remove_request() from succeeding until we actually lock the
page group.
The reason is that whoever called nfs_inode_remove_request() doesn't
necessarily have a lock on the page group head.

So in order to avoid races, let's take the page group lock earlier in
nfs_lock_and_join_requests(), and hold it across the removal of the
request in nfs_inode_remove_request().</Note>
    </Notes>
    <CVE>CVE-2025-39697</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sr: Fix MAC comparison to be constant-time

To prevent timing attacks, MACs need to be compared in constant time.
Use the appropriate helper function for this.</Note>
    </Notes>
    <CVE>CVE-2025-39702</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Prevent file descriptor table allocations exceeding INT_MAX

When sysctl_nr_open is set to a very high value (for example, 1073741816
as set by systemd), processes attempting to use file descriptors near
the limit can trigger massive memory allocation attempts that exceed
INT_MAX, resulting in a WARNING in mm/slub.c:

  WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288

This happens because kvmalloc_array() and kvmalloc() check if the
requested size exceeds INT_MAX and emit a warning when the allocation is
not flagged with __GFP_NOWARN.

Specifically, when nr_open is set to 1073741816 (0x3ffffff8) and a
process calls dup2(oldfd, 1073741880), the kernel attempts to allocate:
- File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes
- Multiple bitmaps: ~400MB
- Total allocation size: &gt; 8GB (exceeding INT_MAX = 2,147,483,647)

Reproducer:
1. Set /proc/sys/fs/nr_open to 1073741816:
   # echo 1073741816 &gt; /proc/sys/fs/nr_open

2. Run a program that uses a high file descriptor:
   #include &lt;unistd.h&gt;
   #include &lt;sys/resource.h&gt;

   int main() {
       struct rlimit rlim = {1073741824, 1073741824};
       setrlimit(RLIMIT_NOFILE, &amp;rlim);
       dup2(2, 1073741880);  // Triggers the warning
       return 0;
   }

3. Observe WARNING in dmesg at mm/slub.c:5027

systemd commit a8b627a introduced automatic bumping of fs.nr_open to the
maximum possible value. The rationale was that systems with memory
control groups (memcg) no longer need separate file descriptor limits
since memory is properly accounted. However, this change overlooked
that:

1. The kernel's allocation functions still enforce INT_MAX as a maximum
   size regardless of memcg accounting
2. Programs and tests that legitimately test file descriptor limits can
   inadvertently trigger massive allocations
3. The resulting allocations (&gt;8GB) are impractical and will always fail

systemd's algorithm starts with INT_MAX and keeps halving the value
until the kernel accepts it. On most systems, this results in nr_open
being set to 1073741816 (0x3ffffff8), which is just under 1GB of file
descriptors.

While processes rarely use file descriptors near this limit in normal
operation, certain selftests (like
tools/testing/selftests/core/unshare_test.c) and programs that test file
descriptor limits can trigger this issue.

Fix this by adding a check in alloc_fdtable() to ensure the requested
allocation size does not exceed INT_MAX. This causes the operation to
fail with -EMFILE instead of triggering a kernel warning and avoids the
impractical &gt;8GB memory allocation request.</Note>
    </Notes>
    <CVE>CVE-2025-39756</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ARM: tegra: Use I/O memcpy to write to IRAM

Kasan crashes the kernel trying to check boundaries when using the
normal memcpy.</Note>
    </Notes>
    <CVE>CVE-2025-39794</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xfrm: Duplicate SPI Handling

The issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPI
Netlink message, which triggers the kernel function xfrm_alloc_spi().
This function is expected to ensure uniqueness of the Security Parameter
Index (SPI) for inbound Security Associations (SAs). However, it can
return success even when the requested SPI is already in use, leading
to duplicate SPIs assigned to multiple inbound SAs, differentiated
only by their destination addresses.

This behavior causes inconsistencies during SPI lookups for inbound packets.
Since the lookup may return an arbitrary SA among those with the same SPI,
packet processing can fail, resulting in packet drops.

According to RFC 4301 section 4.4.2 , for inbound processing a unicast SA
is uniquely identified by the SPI and optionally protocol.

Reproducing the Issue Reliably:
To consistently reproduce the problem, restrict the available SPI range in
charon.conf : spi_min = 0x10000000 spi_max = 0x10000002
This limits the system to only 2 usable SPI values.
Next, create more than 2 Child SA. each using unique pair of src/dst address.
As soon as the 3rd Child SA is initiated, it will be assigned a duplicate
SPI, since the SPI pool is already exhausted.
With a narrow SPI range, the issue is consistently reproducible.
With a broader/default range, it becomes rare and unpredictable.

Current implementation:
xfrm_spi_hash() lookup function computes hash using daddr, proto, and family.
So if two SAs have the same SPI but different destination addresses, then
they will:
a. Hash into different buckets
b. Be stored in different linked lists (byspi + h)
c. Not be seen in the same hlist_for_each_entry_rcu() iteration.
As a result, the lookup will result in NULL and kernel allows that Duplicate SPI

Proposed Change:
xfrm_state_lookup_spi_proto() does a truly global search - across all states,
regardless of hash bucket and matches SPI and proto.</Note>
    </Notes>
    <CVE>CVE-2025-39797</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: initialize more fields in sctp_v6_from_sk()

syzbot found that sin6_scope_id was not properly initialized,
leading to undefined behavior.

Clear sin6_scope_id and sin6_flowinfo.

BUG: KMSAN: uninit-value in __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649
  __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649
  sctp_inet6_cmp_addr+0x4f2/0x510 net/sctp/ipv6.c:983
  sctp_bind_addr_conflict+0x22a/0x3b0 net/sctp/bind_addr.c:390
  sctp_get_port_local+0x21eb/0x2440 net/sctp/socket.c:8452
  sctp_get_port net/sctp/socket.c:8523 [inline]
  sctp_listen_start net/sctp/socket.c:8567 [inline]
  sctp_inet_listen+0x710/0xfd0 net/sctp/socket.c:8636
  __sys_listen_socket net/socket.c:1912 [inline]
  __sys_listen net/socket.c:1927 [inline]
  __do_sys_listen net/socket.c:1932 [inline]
  __se_sys_listen net/socket.c:1930 [inline]
  __x64_sys_listen+0x343/0x4c0 net/socket.c:1930
  x64_sys_call+0x271d/0x3e20 arch/x86/include/generated/asm/syscalls_64.h:51
  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
  do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Local variable addr.i.i created at:
  sctp_get_port net/sctp/socket.c:8515 [inline]
  sctp_listen_start net/sctp/socket.c:8567 [inline]
  sctp_inet_listen+0x650/0xfd0 net/sctp/socket.c:8636
  __sys_listen_socket net/socket.c:1912 [inline]
  __sys_listen net/socket.c:1927 [inline]
  __do_sys_listen net/socket.c:1932 [inline]
  __se_sys_listen net/socket.c:1930 [inline]
  __x64_sys_listen+0x343/0x4c0 net/socket.c:1930</Note>
    </Notes>
    <CVE>CVE-2025-39812</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ftrace: Fix potential warning in trace_printk_seq during ftrace_dump

When calling ftrace_dump_one() concurrently with reading trace_pipe,
a WARN_ON_ONCE() in trace_printk_seq() can be triggered due to a race
condition.

The issue occurs because:

CPU0 (ftrace_dump)                              CPU1 (reader)
echo z &gt; /proc/sysrq-trigger

!trace_empty(&amp;iter)
trace_iterator_reset(&amp;iter) &lt;- len = size = 0
                                                cat /sys/kernel/tracing/trace_pipe
trace_find_next_entry_inc(&amp;iter)
  __find_next_entry
    ring_buffer_empty_cpu &lt;- all empty
  return NULL

trace_printk_seq(&amp;iter.seq)
  WARN_ON_ONCE(s-&gt;seq.len &gt;= s-&gt;seq.size)

In the context between trace_empty() and trace_find_next_entry_inc()
during ftrace_dump, the ring buffer data was consumed by other readers.
This caused trace_find_next_entry_inc to return NULL, failing to populate
`iter.seq`. At this point, due to the prior trace_iterator_reset, both
`iter.seq.len` and `iter.seq.size` were set to 0. Since they are equal,
the WARN_ON_ONCE condition is triggered.

Move the trace_printk_seq() into the if block that checks to make sure the
return value of trace_find_next_entry_inc() is non-NULL in
ftrace_dump_one(), ensuring the 'iter.seq' is properly populated before
subsequent operations.</Note>
    </Notes>
    <CVE>CVE-2025-39813</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: atmtcp: Prevent arbitrary write in atmtcp_recv_control().

syzbot reported the splat below. [0]

When atmtcp_v_open() or atmtcp_v_close() is called via connect()
or close(), atmtcp_send_control() is called to send an in-kernel
special message.

The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length.
Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc.

The notable thing is struct atmtcp_control is uAPI but has a
space for an in-kernel pointer.

  struct atmtcp_control {
  	struct atmtcp_hdr hdr;	/* must be first */
  ...
  	atm_kptr_t vcc;		/* both directions */
  ...
  } __ATM_API_ALIGN;

  typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;

The special message is processed in atmtcp_recv_control() called
from atmtcp_c_send().

atmtcp_c_send() is vcc-&gt;dev-&gt;ops-&gt;send() and called from 2 paths:

  1. .ndo_start_xmit() (vcc-&gt;send() == atm_send_aal0())
  2. vcc_sendmsg()

The problem is sendmsg() does not validate the message length and
userspace can abuse atmtcp_recv_control() to overwrite any kptr
by atmtcp_control.

Let's add a new -&gt;pre_send() hook to validate messages from sendmsg().

[0]:
Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI
KASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f]
CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025
RIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline]
RIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297
Code: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 &lt;42&gt; 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c
RSP: 0018:ffffc90003f5f810 EFLAGS: 00010203
RAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c
RBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd
R10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000
R13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff
FS:  00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0
Call Trace:
 &lt;TASK&gt;
 vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645
 sock_sendmsg_nosec net/socket.c:714 [inline]
 __sock_sendmsg+0x219/0x270 net/socket.c:729
 ____sys_sendmsg+0x505/0x830 net/socket.c:2614
 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668
 __sys_sendmsg net/socket.c:2700 [inline]
 __do_sys_sendmsg net/socket.c:2705 [inline]
 __se_sys_sendmsg net/socket.c:2703 [inline]
 __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f8d7e96a4a9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9
RDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005
RBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f
R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10ac
R13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250
 &lt;/TASK&gt;
Modules linked in:</Note>
    </Notes>
    <CVE>CVE-2025-39828</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Fix buffer free/clear order in deferred receive path

Fix a use-after-free window by correcting the buffer release sequence in
the deferred receive path. The code freed the RQ buffer first and only
then cleared the context pointer under the lock. Concurrent paths (e.g.,
ABTS and the repost path) also inspect and release the same pointer under
the lock, so the old order could lead to double-free/UAF.

Note that the repost path already uses the correct pattern: detach the
pointer under the lock, then free it after dropping the lock. The
deferred path should do the same.</Note>
    </Notes>
    <CVE>CVE-2025-39841</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vxlan: Fix NPD when refreshing an FDB entry with a nexthop object

VXLAN FDB entries can point to either a remote destination or an FDB
nexthop group. The latter is usually used in EVPN deployments where
learning is disabled.

However, when learning is enabled, an incoming packet might try to
refresh an FDB entry that points to an FDB nexthop group and therefore
does not have a remote. Such packets should be dropped, but they are
only dropped after dereferencing the non-existent remote, resulting in a
NPD [1] which can be reproduced using [2].

Fix by dropping such packets earlier. Remove the misleading comment from
first_remote_rcu().

[1]
BUG: kernel NULL pointer dereference, address: 0000000000000000
[...]
CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014
RIP: 0010:vxlan_snoop+0x98/0x1e0
[...]
Call Trace:
 &lt;TASK&gt;
 vxlan_encap_bypass+0x209/0x240
 encap_bypass_if_local+0xb1/0x100
 vxlan_xmit_one+0x1375/0x17e0
 vxlan_xmit+0x6b4/0x15f0
 dev_hard_start_xmit+0x5d/0x1c0
 __dev_queue_xmit+0x246/0xfd0
 packet_sendmsg+0x113a/0x1850
 __sock_sendmsg+0x38/0x70
 __sys_sendto+0x126/0x180
 __x64_sys_sendto+0x24/0x30
 do_syscall_64+0xa4/0x260
 entry_SYSCALL_64_after_hwframe+0x4b/0x53

[2]
 #!/bin/bash

 ip address add 192.0.2.1/32 dev lo
 ip address add 192.0.2.2/32 dev lo

 ip nexthop add id 1 via 192.0.2.3 fdb
 ip nexthop add id 10 group 1 fdb

 ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass
 ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning

 bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020
 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10

 mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q</Note>
    </Notes>
    <CVE>CVE-2025-39851</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: writeback: fix use-after-free in __mark_inode_dirty()

An use-after-free issue occurred when __mark_inode_dirty() get the
bdi_writeback that was in the progress of switching.

CPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1
......
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __mark_inode_dirty+0x124/0x418
lr : __mark_inode_dirty+0x118/0x418
sp : ffffffc08c9dbbc0
........
Call trace:
 __mark_inode_dirty+0x124/0x418
 generic_update_time+0x4c/0x60
 file_modified+0xcc/0xd0
 ext4_buffered_write_iter+0x58/0x124
 ext4_file_write_iter+0x54/0x704
 vfs_write+0x1c0/0x308
 ksys_write+0x74/0x10c
 __arm64_sys_write+0x1c/0x28
 invoke_syscall+0x48/0x114
 el0_svc_common.constprop.0+0xc0/0xe0
 do_el0_svc+0x1c/0x28
 el0_svc+0x40/0xe4
 el0t_64_sync_handler+0x120/0x12c
 el0t_64_sync+0x194/0x198

Root cause is:

systemd-random-seed                         kworker
----------------------------------------------------------------------
___mark_inode_dirty                     inode_switch_wbs_work_fn

  spin_lock(&amp;inode-&gt;i_lock);
  inode_attach_wb
  locked_inode_to_wb_and_lock_list
     get inode-&gt;i_wb
     spin_unlock(&amp;inode-&gt;i_lock);
     spin_lock(&amp;wb-&gt;list_lock)
  spin_lock(&amp;inode-&gt;i_lock)
  inode_io_list_move_locked
  spin_unlock(&amp;wb-&gt;list_lock)
  spin_unlock(&amp;inode-&gt;i_lock)
                                    spin_lock(&amp;old_wb-&gt;list_lock)
                                      inode_do_switch_wbs
                                        spin_lock(&amp;inode-&gt;i_lock)
                                        inode-&gt;i_wb = new_wb
                                        spin_unlock(&amp;inode-&gt;i_lock)
                                    spin_unlock(&amp;old_wb-&gt;list_lock)
                                    wb_put_many(old_wb, nr_switched)
                                      cgwb_release
                                      old wb released
  wb_wakeup_delayed() accesses wb,
  then trigger the use-after-free
  issue

Fix this race condition by holding inode spinlock until
wb_wakeup_delayed() finished.</Note>
    </Notes>
    <CVE>CVE-2025-39866</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable()

The function of_phy_find_device may return NULL, so we need to take
care before dereferencing phy_dev.</Note>
    </Notes>
    <CVE>CVE-2025-39876</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

kernfs: Fix UAF in polling when open file is released

A use-after-free (UAF) vulnerability was identified in the PSI (Pressure
Stall Information) monitoring mechanism:

BUG: KASAN: slab-use-after-free in psi_trigger_poll+0x3c/0x140
Read of size 8 at addr ffff3de3d50bd308 by task systemd/1

psi_trigger_poll+0x3c/0x140
cgroup_pressure_poll+0x70/0xa0
cgroup_file_poll+0x8c/0x100
kernfs_fop_poll+0x11c/0x1c0
ep_item_poll.isra.0+0x188/0x2c0

Allocated by task 1:
cgroup_file_open+0x88/0x388
kernfs_fop_open+0x73c/0xaf0
do_dentry_open+0x5fc/0x1200
vfs_open+0xa0/0x3f0
do_open+0x7e8/0xd08
path_openat+0x2fc/0x6b0
do_filp_open+0x174/0x368

Freed by task 8462:
cgroup_file_release+0x130/0x1f8
kernfs_drain_open_files+0x17c/0x440
kernfs_drain+0x2dc/0x360
kernfs_show+0x1b8/0x288
cgroup_file_show+0x150/0x268
cgroup_pressure_write+0x1dc/0x340
cgroup_file_write+0x274/0x548

Reproduction Steps:
1. Open test/cpu.pressure and establish epoll monitoring
2. Disable monitoring: echo 0 &gt; test/cgroup.pressure
3. Re-enable monitoring: echo 1 &gt; test/cgroup.pressure

The race condition occurs because:
1. When cgroup.pressure is disabled (echo 0 &gt; cgroup.pressure), it:
   - Releases PSI triggers via cgroup_file_release()
   - Frees of-&gt;priv through kernfs_drain_open_files()
2. While epoll still holds reference to the file and continues polling
3. Re-enabling (echo 1 &gt; cgroup.pressure) accesses freed of-&gt;priv

epolling			disable/enable cgroup.pressure
fd=open(cpu.pressure)
while(1)
...
epoll_wait
kernfs_fop_poll
kernfs_get_active = true	echo 0 &gt; cgroup.pressure
...				cgroup_file_show
				kernfs_show
				// inactive kn
				kernfs_drain_open_files
				cft-&gt;release(of);
				kfree(ctx);
				...
kernfs_get_active = false
				echo 1 &gt; cgroup.pressure
				kernfs_show
				kernfs_activate_one(kn);
kernfs_fop_poll
kernfs_get_active = true
cgroup_file_poll
psi_trigger_poll
// UAF
...
end: close(fd)

To address this issue, introduce kernfs_get_active_of() for kernfs open
files to obtain active references. This function will fail if the open file
has been released. Replace kernfs_get_active() with kernfs_get_active_of()
to prevent further operations on released file descriptors.</Note>
    </Notes>
    <CVE>CVE-2025-39881</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix sched_numa_find_nth_cpu() if mask offline

sched_numa_find_nth_cpu() uses a bsearch to look for the 'closest'
CPU in sched_domains_numa_masks and given cpus mask. However they
might not intersect if all CPUs in the cpus mask are offline. bsearch
will return NULL in that case, bail out instead of dereferencing a
bogus pointer.

The previous behaviour lead to this bug when using maxcpus=4 on an
rk3399 (LLLLbb) (i.e. booting with all big CPUs offline):

[    1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000
[    1.423635] Mem abort info:
[    1.423889]   ESR = 0x0000000096000006
[    1.424227]   EC = 0x25: DABT (current EL), IL = 32 bits
[    1.424715]   SET = 0, FnV = 0
[    1.424995]   EA = 0, S1PTW = 0
[    1.425279]   FSC = 0x06: level 2 translation fault
[    1.425735] Data abort info:
[    1.425998]   ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
[    1.426499]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[    1.426952]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[    1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000
[    1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000
[    1.429014] Internal error: Oops: 0000000096000006 [#1]  SMP
[    1.429525] Modules linked in:
[    1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT
[    1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT)
[    1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488
[    1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488
[    1.432543] sp : ffffffc084e1b960
[    1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0
[    1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
[    1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378
[    1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff
[    1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7
[    1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372
[    1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860
[    1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000
[    1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000
[    1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68
[    1.439332] Call trace:
[    1.439559]  sched_numa_find_nth_cpu+0x2a0/0x488 (P)
[    1.440016]  smp_call_function_any+0xc8/0xd0
[    1.440416]  armv8_pmu_init+0x58/0x27c
[    1.440770]  armv8_cortex_a72_pmu_init+0x20/0x2c
[    1.441199]  arm_pmu_device_probe+0x1e4/0x5e8
[    1.441603]  armv8_pmu_device_probe+0x1c/0x28
[    1.442007]  platform_probe+0x5c/0xac
[    1.442347]  really_probe+0xbc/0x298
[    1.442683]  __driver_probe_device+0x78/0x12c
[    1.443087]  driver_probe_device+0xdc/0x160
[    1.443475]  __driver_attach+0x94/0x19c
[    1.443833]  bus_for_each_dev+0x74/0xd4
[    1.444190]  driver_attach+0x24/0x30
[    1.444525]  bus_add_driver+0xe4/0x208
[    1.444874]  driver_register+0x60/0x128
[    1.445233]  __platform_driver_register+0x24/0x30
[    1.445662]  armv8_pmu_driver_init+0x28/0x4c
[    1.446059]  do_one_initcall+0x44/0x25c
[    1.446416]  kernel_init_freeable+0x1dc/0x3bc
[    1.446820]  kernel_init+0x20/0x1d8
[    1.447151]  ret_from_fork+0x10/0x20
[    1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803)
[    1.448040] ---[ end trace 0000000000000000 ]---
[    1.448483] note: swapper/0[1] exited with preempt_count 1
[    1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    1.449741] SMP: stopping secondary CPUs
[    1.450105] Kernel Offset: disabled
[    1.450419] CPU features: 0x000000,00080000,20002001,0400421b
[    
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-39895</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-39898</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm/slub: avoid accessing metadata when pointer is invalid in object_err()

object_err() reports details of an object for further debugging, such as
the freelist pointer, redzone, etc. However, if the pointer is invalid,
attempting to access object metadata can lead to a crash since it does
not point to a valid object.

One known path to the crash is when alloc_consistency_checks()
determines the pointer to the allocated object is invalid because of a
freelist corruption, and calls object_err() to report it. The debug code
should report and handle the corruption gracefully and not crash in the
process.

In case the pointer is NULL or check_valid_pointer() returns false for
the pointer, only print the pointer value and skip accessing metadata.</Note>
    </Notes>
    <CVE>CVE-2025-39902</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path

If request_irq() in i40e_vsi_request_irq_msix() fails in an iteration
later than the first, the error path wants to free the IRQs requested
so far. However, it uses the wrong dev_id argument for free_irq(), so
it does not free the IRQs correctly and instead triggers the warning:

 Trying to free already-free IRQ 173
 WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0
 Modules linked in: i40e(+) [...]
 CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy)
 Hardware name: [...]
 RIP: 0010:__free_irq+0x192/0x2c0
 [...]
 Call Trace:
  &lt;TASK&gt;
  free_irq+0x32/0x70
  i40e_vsi_request_irq_msix.cold+0x63/0x8b [i40e]
  i40e_vsi_request_irq+0x79/0x80 [i40e]
  i40e_vsi_open+0x21f/0x2f0 [i40e]
  i40e_open+0x63/0x130 [i40e]
  __dev_open+0xfc/0x210
  __dev_change_flags+0x1fc/0x240
  netif_change_flags+0x27/0x70
  do_setlink.isra.0+0x341/0xc70
  rtnl_newlink+0x468/0x860
  rtnetlink_rcv_msg+0x375/0x450
  netlink_rcv_skb+0x5c/0x110
  netlink_unicast+0x288/0x3c0
  netlink_sendmsg+0x20d/0x430
  ____sys_sendmsg+0x3a2/0x3d0
  ___sys_sendmsg+0x99/0xe0
  __sys_sendmsg+0x8a/0xf0
  do_syscall_64+0x82/0x2c0
  entry_SYSCALL_64_after_hwframe+0x76/0x7e
  [...]
  &lt;/TASK&gt;
 ---[ end trace 0000000000000000 ]---

Use the same dev_id for free_irq() as for request_irq().

I tested this with inserting code to fail intentionally.</Note>
    </Notes>
    <CVE>CVE-2025-39911</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: af_alg - Set merge to zero early in af_alg_sendmsg

If an error causes af_alg_sendmsg to abort, ctx-&gt;merge may contain
a garbage value from the previous loop.  This may then trigger a
crash on the next entry into af_alg_sendmsg when it attempts to do
a merge that can't be done.

Fix this by setting ctx-&gt;merge to zero near the start of the loop.</Note>
    </Notes>
    <CVE>CVE-2025-39931</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm: bridge: anx7625: Fix NULL pointer dereference with early IRQ

If the interrupt occurs before resource initialization is complete, the
interrupt handler/worker may access uninitialized data such as the I2C
tcpc_client device, potentially leading to NULL pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2025-39934</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer

Since commit 7d5e9737efda ("net: rfkill: gpio: get the name and type from
device property") rfkill_find_type() gets called with the possibly
uninitialized "const char *type_name;" local variable.

On x86 systems when rfkill-gpio binds to a "BCM4752" or "LNV4752"
acpi_device, the rfkill-&gt;type is set based on the ACPI acpi_device_id:

        rfkill-&gt;type = (unsigned)id-&gt;driver_data;

and there is no "type" property so device_property_read_string() will fail
and leave type_name uninitialized, leading to a potential crash.

rfkill_find_type() does accept a NULL pointer, fix the potential crash
by initializing type_name to NULL.

Note likely sofar this has not been caught because:

1. Not many x86 machines actually have a "BCM4752"/"LNV4752" acpi_device
2. The stack happened to contain NULL where type_name is stored</Note>
    </Notes>
    <CVE>CVE-2025-39937</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qcom: q6apm-lpass-dais: Fix NULL pointer dereference if source graph failed

If earlier opening of source graph fails (e.g. ADSP rejects due to
incorrect audioreach topology), the graph is closed and
"dai_data-&gt;graph[dai-&gt;id]" is assigned NULL.  Preparing the DAI for sink
graph continues though and next call to q6apm_lpass_dai_prepare()
receives dai_data-&gt;graph[dai-&gt;id]=NULL leading to NULL pointer
exception:

  qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001002 cmd
  qcom-apm gprsvc:service:2:1: DSP returned error[1001002] 1
  q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: fail to start APM port 78
  q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at snd_soc_pcm_dai_prepare on TX_CODEC_DMA_TX_3: -22
  Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a8
  ...
  Call trace:
   q6apm_graph_media_format_pcm+0x48/0x120 (P)
   q6apm_lpass_dai_prepare+0x110/0x1b4
   snd_soc_pcm_dai_prepare+0x74/0x108
   __soc_pcm_prepare+0x44/0x160
   dpcm_be_dai_prepare+0x124/0x1c0</Note>
    </Notes>
    <CVE>CVE-2025-39938</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cnic: Fix use-after-free bugs in cnic_delete_task

The original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),
which does not guarantee that the delayed work item 'delete_task' has
fully completed if it was already running. Additionally, the delayed work
item is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only
blocks and waits for work items that were already queued to the
workqueue prior to its invocation. Any work items submitted after
flush_workqueue() is called are not included in the set of tasks that the
flush operation awaits. This means that after the cyclic work items have
finished executing, a delayed work item may still exist in the workqueue.
This leads to use-after-free scenarios where the cnic_dev is deallocated
by cnic_free_dev(), while delete_task remains active and attempt to
dereference cnic_dev in cnic_delete_task().

A typical race condition is illustrated below:

CPU 0 (cleanup)              | CPU 1 (delayed work callback)
cnic_netdev_event()          |
  cnic_stop_hw()             | cnic_delete_task()
    cnic_cm_stop_bnx2x_hw()  | ...
      cancel_delayed_work()  | /* the queue_delayed_work()
      flush_workqueue()      |    executes after flush_workqueue()*/
                             | queue_delayed_work()
  cnic_free_dev(dev)//free   | cnic_delete_task() //new instance
                             |   dev = cp-&gt;dev; //use

Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure
that the cyclic delayed work item is properly canceled and that any
ongoing execution of the work item completes before the cnic_dev is
deallocated. Furthermore, since cancel_delayed_work_sync() uses
__flush_work(work, true) to synchronously wait for any currently
executing instance of the work item to finish, the flush_workqueue()
becomes redundant and should be removed.

This bug was identified through static analysis. To reproduce the issue
and validate the fix, I simulated the cnic PCI device in QEMU and
introduced intentional delays - such as inserting calls to ssleep()
within the cnic_delete_task() function - to increase the likelihood
of triggering the bug.</Note>
    </Notes>
    <CVE>CVE-2025-39945</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tls: make sure to abort the stream if headers are bogus

Normally we wait for the socket to buffer up the whole record
before we service it. If the socket has a tiny buffer, however,
we read out the data sooner, to prevent connection stalls.
Make sure that we abort the connection when we find out late
that the record is actually invalid. Retrying the parsing is
fine in itself but since we copy some more data each time
before we parse we can overflow the allocated skb space.

Constructing a scenario in which we're under pressure without
enough data in the socket to parse the length upfront is quite
hard. syzbot figured out a way to do this by serving us the header
in small OOB sends, and then filling in the recvbuf with a large
normal send.

Make sure that tls_rx_msg_size() aborts strp, if we reach
an invalid record there's really no way to recover.</Note>
    </Notes>
    <CVE>CVE-2025-39946</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Harden uplink netdev access against device unbind

The function mlx5_uplink_netdev_get() gets the uplink netdevice
pointer from mdev-&gt;mlx5e_res.uplink_netdev. However, the netdevice can
be removed and its pointer cleared when unbound from the mlx5_core.eth
driver. This results in a NULL pointer, causing a kernel panic.

 BUG: unable to handle page fault for address: 0000000000001300
 at RIP: 0010:mlx5e_vport_rep_load+0x22a/0x270 [mlx5_core]
 Call Trace:
  &lt;TASK&gt;
  mlx5_esw_offloads_rep_load+0x68/0xe0 [mlx5_core]
  esw_offloads_enable+0x593/0x910 [mlx5_core]
  mlx5_eswitch_enable_locked+0x341/0x420 [mlx5_core]
  mlx5_devlink_eswitch_mode_set+0x17e/0x3a0 [mlx5_core]
  devlink_nl_eswitch_set_doit+0x60/0xd0
  genl_family_rcv_msg_doit+0xe0/0x130
  genl_rcv_msg+0x183/0x290
  netlink_rcv_skb+0x4b/0xf0
  genl_rcv+0x24/0x40
  netlink_unicast+0x255/0x380
  netlink_sendmsg+0x1f3/0x420
  __sock_sendmsg+0x38/0x60
  __sys_sendto+0x119/0x180
  do_syscall_64+0x53/0x1d0
  entry_SYSCALL_64_after_hwframe+0x4b/0x53

Ensure the pointer is valid before use by checking it for NULL. If it
is valid, immediately call netdev_hold() to take a reference, and
preventing the netdevice from being freed while it is in use.</Note>
    </Notes>
    <CVE>CVE-2025-39947</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 Rx page leak on multi-buffer frames

The ice_put_rx_mbuf() function handles calling ice_put_rx_buf() for each
buffer in the current frame. This function was introduced as part of
handling multi-buffer XDP support in the ice driver.

It works by iterating over the buffers from first_desc up to 1 plus the
total number of fragments in the frame, cached from before the XDP program
was executed.

If the hardware posts a descriptor with a size of 0, the logic used in
ice_put_rx_mbuf() breaks. Such descriptors get skipped and don't get added
as fragments in ice_add_xdp_frag. Since the buffer isn't counted as a
fragment, we do not iterate over it in ice_put_rx_mbuf(), and thus we don't
call ice_put_rx_buf().

Because we don't call ice_put_rx_buf(), we don't attempt to re-use the
page or free it. This leaves a stale page in the ring, as we don't
increment next_to_alloc.

The ice_reuse_rx_page() assumes that the next_to_alloc has been incremented
properly, and that it always points to a buffer with a NULL page. Since
this function doesn't check, it will happily recycle a page over the top
of the next_to_alloc buffer, losing track of the old page.

Note that this leak only occurs for multi-buffer frames. The
ice_put_rx_mbuf() function always handles at least one buffer, so a
single-buffer frame will always get handled correctly. It is not clear
precisely why the hardware hands us descriptors with a size of 0 sometimes,
but it happens somewhat regularly with "jumbo frames" used by 9K MTU.

To fix ice_put_rx_mbuf(), we need to make sure to call ice_put_rx_buf() on
all buffers between first_desc and next_to_clean. Borrow the logic of a
similar function in i40e used for this same purpose. Use the same logic
also in ice_get_pgcnts().

Instead of iterating over just the number of fragments, use a loop which
iterates until the current index reaches to the next_to_clean element just
past the current frame. Unlike i40e, the ice_put_rx_mbuf() function does
call ice_put_rx_buf() on the last buffer of the frame indicating the end of
packet.

For non-linear (multi-buffer) frames, we need to take care when adjusting
the pagecnt_bias. An XDP program might release fragments from the tail of
the frame, in which case that fragment page is already released. Only
update the pagecnt_bias for the first descriptor and fragments still
remaining post-XDP program. Take care to only access the shared info for
fragmented buffers, as this avoids a significant cache miss.

The xdp_xmit value only needs to be updated if an XDP program is run, and
only once per packet. Drop the xdp_xmit pointer argument from
ice_put_rx_mbuf(). Instead, set xdp_xmit in the ice_clean_rx_irq() function
directly. This avoids needing to pass the argument and avoids an extra
bit-wise OR for each buffer in the frame.

Move the increment of the ntc local variable to ensure its updated *before*
all calls to ice_get_pgcnts() or ice_put_rx_mbuf(), as the loop logic
requires the index of the element just after the current frame.

Now that we use an index pointer in the ring to identify the packet, we no
longer need to track or cache the number of fragments in the rx_ring.</Note>
    </Notes>
    <CVE>CVE-2025-39948</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

qed: Don't collect too many protection override GRC elements

In the protection override dump path, the firmware can return far too
many GRC elements, resulting in attempting to write past the end of the
previously-kmalloc'ed dump buffer.

This will result in a kernel panic with reason:

 BUG: unable to handle kernel paging request at ADDRESS

where "ADDRESS" is just past the end of the protection override dump
buffer. The start address of the buffer is:
 p_hwfn-&gt;cdev-&gt;dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf
and the size of the buffer is buf_size in the same data structure.

The panic can be arrived at from either the qede Ethernet driver path:

    [exception RIP: qed_grc_dump_addr_range+0x108]
 qed_protection_override_dump at ffffffffc02662ed [qed]
 qed_dbg_protection_override_dump at ffffffffc0267792 [qed]
 qed_dbg_feature at ffffffffc026aa8f [qed]
 qed_dbg_all_data at ffffffffc026b211 [qed]
 qed_fw_fatal_reporter_dump at ffffffffc027298a [qed]
 devlink_health_do_dump at ffffffff82497f61
 devlink_health_report at ffffffff8249cf29
 qed_report_fatal_error at ffffffffc0272baf [qed]
 qede_sp_task at ffffffffc045ed32 [qede]
 process_one_work at ffffffff81d19783

or the qedf storage driver path:

    [exception RIP: qed_grc_dump_addr_range+0x108]
 qed_protection_override_dump at ffffffffc068b2ed [qed]
 qed_dbg_protection_override_dump at ffffffffc068c792 [qed]
 qed_dbg_feature at ffffffffc068fa8f [qed]
 qed_dbg_all_data at ffffffffc0690211 [qed]
 qed_fw_fatal_reporter_dump at ffffffffc069798a [qed]
 devlink_health_do_dump at ffffffff8aa95e51
 devlink_health_report at ffffffff8aa9ae19
 qed_report_fatal_error at ffffffffc0697baf [qed]
 qed_hw_err_notify at ffffffffc06d32d7 [qed]
 qed_spq_post at ffffffffc06b1011 [qed]
 qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed]
 qedf_cleanup_fcport at ffffffffc05e7597 [qedf]
 qedf_rport_event_handler at ffffffffc05e7bf7 [qedf]
 fc_rport_work at ffffffffc02da715 [libfc]
 process_one_work at ffffffff8a319663

Resolve this by clamping the firmware's return value to the maximum
number of legal elements the firmware should return.</Note>
    </Notes>
    <CVE>CVE-2025-39949</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: wilc1000: avoid buffer overflow in WID string configuration

Fix the following copy overflow warning identified by Smatch checker.

 drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame()
        error: '__memcpy()' 'cfg-&gt;s[i]-&gt;str' copy overflow (512 vs 65537)

This patch introduces size check before accessing the memory buffer.
The checks are base on the WID type of received data from the firmware.
For WID string configuration, the size limit is determined by individual
element size in 'struct wilc_cfg_str_vals' that is maintained in 'len' field
of 'struct wilc_cfg_str'.</Note>
    </Notes>
    <CVE>CVE-2025-39952</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Clear tcp_sk(sk)-&gt;fastopen_rsk in tcp_disconnect().

syzbot reported the splat below where a socket had tcp_sk(sk)-&gt;fastopen_rsk
in the TCP_ESTABLISHED state. [0]

syzbot reused the server-side TCP Fast Open socket as a new client before
the TFO socket completes 3WHS:

  1. accept()
  2. connect(AF_UNSPEC)
  3. connect() to another destination

As of accept(), sk-&gt;sk_state is TCP_SYN_RECV, and tcp_disconnect() changes
it to TCP_CLOSE and makes connect() possible, which restarts timers.

Since tcp_disconnect() forgot to clear tcp_sk(sk)-&gt;fastopen_rsk, the
retransmit timer triggered the warning and the intended packet was not
retransmitted.

Let's call reqsk_fastopen_remove() in tcp_disconnect().

[0]:
WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))
Modules linked in:
CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))
Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 &lt;0f&gt; 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e
RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293
RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017
RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400
RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8
R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540
R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0
FS:  0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0
Call Trace:
 &lt;IRQ&gt;
 tcp_write_timer (net/ipv4/tcp_timer.c:738)
 call_timer_fn (kernel/time/timer.c:1747)
 __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372)
 timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135)
 tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035)
 __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1))
 tmigr_handle_remote (kernel/time/timer_migration.c:1096)
 handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580)
 irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696)
 sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35))
 &lt;/IRQ&gt;</Note>
    </Notes>
    <CVE>CVE-2025-39955</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: increase scan_ies_len for S1G

Currently the S1G capability element is not taken into account
for the scan_ies_len, which leads to a buffer length validation
failure in ieee80211_prep_hw_scan() and subsequent WARN in
__ieee80211_start_scan(). This prevents hw scanning from functioning.
To fix ensure we accommodate for the S1G capability length.</Note>
    </Notes>
    <CVE>CVE-2025-39957</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fbcon: fix integer overflow in fbcon_do_set_font

Fix integer overflow vulnerabilities in fbcon_do_set_font() where font
size calculations could overflow when handling user-controlled font
parameters.

The vulnerabilities occur when:
1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount
   multiplication with user-controlled values that can overflow.
2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow
3. This results in smaller allocations than expected, leading to buffer
   overflows during font data copying.

Add explicit overflow checking using check_mul_overflow() and
check_add_overflow() kernel helpers to safety validate all size
calculations before allocation.</Note>
    </Notes>
    <CVE>CVE-2025-39967</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i40e: add max boundary check for VF filters

There is no check for max filters that VF can request. Add it.</Note>
    </Notes>
    <CVE>CVE-2025-39968</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i40e: fix validation of VF state in get resources

VF state I40E_VF_STATE_ACTIVE is not the only state in which
VF is actually active so it should not be used to determine
if a VF is allowed to obtain resources.

Use I40E_VF_STATE_RESOURCES_LOADED that is set only in
i40e_vc_get_vf_resources_msg() and cleared during reset.</Note>
    </Notes>
    <CVE>CVE-2025-39969</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i40e: fix input validation logic for action_meta

Fix condition to check 'greater or equal' to prevent OOB dereference.</Note>
    </Notes>
    <CVE>CVE-2025-39970</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i40e: fix idx validation in config queues msg

Ensure idx is within range of active/initialized TCs when iterating over
vf-&gt;ch[idx] in i40e_vc_config_queues_msg().</Note>
    </Notes>
    <CVE>CVE-2025-39971</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i40e: fix idx validation in i40e_validate_queue_map

Ensure idx is within range of active/initialized TCs when iterating over
vf-&gt;ch[idx] in i40e_validate_queue_map().</Note>
    </Notes>
    <CVE>CVE-2025-39972</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i40e: add validation for ring_len param

The `ring_len` parameter provided by the virtual function (VF)
is assigned directly to the hardware memory context (HMC) without
any validation.

To address this, introduce an upper boundary check for both Tx and Rx
queue lengths. The maximum number of descriptors supported by the
hardware is 8k-32.
Additionally, enforce alignment constraints: Tx rings must be a multiple
of 8, and Rx rings must be a multiple of 32.</Note>
    </Notes>
    <CVE>CVE-2025-39973</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

octeontx2-pf: Fix potential use after free in otx2_tc_add_flow()

This code calls kfree_rcu(new_node, rcu) and then dereferences "new_node"
and then dereferences it on the next line.  Two lines later, we take
a mutex so I don't think this is an RCU safe region.  Re-order it to do
the dereferences before queuing up the free.</Note>
    </Notes>
    <CVE>CVE-2025-39978</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: MGMT: Fix possible UAFs

This attemps to fix possible UAFs caused by struct mgmt_pending being
freed while still being processed like in the following trace, in order
to fix mgmt_pending_valid is introduce and use to check if the
mgmt_pending hasn't been removed from the pending list, on the complete
callbacks it is used to check and in addtion remove the cmd from the list
while holding mgmt_pending_lock to avoid TOCTOU problems since if the cmd
is left on the list it can still be accessed and freed.

BUG: KASAN: slab-use-after-free in mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223
Read of size 8 at addr ffff8880709d4dc0 by task kworker/u11:0/55

CPU: 0 UID: 0 PID: 55 Comm: kworker/u11:0 Not tainted 6.16.4 #2 PREEMPT(full)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
Workqueue: hci0 hci_cmd_sync_work
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0xca/0x240 mm/kasan/report.c:482
 kasan_report+0x118/0x150 mm/kasan/report.c:595
 mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223
 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332
 process_one_work kernel/workqueue.c:3238 [inline]
 process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321
 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
 kthread+0x711/0x8a0 kernel/kthread.c:464
 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16.4/arch/x86/entry/entry_64.S:245
 &lt;/TASK&gt;

Allocated by task 12210:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
 poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
 __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394
 kasan_kmalloc include/linux/kasan.h:260 [inline]
 __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4364
 kmalloc_noprof include/linux/slab.h:905 [inline]
 kzalloc_noprof include/linux/slab.h:1039 [inline]
 mgmt_pending_new+0x65/0x1e0 net/bluetooth/mgmt_util.c:269
 mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296
 __add_adv_patterns_monitor+0x130/0x200 net/bluetooth/mgmt.c:5247
 add_adv_patterns_monitor+0x214/0x360 net/bluetooth/mgmt.c:5364
 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719
 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839
 sock_sendmsg_nosec net/socket.c:714 [inline]
 __sock_sendmsg+0x219/0x270 net/socket.c:729
 sock_write_iter+0x258/0x330 net/socket.c:1133
 new_sync_write fs/read_write.c:593 [inline]
 vfs_write+0x5c9/0xb30 fs/read_write.c:686
 ksys_write+0x145/0x250 fs/read_write.c:738
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 12221:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576
 poison_slab_object mm/kasan/common.c:247 [inline]
 __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264
 kasan_slab_free include/linux/kasan.h:233 [inline]
 slab_free_hook mm/slub.c:2381 [inline]
 slab_free mm/slub.c:4648 [inline]
 kfree+0x18e/0x440 mm/slub.c:4847
 mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline]
 mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257
 __mgmt_power_off+0x169/0x350 net/bluetooth/mgmt.c:9444
 hci_dev_close_sync+0x754/0x1330 net/bluetooth/hci_sync.c:5290
 hci_dev_do_close net/bluetooth/hci_core.c:501 [inline]
 hci_dev_close+0x108/0x200 net/bluetooth/hci_core.c:526
 sock_do_ioctl+0xd9/0x300 net/socket.c:1192
 sock_ioctl+0x576/0x790 net/socket.c:1313
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:907 [inline]
 __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xf
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-39981</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_sync

This fixes the following UFA in hci_acl_create_conn_sync where a
connection still pending is command submission (conn-&gt;state == BT_OPEN)
maybe freed, also since this also can happen with the likes of
hci_le_create_conn_sync fix it as well:

BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861
Write of size 2 at addr ffff88805ffcc038 by task kworker/u11:2/9541

CPU: 1 UID: 0 PID: 9541 Comm: kworker/u11:2 Not tainted 6.16.0-rc7 #3 PREEMPT(full)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
Workqueue: hci3 hci_cmd_sync_work
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0xca/0x230 mm/kasan/report.c:480
 kasan_report+0x118/0x150 mm/kasan/report.c:593
 hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861
 hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332
 process_one_work kernel/workqueue.c:3238 [inline]
 process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321
 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
 kthread+0x70e/0x8a0 kernel/kthread.c:464
 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245
 &lt;/TASK&gt;

Allocated by task 123736:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
 poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
 __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394
 kasan_kmalloc include/linux/kasan.h:260 [inline]
 __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359
 kmalloc_noprof include/linux/slab.h:905 [inline]
 kzalloc_noprof include/linux/slab.h:1039 [inline]
 __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939
 hci_conn_add_unset net/bluetooth/hci_conn.c:1051 [inline]
 hci_connect_acl+0x16c/0x4e0 net/bluetooth/hci_conn.c:1634
 pair_device+0x418/0xa70 net/bluetooth/mgmt.c:3556
 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719
 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839
 sock_sendmsg_nosec net/socket.c:712 [inline]
 __sock_sendmsg+0x219/0x270 net/socket.c:727
 sock_write_iter+0x258/0x330 net/socket.c:1131
 new_sync_write fs/read_write.c:593 [inline]
 vfs_write+0x54b/0xa90 fs/read_write.c:686
 ksys_write+0x145/0x250 fs/read_write.c:738
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 103680:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576
 poison_slab_object mm/kasan/common.c:247 [inline]
 __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264
 kasan_slab_free include/linux/kasan.h:233 [inline]
 slab_free_hook mm/slub.c:2381 [inline]
 slab_free mm/slub.c:4643 [inline]
 kfree+0x18e/0x440 mm/slub.c:4842
 device_release+0x9c/0x1c0
 kobject_cleanup lib/kobject.c:689 [inline]
 kobject_release lib/kobject.c:720 [inline]
 kref_put include/linux/kref.h:65 [inline]
 kobject_put+0x22b/0x480 lib/kobject.c:737
 hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline]
 hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173
 hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199
 hci_event_func net/bluetooth/hci_event.c:7477 [inline]
 hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531
 hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070
 process_one_work kernel/workqueue.c:3238 [inline]
 process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321
 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
 kthread+0x70e/0x8a0 kernel/kthread.c:464
 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
 ret_from_fork_asm+0x1a/0x30 home/kwqcheii/sour
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-39982</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow

Sending an PF_PACKET allows to bypass the CAN framework logic and to
directly reach the xmit() function of a CAN driver. The only check
which is performed by the PF_PACKET framework is to make sure that
skb-&gt;len fits the interface's MTU.

Unfortunately, because the mcba_usb driver does not populate its
net_device_ops-&gt;ndo_change_mtu(), it is possible for an attacker to
configure an invalid MTU by doing, for example:

  $ ip link set can0 mtu 9999

After doing so, the attacker could open a PF_PACKET socket using the
ETH_P_CANXL protocol:

	socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))

to inject a malicious CAN XL frames. For example:

	struct canxl_frame frame = {
		.flags = 0xff,
		.len = 2048,
	};

The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
check that the skb is valid, unfortunately under above conditions, the
malicious packet is able to go through can_dev_dropped_skb() checks:

  1. the skb-&gt;protocol is set to ETH_P_CANXL which is valid (the
     function does not check the actual device capabilities).

  2. the length is a valid CAN XL length.

And so, mcba_usb_start_xmit() receives a CAN XL frame which it is not
able to correctly handle and will thus misinterpret it as a CAN frame.

This can result in a buffer overflow. The driver will consume cf-&gt;len
as-is with no further checks on these lines:

	usb_msg.dlc = cf-&gt;len;

	memcpy(usb_msg.data, cf-&gt;data, usb_msg.dlc);

Here, cf-&gt;len corresponds to the flags field of the CAN XL frame. In
our previous example, we set canxl_frame-&gt;flags to 0xff. Because the
maximum expected length is 8, a buffer overflow of 247 bytes occurs!

Populate net_device_ops-&gt;ndo_change_mtu() to ensure that the
interface's MTU can not be set to anything bigger than CAN_MTU. By
fixing the root cause, this prevents the buffer overflow.</Note>
    </Notes>
    <CVE>CVE-2025-39985</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow

Sending an PF_PACKET allows to bypass the CAN framework logic and to
directly reach the xmit() function of a CAN driver. The only check
which is performed by the PF_PACKET framework is to make sure that
skb-&gt;len fits the interface's MTU.

Unfortunately, because the sun4i_can driver does not populate its
net_device_ops-&gt;ndo_change_mtu(), it is possible for an attacker to
configure an invalid MTU by doing, for example:

  $ ip link set can0 mtu 9999

After doing so, the attacker could open a PF_PACKET socket using the
ETH_P_CANXL protocol:

	socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))

to inject a malicious CAN XL frames. For example:

	struct canxl_frame frame = {
		.flags = 0xff,
		.len = 2048,
	};

The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
check that the skb is valid, unfortunately under above conditions, the
malicious packet is able to go through can_dev_dropped_skb() checks:

  1. the skb-&gt;protocol is set to ETH_P_CANXL which is valid (the
     function does not check the actual device capabilities).

  2. the length is a valid CAN XL length.

And so, sun4ican_start_xmit() receives a CAN XL frame which it is not
able to correctly handle and will thus misinterpret it as a CAN frame.

This can result in a buffer overflow. The driver will consume cf-&gt;len
as-is with no further checks on this line:

	dlc = cf-&gt;len;

Here, cf-&gt;len corresponds to the flags field of the CAN XL frame. In
our previous example, we set canxl_frame-&gt;flags to 0xff. Because the
maximum expected length is 8, a buffer overflow of 247 bytes occurs a
couple line below when doing:

	for (i = 0; i &lt; dlc; i++)
		writel(cf-&gt;data[i], priv-&gt;base + (dreg + i * 4));

Populate net_device_ops-&gt;ndo_change_mtu() to ensure that the
interface's MTU can not be set to anything bigger than CAN_MTU. By
fixing the root cause, this prevents the buffer overflow.</Note>
    </Notes>
    <CVE>CVE-2025-39986</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

can: hi311x: populate ndo_change_mtu() to prevent buffer overflow

Sending an PF_PACKET allows to bypass the CAN framework logic and to
directly reach the xmit() function of a CAN driver. The only check
which is performed by the PF_PACKET framework is to make sure that
skb-&gt;len fits the interface's MTU.

Unfortunately, because the sun4i_can driver does not populate its
net_device_ops-&gt;ndo_change_mtu(), it is possible for an attacker to
configure an invalid MTU by doing, for example:

  $ ip link set can0 mtu 9999

After doing so, the attacker could open a PF_PACKET socket using the
ETH_P_CANXL protocol:

	socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))

to inject a malicious CAN XL frames. For example:

	struct canxl_frame frame = {
		.flags = 0xff,
		.len = 2048,
	};

The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
check that the skb is valid, unfortunately under above conditions, the
malicious packet is able to go through can_dev_dropped_skb() checks:

  1. the skb-&gt;protocol is set to ETH_P_CANXL which is valid (the
     function does not check the actual device capabilities).

  2. the length is a valid CAN XL length.

And so, hi3110_hard_start_xmit() receives a CAN XL frame which it is
not able to correctly handle and will thus misinterpret it as a CAN
frame. The driver will consume frame-&gt;len as-is with no further
checks.

This can result in a buffer overflow later on in hi3110_hw_tx() on
this line:

	memcpy(buf + HI3110_FIFO_EXT_DATA_OFF,
	       frame-&gt;data, frame-&gt;len);

Here, frame-&gt;len corresponds to the flags field of the CAN XL frame.
In our previous example, we set canxl_frame-&gt;flags to 0xff. Because
the maximum expected length is 8, a buffer overflow of 247 bytes
occurs!

Populate net_device_ops-&gt;ndo_change_mtu() to ensure that the
interface's MTU can not be set to anything bigger than CAN_MTU. By
fixing the root cause, this prevents the buffer overflow.</Note>
    </Notes>
    <CVE>CVE-2025-39987</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: populate ndo_change_mtu() to prevent buffer overflow

Sending an PF_PACKET allows to bypass the CAN framework logic and to
directly reach the xmit() function of a CAN driver. The only check
which is performed by the PF_PACKET framework is to make sure that
skb-&gt;len fits the interface's MTU.

Unfortunately, because the etas_es58x driver does not populate its
net_device_ops-&gt;ndo_change_mtu(), it is possible for an attacker to
configure an invalid MTU by doing, for example:

  $ ip link set can0 mtu 9999

After doing so, the attacker could open a PF_PACKET socket using the
ETH_P_CANXL protocol:

	socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL));

to inject a malicious CAN XL frames. For example:

	struct canxl_frame frame = {
		.flags = 0xff,
		.len = 2048,
	};

The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
check that the skb is valid, unfortunately under above conditions, the
malicious packet is able to go through can_dev_dropped_skb() checks:

  1. the skb-&gt;protocol is set to ETH_P_CANXL which is valid (the
     function does not check the actual device capabilities).

  2. the length is a valid CAN XL length.

And so, es58x_start_xmit() receives a CAN XL frame which it is not
able to correctly handle and will thus misinterpret it as a CAN(FD)
frame.

This can result in a buffer overflow. For example, using the es581.4
variant, the frame will be dispatched to es581_4_tx_can_msg(), go
through the last check at the beginning of this function:

	if (can_is_canfd_skb(skb))
		return -EMSGSIZE;

and reach this line:

	memcpy(tx_can_msg-&gt;data, cf-&gt;data, cf-&gt;len);

Here, cf-&gt;len corresponds to the flags field of the CAN XL frame. In
our previous example, we set canxl_frame-&gt;flags to 0xff. Because the
maximum expected length is 8, a buffer overflow of 247 bytes occurs!

Populate net_device_ops-&gt;ndo_change_mtu() to ensure that the
interface's MTU can not be set to anything bigger than CAN_MTU or
CANFD_MTU (depending on the device capabilities). By fixing the root
cause, this prevents the buffer overflow.</Note>
    </Notes>
    <CVE>CVE-2025-39988</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 NULL dereference in ath11k_qmi_m3_load()

If ab-&gt;fw.m3_data points to data, then fw pointer remains null.
Further, if m3_mem is not allocated, then fw is dereferenced to be
passed to ath11k_err function.

Replace fw-&gt;size by m3_len.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2025-39991</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: rc: fix races with imon_disconnect()

Syzbot reports a KASAN issue as below:
BUG: KASAN: use-after-free in __create_pipe include/linux/usb.h:1945 [inline]
BUG: KASAN: use-after-free in send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627
Read of size 4 at addr ffff8880256fb000 by task syz-executor314/4465

CPU: 2 PID: 4465 Comm: syz-executor314 Not tainted 6.0.0-rc1-syzkaller #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
Call Trace:
 &lt;TASK&gt;
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:317 [inline]
print_report.cold+0x2ba/0x6e9 mm/kasan/report.c:433
kasan_report+0xb1/0x1e0 mm/kasan/report.c:495
__create_pipe include/linux/usb.h:1945 [inline]
send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627
vfd_write+0x2d9/0x550 drivers/media/rc/imon.c:991
vfs_write+0x2d7/0xdd0 fs/read_write.c:576
ksys_write+0x127/0x250 fs/read_write.c:631
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd

The iMON driver improperly releases the usb_device reference in
imon_disconnect without coordinating with active users of the
device.

Specifically, the fields usbdev_intf0 and usbdev_intf1 are not
protected by the users counter (ictx-&gt;users). During probe,
imon_init_intf0 or imon_init_intf1 increments the usb_device
reference count depending on the interface. However, during
disconnect, usb_put_dev is called unconditionally, regardless of
actual usage.

As a result, if vfd_write or other operations are still in
progress after disconnect, this can lead to a use-after-free of
the usb_device pointer.

Thread 1 vfd_write                      Thread 2 imon_disconnect
                                        ...
                                        if
                                          usb_put_dev(ictx-&gt;usbdev_intf0)
                                        else
                                          usb_put_dev(ictx-&gt;usbdev_intf1)
...
while
  send_packet
    if
      pipe = usb_sndintpipe(
        ictx-&gt;usbdev_intf0) UAF
    else
      pipe = usb_sndctrlpipe(
        ictx-&gt;usbdev_intf0, 0) UAF

Guard access to usbdev_intf0 and usbdev_intf1 after disconnect by
checking ictx-&gt;disconnected in all writer paths. Add early return
with -ENODEV in send_packet(), vfd_write(), lcd_write() and
display_open() if the device is no longer present.

Set and read ictx-&gt;disconnected under ictx-&gt;lock to ensure memory
synchronization. Acquire the lock in imon_disconnect() before setting
the flag to synchronize with any ongoing operations.

Ensure writers exit early and safely after disconnect before the USB
core proceeds with cleanup.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.</Note>
    </Notes>
    <CVE>CVE-2025-39993</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: tuner: xc5000: Fix use-after-free in xc5000_release

The original code uses cancel_delayed_work() in xc5000_release(), which
does not guarantee that the delayed work item timer_sleep has fully
completed if it was already running. This leads to use-after-free scenarios
where xc5000_release() may free the xc5000_priv while timer_sleep is still
active and attempts to dereference the xc5000_priv.

A typical race condition is illustrated below:

CPU 0 (release thread)                 | CPU 1 (delayed work callback)
xc5000_release()                       | xc5000_do_timer_sleep()
  cancel_delayed_work()                |
  hybrid_tuner_release_state(priv)     |
    kfree(priv)                        |
                                       |   priv = container_of() // UAF

Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure
that the timer_sleep is properly canceled before the xc5000_priv memory
is deallocated.

A deadlock concern was considered: xc5000_release() is called in a process
context and is not holding any locks that the timer_sleep work item might
also need. Therefore, the use of the _sync() variant is safe here.

This bug was initially identified through static analysis.

[hverkuil: fix typo in Subject: tunner -&gt; tuner]</Note>
    </Notes>
    <CVE>CVE-2025-39994</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: i2c: tc358743: Fix use-after-free bugs caused by orphan timer in probe

The state-&gt;timer is a cyclic timer that schedules work_i2c_poll and
delayed_work_enable_hotplug, while rearming itself. Using timer_delete()
fails to guarantee the timer isn't still running when destroyed, similarly
cancel_delayed_work() cannot ensure delayed_work_enable_hotplug has
terminated if already executing. During probe failure after timer
initialization, these may continue running as orphans and reference the
already-freed tc358743_state object through tc358743_irq_poll_timer.

The following is the trace captured by KASAN.

BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0
Write of size 8 at addr ffff88800ded83c8 by task swapper/1/0
...
Call Trace:
 &lt;IRQ&gt;
 dump_stack_lvl+0x55/0x70
 print_report+0xcf/0x610
 ? __pfx_sched_balance_find_src_group+0x10/0x10
 ? __run_timer_base.part.0+0x7d7/0x8c0
 kasan_report+0xb8/0xf0
 ? __run_timer_base.part.0+0x7d7/0x8c0
 __run_timer_base.part.0+0x7d7/0x8c0
 ? rcu_sched_clock_irq+0xb06/0x27d0
 ? __pfx___run_timer_base.part.0+0x10/0x10
 ? try_to_wake_up+0xb15/0x1960
 ? tmigr_update_events+0x280/0x740
 ? _raw_spin_lock_irq+0x80/0xe0
 ? __pfx__raw_spin_lock_irq+0x10/0x10
 tmigr_handle_remote_up+0x603/0x7e0
 ? __pfx_tmigr_handle_remote_up+0x10/0x10
 ? sched_balance_trigger+0x98/0x9f0
 ? sched_tick+0x221/0x5a0
 ? _raw_spin_lock_irq+0x80/0xe0
 ? __pfx__raw_spin_lock_irq+0x10/0x10
 ? tick_nohz_handler+0x339/0x440
 ? __pfx_tmigr_handle_remote_up+0x10/0x10
 __walk_groups.isra.0+0x42/0x150
 tmigr_handle_remote+0x1f4/0x2e0
 ? __pfx_tmigr_handle_remote+0x10/0x10
 ? ktime_get+0x60/0x140
 ? lapic_next_event+0x11/0x20
 ? clockevents_program_event+0x1d4/0x2a0
 ? hrtimer_interrupt+0x322/0x780
 handle_softirqs+0x16a/0x550
 irq_exit_rcu+0xaf/0xe0
 sysvec_apic_timer_interrupt+0x70/0x80
 &lt;/IRQ&gt;
...

Allocated by task 141:
 kasan_save_stack+0x24/0x50
 kasan_save_track+0x14/0x30
 __kasan_kmalloc+0x7f/0x90
 __kmalloc_node_track_caller_noprof+0x198/0x430
 devm_kmalloc+0x7b/0x1e0
 tc358743_probe+0xb7/0x610  i2c_device_probe+0x51d/0x880
 really_probe+0x1ca/0x5c0
 __driver_probe_device+0x248/0x310
 driver_probe_device+0x44/0x120
 __device_attach_driver+0x174/0x220
 bus_for_each_drv+0x100/0x190
 __device_attach+0x206/0x370
 bus_probe_device+0x123/0x170
 device_add+0xd25/0x1470
 i2c_new_client_device+0x7a0/0xcd0
 do_one_initcall+0x89/0x300
 do_init_module+0x29d/0x7f0
 load_module+0x4f48/0x69e0
 init_module_from_file+0xe4/0x150
 idempotent_init_module+0x320/0x670
 __x64_sys_finit_module+0xbd/0x120
 do_syscall_64+0xac/0x280
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 141:
 kasan_save_stack+0x24/0x50
 kasan_save_track+0x14/0x30
 kasan_save_free_info+0x3a/0x60
 __kasan_slab_free+0x3f/0x50
 kfree+0x137/0x370
 release_nodes+0xa4/0x100
 devres_release_group+0x1b2/0x380
 i2c_device_probe+0x694/0x880
 really_probe+0x1ca/0x5c0
 __driver_probe_device+0x248/0x310
 driver_probe_device+0x44/0x120
 __device_attach_driver+0x174/0x220
 bus_for_each_drv+0x100/0x190
 __device_attach+0x206/0x370
 bus_probe_device+0x123/0x170
 device_add+0xd25/0x1470
 i2c_new_client_device+0x7a0/0xcd0
 do_one_initcall+0x89/0x300
 do_init_module+0x29d/0x7f0
 load_module+0x4f48/0x69e0
 init_module_from_file+0xe4/0x150
 idempotent_init_module+0x320/0x670
 __x64_sys_finit_module+0xbd/0x120
 do_syscall_64+0xac/0x280
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
...

Replace timer_delete() with timer_delete_sync() and cancel_delayed_work()
with cancel_delayed_work_sync() to ensure proper termination of timer and
work items before resource cleanup.

This bug was initially identified through static analysis. For reproduction
and testing, I created a functional emulation of the tc358743 device via a
kernel module and introduced faults through the debugfs interface.</Note>
    </Notes>
    <CVE>CVE-2025-39995</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: b2c2: Fix use-after-free causing by irq_check_work in flexcop_pci_remove

The original code uses cancel_delayed_work() in flexcop_pci_remove(), which
does not guarantee that the delayed work item irq_check_work has fully
completed if it was already running. This leads to use-after-free scenarios
where flexcop_pci_remove() may free the flexcop_device while irq_check_work
is still active and attempts to dereference the device.

A typical race condition is illustrated below:

CPU 0 (remove)                         | CPU 1 (delayed work callback)
flexcop_pci_remove()                   | flexcop_pci_irq_check_work()
  cancel_delayed_work()                |
  flexcop_device_kfree(fc_pci-&gt;fc_dev) |
                                       |   fc = fc_pci-&gt;fc_dev; // UAF

This is confirmed by a KASAN report:

==================================================================
BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0
Write of size 8 at addr ffff8880093aa8c8 by task bash/135
...
Call Trace:
 &lt;IRQ&gt;
 dump_stack_lvl+0x55/0x70
 print_report+0xcf/0x610
 ? __run_timer_base.part.0+0x7d7/0x8c0
 kasan_report+0xb8/0xf0
 ? __run_timer_base.part.0+0x7d7/0x8c0
 __run_timer_base.part.0+0x7d7/0x8c0
 ? __pfx___run_timer_base.part.0+0x10/0x10
 ? __pfx_read_tsc+0x10/0x10
 ? ktime_get+0x60/0x140
 ? lapic_next_event+0x11/0x20
 ? clockevents_program_event+0x1d4/0x2a0
 run_timer_softirq+0xd1/0x190
 handle_softirqs+0x16a/0x550
 irq_exit_rcu+0xaf/0xe0
 sysvec_apic_timer_interrupt+0x70/0x80
 &lt;/IRQ&gt;
...

Allocated by task 1:
 kasan_save_stack+0x24/0x50
 kasan_save_track+0x14/0x30
 __kasan_kmalloc+0x7f/0x90
 __kmalloc_noprof+0x1be/0x460
 flexcop_device_kmalloc+0x54/0xe0
 flexcop_pci_probe+0x1f/0x9d0
 local_pci_probe+0xdc/0x190
 pci_device_probe+0x2fe/0x470
 really_probe+0x1ca/0x5c0
 __driver_probe_device+0x248/0x310
 driver_probe_device+0x44/0x120
 __driver_attach+0xd2/0x310
 bus_for_each_dev+0xed/0x170
 bus_add_driver+0x208/0x500
 driver_register+0x132/0x460
 do_one_initcall+0x89/0x300
 kernel_init_freeable+0x40d/0x720
 kernel_init+0x1a/0x150
 ret_from_fork+0x10c/0x1a0
 ret_from_fork_asm+0x1a/0x30

Freed by task 135:
 kasan_save_stack+0x24/0x50
 kasan_save_track+0x14/0x30
 kasan_save_free_info+0x3a/0x60
 __kasan_slab_free+0x3f/0x50
 kfree+0x137/0x370
 flexcop_device_kfree+0x32/0x50
 pci_device_remove+0xa6/0x1d0
 device_release_driver_internal+0xf8/0x210
 pci_stop_bus_device+0x105/0x150
 pci_stop_and_remove_bus_device_locked+0x15/0x30
 remove_store+0xcc/0xe0
 kernfs_fop_write_iter+0x2c3/0x440
 vfs_write+0x871/0xd70
 ksys_write+0xee/0x1c0
 do_syscall_64+0xac/0x280
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
...

Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure
that the delayed work item is properly canceled and any executing delayed
work has finished before the device memory is deallocated.

This bug was initially identified through static analysis. To reproduce
and test it, I simulated the B2C2 FlexCop PCI device in QEMU and introduced
artificial delays within the flexcop_pci_irq_check_work() function to
increase the likelihood of triggering the bug.</Note>
    </Notes>
    <CVE>CVE-2025-39996</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb-audio: fix race condition to UAF in snd_usbmidi_free

The previous commit 0718a78f6a9f ("ALSA: usb-audio: Kill timer properly at
removal") patched a UAF issue caused by the error timer.

However, because the error timer kill added in this patch occurs after the
endpoint delete, a race condition to UAF still occurs, albeit rarely.

Additionally, since kill-cleanup for urb is also missing, freed memory can
be accessed in interrupt context related to urb, which can cause UAF.

Therefore, to prevent this, error timer and urb must be killed before
freeing the heap memory.</Note>
    </Notes>
    <CVE>CVE-2025-39997</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 use-after-free in rtw89_core_tx_kick_off_and_wait()

There is a bug observed when rtw89_core_tx_kick_off_and_wait() tries to
access already freed skb_data:

 BUG: KFENCE: use-after-free write in rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110

 CPU: 6 UID: 0 PID: 41377 Comm: kworker/u64:24 Not tainted  6.17.0-rc1+ #1 PREEMPT(lazy)
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS edk2-20250523-14.fc42 05/23/2025
 Workqueue: events_unbound cfg80211_wiphy_work [cfg80211]

 Use-after-free write at 0x0000000020309d9d (in kfence-#251):
 rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110
 rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338
 rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979
 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165
 rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.h:141
 rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012
 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059
 rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758
 process_one_work kernel/workqueue.c:3241
 worker_thread kernel/workqueue.c:3400
 kthread kernel/kthread.c:463
 ret_from_fork arch/x86/kernel/process.c:154
 ret_from_fork_asm arch/x86/entry/entry_64.S:258

 kfence-#251: 0x0000000056e2393d-0x000000009943cb62, size=232, cache=skbuff_head_cache

 allocated by task 41377 on cpu 6 at 77869.159548s (0.009551s ago):
 __alloc_skb net/core/skbuff.c:659
 __netdev_alloc_skb net/core/skbuff.c:734
 ieee80211_nullfunc_get net/mac80211/tx.c:5844
 rtw89_core_send_nullfunc drivers/net/wireless/realtek/rtw89/core.c:3431
 rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338
 rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979
 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165
 rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.c:3194
 rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012
 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059
 rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758
 process_one_work kernel/workqueue.c:3241
 worker_thread kernel/workqueue.c:3400
 kthread kernel/kthread.c:463
 ret_from_fork arch/x86/kernel/process.c:154
 ret_from_fork_asm arch/x86/entry/entry_64.S:258

 freed by task 1045 on cpu 9 at 77869.168393s (0.001557s ago):
 ieee80211_tx_status_skb net/mac80211/status.c:1117
 rtw89_pci_release_txwd_skb drivers/net/wireless/realtek/rtw89/pci.c:564
 rtw89_pci_release_tx_skbs.isra.0 drivers/net/wireless/realtek/rtw89/pci.c:651
 rtw89_pci_release_tx drivers/net/wireless/realtek/rtw89/pci.c:676
 rtw89_pci_napi_poll drivers/net/wireless/realtek/rtw89/pci.c:4238
 __napi_poll net/core/dev.c:7495
 net_rx_action net/core/dev.c:7557 net/core/dev.c:7684
 handle_softirqs kernel/softirq.c:580
 do_softirq.part.0 kernel/softirq.c:480
 __local_bh_enable_ip kernel/softirq.c:407
 rtw89_pci_interrupt_threadfn drivers/net/wireless/realtek/rtw89/pci.c:927
 irq_thread_fn kernel/irq/manage.c:1133
 irq_thread kernel/irq/manage.c:1257
 kthread kernel/kthread.c:463
 ret_from_fork arch/x86/kernel/process.c:154
 ret_from_fork_asm arch/x86/entry/entry_64.S:258

It is a consequence of a race between the waiting and the signaling side
of the completion:

            Waiting thread                            Completing thread

rtw89_core_tx_kick_off_and_wait()
  rcu_assign_pointer(skb_data-&gt;wait, wait)
  /* start waiting */
  wait_for_completion_timeout()
                                                rtw89_pci_tx_status()
                                                  rtw89_core_tx_wait_complete()
                                                    rcu_read_lock()
                                                    /* signals completion and
   
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-40000</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: cadence-quadspi: Implement refcount to handle unbind during busy

driver support indirect read and indirect write operation with
assumption no force device removal(unbind) operation. However
force device removal(removal) is still available to root superuser.

Unbinding driver during operation causes kernel crash. This changes
ensure driver able to handle such operation for indirect read and
indirect write by implementing refcount to track attached devices
to the controller and gracefully wait and until attached devices
remove operation completed before proceed with removal operation.</Note>
    </Notes>
    <CVE>CVE-2025-40005</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

afs: Fix potential null pointer dereference in afs_put_server

afs_put_server() accessed server-&gt;debug_id before the NULL check, which
could lead to a null pointer dereference. Move the debug_id assignment,
ensuring we never dereference a NULL server pointer.</Note>
    </Notes>
    <CVE>CVE-2025-40010</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/gma500: Fix null dereference in hdmi teardown

pci_set_drvdata sets the value of pdev-&gt;driver_data to NULL,
after which the driver_data obtained from the same dev is
dereferenced in oaktrail_hdmi_i2c_exit, and the i2c_dev is
extracted from it. To prevent this, swap these calls.

Found by Linux Verification Center (linuxtesting.org) with Svacer.</Note>
    </Notes>
    <CVE>CVE-2025-40011</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qcom: audioreach: fix potential null pointer dereference

It is possible that the topology parsing function
audioreach_widget_load_module_common() could return NULL or an error
pointer. Add missing NULL check so that we do not dereference it.</Note>
    </Notes>
    <CVE>CVE-2025-40013</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Mark invalid entities with id UVC_INVALID_ENTITY_ID

Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero
unique ID.

```
Each Unit and Terminal within the video function is assigned a unique
identification number, the Unit ID (UID) or Terminal ID (TID), contained in
the bUnitID or bTerminalID field of the descriptor. The value 0x00 is
reserved for undefined ID,
```

If we add a new entity with id 0 or a duplicated ID, it will be marked
as UVC_INVALID_ENTITY_ID.

In a previous attempt commit 3dd075fe8ebb ("media: uvcvideo: Require
entities to have a non-zero unique ID"), we ignored all the invalid units,
this broke a lot of non-compatible cameras. Hopefully we are more lucky
this time.

This also prevents some syzkaller reproducers from triggering warnings due
to a chain of entities referring to themselves. In one particular case, an
Output Unit is connected to an Input Unit, both with the same ID of 1. But
when looking up for the source ID of the Output Unit, that same entity is
found instead of the input entity, which leads to such warnings.

In another case, a backward chain was considered finished as the source ID
was 0. Later on, that entity was found, but its pads were not valid.

Here is a sample stack trace for one of those cases.

[   20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd
[   20.830206] usb 1-1: Using ep0 maxpacket: 8
[   20.833501] usb 1-1: config 0 descriptor??
[   21.038518] usb 1-1: string descriptor 0 read error: -71
[   21.038893] usb 1-1: Found UVC 0.00 device &lt;unnamed&gt; (2833:0201)
[   21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized!
[   21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized!
[   21.042218] ------------[ cut here ]------------
[   21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0
[   21.043195] Modules linked in:
[   21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444
[   21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
[   21.044639] Workqueue: usb_hub_wq hub_event
[   21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0
[   21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 &lt;0f&gt; 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00
[   21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246
[   21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1
[   21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290
[   21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000
[   21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003
[   21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000
[   21.049648] FS:  0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000
[   21.050271] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0
[   21.051136] PKRU: 55555554
[   21.051331] Call Trace:
[   21.051480]  &lt;TASK&gt;
[   21.051611]  ? __warn+0xc4/0x210
[   21.051861]  ? media_create_pad_link+0x2c4/0x2e0
[   21.052252]  ? report_bug+0x11b/0x1a0
[   21.052540]  ? trace_hardirqs_on+0x31/0x40
[   21.052901]  ? handle_bug+0x3d/0x70
[   21.053197]  ? exc_invalid_op+0x1a/0x50
[   21.053511]  ? asm_exc_invalid_op+0x1a/0x20
[   21.053924]  ? media_create_pad_link+0x91/0x2e0
[   21.054364]  ? media_create_pad_link+0x2c4/0x2e0
[   21.054834]  ? media_create_pad_link+0x91/0x2e0
[   21.055131]  ? _raw_spin_unlock+0x1e/0x40
[   21.055441]  ? __v4l2_device_register_subdev+0x202/0x210
[   21.055837]  uvc_mc_register_entities+0x358/0x400
[   21.056144]  uvc_register_chains+0x1
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-40016</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipvs: Defer ip_vs_ftp unregister during netns cleanup

On the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp
before connections with valid cp-&gt;app pointers are flushed, leading to a
use-after-free.

Fix this by introducing a global `exiting_module` flag, set to true in
ip_vs_ftp_exit() before unregistering the pernet subsystem. In
__ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns
cleanup (when exiting_module is false) and defer it to
__ip_vs_cleanup_batch(), which unregisters all apps after all connections
are flushed. If called during module exit, unregister ip_vs_ftp
immediately.</Note>
    </Notes>
    <CVE>CVE-2025-40018</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

crypto: essiv - Check ssize for decryption and in-place encryption

Move the ssize check to the start in essiv_aead_crypt so that
it's also checked for decryption and in-place encryption.</Note>
    </Notes>
    <CVE>CVE-2025-40019</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

can: peak_usb: fix shift-out-of-bounds issue

Explicitly uses a 64-bit constant when the number of bits used for its
shifting is 32 (which is the case for PC CAN FD interfaces supported by
this driver).

[mkl: update subject, apply manually]</Note>
    </Notes>
    <CVE>CVE-2025-40020</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fsl-mc: Check return value of platform_get_resource()

platform_get_resource() returns NULL in case of failure, so check its
return value and propagate the error in order to prevent NULL pointer
dereference.</Note>
    </Notes>
    <CVE>CVE-2025-40029</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: endpoint: pci-epf-test: Add NULL check for DMA channels before release

The fields dma_chan_tx and dma_chan_rx of the struct pci_epf_test can be
NULL even after EPF initialization. Then it is prudent to check that
they have non-NULL values before releasing the channels. Add the checks
in pci_epf_test_clean_dma_chan().

Without the checks, NULL pointer dereferences happen and they can lead
to a kernel panic in some cases:

  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050
  Call trace:
   dma_release_channel+0x2c/0x120 (P)
   pci_epf_test_epc_deinit+0x94/0xc0 [pci_epf_test]
   pci_epc_deinit_notify+0x74/0xc0
   tegra_pcie_ep_pex_rst_irq+0x250/0x5d8
   irq_thread_fn+0x34/0xb8
   irq_thread+0x18c/0x2e8
   kthread+0x14c/0x210
   ret_from_fork+0x10/0x20

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

Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leak

Struct ff_effect_compat is embedded twice inside
uinput_ff_upload_compat, contains internal padding. In particular, there
is a hole after struct ff_replay to satisfy alignment requirements for
the following union member. Without clearing the structure,
copy_to_user() may leak stack data to userspace.

Initialize ff_up_compat to zero before filling valid fields.</Note>
    </Notes>
    <CVE>CVE-2025-40035</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 possible map leak in fastrpc_put_args

copy_to_user() failure would cause an early return without cleaning up
the fdlist, which has been updated by the DSP. This could lead to map
leak. Fix this by redirecting to a cleanup path on failure, ensuring
that all mapped buffers are properly released before returning.</Note>
    </Notes>
    <CVE>CVE-2025-40036</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: nfc: nci: Add parameter validation for packet data

Syzbot reported an uninitialized value bug in nci_init_req, which was
introduced by commit 5aca7966d2a7 ("Merge tag
'perf-tools-fixes-for-v6.17-2025-09-16' of
git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools").

This bug arises due to very limited and poor input validation
that was done at nic_valid_size(). This validation only
validates the skb-&gt;len (directly reflects size provided at the
userspace interface) with the length provided in the buffer
itself (interpreted as NCI_HEADER). This leads to the processing
of memory content at the address assuming the correct layout
per what opcode requires there. This leads to the accesses to
buffer of `skb_buff-&gt;data` which is not assigned anything yet.

Following the same silent drop of packets of invalid sizes at
`nic_valid_size()`, add validation of the data in the respective
handlers and return error values in case of failure. Release
the skb if error values are returned from handlers in
`nci_nft_packet` and effectively do a silent drop

Possible TODO: because we silently drop the packets, the
call to `nci_request` will be waiting for completion of request
and will face timeouts. These timeouts can get excessively logged
in the dmesg. A proper handling of them may require to export
`nci_request_cancel` (or propagate error handling from the
nft packets handlers).</Note>
    </Notes>
    <CVE>CVE-2025-40043</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: udf: fix OOB read in lengthAllocDescs handling

When parsing Allocation Extent Descriptor, lengthAllocDescs comes from
on-disk data and must be validated against the block size. Crafted or
corrupted images may set lengthAllocDescs so that the total descriptor
length (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer,
leading udf_update_tag() to call crc_itu_t() on out-of-bounds memory and
trigger a KASAN use-after-free read.

BUG: KASAN: use-after-free in crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60
Read of size 1 at addr ffff888041e7d000 by task syz-executor317/5309

CPU: 0 UID: 0 PID: 5309 Comm: syz-executor317 Not tainted 6.12.0-rc4-syzkaller-00261-g850925a8133c #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0x169/0x550 mm/kasan/report.c:488
 kasan_report+0x143/0x180 mm/kasan/report.c:601
 crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60
 udf_update_tag+0x70/0x6a0 fs/udf/misc.c:261
 udf_write_aext+0x4d8/0x7b0 fs/udf/inode.c:2179
 extent_trunc+0x2f7/0x4a0 fs/udf/truncate.c:46
 udf_truncate_tail_extent+0x527/0x7e0 fs/udf/truncate.c:106
 udf_release_file+0xc1/0x120 fs/udf/file.c:185
 __fput+0x23f/0x880 fs/file_table.c:431
 task_work_run+0x24f/0x310 kernel/task_work.c:239
 exit_task_work include/linux/task_work.h:43 [inline]
 do_exit+0xa2f/0x28e0 kernel/exit.c:939
 do_group_exit+0x207/0x2c0 kernel/exit.c:1088
 __do_sys_exit_group kernel/exit.c:1099 [inline]
 __se_sys_exit_group kernel/exit.c:1097 [inline]
 __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097
 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232
 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;

Validate the computed total length against epos-&gt;bh-&gt;b_size.

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

Squashfs: fix uninit-value in squashfs_get_parent

Syzkaller reports a "KMSAN: uninit-value in squashfs_get_parent" bug.

This is caused by open_by_handle_at() being called with a file handle
containing an invalid parent inode number.  In particular the inode number
is that of a symbolic link, rather than a directory.

Squashfs_get_parent() gets called with that symbolic link inode, and
accesses the parent member field.

	unsigned int parent_ino = squashfs_i(inode)-&gt;parent;

Because non-directory inodes in Squashfs do not have a parent value, this
is uninitialised, and this causes an uninitialised value access.

The fix is to initialise parent with the invalid inode 0, which will cause
an EINVAL error to be returned.

Regular inodes used to share the parent field with the block_list_start
field.  This is removed in this commit to enable the parent field to
contain the invalid inode number 0.</Note>
    </Notes>
    <CVE>CVE-2025-40049</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vhost: vringh: Modify the return value check

The return value of copy_from_iter and copy_to_iter can't be negative,
check whether the copied lengths are equal.</Note>
    </Notes>
    <CVE>CVE-2025-40051</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 crypto buffers in non-linear memory

The crypto API, through the scatterlist API, expects input buffers to be
in linear memory.  We handle this with the cifs_sg_set_buf() helper
that converts vmalloc'd memory to their corresponding pages.

However, when we allocate our aead_request buffer (@creq in
smb2ops.c::crypt_message()), we do so with kvzalloc(), which possibly
puts aead_request-&gt;__ctx in vmalloc area.

AEAD algorithm then uses -&gt;__ctx for its private/internal data and
operations, and uses sg_set_buf() for such data on a few places.

This works fine as long as @creq falls into kmalloc zone (small
requests) or vmalloc'd memory is still within linear range.

Tasks' stacks are vmalloc'd by default (CONFIG_VMAP_STACK=y), so too
many tasks will increment the base stacks' addresses to a point where
virt_addr_valid(buf) will fail (BUG() in sg_set_buf()) when that
happens.

In practice: too many parallel reads and writes on an encrypted mount
will trigger this bug.

To fix this, always alloc @creq with kmalloc() instead.
Also drop the @sensitive_size variable/arguments since
kfree_sensitive() doesn't need it.

Backtrace:

[  945.272081] ------------[ cut here ]------------
[  945.272774] kernel BUG at include/linux/scatterlist.h:209!
[  945.273520] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI
[  945.274412] CPU: 7 UID: 0 PID: 56 Comm: kworker/u33:0 Kdump: loaded Not tainted 6.15.0-lku-11779-g8e9d6efccdd7-dirty #1 PREEMPT(voluntary)
[  945.275736] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014
[  945.276877] Workqueue: writeback wb_workfn (flush-cifs-2)
[  945.277457] RIP: 0010:crypto_gcm_init_common+0x1f9/0x220
[  945.278018] Code: b0 00 00 00 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 c7 c0 00 00 00 80 48 2b 05 5c 58 e5 00 e9 58 ff ff ff &lt;0f&gt; 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 48 c7 04 24 01 00 00 00 48 8b
[  945.279992] RSP: 0018:ffffc90000a27360 EFLAGS: 00010246
[  945.280578] RAX: 0000000000000000 RBX: ffffc90001d85060 RCX: 0000000000000030
[  945.281376] RDX: 0000000000080000 RSI: 0000000000000000 RDI: ffffc90081d85070
[  945.282145] RBP: ffffc90001d85010 R08: ffffc90001d85000 R09: 0000000000000000
[  945.282898] R10: ffffc90001d85090 R11: 0000000000001000 R12: ffffc90001d85070
[  945.283656] R13: ffff888113522948 R14: ffffc90001d85060 R15: ffffc90001d85010
[  945.284407] FS:  0000000000000000(0000) GS:ffff8882e66cf000(0000) knlGS:0000000000000000
[  945.285262] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  945.285884] CR2: 00007fa7ffdd31f4 CR3: 000000010540d000 CR4: 0000000000350ef0
[  945.286683] Call Trace:
[  945.286952]  &lt;TASK&gt;
[  945.287184]  ? crypt_message+0x33f/0xad0 [cifs]
[  945.287719]  crypto_gcm_encrypt+0x36/0xe0
[  945.288152]  crypt_message+0x54a/0xad0 [cifs]
[  945.288724]  smb3_init_transform_rq+0x277/0x300 [cifs]
[  945.289300]  smb_send_rqst+0xa3/0x160 [cifs]
[  945.289944]  cifs_call_async+0x178/0x340 [cifs]
[  945.290514]  ? __pfx_smb2_writev_callback+0x10/0x10 [cifs]
[  945.291177]  smb2_async_writev+0x3e3/0x670 [cifs]
[  945.291759]  ? find_held_lock+0x32/0x90
[  945.292212]  ? netfs_advance_write+0xf2/0x310
[  945.292723]  netfs_advance_write+0xf2/0x310
[  945.293210]  netfs_write_folio+0x346/0xcc0
[  945.293689]  ? __pfx__raw_spin_unlock_irq+0x10/0x10
[  945.294250]  netfs_writepages+0x117/0x460
[  945.294724]  do_writepages+0xbe/0x170
[  945.295152]  ? find_held_lock+0x32/0x90
[  945.295600]  ? kvm_sched_clock_read+0x11/0x20
[  945.296103]  __writeback_single_inode+0x56/0x4b0
[  945.296643]  writeback_sb_inodes+0x229/0x550
[  945.297140]  __writeback_inodes_wb+0x4c/0xe0
[  945.297642]  wb_writeback+0x2f1/0x3f0
[  945.298069]  wb_workfn+0x300/0x490
[  945.298472]  process_one_work+0x1fe/0x590
[  945.298949]  worker_thread+0x1ce/0x3c0
[  945.299397]  ? __pfx_worker_thread+0x10/0x10
[  945.299900]  kthr
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-40052</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vhost: vringh: Fix copy_to_iter return value check

The return value of copy_to_iter can't be negative, check whether the
copied length is equal to the requested length instead of checking for
negative values.</Note>
    </Notes>
    <CVE>CVE-2025-40056</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Disallow dirty tracking if incoherent page walk

Dirty page tracking relies on the IOMMU atomically updating the dirty bit
in the paging-structure entry. For this operation to succeed, the paging-
structure memory must be coherent between the IOMMU and the CPU. In
another word, if the iommu page walk is incoherent, dirty page tracking
doesn't work.

The Intel VT-d specification, Section 3.10 "Snoop Behavior" states:

"Remapping hardware encountering the need to atomically update A/EA/D bits
 in a paging-structure entry that is not snooped will result in a non-
 recoverable fault."

To prevent an IOMMU from being incorrectly configured for dirty page
tracking when it is operating in an incoherent mode, mark SSADS as
supported only when both ecap_slads and ecap_smpwc are supported.</Note>
    </Notes>
    <CVE>CVE-2025-40058</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

coresight: trbe: Return NULL pointer for allocation failures

When the TRBE driver fails to allocate a buffer, it currently returns
the error code "-ENOMEM". However, the caller etm_setup_aux() only
checks for a NULL pointer, so it misses the error. As a result, the
driver continues and eventually causes a kernel panic.

Fix this by returning a NULL pointer from arm_trbe_alloc_buffer() on
allocation failures. This allows that the callers can properly handle
the failure.</Note>
    </Notes>
    <CVE>CVE-2025-40060</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 race in do_task() when draining

When do_task() exhausts its iteration budget (!ret), it sets the state
to TASK_STATE_IDLE to reschedule, without a secondary check on the
current task-&gt;state. This can overwrite the TASK_STATE_DRAINING state
set by a concurrent call to rxe_cleanup_task() or rxe_disable_task().

While state changes are protected by a spinlock, both rxe_cleanup_task()
and rxe_disable_task() release the lock while waiting for the task to
finish draining in the while(!is_done(task)) loop. The race occurs if
do_task() hits its iteration limit and acquires the lock in this window.
The cleanup logic may then proceed while the task incorrectly
reschedules itself, leading to a potential use-after-free.

This bug was introduced during the migration from tasklets to workqueues,
where the special handling for the draining case was lost.

Fix this by restoring the original pre-migration behavior. If the state is
TASK_STATE_DRAINING when iterations are exhausted, set cont to 1 to
force a new loop iteration. This allows the task to finish its work, so
that a subsequent iteration can reach the switch statement and correctly
transition the state to TASK_STATE_DRAINED, stopping the task as intended.</Note>
    </Notes>
    <CVE>CVE-2025-40061</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: hisilicon/qm - set NULL to qm-&gt;debug.qm_diff_regs

When the initialization of qm-&gt;debug.acc_diff_reg fails,
the probe process does not exit. However, after qm-&gt;debug.qm_diff_regs is
freed, it is not set to NULL. This can lead to a double free when the
remove process attempts to free it again. Therefore, qm-&gt;debug.qm_diff_regs
should be set to NULL after it is freed.</Note>
    </Notes>
    <CVE>CVE-2025-40062</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tty: n_gsm: Don't block input queue by waiting MSC

Currently gsm_queue() processes incoming frames and when opening
a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update().
If basic mode is used it calls gsm_modem_upd_via_msc() and it
cannot block the input queue by waiting the response to come
into the same input queue.

Instead allow sending Modem Status Command without waiting for remote
end to respond. Define a new function gsm_modem_send_initial_msc()
for this purpose. As MSC is only valid for basic encoding, it does
not do anything for advanced or when convergence layer type 2 is used.</Note>
    </Notes>
    <CVE>CVE-2025-40071</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Explicitly check accesses to bpf_sock_addr

Syzkaller found a kernel warning on the following sock_addr program:

    0: r0 = 0
    1: r2 = *(u32 *)(r1 +60)
    2: exit

which triggers:

    verifier bug: error during ctx access conversion (0)

This is happening because offset 60 in bpf_sock_addr corresponds to an
implicit padding of 4 bytes, right after msg_src_ip4. Access to this
padding isn't rejected in sock_addr_is_valid_access and it thus later
fails to convert the access.

This patch fixes it by explicitly checking the various fields of
bpf_sock_addr in sock_addr_is_valid_access.

I checked the other ctx structures and is_valid_access functions and
didn't find any other similar cases. Other cases of (properly handled)
padding are covered in new tests in a subsequent patch.</Note>
    </Notes>
    <CVE>CVE-2025-40078</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: restrict sockets to TCP and UDP

Recently, syzbot started to abuse NBD with all kinds of sockets.

Commit cf1b2326b734 ("nbd: verify socket is supported during setup")
made sure the socket supported a shutdown() method.

Explicitely accept TCP and UNIX stream sockets.</Note>
    </Notes>
    <CVE>CVE-2025-40080</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()

BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186
Read of size 2 at addr ffff8880289ef218 by task syz.6.248/14290

CPU: 0 UID: 0 PID: 14290 Comm: syz.6.248 Not tainted 6.16.4 #1 PREEMPT(full)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0xca/0x5f0 mm/kasan/report.c:482
 kasan_report+0xca/0x100 mm/kasan/report.c:595
 hfsplus_uni2asc+0xa71/0xb90 fs/hfsplus/unicode.c:186
 hfsplus_listxattr+0x5b6/0xbd0 fs/hfsplus/xattr.c:738
 vfs_listxattr+0xbe/0x140 fs/xattr.c:493
 listxattr+0xee/0x190 fs/xattr.c:924
 filename_listxattr fs/xattr.c:958 [inline]
 path_listxattrat+0x143/0x360 fs/xattr.c:988
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fe0e9fae16d
Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fe0eae67f98 EFLAGS: 00000246 ORIG_RAX: 00000000000000c3
RAX: ffffffffffffffda RBX: 00007fe0ea205fa0 RCX: 00007fe0e9fae16d
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000200000000000
RBP: 00007fe0ea0480f0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fe0ea206038 R14: 00007fe0ea205fa0 R15: 00007fe0eae48000
 &lt;/TASK&gt;

Allocated by task 14290:
 kasan_save_stack+0x24/0x50 mm/kasan/common.c:47
 kasan_save_track+0x14/0x30 mm/kasan/common.c:68
 poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
 __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394
 kasan_kmalloc include/linux/kasan.h:260 [inline]
 __do_kmalloc_node mm/slub.c:4333 [inline]
 __kmalloc_noprof+0x219/0x540 mm/slub.c:4345
 kmalloc_noprof include/linux/slab.h:909 [inline]
 hfsplus_find_init+0x95/0x1f0 fs/hfsplus/bfind.c:21
 hfsplus_listxattr+0x331/0xbd0 fs/hfsplus/xattr.c:697
 vfs_listxattr+0xbe/0x140 fs/xattr.c:493
 listxattr+0xee/0x190 fs/xattr.c:924
 filename_listxattr fs/xattr.c:958 [inline]
 path_listxattrat+0x143/0x360 fs/xattr.c:988
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xcb/0x4c0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

When hfsplus_uni2asc is called from hfsplus_listxattr,
it actually passes in a struct hfsplus_attr_unistr*.
The size of the corresponding structure is different from that of hfsplus_unistr,
so the previous fix (94458781aee6) is insufficient.
The pointer on the unicode buffer is still going beyond the allocated memory.

This patch introduces two warpper functions hfsplus_uni2asc_xattr_str and
hfsplus_uni2asc_str to process two unicode buffers,
struct hfsplus_attr_unistr* and struct hfsplus_unistr* respectively.
When ustrlen value is bigger than the allocated memory size,
the ustrlen value is limited to an safe size.</Note>
    </Notes>
    <CVE>CVE-2025-40082</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb-audio: Fix NULL pointer deference in try_to_register_card

In try_to_register_card(), the return value of usb_ifnum_to_if() is
passed directly to usb_interface_claimed() without a NULL check, which
will lead to a NULL pointer dereference when creating an invalid
USB audio device. Fix this by adding a check to ensure the interface
pointer is valid before passing it to usb_interface_claimed().</Note>
    </Notes>
    <CVE>CVE-2025-40085</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Define a proc_layoutcommit for the FlexFiles layout type

Avoid a crash if a pNFS client should happen to send a LAYOUTCOMMIT
operation on a FlexFiles layout.</Note>
    </Notes>
    <CVE>CVE-2025-40087</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hfsplus: fix slab-out-of-bounds read in hfsplus_strcasecmp()

The hfsplus_strcasecmp() logic can trigger the issue:

[  117.317703][ T9855] ==================================================================
[  117.318353][ T9855] BUG: KASAN: slab-out-of-bounds in hfsplus_strcasecmp+0x1bc/0x490
[  117.318991][ T9855] Read of size 2 at addr ffff88802160f40c by task repro/9855
[  117.319577][ T9855]
[  117.319773][ T9855] CPU: 0 UID: 0 PID: 9855 Comm: repro Not tainted 6.17.0-rc6 #33 PREEMPT(full)
[  117.319780][ T9855] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[  117.319783][ T9855] Call Trace:
[  117.319785][ T9855]  &lt;TASK&gt;
[  117.319788][ T9855]  dump_stack_lvl+0x1c1/0x2a0
[  117.319795][ T9855]  ? __virt_addr_valid+0x1c8/0x5c0
[  117.319803][ T9855]  ? __pfx_dump_stack_lvl+0x10/0x10
[  117.319808][ T9855]  ? rcu_is_watching+0x15/0xb0
[  117.319816][ T9855]  ? lock_release+0x4b/0x3e0
[  117.319821][ T9855]  ? __kasan_check_byte+0x12/0x40
[  117.319828][ T9855]  ? __virt_addr_valid+0x1c8/0x5c0
[  117.319835][ T9855]  ? __virt_addr_valid+0x4a5/0x5c0
[  117.319842][ T9855]  print_report+0x17e/0x7e0
[  117.319848][ T9855]  ? __virt_addr_valid+0x1c8/0x5c0
[  117.319855][ T9855]  ? __virt_addr_valid+0x4a5/0x5c0
[  117.319862][ T9855]  ? __phys_addr+0xd3/0x180
[  117.319869][ T9855]  ? hfsplus_strcasecmp+0x1bc/0x490
[  117.319876][ T9855]  kasan_report+0x147/0x180
[  117.319882][ T9855]  ? hfsplus_strcasecmp+0x1bc/0x490
[  117.319891][ T9855]  hfsplus_strcasecmp+0x1bc/0x490
[  117.319900][ T9855]  ? __pfx_hfsplus_cat_case_cmp_key+0x10/0x10
[  117.319906][ T9855]  hfs_find_rec_by_key+0xa9/0x1e0
[  117.319913][ T9855]  __hfsplus_brec_find+0x18e/0x470
[  117.319920][ T9855]  ? __pfx_hfsplus_bnode_find+0x10/0x10
[  117.319926][ T9855]  ? __pfx_hfs_find_rec_by_key+0x10/0x10
[  117.319933][ T9855]  ? __pfx___hfsplus_brec_find+0x10/0x10
[  117.319942][ T9855]  hfsplus_brec_find+0x28f/0x510
[  117.319949][ T9855]  ? __pfx_hfs_find_rec_by_key+0x10/0x10
[  117.319956][ T9855]  ? __pfx_hfsplus_brec_find+0x10/0x10
[  117.319963][ T9855]  ? __kmalloc_noprof+0x2a9/0x510
[  117.319969][ T9855]  ? hfsplus_find_init+0x8c/0x1d0
[  117.319976][ T9855]  hfsplus_brec_read+0x2b/0x120
[  117.319983][ T9855]  hfsplus_lookup+0x2aa/0x890
[  117.319990][ T9855]  ? __pfx_hfsplus_lookup+0x10/0x10
[  117.320003][ T9855]  ? d_alloc_parallel+0x2f0/0x15e0
[  117.320008][ T9855]  ? __lock_acquire+0xaec/0xd80
[  117.320013][ T9855]  ? __pfx_d_alloc_parallel+0x10/0x10
[  117.320019][ T9855]  ? __raw_spin_lock_init+0x45/0x100
[  117.320026][ T9855]  ? __init_waitqueue_head+0xa9/0x150
[  117.320034][ T9855]  __lookup_slow+0x297/0x3d0
[  117.320039][ T9855]  ? __pfx___lookup_slow+0x10/0x10
[  117.320045][ T9855]  ? down_read+0x1ad/0x2e0
[  117.320055][ T9855]  lookup_slow+0x53/0x70
[  117.320065][ T9855]  walk_component+0x2f0/0x430
[  117.320073][ T9855]  path_lookupat+0x169/0x440
[  117.320081][ T9855]  filename_lookup+0x212/0x590
[  117.320089][ T9855]  ? __pfx_filename_lookup+0x10/0x10
[  117.320098][ T9855]  ? strncpy_from_user+0x150/0x290
[  117.320105][ T9855]  ? getname_flags+0x1e5/0x540
[  117.320112][ T9855]  user_path_at+0x3a/0x60
[  117.320117][ T9855]  __x64_sys_umount+0xee/0x160
[  117.320123][ T9855]  ? __pfx___x64_sys_umount+0x10/0x10
[  117.320129][ T9855]  ? do_syscall_64+0xb7/0x3a0
[  117.320135][ T9855]  ? entry_SYSCALL_64_after_hwframe+0x77/0x7f
[  117.320141][ T9855]  ? entry_SYSCALL_64_after_hwframe+0x77/0x7f
[  117.320145][ T9855]  do_syscall_64+0xf3/0x3a0
[  117.320150][ T9855]  ? exc_page_fault+0x9f/0xf0
[  117.320154][ T9855]  entry_SYSCALL_64_after_hwframe+0x77/0x7f
[  117.320158][ T9855] RIP: 0033:0x7f7dd7908b07
[  117.320163][ T9855] Code: 23 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 08
[  117.320167][ T9855] RSP: 002b:00007ffd5ebd9698 EFLAGS: 00000202 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-40088</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 potential double free in drm_sched_job_add_resv_dependencies

When adding dependencies with drm_sched_job_add_dependency(), that
function consumes the fence reference both on success and failure, so in
the latter case the dma_fence_put() on the error path (xarray failed to
expand) is a double free.

Interestingly this bug appears to have been present ever since
commit ebd5f74255b9 ("drm/sched: Add dependency tracking"), since the code
back then looked like this:

drm_sched_job_add_implicit_dependencies():
...
       for (i = 0; i &lt; fence_count; i++) {
               ret = drm_sched_job_add_dependency(job, fences[i]);
               if (ret)
                       break;
       }

       for (; i &lt; fence_count; i++)
               dma_fence_put(fences[i]);

Which means for the failing 'i' the dma_fence_put was already a double
free. Possibly there were no users at that time, or the test cases were
insufficient to hit it.

The bug was then only noticed and fixed after
commit 9c2ba265352a ("drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2")
landed, with its fixup of
commit 4eaf02d6076c ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies").

At that point it was a slightly different flavour of a double free, which
commit 963d0b356935 ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder")
noticed and attempted to fix.

But it only moved the double free from happening inside the
drm_sched_job_add_dependency(), when releasing the reference not yet
obtained, to the caller, when releasing the reference already released by
the former in the failure case.

As such it is not easy to identify the right target for the fixes tag so
lets keep it simple and just continue the chain.

While fixing we also improve the comment and explain the reason for taking
the reference and not dropping it.</Note>
    </Notes>
    <CVE>CVE-2025-40096</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: do not assert we found block group item when creating free space tree

Currently, when building a free space tree at populate_free_space_tree(),
if we are not using the block group tree feature, we always expect to find
block group items (either extent items or a block group item with key type
BTRFS_BLOCK_GROUP_ITEM_KEY) when we search the extent tree with
btrfs_search_slot_for_read(), so we assert that we found an item. However
this expectation is wrong since we can have a new block group created in
the current transaction which is still empty and for which we still have
not added the block group's item to the extent tree, in which case we do
not have any items in the extent tree associated to the block group.

The insertion of a new block group's block group item in the extent tree
happens at btrfs_create_pending_block_groups() when it calls the helper
insert_block_group_item(). This typically is done when a transaction
handle is released, committed or when running delayed refs (either as
part of a transaction commit or when serving tickets for space reservation
if we are low on free space).

So remove the assertion at populate_free_space_tree() even when the block
group tree feature is not enabled and update the comment to mention this
case.

Syzbot reported this with the following stack trace:

  BTRFS info (device loop3 state M): rebuilding free space tree
  assertion failed: ret == 0 :: 0, in fs/btrfs/free-space-tree.c:1115
  ------------[ cut here ]------------
  kernel BUG at fs/btrfs/free-space-tree.c:1115!
  Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
  CPU: 1 UID: 0 PID: 6352 Comm: syz.3.25 Not tainted syzkaller #0 PREEMPT(full)
  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
  RIP: 0010:populate_free_space_tree+0x700/0x710 fs/btrfs/free-space-tree.c:1115
  Code: ff ff e8 d3 (...)
  RSP: 0018:ffffc9000430f780 EFLAGS: 00010246
  RAX: 0000000000000043 RBX: ffff88805b709630 RCX: fea61d0e2e79d000
  RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
  RBP: ffffc9000430f8b0 R08: ffffc9000430f4a7 R09: 1ffff92000861e94
  R10: dffffc0000000000 R11: fffff52000861e95 R12: 0000000000000001
  R13: 1ffff92000861f00 R14: dffffc0000000000 R15: 0000000000000000
  FS:  00007f424d9fe6c0(0000) GS:ffff888125afc000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007fd78ad212c0 CR3: 0000000076d68000 CR4: 00000000003526f0
  Call Trace:
   &lt;TASK&gt;
   btrfs_rebuild_free_space_tree+0x1ba/0x6d0 fs/btrfs/free-space-tree.c:1364
   btrfs_start_pre_rw_mount+0x128f/0x1bf0 fs/btrfs/disk-io.c:3062
   btrfs_remount_rw fs/btrfs/super.c:1334 [inline]
   btrfs_reconfigure+0xaed/0x2160 fs/btrfs/super.c:1559
   reconfigure_super+0x227/0x890 fs/super.c:1076
   do_remount fs/namespace.c:3279 [inline]
   path_mount+0xd1a/0xfe0 fs/namespace.c:4027
   do_mount fs/namespace.c:4048 [inline]
   __do_sys_mount fs/namespace.c:4236 [inline]
   __se_sys_mount+0x313/0x410 fs/namespace.c:4213
   do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
   do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
   entry_SYSCALL_64_after_hwframe+0x77/0x7f
   RIP: 0033:0x7f424e39066a
  Code: d8 64 89 02 (...)
  RSP: 002b:00007f424d9fde68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
  RAX: ffffffffffffffda RBX: 00007f424d9fdef0 RCX: 00007f424e39066a
  RDX: 0000200000000180 RSI: 0000200000000380 RDI: 0000000000000000
  RBP: 0000200000000180 R08: 00007f424d9fdef0 R09: 0000000000000020
  R10: 0000000000000020 R11: 0000000000000246 R12: 0000200000000380
  R13: 00007f424d9fdeb0 R14: 0000000000000000 R15: 00002000000002c0
   &lt;/TASK&gt;
  Modules linked in:
  ---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2025-40100</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.</Note>
    </Notes>
    <CVE>CVE-2025-47913</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">SSH Agent servers do not validate the size of messages when processing new identity requests, which may cause the program to panic if the message is malformed due to an out of bounds read.</Note>
    </Notes>
    <CVE>CVE-2025-47914</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">runc is a CLI tool for spawning and running containers according to the OCI specification. Versions 1.0.0-rc3 through 1.2.7, 1.3.0-rc.1 through 1.3.2, and 1.4.0-rc.1 through 1.4.0-rc.2, due to insufficient checks when bind-mounting `/dev/pts/$n` to `/dev/console` inside the container, an attacker can trick runc into bind-mounting paths which would normally be made read-only or be masked onto a path that the attacker can write to. This attack is very similar in concept and application to CVE-2025-31133, except that it attacks a similar vulnerability in a different target (namely, the bind-mount of `/dev/pts/$n` to `/dev/console` as configured for all containers that allocate a console). This happens after `pivot_root(2)`, so this cannot be used to write to host files directly -- however, as with CVE-2025-31133, this can load to denial of service of the host or a container breakout by providing the attacker with a writable copy of `/proc/sysrq-trigger` or `/proc/sys/kernel/core_pattern` (respectively). This issue is fixed in versions 1.2.8, 1.3.3 and 1.4.0-rc.3.</Note>
    </Notes>
    <CVE>CVE-2025-52565</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">runc is a CLI tool for spawning and running containers according to the OCI specification. In versions 1.2.7, 1.3.2 and 1.4.0-rc.2, an attacker can trick runc into misdirecting writes to /proc to other procfs files through the use of a racing container with shared mounts (we have also verified this attack is possible to exploit using a standard Dockerfile with docker buildx build as that also permits triggering parallel execution of containers with custom shared mounts configured). This redirect could be through symbolic links in a tmpfs or theoretically other methods such as regular bind-mounts. While similar, the mitigation applied for the related CVE, CVE-2019-19921, was fairly limited and effectively only caused runc to verify that when LSM labels are written they are actually procfs files. This issue is fixed in versions 1.2.8, 1.3.3, and 1.4.0-rc.3.</Note>
    </Notes>
    <CVE>CVE-2025-52881</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in Podman. The podman machine init command fails to verify the TLS certificate when downloading the VM images from an OCI registry. This issue results in a Man In The Middle attack.</Note>
    </Notes>
    <CVE>CVE-2025-6032</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">The html.parser.HTMLParser class had worse-case quadratic complexity when processing certain crafted malformed inputs potentially leading to amplified denial-of-service.</Note>
    </Notes>
    <CVE>CVE-2025-6069</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">If the value passed to os.path.expandvars() is user-controlled a 
performance degradation is possible when expanding environment 
variables.</Note>
    </Notes>
    <CVE>CVE-2025-6075</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used. The untrusted sources are the command line and %-sequence expansion of a configuration file. (A configuration file that provides a complete literal username is not categorized as an untrusted source.)</Note>
    </Notes>
    <CVE>CVE-2025-61984</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">ssh in OpenSSH before 10.1 allows the '\0' character in an ssh:// URI, potentially leading to code execution when a ProxyCommand is used.</Note>
    </Notes>
    <CVE>CVE-2025-61985</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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. Versions 1.7.28 and below, 2.0.0-beta.0 through 2.0.6, 2.1.0-beta.0 through 2.1.4, and 2.2.0-beta.0 through 2.2.0-rc.1 contain a bug in the CRI Attach implementation where a user can exhaust memory on the host due to goroutine leaks. This issue is fixed in versions 1.7.29, 2.0.7, 2.1.5 and 2.2.0. To workaround this vulnerability, users can set up an admission controller to control accesses to pods/attach resources.</Note>
    </Notes>
    <CVE>CVE-2025-64329</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to version 1.6.51, a heap buffer over-read vulnerability exists in libpng's png_do_quantize function when processing PNG files with malformed palette indices. The vulnerability occurs when palette_lookup array bounds are not validated against externally-supplied image data, allowing an attacker to craft a PNG file with out-of-range palette indices that trigger out-of-bounds memory access. This issue has been patched in version 1.6.51.</Note>
    </Notes>
    <CVE>CVE-2025-64505</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, a heap buffer over-read vulnerability exists in libpng's png_write_image_8bit function when processing 8-bit images through the simplified write API with convert_to_8bit enabled. The vulnerability affects 8-bit grayscale+alpha, RGB/RGBA, and images with incomplete row data. A conditional guard incorrectly allows 8-bit input to enter code expecting 16-bit input, causing reads up to 2 bytes beyond allocated buffer boundaries. This issue has been patched in version 1.6.51.</Note>
    </Notes>
    <CVE>CVE-2025-64506</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, an out-of-bounds read vulnerability exists in png_image_read_composite when processing palette images with PNG_FLAG_OPTIMIZE_ALPHA enabled. The palette compositing code in png_init_read_transformations incorrectly applies background compositing during premultiplication, violating the invariant component ≤ alpha x 257 required by the simplified PNG API. This issue has been patched in version 1.6.51.</Note>
    </Notes>
    <CVE>CVE-2025-64720</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, there is a heap buffer overflow vulnerability in the libpng simplified API function png_image_finish_read when processing 16-bit interlaced PNGs with 8-bit output format. Attacker-crafted interlaced PNG files cause heap writes beyond allocated buffer bounds. This issue has been patched in version 1.6.51.</Note>
    </Notes>
    <CVE>CVE-2025-65018</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to 1.6.52, an out-of-bounds read vulnerability in libpng's simplified API allows reading up to 1012 bytes beyond the png_sRGB_base[512] array when processing valid palette PNG images with partial transparency and gamma correction. The PNG files that trigger this vulnerability are valid per the PNG specification; the bug is in libpng's internal state management. Upgrade to libpng 1.6.52 or later.</Note>
    </Notes>
    <CVE>CVE-2025-66293</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In GnuPG through 2.4.8, if a signed message has \f at the end of a plaintext line, an adversary can construct a modified message that places additional text after the signed material, such that signature verification of the modified message succeeds (although an "invalid armor" message is printed during verification). This is related to use of \f as a marker to denote truncation of a long plaintext line.</Note>
    </Notes>
    <CVE>CVE-2025-68972</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In GnuPG before 2.4.9, armor_filter in g10/armor.c has two increments of an index variable where one is intended, leading to an out-of-bounds write for crafted input. (For ExtendedLTS, 2.2.51 and later are fixed versions.)</Note>
    </Notes>
    <CVE>CVE-2025-68973</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in glib. An integer overflow during temporary file creation leads to an out-of-bounds memory access, allowing an attacker to potentially perform path traversal or access private temporary file content by creating symbolic links. This vulnerability allows a local attacker to manipulate file paths and access unauthorized data. The core issue stems from insufficient validation of file path lengths during temporary file operations.</Note>
    </Notes>
    <CVE>CVE-2025-7039</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">There is a defect in the CPython “tarfile” module affecting the “TarFile” extraction and entry enumeration APIs. The tar implementation would process tar archives with negative offsets without error, resulting in an infinite loop and deadlock during the parsing of maliciously crafted tar archives. 

This vulnerability can be mitigated by including the following patch after importing the “tarfile” module:   https://gist.github.com/sethmlarson/1716ac5b82b73dbcbf23ad2eff8b33e1</Note>
    </Notes>
    <CVE>CVE-2025-8194</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">The 'zipfile' module would not check the validity of the ZIP64 End of
Central Directory (EOCD) Locator record offset value would not be used to
locate the ZIP64 EOCD record, instead the ZIP64 EOCD record would be
assumed to be the previous record in the ZIP archive. This could be abused
to create ZIP archives that are handled differently by the 'zipfile' module
compared to other ZIP implementations.


Remediation maintains this behavior, but checks that the offset specified
in the ZIP64 EOCD Locator record matches the expected value.</Note>
    </Notes>
    <CVE>CVE-2025-8291</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">There's a vulnerability in podman where an attacker may use the kube play command to overwrite host files when the kube file container a Secrete or a ConfigMap volume mount and such volume contains a symbolic link to a host file path. In a successful attack, the attacker can only control the target file to be overwritten but not the content to be written into the file.

Binary-Affected: podman
Upstream-version-introduced: v4.0.0
Upstream-version-fixed: v5.6.1</Note>
    </Notes>
    <CVE>CVE-2025-9566</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in the GnuTLS library, specifically in the gnutls_pkcs11_token_init() function that handles PKCS#11 token initialization. When a token label longer than expected is processed, the function writes past the end of a fixed-size stack buffer. This programming error can cause the application using GnuTLS to crash or, in certain conditions, be exploited for code execution. As a result, systems or applications relying on GnuTLS may be vulnerable to a denial of service or local privilege escalation attacks.</Note>
    </Notes>
    <CVE>CVE-2025-9820</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">urllib3 is an HTTP client library for Python. urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. urllib3 can perform decoding or decompression based on the HTTP `Content-Encoding` header (e.g., `gzip`, `deflate`, `br`, or `zstd`). When using the streaming API, the library decompresses only the necessary bytes, enabling partial content consumption. Starting in version 1.22 and prior to version 2.6.3, for HTTP redirect responses, the library would read the entire response body to drain the connection and decompress the content unnecessarily. This decompression occurred even before any read methods were called, and configured read limits did not restrict the amount of decompressed data. As a result, there was no safeguard against decompression bombs. A malicious server could exploit this to trigger excessive resource consumption on the client. Applications and libraries are affected when they stream content from untrusted sources by setting `preload_content=False` when they do not disable redirects. Users should upgrade to at least urllib3 v2.6.3, in which the library does not decode content of redirect responses when `preload_content=False`. If upgrading is not immediately possible, disable redirects by setting `redirect=False` for requests to untrusted source.</Note>
    </Notes>
    <CVE>CVE-2026-21441</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
</cvrfdoc>
