<?xml version="1.0" encoding="UTF-8"?>
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
  <DocumentTitle xml:lang="en">SUSE-IU-2024:460-1</DocumentTitle>
  <DocumentType>SUSE Image</DocumentType>
  <DocumentPublisher Type="Vendor">
    <ContactDetails>security@suse.de</ContactDetails>
    <IssuingAuthority>SUSE Security Team</IssuingAuthority>
  </DocumentPublisher>
  <DocumentTracking>
    <Identification>
      <ID>SUSE Image SUSE-IU-2024:460-1</ID>
    </Identification>
    <Status>Interim</Status>
    <Version>1</Version>
    <RevisionHistory>
      <Revision>
        <Number>1</Number>
        <Date>2026-03-19T08:54:01Z</Date>
        <Description>current</Description>
      </Revision>
    </RevisionHistory>
    <InitialReleaseDate>2024-05-29T01:00:00Z</InitialReleaseDate>
    <CurrentReleaseDate>2024-05-29T01:00:00Z</CurrentReleaseDate>
    <Generator>
      <Engine>cve-database/bin/generate-cvrf-publiccloud.pl</Engine>
      <Date>2021-02-18T01:00:00Z</Date>
    </Generator>
  </DocumentTracking>
  <DocumentNotes>
    <Note Title="Topic" Type="Summary" Ordinal="1" xml:lang="en">Image update for SUSE-IU-2024:460-1 / google/sles-15-sp5-chost-byos-v20240529-x86-64</Note>
    <Note Title="Details" Type="General" Ordinal="2" xml:lang="en">This image update for google/sles-15-sp5-chost-byos-v20240529-x86-64 contains the following changes:
Package catatonit was updated:

- Update to catatonit v0.2.0.  * Change license to GPL-2.0-or-later.
- Remove upstreamed patches:
  - 99bb9048f.patch

Package coreutils was updated:

