<?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:344-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:344-1</ID>
    </Identification>
    <Status>Interim</Status>
    <Version>1</Version>
    <RevisionHistory>
      <Revision>
        <Number>1</Number>
        <Date>2026-03-19T09:01:40Z</Date>
        <Description>current</Description>
      </Revision>
    </RevisionHistory>
    <InitialReleaseDate>2026-01-23T01:00:00Z</InitialReleaseDate>
    <CurrentReleaseDate>2026-01-23T01: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:344-1 / google/sles-sap-15-sp6-v20260123-x86-64</Note>
    <Note Title="Details" Type="General" Ordinal="2" xml:lang="en">This image update for google/sles-sap-15-sp6-v20260123-x86-64 contains the following changes:
Package bash was updated:

- Add patch bsc1245199.patch  * Fix histfile missing timestamp for the oldest record (bsc#1245199)

Package bind was updated:

- Security Fixes:  * DNSSEC validation fails if matching but invalid DNSKEY is found.
    [CVE-2025-8677, bsc#1252378, bind-9.18-CVE-2025-8677.patch]
  * Address various spoofing attacks.
    [CVE-2025-40778, bsc#1252379, bind-9.18-CVE-2025-40778.patch]
  * Cache-poisoning due to weak pseudo-random number generator.
    [CVE-2025-40780, bsc#1252380, bind-9.18-CVE-2025-40780.patch]

Package binutils was updated:

- Update to current 2.45 branch at 94cb1c075 to include fix  for PR33584 (a problem related to LTO vs fortran COMMON
  blocks).

- Amend binutils-compat-old-behaviour.diff to not enable
  '-z gcs=implicit' on aarch64 for old codestreams.

- Update to version 2.45:
  * New versioned release of libsframe.so.2
  * s390: tools now support SFrame format 2; recognize &amp;quot;z17&amp;quot; as CPU
    name [bsc#1247105, jsc#IBM-1485]
  * sframe sections are now of ELF section type SHT_GNU_SFRAME.
  * sframe secions generated by the assembler have
    SFRAME_F_FDE_FUNC_START_PCREL set.
  * riscv: Support more extensions: standard: Zicfiss v1.0, Zicfilp v1.0,
    Zcmp v1.0, Zcmt v1.0, Smrnmi v1.0, S[sm]dbltrp v1.0, S[sm]ctr v1.0,
    ssqosid v1.0, ssnpm v1.0, smnpm v1.0, smmpm v1.0, sspm v1.0, supm v1.0,
    sha v1.0, zce v1.0, smcdeleg v1.0, ssccfg v1.0, svvptc v1.0, zilsd v1.0,
    zclsd v1.0, smrnmi v1.0;
    vendor: CORE-V, xcvbitmanip v1.0 and xcvsimd v1.0;
    SiFive, xsfvqmaccdod v1.0, xsfvqmaccqoqv1.0 and xsfvfnrclipxfqf v1.0;
    T-Head: xtheadvdot v1.0;
    MIPS: xmipscbop v1.0, xmipscmov v1.0, xmipsexectl v1.0, xmipslsp v1.0.
  * Support RISC-V privileged version 1.13, profiles 20/22/23, and
    .bfloat16 directive.
  * x86: Add support for these ISAs: Intel Diamond Rapids AMX, MOVRS,
    AVX10.2 (including SM4), MSR_IMM; Zhaoxin PadLock PHE2, RNG2, GMI, XMODX.
    Drop support for  AVX10.2 256 bit rounding.
  * arm: Add support for most of Armv9.6, enabled by -march=armv9.6-a and
    extensions '+cmpbr', '+f8f16mm', '+f8f32mm', '+fprcvt', '+lsfe', '+lsui',
    '+occmo', '+pops', '+sme2p2', '+ssve-aes', '+sve-aes', '+sve-aes2',
    '+sve-bfscale', '+sve-f16f32mm' and '+sve2p2'.
  * Predefined symbols &amp;quot;GAS(version)&amp;quot; and, on non-release builds, &amp;quot;GAS(date)&amp;quot;
    are now being made available.
  * Add .errif and .warnif directives.
  * linker:
  - Add --image-base=&amp;lt;ADDR&amp;gt; option to the ELF linker to behave the same
    as -Ttext-segment for compatibility with LLD.
  - Add support for mixed LTO and non-LTO codes in relocatable output.
  - s390: linker generates .eh_frame and/or .sframe for linker
    generated .plt sections by default (can be disabled
    by --no-ld-generated-unwind-info).
  - riscv: add new PLT formats, and GNU property merge rules for zicfiss
    and zicfilp extensions.
- gold is no longer included
- Contains fixes for these non-CVEs (not security bugs per upstreams
  SECURITY.md):
  * bsc#1236632 aka CVE-2025-0840 aka PR32560
  * bsc#1236977 aka CVE-2025-1149 aka PR32576
  * bsc#1236978 aka CVE-2025-1148 aka PR32576
  * bsc#1236999 aka CVE-2025-1176 aka PR32636
  * bsc#1237000 aka CVE-2025-1153 aka PR32603
  * bsc#1237001 aka CVE-2025-1152 aka PR32576
  * bsc#1237003 aka CVE-2025-1151 aka PR32576
  * bsc#1237005 aka CVE-2025-1150 aka PR32576
  * bsc#1237018 aka CVE-2025-1178 aka PR32638
  * bsc#1237019 aka CVE-2025-1181 aka PR32643
  * bsc#1237020 aka CVE-2025-1180 aka PR32642
  * bsc#1237021 aka CVE-2025-1179 aka PR32640
  * bsc#1237042 aka CVE-2025-1182 aka PR32644
  * bsc#1240870 aka CVE-2025-3198 aka PR32716
  * bsc#1243756 aka CVE-2025-5244 aka PR32858
  * bsc#1243760 aka CVE-2025-5245 aka PR32829
  * bsc#1246481 aka CVE-2025-7545 aka PR33049
  * bsc#1246486 aka CVE-2025-7546 aka PR33050
  * bsc#1247114 aka CVE-2025-8224 aka PR32109
  * bsc#1247117 aka CVE-2025-8225 no PR
- Add these backport patches:
  * pr32556.diff for bsc#1236976 aka CVE-2025-1147 aka PR32556
  * pr33457.diff for bsc#1250632 aka CVE-2025-11083 aka PR33457
  * pr33452.diff for bsc#1251275 aka CVE-2025-11412 aka PR33452
  * pr33456.diff and pr33456-2.diff for bsc#1251276 aka CVE-2025-11413
    aka PR33456
  * pr33450.diff for bsc#1251277 aka CVE-2025-11414 aka PR33450
  * pr33499.diff for bsc#1251794 aka CVE-2025-11494 aka PR33499
  * pr33502.diff for bsc#1251795 aka CVE-2025-11495 aka PR33502
- Adjust binutils-disable-code-arch-error.diff,
  binutils-revert-nm-symversion.diff, binutils-revert-plt32-in-branches.diff,
  binutils-revert-rela.diff, binutils-skip-rpaths.patch
- Remove pr33029.patch (upstreamed), enable-targets-gold.diff (obsolete),
  binutils-2.43.tar.bz2.sig, binutils-2.43.tar.bz2,
  binutils-2.43-branch.diff.gz
- Add binutils-2.45.tar.bz2.sig, binutils-2.45.tar.bz2,
  binutils-2.45-branch.diff.gz
- Rename binutils-fix-branch.diff to binutils-fix-branch.diff.templ
  as long as its empty.

- Skip PGO with %want_reproducible_builds (boo#1040589)

- pr33029.patch: Fix crash in assembler with -gdwarf-5

- Drop aarch64-common-pagesize.patch, aarch64 no longer uses 64K page size

- Add -std=gnu17 to move gcc15 forward, as temporary measure until
  the binutils version can be updated [bsc#1241916].

- Do not build binutils-gold for SLFO.

- Enable multitarget build on loongarch64

- Unset SUSE_ZNOW while running testsuite, many tests cannot cope

Package chrony was updated:

- bsc#1246544: Fix racy socket creation  * Add chrony-unix-socket.patch
  * Add chrony-remove-chmod.patch
- Use make quickcheck to speedup build.

Package cifs-utils was updated:

- Add patches:  * 0001-cifs-utils-Skip-TGT-check-if-valid-service-ticket-is.patch (bsc#1248816)
  * 0001-setcifsacl-fix-memory-allocation-for-struct-cifs_ace.patch
  * 0001-cifs.upcall-fix-UAF-in-get_cachename_from_process_en.patch
  * 0001-cifs-utils-avoid-using-mktemp-when-updating-mtab.patch
  * 0001-cifs-utils-add-documentation-for-upcall_target.patch
  * 0001-cifs.upcall-fix-memory-leaks-in-check_service_ticket.patch

Package kernel-default was updated:

- ALSA: usb-audio: fix uac2 clock source at terminal parser  (git-fixes).
- commit 74497c6

- nfsd: fix return error codes for nfsd_map_name_to_id
  (bsc#1232223).
- commit 24071c5

- nfsd: do not defer requests during idmap lookup in v4 compound
  decode (bsc#1232223).
- commit 4b41b11

- tls: Use __sk_dst_get() and dst_dev_rcu() in
  get_netdev_for_sock() (CVE-2025-40149 bsc#1253355).
- commit c8fb6ed

- smc: Use __sk_dst_get() and dst_dev_rcu() in
  smc_clc_prfx_match() (CVE-2025-40168 bsc#1253427).
- commit 0f10629

- smc: Use __sk_dst_get() and dst_dev_rcu() in in
  smc_clc_prfx_set() (CVE-2025-40139 bsc#1253409).
- commit a7ae1b3

- smc: Fix use-after-free in __pnet_find_base_ndev()
  (CVE-2025-40064 bsc#1252845).
- commit 2971b90

- tcp_metrics: use dst_dev_net_rcu() (CVE-2025-40075 bsc#1252795).
- commit fcb52d9

- Update
  patches.suse/ASoC-Intel-bytcr_rt5640-Fix-invalid-quirk-input-mapp.patch
  (git-fixes CVE-2025-40154 bsc#1253431).
- Update
  patches.suse/ASoC-Intel-bytcr_rt5651-Fix-invalid-quirk-input-mapp.patch
  (git-fixes CVE-2025-40121 bsc#1253367).
- Update
  patches.suse/Bluetooth-ISO-Fix-possible-UAF-on-iso_conn_free.patch
  (git-fixes CVE-2025-40141 bsc#1253352).
- Update
  patches.suse/EDAC-i10nm-Skip-DIMM-enumeration-on-a-disabled-memor.patch
  (git-fixes CVE-2025-40157 bsc#1253423).
- Update
  patches.suse/PM-devfreq-mtk-cci-Fix-potential-error-pointer-deref.patch
  (git-fixes CVE-2025-40156 bsc#1253428).
- Update
  patches.suse/Squashfs-reject-negative-file-sizes-in-squashfs_read_inode.patch
  (git-fixes CVE-2025-40200 bsc#1253448).
- Update
  patches.suse/accel-qaic-Treat-remaining-0-as-error-in-find_and_ma.patch
  (git-fixes CVE-2025-40172 bsc#1253424).
- Update
  patches.suse/bpf-Fix-metadata_dst-leak-__bpf_redirect_neigh_v-4-6.patch
  (git-fixes CVE-2025-40183 bsc#1253441).
- Update
  patches.suse/btrfs-avoid-potential-out-of-bounds-in-btrfs_encode_.patch
  (git-fixes CVE-2025-40205 bsc#1253456).
- Update
  patches.suse/can-hi311x-fix-null-pointer-dereference-when-resumin.patch
  (stable-fixes CVE-2025-40107 bsc#1253018).
- Update
  patches.suse/cpufreq-intel_pstate-Fix-object-lifecycle-issue-in-update_qos_request.patch
  (stable-fixes git-fixes CVE-2025-40194 bsc#1253445).
- Update
  patches.suse/crypto-rng-Ensure-set_ent-is-always-present.patch
  (git-fixes CVE-2025-40109 bsc#1253176).
- Update
  patches.suse/drm-vmwgfx-Fix-Use-after-free-in-validation.patch
  (git-fixes CVE-2025-40111 bsc#1253362).
- Update
  patches.suse/drm-vmwgfx-Fix-a-null-ptr-access-in-the-cursor-snoop.patch
  (git-fixes CVE-2025-40110 bsc#1253275).
- Update
  patches.suse/ext4-avoid-potential-buffer-over-read-in-parse_apply.patch
  (git-fixes CVE-2025-40198 bsc#1253453).
- Update
  patches.suse/hwrng-ks-sa-fix-division-by-zero-in-ks_sa_rng_init.patch
  (git-fixes CVE-2025-40127 bsc#1253369).
- Update
  patches.suse/mailbox-zynqmp-ipi-Fix-out-of-bounds-access-in-mailb.patch
  (git-fixes CVE-2025-40180 bsc#1253440).
- Update
  patches.suse/media-v4l2-subdev-Fix-alloc-failure-check-in-v4l2_su.patch
  (git-fixes CVE-2025-40207 bsc#1253395).
- Update
  patches.suse/net-usb-Remove-disruptive-netif_wake_queue-in-rtl815.patch
  (git-fixes CVE-2025-40140 bsc#1253349).
- Update
  patches.suse/net-usb-asix-hold-PM-usage-ref-to-avoid-PM-MDIO-RTNL.patch
  (git-fixes CVE-2025-40120 bsc#1253360).
- Update
  patches.suse/nvmet-fc-move-lsop-put-work-to-nvmet_fc_ls_req_op.patch
  (bsc#1245193 bsc#1247500 CVE-2025-40171 bsc#1253412).
- Update
  patches.suse/pwm-berlin-Fix-wrong-register-in-suspend-resume.patch
  (git-fixes CVE-2025-40188 bsc#1253449).
- Update
  patches.suse/scsi-mpt3sas-Fix-crash-in-transport-port-remove-by-using-i.patch
  (git-fixes CVE-2025-40115 bsc#1253318).
- Update
  patches.suse/scsi-pm80xx-Fix-array-index-out-of-of-bounds-on-rmmod.patch
  (git-fixes CVE-2025-40118 bsc#1253363).
- Update
  patches.suse/sunrpc-fix-null-pointer-dereference-on-zero-length-checksum.patch
  (git-fixes CVE-2025-40129 bsc#1253472).
- Update
  patches.suse/tcp-Don-t-call-reqsk_fastopen_remove-in-tcp_conn_request.patch
  (git-fixes CVE-2025-40186 bsc#1253438).
- Update
  patches.suse/usb-host-max3421-hcd-Fix-error-pointer-dereference-i.patch
  (git-fixes CVE-2025-40116 bsc#1253324).
- Update
  patches.suse/usbnet-Fix-using-smp_processor_id-in-preemptible-cod.patch
  (git-fixes CVE-2025-40164 bsc#1253407).
- commit d8d3cd1

- ipv4: start using dst_dev_rcu() (CVE-2025-40074 bsc#1252794).
- commit d58640c

- kabi: hide dst_entry::dev_rcu (CVE-2025-40074 bsc#1252794).
- commit 7047515

- net: dst: introduce dst-&amp;gt;dev_rcu (CVE-2025-40074 bsc#1252794).
- commit bc25dd4

- net: Add locking to protect skb-&amp;gt;dev access in ip_output
  (CVE-2025-40074 bsc#1252794).
- commit ba856a3

- ipv6: ip6_mc_input() and ip6_mr_input() cleanups (CVE-2025-40074
  bsc#1252794).
- commit 74e34e6

- ipv6: adopt skb_dst_dev() and skb_dst_dev_net[_rcu]() helpers
  (CVE-2025-40074 bsc#1252794).
- commit bef51be

- ipv6: adopt dst_dev() helper (CVE-2025-40074 bsc#1252794).
- refresh patches.suse/net-ip6_tunnel-Prevent-perpetual-tunnel-growth.patch
- commit 7eda2f1

- ipv4: adopt dst_dev, skb_dst_dev and skb_dst_dev_net[_rcu]
  (CVE-2025-40074 bsc#1252794).
- commit 172fe2b

- net: dst: add four helpers to annotate data-races around
  dst-&amp;gt;dev (CVE-2025-40074 bsc#1252794).
- commit d644653

- net: dst: annotate data-races around dst-&amp;gt;output (CVE-2025-40074
  bsc#1252794).
- commit a54672b

- net: dst: annotate data-races around dst-&amp;gt;input (CVE-2025-40074
  bsc#1252794).
- commit ffc43da

- net: dst: annotate data-races around dst-&amp;gt;lastuse
  (CVE-2025-40074 bsc#1252794).
- commit 8826356

- net: dst: annotate data-races around dst-&amp;gt;expires
  (CVE-2025-40074 bsc#1252794).
- commit 2c55499

- net: dst: annotate data-races around dst-&amp;gt;obsolete
  (CVE-2025-40074 bsc#1252794).
- commit 2ab42e2

- net: ipv4: ipmr: ipmr_queue_xmit(): Drop local variable `dev'
  (CVE-2025-40074 bsc#1252794).
- commit 3c39f8c

- net: gro: convert four dev_net() calls (CVE-2025-40074
  bsc#1252794).
- commit cf41694

- tcp: convert to dev_net_rcu() (CVE-2025-40074 bsc#1252794).
- commit 2fe0b75

- net: dst_cache: annotate data-races around dst_cache-&amp;gt;reset_ts
  (CVE-2025-40074 bsc#1252794).
- commit 5a73952

- Refresh patches.suse/ALSA-usb-audio-Fix-potential-overflow-of-PCM-transfe.patch
  Fix the missing mutex unlock at the error path
- commit f1238c1

- x86/amd_nb: Add new PCI IDs for AMD family 0x1a (stable-fixes).
- Refresh
  patches.suse/x86-amd_nb-Add-new-PCI-IDs-for-AMD-family-1Ah-model-60h.patch.
- commit 5a88cd1

- ALSA: hda: Fix missing pointer check in
  hda_component_manager_init function (git-fixes).
- commit 39c22db

- tools: lib: thermal: don't preserve owner in install
  (stable-fixes).
- watchdog: s3c2410_wdt: Fix max_timeout being calculated larger
  (stable-fixes).
- usb: gadget: f_fs: Fix epfile null pointer access after ep
  enable (stable-fixes).
- usb: mon: Increase BUFF_MAX to 64 MiB to support multi-MB URBs
  (stable-fixes).
- usb: xhci: plat: Facilitate using autosuspend for xhci plat
  devices (stable-fixes).
- usb: cdns3: gadget: Use-after-free during failed initialization
  and exit of cdnsp gadget (stable-fixes).
- usb: gadget: f_hid: Fix zero length packet transfer
  (stable-fixes).
- usb: gadget: f_ncm: Fix MAC assignment NCM ethernet
  (stable-fixes).
- wifi: ath12k: Increase DP_REO_CMD_RING_SIZE to 256
  (stable-fixes).
- wifi: ath10k: Fix connection after GTK rekeying (stable-fixes).
- wifi: rtw88: sdio: use indirect IO for device registers before
  power-on (stable-fixes).
- wifi: mt76: mt7996: Temporarily disable EPCS (stable-fixes).
- wifi: mt76: mt7921: Add 160MHz beamformee capability for mt7922
  device (stable-fixes).
- wifi: mac80211: Fix HE capabilities element check
  (stable-fixes).
- video: backlight: lp855x_bl: Set correct EPROM start for LP8556
  (stable-fixes).
- commit 7dad19b

- tools: lib: thermal: use pkg-config to locate libnl3
  (stable-fixes).
- phy: rockchip: phy-rockchip-inno-csidphy: allow writes to grf
  register 0 (stable-fixes).
- thunderbolt: Use is_pciehp instead of is_hotplug_bridge
  (stable-fixes).
- soc/tegra: fuse: Add Tegra114 nvmem cells and fuse lookups
  (stable-fixes).
- soc: qcom: smem: Fix endian-unaware access of num_entries
  (stable-fixes).
- soc: aspeed: socinfo: Add AST27xx silicon IDs (stable-fixes).
- pinctrl: single: fix bias pull up/down handling in
  pin_config_set (stable-fixes).
- power: supply: qcom_battmgr: handle charging state change
  notifications (stable-fixes).
- power: supply: sbs-charger: Support multiple devices
  (stable-fixes).
- power: supply: qcom_battmgr: add OOI chemistry (stable-fixes).
- spi: rpc-if: Add resume support for RZ/G3E (stable-fixes).
- spi: loopback-test: Don't use %pK through printk (stable-fixes).
- commit 47c8f1c

- NFS4: Fix state renewals missing after boot (git-fixes).
- commit 1f41fdb

- NFS: check if suid/sgid was cleared after a write as needed
  (git-fixes).
- commit 6f2e3ba

- nfs4_setup_readdir(): insufficient locking for
  - &amp;gt;d_parent-&amp;gt;d_inode dereferencing (git-fixes).
- commit cbc0708

- PCI: cadence: Check for the existence of cdns_pcie::ops before
  using it (stable-fixes).
- PCI: rcar-host: Convert struct rcar_msi mask_lock into raw
  spinlock (git-fixes).
- PCI: dwc: Verify the single eDMA IRQ in
  dw_pcie_edma_irq_verify() (stable-fixes).
- PCI/PM: Skip resuming to D0 if device is disconnected
  (stable-fixes).
- PCI/P2PDMA: Fix incorrect pointer usage in devm_kfree() call
  (stable-fixes).
- PCI: Disable MSI on RDC PCI to PCIe bridges (stable-fixes).
- phy: cadence: cdns-dphy: Enable lower resolutions in dphy
  (stable-fixes).
- phy: renesas: r8a779f0-ether-serdes: add new step added to
  latest datasheet (stable-fixes).
- net: phy: clear link parameters on admin link down
  (stable-fixes).
- net: phy: marvell: Fix 88e1510 downshift counter errata
  (stable-fixes).
- net: nfc: nci: Increase NCI_DATA_TIMEOUT to 3000 ms
  (stable-fixes).
- net: phy: fixed_phy: let fixed_phy_unregister free the
  phy_device (stable-fixes).
- media: redrat3: use int type to store negative error codes
  (stable-fixes).
- media: ov08x40: Fix the horizontal flip control (stable-fixes).
- media: i2c: og01a1b: Specify monochrome media bus format
  instead of Bayer (stable-fixes).
- media: adv7180: Only validate format in querystd (stable-fixes).
- media: adv7180: Do not write format to device in set_fmt
  (stable-fixes).
- media: adv7180: Add missing lock in suspend callback
  (stable-fixes).
- media: fix uninitialized symbol warnings (stable-fixes).
- media: imon: make send_packet() more robust (stable-fixes).
- media: i2c: Kconfig: Ensure a dependency on HAVE_CLK for
  VIDEO_CAMERA_SENSOR (stable-fixes).
- media: amphion: Delete v4l2_fh synchronously in .release()
  (stable-fixes).
- mfd: madera: Work around false-positive -Wininitialized warning
  (stable-fixes).
- mfd: da9063: Split chip variant reading in two bus transactions
  (stable-fixes).
- mfd: stmpe-i2c: Add missing MODULE_LICENSE (stable-fixes).
- mfd: stmpe: Remove IRQ domain upon removal (stable-fixes).
- mmc: sdhci-msm: Enable tuning for SDR50 mode for SD card
  (stable-fixes).
- memstick: Add timeout to prevent indefinite waiting
  (stable-fixes).
- mmc: host: renesas_sdhi: Fix the actual clock (stable-fixes).
- commit 8c57bbb

- NFSv4.1: fix mount hang after CREATE_SESSION failure
  (git-fixes).
- commit c832cc2

- NFSv4: handle ERR_GRACE on delegation recalls (git-fixes).
- commit aaacda9

- ima: don't clear IMA_DIGSIG flag when setting or removing
  non-IMA xattr (stable-fixes).
- iio: adc: imx93_adc: load calibrated values even calibration
  failed (stable-fixes).
- iio: adc: spear_adc: mask SPEAR_ADC_STATUS channel and avg
  sample before setting register (stable-fixes).
- hwmon: (dell-smm) Add support for Dell OptiPlex 7040
  (stable-fixes).
- hwmon: (asus-ec-sensors) increase timeout for locking ACPI mutex
  (stable-fixes).
- hwmon: sy7636a: add alias (stable-fixes).
- hwmon: (sbtsi_temp) AMD CPU extended temperature range support
  (stable-fixes).
- hwmon: (k10temp) Add device ID for Strix Halo (stable-fixes).
- hwmon: (k10temp) Add thermal support for AMD Family 1Ah-based
  models (stable-fixes).
- commit f501af0

- jfs: fix uninitialized waitqueue in transaction manager
  (git-fixes).
- commit 0b36ea1

- jfs: Verify inode mode when loading from disk (git-fixes).
- commit 475a90c

- extcon: adc-jack: Cleanup wakeup source only if it was enabled
  (git-fixes).
- commit 5b8d1e6

- drm/amd/display: Disable VRR on DCE 6 (stable-fixes).
- commit d98de00

- drm/amd/display: ensure committing streams is seamless
  (stable-fixes).
- commit 0def0fa

- exfat: limit log print for IO error (git-fixes).
- commit 1fa4a3d

- drm/amd/display: Fix black screen with HDMI outputs (git-fixes).
- fbcon: Set fb_display[i]-&amp;gt;mode to NULL when the mode is released
  (stable-fixes).
- fbdev: bitblit: bound-check glyph index in bit_putcs*
  (stable-fixes).
- fbdev: pvr2fb: Fix leftover reference to ONCHIP_NR_DMA_CHANNELS
  (stable-fixes).
- HID: quirks: avoid Cooler Master MM712 dongle wakeup bug
  (stable-fixes).
- drm/amdgpu: Fix NULL pointer dereference in VRAM logic for
  APU devices (stable-fixes).
- drm/amd/pm: Disable MCLK switching on SI at high pixel clocks
  (stable-fixes).
- fbdev: Add bounds checking in bit_putcs to fix
  vmalloc-out-of-bounds (stable-fixes).
- extcon: adc-jack: Fix wakeup source leaks on device unbind
  (stable-fixes).
- char: misc: Does not request module for miscdevice with dynamic
  minor (stable-fixes).
- char: misc: Make misc_register() reentry for miscdevice who
  wants dynamic minor (stable-fixes).
- drm/amd/display: Add AVI infoframe copy in
  copy_stream_update_to_stream (stable-fixes).
- drm/amdgpu: reject gang submissions under SRIOV (stable-fixes).
- drm/amd/display: Fix DVI-D/HDMI adapters (stable-fixes).
- drm/amd: Avoid evicting resources at S5 (stable-fixes).
- drm/amdgpu: Use memdup_array_user in amdgpu_cs_wait_fences_ioctl
  (stable-fixes).
- drm/msm: make sure to not queue up recovery more than once
  (stable-fixes).
- drm/msm/dsi/phy_7nm: Fix missing initial VCO rate
  (stable-fixes).
- drm/msm/dsi/phy: Toggle back buffer resync after preparing PLL
  (stable-fixes).
- drm/amdgpu: don't enable SMU on cyan skillfish (stable-fixes).
- drm/amdgpu: add support for cyan skillfish gpu_info
  (stable-fixes).
- drm/amd: add more cyan skillfish PCI ids (stable-fixes).
- drm/amdgpu: Allow kfd CRIU with no buffer objects
  (stable-fixes).
- drm/amdkfd: Tie UNMAP_LATENCY to queue_preemption
  (stable-fixes).
- drm/amdkfd: fix vram allocation failure for a special case
  (stable-fixes).
- drm/amdkfd: Handle lack of READ permissions in SVM mapping
  (stable-fixes).
- drm/amdkfd: return -ENOTTY for unsupported IOCTLs
  (stable-fixes).
- drm/amdgpu/jpeg: Hold pg_lock before jpeg poweroff
  (stable-fixes).
- drm/amd/pm: Use cached metrics data on arcturus (stable-fixes).
- drm/amd/pm: Use cached metrics data on aldebaran (stable-fixes).
- drm/amd/display: update dpp/disp clock from smu clock table
  (stable-fixes).
- drm/amd/display: add more cyan skillfish devices (stable-fixes).
- drm/amd/display: Increase AUX Intra-Hop Done Max Wait Duration
  (stable-fixes).
- drm/bridge: display-connector: don't set OP_DETECT for
  DisplayPorts (stable-fixes).
- drm/tidss: Set crtc modesetting parameters with adjusted mode
  (stable-fixes).
- drm/bridge: cdns-dsi: Don't fail on MIPI_DSI_MODE_VIDEO_BURST
  (stable-fixes).
- drm/bridge: cdns-dsi: Fix REG_WAKEUP_TIME value (stable-fixes).
- drm/tidss: Use the crtc_* timings when programming the HW
  (stable-fixes).
- commit 304e918

- tcp: correct handling of extreme memory squeeze (bsc#1253779
  CVE-2025-21710 bsc#1237888).
- commit bba09b0

- net: tcp: send zero-window ACK when no memory (bsc#1253779).
- commit f54e913

- ACPI: property: Return present device nodes only on fwnode
  interface (stable-fixes).
- commit 7bfc861

- ACPI: PRM: Skip handlers with NULL handler_address or NULL VA
  (stable-fixes).
- commit d4e809a

- ACPI: scan: Add Intel CVS ACPI HIDs to acpi_ignore_dep_ids
  (stable-fixes).
- commit cea477f

- ACPICA: Update dsmethod.c to get rid of unused variable warning
  (stable-fixes).
- commit 47d058d

- ACPICA: dispatcher: Use acpi_ds_clear_operands() in
  acpi_ds_call_control_method() (stable-fixes).
- commit a383be8

- tools/cpupower: Fix incorrect size in cpuidle_state_disable()
  (stable-fixes).
- commit 2d1aa96

- tools/cpupower: fix error return value in cpupower_write_sysfs()
  (stable-fixes).
- commit c9d6e6c

- tools/power x86_energy_perf_policy: Prefer driver HWP limits
  (stable-fixes).
- commit e772bc7

- tools/power x86_energy_perf_policy: Enhance HWP enable
  (stable-fixes).
- commit 1133dff

- tools/power x86_energy_perf_policy: Fix incorrect fopen mode
  usage (stable-fixes).
- commit 23d6e42

- Update
  patches.suse/net-smc-Remove-validation-of-reserved-bits-in-CLC-Decline-.patch
  (bsc#1252353).
- commit d9fe289

- crypto: aspeed - fix double free caused by devm (git-fixes).
- dmaengine: dw-edma: Set status for callback_result
  (stable-fixes).
- dmaengine: mv_xor: match alloc_wc and free_wc (stable-fixes).
- crypto: qat - use kcalloc() in qat_uclo_map_objs_from_mof()
  (stable-fixes).
- drm/nouveau: replace snprintf() with scnprintf() in
  nvkm_snprintbf() (stable-fixes).
- char: misc: restrict the dynamic range to exclude reserved
  minors (stable-fixes).
- crypto: aspeed-acry - Convert to platform remove callback
  returning void (stable-fixes).
- commit 89d05dd

- ALSA: usb-audio: Fix potential overflow of PCM transfer buffer
  (stable-fixes).
- ALSA: usb-audio: don't log messages meant for 1810c when
  initializing 1824c (git-fixes).
- ASoC: max98090/91: fixed max98091 ALSA widget powering up/down
  (stable-fixes).
- ASoC: meson: aiu-encoder-i2s: fix bit clock polarity
  (stable-fixes).
- Bluetooth: SCO: Fix UAF on sco_conn_free (stable-fixes).
- Bluetooth: bcsp: receive data only if registered (stable-fixes).
- Bluetooth: btusb: Check for unexpected bytes when defragmenting
  HCI frames (stable-fixes).
- amd/amdkfd: resolve a race in amdgpu_amdkfd_device_fini_sw
  (stable-fixes).
- accel/habanalabs/gaudi2: read preboot status after recovering
  from dirty state (stable-fixes).
- accel/habanalabs: support mapping cb with vmalloc-backed
  coherent memory (stable-fixes).
- accel/habanalabs/gaudi2: fix BMON disable configuration
  (stable-fixes).
- accel/habanalabs: return ENOMEM if less than requested pages
  were pinned (stable-fixes).
- ASoC: tlv320aic3x: Fix class-D initialization for tlv320aic3007
  (stable-fixes).
- ASoC: stm32: sai: manage context in set_sysclk callback
  (stable-fixes).
- ALSA: usb-audio: add mono main switch to Presonus S1824c
  (stable-fixes).
- ASoC: qcom: sc8280xp: explicitly set S16LE format in
  sc8280xp_be_hw_params_fixup() (stable-fixes).
- ALSA: serial-generic: remove shared static buffer
  (stable-fixes).
- ALSA: usb-audio: apply quirk for MOONDROP Quark2 (stable-fixes).
- ALSA: usb-audio: Add validation of UAC2/UAC3 effect units
  (stable-fixes).
- commit d6deb82

- octeontx2-pf: Fix use-after-free bugs in otx2_sync_tstamp() (CVE-2025-39944 bsc#1251120)
- commit f5c6371

- ptp: ocp: fix use-after-free bugs causing by ptp_ocp_watchdog (CVE-2025-39859 bsc#1250252)
- commit b475528

- x86/bugs: Fix reporting of LFENCE retpoline (git-fixes).
- commit 879f123

- x86/vmscape: Add old Intel CPUs to affected list (git-fixes).
- commit 3042143

- net: macb: fix unregister_netdev call order in macb_remove() (CVE-2025-39805 bsc#1249982)
- commit 8a9576d

- x86/bugs: Report correct retbleed mitigation status (git-fixes).
- commit 11da480

- x86/CPU/AMD: Add additional fixed RDSEED microcode revisions (git-fixes).
- commit 265ca5a

- x86/CPU/AMD: Add missing terminator for zen5_rdseed_microcode (git-fixes).
- commit 0a4b156

- net/ip6_tunnel: Prevent perpetual tunnel growth (CVE-2025-40173
  bsc#1253421).
- commit 2d9c02f

- net/smc: Remove validation of reserved bits in CLC Decline
  message (bsc#1253779).
- commit 6b0f67d

- cramfs: Verify inode mode when loading from disk (git-fixes).
- commit 593324b

- minixfs: Verify inode mode when loading from disk (git-fixes).
- commit a428067

- Add missing bugzilla reference to net fix (bsc#1250237 CVE-2025-40206 bsc#1253393)
- commit 9ef65cb

- Input: imx_sc_key - fix memory corruption on unload (git-fixes).
- Input: pegasus-notetaker - fix potential out-of-bounds access
  (git-fixes).
- Input: atmel_mxt_ts - allow reset GPIO to sleep (stable-fixes).
- commit a07d058

- scsi: mvsas: Fix use-after-free bugs in mvs_work_queue
  (CVE-2025-40001 bsc#1252303).
- commit 2c846dd

- pinctrl: s32cc: initialize gpio_pin_config::list after kmalloc()
  (git-fixes).
- pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc
  (git-fixes).
- nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot
  (git-fixes).
- Revert &amp;quot;drm/tegra: dsi: Clear enable register if powered by
  bootloader&amp;quot; (git-fixes).
- drm/tegra: Add call to put_pid() (git-fixes).
- drm/tegra: dc: Fix reference leak in tegra_dc_couple()
  (git-fixes).
- commit 401121e

- tls: wait for pending async decryptions if tls_strp_msg_hold
  fails (CVE-2025-40176 bsc#1253425).
- commit 411c26e

- series.conf: reorder misplaced patches from kABI section
  Fix misplaced patches in the kABI section by restoring correct order.
- commit f6506b9

- platform/x86/intel/speed_select_if: Convert PCIBIOS_* return
  codes to errnos (git-fixes).
- commit e814a2b

- vfs: Don't leak disconnected dentries on umount (CVE-2025-40105
  bsc#1252928).
- commit 29d6b54

- KVM: SVM: Mark VMCB_LBR dirty when MSR_IA32_DEBUGCTLMSR is
  updated (git-fixes).
- commit f6f6b8f

- KVM: VMX: Fix check for valid GVA on an EPT violation
  (git-fixes).
- commit dab0856

- KVM: x86: Don't treat ENTER and LEAVE as branches, because
  they aren't (git-fixes).
- commit 4d07448

- HID: uclogic: Fix potential memory leak in error path
  (git-fixes).
- HID: hid-ntrig: Prevent memory leak in ntrig_report_version()
  (git-fixes).
- HID: amd_sfh: Stop sensor before starting (git-fixes).
- HID: quirks: work around VID/PID conflict for 0x4c4a/0x4155
  (git-fixes).
- commit 98129db

- scsi: storvsc: Prefer returning channel with the same CPU as on the I/O issuing CPU (bsc#1252267).
- uio_hv_generic: Let userspace take care of interrupt mask (git-fixes CVE-2025-40048 bsc#1252862).
- net/mana: fix warning in the writer of client oob (git-fixes).
- uio_hv_generic: Query the ringbuffer size for device (git-fixes).
- Drivers: hv: vmbus: Add utility function for querying ring size (git-fixes).
- commit 0473d84

- sctp: Fix MAC comparison to be constant-time (CVE-2025-40204
  bsc#1253436).
- commit 53f522f

- tracing: dynevent: Add a missing lockdown check on dynevent
  (CVE-2025-40021 bsc#1252681).
- commit c113400

- Update
  patches.suse/netfilter-nft_objref-validate-objref-and-objrefmap-e.patch
  (bsc#1250237 CVE-2025-40206).
  Inserted series, updated CVE reference and mainline
- commit 617e07d

- selftests/bpf: Close fd in error path in drop_on_reuseport
  (git-fixes).
- commit 9eacaa7

- selftests/bpf: Close obj in error path in xdp_adjust_tail
  (git-fixes).
- commit 32804dc

- selftests/bpf: Use pid_t consistently in test_progs.c
  (git-fixes).
- commit 12adc35

- bpf: Reject negative offsets for ALU ops (CVE-2025-40169
  bsc#1253416).
- commit 004bd79

- mtd: onenand: Pass correct pointer to IRQ handler (git-fixes).
- mtd: rawnand: cadence: fix DMA device NULL pointer dereference
  (git-fixes).
- mtdchar: fix integer overflow in read/write ioctls (git-fixes).
- commit fd43643

- net/sched: sch_qfq: Fix null-deref in agg_dequeue (CVE-2025-40083 bsc#1252912).
- commit 517474e

- mm/secretmem: fix use-after-free race in fault handler
  (git-fixes).
- commit 8bf2ad9

- mm/mm_init: fix hash table order logging in
  alloc_large_system_hash() (git-fixes).
- commit fdeb2e0

- xsk: Harden userspace-supplied xdp_desc validation
  (CVE-2025-40159 bsc#1253403).
- commit 7cd1a7d

- selftests/bpf: Fix missing ARRAY_SIZE() definition in bench.c
  (git-fixes).
- commit f67cafa

- selftests/bpf: Fix missing UINT_MAX definitions in benchmarks
  (git-fixes).
- commit 172ead3

- selftests/bpf: Fix missing BUILD_BUG_ON() declaration
  (git-fixes).
- commit 67585df

- drm/vmwgfx: Validate command header size against
  SVGA_CMD_MAX_DATASIZE (git-fixes).
- mmc: sdhci-of-dwcmshc: Change DLL_STRBIN_TAPNUM_DEFAULT to 0x4
  (git-fixes).
- acpi,srat: Fix incorrect device handle check for Generic
  Initiator (git-fixes).
- spi: Try to get ACPI GPIO IRQ earlier (git-fixes).
- regulator: fixed: fix GPIO descriptor leak on register failure
  (git-fixes).
- ASoC: codecs: va-macro: fix resource leak in probe error path
  (git-fixes).
- ASoC: cs4271: Fix regulator leak on probe failure (git-fixes).
- ALSA: usb-audio: Fix NULL pointer dereference in
  snd_usb_mixer_controls_badd (git-fixes).
- crypto: hisilicon/qm - Fix device reference leak in
  qm_get_qos_value (git-fixes).
- commit c9e8681

- s390/mm: Fix in_atomic() handling in do_secure_storage_access()
  (git-fixes CVE-2025-38359 bsc#1247076).
- s390/mm,fault: simplify kfence fault handling (bsc#1247076).
- commit 5eab67b

- Bluetooth: L2CAP: export l2cap_chan_hold for modules
  (stable-fixes).
- commit 0d1ed96

- ACPI: CPPC: Limit perf ctrs in PCC check only to online CPUs
  (git-fixes).
- ACPI: CPPC: Perform fast check switch only for online CPUs
  (git-fixes).
- ACPI: CPPC: Check _CPC validity for only the online CPUs
  (git-fixes).
- wifi: mwl8k: inject DSSS Parameter Set element into beacons
  if missing (git-fixes).
- wifi: mac80211: skip rate verification for not captured PSDUs
  (git-fixes).
- wifi: ath11k: zero init info-&amp;gt;status in
  wmi_process_mgmt_tx_comp() (git-fixes).
- wifi: mac80211: reject address change while connecting
  (git-fixes).
- Bluetooth: 6lowpan: add missing l2cap_chan_lock() (git-fixes).
- Bluetooth: 6lowpan: Don't hold spin lock over sleeping functions
  (git-fixes).
- Bluetooth: 6lowpan: fix BDADDR_LE vs ADDR_LE_DEV address type
  confusion (git-fixes).
- Bluetooth: 6lowpan: reset link-local header on ipv6 recv path
  (git-fixes).
- Bluetooth: btusb: reorder cleanup in btusb_disconnect to avoid
  UAF (git-fixes).
- Bluetooth: MGMT: cancel mesh send timer when hdev removed
  (git-fixes).
- strparser: Fix signed/unsigned mismatch bug (git-fixes).
- commit 22e4e84

- bpf: make sure skb-&amp;gt;len != 0 when redirecting to a tunneling device (CVE-2022-50253 bsc#1249912)
- commit 9d76bea

- scsi: ufs: exynos: Fix programming of HCI_UTRL_NEXUS_TYPE (CVE-2025-39788 bsc#1249547)
- commit 8ecb142

- drm/amd/display: Check dce_hwseq before dereferencing it (CVE-2025-38361 bsc#1247079)
- commit c29726d

- NFSD: Skip close replay processing if XDR encoding fails
  (git-fixes).
- commit a56f52a

- NFSD: Never cache a COMPOUND when the SEQUENCE operation fails
  (git-fixes).
- commit bd549b4

- NFSD: free copynotify stateid in nfs4_free_ol_stateid()
  (git-fixes).
- commit e5427cd

- perf script: add --addr2line option (bsc#1247509).
- commit b555487

- scsi: target: iscsi: Fix buffer overflow in
  lio_target_nacl_info_show() (bsc#1251786 CVE-2023-53676).
- commit 9f54767

- crypto: iaa - Do not clobber req-&amp;gt;base.data (git-fixes).
- commit 5feccb5

- btrfs: scrub: put bio after errors in
  scrub_raid56_parity_stripe() (git-fixes).
- commit 065dd63

- btrfs: do not update last_log_commit when logging inode due
  to a new name (git-fixes).
- commit c42dda1

- KVM: SVM: Emulate PERF_CNTR_GLOBAL_STATUS_SET for PerfMonV2
  (git-fixes).
- commit 187ad0b

- KVM: SVM: Re-load current, not host, TSC_AUX on #VMEXIT from
  SEV-ES guest (git-fixes).
- commit ce2cf8f

- KVM: x86: Add helper to retrieve current value of user return
  MSR (git-fixes).
- commit aaea082

- KVM: VMX: Preserve host's DEBUGCTLMSR_FREEZE_IN_SMM while
  running the guest (git-fixes).
- commit 6c43180

- btrfs: tree-checker: fix the wrong output of data backref
  objectid (git-fix).
- commit b216859

- btrfs: fix COW handling in run_delalloc_nocow() (git-fix).
- commit 1ee428c

- btrfs: avoid page_lockend underflow in
  btrfs_punch_hole_lock_range() (git-fix).
- commit 0febf2a

- btrfs: run btrfs_error_commit_super() early (git-fix).
- commit 8643309

- btrfs: tree-checker: add dev extent item checks (git-fix).
- commit 48bfe9b

- btrfs: tree-checker: reject BTRFS_FT_UNKNOWN dir type (git-fix).
- commit 4308950

- btrfs: avoid using fixed char array size for tree names
  (git-fix).
- commit f141f17

- btrfs: tree-checker: validate dref root and objectid (git-fix).
- commit 3243d37

- btrfs: make btrfs_clear_delalloc_extent() free delalloc  reserve
  (git-fix).
- commit 36065ed

- btrfs: qgroup: correctly model root qgroup rsv in convert
  (git-fix).
- commit 9e4469e

- btrfs: tree-checker: add type and sequence check for inline
  backrefs (git-fix).
- commit d1d2092

- btrfs: scrub: put bio after errors in
  scrub_raid56_parity_stripe() (git-fix).
- commit ee165a1

- Alt-commit updates
- Refresh
  patches.suse/drm-amd-display-Fix-brightness-level-not-retained-ov.patch.
- Refresh
  patches.suse/drm-amdkfd-Don-t-call-mmput-from-MMU-notifier-callba.patch.
- Refresh
  patches.suse/drm-i915-dsi-Use-TRANS_DDI_FUNC_CTL-s-own-port-width.patch.
- Refresh
  patches.suse/drm-panel-simple-Update-timings-for-AUO-G101EVN010.patch.
- Refresh
  patches.suse/drm-sched-Add-locking-to-drm_sched_entity_modify_sch.patch.
- commit 1d2b5d5

- KVM: VMX: Wrap all accesses to IA32_DEBUGCTL with getter/setter
  APIs (git-fixes).
- commit baa92d8

- KVM: nVMX: Check vmcs12-&amp;gt;guest_ia32_debugctl on nested VM-Enter
  (git-fixes).
- commit 508e295

- btrfs: set inode flag BTRFS_INODE_COPY_EVERYTHING when logging
  new name (git-fixes).
- commit c373962

- btrfs: simplify error handling logic for btrfs_link()
  (git-fixes).
- commit 5e3a1fc

- btrfs: fix inode leak on failure to add link to inode
  (git-fixes).
- commit 5155c3a

- btrfs: abort transaction on failure to add link to inode
  (git-fixes).
- commit 91c4075

- btrfs: rename err to ret in btrfs_link() (git-fixes).
- commit 4d5a044

- btrfs: send: fix duplicated rmdir operations when using extrefs
  (git-fixes).
- commit 2c08529

- KVM: VMX: Allow guest to set DEBUGCTL.RTM_DEBUG if RTM is
  supported (git-fixes).
- commit 78a2926

- KVM: x86: Drop kvm_x86_ops.set_dr6() in favor of a new KVM_RUN
  flag (git-fixes).
- commit d3c0a38

- KVM: x86: Convert vcpu_run()'s immediate exit param into a
  generic bitmap (git-fixes).
- commit b58dbd2

- Delete
  patches.kabi/KVM-x86-Snapshot-the-host-s-DEBUGCTL-in-common-x86.patch.
  Now that kabi/severities is amended to ignore
  xfer_to_guest_mode_handle_work(), drop the unneeded kABI workaround.
- commit 27b5996

- btrfs: mark dirty extent range for out of bound prealloc extents
  (git-fixes).
- commit d11dc7c

- btrfs: use smp_mb__after_atomic() when forcing COW in
  create_pending_snapshot() (git-fixes).
- commit 0e43958

- usb/core/quirks: Add Huawei ME906S to wakeup quirk (git-fixes).
- commit add9d74

- kABI fix for KVM: VMX: Apply MMIO Stale Data mitigation if
  KVM maps MMIO into the guest (git-fixes) (git-fixes).
- commit 10ade44

- pds_core: remove write-after-free of client_id (CVE-2025-37916 bsc#1243474)
- commit 40805a0

- coresight: Fix incorrect handling for return value of devm_kzalloc (CVE-2025-40059 bsc#1252809)
- commit f7e7b0e

- ocfs2: fix double free in user_cluster_connect() (CVE-2025-40055 bsc#1252821)
- commit 9897d8a

- pinctrl: check the return value of
  pinmux_ops::get_function_name() (CVE-2025-40030 bsc#1252773).
- commit 060cddf

- KVM: VMX: Apply MMIO Stale Data mitigation if KVM maps MMIO
  into the guest (git-fixes).
- commit 0701a3a

- pps: fix warning in pps_register_cdev when register device fail
  (CVE-2025-40070 bsc#1252836).
- commit 98a58ce

- KVM: x86/mmu: Locally cache whether a PFN is host MMIO when
  making a SPTE (git-fixes).
- commit 15e0a05

- ALSA: hda: cs35l41: Fix NULL pointer dereference in
  cs35l41_get_acpi_mute_state() (CVE-2025-40098 bsc#1252917).
- commit 8b9eeeb

- rtc: rx8025: fix incorrect register reference (git-fixes).
- drm/amd: Fix suspend failure with secure display TA (git-fixes).
- drm/amd/display: Fix NULL deref in debugfs odm_combine_segments
  (git-fixes).
- drm/i915: Fix conversion between clock ticks and nanoseconds
  (git-fixes).
- drm/i915: Avoid lock inversion when pinning to GGTT on
  CHV/BXT+VTD (git-fixes).
- drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb
  (git-fixes).
- Documentation: ACPI: i2c-muxes: fix I2C device references
  (git-fixes).
- ACPI: SBS: Fix present test in acpi_battery_read() (git-fixes).
- lib/crypto: curve25519-hacl64: Fix older clang KASAN workaround
  for GCC (git-fixes).
- wifi: mac80211_hwsim: Limit destroy_on_close radio removal to
  netgroup (git-fixes).
- net: usb: qmi_wwan: initialize MAC header offset in
  qmimux_rx_fixup (git-fixes).
- isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe()
  (git-fixes).
- Bluetooth: btrtl: Fix memory leak in rtlbt_parse_firmware_v2()
  (git-fixes).
- Bluetooth: hci_event: validate skb length for unknown CC opcode
  (git-fixes).
- wifi: zd1211rw: fix potential memory leak in
  __zd_usb_enable_rx() (git-fixes).
- Revert &amp;quot;wifi: ath10k: avoid unnecessary wait for service ready
  message&amp;quot; (git-fixes).
- media: uvcvideo: Use heuristic to find stream entity
  (git-fixes).
- xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races
  with stall event (git-fixes).
- xhci: dbc: Avoid event polling busyloop if pending rx transfers
  are inactive (git-fixes).
- xhci: dbc: Improve performance by removing delay in transfer
  event polling (stable-fixes).
- xhci: dbc: Allow users to modify DbC poll interval via sysfs
  (stable-fixes).
- xhci: dbc: poll at different rate depending on data transfer
  activity (stable-fixes).
- commit 6309683

- x86/CPU/AMD: Do the common init on future Zens too (git-fixes).
- Refresh patches.suse/x86-CPU-AMD-Add-RDSEED-fix-for-Zen5.patch.
- Refresh patches.suse/x86-CPU-AMD-Clear-virtualized-VMLOAD-VMSAVE-on-Zen4-client.
- commit d7ef23e

- x86/CPU/AMD: Add RDSEED fix for Zen5 (git-fixes).
- commit 85fd0b8

- fs/smb: Fix inconsistent refcnt update (bsc#1250176,
  CVE-2025-39819).
- commit 966a58e

- kabi/severities: drop xfer_to_guest_mode_handle_work
  This is part of KVM, and it is already ignored in SL-16.0. The function
  only takes a pointer to a KVM struct and feeds it back to the KVM
  subsystem.
- commit dc5bb81

- net/9p: fix double req put in p9_fd_cancelled (CVE-2025-40027
  bsc#1252763).
- commit bff03bd

- KVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn't
  valid (CVE-2025-40038 bsc#1252817).
- commit d00fe85

- tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails
  to allocate psock-&amp;gt;cork (bsc#1250705).
- commit fd68ed6

- scsi: libfc: Prevent integer overflow in fc_fcp_recv_data()
  (git-fixes).
- scsi: mpt3sas: Fix crash in transport port remove by using
  ioc_info() (git-fixes).
- scsi: hpsa: Fix potential memory leak in
  hpsa_big_passthru_ioctl() (git-fixes).
- scsi: pm80xx: Fix array-index-out-of-of-bounds on rmmod
  (git-fixes).
- md: fix mssing blktrace bio split events (git-fixes).
- md/raid1: fix data lost for writemostly rdev (git-fixes).
- scsi: core: sysfs: Correct sysfs attributes access rights
  (git-fixes).
- block: fix kobject double initialization in add_disk
  (git-fixes).
- block: avoid possible overflow for chunk_sectors check in
  blk_stack_limits() (git-fixes).
- scsi: Fix sas_user_scan() to handle wildcard and multi-channel
  scans (git-fixes).
- scsi: aacraid: Stop using PCI_IRQ_AFFINITY (git-fixes).
- commit 59aa14f

- nexthop: Forbid FDB status change while nexthop is in a group
  (CVE-2025-39980 bsc#1252063).
- commit 44a7e79

- mm/ksm: fix flag-dropping behavior in ksm_madvise
  (CVE-2025-40040 bsc#1252780).
- commit ff8401e

- serial: 8250_mtk: Enable baud clock and manage in runtime PM
  (git-fixes).
- serial: 8250_exar: add support for Advantech 2 port card with
  Device ID 0x0018 (git-fixes).
- PCI: j721e: Fix incorrect error message in probe() (git-fixes).
- PCI: tegra194: Reset BARs when running in PCIe endpoint mode
  (git-fixes).
- commit c2ea229

- selftests/bpf: Fix string read in strncmp benchmark (git-fixes).
- commit 0165696

- selftests/bpf: Mitigate sockmap_ktls disconnect_after_delete
  failure (git-fixes).
- commit 2116607

- selftests/bpf: fix signedness bug in redir_partial()
  (git-fixes).
- commit b261c17

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

- KVM: SVM: Delete IRTE link from previous vCPU irrespective of
  new routing (git-fixes).
- commit 6f9b1c9

- KVM: SVM: Delete IRTE link from previous vCPU before setting
  new IRTE (git-fixes).
- commit b83e48d

- KVM: SVM: WARN if an invalid posted interrupt IRTE entry is
  added (git-fixes).
- commit 2982d0e

- iommu/amd: Return an error if vCPU affinity is set for non-vCPU
  IRTE (git-fixes).
- commit 5cc1fcc

- KVM: SVM: Track per-vCPU IRTEs using kvm_kernel_irqfd structure
  (git-fixes).
- commit 9e70f85

- KVM: Pass new routing entries and irqfd when updating IRTEs
  (git-fixes).
- commit 2630cbd

- Refresh
  patches.suse/Revert-KVM-VMX-Move-LOAD_IA32_PERF_GLOBAL_CTRL-errat.patch.
  Fix whitespace (patch was using spaces).
- commit 04dc661

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

- RDMA/bnxt_re: Don't fail destroy QP and cleanup debugfs earlier (git-fixes)
- commit c7164d9

- RDMA/hns: Fix wrong WQE data when QP wraps around (git-fixes)
- commit ff60916

- RDMA/hns: Fix the modification of max_send_sge (git-fixes)
- commit e73e586

- RDMA/hns: Fix recv CQ and QP cache affinity (git-fixes)
- commit 80efef8

- RDMA/irdma: Set irdma_cq cq_num field during CQ create (git-fixes)
- commit 8445b54

- RDMA/irdma: Fix SD index calculation (git-fixes)
- commit 05d9bdd

- RDMA/bnxt_re: Fix a potential memory leak in destroy_gsi_sqp (git-fixes)
- commit 3c9a931

- 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

- scsi: mpi3mr: Drop unnecessary volatile from __iomem pointers
  (git-fixes).
- Refresh
  patches.suse/scsi-mpi3mr-Serialize-admin-queue-BAR-writes-on-32-bit-sys.patch.
- commit 0321942

- scsi: mpt3sas: Correctly handle ATA device errors (git-fixes).
- scsi: mpi3mr: Correctly handle ATA device errors (git-fixes).
- commit 237fed8

- 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

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

- Enable ARM64 64K page support (bsc##1248074)  * crash-arm64-fix-64K-page-and-52-bits-VA-support.patch
  * crash-arm64-rewrite-the-arm64_get_vmcoreinfo_ul-to-arm64_g.patch
  * crash-arm64-support-HW-Tag-Based-KASAN-MTE-mode.patch
  * crash-arm64-Add-support-for-vmemmap-symbol-in-vmcoreinfo.patch
  * crash-arm64-fix-the-determination-of-vmemmap-and-struct_pa.patch
  * crash-arm64-Add-gdb-stack-unwind-support.patch
  * crash-symbols-expand-all-kernel-module-symtable-if-not-all.patch
  * crash-Add-LoongArch64-framework-code-support.patch
  * crash-LoongArch64-Fixed-link-errors-when-build-on-LOONGARC.patch
  * crash-gdb-fix-p-command-to-print-module-variables-correctl.patch
  * crash-ppc64-Add-gdb-stack-unwind-support.patch
  * crash-Preparing-for-gdb-stack-unwind-support.patch
  * crash-x86_64-Add-gdb-stack-unwind-support.patch
  * crash-gcore-update-set_context-with-upstream-counterpart.patch

Package crmsh was updated:

- Update to version 4.6.2+20251210.9a742f8c:  * Fix: qdevice: Make sure stonith-watchdog-timeout is 2 times of SBD_WATCHDOG_TIMEOUT (bsc#1254571)
  * Fix: prun: Avoid unnecessary sudo in sftp and ssh commands (bsc#1229416)
  * Fix: bootstrap: Correctly identify root user with host
  * Fix: sh: Avoid unnecessary sudo calls in ClusterShell SSH commands (bsc#1229416)
  * Fix: ui_configure: Check if able to set stonith-watchdog-timeout property
  * Dev: report: Collect xml format output from crm_mon

Package cups was updated:

- Adapted cups-2.2.7-CVE-2025-58436.patch according to  https://github.com/OpenPrinting/cups/pull/1439
  &amp;quot;http.c: Fix infinite loop in GTK apps&amp;quot;
  which fixes the regression boo#1254353
  &amp;quot;Cups version 2.2.7-150000.3.77.1 will hang GTK applications&amp;quot;
  https://github.com/OpenPrinting/cups/issues/1429
  &amp;quot;CUPS 2.4.15 freezes apps requesting the GTK print dialog&amp;quot;

- cups-2.2.7-CVE-2025-61915.patch is based on
  https://github.com/OpenPrinting/cups-ghsa-hxm8-vfpq-jrfc/pull/2
  backported to CUPS 2.2.7 to fix CVE-2025-61915
  &amp;quot;Local denial-of-service via cupsd.conf update
  and related issues&amp;quot;
  https://github.com/OpenPrinting/cups/security/advisories/GHSA-hxm8-vfpq-jrfc
  bsc#1253783
- cups-2.2.7-CVE-2025-58436.patch mitigates CVE-2025-58436
  &amp;quot;Slow client communication leads to a possible DoS attack&amp;quot;
  https://github.com/OpenPrinting/cups/security/advisories/GHSA-8wpw-vfgm-qrrr
  (bsc#1244057)
- cups-2.2.7-bsc1234225c76.patch is from
  https://bugzilla.suse.com/show_bug.cgi?id=1234225#c76
  to fix bsc#1234225 &amp;quot;cupsd stuck in poll() loop&amp;quot;
  see also https://github.com/OpenPrinting/cups/issues/1264
- In general regarding CUPS security issues and/or DoS issues see
  https://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings

Package curl was updated:

- Security fix: [bsc#1256105, CVE-2025-14017]  * call ldap_init() before setting the options
  * Add patch curl-CVE-2025-14017.patch

- 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 cyrus-sasl was updated:

- Python3 error log upon importing pycurl (bsc#1233529)  Remove senceless log message.
  * add remove-senceless-log.patch

Package cyrus-sasl-saslauthd was updated:

- bsc#1247498 - replace insecure MD5 with ephemeral HMAC-SHA256  * 0001-Use-HMAC-SHA256-for-cache-passwords-over-MD5.patch

Package lvm2 was updated:

- systemctl start lvmlockd.service times out (bsc#1233655)  * Add a patch containing multiple picked upstream patches
    + bug-1233655_configure-add-option-disable-enable-sd-notify-and-au.patch
  * Update lvm2.spec
  - add pkgconfig(systemd) for lvmlockd build
  - enable configure option '--enable-sd-notify' for lvmlockd

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

- Update to docker-buildx v0.28.0. Upstream changelog:
  &amp;lt;https://github.com/docker/buildx/releases/tag/v0.28.0&amp;gt;
- Update to Docker 28.4.0-ce. See upstream changelog online at
  &amp;lt;https://docs.docker.com/engine/release-notes/28/#2840&amp;gt;
  * Fixes a nil pointer panic in &amp;quot;docker push&amp;quot;. bsc#1248373
- 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 warnings and errors related to &amp;quot;docker buildx ...&amp;quot; so that they
  reference our openSUSE docker-buildx packages.
  + cli-0001-openSUSE-point-users-to-docker-buildx-package.patch
- Enable building docker-buildx for SLE15 systems with SUSEConnect secret
  injection enabled. PED-12534 PED-8905 bsc#1247594
  As docker-buildx does not support our SUSEConnect secret injection (and some
  users depend &amp;quot;docker build&amp;quot; working transparently), patch the docker CLI so
  that &amp;quot;docker build&amp;quot; will no longer automatically call &amp;quot;docker buildx build&amp;quot;,
  effectively making DOCKER_BUILDKIT=0 the default configuration. Users can
  manually use &amp;quot;docker buildx ...&amp;quot; commands or set DOCKER_BUILDKIT=1 in order
  to opt-in to using docker-buildx.
  Users can silence the &amp;quot;docker build&amp;quot; warning by setting DOCKER_BUILDKIT=0
  explicitly.
  In order to inject SCC credentials with docker-buildx, users should use
    RUN --mount=type=secret,id=SCCcredentials zypper -n ...
  in their Dockerfiles, and
    docker buildx build --secret id=SCCcredentials,src=/etc/zypp/credentials.d/SCCcredentials,type=file .
  when doing their builds.
  + cli-0002-SECRETS-SUSE-default-to-DOCKER_BUILDKIT-0-for-docker.patch

Package elfutils was updated:

- Add elfutils-fix-large-alignment.diff and elfutils-pr28190.diff  to fix build/testsuite for more recent glibc and kernels.
- Add elfutils-fuzz-1.diff, elfutils-fuzz-2.diff,
  elfutils-fuzz-3.diff, elfutils-fuzz-4.diff [bsc#1237236,
  bsc#1237240, bsc#1237241, bsc#1237242].
- Add elfutils-fix-debuginfod-groom-race.diff to fix a testsuite
  race in run-debuginfod-find.sh.

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 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 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-notdash-escape.patch

Package grub2 was updated:

- Fix CVE-2025-54771 (bsc#1252931)  * 0001-kern-file-Call-grub_dl_unref-after-fs-fs_close.patch
- Fix CVE-2025-54770 (bsc#1252930)
  * 0002-net-net-Unregister-net_set_vlan-command-on-unload.patch
- Fix CVE-2025-61662 (bsc#1252933)
  * 0003-gettext-gettext-Unregister-gettext-command-on-module.patch
- Fix CVE-2025-61663 (bsc#1252934)
- Fix CVE-2025-61664 (bsc#1252935)
  * 0004-normal-main-Unregister-commands-on-module-unload.patch
  * 0005-tests-lib-functional_test-Unregister-commands-on-mod.patch
- Fix CVE-2025-61661 (bsc#1252932)
  * 0006-commands-usbtest-Use-correct-string-length-field.patch
  * 0007-commands-usbtest-Ensure-string-length-is-sufficient-.patch
- Bump upstream SBAT generation to 6

- Fix timeout when loading initrd via http after PPC CAS reboot (bsc#1245953)
  * 0001-tcp-Fix-TCP-port-number-reused-on-reboot.patch

- Fix PPC CAS reboot failure work when initiated via submenu (bsc#1241132)
  * 0001-Fix-PowerPC-CAS-reboot-to-evaluate-menu-context.patch

- Fix out of memory issue on PowerPC by increasing RMA size (bsc#1236744)
  (bsc#1252269)
  * 0001-powerpc-increase-MIN-RMA-size-for-CAS-negotiation.patch

Package hdparm was updated:

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 resource-agents was updated:

- L3:ec2 and awsvip resource agent's retry mechanism for AWS monitoring  (bsc#1251836)
- Add auth_type parameter and AWS Policy based authentication type
  Add upstream patches:
    1936.patch
    0001-aws-vpc-move-ip-aws-vpc-route53-awseip-awsvip-add-au.patch

- L3: OCF Resource Agents for vsftpd failure: No PID found (bsc#1249819)
  Add patch:
    2075.patch

Package libqt5-qtbase was updated:

- Add patch from upstream to fix a low performance when processing  XML data in encodeText (bsc#1239896, CVE-2025-30348):
  * 0001-XML_QDom-speedup-encodeText.patch

- Add patch from upstream to initialize a member variable that was
  uninitialized under some circumstances:
  * 0001-QObjectPrivateSignal-initialize-all-members.patch
- Add patch from upstream to fix a crash when parsing a particular
  glyph in a particular font (QTBUG-124310):
  * 0001-Avoid-crash-in-font-distancefield-computation.patch
  * 0002-Fix-crash-in-font-distancefield-computation.patch
- Add patch from upstream to fix avoid repeatedly registering
  xsettings callbacks when switching cursor themes:
  * 0001-xcb-Avoid-repeatedly-registering-xsettings-callbacks-When.patch
- Add patch from upstream to check validity of RandR output info
  before using it (QTBUG-128906):
  * 0001-xcb-check-validity-of-RandR-output-info-before-using-it.patch
- Add patch from upstream to fix reparenting a window so it takes
  effect even if there are no other state changes to the window:
  * 0001-xcb-Sync-XCB-connection-after-reparenting-window.patch

- Add patch from upstream to fix a precondition violation in call
  to QByteArrayView::at() which can cause crashes (bsc#1243958,
  CVE-2025-5455):
  * 0001-qDecodeDataUrl-fix-precondition-violation-in-call-to.patch

Package libX11 was updated:

- Add libX11-commit-first-info-in-XimCommitInfo.patch:  Backport 041b5291 from upstream:
  imDefLkup: Commit first info in XimCommitInfo
  Xic.private.proto.commit_info can receive multiple XimCommitInfo
  when typing keys very quickly like an bar code scanner (or evemu-play)
  and the first info in XimCommitInfo should be committed to keep
  the typing key order.
  (bsc#1252250)

- Add libX11-unmark-fabricate-key-events-with-XKeyEvent-serial.patch:
  Backport 024d229f from upstream:
  ximcp: Unmark to fabricate key events with XKeyEvent serial
  _XimProtoKeypressFilter() and _XimProtoKeyreleaseFilter() can
  receive XKeyEvent from both the typing on the keyboard and the
  callback of XIM_FORWARD_EVENT.
  (bsc#1252250)

Package libaio was updated:

- Use %autosetup macro. Allows to eliminate the usage of deprecated  %patchN

- Make the package respect %optflags and disable LTO.

- skip testsuite on qemu_linux_user builds

- add fix-splice-signature.patch to fix build on 32bit

- update to 0.3.113:
  * cases/16.t: loongarch only supports eventfd2
  * Add loongarch to supported architectures in libaio.spec
  * Add endian detection and bit width detection for loongarch
  * Use generic syscall number schema for loongarch
  * Fix struct io_iocb_vector padding for 32bit architectures
  * struct io_iocb_sockaddr padding for 32bit architectures
  * Verify structure padding is correct at build time
  * harness: add test for aio poll missed events

- Update to version libaio0.3.112+29.696a5e6483ba:
  * Fix test issue with gcc-11 (bsc#1181869)
  * harness: Skip the test if io_pgetevents() is not implemented
  * harness: Print better error messages on error conditions in 22.t
  * harness: Fix PROT_WRITE mmap check
  * harness: fix read into PROT_WRITE mmap test
  * harness: skip 22.p if async_poll isn't supported
  * harness: Handle -ENOTSUP from io_submit() with RWF_NOWAIT
  * harness: Add fallback code for filesystems not supporting O_DIRECT
  * harness: add support for skipping tests
  * harness: Make the test exit with a code matching the pass/fail state

-  Add _constraints for PowerPC to avoid OOM at build time

- Update to 0.3.112:
  * Various patches for architectures/etc
- Update url
- Update install
- Enable tests
- Remove mostly merged patches or differently fixed issues:
  * libaio-aarch64-support.diff
  * libaio-generic-arch.diff
  * libaio-optflags.diff
  * 00_arches.patch
  * 00_arches_sh.patch
  * 01_link_libgcc.patch
  * 02_libdevdir.patch
  * 03_man_errors.patch
  * riscv-support.patch

- Disable LTO (boo#1133233).

- riscv-support.patch: Add support for RISC-V

- Use %license instead of %doc [bsc#1082318]

Package avahi was updated:

- Add avahi-CVE-2025-68276.patch:  Backport 0c013e2 from upstream, refuse to create wide-area record
  browsers when wide-area is off.
  (CVE-2025-68276, bsc#1256498)

- Add avahi-CVE-2025-68471.patch:
  Backport 9c6eb53 from upstream, fix DoS bug by changing assert to
  return.
  (CVE-2025-68471, bsc#1256500)

- Add avahi-CVE-2025-68468.patch:
  Backport f66be13 from upstream, fix DoS bug by removing incorrect
  assertion.
  (CVE-2025-68468, bsc#1256499)

Package util-linux was updated:

- Fix heap buffer overread in setpwnam() when processing 256-byte  usernames (bsc#1254666, CVE-2025-14104,
  util-linux-CVE-2025-14104-1.patch,
  util-linux-CVE-2025-14104-2.patch).

- lscpu: Add support for NVIDIA Olympus arm64 core (jsc#PED-13682,
  util-linux-lscpu-add-arm64-NVIDIA-Olympus.patch).

Package libdlm was updated:

- dlm: process waiting for posix lock can't be interrupted (bsc#1255025)  * add uptream patch
    + 0021-fs-dlm-implement-DLM_PLOCK_OP_CANCEL.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.

Package freetype2 was updated:

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

- Update to version 1.8+93.g5986a5a7:  * linux: use EVP_PKEY_CTX_add1_hkdf_info only once in compat function (bsc#1246914)
  * nvme/linux: check for empty digest in gen_tls_identity() (bsc#1246914)
  * nvme/linux: add fallback implementation for nvme_insert_tls_key_compat() (bsc#1246914)
  * linux: fix HKDF TLS key derivation back to OpenSSL 3.0.8 (bsc#1246914)
  * libnvme: TLS PSK derivation fixes (bsc#1246914)
  * linux: rename __nvme_insert_tls_key_versioned() to __nvme_insert_tls_key() (bsc#1246914)
  * linux: rename __nvme_insert_tls_key() to __nvme_import_tls_key() (bsc#1246914)
  * test/psk: add testcase for TLS identity derivation (bsc#1246914)
  * linux: set errno when nvme_generate_tls_key_identity() fails (bsc#1246914)

Package libpcap was updated:

- Security fix: [bsc#1255765, CVE-2025-11961]  * Fix out-of-bound-write and out-of-bound-read in pcap_ether_aton()
    due to missing validation of provided MAC-48 address string
  * Add libpcap-CVE-2025-11961.patch

Package pciutils was updated:

- pciutils.spec: Add a strict dependency to libpci. [bsc#1252338]  Mixing different versions of pciutils and libpci could result in
  a segmentation fault due to incompatible ABI.

- Synchronize SLE-12 and openSUSE:Factory [jsc#PED-4587].
  The following patches are now obsolete in version 3.13.0:
  * add-decoding-of-vendor-specific-vpd-fields.patch
  * pciutils-3.1.7-fix-memory-leak-in-get_cache_name.patch
  * pciutils-3.2.0_update-dist.patch
  * pciutils-3.5.1-add-support-for-32-bit-pci-domains.patch
  * pciutils-lspci-Correct-Root-Capabilities-CRS-Software-Visibil.patch
  * show-gen4-speed-properly.patch

- Synchronize SLE-15 and openSUSE:Factory [jsc#PED-8393, bsc#1224138].
  The following patches are now obsolete in version 3.13.0:
  * lspci-Fixed-buffer-overflows-in-ls-tree.c.patch
  * pciutils-Add-PCIe-5.0-data-rate-32-GT-s-support.patch
  * pciutils-Add-PCIe-6.0-data-rate-64-GT-s-support.patch
  * pciutils-Add-decoding-of-vendor-specific-VPD-fields.patch
  * pciutils-VPD-Cleanup.patch
  * pciutils-VPD-When-printing-item-IDs-escape-non-ASCII-characte.patch

- update to 3.13.0:
  * lspci decodes CXL 1.1 device link status information.
  * Further development of the pcilmr (the link margining
    utility)
  * Dump parsing supports 6-digit domain numbers.
  * Bug fixes in PCIe link state reporting.
  * Decode more fields in PCIe AER capability.
  * Fixed build on Linux systems with musl libc.
  * Updated pci.ids.

- update to 3.12.0:
  * lspci decodes the IDE (Integrity &amp;amp; Data Encryption) and
    TEE-IO extended capabilities.
  * Optimization flags used for compiling individual object files
    should be the same as optimization flags for linking the final
    executable to make link-time optimization possible.
  * no longer look up subsystems in the HWDB
  * Updated pci.ids
- include changes from 3.11:
  * update-pciids now supports XZ compression
  * update-pciids now sends itself as the User-Agent.
  * Added a pcilmr utility for PCIe lane margining
  * ECAM back-end now scans ACPI and BIOS memory faster.
  * Linux systems without pread/pwrite are no longer supported
  * Improved decoding of PCIe control and status registers.
  * Decoding of CXL capabilities now supports up to CXL 3.0.
  * lspci now displays interrupt message numbers consistently across
    different capabilities.
  * Cache of IDs resolved via DNS, which was located in ~/.pci-ids
    by default, is now stored according to the XDG base directory
    specification in $XDG_CACHE_HOME/pci-ids.
  * All source files now have SPDX license identifiers.
  * various minor bug fixes and updated pci.ids.

Package libpng12 was updated:

- security update- modified patches
  * libpng-1.2.51-CVE-2013-7353.patch (-p1)
  * libpng-1.2.51-CVE-2013-7354.patch (-p1)
- added patches
  CVE-2025-64505 [bsc#1254157], heap buffer over-read in `png_do_quantize` via malformed palette index
  * libpng12-CVE-2025-64505.patch

Package libpng16 was updated:

- security update- added patches
  CVE-2026-22695 [bsc#1256525], Heap buffer over-read in png_image_finish_read
  * libpng16-CVE-2026-22695.patch
  CVE-2026-22801 [bsc#1256526], Integer truncation causing heap buffer over-read in png_image_write_*
  * libpng16-CVE-2026-22801.patch

- 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 python3 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).
- Skip test_curses on ppc64le (gh#python/cpython#141534)

- Add CVE-2025-8291-consistency-zip64.patch which checks
  consistency of the zip64 end of central directory record, and
  preventing obfuscation of the payload, i.e., you scanning for
  malicious content in a ZIP file with one ZIP parser (let's say
  a Rust one) then unpack it in production with another (e.g.,
  the Python one) and get malicious content that the other parser
  did not see (CVE-2025-8291, bsc#1251305)
- Readjust patches while synchronizing between openSUSE and SLE trees:
  - F00251-change-user-install-location.patch
  - doc-py38-to-py36.patch
  - gh126985-mv-pyvenv.cfg2getpath.patch

Package ruby2.5 was updated:

- add limit-decompressed-name-length.patch  - fix ruby: denial of service (DoS) due to an insufficient check
    on the length of a decompressed domain name within a DNS packet
    in resolv gem
    bsc#1246430 CVE-2025-24294

Package libselinux was updated:

Package net-snmp was updated:

- Fix snmptrapd buffer overflow (bsc#1255491, CVE-2025-68615).  Add net-snmp-5.9.4-fix-out-of-bounds-trapOid-access.patch

Package systemd was updated:

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

- security update:  * CVE-2025-9900 [bsc#1250413]
    Fix Write-What-Where in libtiff via TIFFReadRGBAImageOriented
    + tiff-CVE-2025-9900.patch

Package libvirt was updated:

- CVE-2025-13193: qemu: Set umask for 'qemu-img' when creating  external inactive snapshots
  bsc#1253703
- CVE-2025-12748: Check ACLs before parsing the whole domain XML
  bsc#1253278

Package libxslt was updated:

- security update- added patches
  CVE-2025-11731 [bsc#1251979], type confusion in exsltFuncResultCompfunction leading to denial of service
  * libxslt-CVE-2025-11731.patch

- propagate test failure into build failure
- added sources
  * libxslt-test-results.ref

- security update
- added patches
  CVE-2025-10911 [bsc#1250553], use-after-free with key data stored cross-RVT
  * libxslt-CVE-2025-10911.patch

Package lifecycle-data-sle-module-live-patching was updated:

- Added data for 5_14_21-150400_24_167, 5_14_21-150400_24_170,  5_14_21-150400_24_173, 5_14_21-150400_24_176,
  5_14_21-150400_24_179, 5_14_21-150500_55_110,
  5_14_21-150500_55_113, 5_14_21-150500_55_116,
  5_14_21-150500_55_121, 5_14_21-150500_55_124,
  5_14_21-150500_55_130, 5_3_18-150300_59_207,
  5_3_18-150300_59_211, 5_3_18-150300_59_215,
  5_3_18-150300_59_218, 5_3_18-150300_59_221,
  6_4_0-150600_23_53, 6_4_0-150600_23_60,
  6_4_0-150600_23_65, 6_4_0-150600_23_70,
  6_4_0-150600_23_73, 6_4_0-150700_51,
  6_4_0-150700_53_11, 6_4_0-150700_53_16,
  6_4_0-150700_53_19, 6_4_0-150700_53_22,
  6_4_0-150700_53_3, 6_4_0-150700_53_6,
  +kernel-livepatch-6_4_0-150600_10_39-rt,*,+kernel-livepatch-6_4_0-150600_10_44-rt,*,+kernel-livepatch-6_4_0-150600_10_49-rt,*,+kernel-livepatch-6_4_0-150600_10_55-rt,*,+kernel-livepatch-6_4_0-150600_10_58-rt,*,+kernel-livepatch-6_4_0-150700_5-rt,*,+kernel-livepatch-6_4_0-150700_7_13-rt,*,+kernel-livepatch-6_4_0-150700_7_16-rt,*,+kernel-livepatch-6_4_0-150700_7_19-rt,*,+kernel-livepatch-6_4_0-150700_7_22-rt,*,+kernel-livepatch-6_4_0-150700_7_25-rt,*,+kernel-livepatch-6_4_0-150700_7_3-rt,*,+kernel-livepatch-6_4_0-150700_7_8-rt,*. (bsc#1020320)

- Added data for 5_14_21-150400_24_167, 5_14_21-150400_24_170,
  5_14_21-150400_24_173, 5_14_21-150400_24_176,
  5_14_21-150500_55_110, 5_14_21-150500_55_113,
  5_14_21-150500_55_116, 5_14_21-150500_55_121,
  5_3_18-150300_59_207, 5_3_18-150300_59_211,
  5_3_18-150300_59_215, 5_3_18-150300_59_218,
  6_4_0-150600_23_53, 6_4_0-150600_23_60,
  6_4_0-150600_23_65, 6_4_0-150600_23_70,
  6_4_0-150700_53_11, 6_4_0-150700_53_16,
  +kernel-livepatch-6_4_0-150600_10_39-rt,*,+kernel-livepatch-6_4_0-150600_10_44-rt,*,+kernel-livepatch-6_4_0-150600_10_49-rt,*,+kernel-livepatch-6_4_0-150700_7_13-rt,*,+kernel-livepatch-6_4_0-150700_7_16-rt,*. (bsc#1020320)

Package mozilla-nspr was updated:

- update to NSPR 4.36.2  * Fixed a syntax error in test file parsetm.c,
    which was introduced in 4.36.1
- update to NSPR 4.36.1
  * Incorrect time value produced by PR_ParseTimeString and
    PR_ParseTimeStringToExplodedTime if input string doesn't
    specify seconds.

Package nvme-cli was updated:

- Update to version 2.8+95.g1a0c2083:  * nvme: add --compat flag for 'gen-tls-key' and 'check-tls-key' (bsc#1246914)

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 perl-HTML-Parser was updated:

- updated to 3.830.0 (3.83)  see /usr/share/doc/packages/perl-HTML-Parser/Changes
  3.83      2024-07-30
  - fix '$\/]' in HTML::Entities::encode_entities (GH#45) (mauke)

- updated to 3.82
  see /usr/share/doc/packages/perl-HTML-Parser/Changes
  3.82      2024-03-13
  - &amp;quot;img lowsrc&amp;quot; and &amp;quot;body background&amp;quot; are not in the HTMLv5 spec (GH#43)
    (Jess)
  - Replace &amp;quot;FileHandle&amp;quot; with &amp;quot;IO::File&amp;quot; (GH#42) (James Raspass)
  - Fix some minor typos (GH#41) (Yoshikazu Sawa)

- updated to 3.81
  see /usr/share/doc/packages/perl-HTML-Parser/Changes
  3.81      2023-01-30
  - Stop depending on &amp;quot;Test&amp;quot; (GH#34) (James Raspass)
  - fix test scripts after conversion to Test::More (GH#35) (Graham Knop)

- updated to 3.80
  see /usr/share/doc/packages/perl-HTML-Parser/Changes
  3.80      2022-11-01
  * Fix compatibility with ancient perl by avoiding index in test (GH#33)
    (Graham Knop)

- updated to 3.79
  see /usr/share/doc/packages/perl-HTML-Parser/Changes
  3.79      2022-10-12
  * Modernise XS (GH#32) (James Raspass)
  * Skip threads on older perl versions, as they often segfault (GH#31) (Graham
  * Knop)

- updated to 3.78
  see /usr/share/doc/packages/perl-HTML-Parser/Changes
  3.78      2022-03-28
  * Remove unused variable (GH#26) (Michal Josef Å paÄek)

- updated to 3.77
  see /usr/share/doc/packages/perl-HTML-Parser/Changes
  3.77      2022-03-14
  * Update tests to remove HTML4 specific tags (GH#25) (Jess)

- updated to 3.76
  see /usr/share/doc/packages/perl-HTML-Parser/Changes
  3.76      2021-03-04
  * Add a fix for a stack confusion error on `eof`. (GH#21) (Matthew Horsfall
    and Chase Whitener)

- updated to 3.75
  see /usr/share/doc/packages/perl-HTML-Parser/Changes

- updated to 3.73
  see /usr/share/doc/packages/perl-HTML-Parser/Changes

Package release-notes-ha was updated:

- 15.6.20251031 (tracked in bsc#933411)- Added note about pacemaker-schemas (bsc#1241163)

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 rubygem-rack was updated:

- update to version 2.2.20 (bsc#1251936)  - CVE-2025-61919: application/x-www-form-urlencoded`, calling `rack.input.read(nil)`
    without enforcing a length or cap (bsc#1251936)
  - CVE-2025-61780: improper handling of headers in `Rack::Sendfile` allows for bypass
    of proxy-level access restrictions (bsc#1253951)
- removed deprecated patches now included in current version:
  - rubygem-rack-CVE-2020-8161.patch
  - rubygem-rack-CVE-2020-8184.patch
  - rubygem-rack-CVE-2022-30122.patch
  - rubygem-rack-CVE-2022-30123.patch
  - rubygem-rack-CVE-2022-44570.patch
  - rubygem-rack-CVE-2022-44571.patch
  - rubygem-rack-CVE-2022-44572.patch
  - rubygem-rack-CVE-2023-27530.patch
  - rubygem-rack-CVE-2023-27539.patch
  - rubygem-rack-CVE-2024-25126.patch
  - rubygem-rack-CVE-2024-26141.patch
  - rubygem-rack-CVE-2024-26146.patch
  - rubygem-rack-CVE-2025-25184.patch
  - rubygem-rack-CVE-2025-27111.patch
  - rubygem-rack-CVE-2025-27610.patch
  - rubygem-rack-CVE-2025-32441.patch
  - rubygem-rack-CVE-2025-46727.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.

- Update to runc v1.3.1. Upstream changelog is available from
  &amp;lt;https://github.com/opencontainers/runc/releases/tag/v1.3.1&amp;gt;
- Fix runc 1.3.x builds on SLE-12 by enabling --std=gnu11.

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

Package saptune was updated:

- update package version of saptune to 3.2.1  * restore CPU performance settings on AWS and Google Cloud
    (changes Note 2205917, 2684254 and 3577842)
    (bsc#1250217)
  * SAP Note 2993054 updated to Version 4
    add parameter setting for net.ipv4.tcp_retries2

Package supportutils-plugin-ha-sap was updated:

- Update to version 0.0.8+git.1761561174.0434cd5:  * fix typo in the definition of INSTANCE_TRACE_DIR
    (gh#SUSE/supportutils-plugin-ha-sap#20)
  * fix calling of getParameter.py
    (gh#SUSE/supportutils-plugin-ha-sap#18)
  * skip unused files from the collection of sudo files and sort
    the result
    (gh#SUSE/supportutils-plugin-ha-sap#17)

Package suse-module-tools was updated:

- Update to version 15.6.13:  * spec file: move %udev_rules_update call to %posttrans (bsc#1250664)

- Update to version 15.6.12:
  * weak-modules2: skip livepatch dir when checking for unresolved symbols
    (bsc#1250655)

Package vim was updated:

- Fix for bsc#1250593.- Backported from 9.1.1683 (xxd: Avoid null dereference in autoskip colorless).

- Fix for bsc#1229750.
- nocompatible must be set before the syntax highlighting is turned on.

Package xen was updated:

- bsc#1254180 - [SLES][15-SP7][x86_64][Build41647] virtxend service  restart. Caused by a failure to start xenstored.
  x86-have-.note.Xen-segment-contents-before-others.patch

- bsc#1248807 - VUL-0: CVE-2025-27466, CVE-2025-58142,
  CVE-2025-58143: xen: Mutiple vulnerabilities in the Viridian
  interface (XSA-472)
  68c0195d-x86-Viridian-NULL-deref-in-update_reference_tsc.patch
  68c01976-x86-Viridian-NULL-deref-in-viridian_synic_deliver_timer_msg.patch
  68c01990-x86-Viridian-ref-TSC-page-concurrency.patch
- bsc#1251271 - VUL-0: CVE-2025-58147,CVE-2025-58148: xen:
  Incorrect input sanitisation in Viridian hypercalls (XSA-475)
  68f77801-Viridian-bounds-check-in-vpmask_set.patch
  68f77825-Viridian-bounds-check-in-send_ipi.patch
- bsc#1252692 - VUL-0: CVE-2025-58149: xen: incorrect removal of
  permissions on PCI device unplug allows PV guests to access
  memory of devices no longer assigned to it (XSA-476)
  68fb6f4f-libxl-BAR-address-truncation.patch
- Upstream bug fixes (bsc#1027519)
  68d4ecdf-libacpi-drop-CPU-hotplug-and-GPE-handling.patch
  68d54c89-x86-populate-CPUID-1-EDX-early.patch
  68ecbb3f-x86-HWP-feature_hdc-section.patch
  68ed1199-VT-d-bus_to_context_maddr-retval.patch
- Drop xsa475-1.patch and xsa475-2.patch in favor of upstream
  versions.

- bsc#1252692 - VUL-0: CVE-2025-58149: xen: incorrect removal of
  permissions on PCI device unplug allows PV guests to access
  memory of devices no longer assigned to it (XSA-476)
  xsa476.patch

- bsc#1251271 - VUL-0: CVE-2025-58147,CVE-2025-58148: xen:
  Incorrect input sanitisation in Viridian hypercalls (XSA-475)
  xsa475-1.patch
  xsa475-2.patch

- Upstream bug fixes (bsc#1027519)
  687a40ac-x86-C6-eoi_errata-include-NEHALEM_EX.patch
  68931694-x86-HPET-defer-LAPIC-EOI.patch
  689b0c0c-EFI-cond-FreePages.patch
  68a2e770-x86-mkelf32-pad-segment-to-2Mb.patch
  68a2e7c8-x86-HVM-ioreq-inverted-condition.patch
  68a6ed85-x86-setup-MMCFG-ahead-of-IOMMU.patch
  68ac5f69-x86-adjustments-to-intel_init_ppin.patch

- bsc#1248807 - VUL-0: CVE-2025-27466, CVE-2025-58142,
  CVE-2025-58143: xen: Mutiple vulnerabilities in the Viridian
  interface (XSA-472)
  xsa472-1.patch
  xsa472-2.patch
  xsa472-3.patch

Package xkbcomp was updated:

- 0001-xkbcomp-Don-t-crash-on-no-op-modmask-expressions.patch  (CVE-2018-15863, bsc#1105832)
- 0002-xkbcomp-Don-t-falsely-promise-from-ExprResolveLhs.patch
  (CVE-2018-15861, bsc#1105832)
- 0003-Fail-expression-lookup-on-invalid-atoms.patch
  (CVE-2018-15859, bsc#1105832)
- 0004-xkbcomp-fix-stack-overflow-when-evaluating-boolean-n.patch
  (CVE-2018-15853, bsc#1105832)

</Note>
    <Note Title="Terms of Use" Type="Legal Disclaimer" Ordinal="3" xml:lang="en">The CVRF data is provided by SUSE under the Creative Commons License 4.0 with Attribution (CC-BY-4.0).</Note>
  </DocumentNotes>
  <DocumentReferences>
    <Reference Type="Self">
      <URL>https://publiccloudimagechangeinfo.suse.com/google/sles-sap-15-sp6-v20260123-x86-64/</URL>
      <Description>Public Cloud Image Info</Description>
    </Reference>
    <Reference Type="Self">
      <URL>https://www.suse.com/support/security/rating/</URL>
      <Description>SUSE Security Ratings</Description>
    </Reference>
  </DocumentReferences>
  <ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
    <Branch Type="Product Family" Name="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <Branch Type="Product Name" Name="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
        <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
      </Branch>
    </Branch>
    <Branch Type="Product Version" Name="bash-4.4-150400.27.6.1">
      <FullProductName ProductID="bash-4.4-150400.27.6.1">bash-4.4-150400.27.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="bash-sh-4.4-150400.27.6.1">
      <FullProductName ProductID="bash-sh-4.4-150400.27.6.1">bash-sh-4.4-150400.27.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="bind-utils-9.18.33-150600.3.18.1">
      <FullProductName ProductID="bind-utils-9.18.33-150600.3.18.1">bind-utils-9.18.33-150600.3.18.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="binutils-2.45-150100.7.57.1">
      <FullProductName ProductID="binutils-2.45-150100.7.57.1">binutils-2.45-150100.7.57.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="chrony-4.1-150400.21.8.1">
      <FullProductName ProductID="chrony-4.1-150400.21.8.1">chrony-4.1-150400.21.8.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="chrony-pool-suse-4.1-150400.21.8.1">
      <FullProductName ProductID="chrony-pool-suse-4.1-150400.21.8.1">chrony-pool-suse-4.1-150400.21.8.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cifs-utils-6.15-150400.3.18.1">
      <FullProductName ProductID="cifs-utils-6.15-150400.3.18.1">cifs-utils-6.15-150400.3.18.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cluster-md-kmp-default-6.4.0-150600.23.81.3">
      <FullProductName ProductID="cluster-md-kmp-default-6.4.0-150600.23.81.3">cluster-md-kmp-default-6.4.0-150600.23.81.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="containerd-1.7.29-150000.128.1">
      <FullProductName ProductID="containerd-1.7.29-150000.128.1">containerd-1.7.29-150000.128.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="crash-8.0.4-150600.4.6.2">
      <FullProductName ProductID="crash-8.0.4-150600.4.6.2">crash-8.0.4-150600.4.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="crmsh-4.6.2+20251210.9a742f8c-150600.3.44.1">
      <FullProductName ProductID="crmsh-4.6.2+20251210.9a742f8c-150600.3.44.1">crmsh-4.6.2+20251210.9a742f8c-150600.3.44.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="crmsh-scripts-4.6.2+20251210.9a742f8c-150600.3.44.1">
      <FullProductName ProductID="crmsh-scripts-4.6.2+20251210.9a742f8c-150600.3.44.1">crmsh-scripts-4.6.2+20251210.9a742f8c-150600.3.44.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cups-config-2.2.7-150000.3.83.1">
      <FullProductName ProductID="cups-config-2.2.7-150000.3.83.1">cups-config-2.2.7-150000.3.83.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="curl-8.14.1-150600.4.37.1">
      <FullProductName ProductID="curl-8.14.1-150600.4.37.1">curl-8.14.1-150600.4.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cyrus-sasl-2.1.28-150600.7.14.1">
      <FullProductName ProductID="cyrus-sasl-2.1.28-150600.7.14.1">cyrus-sasl-2.1.28-150600.7.14.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cyrus-sasl-digestmd5-2.1.28-150600.7.14.1">
      <FullProductName ProductID="cyrus-sasl-digestmd5-2.1.28-150600.7.14.1">cyrus-sasl-digestmd5-2.1.28-150600.7.14.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cyrus-sasl-gssapi-2.1.28-150600.7.14.1">
      <FullProductName ProductID="cyrus-sasl-gssapi-2.1.28-150600.7.14.1">cyrus-sasl-gssapi-2.1.28-150600.7.14.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cyrus-sasl-plain-2.1.28-150600.7.14.1">
      <FullProductName ProductID="cyrus-sasl-plain-2.1.28-150600.7.14.1">cyrus-sasl-plain-2.1.28-150600.7.14.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cyrus-sasl-saslauthd-2.1.28-150600.7.14.1">
      <FullProductName ProductID="cyrus-sasl-saslauthd-2.1.28-150600.7.14.1">cyrus-sasl-saslauthd-2.1.28-150600.7.14.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="device-mapper-2.03.22_1.02.196-150600.3.9.3">
      <FullProductName ProductID="device-mapper-2.03.22_1.02.196-150600.3.9.3">device-mapper-2.03.22_1.02.196-150600.3.9.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="dlm-kmp-default-6.4.0-150600.23.81.3">
      <FullProductName ProductID="dlm-kmp-default-6.4.0-150600.23.81.3">dlm-kmp-default-6.4.0-150600.23.81.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="docker-28.5.1_ce-150000.238.1">
      <FullProductName ProductID="docker-28.5.1_ce-150000.238.1">docker-28.5.1_ce-150000.238.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="elfutils-0.185-150400.5.8.3">
      <FullProductName ProductID="elfutils-0.185-150400.5.8.3">elfutils-0.185-150400.5.8.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="firewalld-1.3.4-150600.13.3.1">
      <FullProductName ProductID="firewalld-1.3.4-150600.13.3.1">firewalld-1.3.4-150600.13.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="gfs2-kmp-default-6.4.0-150600.23.81.3">
      <FullProductName ProductID="gfs2-kmp-default-6.4.0-150600.23.81.3">gfs2-kmp-default-6.4.0-150600.23.81.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glib2-tools-2.78.6-150600.4.25.1">
      <FullProductName ProductID="glib2-tools-2.78.6-150600.4.25.1">glib2-tools-2.78.6-150600.4.25.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="gnutls-3.8.3-150600.4.12.1">
      <FullProductName ProductID="gnutls-3.8.3-150600.4.12.1">gnutls-3.8.3-150600.4.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="gpg2-2.4.4-150600.3.12.1">
      <FullProductName ProductID="gpg2-2.4.4-150600.3.12.1">gpg2-2.4.4-150600.3.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grub2-2.12-150600.8.44.2">
      <FullProductName ProductID="grub2-2.12-150600.8.44.2">grub2-2.12-150600.8.44.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grub2-i386-pc-2.12-150600.8.44.2">
      <FullProductName ProductID="grub2-i386-pc-2.12-150600.8.44.2">grub2-i386-pc-2.12-150600.8.44.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grub2-x86_64-efi-2.12-150600.8.44.2">
      <FullProductName ProductID="grub2-x86_64-efi-2.12-150600.8.44.2">grub2-x86_64-efi-2.12-150600.8.44.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="hdparm-9.62-150400.3.5.2">
      <FullProductName ProductID="hdparm-9.62-150400.3.5.2">hdparm-9.62-150400.3.5.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kernel-default-6.4.0-150600.23.81.3">
      <FullProductName ProductID="kernel-default-6.4.0-150600.23.81.3">kernel-default-6.4.0-150600.23.81.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kmod-29-150600.13.3.1">
      <FullProductName ProductID="kmod-29-150600.13.3.1">kmod-29-150600.13.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ldirectord-4.13.0+git6.ae50f94f-150600.4.19.1">
      <FullProductName ProductID="ldirectord-4.13.0+git6.ae50f94f-150600.4.19.1">ldirectord-4.13.0+git6.ae50f94f-150600.4.19.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libQt5Core5-5.15.12+kde151-150600.3.9.1">
      <FullProductName ProductID="libQt5Core5-5.15.12+kde151-150600.3.9.1">libQt5Core5-5.15.12+kde151-150600.3.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libQt5DBus5-5.15.12+kde151-150600.3.9.1">
      <FullProductName ProductID="libQt5DBus5-5.15.12+kde151-150600.3.9.1">libQt5DBus5-5.15.12+kde151-150600.3.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libQt5Gui5-5.15.12+kde151-150600.3.9.1">
      <FullProductName ProductID="libQt5Gui5-5.15.12+kde151-150600.3.9.1">libQt5Gui5-5.15.12+kde151-150600.3.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libQt5Network5-5.15.12+kde151-150600.3.9.1">
      <FullProductName ProductID="libQt5Network5-5.15.12+kde151-150600.3.9.1">libQt5Network5-5.15.12+kde151-150600.3.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libQt5Widgets5-5.15.12+kde151-150600.3.9.1">
      <FullProductName ProductID="libQt5Widgets5-5.15.12+kde151-150600.3.9.1">libQt5Widgets5-5.15.12+kde151-150600.3.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libX11-6-1.8.7-150600.3.6.1">
      <FullProductName ProductID="libX11-6-1.8.7-150600.3.6.1">libX11-6-1.8.7-150600.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libX11-data-1.8.7-150600.3.6.1">
      <FullProductName ProductID="libX11-data-1.8.7-150600.3.6.1">libX11-data-1.8.7-150600.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libX11-xcb1-1.8.7-150600.3.6.1">
      <FullProductName ProductID="libX11-xcb1-1.8.7-150600.3.6.1">libX11-xcb1-1.8.7-150600.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libaio1-0.3.113-150600.15.3.1">
      <FullProductName ProductID="libaio1-0.3.113-150600.15.3.1">libaio1-0.3.113-150600.15.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libasm1-0.185-150400.5.8.3">
      <FullProductName ProductID="libasm1-0.185-150400.5.8.3">libasm1-0.185-150400.5.8.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libatomic1-15.2.0+git10201-150000.1.6.1">
      <FullProductName ProductID="libatomic1-15.2.0+git10201-150000.1.6.1">libatomic1-15.2.0+git10201-150000.1.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libavahi-client3-0.8-150600.15.12.1">
      <FullProductName ProductID="libavahi-client3-0.8-150600.15.12.1">libavahi-client3-0.8-150600.15.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libavahi-common3-0.8-150600.15.12.1">
      <FullProductName ProductID="libavahi-common3-0.8-150600.15.12.1">libavahi-common3-0.8-150600.15.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libblkid1-2.39.3-150600.4.15.1">
      <FullProductName ProductID="libblkid1-2.39.3-150600.4.15.1">libblkid1-2.39.3-150600.4.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libctf-nobfd0-2.45-150100.7.57.1">
      <FullProductName ProductID="libctf-nobfd0-2.45-150100.7.57.1">libctf-nobfd0-2.45-150100.7.57.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libctf0-2.45-150100.7.57.1">
      <FullProductName ProductID="libctf0-2.45-150100.7.57.1">libctf0-2.45-150100.7.57.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libcups2-2.2.7-150000.3.83.1">
      <FullProductName ProductID="libcups2-2.2.7-150000.3.83.1">libcups2-2.2.7-150000.3.83.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libcurl4-8.14.1-150600.4.37.1">
      <FullProductName ProductID="libcurl4-8.14.1-150600.4.37.1">libcurl4-8.14.1-150600.4.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libdevmapper-event1_03-2.03.22_1.02.196-150600.3.9.3">
      <FullProductName ProductID="libdevmapper-event1_03-2.03.22_1.02.196-150600.3.9.3">libdevmapper-event1_03-2.03.22_1.02.196-150600.3.9.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libdevmapper1_03-2.03.22_1.02.196-150600.3.9.3">
      <FullProductName ProductID="libdevmapper1_03-2.03.22_1.02.196-150600.3.9.3">libdevmapper1_03-2.03.22_1.02.196-150600.3.9.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libdlm-4.2.0-150600.3.3.1">
      <FullProductName ProductID="libdlm-4.2.0-150600.3.3.1">libdlm-4.2.0-150600.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libdlm3-4.2.0-150600.3.3.1">
      <FullProductName ProductID="libdlm3-4.2.0-150600.3.3.1">libdlm3-4.2.0-150600.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libdw1-0.185-150400.5.8.3">
      <FullProductName ProductID="libdw1-0.185-150400.5.8.3">libdw1-0.185-150400.5.8.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libelf1-0.185-150400.5.8.3">
      <FullProductName ProductID="libelf1-0.185-150400.5.8.3">libelf1-0.185-150400.5.8.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libfdisk1-2.39.3-150600.4.15.1">
      <FullProductName ProductID="libfdisk1-2.39.3-150600.4.15.1">libfdisk1-2.39.3-150600.4.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libfreebl3-3.112.2-150400.3.60.1">
      <FullProductName ProductID="libfreebl3-3.112.2-150400.3.60.1">libfreebl3-3.112.2-150400.3.60.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libfreetype6-2.10.4-150000.4.25.1">
      <FullProductName ProductID="libfreetype6-2.10.4-150000.4.25.1">libfreetype6-2.10.4-150000.4.25.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgcc_s1-15.2.0+git10201-150000.1.6.1">
      <FullProductName ProductID="libgcc_s1-15.2.0+git10201-150000.1.6.1">libgcc_s1-15.2.0+git10201-150000.1.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgio-2_0-0-2.78.6-150600.4.25.1">
      <FullProductName ProductID="libgio-2_0-0-2.78.6-150600.4.25.1">libgio-2_0-0-2.78.6-150600.4.25.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libglib-2_0-0-2.78.6-150600.4.25.1">
      <FullProductName ProductID="libglib-2_0-0-2.78.6-150600.4.25.1">libglib-2_0-0-2.78.6-150600.4.25.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgmodule-2_0-0-2.78.6-150600.4.25.1">
      <FullProductName ProductID="libgmodule-2_0-0-2.78.6-150600.4.25.1">libgmodule-2_0-0-2.78.6-150600.4.25.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgnutls30-3.8.3-150600.4.12.1">
      <FullProductName ProductID="libgnutls30-3.8.3-150600.4.12.1">libgnutls30-3.8.3-150600.4.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgobject-2_0-0-2.78.6-150600.4.25.1">
      <FullProductName ProductID="libgobject-2_0-0-2.78.6-150600.4.25.1">libgobject-2_0-0-2.78.6-150600.4.25.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgpgme11-1.23.0-150600.3.5.1">
      <FullProductName ProductID="libgpgme11-1.23.0-150600.3.5.1">libgpgme11-1.23.0-150600.3.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgthread-2_0-0-2.78.6-150600.4.25.1">
      <FullProductName ProductID="libgthread-2_0-0-2.78.6-150600.4.25.1">libgthread-2_0-0-2.78.6-150600.4.25.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libkmod2-29-150600.13.3.1">
      <FullProductName ProductID="libkmod2-29-150600.13.3.1">libkmod2-29-150600.13.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="liblvm2cmd2_03-2.03.22-150600.3.9.3">
      <FullProductName ProductID="liblvm2cmd2_03-2.03.22-150600.3.9.3">liblvm2cmd2_03-2.03.22-150600.3.9.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libmount1-2.39.3-150600.4.15.1">
      <FullProductName ProductID="libmount1-2.39.3-150600.4.15.1">libmount1-2.39.3-150600.4.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libnvme-mi1-1.8+93.g5986a5a7-150600.3.21.1">
      <FullProductName ProductID="libnvme-mi1-1.8+93.g5986a5a7-150600.3.21.1">libnvme-mi1-1.8+93.g5986a5a7-150600.3.21.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libnvme1-1.8+93.g5986a5a7-150600.3.21.1">
      <FullProductName ProductID="libnvme1-1.8+93.g5986a5a7-150600.3.21.1">libnvme1-1.8+93.g5986a5a7-150600.3.21.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpcap1-1.10.4-150600.3.9.1">
      <FullProductName ProductID="libpcap1-1.10.4-150600.3.9.1">libpcap1-1.10.4-150600.3.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpci3-3.13.0-150300.13.12.1">
      <FullProductName ProductID="libpci3-3.13.0-150300.13.12.1">libpci3-3.13.0-150300.13.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpng12-0-1.2.57-150000.4.3.1">
      <FullProductName ProductID="libpng12-0-1.2.57-150000.4.3.1">libpng12-0-1.2.57-150000.4.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpng16-16-1.6.40-150600.3.6.1">
      <FullProductName ProductID="libpng16-16-1.6.40-150600.3.6.1">libpng16-16-1.6.40-150600.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpython3_6m1_0-3.6.15-150300.10.103.1">
      <FullProductName ProductID="libpython3_6m1_0-3.6.15-150300.10.103.1">libpython3_6m1_0-3.6.15-150300.10.103.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libreadline7-7.0-150400.27.6.1">
      <FullProductName ProductID="libreadline7-7.0-150400.27.6.1">libreadline7-7.0-150400.27.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libruby2_5-2_5-2.5.9-150000.4.54.1">
      <FullProductName ProductID="libruby2_5-2_5-2.5.9-150000.4.54.1">libruby2_5-2_5-2.5.9-150000.4.54.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsasl2-3-2.1.28-150600.7.14.1">
      <FullProductName ProductID="libsasl2-3-2.1.28-150600.7.14.1">libsasl2-3-2.1.28-150600.7.14.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libselinux1-3.5-150600.3.3.1">
      <FullProductName ProductID="libselinux1-3.5-150600.3.3.1">libselinux1-3.5-150600.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsmartcols1-2.39.3-150600.4.15.1">
      <FullProductName ProductID="libsmartcols1-2.39.3-150600.4.15.1">libsmartcols1-2.39.3-150600.4.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsnmp40-5.9.4-150600.24.10.1">
      <FullProductName ProductID="libsnmp40-5.9.4-150600.24.10.1">libsnmp40-5.9.4-150600.24.10.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsoftokn3-3.112.2-150400.3.60.1">
      <FullProductName ProductID="libsoftokn3-3.112.2-150400.3.60.1">libsoftokn3-3.112.2-150400.3.60.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsolv-tools-base-0.7.34-150600.8.19.2">
      <FullProductName ProductID="libsolv-tools-base-0.7.34-150600.8.19.2">libsolv-tools-base-0.7.34-150600.8.19.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libstdc++6-15.2.0+git10201-150000.1.6.1">
      <FullProductName ProductID="libstdc++6-15.2.0+git10201-150000.1.6.1">libstdc++6-15.2.0+git10201-150000.1.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsystemd0-254.27-150600.4.46.2">
      <FullProductName ProductID="libsystemd0-254.27-150600.4.46.2">libsystemd0-254.27-150600.4.46.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libtasn1-4.13-150000.4.14.1">
      <FullProductName ProductID="libtasn1-4.13-150000.4.14.1">libtasn1-4.13-150000.4.14.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libtasn1-6-4.13-150000.4.14.1">
      <FullProductName ProductID="libtasn1-6-4.13-150000.4.14.1">libtasn1-6-4.13-150000.4.14.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libtiff5-4.0.9-150000.45.60.1">
      <FullProductName ProductID="libtiff5-4.0.9-150000.45.60.1">libtiff5-4.0.9-150000.45.60.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libtiff6-4.7.1-150600.3.23.1">
      <FullProductName ProductID="libtiff6-4.7.1-150600.3.23.1">libtiff6-4.7.1-150600.3.23.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libudev1-254.27-150600.4.46.2">
      <FullProductName ProductID="libudev1-254.27-150600.4.46.2">libudev1-254.27-150600.4.46.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libuuid1-2.39.3-150600.4.15.1">
      <FullProductName ProductID="libuuid1-2.39.3-150600.4.15.1">libuuid1-2.39.3-150600.4.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libvirt-client-10.0.0-150600.8.12.1">
      <FullProductName ProductID="libvirt-client-10.0.0-150600.8.12.1">libvirt-client-10.0.0-150600.8.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libvirt-libs-10.0.0-150600.8.12.1">
      <FullProductName ProductID="libvirt-libs-10.0.0-150600.8.12.1">libvirt-libs-10.0.0-150600.8.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libwebp7-1.0.3-150200.3.14.1">
      <FullProductName ProductID="libwebp7-1.0.3-150200.3.14.1">libwebp7-1.0.3-150200.3.14.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxslt1-1.1.34-150400.3.13.1">
      <FullProductName ProductID="libxslt1-1.1.34-150400.3.13.1">libxslt1-1.1.34-150400.3.13.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="lifecycle-data-sle-module-live-patching-15-150000.4.135.1">
      <FullProductName ProductID="lifecycle-data-sle-module-live-patching-15-150000.4.135.1">lifecycle-data-sle-module-live-patching-15-150000.4.135.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="lvm2-2.03.22-150600.3.9.3">
      <FullProductName ProductID="lvm2-2.03.22-150600.3.9.3">lvm2-2.03.22-150600.3.9.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="lvm2-lockd-2.03.22-150600.3.9.3">
      <FullProductName ProductID="lvm2-lockd-2.03.22-150600.3.9.3">lvm2-lockd-2.03.22-150600.3.9.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="mozilla-nspr-4.36.2-150000.3.36.1">
      <FullProductName ProductID="mozilla-nspr-4.36.2-150000.3.36.1">mozilla-nspr-4.36.2-150000.3.36.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="mozilla-nss-3.112.2-150400.3.60.1">
      <FullProductName ProductID="mozilla-nss-3.112.2-150400.3.60.1">mozilla-nss-3.112.2-150400.3.60.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="mozilla-nss-certs-3.112.2-150400.3.60.1">
      <FullProductName ProductID="mozilla-nss-certs-3.112.2-150400.3.60.1">mozilla-nss-certs-3.112.2-150400.3.60.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="mozilla-nss-tools-3.112.2-150400.3.60.1">
      <FullProductName ProductID="mozilla-nss-tools-3.112.2-150400.3.60.1">mozilla-nss-tools-3.112.2-150400.3.60.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="net-snmp-5.9.4-150600.24.10.1">
      <FullProductName ProductID="net-snmp-5.9.4-150600.24.10.1">net-snmp-5.9.4-150600.24.10.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="nvme-cli-2.8+95.g1a0c2083-150600.3.24.1">
      <FullProductName ProductID="nvme-cli-2.8+95.g1a0c2083-150600.3.24.1">nvme-cli-2.8+95.g1a0c2083-150600.3.24.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ocfs2-kmp-default-6.4.0-150600.23.81.3">
      <FullProductName ProductID="ocfs2-kmp-default-6.4.0-150600.23.81.3">ocfs2-kmp-default-6.4.0-150600.23.81.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-9.6p1-150600.6.34.1">
      <FullProductName ProductID="openssh-9.6p1-150600.6.34.1">openssh-9.6p1-150600.6.34.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-clients-9.6p1-150600.6.34.1">
      <FullProductName ProductID="openssh-clients-9.6p1-150600.6.34.1">openssh-clients-9.6p1-150600.6.34.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-common-9.6p1-150600.6.34.1">
      <FullProductName ProductID="openssh-common-9.6p1-150600.6.34.1">openssh-common-9.6p1-150600.6.34.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-server-9.6p1-150600.6.34.1">
      <FullProductName ProductID="openssh-server-9.6p1-150600.6.34.1">openssh-server-9.6p1-150600.6.34.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-server-config-disallow-rootlogin-9.6p1-150600.6.34.1">
      <FullProductName ProductID="openssh-server-config-disallow-rootlogin-9.6p1-150600.6.34.1">openssh-server-config-disallow-rootlogin-9.6p1-150600.6.34.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="pciutils-3.13.0-150300.13.12.1">
      <FullProductName ProductID="pciutils-3.13.0-150300.13.12.1">pciutils-3.13.0-150300.13.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="perl-HTML-Parser-3.830.0-150000.3.3.1">
      <FullProductName ProductID="perl-HTML-Parser-3.830.0-150000.3.3.1">perl-HTML-Parser-3.830.0-150000.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="perl-SNMP-5.9.4-150600.24.10.1">
      <FullProductName ProductID="perl-SNMP-5.9.4-150600.24.10.1">perl-SNMP-5.9.4-150600.24.10.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-3.6.15-150300.10.103.1">
      <FullProductName ProductID="python3-3.6.15-150300.10.103.1">python3-3.6.15-150300.10.103.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-base-3.6.15-150300.10.103.1">
      <FullProductName ProductID="python3-base-3.6.15-150300.10.103.1">python3-base-3.6.15-150300.10.103.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-curses-3.6.15-150300.10.103.1">
      <FullProductName ProductID="python3-curses-3.6.15-150300.10.103.1">python3-curses-3.6.15-150300.10.103.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-firewall-1.3.4-150600.13.3.1">
      <FullProductName ProductID="python3-firewall-1.3.4-150600.13.3.1">python3-firewall-1.3.4-150600.13.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-solv-0.7.34-150600.8.19.2">
      <FullProductName ProductID="python3-solv-0.7.34-150600.8.19.2">python3-solv-0.7.34-150600.8.19.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="release-notes-ha-15.6.20251031-150600.3.6.1">
      <FullProductName ProductID="release-notes-ha-15.6.20251031-150600.3.6.1">release-notes-ha-15.6.20251031-150600.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="resource-agents-4.13.0+git6.ae50f94f-150600.4.19.1">
      <FullProductName ProductID="resource-agents-4.13.0+git6.ae50f94f-150600.4.19.1">resource-agents-4.13.0+git6.ae50f94f-150600.4.19.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="rsync-3.2.7-150600.3.14.1">
      <FullProductName ProductID="rsync-3.2.7-150600.3.14.1">rsync-3.2.7-150600.3.14.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ruby-solv-0.7.34-150600.8.19.2">
      <FullProductName ProductID="ruby-solv-0.7.34-150600.8.19.2">ruby-solv-0.7.34-150600.8.19.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ruby2.5-2.5.9-150000.4.54.1">
      <FullProductName ProductID="ruby2.5-2.5.9-150000.4.54.1">ruby2.5-2.5.9-150000.4.54.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ruby2.5-rubygem-rack-2.2.20-150000.3.34.1">
      <FullProductName ProductID="ruby2.5-rubygem-rack-2.2.20-150000.3.34.1">ruby2.5-rubygem-rack-2.2.20-150000.3.34.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ruby2.5-stdlib-2.5.9-150000.4.54.1">
      <FullProductName ProductID="ruby2.5-stdlib-2.5.9-150000.4.54.1">ruby2.5-stdlib-2.5.9-150000.4.54.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="runc-1.3.4-150000.88.1">
      <FullProductName ProductID="runc-1.3.4-150000.88.1">runc-1.3.4-150000.88.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="saptune-3.2.1-150400.15.30.3">
      <FullProductName ProductID="saptune-3.2.1-150400.15.30.3">saptune-3.2.1-150400.15.30.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="sle-module-python3-release-15.6-150600.41.1">
      <FullProductName ProductID="sle-module-python3-release-15.6-150600.41.1">sle-module-python3-release-15.6-150600.41.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="snmp-mibs-5.9.4-150600.24.10.1">
      <FullProductName ProductID="snmp-mibs-5.9.4-150600.24.10.1">snmp-mibs-5.9.4-150600.24.10.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="supportutils-plugin-ha-sap-0.0.8+git.1761561174.0434cd5-150000.1.26.1">
      <FullProductName ProductID="supportutils-plugin-ha-sap-0.0.8+git.1761561174.0434cd5-150000.1.26.1">supportutils-plugin-ha-sap-0.0.8+git.1761561174.0434cd5-150000.1.26.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suse-module-tools-15.6.13-150600.3.14.2">
      <FullProductName ProductID="suse-module-tools-15.6.13-150600.3.14.2">suse-module-tools-15.6.13-150600.3.14.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-254.27-150600.4.46.2">
      <FullProductName ProductID="systemd-254.27-150600.4.46.2">systemd-254.27-150600.4.46.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-sysvcompat-254.27-150600.4.46.2">
      <FullProductName ProductID="systemd-sysvcompat-254.27-150600.4.46.2">systemd-sysvcompat-254.27-150600.4.46.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="udev-254.27-150600.4.46.2">
      <FullProductName ProductID="udev-254.27-150600.4.46.2">udev-254.27-150600.4.46.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="util-linux-2.39.3-150600.4.15.1">
      <FullProductName ProductID="util-linux-2.39.3-150600.4.15.1">util-linux-2.39.3-150600.4.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="util-linux-systemd-2.39.3-150600.4.15.1">
      <FullProductName ProductID="util-linux-systemd-2.39.3-150600.4.15.1">util-linux-systemd-2.39.3-150600.4.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="uuidd-2.39.3-150600.4.15.1">
      <FullProductName ProductID="uuidd-2.39.3-150600.4.15.1">uuidd-2.39.3-150600.4.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="vim-9.1.1629-150500.20.38.1">
      <FullProductName ProductID="vim-9.1.1629-150500.20.38.1">vim-9.1.1629-150500.20.38.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="vim-data-common-9.1.1629-150500.20.38.1">
      <FullProductName ProductID="vim-data-common-9.1.1629-150500.20.38.1">vim-data-common-9.1.1629-150500.20.38.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="xen-libs-4.18.5_08-150600.3.34.2">
      <FullProductName ProductID="xen-libs-4.18.5_08-150600.3.34.2">xen-libs-4.18.5_08-150600.3.34.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="xkbcomp-1.4.1-150000.3.6.1">
      <FullProductName ProductID="xkbcomp-1.4.1-150000.3.6.1">xkbcomp-1.4.1-150000.3.6.1</FullProductName>
    </Branch>
    <Relationship ProductReference="bash-4.4-150400.27.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:bash-4.4-150400.27.6.1">bash-4.4-150400.27.6.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="bash-sh-4.4-150400.27.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:bash-sh-4.4-150400.27.6.1">bash-sh-4.4-150400.27.6.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="bind-utils-9.18.33-150600.3.18.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:bind-utils-9.18.33-150600.3.18.1">bind-utils-9.18.33-150600.3.18.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="binutils-2.45-150100.7.57.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:binutils-2.45-150100.7.57.1">binutils-2.45-150100.7.57.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="chrony-4.1-150400.21.8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:chrony-4.1-150400.21.8.1">chrony-4.1-150400.21.8.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="chrony-pool-suse-4.1-150400.21.8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:chrony-pool-suse-4.1-150400.21.8.1">chrony-pool-suse-4.1-150400.21.8.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cifs-utils-6.15-150400.3.18.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:cifs-utils-6.15-150400.3.18.1">cifs-utils-6.15-150400.3.18.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cluster-md-kmp-default-6.4.0-150600.23.81.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:cluster-md-kmp-default-6.4.0-150600.23.81.3">cluster-md-kmp-default-6.4.0-150600.23.81.3 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="containerd-1.7.29-150000.128.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:containerd-1.7.29-150000.128.1">containerd-1.7.29-150000.128.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="crash-8.0.4-150600.4.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:crash-8.0.4-150600.4.6.2">crash-8.0.4-150600.4.6.2 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="crmsh-4.6.2+20251210.9a742f8c-150600.3.44.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:crmsh-4.6.2+20251210.9a742f8c-150600.3.44.1">crmsh-4.6.2+20251210.9a742f8c-150600.3.44.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="crmsh-scripts-4.6.2+20251210.9a742f8c-150600.3.44.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:crmsh-scripts-4.6.2+20251210.9a742f8c-150600.3.44.1">crmsh-scripts-4.6.2+20251210.9a742f8c-150600.3.44.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cups-config-2.2.7-150000.3.83.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:cups-config-2.2.7-150000.3.83.1">cups-config-2.2.7-150000.3.83.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="curl-8.14.1-150600.4.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:curl-8.14.1-150600.4.37.1">curl-8.14.1-150600.4.37.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cyrus-sasl-2.1.28-150600.7.14.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:cyrus-sasl-2.1.28-150600.7.14.1">cyrus-sasl-2.1.28-150600.7.14.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cyrus-sasl-digestmd5-2.1.28-150600.7.14.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:cyrus-sasl-digestmd5-2.1.28-150600.7.14.1">cyrus-sasl-digestmd5-2.1.28-150600.7.14.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cyrus-sasl-gssapi-2.1.28-150600.7.14.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:cyrus-sasl-gssapi-2.1.28-150600.7.14.1">cyrus-sasl-gssapi-2.1.28-150600.7.14.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cyrus-sasl-plain-2.1.28-150600.7.14.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:cyrus-sasl-plain-2.1.28-150600.7.14.1">cyrus-sasl-plain-2.1.28-150600.7.14.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cyrus-sasl-saslauthd-2.1.28-150600.7.14.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:cyrus-sasl-saslauthd-2.1.28-150600.7.14.1">cyrus-sasl-saslauthd-2.1.28-150600.7.14.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="device-mapper-2.03.22_1.02.196-150600.3.9.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:device-mapper-2.03.22_1.02.196-150600.3.9.3">device-mapper-2.03.22_1.02.196-150600.3.9.3 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="dlm-kmp-default-6.4.0-150600.23.81.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:dlm-kmp-default-6.4.0-150600.23.81.3">dlm-kmp-default-6.4.0-150600.23.81.3 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="docker-28.5.1_ce-150000.238.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:docker-28.5.1_ce-150000.238.1">docker-28.5.1_ce-150000.238.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="elfutils-0.185-150400.5.8.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:elfutils-0.185-150400.5.8.3">elfutils-0.185-150400.5.8.3 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="firewalld-1.3.4-150600.13.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:firewalld-1.3.4-150600.13.3.1">firewalld-1.3.4-150600.13.3.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="gfs2-kmp-default-6.4.0-150600.23.81.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:gfs2-kmp-default-6.4.0-150600.23.81.3">gfs2-kmp-default-6.4.0-150600.23.81.3 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glib2-tools-2.78.6-150600.4.25.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:glib2-tools-2.78.6-150600.4.25.1">glib2-tools-2.78.6-150600.4.25.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="gnutls-3.8.3-150600.4.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:gnutls-3.8.3-150600.4.12.1">gnutls-3.8.3-150600.4.12.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="gpg2-2.4.4-150600.3.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:gpg2-2.4.4-150600.3.12.1">gpg2-2.4.4-150600.3.12.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-2.12-150600.8.44.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:grub2-2.12-150600.8.44.2">grub2-2.12-150600.8.44.2 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-i386-pc-2.12-150600.8.44.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:grub2-i386-pc-2.12-150600.8.44.2">grub2-i386-pc-2.12-150600.8.44.2 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-x86_64-efi-2.12-150600.8.44.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:grub2-x86_64-efi-2.12-150600.8.44.2">grub2-x86_64-efi-2.12-150600.8.44.2 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="hdparm-9.62-150400.3.5.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:hdparm-9.62-150400.3.5.2">hdparm-9.62-150400.3.5.2 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kernel-default-6.4.0-150600.23.81.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:kernel-default-6.4.0-150600.23.81.3">kernel-default-6.4.0-150600.23.81.3 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kmod-29-150600.13.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:kmod-29-150600.13.3.1">kmod-29-150600.13.3.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ldirectord-4.13.0+git6.ae50f94f-150600.4.19.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:ldirectord-4.13.0+git6.ae50f94f-150600.4.19.1">ldirectord-4.13.0+git6.ae50f94f-150600.4.19.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libQt5Core5-5.15.12+kde151-150600.3.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libQt5Core5-5.15.12+kde151-150600.3.9.1">libQt5Core5-5.15.12+kde151-150600.3.9.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libQt5DBus5-5.15.12+kde151-150600.3.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libQt5DBus5-5.15.12+kde151-150600.3.9.1">libQt5DBus5-5.15.12+kde151-150600.3.9.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libQt5Gui5-5.15.12+kde151-150600.3.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libQt5Gui5-5.15.12+kde151-150600.3.9.1">libQt5Gui5-5.15.12+kde151-150600.3.9.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libQt5Network5-5.15.12+kde151-150600.3.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libQt5Network5-5.15.12+kde151-150600.3.9.1">libQt5Network5-5.15.12+kde151-150600.3.9.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libQt5Widgets5-5.15.12+kde151-150600.3.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libQt5Widgets5-5.15.12+kde151-150600.3.9.1">libQt5Widgets5-5.15.12+kde151-150600.3.9.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libX11-6-1.8.7-150600.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libX11-6-1.8.7-150600.3.6.1">libX11-6-1.8.7-150600.3.6.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libX11-data-1.8.7-150600.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libX11-data-1.8.7-150600.3.6.1">libX11-data-1.8.7-150600.3.6.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libX11-xcb1-1.8.7-150600.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libX11-xcb1-1.8.7-150600.3.6.1">libX11-xcb1-1.8.7-150600.3.6.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libaio1-0.3.113-150600.15.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libaio1-0.3.113-150600.15.3.1">libaio1-0.3.113-150600.15.3.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libasm1-0.185-150400.5.8.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libasm1-0.185-150400.5.8.3">libasm1-0.185-150400.5.8.3 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libatomic1-15.2.0+git10201-150000.1.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libatomic1-15.2.0+git10201-150000.1.6.1">libatomic1-15.2.0+git10201-150000.1.6.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libavahi-client3-0.8-150600.15.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libavahi-client3-0.8-150600.15.12.1">libavahi-client3-0.8-150600.15.12.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libavahi-common3-0.8-150600.15.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libavahi-common3-0.8-150600.15.12.1">libavahi-common3-0.8-150600.15.12.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libblkid1-2.39.3-150600.4.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libblkid1-2.39.3-150600.4.15.1">libblkid1-2.39.3-150600.4.15.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libctf-nobfd0-2.45-150100.7.57.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libctf-nobfd0-2.45-150100.7.57.1">libctf-nobfd0-2.45-150100.7.57.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libctf0-2.45-150100.7.57.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libctf0-2.45-150100.7.57.1">libctf0-2.45-150100.7.57.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libcups2-2.2.7-150000.3.83.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libcups2-2.2.7-150000.3.83.1">libcups2-2.2.7-150000.3.83.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libcurl4-8.14.1-150600.4.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libcurl4-8.14.1-150600.4.37.1">libcurl4-8.14.1-150600.4.37.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libdevmapper-event1_03-2.03.22_1.02.196-150600.3.9.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libdevmapper-event1_03-2.03.22_1.02.196-150600.3.9.3">libdevmapper-event1_03-2.03.22_1.02.196-150600.3.9.3 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libdevmapper1_03-2.03.22_1.02.196-150600.3.9.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libdevmapper1_03-2.03.22_1.02.196-150600.3.9.3">libdevmapper1_03-2.03.22_1.02.196-150600.3.9.3 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libdlm-4.2.0-150600.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libdlm-4.2.0-150600.3.3.1">libdlm-4.2.0-150600.3.3.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libdlm3-4.2.0-150600.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libdlm3-4.2.0-150600.3.3.1">libdlm3-4.2.0-150600.3.3.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libdw1-0.185-150400.5.8.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libdw1-0.185-150400.5.8.3">libdw1-0.185-150400.5.8.3 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libelf1-0.185-150400.5.8.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libelf1-0.185-150400.5.8.3">libelf1-0.185-150400.5.8.3 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libfdisk1-2.39.3-150600.4.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libfdisk1-2.39.3-150600.4.15.1">libfdisk1-2.39.3-150600.4.15.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libfreebl3-3.112.2-150400.3.60.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libfreebl3-3.112.2-150400.3.60.1">libfreebl3-3.112.2-150400.3.60.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libfreetype6-2.10.4-150000.4.25.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libfreetype6-2.10.4-150000.4.25.1">libfreetype6-2.10.4-150000.4.25.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgcc_s1-15.2.0+git10201-150000.1.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libgcc_s1-15.2.0+git10201-150000.1.6.1">libgcc_s1-15.2.0+git10201-150000.1.6.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgio-2_0-0-2.78.6-150600.4.25.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libgio-2_0-0-2.78.6-150600.4.25.1">libgio-2_0-0-2.78.6-150600.4.25.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libglib-2_0-0-2.78.6-150600.4.25.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libglib-2_0-0-2.78.6-150600.4.25.1">libglib-2_0-0-2.78.6-150600.4.25.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgmodule-2_0-0-2.78.6-150600.4.25.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libgmodule-2_0-0-2.78.6-150600.4.25.1">libgmodule-2_0-0-2.78.6-150600.4.25.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgnutls30-3.8.3-150600.4.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libgnutls30-3.8.3-150600.4.12.1">libgnutls30-3.8.3-150600.4.12.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgobject-2_0-0-2.78.6-150600.4.25.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libgobject-2_0-0-2.78.6-150600.4.25.1">libgobject-2_0-0-2.78.6-150600.4.25.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgpgme11-1.23.0-150600.3.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libgpgme11-1.23.0-150600.3.5.1">libgpgme11-1.23.0-150600.3.5.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgthread-2_0-0-2.78.6-150600.4.25.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libgthread-2_0-0-2.78.6-150600.4.25.1">libgthread-2_0-0-2.78.6-150600.4.25.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libkmod2-29-150600.13.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libkmod2-29-150600.13.3.1">libkmod2-29-150600.13.3.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="liblvm2cmd2_03-2.03.22-150600.3.9.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:liblvm2cmd2_03-2.03.22-150600.3.9.3">liblvm2cmd2_03-2.03.22-150600.3.9.3 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libmount1-2.39.3-150600.4.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libmount1-2.39.3-150600.4.15.1">libmount1-2.39.3-150600.4.15.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libnvme-mi1-1.8+93.g5986a5a7-150600.3.21.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libnvme-mi1-1.8+93.g5986a5a7-150600.3.21.1">libnvme-mi1-1.8+93.g5986a5a7-150600.3.21.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libnvme1-1.8+93.g5986a5a7-150600.3.21.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libnvme1-1.8+93.g5986a5a7-150600.3.21.1">libnvme1-1.8+93.g5986a5a7-150600.3.21.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpcap1-1.10.4-150600.3.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libpcap1-1.10.4-150600.3.9.1">libpcap1-1.10.4-150600.3.9.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpci3-3.13.0-150300.13.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libpci3-3.13.0-150300.13.12.1">libpci3-3.13.0-150300.13.12.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpng12-0-1.2.57-150000.4.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libpng12-0-1.2.57-150000.4.3.1">libpng12-0-1.2.57-150000.4.3.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpng16-16-1.6.40-150600.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libpng16-16-1.6.40-150600.3.6.1">libpng16-16-1.6.40-150600.3.6.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpython3_6m1_0-3.6.15-150300.10.103.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libpython3_6m1_0-3.6.15-150300.10.103.1">libpython3_6m1_0-3.6.15-150300.10.103.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libreadline7-7.0-150400.27.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libreadline7-7.0-150400.27.6.1">libreadline7-7.0-150400.27.6.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libruby2_5-2_5-2.5.9-150000.4.54.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libruby2_5-2_5-2.5.9-150000.4.54.1">libruby2_5-2_5-2.5.9-150000.4.54.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsasl2-3-2.1.28-150600.7.14.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libsasl2-3-2.1.28-150600.7.14.1">libsasl2-3-2.1.28-150600.7.14.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libselinux1-3.5-150600.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libselinux1-3.5-150600.3.3.1">libselinux1-3.5-150600.3.3.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsmartcols1-2.39.3-150600.4.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libsmartcols1-2.39.3-150600.4.15.1">libsmartcols1-2.39.3-150600.4.15.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsnmp40-5.9.4-150600.24.10.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libsnmp40-5.9.4-150600.24.10.1">libsnmp40-5.9.4-150600.24.10.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsoftokn3-3.112.2-150400.3.60.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libsoftokn3-3.112.2-150400.3.60.1">libsoftokn3-3.112.2-150400.3.60.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsolv-tools-base-0.7.34-150600.8.19.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libsolv-tools-base-0.7.34-150600.8.19.2">libsolv-tools-base-0.7.34-150600.8.19.2 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libstdc++6-15.2.0+git10201-150000.1.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libstdc++6-15.2.0+git10201-150000.1.6.1">libstdc++6-15.2.0+git10201-150000.1.6.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsystemd0-254.27-150600.4.46.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libsystemd0-254.27-150600.4.46.2">libsystemd0-254.27-150600.4.46.2 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libtasn1-4.13-150000.4.14.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libtasn1-4.13-150000.4.14.1">libtasn1-4.13-150000.4.14.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libtasn1-6-4.13-150000.4.14.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libtasn1-6-4.13-150000.4.14.1">libtasn1-6-4.13-150000.4.14.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libtiff5-4.0.9-150000.45.60.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libtiff5-4.0.9-150000.45.60.1">libtiff5-4.0.9-150000.45.60.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libtiff6-4.7.1-150600.3.23.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libtiff6-4.7.1-150600.3.23.1">libtiff6-4.7.1-150600.3.23.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libudev1-254.27-150600.4.46.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libudev1-254.27-150600.4.46.2">libudev1-254.27-150600.4.46.2 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libuuid1-2.39.3-150600.4.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libuuid1-2.39.3-150600.4.15.1">libuuid1-2.39.3-150600.4.15.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libvirt-client-10.0.0-150600.8.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libvirt-client-10.0.0-150600.8.12.1">libvirt-client-10.0.0-150600.8.12.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libvirt-libs-10.0.0-150600.8.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libvirt-libs-10.0.0-150600.8.12.1">libvirt-libs-10.0.0-150600.8.12.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libwebp7-1.0.3-150200.3.14.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libwebp7-1.0.3-150200.3.14.1">libwebp7-1.0.3-150200.3.14.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxslt1-1.1.34-150400.3.13.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:libxslt1-1.1.34-150400.3.13.1">libxslt1-1.1.34-150400.3.13.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="lifecycle-data-sle-module-live-patching-15-150000.4.135.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:lifecycle-data-sle-module-live-patching-15-150000.4.135.1">lifecycle-data-sle-module-live-patching-15-150000.4.135.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="lvm2-2.03.22-150600.3.9.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:lvm2-2.03.22-150600.3.9.3">lvm2-2.03.22-150600.3.9.3 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="lvm2-lockd-2.03.22-150600.3.9.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:lvm2-lockd-2.03.22-150600.3.9.3">lvm2-lockd-2.03.22-150600.3.9.3 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="mozilla-nspr-4.36.2-150000.3.36.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:mozilla-nspr-4.36.2-150000.3.36.1">mozilla-nspr-4.36.2-150000.3.36.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="mozilla-nss-3.112.2-150400.3.60.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:mozilla-nss-3.112.2-150400.3.60.1">mozilla-nss-3.112.2-150400.3.60.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="mozilla-nss-certs-3.112.2-150400.3.60.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:mozilla-nss-certs-3.112.2-150400.3.60.1">mozilla-nss-certs-3.112.2-150400.3.60.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="mozilla-nss-tools-3.112.2-150400.3.60.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:mozilla-nss-tools-3.112.2-150400.3.60.1">mozilla-nss-tools-3.112.2-150400.3.60.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="net-snmp-5.9.4-150600.24.10.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:net-snmp-5.9.4-150600.24.10.1">net-snmp-5.9.4-150600.24.10.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="nvme-cli-2.8+95.g1a0c2083-150600.3.24.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:nvme-cli-2.8+95.g1a0c2083-150600.3.24.1">nvme-cli-2.8+95.g1a0c2083-150600.3.24.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ocfs2-kmp-default-6.4.0-150600.23.81.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:ocfs2-kmp-default-6.4.0-150600.23.81.3">ocfs2-kmp-default-6.4.0-150600.23.81.3 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-9.6p1-150600.6.34.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:openssh-9.6p1-150600.6.34.1">openssh-9.6p1-150600.6.34.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-clients-9.6p1-150600.6.34.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:openssh-clients-9.6p1-150600.6.34.1">openssh-clients-9.6p1-150600.6.34.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-common-9.6p1-150600.6.34.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:openssh-common-9.6p1-150600.6.34.1">openssh-common-9.6p1-150600.6.34.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-server-9.6p1-150600.6.34.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:openssh-server-9.6p1-150600.6.34.1">openssh-server-9.6p1-150600.6.34.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-server-config-disallow-rootlogin-9.6p1-150600.6.34.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:openssh-server-config-disallow-rootlogin-9.6p1-150600.6.34.1">openssh-server-config-disallow-rootlogin-9.6p1-150600.6.34.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="pciutils-3.13.0-150300.13.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:pciutils-3.13.0-150300.13.12.1">pciutils-3.13.0-150300.13.12.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="perl-HTML-Parser-3.830.0-150000.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:perl-HTML-Parser-3.830.0-150000.3.3.1">perl-HTML-Parser-3.830.0-150000.3.3.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="perl-SNMP-5.9.4-150600.24.10.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:perl-SNMP-5.9.4-150600.24.10.1">perl-SNMP-5.9.4-150600.24.10.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-3.6.15-150300.10.103.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:python3-3.6.15-150300.10.103.1">python3-3.6.15-150300.10.103.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-base-3.6.15-150300.10.103.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:python3-base-3.6.15-150300.10.103.1">python3-base-3.6.15-150300.10.103.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-curses-3.6.15-150300.10.103.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:python3-curses-3.6.15-150300.10.103.1">python3-curses-3.6.15-150300.10.103.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-firewall-1.3.4-150600.13.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:python3-firewall-1.3.4-150600.13.3.1">python3-firewall-1.3.4-150600.13.3.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-solv-0.7.34-150600.8.19.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:python3-solv-0.7.34-150600.8.19.2">python3-solv-0.7.34-150600.8.19.2 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="release-notes-ha-15.6.20251031-150600.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:release-notes-ha-15.6.20251031-150600.3.6.1">release-notes-ha-15.6.20251031-150600.3.6.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="resource-agents-4.13.0+git6.ae50f94f-150600.4.19.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:resource-agents-4.13.0+git6.ae50f94f-150600.4.19.1">resource-agents-4.13.0+git6.ae50f94f-150600.4.19.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="rsync-3.2.7-150600.3.14.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:rsync-3.2.7-150600.3.14.1">rsync-3.2.7-150600.3.14.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ruby-solv-0.7.34-150600.8.19.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:ruby-solv-0.7.34-150600.8.19.2">ruby-solv-0.7.34-150600.8.19.2 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ruby2.5-2.5.9-150000.4.54.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:ruby2.5-2.5.9-150000.4.54.1">ruby2.5-2.5.9-150000.4.54.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ruby2.5-rubygem-rack-2.2.20-150000.3.34.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:ruby2.5-rubygem-rack-2.2.20-150000.3.34.1">ruby2.5-rubygem-rack-2.2.20-150000.3.34.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ruby2.5-stdlib-2.5.9-150000.4.54.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:ruby2.5-stdlib-2.5.9-150000.4.54.1">ruby2.5-stdlib-2.5.9-150000.4.54.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="runc-1.3.4-150000.88.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:runc-1.3.4-150000.88.1">runc-1.3.4-150000.88.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="saptune-3.2.1-150400.15.30.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:saptune-3.2.1-150400.15.30.3">saptune-3.2.1-150400.15.30.3 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="sle-module-python3-release-15.6-150600.41.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:sle-module-python3-release-15.6-150600.41.1">sle-module-python3-release-15.6-150600.41.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="snmp-mibs-5.9.4-150600.24.10.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:snmp-mibs-5.9.4-150600.24.10.1">snmp-mibs-5.9.4-150600.24.10.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="supportutils-plugin-ha-sap-0.0.8+git.1761561174.0434cd5-150000.1.26.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:supportutils-plugin-ha-sap-0.0.8+git.1761561174.0434cd5-150000.1.26.1">supportutils-plugin-ha-sap-0.0.8+git.1761561174.0434cd5-150000.1.26.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suse-module-tools-15.6.13-150600.3.14.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:suse-module-tools-15.6.13-150600.3.14.2">suse-module-tools-15.6.13-150600.3.14.2 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-254.27-150600.4.46.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:systemd-254.27-150600.4.46.2">systemd-254.27-150600.4.46.2 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-sysvcompat-254.27-150600.4.46.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:systemd-sysvcompat-254.27-150600.4.46.2">systemd-sysvcompat-254.27-150600.4.46.2 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="udev-254.27-150600.4.46.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:udev-254.27-150600.4.46.2">udev-254.27-150600.4.46.2 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="util-linux-2.39.3-150600.4.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:util-linux-2.39.3-150600.4.15.1">util-linux-2.39.3-150600.4.15.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="util-linux-systemd-2.39.3-150600.4.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:util-linux-systemd-2.39.3-150600.4.15.1">util-linux-systemd-2.39.3-150600.4.15.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="uuidd-2.39.3-150600.4.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:uuidd-2.39.3-150600.4.15.1">uuidd-2.39.3-150600.4.15.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-9.1.1629-150500.20.38.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:vim-9.1.1629-150500.20.38.1">vim-9.1.1629-150500.20.38.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-data-common-9.1.1629-150500.20.38.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:vim-data-common-9.1.1629-150500.20.38.1">vim-data-common-9.1.1629-150500.20.38.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="xen-libs-4.18.5_08-150600.3.34.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:xen-libs-4.18.5_08-150600.3.34.2">xen-libs-4.18.5_08-150600.3.34.2 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="xkbcomp-1.4.1-150000.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64:xkbcomp-1.4.1-150000.3.6.1">xkbcomp-1.4.1-150000.3.6.1 as a component of Public Cloud Image google/sles-sap-15-sp6-v20260123-x86-64</FullProductName>
    </Relationship>
  </ProductTree>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Integer overflow in the png_set_unknown_chunks function in libpng/pngset.c in libpng before 1.5.14beta08 allows context-dependent attackers to cause a denial of service (segmentation fault and crash) via a crafted image, which triggers a heap-based buffer overflow.</Note>
    </Notes>
    <CVE>CVE-2013-7353</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>5</BaseScore>
        <Vector>AV:N/AC:L/Au:N/C:N/I:N/A:P</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Multiple integer overflows in libpng before 1.5.14rc03 allow remote attackers to cause a denial of service (crash) via a crafted image to the (1) png_set_sPLT or (2) png_set_text_2 function, which triggers a heap-based buffer overflow.</Note>
    </Notes>
    <CVE>CVE-2013-7354</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>5</BaseScore>
        <Vector>AV:N/AC:L/Au:N/C:N/I:N/A:P</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Endless recursion exists in xkbcomp/expr.c in xkbcommon and libxkbcommon before 0.8.1, which could be used by local attackers to crash xkbcommon users by supplying a crafted keymap file that triggers boolean negation.</Note>
    </Notes>
    <CVE>CVE-2018-15853</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>2.1</BaseScore>
        <Vector>AV:L/AC:L/Au:N/C:N/I:N/A:P</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Unchecked NULL pointer usage when parsing invalid atoms in ExprResolveLhs in xkbcomp/expr.c in xkbcommon before 0.8.2 could be used by local attackers to crash (NULL pointer dereference) the xkbcommon parser by supplying a crafted keymap file, because lookup failures are mishandled.</Note>
    </Notes>
    <CVE>CVE-2018-15859</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>2.1</BaseScore>
        <Vector>AV:L/AC:L/Au:N/C:N/I:N/A:P</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Unchecked NULL pointer usage in ExprResolveLhs in xkbcomp/expr.c in xkbcommon before 0.8.2 could be used by local attackers to crash (NULL pointer dereference) the xkbcommon parser by supplying a crafted keymap file that triggers an xkb_intern_atom failure.</Note>
    </Notes>
    <CVE>CVE-2018-15861</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>2.1</BaseScore>
        <Vector>AV:L/AC:L/Au:N/C:N/I:N/A:P</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Unchecked NULL pointer usage in ResolveStateAndPredicate in xkbcomp/compat.c in xkbcommon before 0.8.2 could be used by local attackers to crash (NULL pointer dereference) the xkbcommon parser by supplying a crafted keymap file with a no-op modmask expression.</Note>
    </Notes>
    <CVE>CVE-2018-15863</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>2.1</BaseScore>
        <Vector>AV:L/AC:L/Au:N/C:N/I:N/A:P</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A directory traversal vulnerability exists in rack &lt; 2.2.0 that allows an attacker perform directory traversal vulnerability in the Rack::Directory app that is bundled with Rack which could result in information disclosure.</Note>
    </Notes>
    <CVE>CVE-2020-8161</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>5</BaseScore>
        <Vector>AV:N/AC:L/Au:N/C:P/I:N/A:N</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A reliance on cookies without validation/integrity check security vulnerability exists in rack &lt; 2.2.3, rack &lt; 2.1.4 that makes it is possible for an attacker to forge a secure or host-only cookie prefix.</Note>
    </Notes>
    <CVE>CVE-2020-8184</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>5</BaseScore>
        <Vector>AV:N/AC:L/Au:N/C:N/I:P/A:N</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A possible denial of service vulnerability exists in Rack &lt;2.0.9.1, &lt;2.1.4.1 and &lt;2.2.3.1 in the multipart parsing component of Rack.</Note>
    </Notes>
    <CVE>CVE-2022-30122</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 sequence injection vulnerability exists in Rack &lt;2.0.9.1, &lt;2.1.4.1 and &lt;2.2.3.1 which could allow is a possible shell escape in the Lint and CommonLogger components of Rack.</Note>
    </Notes>
    <CVE>CVE-2022-30123</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>critical</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A denial of service vulnerability in the Range header parsing component of Rack &gt;= 1.5.0. A Carefully crafted input can cause the Range header parsing component in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. Any applications that deal with Range requests (such as streaming applications, or applications that serve files) may be impacted.</Note>
    </Notes>
    <CVE>CVE-2022-44570</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 denial of service vulnerability in the Content-Disposition parsingcomponent of Rack fixed in 2.0.9.2, 2.1.4.2, 2.2.4.1, 3.0.0.1. This could allow an attacker to craft an input that can cause Content-Disposition header parsing in Rackto take an unexpected amount of time, possibly resulting in a denial ofservice attack vector. This header is used typically used in multipartparsing. Any applications that parse multipart posts using Rack (virtuallyall Rails applications) are impacted.</Note>
    </Notes>
    <CVE>CVE-2022-44571</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A denial of service vulnerability in the multipart parsing component of Rack fixed in 2.0.9.2, 2.1.4.2, 2.2.4.1 and 3.0.0.1 could allow an attacker tocraft input that can cause RFC2183 multipart boundary parsing in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. Any applications that parse multipart posts using Rack (virtually all Rails applications) are impacted.</Note>
    </Notes>
    <CVE>CVE-2022-44572</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: make sure skb-&gt;len != 0 when redirecting to a tunneling device

syzkaller managed to trigger another case where skb-&gt;len == 0
when we enter __dev_queue_xmit:

WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 skb_assert_len include/linux/skbuff.h:2576 [inline]
WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 __dev_queue_xmit+0x2069/0x35e0 net/core/dev.c:4295

Call Trace:
 dev_queue_xmit+0x17/0x20 net/core/dev.c:4406
 __bpf_tx_skb net/core/filter.c:2115 [inline]
 __bpf_redirect_no_mac net/core/filter.c:2140 [inline]
 __bpf_redirect+0x5fb/0xda0 net/core/filter.c:2163
 ____bpf_clone_redirect net/core/filter.c:2447 [inline]
 bpf_clone_redirect+0x247/0x390 net/core/filter.c:2419
 bpf_prog_48159a89cb4a9a16+0x59/0x5e
 bpf_dispatcher_nop_func include/linux/bpf.h:897 [inline]
 __bpf_prog_run include/linux/filter.h:596 [inline]
 bpf_prog_run include/linux/filter.h:603 [inline]
 bpf_test_run+0x46c/0x890 net/bpf/test_run.c:402
 bpf_prog_test_run_skb+0xbdc/0x14c0 net/bpf/test_run.c:1170
 bpf_prog_test_run+0x345/0x3c0 kernel/bpf/syscall.c:3648
 __sys_bpf+0x43a/0x6c0 kernel/bpf/syscall.c:5005
 __do_sys_bpf kernel/bpf/syscall.c:5091 [inline]
 __se_sys_bpf kernel/bpf/syscall.c:5089 [inline]
 __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5089
 do_syscall_64+0x54/0x70 arch/x86/entry/common.c:48
 entry_SYSCALL_64_after_hwframe+0x61/0xc6

The reproducer doesn't really reproduce outside of syzkaller
environment, so I'm taking a guess here. It looks like we
do generate correct ETH_HLEN-sized packet, but we redirect
the packet to the tunneling device. Before we do so, we
__skb_pull l2 header and arrive again at skb-&gt;len == 0.
Doesn't seem like we can do anything better than having
an explicit check after __skb_pull?</Note>
    </Notes>
    <CVE>CVE-2022-50253</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 DoS vulnerability exists in Rack &lt;v3.0.4.2, &lt;v2.2.6.3, &lt;v2.1.4.3 and &lt;v2.0.9.3 within in the Multipart MIME parsing code in which could allow an attacker to craft requests that can be abuse to cause multipart parsing to take longer than expected.</Note>
    </Notes>
    <CVE>CVE-2023-27530</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">There is a denial of service vulnerability in the header parsing component of Rack.</Note>
    </Notes>
    <CVE>CVE-2023-27539</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

scsi: target: iscsi: Fix buffer overflow in lio_target_nacl_info_show()

The function lio_target_nacl_info_show() uses sprintf() in a loop to print
details for every iSCSI connection in a session without checking for the
buffer length. With enough iSCSI connections it's possible to overflow the
buffer provided by configfs and corrupt the memory.

This patch replaces sprintf() with sysfs_emit_at() that checks for buffer
boundries.</Note>
    </Notes>
    <CVE>CVE-2023-53676</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:

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">Rack is a modular Ruby web server interface. Carefully crafted content type headers can cause Rack's media type parser to take much longer than expected, leading to a possible denial of service vulnerability (ReDos 2nd degree polynomial). This vulnerability is patched in 3.0.9.1 and 2.2.8.1.</Note>
    </Notes>
    <CVE>CVE-2024-25126</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">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">Rack is a modular Ruby web server interface. Carefully crafted Range headers can cause a server to respond with an unexpectedly large response. Responding with such large responses could lead to a denial of service issue. Vulnerable applications will use the `Rack::File` middleware or the `Rack::Utils.byte_ranges` methods (this includes Rails applications). The vulnerability is fixed in 3.0.9.1 and 2.2.8.1.</Note>
    </Notes>
    <CVE>CVE-2024-26141</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">Rack is a modular Ruby web server interface. Carefully crafted headers can cause header parsing in Rack to take longer than expected resulting in a possible denial of service issue. Accept and Forwarded headers are impacted. Ruby 3.2 has mitigations for this problem, so Rack applications using Ruby 3.2 or newer are unaffected. This vulnerability is fixed in 2.0.9.4, 2.1.4.4, 2.2.8.1, and 3.0.9.1.</Note>
    </Notes>
    <CVE>CVE-2024-26146</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability, which was classified as problematic, was found in GNU Binutils up to 2.43. This affects the function disassemble_bytes of the file binutils/objdump.c. The manipulation of the argument buf leads to stack-based buffer overflow. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 2.44 is able to address this issue. The identifier of the patch is baac6c221e9d69335bf41366a1c7d87d8ab2f893. It is recommended to upgrade the affected component.</Note>
    </Notes>
    <CVE>CVE-2025-0840</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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">A use-after-free vulnerability was found in libxslt while parsing xsl nodes that may lead to the dereference of expired pointers and application crash.</Note>
    </Notes>
    <CVE>CVE-2025-10911</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability has been found in GNU Binutils 2.45. The affected element is the function elf_swap_shdr in the library bfd/elfcode.h of the component Linker. The manipulation leads to heap-based buffer overflow. The attack must be carried out locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is 9ca499644a21ceb3f946d1c179c38a83be084490. To fix this issue, it is recommended to deploy a patch. The code maintainer replied with "[f]ixed for 2.46".</Note>
    </Notes>
    <CVE>CVE-2025-11083</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability has been found in GNU Binutils 2.45. This impacts the function bfd_elf_gc_record_vtentry of the file bfd/elflink.c of the component Linker. The manipulation leads to out-of-bounds read. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. The identifier of the patch is 047435dd988a3975d40c6626a8f739a0b2e154bc. To fix this issue, it is recommended to deploy a patch.</Note>
    </Notes>
    <CVE>CVE-2025-11412</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was found in GNU Binutils 2.45. Affected is the function elf_link_add_object_symbols of the file bfd/elflink.c of the component Linker. The manipulation results in out-of-bounds read. The attack needs to be approached locally. The exploit has been made public and could be used. Upgrading to version 2.46 is able to address this issue. The patch is identified as 72efdf166aa0ed72ecc69fc2349af6591a7a19c0. Upgrading the affected component is advised.</Note>
    </Notes>
    <CVE>CVE-2025-11413</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was determined in GNU Binutils 2.45. Affected by this vulnerability is the function get_link_hash_entry of the file bfd/elflink.c of the component Linker. This manipulation causes out-of-bounds read. The attack can only be executed locally. The exploit has been publicly disclosed and may be utilized. Upgrading to version 2.46 addresses this issue. Patch name: aeaaa9af6359c8e394ce9cf24911fec4f4d23703. It is advisable to upgrade the affected component.</Note>
    </Notes>
    <CVE>CVE-2025-11414</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability has been found in GNU Binutils 2.43 and classified as problematic. Affected by this vulnerability is the function __sanitizer::internal_strlen of the file binutils/nm.c of the component nm. The manipulation of the argument const leads to buffer overflow. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used.</Note>
    </Notes>
    <CVE>CVE-2025-1147</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was found in GNU Binutils 2.43 and classified as problematic. Affected by this issue is the function link_order_scan of the file ld/ldelfgen.c of the component ld. The manipulation leads to memory leak. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."</Note>
    </Notes>
    <CVE>CVE-2025-1148</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was found in GNU Binutils 2.43. It has been classified as problematic. This affects the function xstrdup of the file libiberty/xmalloc.c of the component ld. The manipulation leads to memory leak. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."</Note>
    </Notes>
    <CVE>CVE-2025-1149</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was found in GNU Binutils 2.45. Impacted is the function _bfd_x86_elf_late_size_sections of the file bfd/elfxx-x86.c of the component Linker. The manipulation results in out-of-bounds read. The attack needs to be approached locally. The exploit has been made public and could be used. The patch is identified as b6ac5a8a5b82f0ae6a4642c8d7149b325f4cc60a. A patch should be applied to remediate this issue.</Note>
    </Notes>
    <CVE>CVE-2025-11494</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was determined in GNU Binutils 2.45. The affected element is the function elf_x86_64_relocate_section of the file elf64-x86-64.c of the component Linker. This manipulation causes heap-based buffer overflow. The attack can only be executed locally. The exploit has been publicly disclosed and may be utilized. Patch name: 6b21c8b2ecfef5c95142cbc2c32f185cb1c26ab0. To fix this issue, it is recommended to deploy a patch.</Note>
    </Notes>
    <CVE>CVE-2025-11495</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was found in GNU Binutils 2.43. It has been declared as problematic. This vulnerability affects the function bfd_malloc of the file libbfd.c of the component ld. The manipulation leads to memory leak. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."</Note>
    </Notes>
    <CVE>CVE-2025-1150</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was found in GNU Binutils 2.43. It has been rated as problematic. This issue affects the function xmemdup of the file xmemdup.c of the component ld. The manipulation leads to memory leak. The attack may be initiated remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."</Note>
    </Notes>
    <CVE>CVE-2025-1151</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability classified as problematic has been found in GNU Binutils 2.43. Affected is the function xstrdup of the file xstrdup.c of the component ld. The manipulation leads to memory leak. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."</Note>
    </Notes>
    <CVE>CVE-2025-1152</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability classified as problematic was found in GNU Binutils 2.43/2.44. Affected by this vulnerability is the function bfd_set_format of the file format.c. The manipulation leads to memory corruption. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. Upgrading to version 2.45 is able to address this issue. The identifier of the patch is 8d97c1a53f3dc9fd8e1ccdb039b8a33d50133150. It is recommended to upgrade the affected component.</Note>
    </Notes>
    <CVE>CVE-2025-1153</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">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">A flaw was found in the exsltFuncResultComp() function of libxslt, which handles EXSLT &lt;func:result&gt; elements during stylesheet parsing. Due to improper type handling, the function may treat an XML document node as a regular XML element node, resulting in a type confusion. This can cause unexpected memory reads and potential crashes. While difficult to exploit, the flaw could lead to application instability or denial of service.</Note>
    </Notes>
    <CVE>CVE-2025-11731</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was found in GNU Binutils 2.43 and classified as critical. This issue affects the function _bfd_elf_gc_mark_rsec of the file elflink.c of the component ld. The manipulation leads to heap-based buffer overflow. The attack may be initiated remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. The patch is named f9978defb6fab0bd8583942d97c112b0932ac814. It is recommended to apply a patch to fix this issue.</Note>
    </Notes>
    <CVE>CVE-2025-1176</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was found in GNU Binutils 2.43. It has been declared as problematic. Affected by this vulnerability is the function bfd_putl64 of the file libbfd.c of the component ld. The manipulation leads to memory corruption. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The identifier of the patch is 75086e9de1707281172cc77f178e7949a4414ed0. It is recommended to apply a patch to fix this issue.</Note>
    </Notes>
    <CVE>CVE-2025-1178</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was found in GNU Binutils 2.43. It has been rated as critical. Affected by this issue is the function bfd_putl64 of the file bfd/libbfd.c of the component ld. The manipulation leads to memory corruption. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 2.44 is able to address this issue. It is recommended to upgrade the affected component. The code maintainer explains, that "[t]his bug has been fixed at some point between the 2.43 and 2.44 releases".</Note>
    </Notes>
    <CVE>CVE-2025-1179</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability classified as problematic has been found in GNU Binutils 2.43. This affects the function _bfd_elf_write_section_eh_frame of the file bfd/elf-eh-frame.c of the component ld. The manipulation leads to memory corruption. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue.</Note>
    </Notes>
    <CVE>CVE-2025-1180</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability classified as critical was found in GNU Binutils 2.43. This vulnerability affects the function _bfd_elf_gc_mark_rsec of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is 931494c9a89558acb36a03a340c01726545eef24. It is recommended to apply a patch to fix this issue.</Note>
    </Notes>
    <CVE>CVE-2025-1181</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability, which was classified as critical, was found in GNU Binutils 2.43. Affected is the function bfd_elf_reloc_symbol_deleted_p of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. The patch is identified as b425859021d17adf62f06fb904797cf8642986ad. It is recommended to apply a patch to fix this issue.</Note>
    </Notes>
    <CVE>CVE-2025-1182</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">pcap_ether_aton() is an auxiliary function in libpcap, it takes a string argument and returns a fixed-size allocated buffer.  The string argument must be a well-formed MAC-48 address in one of the supported formats, but this requirement has been poorly documented.  If an application calls the function with an argument that deviates from the expected format, the function can read data beyond the end of the provided string and write data beyond the end of the allocated buffer.</Note>
    </Notes>
    <CVE>CVE-2025-11961</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">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">A flaw was discovered in libvirt in the XML file processing. More specifically, the parsing of user provided XML files was performed before the ACL checks. A malicious user with limited permissions could exploit this flaw by submitting a specially crafted XML file, causing libvirt to allocate too much memory on the host. The excessive memory consumption could lead to a libvirt process crash on the host, resulting in a denial-of-service condition.</Note>
    </Notes>
    <CVE>CVE-2025-12748</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 flaw was found in libvirt. External inactive snapshots for shut-down VMs are incorrectly created as world-readable, making it possible for unprivileged users to inspect the guest OS contents. This results in an information disclosure vulnerability.</Note>
    </Notes>
    <CVE>CVE-2025-13193</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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">When doing multi-threaded LDAPS transfers (LDAP over TLS) with libcurl,
changing TLS options in one thread would inadvertently change them globally
and therefore possibly also affect other concurrently setup transfers.

Disabling certificate verification for a specific transfer could
unintentionally disable the feature for other threads as well.</Note>
    </Notes>
    <CVE>CVE-2025-14017</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 util-linux. This vulnerability allows a heap buffer overread when processing 256-byte usernames, specifically within the `setpwnam()` function, affecting SUID (Set User ID) login-utils utilities writing to the password database.</Note>
    </Notes>
    <CVE>CVE-2025-14104</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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">In the Linux kernel, the following vulnerability has been resolved:

tcp: correct handling of extreme memory squeeze

Testing with iperf3 using the "pasta" protocol splicer has revealed
a problem in the way tcp handles window advertising in extreme memory
squeeze situations.

Under memory pressure, a socket endpoint may temporarily advertise
a zero-sized window, but this is not stored as part of the socket data.
The reasoning behind this is that it is considered a temporary setting
which shouldn't influence any further calculations.

However, if we happen to stall at an unfortunate value of the current
window size, the algorithm selecting a new value will consistently fail
to advertise a non-zero window once we have freed up enough memory.
This means that this side's notion of the current window size is
different from the one last advertised to the peer, causing the latter
to not send any data to resolve the sitution.

The problem occurs on the iperf3 server side, and the socket in question
is a completely regular socket with the default settings for the
fedora40 kernel. We do not use SO_PEEK or SO_RCVBUF on the socket.

The following excerpt of a logging session, with own comments added,
shows more in detail what is happening:

//              tcp_v4_rcv(-&gt;)
//                tcp_rcv_established(-&gt;)
[5201&lt;-&gt;39222]:     ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ====
[5201&lt;-&gt;39222]:     tcp_data_queue(-&gt;)
[5201&lt;-&gt;39222]:        DROPPING skb [265600160..265665640], reason: SKB_DROP_REASON_PROTO_MEM
                       [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]
                       [copied_seq 259909392-&gt;260034360 (124968), unread 5565800, qlen 85, ofoq 0]
                       [OFO queue: gap: 65480, len: 0]
[5201&lt;-&gt;39222]:     tcp_data_queue(&lt;-)
[5201&lt;-&gt;39222]:     __tcp_transmit_skb(-&gt;)
                        [tp-&gt;rcv_wup: 265469200, tp-&gt;rcv_wnd: 262144, tp-&gt;rcv_nxt 265600160]
[5201&lt;-&gt;39222]:       tcp_select_window(-&gt;)
[5201&lt;-&gt;39222]:         (inet_csk(sk)-&gt;icsk_ack.pending &amp; ICSK_ACK_NOMEM) ? --&gt; TRUE
                        [tp-&gt;rcv_wup: 265469200, tp-&gt;rcv_wnd: 262144, tp-&gt;rcv_nxt 265600160]
                        returning 0
[5201&lt;-&gt;39222]:       tcp_select_window(&lt;-)
[5201&lt;-&gt;39222]:       ADVERTISING WIN 0, ACK_SEQ: 265600160
[5201&lt;-&gt;39222]:     [__tcp_transmit_skb(&lt;-)
[5201&lt;-&gt;39222]:   tcp_rcv_established(&lt;-)
[5201&lt;-&gt;39222]: tcp_v4_rcv(&lt;-)

// Receive queue is at 85 buffers and we are out of memory.
// We drop the incoming buffer, although it is in sequence, and decide
// to send an advertisement with a window of zero.
// We don't update tp-&gt;rcv_wnd and tp-&gt;rcv_wup accordingly, which means
// we unconditionally shrink the window.

[5201&lt;-&gt;39222]: tcp_recvmsg_locked(-&gt;)
[5201&lt;-&gt;39222]:   __tcp_cleanup_rbuf(-&gt;) tp-&gt;rcv_wup: 265469200, tp-&gt;rcv_wnd: 262144, tp-&gt;rcv_nxt 265600160
[5201&lt;-&gt;39222]:     [new_win = 0, win_now = 131184, 2 * win_now = 262368]
[5201&lt;-&gt;39222]:     [new_win &gt;= (2 * win_now) ? --&gt; time_to_ack = 0]
[5201&lt;-&gt;39222]:     NOT calling tcp_send_ack()
                    [tp-&gt;rcv_wup: 265469200, tp-&gt;rcv_wnd: 262144, tp-&gt;rcv_nxt 265600160]
[5201&lt;-&gt;39222]:   __tcp_cleanup_rbuf(&lt;-)
                  [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]
                  [copied_seq 260040464-&gt;260040464 (0), unread 5559696, qlen 85, ofoq 0]
                  returning 6104 bytes
[5201&lt;-&gt;39222]: tcp_recvmsg_locked(&lt;-)

// After each read, the algorithm for calculating the new receive
// window in __tcp_cleanup_rbuf() finds it is too small to advertise
// or to update tp-&gt;rcv_wnd.
// Meanwhile, the peer thinks the window is zero, and will not send
// any more data to trigger an update from the interrupt mode side.

[5201&lt;-&gt;39222]: tcp_recvmsg_locked(-&gt;)
[5201&lt;-&gt;39222]:   __tcp_cleanup_rbuf(-&gt;) tp-&gt;rcv_wup: 265469200, tp-&gt;rcv_wnd: 262144, tp-&gt;rcv_nxt 265600160
[5201&lt;-&gt;39222]:     [new_win = 262144, win_now = 131184, 2 * win_n
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-21710</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 attack vector is a potential Denial of Service (DoS). The vulnerability is caused by an insufficient check on the length of a decompressed domain name within a DNS packet.

An attacker can craft a malicious DNS packet containing a highly compressed domain name. When the resolv library parses such a packet, the name decompression process consumes a large amount of CPU resources, as the library does not limit the resulting length of the name.

This resource consumption can cause the application thread to become unresponsive, resulting in a Denial of Service condition.</Note>
    </Notes>
    <CVE>CVE-2025-24294</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Rack provides an interface for developing web applications in Ruby. Prior to versions 2.2.11, 3.0.12, and 3.1.10, Rack::CommonLogger can be exploited by crafting input that includes newline characters to manipulate log entries. The supplied proof-of-concept demonstrates injecting malicious content into logs. When a user provides the authorization credentials via Rack::Auth::Basic, if success, the username will be put in env['REMOTE_USER'] and later be used by Rack::CommonLogger for logging purposes. The issue occurs when a server intentionally or unintentionally allows a user creation with the username contain CRLF and white space characters, or the server just want to log every login attempts. If an attacker enters a username with CRLF character, the logger will log the malicious username with CRLF characters into the logfile. Attackers can break log formats or insert fraudulent entries, potentially obscuring real activity or injecting malicious data into log files. Versions 2.2.11, 3.0.12, and 3.1.10 contain a fix.</Note>
    </Notes>
    <CVE>CVE-2025-25184</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Rack is a modular Ruby web server interface. The Rack::Sendfile middleware logs unsanitised header values from the X-Sendfile-Type header. An attacker can exploit this by injecting escape sequences (such as newline characters) into the header, resulting in log injection. This vulnerability is fixed in 2.2.12, 3.0.13, and 3.1.11.</Note>
    </Notes>
    <CVE>CVE-2025-27111</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]

There are multiple issues related to the handling and accessing of guest
memory pages in the viridian code:

 1. A NULL pointer dereference in the updating of the reference TSC area.
    This is CVE-2025-27466.

 2. A NULL pointer dereference by assuming the SIM page is mapped when
    a synthetic timer message has to be delivered.  This is
    CVE-2025-58142.

 3. A race in the mapping of the reference TSC page, where a guest can
    get Xen to free a page while still present in the guest physical to
    machine (p2m) page tables.  This is CVE-2025-58143.</Note>
    </Notes>
    <CVE>CVE-2025-27466</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">Rack provides an interface for developing web applications in Ruby. Prior to versions 2.2.13, 3.0.14, and 3.1.12, `Rack::Static` can serve files under the specified `root:` even if `urls:` are provided, which may expose other files under the specified `root:` unexpectedly. The vulnerability occurs because `Rack::Static` does not properly sanitize user-supplied paths before serving files. Specifically, encoded path traversal sequences are not correctly validated, allowing attackers to access files outside the designated static file directory. By exploiting this vulnerability, an attacker can gain access to all files under the specified `root:` directory, provided they are able to determine then path of the file. Versions 2.2.13, 3.0.14, and 3.1.12 contain a patch for the issue. Other mitigations include removing usage of `Rack::Static`, or ensuring that `root:` points at a directory path which only contains files which should be accessed publicly. It is likely that a CDN or similar static file server would also mitigate the issue.</Note>
    </Notes>
    <CVE>CVE-2025-27610</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">encodeText in QDom in Qt before 6.8.0 has a complex algorithm involving XML string copy and inline replacement of parts of a string (with relocation of later data).</Note>
    </Notes>
    <CVE>CVE-2025-30348</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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">A vulnerability has been found in GNU Binutils 2.43/2.44 and classified as problematic. Affected by this vulnerability is the function display_info of the file binutils/bucomm.c of the component objdump. The manipulation leads to memory leak. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The patch is named ba6ad3a18cb26b79e0e3b84c39f707535bbc344d. It is recommended to apply a patch to fix this issue.</Note>
    </Notes>
    <CVE>CVE-2025-3198</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Rack is a modular Ruby web server interface. Prior to version 2.2.14, when using the `Rack::Session::Pool` middleware, simultaneous rack requests can restore a deleted rack session, which allows the unauthenticated user to occupy that session. Rack session middleware prepares the session at the beginning of request, then saves is back to the store with possible changes applied by host rack application. This way the session becomes to be a subject of race conditions in general sense over concurrent rack requests. When using the `Rack::Session::Pool` middleware, and provided the attacker can acquire a session cookie (already a major issue), the session may be restored if the attacker can trigger a long running request (within that same session) adjacent to the user logging out, in order to retain illicit access even after a user has attempted to logout. Version 2.2.14 contains a patch for the issue. Some other mitigations are available. Either ensure the application invalidates sessions atomically by marking them as logged out e.g., using a `logged_out` flag, instead of deleting them, and check this flag on every request to prevent reuse; or implement a custom session store that tracks session invalidation timestamps and refuses to accept session data if the session was invalidated after the request began.</Note>
    </Notes>
    <CVE>CVE-2025-32441</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pds_core: remove write-after-free of client_id

A use-after-free error popped up in stress testing:

[Mon Apr 21 21:21:33 2025] BUG: KFENCE: use-after-free write in pdsc_auxbus_dev_del+0xef/0x160 [pds_core]
[Mon Apr 21 21:21:33 2025] Use-after-free write at 0x000000007013ecd1 (in kfence-#47):
[Mon Apr 21 21:21:33 2025]  pdsc_auxbus_dev_del+0xef/0x160 [pds_core]
[Mon Apr 21 21:21:33 2025]  pdsc_remove+0xc0/0x1b0 [pds_core]
[Mon Apr 21 21:21:33 2025]  pci_device_remove+0x24/0x70
[Mon Apr 21 21:21:33 2025]  device_release_driver_internal+0x11f/0x180
[Mon Apr 21 21:21:33 2025]  driver_detach+0x45/0x80
[Mon Apr 21 21:21:33 2025]  bus_remove_driver+0x83/0xe0
[Mon Apr 21 21:21:33 2025]  pci_unregister_driver+0x1a/0x80

The actual device uninit usually happens on a separate thread
scheduled after this code runs, but there is no guarantee of order
of thread execution, so this could be a problem.  There's no
actual need to clear the client_id at this point, so simply
remove the offending code.</Note>
    </Notes>
    <CVE>CVE-2025-37916</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

s390/mm: Fix in_atomic() handling in do_secure_storage_access()

Kernel user spaces accesses to not exported pages in atomic context
incorrectly try to resolve the page fault.
With debug options enabled call traces like this can be seen:

BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1523
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 419074, name: qemu-system-s39
preempt_count: 1, expected: 0
RCU nest depth: 0, expected: 0
INFO: lockdep is turned off.
Preemption disabled at:
[&lt;00000383ea47cfa2&gt;] copy_page_from_iter_atomic+0xa2/0x8a0
CPU: 12 UID: 0 PID: 419074 Comm: qemu-system-s39
Tainted: G        W           6.16.0-20250531.rc0.git0.69b3a602feac.63.fc42.s390x+debug #1 PREEMPT
Tainted: [W]=WARN
Hardware name: IBM 3931 A01 703 (LPAR)
Call Trace:
 [&lt;00000383e990d282&gt;] dump_stack_lvl+0xa2/0xe8
 [&lt;00000383e99bf152&gt;] __might_resched+0x292/0x2d0
 [&lt;00000383eaa7c374&gt;] down_read+0x34/0x2d0
 [&lt;00000383e99432f8&gt;] do_secure_storage_access+0x108/0x360
 [&lt;00000383eaa724b0&gt;] __do_pgm_check+0x130/0x220
 [&lt;00000383eaa842e4&gt;] pgm_check_handler+0x114/0x160
 [&lt;00000383ea47d028&gt;] copy_page_from_iter_atomic+0x128/0x8a0
([&lt;00000383ea47d016&gt;] copy_page_from_iter_atomic+0x116/0x8a0)
 [&lt;00000383e9c45eae&gt;] generic_perform_write+0x16e/0x310
 [&lt;00000383e9eb87f4&gt;] ext4_buffered_write_iter+0x84/0x160
 [&lt;00000383e9da0de4&gt;] vfs_write+0x1c4/0x460
 [&lt;00000383e9da123c&gt;] ksys_write+0x7c/0x100
 [&lt;00000383eaa7284e&gt;] __do_syscall+0x15e/0x280
 [&lt;00000383eaa8417e&gt;] system_call+0x6e/0x90
INFO: lockdep is turned off.

It is not allowed to take the mmap_lock while in atomic context. Therefore
handle such a secure storage access fault as if the accessed page is not
mapped: the uaccess function will return -EFAULT, and the caller has to
deal with this. Usually this means that the access is retried in process
context, which allows to resolve the page fault (or in this case export the
page).</Note>
    </Notes>
    <CVE>CVE-2025-38359</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check dce_hwseq before dereferencing it

[WHAT]

hws was checked for null earlier in dce110_blank_stream, indicating hws
can be null, and should be checked whenever it is used.

(cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad)</Note>
    </Notes>
    <CVE>CVE-2025-38361</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

scsi: ufs: exynos: Fix programming of HCI_UTRL_NEXUS_TYPE

On Google gs101, the number of UTP transfer request slots (nutrs) is 32,
and in this case the driver ends up programming the UTRL_NEXUS_TYPE
incorrectly as 0.

This is because the left hand side of the shift is 1, which is of type
int, i.e. 31 bits wide. Shifting by more than that width results in
undefined behaviour.

Fix this by switching to the BIT() macro, which applies correct type
casting as required. This ensures the correct value is written to
UTRL_NEXUS_TYPE (0xffffffff on gs101), and it also fixes a UBSAN shift
warning:

    UBSAN: shift-out-of-bounds in drivers/ufs/host/ufs-exynos.c:1113:21
    shift exponent 32 is too large for 32-bit type 'int'

For consistency, apply the same change to the nutmrs / UTMRL_NEXUS_TYPE
write.</Note>
    </Notes>
    <CVE>CVE-2025-39788</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

net: macb: fix unregister_netdev call order in macb_remove()

When removing a macb device, the driver calls phy_exit() before
unregister_netdev(). This leads to a WARN from kernfs:

  ------------[ cut here ]------------
  kernfs: can not remove 'attached_dev', no directory
  WARNING: CPU: 1 PID: 27146 at fs/kernfs/dir.c:1683
  Call trace:
    kernfs_remove_by_name_ns+0xd8/0xf0
    sysfs_remove_link+0x24/0x58
    phy_detach+0x5c/0x168
    phy_disconnect+0x4c/0x70
    phylink_disconnect_phy+0x6c/0xc0 [phylink]
    macb_close+0x6c/0x170 [macb]
    ...
    macb_remove+0x60/0x168 [macb]
    platform_remove+0x5c/0x80
    ...

The warning happens because the PHY is being exited while the netdev
is still registered. The correct order is to unregister the netdev
before shutting down the PHY and cleaning up the MDIO bus.

Fix this by moving unregister_netdev() ahead of phy_exit() in
macb_remove().</Note>
    </Notes>
    <CVE>CVE-2025-39805</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

fs/smb: Fix inconsistent refcnt update

A possible inconsistent update of refcount was identified in `smb2_compound_op`.
Such inconsistent update could lead to possible resource leaks.

Why it is a possible bug:
1. In the comment section of the function, it clearly states that the
reference to `cfile` should be dropped after calling this function.
2. Every control flow path would check and drop the reference to
`cfile`, except the patched one.
3. Existing callers would not handle refcount update of `cfile` if
-ENOMEM is returned.

To fix the bug, an extra goto label "out" is added, to make sure that the
cleanup logic would always be respected. As the problem is caused by the
allocation failure of `vars`, the cleanup logic between label "finished"
and "out" can be safely ignored. According to the definition of function
`is_replayable_error`, the error code of "-ENOMEM" is not recoverable.
Therefore, the replay logic also gets ignored.</Note>
    </Notes>
    <CVE>CVE-2025-39819</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

ptp: ocp: fix use-after-free bugs causing by ptp_ocp_watchdog

The ptp_ocp_detach() only shuts down the watchdog timer if it is
pending. However, if the timer handler is already running, the
timer_delete_sync() is not called. This leads to race conditions
where the devlink that contains the ptp_ocp is deallocated while
the timer handler is still accessing it, resulting in use-after-free
bugs. The following details one of the race scenarios.

(thread 1)                           | (thread 2)
ptp_ocp_remove()                     |
  ptp_ocp_detach()                   | ptp_ocp_watchdog()
    if (timer_pending(&amp;bp-&gt;watchdog))|   bp = timer_container_of()
      timer_delete_sync()            |
                                     |
  devlink_free(devlink) //free       |
                                     |   bp-&gt; //use

Resolve this by unconditionally calling timer_delete_sync() to ensure
the timer is reliably deactivated, preventing any access after free.</Note>
    </Notes>
    <CVE>CVE-2025-39859</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

octeontx2-pf: Fix use-after-free bugs in otx2_sync_tstamp()

The original code relies on cancel_delayed_work() in otx2_ptp_destroy(),
which does not ensure that the delayed work item synctstamp_work has fully
completed if it was already running. This leads to use-after-free scenarios
where otx2_ptp is deallocated by otx2_ptp_destroy(), while synctstamp_work
remains active and attempts to dereference otx2_ptp in otx2_sync_tstamp().
Furthermore, the synctstamp_work is cyclic, the likelihood of triggering
the bug is nonnegligible.

A typical race condition is illustrated below:

CPU 0 (cleanup)           | CPU 1 (delayed work callback)
otx2_remove()             |
  otx2_ptp_destroy()      | otx2_sync_tstamp()
    cancel_delayed_work() |
    kfree(ptp)            |
                          |   ptp = container_of(...); //UAF
                          |   ptp-&gt; //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 ffff88800aa09a18 by task bash/136
...
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
 otx2_ptp_init+0xb1/0x860
 otx2_probe+0x4eb/0xc30
 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 136:
 kasan_save_stack+0x24/0x50
 kasan_save_track+0x14/0x30
 kasan_save_free_info+0x3a/0x60
 __kasan_slab_free+0x3f/0x50
 kfree+0x137/0x370
 otx2_ptp_destroy+0x38/0x80
 otx2_remove+0x10d/0x4c0
 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 before the otx2_ptp is
deallocated.

This bug was initially identified through static analysis. To reproduce
and test it, I simulated the OcteonTX2 PCI device in QEMU and introduced
artificial delays within the otx2_sync_tstamp() function to increase the
likelihood of triggering the bug.</Note>
    </Notes>
    <CVE>CVE-2025-39944</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

nexthop: Forbid FDB status change while nexthop is in a group

The kernel forbids the creation of non-FDB nexthop groups with FDB
nexthops:

 # ip nexthop add id 1 via 192.0.2.1 fdb
 # ip nexthop add id 2 group 1
 Error: Non FDB nexthop group cannot have fdb nexthops.

And vice versa:

 # ip nexthop add id 3 via 192.0.2.2 dev dummy1
 # ip nexthop add id 4 group 3 fdb
 Error: FDB nexthop group can only have fdb nexthops.

However, as long as no routes are pointing to a non-FDB nexthop group,
the kernel allows changing the type of a nexthop from FDB to non-FDB and
vice versa:

 # ip nexthop add id 5 via 192.0.2.2 dev dummy1
 # ip nexthop add id 6 group 5
 # ip nexthop replace id 5 via 192.0.2.2 fdb
 # echo $?
 0

This configuration is invalid and can result in a NPD [1] since FDB
nexthops are not associated with a nexthop device:

 # ip route add 198.51.100.1/32 nhid 6
 # ping 198.51.100.1

Fix by preventing nexthop FDB status change while the nexthop is in a
group:

 # ip nexthop add id 7 via 192.0.2.2 dev dummy1
 # ip nexthop add id 8 group 7
 # ip nexthop replace id 7 via 192.0.2.2 fdb
 Error: Cannot change nexthop FDB status while in a group.

[1]
BUG: kernel NULL pointer dereference, address: 00000000000003c0
[...]
Oops: Oops: 0000 [#1] SMP
CPU: 6 UID: 0 PID: 367 Comm: ping Not tainted 6.17.0-rc6-virtme-gb65678cacc03 #1 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014
RIP: 0010:fib_lookup_good_nhc+0x1e/0x80
[...]
Call Trace:
 &lt;TASK&gt;
 fib_table_lookup+0x541/0x650
 ip_route_output_key_hash_rcu+0x2ea/0x970
 ip_route_output_key_hash+0x55/0x80
 __ip4_datagram_connect+0x250/0x330
 udp_connect+0x2b/0x60
 __sys_connect+0x9c/0xd0
 __x64_sys_connect+0x18/0x20
 do_syscall_64+0xa4/0x2a0
 entry_SYSCALL_64_after_hwframe+0x4b/0x53</Note>
    </Notes>
    <CVE>CVE-2025-39980</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

scsi: mvsas: Fix use-after-free bugs in mvs_work_queue

During the detaching of Marvell's SAS/SATA controller, the original code
calls cancel_delayed_work() in mvs_free() to cancel the delayed work
item mwq-&gt;work_q. However, if mwq-&gt;work_q is already running, the
cancel_delayed_work() may fail to cancel it. This can lead to
use-after-free scenarios where mvs_free() frees the mvs_info while
mvs_work_queue() is still executing and attempts to access the
already-freed mvs_info.

A typical race condition is illustrated below:

CPU 0 (remove)            | CPU 1 (delayed work callback)
mvs_pci_remove()          |
  mvs_free()              | mvs_work_queue()
    cancel_delayed_work() |
      kfree(mvi)          |
                          |   mvi-&gt; // UAF

Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure
that the delayed work item is properly canceled and any executing
delayed work item completes before the mvs_info is deallocated.

This bug was found by static analysis.</Note>
    </Notes>
    <CVE>CVE-2025-40001</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

tracing: dynevent: Add a missing lockdown check on dynevent

Since dynamic_events interface on tracefs is compatible with
kprobe_events and uprobe_events, it should also check the lockdown
status and reject if it is set.</Note>
    </Notes>
    <CVE>CVE-2025-40021</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/9p: fix double req put in p9_fd_cancelled

Syzkaller reports a KASAN issue as below:

general protection fault, probably for non-canonical address 0xfbd59c0000000021: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: maybe wild-memory-access in range [0xdead000000000108-0xdead00000000010f]
CPU: 0 PID: 5083 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00037-g855bd1d7d838 #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
RIP: 0010:__list_del include/linux/list.h:114 [inline]
RIP: 0010:__list_del_entry include/linux/list.h:137 [inline]
RIP: 0010:list_del include/linux/list.h:148 [inline]
RIP: 0010:p9_fd_cancelled+0xe9/0x200 net/9p/trans_fd.c:734

Call Trace:
 &lt;TASK&gt;
 p9_client_flush+0x351/0x440 net/9p/client.c:614
 p9_client_rpc+0xb6b/0xc70 net/9p/client.c:734
 p9_client_version net/9p/client.c:920 [inline]
 p9_client_create+0xb51/0x1240 net/9p/client.c:1027
 v9fs_session_init+0x1f0/0x18f0 fs/9p/v9fs.c:408
 v9fs_mount+0xba/0xcb0 fs/9p/vfs_super.c:126
 legacy_get_tree+0x108/0x220 fs/fs_context.c:632
 vfs_get_tree+0x8e/0x300 fs/super.c:1573
 do_new_mount fs/namespace.c:3056 [inline]
 path_mount+0x6a6/0x1e90 fs/namespace.c:3386
 do_mount fs/namespace.c:3399 [inline]
 __do_sys_mount fs/namespace.c:3607 [inline]
 __se_sys_mount fs/namespace.c:3584 [inline]
 __x64_sys_mount+0x283/0x300 fs/namespace.c:3584
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81
 entry_SYSCALL_64_after_hwframe+0x6e/0xd8

This happens because of a race condition between:

- The 9p client sending an invalid flush request and later cleaning it up;
- The 9p client in p9_read_work() canceled all pending requests.

      Thread 1                              Thread 2
    ...
    p9_client_create()
    ...
    p9_fd_create()
    ...
    p9_conn_create()
    ...
    // start Thread 2
    INIT_WORK(&amp;m-&gt;rq, p9_read_work);
                                        p9_read_work()
    ...
    p9_client_rpc()
    ...
                                        ...
                                        p9_conn_cancel()
                                        ...
                                        spin_lock(&amp;m-&gt;req_lock);
    ...
    p9_fd_cancelled()
    ...
                                        ...
                                        spin_unlock(&amp;m-&gt;req_lock);
                                        // status rewrite
                                        p9_client_cb(m-&gt;client, req, REQ_STATUS_ERROR)
                                        // first remove
                                        list_del(&amp;req-&gt;req_list);
                                        ...

    spin_lock(&amp;m-&gt;req_lock)
    ...
    // second remove
    list_del(&amp;req-&gt;req_list);
    spin_unlock(&amp;m-&gt;req_lock)
  ...

Commit 74d6a5d56629 ("9p/trans_fd: Fix concurrency del of req_list in
p9_fd_cancelled/p9_read_work") fixes a concurrency issue in the 9p filesystem
client where the req_list could be deleted simultaneously by both
p9_read_work and p9_fd_cancelled functions, but for the case where req-&gt;status
equals REQ_STATUS_RCVD.

Update the check for req-&gt;status in p9_fd_cancelled to skip processing not
just received requests, but anything that is not SENT, as whatever
changed the state from SENT also removed the request from its list.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

[updated the check from status == RECV || status == ERROR to status != SENT]</Note>
    </Notes>
    <CVE>CVE-2025-40027</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

pinctrl: check the return value of pinmux_ops::get_function_name()

While the API contract in docs doesn't specify it explicitly, the
generic implementation of the get_function_name() callback from struct
pinmux_ops - pinmux_generic_get_function_name() - can fail and return
NULL. This is already checked in pinmux_check_ops() so add a similar
check in pinmux_func_name_to_selector() instead of passing the returned
pointer right down to strcmp() where the NULL can get dereferenced. This
is normal operation when adding new pinfunctions.</Note>
    </Notes>
    <CVE>CVE-2025-40030</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

KVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn't valid

Skip the WRMSR and HLT fastpaths in SVM's VM-Exit handler if the next RIP
isn't valid, e.g. because KVM is running with nrips=false.  SVM must
decode and emulate to skip the instruction if the CPU doesn't provide the
next RIP, and getting the instruction bytes to decode requires reading
guest memory.  Reading guest memory through the emulator can fault, i.e.
can sleep, which is disallowed since the fastpath handlers run with IRQs
disabled.

 BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:106
 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 32611, name: qemu
 preempt_count: 1, expected: 0
 INFO: lockdep is turned off.
 irq event stamp: 30580
 hardirqs last  enabled at (30579): [&lt;ffffffffc08b2527&gt;] vcpu_run+0x1787/0x1db0 [kvm]
 hardirqs last disabled at (30580): [&lt;ffffffffb4f62e32&gt;] __schedule+0x1e2/0xed0
 softirqs last  enabled at (30570): [&lt;ffffffffb4247a64&gt;] fpu_swap_kvm_fpstate+0x44/0x210
 softirqs last disabled at (30568): [&lt;ffffffffb4247a64&gt;] fpu_swap_kvm_fpstate+0x44/0x210
 CPU: 298 UID: 0 PID: 32611 Comm: qemu Tainted: G     U              6.16.0-smp--e6c618b51cfe-sleep #782 NONE
 Tainted: [U]=USER
 Hardware name: Google Astoria-Turin/astoria, BIOS 0.20241223.2-0 01/17/2025
 Call Trace:
  &lt;TASK&gt;
  dump_stack_lvl+0x7d/0xb0
  __might_resched+0x271/0x290
  __might_fault+0x28/0x80
  kvm_vcpu_read_guest_page+0x8d/0xc0 [kvm]
  kvm_fetch_guest_virt+0x92/0xc0 [kvm]
  __do_insn_fetch_bytes+0xf3/0x1e0 [kvm]
  x86_decode_insn+0xd1/0x1010 [kvm]
  x86_emulate_instruction+0x105/0x810 [kvm]
  __svm_skip_emulated_instruction+0xc4/0x140 [kvm_amd]
  handle_fastpath_invd+0xc4/0x1a0 [kvm]
  vcpu_run+0x11a1/0x1db0 [kvm]
  kvm_arch_vcpu_ioctl_run+0x5cc/0x730 [kvm]
  kvm_vcpu_ioctl+0x578/0x6a0 [kvm]
  __se_sys_ioctl+0x6d/0xb0
  do_syscall_64+0x8a/0x2c0
  entry_SYSCALL_64_after_hwframe+0x4b/0x53
 RIP: 0033:0x7f479d57a94b
  &lt;/TASK&gt;

Note, this is essentially a reapply of commit 5c30e8101e8d ("KVM: SVM:
Skip WRMSR fastpath on VM-Exit if next RIP isn't valid"), but with
different justification (KVM now grabs SRCU when skipping the instruction
for other reasons).</Note>
    </Notes>
    <CVE>CVE-2025-40038</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/ksm: fix flag-dropping behavior in ksm_madvise

syzkaller discovered the following crash: (kernel BUG)

[   44.607039] ------------[ cut here ]------------
[   44.607422] kernel BUG at mm/userfaultfd.c:2067!
[   44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI
[   44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none)
[   44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
[   44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460

&lt;snip other registers, drop unreliable trace&gt;

[   44.617726] Call Trace:
[   44.617926]  &lt;TASK&gt;
[   44.619284]  userfaultfd_release+0xef/0x1b0
[   44.620976]  __fput+0x3f9/0xb60
[   44.621240]  fput_close_sync+0x110/0x210
[   44.622222]  __x64_sys_close+0x8f/0x120
[   44.622530]  do_syscall_64+0x5b/0x2f0
[   44.622840]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[   44.623244] RIP: 0033:0x7f365bb3f227

Kernel panics because it detects UFFD inconsistency during
userfaultfd_release_all().  Specifically, a VMA which has a valid pointer
to vma-&gt;vm_userfaultfd_ctx, but no UFFD flags in vma-&gt;vm_flags.

The inconsistency is caused in ksm_madvise(): when user calls madvise()
with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode,
it accidentally clears all flags stored in the upper 32 bits of
vma-&gt;vm_flags.

Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and
int are 32-bit wide.  This setup causes the following mishap during the &amp;=
~VM_MERGEABLE assignment.

VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. 
After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then
promoted to unsigned long before the &amp; operation.  This promotion fills
upper 32 bits with leading 0s, as we're doing unsigned conversion (and
even for a signed conversion, this wouldn't help as the leading bit is 0).
&amp; operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffff
instead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears
the upper 32-bits of its value.

Fix it by changing `VM_MERGEABLE` constant to unsigned long, using the
BIT() macro.

Note: other VM_* flags are not affected: This only happens to the
VM_MERGEABLE flag, as the other VM_* flags are all constants of type int
and after ~ operation, they end up with leading 1 and are thus converted
to unsigned long with leading 1s.

Note 2:
After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this is
no longer a kernel BUG, but a WARNING at the same place:

[   45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067

but the root-cause (flag-drop) remains the same.

[akpm@linux-foundation.org: rust bindgen wasn't able to handle BIT(), from Miguel]</Note>
    </Notes>
    <CVE>CVE-2025-40040</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

uio_hv_generic: Let userspace take care of interrupt mask

Remove the logic to set interrupt mask by default in uio_hv_generic
driver as the interrupt mask value is supposed to be controlled
completely by the user space. If the mask bit gets changed
by the driver, concurrently with user mode operating on the ring,
the mask bit may be set when it is supposed to be clear, and the
user-mode driver will miss an interrupt which will cause a hang.

For eg- when the driver sets inbound ring buffer interrupt mask to 1,
the host does not interrupt the guest on the UIO VMBus channel.
However, setting the mask does not prevent the host from putting a
message in the inbound ring buffer.  So let's assume that happens,
the host puts a message into the ring buffer but does not interrupt.

Subsequently, the user space code in the guest sets the inbound ring
buffer interrupt mask to 0, saying “Hey, I'm ready for interrupts”.
User space code then calls pread() to wait for an interrupt.
Then one of two things happens:

* The host never sends another message. So the pread() waits forever.
* The host does send another message. But because there's already a
  message in the ring buffer, it doesn't generate an interrupt.
  This is the correct behavior, because the host should only send an
  interrupt when the inbound ring buffer transitions from empty to
  not-empty. Adding an additional message to a ring buffer that is not
  empty is not supposed to generate an interrupt on the guest.
  Since the guest is waiting in pread() and not removing messages from
  the ring buffer, the pread() waits forever.

This could be easily reproduced in hv_fcopy_uio_daemon if we delay
setting interrupt mask to 0.

Similarly if hv_uio_channel_cb() sets the interrupt_mask to 1,
there's a race condition. Once user space empties the inbound ring
buffer, but before user space sets interrupt_mask to 0, the host could
put another message in the ring buffer but it wouldn't interrupt.
Then the next pread() would hang.

Fix these by removing all instances where interrupt_mask is changed,
while keeping the one in set_event() unchanged to enable userspace
control the interrupt mask by writing 0/1 to /dev/uioX.</Note>
    </Notes>
    <CVE>CVE-2025-40048</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

ocfs2: fix double free in user_cluster_connect()

user_cluster_disconnect() frees "conn-&gt;cc_private" which is "lc" but then
the error handling frees "lc" a second time.  Set "lc" to NULL on this
path to avoid a double free.</Note>
    </Notes>
    <CVE>CVE-2025-40055</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix incorrect handling for return value of devm_kzalloc

The return value of devm_kzalloc could be an null pointer,
use "!desc.pdata" to fix incorrect handling return value
of devm_kzalloc.</Note>
    </Notes>
    <CVE>CVE-2025-40059</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

smc: Fix use-after-free in __pnet_find_base_ndev().

syzbot reported use-after-free of net_device in __pnet_find_base_ndev(),
which was called during connect(). [0]

smc_pnet_find_ism_resource() fetches sk_dst_get(sk)-&gt;dev and passes
down to pnet_find_base_ndev(), where RTNL is held.  Then, UAF happened
at __pnet_find_base_ndev() when the dev is first used.

This means dev had already been freed before acquiring RTNL in
pnet_find_base_ndev().

While dev is going away, dst-&gt;dev could be swapped with blackhole_netdev,
and the dev's refcnt by dst will be released.

We must hold dev's refcnt before calling smc_pnet_find_ism_resource().

Also, smc_pnet_find_roce_resource() has the same problem.

Let's use __sk_dst_get() and dst_dev_rcu() in the two functions.

[0]:
BUG: KASAN: use-after-free in __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926
Read of size 1 at addr ffff888036bac33a by task syz.0.3632/18609

CPU: 1 UID: 0 PID: 18609 Comm: syz.0.3632 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
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
 __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926
 pnet_find_base_ndev net/smc/smc_pnet.c:946 [inline]
 smc_pnet_find_ism_by_pnetid net/smc/smc_pnet.c:1103 [inline]
 smc_pnet_find_ism_resource+0xef/0x390 net/smc/smc_pnet.c:1154
 smc_find_ism_device net/smc/af_smc.c:1030 [inline]
 smc_find_proposal_devices net/smc/af_smc.c:1115 [inline]
 __smc_connect+0x372/0x1890 net/smc/af_smc.c:1545
 smc_connect+0x877/0xd90 net/smc/af_smc.c:1715
 __sys_connect_file net/socket.c:2086 [inline]
 __sys_connect+0x313/0x440 net/socket.c:2105
 __do_sys_connect net/socket.c:2111 [inline]
 __se_sys_connect net/socket.c:2108 [inline]
 __x64_sys_connect+0x7a/0x90 net/socket.c:2108
 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:0x7f47cbf8eba9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f47ccdb1038 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 00007f47cc1d5fa0 RCX: 00007f47cbf8eba9
RDX: 0000000000000010 RSI: 0000200000000280 RDI: 000000000000000b
RBP: 00007f47cc011e19 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f47cc1d6038 R14: 00007f47cc1d5fa0 R15: 00007ffc512f8aa8
 &lt;/TASK&gt;

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888036bacd00 pfn:0x36bac
flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000000000 ffffea0001243d08 ffff8880b863fdc0 0000000000000000
raw: ffff888036bacd00 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as freed
page last allocated via order 2, migratetype Unmovable, gfp_mask 0x446dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOWARN|__GFP_RETRY_MAYFAIL|__GFP_COMP), pid 16741, tgid 16741 (syz-executor), ts 343313197788, free_ts 380670750466
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851
 prep_new_page mm/page_alloc.c:1859 [inline]
 get_page_from_freelist+0x21e4/0x22c0 mm/page_alloc.c:3858
 __alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5148
 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2416
 ___kmalloc_large_node+0x5f/0x1b0 mm/slub.c:4317
 __kmalloc_large_node_noprof+0x18/0x90 mm/slub.c:4348
 __do_kmalloc_node mm/slub.c:4364 [inline]
 __kvmalloc_node
---truncated---</Note>
    </Notes>
    <CVE>CVE-2025-40064</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pps: fix warning in pps_register_cdev when register device fail

Similar to previous commit 2a934fdb01db ("media: v4l2-dev: fix error
handling in __video_register_device()"), the release hook should be set
before device_register(). Otherwise, when device_register() return error
and put_device() try to callback the release function, the below warning
may happen.

  ------------[ cut here ]------------
  WARNING: CPU: 1 PID: 4760 at drivers/base/core.c:2567 device_release+0x1bd/0x240 drivers/base/core.c:2567
  Modules linked in:
  CPU: 1 UID: 0 PID: 4760 Comm: syz.4.914 Not tainted 6.17.0-rc3+ #1 NONE
  RIP: 0010:device_release+0x1bd/0x240 drivers/base/core.c:2567
  Call Trace:
   &lt;TASK&gt;
   kobject_cleanup+0x136/0x410 lib/kobject.c:689
   kobject_release lib/kobject.c:720 [inline]
   kref_put include/linux/kref.h:65 [inline]
   kobject_put+0xe9/0x130 lib/kobject.c:737
   put_device+0x24/0x30 drivers/base/core.c:3797
   pps_register_cdev+0x2da/0x370 drivers/pps/pps.c:402
   pps_register_source+0x2f6/0x480 drivers/pps/kapi.c:108
   pps_tty_open+0x190/0x310 drivers/pps/clients/pps-ldisc.c:57
   tty_ldisc_open+0xa7/0x120 drivers/tty/tty_ldisc.c:432
   tty_set_ldisc+0x333/0x780 drivers/tty/tty_ldisc.c:563
   tiocsetd drivers/tty/tty_io.c:2429 [inline]
   tty_ioctl+0x5d1/0x1700 drivers/tty/tty_io.c:2728
   vfs_ioctl fs/ioctl.c:51 [inline]
   __do_sys_ioctl fs/ioctl.c:598 [inline]
   __se_sys_ioctl fs/ioctl.c:584 [inline]
   __x64_sys_ioctl+0x194/0x210 fs/ioctl.c:584
   do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
   do_syscall_64+0x5f/0x2a0 arch/x86/entry/syscall_64.c:94
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
   &lt;/TASK&gt;

Before commit c79a39dc8d06 ("pps: Fix a use-after-free"),
pps_register_cdev() call device_create() to create pps-&gt;dev, which will
init dev-&gt;release to device_create_release(). Now the comment is outdated,
just remove it.

Thanks for the reminder from Calvin Owens, 'kfree_pps' should be removed
in pps_register_source() to avoid a double free in the failure case.</Note>
    </Notes>
    <CVE>CVE-2025-40070</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

ipv4: start using dst_dev_rcu()

Change icmpv4_xrlim_allow(), ip_defrag() to prevent possible UAF.

Change ipmr_prepare_xmit(), ipmr_queue_fwd_xmit(), ip_mr_output(),
ipv4_neigh_lookup() to use lockdep enabled dst_dev_rcu().</Note>
    </Notes>
    <CVE>CVE-2025-40074</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_metrics: use dst_dev_net_rcu()

Replace three dst_dev() with a lockdep enabled helper.</Note>
    </Notes>
    <CVE>CVE-2025-40075</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

net/sched: sch_qfq: Fix null-deref in agg_dequeue

To prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c)
when cl-&gt;qdisc-&gt;ops-&gt;peek(cl-&gt;qdisc) returns NULL, we check the return
value before using it, similar to the existing approach in sch_hfsc.c.

To avoid code duplication, the following changes are made:

1. Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a static
inline function.

2. Moved qdisc_peek_len from net/sched/sch_hfsc.c to
include/net/pkt_sched.h so that sch_qfq can reuse it.

3. Applied qdisc_peek_len in agg_dequeue to avoid crashing.</Note>
    </Notes>
    <CVE>CVE-2025-40083</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_get_acpi_mute_state()

Return value of a function acpi_evaluate_dsm() is dereferenced  without
checking for NULL, but it is usually checked for this function.

acpi_evaluate_dsm() may return NULL, when acpi_evaluate_object() returns
acpi_status other than ACPI_SUCCESS, so add a check to prevent the crach.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2025-40098</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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">In the Linux kernel, the following vulnerability has been resolved:

vfs: Don't leak disconnected dentries on umount

When user calls open_by_handle_at() on some inode that is not cached, we
will create disconnected dentry for it. If such dentry is a directory,
exportfs_decode_fh_raw() will then try to connect this dentry to the
dentry tree through reconnect_path(). It may happen for various reasons
(such as corrupted fs or race with rename) that the call to
lookup_one_unlocked() in reconnect_one() will fail to find the dentry we
are trying to reconnect and instead create a new dentry under the
parent. Now this dentry will not be marked as disconnected although the
parent still may well be disconnected (at least in case this
inconsistency happened because the fs is corrupted and .. doesn't point
to the real parent directory). This creates inconsistency in
disconnected flags but AFAICS it was mostly harmless. At least until
commit f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon")
which removed adding of most disconnected dentries to sb-&gt;s_anon list.
Thus after this commit cleanup of disconnected dentries implicitely
relies on the fact that dput() will immediately reclaim such dentries.
However when some leaf dentry isn't marked as disconnected, as in the
scenario described above, the reclaim doesn't happen and the dentries
are "leaked". Memory reclaim can eventually reclaim them but otherwise
they stay in memory and if umount comes first, we hit infamous "Busy
inodes after unmount" bug. Make sure all dentries created under a
disconnected parent are marked as disconnected as well.</Note>
    </Notes>
    <CVE>CVE-2025-40105</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:

can: hi311x: fix null pointer dereference when resuming from sleep before interface was enabled

This issue is similar to the vulnerability in the `mcp251x` driver,
which was fixed in commit 03c427147b2d ("can: mcp251x: fix resume from
sleep before interface was brought up").

In the `hi311x` driver, when the device resumes from sleep, the driver
schedules `priv-&gt;restart_work`. However, if the network interface was
not previously enabled, the `priv-&gt;wq` (workqueue) is not allocated and
initialized, leading to a null pointer dereference.

To fix this, we move the allocation and initialization of the workqueue
from the `hi3110_open` function to the `hi3110_can_probe` function.
This ensures that the workqueue is properly initialized before it is
used during device resume. And added logic to destroy the workqueue
in the error handling paths of `hi3110_can_probe` and in the
`hi3110_can_remove` function to prevent resource leaks.</Note>
    </Notes>
    <CVE>CVE-2025-40107</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: rng - Ensure set_ent is always present

Ensure that set_ent is always set since only drbg provides it.</Note>
    </Notes>
    <CVE>CVE-2025-40109</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/vmwgfx: Fix a null-ptr access in the cursor snooper

Check that the resource which is converted to a surface exists before
trying to use the cursor snooper on it.

vmw_cmd_res_check allows explicit invalid (SVGA3D_INVALID_ID) identifiers
because some svga commands accept SVGA3D_INVALID_ID to mean "no surface",
unfortunately functions that accept the actual surfaces as objects might
(and in case of the cursor snooper, do not) be able to handle null
objects. Make sure that we validate not only the identifier (via the
vmw_cmd_res_check) but also check that the actual resource exists before
trying to do something with it.

Fixes unchecked null-ptr reference in the snooping code.</Note>
    </Notes>
    <CVE>CVE-2025-40110</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/vmwgfx: Fix Use-after-free in validation

Nodes stored in the validation duplicates hashtable come from an arena
allocator that is cleared at the end of vmw_execbuf_process. All nodes
are expected to be cleared in vmw_validation_drop_ht but this node escaped
because its resource was destroyed prematurely.</Note>
    </Notes>
    <CVE>CVE-2025-40111</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mpt3sas: Fix crash in transport port remove by using ioc_info()

During mpt3sas_transport_port_remove(), messages were logged with
dev_printk() against &amp;mpt3sas_port-&gt;port-&gt;dev. At this point the SAS
transport device may already be partially unregistered or freed, leading
to a crash when accessing its struct device.

Using ioc_info(), which logs via the PCI device (ioc-&gt;pdev-&gt;dev),
guaranteed to remain valid until driver removal.

[83428.295776] Oops: general protection fault, probably for non-canonical address 0x6f702f323a33312d: 0000 [#1] SMP NOPTI
[83428.295785] CPU: 145 UID: 0 PID: 113296 Comm: rmmod Kdump: loaded Tainted: G           OE       6.16.0-rc1+ #1 PREEMPT(voluntary)
[83428.295792] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
[83428.295795] Hardware name: Dell Inc. Precision 7875 Tower/, BIOS 89.1.67 02/23/2024
[83428.295799] RIP: 0010:__dev_printk+0x1f/0x70
[83428.295805] Code: 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 49 89 d1 48 85 f6 74 52 4c 8b 46 50 4d 85 c0 74 1f 48 8b 46 68 48 85 c0 74 22 &lt;48&gt; 8b 08 0f b6 7f 01 48 c7 c2 db e8 42 ad 83 ef 30 e9 7b f8 ff ff
[83428.295813] RSP: 0018:ff85aeafc3137bb0 EFLAGS: 00010206
[83428.295817] RAX: 6f702f323a33312d RBX: ff4290ee81292860 RCX: 5000cca25103be32
[83428.295820] RDX: ff85aeafc3137bb8 RSI: ff4290eeb1966c00 RDI: ffffffffc1560845
[83428.295823] RBP: ff85aeafc3137c18 R08: 74726f702f303a33 R09: ff85aeafc3137bb8
[83428.295826] R10: ff85aeafc3137b18 R11: ff4290f5bd60fe68 R12: ff4290ee81290000
[83428.295830] R13: ff4290ee6e345de0 R14: ff4290ee81290000 R15: ff4290ee6e345e30
[83428.295833] FS:  00007fd9472a6740(0000) GS:ff4290f5ce96b000(0000) knlGS:0000000000000000
[83428.295837] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[83428.295840] CR2: 00007f242b4db238 CR3: 00000002372b8006 CR4: 0000000000771ef0
[83428.295844] PKRU: 55555554
[83428.295846] Call Trace:
[83428.295848]  &lt;TASK&gt;
[83428.295850]  _dev_printk+0x5c/0x80
[83428.295857]  ? srso_alias_return_thunk+0x5/0xfbef5
[83428.295863]  mpt3sas_transport_port_remove+0x1c7/0x420 [mpt3sas]
[83428.295882]  _scsih_remove_device+0x21b/0x280 [mpt3sas]
[83428.295894]  ? _scsih_expander_node_remove+0x108/0x140 [mpt3sas]
[83428.295906]  ? srso_alias_return_thunk+0x5/0xfbef5
[83428.295910]  mpt3sas_device_remove_by_sas_address.part.0+0x8f/0x110 [mpt3sas]
[83428.295921]  _scsih_expander_node_remove+0x129/0x140 [mpt3sas]
[83428.295933]  _scsih_expander_node_remove+0x6a/0x140 [mpt3sas]
[83428.295944]  scsih_remove+0x3f0/0x4a0 [mpt3sas]
[83428.295957]  pci_device_remove+0x3b/0xb0
[83428.295962]  device_release_driver_internal+0x193/0x200
[83428.295968]  driver_detach+0x44/0x90
[83428.295971]  bus_remove_driver+0x69/0xf0
[83428.295975]  pci_unregister_driver+0x2a/0xb0
[83428.295979]  _mpt3sas_exit+0x1f/0x300 [mpt3sas]
[83428.295991]  __do_sys_delete_module.constprop.0+0x174/0x310
[83428.295997]  ? srso_alias_return_thunk+0x5/0xfbef5
[83428.296000]  ? __x64_sys_getdents64+0x9a/0x110
[83428.296005]  ? srso_alias_return_thunk+0x5/0xfbef5
[83428.296009]  ? syscall_trace_enter+0xf6/0x1b0
[83428.296014]  do_syscall_64+0x7b/0x2c0
[83428.296019]  ? srso_alias_return_thunk+0x5/0xfbef5
[83428.296023]  entry_SYSCALL_64_after_hwframe+0x76/0x7e</Note>
    </Notes>
    <CVE>CVE-2025-40115</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: host: max3421-hcd: Fix error pointer dereference in probe cleanup

The kthread_run() function returns error pointers so the
max3421_hcd-&gt;spi_thread pointer can be either error pointers or NULL.
Check for both before dereferencing it.</Note>
    </Notes>
    <CVE>CVE-2025-40116</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: pm80xx: Fix array-index-out-of-of-bounds on rmmod

Since commit f7b705c238d1 ("scsi: pm80xx: Set phy_attached to zero when
device is gone") UBSAN reports:

  UBSAN: array-index-out-of-bounds in drivers/scsi/pm8001/pm8001_sas.c:786:17
  index 28 is out of range for type 'pm8001_phy [16]'

on rmmod when using an expander.

For a direct attached device, attached_phy contains the local phy id.
For a device behind an expander, attached_phy contains the remote phy
id, not the local phy id.

I.e. while pm8001_ha will have pm8001_ha-&gt;chip-&gt;n_phy local phys, for a
device behind an expander, attached_phy can be much larger than
pm8001_ha-&gt;chip-&gt;n_phy (depending on the amount of phys of the
expander).

E.g. on my system pm8001_ha has 8 phys with phy ids 0-7.  One of the
ports has an expander connected.  The expander has 31 phys with phy ids
0-30.

The pm8001_ha-&gt;phy array only contains the phys of the HBA.  It does not
contain the phys of the expander.  Thus, it is wrong to use attached_phy
to index the pm8001_ha-&gt;phy array for a device behind an expander.

Thus, we can only clear phy_attached for devices that are directly
attached.</Note>
    </Notes>
    <CVE>CVE-2025-40118</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlock

Prevent USB runtime PM (autosuspend) for AX88772* in bind.

usbnet enables runtime PM (autosuspend) by default, so disabling it via
the usb_driver flag is ineffective. On AX88772B, autosuspend shows no
measurable power saving with current driver (no link partner, admin
up/down). The ~0.453 W -&gt; ~0.248 W drop on v6.1 comes from phylib powering
the PHY off on admin-down, not from USB autosuspend.

The real hazard is that with runtime PM enabled, ndo_open() (under RTNL)
may synchronously trigger autoresume (usb_autopm_get_interface()) into
asix_resume() while the USB PM lock is held. Resume paths then invoke
phylink/phylib and MDIO, which also expect RTNL, leading to possible
deadlocks or PM lock vs MDIO wake issues.

To avoid this, keep the device runtime-PM active by taking a usage
reference in ax88772_bind() and dropping it in unbind(). A non-zero PM
usage count blocks runtime suspend regardless of userspace policy
(.../power/control - pm_runtime_allow/forbid), making this approach
robust against sysfs overrides.

Holding a runtime-PM usage ref does not affect system-wide suspend;
system sleep/resume callbacks continue to run as before.</Note>
    </Notes>
    <CVE>CVE-2025-40120</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Intel: bytcr_rt5651: Fix invalid quirk input mapping

When an invalid value is passed via quirk option, currently
bytcr_rt5640 driver just ignores and leaves as is, which may lead to
unepxected results like OOB access.

This patch adds the sanity check and corrects the input mapping to the
certain default value if an invalid value is passed.</Note>
    </Notes>
    <CVE>CVE-2025-40121</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hwrng: ks-sa - fix division by zero in ks_sa_rng_init

Fix division by zero in ks_sa_rng_init caused by missing clock
pointer initialization. The clk_get_rate() call is performed on
an uninitialized clk pointer, resulting in division by zero when
calculating delay values.

Add clock initialization code before using the clock.


 drivers/char/hw_random/ks-sa-rng.c | 7 +++++++
 1 file changed, 7 insertions(+)</Note>
    </Notes>
    <CVE>CVE-2025-40127</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sunrpc: fix null pointer dereference on zero-length checksum

In xdr_stream_decode_opaque_auth(), zero-length checksum.len causes
checksum.data to be set to NULL. This triggers a NPD when accessing
checksum.data in gss_krb5_verify_mic_v2(). This patch ensures that
the value of checksum.len is not less than XDR_UNIT.</Note>
    </Notes>
    <CVE>CVE-2025-40129</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:

smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().

smc_clc_prfx_set() is called during connect() and not under RCU
nor RTNL.

Using sk_dst_get(sk)-&gt;dev could trigger UAF.

Let's use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock()
after kernel_getsockname().

Note that the returned value of smc_clc_prfx_set() is not used
in the caller.

While at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu()
not to touch dst there.</Note>
    </Notes>
    <CVE>CVE-2025-40139</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:

net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast

syzbot reported WARNING in rtl8150_start_xmit/usb_submit_urb.
This is the sequence of events that leads to the warning:

rtl8150_start_xmit() {
	netif_stop_queue();
	usb_submit_urb(dev-&gt;tx_urb);
}

rtl8150_set_multicast() {
	netif_stop_queue();
	netif_wake_queue();		&lt;-- wakes up TX queue before URB is done
}

rtl8150_start_xmit() {
	netif_stop_queue();
	usb_submit_urb(dev-&gt;tx_urb);	&lt;-- double submission
}

rtl8150_set_multicast being the ndo_set_rx_mode callback should not be
calling netif_stop_queue and notif_start_queue as these handle
TX queue synchronization.

The net core function dev_set_rx_mode handles the synchronization
for rtl8150_set_multicast making it safe to remove these locks.</Note>
    </Notes>
    <CVE>CVE-2025-40140</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:

Bluetooth: ISO: Fix possible UAF on iso_conn_free

This attempt to fix similar issue to sco_conn_free where if the
conn-&gt;sk is not set to NULL may lead to UAF on iso_conn_free.</Note>
    </Notes>
    <CVE>CVE-2025-40141</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock().

get_netdev_for_sock() is called during setsockopt(),
so not under RCU.

Using sk_dst_get(sk)-&gt;dev could trigger UAF.

Let's use __sk_dst_get() and dst_dev_rcu().

Note that the only -&gt;ndo_sk_get_lower_dev() user is
bond_sk_get_lower_dev(), which uses RCU.</Note>
    </Notes>
    <CVE>CVE-2025-40149</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Intel: bytcr_rt5640: Fix invalid quirk input mapping

When an invalid value is passed via quirk option, currently
bytcr_rt5640 driver only shows an error message but leaves as is.
This may lead to unepxected results like OOB access.

This patch corrects the input mapping to the certain default value if
an invalid value is passed.</Note>
    </Notes>
    <CVE>CVE-2025-40154</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

PM / devfreq: mtk-cci: Fix potential error pointer dereference in probe()

The drv-&gt;sram_reg pointer could be set to ERR_PTR(-EPROBE_DEFER) which
would lead to a error pointer dereference.  Use IS_ERR_OR_NULL() to check
that the pointer is valid.</Note>
    </Notes>
    <CVE>CVE-2025-40156</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

EDAC/i10nm: Skip DIMM enumeration on a disabled memory controller

When loading the i10nm_edac driver on some Intel Granite Rapids servers,
a call trace may appear as follows:

  UBSAN: shift-out-of-bounds in drivers/edac/skx_common.c:453:16
  shift exponent -66 is negative
  ...
  __ubsan_handle_shift_out_of_bounds+0x1e3/0x390
  skx_get_dimm_info.cold+0x47/0xd40 [skx_edac_common]
  i10nm_get_dimm_config+0x23e/0x390 [i10nm_edac]
  skx_register_mci+0x159/0x220 [skx_edac_common]
  i10nm_init+0xcb0/0x1ff0 [i10nm_edac]
  ...

This occurs because some BIOS may disable a memory controller if there
aren't any memory DIMMs populated on this memory controller. The DIMMMTR
register of this disabled memory controller contains the invalid value
~0, resulting in the call trace above.

Fix this call trace by skipping DIMM enumeration on a disabled memory
controller.</Note>
    </Notes>
    <CVE>CVE-2025-40157</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Harden userspace-supplied xdp_desc validation

Turned out certain clearly invalid values passed in xdp_desc from
userspace can pass xp_{,un}aligned_validate_desc() and then lead
to UBs or just invalid frames to be queued for xmit.

desc-&gt;len close to ``U32_MAX`` with a non-zero pool-&gt;tx_metadata_len
can cause positive integer overflow and wraparound, the same way low
enough desc-&gt;addr with a non-zero pool-&gt;tx_metadata_len can cause
negative integer overflow. Both scenarios can then pass the
validation successfully.
This doesn't happen with valid XSk applications, but can be used
to perform attacks.

Always promote desc-&gt;len to ``u64`` first to exclude positive
overflows of it. Use explicit check_{add,sub}_overflow() when
validating desc-&gt;addr (which is ``u64`` already).

bloat-o-meter reports a little growth of the code size:

add/remove: 0/0 grow/shrink: 2/1 up/down: 60/-16 (44)
Function                                     old     new   delta
xskq_cons_peek_desc                          299     330     +31
xsk_tx_peek_release_desc_batch               973    1002     +29
xsk_generic_xmit                            3148    3132     -16

but hopefully this doesn't hurt the performance much.</Note>
    </Notes>
    <CVE>CVE-2025-40159</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:

usbnet: Fix using smp_processor_id() in preemptible code warnings

Syzbot reported the following warning:

BUG: using smp_processor_id() in preemptible [00000000] code: dhcpcd/2879
caller is usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331
CPU: 1 UID: 0 PID: 2879 Comm: dhcpcd Not tainted 6.15.0-rc4-syzkaller-00098-g615dca38c2ea #0 PREEMPT(voluntary)
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120
 check_preemption_disabled+0xd0/0xe0 lib/smp_processor_id.c:49
 usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331
 usbnet_resume_rx+0x4b/0x170 drivers/net/usb/usbnet.c:708
 usbnet_change_mtu+0x1be/0x220 drivers/net/usb/usbnet.c:417
 __dev_set_mtu net/core/dev.c:9443 [inline]
 netif_set_mtu_ext+0x369/0x5c0 net/core/dev.c:9496
 netif_set_mtu+0xb0/0x160 net/core/dev.c:9520
 dev_set_mtu+0xae/0x170 net/core/dev_api.c:247
 dev_ifsioc+0xa31/0x18d0 net/core/dev_ioctl.c:572
 dev_ioctl+0x223/0x10e0 net/core/dev_ioctl.c:821
 sock_do_ioctl+0x19d/0x280 net/socket.c:1204
 sock_ioctl+0x42f/0x6a0 net/socket.c:1311
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:906 [inline]
 __se_sys_ioctl fs/ioctl.c:892 [inline]
 __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

For historical and portability reasons, the netif_rx() is usually
run in the softirq or interrupt context, this commit therefore add
local_bh_disable/enable() protection in the usbnet_resume_rx().</Note>
    </Notes>
    <CVE>CVE-2025-40164</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

smc: Use __sk_dst_get() and dst_dev_rcu() in smc_clc_prfx_match().

smc_clc_prfx_match() is called from smc_listen_work() and
not under RCU nor RTNL.

Using sk_dst_get(sk)-&gt;dev could trigger UAF.

Let's use __sk_dst_get() and dst_dev_rcu().

Note that the returned value of smc_clc_prfx_match() is not
used in the caller.</Note>
    </Notes>
    <CVE>CVE-2025-40168</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 negative offsets for ALU ops

When verifying BPF programs, the check_alu_op() function validates
instructions with ALU operations. The 'offset' field in these
instructions is a signed 16-bit integer.

The existing check 'insn-&gt;off &gt; 1' was intended to ensure the offset is
either 0, or 1 for BPF_MOD/BPF_DIV. However, because 'insn-&gt;off' is
signed, this check incorrectly accepts all negative values (e.g., -1).

This commit tightens the validation by changing the condition to
'(insn-&gt;off != 0 &amp;&amp; insn-&gt;off != 1)'. This ensures that any value
other than the explicitly permitted 0 and 1 is rejected, hardening the
verifier against malformed BPF programs.</Note>
    </Notes>
    <CVE>CVE-2025-40169</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nvmet-fc: move lsop put work to nvmet_fc_ls_req_op

It's possible for more than one async command to be in flight from
__nvmet_fc_send_ls_req. For each command, a tgtport reference is taken.

In the current code, only one put work item is queued at a time, which
results in a leaked reference.

To fix this, move the work item to the nvmet_fc_ls_req_op struct, which
already tracks all resources related to the command.</Note>
    </Notes>
    <CVE>CVE-2025-40171</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Treat remaining == 0 as error in find_and_map_user_pages()

Currently, if find_and_map_user_pages() takes a DMA xfer request from the
user with a length field set to 0, or in a rare case, the host receives
QAIC_TRANS_DMA_XFER_CONT from the device where resources-&gt;xferred_dma_size
is equal to the requested transaction size, the function will return 0
before allocating an sgt or setting the fields of the dma_xfer struct.
In that case, encode_addr_size_pairs() will try to access the sgt which
will lead to a general protection fault.

Return an EINVAL in case the user provides a zero-sized ALP, or the device
requests continuation after all of the bytes have been transferred.</Note>
    </Notes>
    <CVE>CVE-2025-40172</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/ip6_tunnel: Prevent perpetual tunnel growth

Similarly to ipv4 tunnel, ipv6 version updates dev-&gt;needed_headroom, too.
While ipv4 tunnel headroom adjustment growth was limited in
commit 5ae1e9922bbd ("net: ip_tunnel: prevent perpetual headroom growth"),
ipv6 tunnel yet increases the headroom without any ceiling.

Reflect ipv4 tunnel headroom adjustment limit on ipv6 version.

Credits to Francesco Ruggeri, who was originally debugging this issue
and wrote local Arista-specific patch and a reproducer.</Note>
    </Notes>
    <CVE>CVE-2025-40173</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: wait for pending async decryptions if tls_strp_msg_hold fails

Async decryption calls tls_strp_msg_hold to create a clone of the
input skb to hold references to the memory it uses. If we fail to
allocate that clone, proceeding with async decryption can lead to
various issues (UAF on the skb, writing into userspace memory after
the recv() call has returned).

In this case, wait for all pending decryption requests.</Note>
    </Notes>
    <CVE>CVE-2025-40176</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:

mailbox: zynqmp-ipi: Fix out-of-bounds access in mailbox cleanup loop

The cleanup loop was starting at the wrong array index, causing
out-of-bounds access.
Start the loop at the correct index for zero-indexed arrays to prevent
accessing memory beyond the allocated array bounds.</Note>
    </Notes>
    <CVE>CVE-2025-40180</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix metadata_dst leak __bpf_redirect_neigh_v{4,6}

Cilium has a BPF egress gateway feature which forces outgoing K8s Pod
traffic to pass through dedicated egress gateways which then SNAT the
traffic in order to interact with stable IPs outside the cluster.

The traffic is directed to the gateway via vxlan tunnel in collect md
mode. A recent BPF change utilized the bpf_redirect_neigh() helper to
forward packets after the arrival and decap on vxlan, which turned out
over time that the kmalloc-256 slab usage in kernel was ever-increasing.

The issue was that vxlan allocates the metadata_dst object and attaches
it through a fake dst entry to the skb. The latter was never released
though given bpf_redirect_neigh() was merely setting the new dst entry
via skb_dst_set() without dropping an existing one first.</Note>
    </Notes>
    <CVE>CVE-2025-40183</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Don't call reqsk_fastopen_remove() in tcp_conn_request().

syzbot reported the splat below in tcp_conn_request(). [0]

If a listener is close()d while a TFO socket is being processed in
tcp_conn_request(), inet_csk_reqsk_queue_add() does not set reqsk-&gt;sk
and calls inet_child_forget(), which calls tcp_disconnect() for the
TFO socket.

After the cited commit, tcp_disconnect() calls reqsk_fastopen_remove(),
where reqsk_put() is called due to !reqsk-&gt;sk.

Then, reqsk_fastopen_remove() in tcp_conn_request() decrements the
last req-&gt;rsk_refcnt and frees reqsk, and __reqsk_free() at the
drop_and_free label causes the refcount underflow for the listener
and double-free of the reqsk.

Let's remove reqsk_fastopen_remove() in tcp_conn_request().

Note that other callers make sure tp-&gt;fastopen_rsk is not NULL.

[0]:
refcount_t: underflow; use-after-free.
WARNING: CPU: 12 PID: 5563 at lib/refcount.c:28 refcount_warn_saturate (lib/refcount.c:28)
Modules linked in:
CPU: 12 UID: 0 PID: 5563 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025
RIP: 0010:refcount_warn_saturate (lib/refcount.c:28)
Code: ab e8 8e b4 98 ff 0f 0b c3 cc cc cc cc cc 80 3d a4 e4 d6 01 00 75 9c c6 05 9b e4 d6 01 01 48 c7 c7 e8 df fb ab e8 6a b4 98 ff &lt;0f&gt; 0b e9 03 5b 76 00 cc 80 3d 7d e4 d6 01 00 0f 85 74 ff ff ff c6
RSP: 0018:ffffa79fc0304a98 EFLAGS: 00010246
RAX: d83af4db1c6b3900 RBX: ffff9f65c7a69020 RCX: d83af4db1c6b3900
RDX: 0000000000000000 RSI: 00000000ffff7fff RDI: ffffffffac78a280
RBP: 000000009d781b60 R08: 0000000000007fff R09: ffffffffac6ca280
R10: 0000000000017ffd R11: 0000000000000004 R12: ffff9f65c7b4f100
R13: ffff9f65c7d23c00 R14: ffff9f65c7d26000 R15: ffff9f65c7a64ef8
FS:  00007f9f962176c0(0000) GS:ffff9f65fcf00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000200000000180 CR3: 000000000dbbe006 CR4: 0000000000372ef0
Call Trace:
 &lt;IRQ&gt;
 tcp_conn_request (./include/linux/refcount.h:400 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 ./include/net/sock.h:1965 ./include/net/request_sock.h:131 net/ipv4/tcp_input.c:7301)
 tcp_rcv_state_process (net/ipv4/tcp_input.c:6708)
 tcp_v6_do_rcv (net/ipv6/tcp_ipv6.c:1670)
 tcp_v6_rcv (net/ipv6/tcp_ipv6.c:1906)
 ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:438)
 ip6_input (net/ipv6/ip6_input.c:500)
 ipv6_rcv (net/ipv6/ip6_input.c:311)
 __netif_receive_skb (net/core/dev.c:6104)
 process_backlog (net/core/dev.c:6456)
 __napi_poll (net/core/dev.c:7506)
 net_rx_action (net/core/dev.c:7569 net/core/dev.c:7696)
 handle_softirqs (kernel/softirq.c:579)
 do_softirq (kernel/softirq.c:480)
 &lt;/IRQ&gt;</Note>
    </Notes>
    <CVE>CVE-2025-40186</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:

pwm: berlin: Fix wrong register in suspend/resume

The 'enable' register should be BERLIN_PWM_EN rather than
BERLIN_PWM_ENABLE, otherwise, the driver accesses wrong address, there
will be cpu exception then kernel panic during suspend/resume.</Note>
    </Notes>
    <CVE>CVE-2025-40188</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: intel_pstate: Fix object lifecycle issue in update_qos_request()

The cpufreq_cpu_put() call in update_qos_request() takes place too early
because the latter subsequently calls freq_qos_update_request() that
indirectly accesses the policy object in question through the QoS request
object passed to it.

Fortunately, update_qos_request() is called under intel_pstate_driver_lock,
so this issue does not matter for changing the intel_pstate operation
mode, but it theoretically can cause a crash to occur on CPU device hot
removal (which currently can only happen in virt, but it is formally
supported nevertheless).

Address this issue by modifying update_qos_request() to drop the
reference to the policy later.</Note>
    </Notes>
    <CVE>CVE-2025-40194</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: avoid potential buffer over-read in parse_apply_sb_mount_options()

Unlike other strings in the ext4 superblock, we rely on tune2fs to
make sure s_mount_opts is NUL terminated.  Harden
parse_apply_sb_mount_options() by treating s_mount_opts as a potential
__nonstring.</Note>
    </Notes>
    <CVE>CVE-2025-40198</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: reject negative file sizes in squashfs_read_inode()

Syskaller reports a "WARNING in ovl_copy_up_file" in overlayfs.

This warning is ultimately caused because the underlying Squashfs file
system returns a file with a negative file size.

This commit checks for a negative file size and returns EINVAL.

[phillip@squashfs.org.uk: only need to check 64 bit quantity]</Note>
    </Notes>
    <CVE>CVE-2025-40200</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sctp: Fix 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-40204</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:

btrfs: avoid potential out-of-bounds in btrfs_encode_fh()

The function btrfs_encode_fh() does not properly account for the three
cases it handles.

Before writing to the file handle (fh), the function only returns to the
user BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords, 20 bytes) or
BTRFS_FID_SIZE_CONNECTABLE (8 dwords, 32 bytes).

However, when a parent exists and the root ID of the parent and the
inode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT
(10 dwords, 40 bytes).

If *max_len is not large enough, this write goes out of bounds because
BTRFS_FID_SIZE_CONNECTABLE_ROOT is greater than
BTRFS_FID_SIZE_CONNECTABLE originally returned.

This results in an 8-byte out-of-bounds write at
fid-&gt;parent_root_objectid = parent_root_id.

A previous attempt to fix this issue was made but was lost.

https://lore.kernel.org/all/4CADAEEC020000780001B32C@vpn.id2.novell.com/

Although this issue does not seem to be easily triggerable, it is a
potential memory corruption bug that should be fixed. This patch
resolves the issue by ensuring the function returns the appropriate size
for all three cases and validates that *max_len is large enough before
writing any data.</Note>
    </Notes>
    <CVE>CVE-2025-40205</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nft_objref: validate objref and objrefmap expressions

Referencing a synproxy stateful object from OUTPUT hook causes kernel
crash due to infinite recursive calls:

BUG: TASK stack guard page was hit at 000000008bda5b8c (stack is 000000003ab1c4a5..00000000494d8b12)
[...]
Call Trace:
 __find_rr_leaf+0x99/0x230
 fib6_table_lookup+0x13b/0x2d0
 ip6_pol_route+0xa4/0x400
 fib6_rule_lookup+0x156/0x240
 ip6_route_output_flags+0xc6/0x150
 __nf_ip6_route+0x23/0x50
 synproxy_send_tcp_ipv6+0x106/0x200
 synproxy_send_client_synack_ipv6+0x1aa/0x1f0
 nft_synproxy_do_eval+0x263/0x310
 nft_do_chain+0x5a8/0x5f0 [nf_tables
 nft_do_chain_inet+0x98/0x110
 nf_hook_slow+0x43/0xc0
 __ip6_local_out+0xf0/0x170
 ip6_local_out+0x17/0x70
 synproxy_send_tcp_ipv6+0x1a2/0x200
 synproxy_send_client_synack_ipv6+0x1aa/0x1f0
[...]

Implement objref and objrefmap expression validate functions.

Currently, only NFT_OBJECT_SYNPROXY object type requires validation.
This will also handle a jump to a chain using a synproxy object from the
OUTPUT hook.

Now when trying to reference a synproxy object in the OUTPUT hook, nft
will produce the following error:

synproxy_crash.nft: Error: Could not process rule: Operation not supported
  synproxy name mysynproxy
  ^^^^^^^^^^^^^^^^^^^^^^^^</Note>
    </Notes>
    <CVE>CVE-2025-40206</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: v4l2-subdev: Fix alloc failure check in v4l2_subdev_call_state_try()

v4l2_subdev_call_state_try() macro allocates a subdev state with
__v4l2_subdev_state_alloc(), but does not check the returned value. If
__v4l2_subdev_state_alloc fails, it returns an ERR_PTR, and that would
cause v4l2_subdev_call_state_try() to crash.

Add proper error handling to v4l2_subdev_call_state_try().</Note>
    </Notes>
    <CVE>CVE-2025-40207</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Under certain circumstances, BIND is too lenient when accepting records from answers, allowing an attacker to inject forged data into the cache.
This issue affects BIND 9 versions 9.11.0 through 9.16.50, 9.18.0 through 9.18.39, 9.20.0 through 9.20.13, 9.21.0 through 9.21.12, 9.11.3-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.39-S1, and 9.20.9-S1 through 9.20.13-S1.</Note>
    </Notes>
    <CVE>CVE-2025-40778</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 specific circumstances, due to a weakness in the Pseudo Random Number Generator (PRNG) that is used, it is possible for an attacker to predict the source port and query ID that BIND will use.
This issue affects BIND 9 versions 9.16.0 through 9.16.50, 9.18.0 through 9.18.39, 9.20.0 through 9.20.13, 9.21.0 through 9.21.12, 9.16.8-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.39-S1, and 9.20.9-S1 through 9.20.13-S1.</Note>
    </Notes>
    <CVE>CVE-2025-40780</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">Rack is a modular Ruby web server interface. Prior to versions 2.2.14, 3.0.16, and 3.1.14, `Rack::QueryParser` parses query strings and `application/x-www-form-urlencoded` bodies into Ruby data structures without imposing any limit on the number of parameters, allowing attackers to send requests with extremely large numbers of parameters. The vulnerability arises because `Rack::QueryParser` iterates over each `&amp;`-separated key-value pair and adds it to a Hash without enforcing an upper bound on the total number of parameters. This allows an attacker to send a single request containing hundreds of thousands (or more) of parameters, which consumes excessive memory and CPU during parsing. An attacker can trigger denial of service by sending specifically crafted HTTP requests, which can cause memory exhaustion or pin CPU resources, stalling or crashing the Rack server. This results in full service disruption until the affected worker is restarted. Versions 2.2.14, 3.0.16, and 3.1.14 fix the issue. Some other mitigations are available. One may use middleware to enforce a maximum query string size or parameter count, or employ a reverse proxy (such as Nginx) to limit request sizes and reject oversized query strings or bodies. Limiting request body sizes and query string lengths at the web server or CDN level is an effective mitigation.</Note>
    </Notes>
    <CVE>CVE-2025-46727</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was found in GNU Binutils up to 2.44. It has been rated as critical. Affected by this issue is the function elf_gc_sweep of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. Upgrading to version 2.45 is able to address this issue. It is recommended to upgrade the affected component.</Note>
    </Notes>
    <CVE>CVE-2025-5244</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability classified as critical has been found in GNU Binutils up to 2.44. This affects the function debug_type_samep of the file /binutils/debug.c of the component objdump. The manipulation leads to memory corruption. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue.</Note>
    </Notes>
    <CVE>CVE-2025-5245</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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">An issue was found in the private API function qDecodeDataUrl() in QtCore, which is used in QTextDocument and QNetworkReply, and, potentially, in user code.

If the function was called with malformed data, for example, an URL that
contained a "charset" parameter that lacked a value (such as
"data:charset,"), and Qt was built with assertions enabled, then it would hit an assertion, resulting in a denial of service
(abort).

This impacts Qt up to 5.15.18, 6.0.0-&gt;6.5.8, 6.6.0-&gt;6.8.3 and 6.9.0. This has been fixed in 5.15.19, 6.5.9, 6.8.4 and 6.9.1.</Note>
    </Notes>
    <CVE>CVE-2025-5455</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability has been identified in the GRUB2 bootloader's network module that poses an immediate Denial of Service (DoS) risk. This flaw is a Use-after-Free issue, caused because the net_set_vlan command is not properly unregistered when the network module is unloaded from memory. An attacker who can execute this command can force the system to access memory locations that are no longer valid. Successful exploitation leads directly to system instability, which can result in a complete crash and halt system availability</Note>
    </Notes>
    <CVE>CVE-2025-54770</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A use-after-free vulnerability has been identified in the GNU GRUB (Grand Unified Bootloader). The flaw occurs because the file-closing process incorrectly retains a memory pointer, leaving an invalid reference to a file system structure. An attacker could exploit this vulnerability to cause grub to crash, leading to a Denial of Service. Possible data integrity or confidentiality compromise is not discarded.</Note>
    </Notes>
    <CVE>CVE-2025-54771</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]

There are multiple issues related to the handling and accessing of guest
memory pages in the viridian code:

 1. A NULL pointer dereference in the updating of the reference TSC area.
    This is CVE-2025-27466.

 2. A NULL pointer dereference by assuming the SIM page is mapped when
    a synthetic timer message has to be delivered.  This is
    CVE-2025-58142.

 3. A race in the mapping of the reference TSC page, where a guest can
    get Xen to free a page while still present in the guest physical to
    machine (p2m) page tables.  This is CVE-2025-58143.</Note>
    </Notes>
    <CVE>CVE-2025-58143</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">[This CNA information record relates to multiple CVEs; the
text explains which aspects/vulnerabilities correspond to which CVE.]

Some Viridian hypercalls can specify a mask of vCPU IDs as an input, in
one of three formats.  Xen has boundary checking bugs with all three
formats, which can cause out-of-bounds reads and writes while processing
the inputs.

 * CVE-2025-58147.  Hypercalls using the HV_VP_SET Sparse format can
   cause vpmask_set() to write out of bounds when converting the bitmap
   to Xen's format.

 * CVE-2025-58148.  Hypercalls using any input format can cause
   send_ipi() to read d-&gt;vcpu[] out-of-bounds, and operate on a wild
   vCPU pointer.</Note>
    </Notes>
    <CVE>CVE-2025-58147</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 passing through PCI devices, the detach logic in libxl won't remove
access permissions to any 64bit memory BARs the device might have.  As a
result a domain can still have access any 64bit memory BAR when such
device is no longer assigned to the domain.

For PV domains the permission leak allows the domain itself to map the memory
in the page-tables.  For HVM it would require a compromised device model or
stubdomain to map the leaked memory into the HVM domain p2m.</Note>
    </Notes>
    <CVE>CVE-2025-58149</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. Prior to version 2.4.15, a client that connects to cupsd but sends slow messages, e.g. only one byte per second, delays cupsd as a whole, such that it becomes unusable by other clients. This issue has been patched in version 2.4.15.</Note>
    </Notes>
    <CVE>CVE-2025-58436</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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">A vulnerability has been identified in the GRUB (Grand Unified Bootloader) component. This flaw occurs because the bootloader mishandles string conversion when reading information from a USB device, allowing an attacker to exploit inconsistent length values. A local attacker can connect a maliciously configured USB device during the boot sequence to trigger this issue. A successful exploitation may lead GRUB to crash, leading to a Denial of Service. Data corruption may be also possible, although given the complexity of the exploit the impact is most likely limited.</Note>
    </Notes>
    <CVE>CVE-2025-61661</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A Use-After-Free vulnerability has been discovered in GRUB's gettext module. This flaw stems from a programming error where the gettext command remains registered in memory after its module is unloaded. An attacker can exploit this condition by invoking the orphaned command, causing the application to access a memory location that is no longer valid. An attacker could exploit this vulnerability to cause grub to crash, leading to a Denial of Service. Possible data integrity or confidentiality compromise is not discarded.</Note>
    </Notes>
    <CVE>CVE-2025-61662</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability has been identified in the GRUB2 bootloader's normal command that poses an immediate Denial of Service (DoS) risk. This flaw is a Use-after-Free issue, caused because the normal command is not properly unregistered when the module is unloaded. An attacker who can execute this command can force the system to access memory locations that are no longer valid. Successful exploitation leads directly to system instability, which can result in a complete crash and halt system availability. Impact on the data integrity and confidentiality is also not discarded.</Note>
    </Notes>
    <CVE>CVE-2025-61663</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability in the GRUB2 bootloader has been identified in the normal module. This flaw, a memory Use After Free issue, occurs because the normal_exit command is not properly unregistered when its related module is unloaded. An attacker can exploit this condition by invoking the command after the module has been removed, causing the system to improperly access a previously freed memory location. This leads to a system crash or possible impacts in data confidentiality and integrity.</Note>
    </Notes>
    <CVE>CVE-2025-61664</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Rack is a modular Ruby web server interface. Prior to versions 2.2.20, 3.1.18, and 3.2.3, a possible information disclosure vulnerability existed in `Rack::Sendfile` when running behind a proxy that supports `x-sendfile` headers (such as Nginx). Specially crafted headers could cause `Rack::Sendfile` to miscommunicate with the proxy and trigger unintended internal requests, potentially bypassing proxy-level access restrictions. When `Rack::Sendfile` received untrusted `x-sendfile-type` or `x-accel-mapping` headers from a client, it would interpret them as proxy configuration directives. This could cause the middleware to send a "redirect" response to the proxy, prompting it to reissue a new internal request that was not subject to the proxy's access controls. An attacker could exploit this by setting a crafted `x-sendfile-type: x-accel-redirect` header, setting a crafted `x-accel-mapping` header, and requesting a path that qualifies for proxy-based acceleration. Attackers could bypass proxy-enforced restrictions and access internal endpoints intended to be protected (such as administrative pages). The vulnerability did not allow arbitrary file reads but could expose sensitive application routes. This issue only affected systems meeting all of the following conditions: The application used `Rack::Sendfile` with a proxy that supports `x-accel-redirect` (e.g., Nginx); the proxy did **not** always set or remove the `x-sendfile-type` and `x-accel-mapping` headers; and the application exposed an endpoint that returned a body responding to `.to_path`. Users should upgrade to Rack versions 2.2.20, 3.1.18, or 3.2.3, which require explicit configuration to enable `x-accel-redirect`. Alternatively, configure the proxy to always set or strip the header, or in Rails applications, disable sendfile completely.</Note>
    </Notes>
    <CVE>CVE-2025-61780</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. Prior to version 2.4.15, a user in the lpadmin group can use the cups web ui to change the config and insert a malicious line. Then the cupsd process which runs as root will parse the new config and cause an out-of-bound write. This issue has been patched in version 2.4.15.</Note>
    </Notes>
    <CVE>CVE-2025-61915</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Rack is a modular Ruby web server interface. Prior to versions 2.2.20, 3.1.18, and 3.2.3, `Rack::Request#POST` reads the entire request body into memory for `Content-Type: application/x-www-form-urlencoded`, calling `rack.input.read(nil)` without enforcing a length or cap. Large request bodies can therefore be buffered completely into process memory before parsing, leading to denial of service (DoS) through memory exhaustion. Users should upgrade to Rack version 2.2.20, 3.1.18, or 3.2.3, anu of which enforces form parameter limits using `query_parser.bytesize_limit`, preventing unbounded reads of `application/x-www-form-urlencoded` bodies. Additionally, enforce strict maximum body size at the proxy or web server layer (e.g., Nginx `client_max_body_size`, Apache `LimitRequestBody`).</Note>
    </Notes>
    <CVE>CVE-2025-61919</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">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">Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, an unprivileged local users can crash avahi-daemon (with wide-area disabled) by creating record browsers with the AVAHI_LOOKUP_USE_WIDE_AREA flag set via D-Bus. This can be done by either calling
the RecordBrowserNew method directly or creating hostname/address/service resolvers/browsers that create those browsers internally themselves.</Note>
    </Notes>
    <CVE>CVE-2025-68276</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, avahi-daemon can be crashed by sending unsolicited announcements containing CNAME resource records pointing it to resource records with short TTLs. As soon as they expire avahi-daemon crashes.</Note>
    </Notes>
    <CVE>CVE-2025-68468</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, avahi-daemon can be crashed by sending 2 unsolicited announcements with CNAME resource records 2 seconds apart.</Note>
    </Notes>
    <CVE>CVE-2025-68471</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">net-snmp is a SNMP application library, tools and daemon. Prior to versions 5.9.5 and 5.10.pre2, a specially crafted packet to an net-snmp snmptrapd daemon can cause a buffer overflow and the daemon to crash. This issue has been patched in versions 5.9.5 and 5.10.pre2.</Note>
    </Notes>
    <CVE>CVE-2025-68615</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 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">A vulnerability classified as problematic was found in GNU Binutils 2.45. Affected by this vulnerability is the function copy_section of the file binutils/objcopy.c. The manipulation leads to heap-based buffer overflow. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The patch is named 08c3cbe5926e4d355b5cb70bbec2b1eeb40c2944. It is recommended to apply a patch to fix this issue.</Note>
    </Notes>
    <CVE>CVE-2025-7545</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability, which was classified as problematic, has been found in GNU Binutils 2.45. Affected by this issue is the function bfd_elf_set_group_contents of the file bfd/elf.c. The manipulation leads to out-of-bounds write. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used. The name of the patch is 41461010eb7c79fee7a9d5f6209accdaac66cc6b. It is recommended to apply a patch to fix this issue.</Note>
    </Notes>
    <CVE>CVE-2025-7546</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability has been found in GNU Binutils 2.44 and classified as problematic. This vulnerability affects the function bfd_elf_get_str_section of the file bfd/elf.c of the component BFD Library. The manipulation leads to null pointer dereference. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. The name of the patch is db856d41004301b3a56438efd957ef5cabb91530. It is recommended to apply a patch to fix this issue.</Note>
    </Notes>
    <CVE>CVE-2025-8224</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was found in GNU Binutils 2.44 and classified as problematic. This issue affects the function process_debug_info of the file binutils/dwarf.c of the component DWARF Section Handler. The manipulation leads to memory leak. Attacking locally is a requirement. The identifier of the patch is e51fdff7d2e538c0e5accdd65649ac68e6e0ddd4. It is recommended to apply a patch to fix this issue.</Note>
    </Notes>
    <CVE>CVE-2025-8225</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">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">Querying for records within a specially crafted zone containing certain malformed DNSKEY records can lead to CPU exhaustion.
This issue affects BIND 9 versions 9.18.0 through 9.18.39, 9.20.0 through 9.20.13, 9.21.0 through 9.21.12, 9.18.11-S1 through 9.18.39-S1, and 9.20.9-S1 through 9.20.13-S1.</Note>
    </Notes>
    <CVE>CVE-2025-8677</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">A flaw was found in Libtiff. This vulnerability is a "write-what-where" condition, triggered when the library processes a specially crafted TIFF image file.

By providing an abnormally large image height value in the file's metadata, an attacker can trick the library into writing attacker-controlled color data to an arbitrary memory location. This memory corruption can be exploited to cause a denial of service (application crash) or to achieve arbitrary code execution with the permissions of the user.</Note>
    </Notes>
    <CVE>CVE-2025-9900</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">LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From 1.6.51 to 1.6.53, there is a heap buffer over-read in the libpng simplified API function png_image_finish_read when processing interlaced 16-bit PNGs with 8-bit output format and non-minimal row stride. This is a regression introduced by the fix for CVE-2025-65018. This vulnerability is fixed in 1.6.54.</Note>
    </Notes>
    <CVE>CVE-2026-22695</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 1.6.26 to 1.6.53, there is an integer truncation in the libpng simplified write API functions png_write_image_16bit and png_write_image_8bit causes heap buffer over-read when the caller provides a negative row stride (for bottom-up image layouts) or a stride exceeding 65535 bytes. The bug was introduced in libpng 1.6.26 (October 2016) by casts added to silence compiler warnings on 16-bit systems. This vulnerability is fixed in 1.6.54.</Note>
    </Notes>
    <CVE>CVE-2026-22801</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
</cvrfdoc>