- ls: avoid triggering automounts (bsc#1221632)  - add coreutils-ls-avoid-triggering-automounts.patch

Package e2fsprogs was updated:

EA Inode handling fixes:- ext2fs-avoid-re-reading-inode-multiple-times.patch: ext2fs: avoid re-reading
  inode multiple times (bsc#1223596)
- e2fsck-fix-potential-out-of-bounds-read-in-inc_ea_in.patch: e2fsck: fix
  potential out-of-bounds read in inc_ea_inode_refs() (bsc#1223596)
- e2fsck-add-more-checks-for-ea-inode-consistency.patch: e2fsck: add more
  checks for ea inode consistency (bsc#1223596)
- e2fsck-fix-golden-output-of-several-tests.patch: e2fsck: fix golden output of
  several tests (bsc#1223596)

Package kdump was updated:

- spec: return success from pre, post, preun and postun scriplets  (bsc#1222228, bsc#1191410)
- spec: differentiate between uninstall and upgrade in postun/preun
  (bsc#1191410)

Package kernel-default was updated:

- Update  patches.suse/efi-libstub-Implement-support-for-unaccepted-memory.patch
  (jsc#PED-7167, bsc#1224169).
- commit a57eb93

- Update
  patches.suse/SUNRPC-fix-a-memleak-in-gss_import_v2_context.patch
  (git-fixes bsc#1223858).
- commit e50ed21

- netfilter: nft_ct: fix l3num expectations with inet pseudo
  family (git-fixes).
- commit 87e8a80

- Reapply &amp;quot;drm/qxl: simplify qxl_fence_wait&amp;quot; (stable-fixes).
- commit 8f3269f

- Update
  patches.suse/1576-drm-amd-display-fix-memory-leak-when-using-debugfs_l.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225 jsc#PED-2849
  CVE-2022-48698 bsc#1223956).
- commit a0e3008

- Update patches.suse/ice-Fix-DMA-mappings-leak.patch (jsc#PED-376
  CVE-2022-48690 bsc#1223960).
- commit 7e1bf3d

- Update
  patches.suse/ALSA-emu10k1-Fix-out-of-bounds-access-in-snd_emu10k1.patch
  (git-fixes CVE-2022-48702 bsc#1223923).
- Update
  patches.suse/ALSA-usb-audio-Fix-an-out-of-bounds-bug-in-__snd_usb.patch
  (git-fixes CVE-2022-48701 bsc#1223921).
- Update
  patches.suse/RDMA-irdma-Fix-drain-SQ-hang-with-no-completion.patch
  (jsc#SLE-18383 CVE-2022-48694 bsc#1223964).
- Update
  patches.suse/RDMA-srp-Set-scmnd-result-only-when-scmnd-is-not-NUL.patch
  (git-fixes CVE-2022-48692 bsc#1223962).
- Update
  patches.suse/cgroup-Add-missing-cpus_read_lock-to-cgroup_attach_task_all.patch
  (bsc#1196869 CVE-2022-48671 bsc#1223929).
- Update
  patches.suse/drm-radeon-add-a-force-flush-to-delay-work-when-rade.patch
  (git-fixes CVE-2022-48704 bsc#1223932).
- Update
  patches.suse/i40e-Fix-kernel-crash-during-module-removal.patch
  (jsc#SLE-18378 CVE-2022-48688 bsc#1223953).
- Update
  patches.suse/ipv6-sr-fix-out-of-bounds-read-when-setting-HMAC-dat.patch
  (bsc#1211592 CVE-2023-2860 CVE-2022-48687 bsc#1223952).
- Update
  patches.suse/net-smc-Fix-possible-access-to-freed-memory-in-link-clear
  (git-fixes CVE-2022-48673 bsc#1223934).
- Update
  patches.suse/nvme-tcp-fix-uaf-when-detecting-digest-errors.patch
  (bsc#1200313 bsc#1201489 CVE-2022-48686 bsc#1223948).
- Update patches.suse/nvmet-fix-a-use-after-free.patch (git-fixes
  CVE-2022-48697 bsc#1223922).
- Update
  patches.suse/of-fdt-fix-off-by-one-error-in-unflatten_dt_nodes.patch
  (git-fixes CVE-2022-48672 bsc#1223931).
- Update
  patches.suse/scsi-mpt3sas-Fix-use-after-free-warning.patch
  (git-fixes CVE-2022-48695 bsc#1223941).
- Update
  patches.suse/soc-brcmstb-pm-arm-Fix-refcount-leak-and-__iomem-lea.patch
  (git-fixes CVE-2022-48693 bsc#1223963).
- Update
  patches.suse/thermal-int340x_thermal-handle-data_vault-when-the-v.patch
  (bsc#1201308 CVE-2022-48703 bsc#1223924).
- Update patches.suse/vfio-type1-Unpin-zero-pages.patch (git-fixes
  CVE-2022-48700 bsc#1223957).
- commit c8677b5

- packet: annotate data-races around ignore_outgoing
  (CVE-2024-26862 bsc#1223111).
- commit 6e591e7

- sctp: fix potential deadlock on &amp;amp;net-&amp;gt;sctp.addr_wq_lock
  (CVE-2024-0639 bsc#1218917).
- commit 517d4f7

- Update
  patches.suse/drm-i915-gem-Really-move-i915_gem_context.link-under.patch
  (CVE-2022-48662 bsc#1223505).
  Unbreak metadata (References: collides with our internal tracking,
  switch to Fixes: when referencing a commit).
- commit cd38265

- netfilter: nft_ct: sanitize layer 3 and 4 protocol number in
  custom expectations (bsc#1222368 CVE-2024-26673).
- commit 785b7d0

- igc: avoid returning frame twice in XDP_REDIRECT (bsc#1223061
  CVE-2024-26853).
- commit 021db33

- net: sparx5: Fix use after free inside sparx5_del_mact_entry
  (bsc#1223052 CVE-2024-26856).
- commit fc5c6ad

- fs: sysfs: Fix reference leak in sysfs_break_active_protection() (CVE-2024-26993 bsc#1223693)
- commit b0c9830

- Update
  patches.suse/IB-core-Fix-a-nested-dead-lock-as-part-of-ODP-flow.patch
  (git-fixes CVE-2022-48675 bsc#1223894).
- Update
  patches.suse/drm-gma500-Fix-BUG-sleeping-function-called-from-inv.patch
  (git-fixes CVE-2022-48634 bsc#1223501).
- Update
  patches.suse/drm-i915-gem-Really-move-i915_gem_context.link-under.patch
  (CVE-2022-48662 bsc#1223505a4e7ccdac38e (&amp;quot;drm/i915: Move
  context management under GEM&amp;quot;) bsc#1223505).
- Update
  patches.suse/i2c-mlxbf-prevent-stack-overflow-in-mlxbf_i2c_smbus_.patch
  (git-fixes CVE-2022-48632 bsc#1223481).
- Update
  patches.suse/ice-Fix-crash-by-keep-old-cfg-when-update-TCs-more-t.patch
  (git-fixes CVE-2022-48652 bsc#1223520).
- Update
  patches.suse/s390-dasd-fix-Oops-in-dasd_alias_get_start_dev-due-to-missing-pavgroup
  (git-fixes CVE-2022-48636 bsc#1223512).
- commit 523501c

- blacklist.conf: add a not-relevant module-loader patch
- commit 90c64db

- ring-buffer: Only update pages_touched when a new page is
  touched (git-fixes).
- commit b42aba1

- kprobes: Fix possible use-after-free issue on kprobe
  registration (git-fixes).
- commit e007447

- ring-buffer: use READ_ONCE() to read cpu_buffer-&amp;gt;commit_page
  in concurrent environment (git-fixes).
- commit 118cfcd

- tracing/net_sched: Fix tracepoints that save qdisc_dev()
  as a string (git-fixes).
- commit a272f90

- tracing: Show size of requested perf buffer (git-fixes).
- commit f8d068b

- Bluetooth: Add new quirk for broken read key length on ATS2851
  (git-fixes).
- commit 9ac913a

- Bluetooth: hci_event: Fix sending HCI_OP_READ_ENC_KEY_SIZE
  (git-fixes).
- commit 83cd609

- fuse: don't unhash root (bsc#1223951).
- fuse: fix root lookup with nonzero generation (bsc#1223950).
- virtio: treat alloc_dax() -EOPNOTSUPP failure as non-fatal
  (bsc#1223949).
- commit fdf9216

- RDMA/cm: Print the old state when cm_destroy_id gets timeout
  (git-fixes).
- commit 9b2934b

- nouveau: lock the client object tree. (bsc#1223834 CVE-2024-27062)
- commit e828498

- drm/nouveau/nvkm: add a replacement for nvkm_notify (bsc#1223834)
- commit 5647172

- drm/amd/display: fix NULL checks for adev-&amp;gt;dm.dc in amdgpu_dm_fini() (CVE-2024-27041 bsc#1223714)
- commit ae6f7a9

- tun: limit printing rate when illegal packet received by tun
  dev (bsc#1223745 CVE-2024-27013).
- net/mlx5e: Prevent deadlock while disabling aRFS (bsc#1223735
  CVE-2024-27014).
- octeontx2-af: Use separate handlers for interrupts (bsc#1223790
  CVE-2024-27030).
- wireguard: netlink: access device through ctx instead of peer
  (bsc#1223661 CVE-2024-26950).
- wireguard: netlink: check for dangling peer via is_dead instead
  of empty list (bsc#1223660 CVE-2024-26951).
- wireguard: receive: annotate data-race around
  receiving_counter.counter (bsc#1223076 CVE-2024-26861).
- nfp: flower: handle acti_netdevs allocation failure (bsc#1223827
  CVE-2024-27046).
- commit b495510

- drm/amd/display: Add a dc_state NULL check in dc_state_release (CVE-2024-26948 bsc#1223664)
- commit 211db77

- slimbus: qcom-ngd-ctrl: Add timeout for wait operation
  (git-fixes).
- iio:imu: adis16475: Fix sync mode setting (git-fixes).
- iio: accel: mxc4005: Interrupt handling fixes (git-fixes).
- usb: typec: tcpm: Check for port partner validity before
  consuming it (git-fixes).
- usb: typec: tcpm: unregister existing source caps before
  re-registration (bsc#1220569).
- usb: Fix regression caused by invalid ep0 maxpacket in virtual
  SuperSpeed device (git-fixes).
- usb: ohci: Prevent missed ohci interrupts (git-fixes).
- usb: gadget: f_fs: Fix a race condition when processing setup
  packets (git-fixes).
- usb: gadget: composite: fix OS descriptors w_value logic
  (git-fixes).
- commit d9cff03

- pstore: inode: Only d_invalidate() is needed (bsc#1223705
  CVE-2024-27389).
- commit bbe965a

- ALSA: hda/realtek: Fix mute led of HP Laptop 15-da3001TU
  (stable-fixes).
- ALSA: hda/realtek: Add quirk for HP SnowWhite laptops
  (stable-fixes).
- commit 86753e0

- ASoC: meson: axg-tdm-interface: manage formatters in trigger
  (git-fixes).
- ASoC: meson: axg-card: make links nonatomic (git-fixes).
- ASoC: meson: cards: select SND_DYNAMIC_MINORS (git-fixes).
- ASoC: ti: davinci-mcasp: Fix race condition during probe
  (git-fixes).
- ASoC: tegra: Fix DSPK 16-bit playback (git-fixes).
- ALSA: hda: intel-sdw-acpi: fix usage of
  device_get_named_child_node() (git-fixes).
- drm/panel: ili9341: Use predefined error codes (git-fixes).
- drm/panel: ili9341: Respect deferred probe (git-fixes).
- drm/vmwgfx: Fix invalid reads in fence signaled events
  (git-fixes).
- drm/amdgpu: once more fix the call oder in amdgpu_ttm_move()
  v2 (git-fixes).
- spi: hisi-kunpeng: Delete the dump interface of data registers
  in debugfs (git-fixes).
- commit 79c4a57

- wifi: iwlwifi: mvm: ensure offloading TID queue exists
  (CVE-2024-27056 bsc#1223822).
- wifi: iwlwifi: mvm: protect TXQ list manipulation
  (CVE-2024-27056 bsc#1223822).
- commit 5895d13

- media: edia: dvbdev: fix a use-after-free (CVE-2024-27043
  bsc#1223824).
- commit e3d9ce5

- clk: hisilicon: hi3559a: Fix an erroneous devm_kfree()
  (CVE-2024-27039 bsc#1223821).
- commit 70ad74a

- clk: Fix clk_core_get NULL dereference (CVE-2024-27038
  bsc#1223816).
- commit bcf8ce4

- Rename to
  patches.suse/drm-i915-gem-Really-move-i915_gem_context.link-under.patch.
- commit e953a9a

- s390/qeth: Fix kernel panic after setting hsuid (git-fixes
  bsc#1223879).
- commit 1b0c7f2

- s390/mm: Fix storage key clearing for guest huge pages
  (git-fixes bsc#1223878).
- commit fc57acc

- s390/mm: Fix clearing storage keys for huge pages (git-fixes
  bsc#1223877).
- commit c73273d

- s390/vdso: Add CFI for RA register to asm macro vdso_func
  (git-fixes bsc#1223876).
- commit 15b93ff

- s390/cio: Ensure the copied buf is NUL terminated (git-fixes
  bsc#1223875).
- commit c670b5d

- NTB: fix possible name leak in ntb_register_device()
  (CVE-2023-52652 bsc#1223686).
- commit 206337a

- mm: swap: fix race between free_swap_and_cache() and swapoff()
  (CVE-2024-26960 bsc#1223655).
- commit b6bee56

- swap: comments get_swap_device() with usage rule (CVE-2024-26960
  bsc#1223655).
- commit 15510e4

- Refresh patches.suse/powerpc-pseries-iommu-LPAR-panics-when-rebooted-with.patch.
- commit 2ecdc0a

- clk: qcom: mmcc-msm8974: fix terminating of frequency table
  arrays (CVE-2024-26965 bsc#1223648).
- commit 1dd34df

- clk: qcom: mmcc-apq8084: fix terminating of frequency table
  arrays (CVE-2024-26966 bsc#1223646).
- commit a12a96e

- clk: qcom: gcc-ipq8074: fix terminating of frequency table
  arrays (CVE-2024-26969 bsc#1223645).
- commit 8dca0be

- xfrm6: fix inet6_dev refcount underflow problem (git-fixes).
- commit f5401a7

- ipv6/addrconf: fix a potential refcount underflow for idev
  (git-fixes).
- commit cdd225e

- net: fix skb leak in __skb_tstamp_tx() (git-fixes).
- commit 87fa6a6

- tcp/udp: Fix memleaks of sk and zerocopy skbs with TX timestamp
  (git-fixes).
- commit 77fb94f

- net: stream: purge sk_error_queue in sk_stream_kill_queues()
  (git-fixes).
- commit cb9fa4c

- netfilter: br_netfilter: Drop dst references before setting
  (git-fixes).
- commit 28508ef

- net: mld: fix reference count leak in mld_{query |
  report}_work() (git-fixes).
- commit 389c7c7

- net: ipv6: ensure we call ipv6_mc_down() at most once
  (git-fixes).
- commit e46b1a5

- net: fix a memleak when uncloning an skb dst and its metadata
  (git-fixes).
- commit 9e895dd

- net: bridge: vlan: fix memory leak in __allowed_ingress
  (git-fixes).
- commit 26122cb

- Update patches.suse/nfsd-use-__fput_sync-to-avoid-delayed-closing-of-fil.patch
  (bsc#1223380 bsc#1217408 bsc#1223640).
- commit 48bb894

- netfilter: ipt_CLUSTERIP: fix refcount leak in
  clusterip_tg_check() (git-fixes).
- commit 014c7bb

- net: vlan: fix underflow for the real_dev refcnt (git-fixes).
- commit f6e1f81

- x86/sev: Skip ROM range scans and validation for SEV-SNP guests
  (jsc#PED-7167 git-fixes).
- Refresh
  patches.suse/0003-efi-Lock-down-the-kernel-if-booted-in-secure-boot-mode.patch.
- Refresh
  patches.suse/0004-efi-Lock-down-the-kernel-at-the-integrity-level-if-b.patch.
- commit 8eb012f

- x86/mm: Ensure input to pfn_to_kaddr() is treated as a 64-bit
  type (jsc#PED-7167 git-fixes).
- commit 554f303

- Update
  patches.suse/ext4-fix-bug-in-extents-parsing-when-eh_entries-0-an.patch
  (bsc#1206881 bsc#1223475 CVE-2022-48631).
- commit 718df1c

- clk: qcom: gcc-ipq6018: fix terminating of frequency table
  arrays (CVE-2024-26970 bsc#1223644).
- commit 0c0dddd

- mtd: diskonchip: work around ubsan link failure (stable-fixes).
- drm/amdgpu/sdma5.2: use legacy HDP flush for SDMA2/3
  (stable-fixes).
- drm/amdgpu: Fix leak when GPU memory allocation fails
  (stable-fixes).
- Bluetooth: btusb: Add Realtek RTL8852BE support ID 0x0bda:0x4853
  (stable-fixes).
- Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()
  (stable-fixes).
- serial: core: fix kernel-doc for uart_port_unlock_irqrestore()
  (git-fixes).
- serial: core: Provide port lock wrappers (stable-fixes).
- drm-print: add drm_dbg_driver to improve namespace symmetry
  (stable-fixes).
- commit ac12ea7

- net/ipv6: avoid possible UAF in ip6_route_mpath_notify()
  (CVE-2024-26852 bsc#1223057)
- commit d89430d

- arm64: dts: rockchip: Remove unsupported node from the Pinebook Pro (git-fixes)
- commit 4bfffd4

- arm64: dts: rockchip: enable internal pull-up on PCIE_WAKE# for (git-fixes)
- commit 1d62037

- arm64: dts: rockchip: enable internal pull-up on Q7_USB_ID for RK3399 (git-fixes)
- commit 93fb4e2

- arm64: dts: rockchip: enable internal pull-up for Q7_THRM# on RK3399 (git-fixes)
- commit 5fec238

- arm64: dts: imx8-ss-conn: fix usdhc wrong lpcg clock order (git-fixes)
- commit 8f27cd5

- md/raid5: fix atomicity violation in raid5_cache_count
  (bsc#1219169, CVE-2024-23307).
- commit d2d22f0

- s390/decompressor: fix misaligned symbol build error (git-fixes
  bsc#1223785).
- commit 47fb728

- arm64: dts: rockchip: fix rk3399 hdmi ports node (git-fixes)
- commit c7b5bd6

- arm64: dts: rockchip: fix rk3328 hdmi ports node (git-fixes)
- commit a134662

- s390/scm: fix virtual vs physical address confusion (git-fixes bsc#1223784).
- commit bb84f10

- kABI workaround for cec_adapter (CVE-2024-23848 bsc#1219104).
- media: cec: core: avoid recursive cec_claim_log_addrs
  (CVE-2024-23848 bsc#1219104).
- media: cec: core: avoid confusing &amp;quot;transmit timed out&amp;quot; message
  (CVE-2024-23848 bsc#1219104).
- media: cec: cec-api: add locking in cec_release()
  (CVE-2024-23848 bsc#1219104).
- media: cec: cec-adap: always cancel work in cec_transmit_msg_fh
  (CVE-2024-23848 bsc#1219104).
- commit 70ecf73

- mm/slub: fix to return errno if kmalloc() fails (CVE-2022-48659
  bsc#1223498).
- commit d72759d

- drm/amdgpu: Fix possible NULL dereference in amdgpu_ras_query_error_status_helper() (CVE-2023-52585 bsc#1221080).
- commit cde7c84

- bonding: fix NULL deref in bond_rr_gen_slave_id (bsc#1223499
  CVE-2022-48640).
- commit 9f14266

- media: cec: abort if the current transmit was canceled
  (CVE-2024-23848 bsc#1219104).
- commit e51b978

- Squashfs: check the inode number is not the invalid value of
  zero (bsc#1223634 CVE-2024-26982).
- commit 8ad2647

- Update
  patches.suse/ubifs-ubifs_symlink-Fix-memleak-of-inode-i_link-in-error-path.patch
  (git-fixes CVE-2024-26972 bsc#1223643).
- commit c1d0983

- Update
  patches.suse/nilfs2-prevent-kernel-bug-at-submit_bh_wbc.patch
  (git-fixes CVE-2024-26955 bsc#1223657).
- commit 59db655

- Update
  patches.suse/nilfs2-fix-failure-to-detect-DAT-corruption-in-btree.patch
  (git-fixes CVE-2024-26956 bsc#1223663).
- commit b968ba7

- Update patches.suse/nilfs2-fix-OOB-in-nilfs_set_de_type.patch
  (git-fixes CVE-2024-26981 bsc#1223668).
- commit 7b2eba5

- ASoC: SOF: Add some bounds checking to firmware data
  (CVE-2024-26927 bsc#1223525).
- commit 797ef67

- Update
  patches.suse/gpio-mockup-fix-NULL-pointer-dereference-when-removi.patch
  (git-fixes CVE-2022-48663 bsc#1223523).
- commit fb50f4d

- Update
  patches.suse/cgroup-cgroup_get_from_id-must-check-the-looked-up-kn-is-a-directory.patch
  (bsc#1203906 CVE-2022-48638 bsc#1223522).
- commit 1b1d545

- Update
  patches.suse/sfc-fix-TX-channel-offset-when-using-legacy-interrup.patch
  (git-fixes CVE-2022-48647 bsc#1223519).
- commit 2df3009

- Update
  patches.suse/smb3-fix-temporary-data-corruption-in-insert-range.patch
  (bsc#1193629 CVE-2022-48667 bsc#1223518).
- commit 2544640

- Update
  patches.suse/bnxt-prevent-skb-UAF-after-handing-over-to-PTP-worke.patch
  (jsc#SLE-18978 CVE-2022-48637 bsc#1223517).
- commit 8af9f52

- Update
  patches.suse/smb3-fix-temporary-data-corruption-in-collapse-range.patch
  (bsc#1193629 CVE-2022-48668 bsc#1223516).
- commit ea57df6

- drm/i915/gem: Really move i915_gem_context.link under ref
  protection (CVE-2022-48662 bsc#1223505).
- commit 1ea0422

- Update
  patches.suse/net-sched-taprio-avoid-disabling-offload-when-it-was.patch
  (bsc#1207361 CVE-2022-48644 bsc#1223511).
- commit 32036dc

- Update
  patches.suse/1631-drm-i915-gem-Really-move-i915_gem_context.link-under.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225
  jsc#PED-2849a4e7ccdac38e (&amp;quot;drm/i915: Move context management
  under GEM&amp;quot;) CVE-2022-48662 bsc#1223505).
- commit 16b0082

- netfilter: nf_tables: disallow timeout for anonymous sets
  (CVE-2023-52620 bsc#1221825).
- commit 19a9222

- Update
  patches.suse/scsi-qla2xxx-Fix-memory-leak-in-__qlt_24xx_handle_ab.patch
  (bsc#1203935 CVE-2022-48650 bsc#1223509).
- commit a4b4019

- Update
  patches.suse/scsi-qla2xxx-Fix-memory-leak-in-__qlt_24xx_handle_ab.patch
  (bsc#1203935 CVE-2022-48650 bsc#1223509).
- commit ecd523c

- Update
  patches.suse/sfc-fix-null-pointer-dereference-in-efx_hard_start_x.patch
  (git-fixes CVE-2022-48648 bsc#1223503).
- commit 2cd307a

- Update
  patches.suse/sfc-siena-fix-null-pointer-dereference-in-efx_hard_s.patch
  (jsc#PED-1565 CVE-2022-48646 bsc#1223502).
- commit 54704c0

- Update
  patches.suse/net-sched-fix-possible-refcount-leak-in-tc_new_tfilt.patch
  (bsc#1207361 CVE-2022-48639 bsc#1223490).
- commit 1b88973

- Update
  patches.suse/gpiolib-cdev-Set-lineevent_state-irq-after-IRQ-regis.patch
  (git-fixes CVE-2022-48660 bsc#1223487).
- commit 30d7811

- Update
  patches.suse/arm64-topology-fix-possible-overflow-in-amu_fie_setu.patch
  (git-fixes CVE-2022-48657 bsc#1223484).
- commit d7e1659

- Update
  patches.suse/netfilter-nfnetlink_osf-fix-possible-bogus-match-in-.patch
  (bsc#1204614 CVE-2022-48654 bsc#1223482).
- commit a8a2952

- Update
  patches.suse/dmaengine-ti-k3-udma-private-Fix-refcount-leak-bug-i.patch
  (git-fixes CVE-2022-48656 bsc#1223479).
- commit 90546f3

- netfilter: nf_tables: fix percpu memory leak at
  nf_tables_addchain() (bsc#1223478 CVE-2022-48642).
- commit 839888a

- blacklist.conf: code refactoring
- commit f72ed44

- dump_stack: Do not get cpu_sync for panic CPU (bsc#1223574).
- commit 15c6bc2

- printk: Avoid non-panic CPUs writing to ringbuffer
  (bsc#1223574).
- commit d14ad8e

- Update
  patches.suse/ice-Don-t-double-unplug-aux-on-peer-initiated-reset.patch
  (git-fixes CVE-2022-48653 bsc#1223474).
- commit dba84ad

- blacklist.conf: refactoring, not a fix
- commit ef0f94f

- s390/vdso: drop '-fPIC' from LDFLAGS (git-fixes bsc#1223598).
- commit ed11fe0

- printk: Disable passing console lock owner completely during
  panic() (bsc#1223574).
- commit d98358d

- s390/zcrypt: fix reference counting on zcrypt card objects
  (git-fixes bsc#1223595).
- commit 0483eb1

- Update
  patches.suse/media-pvrusb2-fix-uaf-in-pvr2_context_set_notify.patch
  (git-fixes CVE-2024-26875 bsc#1223118).
- commit fd5a947

- printk: ringbuffer: Skip non-finalized records in panic
  (bsc#1223574).
- commit c9df6e3

- printk: Wait for all reserved records with pr_flush()
  (bsc#1223574).
- commit d04f93d

- Update
  patches.suse/RDMA-srpt-Do-not-register-event-handler-until-srpt-d.patch
  (git-fixes CVE-2024-26872 bsc#1223115).
- commit 66d99f5

- printk: ringbuffer: Cleanup reader terminology (bsc#1223574).
- commit a92ce86

- printk: Add this_cpu_in_panic() (bsc#1223574).
- commit 0b039ad

- quota: Fix potential NULL pointer dereference (bsc#1223060
  CVE-2024-26878).
- commit 93c484c

- do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak
  (bsc#1223198 CVE-2024-26901).
- commit a397ff1

- blk-mq: fix IO hang from sbitmap wakeup race (bsc#1222357
  CVE-2024-26671).
- commit 9908e06

- ext4: avoid allocating blocks from corrupted group in
  ext4_mb_find_by_goal() (bsc#1222613 CVE-2024-26772).
- commit be73fd6

- printk: Rename abandon_console_lock_in_panic() to
  other_cpu_in_panic() (bsc#1223574).
- commit 6336c25

- Update
  patches.suse/s390-Once-the-discipline-is-associated-with-the-device-de.patch
  (bsc#1141539 git-fixes).
- commit 111a038

- printk: Drop console_sem during panic (bsc#1223574).
- commit 725427c

- clk: meson: Add missing clocks to axg_clk_regmaps
  (CVE-2024-26879 bsc#1223066).
- commit 46eee50

- printk: ringbuffer: Clarify special lpos values (bsc#1223574).
- commit 0f13b5c

- printk: ringbuffer: Do not skip non-finalized records with
  prb_next_seq() (bsc#1223574).
- commit 28b403a

- printk: ringbuffer: Improve prb_next_seq() performance
  (bsc#1223574).
- commit 6a93375

- Update
  patches.suse/msft-hv-2942-hv_netvsc-Register-VF-in-netvsc_probe-if-NET_DEVICE_.patch
  (git-fixes CVE-2024-26820 bsc#1223078).
- commit d0bb689

- Update
  patches.suse/nfc-nci-free-rx_data_reassembly-skb-on-NCI-device-cl.patch
  (git-fixes CVE-2024-26825 bsc#1223065).
- commit 4685711

- wifi: wfx: fix memory leak when starting AP (CVE-2024-26896
  bsc#1223042).
- commit f3e25cb

- Update
  patches.suse/scsi-Revert-scsi-fcoe-Fix-potential-deadlock-on-fip-ctlr_lock.patch
  (git-fixes bsc#1219141 CVE-2024-26917 bsc#1223056).
- commit f3895d7

- printk: Use prb_first_seq() as base for 32bit seq macros
  (bsc#1223574).
- commit e3b59e0

- printk: Adjust mapping for 32bit seq macros (bsc#1223574).
- commit 6dcabeb

- printk: nbcon: Relocate 32bit seq macros (bsc#1223574).
- commit c13f8d3

- PM / devfreq: Fix buffer overflow in trans_stat_show
  (CVE-2023-52614 bsc#1221617).
- commit 43b7d5b

- Update
  patches.suse/0002-iommu-vt-d-Don-t-issue-ATS-Invalidation-request-when.patch
  (git-fixes CVE-2024-26891 bsc#1223037).
- commit 7b52ba2

- Update
  patches.suse/drm-amd-display-Fix-memory-leak-in-dm_sw_fini.patch
  (git-fixes CVE-2024-26833 bsc#1223036).
- commit 6c18411

- ipvlan: Fix out-of-bound bugs caused by unset skb-&amp;gt;mac_header
  (bsc#1223513 CVE-2022-48651).
- commit c96a663

- net: hns3: fix kernel crash when 1588 is received on HIP08
  devices (bsc#1223041 CVE-2024-26881).
- net: ice: Fix potential NULL pointer dereference in
  ice_bridge_setlink() (bsc#1223051 CVE-2024-26855).
- geneve: make sure to pull inner header in geneve_rx()
  (bsc#1223058 CVE-2024-26857).
- ppp_async: limit MRU to 64K (bsc#1222379 CVE-2024-26675).
- commit 61a60e2

- Update
  patches.suse/efi-runtime-Fix-potential-overflow-of-soft-reserved-.patch
  (git-fixes CVE-2024-26843 bsc#1223014).
- commit 3f9577f

- net: usb: ax88179_178a: stop lying about skb-&amp;gt;truesize
  (git-fixes).
- commit 416a90a

- Update
  patches.suse/wifi-ath9k-delay-all-of-ath9k_wmi_event_tasklet-unti.patch
  (git-fixes CVE-2024-26897 bsc#1223323).
- commit 938950f

- drm/amd/display: Fix MST Null Ptr for RV (CVE-2021-47200 bsc#1222838)
- commit 3d0cc91

- Update
  patches.suse/wifi-wilc1000-prevent-use-after-free-on-vif-when-cle.patch
  (git-fixes CVE-2024-26895 bsc#1223197).
- commit 73cb93c

- amdkfd: use calloc instead of kzalloc to avoid integer overflow (CVE-2024-26817 bsc#1222812)
- commit 5946a4f

- Update patches.suse/firmware-arm_scmi-Harden-accesses-to-the-reset-domai.patch (git-fixes CVE-2022-48655 bsc#1223477)
- commit 2dabafb

- mm: slub: fix flush_cpu_slab()/__free_slab() invocations in
  task context (CVE-2022-48658 bsc#1223496).
- commit 3480d23

- firmware: arm_scmi: Fix double free in SMC transport cleanup
  path (CVE-2024-26893 bsc#1223196).
- commit 689202d

- nfsd: use __fput_sync() to avoid delayed closing of files
  (bsc#1223380 bsc#1217408).
- commit aa925bb

- Revert &amp;quot;ice: Fix ice VF reset during iavf initialization (jsc#PED-376).&amp;quot; (bsc#1223275)
  This reverts commit b92b60703522e3531f77c5af2f34b4b165007b3a.
  This commit was reverted upstream by commit 0ecff05e6c59dd82dbcb9706db911f7fd9f40fb8
  with note:
  ice_check_vf_ready_for_cfg() already contain waiting for reset.
  New condition in ice_check_vf_ready_for_reset() causing only problems.
- commit 33e8bb2

- Update patches.suse/powerpc-pseries-vas-Hold-mmap_mutex-after-mmap-lock-.patch
  (jsc#PED-542 git-fixes bsc#1213573 ltc#203238).
- commit 29ca2f7

- livepatch: Fix missing newline character in
  klp_resolve_symbols() (bsc#1223539).
- commit ccf2afb

- blacklist.conf: cosmetic; kind of code documentation
- commit 6c8cbf7

- blacklist.conf: workqueue: prevent false circular dependency by lockdep,
  code churn, primary useful when developing new code, lockdep is
  disabled on production kernels (bsc#1223536)
- commit 6ab7164

- Update
  patches.suse/spi-spi-zynqmp-gqspi-Handle-error-for-dma_set_mask.patch
  (git-fixes CVE-2021-47047 bsc#1220761).
- commit 1f6461d

- crypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init
  (CVE-2023-52616 bsc#1221612).
- commit 6fa74bc

- mm/vmscan: fix a bug calling wakeup_kswapd() with a wrong zone
  index (bsc#1222615 CVE-2024-26783).
- commit d2a6383

- mm/vmscan: make sure wakeup_kswapd with managed zone
  (bsc#1223473).
- commit c954567

- x86/boot: Ignore relocations in .notes sections in walk_relocs() too (bsc#1222624 CVE-2024-26816).
- commit 9c9dbbd

- x86, relocs: Ignore relocations in .notes section (bsc#1222624 CVE-2024-26816).
- commit 9bcfc48

- hugetlb, userfaultfd: fix reservation restore on userfaultfd
  error (bsc#1222710 CVE-2021-47214).
- commit 4a75d88

- drm/amdgpu: fix use-after-free bug (CVE-2024-26656 bsc#1222307)
- commit 2c0e8cb

- i2c: smbus: fix NULL function pointer dereference (git-fixes).
- dmaengine: idxd: Fix oops during rmmod on single-CPU platforms
  (git-fixes).
- dma: xilinx_dpdma: Fix locking (git-fixes).
- idma64: Don't try to serve interrupts when device is powered
  off (git-fixes).
- dmaengine: tegra186: Fix residual calculation (git-fixes).
- dmaengine: owl: fix register access functions (git-fixes).
- USB: serial: option: add Telit FN920C04 rmnet compositions
  (stable-fixes).
- USB: serial: option: add Rolling RW101-GL and RW135-GL support
  (stable-fixes).
- USB: serial: option: add Lonsung U8300/U9300 product
  (stable-fixes).
- USB: serial: option: add support for Fibocom FM650/FG650
  (stable-fixes).
- USB: serial: option: support Quectel EM060K sub-models
  (stable-fixes).
- USB: serial: option: add Fibocom FM135-GL variants
  (stable-fixes).
- thunderbolt: Avoid notify PM core about runtime PM resume
  (stable-fixes).
- thunderbolt: Fix wake configurations after device unplug
  (stable-fixes).
- usb: Disable USB3 LPM at shutdown (stable-fixes).
- usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb
  ep transport error (stable-fixes).
- clk: Get runtime PM before walking tree during disable_unused
  (git-fixes).
- clk: Initialize struct clk_core kref earlier (stable-fixes).
- arm64: hibernate: Fix level3 translation fault in swsusp_save()
  (git-fixes).
- ALSA: hda/realtek - Enable audio jacks of Haier Boyue G42 with
  ALC269VC (stable-fixes).
- drm/vmwgfx: Fix crtc's atomic check conditional (git-fixes).
- drm/amd/display: Do not recursively call manual trigger
  programming (stable-fixes).
- drm/amdgpu: fix incorrect number of active RBs for gfx11
  (stable-fixes).
- drm: panel-orientation-quirks: Add quirk for Lenovo Legion Go
  (stable-fixes).
- ALSA: scarlett2: Add Focusrite Clarett 2Pre and 4Pre USB support
  (stable-fixes).
- ALSA: scarlett2: Add Focusrite Clarett+ 2Pre and 4Pre support
  (stable-fixes).
- ALSA: scarlett2: Add correct product series name to messages
  (stable-fixes).
- ALSA: scarlett2: Add support for Clarett 8Pre USB
  (stable-fixes).
- ALSA: scarlett2: Move USB IDs out from device_info struct
  (stable-fixes).
- ALSA: scarlett2: Default mixer driver to enabled (stable-fixes).
- clk: Print an info line before disabling unused clocks
  (stable-fixes).
- drm/amdgpu: fix incorrect active rb bitmap for gfx11
  (stable-fixes).
- clk: remove extra empty line (stable-fixes).
- clk: Mark 'all_lists' as const (stable-fixes).
- commit 2a4676e

- i40e: Fix VF MAC filter removal (git-fixes).
- commit 03f8d56

- mmc: sdhci-msm: pervent access to suspended controller
  (git-fixes).
- fbdev: fix incorrect address computation in deferred IO
  (git-fixes).
- wifi: nl80211: don't free NULL coalescing rule (git-fixes).
- wifi: iwlwifi: mvm: return uid from iwl_mvm_build_scan_cmd
  (git-fixes).
- wifi: iwlwifi: mvm: remove old PASN station when adding a new
  one (git-fixes).
- Bluetooth: qca: fix NULL-deref on non-serdev suspend
  (git-fixes).
- NFC: trf7970a: disable all regulators on removal (git-fixes).
- HID: logitech-dj: allow mice to use all types of reports
  (git-fixes).
- HID: intel-ish-hid: ipc: Fix dev_err usage with uninitialized
  dev-&amp;gt;devc (git-fixes).
- init/main.c: Fix potential static_command_line memory overflow
  (git-fixes).
- ax25: fix use-after-free bugs caused by ax25_ds_del_timer
  (git-fixes).
- commit eb0d29c

- blacklist.conf: Add 246f80a0b17f8 (&amp;quot;sh: push-switch: Reorder cleanup operations to avoid use-after-free bug&amp;quot;)
- commit 701f2ea

- Update
  patches.suse/aoe-fix-the-potential-use-after-free-problem-in-aoec.patch
  (bsc#1218562 CVE-2023-6270 CVE-2024-26898 bsc#1223016).
- commit 5a56f33

- i40e: Do not allow untrusted VF to remove administratively
  set MAC (git-fixes CVE-2024-26830 bsc#1223012).
- commit 67a5cff

- net: ip_tunnel: make sure to pull inner header in
  ip_tunnel_rcv() (git-fixes CVE-2024-26882 bsc#1223034).
- commit 1915836

- PM / devfreq: Synchronize devfreq_monitor_[start/stop]
  (CVE-2023-52635 bsc#1222294).
- commit 6f88f1b

- powerpc/rtas: export rtas_error_rc() for reuse (bsc#1223369
  ltc#205888).
- powerpc/rtas: define pr_fmt and convert printk call sites
  (bsc#1223369 ltc#205888).
- commit 13f68b5

- Update
  patches.suse/Bluetooth-rfcomm-Fix-null-ptr-deref-in-rfcomm_check_.patch
  (bsc#1219170 CVE-2024-22099 CVE-2024-26903 bsc#1223187).
- commit 1a4ee0a

- Renamepatches before cve/linux-5.14-LTSS
- commit 0b096bb

- PCI: rpaphp: Error out on busy status from get-sensor-state
  (bsc#1223369 ltc#205888).
- commit f9716ef

- bpf: Fix stackmap overflow check on 32-bit arches (bsc#1223035
  CVE-2024-26883).
- bpf: Fix hashtab overflow check on 32-bit arches (bsc#1223189
  CVE-2024-26884).
- bpf: Fix DEVMAP_HASH overflow check on 32-bit arches
  (bsc#1223190 CVE-2024-26885).
- commit c435af8

- Update
  patches.suse/scsi-target-pscsi-Fix-bio_put-for-error-case.patch
  (bsc#1222596 cve-2024-26760), updating CVE number.
- commit 0b78c9a

- powerpc/kasan: Don't instrument non-maskable or raw interrupts
  (bsc#1223191).
- powerpc: Refactor verification of MSR_RI (bsc#1223191).
  - Refresh patches.suse/powerpc-64s-Fix-unrecoverable-MCE-calling-async-hand.patch
- commit 8a00767

- powerpc: Avoid nmi_enter/nmi_exit in real mode interrupt
  (bsc#1221645 ltc#205739 bsc#1223191).
- commit caf6e20

- comedi: vmk80xx: fix incomplete endpoint checking (git-fixes).
- mei: me: disable RPL-S on SPS and IGN firmwares (git-fixes).
- speakup: Avoid crash on very long word (git-fixes).
- serial/pmac_zilog: Remove flawed mitigation for rx irq flood
  (git-fixes).
- serial: mxs-auart: add spinlock around changing cts state
  (git-fixes).
- Revert &amp;quot;usb: cdc-wdm: close race between read and workqueue&amp;quot;
  (git-fixes).
- usb: dwc2: host: Fix dereference issue in DDMA completion flow
  (git-fixes).
- usb: typec: ucsi: Fix connector check on init (git-fixes).
- commit 28e1f50

- x86/cpufeatures: Fix dependencies for GFNI, VAES, and VPCLMULQDQ (git-fixes).
- commit e92aa40

- blacklist.conf: We don't support FRED
- commit ce7dd35

- clk: Remove prepare_lock hold assertion in __clk_release()
  (git-fixes).
- commit 7812d3f

- nilfs2: fix OOB in nilfs_set_de_type (git-fixes).
- commit 236cddf

- drm/panel: visionox-rm69299: don't unregister DSI device
  (git-fixes).
- drm/vmwgfx: Sort primary plane formats by order of preference
  (git-fixes).
- drm: nv04: Fix out of bounds access (git-fixes).
- nouveau: fix instmem race condition around ptr stores
  (git-fixes).
- drm/amdgpu: validate the parameters of bo mapping operations
  more clearly (git-fixes).
- nilfs2: fix OOB in nilfs_set_de_type (git-fixes).
- commit d2ecf52

- pmdomain: mediatek: fix race conditions with genpd
  (CVE-2023-52645 bsc#1223033).
- commit 9a65bfe

- spi: spi-fsl-lpspi: remove redundant spi_controller_put call
  (CVE-2024-26866 bsc#1223024).
- commit 1408e84

- spi: lpspi: Avoid potential use-after-free in probe()
  (CVE-2024-26866 bsc#1223024).
- commit 233d8aa

- platform/x86: think-lmi: Fix password opcode ordering for
  workstations (CVE-2024-26836 bsc#1222968).
- platform/x86: think-lmi: Enable opcode support on BIOS settings
  (CVE-2024-26836 bsc#1222968).
- commit 13fd3e3

- net: usb: ax88179_178a: avoid writing the mac address before
  first reading (git-fixes).
- drm/msm/dp: fix typo in dp_display_handle_port_status_changed()
  (git-fixes).
- drm/vmwgfx: Enable DMA mappings with SEV (git-fixes).
- drm/client: Fully protect modes[] with dev-&amp;gt;mode_config.mutex
  (stable-fixes).
- nouveau: fix function cast warning (git-fixes).
- Revert &amp;quot;drm/qxl: simplify qxl_fence_wait&amp;quot; (git-fixes).
- drm/ast: Fix soft lockup (git-fixes).
- drm/amd/display: fix disable otg wa logic in DCN316
  (stable-fixes).
- drm/amd/pm: fixes a random hang in S4 for SMU v13.0.4/11
  (stable-fixes).
- drm/amdgpu: Reset dGPU if suspend got aborted (stable-fixes).
- drm/amdgpu: always force full reset for SOC21 (stable-fixes).
- drm/amdkfd: Reset GPU on queue preemption failure
  (stable-fixes).
- drm/i915/vrr: Disable VRR when using bigjoiner (stable-fixes).
- drm/i915: Disable port sync when bigjoiner is used
  (stable-fixes).
- drm/i915/cdclk: Fix CDCLK programming order when pipes are
  active (git-fixes).
- Bluetooth: hci_sock: Fix not validating setsockopt user input
  (git-fixes).
- Bluetooth: L2CAP: Fix not validating setsockopt user input
  (git-fixes).
- Bluetooth: RFCOMM: Fix not validating setsockopt user input
  (git-fixes).
- Bluetooth: SCO: Fix not validating setsockopt user input
  (git-fixes).
- Bluetooth: Fix memory leak in hci_req_sync_complete()
  (git-fixes).
- batman-adv: Avoid infinite loop trying to resize local TT
  (git-fixes).
- platform/x86: intel-vbtn: Update tablet mode switch at end of
  probe (git-fixes).
- i2c: pxa: hide unused icr_bits[] variable (git-fixes).
- ALSA: hda/realtek - Fix inactive headset mic jack
  (stable-fixes).
- Bluetooth: Fix TOCTOU in HCI debugfs implementation (git-fixes).
- Bluetooth: hci_event: set the conn encrypted before conn
  establishes (stable-fixes).
- Bluetooth: add quirk for broken address properties (git-fixes).
- usb: typec: ucsi: Clear UCSI_CCI_RESET_COMPLETE before reset
  (stable-fixes).
- usb: typec: ucsi: Ack unsupported commands (stable-fixes).
- usb: udc: remove warning when queue disabled ep (stable-fixes).
- Revert &amp;quot;usb: phy: generic: Get the vbus supply&amp;quot; (git-fixes).
- USB: UAS: return ENODEV when submit urbs fail with device not
  attached (stable-fixes).
- wifi: mac80211: check/clear fast rx for non-4addr sta VLAN
  changes (stable-fixes).
- fbmon: prevent division by zero in fb_videomode_from_videomode()
  (stable-fixes).
- fbdev: viafb: fix typo in hw_bitblt_1 and hw_bitblt_2
  (stable-fixes).
- ASoC: soc-core.c: Skip dummy codec when adding platforms
  (stable-fixes).
- speakup: Fix 8bit characters from direct synth (git-fixes).
- USB: serial: cp210x: add pid/vid for TDK NC0110013M and
  MM0110113M (stable-fixes).
- USB: serial: option: add MeiG Smart SLM320 product
  (stable-fixes).
- USB: serial: cp210x: add ID for MGP Instruments PDS100
  (stable-fixes).
- USB: serial: add device ID for VeriFone adapter (stable-fixes).
- USB: serial: ftdi_sio: add support for GMC Z216C Adapter IR-USB
  (stable-fixes).
- usb: gadget: tegra-xudc: Fix USB3 PHY retrieval logic
  (git-fixes).
- phy: tegra: xusb: Add API to retrieve the port number of phy
  (stable-fixes).
- usb: sl811-hcd: only defined function checkdone if QUIRK2 is
  defined (stable-fixes).
- usb: typec: tcpci: add generic tcpci fallback compatible
  (stable-fixes).
- ahci: asm1064: asm1166: don't limit reported ports (git-fixes).
- Input: synaptics-rmi4 - fail probing if memory allocation for
  &amp;quot;phys&amp;quot; fails (stable-fixes).
- media: sta2x11: fix irq handler cast (stable-fixes).
- media: cec: core: remove length check of Timer Status
  (stable-fixes).
- ALSA: firewire-lib: handle quirk to calculate payload quadlets
  as data block counter (stable-fixes).
- Revert &amp;quot;ACPI: PM: Block ASUS B1400CEAE from suspend to idle
  by default&amp;quot; (stable-fixes).
- platform/x86: touchscreen_dmi: Add an extra entry for a variant
  of the Chuwi Vi8 tablet (stable-fixes).
- Input: allocate keycode for Display refresh rate toggle
  (stable-fixes).
- pinctrl: renesas: checker: Limit cfg reg enum checks to provided
  IDs (stable-fixes).
- drm/amd/display: Fix nanosec stat overflow (stable-fixes).
- drm: panel-orientation-quirks: Add quirk for GPD Win Mini
  (stable-fixes).
- drm/vc4: don't check if plane-&amp;gt;state-&amp;gt;fb == state-&amp;gt;fb
  (stable-fixes).
- hwmon: (amc6821) add of_match table (stable-fixes).
- Bluetooth: btintel: Fixe build regression (git-fixes).
- Bluetooth: btintel: Fix null ptr deref in btintel_read_version
  (stable-fixes).
- wifi: ath9k: fix LNA selection in ath_ant_try_scan()
  (stable-fixes).
- pstore/zone: Add a null pointer check to the psz_kmsg_read
  (stable-fixes).
- mei: me: add arrow lake point H DID (stable-fixes).
- mei: me: add arrow lake point S DID (stable-fixes).
- ahci: asm1064: correct count of reported ports (stable-fixes).
- Documentation: Add missing documentation for EXPORT_OP flags
  (stable-fixes).
- HID: uhid: Use READ_ONCE()/WRITE_ONCE() for -&amp;gt;running
  (stable-fixes).
- docs: Document the FAN_FS_ERROR event (stable-fixes).
- commit 5f4b68d

- Update
  patches.suse/fbcon-always-restore-the-old-font-data-in-fbcon_do_s.patch
  (git-fixes CVE-2024-26798 bsc#1222798).
- commit 3f5154a

- Update
  patches.suse/0001-fs-hugetlb-fix-NULL-pointer-dereference-in-hugetlbs_.patch
  (bsc#1219264 CVE-2024-0841 CVE-2024-26688 bsc#1222482).
- Update
  patches.suse/btrfs-fix-double-free-of-anonymous-device-after-snap.patch
  (bsc#1219126 CVE-2024-23850 CVE-2024-26792 bsc#1222430).
- Update
  patches.suse/net-sched-act_mirred-don-t-override-retval-if-we-alr.patch
  (CVE-2024-26733 bsc#1222585 CVE-2024-26739 bsc#1222559).
- commit ac0df3e

- Update
  patches.suse/ALSA-gus-fix-null-pointer-dereference-on-pointer-blo.patch
  (git-fixes CVE-2021-47207 bsc#1222790).
- Update
  patches.suse/ALSA-usb-audio-fix-null-pointer-dereference-on-point.patch
  (bsc#1192354 CVE-2021-47211 bsc#1222869).
- Update
  patches.suse/RDMA-core-Set-send-and-receive-CQ-before-forwarding-.patch
  (jsc#SLE-19249 CVE-2021-47196 bsc#1222773).
- Update
  patches.suse/arm64-dts-qcom-msm8998-Fix-CPU-L2-idle-state-latency.patch
  (git-fixes CVE-2021-47187 bsc#1222703).
- Update
  patches.suse/cfg80211-call-cfg80211_stop_ap-when-switch-from-P2P_.patch
  (git-fixes CVE-2021-47194 bsc#1222829).
- Update
  patches.suse/clk-sunxi-ng-Unregister-clocks-resets-when-unbinding.patch
  (git-fixes CVE-2021-47205 bsc#1222888).
- Update
  patches.suse/drm-prime-Fix-use-after-free-in-mmap-with-drm_gem_tt.patch
  (git-fixes CVE-2021-47200 bsc#1222838).
- Update
  patches.suse/i40e-Fix-NULL-ptr-dereference-on-VSI-filter-sync.patch
  (jsc#SLE-18378 CVE-2021-47184 bsc#1222666).
- Update
  patches.suse/iavf-free-q_vectors-before-queues-in-iavf_disable_vf.patch
  (jsc#SLE-18385 CVE-2021-47201 bsc#1222792).
- Update
  patches.suse/msft-hv-2480-x86-hyperv-Fix-NULL-deref-in-set_hv_tscchange_cb-if-.patch
  (git-fixes CVE-2021-47217 bsc#1222836).
- Update
  patches.suse/net-dpaa2-eth-fix-use-after-free-in-dpaa2_eth_remove.patch
  (git-fixes CVE-2021-47204 bsc#1222787).
- Update
  patches.suse/net-mlx5-Update-error-handler-for-UCTX-and-UMEM.patch
  (jsc#SLE-19253 CVE-2021-47212 bsc#1222709).
- Update
  patches.suse/net-mlx5e-CT-Fix-multiple-allocations-and-memleak-of.patch
  (jsc#SLE-19253 CVE-2021-47199 bsc#1222785).
- Update
  patches.suse/net-mlx5e-kTLS-Fix-crash-in-RX-resync-flow.patch
  (jsc#SLE-19253 CVE-2021-47215 bsc#1222704).
- Update
  patches.suse/net-mlx5e-nullify-cq-dbg-pointer-in-mlx5_debug_cq_re.patch
  (jsc#SLE-19253 CVE-2021-47197 bsc#1222776).
- Update
  patches.suse/sched-fair-Prevent-dead-task-groups-from-regaining-cfs_rq-s.patch
  (bsc#1192837 CVE-2021-47209 bsc#1222796).
- Update patches.suse/scsi-advansys-Fix-kernel-pointer-leak.patch
  (git-fixes CVE-2021-47216 bsc#1222876).
- Update
  patches.suse/scsi-core-sysfs-Fix-hang-when-device-state-is-set-via-sysfs
  (git-fixes CVE-2021-47192 bsc#1222867).
- Update
  patches.suse/scsi-lpfc-Fix-list_add-corruption-in-lpfc_drain_txq.patch
  (bsc#1190576 CVE-2021-47203 bsc#1222881).
- Update
  patches.suse/scsi-lpfc-Fix-use-after-free-in-lpfc_unreg_rpi-routi.patch
  (bsc#1192145 CVE-2021-47198 bsc#1222883).
- Update
  patches.suse/scsi-pm80xx-Fix-memory-leak-during-rmmod.patch
  (git-fixes CVE-2021-47193 bsc#1222879).
- Update
  patches.suse/scsi-scsi_debug-Fix-out-of-bound-read-in-resp_readcap16.patch
  (git-fixes CVE-2021-47191 bsc#1222866).
- Update
  patches.suse/scsi-scsi_debug-Fix-out-of-bound-read-in-resp_report_tgtpgs.patch
  (git-fixes CVE-2021-47219 bsc#1222824).
- Update patches.suse/scsi-ufs-core-Improve-SCSI-abort-handling
  (git-fixes CVE-2021-47188 bsc#1222671).
- Update
  patches.suse/selinux-fix-NULL-pointer-dereference-when-hashtab-al.patch
  (git-fixes CVE-2021-47218 bsc#1222791).
- Update
  patches.suse/thermal-Fix-NULL-pointer-dereferences-in-of_thermal_.patch
  (stable-5.14.21 CVE-2021-47202 bsc#1222878).
- Update
  patches.suse/tty-tty_buffer-Fix-the-softlockup-issue-in-flush_to_.patch
  (git-fixes CVE-2021-47185 bsc#1222669).
- Update
  patches.suse/usb-host-ohci-tmio-check-return-value-after-calling-.patch
  (git-fixes CVE-2021-47206 bsc#1222894).
- Update
  patches.suse/usb-typec-tipd-Remove-WARN_ON-in-tps6598x_block_read.patch
  (git-fixes CVE-2021-47210 bsc#1222901).
- commit 48b69db

- iommu/arm-smmu-v3: Work around MMU-600 erratum 1076982
  (git-fixes).
- Refresh
  patches.suse/coresight-etm-Override-TRCIDR3.CCITMIN-on-errata-affected-cpus.patch.
- commit d93f0f0

- Update
  patches.suse/wifi-mac80211-fix-race-condition-on-enabling-fast-xm.patch
  (git-fixes CVE-2024-26779 bsc#1222772).
- commit c8c8675

- wifi: wfx: fix possible NULL pointer dereference in
  wfx_set_mfp_ap() (CVE-2023-52593 bsc#1221042).
- commit 846e85e

- iommu/mediatek: Flush IOTLB completely only if domain has
  been attached (git-fixes).
- commit 623c929

- media: rkisp1: Fix IRQ disable race issue (CVE-2023-52589
  bsc#1221084).
- commit e4627b0

- iommu/amd: Fix domain flush size when syncing iotlb (git-fixes).
- commit b3bdbef

- Update patch reference of iio fix (CVE-2024-26702 bsc#1222424)
- commit 9b2027c

- iommu/amd: Don't block updates to GATag if guest mode is on
  (git-fixes).
- commit 9ffdfc7

- iommu/rockchip: Fix unwind goto issue (git-fixes).
- commit c8c9239

- wifi: iwlwifi: fix a memory corruption (CVE-2024-26610
  bsc#1221299).
- commit e7967c5

- iommu/sprd: Release dma buffer to avoid memory leak (git-fixes).
- commit 6d1aa27

- iommu/fsl: fix all kernel-doc warnings in fsl_pamu.c
  (git-fixes).
- commit 452d862

- iommu/arm-smmu-v3: Acknowledge pri/event queue overflow if  any
  (git-fixes).
- commit 161366f

- x86/xen: add CPU dependencies for 32-bit build (git-fixes).
- commit b3ada40

- xen/events: close evtchn after mapping cleanup (CVE-2024-26687,
  bsc#1222435).
- commit eb41ab9

- xen/xenbus: document will_handle argument for
  xenbus_watch_path() (git-fixes).
- commit c749895

- blacklist.conf: Append 'drm/amdgpu: Fix variable 'mca_funcs' dereferenced before NULL check in 'amdgpu_mca_smu_get_mca_entry()''
- commit f765ec7

- Update patches.suse/arp-Prevent-overflow-in-arp_req_get.patch
- fix build warning
- commit b98055d

- blacklist.conf: Append 'drm/amd/display: Fix 'panel_cntl' could be null in 'dcn21_set_backlight_level()''
- commit 182dade

- ceph: stop copying to iter at EOF on sync reads (bsc#1223068).
- libceph: init the cursor when preparing sparse read in msgr2
  (bsc#1222247 CVE-2023-52636).
- ceph: switch to corrected encoding of max_xattr_size in mdsmap
  (bsc#1223067).
- libceph: just wait for more data to be available on the socket
  (bsc#1222247 CVE-2023-52636).
- libceph: rename read_sparse_msg_*() to
  read_partial_sparse_msg_*() (bsc#1222247 CVE-2023-52636).
- commit c683288

- serial: sc16is7xx: convert from _raw_ to _noinc_ regmap
  functions for FIFO (bsc#1221162 CVE-2023-52488).
- commit 0ac4803

- iommu/arm-smmu-qcom: Limit the SMR groups to 128 (git-fixes).
- commit aa65491

Package less was updated:

- Fix CVE-2024-32487, mishandling of \n character in paths when  LESSOPEN is set leads to OS command execution
  (CVE-2024-32487, bsc#1222849)
  * CVE-2024-32487.patch

Package util-linux was updated:

- lscpu: Add more ARM cores (bsc#1223605,  util-linux-lscpu-add-more-ARM-cores-1.patch,
  util-linux-lscpu-add-more-ARM-cores-2.patch,
  util-linux-lscpu-add-more-ARM-cores-3.patch,
  util-linux-lscpu-add-more-ARM-cores-4.patch,
  util-linux-lscpu-add-more-ARM-cores-5.patch,
  util-linux-lscpu-add-more-ARM-cores-6.patch).

- Document that chcpu -g is not supported on IBM z/VM (bsc#1218609,
  util-linux-chcpu-document-zVM-limitations.patch).

- bsc#1220117: Processes not cleaned up after failed SSH session are using up 100% CPU
  + util-linux-more-exit-if-POLLERR-and-POLLHUP-on-stdin-is-received.patch

Package glib2 was updated:

- Add patches to fix CVE-2024-34397 (boo#1224044):  glib2-CVE-2024-34397.patch (glgo#GNOME/glib#3268).
  glib2-fix-ibus-regression.patch (glgo#GNOME/glib#3353)

Package openssl-1_1 was updated:

- Security fix: [bsc#1222548, CVE-2024-2511]  * Fix unconstrained session cache growth in TLSv1.3
  * Add openssl-CVE-2024-2511.patch

Package tpm2-0-tss was updated:

- add 0001-FAPI-Fix-check-of-magic-number-in-verify-quote.patch: fixes  CVE-2024-29040 (bsc#1223690): Missing verification of the magic number in
  Fapi_VerifyQuote(), which might allow an attacker to generate arbitrary
  quote data, which would not be detected by Fapi_VerifyQuote().

Package perl was updated:

- fix space calculation issues in pp_pack.c [bnc#1082216]  [CVE-2018-6913]
  * new patch: perl-pack-overflow.diff
- fix heap buffer overflow in regexec.c [bnc#1082233]
  [CVE-2018-6798]
  new patch: perl-regexec-heap-overflow.diff
- make Net::FTP work with TLS 1.3 [bnc#1213638]
  new patch: perl-net-ftp-tls13.diff

Package 000release-packages:sle-module-basesystem-release was updated:

Package 000release-packages:sle-module-containers-release was updated:

Package 000release-packages:sle-module-public-cloud-release was updated:

Package 000release-packages:sle-module-server-applications-release was updated:

Package 000release-packages:SLES-release was updated:

Package suseconnect-ng was updated:

- Update to version 1.9.0  * Fix certificate import for Yast when using a registration proxy with
    self-signed SSL certificate (bsc#1223107)

Package systemd-presets-branding-SLE was updated:

Package tpm2.0-tools was updated:

- Add 0001-tpm2_checkquote-Fix-check-of-magic-number.patch: tpm2_checkquote  did not check whether the magic number in the attest is equal to
  TPM2_GENERATED_VALUE, which might allow a malicious actor to generate
  arbitrary quote data, undetected by tpm2_checkquote (bsc#1223687, CVE-2024-29038).
- Add 0001-tpm2_checkquote-Add-comparison-of-pcr-selection.patch:
  tpm2_checkquote did not compare the --pcr parameter passed to the tool with
  the attest. A malicious actor might thus be able to fake a valid
  attestation (bsc#1223689, CVE-2024-29039).

Package util-linux-systemd was updated:

- lscpu: Add more ARM cores (bsc#1223605,  util-linux-lscpu-add-more-ARM-cores-1.patch,
  util-linux-lscpu-add-more-ARM-cores-2.patch,
  util-linux-lscpu-add-more-ARM-cores-3.patch,
  util-linux-lscpu-add-more-ARM-cores-4.patch,
  util-linux-lscpu-add-more-ARM-cores-5.patch,
  util-linux-lscpu-add-more-ARM-cores-6.patch).

- Document that chcpu -g is not supported on IBM z/VM (bsc#1218609,
  util-linux-chcpu-document-zVM-limitations.patch).

- bsc#1220117: Processes not cleaned up after failed SSH session are using up 100% CPU
  + util-linux-more-exit-if-POLLERR-and-POLLHUP-on-stdin-is-received.patch

Package wicked was updated:

- client: fix ifreload to pull UP ports/links again when the config  of their master/lower changed (bsc#1224100,gh#openSUSE/wicked#1014).
  [+ 0001-ifreload-pull-UP-again-on-master-lower-changes-bsc1224100.patch]

- Update to version 0.6.75:
  - cleanup: fix ni_fsm_state_t enum-int-mismatch warnings
  - cleanup: fix overflow warnings in a socket testcase on i586
  - ifcheck: report new and deleted configs as changed (bsc#1218926)
  - man: improve ARP configuration options in the wicked-config.5
  - bond: add ports when master is UP to avoid port MTU revert (bsc#1219108)
  - cleanup: fix interface dependencies and shutdown order (bsc#1205604)
  - Remove port arrays from bond,team,bridge,ovs-bridge (redundant)
    and consistently use config and state info attached to the port
    interface as in rtnetlink(7).
  - Cleanup ifcfg parsing, schema configuration and service properties
  - Migrate ports in xml config and policies already applied in nanny
  - Remove &amp;quot;missed config&amp;quot; generation from finite state machine, which
    is completed while parsing the config or while xml config migration.
  - Issue a warning when &amp;quot;lower&amp;quot; interface (e.g. eth0) config is missed
    while parsing config depending on it (e.g. eth0.42 vlan).
  - Resolve ovs master to the effective bridge in config and wickedd
  - Implement netif-check-state require checks using system relations
    from wickedd/kernel instead of config relations for ifdown and add
    linkDown and deleteDevice checks to all master and lower references.
  - Add a `wicked &amp;lt;ifup|ifdown|ifreload&amp;gt; --dry-run â¦` option to show the
    system/config interface hierarchies as notice with +/- marked
    interfaces to setup and/or shutdown.
- Removed patches included in the source archive:
  [- 0001-addrconf-fix-fallback-lease-drop-bsc-1220996.patch]
  [- 0002-extensions-nbft-replace-nvme-show-nbft-with-nvme-nbf.patch]
  [- 0003-move-all-attribute-definitions-to-compiler-h.patch]
  [- 0004-hide-secrets-in-debug-log-bsc-1221194.patch]
  [- 0005-client-do-to-not-convert-sec-to-msec-twice-bsc-1222105.patch]

</Note>
    <Note Title="Terms of Use" Type="Legal Disclaimer" Ordinal="3" xml:lang="en">The CVRF data is provided by SUSE under the Creative Commons License 4.0 with Attribution (CC-BY-4.0).</Note>
  </DocumentNotes>
  <DocumentReferences>
    <Reference Type="Self">
      <URL>https://publiccloudimagechangeinfo.suse.com/google/sles-15-sp5-chost-byos-v20240529-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-15-sp5-chost-byos-v20240529-x86-64">
      <Branch Type="Product Name" Name="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
        <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
      </Branch>
    </Branch>
    <Branch Type="Product Version" Name="catatonit-0.2.0-150500.3.3.1">
      <FullProductName ProductID="catatonit-0.2.0-150500.3.3.1">catatonit-0.2.0-150500.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="coreutils-8.32-150400.9.6.1">
      <FullProductName ProductID="coreutils-8.32-150400.9.6.1">coreutils-8.32-150400.9.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="e2fsprogs-1.46.4-150400.3.6.2">
      <FullProductName ProductID="e2fsprogs-1.46.4-150400.3.6.2">e2fsprogs-1.46.4-150400.3.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kdump-1.0.2+git47.g28549ab-150500.3.6.1">
      <FullProductName ProductID="kdump-1.0.2+git47.g28549ab-150500.3.6.1">kdump-1.0.2+git47.g28549ab-150500.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kernel-default-5.14.21-150500.55.65.1">
      <FullProductName ProductID="kernel-default-5.14.21-150500.55.65.1">kernel-default-5.14.21-150500.55.65.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="less-590-150400.3.9.1">
      <FullProductName ProductID="less-590-150400.3.9.1">less-590-150400.3.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libblkid1-2.37.4-150500.9.11.1">
      <FullProductName ProductID="libblkid1-2.37.4-150500.9.11.1">libblkid1-2.37.4-150500.9.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libcom_err2-1.46.4-150400.3.6.2">
      <FullProductName ProductID="libcom_err2-1.46.4-150400.3.6.2">libcom_err2-1.46.4-150400.3.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libext2fs2-1.46.4-150400.3.6.2">
      <FullProductName ProductID="libext2fs2-1.46.4-150400.3.6.2">libext2fs2-1.46.4-150400.3.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libfdisk1-2.37.4-150500.9.11.1">
      <FullProductName ProductID="libfdisk1-2.37.4-150500.9.11.1">libfdisk1-2.37.4-150500.9.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libglib-2_0-0-2.70.5-150400.3.11.1">
      <FullProductName ProductID="libglib-2_0-0-2.70.5-150400.3.11.1">libglib-2_0-0-2.70.5-150400.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libmount1-2.37.4-150500.9.11.1">
      <FullProductName ProductID="libmount1-2.37.4-150500.9.11.1">libmount1-2.37.4-150500.9.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libopenssl1_1-1.1.1l-150500.17.28.2">
      <FullProductName ProductID="libopenssl1_1-1.1.1l-150500.17.28.2">libopenssl1_1-1.1.1l-150500.17.28.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libprotobuf-lite25_1_0-25.1-150400.9.6.1">
      <FullProductName ProductID="libprotobuf-lite25_1_0-25.1-150400.9.6.1">libprotobuf-lite25_1_0-25.1-150400.9.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsmartcols1-2.37.4-150500.9.11.1">
      <FullProductName ProductID="libsmartcols1-2.37.4-150500.9.11.1">libsmartcols1-2.37.4-150500.9.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libtss2-esys0-3.1.0-150400.3.6.1">
      <FullProductName ProductID="libtss2-esys0-3.1.0-150400.3.6.1">libtss2-esys0-3.1.0-150400.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libtss2-fapi1-3.1.0-150400.3.6.1">
      <FullProductName ProductID="libtss2-fapi1-3.1.0-150400.3.6.1">libtss2-fapi1-3.1.0-150400.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libtss2-mu0-3.1.0-150400.3.6.1">
      <FullProductName ProductID="libtss2-mu0-3.1.0-150400.3.6.1">libtss2-mu0-3.1.0-150400.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libtss2-rc0-3.1.0-150400.3.6.1">
      <FullProductName ProductID="libtss2-rc0-3.1.0-150400.3.6.1">libtss2-rc0-3.1.0-150400.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libtss2-sys1-3.1.0-150400.3.6.1">
      <FullProductName ProductID="libtss2-sys1-3.1.0-150400.3.6.1">libtss2-sys1-3.1.0-150400.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libtss2-tctildr0-3.1.0-150400.3.6.1">
      <FullProductName ProductID="libtss2-tctildr0-3.1.0-150400.3.6.1">libtss2-tctildr0-3.1.0-150400.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libuuid1-2.37.4-150500.9.11.1">
      <FullProductName ProductID="libuuid1-2.37.4-150500.9.11.1">libuuid1-2.37.4-150500.9.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssl-1_1-1.1.1l-150500.17.28.2">
      <FullProductName ProductID="openssl-1_1-1.1.1l-150500.17.28.2">openssl-1_1-1.1.1l-150500.17.28.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="perl-5.26.1-150300.17.17.1">
      <FullProductName ProductID="perl-5.26.1-150300.17.17.1">perl-5.26.1-150300.17.17.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="perl-base-5.26.1-150300.17.17.1">
      <FullProductName ProductID="perl-base-5.26.1-150300.17.17.1">perl-base-5.26.1-150300.17.17.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="rpm-ndb-4.14.3-150400.59.16.1">
      <FullProductName ProductID="rpm-ndb-4.14.3-150400.59.16.1">rpm-ndb-4.14.3-150400.59.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suseconnect-ng-1.9.0-150500.3.21.2">
      <FullProductName ProductID="suseconnect-ng-1.9.0-150500.3.21.2">suseconnect-ng-1.9.0-150500.3.21.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-presets-branding-SLE-15.1-150100.20.14.1">
      <FullProductName ProductID="systemd-presets-branding-SLE-15.1-150100.20.14.1">systemd-presets-branding-SLE-15.1-150100.20.14.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="tpm2.0-tools-5.2-150400.6.3.1">
      <FullProductName ProductID="tpm2.0-tools-5.2-150400.6.3.1">tpm2.0-tools-5.2-150400.6.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="util-linux-2.37.4-150500.9.11.1">
      <FullProductName ProductID="util-linux-2.37.4-150500.9.11.1">util-linux-2.37.4-150500.9.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="util-linux-systemd-2.37.4-150500.9.11.1">
      <FullProductName ProductID="util-linux-systemd-2.37.4-150500.9.11.1">util-linux-systemd-2.37.4-150500.9.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="wicked-0.6.75-150500.3.26.1">
      <FullProductName ProductID="wicked-0.6.75-150500.3.26.1">wicked-0.6.75-150500.3.26.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="wicked-service-0.6.75-150500.3.26.1">
      <FullProductName ProductID="wicked-service-0.6.75-150500.3.26.1">wicked-service-0.6.75-150500.3.26.1</FullProductName>
    </Branch>
    <Relationship ProductReference="catatonit-0.2.0-150500.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:catatonit-0.2.0-150500.3.3.1">catatonit-0.2.0-150500.3.3.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="coreutils-8.32-150400.9.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:coreutils-8.32-150400.9.6.1">coreutils-8.32-150400.9.6.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="e2fsprogs-1.46.4-150400.3.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:e2fsprogs-1.46.4-150400.3.6.2">e2fsprogs-1.46.4-150400.3.6.2 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kdump-1.0.2+git47.g28549ab-150500.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kdump-1.0.2+git47.g28549ab-150500.3.6.1">kdump-1.0.2+git47.g28549ab-150500.3.6.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kernel-default-5.14.21-150500.55.65.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1">kernel-default-5.14.21-150500.55.65.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="less-590-150400.3.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:less-590-150400.3.9.1">less-590-150400.3.9.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libblkid1-2.37.4-150500.9.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:libblkid1-2.37.4-150500.9.11.1">libblkid1-2.37.4-150500.9.11.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libcom_err2-1.46.4-150400.3.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:libcom_err2-1.46.4-150400.3.6.2">libcom_err2-1.46.4-150400.3.6.2 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libext2fs2-1.46.4-150400.3.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:libext2fs2-1.46.4-150400.3.6.2">libext2fs2-1.46.4-150400.3.6.2 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libfdisk1-2.37.4-150500.9.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:libfdisk1-2.37.4-150500.9.11.1">libfdisk1-2.37.4-150500.9.11.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libglib-2_0-0-2.70.5-150400.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:libglib-2_0-0-2.70.5-150400.3.11.1">libglib-2_0-0-2.70.5-150400.3.11.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libmount1-2.37.4-150500.9.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:libmount1-2.37.4-150500.9.11.1">libmount1-2.37.4-150500.9.11.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libopenssl1_1-1.1.1l-150500.17.28.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:libopenssl1_1-1.1.1l-150500.17.28.2">libopenssl1_1-1.1.1l-150500.17.28.2 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libprotobuf-lite25_1_0-25.1-150400.9.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:libprotobuf-lite25_1_0-25.1-150400.9.6.1">libprotobuf-lite25_1_0-25.1-150400.9.6.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsmartcols1-2.37.4-150500.9.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:libsmartcols1-2.37.4-150500.9.11.1">libsmartcols1-2.37.4-150500.9.11.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libtss2-esys0-3.1.0-150400.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:libtss2-esys0-3.1.0-150400.3.6.1">libtss2-esys0-3.1.0-150400.3.6.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libtss2-fapi1-3.1.0-150400.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:libtss2-fapi1-3.1.0-150400.3.6.1">libtss2-fapi1-3.1.0-150400.3.6.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libtss2-mu0-3.1.0-150400.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:libtss2-mu0-3.1.0-150400.3.6.1">libtss2-mu0-3.1.0-150400.3.6.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libtss2-rc0-3.1.0-150400.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:libtss2-rc0-3.1.0-150400.3.6.1">libtss2-rc0-3.1.0-150400.3.6.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libtss2-sys1-3.1.0-150400.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:libtss2-sys1-3.1.0-150400.3.6.1">libtss2-sys1-3.1.0-150400.3.6.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libtss2-tctildr0-3.1.0-150400.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:libtss2-tctildr0-3.1.0-150400.3.6.1">libtss2-tctildr0-3.1.0-150400.3.6.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libuuid1-2.37.4-150500.9.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:libuuid1-2.37.4-150500.9.11.1">libuuid1-2.37.4-150500.9.11.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssl-1_1-1.1.1l-150500.17.28.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:openssl-1_1-1.1.1l-150500.17.28.2">openssl-1_1-1.1.1l-150500.17.28.2 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="perl-5.26.1-150300.17.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:perl-5.26.1-150300.17.17.1">perl-5.26.1-150300.17.17.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="perl-base-5.26.1-150300.17.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:perl-base-5.26.1-150300.17.17.1">perl-base-5.26.1-150300.17.17.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="rpm-ndb-4.14.3-150400.59.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:rpm-ndb-4.14.3-150400.59.16.1">rpm-ndb-4.14.3-150400.59.16.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suseconnect-ng-1.9.0-150500.3.21.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:suseconnect-ng-1.9.0-150500.3.21.2">suseconnect-ng-1.9.0-150500.3.21.2 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-presets-branding-SLE-15.1-150100.20.14.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:systemd-presets-branding-SLE-15.1-150100.20.14.1">systemd-presets-branding-SLE-15.1-150100.20.14.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="tpm2.0-tools-5.2-150400.6.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:tpm2.0-tools-5.2-150400.6.3.1">tpm2.0-tools-5.2-150400.6.3.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="util-linux-2.37.4-150500.9.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:util-linux-2.37.4-150500.9.11.1">util-linux-2.37.4-150500.9.11.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="util-linux-systemd-2.37.4-150500.9.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:util-linux-systemd-2.37.4-150500.9.11.1">util-linux-systemd-2.37.4-150500.9.11.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="wicked-0.6.75-150500.3.26.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:wicked-0.6.75-150500.3.26.1">wicked-0.6.75-150500.3.26.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="wicked-service-0.6.75-150500.3.26.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:wicked-service-0.6.75-150500.3.26.1">wicked-service-0.6.75-150500.3.26.1 as a component of Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-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">An issue was discovered in Perl 5.22 through 5.26. Matching a crafted locale dependent regular expression can cause a heap-based buffer over-read and potentially information disclosure.</Note>
    </Notes>
    <CVE>CVE-2018-6798</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:perl-5.26.1-150300.17.17.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:perl-base-5.26.1-150300.17.17.1</ProductID>
      </Status>
    </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">Heap-based buffer overflow in the pack function in Perl before 5.26.2 allows context-dependent attackers to execute arbitrary code via a large item count.</Note>
    </Notes>
    <CVE>CVE-2018-6913</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:perl-5.26.1-150300.17.17.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:perl-base-5.26.1-150300.17.17.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>7.5</BaseScore>
        <Vector>AV:N/AC:L/Au:N/C:P/I:P/A:P</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

spi: spi-zynqmp-gqspi: return -ENOMEM if dma_map_single fails

The spi controller supports 44-bit address space on AXI in DMA mode,
so set dma_addr_t width to 44-bit to avoid using a swiotlb mapping.
In addition, if dma_map_single fails, it should return immediately
instead of continuing doing the DMA operation which bases on invalid
address.

This fixes the following crash which occurs in reading a big block
from flash:

[  123.633577] zynqmp-qspi ff0f0000.spi: swiotlb buffer is full (sz: 4194304 bytes), total 32768 (slots), used 0 (slots)
[  123.644230] zynqmp-qspi ff0f0000.spi: ERR:rxdma:memory not mapped
[  123.784625] Unable to handle kernel paging request at virtual address 00000000003fffc0
[  123.792536] Mem abort info:
[  123.795313]   ESR = 0x96000145
[  123.798351]   EC = 0x25: DABT (current EL), IL = 32 bits
[  123.803655]   SET = 0, FnV = 0
[  123.806693]   EA = 0, S1PTW = 0
[  123.809818] Data abort info:
[  123.812683]   ISV = 0, ISS = 0x00000145
[  123.816503]   CM = 1, WnR = 1
[  123.819455] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000805047000
[  123.825887] [00000000003fffc0] pgd=0000000803b45003, p4d=0000000803b45003, pud=0000000000000000
[  123.834586] Internal error: Oops: 96000145 [#1] PREEMPT SMP</Note>
    </Notes>
    <CVE>CVE-2021-47047</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 NULL ptr dereference on VSI filter sync

Remove the reason of null pointer dereference in sync VSI filters.
Added new I40E_VSI_RELEASING flag to signalize deleting and releasing
of VSI resources to sync this thread with sync filters subtask.
Without this patch it is possible to start update the VSI filter list
after VSI is removed, that's causing a kernel oops.</Note>
    </Notes>
    <CVE>CVE-2021-47184</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: tty_buffer: Fix the softlockup issue in flush_to_ldisc

When running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup,
which look like this one:

  Workqueue: events_unbound flush_to_ldisc
  Call trace:
   dump_backtrace+0x0/0x1ec
   show_stack+0x24/0x30
   dump_stack+0xd0/0x128
   panic+0x15c/0x374
   watchdog_timer_fn+0x2b8/0x304
   __run_hrtimer+0x88/0x2c0
   __hrtimer_run_queues+0xa4/0x120
   hrtimer_interrupt+0xfc/0x270
   arch_timer_handler_phys+0x40/0x50
   handle_percpu_devid_irq+0x94/0x220
   __handle_domain_irq+0x88/0xf0
   gic_handle_irq+0x84/0xfc
   el1_irq+0xc8/0x180
   slip_unesc+0x80/0x214 [slip]
   tty_ldisc_receive_buf+0x64/0x80
   tty_port_default_receive_buf+0x50/0x90
   flush_to_ldisc+0xbc/0x110
   process_one_work+0x1d4/0x4b0
   worker_thread+0x180/0x430
   kthread+0x11c/0x120

In the testcase pty04, The first process call the write syscall to send
data to the pty master. At the same time, the workqueue will do the
flush_to_ldisc to pop data in a loop until there is no more data left.
When the sender and workqueue running in different core, the sender sends
data fastly in full time which will result in workqueue doing work in loop
for a long time and occuring softlockup in flush_to_ldisc with kernel
configured without preempt. So I add need_resched check and cond_resched
in the flush_to_ldisc loop to avoid it.</Note>
    </Notes>
    <CVE>CVE-2021-47185</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: dts: qcom: msm8998: Fix CPU/L2 idle state latency and residency

The entry/exit latency and minimum residency in state for the idle
states of MSM8998 were ..bad: first of all, for all of them the
timings were written for CPU sleep but the min-residency-us param
was miscalculated (supposedly, while porting this from downstream);
Then, the power collapse states are setting PC on both the CPU
cluster *and* the L2 cache, which have different timings: in the
specific case of L2 the times are higher so these ones should be
taken into account instead of the CPU ones.

This parameter misconfiguration was not giving particular issues
because on MSM8998 there was no CPU scaling at all, so cluster/L2
power collapse was rarely (if ever) hit.
When CPU scaling is enabled, though, the wrong timings will produce
SoC unstability shown to the user as random, apparently error-less,
sudden reboots and/or lockups.

This set of parameters are stabilizing the SoC when CPU scaling is
ON and when power collapse is frequently hit.</Note>
    </Notes>
    <CVE>CVE-2021-47187</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: ufs: core: Improve SCSI abort handling

The following has been observed on a test setup:

WARNING: CPU: 4 PID: 250 at drivers/scsi/ufs/ufshcd.c:2737 ufshcd_queuecommand+0x468/0x65c
Call trace:
 ufshcd_queuecommand+0x468/0x65c
 scsi_send_eh_cmnd+0x224/0x6a0
 scsi_eh_test_devices+0x248/0x418
 scsi_eh_ready_devs+0xc34/0xe58
 scsi_error_handler+0x204/0x80c
 kthread+0x150/0x1b4
 ret_from_fork+0x10/0x30

That warning is triggered by the following statement:

	WARN_ON(lrbp-&gt;cmd);

Fix this warning by clearing lrbp-&gt;cmd from the abort handler.</Note>
    </Notes>
    <CVE>CVE-2021-47188</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: scsi_debug: Fix out-of-bound read in resp_readcap16()

The following warning was observed running syzkaller:

[ 3813.830724] sg_write: data in/out 65466/242 bytes for SCSI command 0x9e-- guessing data in;
[ 3813.830724]    program syz-executor not setting count and/or reply_len properly
[ 3813.836956] ==================================================================
[ 3813.839465] BUG: KASAN: stack-out-of-bounds in sg_copy_buffer+0x157/0x1e0
[ 3813.841773] Read of size 4096 at addr ffff8883cf80f540 by task syz-executor/1549
[ 3813.846612] Call Trace:
[ 3813.846995]  dump_stack+0x108/0x15f
[ 3813.847524]  print_address_description+0xa5/0x372
[ 3813.848243]  kasan_report.cold+0x236/0x2a8
[ 3813.849439]  check_memory_region+0x240/0x270
[ 3813.850094]  memcpy+0x30/0x80
[ 3813.850553]  sg_copy_buffer+0x157/0x1e0
[ 3813.853032]  sg_copy_from_buffer+0x13/0x20
[ 3813.853660]  fill_from_dev_buffer+0x135/0x370
[ 3813.854329]  resp_readcap16+0x1ac/0x280
[ 3813.856917]  schedule_resp+0x41f/0x1630
[ 3813.858203]  scsi_debug_queuecommand+0xb32/0x17e0
[ 3813.862699]  scsi_dispatch_cmd+0x330/0x950
[ 3813.863329]  scsi_request_fn+0xd8e/0x1710
[ 3813.863946]  __blk_run_queue+0x10b/0x230
[ 3813.864544]  blk_execute_rq_nowait+0x1d8/0x400
[ 3813.865220]  sg_common_write.isra.0+0xe61/0x2420
[ 3813.871637]  sg_write+0x6c8/0xef0
[ 3813.878853]  __vfs_write+0xe4/0x800
[ 3813.883487]  vfs_write+0x17b/0x530
[ 3813.884008]  ksys_write+0x103/0x270
[ 3813.886268]  __x64_sys_write+0x77/0xc0
[ 3813.886841]  do_syscall_64+0x106/0x360
[ 3813.887415]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

This issue can be reproduced with the following syzkaller log:

r0 = openat(0xffffffffffffff9c, &amp;(0x7f0000000040)='./file0\x00', 0x26e1, 0x0)
r1 = syz_open_procfs(0xffffffffffffffff, &amp;(0x7f0000000000)='fd/3\x00')
open_by_handle_at(r1, &amp;(0x7f00000003c0)=ANY=[@ANYRESHEX], 0x602000)
r2 = syz_open_dev$sg(&amp;(0x7f0000000000), 0x0, 0x40782)
write$binfmt_aout(r2, &amp;(0x7f0000000340)=ANY=[@ANYBLOB="00000000deff000000000000000000000000000000000000000000000000000047f007af9e107a41ec395f1bded7be24277a1501ff6196a83366f4e6362bc0ff2b247f68a972989b094b2da4fb3607fcf611a22dd04310d28c75039d"], 0x126)

In resp_readcap16() we get "int alloc_len" value -1104926854, and then pass
the huge arr_len to fill_from_dev_buffer(), but arr is only 32 bytes. This
leads to OOB in sg_copy_buffer().

To solve this issue, define alloc_len as u32.</Note>
    </Notes>
    <CVE>CVE-2021-47191</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: core: sysfs: Fix hang when device state is set via sysfs

This fixes a regression added with:

commit f0f82e2476f6 ("scsi: core: Fix capacity set to zero after
offlinining device")

The problem is that after iSCSI recovery, iscsid will call into the kernel
to set the dev's state to running, and with that patch we now call
scsi_rescan_device() with the state_mutex held. If the SCSI error handler
thread is just starting to test the device in scsi_send_eh_cmnd() then it's
going to try to grab the state_mutex.

We are then stuck, because when scsi_rescan_device() tries to send its I/O
scsi_queue_rq() calls -&gt; scsi_host_queue_ready() -&gt; scsi_host_in_recovery()
which will return true (the host state is still in recovery) and I/O will
just be requeued. scsi_send_eh_cmnd() will then never be able to grab the
state_mutex to finish error handling.

To prevent the deadlock move the rescan-related code to after we drop the
state_mutex.

This also adds a check for if we are already in the running state. This
prevents extra scans and helps the iscsid case where if the transport class
has already onlined the device during its recovery process then we don't
need userspace to do it again plus possibly block that daemon.</Note>
    </Notes>
    <CVE>CVE-2021-47192</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 memory leak during rmmod

Driver failed to release all memory allocated. This would lead to memory
leak during driver removal.

Properly free memory when the module is removed.</Note>
    </Notes>
    <CVE>CVE-2021-47193</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cfg80211: call cfg80211_stop_ap when switch from P2P_GO type

If the userspace tools switch from NL80211_IFTYPE_P2P_GO to
NL80211_IFTYPE_ADHOC via send_msg(NL80211_CMD_SET_INTERFACE), it
does not call the cleanup cfg80211_stop_ap(), this leads to the
initialization of in-use data. For example, this path re-init the
sdata-&gt;assigned_chanctx_list while it is still an element of
assigned_vifs list, and makes that linked list corrupt.</Note>
    </Notes>
    <CVE>CVE-2021-47194</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/core: Set send and receive CQ before forwarding to the driver

Preset both receive and send CQ pointers prior to call to the drivers and
overwrite it later again till the mlx4 is going to be changed do not
overwrite ibqp properties.

This change is needed for mlx5, because in case of QP creation failure, it
will go to the path of QP destroy which relies on proper CQ pointers.

 BUG: KASAN: use-after-free in create_qp.cold+0x164/0x16e [mlx5_ib]
 Write of size 8 at addr ffff8880064c55c0 by task a.out/246

 CPU: 0 PID: 246 Comm: a.out Not tainted 5.15.0+ #291
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
 Call Trace:
  dump_stack_lvl+0x45/0x59
  print_address_description.constprop.0+0x1f/0x140
  kasan_report.cold+0x83/0xdf
  create_qp.cold+0x164/0x16e [mlx5_ib]
  mlx5_ib_create_qp+0x358/0x28a0 [mlx5_ib]
  create_qp.part.0+0x45b/0x6a0 [ib_core]
  ib_create_qp_user+0x97/0x150 [ib_core]
  ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs]
  ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs]
  ib_uverbs_ioctl+0x169/0x260 [ib_uverbs]
  __x64_sys_ioctl+0x866/0x14d0
  do_syscall_64+0x3d/0x90
  entry_SYSCALL_64_after_hwframe+0x44/0xae

 Allocated by task 246:
  kasan_save_stack+0x1b/0x40
  __kasan_kmalloc+0xa4/0xd0
  create_qp.part.0+0x92/0x6a0 [ib_core]
  ib_create_qp_user+0x97/0x150 [ib_core]
  ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs]
  ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs]
  ib_uverbs_ioctl+0x169/0x260 [ib_uverbs]
  __x64_sys_ioctl+0x866/0x14d0
  do_syscall_64+0x3d/0x90
  entry_SYSCALL_64_after_hwframe+0x44/0xae

 Freed by task 246:
  kasan_save_stack+0x1b/0x40
  kasan_set_track+0x1c/0x30
  kasan_set_free_info+0x20/0x30
  __kasan_slab_free+0x10c/0x150
  slab_free_freelist_hook+0xb4/0x1b0
  kfree+0xe7/0x2a0
  create_qp.part.0+0x52b/0x6a0 [ib_core]
  ib_create_qp_user+0x97/0x150 [ib_core]
  ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs]
  ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs]
  ib_uverbs_ioctl+0x169/0x260 [ib_uverbs]
  __x64_sys_ioctl+0x866/0x14d0
  do_syscall_64+0x3d/0x90
  entry_SYSCALL_64_after_hwframe+0x44/0xae</Note>
    </Notes>
    <CVE>CVE-2021-47196</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: nullify cq-&gt;dbg pointer in mlx5_debug_cq_remove()

Prior to this patch in case mlx5_core_destroy_cq() failed it proceeds
to rest of destroy operations. mlx5_core_destroy_cq() could be called again
by user and cause additional call of mlx5_debug_cq_remove().
cq-&gt;dbg was not nullify in previous call and cause the crash.

Fix it by nullify cq-&gt;dbg pointer after removal.

Also proceed to destroy operations only if FW return 0
for MLX5_CMD_OP_DESTROY_CQ command.

general protection fault, probably for non-canonical address 0x2000300004058: 0000 [#1] SMP PTI
CPU: 5 PID: 1228 Comm: python Not tainted 5.15.0-rc5_for_upstream_min_debug_2021_10_14_11_06 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:lockref_get+0x1/0x60
Code: 5d e9 53 ff ff ff 48 8d 7f 70 e8 0a 2e 48 00 c7 85 d0 00 00 00 02
00 00 00 c6 45 70 00 fb 5d c3 c3 cc cc cc cc cc cc cc cc 53 &lt;48&gt; 8b 17
48 89 fb 85 d2 75 3d 48 89 d0 bf 64 00 00 00 48 89 c1 48
RSP: 0018:ffff888137dd7a38 EFLAGS: 00010206
RAX: 0000000000000000 RBX: ffff888107d5f458 RCX: 00000000fffffffe
RDX: 000000000002c2b0 RSI: ffffffff8155e2e0 RDI: 0002000300004058
RBP: ffff888137dd7a88 R08: 0002000300004058 R09: ffff8881144a9f88
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881141d4000
R13: ffff888137dd7c68 R14: ffff888137dd7d58 R15: ffff888137dd7cc0
FS:  00007f4644f2a4c0(0000) GS:ffff8887a2d40000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055b4500f4380 CR3: 0000000114f7a003 CR4: 0000000000170ea0
Call Trace:
  simple_recursive_removal+0x33/0x2e0
  ? debugfs_remove+0x60/0x60
  debugfs_remove+0x40/0x60
  mlx5_debug_cq_remove+0x32/0x70 [mlx5_core]
  mlx5_core_destroy_cq+0x41/0x1d0 [mlx5_core]
  devx_obj_cleanup+0x151/0x330 [mlx5_ib]
  ? __pollwait+0xd0/0xd0
  ? xas_load+0x5/0x70
  ? xa_load+0x62/0xa0
  destroy_hw_idr_uobject+0x20/0x80 [ib_uverbs]
  uverbs_destroy_uobject+0x3b/0x360 [ib_uverbs]
  uobj_destroy+0x54/0xa0 [ib_uverbs]
  ib_uverbs_cmd_verbs+0xaf2/0x1160 [ib_uverbs]
  ? uverbs_finalize_object+0xd0/0xd0 [ib_uverbs]
  ib_uverbs_ioctl+0xc4/0x1b0 [ib_uverbs]
  __x64_sys_ioctl+0x3e4/0x8e0</Note>
    </Notes>
    <CVE>CVE-2021-47197</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 use-after-free in lpfc_unreg_rpi() routine

An error is detected with the following report when unloading the driver:
  "KASAN: use-after-free in lpfc_unreg_rpi+0x1b1b"

The NLP_REG_LOGIN_SEND nlp_flag is set in lpfc_reg_fab_ctrl_node(), but the
flag is not cleared upon completion of the login.

This allows a second call to lpfc_unreg_rpi() to proceed with nlp_rpi set
to LPFC_RPI_ALLOW_ERROR.  This results in a use after free access when used
as an rpi_ids array index.

Fix by clearing the NLP_REG_LOGIN_SEND nlp_flag in
lpfc_mbx_cmpl_fc_reg_login().</Note>
    </Notes>
    <CVE>CVE-2021-47198</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: CT, Fix multiple allocations and memleak of mod acts

CT clear action offload adds additional mod hdr actions to the
flow's original mod actions in order to clear the registers which
hold ct_state.
When such flow also includes encap action, a neigh update event
can cause the driver to unoffload the flow and then reoffload it.

Each time this happens, the ct clear handling adds that same set
of mod hdr actions to reset ct_state until the max of mod hdr
actions is reached.

Also the driver never releases the allocated mod hdr actions and
causing a memleak.

Fix above two issues by moving CT clear mod acts allocation
into the parsing actions phase and only use it when offloading the rule.
The release of mod acts will be done in the normal flow_put().

 backtrace:
    [&lt;000000007316e2f3&gt;] krealloc+0x83/0xd0
    [&lt;00000000ef157de1&gt;] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core]
    [&lt;00000000970ce4ae&gt;] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core]
    [&lt;0000000067c5fa17&gt;] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core]
    [&lt;00000000d032eb98&gt;] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core]
    [&lt;00000000fd23b869&gt;] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core]
    [&lt;000000004fc24acc&gt;] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core]
    [&lt;00000000dc741c17&gt;] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core]
    [&lt;00000000e92e49d7&gt;] mlx5e_rep_update_flows+0x6e4/0x9b0 [mlx5_core]
    [&lt;00000000f60f5602&gt;] mlx5e_rep_neigh_update+0x39a/0x5d0 [mlx5_core]</Note>
    </Notes>
    <CVE>CVE-2021-47199</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/prime: Fix use after free in mmap with drm_gem_ttm_mmap

drm_gem_ttm_mmap() drops a reference to the gem object on success. If
the gem object's refcount == 1 on entry to drm_gem_prime_mmap(), that
drop will free the gem object, and the subsequent drm_gem_object_get()
will be a UAF. Fix by grabbing a reference before calling the mmap
helper.

This issue was forseen when the reference dropping was adding in
commit 9786b65bc61ac ("drm/ttm: fix mmap refcounting"):
  "For that to work properly the drm_gem_object_get() call in
  drm_gem_ttm_mmap() must be moved so it happens before calling
  obj-&gt;funcs-&gt;mmap(), otherwise the gem refcount would go down
  to zero."</Note>
    </Notes>
    <CVE>CVE-2021-47200</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: free q_vectors before queues in iavf_disable_vf

iavf_free_queues() clears adapter-&gt;num_active_queues, which
iavf_free_q_vectors() relies on, so swap the order of these two function
calls in iavf_disable_vf(). This resolves a panic encountered when the
interface is disabled and then later brought up again after PF
communication is restored.</Note>
    </Notes>
    <CVE>CVE-2021-47201</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

thermal: Fix NULL pointer dereferences in of_thermal_ functions

of_parse_thermal_zones() parses the thermal-zones node and registers a
thermal_zone device for each subnode. However, if a thermal zone is
consuming a thermal sensor and that thermal sensor device hasn't probed
yet, an attempt to set trip_point_*_temp for that thermal zone device
can cause a NULL pointer dereference. Fix it.

 console:/sys/class/thermal/thermal_zone87 # echo 120000 &gt; trip_point_0_temp
 ...
 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
 ...
 Call trace:
  of_thermal_set_trip_temp+0x40/0xc4
  trip_point_temp_store+0xc0/0x1dc
  dev_attr_store+0x38/0x88
  sysfs_kf_write+0x64/0xc0
  kernfs_fop_write_iter+0x108/0x1d0
  vfs_write+0x2f4/0x368
  ksys_write+0x7c/0xec
  __arm64_sys_write+0x20/0x30
  el0_svc_common.llvm.7279915941325364641+0xbc/0x1bc
  do_el0_svc+0x28/0xa0
  el0_svc+0x14/0x24
  el0_sync_handler+0x88/0xec
  el0_sync+0x1c0/0x200

While at it, fix the possible NULL pointer dereference in other
functions as well: of_thermal_get_temp(), of_thermal_set_emul_temp(),
of_thermal_get_trend().</Note>
    </Notes>
    <CVE>CVE-2021-47202</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 list_add() corruption in lpfc_drain_txq()

When parsing the txq list in lpfc_drain_txq(), the driver attempts to pass
the requests to the adapter. If such an attempt fails, a local "fail_msg"
string is set and a log message output.  The job is then added to a
completions list for cancellation.

Processing of any further jobs from the txq list continues, but since
"fail_msg" remains set, jobs are added to the completions list regardless
of whether a wqe was passed to the adapter.  If successfully added to
txcmplq, jobs are added to both lists resulting in list corruption.

Fix by clearing the fail_msg string after adding a job to the completions
list. This stops the subsequent jobs from being added to the completions
list unless they had an appropriate failure.</Note>
    </Notes>
    <CVE>CVE-2021-47203</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: dpaa2-eth: fix use-after-free in dpaa2_eth_remove

Access to netdev after free_netdev() will cause use-after-free bug.
Move debug log before free_netdev() call to avoid it.</Note>
    </Notes>
    <CVE>CVE-2021-47204</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sunxi-ng: Unregister clocks/resets when unbinding

Currently, unbinding a CCU driver unmaps the device's MMIO region, while
leaving its clocks/resets and their providers registered. This can cause
a page fault later when some clock operation tries to perform MMIO. Fix
this by separating the CCU initialization from the memory allocation,
and then using a devres callback to unregister the clocks and resets.

This also fixes a memory leak of the `struct ccu_reset`, and uses the
correct owner (the specific platform driver) for the clocks and resets.

Early OF clock providers are never unregistered, and limited error
handling is possible, so they are mostly unchanged. The error reporting
is made more consistent by moving the message inside of_sunxi_ccu_probe.</Note>
    </Notes>
    <CVE>CVE-2021-47205</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ohci-tmio: check return value after calling platform_get_resource()

It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value.</Note>
    </Notes>
    <CVE>CVE-2021-47206</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: gus: fix null pointer dereference on pointer block

The pointer block return from snd_gf1_dma_next_block could be
null, so there is a potential null pointer dereference issue.
Fix this by adding a null check before dereference.</Note>
    </Notes>
    <CVE>CVE-2021-47207</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/fair: Prevent dead task groups from regaining cfs_rq's

Kevin is reporting crashes which point to a use-after-free of a cfs_rq
in update_blocked_averages(). Initial debugging revealed that we've
live cfs_rq's (on_list=1) in an about to be kfree()'d task group in
free_fair_sched_group(). However, it was unclear how that can happen.

His kernel config happened to lead to a layout of struct sched_entity
that put the 'my_q' member directly into the middle of the object
which makes it incidentally overlap with SLUB's freelist pointer.
That, in combination with SLAB_FREELIST_HARDENED's freelist pointer
mangling, leads to a reliable access violation in form of a #GP which
made the UAF fail fast.

Michal seems to have run into the same issue[1]. He already correctly
diagnosed that commit a7b359fc6a37 ("sched/fair: Correctly insert
cfs_rq's to list on unthrottle") is causing the preconditions for the
UAF to happen by re-adding cfs_rq's also to task groups that have no
more running tasks, i.e. also to dead ones. His analysis, however,
misses the real root cause and it cannot be seen from the crash
backtrace only, as the real offender is tg_unthrottle_up() getting
called via sched_cfs_period_timer() via the timer interrupt at an
inconvenient time.

When unregister_fair_sched_group() unlinks all cfs_rq's from the dying
task group, it doesn't protect itself from getting interrupted. If the
timer interrupt triggers while we iterate over all CPUs or after
unregister_fair_sched_group() has finished but prior to unlinking the
task group, sched_cfs_period_timer() will execute and walk the list of
task groups, trying to unthrottle cfs_rq's, i.e. re-add them to the
dying task group. These will later -- in free_fair_sched_group() -- be
kfree()'ed while still being linked, leading to the fireworks Kevin
and Michal are seeing.

To fix this race, ensure the dying task group gets unlinked first.
However, simply switching the order of unregistering and unlinking the
task group isn't sufficient, as concurrent RCU walkers might still see
it, as can be seen below:

    CPU1:                                      CPU2:
      :                                        timer IRQ:
      :                                          do_sched_cfs_period_timer():
      :                                            :
      :                                            distribute_cfs_runtime():
      :                                              rcu_read_lock();
      :                                              :
      :                                              unthrottle_cfs_rq():
    sched_offline_group():                             :
      :                                                walk_tg_tree_from(...,tg_unthrottle_up,...):
      list_del_rcu(&amp;tg-&gt;list);                           :
 (1)  :                                                  list_for_each_entry_rcu(child, &amp;parent-&gt;children, siblings)
      :                                                    :
 (2)  list_del_rcu(&amp;tg-&gt;siblings);                         :
      :                                                    tg_unthrottle_up():
      unregister_fair_sched_group():                         struct cfs_rq *cfs_rq = tg-&gt;cfs_rq[cpu_of(rq)];
        :                                                    :
        list_del_leaf_cfs_rq(tg-&gt;cfs_rq[cpu]);               :
        :                                                    :
        :                                                    if (!cfs_rq_is_decayed(cfs_rq) || cfs_rq-&gt;nr_running)
 (3)    :                                                        list_add_leaf_cfs_rq(cfs_rq);
      :                                                      :
      :                                                    :
      :                                                  :
      :                                                :
      :                           
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47209</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: typec: tipd: Remove WARN_ON in tps6598x_block_read

Calling tps6598x_block_read with a higher than allowed len can be
handled by just returning an error. There's no need to crash systems
with panic-on-warn enabled.</Note>
    </Notes>
    <CVE>CVE-2021-47210</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 dereference on pointer cs_desc

The pointer cs_desc return from snd_usb_find_clock_source could
be null, so there is a potential null pointer dereference issue.
Fix this by adding a null check before dereference.</Note>
    </Notes>
    <CVE>CVE-2021-47211</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Update error handler for UCTX and UMEM

In the fast unload flow, the device state is set to internal error,
which indicates that the driver started the destroy process.
In this case, when a destroy command is being executed, it should return
MLX5_CMD_STAT_OK.
Fix MLX5_CMD_OP_DESTROY_UCTX and MLX5_CMD_OP_DESTROY_UMEM to return OK
instead of EIO.

This fixes a call trace in the umem release process -
[ 2633.536695] Call Trace:
[ 2633.537518]  ib_uverbs_remove_one+0xc3/0x140 [ib_uverbs]
[ 2633.538596]  remove_client_context+0x8b/0xd0 [ib_core]
[ 2633.539641]  disable_device+0x8c/0x130 [ib_core]
[ 2633.540615]  __ib_unregister_device+0x35/0xa0 [ib_core]
[ 2633.541640]  ib_unregister_device+0x21/0x30 [ib_core]
[ 2633.542663]  __mlx5_ib_remove+0x38/0x90 [mlx5_ib]
[ 2633.543640]  auxiliary_bus_remove+0x1e/0x30 [auxiliary]
[ 2633.544661]  device_release_driver_internal+0x103/0x1f0
[ 2633.545679]  bus_remove_device+0xf7/0x170
[ 2633.546640]  device_del+0x181/0x410
[ 2633.547606]  mlx5_rescan_drivers_locked.part.10+0x63/0x160 [mlx5_core]
[ 2633.548777]  mlx5_unregister_device+0x27/0x40 [mlx5_core]
[ 2633.549841]  mlx5_uninit_one+0x21/0xc0 [mlx5_core]
[ 2633.550864]  remove_one+0x69/0xe0 [mlx5_core]
[ 2633.551819]  pci_device_remove+0x3b/0xc0
[ 2633.552731]  device_release_driver_internal+0x103/0x1f0
[ 2633.553746]  unbind_store+0xf6/0x130
[ 2633.554657]  kernfs_fop_write+0x116/0x190
[ 2633.555567]  vfs_write+0xa5/0x1a0
[ 2633.556407]  ksys_write+0x4f/0xb0
[ 2633.557233]  do_syscall_64+0x5b/0x1a0
[ 2633.558071]  entry_SYSCALL_64_after_hwframe+0x65/0xca
[ 2633.559018] RIP: 0033:0x7f9977132648
[ 2633.559821] Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 55 6f 2d 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55
[ 2633.562332] RSP: 002b:00007fffb1a83888 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 2633.563472] RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007f9977132648
[ 2633.564541] RDX: 000000000000000c RSI: 000055b90546e230 RDI: 0000000000000001
[ 2633.565596] RBP: 000055b90546e230 R08: 00007f9977406860 R09: 00007f9977a54740
[ 2633.566653] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f99774056e0
[ 2633.567692] R13: 000000000000000c R14: 00007f9977400880 R15: 000000000000000c
[ 2633.568725] ---[ end trace 10b4fe52945e544d ]---</Note>
    </Notes>
    <CVE>CVE-2021-47212</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hugetlb, userfaultfd: fix reservation restore on userfaultfd error

Currently in the is_continue case in hugetlb_mcopy_atomic_pte(), if we
bail out using "goto out_release_unlock;" in the cases where idx &gt;=
size, or !huge_pte_none(), the code will detect that new_pagecache_page
== false, and so call restore_reserve_on_error().  In this case I see
restore_reserve_on_error() delete the reservation, and the following
call to remove_inode_hugepages() will increment h-&gt;resv_hugepages
causing a 100% reproducible leak.

We should treat the is_continue case similar to adding a page into the
pagecache and set new_pagecache_page to true, to indicate that there is
no reservation to restore on the error path, and we need not call
restore_reserve_on_error().  Rename new_pagecache_page to
page_in_pagecache to make that clear.</Note>
    </Notes>
    <CVE>CVE-2021-47214</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: kTLS, Fix crash in RX resync flow

For the TLS RX resync flow, we maintain a list of TLS contexts
that require some attention, to communicate their resync information
to the HW.
Here we fix list corruptions, by protecting the entries against
movements coming from resync_handle_seq_match(), until their resync
handling in napi is fully completed.</Note>
    </Notes>
    <CVE>CVE-2021-47215</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: advansys: Fix kernel pointer leak

Pointers should be printed with %p or %px rather than cast to 'unsigned
long' and printed with %lx.

Change %lx to %p to print the hashed pointer.</Note>
    </Notes>
    <CVE>CVE-2021-47216</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

x86/hyperv: Fix NULL deref in set_hv_tscchange_cb() if Hyper-V setup fails

Check for a valid hv_vp_index array prior to derefencing hv_vp_index when
setting Hyper-V's TSC change callback.  If Hyper-V setup failed in
hyperv_init(), the kernel will still report that it's running under
Hyper-V, but will have silently disabled nearly all functionality.

  BUG: kernel NULL pointer dereference, address: 0000000000000010
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: 0000 [#1] SMP
  CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.15.0-rc2+ #75
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
  RIP: 0010:set_hv_tscchange_cb+0x15/0xa0
  Code: &lt;8b&gt; 04 82 8b 15 12 17 85 01 48 c1 e0 20 48 0d ee 00 01 00 f6 c6 08
  ...
  Call Trace:
   kvm_arch_init+0x17c/0x280
   kvm_init+0x31/0x330
   vmx_init+0xba/0x13a
   do_one_initcall+0x41/0x1c0
   kernel_init_freeable+0x1f2/0x23b
   kernel_init+0x16/0x120
   ret_from_fork+0x22/0x30</Note>
    </Notes>
    <CVE>CVE-2021-47217</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

selinux: fix NULL-pointer dereference when hashtab allocation fails

When the hash table slot array allocation fails in hashtab_init(),
h-&gt;size is left initialized with a non-zero value, but the h-&gt;htable
pointer is NULL. This may then cause a NULL pointer dereference, since
the policydb code relies on the assumption that even after a failed
hashtab_init(), hashtab_map() and hashtab_destroy() can be safely called
on it. Yet, these detect an empty hashtab only by looking at the size.

Fix this by making sure that hashtab_init() always leaves behind a valid
empty hashtab when the allocation fails.</Note>
    </Notes>
    <CVE>CVE-2021-47218</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: scsi_debug: Fix out-of-bound read in resp_report_tgtpgs()

The following issue was observed running syzkaller:

BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:377 [inline]
BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831
Read of size 2132 at addr ffff8880aea95dc8 by task syz-executor.0/9815

CPU: 0 PID: 9815 Comm: syz-executor.0 Not tainted 4.19.202-00874-gfc0fe04215a9 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0xe4/0x14a lib/dump_stack.c:118
 print_address_description+0x73/0x280 mm/kasan/report.c:253
 kasan_report_error mm/kasan/report.c:352 [inline]
 kasan_report+0x272/0x370 mm/kasan/report.c:410
 memcpy+0x1f/0x50 mm/kasan/kasan.c:302
 memcpy include/linux/string.h:377 [inline]
 sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831
 fill_from_dev_buffer+0x14f/0x340 drivers/scsi/scsi_debug.c:1021
 resp_report_tgtpgs+0x5aa/0x770 drivers/scsi/scsi_debug.c:1772
 schedule_resp+0x464/0x12f0 drivers/scsi/scsi_debug.c:4429
 scsi_debug_queuecommand+0x467/0x1390 drivers/scsi/scsi_debug.c:5835
 scsi_dispatch_cmd+0x3fc/0x9b0 drivers/scsi/scsi_lib.c:1896
 scsi_request_fn+0x1042/0x1810 drivers/scsi/scsi_lib.c:2034
 __blk_run_queue_uncond block/blk-core.c:464 [inline]
 __blk_run_queue+0x1a4/0x380 block/blk-core.c:484
 blk_execute_rq_nowait+0x1c2/0x2d0 block/blk-exec.c:78
 sg_common_write.isra.19+0xd74/0x1dc0 drivers/scsi/sg.c:847
 sg_write.part.23+0x6e0/0xd00 drivers/scsi/sg.c:716
 sg_write+0x64/0xa0 drivers/scsi/sg.c:622
 __vfs_write+0xed/0x690 fs/read_write.c:485
kill_bdev:block_device:00000000e138492c
 vfs_write+0x184/0x4c0 fs/read_write.c:549
 ksys_write+0x107/0x240 fs/read_write.c:599
 do_syscall_64+0xc2/0x560 arch/x86/entry/common.c:293
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

We get 'alen' from command its type is int. If userspace passes a large
length we will get a negative 'alen'.

Switch n, alen, and rlen to u32.</Note>
    </Notes>
    <CVE>CVE-2021-47219</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 bug in extents parsing when eh_entries == 0 and eh_depth &gt; 0

When walking through an inode extents, the ext4_ext_binsearch_idx() function
assumes that the extent header has been previously validated.  However, there
are no checks that verify that the number of entries (eh-&gt;eh_entries) is
non-zero when depth is &gt; 0.  And this will lead to problems because the
EXT_FIRST_INDEX() and EXT_LAST_INDEX() will return garbage and result in this:

[  135.245946] ------------[ cut here ]------------
[  135.247579] kernel BUG at fs/ext4/extents.c:2258!
[  135.249045] invalid opcode: 0000 [#1] PREEMPT SMP
[  135.250320] CPU: 2 PID: 238 Comm: tmp118 Not tainted 5.19.0-rc8+ #4
[  135.252067] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014
[  135.255065] RIP: 0010:ext4_ext_map_blocks+0xc20/0xcb0
[  135.256475] Code:
[  135.261433] RSP: 0018:ffffc900005939f8 EFLAGS: 00010246
[  135.262847] RAX: 0000000000000024 RBX: ffffc90000593b70 RCX: 0000000000000023
[  135.264765] RDX: ffff8880038e5f10 RSI: 0000000000000003 RDI: ffff8880046e922c
[  135.266670] RBP: ffff8880046e9348 R08: 0000000000000001 R09: ffff888002ca580c
[  135.268576] R10: 0000000000002602 R11: 0000000000000000 R12: 0000000000000024
[  135.270477] R13: 0000000000000000 R14: 0000000000000024 R15: 0000000000000000
[  135.272394] FS:  00007fdabdc56740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000
[  135.274510] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  135.276075] CR2: 00007ffc26bd4f00 CR3: 0000000006261004 CR4: 0000000000170ea0
[  135.277952] Call Trace:
[  135.278635]  &lt;TASK&gt;
[  135.279247]  ? preempt_count_add+0x6d/0xa0
[  135.280358]  ? percpu_counter_add_batch+0x55/0xb0
[  135.281612]  ? _raw_read_unlock+0x18/0x30
[  135.282704]  ext4_map_blocks+0x294/0x5a0
[  135.283745]  ? xa_load+0x6f/0xa0
[  135.284562]  ext4_mpage_readpages+0x3d6/0x770
[  135.285646]  read_pages+0x67/0x1d0
[  135.286492]  ? folio_add_lru+0x51/0x80
[  135.287441]  page_cache_ra_unbounded+0x124/0x170
[  135.288510]  filemap_get_pages+0x23d/0x5a0
[  135.289457]  ? path_openat+0xa72/0xdd0
[  135.290332]  filemap_read+0xbf/0x300
[  135.291158]  ? _raw_spin_lock_irqsave+0x17/0x40
[  135.292192]  new_sync_read+0x103/0x170
[  135.293014]  vfs_read+0x15d/0x180
[  135.293745]  ksys_read+0xa1/0xe0
[  135.294461]  do_syscall_64+0x3c/0x80
[  135.295284]  entry_SYSCALL_64_after_hwframe+0x46/0xb0

This patch simply adds an extra check in __ext4_ext_check(), verifying that
eh_entries is not 0 when eh_depth is &gt; 0.</Note>
    </Notes>
    <CVE>CVE-2022-48631</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction()

memcpy() is called in a loop while 'operation-&gt;length' upper bound
is not checked and 'data_idx' also increments.</Note>
    </Notes>
    <CVE>CVE-2022-48632</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 BUG: sleeping function called from invalid context errors

gma_crtc_page_flip() was holding the event_lock spinlock while calling
crtc_funcs-&gt;mode_set_base() which takes ww_mutex.

The only reason to hold event_lock is to clear gma_crtc-&gt;page_flip_event
on mode_set_base() errors.

Instead unlock it after setting gma_crtc-&gt;page_flip_event and on
errors re-take the lock and clear gma_crtc-&gt;page_flip_event it
it is still set.

This fixes the following WARN/stacktrace:

[  512.122953] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:870
[  512.123004] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1253, name: gnome-shell
[  512.123031] preempt_count: 1, expected: 0
[  512.123048] RCU nest depth: 0, expected: 0
[  512.123066] INFO: lockdep is turned off.
[  512.123080] irq event stamp: 0
[  512.123094] hardirqs last  enabled at (0): [&lt;0000000000000000&gt;] 0x0
[  512.123134] hardirqs last disabled at (0): [&lt;ffffffff8d0ec28c&gt;] copy_process+0x9fc/0x1de0
[  512.123176] softirqs last  enabled at (0): [&lt;ffffffff8d0ec28c&gt;] copy_process+0x9fc/0x1de0
[  512.123207] softirqs last disabled at (0): [&lt;0000000000000000&gt;] 0x0
[  512.123233] Preemption disabled at:
[  512.123241] [&lt;0000000000000000&gt;] 0x0
[  512.123275] CPU: 3 PID: 1253 Comm: gnome-shell Tainted: G        W         5.19.0+ #1
[  512.123304] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013
[  512.123323] Call Trace:
[  512.123346]  &lt;TASK&gt;
[  512.123370]  dump_stack_lvl+0x5b/0x77
[  512.123412]  __might_resched.cold+0xff/0x13a
[  512.123458]  ww_mutex_lock+0x1e/0xa0
[  512.123495]  psb_gem_pin+0x2c/0x150 [gma500_gfx]
[  512.123601]  gma_pipe_set_base+0x76/0x240 [gma500_gfx]
[  512.123708]  gma_crtc_page_flip+0x95/0x130 [gma500_gfx]
[  512.123808]  drm_mode_page_flip_ioctl+0x57d/0x5d0
[  512.123897]  ? drm_mode_cursor2_ioctl+0x10/0x10
[  512.123936]  drm_ioctl_kernel+0xa1/0x150
[  512.123984]  drm_ioctl+0x21f/0x420
[  512.124025]  ? drm_mode_cursor2_ioctl+0x10/0x10
[  512.124070]  ? rcu_read_lock_bh_held+0xb/0x60
[  512.124104]  ? lock_release+0x1ef/0x2d0
[  512.124161]  __x64_sys_ioctl+0x8d/0xd0
[  512.124203]  do_syscall_64+0x58/0x80
[  512.124239]  ? do_syscall_64+0x67/0x80
[  512.124267]  ? trace_hardirqs_on_prepare+0x55/0xe0
[  512.124300]  ? do_syscall_64+0x67/0x80
[  512.124340]  ? rcu_read_lock_sched_held+0x10/0x80
[  512.124377]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
[  512.124411] RIP: 0033:0x7fcc4a70740f
[  512.124442] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 &lt;89&gt; c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00
[  512.124470] RSP: 002b:00007ffda73f5390 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[  512.124503] RAX: ffffffffffffffda RBX: 000055cc9e474500 RCX: 00007fcc4a70740f
[  512.124524] RDX: 00007ffda73f5420 RSI: 00000000c01864b0 RDI: 0000000000000009
[  512.124544] RBP: 00007ffda73f5420 R08: 000055cc9c0b0cb0 R09: 0000000000000034
[  512.124564] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c01864b0
[  512.124584] R13: 0000000000000009 R14: 000055cc9df484d0 R15: 000055cc9af5d0c0
[  512.124647]  &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2022-48634</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/dasd: fix Oops in dasd_alias_get_start_dev due to missing pavgroup

Fix Oops in dasd_alias_get_start_dev() function caused by the pavgroup
pointer being NULL.

The pavgroup pointer is checked on the entrance of the function but
without the lcu-&gt;lock being held. Therefore there is a race window
between dasd_alias_get_start_dev() and _lcu_update() which sets
pavgroup to NULL with the lcu-&gt;lock held.

Fix by checking the pavgroup pointer with lcu-&gt;lock held.</Note>
    </Notes>
    <CVE>CVE-2022-48636</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bnxt: prevent skb UAF after handing over to PTP worker

When reading the timestamp is required bnxt_tx_int() hands
over the ownership of the completed skb to the PTP worker.
The skb should not be used afterwards, as the worker may
run before the rest of our code and free the skb, leading
to a use-after-free.

Since dev_kfree_skb_any() accepts NULL make the loss of
ownership more obvious and set skb to NULL.</Note>
    </Notes>
    <CVE>CVE-2022-48637</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cgroup: cgroup_get_from_id() must check the looked-up kn is a directory

cgroup has to be one kernfs dir, otherwise kernel panic is caused,
especially cgroup id is provide from userspace.</Note>
    </Notes>
    <CVE>CVE-2022-48638</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: sched: fix possible refcount leak in tc_new_tfilter()

tfilter_put need to be called to put the refount got by tp-&gt;ops-&gt;get to
avoid possible refcount leak when chain-&gt;tmplt_ops != NULL and
chain-&gt;tmplt_ops != tp-&gt;ops.</Note>
    </Notes>
    <CVE>CVE-2022-48639</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix NULL deref in bond_rr_gen_slave_id

Fix a NULL dereference of the struct bonding.rr_tx_counter member because
if a bond is initially created with an initial mode != zero (Round Robin)
the memory required for the counter is never created and when the mode is
changed there is never any attempt to verify the memory is allocated upon
switching modes.

This causes the following Oops on an aarch64 machine:
    [  334.686773] Unable to handle kernel paging request at virtual address ffff2c91ac905000
    [  334.694703] Mem abort info:
    [  334.697486]   ESR = 0x0000000096000004
    [  334.701234]   EC = 0x25: DABT (current EL), IL = 32 bits
    [  334.706536]   SET = 0, FnV = 0
    [  334.709579]   EA = 0, S1PTW = 0
    [  334.712719]   FSC = 0x04: level 0 translation fault
    [  334.717586] Data abort info:
    [  334.720454]   ISV = 0, ISS = 0x00000004
    [  334.724288]   CM = 0, WnR = 0
    [  334.727244] swapper pgtable: 4k pages, 48-bit VAs, pgdp=000008044d662000
    [  334.733944] [ffff2c91ac905000] pgd=0000000000000000, p4d=0000000000000000
    [  334.740734] Internal error: Oops: 96000004 [#1] SMP
    [  334.745602] Modules linked in: bonding tls veth rfkill sunrpc arm_spe_pmu vfat fat acpi_ipmi ipmi_ssif ixgbe igb i40e mdio ipmi_devintf ipmi_msghandler arm_cmn arm_dsu_pmu cppc_cpufreq acpi_tad fuse zram crct10dif_ce ast ghash_ce sbsa_gwdt nvme drm_vram_helper drm_ttm_helper nvme_core ttm xgene_hwmon
    [  334.772217] CPU: 7 PID: 2214 Comm: ping Not tainted 6.0.0-rc4-00133-g64ae13ed4784 #4
    [  334.779950] Hardware name: GIGABYTE R272-P31-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021
    [  334.789244] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [  334.796196] pc : bond_rr_gen_slave_id+0x40/0x124 [bonding]
    [  334.801691] lr : bond_xmit_roundrobin_slave_get+0x38/0xdc [bonding]
    [  334.807962] sp : ffff8000221733e0
    [  334.811265] x29: ffff8000221733e0 x28: ffffdbac8572d198 x27: ffff80002217357c
    [  334.818392] x26: 000000000000002a x25: ffffdbacb33ee000 x24: ffff07ff980fa000
    [  334.825519] x23: ffffdbacb2e398ba x22: ffff07ff98102000 x21: ffff07ff981029c0
    [  334.832646] x20: 0000000000000001 x19: ffff07ff981029c0 x18: 0000000000000014
    [  334.839773] x17: 0000000000000000 x16: ffffdbacb1004364 x15: 0000aaaabe2f5a62
    [  334.846899] x14: ffff07ff8e55d968 x13: ffff07ff8e55db30 x12: 0000000000000000
    [  334.854026] x11: ffffdbacb21532e8 x10: 0000000000000001 x9 : ffffdbac857178ec
    [  334.861153] x8 : ffff07ff9f6e5a28 x7 : 0000000000000000 x6 : 000000007c2b3742
    [  334.868279] x5 : ffff2c91ac905000 x4 : ffff2c91ac905000 x3 : ffff07ff9f554400
    [  334.875406] x2 : ffff2c91ac905000 x1 : 0000000000000001 x0 : ffff07ff981029c0
    [  334.882532] Call trace:
    [  334.884967]  bond_rr_gen_slave_id+0x40/0x124 [bonding]
    [  334.890109]  bond_xmit_roundrobin_slave_get+0x38/0xdc [bonding]
    [  334.896033]  __bond_start_xmit+0x128/0x3a0 [bonding]
    [  334.901001]  bond_start_xmit+0x54/0xb0 [bonding]
    [  334.905622]  dev_hard_start_xmit+0xb4/0x220
    [  334.909798]  __dev_queue_xmit+0x1a0/0x720
    [  334.913799]  arp_xmit+0x3c/0xbc
    [  334.916932]  arp_send_dst+0x98/0xd0
    [  334.920410]  arp_solicit+0xe8/0x230
    [  334.923888]  neigh_probe+0x60/0xb0
    [  334.927279]  __neigh_event_send+0x3b0/0x470
    [  334.931453]  neigh_resolve_output+0x70/0x90
    [  334.935626]  ip_finish_output2+0x158/0x514
    [  334.939714]  __ip_finish_output+0xac/0x1a4
    [  334.943800]  ip_finish_output+0x40/0xfc
    [  334.947626]  ip_output+0xf8/0x1a4
    [  334.950931]  ip_send_skb+0x5c/0x100
    [  334.954410]  ip_push_pending_frames+0x3c/0x60
    [  334.958758]  raw_sendmsg+0x458/0x6d0
    [  334.962325]  inet_sendmsg+0x50/0x80
    [  334.965805]  sock_sendmsg+0x60/0x6c
    [  334.969286]  __sys_sendto+0xc8/0x134
    [  334.972853]  __arm64_sys_sendto+0x34/0x4c
---truncated---</Note>
    </Notes>
    <CVE>CVE-2022-48640</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: fix percpu memory leak at nf_tables_addchain()

It seems to me that percpu memory for chain stats started leaking since
commit 3bc158f8d0330f0a ("netfilter: nf_tables: map basechain priority to
hardware priority") when nft_chain_offload_priority() returned an error.</Note>
    </Notes>
    <CVE>CVE-2022-48642</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/sched: taprio: avoid disabling offload when it was never enabled

In an incredibly strange API design decision, qdisc-&gt;destroy() gets
called even if qdisc-&gt;init() never succeeded, not exclusively since
commit 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation"),
but apparently also earlier (in the case of qdisc_create_dflt()).

The taprio qdisc does not fully acknowledge this when it attempts full
offload, because it starts off with q-&gt;flags = TAPRIO_FLAGS_INVALID in
taprio_init(), then it replaces q-&gt;flags with TCA_TAPRIO_ATTR_FLAGS
parsed from netlink (in taprio_change(), tail called from taprio_init()).

But in taprio_destroy(), we call taprio_disable_offload(), and this
determines what to do based on FULL_OFFLOAD_IS_ENABLED(q-&gt;flags).

But looking at the implementation of FULL_OFFLOAD_IS_ENABLED()
(a bitwise check of bit 1 in q-&gt;flags), it is invalid to call this macro
on q-&gt;flags when it contains TAPRIO_FLAGS_INVALID, because that is set
to U32_MAX, and therefore FULL_OFFLOAD_IS_ENABLED() will return true on
an invalid set of flags.

As a result, it is possible to crash the kernel if user space forces an
error between setting q-&gt;flags = TAPRIO_FLAGS_INVALID, and the calling
of taprio_enable_offload(). This is because drivers do not expect the
offload to be disabled when it was never enabled.

The error that we force here is to attach taprio as a non-root qdisc,
but instead as child of an mqprio root qdisc:

$ tc qdisc add dev swp0 root handle 1: \
	mqprio num_tc 8 map 0 1 2 3 4 5 6 7 \
	queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0
$ tc qdisc replace dev swp0 parent 1:1 \
	taprio num_tc 8 map 0 1 2 3 4 5 6 7 \
	queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \
	sched-entry S 0x7f 990000 sched-entry S 0x80 100000 \
	flags 0x0 clockid CLOCK_TAI
Unable to handle kernel paging request at virtual address fffffffffffffff8
[fffffffffffffff8] pgd=0000000000000000, p4d=0000000000000000
Internal error: Oops: 96000004 [#1] PREEMPT SMP
Call trace:
 taprio_dump+0x27c/0x310
 vsc9959_port_setup_tc+0x1f4/0x460
 felix_port_setup_tc+0x24/0x3c
 dsa_slave_setup_tc+0x54/0x27c
 taprio_disable_offload.isra.0+0x58/0xe0
 taprio_destroy+0x80/0x104
 qdisc_create+0x240/0x470
 tc_modify_qdisc+0x1fc/0x6b0
 rtnetlink_rcv_msg+0x12c/0x390
 netlink_rcv_skb+0x5c/0x130
 rtnetlink_rcv+0x1c/0x2c

Fix this by keeping track of the operations we made, and undo the
offload only if we actually did it.

I've added "bool offloaded" inside a 4 byte hole between "int clockid"
and "atomic64_t picos_per_byte". Now the first cache line looks like
below:

$ pahole -C taprio_sched net/sched/sch_taprio.o
struct taprio_sched {
        struct Qdisc * *           qdiscs;               /*     0     8 */
        struct Qdisc *             root;                 /*     8     8 */
        u32                        flags;                /*    16     4 */
        enum tk_offsets            tk_offset;            /*    20     4 */
        int                        clockid;              /*    24     4 */
        bool                       offloaded;            /*    28     1 */

        /* XXX 3 bytes hole, try to pack */

        atomic64_t                 picos_per_byte;       /*    32     0 */

        /* XXX 8 bytes hole, try to pack */

        spinlock_t                 current_entry_lock;   /*    40     0 */

        /* XXX 8 bytes hole, try to pack */

        struct sched_entry *       current_entry;        /*    48     8 */
        struct sched_gate_list *   oper_sched;           /*    56     8 */
        /* --- cacheline 1 boundary (64 bytes) --- */</Note>
    </Notes>
    <CVE>CVE-2022-48644</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sfc/siena: fix null pointer dereference in efx_hard_start_xmit

Like in previous patch for sfc, prevent potential (but unlikely) NULL
pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2022-48646</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sfc: fix TX channel offset when using legacy interrupts

In legacy interrupt mode the tx_channel_offset was hardcoded to 1, but
that's not correct if efx_sepparate_tx_channels is false. In that case,
the offset is 0 because the tx queues are in the single existing channel
at index 0, together with the rx queue.

Without this fix, as soon as you try to send any traffic, it tries to
get the tx queues from an uninitialized channel getting these errors:
  WARNING: CPU: 1 PID: 0 at drivers/net/ethernet/sfc/tx.c:540 efx_hard_start_xmit+0x12e/0x170 [sfc]
  [...]
  RIP: 0010:efx_hard_start_xmit+0x12e/0x170 [sfc]
  [...]
  Call Trace:
   &lt;IRQ&gt;
   dev_hard_start_xmit+0xd7/0x230
   sch_direct_xmit+0x9f/0x360
   __dev_queue_xmit+0x890/0xa40
  [...]
  BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
  [...]
  RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc]
  [...]
  Call Trace:
   &lt;IRQ&gt;
   dev_hard_start_xmit+0xd7/0x230
   sch_direct_xmit+0x9f/0x360
   __dev_queue_xmit+0x890/0xa40
  [...]</Note>
    </Notes>
    <CVE>CVE-2022-48647</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sfc: fix null pointer dereference in efx_hard_start_xmit

Trying to get the channel from the tx_queue variable here is wrong
because we can only be here if tx_queue is NULL, so we shouldn't
dereference it. As the above comment in the code says, this is very
unlikely to happen, but it's wrong anyway so let's fix it.

I hit this issue because of a different bug that caused tx_queue to be
NULL. If that happens, this is the error message that we get here:
  BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
  [...]
  RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc]</Note>
    </Notes>
    <CVE>CVE-2022-48648</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 memory leak in __qlt_24xx_handle_abts()

Commit 8f394da36a36 ("scsi: qla2xxx: Drop TARGET_SCF_LOOKUP_LUN_FROM_TAG")
made the __qlt_24xx_handle_abts() function return early if
tcm_qla2xxx_find_cmd_by_tag() didn't find a command, but it missed to clean
up the allocated memory for the management command.</Note>
    </Notes>
    <CVE>CVE-2022-48650</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipvlan: Fix out-of-bound bugs caused by unset skb-&gt;mac_header

If an AF_PACKET socket is used to send packets through ipvlan and the
default xmit function of the AF_PACKET socket is changed from
dev_queue_xmit() to packet_direct_xmit() via setsockopt() with the option
name of PACKET_QDISC_BYPASS, the skb-&gt;mac_header may not be reset and
remains as the initial value of 65535, this may trigger slab-out-of-bounds
bugs as following:

=================================================================
UG: KASAN: slab-out-of-bounds in ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan]
PU: 2 PID: 1768 Comm: raw_send Kdump: loaded Not tainted 6.0.0-rc4+ #6
ardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33
all Trace:
print_address_description.constprop.0+0x1d/0x160
print_report.cold+0x4f/0x112
kasan_report+0xa3/0x130
ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan]
ipvlan_start_xmit+0x29/0xa0 [ipvlan]
__dev_direct_xmit+0x2e2/0x380
packet_direct_xmit+0x22/0x60
packet_snd+0x7c9/0xc40
sock_sendmsg+0x9a/0xa0
__sys_sendto+0x18a/0x230
__x64_sys_sendto+0x74/0x90
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd

The root cause is:
  1. packet_snd() only reset skb-&gt;mac_header when sock-&gt;type is SOCK_RAW
     and skb-&gt;protocol is not specified as in packet_parse_headers()

  2. packet_direct_xmit() doesn't reset skb-&gt;mac_header as dev_queue_xmit()

In this case, skb-&gt;mac_header is 65535 when ipvlan_xmit_mode_l2() is
called. So when ipvlan_xmit_mode_l2() gets mac header with eth_hdr() which
use "skb-&gt;head + skb-&gt;mac_header", out-of-bound access occurs.

This patch replaces eth_hdr() with skb_eth_hdr() in ipvlan_xmit_mode_l2()
and reset mac header in multicast to solve this out-of-bound bug.</Note>
    </Notes>
    <CVE>CVE-2022-48651</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ice: Fix crash by keep old cfg when update TCs more than queues

There are problems if allocated queues less than Traffic Classes.

Commit a632b2a4c920 ("ice: ethtool: Prohibit improper channel config
for DCB") already disallow setting less queues than TCs.

Another case is if we first set less queues, and later update more TCs
config due to LLDP, ice_vsi_cfg_tc() will failed but left dirty
num_txq/rxq and tc_cfg in vsi, that will cause invalid pointer access.

[   95.968089] ice 0000:3b:00.1: More TCs defined than queues/rings allocated.
[   95.968092] ice 0000:3b:00.1: Trying to use more Rx queues (8), than were allocated (1)!
[   95.968093] ice 0000:3b:00.1: Failed to config TC for VSI index: 0
[   95.969621] general protection fault: 0000 [#1] SMP NOPTI
[   95.969705] CPU: 1 PID: 58405 Comm: lldpad Kdump: loaded Tainted: G     U  W  O     --------- -t - 4.18.0 #1
[   95.969867] Hardware name: O.E.M/BC11SPSCB10, BIOS 8.23 12/30/2021
[   95.969992] RIP: 0010:devm_kmalloc+0xa/0x60
[   95.970052] Code: 5c ff ff ff 31 c0 5b 5d 41 5c c3 b8 f4 ff ff ff eb f4 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 89 d1 &lt;8b&gt; 97 60 02 00 00 48 8d 7e 18 48 39 f7 72 3f 55 89 ce 53 48 8b 4c
[   95.970344] RSP: 0018:ffffc9003f553888 EFLAGS: 00010206
[   95.970425] RAX: dead000000000200 RBX: ffffea003c425b00 RCX: 00000000006080c0
[   95.970536] RDX: 00000000006080c0 RSI: 0000000000000200 RDI: dead000000000200
[   95.970648] RBP: dead000000000200 R08: 00000000000463c0 R09: ffff888ffa900000
[   95.970760] R10: 0000000000000000 R11: 0000000000000002 R12: ffff888ff6b40100
[   95.970870] R13: ffff888ff6a55018 R14: 0000000000000000 R15: ffff888ff6a55460
[   95.970981] FS:  00007f51b7d24700(0000) GS:ffff88903ee80000(0000) knlGS:0000000000000000
[   95.971108] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   95.971197] CR2: 00007fac5410d710 CR3: 0000000f2c1de002 CR4: 00000000007606e0
[   95.971309] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   95.971419] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   95.971530] PKRU: 55555554
[   95.971573] Call Trace:
[   95.971622]  ice_setup_rx_ring+0x39/0x110 [ice]
[   95.971695]  ice_vsi_setup_rx_rings+0x54/0x90 [ice]
[   95.971774]  ice_vsi_open+0x25/0x120 [ice]
[   95.971843]  ice_open_internal+0xb8/0x1f0 [ice]
[   95.971919]  ice_ena_vsi+0x4f/0xd0 [ice]
[   95.971987]  ice_dcb_ena_dis_vsi.constprop.5+0x29/0x90 [ice]
[   95.972082]  ice_pf_dcb_cfg+0x29a/0x380 [ice]
[   95.972154]  ice_dcbnl_setets+0x174/0x1b0 [ice]
[   95.972220]  dcbnl_ieee_set+0x89/0x230
[   95.972279]  ? dcbnl_ieee_del+0x150/0x150
[   95.972341]  dcb_doit+0x124/0x1b0
[   95.972392]  rtnetlink_rcv_msg+0x243/0x2f0
[   95.972457]  ? dcb_doit+0x14d/0x1b0
[   95.972510]  ? __kmalloc_node_track_caller+0x1d3/0x280
[   95.972591]  ? rtnl_calcit.isra.31+0x100/0x100
[   95.972661]  netlink_rcv_skb+0xcf/0xf0
[   95.972720]  netlink_unicast+0x16d/0x220
[   95.972781]  netlink_sendmsg+0x2ba/0x3a0
[   95.975891]  sock_sendmsg+0x4c/0x50
[   95.979032]  ___sys_sendmsg+0x2e4/0x300
[   95.982147]  ? kmem_cache_alloc+0x13e/0x190
[   95.985242]  ? __wake_up_common_lock+0x79/0x90
[   95.988338]  ? __check_object_size+0xac/0x1b0
[   95.991440]  ? _copy_to_user+0x22/0x30
[   95.994539]  ? move_addr_to_user+0xbb/0xd0
[   95.997619]  ? __sys_sendmsg+0x53/0x80
[   96.000664]  __sys_sendmsg+0x53/0x80
[   96.003747]  do_syscall_64+0x5b/0x1d0
[   96.006862]  entry_SYSCALL_64_after_hwframe+0x65/0xca

Only update num_txq/rxq when passed check, and restore tc_cfg if setup
queue map failed.</Note>
    </Notes>
    <CVE>CVE-2022-48652</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 double unplug aux on peer initiated reset

In the IDC callback that is accessed when the aux drivers request a reset,
the function to unplug the aux devices is called.  This function is also
called in the ice_prepare_for_reset function. This double call is causing
a "scheduling while atomic" BUG.

[  662.676430] ice 0000:4c:00.0 rocep76s0: cqp opcode = 0x1 maj_err_code = 0xffff min_err_code = 0x8003

[  662.676609] ice 0000:4c:00.0 rocep76s0: [Modify QP Cmd Error][op_code=8] status=-29 waiting=1 completion_err=1 maj=0xffff min=0x8003

[  662.815006] ice 0000:4c:00.0 rocep76s0: ICE OICR event notification: oicr = 0x10000003

[  662.815014] ice 0000:4c:00.0 rocep76s0: critical PE Error, GLPE_CRITERR=0x00011424

[  662.815017] ice 0000:4c:00.0 rocep76s0: Requesting a reset

[  662.815475] BUG: scheduling while atomic: swapper/37/0/0x00010002

[  662.815475] BUG: scheduling while atomic: swapper/37/0/0x00010002
[  662.815477] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs rfkill 8021q garp mrp stp llc vfat fat rpcrdma intel_rapl_msr intel_rapl_common sunrpc i10nm_edac rdma_ucm nfit ib_srpt libnvdimm ib_isert iscsi_target_mod x86_pkg_temp_thermal intel_powerclamp coretemp target_core_mod snd_hda_intel ib_iser snd_intel_dspcfg libiscsi snd_intel_sdw_acpi scsi_transport_iscsi kvm_intel iTCO_wdt rdma_cm snd_hda_codec kvm iw_cm ipmi_ssif iTCO_vendor_support snd_hda_core irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hwdep snd_seq snd_seq_device rapl snd_pcm snd_timer isst_if_mbox_pci pcspkr isst_if_mmio irdma intel_uncore idxd acpi_ipmi joydev isst_if_common snd mei_me idxd_bus ipmi_si soundcore i2c_i801 mei ipmi_devintf i2c_smbus i2c_ismt ipmi_msghandler acpi_power_meter acpi_pad rv(OE) ib_uverbs ib_cm ib_core xfs libcrc32c ast i2c_algo_bit drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm_ttm_helpe
 r ttm
[  662.815546]  nvme nvme_core ice drm crc32c_intel i40e t10_pi wmi pinctrl_emmitsburg dm_mirror dm_region_hash dm_log dm_mod fuse
[  662.815557] Preemption disabled at:
[  662.815558] [&lt;0000000000000000&gt;] 0x0
[  662.815563] CPU: 37 PID: 0 Comm: swapper/37 Kdump: loaded Tainted: G S         OE     5.17.1 #2
[  662.815566] Hardware name: Intel Corporation D50DNP/D50DNP, BIOS SE5C6301.86B.6624.D18.2111021741 11/02/2021
[  662.815568] Call Trace:
[  662.815572]  &lt;IRQ&gt;
[  662.815574]  dump_stack_lvl+0x33/0x42
[  662.815581]  __schedule_bug.cold.147+0x7d/0x8a
[  662.815588]  __schedule+0x798/0x990
[  662.815595]  schedule+0x44/0xc0
[  662.815597]  schedule_preempt_disabled+0x14/0x20
[  662.815600]  __mutex_lock.isra.11+0x46c/0x490
[  662.815603]  ? __ibdev_printk+0x76/0xc0 [ib_core]
[  662.815633]  device_del+0x37/0x3d0
[  662.815639]  ice_unplug_aux_dev+0x1a/0x40 [ice]
[  662.815674]  ice_schedule_reset+0x3c/0xd0 [ice]
[  662.815693]  irdma_iidc_event_handler.cold.7+0xb6/0xd3 [irdma]
[  662.815712]  ? bitmap_find_next_zero_area_off+0x45/0xa0
[  662.815719]  ice_send_event_to_aux+0x54/0x70 [ice]
[  662.815741]  ice_misc_intr+0x21d/0x2d0 [ice]
[  662.815756]  __handle_irq_event_percpu+0x4c/0x180
[  662.815762]  handle_irq_event_percpu+0xf/0x40
[  662.815764]  handle_irq_event+0x34/0x60
[  662.815766]  handle_edge_irq+0x9a/0x1c0
[  662.815770]  __common_interrupt+0x62/0x100
[  662.815774]  common_interrupt+0xb4/0xd0
[  662.815779]  &lt;/IRQ&gt;
[  662.815780]  &lt;TASK&gt;
[  662.815780]  asm_common_interrupt+0x1e/0x40
[  662.815785] RIP: 0010:cpuidle_enter_state+0xd6/0x380
[  662.815789] Code: 49 89 c4 0f 1f 44 00 00 31 ff e8 65 d7 95 ff 45 84 ff 74 12 9c 58 f6 c4 02 0f 85 64 02 00 00 31 ff e8 ae c5 9c ff fb 45 85 f6 &lt;0f&gt; 88 12 01 00 00 49 63 d6 4c 2b 24 24 48 8d 04 52 48 8d 04 82 49
[  662.815791] RSP: 0018:ff2c2c4f18edbe80 EFLAGS: 00000202
[  662.815793] RAX: ff280805df140000 RBX: 0000000000000002 RCX: 000000000000001f
[  662.815795] RDX: 0000009a52da2d08 R
---truncated---</Note>
    </Notes>
    <CVE>CVE-2022-48653</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nfnetlink_osf: fix possible bogus match in nf_osf_find()

nf_osf_find() incorrectly returns true on mismatch, this leads to
copying uninitialized memory area in nft_osf which can be used to leak
stale kernel stack data to userspace.</Note>
    </Notes>
    <CVE>CVE-2022-48654</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

firmware: arm_scmi: Harden accesses to the reset domains

Accessing reset domains descriptors by the index upon the SCMI drivers
requests through the SCMI reset operations interface can potentially
lead to out-of-bound violations if the SCMI driver misbehave.

Add an internal consistency check before any such domains descriptors
accesses.</Note>
    </Notes>
    <CVE>CVE-2022-48655</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dmaengine: ti: k3-udma-private: Fix refcount leak bug in of_xudma_dev_get()

We should call of_node_put() for the reference returned by
of_parse_phandle() in fail path or when it is not used anymore.
Here we only need to move the of_node_put() before the check.</Note>
    </Notes>
    <CVE>CVE-2022-48656</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

arm64: topology: fix possible overflow in amu_fie_setup()

cpufreq_get_hw_max_freq() returns max frequency in kHz as *unsigned int*,
while freq_inv_set_max_ratio() gets passed this frequency in Hz as 'u64'.
Multiplying max frequency by 1000 can potentially result in overflow --
multiplying by 1000ULL instead should avoid that...

Found by Linux Verification Center (linuxtesting.org) with the SVACE static
analysis tool.</Note>
    </Notes>
    <CVE>CVE-2022-48657</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm: slub: fix flush_cpu_slab()/__free_slab() invocations in task context.

Commit 5a836bf6b09f ("mm: slub: move flush_cpu_slab() invocations
__free_slab() invocations out of IRQ context") moved all flush_cpu_slab()
invocations to the global workqueue to avoid a problem related
with deactivate_slab()/__free_slab() being called from an IRQ context
on PREEMPT_RT kernels.

When the flush_all_cpu_locked() function is called from a task context
it may happen that a workqueue with WQ_MEM_RECLAIM bit set ends up
flushing the global workqueue, this will cause a dependency issue.

 workqueue: WQ_MEM_RECLAIM nvme-delete-wq:nvme_delete_ctrl_work [nvme_core]
   is flushing !WQ_MEM_RECLAIM events:flush_cpu_slab
 WARNING: CPU: 37 PID: 410 at kernel/workqueue.c:2637
   check_flush_dependency+0x10a/0x120
 Workqueue: nvme-delete-wq nvme_delete_ctrl_work [nvme_core]
 RIP: 0010:check_flush_dependency+0x10a/0x120[  453.262125] Call Trace:
 __flush_work.isra.0+0xbf/0x220
 ? __queue_work+0x1dc/0x420
 flush_all_cpus_locked+0xfb/0x120
 __kmem_cache_shutdown+0x2b/0x320
 kmem_cache_destroy+0x49/0x100
 bioset_exit+0x143/0x190
 blk_release_queue+0xb9/0x100
 kobject_cleanup+0x37/0x130
 nvme_fc_ctrl_free+0xc6/0x150 [nvme_fc]
 nvme_free_ctrl+0x1ac/0x2b0 [nvme_core]

Fix this bug by creating a workqueue for the flush operation with
the WQ_MEM_RECLAIM bit set.</Note>
    </Notes>
    <CVE>CVE-2022-48658</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix to return errno if kmalloc() fails

In create_unique_id(), kmalloc(, GFP_KERNEL) can fail due to
out-of-memory, if it fails, return errno correctly rather than
triggering panic via BUG_ON();

kernel BUG at mm/slub.c:5893!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP

Call trace:
 sysfs_slab_add+0x258/0x260 mm/slub.c:5973
 __kmem_cache_create+0x60/0x118 mm/slub.c:4899
 create_cache mm/slab_common.c:229 [inline]
 kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335
 kmem_cache_create+0x1c/0x28 mm/slab_common.c:390
 f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [inline]
 f2fs_init_xattr_caches+0x78/0xb4 fs/f2fs/xattr.c:808
 f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149
 mount_bdev+0x1b8/0x210 fs/super.c:1400
 f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512
 legacy_get_tree+0x30/0x74 fs/fs_context.c:610
 vfs_get_tree+0x40/0x140 fs/super.c:1530
 do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040
 path_mount+0x358/0x914 fs/namespace.c:3370
 do_mount fs/namespace.c:3383 [inline]
 __do_sys_mount fs/namespace.c:3591 [inline]
 __se_sys_mount fs/namespace.c:3568 [inline]
 __arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568</Note>
    </Notes>
    <CVE>CVE-2022-48659</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gpiolib: cdev: Set lineevent_state::irq after IRQ register successfully

When running gpio test on nxp-ls1028 platform with below command
gpiomon --num-events=3 --rising-edge gpiochip1 25
There will be a warning trace as below:
Call trace:
free_irq+0x204/0x360
lineevent_free+0x64/0x70
gpio_ioctl+0x598/0x6a0
__arm64_sys_ioctl+0xb4/0x100
invoke_syscall+0x5c/0x130
......
el0t_64_sync+0x1a0/0x1a4
The reason of this issue is that calling request_threaded_irq()
function failed, and then lineevent_free() is invoked to release
the resource. Since the lineevent_state::irq was already set, so
the subsequent invocation of free_irq() would trigger the above
warning call trace. To fix this issue, set the lineevent_state::irq
after the IRQ register successfully.</Note>
    </Notes>
    <CVE>CVE-2022-48660</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/i915/gem: Really move i915_gem_context.link under ref protection

i915_perf assumes that it can use the i915_gem_context reference to
protect its i915-&gt;gem.contexts.list iteration. However, this requires
that we do not remove the context from the list until after we drop the
final reference and release the struct. If, as currently, we remove the
context from the list during context_close(), the link.next pointer may
be poisoned while we are holding the context reference and cause a GPF:

[ 4070.573157] i915 0000:00:02.0: [drm:i915_perf_open_ioctl [i915]] filtering on ctx_id=0x1fffff ctx_id_mask=0x1fffff
[ 4070.574881] general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP
[ 4070.574897] CPU: 1 PID: 284392 Comm: amd_performance Tainted: G            E     5.17.9 #180
[ 4070.574903] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017
[ 4070.574907] RIP: 0010:oa_configure_all_contexts.isra.0+0x222/0x350 [i915]
[ 4070.574982] Code: 08 e8 32 6e 10 e1 4d 8b 6d 50 b8 ff ff ff ff 49 83 ed 50 f0 41 0f c1 04 24 83 f8 01 0f 84 e3 00 00 00 85 c0 0f 8e fa 00 00 00 &lt;49&gt; 8b 45 50 48 8d 70 b0 49 8d 45 50 48 39 44 24 10 0f 85 34 fe ff
[ 4070.574990] RSP: 0018:ffffc90002077b78 EFLAGS: 00010202
[ 4070.574995] RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000000
[ 4070.575000] RDX: 0000000000000001 RSI: ffffc90002077b20 RDI: ffff88810ddc7c68
[ 4070.575004] RBP: 0000000000000001 R08: ffff888103242648 R09: fffffffffffffffc
[ 4070.575008] R10: ffffffff82c50bc0 R11: 0000000000025c80 R12: ffff888101bf1860
[ 4070.575012] R13: dead0000000000b0 R14: ffffc90002077c04 R15: ffff88810be5cabc
[ 4070.575016] FS:  00007f1ed50c0780(0000) GS:ffff88885ec80000(0000) knlGS:0000000000000000
[ 4070.575021] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4070.575025] CR2: 00007f1ed5590280 CR3: 000000010ef6f005 CR4: 00000000003706e0
[ 4070.575029] Call Trace:
[ 4070.575033]  &lt;TASK&gt;
[ 4070.575037]  lrc_configure_all_contexts+0x13e/0x150 [i915]
[ 4070.575103]  gen8_enable_metric_set+0x4d/0x90 [i915]
[ 4070.575164]  i915_perf_open_ioctl+0xbc0/0x1500 [i915]
[ 4070.575224]  ? asm_common_interrupt+0x1e/0x40
[ 4070.575232]  ? i915_oa_init_reg_state+0x110/0x110 [i915]
[ 4070.575290]  drm_ioctl_kernel+0x85/0x110
[ 4070.575296]  ? update_load_avg+0x5f/0x5e0
[ 4070.575302]  drm_ioctl+0x1d3/0x370
[ 4070.575307]  ? i915_oa_init_reg_state+0x110/0x110 [i915]
[ 4070.575382]  ? gen8_gt_irq_handler+0x46/0x130 [i915]
[ 4070.575445]  __x64_sys_ioctl+0x3c4/0x8d0
[ 4070.575451]  ? __do_softirq+0xaa/0x1d2
[ 4070.575456]  do_syscall_64+0x35/0x80
[ 4070.575461]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 4070.575467] RIP: 0033:0x7f1ed5c10397
[ 4070.575471] Code: 3c 1c e8 1c ff ff ff 85 c0 79 87 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d a9 da 0d 00 f7 d8 64 89 01 48
[ 4070.575478] RSP: 002b:00007ffd65c8d7a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 4070.575484] RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 00007f1ed5c10397
[ 4070.575488] RDX: 00007ffd65c8d7c0 RSI: 0000000040106476 RDI: 0000000000000006
[ 4070.575492] RBP: 00005620972f9c60 R08: 000000000000000a R09: 0000000000000005
[ 4070.575496] R10: 000000000000000d R11: 0000000000000246 R12: 000000000000000a
[ 4070.575500] R13: 000000000000000d R14: 0000000000000000 R15: 00007ffd65c8d7c0
[ 4070.575505]  &lt;/TASK&gt;
[ 4070.575507] Modules linked in: nls_ascii(E) nls_cp437(E) vfat(E) fat(E) i915(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) aesni_intel(E) crypto_simd(E) intel_gtt(E) cryptd(E) ttm(E) rapl(E) intel_cstate(E) drm_kms_helper(E) cfbfillrect(E) syscopyarea(E) cfbimgblt(E) intel_uncore(E) sysfillrect(E) mei_me(E) sysimgblt(E) i2c_i801(E) fb_sys_fops(E) mei(E) intel_pch_thermal(E) i2c_smbus
---truncated---</Note>
    </Notes>
    <CVE>CVE-2022-48662</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gpio: mockup: fix NULL pointer dereference when removing debugfs

We now remove the device's debugfs entries when unbinding the driver.
This now causes a NULL-pointer dereference on module exit because the
platform devices are unregistered *after* the global debugfs directory
has been recursively removed. Fix it by unregistering the devices first.</Note>
    </Notes>
    <CVE>CVE-2022-48663</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

smb3: fix temporary data corruption in insert range

insert range doesn't discard the affected cached region
so can risk temporarily corrupting file data.

Also includes some minor cleanup (avoiding rereading
inode size repeatedly unnecessarily) to make it clearer.</Note>
    </Notes>
    <CVE>CVE-2022-48667</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

smb3: fix temporary data corruption in collapse range

collapse range doesn't discard the affected cached region
so can risk temporarily corrupting the file data. This
fixes xfstest generic/031

I also decided to merge a minor cleanup to this into the same patch
(avoiding rereading inode size repeatedly unnecessarily) to make it
clearer.</Note>
    </Notes>
    <CVE>CVE-2022-48668</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cgroup: Add missing cpus_read_lock() to cgroup_attach_task_all()

syzbot is hitting percpu_rwsem_assert_held(&amp;cpu_hotplug_lock) warning at
cpuset_attach() [1], for commit 4f7e7236435ca0ab ("cgroup: Fix
threadgroup_rwsem &lt;-&gt; cpus_read_lock() deadlock") missed that
cpuset_attach() is also called from cgroup_attach_task_all().
Add cpus_read_lock() like what cgroup_procs_write_start() does.</Note>
    </Notes>
    <CVE>CVE-2022-48671</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

of: fdt: fix off-by-one error in unflatten_dt_nodes()

Commit 78c44d910d3e ("drivers/of: Fix depth when unflattening devicetree")
forgot to fix up the depth check in the loop body in unflatten_dt_nodes()
which makes it possible to overflow the nps[] buffer...

Found by Linux Verification Center (linuxtesting.org) with the SVACE static
analysis tool.</Note>
    </Notes>
    <CVE>CVE-2022-48672</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/smc: Fix possible access to freed memory in link clear

After modifying the QP to the Error state, all RX WR would be completed
with WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not
wait for it is done, but destroy the QP and free the link group directly.
So there is a risk that accessing the freed memory in tasklet context.

Here is a crash example:

 BUG: unable to handle page fault for address: ffffffff8f220860
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060
 Oops: 0002 [#1] SMP PTI
 CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S         OE     5.10.0-0607+ #23
 Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018
 RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0
 Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e &lt;48&gt; 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32
 RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086
 RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000
 RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00
 RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b
 R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010
 R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040
 FS:  0000000000000000(0000) GS:ffff91db1f840000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: ffffffff8f220860 CR3: 00000001f9580004 CR4: 00000000003706e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 Call Trace:
  &lt;IRQ&gt;
  _raw_spin_lock_irqsave+0x30/0x40
  mlx5_ib_poll_cq+0x4c/0xc50 [mlx5_ib]
  smc_wr_rx_tasklet_fn+0x56/0xa0 [smc]
  tasklet_action_common.isra.21+0x66/0x100
  __do_softirq+0xd5/0x29c
  asm_call_irq_on_stack+0x12/0x20
  &lt;/IRQ&gt;
  do_softirq_own_stack+0x37/0x40
  irq_exit_rcu+0x9d/0xa0
  sysvec_call_function_single+0x34/0x80
  asm_sysvec_call_function_single+0x12/0x20</Note>
    </Notes>
    <CVE>CVE-2022-48673</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

IB/core: Fix a nested dead lock as part of ODP flow

Fix a nested dead lock as part of ODP flow by using mmput_async().

From the below call trace [1] can see that calling mmput() once we have
the umem_odp-&gt;umem_mutex locked as required by
ib_umem_odp_map_dma_and_lock() might trigger in the same task the
exit_mmap()-&gt;__mmu_notifier_release()-&gt;mlx5_ib_invalidate_range() which
may dead lock when trying to lock the same mutex.

Moving to use mmput_async() will solve the problem as the above
exit_mmap() flow will be called in other task and will be executed once
the lock will be available.

[1]
[64843.077665] task:kworker/u133:2  state:D stack:    0 pid:80906 ppid:
2 flags:0x00004000
[64843.077672] Workqueue: mlx5_ib_page_fault mlx5_ib_eqe_pf_action [mlx5_ib]
[64843.077719] Call Trace:
[64843.077722]  &lt;TASK&gt;
[64843.077724]  __schedule+0x23d/0x590
[64843.077729]  schedule+0x4e/0xb0
[64843.077735]  schedule_preempt_disabled+0xe/0x10
[64843.077740]  __mutex_lock.constprop.0+0x263/0x490
[64843.077747]  __mutex_lock_slowpath+0x13/0x20
[64843.077752]  mutex_lock+0x34/0x40
[64843.077758]  mlx5_ib_invalidate_range+0x48/0x270 [mlx5_ib]
[64843.077808]  __mmu_notifier_release+0x1a4/0x200
[64843.077816]  exit_mmap+0x1bc/0x200
[64843.077822]  ? walk_page_range+0x9c/0x120
[64843.077828]  ? __cond_resched+0x1a/0x50
[64843.077833]  ? mutex_lock+0x13/0x40
[64843.077839]  ? uprobe_clear_state+0xac/0x120
[64843.077860]  mmput+0x5f/0x140
[64843.077867]  ib_umem_odp_map_dma_and_lock+0x21b/0x580 [ib_core]
[64843.077931]  pagefault_real_mr+0x9a/0x140 [mlx5_ib]
[64843.077962]  pagefault_mr+0xb4/0x550 [mlx5_ib]
[64843.077992]  pagefault_single_data_segment.constprop.0+0x2ac/0x560
[mlx5_ib]
[64843.078022]  mlx5_ib_eqe_pf_action+0x528/0x780 [mlx5_ib]
[64843.078051]  process_one_work+0x22b/0x3d0
[64843.078059]  worker_thread+0x53/0x410
[64843.078065]  ? process_one_work+0x3d0/0x3d0
[64843.078073]  kthread+0x12a/0x150
[64843.078079]  ? set_kthread_struct+0x50/0x50
[64843.078085]  ret_from_fork+0x22/0x30
[64843.078093]  &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2022-48675</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nvme-tcp: fix UAF when detecting digest errors

We should also bail from the io_work loop when we set rd_enabled to true,
so we don't attempt to read data from the socket when the TCP stream is
already out-of-sync or corrupted.</Note>
    </Notes>
    <CVE>CVE-2022-48686</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i40e: Fix kernel crash during module removal

The driver incorrectly frees client instance and subsequent
i40e module removal leads to kernel crash.

Reproducer:
1. Do ethtool offline test followed immediately by another one
host# ethtool -t eth0 offline; ethtool -t eth0 offline
2. Remove recursively irdma module that also removes i40e module
host# modprobe -r irdma

Result:
[ 8675.035651] i40e 0000:3d:00.0 eno1: offline testing starting
[ 8675.193774] i40e 0000:3d:00.0 eno1: testing finished
[ 8675.201316] i40e 0000:3d:00.0 eno1: offline testing starting
[ 8675.358921] i40e 0000:3d:00.0 eno1: testing finished
[ 8675.496921] i40e 0000:3d:00.0: IRDMA hardware initialization FAILED init_state=2 status=-110
[ 8686.188955] i40e 0000:3d:00.1: i40e_ptp_stop: removed PHC on eno2
[ 8686.943890] i40e 0000:3d:00.1: Deleted LAN device PF1 bus=0x3d dev=0x00 func=0x01
[ 8686.952669] i40e 0000:3d:00.0: i40e_ptp_stop: removed PHC on eno1
[ 8687.761787] BUG: kernel NULL pointer dereference, address: 0000000000000030
[ 8687.768755] #PF: supervisor read access in kernel mode
[ 8687.773895] #PF: error_code(0x0000) - not-present page
[ 8687.779034] PGD 0 P4D 0
[ 8687.781575] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 8687.785935] CPU: 51 PID: 172891 Comm: rmmod Kdump: loaded Tainted: G        W I        5.19.0+ #2
[ 8687.794800] Hardware name: Intel Corporation S2600WFD/S2600WFD, BIOS SE5C620.86B.0X.02.0001.051420190324 05/14/2019
[ 8687.805222] RIP: 0010:i40e_lan_del_device+0x13/0xb0 [i40e]
[ 8687.810719] Code: d4 84 c0 0f 84 b8 25 01 00 e9 9c 25 01 00 41 bc f4 ff ff ff eb 91 90 0f 1f 44 00 00 41 54 55 53 48 8b 87 58 08 00 00 48 89 fb &lt;48&gt; 8b 68 30 48 89 ef e8 21 8a 0f d5 48 89 ef e8 a9 78 0f d5 48 8b
[ 8687.829462] RSP: 0018:ffffa604072efce0 EFLAGS: 00010202
[ 8687.834689] RAX: 0000000000000000 RBX: ffff8f43833b2000 RCX: 0000000000000000
[ 8687.841821] RDX: 0000000000000000 RSI: ffff8f4b0545b298 RDI: ffff8f43833b2000
[ 8687.848955] RBP: ffff8f43833b2000 R08: 0000000000000001 R09: 0000000000000000
[ 8687.856086] R10: 0000000000000000 R11: 000ffffffffff000 R12: ffff8f43833b2ef0
[ 8687.863218] R13: ffff8f43833b2ef0 R14: ffff915103966000 R15: ffff8f43833b2008
[ 8687.870342] FS:  00007f79501c3740(0000) GS:ffff8f4adffc0000(0000) knlGS:0000000000000000
[ 8687.878427] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 8687.884174] CR2: 0000000000000030 CR3: 000000014276e004 CR4: 00000000007706e0
[ 8687.891306] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 8687.898441] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 8687.905572] PKRU: 55555554
[ 8687.908286] Call Trace:
[ 8687.910737]  &lt;TASK&gt;
[ 8687.912843]  i40e_remove+0x2c0/0x330 [i40e]
[ 8687.917040]  pci_device_remove+0x33/0xa0
[ 8687.920962]  device_release_driver_internal+0x1aa/0x230
[ 8687.926188]  driver_detach+0x44/0x90
[ 8687.929770]  bus_remove_driver+0x55/0xe0
[ 8687.933693]  pci_unregister_driver+0x2a/0xb0
[ 8687.937967]  i40e_exit_module+0xc/0xf48 [i40e]

Two offline tests cause IRDMA driver failure (ETIMEDOUT) and this
failure is indicated back to i40e_client_subtask() that calls
i40e_client_del_instance() to free client instance referenced
by pf-&gt;cinst and sets this pointer to NULL. During the module
removal i40e_remove() calls i40e_lan_del_device() that dereferences
pf-&gt;cinst that is NULL -&gt; crash.
Do not remove client instance when client open callbacks fails and
just clear __I40E_CLIENT_INSTANCE_OPENED bit. The driver also needs
to take care about this situation (when netdev is up and client
is NOT opened) in i40e_notify_client_of_netdev_close() and
calls client close callback only when __I40E_CLIENT_INSTANCE_OPENED
is set.</Note>
    </Notes>
    <CVE>CVE-2022-48688</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 DMA mappings leak

Fix leak, when user changes ring parameters.
During reallocation of RX buffers, new DMA mappings are created for
those buffers. New buffers with different RX ring count should
substitute older ones, but those buffers were freed in ice_vsi_cfg_rxq
and reallocated again with ice_alloc_rx_buf. kfree on rx_buf caused
leak of already mapped DMA.
Reallocate ZC with xdp_buf struct, when BPF program loads. Reallocate
back to rx_buf, when BPF program unloads.
If BPF program is loaded/unloaded and XSK pools are created, reallocate
RX queues accordingly in XDP_SETUP_XSK_POOL handler.

Steps for reproduction:
while :
do
	for ((i=0; i&lt;=8160; i=i+32))
	do
		ethtool -G enp130s0f0 rx $i tx $i
		sleep 0.5
		ethtool -g enp130s0f0
	done
done</Note>
    </Notes>
    <CVE>CVE-2022-48690</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/srp: Set scmnd-&gt;result only when scmnd is not NULL

This change fixes the following kernel NULL pointer dereference
which is reproduced by blktests srp/007 occasionally.

BUG: kernel NULL pointer dereference, address: 0000000000000170
PGD 0 P4D 0
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 9 Comm: kworker/0:1H Kdump: loaded Not tainted 6.0.0-rc1+ #37
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-29-g6a62e0cb0dfe-prebuilt.qemu.org 04/01/2014
Workqueue:  0x0 (kblockd)
RIP: 0010:srp_recv_done+0x176/0x500 [ib_srp]
Code: 00 4d 85 ff 0f 84 52 02 00 00 48 c7 82 80 02 00 00 00 00 00 00 4c 89 df 4c 89 14 24 e8 53 d3 4a f6 4c 8b 14 24 41 0f b6 42 13 &lt;41&gt; 89 87 70 01 00 00 41 0f b6 52 12 f6 c2 02 74 44 41 8b 42 1c b9
RSP: 0018:ffffaef7c0003e28 EFLAGS: 00000282
RAX: 0000000000000000 RBX: ffff9bc9486dea60 RCX: 0000000000000000
RDX: 0000000000000102 RSI: ffffffffb76bbd0e RDI: 00000000ffffffff
RBP: ffff9bc980099a00 R08: 0000000000000001 R09: 0000000000000001
R10: ffff9bca53ef0000 R11: ffff9bc980099a10 R12: ffff9bc956e14000
R13: ffff9bc9836b9cb0 R14: ffff9bc9557b4480 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff9bc97ec00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000170 CR3: 0000000007e04000 CR4: 00000000000006f0
Call Trace:
 &lt;IRQ&gt;
 __ib_process_cq+0xb7/0x280 [ib_core]
 ib_poll_handler+0x2b/0x130 [ib_core]
 irq_poll_softirq+0x93/0x150
 __do_softirq+0xee/0x4b8
 irq_exit_rcu+0xf7/0x130
 sysvec_apic_timer_interrupt+0x8e/0xc0
 &lt;/IRQ&gt;</Note>
    </Notes>
    <CVE>CVE-2022-48692</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugs

In brcmstb_pm_probe(), there are two kinds of leak bugs:

(1) we need to add of_node_put() when for_each__matching_node() breaks
(2) we need to add iounmap() for each iomap in fail path</Note>
    </Notes>
    <CVE>CVE-2022-48693</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/irdma: Fix drain SQ hang with no completion

SW generated completions for outstanding WRs posted on SQ
after QP is in error target the wrong CQ. This causes the
ib_drain_sq to hang with no completion.

Fix this to generate completions on the right CQ.

[  863.969340] INFO: task kworker/u52:2:671 blocked for more than 122 seconds.
[  863.979224]       Not tainted 5.14.0-130.el9.x86_64 #1
[  863.986588] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  863.996997] task:kworker/u52:2   state:D stack:    0 pid:  671 ppid:     2 flags:0x00004000
[  864.007272] Workqueue: xprtiod xprt_autoclose [sunrpc]
[  864.014056] Call Trace:
[  864.017575]  __schedule+0x206/0x580
[  864.022296]  schedule+0x43/0xa0
[  864.026736]  schedule_timeout+0x115/0x150
[  864.032185]  __wait_for_common+0x93/0x1d0
[  864.037717]  ? usleep_range_state+0x90/0x90
[  864.043368]  __ib_drain_sq+0xf6/0x170 [ib_core]
[  864.049371]  ? __rdma_block_iter_next+0x80/0x80 [ib_core]
[  864.056240]  ib_drain_sq+0x66/0x70 [ib_core]
[  864.062003]  rpcrdma_xprt_disconnect+0x82/0x3b0 [rpcrdma]
[  864.069365]  ? xprt_prepare_transmit+0x5d/0xc0 [sunrpc]
[  864.076386]  xprt_rdma_close+0xe/0x30 [rpcrdma]
[  864.082593]  xprt_autoclose+0x52/0x100 [sunrpc]
[  864.088718]  process_one_work+0x1e8/0x3c0
[  864.094170]  worker_thread+0x50/0x3b0
[  864.099109]  ? rescuer_thread+0x370/0x370
[  864.104473]  kthread+0x149/0x170
[  864.109022]  ? set_kthread_struct+0x40/0x40
[  864.114713]  ret_from_fork+0x22/0x30</Note>
    </Notes>
    <CVE>CVE-2022-48694</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 use-after-free warning

Fix the following use-after-free warning which is observed during
controller reset:

refcount_t: underflow; use-after-free.
WARNING: CPU: 23 PID: 5399 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0</Note>
    </Notes>
    <CVE>CVE-2022-48695</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nvmet: fix a use-after-free

Fix the following use-after-free complaint triggered by blktests nvme/004:

BUG: KASAN: user-memory-access in blk_mq_complete_request_remote+0xac/0x350
Read of size 4 at addr 0000607bd1835943 by task kworker/13:1/460
Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop]
Call Trace:
 show_stack+0x52/0x58
 dump_stack_lvl+0x49/0x5e
 print_report.cold+0x36/0x1e2
 kasan_report+0xb9/0xf0
 __asan_load4+0x6b/0x80
 blk_mq_complete_request_remote+0xac/0x350
 nvme_loop_queue_response+0x1df/0x275 [nvme_loop]
 __nvmet_req_complete+0x132/0x4f0 [nvmet]
 nvmet_req_complete+0x15/0x40 [nvmet]
 nvmet_execute_io_connect+0x18a/0x1f0 [nvmet]
 nvme_loop_execute_work+0x20/0x30 [nvme_loop]
 process_one_work+0x56e/0xa70
 worker_thread+0x2d1/0x640
 kthread+0x183/0x1c0
 ret_from_fork+0x1f/0x30</Note>
    </Notes>
    <CVE>CVE-2022-48697</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: fix memory leak when using debugfs_lookup()

When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time.  Fix this up by properly
calling dput().</Note>
    </Notes>
    <CVE>CVE-2022-48698</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2022-48700</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb-audio: Fix an out-of-bounds bug in __snd_usb_parse_audio_interface()

There may be a bad USB audio device with a USB ID of (0x04fa, 0x4201) and
the number of it's interfaces less than 4, an out-of-bounds read bug occurs
when parsing the interface descriptor for this device.

Fix this by checking the number of interfaces.</Note>
    </Notes>
    <CVE>CVE-2022-48701</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: emu10k1: Fix out of bounds access in snd_emu10k1_pcm_channel_alloc()

The voice allocator sometimes begins allocating from near the end of the
array and then wraps around, however snd_emu10k1_pcm_channel_alloc()
accesses the newly allocated voices as if it never wrapped around.

This results in out of bounds access if the first voice has a high enough
index so that first_voice + requested_voice_count &gt; NUM_G (64).
The more voices are requested, the more likely it is for this to occur.

This was initially discovered using PipeWire, however it can be reproduced
by calling aplay multiple times with 16 channels:
aplay -r 48000 -D plughw:CARD=Live,DEV=3 -c 16 /dev/zero

UBSAN: array-index-out-of-bounds in sound/pci/emu10k1/emupcm.c:127:40
index 65 is out of range for type 'snd_emu10k1_voice [64]'
CPU: 1 PID: 31977 Comm: aplay Tainted: G        W IOE      6.0.0-rc2-emu10k1+ #7
Hardware name: ASUSTEK COMPUTER INC P5W DH Deluxe/P5W DH Deluxe, BIOS 3002    07/22/2010
Call Trace:
&lt;TASK&gt;
dump_stack_lvl+0x49/0x63
dump_stack+0x10/0x16
ubsan_epilogue+0x9/0x3f
__ubsan_handle_out_of_bounds.cold+0x44/0x49
snd_emu10k1_playback_hw_params+0x3bc/0x420 [snd_emu10k1]
snd_pcm_hw_params+0x29f/0x600 [snd_pcm]
snd_pcm_common_ioctl+0x188/0x1410 [snd_pcm]
? exit_to_user_mode_prepare+0x35/0x170
? do_syscall_64+0x69/0x90
? syscall_exit_to_user_mode+0x26/0x50
? do_syscall_64+0x69/0x90
? exit_to_user_mode_prepare+0x35/0x170
snd_pcm_ioctl+0x27/0x40 [snd_pcm]
__x64_sys_ioctl+0x95/0xd0
do_syscall_64+0x5c/0x90
? do_syscall_64+0x69/0x90
? do_syscall_64+0x69/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd</Note>
    </Notes>
    <CVE>CVE-2022-48702</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR

In some case, the GDDV returns a package with a buffer which has
zero length. It causes that kmemdup() returns ZERO_SIZE_PTR (0x10).

Then the data_vault_read() got NULL point dereference problem when
accessing the 0x10 value in data_vault.

[   71.024560] BUG: kernel NULL pointer dereference, address:
0000000000000010

This patch uses ZERO_OR_NULL_PTR() for checking ZERO_SIZE_PTR or
NULL value in data_vault.</Note>
    </Notes>
    <CVE>CVE-2022-48703</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/radeon: add a force flush to delay work when radeon

Although radeon card fence and wait for gpu to finish processing current batch rings,
there is still a corner case that radeon lockup work queue may not be fully flushed,
and meanwhile the radeon_suspend_kms() function has called pci_set_power_state() to
put device in D3hot state.
Per PCI spec rev 4.0 on 5.3.1.4.1 D3hot State.
&gt; Configuration and Message requests are the only TLPs accepted by a Function in
&gt; the D3hot state. All other received Requests must be handled as Unsupported Requests,
&gt; and all received Completions may optionally be handled as Unexpected Completions.
This issue will happen in following logs:
Unable to handle kernel paging request at virtual address 00008800e0008010
CPU 0 kworker/0:3(131): Oops 0
pc = [&lt;ffffffff811bea5c&gt;]  ra = [&lt;ffffffff81240844&gt;]  ps = 0000 Tainted: G        W
pc is at si_gpu_check_soft_reset+0x3c/0x240
ra is at si_dma_is_lockup+0x34/0xd0
v0 = 0000000000000000  t0 = fff08800e0008010  t1 = 0000000000010000
t2 = 0000000000008010  t3 = fff00007e3c00000  t4 = fff00007e3c00258
t5 = 000000000000ffff  t6 = 0000000000000001  t7 = fff00007ef078000
s0 = fff00007e3c016e8  s1 = fff00007e3c00000  s2 = fff00007e3c00018
s3 = fff00007e3c00000  s4 = fff00007fff59d80  s5 = 0000000000000000
s6 = fff00007ef07bd98
a0 = fff00007e3c00000  a1 = fff00007e3c016e8  a2 = 0000000000000008
a3 = 0000000000000001  a4 = 8f5c28f5c28f5c29  a5 = ffffffff810f4338
t8 = 0000000000000275  t9 = ffffffff809b66f8  t10 = ff6769c5d964b800
t11= 000000000000b886  pv = ffffffff811bea20  at = 0000000000000000
gp = ffffffff81d89690  sp = 00000000aa814126
Disabling lock debugging due to kernel taint
Trace:
[&lt;ffffffff81240844&gt;] si_dma_is_lockup+0x34/0xd0
[&lt;ffffffff81119610&gt;] radeon_fence_check_lockup+0xd0/0x290
[&lt;ffffffff80977010&gt;] process_one_work+0x280/0x550
[&lt;ffffffff80977350&gt;] worker_thread+0x70/0x7c0
[&lt;ffffffff80977410&gt;] worker_thread+0x130/0x7c0
[&lt;ffffffff80982040&gt;] kthread+0x200/0x210
[&lt;ffffffff809772e0&gt;] worker_thread+0x0/0x7c0
[&lt;ffffffff80981f8c&gt;] kthread+0x14c/0x210
[&lt;ffffffff80911658&gt;] ret_from_kernel_thread+0x18/0x20
[&lt;ffffffff80981e40&gt;] kthread+0x0/0x210
 Code: ad3e0008  43f0074a  ad7e0018  ad9e0020  8c3001e8  40230101
 &lt;88210000&gt; 4821ed21
So force lockup work queue flush to fix this problem.</Note>
    </Notes>
    <CVE>CVE-2022-48704</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An out-of-bounds read vulnerability was found in the SR-IPv6 implementation in the Linux kernel. The flaw exists within the processing of seg6 attributes. The issue results from the improper validation of user-supplied data, which can result in a read past the end of an allocated buffer. This flaw allows a privileged local user to disclose sensitive information on affected installations of the Linux kernel.</Note>
    </Notes>
    <CVE>CVE-2023-2860</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFO

The SC16IS7XX IC supports a burst mode to access the FIFOs where the
initial register address is sent ($00), followed by all the FIFO data
without having to resend the register address each time. In this mode, the
IC doesn't increment the register address for each R/W byte.

The regmap_raw_read() and regmap_raw_write() are functions which can
perform IO over multiple registers. They are currently used to read/write
from/to the FIFO, and although they operate correctly in this burst mode on
the SPI bus, they would corrupt the regmap cache if it was not disabled
manually. The reason is that when the R/W size is more than 1 byte, these
functions assume that the register address is incremented and handle the
cache accordingly.

Convert FIFO R/W functions to use the regmap _noinc_ versions in order to
remove the manual cache control which was a workaround when using the
_raw_ versions. FIFO registers are properly declared as volatile so
cache will not be used/updated for FIFO accesses.</Note>
    </Notes>
    <CVE>CVE-2023-52488</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 possible NULL dereference in amdgpu_ras_query_error_status_helper()

Return invalid error code -EINVAL for invalid block id.

Fixes the below:

drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1183 amdgpu_ras_query_error_status_helper() error: we previously assumed 'info' could be null (see line 1176)</Note>
    </Notes>
    <CVE>CVE-2023-52585</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: rkisp1: Fix IRQ disable race issue

In rkisp1_isp_stop() and rkisp1_csi_disable() the driver masks the
interrupts and then apparently assumes that the interrupt handler won't
be running, and proceeds in the stop procedure. This is not the case, as
the interrupt handler can already be running, which would lead to the
ISP being disabled while the interrupt handler handling a captured
frame.

This brings up two issues: 1) the ISP could be powered off while the
interrupt handler is still running and accessing registers, leading to
board lockup, and 2) the interrupt handler code and the code that
disables the streaming might do things that conflict.

It is not clear to me if 2) causes a real issue, but 1) can be seen with
a suitable delay (or printk in my case) in the interrupt handler,
leading to board lockup.</Note>
    </Notes>
    <CVE>CVE-2023-52589</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: wfx: fix possible NULL pointer dereference in wfx_set_mfp_ap()

Since 'ieee80211_beacon_get()' can return NULL, 'wfx_set_mfp_ap()'
should check the return value before examining skb data. So convert
the latter to return an appropriate error code and propagate it to
return from 'wfx_start_ap()' as well. Compile tested only.</Note>
    </Notes>
    <CVE>CVE-2023-52593</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix buffer overflow in trans_stat_show

Fix buffer overflow in trans_stat_show().

Convert simple snprintf to the more secure scnprintf with size of
PAGE_SIZE.

Add condition checking if we are exceeding PAGE_SIZE and exit early from
loop. Also add at the end a warning that we exceeded PAGE_SIZE and that
stats is disabled.

Return -EFBIG in the case where we don't have enough space to write the
full transition table.

Also document in the ABI that this function can return -EFBIG error.</Note>
    </Notes>
    <CVE>CVE-2023-52614</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: lib/mpi - Fix unexpected pointer access in mpi_ec_init

When the mpi_ec_ctx structure is initialized, some fields are not
cleared, causing a crash when referencing the field when the
structure was released. Initially, this issue was ignored because
memory for mpi_ec_ctx is allocated with the __GFP_ZERO flag.
For example, this error will be triggered when calculating the
Za value for SM2 separately.</Note>
    </Notes>
    <CVE>CVE-2023-52616</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: disallow timeout for anonymous sets

Never used from userspace, disallow these parameters.</Note>
    </Notes>
    <CVE>CVE-2023-52620</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Synchronize devfreq_monitor_[start/stop]

There is a chance if a frequent switch of the governor
done in a loop result in timer list corruption where
timer cancel being done from two place one from
cancel_delayed_work_sync() and followed by expire_timers()
can be seen from the traces[1].

while true
do
        echo "simple_ondemand" &gt; /sys/class/devfreq/1d84000.ufshc/governor
        echo "performance" &gt; /sys/class/devfreq/1d84000.ufshc/governor
done

It looks to be issue with devfreq driver where
device_monitor_[start/stop] need to synchronized so that
delayed work should get corrupted while it is either
being queued or running or being cancelled.

Let's use polling flag and devfreq lock to synchronize the
queueing the timer instance twice and work data being
corrupted.

[1]
...
..
&lt;idle&gt;-0    [003]   9436.209662:  timer_cancel   timer=0xffffff80444f0428
&lt;idle&gt;-0    [003]   9436.209664:  timer_expire_entry   timer=0xffffff80444f0428  now=0x10022da1c  function=__typeid__ZTSFvP10timer_listE_global_addr  baseclk=0x10022da1c
&lt;idle&gt;-0    [003]   9436.209718:  timer_expire_exit   timer=0xffffff80444f0428
kworker/u16:6-14217    [003]   9436.209863:  timer_start   timer=0xffffff80444f0428  function=__typeid__ZTSFvP10timer_listE_global_addr  expires=0x10022da2b  now=0x10022da1c  flags=182452227
vendor.xxxyyy.ha-1593    [004]   9436.209888:  timer_cancel   timer=0xffffff80444f0428
vendor.xxxyyy.ha-1593    [004]   9436.216390:  timer_init   timer=0xffffff80444f0428
vendor.xxxyyy.ha-1593    [004]   9436.216392:  timer_start   timer=0xffffff80444f0428  function=__typeid__ZTSFvP10timer_listE_global_addr  expires=0x10022da2c  now=0x10022da1d  flags=186646532
vendor.xxxyyy.ha-1593    [005]   9436.220992:  timer_cancel   timer=0xffffff80444f0428
xxxyyyTraceManag-7795    [004]   9436.261641:  timer_cancel   timer=0xffffff80444f0428

[2]

 9436.261653][    C4] Unable to handle kernel paging request at virtual address dead00000000012a
[ 9436.261664][    C4] Mem abort info:
[ 9436.261666][    C4]   ESR = 0x96000044
[ 9436.261669][    C4]   EC = 0x25: DABT (current EL), IL = 32 bits
[ 9436.261671][    C4]   SET = 0, FnV = 0
[ 9436.261673][    C4]   EA = 0, S1PTW = 0
[ 9436.261675][    C4] Data abort info:
[ 9436.261677][    C4]   ISV = 0, ISS = 0x00000044
[ 9436.261680][    C4]   CM = 0, WnR = 1
[ 9436.261682][    C4] [dead00000000012a] address between user and kernel address ranges
[ 9436.261685][    C4] Internal error: Oops: 96000044 [#1] PREEMPT SMP
[ 9436.261701][    C4] Skip md ftrace buffer dump for: 0x3a982d0
...

[ 9436.262138][    C4] CPU: 4 PID: 7795 Comm: TraceManag Tainted: G S      W  O      5.10.149-android12-9-o-g17f915d29d0c #1
[ 9436.262141][    C4] Hardware name: Qualcomm Technologies, Inc.  (DT)
[ 9436.262144][    C4] pstate: 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=--)
[ 9436.262161][    C4] pc : expire_timers+0x9c/0x438
[ 9436.262164][    C4] lr : expire_timers+0x2a4/0x438
[ 9436.262168][    C4] sp : ffffffc010023dd0
[ 9436.262171][    C4] x29: ffffffc010023df0 x28: ffffffd0636fdc18
[ 9436.262178][    C4] x27: ffffffd063569dd0 x26: ffffffd063536008
[ 9436.262182][    C4] x25: 0000000000000001 x24: ffffff88f7c69280
[ 9436.262185][    C4] x23: 00000000000000e0 x22: dead000000000122
[ 9436.262188][    C4] x21: 000000010022da29 x20: ffffff8af72b4e80
[ 9436.262191][    C4] x19: ffffffc010023e50 x18: ffffffc010025038
[ 9436.262195][    C4] x17: 0000000000000240 x16: 0000000000000201
[ 9436.262199][    C4] x15: ffffffffffffffff x14: ffffff889f3c3100
[ 9436.262203][    C4] x13: ffffff889f3c3100 x12: 00000000049f56b8
[ 9436.262207][    C4] x11: 00000000049f56b8 x10: 00000000ffffffff
[ 9436.262212][    C4] x9 : ffffffc010023e50 x8 : dead000000000122
[ 9436.262216][    C4] x7 : ffffffffffffffff x6 : ffffffc0100239d8
[ 9436.262220][    C4] x5 : 0000000000000000 x4 : 0000000000000101
[ 9436.262223][    C4] x3 : 0000000000000080 x2 : ffffff8
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-52635</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

libceph: just wait for more data to be available on the socket

A short read may occur while reading the message footer from the
socket.  Later, when the socket is ready for another read, the
messenger invokes all read_partial_*() handlers, including
read_partial_sparse_msg_data().  The expectation is that
read_partial_sparse_msg_data() would bail, allowing the messenger to
invoke read_partial() for the footer and pick up where it left off.

However read_partial_sparse_msg_data() violates that and ends up
calling into the state machine in the OSD client.  The sparse-read
state machine assumes that it's a new op and interprets some piece of
the footer as the sparse-read header and returns bogus extents/data
length, etc.

To determine whether read_partial_sparse_msg_data() should bail, let's
reuse cursor-&gt;total_resid.  Because once it reaches to zero that means
all the extents and data have been successfully received in last read,
else it could break out when partially reading any of the extents and
data.  And then osd_sparse_read() could continue where it left off.

[ idryomov: changelog ]</Note>
    </Notes>
    <CVE>CVE-2023-52636</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pmdomain: mediatek: fix race conditions with genpd

If the power domains are registered first with genpd and *after that*
the driver attempts to power them on in the probe sequence, then it is
possible that a race condition occurs if genpd tries to power them on
in the same time.
The same is valid for powering them off before unregistering them
from genpd.
Attempt to fix race conditions by first removing the domains from genpd
and *after that* powering down domains.
Also first power up the domains and *after that* register them
to genpd.</Note>
    </Notes>
    <CVE>CVE-2023-52645</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

NTB: fix possible name leak in ntb_register_device()

If device_register() fails in ntb_register_device(), the device name
allocated by dev_set_name() should be freed. As per the comment in
device_register(), callers should use put_device() to give up the
reference in the error path. So fix this by calling put_device() in the
error path so that the name can be freed in kobject_cleanup().

As a result of this, put_device() in the error path of
ntb_register_device() is removed and the actual error is returned.

[mani: reworded commit message]</Note>
    </Notes>
    <CVE>CVE-2023-52652</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of service condition or potential code execution.</Note>
    </Notes>
    <CVE>CVE-2023-6270</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 due to a deadlock was found in sctp_auto_asconf_init in net/sctp/socket.c in the Linux kernel's SCTP subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.</Note>
    </Notes>
    <CVE>CVE-2024-0639</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A null pointer dereference flaw was found in the hugetlbfs_fill_super function in the Linux kernel hugetlbfs (HugeTLB pages) functionality. This issue may allow a local user to crash the system or potentially escalate their privileges on the system.</Note>
    </Notes>
    <CVE>CVE-2024-0841</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">NULL Pointer Dereference vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (net, bluetooth modules) allows Overflow Buffers. This vulnerability is associated with program files /net/bluetooth/rfcomm/core.C.

This issue affects Linux kernel: v2.6.12-rc2.</Note>
    </Notes>
    <CVE>CVE-2024-22099</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Integer Overflow or Wraparound vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (md, raid, raid5 modules) allows Forced Integer Overflow.</Note>
    </Notes>
    <CVE>CVE-2024-23307</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel through 6.7.1, there is a use-after-free in cec_queue_msg_fh, related to drivers/media/cec/core/cec-adap.c and drivers/media/cec/core/cec-api.c.</Note>
    </Notes>
    <CVE>CVE-2024-23848</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In btrfs_get_root_ref in fs/btrfs/disk-io.c in the Linux kernel through 6.7.1, there can be an assertion failure and crash because a subvolume can be read out too soon after its root item is inserted upon subvolume creation.</Note>
    </Notes>
    <CVE>CVE-2024-23850</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Issue summary: Some non-default TLS server configurations can cause unbounded
memory growth when processing TLSv1.3 sessions

Impact summary: An attacker may exploit certain server configurations to trigger
unbounded memory growth that would lead to a Denial of Service

This problem can occur in TLSv1.3 if the non-default SSL_OP_NO_TICKET option is
being used (but not if early_data support is also configured and the default
anti-replay protection is in use). In this case, under certain conditions, the
session cache can get into an incorrect state and it will fail to flush properly
as it fills. The session cache will continue to grow in an unbounded manner. A
malicious client could deliberately create the scenario for this failure to
force a Denial of Service. It may also happen by accident in normal operation.

This issue only affects TLS servers supporting TLSv1.3. It does not affect TLS
clients.

The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL
1.0.2 is also not affected by this issue.</Note>
    </Notes>
    <CVE>CVE-2024-2511</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:libopenssl1_1-1.1.1l-150500.17.28.2</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:openssl-1_1-1.1.1l-150500.17.28.2</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix a memory corruption

iwl_fw_ini_trigger_tlv::data is a pointer to a __le32, which means that
if we copy to iwl_fw_ini_trigger_tlv::data + offset while offset is in
bytes, we'll write past the buffer.</Note>
    </Notes>
    <CVE>CVE-2024-26610</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: fix use-after-free bug

The bug can be triggered by sending a single amdgpu_gem_userptr_ioctl
to the AMDGPU DRM driver on any ASICs with an invalid address and size.
The bug was reported by Joonkyo Jung &lt;joonkyoj@yonsei.ac.kr&gt;.
For example the following code:

static void Syzkaller1(int fd)
{
	struct drm_amdgpu_gem_userptr arg;
	int ret;

	arg.addr = 0xffffffffffff0000;
	arg.size = 0x80000000; /*2 Gb*/
	arg.flags = 0x7;
	ret = drmIoctl(fd, 0xc1186451/*amdgpu_gem_userptr_ioctl*/, &amp;arg);
}

Due to the address and size are not valid there is a failure in
amdgpu_hmm_register-&gt;mmu_interval_notifier_insert-&gt;__mmu_interval_notifier_insert-&gt;
check_shl_overflow, but we even the amdgpu_hmm_register failure we still call
amdgpu_hmm_unregister into  amdgpu_gem_object_free which causes access to a bad address.
The following stack is below when the issue is reproduced when Kazan is enabled:

[  +0.000014] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020
[  +0.000009] RIP: 0010:mmu_interval_notifier_remove+0x327/0x340
[  +0.000017] Code: ff ff 49 89 44 24 08 48 b8 00 01 00 00 00 00 ad de 4c 89 f7 49 89 47 40 48 83 c0 22 49 89 47 48 e8 ce d1 2d 01 e9 32 ff ff ff &lt;0f&gt; 0b e9 16 ff ff ff 4c 89 ef e8 fa 14 b3 ff e9 36 ff ff ff e8 80
[  +0.000014] RSP: 0018:ffffc90002657988 EFLAGS: 00010246
[  +0.000013] RAX: 0000000000000000 RBX: 1ffff920004caf35 RCX: ffffffff8160565b
[  +0.000011] RDX: dffffc0000000000 RSI: 0000000000000004 RDI: ffff8881a9f78260
[  +0.000010] RBP: ffffc90002657a70 R08: 0000000000000001 R09: fffff520004caf25
[  +0.000010] R10: 0000000000000003 R11: ffffffff8161d1d6 R12: ffff88810e988c00
[  +0.000010] R13: ffff888126fb5a00 R14: ffff88810e988c0c R15: ffff8881a9f78260
[  +0.000011] FS:  00007ff9ec848540(0000) GS:ffff8883cc880000(0000) knlGS:0000000000000000
[  +0.000012] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  +0.000010] CR2: 000055b3f7e14328 CR3: 00000001b5770000 CR4: 0000000000350ef0
[  +0.000010] Call Trace:
[  +0.000006]  &lt;TASK&gt;
[  +0.000007]  ? show_regs+0x6a/0x80
[  +0.000018]  ? __warn+0xa5/0x1b0
[  +0.000019]  ? mmu_interval_notifier_remove+0x327/0x340
[  +0.000018]  ? report_bug+0x24a/0x290
[  +0.000022]  ? handle_bug+0x46/0x90
[  +0.000015]  ? exc_invalid_op+0x19/0x50
[  +0.000016]  ? asm_exc_invalid_op+0x1b/0x20
[  +0.000017]  ? kasan_save_stack+0x26/0x50
[  +0.000017]  ? mmu_interval_notifier_remove+0x23b/0x340
[  +0.000019]  ? mmu_interval_notifier_remove+0x327/0x340
[  +0.000019]  ? mmu_interval_notifier_remove+0x23b/0x340
[  +0.000020]  ? __pfx_mmu_interval_notifier_remove+0x10/0x10
[  +0.000017]  ? kasan_save_alloc_info+0x1e/0x30
[  +0.000018]  ? srso_return_thunk+0x5/0x5f
[  +0.000014]  ? __kasan_kmalloc+0xb1/0xc0
[  +0.000018]  ? srso_return_thunk+0x5/0x5f
[  +0.000013]  ? __kasan_check_read+0x11/0x20
[  +0.000020]  amdgpu_hmm_unregister+0x34/0x50 [amdgpu]
[  +0.004695]  amdgpu_gem_object_free+0x66/0xa0 [amdgpu]
[  +0.004534]  ? __pfx_amdgpu_gem_object_free+0x10/0x10 [amdgpu]
[  +0.004291]  ? do_syscall_64+0x5f/0xe0
[  +0.000023]  ? srso_return_thunk+0x5/0x5f
[  +0.000017]  drm_gem_object_free+0x3b/0x50 [drm]
[  +0.000489]  amdgpu_gem_userptr_ioctl+0x306/0x500 [amdgpu]
[  +0.004295]  ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]
[  +0.004270]  ? srso_return_thunk+0x5/0x5f
[  +0.000014]  ? __this_cpu_preempt_check+0x13/0x20
[  +0.000015]  ? srso_return_thunk+0x5/0x5f
[  +0.000013]  ? sysvec_apic_timer_interrupt+0x57/0xc0
[  +0.000020]  ? srso_return_thunk+0x5/0x5f
[  +0.000014]  ? asm_sysvec_apic_timer_interrupt+0x1b/0x20
[  +0.000022]  ? drm_ioctl_kernel+0x17b/0x1f0 [drm]
[  +0.000496]  ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]
[  +0.004272]  ? drm_ioctl_kernel+0x190/0x1f0 [drm]
[  +0.000492]  drm_ioctl_kernel+0x140/0x1f0 [drm]
[  +0.000497]  ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]
[  +0.004297]  ? __pfx_drm_ioctl_kernel+0x10/0x10 [d
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-26656</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-mq: fix IO hang from sbitmap wakeup race

In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered
with the following blk_mq_get_driver_tag() in case of getting driver
tag failure.

Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe
the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime
blk_mq_mark_tag_wait() can't get driver tag successfully.

This issue can be reproduced by running the following test in loop, and
fio hang can be observed in &lt; 30min when running it on my test VM
in laptop.

	modprobe -r scsi_debug
	modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4
	dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename`
	fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \
       		--runtime=100 --numjobs=40 --time_based --name=test \
        	--ioengine=libaio

Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which
is just fine in case of running out of tag.</Note>
    </Notes>
    <CVE>CVE-2024-26671</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_ct: sanitize layer 3 and 4 protocol number in custom expectations

- Disallow families other than NFPROTO_{IPV4,IPV6,INET}.
- Disallow layer 4 protocol with no ports, since destination port is a
  mandatory attribute for this object.</Note>
    </Notes>
    <CVE>CVE-2024-26673</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ppp_async: limit MRU to 64K

syzbot triggered a warning [1] in __alloc_pages():

WARN_ON_ONCE_GFP(order &gt; MAX_PAGE_ORDER, gfp)

Willem fixed a similar issue in commit c0a2a1b0d631 ("ppp: limit MRU to 64K")

Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU)

[1]:

 WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543
Modules linked in:
CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
Workqueue: events_unbound flush_to_ldisc
pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543
 lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537
sp : ffff800093967580
x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000
x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0
x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8
x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120
x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005
x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000
x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001
x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003f
x5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020
x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0
Call trace:
  __alloc_pages+0x308/0x698 mm/page_alloc.c:4543
  __alloc_pages_node include/linux/gfp.h:238 [inline]
  alloc_pages_node include/linux/gfp.h:261 [inline]
  __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926
  __do_kmalloc_node mm/slub.c:3969 [inline]
  __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001
  kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590
  __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651
  __netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715
  netdev_alloc_skb include/linux/skbuff.h:3235 [inline]
  dev_alloc_skb include/linux/skbuff.h:3248 [inline]
  ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline]
  ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341
  tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390
  tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37
  receive_buf drivers/tty/tty_buffer.c:444 [inline]
  flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494
  process_one_work+0x694/0x1204 kernel/workqueue.c:2633
  process_scheduled_works kernel/workqueue.c:2706 [inline]
  worker_thread+0x938/0xef4 kernel/workqueue.c:2787
  kthread+0x288/0x310 kernel/kthread.c:388
  ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860</Note>
    </Notes>
    <CVE>CVE-2024-26675</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xen/events: close evtchn after mapping cleanup

shutdown_pirq and startup_pirq are not taking the
irq_mapping_update_lock because they can't due to lock inversion. Both
are called with the irq_desc-&gt;lock being taking. The lock order,
however, is first irq_mapping_update_lock and then irq_desc-&gt;lock.

This opens multiple races:
- shutdown_pirq can be interrupted by a function that allocates an event
  channel:

  CPU0                        CPU1
  shutdown_pirq {
    xen_evtchn_close(e)
                              __startup_pirq {
                                EVTCHNOP_bind_pirq
                                  -&gt; returns just freed evtchn e
                                set_evtchn_to_irq(e, irq)
                              }
    xen_irq_info_cleanup() {
      set_evtchn_to_irq(e, -1)
    }
  }

  Assume here event channel e refers here to the same event channel
  number.
  After this race the evtchn_to_irq mapping for e is invalid (-1).

- __startup_pirq races with __unbind_from_irq in a similar way. Because
  __startup_pirq doesn't take irq_mapping_update_lock it can grab the
  evtchn that __unbind_from_irq is currently freeing and cleaning up. In
  this case even though the event channel is allocated, its mapping can
  be unset in evtchn_to_irq.

The fix is to first cleanup the mappings and then close the event
channel. In this way, when an event channel gets allocated it's
potential previous evtchn_to_irq mappings are guaranteed to be unset already.
This is also the reverse order of the allocation where first the event
channel is allocated and then the mappings are setup.

On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal
[un]bind interfaces"), we hit a BUG like the following during probing of NVMe
devices. The issue is that during nvme_setup_io_queues, pci_free_irq
is called for every device which results in a call to shutdown_pirq.
With many nvme devices it's therefore likely to hit this race during
boot because there will be multiple calls to shutdown_pirq and
startup_pirq are running potentially in parallel.

  ------------[ cut here ]------------
  blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled
  kernel BUG at drivers/xen/events/events_base.c:499!
  invalid opcode: 0000 [#1] SMP PTI
  CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1
  Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006
  Workqueue: nvme-reset-wq nvme_reset_work
  RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0
  Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff &lt;0f&gt; 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00
  RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046
  RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006
  RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff
  RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00
  R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed
  R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002
  FS:  0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  Call Trace:
   ? show_trace_log_lvl+0x1c1/0x2d9
   ? show_trace_log_lvl+0x1c1/0x2d9
   ? set_affinity_irq+0xdc/0x1c0
   ? __die_body.cold+0x8/0xd
   ? die+0x2b/0x50
   ? do_trap+0x90/0x110
   ? bind_evtchn_to_cpu+0xdf/0xf0
   ? do_error_trap+0x65/0x80
   ? bind_evtchn_to_cpu+0xdf/0xf0
   ? exc_invalid_op+0x4e/0x70
   ? bind_evtchn_to_cpu+0xdf/0xf0
   ? asm_exc_invalid_op+0x12/0x20
   ? bind_evtchn_to_cpu+0xdf/0x
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-26687</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRC

Recently, we encounter kernel crash in function rm3100_common_probe
caused by out of bound access of array rm3100_samp_rates (because of
underlying hardware failures). Add boundary check to prevent out of
bound access.</Note>
    </Notes>
    <CVE>CVE-2024-26702</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

arp: Prevent overflow in arp_req_get().

syzkaller reported an overflown write in arp_req_get(). [0]

When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour
entry and copies neigh-&gt;ha to struct arpreq.arp_ha.sa_data.

The arp_ha here is struct sockaddr, not struct sockaddr_storage, so
the sa_data buffer is just 14 bytes.

In the splat below, 2 bytes are overflown to the next int field,
arp_flags.  We initialise the field just after the memcpy(), so it's
not a problem.

However, when dev-&gt;addr_len is greater than 22 (e.g. MAX_ADDR_LEN),
arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL)
in arp_ioctl() before calling arp_req_get().

To avoid the overflow, let's limit the max length of memcpy().

Note that commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible
array in struct sockaddr") just silenced syzkaller.

[0]:
memcpy: detected field-spanning write (size 16) of single field "r-&gt;arp_ha.sa_data" at net/ipv4/arp.c:1128 (size 14)
WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
Modules linked in:
CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014
RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb &lt;0f&gt; 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6
RSP: 0018:ffffc900050b7998 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001
RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000
R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010
FS:  00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261
 inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981
 sock_do_ioctl+0xdf/0x260 net/socket.c:1204
 sock_ioctl+0x3ef/0x650 net/socket.c:1321
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:870 [inline]
 __se_sys_ioctl fs/ioctl.c:856 [inline]
 __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81
 entry_SYSCALL_64_after_hwframe+0x64/0xce
RIP: 0033:0x7f172b262b8d
Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 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 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d
RDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003
RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-26733</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 allocating blocks from corrupted group in ext4_mb_find_by_goal()

Places the logic for checking if the group's block bitmap is corrupt under
the protection of the group lock to avoid allocating blocks from the group
with a corrupted block bitmap.</Note>
    </Notes>
    <CVE>CVE-2024-26772</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: fix race condition on enabling fast-xmit

fast-xmit must only be enabled after the sta has been uploaded to the driver,
otherwise it could end up passing the not-yet-uploaded sta via drv_tx calls
to the driver, leading to potential crashes because of uninitialized drv_priv
data.
Add a missing sta-&gt;uploaded check and re-check fast xmit after inserting a sta.</Note>
    </Notes>
    <CVE>CVE-2024-26779</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm/vmscan: fix a bug calling wakeup_kswapd() with a wrong zone index

With numa balancing on, when a numa system is running where a numa node
doesn't have its local memory so it has no managed zones, the following
oops has been observed.  It's because wakeup_kswapd() is called with a
wrong zone index, -1.  Fixed it by checking the index before calling
wakeup_kswapd().

&gt; BUG: unable to handle page fault for address: 00000000000033f3
&gt; #PF: supervisor read access in kernel mode
&gt; #PF: error_code(0x0000) - not-present page
&gt; PGD 0 P4D 0
&gt; Oops: 0000 [#1] PREEMPT SMP NOPTI
&gt; CPU: 2 PID: 895 Comm: masim Not tainted 6.6.0-dirty #255
&gt; Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
&gt;    rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
&gt; RIP: 0010:wakeup_kswapd (./linux/mm/vmscan.c:7812)
&gt; Code: (omitted)
&gt; RSP: 0000:ffffc90004257d58 EFLAGS: 00010286
&gt; RAX: ffffffffffffffff RBX: ffff88883fff0480 RCX: 0000000000000003
&gt; RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88883fff0480
&gt; RBP: ffffffffffffffff R08: ff0003ffffffffff R09: ffffffffffffffff
&gt; R10: ffff888106c95540 R11: 0000000055555554 R12: 0000000000000003
&gt; R13: 0000000000000000 R14: 0000000000000000 R15: ffff88883fff0940
&gt; FS:  00007fc4b8124740(0000) GS:ffff888827c00000(0000) knlGS:0000000000000000
&gt; CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
&gt; CR2: 00000000000033f3 CR3: 000000026cc08004 CR4: 0000000000770ee0
&gt; DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
&gt; DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
&gt; PKRU: 55555554
&gt; Call Trace:
&gt;  &lt;TASK&gt;
&gt; ? __die
&gt; ? page_fault_oops
&gt; ? __pte_offset_map_lock
&gt; ? exc_page_fault
&gt; ? asm_exc_page_fault
&gt; ? wakeup_kswapd
&gt; migrate_misplaced_page
&gt; __handle_mm_fault
&gt; handle_mm_fault
&gt; do_user_addr_fault
&gt; exc_page_fault
&gt; asm_exc_page_fault
&gt; RIP: 0033:0x55b897ba0808
&gt; Code: (omitted)
&gt; RSP: 002b:00007ffeefa821a0 EFLAGS: 00010287
&gt; RAX: 000055b89983acd0 RBX: 00007ffeefa823f8 RCX: 000055b89983acd0
&gt; RDX: 00007fc2f8122010 RSI: 0000000000020000 RDI: 000055b89983acd0
&gt; RBP: 00007ffeefa821a0 R08: 0000000000000037 R09: 0000000000000075
&gt; R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000
&gt; R13: 00007ffeefa82410 R14: 000055b897ba5dd8 R15: 00007fc4b8340000
&gt;  &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-26783</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: always restore the old font data in fbcon_do_set_font()

Commit a5a923038d70 (fbdev: fbcon: Properly revert changes when
vc_resize() failed) started restoring old font data upon failure (of
vc_resize()). But it performs so only for user fonts. It means that the
"system"/internal fonts are not restored at all. So in result, the very
first call to fbcon_do_set_font() performs no restore at all upon
failing vc_resize().

This can be reproduced by Syzkaller to crash the system on the next
invocation of font_get(). It's rather hard to hit the allocation failure
in vc_resize() on the first font_set(), but not impossible. Esp. if
fault injection is used to aid the execution/failure. It was
demonstrated by Sirius:
  BUG: unable to handle page fault for address: fffffffffffffff8
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0
  Oops: 0000 [#1] PREEMPT SMP KASAN
  CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  RIP: 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286
  Call Trace:
   &lt;TASK&gt;
   con_font_get drivers/tty/vt/vt.c:4558 [inline]
   con_font_op+0x1fc/0xf20 drivers/tty/vt/vt.c:4673
   vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline]
   vt_ioctl+0x632/0x2ec0 drivers/tty/vt/vt_ioctl.c:752
   tty_ioctl+0x6f8/0x1570 drivers/tty/tty_io.c:2803
   vfs_ioctl fs/ioctl.c:51 [inline]
  ...

So restore the font data in any case, not only for user fonts. Note the
later 'if' is now protected by 'old_userfont' and not 'old_data' as the
latter is always set now. (And it is supposed to be non-NULL. Otherwise
we would see the bug above again.)</Note>
    </Notes>
    <CVE>CVE-2024-26798</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

x86, relocs: Ignore relocations in .notes section

When building with CONFIG_XEN_PV=y, .text symbols are emitted into
the .notes section so that Xen can find the "startup_xen" entry point.
This information is used prior to booting the kernel, so relocations
are not useful. In fact, performing relocations against the .notes
section means that the KASLR base is exposed since /sys/kernel/notes
is world-readable.

To avoid leaking the KASLR base without breaking unprivileged tools that
are expecting to read /sys/kernel/notes, skip performing relocations in
the .notes section. The values readable in .notes are then identical to
those found in System.map.</Note>
    </Notes>
    <CVE>CVE-2024-26816</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

amdkfd: use calloc instead of kzalloc to avoid integer overflow

This uses calloc instead of doing the multiplication which might
overflow.</Note>
    </Notes>
    <CVE>CVE-2024-26817</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hv_netvsc: Register VF in netvsc_probe if NET_DEVICE_REGISTER missed

If hv_netvsc driver is unloaded and reloaded, the NET_DEVICE_REGISTER
handler cannot perform VF register successfully as the register call
is received before netvsc_probe is finished. This is because we
register register_netdevice_notifier() very early( even before
vmbus_driver_register()).
To fix this, we try to register each such matching VF( if it is visible
as a netdevice) at the end of netvsc_probe.</Note>
    </Notes>
    <CVE>CVE-2024-26820</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfc: nci: free rx_data_reassembly skb on NCI device cleanup

rx_data_reassembly skb is stored during NCI data exchange for processing
fragmented packets. It is dropped only when the last fragment is processed
or when an NTF packet with NCI_OP_RF_DEACTIVATE_NTF opcode is received.
However, the NCI device may be deallocated before that which leads to skb
leak.

As by design the rx_data_reassembly skb is bound to the NCI device and
nothing prevents the device to be freed before the skb is processed in
some way and cleaned, free it on the NCI device cleanup.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.</Note>
    </Notes>
    <CVE>CVE-2024-26825</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Do not allow untrusted VF to remove administratively set MAC

Currently when PF administratively sets VF's MAC address and the VF
is put down (VF tries to delete all MACs) then the MAC is removed
from MAC filters and primary VF MAC is zeroed.

Do not allow untrusted VF to remove primary MAC when it was set
administratively by PF.

Reproducer:
1) Create VF
2) Set VF interface up
3) Administratively set the VF's MAC
4) Put VF interface down

[root@host ~]# echo 1 &gt; /sys/class/net/enp2s0f0/device/sriov_numvfs
[root@host ~]# ip link set enp2s0f0v0 up
[root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d
[root@host ~]# ip link show enp2s0f0
23: enp2s0f0: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff
    vf 0     link/ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
[root@host ~]# ip link set enp2s0f0v0 down
[root@host ~]# ip link show enp2s0f0
23: enp2s0f0: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff
    vf 0     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off</Note>
    </Notes>
    <CVE>CVE-2024-26830</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix memory leak in dm_sw_fini()

After destroying dmub_srv, the memory associated with it is
not freed, causing a memory leak:

unreferenced object 0xffff896302b45800 (size 1024):
  comm "(udev-worker)", pid 222, jiffies 4294894636
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc 6265fd77):
    [&lt;ffffffff993495ed&gt;] kmalloc_trace+0x29d/0x340
    [&lt;ffffffffc0ea4a94&gt;] dm_dmub_sw_init+0xb4/0x450 [amdgpu]
    [&lt;ffffffffc0ea4e55&gt;] dm_sw_init+0x15/0x2b0 [amdgpu]
    [&lt;ffffffffc0ba8557&gt;] amdgpu_device_init+0x1417/0x24e0 [amdgpu]
    [&lt;ffffffffc0bab285&gt;] amdgpu_driver_load_kms+0x15/0x190 [amdgpu]
    [&lt;ffffffffc0ba09c7&gt;] amdgpu_pci_probe+0x187/0x4e0 [amdgpu]
    [&lt;ffffffff9968fd1e&gt;] local_pci_probe+0x3e/0x90
    [&lt;ffffffff996918a3&gt;] pci_device_probe+0xc3/0x230
    [&lt;ffffffff99805872&gt;] really_probe+0xe2/0x480
    [&lt;ffffffff99805c98&gt;] __driver_probe_device+0x78/0x160
    [&lt;ffffffff99805daf&gt;] driver_probe_device+0x1f/0x90
    [&lt;ffffffff9980601e&gt;] __driver_attach+0xce/0x1c0
    [&lt;ffffffff99803170&gt;] bus_for_each_dev+0x70/0xc0
    [&lt;ffffffff99804822&gt;] bus_add_driver+0x112/0x210
    [&lt;ffffffff99807245&gt;] driver_register+0x55/0x100
    [&lt;ffffffff990012d1&gt;] do_one_initcall+0x41/0x300

Fix this by freeing dmub_srv after destroying it.</Note>
    </Notes>
    <CVE>CVE-2024-26833</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

platform/x86: think-lmi: Fix password opcode ordering for workstations

The Lenovo workstations require the password opcode to be run before
the attribute value is changed (if Admin password is enabled).

Tested on some Thinkpads to confirm they are OK with this order too.</Note>
    </Notes>
    <CVE>CVE-2024-26836</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

efi: runtime: Fix potential overflow of soft-reserved region size

md_size will have been narrowed if we have &gt;= 4GB worth of pages in a
soft-reserved region.</Note>
    </Notes>
    <CVE>CVE-2024-26843</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/ipv6: avoid possible UAF in ip6_route_mpath_notify()

syzbot found another use-after-free in ip6_route_mpath_notify() [1]

Commit f7225172f25a ("net/ipv6: prevent use after free in
ip6_route_mpath_notify") was not able to fix the root cause.

We need to defer the fib6_info_release() calls after
ip6_route_mpath_notify(), in the cleanup phase.

[1]
BUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0
Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037

CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Call Trace:
 &lt;TASK&gt;
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106
  print_address_description mm/kasan/report.c:377 [inline]
  print_report+0x167/0x540 mm/kasan/report.c:488
  kasan_report+0x142/0x180 mm/kasan/report.c:601
 rt6_fill_node+0x1460/0x1ac0
  inet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184
  ip6_route_mpath_notify net/ipv6/route.c:5198 [inline]
  ip6_route_multipath_add net/ipv6/route.c:5404 [inline]
  inet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517
  rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597
  netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
  netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
  netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
  netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x221/0x270 net/socket.c:745
  ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
  ___sys_sendmsg net/socket.c:2638 [inline]
  __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
 do_syscall_64+0xf9/0x240
 entry_SYSCALL_64_after_hwframe+0x6f/0x77
RIP: 0033:0x7f73dd87dda9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 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:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9
RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005
RBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858
 &lt;/TASK&gt;

Allocated by task 23037:
  kasan_save_stack mm/kasan/common.c:47 [inline]
  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
  poison_kmalloc_redzone mm/kasan/common.c:372 [inline]
  __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389
  kasan_kmalloc include/linux/kasan.h:211 [inline]
  __do_kmalloc_node mm/slub.c:3981 [inline]
  __kmalloc+0x22e/0x490 mm/slub.c:3994
  kmalloc include/linux/slab.h:594 [inline]
  kzalloc include/linux/slab.h:711 [inline]
  fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155
  ip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758
  ip6_route_multipath_add net/ipv6/route.c:5298 [inline]
  inet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517
  rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597
  netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
  netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
  netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
  netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x221/0x270 net/socket.c:745
  ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
  ___sys_sendmsg net/socket.c:2638 [inline]
  __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
 do_syscall_64+0xf9/0x240
 entry_SYSCALL_64_after_hwframe+0x6f/0x77

Freed by task 16:
  kasan_save_stack mm/kasan/common.c:47 [inline]
  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
  kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640
  poison_slab_object+0xa6/0xe0 m
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-26852</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

igc: avoid returning frame twice in XDP_REDIRECT

When a frame can not be transmitted in XDP_REDIRECT
(e.g. due to a full queue), it is necessary to free
it by calling xdp_return_frame_rx_napi.

However, this is the responsibility of the caller of
the ndo_xdp_xmit (see for example bq_xmit_all in
kernel/bpf/devmap.c) and thus calling it inside
igc_xdp_xmit (which is the ndo_xdp_xmit of the igc
driver) as well will lead to memory corruption.

In fact, bq_xmit_all expects that it can return all
frames after the last successfully transmitted one.
Therefore, break for the first not transmitted frame,
but do not call xdp_return_frame_rx_napi in igc_xdp_xmit.
This is equally implemented in other Intel drivers
such as the igb.

There are two alternatives to this that were rejected:
1. Return num_frames as all the frames would have been
   transmitted and release them inside igc_xdp_xmit.
   While it might work technically, it is not what
   the return value is meant to represent (i.e. the
   number of SUCCESSFULLY transmitted packets).
2. Rework kernel/bpf/devmap.c and all drivers to
   support non-consecutively dropped packets.
   Besides being complex, it likely has a negative
   performance impact without a significant gain
   since it is anyway unlikely that the next frame
   can be transmitted if the previous one was dropped.

The memory corruption can be reproduced with
the following script which leads to a kernel panic
after a few seconds.  It basically generates more
traffic than a i225 NIC can transmit and pushes it
via XDP_REDIRECT from a virtual interface to the
physical interface where frames get dropped.

   #!/bin/bash
   INTERFACE=enp4s0
   INTERFACE_IDX=`cat /sys/class/net/$INTERFACE/ifindex`

   sudo ip link add dev veth1 type veth peer name veth2
   sudo ip link set up $INTERFACE
   sudo ip link set up veth1
   sudo ip link set up veth2

   cat &lt;&lt; EOF &gt; redirect.bpf.c

   SEC("prog")
   int redirect(struct xdp_md *ctx)
   {
       return bpf_redirect($INTERFACE_IDX, 0);
   }

   char _license[] SEC("license") = "GPL";
   EOF
   clang -O2 -g -Wall -target bpf -c redirect.bpf.c -o redirect.bpf.o
   sudo ip link set veth2 xdp obj redirect.bpf.o

   cat &lt;&lt; EOF &gt; pass.bpf.c

   SEC("prog")
   int pass(struct xdp_md *ctx)
   {
       return XDP_PASS;
   }

   char _license[] SEC("license") = "GPL";
   EOF
   clang -O2 -g -Wall -target bpf -c pass.bpf.c -o pass.bpf.o
   sudo ip link set $INTERFACE xdp obj pass.bpf.o

   cat &lt;&lt; EOF &gt; trafgen.cfg

   {
     /* Ethernet Header */
     0xe8, 0x6a, 0x64, 0x41, 0xbf, 0x46,
     0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
     const16(ETH_P_IP),

     /* IPv4 Header */
     0b01000101, 0,   # IPv4 version, IHL, TOS
     const16(1028),   # IPv4 total length (UDP length + 20 bytes (IP header))
     const16(2),      # IPv4 ident
     0b01000000, 0,   # IPv4 flags, fragmentation off
     64,              # IPv4 TTL
     17,              # Protocol UDP
     csumip(14, 33),  # IPv4 checksum

     /* UDP Header */
     10,  0, 1, 1,    # IP Src - adapt as needed
     10,  0, 1, 2,    # IP Dest - adapt as needed
     const16(6666),   # UDP Src Port
     const16(6666),   # UDP Dest Port
     const16(1008),   # UDP length (UDP header 8 bytes + payload length)
     csumudp(14, 34), # UDP checksum

     /* Payload */
     fill('W', 1000),
   }
   EOF

   sudo trafgen -i trafgen.cfg -b3000MB -o veth1 --cpp</Note>
    </Notes>
    <CVE>CVE-2024-26853</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ice: Fix potential NULL pointer dereference in ice_bridge_setlink()

The function ice_bridge_setlink() may encounter a NULL pointer dereference
if nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequently
in nla_for_each_nested(). To address this issue, add a check to ensure that
br_spec is not NULL before proceeding with the nested attribute iteration.</Note>
    </Notes>
    <CVE>CVE-2024-26855</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sparx5: Fix use after free inside sparx5_del_mact_entry

Based on the static analyzis of the code it looks like when an entry
from the MAC table was removed, the entry was still used after being
freed. More precise the vid of the mac_entry was used after calling
devm_kfree on the mac_entry.
The fix consists in first using the vid of the mac_entry to delete the
entry from the HW and after that to free it.</Note>
    </Notes>
    <CVE>CVE-2024-26856</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

geneve: make sure to pull inner header in geneve_rx()

syzbot triggered a bug in geneve_rx() [1]

Issue is similar to the one I fixed in commit 8d975c15c0cd
("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")

We have to save skb-&gt;network_header in a temporary variable
in order to be able to recompute the network_header pointer
after a pskb_inet_may_pull() call.

pskb_inet_may_pull() makes sure the needed headers are in skb-&gt;head.

[1]
BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]
 BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline]
 BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391
  IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]
  geneve_rx drivers/net/geneve.c:279 [inline]
  geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391
  udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108
  udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186
  udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346
  __udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422
  udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604
  ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205
  ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233
  NF_HOOK include/linux/netfilter.h:314 [inline]
  ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254
  dst_input include/net/dst.h:461 [inline]
  ip_rcv_finish net/ipv4/ip_input.c:449 [inline]
  NF_HOOK include/linux/netfilter.h:314 [inline]
  ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569
  __netif_receive_skb_one_core net/core/dev.c:5534 [inline]
  __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648
  process_backlog+0x480/0x8b0 net/core/dev.c:5976
  __napi_poll+0xe3/0x980 net/core/dev.c:6576
  napi_poll net/core/dev.c:6645 [inline]
  net_rx_action+0x8b8/0x1870 net/core/dev.c:6778
  __do_softirq+0x1b7/0x7c5 kernel/softirq.c:553
  do_softirq+0x9a/0xf0 kernel/softirq.c:454
  __local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381
  local_bh_enable include/linux/bottom_half.h:33 [inline]
  rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline]
  __dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378
  dev_queue_xmit include/linux/netdevice.h:3171 [inline]
  packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276
  packet_snd net/packet/af_packet.c:3081 [inline]
  packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg net/socket.c:745 [inline]
  __sys_sendto+0x735/0xa10 net/socket.c:2191
  __do_sys_sendto net/socket.c:2203 [inline]
  __se_sys_sendto net/socket.c:2199 [inline]
  __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b

Uninit was created at:
  slab_post_alloc_hook mm/slub.c:3819 [inline]
  slab_alloc_node mm/slub.c:3860 [inline]
  kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903
  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
  __alloc_skb+0x352/0x790 net/core/skbuff.c:651
  alloc_skb include/linux/skbuff.h:1296 [inline]
  alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394
  sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783
  packet_alloc_skb net/packet/af_packet.c:2930 [inline]
  packet_snd net/packet/af_packet.c:3024 [inline]
  packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg net/socket.c:745 [inline]
  __sys_sendto+0x735/0xa10 net/socket.c:2191
  __do_sys_sendto net/socket.c:2203 [inline]
  __se_sys_sendto net/socket.c:2199 [inline]
  __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b</Note>
    </Notes>
    <CVE>CVE-2024-26857</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wireguard: receive: annotate data-race around receiving_counter.counter

Syzkaller with KCSAN identified a data-race issue when accessing
keypair-&gt;receiving_counter.counter. Use READ_ONCE() and WRITE_ONCE()
annotations to mark the data race as intentional.

    BUG: KCSAN: data-race in wg_packet_decrypt_worker / wg_packet_rx_poll

    write to 0xffff888107765888 of 8 bytes by interrupt on cpu 0:
     counter_validate drivers/net/wireguard/receive.c:321 [inline]
     wg_packet_rx_poll+0x3ac/0xf00 drivers/net/wireguard/receive.c:461
     __napi_poll+0x60/0x3b0 net/core/dev.c:6536
     napi_poll net/core/dev.c:6605 [inline]
     net_rx_action+0x32b/0x750 net/core/dev.c:6738
     __do_softirq+0xc4/0x279 kernel/softirq.c:553
     do_softirq+0x5e/0x90 kernel/softirq.c:454
     __local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381
     __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]
     _raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210
     spin_unlock_bh include/linux/spinlock.h:396 [inline]
     ptr_ring_consume_bh include/linux/ptr_ring.h:367 [inline]
     wg_packet_decrypt_worker+0x6c5/0x700 drivers/net/wireguard/receive.c:499
     process_one_work kernel/workqueue.c:2633 [inline]
     ...

    read to 0xffff888107765888 of 8 bytes by task 3196 on cpu 1:
     decrypt_packet drivers/net/wireguard/receive.c:252 [inline]
     wg_packet_decrypt_worker+0x220/0x700 drivers/net/wireguard/receive.c:501
     process_one_work kernel/workqueue.c:2633 [inline]
     process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2706
     worker_thread+0x525/0x730 kernel/workqueue.c:2787
     ...</Note>
    </Notes>
    <CVE>CVE-2024-26861</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

packet: annotate data-races around ignore_outgoing

ignore_outgoing is read locklessly from dev_queue_xmit_nit()
and packet_getsockopt()

Add appropriate READ_ONCE()/WRITE_ONCE() annotations.

syzbot reported:

BUG: KCSAN: data-race in dev_queue_xmit_nit / packet_setsockopt

write to 0xffff888107804542 of 1 bytes by task 22618 on cpu 0:
 packet_setsockopt+0xd83/0xfd0 net/packet/af_packet.c:4003
 do_sock_setsockopt net/socket.c:2311 [inline]
 __sys_setsockopt+0x1d8/0x250 net/socket.c:2334
 __do_sys_setsockopt net/socket.c:2343 [inline]
 __se_sys_setsockopt net/socket.c:2340 [inline]
 __x64_sys_setsockopt+0x66/0x80 net/socket.c:2340
 do_syscall_64+0xd3/0x1d0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75

read to 0xffff888107804542 of 1 bytes by task 27 on cpu 1:
 dev_queue_xmit_nit+0x82/0x620 net/core/dev.c:2248
 xmit_one net/core/dev.c:3527 [inline]
 dev_hard_start_xmit+0xcc/0x3f0 net/core/dev.c:3547
 __dev_queue_xmit+0xf24/0x1dd0 net/core/dev.c:4335
 dev_queue_xmit include/linux/netdevice.h:3091 [inline]
 batadv_send_skb_packet+0x264/0x300 net/batman-adv/send.c:108
 batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127
 batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:392 [inline]
 batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:420 [inline]
 batadv_iv_send_outstanding_bat_ogm_packet+0x3f0/0x4b0 net/batman-adv/bat_iv_ogm.c:1700
 process_one_work kernel/workqueue.c:3254 [inline]
 process_scheduled_works+0x465/0x990 kernel/workqueue.c:3335
 worker_thread+0x526/0x730 kernel/workqueue.c:3416
 kthread+0x1d1/0x210 kernel/kthread.c:388
 ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243

value changed: 0x00 -&gt; 0x01

Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 27 Comm: kworker/u8:1 Tainted: G        W          6.8.0-syzkaller-08073-g480e035fc4c7 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet</Note>
    </Notes>
    <CVE>CVE-2024-26862</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: lpspi: Avoid potential use-after-free in probe()

fsl_lpspi_probe() is allocating/disposing memory manually with
spi_alloc_host()/spi_alloc_target(), but uses
devm_spi_register_controller(). In case of error after the latter call the
memory will be explicitly freed in the probe function by
spi_controller_put() call, but used afterwards by "devm" management outside
probe() (spi_unregister_controller() &lt;- devm_spi_unregister() below).

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070
...
Call trace:
 kernfs_find_ns
 kernfs_find_and_get_ns
 sysfs_remove_group
 sysfs_remove_groups
 device_remove_attrs
 device_del
 spi_unregister_controller
 devm_spi_unregister
 release_nodes
 devres_release_all
 really_probe
 driver_probe_device
 __device_attach_driver
 bus_for_each_drv
 __device_attach
 device_initial_probe
 bus_probe_device
 deferred_probe_work_func
 process_one_work
 worker_thread
 kthread
 ret_from_fork</Note>
    </Notes>
    <CVE>CVE-2024-26866</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/srpt: Do not register event handler until srpt device is fully setup

Upon rare occasions, KASAN reports a use-after-free Write
in srpt_refresh_port().

This seems to be because an event handler is registered before the
srpt device is fully setup and a race condition upon error may leave a
partially setup event handler in place.

Instead, only register the event handler after srpt device initialization
is complete.</Note>
    </Notes>
    <CVE>CVE-2024-26872</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: pvrusb2: fix uaf in pvr2_context_set_notify

[Syzbot reported]
BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26

CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Workqueue: usb_hub_wq hub_event
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0xc4/0x620 mm/kasan/report.c:488
 kasan_report+0xda/0x110 mm/kasan/report.c:601
 pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
 pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline]
 pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272

Freed by task 906:
kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640
poison_slab_object mm/kasan/common.c:241 [inline]
__kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257
kasan_slab_free include/linux/kasan.h:184 [inline]
slab_free_hook mm/slub.c:2121 [inline]
slab_free mm/slub.c:4299 [inline]
kfree+0x105/0x340 mm/slub.c:4409
pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline]
pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158

[Analyze]
Task A set disconnect_flag = !0, which resulted in Task B's condition being met
and releasing mp, leading to this issue.

[Fix]
Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect()
to avoid this issue.</Note>
    </Notes>
    <CVE>CVE-2024-26875</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

quota: Fix potential NULL pointer dereference

Below race may cause NULL pointer dereference

P1					P2
dquot_free_inode			quota_off
					  drop_dquot_ref
					   remove_dquot_ref
					   dquots = i_dquot(inode)
  dquots = i_dquot(inode)
  srcu_read_lock
  dquots[cnt]) != NULL (1)
					     dquots[type] = NULL (2)
  spin_lock(&amp;dquots[cnt]-&gt;dq_dqb_lock) (3)
   ....

If dquot_free_inode(or other routines) checks inode's quota pointers (1)
before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer
dereference will be triggered.

So let's fix it by using a temporary pointer to avoid this issue.</Note>
    </Notes>
    <CVE>CVE-2024-26878</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: meson: Add missing clocks to axg_clk_regmaps

Some clocks were missing from axg_clk_regmaps, which caused kernel panic
during cat /sys/kernel/debug/clk/clk_summary

[   57.349402] Unable to handle kernel NULL pointer dereference at virtual address 00000000000001fc
...
[   57.430002] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   57.436900] pc : regmap_read+0x1c/0x88
[   57.440608] lr : clk_regmap_gate_is_enabled+0x3c/0xb0
[   57.445611] sp : ffff800082f1b690
[   57.448888] x29: ffff800082f1b690 x28: 0000000000000000 x27: ffff800080eb9a70
[   57.455961] x26: 0000000000000007 x25: 0000000000000016 x24: 0000000000000000
[   57.463033] x23: ffff800080e8b488 x22: 0000000000000015 x21: ffff00000e7e7000
[   57.470106] x20: ffff00000400ec00 x19: 0000000000000000 x18: ffffffffffffffff
[   57.477178] x17: 0000000000000000 x16: 0000000000000000 x15: ffff0000042a3000
[   57.484251] x14: 0000000000000000 x13: ffff0000042a2fec x12: 0000000005f5e100
[   57.491323] x11: abcc77118461cefd x10: 0000000000000020 x9 : ffff8000805e4b24
[   57.498396] x8 : ffff0000028063c0 x7 : ffff800082f1b710 x6 : ffff800082f1b710
[   57.505468] x5 : 00000000ffffffd0 x4 : ffff800082f1b6e0 x3 : 0000000000001000
[   57.512541] x2 : ffff800082f1b6e4 x1 : 000000000000012c x0 : 0000000000000000
[   57.519615] Call trace:
[   57.522030]  regmap_read+0x1c/0x88
[   57.525393]  clk_regmap_gate_is_enabled+0x3c/0xb0
[   57.530050]  clk_core_is_enabled+0x44/0x120
[   57.534190]  clk_summary_show_subtree+0x154/0x2f0
[   57.538847]  clk_summary_show_subtree+0x220/0x2f0
[   57.543505]  clk_summary_show_subtree+0x220/0x2f0
[   57.548162]  clk_summary_show_subtree+0x220/0x2f0
[   57.552820]  clk_summary_show_subtree+0x220/0x2f0
[   57.557477]  clk_summary_show_subtree+0x220/0x2f0
[   57.562135]  clk_summary_show_subtree+0x220/0x2f0
[   57.566792]  clk_summary_show_subtree+0x220/0x2f0
[   57.571450]  clk_summary_show+0x84/0xb8
[   57.575245]  seq_read_iter+0x1bc/0x4b8
[   57.578954]  seq_read+0x8c/0xd0
[   57.582059]  full_proxy_read+0x68/0xc8
[   57.585767]  vfs_read+0xb0/0x268
[   57.588959]  ksys_read+0x70/0x108
[   57.592236]  __arm64_sys_read+0x24/0x38
[   57.596031]  invoke_syscall+0x50/0x128
[   57.599740]  el0_svc_common.constprop.0+0x48/0xf8
[   57.604397]  do_el0_svc+0x28/0x40
[   57.607675]  el0_svc+0x34/0xb8
[   57.610694]  el0t_64_sync_handler+0x13c/0x158
[   57.615006]  el0t_64_sync+0x190/0x198
[   57.618635] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (b941fc00)
[   57.624668] ---[ end trace 0000000000000000 ]---

[jbrunet: add missing Fixes tag]</Note>
    </Notes>
    <CVE>CVE-2024-26879</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: hns3: fix kernel crash when 1588 is received on HIP08 devices

The HIP08 devices does not register the ptp devices, so the
hdev-&gt;ptp is NULL, but the hardware can receive 1588 messages,
and set the HNS3_RXD_TS_VLD_B bit, so, if match this case, the
access of hdev-&gt;ptp-&gt;flags will cause a kernel crash:

[ 5888.946472] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018
[ 5888.946475] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018
...
[ 5889.266118] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge]
[ 5889.272612] lr : hclge_ptp_get_rx_hwts+0x34/0x170 [hclge]
[ 5889.279101] sp : ffff800012c3bc50
[ 5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040
[ 5889.289927] x27: ffff800009116484 x26: 0000000080007500
[ 5889.296333] x25: 0000000000000000 x24: ffff204001c6f000
[ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000
[ 5889.309134] x21: 0000000000000000 x20: ffff204004220080
[ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000
[ 5889.321897] x17: 0000000000000000 x16: 0000000000000000
[ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000
[ 5889.334617] x13: 0000000000000000 x12: 00000000010011df
[ 5889.340965] x11: bbfeff4d22000000 x10: 0000000000000000
[ 5889.347303] x9 : ffff800009402124 x8 : 0200f78811dfbb4d
[ 5889.353637] x7 : 2200000000191b01 x6 : ffff208002a7d480
[ 5889.359959] x5 : 0000000000000000 x4 : 0000000000000000
[ 5889.366271] x3 : 0000000000000000 x2 : 0000000000000000
[ 5889.372567] x1 : 0000000000000000 x0 : ffff20400095c080
[ 5889.378857] Call trace:
[ 5889.382285] hclge_ptp_get_rx_hwts+0x40/0x170 [hclge]
[ 5889.388304] hns3_handle_bdinfo+0x324/0x410 [hns3]
[ 5889.394055] hns3_handle_rx_bd+0x60/0x150 [hns3]
[ 5889.399624] hns3_clean_rx_ring+0x84/0x170 [hns3]
[ 5889.405270] hns3_nic_common_poll+0xa8/0x220 [hns3]
[ 5889.411084] napi_poll+0xcc/0x264
[ 5889.415329] net_rx_action+0xd4/0x21c
[ 5889.419911] __do_softirq+0x130/0x358
[ 5889.424484] irq_exit+0x134/0x154
[ 5889.428700] __handle_domain_irq+0x88/0xf0
[ 5889.433684] gic_handle_irq+0x78/0x2c0
[ 5889.438319] el1_irq+0xb8/0x140
[ 5889.442354] arch_cpu_idle+0x18/0x40
[ 5889.446816] default_idle_call+0x5c/0x1c0
[ 5889.451714] cpuidle_idle_call+0x174/0x1b0
[ 5889.456692] do_idle+0xc8/0x160
[ 5889.460717] cpu_startup_entry+0x30/0xfc
[ 5889.465523] secondary_start_kernel+0x158/0x1ec
[ 5889.470936] Code: 97ffab78 f9411c14 91408294 f9457284 (f9400c80)
[ 5889.477950] SMP: stopping secondary CPUs
[ 5890.514626] SMP: failed to stop secondary CPUs 0-69,71-95
[ 5890.522951] Starting crashdump kernel...</Note>
    </Notes>
    <CVE>CVE-2024-26881</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv()

Apply the same fix than ones found in :

8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")
1ca1ba465e55 ("geneve: make sure to pull inner header in geneve_rx()")

We have to save skb-&gt;network_header in a temporary variable
in order to be able to recompute the network_header pointer
after a pskb_inet_may_pull() call.

pskb_inet_may_pull() makes sure the needed headers are in skb-&gt;head.

syzbot reported:
BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
 BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
 BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]
 BUG: KMSAN: uninit-value in ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409
  __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
  INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
  IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]
  ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409
  __ipgre_rcv+0x9bc/0xbc0 net/ipv4/ip_gre.c:389
  ipgre_rcv net/ipv4/ip_gre.c:411 [inline]
  gre_rcv+0x423/0x19f0 net/ipv4/ip_gre.c:447
  gre_rcv+0x2a4/0x390 net/ipv4/gre_demux.c:163
  ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205
  ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233
  NF_HOOK include/linux/netfilter.h:314 [inline]
  ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254
  dst_input include/net/dst.h:461 [inline]
  ip_rcv_finish net/ipv4/ip_input.c:449 [inline]
  NF_HOOK include/linux/netfilter.h:314 [inline]
  ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569
  __netif_receive_skb_one_core net/core/dev.c:5534 [inline]
  __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648
  netif_receive_skb_internal net/core/dev.c:5734 [inline]
  netif_receive_skb+0x58/0x660 net/core/dev.c:5793
  tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1556
  tun_get_user+0x53b9/0x66e0 drivers/net/tun.c:2009
  tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055
  call_write_iter include/linux/fs.h:2087 [inline]
  new_sync_write fs/read_write.c:497 [inline]
  vfs_write+0xb6b/0x1520 fs/read_write.c:590
  ksys_write+0x20f/0x4c0 fs/read_write.c:643
  __do_sys_write fs/read_write.c:655 [inline]
  __se_sys_write fs/read_write.c:652 [inline]
  __x64_sys_write+0x93/0xd0 fs/read_write.c:652
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b

Uninit was created at:
  __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590
  alloc_pages_mpol+0x62b/0x9d0 mm/mempolicy.c:2133
  alloc_pages+0x1be/0x1e0 mm/mempolicy.c:2204
  skb_page_frag_refill+0x2bf/0x7c0 net/core/sock.c:2909
  tun_build_skb drivers/net/tun.c:1686 [inline]
  tun_get_user+0xe0a/0x66e0 drivers/net/tun.c:1826
  tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055
  call_write_iter include/linux/fs.h:2087 [inline]
  new_sync_write fs/read_write.c:497 [inline]
  vfs_write+0xb6b/0x1520 fs/read_write.c:590
  ksys_write+0x20f/0x4c0 fs/read_write.c:643
  __do_sys_write fs/read_write.c:655 [inline]
  __se_sys_write fs/read_write.c:652 [inline]
  __x64_sys_write+0x93/0xd0 fs/read_write.c:652
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b</Note>
    </Notes>
    <CVE>CVE-2024-26882</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 stackmap overflow check on 32-bit arches

The stackmap code relies on roundup_pow_of_two() to compute the number
of hash buckets, and contains an overflow check by checking if the
resulting value is 0. However, on 32-bit arches, the roundup code itself
can overflow by doing a 32-bit left-shift of an unsigned long value,
which is undefined behaviour, so it is not guaranteed to truncate
neatly. This was triggered by syzbot on the DEVMAP_HASH type, which
contains the same check, copied from the hashtab code.

The commit in the fixes tag actually attempted to fix this, but the fix
did not account for the UB, so the fix only works on CPUs where an
overflow does result in a neat truncation to zero, which is not
guaranteed. Checking the value before rounding does not have this
problem.</Note>
    </Notes>
    <CVE>CVE-2024-26883</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 hashtab overflow check on 32-bit arches

The hashtab code relies on roundup_pow_of_two() to compute the number of
hash buckets, and contains an overflow check by checking if the
resulting value is 0. However, on 32-bit arches, the roundup code itself
can overflow by doing a 32-bit left-shift of an unsigned long value,
which is undefined behaviour, so it is not guaranteed to truncate
neatly. This was triggered by syzbot on the DEVMAP_HASH type, which
contains the same check, copied from the hashtab code. So apply the same
fix to hashtab, by moving the overflow check to before the roundup.</Note>
    </Notes>
    <CVE>CVE-2024-26884</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 DEVMAP_HASH overflow check on 32-bit arches

The devmap code allocates a number hash buckets equal to the next power
of two of the max_entries value provided when creating the map. When
rounding up to the next power of two, the 32-bit variable storing the
number of buckets can overflow, and the code checks for overflow by
checking if the truncated 32-bit value is equal to 0. However, on 32-bit
arches the rounding up itself can overflow mid-way through, because it
ends up doing a left-shift of 32 bits on an unsigned long value. If the
size of an unsigned long is four bytes, this is undefined behaviour, so
there is no guarantee that we'll end up with a nice and tidy 0-value at
the end.

Syzbot managed to turn this into a crash on arm32 by creating a
DEVMAP_HASH with max_entries &gt; 0x80000000 and then trying to update it.
Fix this by moving the overflow check to before the rounding up
operation.</Note>
    </Notes>
    <CVE>CVE-2024-26885</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Don't issue ATS Invalidation request when device is disconnected

For those endpoint devices connect to system via hotplug capable ports,
users could request a hot reset to the device by flapping device's link
through setting the slot's link control register, as pciehp_ist() DLLSC
interrupt sequence response, pciehp will unload the device driver and
then power it off. thus cause an IOMMU device-TLB invalidation (Intel
VT-d spec, or ATS Invalidation in PCIe spec r6.1) request for non-existence
target device to be sent and deadly loop to retry that request after ITE
fault triggered in interrupt context.

That would cause following continuous hard lockup warning and system hang

[ 4211.433662] pcieport 0000:17:01.0: pciehp: Slot(108): Link Down
[ 4211.433664] pcieport 0000:17:01.0: pciehp: Slot(108): Card not present
[ 4223.822591] NMI watchdog: Watchdog detected hard LOCKUP on cpu 144
[ 4223.822622] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S
         OE    kernel version xxxx
[ 4223.822623] Hardware name: vendorname xxxx 666-106,
BIOS 01.01.02.03.01 05/15/2023
[ 4223.822623] RIP: 0010:qi_submit_sync+0x2c0/0x490
[ 4223.822624] Code: 48 be 00 00 00 00 00 08 00 00 49 85 74 24 20 0f 95 c1 48 8b
 57 10 83 c1 04 83 3c 1a 03 0f 84 a2 01 00 00 49 8b 04 24 8b 70 34 &lt;40&gt; f6 c6 1
0 74 17 49 8b 04 24 8b 80 80 00 00 00 89 c2 d3 fa 41 39
[ 4223.822624] RSP: 0018:ffffc4f074f0bbb8 EFLAGS: 00000093
[ 4223.822625] RAX: ffffc4f040059000 RBX: 0000000000000014 RCX: 0000000000000005
[ 4223.822625] RDX: ffff9f3841315800 RSI: 0000000000000000 RDI: ffff9f38401a8340
[ 4223.822625] RBP: ffff9f38401a8340 R08: ffffc4f074f0bc00 R09: 0000000000000000
[ 4223.822626] R10: 0000000000000010 R11: 0000000000000018 R12: ffff9f384005e200
[ 4223.822626] R13: 0000000000000004 R14: 0000000000000046 R15: 0000000000000004
[ 4223.822626] FS:  0000000000000000(0000) GS:ffffa237ae400000(0000)
knlGS:0000000000000000
[ 4223.822627] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4223.822627] CR2: 00007ffe86515d80 CR3: 000002fd3000a001 CR4: 0000000000770ee0
[ 4223.822627] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 4223.822628] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
[ 4223.822628] PKRU: 55555554
[ 4223.822628] Call Trace:
[ 4223.822628]  qi_flush_dev_iotlb+0xb1/0xd0
[ 4223.822628]  __dmar_remove_one_dev_info+0x224/0x250
[ 4223.822629]  dmar_remove_one_dev_info+0x3e/0x50
[ 4223.822629]  intel_iommu_release_device+0x1f/0x30
[ 4223.822629]  iommu_release_device+0x33/0x60
[ 4223.822629]  iommu_bus_notifier+0x7f/0x90
[ 4223.822630]  blocking_notifier_call_chain+0x60/0x90
[ 4223.822630]  device_del+0x2e5/0x420
[ 4223.822630]  pci_remove_bus_device+0x70/0x110
[ 4223.822630]  pciehp_unconfigure_device+0x7c/0x130
[ 4223.822631]  pciehp_disable_slot+0x6b/0x100
[ 4223.822631]  pciehp_handle_presence_or_link_change+0xd8/0x320
[ 4223.822631]  pciehp_ist+0x176/0x180
[ 4223.822631]  ? irq_finalize_oneshot.part.50+0x110/0x110
[ 4223.822632]  irq_thread_fn+0x19/0x50
[ 4223.822632]  irq_thread+0x104/0x190
[ 4223.822632]  ? irq_forced_thread_fn+0x90/0x90
[ 4223.822632]  ? irq_thread_check_affinity+0xe0/0xe0
[ 4223.822633]  kthread+0x114/0x130
[ 4223.822633]  ? __kthread_cancel_work+0x40/0x40
[ 4223.822633]  ret_from_fork+0x1f/0x30
[ 4223.822633] Kernel panic - not syncing: Hard LOCKUP
[ 4223.822634] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S
         OE     kernel version xxxx
[ 4223.822634] Hardware name: vendorname xxxx 666-106,
BIOS 01.01.02.03.01 05/15/2023
[ 4223.822634] Call Trace:
[ 4223.822634]  &lt;NMI&gt;
[ 4223.822635]  dump_stack+0x6d/0x88
[ 4223.822635]  panic+0x101/0x2d0
[ 4223.822635]  ? ret_from_fork+0x11/0x30
[ 4223.822635]  nmi_panic.cold.14+0xc/0xc
[ 4223.822636]  watchdog_overflow_callback.cold.8+0x6d/0x81
[ 4223.822636]  __perf_event_overflow+0x4f/0xf0
[ 4223.822636]  handle_pmi_common
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-26891</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

firmware: arm_scmi: Fix double free in SMC transport cleanup path

When the generic SCMI code tears down a channel, it calls the chan_free
callback function, defined by each transport. Since multiple protocols
might share the same transport_info member, chan_free() might want to
clean up the same member multiple times within the given SCMI transport
implementation. In this case, it is SMC transport. This will lead to a NULL
pointer dereference at the second time:

    | scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16
    | arm-scmi firmware:scmi: SCMI Notifications - Core Enabled.
    | arm-scmi firmware:scmi: unable to communicate with SCMI
    | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
    | Mem abort info:
    |   ESR = 0x0000000096000004
    |   EC = 0x25: DABT (current EL), IL = 32 bits
    |   SET = 0, FnV = 0
    |   EA = 0, S1PTW = 0
    |   FSC = 0x04: level 0 translation fault
    | Data abort info:
    |   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
    |   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
    |   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
    | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881ef8000
    | [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
    | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
    | Modules linked in:
    | CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g455ef3d016c9-dirty #793
    | Hardware name: FVP Base RevC (DT)
    | pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
    | pc : smc_chan_free+0x3c/0x6c
    | lr : smc_chan_free+0x3c/0x6c
    | Call trace:
    |  smc_chan_free+0x3c/0x6c
    |  idr_for_each+0x68/0xf8
    |  scmi_cleanup_channels.isra.0+0x2c/0x58
    |  scmi_probe+0x434/0x734
    |  platform_probe+0x68/0xd8
    |  really_probe+0x110/0x27c
    |  __driver_probe_device+0x78/0x12c
    |  driver_probe_device+0x3c/0x118
    |  __driver_attach+0x74/0x128
    |  bus_for_each_dev+0x78/0xe0
    |  driver_attach+0x24/0x30
    |  bus_add_driver+0xe4/0x1e8
    |  driver_register+0x60/0x128
    |  __platform_driver_register+0x28/0x34
    |  scmi_driver_init+0x84/0xc0
    |  do_one_initcall+0x78/0x33c
    |  kernel_init_freeable+0x2b8/0x51c
    |  kernel_init+0x24/0x130
    |  ret_from_fork+0x10/0x20
    | Code: f0004701 910a0021 aa1403e5 97b91c70 (b9400280)
    | ---[ end trace 0000000000000000 ]---

Simply check for the struct pointer being NULL before trying to access
its members, to avoid this situation.

This was found when a transport doesn't really work (for instance no SMC
service), the probe routines then tries to clean up, and triggers a crash.</Note>
    </Notes>
    <CVE>CVE-2024-26893</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: prevent use-after-free on vif when cleaning up all interfaces

wilc_netdev_cleanup currently triggers a KASAN warning, which can be
observed on interface registration error path, or simply by
removing the module/unbinding device from driver:

echo spi0.1 &gt; /sys/bus/spi/drivers/wilc1000_spi/unbind

==================================================================
BUG: KASAN: slab-use-after-free in wilc_netdev_cleanup+0x508/0x5cc
Read of size 4 at addr c54d1ce8 by task sh/86

CPU: 0 PID: 86 Comm: sh Not tainted 6.8.0-rc1+ #117
Hardware name: Atmel SAMA5
 unwind_backtrace from show_stack+0x18/0x1c
 show_stack from dump_stack_lvl+0x34/0x58
 dump_stack_lvl from print_report+0x154/0x500
 print_report from kasan_report+0xac/0xd8
 kasan_report from wilc_netdev_cleanup+0x508/0x5cc
 wilc_netdev_cleanup from wilc_bus_remove+0xc8/0xec
 wilc_bus_remove from spi_remove+0x8c/0xac
 spi_remove from device_release_driver_internal+0x434/0x5f8
 device_release_driver_internal from unbind_store+0xbc/0x108
 unbind_store from kernfs_fop_write_iter+0x398/0x584
 kernfs_fop_write_iter from vfs_write+0x728/0xf88
 vfs_write from ksys_write+0x110/0x1e4
 ksys_write from ret_fast_syscall+0x0/0x1c

[...]

Allocated by task 1:
 kasan_save_track+0x30/0x5c
 __kasan_kmalloc+0x8c/0x94
 __kmalloc_node+0x1cc/0x3e4
 kvmalloc_node+0x48/0x180
 alloc_netdev_mqs+0x68/0x11dc
 alloc_etherdev_mqs+0x28/0x34
 wilc_netdev_ifc_init+0x34/0x8ec
 wilc_cfg80211_init+0x690/0x910
 wilc_bus_probe+0xe0/0x4a0
 spi_probe+0x158/0x1b0
 really_probe+0x270/0xdf4
 __driver_probe_device+0x1dc/0x580
 driver_probe_device+0x60/0x140
 __driver_attach+0x228/0x5d4
 bus_for_each_dev+0x13c/0x1a8
 bus_add_driver+0x2a0/0x608
 driver_register+0x24c/0x578
 do_one_initcall+0x180/0x310
 kernel_init_freeable+0x424/0x484
 kernel_init+0x20/0x148
 ret_from_fork+0x14/0x28

Freed by task 86:
 kasan_save_track+0x30/0x5c
 kasan_save_free_info+0x38/0x58
 __kasan_slab_free+0xe4/0x140
 kfree+0xb0/0x238
 device_release+0xc0/0x2a8
 kobject_put+0x1d4/0x46c
 netdev_run_todo+0x8fc/0x11d0
 wilc_netdev_cleanup+0x1e4/0x5cc
 wilc_bus_remove+0xc8/0xec
 spi_remove+0x8c/0xac
 device_release_driver_internal+0x434/0x5f8
 unbind_store+0xbc/0x108
 kernfs_fop_write_iter+0x398/0x584
 vfs_write+0x728/0xf88
 ksys_write+0x110/0x1e4
 ret_fast_syscall+0x0/0x1c
 [...]

David Mosberger-Tan initial investigation [1] showed that this
use-after-free is due to netdevice unregistration during vif list
traversal. When unregistering a net device, since the needs_free_netdev has
been set to true during registration, the netdevice object is also freed,
and as a consequence, the corresponding vif object too, since it is
attached to it as private netdevice data. The next occurrence of the loop
then tries to access freed vif pointer to the list to move forward in the
list.

Fix this use-after-free thanks to two mechanisms:
- navigate in the list with list_for_each_entry_safe, which allows to
  safely modify the list as we go through each element. For each element,
  remove it from the list with list_del_rcu
- make sure to wait for RCU grace period end after each vif removal to make
  sure it is safe to free the corresponding vif too (through
  unregister_netdev)

Since we are in a RCU "modifier" path (not a "reader" path), and because
such path is expected not to be concurrent to any other modifier (we are
using the vif_mutex lock), we do not need to use RCU list API, that's why
we can benefit from list_for_each_entry_safe.

[1] https://lore.kernel.org/linux-wireless/ab077dbe58b1ea5de0a3b2ca21f275a07af967d2.camel@egauge.net/</Note>
    </Notes>
    <CVE>CVE-2024-26895</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: wfx: fix memory leak when starting AP

Kmemleak reported this error:

    unreferenced object 0xd73d1180 (size 184):
      comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.245s)
      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 1e 00 01 00 00 00 00 00  ................
      backtrace:
        [&lt;5ca11420&gt;] kmem_cache_alloc+0x20c/0x5ac
        [&lt;127bdd74&gt;] __alloc_skb+0x144/0x170
        [&lt;fb8a5e38&gt;] __netdev_alloc_skb+0x50/0x180
        [&lt;0f9fa1d5&gt;] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]
        [&lt;7accd02d&gt;] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]
        [&lt;41e25cc3&gt;] wfx_start_ap+0xc8/0x234 [wfx]
        [&lt;93a70356&gt;] ieee80211_start_ap+0x404/0x6b4 [mac80211]
        [&lt;a4a661cd&gt;] nl80211_start_ap+0x76c/0x9e0 [cfg80211]
        [&lt;47bd8b68&gt;] genl_rcv_msg+0x198/0x378
        [&lt;453ef796&gt;] netlink_rcv_skb+0xd0/0x130
        [&lt;6b7c977a&gt;] genl_rcv+0x34/0x44
        [&lt;66b2d04d&gt;] netlink_unicast+0x1b4/0x258
        [&lt;f965b9b6&gt;] netlink_sendmsg+0x1e8/0x428
        [&lt;aadb8231&gt;] ____sys_sendmsg+0x1e0/0x274
        [&lt;d2b5212d&gt;] ___sys_sendmsg+0x80/0xb4
        [&lt;69954f45&gt;] __sys_sendmsg+0x64/0xa8
    unreferenced object 0xce087000 (size 1024):
      comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.246s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        10 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............
      backtrace:
        [&lt;9a993714&gt;] __kmalloc_track_caller+0x230/0x600
        [&lt;f83ea192&gt;] kmalloc_reserve.constprop.0+0x30/0x74
        [&lt;a2c61343&gt;] __alloc_skb+0xa0/0x170
        [&lt;fb8a5e38&gt;] __netdev_alloc_skb+0x50/0x180
        [&lt;0f9fa1d5&gt;] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]
        [&lt;7accd02d&gt;] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]
        [&lt;41e25cc3&gt;] wfx_start_ap+0xc8/0x234 [wfx]
        [&lt;93a70356&gt;] ieee80211_start_ap+0x404/0x6b4 [mac80211]
        [&lt;a4a661cd&gt;] nl80211_start_ap+0x76c/0x9e0 [cfg80211]
        [&lt;47bd8b68&gt;] genl_rcv_msg+0x198/0x378
        [&lt;453ef796&gt;] netlink_rcv_skb+0xd0/0x130
        [&lt;6b7c977a&gt;] genl_rcv+0x34/0x44
        [&lt;66b2d04d&gt;] netlink_unicast+0x1b4/0x258
        [&lt;f965b9b6&gt;] netlink_sendmsg+0x1e8/0x428
        [&lt;aadb8231&gt;] ____sys_sendmsg+0x1e0/0x274
        [&lt;d2b5212d&gt;] ___sys_sendmsg+0x80/0xb4

However, since the kernel is build optimized, it seems the stack is not
accurate. It appears the issue is related to wfx_set_mfp_ap(). The issue
is obvious in this function: memory allocated by ieee80211_beacon_get()
is never released. Fixing this leak makes kmemleak happy.</Note>
    </Notes>
    <CVE>CVE-2024-26896</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ath9k: delay all of ath9k_wmi_event_tasklet() until init is complete

The ath9k_wmi_event_tasklet() used in ath9k_htc assumes that all the data
structures have been fully initialised by the time it runs. However, because of
the order in which things are initialised, this is not guaranteed to be the
case, because the device is exposed to the USB subsystem before the ath9k driver
initialisation is completed.

We already committed a partial fix for this in commit:
8b3046abc99e ("ath9k_htc: fix NULL pointer dereference at ath9k_htc_tx_get_packet()")

However, that commit only aborted the WMI_TXSTATUS_EVENTID command in the event
tasklet, pairing it with an "initialisation complete" bit in the TX struct. It
seems syzbot managed to trigger the race for one of the other commands as well,
so let's just move the existing synchronisation bit to cover the whole
tasklet (setting it at the end of ath9k_htc_probe_device() instead of inside
ath9k_tx_init()).</Note>
    </Notes>
    <CVE>CVE-2024-26897</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak

syzbot identified a kernel information leak vulnerability in
do_sys_name_to_handle() and issued the following report [1].

[1]
"BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40
 instrument_copy_to_user include/linux/instrumented.h:114 [inline]
 _copy_to_user+0xbc/0x100 lib/usercopy.c:40
 copy_to_user include/linux/uaccess.h:191 [inline]
 do_sys_name_to_handle fs/fhandle.c:73 [inline]
 __do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
 __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94
 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
 ...

Uninit was created at:
 slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
 slab_alloc_node mm/slub.c:3478 [inline]
 __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517
 __do_kmalloc_node mm/slab_common.c:1006 [inline]
 __kmalloc+0x121/0x3c0 mm/slab_common.c:1020
 kmalloc include/linux/slab.h:604 [inline]
 do_sys_name_to_handle fs/fhandle.c:39 [inline]
 __do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
 __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94
 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
 ...

Bytes 18-19 of 20 are uninitialized
Memory access of size 20 starts at ffff888128a46380
Data copied to user address 0000000020000240"

Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to
solve the problem.</Note>
    </Notes>
    <CVE>CVE-2024-26901</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Revert "scsi: fcoe: Fix potential deadlock on &amp;fip-&gt;ctlr_lock"

This reverts commit 1a1975551943f681772720f639ff42fbaa746212.

This commit causes interrupts to be lost for FCoE devices, since it changed
sping locks from "bh" to "irqsave".

Instead, a work queue should be used, and will be addressed in a separate
commit.</Note>
    </Notes>
    <CVE>CVE-2024-26917</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ASoC: SOF: Add some bounds checking to firmware data

Smatch complains about "head-&gt;full_size - head-&gt;header_size" can
underflow.  To some extent, we're always going to have to trust the
firmware a bit.  However, it's easy enough to add a check for negatives,
and let's add a upper bounds check as well.</Note>
    </Notes>
    <CVE>CVE-2024-26927</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add a dc_state NULL check in dc_state_release

[How]
Check wheather state is NULL before releasing it.</Note>
    </Notes>
    <CVE>CVE-2024-26948</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wireguard: netlink: access device through ctx instead of peer

The previous commit fixed a bug that led to a NULL peer-&gt;device being
dereferenced. It's actually easier and faster performance-wise to
instead get the device from ctx-&gt;wg. This semantically makes more sense
too, since ctx-&gt;wg-&gt;peer_allowedips.seq is compared with
ctx-&gt;allowedips_seq, basing them both in ctx. This also acts as a
defence in depth provision against freed peers.</Note>
    </Notes>
    <CVE>CVE-2024-26950</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wireguard: netlink: check for dangling peer via is_dead instead of empty list

If all peers are removed via wg_peer_remove_all(), rather than setting
peer_list to empty, the peer is added to a temporary list with a head on
the stack of wg_peer_remove_all(). If a netlink dump is resumed and the
cursored peer is one that has been removed via wg_peer_remove_all(), it
will iterate from that peer and then attempt to dump freed peers.

Fix this by instead checking peer-&gt;is_dead, which was explictly created
for this purpose. Also move up the device_update_lock lockdep assertion,
since reading is_dead relies on that.

It can be reproduced by a small script like:

    echo "Setting config..."
    ip link add dev wg0 type wireguard
    wg setconf wg0 /big-config
    (
            while true; do
                    echo "Showing config..."
                    wg showconf wg0 &gt; /dev/null
            done
    ) &amp;
    sleep 4
    wg setconf wg0 &lt;(printf "[Peer]\nPublicKey=$(wg genkey)\n")

Resulting in:

    BUG: KASAN: slab-use-after-free in __lock_acquire+0x182a/0x1b20
    Read of size 8 at addr ffff88811956ec70 by task wg/59
    CPU: 2 PID: 59 Comm: wg Not tainted 6.8.0-rc2-debug+ #5
    Call Trace:
     &lt;TASK&gt;
     dump_stack_lvl+0x47/0x70
     print_address_description.constprop.0+0x2c/0x380
     print_report+0xab/0x250
     kasan_report+0xba/0xf0
     __lock_acquire+0x182a/0x1b20
     lock_acquire+0x191/0x4b0
     down_read+0x80/0x440
     get_peer+0x140/0xcb0
     wg_get_device_dump+0x471/0x1130</Note>
    </Notes>
    <CVE>CVE-2024-26951</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nilfs2: prevent kernel bug at submit_bh_wbc()

Fix a bug where nilfs_get_block() returns a successful status when
searching and inserting the specified block both fail inconsistently.  If
this inconsistent behavior is not due to a previously fixed bug, then an
unexpected race is occurring, so return a temporary error -EAGAIN instead.

This prevents callers such as __block_write_begin_int() from requesting a
read into a buffer that is not mapped, which would cause the BUG_ON check
for the BH_Mapped flag in submit_bh_wbc() to fail.</Note>
    </Notes>
    <CVE>CVE-2024-26955</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix failure to detect DAT corruption in btree and direct mappings

Patch series "nilfs2: fix kernel bug at submit_bh_wbc()".

This resolves a kernel BUG reported by syzbot.  Since there are two
flaws involved, I've made each one a separate patch.

The first patch alone resolves the syzbot-reported bug, but I think
both fixes should be sent to stable, so I've tagged them as such.


This patch (of 2):

Syzbot has reported a kernel bug in submit_bh_wbc() when writing file data
to a nilfs2 file system whose metadata is corrupted.

There are two flaws involved in this issue.

The first flaw is that when nilfs_get_block() locates a data block using
btree or direct mapping, if the disk address translation routine
nilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata
corruption, it can be passed back to nilfs_get_block().  This causes
nilfs_get_block() to misidentify an existing block as non-existent,
causing both data block lookup and insertion to fail inconsistently.

The second flaw is that nilfs_get_block() returns a successful status in
this inconsistent state.  This causes the caller __block_write_begin_int()
or others to request a read even though the buffer is not mapped,
resulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc()
failing.

This fixes the first issue by changing the return value to code -EINVAL
when a conversion using DAT fails with code -ENOENT, avoiding the
conflicting condition that leads to the kernel bug described above.  Here,
code -EINVAL indicates that metadata corruption was detected during the
block lookup, which will be properly handled as a file system error and
converted to -EIO when passing through the nilfs2 bmap layer.</Note>
    </Notes>
    <CVE>CVE-2024-26956</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: swap: fix race between free_swap_and_cache() and swapoff()

There was previously a theoretical window where swapoff() could run and
teardown a swap_info_struct while a call to free_swap_and_cache() was
running in another thread.  This could cause, amongst other bad
possibilities, swap_page_trans_huge_swapped() (called by
free_swap_and_cache()) to access the freed memory for swap_map.

This is a theoretical problem and I haven't been able to provoke it from a
test case.  But there has been agreement based on code review that this is
possible (see link below).

Fix it by using get_swap_device()/put_swap_device(), which will stall
swapoff().  There was an extra check in _swap_info_get() to confirm that
the swap entry was not free.  This isn't present in get_swap_device()
because it doesn't make sense in general due to the race between getting
the reference and swapoff.  So I've added an equivalent check directly in
free_swap_and_cache().

Details of how to provoke one possible issue (thanks to David Hildenbrand
for deriving this):

--8&lt;-----

__swap_entry_free() might be the last user and result in
"count == SWAP_HAS_CACHE".

swapoff-&gt;try_to_unuse() will stop as soon as soon as si-&gt;inuse_pages==0.

So the question is: could someone reclaim the folio and turn
si-&gt;inuse_pages==0, before we completed swap_page_trans_huge_swapped().

Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are
still references by swap entries.

Process 1 still references subpage 0 via swap entry.
Process 2 still references subpage 1 via swap entry.

Process 1 quits. Calls free_swap_and_cache().
-&gt; count == SWAP_HAS_CACHE
[then, preempted in the hypervisor etc.]

Process 2 quits. Calls free_swap_and_cache().
-&gt; count == SWAP_HAS_CACHE

Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls
__try_to_reclaim_swap().

__try_to_reclaim_swap()-&gt;folio_free_swap()-&gt;delete_from_swap_cache()-&gt;
put_swap_folio()-&gt;free_swap_slot()-&gt;swapcache_free_entries()-&gt;
swap_entry_free()-&gt;swap_range_free()-&gt;
...
WRITE_ONCE(si-&gt;inuse_pages, si-&gt;inuse_pages - nr_entries);

What stops swapoff to succeed after process 2 reclaimed the swap cache
but before process1 finished its call to swap_page_trans_huge_swapped()?

--8&lt;-----</Note>
    </Notes>
    <CVE>CVE-2024-26960</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

clk: qcom: mmcc-msm8974: fix terminating of frequency table arrays

The frequency table arrays are supposed to be terminated with an
empty element. Add such entry to the end of the arrays where it
is missing in order to avoid possible out-of-bound access when
the table is traversed by functions like qcom_find_freq() or
qcom_find_freq_floor().

Only compile tested.</Note>
    </Notes>
    <CVE>CVE-2024-26965</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

clk: qcom: mmcc-apq8084: fix terminating of frequency table arrays

The frequency table arrays are supposed to be terminated with an
empty element. Add such entry to the end of the arrays where it
is missing in order to avoid possible out-of-bound access when
the table is traversed by functions like qcom_find_freq() or
qcom_find_freq_floor().

Only compile tested.</Note>
    </Notes>
    <CVE>CVE-2024-26966</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

clk: qcom: gcc-ipq8074: fix terminating of frequency table arrays

The frequency table arrays are supposed to be terminated with an
empty element. Add such entry to the end of the arrays where it
is missing in order to avoid possible out-of-bound access when
the table is traversed by functions like qcom_find_freq() or
qcom_find_freq_floor().

Only compile tested.</Note>
    </Notes>
    <CVE>CVE-2024-26969</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

clk: qcom: gcc-ipq6018: fix terminating of frequency table arrays

The frequency table arrays are supposed to be terminated with an
empty element. Add such entry to the end of the arrays where it
is missing in order to avoid possible out-of-bound access when
the table is traversed by functions like qcom_find_freq() or
qcom_find_freq_floor().

Only compile tested.</Note>
    </Notes>
    <CVE>CVE-2024-26970</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2024-26972</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix OOB in nilfs_set_de_type

The size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is
defined as "S_IFMT &gt;&gt; S_SHIFT", but the nilfs_set_de_type() function,
which uses this array, specifies the index to read from the array in the
same way as "(mode &amp; S_IFMT) &gt;&gt; S_SHIFT".

static void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode
 *inode)
{
	umode_t mode = inode-&gt;i_mode;

	de-&gt;file_type = nilfs_type_by_mode[(mode &amp; S_IFMT)&gt;&gt;S_SHIFT]; // oob
}

However, when the index is determined this way, an out-of-bounds (OOB)
error occurs by referring to an index that is 1 larger than the array size
when the condition "mode &amp; S_IFMT == S_IFMT" is satisfied.  Therefore, a
patch to resize the nilfs_type_by_mode array should be applied to prevent
OOB errors.</Note>
    </Notes>
    <CVE>CVE-2024-26981</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: check the inode number is not the invalid value of zero

Syskiller has produced an out of bounds access in fill_meta_index().

That out of bounds access is ultimately caused because the inode
has an inode number with the invalid value of zero, which was not checked.

The reason this causes the out of bounds access is due to following
sequence of events:

1. Fill_meta_index() is called to allocate (via empty_meta_index())
   and fill a metadata index.  It however suffers a data read error
   and aborts, invalidating the newly returned empty metadata index.
   It does this by setting the inode number of the index to zero,
   which means unused (zero is not a valid inode number).

2. When fill_meta_index() is subsequently called again on another
   read operation, locate_meta_index() returns the previous index
   because it matches the inode number of 0.  Because this index
   has been returned it is expected to have been filled, and because
   it hasn't been, an out of bounds access is performed.

This patch adds a sanity check which checks that the inode number
is not zero when the inode is created and returns -EINVAL if it is.

[phillip@squashfs.org.uk: whitespace fix]</Note>
    </Notes>
    <CVE>CVE-2024-26982</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sysfs: Fix reference leak in sysfs_break_active_protection()

The sysfs_break_active_protection() routine has an obvious reference
leak in its error path.  If the call to kernfs_find_and_get() fails then
kn will be NULL, so the companion sysfs_unbreak_active_protection()
routine won't get called (and would only cause an access violation by
trying to dereference kn-&gt;parent if it was called).  As a result, the
reference to kobj acquired at the start of the function will never be
released.

Fix the leak by adding an explicit kobject_put() call when kn is NULL.</Note>
    </Notes>
    <CVE>CVE-2024-26993</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tun: limit printing rate when illegal packet received by tun dev

vhost_worker will call tun call backs to receive packets. If too many
illegal packets arrives, tun_do_read will keep dumping packet contents.
When console is enabled, it will costs much more cpu time to dump
packet and soft lockup will be detected.

net_ratelimit mechanism can be used to limit the dumping rate.

PID: 33036    TASK: ffff949da6f20000  CPU: 23   COMMAND: "vhost-32980"
 #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253
 #1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3
 #2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e
 #3 [fffffe00003fced0] do_nmi at ffffffff8922660d
 #4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663
    [exception RIP: io_serial_in+20]
    RIP: ffffffff89792594  RSP: ffffa655314979e8  RFLAGS: 00000002
    RAX: ffffffff89792500  RBX: ffffffff8af428a0  RCX: 0000000000000000
    RDX: 00000000000003fd  RSI: 0000000000000005  RDI: ffffffff8af428a0
    RBP: 0000000000002710   R8: 0000000000000004   R9: 000000000000000f
    R10: 0000000000000000  R11: ffffffff8acbf64f  R12: 0000000000000020
    R13: ffffffff8acbf698  R14: 0000000000000058  R15: 0000000000000000
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 #5 [ffffa655314979e8] io_serial_in at ffffffff89792594
 #6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470
 #7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6
 #8 [ffffa65531497a20] uart_console_write at ffffffff8978b605
 #9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558
 #10 [ffffa65531497ac8] console_unlock at ffffffff89316124
 #11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07
 #12 [ffffa65531497b68] printk at ffffffff89318306
 #13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765
 #14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun]
 #15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun]
 #16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net]
 #17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost]
 #18 [ffffa65531497f10] kthread at ffffffff892d2e72
 #19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f</Note>
    </Notes>
    <CVE>CVE-2024-27013</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Prevent deadlock while disabling aRFS

When disabling aRFS under the `priv-&gt;state_lock`, any scheduled
aRFS works are canceled using the `cancel_work_sync` function,
which waits for the work to end if it has already started.
However, while waiting for the work handler, the handler will
try to acquire the `state_lock` which is already acquired.

The worker acquires the lock to delete the rules if the state
is down, which is not the worker's responsibility since
disabling aRFS deletes the rules.

Add an aRFS state variable, which indicates whether the aRFS is
enabled and prevent adding rules when the aRFS is disabled.

Kernel log:

======================================================
WARNING: possible circular locking dependency detected
6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G          I
------------------------------------------------------
ethtool/386089 is trying to acquire lock:
ffff88810f21ce68 ((work_completion)(&amp;rule-&gt;arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0

but task is already holding lock:
ffff8884a1808cc0 (&amp;priv-&gt;state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-&gt; #1 (&amp;priv-&gt;state_lock){+.+.}-{3:3}:
       __mutex_lock+0x80/0xc90
       arfs_handle_work+0x4b/0x3b0 [mlx5_core]
       process_one_work+0x1dc/0x4a0
       worker_thread+0x1bf/0x3c0
       kthread+0xd7/0x100
       ret_from_fork+0x2d/0x50
       ret_from_fork_asm+0x11/0x20

-&gt; #0 ((work_completion)(&amp;rule-&gt;arfs_work)){+.+.}-{0:0}:
       __lock_acquire+0x17b4/0x2c80
       lock_acquire+0xd0/0x2b0
       __flush_work+0x7a/0x4e0
       __cancel_work_timer+0x131/0x1c0
       arfs_del_rules+0x143/0x1e0 [mlx5_core]
       mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]
       mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]
       ethnl_set_channels+0x28f/0x3b0
       ethnl_default_set_doit+0xec/0x240
       genl_family_rcv_msg_doit+0xd0/0x120
       genl_rcv_msg+0x188/0x2c0
       netlink_rcv_skb+0x54/0x100
       genl_rcv+0x24/0x40
       netlink_unicast+0x1a1/0x270
       netlink_sendmsg+0x214/0x460
       __sock_sendmsg+0x38/0x60
       __sys_sendto+0x113/0x170
       __x64_sys_sendto+0x20/0x30
       do_syscall_64+0x40/0xe0
       entry_SYSCALL_64_after_hwframe+0x46/0x4e

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&amp;priv-&gt;state_lock);
                               lock((work_completion)(&amp;rule-&gt;arfs_work));
                               lock(&amp;priv-&gt;state_lock);
  lock((work_completion)(&amp;rule-&gt;arfs_work));

 *** DEADLOCK ***

3 locks held by ethtool/386089:
 #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40
 #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240
 #2: ffff8884a1808cc0 (&amp;priv-&gt;state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]

stack backtrace:
CPU: 15 PID: 386089 Comm: ethtool Tainted: G          I        6.7.0-rc4_net_next_mlx5_5483eb2 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x60/0xa0
 check_noncircular+0x144/0x160
 __lock_acquire+0x17b4/0x2c80
 lock_acquire+0xd0/0x2b0
 ? __flush_work+0x74/0x4e0
 ? save_trace+0x3e/0x360
 ? __flush_work+0x74/0x4e0
 __flush_work+0x7a/0x4e0
 ? __flush_work+0x74/0x4e0
 ? __lock_acquire+0xa78/0x2c80
 ? lock_acquire+0xd0/0x2b0
 ? mark_held_locks+0x49/0x70
 __cancel_work_timer+0x131/0x1c0
 ? mark_held_locks+0x49/0x70
 arfs_del_rules+0x143/0x1e0 [mlx5_core]
 mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]
 mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]
 ethnl_set_channels+0x28f/0x3b0
 ethnl_default_set_doit+0xec/0x240
 genl_family_rcv_msg_doit+0xd0/0x120
 genl_rcv_msg+0x188/0x2c0
 ? ethn
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-27014</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Use separate handlers for interrupts

For PF to AF interrupt vector and VF to AF vector same
interrupt handler is registered which is causing race condition.
When two interrupts are raised to two CPUs at same time
then two cores serve same event corrupting the data.</Note>
    </Notes>
    <CVE>CVE-2024-27030</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 clk_core_get NULL dereference

It is possible for clk_core_get to dereference a NULL in the following
sequence:

clk_core_get()
    of_clk_get_hw_from_clkspec()
        __of_clk_get_hw_from_provider()
            __clk_get_hw()

__clk_get_hw() can return NULL which is dereferenced by clk_core_get() at
hw-&gt;core.

Prior to commit dde4eff47c82 ("clk: Look for parents with clkdev based
clk_lookups") the check IS_ERR_OR_NULL() was performed which would have
caught the NULL.

Reading the description of this function it talks about returning NULL but
that cannot be so at the moment.

Update the function to check for hw before dereferencing it and return NULL
if hw is NULL.</Note>
    </Notes>
    <CVE>CVE-2024-27038</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: hisilicon: hi3559a: Fix an erroneous devm_kfree()

'p_clk' is an array allocated just before the for loop for all clk that
need to be registered.
It is incremented at each loop iteration.

If a clk_register() call fails, 'p_clk' may point to something different
from what should be freed.

The best we can do, is to avoid this wrong release of memory.</Note>
    </Notes>
    <CVE>CVE-2024-27039</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: fix NULL checks for adev-&gt;dm.dc in amdgpu_dm_fini()

Since 'adev-&gt;dm.dc' in amdgpu_dm_fini() might turn out to be NULL
before the call to dc_enable_dmub_notifications(), check
beforehand to ensure there will not be a possible NULL-ptr-deref
there.

Also, since commit 1e88eb1b2c25 ("drm/amd/display: Drop
CONFIG_DRM_AMD_DC_HDCP") there are two separate checks for NULL in
'adev-&gt;dm.dc' before dc_deinit_callbacks() and dc_dmub_srv_destroy().
Clean up by combining them all under one 'if'.

Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.</Note>
    </Notes>
    <CVE>CVE-2024-27041</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: edia: dvbdev: fix a use-after-free

In dvb_register_device, *pdvbdev is set equal to dvbdev, which is freed
in several error-handling paths. However, *pdvbdev is not set to NULL
after dvbdev's deallocation, causing use-after-frees in many places,
for example, in the following call chain:

budget_register
  |-&gt; dvb_dmxdev_init
        |-&gt; dvb_register_device
  |-&gt; dvb_dmxdev_release
        |-&gt; dvb_unregister_device
              |-&gt; dvb_remove_device
                    |-&gt; dvb_device_put
                          |-&gt; kref_put

When calling dvb_unregister_device, dmxdev-&gt;dvbdev (i.e. *pdvbdev in
dvb_register_device) could point to memory that had been freed in
dvb_register_device. Thereafter, this pointer is transferred to
kref_put and triggering a use-after-free.</Note>
    </Notes>
    <CVE>CVE-2024-27043</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfp: flower: handle acti_netdevs allocation failure

The kmalloc_array() in nfp_fl_lag_do_work() will return null, if
the physical memory has run out. As a result, if we dereference
the acti_netdevs, the null pointer dereference bugs will happen.

This patch adds a check to judge whether allocation failure occurs.
If it happens, the delayed work will be rescheduled and try again.</Note>
    </Notes>
    <CVE>CVE-2024-27046</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ensure offloading TID queue exists

The resume code path assumes that the TX queue for the offloading TID
has been configured. At resume time it then tries to sync the write
pointer as it may have been updated by the firmware.

In the unusual event that no packets have been send on TID 0, the queue
will not have been allocated and this causes a crash. Fix this by
ensuring the queue exist at suspend time.</Note>
    </Notes>
    <CVE>CVE-2024-27056</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nouveau: lock the client object tree.

It appears the client object tree has no locking unless I've missed
something else. Fix races around adding/removing client objects,
mostly vram bar mappings.

 4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI
[ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27
[ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021
[ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau]
[ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 &lt;48&gt; 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe
[ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206
[ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58
[ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400
[ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000
[ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0
[ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007
[ 4562.099528] FS:  00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000
[ 4562.099534] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0
[ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 4562.099544] Call Trace:
[ 4562.099555]  &lt;TASK&gt;
[ 4562.099573]  ? die_addr+0x36/0x90
[ 4562.099583]  ? exc_general_protection+0x246/0x4a0
[ 4562.099593]  ? asm_exc_general_protection+0x26/0x30
[ 4562.099600]  ? nvkm_object_search+0x1d/0x70 [nouveau]
[ 4562.099730]  nvkm_ioctl+0xa1/0x250 [nouveau]
[ 4562.099861]  nvif_object_map_handle+0xc8/0x180 [nouveau]
[ 4562.099986]  nouveau_ttm_io_mem_reserve+0x122/0x270 [nouveau]
[ 4562.100156]  ? dma_resv_test_signaled+0x26/0xb0
[ 4562.100163]  ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm]
[ 4562.100182]  ? __mutex_unlock_slowpath+0x2a/0x270
[ 4562.100189]  nouveau_ttm_fault+0x69/0xb0 [nouveau]
[ 4562.100356]  __do_fault+0x32/0x150
[ 4562.100362]  do_fault+0x7c/0x560
[ 4562.100369]  __handle_mm_fault+0x800/0xc10
[ 4562.100382]  handle_mm_fault+0x17c/0x3e0
[ 4562.100388]  do_user_addr_fault+0x208/0x860
[ 4562.100395]  exc_page_fault+0x7f/0x200
[ 4562.100402]  asm_exc_page_fault+0x26/0x30
[ 4562.100412] RIP: 0033:0x9b9870
[ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 &lt;44&gt; 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7
[ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246
[ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000
[ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066
[ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000
[ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff
[ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 4562.100446]  &lt;/TASK&gt;
[ 4562.100448] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac80211 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-27062</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pstore: inode: Only d_invalidate() is needed

Unloading a modular pstore backend with records in pstorefs would
trigger the dput() double-drop warning:

  WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410

Using the combo of d_drop()/dput() (as mentioned in
Documentation/filesystems/vfs.rst) isn't the right approach here, and
leads to the reference counting problem seen above. Use d_invalidate()
and update the code to not bother checking for error codes that can
never happen.

---</Note>
    </Notes>
    <CVE>CVE-2024-27389</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:kernel-default-5.14.21-150500.55.65.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">tpm2-tools is the source repository for the Trusted Platform Module (TPM2.0) tools. A malicious attacker can generate arbitrary quote data which is not detected by `tpm2 checkquote`. This issue was patched in version 5.7.</Note>
    </Notes>
    <CVE>CVE-2024-29038</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:tpm2.0-tools-5.2-150400.6.3.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">tpm2 is the source repository for the Trusted Platform Module (TPM2.0) tools. This vulnerability allows attackers to manipulate tpm2_checkquote outputs by altering the TPML_PCR_SELECTION in the PCR input file.  As a result, digest values are incorrectly mapped to PCR slots and banks, providing a misleading picture of the TPM state. This issue has been patched in version 5.7.</Note>
    </Notes>
    <CVE>CVE-2024-29039</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:tpm2.0-tools-5.2-150400.6.3.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 repository hosts source code implementing the Trusted Computing Group's (TCG) TPM2 Software Stack (TSS). The JSON Quote Info returned by Fapi_Quote has to be deserialized by Fapi_VerifyQuote to the TPM Structure `TPMS_ATTEST`. For the field `TPM2_GENERATED magic` of this structure any number can be used in the JSON structure. The verifier can receive a state which does not represent the actual, possibly malicious state of the device under test. The malicious device might get access to data it shouldn't, or can use services it shouldn't be able to. This 
issue has been patched in version 4.1.0.</Note>
    </Notes>
    <CVE>CVE-2024-29040</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:libtss2-esys0-3.1.0-150400.3.6.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:libtss2-fapi1-3.1.0-150400.3.6.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:libtss2-mu0-3.1.0-150400.3.6.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:libtss2-rc0-3.1.0-150400.3.6.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:libtss2-sys1-3.1.0-150400.3.6.1</ProductID>
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:libtss2-tctildr0-3.1.0-150400.3.6.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">less through 653 allows OS command execution via a newline character in the name of a file, because quoting is mishandled in filename.c. Exploitation typically requires use with attacker-controlled file names, such as the files extracted from an untrusted archive. Exploitation also requires the LESSOPEN environment variable, but this is set by default in many common cases.</Note>
    </Notes>
    <CVE>CVE-2024-32487</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:less-590-150400.3.9.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An issue was discovered in GNOME GLib before 2.78.5, and 2.79.x and 2.80.x before 2.80.1. When a GDBus-based client subscribes to signals from a trusted system service such as NetworkManager on a shared computer, other users of the same computer can send spoofed D-Bus signals that the GDBus-based client will wrongly interpret as having been sent by the trusted system service. This could lead to the GDBus-based client behaving incorrectly, with an application-dependent impact.</Note>
    </Notes>
    <CVE>CVE-2024-34397</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-15-sp5-chost-byos-v20240529-x86-64:libglib-2_0-0-2.70.5-150400.3.11.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
</cvrfdoc>
